Automatic Testing Based on Design by Contract
|
|
- Rolf Singleton
- 5 years ago
- Views:
Transcription
1 Automatic Testing Based on Design by Contract Ilinca Ciupa Andreas Leitner, ETH Zürich (Swiss Federal Institute of Technology Zurich) SOQUA Developer Track 2005 September 22, 2005
2 The important things in life... taking a lunch break
3 Outline 1. Problems addressed and our solution: contractbased testing 2. AutoTest framework! Test process configuration! Input value generation! Test execution! Test results 3. Results 4. Conclusions
4 Problems with existing testing strategies! They require too much work from the user! Those that are automatic, work only in the most basic cases! They are targeted at only one particular language! Some of them require some kind of modification / addition to the tested software! They are often tested by their authors only on small, artificial examples
5 Our goal We want to develop a testing strategy that:! Finds the real bugs in real systems! Is fully automatic! Is applicable to several programming languages! Tests software as it is! Can be tested on full-fledged, industrial-scale applications
6 The idea As long as we know what the software is supposed to do, we do not need any human intervention to test it. Contracts contain the specification of the software! Contract-based testing: using contracts as defined in Design by Contract as an automatic, freelyavailable testing oracle (and for input value generation)
7 Contract-based testing When testing a certain method:! We try to satisfy its precondition (so that we can execute it)! We hope it will not fulfill its postcondition => BUG class ARRAYED_LIST [G]... put (v: like item) is -- Replace current item by `v'. -- (Synonym for `replace') require extendible: extendible do... ensure item_inserted: is_inserted (v) same_count: count = old count end precondition body postcondition
8 So practically...! Our testing strategy: fully automatic, random! Tool: AutoTest! Programming language: Eiffel! Found bugs:! Yes many!! In production-quality libraries
9 Outline 1. Problems addressed and our solution: contractbased testing 2. AutoTest framework! Test process configuration! Input value generation! Test execution! Test results 3. Results 4. Conclusions
10 Issues! Generation of input data! Tailorability of the testing process! Interpretation and representation of results! Fault isolation! Failure-reproducing examples! Estimation of the quality of the test suites
11 AutoTest AutoTest
12 Test scope! Methods! For convenience, user can also specify scope at:! Class level all its methods included! Package level all its classes included! Suppose user wants to test method m of class A. Issues:! Should we also test m in descendants of A?! If A is generic, which instantiations of the generic parameter/s do we use?
13 Configuration parameters! Stress level:! Number of calls to tested methods! Testing in descendants! Testing order! Level of support for genericity! Values used for primitive types! Instances for non-primitive types
14 Input value generation! Currently random strategy! Random object creation! Random object modification! We keep a pool of objects that we enhance and diversify as testing proceeds! Algorithm For each call to each method under test (MUT): 1. Create objects needed for the next call 2. Store these objects in the pool 3. Modify an arbitrary object from the pool 4. Call MUT with objects randomly selected from the pool
15 Preconditions! Generated test cases (TCs) that don t satisfy the tested method s precondition are useless.! The stronger the preconditions, the harder it is for the random strategy to satisfy them. (Plus, random strategy has no notion of coverage.)! So how do we automatically generate valid TCs?! Our solution: planning augmented with learning
16 Execution of test code
17 Test results! Evaluation straightforward due to the presence of contracts! Classification:! Pass all OK /! Invalid MUT was not executed! Fail contract violation => bug! Bad response interpreter returned unexpected response
18 Outline 1. Problems addressed and our solution: contractbased testing 2. AutoTest framework! Test process configuration! Input value generation! Test execution! Test results 3. Results 4. Conclusions
19 Results! Main advantage of our approach: we can test it on existing large-scale applications and libraries! Some figures from testing EiffelBase (the most widely used Eiffel library, that has been in use for more than 10 years):! Class ARRAYED_LIST [G]: tests failed for 13 out of 98 public methods! Class STRING: test failed for 25 out of 157 public methods
20 Example of found bug class ARRAYED_LIST [G]... put (v: like item) is -- Replace current item by `v'. -- (Synonym for `replace') require extendible: extendible do replace (v) ensure item_inserted: is_inserted (v) same_count: count = old count end replace (v: like first) is -- Replace current item by `v'. require writable: writable do put_i_th (v, index) ensure item_replaced: item = v end extendible: BOOLEAN is True 1 <= index <= count (there exists a current element) NOT ALWAYS TRUE!
21 Conclusions! We focus on functional unit testing! Main contribution: practical! Tool: AutoTest ( Strengths:! Fully automatic! Approach tested on full-fledged, industrial-scale applications! Approach can be extended to any programming language with support for assertions! No need to modify the software in order to test it! Found (an impressive number of) real bugs in real libraries
22 Future work! Perform a thorough evaluation of the random strategy! Generation of input values! Improve planning strategy! Try alternatives! Minimization of failure-reproducing examples! Incorporating the knowledge of the human tester in the process: integration with manual unit tests! Does the use of contracts for automatic testing! decrease novice developers reluctance towards them?! improve the quality of the contracts written by developers?
23 Final point Over-lunch testing concept already in operation Future work: over-coffee-break testing TO DO
Assertions. 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 informationAutomatic Verification of Computer Programs
Chair of Software Engineering Automatic Verification of Computer Programs these slides contain advanced material and are optional What is verification Check correctness of the implementation given the
More informationTrusted Components. Bertrand Meyer, Manuel Oriol. Lecture 7: Testing Object-Oriented Software. Ilinca Ciupa, Andreas Leitner, Bertrand Meyer
Trusted Components Bertrand Meyer, Manuel Oriol Lecture 7: Testing Object-Oriented Software Ilinca Ciupa, Andreas Leitner, Bertrand Meyer A (rather unorthodox) introduction (1) (Geoffrey James The Zen
More informationFaults Found by Random Testing. WanChi Chio Justin Molinyawe
Faults Found by Random Testing WanChi Chio Justin Molinyawe Introduction Why apply random testing to object oriented software? Cost-efficient in terms of implementation effort and execution time. Introduction
More informationOn the number and nature of faults found by random testing
SOFTWARE TESTING, VERIFICATION AND RELIABILITY Softw. Test. Verif. Reliab. 2011; 21:3 28 Published online 6 July 2009 in Wiley Online Library (wileyonlinelibrary.com)..415 On the number and nature of faults
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 informationGuided Random-Based Testing Strategies Diploma Thesis
Guided Random-Based Testing Strategies Diploma Thesis Cosmin Mitran Faculty of Automation and Computer Science Technical University of Cluj-Napoca Supervisors: Ilinca Ciupa Prof. Dr. Bertrand Meyer Chair
More informationReproducing Crashes. Shifting Role of Testing. Shifting Role of Testing. Waterfall Model, V-Model
Reproducing Crashes Andreas Leitner Universität des Saarlandes 11.12.2008 1 Shifting Role of ing ing often ne towards release-time Modern development processes move testing to the center of development
More informationA Practical Approach to Programming With Assertions
A Practical Approach to Programming With Assertions Ken Bell Christian-Albrechts Universität Kiel Department of Computer Science and Applied Mathematics Real-Time Systems and Embedded Systems Group July
More informationSoftware Engineering Testing and Debugging Testing
Software Engineering Testing and Debugging Testing Prof. Dr. Peter Thiemann Universitt Freiburg 08.06.2011 Recap Testing detect the presence of bugs by observing failures Debugging find the bug causing
More informationObject-Oriented Design
Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Open Closed Principle (OCP) Classes should be open for extension but closed
More informationEiffel: Analysis, Design and Programming. ETH Zurich, September-December Exception handling
Eiffel: Analysis, Design and Programming ETH Zurich, September-December 2008-6- Exception handling What is an exception? An abnormal event Not a very precise definition Informally: something that you don
More informationEIFFEL TEST STUDIO Locating faults in external code Master Thesis Project Plan
EIFFEL TEST STUDIO Locating faults in external code Master Thesis Project Plan Reto Ghioldi Department of Computer Science ETH Zürich September 6, 2005 Project period 8.September 2005-9.March 2006 Student
More informationA comparative study of programmer-written and automatically inferred contracts
A comparative study of programmer-written and automatically inferred contracts Nadia Polikarpova, Ilinca Ciupa, Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland {firstname.lastname}@inf.ethz.ch
More informationFinding Faults: Manual Testing vs. Random Testing+ vs. User Reports
Finding Faults: Manual Testing vs. Random Testing+ vs. User Reports Ilinca Ciupa, Bertrand Meyer, Manuel Oriol, Alexander Pretschner Department of Computer Science, ETH Zurich, Switzerland {ilinca.ciupa,
More informationImproving Test Suites via Operational Abstraction
Improving Test Suites via Operational Abstraction Michael Ernst MIT Lab for Computer Science http://pag.lcs.mit.edu/~mernst/ Joint work with Michael Harder, Jeff Mellen, and Benjamin Morse Michael Ernst,
More informationAutomatic testing of object-oriented software
Automatic testing of object-oriented software Bertrand Meyer, Ilinca Ciupa, Andreas Leitner, Lisa (Ling) Liu Chair of Software Engineering, ETH Zurich, Switzerland http://se.ethz.ch {Firstname.Lastname}@inf.ethz.ch
More informationEvolutionary Object-Oriented Testing
Evolutionary Object-Oriented Testing Lucas Serpa Silva Artificial Intelligence University of Amsterdam A thesis submitted for the degree of Msc Artificial Intelligence Supervised by Dr. Maarten van Someren
More informationSoftware Architecture 4. July 2005
Chair of Software Engineering Bertrand Meyer Software Architecture 4. July 2005 Name, First name:... I confirm with my signature, that I was able to take this exam under regular conditions and that I have
More informationUC Santa Barbara. CS189A - Capstone. Christopher Kruegel Department of Computer Science UC Santa Barbara
CS189A - Capstone Christopher Kruegel Department of Computer Science http://www.cs.ucsb.edu/~chris/ Design by Contract Design by Contract and the language that implements the Design by Contract principles
More informationSoftware Engineering
Software Engineering Lecture 13: Testing and Debugging Testing Peter Thiemann University of Freiburg, Germany SS 2014 Recap Recap Testing detect the presence of bugs by observing failures Recap Testing
More informationObject-Oriented Design
Object-Oriented Design Lecturer: Raman Ramsin Lecture 15: Object-Oriented Principles 1 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should
More informationAutomated Fixing of Programs with Contracts
Automated Fixing of Programs with Contracts Yi Wei, Yu Pei, Carlo A. Furia, Lucas S. Silva, Stefan Buchholz, Bertrand Meyer and Andreas Zeller Chair of Software Engineering, ETH Zürich Software Engineering
More informationSoftware Architecture Bertrand Meyer. Lecture 3: Language constructs for modularity and information hiding
Software Architecture Bertrand Meyer Last update: 3 April 2007 ETH Zurich, March-July 2007 Lecture 3: Language constructs for modularity and information hiding Ilinca Ciupa Overview Review of modularity
More informationTest-Driven Development (TDD)
Test-Driven Development (TDD) EECS3311 A: Software Design Fall 2018 CHEN-WEI WANG DbC: Supplier DbC is supported natively in Eiffel for supplier: class ACCOUNT create make feature -- Attributes owner :
More informationAutomated Object-Oriented Software Testing using Genetic Algorithms and Static-Analysis
Automated Object-Oriented Software Testing using Genetic Algorithms and Static-Analysis Lucas Serpa Silva Software Engineering Swiss Federal Institute of Technology A thesis submitted for the degree of
More informationArray Based Lists. Collections
Array Based Lists Reading: RS Chapter 15 1 Collections Data structures stores elements in a manner that makes it easy for a client to work with the elements Specific collections are specialized for particular
More informationComparing procedure specifications
Comparing procedure specifications CSE 331 University of Washington Michael Ernst Outline Satisfying a specification; substitutability Stronger and weaker specifications Comparing by hand Comparing via
More informationJava: advanced object-oriented features
Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Java: advanced object-oriented features Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Packages
More information6.170 Lecture 6 Procedure specifications MIT EECS
6.170 Lecture 6 Procedure specifications MIT EECS Outline Satisfying a specification; substitutability Stronger and weaker specifications Comparing by hand Comparing via logical formulas Comparing via
More informationCoding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends!
Requirements Spec. Design Coding and Unit Testing Characteristics of System to be built must match required characteristics (high level) Architecture consistent views Software Engineering Computer Science
More informationCSI33 Data Structures
Outline Department of Mathematics and Computer Science Bronx Community College August 31, 2015 Outline Outline 1 Chapter 1 Outline Textbook Data Structures and Algorithms Using Python and C++ David M.
More informationIntroduction to Software Testing Chapter 4 Input Space Partition Testing
Introduction to Software Testing Chapter 4 Input Space Partition Testing Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/ softwaretest/ Ch. 4 : Input Space Coverage Four Structures for Modeling
More informationDesign by Contract in Eiffel
Design by Contract in Eiffel 2002/04/15 ctchen@canthink.com.com.tw.tw Reference & Resource Bertrand Meyer, Object-Oriented Oriented Software Construction 2nd,, 1997, PH. Bertrand Meyer, Eiffel: The Language,,
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 informationARTOO: Adaptive Random Testing for Object-Oriented Software
ARTOO: Adaptive Random Testing for Object-Oriented Software Ilinca Ciupa, Andreas Leitner, Manuel Oriol, Bertrand Meyer Chair of Software Engineering ETH Zurich, Switzerland {firstname.lastname}@inf.ethz.ch
More informationa correct statement? You need to know what the statement is supposed to do.
Using assertions for correctness How can we know that software is correct? It is only correct if it does what it is supposed to do. But how do we know what it is supposed to do? We need a specification.
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 informationOutline. Data Definitions and Templates Syntax and Semantics Defensive Programming
Outline Data Definitions and Templates Syntax and Semantics Defensive Programming 1 Data Definitions Question 1: Are both of the following data definitions ok? ; A w-grade is either ; - num ; - posn ;
More informationEiffel as a Framework for Verification
Eiffel as a Framework for Verification Bertrand Meyer ETH Zurich http://se.inf.ethz.ch Eiffel Software www.eiffel.com Abstract. The Eiffel method and language integrate a number of ideas originating from
More informationUsing contracts and boolean queries to improve the quality of automatic test generation
Using contracts and boolean queries to improve the quality of automatic test generation Lisa (Ling) Liu Bertrand Meyer Bernd Schoeller Chair of Software Engineering, ETH Zurich, Switzerland {ling.liu,
More informationReadability [Skrien 4.0] Programs must be written for people to read, and only incidentally for machines to execute.
Readability [Skrien 4.0] Programs must be written for people to read, and only incidentally for machines to execute. Abelson & Sussman Use a good set of coding conventions, such as the ones given in the
More informationDefault arguments, documentation
, documentation Comp Sci 1570 Introduction to C++ Outline 1 2 to functions A default parameter (also called an optional parameter or a default argument) is a function parameter that has a default value
More informationSoftwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany
Softwaretechnik Lecture 08: Testing and Debugging Overview Peter Thiemann University of Freiburg, Germany SS 2012 Literature Essential Reading Why Programs Fail: A Guide to Systematic Debugging, A Zeller
More informationSoftwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany
Softwaretechnik Lecture 08: Testing and Debugging Overview Peter Thiemann University of Freiburg, Germany SS 2012 Literature Essential Reading Why Programs Fail: A Guide to Systematic Debugging, A Zeller
More informationTestBase's Patented Slice Feature is an Answer to Db2 Testing Challenges
Db2 for z/os Test Data Management Revolutionized TestBase's Patented Slice Feature is an Answer to Db2 Testing Challenges The challenge in creating realistic representative test data lies in extracting
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 informationAssignment 4: Object creation
Assignment 4: Object creation ETH Zurich Hand-out: 15 November 2005 Due: 22 November 2005 Copyright FarWorks, Inc. Gary Larson 1 Summary Today you are going to write your rst stand-alone program. Please
More informationDesign by Contract: An Overview
: An Overview CSCI 5828 Michael M. Vitousek University of Colorado at Boulder michael.vitousek@colorado.edu March 21, 2012 1 / 35 Outline 1 Introduction Motivation and Introduction Simple Example Contract
More informationMethod Description for Semla A Software Design Method with a Focus on Semantics
Computer Science Method Description for Semla A Software Design Method with a Focus on Semantics Semla for Java, English version May 2000 Method Description for Semla A Software Design Method with a Focus
More informationLow Level Design Activities. Implementation (Low Level Design) What is a Good Low Level Module? Black Box Aspects. Black box aspects White box aspects
Low Level Design Activities Implementation (Low Level Design) Implement Document Deskcheck Basic Test PVK--HT00 Copyright 1997-1999, jubo@cs.umu.se/epltos@epl.ericsson.se 2 What is a Good Low Level Module?
More informationSoftware Development. Modular Design and Algorithm Analysis
Software Development Modular Design and Algorithm Analysis Precondition and Postcondition To create a good algorithm, a programmer must be able to analyse a precondition (starting state) and a postcondition
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 informationSelf-checking software insert specifications about the intent of a system
Assertions Reading assignment A. J. Offutt, A Practical System for Mutation Testing: Help for the Common Programmer, Proceedings of the 12th International Conference on Testing Computer Software, Washington,
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 informationIn-Class Exercises. ETH Zurich. ETH students recently designed a special kind of oven for cooking potatoes. Here are some facts about such an oven:
In-Class Exercises ETH Zurich 1 Contracts ETH students recently designed a special kind of oven for cooking potatoes. Here are some facts about such an oven: each oven is equipped with a door which is
More informationSpecifying Reusable Components
Specifying Reusable Components Nadia Polikarpova, Carlo A. Furia, and Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland {nadia.polikarpova,carlo.furia,bertrand.meyer}@inf.ethz.ch Abstract.
More informationWhat Good Are Strong Specifications?
What Good Are Strong Specifications? Nadia Polikarpova Carlo A. Furia Yu Pei Yi Wei Bertrand Meyer, Chair of Software Engineering, ETH Zurich, Switzerland ITMO National Research University, St. Petersburg,
More informationFormal Technology in the Post Silicon lab
Formal Technology in the Post Silicon lab Real-Life Application Examples Haifa Verification Conference Jamil R. Mazzawi Lawrence Loh Jasper Design Automation Focus of This Presentation Finding bugs in
More informationUnit Testing as Hypothesis Testing
Unit Testing as Hypothesis Testing Jonathan Clark September 19, 2012 You should test your code. Why? To find bugs. Even for seasoned programmers, bugs are an inevitable reality. Today, we ll take an unconventional
More informationNo Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages
No Source Code : Software Testing Black-Box Testing Test-Driven Development No access to source code So test cases don t worry about structure Emphasis is only on ensuring that the contract is met Specification-Based
More informationAgenda. More on the Unified Modeling Language. UML diagram types. Packages
Agenda More on the Unified Modeling Language Perdita Stevens, University of Edinburgh July 2010 And the rest... deployment diagrams, component diagrams, object diagrams, timing diagrams, etc. OCL and alternatives
More informationIntroduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS
Introduction To Software Testing Brian Nielsen bnielsen@cs.aau.dk Center of Embedded Software Systems Aalborg University, Denmark CSS 1010111011010101 1011010101110111 What is testing? Testing Testing:
More informationBlack Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing
Black Box Testing EEC 521: Software Engineering Software Testing Black-Box Testing Test-Driven Development Also known as specification-based testing Tester has access only to running code and the specification
More informationJtest Tutorial. Tutorial
Jtest Jtest Welcome to the Jtest. This tutorial walks you through how to perform common Jtest tasks using example files. Please note that although the four types of tests (static analysis, white-box testing,
More informationChapter 11, Testing, Part 2: Integration and System Testing
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing
More informationThe Eiffel language. Slides partly based on :
The Eiffel language Slides partly based on : http://se.inf.ethz.ch/courses/2015b_fall/eprog/english_index.html Eiffel, in brief Procedural, object-oriented programming language created by Bertrand Meyer
More informationRegression testing. Whenever you find a bug. Why is this a good idea?
Regression testing Whenever you find a bug Reproduce it (before you fix it!) Store input that elicited that bug Store correct output Put into test suite Then, fix it and verify the fix Why is this a good
More informationAn Annotated Language
Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of
More informationTesting Objectives. Successful testing: discovers previously unknown errors
Testing Objectives Informal view: Testing: a process of executing software with the intent of finding errors Good testing: a high probability of finding as-yetundiscovered errors Successful testing: discovers
More informationIn-Class Exercises. ETH Zurich. November
In-Class Exercises ETH Zurich November 28 2012 1 Contracts ETH students recently designed a special kind of oven for cooking potatoes. Here are some facts about such an oven: each oven is equipped with
More informationLECTURE 9 TEST DESIGN TECHNIQUES - II
LECTURE 9 TEST DESIGN TECHNIQUES - II DECISION TABLE A decision table is a good way to deal with different combination inputs with their associated outputs and also called cause-effect table. Decision
More informationUnit Testing as Hypothesis Testing
Unit Testing as Hypothesis Testing Jonathan Clark September 19, 2012 5 minutes You should test your code. Why? To find bugs. Even for seasoned programmers, bugs are an inevitable reality. Today, we ll
More informationChapter 11, Testing, Part 2: Integration and System Testing
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing
More information10. Software Testing Fundamental Concepts
10. Software Testing Fundamental Concepts Department of Computer Science and Engineering Hanyang University ERICA Campus 1 st Semester 2016 Testing in Object-Oriented Point of View Error Correction Cost
More informationIn this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs.
In this Lecture you will Learn: Testing in Software Development Process Examine the verification and validation activities in software development process stage by stage Introduce some basic concepts of
More informationCSC Advanced Object Oriented Programming, Spring Specification
CSC 520 - Advanced Object Oriented Programming, Spring 2018 Specification Specification A specification is an unambiguous description of the way the components of the software system should be used and
More informationLecture Notes on Contracts
Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,
More informationAutomatic Testing of Sequential and Concurrent Substitutability
Automatic Testing of Sequential and Concurrent Substitutability Michael Pradel and Thomas R. Gross Department of Computer Science ETH Zurich 1 Motivation void bar(foo f) { f.m();... } bar() expects functionality
More informationA Tutorial for ECE 175
Debugging in Microsoft Visual Studio 2010 A Tutorial for ECE 175 1. Introduction Debugging refers to the process of discovering defects (bugs) in software and correcting them. This process is invoked when
More information5. Defining Classes and Methods
5. Defining Classes and Methods Harald Gall, Prof. Dr. Institut für Informatik Universität Zürich http://seal.ifi.uzh.ch/info1 Objectives Describe and define concepts of class, class object Describe use
More informationContract-based Programming: a Route to Finding Bugs Earlier
Contract-based Programming: a Route to Finding Bugs Earlier JSA Research & Innovation February 2018 Subprogram Contracts Type Contracts Contract-based Programming A software development technique, used
More informationVerification Condition Generation
Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture
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 informationAutomatic Program Repair by Fixing Contracts
Automatic Program Repair by Fixing Contracts Yu Pei, Carlo A. Furia, Martin Nordio, and Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland firstname.lastname@inf.ethz.ch Abstract. While
More informationAutomatic Black-Box Method-Level Test Case Generation Based on Constraint Logic Programming
Automatic Black-Box Method-Level Test Case Generation Based on Constraint Logic Programming i-tin Hu and ai-wei Lin Department of Computer Science and Information Engineering ational Chung Cheng University
More informationA Class-Level Unit Testing Tool for Java
A Class-Level Unit Testing Tool for Java Tz-Fan Hu and Nai-Wei Lin Department of Computer Science and Information Engineering National Chung Cheng University Chiayi 621, Taiwan, R.O.C. Email: {htf97m,naiwei}@cs.ccu.edu.tw
More informationUNIT-4 Black Box & White Box Testing
Black Box & White Box Testing Black Box Testing (Functional testing) o Equivalence Partitioning o Boundary Value Analysis o Cause Effect Graphing White Box Testing (Structural testing) o Coverage Testing
More information3. Design by Contract
3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Roadmap > Contracts > Stacks > Design by
More informationLecture Notes: Hoare Logic
Lecture Notes: Hoare Logic 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich (jonathan.aldrich@cs.cmu.edu) Lecture 3 1 Hoare Logic The goal of Hoare logic is to provide a formal system for
More informationCSI33 Data Structures
Outline Department of Mathematics and Computer Science Bronx Community College August 29, 2018 Outline Outline 1 Chapter 2: Data Abstraction Outline Chapter 2: Data Abstraction 1 Chapter 2: Data Abstraction
More informationProgramming with assertions Oracle guidelines
Programming with assertions Oracle guidelines J.Serrat 102759 Software Design October 27, 2015 Index 1 Preliminaries 2 When not to use assertions 3 When to use assertions 4 Post-conditions 5 Requiring
More informationCSE 331 Midterm Exam Sample Solution 2/18/15
Question 1. (10 points) (Forward reasoning) Using forward reasoning, write an assertion in each blank space indicating what is known about the program state at that point, given the precondition and the
More informationAssertions, pre/postconditions
Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What
More informationTesting for the Unexpected
Erlang Solutions Ltd. Testing for the Unexpected Ulf Wiger, CTO Erlang Solutions Ltd QCon, London 2011 1999-2011 Erlang Solutions Ltd. About me Spent 4 years in Alaska working on Military Command & Control
More informationMASSACHUSETTS INSTITUTE OF TECHNOLOGY Computer Systems Engineering: Spring Quiz I Solutions
Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY 6.033 Computer Systems Engineering: Spring 2011 Quiz I Solutions There are 10 questions and 12 pages in this
More informationMSO Lecture Design by Contract"
1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018 2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade,
More informationSoftware Testing Interview Question and Answer
Software Testing Interview Question and Answer What is Software Testing? A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to
More informationUNIT-4 Black Box & White Box Testing
Black Box & White Box Testing Black Box Testing (Functional testing) o Equivalence Partitioning o Boundary Value Analysis o Cause Effect Graphing White Box Testing (Structural testing) o Coverage Testing
More information