1. Functional Testing & Structural Testing UNIT 2

2. Learning Objectives Software Testing: Types of Tesing
functional testing
Boundary value analysis
Equivalence class testing
Decision table testing
Cause effect graphing
Structural testing
Path Testing
Data flow Testing
Slice Based Testing
Mutation Testing

3. Background

4. Classification of Test
There are two levels of classification
One distinguishes at granularity level
Unit level
System level
Integration level
Other classification is based on methodologies
Black box (Functional) Testing
Inspects specified behavior
White box (Structural) Testing
Inspects programmed behavior

5. Test Methodologies Functional (Black box) inspects specified behavior
Structural (White box) inspects programmed behavior

6. Validation Techniques
Functional Testing

7. Functional Testing
Testing is based on the functionality of the program
Internal structure of the code is ignored ( black box testing)
Input
test data
Output
System

8. Functional (Black Box) Testing
Checks the overall functionality of the system under test.
Knowledge of system internals is not required
But it may help in designing specific to error prone areas
It helps in saving cost and effort if test cases are designed in a well planned way to:
Avoid redundancy
Provide better coverage

9. Metrics Analysis Can be used to plot Total number of test cases
% passed
% failed
Number of defects (overall and priority based)
Number of requirements: completed successfully and pending

10. Techniques / Approaches
Boundary Value Analysis
Equivalence Partitioning
Decision table based testing
Cause Effect Graph Technique
State Based Testing

11. Boundary Value Analysis
Test cases explore boundary condition have higher chances of detecting error
Directly on, just above and just below the boundaries of input

12. Simple Example (to be generalized)c d x2 1 x

13. Boundary Value Analysis cont..
Consider function F with input variables x& y
a<= x<= b
c<=y<=d
x & y bounded by two intervals [a,b] & [c,d]
Basic idea is to use input variables
Minimum
Just above min
Just below max
max d x1 a c x2 b

14. Boundary Value Analysis cont..
Test cases
<Xnom, Ymin>, <10,25>
<Xnom, Ymin+>, <10,26>
<Xnom, Ynom>, <10,30>
<Xnom, Ymax>, <10,35>
<Xnom, Ymax->, <10,34>
<Xmin, Ynom>, <5,30>
<Xmin+, Ynom>, <6,30>
<Xmax, Ynom>, <15,30>
<Xmax+, Ynom> <14,30>
Inputs
5<=x<=15
25<=y<=35

15. Worst Case Analysis Example
<10,25>
<10,26>
<10,30>
<10,35>
<10,34>
<15,25>
<15,26>
<15,30>
<15,35>
<15,34>
<14,25>
<14,26>
<14,30>
<14,35>
<14,34>
<5,25>
<5,26>
<5,30>
<5,35>
<5,34>
<6,25>
<6,26>
<6,30>
<6,35>
<6,34>
Inputs
5<=x<=15
25<=y<=35

16. Limitations Variables to be truly independent
Doesn’t make sense for Boolean variables

17. Equivalence Class Testing
Equivalence partitioning (EP) is a specification-based or black-box technique.
It can be applied at any level of testing and is often a good technique to use first.
The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently), hence ‘equivalence partitioning’. Equivalence partitions are also known as equivalence classes – the two terms mean exactly the same thing.

18. In equivalence-partitioning technique we need to test only one condition from each partition. This is because we are assuming that all the conditions in one partition will be treated in the same way by the software. If one condition in a partition works, we assume all of the conditions in that partition will work, and so there is little point in testing any of these others. Similarly, if one of the conditions in a partition does not work, then we assume that none of the conditions in that partition will work so again there is little point in testing any more in that partition.

19. For example, a savings account in a bank has a different rate of interest depending on the balance in the account. In order to test the software that calculates the interest due, we can identify the ranges of balance values that earn the different rates of interest. For example, 3% rate of interest is given if the balance in the account is in the range of $0 to $100, 5% rate of interest is given if the balance in the account is in the range of $100 to $1000, and 7% rate of interest is given if the balance in the account is $1000 and above, we would initially identify three valid equivalence partitions and one invalid partition as shown below.

21. In the above example we have identified four partitions, even though the specification mentioned only three. This shows a very important task of the tester that is a tester should not only test what is in the specification, but should also think about things that haven’t been specified. In this case we have thought of the situation where the balance is less than zero.

22. We haven’t (yet) identified an invalid partition on the right, but this would also be a good thing to consider. In order to identify where the 7% partition ends, we would need to know what the maximum balance is for this account (which may not be easy to find out). In our example we have left this open for the time being. Note that non-numeric input is also an invalid partition (e.g. the letter ‘a’) but we discuss only the numeric partitions for now.

23. We have made an assumption here about what the smallest difference is between two values. We have assumed two decimal places, i.e. $100.00, but we could have assumed zero decimal places (i.e. $100) or more than two decimal places (e.g. $ ) In any case it is a good idea to state your assumptions – then other people can see them and let you know if they are correct or not.

24. When designing the test cases for this software we would ensure that all the three valid equivalence partitions are covered once, and we would also test the invalid partition at least once. So for example, we might choose to calculate the interest on balances of-$10.00, $50.00, $ and $ If we hadn’t specifically identified these partitions, it is possible that at least one of them could have been missed at the expense of testing another one several times over.

25. Note that we could also apply equivalence partitioning to outputs as well. In this case we have three interest rates: 3%, 5% and 7%, plus the error message for the invalid partition (or partitions). In this example, the output partitions line up exactly with the input partitions. How would someone test this without thinking about the partitions?

26. Decision table testing is a testing technique used to test system behavior for different input combinations. This is a systematic approach where the different input combinations and their corresponding system behavior (Output) are captured in a tabular form. That is why it is also called as a Cause-Effect table where Cause and effects are captured for better test coverage.
A Decision Table is a tabular representation of inputs versus rules/cases/test conditions. Let's learn with an example.

27. Example 1: Decision Base Table for Login Screen
Let's create a decision table for a login screen.

29. While converting this to test case, we can create 2 scenarios ,
Enter correct username and correct password and click on login, and the expected result will be the user should be navigated to homepage

30. And one from the below scenario
Enter wrong username and wrong password and click on login, and the expected result will be the user should get an error message
Enter correct username and wrong password and click on login, and the expected result will be the user should get an error message
Enter wrong username and correct password and click on login, and the expected result will be the user should get an error message
As they essentially test the same rule.

31. Cause-Effect Graph graphically shows the connection between a given outcome and all issues that manipulate the outcome. Cause Effect Graph is a black box testing technique. It is also known as Ishikawa diagram because of the way it looks, invented by Kaoru Ishikawa or fish bone diagram.
It is generally uses for hardware testing but now adapted to software testing, usually tests external behavior of a system. It is a testing technique that aids in choosing test cases that logically relate Causes (inputs) to Effects (outputs) to produce test cases.

32. A “Cause” stands for a separate input condition that fetches about an internal change in the system. An “Effect” represents an output condition, a system transformation or a state resulting from a combination of causes.

33. The Cause-Effect Diagram can be used under these Circumstances:
To determine the current problem so that right decision can be taken very fast.
To narrate the connections of the system with the factors affecting a particular process or effect.
To recognize the probable root causes, the cause for a exact effect, problem, or outcome.

34. Benefits of making cause-Effect Diagram
It finds out the areas where data is collected for additional study.
It motivates team contribution and uses the team data of the process.
Uses synchronize and easy to read format to diagram cause-and- effect relationships.
Point out probable reasons of difference in a process.
It enhances facts of the procedure by helping everyone to learn more about the factors at work and how they relate.
It assists us to decide the root reasons of a problem or quality using a structured approach.

35. Steps to proceed on Cause-Effect Diagram:
Firstly: Recognize and describe the input conditions (causes) and actions (effect)
Secondly: Build up a cause-effect graph
Third: Convert cause-effect graph into a decision table
Fourth: Convert decision table rules to test cases. Each column of the decision table represents a test case

36. Symbols used in Cause-effect graphs:

37. Just assume that each node having the value 0 or 1 where 0 shows the ‘absent state’ and 1 shows the ‘present state’. The identity function states when c1 = 1, e1 = 1 or we can say if c0 = 0 and e0 = 0.
The NOT function states that, if C1 = 1, e1= 0 and vice-versa. Likewise, OR function states that, if C1 or C2 or C3 = 1, e1 = 1 else e1 = 0. The AND function states that, if both C1 and C2 = 1, e1 = 1, else e1 = 0. The AND and OR functions are permitted to have any number of inputs.

38. Cause-Effect Testing Steps
Six steps
Divide specification into ``workable “ pieces
Identify causes and effects
Create Boolean graph that links causes to effects
Annotate graph with constraints
Create a limited-entry decision table from the graph
Convert the columns in the decision table into testcases

39. Structural Testing White box Testing
Possess complete knowledge about the internal structure of the source code

40. Control-Flow Graph Control-Flow Graph
A control flow graph (or flow graph) G is defined as a finite set N of nodes and a finite set E of edges. An edge (i, j) in E connects two nodes ni and nj in N. We often write G= (N,E)to denote a flowgraph G with nodes given by N and edges by E.

43. Path
A complete path is a path from start to end. A subpath is a subsequence of a complete path.
Feasible Paths
A path p through a flow graph for program P is considered feasible if there exists at least one test case which when input to P produces path p.

44. Example:

45. DD-Paths
Decision to Decision path (D-D) - The CFG can be broken into various Decision to Decision paths and then collapsed into individual nodes

46. A decision-to-decision path, or DD-path, is a path of execution (usually through a flow graph representing a program, such as a flow chart) between two decisions. More recent versions of the concept also include the decisions themselves in their own DD-paths.

47. Properties From the definition we can conclude the following:
Every node on a flow graph of a program belongs to one DD-path.
If the first node on a DD-path is traversed, then all other nodes on that path will also be traversed.
The DD path graph is used to find independent path for testing.
Every statement in the program has been executed at least once.

