REST API自動化測試綜述

陳靜 魏強 武澤慧 王新蕾

收稿日期：2023-05-08；修回日期：2023-07-17? 基金項目：國家重點研發計劃資助項目（2019QY0501）

作者簡介：陳靜（1999—），女，河南許昌人，碩士研究生，主要研究方向為軟件安全分析；魏強（1979—），男（通信作者），江西南昌人，教授，博導，博士，主要研究方向為軟件安全分析與工控系統安全（1219683194@qq.com）；武澤慧（1988—），男，安徽臨泉人，講師，博士，主要研究方向為軟件與系統漏洞分析；王新蕾（1990—），女，河南內黃人，主要研究方向為軟件安全分析.

摘? 要：REST API已經成為訪問和使用云服務、Web、移動應用程序的重要途徑，如何對這些API進行自動化測試以保證服務的安全性和可靠性是亟待解決的問題。目前雖然關于REST API自動化測試的研究成果眾多，但仍缺少對測試技術全面的分析和總結。梳理了該領域近10年的代表性成果，首先總結了REST API自動化測試的發展歷程；然后結合REST API自動化測試特征，提煉了測試的通用流程；接著分別從預處理、測試用例生成、測試用例執行與監測、結果分析四個環節闡述現有成果的技術特征，對比分析其優缺點；最后論述當前研究存在的不足，討論可能的解決思路，展望了下一步研究方向。

關鍵詞：REST API；自動化測試；模糊測試；測試用例生成

中圖分類號：TP311??? 文獻標志碼：A

文章編號：1001-3695（2024）02-001-0321-08

doi：10.19734/j.issn.1001-3695.2023.05.0230

Survey of REST API automation testing

Chen Jing1，2，Wei Qiang2，Wu Zehui2，Wang Xinlei2

（1.School of Cyber Science and Engineering，Zhengzhou University，Zhengzhou 450001，China；2.Information Engineering University，Zhengzhou 450001，China）

Abstract：The REST API has become an important way to access and use cloud services，Web，and mobile applications.It is urgent to solve the problem of how to carry out automated testing on these APIs to ensure the security and reliability of ser-vices.Although there are numerous research results on REST API automation testing，there is still a lack of comprehensive analysis and summarization of testing techniques.This paper firstly summarized the development history of REST API automation testing，then refined the general process of testing by combining the features of REST API automation testing.Next，this paper elaborated the technical features of existing achievements from four aspects：pre-processing，test case generation，test case execution and monitoring，and result analysis，and compared and analyzed their advantages and disadvantages.Finally，it discussed the shortcomings of the current research，proposed possible solutions，and explored the next research direction.

Key words：REST API；automated testing；fuzzing；test case generation

0? 引言

應用程序編程接口（application programming interface，API）是一種計算接口，它通過定義一組函數、協議和數據結構，使得多個軟件應用程序之間能夠互相通信、交換數據［1］。表述性狀態傳遞（representational state transfer，REST）是Fielding博士［2］在2000年提出的一種分布式超媒體系統的架構風格，符合這種設計風格的API即為REST API。隨著云計算的快速發展和微服務架構［3］的廣泛采用，REST API因簡潔易用，在降低軟件開發復雜度的同時還能夠提升軟件應用的拓展性等特征，目前已成為訪問Web應用程序和云服務的主要方式。多數Web服務提供商（如Google、Twitter和Amazon）都公開使用REST API來授予對其應用程序或服務的訪問權，然而，近年來API問題頻發。2020年，美國開放銀行應用Dave的700萬用戶信息泄露，并在黑客平臺被販賣。2021年，Facebook某在線業務的API遭到誤用，造成5億條用戶信息泄露。因此保證API的安全性和可靠性至關重要。

API測試是API開發生命周期中重要的組成部分，也是確保業務邏輯的功能性、可靠性、安全性和交付的關鍵環節。傳統的手工測試效率低，且難以實現回歸測試［4］。自動化測試可以減少測試人員的重復工作，提升測試效率。研究人員先后提出多種用于REST API自動化測試和漏洞發現的方法和技術，根據測試過程中所需的輸入信息或對程序內部信息分析的程度，可將這些方法分為黑盒測試、白盒測試和灰盒測試三大類。黑盒測試不知道目標服務的內部執行狀態，通常利用REST API的輸入格式或不同的輸出響應來優化測試，其中代表性的工作包括RESTler［5］、foREST［6］、RestTestGen［7］、MOREST［8］和RestCT［9］等。白盒測試獲得了執行的所有內部信息，常采用基于搜索的測試用例生成策略，系統地探索目標程序的狀態空間，其中代表性工作包括EvoMASTER［10］等?；液袦y試可以獲取程序執行的部分信息，現有研究往往采用代碼覆蓋率作為程序執行反饋信息指導生成有效的輸入，其中代表性工作包括Pythia［11］。關于REST API自動化測試的研究眾多，但是相關的綜述性文章較少，而且沒有對REST API的通用測試流程進行提煉和體系化的技術分析。文獻［12］根據工具、方法和框架對REST API測試進行了分類，但僅僅討論了實現代碼高覆蓋率存在的主要障礙，其綜述內容不夠全面。文獻［13］對比了10個先進的REST API測試工具，根據實現的代碼覆蓋率和觸發的唯一故障分析了這些工具的性能，指出了當前API測試的局限性和面臨的挑戰，但是未對具體的方法進行研究和分析。為了揭示該領域的核心問題和相關研究進展，本文梳理了近十年的代表性成果，首先總結了REST API自動化測試的發展歷程，然后結合REST API自動化測試特征，提煉測試的通用流程；接著分別從預處理、測試用例生成、測試用例執行與監測、結果分析四個環節闡述現有成果的技術特征，對比分析其優缺點；最后論述當前研究存在的不足，討論可能的解決思路，展望下一步研究方向。

1? REST API自動化測試

1.1? REST API自動化測試發展歷程

圖1展示了REST API自動化測試的發展歷程。如圖所示，2000—2017年，REST API自動化測試開始了初步發展。但是，由于2015年前，Web多采用面向服務的架構（service-oriented architecture，SOA），基于SOAP協議的API接口被廣泛接受［14］，所以該階段的REST API測試研究成果較少，且以黑盒測試為主。其中比較重要的有，2011年發明了Swagger［15］/OpenAPI［16］規范格式。雖然OpenAPI不是REST API的唯一規范格式，但它是迄今為止最常見的規范格式。2013年，Lamela等人［17］提出將基于屬性的測試方法用于RESTful Web服務中。2015年，Fertig等人［18］提出一種自動化的基于模型的REST API測試方法，證明了基于模型的測試技術用于測試RESTful API的可用性，為未來的研究工作奠定了基礎。

