今年開(kāi)始，我們看到了越來(lái)越多的人開(kāi)始關(guān)注測(cè)試用例自動(dòng)生成這個(gè)領(lǐng)域，包括一些Devops產(chǎn)品也在做用例自動(dòng)生成方面的工作。這里我主要和大家來(lái)介紹下測(cè)試用例自動(dòng)生成這個(gè)領(lǐng)域的背景、相關(guān)研究方向、研究難點(diǎn)，以及在螞蟻我們是怎么來(lái)做測(cè)試用例自動(dòng)生成這件事情的。

1

背景

首先我們來(lái)看測(cè)試用例自動(dòng)生成這件事情的背景。隨著業(yè)務(wù)的不斷積累和發(fā)展，工業(yè)界中可以看到大型復(fù)雜系統(tǒng)的數(shù)量是持續(xù)在積累和增長(zhǎng)的。在這個(gè)過(guò)程中，我們對(duì)這些復(fù)雜系統(tǒng)的測(cè)試和維護(hù)成本是不斷在增加的。不管是開(kāi)發(fā)同學(xué)還是測(cè)試同學(xué)，都需要投入大量的時(shí)間在測(cè)試用例編寫(xiě)環(huán)節(jié)。我們也經(jīng)常會(huì)收到一些同學(xué)的反饋，比如在一次功能迭代過(guò)程中，開(kāi)發(fā)業(yè)務(wù)代碼所需要的時(shí)間和開(kāi)發(fā)測(cè)試用例所需要的時(shí)間可能會(huì)達(dá)到1 : 1。從這里我們可以看出，開(kāi)發(fā)測(cè)試用例環(huán)節(jié)是存在非常大的提效空間的。

在整個(gè)快速迭代的背景之下，我們希望能夠通過(guò)智能化的手段來(lái)解決測(cè)試時(shí)間的投入，其中單測(cè)首當(dāng)其沖。

PART

單測(cè)是質(zhì)量保障流程中的第一環(huán)，單測(cè)階段攔截問(wèn)題后解決成本最低

圖1 問(wèn)題修復(fù)成本

從圖1可以看出，在迭代環(huán)節(jié)逐步推進(jìn)的過(guò)程中，環(huán)節(jié)越靠后時(shí)問(wèn)題修復(fù)成本越高，因此我們希望把發(fā)現(xiàn)問(wèn)題的環(huán)節(jié)盡可能提前，單測(cè)就是最早的這個(gè)階段。在單測(cè)階段攔截問(wèn)題，解決問(wèn)題的成本是最低的。

PART

單測(cè)具備Fast 、 Stable、QuickDiagnosis特性，更適合集成至Devops流水線中進(jìn)行持續(xù)回歸

圖2 Google測(cè)試金字塔

大家應(yīng)該對(duì)Google的測(cè)試金字塔比較熟悉，Google測(cè)試金字塔中占比最高的是單測(cè)用例，達(dá)到了80%，再往上才是集成測(cè)試、端到端測(cè)試。為什么單測(cè)能夠作為大底座這樣的存在呢？主要原因在于單測(cè)具備Fast 、 Stable、QuickDiagnosis特性，這些特性使得單測(cè)更適合于集成到Devops流水線里面去做持續(xù)回歸，在我們的項(xiàng)目里面更多比例的測(cè)用例也應(yīng)該是單元測(cè)試用例。

PART

實(shí)際研發(fā)流程中單測(cè)比例低，面臨開(kāi)發(fā)成本高、運(yùn)維難等問(wèn)題

然而，在實(shí)際研發(fā)流程中，我們看到更多的并不是一個(gè)正金字塔，反而是一個(gè)倒金字塔。實(shí)際項(xiàng)目中單測(cè)用例占比往往很低，更多的測(cè)試被推到了集成測(cè)試、甚至是聯(lián)調(diào)測(cè)試階段。我們發(fā)現(xiàn)造成這種現(xiàn)象的主要原因是單測(cè)的開(kāi)發(fā)成本、運(yùn)維成本普遍很高。如何能夠智能化地提升單測(cè)環(huán)節(jié)的效能呢？關(guān)鍵的技術(shù)方向就是去做測(cè)試用例的自動(dòng)生成。

