chapter_14
-
Upload
mynee-sonu -
Category
Documents
-
view
67 -
download
1
Transcript of chapter_14
![Page 1: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/1.jpg)
Testing Tactics
TCS2411 Software Engineering 1
![Page 2: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/2.jpg)
Software Testing Fundamentals
Testability How easily a computer program can be
tested.What are the characteristics of testability?1.operability 5.Simplicity2.Observability 6.Stability3.Controllability 7.Understandability4.Decompsability
TCS2411 Software Engineering 2
![Page 3: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/3.jpg)
Operability 1. The better the software works, the more efficiently it can be tested.2. The system has few bugs (bugs add analysis and reporting overhead to the test process)3. No bugs block the execution of tests.4. The product evolves in functional stages (allows simultaneous development & testing
TCS2411 Software Engineering 3
![Page 4: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/4.jpg)
Observability in Software Testing:
1.What is seen is what is tested2. Distinct output is generated for each input3. System states and variables are visible or queriable during execution4. Past system states and variables are visible or queriable (eg., transaction logs)5. All factors affecting the output are visible6. Incorrect output is easily identified7. Incorrect input is easily identified8. Internal errors are automatically detected through self-testing mechanism9. Internally errors are automatically reported10. Source code is accessible
TCS2411 Software Engineering 4
![Page 5: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/5.jpg)
Controllability in Software Testing
1. The better the software is controlled, the more the testing can be automated and optimized.2. All possible outputs can be generated through some combination of input in Software Testing3. All code is executable through some combination of input in Software Testing4. Software and hardware states can be controlled directly by testing5. Input and output formats are consistent and structured in Software Testing6. Tests can be conveniently specified, automated, and
reproduced.
TCS2411 Software Engineering 5
![Page 6: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/6.jpg)
Decomposability in Software Testing:
1. By controlling the scope of testing, problems can be isolated quickly, and smarter testing can be performed.
2. The software system is built from independent modules
3. Software modules can be tested independently in Software Testing
TCS2411 Software Engineering 6
![Page 7: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/7.jpg)
Simplicity in Software Testing:
1. The less there is to test, the more quickly it can be tested in Software Testing2. Functional simplicity3. Structural simplicity4. Code simplicity
TCS2411 Software Engineering 7
![Page 8: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/8.jpg)
Stability in Software Testing:
1. The fewer the changes, the fewer the disruptions to testing
2. Changes to the software are infrequent
3. Changes to the software are controlled in Software Testing
4. Changes to the software do not invalidate existing tests in Software Testing
5. The software recovers well from failures in Software Testing
TCS2411 Software Engineering 8
![Page 9: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/9.jpg)
Understandability in Software Testing
1. The more information we have, the smarter we will test2. The design is well understood in Software Testing3. Dependencies between internal external and shared components are well understood.4. Changes to the design are communicated.5. Technical documentation is instantly accessible6. Technical documentation is well organized in Software Testing7. Technical documentation is specific and detailed8. Technical documentation is accurate
TCS2411 Software Engineering 9
![Page 10: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/10.jpg)
TCS2411 Software Engineering 10
Methods
Strategies
white-box
methods
black-box
methods
Software Testing
![Page 11: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/11.jpg)
TCS2411 Software Engineering 11
White Box Testing
Derived from knowledge of program’s structure & implementation
Structural testing - analyse code & use knowledge of the structure of a component to derive test data
Logical paths are tested by providing test cases that exercise specific sets of conditions and/or loops
![Page 12: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/12.jpg)
TCS2411 Software Engineering 12
White Box Testing (Continued)
Thorough white box testing would lead to “100 percent correct programs”
Exhaustive testing are impractical - too many tests!
A limited number of logical paths can be selected and exercised
Important data structures can be probed for validity
![Page 13: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/13.jpg)
TCS2411 Software Engineering 13
White Box Test Cases
Guarantee that all independent paths have been exercised at least once
Exercise all logical decisions on their true and false sides
Execute all loops at their boundaries and within their operational bounds
Exercise internal data structures to ensure their validity
![Page 14: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/14.jpg)
TCS2411 Software Engineering 14
White Box Testing Techniques
Basis path testing Flow graph notation Cyclomatic complexity Derived test cases Graph metrics
Control structure testing Condition testing Data Flow testing Loop testing
![Page 15: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/15.jpg)
TCS2411 Software Engineering 15
Flow Graph Notation
1
2
3
6
7 8
4
5
9
1011
1
2,3
6
7 8
9
10
11
4,5
NodeEdge
R3
R2
R1
R4
Region
![Page 16: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/16.jpg)
TCS2411 Software Engineering 16
Cyclomatic Complexity
Provide quantitative measure for program logical complexity.
Defined number of independent path Any path that introduce one ser of processing
statements or new conditionEg :-
Path 1 : 1-11 Path 2 : 1-2-3-4-5-10-1-11 Path 3 : 1-2-3-6-8-9-10-1-11 Path 4 : 1-2-3-6-7-9-10-1-11
![Page 17: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/17.jpg)
TCS2411 Software Engineering 17
How Is Cyclomatic Complexity Computed?
1. Number of regions The flow graph has 4 regions
2. V(G) = E – N + 2 E : Number of flow graph edges N : Number of flow graph nodes
V(G) = 11 edges – 9 nodes + 2 = 4
3. V(G) = P + 1 P : Number of predicate nodes
V(G) = 3 predicate nodes + 1 = 4
![Page 18: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/18.jpg)
TCS2411 Software Engineering 18
Deriving Test Cases1. Draw flow graph from design/code as foundation.
…i=1;total.input = total.valid=0;sum=0;do while value[i] <> -999 and total.input<100 increment total.input by 1; if value[i] >= minimum AND value[i] <= maximum then increment total.valid by 1; sum = sum + value[i] else skip end if increment i by 1End doIf total.valid > 0 then average = sum / total valid; else average = -999;End if…
1
2
3
4
56
7
8
9
10
1112
13
1
2
3
4
5
6
78
9
10
1112
13
![Page 19: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/19.jpg)
TCS2411 Software Engineering 19
Deriving Test Cases (cont)
2. Determine cyclomatic complexity V(G) = 6 regions V(G) = 17 edges – 13 nodes + 2 = 6 V(G) = 5 predicates nodes + 1 = 6
3. Determine a basis set of linearly independent graph Path 1 = 1-2-10-11-13 Path 2 = 1-2-10-12-13 ….
4. Prepare test cases that will force execution of each path in the basis set.
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 result.
![Page 20: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/20.jpg)
TCS2411 Software Engineering 20
Discussion on White Box Testing
Advantages Find errors on code level Typically based on a very systematic
approach, covering the complete internal module structure
Constraints Does not find missing or additional
functionality Does not really check the interface Difficult for large and complex module
![Page 21: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/21.jpg)
TCS2411 Software Engineering 21
![Page 22: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/22.jpg)
Control structure testing
Condition testing Data Flow testing Loop testing
TCS2411 Software Engineering 22
![Page 23: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/23.jpg)
23
DEF(s)={x/statement S contains definition of x}
USE(s)={x/statement S contains a use of x}
For a statement with S as its statement number
A definition-use chain of variable x is of the form [X,S,S’],where S,S’ are statement no,X is in DEF(S) and USE(S’) and the definition of X in statement S is live at
statement S’.
![Page 24: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/24.jpg)
Loop testing is a white-box testing
technique that focuses exclusively on the validity of loop constructs.
TCS2411 Software Engineering 24
![Page 25: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/25.jpg)
Loop testing is a white-box testing technique that focuses exclusively on the validity of loop constructs.
TCS2411 Software Engineering 25
![Page 26: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/26.jpg)
TCS2411 Software Engineering 26
![Page 27: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/27.jpg)
TCS2411 Software Engineering 27
![Page 28: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/28.jpg)
TCS2411 Software Engineering 28
Black Box Testing
Derived from program specificationFunctional testing of a component of
a systemExamine behaviour through inputs &
the corresponding outputsInput is properly accepted, output is
correctly producedDisregard internal logical structure
![Page 29: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/29.jpg)
TCS2411 Software Engineering 29
Black Box Testing (Continued)
Attempts to find the following errors:Incorrect or missing functionsInterface errorsErrors in data structures or external
database accessPerformance errorsInitialisation and termination errors
![Page 30: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/30.jpg)
TCS2411 Software Engineering 30
Black Box Testing Techniques
Graph Based Testing MethodsEquivalence PartitioningBoundary Value Analysis
![Page 31: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/31.jpg)
TCS2411 Software Engineering 31
![Page 32: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/32.jpg)
TCS2411 Software Engineering 32
Equivalence Partitioning
Divide input domain into classes of dataBased on an evaluation of equivalence classes
for an input conditionGuidelines to define equivalence classes
Range input : One valid and two invalid equivalence Specific value : One valid and two invalid
equivalence A member of a set : One valid and one invalid
equivalence Boolean : One valid and one invalid equivalence
![Page 33: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/33.jpg)
Equivalence Partitioning
In this method ,the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements.
TCS2411 Software Engineering 33
![Page 34: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/34.jpg)
TCS2411 Software Engineering 34
Example – Data for Automated Banking Application
The use can access the bank using his personal computer, provide a six digit password, and follow with a series of typed commands that trigger various banking function. During the log on sequence the software supplied for the banking application accepts data in the form:
area code – blank or 3 digit numbersprefix – 3 digit numbers, nor beginning with 0 or 1suffix – 4 digit numberspassword – 6 digits alphanumeric stringscommands – “check”, “deposit”, “bill pay” etc
Input condition
area code : Input condition : Boolean – area code may or may not present Input condition : Range – 200 – 999 with specific exception
prefix : Input condition : Range – specified value > 200 with no 0 digitssuffix : Input condition : Value – 4 digit lengthpassword : Input condition : Boolean – password may or may not present
Input condition : Value – six character stringcommand : Input condition : Set – containing command
![Page 35: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/35.jpg)
Boundary Value Analysis
It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain.
TCS2411 Software Engineering 35
![Page 36: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/36.jpg)
TCS2411 Software Engineering 36
Boundary Value Analysis
Complement equivalence partitioningTest both sides of each boundary Look at output boundaries for test
cases Test min, min-1, max, max+1, typical
valuesExample : 1 <= x <=100
Valid : 1, 2, 99, 100 Invalid : 0 and 101
![Page 37: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/37.jpg)
TCS2411 Software Engineering 37
Discussion on Black Box Testing
Advantages Find missing functionality Independent from code size and
functionality Find some coding errors
Constraints No systematic search for low level errors Specification errors not found
![Page 38: chapter_14](https://reader033.fdocuments.net/reader033/viewer/2022061123/5471a72fb4af9fcf148b457d/html5/thumbnails/38.jpg)
TCS2411 Software Engineering 38
References
“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001