CEN Software V & V Unit Testing Concepts

CEN 5070 - Software V & V Unit Testing Concepts
2/2000 CEN Software V & V Unit Testing Concepts 1) Welcome to session #1 Unit Test CONCEPTS 2) A few administrative matters 1. Sign in -- the sheet is circulating 2. Attend each session 3. You will be asked to complete a course evaluation at the end of Session #3. 3) How many of you are Test: [ ] Lead [ ] Analyst [ ] Coordinator Development A&D Now, open your notebook. 1. Read the welcome page 2. Turn to Tab1 This session takes around 2.5 hours. Handouts -- Unit Test Concepts

2/2000 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. SYSTEMATIC testing = not too much, not too little FOCUS is DESIGN OF 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/2000 Unit Test Concepts Handouts -- Unit Test Concepts 5

Agenda What Is Unit Testing Black-Box Testing White-Box Testing
2/2000 Agenda What Is Unit Testing Black-Box Testing White-Box Testing The session is broken into these topics, with major emphasis on the second and third. Putting It All Together 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts 5

2/2000 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. TESTING implies EXECUTING software or INSPECTIING software The intent of testing is TO FIND ERRORS!! A unit is the smallest software element that will be separately tested. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

WHAT IS A UNIT? Named software element Separately invokable
2/2000 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 ELEMENTARY UNITS have these properties. The main property is that is can be INVOKED SEPARATELY -- so it can be isolated for the purpose of testing. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

SPRAE: A Model for Testing Practice
2/2000 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 The practice of software testing should adhere to these five principles. 1. Testing without a specification is invalid -- the specification defines "correct behavior" 2. A systematic, consistent process must be used to design test cases. 3. The overall testing process must be repeatable -- results must be independent of the tester. 4. Testing must produce evidence showing what was attempted, the results of testing, and how the results were interpreted. 5. Testing practice must be realistic in terms of time and labor required. The focus of this session is a REPEATABLE PROCESS for TEST CASE DESIGN. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

A TESTING LIFECYCLE Analysis Design Implementation Execution
2/2000 A TESTING LIFECYCLE Specification Analysis Test Strategy/Plan Design Test Cases Implementation Test Script, Data, Driver Just as there is a lifecycle for software development, there is one for testing. 1. ANALYSIS -- Given the specification, determine a test strategy (and/or plan). 2. DESIGN -- Given the specification and strategy, apply techniques to derive test cases. 3. IMPLEMENTATION -- Build the machinery necessary to execute the tests, including data and manual scripts or automated scripts (drivers). 4. EXECUTION -- Perform the tests according to the script/driver, and capture results. 5. EVALUATION -- Evaluate test results to classify errors found, and record deficiencies. Execution Test Results Defect Data Problem Reports Evaluation 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Agenda What is Unit Testing Black-Box Testing White-Box Testing
2/2000 Agenda What is Unit Testing Black-Box Testing White-Box Testing In this section we focus on black-box testing, which relies on the specification rather than the implementation. Putting It All Together 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts 5

2/2000 BLACK-BOX TESTING Software under Test Stimuli Response(s) Testing based on the specification rather than the implementation. Specification defines the expected response(s) to stimuli The emphasis of black-box test case design is in gaining a COMPLETE UNDERSTANDING of the the data and conditions affecting the externally visible behavior of the software. In engineering, a black-box analysis is really an analysis of a system's RESPONSES to various input combinations (STIMULI). The relationships between stimuli and responses should be stated in the SPECIFICATION, or the specification must be modified to make those relationships explicit. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 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 There are four black-box testing techniques. We will focus on SYSTEMATIC techniques for functional and boundary testing. INTUITIVE testing is non-systematic, but relies upon the tester's intuition about where errors may exist. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BLACK-BOX TECHNIQUES Fuzz Testing
2/2000 BLACK-BOX TECHNIQUES Fuzz 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, There are four black-box testing techniques. We will focus on SYSTEMATIC techniques for functional and boundary testing. INTUITIVE testing is non-systematic, but relies upon the tester's intuition about where errors may exist. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BLACK-BOX TECHNIQUES Category Partitioning
2/2000 BLACK-BOX TECHNIQUES Category 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 CPM_paper.pdf There are four black-box testing techniques. We will focus on SYSTEMATIC techniques for functional and boundary testing. INTUITIVE testing is non-systematic, but relies upon the tester's intuition about where errors may exist. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BLACK-BOX TECHNIQUES Equivalence Partitioning
2/2000 BLACK-BOX TECHNIQUES Equivalence Partitioning Domain testing approach – input (domain) or output (range) 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. There are four black-box testing techniques. We will focus on SYSTEMATIC techniques for functional and boundary testing. INTUITIVE testing is non-systematic, but relies upon the tester's intuition about where errors may exist. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

