軟件測試中編寫(xiě)測試需求及測試用例
測試用例的模版其實(shí)沒(méi)有太多的差異，而在我剛開(kāi)始接觸測試時(shí)總想找一個(gè)好的測試用例模版。通常來(lái)說(shuō)，測試用例模版包括最主要的三項：操作說(shuō)明，預期結果和否通過(guò)。有了這三項，其它的就根據你的需要來(lái)添枝加葉了，我blog上面有一個(gè)我現在用的測試需求及用例模版，可參考一下。
問(wèn)題是如何填滿(mǎn)這個(gè)模版，即如何編寫(xiě)測試需求和用例。有的人把測試需求和測試用例分開(kāi)來(lái)編寫(xiě)的。測試需求作為一個(gè)文檔，測試用例作為另一個(gè)文檔，在我開(kāi)始寫(xiě)測試用例之初，一直有這樣一個(gè)疑問(wèn)：測試需求和測試用例只寫(xiě)一個(gè)不就可以了嗎？的確，測試需求和測試用例本身沒(méi)有太明顯的界限，測試需求寫(xiě)得細的話(huà)和測試用例就沒(méi)有太多的差別了。根據詳細的測試需求是可以執行測試的，這一點(diǎn)我不懷疑。其實(shí)我一直持有一種觀(guān)點(diǎn)，如果時(shí)間不夠的話(huà)，可以只寫(xiě)測試需求，因為畢竟現在測試基本上都是由測試員本人執行自己的測試需求和測試用例，如果測試需求將功能點(diǎn)都列出來(lái)了，操作過(guò)程自己都知道。不過(guò)，我現在還是將測試需求和測試用例寫(xiě)在一起的，時(shí)間也好像還比較充足。
下面舉一個(gè)簡(jiǎn)單的測試需求和測試用例的例子：
| 測試需求： | 在編輯框中只能輸入1～4中的任意一個(gè)數字 |
| 測試用例： | 1.考慮輸入非數字的情況 |
| (不是完整 | 2.考慮不輸入的情況 |
| 的測試用例格式) | 3.考慮輸入的不是1～4中的情況 |
| 4.................. |
以上是一個(gè)測試需求和測試用例的對比，可以看出上面的測試用例比測試需求描述的要詳細的多，一般來(lái)說(shuō)我是按上面的方式來(lái)寫(xiě)的，測試需求只說(shuō)明一個(gè)整體要求，測試用例則考慮多種情況。
至于測試需求和測試用例的編寫(xiě)，還一個(gè)容易疑惑的問(wèn)題：粒度。簡(jiǎn)單的說(shuō)就是細化到何種程度。 寫(xiě)的粒度太大，不利于寫(xiě)清楚測試對象及操作過(guò)程。如果是自己執行測試自己寫(xiě)的測試用例還好一點(diǎn)，知道你自己寫(xiě)的是什么，在什么前置條件下可以執行這個(gè)測試用例，如果是別人執行你寫(xiě)的測試用例，特別是對系統還不熟的人，就難說(shuō)不碰到麻煩了，可能是找不到操作說(shuō)明中的第一步在什么地方操作，也有可能是對測試結果產(chǎn)生疑惑，這個(gè)結果是和測試用例上面寫(xiě)的測試結果是一樣的嗎？我想這樣的測試用例不能算好的測試用例。 寫(xiě)的粒度太小，自己都會(huì )受不了，你會(huì )埋怨要寫(xiě)的東西實(shí)在是太多了，更重要的是，寫(xiě)測試用例的時(shí)間用的越多，你可以用來(lái)執行測試用例的時(shí)間就越少，這點(diǎn)我有過(guò)類(lèi)似的經(jīng)歷。 粒度的權衡，是個(gè)麻煩的事情，不過(guò)對于剛開(kāi)始寫(xiě)測試用例的人來(lái)說(shuō)，建議開(kāi)始還是寫(xiě)細一點(diǎn)，寫(xiě)的多了，也會(huì )慢慢的體會(huì )到哪些地方可以偷偷懶了，呵呵。
測試用例的覆蓋，這是個(gè)比較大的問(wèn)題，我在這里只是初略的提一下，很多書(shū)中都有介紹，我才學(xué)了點(diǎn)皮毛。最簡(jiǎn)單的，測試用例，第一必須保證包含了你所要測試對象的所有功能點(diǎn)；第二，必須有至少有正反兩個(gè)測試項。另外還一個(gè)等價(jià)劃分，這個(gè)方法我想，這是最基本的要求了，但是也是用的最多的，最重要的。其它的某某方法，也可以學(xué)習學(xué)習，必要的時(shí)候說(shuō)不定用的上，比如要測試的對象關(guān)系特復雜的時(shí)候，因果圖的方法就可以試試了。老實(shí)說(shuō)，那些方法我一個(gè)也沒(méi)用過(guò)，因為基本上用不上，用它們簡(jiǎn)直是浪費腦力，呵呵。
測試用例的跌代，一個(gè)不可避免的過(guò)程。我到現在也寫(xiě)了一兩篇測試用例文檔了，沒(méi)有一次是一次就搞定的。一個(gè)是因為剛開(kāi)始對需求及詳細設計文檔理解的不深，疏忽了一些比較隱蔽但重要的測試點(diǎn)，第二則是在編寫(xiě)測試用例期間軟件需求有可能出現一些小的變化。記得有一次我寫(xiě)完一遍測試用例的時(shí)候，自認為快寫(xiě)完了，很高興，發(fā)現才二十幾頁(yè)，然而到最終我真的覺(jué)得可以完工的時(shí)候，文檔頁(yè)數翻了一倍，五十幾頁(yè)，我還真是頭一次寫(xiě)這么多的字。
最后一個(gè)，持懷疑態(tài)度。理論上說(shuō)，測試應該從需求開(kāi)始抓起，參與需求的評審，對詳細設計也要測試，但目前我們并沒(méi)有做這么多，或者說(shuō)做得不完全。根據現狀，有時(shí)候我只能依靠詳細設計來(lái)寫(xiě)測試用例，所以先必須假設詳細設計上面寫(xiě)的是對的。然后我們開(kāi)始理解詳細設計，持懷疑態(tài)度的看，在我們對詳細設計有了一定的理解之后（剛開(kāi)始最好不要懷疑）。這時(shí)候會(huì )有幾種情況，一種，看的不是很明白；第二種，好像有遺漏的地方；第三種，好像錯了（僅僅指寫(xiě)錯了字，因為我們還沒(méi)有需求規格可以參考）。要繼續寫(xiě)測試用例必須處理這三個(gè)問(wèn)題，對第一種，沒(méi)辦法，請教寫(xiě)這個(gè)文檔的程序員；對第二種，還是請教寫(xiě)這個(gè)文檔的程序員；對第三種，告訴他這里錯了。當然你也可以選擇另一種途徑，暫時(shí)跳過(guò)，不過(guò)遲早還是要解決的。在沒(méi)有需求文檔的條件下，有一定的風(fēng)險，不知道詳細設計是否和需求是否一致，在需求文檔沒(méi)有出來(lái)之前，對自己懷疑的地方問(wèn)一下需求人員，在需求文檔出來(lái)之后，和詳細設計文檔對照一下，一般詳細設計文檔都不會(huì )錯到哪去，呵呵。
好像就這些吧，自己慢慢體會(huì )也就出來(lái)了，但是一定要先硬著(zhù)頭皮寫(xiě)用例，寫(xiě)著(zhù)寫(xiě)著(zhù)就好了。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
