本篇文章重點(diǎn)探討如何才能設(shè)計(jì)出一個(gè)“好的”測試用例。

什么才算是“好的”測試用例？

什么才是“好的”測試用例，這個(gè)“好”又應(yīng)該體現(xiàn)在哪些方面。這是一個(gè)看似簡單實(shí)則難以回答的問題，即使深入思考后，也很難有非常標(biāo)準(zhǔn)的答案。

通常，你的第一反應(yīng)很可能會(huì)是“發(fā)現(xiàn)了軟件缺陷的測試用例就是好的用例”，我可能會(huì)反問你“如果說測試用例發(fā)現(xiàn)了缺陷就是好用例，那么在該缺陷被修復(fù)后，同樣的用例難道就不是好用例了嗎？”。

你可能還會(huì)說“發(fā)現(xiàn)軟件缺陷可能性大的測試用例就是好用例”，這話看起來還是蠻有道理的，但是我同樣會(huì)反問你“你打算用什么方法來量化測試用例發(fā)現(xiàn)缺陷的可能性？”。

類似地，你可能還會(huì)說“發(fā)現(xiàn)至今未被發(fā)現(xiàn)的軟件缺陷的測試用例就是好用例”，那么我想問你的是：如何評估是否還存在未被發(fā)現(xiàn)的缺陷？如果軟件中根本就沒有錯(cuò)誤了呢？

其實(shí)，是你定義“好的”測試用例的思路錯(cuò)了，這就有點(diǎn)像“傻子吃燒餅”，連吃五個(gè)不飽，吃完第六個(gè)終于飽了，于是他說：早知道吃了第六個(gè)就會(huì)飽，何必吃前面五個(gè)呢。細(xì)想，他吃的六個(gè)燒餅其實(shí)是一個(gè)整體，一起吃下去才會(huì)飽，而你無法找到吃一個(gè)就能飽的“好”燒餅。

對于測試用例其實(shí)也是同樣的道理，“好的”測試用例一定是一個(gè)完備的集合，它能夠覆蓋所有等價(jià)類以及各種邊界值，而跟能否發(fā)現(xiàn)缺陷無關(guān)。

我舉一個(gè)“池塘捕魚”的例子，可以幫你更好地理解什么是“好的”測試用例。

如果把被測試軟件看作一個(gè)池塘，軟件缺陷是池塘中的魚，建立測試用例集的過程就像是在編織一張捕漁網(wǎng)?！昂玫摹睖y試用例集就是一張能夠覆蓋整個(gè)池塘的大漁網(wǎng)，只要池塘里有魚，這個(gè)大漁網(wǎng)就一定能把魚給撈上來。

如果漁網(wǎng)本身是完整的且合格的，那么撈不到魚，就證明池塘中沒有魚，而漁網(wǎng)的好壞與池塘中是否有魚無關(guān)。

“好的”測試用例必須具備哪些特征？

一個(gè)“好的”測試用例，必須具備以下三個(gè)特征。

1. 整體完備性：?“好的”測試用例一定是一個(gè)完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。
2. 等價(jià)類劃分的準(zhǔn)確性：?指的是對于每個(gè)等價(jià)類都能保證只要其中一個(gè)輸入測試通過，其他輸入也一定測試通過。
3. 等價(jià)類集合的完備性：?需要保證所有可能的邊界值和邊界條件都已經(jīng)正確識別。

做到了以上三點(diǎn)，就可以肯定測試是充分且完備的，即做到了完整的測試需求覆蓋。

三種最常用的測試用例設(shè)計(jì)方法

明白了“好的”測試用例的內(nèi)涵和外延后，我再回過頭來給你講講，為了能夠設(shè)計(jì)出“好的”測試用例，你通常都要使用哪些設(shè)計(jì)方法。

從理論層面來講，設(shè)計(jì)用例的方法有很多，如果你去翻閱測試圖書或網(wǎng)絡(luò)教程，會(huì)發(fā)現(xiàn)一堆讓人眼花繚亂的測試方法，比如等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測方法、因果圖方法、判定表驅(qū)動(dòng)分析法、正交實(shí)驗(yàn)設(shè)計(jì)方法、功能圖分析方法、場景設(shè)計(jì)方法、形式化方法、擴(kuò)展有限狀態(tài)機(jī)方法等等，但是從軟件企業(yè)實(shí)際的工程實(shí)踐來講，真正具有實(shí)用價(jià)值并且常用的只有前三種方法。

當(dāng)然，對于那些與人的生命安全直接或間接相關(guān)的軟件，比如飛行控制、軌道交通的列車控制、醫(yī)療檢測相關(guān)的軟件或者系統(tǒng)，由于需要達(dá)到幾近變態(tài)的測試覆蓋率要求，會(huì)采用更多的測試設(shè)計(jì)方法。但對大多數(shù)的軟件測試而言，綜合使用等價(jià)類劃分、邊界值分析和錯(cuò)誤推測這三大類方法就足夠了。

