Activity & Class Modeling Labs Discussion p3 T120B029 200 4 pavasario sem.
Software testing Lecture p8 T120B029 2012 pavasario sem.
-
Upload
nelson-jeffery-peters -
Category
Documents
-
view
215 -
download
2
Transcript of Software testing Lecture p8 T120B029 2012 pavasario sem.
![Page 1: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/1.jpg)
Software testingSoftware testing
LectureLecturep8p8
T120B029T120B02920201212 pavasario sem. pavasario sem.
![Page 2: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/2.jpg)
2
Motivation
“ Testing is the process ofexecuting a program with
theintent of finding errors”
![Page 3: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/3.jpg)
3
Limits of software testing
• “Good” testing will find bugs• “Good” testing is based on requirements,
i.e. testing tries to find differences between the expected and the observed behavior of systems or their components
• BUT: Testing can only prove the presence of bugs - never their absence
![Page 4: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/4.jpg)
4
Test Specification - Manual Process
Manual Manual Manual
Test Document
Text-based
Inspection Test Cases
![Page 5: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/5.jpg)
5
Semi-Automated Process
Manual
Semi- Automated Automated
Test Document
Model-based
Inspection Test Cases
Consistency SyntaxSemantic
![Page 6: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/6.jpg)
6
The V-modelRequirements Definition
Functional system Design
Technical system Design
Component Specification
Implementation
Acceptance Level Testing
System Level Testing
Integration Level Testing
Unit Level Testing
Constru
ction p
hase
ss
Test
ing p
hase
ss
I
II
IV
III
![Page 7: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/7.jpg)
7
The W-modelI
II
III
IV
Implementation
Acceptance Level Testing
System Level Testing
Integration Level Testing
Unit Level Testing
Constru
ction p
hase
ss
Preparation of Acceptance Level Testing
Preparation of System Level TestingPreparation of Integration Level Testing
Preparation of Unit Level Testing
Debuging
![Page 8: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/8.jpg)
8
Using UML and UTP in system development
UML
UML
UML
UML
UTP
UTP
UTP
UTP
TTCN
TTCN
Junit&TTCN
JUnit
Debuging
Debuging
Debuging
Debuging
Implementation Changes
I
II
III
IV
![Page 9: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/9.jpg)
9
Exhaustive testing
There are 1014 possible paths! If we execute one test per millisecond, it would take 3.170 years to test this program!! Out of question
loop < 20x
![Page 10: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/10.jpg)
10
Testability = how easy can a program be tested
Features that help/influence testing:• operability - it operates cleanly• observability
• the results are easy to see• distinct output is generated for each input• incorrect output is easily identified
• controllability• processing can be controlled• tests can be automated & reproduced
• decomposability - software modules can be tested independently
• simplicity - no complex architecture and logic• stability - few changes are requested during testing• understandability - program is easy to understand
![Page 11: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/11.jpg)
11
Who tests the software
Understands the systembut, will test “gently”and, is driven by “delivery”
Must learn about the system,but, will attempt to break itand, is driven by quality
developer independent tester
![Page 12: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/12.jpg)
12
Test cases
• Describe how to test a system/module/function
• Description must identify– system state before executing the test– function to be tested– parameter values for the test– expected outcome of the test
Some automation should be possible after defining them!
![Page 13: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/13.jpg)
13
Black box vs. white box testing
requirements
input
events
output
![Page 14: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/14.jpg)
14
White box testing
…our goal is to ensure that all statements and conditions have been executed at least once...
![Page 15: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/15.jpg)
15
White box testing:Why cover all paths?
• logic errors and incorrect assumptions are inversely proportional to a path’s execution probability
• we often believe that a path is not likely to be executed; in fact, reality is often counter intuitive
• typographical errors are random; it’s likely that untested paths will contain some
![Page 16: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/16.jpg)
16
Guaranteed cover:Exhaustive testing
But:There are 520=1014 (approx.) possible paths!
loop < 20x
If-then-else
![Page 17: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/17.jpg)
17
Better:Selective testing
a selected path
loop < = 20x
![Page 18: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/18.jpg)
18
Path coverage testing
1) Derive a logical complexity measure
2) Use it to define a basis set of execution paths
First, we compute the cyclomatic complexity V(G):
number of transitions - number of nodes +2
In this case, V (G) = 4
V(G) provides an upper bound of tests that must be executed to guarantee coverage of all program statements
![Page 19: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/19.jpg)
19
Path coverage set• Cyclomatic complexity defines the
number of independent paths in the basis set
• Path coverage set = set of paths that will execute all statements and all conditions in a program at least once
• Goal: Define test cases for basis set• Path coverage set is not unique!
![Page 20: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/20.jpg)
20
Path coverage testing
1
2
4
7
8
3
65
Next, we derive the independent paths:
Since V(G) = 4, there are four paths
Path 1: 1,2,3,6,7,8
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4…7,8
Finally, we derive test cases to exercise these paths, i.e. choose inputs that lead to traversing the paths
![Page 21: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/21.jpg)
21
Documenting test cases
• Name• Number• Description of system state before
running the test case• Values for the inputs• Expected outputs• Short description (if needed)
![Page 22: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/22.jpg)
22
Path coverage testing - remarks
• you don’t need a flow chart, but the picture will help when you trace program paths
• each connection between boxes counts as 1 transition
• path coverage testing should be applied to critical modules
Connects four boxes counts as three transitions
![Page 23: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/23.jpg)
23
Black box testing
requirements
input
events
output
![Page 24: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/24.jpg)
24
Categories of errors in
black box testing
• incorrect or missing functions• interface errors• errors in data structures or external
database access• performance errors• initialization and termination errors
![Page 25: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/25.jpg)
25
Example
abs(integer x)Return x if x >= 0Return -x if x<0
• The concrete value of x does not matter! Basis for Equivalence Testing
![Page 26: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/26.jpg)
26
Loops
• Cornerstone of every program• Loops can lead to non-
terminating programs
![Page 27: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/27.jpg)
27
Loop testingsimple loop
nested loops
concatenated loops
unstructured loops
![Page 28: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/28.jpg)
28
Loop testing: simple loops
Minimum conditions - simple loops1. skip the loop entirely2. only one pass through the loop3. two passes through the loop4. m passes through the loop m < n5. (n-1), n, and (n+1) passes through the loop
where n is the maximum number of allowable passes
![Page 29: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/29.jpg)
29
Nested loops• Just extending simple loop testing:
number of tests explodes• Reduce the number of tests:
– start at the innermost loop; set all other loops to minimum values
– conduct simple loop test; add out of range or excluded values
– work outwards while keeping inner nested loops to typical values
– continue until all loops have been tested
![Page 30: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/30.jpg)
30
Equivalence class testing Equivalence partitioning
userqueries
numericaldata
output format requests
responsesto prompts
command key input
mouse picks on menu
Partitioning is basedon input conditions
![Page 31: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/31.jpg)
31
Equivalence classes (1)
• Valid data– user supplied commands– responses to system prompts– file names– computational data
physical parametersbounding valuesinitiation values
– output data formatting commands– responses to error messages– graphical data (e.g., mouse picks)
![Page 32: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/32.jpg)
32
Equivalence classes (2)
• Invalid data– data outside bounds of the program– physically impossible data– proper value supplied in wrong place
![Page 33: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/33.jpg)
33
Defining equivalence classes
• Input condition is a range: one valid and two invalid classes are defined
• Input condition requires specific value: one valid and two invalid classes are defined
• Input condition is boolean: one valid and one invalid class are defined
Then define one test case for each equivalence class
![Page 34: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/34.jpg)
34
Automating software testing
• Manual software testing is time consuming
• Software testing has to be repeated after every change (regression testing)
• Write test drivers that can run automatically and produce a test report
![Page 35: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/35.jpg)
35
Testing OO software:general remarks
• Based on UML specifications– Use cases– Class diagrams– State transition diagrams– …
• Problem: Effort
focus on requirementsnot comprehensive quality?
![Page 36: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/36.jpg)
36
Scenario based testing
• Concentrates on (functional) requirements
• Based on – use cases – corresponding sequence diagrams
![Page 37: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/37.jpg)
37
Test Requirements• Every use case• Every fully expanded extension
(<<extend>>) combination• Every fully expanded uses
(<<uses>>) combination• Tests normal as well as exceptional
behavior
![Page 38: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/38.jpg)
38
Example
![Page 39: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/39.jpg)
39
Scenarios for ATM Example
![Page 40: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/40.jpg)
40
Test Procedure (1)• Establish testing budget• Rank Use Cases (& variants) according
to– Relative frequencies– Criticality
• Allocate #test cases to each use case (and possibly variants)
• Develop test cases for scenarios
![Page 41: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/41.jpg)
41
Testing a use case/scenarios (1)
• A scenario is a path through a sequence diagram
• There are many different scenarios associated with a sequence diagram!
![Page 42: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/42.jpg)
42
What can be wrong?• Incorrect or missing output• Missing function/feature in an object• Incorrect parameter values boundary value
analysis• Correct message - wrong object• Incorrect message - right object• Incorrect object state• Message sent to destroyed object• Incorrect exception thrown• Incorrect exception handling• Incorrect assumption about receiver’s class
– Class casts
![Page 43: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/43.jpg)
43
Testing a use case/scenarios (2)
• All paths in sequence diagram should be executed– Focus on messages from the actor/UI to the
system– If possible: check “internal” objects
• Extract control flow information from a sequence diagram – Test branches and loops– Test exceptions– Consider state
![Page 44: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/44.jpg)
44
Example: Establish Session
<4]
![Page 45: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/45.jpg)
45
Example (cont.)• Several checks are performed
– Is the card an ATM card?– Is the card stolen?– Has the customer a valid bank account?– Has the customer a valid PIN?
• Three chances to enter the PIN• Service charge if from different bank
![Page 46: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/46.jpg)
46
Test Procedure (2)
• Translate the sequence diagram into a flow graph– Each message or group of consecutive
messages becomes a segment (box). – A conditional action (branch, iteration)
ends a segment– Each bracketed (loop) condition
becomes a decision (hexagon)
![Page 47: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/47.jpg)
47
Establish Session
![Page 48: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/48.jpg)
48
Remarks• White-box testing can be applied
to flow graph• Control flow graph may reveal
– ambiguities and omissions in the sequence diagram
• Ambiguities either reveal faults or a behavior to be interpreted by the coder
![Page 49: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/49.jpg)
49
Path conditions• Input and object state need to
satisfy the path conditions• Identify predicates on each path,
work from first predicate and identify required input and state variable values
• Do the same for the next path conditions until the last one
• Some paths may not be feasible
![Page 50: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/50.jpg)
50
Example: Path Conditions
![Page 51: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/51.jpg)
51
Special cases• Sequence diagrams rarely include
two significant details: – Polymorphism: receiver has to be of a
specific type but not an instance of one specific class•If needed: check instances of different classes
– Exception-handling: “jumping out” of the sequence diagram•Catch exception
![Page 52: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/52.jpg)
52
Test Procedure (3)
• Develop the Use Case / Class coverage matrix
• Analyze matrix– Which classes are not covered by test
cases?– Which methods of a class are not
covered?
• Create additional test cases
![Page 53: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/53.jpg)
53
Use case / class coverage matrix
ResourcePool Resource …newResource deleteResource … setname …. …
use case 1 X Xuse case 2 X…
![Page 54: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/54.jpg)
54
Test case document
1. Usual cover information2. Use case test descriptions3. References4. Appendices
![Page 55: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/55.jpg)
55
Test Procedure (4)• Define test case
– Name– Unique number– Textual description of test procedure
• Based on flow graph and conditions• Includes expected results after each step
define condition that allows todetermine if the step succeededor failed
![Page 56: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/56.jpg)
56
Use case test descriptions
• For every use case/sequence diagram in the design document– a test case that shows that the scenarios and
its variations can be executed by the system• describe as precondition the objects and
their state that get messages from the UI• As steps: list the sequence of messages
that are send from the UI to other objects
– test cases for all exceptions of the use case
![Page 57: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/57.jpg)
57
Example: Test case definition (1)
Test “Establish session”UID: 0001Description:
Precondition: ATM is running and no sessions exist…
![Page 58: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/58.jpg)
58
Example: Test case definition (2)
…Step 1: test “begin session”
To execute: Create a session objectExpected result: session object exists and is in its
initial state
Step 2: test “no ATM card was entered”Precondition: Card entered is no ATM cardTo execute: Read cardExpected result: NoATMCard exception is thrown
and session object was deleted
…
![Page 59: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/59.jpg)
59
Example: Test case definition (3)
…Step 3: test “get PIN”
Precondition: Card entered is ATM cardTo execute (a): displayEnterPINExpected result: “Enter PIN” is displayedTo execute (b): getEntryExpected result: 4 digit entry of a stolen cardTo execute (c): checkCardExpected result: StolenCardException is thrown…
![Page 60: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/60.jpg)
60
Example: Test case definition (4)
…To execute (d): getEntryExpected result: 4 digit entry of invalid accountTo execute (e): checkCardExpected result: falseTo execute (g): getEntryExpected result: 4 digit entry of valid accountTo execute (h): checkCardExpected result: true…
![Page 61: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/61.jpg)
61
Executing tests• Develop automatic test drivers
– In assignment: test driver should run on CLIENT side to make sure that the client/server communication is properly implemented
• Use case tests– develop test classes that execute the use
cases without user involvement
• Test the use cases manually with UI• System test driver calls all use case test
classes
![Page 62: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/62.jpg)
62
Implementing test cases
• Test driver code must– create the system state described in the
test case– call the method to test– check if the expected result is produced– print test result to file/console e.g.– count the number of failed test to produce
a summary result at the end
![Page 63: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/63.jpg)
63
Test driver (1)package atm.impl.test;public class ATMUseCaseTest {
private int allErrors = 0; //count #errors
private void usecase1 () { //test use case 1try{
System.out.println(“========“);System.out.println(“Testing Use Case 1: Establish Session”);testStep1();testStep2();testStep3();…System.out.print(“Establish Session: Errors found = ”, allErrors);System.out.print(“Finished testing Use Case 1: Establish Session”);}
catch (Exception anExc) {System.out.println(“Unexpected exception “, anExc, “in Use Case 1”); allErrors = allErrors +1;
System.out.print(“Establish Session: Errors found = ”, allErrors); System.out.println(“Testing Use Case 1: Establish Session”);}
}…
![Page 64: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/64.jpg)
64
Test driver (2) private void testStep1() {
try{//test step 1 of use case 1System.out.print(“Testing Step 1: Begin Session ”);
//create precondition/state//execute testSession aSession = new Session();//check postcondition and print resultif (aSession == null) {System.out.println(“failed”); allErrors = allErrors + 1;}else{System.out.println(“succeeded”);}}
catch (Exception anExc) {System.out.println(“Unexpected exception “, anExc, “in Step 1”); allErrors = allErrors + 1;}
}…
![Page 65: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/65.jpg)
65
Tools to use(1)
Test Design Test
Specificacion
Test Result Analysis
TestExecutation
TestValidation
UTP
![Page 66: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/66.jpg)
66
Tools to use(2)
•Test design•Test specification•Test validation•Test execution•Test result analysis•Test generation•System model validation
![Page 67: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/67.jpg)
67
Tools to use(3)
•Test management tools•Monitoring tools•Defect tracking tools•Static analysis tools•Metrics tools
![Page 68: Software testing Lecture p8 T120B029 2012 pavasario sem.](https://reader038.fdocuments.us/reader038/viewer/2022110210/56649e5e5503460f94b58329/html5/thumbnails/68.jpg)
68
Tools to use(4)
Test Management Tool
Converted to UTP format
Serialized using XMI Encoder
Test Execution Tool
Converted from UTP format
Serialized using XMI Decoder
Abstraction Layer