Preface
As a new tester, I just started to get into testing. I have a headache about how to write test cases. I can't understand the requirements. I can only do the test from the user's perspective. However, this situation will lead to the inability to test the APP in all aspects. This situation is I need a test case, but I don’t know how to write it. Please give me some advice! And how to track the bugs that come out of the test? Contact with development is basically face-to-face communication, and there is no good standard.
Learning with questions is the most efficient way to learn.
Table of contents
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 first look at a test of the login function of the software system (as shown in the screenshot below):
To make a test case for this login page, what aspects will you consider for testing?
How many test cases can be designed to complete a more comprehensive test for a seemingly simple page function? Within 10 items? 20 items? .......
So before giving the above answer, let us first familiarize ourselves with what is a test case? What do test cases do? Then, combined with the above-mentioned cases, we will discuss how to write test cases?
The following is a screenshot of the directory of this article:
1. What is a test case?
Test case: A set of documents consisting of test inputs, execution conditions, and expected results designed for a specific purpose (to prove that a certain problem exists in the software)
1. Test cases are simply documents that guide how to do testing. This document mainly records the need to verify whether the software under test meets the requirements.
2. There are two common forms of test case expression, 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 directly organize test points through xmind
——When time is tight and the project does not have mandatory requirements, you can write it in the form of designing test points
——For business process tests, they can also be organized into test points for testing.
3. Design and implementation personnel: test engineer
4. Use case template: Describe the core content of writing use cases. Generally, projects have their own design use case templates. Common test case templates can be referred to as follows:
In order to support friends who are new to the industry, here I also share hundreds of learning materials and explanation videos that I have carefully compiled over the years. They are definitely useful for beginners. They are all listed below. No more nonsense. The end of the article is free. Get~
2. Why write test cases?
Why write test cases? In practice, if there is a problem with the product, the first thing the person responsible for thinks of is why the test didn't detect it?
There is a problem with the product, why didn't you test it?
Of course, in addition to avoiding "passing the blame", the more important functions of writing test cases are as follows:
- Technically convert requirements into specific and verifiable indicators
- Document possible problems with the software
- Prevent omissions in activities during the testing process and improve work efficiency
- Demonstration of testing workload
3. How to write test cases
Since writing test cases is so important, how to write test cases better? Personally, I think the following points need to be met: - Conventional thinking, put yourself in the user's shoes (for example: Do actual users use it this way, will they encounter abnormal situations?) - Support from testing theoretical methods (for example: According to needs When designing test cases, what common test case design methods can be used?) - Familiarity with the product and accumulation of experience (for example: already have experience in type projects, have had problems in some aspects, how were they handled at that time) ?) The above-mentioned design use case process has a prerequisite, which is to have patience and perseverance for testing, plus daily conscious thinking training, so that comprehensive use cases can be written.
1. Conventional thinking
Returning to the question at the beginning, for a basic login page, according to the conventional thinking, can you think of the test points as shown in the screenshot below? In fact, these test points are all derived from the process of detailed design based on the needs from the user's perspective. Are these test points the only ones used in actual testing?
2. Learning and accumulation
I believe that most test engineers can think of the above basic test points. However, the projects they face in actual work are different, and the granularity of designed test cases also has different requirements. What if we consider the above-mentioned login modules in a deeper level? At this time, you need the support of familiarity with the product and testing experience, and the design of these points is obtained through continuous learning, familiarity with the project, and accumulation of testing.
3. Theoretical support
With conventional thinking and experience accumulation, theoretical support is also needed. After all, test cases are designed through human thinking, and omissions are inevitable in this process. How to avoid it? In practice, the support of testing theory is needed. Personally, I think that in-depth thinking about design use cases is nothing more than the following two aspects:
1) Design method of test cases
A key part of testing theory is to split the requirements into specific test points, and then carry out specific designs 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 usage scenarios. , the accumulation of personal testing experience (if any), split large sections of content into test points that can directly use the use case design method, so that it can be directly converted into Excel test cases through concise text descriptions, in this The process is generally understood as a process of splitting and refining until a use case can be directly written to verify a specific function point.
Well-known design use case methods include:
- Observation
- Equivalence classes, boundary values
- Decision table, cause and effect diagram
- Flow chart, scenario method
- Wrong guessing, etc.
2) Development of ideas for test design
If all the existing description information has been split according to the requirements, can we ensure that there are no problems in the test?
In fact, this is not the case. If you need to expand comprehensive testing based on the above, you will also need to rely on the characteristics of the software quality model. Based on these characteristics, test case designers will be given more room to think. This design is more comprehensive and reliable.
Description of common software quality model characteristics:
-Functionality: Does it have functions? Is it easy to use?
- Performance efficiency: corresponding to the system’s resource consumption and response time
- Ease of use: easy to understand, learn, and use
- Compatibility: Compatible with different software and hardware platforms
- Reliability: less likely to go wrong, and easy to recover if something goes wrong
- Security: User safety (external life security, internal information security, etc.)
- Portability: ability to operate without glitches in different environmental conditions
- Maintainability: Is it convenient and quick 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:
4. Write at the end
Looking back at this time, do you still think that logging in, a function that has been tried and tested, is enough to design a dozen or even dozens of test cases? Obviously it is not that simple. It needs to be split and refined on the basis of familiarity with the requirements, and conventional thinking, accumulation of experience, and theoretical support can be combined and used to finally transform it into results to be verified by testing.
The first step is to familiarize yourself with the requirements, and on this basis, split and refine the test points. For more complex functional points, you need to rely on test case design methods. The most common application is for page-level test points. It is almost an equivalence class and a boundary value.
Just being familiar with the needs, you also need to combine the accumulation of experience and start from the characteristics of the quality model to comprehensively think about the design of function points to see if there are any omissions and whether there are any special requirements for the project.
The design of use cases is not something that can be accomplished overnight. Good use cases also require continuous practice and repeated revision and review in order to write excellent use cases.
That’s the end of today’s sharing. If you still don’t understand anything, you can ask in the comment area. If my article is helpful to you, you can like Sanlian to support it.