With the requirements analyzed and the test scoped, it’s time to design the test cases. The question is: How do you design a “good” test case?

First, what is “good”

Ru Bingsheng used fish pond to distance me.

If you think of the software under test as a pond, and software defects are the fish in the pond, the process of building a test case set is like weaving a fishing net. A "good" set of test cases is a large net that covers an entire pond and is guaranteed to scoop up any fish that are in the pond. If the net itself is complete and up to standard, the failure to catch fish proves that there are no fish in the pond, and the quality of the net is independent of whether there are fish in the pond.Copy the code

Therefore, a “good” test case must be a complete set that covers all equivalence classes and boundary values, regardless of whether it ultimately finds defects.

“Good” use cases have characteristics

1. Overall completeness

Often, a function point needs to involve multiple use cases to cover all aspects, so test cases are a complete whole, a set of effective test cases, which can fully cover the test requirements.

2. Accurately classify equivalence classes

This means that for each equivalence class, it is guaranteed that if one of the input tests passes, the others will also pass.

For example, in the test of wechat red envelope, 0< amount <=200 is one of the equivalence classes. Any number in any range can pass, indicating that this equivalence class is accurate.

3. Completeness of equivalence class set

You need to ensure that all possible boundary values and boundary conditions have been correctly identified.

Take the above red envelopes as an example. The amount <=0 and the amount >200 belong to the invalid equivalence class. 0 and 200 are boundary values, which should be determined clearly.

The three most commonly used methods of use case design

How come there are three? There are so many on the Internet and in books.

Such as equivalence class partition method, boundary value analysis method, error prediction method, causal graph method, decision table driven analysis method, orthogonal experimental design method, function graph analysis method, scene design method, formal method, extended finite state machine method and so on.

However, from the practical point of view, only the first three methods have real practical value and are commonly used: equivalence class division method, boundary value analysis method and error conjecture method.

Note that this is not to say that other approaches do not work; in some specific areas, where test coverage requirements are almost perverted, more test design approaches will be adopted. However, for most software testing, a combination of equivalence partitioning, boundary value analysis and error prediction is sufficient.

Do you think you are?

1. Equivalence class division method

Any input data in an equivalence class has the same effect on exposing potential errors in a program. As long as we choose any value from each equivalence class to test, we can obtain good test coverage results with a small number of representative test inputs.

Valid and invalid equivalence classes are usually considered.

For example, the student information system has a “test score” input. The score is an integer ranging from 0 to 100, and the score score is 60.

Valid equivalence class any integer between 1:0 and 59: any integer between 59 and 100 Invalid equivalence class 1: negative number less than 0 2: integer greater than 100 3: floating point number between 0 and 100 4: other non-numeric charactersCopy the code

2. Boundary value analysis method

Boundary value analysis is a supplement to equivalence class partitioning. You can find from practical experience that a large number of errors occur on the boundary values of input and output.

Therefore, it is necessary to conduct a key test on the boundary value, usually selecting the value exactly equal to, just greater than or just less than the boundary as the test data.

Continuing with the example of “test scores” in the student information system, the selected boundary values should include: -1, 0, 1, 59, 60, 61, 99, 100, 101.

3. Wrong guess method

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. The disadvantages are also obvious: it is difficult to systematize and relies too much on individual ability.

For example:

  • Web page testing needs to consider how the browser performs with and without caching
  • In Web API testing, you need to consider the processing logic when the third-party API on which the API under test depends fails
  • Code-level unit testing requires consideration of internal processing logic in the case that the input parameters of the function under test are null

The design of these test cases is based on false assumptions based on problems encountered before, largely depending on individual competence.

In order to reduce the dependence on individual ability, enterprises usually establish a knowledge base of common defects. In the process of test design, they use the knowledge base as a checklist to help optimize the design of supplementary test cases.

How to design “good” test cases?

There is no consistent formula for this.

In real engineering practice, different software projects will have different types of tests at different stages of the development life cycle. Such as unit testing, integration testing, GUI testing, API testing, middleware testing, and so on. For different types of tests, the design of test cases can vary greatly; some may use a black-box approach, some may use a white-box approach, and some may use a grey-box approach.

However, one thing is certain: to do good test analysis, you must have a deep understanding of requirements. This is why we want testing to start at the requirements analysis and design stage.

Then do these 2 things well:

  • 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 each identified test demand point, equivalence class division, boundary value analysis and error prediction methods should be used to design test cases comprehensively.

Five, other easy to be ignored “secrets”

I remember one of the test masters of airline tickets told me that you should never jump right into a specific business. Looking back on his words now, it was.

We often get a specific requirement and start testing against it, but have a poor understanding of the architecture, which is to our disadvantage:

1. Do not put the whole system under test as a big black box

Must have a clear understanding of the internal architecture, such as database connection mode, database read/write separation, message middleware Kafka configuration, cache system hierarchy distribution, third-party system integration, etc.

2. Must have an in-depth understanding of the design and implementation details of the software under test, as well as the internal processing logic of the software

A use case designed only according to the test requirement point can only cover one layer of the “surface”, often failing to cover the internal processing process and branch processing, and the part not covered is likely to have defects.

3. Never design test cases based on the implementation of development code

Because errors in developing code implementations can lead to errors in test cases, you should design test cases according to the original requirements.

4. Introduce requirements and code coverage

Introduce requirements coverage and code coverage to measure the completeness of test execution and use this as a basis to identify missing test points. Requirements coverage is actually easy to do, but code coverage may take some effort, but I’ll talk about that later.