CSCE 747 Software Testing and Quality Assurance

Slides:



Advertisements
Similar presentations
Testing “Multiple Conditions” with Decision Table Technique
Advertisements

CHAPTER 40 Probability.
Overview Functional Testing Boundary Value Testing (BVT)
Decision-Table Test Case Generation. DT terminology 2.
Decision Table Based Testing
14004 L5 - © D. Deugo, Lecture 5 Combinational Models (Binder chapter 6)
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
Equivalence Class Testing
Testing an individual module
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Introduction to Software Testing Chapter 3.1 Logic Coverage Paul Ammann & Jeff Offutt.
Chapter 5 Retrospective on Functional Testing Software Testing
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Equivalence Class Testing
Modeling and Design of Rule-Based Systems Yonglei Tao.
Lecture 17: Digital Design Today’s topic –Intro to Boolean functions Reminders –HW 4 due Wednesday 10/8/2014 (extended) –HW 5 due Wednesday 10/15/2014.
By Asst.Prof.Dr. Wararat Songpan (Rungworawut) Faculty of Computer Science, Department of Science, Khon Kaen University, Thailand 1 Chapter 3: Equivalence.
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
1 Software Testing & Quality Assurance Lecture 14 Created by: Paulo Alencar Modified by: Frank Xu.
Cause & Effect Graph Comparison Testing. Cause & Effect Graph This is basically a hardware testing technique adapted to software testing. It considers.
Lec 06 Path Testing Part II - 1 CSCE 747 Fall 2013 CSCE 747 Software Testing and Quality Assurance Lecture 06 – Path Testing Part II 9/16/
1 Equivalence Class Testing Chapter 6. 2 Introduction Boundary Value Testing derives test cases with Massive redundancy Serious gaps Equivalence Class.
Overview Functional Testing Boundary Value Testing (BVT)
Equivalence Class Testing In chapter 5, we saw that all four variations of boundary value testing are vulnerable to –gaps of untested functionality, and.
Introduction to Software Testing Chapter 3.1 Logic Coverage Paul Ammann & Jeff Offutt.
Decision Table Based Testing Outline Decision table vocabulary –Limited Entry Decision Tables (LEDT) –Extended Entry Decision Tables (EEDT) –Mixed Entry.
Write a function rule for a graph EXAMPLE 3 Write a rule for the function represented by the graph. Identify the domain and the range of the function.
1 Software Testing. 2 Equivalence Class Testing 3 The use of equivalence class testing has two motivations: –Sense of complete testing –Avoid redundancy.
Equivalence Class Testing Use the mathematical concept of partitioning into equivalence classes to generate test cases for Functional (Black-box) testing.
Boundary Value Testing
1 Sections 7.2 – 7.7 Nested Control Statements Fundamentals of Java: AP Computer Science Essentials, 4th Edition Lambert / Osborne.
Dr. ClincyLecture Slide 1 CS6020- Chapter 3 (3A and ) Dr. Clincy Professor of CS First Exam - Tuesday, September 6th Coverage: All subjects up to.
Kiểm thử và đảm bảo chất lượng phần mềm
Cause & Effect Graph Comparison Testing
Chapter 3: Equivalence Class Testing :EC Software Testing
Elementary and Middle School Mathematics Teaching Developmentally
Digital Logic.
IT316 Software Requirement Engineering
Decision Table Testing
DeMorgan’s Theorem DeMorgan’s 2nd Theorem
Input Space Partition Testing CS 4501 / 6501 Software Testing
Angles In Triangles Types of Triangles Isosceles triangle
Chapter 5 Retrospective on Functional Testing Software Testing
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage
EEL 3705 / 3705L Digital Logic Design
Overview Functional Testing Boundary Value Testing (BVT)
Chapter 9 Path Testing–Part 1
CSCE 747 Software Testing and Quality Assurance
Angles In Triangles Types of Triangles Isosceles triangle
Equivalence Class Testing
Independent Variable:
Developing More Complex Decision Trees
AP STATISTICS LESSON 4 – 3 ( DAY 1 )
CSCE 747 Software Testing and Quality Assurance
DESICION TABLE Decision tables are precise and compact way to model complicated logic. Decision table is useful when input and output data can be.
CSCE 747 Software Testing and Quality Assurance
Chapter 3 – Combinational Logic Design
Design Example “Date of Birth Problem”
ISP Coverage Criteria CS 4501 / 6501 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.
Logic Gates Truth Table Challenge
Pruning 24-Feb-19.
Overview Functional Testing Boundary Value Testing (BVT)
Boolean Expressions to Make Comparisons
This Lecture Substitution model
Overview Functional Testing Boundary Value Testing (BVT)
Black-Box Testing Techniques II
Laws & Rules of Boolean Algebra
CSCE 747 Software Testing and Quality Assurance
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage
Presentation transcript:

CSCE 747 Software Testing and Quality Assurance Lecture 04 – Decision Tables Based Testing 9/9/2013

