Author: JD Logistics Wang Yukun

Software test design is an important testing activity in the testing process. How to design test cases can improve the efficiency and quality of our testing. A brief explanation is given from the following aspects.

1 Principles of test case design

The basic principles of test case design include: effectiveness, clarity, reusability, maintainability, integrity, compatibility, ease of operation, manageability, and evaluability

1. Effectiveness: The test case steps must be clearly described, and ambiguous and repeated words cannot appear. Test cases should be written in a certain order, so that the execution efficiency is relatively high.
2. Clarity: The operation steps of the use case should be clearly described, including clear input data and expected output. The verification point must be clear and clear, and can highlight the key points. For procedural use cases, it is recommended to arrange the use cases in the order of the process, starting from the first verification point To the last verification point, from the beginning to the end of the composition process, it is convenient for test execution. If the test case contains preconditions, the preconditions must be clearly described, including entry points, etc.
3. Reusability: Reusable, and try to abstract and classify test cases with similar functions.
4. Maintainability: When the test case changes due to business requirements, it is necessary to update and maintain the test case in time to ensure the real-time performance and effectiveness of the test case. The test case needs to be refined and continuously improved, which is a gradual process.
5. Completeness: Whether the use case is complete and covers all requirements, so as to fully understand the requirements.
6. Compatibility: Test cases should include test points such as compatibility between old and new versions, compatibility between old and new data, and browser compatibility.
7. Manageability: Ability to detect testers’ test progress, workload, etc.
8. Evaluability: The passing rate of test cases and the number of defects are the criteria for evaluating the quality of software.

2 The life cycle of a test case

The design phase of software test cases includes: requirements analysis, test case design, test case implementation, test case execution, test case management

2.1 Demand Analysis

The first step in the test case process is to determine what to test, identify and prioritize test points.

2.2 Test case design

Test case design determines how to test the analyzed test points.

The main point of test design is to determine the expected results of the test. In order to determine the expected test results, testers not only need to pay attention to the test output, but also need to pay attention to the pre- and post-conditions of the test data and test environment. If the test case does not have the expected test result, it is meaningless for the test case to judge whether the test result is right or wrong.

The expected results of the test can be various, including the results that need to be created or output, the results that need to be updated or changed, or the results that need to be deleted. Each test case should clearly describe the expected results of the test. In this way, it is necessary for testers to have rich knowledge and experience related to the system under test to make a correct evaluation of the test output of the software system. If the test output evaluation is considered correct, it can be used as the expected output of the test case.

2.3 Test case realization

The process of test case realization includes preparation of test scripts, test input, test data, and expected results. A test script refers to organizing data or instructions according to a standard syntax. Before the test is executed, the test preconditions must first be met. For example, if a test case needs to use some configured data, then this data must be created in advance.

2.4 Test case execution

Test the system under test by running test cases. For manual testing, test execution mainly refers to the steps of the test case, compares the expected results with the actual results, and records the problems found during the test.

For the automated testing process, it is necessary to use testing tools during execution, run test case scripts, etc., and record test results.

If the actual result is the same as the expected result when executing the test, it is considered to have passed. If not, then the execution of the use case failed, or there is a problem. If the execution of the use case fails, further inspection is required to determine whether it is a software problem or the expectation of the use case If there is a problem with the result, or it is caused by a data problem or an environmental problem, it needs to be analyzed from different aspects.

2.5 Test case management

1) Test case organization

Each project has a very large number of test cases. How to organize, track and maintain test cases is a very important thing. How to organize the test cases is an important factor for the success of the test and an important step to improve the test efficiency.

The organization of test cases can be organized or categorized in different ways:

• Organize according to software function modules: software systems generally assign work tasks according to software function modules. Therefore, it is a very common method to design and execute test cases based on software function modules. Organizing test cases according to modules can ensure that test cases can cover each system module and achieve better module test coverage.
• Organize by test case priority: Test cases are prioritized. For any software, it is not realistic to implement exhaustive testing. With limited resources and time, the high priority test cases should be executed first.

Dividing according to functional modules is the most commonly used, and we can also use them in combination, for example, on the basis of dividing according to functional modules, and then divide them into different priorities.

2) Test case tracking

The tracking of test cases is mainly carried out for the state of test cases in the process of test execution. Through the tracking and management of test state, the management and evaluation of test process and test effectiveness can be realized.

• Tracking of test case execution: In the process of test execution, tracking the state of test cases can effectively quantify the test process. For example, in the process of executing a round of testing, what is the number of test cases tested, and what are the proportions of passed, failed, and untested test cases. These data can provide some information to judge the quality and execution progress of the software project, and provide clear data on the test progress and status, which is conducive to the control of the test progress and test focus.

3) Test case maintenance

The test cases are not static. When the test process of a stage is over, it will be found that some test cases are unreasonably written, or the requirements have changed. This requires some current test cases to be modified and updated, so that the test cases have Reusability.

3 Elements of test case writing

• Use case number: the unique identification of the use case
• Test module: the module to which the test case belongs
• Test Case Title: A brief description of the test case
• Precondition: the prerequisite for use case execution
• Test Steps: Execute Use Case Steps
• Expected result: the result you should get
• Priority: Use case importance

4 Functional test case design method

4.1 Equivalence class division method

Definition of equivalence class division method

• Enter a representative subset of data

equivalence class classification

• Valid equivalence classes: those that satisfy the requirements
• Invalid equivalence class: does not satisfy requirements

scope of application

• function with a single input

step

