模板
教程
環境
性能
功能
管理
測試用例可以當需求嗎？
發表于：2009-03-05來源：作者：點擊數：
標簽：需求
如果我們循序漸進地做項目，那么一個大型軟件項目就成了一系列小的項目。在這些小項目中，如果我們無法為下面兩周所作的 工作 制定可供 測試 的驗收標準，那么我們的麻煩就大了。如果我們可以制定該標準，那么我們為什么不直接用 測試用例 來表現該標準，反而
如果我們循序漸進地做項目，那么一個大型軟件項目就成了一系列小的項目。在這些小項目中，如果我們無法為下面兩周所作的工作制定可供測試的驗收標準，那么我們的麻煩就大了。如果我們可以制定該標準，那么我們為什么不直接用測試用例來表現該標準，反而要用其它方式表現該標準而后又從中衍生測試用例呢？”
-- Steven Gordon, 博士, 原文出自Agile Testing List
Steven Gordon在上文中所推薦的想法超過了普通的驗收測試自動化。事實上，他建議我們直接把測試用例當作產品需求來用。換句話說：如果我們在一開始就開發了測試用例，用其衡量代碼是否正確 -- 那么需求文檔還拿來干什么呢？如果測試用例通過了，代碼就是正確的。如果現有用例不能論證代碼是正確的，那么我們則需要更多的測試。
我得承認，這種邏輯有些誘人。第一，自動測試用例是具體、明確、而且顯然可測試的。你（至少現在）不可能寫一個能“適當的處理錯誤”的模棱兩可的自動測試。反之，你必須定義發生錯誤的情況，軟件對其反應，以及怎么去衡量這些錯誤是否正確。同時，發現不一致的測試要比發現不一致的需求容易的多。比如：“這兩個用例輸入一樣，輸出卻不同，到底哪個正確？”
但現實中是什么樣的呢？
試想現在我們有個項目是設計并創造一個簡單的網頁 – 一個把華氏度轉為攝氏度的在線服務。我們的商業用戶制定了一套驗收測試，而我們把它全部自動到只要按一個按鈕就能運行。在產品初具規模時，我們運行這個自動測試工具而得出了以下結果：
|
函數 |
輸入 |
期待輸出 |
實際輸出 |
結果 |
|
Convert_Farenheit_To_Celsius |
32 |
0 |
0 | |
|
Convert_Farenheit_To_Celsius |
212 |
100 |
100 | |
|
Convert_Farenheit_To_Celsius |
100 |
38 |
38 | |
|
Convert_Farenheit_To_Celsius |
300 |
149 |
149 | |
|
Convert_Farenheit_To_Celsius |
0 |
-17 |
-17 | |
|
Convert_Farenheit_To_Celsius |
10 |
-12 |
-12 | |
|
Convert_Farenheit_To_Celsius |
-20 |
-29 |
-29 |
很明顯，所有的驗收測試都過了，那么這軟件一定工作，對吧？
試想如果你是這個軟件的商業用戶，或者是一個獨立的第三方測試人員，你愿意讓這個軟件過關嗎？
作為一套測試用例集，以上的列表還比較全面。但作為需求文檔，有許多方面它都沒有覆蓋到：
-
把華氏轉為攝氏的基本邏輯是什么？分數結果怎么處理？應該四舍五入還是用小數表示？
-
該函數的上限及下限是什么？
-
輸入可以是分數么？
-
Null或者數學公式化輸入怎么辦？
為了要給出這些問題的答案，我們需要更多的測試用例。但就算這樣做，還是會有無法回答的問題（比如基本邏輯）。
所以這就是問題根本所在：如果我們要隨機的測試其它輸入，就必須的知道期待正確的輸出是什么 – 而要達到這個目的我們需要一個“先知”。需求文檔可以在多數情況下擔任“先知”的作用。如果沒有這個“先知”，使這套驗收測試通過就可以簡單到專門為這些用例寫一些只針對對它們返回正確值的代碼。
以上是個很簡單的例子?，F實生活中的代碼會與數據庫、文件、以及有諸多變量的對象互動。
在我工作的環境里（我想在你的環境中也一樣），事先制定好的驗收測試用例是很有用的，不過單靠它們是不夠的。所以我們會制定需求然后做探索性的驗收測試。
驗收測試可以成為需求文檔很好的補充。它們可以作為例子形容這個軟件應該做些什么。但例子不能做為解釋，而測試用例并不能取代需求。