FUNCTIONAL TEST DESIGN METHODOLOGY
2/2000 FUNCTIONAL TEST DESIGN METHODOLOGY Specification Identify behaviors Develop test cases Write test script The process for designing functional test cases starts with the specification. The STIMULUS / RESPONSE behaviors are derived from the specification. Next, a systematic process is applied to derive test cases from the behaviors. Finally, the test cases are recorded in a test script (or driver), so they can be executed during testing. NOTE: This course does NOT treat the EXECUTION and EVALUATION phases of the test lifecycle. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE A (1) Specification
2/2000 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. The diagram, a BLACK-BOX SCHEMATIC, communicates information about the unit under test: 1. TWO input arguments, Hours and Rate 2. ONE output result, Pay The narrative specification, which is used to construct the schematic, contains explicit or implicit statement of the relationship between stimuli (Hours, Rate) and response (Pay). Software under Test Hours Pay Rate 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE A (2) Identify Behaviors
2/2000 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) There are TWO WAYS TO CALCULATE PAY: 1. Overtime pay formula for over 40 hours 2. Straight pay formula for 40 hours or less That is, to the outside observer, Pay has two BEHAVIORS, one when Pay is just the product of in the arguments (Hours * Rate), and another formula is used Hours > 40. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE A (3) Create Test Cases
2/2000 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 1. The function of Pay is tested only WHEN EACH BEHAVIOR is tested. So two cases are adequate for testing the function of Pay. NOTE: Note the behavior of Pay is the same for Hours = 10, 20, 30 and 40, since in all these cases Hours <= 40, the condition for BEHAVIOR #1. These values of Hours are EQUIVALENT in that they induce the SAME BEHAVIOR from Pay. The set of Hours <= 40 is called an Equivalence Class. Testing by picking ONE VALUE from an equivalence class is called EQUIVALENCE PARTITIONING TESTING 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE A (4) Write Test Script
2/2000 EXAMPLE A (4) Write Test Script Step Stimuli Expected Response Hours Rate Pay = 1 2 30 50 10 300 550 1) The term TEST SCRIPT is used in a generic sense to mean a SEQUENCE OF TEST CASES to be executed at some later time. Additionally, the script specifies: a) Steps to set up for test case execution b) Steps to VERIFY that the actual results match those expected. 2) NOTE: Each test case includes the expected response. 3) Test scripts are written records of the INTENT TO TEST, and are usually stored electronically. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

A MORE COMPLEX EXAMPLE (B)
2/2000 A MORE COMPLEX EXAMPLE (B) Increased number of behaviors Use of decision table to document behaviors Test case generation from decision table The previous example is very simple. By now, you should feel comfortable with analyzing the behaviors of a function. We will introduce DECISION TABLES as tools to help you organize your analysis of a unit's behaviors. We will also see that once a decision table has been created, there is a straightforward way to generate test cases from the table. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE B (1) Specification
2/2000 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. The one change to the specification is the introduction of a salaried employee who does not get paid overtime or straight time, but for exactly 40 hours. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE B (2) Identify Behaviors
2/2000 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 Analysis of the specification identifies three behaviors, TWO for hourly employees, and ONE for salaried. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

DECISION TABLE Columns define Behaviors Condition
2/2000 DECISION TABLE Condition c1: Rate < | Y Y N N c2: Hours <= | Y N Y N Action a1: Pay = Straight time | X a2: Pay = Overtime | X a3: Pay = Professional | X X We can use a decision table to organize our analysis. 1. The TOP (CONDITION) part of the table addresses the conditions that define the behaviors. 2. The BOTTOM (ACTION) part of the table identifies the different formulas (actions) taken by the unit, based on COMBINATIONS of conditions. NOTE: 1. More than one action may be taken for a combination of conditions 2. Distinct condition combinations may result in the same action(s) being taken. Columns define Behaviors 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE B (3) Create Test Cases
2/2000 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 Given the decision table, the rule is: GENERATE ONE TEST CASE FOR EACH COLUMN. That is, each column defines a FUNCTIONAL EQUIVALENCE CLASS. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

