Shulou(Shulou.com)06/03 Report--

The content of this article is:

Test script management: describes how to design the directory structure of a test project on EOLINKER.

Writing test scripts: describes how to write interface test scripts on EOLINKER.

Test script execution and report: describes how to execute interface test scripts on EOLINKER, and how to view and download test reports.

Test project staff collaboration: describes how to collaborate on multi-person test projects on EOLINKER. 1. Test script management

Design the test project directory structure on EOLINKER to manage test scripts

Let's first take a look at EOLINKER's test script management rating:

Project management > test project management > test project module management (support sub-module and sub-module management) > test case set > single test case

Test script management rating

Project management

If you have only one project called "Little Fish Tour Web", including web version / app version / official account H5 version / Mini Program version, you can create each version of the test project through [New Automated Test] (as marked 1 in the figure below).

If you now have multiple projects, such as "small fish swimming Web" and "small fish swimming APP", and each project contains web version / app version / official account H5 version / Mini Program version, you can first create respective project directories for "small fish swimming Web" and "small fish swimming APP" by [New grouping] (as marked 2 in the figure below), and then enter each project directory. Create each version of the test project by [New Automated Test] (as marked 1 in the following figure)

In addition, if the project has been closed, you can use the "Archive" button in the project list, and the project will be moved to the list of [archived projects] (such as Mark 3 in the following figure). There is no essential difference between archived and unarchived. Just put it in a different folder.

Project Management Page

Through the previous operation, you already have a test project, you can enter the project to have a look.

1. If you need to know the current number of collaborators / project dynamics / number of test cases of the test project, please open the overview page

two。 If you want to create and manage test project modules, test case sets, and individual test cases, you can first check the scenario use cases page, which will be explained in more detail later

3. If you want to specify a batch of test case scripts to run automatically at the time you set, and send the test results to your specified mailbox, check them regularly. This function requires everyone to open the enterprise version before you can use it; if you already have the enterprise version, you can open the scheduled task page to see what it looks like, and we will explain it in detail later.

4. If you want to customize some variables or parameters of the public call, such as the default value of the http request (host url, request header, body parameter), to the public resource management page.

5. If you want to limit the rights of the test script, such as read-only / read-write, go to the collaborator to manage the page setup

6. Finally, if you want to import API documents and only look at the API documents of Xiaoyu Youyu Web project, you can set them in [referenced API Project] in Automated Test Management.

Test project management

Test project module management / test case set

Review what was said earlier: "if you want to create and manage test project modules, test case sets, and individual test cases, go to the scenario use cases page and talk about it in more detail later."

Click "scenario Test" to enter the test project module / test case set page

Create a project module directory by [New grouping] (as marked 1 in the figure below) (usually divided into two types: by business and by interface, you can press the interface when designing a single-interface test script and by business when designing a scenario test script). You can create sub-groups and sub-groups, that is, sub-modules and sub-modules, through the menu buttons behind the module directory.

After creating the module directory, we need to create a pair of application case sets under each module directory, and create their own use case sets through [New use case] (as marked 2 in the figure below).

Test Project Module / Test case set Page

There are two types of use case sets for EOLINER:

1. Common type-UI mode (default type): if you prefer the interface, you can choose this mode. You only need to fill in the blanks to complete the interface test script.

two。 Advanced type-code mode: if you like Javascript code, if you can do it again, this pattern will be more suitable for you

Create a new use case set pop-up window

Single test case

At this point, the project structure is complete, and you can start writing test scripts.

In the list of test case sets, click on a common type-UI pattern use case set, go to the single test case-common type [UI mode] page, and import the basic interface information (url/ request method / request protocol / parameter / return information) from the API document through [+ existing interface] (as marked 1 in the following figure). This makes it convenient for us to change the passing parameters and add verification information when designing the script. That is, to complete a use case scripting, how to do it, go to the next section Of course, if the developer does not write API documents in EOLINKER's API R & D management module, you can write test scripts through [+ blank interface] (as marked 2 in the figure below).

Single test case page-normal type [UI mode]

If you click on an advanced type-code pattern use case set, you will go to a single test case-advanced type [code mode] page with the following interface

Single test case page-advanced type [code mode]

two。 Write test scripts

As mentioned in the above section, there are two ways to write interface test scripts:

Import the existing interface document from the API document list (such as the following figure-API document list page) through the [+ existing interface] button, and then improve the interface test script based on the basic information of the interface document and add use case name and verification information (assertion). (recommended)

Through the [+ blank interface] button, fill in the blank interface document, and then add the use case name and verification information (assertion) to complete the interface test script.

Screenshot entry path: API R & D and Automation Test-> API R & D Management-> Xiaoyu Youyou Web (Web Development Project)-> API documentation

API document list page

If you are now writing the first test case script for the project on EOLINKER, you can follow these steps to write the test script:

Create a test environment and import it into a use case set

Create a pre-use case (such as login or registration)

Create a post-use case (such as logout)

Note: it is also possible to do steps 2-3 after step 5.

Import API documents (or add blank interfaces)

a. In the imported API document, edit the test case description (called interface name on EOLINKER)

b. In the imported API document, edit the request information

c. In the imported API document, edit the expected return information (here, fill in the return header and return parameters, if this part of the development has been completed, you can skip this step)

d. In the imported API document, add return header check

