Readyapi

ReadyAPI DocumentationInstallationInstall ReadyAPI from the Command LineThis page explains how to install ReadyAPI from the command line.For a typical installation process, see the Installation Guide.To learn how to install VirtServer, see VirtServer Installation.Before installationTo run ReadyAPI, your computer must meet certain system requirements.Also, you will need either a ReadyAPI trial license or a commercial Pro license for one or all ReadyAPI tools (ReadyAPI Test, ReadyAPI Performance, ReadyAPI Virtualization). A Pro license for one of the tools enables the basic functionality of the other ones.Before the first ReadyAPI run, you need to install a license.For current ReadyAPI users:If you have an active license of ReadyAPI, you do not need to activate a new license.VirtServer requires a separate license.Ubuntu prerequisitesImportantIf you install ReadyAPI on the Ubuntu operating system, you should run the following command to avoid an error during the installation:sudo apt-get install fontconfigDownload installerVisit the ReadyAPI Downloads Center and download the ReadyAPI Linux installer of the desired bitness. This package includes JDK, so you can use it on a machine without installing Java. To install ReadyAPI on a headless machine, follow the instructions below.To download a package on a headless machine, you can use curl or a similar tool:Installation stepsThe following instruction describes the process of installing ReadyAPI on a headless machine.Prepare the installation file:Run the installer with the -c argument:If ReadyAPI is already installed on your computer, you will be asked whether you want to update the current installation or install the product anew to a different directory.After the installation is complete, you can run ReadyAPI command-line tools to run tests:TestRunnerAbout Security TestRunnerAbout Performance TestRunnerAbout Automating Virtual Service RunsCommand-line argumentsBelow is a short list of command-line parameters you can use to install ReadyAPI on a headless machine. For the complete list of parameters, see install4j help.-h, -help, or /?: Displays the list of available command-line arguments.-manual: Commands the installer to act as if no JRE has been found and displays the dialog where you can choose a JRE or download one if a JRE has been bundled dynamically. If you locate a JRE, it will be used for the installed tool.ImportantYou can apply this parameter to Microsoft Windows only.-c: Executes the installer in the console mode, that is, the interaction with the user is performed in the terminal from which the installer was invoked.-q: Executes the installer in the unattended mode, that is, there is no interaction with the user, and the installation is performed automatically with the default values.-g: Executes the installer in the GUI mode.TipUse this parameter if you configured the installer default execution mode as the console or unattended one.-console: Displays the installer output, if the installer is executed in the unattended mode and the -console parameter

The startup, shutdown, Before Request, and After Request scripts to perform initialization, cleanup, or dispatch and handle requests to the virtual API.Create load and save scripts that will trigger when you open or save your project respectively.Store scripts common for your projects in Groovy Script libraries and reuse them whenever you want.Generate data for test cases with data source scripts.Save the test case run data with data sink scripts.Generate property values dynamically with DataGen script properties.You can find some examples of script usage in the Groovy Scripting Samples section.Supported languagesCurrently, ReadyAPI supports the following languages:You can select the scripting language to be used in the project properties. We recommend using Groovy scripts in your tests, since ReadyAPI offers code completion and debugging of Groovy scripts.Libraries and script collectionsScripting editors in ReadyAPI give you access to several types of scripting objects:Libraries that come pre-installed with ReadyAPI, including a number of standard Groovy and Java classes.External Java libraries that you can add if the pre-installed libraries do not satisfy your needs.Custom collections of Groovy scripts that you can create and reuse throughout your projects.To learn more about customizing your scripting needs, see the Script Libraries section.ImportantReadyAPI uses a number of third-party libraries. It is quite possible that we will update some of these libraries or even remove them from ReadyAPI. If you use classes from these libraries, you will have to update your scripts. See a list of third-party libraries updated in ReadyAPI 3.48.Object referenceScripting also allows you to access objects of

ReadyAPI DocumentationAboutReadyAPI allows teams to create, manage, and execute automated functional, security, and performance tests in one centralized interface – accelerating API quality for Agile and DevOps software teams.ReadyAPI provides three modules on a single platform:In ReadyAPI Test Module, you create functional tests to verify that your service works as expected. You can quickly create simple tests or build complex tests by using data-driven loops, property expansion, scripting, and so on.You can also use security tests with predefined and custom security scans to verify that your service can resist the most common attacks.In ReadyAPI Performance Module, you simulate a massive load on your web server to see how it works under these conditions. You can use various testing strategies to test different aspects of your server. With ReadyAPI Performance, you can run tests in parallel, as well as distribute tests among several test computers.In ReadyAPI Virtualization Module, you virtualize your service to continue its testing regardless of the development stage. It allows you to create a complex behavior and simulate a real behavior. In addition, you can use VirtServer to run your virtual services in your network.Why ReadyAPI?Helps teams create automated, end-to-end workflows to drive complex functional, security, and load testing with or without scripting knowledge.Enables seamless integration of API testing into a CI/CD pipeline, with native plugins for popular tools like Jenkins, TeamCity, and Azure Pipelines as well as a Command Line Utility.Tests performance by generating local or cloud-based load against critical endpoints and web services.Virtualizes and emulates services

