Black-Box Testing Techniques III

Slides:



Advertisements
Similar presentations
Testing and Test Case Development A “primitive” method of testing, with NO test preparation, may include the following steps : – Initiate the system –
Advertisements

White-Box Testing Techniques IV
Test Case Design: Strategies, Techniques & Models Robin Brennan, Senior Consultant Quality Assurance Institute.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Boundary Value Testing A type of “Black box” functional testing –The program is viewed as a mathematical “function” –The program takes inputs and maps.
Black box testing  Black box tests focus on the input/output behavior of the component  Black-box tests do not deal with the internal aspects of the.
Bellevue University CIS 205: Introduction to Programming Using C++ Lecture 3: Primitive Data Types.
Software Testing and Quality Assurance
Testing an individual module
1 Functional Testing Motivation Example Basic Methods Timing: 30 minutes.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Verificarea şi Validarea Sistemelor Soft Tem ă Laborator 2 Testare Black Box Dat ă primire laborator: Lab 2 Dat ă predare laborator: Lab 2,3.
Black-Box Testing Techniques I Software Testing Lecture 4.
University of Palestine software engineering department Testing of Software Systems Test-Case Design instructor: Tasneem Darwish.
Black-Box Testing Techniques II Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 5.
Agenda Introduction Overview of White-box testing Basis path testing
Black-Box Testing Techniques I
1 Software Testing. 2 Path Testing 3 Structural Testing Also known as glass box, structural, clear box and white box testing. A software testing technique.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Black-box Testing.
CS 217 Software Verification and Validation Week 7, Summer 2014 Instructor: Dong Si
Case Study: Black-Box Testing Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 6.1.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
Theory and Practice of Software Testing
1 Software Testing & Quality Assurance Lecture 5 Created by: Paulo Alencar Modified by: Frank Xu.
Boundary Value Testing 1.A type of “Black box” functional testing –The program is viewed as a mathematical “function” –The program takes inputs and maps.
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
Boundary Value Testing
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
Testing Data Structures
Functional testing, Equivalence class testing
Software Engineering (CSI 321)
DATA TYPES.
Software TestIng White box testing.
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
White-Box Testing Techniques IV
Software Testing.
G&W Chapter 22: Test Cases Software Specification Lecture 29
(State) Model-Based Approaches I Software Specification Lecture 35
The Joy of Breaking Code Testing Logic and Case Selection
White-Box Testing Techniques IV
Black-Box Testing Techniques I
Input Space Partition Testing CS 4501 / 6501 Software Testing
Case Study: Black-Box Testing
CS5123 Software Validation and Quality Assurance
Structural testing, Path Testing
White-Box Testing Techniques
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
White-Box Testing Techniques II
Software Development Cycle
UNIT-4 BLACKBOX AND WHITEBOX TESTING
White-Box Testing Techniques III
White-Box Testing Techniques II
Black-Box Testing Techniques III
Software Engineering Lecture #13.
Software Engineering Lecture #12.
White-Box Testing Techniques III
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
White-Box Testing Techniques I
CSE403 Software Engineering Autumn 2000 More Testing
Institute of Computing Tech.
Black-Box Testing Techniques II
Chapter 1: Boundary Value Testing
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Black-Box Testing Techniques II
Overview Functional Testing Boundary Value Testing (BVT)
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Unit III – Chapter 3 Path Testing.
Presentation transcript:

Black-Box Testing Techniques III Software Testing and Verification Lecture 6 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Another Cause-Effect Example: Symbol Table Storage Specification The conditions for storing an identifier in one of two symbol tables are: (a) must be from 2 to 8 characters in length; (b) first character must be a letter or “$”; (c) other characters must be a letter or digit. If the first character is a letter, the identifier will be stored in symbol table A. If the first character is “$”, it will be stored in symbol table B. If the first character is neither a letter nor “$”, or if condition (c) is not satisfied, error message J11 is output. If condition (a) is not satisfied, error message J12 is output.

Causes and Effects Causes: Effects: (1) 2  no. chars  8 (31) store in table A (2) 1st char is letter (32) store in table B (3) 1st char is $ (33) output msg J11 (4) other chars only letters/digits (34) output msg J12 only (35) output msgs J11 and J12

Boolean Graphs [2,8] let $ (1) (2) (3) (4) (31) (32) −> A −> B E others let/dig

