1 Phase Testing. \ 2 Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards.

Slides:



Advertisements
Similar presentations
Equivalence Partitioning
Advertisements

DETAILED DESIGN, IMPLEMENTATIONA AND TESTING Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Testing in the Small (aka Unit Testing, Class Testing)
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
1 CSE1301 Computer Programming: Lecture 15 Flowcharts and Debugging.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
CS 425/625 Software Engineering Software Testing
Testing an individual module
Review CSC 171 FALL 2004 LECTURE 21. Topics Objects and Classes Fundamental Types Graphics and Applets Decisions Iteration Designing Classes Testing and.
1 CSE1301 Computer Programming: Lecture 15 Flowcharts, Testing and Debugging.
Recall The Team Skills Analyzing the Problem
OHT 9.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Chapter 9.3 Software Testing Strategies.
1 Functional Testing Motivation Example Basic Methods Timing: 30 minutes.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Verificarea şi Validarea Sistemelor Soft Tem ă Laborator 2 Testare Black Box Dat ă primire laborator: Lab 2 Dat ă predare laborator: Lab 2,3.
RUP Requirements RUP Artifacts and Deliverables
Introduction Telerik Software Academy Software Quality Assurance.
UNIT TESTING. Plan project Integrate & test system Analyze requirements Design Maintain Test units Implement Software Engineering Roadmap Identify corporate.
9/18/2015CPSC , CPSC , Lecture 121 Software Engineering, CPSC , CPSC , Lecture 12.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Case Study: Game2D with Method Design
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Unit Testing -Ranjit Shewale Contents  Scope  Owner  Approach  Conventional approach  Object oriented approach  Tips for the.
Chapter 5 Functions For All Subtasks. Void functions Do not return a value. Keyword void is used as the return type in the function prototype to show.
Software Testing. 2 CMSC 345, Version 4/12 Topics The testing process  unit testing  integration and system testing  acceptance testing Test case planning.
Testing Testing Techniques to Design Tests. Testing:Example Problem: Find a mode and its frequency given an ordered list (array) of with one or more integer.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Today’s Agenda  Reminder: HW #1 Due next class  Quick Review  Input Space Partitioning Software Testing and Maintenance 1.
Unit Testing LEVEL GAME.  Create pieces array  Call move or interact  Use getters or return type to verify correct behavior  Test ends (don’t go GameEngine.BOARD_SIZE-1)
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
CSC 480 Software Engineering Testing - I. Plan project Integrate & test system Analyze requirements Design Maintain Test units Implement Software Engineering.
Protocols Software Engineering II Wirfs Brock et al, Designing Object-Oriented Software, Prentice Hall, Mitchell, R., and McKim, Design by Contract,
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Phase Testing: More examples 1. Review: Selecting Glass box test cases  Determine what to test (select types of coverage)  Create a flowchart for code.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
CS451 Lecture 10: Software Testing Yugi Lee STB #555 (816)
Documenting a function. Documenting a function definition We have a template for information that we need you to put at the top of each function - if.
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
Chapter 12: Software Testing Omar Meqdadi SE 273 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Fusion Design Overview Object Interaction Graph Visibility Graph Class Descriptions Inheritance Graphs Fusion: Design The overall goal of Design is to.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Defect testing Testing programs to establish the presence of system defects.
Testing It is much better to have a plan when testing your programs than it is to just randomly try values in a haphazard fashion. Testing Strategies:
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
Testing 1. Aims To understand the purpose of testing To understand the different test strategies To explore the four types of test data Have a understanding.
Boxes. boxes- learning targets o I will be able to display buttons (boxes) o I will be able to organize boxes o I will be able to create an animation.
Software Testing. Software Quality Assurance Overarching term Time consuming (40% to 90% of dev effort) Includes –Verification: Building the product right,
Functional testing, Equivalence class testing
Domain Testing Functional testing which tests the application by giving inputs and evaluating its appropriate outputs. system does not accept invalid and.
Recall The Team Skills Analyzing the Problem
Testing Approaches.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Navigating huge (UE4 (rendering)) code
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
Software testing.
Chapter 10 – Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
CSE 1020:Software Development
TYPES OF TESTING.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

