下面是用例設計後出現的較為常見的問題：

• 從此幾乎很少被執行

• 執行用例發現的bug很少

• 根本沒有時間為新的功能需求增補用例

• 有時間補充，但用例結構越來越亂

• 特性的用例與通性用例之間聯系不明確(以新增需求為主線列出所有涉及到的更改，但特性與通行之間的數據或業務聯系在用例中逐漸淡化)

• 知道怎樣執行這個用例，但它要說明什麽呢?(多數用例給我們的感覺是只見樹木，不見森林，只對某一功能，無法串起)

通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多於益 處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。

事實上我們在測試用例編寫和設計上遇到的一系列問題只是一種表面的呈現，究其原因有如下幾點：

1、沒有適合的規範

2、功能與業務的分離

3、測試未能跟上變化

下面給大家列舉一些解決的辦法

在這裏我希望以探討的方式提出一些可能的解決辦法，因為上面的問題也許在成熟的公司和項目組內很少遇到，而遇到問題的也需根據不同的情況單獨考慮。不用拘泥形式，最適合的就是最好的。

1、測試驅動開發，用例指導結果，數據記錄變化

“測試驅動開發”(TDD)是一個比較新的概念，在網上可以看到很多介紹文章，它主要討論如何讓開發的代碼更奏效(Work)更潔凈(Clean)，“測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼”。

可以看到，TDD是建立在“代碼”級別的驅動，但目前我們需要探討的問題是怎樣在黑盒測試中做到“測試驅動開發”。

首先我們需要糾正一個態度，很多人認為黑盒測試的技術含量不高，可思考可拓展的內容不多，主要的工作就是用鼠標在那裏瞎點，於是很多“高級”的技術方法都試圖與黑盒測試劃清界限。

但測試人員發現的bug有80%以上都是黑盒測試發現的，手工操作軟件仍是目前檢驗軟件質量最有效的一種方法。

如何在黑盒測試中做到測試驅動開發?我認為可以從用例級別做起，以業務用例指導過程和結果。

開發人員通常比較關註技術，對於業務上的理解容易忽視並出現偏差，而需求文檔又不會很明確的指出應該實現怎樣的結果，這使得從業務到功能出現一個“閱讀上的障礙”，如果最後程序錯誤了還需返工，這樣耗費的人力物力就非常大了。

使用業務用例驅動開發，就是一個比較好的方法，同樣這也需要運用測試中的各種方法，列舉出業務流程裏數據的等價類和邊界值。

業務用例的構造要先於程序實現，與需求和開發人員溝通一致，並以此作為一個基準，保證程序實現不會錯，還能對整個軟件的進度和質量有一個很好的估計和度量。

業務用例可以不關註程序的界面，但一定要有數據的支持。

這就是測試主導變化的另一點“數據記錄變化”。

我們不僅要應對變化，還要記錄變化，使測試用例成為對程序持續性的監控，數據可以作為最基本、最簡單的支持。

當一個業務很復雜時可以拆分成段(業務段與程序中以窗體或頁面的劃分是不一樣的)，使用典型的用例方法列出實際輸入和預期結果。

我們希望數據能做到通用和共享，最理想的情況就是建立一個“數據庫”，每個業務用例都從“數據庫”中取得輸入數據和預期結果，這個數據只是針對業務入口和出口的，當程序內部設計變更時，保留的數據不會因此而作廢。

舉一個例子，例如我的程序要從某種文件中讀取數據並計算結果，一段時間後程序內部字段增加了，如果是以保存的文件附件方式提供數據，則現在程序很可能就打不開這個文件了。

使用“數據庫”指導測試人員可以在變化的程序裏直接針對業務輸入，而不關心程序內部結構。

再進一步的話“數據庫”就開始涉及到程序內部的接口了，這需要開發人員的配合。

為測試用例標明時間或版本可以起到一種基準的作用，標明項目進度過程中的每一個階段，使用例直接和需求基線、軟件版本對應。

同樣這需要規範流程，也是對變更的一種確認和控制。或者可以為用例增加一個狀態，指明這個用例目前是否與程序沖突，當程序變更時改變用例的狀態，並更新用例版本。

為測試用例標明優先級可以指出軟件的測試重點、用例編寫的重點，減少用例回歸的時間，增加重點用例執行的次數，幫助項目組新人盡快了解需求，在自動化測試的初期也可以參考這個優先級錄制腳本。

2、功能用例與業務用例分開組織

將功能用例與業務用例分開組織，按照不同關註點列舉執行路徑。業務用例應在開發前或同期編寫，幫助測試人員和開發人員明確業務，了解正確流程和錯誤流程。

功能用例更依賴於程序界面的描述，但功能用例並不等於使用說明。對某些模塊的等價類、邊界值測試會發現很多嚴重的bug，也許與業務無關，但用戶往往很容易這樣操作(例如登錄名，你是否考慮到很長的名字，或者用戶的鍵盤有問題，總是敲入n多空格在裏面，這與業務無關，但程序將會怎樣處理?)。

3、審核用例，結對編寫

測試組長或經理對用例進行審核可以做到用例的補充和校對，但一般情況下是很難做到的，我們可以采用另一種方法，就是結對編寫測試用例(前提是你有兩個以上的測試人員)，內部審核。

測試用例不是一個人編寫一個人執行，它需要其他測試人員都能讀懂且明白目標所指。結對編寫可以盡量減少個人的“偏好習慣”，同時也能拓展思維，加強測試重點的確認，小組內部達到統一。

一定程度上結對編寫也可以減少組長或經理對用例的管理，提高組員的參與積極性。

深度解析用例設計方法