1. Chapter : 18 Testing Conventional Applications

2. Software Testing Fundamentals
Testability
Software testability is simply how easily a computer program can be tested.
The following characteristics lead to testable software:
Operability : The better it works, the more efficient it can be tested.
Observability : What you see is what you test
Controllability : The better we can control the software, the more the testing can be automated and optimized.

3. 4) Decomposability : By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.
5)Simplicity : The less there is to test, the more quickly we can test it.
6)Stability : The fewer the changes, the fewer the disruptions to testing
7)Understandability : The more information we have, the smarter we will test.

4. Test Characteristics Following are attributes of good test:
A good test has a high priority of finding errors.
A good test is not redundant.
A good test should be “best of breed”.
A good test should neither too simple nor too complex.

5. Internal And External Views of Testing
Any engineered product can be tested in one of two ways:
1) Knowing the specified function that product has designed to perform (external view)
2) Knowing internal working of a product (internal view)

6. White-Box Testing
White-box testing, also called glass-box testing, is a test-case design philosophy that uses the control structure described as a part of component-level design to derive test cases.
Using white-box testing methods, you can derive test cases that
1) guarantee that all independent paths within a module have been exercised at least once,
2) exercise all logical decisions on their true and false sides,
3) execute all loops at their boundaries and within their operational bounds,
4) exercise internal data structures to ensure their validity.

7. Basis Path Testing
Basis path testing, a white-box testing technique, enables the test-case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution path.
Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time testing.

8. Flow Graph Notation
The flow graph depicts logical control flow using some notations.
Figure : 18.1
Each circle in flow graph is called flow graph node and represents one or more procedural statements.
The arrows on flow graph is called edges or links and represents flow of control.
Areas bounded by edges and nodes are called regions.
When counting regions, we include the area outside the graph as a region.

9. Figure 18.2
A compound condition occurs when one or more Boolean operators (OR,AND) is present in a conditional statement.
Figure 18.3
Each node that contains a condition is called a predicate node and is characterized by two or more edges emanating from it.

10. Independent Program Paths
An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.
In terms of a flow graph, an independent path must move along at least one edge that has not been traversed before the path is defined.
Example
These paths constitute a basis set for flow graph 18.2
The basis set is not unique. A number of different basis sets can be derived for a given procedural design.

11. The computation of cyclomatic complexity helps to look for number of paths.
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program.
In context of basis path testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program.
Cyclomatic complexity is computed in one of three ways:

12. 1)The number of regions of the flow graph corresponds to the cyclomatic complexity.
2)Cyclomatic complexity V(G) for a flow graph G is defined as
V(G) = E – N + 2
where E is number of flow graph edges and N is number of flow graph nodes.
3)Cyclomatic complexity V(G) for flow graph G is defined as
V(G) = P + 1
where P is number of predicate nodes.

13. Deriving Test Cases Steps :
1)Using the design or code as a foundation, draw a corresponding flow graph.
2)Determine the cyclomatic complexity of the resultant flow graph.
3)Determine a basis set of linearly independent paths.
4) Prepare test cases that will force execution of each path in the basis : Data should be chosen so that conditions at the predicate nodes are appropriately set as each path is tested. Each test case is executed and compared to expected results. Once all test cases have been completed, the tester can be sure that all statements in the program have been executed at least once.

14. Graph Matrices
A data structure, called a graph matrix, can be quite useful for developing a software tool that assists in basis path testing.
A graph matrix is square matrix whose size (i.e. no of rows and columns) is equal to the no of nodes on the flow graph.
Each row and column corresponds to an identified node.
Matrix entries corresponds to connection (an edge) between nodes.
Figure

15. A Each node on flow graph is identified by no.
Each edge is identified by letters.
A letter entry is made in the matrix to corresponds to a connection between two nodes.
A link weight can also be added to each matrix entry.
If the link weight is 1 then connection exists. If it is 0 then connection does not exist.
A link weights can be assigned other properties
The probability that a link will execute.
The processing time expended during traversal of a link.
The memory required during traversal of link.
The resources required during traversal of link.

16. Control Structure Testing
It improves quality of white box testing.
Condition testing
Data flow testing
Loop testing.

17. Condition Testing
It is test case design method that exercise the logical condition contained in the program module.
A relational expression takes the form
E1 <relational operator> E2
Compound condition is composed of two or more conditions, Boolean operators and parentheses.
If a condition is incorrect, then at least one component of condition is incorrect. Types of errors in condition include Boolean operator errors (incorrect/missing/extra Boolean operators) , Boolean variable errors, parenthesis errors, relational operator errors and arithmetic expression errors.
The condition testing method focuses on the testing each condition in the program to ensure that it does not contain errors.

