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

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

版塊 |鑒源論壇 · 觀模

社群 |添加微信號(hào)“TICPShanghai”加入“上海控安51fusa安全社區(qū)”

01

應(yīng)用程序編程接口（API）

應(yīng)用程序編程接口，英文全稱為Application Programming Interface[7]（簡(jiǎn)稱API），是一組定義了軟件組件如何互相通信和交互的規(guī)則和協(xié)議。和用戶接口（User Interface，簡(jiǎn)稱UI）不同，API的目的是連接不同的軟件，允許不同的軟件應(yīng)用程序之間共享功能和數(shù)據(jù)，而無需了解其內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。

API的表現(xiàn)形式一般是使用某種編程語言編寫的函數(shù)（function）或者數(shù)據(jù)結(jié)構(gòu)（data structure）。對(duì)一個(gè)應(yīng)用程序中的編程接口進(jìn)行定義和說明的文檔被稱為API規(guī)格說明（API specification）。公開的API和其對(duì)應(yīng)的規(guī)格說明使得該應(yīng)用程序開發(fā)者之外的開發(fā)人員能夠調(diào)用這些API，并通過新編寫的軟件邏輯實(shí)現(xiàn)新功能或者對(duì)原有功能進(jìn)行擴(kuò)展。這使得開發(fā)人員能夠構(gòu)建更加模塊化、可擴(kuò)展和可重用的軟件。API在現(xiàn)代軟件開發(fā)中起著重要作用，它們促進(jìn)了分布式系統(tǒng)、微服務(wù)架構(gòu)和應(yīng)用程序集成。通過使用API，開發(fā)人員可以利用現(xiàn)有功能，加快開發(fā)速度，提高代碼的可維護(hù)性和可重用性。

02

自動(dòng)化API測(cè)試

隨著軟件技術(shù)的發(fā)展，由于軟件結(jié)構(gòu)的高度復(fù)雜和軟件開發(fā)周期的不斷縮短，為了確保應(yīng)用程序的質(zhì)量和安全，API自身的功能正確性和使用安全性越來越重要，能快速有效地對(duì)API進(jìn)行測(cè)試是關(guān)鍵。API測(cè)試是一種直接對(duì)API進(jìn)行測(cè)試的軟件測(cè)試技術(shù)，主要用于保證開發(fā)人員所編寫的API滿足給定的功能目標(biāo)、性能目標(biāo)和安全目標(biāo)。

現(xiàn)代軟件的架構(gòu)大部分采用模塊化和分層化的模式，各模塊和層次之間通過API進(jìn)行功能交互和數(shù)據(jù)傳輸。當(dāng)某個(gè)模塊或者軟件層提供的API存在軟件錯(cuò)誤（bug），那么依賴該模塊或者該軟件層的其他模塊和軟件層自身功能也將出現(xiàn)錯(cuò)誤。最壞情況下可能導(dǎo)致應(yīng)用程序整體出錯(cuò)，影響用戶使用體驗(yàn)，危害用戶數(shù)據(jù)安全。因此，API測(cè)試是非常必要且需要重視的一個(gè)軟件開發(fā)流程階段。當(dāng)API測(cè)試足夠充分并且結(jié)果表明被測(cè)API正確無誤時(shí)，使用這些API構(gòu)建的應(yīng)用程序或者程序功能才有基礎(chǔ)的質(zhì)量和安全保障。

從最初的軟件開發(fā)瀑布模型（Waterfall model）到時(shí)下流行的敏捷開發(fā)（Agile development）和DevOps，軟件開發(fā)周期不斷縮短，使得如何高效保障應(yīng)用程序的質(zhì)量和安全受到更多的關(guān)注，也就催生了自動(dòng)化測(cè)試（Automated testing）。API測(cè)試也順勢(shì)進(jìn)入自動(dòng)化時(shí)代。從通用自動(dòng)化API測(cè)試技術(shù)（如單元測(cè)試、模糊測(cè)試）到特定編程語言的測(cè)試框架（如pytest[9]、JUnit[10]），從傳統(tǒng)的應(yīng)用程序編程庫（library）API測(cè)試到Web場(chǎng)景下的RESTful API測(cè)試，自動(dòng)化API測(cè)試技術(shù)得到廣泛發(fā)展。