EXAMPLE B (4) Write Test Script
2/2000 EXAMPLE B (4) Write Test Script Step Stimuli Expected Response Hours Rate Pay = 1 2 30 50 10 300 550 3 40 1600 4 Record the test cases in the test script, entering the cases in the same order as the COLUMNS of the decision table. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

RULES -- DECISION TABLES
2/2000 RULES -- DECISION TABLES Elementary conditions Condition c1: Rate < | Y Y N N c2: Hours <= | Y N Y N Action a1: Pay = Straight time | X a2: Pay = Overtime | X a3: Pay = Professional | X X Use 'Y', 'N', '-' or space Here are some rules regarding the construction of decision tables. 1. Conditions must be ELEMENTARY -- they can not contain logical operators AND or OR. 2. In a column defining condition combinations, use the letters Y or N, or the dash, or space. 3. In the ACTION section, mark actions for a condition combination using the letter X or space. NOTE: The table can be stored in ASCII form in a text document, or in text form in a WORD document using a font like Courier or Arial, or hand-written. Use X to select action(s) 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn -- Problem P1 (1) Specification
2/2000 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. You will find worksheets for this exercise in the Handouts section (Tab4) of your notebook. Please organize into groups of AT MOST 4. You have 15 minutes. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (2a) Identify Behaviors
2/2000 Your Turn (2a) Identify Behaviors Expected Case Stimulus Description #Pills 1 2 3 Consider doing an informal analysis WITHOUT DECISION TABLE. I expect you will find that the decision table helps you better keep track of the combinations. 4 5 6 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (3) Create Test Cases
2/2000 Your Turn (3) Create Test Cases Case Age ___ ___ ___ ___ ___ ___ ___ ___ ___ Weight ___ ___ ___ ___ ___ ___ ___ ___ ___ Pills ___ ___ ___ ___ ___ ___ ___ ___ ___ This is a short form for recording test cases. Remember to create ONE FOR EACH COLUMN of the decision table. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (4) Write Test Script
2/2000 Your Turn (4) Write Test Script Step Stimuli Pills= Age 1 2 3 4 5 6 Weight Stimuli Pills= Step Age Weight 7 8 9 If you completed the previous worksheet, you may skip this one. This sheet reminds you that the test cases must be "packaged" for execution at some later time. 10 11 12 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 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. The value of the decision table may not become clear until you are faced with a very complex unit with many conditions and combinations of conditions. The examples we have seen so far have simple stimuli and responses, corresponding to arguments passed and values returned by the function. In general, a surprising amount of effort may have to go into identifying all stimuli and responses. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

IDENTIFYING BEHAVIOR Approaches
2/2000 IDENTIFYING BEHAVIOR Approaches 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 Identifying behavior means identifying all stimuli and all responses, AND relating responses to stimuli. 1. Start with responses, then identify situations that cause each combination of responses, then identify individual stimuli. 2. OR start by identifying stimuli, then identify combinations of stimuli that cause different behavior, then identify each response. EXPECT TO COMBINE THESE APPROACHES 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

IDENTIFYING STIMULI Arguments passed upon invocation
2/2000 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 ENLARGE your view of the TYPES of STIMULI: 1. For units, the most common types are arguments passed when the unit is called. 2. Interactive inputs (keyboard or mouse) 3. Internal data such as global variables my be used to control a unit or to alter a value calculated by the unit 4. External data from files or databases, including the FILE STATUS (end-of-file, access errors, etc). 5. The occurrence of exceptions may alter the behavior of a unit. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

IT PAYS TO BE A GOOD STIMULUS DETECTIVE
2/2000 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 STIMULI define TEST CASE DATA When a stimulus is missed, that aspect of the unit's behavior can never be tested. The process of finding out what the stimuli are stimulates discussion and clarification of the interfaces to the unit. Such questioning is likely to reveal an incomplete design. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

IDENTIFYING RESPONSES
2/2000 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 The types of RESPONSES are the same as the types of STIMULI. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

