如何評價測試用例的有效性?

　　很多測試團多都會既開展腳本化的測試(Scripted Testing)，也開展探索性的測試(Exploratory Testing)，關于二者的定義和區別，可以參見Cem Kaner的膠片：http://www.kaner.com/pdfs/QAIExploring.pdf

　　本文探討腳本化測試中的測試用例的有效性問題，尤其是針對功能性測試用例而言。

　　如何評價測試用例的有效性?

　　我的答案：Incremental Analysis & Traceability

　　你所在團隊是如何評價測試用例的有效性的?

　　- 對用例進行檢視

　　- 看用例總數

　　- 看代碼覆蓋率

　　- 網上問題多少

　　- 千行代碼用例數

　　- 用例發現缺陷密度

　　。。。。。。

　　如何評價代碼的有效性?– 通過測試驗證。

　　如何評價測試用例的有效性? — 通過產品發布后用戶反饋的問題。

　　OK, 用戶反饋的問題確實能總體上評價測試的有效性，不過這已經是事后了，我們想事前就能有信心。

　　那么，換一種問法。

　　如何確保，你寫的代碼確實實現了給定的需求?

　　看一看我們的V模型吧，從“需求”到“代碼”你走了怎樣的路?你從拿到需求開始，開展了一系列的活動，需求分析、功能設計、技術設計，經過這些增量的過程，你的分析越來越深入，最終出來的是代碼，這樣的系統化的過程本身就一定程度地保證了你的代碼是針對這些需求的、是有效的(這就是verification)，但不一定是正確的，也許其中還有bug，這可以通過事后的測試活動找出來(這就是validation)。

　　即使你采用敏捷開發，也仍然需要進行“需求分析”“系統設計”“編碼”。

　　那么如何確保，你寫的測試用例充分地測試了給定的需求?

　　從“需求”到“測試用例”你走了怎樣的路?你是拿到需求，基于個人經驗，寫出來一大批用例?(這就像你拿到需求一上來就編碼一樣。) 你是否經過了一個“系統化的、增量的、分析過程”，來一步一步地確保你的用例能夠充分覆蓋這些需求?這就是我所說的測試分析設計的框架的概念。你需要分析、畫model、找出測試條件，然后才出具測試用例，你需要這樣一系列的過程。

　　你是否會對每一行代碼進行檢視之后，才知道代碼的有效性或質量?不會。那為什么要求“通過逐個檢視測試用例，就能判斷出測試用例的有效性”呢?

　　你是否會通過代碼行的總數判斷代碼的有效性(是否實現了需求)?不會。那么為什么要去“通過檢查測試用例個數或密度的方法來判斷測試用例的有效性”呢?

　　你是否因為需求分析、功能設計、技術設計等這些CMM的中間過程太耗時，而要求員工直接編碼呢?不會。那為什么叫喊“測試分析、畫model等測試設計活動工作量太大了”呢?(每當我講完一次“MFQ&PPDCS：軟件測試分析與測試設計”這門課，培訓調查表中就會有這樣的反饋：“測試分析的工作量太大了，沒有時間做”;而與此同時，課前反饋的培訓需求中又總是會有“學習測試設計技術，確保測試用例的有效性”、“設計出高質量的用例”。)

　　一邊希望幾乎不花什么時間、不用太費腦筋，就能得出測試用例;一邊又對測試用例的有效性和評估提出高要求。測試是一種投資，測試設計活動更是一種投資，用戶會買你的代碼，但不會買你的測試用例。你的用例的質量可以增加你對代碼質量的信心，這其中是個平衡。如果你自信你的代碼質量很高，那么恭喜你，無須在測試用例上投資太多;如果你沒有這份自信，那么請不要不舍得在測試設計上多投一些時間，請不要不愿意花一點精力去專研測試設計這門技術，更不要認為只有編碼是高尚的技術行為、測試只是沒有什么技術含量的活兒。

　　如果你想知道你的產品的測試用例的有效性，我的建議，從測試分析設計框架上看，不僅僅看最終的一個一個的測試用例，更要看的是中間的、增量的、測試分析設計的過程，同時確保從需求到model、到測試條件、到測試用例的可跟蹤性。

原文轉自：http://www.anti-gravitydesign.com