This section describes some of the terms used on the web site.
Other sections of the tutorial, and its examples, are needed for a complete understanding
of some of the terms.
Nevertheless, they are listed together here for reference.
This material is provided as an introduction to using the HTML interface with a browser.
Generally the WSDL interface elements have similar meanings to those given below.
However, the syntax rules for new lines and special characters do not apply to the WSDL interface.

**block:**
A block is a multi-line string containing
two or more factor values lines.
There is one line containing the values for each test factor.
Each block defines a set of possible test cases formed by all combinations of the listed factor values.
(Any combination of values in the block is allowed.)
Different blocks may define different sets of allowed combinations, to reflect the constraints among the factor values.
All the blocks of the partition, taken together,
contain the request data needed to generate the set of allowed test cases for the partition.
When there are more than one block in a partition, the blocks are separated by lines starting with the plus (+) character.

**combination of test factor values:**
A combination of test factor values is an association of some number of factor values.
For example, a browser value of IE with a display resolution value of high
is a combination of two factor values which could be in a particular test case.
When assessing test coverage, testers usually consider pairwise (two-at-a-time) combinations of factor values.
Any combination of factor values is either **allowed** or **disallowed** by a partition.
In the calendar example, the valid dates partition allows jan 31 and disallows jan 32.
But in the too long month partition (for invalid dates) jan 32 is allowed, and jan 31 is disallowed.

**equivalence partitioning:**
Equivalence partitioning is a technique for separating test factor values into classes of equivalent expected results.
The partitions divide the values according to their different classes of results.
And all values from the same partition are expected to give equivalent results.
When there are different classes of results, the boundaries between partitions are tested.
A boundary may be described by a single value (absolute zero in the temperature conversion example)
or by a combination of values (feb 29 2016 in the calendar example).

**functional dependence:**
A factor is functionally dependent when some or all of its values are determined by the values of one or more other factors.
In the calendar example the last day of each month is used to test the boundary of the valid dates partition.
The number of days in a month is determined by the month and year,
so the last day can be expressed as the function last_day(month,year).
In the valid dates partition, Day is a **functionally dependent factor**;
Month and Year are the **determinant factors** for the last day function.
Other factors outside this relation (if any) are **nondeterminant factors**.
Expressing values in **functionally dependent form** can clarify the constraint analysis in a test design
by making these relations among factor values explicit.
When a request contains values in functionally dependent form, e.g. last_day(month,year),
the values of the determinant factors in the test cases determine those of the dependent factor.
If month is feb, and year is 2016, then the last day is 29.
Requests with values in functionally dependent form can be converted to **fixed values form**.
The fixed values are expressed either in terms of the function's domain, e.g. last_day(feb,2016), or range, 29.

**one function of one factor:**
When all values of a functionally dependent factor are determined
by one function of one determinant factor,
(1) all allowed values of the dependent factor are covered, and
(2) each nondeterminant factor value is paired with all allowed values of the determinant and dependent factors.
In this case the functionally dependent form is equivalent to the fixed values form:
Both forms yield test cases covering the same values and pairs.

**one function of two factors:**
When all values of a functionally dependent factor are determined
by one function of two determinant factors,
(1) all allowed values of the dependent factor are covered, and
(2) each nondeterminant factor value is paired with all allowed values of each determinant factor *and*
with at least one corresponding value of the dependent factor.
In this case conversion to the fixed values form yields test cases covering all allowed pairs.