ReadyAPI DocumentationWhat's NewVersion HistoryFeatures added to ReadyAPI 3.5.0The new version includes a number of improvements to make API testing easier and more powerful. Below is the list of changes relative to the previous version of the product – ReadyAPI 3.4.5. For information on the changes made to other versions, see Version History.Performance testingThe AppDynamics monitors have a new option – – that specifies how frequently a monitor pulls data from the AppDynamics server.Load-testing-related options of data sources are now available right in ReadyAPI Performance:Besides that, when you do not share the data source between virtual users, ReadyAPI visually shows you that a virtual user will go through the data source loop. To learn more, see Data Source in Load Testing.The PerformanceTestRunner utility now supports encrypted projects. To specify a project password, use the new -x argument of the command line.Overall improvementsUI improvements:You can import or create a new project in the workspace’s flyout menu:Also, when your workspace is empty and has no projects, you can now create or import projects right from the Navigator panel:We’ve also made a few minor visual improvements.ReadyAPI now uses OpenJDK 15.Newer versions of some libraries used in version 3.5. If your scripts refer to classes from these libraries, you might need to update the scripts.We have fixed a few bugs reported by our customers.Discontinued supportReadyAPI no longer supports the following operating systems:Windows 7Mac OS X 10.7, OS X 10.8 - 10.11, macOS 10.12macOS ServerSuse Enterprise Server 10 SP2Ubuntu 10.04 - 18.04See AlsoVersion History

ReadyAPI DocumentationPerformance TestsBest PracticesRunning Load Tests from MavenIf you are using Maven in your development environment, you can include ReadyAPI Performance tests in your builds. To do so, you command Maven to download and use the ReadyAPI Maven plugin in your project.RequirementsTo run load tests from Maven, you need to have the following on the computer, where you are going to run a Maven build:A pom.xml file with a reference to the ReadyAPI Maven pluginReadyAPIYour ReadyAPI project fileYou do not need to configure your environment specifically for running load tests, and any required dependencies will be handled by Maven.Pom FileMaven reads details about the build from the pom.xml file. You need to configure it to get the ReadyAPI plugin from the Maven repository and add a load test to the test phase of the build lifecycle.You can find a sample Maven configuration below. If you already have your own configuration, copy the necessary elements to it.Running Load TestTo start the load test, use the Maven test command in the folder with your pom.xml file. This command will run the load test and generate reports for it. For example:C:/Work/MvnSample> mvn testIf your tests use the Maven SureFire plugin to create reports, use the site command instead.C:/Work/MvnSample> mvn siteSample Maven Load TestBelow is a sample pom.xml file that runs the Baseline-load-test-project.xml project. You can find this project in the folder. To use the sample:(Optional) Start virtual service from the project. This step is not required, but having a running virtual service will provide meaningful results.Create a new pom.xml file and copy the sample code to it. Make sure to specify the same version as the ReadyAPI version you have.Place the Baseline-load-test-project.xml project file in the folder where the pom.xml file is located.Run the Maven build by using the mvn site command as described above.You can specify additional properties of the load test by removing comments on unused elements and entering the parameters.If you already have a pom.xml file, copy the elements to it to include a load test in the build. 4.0.0 com.mycompany.app my-app 1.0 SmartBearPluginRepository com.smartbear ready-api-maven-plugin 1.6.1 test loadtest Baseline-load-test-project.xml Baseline Load Test (Geocoding) PDF true Maven Surefire reports. Must be as shown. --> in. --> ${basedir}/target/surefire-reports true :: (for example, 60:0:200)--> this value.--> =--> if the runner terminates requests running at the moment the test is stopped.--> if the load is simulated from the local computer.--> false, configured agents are used.--> scenario) --> =--> =--> in the test run.--> Information on Plugins UsedThis example uses the Maven Surefire Plugin to generate JUnit XML reports and the Maven Site Plugin to improve test stability. Depending on the changes to the plugins, you may need to change the pom.xml file. For

TestEngine stage('Pass Results') {//Pass Results to Zephyr Scale }}Now we need to be a little more specific with the 'Run API Tests' Stage. Above I mention when we run our API Tests in an automated fashion, we need to write the results to a relative location so that we can then send those results to Zephyr Scale from that location. Both ReadyAPI and TestEngine allow us to write results to locations as part of the command-line or native integrations. I will show command- line options for ReadyAPI and UI native integration for TestEngine but both options are available for both tools.Starting with ReadyAPI, testrunner CLI, the -f and -F flags represent the directory we are writing to, and the report format, respectively. ReadyAPI offers reports in PDF, XLS, HTML, RTF, CSV, TXT and XML, but the automation recommendation would be to pass results in the Junit-XML option. At a basic level we need this:testrunner.bat [optional-arguments] And we need to specify -f and -Ftestrunner.bat -f -F and with -f requiring a relative directory, that can change based on the CI system. I will use Azure Dev Ops for both my examples here. In Azure I pull my test cases from the $(System.DefaultWorkingDirectory), which contains my git repo.In Azure I publish results to the $(Common.TestResultsDirectory) An example full command would look like this:"C:\Program Files\SmartBear\ReadyAPI-3.40.1\bin\testrunner.bat" -r -a -j -f$(Common.TestResultsDirectory) "-RJUnit-Style HTML Report" -FXML "-EDefault environment" "$(System.DefaultWorkingDirectory)/"With TestEngine it's very similar, but I am highlighting it through the native integration, note the publish test results and save Junit report option enabled below:Now lastly, we need to send the results to Zephyr Scale from the pipeline, before our release is over. I think it's easiest with the Zephyr Scale API: along with the Auto-Create Test Case option to true. The command below is a basic