preface

I’ve never been good to write a test case, before doing development while writing unit tests and process test, basically all is based on your own code, and unit test and process test box and the specification has been very perfect, you just need to fill in the blanks, then switched to automated testing, but also stay in my way of doing things and thinking development level, Use cases are basically extracted from the manual business function test set. I only need to convert this subset into script code to run, instead of systematically writing a use case by hand according to the business requirements. In our spare time, we would also talk about what is a good test case. Before getting into this, I went to systematically look at the basis of the test. There are many ways to test. From the Internet can also search a lot of information in this area, I also sum up the knowledge of predecessors.

Test method

As a test, our main goal is to ensure that the system functions as designed in various application scenarios, so you need to consider more and more comprehensive test cases. How do we design test cases? We usually design a series of test cases according to the business requirements of the function under test, usually using equivalence class partitioning and boundary value analysis methods

Equivalence class partition method

It is to divide all possible input data into several subsets. In each subset, if any input data has the same effect on exposing potential errors in the program, then such subsets constitute an equivalence class. As long as a random value is selected from each equivalence class to test, a small number of representative test inputs can be used to obtain good test coverage results.

For example

A very common example: a student’s test score, which is an integer between 0 and 100, with 60 passing. In order to test this input, it is obviously not possible to test every number from 0 to 100 (except for those size tests, if you want to run all of them, consider scripting them).

So we can classify equivalence classes, pass classes and fail classes based on the requirement that this grade pass or fail classes and then we can verify that by randomly picking integers between 0 and 59 and 60 and 00. Such designs constitute what are known as “valid equivalence classes”.

We don’t end there, because another key point of equivalence partitioning is to find all the “invalid equivalence classes.” Obviously, if the input score is negative, or a number greater than 100, etc., it constitutes an “invalid equivalence class”. After considering invalid equivalence classes, the final test case is as follows:

• Any integer between 1:0 and 59 of the valid equivalence class;
• Any integer between the valid equivalence class 2:59 and 100;
• Invalid equivalence class 1: negative number less than 0;
• Invalid equivalence class 2: integers greater than 100;
• Any floating point number between the invalid equivalence class 3:0 and 100;
• Invalid equivalence class 4: Any other non-numeric character.

Boundary value analysis method

Is to select input, output boundary value for testing. Because most software errors occur at the boundary of the input or output range, it is necessary to focus on testing the boundary values, usually selecting values that are exactly equal to, just greater than or just less than the boundary as test data. The boundary value analysis method is a supplement to equivalence class partitioning. Then the boundary value data selected based on the above example of students’ scores should include: -1, 0, 1, 59, 60, 61, 99, 100, 101.

Method of miscalculation

Error prediction method refers to the method of calculating the possible defects of the software based on the understanding, past experience and personal intuition of the design of the tested software system, so as to design test cases in a targeted manner. This approach emphasizes the understanding of the requirements of the software being tested and the mastery of the details of the design implementation, as well as the ability of individuals. Error conjecture and the current very popular “exploratory testing method” of basic ideas and concepts, such as the relationship between modules under test and impact, when there is a requirement change in one place, other places will be affected

How do you design “good” test cases?

In addition to the above three methods, there are other methods of testing, mastering the most common of them, you can basically design test cases.

For functional testing, the core test point is to verify the software to meet the requirements, which requires test engineers to have a deep understanding of the requirements of the tested software. The requirements analysis and design phase is the time to start designing test cases with requirements review meetings along with the development product, because this phase is the best time to understand and master the original business requirements for the software. Only with a true understanding of the original business requirements can it be possible to design a set of end-2-end test cases that are clearly targeted from a business requirement perspective and consider end-user usage scenarios. The main purpose of test case design in this stage is to verify whether each business requirement is met, and the test design method based on black box is mainly adopted.

In the specific use case design, it is necessary to make clear the multiple software functional requirement points corresponding to each business requirement, and then analyze the multiple test requirement points corresponding to each software functional requirement point, and finally design test cases for each test requirement point. Taking the test case design of the “user login” function as an example, the following figure illustrates the mapping between these concepts. The mapping of business requirements to software functional requirements, software functional requirements to test requirements, and test requirements to test cases is shown in the figure

Points to note when designing use cases

When it comes to the design of the test case itself, there are two key points to note.

From the perspective of software functional requirements, it is very important to identify test requirements comprehensively and without omission, which is directly related to test coverage of use cases. For example, if you fail to identify security testing requirements for user login functionality, subsequent test cases will not address security at all, resulting in significant test vulnerabilities.

For each identified test demand point, equivalence class division, boundary value analysis and error prediction methods should be used to design test cases comprehensively. It is important to combine these three methods and make flexible choices according to the specific situation of each test requirement point. “User login” functional test requirements, for example, the first thing you should to the “user name” and “password” the two input item separately equivalence class division, listed corresponding effective equivalence class and invalid equivalence class, for the identification of invalid equivalence class can use error guessing method (for example, the user name contains special characters, etc.), and then based on the combination of both may, Design the first test cases. After the equivalence class is divided, you need to add the test cases of the boundary values of “username” and “password”, for example, the user name is NULL, and the user name length is just larger than the allowed length.

conclusion

A good test case must be a complete set, which can cover all equivalence classes and boundary values, and the detection of software defects is not the criterion to measure the quality of a test case. Secondly, there are many methods to design test cases, but the comprehensive application of equivalence class division, boundary value analysis and error speculation can meet the needs of most software test case design. Thirdly, “good” test cases should be designed from the perspective of software functional requirements. It is crucial to comprehensively identify test requirements without omission. Finally, if you want to design a “good” test case, you must deeply understand the architectural design of the software under test and the processing logic inside the software.

In this way, it is not only manual testing or automated testing. Only with the support of a perfect set of excellent test cases can the quality of products be better guaranteed. On the other hand, in the self-testing stage of development, some tests can be done by referring to test cases.

Development and testing are never opposites, and neither are manual and automated testing. Everyone is an integral part of the development process, complementing each other to get this thing right. But in real projects, there are all kinds of problems, and this is a different story.