Software Testing. 2. Models. 2. Models. Testing Approaches. Why Models? (in Testing) (Based on Part II: Models of Testing Object-Oriented Systems)
|
|
- Kimberly Henry
- 5 years ago
- Views:
Transcription
1 2. Models (Based on Part II: Models of Testing Object-Oriented Systems) Software Testing 2. Models Models - Why? What? How? Combinational Models - Decision Tables: What? How? - Test Generation State Machines - What? (variants: Mealy & Moore) - State Transition Tables (State-to-state, Event-to-state) - The FREE State Model (State? Transition?) - Test Generation (N+) Chapter 2 2 (Smart) Poking Around Testing Approaches Brute Force Testing is a search problem Why Models? (in Testing) Models are what distinguishes craft from engineering! trillions and trillions of possible input and state combinations! only a few will reach, trigger and propagate bugs Systematic & Focused Solutions? Brute force does not work at this scale Poking around inefficient + false feeling of confidence. Model based = systematic, focused and automated - Systematic: we try every target combination (target! model) - Focused: where are bugs likely? (likely! fault model) - Automated: more tests; more repeatable test (tools! model) 3 4
2 What is a Model? (in Testing) Scope: Testing, Validation, Checking, Verification Covered in this course! ENGINEERING MODELS subject - e.g. airplanes, buildings, weather, economics TEST MODELS subject - e.g. implementation, component, under test point of view/theory - e.g. gravitation, air-pressure, law of demand and offer point of view/theory - required behaviour, where are bugs likely? representation - wire frame image, blueprint - mathematical equations representation - graphs (nodes & edges), - checklists technique - skill and expertise of modeler matters technique - experience with requirements, design, required behaviour Validation observed behaviour 5 Cartoons vs. Models CARTOONS sketching, refining, documentation - initial analysis, design, potentially (TEST) MODELS Specify precisely - what is allowed what is NOT allowed - complete - unambiguous - consistent - not integrated - different models (representing various perspectives) are coherent Completeness Checking Consistency Checking component representation yilit sab ting n spo Tes x] Re sed bo ba ck Verification (checklists, proofs) [no execution] a [Bl Implementationbased Testing [White box] component implementation 6 2. Models (Based on Part II: Models of Testing Object-Oriented Systems) Models - Why? What? How? Combinational Models - Decision Tables: What? How? - Test Generation State Machines necessarily - incomplete - ambiguous - inconsistent meta-model - What? (variants: Mealy & Moore) - State Transition Tables (State-to-state, Event-to-state) - The FREE State Model (State? Transition?) - Test Generation (N+) 7 8
3 Decision Table: example Decision Table: alternative views Annual renewal of a hypothetical car insurance policy Condition Section Variant # Claims # Insured Age Premium Increase Action Section Send Warning 1 0 <= No No 2 >= No No 3 1 <= Yes No 4 >= No No 5 2 to 4 <= Yes No 6 >= Yes No 7 5 or more Any 0 No Yes Implicit Assumptions Logical operator to interpret a row? (AND) Cancel Can a person of 15 really be insured? And what about 99? Decision Tree None 1 Number of Claims 2-4 >= 5 <= 25 Age >= 26 <= 25 Age >= 26 <= 25 Age >= 26 Cancel $50, no letter $25, no letter $100, send warning letter $50, no letter $400, send warning letter $200, send warning letter Conditi on Section Action Section Number of Claims Insured Age Premium increase Send warning easier to understand (an program) possibility to overlook a case Variant >= 5 <= 25 >= 26 <= 25 Column wise view >= 26 <= 25 >= Any No No Yes No Yes Yes No Cancel No No No No No No Yes 9 10 Combinational Models: Basic Approach Identify decision variable and conditions APPLICABLE? One of several distinct responses is to be selected according to distinct cases of input variables (finite!) - input cases are mutually exclusive response is independent of - order of input variables - prior input or output prefer small tables (combinational explosion) typical for business rules, simple protocols (locks), STEPS 1) identify the decision variables and conditions - n condition 2 n variants 2) identify the resultant actions to be selected or controlled 3) identify which actions should be produced in response to particular combinations of conditions 4) derive the logic function - via truth table - validate completeness and consistency 11 decision table with n conditions 2 n variants usually fewer variants, only explicit variants are listed Implicit variants? don t care: condition true or false, doesn t change the action - e.g.: when # claims >= 5, then age is don t care condition can t happen: condition which is assumed never to become true - e.g.: insured age < 16 or 18 (age when driving is allowed) - can sometimes occur when context changes (Ariane crash) - must be tested explicitly (sometimes is a surprise ) don t know: is an incomplete model - e.g. what happens with an age > 300? can t happen + don t know (+ don t care): typical source for bugs - specify resulting action anyway (defaults) - test for the result 12
4 Deriving the logic function: truth table Logic function: only boolean variables as input and output Expression consisting solely of AND, OR, XOR, NOT + conditions Convert decision table to truth table; truth table into expression Decision Variable Variant Condition Condition section Number of claims 0 T T F F F F F 1 F F T T F F F 2-4 F F F F T T F 5+ F F F F F F T Insured Age 25 or younger T F T F T F DC 26 or older F T F T F T DC Action Premium increase = 0 F F F F F F T section Premium increase = 25 F T F F F F F Premium increase = 50 T F F T F F F Premium increase = 100 F F T F F F F Premium increase = 200 F F F F F T F Premium increase = 400 F F F F T F F Send warning F F T F T T F Cancel F F F F F F T 13 Deriving the Logic Function: logic minimization reduce logic function to compact but equivalent expression - fewer test cases are needed - faster testing (automated) - may reveal omissions or inconsistencies Initial Development Logic Minimization Technique -- inspection s KV matrix s Cause-effect graph s Quine-McCluskey method s Starner-Dietmeyer s Exact minimization s Heuristic minimization upper limit, number of boolean variables 14 Incorrect value assigned to a decision variable Incorrect or missing operator in a predicate Incorrect or missing variable in a predicate Incorrect structure in a predicate - dangling else, misplaced semicolon, Incorrect or missing default case Incorrect or missing action(s) Extra actions Structural error in decision table implementation - falling through (i.e. a missing break in C++), incorrect value for an index or action selector Missing or incorrect class or method signature - when variants are implemented via polymorphism Generic errors Decision Table: Fault Model No empirical models about distribution of faults! - wrong version, incorrect or missing specification item, ambiguous All-Explicit Variants - Most intuitive approach - 1 test case for each explicit variant of all decision variables - example: 0 claims, 1 claim, 2-4 claims, 5+ claims, 25 or younger, 26 or older Applicable Test Generation: All-Explicit Variants - decision tables with non-binary variables - weak for undefined can t happen situations - weak when boundaries are undefined (=> don t know situation) Also apply non binary variable domain analysis 15 16
5 All-Variants, All-True, All-False, All-Primes Start from truth table (+ corresponding boolean function) All-Variants: every variant in the table is tested once - 2 n possibilities: works only for smaller tables All-True: every variant that produces TRUE - equivalent to testing all minterms of logical function - inappropriate when important actions follow from false variants All-False: every variant that produces FALSE - equivalent to testing complement of all minterms of logical function - inappropriate when important actions follow from true variants All-Primes: each prime implicant of boolean function at least once - i.e. each product term in a minimal sum-of-products form of boolean expression All-true, all-false, all-primes may miss critical bugs!! Each-Condition/All-Condition each variable is made true once, with all other variables being false + one test case where all variables are true (and logic) + one test case where all variables are false (or logic) Binary Decision Diagram Determinants Starts from the truth table - Produces a binary-decision diagram (see book p ) - Map the diagram into a determinant table (see book p ) Variable Negation Starts from sum-of-products boolean formula - unique true points: - near false points: Nonbinary Variable Domain Analysis More test generation techniques domain testing (inluding boundary values) on decision variables Decision Table Test Suite Size Inclusion Hierarchy Test Strategy Test size, Binary Decision Variables Test Size, Nonbinary Decision Variables Test Power All-Variants All-Variants 2 n 2 n * 4 n 100% Basic Variable Negation 0.1 * 2 n 0.1 * 2 n * 4n 97% Each Condition/All- Conditions m + " L(pi) (m + " L(pi)) * 4n? All-True All-False All BDD Determinants d d * 4n? All-True t t * 4n? All-False f f * 4n? Each-Condition/ All-Conditions Basic Variable Negation BDD Determinants All-Primes m m * 4n? All-Explicit x x * 4n? For non-binary decision variable we have an expression (A <= x <= B) All-Primes test x = A - 1, x = A + 1, x = B -1, x = B # tests may become smaller for ranges where x are adjacent 19 20
6 2. Models (Based on Part II: Models of Testing Object-Oriented Systems) Models - Why? What? How? Combinational Models - Decision Tables: What? How? - Test Generation State Machines - What? (variants: Mealy & Moore) - State Transition Tables (State-to-state, Event-to-state) - The FREE State Model (State? Transition?) - Test Generation (N+) = system whose output is determined by both current and past input (with Decision tables, only current input influences result) identical inputs are not always accepted identical inputs may produce different outputs State machine consists of 4 building blocks State: an abstraction that summarizes the past inputs Transition: an allowable two-state sequence - accepting and resulting state - Caused by an event; may result in an action! Guarded transition: event + guard predicate Event: an input (or an interval of time) Action: the result or output that follows an event What is a state machine? Special states: initial state, current state, final state MEALY State Machine transitions are active - may have output action - any output action may be used in more than one transition states are passive Mathematically equivalent Variants: Mealy and Moore MOORE State Machine transitions are passive states are active - may have output action - every output action has at least one state MEALY is preferred for engineering design UML allows both! - Hybrids are bad for test design! p1_winsvolley() [this.p1.score()< 20] / this.p1addpoint() Two-player Squash: Mealy State Machine p1_start()/ player1 served p1_winsvolley() [this.p1.score()== 20] / this.p1addpoint() p1_iswinner()/ return TRUE player1 won game started p1_winsvolley()/ / p2_start()/ player2 served player2 won [this.p2.score()< 20] / this.p2addpoint() [this.p2.score()== 20] / this.p2addpoint() p2_iswinner()/ return TRUE 23 24
7 Two-player Squash: Moore State Machine p1_start() Player1 serving Player1 won p1_addpoint() game started p1_winsvolley() Player1 continues p1_addpoint() p1_winsvolley() [this.p1_score() < 20] p1_winsvolley() p1_iswinner() p1_winsvolley() Answering Player1 won return TRUE; p1_winsvolley() [this.p1_score() == 20] p1_iswinner() p2_start() Player2 serving Player2 continues p2_addpoint() [this.p2_score() == 20] Player2 won p2_addpoint() p2_iswinner() Answering Player2 won return TRUE; [ ] p2_iswinner() State Transition Tables state-to-state format row = accepting state; column = resulting state cell = transition = event (with guard) + action event-to-state format row = event (with guard); column = accepting state cell = transition = action + resultant state expanded state-to-state format 2 state-to-state tables: 1 for events and 1 for actions separates the transition function and output function Example: State-to-state Example: Event-to-state Current State Game Started Player 1 served Player 2 served Player 1 won Player 2 won Game Started Resultant State/Event/Action Player 1 Served Player 2 Served Player 1 Won Player 2 Won p1_start() p1_winsvolley() [p1 score < 20] this.p1addpoint(), SimulateVolley() p1_winsvolley() p2_start() p2_winsvolley() p2_winsvolley() [p2 score < 20] this.p2addpoint(), SimulateVolley() p1_winsvolley() [p1 score == 20] p1_iswinner() return TRUE p2_winsvolley() [p2 score == 20] p2_iswinner() return TRUE Current State/Action/Next State Event Guard Game Started Player 1 Served Player 2 Served Player 1 Won Player 2 Won p1_start() p2_start() p2_winsv olley() p1_winsv olley() p1_iswinn er() DC (don t care) p2_score < 20 p2_score == 20 Player 1 Served Player 2 Served Player 2 Served this.p2addpoint(), Player 2 Served this.p2addpoint() Player 2 Served return TRUE Player 1 Won 27 28
8 Flattened Regular Expression (FREE) class under test is flattened - all inherited features are collapsed in class under test - assume type-substitution principle! instance of a class may be substituted by an instance of a subclass model behaviour as state machine restrictions to UML statechart notation few changes to UML statechart notation (e.g., alpha/omega states) - can be expressed in UML results in testable model - no ambiguities (among others precise definition of state ) - automatic generation of test cases The FREE State Model A particular subset of a class combinational value set! Represented by a State Invariant (predicate) Account.balance What is State? Class Account { private: AccountNumber number; Money balance; Date lastupdate} states Account.number Account.lastUpdate Open State Inactive State Implications What is a Transition? state invariant defines a subset of legal values for a class - state invariant is same or stronger than class invariant - method postconditions + state invariants = all states don t use hybrids (i.e. no mixing of Mealy and Moore) alpha state - null state: represent declared object before construction - accept only constructor, new, (alpha transition) - is NOT the same as the UML initial state (solid circle) omega state - null state: reached after deletion, destruction, out of scope - accepted explicit or implicit destructors (omega transition) - is NOT the same as the UML final state (bulls-eye) alpha-omega cycle Transition = 1 state invariant for accepting state 1 state invariant for resulting state 1 associated event - message sent to the class under test - interrupt or similar external control (timer, ) [optional guard expression] - predicate expression evaluated in the context of class under test 0 or more actions - message sent to a server object of the class under test - response provided by an object of the class under test 31 32
9 What should happen when a state machine in a given state receives an event not specified for this state? ignore - standard semantics for state machines - unacceptable for testing purposes omitted - incomplete specification: extend the state machine illegal (or impossible ) - illegal event = valid event, not acceptable for the current state (e.g. pop() on an empty stack) - if accepted results in an illegal transition Sneak path Unspecified Event/State Pairs - beware: guarded transitions, what if the guard is FALSE? - transition to an Illegal event exception state Response Matrix = Modified event-to-state table ROWS: list events + guards - unguarded event: 1 row - guarded event: 1 row for each unique event/guard combination! one row for each truth combination of subexpressions + additional column for all sub expressions! if event is sometimes guarded, then include a don t care column COLUMNS: list Accepting states CELLS: list responses - error codes for possible responses Response Matrix Response Matrix: Possible Responses 0. Accept (perform specified transition) 1. Queue (queue event for subsequent evaluation and ignore) 2. Ignore 3. Flag (return a non zero error code) 4. Reject (raise an exception) 5. Mute (disable the source of events and ignore) 6. Abend (invoke abnormal termination and halt process) Example: Response Matrix Accepting State/Expected Response Events Guards alpha A B C omega constructor event 1 x == 0 DC F T event 2 i > 10 k == max isreset() DC DC DC F F F F F T F T F destructor
10 s states, e events, a actions gives (s x a) es possible implementations! 5 states, 2 events and 2 actions: 10 billion possibilities! only one correct implementation Possible faults missing or incorrect transition missing or incorrect event missing or incorrect action an extra, missing or corrupt state State Based Testing: Fault Model a sneak path (a message is accepted when it shouldn t be) an illegal message failure (unexpected message causes a failure) trap door (implementation accepts undefined messages) No empirical models about distribution of faults! Verify the State Model structure check-list (Table 7.5) - structurally complete and consistent state name check-list (Table 7.6) - avoid weak, ambiguous or inappropriate state names guarded transition check-list (Table 7.7) - check logic and structure of guard expressions flattened machine check-list (Table 7.8) - free of level-to-level conflicts - consistent behaviour for inheritance tree - reuse of superclass test suites robustness check-list (Table 7.9) - safe and correct behaviour under failure modes Test Generation State Machine Coverage N+ Test Generation Features - exercise all implicit transitions to reveal sneaky paths - implementation must be able to report current state state reporter methods (available? encapsulation?) Steps - Develop a FREE model + Derive response matrix - Generate round-trip test cases via Transition Tree (see p. 249) cover all branches (= transitions) at least once identify parameter values, expected state and exception - Generate sneak path test cases cover all branches with unspecified transitions verify response + resulting state - Sensitize the transitions find input values for all guards Based on years of experience with state-based testing of hardware and telecomunications infrastructure All Transitions - every specified transition at least once All n-transition sequences - every specified transition sequence of n events All round-trip Paths - every sequence of specified transitions beginning and ending in the same state is exercised at least once M-Length Signature (when state reporter methods are absent) - signature = sequence of output actions unique for given state - verify whether we reached the given state by verifying signature 39 40
11 Conclusion Models - Why? What? How? Combinational Models - Decision Tables: What? How? - Test Generation State Machines - What? (variants: Mealy & Moore) - State Transition Tables (State-to-state, Event-to-state) - The FREE State Model (State? Transition?) alpha-omega cycle - Test Generation (N+) 41
Software Testing. 2. Models. 2. Models. Testing Approaches. Why Models? (in Testing) (Based on Part II: Models of Testing Object-Oriented Systems)
2. Models (Based on Part II: Models of Testing Object-Oriented Systems) Software Testing 2. Models Models Why? What? How? Combinational Models Decision Tables: What? How? Test Generation State Machines
More informationMotivation State Machines
Motivation State Machines Generating test cases for complex behaviour Textbook Reading: Chapter 7 We are interested in testing the behaviour of object-oriented software systems Behaviour: Interactions
More informationState-Based Testing Part B Error Identification. Generating test cases for complex behaviour
State-Based Testing Part B Error Identification Generating test cases for complex behaviour Reference: Robert V. Binder Testing Object-Oriented Systems: Models, Patterns, and Tools Addison-Wesley, 2000,
More informationDecision tables. Combinational Models. Necessary Characteristics of the Implementation. Decision tables. Deriving decision tables
ombinational Models Generating test cases when the test model is a decision table Textbook Reading: hapter 6 ecision tables Ideal representation for a test model for the following reasons: Straightforward
More informationdoor Sasa Berberovic
door Sasa Berberovic Overview Reusable Components Subsystems Reusable Components Reuse Mechanisms The Role of Testing in Reuse Reusing Test Suites Test Design Patterns Abstract Class Test Generic Class
More informationClass Modality. Modality Types. Modality Types. Class Scope Test Design Patterns
Class Scope Test Design Patterns Testing methods in isolation is not enough Instance variables act like global variables within a class Need to test intraclass interactions Message sequences Class Modality
More informationBłaej Pietrzak
Błaej Pietrzak blazej.pietrzak@cs.put.poznan.pl Fault model Result-oriented testing Test design approach Domain testing model Category-Partition test pattern Polymorphic message test pattern 1 Exhaustive
More information17. Assertions. Outline. Built-in tests. Built-in tests 3/29/11. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen
17. Assertions Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen Outline Introduction (BIT, assertion, executable assertion, why?) Implementation-based vs responsability-based assertions Implementation
More information17. Assertions. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen
17. Assertions Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen Outline Introduction (BIT, assertion, executable assertion, why?) Implementation-based vs responsability-based assertions Implementation
More informationNOTES ON OBJECT-ORIENTED MODELING AND DESIGN
NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationTopic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia
Topic: Software Verification, Validation and Testing Software Engineering Faculty of Computing Universiti Teknologi Malaysia 2016 Software Engineering 2 Recap on SDLC Phases & Artefacts Domain Analysis
More informationSemantics via Syntax. f (4) = if define f (x) =2 x + 55.
1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)
More informationChapter 5 Selection Statements. Mr. Dave Clausen La Cañada High School
Chapter 5 Selection Statements Mr. Dave Clausen La Cañada High School Objectives Construct and evaluate Boolean expressions Understand how to use selection statements to make decisions Design and test
More informationIntroduction. The Quine-McCluskey Method Handout 5 January 24, CSEE E6861y Prof. Steven Nowick
CSEE E6861y Prof. Steven Nowick The Quine-McCluskey Method Handout 5 January 24, 2013 Introduction The Quine-McCluskey method is an exact algorithm which finds a minimum-cost sum-of-products implementation
More informationBłaej Pietrzak Goal. Two approaches. Process. If we limit testing to method scope
Błaej Pietrzak blazej.pietrzak@cs.put.poznan.pl Class scope integration Design by Contract Invariant Boundaries pattern Non-modal class pattern FREE state model Quasi-modal class pattern Modal class pattern
More informationPart I: Preliminaries 24
Contents Preface......................................... 15 Acknowledgements................................... 22 Part I: Preliminaries 24 1. Basics of Software Testing 25 1.1. Humans, errors, and testing.............................
More informationAXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop
AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language
More informationSoftware Design and Analysis for Engineers
Software Design and Analysis for Engineers by Dr. Lesley Shannon Email: lshannon@ensc.sfu.ca Course Website: http://www.ensc.sfu.ca/~lshannon/courses/ensc251 Simon Fraser University Slide Set: 2 Date:
More informationSubsystem Hazard Analysis (SSHA)
Subsystem Hazard Analysis (SSHA) c "!$#%! Examine subsystems to determine how their Normal performance Operational degradation Functional failure Unintended function Inadvertent function (proper function
More informationLecture 15 Software Testing
Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered
More informationSample Question Paper. Software Testing (ETIT 414)
Sample Question Paper Software Testing (ETIT 414) Q 1 i) What is functional testing? This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type
More informationLecture Notes on Binary Decision Diagrams
Lecture Notes on Binary Decision Diagrams 15-122: Principles of Imperative Computation William Lovas Notes by Frank Pfenning Lecture 25 April 21, 2011 1 Introduction In this lecture we revisit the important
More informationRedundant States in Sequential Circuits
Redundant States in Sequential Circuits Removal of redundant states is important because Cost: the number of memory elements is directly related to the number of states Complexity: the more states the
More informationIntroduction to Dynamic Analysis
Introduction to Dynamic Analysis Reading assignment Gary T. Leavens, Yoonsik Cheon, "Design by Contract with JML," draft paper, http://www.eecs.ucf.edu/~leavens/jml//jmldbc.pdf G. Kudrjavets, N. Nagappan,
More informationTesting Object-Oriented Software. 22 November 2017
Testing Object-Oriented Software 22 November 2017 Testing Object-Oriented Software 2 Problems in object-oriented testing [Binder] Each level in the class hierarchy creates a new context for inherited features:
More informationCombinational Logic Circuits Part III -Theoretical Foundations
Combinational Logic Circuits Part III -Theoretical Foundations Overview Simplifying Boolean Functions Algebraic Manipulation Karnaugh Map Manipulation (simplifying functions of 2, 3, 4 variables) Systematic
More informationIntroduction to Software Testing Chapter 3, Sec# 1 & 2 Logic Coverage
Introduction to Software Testing Chapter 3, Sec# 1 & 2 Logic Coverage Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/soft waretest/ Ch. 3 : Logic Coverage Four Structures for Modeling Software
More informationProgramming Languages Third Edition. Chapter 9 Control I Expressions and Statements
Programming Languages Third Edition Chapter 9 Control I Expressions and Statements Objectives Understand expressions Understand conditional statements and guards Understand loops and variation on WHILE
More informationChapter 5 System modeling
Chapter 5 System Modeling Lecture 1 1 Topics covered Context models Interaction models Structural models Behavioral models Model-driven driven engineering 2 System modeling System modeling is the process
More informationReferences: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationTheme 2 Program Design and Testing
Theme 2 Program Design and Testing Systematic Testing 1 Learning Objectives to present a few systematic testing techniques that increase the chance of finding defects while keeping the number of test cases
More informationBlack-box Testing Techniques
T-76.5613 Software Testing and Quality Assurance Lecture 4, 20.9.2006 Black-box Testing Techniques SoberIT Black-box test case design techniques Basic techniques Equivalence partitioning Boundary value
More informationSOFTWARE DESIGN COSC 4353 / Dr. Raj Singh
SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a
More informationChapter 3. Set Theory. 3.1 What is a Set?
Chapter 3 Set Theory 3.1 What is a Set? A set is a well-defined collection of objects called elements or members of the set. Here, well-defined means accurately and unambiguously stated or described. Any
More informationGiovanni De Micheli. Integrated Systems Centre EPF Lausanne
Two-level Logic Synthesis and Optimization Giovanni De Micheli Integrated Systems Centre EPF Lausanne This presentation can be used for non-commercial purposes as long as this note and the copyright footers
More informationDiscrete Mathematics Lecture 4. Harper Langston New York University
Discrete Mathematics Lecture 4 Harper Langston New York University Sequences Sequence is a set of (usually infinite number of) ordered elements: a 1, a 2,, a n, Each individual element a k is called a
More informationChapter 8 Software Testing. Chapter 8 Software testing
Chapter 8 Software Testing 1 Topics covered Introduction to testing Stages for testing software system are: Development testing Release testing User testing Test-driven development as interleave approach.
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical
More informationInput Space Partitioning
Input Space Partitioning Instructor : Ali Sharifara CSE 5321/4321 Summer 2017 CSE 5321/4321, Ali Sharifara, UTA 1 Input Space Partitioning Introduction Equivalence Partitioning Boundary-Value Analysis
More informationLecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationAn Introduction to Systematic Software Testing. Robert France CSU
An Introduction to Systematic Software Testing Robert France CSU Why do we need to systematically test software? Poor quality products can Inconvenience direct and indirect users Result in severe financial
More informationOverview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing.
Overview CS 619 Introduction to OO Design and Development ing! Preliminaries! All sorts of test techniques! Comparison of test techniques! Software reliability Fall 2012! Main issues: There are a great
More informationFortgeschrittene objektorientierte Programmierung (Advanced Object-Oriented Programming)
2014-03-07 Preface Fortgeschrittene objektorientierte Programmierung (Advanced Object-Oriented Programming) Coordinates: Lecturer: Web: Studies: Requirements: No. 185.211, VU, 3 ECTS Franz Puntigam http://www.complang.tuwien.ac.at/franz/foop.html
More informationVerification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process
Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1
More informationTest Requirement Catalog. Generic Clues, Developer Version
Version 4..0 PART 1: DATA TYPES Test Requirement Catalog SIMPLE DATA TYPES... 4 BOOLEAN... 4 CASES... 4 COUNTS... 5 INTERVALS... 5 [LOW, HIGH] an interval that contains both LOW and HIGH... 6 [LOW, HIGH)
More informationM301: Software Systems & their Development. Unit 4: Inheritance, Composition and Polymorphism
Block 1: Introduction to Java Unit 4: Inheritance, Composition and Polymorphism Aims of the unit: Study and use the Java mechanisms that support reuse, in particular, inheritance and composition; Analyze
More informationPropositional Logic. Application of Propositional logic
DISCRETE STRUCTURE Propositional Logic Application of Propositional logic Propositional logic is the study of propositions (true or false statements) and ways of combining them (logical operators) to
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationPrinciples of Testing and Analysis. COMP 4004 Fall Notes Adapted from Dr. A. Williams
Principles of Testing and Analysis COMP 4004 Fall 2008 Notes Adapted from Dr. A. Williams Software Quality Assurance Lec 3 1 Principles of Testing and Analysis Sensitivity Redundancy Restriction Partition
More informationIntroduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt www.introsoftwaretesting.com Ch. 3 : Logic Coverage Four Structures for Modeling Software Graphs Logic Input Space
More informationIntroduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/softwaretest/ Ch. 3 : Logic Coverage Four Structures for Modeling Software Graphs
More informationSoftware Service Engineering
Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language
More informationTesting and Debugging
Testing and Debugging Comp-303 : Programming Techniques Lecture 14 Alexandre Denault Computer Science McGill University Winter 2004 March 1, 2004 Lecture 14 Comp 303 : Testing and Debugging Page 1 Announcements...
More informationContents. Chapter 3 Combinational Circuits Page 1 of 34
Chapter 3 Combinational Circuits Page of 34 Contents Contents... 3 Combinational Circuits... 2 3. Analysis of Combinational Circuits... 2 3.. Using a Truth Table... 2 3..2 Using a Boolean unction... 4
More informationCSE 5317 Midterm Examination 4 March Solutions
CSE 5317 Midterm Examination 4 March 2010 1. / [20 pts] Solutions (parts a j; -1 point for each wrong answer, 0 points for each blank answer, 2 point for each correct answer. Therefore, the score for this
More informationCSE 403: Software Engineering, Fall courses.cs.washington.edu/courses/cse403/16au/ Unit Testing. Emina Torlak
CSE 403: Software Engineering, Fall 2016 courses.cs.washington.edu/courses/cse403/16au/ Unit Testing Emina Torlak emina@cs.washington.edu Outline Software quality control Effective unit testing Coverage
More information1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.
1. true / false By a compiler we mean a program that translates to code that will run natively on some machine. 2. true / false ML can be compiled. 3. true / false FORTRAN can reasonably be considered
More informationCS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING
1 CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING Outline 2 Quiz Black-Box Testing Equivalence Class Testing (Equivalence Partitioning) Boundary value analysis Decision Table Testing 1 3 Quiz - 1
More information12 Tutorial on UML. TIMe TIMe Electronic Textbook
TIMe TIMe Electronic Textbook 12 Tutorial on UML Introduction......................................................2.................................................3 Diagrams in UML..................................................3
More informationCombinational Logic & Circuits
Week-I Combinational Logic & Circuits Spring' 232 - Logic Design Page Overview Binary logic operations and gates Switching algebra Algebraic Minimization Standard forms Karnaugh Map Minimization Other
More informationIntegration Testing Qualidade de Software 2
Integration Testing Integration Testing Software systems are built with components that must interoperate Primary purpose: To reveal component interoperability faults so that testing at system scope may
More informationWhy testing and analysis. Software Testing. A framework for software testing. Outline. Software Qualities. Dependability Properties
Why testing and analysis Software Testing Adapted from FSE 98 Tutorial by Michal Young and Mauro Pezze Software is never correct no matter what developing testing technique is used All software must be
More informationConcepts of Programming Languages
Concepts of Programming Languages Lecture 10 - Object-Oriented Programming Patrick Donnelly Montana State University Spring 2014 Patrick Donnelly (Montana State University) Concepts of Programming Languages
More informationCOURSE 2 DESIGN PATTERNS
COURSE 2 DESIGN PATTERNS CONTENT Fundamental principles of OOP Encapsulation Inheritance Abstractisation Polymorphism [Exception Handling] Fundamental Patterns Inheritance Delegation Interface Abstract
More informationLecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page:
Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 17 Concepts of Object Oriented Design Object-Oriented
More information(See related materials in textbook.) CSE 435: Software Engineering (slides adapted from Ghezzi et al & Stirewalt
Verification (See related materials in textbook.) Outline What are the goals of verification? What are the main approaches to verification? What kind of assurance do we get through testing? How can testing
More informationAssertions. Assertions - Example
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationThe testing process. Component testing. System testing
Software testing Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating system
More information6.001 Notes: Section 8.1
6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything
More informationPropositional Calculus. CS 270: Mathematical Foundations of Computer Science Jeremy Johnson
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson Propositional Calculus Objective: To provide students with the concepts and techniques from propositional calculus
More informationChapter 10 Classes Continued. Fundamentals of Java
Chapter 10 Classes Continued Objectives Know when it is appropriate to include class (static) variables and methods in a class. Understand the role of Java interfaces in a software system and define an
More informationUnit 4: Formal Verification
Course contents Unit 4: Formal Verification Logic synthesis basics Binary-decision diagram (BDD) Verification Logic optimization Technology mapping Readings Chapter 11 Unit 4 1 Logic Synthesis & Verification
More informationChapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering
Chapter 11, Testing Using UML, Patterns, and Java Object-Oriented Software Engineering Outline Terminology Types of errors Dealing with errors Quality assurance vs Testing Component Testing! Unit testing!
More informationSimplification of Boolean Functions
COM111 Introduction to Computer Engineering (Fall 2006-2007) NOTES 5 -- page 1 of 5 Introduction Simplification of Boolean Functions You already know one method for simplifying Boolean expressions: Boolean
More informationMonitoring Interfaces for Faults
Monitoring Interfaces for Faults Aleksandr Zaks RV 05 - Fifth Workshop on Runtime Verification Joint work with: Amir Pnueli, Lenore Zuck Motivation Motivation Consider two components interacting with each
More information9/21/17. Outline. Expression Evaluation and Control Flow. Arithmetic Expressions. Operators. Operators. Notation & Placement
Outline Expression Evaluation and Control Flow In Text: Chapter 6 Notation Operator evaluation order Operand evaluation order Overloaded operators Type conversions Short-circuit evaluation of conditions
More informationDistributed Systems Programming (F21DS1) Formal Verification
Distributed Systems Programming (F21DS1) Formal Verification Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Focus on
More informationIndex. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107
A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105
More informationCA314 Object Oriented Analysis & Design - 7. File name: CA314_Section_07_Ver01 Author: L Tuohey No. of pages: 16
CA314 Object Oriented Analysis & Design - 7 File name: CA314_Section_07_Ver01 Author: L Tuohey No. of pages: 16 Table of Contents 7. UML State & Activity Diagrams (see ref 1, Chap. 11, 12)...3 7.1 Introduction...3
More informationChapter 7 Control Statements Continued
Chapter 7 Control Statements Continued Logical Operators used in Boolean expressions to control behavior of if, while or for statements. && - and, - or,! - not if (the sun shines && you have the time)
More informationCITS5501 Software Testing and Quality Assurance Formal methods
CITS5501 Software Testing and Quality Assurance Formal methods Unit coordinator: Arran Stewart May 1, 2018 1 / 49 Sources Pressman, R., Software Engineering: A Practitioner s Approach, McGraw-Hill, 2005
More informationIan Sommerville 2006 Software Engineering, 8th edition. Chapter 22 Slide 1
Verification and Validation Slide 1 Objectives To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V
More informationReview sheet for Final Exam (List of objectives for this course)
Review sheet for Final Exam (List of objectives for this course) Please be sure to see other review sheets for this semester Please be sure to review tests from this semester Week 1 Introduction Chapter
More informationDecision Management Community
Decision Management Community Challenge Jan-2016 INTRO I was happy to see a large number of submissions to the challenge. Just to make things clear, I did not start the challenge and I did not pick the
More informationCombinatorial Clause Coverage CoC
Introduction to Software Testing Chapter 3.2 Logic Coverage Paul Ammann & Jeff Offutt Covering Logic Expressions Logic expressions show up in many situations Covering logic expressions is required by the
More informationSoftware testing. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1
Software testing Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles
More informationInstantiation of Template class
Class Templates Templates are like advanced macros. They are useful for building new classes that depend on already existing user defined classes or built-in types. Example: stack of int or stack of double
More informationCS 451 Software Engineering
CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 Elaboration 2 Elaboration: Building the Analysis Model An analysis model provides a description
More informationTesting3. State-based Testing
Testing3 State-based testing Inheritance Testing interacting classes Communication diagrams Object relation graph (ORD) Regression testing GUI Testing 1 State-based Testing Natural representation with
More informationSoftware Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification Techniques
Software Testing in the textbook Software Testing Chapter 8 Introduction (Verification and Validation) 8.1 Development testing 8.2 Test-driven development 8.3 Release testing 8.4 User testing 1 2 Verification
More informationSUMMARY: MODEL DRIVEN SECURITY
SUMMARY: MODEL DRIVEN SECURITY JAN-FILIP ZAGALAK, JZAGALAK@STUDENT.ETHZ.CH Model Driven Security: From UML Models to Access Control Infrastructres David Basin, Juergen Doser, ETH Zuerich Torsten lodderstedt,
More informationProgram Correctness and Efficiency. Chapter 2
Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you
More informationAbsolute C++ Walter Savitch
Absolute C++ sixth edition Walter Savitch Global edition This page intentionally left blank Absolute C++, Global Edition Cover Title Page Copyright Page Preface Acknowledgments Brief Contents Contents
More informationPart X. Advanced C ++
Part X Advanced C ++ topics Philip Blakely (LSC) Advanced C++ 158 / 217 References The following are highly regarded books. They are fairly in-depth, and I haven t read them in their entirity. However,
More informationFormally-Proven Kosaraju s algorithm
Formally-Proven Kosaraju s algorithm Laurent Théry Laurent.Thery@sophia.inria.fr Abstract This notes explains how the Kosaraju s algorithm that computes the strong-connected components of a directed graph
More informationExamples of Code Roaches. First Draft List Cem Kaner September 11, 2005
Examples of Code Roaches First Draft List Cem Kaner September 11, 2005 Why a Potential-Bug List? Given a potential error, you can develop a method to test for it Foundation for Code inspections Glass box
More informationText Input and Conditionals
Text Input and Conditionals Text Input Many programs allow the user to enter information, like a username and password. Python makes taking input from the user seamless with a single line of code: input()
More informationSoftware Quality. Chapter What is Quality?
Chapter 1 Software Quality 1.1 What is Quality? The purpose of software quality analysis, or software quality engineering, is to produce acceptable products at acceptable cost, where cost includes calendar
More informationExercise Unit 2: Modeling Paradigms - RT-UML. UML: The Unified Modeling Language. Statecharts. RT-UML in AnyLogic
Exercise Unit 2: Modeling Paradigms - RT-UML UML: The Unified Modeling Language Statecharts RT-UML in AnyLogic Simulation and Modeling I Modeling with RT-UML 1 RT-UML: UML Unified Modeling Language a mix
More information