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

1

背景

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

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

PART

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

圖1 問題修復成本

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

PART

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

圖2 Google測試金字塔

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

PART

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

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

2

相關研究

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

圖3 測試用例自動生成相關研究

PART

模糊測試Fuzzing

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

PART

符號執行

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

PART

基于搜索 Search Based Software Testing

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

3

難點和挑戰

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

圖4 測試用例自動生成的難點和挑戰

PART

測試用例生成

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

PART

測試用例執行

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

PART

測試用例運維

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

4

測試用例智能生成SmartUnit

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

01

產品能力介紹

SmartUnit是智能單元測試用例生成產品，致力于解決單元測試環節里測試用例的自動生成執行態化和管理，SmartUnit的產品能力包括了快速提升覆蓋率和智能探測異常。

圖5 SmartUnit能力大圖

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

PART

本地命令行

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

PART

IDEA插件

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

PART

DevOps組件

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

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

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

PART

用例覆蓋率

我們不管去怎么做測試這個環節，最終希望的都是都能夠對代碼有更深度的覆蓋，對代碼有更完整的測試。目前SmartUnit自動生成用例的覆蓋率超過60%，在部分系統上可達到80%。

PART

用例有效性

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

PART

用例精簡性

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

PART

用例生成效率

用例生成效率用來評價自動用例生成產品的提效能力，通過自動生成的效率提升，從而提升單測環節的效能。

PART

用例執行效率

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

02

自動生成用例示例

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

用例注釋：直觀的告訴大家這個用例在測那些被測代碼、使用什么樣的入參、校驗什么樣的返回值；

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

方法調用：請求被測方法，獲取返回值；

結果校驗：對方法返回值進行Assert。

圖7 SmartUnit自動生成用例示意

03

核心算法和技術

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

圖8 SmartUnit算法架構

SmartUnit使用動態多目標搜索作為主體算法框架，結合程序分析、符號執行等技術共同完成從0到1進行用例生成。從整體框架上包含環境構建、種子用例生成、單測用例迭代、用例語句生成。

PART

環境構建

通過加載被測類和被測類的依賴，從而構建出一套可運行環境。后續的算法迭代強依賴于環境構建是否成功。

PART

種子用例生成

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

PART

單測用例迭代

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

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

PART

用例語句生成

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

04

落地效果

最后介紹在螞蟻SmartUnit的落地效果。目前SmartUnit已經在螞蟻多個BU中使用，接入系統數據1000+。

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

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

圖9 SmartUnit落地效果

05

總結與展望

圖10 總結與展望

面向未來發展，SmartUnit的發力方向包括：算法持續優化、豐富產品形態、開源共建、SaaS服務。

審核編輯 ：李倩