1. Types of Testing
Visit to more Learning Resources

2. White-box testing: Summary statement coverage path coverage
branch testing
condition coverage
Cyclomatic complexity
Summary

3. Input test data to the system. Observe the output:
How do you test a system?
Input test data to the system.
Observe the output:
Check if the system behaved as expected.

4. How do you test a system?
Input
System
Output

5. If the program does not behave as expected:
How do you test a system?
If the program does not behave as expected:
note the conditions under which it failed.
later debug and correct.

6. A failure is a manifestation of an error (aka defect or bug).
Errors and Failures
A failure is a manifestation of an error (aka defect or bug).
mere presence of an error may not lead to a failure.

7. White-box Testing Designing white-box test cases:
requires knowledge about the internal structure of software.
white-box testing is also called structural testing.

8. Static white box testing
Static white box testing which involves only the source code of the product and not the binaries or executable, static white box testing will be done before the code is executed or completed.
For static white box testing only selected peoples are involved to find out the defects in the code. The main aim of the static testing is to check whether the code is according to the Functional requirements, design, coding standards, all functionalities covered and error handling

9. Desk checking
Desk checking is the primary testing done on the code. Static checking will be done by programmers before compiled or executed, if any error is find it is going to check by author and he will correct the code, in this process the code is compared with requirements specification or design to see that the designed code is according to client adhoc requests

10. Code walkthrough
This testing is also known as technical code walkthrough, in this testing process a group of technical people go through the code.
This is one type of semi-formal review technique. In Code walkthrough process a high level employees involved such as technical leads, database administrators and one or more peers.
The people who involved in this technical code walkthrough they raise questions on code to author, in this process author explains the logic and if there is any mistake in the logic, the code is corrected immediately

11. Formal Inspections
Inspection is a formal, efficient and economical method of finding errors in design and code. It’s a formal review and aimed at detecting all faults, violations and other side effects.
According to M. E. Fagan “A defect is an instance in which a requirement is not satisfied”. Fagan inspection process is a structured process of finding defects in the provided source code.

12. White-Box Testing Statement coverage branch coverage path coverage
There exist several popular white-box testing methodologies:
Statement coverage
branch coverage
path coverage
condition coverage
mutation testing
data flow-based testing

13. Statement coverage methodology:
design test cases so that
every statement in a program is executed at least once.

14. Statement Coverage The principal idea: unless a statement is executed,
we have no way of knowing if an error exists in that statement.

15. Statement coverage criterion
Based on the observation:
an error in a program can not be discovered:
unless the part of the program containing the error is executed.

16. Statement coverage criterion
Observing that a statement behaves properly for one input value:
no guarantee that it will behave correctly for all input values.

17. Example int f1(int x, int y){ 1 while (x != y){ 2 if (x>y) then
x=x-y;
4 else y=y-x;
5 }
6 return x; }

18. Euclid's GCD computation algorithm
By choosing the test set {(x=3,y=3),(x=4,y=3), (x=3,y=4)}
all statements are executed at least once.

19. Branch Coverage Test cases are designed such that:
different branch conditions
given true and false values in turn.

20. Branch Coverage Branch testing guarantees statement coverage:
a stronger testing compared to the statement coverage-based testing.

21. Stronger testing discovers at least as many errors as a weaker testing
Test cases are a superset of a weaker testing:
discovers at least as many errors as a weaker testing
contains at least as many significant test cases as a weaker test.

22. Example int f1(int x,int y){ 1 while (x != y){ 2 if (x>y) then
x=x-y;
4 else y=y-x;
5 }
6 return x; }

23. Example Test cases for branch coverage can be:
{(x=3,y=3),(x=3,y=2), (x=4,y=3), (x=3,y=4)}

24. Condition Coverage Test cases are designed such that:
each component of a composite conditional expression
given both true and false values.

25. Example Consider the conditional expression
((c1.and.c2).or.c3):
Each of c1, c2, and c3 are exercised at least once,
i.e. given true and false values.

26. Branch testing
Branch testing is the simplest condition testing strategy:
compound conditions appearing in different branch statements
are given true and false values.

27. Branch testing Condition testing Branch testing
stronger testing than branch testing:
Branch testing
stronger than statement coverage testing.

