It is the responsibility of every test engineer to write good test cases, but in actual work, the test cases written by everyone often need to be modified continuously before they can be used. Various conflicts arise in the team.
So how to efficiently design test cases? How should the writing of test cases be handled within the team? The following is a suggestion on the practice of individuals and teams, hoping to help everyone.
Personally write test cases
When I write test cases, I use a lot of design methods and write a lot of execution steps, but when I implement the test, I find that the written steps cannot be connected to a large extent and need to be modified before execution. It is caused by insufficient understanding of the software interface operation, and the software interface operation has rules to follow.
The following common interfaces are used to explain the design ideas and specific methods of test cases.
1.1 Interface function analysis
First of all, the red and bold information items in the figure are required items, and they are often placed in the front when designing the interface. Non-mandatory items are placed after required items
The software does not verify the legitimacy and correctness of the data immediately when entering a certain data, but performs data verification when clicking the "Save" button and submitting the data
Data item verification sequence: from left to right, from top to bottom. Non-required items will not be verified if there is no data
Verification prompt principle 1: Verify item by item according to the verification order, and immediately pop up a prompt when encountering an error, terminate the verification process, and fail to submit the data
Verification Prompt Principle 2: First, verify the integrity of the overall data, and then pay attention to verifying that it is legal and valid. That is, first check whether all required items have data, and then check whether the data is correct!
1.2 Description of information prompt rules
When a problem is found, the task can no longer be completed, and it doesn't matter whether the following data items still have problems. The software cannot control the user's operation behavior, and will not prompt all data item errors at one time, because if the user has not completed the modification, has not modified it, or accidentally corrected the correct data, etc., it will cause this one-time error. The prompt is meaningless. The most important thing is that this information is displayed in the prompt box and disappears after the user clicks the "OK" button. Can he remember it completely?
1.3 Test data design
For each item of data, multiple technologies are used to design several illegal and invalid data and valid data. The valid data of all required items are combined into a group of complete data. The number of data groups is calculated according to the largest valid data item. For data items with insufficient valid data, the existing valid data can be copied to make up for the shortage.
1.4 General steps of test case design
1) All required and non-required fields are empty, then click [Save], the system prompts: [Name] cannot be empty
2) Fill in an illegal data for [Name] and click [Save], the system prompts: [Age] cannot be empty
3) Fill in an illegal data for [Age] and click [Save], the system prompts: [Gender] cannot be empty
4) Fill in illegal data for [Gender] and click [Save], the system prompts: [Education] cannot be empty
5) Fill in an illegal data for [Education] and click [Save], the system prompts: [Height] cannot be empty
6) Fill in an illegal data for [Height] and click [Save], the system prompts: [Weight] cannot be empty
7) Fill in an illegal data for [Weight] and click [Save], the system prompts: [Name] data error. Note: So far, all required items have been tested
8) Fill in other illegal data for [Name] one by one and click [Save], the system prompts: [Name] data error. Note: Fill in an illegal and click [Save]
9) Fill in a legal data for [Name] and click [Save], the system prompts: [Age] data error. Note: At this time, all illegal tests on [Name] have been tested, and a legal one has been tested
10) Repeat steps 8 and 9, and do the same operation for the remaining required items, first fill in all the illegal ones of the current data item, and finally follow the one legal. So far, the illegal data of all required items have been tested, and a set of legal data has been tested
11) Fill in the remaining untested data of the required items by group, and then click [Save] to complete the remaining required items. So far, the legal and illegal tests of the required items have been completed
12) Non-mandatory items are tested separately, and a set of legal data of the previous required items can be taken out to cooperate
Team writes test cases
The biggest problem with team work is that everyone’s test data is designed according to their own ideas and requirements. When everyone’s test cases are put together, they cannot form a set, and the system cannot be tested completely, and the amount of changes is large. . In particular, it has a huge impact on query, statistics, and report functions, and it is almost impossible to test!
The principles for the team to write test cases are:
For use cases with lagging functions, data requirements need to be put forward for use cases with pre-functions when writing
The use cases of pre-functions should consider the data requirements of subsequent tests on the basis of meeting their own test needs, and it is best to be able to integrate them (what is left is the data that meets the subsequent functional requirements)
For example:
Zhang San wrote [Material Storage], there are two pieces of data retained in the system after the addition, deletion and modification functions are executed.
When Li Si wrote the follow-up [Material Outbound], he first used Zhang San to keep two pieces of data in the system. If the data was not enough, Li Si had to ask Zhang San to add data to meet his own testing work.
By analogy, a set of test cases for the entire team can be written. Such test cases have very high availability, and they basically do not use their brains when executing them, and only look at the expected results.
It is recommended to hold a dedicated test case design meeting at the beginning to communicate the problem of test data
This is what I did when I was a test manager. The test engineers were very resistant at the beginning, thinking that it would be cumbersome and the progress was slow, but when they entered the test execution stage, they were very happy because the test cases were executed smoothly and there was no problem. Those who changed the use cases in the past are alive.
efficient
It is to do one thing and use it as several things. Specifically, one test data can measure multiple aspects, which is efficient!
The efficiency of the test is the efficiency of the test data, so how to do it?
3.1 About illegal data
Illegal data must be measured and carefully designed, but cannot enter the system
3.2 Regarding legitimate data
From a functional point of view, test cases can be divided into legal and illegal. Generally, the design of legal data only needs to be legal, but it often does not satisfy the business. At this time, it is time-consuming and laborious to redesign the data for business testing. It is necessary to merge legal data and business data to improve the efficiency of use cases, that is, efficient!
When merging, use business data in place of legal data. For test engineers, it is likely that they don’t understand the business. It doesn’t matter that the user understands it, and the user has a lot of business data at hand, and can find the user to obtain these business data.
Pay attention to the confidentiality of user business data! In the second half of 21, the country officially implemented the "Data Security Law of the People's Republic of China", which has legal requirements for the acquisition, dissemination and use of data.
review
There are a lot of practices about evaluation, I won’t repeat them here. When the previous points have been achieved and done well, in fact, what to evaluate and how to evaluate during the evaluation will be ready to come out.
Whether the design of individual use cases is reasonable and consistent with the operation of the software is a key point.
Whether the data before and after the overall use case echoes and can form a set is another key point.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. web, app, interface automation, 7. performance testing, 8. programming basics, 9. hr interview questions, 10. open test questions, 11. security testing, 12. computer basics
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can help you too!