軟件測試中測試用例可以當需求嗎？
測試用例（Test Case）是為某個(gè)特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個(gè)程序路徑或核實(shí)是否滿(mǎn)足某個(gè)特定需求。 測試用例（Test Case）目前沒(méi)有經(jīng)典的定義。比較通常的說(shuō)法是：指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現測試方案、方法、技術(shù)和策略。內容包括測試目標、測試環(huán)境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
“如果我們循序漸進(jìn)地做項目，那么一個(gè)大型軟件項目就成了一系列小的項目。在這些小項目中，如果我們無(wú)法為下面兩周所作的工作制定可供測試的驗收標準，那么我們的麻煩就大了。如果我們可以制定該標準，那么我們?yōu)槭裁床恢苯佑脺y試用例來(lái)表現該標準，反而要用其它方式表現該標準而后又從中衍生測試用例呢？”
Steven Gordon在上文中所推薦的想法超過(guò)了普通的驗收測試自動(dòng)化。事實(shí)上，他建議我們直接把測試用例當作產(chǎn)品需求來(lái)用。換句話(huà)說(shuō)：如果我們在一開(kāi)始就開(kāi)發(fā)了測試用例，用其衡量代碼是否正確 -- 那么需求文檔還拿來(lái)干什么呢？如果測試用例通過(guò)了，代碼就是正確的。如果現有用例不能論證代碼是正確的，那么我們則需要更多的測試。
我得承認，這種邏輯有些誘人。第一，自動(dòng)測試用例是具體、明確、而且顯然可測試的。你（至少現在）不可能寫(xiě)一個(gè)能“適當的處理錯誤”的模棱兩可的自動(dòng)測試。反之，你必須定義發(fā)生錯誤的情況，軟件對其反應，以及怎么去衡量這些錯誤是否正確。同時(shí)，發(fā)現不一致的測試要比發(fā)現不一致的需求容易的多。比如：“這兩個(gè)用例輸入一樣，輸出卻不同，到底哪個(gè)正確？”
但現實(shí)中是什么樣的呢？
試想現在我們有個(gè)項目是設計并創(chuàng )造一個(gè)簡(jiǎn)單的網(wǎng)頁(yè) – 一個(gè)把華氏度轉為攝氏度的在線(xiàn)服務(wù)。我們的商業(yè)用戶(hù)制定了一套驗收測試，而我們把它全部自動(dòng)到只要按一個(gè)按鈕就能運行。在產(chǎn)品初具規模時(shí)，我們運行這個(gè)自動(dòng)測試工具而得出了以下結果：
函數 輸入 期待輸出 實(shí)際輸出 結果
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
很明顯，所有的驗收測試都過(guò)了，那么這軟件一定工作，對吧？
試想如果你是這個(gè)軟件的商業(yè)用戶(hù)，或者是一個(gè)獨立的第三方測試人員，你愿意讓這個(gè)軟件過(guò)關(guān)嗎？
作為一套測試用例集，以上的列表還比較全面。但作為需求文檔，有許多方面它都沒(méi)有覆蓋到：
把華氏轉為攝氏的基本邏輯是什么？分數結果怎么處理？應該四舍五入還是用小數表示？
該函數的上限及下限是什么？
輸入可以是分數么？
Null或者數學(xué)公式化輸入怎么辦？
為了要給出這些問(wèn)題的答案，我們需要更多的測試用例。但就算這樣做，還是會(huì )有無(wú)法回答的問(wèn)題（比如基本邏輯）。
所以這就是問(wèn)題根本所在：如果我們要隨機的測試其它輸入，就必須的知道期待正確的輸出是什么 – 而要達到這個(gè)目的我們需要一個(gè)“先知”。需求文檔可以在多數情況下?lián)巍跋戎钡淖饔�。如果沒(méi)有這個(gè)“先知”，使這套驗收測試通過(guò)就可以簡(jiǎn)單到專(zhuān)門(mén)為這些用例寫(xiě)一些只針對對它們返回正確值的代碼。
以上是個(gè)很簡(jiǎn)單的例子�，F實(shí)生活中的代碼會(huì )與數據庫、文件、以及有諸多變量的對象互動(dòng)。
在我工作的環(huán)境里（我想在你的環(huán)境中也一樣），事先制定好的驗收測試用例是很有用的，不過(guò)單靠它們是不夠的。所以我們會(huì )制定需求然后做探索性的驗收測試。
驗收測試可以成為需求文檔很好的補充。它們可以作為例子形容這個(gè)軟件應該做些什么。但例子不能做為解釋?zhuān)鴾y試用例并不能取代需求。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
