Interface Test 01-Introduction and Use Case Design

interface

1. Concept

A channel for data transfer and interaction between systems and components.

2. Type

Divided by protocol : http, tcp, IP.
Divided by language : C++, java, php. . .
Divided by scope :
  1) Between systems:
  between multiple internal systems;
  between internal systems and external systems;
  2) Between programs:
  between methods, between functions, between modules

Interface testing

1. Concept

Interface testing is to test the interfaces between systems or components. Verify the correctness of the passed data and the correctness of the logical dependencies!

2. Principle

Interface testing is mainly aimed at the test target -
how to test Server 2.1?
Simulate the client and send requests to the server.
2.2 What to use for testing?
Tools : fiddler, postman, Jmeter
Code : python + UnitTest framework + Requests framework
2.3 What to test?
Test whether the response data sent back by the server in response to the client request is consistent with the expected result!
Human eye comparison
assertion

3. Features

In line with the concept of moving quality control forward;
it can discover some problems that cannot be found by page operations;
interface testing
is low-cost and highly effective; interface testing tests the system from the user's perspective;

4. Implementation method

Tools : JMeter, Postman, fiddler
Code : Python + Requests + UnitTest

What is automated interface testing?
With the help of tools and codes, simulate the client to send a request to the server, and use assertions to automatically determine whether the expected results are consistent with the actual results!

Introduction to HTTP protocol

1. HTTP

HTTP : (HyperText Transfer Protocol) Hypertext Transfer Protocol is an application layer protocol based on the request and response model. It is also the most widely used network protocol on the Internet.
Features :
Support client/server mode,
simple, fast
, flexible
, connectionless
, stateless

2. URL format

Concept : (Uniform Resource Locator) Function of Uniform Resource Locator
: In a network environment, uniquely defines a data resource

3. HTTP request

Function : The client (app, browser) uses the protocol when sending a request to the server - http request protocol.
Specifies the syntax format for data transmission to the server.

3.1 Request format

Request line : The first line of the http request. Request method (space) URL (space) Protocol version
request header : Syntax format: k: v
User-Agent : Describe the browser type of the request sender
Content-Type : Describe the data type of the request body
Empty line : Represents the http request header to end
the request Body : The data carried when the request is sent. The value of the data type Content-Type!

post and put have request bodies,
get and delete have no request bodies.

3.2 Request line

http request method: both upper and lower case
GET: query. —— No request body
POST: added. (Commonly used when logging in)
put: modify.
delete: delete. ——No request body

3.3 Request header

Data format: k: v
Content-Type:
application/json: JSON data format
application/x-www-form-urlencoded: form form data

3.4 Request body

GET and DELETE do not
have PUT and POST.
The data type is affected by the Content-Type value.

4. HTTP response

The server side sends back response data to the http request sent by the client. —— http response!
Specifies the organization format of data sent back to the client.


Response line (status line ): Protocol version (space) Status code (space) Status description
response header : Syntax format: k:v
Content-Type : Describe the data type in the response body.
Blank line : represents the end of the response header.
Response body : most are not empty. (If the request is successful: data is sent back, if the request fails: error information is sent back)
The data type is affected by the Content-Type value.

4.1 Status line

Status code:
1xx : represents instruction information. Indicates that the request has been received and is waiting to be processed.
2xx : Indicates that the request was successfully processed and received. Common: 200, 201
3xx : redirection, the resource to be accessed needs to be re-specified for access.
4xx : Represents client error. Common: 404, 403
5xx : server-side error.
Status code description: Generally uniquely corresponds to the status code. 200 —— ok; 404 —— file not found

4.2 Response header

Syntax format: k: v
Content-Type: The value is the data type of the response body.
Content-Length: The size of the response body. You don’t need to write it, the browser will get it automatically. Once written, it must be accurate!

4.3 Response body

The content of the message sent back to the client. Common ones include html web pages, xml, and json

Interface style

1. Traditional style interface