IT PAYS TO BE A GOOD RESPONSE DETECTIVE
2/2000 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 RESPONSES define EXPECTED RESULTS for test cases. 1. Incomplete set of responses --> Incomplete and erroneous verification. 2. Responses are not always visible -- effects may show up later on, for example: - Failure to initialize variable Sum to zero leads to overflow after adding 30 values. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

A SKETCHING TOOL Black-Box Schematic
2/2000 A SKETCHING TOOL Black-Box Schematic Stimulus Type Response Type Argument Argument Inputs Outputs Software under Test Globals Globals Again we see the schematic template which lists the types of Stimuli and Responses. When analyzing behavior, question whether there are stimuli (responses) of each type. If so, list them by name (or description). RECALL: Stimuli tend to be used in the CONDITION part of the Decision Table. Responses appear in the ACTION part, along with those stimuli that provide values used in the computation of a response. Database Database Exception Exception 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BEFORE CONTINUTING One Stone for Two Birds!!
2/2000 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!! 1. A Decision Table is a SPECIFCIATION. 2. The specification is used for DESIGN AND FOR TESTING. 3. Killing TWO BIRDS with ONE STONE! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BOUNDARY TESTING DESIGN METHODOLOGY
2/2000 BOUNDARY TESTING DESIGN METHODOLOGY Specification Identify elementary boundary conditions Identify boundary points Generate boundary test cases Update test script (add boundary cases). We now show you a way to derive boundary test cases from the specification. The approach is 1. Analyze specification to identify behaviors. 2. From the decision table CONDITION section, identify boundary conditions. 3. For each boundary condition, derive boundary points. 4. Generate boundary test cases from the boundary points. 5. Add the boundary test cases to the functional test cases already in the test script. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 (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. Given this specification, we determine potential boundary conditions. Software under Test Hours Pay Rate 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

(2) Identify Boundary Conditions
2/2000 (2) Identify Boundary Conditions Condition 1 (bc1): Hours <= 40 Observations: Condition taken directly from decision table No boundary conditions for Rate There is just one -- relating to the OVERTIME criterion. NOTE: Boundary conditions are the condition rows in the decision table. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

(3) Identify Boundary Points
2/2000 (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 A boundary point is a value as close as possible to the boundary stated by the decision table condition. How close a boundary point can be to the boundary depends on the PRECISION of the value. Example: when Hours are recorded down to 1/10 of an hour: IN = just inside, Hours = = 39.9 OUT = just outside, Hours = = 40.1 NOTE: a) For strict inequality, there is NO AT, and the value stated is OUT! b) SURPRISE: For strict EQUALITY, there is AT and TWO OUTS, outHI and outLO! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

(3a) BP Generalization bc: x > y has TWO boundary points
2/2000 (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 A boundary point is a value as close as possible to the boundary stated by the decision table condition. How close a boundary point can be to the boundary depends on the PRECISION of the value. Example: when Hours are recorded down to 1/10 of an hour: IN = just inside, Hours = = 39.9 OUT = just outside, Hours = = 40.1 NOTE: a) For strict inequality, there is NO AT, and the value stated is OUT! b) SURPRISE: For strict EQUALITY, there is AT and TWO OUTS, outHI and outLO! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

(3b) BP Generalization bc x != y has THREE boundary points:
2/2000 (3b) BP Generalization bc x != y has THREE boundary points: bp1: INlo: x = y - precision bp2: INhi: x = y + precision bp3: OUT: x = y A boundary point is a value as close as possible to the boundary stated by the decision table condition. How close a boundary point can be to the boundary depends on the PRECISION of the value. Example: when Hours are recorded down to 1/10 of an hour: IN = just inside, Hours = = 39.9 OUT = just outside, Hours = = 40.1 NOTE: a) For strict inequality, there is NO AT, and the value stated is OUT! b) SURPRISE: For strict EQUALITY, there is AT and TWO OUTS, outHI and outLO! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

