自動化單元測試用例生成工具EvoSuite 的性能探究

岳鑫

（四川大學計算機學院，成都610065）

0 引言

單元測試是軟件測試中非常基礎和重要的方式，能夠盡早發現程序缺陷，保障軟件質量。手動單元測試是一項耗時又有挑戰性的工作，自動化單元測試能有效提升測試效率、降低成本。

EvoSuite 是一款先進的JUnit 測試工具，由Gordon Fraser 和Andrea Arcuri 公開發表于2011 年[1]，作為一個開源軟件，源碼存管于GitHub①https://github.com/EvoSuite/evosuite，并得到不斷地改進和維護。基于搜索的軟件測試研討會（Search-Based Software Testing，簡稱SBST②http://www.searchbasedsoftwaretesting.org）從2013 年開始增加了JUnit 測試工具競賽環節，評測當前流行的自動化工具的性能。為了提升競賽的公正性和效率，SBST 從2017年開始實現了一個簡單易用的開源框架③https://github.com/PROSRESEARCHCENTER/junitcontest來自動執行競賽流程。近三年（2017-2019）競賽都是EvoSuite 取得了最高分[2-4]。

EvoSuite 使用遺傳算法來進化生成一組具有最優代碼覆蓋的Junit 測試用例[5]。它首先初始化一組由隨機測試用例組成的測試套件，然后迭代地使用搜索、變異和交叉等搜索算子（searching operators）來進化它們。搜索過程中存在一個基于覆蓋率的適應度函數（fitness function）來指導這種進化，例如最基本的是分支覆蓋。當搜索結束后，選取具有最高代碼覆蓋的測試套件，并在保持覆蓋率的前提下去除冗余測試用例。最后會添加回歸測試斷言，讓生成的測試套件能夠應用于回歸測試場景。

作為一款有代表性的JUnit 測試工具，可以說Evo-Suite 代表了該類工具的最先進水平，那么它目前的實際表現究竟如何？本文借助SBST 會議中JUnit 測試工具競賽所使用的框架，選取了15 個來自真實世界的Java 項目，共計130 個被測類，實證探究最新版本Evo-Suite 的性能，包括其運行穩定性，不同生成時間下生成的測試用例的可用性、覆蓋率和揭錯能力，以及與手工測試用例效果的差異。本研究評估了目前EvoSuite 的實際表現，并為該工具的使用和改進提供了有價值的建議，對于其他同類工具的改進和該領域內的相關研究也有借鑒意義。

1 實驗設計

1.1 實驗目標

實驗將從以下幾個方面來探究EvoSuite 的性能：

（1）EvoSuite 運行的穩定性。穩定性是指在不同的生成時間下，面對不同的被測類，該工具總是能正確運行，最終生成測試用例。

（2）生成時間對測試用例的可用性、覆蓋率和揭錯能力的影響。在運行EvoSuite 前，可以設定生成時間。可用性是指生成的測試用例語法正確，能夠通過編譯（沒有不可編譯測試），并能在生成之后的任意時間正確執行（沒有不穩定測試）。EvoSuite 在生成一些斷言時，被測類中的某些與外部因素（如系統時間、文件系統等）關聯緊密的代碼會被執行到，這可能導致將來執行包含這些斷言的測試用例時會報錯。這種測試用例叫做不穩定測試，需要特別處理。這些測試套件的覆蓋率和揭錯能力可以通過計算行覆蓋率、分支覆蓋率和變異分數這些指標來量化。已有研究表明，具有更高變異分數的測試套件也會有更好的揭錯效果[6]。

（3）自動生成的測試用例與手工測試用例的效果比較。面對相同的被測類，將EvoSuite 生成的效果最好的測試用例與手工測試用例進行比較，如果覆蓋率和揭錯能力差異較小，則說明該工具有可能替代手工測試用例編寫，以用于實際軟件測試。

1.2 實驗對象及環境