2017年，Arcuri［10］提出了一個完全自動化的REST API白盒測試工具EvoMaster。隨后，REST API白盒自動化測試也發展起來，大量基于EvoMaster的改進工作集中出現，研究成果的數量急劇增加，該工作將在3.2.4節中詳細介紹。

2019年，RESTler［5］誕生，這是一個有狀態的模糊測試工具。隨后幾年，基于有狀態的REST API，該如何探索到更深層次的服務是主要的研究方向。

2020年，REST API灰盒測試也逐漸發展，Atlidakis等人［11］提出了Pythia，這是第一個通過覆蓋率引導反饋和基于學習的變異策略增強REST API模糊測試的灰盒工具。2021年，Mirabella等人［19］將深度學習與REST API測試相結合來自動推斷REST API請求是否有效，這也為REST API自動化測試領域的未來帶來了新的可能性。2023年，Deng等人［20］提出了REST API漏洞自動化檢測工具Nautilus，獲得了很好的測試效果。

1.2? REST API自動化測試通用流程

REST API自動化測試的通用流程如圖2所示，可以分為預處理、測試用例生成、測試用例執行與監測和結果分析四個步驟。在接口測試的過程中，由于API操作可以按照許多不同的順序執行，以及其相關的輸入參數可以使用許多不同的值，這導致產生了一個潛在的巨大的輸入空間，很難被徹底探索。而且，不同操作和參數之間還存在依賴關系，即約束，任何不能正確處理這些約束的測試用例都將導致無效的HTTP請求，從而降低測試的有效性。對接口文檔進行預處理，提取接口間的資源依賴和參數依賴關系可以有效緩解上述問題。此外，現有研究還提出了多種測試用例生成策略來提高測試效率。根據技術的不同，這些生成策略可以分為：基于模型的測試用例生成策略、基于屬性的測試用例生成策略、隨機測試用例生成策略和基于搜索的測試用例生成策略。

測試用例執行與監測過程首先發送REST請求來測試Web服務或者云服務，然后對測試用例執行過程中的狀態碼、響應模式，以及定義的性能屬性、安全屬性和蛻變關系進行監控，判斷程序是否產生了異常。對于灰盒測試工具來說，還會獲取程序運行時的覆蓋信息，并用獲得的信息來指導測試用例變異，以更快地發現程序缺陷。將結果分析作為自動化測試的最后一個環節，完成對異常信息的分類和去重工作。

2? 預處理

OpenAPI specification（OAS）是一個與編程語言無關的REST API描述文檔規范［16］，它最初基于2015年SmartBear Software捐贈的Swagger 2.0［15］規范構建。OAS描述了REST API所有的請求方法和服務端的信息，例如必須使用哪些URI和哪些HTTP謂詞來調用特定的端點，以及可能需要哪些參數及其數據類型。OAS使人類和機器能夠了解API服務的功能，而無須訪問服務的源代碼或網絡流量，所以REST API自動化測試用例大多基于OAS解析產生。預處理作為REST API自動化測試的第一步，主要對API操作間的資源依賴關系和參數間的資源關系進行解析，以幫助生成有效的測試用例。OAS預處理方式［5～9，19，21～27］對比匯總如表1所示。

2.1? 資源依賴關系解析

雖然REST API是無狀態的，但接口所表述的資源是有狀態的。大量接口請求的有效輸入參數依賴于其他接口的響應，如何建模和解決這些資源依賴關系，是API生成有效測試用例的關鍵。RESTler［5］采用輕量級靜態分析方法，自動地從swagger文檔中推斷請求之間的生產者-消費者關系，從單個API開始，通過啟發式的方式附加API請求來擴展API調用序列，能夠測試更深層次的云服務。但是這種自下而上的方法缺乏對測試序列的整體意識，很容易在搜索時產生路徑爆炸。為此，foREST［6］實現了一種基于樹的REST API模糊測試方法，該方法巧妙地用樹結構對API之間的關系進行建模，不僅降低了API依賴關系的復雜性，而且捕獲了資源依賴關系的優先級，這比傳統基于圖的測試方法更加有效。RestTestGen［7］通過簡單字段匹配算法推斷API間的資源依賴關系，構建了操作依賴關系圖（operation dependency graph，ODG），通過遍歷ODG來生成有效的API調用序列，但該方法嚴重依賴于ODG，而ODG可能由于某些缺陷（例如OpenAPI編寫不規范）而不能正確地反映API行為，從而影響測試效果?；诖?，Liu等人［8］提出了一種基于動態更新REST服務屬性圖（RESTful-service property graph，RPG）的黑盒測試工具——MOREST。RPG不完全依賴于OpenAPI規范，它可以靈活地利用執行反饋進行自我更新。通過遍歷RPG，MOREST可以聚合被訪問的API來構建有意義的調用序列。

上述是黑盒測試經常采用的方法，對于白盒測試來說，處理資源之間的依賴關系同樣有助于提高測試覆蓋率。Zhang等人［21］提出了一種基于CRUD語義的測試方法，使用相關操作對的模板（例如post+delete和post+put），可減少搜索過程中的無用API調用。2021年，Zhang等人［22］又提出基于資源的MIO算法［28］來實現個體對資源的處理，包括基于資源的抽樣和基于資源的變異，實驗表明該方法顯著提升了代碼覆蓋率。

2.2? 參數依賴關系解析

REST API的參數依賴性指的是在某種情況下，需要將兩個或者多個輸入參數的值關聯起來才能形成對服務有效調用的API請求。例如：YouTube Data API的文檔指出，當使用參數videoDefinition時，類型參數必須設置為video，否則將返回HTTP 400（錯誤請求）。但是現有的規范語言往往采用自然語言來描述這種參數間的依賴關系，很少或不支持形式化表示，這給自動化生成測試用例帶來了困難。

為了解決上述問題，Wu等人［23］提出了一種采用混合分析自動推斷Web服務中參數依賴關系的方法，該方法通過分析四個流行的Web API，將發現的依賴關系分為六種類型。Oostvogels 等人［24］調查了當前的API文檔，將參數依賴性分為獨占性、依賴性和組約束三種類型?？紤]到參數間約束對于實現全面的、機器可讀的Web API規范至關重要，還設計了一種基于OpenAPI規范的API規范語言OAS-IP。但是這兩項工作都沒有對REST API間參數依賴關系進行徹底分析和系統研究。