(4) Generate Test Cases Combine Hours boundary points with Rate
2/2000 (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 RECALL that a test case is a PAIR of a RATE value with an HOURS value. 1. Hold Rate CONSTANT at a NOMINAL (not near a boundary) value, and pair it with each of the HOURS boundary values. 2. This provides an ISOLATED boundary test on HOURS, without possible interference with boundary values of RATE (if any). 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

(5) Update Test Script Stimuli Expected Response Step Hours Rate Pay =
2/2000 (5) Update Test Script Stimuli Expected Response Step Hours Rate Pay = 1 30 10 300 2 50 10 550 3 40 10 400 We have added THREE boundary test cases. In general, each boundary condition has 2 or 3 boundary points, each of which must be used in a boundary test case. When the number of conditions grows, so can the number of boundary points, hence test cases! 4 39 10 390 5 41 10 415 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn Boundary Testing
2/2000 Your Turn Boundary Testing Decision Table: c1: Age <= | Y N N c2: Age > | Y N N c3: Age > | Y c4: Weight > | Y N N N N c5: Weight > | N Y a1: Pills = | X X a2: Pills = | X a3: Pills = | X X a4: Pills = 2+(W-120)/50 | X It is now your turn to apply the technique to the DOSAGE calculation from the last session. Use the decision table shown as the starting point. This will take 10 minutes. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (2-3) Boundary Conditions/Points
2/2000 Your Turn (2-3) Boundary Conditions/Points Boundary Point (BP) Boundary Condition AT IN OUT bc1: bc2: bc3: 1) Extract boundary conditions from the decision table, in the order they appear in the decision table. 2) For each boundary condition, DERIVE boundary points. bc4: bc5: 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (4) Generate Boundary Test Cases
2/2000 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 Begin by testing boundary handling on one variable at a time. Next create test cases that pair OUT values of multiple variables. Suggested NOMINAL values: AGE = 21 WEIGHT = 220 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 Handouts -- Unit Test Concepts

Your Turn (4) Boundary-Nominal Test Cases
2/2000 Your Turn (4) Boundary-Nominal Test Cases Condition btc BC Weight Age Expect Weight> IN 2 OUT Age <= IN 4 AT 5 OUT Age > IN 7 OUT Age > IN 10 OUT Weight> IN 12 OUT Note the nominal values in red. We have already tested the function of the unit, so using the same nominal value each time a nominal value is required does not reduce the strength of the test, but does simplify determining the expected results. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (4) Out-Out Boundary Test Cases
2/2000 Your Turn (4) Out-Out Boundary Test Cases Condition OUT BP Weight Age btc Weight Age Expect > <= > > > <= > > These test cases exercise the handling of multiple variables being out of bounds at the same time RELATIVE TO THE BOUNDARY CONDITIONS. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

OBSERVATIONS Functional testing defines a minimal number of test cases
2/2000 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! 1. Functional testing is a form of EQUIVALENCE PARTITIONING testing that has the goal of a minimum number of (POSITIVE) test cases that cover the functionality (behaviors) of the unit. 2. Boundary testing generates far more test cases … 3. But they're worth it: Boundary testing is especially effective in finding coding errors. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BOUNDARIES EXIST FOR Optional fields: (present, missing).
2/2000 BOUNDARIES EXIST FOR Optional fields: (present, missing). Variable length data: null string, max length Database tables: empty Searching: first/last position File: closed, empty Boundaries exist for situations that do not appear to be NUMERIC. - Any time there is a LIMIT, there are boundary points - Any time there is a notion of READY or NOT-READY, there are boundary points - Any time there is notion of ORDER, ARRANGEMENT or SORTEDNESS, there are boundary points based on the POSITION of an element in this collection 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

RANDOM TESTING Beyond scope of course (except for term project)
2/2000 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. (OPTIONAL) Random testing ignores the semantics of the inputs, and just churns out lots of values that fall within the range. Unless smart algorithms are used, random testing may produce lots of test cases that fall within the same equivalence partitions -- redundant test cases! There are situations, such as load or performance testing, where volume of data is more important than the meaning of the data. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

INTUITIVE (AD HOC) TESTING
2/2000 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 INTUITIVE TESTING is based on experience or "gut feel" about where errors may be. When all else fails, this is an effective technique … but may have serious GAPS in the coverage of function, boundaries, and amount of the code that is exercised during the testing process. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Forces treatment of error/exception handling
2/2000 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 A benefit of intuitive testing is that it permits destructive (NEGATIVE) testing without the need to document ahead of time what the test cases will be. The "chimpanzee at the keyboard" approach forces discussion of responding to UNEXPECTED USAGE. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

