Preface
Today I want to talk about test cases with you. This article is mainly written for test partners, because I find that there are still many friends who don’t know how to start when they encounter writing test cases. I just want to talk to you about it. Just a quick chat, this article is mainly for functional testing.
At the end of this article, the author has prepared a surprise for you.
1. What is a test case?
A test case is a set of test inputs, execution conditions, and expected results compiled for a special goal in order to test a program path or verify whether a specific requirement is met.
In layman's terms: it means describing the operating steps of our test system in words according to a certain format.
2. What are the benefits of writing test cases?
1. Clarify your thoughts and avoid omissions
Here is what we think is the most important point. If the project we test is large and complex, we can subdivide the project functions and organize the ideas of our test system by writing use cases according to each function to avoid missing the functions to be tested. point.
2. Track test progress
By writing test cases and executing test cases, we can clearly know the progress of our testing.
3. Historical reference
In the projects we work on, there may be many functions that are the same or similar. We have designed test cases for such functions so that we can use them as a reference when we encounter similar functions in the future.
4. Repeatability
When we test a system, we can't just test it once by one person. It requires multiple people to test it repeatedly. Then we need test cases to standardize and guide our testing behavior.
3. Test case method
Okay, now that we know what a test case is and why we should write a test case, how should we write it? No way to start. Before we write test cases, we first learn several methods, which are our guiding principles for writing test cases.
1. Equivalence class division
A subset of the input domain in which the input data are equivalent in revealing errors in the program. If there is an input box that requires the input of numbers from 1 to 10,000, it is impossible for us to try every number. Our input of 5 and 6 to verify and expose the errors in the input box can be considered equivalent. Then at this time we can randomly extract some data for verification. Such as: 10, 99, 7777...
Equivalence classes: valid equivalence classes and invalid equivalence classes
The input box requires input of a number from 1 to 10000
Valid equivalence classes: You can enter a number between 1-10000 to verify, such as: 2, 5, 99, 8495...
Invalid equivalence class: You can enter any character other than 1-10000 for verification, such as: 20000, letters, underscores, special symbols, spaces, carriage returns...
2. Boundary value
Boundary values are a supplement to equivalence classes. Testing experience tells us that a large number of errors occur in the boundary values of input and output. Let's take the example above. An input box requires the input of a number between 1-10000. We need to test whether it exceeds this range, such as: 0, -1, -2, 1000, 10001...etc., to determine whether it exceeds our range.
3. Cause and Effect Diagram
The final product generated by the causal diagram method is a decision table, which is suitable for checking various combinations of program input conditions. For example: Reason: A=0, B=0. As a result, I can determine: A=B. To be precise, it is a causal idea. It will implicitly guide our testing. Of course, in order to avoid missing things, we can draw the causal relationships in the system with pictures. However, if the system is large and complex, it will be a laborious task. hehe.
4. Wrong guessing method
Based on experience and intuition, we can speculate on possible errors in the system and design test cases in a targeted manner.
5. Others
There are many methods for designing test cases. We commonly use the above methods. Other methods include: state transition diagram, process analysis method, orthogonal verification method, etc.
4. Format and elements of test cases
A test case should include: number, title, test scenario, test steps, and expected results.
Of course, you can also add some other options, such as: priority, testing phase...
Note: The above format is taken from "Microsoft's Software Testing Method". It may not be suitable for you. I just want to give everyone an understanding of the testing format.
Regarding the storage and management of test cases:
1. The project management system comes with use case management. Generally, use cases are linked to the project, have a fixed format, search, modification and other functions, and are very convenient to use. For example: ZenTao project management, QC, bugfree, etc. all have use case management functions.
2. Managed through world\Excel document form, the advantage of this is that you can define the format of test cases by yourself.
Test case example
Now that we have almost understood the basic knowledge, let’s look at a specific test case. We will have a deeper understanding.
Note: This is not a complete test case, and the format is not fixed. You can write design test cases according to your own needs.
Apart from the above we also need to know about test cases.
5. When can we design test cases?
When the project requirements analysis document is compiled according to the customer's needs, we can write test cases based on the requirements document. However, generally our project requirements documents (most small companies in China) are very "rudimentary", so it is difficult to design test cases based on the requirements documents.
We have to wait until the project developers develop the project and give us system documents, deployment environment, and database structure (if the system involves a database), and we eliminate these documents to design test cases.
6. Review and update of test cases
After the test case design we designed is completed, is it complete? Does it comply with the system? Meet customer requirements? A review of the use cases is essential. Regarding the review methods, different companies have different processes.
The test cases we write do not remain unchanged after review. As requirements change and functions improve, test cases will of course also need to be updated and changed.
7. Under what circumstances is it not suitable to write test cases?
1. File time
If I test a function quickly and only need to test it once, it is more troublesome and takes a long time when we design test cases. There is no need to write test cases at this time.
2. Demand changes greatly and frequently
The required functions change very frequently and greatly. The test cases written before cannot be used at all and must be rewritten. There is no need to design test cases at this time.
3. Project time does not allow
This is not a very kind approach. If there is no urgent need to deliver it to customers, try not to do it; of course, if it is just for display or trial use to customers, you can supplement and improve the test cases later.
Don't write test cases that are incomplete or incomprehensible to others, as that would be meaningless.