Application Form Testing (PowerPoint Slides)

646 views
548 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
646
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 1) Welcome to session #2 - Unit Test Practice 2) During this session you will use unit test worksheets to design and record test cases for units.
  • Testing involves either executing a unit or inspecting a unit -- with the intent of finding errors.
  • When we think of units, we generally think SMALL. In addition to being small, there are other features of a unit: NAMED SOFTWARE ELEMENT THAT CAN BE SEPARATELY INVOKED LOGICALLY COHERENT -- Performs a SINGLE function or a GROUP OF RELATED FUNCTIONS.
  • This break-out of units into VISIBLE and INTERNAL is related to how the unit is INVOKED DURING TESTING VISIBLE -- test scripts, human tester INTERNAL -- test drivers, automated tester
  • FORMS, DATABASE and CLASSES are COMPOSITE UNIT made up of elementary units. A composite unit is tested by testing each of its elementary units, in a bottom-up fashion.
  • 1) A field has the characteristics of a unit. It is an ELEMENTARY VISIBLE UNIT. 2) Of the properties of a field, some depend on the form (e.g., color, usage for input/output), while others depend on the application (set of values, default value). 3) Activation of a field results in several important behaviors a) Validation b) Messaging -- if validation fails c) Setting of FORM STATUS (e.g., SUBMIT button DISABLED UNTIL all fields contain valid data.
  • 1) Unit tests are required to ensure the correct implementation of field attributes and behavior. TESTS OF FORM-INDEPENDENT ATTRIBUTES & BEHAVIORS ARE REUSABLE!!
  • The major focus of field testing is VALIDATION and ERROR HANDLING. Validation can be programmed using property sheets of the field (Lotus Notes) or written in the target language (e.g., Java).
  • VALIDATION ensures that the intended ATTRIBUTES have been correctly implemented. Certain technology, such as Microsoft Office or Lotus Notes can prevent certain errors from occurring, eliminating the need for validation. Even then, the CORRECT USE of these features must be TESTED .
  • In the next section we will DERIVE a set of generic test case descriptions for testing input fields implemented as text boxes and list boxes. The result will be WORKSHEET TEMPLATES that will be tailored to a given situation. The purpose of showing the DERIVATION is to show you how to construct worksheet templates for other types of fields or other units that FOLLOW A PATTERN .
  • Don’t forget that these are TEMPLATES, so some critical thought must be put into making them reflect the situation at hand. The INTENT is to GUIDE the developer through a TEST CASE DESIGN PROCESS>
  • This decision table reflects the outcomes of entering data into a text box field. 1) ROWS 1-4 reflect responses to errors a) Wrong type of input characters (numeric, alpha) b) Too much/too little data c) Wrong format (layout, appearance, punctuation) d) Illegal value 2) The last two rows address the selection of the default value, or the observation that the WRONG DEFAULT is being displayed. 3) The APPLICATION RESPONSE to these errors should include issuing an error message and other appropriate actions.
  • The next step in the derivation is to DERIVE FUNCTIONAL TEST CASES from the decision table, following the process defined in the Unit Test Concepts session.
  • The BOUNDARY TEST CASES apply to the attributes for which LIMITS APPLY -- field length and field domain (legal values). NOTE: These conditions may not apply to all fields.
  • Consider the form with this specification. 1) THREE INPUT FIELDS a) Text box for text data b) List box c) Text box for numeric data 2) ONE OUTPUT FIELD 3) Two ACTION BUTTONS 4) One FORM button -- Clear 5) One NAVIGATION button -- GoBack
  • It’s now your turn to design test cases for the Name field. Use pages from behind Tab4 -- Practice Handout
  • 5 The form looks like this. In the test case description, give a SPECIFIC VALUE to be entered, or state a tester action, like “TAB thru field” If a test condition does not apply, DELETE THE ROW. AVOID “N/A” When you get finished, we will view a solution (click on ARROW).
  • Now, create test cases for the Weight field. This is also a text box, but because the data type is NUMERIC, certain test cases that were not applicable for the Name field ARE APPLICABLE for the Weight field.
  • 5 When you get finished, we will view a solution (click on ARROW).
  • The data entry errors shown in RED are PREVENTED by list boxes -- because data entry has been replaced by DATA SELECTION . Consequently, there are just THREE functional test conditions.
  • Boundary test cases relate to the POSITION of values within the LIST OF VALUES .
  • Now, create test cases for the Age field. The test condition “DEFAULT VALUE SELECTED” should be expanded into TWO TEST CASES , since there are really two ways to select the default.
  • 5 When you get finished, we will view a solution (click on ARROW). NOTE: The default can be selected up to 3 ways: a) EXPLICITLY, by clicking on the default b) IMPLICITLY, by tabbing through the Age field when the default is displyed c) IMPLICITLY, by moving the mouse past the Age field.
  • We have shown how to test input fields designed as text and list boxes. A series of tests is used to test each field. Other properties (indicated by * ) can be tested via checklists. The checklist also provides a specification of required behavior of the form (e.g., tab sequence or cursor movement).
  • Testing a field is easiest when validation occurs IMMEDIATELY upon leaving the field. The developer can follow a BUILD-then-TEST approach, correctly implementing one field before implementing the next field. CLIENT-SIDE validation permits this. DEFERRED VALIDATION occurs when a field is validated only WHEN USED -- when a button is selected. The BUILD-then-TEST approach is hard in this case. SERVER-SIDE validation is deferred validation .
  • We have shown how to test input fields designed as text and list boxes. There are other input field designs (also called controls) a) List box permitting exactly 1 choice b) List box permitting multiple choices c) Radio buttons permitting exactly 1 choice d) Check boxes permitting multiple choices. NOTE: For testing purposes, a and c are equivalent, so are b and d; that is, the test worksheet templates have the same test conditions.
  • 5 We now focus on testing an ACTION BUTTON . Other kinds of buttons are: a) Form button -- manipulates the form, but does not transmit or process data. Example: CLEAR. B) Navigation button -- moves to another form, or to another location within the current form. An associated action may be the closing of the current form (possibly including children of the current form). Example: GoBack.
  • 5
  • SAVE is an ACTION BUTTON . The effect of button is to take certain data from the form (the input fields only), and store the data in the Trials database. Unlike input fields, developing test cases for buttons requires an analysis and design process. 1) ANALYSIS a) Identify all stimuli and responses -- some will form fields, others will be databases, messages, etc. b) Develop decision table relating responses to stimuli. 2) DESIGN test cases from decision table.
  • 1) STIMULI a) Input fields of the form -- provide data that will be saved. B) The database must exist 2) RESPONSES a) Updates to the database b) Error messages, if unsuccessful c) Consider additional visual effects, such as cursor movement or color changes. The next step is to determine the specific circumstances under which each response occurs, and to decide the specific values in each response .
  • NOTE: (These notes optional -- may confuse) (1) This is a compressed table that treats SINGLE ERRORS. (2) The behavior when multiple errors occur at the same time is not reflected (3) One interpretation is that checking occurs in the order, and checking stops on the first error: (a) DB open? (b) Weight valid (c ) Name Valid> (d) Duplicate Name? (4) When the precedence is critical, this table should be expanded to specify responses to multiple errors.
  • The SECOND test case conditions tests the occurrence of two errors -- DB-not-ready and bad-Name. Other test cases handle zero or one error.
  • It is now your turn to design test cases for the CalculateDosage button. Before proceeding, let’s preview the steps you will follow: (Show next 4 slides). Recall that in the Unit Testing Concepts session we designed test cases for the UNDERLYING FUNCTION, where the focus was on calculating #Pills, given Age and Weight. The focus here is the VISIBLE FORM and circumstances in which the FORM CHANGES (including messages).
  • Determine the stimuli and responses. A) This may not involve every field on the form. B) There may not be a database involved C) There may be error messages. NOTE: RESPONSES are HIGH LEVEL -- - VISIBLE changes to the form - VISIBLE error messages - Specific values of DOSAGE not enumerated
  • As with the SAVE button, certain questions must be asked to determine the relationship between responses and stimuli. Include CURSOR MOVEMENT in the questions, since cursor movement is a RESPONSE . When the specification is unclear, it should be refined based on the answer to questions.
  • Complete the decision table based on the Stimulus-Response analysis and the answers to the questions. Actions include cursor placement and setting a value in DOSAGE field.
  • Derive test cases from the decision table. Stop at FOUR test cases -- the first 2-3 will be error test cases. The last test case involves a valid weight, and requires a computation of the DOSAGE field.
  • 5 Testing an action button combines a form-level test with the test of the underlying function. The form level test relates to WHEN IS IT OKAY TO SELECT THE BUTTON, and WHAT VISIBLE HAPPENS? The underlying function test relates specific values of form (input) fields to form output fields. Test cases for the function may be designed independently from the form-level tests.
  • 5 A BOTTOM-UP process for testing a form. 1) Start with the tests that can be done in ISOLATION -- FIELD TESTS -- FORM BUTTONS 2) Perform tests that require connection to other forms and to underlying functions -- NAVIGATION BUTTONS -- ACTION BUTTONS -- CURSOR MOVEMENT Some of these tests can be completed using CHECK LISTS.
  • 5 Here is an example of a CHECKLIST for testing cursor movement. NOTE: This checklist is a SPECIFICATION of required movement. NOTE: This is a NEGATIVE CHECKLIST -- it is “ tallied ” (marked) when a specified MOVEMENT DOES NOT OCCUR
  • 5 This checklist specifies a set of visual properties that must be satisfied by the form. The list of properties reflects STANDARDS , BONDING and application l ook and feel . NOTE: Even though the SAME STANDARDS may apply to all forms, use ONE CHECKLIST PER FORM .
  • 5 The set-up for form testing is less for isolated testing, especially when CLIENT-SIDE validation is implemented. SERVER-SIDE testing requires some level of integration of the FIELDS with at least on BUTTON. Fields can be tested one at a time by providing VALID values for all fields but one, and varying the values of the remaining field. RULE: TEST AS MUCH AS YOU CAN AS SOON AS YOU CAN!
  • 5 It should be clear that designing test cases goes HAND IN HAND with clearly specifying the behavior of the form. You are provided with reusable templates that must be customized based on the specifics of the form being designed. PLEASE NOTE: BE SURE TO INCLUDE TESTS FOR RELATED FIELD GROUPS (e.g., MALE answering FEMALE question). These are not included in the worksheet.
  • 5 The worksheet templates satisfy the goals of SPECIFICATION driven PREMEDITATION -- systematic design process REPEATABILITY -- same templates used by all. ACCOUNTABILITY -- the worksheet are a record of what was planned, what was tested, and what the results were. ECONOMY -- the effort to design and execute tests is bounded. Expect it to reduce through reuse (copy, paste, edit).
  • 5 Read as is.
  • 5 The test driver for a class is similar to that for an elementary unit: 1) Reads test cases from a file 2) Writes test results to a file The class test driver is DIFFERENT: 1) Calls MULTIPLE functions, passing test data and receiving test results. 2) Must distinguish WHICH FUNCTION is being tested. The class test driver EXTENDS the elementary unit test driver in difference #2.
  • 5 1) A stack is a collection managed by the rule: First In, Last Out. It works like a stack of plates at a cafeteria. An instance of a stack is called a STACK OBJECT. 2) ATTRIBUTES: data about the collection -- the PRIVATE section above, the STATE of the stack object. 3) BEHAVIOR: the METHODS (functions) in the PUBLIC section above. Stack -- creates an empty stack. Push -- adds another value to top of the stack Pop -- removes the value at the top of the stack Top -- returns the value at the top of the stack Empty -- returns TRUE when stack is empty 4) Methods UPDATE or INQUIRE the state.
  • 5 Before showing the driver, here are the input and output files used by the driver. 1) The input file contains METHOD TEST CASES. 2) Each method is assigned a UNIQUE NUMBER. 3) The test data required depends on which method is being tested. 4) Expected results depend on the overall behavior of the object (stack) under a SEQUENCE of method test cases. The results file also identifies the method being tested. What is wrong with this stack? Which method contains the error?
  • 5 The class test driver extends the elementary unit test driver as follows: 1) Because a test case may apply to any of the methods, as SWITCH or CASE statement is used inside the main loop. 2) Each case tests ONE METHOD.
  • 5 Besides these changes, the structure of the class driver is identical to the elementary unit driver. This driver performs a BLACK-BOX CLASS TEST -- the internals of the class (its state) are not examined directly.
  • 5 There are choices about the class test driver. 1) The driver can read test cases interactively, or from a file (batch). The driver can also display results in addition to (in lieu of) writing them to a file. Batch drivers are more economical. 2) A class driver collects separate unit tests into a single, comprehensive test.
  • 5 The class driver is DATA DRIVEN: After test cases have been designed, they can be stored immediately in the driver input file. In addition to the BLACK-BOX class test driver, a CLEAR-BOX test driver can be be constructed that directly accesses and modifies the internal class state. To accommodate this, special methods are required to provide a TESTING WINDOW into the class. The notion of class can be extended to include any SET OF RELATED FUNCTIONS that use or share common data.
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • Application Form Testing (PowerPoint Slides)

    1. 1. CIS 4932 Special Topics Software Testing Fall 2001 Practice -- Testing Forms © 2001, Dr. E.L. Jones
    2. 2. What is Unit Testing? <ul><ul><li>Executing a software element to determine whether it meets its specification </li></ul></ul><ul><ul><li>Executing a software element to discover defects or anomalies </li></ul></ul><ul><ul><li>Inspecting software element code to discover defects or anomalies. </li></ul></ul>
    3. 3. What Is A Unit? <ul><ul><li>Named software element with properties and behavior </li></ul></ul><ul><ul><li>Separately invokable </li></ul></ul><ul><ul><li>Performs single function </li></ul></ul><ul><ul><li>Logically cohesive set of the above </li></ul></ul>
    4. 4. Examples of Units <ul><ul><li>User-Visible software elements </li></ul></ul><ul><ul><ul><li>Fields on forms </li></ul></ul></ul><ul><ul><ul><li>Buttons on forms </li></ul></ul></ul><ul><ul><ul><li>Entire forms (reports) </li></ul></ul></ul><ul><ul><li>Program-Internal software elements </li></ul></ul><ul><ul><ul><li>Subprograms (procedures, functions, mains) </li></ul></ul></ul><ul><ul><ul><li>Classes </li></ul></ul></ul><ul><ul><ul><li>Databases </li></ul></ul></ul>
    5. 5. Elementary Units <ul><ul><li>Form </li></ul></ul><ul><ul><ul><li>Field </li></ul></ul></ul><ul><ul><ul><li>Navigation Button </li></ul></ul></ul><ul><ul><ul><li>Operation Button </li></ul></ul></ul><ul><ul><li>Database </li></ul></ul><ul><ul><ul><li>Field </li></ul></ul></ul><ul><ul><ul><li>Stored Procedure </li></ul></ul></ul><ul><ul><ul><li>Query </li></ul></ul></ul><ul><ul><li>Program Code </li></ul></ul><ul><ul><ul><li>Main </li></ul></ul></ul><ul><ul><ul><li>Method </li></ul></ul></ul><ul><ul><ul><li>Function </li></ul></ul></ul><ul><ul><ul><li>Script </li></ul></ul></ul>
    6. 6. WHY IS A FIELD A UNIT? <ul><ul><li>Field has properties </li></ul></ul><ul><ul><ul><li>Data type and domain (size, value set, default) </li></ul></ul></ul><ul><ul><ul><li>Visual appearance (color, case, alignment) </li></ul></ul></ul><ul><ul><ul><li>Accesibility&quot; Read-only, write-only, R/W </li></ul></ul></ul><ul><ul><li>Field has behavior </li></ul></ul><ul><ul><ul><li>Validation -- reject if property rule violated </li></ul></ul></ul><ul><ul><ul><li>Messaging -- to report violation </li></ul></ul></ul><ul><ul><ul><li>Global status -- bad field invalidates form </li></ul></ul></ul>
    7. 7. FIELD ATTRIBUTES and BEHAVIOR <ul><li>Data type </li></ul><ul><li>Length </li></ul><ul><li>Format </li></ul><ul><li>Domain </li></ul><ul><li>Default value </li></ul><ul><li>Validation rules </li></ul><ul><li>Error messages </li></ul>
    8. 8. TESTING AN INPUT FIELD An Error-Handling Approach <ul><ul><li>A primary function of an input field is to validate data entered into a field, and to notify the user if an error occurs. </li></ul></ul><ul><ul><li>Properties of the field determine error conditions and the correct response </li></ul></ul><ul><ul><li>Input field testing ensures that only valid input is accepted, and proper error handling occurs. </li></ul></ul>
    9. 9. RELATIONSHIP BETWEEN ATTRIBUTES and VALIDATION <ul><ul><li>Validation rules perform self-checking at field, form, and/or database level </li></ul></ul><ul><ul><li>Lotus Notes prevents some input errors </li></ul></ul><ul><ul><ul><li>Input masking prevents formatting and data type errors </li></ul></ul></ul><ul><ul><ul><li>List boxes prevent input errors </li></ul></ul></ul><ul><ul><li>Certain &quot;semantic&quot; errors still must be checked (inconsistency) </li></ul></ul>
    10. 10. BEFORE WE CONTINUE … A LOOK AHEAD <ul><ul><li>We derive generic test case specifications for certain types of fields </li></ul></ul><ul><ul><ul><li>Text boxes -- string and numeric data </li></ul></ul></ul><ul><ul><ul><li>List boxes -- string and numeric data </li></ul></ul></ul><ul><ul><li>These become worksheet templates for designing field test cases </li></ul></ul>
    11. 11. WHERE IS THE WORK? … A LOOK AHEAD <ul><ul><li>Developer must supply actual test cases for each test case specification </li></ul></ul><ul><ul><ul><li>Some specs expand into multiple test cases </li></ul></ul></ul><ul><ul><li>Developer may derive additional generic test case specs for new field types </li></ul></ul><ul><ul><li>Developer combines test cases into a test worksheet. </li></ul></ul>
    12. 12. Deriving Generic Test Case Specs for a Text Box a1: PREVENTED | Action a2: Data Type Error Msg | X a3: Length Error Msg | X a4: Format Error Msg | X a5: Domain Error Msg | X a6: Field set to Default | X a7: Truncated/padded | X a8: Input accepted | X a9: FIELD ERROR | X c1: Wrong Data type | Y N N N N C ondition c2: Wrong Length | - Y N N N c3: Wrong format | - - Y N N c4: Illegal value | - - - Y N c5: Default value used | N Y c6: Wrong default value | Y
    13. 13. TEXT BOX Functional TEST CASES (Generic) Case Stimulus Expected Response 1 Wrong data type Data type error message 2 Length error message 3 Length error message, truncate 4* Format error message 5 Value error message 7 ACCEPT Default value. 6 ACCEPT value Default value selected Non-Default value entered Illegal value only. Good type, length; bad format Good type, too long Good type, too short 8 UNEXPECTED: FIELD Error. Wrong Default value displayed * Expand based on format syntax
    14. 14. TEXT BOX Boundary TEST CASES (Generic) Case Stimulus Expected Response 9 GOOD: Length = minimum ACCEPT field 10 11 12 GOOD: value = &quot;maximum&quot; GOOD: value = &quot;minimum&quot; GOOD: Length = maximum Tester sees only the Generic Test Cases, not the process followed to derive them. ACCEPT field ACCEPT field ACCEPT field
    15. 15. DOSAGE CALCULATION FORM -- Specification Field/ Button Description (Specification) Patient Name Patient Age Dosage Calculate Dosage Button Clear Button Name. 1-20 alpha/comma chars . Format: Last, First Middle Computed output field. Whole number, in range 0-5 . Action button. Compute dosage based on Age, Weight, and display in Dosage field. List box: {12 and under, 13-65 (default) , 65-80, over 80 }. Form button. Clear all input and output fields. Patient Weight Weight in pounds. Whole number, in range 1-900 . Save Button Action button. Save form data to Trials Database. GoBack Button Navigation button. Return to previous screen.
    16. 16. Your Turn -- Error Test Cases (Dosage Form Name Field) a) Fill in FIELD NAME b) Create TEST DATA for each row. c) Complete the expected result -- at minimum, issue a message if an error occurs. d) If a test condition does not apply for the field, delete the row from the worksheet. 1. Remove the Form Test Worksheet after Tab4 2. You will use Section A -- Field Unit Test 3. Complete the TextBox-Text Data template.
    17. 17. Name Field Test Worksheet Text Box (Text)
    18. 18. Your Turn -- Error Test Cases (Dosage Form Weight Field) a) Fill in FIELD NAME b) Create TEST DATA for each row. c) Complete the expected result -- at minimum, issue a message if an error occurs. d) If a test condition does not apply for the field, delete the row from the worksheet. 1. Use the Form Test Worksheet, Section A. 2. Complete the TextBox-Numeric Data template
    19. 19. Weight Field Test Worksheet Text Box (Numeric)
    20. 20. Deriving Generic Test Case Specs for a List Box a1: PREVENTED | X X X X Action a2: Field set to Default | X a3: Input accepted | X a4: FIELD ERROR | X Condition c1: Wrong Data type | N c2: Wrong Length | N c3: Wrong format | N c4: Invalid value | N c5: Default selected | Y N - c6: Wrong default value | N N Y List boxes prevent these input errors.
    21. 21. LIST BOX Functional/Boundary TEST CASES (Generic) Case Stimulus Expected Response 1 Select Default value. ACCEPT DefaultValue 2 ACCEPT ListValue_k 3 FIELD Error, no message. Wrong Default value displayed. Select k'th value from List. * Boundary test cases. 4 First list item ACCEPT first ListValue. 5 Last list item ACCEPT last ListValue
    22. 22. Your Turn -- Error Test Cases (Dosage Form Age Field) a) Fill in FIELD NAME b) Create TEST DATA for each row. c) Complete the expected result -- at minimum, issue a message if an error occurs. d) If a test condition does not apply for the field, delete the row from the worksheet. 1. Use the Form Test Worksheet, Section A. 2. Complete the ListBox template.
    23. 23. Age Field Test Worksheet List Box
    24. 24. Other Form-Field Attributes ( verify using checklist * ) <ul><li>Form-Level Test </li></ul><ul><ul><li>Data source </li></ul></ul><ul><ul><li>Data destination </li></ul></ul><ul><ul><li>Correlated fields </li></ul></ul><ul><ul><li>Tab/Cursor sequence * </li></ul></ul><ul><li>Field-Level Test </li></ul><ul><ul><li>Required Field </li></ul></ul><ul><ul><li>Input only access * </li></ul></ul><ul><ul><li>Output only access * </li></ul></ul><ul><ul><li>Input/Output access * </li></ul></ul><ul><ul><li>Visual appearance * </li></ul></ul>
    25. 25. WHEN IS VALIDATION PERFORMED? <ul><ul><li>At the field level, immediately upon changing focus from field (e.g., client side) </li></ul></ul><ul><ul><ul><li>Supports field build & test </li></ul></ul></ul><ul><ul><li>At the form level, upon clicking a button that requires the data (e.g., server side) </li></ul></ul><ul><ul><ul><li>Deferred field test, rolled into form test . </li></ul></ul></ul>
    26. 26. GOOD NEWS! A FIELD IS REUSABLE! <ul><ul><li>Same field used on many forms </li></ul></ul><ul><ul><li>Most attributes are the same, so are the validation rules </li></ul></ul><ul><ul><li>Field implementation and test are reusable </li></ul></ul><ul><ul><li>Only form-specific attributes may change </li></ul></ul>Insight: There are reusable test patterns based on field attributes.
    27. 27. Agenda <ul><ul><li>Products & Deliverables </li></ul></ul><ul><ul><li>Testing Forms: Fields & Buttons </li></ul></ul><ul><ul><li>Testing Classes </li></ul></ul><ul><ul><li>What is Unit Testing? </li></ul></ul><ul><ul><li>Testing Callable Modules </li></ul></ul><ul><ul><li>Putting It All Together </li></ul></ul>
    28. 28. Objective Testing a button is testing a function that uses form input field data, and may produce form output fields. There may be additional stimuli and responses beyond those observable from the form. A button test is a black-box test.
    29. 29. Testing the SAVE Button <ul><ul><li>Identify stimuli and responses </li></ul></ul><ul><ul><ul><li>Schematic diagram </li></ul></ul></ul><ul><ul><li>Develop decision table </li></ul></ul><ul><ul><ul><li>Ask questions about required behavior </li></ul></ul></ul><ul><ul><ul><li>Identify conditions for certain behavior </li></ul></ul></ul><ul><ul><li>Develop test cases </li></ul></ul><ul><ul><ul><li>Functional and boundary test cases </li></ul></ul></ul>
    30. 30. SAVE Button Black-Box Schematic Stimulus Type Response Type SAVE Button Argument Inputs Globals Database Exception Argument Outputs Globals Database Exception Name, Age, Weight Trials DB Error Msg? Trials DB
    31. 31. Asking the Right Questions <ul><ul><li>Preconditions? </li></ul></ul><ul><ul><ul><li>Trials database OPEN and available </li></ul></ul></ul><ul><ul><ul><li>Form fields are valid </li></ul></ul></ul><ul><ul><li>Postconditions? </li></ul></ul><ul><ul><ul><li>Entry for patient in Trials database </li></ul></ul></ul><ul><ul><ul><ul><li>#entries per patient? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>How are entries stored? </li></ul></ul></ul></ul><ul><ul><li>Errors Detected, Messages? </li></ul></ul><ul><ul><ul><li>Field data not valid </li></ul></ul></ul><ul><ul><ul><li>Unable to update, given field data </li></ul></ul></ul>
    32. 32. SAVE Button DECISION TABLE c1: Trials DB open | N Y Y Y Y Y c2: Valid Age | Y Y N Y Y c3: Valid Weight | Y Y N Y c4: Valid Name | Y Y N c5: Name already in DB | N Y a1: &quot;DB not ready&quot; msg | X a2: Save | X a3: &quot;Duplicate entry&quot; msg | X a4: &quot;Invalid Field&quot; msg | X X X * Impossible to have invalid Age: list box with default. * (a4) Possibly a different message for each field.
    33. 33. SAVE Button Functional Test Cases * Multiple errors: which one takes precedence? * Infeasible test case, given list box! Case Stimulus Expected Response 1 1a 3 5 6 Trials DB not ready, good fields &quot;DB not ready&quot; msg, no save. Trials DB not ready, bad Name field &quot;??&quot; msg, no save. DB ready, duplicate Name &quot;Duplicate&quot; msg, no save. DB ready, bad Weight only. &quot;Bad Field&quot; msg, no save. DB ready, bad Name only &quot;Bad Field&quot; msg, no save. 2 DB ready, unique Name SAVED, no msg. 4x Impossible -- drop N/A
    34. 34. Your Turn -- Testing the CalculateDosage Button <ul><ul><li>Identify stimuli and responses </li></ul></ul><ul><ul><ul><li>Schematic diagram </li></ul></ul></ul><ul><ul><li>Develop decision table </li></ul></ul><ul><ul><ul><li>Ask questions about required behavior </li></ul></ul></ul><ul><ul><ul><li>Identify conditions for certain behavior </li></ul></ul></ul><ul><ul><li>Develop test cases </li></ul></ul><ul><ul><ul><li>Functional and boundary test cases </li></ul></ul></ul>
    35. 35. Your Turn -- CalculateDosage Button Black-Box Schematic Stimulus Type Response Type Calculate Dosage Button Argument Inputs Globals Database Exception Argument Outputs Globals Database Exception
    36. 36. <ul><ul><li>Preconditions? </li></ul></ul><ul><ul><li>Postconditions? </li></ul></ul><ul><ul><ul><li>patient? </li></ul></ul></ul>Your Turn -- CalculateDosage Button -- Questions <ul><ul><li>Errors Detected, Messages? </li></ul></ul>
    37. 37. Your Turn -- CalculateDosage Button Decision Table c1: | c2: | a1: Dosage = calculated #pills | a2: | a3: | a4: | a5: | NOTE: This table deals with the activation of the button in terms of visible form elements (input/output fields and error messages). Detailed rules for calculating the value were treated in Unit Testing Concepts session.
    38. 38. Your Turn -- CalculateDosage Button Test Cases Case Test Data/Actions Expected Response 1 NOTE: These cases begin with form-level error handling for the CalculateDosage button, and contains functional test cases from the Concepts session. 2 3 4
    39. 39. Button Testing -- Summary Testing a button is easy when the test analysis has already been performed on the underlying function. The form expands the scope of the function to include visible fields and hidden effects (e.g., database updates). The basic question remains &quot;what should happen, and where should I look for it?&quot;
    40. 40. Form Testing -- Process <ul><li>Perform field tests </li></ul><ul><li>Perform button tests </li></ul><ul><ul><li>Form buttons * </li></ul></ul><ul><ul><li>Navigation * </li></ul></ul><ul><ul><li>Action buttons </li></ul></ul><ul><li>Perform cursor tests * </li></ul><ul><ul><li>Initial position, tab sequence, position after data entry or button activation </li></ul></ul>------------------ * via checklist
    41. 41. Form Test Worksheet Cursor Movement & Navigation
    42. 42. Visual Properties Checklist
    43. 43. Form Testing -- Set Up <ul><li>Isolated Testing </li></ul><ul><ul><li>Form visual attributes </li></ul></ul><ul><ul><li>Individual field testing -- validation </li></ul></ul><ul><li>Integrated Testing </li></ul><ul><ul><li>Form connected to other forms for navigation </li></ul></ul><ul><ul><li>Buttons connected to underlying code </li></ul></ul><ul><ul><li>Database connected </li></ul></ul>
    44. 44. Form Testing -- Results <ul><li>Perform tests specified on Checklists and Worksheets created during design, and record results </li></ul><ul><ul><li>Form test checklist </li></ul></ul><ul><ul><ul><li>visuals </li></ul></ul></ul><ul><ul><ul><li>cursor movement </li></ul></ul></ul><ul><ul><ul><li>navigation </li></ul></ul></ul><ul><ul><li>Form test worksheet </li></ul></ul><ul><ul><ul><li>field test section * </li></ul></ul></ul><ul><ul><ul><li>buttons test section </li></ul></ul></ul>------------ * Generic based on field type.
    45. 45. Form Testing Worksheets <ul><li>Stored in Domino </li></ul><ul><ul><li>Master template </li></ul></ul><ul><ul><li>Separate templates for each form element </li></ul></ul><ul><li>Construct Worksheet by including templates for form elements </li></ul><ul><li>Preview Worksheets </li></ul>
    46. 46. Form Testing -- Summary Form testing is a bottom-up process involving testing of visual properties, cursor movement, data entry and display, and actions triggered by buttons. Certain properties can be tested immediately; others require varying degrees of system integration.
    47. 47. Testing Classes -- Drivers (Black-Box) Class Test Driver Method Args /Results Test set Data Test Set Results Class Class-state Method(s)
    48. 48. Example -- Stack Class class Stack { public: Stack(); void push(int n); int pop(); int top(); bool empty(); private: int Size; int Top; int Values[100]; }; Notes: (1) Class state -- variables Size, Top and the first 'Size' values in array Values. (2) Methods push and pop modify class state; top and empty inquire about the state. (3) Stack does not require any test environment of its own. (4) Class state HIDDEN from test, i.e., black box.
    49. 49. Test Driver Files (Stack class) Test Data File (tdi-stack.txt) File content: ----- 1 8 1 7 3 7 2 7 2 8 4 true ------ Note: No test environment setup. Methods: 1-push, 2-pop, 3-top, 4-empty Test Results File (trs-stack.txt) File content: ----- 1 1 8 2 1 7 3 3 7 8 4 2 7 8 5 2 8 7 6 4 1 ------ Note: Results file must be inspected for pass/fails . --- Top should be 7 . --- Push . --- Pop, should be 8 . --- Stack should be empty. Fail Fail Fail Pass
    50. 50. Class Test Driver Design Driver dC uses class C { c = new (C); testcase_no = 0; open tdi_file(&quot;tdi_stack.txt&quot;); open trs_file(&quot;trs_stack.txt&quot;); while (more data in tdi_file) { op = read(tdi_file); switch (op) { case 1: //Push. read(tdi_file, value); c.push(value); write(trs_file, testcase_no, 1, value); break; case 2: //Pop. read(tdi_file, expect); value = c.pop(); write(trs_file, testcase_no, 2, expect, value); break;
    51. 51. Class Test Driver Design … default: } // switch } //while close tdi_file, trs_file; } //class-driver case 3: //Top. read(tdi_file, expect); value = c.top(); write(trs_file, testcase_no, 3, expect, value); break; case 4: //Empty. read(tdi_file, expect); value = c.empty(); write(trs_file, testcase_no, 4, expect, value); break;
    52. 52. Implementing Class Test Drivers <ul><li>Interactive vs Batch (files) </li></ul><ul><li>Extend Unit Driver </li></ul><ul><ul><li>switch to handle multiple methods </li></ul></ul><ul><ul><li>Method-specific test cases </li></ul></ul><ul><ul><li>Method interactions tested </li></ul></ul><ul><ul><li>All results stored in common results file </li></ul></ul><ul><li>Major Benefits -- comprehensive driver </li></ul><ul><ul><li>Automated, repeatable, documented </li></ul></ul><ul><ul><li>Minimized set-up </li></ul></ul>
    53. 53. Class Test Driver -- Summary <ul><li>Data Driven -- flexible, extensible </li></ul><ul><li>Varying levels of detail </li></ul><ul><ul><li>black-box (method calls, no class state) </li></ul></ul><ul><ul><li>clear-box (class state, advanced topic ) </li></ul></ul><ul><ul><li>global effects (test environment) </li></ul></ul><ul><li>A driver is a reusable pattern for testing. </li></ul>
    54. 54. Name Field Test Worksheet
    55. 55. Weight Field Test Worksheet
    56. 56. Age Field Test Worksheet List Box
    57. 57. Your Turn -- Testing the CalculateDosage Button <ul><ul><li>Identify stimuli and responses </li></ul></ul><ul><ul><ul><li>Schematic diagram </li></ul></ul></ul><ul><ul><li>Develop decision table </li></ul></ul><ul><ul><ul><li>Ask questions about required behavior </li></ul></ul></ul><ul><ul><ul><li>Identify conditions for certain behavior </li></ul></ul></ul><ul><ul><li>Develop test cases </li></ul></ul><ul><ul><ul><li>Functional and boundary test cases </li></ul></ul></ul>
    58. 58. Your Turn -- CalculateDosage Button Black-Box Schematic Stimulus Type Response Type CALCULATE DOSAGE Button Argument Inputs Globals Database Exception Argument Outputs Globals Database Exception Age, Weight ErrorMsg? Dosage field
    59. 59. Your Turn -- CalculateDosage Button -- Questions <ul><ul><li>Preconditions? </li></ul></ul><ul><ul><ul><li>Form fields are valid </li></ul></ul></ul><ul><ul><ul><li>Initial value of Dosage field (e.g., blank)? </li></ul></ul></ul><ul><ul><li>Postconditions? </li></ul></ul><ul><ul><ul><li>Dosage field computed </li></ul></ul></ul><ul><ul><ul><li>No other fields updated </li></ul></ul></ul><ul><ul><ul><li>Cursor position </li></ul></ul></ul><ul><ul><ul><li>Dosage blank if error </li></ul></ul></ul><ul><ul><li>Errors Detected, Messages? </li></ul></ul><ul><ul><ul><li>Form field data not valid </li></ul></ul></ul><ul><ul><ul><li>Unable to calculate (Dosage field value: blank or ZERO?) </li></ul></ul></ul>
    60. 60. Your Turn -- CalculateDosage Button Decision Table c1: Weight = blank | Y N N c2: Valid Weight | - N Y* c3: Valid Weight | - N Y* a1: Dosage = calculated #pills | X* a2: Dosage field = blank | X X a3: Error msg = &quot;can't compute&quot; | X X a4: Cursor at Dosage field | X a5: Cursor at Weight field | X *NOTE: This table deals with the activation of the button in terms of visible form elements (input/output fields and error messages). Detailed rules for calculating the value were treated in Unit Testing Concepts session.
    61. 61. Your Turn -- CalculateDosage Button Test Cases NOTE: These cases begin with form-level error handling for the CalculateDosage button, and contains functional test cases from the Concepts session. Case Test Data/Actions Expected Response 1 2 3 4 Enter Name = &quot;Doe, Joe&quot; Enter Default Age Tab through BLANK Weight field Enter Name = &quot;Doe, Joe&quot; Enter Default Age Enter Weight = 925 Enter Name = &quot;Test, Joe&quot; Enter Age from functional test set Enter Weight from functional test set … Remaining functional test cases … 1.&quot; Invalid Weight&quot; message 2. Dosage = blank 3. Cursor at Weight 1.&quot; Missing Weight&quot; message 2. Dosage = blank 3. Cursor at Weight 1. Dosage = computed value (from test case) 2. Cursor at Dosage
    62. 62. Action Button Test Worksheet
    63. 63. Example -- Stack Class class Stack { public: Stack(); void push(int n); int pop(); int top(); bool empty(); void SetState(int,int,int[]); void GetState(int &,int &,int[]); private: int Size; int Top; int Values[100]; }; Notes: (1) Class state -- variables Size, Top and the first 'Size' values in array Values. (2) Methods push and pop modify class state; top and empty inquire about the state. (3) &quot;Hooks&quot; can be created to set and retrieve the class state. (4) Stack does not require any test environment of its own.
    64. 64. Class Test Driver Design Driver dC uses Test_Env T; uses class C { // Set up external environment // c = new (C); testcase_no = 0; open tdi_file (filename); open trs_file (filename) case -4: //Set test env// read(tdi_file. t_env); T.setenv(t_env); break; case -3: //Get test env// T.getenv(t_env); write(trs_file, t_env); break; case -2: //Set class state// read(tdi_file, c_state); c.setstate(c_state); break;
    65. 65. Class Test Driver Design case -1: //Get class state. c.getstate(c_state); write(trs_file, c_state); break; case m: // test class method #m. read(tdi_file, args); read(tdi_file, expect); result = method(args); write (trs_file, testcase_no++, args, expect, result); break; // If the internal state of the class // must be set or checked, a (-2) // precedes case &quot;m&quot;, and a (-1) // follows case &quot;m&quot;. // Remaining methods … // default: } // switch } //while close tdi_file, trs_file; } //driver

    ×