Service interface test guide

The first goal of testing is quality assurance , So from the perspective of quality assurance , To understand interface testing .

1、 Understand interfaces

1.1 What does the interface do ？

First , Understand... From a functional perspective .
such as , Understand from the business process of a user purchasing a product ：

New user registration ： Through the registration interface Add a new user data （Create）;
Login after successful registration ： Through the login interface , First, query according to the user name （Select） password , Then verify the password , Password verification succeeded , Through rules and encryption newly build （Create）token Signature , take token Send to client ;
Search for products ： Search the target product through the product search interface , The essence is to query conditions from the commodity database （Select）;
Check product details ： goods ID + Product details interface , Check product details （Select）;
Select items to add to the shopping cart ： Add shopping cart interface , Update shopping cart data , Inventory data minus one （Update）;
Create an address and select an address ： Create a new address interface , Add a new address （Create）;
Place an order & Settlement ： Order interface , Add a new order data （Create）;
payment ： Payment interface , If the payment is successful , Add a payment message , Order status updated to paid , Add a new piece of logistics information .
The main function of the interface is the data interaction between the client and the server , That is, add, delete, modify and query the back-end data through the interface , To realize the interaction between users and products .

1.2 How to ensure interface quality

From the registration interface of Jingdong website , From what latitude do we need to ensure quality .

Analyze the registration interface

Registration page ：

Http Registered interface ：

Request Header:

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Content-Length: 6028
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: shshshfpb=sJZnAsUTcZJjuNedVMhztBA%3D%3D; 
Host: reg.jd.com
Origin: https://reg.jd.com
Referer: https://reg.jd.com/reg/person?ReturnUrl=https%3A//www.jd.com/
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
X-Requested-With: XMLHttpRequest

Request Body：（ Ignoring part cannot interpret parameter ）

uuid: 68455e864c894bda845de413849204d0
authCodeStrategy: 1  ( Verification code policy )
phone: +00861553605xxxx（ cell-phone number ）
mobileCode: 116547（ Mobile phone verification code ）
regName: demo83520（ Registered user name ）
email: [email protected]（ Sign up for email ）
mailCode: 661591（ Email verification code ）
pwd: MvaEqtzkZ4/R4P3wMoRIuZpA4egWYBmz7bikspIWRYwozJgOHJQlQW8POp8elFhi7OXchoz1OPRoFwxqjWpwcWQCUABx5oovhFxLZ0p8CqB3s0lNDz9QlF8ZYMBanwk+Cne4mXMOTop9OGD8XF8YPqb4qkox8A=（ Password encryption string ）

Next , From the perspective of interface development and design , Analyze the registration interface . Because it is a pure black box angle , So from UI The design logic of the registration interface is analyzed from two aspects of interaction and interface parameters .

UI Interaction angle analysis

Same mobile number 、 Different mailboxes can register at most 3 Accounts ;
user name ： Support Chinese 、 english 、 Numbers 、” - “、”_” The combination of ,4-20 Characters , It can't be pure numbers ; User name cannot be duplicate ;
password ： Length can only be in 8-20 Between characters , It is recommended to use letters 、 Two or more combinations of numbers and symbols ; Do not register frequently ;

Interface parameter analysis （ Take several main parameters ）

uuid： The only user ID？uid Generate rules ？
phone： Register mobile number format verification ？
mobileCode： Number of mobile phone verification codes 、 Character type checking ？
regName： User name rule verification ？
email： Register email format verification ？
mailCode： Email verification code digit 、 Character type checking ？
pwd： Password encrypted string

2、 How to test the interface

The interface test , There are three main steps ：

Prepare test data （ It may not be necessary ）;
API Testing tools , Initiate request ;
Verify that Response;

（1） Test data

Test data generation method ：

be based on API Generate the data ;
The database directly constructs data ;
UI Operation generates data ;

Generation time ：

Create in real time ： Generated during test case execution （ It will lead to longer test case execution time ）;
Create in advance ： Before test execution , Generate all test data in batch （ The data created in advance may have been modified and cannot be used normally ）;

