What makes a “good” test case?

A “good” test case must be a complete set that covers all equivalence classes and boundary values, regardless of whether defects can be found

For chestnuts

Tested software – fish pond

Software bug – fish

Test case set — Fishing nets

A “good” set of test cases is a large net that covers the entire fishpond and can be retrieved as long as there are fish in the pond;

If the net itself is fully qualified, then the failure to catch fish proves that there are no fish in the pond, and the quality of the net has nothing to do with whether there are fish in the pond

 

What characteristics a “good” test case must have

  1. Overall completeness: it must be a complete whole, a set of valid test cases that can fully cover testing requirements
  2. Accuracy of equivalence class division: for each equivalence class, it can ensure that as long as one of the input tests passes, the other input pages must pass
  3. Completeness of the set of equivalence classes: it is necessary to ensure that all possible boundary values and boundary conditions have been correctly identified

 

The three most commonly used test case design approaches

  1. Equivalence division
  2. Boundary value analysis
  3. Error inference method: Based on the understanding of the design of the software system under test, past experience and personal intuition, the possible defects of the software are speculated, so as to design the test case method accordingly. Emphasis is to understand the requirements of the software under test and grasp the details of the design implementation

Examples of false inference

 

How to design “good” test cases

Big Chestnut: Test GUI tests for end users

The core test point: verify the software to meet the requirements

How to do this: Start in the requirements analysis phase and the technical design phase

Effectiveness: Designed a set of end-to-end test cases from the end user scenarios, mainly to verify whether each business requirement is met, based on the black box test design method

Key points: In the design of specific use cases, we should first make clear the multiple software functional demand points corresponding to each business requirement, then analyze the multiple test demand points corresponding to each software functional demand point, and finally design test cases for each test demand point

Is it around?? (; ´ д ゞ `)

Xiao Li: Design test cases with the “user login” function

First, take a look at the mapping diagram of the User Login function

Two key points:

  1. 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.
  2. To identify each test demand point, it is necessary to comprehensively design test cases by using equivalence class partition, boundary value analysis and error prediction methods.

Take the functional requirements for user login as an example

  1. First of all, the input fields of “username” and “password” are divided into equivalence classes respectively. For the identification of invalid equivalence classes, error prediction method can be adopted (for example, the username contains special characters).
  2. Then add the input field boundary value use case, such as: empty, user name length is just greater than the limit length

 

Advanced experience in designing test cases

Deep understanding of the architecture of the software under test to identify potential errors in system boundaries and integration

You must have a clear understanding of the internal architecture, such as database connectivity, database read-write separation, messaging middleware configuration, hierarchical distribution of caching systems, and integration of third-party systems

Must have a deep understanding of the design and implementation details and internal processing logic of the software under test

Designing test cases only according to test points can only cover the “surface” layer, and often the internal processing process and branch processing cannot cover completely. In practice, code coverage metrics can be used to identify possible test omissions

Introduce requirements coverage and code coverage to measure the completeness of test execution

Subsequent introduction

 

“Extra meals” in the comments section

  1. [Requirements rationality testing] user experience testing is also very important now
  2. In a fast-paced, iterative, agile development pace, it is not necessary to write every use case so complex that it is important to write the test points clearly, not the obvious steps, environments, and expectations perfectly