1 Phase Testing

\ 2 Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards For each subphase Implement Methods in class/es Code review Unit test Create integration Test plan Create unit Test plans Release unit for integration Integration Testing System Testing Create system Test plan

\ 3 Review: Selecting Glass box test cases  Determine what to test (select types of coverage)  Create a flowchart for code to be tested  Select test cases such that  For a method with only sequential statements, 100% statement coverage will be achieved  For a method with sequential statements and branches 100% branch coverage will be achieved in addition to 100% statement coverage  For a method that also includes iterative statements try to approach 100% path coverage as closely as possible with a reasonable number of tests. (assure statement and branch coverage)

\ 4 Black Box Testing  We treat software system as a black box  We cannot see inside, i.e., we knows nothing about  source code  internal data  design documentation  So what do we know then?  Public interface of the function or class (methods, parameters)  Class skeleton (pre and post conditions, description, invariants)  Test cases are selected based on  input values or situation  expected behaviour and output of methods

\ 5 Select Set of Test Cases using Black Box Testing Strategy 1. Determine what to test  Which method of which class, type of test 2. For each parameter and object a) Establish the parameters equivalence classes OR consider that various states of object  Determine all valid (invalid) values or all ranges of valid (invalid) values, and boundaries between those ranges.  Determine valid and invalid states of objects (preconditions) b) Select representative values for each equivalence class (one from each range, and boundary values) to use as basis of your test cases

\6 Example Test case: (from text)  Code being tested:  Method in a board game. setDot(…)  Turns dots in a grid on and off  Assuming that the grid is to be 15 by 15

\ 7 From Skeleton: setDot(int i, int j, int c) Public void setDot( int i, int j, int c) // send message to the Graphical_Cell object which is the //element at row i and column j in the grid array. Set the // dot to color c. i and j are both less than 15 //precondition: the 2_D array of Graphical_Cell objects //has been instantiated. c has value 1 or 2 //postcondition: Graphical_Cell object shows that a dot at //row i and column j is displayed with color c.  Use the information -1 < i,j < 15, and 0 < c < 3 to define equivalence classes for the variables  Use the information Graphical_Cell object has been instantiated to define equivalence classes for object Graphical_Cell

\ 8 Equivalence classes for c, i and j  3 equivalence classes have been defined for each variable. Each colored bar shows one equivalence class. The equivalence classes define where each variable is valid and invalid.  Next, the equivalence classes can be used to help choose test values for each variable 0-14 >14 ijc <0 validinvalid 0-14 >14<0 valid invalid 1-2 >2 <1 validinvalid

\ 9 Choosing Representative test values i, j  How to choose representative values for tests based on equivalence classes:  Consider variables i and j:  Choose one value from each equivalence class for i -3, 6, 18  Choose one value from each equivalence class for j -4, 8, 17  Choose boundary values between each pair of equivalence classes, -1, 0 and 14, 15. For variables i and j use test values  i: -3, -1, 0, 6, 14, 15, 18  j: -4, -1, 0, 8, 14, 15, >14 i or j <0 validinvalid

\ 10 Choosing Representative test values c  Consider variable c  Choose one value from each equivalence class -2, 2, 5  Choose boundary values between each pair of equivalence classes, 0,1 and 2, 3.  For variable c use test values  -2, 0, 1, 2, 3, >2 i or j <1 validinvalid

\ 11 Choosing Representative test values Graphical_Cell Not instantiated Graphical_Cell Graphical_Cell has two possible states, instantiated (consistent with precondition) or not instantiated (inconsistent with precondition) Each colored bar shows one equivalence class instantiated valid invalid

\ 12 Equivalence classes for grid or Graphical_Cell Not instantiated Graphical_Cell Consider the object, Graphical_Cell. has two possible states, instantiated, not instantiated In designing test cases use two possible states, instantiated, not instantiated instantiated valid invalid

