Class Notes (1,100,000)
CA (650,000)
UW (20,000)
CS (1,000)
CS447 (60)
Lin Tan (60)
Lecture 16

CS447 Lecture Notes - Lecture 16: Daikon, Metar, Finite-State Machine


Computer Science
Course Code
Lin Tan

This preview shows page 1. to view the full 4 pages of the document.
Software Testing, Quality Assurance and Maintenance Winter 2015
Lecture 22 — March 2, 2015
Patrick Lam version 1
Graph Coverage for Specifications
We’ll move further up the abstraction chain now and talk about testing based on specifications.
Specification-based testing can help ensure that a system doesn’t drift too far from its intended
behaviour, and tends to focus on higher-level concerns than the testing we’ve seen so far, which is
based on properties of the source code.
Sequencing Constraints
Libraries often come with constraints on permissible actions; we call these constraints sequencing
Java Iterators. Here are two possible constraints.
(1) A good practice is to always call hasNext() before calling next(). (2) The Java API states that
clients must not use an Iterator after they have modified the underlying Collection. For instance,
c = new LinkedList(); c.add(o1); i = c.iterator();; c.add(o2);; /*
bad! */
The general format of sequencing constraints is “do X before Y”, or “don’t do W before A”. Here
is another sequencing constraint, this one implicit.
/* @requires size() > 0 */
public int dequeue() { ... }
/* @ensures size() = \old(size()) + 1 */
public void enqueue (int x) { ... }
Assuming that the only way to increase size() is by calling enqueue(), then a client had better
call enqueue() before calling dequeue().
It’s generally useful to look for such constraints in code that you’re developing or testing, even if
it’s hard to identify them. These constraints specify partial program properties.
Using Sequencing Constraints. Our approach will be to verify that sequencing constraints
hold (or are never violated) on all paths through a graph modelling the system under test.
You're Reading a Preview

Unlock to view full version