Students who are fortunate enough to read this article, please read this article carefully (remember to read it several times), because this article can improve your interface testing skills.
Written in the front _ must first talk about the status of the interface in the testing field:
In the current application of practical testing skills in enterprises, functional testing and interface testing are the most widely used . But compared to functional testing, the interface testing gap is very large.
And interface testing has a very high status in the testing field, and is the dividing line between primary and intermediate software test engineers . Therefore, as long as testers understand interface testing, they can find a job with a good salary.
Therefore, test workers (that is, QA in the eyes of the questioner) must do their best to improve their interface testing strength.
Back to the point
If you want to improve the code coverage of interface testing. First of all, you must know the reasons for the low code coverage, and then you can take better measures to improve the code coverage. I will explain in 4 parts. [Share study notes at the end of the article]
1. Why is the code coverage low for conventional interface testing?
2. How to improve code coverage?
3. In order to facilitate the understanding of the interface test case method, an example is given.
4. Analysis of difficulties that may be encountered in ensuring interface test coverage.
1. Why is the code coverage rate low in conventional interface testing?
Interface QA is still a black box. QAs are not concerned with the internal logic of the interface. Just design different parameter combinations as use cases according to your own understanding.
In fact, the subject has already exposed the root cause of low code coverage. For interface testing, this kind of black- box test case design thinking is relatively common.
Let's take a simple interface scenario as an example to see the test case design of black-box testers:
以http协议为例
单接口：
验证 URL
* 针对URL 路径上存在一些特殊的path需要验证
验证 查询参数，请求头、请求体参数
* 针对参数：正则类的参数校验（正常和异常数据）
* 针对业务：单接口功能覆盖（正向需求和反向需求）
验证 响应数据
* 正常接口响应覆盖
* 异常接口响应覆盖（错误信息）
验证 业务场景：
* 覆盖应用的业务场景
* 通过接口，模拟用户可能的操作流程This black-box design for interface testing often misses the following four categories:
Omission classification 1. Scene omission caused by unclear or non-standard testing
If the interface test case design ideas are unclear or non-standard, it is easy to miss scenarios. That is, as mentioned above, there are omissions in the scenarios that the black-box test case design thinking should cover, which will definitely reduce the code coverage.
Missing classification 2, involving branches that are not easy to cover
The implementation logic of the interface is varied and involves many branches. Some common points are listed below. I hope you will add more.
1. The interface involves asynchronous tasks
When the interface involves asynchronous tasks. Conventional interface test case design ideas generally only trigger the normal execution of asynchronous tasks. And asynchronous tasks fail, retries, and periodically pull up these asynchronous processes, which may be missed. So it reduces code coverage.
2. The interface involves transactions
When an interface involves transactions, conventional interface test case design generally only triggers the normal transaction process. However, the actual developers have done some special business implementations for the specific step of rollback and the processing required after the rollback. These scenarios are easy to miss and also affect code coverage.
3. The interface involves locks
When an interface involves locks, there are also some test scenarios that are easy to miss. Take read-write locks as an example (read-read coexistence, read-write non-coexistence, and write-write non-coexistence). Conventional interface test case design is likely to miss some scenarios of read-read coexistence, read-write non-coexistence, and write-write non-coexistence. Even if these scenarios are covered, it is difficult to cover the scenario of waiting after the lock has expired and failed to acquire the lock. Obviously this reduces code coverage.
4. The interface involves caching
It is common to use caching technology in interfaces, especially query interfaces. Such as batch query. If the interface involves caching, it is easy to ignore the impact of caching in the design of conventional interface test cases, and does not specifically verify the interface caching. This also reduces code coverage.
Omission classification 3. Ignore abnormal scenes
In theory, each interface may have abnormal scenarios
When there are some abnormal scenarios in the interface, the error of the framework is thrown, which is generally not allowed. In other words, programmers generally have to deal with abnormal scenarios that may appear in the interface. Some scenarios are harsh and difficult to appear, and testers are easy to ignore. Once there is no coverage, it will definitely reduce the coverage of the code. for example:
Scenario 1: Downstream interface returns timeout
When an upstream service calls an interface provided by this service, this service needs to access other services when processing this interface business, and the return of other services may time out, and this service generally does not wait all the time.
Scenario 2: Database connection timeout
When a certain interface needs to operate data, the performance of the database server is certain, and there must be some database exception scenarios. For these scenarios, development generally does some code processing.
Scenario 3: Cache server exception
Some login status of the user, if stored in the cache service. If the cache service is abnormal or restarted, many interfaces will be affected. These scenarios also need to be covered.
Missing classification 4. Other related - project configuration
The business logic of many projects can be controlled through configuration, which is also very common. Whether some functions are enabled, the starting mode, and the control of specific business content can be handled using configuration items.
for example:
- Function enable switch configuration
If the switch is turned off, the business code of this function cannot be covered. It is necessary to enable and test the relevant salesperson to cover this type of code. - Scheduled task configuration
Set the scheduled task execution policy according to the configuration. Some scheduled tasks process data in different states. If a certain task mode is not tested, or if the data state coverage in a certain mode is incomplete, the side scene will be missed. Reduce code coverage.
Second, how to improve code coverage?
Overall idea: For the reasons analyzed in the first part, take some measures to allow testers who do not understand the code to better test the interface and cover these scenarios. Ultimately improve code coverage.
Solution 1. Omission of black box test scenarios
This kind of omission is a better solution. Specific measures: Standardize the use case design method and process, and basic testers can be competent.
Solution 2. Cover special branch points, abnormal scenarios and project configuration related scenarios in the interface
If you want to cover these scenarios from interface design use cases, you must know and understand these business logics. In order to achieve this goal, it can be guaranteed from the following 4 steps.
- In addition to providing interface documents, development also provides interface implementation documents , in which the implementation process of the interface should be clearly described. For example, the configuration items, asynchronous tasks, transactions, locks, caches, etc. involved in the interface must be clearly explained. It is best to be able to output a flowchart or timing diagram. This is critical, it can greatly help no-code-based testers understand the interface business and implementation details.
- In addition to participating in the requirements review, the testers master the project requirements. It is also necessary to participate in the development requirements design review meeting to deepen the specific business understanding of the interface. Since it is difficult for testers to read and learn alone, testers can find more corresponding developers to understand business implementation.
- If requirements change, or business implementation changes, timely communicate and update relevant documents.
- Testers design test cases based on their grasp of business implementation to cover the implementation business scenarios of the interface .
3. In order to facilitate the understanding of the method of improving code coverage, an example is given.
Example 1. Asynchronous task_take batch deletion as an example
In order to give users a good experience in the project, it is very common for some interfaces to delete classes to have asynchronous deletion tasks .
For example: batch deletion of orders (an e-commerce company), batch deletion of files (a disk), etc. Many of these data batch deletion businesses are implemented through asynchronous tasks.
Let's roughly write the assumed logic of deleting data
batch deletion
analyze:
Regular interface test case coverage, it is easy to ignore other branches of these asynchronous tasks. The reason is also very simple, QA does not know these logics. These scenarios are also not easily triggered when the interface is called.
If the developer provides this flow chart, the tester can completely design the test case according to the flow chart, covering all branches.
Scenario example:
- Asynchronous task write failed
- Data writing can be prevented by writing fixed data of fixed users in advance (processing such as primary key conflict)
- Modify the number of database connections and execute the delete interface in batches
- Asynchronous task execution failed
- Error data can be preset in advance, causing execution to fail (some fields are missing, some field values are wrong data)
Example 2. Transaction
In the project, there are some interface implementations involving some transactions, which is also very common.
affairs
analyze:
In the design process of interface test cases, consider covering the exceptions at each step as much as possible in the entire business process, and design different test scenarios to cover the entire business process.
Scenario example:
- An exception occurred within the transaction, and the rollback was successful.
Example 3. Lock
In the project, multi-terminal operations are also relatively common, such as the web side, the App side, and the applet. Then there will be some scenarios where the interface operates on the same part of the data .
Lock
analyze:
When designing interface test cases, consider lock-related scenarios to improve code coverage.
Scenario example:
- acquire lock
- no lock
- acquire write lock
- acquire read lock
- write lock exists
- acquire read lock
- acquire write lock
- read lock exists
- acquire read lock
- acquire write lock
- no lock
- release lock
- read lock
- Release the lock successfully
- Failed to release lock
- write lock
- Release the lock successfully
- Failed to release lock
- read lock
Example 4. Scheduled tasks
If there is a project that needs to process data in batches, it will generally be implemented through timed tasks during low-peak periods.
For example: data version migration, cleaning up expired data, etc.
timed task
analyze:
When testing the server interface, these timing tasks should also be verified. Can effectively improve code coverage.
The main emphasis here is on the data status of task execution. To ensure the comprehensiveness of the data, the data representation of the entire life cycle must exist and must be of a certain magnitude, so that the processing logic of the task can be covered.
Scenario example:
- Whether the scheduled task is started
- Whether the scheduled task is executed
- Before the task is executed, is the data comprehensive (covering all types of data throughout the life cycle)
4. Analysis of difficulties that may be encountered in ensuring interface test coverage
Difficulty 1. The interface implementation document provided by the development is not standardized
Development and implementation documents must have certain templates and writing specifications, and developers are strictly required to output documents. Have control measures.
Difficulty 2. Testers have difficulty understanding
- Documents should focus on process description and less code.
- This can be cultivated, and the difficulty is not particularly big. Unless this tester doesn't want to progress.
Difficulty 3. The designed use case cannot be tested
- There are some abnormal scenarios, it is really difficult to implement the test, you can ask for help.
- I now feel more and more that as a tester, when designing a use case, there is no need to consider whether the test can be implemented. I can't test, mostly because of my lack of skills. Therefore, the use case is normally designed, and the execution of the use case can be assisted by a boss.
V. Final Summary
specific implementation requirements
-
- Developers transform the interface implementation logic from code ideas into document descriptions. This is the premise for the no-code foundation to understand the business of the project. Documents should be standardized, reviews should be clear, and changes should be synchronized in a timely manner.
- Testers need to strengthen their learning, through document reading, review learning, consulting development, and understanding business implementation.
- Testers gain a deep understanding of the business, then design more comprehensive test scenarios and implement the tests.
significance
-
- The code coverage is improved, and the project is naturally tested more fully. More hidden problems can be found.
- It can allow testers without coding ability to grow rapidly and test well.
- It standardizes the development and implementation process, and also promotes the development and management of the project.
shortcoming
-
- It will be difficult to implement at the beginning, especially in cross-departmental operations.
- There are more communication costs for testing and development.
Finally, I would like to thank everyone who has read my article carefully. Watching the rise and attention of fans all the way, there is always a need for ritual exchanges. Although it is not a very valuable thing, if you can use it, you can take it directly.
These materials should be the most comprehensive and complete preparation warehouse for friends who do [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you! Everything should be done as early as possible, especially in the technology industry, and the technical foundation must be improved. I hope to be helpful…….
