Although test cases are the most basic skills for testers, they are very important. Test cases are the basic skills that support us to further learn other testing skills on the test road.
How to write a test case should include two parts in a complete way:
Content 1: Test case writing (according to the eight elements);
Content 2: Test case (test point) analysis (try to make the test case more comprehensive and less missing test scenarios).
So this article talks about skipping test case writing, and the key goal is to explain "how to conduct test case analysis".
In order to let students understand the overall situation of this article, the structure of the article is first introduced as follows:
1. After getting the software, how to analyze test cases;
2. Douyin case_how to analyze test cases through business scenarios;
3. Douyin case_how to analyze test cases in depth for single function modules;
4. Summary + test case series learning Information sharing
OK, let's start.
1. After getting the software, how to analyze the test cases?
Tell the answer directly, that is, you should analyze the test cases from "global -> local".
Getting a piece of software is like walking to the entrance of a maze. In order to get out of the maze and complete the maze game, if we don't analyze the whole maze first, but directly enter the part of the maze to get a deeper understanding, it will be difficult to find an optimal game path. So to play a maze game, you need to go from global to local.
Corresponding to a project, such as the TP mall in the picture below (the web mall is essentially a piece of software), there are many menus and many function items with passwords. How to start testing to ensure the quality of the software? Then it is the same as the maze above, you must first fully understand the software from the overall situation, and then go deep into the local area. That is to say, from global to local.
TP mall background
For software, the global refers to business processes, and the local refers to functional modules.
Business process, which represents the highest commercial value for users to use your software (more on this below)
How to understand the overall situation of the software (business process), we need to use an important core reference document at this time, that is the Product Requirement Document (PRD) written by the product manager.
The role of the PRD document is:
1) A tool for planning, defining, describing, and displaying software requirements
2) It is a guiding principle in the design/development/testing process
Production and Research Team Cooperation Form
2. How to analyze test cases through business scenarios
As mentioned in the previous section, test case analysis must have the idea of "from global to local".
Then how to start from the overall situation, we have to start from the "business scenario".
1. What is a business scenario
Business scenarios, representing the highest commercial value for users to use your software
If it is difficult to understand, let us illustrate with an example.
Taking Taobao Mall as an example, the realization of its commercial value is to attract users to buy goods on Taobao. To achieve this goal, Taobao needs to provide the following series of functions.
The series of functions shown in the above screenshots are the business scenarios of Taobao stores.
So we can also understand the business scenario as follows:
1) Business scenarios, which represent the highest commercial value for users to use your software.
2) A business scenario is a combination of multiple functions.
To summarize the business scenario, it is a series of activities generated by users to realize the highest commercial value of a certain software.
So when we get a software product, we must first analyze the business scenario, test the business scenario, and give priority to ensuring that the global functions of the software can be used by users.
Go through and achieve software goals. So business scenario testing is the basis of comprehensive testing.
So how should test cases be written through business scenarios? There are two methods: flowchart method and swim lane diagram method.
Let's talk about it below.
2. Write test cases for business scenarios_flowchart method
First introduce the 4 steps of this method, as follows:
1. Obtain (or draw) the flow chart according to the product requirements document
2. Analyze the flow chart path
3. Write test scenarios-test points
4. Test case design
After the steps are finished, let's run another case, taking the video released by the Douyin project that everyone is familiar with as an example, to give you an example.
Business scenario: Users post videos using Douyin
1) Obtain (or draw by yourself) Douyin project release video according to the product requirements document
PRD document, the text description of this business scenario is as follows:
①Entrance: Click the + sign on the home page to enter video shooting
②Video type: Daily video can only be seen for one day/work video can be permanently seen
Take a screenshot of the PRD document flow chart as follows
2) Flow chart path analysis
①From the beginning to the end is a path,
②Skill sharing: number of paths = number of judgment points (diamond) + 1
Therefore, the total number of video paths released by the Douyin project = the number of judgments + 1 = 4
3) Compose "Test Scenario - Test Point" for 4 paths
① Scenario 1: Posting videos without logging in
② Scenario 2: Posting daily videos
③ Scenario 3: Posting draft videos
④ Scenario 4: Publishing videos of works
4) Test case design
Because it is a button click operation, the test data is empty
3. Write test cases for business scenarios_swim lane diagram method
In the above case of "user publishes video through Douyin", in the business scenario, the role is only one person, so the flow chart can be used.
But when multiple roles are involved in the business scenario, the flow chart cannot be expressed, and a swim lane diagram is needed.
However, the analysis method of the swim lane diagram test path is the same as that of the flow chart, and it is also the following 4 steps:
1) Obtain (or draw) the flow chart according to the product requirements document
2) Analyze the flow chart path
3) Write the test scenario-test point
4) Test case design
Next, let's run a case, for example, the refund of Douyin Mall.
Business Scenario: Users use Douyin Mall to refund
1) Obtain (or draw) the flow chart according to the product requirements document
In the PRD document, the text description of the business scenario is as follows:
① Ordinary users initiate a refund application
② The merchant conducts an audit, and if the audit passes, the refund will be issued. If the audit fails, the refund will be rejected. If the refund is successful, the user account will receive the refund item, and after-sales
The details show that it has been refunded
③After the merchant refuses to refund, the user confirms the after-sales result, the refund process is over, and the after-sales details show that it has ended.
④ After the merchant refuses to refund, the user can appeal to the platform, and the platform can decide to refund the full amount/partial refund/reject refund according to the actual situation after review, and the platform's result is the final review result.
The screenshot of the PRD document flowchart is as follows:
Douyin mall refund swimming lane map
2) Flow chart path analysis
①From the beginning to the end is a path,
②Skill sharing: number of paths = number of judgment points (diamond) + 1
Therefore, the total number of paths for the Douyin Mall refund business = the number of judgments + 1 = 5
3) Write "TikTok Mall Refund Business", 5 paths of "Test Scenario-Test Points"
① Scenario 1: Merchant review fails
② Scenario 2: Merchant review passes
③ Scenario 3: Platform review fails
④ Scenario 4: Full refund after platform review
⑤ Scenario 5: Partial refund after platform review
I won’t go into details here, just put the test case table directly:
Because it is a button click operation, the test data is empty
Summary: Design test cases from a global to local perspective. The overall situation is expressed from the perspective of business scenarios. Analyze from the flow chart (swim lane diagram), and finally convert it into a test case and execute the test.
After the introduction of the overall main business, how to design test cases for specific functional modules? Let's talk about it below.
3. How to in-depth analysis of test cases for single-function modules
Carry out detailed testing for local functions, generally also called module testing.
The module function test also has a test idea, which is divided into three steps. Let me introduce it first:
1. Get the module introduction according to the product requirements document (also known as the PRD document)
① Function description
② Page prototype
③ Requirement description
2. According to the PRD document, sort out the functional requirements
and design ideas:
① Business rules: This rule has the greatest value for users and is the priority Highest level
② Element rules: consider element length/type/operation
③ Default value of page layout: element typesetting + default value display
④ Data logic: data source, data processing and output (this point requires database knowledge, skip it first)
3. Writing
Design ideas for test points Test points
① Business rules: forward (conforms to requirements) + reverse (does not meet requirements)
② Element rules: forward + reverse
③ Default page layout
4. Improve test points
① As many use cases as possible Cover the forward test point
② Each reverse test point uses a use case to cover
5. The test point is converted into a test case
It doesn't matter if you don't understand the above ideas, let's take a case, and the students will have a perception.
Let's illustrate with the first module in the business scenario, the login module .
Step 1: According to the product requirements document (also known as PRD document), get the introduction of "Douyin Login Module"
① Function description ② Page prototype ③ Requirement description
1) Function description
User login method: mobile phone number and verification code / mobile phone number and password / third-party login
2) Page Prototype
3) Requirement description
Step 2: Sort out the functional requirements according to the PRD document (use xmind to sort out)
① Business rule: This rule has the greatest value to users and has the highest priority
② Element rule: Consider element length/type/operation
③ Default value of page layout: Element typesetting + default value display
1) Sort out business rules: this rule has the greatest value to users and the highest priority
Business rules: When the mobile phone number is not registered, automatically register and log in
2) Element rules: consider element length/type/operation
The element rule is to find all the elements in the product and sort out the length, type, time, and operation requirements of these elements
According to the page prototype and requirement description in the PRD document, the summary is as follows:
3) Page layout default value: element layout + default value display
Step 3: Write Test Points
① Business rules: Forward (meets requirements) + Reverse (does not meet requirements)
② Element rules: Forward + Reverse
③ Default page layout
1) Business rule writing test points (forward and reverse)
2) Element rule: forward + reverse
"Return to the clickable state after more than 60 seconds" can be classified as forward or reverse. The core lies in the situation of "more than 60 seconds", which should be considered as a test point and not missed. Here we first return to reverse.
Protocol selection radio button and login button operation, can not write the forward and reverse, you can not write.
3) Page layout defaults
Because the "page layout default value", there is no forward and reverse, so there is no need to write. jump over.
Step 4: Improve the test points
① A use case covers as many forward test points as possible
② Each reverse test point is covered by a use case
1) A use case covers as many forward test points as possible
A use case covers as many positive test points as possible, which means that all the positive test points sorted out are written into a use case to test whether the test can run successfully
case01: The mobile phone number has been registered and the login is successful
2) Each reverse test point is covered by a use case
case02: The mobile phone number is not registered, automatically register and log in
case03: The mobile phone number is not 11 digits
case04: The mobile phone number is not a number
case05: The verification code is not 4 digits
case06: The verification code is not a number
case07: The verification code is valid for more than 3 minutes
case08: Verification "Get Whether the verification code button returns to the clickable state after more than 60s"
3) Added "Action Button" + "Page Layout Defaults"
case09: verify the "protocol radio button click to switch the selected state"
case10: verify "mobile phone number/verification code/protocol radio button, any one is missing, grayed out and cannot be clicked"
case11: verify the default value of the page layout
Note: We will find a problem with the above test points, that is, the writing of the test points is not rigorous enough. For example, if the mobile phone number is not 11 digits, it means that the mobile phone number is not 11 digits. Do we have to test it? That's troublesome, because looking at it this way, the test data "cannot be exhaustive". At this time, it is necessary to use the equivalence class division method to test the points at night.
4) Use the "equivalence class division method" to improve the test points
Equivalence class division method: divide the test data into "several subsets" according to certain common characteristics, and these subsets are called "equivalent classes".
Application scenario: test data cannot be exhaustive
To improve the test point, you need to use the "equivalent class table", as shown in the following figure:
equivalence class table
ps: The "effective equivalence class" in the field of the above table refers to the data set that meets the requirements. "invalid equivalence class", which refers to "a collection of data that does not satisfy the requirement"
There are 3 steps to use the equivalence list:
step1. Find out the input conditions from the requirements. "
step2. Divide equivalence classes (equivalence class table) for input conditions, in the case,
step3. Design test cases
Combined with the element rules in the login case, we can get the following completed form:
Therefore, the simple test point above is optimized as follows: case01: The mobile phone number has been registered and the login is successful
case02: 手机号未注册，自动注册并登录case03: 手机号非11位case03-1: 手机号大于11位case03-2: 手机号小于11位case03-3: 手机号为空case03-4: 11位数字非手机号case04: 手机号非数字case05: 验证码非4位case05-1: 验证码大于4位数字case05-2: 验证码小于4位数字case05-3: 验证码为空case05-4: 错误的4位验证码case06: 验证码非数字case07: 验证码有效期大于3分钟case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”case09: 验证“协议单选按钮点击切换选中状态”case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”case11: 验证页面布局默认值
PS: I believe that some students will still have doubts after seeing this, that is the test data filled in the equivalence table. For example, "a number greater than 11", why is there 14 digits in the table instead of 15 digits, 13 digits, or 12 digits...?
This involves another question: How can the equivalence class take a more representative value?
Then it is necessary to introduce another knowledge point: the boundary value method.
5) Use the "boundary value method" to make the value of the equivalence class more representative
Boundary value method: When selecting test data, when there is an interval, select the data on both sides of the critical point.
How to use: Select values that are exactly equal to, just greater than, or just smaller than the boundary as test data.
Reason: Values on borders are more error-prone.
Therefore, for the data in the chart, according to the idea of boundary value, let’s optimize the lower value, as shown in the screenshot below:
The test points are more detailed and the values are more representative. Are there any other problems with the test points?
have.
Example case10: Verify the "mobile phone number/verification code/protocol radio button, if any condition is missing, it will be grayed out and cannot be clicked". Here, only one condition is considered to be grayed out.
Is it also necessary to consider the test points where two conditions are missing at the same time and three conditions are missing at the same time? Therefore, the current test point only focuses on the test point of a single input condition, and does not consider the combination relationship between multiple input conditions.
Solution: need to introduce "decision table analysis method".
6) Use the "decision table analysis method" to further optimize the test points
Judgment table: It is an analysis tool that expresses the different results obtained under the "combination of multiple conditions" in tabular form.
decision table analysis
Drawing the decision table mainly goes through the following three steps:
1) List the actions
2) Fill in the condition items and combine the conditions
3) Determine the action according to the combination of condition items
. There are n conditions, and each condition item has 2 values. The maximum condition item combination is: 2 to the nth power
4) Simplified merge similarity rules
Let's work with the login case.
① There are two action items: the login button can be clicked, and the login button is grayed out.
② There are 3 condition items: the mobile phone number is empty, the verification code is empty, and the protocol radio button is empty.
③ The determined maximum combination of conditional items is: 2 to the 3rd power = 8, and 8 columns should be reserved for the table
Get the form as follows:
④ Simplified merge similarity rules
When the action outputs two or more columns that are exactly the same, if the action output has nothing to do with the condition, they can be combined, as shown in the following figure:
Then the above judgment table can be optimized as follows, from 8 test points to 5 test points
Then the final test point is written as follows:
case01: 手机号已注册，登录成功case02: 手机号未注册，自动注册并登录case03: 手机号非11位case03-1: 手机号大于11位case03-2: 手机号小于11位case03-3: 手机号为空case03-4: 11位数字非手机号case04: 手机号非数字case05: 验证码非4位case05-1: 验证码大于4位数字case05-2: 验证码小于4位数字case05-3: 验证码为空case05-4: 错误的4位验证码case06: 验证码非数字case07: 验证码有效期大于3分钟case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”case09: 验证“协议单选按钮点击切换选中状态”case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”case10-1: 验证“手机号为空+验证码为空，登录按钮置灰不可点击”case10-2: 验证“手机号为空+验证码不为空，登录按钮置灰不可点击”case10-3: 验证“手机号不为空+验证码为空，登录按钮置灰不可点击”case10-4: 验证“手机号不为空+验证码不为空+协议选择按钮为空，登录按钮置灰不可点击”case10-5: 验证“手机号不为空+验证码不为空+协议选择按钮不为空，登录按钮可点击” case11: 验证页面布局默认值
Step 5: Convert test points to test cases
Take a screenshot of the test case directly as follows:
4. Final summary:
When we get the product, how to write test cases?
In general, we need to think about the following steps: 1) Analyze requirements 2) Sort out rules 3) Disassemble test points 4) Convert into test cases.
We must focus on the needs of the product itself, and also think about whether there is any way for us to consider the problem more comprehensively.
You can consider using the three knowledge points we introduced today: equivalence class division method, boundary value method, and decision table analysis method.
Finally: The complete software testing video tutorial below has been organized and uploaded, and friends who need it can get it by themselves [Guaranteed 100% free]
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.
Acquisition of complete set of information
