Ch2-5-spec - Introduction to Software Testing Chapter 2.5...

Info iconThis preview shows pages 1–5. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Introduction to Software Testing Chapter 2.5 Graph Coverage for Specifications Paul Ammann & Jeff Offutt www introsoftwaretesting com www.introsoftwaretesting.com Design Specifications A design specification describes aspects of what behavior software should exhibit A design specification may or may not reflect the implementation More accurately – the implementation may not exactly reflect the spec Design specifications are often called models of the software © Ammann & Offutt 2 Two types of descriptions are used in this chapter 1. Sequencing constraints on class methods 2. State behavior descriptions of software Introduction to Software Testing (Ch 2), www.introsoftwaretesting.com
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 Sequencing Constraints Sequencing constraints are rules that impose constraints on the order in which methods may be called They can be encoded as a preconditions or other specifications Section 2.4 said that classes often have methods that do not call each other Class stack public void push (Object o) public Object pop ( ) public boolean isEmpty ( ) ? ? ? © Ammann & Offutt 3 pop push isEmpty Tests can be created for these classes as sequences of method calls Sequencing constraints give an easy and effective way to choose which sequences to use Introduction to Software Testing (Ch 2), www.introsoftwaretesting.com Sequencing Constraints Overview Sequencing constraints might be Expressed explicitly Expressed implicitly Not expressed at all Testers should derive them if they do not exist Look at existing design documents Look at requirements documents Ask the developers © Ammann & Offutt 4 Last choice : Look at the implementation If they don’t exist, expect to find more faults ! Remember that sequencing constraints do not capture all behavior Introduction to Software Testing (Ch 2), www.introsoftwaretesting.com
Background image of page 2
3 Queue Example public int DeQueue() { // Pre: At least one element must be on the queue. Sequencing constraints are implicitly embedded in the pre and postconditions … … public EnQueue (int e) { // Post: e is on the end of the queue. © Ammann & Offutt 5 EnQueue () must be called before DeQueue () Does not include the requirement that we must have at least as many Enqueue () calls as DeQueue () calls Can be handled by state behavior techniques Introduction to Software Testing (Ch 2), www.introsoftwaretesting.com File ADT Example class FileADT has three methods: open (String fName) // Opens file with name fName close () // Closes the file and makes it unavailable write (String textLine ) // Writes a line of text to the file Valid sequencing constraints on FileADT : 1. An open (f) must be executed before every write (t) 2. An open (f) must be executed before every close () 3. A write (f) may not be executed after a close () s 1 s 2 s 3 open (f) write(t) © Ammann & Offutt 6 unless there is an open (f) in between 4. A write (t) should be executed before every close () s 4 s 5 s 6 write (t) close () Introduction to Software Testing (Ch 2), www.introsoftwaretesting.com
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
4
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 15

Ch2-5-spec - Introduction to Software Testing Chapter 2.5...

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online