Preface
This article is a little bit of personal advice I summarized in the company. There may be a lot of omissions, so I will record my understanding at this time. The company is in the bicycle sharing business, so the scenes can basically be reused. After all, everyone has ridden a bicycle. Note: code is the flag returned by our interface.
Before writing
, interface related (this summary is incomplete)
Understand the functions of the interface and its usage scenarios (normal/abnormal) and what the interface does specifically.
What functions does the interface implement?
Whether the interface operates the corresponding fields of the database
Whether the interface has operated the redis corresponding key
Interface input parameters
Including the impact of missing/redundant required and optional items, and whether there is a limit on the length of input fields, such as ID card name, etc.
Interface parameters
Including verification of code, msg and other fields in normal/abnormal scenarios. If there is return data, how to verify the returned data?
Whether the interface design meets functional expectations
If data is not allowed to be repeated, will two pieces of data be inserted if the interface is called twice consecutively?
Scene preparation
Master the prerequisites required for each scenario
If the lock interface is in normal use, its prerequisite is that the vehicle's lock has been opened.
Consider how to design the scene
You can choose to add test data to the database/redis or call the interface to add data (there will be dependencies between interfaces. Once the interface for adding data is wrong, this scenario cannot be verified)
Use case data preparation
Prepare test data as dynamically as possible
For example, the vehicle number can be retrieved from the database. If there is more complex data such as ID number + name, it can be written in variables. But you need to select a few more sets of data and read them randomly
data dependency
Priority is given to adding new data to ensure that the previous data is intact. If the new data has fields such as name, it can be added with a specific identifier + timestamp. Clean up the use cases after they are executed. If junk data appears, it is also convenient to use scheduled tasks to clean it up.
Try not to write the data to death
affirmation
Make assertions on more important fields, such as fields that need to be displayed to users.
http status code verification
code/msg verification
db verification (business related, can be ignored if there is no similar situation)
There may be situations where the interface name returned is inconsistent with the database, so the interface should be the main one. db currently uses underscore format, and interface parameters often use camel case format. When writing SQL query statements, use select ride_type as rideType.
Abnormal scenario db verification
In order to prevent: the interface parameter return code is not 0, but the db is modified.
redis verification
If redis is involved, assertions need to be made on the redis field.
The recently popular asynchronous interface
I don't have much contact with how to make assertions on asynchronous interfaces. Since the http protocol is stateless, the asynchronous interface generally puts the task into the message queue after being called, and the interface returns successfully. My understanding is to check whether there are messages in the message queue. If there are messages that have been consumed, a use case with a ending similar to tearDown can be created specifically for the asynchronous interface. After they are consumed, the relevant verification will be performed on the database/redis.
Start coding
Coding
gat is an automated testing framework based on golang that is packaged within the company. In fact, it only encapsulates http requests and does part of the unit testing framework work.
Use case description
Before writing a use case, you should have the following points in mind. How to design scenarios, which scenarios to cover, and how to make assertions. You can write your own ideas at the top of the file, so that you will be able to do it with ease during the coding process and not get confused. You won’t be confused by business logic during subsequent maintenance.
setUp and tearDown
At present, the gat framework uses TestFuncName as the entry point. After the function starts executing, we can call the setUp() function to process all the data we want to process. Next is the logic code, and tearDown is used to clean it up at the end.
The use case name corresponds to the Action, and the file name should be consistent with the structure name.
General structure
Write more comments, and common methods can be encapsulated
/*
测试功能点: 检查用户行程
覆盖到的场景:
1. 用户正在骑行中
2. 用户未骑行
数据准备:
这里填写, 你将怎样制作数据
数据清理:
这里填写, 你将如何清理脏数据
用例执行流程:
这里写你的执行思路, 首先检测什么测试点, 然后....
断言:
写出断言的标准, 理由, 如何做(这也是评审的一部分)
*/
package UserCenter
import (
"fmt"
"testing"
)
type struct UserRideCheck {
Data []map[string]interface{} // 测试数据
Action string //调用接口名
}
func (u *UserRideCheck) setUp() {
fmt.Println("用例正准备执行!")
}
func (u *UserRideCheck) tearDown() {
fmt.Println("用例执行完毕, 正在清理!")
}
func (u *UserRideCheck) TestUserRideCheck() {
setUp() // 初始化
//主逻辑, 可再封装函数
defer tearDown() // 清理(后续可添加Recovery防止用例失败阻塞)
}
func init() {
// 自己框架添加用例的逻辑
data := initStruct()
testcase.Cases["UserCenter"] = append(testcase.Cases["UserCenter"], data)
}
func initStruct() *UserRideCheck{
return &UserRideCheck {
Action: "user.ride.check"
}
}
// unittest
func UnitTestUserRideCheck(t *testing.T) {
u := initStruct()
u.TestUserRideCheck()
}Additional:
-
If possible, do a code walkthrough of the development and cover its if else branches as much as possible
-
Our own code will also make mistakes. We need to use logs to record problems in the interface during the test process as well as our own problems.
-
If possible, combine with CI
The following are supporting learning materials. For those who are doing [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!
