CitLabLanguage

CitLab Language

How to model problem paramters

In the Parameters section the designer specifies the parameters (inputs) of the system. CITLAB language forces the designer to name parameters and to specify their types by listing all the values in their domain. Four kinds of parameter type are introduced:

Enumerative

Parameters that can take a value in a set of symbolic constants. Enumerative parameters are declared in the following way. For instance if the display of the cell phone can be colored (with 16 or 8 millions colors) or black and white, we introduce the following parameter.

Enumerative display {16MC 8MC BW};

Boolean

Parameters that can be either true or false, which can be declared as follows. For instance if the phone can have an email viewer, the designer can introduce the following parameter.

Boolean emailViewer;

Range

Numerical values in a range for parameters that take any value in an integer range. The user can also specify an integer step. For instance, if the phone has a number of lines between 10 and 30, but the designer want to test only this parameter every 5 values, he/she can write:

Range textLines [ 10 .. 30 ] step 5;

Note that the step can be omitted and in that case its value is 1, otherwise it must be a divisor of the difference between the two extreme values.

Numbers

A list of Numbers for parameters that take any value in a set of integers. It is like an enumerative, but mathematical comparisons and operations are allowed over these parameters.

Numbers year {2012 2013};

How to define types

Types can be implicitly introduced directly when declaring a parameter belonging to an anonymous type or they can be defined with their name in the Types section to be used in parameters declaration. For instance, a type can be defined as follows and this allows two parameters to share the same domain.

Types:
EnumerativeType
cameraType { 2MP 1MP NOC};
end
Parameters:
Enumerative rearCamera : cameraType;
Enumerative frontCamera : cameraType;
end

How to model constraints

In the CITLAB language all the constraints must be listed in a section called Constraints (and included between two # symbols ). For instance, assume that the user wants to model the following two constraints:

• if the display is black and white, then the phone cannot have any camera;
• if the phone has the email viewer or the front camera, then the display is colored and the lines greater than the given threshold (defined as constant).

He/she can add specify them as follows:

Constraints:
# display==display.BW => rearCamera==cameraType.NOC #
# emailViewer==true or frontCamera!=cameraType.NOC =>
    display!=display.BW and textLines>=threshold #
end

We assume that all the constraints must be satisfied by any test case, i.e., the constraints are conjoint with an implicit "and" operator.

How to model seeds

The testers can also force the inclusion of their favorite test cases by specifying them as seed tests. The seed tests must be included in the generated test set without modification. Since seeds represent tests the user has already executed or will execute in any case, the generation algorithm should take advantage of the seeds and avoid redundant coverage of interactions. In CITLAB, seeds can be added in the Seeds section and can be expressed as a sequence of assignments as follows. For instance, the user wants to force the inclusion of the following combinatorial test, by writing in the model:

Seeds:
# emailViewer=false , display=display.16MC,
frontCamera=cameraType.NOC, year = 2012,
rearCamera=cameraType.2MP, textLines=30 #
end

How to model test goals

CITLAB allows the tester to introduce extra testing requirements by means of test goals. They must be considered in addition to the desired t-wise coverage. In fact, the user may be interested to test some particular critical situations or input combinations, for instance simple incomplete combinations, or more generic relations than simple combinations among parameters. For instance, if the user wants to be sure that the test suite contains at least a test in which at least one camera is missing and the display has at least threshold lines, he can write the following test goal:

TestGoals:
    # (rearCamera == cameraType.NOC or frontCamera == cameraType.NOC) and
        textLines >= threshold #
end

Note that most tools do not support test goals and seeds, however we decided to include them in the language because one of the CITLAB aims is to provide a standard common language capable to represent a rich variety of combinatorial testing concepts.