foreword
As a new tester, I just started to get in touch with testing. I have a headache about how to write test cases, and I can’t touch the requirements. I can only test from the perspective of users. However, this situation will lead to the inability to test the APP in all directions. I need a test case, but I can't write it, please advise! Also, how to track the bugs that are tested? The contact with the development is basically face-to-face communication, there is no good standard
Learning with questions is the most efficient way of learning.
Table of contents
foreword
1. What is a test case
2. Why write test cases
3. How to write test cases
Therefore, before introducing how to write test cases, let’s look at a test of the login function of a software system (as shown in the screenshot below):
To make a test case for this login page, what aspects would you think about testing?
How many test cases can be designed for a seemingly simple page function to complete a more comprehensive test? Within 10? 20 pieces? …
So before giving the above answers, let us familiarize ourselves with what is a test case? What does a test case do? Then discuss how to write test cases in combination with the above-mentioned cases.
Here is a screenshot of this directory:
1. What is a test case
Test case: A set of documents consisting of test input, execution conditions, and expected results designed for a specific purpose (to prove that there is a problem in the software)
1. The test case is simply a document that guides how to do the test. This document mainly records the need to verify whether the software under test meets the requirements.
2. There are two common manifestations of test cases, which can be displayed in the form of templates
1) One is to write directly through Excel
——Most projects need to be designed and written in this way
2) One is to organize test points directly through xmind
——Time is tight, and when the project does not have mandatory requirements, it can be written in the form of design test points
——For business process tests, it can also be organized into test points for testing
3. Design and execution personnel: test engineer
4. Use case templates: describe the core content of writing use cases. Generally, projects have their own templates for designing use cases. Common test case templates can be referred to as follows:
2. Why write test cases
Why do you need to write test cases? In reality, if there is a problem with the product, the first thing the person in charge thinks of is why the test didn’t detect it?
There is a problem with the product, why didn't you detect it?
Of course, in addition to avoiding "throwing the pot and taking the blame", the more important role of writing test cases is as follows:
- Technically transform requirements into specific and verifiable indicators
- Record the possible problems of the software in the form of documents
- Prevent missing activities in the testing process and improve work efficiency
- Demonstration of test workload
3. How to write test cases
Since writing test cases is so important, how to better write test cases? I personally think that the following points need to be met: - Conventional thinking, put yourself in the user's perspective (for example: is the actual user using this way, will there be any abnormal situations?) - Support for testing theoretical methods (for example: according to the needs What common test case design methods can be used when designing test cases?) - Familiarity with products and accumulation of experience (for example: I have had experience in type projects, and I have had problems in a certain aspect, how did I deal with them at that time? ?) There is a prerequisite for the above-mentioned design use case process, which is to have patience and perseverance for testing, coupled with daily conscious thinking training, can write a comprehensive use case.
1. Conventional thinking
Returning to the question at the beginning, for a basic login page, can you think of the test points in the following screenshots according to the conventional thinking? In fact, these test points are all derived from the process of detailed design based on the user's perspective and combined with the requirements. Are there only these test points in the actual test?
2. Learning accumulation
I believe that most test engineers can think of the above-mentioned basic test points. However, in actual work, the projects faced are different, and the granularity of design test cases also has different requirements. How about a deeper consideration for the above-mentioned logged-in modules? At this time, the familiarity of the product and the blessing of testing experience are needed, and the design of these points is obtained through continuous learning, familiarity with the project, and test accumulation.
3. Theoretical support
With conventional thinking and experience accumulation, theoretical support is also needed. After all, test cases are designed through human thinking, and there are inevitably omissions in this process. How to avoid it? In fact, the support of test theory is needed. I personally think that in-depth thinking about design use cases is nothing more than the following two aspects:
1) Design method of test case
A key part of the test theory is to split the requirements into specific test points, and then carry out specific design according to the use case design method. The key to splitting the requirements is to be familiar with the requirements, and to use the existing descriptions in the document according to the user's usage scenarios. , Accumulation of personal test experience (if any), splitting large sections of content into test points that can be directly used in the use case design method, so that it can be directly converted into Excel test cases through concise text descriptions, in this The popular understanding of the process is the process of splitting and refining, until you can directly write use cases to verify a specific function point.
Among the well-known design use case methods are:
- Observation
- Equivalence classes, boundary values
- Decision tables, cause and effect diagrams
- Flow chart, scene method
- Miscalculation, etc.
2) Develop ideas for test design
If the existing description information has been split according to the requirements, can it be ensured that there is no problem with the test?
In fact, if it is necessary to expand comprehensive testing on the basis of the above, it is necessary to rely on the characteristics of the software quality model. Starting from these characteristics, test case designers are given more room for thinking. This design is more comprehensive and reliable.
Description of common software quality model features:
- Functionality: whether the function is available, whether it is easy to use
- Performance efficiency: corresponding to system resource consumption and response time
- Ease of use: easy to understand, learn and use
- Compatibility: Compatible with different hardware and software platforms
- Reliability: It is not easy to go wrong, and it is easy to recover in case of a problem
- Security: security guarantee for users (external life security, internal information security, etc.)
- Portability: ability to operate trouble-free under different environmental conditions
- Maintainability: Whether it is convenient and fast for later repair and maintenance
Therefore, for the above login function, following the guidance of the above quality model, the following test points are obtained:
Fourth, write at the end
At this time, when you look back, do you still think that you have to design a dozen or even dozens of test cases for the function of logging in, which is a tried and tested function? It is obviously not that simple. It needs to be split and refined on the basis of familiarity with the requirements, and the combination of conventional thinking, experience accumulation, and theoretical support can finally be transformed into the results of the test to be verified.
Familiarize yourself with the first step in the requirements , and on this basis, split and refine the test points. If this process is for more complex function points, you need to rely on the design method of test cases, which is the most widely used for page-level test points. It is almost an equivalence class and a boundary value.
It is only necessary to be familiar with the needs, and it is also necessary to combine the accumulation of experience , starting from the characteristics of the quality model , to conduct a comprehensive design of function points, whether there are omissions, and whether there are special requirements for the project.
The design of use cases is not something that can be achieved overnight. Good use cases also require continuous practice , repeated revisions and reviews , in order to write excellent use cases.
