Written in the front: Test cases are the most basic, but very important, and they are the basic skills that support us to further learn other testing skills on the test road . After enrolling in the online software testing training class, the students who enroll in the class don't know how to write test cases, and they have to go to Zhihu for help, which is really heartbreaking. It can be seen that the water for training institutions is very deep, and you must keep your eyes open when choosing a training institution , and you don't know how to choose.
Test case is an important document to guide testers in test execution, and it is a very core job of testers . As a testing and training institution, let me answer. In order to thoroughly answer the doubts of the subject, I will first announce the structure of the article:
1. Clarify motivation and understand the importance of "test cases"
2. Clear style, explaining the eight elements of the "test case" format
3. Clear mines in advance and inform the precautions for writing "test cases"
4. Case consolidation, teaching how to write "test cases"
5. Broaden your horizons and share learning resources about test cases
1. Clarify motivation and understand the importance of "test cases"
What is a use case?
A use case is an example of how a user uses the software.
So what is a test case?
The test case is to make a scientific organization and induction of the case of the user using the software, and form a document to guide the test execution.
Therefore, the test case can also be simply described as: a test execution document designed for a specific test purpose.
How important test cases are, as long as we look at the "software testing process" from a macro perspective, we can know.
complete testing process
In the complete testing process, there are two links related to use cases . Therefore, the writing of test cases is very important and can be called the core work. Because it is important, testers spend a lot of time writing test cases in their daily work. As shown in the figure below:
Why are test cases so important? There are 3 reasons:
Reason 1. Test cases can prevent missing tests
The test case is to write and sort out the test work in advance. If test cases are not documented in advance, testers will easily miss test scenarios.
Reason 2. Test cases are the standard for implementing tests
The test case writes clearly what to test and how to test it. The testers will execute it according to the test case writing.
Reason 3. Test cases are an important basis for testing work evaluation
Whether the test is comprehensive can also be reflected intuitively through test cases. It is also an assessment of the workload of the tester
2. Clear style, explain the eight elements of the "test case" format
Test cases are so important, how to write test cases?
First show the complete test case format for everyone to see. As can be seen from the use case format, a test case contains eight elements.
1. In order to concentrate, first master the 4 core elements
Let's first look at the 4 elements marked in red font, these 4 elements are the core elements (the following introduction text is recommended to read word by word):
1) Use case title: The user writes the test purpose and test points, which is the most important. The format is suggested to be "test purpose - test point (summary, if there is no summary text, you can leave it blank)". For example, "Successful login-correct account number and password" in the picture
2) Test steps: In order to achieve the purpose of the test, which steps you need to go through, use numbers to describe the operation steps, so that it does not appear confusing.
3) Test data: the data involved in the operation steps. If the operation step does not require data, such as clicking various buttons, it can be empty.
4) Expected result: the desired result. The result is not my own subjective imagination, but from the visible product requirements document (provided by the product manager, PRD for short).
The above four elements need to be mastered by testers.
2. After talking about the core elements, come to understand the non-core elements
The other 4 are non-core elements, let’s take a look:
1) Use case number: If the use case is written by software, there is no need to pay attention to this item. But if you write by yourself through an excel document, you need to write in the format "Project_Module_Number". This format is not easy to repeat the number.
2) Preconditions: Preconditions to execute this use case.
For example, in the screenshot above, the prerequisite for testing login is to enter the login page first, and the qq account has been registered.
3) Module/Project: The project or module it belongs to. Take the screenshot as an example, we are now testing the login module, so just fill in the login here.
In actual work, we don't need to think about it, because the product requirements document (provided by the product manager, PRD for short) will be clearly planned, and only need to be filled in according to the requirements.
4) Priority: Indicates the importance or influence of the use case. This element is more important. The principle is that the more important the function to the user, the higher the priority.
3. Demining in advance and informing the precautions of error-prone elements
After the introduction of the 8 major elements of the test case is completed, in order to make the subsequent project practice more smooth, let's first introduce the 6 major error-prone elements, write precautions, and first clear mines in advance.
1. Precautions for writing "Use Case Title"
Use case title, is used for table name testing purposes.
Qualified use case titles can be judged by two aspects:
1) Be clear: other members of the team can clearly understand what scenario you want to test through the title of the use case, without having to look at the subsequent test steps.
2) Don’t be too cumbersome: don’t write a long list for clarity, in fact, you only need to clearly mark the core points.
2. Precautions for writing "test steps"
To write qualified test steps, you need to grasp:
-
Be sure to refer to the prototyping page and prototyping drawings provided with the product.
-
Don't skip some steps: the steps and links in the prototype diagram should also be clearly written step by step in the test steps.
-
Don't mix multiple steps together: each step represents an action, so it will be clear when reading.
3. Precautions for writing "test data"
How to judge that the writing of "test data" is reasonable?
-
The identification before the content (for example, the screenshot refers to "QQ number" and "password") must be written clearly. In this way, when other people in the team execute the use case, they can also understand the meaning of the data and execute it clearly.
-
The core data associated with the test steps must be constructed separately, so as not to confuse the rest of the team.
-
Hard-coded data does not need to be filled in with test data, it only needs to be specified in the "preconditions". For example, if the verification code is 8888, then I don't need to explain it in the test data.
4. Precautions for writing "expected results"
Qualified "expected results", need to pay attention to the following two points:
-
Write down the expected results clearly. Don't just write about successes and failures. Otherwise, the executor has to check the product requirements document after the test case, otherwise it is impossible to judge what is success and what is failure.
-
How the requirements document defines success and failure can be written as it is, and cannot be omitted.
5. Precautions for writing "preconditions"
Qualified "preconditions", you can pay attention to the following two points:
1) The premise of the precondition is what your test steps are. So write the test steps first, then the preconditions.
2) The conditions that most of the preconditions need to meet are the default conditions, which can be omitted. For example, the network is normal (unless the weak network test needs to be done, and the network is not normal).
6. Precautions for writing "Priority"
Priority, don't just write P0 (the highest level), that's unreasonable. It can be determined according to the project requirements.
It is written according to the priority level of popularization, and it is generally named P0~P3. For everyone’s better understanding, I will add the case of "mall app" to illustrate:
P0: The highest priority, verifying business processes, accounting for 10-15%.
Business process, representing the highest commercial value of users using your software.
For example, in the mall app, user login->search for products->add shopping cart->order->pay->view order, the function of this core business line, It belongs to the P0 level.
P1: High priority, verifying core functions, accounting for 20-30%.
For example, in the mall app, using the account balance to pay for an order, or registering an account, all belong to the P1 level.
P2: Medium priority, verifying general functions, accounting for 50%-60%.
For example, in the mall app, if the user modifies the personal avatar to png format, it belongs to the P2 level.
P3: Low priority, verify special preset conditions and data settings, accounting for 10-15%.
For example, 10,000 random operations on the mall app in 3 minutes belong to the P3 level.
What to fill in, please refer to the division of the project.
Combined with the introduction of the 8 major elements of "test case" + the precautions of 6 major error-prone elements, in summary, the key to a qualified test case is to grasp this principle:
"Not only can you execute it yourself, but also the rest of the team can execute it."
4. Case consolidation, teaching how to write "test cases"
After the elaboration of the above two parts, is it easy to write test cases now? Next, let's verify the case.
TP Mall - Product Requirements Document (provided by product manager, referred to as PRD)
As shown in the Product Requirements Document PRD above, we need to design two test cases for "successful registration" and "existence of mobile phone number". How should we write them?
Combining the introduction of the 8 major elements of "test case" + the precautions of the 6 major error-prone elements, let's try:
Step1: First write the module + use case number
It needs to be written according to the format "Project_Module_Number". This format is not easy to repeat the number.
The project is "TP Mall", the module is "Registration", and the serial number is 001,002
So use case numbers and modules can be done together, as shown in the screenshot:
Step2: Use case title
The user writes the test purpose and test point, which is the most important. The format is "test purpose - test point (summary)"
1) Be clear: other members of the team can clearly understand what scenario you want to test through the title of the use case, without having to look at the subsequent test steps. 2) Don’t be too cumbersome: don’t write a long list for clarity, in fact, you only need to clearly mark the core points.
Test scenario 1) Purpose: registration is successful, the scenario is: the mobile phone number does not exist, that is, the mobile phone number is not registered,
Test scenario 2) Purpose: registration failed, the scenario is: the mobile phone number already exists, that is, the mobile phone number has been registered
The purpose and the test point are separated by "-", and at the same time, it must meet the requirements of clarity and not cumbersome, so the title of the use case is written as follows:
Step3: Priority
Priority : generally P0~P3 for naming
P0: the highest priority, verifying the business process, accounting for 10-15%.
Business process , representing the highest commercial value of users using your software.
For example, in the mall app, user login->search for products->add shopping cart->order->pay->view order, the function of this core business line, It belongs to the P0 level.
P1: High priority, verifying core functions, accounting for 20-30%. For example, in the mall app, using the account balance to pay for an order, or registering an account, all belong to the P1 level.
P2: Medium priority, verifying general functions, accounting for 50%-60%. For example, in the mall app, if the user modifies the personal avatar to png format, it belongs to the P2 level.
P3: Low priority, verify special preset conditions and data settings, accounting for 10-15%. For example, 10,000 random operations on the mall app in 3 minutes belong to the P3 level.
The mobile phone registration function does not belong to the function of the business process, but it belongs to the core function (the registration is not successful, and the business function cannot be realized), so it is more appropriate to set P1.
Prompting that the mobile phone registration failed is not a function of the business process. Relatively speaking, it is a general function, so it is more appropriate to set P2.
If you are not sure, it can be determined according to the project requirements.
Step4: Test Steps -> Preconditions -> Test Data
"Preconditions" 2 points to note:
1) The premise of the precondition is what your test steps are. So write the test steps first, then the preconditions.
2) The conditions that most of the preconditions need to meet are the default conditions, which can be omitted. such as network
"Test steps" 3 points to note:
-
Be sure to refer to the prototyping page and prototyping drawings provided with the product.
-
Don't skip some steps: the steps and links in the prototype diagram should also be clearly written step by step in the test steps.
-
Don't mix multiple steps together: each step represents an action, so it will be clear when reading.
"Test data" 3 points of attention:
-
The identification before the content (for example, the screenshot refers to "QQ number" and "password") must be written clearly. In this way, when other people in the team execute the use case, they can also understand the meaning of the data and execute it clearly.
-
The core data associated with the test steps must be constructed separately, so as not to confuse the rest of the team.
-
Hard-coded data does not need to be filled in with test data, it only needs to be specified in the "preconditions". For example, if the verification code is 8888, then I don't need to explain it in the test data.
Therefore, write the test steps first, be sure to refer to the prototype page and prototype diagram provided by the product, and write clearly step by step:
Prototype
Combining the prototype diagram to write test steps:
Combining test steps to write preconditions:
Write test steps combined with preconditions:
With the same three steps, we also get the filling of the three elements when the registration fails:
Step5: Expected results
-
Write down the expected results clearly. Don't just write about successes and failures.
-
How the requirements document defines success and failure can be written as it is, and cannot be omitted.
Success and failure of requirements document definition
Follow me, after writing the test cases of two test points by hand, do you still feel difficult?
Hope to hear you say: not difficult.
Special Note:
Because this article focuses on how to write test cases, a relatively simple login function is selected as a case.
But in the real situation, when we get the software and write the test cases, there are about 4 links: 1) Analyze the software requirements 2) Sort out the software rules 3) Disassemble the software test points 4) Convert into test cases.
Finally: In order to give back to the die-hard fans, I have compiled a complete software testing video learning tutorial for you. If you need it, you can get it for free【保证100%免费】
Software Testing Interview Documentation
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 Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