• clear needs
• Determine valid and invalid equivalence classes
• Write test cases

example

Requirements: If the order is delivered quickly, the courier needs to be allowed to modify it, and the limited number of packages must be 1, and the weight must be <0.5kg.

4.2 Boundary Value Analysis

Definition of boundary value

• For some specific cases of input equivalence class and output equivalence class slightly above or slightly below its boundary

Boundary value range

• exactly equal to
• just bigger than
• just less than

Three Points in Boundary Value Analysis

• Upper point: point on the boundary
• From point: the point closest to the boundary
• Inliers: points within range

Example: 1-100, upper point: 1 100 from point: 0 99 2 101 inner point: 50

scope of application

• When there are input parameters, and the input type or range length has a boundary (applicable to the case where there is a length or range in the title requirement)
• Used with equivalence classes, for the case of inputs to a single function

step

1. clear needs
2. Determine valid and invalid equivalence classes
3. Clarify the boundary value in the topic condition
4. Write test cases

example

4.3 Decision table method

Applicable conditions

• The decision table shows that there are multiple inputs and multiple outputs, and the combination relationship between the input and the input, and the mutual constraints and dependencies between the input and the output

component

• Condition pile: all test inputs in the question condition
• Action pile: all outputs in the topic condition
• Condition item: the value of the test input
• Action item: the value of the test output

step

1. Clarify condition pile
2. Clear Action Pile
3. Full combination of conditional piles
4. Clarify the action pile corresponding to each combination
5. design test cases

example

4.4 Causal Diagram Method

Cause and Effect Diagram Definition

• In theory, it is an intermediate process leading to the decision table

scope of application

• The cause-and-effect diagram is a method for designing test cases by analyzing various combinations of inputs using a graphical method, which is suitable for checking various combinations of program input conditions

The core of causal diagrams

• The so-called cause is the input, and the so-called effect is the output.
• The cause-input condition of the causal diagram
• Result-input outcome of causal diagram

Cause and Effect Diagram Basic Notation

relation

• Identity: If Ci is 1, then ei is also 1; otherwise ei is 0
• Not: if ci is 1, then ei is 0; otherwise ei is 1
• Or: if c1 or c2 or c3 is 1, then ei is 1; otherwise ei is 0
• And: if c1 and c2 are both 1, then ei is 1; otherwise ei is 0

step

• Identify inputs and outputs
• draw a causal diagram
• Convert a Cause-Effect Diagram to a Decision Table
• Generate test cases

example

Requirement: A certain software specification contains such a requirement: the characters in the first column must be A or B, and the characters in the second column must be a number. In this case, modify the file, but if the characters in the first column are incorrect, give Output information L; if the characters in the second column are not numbers, then output information M.

convert to decision table

Finally turned into test cases.

4.5 Orthogonal analysis method

definition

• Orthogonal method is also called orthogonal test method, also known as orthogonal arrangement method, which uses the smallest test process set to obtain the largest test coverage rate (the number of test cases is written less, and the number of bugs detected is more), Orthogonal experimental design method is a scientific experimental design method that selects appropriate and representative points from a large number of experimental points, and uses the “orthogonal table” derived from Galois theory to arrange experiments reasonably.

The concept of orthogonal table: a special table, the general orthogonal table is marked as Ln (mk)

• n represents the number of rows, that is, the number of combinations that need to be tested
• The number of columns represented by k indicates the number of controls (the number of factors, or the number of factors)
• m is the number of values ​​contained in each control (the number of levels of each factor, that is, the number of states of each factor)

Such as: L9( 34 )
There are 4 controls
Each control has 3 values
9 is the number of combinations to be tested, and there are 9 test cases
Called 4 Factors 3 Levels

step

1. Form the factor state table according to the requirements – factor: control name state: the value corresponding to each control
2. Determine the orthogonal table used
3. Replace the numbers in the orthogonal table with words
4. A line is a test case

example

Notice

If the number of states of each factor is not uniform, and it is almost impossible to have a uniform situation, choose the orthogonal table to be equal to or slightly greater than the number of factors, the number of states, and the number of trials is the least

Some Methods of Creating Orthogonal Test Table
Online generation: https://jaccz.github.io/pairwise/tools.html

Enter the value of each control and control

generated table

A table of examples of orthogonal experiments can be applied to use cases http://www.york.ac.uk/depts/maths/tables/orthogonal.htm
The example table of the orthogonal test can be applied to the use case http://support.sas.com/techsup/technote/ts723_Designs.txt

4.6 Scenario Method-Flowchart Method

definition

• Simulate the scene of user operation, mainly used to test the combined use of multiple functions

Why User Scenarios

• User perspective: users usually use not a single function, but a combination of multiple functions
• From the perspective of testers: Usually, a single function point is tested. In order to ensure the comprehensiveness of the test, the scenario of combined testing between multiple functions is considered

The scope of application of the scene method

• Combined testing between multiple functions
• Often used in smoke testing

Two important concepts in the scene method

• Elementary flow: a path to follow the correct business process
• Alternate Flow: Operational Flow Where Errors Occur

step

1. Identify project roles
2. Clarify the common functions of roles
3. Build test scenarios according to requirements
4. A scene is a case

5 Security Test Design

Security testing is the process of verifying whether the product meets the definition of security requirements and product quality standards when the software product development is basically completed. Security testing is to check the ability of the system to prevent illegal intrusion and penetration.

The test points included are as follows:

• sql injection
• clear text transmission
• unauthorized access
• SMS email verification
• lack of authentication
• password security
• Data robustness, etc.