實驗使用了當前最新版本的EvoSuite（1.0.6）④https://github.com/EvoSuite/evosuite/releases。參考之前的研究[7]及SBST 比賽中EvoSuite 的參數設置[8]，禁用了使用變異分析來過濾斷言的功能，因為這需要花費很長時間。除了將生成時間作為自變量，其余都保持默認配置，因為這能達到最好的效果[7]。另外需要說明的是，由于EvoSuite 在生成測試套件時包含若干個階段：初始化、搜索、精簡測試、斷言生成、編譯檢查、移除不穩定測試[5]。因此，對于某一給定的生成時間，每個階段的時間分配策略是：搜索階段分配50%，其他階段各分配10%。對于任意一個階段，如果超時，就立即停止并保留當前的結果，執行下一個階段。

在選取實驗所用的項目時，遵循了以下原則：能夠代表真實世界中的軟件;考慮到獲取的難易程度，一般使用開源項目；項目要盡量覆蓋多個應用領域；項目中最好包含手工測試套件；項目中的代碼足夠復雜；程序的輸入類型多樣。另外，在選擇項目中的被測類時，會先使用CKJM⑤http://gromit.iiar.pwr.wroc.pl/p_inf/ckjm/擴展庫，利用McCabe 圈復雜度來計算所有類文件的圈復雜度，排除那些只包含圈復雜度低于3 的方法的類，保證被測類包含至少有2 個分支的方法。考慮到實驗需要花費的時間，不會使用所有的類文件，而是從滿足復雜度的類文件中隨機采樣，選取最終的被測類。使用上述方法，最終從GitHub 中選取了15 個關注度較高、使用廣泛且應用領域類型豐富的Java 開源項目，經過采樣后最終得到130 個被測類。具體信息如表1 所示。

表1 實驗項目及被測類信息

為了方便進行實驗，這里借助了SBST 公開的最新版本競賽框架（v1.0.1）。按照使用要求，將EvoSuite 和被測類放在指定目錄，并設定好必要的環境變量和參數，該框架就可以自動執行完整的實驗流程，無需人工干預。

考慮到實驗所需時間以及排除無關因素的影響，本實驗搭建了一臺安裝Ubuntu 16.04.6 LTS 操作系統的虛擬機，分配3 個CPU 內核（物理主機CPU 為第八代Intel Core i5-8500B 六核處理器，3.0GHz），8G 內存，60G SSD，并且只安裝必要軟件。

1.3 實驗步驟

實驗基本流程如圖1 所示。

圖1 實驗基本流程

具體步驟如下：

（1）前期準備。準備運行環境，選取被測類文件，配置EvoSuite 并做調試。

（2）測試用例生成。針對每個被測類，設置不同的生成時間，多次運行EvoSuite，每次生成一組包含若干測試用例的測試套件。參考近3 年SBST 比賽的時間設定和計算資源，本文選擇10、60、120、240 秒這4 種生成時間，針對每個被測類執行3 次EvoSuite。同時，實際運行EvoSuite 可能會超過設定的生成時間，為了不強制終止其運行，允許最多有比設定的生成時間多一倍的實際運行時間。

（3）測試用例檢查。如前所述，EvoSuite 可能會生成不可編譯和不穩定的測試用例，并在生成測試用例的最后階段進行檢查和處理。實驗框架也包含了檢查測試用例是否可用的環節，會記錄并注釋掉不可編譯和不穩定測試。

（4）計算效度指標。這里會同時計算由工具生成的經上一步驟處理后的測試套件和可用的手工測試套件的效果指標，具體來說：使用JaCoCo⑥https://github.com/EvoSuite/evosuite/releases計算測試套件的代碼覆蓋率，包括行覆蓋和分支覆蓋；使用PITest⑦http://gromit.iiar.pwr.wroc.pl/p_inf/ckjm/對這些測試套件進行變異分析。