18. Data Flow Testing
The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program.
Assume that we are assigning unique statement no to statements and each function does not modify its parameters or global variables.
For a statement with s as its no,
DEF(s) = {x| statement s contains a definition of x}
USE(s) = {x| statement s contains a use of x}
If statement S is an if or loop statement, its DEF set is empty and its USE set is based on the condition of the statement s.

19. The definition of variable x at statement S is said to be live at statement S’ if there exists a path from statement S to S’ that contains no other definition of x.
A definition-use (DU) chain of variable x is of the form [x,s,s’], where s and s’ are statement numbers, x is in DEF(S) and USE(S’), and the definition of x in statement S is live at statement S’.

20. Loop Testing
It is white box testing technique that focuses on the validity of loop constructs.
Four classes of loops can be defined:-
(1)Simple
(2)Nested
(3)Concatenated loops
(4)Unstructured

21. Simple loop:- The following set of tests can be applied to simple loops. ( n is maximum no of allowable passes through the loop).
Skip the loop entirely.
Only one pass through the loop.
Two pass through the loop.
m passes through the loop where m<n.
n-1, n, n+1 passes through the loop.

22. Nested loop:- Beizer suggests an approach that will help to reduce the no of tests:
(1)Start at the innermost loop. Set all other loops to minimum value.
(2)Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum parameter ( loop counter) value.
(3)Work outward, but keeping all other outer loops at minimum values.
(4) Continue until all loops have been tested.

23. Concatenated loops:- It can be tested using the approach defined for simple loops , if each loop is independent of the other. When loops are not independent, the approach applied to nested loop is recommended.
Unstructured loop:- This class of loop should be redesigned to reflect the use of the structured programming language.

24. Black Box Testing
Also known as functional testing and behavioral testing, Black-box testing focuses on the functional requirements of the software.
The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.
Black Box Testing is testing without knowledge of the internal workings of the item being tested.  For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs.

25. The tester does not ever examine the programming code.
The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application.
Black box testing is sometimes also called as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".
It attempts to find errors in following categories: incorrect or missing functions, interface errors, errors in data structures or external database access

26. Graph Based Testing Method
Software testing begins by creating graph of important objects and their relationship and then devising a series of test that will cover the graph so that each object and relationship is exercised and errors are uncovered.
S.w eng begins by creating graph- collection of nodes that represent objects; links that represent the relationship between objects; node weight that represent properties of node; and link weights that describe some characteristics of link.
Link may take no of different forms:-

27. Directed link:- represented by arrow, indicates relationship moves in only one direction.
A bidirectional link:- also called symmetric link, implies that relationship applies in both direction.
Parallel link:- it is used when no. of different relationship are established between graph nodes.
Figure
Behavior Testing Methods that make use of graph
1) Transaction flow modeling :-nodes represent steps in some transactions (e.g. steps required to make airline reservation using online service) and the links represent the logical connection between steps.

28. 2)Finite state modeling:-nodes represent different user observable states of the s.w (e.g. each of the “screens” that appear as an order entry clerk takes a phone order) , and the links represent the transitions that occur to move from state to state.
3)Data flow modeling:- nodes are data objects and the links are the transformation that occur to translate one data object into another.
4)Timing modeling:- The nodes are program objects and links are sequential connections between those objects

29. Equivalence Partitioning
Divides input domain of program into classes of data from which test cases can be derived.
Goals:-
To reduce the number of test cases to a necessary minimum.
To select the right test cases to cover all possible scenarios.
Test-case design for equivalence partitioning is based on an evaluation of equivalence classes for input condition.
If a set of objects can be linked by relationships that are symmetric, transitive, and reflexive, an equivalence class is present.

30. An equivalence class represents a set of valid or invalid states for input condition.
An input condition is either a specific numeric value, a range of values, a set of related values, or a Boolean condition.
Equivalence classes may be defined according to the following guidelines:
If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
If an input condition specifies a member of a set, one valid and one invalid equivalence classes are defined.

31. 4) If input condition is Boolean
4) If input condition is Boolean. One valid and one invalid classes are defined.
Example : An input has certain ranges, one valid and two invalid equivalence classes are defined. This may be best explained at the following example of a function which has the pass parameter "month" of a date. The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.

32. | | invalid partition valid partition invalid partition 2
(one valid and two invalid equivalence classes are defined)