e. In the imported API document, add the returned result check

f. In the imported API document, add advanced settings

Click Save to complete the test script writing.

Description: after adding a new use case, basically repeating the 4-5 operation, it is still very convenient!

1. Create a test environment and import it into a use case set

In the test environment, we can customize the global variable of public URL (the host name where the API resides), add common request parameters, add public request header tags, and customize the method of adding public authentication.

The steps to create a test environment and import it into a use case set are as follows: gif dynamic diagram:

Create a test environment and import it into a use case set

GIF dynamic diagram description:

The first page is the test project list page.

The second page is the common resource management-test environment page for the test project, where the test environment is created.

The third page is the scenario use case page for the test project, where you import the test environment you just created.

two。 Create a pre-use case (such as login or registration)

The pre-use case, that is, the precondition, login or data initialization of the test case, does not support remote connection and operation of the database at present, but we can achieve the purpose of data initialization by calling the interface.

Let's assume that the login API document has been added in the API document list. Here, I use the [+ existing API] button to import the login interface from the API document list to create a pre-use case. The steps are as follows: GIF dynamic diagram:

GIF dynamic diagram description:

The first page is the scenario use case page of the test project, where you click "pre-use case", go to the list page of the pre-use case set, and then click "New pre-use case" to create a use case set called login. Click the new use case set to go to the pre-use case editing page.

The second page is the edit page for the front use case, (Note: clear the sample code in the editing window before creating a new use case or importing API), here

a. Click the "+ existing APIs" button, and then go to the API document list selection page, check the login interface, and click "OK" button to complete the API import.

b. Edit the imported API document, because there are three required parameters in the login interface here, so I define three variables, the value of the variable, which needs to be constructed by myself. The login parameters of each company are different, some are timestamp + random string + key, some are md5, etc., this part of eolinker has encapsulated md5 and sha methods, which can be called directly, or you can construct custom functions by yourself. The following figure shows the general function editing page. I think this piece is much easier to use than jmeter. For jmeter, you need to write a jar package with java, then import it in jmeter's test plan, and then write a beanshell script when you call it.

In addition, an assertion is written to test whether the pre-use case is correct, where "result_api_1.response" is the return information of the interface, which is of type string, so it is later converted to a json object with JSON.parse (), which is used by response.statusCode to get the value of the statusCode field in the return information.

c. After editing the API document, that is, write the pre-use case, you can click the test button to see if the login is successful. The test result here is the test failure, because my three pass parameters are empty.

d. Click [Save], and then click [return list] to return to the previous use case set list page.

The third page is the list of pre-use cases. 3. Create a post-use case (such as logout)

Post-use cases, that is, post-processing, return parameter processing, resource cleanup, or data cleanup.

The post-use case is the same as the pre-use case creation step, so the gif dynamic diagram is no longer available here.

4. Import the API document and complete the test script

Needless to say here, directly on the gif dynamic map, the picture does not understand, you can see the following dynamic diagram description (TT, the catalogue is very hard, request to add chicken legs.).

GIF dynamic diagram description:

The first page is the scenario use case page of the test project. Here, the test project module directory created before clicking [Common Interface], go to the use case set list page, and then click "New use case". Create a use case set called get the company list, and click the new use case set to enter the use case editing page.

The second page is the singleton list page, here

a. Click [+ existing APIs], and then go to the API document list selection page, check the login interface, and click "OK" button to complete the API import.

b. Click the Edit action button after the newly imported API document to enter the use case editing page.

The third page edits the page for the use case

a. Edit the interface name, that is, the use case name.

b. There is no need to pass parameters when accessing this API, so the request information is empty here.

c. The expected return parameters are usually filled in by the developer in the API document, so it is empty here.

d. There is no verifiable return header, so the return header verifies that it is empty.

e. Return the result verification. Here I use the JSON verification method. There is a "synchronous return parameters" button, and the XML verification method is also available. If the developer has written the expected return parameters, after clicking this button, all the returned parameters will be automatically imported into the verification field list.

f. For the advanced settings, I checked "execute the next use case when the use case verification fails]. If it is not checked, the subsequent use case will not be executed when the use case test fails; among them," when a certain verification rule is judged to be failed, still judge the rest of the rules] is checked by default, which means that if a field in the verification field list fails, other fields that have not been verified are still checked. Timeout limit. The default 5000ms, that is, 5 seconds, means that the test timeout will automatically be judged as a test failure.

Click [Save] and return to the singleton list page to complete the use case writing.

The fourth page is the singleton list page. Click the "+ pre-use case" button here, and select the use case to be added in the pop-up window, because you need to log in to successfully call the common API "get Company list". Here, you need to add a login pre-use case.

Note: the use case writing method of advanced type-code pattern is the same as the previous method of creating pre-use cases, so I will not elaborate here. If you really want me to write a use case writing about advanced type-code patterns, please leave a message and ask the leader to add drumsticks to me! (yes, I am so futile, I just want drumsticks.)

At this point, the correct way to write the test case is introduced, and then we can execute the previously written test case and view the test report.

This paper summarizes

This article is mainly to guide you how to use EOLINKER to design interface test project architecture, including how to project directory structure, how to write interface test scripts, how to execute test scripts and how to obtain test reports, as well as how to cooperate with many people. The last two parts will be introduced in the next article!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.