（5）結果分析討論。根據上述步驟獲得的效果指標、生成測試套件時是否超時、生成的可用測試比例等多種數據，結合具體的被測項目，進行分析討論。

1.4 實驗效度

本實驗使用多種手段保證有效性。實驗環境為全新搭建的虛擬環境，只安裝必要的實驗相關軟件，保證實驗過程不受其他程序影響。選擇被測項目時，在條件允許的情況下，選取了盡量多的項目，并保證項目的多樣性。選取被測類時，在滿足復雜度的條件下，各個項目隨機選取一定數量的被測類，確保整體上分布均勻。實驗中使用的框架經過了近幾年SBST 競賽的使用而不斷完善，實驗過程基本上都是自動化執行，避免了人為干擾。在計算測試套件的覆蓋率和變異分數時，使用了常用的比較成熟可靠的工具[9,10]，保證計算結果的準確。

2 實驗結果分析與討論

2.1 實驗結果

實驗中，EvoSuite 共運行1560 次來生成測試用例（4 種生成時間，130 個被測類，每個被測類上運行3次）。對于每個被測類，整理并記錄了不同生成時間下EvoSuite 的實際運行時間和生成的測試用例的行覆蓋率、分支覆蓋率和變異分數，結果匯總如表2 所示。其中“-”表示未能生成任何測試用例。這里只展示了每個項目中選取的前兩個被測類的數據，完整數據可以在GitHub 倉庫⑧https://github.com/HsingYue/EvoSuite-evaluation中查看。

表2 實驗結果匯總（部分）

2.2 分析與討論

（1）EvoSuite 運行的穩定性。

查看所有運行結果，發現在面對13 個被測類時，共有102 次生成失敗，占總次數的6.54%，基本情況如表3 所示。

表3 生成失敗情況匯總

總體來看，EvoSuite 在超過93%的運行中都生成了測試套件，穩定性在可接受的范圍。具體分析那些生成失敗的情況。對于被測類JXPATH-7，EvoSuite 每次運行都未能生成任何測試用例。通過過程數據發現，每次都會出現運行時異常java.lang.VerifyError。分析異常信息，發現該異常出現在字節碼插裝階段。由于EvoSuite 使用字節碼插裝來模擬外部對象，增加了被插裝方法的大小，使其超出了Java 對方法字節碼大小的限制（64KB）。EvoSuite 在被測類OKHTTP-5、DUBBO-2 和WEBMAGIC-4 上也未生成任何測試用例。這是由于這些類缺失依賴項，EvoSuite 會中止運行并拋出錯誤來通知用戶。對于REDISSION 項目中的被測類，大多數生成失敗是由于運行超時，目前還未找到具體原因。

（2）生成時間對測試用例的可用性、覆蓋率和揭錯能力的影響。

表4 顯示了設定不同生成時間時，EvoSuite 實際的運行時間情況（不考慮生成失敗的情況）。其中，超時次數（嚴格）是指超過了設定的生成時間，而超時次數（寬容）是指在原設定時間的基礎上增加6 秒后，實際運行超過該時間的次數。之所以這樣考慮，是因為如前面所說，EvoSuite 會將運行分成6 個階段，連續兩個階段的運行之間還需要一定的切換時間。根據之前的研究[5]，這些切換時間總共約6 秒，而目前的EvoSuite未將切換時間計入設定的分配時間中，因此考慮寬容的超時次數和超時率更合理。可以發現，設定生成時間為10 秒時，EvoSuite 極容易出現運行超時的情況，超時率（寬容）高達61.3%。當生成時間設定為60 秒及以上時，超時率（寬容）大幅下降，均不到5%。

表4 EvoSuite 實際（成功）運行時間