Features:
Request method, only use get and post.
The URL is not unique. The same operation can correspond to different URL
status codes and the use is relatively simple. 200 most common.

2. RESTful style interface

Features:
Each URL represents a resource;
a certain presentation layer of this resource is transferred between the client and the server;
presentation layer: different presentation forms of data (such as pictures and text representing the same data object). The
client passes Four HTTP verbs (GET, post, delete, put) operate on server-side resources to achieve "presentation layer state transformation"; the
most commonly used format for data passed between interfaces is JSON.

Interface testing process

1. Analyze requirements and generate requirements documents (products).
   (Develop and generate interface documents) Parse interface documents.
2. Generate interface test cases (submit for review).
3. Execute test cases
4. Tools: postman, jmeter, fidller
5. Code: python + Requests +UnitTest
6. Submit and track defects.
7. Generate test reports.
8. (Optional) Interface automation continuous integration

Interface documentation

A document written by developers that describes interface information. The development team conducts development work according to the interface document and must maintain and comply with it at all times.
Function:
It enables front-end development and back-end developers to better cooperate and improve work efficiency. (There is a unified reference file)
When the project iterates or project personnel change, it is convenient for later personnel to view and maintain. It is
convenient for testers to conduct interface testing. Take
"login" as an example:
Request method: POST
URL: http://ihrm-test.itheima .net/api/sys/login
request header: Content-Type: application/json
request body: {"mobile":"13800000002", "password":"123456"}
response status code: 200
error code:
  10000: operation successful !
  20001: Incorrect username or password
  99999: Sorry, the system is busy, please try again later!

Interface use case design

Reasons for designing interface use cases:
to prevent missing test points and make it clear and
easy to allocate work and evaluate workload and time.

1. Test points for interface testing

Test points are called test dimensions

1.1 Functional testing

1.1.1 Single interface function

A single business module in manual testing generally corresponds to an interface.

• Login business——>Login interface
• Add to shopping cart business——>Add to shopping cart interface
• Order business——>Order interface
• Payment business——>Payment interface
• With tools and code. Bypass the front-end interface, organize the data required for the interface, and carry out interface testing.

1.1.2 Business scenario function

Sort out the interface business scenarios according to the actual usage scenarios of users.

• When organizing business scenarios, you generally only need to do forward testing (the same as manual testing).
• It is generally recommended to use the fewest use cases to cover the most business scenarios.
• Login——Search for products——Add to shopping cart——Place order——Pay——Evaluate

1.2 Performance test

Response time,
throughput
, number of concurrencies,
server resource utilization

1.3 Security testing

Attack security - completed by professional security testing engineers
Business security - test direction
Whether sensitive data is encrypted
SQL injection: Write SQL statements where users can enter data
SQL injection security, SQL statements maliciously written by users will not Execute query database

2. Design methods and ideas

2.1 Similarities with manual design

The functional test points corresponding to manual testing are completely consistent with the functions corresponding to interface testing.

Example: tpshop mall login page, manual function test case design points:
1) Whether the page layout meets the requirements;
2) Test the username input box to see if the entered data is correct;
3) Test the password input box to see if the entered data is correct;
4 ) Test the verification code input box to see if the entered data is correct;

tpshop mall login page, interface test case design points:
1) Test whether the value of username corresponding to the username input box is correct;
2) Test whether the value of password corresponding to the password input box is correct;
3) Test whether the value corresponding to the verification code input box The value of verify_code is correct;

2.1 Differences from manual design

Manual test to see if the data written into the input box is correct.
The interface test tests whether the parameter values ​​corresponding to the parameters are correct.
Interface testing is not only conducted on parameter values, but also on the parameters themselves.

• Forward parameters:
  required parameters: all required (required) are included.
  Combination parameters: all required + any one or more optional parameters.
  All parameters: all required + all optional parameters.
• Reverse parameters:
  Multiple parameters: One or more required parameters are added (can be specified arbitrarily)
  Few parameters: One or more required parameters are missing
  No parameters: There are no required parameters
  Error parameters: The parameter name is entered incorrectly