Be careful ️： The test environment is unstable , It will affect the smooth creation of test data ;

Dirty data ：

Concept ： Dirty data means , Data before it is actually used , Unexpected modifications have been made .

Test data classification ：

“ Dead water data ”： Means relatively stable , It will not change the state during use , Data that can be used multiple times . This type of data is suitable for pre creation .

Be careful ：“ Dead water data ” It's relatively stable , Stability depends on the purpose of the test . For example, user data , It is basically stable when testing non user related tests , But for the test cases that specifically test user accounts , It often involves functions such as user logout , So it is unstable at this time .

“ Live water data ”： It can only be used once , Or data that is often modified . for example Coupon 、 Data such as orders .

（2） Test case design

Use case design is designed from two dimensions , Functional and non functional requirements .

Functional requirements

Use case design method reference ： Fundamentals of software testing — Process and use case design methods -piecesof

Nonfunctional requirements - Safe latitude

Whether sensitive information is encrypted ： Whether the front and back end transmission of password is encrypted
sql Inject ？（ It is dynamically constructed based on the user's input data Sql sentence , If the data entered by the user is constructed to be malicious Sql Code ,Web The application has no dynamic construction of Sql Statement using parameters for review , It will bring unexpected danger .）
Logical loopholes ：
Batch registration and repeated consumption ？（ such as , At the same time , The same parameters , High concurrent requests , Is there only one Http Registration request succeeded ）
The same cell phone number , Different mailboxes , Can I register more than 3 Users ？

Nonfunctional requirements - Performance latitude

Whether the benchmark performance is up to standard ？ For example, a single request requires less than 500ms？
High concurrency performance evaluation ： By means of performance test , Evaluate the performance of the registered interface . Specific to see ： Server performance test - Getting started and Server performance test - Tools section

Functional requirements latitude ： Using the orthogonal method , At least 29 Use cases .
Non functional requirements latitude - Safe latitude ：4 Use cases .
Non functional requirements latitude - Performance latitude ：2 Use cases .

（3） How to make interface assertions ？

Http Response Assertion ：
Http Status code
Response Body Field 、 structure check
Response Header
Data assertion ：
Assert against data in the database
Does the response time meet the requirements ？

3、 How to test a system with interfaces ？

（1） Complex system test case structure

Reference resources ： HttpRunner And step/case/suite

testing procedure (testStep) -> The test case (testCase) -> Test scenarios / Test case set (testSuite)

testing procedure (testStep)

For interface testing , Each test step should correspond to one API Request description for .

The test case (testCase)

The test case （testcase） It should be carefully designed to test a specific functional logic , And at least include the following points ：

Clear test purpose
Clear input
Clear operating environment
Clear description of test steps
Clear expected results

Test case design principles ：

Test cases should be complete and independent , Each test case should be able to run independently ;
The test case consists of test script and test data .
The test script ： The test script only focuses on the tested business function logic , Including preconditions 、 testing procedure 、 Expected results, etc .
Test data ： It is the business data corresponding to the test .
Test data and test script are separated ： Facilitate the implementation of data-driven testing . Pass in a set of data to the test script , Test and verify the same business function under different data logic . such as ： Purchase product interface , The commodity prices of members and non members are different , The logic of coupons is also different . So through different user data , It can test the shopping logic of members and non members .

Test case set (testSuite)

Test case set is an unordered set of test cases , The test cases in the collection should be independent of each other , There is no prior dependency .

If there is a sequence dependency , For example, login function and order function . The right thing to do is , Perform the login operation in the pre step of placing a test case .

（2） Test data management

source ： Test the data management strategy in the framework

Two properties of data ：

Scope ： Shared data （ Apply to testSuite Level ）、 Isolate data （ Apply to testCase Level ）
How it was created ： Call the development interface 、 Use Sql、 Develop data templates independently

Scope of test data

Shared data ： all case Or part of it case Common test data

