CIS 4932 Software Testing Unit Testing Concepts 22000
- Slides: 90
CIS 4932 Software Testing Unit Testing Concepts 2/2000 Unit Test Concepts
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 Unlimited 2 2/2000 Unit Test Concepts
Agenda • What is Unit Testing • Black-Box Testing • White-Box Testing • Putting It All Together 3 2/2000 Unit Test Concepts
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. 4 2/2000 Unit Test Concepts
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 5 2/2000 Unit Test Concepts
REQUIRED ELEMENTS OF A TESTING METHODOLOGY? • Specification for the software • Process for designing test cases • Repeatable process for designing, running and evaluating tests • Accountable artifacts of testing activities • Economical use of human, time and computing resources 6 2/2000 Unit Test Concepts
A TESTING LIFECYCLE Specification Analysis Test Strategy/Plan Design Test Cases Implementation Execution Test Results Evaluation Test Script, Data, Driver Defect Data Problem Reports 7 2/2000 Unit Test Concepts
Agenda • What is Unit Testing • Black-Box Testing • White-Box Testing • Putting It All Together 8 2/2000 Unit Test Concepts
BLACK-BOX TESTING Stimuli Software under Test Response(s) • Testing based on the specification rather than the implementation. • Specification defines the expected response(s) to stimuli 9 2/2000 Unit Test Concepts
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 • Intuitive (ad hoc) testing -- error guessing 10 2/2000 Unit Test Concepts
FUNCTIONAL TEST DESIGN METHODOLOGY • Specification • Identify behaviors • Develop test cases • Write test script 11 2/2000 Unit Test Concepts
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. Hours Rate Software under Test Pay 12 2/2000 Unit Test Concepts
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) 13 2/2000 Unit Test Concepts
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 14 2/2000 Unit Test Concepts
EXAMPLE A (4) Write Test Script Step 1 2 Stimuli Hours Rate 30 10 50 10 Expected Response Pay = 300 550 15 2/2000 Unit Test Concepts
A MORE COMPLEX EXAMPLE (B) • Increased number of behaviors • Use of decision table to document behaviors • Test case generation from decision table 16 2/2000 Unit Test Concepts
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. 17 2/2000 Unit Test Concepts
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 18 2/2000 Unit Test Concepts
DECISION TABLE Condition c 1: Rate < 30 | Y Y N N c 2: Hours <= 40 | Y N Action a 1: Pay = Straight time | X a 2: Pay = Overtime | a 3: Pay = Professional | X X X Columns define Behaviors 19 2/2000 Unit Test Concepts
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 20 2/2000 Unit Test Concepts
EXAMPLE B (4) Write Test Script Step 1 2 3 4 Stimuli Hours Rate 30 10 50 10 30 40 50 40 Expected Response Pay = 300 550 1600 21 2/2000 Unit Test Concepts
RULES -- DECISION TABLES Elementary conditions Condition c 1: Rate < 30 | Y Y N N c 2: Hours <= 40 | Y N Use 'Y', 'N', '-' or space Action a 1: Pay = Straight time | X a 2: Pay = Overtime | a 3: Pay = Professional | X X X Use X to select action(s) 22 2/2000 Unit Test Concepts
Your Turn -- Problem P 1 (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. 23 2/2000 Unit Test Concepts
Your Turn (2 a) Identify Behaviors Case 1 2 3 4 5 6 Stimulus Description Expected #Pills 24 2/2000 Unit Test Concepts
Your Turn (2 b) Decision Table c 1: Age <= 12 | c 2: Age > 65 | c 3: Age > 80 | c 4: Weight > 300 | c 5: Weight > 120 | a 1: Pills = 0 | a 2: Pills = 1 | a 3: Pills = 2 | a 4: Pills = 2+(W-120)/50 | 25 2/2000 Unit Test Concepts
Your Turn (3) Create Test Cases Case Age 1 2 3 4 5 6 7 8 9 ___ ___ ___ Weight ___ ___ ___ Pills ___ ___ ___ 26 2/2000 Unit Test Concepts
Your Turn (4) Write Test Script Step 1 2 3 4 5 6 Stimuli Pills= Age Weight Step 7 8 9 10 11 12 Stimuli Pills= Age Weight 27 2/2000 Unit Test Concepts
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. 28 2/2000 Unit Test Concepts
IDENTIFYING BEHAVIOR Approaches • Work backwards • Identify each response • Identify conditions that provoke response • Identify separate stimuli • Work forward • Identify stimuli • Identify how each stimulus influences what unit does • Specify the response 29 2/2000 Unit Test Concepts
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 30 2/2000 Unit Test Concepts
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 31 2/2000 Unit Test Concepts
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 32 2/2000 Unit Test Concepts
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 33 2/2000 Unit Test Concepts
A SKETCHING TOOL Black-Box Schematic Stimulus Type Response Type Argument Inputs Globals Argument Software under Test Outputs Globals Database Exception 34 2/2000 Unit Test Concepts
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 35
BOUNDARY TESTING DESIGN METHODOLOGY • Specification • Identify elementary boundary conditions • Identify boundary points • Generate boundary test cases • Update test script (add boundary cases). 36 2/2000 Unit Test Concepts
(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. Hours Rate Software under Test Pay 37 2/2000 Unit Test Concepts
(2) Identify Boundary Conditions • Condition 1 (bc 1): Hours <= 40 • Observations: • Condition taken directly from decision table 38 2/2000 Unit Test Concepts
(3) Identify Boundary Points • bc 1 Boundary Points • Point 1: AT the boundary: Hours = 40 • Point 2: Just INside: Hours = 39 • Point 3: Just OUTside: Hours = 41 • Observations: • The Hours value must be paired with Rate • Inclusive inequalities have 3 boundary points 39 2/2000 Unit Test Concepts
(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 40 2/2000 Unit Test Concepts
(5) Update Test Script Step 1 2 3 4 5 Stimuli Hours Rate 30 10 50 10 40 10 39 10 41 10 Expected Response Pay = 300 550 400 390 415 41 2/2000 Unit Test Concepts
Your Turn Boundary Testing Decision Table: c 1: Age <= 12 | c 2: Age > 65 | c 3: Age > 80 | c 4: Weight > 300 | Y N N c 5: Weight > 120 | N Y a 1: Pills = 0 | X a 2: Pills = 1 | a 3: Pills = 2 | a 4: Pills = 2+(W-120)/50 | Y N N Y X X X 42 2/2000 Unit Test Concepts
Your Turn (2 -3) Boundary Conditions/Points Boundary Condition Boundary Point (BP) AT IN OUT bc 1: bc 2: bc 3: bc 4: bc 5: 43 2/2000 Unit Test Concepts
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. 44 2/2000 Unit Test Concepts
Your Turn (4) Boundary-Nominal Test Cases Condition Weight>300 Age <= 12 Age > 65 Age > 80 Weight>120 btc BC 1 IN 301 21 2 OUT 300 21 3 IN 220 11 4 AT 12 5 OUT 13 6 IN 7 OUT 9 IN 10 OUT 11 IN 12 OUT Weight Age Expect 0 45 2/2000 Unit Test Concepts
Your Turn (4) Out-Out Boundary Test Cases Condition Weight Expect >300 >120 Age OUT BP btc <=12 13 >65 14 >80 15 <=12 16 >65 17 >80 18 Weight Age 46 2/2000 Unit Test Concepts
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! 47 2/2000 Unit Test Concepts
BOUNDARIES EXIST FOR • Optional fields: (present, missing). • Variable length data: null string, max length • Database tables: empty • Searching: first/last position • File: closed, empty 48 2/2000 Unit Test Concepts
RANDOM TESTING • Beyond scope of this course • Generally used to bombard software with inputs • No effort to identify expected results • Appropriate for automated load testing, where concern is for capacity/volume. 49 2/2000 Unit Test Concepts
INTUITIVE (AD HOC) TESTING • Most common type of informal testing • No scripts • Not repeatable • Not systematic • Very effective • Does not guarantee thorough testing 50 2/2000 Unit Test Concepts
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 51 2/2000 Unit Test Concepts
MAIN POINTS BLACK-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 52 2/2000 Unit Test Concepts
Agenda • What is Unit Testing • Black-Box Testing • White-Box Testing • Putting It All Together 53 2/2000 Unit Test Concepts
WHITE-BOX TESTING Stimuli Software under Test Response(s) Testing to ensure that software does not do what is not supposed to do. Test ALL of it! No-Surprise Tick -- Tick. Software!! -- Tick 54 2/2000 Unit Test Concepts
WHITE-BOX TESTING Stimuli Software under Test Response(s) • Focus is thorough execution of program elements during the testing process. • Warning: Tests only what is built, not what was intended! 55 2/2000 Unit Test Concepts
WHITE-BOX TESTING • Concept of coverage. Numeric measure of thoroughness of testing, relative to • Statements • Branches • Conditions • Paths 56 2/2000 Unit Test Concepts
CONTROL FLOW GRAPH • Defines the flow of control through unit. 1 2 4 3 5 57 2/2000 Unit Test Concepts
CONTROL FLOW GRAPH TERMINOLOGY • 5 NODES 1 • sequential blocks of code terminated by a branch • 3 PATHS: 2 4 3 • [1, 2, 3, 5], [1, 2, 5], [1, 4, 5] 5 • 2 BRANCHES • 1 and 2 are decision nodes 58 2/2000 Unit Test Concepts
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 3 5 59 2/2000 Unit Test Concepts
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 testing • Condition -- a condition has evaluated to true and to false at least once during testing 60 2/2000 Unit Test Concepts
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 1 2 4 3 5 • Statement cov = 90% • Branch cov = 80% • Path cov = 70% 61 2/2000 Unit Test Concepts
BRANCH vs CONDITION COVERAGE • Code example 1 if (x<1 && y>1) x = x + y; else y = y - x; 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) 62 2/2000 Unit Test Concepts
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!! if (x<1) {if (y>1) x=x+y; else y=y-x; } else y=y-x; 1 2 3 5 4 63 2/2000 Unit Test Concepts
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; 1 2 3 4 5 64 2/2000 Unit Test Concepts
Measuring Path Testing Difficulty • Mc. Cabe 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 • Mc. Cabe measures test (development) difficulty 65 2/2000 Unit Test Concepts
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. 66 2/2000 Unit Test Concepts
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 67 2/2000 Unit Test Concepts
Problem P 1 Code (v 1) & Decision Table Age>80 | Y N N N if (Age>80 || Weight>300 | - Y N N Weight>300) Age<=12 | Y N N N return 0; Age>65 | Y N N if (Age <= 12) return 1; Weight<120 | Y N if (Age > 65) Pills = | 0 0 1 2 2 C return 2; ---------------if (Weight < 120) return 2 Note: C: 2+(Weight/120)/50 else return 2+(Weight-120)/50; Mc. Cabe = 6 68 2/2000 Unit Test Concepts
Problem P 1 Code (v 2) & Decision Table Age>80 | Y N N N Weight>300 | - Y N N N if (Age>80 || Age<=12 | Y N N N Weight>300) Age>65 | Y N N return 0; if (Age <= 12) Weight<120 | - Y N return 1; Pills = | 0 0 0 1 2 2 C if (Age > 65 || (Age<=65 && Weight<120)) return 2; return 2+(Weight-120)/50; Mc. Cabe = 7 69 2/2000 Unit Test Concepts
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 70 2/2000 Unit Test Concepts
Your Turn -- P 1 (2) Derive White-Box Test Cases Case Age 1 2 3 4 5 6 7 8 9 ___ ___ ___ Weight ___ ___ ___ Pills ___ ___ ___ 71 2/2000 Unit Test Concepts
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 72 2/2000 Unit Test Concepts
MAIN POINTS WHITE-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. 73 2/2000 Unit Test Concepts
Agenda • What is Unit Testing • Black-Box Testing • White-Box Testing • Putting It All Together 74 2/2000 Unit Test Concepts
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 75 2/2000 Unit Test Concepts
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!! 76 2/2000 Unit Test Concepts
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 77 2/2000 Unit Test Concepts
SOLUTIONS TO EXERCISES 78 2/2000 Unit Test Concepts
Your Turn (Dosage Problem) (2 a) Identify Behaviors Case 1 2 3 4 5 6 Stimulus Description Any Age, Weight>300 Age > 80, any Weight Age <= 12, Weight <= 300 Age > 65, Weight <= 300 Age 13 -65, Weight 120 -300 Age 13 -65, Weight < 120 Expected #Pills 0 0 1 2 2+(W-120)/50 2 79 2/2000 Unit Test Concepts
Your Turn (2 b) Decision Table #1 c 1: Age <= 12 | Y Y c 2: Age > 65 | c 3: Age > 80 | c 4: Weight > 300 | N Y N Y N N Y c 5: Weight > 120 | a 1: Pills = 0 | a 2: Pills = 1 | X a 3: Pills = 2 | a 4: Pills = 2+(W-120)/50 | N N N Y Y N Y X X X X 80 2/2000 Unit Test Concepts
Your Turn (2 b) Decision Table #2 c 1: Age <= 12 | c 2: Age > 65 | c 3: Age > 80 | c 4: Weight > 300 | Y N N c 5: Weight > 120 | N Y a 1: Pills = 0 | X a 2: Pills = 1 | a 3: Pills = 2 | a 4: Pills = 2+(W-120)/50 | Y N N Y X X X 81 2/2000 Unit Test Concepts
Your Turn (3 a) Create Test Cases (testset 1) Case 1 2 3 4 5 6 7 8 9 Age 8 12 67 67 81 85 15 28 28 Weight Pills 40 305 180 360 120 315 100 220 320 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 variabl 82 2/2000 Unit Test Concepts
Your Turn (3 b) Create Test Cases (testset 2) Case 1 2 3 4 5 6 Age 20 10 70 83 13 30 Weight 310 Pills 0 70 160 150 115 220 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 83 2/2000 Unit Test Concepts
Your Turn (4) Write Test Script (testset 1) Step 1 Stimuli Pills= Age Weight 8 40 1 2 3 4 5 12 67 67 81 305 180 360 120 0 2 0 0 6 85 315 0 Step 7 8 9 10 Stimuli Pills= Age Weight 15 100 2 28 28 220 320 4 0 11 12 84 2/2000 Unit Test Concepts
Your Turn (2) Identify Boundary Conditions • Condition 1 (bc 1): Age <= 12 • Condition 2 (bc 2): Age > 65 • Condition 3 (bc 3): Age > 80 • Condition 4 (bc 4): Weight > 300 • Condition 5 (bc 5): Weight > 120 85 2/2000 Unit Test Concepts
Your Turn (3) Identify Boundary Points Boundary Condition bc 1: Age <= 12 bc 2: Age > 65 bc 3: Age > 80 bc 4: Weight > 300 AT 12 Boundary Point IN 11 66 81 OUT 13 65 80 301 121 300 120 bc 5: Weight > 120 86 2/2000 Unit Test Concepts
Your Turn (4) Boundary-Nominal Test Cases Condition Weight>300 Weight>120 Age <= 12 Age>65 Age>80 btc BC Weight Age Expect 1 IN 301 21 0 2 OUT 300 21 5 3 IN 121 21 2 4 OUT 120 21 2 5 AT 220 12 1 6 IN 220 11 1 7 OUT 220 13 4 8 IN 220 66 2 9 OUT 220 65 4 10 IN 220 81 0 11 OUT 220 80 2 87 2/2000 Unit Test Concepts
Your Turn (4) Out-Out Boundary Test Cases Condition Weight >300 >120 OUT B-point Age btc Weight Age Expect <=12 12 300 13 5 >65 13 300 65 5 >80 14 300 80 5 <=12 15 120 13 2 >65 16 120 65 2 >80 17 120 80 2 88 2/2000 Unit Test Concepts
Your Turn -- White-Box Testing (1) Construct Decision Table | Age < 80 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; | 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 89 2/2000 Unit Test Concepts
Your Turn (2) Derive White-Box Test Cases Case 1 2 3 4 5 Age 83 24 11 68 35 Weight 97 310 Pills | Age < 80 0 0 85 225 108 1 2 2 | N - Y Y Y | Weight<300 | - N Y Y Y | Age >= 65 | N Y N | Age > 12 Pills = | N Y Y | 0 0 1 2 C 90 2/2000 Unit Test Concepts
- Bug report sample
- Advanced software testing concepts
- Iso 22000 rådgivning
- Iso 9000 iso 22000
- Apresia 13200
- 22000-tools.com
- Sandvine pts 22000
- Iso 22000 fsms 2005
- Fssc 22000 decision tree
- Tanovi
- Iso 22000
- Benefits of iso 22000 to the food industry
- Cac/rcp 1-1969
- Domain testing example
- Motivational overview of logic based testing
- Data flow testing strategies in software testing
- Globalization testing example
- Decision table testing in software testing
- Control structure testing in software engineering
- Decision table testing in software testing
- Decision table testing examples
- Limited entry decision table
- Rigorous testing in software testing
- Testing blindness in software testing
- Domain testing in software testing
- Functional testing vs unit testing
- Module testing in software engineering
- Embedded software unit testing
- Unit 10, unit 10 review tests, unit 10 general test
- Meme about concepts in hypothesis testing
- Design concepts in software engineering
- Dasar dasar rpl
- System software concepts
- Software design concept
- System software concepts
- Apush unit 2 key concepts
- Ap macro unit 1 basic economic concepts
- Unit 1: basic economic concepts answer key
- Ssef price list
- Unit 1 basic economic concepts
- Positive and negative testing
- Static testing and dynamic testing
- Blackbox testing
- Behavior testing adalah
- Component testing is a black box testing
- State state graphs and transition testing
- Path sensitizing in software testing
- Consequences of bugs in stm
- Linda shafer
- Online test delivery system
- Next date function in software testing
- Software testing subject code
- Software testing subject code
- Software testing subject code
- Dr. samer hanna
- What is software testing definition
- Software implementation of state graph
- Testing process
- Software testing valadares
- User testing software engineering
- Types of testing in software engineering
- Interface testing in software engineering
- Workbench concept in software testing
- User testing software engineering
- Testing activities in software engineering
- Rapid software testing
- Edge-pair coverage
- Offshore vendor management best practices
- What is this
- Cluster testing in software engineering
- Cyclomatic complexity example
- Advanced topics in software engineering
- Domain error in software testing
- Test summary report template
- Software testing objectives
- Testing types in software engineering
- Big bang software testing
- Taxanomy of bugs
- Test lll
- Software testing
- Process of finding errors in software code
- Quality assurance theory
- The quality revolution
- Sommerville 2007
- Cfg in software testing
- Chapter 8 software testing
- Computer aided software testing
- Basis path testing
- Foundations of software testing aditya p mathur pdf
- What is regression testing in software engineering
- A good srs should be