Jorgensen, Paul C. Software Testing 12/29/2018 Last Time Equivalence Class Testing Revision Control Systems Git intro Today Decision Table Based Testing Ch 7 pp 103-116 Decision Trees Decision Tables for Business Logic Decision Tables for Testing Jorgensen, Paul C. Software Testing A Craftsman Approach

Decision Trees - CSCE 510 2013 - http://en.wikipedia.org/wiki/Decision_tree

Decision Tables http://en.wikipedia.org/wiki/Decision_table

Jorgensen, Paul C. Software Testing Decision Tables Decision tables have been used to represent and analyze complex logical relationships since the early 1960s. Ideal for describing situations in which a number of combinations of actions are taken under varying sets of conditions Capture “Business Logic” Capture = describe = document = display for stakeholders Jorgensen, Paul C. Software Testing A Craftsman Approach

Decision Tables Support Completeness Decision table with boolean conditions like rotated truth table Supports complete coverage of the logic Testing based on decision tables enforce logical rigor. Related methods are used: cause–effect graphing (Elmendorf, 1973; Myers, 1979) and the decision tableau method (Mosley, 1993). Jorgensen, Paul C. Software Testing A Craftsman Approach

Decision Table for Triangle Problem01 Jorgensen, Paul C. Software Testing A Craftsman Approach

Decision Tables to Test Cases “To identify test cases with decision tables, we: Interpret conditions as inputs and actions as outputs. Sometimes conditions end up referring to equivalence classes of inputs, and Actions refer to major functional processing portions of the item tested. The rules are then interpreted as test cases. Because the decision table can mechanically be forced to be complete, we know we have a comprehensive set of test cases.” Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing A Craftsman Approach

NextDate Decision tables What are meaningful decisions for NextDate? Months M1 ={ months that have 30 days} M2 ={ months that have 31 days} M3 ={February} Days D1 ( ), D2( ), D3( ), D4( ) Years Y1(2000), Y2(non-century-leap-year), Y3() So how big is the table? 9 boolean tests  210=1024 3*4*3 Jorgensen, Paul C. Software Testing A Craftsman Approach

When conditions refer to equivalence classes In NextDate Consider equivalence class = sameLengthMonth Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing Rule Counts Rule Count – number of corresponding cases Note sum of counts = 64 for complete truth table Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing A Craftsman Approach

Rule Counts for NextDate Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing Consider Equivalence Relation M X D Eg. 2.3 = equivalence class M2 X D3 Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing Impossible Rules Impossible Rules – cases that cannot happen Jorgensen, Paul C. Software Testing A Craftsman Approach

Redundancy in Decision Tables Here rules 4 and rule 9 are identical; redundant Jorgensen, Paul C. Software Testing A Craftsman Approach

Redundancy OK; but Inconsistency? Now consider rules 4 and 9 Jorgensen, Paul C. Software Testing A Craftsman Approach

Test Cases for the Triangle Problem 3 impossible 3 not triangle 1 equilateral 1 scalene 3 isosceles ? means invalid Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing NextDate Try1 8 boolean conditions  28 =256 cases Jorgensen, Paul C. Software Testing A Craftsman Approach

Test Cases for NextDate Invalid actions a1: Day invalid for this month a2: Cannot happen in a non-leap year a3: Compute the next date 3([months])*4([days])*3([year]) = 36 equiv classes [x] = equivalence classes <m,d,y> 36 equiv. classes on M x D x Y 36 rules/test cases – reducing by combining rules with don’t care cases yields 16 rules Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing NextDate 2nd Try Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing But Problems Remain December problems in rule 8 Feb 28 problems in 9, 11 and 12 So new decomposition M1 = {month : month has 30 days} M2 = {month : month has 31 days except December} M3 = {month : month is December} M4 = {month : month is February} D1 = {day : 1 ≤ day ≤ 27} D2 = {day : day = 28} D3 = {day : day = 29} D4 = {day : day = 30} D5 = {day : day = 31} Y1 = {year : year is a leap year} Y2 = {year : year is a common year} note author eliminated Y3 to make tables smaller Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing Compressing the Table Combining columns Table for 11-22 in text Jorgensen, Paul C. Software Testing A Craftsman Approach

NextDate Decision Table Test cases Jorgensen, Paul C. Software Testing A Craftsman Approach

Decision Table for Commission Problem Not well suited Very little decision logic Variables truly independent  no impossible cases as in NextDate 3 equivalence classes: Commission1, commission2, commission3 Jorgensen, Paul C. Software Testing A Craftsman Approach

Guidelines and Observations Decision table approach appropriate for applications with Prominent if-then-else logic Logical relationships among input variables Calculations involving subsets of inputs Decision tables do not scale up well Iteration helps. Start then refine. Jorgensen, Paul C. Software Testing A Craftsman Approach

Jorgensen, Paul C. Software Testing Homework Consider a NextMonth function NextMonth(Feb, 15, 2000) = (March, 15, 2000) NextMonth(jan, 30, 2000) =? There are multiple correct answers here. Your answer here will affect #2. Develop a decision table for NextMonth function (not ignoring days) Jorgensen, Paul C. Software Testing A Craftsman Approach