Package uk.ac.sheffield.vtts.web

This package contains four Java programs designed to be launched by CGI scripts, in order to offer the validation, verification, test generation and test grounding tools online, as web-services.

See: Description

Class Summary

Class	Description
WebGenerateTests	WebGenerateTests is a CGI program to generate a test suite for a cloud service specification.
WebGroundTests	WebGroundTests is a CGI program to generate a test suite for a cloud service specification.
WebValidateMachine	WebValidateMachine is a CGI program to validate the state machine of a cloud service specification.
WebVerifyProtocol	WebVerifyProtocol is a CGI program to verify the protocol of a cloud service specification.

Package uk.ac.sheffield.vtts.web Description

This package contains four Java programs designed to be launched by CGI scripts, in order to offer the validation, verification, test generation and test grounding tools online, as web-services. It is part of the Broker@Cloud Verification and Testing Tool Suite, v1.0, © Anthony J H Simons and Raluca Lefticaru, 2015. Main web site: http://staffwww.dcs.shef.ac.uk/people/A.Simons/broker/.

Package uk.ac.sheffield.vtts.web

This package contains four Java programs designed to be launched by CGI scripts, in order to offer the validation, verification, test generation and test grounding tools online, as web-services. All these programs have been designed with JDK 1.6 compliance in mind (for the sake of older web servers) but have also been compiled and executed under JDK 1.7. Examples of these programs in use may be found at the web site: http://staffwww.dcs.shef.ac.uk/people/A.Simons/broker/. All of these programs work in the same way as the command-line versions, with the exception of the test grounding program, which performs the equivalent of test generation and grounding in a single step.

Dependencies

These tools use the Java Abstract Syntax Trees (JAST) package for marshalling and unmarshalling, © Anthony J H Simons, University of Sheffield, available from: http://staffwww.dcs.shef.ac.uk/people/A.Simons/jast/. You should install and unpack JAST 1.1 (available as the jar-file JAST11.jar in the same place that you compile and install this software. This will be in some directory that is accessible from your web server's cgi-bin directory (see below).

You will need a web server configured to allow simple executable CGI scripts. You will need to write four short CGI scripts, in your preferred scripting language, to launch the Java Runtime Environment with one of the programs below as the main class to execute. You will need a web browser to submit web forms and view results as web pages. You will also need to create suitable HTML web pages designed to collect the inputs required by each program and submit them via a web form, in the URL-encoded format. Examples of such web-pages are available here: http://staffwww.dcs.shef.ac.uk/people/A.Simons/broker/. Your web browser must be configured to display raw XML files using a default CSS stylesheet.

Configuration

To run these programs under CGI (Common Gateway Interface), you will need to have a web server configured to allow you to run simple executable scripts under a directory that is usually named cgi-bin. Here, you will place small scripts which invoke the Java Runtime Environment (JRE) with one of the programs below, on your machine. While every installation may be slightly different, in the following we assume that you have a cgi-bin directory, and under this, have created a sub-directory to store compiled Java classes, cgi-bin/classes. We assume that your local JRE is installed at the absolute path: /usr/local/bin/java.

The simplest way to install the software is to compile the source code from this software bundle, and install the compiled classes, along with the unpacked classes from the JAST 1.1 bundle, in their natural package directory structure, under cgi-bin/classes, which must be a readable directory (but need not be executable). The CGI back-end only uses classes in the packages:

• uk.ac.sheffield.vtts.web
• uk.ac.sheffield.vtts.model
• uk.ac.sheffield.vtts.ground
• org.jast.ast

and the other source distribution packages are not so relevant (the software does depend on standard Java packages). Then, you will write simple executable scripts to launch each main program, and place these in the parent directory cgi-bin. Illustrations are given below.

In the following, we also assume you have designed a web page to launch each program. Each page will have a web-form which collects the expected parameters for that program. The web form should use the HTTP POST method to submit the form data, since each program expects to receive the web form data on standard input. The output from the program will be returned as XML data, apart from grounding, which returns a Java source code text file. You may need to configure your web browser to display raw XML using a default CSS stylesheet (Apple Safari sometimes does not display raw XML).

Usage

Since Java class files are not directly executable as CGI programs, you will need to write short executable scripts (in C shell, Bourne shell, etc.) that launch your Java runtime environment with the chosen program. The following example scripts are merely illustrative and do not necessarily reflect the actual pathnames on your machine. The examples each describe the web form parameter names used to pass data.

• Validation: validates a specification looking for missing transitions in the state machine. Checks all handled and ignored events, so that the designer may be confident of handling the desired events in each state. The web-form should have a text-field named url to accept the public URL of your specification file. The submitted form data should look something like this:

  url=xml_spec_url

  Where the xml_spec_url is the complete URL pathname leading to your XML specification file. The script to launch this program will contain a line like this:

  /usr/local/bin/java classes/uk.ac.sheffield.vtts.web.WebValidateMachine

• Verification: verifies a specification for logical consistency and completeness. Checks that all the guarded paths through each operation are mutually exclusive and exhaustive, such that there is no blocking or nondeterminism. The web-form should have a text-field named url to accept the public URL of your specification file. The submitted form data should look something like this:

  url=xml_spec_url

  Where the xml_spec_url is the complete URL pathname leading to your XML specification file. The script to launch this program will contain a line like this:

  /usr/local/bin/java classes/uk.ac.sheffield.vtts.web.WebVerifyProtocol

• Test Generation: generates a high-level test suite from a specification. Simulates the whole specification model (machine and protocol), generating test sequences up to a given maximum length, and optionally compressing the results. The web-form should have a text-field named url to accept the public URL of your specification file, an integer spinner field named depth to set the desired test depth, and a boolean radio button named multi to select multi-objective test generation. The submitted form data should look something like this:

  url=xml_spec_url&depth=2&multi=false

  Where the xml_spec_url is the complete URL pathname leading to your XML specification file, 2 is a chosen test depth, and false indicates single-objective testing. The script to launch this program will contain a line like this:

  /usr/local/bin/java classes/uk.ac.sheffield.vtts.web.WebGenerateTests

• Test Grounding: generates a concrete JUnit test driver, based on the assumption that the service-under-test is either: a plain old Java object; a JAX-WS SOAP web service; or a JAX-RS REST web service. These are examples on which to base your own grounding. The web-form should have a text-field named url to accept the public URL of your specification file, an integer spinner field named depth to set the desired test depth, a boolean radio button named multi to select multi-objective test generation, a text spinner labelled ground to pick one of the three grounding formats: "Java" | "JAX-WS" | "JAX-RS" and a boolean radio button named meta to select full meta-testing of all labelled states and transitions.

  Further optional fields include a text field labelled driver to accept the target package name for the generated JUnit test driver, a text field labelled system to accept the source package name for the tested Java service client (for non-REST), a text field labelled endpoint to accept the URI of the service (for REST only) The submitted form data should look something like this:

  url=xml_spec_url&depth=2&multi=false&ground=JAX-RS&meta=true&driver=my.test.driver&endpoint=my_rest_url

  Where the xml_spec_url is the complete URL pathname leading to your XML specification file, 2 is a chosen test depth, false indicates single-objective testing, JAX-RS indicates generating code for testing a REST service, true is chosen to request full meta-testing and the other parameters are a package name and the URL of the tested REST service. The script to launch this program will contain a line like this:

  /usr/local/bin/java classes/uk.ac.sheffield.vtts.web.WebGroundTests