Written in the front_Be sure to 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. However, compared with functional testing, the interface testing gap is very large.
And interface testing has a very high status in the testing field, and it is the dividing line between junior and intermediate software testing engineers . Therefore, as long as testers understand interface testing, they can find jobs with very good salaries.
Therefore, test workers (that is, QA in the eyes of the questioner) must do their best to improve their interface testing capabilities.
If you want to improve the code coverage of interface testing. First of all, we must know the reasons for the low code coverage, so that we can take better measures to improve the code coverage. After carefully analyzing the application scenarios supplemented by the subject, I will explain the subject's question in 4 parts.
1. Why is the code coverage rate low for conventional interface testing?
2. How to improve code coverage?
3. In order to facilitate the understanding of interface test case methods, examples are given.
4. Analyze the difficulties that may be encountered in ensuring the interface test coverage.
1. Why is the code coverage rate low in conventional interface testing?
Interface QA is still a black box. QAs do not pay attention to the internal logic of the interface. Just design different parameter combinations according to your own understanding as use cases.
In fact, the subject has revealed the root cause of low code coverage. For interface testing, this kind of black-box test case design thinking is quite common.
Let's take a simple interface scenario as an example to see the test case design of black-box testers:
Take the http protocol as an example
Single interface:
Validate URL
* There are some special paths on the URL path that need to be validated
Validate query parameters, request header, request body parameters
* For parameters: regular parameter verification (normal and abnormal data)
* For business: single interface function coverage (forward and reverse requirements)
Validate response data
* Normal interface response coverage
* Abnormal interface response coverage (error information)
Verify the business scenario:
* Cover the business scenario of the application
* Simulate the user's possible operation process through the interface
This kind of black-box design deals with interface testing, and often misses the following four categories:
Omission classification 1. Scene omissions caused by unclear or irregular tests
If the design ideas of interface test cases are not clear or standardized, it is easy to miss the scene. That is to say, there are omissions in the scenarios that should be covered by black-box test case design thinking, which will definitely reduce the coverage rate of the code.
Missing classification 2, involving branches that are not easy to cover
The implementation logic of the interface is diverse 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. However, the asynchronous processes such as asynchronous task failure, retry, and timing being pulled up may be missed. Thus reducing code coverage.
2. The interface involves transactions
When an interface involves a transaction, the conventional interface test case design generally only triggers the normal transaction process. 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, it is easy to miss some test scenarios. Take read-write locks as an example (read-read coexistence, read-write non-coexistence, write-write non-coexistence). Conventional interface test case design is likely to miss some read-read coexistence, read-write non-coexistence, and write-write non-coexistence scenarios. Even if these scenarios are covered, it is difficult to cover the scenarios of waiting after the lock expires and failing 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, conventional interface test case design can easily ignore the impact of caching, and there is no targeted verification related to interface caching. This also reduces code coverage.
Omission Classification 3. Ignoring Abnormal Scenes
Theoretically speaking, every interface may have abnormal scenarios
When there are some abnormal scenarios in the interface, an error of the framework is thrown, which is generally not allowed. In other words, programmers generally have to deal with exception scenarios that may occur on the interface. There are some harsh scenarios that are not easy 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: The downstream interface returns a 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 forever.
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 saved in the cache service. If the cache service is abnormal or restarted, many interfaces will be affected. These scenarios also need to be covered.
Omission 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 all be handled using configuration items.
for example:
Feature Enable Switch Configuration
If the switch is turned off, the business code of this function must not be covered. It needs to be turned on and tested by the relevant salesman, so that this type of code can be covered.
Timing 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 the data status of a certain mode is not fully covered, the scene will be missed. Reduce code coverage.
Second, how to improve code coverage?
Overall idea: In view of the reasons analyzed in the first part, take some measures to try our best to let our testers who don't understand the code be able to better test the interface and cover these scenarios. Ultimately improve code coverage.
Solution 1. Omission of black-box test scenarios
This kind of scene omission is relatively easy to solve. Specific measures: Standardize the use case design method and process, and basic testers are competent.
Solution 2. Cover the special branch points in the interface, exception scenarios and project configuration related scenarios
If you want to cover these scenarios from the 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.
1. Development not only provides interface documents, but also provides interface implementation documents, and the implementation process of the interface must be clearly described in the documents. For example, the configuration items, asynchronous tasks, transactions, locks, caches, etc. involved in the interface must be clearly stated. It is best to be able to output a flowchart or sequence diagram. This point is very critical, which can greatly help testers without a code foundation to understand the interface business and implementation details.
2. 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 study alone, testers can find more corresponding developers to understand business implementation.
3. If the requirements change or the business implementation changes, communicate and update relevant documents in a timely manner.
4. Testers design test cases based on the mastery of business implementation, covering the implementation business scenarios of the interface.
3. In order to facilitate the understanding of the method of improving code coverage, give an example
Example 1. Asynchronous task_taking batch deletion as an example
In order to give users a good experience in the project, it is very common for some deletion interfaces to have asynchronous deletion tasks.
For example: batch deletion of orders (an e-commerce company), batch deletion of files (a certain disk), etc. Many of these data batch deletion services are implemented through asynchronous tasks.
Let's roughly write the hypothetical logic of deleting data
analyze:
Conventional 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 easy to trigger when calling the interface.
If the developer provides this flowchart, testers can design test cases based on the flowchart to cover all branches.
Scenario example:
Asynchronous task write failed
Data writing can be prevented by writing fixed data of fixed users in advance (handling such as primary key conflicts)
Modify the number of database connections and delete interfaces in batches
Asynchronous task execution failed
Wrong data can be preset in advance, resulting in execution failure (some fields are missing, some field values are wrong data)
Example 2. Transaction
In the project, there are some interface implementations that involve some transactions, which is also very common.
analyze:
In the process of interface test case design, consider that in the entire business process, try to cover exceptions in each step as much as possible, and design different test scenarios to cover the entire business process.
Scenario example:
An exception occurred in the transaction, and the rollback was successful.
Example 3. Locks
In projects, multi-terminal operations are also relatively common, such as web-side, App-side, small programs, etc. Then there will be some scenarios where the interface operates on the same part of the data.
Analysis:
When designing interface test cases, lock-related scenarios should be considered to improve code coverage.
Scenario example:
acquire a 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
release lock
read lock
Successfully released the lock
Failed to release lock
write lock
Successfully released the lock
Failed to release lock
Example 4. Scheduled tasks
If the project needs to process data in batches, it will generally choose to implement it through scheduled tasks during off-peak periods.
For example: data version migration, cleaning up expired data, etc.
analyze:
When testing the server interface, these scheduled tasks should also be verified. Can effectively improve code coverage.
Here we mainly emphasize the data status of task execution. To ensure the comprehensiveness of data, the data representatives of the entire life cycle must exist, and must have a certain magnitude, so that the processing logic of the task can be covered.
Scenario example:
Whether the timed task is activated
Whether the scheduled task is executed
Before the task is executed, is the data comprehensive (covering all types of the entire life cycle)
4. Analysis of the difficulties that may be encountered in ensuring the interface test coverage
Difficulty 1. The interface implementation documents provided by the development are not standardized
Development and implementation documents must have certain templates and writing specifications, and developers are strictly required to output documents. There must be control measures.
Difficulty 2. Difficulty for testers to understand
Documentation should focus on process description and less code.
This can be cultivated, and the difficulty is not particularly great. Unless this tester doesn't want to progress.
Difficulty 3. The designed use cases cannot be tested
There are some abnormal scenarios, and it is really difficult to implement the test, you can ask for help.
Now I feel more and more that as a tester, when designing a use case, there is no need to consider whether the test can be realized. Unable to test, mostly because of lack of skills. Therefore, the use case is designed normally, and the execution of the use case can be assisted by a big boss.
5. Final summary
specific implementation requirements
Developers transform interface implementation logic from code thinking into document description. This is the premise for the no-code foundation to understand the business of the project. Documents must be standardized, reviews must be clear, and changes must be synchronized in a timely manner.
Testers need to strengthen their studies, read documents, learn from reviews, consult development, and understand business implementation.
Testers have a deep understanding of the business, then design more comprehensive test scenarios and implement tests.
significance
The code coverage rate is improved, and the project is naturally tested more fully. Can find more hidden problems.
It can allow testers who have no coding ability to grow quickly and do a good job of testing.
It standardizes the development and implementation process, and it also plays a certain role in promoting the development and management of the project.
shortcoming
It will be difficult to implement at the beginning, especially for cross-departmental operations.
There will be more communication costs for testing and development.
[The following is the most complete software test engineer learning knowledge architecture system diagram in 2023 that I compiled]
1. From entry to mastery of Python programming
2. Interface automation project actual combat
3. Actual Combat of Web Automation Project
4. Actual Combat of App Automation Project
5. Resume of first-tier manufacturers
6. Test and develop DevOps system
7. Commonly used automated testing tools
Eight, JMeter performance test
9. Summary (little surprise at the end)
life is long so add oil. Every effort will not be let down, as long as you persevere, there will be rewards in the end. Cherish your time and pursue your dreams. Don't forget the original intention, forge ahead. Your future is in your hands!
Life is short, time is precious, we cannot predict what will happen in the future, but we can grasp the present moment. Cherish every day and work hard to make yourself stronger and better. Firm belief, persistent pursuit, success will eventually belong to you!
Only by constantly challenging yourself can you constantly surpass yourself. Persist in pursuing your dreams and move forward bravely, and you will find that the process of struggle is so beautiful and worthwhile. Believe in yourself, you can do it!
