Phase Testing: More examples 1. Review: Selecting Glass box test cases  Determine what to test (select types of coverage)  Create a flowchart for code.

Slides:



Advertisements
Similar presentations
การทดสอบโปรแกรม กระบวนการในการทดสอบ
Advertisements

10 Software Engineering Foundations of Computer Science ã Cengage Learning.
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Nov R McFadyen1 A Traditional Software Development Process Unit test Integration test System test Detailed design Architectural design Analysis.
Integration testing Satish Mishra
1 CODE TESTING Principles and Alternatives. 2 Testing - Basics goal - find errors –focus is the source code (executable system) –test team wants to achieve.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Object-Oriented Analysis and Design Lecture 10 Implementation (from Schach, “O-O and Classical Software Engineering”)
1 CSE1301 Computer Programming: Lecture 15 Flowcharts and Debugging.
Software Engineering Software Testing.
CS 425/625 Software Engineering Software Testing
Testing an individual module
1 CSE1301 Computer Programming: Lecture 15 Flowcharts, Testing and Debugging.
- Testing programs to establish the presence of system defects -
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 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 3 Object-Oriented Analysis of Library Management System(LMS)
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
1 Phase Implementation and Test Plan. Making your implementation plan First Steps  Consider your use case diagram and your prioritization of use cases.
1 Phase Implementation. Janice Regan, Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases)
Introduction Telerik Software Academy Software Quality Assurance.
CMSC 345 Fall 2000 Unit Testing. The testing process.
Software Testing.
Chapter 13: Implementation Phase 13.3 Good Programming Practice 13.6 Module Test Case Selection 13.7 Black-Box Module-Testing Techniques 13.8 Glass-Box.
1 Phase Testing. \ 2 Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards.
1 CMPT 275 Phase: Design. Janice Regan, Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance.
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.
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
1 Software Defect Testing Testing programs to establish the presence of system defects.
Software Testing Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Value and Reference Parameters. CSCE 1062 Outline  Summary of value parameters  Summary of reference parameters  Argument/Parameter list correspondence.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
Software testing techniques Software testing techniques Interface Testing Presentation on the seminar Kaunas University of Technology.
Chapter 8 Testing. Principles of Object-Oriented Testing Å Object-oriented systems are built out of two or more interrelated objects Å Determining the.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Chapter 7 Implementation. Implementation Approaches F Big bang –Code entire system and test in an unstructured manner F Top-down –Start by implementing.
CS451 Lecture 10: Software Testing Yugi Lee STB #555 (816)
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
CMPSC 16 Problem Solving with Computers I Spring 2014 Instructor: Tevfik Bultan Lecture 4: Introduction to C: Control Flow.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
1 CSE1301 Computer Programming: Lecture 16 Flow Diagrams and Debugging.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Software Test Plan Why do you need a test plan? –Provides a road map –Provides a feasibility check of: Resources/Cost Schedule Goal What is a test plan?
Chapter 4 Repetition Statements Program Development and Design Using C++, Third Edition.
Dynamic White-Box Testing What is code coverage? What are the different types of code coverage? How to derive test cases from control flows?
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Software Testing. SE, Testing, Hans van Vliet, © Nasty question  Suppose you are being asked to lead the team to test the software that controls.
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:
Dynamic Black-Box Testing Part 1 What is dynamic black-box testing? How to reduce the number of test cases using: Equivalence partitioning Boundary value.
© 2006 Pearson Education Chapter 3 Part 2 More about Strings and Conditional Statements Loops (for and while) 1.
Functional testing, Equivalence class testing
Testing Tutorial 7.
Chapter 9, Testing.
IS301 – Software Engineering V:
Input Space Partition Testing CS 4501 / 6501 Software Testing
Structural testing, Path Testing
UNIT-4 BLACKBOX AND WHITEBOX TESTING
“White box” or “glass box” tests
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
Chapter 2.1 Repetition.
Guide for writing a Software Testing Document
CSE 1020:Software Development
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

Phase Testing: More examples 1

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) \2

Review: Select 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 \3

Using Black-Box Testing Strategy  Back to our FindMean( ) function …  Consider its parameter, the score file float FindMean( FILE scoreFile ) { /* Reads scores (floats) from file scoreFile */ /* Sums and counts all positive scores */ /* Scores <=0 re not summed or counted */ /* Mean is 0 if count is 0, otherwise mean is */\ /* sum/count */. } \4

