Software Testing

Methods

White-box testing

Test case design based on the inner structure of the software program

Static analysis

  • Test without exectuing the program
  • NULL pointers

Dynamic analysis

  • Test code while it is running
  • Statement coverage
  • Branch coverage
  • Clause coverage
  • Combinatorial coverage

https://www.cnblogs.com/dulijuan/p/4471405.html

Statement coverage

Designing test cases that enable the execution of each statement at least once

Branch coverage

Designing test cases that enable the execution of each branch of each decision at least once

流程图 不需要四种 只要第一个每个decision就可以了

Clause coverage

Designing test cases that enable each clause to evaluate to each possible value

第二个改x

Combinatorial coverage

Designing test cases that enable the coverage of each possible combination of the clauses of each decision.

Active clause coverage

Same as MCDC(Modified Condition/Decision Coverage)

For each $p \in P$ and each major clause $c_i \in C_p$ choose minor clauses $c_j$ (j≠i) so that $c_i$ determines p, design test cases to cover each possible value of $c_i$.

General/Correlated/Restricted

Path coverage

Designing test cases that enable the execution of each path at least once

Graph coverage

Representing program structure with graph and using different graph coverage criteria to design test cases.

Node coverage
Edge coverage

Blackbox-Testing

Test case design based on the specification of the software product.

Input space partitioning

  • The input domain is defined in terms of the possible values the inut variables can have
  • The input domain is partitioned into regions that assumed to contain equally useful values from a testing perspective, and values are selected from each region

ascending

descending

arbitary

=> not a valid partitioning

  1. Identifictaion of testable functions
  2. Identification of all the parameters affecting the behavior of the function
  3. Modeling the input domain articulated in the prior step

  • IDM(Input Domain Modeling) approach

    • Interface-based IDM

      Developing characteristics directly from input parameters to the program

      • Easy to identify characteristics
      • Easy to translate abstract tests ino executable test cases
      • Not all the available information will be reflected in the interface domain model
      • Missing some important combinations of parameters since each parameter is analyzed in isolation

    • Functionality-based IDM

      Developing characteristics from a functional or behavioral view of the program

      • Likely to yield better test cases since it includes more semantic information
      • Requirements are available before the software is implemented and IDM can start early in the development
      • If the system is large and complex, or the specifications are informal and incomplete, it can be hard to design reasonable characteristics
      • Harder to generate executable test cases

Boundary value analysis