This article mainly introduces the small testing team in the interface testing practice encountered some things, if there is a coincidence 😊.

From 0 to 0.1 — Import HttpRunner

The easiest way for someone who does interface testing almost from scratch is, of course, to stand on the shoulders of giants. So I went to TesterHome, a popular website for testing children, saw HttpRunner with the most liked HttpRunner among a few items, browned through it and decided to go ahead with 😂.

HttpRunner project structure is clear and simple, very beginner friendly.

├ ─ ─ the env ├ ─ ─. Gitignore ├ ─ ─ debugtalk. Py ├ ─ ─ data ├ ─ ─ reports └ ─ ─ the testcases ├ ─ ─ demo_testcase1. Yml └ ─ ─ demo_testcase2.ymlCopy the code

The general installation steps are as follows:

  1. Run the PIP installation commandpip3 install httprunner;
  2. View the HttpRunner version:hrun -V;
  3. Use scaffolding to quickly create projects:httprunner startproject PROJECT_NAME;
  4. Modify the quickly created demo based on your own project;
  5. performhrunCommand to view the report.

The following figure pastes the structure diagram of our project and the report that has been run before.

Attached here is the official document, you can almost consult the official document to solve your questions.

With the tools in place and the framework in place, it’s time to start your own project. Most of the interfaces can be obtained through the packet capture tool, and the parameters are easy to deal with, but for some time-sensitive parameters that need to be encrypted and decrypted, we need to communicate and learn more with the developers. HttpRunner: HttpRunner: HttpRunner: HttpRunner: HttpRunner: HttpRunner: HttpRunner: HttpRunner: HttpRunner: HttpRunner

  • Setup_hooks: Trigger hook functions before the entire use case starts execution, primarily for preparatory work such as parameter encryption;
  • Teardown_hooks: Trigger hook functions after the entire use case has finished executing, primarily for post-test cleanup, such as token saving.

The following is a use case of the login interface in our project. Set_signatures function is called in setuP_hooks for parameter encryption and verification. Save_token in teardown_hooks Function save_token in teardown_hooks function save_token in teardown_hooks function save_token in teardown_hooks

- name: / XXXX/XXX /v1/codeLogin -- verification codeLogin request: headers: signature:?????? aaaaaaaaa: ?????? bbbbbbbbb: ?????? json: CCCCCCCCC: ?????? DDDDDDDDD: ?????? phone: $phone method: POST url: xxxx/xxx/v1/codeLogin setup_hooks: - ${set_signatures($request)} teardown_hooks: - ${save_token($response)}Copy the code

At this point, our interface testing has begun.

0.1 to 1.0 – HttpRunner V3. X

As time went on, the work got more and more boring. Each new interface is repeated over and over again — packet capture, packet data export, YML file generation, TestCase file modification, running. Repetitive and unproductive work makes team members less likely to do it.

Later, our team members learned about pyTest framework in the process of learning Python, and our interface test ushered in an iterative update. Knowing that HttpRunner 3.x supports the PyTest framework perfectly, we upgraded the previous framework. Since everyone is learning Python, every test partner actively participated in the transformation, which improved everyone’s enthusiasm for work and helped them consolidate the knowledge they learned.

The picture below shows the coexistence of YML files and py files during the transformation process (here thanks to the developer for helping us batch process yML files into py files ❤️ according to the template).

It was also in the process of this transformation that we discovered the problems we had neglected before. Due to the full participation of the test team, each child is responsible for different modules, everyone just added their responsible interface and ignored the dependency between the interfaces, resulting in a large number of errors after the implementation of the new module is added.

This is also one of the issues raised in the official documentation — testCases and TestSuites. Each test case should be complete and run independently, and test case sets are there to facilitate regular batch execution. You must remember to divide the functional modules in the initial design.

(👆🏼 above from official documentation)

The entire iteration from 0.1 to 1.0 also taught us that whether building a testing framework or doing interface testing, we should not be obsessed with which language or framework to use, but should use “tools” that team members are familiar with and easy to use. At the end of the day, tools are about helping us work more productively, not putting the cart before the horse.

1.0 to 2.0 – Apifox

Why did the introduction of Apifox turn into a 1.0 to 2.0 — the difficulty of not having enough people to work on projects was real, just in time for developers to introduce the Apifox tool to solve the problem of testing and front-end development working together efficiently. The following excerpt from Apifox’s github project is, I think, no exaggeration.

Postman + Swagger + Mock + JMeter Apifox is an integrated platform for API documentation, debugging, Mock and testing. It solves the data synchronization problem among multiple systems by using one set of systems and one piece of data. Once the API documentation is defined, API debugging, API data Mock, and API automation testing can be used directly without further definition. API documentation and API development debugging use the same tool, API debugging can be guaranteed to be exactly the same as the API documentation definition. Efficient, timely and accurate!

Here is a brief introduction to Apifox:

  1. Item Settings: Item Settings ➡️ Import data ➡️ Modify configurations ➡️ Import data immediately. Refresh the data before each run so you don’t have to worry about keeping up with the developers.

  2. Global variable configuration, environment configuration:

  3. Common script configuration, including pre-action and post-action:

    Intercept part of the pre-operation code:

    var sign = createSignatureJson(pm.request.method, req); // replace the request entry with pm.request.body.raw = json.stringify (sign.sortData); Pm.request.headers. Add ({key: 'signature', value: sign.signature});Copy the code

    Truncated part of the post-operation code:

    Var jsonData = pm.response.json(); Parse (jsondata.data) var data = json.parse (jsondata.data) // Write the value of jsondata.token to the variable pm.globals.set('token', data.token); pm.globals.set('member_id', data.member_id);Copy the code

  4. Add interface: Interface management ➡️ Create a group ➡️ Create an interface. If interface development has been added, just use it. If not, the shortcut is to copy the entire URL directly in the packet capture tool and paste it in the interface path (2). Apifox will automatically fill the params, and other fields marked in red need to be added and saved manually. Use cases after running are also saved in time.

  5. Create interface test cases: automated tests ➡️ test cases ➡️ Create groups ➡️ Create use cases (if the mock and syncretation work well, most of the use cases can be imported automatically).

  6. Run the use case to view the report:

conclusion

Now this article is about to end, I hope the method introduced in this article can provide you with a little help, you can also leave a comment in the comments section. Finally, I remind you not to blindly follow the trend of choice. What suits you at a certain stage is the best.

More exciting, please pay attention to our public number “100 bottle technology”, there are not regular benefits!