于是，Martin-Lopez等人［25］研究了40個真實世界的API，包含超過2 500個操作，對REST API參數的特征、常用的語言模式和相關性進行了徹底分析。結果表明：參數間的依賴關系在API中是普遍存在的，并且在操作較少的API中，具有參數依賴項的操作所占比例較高，最后還總結了七種類型的參數依賴關系。隨后，文獻［26］又在文獻［25］的基礎上提出了一種特定于該領域的語言，用于規范Web API中參數間的依賴關系，稱為參數間依賴關系語言（inter-parameter dependency language，IDL），并且利用約束編程實現IDL規范自動分析的方法，這為Web API中參數間依賴關系的自動化管理提供了一個完整的解決方案。除了使用傳統的技術外，Mirabella等人［19］還提出了一種基于深度學習的方法來自動推斷REST API請求是否有效，即請求是否滿足所有參數間的依賴關系，證明了人工智能在自動化測試領域的無限潛力。

上述研究只致力于分析REST API間的參數依賴關系，缺少應用。Wu等人［9］依靠文獻［26］提出的參數間依賴目錄手動創建一組用于RESTCT的23個模式，用于生成有效的輸入參數。文獻［27］設計了基于黑盒約束的REST API測試工具RESTest，該工具能自動分析內部參數的依賴關系，并使用約束求解測試用例，這使得它能夠更快地檢測出更多的bug。

3? 測試用例生成

測試用例生成是REST API自動化測試的核心環節，包括測試數據生成和用例生成兩部分。測試用例的質量深刻的影響著測試結果。一方面，若生成的測試用例不滿足特定的數據格式要求和值域限制，那么會被視為無效的API請求，這些請求可能會被服務拒絕，無法測試到程序的深層分支，從而導致測試結果的代碼覆蓋率低下。另一方面，測試用例生成不當，會導致大量冗余的輸入，浪費程序執行時間，影響測試的效率。不同的生成策略可以幫助測試人員更高效的生成測試用例，提高API測試的效率和質量。

3.1? 測試數據生成策略

對于給定的API操作，應該仔細確定其輸入參數的值，以生成具體的、有效的HTTP請求?，F有研究利用各種方法生成測試數據。Ed-Douibi等人［29］使用了OpenAPI規范中定義的默認值和示例值作為輸入，但這種方法生成數據的質量過分依賴于規范的好壞。Atlidakis等人［5］提出了模糊字典，根據數據類型從字典中選取輸入數據，這種方法需要測試人員對要測試的服務有一定的了解才能達到高代碼覆蓋率。Arcuri等人［30］采用隨機值，該方法簡單但不太可能產生有效的測試用例。Corradini等人［31］利用了上下文數據，即將成功請求返回的數據記錄下來，供之后使用。Bania等人［32］設計了用戶交互，將用戶的輸入作為補充數據輸入，提高了測試用例的有效性。Maritin-Lopez等人［33］自定義了數據生成器，這些生成器可以自動生成實際數據，如電子郵件地址、語言代碼或匹配正則表達式的字符串等。Alonso等人［34］考慮了參數的實際意義，利用自然語言處理技術從知識庫［35］中提取數據，該方法提高了數據生成的自動化程度。

3.2? 測試用例生成策略

測試用例生成策略指的是根據一系列算法或技術來自動化地生成測試用例。常見的REST API測試用例生成策略有：基于模型的測試用例生成策略、基于屬性的測試用例生成策略、隨機測試用例生成策略和基于搜索的測試用例生成策略。下面將分別對這四種不同的方法進行總結。

3.2.1? 基于模型的測試用例生成策略

基于模型的測試用例生成策略將程序抽象成一個數學模型，將系統狀態抽象成狀態圖或狀態轉移矩陣等，然后應用搜索算法在狀態空間上進行搜索，以產生盡可能多、盡可能有代表性的測試用例［36］?；谀Ｐ偷臏y試用例生成策略［8，18，29，33，37，38］對比匯總如表2所示。

Pinheiro等人［37］創建了UML協議狀態機（行為模型），并將該行為模型轉換為XML元數據格式，然后開發工具讀取XML信息，并基于狀態覆蓋和轉換覆蓋生成測試用例，但是無法測試需要身份認證的Web服務。Fertig等人［18］提出了一種模型驅動的測試方法，該方法需要領域特定語言（domain specific language，DSL）來描述API，生成器使用此描述來生成不同的測試用例，包含功能測試、安全測試、性能測試和行為測試。這兩項工作證明了模型驅動測試的可行性，但它們都需要人工定義模型，存在一定的局限性。

Ed-Douibi等人［29］依賴API規范實現了REST API的自動測試，首先解析OpenAPI規范生成OpenAPI元模型［39］，然后添加參數將元模型擴展為TestSuite模型，最后基于Eclipse平臺實現了可以生成測試用例的插件。但是該方法沒有明確地對操作之間的依賴關系進行建模，產生的測試用例的質量不高。為此，MOREST［8］維護了一個動態更新的RESTful服務屬性圖（RPG），對RESTful服務的行為進行建模，動態指導測試序列的生成，該方法在覆蓋率和bug檢測方面都能顯著優于現有技術。

Martin-Lopez等人［33］遵循基于模型的測試方法，使用了系統模型和測試模型兩個模型。系統模型由API規范構成，測試模型包含被測試API的所有與測試相關的配置設置，以及指定了用于每個參數的測試數據。該方法基于框架開發實現，具有很好的擴展性。楊揚［38］設計并實現了移動端REST接口模糊測試工具REST-Fuzzer。REST-Fuzzer 能自動化地獲取移動應用程序的網絡流量數據進行REST業務接口的區分和篩選，基于lattice model的REST接口參數預判模型生成參數級別的模糊方案，對模糊測試范圍進行有效剪枝。

3.2.2? 基于屬性的測試用例生成策略

基于屬性的測試（property-based testing，PBT）最初起源于 Haskell 庫 QuickCheck［40］，其流程為：測試人員首先編寫對代碼來說為真的邏輯語句（即“屬性”），然后使用自動化工具來生成測試輸入，并觀察程序接受該輸入時屬性是否保持不變。如果某個輸入違反了某一條屬性，則證明程序存在一處錯誤?；趯傩缘臏y試用例生成策略［17，41～43］對比匯總如表3所示。

2013年，Lamela等人［17］開發了一個基于屬性的測試模型，并利用QuickCheck工具實現了該測試模型，不過該工具需要大量的手工工作輔助，并且只測試了單個集合。QuickREST［41］作為一個黑盒測試工具，它從swagger規范中解析出有狀態的API序列，利用隨機值作為測試數據輸入，然后檢測測試用例是否違反定義的三類屬性。QuickREST是一種發現真正錯誤的低成本方法，但它過度依賴規范，會產生一定比例的誤報和漏報。

