Beruflich Dokumente
Kultur Dokumente
(09CS 491)
Objectives
l
To review the V Model and set the context for different types of tests
l l l
To focus on white box testing To distinguish between different types of white box testing To place special emphasis on
Software Testing
Slide 2
System Testing
High-Level Design
Integration Testing
Low-Level Design
Component Testing
Development
Unit Testing
Testing
Software Testing
Slide 3
V Model
Overall Business Requirements Acceptance Test Design Acceptance Test Execution
Software Requirements
High-Level Design
Low-Level Design
Development
Software Testing
Slide 4
Do an early test design. Involve the right people in the design of the right type of tests.
Make the tests reflect closely the steps on the left-hand side of
the V.
Unit testing
Software Testing
Slide 5
Software Testing
Slide 6
Software Testing
Slide 8
The program code truly represents what the program actually does and not just what it is intended to do!
It minimizes delay between defect injection and defect detection (i.e., does not postpone detection to be done by someone else).
Can catch obvious programming errors that do not necessarily map to common user scenarios (e.g., divide by zero).
Software Testing Slide 9
Static Testing
l l
Involves only the source code and not the executable or binaries
Does not involve executing the program on a machine but rather humans going through it or the usage of specialized tools
Humans can find errors that computers cant. Multiple humans can provide multiple perspectives.
Software Testing
Slide 11
Different types
Desk checking of the code Code walkthrough
Code review
Code inspection
l
l l l
QA vs QC argument Increasing the involvement of people More variety of perspectives Increasing formalism Increasing the likelihood of identifying more complex defects
Software Testing Slide 12
Desk Checking
l
l l l
No log or checklist is maintained. It relies only on the thoroughness of the author. It may suffice for obvious programming errors but may not be effective for incomplete / misunderstood requirements.
Software Testing
Slide 13
Advantages
The programmer knows the code and programming language well and hence is best suited to read the program Less scheduling and logistics overheads Reduces delay in defect detection and correction
Disadvantages
Software Testing
Slide 14
Code Walkthrough
l l l
Software Testing
Slide 15
l
l
Software Testing
Slide 16
Author Author of the work product Makes available the required material to the reviewers Fixes defects that are reported
Moderator Controls the meeting(s) Inspectors (reviewers) Prepare by reading the required documents Take part in the meeting(s) and report defects Scribe Takes down notes during the meeting Assigned in advance by turns Can participate to review to the extent possible Documents the minutes and circulates them to participants
Software Testing Slide 17
Software Testing
Slide 18
Preliminary meeting (optional) Author explains his / her perspective Makes available the necessary documents Highlights concern areas, if any, for which review comments are sought
Defect Logging Meeting All come prepared! Moderator goes through the code sequentially Each reviewer comes up with comments Comments / defects categorized as defect / observation, major / minor, systemic / mis-execution
Software Testing
Slide 20
Advantages
Thorough, when prepared well Brings in multiple perspectives
Disadvantages
Logistically difficult Time consuming May not be possible to exhaustively go through the entire code
Software Testing
Software Testing
Slide 22
Whether there are unreachable codes (usage of goto statements sometimes creates this situation; there could be other reasons too)
l l l l l
Variables declared but not used Mismatch in definition and assignment of values to variables Illegal or error-prone type-casting of variables Use of non-portable or architecture-dependent programming constructs Memory allocated but not having corresponding statements for freeing up memory
l l
For calculation of cyclomatic complexity As an extension of compilers (lint, compiler flag driven checking)
Software Testing Slide 23
The code review checklist aids in organizational learning by indicating what to look for.
It should be kept current as we learn. A discussion of a sample checklist is given on Page 54.
Software Testing
Slide 24
Structural Testing
l
l
Software Testing
Slide 26
Instrumentation rebuilds the product, linking it with libraries provided by the tool vendors.
l l
Instrumented code can monitor what parts of code is covered Can help identify critical portions of code, executed often
Software Testing
Slide 27
Condition coverage
Function coverage
Software Testing
Slide 28
Programming Constructs
l
Software Testing
Slide 29
Generate test data to make the program enter the sequential block, to make it go through the entire block (Is this valid?)
Asynchronous exceptions
Multiple entry points, in non-structured programming
Software Testing
Slide 30
if (code == M) {
stmt1; stmt2;
}
else percent = value/Total*100; /* divide by zero */
Software Testing
Slide 31
Path Coverage
l l
Statement Coverage may not indicate true coverage Path Coverage provides better representation
Previous example: Having data go through the THEN part and ELSE part gives only 50% coverage, irrespective of number of statements in each path
l l
Software Testing
Slide 32
Software Testing
Slide 33
Condition Coverage
l l
Further refinement of path coverage Makes sure each constituent condition in a Boolean expression
is covered
l
l
Software Testing
Slide 34
Function Coverage
l
l
l
l l l l
Software Testing
Slide 35
l
l l
Software Testing
Slide 36
Which of the paths are independent? (If paths are not independent, we may be able to minimize the number of tests.)
Is there an upper bound on the number of tests to be executed to ensure that all the statements have been executed at least once?
questions.
Software Testing
Slide 37
l l
Software Testing
Slide 38
Software Testing
Slide 39
Software Testing
Slide 40
Make sure that all edges terminate in some node, adding a node to represent all the statements at the end of the program.
Software Testing
Slide 41
Software Testing
Slide 42
Formal definitions
CC = # of predicate nodes + 1 CC = E N + 2 (E = edges, N = nodes)
Intuitive definitions
Software Testing
Slide 43
# of independent paths = 1 # of nodes, N = 2; # of edges, E = 1; Cyclomatic complexity = E N + 2 = 1 # of predicate nodes, P = 0; Cyclomatic complexity = P + 1 = 1
End
Software Testing
Slide 44
# of independent paths = 2 # of nodes, N = 4; # of edges, E = 4; Cyclomatic complexity = E N + 2 = 2 # of predicate nodes, P = 1; Cyclomatic complexity = P + 1 = 2 End
Software Testing
Slide 45
An independent path is a path in the flow graph that has not been traversed before in other paths.
Find the basis set and write the test cases to execute all the paths in the basis set.
Software Testing
Slide 46
1-10
10-20
20-40
>40
Developers not finding time for testing They develop blind spots for their own defects
Software Testing
Slide 48
Objectives (Recap)
l
To review the V Model and set the context for different types of
tests
l l l
To focus on white box testing To distinguish between different types of white box testing To place special emphasis on
Code reviews / inspections Methods of code coverage and relationship to quality Code complexity
Software Testing
Slide 49
Appendix
EXAMPLES
Software Testing
Slide 50
8 9
}
Software Testing Slide 52
F 5
F 9
9 k
Exit
Software Testing
Slide 54
Self reading
Unit-testing Heuristics
1. Create unit tests as soon as object design is completed: Black-box test: Test the use cases & functional model White-box test: Test the dynamic model Data-structure test: Test the object model 2. Develop the test cases Goal: Find the minimal number of test cases to cover as many paths as possible 3. Cross-check the test cases to eliminate duplicates Don't waste your time! 4. Desk check your source code Reduces testing time 5. Create a test harness Test drivers and test stubs are needed for integration testing 6. Describe the test oracle Often the result of the first successfully executed test 7. Execute the test cases Dont forget regression testing Re-execute test cases every time a change is made.
Big cost -> what should be done?
8. Compare the results of the test with the test oracle Automate as much as possible
Slide 55
Software Testing
THANKS!
Software Testing
Slide 56