2

相關(guān)研究

測(cè)試用例自動(dòng)生成其實(shí)在學(xué)術(shù)界一直是比較熱門(mén)的研究方向，這里和大家一起分享下目前學(xué)術(shù)界已有的研究方向和相關(guān)成果。

圖3 測(cè)試用例自動(dòng)生成相關(guān)研究

PART

模糊測(cè)試Fuzzing

Fuzzing的主要思路是通過(guò)構(gòu)造大量的測(cè)試輸入來(lái)去發(fā)現(xiàn)軟件里面存在的問(wèn)題。2013年AFL工具發(fā)布，AFL首次在Fuzzing里使用了通過(guò)插裝獲取代碼覆蓋，從而來(lái)引導(dǎo)Fuzzing的方式。隨后以覆蓋率為引導(dǎo)的Fuzzing也被使用到了測(cè)試用例自動(dòng)生成領(lǐng)域。

PART

符號(hào)執(zhí)行

符號(hào)執(zhí)行是一個(gè)程序分析非常經(jīng)典的概念，主要是通過(guò)解析程序的執(zhí)行路徑，用符號(hào)模擬輸入并獲得輸出。很多研究者也在嘗試通過(guò)使用符號(hào)執(zhí)行的結(jié)果來(lái)進(jìn)行測(cè)試用例自動(dòng)生成。

PART

基于搜索 Search Based Software Testing

Search Based Software Testing的思路是從問(wèn)題解空間出發(fā)，通過(guò)一些啟發(fā)式的搜索算法來(lái)去解決測(cè)試用例生成的問(wèn)題。SBST的可擴(kuò)展性很高，在整體的算法框架之下，可以隨意切換搜索算法，比如遺傳算法、爬山算法、多目標(biāo)搜索算法等等，都可以很好的融入到這個(gè)框架里面來(lái)去做這個(gè)用例生成。

3

難點(diǎn)和挑戰(zhàn)

當(dāng)我們將已有研究成果去落地到實(shí)際系統(tǒng)時(shí)，會(huì)遇到什么樣的難點(diǎn)和挑戰(zhàn)呢？這里列出了三大類(lèi)挑戰(zhàn)，涵蓋了測(cè)試用例自動(dòng)生成、執(zhí)行、運(yùn)維的整個(gè)生命周期。

圖4 測(cè)試用例自動(dòng)生成的難點(diǎn)和挑戰(zhàn)

PART

測(cè)試用例生成

測(cè)試用例生成是最基礎(chǔ)、最核心的環(huán)節(jié)。在實(shí)際系統(tǒng)中進(jìn)行測(cè)試用例生成通常會(huì)面臨復(fù)雜數(shù)據(jù)類(lèi)型、復(fù)雜語(yǔ)言特性的情況。對(duì)于復(fù)雜情況的處理能力決定了生成用例的覆蓋率效果。除了復(fù)雜語(yǔ)法外，斷言生成也是測(cè)試用例生成的難點(diǎn)之一。我們的測(cè)試用例之所以能夠有效地發(fā)現(xiàn)問(wèn)題，是因?yàn)橛美邪瑪嘌?，因此測(cè)試用例自動(dòng)生成需要能夠包括斷言的生成能力。

PART

測(cè)試用例執(zhí)行

