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