Feedback-Based Specification, Coding and Testing… …with JWalk Anthony J H Simons, Neil Griffiths and Christopher D Thomson.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Advertisements

ISBN Chapter 3 Describing Syntax and Semantics.
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Software testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Well-behaved objects 4.0 Testing. 2 Objects First with Java - A Practical Introduction using BlueJ, © David J. Barnes, Michael Kölling Main concepts to.
Describing Syntax and Semantics
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
Outline Types of errors Component Testing Testing Strategy
Impact Analysis of Database Schema Changes Andy Maule, Wolfgang Emmerich and David S. Rosenblum London Software Systems Dept. of Computer Science, University.
CS527: (Advanced) Topics in Software Engineering Overview of Software Quality Assurance Tao Xie ©D. Marinov, T. Xie.
System/Software Testing
Reverse Engineering State Machines by Interactive Grammar Inference Neil Walkinshaw, Kirill Bogdanov, Mike Holcombe, Sarah Salahuddin.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 23 Slide 1 Software testing Slightly adapted by Anders Børjesson.
Software Testing. Definition To test a program is to try to make it fail.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
1. Topics to be discussed Introduction Objectives Testing Life Cycle Verification Vs Validation Testing Methodology Testing Levels 2.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Chapter 8 – Software Testing Lecture 1 1Chapter 8 Software testing The bearing of a child takes nine months, no matter how many women are assigned. Many.
Overview of Software Testing 07/12/2013 WISTPC 2013 Peter Clarke.
Dynamic Analysis of Algebraic Structure to Optimize Test Generation and Test Case Selection Anthony J H Simons and Wenwen Zhao.
Lecture 3 Software Engineering Models (Cont.)
Software testing Main issues: There are a great many testing techniques Often, only the final code is tested.
COMP 121 Week 1: Testing and Debugging. Testing Program testing can be used to show the presence of bugs, but never to show their absence! ~ Edsger Dijkstra.
CSE403 Software Engineering Autumn 2001 More Testing Gary Kimura Lecture #10 October 22, 2001.
Testing Testing Techniques to Design Tests. Testing:Example Problem: Find a mode and its frequency given an ordered list (array) of with one or more integer.
Automatically Repairing Broken Workflows for Evolving GUI Applications Sai Zhang University of Washington Joint work with: Hao Lü, Michael D. Ernst.
Well-behaved objects Main concepts to be covered Testing Debugging Test automation Writing for maintainability Objects First with Java - A Practical.
Xusheng Xiao North Carolina State University CSC 720 Project Presentation 1.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
Week 14 Introduction to Computer Science and Object-Oriented Programming COMP 111 George Basham.
COP INTERMEDIATE JAVA Designing Classes. Class Template or blueprint for creating objects. Their definition includes the list of properties (fields)
Testing, Testing & Testing - By M.D.ACHARYA QA doesn't make software but makes it better.
Com1040 Systems Design and Testing Part II – Testing (Based on A.J. Cowling’s lecture notes) LN-Test1+2: Introduction to Testing Marian Gheorghe ©University.
Toulouse, September 2003 Page 1 JOURNEE ALTARICA Airbus ESACS  ISAAC.
LECTURE 20 26/11/15. Summary - Testing ◦ Testing affects all stages of software engineering cycle ◦ One strategy is a bottom-up approach – class, integration,
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 11, Testing.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
OOPDA Intro 5.0. Topics Website and Syllabus Rowan VPN and H:drive BlueJ application and projects Programming Style (Appendix J) Javadoc (Appendix I)
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Lazy Systematic Unit Testing for Java Anthony J H Simons Christopher D Thomson.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
Benchmarking Effectiveness for Object-Oriented Unit Testing Anthony J H Simons and Christopher D Thomson.
S Ramakrishnan1 Systems V & V, Quality and Standards Dr Sita Ramakrishnan School CSSE Monash University.
CSI 1340 Introduction to Computer Science II Chapter 1 Software Engineering Principles.
Objects First With Java A Practical Introduction Using BlueJ Well-behaved objects 2.1.
Chapter 5 – Software Testing & Maintenance (Evolution) 1.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
T EST T OOLS U NIT VI This unit contains the overview of the test tools. Also prerequisites for applying these tools, tools selection and implementation.
Random Test Generation of Unit Tests: Randoop Experience
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
CS223: Software Engineering Lecture 25: Software Testing.
Software Engineering Algorithms, Compilers, & Lifecycle.
Cs498dm Software Testing Darko Marinov January 24, 2012.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVIII. Software Testing.
A Review of Software Testing - P. David Coward
TQS - Teste e Qualidade de Software (Software Testing and Quality) Software Testing Concepts João Pascoal Faria
Testing Tutorial 7.
Generating Automated Tests from Behavior Models
Testing and Debugging PPT By :Dr. R. Mall.
Chapter 8 – Software Testing
CS5123 Software Validation and Quality Assurance
Fabiano Ferrari Software Engineering Federal University of São Carlos
Software Verification and Validation
Software Verification and Validation
CSE403 Software Engineering Autumn 2000 More Testing
Scriptless Test Automation through Graphical User Interface
Software Verification and Validation
Chapter 7 Software Testing.
Presentation transcript:

Feedback-Based Specification, Coding and Testing… …with JWalk Anthony J H Simons, Neil Griffiths and Christopher D Thomson

Overview Lazy Systematic Unit Testing  JWalk testing tool (Simons) The JWalkEditor tool  Integrated Java editor and JWalk (Griffiths) Feedback-based methodology  Prototype, validate, specify, test Evaluation of cost-effectivness  Testing effort, time, coverage (Thomson)

Motivation State of the art in agile testing  Test-driven development is good, but…  …no specification to inform the selection of tests  …manual test-sets are fallible (missing, redundant cases)  …reusing saved tests for conformance testing is fallible – state partitions hide paths, faults (Simons, 2005) Lazy systematic testing method: the insight  Complete testing requires a specification (even in XP!)  Infer an up-to-date specification from a code prototype  Let tools handle systematic test generation and coverage  Let the programmer focus on novel/unpredicted results

Lazy Systematic Unit Testing Lazy Specification  late inference of a specification from evolving code  semi-automatic, by static and dynamic analysis of code with limited user interaction  specification evolves in step with modified code Systematic Testing  bounded exhaustive testing, up to the specification  emphasis on completeness, conformance, correctness properties after testing, repeatable test quality

JWalk Testing Tool Lazy systematic unit testing for Java  static analysis - extracts the public API of a compiled Java class  protocol walking (code exploration) - executes all interleaved methods to a given path depth  algebraic testing (memory states) - validates all observations on all mutator-method sequences  state-based testing (high-level states) - validates all state- transitions (n-switch coverage) for inferred high-level states

JWalkEditor Integration of JWalk with a Java-editor Editing features  Java-sensitive  Integrated with JDK compiler tools – track exceptions to source Testing features  Invokes JWalk (6 validation/testing modes)  Confirm/reject key results via dialogs  Browse test result-sets via tabbed panes

Snapshot – Editing a Stack Syntax sensitive text highlights Full build cycle, multiple sources Set JWalk test parameters

Snapshot –Testing a Stack Tabbed pane with test results for the Empty state, for all paths of depth 2 Colour-coded test outcomes Colour-coded test sequences

Dynamic Analysis of States Memory states  generate all interleaved method paths to depth 1..n  prune sequences ending in observers from the active edges, preserving mutator sequences  distinguish observer/mutator methods by empirical low-level state comparison (extracted by reflection) High-level states  generate all mutator-method paths (as above)  evaluate all state predicates, eg: isEmpty(), isFull()  seek states corresponding to the product of boolean outcomes: viz: {Default, Empty, Full, Full&Empty}

Test Result Prediction Strong prediction  From known results, guarantee further outcomes in the same equivalence class  eg: test sequences containing observers in the prefix map onto a shorter sequence  target.push(e).size().top() == target.push(e).top() Weak prediction  From known facts, guess further outcomes; an incorrect guess will be revealed in the next cycle  eg: methods with void type usually return no result, but may raise an exception  target.pop() predicted to have no result  target.pop().size() == -1 reveals an error

Feedback-based Methodology Coding  The programmer prototypes a Java class in the editor Validation  JWalk systematically explores method paths, providing useful instant feedback to the programmer Specification  JWalk infers a specification, building a test oracle based on key test results confirmed by the programmer Testing  JWalk tests the class to bounded exhaustive depths, based on confirmed and predicted test outcomes  JWalk uses state-based test generation algorithms

Example – Library Book Validation  surprise: target.issue(“a”).issue(“b”).getBorrower() == “b”  violates business rules: fix code to raise an exception Testing  all observations on chains of issue(), discharge()  n-switch cover on states {Default, OnLoan} public class LibraryBook { private String borrower; public LibraryBook(); public void issue(String); public void discharge(); public String getBorrower(); public Boolean isOnLoan(); }

Extension – Reservable Book Validation  surprise: target.reserve(“a”).issue(“b”).getBorrower() == “b”  violates business rules: override issue() to refuse “b” here. Testing  all obs. on chains of issue(), discharge(), reserve(), cancel()  n-switch cover on states {Default, OnLoan, Reserved, Reserved&OnLoan} public class ReservableBook extends LibraryBook { private String requester; public ReservableBook(); public void reserve(String); public void cancel(); public String getRequester(); public Boolean isReserved(); }

Evaluation User Acceptance  programmers find JWalk habitable  they can concentrate on creative aspects (coding) while JWalk handles systematic aspects (validation, testing) Cost of Confirmations  not so burdensome, since amortized over many test cycles  metric: measure amortized confirmations per test cycle Comparison with JUnit  propose a common testing objective for manual and lazy systematic testing; evaluate coverage and testing effort  Eclipse+JUnit vs. JWalkEditor: given the task of testing the “transition cover + all equivalence partitions of inputs”