與上述工作不同，一些研究關注REST API的語義屬性。Schemathesis［42］在基于屬性的工具Hypothesis［40］的基礎上實現了負面測試，可確定測試響應是否符合其基于狀態代碼、內容類型、標頭和正文有效負載定義的模式。在16個Web服務上面與目前最先進的7個REST API模糊測試工具進行了對比分析，結果表明Schemathesis在錯誤檢測方面優于其他技術，并且是唯一一個能夠處理超過三分之二的目標服務而不會出現致命內部錯誤的工具。趙春暉［43］設計了一種REST接口一致性測試的測試用例形式化定義方法，并且考慮了網絡管理領域中類模型之間還存在著一定的語義關系，提出了支持語義的測試用例的生成方法。首先，分析了測試數據的生成，設計了參數值區間的精簡及約束規則，通過使用基于IPO（in-parameter-order）算法［44］進行改進的IPO_S_RIC算法生成測試數據集，提高測試效率和測試用例的質量。

3.2.3? 隨機測試用例生成策略

隨機測試即通過為被測操作的每個參數分配隨機值來構建測試用例。模糊測試是REST API測試中廣泛使用的隨機化測試方法，其核心思想是將自動或半自動生成的隨機數據輸入到程序中，并監視程序異常，如崩潰或斷言失敗，以發現可能的程序錯誤。隨機測試用例生成策略［5～7，9，31，45～47］對比匯總如表4所示。

RESTler［5］、foREST［6］和Resttestgen［7］都是有狀態的模糊測試工具，基于OpenAPI規范，這些工作采取不同的靜態分析方法提取測試用例，然后變異器針對不同的數據類型采取不同的變異策略進行測試。在上述工作的基礎上，Godefroid等人［45］在RESTler的基礎上，研究了如何智能地生成嵌入在REST API請求中的數據payloads，以發現云服務中的數據處理bug。首先從REST API規范提取包含API請求主體的數據模式，以及從REST API規范包含的示例中提取數據值和從以前的服務響應中實時學習的數據值。 然后，提出并評估了一系列數據模糊化技術，包括結構模式模糊化規則、搜索啟發式等，在評估了這些技術之后，確定了性能最好的組合，并對幾個Microsoft Azure云服務進行了模糊測試。文獻［31］對Resttestgen進行了改進，增加了可以測試需要身份驗證的REST API服務。并且在真實的Web環境中進行了測試，實驗表明，改進后的Resttestgen可以檢測出較多的bug，但是在API依賴關系不復雜的服務中，Resttestgen表現得一般。Wu等人［9］提出采用組合測試的方式對REST API進行測試，并設計了自動化缺陷檢測工具RestCT。RestCT結合了序列和經典覆蓋數組的概念，實現了一種新的兩階段測試用例生成方法。Mahmood等人［46］提出了一個面向企業的Fuzz測試框架，并通過容器化模糊器和開源集群計算技術（即Kubernetes）部署實現。該框架可以同時模糊多個應用程序，并保留了企業的信任邊界。于海峰［47］提出了一種基于預篩選的快速定位模糊測試方法，通過分析API接口定義描述的關鍵字段，結合漏洞庫指引，在有效定義域內及定義邊界附近對脆弱字段進行針對性變異，生成畸形用例。但該系統只用于判斷RESTful API接口系統存在何種類型的軟件漏洞，如果要進行問題定位，則需要借助白盒走讀代碼或軟件逆向。

3.2.4? 基于搜索的測試用例生成策略

上述三種策略是黑盒測試經常采用的方式，對于白盒測試來說，測試人員可以根據程序內部結構及邏輯及關系設計測試用例，覆蓋代碼中的每條分支和路徑?；谒阉鞯臏y試用例生成是白盒測試經常采用的方式，它已被證明能夠在許多不同的測試上下文中成功地生成高覆蓋率的測試用例［48］?；谒阉鞯臏y試用例生成策略［10，49～54］對比匯總如表5所示。

Arcuri［10］從開發人員的角度考慮測試，設計了白盒測試工具EvoMASTER。EvoMASTER使用遺傳算法（genetic algorithm，GA）生成隨機的測試用例，根據覆蓋率指導變異測試。隨后，Arcuri［49］改進了EvoMASTER，使用MIO算法［23］進行智能采樣來生成具有預定義結構的測試，以加快搜索速度。但是改進后的EvoMASTER在某些項目中的代碼覆蓋率仍然較低，還有很大的提升空間。為此，Arcuri等人［50］考慮了數據庫的狀態，通過監控SQL命令計算啟發式值來增強基于搜索的測試，同時還支持直接從測試用例生成SQL數據。該工作顯著提高了測試的覆蓋率和查找bug的能力，但是它僅支持采取關系型數據庫的服務。

進化算法對基于搜索測試進行優化與設計，可以提高測試效率。Zhang等人［51］在測試REST API的背景下，考慮到基因數量多且類型不同，提出了一種基于權重的自適應超突變，以增強進化算法的突變，并在MIO算法中實現了該突變算子MIO-WH*，結果表明，新的變異算子比默認的MIO有明顯的改進，在目標覆蓋率、線路覆蓋率、分支覆蓋率方面都有顯著提升。Sahin等人［52］提出了一種用于RESTful Web服務自動測試的離散動態人工蜂群超偵察機（DABC-HS）算法，該算法是一種多目標優化算法，同時考慮了覆蓋量、服務器錯誤數和測試用例數。該工作還改進了ABC算法的搜索機制，并增加了超偵察階段，提高了算法的探測能力。Zhang等人［53］對RDMIO，一種基于搜索的測試方法，進行了擴展，采用結構化查詢語言（SQL）增強了資源處理能力。Stallenberg等人［54］為了提高REST API測試用例生成過程的有效性，使用凝聚層次聚類算法自動從生成的測試用例中推斷HTTP請求模式，然后提出了一種新算法LT-MOSA，并在EvoMASTER實現了該工作。LT-MOSA極大地提高了代碼覆蓋率，可以檢測到比MIO和MOSA［55］更多的錯誤。

上述測試用例生成策略在一定程度上增強了測試質量，提高了測試效率。表6對這四種測試用例生成策略進行了總結：基于模型的測試用例生成策略通過對REST API服務建模，能夠實現較高的代碼覆蓋率，但是通常需要手工建模，測試成本較高，現有工作大多采取各種自動化的方式建立更準確的模型，以降低測試成本?；趯傩缘臏y試用例生成策略，需要對系統有深入的了解，選擇屬性時也要考慮屬性的相互影響以避免遺漏測試用例，現有研究更注重設置多種屬性，來檢測服務更多的異常狀態。隨機測試用例生成策略的特點是簡單、快速，但具有盲目性，現有研究采取各種啟發式方法生成測試數據，通過使用不同變異策略來提高測試用例的質量?；谒阉鳒y試用例生成策略的核心是搜索算法，這種方法的自動化程度高，但是當狀態空間龐大時，搜索比較耗時，現有研究提出多種算法來解決此問題，從而提升測試效率。

