cen 5070 - software v & v unit testing concepts 2/2000unit test concepts2 purpose this module...
DESCRIPTION
2/2000Unit Test Concepts2 Purpose This module presents the basic concepts of black-box and white-box testing for unit testing. A systematic approach is shown for deriving functional, boundary and white-box test cases. "… arbitrarily selected test set... results in inefficient testing, leaving some functions untested while performing redundant testing of others." Darlene Mackay, Quality Consultants UnlimitedTRANSCRIPT
CEN 5070 - Software V & V
Unit Testing Concepts
2/2000 Unit Test Concepts 2
Purpose
This module presents the basic concepts of black-box and white-box testing for unit testing. A systematic approach is shown for deriving functional, boundary and white-box test cases.
"… arbitrarily selected test set ... results in inefficient testing, leavingsome functions untested while performing redundant testing of others."Darlene Mackay, Quality Consultants Unlimited
2/2000 Unit Test Concepts 3
Agenda
• What Is Unit Testing
• Black-Box Testing
• White-Box Testing
• Putting It All Together
2/2000 Unit Test Concepts 4
WHAT IS UNIT TESTING?
• Executing a software element to determine whether it meets its specification
• Executing a software element to discover defects or anomalies
• Inspecting software element code to discover defects or anomalies.
2/2000 Unit Test Concepts 5
WHAT IS A UNIT?
• Named software element • Separately invokable• Performs single function• Examples
• Subprogram or script• Field with validation• Database stored procedure• Java class method
2/2000 Unit Test Concepts 6
SPRAE: A Model for Testing Practice
• Specification -- basis for software testing• Premeditation -- testing requires planning,
forethought • Repeatability -- process, results independent
of tester• Accountability -- testing artifacts maintained• Economy in the use of human, time and
computing resources
2/2000 Unit Test Concepts 7
A TESTING LIFECYCLE
Analysis
Design
Implementation
Execution
Evaluation
Specification
Test Strategy/Plan
Test Script, Data, Driver
Defect DataProblem Reports
Test Results
Test Cases
2/2000 Unit Test Concepts 8
Agenda
• What is Unit Testing
• Black-Box Testing
• White-Box Testing
• Putting It All Together
2/2000 Unit Test Concepts 9
BLACK-BOX TESTING
• Testing based on the specification rather than the implementation.
• Specification defines the expected response(s) to stimuli
SoftwareunderTest
Stimuli Response(s)
2/2000 Unit Test Concepts 10
BLACK-BOX TECHNIQUES
• Functional testing -- tests the behavior of the software.
• Boundary testing -- tests behavior at the lower/upper bounds of input values
• Random testing -- tests using randomly generated stimuli (load testing)
• Intuitive (ad hoc) testing -- error guessing
2/2000 Unit Test Concepts 11
BLACK-BOX TECHNIQUESFuzz Testing
• Fuzz testing – random data used as program inputs
• Forces program crashes, assertion violations
• Is not functional (results-oriented) testing• Barton Miller at U. Wisconsin, 1988-89
2/2000 Unit Test Concepts 12
BLACK-BOX TECHNIQUESCategory Partitioning
1. Transform the system’s specification to be more concise and structured.2. Decompose the specification into functional units - to
be tested independently.3. Identify the parameters and environment
conditions.4. Find categories that characterize each parameter and
environment condition.5. Every category should be partitioned into distinct
choices www.cis.famu.edu/~cen5070joe/Lectures/CPM.pdf, CPM_paper.pdf
2/2000 Unit Test Concepts 13
BLACK-BOX TECHNIQUESEquivalence Partitioning
1. Domain testing approach – input (domain) or output (range)
2. An equivalence partition (EP) is a set of values s.t. behavior is same for all values in set• Month: valid=[1,12]; Lo = [<1]; Hi [ >12]• Age: baby = [<1]; toddler = [1,3]; teen=[13,19];adult
=[19,55];senior=[>55]3. Output partition – idea to force all behaviors to be seen
• Loan Action: [approved], [denied], [conditional], [held]4. Rules in Dec Table => equivalence class of data values
that cause rule to fire.
2/2000 Unit Test Concepts 14
FUNCTIONAL TEST DESIGN METHODOLOGY
• Specification
• Identify behaviors
• Develop test cases
• Write test script
2/2000 Unit Test Concepts 15
EXAMPLE A(1) Specification
• Compute pay for an hourly employee, given the number of hours worked and the hourly pay rate. Compute overtime at 1.5 times hourly rate for hours in excess of 40.
SoftwareunderTest
Hours PayRate
2/2000 Unit Test Concepts 16
EXAMPLE A(2) Identify Behaviors
• Case 1: No overtime (Hours <= 40)• Expect Pay = Hours * Rate
• Case 2: Overtime (Hours > 40)• Expect Pay = 40*Rate+1.5*Rate*(Hours - 40)
2/2000 Unit Test Concepts 17
EXAMPLE A(3) Create Test Cases
• Case 1: No overtime (Hours <= 40)• Use Rate = 10, Hours = 30• Expect Pay = Hours * Rate = 300
• Case 2: Overtime (Hours > 40)• Use Rate = 10, Hours = 50 • Expect Pay = 40*Rate+1.5*Rate*(Hours - 40) = 550
2/2000 Unit Test Concepts 18
EXAMPLE A(4) Write Test Script
StepStimuli Expected Response
Hours Rate Pay =12
3050 10
10 300550
2/2000 Unit Test Concepts 19
A MORE COMPLEX EXAMPLE (B)
• Increased number of behaviors
• Use of decision table to document
behaviors
• Test case generation from decision table
2/2000 Unit Test Concepts 20
EXAMPLE B(1) Specification
• Compute pay for employee, given the number of hours worked and the hourly pay rate. For hourly employees (rate < 30), compute overtime at 1.5 times hourly rate for hours in excess of 40. Salaried employees (rate >= 30) are paid for exactly 40 hours.
2/2000 Unit Test Concepts 21
EXAMPLE B(2) Identify Behaviors
• Case 1: Hourly AND No overtime • (Rate < 30) & (Hours <= 40)• Expect Pay = Hours * Rate
• Case 2: Hourly AND Overtime • (Rate < 30) & (Hours > 40)• Expect Pay = 40*Rate+1.5*Rate*(Hours - 40)
• Case 3: Salaried (Rate >= 30) • Expect Pay = 40 * Rate
2/2000 Unit Test Concepts 22
DECISION TABLE
Condition c1: Rate < 30 | Y Y N N
c2: Hours <= 40 | Y N Y NAction
a1: Pay = Straight time | X
a2: Pay = Overtime | X
a3: Pay = Professional | X X
Columns defineBehaviors
2/2000 Unit Test Concepts 23
EXAMPLE B(3) Create Test Cases
• One test case per column of decision table• Case 1: Hourly, No Overtime
• Case 2: Hourly, Overtime
• Case 3: Salaried, No Extra Hours
• Case 4: Salaried, Extra Hours
• Order the test cases by column
2/2000 Unit Test Concepts 24
EXAMPLE B(4) Write Test Script
StepStimuli Expected Response
Hours Rate Pay =12
3050 10
10 300550
3 30 40 16004 50 40 1600
2/2000 Unit Test Concepts 25
RULES -- DECISION TABLES
Condition c1: Rate < 30 | Y Y N N
c2: Hours <= 40 | Y N Y NAction
a1: Pay = Straight time | X
a2: Pay = Overtime | X
a3: Pay = Professional | X X Use X to select action(s)
Elementaryconditions
Use 'Y', 'N', '-' or space
2/2000 Unit Test Concepts 26
Your Turn -- Problem P1(1) Specification
• Compute the dosage of drug X for patient, given the patient's Age and Weight. For patients 12 and under, the dosage is 1 pill. For patients over 65, the dosage is 2 pills. For all other patients, the dosage is 2 pills plus an extra pill for each 50 pounds above 120. The drug can not be given to patients over 300 pounds or over the age of 80.
2/2000 Unit Test Concepts 27
Your Turn(2a) Identify Behaviors
CaseExpected
Stimulus Description #Pills 123456
2/2000 Unit Test Concepts 28
Your Turn (2b) Decision Table
c1: Age <= 12 |
c2: Age > 65 |
c3: Age > 80 |
c4: Weight > 300 |
c5: Weight > 120 |a1: Pills = 0 |
a2: Pills = 1 |
a3: Pills = 2 |
a4: Pills = 2+(W-120)/50 |
2/2000 Unit Test Concepts 29
Your Turn(3) Create Test Cases
Case 1 2 3 4 5 6 7 8 9
Age ___ ___ ___ ___ ___ ___ ___ ___ ___
Weight ___ ___ ___ ___ ___ ___ ___ ___ ___
Pills ___ ___ ___ ___ ___ ___ ___ ___ ___
2/2000 Unit Test Concepts 30
Your Turn(4) Write Test Script
StepStimuli Pills=
Age123456
Weight StepStimuli Pills= Age
78910
12
Weight
11
2/2000 Unit Test Concepts 31
SCALING UP
The heart of the approach is to use a decision table as a thinking tool. The most critical task in this process is to identify all the stimuli and responses. When there are many logical combinations of stimuli, the decision table can become large, indicating that the unit is probably too complex.
2/2000 Unit Test Concepts 32
IDENTIFYING BEHAVIORApproaches
• Work backwards• Identify each response• Identify conditions that provoke response• Identify separate stimuli
• Work forward• Identify each stimulus• Identify how stimulus influences what unit does• Specify the response• Treat stimuli combinations
2/2000 Unit Test Concepts 33
IDENTIFYING STIMULI
• Arguments passed upon invocation• Interactive user inputs• Internal, secondary data
• global or class variables• External data (sources)
• file or database status variables• file or database data
• Exceptions
2/2000 Unit Test Concepts 34
IT PAYS TO BE A GOOD STIMULUS DETECTIVE
• Failure to identify stimuli results in an incomplete, possibly misleading test case
• The search for stimuli exposes• interface assumptions -- a major source of
integration problems• incomplete design of unit• inadequate provision for exception handling
2/2000 Unit Test Concepts 35
IDENTIFYING RESPONSES
• Arguments/Results passed back on exit• Interactive user outputs• Internal, secondary data
• updated global or class variables• External data (sinks)
• output file or database status variables• output file or database data
• Exceptions
2/2000 Unit Test Concepts 36
IT PAYS TO BE A GOOD RESPONSE DETECTIVE
• Failure to identify responses results in • incomplete understanding of the software
under test• shallow test cases• incomplete expected results• incomplete test "success" verification --
certain effects not checked• To test, one must know all the effects
2/2000 Unit Test Concepts 37
A SKETCHING TOOL Black-Box Schematic
Stimulus Type Response Type
SoftwareunderTest
Argument
Inputs
Globals
Database
Exception
Argument
Outputs
Globals
Database
Exception
2/2000 Unit Test Concepts 38
BEFORE CONTINUTING
Much of the discussion so far involves how to identify what software does. We have introduced thinking tools for systematically capturing our findings. These thought processes and tools can be used anywhere in the lifecycle, e.g., in software design!
One Stone for Two Birds!!
2/2000 Unit Test Concepts 39
BOUNDARY TESTING DESIGN METHODOLOGY
• Specification
• Identify elementary boundary conditions
• Identify boundary points
• Generate boundary test cases
• Update test script (add boundary cases).
2/2000 Unit Test Concepts 40
(1) Specification
• Compute pay for an hourly employee, given the number of hours worked and the hourly pay rate. Compute overtime at 1.5 times hourly rate for hours in excess of 40.
SoftwareunderTest
Hours PayRate
2/2000 Unit Test Concepts 41
(2) Identify Boundary Conditions
• Condition 1 (bc1): Hours <= 40
• Observations:• Condition taken directly from decision table• No boundary conditions for Rate
2/2000 Unit Test Concepts 42
(3) Identify Boundary Points
• bc1 (Hrs <= 40) Boundary Points• Point 1: AT the boundary: Hours = 40• Point 2: Just INside: Hours = 39• Point 3: Just OUTside: Hours = 41
• Observations:• Inclusive inequalities have 3 boundary points
2/2000 Unit Test Concepts 43
(3a) BP Generalization
• bc: x > y has TWO boundary points• bp1: Just INside: x = y + precision• bp2: Just OUTside: x = y
• bc: x == y has THREE boundary points:• bp1: OUTlo: x = y - precision• bp2: OUThi: x = y + precision• bp3: AT: x = y
2/2000 Unit Test Concepts 44
(3b) BP Generalization
• bc x != y has THREE boundary points:• bp1: INlo: x = y - precision• bp2: INhi: x = y + precision• bp3: OUT: x = y
2/2000 Unit Test Concepts 45
(4) Generate Test Cases
• Combine Hours boundary points with Rate• Case 1 (AT): Hours = 40, Rate = 10, Pay=400• Case 2 (IN): Hours = 39, Rate = 10, Pay=390• Case 3: (OUT): Hours = 41, Rate=10, Pay=415
• Observations:• Test each boundary point individually• Then consider pair-wise boundary points
2/2000 Unit Test Concepts 46
(5) Update Test Script
StepStimuli Expected Response
Hours Rate Pay =12
3050 10
10 300550
3 40 10 4004 39 10 3905 41 10 415
2/2000 Unit Test Concepts 47
Your TurnBoundary Testing
c1: Age <= 12 | Y N N
c2: Age > 65 | Y N N
c3: Age > 80 | Y
c4: Weight > 300 | Y N N N N
c5: Weight > 120 | N Ya1: Pills = 0 | X X
a2: Pills = 1 | X
a3: Pills = 2 | X X
a4: Pills = 2+(W-120)/50 | X
Decision Table:
2/2000 Unit Test Concepts 48
Your Turn (2-3) Boundary Conditions/Points
Boundary Condition Boundary Point (BP)AT IN
bc1:OUT
bc2:bc3:bc4:
bc5:
2/2000 Unit Test Concepts 49
Your Turn(4) Generate Boundary Test Cases
• To create a test case, you must pair an Age with a Weight• Weight boundary point + NOMINAL Age• Age boundary point + NOMINAL Weight• OUT Age + OUT Weight
A nominal value is one that is not close to a boundary point. For simplicity, use the same nominal value in all test cases.
2/2000 Unit Test Concepts 50
Your Turn(4) Boundary-Nominal Test CasesCondition btc BC Weight Age Expect Weight>300 1 IN 301 21 0 2 OUT 300 21 Age <= 12 3 IN 220 11 4 AT 12 5 OUT 13 Age > 65 6 IN 7 OUT Age > 80 9 IN 10 OUT Weight>120 11 IN 12 OUT
2/2000 Unit Test Concepts 51
Your Turn(4) Out-Out Boundary Test Cases
Condition OUT BPWeight Age btc Weight Age Expect
>300 <=12 13
>65 14
>80 15
>120 <=12 16
>65 17 >80 18
2/2000 Unit Test Concepts 52
OBSERVATIONS
• Functional testing defines a minimal number of test cases
• Boundary testing adds a large number of test cases, but are EASY to create
• Boundary testing finds lots of errors!
2/2000 Unit Test Concepts 53
BOUNDARIES EXIST FOR
• Optional fields: (present, missing).• Variable length data: null string, max
length• Database tables: empty• Searching: first/last position• File: closed, empty
2/2000 Unit Test Concepts 54
Agenda
• More on Boundary Points & Values
• Automated Test Data Generation
• Boundary Testing Approach
• Test Set Reduction Strategies
2/2000 Unit Test Concepts 55
Tools for Boundary Testing
• Ref – MS thesis, Jermaine Stewart, 2006• Versions: BTDgen.run, BTDgenGUI.run• Unix invocation: % BTDgen • BTDgen: specification Boundary Test Sets
• Full cartesian product – high volume [btd_xxx.txt]• Reduced set (nominal values) [bnc_xxx.txt]
• Specification: var declarations + boundary conditions.
2/2000 Unit Test Concepts 56
Agenda
• More on Boundary Points & Values
• Automated Test Data Generation
• Boundary Testing Approach
• Test Set Reduction Strategies
2/2000 Unit Test Concepts 57
Boundary Test Set Reduction
• Cartesian product yields exponential size• Boundary-nominal yields linear size
• By-passes “masking” problem• Multiple boundaries not tested
• Combinatorial methods applied to each variable’s boundary value set.
2/2000 Unit Test Concepts 58
RANDOM TESTING
• Beyond scope of course (except for term project)
• Generally used to bombard software with inputs
• Usually no effort to identify expected results• Appropriate for automated load testing,
where concern is for capacity/volume.
2/2000 Unit Test Concepts 59
INTUITIVE (AD HOC) TESTING
• Most common type of informal testing• Often, no specification!!• No scripts• Not repeatable• Not systematic
• Very effective• Does not guarantee thorough testing
2/2000 Unit Test Concepts 60
INTUITIVE TESTING
• Ad hoc, exploratory testing, ideal for destructive testing• Goal is to break the software via unexpected
stimuli or sequences of stimuli• Benefits
• Flushes out holes in the specification .. What really should happen when the input is X?
• Forces treatment of error/exception handling
2/2000 Unit Test Concepts 61
MAIN POINTSBLACK-BOX TESTING
• Black-box = spec-based testing• Tests intentions• Key knowledge = stimuli and responses• Decision table organizes S/R conditions• Boundary testing flushes coding errors• Black-box test case design can drive
software design -- same issues addressed
2/2000 Unit Test Concepts 62
Agenda
• What is Unit Testing
• Black-Box Testing
• White-Box Testing
• Putting It All Together
2/2000 Unit Test Concepts 63
WHITE-BOX TESTING
SoftwareunderTest
Stimuli Response(s)
Testing to ensure that software does not do what is not supposed to do. Test ALL of it!
Tick -- Tick -- TickNo-Surprise Software!!
2/2000 Unit Test Concepts 64
WHITE-BOX TESTING
• Focus is thorough execution of program elements during the testing process.
• Warning: Tests only what is built, not what was intended!
SoftwareunderTest
Stimuli Response(s)
2/2000 Unit Test Concepts 65
WHITE-BOX TESTING
• Concept of coverage. Numeric measure of thoroughness of testing, relative to • Statements• Branches• Conditions• Paths
2/2000 Unit Test Concepts 66
CONTROL FLOW GRAPH
• Defines the flow of control through unit.
12 4
53
2/2000 Unit Test Concepts 67
CONTROL FLOW GRAPH TERMINOLOGY
• 5 NODES• sequential blocks of code
terminated by a branch• 3 PATHS:
• [1,2,3,5], [1,2,5], [1,4,5]• 2 BRANCHES
• 1 and 2 are decision nodes
12 4
53
2/2000 Unit Test Concepts 68
CONTROL FLOW GRAPH COVERAGE
• One test case forces execution of one path (red)
• Paths are determined by branches (decision nodes)
• A thorough test set forces execution of all paths (red, green, blue).
1
2 4
53
2/2000 Unit Test Concepts 69
COVERAGE LEVELS (%)
• Statement -- a statement has been executed at least once during testing
• Branch -- each outcome of a branch has been performed at least once during testing
• Path -- a path through the code has been executed at least once during during testing
• Condition -- a condition has evaluated to true and to false at least once during testing
2/2000 Unit Test Concepts 70
CONTROL FLOW GRAPH COVERAGE MEASUREMENT
• For 2 test cases (red, green)• Node (statement) cov = 4/5• Branch cov = 1/2 [2]• Path cov = 2/3
• Acceptable coverage levels• Statement cov = 90%• Branch cov = 80%• Path cov = 70%
1
2 4
53
2/2000 Unit Test Concepts 71
BRANCH vs CONDITION COVERAGE
• Code example 1
2 4
• 100% Branch coverage [1] • (x=0,y=2), (x=1,y=2) [TT,FT]
• But not 100% Condition coverage • Need case TF (x=0,y=1)
if (x<1 && y>1) x = x + y;else y = y - x;
2/2000 Unit Test Concepts 72
THE PROBLEM WITH COMPOUND CONDITIONS
• Makes complex logic appear simpler than it really is
• Test cases may be omitted• Logic results in 3 paths, not 2!!
12 3
if (x<1){if (y>1) x=x+y; else y=y-x;} else y=y-x;
12 5
3 4
2/2000 Unit Test Concepts 73
THE PROBLEM WITH PATH COVERAGE
• Not all paths are feasible• No test case can force path [1,2,3,4,5].
Consecutive decisions mutually exclusive.
if (x<1) y=2;if (x >= 1) y=3;z=y;
12
4
3
5
2/2000 Unit Test Concepts 74
Measuring Path Testing Difficulty
• McCabe metric -- logical code complexity • Formula: 1 + #decisions in control flow graph• Test Significance: #basis paths through code• Design use: complexity of code• Test use: min #test cases for 100% path coverage
• McCabe measures test (development) difficulty
2/2000 Unit Test Concepts 75
How To Design White Box Tests
• Test cases must execute different paths• Decision tables
• Rows -- elementary conditions in the code• Columns -- combinations of conditions in the code• Column based test case forces flow through
different logic paths in the code• Decision table built from code reflects what was
built versus intended (from spec)• Decision analysis for white-box testing.
2/2000 Unit Test Concepts 76
WHITE-BOX TESTING TOOLS
• Tools instrument source code and gathers coverage data when tests • Compiled languages• Script languages -- coming to market
• Some provide test case design assistance• List of paths not covered• Data conditions to force branch/path• Graphic depiction of graph coverage
2/2000 Unit Test Concepts 77
Problem P1Code (v1) & Decision Table
if (Age>80 || Weight>300) return 0; if (Age <= 12) return 1;if (Age > 65) return 2;if (Weight < 120) return 2else return 2+(Weight-120)/50;
Age>80 | Y N N N N N
Weight>300 | - Y N N N N
Age<=12 | Y N N N
Age>65 | Y N N
Weight<120 | Y N Pills = | 0 0 1 2 2 C
------------------------------
Note: C: 2+(Weight/120)/50
McCabe = 6
2/2000 Unit Test Concepts 78
Problem P1Code (v2) & Decision Table
if (Age>80 || Weight>300)return 0; if (Age <= 12) return 1;if (Age > 65 || (Age<=65 && Weight<120)) return 2;return 2+(Weight-120)/50;
Age>80 | Y N N N N N N
Weight>300 | - Y N N N N N
Age<=12 | Y N N N
Age>65 | Y N N
Weight<120 | - Y N Pills = | 0 0 0 1 2 2 C
McCabe = 7
2/2000 Unit Test Concepts 79
Your Turn -- White-Box Testing(1) Construct Decision Table
pills=0;if (Age < 80 && Weight <300){ pills=1; if (Age >= 65) pills=2; else if (Age > 12) pills=2+(Weight-120)/50;}return pills;
____________ |
____________ |
____________ |
____________ |
____________ |Pills = | - - - - - - -
---------------------------
Note: C: 2+(Weight/120)/50
2/2000 Unit Test Concepts 80
Your Turn -- P1(2) Derive White-Box Test Cases
Case 1 2 3 4 5 6 7 8 9
Age ___ ___ ___ ___ ___ ___ ___ ___ ___
Weight ___ ___ ___ ___ ___ ___ ___ ___ ___
Pills ___ ___ ___ ___ ___ ___ ___ ___ ___
2/2000 Unit Test Concepts 81
OBSERVATIONS -- WHITE-BOX TEST CASES
• Code may not be complete with respect to input combinations from the specification
• Decision table constructed from code is simpler -- subset of black-box table
• Claim: black-box test cases force coverage of logic• Unless the code implements the wrong (a
different) function
2/2000 Unit Test Concepts 82
MAIN POINTSWHITE-BOX TESTING
• White-box = logic testing• Limitation: can't tell what's missing• Don't forget exceptions -- throwing,
catching, propagating (debugger)• Perform decision analysis of code• Coverage tools help.• Use black-box test cases.
2/2000 Unit Test Concepts 83
Agenda
• What is Unit Testing
• Black-Box Testing
• White-Box Testing
• Putting It All Together
2/2000 Unit Test Concepts 84
PUTTING IT ALL TOGETHER
• Test design is a systematic process • whether you use decision tables or not, you
must understand the factors influencing and influenced by the behavior of the unit
• The sooner you design test cases, the better• Test design is more crucial than running tests• Reveals assumptions, omissions and errors
• Use test cases during design and coding
2/2000 Unit Test Concepts 85
PUTTING IT ALL TOGETHER
• It's okay to ask "What happens when …? • Look for test design patterns
• Expect certain type units to be tested in a similar way
• A way to identify best practices• Efficiency without cutting corners
• View test design as a "design product", not just a test product!!
2/2000 Unit Test Concepts 86
Functional/Boundary Testing Worksheets
• Stored in Domino• Master template
• Stimulus-Response Analysis• Decision Table• Functional Test Cases• Boundary Test Design
• Boundary Point Analysis• Boundary Test Cases
2/2000 Unit Test Concepts 87
SOLUTIONS TO EXERCISES
2/2000 Unit Test Concepts 88
Your Turn (Dosage Problem)(2a) Identify Behaviors
CaseExpected
Stimulus Description #Pills 123456
Any Age, Weight>300Age > 80, any WeightAge <= 12, Weight <= 300Age > 65, Weight <= 300Age 13-65, Weight 120-300Age 13-65, Weight < 120
0012
2+(W-120)/502
2/2000 Unit Test Concepts 89
Your Turn(2b) Decision Table #1
c1: Age <= 12 | Y Y N N N
c2: Age > 65 | Y Y N N N
c3: Age > 80 | Y Y
c4: Weight > 300 | N Y N Y N Y N N Y
c5: Weight > 120 | N Ya1: Pills = 0 | X X X X X
a2: Pills = 1 | X
a3: Pills = 2 | X X
a4: Pills = 2+(W-120)/50 | X
2/2000 Unit Test Concepts 90
Your Turn (2b) Decision Table #2
c1: Age <= 12 | Y N N
c2: Age > 65 | Y N N
c3: Age > 80 | Y
c4: Weight > 300 | Y N N N N
c5: Weight > 120 | N Ya1: Pills = 0 | X X
a2: Pills = 1 | X
a3: Pills = 2 | X X
a4: Pills = 2+(W-120)/50 | X
2/2000 Unit Test Concepts 91
Your Turn(3a) Create Test Cases (testset1)
Case 1 2 3 4 5 6 7 8 9
Age 8 12 67 67 81 85 15 28 28
Weight 40 305 180 360 120 315 100 220 320
Pills 1 0 2 0 0 0 2 4 0•Is more better? •Every combination of stimuli is tested. •Each column specifies at least one condition per variable
2/2000 Unit Test Concepts 92
Your Turn(3b) Create Test Cases (testset2)
Case 1 2 3 4 5 6 Age 20 10 70 83 13 30 Weight 310 70 160 150 115 220 Pills 0 1 2 0 2 4
•Is fewer better? •Not every combination of stimuli is tested. •Test case generation easier when each column specifies at least one condition per variable
2/2000 Unit Test Concepts 93
Your Turn(4) Write Test Script (testset1)
StepStimuli Pills=
Age123456
Weight StepStimuli Pills= Age
78910
12
Weight
11
8
12
678185
672828
15
315
120360180305 40 100
220320 0
4 2 1
0 2 0 0 0
2/2000 Unit Test Concepts 94
Your Turn(2) Identify Boundary Conditions
• Condition 1 (bc1): Age <= 12
• Condition 2 (bc2): Age > 65
• Condition 3 (bc3): Age > 80
• Condition 4 (bc4): Weight > 300
• Condition 5 (bc5): Weight > 120
2/2000 Unit Test Concepts 95
Your Turn(3) Identify Boundary Points
Boundary Condition Boundary PointAT IN
bc1: Age <= 12 OUT
bc2: Age > 65 bc3: Age > 80bc4: Weight > 300
bc5: Weight > 120
12 11 6681
301 121
13 65 80
300120
2/2000 Unit Test Concepts 96
Your Turn(4) Boundary-Nominal Test Cases
Condition btc BC Weight Age Expect Weight>300 1 IN 301 21 0 2 OUT 300 21 5 Weight>120 3 IN 121 21 2 4 OUT 120 21 2 Age <= 12 5 AT 220 12 1 6 IN 220 11 1 7 OUT 220 13 4 Age>65 8 IN 220 66 2 9 OUT 220 65 4 Age>80 10 IN 220 81 0 11 OUT 220 80 2
2/2000 Unit Test Concepts 97
Your Turn(4) Out-Out Boundary Test Cases
Condition OUT B-point
Weight Age btc Weight Age Expect >300 <=12 12 300 13 5
>65 13 300 65 5
>80 14 300 80 5
>120 <=12 15 120 13 2
>65 16 120 65 2
>80 17 120 80 2
2/2000 Unit Test Concepts 98
Your Turn -- White-Box Testing(1) Construct Decision Table
pills=0;if (Age < 80 && Weight <300){ pills=1; if (Age >= 65) pills=2; else if (Age > 12) pills=2+(Weight-120)/50;}return pills;
| Age < 80 | N - Y Y Y
| Weight<300 | - N Y Y Y
| Age >= 65 | N Y N
| Age > 12 | N - Y| Pills = | 0 0 1 2 C--------------
Note: C: 2+(Weight/120)/50
2/2000 Unit Test Concepts 99
Your Turn(2) Derive White-Box Test Cases
Case 1 2 3 4 5
Age 83 24 11 68 35
Weight 97 310 85 225 108
Pills 0 0 1 2 2| Age < 80 | N - Y Y Y
| Weight<300 | - N Y Y Y
| Age >= 65 | N Y N
| Age > 12 | N Y YPills = | 0 0 1 2 C