33. BVA (Boundary Value Analysis)
The boundaries of software component input ranges are areas of frequent problems.
A greater no of errors occurrs at the boundries of input domain rather than in the “center”.
BVA leads to selcetion of test cases that exercise bounding values.

34. if (month > 0 && month < 13)
But a common programming error may check a wrong range e.g. starting the range at 0 by writing:
if (month >= 0 && month < 13)
For more complex range checks in a program this may be a problem which is not so easily spotted as in the above simple example.
To set up boundary value analysis test cases you first have to determine which boundaries you have at the interface of a software component. This has to be done by applying the equivalence partitioning technique. Boundary value analysis and equivalence partitioning are inevitably linked together.

35. | | invalid partition valid partition invalid partition 2
Applying boundary value analysis you have to select now a test case at each side of the boundary between two partitions. In the above example this would be 0 and 1 for the lower boundary as well as 12 and 13 for the upper boundary
The boundary value analysis can have 6 text cases. n, n-1,n+1 for the upper limit and n, n-1,n+1 for the lower limit.

36. Rather than selecting any element of equivalence class, BVA leads to selection of test cases at the “edges” of class.
Rather than focusing solely on input conditions, BVA derives test cases from the output domain also.
Guidelines:-
(1)If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b as well as just above and just below a and b.

37. (2)If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below maximum and minimum are also tested.
(3)Apply 1 and 2 to output condition. E.g. assume that temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries.
(4)If internal program data structure have prescribed boundaries (e.g. an array has defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.

38. Testing For Specialized Environments, Architectures, And Applications
Testing GUI
GUI will present you with interesting testing challenges.
Because reusable components are a common part of GUI development environment, the creation of the UI has become less time consuming but the complexity of GUI has grown leading to more difficult in the design and execution of test cases.

39. Finite-state modeling graphs may be used to derive a series of tests that address specific data and program objects that are relevant to the GUI.
Because of the large number of permutations associated with GUI operations, GUI testing should be approached using automated tools.

40. Testing of Client-Server Architecture
The distribution nature of client-server environments, the performance issues associated with transaction processing, the complexity of network communication all combine to make testing of client-server architectures and the software that resides within them considerably more difficult than stand-alone application.
The testing of client-server software occurs at three different levels:
1)Individual client applications are tested in a “disconnected” mode; the operation of the server and the underlying network are not considered.

41. 2)The client software and associated server applications are tested in concert (performance), but network operations are not explicitly exercised.
3) The complete client-server architecture, including network operation and performance is tested.
Testing Approaches for client-server architecture
1) Application function tests : The functionality of client application is tested. The application is tested in stand-alone fashion to uncover an errors in its operations.
2) Server tests : The coordination and data management functions of the servers are tested.

42. 3) Database tests : The accuracy and integrity of data stored by the server is tested. Transactions posed by the client applications are examined to ensure that data are properly stored, updated, and retrieved.
4) Transaction tests : A series of tests are created to ensure that each class of transaction is processed according to requirements.
5) Network communication tests : These tests verify that communication among the nodes of network occurs correctly and that message passing transactions, and related network traffc occur without errors.

43. To accomplish these testing approaches, develop operational profiles derived from client-server usage scenarios.
An operational profile indicates how different types of users interoperate with the client-server system.
To develop operational profile, it is necessary to derive a set of scenarios.
Each usage scenario addresses who, where, what, and why.
Scenarios can be derived using requirement elicitation techniques.

44. Testing Documentation and Help Facilities
Errors in documentation can be devastating (disturbing) as errors in data or source code.
Nothing is more frustrating than following a user guide or an online help facility exactly and getting results or behavior that do not coincide with those predicated by the documentation.
Documentation testing can be approached in two different phases.
The first phase, technical review, examines the document for editorial clarity.
The second phase, live test, uses the documentation in conjunction with the actual program.

45. Testing for Real-Time Systems
Four step strategy :
1) Task testing : The first step is to test each task independently. Task testing uncovers errors n logic and function but not timing and behavior.
2)Behavioral Testing : Using system models created with automated tools, it is possible to simulate the behavior of a real-time system and examines its behavior as a consequence of a external events. Using a technique that is similar to equivalence partitioning, events are categorized. Each of these events is tested individually, and the behavior of the executable system is examined to detect errors.
3)Intertask testing : Now testing shifts to time-related

46. errors. Asynchronous tasks that are known to communicate with one another are tested with different data rates and processing load to determine if intertask synchronization errors will occur.
4)System Testing : Software and hardware are integrated, and full range of system tests are conducted in an attempt to uncover errors at the software-hardware interface.