建站
咨詢
售后
建站咨詢
新聞中心
這么多的CASE，花了大量時間和資源去運行，真能發(fā)現(xiàn)BUG嗎?CI做到90%的行覆蓋率，能發(fā)現(xiàn)問題嗎?測試用例越來越多，刪一些，會不會就發(fā)現(xiàn)不了問題了?今天，我們談?wù)勅绾卧u估測試用例的有效性?
在橫縣等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供做網(wǎng)站、成都做網(wǎng)站 網(wǎng)站設(shè)計制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè),橫縣網(wǎng)站建設(shè)費用合理。
我們的測試用例有兩個比較關(guān)鍵的部分：
1)調(diào)用被測代碼：例如下面的RuleService.getLastRuleByClientId(ClientId)。2)進行結(jié)果Check：例如下面的AssertEqual(OrderId,"ABCD1234")。
- TestCaseA
- ...
- RuleService.createRuleByClientId(ClientId,RuleDO);
- StringOrderId=RuleService.getLastRuleByClientId(ClientId);
- ...
- TestCaseB
- ...
- RuleService.createRuleByClientId(ClientId,RuleDO);
- StringOrderId=OrderService.getLastOrderByClientId(ClientId);
- AssertEqual(OrderId,"ABCD1234");
- ...
我們希望一組測試用例不僅能夠“觸發(fā)被測代碼的各種分支”，還能夠做好結(jié)果校驗。
- 當(dāng)業(yè)務(wù)代碼出現(xiàn)問題的時候，測試用例可以發(fā)現(xiàn)這個問題，我們就認為這一組測試用例是有效的。
- 當(dāng)業(yè)務(wù)代碼出現(xiàn)問題的時候，測試用例沒能發(fā)現(xiàn)這個問題，我們就認為這一組測試用例是無效的。
我們對測試用例有效性的理論建模是：
>> 測試有效性 = 被發(fā)現(xiàn)的問題數(shù) / 出現(xiàn)問題的總數(shù)
為什么要評估測試用例的有效性?
測試用例有效性評估的方法?
基于故障復(fù)盤的模式成本太高，我們希望能夠主動創(chuàng)造問題來評估測試用例的有效性。
我們找到了一種衡量“測試有效性”的方法，變異測試(mutation testing)：
變異測試的例子
我們用了一組測試用例(3個)，去測試一個判斷分支。而為了證明這一組測試用例的有效性，我們向業(yè)務(wù)代碼中注入變異。我們把b<100的條件改成了b<=100。 我們認為：
- 一組Success的測試用例，在其被測對象發(fā)生變化后(注入變異后)，應(yīng)該至少有一個失敗。
- 如果這組測試用例仍然全部Success，則這組測試用例的有效性不足。
通過變異測試的方式：讓注入變異后的業(yè)務(wù)代碼作為“測試用例”，來測試“測試代碼”。
我們實現(xiàn)了多種規(guī)則，可以主動的注入下面這些變異：
如何優(yōu)雅的評估測試有效性?
為了全自動的進行測試有效性評估，我們做了一個變異機器人，其主要運作是：
- 往被測代碼中寫入一個BUG(即：變異);
- 執(zhí)行測試;
- 把測試結(jié)果和無變異時的測試結(jié)果做比對，判斷是否有新的用例失敗;
- 重復(fù)1-3若干次，每次注入一個不同的Bug;
- 統(tǒng)計該系統(tǒng)的“測試有效性” 。
變異機器人的優(yōu)點：
- 防錯上線：變異是單獨拉代碼分支，且該代碼分支永遠不會上線，不影響生產(chǎn)。
- 全自動：只需要給出系統(tǒng)代碼的git地址，即可進行評估，得到改進報告。
- 高效：數(shù)小時即可完成一個系統(tǒng)的測試有效性評估。
- 擴展性：該模式可以支持JAVA以及JAVA以外的多種語系。
- 適用性：該方法不僅適用于單元測試，還適用于其他自動化測試，例如接口測試、功能測試、集成測試。
變異機器人的使用門檻：
- 測試成功率：只會選擇通過率100%的測試用例，所對應(yīng)的業(yè)務(wù)代碼做變異注入。
- 測試覆蓋率：只會注入被測試代碼覆蓋的業(yè)務(wù)代碼，測試覆蓋率越高，評估越準確。
高配版變異機器人
我們正在打造的高配版變異機器人擁有三大核心競爭力：
分鐘級的系統(tǒng)評估效率
為了保證評估的準確性，100個變異將會執(zhí)行全量用例100遍，每次執(zhí)行時間長是一大痛點。
高配版變異機器人給出的解法：
- 并行注入：基于代碼覆蓋率，識別UT之間的代碼覆蓋依賴關(guān)系，將獨立的變異合并到一次自動化測試中。
- 熱部署：基于字節(jié)碼做更新，減少變異和部署的過程。
- 精準測試：基于UT代碼覆蓋信息，只運行和本次變異相關(guān)的UT(該方法不僅適用于UT，還適用于其他自動化測試，例如接口測試、功能測試、集成測試)。
學(xué)習(xí)型注入經(jīng)驗庫
為了避免“殺蟲劑”效應(yīng)，注入規(guī)則需要不斷的完善。
高配版變異機器人給出的解法：故障學(xué)習(xí)，基于故障學(xué)習(xí)算法，不斷學(xué)習(xí)歷史的代碼BUG，并轉(zhuǎn)化為注入經(jīng)驗?？蓪W(xué)習(xí)型經(jīng)驗庫目前覆蓋螞蟻金服的代碼庫，明年會覆蓋開源社區(qū)。
兼容不穩(wěn)定環(huán)境
集成測試環(huán)境會存在一定的不穩(wěn)定，難以判斷用例失敗是因為“發(fā)現(xiàn)了變異”還是“環(huán)境出了問題”，導(dǎo)致測試有效性評估存在誤差。
高配版變異機器人給出的解法：
- 高頻跑：同樣的變異跑10次，對多次結(jié)果進行統(tǒng)計分析，減少環(huán)境問題引起的偶發(fā)性問題。
- 環(huán)境問題自動定位：接入附屬的日志服務(wù)，它會基于用例日志/系統(tǒng)錯誤日志構(gòu)建的異常場景，自動學(xué)習(xí)“因環(huán)境問題導(dǎo)致的用例失敗”，準確區(qū)分出用例是否發(fā)現(xiàn)變異。
落地效果如何?
我們在螞蟻金服的一個部門進行了實驗，得出了這樣的數(shù)據(jù)：
換言之，幾個系統(tǒng)的測試有效性為：系統(tǒng)A 72%，系統(tǒng)B 56%，系統(tǒng)C 70%。
測試有效性(%) = 1 - 未發(fā)現(xiàn)注入數(shù) / 注入數(shù)
更多的測試有效性度量手段
基于代碼注入的測試有效性度量，只是其中的一種方法，我們?nèi)粘玫降姆椒ㄓ羞@么幾種：
- 代碼注入：向代碼注入變異，看測試用例是否能發(fā)現(xiàn)該問題
- 內(nèi)存注入：修改API接口的返回內(nèi)容，看測試用例是否能發(fā)現(xiàn)該問題
- 靜態(tài)掃描：掃描測試代碼里是否做了Assert等判斷，看Assert場景與被測代碼分支的關(guān)系
- ... 還有更多其他的度量手段
Meet the testcase again
測試有效性可以作為基石，驅(qū)動很多事情向好發(fā)展：
- 讓測試用例變得更能發(fā)現(xiàn)問題。
- 讓無效用例可被識別、清理。
- 創(chuàng)造一個讓技術(shù)人員真正思考如何寫好TestCase的質(zhì)量文化。
- 測試左移與敏捷的前置條件。
- ......
寫到最后，想起了同事給我講的一個有趣的人生經(jīng)歷：
“大二期間在一家出版社編輯部實習(xí)，工作內(nèi)容就是校對文稿中的各種類型的錯誤。編輯部考核校對質(zhì)量的辦法是，人為的事先在文稿中加入各種類型的錯誤，然后根據(jù)你的錯誤發(fā)現(xiàn)率來衡量，并計算實習(xí)工資。”
“你干得咋樣?”
“我學(xué)習(xí)了他們的規(guī)則，寫了個程序來查錯，拿到了第一個滿分”
“厲害了...”
“第二個月就不行了，他們不搞錯別字了，搞了一堆語法、語義、中心思想的錯誤... 我就專心干活兒了”
“...”
殊途同歸，其致一也。
文章名稱：CI做到90%的行覆蓋率，真能發(fā)現(xiàn)BUG嗎？
標題URL：http://m.5511xx.com/article/cdjogjs.html
