對(duì)于測(cè)試人員來(lái)說(shuō)測(cè)試用例的設(shè)計(jì)編寫(xiě)是一項(xiàng)必須掌握的能力，但有效的設(shè)計(jì)和熟練的編寫(xiě)卻是一個(gè)十分復(fù)雜的技術(shù)，它需要你對(duì)整個(gè)軟件不管從業(yè)務(wù)還是從功能上都有一個(gè)明晰的把握。那么，軟件測(cè)試用例的設(shè)計(jì)編寫(xiě)技巧有哪些呢?下面就讓小編來(lái)告訴的大家吧!
軟件測(cè)試用例的設(shè)計(jì)編寫(xiě)技巧
一、問(wèn)題
許多測(cè)試類書(shū)籍中都有大幅的篇章介紹用例的設(shè)計(jì)方法，如等價(jià)類劃分，邊界值，錯(cuò)誤推斷，因果圖等。但實(shí)際應(yīng)用中這些理論卻不能給我們很明確的行為指導(dǎo)，尤其是業(yè)務(wù)復(fù)雜，關(guān)聯(lián)模塊緊密，輸入標(biāo)準(zhǔn)和輸出結(jié)果間路徑眾多時(shí)，完全的遵循這些方法只能讓我們?cè)谛睦砩系玫揭环N滿足，而無(wú)法有效的提高測(cè)試效率。有時(shí)我們只有依靠以前項(xiàng)目的用例編寫(xiě)經(jīng)驗(yàn)(或習(xí)慣)，希望能在這一個(gè)項(xiàng)目中更加規(guī)范，但多數(shù)情況下我們規(guī)范的只是“書(shū)寫(xiě)的規(guī)范”，在用例設(shè)計(jì)上以前存在的問(wèn)題現(xiàn)在依舊。
當(dāng)好不容易用例基本完成，我們卻發(fā)現(xiàn)面對(duì)隨之而來(lái)的眾多地區(qū)特性和新增需求，測(cè)試用例突然處于一種十分尷尬的境地：
從此幾乎很少被執(zhí)行
執(zhí)行用例發(fā)現(xiàn)的bug很少
根本沒(méi)有時(shí)間為新的功能需求增補(bǔ)用例
有時(shí)間補(bǔ)充，但用例結(jié)構(gòu)越來(lái)越亂
特性的用例與通性用例之間聯(lián)系不明確(以新增需求為主線列出所有涉及到的更改，但特性與通行之間的數(shù)據(jù)或業(yè)務(wù)聯(lián)系在用例中逐漸淡化)
知道怎樣執(zhí)行這個(gè)用例，但它要說(shuō)明什么呢?(多數(shù)用例給我們的感覺(jué)是只見(jiàn)樹(shù)木，不見(jiàn)森林，只對(duì)某一功能，無(wú)法串起)
通過(guò)上面的一系列問(wèn)題可以看到，似乎測(cè)試用例給我們帶來(lái)的問(wèn)題遠(yuǎn)多于益 處，也正是因?yàn)樵趯?shí)際過(guò)程中遇到的問(wèn)題積累，導(dǎo)致我們有很充分的理由忽視或拒絕用例的應(yīng)用。
但沒(méi)有用例或簡(jiǎn)略用例的編寫(xiě)我們又會(huì)舒服很多么?不言自明，誰(shuí)也不想倒退發(fā)展吧。
二、原因
事實(shí)上我們?cè)跍y(cè)試用例編寫(xiě)和設(shè)計(jì)上遇到的一系列問(wèn)題只是一種表面的呈現(xiàn)，究其原因我認(rèn)為有如下幾點(diǎn)：
1、沒(méi)有適合的規(guī)范
“適合的規(guī)范”或稱“本地化的規(guī)范”。這是我們?cè)跍y(cè)試過(guò)程中遇到的第一個(gè)問(wèn)題，通常也是很容易習(xí)慣且淡忘的。我們擁有相當(dāng)多的流程文檔、書(shū)本上的定義，但它適合我們當(dāng)前的項(xiàng)目么?
每一個(gè)測(cè)試工程師在進(jìn)入這個(gè)職業(yè)的初期都會(huì)了解一些測(cè)試上的概念和術(shù)語(yǔ)，進(jìn)入公司或項(xiàng)目組后也會(huì)進(jìn)一步學(xué)習(xí)相應(yīng)的文檔，例如怎樣規(guī)范編寫(xiě)，怎樣定義bug級(jí)別，軟件實(shí)現(xiàn)的主要業(yè)務(wù)等。但當(dāng)測(cè)試經(jīng)理開(kāi)始給我們分配某一模塊的用例編寫(xiě)時(shí)，又有多少人知道該怎樣去寫(xiě)，怎樣寫(xiě)算是好?
在測(cè)試論壇中常能看到介紹用例編寫(xiě)方法的帖子，而迷茫于怎樣應(yīng)用到實(shí)踐的回復(fù)也不為少數(shù)。為何我們無(wú)法在公司和項(xiàng)目組內(nèi)找到明確且適合的規(guī)范?于是我們只得選擇從書(shū)本或之前的用例中復(fù)制，不管是結(jié)構(gòu)還是方式都依賴于以往"的經(jīng)驗(yàn)，我并不是說(shuō)這樣就是錯(cuò)誤的，但不能總結(jié)成文的經(jīng)驗(yàn)無(wú)法給予測(cè)試更多幫助。
我們有太多經(jīng)驗(yàn)，但卻沒(méi)有形成適合的規(guī)范。
2、功能與業(yè)務(wù)的分離
我們知道怎樣列舉一個(gè)輸入框的用例，但卻很少考慮說(shuō)明這個(gè)輸入框是用來(lái)做什么的，如果仔細(xì)分析不難發(fā)現(xiàn)，用例中這種功能與業(yè)務(wù)的分離越來(lái)越普遍也越來(lái)越明顯。
邊界值、等價(jià)類劃分、因果圖，這些用例方法是一種高度提純的方法，本身就很偏向于功能及代碼，所以怎樣編寫(xiě)業(yè)務(wù)的用例我們就從理論上失去了參考。
復(fù)雜的業(yè)務(wù)會(huì)貫穿于整個(gè)軟件，涉及眾多功能點(diǎn)，里面組合的分支更不可勝數(shù)。測(cè)試用例務(wù)求簡(jiǎn)潔、明確，這一點(diǎn)也與業(yè)務(wù)“格格不入”。功能用例依賴程序界面，業(yè)務(wù)描述依賴需求文檔。于是我們更偏向于根據(jù)已實(shí)現(xiàn)的界面編寫(xiě)功能用例，列舉出眾多的邊界值、等價(jià)類。
流程的操作只有憑借經(jīng)驗(yàn)和理解，這時(shí)測(cè)試出的bug是最多的，但我們卻無(wú)法使這個(gè)bug對(duì)應(yīng)到一個(gè)用例中(點(diǎn)擊一個(gè)按鈕報(bào)出的錯(cuò)誤有時(shí)原因并不在這個(gè)按鈕或按鈕所在的窗體)。正因?yàn)槲覀儧](méi)有很好的積累業(yè)務(wù)上的用例，才使得我們感到執(zhí)行用例時(shí)發(fā)現(xiàn)的bug不多。
用例結(jié)構(gòu)的劃分一定程度上也造成了功能和業(yè)務(wù)的分離，依照界面模塊建立文件夾，并在其中新建不同用例，這使得用例從結(jié)構(gòu)上就很難聯(lián)通起來(lái)。
3、測(cè)試未能跟上變化
想象一下，當(dāng)我們?cè)絹?lái)越多的聽(tīng)到開(kāi)發(fā)人員在那里高呼“擁抱變化”“敏捷開(kāi)發(fā)”的時(shí)候，測(cè)試又有什么舉措呢?當(dāng)?shù)貐^(qū)特性，軟件版本越來(lái)越多的時(shí)候，測(cè)試是否在積極響應(yīng)呢?變化是我們面臨的最大挑戰(zhàn)，我認(rèn)為測(cè)試未能跟上變化是造成測(cè)試過(guò)程中遇到種種問(wèn)題和矛盾的主要原因。
對(duì)需求和程序的變化測(cè)試人員的感受是非常深的，測(cè)試總是跟在需求和開(kāi)發(fā)后面跑，使得所有風(fēng)險(xiǎn)都?jí)涸谧约荷砩�。不斷壓縮的時(shí)間和資源使我們只能放棄那些“不必要”的工作：盡快投入測(cè)試，盡快發(fā)現(xiàn)bug，而非從整體把握軟件的質(zhì)量情況，統(tǒng)籌策略。
疲于應(yīng)對(duì)的直接影響就是程序質(zhì)量無(wú)法準(zhǔn)確度量，進(jìn)度無(wú)法控制，風(fēng)險(xiǎn)無(wú)法預(yù)估。用例與程序脫節(jié)，新增用例混亂和缺少。長(zhǎng)此以往我們只得放棄修改、增補(bǔ)用例，甚至放棄之前積累的所有成果。用例變?yōu)槌绦蜃兏挠涗浾瑳](méi)有測(cè)試數(shù)據(jù)的保留，測(cè)試步驟和重點(diǎn)無(wú)法體現(xiàn)，新加功能與原來(lái)的程序逐漸“脫離”，可能還會(huì)出現(xiàn)相互違背的情況，但這我們卻無(wú)法很快發(fā)現(xiàn)。
永遠(yuǎn)是變化決定我們的下一步工作，這也是混亂的開(kāi)始。
三、可能解決的辦法
在這里我希望以探討的方式提出一些可能的解決辦法，因?yàn)樯厦娴膯?wèn)題也許在成熟的公司和項(xiàng)目組內(nèi)很少遇到，而遇到問(wèn)題的也需根據(jù)不同的情況單獨(dú)考慮。不用拘泥形式，最適合的就是最好的。
1、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，用例指導(dǎo)結(jié)果，數(shù)據(jù)記錄變化
“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)”(TDD)是一個(gè)比較新的概念，在網(wǎng)上可以看到很多介紹文章，它主要討論如何讓開(kāi)發(fā)的代碼更奏效(Work)更潔凈(Clean)，“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的基本思想就是在開(kāi)發(fā)功能代碼之前，先編寫(xiě)測(cè)試代碼”�？梢钥吹�，TDD是建立在“代碼”級(jí)別的驅(qū)動(dòng)，但目前我們需要探討的問(wèn)題是怎樣在黑盒測(cè)試中做到“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)”。
首先我們需要糾正一個(gè)態(tài)度，很多人認(rèn)為黑盒測(cè)試的技術(shù)含量不高，可思考可拓展的內(nèi)容不多，主要的工作就是用鼠標(biāo)在那里瞎點(diǎn)，于是很多“高級(jí)”的技術(shù)方法都試圖與黑盒測(cè)試劃清界限。但測(cè)試人員發(fā)現(xiàn)的bug有80%以上都是黑盒測(cè)試發(fā)現(xiàn)的，手工操作軟件仍是目前檢驗(yàn)軟件質(zhì)量最有效的一種方法。
如何在黑盒測(cè)試中做到測(cè)試驅(qū)動(dòng)開(kāi)發(fā)?我認(rèn)為可以從用例級(jí)別做起，以業(yè)務(wù)用例指導(dǎo)過(guò)程和結(jié)果。
開(kāi)發(fā)人員通常比較關(guān)注技術(shù)，對(duì)于業(yè)務(wù)上的理解容易忽視并出現(xiàn)偏差，而需求文檔又不會(huì)很明確的指出應(yīng)該實(shí)現(xiàn)怎樣的結(jié)果，這使得從業(yè)務(wù)到功能出現(xiàn)一個(gè)“閱讀上的障礙”，如果最后程序錯(cuò)誤了還需返工，這樣耗費(fèi)的人力物力就非常大了。使用業(yè)務(wù)用例驅(qū)動(dòng)開(kāi)發(fā)，就是一個(gè)比較好的方法，同樣這也需要運(yùn)用測(cè)試中的各種方法，列舉出業(yè)務(wù)流程里數(shù)據(jù)的等價(jià)類和邊界值。
業(yè)務(wù)用例的構(gòu)造要先于程序?qū)崿F(xiàn)，與需求和開(kāi)發(fā)人員溝通一致，并以此作為一個(gè)基準(zhǔn)，保證程序?qū)崿F(xiàn)不會(huì)錯(cuò)，還能對(duì)整個(gè)軟件的進(jìn)度和質(zhì)量有一個(gè)很好的估計(jì)和度量。業(yè)務(wù)用例可以不關(guān)注程序的界面，但一定要有數(shù)據(jù)的支持。
這就是測(cè)試主導(dǎo)變化的另一點(diǎn)“數(shù)據(jù)記錄變化”。
我們不僅要應(yīng)對(duì)變化，還要記錄變化，使測(cè)試用例成為對(duì)程序持續(xù)性的監(jiān)控，數(shù)據(jù)可以作為最基本、最簡(jiǎn)單的支持。當(dāng)一個(gè)業(yè)務(wù)很復(fù)雜時(shí)可以拆分成段(業(yè)務(wù)段與程序中以窗體或頁(yè)面的劃分是不一樣的)，使用典型的用例方法列出實(shí)際輸入和預(yù)期結(jié)果。我們希望數(shù)據(jù)能做到通用和共享，最理想的情況就是建立一個(gè)“數(shù)據(jù)庫(kù)”，每個(gè)業(yè)務(wù)用例都從“數(shù)據(jù)庫(kù)”中取得輸入數(shù)據(jù)和預(yù)期結(jié)果，這個(gè)數(shù)據(jù)只是針對(duì)業(yè)務(wù)入口和出口的，當(dāng)程序內(nèi)部設(shè)計(jì)變更時(shí)，保留的數(shù)據(jù)不會(huì)因此而作廢。
舉一個(gè)例子，例如我的程序要從某種文件中讀取數(shù)據(jù)并計(jì)算結(jié)果，一段時(shí)間后程序內(nèi)部字段增加了，如果是以保存的文件附件方式提供數(shù)據(jù)，則現(xiàn)在程序很可能就打不開(kāi)這個(gè)文件了。使用“數(shù)據(jù)庫(kù)”指導(dǎo)測(cè)試人員可以在變化的程序里直接針對(duì)業(yè)務(wù)輸入，而不關(guān)心程序內(nèi)部結(jié)構(gòu)。
再進(jìn)一步的話“數(shù)據(jù)庫(kù)”就開(kāi)始涉及到程序內(nèi)部的接口了，這需要開(kāi)發(fā)人員的配合。
為測(cè)試用例標(biāo)明時(shí)間或版本可以起到一種基準(zhǔn)的作用，標(biāo)明項(xiàng)目進(jìn)度過(guò)程中的每一個(gè)階段，使用例直接和需求基線、軟件版本對(duì)應(yīng)。同樣這需要規(guī)范流程，也是對(duì)變更的一種確認(rèn)和控制�；蛘呖梢詾橛美黾右粋�(gè)狀態(tài)，指明這個(gè)用例目前是否與程序沖突，當(dāng)程序變更時(shí)改變用例的狀態(tài)，并更新用例版本。
為測(cè)試用例標(biāo)明優(yōu)先級(jí)可以指出軟件的測(cè)試重點(diǎn)、用例編寫(xiě)的重點(diǎn)，減少用例回歸的時(shí)間，增加重點(diǎn)用例執(zhí)行的次數(shù)，幫助項(xiàng)目組新人盡快了解需求，在自動(dòng)化測(cè)試的初期也可以參考這個(gè)優(yōu)先級(jí)錄制腳本。
2、功能用例與業(yè)務(wù)用例分開(kāi)組織
將功能用例與業(yè)務(wù)用例分開(kāi)組織，按照不同關(guān)注點(diǎn)列舉執(zhí)行路徑。業(yè)務(wù)用例應(yīng)在開(kāi)發(fā)前或同期編寫(xiě)，幫助測(cè)試人員和開(kāi)發(fā)人員明確業(yè)務(wù)，了解正確流程和錯(cuò)誤流程。功能用例更依賴于程序界面的描述，但功能用例并不等于使用說(shuō)明。對(duì)某些模塊的等價(jià)類、邊界值測(cè)試會(huì)發(fā)現(xiàn)很多嚴(yán)重的bug，也許與業(yè)務(wù)無(wú)關(guān)，但用戶往往很容易這樣操作(例如登錄名，你是否考慮到很長(zhǎng)的名字，或者用戶的鍵盤(pán)有問(wèn)題，總是敲入n多空格在里面，這與業(yè)務(wù)無(wú)關(guān)，但程序?qū)?huì)怎樣處理?)。
3、審核用例，結(jié)對(duì)編寫(xiě)
測(cè)試組長(zhǎng)或經(jīng)理對(duì)用例進(jìn)行審核可以做到用例的補(bǔ)充和校對(duì)，但一般情況下是很難做到的，我們可以采用另一種方法，就是結(jié)對(duì)編寫(xiě)測(cè)試用例(前提是你有兩個(gè)以上的測(cè)試人員)，內(nèi)部審核。
測(cè)試用例不是一個(gè)人編寫(xiě)一個(gè)人執(zhí)行，它需要其他測(cè)試人員都能讀懂且明白目標(biāo)所指。結(jié)對(duì)編寫(xiě)可以盡量減少個(gè)人的“偏好習(xí)慣”，同時(shí)也能拓展思維，加強(qiáng)測(cè)試重點(diǎn)的確認(rèn)，小組內(nèi)部達(dá)到統(tǒng)一。一定程度上結(jié)對(duì)編寫(xiě)也可以減少組長(zhǎng)或經(jīng)理對(duì)用例的管理，提高組員的參與積極性。
四、發(fā)展
上面的這些解決方法只是一種建議，具體怎樣實(shí)施到項(xiàng)目中還需根據(jù)情況而定�？梢钥吹綔y(cè)試的發(fā)展方向是很多很廣的，傳統(tǒng)的黑盒測(cè)試并不是毫無(wú)新意，測(cè)試工作怎樣適合我們而發(fā)展，將給予我們更多的思考。