云原生集成開發(fā)環(huán)境——TitanIDE
通過網(wǎng)頁在任何地方更安全、更高效地編碼2022-06-23
873
作者:行云創(chuàng)新 孫春景
在談 flaky test 之前,我們先談?wù)勛鳛楣こ處熃?jīng)常遇見的幾個問題:
- 您是否遇到過在測試軟件或者應(yīng)用程序時,都是相同的輸入,有時候通過有時候又不通過?
- 您是否遇到過對相同的代碼進(jìn)行相同的測試會產(chǎn)生不同的結(jié)果?
- 如果您是一個測試工程師提交一個嚴(yán)重bug時,卻在研發(fā)那沒法重現(xiàn),您是否感受到來自開發(fā)的輕視?
...
沒錯,這種每次運(yùn)行相同的代碼或者應(yīng)用程序,卻產(chǎn)生了不同的結(jié)果,我們叫做 flaky test。每當(dāng)開發(fā)更新計(jì)算機(jī)軟件、網(wǎng)頁或者應(yīng)用程序而編寫新代碼時,都需要在整個開發(fā)過程中進(jìn)行測試,以確保應(yīng)用程序在發(fā)布后能夠按照預(yù)期運(yùn)行。從邏輯上講,當(dāng)我們進(jìn)行一次又一次進(jìn)行相同的測試時,代碼將只產(chǎn)生一份結(jié)果,要么通過測試,要么每次不能正常工作,從而測試失??!
然而,看似隨機(jī)的,有時對相同代碼的相同測試會產(chǎn)生不同的結(jié)果。有時它會顯示代碼通過了測試并且應(yīng)用程序按計(jì)劃工作,有時它會顯示代碼未通過測試并且沒有按計(jì)劃工作。當(dāng)測試未能產(chǎn)生一致的結(jié)果時,該測試被認(rèn)為是不穩(wěn)定的。
這種不穩(wěn)定的測試可能由多種因素引起:
- 新編寫的代碼有問題
- 測試本身的問題
- 一些影響測試結(jié)果的外部因素
Flaky tests 是軟件質(zhì)量的報警器,它在您診斷其根本原因前,是無法知道其缺陷來自測試還是產(chǎn)品代碼亦或者外部原因。
Flaky tests的影響
Flaky tests是維護(hù)可靠的測試自動化框架的最大障礙之一。
1.Flaky tests阻礙了生產(chǎn)力
Flaky tests調(diào)試成本很高:工程師團(tuán)隊(duì)花費(fèi)數(shù)天、數(shù)周甚至數(shù)月的時間來確認(rèn)問題,進(jìn)行根本原因分析,然而他們還不一定得到想要的結(jié)果
工程師認(rèn)為已經(jīng)找到了原因并解決了,然而在重新運(yùn)行進(jìn)行測試時,又有可能失敗,從而浪費(fèi)大量時間(此處會涉及到各種流程時間、溝通時間等)。
2.Flaky tests讓工程師對測試失去信心
當(dāng)一個軟件或者應(yīng)用程序出現(xiàn)flaky test時,通常有這樣的反應(yīng):這是測試的問題,而不是我的軟件問題!如果我重新運(yùn)行軟件進(jìn)行測試,也許重新測試就不會失敗。
Flaky tests會導(dǎo)致測試結(jié)果的不一致性,進(jìn)而導(dǎo)致開發(fā)人員對測試本身失去信心。研究發(fā)現(xiàn):開發(fā)人員認(rèn)為測試輸出越不可靠,他們就越有可能完全忽視測試結(jié)果的結(jié)果。簡而言之,開發(fā)人員根本不信任測試結(jié)果。
一個對測試失去信心的團(tuán)隊(duì)和一個沒有測試的團(tuán)隊(duì),哪個做得更好?顯然后者大概率做得更好。如果都不認(rèn)同測試結(jié)果,那么測試就沒有任何意義了。
除了對開發(fā)團(tuán)隊(duì)的負(fù)面影響之外,這些未解決的問題可能會變成定時炸彈,隨時可能在客戶現(xiàn)場爆炸,造成嚴(yán)重?fù)p失。
3.引入了昂貴的技術(shù)債
不穩(wěn)定問題需要及時修復(fù),否則就會產(chǎn)生技術(shù)債,并且隨著不穩(wěn)定問題的擴(kuò)散,“債務(wù)利息”變得越來越昂貴??偠灾?,如果開發(fā)人員希望下次運(yùn)行能夠順利通過,那么他就會忽略這種不穩(wěn)定的問題,從而導(dǎo)致整個系統(tǒng)的穩(wěn)定性隨著時間的推移而下降。并且失敗的測試不再與特定的提交相關(guān)聯(lián),后期排查和解決該問題將會越來越困難。
4.Flaky tests與CD不兼容
任何可靠的發(fā)布過程都將受到flaky tests的阻止,如果系統(tǒng)有很多Flaky tests,那么系統(tǒng)將會不再干凈也很難判斷是否可發(fā)布,這時就需要人工判斷才知道是否可發(fā)布。系統(tǒng)越不穩(wěn)定,CD過程中就越會判斷阻止發(fā)布。如果您的產(chǎn)品過早發(fā)布,總會容忍一些不穩(wěn)定因素,盡管這些因素可能很嚴(yán)重。這就是為什么82%的軟件公司報告測試未解決的失敗是導(dǎo)致生成失敗的主要原因。
如何解決:跟蹤記錄并盡可能的早解決
不管是代碼庫還是測試出現(xiàn)的不穩(wěn)定,你需要做的就是立刻解決。你離開它時間越長,就越難解決,就好比病毒,存在時間越長,就會繁殖越多,產(chǎn)生的變異就越多。*時間旅行調(diào)試*(Time Travel Debugging,簡稱TTD)是解決flaky tests的關(guān)鍵因素。
1.自動記錄flaky tests相關(guān)的失敗測試
當(dāng)作為持續(xù)集成/測試自動化框架的一部分時,*時間旅行調(diào)試*可用于在記錄下持續(xù)運(yùn)行flaky tests。記錄捕獲了失敗運(yùn)行的精確副本,并提供了程序做了什么以及原因的完整圖片。所有工程師所要做的就是向前和向后調(diào)試錄音——就像使用視頻播放器一樣——以快速定位問題的根本原因。通過向前和向后執(zhí)行代碼執(zhí)行時間旅行的能力稱為時間旅行調(diào)試。
這種記錄/重放過程顯著提高了工程效率,因?yàn)闊o需浪費(fèi)時間嘗試重現(xiàn)故障。
Flaky tests每次都會以不同的方式失敗,因此如果沒有時間旅行調(diào)試,很難收集有關(guān)單個故障的足夠信息。更糟糕的是,間歇性故障的根本原因通常發(fā)生在影響被注意到之前的某個時間,例如,數(shù)據(jù)損壞發(fā)生在斷言失敗之前很長時間。記錄故障使工程師可以輕松地從一次運(yùn)行中確定錯誤的根本原因——反復(fù)運(yùn)行,快速定位問題。
2.使錯誤修復(fù)可預(yù)測
由于它們的間歇性,無法預(yù)測修復(fù)片狀測試需要多長時間。但是通過時間旅行調(diào)試,記錄會捕獲調(diào)試和修復(fù)問題所需的所有內(nèi)容(直至指令級別)——從而使缺陷解決變得更加可預(yù)測。
3.減少計(jì)劃延誤
當(dāng)軟件延遲交付時,通常是因?yàn)殚_發(fā)人員無法解決錯誤。隨著不穩(wěn)定測試的解決時間顯著減少,調(diào)試中的可預(yù)測性水平提高,計(jì)劃延遲可以最小化。
4.保持穩(wěn)定
不可靠的測試套件的最壞影響之一是通常不可能注意到新引入的間歇性故障。當(dāng)你有一個可以信任的測試套件時,當(dāng)一個新的間歇性故障源出現(xiàn)時,它很快就會變得很明顯,即使它只是偶爾導(dǎo)致測試套件失敗。
通過將時間旅行調(diào)試作為 CI 或測試自動化框架的一部分,可以快速發(fā)現(xiàn)回歸,并且可以快速根除錯誤代碼。
總之,flaky tests會導(dǎo)致低效的軟件團(tuán)隊(duì)和不可靠的軟件發(fā)布。
修復(fù)所有因子可能是一個昂貴而痛苦的過程;但問題未解決的時間越長,對生產(chǎn)力和產(chǎn)品質(zhì)量的拖累就越大,修復(fù)成本也越高。
時間旅行調(diào)試將軟件故障解決從一個緩慢且不可預(yù)測的消除過程轉(zhuǎn)變?yōu)橐粋€系統(tǒng)的、可重復(fù)的工作流程。
- 使錯誤修復(fù)可預(yù)測并避免計(jì)劃延誤
- 加快缺陷解決,從而加快產(chǎn)品交付
- 提高 CI/CD 管道效率并降低工程成本
了解企業(yè)開發(fā)測試云,從這里開始。