Boolean Graphs (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (31) (32) −> A −> B E others let/dig

Boolean Graphs (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (31) (32) −> A −> B E Л  others let/dig

Boolean Graphs (cont’d) [2,8] let $ (1) (2) (3) (4) (33) (34) (35) J11 only J12 only J11 & J12 E others let/dig

Boolean Graphs (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (33) (34) (35) J11 only J12 only J11 & J12 Л  E (A) V  (B) others let/dig

Boolean Graphs (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (33) (34) (35) J11 only J12 only J11 & J12 Л  Л  E (A) V  (B) others let/dig

Boolean Graphs (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (33) (34) (35) J11 only J12 only J11 & J12 Л  Л  E (A) V  (B) Л  others let/dig

A Variation on Test Case Selection Strategy #3 Test case selection “Strategy #3” (p. 32) considers ALL feasible combinations of connected Cause values that result in each Effect being True. For complex specifications, this can be impractical. We now consider a variation on this strategy which “culls” all but the combinations “of greatest interest”.

Test Case Selection Strategy #3 Plus “Culling Rules” REPEAT Select the next (initially, the first) Effect. Tracing back through the graph (right to left), find all feasible combinations of connected Cause values that result in the Effect being True, subject to the following culling rules: When encountering an nth-degree OR-node that must be True, consider only those n combinations for which exactly one incoming edge is True.

Test Case Selection Strategy #3 Plus “Culling Rules” (cont’d) When encountering an nth-degree AND-node that must be False, consider only those n combinations for which exactly one incoming edge is False. For each new such combination found: Determine values of all other Effects, and Enter values for each Cause and Effect in a new column of the test case coverage matrix. UNTIL each Effect has been selected.

Rationale for these Culling Rules? Number of combinations decreases by a factor of O(2 ) to O(n) at each true OR node and each false AND node. Idea: cover only the minimally sufficient conditions for the desired result. n ( ( V Л T F

Applying Strategy #3 Plus Culling Rules [2,8] let $ (1) (2) (3) (4) Л  (31) (32) −> A −> B E Л  others let/dig

Coverage Matrix TEST CASES CAUSES 1 2 3 4 5 6 7 8 9 10 2  no. chars  8 (1) T 1st char is letter (2) 1st char is $ (3) F others letters/digits (4) EFFECTS store in table A (31) store in table B (32) output J11 only (33) output J12 only (34) output J11 & J12 (35)

Applying Strategy #3 Plus Culling Rules (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (31) (32) −> A −> B E Л  others let/dig

Coverage Matrix (cont’d) TEST CASES CAUSES 1 2 3 4 5 6 7 8 9 10 2  no. chars  8 (1) T 1st char is letter (2) F 1st char is $ (3) others letters/digits (4) EFFECTS store in table A (31) store in table B (32) output J11 only (33) output J12 only (34) output J11 & J12 (35)

Applying Strategy #3 Plus Culling Rules (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (33) (34) (35) J11 only J12 only J11 & J12 Л  Л  E (A) V  (B) Л  others let/dig

Applying Strategy #3 Plus Culling Rules (cont’d) (33)  1, B B  (A V 4)  (4, A) V (4, A) V (4, A) (T,T) (T,F) (F,T) culled (rule 1)

Applying Strategy #3 Plus Culling Rules (cont’d)

Applying Strategy #3 Plus Culling Rules (cont’d)

Applying Strategy #3 Plus Culling Rules (cont’d) 1, 4, 2, 3

Applying Strategy #3 Plus Culling Rules (cont’d) 1, 4, 2, 3

Applying Strategy #3 Plus Culling Rules (cont’d)  (2, 3) V (2, 3) V (2, 3) (F,F) (F,T) (T,F) culled (rule 2) and infeasible 1, 4, 2, 3

Applying Strategy #3 Plus Culling Rules (cont’d) (33)  1, 4, 2, 3 1, 4, 2, 3 1, 4, 2, 3

Coverage Matrix (cont’d) TEST CASES CAUSES 1 2 3 4 5 6 7 8 9 10 2  no. chars  8 (1) T 1st char is letter (2) F 1st char is $ (3) others letters/digits (4) EFFECTS store in table A (31) store in table B (32) output J11 only (33) output J12 only (34) output J11 & J12 (35)

Applying Strategy #3 Plus Culling Rules (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (33) (34) (35) J11 only J12 only J11 & J12 Л  Л  E (A) V  (B) Л  others let/dig

Applying Strategy #3 Plus Culling Rules (cont’d) (34)  1, B B  (4 V A)  4, A

Applying Strategy #3 Plus Culling Rules (cont’d)

Applying Strategy #3 Plus Culling Rules (cont’d)

Applying Strategy #3 Plus Culling Rules (cont’d)  (2, 3) V (2, 3) V (2, 3) (F,F) (F,T) (T,F) culled (rule 2) and infeasible

Applying Strategy #3 Plus Culling Rules (cont’d) (34)  1, 4, 2, 3  1, 4, 2, 3

Coverage Matrix (cont’d) TEST CASES CAUSES 1 2 3 4 5 6 7 8 9 10 2  no. chars  8 (1) T F 1st char is letter (2) 1st char is $ (3) others letters/digits (4) EFFECTS store in table A (31) store in table B (32) output J11 only (33) output J12 only (34) output J11 & J12 (35)

Applying Strategy #3 Plus Culling Rules (cont’d) [2,8] let $ (1) (2) (3) (4) Л  (33) (34) (35) J11 only J12 only J11 & J12 Л  Л  E (A) V  (B) Л  others let/dig

Applying Strategy #3 Plus Culling Rules (cont’d) (35)  1, B Which are just the conditions associated with error messages J11 (B) and J12 (1). Combining these conditions from (33) and (34) yields: (35)  1, 4, 2, 3 1, 4, 2, 3 1, 4, 2, 3

Coverage Matrix (cont’d) TEST CASES CAUSES 1 2 3 4 5 6 7 8 9 10 2  no. chars  8 (1) T F 1st char is letter (2) 1st char is $ (3) others letters/digits (4) EFFECTS store in table A (31) store in table B (32) output J11 only (33) output J12 only (34) output J11 & J12 (35)

Complete Coverage Matrix TEST CASES CAUSES 1 2 3 4 5 6 7 8 9 10 2  no. chars  8 (1) T F 1st char is letter (2) 1st char is $ (3) others letters/digits (4) EFFECTS store in table A (31) store in table B (32) output J11 only (33) output J12 only (34) output J11 & J12 (35)

Cause-Effect Analysis: Discussion Questions & Exercises Under what circumstances should Cause-Effect Analysis be used for test case design? Are there any other obvious benefits? What are the pros and cons of having a set of mutually exclusive Effects?

Cause-Effect Analysis: Discussion Questions & Exercises (cont’d) Suppose that some program Effect is associated with integer input X being either  30 or even. What are the pros and cons of defining { X | X  30 V EVEN(X) } to be a Cause? Devise a scenario that illustrates some creative ideas for how a well-engineered CASE tool could effectively support Cause-Effect Analysis.

Cause-Effect Analysis: Discussion Questions & Exercises (cont’d) Cause-Effect Analysis seems well suited for “single-state-transition” program models in which Causes are mapped to Effects in one conceptual step. How could you apply the strategy to multi-state-transition program models?

Boundary Value Analysis A technique based on identifying, and generating test cases to explore boundary conditions. Boundary conditions are an extremely rich source of errors. Natural language based specifications of boundaries are often ambiguous, as in “for input values of X between 0 and 40,...”

Boundary Value Analysis (cont’d) May be applied to both input and output conditions. Also applicable to white box testing (as will be illustrated later).

Guidelines for Identifying Boundary Values “Range” guideline: K will range in value from 0.0 to 4.0. Identify values at the endpoints of the range and just beyond. Boundary values: 0.0- (I) 0.0 (V) 4.0 (V) 4.0+ (I)

Guidelines for Identifying Boundary Values (cont’d) “Number of values” guideline: The file will contain 1-25 records. Identify the minimum, the maximum, and values just below the minimum and above the maximum. Boundary values: empty file (I), file with 1 (V), 25 (V), and 26 (I) records

Boundary Value Analysis Exercise Identify appropriate boundary values for the following program specification fragment.

City Tax Specification 1: The first input is a yes/no response to the question “Do you reside within the city?” The second input is gross pay for the year in question. A non-resident will pay 1% of the gross pay in city tax. Residents pay on the following scale: - If gross pay is no more than $30,000, the tax is 1%. - If gross pay is more than $30,000, but no more than $50,000, the tax is 5%. - If gross pay is more than $50,000, the tax is 15%.

Test Case Design Based on Intuition and Experience Also known as Error Guessing, Ad Hoc Testing, Artistic Testing, etc. Testers utilize intuition and experience to identify potential errors and design test cases to reveal them. Guidelines: Design tests for reasonable but incorrect assumptions that may have been made by developers. (cont’d)

Intuition and Experience (cont’d) Guidelines: (cont’d) Design tests to detect errors in handling special situations or cases. Design tests to explore unexpected or unusual program use or environmental scenarios.

Intuition and Experience (cont’d) Examples of data conditions to explore: (1) (2) Repeated instances or occurrences (3) Repeated instances or occurrences (4) Bl anks or null char acters in strings (eT c.) (-5) Negative numbers (#) Non-numeric values in numeric fields (or vic3 versa) (6789) Inputs that are too long or too short

Intuition and Experience (cont’d) Testing based on intuition and experience can be extremely effective. Test plans should reflect the explicit allocation of resources for this activity. Consider the “Try to break our system –lunch is on us” example…

Intuition and Experience Exercise Using intuition and experience, identify tests you would want to design for a subroutine that is to input and sort a list of strings based on a user-specified field.

Black-Box Testing Techniques III Software Testing and Verification Lecture 6 Prepared by Stephen M. Thebaut, Ph.D. University of Florida