MAIN POINTS BLACK-BOX TESTING
2/2000 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 MAJOR POINTS: 1. Black-Box testing focuses on ensuring the software meets its specification. 2. Test case design is likely to result in the REFINEMENT OF THE SPECIFICATION. 3. The decision table is an intermediate specification useful for designing and testing. 4. Unit test design and software design are FLIP SIDES of the SAME COIN. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 Agenda What is Unit Testing Black-Box Testing White-Box Testing We are now ready to discuss another approach to unit testing that focuses on HOW THE unit is BUILT rather than the specification. Putting It All Together 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts 5

WHITE-BOX TESTING Tick -- Tick -- Tick No-Surprise Software!!
2/2000 WHITE-BOX TESTING Software under Test Stimuli Response(s) Testing to ensure that software does not do what is not supposed to do. Test ALL of it! White-Box Testing is an UNDER-THE-HOOD testing approach. The goal is to ensure that the software does not contain a TICKING BOMB waiting to go off unexpectedly. Tick -- Tick -- Tick No-Surprise Software!! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 WHITE-BOX TESTING Software under Test Stimuli Response(s) Focus is thorough execution of program elements during the testing process. Warning: Tests only what is built, not what was intended! The one way to ensure that there is no ticking time bomb is to execute all the code under all the possible circumstances -- to see how the code responds. WARNING: Success in white-box testing is measured in terms of how thoroughly the code was executed -- EVEN IF IT'S THE WRONG CODE! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 WHITE-BOX TESTING Concept of coverage. Numeric measure of thoroughness of testing, relative to Statements Branches Conditions Paths 1) White-box testing can be MEASURED. 2) The granularity of the measurement is defined in terms of code elements a) Statements (or blocks) b) Branches caused by decision statements (if, loops, switches) c) Conditions used to make decisions d) Execution paths through the code 3) COVERAGE is the numeric measure -- a percentage of the countable code elements 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

CONTROL FLOW GRAPH Defines the flow of control through unit. 1 2 4 3 5
2/2000 CONTROL FLOW GRAPH Defines the flow of control through unit. 1 2 4 3 The execution of a unit can be described by a graph that depicts the FLOW OF CONTROL through elements of the code. Drawing this graph IS NOT REQUIRED (whew!), but the graph explains the important relationship between code complexity and testing difficulty. 5 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

CONTROL FLOW GRAPH TERMINOLOGY
2/2000 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 1 2 4 5 3 A unit can be described by this graph. Certain features of the graph are relevant to white-box testing. 1) NODE -- block of statements in the code 2) BRANCH -- code statement at which sequential flow is broken based on the outcome of a decision 3) PATH -- end-to-end sequence of nodes visited during one execution of the unit. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

CONTROL FLOW GRAPH COVERAGE
2/2000 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 5 3 The measure of thoroughness is called COVERAGE. The notion of THOROUGHNESS can be made VISUAL by coloring elements of the graph that have been executed during testing. There are tools that produce such pictures. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 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 These coverage levels are arranged in order of RELATIVE STRENGTH and INCREASING DIFFICULTY. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

CONTROL FLOW GRAPH COVERAGE MEASUREMENT
2/2000 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 3 5 You may be surprised that acceptable coverage levels are not all 100%. You will see in the next few slides some of the things take make it hard to achieve 100% coverage. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

BRANCH vs CONDITION COVERAGE
2/2000 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) It is common to write code that uses COMPLEX CONDITIONS of logical expressions involving AND and OR operators. From experience, it is HARD to get programs with complex logic to work properly. If they are hard to get to work, they are also HARD TO TEST! 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

THE PROBLEM WITH COMPOUND CONDITIONS
2/2000 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!! 1 2 3 1 2 5 3 4 if (x<1) {if (y>1) x=x+y; else y=y-x; } 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

THE PROBLEM WITH PATH COVERAGE
2/2000 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. 1 2 4 3 5 if (x<1) y=2; if (x >= 1) y=3; z=y; 1) There may be paths in code that CAN NEVER BE EXECUTED. These are called INFEASIBLE PATHS. 2) For the example: a) Test case x=0, path is [1,2,3,5] b) Test case x=2, path is [1,3,4.5] c) NO TEST CASE for path [1,2,3,4,5] 3) One can TEST FOREVER and NEVER REACH 100% path coverage. 4) HOWEVER -- These test cases achieved 100% BRANCH and CONDITION COVERAGE!! 5) Designing test cases for path coverage results in high levels of branch/condition coverage. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Measuring Path Testing Difficulty
2/2000 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 1) There is a surprisingly simple way to determine the minimum number of test cases required to achieve 100% PATH COVERAGE (assuming feasibility) 2) The metric, McCabe's Cyclomatic Complexity = 1 + #elementary_decisions 3) Most widely used metric for software design a) SPLIT unit when McCabe exceeds threshold b) High McCabe means ERROR-PRONE 4) McCabe = MIN# TEST CASES for path coverage 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

