1 / 20

Java Specification Extension for Automated Test Development

Java Specification Extension for Automated Test Development. I gor B. Bourdonov , A lexei V. Demakov , A ndrei A. Jarov , A lexander S. Kossatchev , V ictor V. Kuliamin , A lexander K. Petrenko , S ergei V. Zelenov. J@va Design Goals.

nayef
Download Presentation

Java Specification Extension for Automated Test Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Java Specification Extension for Automated Test Development Igor B.Bourdonov, Alexei V.Demakov, Andrei A.Jarov, Alexander S.Kossatchev, Victor V.Kuliamin, Alexander K.Petrenko, Sergei V.Zelenov ISP RAS

  2. J@va Design Goals • To preserve and to extend the techniques developed in previous verification projects • Automatic generation of test oracles from pre- and postconditions • Testing mechanism based of FSM traversal • Test coverage metrics definition and tracking • Dynamic test optimization for the target coverage • To propose a specification based test development process for use in the software industry • To provide a specification extension of widely used programming language • To simplify the technology ISP RAS

  3. Solutions Proposed • Constraint specifications and axioms are both used for functional requirements recording • Constraint specifications give rise to test oracles • Axioms can be transformed into test scenarios • OO architecture is used for specification reuse • User should specify branches as the basic test coverage metric based on specifications. Several additional metrics can be extracted automatically. • Test sequence can be generated with the help of FSM traversal mechanism. Test scenarios serve as a source for FSM description. • Flexible mechanism to bind specification with target component is used ISP RAS

  4. J@va Verification Suite Components Requirements recording Test effectiveness measure Axioms Constraint Specifications Test Coverage Metrics Implementation Test Scenarios FSM Traversal Algorithms Oracles Test drivers Test sequence generation Test coverage trackers Legend Handmade component Generated component Prebuilt component Dependency Automatic derivation ISP RAS

  5. Main Features of J@va • State based behavior specifications • Object state and invariants • Precondition and postcondition of a method • Axioms and algebraic specifications • Test coverage metrics description • Abstraction management • Test scenarios executed with the help of FSM based testing machine • Flexible OO test suite architecture ISP RAS

  6. Specification of Object State Attributes of class and invariants constitute the specification of state for objects of this class. Example. Specification of a queue with elements having priorities. ISP RAS

  7. Example of Object State Specification public class PriorityQueueSpecification { public List items; // The list of queue elements public List priorities; // The list of elements’ priorities invariant I1() // The lists of elements and priorities have the same sizes { return items.size() == priorities.size(); } invariant I2() // The list of priorities contains only Priority objects { for(int i = 0; i < priorities.size(); i++) if(!(priorities.elementAt(i) instanceof Priority)) return false; return true; } invariant I3() // The values of priorities should not increase { for(int i = 1; i < priorities.size(); i++) if( ((Priority)priorities.elementAt(i)).greater( (Priority)priorities.elementAt(i-1) ) ) return false; return true; } } ISP RAS

  8. Method Precondition and Postcondition Method precondition formulates the conditions when this method can be called. Method postcondition gives the criterion of the correct method’s behavior in terms of states of method parameters and other objects before the call and after it. Example. The specifications of enq() method in the queue. The most coarse test coverage is based on branch operators, which make a section of postcondition control flow graph. ISP RAS

  9. Example of Method Behavior Specification specificationpublic synchronized void enq(Object obj) reads obj updates items.? { pre { return obj != null; } // We cannot add null object reference to the queue post { branch “Singlebranch"; List new_items = (List)(@items.clone()); // @<expr> means pre-value of <expr> new_items.addLastElement(obj); return items.equals(new_items); } } ISP RAS

  10. Axioms and Algebraic Specifications Axioms are represented as special methods that return boolean result and can have precondition. Algebraic specifications are represented as special methods with several bodies. They also can have precondition. Example. Axiom and algebraic specification for a stack. ISP RAS

  11. Example of Axiom and Algebraic Specification axiom PushAndSize() { pre{ return true; } int oldSize = size(); push(new Object()); returnsize() == oldSize() + 1; } equivalence Object PushAndPop(Object obj) { pre{ return true; } alternative { push(obj); return pop(); } alternative { return obj; } } ISP RAS

  12. Test Coverage Metrics Four predefined test coverage metrics are extracted from the control flow of pre- and postcondition. User can describe his own metrics in addition. Test execution environment keeps track of all the metrics defined and can perform dynamic optimizations for the coverage specified as target. Example. Specification of enq() operation for the queue with additional coverage metrics. ISP RAS

  13. Test Coverage Metrics Example specificationpublic synchronized void enq(Object obj) reads obj updates items.? { pre { return obj != null; } // We cannot add null object reference to the queue post { switch(items.size()) { case 0: mark “Empty queue”; break; case 1: mark “Single element in the queue”; break; default: mark “Several elements in the queue”; break; } branch “Singlebranch"; List new_items = (List)(@items.clone()); // @<expr> means pre-value of <expr> new_items.addLastElement(obj); return items.equals(new_items); } } ISP RAS

  14. Abstraction Management J@va has the following instruments for abstraction management • Inheritance of specifications • Refinement of specifications • Multi-level system of specifications As an example of inheritance we can present specifications of the ordinary queue and the queue with priorities, which has an additional operation enq(Object o) adding an element with minimum priority. ISP RAS

  15. Test Scenarios Test scenarios provide a powerful tool of test design. They are used as a source for test sequence generation. Test scenarios are executed with the help of the FSM traversal mechanism. Example. Test scenario for the queue. It is based of the FSM model of the queue, where different states correspond to different numbers of elements. The test generated from this scenario performs the traversal of the FSM having 10 states and enq() and deq() transitions from every state, except for the initial and last ones. The initial state has only enq() transition, and the last state has only deq() transition. ISP RAS

  16. Example of Test Scenario scenariopublic class QueueTestScenario { publicQueueSpecification queue = new QueueSpecification(); // The object under test public maxNumberOfItems = 10; // The maximum number of elements in // the queue during the test public synchronized AbstractGenState getGenState() // Returns the state object { return new IntGenState(queue.items.size()); // Library class IntGenState is used } scenariopublic boolean enq() // Subscenario for enq() method { if( queue.items.size() < maxNumberOfItems ) queue.enq(new Object()); return true; } scenariopublic boolean deq() // Subscenario for deq() method { if( queue.items.size() != 0 ) queue.deq(); return true; } } ISP RAS

  17. J@va Test Suite Architecture Specification Model Oracle Test coverage trackers Test coverage trackers Implementation Mediator Java Mediator Test Scenario Test driver Test Engine Legend Handmade component Generated component Prebuilt component Automatic derivation Reference Inheritance ISP RAS

  18. J@T — J@va Based Test Development Framework ISP RAS

  19. References • A. K. Petrenko, I. B. Bourdonov, A. S. Kossatchev, V. V. Kuliamin. Experiences in using testing tools and technology in real-life applications. Proceedings of SETT’01, India, Pune, 2001 • I. B. Bourdonov, A. S. Kossatchev, V. V. Kuliamin. Using Finite State Machines in Program Testing. "Programmirovanije", 2000, No. 2 (in Russian). Programming and Computer Software, Vol. 26, No. 2, 2000, pp. 61-73 (English version) • I. Bourdonov, A. Kossatchev, A. Petrenko, and D. Galter. KVEST: Automated Generation of Test Suites from Formal Specifications. Proceedings of World Congress of Formal Methods, Toulouse, France, LNCS, No. 1708, 1999, pp. 608-621 • I. B. Bourdonov, A. S. Kossatchev, V. V. Kuliamin, A. V. Maximov. Testing Programs Modeled by Nondeterministic Finite State Machine. (see [6] white papers) • http://www.fmeurope.org/databases/fmadb088.html • http://www.ispras.ru/~RedVerst/ ISP RAS

  20. Contacts Victor V. Kuliamin E-mail: kuliamin@ispras.ru 109004, B. Kommunisticheskaya, 25 Moscow, Russia. Web: http://ispras.ru/~RedVerst Phone: 007 (095) 912-5317 ext 4422 Fax: 007 (095) 912-1524 ISP RAS

More Related