Fastest

Fastest is a model-based testing tool that works with specifications written in the Z notation. The tool implements (Cristia & Rodriguez Monetti 2009) the Test Template Framework (TTF) proposed by Phil Stocks and David Carrington in (Stocks & Carrington 1996).

Usage

Fastest presents a command-line user interface. The user first needs to load a Z specification written in LaTeX format verifying the ISO standard (Z Standard 2002). Then, the user has to enter a list of the operations to test as well as the testing tactics to apply to each of them. In a third step Fastest generates the testing tree of each operation. After testing trees have been generated, users can browse them and their test classes, and, more importantly, they can prune any test class both automatically or manually. Once testing trees have been pruned, users can instruct Fastest to find one abstract test case for each leaf in each testing tree. (Cristia, Rodriguez Monetti & Albertengo 2009)

Testing tactics supported by Fastest

Currently, Fastest supports the following testing tactics:

Pruning testing trees in Fastest

Fastest provides two ways of pruning testing trees (Cristia, Rodriguez Monetti & Albertengo 2010):

  • Automatic pruning.
To prune a testing tree, Fastest analyzes the predicate of each leaf to determine if the predicate is a contradiction or not. Since this problem is undecidable, the tool implements a best-effort algorithm that can be improved by users. The most important aspect of the algorithm is a library of so called elimination theorems each of which represents a family of contradictions. This library can be extended by users by simply editing a text file. Elimination theorems are conjunctions of parametric Z atomic predicates.
  • Manual pruning.
Fastest users can prune subtrees or individual leaves of testing trees by issuing two commands. These commands will prune all the test classes in the subtree regardless of them being empty or not. The main purpose of these commands is to allow engineers to reduce the number of or to eliminate unimportant test cases.

How Fastest finds abstract test cases

The tool finds abstract test cases by calculating a finite model for each leaf in a testing tree (Cristia & Rodriguez Monetti 2009). Finite models are calculated by restricting the type of each VIS variable to a finite set and then by calculating the Cartesian product between these sets. Each leaf predicate is evaluated on each element of this Cartesian product until one satisfies the predicate (meaning that an abstract test case was found) or until it is exhausted (meaning that either the test class is unsatisfiable or the finite model is inadequate). In the last case, the user has the chance to assist the tool in finding the right finite model or to prune the test class because it is unsatisfiable.

Architecture and technology

Fastest is a Java application based on the Community Z Tools (CZT) project. The tool can be used in one of two modes (Cristia & Rodriguez Monetti 2009):

  • In distributed mode Fastest works as a client-server application. The application can be installed in a number of computers each acting as client, a server or both. Users access the application through clients which send test classes to servers (called testing servers) which try to find an abstract test case out of them. In this way the heaviest task is distributed across as many computers as possible. Since the calculation of an abstract test case from a test class is completely independent from each other, this architecture speeds up the entire process proportionally with respect to the number of testing servers.
  • In application mode each instance of Fastest is completely independent of each other. All the tasks are computed in the local computer.

Adding new testing tactics

As can be seen from the TTF presentation, testing tactics are essential to the method. They are the tools that engineers must use to create the most discovering test cases possible. Then, the more sound testing tactics available to engineers the better.

In Fastest users can add testing tactics of their own by implementing the Tactic interface provided by the tool. This interface has methods to configure and apply testing tactics. The interface definition is the following:

package client.blogic.testing.ttree.tactics;

import java.util.*;
import net.sourceforge.czt.z.ast.Spec;
import common.z.TClass;
import common.z.OpScheme;

/**
 * Interface that abstracts a testing tactic (needed to generate test trees) and
 * makes possible its application to a test class in order to generate new ones.
 */
public interface Tactic {
    
    /**
     * Applies this tactic to the specified test class and returns the list with
     * the generated test classes.
     * @param tClass
     * @return
     */
    public List<TClass> applyTactic(TClass tClass);
    
    /**
     * Sets the specification of the system under test.
     * @param opScheme
     */
    public void setSpec(Spec spec);
    
    /**
     * Gets the Z schema box of the operation under test.
     * @return
     */
    public Spec getSpec();  
    
    /**
     * Sets the Z schema box of the operation under test.
     * @param opScheme
     */
    public void setOriginalOp(OpScheme opScheme);
    
    /**
     * Gets the Z schema box of the operation under test.
     * @return
     */
    public OpScheme getOriginalOp();
    
    /**
     * Parses the parameters of this tactic.
     * @param str
     * @return
     */
    public boolean parseArgs(String str);
    
    /**
     * Sets the instance of TacticInfo associated to this object.
     * @param tacticInfo
     */
    public void setTacticInfo(TacticInfo tacticInfo);
    
    /**
     * Gets the instance of TacticInfo associated to this object.
     * @return
     */
    public TacticInfo getTacticInfo();
    
    /**
     * Gets the description of this tactic.
     * @return the string with the description of this tactic.
     */    
    public String getDescription();
    
    /**
     * Sets the description of this tactic.
     * @param description
     */
    public void setDescription(String description);
}

See also

Notes

    References

    • Cristiá, Maximiliano; Rodríguez Monetti, Pablo (2009). "Implementing and Applying the Stocks-Carrington Framework for Model-Based Testing". Formal Methods and Software Engineering, 11th International Conference on Formal Engineering Methods, ICFEM 2009. Rio de Janeiro, Brazil: Springer-Verlag.
    • Stocks, Phil; Carrington, David (1996), "A framework for specification-based testing", IEEE Transactions on Software Engineering, 22 (11): 777–793, doi:10.1109/32.553698.
    • Information Technology — Z Formal Specification Notation — Syntax, Type System and Semantics (1 MB PDF) (ISO/IEC 13568:2002 ed.), 2002, pp. 196 pages.
    • Cristiá, Maximiliano; Albertengo, Pablo; Rodríguez Monetti, Pablo (2010). "Pruning Testing Trees in the Test Template Framework by Detecting Mathematical Contradictions". 8th IEEE International Conference on Software Engineering and Formal Methods (SEFM), 2010. Pisa, Italy: IEEE.
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.