一、什么是測試用例？

測試用例是為某個特殊目標而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序路徑或核實是否滿足某個特定需求。

通俗的講：就是把我們測試系統(tǒng)的操作步驟用按照一定的格式用文字描述出來。

二、寫測試用例有什么好處？

理清思路，避免遺漏

這里是我們認為最重要的一點，假如我們測試的項目大而復(fù)雜，我們可以把項目功能細分，根據(jù)每一個功能通過編寫用例的方式來整理我們測試系統(tǒng)的思路，避免遺漏掉要測試的功能點。

跟蹤測試進展

通過編寫測試用例，執(zhí)行測試用例，我們可以很清楚的知道我們的測試進度。

歷史參考

在我們所做的項目中，也許會有很多功能是相同或相近的，我們對這類功能設(shè)計了測試用例，便于以后我們遇到類似功能的時候可以做參考依據(jù)。

重復(fù)性

我們測試一個系統(tǒng)不是一個人測一遍就算測完的，需要多人反復(fù)的進行測試，那么我們就需要測試用例來規(guī)范和指導(dǎo)我們的測試行為。

告訴領(lǐng)導(dǎo)，這事俺干過，不然別人怎么知道你測沒測，測的全面不全面，拿測試用例給他們看唄！俺就是照著這個干活，呵呵！

三、測試用例的方法

好吧，咱知道啥是測試用例了，也是知道為什么要寫測試用例了，那到底應(yīng)該怎么寫？無從下手埃我們在寫測試用例之前，先學(xué)習(xí)幾種方法，它是我們寫測試用例的指導(dǎo)思想。

1.等價類劃分

在某個輸入域的子集合，在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等價的。假如有一個輸入框要求輸入1-10000個數(shù)，我們不可能用每一個數(shù)去試，我們輸入5和輸入6去驗證和揭露輸入框的錯誤可以看做是等價的。那么這個時候我們就可以隨機的抽取一些數(shù)據(jù)來進行驗證。如：10、99、7777......

等價類分：有效等價類和無效等價類

輸入框要求輸入1-10000的數(shù)

有效等價類：可以輸入1-10000之間的數(shù)來驗證，如：2、5、99、8495......

無效等價類：可以輸入1-10000之外的任意字符驗證，如：20000、字母、下劃線、特殊符號、空格、回車.....

2.邊界值

邊界值是對等價類的補充，測試工作經(jīng)驗告訴我們，大量的錯誤是出在輸入輸出的邊界價上。我們還拿上面的例子，一個輸入框要求輸入1-10000之間的數(shù)。我們要測它有沒有超出這個范圍，如：0、-1、-2、1000、10001.....等等，來判定是否超出了我們的范圍。

3.因果圖

因果圖方法最終生成的就是判定表，它適合于檢查程序輸入條件的各種組合情況。舉個例子：原因：A=0，B=0，結(jié)果我就可以判定：A=B。確切的說他是一種因果關(guān)系思想。它會無形中指導(dǎo)這我們的測試。當然了，我們?yōu)榱艘悦膺z漏，可以把系統(tǒng)中的因果關(guān)系用圖畫出。不過系統(tǒng)大而復(fù)雜的話就是個體力活了。呵呵。

4.錯誤推測法

基于經(jīng)驗和直覺推測出系統(tǒng)可能存在的錯誤，從而有針對性的設(shè)計測試用例的方法。

5.其它

設(shè)計測試用例的方法有很多，我們常用就上面幾種，其它的方法還有：狀態(tài)遷移圖、流程分析法、正交驗證法等等。

四、測試用例的格式與要素

一個測試用例應(yīng)該包括：編號，標題，測試場景，測試步驟，預(yù)期結(jié)果。

當然還可加入一些它選項，如：優(yōu)先級、測試階段....

注：并不是每個方法都一定適合你，我只是讓大家對測試格式有個了解。

關(guān)于測試用例的存放管理：

1.項目管理系統(tǒng)自帶的用例管理，一般用例會與項目掛鉤，有固定的格式，搜索、修改等功能，使用起來非常方便。如：禪道項目管理、QC、bugfree等等都帶的有用例管理功能。