生成成功的測試用例中有一些不可用測試用例（包括不可編譯測試和不穩定測試），占比不到1%，即EvoSuite 成功運行生成的測試用例的可用性高達99%。這是由于EvoSuite 使用了多種技術手段來避免許多不穩定測試的出現[14]，又在生成測試用例的最后階段進行檢查，注釋掉不可用測試，所以最終輸出的測試用例中包含的不可用測試比例非常低.。之所以還會出現，一般都是由于運行超過了分配的時間而停止檢查所致。例如，FREEHEP-7，JXPATH-10 和FASTJSON-4 是在一次運行中出現最多數量的不穩定測試（分別為12、14 和12 個）的被測類。對于這三個項目，測試用例生成的精簡測試階段都會超時，因此會遺留數量較多的測試用例，這可能導致更大概率出現不穩定測試。

競賽框架最終計算得到了不同生成時間下，Evo-Suite 生成的測試套件的行覆蓋率、分支覆蓋率和變異分數，這些效果指標的整體變化情況（以均值表示）如圖2 所示。

圖2 不同生成時間下的測試套件整體效果指標

觀察圖2 中三個效果指標與生成時間的變化關系，明顯看出代碼行覆蓋率、分支覆蓋率和變異分數均隨生成時間增長而增長，這也符合預期。從表5 中可以看出，當生成時間從10 秒增加到60 秒時，三個指標均增長了15.5%左右，但相比于10 秒時的數值，變化率非常大，尤其是變異分數，變化率高達71.8%；從60秒增加到120 秒時，三個指標均有約8%的增長，相比于10 秒到60 秒的時間變化，增長率小了很多，但增長率仍然很可觀；當從120 秒增加到240 秒時，增長明顯放慢，三個指標的增長量均為3.5%左右，增長率也都不超過7%。這說明在本文選擇的4 個生成時間下，120 秒的時間收益較高，而繼續增加生成時間雖然也會帶來效果指標的提升，但要放緩許多。另外隨著代碼覆蓋率的提高，變異分數也在提高，這也與已有研究中的經驗證據一致[11]。

表5 生成時間變化時測試用例各效果指標的變化

通過上述分析可以發現，在面對大多數項目時，分配給EvoSuite 生成測試用例的時間不能太短（尤其是時間要求相對嚴格的情況下），至少應該有1 分鐘，這樣才能保證生成測試用例的每個階段都完全執行，得到的測試用例的可用性、覆蓋率和變異分數也會更好。

（3）自動生成的測試用例與手工測試用例的效果比較。

為了比較EvoSuite 生成的測試用例與手工編寫的測試用例的差距，實驗中也對可用的手工測試用例進行了效果指標的計算。在所選項目中，包含手工測試用例的被測類共有36 個。同時，也選擇了這些被測類在生成時間為240 秒時，3 次運行EvoSuite 中某一次生成的測試用例來進行比較，因為根據前面的實驗結果，此時得到的測試用例效果相對最優。圖3 展示了手工測試用例和生成的測試用例的分支覆蓋率（相比于行覆蓋率，在邏輯上更有意義）和變異分數的分布差異。可以發現，對于分支覆蓋率，EvoSuite 生成的測試用例更為分散一些；對于變異分數，手工測試用例整體的效果要明顯好于生成的測試用例了。

圖3 兩類測試用例的分支覆蓋率和變異分數的分布差異

經過計算，對于分支覆蓋率，手工測試套件的均值為66.2%，對應的生成的測試套件均值為63.4%；對于變異分數，手工測試套件的均值為61.9%，對應的生成的測試套件均值為46.7%。這里使用Vargha-Delaney A 檢驗方法[3]進行度量。Vargha-Delaney A 檢驗是一種非參數統計檢驗方法，可以定量的對兩類測試套件的效果差異的顯著性進行評估。也就是說，通過該方法可以分析生成測試套件的效果與手工測試套件的效果相比是否有明顯差異，如果有的話，能達到什么程度。在這里，零假設是指生成測試與手工測試相比效果無差異；備擇假設則是生成測試與手工測試相比效果有差異。在顯著性水平為0.05 時，如果A12 偏離0.5 越遠，表示生成測試與手工測試的效果差異越大。根據經驗[11]，Vargha 和Delaney 建議，A12 大于0.64 或小于0.36 時，表示差異達到中等程度，如果大于0.71 或小于0.29，表示差異很大。基于之前的分析，這里選取生成時間為240 秒的分支覆蓋和變異分數，因為在這個時間點，二者的值都趨于穩定。在實驗中，對于分支覆蓋率，生成的測試套件與手工測試套件的A12 為0.45，p為0.367，無重大差異；對于變異分數，生成測試套件與手工測試套件的A12 為0.31，p 值小于0.001，差異很大，手工測試套件的變異分數優于生成測試套件很多。