4? 測試用例執行與監測

測試用例執行與監測是REST API自動化測試的重要環節，可以提高測試效率和質量，實時監測測試結果。該過程主要完成兩個工作。a）監測測試用例執行過程中是否增加了代碼覆蓋率。代碼覆蓋率可以作為程序執行反饋信息指導生成有效的輸入，基于有效的輸入進行變異，更容易探測到程序的深層分支，觸發潛在的異常。b）根據測試預言來監測程序執行是否正確。測試預言是一種判斷程序在給定測試輸入下的執行結果是否符合預期的方法，在REST API測試中，它可以幫助測試人員評估測試結果是否正確，從而發現程序缺陷。

4.1? 覆蓋反饋

對于黑盒測試來說，不需要了解程序內部的代碼實現，就可以快速進行自動化測試，但盲目、隨機和發散的突變會導致大量冗余、無效的輸入，使某些代碼路徑難以被測試。利用代碼覆蓋率作為反饋來指導測試，是改進黑盒測試的常見做法。

Atlidakis等人［11］提出了Pythia，這是第一個通過覆蓋率引導反饋和基于學習的變異策略增強REST API模糊測試的灰盒工具。Pythia使用統計模型，在結構上從有效的種子輸入中學習REST API的模式，在保持句法有效性的同時，加入隨機噪聲進行突變。Pythia的變異策略有助于生成語法上有效的測試用例，而覆蓋率反饋有助于優先選擇更有可能檢測到有缺陷的種子進行變異。該工具對三個生產規模的開源云服務的實驗表明：Pythia在代碼覆蓋率和發現新bug方面都優于以前的方法。

與Pythia工作不同，文獻[56]沒有對代碼進行插裝來統計代碼覆蓋率，而是提出使用TCL測試覆蓋準則（一種RESTful Web API的測試覆蓋標準）來指導模糊測試。HsuanFuzz［57］將能夠引起代碼覆蓋級別變化的種子認定為有趣的種子，保留它們用于下一次使用，反之舍棄。該策略解決了黑盒模糊測試盲目的缺點，提高了檢測bug的能力，但該工作最大的局限性是REST API間依賴關系的提取不是自動的，需要測試人員列出所有的路徑參數依賴關系。

4.2? 測試預言

測試預言（test oracle）可以認為是一個函數，判斷測試用例的執行結果是否正確。通過將被測試系統的實際輸出與所期望的輸出（測試預言）進行比較，從而判斷程序是否發生錯誤?，F有研究采用各種oracle來判斷REST API服務是否發生了錯誤，下面對test oracle的類型進行總結：

1）狀態碼? 狀態碼是HTTP響應中的一個三位數整數值，用來描述請求的結果。最常見的狀態碼有200、302、404、500等。其中：2xx表示已成功接收并處理請求；3xx表示重定向，需要進一步處理操作才能完成請求；4xx表示客戶端請求錯誤，如找不到頁面等；5xx 表示服務器錯誤。如果所測試的Web服務的環境（例如數據庫）工作正常，那么5xx狀態代碼通常意味著此類服務中存在缺陷。所以現有研究將狀態碼5xx用于識別REST API測試中的潛在故障［5～11，20～22，28～33，37～47，49～54］。

2）響應模式? OpenAPI記錄了接口操作響應及其模式，即預期的狀態代碼和響應中的字段，對于連接到REST API的遠程程序來說，實際響應與其模式之間的一致性非常重要，這可能會造成敏感信息泄露問題，且這類錯誤往往不會產生5XX響應碼。于是一些研究將預期響應和實際響應不一致記錄為缺陷［7，31］。

3）安全屬性? 安全性是REST API測試中應該關注的重要屬性。目前已有研究專注REST API安全測試，以發現REST API中潛在的漏洞。Atlidakis等人［58］設計了四個安全規則：釋放后重引用規則（use-after-free rule），資源泄露規則（resource-leak rule）、資源層次規則（resource-hierarchy rule）、用戶命名空間規則（user-namespace rule）來檢測云服務中的漏洞。Barabanov等人［59］總結了IDOR（insecure direct object refe-rence）漏洞的攻擊模式，提出了一種基于OpenAPI規范處理的IDOR/BOLA（insecure direct object reference/broken object level authorization）靜態檢測算法。Chen等人［60］通過利用API調用和規范中定義的數據字段之間的相互依賴關系來識別敏感數據，以發現敏感數據泄露風險。Corradini等人［61］利用聚類方法識別API規范中的只讀字段，并設計了兩個抽象測試模板和對應的安全oracle來檢測REST API中的自動綁定漏洞。Deng等人［20］使用特定的payloads來檢測SQL注入、XSS、訪問控制等漏洞，并且將狀態碼、數據結構變化、語義關系作為檢測漏洞的測試預言。

4）性能屬性? 如果功能性考慮的是REST API“能做什么”的問題，那么性能關注的則是REST API所完成的工作“做得如何”的問題。顯然，API的性能實現同樣重要。Hatfield-Dodds等人［42］將響應時間和請求放大率作為衡量性能的oracle。Bania等人［32］度量了每個發送的請求接收響應所需的平均時間。Bucaille等人［62］開發了REST API的非功能測試框架Gadolinium，Gadolinium通過計算請求和響應之間的延遲或時間間隔來衡量性能，通過API正常運行時間來衡量API的可用性。

5）蛻變關系? 蛻變測試是緩解oracle問題［63］的有效方法，蛻變測試的核心元素是一組蛻變關系，這是目標函數或算法相對于多個輸入及其預期輸出的必要屬性［64］。Segura等人［65］捕捉了六種Web API中典型蛻變關系模式，每個模式是根據API響應之間的集合關系定義的，并且在每個被測試的Web API上實例化為一個或多個具體的蛻變關系。Mai等人［66］根據OWASP中提供的Web測試方法，提取了22個與系統無關的蛻變關系（metamorphic relation，MR）目錄，依賴這些MR來自動化安全測試。實驗結果顯示，該工作能夠檢測到大部分的目標漏洞，有助于解決安全測試中的oracle問題。Pan等人［67］提出通過蛻變關系來解決過度數據暴露漏洞不會通過明顯的異常行為表現，從而難以檢測的問題，并在此基礎上實現了一個模糊測試工具EDEFuzz。

