設計的軟體測試用例是否越詳細越好？

　　軟體測試人員設計測試用例的時候，面臨的第一個問題就是軟體測試用例的步驟是否越詳細越好？或者如何把握軟體測試用例的詳細步驟？在這個問題上，贊成測試用例詳細化的人肯定有不少，因為詳細測試用例可以提供如下優點：

　　1）缺乏經驗或者技能的軟體測試人員，可以按照測試用例的步驟順利開展測試執行工作。這是指令碼化測試實踐中的思維：有經驗與技能的測試人員設計測試用例，而缺乏經驗的人員去執行測試用例。

　　2）缺乏經驗的測試人員，按照詳細測試用例的步驟執行的過程，不僅可以幫助他們瞭解測試物件的功能與業務知識，也可以幫助他們瞭解測試設計技術與方法。

　　3）更好的一致性。由於設計的測試用例提供了詳細了步驟，每個測試人員按照這個步驟可以得到一直的測試結果，因此保證測試一致性。

　　3）有助於測試用例的自動化。因為詳細的測試用例提供了詳細的步驟和期望的結果，因此將它們轉化為自動化測試用例會相對比較簡單。

　　4）有時候提供詳細的測試用例，是為了滿足法律法規的要求，特別是針對安全關鍵系統，在有審計的情況下。

　　儘管詳細化測試用例可以有上述的優點，但是反對測試用例詳細化的也大有人在，因為詳細化測試用例也會導致一系列的問題：

　　1）設計成本高：測試人員需要花費大量的時間投入到測試用例的編寫上面。同時測試用例文件的頁數越多，被完整閱讀的可能性就越少。

　　2）效果差：窮盡測試不可能，好的測試用例設計是從無窮的測試中選擇合理測試輸入、測試組合、測試資料等，以相對有限的測試用例數目儘量達到理想的覆蓋率。而詳細的測試用例設計很難完全定義這些組合和場景，實踐中需要測試設計不斷迭代和更新。

　　3）維護成本高：測試用例的輸入參考，例如：需求文件是經常變更的，這就會導致測試用例越詳細，其維護的工作量更大。

　　因此，測試用例的詳細程度要求，並沒有一個標準的答案，儘管我是輕量級測試用例設計的擁護者。測試用例詳細與否，會受到各種因素的因素，例如：

　　1）測試目標。測試人員測試該產品或者系統的目標是什麼。假如測試用例文件不能支援這個目標，或者無助於達到這個目標，那麼這樣的測試用例設計文件價值就會降低很多。

　　2）測試用例文件是產品還是工具。假如測試用例文件是軟體系統或者產品的一部分，那麼這些文件是需要釋出給客戶使用的，這時候測試用例文件就需要按照客戶的要求遵循某種表尊。而假如它們只是內部使用的工具，那麼就不必太完整、太整齊，能夠在最低限度上有助於達到目標即可。

　　3）軟體設計變更是否頻繁。如果軟體設計變更很頻繁，則不要將許多細節寫入測試用例文件中，因為這些細節很快就會過時。這種情況下，不要編寫大量的測試用例文件，它們被修改或者放棄的速度太快，不值得在測試用例文件上投入太多。

　　4）採用的測試方法。假如目前採用的軟體開發模型是V模型之類的線性模型，那麼採用的測試方法通常是依賴於預先定義的測試，這時候需要詳細的測試用例的操作和維護文件。假如採用的是探索性測試，則更需要策略方面的文件，例如：關於某個測試領域的想法，但不是具體的測試用例。

　　5）測試用例文件給誰看。假如測試用例文件是主要給新的測試人員或者沒有經驗的測試人員看，那麼需要足夠詳細使得他們能夠正常開展工作。

本文轉載自51Testing軟體測試網，檢視更多：http://www.51testing.com/html/news.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1059557/，如需轉載，請註明出處，否則將追究法律責任。