**partition:**
A partition is a multi-line string consisting of a line starting with the pound (#) character
and one or more blocks.
Each block in a partition defines a set of allowed test cases.
Taken together the blocks
contain the request data needed to generate the test cases for the partition.
Multiple blocks *combine* the test coverage when the test factor values have constraints.
Constraints may occur (1) when some test configurations are not allowed, as in the
constraints example,
and (2) when input data are constrained for equivalent expected results, as in the
calendar example.

**placeholder value:**
A factor with a placeholder value can be used to substitute values *after* test case generation.
Examples include (1) substitution of unique values in a database key, and
(2) substitution of functionally dependent factor values.

**propagation model:**
The **integrated propagation model** tests for observable effects in *other* regions
expected from the transition actions of the region under test.
The propagation model is based on the same test factor values, blocks and partitions as the integrated target state model.
However, combinations of states, trigger events, and program variable values are selected
to test the interactions with other regions.
Combinations of test factor values which do not lead to observable effects in other regions are omitted.

**request:**
A request is the data for one set of test factors that a user submits to the test case generator.
The request is a multi-line string containing one or more partitions.
Each partition contains the data to generate an independent set of test cases for equivalent expected test results.
Different partitions are used when some combinations of values are to be tested more than once,
for example, once normally and once with an error condition.
Different partitions *separate* the test coverage in these situations.
The calendar example illustrates the use of multiple partitions in a request.

**results:**
The results of the request are displayed as HTML tables.
Each partition has its own table
in which each row is a test case,
and each column contains the values for one of the factors.
Each test case row contains the values generated for all of the factors.
A Test Case ID labels each row, and a Combo Countdown shows the progress covering
the factor value combinations if the test cases were run in the order given.
The test cases cover all the allowed pairwise combinations at least once.

**sequence unit replay model:**
The sequence unit replay model tests a succession of state transitions with comparisons to expected results.
A **sequence unit** is a set of test inputs run consecutively during test execution (e.g. a test automation component).
Sequence units may have parameters specifying which inputs are applied and what their values are.
Test factors are sequence unit replay slots, in order of test execution.
Test values are the chosen sequence units and their parameters as needed.
Each partition corresponds to a state transition path with one behavior.
That is, each transition in the path is associated with one equivalence class,
so that the action of the transition is an expected result in that class.
Each test case replays a different run over the path of interest,
with pairwise coverage of the sequence units and their parameters.

**single-value factor:**
A single-value factor is a test factor with only one value in a partition.
When a set of test cases covers all pairs,
and a single-value factor is appended to the design,
the test cases with the new factor still cover all allowed pairs.
(All the values in the original test cases are paired with the new value as well.)
Including or omitting single-value factors does not need to change the number of test cases in a design.

**target state model:**
A target state model tests all transitions to each diagrammed state in one partition.
The target state model is based on the transition model:
It uses the same test factor values and blocks grouped into fewer partitions.
The actions of the transitions define equivalent expected results.
When there is only one transition to a diagrammed state,
the target state model partition is the same as the corresponding transition model partition.
If the system under test has more than one region,
a **stand-alone target state model** can test one region in isolation, using only the chosen region's state.
Alternatively, an **integrated target state model** can test the transition actions
of one region in the presence of others,
by controlling the current states of more than one region.

**test case:**
A test case is a set of specific test factor values in which one allowed value is associated
with each of the test factors.
If for example, there are five test factors, each test case has five test factor values,
one for each of the five factors.
Each set of test factor values represents an individual test from a sequence to be performed.

**test factor:**
A test factor is any variable whose values are to be controlled during the tests.
Examples are hardware and operating system configurations, load characteristics,
software versions, operating modes, input data, and so forth.
A **test factor value**
is a specific value taken by one of the test factors during the test.
A browser test factor value could be IE or Firefox.
A display resolution value could be low, medium or high.

**transition model:**
A transition model tests each diagrammed state transition in its own partition.
Its test factors include the current diagrammed state(s), program variables and transition event.
The action of the transition defines equivalent expected results.
If the system under test has more than one region,
a **stand-alone transition model** can test one region in isolation, using only the chosen region's state.
Alternatively, an **integrated transition model** can test the transition actions
of one region in the presence of others,
by controlling the current states of more than one region.

**UML state machine:**
A finite state machine is a system model composed of **diagrammed states** and **transitions** among them.
A UML state machine is a generalization of a traditional state machine.
A finite state machine can be in only one state at a time,
but a UML state machine allows for multiple regions operating concurrently.
Thus each **region** of a UML state machine has its own state,
and the overall operation depends on the states of all the regions.
UML state machines also can have hierarchically nested states and actions associated with the entry and exit of the states.
A region's diagrammed state and its **program variables** comprise its **extended state**.
By using the diagrammed state(s) and program variables as test factors, the test models define the system set-up.
An additional **event** factor specifies the trigger for the transition to the next state.
The expected result is the action of this transition.
In the test models based on state machines,
there can be one transition between each source state and target state, with one or more event(s) triggering the transition.
A **behavior** is a class of equivalent results involving one or more transitions among diagrammed states.