測(cè)試用例生成后，就來(lái)到了執(zhí)行這個(gè)環(huán)節(jié)。執(zhí)行環(huán)節(jié)最重要的是有一個(gè)穩(wěn)定的運(yùn)行環(huán)境。相信大家肯定都會(huì)遇到這種場(chǎng)景，測(cè)試用例跑不通或者多次運(yùn)行結(jié)果不一致，本質(zhì)都是用例不穩(wěn)定。為了保證用例能夠穩(wěn)定運(yùn)行，是需要去做很多Mock的。比如代碼獲取了當(dāng)前機(jī)器的IP，需要通過(guò)對(duì)IP的mock來(lái)確保無(wú)論測(cè)試用例跑在哪臺(tái)機(jī)器上都能夠得到穩(wěn)定的返回值。用例運(yùn)行穩(wěn)定之后，要考慮運(yùn)行效率和運(yùn)行穩(wěn)定性。系統(tǒng)越復(fù)雜，對(duì)應(yīng)測(cè)試用例的量級(jí)也越高。大規(guī)模單元測(cè)試用例的運(yùn)行過(guò)程中，需要保證運(yùn)行效率和穩(wěn)定性，才能融入DevOps流水線進(jìn)行持續(xù)回歸。

PART

測(cè)試用例運(yùn)維

最后是測(cè)試用例的運(yùn)維。測(cè)試用例的運(yùn)維包括了：1）存量用例汰換。被測(cè)代碼變更后，部分舊的測(cè)試用例會(huì)失效。比如，被測(cè)代碼的某個(gè)方法在變更過(guò)程中被刪除了，那么涉及到這個(gè)方法的測(cè)試用例都會(huì)失效。對(duì)于失效用例，我們需要能夠把它們汰換掉。2）增量用例生成。迭代變更時(shí)會(huì)有新的代碼進(jìn)來(lái)，對(duì)于新增的代碼需要能夠觸發(fā)用例生成，將增量用例補(bǔ)充進(jìn)來(lái)。3）回歸分析。在歷史存量用例的回歸過(guò)程中，會(huì)出現(xiàn)用例失敗報(bào)錯(cuò)的情況。針對(duì)這些失敗的情況，我們需要進(jìn)行降噪處理過(guò)濾掉無(wú)效失敗，從而去發(fā)現(xiàn)真正的代碼變更導(dǎo)致的問(wèn)題。

4

測(cè)試用例智能生成SmartUnit

上面講了測(cè)試用例自動(dòng)生成這項(xiàng)技術(shù)在實(shí)際系統(tǒng)中落地會(huì)遇到的很多難點(diǎn)和挑戰(zhàn)，在這部分就來(lái)介紹我們?cè)谖浵佀龅臏y(cè)試用例智能生成產(chǎn)品SmartUnit。

01

產(chǎn)品能力介紹

SmartUnit是智能單元測(cè)試用例生成產(chǎn)品，致力于解決單元測(cè)試環(huán)節(jié)里測(cè)試用例的自動(dòng)生成執(zhí)行態(tài)化和管理，SmartUnit的產(chǎn)品能力包括了快速提升覆蓋率和智能探測(cè)異常。

圖5 SmartUnit能力大圖

SmartUnit產(chǎn)品提供了三種使用方式，涵蓋Local測(cè)試和回歸測(cè)試階段：

PART

本地命令行

提供核心能力Jar包，用戶可以通過(guò)本地java -jar來(lái)執(zhí)行jar包做用例生成。這種使用方式適用于Local測(cè)試階段，在開(kāi)發(fā)同學(xué)寫(xiě)完代碼后，直接在本地就可以生成用例，進(jìn)行單測(cè)驗(yàn)證。

PART

IDEA插件

IDEA插件與本地命令行一樣，也適用于Local測(cè)試。相比于本地命令行，IDEA插件給用戶帶來(lái)了操作方式上的便捷。不需要執(zhí)行多條命令，而是僅僅右鍵單擊被測(cè)類(lèi)，即可一鍵生成測(cè)試用例。

PART

DevOps組件