以上結果表明，對于分支覆蓋，EvoSuite 生成的測試套件與手工測試套件的差異很小，有時候生成測試套件的分支覆蓋率甚至會超過手工測試套件；但是對于變異分數，二者的差異很大。變異分數較高的測試套件更容易發現因修改代碼而引入的新的錯誤。因此，EvoSuite 生成的測試套件在揭錯能力上還與手工測試套件有較大差距。

2.3 一些建議

經過實驗與分析討論，這里對EvoSuite 的使用和改進提出一些建議。

首先，在生成測試用例時，用戶要保證被測類的依賴項都存在，否則會生成失敗。其實可以使用更加靈活的策略來提高運行穩定性，例如對于那些缺失依賴的類，EvoSuite 也可以在執行時不直接中止，而是忽略此類錯誤，并嘗試利用可以找到的依賴項盡量生成不完全的測試用例。另外，當面對少數很“龐大”的方法，EvoSuite 可以在字節碼插裝時進行一些判斷，一個方案是動態識別代碼易產生不穩定測試用例的部分進行插裝，并監測被插裝方法大小，在達到大小限制之前停止。在測試用例精簡階段，EvoSuite 可以考慮其他更高效的精簡方法，例如delta-調試[12]。

然后，在實際使用EvoSuite 時，最優的時間選擇是120 秒，能在相對較短的時間內獲得效果相對很好的測試套件；如果時間比較緊迫，想在較短的時間內生成效果最好的測試套件，那就盡量讓生成時間達到60 秒或以上；如果在特殊情況下時間過于緊迫，生成時間達不到60 秒，那就分配盡量長的時間；如果時間充裕，可以選擇240 秒，能得到接近最優的測試套件；如果時間非常充裕，也可以設定生成時間在240 秒以上，雖然說生成時間越長，得到的單元測試套件效果越好，但此時生成時間增加帶來的效果提升非常有限。另外，在設定小于60 秒這樣較短的生成時間時，EvoSuite 容易超時。為保證正常生成測試套件，即使超時也盡量等待程序自己運行結束，而不要外部強制終止。考慮到超時問題，還是建議選取120 秒左右的生成時間。

最后，如果只是想在較短時間內生成具有較高行覆蓋率和分支覆蓋率的測試套件，EvoSuite 足夠勝任，甚至比開發人員做得更好。但考慮到揭錯潛力，這些生成的測試套件還遠不能替代手工測試套件，而考慮到EvoSuite 生成的測試用例是應用于回歸場景的，這點尤為重要了。

3 結語

關于EvoSuite 的研究，還有很多值得進一步做的工作。對于EvoSuite 的使用，可以設定更多、更細粒度的生成時間來找到更精確的最優時間。在數據集上，可以選取更大樣本的被測類，如果有條件，甚至可以與企業合作，在真實的商業軟件上使用EvoSuite。這樣可以增加實驗的外部效度，使結論的適用范圍更加廣泛。對于實驗中發現的一些問題，EvoSuite 還需繼續完善，例如說，以更聰明的方式進行字節碼插裝；生成測試時使用更高效的精簡測試的算法；進一步提升生成測試的變異分數，減少與手工測試的效果差異等。