advantage ： Fast , Data only needs to be created once and can be given to many case Use .
shortcoming ：
There are a lot of data case To prepare the , It's hard to tell which data is for this case To prepare the , What data is given to another case To prepare the .case Low readability of
case They influence each other . Because the function to be tested will affect the database itself . It's very likely that one case Your failure or success will result in a batch of case Of fail
The data itself cannot be extended , A little change , The impact is very extensive . Several or even dozens case The failure of is very common . The cost of maintaining scripts is high

Isolate data ： Every case Have exclusive test data ,case They don't affect each other , each case do setup and teardown The operation of .case Create data before execution , Destroy data after execution .

advantage ：case They don't affect each other , The data does not affect each other .case The stability of , Maintainability , Readability is greatly improved
shortcoming ： Slow speed .... Grey is always slow ... Because of every case There are many disks IO operation ... It is not surprising that the time to maintain data is longer than the time to invoke functions . OK, This method is actually the one we use most in testing . Although it is very slow , And it is difficult for many people to realize it . But the maintainability it brings is so tempting . I no longer have to maintain those unstable scripts all day . Slow down, just slow down . Anyway, we do interface testing and UI The continuous integration strategy of automated testing also runs regularly . Run 10 A few minutes , I don't care for a few minutes . As long as it's not a strategy to monitor code changes , Everything is easy to say .

sensitive data ： account number 、 password 、key Other sensitive information , Set to an environment variable with permission restrictions .

The main reason why sensitive information cannot be disclosed ：
Strengthen authority control ： There may be many developers involved in the project , Everyone has the permission to read the code warehouse , But like key This kind of extremely sensitive information should not be accessible to everyone ;
Reduce the harm of code leakage ： If the code leaks , Sensitive data information should not be disclosed at the same time .
Recommended solution ：
Perform permission control on the server , Only O & M personnel （ Or core developers ） You have the right to log in to the server ;
Operations staff （ Or core developers ）： Set sensitive data to the environment variables of the system on the running machine ;
Ordinary developers ： You only need to know the variable names of sensitive information , Get sensitive data by reading environment variables in the code .

How to construct data

Call the development interface

advantage ： It is relatively simple to implement in scripts , No need to understand the background database .
shortcoming ：
Coupling too high , Relying on other interfaces of the product to create data is doomed case It is non isolated . Note that isolation is case An important indicator of quality . Once the data interface is created bug 了 , How many did you say case Failure . And in the real world , Need to call N An interface to create the data you need . It is impossible to determine which interface bug. This has become end-to-end testing . Be able to quickly locate bug Location , Are also case An important indicator of quality .
If you isolate data , Interfaces in products are often difficult to meet your need to destroy data , Take the most common example . In this world, there is a deletion mechanism called logical deletion , That is, the product interface does not really delete the data in the database , Instead, it uses a logical marker , Indicates that this data has been deleted . No more feedback to users . In fact, you can't do this “ Isolate the data ”
Use advice ： Not recommended . Although the cost of script maintenance is low , But the coupling degree of use cases is high 、 Poor isolation , The cost of problem location is high . A called development interface BUG, May cause a large number of use cases to fail .

Use it directly sql： It is to write directly sql Create and destroy data .

advantage ： Isolation and bug Tracking is very good .
shortcoming ： If you give it to the tester to write in the script sql Words , difficulty , Readability is not very optimistic , And rely too much on the ability of the tester , High error rate . Fortunately, we can do some tricks on the test framework , Solve this problem .
Use advice ： Except query sql Outside , Additions and deletions sql Careful use , Because the implementation cost is high 、 High operational risk . You need to have a good understanding of database table structure and business logic , Deleting and modifying data is likely to affect the actual business or other students' tests .

Data templates ： Test data for core business , Create a separate data template , Specially assigned person for independent maintenance .

Reference resources ： The birth of testing energy efficiency platform - International Mall intelligent material platform

