作者 |黃杉華東師范大學(xué)軟件工程學(xué)院博士

蘇亭 華東師范大學(xué)軟件工程學(xué)院教授

版塊 |鑒源論壇 · 觀模

社群 |添加微信號“TICPShanghai”加入“上?？匕?1fusa安全社區(qū)”

上文“基于應(yīng)用程序編程接口（API）的自動化測試（上）”中，系統(tǒng)介紹了應(yīng)用程序編程接口（API）的概念及其在軟件開發(fā)中的作用與重要性，重點分享自動化API測試的發(fā)展歷程與測試對象。

本文將深入剖析單元測試、模糊測試等當(dāng)前主流的自動化API測試形式與技術(shù)。

04

自動化API測試形式與技術(shù)

對API進行自動化測試一般使用單元測試（Unit testing）的測試形式，這也是當(dāng)下敏捷開發(fā)的重要組成部分。隨著模糊測試的興起，針對API的模糊測試（API fuzzing）成為當(dāng)下流行的API測試技術(shù)。下面將從單元測試和模糊測試兩部分對自動化API測試形式和技術(shù)進行介紹。

4.1單元測試（Unit Testing）

單元測試（Unit Testing）又稱為模塊測試，是一種測試形式（或稱測試框架），它針對程序模塊（軟件設(shè)計的最小單位）來進行正確性檢驗的測試工作。程序單元是應(yīng)用的最小的測試部件。在過程化編程中，單元測試由單個API或者多個API組合完成；對于面向?qū)ο缶幊?，單元測試由單個或者多個類的方法以及對象之間的交互操作完成。單元測試主要由開發(fā)人員手動編寫（如Junit、pytest），也可以通過一些自動測試用例生成技術(shù)（如Randoop[6]、GraphFuzz[4]）完成。

單元測試的一般流程為：（1）編寫或生成單元測試用例，其中包含測試環(huán)境初始化、調(diào)用被測API完成相應(yīng)功能、檢查調(diào)用結(jié)果；（2）執(zhí)行單元測試用例，收集執(zhí)行結(jié)果，統(tǒng)計成功的測試用例和失敗的測試用例，失敗的測試用例表明API實現(xiàn)中存在錯誤或缺陷。無論是函數(shù)級API還是RESTful API，使用單元測試這種測試形式都十分有效。

圖 1 Junit單元測試示例

如圖 1所示，這是一個使用Junit單元測試框架編寫的Java單元測試用例。“@Test”表示該函數(shù)執(zhí)行一個單元測試用例，其中首先初始化一個AdderImpl對象，并調(diào)用該對象的add方法，傳入1和2這兩個參數(shù)，最終判斷add方法的返回結(jié)果是否為3。如果結(jié)果不為3，則該單元測試失敗，表示add方法實現(xiàn)出錯，反則成功。

4.2API模糊測試 （Fuzz Test）

模糊測試（Fuzz test）是一種自動化測試技術(shù)，其核心組件模糊器（Fuzzer）可以基于語法規(guī)則直接生成測試用例，也可以基于已有測試用例進行編譯生成測試用例。由于模糊器可以生成多樣的測試用例，這些測試用例相比于開發(fā)人員編寫的測試更有可能觸發(fā)程序中的邊界條件和更多樣的測試場景，因此模糊測試在測試軟件魯棒性和軟件漏洞挖掘中非常有效。

針對API的模糊測試流程和一般針對二進制程序的模糊測試流程相同：模糊器從種子庫中選取種子進行變異或者直接根據(jù)語法規(guī)則生成測試用例，執(zhí)行測試用例，監(jiān)測執(zhí)行過程并檢查執(zhí)行結(jié)果，當(dāng)執(zhí)行過程中出現(xiàn)崩潰或者執(zhí)行結(jié)果與預(yù)期不符，則認為找到了潛在的API錯誤。

4.2.1 針對函數(shù)級API的模糊測試