2.通過world\Excel文檔形式管理，這樣的好處就是自己定義測試用例的格式。

一、.我們在什么時候可以設(shè)計測試用例？

當根據(jù)客戶的需求整理出項目需求分析文檔時，我們就可以根據(jù)需求文檔來編寫測試用例了。但是，一般我們（國內(nèi)大多小公司）項目需求文檔都非?！昂喡?，所以，很難根據(jù)需求文檔設(shè)計測試用例。

我們只有等到項目開發(fā)人員把項目開發(fā)出來，給我們系統(tǒng)文檔、部署環(huán)境、數(shù)據(jù)庫結(jié)構(gòu)（如果系統(tǒng)牽涉到數(shù)據(jù)庫的話），我們根絕這些文檔來設(shè)計測試用例。

二、測試用例的評審與更新

我們設(shè)計的測試用例設(shè)計完成之后，是否完整？是否符合系統(tǒng)？符合客戶要求？對用例做一個評審是必不可少。關(guān)于評審的方式，不同的公司有不同的流程。

我們編寫的測試用例也不是經(jīng)過評審之后就不變了，隨著需求的變更、功能的改進，測試用例當然也需要更新和變動。

三、什么情況下不適合寫測試用例

文件時間

如果一個功能我很快就測試完了，而且只需要測試一遍，但我們設(shè)計測試用例時卻比較麻煩，花時間也長。這個時候就沒必要編寫測試用例了。

需求變動大且頻繁

需求的功能變動非常頻繁，而且變動很大，之前編寫的測試用例根本沒法使用，必須要重新編寫，這個時候也沒必要去設(shè)計測試用例了。

項目時間不允許

這一項是不太厚道的做法，如果不是急需交付客戶的話，盡量不要這樣做；當然了，如果只是給客戶展示或試用，可以在之后進行補充和完善測試用例。

不要編寫不完整或別人看不懂的測試用例，那樣就沒有意義了。

四、停止軟件測試的標準。

語句覆蓋最低不能小于80%，測試需求覆蓋率達到100%，測試用例覆蓋率達到100%，一、二級缺陷修復(fù)率達到100%，三、四級修復(fù)率達到80%。

（上面一句是再網(wǎng)上找的，不是標準，只是個參考）

bug等級：

一級：非常嚴重的bug

二級：嚴重的bug

三級：一般性的bug

四級：建議性問題

五、關(guān)于探索性測試

完全的執(zhí)行測試用例時一件非?？菰锏氖虑?，個人在執(zhí)行測試用例時會做一些，其它的非常規(guī)性的操作，看系統(tǒng)是否會有相應(yīng)的處理和提示。我的一部分bug就是再這種非常規(guī)操作下發(fā)現(xiàn)的。

當然了真正的探索性測試需要對產(chǎn)品的深入了解，以及軟件開發(fā)技術(shù)有一定的深度和寬度。姑且把我們的探索性測試看成是瞎搗鼓吧！呵呵。

六、交叉測試

有木有發(fā)現(xiàn)，當我們第一遍測試系統(tǒng)時，會非常認真，但要我們測試第二遍時，我們不愿意像第一次那樣認真的去測了，這不能說明我們不負責(zé)，而是每個人都有的心理現(xiàn)象。這個時候，我們可以和其它測試人員交換功能來測試，提高效率，而且更容易發(fā)現(xiàn)問題。

七、測試的目的

1.我們讓它做的它必須會做。

2.我們不讓它做的它必須不會做。

可能你會發(fā)現(xiàn)有附加功能的時候，就是客戶沒有要求，我們加了這樣的功能，可能加了這點功能系統(tǒng)看上去會更好。這時怎么辦？算問題么？

作為開發(fā)人員，中規(guī)中矩的做東西最好，如果真的有非常好的功能要加的話，需要和客戶溝通，然后寫到需求里。畢竟多一點功能多一點風(fēng)險。呵呵

作為測試人員，凡是不符合需求文檔的都需要當問題點提出。責(zé)任分明，以免后續(xù)麻煩。

請聯(lián)系網(wǎng)站客服，了解詳細的優(yōu)惠課程信息~

優(yōu)質(zhì)、權(quán)威、便捷、省心