48. When we have a flow graph, we can easily draw another graph that is known as decision-to-decision or (DD) path graph, wherein we lay our main focus on the decision nodes only. The nodes of the flow graph are combined into a single node it they are in sequence.

49. Graph Matrix A graph matrix is a tabular representation of flow graph
Can be used to find cyclomatic complexity
Each row having more than one entry shows the predicate node
Empty column shows the beginning node
Empty row tells the end node

52. A simplest weight we can use is to note that there is or isn’t a connection. Let “1” mean that there is a connection and “0” mean that there isn’t.
The arithmetic rules are:
1+1=1 1*1=1
1+0=1 1*0=0
0+0=0 0*0=0
A matrix defined like this is called connection matrix.

55. Control Flow Testing Inputs to the test generation process
Source code
Path selection criteria: statement, branch, …
Generation of control flow graph (CFG)
A CFG is a graphical representation of a program unit.
Compilers are modified to produce CFGs. (You can draw one by hand.)
Selection of paths
Enough entry/exit paths are selected to satisfy path selection criteria.

56. Generation of test input data
Two kinds of paths
Executable path: There exists input so that the path is executed.
Infeasible path: There is no input to execute the path.
Solve the path conditions to produce test input for each path.

57. Outline of Control Flow Testing

58. Control Flow Testing: Works

59. Data Flow Testing

64. Slice Based Testing (SBT)
Originally proposed by Weiser (1985) used by Gallagher (1991) in software maintenance and Bieman (1994) in Quantification of functional cohesion
Useful for
Software Debugging
Software Maintenance
Program understanding
Quantification of functional cohesion
Basic idea: Divide the program into slices (meaningful components) that contribute to value of a variable

65. Informal Definition of SBT
Slice-based Testing technique
divides a program into components (or slices)
A program slice?
Refers to a set of program statements that may affect the computation of variable v at statement s

66. Formal Definition Given a program P and a set of variables V in P,
a slice on the variable set V at statement n,
written as S(V, n)
is the set of all statements in P prior to n that contribute to the values of variables in V at statement n.

67. Testing slices
It focuses on a portion of a program with respect to a variable location in any statement of the program.
Slicing cannot test a behaviour which is not represented by a set of variables or a variable of the program

68. Example
1a=3; 2.b=6; 3.c=b2; 4.d=a2+b2; 5.c=a+b; S(c,5) ? S(c,3)?

69. Example S(c,5) 1. a=3; 1.a=3; 2. b=6; 2.b=6; 3. c=b2; 5.c=a+b;
4. d=a2+b2;
5. c=a+b;

70. Mutation Testing
Mutation testing injects faults into code to determine optimal test inputs. 
Similar to fault seeding
Determine properties of test cases
For example, a constant might be incremented by one, decremented by one, or replaced by zero, yielding one of three mutants.

71. Mutation Testing cont..
Multiple copies of the program are made, and each copy is altered
Alter copy is called a mutant
Mutant detected by a test case is termed “killed”
Objective is to find a set of test cases that are able to kill the group of mutants

72. Mutation Testing A mutated program:
tested against the full test suite of the program.
If there exists at least one test case in the test suite for which:
a mutant gives an incorrect result, then the mutant is said to be dead.

73. Mutation Testing If a mutant remains alive:
even after all test cases have been exhausted, the test suite is enhanced to kill the mutant.
The process of generation and killing of mutants:
can be automated by predefining a set of primitive changes that can be applied to the program.

74. Mutation Testing The primitive changes can be:
altering an arithmetic operator,
changing the value of a constant,
changing a data type, etc.

75. Mutation Testing A major disadvantage of mutation testing:
computationally very expensive,
a large number of possible mutants can be generated.

76. References
1. K. K. Aggarwal & Yogesh Singh, “Software Engineering”, 2nd Ed., New Age International, 2005.
2. R. S. Pressman, “Software Engineering – A practitioner’s approach”, 5th Ed., McGraw Hill Int. Ed., 2001.
3. Pankaj Jalote, “An Integrated Approach to Software Engineering”, Narosa, 3rd Ed., 2005.
4. Stephen R. Schach, “Classical & Object Oriented Software Engineering”, IRWIN,
5. James Peter, W. Pedrycz, “Software Engineering: An Engineering Approach”, John Wiley & Sons.
6. Sommerville, “Software Engineering”, Addison Wesley,8th Ed.,
7. Frank Tsui and Orlando Karan, “Essentials of Software Engineering”, Joes and Bartlett, 2nd Ed., 2010.
8. Kassem A. Saleh, “Software Engineering”, Cengage Learning, 2009.
9. Rajib Mall, “Fundamrntal of Software Engineering”, PHI, 3rd Ed., 2009.
10. Carlo Ghizzi , Mehdi Jazayeri and Dino Mandrioli, “ Fundamental of Software Engineering”, PHI, 2nd Ed.,2003.