接下來，結(jié)合實(shí)際的例子，解釋一下這三類方法的核心概念以及在使用時(shí)需要注意的問題。

第一，等價(jià)類劃分方法

從上一篇文章中你已經(jīng)知道了，等價(jià)類中任意一個(gè)輸入數(shù)據(jù)對于揭露程序中潛在錯(cuò)誤都具有同等效果。后續(xù)我們只要從每個(gè)等價(jià)類中任意選取一個(gè)值進(jìn)行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結(jié)果。

現(xiàn)在，我給你看一個(gè)具體的例子：學(xué)生信息系統(tǒng)中有一個(gè)“考試成績”的輸入項(xiàng)，成績的取值范圍是0~100之間的整數(shù)，考試成績及格的分?jǐn)?shù)線是60。

為了測試這個(gè)輸入項(xiàng)，顯然不可能用0~100的每一個(gè)數(shù)去測試。通過需求描述可以知道，輸入0~59之間的任意整數(shù)，以及輸入60~100之間的任意整數(shù)，去驗(yàn)證和揭露輸入框的潛在缺陷可以看做是等價(jià)的。

那么這就可以在0~59和60~100之間各隨機(jī)抽取一個(gè)整數(shù)來進(jìn)行驗(yàn)證。這樣的設(shè)計(jì)就構(gòu)成了所謂的“有效等價(jià)類”。

你不要覺得進(jìn)行到這里，已經(jīng)完成了等價(jià)類劃分的工作，因?yàn)?strong>等價(jià)類劃分方法的另一個(gè)關(guān)鍵點(diǎn)是要找出所有“無效等價(jià)類”。顯然，如果輸入的成績是負(fù)數(shù)，或者是大于100的數(shù)等都構(gòu)成了“無效等價(jià)類”。

在考慮了無效等價(jià)類后，最終設(shè)計(jì)的測試用例為：

• 有效等價(jià)類1：0~59之間的任意整數(shù)；
• 有效等價(jià)類2：59~100之間的任意整數(shù)；
• 無效等價(jià)類1：小于0的負(fù)數(shù)；
• 無效等價(jià)類2：大于100的整數(shù)；
• 無效等價(jià)類3：0~100之間的任何浮點(diǎn)數(shù)；
• 無效等價(jià)類4：其他任意非數(shù)字字符。

第二，邊界值分析方法

邊界值分析是對等價(jià)類劃分的補(bǔ)充，你從工程實(shí)踐經(jīng)驗(yàn)中可以發(fā)現(xiàn)，大量的錯(cuò)誤發(fā)生在輸入輸出的邊界值上，所以需要對邊界值進(jìn)行重點(diǎn)測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)。

我們繼續(xù)看學(xué)生信息系統(tǒng)中“考試成績”的例子，選取的邊界值數(shù)據(jù)應(yīng)該包括：-1，0，1，59，60，61，99，100，101。

第三，錯(cuò)誤推測方法

錯(cuò)誤推測方法是指基于對被測試軟件系統(tǒng)設(shè)計(jì)的理解、過往經(jīng)驗(yàn)以及個(gè)人直覺，推測出軟件可能存在的缺陷，從而有針對性地設(shè)計(jì)測試用例的方法。這個(gè)方法強(qiáng)調(diào)的是對被測試軟件的需求理解以及設(shè)計(jì)實(shí)現(xiàn)的細(xì)節(jié)把握，當(dāng)然還有個(gè)人的能力。

錯(cuò)誤推測法和目前非常流行的“探索式測試方法”的基本思想和理念是不謀而合的，這類方法在目前的敏捷開發(fā)模式下的投入產(chǎn)出比很高，因此被廣泛應(yīng)用。但是，這個(gè)方法的缺點(diǎn)也顯而易見，那就是難以系統(tǒng)化，并且過度依賴個(gè)人能力。

比如，Web界面的GUI功能測試，需要考慮瀏覽器在有緩存和沒有緩存下的表現(xiàn)；Web Service的API測試，需要考慮被測API所依賴的第三方API出錯(cuò)下的處理邏輯；對于代碼級的單元測試，需要考慮被測函數(shù)的輸入?yún)?shù)為空情況下的內(nèi)部處理邏輯等等。由此可見，這些測試用例的設(shè)計(jì)都是基于曾經(jīng)遇到的問題而進(jìn)行的錯(cuò)誤推測，很大程度上取決于個(gè)人能力。

在軟件企業(yè)的具體實(shí)踐中，為了降低對個(gè)人能力的依賴，通常會(huì)建立常見缺陷知識庫，在測試設(shè)計(jì)的過程中，會(huì)使用缺陷知識庫作為檢查點(diǎn)列表（checklist），去幫助優(yōu)化補(bǔ)充測試用例的設(shè)計(jì)。

