Unit Testing a Primer
Upcoming SlideShare
Loading in...5
×
 

Unit Testing a Primer

on

  • 123 views

Unit test ???? - is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work. This presentation is all about ...

Unit test ???? - is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work. This presentation is all about Unit Testing. Will be beneficial to both the developers and testers to learn from.

Statistics

Views

Total Views
123
Views on SlideShare
123
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Unit Testing a Primer Unit Testing a Primer Presentation Transcript

    • Unit Testing Name: Amit Satpathy No. of Slides: 48 Duration: 2 hours Date: 18/02/2014
    • 2 Table of Content • What is Unit? • Generic Definition of Unit • Integration of Units • Why Unit is Important? • What is Unit Testing? • Unit Testing Methods (Static and Dynamic) • Unit testing guidelines for Screen Based Systems
    • 3 What is a Unit ? • Is it Unit of measurement for software ? • Is it a computer Unit ? • Is it the work done by a developer ? • Is it a logical Unit of source code developed ?
    • 4 Generic definition of a Unit • A unit is smallest executable/testable piece of software, which can be compiled or assembled or linked . • It is usually the work of a developer and it consists of several hundreds or fewer lines of source code.
    • 5 How a software product is built ? • In a Software product the lowest level executable codes are Units. • Seamless integration of these Units result in the intermediate/final product.
    • 6 Integration of Units • Integration of Units sometimes gives rise to modules • Modules are sometimes joined to result in as intermediate product
    • 7 Why Unit is important ? • Man is the best example • Mouth, Nose, Eye etc are different units • Seamless integration of different units results in complete man • What if one unit does not function properly ?
    • 8 What is unit testing ? • The testing performed to show that – the unit does not satisfy its functional specification – and/or that its implementation structure does not match the intended design structure • When our test reveals such faults, we say there is unit defect.
    • 9 Unit Testing Methods • Static Analysis – is a method used to investigate the structural properties of the code • Dynamic Testing – is a method used to investigate the behavior of the source code by executing the program on the test data
    • 10 Static Analysis Considerations • Syntax • Unreachable code • Unconditional branches into loops • Undeclared variables • Un-initialized variables
    • 11 Static Analysis Considerations... • Parameter type mismatches • Uncalled functions and procedures. • Variables used before initialization. • Non usage of function results. • Possible array bound errors. • Misuse of pointers
    • 12 Dynamic Unit Testing Considerations • Interface • Local data structures • Boundary conditions • Independent paths • Error handling paths
    • 13 Suggested checklist - Interface • Number of input parameters equal to number of arguments? • Parameter and argument attributes match?
    • 14 Suggested checklist…. • Parameters passed in correct order? • Input only parameters changed? • Global variable definitions consistent across modules
    • 15 Suggested checklist – I/O If the unit does I/O • File attributes correct? • Open / Close statements correct? • Format specifications match I/O statements? • Buffer size match record size?
    • 16 Suggested checklist... • Files opened before use? • End of file condition handled? • I/O errors handled? • Any textual errors in output information?
    • 17 Suggested checklist - Local Data Structures • Improper or inconsistent typing • Erroneous initialization or default values • Incorrect variable names • Inconsistent data types
    • 18 Suggested checklist - Error Handling • Error description unintelligible. • Error noted does not correspond to error encountered. • Error description does not provide sufficient information to assist in determining error.
    • 19 Boundary Value Analysis • Large number of errors tend to occur at boundaries of the input domain • BVA leads to selection of test cases that exercise boundary values.
    • 20 Boundary Value Analysis……. • Examples 1.For a range of values bounded by a and b, test (a- 1), a, (a+1), (b-1), b, (b+1). 2.If input conditions specify a number of values n, test with (n-1), n and (n+1) input values. 3.Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size). 4.If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.
    • 21 Control Structure Testing Conditions Can define : • Relational expression: (E1 op E2), where E1 and E2 are arithmetic expressions. Ex:- E1 <= E2 • Boolean Expression: Boolean variable or relational expression, possibly preceded by a NOT operator. NOT(E1 > E2) AND (E3 < E4) • Compound condition: composed of two or more simple conditions, Boolean operators and parentheses. (E1 > E2) AND (E3 < E4)
    • 22 Control Structure Testing... Errors in expressions can be due to: • Boolean operator error • Boolean variable error • Boolean parenthesis error
    • 23 Control Structure Testing... • Relational operator error • Arithmetic expression error • Condition testing methods focus on testing each condition in the program
    • 24 Strategies for Control Structure Testing Strategies proposed include- • Branch testing - execute every branch at least once. • Domain Testing - uses three or four tests for every relational operator. • Branch and relational operator testing - uses condition constraints
    • 25 Data Flow Testing • Selects test paths according to the location of definitions and use of variables.
    • 26 Loop Testing- Simple Loops Simple Loops of size n: – Skip loop entirely – Only one pass through loop – Two passes through loop – m passes through loop where m<n. – (n-1), n, and (n+1) passes through the loop.
    • 27 Loop Testing-Nested Loops Nested Loops • Start with inner loop. Set all other loops to minimum values. • Conduct simple loop testing on inner loop. • Work outwards • Continue until all loops tested.
    • 28 Break……………………………….
    • 29 Quiz • Is unit testing necessary and Why? • How many conditions can be there for Control structure testing? • How nested loop structure is tested? • What is BVA? • What are the checks for I/O operations? • What are the checks done in Static checking?
    • 30 Unit testing guidelines for Screen Based Systems
    • 31 General Considerations • Make sure that orientation of the place holders through out the screen should be uniform • Mandatory field should have a indicator along with the label. • Try to use uniform alert messages for similar error conditions. • Example : While checking for non-numeric input in a numeric field on one screen alert message “Non-numeric data. Please try again…” and on some other screen the alert “You have entered invalid data” should not come.
    • 32 General Considerations… • Timeout expired errors • Password configuration max length different from password entry box max length • Window resize problem - sometimes you cannot resize windows • Missing confirmation prompts for save or delete • When run a report it looks for a path from the programmer's machine • Keyboard shortcuts for menus and buttons missing the underline.
    • 33 Empty screen(without any data) • Screen layout should be checked with user screen specification or any standard screen layout which you want to follow through out • Check the functionality of buttons, valid responses as well as invalid responses. • Example : Submit, Next, Previous, Reset, Add, Update, Delete etc. • Ensure that their is no syntax related errors
    • 34 Cursor Positioning • While entering into the screen the cursor should not point to the field which is not editable • Cursor should not go to frame outline by using any cursor movement keys • After showing the Alert/Error Message for any field the cursor focus should come Option-1 : Old data value and chance is given to the user to correct it Option-2 : Old value should be deleted and cursor focus should be from the beginning of the filed. Out of this two options follow one through out the unit, module and package.
    • 35 Browser Related • If the browser text for largest text size (View-Text Size- Largest) is selected then the text inside the buttons should not spill over the button • Units/Modules should be tested in common browsers like IE, Firefox, Chrome, Safari etc. across mac, win and linux based systems.
    • 36 Screen Resolution related • Screens should be tested with different common resolutions like 800x600, 1024x768, 640x480 etc.
    • 37 Drop down related • Verify all the drop downs whether they have selectable items in them or not. • Drop down list options can be chosen carefully to convey the proper meaning. Example : “Employer Iden. No.”, one option in a drop down list can be written as “Employer Id. No.” for better clarity. • While making any drop down list pl. try to put all valid options first and then put the invalid option towards the end of the list. • Example : Gender – Instead of this you can write Male Unknown Female Male Female Unknown
    • 38 Labels related • All labels through out the screen should be uniform as far are font size, font type are concerned • Carefully choose the words for the labels & write down the labels with correct spelling – If the system is for USA then American Spelling. Example : “Organization” should be written as “Organization
    • 39 Labels related… • Labels should also be chosen correctly. Example : Instead of “Reference Id. Qual” we can write “Ref. Id. Qualifier” as in this case of “Qual” it can be either “Qualifier” or “Qualification”. • Any serial no., if any mentioned in the screen, should follow some standard. Suggestion : Either they should be like 1,2,3,…..10,11,12… or they can be 01,02,03,04……10,11,12….. But the mixture of two standards does not look nice.
    • 40 Invalid set of data • Pl. check that all the invalid set of data are rejected by the system. based on the design, each field may have different set of allowable characters and suitable validations. • Pl. check with different combinations of insufficient mandatory data. i.e. if there are 5 mandatory fields, try different combinations where at least one of them is missing.
    • 41 Invalid set of data… • Check with special characters, if they are not valid for that field • Check for the Null value • Mismatch of field length with column length of the table
    • 42 Valid set of Data • Check with minimal required data • Check with data in all the fields • Different valid combinations of empty & completed fields • Handling of Duplicate data • Functionality of different buttons, valid actions & invalid actions • Try quitting with saving and without saving • Try quitting before logical completion of work.
    • 43 Numeric Field • Pl. check for non numeric data • Pl. check for Integer or Decimal as per design/business rule – type validation • Check with out of range data – length validation • Check with minimum & maximum limit – boundary condition validation • In case of Amount/Cost/Price fields, there should not be any chance for truncation before decimal point or after decimal point.
    • 44 Special Character Checking • Check inputting of special characters like single- quote(‘), double (“), comma (,), greater than (>), less than (<) and ampersand (&) in all alphabetic as well as alphanumeric fields. • Also check for special characters like asterisk (*), hash (#), exclamation mark (!), question mark (?) etc. in all alphabetic as well as alphanumeric fields.
    • 45 Date validation • In case of Begin Date and End Date kind of entry in any screen, make sure that Begin Date should be <= End Date • Date validation format should be checked properly. Suggestion : if the format specified as CCYY/MM/DD then only dates with this formats should be accepted but not the dates with CCYY-MM-DD.
    • 46 Screen Navigation & Data flow • Try different combinations of navigations • Check for data entered on other screens, look for truncation, corruption, reformatting & other unwanted processing • In any screen check for the Navigation through <TAB> key and reverse-navigation through <shift-TAB> key.
    • 47 Quiz • What are various general checks to be carried out on each screen? • What are the checks for Invalid Data? • What are the checks for Numeric field? • What are the checks for Drop Down related fields? • What are the checks for Cursor Positioning?
    • 48 Thank you