Due to project reasons, I researched and used the SoapUI testing tool some time ago for self-test development of the API. The results of the research are shown below, hoping to be helpful to those in need.
What is SoapUI?
SoapUI is an open source testing tool that checks, calls, and implements function/load/compliance testing of Web Services through soap/http. This tool can be used as a stand-alone testing software or integrated into Eclipse, maven2.X, Netbeans and intellij using plug-ins.
SoapUI installation
Download address , it is best to download the latest version of the installation package, because SoapUI is a testing tool developed based on java. The installation package of versions prior to 3.0 does not integrate JRE, so you have to install and configure the java runtime environment yourself.
How to use SoapUI
1. In the File menu of the main interface, click "New REST Project" and fill in the URL you want to test. According to the URL in our project Teacher Site, for example: https://teacher-test.grapecitydev.com :
Referring to the figure below, you need to enter the /Login/Login route in the Resource input box, and enter the query parameters accountName and password required for login in Params.
2. Click the green button, SoapUI sends a login request, and you can see the result returned by the login request in the right box.
According to the business requirements of the Teacher site project, after sending the Login request, the SchoolItemChange interface must be sent to return the Token authenticated after the user successfully logs in. The value of Set-Cookie in the figure below will be used in the Cookie attribute in the request header of the next GetOverview interface. :
3. The next third request to GetOverview is as shown below. Add the Cookie attribute in the Header box. The value is the Set-Cookie value returned by the previous request SchoolItemChange:
automated test
In fact, the calls to the above three interfaces are just a simple test of whether the interfaces are called normally. If you want to perform automated testing on the calls to the three interfaces, please see the following decomposition:
1. Right-click the Request request under each interface, as shown in the figure, select the "Add TestCase" item, and set the Test Case for the above three interfaces in sequence. Under TestSteps, there are three TestCases: Login, SchoolItemChange, and GetOverview.
2. Have you noticed that there is an additional Set Cookie item under Test Steps? What does this do?
This is to obtain the return value of the previous request through Groovy Script syntax (here, get the return value "Set-Cookie" of the SchoolItemChange interface), and assign the "Set-Cookie" attribute value to the request header Cookie of the next request GetOverview. , doesn’t it fit in well with items 2 and 3? ! This solves the problem of automated interface testing without having to copy and paste the dependent return values between requests.
3. Next, add an Assertion to the tested interface. Click in the lower left corner to pop up the Add Assertion dialog box. According to the assertion annotation, select the required test point. For example, Response SLA represents the expected response time after the request is sent:
Contains Assertion means that the string returned by the request contains the specified string. The content for which this assertion applies to comparison does not exceed 65535 characters. Because Soapui is written in Java language, this is the maximum number of characters supported by JVM:
4. In order to solve the above problem of not exceeding 65535 characters, you need to add Script Assertion to the interface. The following code means to compare the content in the local file GetOverview 01.txt with the value of the HtmlOfPartialView attribute in the request return to determine the content of the two. Are they equal:
5. Double-click Test Case, as shown below, click the button, or right-click Login and select "Run from here" to execute the Test Steps in sequence. As shown in the figure, the word "Failed" appears with a red background. Check the TestCase Log box in the lower right corner. You can It can be seen that the response time of the Step 4 GetOverview interface request is 1272ms, which is greater than the time 500ms set in the assertion:
Send email function
When you want the result of an interface request to be notified to you by email, as shown in the figure below, right-click Test Steps -> Add Step -> Groovy Script, and add the Send Email script, where Username and Password are the accounts of the company's mail server respectively. and password, the Internet Address is the receiving email address.
The order of "${teacher-test#TestCase#Getoverview#Response}" is as follows
Test Suite name # Test Case name # Test Step name # Response：
pressure test
The above is the functional test, and the next is the stress test. Right-click Load Tests to create a test case.
Limit: 60 is the stress test time of 60 seconds. Thread represents multi-threading and can run 5 threads at the same time. Test Delay * Radom represents the number of random delays.
min represents the minimum response time, max represents the maximum response time, avg represents the average response time, last represents the last request response time, cnt represents the number of requests, tps represents the number of requests processed per second, bps represents the throughput rate, and rat represents the error rate.
Right-click to add assertions to the request, Max Errors sets the maximum number of errors, Step Average sets the expected average time, and so on:
As shown below, you can choose different strategies for load and performance testing:
The most commonly used strategy is Simple. If you want to run a functional test and want to delay 5 threads within 10 seconds, set Threads to 5, delay 1000s, and random delay ratio 0.5 (which will cause a delay of 5 to 10 seconds) .
Variance strategy (Variance), Threads is the number of threads for the variance, and Interval is the required value for the interval setting. For example, if you set 20 threads, an interval of 60, and a variance of 0.8, the number of threads will increase from 20 to 36 in the first 15 seconds, then decrease to 20, continue to decrease to 4 threads after 45 seconds, and finally return at 60 seconds. to the initial value of 20. We can easily follow this variance in a statistical plot:
Linear strategy (Thread), number of runs from one thread to another. Its main function is to determine the level when certain statistics change or event occurs, such as setting the start and end thread values (for example 1 - 10), and setting the duration (at least 30 seconds per thread in this example) to get accurate Measurement data:
continuous integration
Perform continuous integration on the UI interface: right-click the project name REST Project 1 -> select Launch TestRunner, the following picture will appear, select the TestRunner installation path on the Basic Tab page:
Select the report output folder on the Reports Tab page:
Click the Launch button to automatically execute the test project.
Perform continuous integration by executing commands, open the Command Prompt dialog box as an administrator, and execute the following commands:
testrunner.bat -s'teacher-test' -cLogin -r -j -f'D:\Trivals\SoapUI\Logs' D:\Trivals\SoapUI\REST-Project-1-project.xml
The meanings of each parameter on the command line are as follows:
- s : The TestSuite to run, used to narrow down the tests to run
- c : The TestCase to run, used to narrow down the tests to run
- r : Turns on printing of a small summary report (see below)
- j : Turns on exporting of JUnit-compatible reports, see below
- f : Specifies the root folder to which test results should be exported
[Full 200 episodes] A collection of super detailed advanced tutorials on automated testing of Python interfaces, truly simulating the actual combat of enterprise projects.