精準(zhǔn)測(cè)試二三談 | IDCF

來(lái)源：Thoughtworks洞見(jiàn)

作者：齊磊   前Thoughtworks高級(jí)質(zhì)量分析師，現(xiàn)任HSBC測(cè)試咨詢專家，擅長(zhǎng)敏捷測(cè)試，測(cè)試開(kāi)發(fā)，DevOps等領(lǐng)域。

我們都在使用敏捷開(kāi)發(fā)、敏捷測(cè)試，維護(hù)著我們的項(xiàng)目，我們寫(xiě)著少量的test case，甚至不寫(xiě)一條case，敏捷宣言其中一條原則是工作的軟件 “高于” 詳盡的文檔，詳解文檔包括各種計(jì)劃書(shū)、總結(jié)報(bào)告、詳盡測(cè)試用例等，我們將大量時(shí)間用在自動(dòng)化測(cè)試以及手工探索性測(cè)試上面，而我們的用例則以BDD形式存在于代碼之中，這樣來(lái)幫助盡可能早的發(fā)現(xiàn)問(wèn)題。

但最近我發(fā)現(xiàn)幾個(gè)客戶在質(zhì)量問(wèn)題，存在一些共性，這些基于黑盒測(cè)試的項(xiàng)目在測(cè)試過(guò)程中存在以下幾個(gè)共同的問(wèn)題：

• 大量的黑盒測(cè)試用例，有的項(xiàng)目甚至用例數(shù)超過(guò)5w，測(cè)試工作大都是手工為主，受主觀人為因素影響太大：每次版本發(fā)布，QA全憑個(gè)人經(jīng)驗(yàn)來(lái)確定改動(dòng)對(duì)系統(tǒng)影響范圍，通常情況，要么測(cè)試范圍定小了，造成漏測(cè)，要么測(cè)試范圍過(guò)大，付出的代價(jià)過(guò)高，造成項(xiàng)目不能如期按時(shí)交付。 
• 代碼與測(cè)試沒(méi)有數(shù)據(jù)可衡量：沒(méi)有單元測(cè)試，其他類型測(cè)試對(duì)代碼覆蓋程度，質(zhì)量高低，沒(méi)有數(shù)據(jù)能夠衡量，例如我們說(shuō)api測(cè)試覆蓋率是100%，這個(gè)數(shù)據(jù)大多都是根據(jù)用例業(yè)務(wù)場(chǎng)景估算出的。QA只能增加更多的黑盒測(cè)試，而實(shí)際功能測(cè)試覆蓋率隨著時(shí)間和用例增多，便會(huì)觸達(dá)覆蓋率的天花板，更多的是重復(fù)的無(wú)效測(cè)試。 
• 自動(dòng)化測(cè)試無(wú)法發(fā)揮作用：對(duì)于web/api或app 后端服務(wù)系統(tǒng)，測(cè)試人員對(duì)除手工測(cè)試外，我們將大量的時(shí)間與精力投放在api接口測(cè)試的實(shí)現(xiàn)上，隨著項(xiàng)目的迭代，自動(dòng)化用例積累越來(lái)越多，從幾百到上千，這時(shí)候我們需要考慮測(cè)試穩(wěn)定性，運(yùn)行時(shí)長(zhǎng)，大量重復(fù)測(cè)試場(chǎng)景與代碼，整個(gè)測(cè)試ROI并不是隨著用例數(shù)增多而上升，反而維護(hù)和排查問(wèn)題成為QA日常工作的重?fù)?dān)，疲于應(yīng)付，沒(méi)有精力將時(shí)間投入到更有用的探索性測(cè)試和分析工作中，進(jìn)而造成bug頻出，整個(gè)團(tuán)隊(duì)便對(duì)自動(dòng)化失去信任，直至廢棄，這也是很多傳統(tǒng)行業(yè)無(wú)法規(guī)模化實(shí)施敏捷測(cè)試原因之一。

那么如何幫助團(tuán)隊(duì)樹(shù)立信心，準(zhǔn)確定位到變更影響的范圍？精準(zhǔn)測(cè)試。這個(gè)概念是最近幾年逐漸興起的話題。