Amortized Interaction Costs  number of new confirmations, amortized over 6 test cycles  con = manual confirmations, > 25 test cases/minute  pre = JWalk’s predictions, eventually > 90% of test cases Test classa1a2a3s1s2s3 LibBk con LibBk pre ResBk con ResBk pre eg: algebra-test to depth 2, 14 new confirmations eg: state-test to depth 2, 241 predicted results

Comparison with JUnit manual testing method  Manual test creation takes skill, time and effort (eg: ~20 min to develop manual cases for ReservableBook)  The programmer missed certain corner-cases  eg: target.discharge().discharge() - a nullop?  The programmer redundantly tested some properties  eg: assertTrue(target != null) - multiple times  The state coverage for LibraryBook was incomplete, due to the programmer missing hard-to-see cases  The saved tests were not reusable for ReservableBook, for which all-new tests were written to test new interleavings

Advantages of JWalk JWalk lazy systematic testing  JWalk automates test case selection - relieves the programmer of the burden of thinking up the right test cases!  Each test case is guaranteed to test a unique property  Interactive test result confirmation is very fast (eg: ~80 sec in total for 36 unique test cases in ReservableBook)  All states and transitions covered, including nullops, to the chosen depth  The test oracle created for LibraryBook formed the basis for the new oracle for ReservableBook, but…  JWalk presented only those sequences involving new methods, and all interleavings with inherited methods

Speed and Adequacy of Testing  Test goal: transition cover + equiv. partitions of inputs  manual testing expensive, redundant and incomplete  JWalk testing very efficient, close to complete eg: wrote 104 tests, 21 were effective and 83 not! eg: JWalk achieved 100% test coverage Test classTTETE TRTR Adeqtime min.sec LibBk manual %11.00 ResBk manual %20.00 LibBk jwalk %0.30 ResBk jwalk36 090%0.46

Conclusion Performance of JWalk testing  clearly outperformed manual testing  coverage based on all states and transitions  input equivalence partitions are not yet handled Performance of JWalkEditor  unexpected gain: automatic validation of prototype code  c.f. Alloy’s model checking from a partial specification Moral for testing  just automatically executing saved tests is not so great  need systematic test generation tools to get coverage  automate the parts that humans get wrong!

Any Questions?

Bibliography A J H Simons, JWalk: a tool for lazy systematic testing of Java classes by introspection and user interaction, Automated Software Engineering, 14 (4), December, ed. B. Nuseibeh, (Springer, USA, 2007), SpringerLink: DOI /s , 8 September, Final draft version also deposited with White Rose Research Online.JWalk: a tool for lazy systematic testing of Java classes by introspection and user interaction Final draft versionWhite Rose Research Online A J H Simons and C D Thomson, Lazy systematic unit testing: JWalk versus JUnit, Proc 2nd. Testing in Academia and Industry Conference - Practice and Research Techniques, September, eds. P McMinn and M Harman, (Cumberland Lodge, Windsor Great Park: IEEE, 2007), 138. See also the A1 poster presenting this result.Lazy systematic unit testing: JWalk versus JUnitA1 poster A J H Simons and C D Thomson, Benchmarking effectiveness for object-oriented unit testing, Proc 1st. Software Testing Benchmark Workshop, 9-11 April, eds. M Roper and W M L Holcombe, (Lillehammer: ICST/IEEE, 2008).Benchmarking effectiveness for object-oriented unit testing A J H Simons, N Griffiths and C D Thomson, Feedback-based specification, coding and testing with JWalk, Proc 3rd. Testing in Academia and Industry Conference - Practice and Research Techniques, August, eds. L. Bottacci and G. M. Kapfhammer and M. Roper, (Cumberland Lodge, Windsor Great Park: IEEE, 2008), to appear.Feedback-based specification, coding and testing with JWalk A J H Simons, A theory of regression testing for behaviourally compatible object types, rev. and ext., Software Testing, Verification and Reliability, 16 (3), UKTest 2005 Special Issue, September, eds. M Woodward, P. McMinn, M. Holcombe, R. Hierons (London: John Wiley, 2006), A theory of regression testing for behaviourally compatible object types A J H Simons, Testing with guarantees and the failure of regression testing in eXtreme Programming, Proc. 6th Int. Conf. on eXtreme Programming and Agile Processes in Software Engineering (XP 2005), eds. H Baumeister et al., Lecture Notes in Computer Science, 3556, (Berlin: Springer Verlag, 2005), Testing with guarantees and the failure of regression testing in eXtreme ProgrammingProc. 6th Int. Conf. on eXtreme Programming and Agile Processes in Software Engineering Wikipedia entry for JWalkJWalk Wikipedia entry for Lazy Systematic Unit TestingLazy Systematic Unit Testing