Due to their widespread use in industry, several techniques have been proposed in the literature to fuzz REST APIs. Existing fuzzers for REST APIs have been focusing on detecting crashes (e.g., 500 HTTP server error status code). However, security vulnerabilities can have major drastic consequences on existing cloud infrastructures.In this paper, we propose a series of novel automated oracles aimed at detecting violations of access policies in REST APIs, as well as executing traditional attacks such as SQL Injection and XSS. These novel automated oracles can be integrated into existing fuzzers, in which, once the fuzzing session is completed, a “security testing” phase is executed to verify these oracles. When a security fault is detected, as output our technique is able to generate executable test cases in different formats, like Java, Kotlin, Python and JavaScript test suites.Our novel techniques are integrated as an extension of EvoMaster, a state-of-the-art open-source fuzzer for REST APIs. Experiments are carried out on 9 artificial examples, 8 vulnerable-by-design REST APIs with black-box testing, and 36 REST APIs from the WFD corpus with white-box testing, for a total of 52 distinct APIs. Results show that our novel oracles and their automated integration in a fuzzing process can lead to detecting security issues in several of these APIs.

The widespread adoption of microservices has fundamentally transformed how modern software systems are designed, deployed, operated and maintained. However, well-known microservice properties (e.g., dynamic scalability and decentralized control) introduce inherent and multi-dimensional uncertainties. These uncertainties span across inter-service interactions, runtime environments, and internal service logic, which manifest as nondeterministic behaviors, performance fluctuations, and unpredictable fault propagation. Existing approaches do not have sufficient support in capturing such uncertainties and their propagation in industrial microservice systems, and these approaches mostly focus on single-service testing. In this paper, we argue for a novel paradigm: “uncertainty-driven” and “system-level” microservice testing. We outline key research challenges, including the modeling and injection of uncertainties and their propagation, causal inference for fault localization, and multi-dimensional analyses and assessment of uncertainties and their impact on system quality. We propose an architecture for continuous uncertainty-driven and system-level microservice fuzzing, which integrates service virtualization, uncertainty simulation, adaptive test generation and optimization, and illustrate it with an e-commerce example we developed. Our goal is to inspire the development of scalable and automated system-level testing methods that improve the dependability and resilience of industrial microservice systems, with the explicit consideration of uncertainties and their propagation.

Web application testing is an essential practice to ensure the reliability, security, and performance of web systems in an increasingly digital world. This paper presents a systematic literature survey focusing on web testing methodologies, tools, and trends from 2014 to 2025. By analyzing 258research papers, the survey identifies key trends, demographics, contributions, tools, challenges, and innovations in this domain. In addition, the survey analyzes the experimental setups adopted by the studies, including the number of participants involved and the outcomes of the experiments. Our results show that web testing research has been highly active, with ICST as the leading venue. Most studies focus on novel techniques, emphasizing automation in black-box testing. Selenium is the most widely used tool, while industrial adoption and human studies remain comparatively limited. The findings provide a detailed overview of trends, advancements, and challenges in web testing research, the evolution of automated testing methods, the role of artificial intelligence in test case generation, and gaps in current research. Special attention was given to the level of collaboration and engagement with the industry. A positive trend in using industrial systems is observed, though many tools lack open-source availability.

Testing large and complex enterprise software systems can be a challenging task. This is especially the case when the functionality of the system depends on interactions with other external services over a network (e.g., external web services accessed through REST API calls). Although several techniques in the research literature have been shown to be effective at generating test cases in a good number of different software testing contexts, dealing with external services is still a major research challenge. In industry, a common approach is to mock external web services for testing purposes. However, generating and configuring mock web services can be a very time-consuming task, e.g., external services may not be under the control of the same developers of the tested application, making it challenging to identify the external services and simulate various possible responses. In this article, we present a novel search-based approach aimed at fully automated mocking of external web services as part of white-box, search-based fuzzing. We rely on code instrumentation to detect all interactions with external services, and how their response data is parsed. We then use such information to enhance a search-based approach for fuzzing. The tested application is automatically modified (by manipulating DNS lookups) to rather interact with instances of mock web servers. The search process not only generates inputs to the tested applications but also automatically configures responses in those mock web server instances, aiming at maximizing code coverage and fault-finding. An empirical study on four open source REST APIs from EMB, and one industrial API from an industry partner, shows the effectiveness of our novel techniques (i.e., in terms of line coverage and fault detection).

