書名: 全棧自動(dòng)化測(cè)試實(shí)戰(zhàn):基于TestNG、HttpClient、Selenium和Appium作者名: 盧家濤本章字?jǐn)?shù): 1671字更新時(shí)間: 2020-06-08 17:55:44
1.2 自動(dòng)化測(cè)試的目的
1.2.1 提高軟件質(zhì)量
既然談到軟件質(zhì)量,那么就有必要了解一下軟件質(zhì)量的度量標(biāo)準(zhǔn)。
1.需求覆蓋率
需求覆蓋率更多的是從產(chǎn)品經(jīng)理的角度出發(fā),統(tǒng)計(jì)產(chǎn)品需求文檔中的需求被覆蓋了多少,從而計(jì)算出需求覆蓋率:
需求覆蓋率=測(cè)試覆蓋的需求數(shù)/需求總數(shù)×100%
2.代碼覆蓋率
開發(fā)人員可能更關(guān)心代碼覆蓋率。代碼覆蓋方式有很多種,下面舉例說明。
有一個(gè)名為demo的Java方法如下:

(1)語句覆蓋
語句覆蓋的原則是覆蓋每條語句,針對(duì)demo方法,一條測(cè)試用例即可完成覆蓋:
Case 1:a=true,b=true,c=true,d=false
(2)分支(判定)覆蓋
語句覆蓋并沒有考慮if語句為假(false)的情況,顯然測(cè)試并不充分。分支(判定)覆蓋可以解決這個(gè)問題。采用分支(判定)覆蓋重寫的測(cè)試用例如下:

(3)條件覆蓋
分支(判定)覆蓋看似比語句覆蓋更加完美,但分支(判定)覆蓋并沒有考慮每個(gè)條件的每個(gè)取值(即a、b、c、d均可以取true或false兩個(gè)值)。條件覆蓋能覆蓋到每個(gè)條件的每個(gè)取值,采用條件覆蓋重寫的測(cè)試用例如下:

(4)分支(判定)—條件覆蓋
如果能同時(shí)滿足分支(判定)覆蓋和條件覆蓋就更好了,而分支(判定)—條件覆蓋就能做到,采用分支(判定)—條件覆蓋重寫的測(cè)試用例如下:

(5)條件組合覆蓋
條件組合覆蓋考慮的是覆蓋每個(gè)分支(判定)中每個(gè)條件的每種組合,采用條件覆蓋重寫的測(cè)試用例如下:

下面對(duì)這4條測(cè)試用例進(jìn)行詳細(xì)解釋:
若a&&b為true,那么a=true,b=true。
若a&&b為false,那么a=true,b=false;或a=false,b=true;或a=false,b=false。
若c&&d為true,那么c=true,d=true;或c=true,d=false;或c=false,d=true。
若c&&d為false,那么c=false,d=false。
(6)路徑覆蓋
路徑覆蓋的原則是覆蓋所有路徑,針對(duì)demo方法,共包含4條路徑:
a&&b為true,同時(shí)c&&d為true。
a&&b為true,同時(shí)c&&d為false。
a&&b為false,同時(shí)c&&d為true。
a&&b為false,同時(shí)c&&d為false。
對(duì)應(yīng)測(cè)試用例如下:

如何計(jì)算代碼覆蓋率呢?以路徑覆蓋為例,假如執(zhí)行了Case 1,那么路徑覆蓋率為25%(即1/4×100%)。
關(guān)于代碼覆蓋的更多內(nèi)容,參見本書第12章。
3.缺陷遺漏率
在軟件質(zhì)量的度量標(biāo)準(zhǔn)中,關(guān)于缺陷的不在少數(shù),比如缺陷遺漏率、缺陷修復(fù)率、缺陷遺留率和嚴(yán)重缺陷率等。筆者見得最多的是缺陷遺漏率,正所謂“玉瓷之石,金剛試之”,軟件質(zhì)量好不好,用戶說了算。當(dāng)缺陷太多時(shí),說明軟件質(zhì)量仍有很大的提升空間。
缺陷遺漏率=線上缺陷數(shù)/缺陷總數(shù)×100%
缺陷遺漏率不僅是軟件質(zhì)量的度量標(biāo)準(zhǔn),也是測(cè)試人員考核的硬指標(biāo)之一。
從軟件質(zhì)量的度量標(biāo)準(zhǔn)中無法看出自動(dòng)化測(cè)試是如何提高質(zhì)量的,下面舉例說明。
假設(shè)某軟件頻繁地進(jìn)行回歸測(cè)試,測(cè)試人員已經(jīng)身心疲憊,難以保證每次回歸測(cè)試的質(zhì)量,這時(shí)如果使用自動(dòng)化測(cè)試代替測(cè)試人員進(jìn)行回歸測(cè)試,那么回歸測(cè)試的質(zhì)量就能得到很好的保證(機(jī)器是不知疲倦的),從而減少線上缺陷數(shù),降低缺陷遺漏率。
1.2.2 提高測(cè)試效率
可能很多人認(rèn)為:手工測(cè)試執(zhí)行的用例由自動(dòng)化測(cè)試代替,測(cè)試效率的提高顯而易見。
但事實(shí)上不能如此片面地下結(jié)論,原因如下。
(1)自動(dòng)化測(cè)試用例的編寫和維護(hù)效率遠(yuǎn)低于手工測(cè)試用例
自動(dòng)化測(cè)試用例一天只有幾條的產(chǎn)出,而手工測(cè)試用例一天可以寫幾十條,甚至上百條。對(duì)于迭代頻繁的產(chǎn)品,維護(hù)自動(dòng)化測(cè)試用例將是測(cè)試人員的“噩夢(mèng)”。
(2)自動(dòng)化測(cè)試用例執(zhí)行失敗后需要人工分析
自動(dòng)化測(cè)試用例雖然可以做斷言,但執(zhí)行結(jié)果仍然需要由測(cè)試人員進(jìn)行人工分析,判斷是自動(dòng)化測(cè)試用例本身的問題還是真正的缺陷。
(3)自動(dòng)化測(cè)試無法處理未知的場(chǎng)景
假設(shè)測(cè)試人員誤刪除了自動(dòng)化測(cè)試用例在測(cè)試環(huán)境中創(chuàng)建的一條數(shù)據(jù),那么這條自動(dòng)化測(cè)試用例就會(huì)執(zhí)行失敗,從而增加人工分析的時(shí)間。而手工測(cè)試則不同,如果發(fā)現(xiàn)創(chuàng)建的數(shù)據(jù)被刪除了,那么再創(chuàng)建一條即可。
從以上幾點(diǎn)來看,自動(dòng)化測(cè)試要想提高測(cè)試效率,需要做到以下幾點(diǎn)。
①自動(dòng)化測(cè)試建設(shè)初期需要投入更多的人力,否則自動(dòng)化測(cè)試無法形成一定的體量,也就談不上代替手工測(cè)試提高測(cè)試效率。
②產(chǎn)品迭代頻率不能太快,否則自動(dòng)化測(cè)試用例將難以跟上維護(hù)的節(jié)奏,幾個(gè)迭代過后,自動(dòng)化用例將不可用。
③自動(dòng)化測(cè)試用例質(zhì)量要過關(guān),否則在執(zhí)行完成后會(huì)出現(xiàn)大量的“誤報(bào)”,即自動(dòng)化測(cè)試用例本身的問題,并非真正的缺陷。
④由于自動(dòng)化測(cè)試對(duì)執(zhí)行環(huán)境要求非常苛刻,因此不能與手工測(cè)試環(huán)境混用。
- Mastering Visual Studio 2017
- R語言數(shù)據(jù)可視化之美:專業(yè)圖表繪制指南
- Reactive Android Programming
- Web Development with MongoDB and Node(Third Edition)
- 從零開始學(xué)C語言
- D3.js By Example
- C#開發(fā)案例精粹
- 打開Go語言之門:入門、實(shí)戰(zhàn)與進(jìn)階
- Java Web從入門到精通(第3版)
- 代碼閱讀
- 零基礎(chǔ)學(xué)Scratch 3.0編程
- 高效使用Greenplum:入門、進(jìn)階與數(shù)據(jù)中臺(tái)
- Python Social Media Analytics
- Mastering OpenStack
- Lync Server Cookbook