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］等。灰盒测试可以获取程序执行的部分信息，现有研究往往采用代码覆盖率作为程序执行反馈信息指导生成有效的输入，其中代表性工作包括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请求。现有研究利用各种方法生成测试数据。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］。基于模型的测试用例生成策略［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］，其流程为：测试人员首先编写对代码来说为真的逻辑语句（即“属性”），然后使用自动化工具来生成测试输入，并观察程序接受该输入时属性是否保持不变。如果某个输入违反了某一条属性，则证明程序存在一处错误。基于属性的测试用例生成策略［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  基于搜索的测试用例生成策略

上述三种策略是黑盒测试经常采用的方式，对于白盒测试来说，测试人员可以根据程序内部结构及逻辑及关系设计测试用例，覆盖代码中的每条分支和路径。基于搜索的测试用例生成是白盒测试经常采用的方式，它已被证明能够在许多不同的测试上下文中成功地生成高覆盖率的测试用例［48］。基于搜索的测试用例生成策略［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服务建模，能够实现较高的代码覆盖率，但是通常需要手工建模，测试成本较高，现有工作大多采取各种自动化的方式建立更准确的模型，以降低测试成本。基于属性的测试用例生成策略，需要对系统有深入的了解，选择属性时也要考虑属性的相互影响以避免遗漏测试用例，现有研究更注重设置多种属性，来检测服务更多的异常状态。随机测试用例生成策略的特点是简单、快速，但具有盲目性，现有研究采取各种启发式方法生成测试数据，通过使用不同变异策略来提高测试用例的质量。基于搜索测试用例生成策略的核心是搜索算法，这种方法的自动化程度高，但是当状态空间庞大时，搜索比较耗时，现有研究提出多种算法来解决此问题，从而提升测试效率。

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）可以认为是一个函数，判断测试用例的执行结果是否正确。通过将被测试系统的实际输出与所期望的输出（测试预言）进行比较，从而判断程序是否发生错误。现有研究采用各种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测试的首要环节。现有研究采取各种方法从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安全管理制度外，提早检测漏洞，避免造成严重的危害也是一种很有效的手段。现有研究要么不关注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.