Context: REST APIs are widely used in industry. These APIs use HTTP for their communications. Failures in following the specifications of HTTP can lead to confusing and hard to use APIs, with possibly serious software faults with dire consequences. Objectives: Define novel automated techniques to automatically find HTTP semantics-level faults in existing REST APIs. Methods: We extended the state-of-the-art fuzzer EvoMaster with 9 new oracles to detect HTTP semanticslevel faults. Once the standard fuzzing process is finished generating N test cases, a new phase is executed in which these N tests are used as a starting point to create new scenarios (i.e., new sequences of HTTP calls) aimed at validating specific HTTP properties defined in these 9 oracles. Results: Experiments on 9 artificial APIs with inject faults show that our novel techniques can successfully detect all of them. Further experiments on 36 APIs from the WFD corpus show that our novel techniques can automatically find 166 existing faults in these real-world APIs. Conclusion: REST APIs use HTTP, and, as such, they need to follow its semantics to avoid misleading their clients and introducing subtle software faults. The novel techniques presented in this paper are shown to be effective at automatically finding several of this type of faults.

REST APIs are widely used in industry. Therefore, a lot of research has been focused on how to automatically generate test cases for REST APIs, with few different open-source fuzzers existing in the literature. For a thorough testing, especially in black-box scenarios, just relying on the information provided in the OpenAPI schemas is not enough. Testers typically need to provide extra input data to help steer the fuzzers in the right direction. Dedicated formats specific to each different fuzzer would work, but they would create a vendor lock-in, as well as increasing cognitive load. The OpenAPI Initiative (OAI) standard Overlay might be a solution to this problem. Such standard enables to define transformations on the OpenAPI schemas, where testers can provide input data in Overlay files where such data is provided as “examples” entries. In this paper, we have extended the state-of-the-art fuzzer EvoMaster to support Overlay files natively. Experiments are carried out in industry on five APIs from five enterprises from around the world (e.g., Belgium, China, Germany and Türkiye), including two Fortune500 enterprises as well as a 3-man startup. Our industrial results show that Overlay is a viable solution to better enable black-box fuzzing of REST APIs in industry.

In RESTful APIs, interactions with a database are a common and crucial aspect. When generating whitebox tests, it is essential to consider the database's state (i.e., the data contained in the database) to achieve higher code coverage and uncover more hidden faults. This article presents novel techniques to enhance search-based software test generation for RESTful APIs interacting with NoSQL databases. Specifically, we target the popular MongoDB database, by dynamically analyzing (via automated code instrumentation) the state of the database during the test generation process. Additionally, to achieve better results, our novel approach allows inserting NoSQL data directly from test cases. This is particularly beneficial when generating the correct sequence of events to set the NoSQL database in an appropriate state is challenging or time-consuming. This method is also advantageous for testing read-only microservices. Our novel techniques are implemented as an extension of EvoMaster, the only open-source tool for white-box fuzzing RESTful APIs. Experiments conducted on six RESTful APIs demonstrated significant improvements in code coverage, with increases of up to 18

REST APIs are widely used in industry, in all different kinds of domains. An example is Volkswagen AG, a German automobile manufacturer. Established testing approaches for REST APIs are time consuming, and require expertise from professional test engineers. Due to its cost and importance, in the scientific literature several approaches have been proposed to automatically test REST APIs. The open-source, search-based fuzzer EvoMaster is one of such tools proposed in the academic literature. However, how academic prototypes can be integrated in industry and have real impact to software engineering practice requires more investigation. In this paper, we report on our experience in using EvoMaster at Volkswagen AG, as an EvoMaster user from 2023 to 2026. We share our learnt lessons, and discuss several features needed to be implemented in EvoMaster to make its use in an industrial context successful. Feedback about value in industrial setups of EvoMaster was given from Volkswagen AG about 4 APIs. Additionally, a user study was conducted involving 11 testing specialists from 4 different companies. We further identify several real-world research challenges that still need to be solved.

Test flakiness is a common problem in industry, which hinders the reliability of automated build and testing workflows. Most existing research on test flakiness has primarily focused on unit and small-scale integration tests. In contrast, flakiness in system-level testing such as REST APIs are comparatively under-explored. A large body of literature has been dedicated to the topic of fuzzing REST APIs, whereas relatively little attention has been paid to detecting and possibly mitigating negative effects of flakiness in this context. To fill this major gap, in this paper, we study the flakiness of tests generated by one of the popularly applied REST API fuzzer in the literature, namely EvoMaster, conduct empirical studies with a corpus of 36 REST APIs to understand flakiness of REST APIs. Based on the results of the empirical studies, we categorize and analyze flakiness sources by inspecting near 3000 failing tests. Based on the understanding, we propose FlakyCatch to detect and mitigate flakiness in REST APIs and empirically evaluate its performance. Results show that FlakyCatch is effective in detecting and handling flakiness in tests generated by white-box and black-box fuzzers.

Automated test generation has become a key technique for ensuring software quality. However, automatically generated test cases are typically assigned non-descriptive names, which reduces their readability and hinders their usefulness during comprehension and maintenance. While prior research has explored naming strategies for unit tests, little attention has been given to system-level REST API tests.In this work, we present three novel deterministic techniques to generate test names. We compare eight techniques in total for generating descriptive names for REST API tests automatically produced by the fuzzer EvoMaster, using 10 test cases generated for 9 different open-source APIs. The eight techniques include rule-based heuristics and large language model (LLM)-based approaches. Their effectiveness was empirically evaluated through two surveys (involving up to 39 people recruited via LinkedIn). Our results show that a rule-based approach achieves the highest clarity ratings among deterministic methods, performs on par with state-of-the-art LLM-based models.To evaluate the practical impact of our results, an industrial case study was carried out with practitioners who actively use EvoMaster at Volkswagen AG. A developer questionnaire was then carried out based on the use of EvoMaster on four different APIs by four different users, for a total of 74 evaluated test cases. Feedback from practitioners further confirms that descriptive names produced by this approach improve test suite readability. These findings highlight that lightweight, deterministic techniques can serve as effective alternatives to computationally expensive and security-sensitive LLM-based approaches for automated system-level test naming, providing a practical step toward more developer-friendly API test generation.

As software applications grow increasingly complex, particularly in their input formats, testing these applications becomes a challenging endeavour. Automated testing techniques, such as search-based white-box fuzzing, have shown promise in addressing these challenges. However, generating well-formed inputs for fuzzing remains a significant obstacle. In this paper, we present novel techniques as an academic proof-of-concept for automatically inferring JSON-based schemas to enhance search-based white-box fuzzing, focusing on Java and Kotlin applications. Our work offers an alternative approach to black-box grammar-based fuzzing.

Due to their widespread use in industry, several techniques have been proposed in the literature to fuzz REST APIs. Existing fuzzers for REST APIs have been focusing on detecting crashes (e.g., 500 HTTP server error status code). However, security vulnerabilities can have major drastic consequences on existing cloud infrastructures.In this paper, we propose a series of novel automated oracles aimed at detecting violations of access policies in REST APIs. These novel automated oracles can be integrated into existing fuzzers, in which, once the fuzzing session is completed, a “security testing” phase is executed to verify these oracles.Our novel techniques are integrated as an extension of EVO-MASTER, a state-of-the-art fuzzer for REST APIs. Experiments are carried out on a series of artificial examples and 13 real-world REST APIs. Results show that our novel oracles and their automated integration in a fuzzing process can lead to detect security issues in some of these APIs.

Search-based software engineering (SBSE), which integrates metaheuristic search techniques with software engineering, has been an active area of research for about 25 years. It has been applied to solve numerous problems across the entire software engineering lifecycle and has demonstrated its versatility in multiple domains. With recent advances in Artificial Intelligence (AI), particularly the emergence of foundation models (FMs) such as large language models (LLMs), the evolution of SBSE alongside these models remains undetermined. In this window of opportunity, we present a research roadmap that articulates the current landscape of SBSE in relation to FMs, identifies open challenges, and outlines potential research directions to advance SBSE through its synergy with FMs. Specifically, we analyze three core aspects: utilizing FMs to enhance SBSE, applying SBSE to advance FMs, and exploring the integration of SBSE and FMs. Furthermore, we present a forward-thinking perspective that envisions the future of SBSE in the era of FMs, highlighting promising research opportunities to address challenges in emerging domains.

Search-Based Software Testing (SBST) has seen several success stories in academia and industry. The effectiveness of a search algorithm at solving a software engineering problem strongly depends on how such algorithm can navigate the fitness landscape of the addressed problem. The fitness landscape depends on the used fitness function. Understanding the properties of a fitness landscape can help to provide insight on how a search algorithm behaves on it. Such insight can provide valuable information to researchers to being able to design novel, more effective search algorithms and fitness functions tailored for a specific problem. Due to its importance, few fitness landscape analyses have been carried out in the scientific literature of SBST. However, those have been focusing on the problem of unit test generation, e.g., with state-of-the-art tools such as EvoSuite. In this paper, we replicate one such existing study. However, in our work we focus on system test generation, with the state-of-the-art tool EvoMaster. Based on an empirical study involving the testing of 23 web services, this enables us to provide valuable insight into this important testing domain of practical industrial relevance. Our results indicate that fitness landscapes are largely dominated by neutral regions (e.g., plateaus), which make the search process challenging. We observe that the presence of information content in the landscape can improve search guidance, while boolean flags are a primary contributor to neutrality. These findings confirm prior results in unit testing but also reveal system-level differences, particularly in how branch types impact search effectiveness. These insights suggest the need for improved fitness functions, testability transformations, and search operators tailored to system-level testing.