一、先來(lái)談?wù)勈裁词蔷珳?zhǔn)測(cè)試？

定義：利用技術(shù)手段對(duì)測(cè)試過(guò)程產(chǎn)生的數(shù)據(jù)進(jìn)行采集存儲(chǔ)，計(jì)算，匯總，可視化最終幫助團(tuán)隊(duì)提升軟件測(cè)試的效率、并對(duì)項(xiàng)目整體質(zhì)量進(jìn)行改進(jìn)和優(yōu)化的這一系列操作。

通俗點(diǎn)講：核心基于源代碼變更分析，結(jié)合分析算法，確定影響范圍，提升測(cè)試效率。

精準(zhǔn)測(cè)試并沒(méi)有改變傳統(tǒng)的軟件測(cè)試方法論，只不過(guò)是幫助我們將測(cè)試用例與程序代碼之間的邏輯映射關(guān)系建立起來(lái)，而這個(gè)過(guò)程則是通過(guò)算法和工具去采集測(cè)試過(guò)程執(zhí)行的代碼邏輯及測(cè)試數(shù)據(jù)，在測(cè)試過(guò)程加入采集過(guò)程，形成正向和逆向的追溯。

• 正向追溯，開(kāi)發(fā)人員可以看到QA執(zhí)行用例的代碼細(xì)節(jié)，例如用例執(zhí)行過(guò)程中，調(diào)用具體方法與實(shí)現(xiàn)類，方便進(jìn)行缺陷的修復(fù)與定位。
• 逆向追溯，測(cè)試人員通過(guò)release前的增量代碼快速確定測(cè)試用例的范圍，極大減少回歸測(cè)試的盲目性和工作量，提升ROI，達(dá)到測(cè)試覆蓋率最大化。

二、精準(zhǔn)測(cè)試原理

上圖是我基于業(yè)界通用精準(zhǔn)測(cè)試架構(gòu)畫(huà)出的架構(gòu)圖與流程圖。

這套精準(zhǔn)測(cè)試架構(gòu)既可以用作手工測(cè)試，也可用在任意自動(dòng)化測(cè)試上。

整個(gè)架構(gòu)分為以下幾部分：

• 建立用例與代碼覆蓋率之間的映射關(guān)系；
• 影響面評(píng)估，分析識(shí)別增量與變更代碼； 
• 測(cè)試范圍評(píng)估，用例篩選，鏈路分析。

2.1 建立用例與代碼覆蓋率之間的映射關(guān)系

目前建立用例與代碼之間的關(guān)系通過(guò)統(tǒng)計(jì)調(diào)用產(chǎn)生的覆蓋率與路徑進(jìn)行關(guān)聯(lián)。

1）在線模式

• 功能測(cè)試關(guān)聯(lián)方案

目前通用的解決方案是利用Jacocoon-the-fly模式基于 On-the-fly 方式無(wú)須入侵應(yīng)用服務(wù)代碼，啟動(dòng)腳本時(shí)，只需在 JVM 中通過(guò) -javaagent 參數(shù)指定 jar 文件以啟動(dòng) Instrumentation 的代理程序，該代理程序通過(guò) Class Loader 裝載一個(gè) class 前判斷是否需要注入 class 文件，再將統(tǒng)計(jì)代碼插入 class ，測(cè)試覆蓋率分析就可以在 JVM 執(zhí)行測(cè)試的過(guò)程中完成。Jacoco提供了自己的Agent，完成插樁的同時(shí)，還提供了豐富的dump輸出機(jī)制，如File,Tcp Server,Tcp Client。覆蓋率信息可以通過(guò)文件或是Tcp的形式輸出。通過(guò)外部服務(wù)在任意機(jī)器上通過(guò)api請(qǐng)求獲取被測(cè)程序的覆蓋率與執(zhí)行路徑。

