Here we take the WebService interface of qqCheckOnline as an example. Explain, the specific information of the interface is as follows:
l interface Description: Get Tencent QQ online status
l Entry : QqCode, String type, default QQ number: 8698053
l Reference: qqCheckOnlineResult, String type
The meaning of the returned data is: Y = Online; N = offline; E = QQ number error; A = business user verification failed; V = more than free users
l Return format:
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
After understanding the interface information, let’s take a look at how to complete the design of the interface use case script. The general steps are shown in Figure 5.1.
Figure 5.1 Interface use case script design steps
< p style="margin-top:16px;margin-bottom:16px;padding:0px;color:rgb(34,34,34);font-family:'PingFang SC','Hiragino Sans GB','Microsoft YaHei' ,'WenQuanYi Micro Hei','Helvetica Neue', Arial, sans-serif;white-space:normal;background-color:rgb(255,255,255);">5.2.1 Single interface test method
After completing the preliminary settings according to the steps shown in Figure 5.1, the script structure is shown in Figure 5.2 As shown, this is the simplest script state, and there are still many places we need to optimize and improve. Below we will explain the common optimization methods separately. Note: All subsequent operations are done in TestSuite.
Figure 5.2 Script structure
According to the information of the interface, we may need to consider a variety of situations when designing test cases, including but not limited to correct QQ number, wrong QQ number, online QQ number and offline QQ number and so on to verify the correctness of the interface in various situations, specific use cases need to be designed according to specific interface information. Here we only take the correct and online QQ number as an example to explain.
1. Parameterized
Open the qqCheckOnline interface under our TestSteps, as shown in Figure 5.3, you will find that the qqCode is hard-coded. Obviously this is not what we want, we hope it is “alive” here.
Figure 5.3 qqCode
How to make this parameter “live”? At this time, we must use the powerful function of DataSource. DataSource can be parameterized through a variety of external media, such as:
l File: The form of a text file.
l Excel: It is best to use Excel in 2003 format .
l Grid: table format.
l JDBC: JDBC data source is from the database Get in.
l XML: XML format.
l Groovy: Groovy script form.
Here we use File type text file format Parameterization, the approximate implementation steps are as follows:
1) Create a new text file on the local computer: qq.txt, and enter the content as shown in Figure 5.4 in the file.
Figure 5.4 qq.txt
2) Create a new DataSource, fill in the relevant data information, pay attention to its order to be located before the interface. As shown in Figure 4.5.
Figure 5.5 DataSource
The explanation of some fields is as follows:
l DataSource: Select an external storage medium.
l File: select the file path.
l Properties: Obtain from external storage media The results are saved here.
l The rest of the fields can be left as default.
3) Switch to the qqCheckOnline interface and write before The dead qqCode becomes “alive”. Just right-click the qqCode parameter and select Properties in the corresponding step under “Get Data”. As shown in Figure 5.6.
Figure 5.6 Get Data
4) Add DataSource Loop to complete the parameterized traversal. If you don’t add this, the first QQ number will always be retrieved. The final script structure is shown in Figure 5.7. Among them, DataSource Step is the selected source data, and Target Step is the selected target step. Here you need to pay special attention to the order of DataSource, Interface, and DataSource Loop.
Figure 5.7 DataSource Loop
2. Assertions (checkpoints)
Since we are automating the function of the interface, we must check the returned response data (out parameters), and only meet our expected results In order to think that the interface has passed the test, to complete this thing, you need to use assertions, which are commonly referred to as checkpoints. The general implementation steps are as follows:
1) Double-click the interface in TestSteps and run it, add an assertion to the content you want to check in the response area, right-click and select Add Assertion-> for Cotent, as shown in Figure 5.8.
Figure 5.8 Select assertion
2) In the pop-up “XPath Expression” dialog box, we can see that the content to be checked is identified as the value Y corresponding to qqCheckOnlineResult, just click the “save” button, as shown in Figure 5.9 Show.
Figure 5.9 Confirm Assertion
3) The final result is shown in Figure 5.10, where Assertions represent assertions.
Figure 5.10 Assertion effect map
There are many types of assertions in SoapUI, which can be described as very powerful. You can click “Add Assertion” to view them. For details, see Chapter 5 in the book.
3. Run and report
After completing the above steps, you can run this use case script, double-click this TestCase, and click the “small green arrow” in the pop-up “qqCheckOnline TestCase” dialog box, as shown in Figure 5.13. If you want to see the test report generated by SoapUI, just click the “document” icon. The test report style is shown in Figure 5.14.
All single-interface tests like this are probably the process. You need to make certain adjustments according to the specific interface information, but the overall ideas and methods are similar, and I hope everyone will continue to learn. You can realize the principle of “One Pass Belden” in this course, so that even if you only have 2 years of work experience, you may surpass a friend with 5 years of work experience.