【Software Testing】Summary of test case design points

---

Exam question types

• Short answer questions (4 questions in total, 5 points each, 20 points in total)
• Equivalence class division (16 points)
• Boundary value analysis (13 points)
• Decision table driven (22 points)
• Logical coverage (12 points)
• Basic Path Test (17 points)
• Precautions:
  • Check the online test as soon as possible for misjudgments
  • Check experimental results and deductions
  • Pay attention to the order of answering questions (it is recommended to follow the order of difficulty + score)
  • Pencil drawings (cause and effect diagrams and program control flow diagrams) are not allowed
  • Each input condition in the test case must have a specific value
  • The numbered part in the header only gives the number. Except for the conditional coverage of the logical coverage method, there is at most one invalid situation in other tests (null is also done)

short answer questions

[The difference and connection between interoperability (interaction) and coexistence (influence)] Software quality analysis

• Interoperability: the ability to interact with one or more specified systems; coexistence: the ability to coexist with other independent software in a common environment

• Common points:

  • Both focus on how a system or component interacts with other systems or components.
  • All require targeted testing.
  • All are closely related to system or component compatibility.

• the difference:

  • Interoperability focuses on the exchange and utilization of information between different systems or components, emphasizing whether software can successfully cooperate with other systems in different environments.
  • Coexistence focuses on whether the system can coexist and operate normally with other systems. It mainly depends on whether the newly introduced software will affect the normal operation of the existing system, or whether the existing system will affect the normal operation of the newly introduced software.

• Software quality models: McCall model (1979), ISO/IEC 9126-1991 model, new ISO/IEC 9126 model, ISO/IEC 25010-2011 model
  

[Manual testing and automated testing] Classification of software testing

• Classification of software testing
  • Test execution method: static test, dynamic test
  • Test objects: black box testing, white box testing
  • Testing process: unit testing, integration testing, system testing, acceptance testing
  • Test purpose: functional test, robustness test, performance test, security test, compatibility test, usability test
  • Test execution means: manual testing, automated testing
    
• Manual Testing vs. Automated Testing
  • Manual testing:
    • Advantages: ①The cost of performing tests is low; ②Manual comparison is more intelligent
    • Disadvantages: ① low execution efficiency, accuracy cannot be guaranteed; ② not reusable
  • automated test:
    • Advantages: ① Fast and reliable test execution; ② Support repeated testing and programmable; ③ Support test types that are incompetent manually, such as performance testing, security testing, etc.
    • Disadvantages: ① The cost of commercial software is generally high and not suitable for small and medium-sized enterprises; ② The accuracy is based on the instructions of the test script, which is not flexible and intelligent enough.
      

[General principles for determining intermediate results using cause-and-effect diagram analysis] Key points in the design of cause-and-effect analysis method

• In order to simplify the problem, the cause only describes the valid equivalence class of the input condition; the cause and the result are described in the form of logical values ​​as much as possible
• In order to ensure the adequacy of testing, compound input conditions need to be split into simple conditions
• Analysis ideas: start with the results and analyze the relationship between the results and the causes.
• Results analysis sequence:
  • If there is no progressive relationship between the results, the analysis will generally start with the simplest one.
  • If there is a progressive relationship between the results, they must be analyzed in order
• Determination of intermediate results:
  • The input conditions that were originally split need to be combined with intermediate results to describe their logical relationships.
  • There are close dependencies between multiple input conditions, consider adding intermediate results
  • There is a relationship between a result and multiple causes. It is not a pure AND/OR relationship. Intermediate results need to be added.
  • A certain output takes a certain input as a prerequisite. In order for subsequent analysis to proceed smoothly, intermediate results must be added.
• Determination of constraints between causes:
  • It is necessary to consider the restrictions on user input from the perspective of the end user.
  • Focus on mutual exclusion, containment and unique relationships
    

[Logical coverage method and basic path test method]

• Logical coverage method
  • Advantages: ① Based on the truth table, saving testing work hours; ② Six coverage criteria, applicable to different application scenarios
  • Disadvantages: ① The six coverage criteria are relatively similar and easy to confuse; ② Unable to take into account both efficiency and effectiveness; ③ No real simplification of complex situations such as loops is achieved
• basic path testing method
  • Advantages: ① The test data is based on a single defect hypothesis, which improves testing effectiveness; ② Complex situations such as loops are simplified to a complexity similar to nested branch structures, which improves testing efficiency
  • Disadvantages: ① Design test cases based on program control flow chart and independent path analysis, the design process is relatively complicated
    

[Tasks and adoption methods of unit testing] Objectives and methods of unit testing

• Goal: Unit modules are correctly coded
• Task:
  • Module interface: Check whether the module unit data input and output are correct
  • Local data structure: Check the integrity and correctness of the internal data within the module [code inspection method, static structure analysis method]
  • Error handling: An error occurs in the module, whether the system's error handling is effective [error speculation method]
  • Boundary conditions: Use boundary value analysis method to find errors that occur at the boundary [boundary analysis method]
  • Independent execution path: Test independent paths to find calculation, decision and control flow errors [basic path detection method, logic coverage method]

---

(1) Equivalence class division

1.1 Divide equivalence classes

• Equivalence class design allows moderate redundancy;
• The input conditions contain compound conditions that need to be split;
• Valid equivalence classes used to verify the functional correctness of the system are allowed to be merged;
• Pay attention to implicit conditions when analyzing equivalence classes;
• Valid equivalence classes and invalid equivalence classes need to be numbered sequentially respectively;
• When the output domain is not massive data, there is no need to analyze equivalence classes;
• When there is a dependency between input conditions, it only needs to be reflected in the test case design process, and it is analyzed as an independent condition during the design of equivalence classes.

Principles for dividing equivalence classes

• Divided by interval: 1 valid equivalence class, 2 invalid equivalence classes [single value (can be added or subtracted), date]
• Divided by value: 1 valid equivalence class, n invalid equivalence classes [process each value separately]
• Divided by input set: 1 valid equivalence class, 1 invalid [not processing each value separately (set)]
• Divided by restrictions: 1 valid equivalence class, 1 invalid equivalence class [Logical value: Requirements must be filled in (fill/not filled in)]
• Divided by restriction rules: 1 valid equivalence class, several invalid equivalence classes (minimum restriction) [≈Divided by restrictions]

• Valid equivalence class: copy the question requirements
• Invalid equivalence class requirement:
  • split to the end
  • Allow moderate redundancy (no earlier than current leave date => earlier than current leave date + equal to current leave date)

1.2 Design test cases

• The expected output must be completely consistent with the requirements of the question rules;
• A test case can only cover at most one invalid equivalence class;
• For test cases that verify robustness, covering the equivalence class number only requires highlighting the invalid equivalence class;
• Test case design needs to take into account both input and output equivalence class coverage.

• Valid equivalence classes: Cover as many valid equivalence classes as possible that are not yet covered (as few test cases as possible to cover => 1)
• Invalid Equivalence Class: Overriding only one invalid equivalence class

---

(2) Boundary value analysis

2.1 List the boundary value analysis table

• Only boundary values ​​need to be analyzed for equivalence classes related to values , intervals , ranges , and times ;
• The seven-point method represents an idea of ​​value selection. It does not require hard-earned seven data, but requires detailed analysis of specific issues;
• If it is an unbounded interval [a,+∞], then choose a large enough number to replace infinity on the right boundary; you need to choose a fixed value as the normal value of the test case.

Seven-point method:
Processing of boundary values ​​slightly below the minimum value, minimum value, slightly above the minimum value, normal value, slightly below the maximum value, maximum value, and slightly above the maximum value (dependency): Eg: end date = >Start date, conditional on the normal value of the start date (minimum boundary value)
normal value underlined

2.2 Design test cases

• The data of all test cases should be taken from the boundary value analysis table;
• A test case can only cover at most one boundary value, and the rest are normal values;
• Equivalence classes that have nothing to do with numerical values ​​can be arbitrarily selected as legal and valid inputs during the test case design process.

---

(3) Cause and effect diagram analysis

3.1 Determine causes and effects

• Reason: Valid equivalence class of input conditions (general rules) [Copying requirements (valid equivalence classes divided by equivalence classes)]
• Result: expected output
• Precautions:
  • Causes and effects are given as logical values;
  • It is recommended to describe the reason in the form of a valid equivalence class;
  • In order to ensure the adequacy of testing, compound conditions need to be split into simple conditions (relational expressions);
    • with, or whether to split
    • Test under opposite conditions
    • Flowchart verification of basic path testing method: cause + result (white box testing)
  • The numbers and descriptions of causes and results need to be standardized and accurate.

3.2 Determine the logical relationship between causes and effects

• Do not use pencil to draw cause and effect diagrams;
• The general way to analyze problems is: start with the results and analyze the relationship between the results and the causes;
• If there is a progressive relationship or a nested relationship between the results, they must be analyzed in the order of input;
• Determination of intermediate results: There is a closer relationship between multiple input conditions;
• A certain output takes a certain input as a precondition (pay attention to the description in the requirements). For the smooth progress of subsequent analysis, intermediate results must be added.

3.3 Use standard symbols to indicate constraints on cause-and-effect diagrams

• Determination of constraints between causes: It is necessary to consider the restrictions on user input from the perspective of the end user.
• E (mutually exclusive) , I (included), O (unique) , R (required), M (shielded)
  

---

(4) Determination table driver

4.1 Transforming a causal diagram into a decision table

• For unreasonable rules, determine whether to list them according to the requirements of the question;
• Intermediate results do not need to be listed, condition piles and action piles only need to list the number of the cause and result ;
• In order to reduce the number of rules and test cases, they should be merged and simplified as much as possible;
• To avoid repeated merging and missing merging, it is recommended to merge in the order of input conditions.
• The decision table driven method considers permutation and combination problems.
• Merge simplification notes:
  • For situations where there are too many input conditions, you can consider merging and simplification from the beginning;
  • The prerequisite for merging and simplification is that the action items are the same;
  • Must pass "-" to indicate that the condition is irrelevant or the condition is not applicable.

• List all condition piles and action piles
• Determine the total number of rules
• Fill in conditional items and action items
• Merge and simplify similar rules

• AND relationship: operate in sequence
• Or relation: mutually exclusive relation, Cartesian product (test case)

4.2 Design test cases

• Each input condition in the test case must have a specific value, and cannot be expressed by "-" or "value independent";
• If the test case is empty, no information will be filled in, and it cannot be expressed by "empty" or "NULL".

---

(5) Logic coverage

• Basic design ideas:
  • Carry out test design tasks according to the basic idea of ​​"classification design**, strict concept**"; (different coverage concepts)
    • Decision coverage : first give statement coverage, and fill in the missing ones (general situation: decision coverage = statement coverage)
    • Condition coverage : as few test cases as possible (as many as possible true and false)
    • Judgment condition coverage :
  • Make reasonable use of the truth table , first determine the value of the judgment or condition, and then select the test data;
  • First design test cases with low coverage, and then check for deficiencies against the requirements for high coverage;
  • Avoid redundancies or omissions.
    
• Precautions:
  • A "-" must be passed in the truth table to indicate that the condition does not apply;
  • In logical coverage analysis, only the nested relationship between judgments is considered, and the logical relationship between conditions is not considered;
  • For input conditions that cannot be verified in the truth table, specific and valid data must be given in the test case;
  • To cover the path, just give the number.

---

(6) Basic path test

6.1 Draw program control flow chart

• Determination nodes under compound conditions must be split into simple conditions (relational expressions);
• Appropriately merge processing nodes;
• Add meeting points appropriately (end of branch structure, program exit, etc.) according to the situation.
• After drawing, confirm the following:
  • It is necessary to ensure that the out-degree of each conditional node is equal to 2;
  • The drawing of the graph guarantees a single entry and a single exit;
  • Avoid cross lines that prevent areas from being accurately identified;
  • The areas need to be marked in the picture, and note that there is 1 open area;
  • The meeting point must be given a number.

6.2 Calculating program cycle complexity

• The three formulas must give the complete calculation process and results.
  • V(G) = number of regions
  • V(G) = E - N + 2
  • V(G) = P + 1
• Since the sequence number of the condition node has been marked in the program flow chart, the formula P+1 can be used to check whether the results of other formulas are consistent and whether the drawing is correct.

6.3 Determine the set of independent paths

• Number of independent paths ≤ cycle complexity: If there is a local chain structure (existence or relationship, and not at the end ◇) in the program control flow graph, then the number of independent paths < cycle complexity;
• Basic path coverage needs to ensure coverage of all nodes and control streamlines (arcs) in the program control flow chart;
• Avoid redundancy or omissions during independent path enumeration;
• Independent paths need to exclude unreasonable situations.
• same entrance, same exit

6.4 Design test cases

• Each input condition in the test case must have a specific value, even if the covered independent path does not verify an input condition;
• Overriding independent paths only needs to give the number.