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

1

背景

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

在整個快速迭代的背景之下，我們希望能夠通過智能化的手段來解決測試時間的投入，其中單測首當其沖。

PART

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

圖1 問題修復成本

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

PART

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

圖2 Google測試金字塔

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

PART

實際研發(fā)流程中單測比例低，面臨開發(fā)成本高、運維難等問題

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

2

相關(guān)研究

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

圖3 測試用例自動生成相關(guān)研究

PART

模糊測試Fuzzing

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

PART

符號執(zhí)行

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

PART

基于搜索 Search Based Software Testing

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

3

難點和挑戰(zhàn)

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

圖4 測試用例自動生成的難點和挑戰(zhàn)

PART

測試用例生成

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

PART

測試用例執(zhí)行

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

PART

測試用例運維

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

4

測試用例智能生成SmartUnit

上面講了測試用例自動生成這項技術(shù)在實際系統(tǒng)中落地會遇到的很多難點和挑戰(zhàn)，在這部分就來介紹我們在螞蟻所做的測試用例智能生成產(chǎn)品SmartUnit。

01

產(chǎn)品能力介紹

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

圖5 SmartUnit能力大圖

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

PART

本地命令行

提供核心能力Jar包，用戶可以通過本地java -jar來執(zhí)行jar包做用例生成。這種使用方式適用于Local測試階段，在開發(fā)同學寫完代碼后，直接在本地就可以生成用例，進行單測驗證。

PART

IDEA插件

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

PART

DevOps組件

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

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

對于SmartUnit這類測試用例自動生成產(chǎn)品，我們認為核心評價指標應(yīng)該包括五個：

PART

用例覆蓋率

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

PART

用例有效性

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

PART

用例精簡性

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

PART

用例生成效率

用例生成效率用來評價自動用例生成產(chǎn)品的提效能力，通過自動生成的效率提升，從而提升單測環(huán)節(jié)的效能。

PART

用例執(zhí)行效率

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

02

自動生成用例示例

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

用例注釋：直觀的告訴大家這個用例在測那些被測代碼、使用什么樣的入?yún)?、校驗什么樣的返回值?/p>

Mock數(shù)據(jù)：單測用例里最為基本的一部分，也是占比最大的一部分。SmartUnit會通過Mock的方式屏蔽掉依賴；

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

結(jié)果校驗：對方法返回值進行Assert。

圖7 SmartUnit自動生成用例示意

03

核心算法和技術(shù)

為了達成我們在產(chǎn)品能力上的目標，SmartUnit底層具備完整的核心算法架構(gòu)來確保自動生成用例的覆蓋率、有效性等指標水位。下圖是SmartUnit從0到1進行用例生成的算法架構(gòu)。

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

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

PART

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

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

PART

種子用例生成

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

PART

單測用例迭代

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

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

PART

用例語句生成

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

04

落地效果

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

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

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

圖9 SmartUnit落地效果

05

總結(jié)與展望

圖10 總結(jié)與展望

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

審核編輯 ：李倩