TestCases can be powerful re-usable building blocks for a comprehensive suite of tests. It is worth spending some time on reviewing the best strategy for building a library of TestCases.
A TestCase has a duration. For its duration, it defines how a set of Stimulus Signals change with time. It also defines the expected response for a set of Output Signals during the same period. Tolerances can be specified so that an automated pass/fail algorithm can be executed against the results. The Signals in a TestCase are selected from the Signal Dictionary. You can create and modify TestCases and build comprehensive test Scenarios using only your mouse.
To the tester a TestCase serves two primary purposes:
•Advance the SUT from one operational state to another (establish the preconditions for a test)
•When in a particular state, verify that a required behavior is exhibited
In general, a TestCase is built to test specific requirements of the SUT. For example, in a system for vehicle security, a TestCase might verify that the alarm sounds when the trunk is opened without a key.
It is important to put some forethought into how you partition individual tests into TestCases. A TestCase could have just a couple of steps or several hundred steps, so here are some simple rules:
•A TestCase operates on a set of Signals. At any time you can modify the Signals that a TestCase uses. Just click the Pick Signals toolbar button to add or remove signals from the TestCase. Note that the changes are not saved until the next time you save the TestCase.
•To test a particular feature, pick the Input Signals that cause the feature to be exercised. You should select Output Signal that will show the expected transients. It is often beneficial to add additional signals to a TestCase just to demonstrate that they do not change.
•You will get more re-use from TestCases if they are short and modular. You can reuse TestCases in other Scenarios if they have a specific well-defined purpose.
•Always update the requirements traceability links, and review the comments in a TestCase as you make changes. Don't forget to add comments to key transitions. Some command inputs just put the system in a known state, some will actually demonstrate a particular behavior. This effort will make for easier understanding and maintenance in the future.
•On state-driven systems, design TestCases that cause a particular state Transition. These tests can be re-used when you need to put the system in that state for subsequent downstream testing.
•Limit a TestCase to testing just one or two requirements when possible and only test-related requirements in a given test. If you design long tests that test many requirements, it will be difficult to determine what requirements pass and what requirements fail when reviewing the reports. The value of traceability information diminishes when individual requirements trace to a large number of tests, and individual tests verify a large number of requirements. Also, long TestCases that test many requirements have little re-use potential.
•Group related Signals in a TestCase by locating them one above the other.
•Put the signals that change in a TestCase close together. Put signals that don't change towards the bottom of a TestCase. Use the 'Auto Hide' toolbar button to hide output signals that do not change.
•Use the Hide Signals with no change button in the Signal List to hide signals that have no expected and actual transitions.
•Become familiar with the Auto Add feature found on the properties dialog of a Job in a Scenario. This is used to automatically add any Signal that changes to a TestCase.
A single TestCase can run independently, but for most testing it runs as part of a Scenario. The Scenario schedules one or more TestCases to run in sequence or parallel. In this way, you can schedule one TestCase to set the SUT to a known state, and use this TestCase as a precondition for follow-on TestCases. For example, you may want your first TestCase to turn on the SUT's Security System feature, set up state indicating that the doors and trunk are closed and locked, and then wait fifteen seconds. The next TestCase could then verify that the alarm is activated when the trunk is opened without a key.