Lofton Henderson
March 16, 2001
The project documents of SVG BE-suite and the WebCGM test suite have the start of a glossary for some of the terminology in the respective projects. Below is an excerpt. Some terms might not be of general interest, and some definitions might be arguable. Nevertheless it should be useful, if for no other reason than provoking the inclusion of some terms into the glossary.
A test which lightly exercises one of the basic functionalities of the standard (Recommendation). Collectively, the BE tests of a functional area (e.g., chapter) give a complete but lightweight examination of the major functional aspects of the chapter, without dwelling on fine detail or probing exhaustively. BE tests are intended to simply establish that a viewer has implemented the functional capability.
A test which is intended to show the capabilities of the standard (Recommendation), or a functional area thereof, but is otherwise not necessarily tied to any particular set of testable assertions from the standard.
Also called drill-down tests. DT tests probe for exact, complete, and correct conformance to the most detailed specifications and requirements of the standard (Recommendation). Collectively, the set of DT tests is equivalent to the set of testable assertions about the standard.
See Detailed Test.
An Error Test probes the error response of viewers, especially for those cases where the standard (Recommendation) describes particular error conditions and prescribes viewer error behavior.
See Test Requirement.
See Test Requirement.
The program, process, or context associated with test suite materials, that organizes the materials and test results for presentation to the user, and facilitates execution of and navigation through the test suite.
A testable assertion which is extracted from the standard (Recommendation). Also called Semantic Requirement (SR) or Test Assertion (TA) in some literature. Example. "Non-positive radius is an error condition."
A reformulation of a Test Requirement (or, one or more TRs) as a testing directive. Example. "Verify that radius is positive" would be a Test Purpose for validating file instances, and "Verify that interpreter treats non-positive radius as an error condition" would be a TP for interpreter or viewer testing.
As used in these project, an executable unit of the material in the test suite which implements one or more Test Purposes (hence verifies one or more Test Requirements). Example. An SVG test file which contains an elliptical arc element with a negative radius. In practice in these projects, the relationship of TRs to TCs can be many-to-many.
The ability, in a test suite, to trace a Test Case and its Test Purpose back to the applicable Test Requirement(s) in the standard specification (Recommendation).