編寫測試需求及測試用例

　　測試用例的模版其實沒有太多的差異，而在我剛開始接觸測試時總想找一個好的測試用例模版。通常來說，測試用例模版包括最主要的三項：操作說明，預期結果和否通過。有了這三項，其它的就根據你的需要來添枝加葉了，我blog上面有一個我現在用的測試需求及用例模版，可參考一下。

　　問題是如何填滿這個模版，即如何編寫測試需求和用例。有的人把測試需求和測試用例分開來編寫的。測試需求作為一個文檔，測試用例作為另一個文檔，在我開始寫測試用例之初，一直有這樣一個疑問：測試需求和測試用例只寫一個不就可以了嗎?的確，測試需求和測試用例本身沒有太明顯的界限，測試需求寫得細的話和測試用例就沒有太多的差別了。根據詳細的測試需求是可以執行測試的，這一點我不懷疑。其實我一直持有一種觀點，如果時間不夠的話，可以只寫測試需求，因為畢竟現在測試基本上都是由測試員本人執行自己的測試需求和測試用例，如果測試需求將功能點都列出來了，操作過程自己都知道。不過，我現在還是將測試需求和測試用例寫在一起的，時間也好像還比較充足。

　　下面舉一個簡單的測試需求和測試用例的例子：

　　測試需求：在編輯框中只能輸入1～4中的任意一個數字

　　測試用例：1.考慮輸入非數字的情況

　　(不是完整2.考慮不輸入的情況

　　的測試用例格式)3.考慮輸入的不是1～4中的情況

　　4..................

　　以上是一個測試需求和測試用例的對比，可以看出上面的測試用例比測試需求描述的要詳細的多，一般來說我是按上面的方式來寫的，測試需求只說明一個整體要求，測試用例則考慮多種情況。

　　至于測試需求和測試用例的編寫，還一個容易疑惑的問題：粒度。簡單的說就是細化到何種程度。 寫的粒度太大，不利于寫清楚測試對象及操作過程。如果是自己執行測試自己寫的測試用例還好一點，知道你自己寫的是什么，在什么前置條件下可以執行這個測試用例，如果是別人執行你寫的測試用例，特別是對系統還不熟的人，就難說不碰到麻煩了，可能是找不到操作說明中的第一步在什么地方操作，也有可能是對測試結果產生疑惑，這個結果是和測試用例上面寫的測試結果是一樣的嗎?我想這樣的測試用例不能算好的測試用例。 寫的粒度太小，自己都會受不了，你會埋怨要寫的東西實在是太多了，更重要的是，寫測試用例的時間用的越多，你可以用來執行測試用例的時間就越少，這點我有過類似的經歷。 粒度的權衡，是個麻煩的事情，不過對于剛開始寫測試用例的人來說，建議開始還是寫細一點，寫的多了，也會慢慢的體會到哪些地方可以偷偷懶了，呵呵。

　　測試用例的覆蓋，這是個比較大的問題，我在這里只是初略的提一下，很多書中都有介紹，我才學了點皮毛。最簡單的，測試用例，第一必須保證包含了你所要測試對象的所有功能點;第二，必須有至少有正反兩個測試項。另外還一個等價劃分，這個方法我想，這是最基本的要求了，但是也是用的最多的，最重要的。其它的某某方法，也可以學習學習，必要的時候說不定用的上，比如要測試的對象關系特復雜的時候，因果圖的方法就可以試試了。老實說，那些方法我一個也沒用過，因為基本上用不上，用它們簡直是浪費腦力，呵呵。

　　測試用例的跌代，一個不可避免的過程。我到現在也寫了一兩篇測試用例文檔了，沒有一次是一次就搞定的。一個是因為剛開始對需求及詳細設計文檔理解的不深，疏忽了一些比較隱蔽但重要的測試點，第二則是在編寫測試用例期間軟件需求有可能出現一些小的變化。記得有一次我寫完一遍測試用例的時候，自認為快寫完了，很高興，發現才二十幾頁，然而到最終我真的覺得可以完工的時候，文檔頁數翻了一倍，五十幾頁，我還真是頭一次寫這么多的字。

　　最后一個，持懷疑態度。理論上說，測試應該從需求開始抓起，參與需求的評審，對詳細設計也要測試，但目前我們并沒有做這么多，或者說做得不完全。根據現狀，有時候我只能依靠詳細設計來寫測試用例，所以先必須假設詳細設計上面寫的是對的。然后我們開始理解詳細設計，持懷疑態度的看，在我們對詳細設計有了一定的理解之后(剛開始最好不要懷疑)。這時候會有幾種情況，一種，看的不是很明白;第二種，好像有遺漏的地方;第三種，好像錯了(僅僅指寫錯了字，因為我們還沒有需求規格可以參考)。要繼續寫測試用例必須處理這三個問題，對第一種，沒辦法，請教寫這個文檔的程序員;對第二種，還是請教寫這個文檔的程序員;對第三種，告訴他這里錯了。當然你也可以選擇另一種途徑，暫時跳過，不過遲早還是要解決的。在沒有需求文檔的條件下，有一定的風險，不知道詳細設計是否和需求是否一致，在需求文檔沒有出來之前，對自己懷疑的地方問一下需求人員，在需求文檔出來之后，和詳細設計文檔對照一下，一般詳細設計文檔都不會錯到哪去，呵呵。

原文轉自：http://www.uml.org.cn/Test/200907272.asp