為減輕用例運(yùn)維成本，我們提供了DevOps組件。通過(guò)DevOps組件，可以跟隨每一次的變更，每一次的PR或者M(jìn)R來(lái)去自動(dòng)觸發(fā)這個(gè)組件，自動(dòng)去做這個(gè)用例生成與汰換。下圖展示了我們與螞蟻Devops融合后的流水線全生命周期管理示例。

圖6 SmartUnit與螞蟻Devops流水線融合

對(duì)于SmartUnit這類(lèi)測(cè)試用例自動(dòng)生成產(chǎn)品，我們認(rèn)為核心評(píng)價(jià)指標(biāo)應(yīng)該包括五個(gè)：

PART

用例覆蓋率

我們不管去怎么做測(cè)試這個(gè)環(huán)節(jié)，最終希望的都是都能夠?qū)Υa有更深度的覆蓋，對(duì)代碼有更完整的測(cè)試。目前SmartUnit自動(dòng)生成用例的覆蓋率超過(guò)60%，在部分系統(tǒng)上可達(dá)到80%。

PART

用例有效性

用例有效性用于度量用例到底有沒(méi)有作用，會(huì)不會(huì)在代碼變更的情況下出現(xiàn)執(zhí)行失敗。我們度量有效性的方式是基于源碼攻擊，對(duì)于源碼進(jìn)行模擬變更，測(cè)試用例是否能夠發(fā)現(xiàn)變更。目前SmartUnit自動(dòng)生成用例的有效性超過(guò)60%，高于人工手寫(xiě)的測(cè)試用例。

PART

用例精簡(jiǎn)性

單元測(cè)試用例一般是精簡(jiǎn)的，甚至于是可讀的。只有精簡(jiǎn)的用例才能夠合并到代碼庫(kù)中持續(xù)進(jìn)行維護(hù)。因此用例的精簡(jiǎn)性也是非常重要的指標(biāo)。目前SmartUnit對(duì)生成的用例會(huì)進(jìn)行以行覆蓋/分支覆蓋為指標(biāo)的精簡(jiǎn)，確保保留下來(lái)的用例都是對(duì)覆蓋率有正向影響的。

PART

用例生成效率

用例生成效率用來(lái)評(píng)價(jià)自動(dòng)用例生成產(chǎn)品的提效能力，通過(guò)自動(dòng)生成的效率提升，從而提升單測(cè)環(huán)節(jié)的效能。

PART

用例執(zhí)行效率

單元測(cè)試用例的量級(jí)相對(duì)會(huì)比較大，針對(duì)大規(guī)模的單測(cè)用例，需要保障用例執(zhí)行效率才不會(huì)阻塞CI流水線。面對(duì)2~3萬(wàn)的測(cè)試用例量級(jí)，SmartUnit可以在30min內(nèi)執(zhí)行完。

02

自動(dòng)生成用例示例

我們說(shuō)了這么久用例自動(dòng)生成，這里直觀看一下SmartUnit自動(dòng)生成用例的樣子。SmartUnit用例包含以下四大部分：

用例注釋：直觀的告訴大家這個(gè)用例在測(cè)那些被測(cè)代碼、使用什么樣的入?yún)?、校?yàn)什么樣的返回值；

Mock數(shù)據(jù)：?jiǎn)螠y(cè)用例里最為基本的一部分，也是占比最大的一部分。SmartUnit會(huì)通過(guò)Mock的方式屏蔽掉依賴；

方法調(diào)用：請(qǐng)求被測(cè)方法，獲取返回值；

結(jié)果校驗(yàn)：對(duì)方法返回值進(jìn)行Assert。

圖7 SmartUnit自動(dòng)生成用例示意

03

核心算法和技術(shù)

為了達(dá)成我們?cè)诋a(chǎn)品能力上的目標(biāo)，SmartUnit底層具備完整的核心算法架構(gòu)來(lái)確保自動(dòng)生成用例的覆蓋率、有效性等指標(biāo)水位。下圖是SmartUnit從0到1進(jìn)行用例生成的算法架構(gòu)。