Realize the idea ：
The data structure is complex , And there are many data related businesses 、 Data with high risk of abnormal data （ For example, the material data of e-commerce ）, It is recommended to encapsulate general functions based on the development interface , And make targeted exception handling and positioning .
advantage ：
Specially assigned person to develop and maintain , Greatly reduce the cost and risk of building complex data
Reduce the effort of functional test to construct data , Break through the bottleneck of relevant testing manpower .
shortcoming ： High development cost , Use heavyweight business systems

4、 Interface test evolution

Review the previous interface tests , Find a few problems ：

Complex systems have thousands of interfaces , The workload of regression test is heavy ;
The cost of writing use cases is high , Interfaces with many parameters
You can refer to the following cases , Improve the productivity of interface testing .

（1） The workload of regression test is heavy ？ Record online traffic regression

Reference resources ： Record the correct way to open online traffic for regression testing

（2） The cost of writing use cases is high ？ General interface automatic test scheme

Reference resources ： Universal interface robustness scanning scheme

（3） Quickly verify interface data structure changes ？ Interface automation full field verification

source ： Interface automation full field verification

Realization ： Custom interface return data format (【 Contract definition 】)- Actual response data format verification (【 Contract verification 】) The function of

Verification principle ：

The actual returned field name must be strictly equal to or contain the contract defined field name ( Determine according to different matching patterns )
Field values can be equal in value or type

This article was first published on TesterHome Community , Link to the original text https://testerhome.com/topics/29928
It is an internal sharing document , It is intended to share the contents of single interface test and system interface test from basic to in-depth . This article draws on and cites the contents of many peer articles , The content source has been marked . You can view the original text of relevant contents through links .

The above is today's sharing , Did you stop learning ~

Want to learn more about dry goods and cutting-edge technology ？

I want to get acquainted with the test industry and the industry elite ？

Welcome to your attention 2022 MTSC The conference （ The 10th China Internet testing and Development Conference ）

Industry pairs MTSC The evaluation of the General Assembly ： to ground 、 Pragmatic 、 There is depth 、 Re share

China Internet test and Development Conference Testing Summit China, By TesterHome Initiated the technical conference of software testing and development industry . There's another alias ：Make Testing Super Cool！

MTSC The main purpose of the conference is to exchange software quality assurance system and testing and R & D technology , Began in 2015 year , Nine sessions have been held successfully . share 1000+ companies ,10000+ Test Engineer 、 Test Manager 、CTO Participation , It has been widely concerned by the whole industry , It's the top conference in China's Internet quality assurance industry .

In order to ensure the quality of the topic , Every year, topics will be collected half a year in advance , After several months of review , Finalize the topics to be shared at the conference .MTSC 2022 The topics are still being solicited , We sincerely invite all senior test technology experts 、 Quality management managers and test rookies recommend themselves / Recommended topics ！

How to submit the topic

Just click https://www.wjx.top/vj/wZwCju... Enter the delivery entrance , Fill in and submit according to the format , Welcome to introduce yourself / Recommended topics .

Issue deadline

In order to facilitate the review team to have more time for review and communication with lecturers , Present better topics for the majority of participants , Topic submission （ But there is no PPT, There is an outline and other topic information introduction ） The delivery deadline is advanced to ：2022 year 3 month 30 Japan

Issue solicitation and selection process

Overall process ： Case submission > Preliminary examination and approval > PPT Submit > Confirm the topic > Conference speech

Overall time node ：

Case submission >> 3 month 30 Japan

Preliminary examination and approval >> 4 month 15 Japan

ppt Submit >> 5 month 15 Japan

Topic confirmation >> 5 month 30 Japan

Conference speech >> 7 month 22~23 Japan

Share instructor benefits

Practice your speaking ability , Enhance personal brand
Access to face-to-face communication with industry experts , learn widely from others ' strong points
Enhance the company's brand , Make your team more attractive
Get free conference tickets and information ：
Every lecturer will receive 1 Tickets for the conference , Follow up to the conference PPT And videos will be given to the lecturer at the first time
Field lecturers are from MTSC The organizing committee shall bear the travel expenses