5? 結果分析

結果分析作為自動化測試的最后一步，對自動工具生成的結果進行分類、去重等工作，以發現潛在的bug。自動化測試中往往會產生很多崩潰的測試用例，采用人工驗證的方式是一種費時、費力的工作。為此，RESTler［5］自動對查找到的bug進行了去重；RESTCluster［68］使用兩步聚類的方法，首先根據上下文將崩潰劃分為不同的集群，然后對每一個集群再進行參數的相似度計算，從而實現crash的分類。

6? 總結與展望

6.1? 存在的問題

通過上述分析可知，REST API的自動化測試問題已經受到了學術界的廣泛關注，并取得了大量的研究成果。與人工測試相比，自動化測試節省了人力和時間成本，提高了檢測REST API服務缺陷的效率，但是仍然存在以下幾個方面的問題：

a）黑盒測試過度依賴API規范。預處理是REST API測試的首要環節?，F有研究采取各種方法從OpenAPI規范中提取資源依賴關系和參數依賴關系，以生成質量更高的測試用例。但是由于API實現與規范文檔更新的不同步性，以及人工編寫文檔易導致錯誤或者遺漏，根據文檔推斷出的依賴關系可能不全面或者部分依賴關系在實際測試中并不可用。對于白盒測試來說，這個問題可以通過分析源代碼來解決，但是對于黑盒測試，目前還沒有完全有效的解決方案。

b）良性測試用例生成率低。測試用例的質量是有效執行REST API測試的關鍵，測試用例的高質量表現在高錯誤檢測能力、高代碼覆蓋率和低冗余度。API輸入參數復雜、數據結構多變和系統路徑分支眾多，限制了測試用例的有效性，現有研究已提出各種策略和技術來提高測試用例的質量，從結果來看，測試用例的質量達到了大幅度提升，但是還存在進一步的提升空間。

c）測試oracle不準確。oracle問題一直是困擾自動化測試的難題。對于REST API來說，輸入和輸出結果復雜多樣，確定給定輸入的正確輸出極其困難。從測試用例執行監測環節來看，多數的研究采用5xx狀態碼來檢測缺陷，雖然這種方式簡單方便，但是有些錯誤并不能通過5xx狀態碼表現出來。只有一小部分的研究關注REST API的安全性和性能好壞，且安全測試只能檢測到部分的API漏洞類型。所以，目前雖然研究人員提出了一系列oracle，但是仍然沒有完全準確的、統一的oracle可以發現所有的潛在故障。

6.2? 未來的研究方向

隨著REST API的廣泛應用，各類數據依賴API進行交互，API經濟已經成為信息網絡化時代產生的一種嶄新的經濟現象，所以亟待使用更好的方法對這些API進行測試，來保證服務的正常運行。針對上述存在的問題，本文從多角度分析REST API自動化測試未來可行的研究方向。

a）研究智能的自動化測試技術。當前機器學習、深度學習與傳統的軟件測試方法結合取得了大量的研究成果。REST API自動化測試同樣可以借鑒這些結合工具的方法，提升測試用例的質量和監測bug的能力。比如：使用自然語言處理技術生成測試數據；使用深度學習中的模型訓練，自動生成符合語法的變異測試用例，提高生成的測試用例質量，從而觸發更多的程序狀態；使用更高效的搜索算法，提高測試用例的代碼覆蓋率等。

b）研究REST API漏洞檢測。API的廣泛應用以及傳輸數據量的飛速增長，使得API安全管理面臨著巨大的困難，國內外已經發生多起由于API漏洞被惡意攻擊或者安全管理疏漏導致的數據安全事件。對此，除了建立健全的API安全管理制度外，提早檢測漏洞，避免造成嚴重的危害也是一種很有效的手段?，F有研究要么不關注API的漏洞檢測，要么只關注某一特定類型的漏洞，對于由不當資產管理導致的漏洞，如訪問控制、缺乏速率限制等，這類漏洞很難統一建模，目前還沒有研究可以有效檢測該類型的漏洞。所以如何對常見的API漏洞類型進行建模和檢測是一個值得研究的方向。

7? 結束語

REST API在云服務中發揮著重要的作用。本文通過梳理相關文獻，綜述了REST API自動化測試的方法，重點介紹了測試用例生成和執行監測，對比分析了目前測試用例生成策略的優缺點，討論了該領域研究的難點和未來發展方向，期望能為相關研究提供參考。

參考文獻：

［1］錢君生，楊明，韋巍.API安全技術與實戰［M］.北京：北京機械出版社，2021：7-8.（Qian Junsheng，Yang Ming，Wei Wei.API security technology and practice［M］.Beijing：Beijing Machinery Press，2021：7-8.）

［2］Fielding R T.Architectural styles and the design of network-based software architectures［M］.Irvine：University of California Press，2000.

［3］鄭天民.微服務設計原理與架構［M］.北京： 人民郵電出版社，2018：302.（Zheng Tianmin.Microservice design principles and architecture［M］.Beijing：Peoples Post and Telecommunications Publishing House，2018：302.）

［4］陳能技，黃志國.軟件測試技術大全［M］.北京：人民郵電出版社，2015：577.（Chen Nengji，Huang Zhiguo.Software testing techniques［M］.Beijing：Peoples Post and Telecommunications Publishing House，2015：577.）

［5］Atlidakis V，Godefroid P，Polishchuk M.RESTler：stateful rest API fuzzing［C］//Proc of the 41st International Conference on Software Engineering.Piscataway，NJ：IEEE Press，2019：748-758.

［6］Lin Jiaxian，Li Tianyu，Chen Yang，et al.foREST：a tree-based black-box fuzzing approach for RESTful APIs［C］//Proc of the 34th International Symposium on Software Reliability Engineering.Piscataway，NJ：IEEE Press，2023：695-705.

［7］Viglianisi E，Dallago M，Ceccato M.RESTTESTGEN：automated black-box testing of RESTful APIs［C］//Proc of the 13th International Conference on Software Testing，Validation and Verification.Pisca-taway，NJ：IEEE Press，2020：142-152.

［8］Liu Yi，Li Yuekang，Deng Gelei，et al.MOREST：model-based RESTful API testing with execution feedback［C］//Proc of the 44th International Conference on Software Engineering.Piscataway，NJ：IEEE Press，2022：1406-1417.

［9］Wu Huayao，Xu Lixin，Niu Xintao，et al.Combinatorial testing of RESTful APIs［C］//Proc of the 44th International Conference on Software Engineering.New York：ACM Press，2022：426-437.