03

自動(dòng)化API測(cè)試對(duì)象

自動(dòng)化API測(cè)試的對(duì)象目前主要分為兩種：函數(shù)級(jí)API（Function-level API）和RESTful API。前者是傳統(tǒng)的程序編程庫（或者稱為第三方庫）或者系統(tǒng)庫中為開發(fā)者提供的API接口，需要開發(fā)者在軟件代碼中實(shí)際調(diào)用才能夠發(fā)揮作用。后者則是在Web和云場(chǎng)景下廣泛使用的具有REST規(guī)范的API，一般以客戶端向服務(wù)器發(fā)起HTTP請(qǐng)求的形式呈現(xiàn)。對(duì)兩者進(jìn)行自動(dòng)化測(cè)試在形式上相同，都需要測(cè)試人員編寫特定的測(cè)試驅(qū)動(dòng)進(jìn)行API調(diào)用來完成測(cè)試，測(cè)試的重要內(nèi)容也都是檢查API調(diào)用的執(zhí)行結(jié)果是否符合預(yù)期以及API執(zhí)行過程中是否出現(xiàn)錯(cuò)誤。而不同之處在于，函數(shù)級(jí)API通常運(yùn)行在本地環(huán)境，而RESTful API運(yùn)行在云端環(huán)境，API的調(diào)用形式不同，整體的交互環(huán)境和測(cè)試框架也有所差異。

3.1函數(shù)級(jí) API

函數(shù)級(jí)API（Function-level API）主要是指庫API和系統(tǒng)調(diào)用。一般軟件開發(fā)過程中，開發(fā)人員編寫的單個(gè)函數(shù)或者軟件模塊中暴露的API接口也屬于函數(shù)級(jí)API范疇。對(duì)于這一類API的自動(dòng)化測(cè)試主要通過由開發(fā)人員編寫的或者自動(dòng)生成的測(cè)試驅(qū)動(dòng)（test driver）完成。

庫API指的是SDK（Software Development Kit）、標(biāo)準(zhǔn)庫（Standard libraries）和第三方庫（Third-party libraries）開放給軟件開發(fā)人員調(diào)用的函數(shù)，如Android SDK和Python官方標(biāo)準(zhǔn)庫中的API。庫API通常是構(gòu)建整個(gè)應(yīng)用程序的基礎(chǔ)，軟件提供給用戶的各種高級(jí)功能都將通過調(diào)用已有API或者組合已有API的方式實(shí)現(xiàn)，因此庫API的正確性和安全性不言而喻。

系統(tǒng)調(diào)用（syscall）指的是操作系統(tǒng)中提供給開發(fā)人員進(jìn)行用戶空間和系統(tǒng)內(nèi)核進(jìn)行交互的接口，用于訪問底層的操作系統(tǒng)功能，如Linux中的open、malloc和fork。

3.2RESTful API

RESTful API通過直觀簡(jiǎn)短的統(tǒng)一資源標(biāo)識(shí)符（URI）定義資源，通過JSON、XML等文件格式進(jìn)行數(shù)據(jù)傳輸。RESTful API使用基于HTTP動(dòng)詞的語義的操作來操作這些資源，例如GET、POST、DELETE和PUT。在處理HTTP請(qǐng)求期間，API可能需要從數(shù)據(jù)庫讀取/寫入數(shù)據(jù)，并與其他web服務(wù)通信。測(cè)試RESTful API不僅需要為不同的端點(diǎn)編寫HTTP消息，還需要選擇正確的查詢參數(shù)，以及正文有效載荷消息。

本文系統(tǒng)介紹了應(yīng)用程序編程接口（API）的概念及其在軟件開發(fā)中的作用與重要性，重點(diǎn)分享自動(dòng)化API測(cè)試的發(fā)展歷程與測(cè)試對(duì)象。后續(xù)，在基于應(yīng)用程序編程接口（API）的自動(dòng)化測(cè)試（下）中，筆者將深入剖析單元測(cè)試、模糊測(cè)試等當(dāng)前主流的自動(dòng)化API測(cè)試形式與技術(shù)。

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

[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

審核編輯 黃宇