1. Design test cases for cases without requirements
For cases without requirements, we can design test cases from the following aspects
Functional testing + interface testing + performance testing + security testing + compatibility testing + usability testing
Case 1: Design a test case for a water cup
Case 2: Design test cases for a login system
2. Design test cases for cases with requirements
The general design idea is as follows:
demand analysis
Summarize what functions are required
design test point
design test cases
1. Exhaustive method
Suppose the given software requirement is: prompt name length is 6~15 digits.
During the test, we set the data as 6, 7, 8 ... 14, 15, so that the test cases are designed through the exhaustive method. If the test cases pass, the function is considered to meet the requirements.
If the given length is not 6~15 digits, but 6~500 digits, how should we design the test cases? It is definitely unrealistic for test cases to pass the exhaustive method.
2. Equivalence class
Concept: Divide all test cases in the input range into several equivalence classes according to the requirements, and take a use case from one of the equivalence classes. If the test case passes the test, the equivalence class in which the test case is located is considered to pass.
The core of the equivalence class is to partition the test data and use fewer test cases to achieve a consistent system test coverage.
Equivalence classes are further divided into valid equivalence classes and invalid equivalence classes:
Effective equivalence class: A collection of data that is valid and meaningful for the requirements.
Invalid equivalence class: A collection of data that is invalid and meaningless for the requirements.
Steps to divide test cases according to equivalence classes:
Identify valid and invalid equivalence classes
Write test cases
example
Requirements: The name can be entered with 6~200 characters. How should we design the test cases?
Step 1: Identify valid and invalid equivalence classes
Valid equivalence classes: 6~200
Invalid equivalence class: less than 6 greater than 200
PS: In fact, you need to divergently consider more situations according to your needs during design. For example, you can also design valid equivalence classes and invalid equivalence classes for character types (numbers, strings, special characters). Here is just a simple For example, only length is considered.
Step 2: Write test cases
3. Boundary value
Boundary value methods are often complementary to equivalence classes. Note that when designing boundary value test cases, you need to add: boundary value + secondary boundary value
Continuing with the example of equivalence classes, this time we add test cases for boundary values:
4. Decision table method
The core of the decision table method is to consider the combination relationship between input and output, draw a decision table according to this relationship, and then design a test case.
Decision table design test case steps:
Determine input conditions and output conditions
Find the relationship between input conditions and output conditions
draw decision table
Write test cases based on decision tables
example
Requirement: If the order has been submitted, and the total amount of the order is greater than 300 yuan or the order has a red envelope, the order is considered to be an order with a discount, otherwise it is an order without a discount.
step1: Determine the input conditions and output conditions
Input conditions: the amount is greater than 300 yuan, there is a red envelope, and the order has been submitted
Output conditions: with discounts, without discounts
step2: Find out the relationship between input conditions and output conditions
step3: draw the judgment table
step4: Write test cases according to the decision table
The amount is greater than 300 yuan, there is no red envelope, no order is submitted, and the result is no discount
The amount is not more than 300 yuan, there is a red envelope, no order is submitted, and the result is no discount
The amount is not more than 300 yuan, there is no red envelope, and the order is submitted, but the result is no discount
If the amount is greater than 300 yuan, there is a red envelope, but no order is submitted, the result is no discount
The amount is greater than 300 yuan, there is no red envelope, and the order is submitted, and the result is that there is a discount
The amount is not more than 300 yuan, there is a red envelope, the order is submitted, and the result is a discount
The amount is greater than 300 yuan, there is a red envelope, the order is submitted, and the result is a discount
The amount is not more than 300 yuan, there is no red envelope, no order is submitted, and the result is no discount
5. Scenario Design Method
5.1 Introduction
Almost all current software uses event triggers to control the process. The scene when the event is triggered forms the scene, and the different trigger sequences and processing results of the same event form the event flow. This method can vividly describe the situation when the event is triggered, which is beneficial to the test designer to design the test case, and makes the test case easier to understand and execute.
A typical application is to use business flow to string together isolated functional points to create an overall business sense for testers, so as to avoid the wrong tendency of falling into functional details and ignoring business process points.
5.2 Basic Design Steps
According to the instructions, describe the basic flow of the program and various alternative flows
Generate different scenarios based on the basic flow and various alternative flows
Generate corresponding test cases for each scenario
Re-review all generated test cases and remove redundant test cases
After the test case is determined, determine the test data value for each test case
5.3 Basic flow and alternative flow
Basic flow: also called effective flow or correct flow, which simulates the user's correct business operation process.
Alternative flow: also called invalid flow or error flow, which simulates the business operation process of user error.
5.4 Usage Scenarios
It is mainly used to test the business logic and business process of the software. Generally, equivalence class division, boundary value analysis, error inference method, cause-and-effect diagram and decision table method are used to verify the single-point function, and then the scenario method is used to verify the business process after the verification is passed.
5.5 Advantages and disadvantages
Advantages: When it comes to business scenarios, using the scenario method is beneficial for test designers to design test cases, making test cases easier to understand and execute.
Disadvantages: Only verify business processes, not single-point functions.
5.6 Example
scene introduction
The user enters the website of the online shopping system for shopping, and purchases after selecting items.
At this time, you need to log in with your account, pay after the login is successful, and generate an order after the transaction is successful to complete the shopping activity.
Step 1: Analyze requirements, determine basic flow and alternative flow events
Step 2: Determine the scene based on the basic flow and the alternative flow
Step 3: Design Use Cases
Step 4: Design the data required in the test case
6. The wrong guess method
The wrong guessing method is based on the understanding of the tested software design, past experience and personal intuition, to speculate on possible defects in the software, so as to design test cases in a targeted manner.
This method emphasizes the understanding of the requirements of the tested software and the details of the design and implementation, as well as personal experience and intuition.
The wrong guessing method is consistent with the basic idea of the currently popular "exploratory testing method". This type of method has a high input-output ratio in the agile development mode and is widely used in testing.
The disadvantage of this method is that it is difficult to systematize and relies too much on individual abilities.
Taking registration as an example, we can directly make wrong guesses about this scenario to design test cases:
How to deal with special characters and spaces in checksum?
Case in password verification?
Special characters in names?
Is the password sent in clear text?
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:
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, and I hope it can help you! Partners can click the small card below to receive