LLVM項目中的Libfuzzer[11]是一款進程內(nèi)的由覆蓋率引導(dǎo)的進化型模糊引擎。它通過讀取用戶提供的種子（特定的程序輸入或者API調(diào)用參數(shù)），對種子進行變異生成新的測試用例輸入并傳遞給由用戶編寫的測試驅(qū)動，從而實現(xiàn)API模糊測試。

圖 2 Libfuzzer測試驅(qū)動示例

圖 2是一個Libfuzzer測試驅(qū)動示例，Libfuzzer生成的測試輸入將通過Data參數(shù)傳入測試驅(qū)動，用戶則會將該測試輸入在經(jīng)過適當(dāng)處理后傳遞給被測API，從而對API進行測試。值得注意的是，在Libfuzzer的測試驅(qū)動中，開發(fā)人員同樣可以編寫條件檢查來達到單元測試的效果。

Libfuzzer初步解決了測試輸入生成，而對API的模糊測試難點在于如何觸發(fā)更深層次的API行為。為了更高效地對函數(shù)級API進行測試，研究人員們對如何高效地自動化生成測試驅(qū)動進行了研究，即如何自動化地構(gòu)造有效的API調(diào)用序列和API執(zhí)行環(huán)境和程序片段。

FUDGE[2]是一個通過對代碼切片進行合成來生成模糊測試候選驅(qū)動的工具。FUDGE的核心見解是，以有效且有用的方式執(zhí)行庫函數(shù)的模糊測試驅(qū)動可以通過代碼庫中的現(xiàn)有代碼片段合成。FUDGE的整體流程如圖 3所示，在完成模糊測試驅(qū)動生成后，F(xiàn)UDGE會將生成的驅(qū)動交給開發(fā)人員進行評估。

圖 3 FUDGE整體流程

FuzzGen[5] 利用整個系統(tǒng)分析來推斷庫的接口并專門為該庫合成模糊測試驅(qū)動。FuzzGen不需要開發(fā)人員的參與，并且可以廣泛應(yīng)用于多種編程庫。FuzzGen的核心思想是系統(tǒng)中的現(xiàn)有代碼在多個方面利用編程庫。如圖 4所示，它從系統(tǒng)中已有使用庫的代碼出發(fā)，通過對整個系統(tǒng)進行分析，先確定哪些是API，再從控制流和數(shù)據(jù)流兩方面整理出抽象API依賴圖(A2DG)。這個過程需要確定每個參數(shù)的可能值和類型，并分析參數(shù)之間的依賴關(guān)系。最后，基于依賴圖生成libFuzzer的樁代碼，從而進行不需人工干預(yù)、能較好地平衡寬度和深度的模糊測試。

圖 4 FuzzGen的核心思想示意圖

GraphFuzz[4]則是通過將整個API調(diào)用序列表示為一個數(shù)據(jù)流圖，然后在數(shù)據(jù)流圖中進行給定的變異操作進行API調(diào)用序列構(gòu)造。圖 5列舉了三種GraphFuzz支持的數(shù)據(jù)流圖變異操作：刪除、插入和串聯(lián)。

圖 5 GraphFuzz支持的部分變異操作

除了泛用性的針對函數(shù)級API的模糊測試方法的研究工作外，還有特別針對系統(tǒng)調(diào)用的模糊測試方法的研究工作，這些研究工作都著力于解決如何構(gòu)造API調(diào)用能夠探索更深層次的API使用場景這一挑戰(zhàn)。

4.2.2 針對RESTful API的模糊測試

早期Chakrabarti[3]等人提出了黑盒的、基于規(guī)范的RESTful API測試方法，其中測試用例需要使用一種基于XML的可擴展測試規(guī)范語言進行手工構(gòu)造。但手工構(gòu)造測試用例需要較多的人工開銷，后來的工作通過從OpenAPI或者Swagger規(guī)范中提取RESTful API的接口信息，從而實現(xiàn)了測試用例的自動化生成。

