When selecting a type of test, the challenge is to select the test type that provides (and maintains) the correct test coverage with the minimal amount of effort (both initially and as the design matures). It is also important to understand the assumptions that different diagnostic algorithms make for each type of test. The types of tests that can be selected are as follows:
For path-based tests, the Analyst begins by specifying the test location and eXpress automatically calculates test coverage (the coverage can be constrained in a variety of ways, depending on the specific test type). For coverage-based tests , the Analyst explicitly enumerates the test coverage (depending on the type and settings selected, eXpress may automatically calculateinterference for the test). Complex tests are build out of other test definitions.
Test Type Considerations
The best way for an Analyst to excel at defining tests is to first learn about the idiosyncrasies of each test type (by clicking on the corresponding link above). Neverless, because it can be difficult to determine the right type of test to use, the following flowchart has been developed to aid the Analyst in choosing the best test definition method:
The following table lists some of the questions that must be considered when choosing a test type:
What is being Tested?
A test result from a subsystem
A known value at a particular point
A comparison between outputs
A visual indication
etc.
When is the Test Meaningful?
Off-line Testing
Embedded Diagnostics
During Maintenance Only
Restricted to certain Operating Modes
etc.
Is there significance tothe Test Name?
Names can indicate phases of testing (IBIT, PBIT, etc)
Sometimes it is important to consider how the model may be changing in the future. If few changes are expected, test types that do not update as automatically may be used to save time. Ideally, once a test is defined, it never needs to be touched. In practice, however, tests must occasionally be reworked as the model matures. The degree to which rework is required is influenced by the following factors:
Degree to which the design is changing
Types of Tests used
Phase of Development
While design changes and the phase of development are factors that can not be controlled, it is very possible to limit rework purely through the types of tests used. This is especially true when considering the fact that it is often desirable to use different types of tests early in development for diagnostic "forecasting" than one would use later in development when obtaining final numbers. Put simply, any of the other influences that cause test definition changes can be reduced through intelligent test type selection.
Ability to Prevent New Coverage from Being Added to Path-Based Tests
For path-based (Operational, User-Initiated and Probe) tests, you can now specify that new functions and failure modes should not be added to the coverage when the design changes. Once this setting is enabled, the test will be treated like a coverage-based test—additional coverage will only be added when you change the settings on the test (test location, applied stimuli, state selections or test coverage filters) or explicitly re-allow new coverage on updates.
This setting can only be changed in Grid View. Select the “New Coverage on Update” column from the Test Interpretation folder while editing tests in Grid View. Then change the value in this column from “Include new elements in coverage” to “Include only previously-covered elements”.