\ 13 What test values have we selected?  For variable i use test values  -3, -1, 0, 6, 14, 15, 18  For variable j use test values  -4, -1, 0, 8, 14, 15, 17  For variable c use test values  -2, 0, 1, 2, 3, 5  For object, Graphical_Cell.  instantiated, not instantiated  For optimal testing coverage we would use all possible combinations of these values (2*6*7*7=588 tests).  In practice will usually choose a subset of possible combinations which reflects the best test coverage with a more reasonable number of tests.

\ 14 Choosing a subset: an example  You may wish to consider the following  Testing with all valid variables and preconditions  Testing with all valid variables and only one invalid precondition (for each precondition in turn)  Testing with all valid preconditions and one invalid variable (for each variable in turn, one sample from each invalid equivalence class)  Testing with all valid preconditions and a boundary value for each variable  Testing with pairs of invalid variables?  What else is needed ?

\ 15 Proposed subset - 1  1 -- All variables in the valid range  i=6 j= 8 c = 1 Graphical_ Cell instantiated  2 -- All variables in the valid range  i=6 j= 8 c = 1 Graphical_ Cell not instantiated  3 – i, and c valid j invalid  i=6 j= 17 c = 1 Graphical_ Cell instantiated  4 – i, and c valid j invalid (different equivalence class value)  i=3 j= -4 c = 1 Graphical_ Cell instantiated  5 -- j, and c valid i invalid  i=-3 j= 8 c = 1 Graphical_ Cell instantiated  6 -- j, and c valid i invalid  i=18 j= 8 c = 1 Graphical_ Cell instantiated

\ 16 Proposed subset - 2  7 -- i, and j valid c invalid  i=6 j= 8 c = 5 Graphical_ Cell instantiated  8 -- i, and j valid c invalid  i=6 j= 8 c = -2 Graphical_ Cell instantiated  9 – i, and c valid j invalid  i=15 j= 14 c = 1 Graphical_ Cell instantiated  10 – i, and c valid j invalid (different equivalence class value)  i=14 j= 15 c = 1 Graphical_ Cell instantiated  j, and c valid i invalid  i=-1 j= 0 c = 2 Graphical_ Cell instantiated  j, and c valid i invalid  i=0 j= -1 c = 2 Graphical_ Cell instantiated

\17 Proposed subset - 3  i, and j valid c invalid  i=0 j= 14 c = 0 Graphical_ Cell instantiated  i, and j valid c invalid  i=14 j= 0 c = 3 Graphical_ Cell instantiated  15 – i, and c valid j invalid  i=0 j= 14 c = 1 Graphical_ Cell instantiated  16 – i, and c valid j invalid (different equivalence class value)  i=14 j= 0 c = 2 Graphical_ Cell instantiated

\ 18 Test Case Example  Test id - 1  Test purpose: Unit test Game2DClient class method setDot( ) (page271) using Black box testing strategy  Requirement # 4  Inputs: i = 6, j = 8, c = 1 (blue), grid has been instantiated  Testing procedure:  Create an object of Game2DClient class type  Show grid (to demonstrate dot is not set before call to setDot)  Call setDot( i = 6, j = 8, c = 1 )  Evaluation: Show grid  Expected behaviours and results: blue dot now showing at location (6, 8) on grid  Actual behaviours and results:

\ 19 Test Case Example  Test id - 2  Test purpose: Unit test Game2DClient class method setDot( ) (page271) using Black box testing strategy  Requirement # 4  Inputs: i = 6, j = 8, c = 1 (blue), grid has NOT been instantiated  Testing procedure:  Create an object of Game2DClient class type without a grid  Call setDot( i = 6, j = 8, c = 1 )  Evaluation: no step required  Expected behaviours and results: message stating that grid does not exist  Actual behaviours and results:

\ 20 Test Case Example  Test id - 11  Test purpose: Unit test Game2DClient class method setDot( ) (page271) using Black box testing strategy  Requirement # 4  Inputs: i = -1, j = 0, c = 2 (blue), grid has been instantiated  Testing procedure:  Create an object of Game2DClient class type  Show grid (could set other dots)  Call setDot( i = -1, j = 0, c = 2 )  Evaluation: Show grid  Expected behaviours and results: grid should be unchanged and a message stating that the location for the new blue dot is erroneous  Actual behaviours and results: