基于應(yīng)用程序編程接口（API）的自動(dòng)化測(cè)試（下）

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

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

版塊 |鑒源論壇 · 觀模

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

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

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

04

自動(dòng)化API測(cè)試形式與技術(shù)

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

4.1單元測(cè)試（Unit Testing）

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

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

圖 1 Junit單元測(cè)試示例

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

4.2API模糊測(cè)試 （Fuzz Test）

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

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

4.2.1 針對(duì)函數(shù)級(jí)API的模糊測(cè)試

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

圖 2 Libfuzzer測(cè)試驅(qū)動(dòng)示例

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

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

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

圖 3 FUDGE整體流程

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

圖 4 FuzzGen的核心思想示意圖

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

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

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

4.2.2 針對(duì)RESTful API的模糊測(cè)試

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

EvoMaster[8]是一個(gè)使用進(jìn)化算法來生成RESTful API測(cè)試用例的基于搜索的模糊測(cè)試工具，這也是一款完全自動(dòng)化的黑盒測(cè)試工具。它在測(cè)試RESTful服務(wù)內(nèi)部更深層次的邏輯方面更有效，因?yàn)樗梢运鸭褪褂糜嘘P(guān)服務(wù)目標(biāo)的更多信息來指導(dǎo)測(cè)試用例生成。

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

圖 6 Swagger接口文檔示例

05

總結(jié)

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

參考文獻(xià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

審核編輯 黃宇