對于中小企業(yè)，可能最初的方法就是建立一個(gè)簡單的wiki頁面，讓測試工程師完成測試用例的最初設(shè)計(jì)后對應(yīng)這個(gè)wiki頁面先做一輪自檢，如果在后續(xù)測試中發(fā)現(xiàn)了新的點(diǎn)，就會(huì)繼續(xù)完善這個(gè)wiki頁面。

對于測試基礎(chǔ)架構(gòu)比較成熟的中大型軟件企業(yè)，通常會(huì)以該缺陷知識庫作為數(shù)據(jù)驅(qū)動(dòng)測試的輸入來自動(dòng)生成部分的測試數(shù)據(jù)，這部分內(nèi)容我會(huì)在后面的文章中詳細(xì)介紹。

如何才能設(shè)計(jì)出“好的”測試用例？

掌握了最基本的三種設(shè)計(jì)測試用例的方法，你就相當(dāng)于拿到了打仗所需要的槍支彈藥，接下來就是如何在實(shí)戰(zhàn)中用這些武器打個(gè)大勝仗了。

在真實(shí)的工程實(shí)踐中，不同的軟件項(xiàng)目在研發(fā)生命周期的各個(gè)階段都會(huì)有不同的測試類型。?比如，傳統(tǒng)軟件的開發(fā)階段通常會(huì)有單元測試，軟件模塊集成階段會(huì)有代碼級集成測試，打包部署后會(huì)有面向終端用戶的GUI測試；再比如，電商網(wǎng)站的測試會(huì)分為服務(wù)器端基于API的測試、中間件測試、前端GUI測試等。

對于每一種不同的測試類型，設(shè)計(jì)出“好的”測試用例的關(guān)注點(diǎn)和方法論可能會(huì)有很大的差異，?有些可能采用黑盒方法，有些可能采用白盒方法，有些還會(huì)采用灰盒方法（比如，微服務(wù)架構(gòu)中的測試），所以很難有一套放之四海而皆準(zhǔn)的套路。

以最常見、最容易理解的面向終端用戶的GUI測試為例，探討如何才能設(shè)計(jì)一個(gè)“好的”測試用例。

面向終端用戶的GUI測試，最核心的測試點(diǎn)就是驗(yàn)證軟件對需求的滿足程度，這就要求測試工程師對被測軟件的需求有深入的理解。在我看來，深入理解被測軟件需求的最好方法是，測試工程師在需求分析和設(shè)計(jì)階段就開始介入，因?yàn)檫@個(gè)階段是理解和掌握軟件的原始業(yè)務(wù)需求的最好時(shí)機(jī)。

只有真正理解了原始業(yè)務(wù)需求之后，才有可能從業(yè)務(wù)需求的角度去設(shè)計(jì)針對性明確、從終端用戶使用場景考慮的端到端（End-2-End）的測試用例集。這個(gè)階段的測試用例設(shè)計(jì)，主要目的是驗(yàn)證各個(gè)業(yè)務(wù)需求是否被滿足，主要采用基于黑盒的測試設(shè)計(jì)方法。

在具體的用例設(shè)計(jì)時(shí)，首先需要搞清楚每一個(gè)業(yè)務(wù)需求所對應(yīng)的多個(gè)軟件功能需求點(diǎn)，然后分析出每個(gè)軟件功能需求點(diǎn)對應(yīng)的多個(gè)測試需求點(diǎn)，最后再針對每個(gè)測試需求點(diǎn)設(shè)計(jì)測試用例。

這個(gè)用例設(shè)計(jì)過程，你可能覺得有點(diǎn)繞，但是沒關(guān)系，我以“用戶登錄”功能的測試用例設(shè)計(jì)為例，畫了一張圖來幫你理清這些概念之間的映射關(guān)系。

圖中的業(yè)務(wù)需求到軟件功能需求、軟件功能需求到測試需求，以及測試需求到測試用例的映射關(guān)系，在非互聯(lián)網(wǎng)軟件企業(yè)的實(shí)踐中，通常會(huì)使用需求追蹤管理工具（比如ALM、DOORS、JIRA、TestLink等）來管理，并以此來衡量測試用例對業(yè)務(wù)需求、軟件功能需求的覆蓋率。

具體到測試用例本身的設(shè)計(jì)，有兩個(gè)關(guān)鍵點(diǎn)需要你注意。

• 從軟件功能需求出發(fā)，全面地、無遺漏地識別出測試需求是至關(guān)重要的，這將直接關(guān)系到用例的測試覆蓋率。?比如，如果你沒有識別出用戶登錄功能的安全性測試需求，那么后續(xù)設(shè)計(jì)的測試用例就完全不會(huì)涉及安全性，最終造成重要測試漏洞。
• 對于識別出的每個(gè)測試需求點(diǎn)，需要綜合運(yùn)用等價(jià)類劃分、邊界值分析和錯(cuò)誤推測方法來全面地設(shè)計(jì)測試用例。?這里需要注意的是，要綜合運(yùn)用這三種方法，并針對每個(gè)測試需求點(diǎn)的具體情況，進(jìn)行靈活選擇。- 以“用戶登錄”的功能性測試需求為例，你首先應(yīng)該對“用戶名”和“密碼”這兩個(gè)輸入項(xiàng)分別進(jìn)行等價(jià)類劃分，列出對應(yīng)的有效等價(jià)類和無效等價(jià)類，對于無效等價(jià)類的識別可以采用錯(cuò)誤猜測法（比如，用戶名包含特殊字符等），然后基于兩者可能的組合，設(shè)計(jì)出第一批測試用例。- 等價(jià)類劃分完后，你需要補(bǔ)充“用戶名”和“密碼”這兩個(gè)輸入項(xiàng)的邊界值的測試用例，比如用戶名為空（NULL）、用戶名長度剛剛大于允許長度等。

用例設(shè)計(jì)的其他經(jīng)驗(yàn)

除了上面介紹的方法外，我再跟你分享三個(gè)獨(dú)家“秘籍”，希望能夠幫你設(shè)計(jì)出“好的”測試用例集。

• • 只有深入理解被測試軟件的架構(gòu)，你才能設(shè)計(jì)出“有的放矢”的測試用例集，去發(fā)現(xiàn)系統(tǒng)邊界以及系統(tǒng)集成上的潛在缺陷。- 作為測試工程師，切忌不能把整個(gè)被測系統(tǒng)看作一個(gè)大黑盒，你必須對內(nèi)部的架構(gòu)有清楚的認(rèn)識，比如數(shù)據(jù)庫連接方式、數(shù)據(jù)庫的讀寫分離、消息中間件Kafka的配置、緩存系統(tǒng)的層級分布、第三方系統(tǒng)的集成等等。
  • 必須深入理解被測軟件的設(shè)計(jì)與實(shí)現(xiàn)細(xì)節(jié)，深入理解軟件內(nèi)部的處理邏輯。- 單單根據(jù)測試需求點(diǎn)設(shè)計(jì)的用例，只能覆蓋“表面”的一層，往往會(huì)覆蓋不到內(nèi)部的處理流程、分支處理，而沒有覆蓋到的部分就很可能出現(xiàn)缺陷遺漏。在具體實(shí)踐中，你可以通過代碼覆蓋率指標(biāo)找出可能的測試遺漏點(diǎn)。- 同時(shí)，切忌不要以開發(fā)代碼的實(shí)現(xiàn)為依據(jù)設(shè)計(jì)測試用例。因?yàn)殚_發(fā)代碼實(shí)現(xiàn)的錯(cuò)誤會(huì)導(dǎo)致測試用例也出錯(cuò)，所以你應(yīng)該根據(jù)原始需求設(shè)計(jì)測試用例。
  • 需要引入需求覆蓋率和代碼覆蓋率來衡量測試執(zhí)行的完備性，并以此為依據(jù)來找出遺漏的測試點(diǎn)。?關(guān)于什么是需求覆蓋率和代碼覆蓋率，我會(huì)在后續(xù)的文章中詳細(xì)介紹。

總結(jié)

? ? ?最后，總結(jié)一下這篇文章的主要內(nèi)容。文章來源地址http://www.zghlxwxcb.cn/news/detail-808107.html

• 首先，“好的”測試用例一定是一個(gè)完備的集合，它能夠覆蓋所有等價(jià)類以及各種邊界值，而能否發(fā)現(xiàn)軟件缺陷并不是衡量測試用例好壞的標(biāo)準(zhǔn)。
• 其次，設(shè)計(jì)測試用例的方法有很多種，但綜合運(yùn)用等價(jià)類劃分、邊界值分析和錯(cuò)誤推測方法，可以滿足絕大多數(shù)軟件測試用例設(shè)計(jì)的需求。
• 再次，“好的”測試用例在設(shè)計(jì)時(shí)，需要從軟件功能需求出發(fā)，全面地、無遺漏地識別出測試需求至關(guān)重要。
• 最后，如果想設(shè)計(jì)一個(gè)“好的”測試用例，你必須要深入理解被測軟件的架構(gòu)設(shè)計(jì)，深入軟件內(nèi)部的處理邏輯，需求覆蓋率和代碼覆蓋率這兩個(gè)指標(biāo)可以幫你衡量測試執(zhí)行的完備性。

到了這里，關(guān)于【軟件測試】學(xué)習(xí)筆記-設(shè)計(jì)一個(gè)“好的”測試用例的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！