28. Consider a boolean expression having n components:
Condition coverage
Consider a boolean expression having n components:
for condition coverage we require 2n test cases.

29. Condition coverage-based testing technique:
practical only if n (the number of component conditions) is small.

30. Path Coverage Design test cases such that:
all linearly independent paths in the program are executed at least once.

31. Path coverage-based testing
To understand the path coverage-based testing:
we need to learn how to draw control flow graph of a program.

32. Path A path through a program:
a node and edge sequence from the starting node to a terminal node of the control flow graph.
There may be several terminal nodes for program.

33. Independent path Any path through the program:
introducing at least one new node:
that is not included in any other independent paths.

34. Independent path
It is straight forward:
to identify linearly independent paths of simple programs.
For complicated programs:
it is not so easy to determine the number of independent paths.

35. McCabe's cyclomatic metric
An upper bound:
for the number of linearly independent paths of a program
Provides a practical way of determining:
the maximum number of linearly independent paths in a program.

36. McCabe's cyclomatic metric
Given a control flow graph G, cyclomatic complexity V(G):
V(G)= E-N+2
N is the number of nodes in G
E is the number of edges in G

37. Example Control Flow Graph1 2 3 4 5 6

38. Example
Cyclomatic complexity = = 3.

39. Cyclomatic complexity
Another way of computing cyclomatic complexity:
inspect control flow graph
determine number of bounded areas in the graph
V(G) = Total number of bounded areas + 1

40. Bounded area
Any region enclosed by a nodes and edge sequence.

41. Example Control Flow Graph1 2 3 4 5 6

42. Example From a visual examination of the CFG:
the number of bounded areas is 2.
cyclomatic complexity = 2+1=3.

43. Cyclomatic complexity
McCabe's metric provides:
a quantitative measure of testing difficulty and the ultimate reliability
Intuitively,
number of bounded areas increases with the number of decision nodes and loops.

44. Cyclomatic complexity
The first method of computing V(G) is amenable to automation:
you can write a program which determines the number of nodes and edges of a graph
applies the formula to find V(G).

45. Cyclomatic complexity
The cyclomatic complexity of a program provides:
a lower bound on the number of test cases to be designed
to guarantee coverage of all linearly independent paths.

46. Cyclomatic complexity
Defines the number of independent paths in a program.
Provides a lower bound:
for the number of test cases for path coverage.

47. Cyclomatic complexity
Knowing the number of test cases required:
does not make it any easier to derive the test cases,
only gives an indication of the minimum number of test cases required.

48. Black Box Testing:
Black box testing plays a significant role in software testing, it aid in overall functionality validation of the system.
Black box testing is done based on customers’ requirements-so any incomplete or unpredictable requirements can be easily identified and it can be addressed later.
Black box testing is done based on end user perspective.
The main importance of black box testing it handles both valid and invalid inputs from customer’s perspective

49. Equivalence Class Partitioning
Equivalence class testing is based upon the assumption that a program’s input and output domains can be partitioned into a finite number of (valid and invalid) classes such that all cases in a single partition exercise the same functionality or exhibit the same behaviour .
The partitioning is done such that the program behaves in a similar way to every input value belonging to an equivalence class. Test cases are designed to test the input or output domain partitions.
Equivalence class is determined by examining and analysing the input data range. Only one test case from each partition is required, which reduces the number of test cases necessary to achieve functional coverage .
The success of this approach depends upon the tester being able to identify partitions of the input and output spaces for which, in reality, cause distinct sequences of program source code to be executed

50. Boundary Value Analysis
Boundary value analysis is performed by creating tests that exercise the edges of the input and output classes identified in the specification. Test cases can be derived from the ‘boundaries’ of equivalence classes.
Typically programming errors occur at the boundaries of equivalence classes are known as “Boundary Value Analysis”. Generally some time programmers fail to check special processing required especially at boundaries of equivalence classes.
A general example is programmers may improperly use < instead of <=. The choices of boundary values include above, below and on the boundary of the class

51. Decision Tables
Decision tables are human readable rules used to express the test experts or design experts knowledge in a compact form.
Decision Tables can be used when the outcome or the logic involved in the program is based on a set of decisions and rules which need to be followed.
Decision table mainly consists of four areas called the condition stub, the condition entry, the action stub and finally action entry
For more Details Contact Us