| Testcover.com | |
| Tutorial - Definitions of Terms | ||
|
Home Existing User Login Brochure Sign up for Risk-Free Trial About Testcover.com Frequently Asked Questions Tutorial ->Definitions of Terms ->Need for the Service ->Submitting Requests ->Reading Results ->Configuration Example ->Constraints Example ->Calendar Example ->RDF/XML Example Performance Background Partners Subscription Prices Promotion Activations Student Subscriptions Privacy Policy Terms & Conditions Contact Information |
This section describes some of the terms used on the web site.
Later sections of the tutorial, and its examples, are needed for a complete understanding
of some of these terms.
However, all the terms are listed here to form one section for reference.
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.
test factor value:
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 IE5 or NS7.
Display resolution values could be low, medium or high.
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.
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 IE5 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.
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 one independent set of test cases.
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 below illustrates the use of multiple partitions in a request.
partition:
A partition is a multi-line string consisting of a line starting with the pound (#) character
and one or more blocks.
Multiple blocks are used when there are constraints making some combinations untestable.
Each block defines a set of allowed test cases.
Taken together the blocks of a
partition contain the request data needed to generate one set of test cases with constraints.
Multiple blocks combine the test coverage in these situations.
The constraints example below illustrates the use of multiple blocks in a partition.
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 one set of allowed test cases.
When there are more than one block in a partition, the blocks are separated by lines starting with the plus (+) character.
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 suggested 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.
|