因此，衡量一個項目的測試設計是否到位，是否完善，并不能單從所設計的測試用例個數來衡量，還要真正看到測試用例里面的內容。要想讓測試用例的個數代表點什么的話，我們必須進行測試用例的評審。
測試用例的評審
測試用例設計出來了，質量如何，如何提高測試用例設計的質量?就像軟件產品需要通過各種手段來保證質量一樣，測試用例的質量保證也需要綜合使用各種手段和方法。
測試用例的檢查可以有多種方式，但是最敏捷的應當屬臨時的同行評審。我認為同行評審，尤其是臨時的同行評審，應該演變成類似軟件開發中的“結對編程”一樣的方式。從而體現敏捷的“個體和交互比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設計測試用例，善用“集體智慧”、“群眾的智慧”。
測試用例的評審要點需要至少包括以下幾個方面：
測試用例對需求覆蓋的完整性。
測試用例的有效性。
測試用例的清晰性。
測試用例的可理解性。
測試用例的可維護性。
除了同行評審，還應該盡量引入用戶參與到測試用例的設計中來，讓他們參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。這里顧客的含義比較廣泛，關鍵在于你怎樣定義測試，如果測試是對產品的批判，則顧客應該指最終用戶或顧客代表(在內部可以是市場人員或領域專家);如果測試是指對開發提供幫助和支持，那么顧客顯然就是程序員了。
邀請程序員參與測試用例的評審，就好比臨戰前的“演練”，測試人員是“劍”，開發人員是“盾”，如果開發人員能回答測試人員基于測試用例提出的所有問題，那么OK，測試人員要好好考慮是否應該增強自己的測試用例了，另外，開發人員回去可能也會好好考慮如何增強自己的程序在處理可能出現的異常和錯誤方面的代碼，真可謂“一舉兩得”!
當然，在這種開發人員參與的測試用例評審中，也是一個暴露兩方對于同一需求的不同理解的機會，通過評審和交流，能盡早達成共識，避免造成在測試執行和BUG修改階段產生的“誤會”。
小結
鼓吹測試用例無用論的測試人員可能并沒有真正理解測試用例的意義，沒有意識到測試之前進行“戰略部署”的重要性，同時也很可能誤解了敏捷測試、探索性測試的方法，把自由、隨意當成了敏捷，把隨機的、即興的測試當成了探索性測試。
測試用例可粗可細，可建立完善的測試用例庫，也可僅僅用一個Excel表來記錄，但是一定要對測試進行“設計”，在與軟件BUG進行的持續“戰斗”中，一定要體現出測試人員的“智慧”來，相信“胸有成竹，則戰無不勝”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