How To Design White Box Tests
2/2000 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. There are two options for designing white-box test cases: 1. Reverse Engineer Decision Table from Code a) Each column represents a path b) Create test case for each column NOTE: Decisions based on computed values may complicate test case generation. 2. Use Black-Box Test Cases a) Adequate scheme when implementation matches the specification -- or is very close b) Misleading otherwise NOTE: Use of black-box test cases during code inspection may keep implementation close to spec. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

WHITE-BOX TESTING TOOLS
2/2000 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 1) Fortunately, there are tools for white-box testing. Basic features a) Instrument source code by inserting probes to gather coverage data b) Report generation following test execution c) Graphical display of coverage d) Assistance with test case design 2) Unfortunately, these tools are not in widespread or consistent use in SC. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Problem P1 Code (v1) & Decision Table
2/2000 Problem P1 Code (v1) & Decision Table Age> | Y N N N N N Weight>300 | - Y N N N N Age<= | Y N N N Age> | Y N N Weight<120 | Y N Pills = | C Note: C: 2+(Weight/120)/50 if (Age>80 || Weight>300) return 0; if (Age <= 12) return 1; if (Age > 65) return 2; if (Weight < 120) return 2 else return 2+(Weight-120)/50; 1) On the next two slides you will be shown how to build a decision table from code. 2) Afterwards, you will be given "Your Turn" at doing the same. 3) NOTE: This is an implementation of the Compute Dosage. It has McCabe of 6, so six test cases are needed to achieve 100% path coverage. 4) The reverse engineered decision table has 6 columns, as expected. So deriving a test case for each column should force execution of the 6 different paths. McCabe = 6 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Problem P1 Code (v2) & Decision Table
2/2000 Problem P1 Code (v2) & Decision Table Age> | Y N N N N N N Weight>300 | - Y N N N N N Age<= | Y N N N Age> | Y N N Weight<120 | Y N Pills = | C 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; 1) This is a different implementation of Compute Dosage. It is slightly more complex -- largely due to the use of complex conditions. NOTE: The decision table is different from your notes -- the condition rows have been reordered to match the order the conditions APPEAR IN THE CODE. 2) WARNING: REMEMBER that these test cases force the execution of the paths of the AS BUILT CODE. Passing these tests does not mean the code matches the specification. McCabe = 7 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn -- White-Box Testing (1) Construct Decision Table
2/2000 Your Turn -- White-Box Testing (1) Construct Decision Table ____________ | Pills = | Note: C: 2+(Weight/120)/50 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; YOUR TURN: (1) Reverse engineer the decision table from the code. In determining expected result, GO BY THE CODE, not the original spec. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn -- P1 (2) Derive White-Box Test Cases
2/2000 Your Turn -- P1 (2) Derive White-Box Test Cases Case Age ___ ___ ___ ___ ___ ___ ___ ___ ___ Weight ___ ___ ___ ___ ___ ___ ___ ___ ___ Pills ___ ___ ___ ___ ___ ___ ___ ___ ___ YOUR TURN (1) Create test cases for path coverage, one per column of the decision table. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

OBSERVATIONS -- WHITE-BOX TEST CASES
2/2000 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 In the ideal world, the CODE implements the SPEC, so that EACH black-box test case triggers a distinct behavior from the code .. and EACH DISTINCT BEHAVIOR has a UNIQUE PATH through the code. USE BLACK-BOX TEST CASES FOR WHITE-BOX TESTING a) Measure actual coverage (using tool) b) Create only those test cases needed to achieve coverage goal WITHOUT TOOLS, USE SOUND ENGINEERING JUDGMENT. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