［10］Arcuri A.RESTful API automated test case generation［C］//Proc of IEEE International Conference on Software Quality，Reliability and Security.Piscataway，NJ：IEEE Press，2017：9-20.

［11］Atlidakis V，Geambasu R，Godefroid P，et al.Pythia：grammar-based fuzzing of rest APIs with coverage-guided feedback and learning-based mutations［EB/OL］.（2020-05-23）.https：//arxiv.org/abs/2005.11498.

［12］Ehsan A，Abuhaliqa M A M E，Catal C，et al.RESTful API testing methodologies：rationale，challenges，and solution directions［J］.Applied Sciences，2022，12（9）：4369.

［13］Kim M，Xin Qi，Sinha S，et al.Automated test generation for REST APIs：no time to rest yet［C］//Proc of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis.New York：ACM Press，2022：289-301.

［14］艾瑞咨詢有限公司.2020年中國人工智能API經濟白皮書［EB/OL］.（2020-10）.https：//report.iresearch.cn/report/202010/3670.shtml.（IResearch Consulting Croup.White paper on API economy of Chinas artificial intelligence［EB/OL］.（2020-10）.https：//report.iresearch.cn/report/202010/3670.shtml.）

［15］Swagger.API development for everyone［EB/OL］.（2020）.http：//swagger.io/.

［16］Miller D，Whitlock J，Gardiner M，et al.OpenAPI specification［EB/OL］.（2020）.https：//github.com/OAI/OpenAPI-Specification.

［17］Lamela S P，Li Huiqing，Thompson S.Towards property-based testing of restful Web services［C］//Proc of the 12th ACM SIGPLAN Workshop on Erlang.New York：ACM Press，2013：77-78.

［18］Fertig T，Braun P.Model-driven testing of RESTful APIs［C］//Proc of the 24th International Conference on World Wide Web.New York：ACM Press，2015：1497-1502.

［19］Mirabella A G，Martin-Lopez A，Segura S，et al.Deep learning-based prediction of test input validity for RESTful APIs［C］//Proc of the 3rd International Workshop on Deep Learning for Testing and Testing for Deep Learning.Piscataway，NJ：IEEE Press，2021：9-16.

［20］Deng Gelei，Zhang Zhiyi，Li Yi，et al.NAUTILUS：automated RESTful API vulnerability detection［C］//Proc of the 32nd USENIX Security Symposium.Berkeley，CA：USENIX Association，2023：5593-5609.

［21］Zhang Man，Marculescu B，Arcuri A.Resource-based test case generation for RESTful Web services［C］//Proc of Genetic and Evolutionary Computation Conference.New York：ACM Press，2019：1426-1434.

［22］Zhang Man，Marculescu B，Arcuri A.Resource and dependency based test case generation for RESTful Web services［J］.Empirical Software Engineering，2021，26（4）：article No.76.

［23］Wu Qian，Wu Ling，Liang Guangtai，et al.Inferring dependency constraints on parameters for Web services［C］//Proc of the 22nd International Conference on World Wide Web.New York：ACM Press，2013：1421-1432.

［24］Oostvogels N，De Koster J，De Meuter W.Inter-parameter constraints in contemporary Web APIs［M］// Cabot J，De Virgilio R，Torlone R.Web Engineering.Cham：Springer，2017：323-335.

［25］Martin-Lopez A，Segura S，Ruiz-Cortés A.A catalogue of inter-parameter dependencies in RESTful Web APIs［M］//Yangui S，Rodriguez I B，Drira K，et al.Service-Oriented Computing.Cham：Sprin-ger，2019：399-414.

［26］Martin-Lopez A，Segura S，Müller C，et al.Specification and automated analysis of inter-parameter dependencies in Web APIs［J］.IEEE Trans on Services Computing，2021，15（4）：2342-2355.

［27］Martin-Lopez A，Segura S，Ruiz-Cortés A.RESTest：black-box constraint-based testing of RESTful Web APIs［M］//Kafeza E，Benatallah B，Martinelli F，et al.Service-Oriented Computing.Cham：Sprin-ger，2020：459-475.

［28］Arcuri A.Test suite generation with the many independent objective（MIO） algorithm［J］.Information and Software Technology，2018，104：195-206.

［29］Ed-Douibi H，Cánovas I J L，Cabot J.Automatic generation of test cases for REST APIs：a specification-based approach［C］//Proc of the 22nd International Enterprise Distributed Object Computing Confe-rence.Piscataway，NJ：IEEE Press，2018：181-190.

［30］Arcuri A.Automated black-and white-box testing of RESTful APIs with evomaster［J］.IEEE Software，2020，38（3）：72-78.

［31］Corradini D，Zampieri A，Pasqua M，et al.Automated black-box testing of nominal and error scenarios in RESTful APIs［J］.Software Testing，Verification and Reliability，2022，32（5）：e1808.

［32］Bania O，Florea D，Gyalai R，et al.Automated specification-based testing of REST APIs［J］.Sensors，2021，21（16）：5375.

［33］Martin-Lopez A，Segura S，Ruiz-Cortés A.RESTest：automated black-box testing of RESTful Web APIs［C］//Proc of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis.New York：ACM Press，2021：682-685.

［34］Alonso J C，Martin-Lopez A，Segura S，et al.ARTE：automated generation of realistic test inputs for Web APIs［J］.IEEE Trans on Software Engineering，2022，49（1）：348-363.

［35］Bizer C，Lehmann J，Kobilarov G，et al.DBpedia-a crystallization point for the Web of data［J］.Journal of Web Semantics，2009，7（3）：154-165.

［36］蒲卿路，王月波，劉濤，等.基于模型的測試用例生成方法［J］.計算機測量與控制，2021，29（12）：22-26.（Pu Qinglu，Wang Yuebo，Liu Tao，et al.A model-based approach to test case generation［J］.Computer Measurement and Control，2021，29（12）：22-26.）

［37］Pinheiro P V P，Endo A T，Simao A.Model-based testing of RESTful Web services using UML protocol state machines［EB/OL］.（2013）.https：//repositorio.usp.br/item/002429063.

［38］楊揚.移動端REST接口模糊測試方法［D］.上海：上海交通大學，2020.（Yang Yang.A fuzzy testing approach for REST interfaces on mobile［D］.Shanghai：Shanghai Jiaotong University，2020.）

［39］Ed-Douibi H，Cánovas I J L，Cabot J.Example-driven Web API specification discovery［M］// Anjorin A，Espinoza H.Modelling Foundations and Applications.Cham：Springer，2017：267-284.

［40］Claessen K，Hughes J.QuickCheck：a lightweight tool for random testing of Haskell programs［C］//Proc of the 5th ACM SIGPLAN International Conference on Functional Programming.New York：ACM Press，2000：268-279.