Equivalence classes for findMean( …) \5  5 equivalence classes have been defined for dataFile. 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 data file not opened validinvalid valid data file empty data file contains data >0 data file contains data <=0 valid Contains data

Using Black-Box Testing Strategy  Consider the parameter, the score file  Look at equivalence classes of the score file of type FILE (i.e., all possible values that can be assigned to this parameter), then select representative values:  variable of type FILE is null (e.g. score file does not exist, or could not be opened)  scoreFile is empty  scoreFile contains 1 score >0  scoreFile contains 1 score <0  scoreFile contains many scores > 0  scoreFile contains many scores < =0  scoreFile contains many scores both >0 and <=0 (mix?) \6

Back to Library Management System  … of textbook, at page 278, Figure 8.3 representing section of code of checkOutResource( ) method from the LibrarySystem class \7

Glass-Box Example: checkOutResource Public void checkoutResource(Patron patron, Resource resource) { if(patron.getTotalResourcesChecked() < 15) { if(resource.getStatus() == HAS_OVER_DUE); { if(resource.getStatus == AVAILABLE) { resource.checkout(patron); } else { new ErrorDialog("resource is NOT available"); } } else { newErrorDialog("Patron has Overdue Resources out"); } } else { newErrorDialog("Patron already has 15 items checked out"); } } \

checkOutResource( ) Example \ T F F F T T b c e f d a g h start finish

checkOutResource( ) Example - 1  Will need at least 4 unit test cases to test checkOutResource( ) method with Patron and Resource objects (statement coverage)  Test case id – 1: Patron has borrowed < 15 resources, none of these resources are overdue, and the resource is available  Statement Coverage – Start Finish  Test case id – 2: Patron has borrowed < 15 resources and none are overdue but the resource is not available  Statement Coverage – Start Finish  Test case id – 3: Patron has borrowed < 15 resources but at least one resource is overdue  Statement Coverage – Start Finish  Test case id – 4: Patron has borrowed 15 or more resources  Statement Coverage – Start-1-7-Finish \10

checkOutResource( ) Example - 1  Will need at least 4 unit test cases to test checkOutResource( ) method with Patron and Resource objects (branch coverage)  Test case id – 1: Patron has borrowed < 15 resources, none of these resources are overdue, and the resource is available  Branch Coverage – Start- a-d-f-g-h-Finish  Test case id – 2: Patron has borrowed < 15 resources and none are overdue but the resource is not available  Branch Coverage – Start- a-d-e-g-h-Finish  Test case id – 3: Patron has borrowed < 15 resources but at least one resource is overdue  Branch Coverage – Start- a-c-g-h-Finish  Test case id – 4: Patron has borrowed 15 or more resources  Branch Coverage – Start- a-b-h-Finish \11

Library Management System  representing section of code of checkOutResource( ) method from the LibrarySystem class  Same 4 tests give 100% statement coverage and 100% branch coverage  Start- a-b-h-Finish  Start- a-c-g-h-Finish  Start- a-d-e-g-h-Finish  Start- a-d-f-g-h-Finish  What about path coverage?  No loops in code being tested so do not need to consider path coverage. \12

Special Issues for Testing Object- Oriented Systems  Inheritance and polymorphism makes testing more difficult by requiring more contexts (all sub classes) for testing an inherited module \13

checkOutResource( ) Example  The impact of inheritance and polymorphism in unit testing the method checkOutResource( ) is such that the number of test cases will grow from 4 to 64:  Let's look at each of the four test cases separately and determine how many test cases result when inheritance in considered  For simplicity assume that borrowing limits are the same for each type of patron (15 maximum), that there are 4 types of patron and 7 types of resource \14

checkOutResource( ) Example  Test case id – 1: Patron has borrowed < 15 resources, none of these resources are overdue, and the resource is available. There are 4 types of patron. Branch Coverage – Start- a-d-f-g-h-Finish  test case id – 1.1 -> Faculty has borrowed less than 15 resources none of these resources are overdue, and the resource is available.  test case id – 1.2 -> Student has borrowed less than 15 resources  test case id – 1.3 -> Library Staff has borrowed less than 15 resources  test case id – 1.4 -> Local resident has borrowed less than 15 resources \15

