發(fā)布時(shí)間:2020-07-16
測試用例是一組條件或變量,測試者根據(jù)它來確定應(yīng)用軟件或軟件系統(tǒng)是否正確工作。確定軟件程序或系統(tǒng)是否通過測試的方法叫做測試準(zhǔn)則。
在編寫測試用例的時(shí)候,我們應(yīng)該知道,所有的測試用例應(yīng)該是易于理解的,一個(gè)不懂應(yīng)用程序的人也是可以執(zhí)行測試步驟。對于要測試的應(yīng)用程序或軟件,基本上我們必須涵蓋不同類型的測試用例,包括正?;虺墒炝鞒?,異?;蜇?fù)流,替代流量和邊界值測試用例。
高質(zhì)量的測試用例標(biāo)準(zhǔn):
1、 覆蓋到所有的業(yè)務(wù)邏輯(包括正常邏輯和異常邏輯);
2、 覆蓋到所有的典型用戶場景;
3、 覆蓋到所有的需求點(diǎn);
4、 測試目標(biāo)明確,并且測試步驟能夠最快的達(dá)到測試目的或者測試時(shí)間很短;
5、 沒有冗余的用例;
6、 測試用例能夠直接附帶測試策略,該模塊的策略指定人和用例執(zhí)行人能夠非常清楚;
如何編寫高質(zhì)量的測試用例?
一、基于邏輯的用例設(shè)計(jì)過程
A、用例編寫過程:
1、優(yōu)先完成業(yè)務(wù)邏輯圖,需要在測試的角度上面去畫邏輯圖,包括數(shù)據(jù)流完整的輸入和輸出過程,并且自己能夠理解為什么這樣處理;
2、根據(jù)自己的理解分析每個(gè)邏輯的處理是否完善,是否有沒有覆蓋到的地方,并提交缺陷預(yù)防bug;
3、根據(jù)邏輯編寫測試用例,保證每個(gè)邏輯都能夠有對應(yīng)的用例覆蓋;
4、編寫邏輯用例的過程中思考如何去改進(jìn)該用例的測試過程,比如:接口測試,自動化測試,腳本。并且,能夠及時(shí)讓研發(fā)提供對應(yīng)的接口和調(diào)試方法;
5、用例要按照10分鐘原則,即保證10分鐘內(nèi)能夠執(zhí)行完成;
B、用例評審過程:
1、先講解整個(gè)業(yè)務(wù)邏輯圖,需要保證評審人員對于整個(gè)業(yè)務(wù)邏輯圖都非常清楚,并且能夠理解為什么這樣做;
2、分析整個(gè)業(yè)務(wù)邏輯圖是否有沒有覆蓋到的場景或者分支情況(采用頭腦風(fēng)暴的方式);
3、分析業(yè)務(wù)邏輯的異常處理情況(是否每個(gè)業(yè)務(wù)邏輯都有對異常情況進(jìn)行處理,也采用頭腦風(fēng)暴的方式);
4、是否將邏輯的用例分類比較合理,讓大家通過邏輯很容易就找到對應(yīng)的用例;
5、分析是否所有的邏輯都能夠找到對應(yīng)的用例(通過邏輯找到對應(yīng)的用例),包括前面沒有考慮到的邏輯;
6、分析用例是否有冗余,是否多個(gè)用例都是覆蓋的同一個(gè)邏輯(包括測試步驟和檢查點(diǎn));
7、分析用例的測試方法是否有改進(jìn),是否能夠直接通過代碼靜態(tài)走讀、接口測試、自動化測試(包括編寫腳本)、引入測試工具等等來進(jìn)一步提高我們的測試效率;
C、友情提醒:
1、僅僅只能保證已有的邏輯沒有問題,但是可能出現(xiàn)部分情況沒有處理導(dǎo)致失效的情況,可以通過后面的場景用例和需求用例來補(bǔ)充覆蓋;
2、邏輯里面異常情況考慮不充分,導(dǎo)致測試用例也相對比較欠缺,可以通過對每個(gè)邏輯進(jìn)行頭腦風(fēng)暴,分析是否有其他異常情況,并且評審時(shí)重點(diǎn)評審這塊;
3、研發(fā)的邏輯有可能本身就是錯(cuò)誤的,但是如果順著研發(fā)的邏輯去編寫用例時(shí)會導(dǎo)致用例也有問題,達(dá)不到測試目的,所以需要從需求和設(shè)計(jì)的角度去提前分析邏輯是否有問題;
4、過程中研發(fā)的邏輯可能變化比較快,這樣會導(dǎo)致邏輯測試用例也要經(jīng)常變化,所以需要保證研發(fā)的編碼是與設(shè)計(jì)一致的,并且邏輯是盡量根據(jù)設(shè)計(jì)來進(jìn)行的;
另外,邏輯用例的設(shè)計(jì)可以在編碼中后期進(jìn)行,這樣的改動會少點(diǎn)。
二、基于場景的用例設(shè)計(jì)過程:
A、用例編寫過程:
1、搞清楚客戶的原始需求,為什么需要這個(gè)功能,能夠給客戶帶來的價(jià)值是什么;
2、查看需求說明書里面的客戶使用的典型用戶場景,并且整合到場景用例里面;
3、在需求說明書的基礎(chǔ)上進(jìn)一步分析客戶還可能有哪些實(shí)際的使用場景(主要是整個(gè)客戶的拓?fù)浣Y(jié)構(gòu));
4、客戶會怎樣去配置該模塊以滿足什么樣的需求(頭腦風(fēng)暴);
5、過程中客戶會有哪些操作(頭腦風(fēng)暴);
B、用例評審過程:
1、安排相關(guān)模塊專家、規(guī)劃經(jīng)理和主管來進(jìn)行評審,主要是分析還可能有哪些場景沒有考慮到,最好是能夠有具體的客戶;
2、安排講解該模塊的場景,保證用例責(zé)任人對模塊場景是非常熟悉的,并且過程中分析是否可能會有其他情況,來進(jìn)一步完善場景用例;
C、友情提醒:
1、模塊用戶場景盡量是有真實(shí)的客戶;
2、模塊用戶場景最好是完整的客戶使用過程,而不是某一個(gè)測試點(diǎn);
3、并不是所有的模塊都有場景用例;
三、基于需求的用例設(shè)計(jì)過程:
A、用例編寫過程:
1、參照需求表,并且對照前面的邏輯用例和場景用例,檢視是否覆蓋到所有需求,沒有的分析下原因,是否邏輯用例or場景用例考慮的還不充分,是的話補(bǔ)充到上面,不是的話則補(bǔ)充到需求用例里面;
2、充分利用相關(guān)的用例編寫技術(shù),包括:邊界值分析法、等價(jià)類分析法、 錯(cuò)誤類推測法、路徑覆蓋法、因果分析法、正交分析法等;
3、分析用例是否能夠通過自動化or其他測試手段來覆蓋到;
B、用例評審過程:
1、對照需求表來進(jìn)行檢視,是否全部覆蓋到,不僅僅是測試用例,還包括測試步驟和期望結(jié)果,避免因?yàn)橐蕾囇邪l(fā)的邏輯來設(shè)計(jì)用例導(dǎo)致問題;
2、評審該部分用例是否跟前面的邏輯用例和場景用例冗余;
3、分析用例是否能夠通過自動化or其他測試手段來覆蓋到;
C、友情提醒:
1、基于需求的用例僅僅是針對前面沒有覆蓋到的用例的補(bǔ)充,所以這部分用例應(yīng)該相對比較少,如果發(fā)現(xiàn)比較多的話可以分析下是否研發(fā)的一些邏輯沒有覆蓋到相關(guān)地方;
四、模塊測試方法說明(提高該模塊的用例執(zhí)行效率):
1、將該模塊的業(yè)務(wù)邏輯圖放到用例的指定目錄,這樣方便給評審人員講解,以及后面相關(guān)人員的學(xué)習(xí);
2、將該模塊的排查和定位問題的方法給出來,并放到指定目錄,能夠有效指導(dǎo)后面人員排查和定位問題;
3、將該模塊的測試思路和測試重點(diǎn)給出來,并放到指定目錄,能夠有效的指導(dǎo)該模塊的測試策略;
推薦閱讀:
怎么進(jìn)行測試用例管理?測試用例管理平臺的功能有哪些?
電話咨詢,400-035-7887,安排專業(yè)技術(shù)售前給您解答(產(chǎn)品試用、技術(shù)交流、服務(wù)咨詢和商務(wù)報(bào)價(jià))。
您的信息已成功提交!
我們的客服人員稍后會與您聯(lián)系