［41］Karlsson S，Cˇauevicˇ A，Sundmark D.QuickREST：property-based test generation of OpenAPI-described RESTful APIs［C］//Proc of the 13th International Conference on Software Testing，Validation and Ve-rification.Piscataway，NJ：IEEE Press，2020：131-141.

［42］Hatfield-Dodds Z，Dygalo D.Deriving semantics-aware fuzzers from Web API schemas［C］//Proc of the 44th International Conference on Software Engineering：Companion Proc.Piscataway，NJ：IEEE Press，2022：345-346.

［43］趙春暉.REST接口一致性測試用例形式化定義和生成方法［D］.北京：北京郵電大學，2021.（Zhao Chunhui.A formal definition and generation method for REST interface conformance test cases［D］.Beijing：Beijing University of Posts and Telecommunications，2021.）

［44］MacIver D R，Hatfield-Dodds Z.Hypothesis：a new approach to property-based testing［J］.Journal of Open Source Software，2019，4（43）：1891.

［45］Godefroid P，Huang B Y，Polishchuk M.Intelligent REST API data fuzzing［C］//Proc of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on Foundations of Software Engineering.New York：ACM Press，2020：725-736.

［46］Mahmood R，Pennington J，Tsang D，et al.A framework for automated API fuzzing at enterprise scale［C］//Proc of IEEE Conference on Software Testing，Verification and Validation.Piscataway，NJ：IEEE Press，2022：377-388.

［47］于海峰.RESTful API接口Fuzz測試關鍵技術研究［D］.南京：東南大學，2019.（Yu Haifeng.Research on key technologies for Fuzz testing of RESTful API interfaces［D］.Nanjing：Southeast University，2019.）

［48］Harman M，Jia Yue，Zhang Yuanyuan.Achievements，open problems and challenges for search based software testing［C］//Proc of the 8th International Conference on Software Testing，Verification and Validation.Piscataway，NJ：IEEE Press，2015：1-12.

［49］Arcuri A.RESTful API automated test case generation with EvoMaster［J］.ACM Trans on Software Engineering and Methodology，2019，28（1）：article No.3.

［50］Arcuri A，Galeotti J P.Handling SQL databases in automated system test generation［J］.ACM Trans on Software Engineering and Methodology，2020，29（4）：article No.22.

［51］Zhang Man，Arcuri A.Adaptive hypermutation for search-based system test generation：a study on REST APIs with EvoMaster［J］.ACM Trans on Software Engineering and Methodology，2021，31（1）：article No.2.

［52］Sahin O，Akay B.A discrete dynamic artificial bee colony with hyper-scout for RESTful Web service API test suite generation［J］.Applied Soft Computing，2021，104：107246.

［53］Zhang Man，Arcuri A.Enhancing resource-based test case generation for RESTful APIs with SQL handling［M］//OReilly U M，Devroey X.Search-Based Software Engineering.Cham：Springer，2021：103-117.

［54］Stallenberg D，Olsthoorn M，Panichella A.Improving test case generation for rest APIs through hierarchical clustering［C］//Proc of the 36th IEEE/ACM International Conference on Automated Software Engineering.Piscataway，NJ：IEEE Press，2021：117-128.

［55］Panichella A，Kifetew F M，Tonella P.Reformulating branch coverage as a many-objective optimization problem［C］//Proc of the 8th International Conference on Software Testing，Verification and Validation.Piscataway，NJ：IEEE Press，2015：1-10.

［56］Martin-Lopez A，Segura S，Ruiz-Cortés A.Test coverage criteria for RESTful Web APIs［C］//Proc of the 10th ACM SIGSOFT Internatio-nal Workshop on Automating TEST Case Design，Selection，and Evaluation.New York：ACM Press，2019：15-21.

［57］Tsai C H，Tsai S C，Huang S K.REST API fuzzing by coverage level guided blackbox testing［C］//Proc of the 21st International Confe-rence on Software Quality，Reliability and Security.Piscataway，NJ：IEEE Press，2021：291-300.

［58］Atlidakis V，Godefroid P，Polishchuk M.Checking security properties of cloud service REST APIs［C］//Proc of the 13th International Conference on Software Testing，Validation and Verification.Piscataway，NJ：IEEE Press，2020：387-397.

［59］Barabanov A，Dergunov D，Makrushin D，et al.Automatic detection of access control vulnerabilities via API specification processing［EB/OL］.（2022-01-26）.https：//arxiv.org/abs/2201.10833.

［60］Chen C，Chen Binbin.Analyzing OpenAPI specifications for security design issues［C］//Proc of IEEE Secure Development Conference.Piscataway，NJ：IEEE Press，2021：15-22.

［61］Corradini D，Pasqua M，Ceccato M.Automated black-box testing of mass assignment vulnerabilities in RESTful APIs［C］//Proc of the 45th International Conference on Software Engineering.Piscataway，NJ：IEEE Press，2023：2553-2564.

［62］Bucaille S，CáNovas I J L，Ed-Douibi H，et al.An OpenAPI-based testing framework to monitor non-functional properties of REST APIs［C］//Proc of International Conference on Web Engineering.Berlin：Springer，2020：533-537.

［63］Barr E T，Harman M，McMinn P，et al.The oracle problem in software testing：a survey［J］.IEEE Trans on Software Engineering，2014，41（5）：507-525.

［64］田甜，楊秀婷，王安軾，等.蛻變測試研究進展及其在并行程序測試中的研究展望［J］.軟件學報，2023，34（1）：130-149.（Tian Tian，Yang Xiuting，Wang Anshi，et al.Research advances in metamorphic testing and its research perspectives in parallel program testing［J］.Journal of Software，2023，34（1）：130-149.）

［65］Segura S，Parejo J A，Troya J，et al.Metamorphic testing of RESTful Web APIs［C］//Proc of the 40th International Conference on Software Engineering.New York：ACM Press，2018：882-882.

［66］Mai P X，Pastore F，Goknil A，et al.Metamorphic security testing for Web systems［C］//Proc of the 13th International Conference on Software Testing，Validation and Verification.Piscataway，NJ：IEEE Press，2020：186-197.

［67］Pan Lianglu，Cohney S，Murray T，et al.Detecting excessive data exposures in Web server responses with metamorphic fuzzing［EB/OL］.（2023-01-23）.https：//arxiv.org/abs/2301.09258.

［68］Liu Yi.RESTCluster：automated crash clustering for RESTful API［C］//Proc of the 37th IEEE/ACM International Conference on Automated Software Engineering.New York：ACM Press，2022：article No.198.