- In some applications the reliability is critical.
- Redundant hardware and software may be used.
- For redundant software, use separate teams to develop independent versions of the software.
- Test each version with same test data to ensure all provisional identical output.
- Run all versions in parallel with a real-time comparison of results.
- 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.
- When outputs of versions differ, each is investigated to determine if there is a defect.
- Method does not catch errors in the specification.
This strategy helps in identifying errors without executing the program. Peer reviewers and programmers will use this strategy to uncover probable static errors.
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 analysis tools scan the source code to try to detect errors.
- The code does not need to be executed.
- Most useful for languages which do not have strong typing.
Unconditional branches into loops
Parameter type mismatches
Uncalled functions and procedures.
Variables used before initialization.
Non-usage of function results.
Possible array bound errors.
Misuse of pointers.
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 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