MAIN POINTS WHITE-BOX TESTING
2/2000 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. 1) The real goal of white-box testing is to TEST IT ALL! 2) COVERAGE answers HOW MUCH SO FAR? 3) TEST CASE DESIGN uses REVERSE ENGINEERING of code to decision table 4) CODE INSPECTIONS are the best way to address whether black-box test cases are adequate for achieving white-box coverage. 5) WITHOUT TOOLS you are limited in what you can BE SURE OF. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

2/2000 Agenda What is Unit Testing Black-Box Testing White-Box Testing We have nearly reached the end of this session. In the next few slides we will summarize what was presented in this session. Putting It All Together 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts 5

PUTTING IT ALL TOGETHER
2/2000 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 1. Test case creation requires a SYSTEMATIC DESIGN PROCESS 2. The same design process is required for SOFTWARE DESIGN 3. DECISION TABLES provide a simple way to SPECIFY THE INTENT of a software unit 4. EARLY TEST CASE DESIGN forces EARLY CLARIFIICATION/REFINEMENT OF SPECS 5. USE TEST CASES THROUGHOUT SOFTWARE DEVELOPMENT 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

PUTTING IT ALL TOGETHER
2/2000 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!! 1. The sooner you ask the question, the sooner you get an answer 2. Since many units are similar (copy-and-paste coding), the test process is also likely to be similar -- PATTERNS 3. TEST DESIGN is DESIGN -- treat it as a software design product. 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Functional/Boundary Testing Worksheets
2/2000 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 Handouts -- Unit Test Concepts 5

SOLUTIONS TO EXERCISES
2/2000 SOLUTIONS TO EXERCISES 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (Dosage Problem) (2a) Identify Behaviors
2/2000 Your Turn (Dosage Problem) (2a) Identify Behaviors Expected Case Stimulus Description #Pills 1 Any Age, Weight>300 2 Age > 80, any Weight 3 Age <= 12, Weight <= 300 1 4 Age > 65, Weight <= 300 2 5 Age 13-65, Weight 2+(W-120)/50 6 Age 13-65, Weight < 120 2 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (3a) Create Test Cases (testset1)
2/2000 Your Turn (3a) Create Test Cases (testset1) Case Age Weight Pills Is more better? Every combination of stimuli is tested. Each column specifies at least one condition per variable 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (3b) Create Test Cases (testset2)
2/2000 Your Turn (3b) Create Test Cases (testset2) Case Age Weight Pills 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 Handouts -- Unit Test Concepts

Your Turn (4) Write Test Script (testset1)
2/2000 Your Turn (4) Write Test Script (testset1) Step Stimuli Pills= Age 1 2 3 4 5 6 Weight 7 8 9 10 12 11 67 81 85 28 15 315 120 360 180 305 40 100 220 320 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (2) Identify Boundary Conditions
2/2000 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 Handouts -- Unit Test Concepts

Your Turn (3) Identify Boundary Points
2/2000 Your Turn (3) Identify Boundary Points Boundary Point Boundary Condition AT IN OUT bc1: Age <= 12 12 11 13 bc2: Age > 65 66 65 bc3: Age > 80 81 80 bc4: Weight > 300 301 300 bc5: Weight > 120 121 120 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (4) Boundary-Nominal Test Cases
2/2000 Your Turn (4) Boundary-Nominal Test Cases Condition btc BC Weight Age Expect Weight> IN 2 OUT Weight> IN 4 OUT Age <= AT 6 IN 7 OUT Age> IN 9 OUT Age> IN 11 OUT 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn (4) Out-Out Boundary Test Cases
2/2000 Your Turn (4) Out-Out Boundary Test Cases Condition OUT B-point Weight Age btc Weight Age Expect > <= > > > <= > > 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

Your Turn -- White-Box Testing (1) Construct Decision Table
2/2000 Your Turn -- White-Box Testing (1) Construct Decision Table | Age < 80 | N - Y Y Y | Weight<300 | - N Y Y Y | Age >= 65 | N Y N | Age > 12 | N - Y 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 = | C Note: C: 2+(Weight/120)/50 2/2000 Unit Test Concepts Handouts -- Unit Test Concepts

CEN Software V & V Unit Testing Concepts

Similar presentations

Presentation on theme: "CEN Software V & V Unit Testing Concepts"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CEN Software V & V Unit Testing Concepts

Similar presentations

Presentation on theme: "CEN Software V & V Unit Testing Concepts"— Presentation transcript:

Similar presentations

About project

Feedback