Automated test generation has become a key technique for ensuring software quality, particularly in modern API-based architectures. However, automatically generated test cases are typically assigned non-descriptive names (e.g., test0, test1), which reduces their readability and hinders their usefulness during comprehension and maintenance. In this work, we present three novel deterministic techniques to generate REST API test names. We then compare eight techniques in total for generating descriptive names for REST API tests automatically produced by the fuzzer EvoMaster, using 10 test cases generated for 9 different open-source APIs. The eight techniques include rule-based heuristics and large language model (LLM)-based approaches. Their effectiveness was empirically evaluated through two surveys (involving up to 39 people recruited via LinkedIn). Our results show that a rule-based approach achieves the highest clarity ratings among deterministic methods, performs on par with state-of-the-art LLM-based models such as Gemini and GPT-4o, and significantly outperforms GPT-3.5. To further evaluate the practical impact of our results, an industrial case study was carried out with practitioners who actively use EvoMaster at Volkswagen AG. A developer questionnaire was then carried out based on the use of EvoMaster on four different APIs by four different users, for a total of 74 evaluated test cases. Feedback from practitioners further confirms that descriptive names produced by this approach improve test suite readability. These findings highlight that lightweight, deterministic techniques can serve as effective alternatives to computationally expensive and security-sensitive LLM-based approaches for automated system-level test naming, providing a practical step toward more developer-friendly API test generation.

With several microservice architectures comprising thousands of web services in total, used to serve 630 million customers, companies like Meituan face several challenges in the verification and validation of their software. The use of automated techniques, especially advanced AI-based ones, could bring significant benefits here. EvoMaster is an open-source test case generation tool for web services, that exploits the latest advances in the field of Search-Based Software Testing research. This paper reports on our experience of integrating the EvoMaster tool in the testing processes at Meituan over almost 2 years (i.e., between October 2021 and July 2023). Two user studies were carried out in 2021 (with two industrial APIs) and in 2023 (with three industrial APIs) to evaluate two versions of EvoMaster (i.e., v1.3.0 and v1.6.1), respectively, in tackling the test generation for industrial web services which are parts of a large e-commerce microservice system. The two user studies involve in total 321,131 lines of code from these five APIs and 27 industrial participants at Meituan. Questionnaires and interviews were carried out in both user studies with the engineers and managers at Meituan. The two user studies demonstrate clear advantages of EvoMaster (in terms of code coverage and fault detection) and the urgent need to have such a fuzzer in industrial microservices testing. Given its clear advantages, EvoMaster now has been integrated into the industrial testing pipelines at Meituan. To study how these results could generalize, a follow up user study was done in 2024 (with EvoMaster v2.0.0) with five engineers in the five different companies. Our results show that, besides their clear usefulness, there are still many critical challenges that the research community needs to investigate to improve performance further.

Web APIs, like for example REST, GraphQL and RPC APIs, are widely used in industry. Due to their importance, a lot of research work has been carried out in the recent years on test automation in this domain. Several fuzzers have been developed and evaluated in the research literature. EvoMaster is a state-of-the-art, search-based fuzzer for Web APIs. It is in active development, since 2016, and it is used in several enterprises around the world, like for example at Meituan and Volkswagen. In this paper, we present and discuss its most recent technical features, aimed at widening its adoption in industry. In particular, we discuss its release on Docker, its use in Continuous Integration environments such as GitHub Actions, and the support for test case outputs in Python. This enables us a better technology transfer from academic results to industrial practice. A video showcasing these new features is currently available at: https://youtu.be/l1ybs7SjvcA

Fuzzing REST APIs is an important research problem, with practical applications and impact in industry. As such, a lot of research work has been carried out on this topic in the last few years. However, there are three major issues that hinder further progress: how to deal with API authentication; how to catalog and compare different fault types found by different fuzzers; and what to use as case study to facilitate fair comparisons among fuzzers. To address these important challenges, we present Web Fuzzing Commons (WFC) and Web Fuzzing Dataset (WFD). WFC is a set of open-source libraries and schema definitions to declaratively specify authentication info and catalog different types of faults that fuzzers can automatically detect. WFD is a collection of 36 open-source APIs with all necessary scaffolding to easily run experiments with fuzzers, supported by WFC. To show the usefulness of WFC/WFD, a set of experiments is carried out with EvoMaster, a state-of-the-art fuzzer for Web APIs. However, any fuzzer can benefit from WFC and WFD. We compare EvoMaster with other state-of-the-art tools such as ARAT-RL, EmRest, LLamaRestTest, RESTler, and Schemathesis. We discuss common pitfalls in tool comparisons, as well as providing guidelines with support of WFC/WFD to avoid them.