Introduction: Interface testing is an essential item in all development tests. Effective and complete interface testing can not only ensure the development quality of new functions, but also allow developers to have the ability to return when modifying functional logic. It is also a prerequisite for elegant refactoring. What principles should be followed when writing interface tests? What should the structure of the test code look like? What are the practical skills for interface testing? This article shares the author’s practical summary of interface testing.
Front-line development students may have caused online bugs or even failures to one degree or another; they may also encounter a scenario where a student refactored the code while developing a certain function, causing online bugs or failures; during development When it comes to a certain function, it is found that the public logic needs to be modified, and for fear of affecting other functions, it is very unsightly to copy the code and rewrite a separate set of logic to support it.
The above situations all contain a key issue, whether it is functional development or logical reconstruction, how to ensure the quality of code development. Everyone knows that the means of guarantee is testing. The first is new function testing to ensure that the new function logic is correct; the second is regression testing to ensure that the original business function logic is correct. There are generally two methods of testing, manual testing and automated testing. With the continuous development of testing technology and tools, the proportion of manual testing has gradually decreased and been gradually replaced by automated testing. Automated testing is sustainable and repeatable, and even AI-enabled.
1. Test layering
Testing is also layered, as shown in the figure below:
Within a system, automated testing is generally divided into unit testing, module testing and interface testing.
Unit testing
At present, my application code is basically based on the interface-oriented programming model of the spring framework, and unit testing has been weakened. The requirement of unit testing is basically to test a single method of a single class. In our current mode, the writing cost is too high. Of course, if it is a tool or a piece of relatively cohesive and complex logic (such as algorithmic logic), unit testing should still be used to ensure the correctness of the logic.
Module testing
When the system is relatively large and has many modules, a module testing layer can be established to ensure the correctness of the functions of each module. However, the current system development trend is microservice architecture, so the module test layer is not very necessary and can be covered by the interface test layer.
Interface testing
Personally, I think it should be called entrance testing to be precise. This layer is the integration test starting from the system entrance. The application entrance is usually HSF (a distributed RPC service framework) service, message, and scheduled task.
As a developer, there are tens of thousands of testing methods, and interface testing is indispensable. When the interface testing of our application is effective and fully covered, it can not only ensure the development quality of our new functions, but also allow us to have the ability to return when modifying the functional logic. This is also the prerequisite for code refactoring. At the same time, testability is also an indicator of a reasonable code structure. If it is found that it is difficult to write a test script for a piece of code or cannot be tested, it means that the current code structure is unreasonable and needs to be refactored. Next, I will mainly talk about the effectiveness of interface testing.
Now I have also found a lot of test friends and created a communication group to share technology, sharing a lot of technical documents and video tutorials we collected. If you don’t want to experience the feeling of not being able to find resources when studying on your own, having no one to answer your questions, and persisting for a few days before giving up. You can join us to communicate. And there are many technical experts who have made certain achievements in automation, performance, security, test development, etc. Share their experience, and also share many live lectures and technical salons You can learn for free! Focus on it! Open source! ! ! QQ group number: 110685036 [password: csdn999]
2. Testing principles
Basic principles:
- Automation: Interface testing is a non-interactive automated execution that does not require human participation.
- Independence: Interface tests should not depend on each other.
- Repeatable: Interface testing can be executed repeatedly and is not affected by the environment.
- Interface testing follows BCDE principles to ensure the quality of interface delivery. Border: Boundary testing. Correct: Correct input, correct expected output. Design: Write test logic according to requirements and design documents. Error: Error input, expected output.
- Data preparation: Data preparation is performed through system services and cannot be directly inserted into the db.
- Testability: Untestable code needs to be restructured into a reasonable structure.
- Coverage: Interface testing needs to cover all UC, and code coverage and branch coverage should reach a certain standard, and new code must be covered.
- Continuity: If code modification causes existing interface tests to fail, the code problem must be fixed or the code logic must be tested.
- Time requirements: Interface testing should be completed before the project is released and should not be added after the project is released.
The above basic principles should apply to automated test cases at all layers. When writing interface tests, in addition to the above principles, there are other principles that need to be followed. First, look at a picture:
Analyze the entry call from a system perspective, taking the HSF service as an example:
- Peripheral systems call services provided by our system.
- The system executes a bunch of code logic, including branch logic.
- During the execution of the system, it relied on the external HSF service, made a call, and obtained the return value.
- During system execution, it relies on DB query or landing data, and relies on cache query or landing data.
- A message was sent externally during system execution.
- Return HSF execution results to the upstream system.
The key principles for effective interface testing are to cover all entries, mock all dependencies, and verify traces left during execution. This is summarized as follows:
- Entry coverage: The interface test case must cover the HSF service entrance, message entrance, and scheduled task entrance.
- Dependence on mocks: Among the basic principles, there is the principle of repeatability, that is, interface testing cannot be dependent on the environment and needs to be mocked to remove external dependencies. But for db dependencies, it is not recommended to completely mock them. On the one hand, mocking is costly, and on the other hand, it may not cover sql and table constraint logic.
- Complete verification: A valid interface test should have complete verification. Interface testing without verification is meaningless. As long as the traces left during the execution process have an impact on the business, they must be completely verified to ensure the effectiveness of the interface test. HSF interface return value verification: HSF return parameter verification is performed according to the scenario and interface convention. DB verification: Verify the correctness of landing data. Cache verification: Verify the correctness of the data stored in the cache. HSF dependent input parameter verification: Use the mock tool to obtain the input parameters that depend on the HSF call and perform input parameter verification. Message verification: Obtain the sent message object through the mock tool and verify the message body.
3. Test code structure
When writing test code, you should also consider the readability, scalability, and reusability of the code just like writing business code. At the same time, according to the business characteristics of the system, test components suitable for the current system can be encapsulated on the basis of the test framework, so as to improve the efficiency of test code writing and standardize the test code structure.
The test code for an interface has an approximate structure as follows:
1. Test preparation
Dependent on data preparation
Many times, our tests have data dependencies, which may be configuration data or business data (for example, refunds depend on payment data).
- Configuration data: Configuration can be initialized by defining configuration files.
- Business data: This type of data is prohibited from being generated by directly inserting data, but should be generated by calling business services.
Depend on mock
For external dependencies, the dependent services need to be mocked to avoid real calls.
Interface test parameter preparation
Prepare input parameters for the interface.
2. Test execution
Call interface methods and execute business logic.
3. Test verification
- Return parameter verification: Verify the return parameters of the interface.
- DB: Verify DB landing data.
- Cache data verification: Verify the data landed in the cache.
- Message verification: Verify the message object sent externally.
- Verification of external HSF calls: Verify the input parameters of external HSF calls.
4. Practical skills
1. Execution efficiency
For interface testing, execution efficiency is a point that must be paid attention to. If an interface test takes more than 3 minutes to see the results, it will greatly reduce the enthusiasm of development students to write interface tests. To improve test execution efficiency, the recommended solution is:
- Minimize the startup test context, such as spring boot application, just start spring.
- Use an in-memory database such as h2
- Mock middleware dependencies
2. Test framework selection
For the testing framework, it is recommended to choose a testing framework based on testng that can provide data preparation through configuration files. If you can’t find a suitable one, you can package it yourself based on testng.
3. Interface test coverage
The completeness of the scenario affects the coverage of test cases. On the one hand, developers need to enumerate normal and abnormal situations based on the input of business scenarios and testing experience. On the other hand, interface methods also have some fixed points that need to be tested, such as idempotent testing. , boundary value testing, incorrect parameter testing, etc.
At the same time, you should also use the coverage tool to check the code or branch logic that is not covered by the interface and conduct targeted scenario coverage testing. According to my experience, complete branch coverage is very important, especially abnormal branches.
5. Summary
To ensure the stable operation of the system online, quality assurance measures are essential. Although there are many automated assurance methods now, interface testing is still one of the most basic and important assurance methods. If the coverage and effectiveness of interface testing can be continuously ensured, the occurrence of online bugs will be reduced to a large extent, and development students will be more motivated to refactor the code.
Finally, I would like to thank everyone who has read my article carefully. Looking at the increase in fans and attention, there is always some courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly!
Software testing interview document
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Python entry skill treeHomepageOverview 388735 people are learning the system