测试知识汇总
目錄
軟件測(cè)試開發(fā)流程
需求分析
評(píng)審測(cè)試用例
執(zhí)行測(cè)試
提交 Bug 并推動(dòng) Bug 解決
回歸測(cè)試
編寫并提交測(cè)試報(bào)告
軟件測(cè)試方法
白盒測(cè)試
黑盒測(cè)試
等價(jià)類
?灰盒測(cè)試
動(dòng)態(tài)測(cè)試
α測(cè)試
β測(cè)試
冒煙測(cè)試
回歸測(cè)試
隨機(jī)測(cè)試
探索測(cè)試
為什么引入自動(dòng)化測(cè)試
自動(dòng)化測(cè)試框架包含哪些模塊
基礎(chǔ)模塊
管理模塊
運(yùn)行模塊
統(tǒng)計(jì)模塊
常用的測(cè)試框架類型
模塊化測(cè)試框架
數(shù)據(jù)驅(qū)動(dòng)框架
關(guān)鍵字驅(qū)動(dòng)框架
混合模型
測(cè)試框架設(shè)計(jì)原則
如何設(shè)計(jì)一個(gè)不錯(cuò)的測(cè)試案例
第一，等價(jià)類劃分法
第二，邊界值分析方法
第三，錯(cuò)誤推測(cè)方法
軟件測(cè)試開發(fā)流程
需求分析
在測(cè)試前拿到產(chǎn)品需求文檔，進(jìn)行需求分析及需求評(píng)審前先對(duì)需求文檔進(jìn)行詳細(xì)的閱讀，對(duì)有疑問(wèn)的地方進(jìn)行標(biāo)注。
具體可從以下進(jìn)行：
- 分析產(chǎn)品功能點(diǎn)
- 產(chǎn)品核心競(jìng)爭(zhēng)力
- Kano模型、馬斯洛需求分析、多問(wèn)幾個(gè)為什么、上下文分析法
制訂測(cè)試用例（重要）
工欲善其事，必先利其器；對(duì)測(cè)試而言，測(cè)試用例就是器，做好了才能把好關(guān)
-
使用思維導(dǎo)圖列舉測(cè)試大綱，盡量發(fā)散，想到什么就寫什么，；先放后收，對(duì)知識(shí)點(diǎn)進(jìn)行總結(jié)和歸納，標(biāo)記重點(diǎn)測(cè)試模塊，刪除冗余及重復(fù)測(cè)試點(diǎn)。
-
可使用邊界值法、等價(jià)類劃分法、錯(cuò)誤推測(cè)法、因果圖法等設(shè)計(jì)案例
-
根據(jù)測(cè)試大綱制定測(cè)試用例，需包含模塊名、測(cè)試優(yōu)先級(jí)、操作步驟、期望結(jié)果、測(cè)試結(jié)果、備注
評(píng)審測(cè)試用例
- 測(cè)試作為主導(dǎo)，聯(lián)合開發(fā)、項(xiàng)目經(jīng)理、PM進(jìn)行測(cè)試用例評(píng)審
- 可先講解測(cè)試大綱，讓開發(fā)、項(xiàng)目經(jīng)理、PM心中對(duì)測(cè)試用例有個(gè)大概；后再進(jìn)行詳細(xì)測(cè)試用例講解
執(zhí)行測(cè)試
- 根據(jù)測(cè)試用例執(zhí)行測(cè)試
- 發(fā)現(xiàn)問(wèn)題保留現(xiàn)場(chǎng)，記錄測(cè)試方法，通知開發(fā)解決問(wèn)題
- 覆蓋測(cè)試用例之外若有時(shí)間可進(jìn)行探索性測(cè)試
提交 Bug 并推動(dòng) Bug 解決
-
在Bug管理工具上提交Bug，詳細(xì)記錄測(cè)試步驟
-
根據(jù)Bug嚴(yán)重程度劃分Bug等級(jí):致命、嚴(yán)重、一般、提示
-
推動(dòng)開發(fā)解決問(wèn)題，記錄問(wèn)題進(jìn)展，一般聊天溝通，若問(wèn)題嚴(yán)重則需通過(guò)郵件推動(dòng)解決
回歸測(cè)試
-
對(duì)已修復(fù)的 Bug 進(jìn)行驗(yàn)證
-
對(duì) Bug 所在模塊進(jìn)行基本功能測(cè)試；整體進(jìn)行冒煙測(cè)試，確保不會(huì)因?yàn)樾薷?Bug 而引起其他功能出現(xiàn)問(wèn)題
編寫并提交測(cè)試報(bào)告
可使用金字塔原理設(shè)計(jì)測(cè)試報(bào)告，先總后分，上級(jí)統(tǒng)領(lǐng)下級(jí)，下級(jí)推導(dǎo)出上級(jí)，環(huán)環(huán)相扣
-
對(duì)Bug進(jìn)行匯總，篩選出各個(gè)等級(jí)的Bug存活情況
-
制訂Bug發(fā)現(xiàn)及解決曲線圖，一般版本正常應(yīng)是前期多，后期收斂，存活的是級(jí)別較低的Bug
-
總結(jié)歸納版本情況，評(píng)估發(fā)布與否
軟件測(cè)試方法
白盒測(cè)試
概念：關(guān)注程序代碼的具體細(xì)節(jié)，根據(jù)軟件內(nèi)部代碼的邏輯結(jié)構(gòu)分析來(lái)進(jìn)行測(cè)試。主要是通過(guò)閱讀程序代碼或者通過(guò)使用開發(fā)工具中的單步調(diào)試來(lái)判斷軟件質(zhì)量。關(guān)注代碼的實(shí)現(xiàn)細(xì)節(jié)。主要對(duì)程序模塊的所有獨(dú)立執(zhí)行路徑至少測(cè)試一遍、對(duì)所有的邏輯判定，取“真”或“假”的兩種情況都要測(cè)試一遍，循環(huán)邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體等等
測(cè)試用例設(shè)計(jì)方法：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋、判定覆蓋
優(yōu)點(diǎn)：增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問(wèn)題
缺點(diǎn)：系統(tǒng)龐大時(shí)測(cè)試開銷很大，難以測(cè)試所有運(yùn)行路徑；測(cè)試基于代碼，只能驗(yàn)證代碼是否正確，而不曉得代碼設(shè)計(jì)是否合理，可能會(huì)遺漏某些功能需求
黑盒測(cè)試
概念：不考慮其內(nèi)部結(jié)構(gòu)，即具體代碼實(shí)現(xiàn)，檢測(cè)軟件的各個(gè)功能能否得以實(shí)現(xiàn)，確認(rèn)軟件功能的正確性，依靠軟件說(shuō)明書來(lái)判斷測(cè)試用例,關(guān)注具體的客戶需求及軟件功能。黑盒測(cè)試主要是為了發(fā)現(xiàn)：1.是否有不正確的或者遺漏的功能；2.輸入是否能輸出正確的結(jié)果；3.性能上是否滿足要求
優(yōu)點(diǎn)：①較為簡(jiǎn)單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn)，與軟件內(nèi)部實(shí)現(xiàn)無(wú)關(guān)；②從用戶角度出發(fā)，實(shí)際考慮用戶使用的功能及可能出現(xiàn)的問(wèn)題
缺點(diǎn)：不可能覆蓋所有的代碼，覆蓋率較低
測(cè)試用例設(shè)計(jì)方法：邊界值分析法、等價(jià)類劃分、錯(cuò)誤猜測(cè)法、因果圖法、狀態(tài)圖法、測(cè)試大綱法、隨機(jī)測(cè)試法、場(chǎng)景法
等價(jià)類
輸入域的各子集中，各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的。
- 等價(jià)類劃分：將全部輸入數(shù)據(jù)合理劃分成若干個(gè)等價(jià)類，在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為輸入條件，就可以用少量代表性測(cè)試數(shù)據(jù)取得較好的測(cè)試結(jié)果。分為有效等價(jià)類（合理、有意義的輸入數(shù)據(jù)構(gòu)成的集合）和無(wú)效等價(jià)類
- 邊界值分析法：大量錯(cuò)誤是發(fā)生在輸入輸出范圍的邊界上，選定測(cè)試用例時(shí)應(yīng)該選取正好等于、剛剛大于、剛剛小于邊界值的值作為測(cè)試數(shù)據(jù)，而不是選取等價(jià)類中的任意值，作為對(duì)等價(jià)類劃分的補(bǔ)充
- 錯(cuò)誤猜測(cè)法：基于經(jīng)驗(yàn)和直覺推測(cè)，列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況，根據(jù)這些情況選擇測(cè)試用例
- 因果圖法：考慮輸入條件之間的相互組合，也考慮輸出結(jié)果對(duì)輸入條件的依賴關(guān)系。原因即為輸入條件或者輸入條件的等價(jià)類，結(jié)果即為輸出條件，把因果轉(zhuǎn)換為決策表，為決策表中的每一列設(shè)計(jì)測(cè)試用例。
- 場(chǎng)景分析法：根據(jù)用戶場(chǎng)景來(lái)模擬用戶的操作步驟
- 大綱法：著眼于需求。將需求轉(zhuǎn)換為大綱的形式，大綱表示為樹狀結(jié)構(gòu)，在根和葉子節(jié)點(diǎn)之間存在唯一路徑，大綱為每條路徑定義了一個(gè)特殊的輸入條件集合，用于測(cè)試用例。
- 隨機(jī)測(cè)試法：不考慮任何用例和需求，完全站在用戶的角度對(duì)產(chǎn)品進(jìn)行測(cè)試
?灰盒測(cè)試
關(guān)注輸入輸出的準(zhǔn)確性，也關(guān)注內(nèi)部的代碼，但是沒(méi)有白盒測(cè)試那么詳細(xì)完整。
動(dòng)態(tài)測(cè)試
實(shí)際運(yùn)行被測(cè)程序，輸入相應(yīng)的測(cè)試用例，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，從而驗(yàn)證程序的正確性、有效性和可靠性，并且分析系統(tǒng)運(yùn)行的效率和健壯性。
α測(cè)試
一個(gè)用戶在開發(fā)環(huán)境下的受控測(cè)試，模擬實(shí)際操作環(huán)境
β測(cè)試
多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試，如一些軟件的公測(cè)
冒煙測(cè)試
在大規(guī)模測(cè)試之前，先對(duì)軟件的基本、核心、主要功能進(jìn)行測(cè)試，節(jié)省資源
回歸測(cè)試
開發(fā)修正完代碼后再回過(guò)頭來(lái)做測(cè)試
隨機(jī)測(cè)試
跳出思維的限制，沒(méi)有思想、沒(méi)有步驟地隨機(jī)進(jìn)行測(cè)試
探索測(cè)試
有思想，有步驟地測(cè)試一些復(fù)雜的、不常用地功能
為什么引入自動(dòng)化測(cè)試
自動(dòng)化測(cè)試是將自動(dòng)化工具和技術(shù)應(yīng)用于軟件測(cè)試，旨在減少測(cè)試工作，更快，更經(jīng)濟(jì)地驗(yàn)證軟件質(zhì)量。有助于以更少的工作量構(gòu)建質(zhì)量更好的軟件。
許多公司多多少少都在做自動(dòng)化測(cè)試，但手動(dòng)測(cè)試仍然占主要的比例，因?yàn)橛行﹫F(tuán)隊(duì)不知道如何在開發(fā)過(guò)程中更好的利用自動(dòng)化測(cè)試來(lái)替代手動(dòng)測(cè)試。
手工測(cè)試通常是工程師仔細(xì)的執(zhí)行預(yù)定義的測(cè)試用例，將執(zhí)行結(jié)果與預(yù)期的行為進(jìn)行手工比較并記錄結(jié)果。每次源代碼更改時(shí)都會(huì)重復(fù)這些手動(dòng)測(cè)試，由于都是人為參與，這個(gè)過(guò)程中很容易出錯(cuò)。
在組織中引入自動(dòng)化測(cè)試時(shí)，需要投入大量財(cái)力和時(shí)間。 然而，一般沒(méi)有太多的財(cái)務(wù)回報(bào)，至少在小規(guī)模開始時(shí)沒(méi)有。 因此許多公司選擇開源測(cè)試自動(dòng)化工具，特別是在開始引入自動(dòng)化測(cè)試的階段。
通常，軟件公司害怕投資自動(dòng)化測(cè)試，不是因?yàn)樨?fù)擔(dān)不起這個(gè)投入，而是因?yàn)樗麄儞?dān)心的回報(bào)不會(huì)像預(yù)期的那樣，或者根本不會(huì)產(chǎn)生積極的投資回報(bào)率。
1. 降低成本（特別是問(wèn)題出現(xiàn)時(shí)的成本）
如前所述，開始自動(dòng)化測(cè)試的初始成本并不高，比如選用免費(fèi)的開源工具。 但是，一旦您的組織全面展開自動(dòng)化測(cè)試，您就會(huì)希望投資更好的工具、更好的服務(wù)器，雇用人力來(lái)維護(hù)基礎(chǔ)設(shè)施等。這些成本絕對(duì)不是無(wú)關(guān)緊要的。
自動(dòng)化測(cè)試不會(huì)自動(dòng)生成。創(chuàng)建有價(jià)值的自動(dòng)化測(cè)試需要花費(fèi)時(shí)間和精力，而且不會(huì)在一夜之間發(fā)生。
如果您想證明引入自動(dòng)化測(cè)試的合理性，不能只關(guān)注財(cái)務(wù)回報(bào)，而應(yīng)考慮應(yīng)用出現(xiàn)問(wèn)題導(dǎo)致的隱性成本。例如一個(gè)問(wèn)題在手動(dòng)測(cè)試沒(méi)有發(fā)現(xiàn)而出現(xiàn)在產(chǎn)品環(huán)境中，公司會(huì)花多少錢？你是否會(huì)失去客戶？需要花多少時(shí)間、資源和資金來(lái)糾正這種情況？
如果每次對(duì)代碼進(jìn)行更改時(shí)，都重復(fù)執(zhí)行一組非常強(qiáng)大的測(cè)試套件，可以降低問(wèn)題出現(xiàn)在產(chǎn)品環(huán)境的風(fēng)險(xiǎn)。自動(dòng)化測(cè)試有助于在軟件開發(fā)生命周期的早期發(fā)現(xiàn)錯(cuò)誤，從而降低交付故障軟件的風(fēng)險(xiǎn)。
說(shuō)到底，向市場(chǎng)提供高質(zhì)量的產(chǎn)品重要性遠(yuǎn)大于任何其他類型的節(jié)省。
2. 節(jié)省時(shí)間
雖然初期建立自動(dòng)化測(cè)試需要花費(fèi)大量的時(shí)間和人力，但是一旦自動(dòng)化測(cè)試建立了，您就可以重用這些測(cè)試。自動(dòng)化測(cè)試的執(zhí)行速度明顯快于手動(dòng)測(cè)試，不易出錯(cuò)，且節(jié)省人力。
在日常的代碼修改過(guò)程中，您可以在每次提交時(shí)執(zhí)行自動(dòng)化測(cè)試，而不必通過(guò)設(shè)置環(huán)境或記住執(zhí)行每個(gè)測(cè)試的步驟來(lái)持續(xù)執(zhí)行手動(dòng)步驟。一切都是自動(dòng)完成的。
只要首次設(shè)置完成后，就可以重復(fù)運(yùn)行你的自動(dòng)化測(cè)試，從而將重復(fù)的手動(dòng)測(cè)試時(shí)間從數(shù)周縮短至數(shù)小時(shí)。
同樣一旦編寫好，測(cè)試可以執(zhí)行任意次。與手動(dòng)測(cè)試儀不同，測(cè)試也可全天候，無(wú)人值守的執(zhí)行。
在軟件開發(fā)團(tuán)隊(duì)中，通常的做法是每天多次（通常是每次提交）運(yùn)行基本單元測(cè)試，并且每天在下班后執(zhí)行耗時(shí)的集成測(cè)試和UI測(cè)試。
3. CI和DevOps
自動(dòng)化測(cè)試構(gòu)成任何持續(xù)集成或DevOps設(shè)置的基礎(chǔ)。從本質(zhì)上講，CI（持續(xù)集成）和DevOps都依賴于“Fail fast, Fail early”的理念。對(duì)代碼庫(kù)的每次提交都將自動(dòng)進(jìn)行測(cè)試，并將結(jié)果報(bào)告給開發(fā)人員。開發(fā)人員優(yōu)先修復(fù)任何導(dǎo)致構(gòu)建失敗或?qū)е轮饕獪y(cè)試失敗的錯(cuò)誤，確保主線代碼始終按預(yù)期工作。
4. 準(zhǔn)確性和可靠性
由于運(yùn)行每個(gè)測(cè)試涉及多個(gè)先決條件，手動(dòng)測(cè)試容易出錯(cuò)。另外每個(gè)測(cè)試可能需要不同的執(zhí)行順序。
畢竟手動(dòng)測(cè)試人員是人類，人有不善于執(zhí)行重復(fù)枯燥工作的特點(diǎn)，因此可以預(yù)料手動(dòng)測(cè)試不會(huì)精確并有一定的幾率出錯(cuò)。這會(huì)導(dǎo)致不準(zhǔn)確的結(jié)果反饋到開發(fā)團(tuán)隊(duì)。
自動(dòng)化測(cè)試每次都執(zhí)行相同的步驟，不僅精確，而且結(jié)果可在最短的時(shí)間內(nèi)提供給所有相關(guān)人員。
可靠性的另一個(gè)方面是在不同服務(wù)器上重新執(zhí)行相同的測(cè)試。這使得能夠快速驗(yàn)證測(cè)試是否在所有服務(wù)器上按預(yù)期運(yùn)行，從而排除了服務(wù)器配置問(wèn)題的可能性。
4. 性能測(cè)試
性能負(fù)載測(cè)試可確保您的應(yīng)用程序可以處理預(yù)期和意外的用戶負(fù)載。
如果您當(dāng)前只在項(xiàng)目中使用手動(dòng)測(cè)試方法，則負(fù)載測(cè)試可能會(huì)推遲到開發(fā)周期結(jié)束。按照敏捷方法和持續(xù)集成理念，應(yīng)及早地進(jìn)行性能測(cè)試，但現(xiàn)實(shí)是很大一部分項(xiàng)目團(tuán)隊(duì)執(zhí)行做這個(gè)測(cè)試的時(shí)間太晚，最終導(dǎo)致產(chǎn)品發(fā)布推遲。
自動(dòng)化性能測(cè)試能夠同時(shí)運(yùn)行數(shù)千個(gè)測(cè)試，模擬數(shù)百萬(wàn)用戶，所有這些用戶手動(dòng)測(cè)試幾乎都是不可能的。
5. 增加對(duì)軟件的信心
敏捷方法建議使用sprint，即短周期的迭代。每個(gè)sprint通常2-3周。這需要一種新的方式來(lái)組織測(cè)試工作并要求更高的效率。
每個(gè)sprint都專注于開發(fā)一組小功能，但必須在其結(jié)束的時(shí)候提供較完整的新功能特性，還包括之前sprint的所有功能特性。如果沒(méi)有適當(dāng)?shù)臏y(cè)試，在不破壞之前正常工作的功能特性的情況下提供全功能系統(tǒng)的風(fēng)險(xiǎn)很高。在每個(gè)sprint中反復(fù)手動(dòng)測(cè)試所有功能會(huì)效率低下。
這也是自動(dòng)化測(cè)試最大的好處。自動(dòng)化測(cè)試并能夠在每個(gè)sprint中快速重復(fù)測(cè)試，可以確保所有事情都按預(yù)期工作。
6. 衡量質(zhì)量指標(biāo)
可用于自動(dòng)化測(cè)試的擴(kuò)展和工具提供了測(cè)量許多代碼質(zhì)量指標(biāo)的功能，例如代碼覆蓋率（即實(shí)際測(cè)試的代碼百分比），技術(shù)債，代碼語(yǔ)義檢查等。
通常，當(dāng)測(cè)試作為持續(xù)集成或DevOps工作流程的一部分執(zhí)行時(shí)，可同時(shí)獲取這些方面的測(cè)量數(shù)據(jù)。
之所以能夠測(cè)量這些指標(biāo)，是因?yàn)樽詣?dòng)化測(cè)試代碼本身與產(chǎn)品代碼共存，通過(guò)在自動(dòng)構(gòu)建階段解析源代碼，能提供在幾分鐘內(nèi)測(cè)量巨大代碼庫(kù)質(zhì)量的機(jī)會(huì)。這在手動(dòng)測(cè)試中根本不可能。
小結(jié)
如果您的產(chǎn)品質(zhì)量是您的首要目標(biāo)，我強(qiáng)烈建議您使用自動(dòng)化測(cè)試作為日常開發(fā)實(shí)踐的一部分。它將確保您的應(yīng)用程序得到正確測(cè)試，并為研發(fā)、管理人員和客戶提供信心。
自動(dòng)化測(cè)試需要前期投入，并且需要花時(shí)間進(jìn)行開發(fā)。這些投入會(huì)得到長(zhǎng)期的回報(bào)：可以減少工作量，消除手動(dòng)測(cè)試的錯(cuò)誤，提高準(zhǔn)確性，最終節(jié)省成本和時(shí)間。
總的來(lái)說(shuō)，自動(dòng)化測(cè)試是一種比手動(dòng)測(cè)試更快獲得故障反饋的方法，符合“快速失敗，早期失敗”的原則。它有助于實(shí)現(xiàn)手動(dòng)測(cè)試無(wú)法提供的質(zhì)量。在自動(dòng)化測(cè)試中，
行為驅(qū)動(dòng)的自動(dòng)化測(cè)試
現(xiàn)已廣泛為研發(fā)團(tuán)隊(duì)所接受，基于行為驅(qū)動(dòng)(BDD)的測(cè)試腳本具有上手快、易維護(hù)、方便所有stakeholders溝通等特點(diǎn)。
如果您還沒(méi)有一款合適的自動(dòng)化測(cè)試工具來(lái)確保軟件質(zhì)量，您可以了解
自動(dòng)化測(cè)試框架包含哪些模塊
一個(gè)比較成熟的測(cè)試框架通常會(huì)包含 4 個(gè)部分，分別為基礎(chǔ)模塊，管理模塊，統(tǒng)計(jì)模塊和運(yùn)行模塊。
基礎(chǔ)模塊
造房子要穩(wěn)固需要良好的地基。如果把自動(dòng)化測(cè)試框架比作一輛汽車，那么自動(dòng)化測(cè)試基礎(chǔ)模塊就是那四只輪胎，沒(méi)有它們，這輛汽車寸步難行，它們一般包括如下部分。
- 可重用的組件
? ? ? ?一般來(lái)說(shuō)用來(lái)降低開發(fā)成本，常見有日志模塊，時(shí)間模塊等
- 配置文件
? ? ? ?通常會(huì)包含測(cè)試環(huán)境的配置和應(yīng)用程序的配置。其中測(cè)試環(huán)境配置用來(lái)減少環(huán)境版本切換，從開發(fā)到上線。
管理模塊
管理模塊就仿佛是車中的內(nèi)飾，它對(duì)測(cè)試框架的使用操作體驗(yàn)有著直接的影響，分為測(cè)試數(shù)據(jù)管理和測(cè)試文件管理
- 測(cè)試數(shù)據(jù)管理
測(cè)試數(shù)據(jù)一般是測(cè)試用例用到的各種測(cè)試數(shù)據(jù)，他們是為了驗(yàn)證業(yè)務(wù)正確性而構(gòu)造，每一組的測(cè)試案例通常會(huì)對(duì)應(yīng)一對(duì)或多對(duì)測(cè)試數(shù)據(jù)。測(cè)試數(shù)據(jù)的創(chuàng)建又分為實(shí)時(shí)創(chuàng)建和事先創(chuàng)建，
實(shí)時(shí)創(chuàng)建是測(cè)試代碼運(yùn)行的時(shí)候才生成測(cè)試數(shù)據(jù)。好處是測(cè)試數(shù)據(jù)和測(cè)試代碼解耦合，測(cè)試人員不用關(guān)心創(chuàng)建過(guò)程和業(yè)務(wù)調(diào)用鏈，通常用在測(cè)試的公用功能上。
事先創(chuàng)建，是指測(cè)試代碼運(yùn)行前就準(zhǔn)備好的數(shù)據(jù)文件，其好處是數(shù)據(jù)拿來(lái)即用，幾乎不耗費(fèi)時(shí)間，由于沒(méi)有業(yè)務(wù)調(diào)用，所以這在一定程度上減少了調(diào)用失敗的風(fēng)險(xiǎn)；壞處則是數(shù)據(jù)文件本身需要維護(hù)，以保持可用性和正確性。
- 測(cè)試文件管理
測(cè)試文件管理就仿佛是車子的外觀，給人第一印象。一個(gè)測(cè)試用例通常需要包含三個(gè)文件，分別是Page類文件，測(cè)試類文件和對(duì)象庫(kù)文件。
這三個(gè)文件共同描述一個(gè)完整的測(cè)試用例。測(cè)試文件的結(jié)構(gòu)清晰有助于他人理解測(cè)試框架的設(shè)計(jì)思想
運(yùn)行模塊
運(yùn)行模塊為測(cè)試框架的發(fā)送機(jī)，用于測(cè)試用例的組織和運(yùn)行，通常包含下面幾個(gè)部分
-
測(cè)試用例調(diào)度，驅(qū)動(dòng)機(jī)制
-
錯(cuò)誤恢復(fù)機(jī)制
測(cè)試框架應(yīng)該具有一定的錯(cuò)誤恢復(fù)機(jī)制，測(cè)試案例執(zhí)行過(guò)程中，可能出現(xiàn)代碼運(yùn)行錯(cuò)誤或環(huán)境導(dǎo)致的錯(cuò)誤。
- 持續(xù)集成支持
測(cè)試框架應(yīng)該能夠和 CI 系統(tǒng)低成本集成，包括通過(guò)用戶輸入?yún)?shù)指定運(yùn)行環(huán)境、測(cè)試結(jié)束后自動(dòng)生成測(cè)試報(bào)告等。
統(tǒng)計(jì)模塊
統(tǒng)計(jì)模塊相當(dāng)于車子的品質(zhì)和口碑。一個(gè)完整的統(tǒng)計(jì)模塊，可以告訴你當(dāng)前測(cè)試有沒(méi)有 Bug，還能分析軟件質(zhì)量的變化情況，統(tǒng)計(jì)模塊一般包含下面幾個(gè)模塊
- 測(cè)試報(bào)告
測(cè)試報(bào)告應(yīng)該全面，包括測(cè)試用例條數(shù)統(tǒng)計(jì)、測(cè)試用例成功/失敗百分比、測(cè)試用例總執(zhí)行時(shí)間等總體信息。其中，對(duì)于單條測(cè)試用例，還應(yīng)該包括測(cè)試用例 ID、測(cè)試用例運(yùn)行結(jié)果、測(cè)試用例運(yùn)行時(shí)間、測(cè)試用例所屬模塊、測(cè)試失敗時(shí)刻系統(tǒng)截圖、測(cè)試的日志等信息。
- 日志模塊
測(cè)試框架應(yīng)該包括完善的日志文件，方便出錯(cuò)時(shí)進(jìn)行排查和定位。
常用的測(cè)試框架類型
模塊化測(cè)試框架
模塊化測(cè)試框架是利用 OOP 思想和 PO 模式改造而來(lái)的框架。
模塊化測(cè)試框架把整個(gè)測(cè)試分為多個(gè)模塊，模塊化有以下幾個(gè)特征：
-
我們將一個(gè)業(yè)務(wù)或者一個(gè)頁(yè)面成為一個(gè) Page 對(duì)象；
-
這個(gè) Page 對(duì)象，我們以一個(gè) Page 類來(lái)表示它；
-
這個(gè) Page 類里存放有所有這個(gè) Page所屬的頁(yè)面對(duì)象、元素操作；
-
頁(yè)面對(duì)象和元素操作組成一個(gè)個(gè)的測(cè)試類方法，供測(cè)試用例層調(diào)用。
簡(jiǎn)單來(lái)說(shuō)，使用了 PO 模式的框架就可以叫作模塊化測(cè)試框架。
-
模塊化測(cè)試框架的好處在于方便維護(hù)，你的測(cè)試用例可以由不同模塊的不同對(duì)象組成；
-
壞處在于你需要非常了解你的系統(tǒng)及這些模塊是如何劃分的，才能在測(cè)試腳本里自如地使用，否則你就會(huì)陷入重復(fù)定義模塊對(duì)象的循環(huán)里。
數(shù)據(jù)驅(qū)動(dòng)框架
數(shù)據(jù)驅(qū)動(dòng)框架主要是解決測(cè)試數(shù)據(jù)問(wèn)題。
在測(cè)試中，我們常常需要為同一個(gè)測(cè)試邏輯，構(gòu)造不同的測(cè)試數(shù)據(jù)以滿足業(yè)務(wù)需求，這些測(cè)試數(shù)據(jù)可以保存在測(cè)試代碼里，也可以保存在外部文件里（包括 Excel、File、DB）。
數(shù)據(jù)驅(qū)動(dòng)框架的精髓在于，輸入 M 組數(shù)據(jù)，框架會(huì)自動(dòng)構(gòu)造出 M 個(gè)測(cè)試用例，并在測(cè)試結(jié)果中把每一個(gè)測(cè)試用例的運(yùn)行結(jié)果獨(dú)立展示出來(lái)。
在 Python 架構(gòu)里，最出名的數(shù)據(jù)驅(qū)動(dòng)框架就是 DDT。
關(guān)鍵字驅(qū)動(dòng)框架
當(dāng)把一系列代碼封裝為要給關(guān)鍵字，在測(cè)試的過(guò)程中，通過(guò)組合關(guān)鍵字的方式來(lái)生成測(cè)試用例，而不關(guān)心關(guān)鍵字如何運(yùn)作的，這種為關(guān)鍵字驅(qū)動(dòng)框架。
混合模型
并不一定要選擇上面的三種框架之一，需要根據(jù)需求靈活的選擇測(cè)試框架，在工作中可能經(jīng)常需要糅合不同的框架模型，這樣的模型就叫做混合模型。
測(cè)試框架設(shè)計(jì)原則
- 首先是清晰明了，學(xué)習(xí)成本低，其中包含代碼規(guī)范和模塊清晰明確。
-
通用性強(qiáng)，可維護(hù)，可擴(kuò)展
-
對(duì)錯(cuò)誤的處理能力強(qiáng)
? ? ? ?錯(cuò)誤處理機(jī)制，能高效解決。系統(tǒng)日志清晰，方便調(diào)試。
- 運(yùn)行效率高且功能強(qiáng)大
? ? ??支持測(cè)試環(huán)境切換，支持外部數(shù)據(jù)驅(qū)動(dòng)，支持順序并發(fā)，遠(yuǎn)程運(yùn)行，報(bào)告完備詳盡。
- 支持版本控制和持續(xù)集成
? ? ?版本控制回溯復(fù)盤，持續(xù)集成全局出發(fā)
如何設(shè)計(jì)一個(gè)不錯(cuò)的測(cè)試案例
「好的」測(cè)試用例一定是一個(gè)完備的集合，它能夠覆蓋所有等價(jià)類以及各種邊界值，而跟能否發(fā)現(xiàn)缺陷無(wú)關(guān)。
一個(gè)“好的”測(cè)試用例，必須具備以下三個(gè)特征?。
-
整體完備性?：「好的」測(cè)試用例一定是一個(gè)完備的整體，是有效測(cè)試用例組成的集合，能夠完全覆蓋測(cè)試需求。
-
等價(jià)類劃分的準(zhǔn)確性?： 指的是對(duì)于每個(gè)等價(jià)類都能保證只要其中一個(gè)輸入測(cè)試通過(guò)，其他輸入也一定測(cè)試通過(guò)。
-
等價(jià)類集合的完備性?： 需要保證所有可能的邊界值和邊界條件都已經(jīng)正確識(shí)別。
三種最常用的測(cè)試用例設(shè)計(jì)方法： 等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測(cè)方法。
第一，等價(jià)類劃分法
我們只要從每個(gè)等價(jià)類中任意選取一個(gè)值進(jìn)行測(cè)試，就可以用少量具有代表性的測(cè)試輸入取得較好的測(cè)試覆蓋結(jié)果?，F(xiàn)在，我給你看一個(gè)具體的例子：學(xué)生信息系統(tǒng)中有一個(gè)考試成績(jī)的輸入項(xiàng)，成績(jī)的取值范圍是 0~100 之間的整數(shù)，考試成績(jī)及格的分?jǐn)?shù)線是 60。為了測(cè)試這個(gè)輸入項(xiàng)，顯然不可能用 0~100 的每一個(gè)數(shù)去測(cè)試。通過(guò)需求描述可以知道，輸入 0~59 之間的任意整數(shù)，以及輸入 60~100 之間的任意整數(shù)，去驗(yàn)證和揭露輸入框的潛在缺陷可以看做是等價(jià)的。那么這就可以在 0~59 和 60~100 之間各隨機(jī)抽取一個(gè)整數(shù)來(lái)進(jìn)行驗(yàn)證。這樣的設(shè)計(jì)就構(gòu)成了所謂的“有效等價(jià)類”。
你不要覺得進(jìn)行到這里，已經(jīng)完成了等價(jià)類劃分的工作，因?yàn)榈葍r(jià)類劃分方法的另一個(gè)關(guān)鍵點(diǎn)是要找出所有「無(wú)效等價(jià)類」 。顯然，如果輸入的成績(jī)是負(fù)數(shù)，或者是大于100的數(shù)等都構(gòu)成了“無(wú)效等價(jià)類”。
在考慮了無(wú)效等價(jià)類后，最終設(shè)計(jì)的測(cè)試用例為：
有效等價(jià)類1：0~59之間的任意整數(shù)；
有效等價(jià)類2：59~100之間的任意整數(shù)；
無(wú)效等價(jià)類1：小于0的負(fù)數(shù)；
無(wú)效等價(jià)類2：大于100的整數(shù)；
無(wú)效等價(jià)類3：0~100之間的任何浮點(diǎn)數(shù)；
無(wú)效等價(jià)類4：其他任意非數(shù)字字符。
第二，邊界值分析方法
邊界值分析是對(duì)等價(jià)類劃分的補(bǔ)充，你從工程實(shí)踐經(jīng)驗(yàn)中可以發(fā)現(xiàn)，大量的錯(cuò)誤發(fā)生在輸入輸出的邊界值上，所以需要對(duì)邊界值進(jìn)行重點(diǎn)測(cè)試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測(cè)試數(shù)據(jù)。我們繼續(xù)看學(xué)生信息系統(tǒng)中“考試成績(jī)”的例子，選取的邊界值數(shù)據(jù)應(yīng)該包括：-1，0，1，59，60，61，99，100，101。
第三，錯(cuò)誤推測(cè)方法
錯(cuò)誤推測(cè)方法是指基于對(duì)被測(cè)試軟件系統(tǒng)設(shè)計(jì)的理解、過(guò)往經(jīng)驗(yàn)以及個(gè)人直覺，推測(cè)出軟件可能存在的缺陷，從而有針對(duì)性地設(shè)計(jì)測(cè)試用例的方法。** 這個(gè)方法強(qiáng)調(diào)的是對(duì)被測(cè)試軟件的需求理解以及設(shè)計(jì)實(shí)現(xiàn)的細(xì)節(jié)把握，當(dāng)然還有個(gè)人的能力。
錯(cuò)誤推測(cè)法和目前非常流行的“探索式測(cè)試方法”的基本思想和理念是不謀而合的，這類方法在目前的敏捷開發(fā)模式下的投入產(chǎn)出比很高，因此被廣泛應(yīng)用。但是，這個(gè)方法的缺點(diǎn)也顯而易見，那就是難以系統(tǒng)化，并且過(guò)度依賴個(gè)人能力。
總結(jié)：在我看來(lái)，深入理解被測(cè)軟件需求的最好方法是，測(cè)試工程師在需求分析和設(shè)計(jì)階段就開始介入，因?yàn)檫@個(gè)階段是理解和掌握軟件的原始業(yè)務(wù)需求的最好時(shí)機(jī)。
總結(jié)
- 上一篇： mysql limit 和 offset
- 下一篇： [测试用例设计]