3. Single interface test case

8 major elements of manual test case document:
number, use case name (title), module, priority, preset conditions, test data, operation steps, expected results

Interface test case document 10 elements:
number, use case name (title), module, priority, preset conditions, request method, URL, request header, request body (request data), expected results

3.1 Analyze interface documents

Take the login interface as an example:

Request method: post
URL: Protocol and domain name in "System Information" + /api/sys/login
Request header: Content-Type: application/json
Request body: {"mobile": "13800000002", "password": "123456 "}
Expected results: {"success":true,"code":10000,"message":"The operation was successful!","data":"f5050a1b-7919-444c-9ec4-3c1a7286536d"} data: The value is login
successful Generated token data. This data changes periodically.

serial number	Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
login_001	Landed successfully	Log in	p1	Account has been registered	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800000002”,“password”:“123456”}	Status code: 200 {"success":true,"code":10000,"message":"Operation successful!","data":"f5050a1b-7919-444c-9ec4-3c1a7286536d"}

3.2 Interface test case test points of login module

3.2.1 Numerical values

• Forward
  Login successful
• Reverse
  The user name is empty.
  The user name contains special characters and letters. The
  user name exceeds 11 digits (12 digits). The user name
  is less than 11 digits (10 digits).
  The user name is not registered. The
  password is empty
  . The password contains special characters and letters. The
  password is 1 digit.
  The password is 100
  digit password wrong

3.2.2 Parameters

• Forward
  Required parameters: correct username + correct password
  Combined parameters: Ignore
  All parameters: correct username + correct password
• Reverse
  Multiple parameters: multiple abc: "123"
  Few parameters (less mobile): no user name, correct password
  No parameters: no parameters Wrong parameters
  (mobile phone number parameter name is wrong): abc:1381234567, password: "123456"

Username related:

serial number	Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
login_002	Username is empty	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“”,“password”:“123456”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_003	Username contains special characters and letters	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800&#abc”,“password”:“123456”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_004	Username exceeds 11 digits (12 digits)	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“138000000023”,“password”:“123456”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_005	Username is less than 11 digits (10 digits)	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“1380000000”,“password”:“123456”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_006	Username is not registered	Log in	p2	Mobile phone number that does not exist in the database	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“16700542479”,“password”:“123456”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}

Password related:

serial number	Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
login_007	Password is empty	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800000002”,“password”:“”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_008	The password contains special characters and letters	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800000002”,“password”:“123&%rt”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_009	Password 1 digit	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800000002”,“password”:“1”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_010	Password 100 digits	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{"mobile":"13800000002","password":"Place a 100-character password"}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}
login_011	Wrong password	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800000002”,“password”:“888888”}	Status code: 200 {"success":false,"code":20001,"message":"Incorrect username or password","data":null}

Parameter related:

serial number	Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
login_012	Required parameters (all parameters)	Log in	p2	/	POST	{protocol+domain name}/api/sys/login	Content-Type:application/json	{“mobile”:“13800000002”,“password”:“123456”}	状态码：200 {“success”:true,“code”:10000,“message”:“操作成功！”,“data”:"f5050a1b-7919-444c-9ec4- 3c1a7286536d "}
login_013	多参	登录	p2	/	POST	{协议+域名}/api/sys/login	Content-Type:application/json	{“abc”:“123”,“mobile”:“13800000002”,“password”:“123456”}	状态码：200 {“success”:true,“code”:10000,“message”:“操作成功！”,“data”:"f5050a1b-7919-444c-9ec4- 3c1a7286536d "}
login_014	少参（少mobile）	登录	p2	/	POST	{协议+域名}/api/sys/login	Content-Type:application/json	{“password”:“123456”}	状态码：200 {“success”:false,“code”:20001,“message”:“用户名或密码错误”,“data”:null}
login_015	无参	登录	p2	/	POST	{协议+域名}/api/sys/login	Content-Type:application/json	/	{“success”:false,“code”:99999,“message”:“抱歉，系统繁忙，请稍后重试！”,“data”:null}
login_016	错误参数（mobile参数名错误）	登录	p2	/	POST	{协议+域名}/api/sys/login	Content-Type:application/json	{“abc”:“13800000002”,“password”:“123456”}	状态码：200 {“success”:false,“code”:20001,“message”:“用户名或密码错误”,“data”:null}