圖8 SmartUnit算法架構(gòu)

SmartUnit使用動(dòng)態(tài)多目標(biāo)搜索作為主體算法框架，結(jié)合程序分析、符號(hào)執(zhí)行等技術(shù)共同完成從0到1進(jìn)行用例生成。從整體框架上包含環(huán)境構(gòu)建、種子用例生成、單測(cè)用例迭代、用例語(yǔ)句生成。

PART

環(huán)境構(gòu)建

通過(guò)加載被測(cè)類(lèi)和被測(cè)類(lèi)的依賴，從而構(gòu)建出一套可運(yùn)行環(huán)境。后續(xù)的算法迭代強(qiáng)依賴于環(huán)境構(gòu)建是否成功。

PART

種子用例生成

有了可運(yùn)行環(huán)境后，會(huì)進(jìn)行種子用例的生成。種子用例一般比較簡(jiǎn)單，只包含一些初始化的對(duì)象和調(diào)用。

PART

單測(cè)用例迭代

種子用例作為單測(cè)迭代的初始狀態(tài)被傳入到真正的用例迭代流程中，在用例迭代流程中對(duì)種子不斷地修改、優(yōu)化、迭代，最終產(chǎn)出我們需要的測(cè)試用例集。在用例迭代過(guò)程中，通過(guò)Mock動(dòng)態(tài)生成算法、最優(yōu)用例數(shù)據(jù)生成算法、最優(yōu)調(diào)用序列算法來(lái)對(duì)用例的完整性進(jìn)行填充，包括Mock語(yǔ)句和方法調(diào)用語(yǔ)句。最終，需要執(zhí)行用例來(lái)確定它的覆蓋效果，根據(jù)覆蓋率效果進(jìn)行最優(yōu)用例選擇。選擇出來(lái)的用例作為下一次迭代的種子，一代一代地迭代下去。

整個(gè)迭代過(guò)程有兩個(gè)終止條件。第一個(gè)是覆蓋率達(dá)到了預(yù)期的值，第二個(gè)是達(dá)到了設(shè)置的時(shí)間域值。

PART

用例語(yǔ)句生成

與整個(gè)單測(cè)用例迭代過(guò)程相配合的，是用例語(yǔ)句生成。用例語(yǔ)句生成包括Mock語(yǔ)句、Method調(diào)用語(yǔ)句、Assert語(yǔ)句。其中值得一提的是Assert語(yǔ)句自動(dòng)生成，在SmartUnit中使用基于Mutate的斷言自動(dòng)生成算法，這也是目前在學(xué)術(shù)界比較廣泛認(rèn)可的斷言生成方式。

04

落地效果

最后介紹在螞蟻SmartUnit的落地效果。目前SmartUnit已經(jīng)在螞蟻多個(gè)BU中使用，接入系統(tǒng)數(shù)據(jù)1000+。

用例覆蓋率維度上，SmartUnit自動(dòng)生成用例可以達(dá)到60%+的效果，結(jié)合歷史存量用例后平均覆蓋率達(dá)到80%+；

用例有效性維度上，SmartUnit作為底層能力支持了螞蟻內(nèi)部編程活動(dòng)。針對(duì)活動(dòng)中提交的PR，67%的PR發(fā)現(xiàn)了問(wèn)題，共發(fā)現(xiàn)34個(gè)問(wèn)題，包括7個(gè)有效BUG和27個(gè)健壯性問(wèn)題。

圖9 SmartUnit落地效果

05

總結(jié)與展望

圖10 總結(jié)與展望

面向未來(lái)發(fā)展，SmartUnit的發(fā)力方向包括：算法持續(xù)優(yōu)化、豐富產(chǎn)品形態(tài)、開(kāi)源共建、SaaS服務(wù)。

審核編輯 ：李倩