checkOutResource( ) Example  Test case id – 1.1: Faculty has borrowed < 15 resources (all of the same type), none of these resources are overdue, and the resource is available. There are 7 types of resource Branch Coverage – Start- a-d-f-g-h-Finish  test case id – > Faculty has borrowed less than 15 resources none of these resources are overdue, and the book is available.  test case id – > … and the video is available  test case id – > … and the CD is available  test case id – > … and the software is available  test case id – > … and the research material is available  test case id – > … and the on line research resource is available  test case id – > … and the reserve resource is available  For this test case there are at least 4*7=28 tests \16

checkOutResource( ) Example  Test case id – 2: Patron has borrowed < 15 resources, none of these resources are overdue, and the resource is not available. There are 4 types of patron. Branch Coverage – Start- a-d-f-g-h-Finish  test case id – 2.1 -> Faculty has borrowed less than 15 resources none of these resources are overdue, and the resource is not available.  test case id – 2.2 -> Student has borrowed less than 15 resources …  test case id – 2.3 -> Library Staff has borrowed less than 15 resources …  test case id – 2.4 -> Local resident has borrowed less than 15 resources … \17

checkOutResource( ) Example  Test case id – 2.1: Faculty has borrowed < 15 resources (all of the same type), none of these resources are overdue, and the resource is available. There are 7 types of resource Branch Coverage – Start- a-d-e-g-h-Finish  test case id – > Faculty has borrowed less than 15 resources none of these resources are overdue, and the book is not available.  test case id – > … and the video is not available  test case id – > … and the CD is not available  test case id – > … and the software is not available  test case id – > … and the research material is not available  test case id – > … and the on line research resource is not available  test case id – > … and the reserve resource is not available  For this test case there are at least 4*7=28 tests \18

checkOutResource( ) Example  Test case id – 3: Patron has borrowed < 15 resources, at least one of these resources is overdue,. There are 4 types of patron. Branch Coverage – Start- a-c-g-h-Finish  test case id – 3.1 -> Faculty has borrowed less than 15 resources and at least one of these resources is overdue  test case id – 3.2 -> Student has borrowed less than 15 resources and at least one of these resources is overdue  test case id – 3.3 -> Library Staff has borrowed less than 15 resources and at least one of these resources is overdue  test case id – 3.4 -> Local resident has borrowed less than 15 resources and at least one of these resources is overdue … \19

checkOutResource( ) Example  test case id – 4 -> Test case id – 4: Patron has borrowed 15 or more resources Branch Coverage – Start- a-b-h-Finish  test case id – 4.1 -> Faculty has borrowed 15 or more resources  test case id – 4.2 -> Student has borrowed 15 or more resources  test case id – 4.3 -> Library Staff has borrowed 15 or more resources  test case id – 4.4 -> Local resident has borrowed 15 or more resources  For this test case there are 4 tests.  For this case the type of resource is not critical since no methods from class resource will be used \20

Example Summary: Testing Object-Oriented Systems  Inheritance and polymorphism makes testing more difficult by requiring more contexts (all sub classes) for testing an inherited module  In our example we see that the inheritance of patron (4 inherited cases) and resource (7 inherited cases) causes the number of test cases to increase from 4 to  4*7+4*7+4+4=64 \21

Integration Test Cases  Four kinds of integration tests (read text)  Structure tests  Functional tests  Stress tests  Performance tests  For us, in 275, we shall focus on  Functional tests \22

Integration Test Case Example  Example of Thread implementation approach  Consider Deliverable 7.2 Implementation Plan Diagram, in textbook at page 246  Sub phase 1: CheckOutResource, CheckInResource  Sub phase 2: ManageResource  Sub phase 3: ManagePatron  Sub phase 4: BrowseResource, RequestResource, ReserveResource \23

LMS Implementation plan diagram  Order based on importance of each use case as expressed by the user/client \24 Library staff browseResource requestResource reserveResource manageResource checkInResource checkOutResource resource patron managePatron genFormLetter Overdue form letter Phase 4 Phase 1 Phase 2 Phase 3

Integration Test Case Example  Test id - 53A  Test purpose: Integration testing “ManageResource” build, specifically “RemoveResource” scenario  Requirement # 8, 9 10, 14, 15  Inputs: Quantum Physics book call # D  Testing procedure:  Evaluation: try to check out Quantum Physics book  Expected behaviours and results: call # is invalid  Actual behaviours and results \25

System Test Case  For us, in 275, our system test case is our User Manual \26