TEST CASE DESIGN PART SIX

Comparison Testing

1. In some applications the reliability is critical.
2. Redundant hardware and software may be used.
3. For redundant software, use separate teams to develop independent versions of the software.
4. Test each version with same test data to ensure all provisional identical output.
5. Run all versions in parallel with a real-time comparison of results.
6. Even if will only run one version in final system, for some critical applications can develop independent versions and use comparison testing or back-to-back testing.
7. When outputs of versions differ, each is investigated to determine if there is a defect.
8. Method does not catch errors in the specification.

Static Program Analysis

This strategy helps in identifying errors without executing the program. Peer reviewers and programmers will use this strategy to uncover probable static errors.

Mathematical Program Verification

If the programming language semantics are formally defined, one can consider program to be a set of mathematical statements. We can attempt to develop a mathematical proof that the program is correct with respect to the specification. If the proof can be established, the program is verified and testing to check verification is not required.

There are a number of approaches to proving program correctness. We will only consider axiomatic approach.

Suppose that at points P(1), .. , P(n) assertions concerning the program variables and their relationships can be made.

The assertions are a(1), ..., a(n).

The assertion a(1) is about inputs to the program, and a(n) about outputs.

We can now attempt, for k between 1 and (n-1), to prove that the statements between

P(k) and P(k+1) transform the assertion a(k) to a(k+1).

Given that a(1) and a(n) are true, this sequence of proofs shows partial program correctness. If it can be shown that the program will terminate, the proof is complete.

Static Program Analyzers

1. Static analysis tools scan the source code to try to detect errors.
2. The code does not need to be executed.
3. Most useful for languages which do not have strong typing.

It can check:

1. Syntax.

2. Unreachable code

3. Unconditional branches into loops

4. Undeclared variables

5. Uninitialised variables.

6. Parameter type mismatches

7. Uncalled functions and procedures.

8. Variables used before initialization.

9. Non-usage of function results.

1. Possible array bound errors.

Misuse of pointers.

RELATED POST


INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

QUALITY TESTING

QUALITY ASSURANCE

QUALITY ASSURANCE PART TWO

QUALITY ASSURANCE SQA

QUALITY OF DESIGN OF TEST CASE

QUALITY MANAGEMENT IN SOFTWARE TESTING

TOOLS FOR QUALITY MANAGEMENT

STATICAL QUALITY ASSURANCE

ISO APPROACH TO QUALITY TESTING