EvoMaster[8]是一個使用進化算法來生成RESTful API測試用例的基于搜索的模糊測試工具，這也是一款完全自動化的黑盒測試工具。它在測試RESTful服務(wù)內(nèi)部更深層次的邏輯方面更有效，因為它可以搜集和使用有關(guān)服務(wù)目標(biāo)的更多信息來指導(dǎo)測試用例生成。

RESTler[1]是第一個有狀態(tài)基于廣度優(yōu)先探索的RESTful API模糊測試器。RESTler 通過分析云服務(wù)的 API 規(guī)范，生成請求序列并自動調(diào)用云服務(wù)的API對其測試。RESTler首先會通過讀取Swagger接口文檔（圖 6給出了Swagger接口文檔的示例）對API返回結(jié)果之間的依賴關(guān)系進行推斷，然后生成合法的API調(diào)用序列。然后，RESTler會根據(jù)執(zhí)行API調(diào)用序列過程中服務(wù)器返回的狀態(tài)碼來修改原有的API調(diào)用序列，使其避免生成無效的API調(diào)用序列。

圖 6 Swagger接口文檔示例

05

總結(jié)

自動化API測試有較長的歷史，其自身也在不斷演化進步。針對函數(shù)級API的自動化測試在泛用方法研究的基礎(chǔ)上，目前也出現(xiàn)了一些針對特殊編程語言和特殊API場景的研究，如針對Rust library和深度學(xué)習(xí)庫（PyTorch、TensorFlow）的自動化測試方法研究。針對RESTful API的自動化測試也是繼SOAP測試之后出現(xiàn)的web API測試新種類。隨著軟件工程技術(shù)的發(fā)展，API也在不斷進化，如何根據(jù)不同API自身特點制定相對應(yīng)的自動化測試方案將會是自動化API測試重點關(guān)注的核心問題。

參考文獻：

[1] Vaggelis Atlidakis, Patrice Godefroid, and Marina Polishchuk. 2019. RESTler: Stateful REST API Fuzzing. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), 748–758.

[2] Domagoj Babi?, Stefan Bucur, Yaohui Chen, Franjo Ivan?i?, Tim King, Markus Kusano, Caroline Lemieux, László Szekeres, and Wei Wang. 2019. FUDGE: fuzz driver generation at scale. In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2019), Association for Computing Machinery, New York, NY, USA, 975–985.

[3] Sujit Kumar Chakrabarti and Prashant Kumar. 2009. Test-the-REST: An Approach to Testing RESTful Web-Services. In 2009 Computation World: Future Computing, Service Computation, Cognitive, Adaptive, Content, Patterns, 302–308.

[4] Harrison Green and Thanassis Avgerinos. 2022. GraphFuzz: Library API Fuzzing with Lifetime-aware Dataflow Graphs. In 2022 IEEE/ACM 44th International Conference on Software Engineering (ICSE), 1070–1081

[5] Kyriakos Ispoglou, Daniel Austin, Vishwath Mohan, and Mathias Payer. 2020. {FuzzGen}: Automatic Fuzzer Generation. 2271–2287. Retrieved July 5, 2023

[6] Carlos Pacheco, Shuvendu K. Lahiri, Michael D. Ernst, and Thomas Ball. 2007. Feedback-Directed Random Test Generation. In 29th International Conference on Software Engineering (ICSE’07), IEEE, Minneapolis, MN, USA, 75–84. D

[7] 2023. API. Wikipedia. Retrieved August 16, 2023

[8] 2023. EvoMaster: A Tool For Automatically Generating System-Level Test Cases. Retrieved August 16, 2023

[9] pytest: helps you write better programs — pytest documentation. Retrieved August 16, 2023[10] JUnit 5. Retrieved August 16, 2023

[11] libFuzzer – a library for coverage-guided fuzz testing. — LLVM 18.0.0git documentation. Retrieved August 16, 2023

審核編輯 黃宇