對(duì)功能測(cè)試用例，我們可以通過(guò)執(zhí)行單個(gè)用例，經(jīng)過(guò)上述步驟后拿到該條用例影響代碼的覆蓋率與執(zhí)行路徑。在通過(guò)關(guān)聯(lián)服務(wù)，將具體用例的ID與生成的覆蓋率信息（類，方法，行等）建立映射關(guān)系，最后將關(guān)聯(lián)數(shù)據(jù)存到數(shù)據(jù)庫(kù)中保存。

基于Jacocoon-the-fly 模式獲取單個(gè)用例覆蓋率建立映射關(guān)系的流程如下：

以上是基于java語(yǔ)言來(lái)關(guān)聯(lián)用例與代碼直接的關(guān)系，前端也有類似原理的工具，利用istanbul-middleware也可以實(shí)現(xiàn)同樣的功能，具體請(qǐng)查閱一下這兩篇文章，這里不再?gòu)?fù)述。

• 自動(dòng)化測(cè)試關(guān)聯(lián)方案

利用AOP原理，在自動(dòng)化框架的執(zhí)行器加一個(gè)攔截器，在覆蓋率收集開(kāi)關(guān)打開(kāi)時(shí)，請(qǐng)求執(zhí)行前，這個(gè)過(guò)程類似于測(cè)試框架中的before hook：reset 被測(cè)服務(wù)樁數(shù)據(jù)，也就是上一次測(cè)試產(chǎn)生的dump 文件，請(qǐng)求執(zhí)行后，這個(gè)過(guò)程類似于測(cè)試框架中的after hook：用api導(dǎo)出內(nèi)存中的覆蓋率數(shù)據(jù)，我們利用反射拿到用例方法名，利用關(guān)聯(lián)服務(wù)將之與對(duì)應(yīng)的 dump結(jié)果關(guān)聯(lián)起來(lái)，實(shí)現(xiàn)自動(dòng)插樁功能，快速幫助我們建立自動(dòng)化用例與覆蓋率之間的關(guān)系。

2）Offline模式（unit test采用模式，不是本文）

在測(cè)試前先對(duì)文件進(jìn)行插樁，然后生成插過(guò)樁的class或jar包，測(cè)試插過(guò)樁 的class和jar包后，會(huì)生成動(dòng)態(tài)覆蓋信息到文件，最后統(tǒng)一對(duì)覆蓋信息進(jìn)行處理，并生成報(bào)告。Offline模式適用于以下場(chǎng)景：

• 運(yùn)行環(huán)境不支持java agent；
• 部署環(huán)境不允許設(shè)置JVM參數(shù)； 
• 字節(jié)碼需要被轉(zhuǎn)換成其他虛擬機(jī)字節(jié)碼，如Android Dalvik VM；
• 動(dòng)態(tài)修改字節(jié)碼過(guò)程中和其他agent沖突；
• 無(wú)法自定義用戶加載類。

2.2 影響面評(píng)估，分析識(shí)別增量與變更代碼

我們有了代碼與用例直接的關(guān)系的映射，我們需要將之用在開(kāi)發(fā)流程中，首先我們需要得知我們的改動(dòng)是什么，最直接的是通過(guò) git diff 得知具體改動(dòng)代碼，但過(guò)于繁重，且太多干擾例如注釋，空行等，最好的方法是實(shí)現(xiàn)比對(duì)算法，經(jīng)過(guò)降噪處理，消除干擾，進(jìn)而拿到處理后變更數(shù)據(jù)。

2.3 測(cè)試范圍評(píng)估，用例篩選，鏈路分析

我們有了用例與代碼之間的關(guān)系映射，有了提交增量代碼差異記錄，就可以實(shí)現(xiàn)逆向回溯。

利用代碼的差異，通過(guò)查詢服務(wù)就可以在上面提到關(guān)聯(lián)關(guān)系數(shù)據(jù)庫(kù)中反推影響的用例，以及上層的業(yè)務(wù)。這樣可以幫助QA快速劃分測(cè)試范圍，減少過(guò)度測(cè)試。

三、總結(jié)精準(zhǔn)測(cè)試的優(yōu)點(diǎn)

