SQLFpc Web Interface- Generation of Full Predicate Coverage Rules for testing SQL database queries (MCDC for SQL)

To get started with SQLFpc (Web interface) read the following information. Alternatively, you can generate the rules using a Web service and both generate and evaluate them using SQLRules.

  1. Specifying the database schema
  2. Specifying the database query
  3. Specifying query parameters
  4. Description of the rules
  5. Submitting RFE/SPR reports
  6. Release Notes
  7. Back (SQLFpc main page)

1. Specifying the database schema

The first step is to specify the tables and columns that are to be used by the query. There are two different ways to perform this task: either using the Web interface or uploading an XML file.

1.1. Declaring the schema using the web interface

  1. Indicate the number of tables and the maximum number of columns and click Update.
  2. Specify the following information about tables and columns in the Database Schema . section:
    1. Name of the tables and their columns in the text fields.
    2. Specify the type of each column using the combo-box.
    3. Indicate the columns that are primary keys by clicking the Key check-box.
    4. Indicate the columns that have a NOT NULL constraint by clicking the Not Null check-box.

1.2. Declaring the schema in XML

Create a local file that will store an XML representation of the schema including the information about the database needed for the mutation process. This file can be generated from your database using the XDBSchema tool. The file must be a valid xml file (don't forget to close the tags):

  1. Begin the xml file with a tag <schema>.
  2. For each table:
    1. Place a tag <table name="TTT"> where TTT is the name of the table.
    2. For each column:
      1. Begin a tag <column name="CCC" where CCC is the name of the table.
      2. Place the attribute type="ttt" where ttt is the data type of the column. The data types supported can be viewed in the combo-box of the web interface.
      3. Optional: place the attribute key="true" if the column is primary key.
      4. Optional: place the attribute notnull="true" if the column has a NOT NULL constraint.
      5. Close the column tag (/>).
    3. Close the table tag (</table>).
  3. Close the schema tag (</schema>).

Save this file to disk, then select it using the web interface and finally click Upload this file. The Database Schema section will automatically be filled with the loaded schema.

This is an example of a schema file:

 <schema>
<table name="STAFF">
<column name="EMPNUM" type="char" notnull="true" key="true"/>
<column name="EMPNAME" type="char"/>
<column name="GRADE" type="decimal"/>
<column name="CITY" type="char"/>
</table>
<table name= "WORKS">
<column name="EMPNUM" type="char" notnull="true" key="true"/>
<column name="PNUM" type="char" notnull="true" key="true"/>
<column name="HOURS" type="decimal" notnull="true"/>
</table>
</schema>

2. Specifying the database query

Once you have declared the schema, you fill in the SQL Query text area and then click Generate Rules. The "Coverage Rules" section will display for each rule its classification (Category, Type, Sub Type, number of clause), followed by the SQL query that is to be executed for evaluating the coverage and a textual description of the test point requirement that is satisfied if the rule is covered.

A set of addtional options is available in order to exclude particular rules from the generation and select the language for the textual description of each rule.

An example of a query to be used with the above schema is:

 select S.empnum, sum(W.hours) from staff S left join works W on S.empnum=W.empnum group by S.empnum

SQLFpc processes the database query using a light-weight parser, and does very few syntactic checks on the correctness of the SQL. Therefore, the user MUST ensure that queries are syntactically correct before generating the mutants.

3. Specifying query parameters

Parameters, when present in a query, participate in the generation process in a similar way than columns or constants, and so, their data type must be known by the system. There are several ways to specify each parameter:

4. Description of the rules

The output presents the mutants in a table with five columns:

  1. ID: sequence number.
  2. Category: one of
    • S - select operators
    • J - join operators
    • C - case expressions
    • G - groupings and aggregate value
  3. Type and subtype: identifie the kind of rule
  4. Location: First letter of the SQL clause and a numer that identifies the clause that is being considered for the rule
  5. The SQL query that is to be executed for evaluating the coverage
  6. A textual description of the test point requirement that is satisfied if the rule is covered

A detailed description of all rules can be found in the article "Full predicate coverage for testing SQL database queries" (submitted, under revision).

5. Submitting RFE/SPR reports

This is an experimental research application intended for a research usage. Feedback from the users is greatly welcomed: