Talk about login test
Maybe you will say, the test object of "user login" is a bit too simple, I just want to find a user, let him enter the username and password on the interface, and then click the "confirm" button to verify whether the login is successful . Indeed, this constitutes the most basic and typical test case, which is also the most typical scenario when end users use the system.
But as a test engineer, your goal is to ensure that the function of the system in various application scenarios meets the design requirements, so you need to consider more and more comprehensive test cases, so you may be based on "user login" Functional requirements description, combined with equivalent class division and boundary value analysis methods to design a series of test cases.
Equivalence class, boundary value
So what are the equivalence class division and boundary value analysis methods? First, both of them belong to the most commonly used, most typical, and most important black box test methods.
The equivalence class division method is to divide all possible input data into several subsets. In each subset, if any input data has the same effect on revealing potential errors in the program, then such a subset constitutes an equal Price category. Later, as long as a value is randomly selected from each equivalence class for testing, a small amount of representative test input can be used to obtain better test coverage results.
The boundary value analysis method is to select the input and output boundary values for testing. Because a large number of software errors usually occur on the boundary of the input or output range, it is necessary to focus on the boundary value test, usually choose the value that is exactly equal to, just above or just below the boundary as the test data. It can be seen from the methodology that boundary value analysis is complementary to the division of equivalence classes, so these two test methods are often used in combination
Now, for the "user login" function, based on the equivalence class division and boundary value analysis methods, the test cases we designed include:
after listing these test cases, you may already feel more satisfied because you feel that you have put your own test Knowledge is used in the design of these use cases.
Indeed, the above set of test cases already covers the main functional test scenarios. But in the eyes of an excellent test engineer, these use cases can only reach barely passing standards.
What? Just passed? If you have this idea, then I suggest you to think carefully before continuing to read the following content. Do these test cases really need to be expanded?
Now, share some more test cases that experienced test engineers will add:
After reading these use cases, you might say: "Wow, there are so many points that need to be tested for a simple login function." However, don't be too happy, the "user login" feature test is not over yet.
Although the improved test case set has indeed improved a lot compared to the previous test coverage, from the perspective of senior testers, there are many use cases that need to be designed.
As I said, you may have discovered that all the test case design above is based on the verification of explicit functional requirements. In other words, these test cases are directly verified for the functionality of the "user login" function And tested.
However, in addition to the explicit functional requirements, other non-functional requirements, that is, implicit functional requirements, are also critical for a software system of excellent quality. The meaning of explicit functional requirements can be understood very literally, referring to the specific functions that the software itself needs to implement, such as "normal users can successfully log in with the correct user name and password", "non-registered The user cannot log in "etc., which are all typical explicit functional requirements descriptions.
What is a non-functional requirement? From the perspective of software testing, non-functional requirements mainly involve three aspects: security, performance, and compatibility. In all the test case design above, we have not considered the testing of non-functional requirements at all, but these are often the key factors that determine the quality of software.
After understanding the importance of non-functional requirements testing, you can first think about which test cases you need to design, and then take a look at which use cases I will give, I believe this way will help you more.
Security test case:
Performance test cases:
Compatibility test cases:
Speaking of which, do you still think that the "user login" function test is very simple and worthless? A seemingly simple functional test actually covers so many test cases, in addition to covering clear functional requirements, There are many other non-functional requirements that need to be considered.
In addition, through the design of these test cases, you can also find that an excellent test engineer must have a very broad knowledge, if you can not have a deep understanding of the design of the system under test, do not understand the basic principles of security attacks, no Mastering the basic design methods of performance testing makes it difficult to design "targeted" test cases.
Through the "user login" function test this example, I hope that it can stimulate you to think more about the test, and open up your ideas for designing test cases, in order to achieve the effect of throwing a brick.
After reading these test cases, you may say that there are still some missing test points that are not covered, and the test points of this function are not comprehensive enough.
The inexhaustibility of testing means that in most cases, it is impossible to perform exhaustive testing.
The so-called "exhaustive test" refers to a test method that includes all possible combinations of software input values and prerequisites. The system that completes the exhaustive test should not leave any unknown software defects. Because if there are unknown software defects, you can find them by doing more tests, which means that your tests have not been exhausted.
However, in the vast majority of software engineering practices, testing is limited by time and economic costs, and it is impossible to exhaust all possible combinations. Instead, a risk-driven model is adopted and the test scope is selected with some emphasis And design test cases to find a balance between defect risk and R & D costs.
to sum up
First, for high-quality software testing, use-case design not only needs to consider explicit explicit functional requirements, but also involves a series of non-functional requirements such as compatibility, security, and performance. These non-functional requirements Quality plays a decisive role.
Secondly, an excellent test engineer must have a broad knowledge to design targeted test cases that are easier to find problems.
Finally, the use case design of software testing is inexhaustible. In engineering practice, it is difficult to avoid the time cost and economic cost. Therefore, an excellent test engineer needs to balance the risk of defects and the cost of development.
————————————————
Copyright Statement: This article is an original article of CSDN blogger “yinlin330”, following the CC 4.0 BY-SA copyright agreement, please attach the original source link and this statement for reprint .
Original link: https://blog.csdn.net/yinlin330/article/details/90607335