這種代碼與用例，業(yè)務(wù)之間的關(guān)聯(lián)關(guān)系，能夠加深我們對(duì)被測(cè)系統(tǒng)及架構(gòu)的了解，在不斷的版本迭代過(guò)程中，能夠?qū)崟r(shí)了解任何類型測(cè)試對(duì)于當(dāng)前版本的覆蓋率，是否有遺漏的場(chǎng)景等，幫助團(tuán)隊(duì)更好的建立信心，使質(zhì)量真正走上可持續(xù)化道路。

精準(zhǔn)測(cè)試在項(xiàng)目的中后期不在不依賴個(gè)人能力以及業(yè)務(wù)熟悉度等特點(diǎn)，大幅降低了團(tuán)隊(duì)測(cè)試的成本，使得團(tuán)隊(duì)QA能夠有大量的時(shí)間做探索性測(cè)試以及質(zhì)量度量上，提高QA對(duì)于團(tuán)隊(duì)的ROI，帶給團(tuán)隊(duì)更清晰的質(zhì)量數(shù)據(jù)。

但事物總是存在對(duì)立面的，獲得巨大的收益同時(shí)，必然相應(yīng)的存在缺點(diǎn)。否則也應(yīng)當(dāng)像UI自動(dòng)化測(cè)試一樣流行于各個(gè)公司以及團(tuán)隊(duì)中。

四、精準(zhǔn)測(cè)試存在的問(wèn)題

• 基于手工測(cè)試的精準(zhǔn)測(cè)試建立映射關(guān)系繁雜，如果需求改變頻繁，用例維護(hù)以及之間的關(guān)系維護(hù)需要耗費(fèi)大量時(shí)間精力。
  

• 精準(zhǔn)測(cè)試需要一定的自動(dòng)化測(cè)試的覆蓋，這樣做起來(lái)更有意義，例如api自動(dòng)化測(cè)試，如果本身用例過(guò)少，與代碼之間關(guān)聯(lián)關(guān)系不多時(shí)，變更代碼后可能不會(huì)得出什么結(jié)果。

• 最好有對(duì)應(yīng)的用例管理系統(tǒng)，能夠方便的幫助我們建立與代碼之間的關(guān)系。

• 需要投入開(kāi)發(fā)能力強(qiáng)的QA或者測(cè)試開(kāi)發(fā)建立整套系統(tǒng)環(huán)境，但長(zhǎng)遠(yuǎn)考慮，將精準(zhǔn)測(cè)試嵌入整個(gè)公司的質(zhì)量平臺(tái)中，不管對(duì)于新項(xiàng)目還說(shuō)維護(hù)項(xiàng)目來(lái)說(shuō)都是一種提升。

• 項(xiàng)目生命周期需要較長(zhǎng)，短期項(xiàng)目花費(fèi)巨大精力開(kāi)發(fā)和維護(hù)整套精準(zhǔn)測(cè)試系統(tǒng)得不償失。短期項(xiàng)目可以利用精準(zhǔn)測(cè)試以api測(cè)試覆蓋率作為衡量標(biāo)準(zhǔn)。不去建立繁雜的關(guān)系，只監(jiān)控UI API測(cè)試覆蓋率迭代時(shí)的變更來(lái)達(dá)到目的。

精準(zhǔn)測(cè)試不是銀彈，需要巨大的投入，用得好，能夠成倍的提升質(zhì)量，生產(chǎn)效率，用不好的話，就成了領(lǐng)導(dǎo)的KPI項(xiàng)目，棄之可惜，食之無(wú)味，雞肋也。

IDCF DevOps黑客馬拉松，獨(dú)創(chuàng)端到端DevOps體驗(yàn)，精益創(chuàng)業(yè)+敏捷開(kāi)發(fā)+DevOps流水線的完美結(jié)合，2021年僅有的3場(chǎng)公開(kāi)課，數(shù)千人參與并一致五星推薦的金牌訓(xùn)練營(yíng)，追求卓越的你一定不能錯(cuò)過(guò)！

9月11-12日，上海站，企業(yè)組隊(duì)參賽&個(gè)人參賽均可，一年等一回，錯(cuò)過(guò)等一年，趕緊上車(chē)~??