Skip to content

The first open-source AI-driven tool for automatically generating system-level test cases (also known as fuzzing) for web/enterprise applications. Currently targeting whitebox and blackbox testing of Web APIs, like REST, GraphQL and RPC (e.g., gRPC and Thrift).

License

Notifications You must be signed in to change notification settings

WebFuzzing/EvoMaster

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

EvoMaster: A Tool For Automatically Generating System-Level Test Cases

Maven Central javadoc CI codecov DOI License: LGPL v3 Github All Releases

Summary

EvoMaster (www.evomaster.org) is the first (2016) open-source AI-driven tool that automatically generates system-level test cases for web/enterprise applications. This is related to Fuzzing. In particular, EvoMaster can fuzz APIs such as REST, GraphQL and RPC. Not only EvoMaster can generate inputs that find program crashes, but also it generates small effective test suites (e.g., in Python, JS and Java/Kotlin JUnit format) that can be used for regression testing.

EvoMaster is an AI driven tool. In particular, internally it uses an Evolutionary Algorithm and Dynamic Program Analysis to be able to generate effective test cases. The approach is to evolve test cases from an initial population of random ones, trying to maximize measures like code coverage and fault detection. EvoMaster uses several kinds of AI heuristics to improve performance even further, building on decades of research in the field of Search-Based Software Testing.

Key features:

  • Web APIs: At the moment, EvoMaster can generate test cases for REST, GraphQL and RPC (e.g., gRPC and Thrift) APIs.

  • Black-Box testing mode: can run on any API (regardless of its programming language, e.g., Python and Go). However, results for black-box testing will be worse than white-box testing (e.g., due to lack of code analysis). Default test case output is in Python, but other formats are available as well.

  • White-Box testing mode: can be used for APIs compiled to JVM (e.g., Java and Kotlin). EvoMaster analyses the bytecode of the tested applications, and uses several heuristics such as testability transformations and taint analysis to be able to generate more effective test cases. We support JDK 8 and the major LTS versions after that (currently JDK 21). Might work on other JVM versions, but we provide NO support for it. Note: there was initial support for other languages as well, like for example JavaScript/TypeScript and C#, but they were not in a stable, feature-complete state. The support for those languages for white-box testing has been dropped, at least for the time being.

  • Installation: we provide installers for the main operating systems: Windows (.msi), OSX (.dmg) and Linux (.deb). We also provide an uber-fat JAR file. To download them, see the Release page. Release notes are present in the file release_notes.md. If you are using the uber-fat JAR, it should work with any major LTS version (from JDK 8 on). Whereas for the client library, needed for white-box testing, we will support JDK 8 likely for a long, long while, be warned that future versions of the executable JAR might start to require higher versions of the JDK in a non-so-distant future. If that is going to be higher than your current version of the JVM, if you cannot upgrade or have 2 different JDKs on your machine, then you should not use the uber-jar but rather one of the installers. When you use one of the installers, keep in mind that currently they do not update the PATH variable. This needs to be done manually, see documentation.

  • State-of-the-art: an independent study (2022), comparing 10 fuzzers on 20 RESTful APIs, shows that EvoMaster gives the best results. Another independent study (2024) done by a different research group confirms these results.

  • Schema: REST APIs must provide a schema in OpenAPI/Swagger format (either v2 or v3).

  • Output: the tool generates JUnit (version 4 or 5) tests, written in either Java or Kotlin, as well as test suites in Python and JavaScript. For a complete list, see the documentation for the CLI parameter --outputFormat. Some examples are: PYTHON_UNITTEST, KOTLIN_JUNIT_5, JAVA_JUNIT_4 and JS_JEST. Note that the generated tests rely on third-party libraries (e.g., to make HTTP calls). These will need to be setup in your projects, see documentation.

  • Fault detection: EvoMaster can generate tests cases that reveal faults/bugs in the tested applications. Different heuristics are employed, like checking for 500 status codes and mismatches from the API schemas.

  • Self-contained tests: for white-box testing, the generated tests do start/stop the application, binding to an ephemeral port. This means that the generated tests can be used for regression testing (e.g., added to the Git repository of the application, and run with any build tool such as Maven and Gradle). For black-box testing, you will need to make sure the application is up and running before executing the tests.

  • SQL handling: for white-box testing, EvoMaster can intercept and analyse all communications done with SQL databases, and use such information to generate higher code coverage test cases. Furthermore, it can generate data directly into the databases, and have such initialization automatically added in the generated tests. At the moment, EvoMaster supports Postgres, MySQL and H2 databases.

  • Authentication: we support auth based on authentication headers and cookies. Besides using fixed HTTP headers, it is also possible to declaratively specify which login endpoint should be used to dynamically obtain authentication info (e.g., auth tokens or cookies) for each test execution. See documentation.

Known limitations:

  • Driver: to be used for white-box testing, users need to write a driver manually. We recommend to try black-box mode first (should just need a few minutes to get it up and running) to get an idea of what EvoMaster can do for you.

  • JDK 9+: white-box testing requires bytecode manipulation. Each new release of the JDK makes doing this harder and harder. Dealing with JDKs above 8 is doable, but it requires some settings. See documentation.

  • Execution time: to get good results, you might need to run the search for several hours. We recommend to first try the search for 10 minutes, just to get an idea of what type of tests can be generated. But, then, you should run EvoMaster for something like between 1 and 24 hours (the longer the better, but it is unlikely to get better results after 24 hours).

  • RPC APIs: for the moment, we do not directly support RPC schema definitions. Fuzzing RPC APIs requires to write a driver, using the client library of the API to make the calls.

  • External services: (e.g., other RESTful APIs) currently there is no support for them (e.g., to automatically mock them). It is work in progress.

  • NoSQL databases: (e.g., MongoDB) currently no support. It is work in progress.

  • Failing tests: the tests generated by EvoMaster should all pass, and not fail, even when they detect a fault. In those cases, comments/test-names would point out that a test is revealing a possible fault, while still passing. However, in some cases the generated tests might fail. This is due to the so called flaky tests, e.g., when a test has assertions based on the time clock (e.g., dates and timestamps). There is ongoing effort to address this problem, but it is still not fully solved.

Use in Industry

Several enterprises use EvoMaster to fuzz their Web APIs. We do few academia-industry collaborations (see more info here), where we help test engineers to apply EvoMaster on their systems, as long as we can then report on such experience. Example of Fortune 500 companies using EvoMaster are:

Videos

Alternatives

In the last few years, several few tools have been proposed in the academic literature and in the open-source community. You can read more details in this 2023 survey on REST API testing.

Existing open-source tools for REST API fuzzing are for example (in alphabetic order): CATS, Dredd, Fuzz-lightyear, ResTest, RestCT, Restler, RestTestGen, and Schemathesis.

All these tools are black-box, i.e., they do not analyze the source-code of the tested APIs to generate more effective test data. As we are the authors of EvoMaster, we are too biased to compare it properly with those other black-box tools. However, different independent studies (e.g., in 2022 and 2024) shows that EvoMaster is among the best performant. Furthermore, if your APIs are running on the JVM (e.g., written in Java or Kotlin), then EvoMaster has clearly an advantage, as it supports white-box testing.

Documentation

If you are trying to use EvoMaster, but the instructions in this documentation are not enough to get you started, or they are too unclear, then it means it is a bug in the documentation, which then would need to be clarified and updated. In such cases, please create a new issue.

Also, feel free to start new discussion topics in the Discussions forum. If you have time, please consider answering the polls there.

If you are working on an open-source API, you can drop us a message if you have problems using EvoMaster on it. Otherwise, if you are working in industry on closed-source APIs, we have options for academia-industry collaborations (see more info here).

Funding

EvoMaster has been funded by:

  • 2020-2025: a 2 million Euro grant by the European Research Council (ERC), as part of the ERC Consolidator project Using Evolutionary Algorithms to Understand and Secure Web/Enterprise Systems.
  • 2018-2021: a 7.8 million Norwegian Kroner grant by the Research Council of Norway (RCN), as part of the Frinatek project Evolutionary Enterprise Testing.

This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 864972).

License

EvoMaster's source code is released under the LGPL (v3) license. For a list of the used third-party libraries, you can directly see the root pom.xml file. For a list of code directly imported (and then possibly modified/updated) from other open-source projects, see here.