3.2.3 业务场景测试用例

用户怎么用，怎样设计业务。
用最少的测试用例，尽量覆盖最多的接口

• 分析测试点
  针对 员工管理 业务场景：
  登录 —— 添加员工 —— 查询员工 —— 修改员工 —— 再次查询 —— 删除员工 —— 查询员工列表
• 添加员工
  请求方法：post
  URL： {协议+域名}/api/sys/user
  请求头：
  Content-Type： application/json
  Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
  请求体（请求数据）：{“username”:“爱因斯坦”,“mobile”:“17289432100”,“timeOfEntry”:“2021-07-12”,“formOfEmployment”:1,“departmentName”:“测试0607”,“departmentId”:“1412421425733664768”,“workNumber”:“234”,“correctionTime”:“2021-07-30T16:00:00.000Z”}
  预期结果：
  状态码：200
  {“success”:true,“code”:10000,“message”:“操作成功！”, “data”:{“id”:“113749504”}}

用例名称	模块	优先级	预置条件	请求方法	URL	请求头	请求体(请求数据）	预期结果
添加员工	员工管理	p0	登录成功	POST	{协议+域名}/api/sys/user	Content-Type： application/json， Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d	{“username”:“爱因斯坦”,“mobile”:“17289432100”,“timeOfEntry”:“2021-07-12”,“formOfEmployment”:1,“departmentName”:“测试0607”,“departmentId”:“1412421425733664768”,“workNumber”:“234”,“correctionTime”:“2021-07-30T16:00:00.000Z”}	状态码：200 {“success”:true,“code”:10000,“message”:“操作成功！”, “data”:{“id”:“113749504”}}

• 查询员工
  请求方法：GET
  URL： {协议+域名}/api/sys/user/:target
  请求头：
  Content-Type： application/json
  Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
  请求体:
  无
  返回数据：
  状态码：200
  "code": 10000, "message": "操作成功！", "data": { 所查询的员工的详细信息} }

用例名称	模块	优先级	预置条件	请求方法	URL	请求头	请求体(请求数据）	预期结果
查询员工	员工管理	p1	登录成功	GET	{协议+域名}/api/sys/user/:target	Content-Type： application/json， Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d	/	Status code: 200 {"success": true, "code": 10000, "message": "The operation was successful!", "data": {Details of the employee being queried} }

• Modifying the employee
  returns the id in the data, which represents the modified employee id (which is data that will change).

Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
Modify employee	Employee management	p0	login successful	PUT	{protocol+domain name}/api/sys/user/:target	Content-Type： application/json， Authorization： Bearer xxx	{"username":"Peppa Pig"}	Status code: 200 {"success":true,"code":10000,"message":"The operation was successful!", "data":{"id":"xxx"}}

• Delete employee

Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
Delete employee	Employee management	p0	login successful	delete	{protocol+domain name} /api/sys/user/:target	Content-Type： application/json， Authorization： Bearer xxx	/	Status code: 200 {"success":true,"code":10000,"message":"The operation was successful!","data":null}

• Query employee list

Use case name	module	priority	Preconditions	Request method	URL	Request header	Request body (request data)	expected outcome
Query employee list	Employee management	p0	login successful	GET	{Protocol+Domain Name} /api/sys/user?page=1&size=10	Content-Type： application/json， Authorization： Bearer xxx	/	Status code: 200 { “success”: true, “code”: 10000, “message”: “The operation was successful!”, “data”: { “total”: xxxx, “rows” [ {},{},… 10 employee details] } }