A TestStand sequence is typically used by a number of people, such as engineers working on a shared test project, operators running the sequence on a deployed system, and potentially developers on next-generation products years in the future. Thus, it is important to establish standards for organizing a sequence to make it readable, reusable, and maintainable.
Isolate Nonproduct-Specific Operations in a Callback or the Process Model
In general, the MainSequence in a TestStand sequence file should contain only the tests for the product or product family you are testing. Communicating with a handler, scanning a serial number, and generating a test report, for instance, should be done in either a sequence file callback or a TestStand process model. This practice results not only in a more readable sequence, but also in one that can easily be reused and maintained because it does not contain any code that ties it to systems that might change. If these elements of the test system do change, you can modify them in the callback or process model sequence rather than in each test sequence. For more information on callbacks and process models refer to the Use of the Process Model section.
Using the Setup and Cleanup Step Groups
Each sequence in TestStand has the following three step groups -- Setup, Main, and Cleanup. During normal execution, these step groups execute sequentially in that order. Within each MainSequence, it is a good idea to use the Setup step group to contain your initialization steps and the Cleanup step group to contain your error-handling and shutdown routines. In this way, the Main step group consists primarily of test steps rather than housekeeping operations. The Cleanup step group is particularly useful, because if a run-time error occurs in any step, the execution skips immediately to the Cleanup step group. This ensures that your error-handling and shutdown steps execute regardless of where the error occurs.
Setup steps and Cleanup steps run even in an interactive execution, which you initiate by selecting the Run Selected Steps or Loop on Selected Steps command. The Setup step group runs first, followed by the steps you select, followed by the Cleanup step group. In this way, the necessary initialization and shutdown operations occur automatically before and after the selected steps. If you do not want the Setup and Cleanup step groups to run in an interactive execution, you can disable this feature in the Execution tab of the Station Options dialog box.
The steps you place in the Setup and Cleanup step groups should be specific to the product or subcomponent sequence. More general setup and cleanup routines should be handled in a process model or a sequence file callback.
Modularize Test Steps into Subsequences
You should organize the steps in each MainSequence into logical groups of tests. If several tests are often together, it is appropriate to encapsulate these steps into a subsequence you can reuse in other sequences. Use the parameters of the subsequence to pass inputs and outputs. By specifying values as parameters rather than as explicit values in the subsequence, you can make your subsequence more generic and thus reusable. Furthermore, because each subsequence can have its own Setup and Cleanup step groups, modularizing your test steps into subsequences is beneficial because you can specify setup and cleanup routines that apply only to a subset of the product tests. It also provides you with more places to handle errors and ensure that the system shutdown is graceful, if an error occurs.
Another benefit of grouping steps into subsequences is that you can dynamically choose at run time which subsequence to call. For example, if three versions of the same product differ in only a few tests, you can make a single top-level testing sequence that runs all the common tests and then dynamically runs a subsequence that has the tests specific to each version. Thus, you create as few sequences as possible with little or no duplication of test steps between sequences. Reducing the number of sequences and minimizing duplication makes maintenance easier because you can modify a particular test step in only one place, and because you can make changes to the component-specific tests without affecting the other components in any way.
Share Data Using Local Variables, Global Variables, and Step Properties
TestStand gives you the freedom to share data among sequences at several different levels. With local variables, you can share data among the steps within a single sequence. With sequence global variables, you can share data among all of the sequences in a sequence file. With station globals, you can share data among all of the sequence files on one computer. With step properties, you can associate a variable with a particular step and still make it available to other steps in the sequence.
Knowing when to use local variables, global variables, and step properties is an important consideration in creating an effective sequence. For sharing data between steps, sequences, or files, use local variables, global variables, or station globals, respectively. If you want to pass information to, or return information from, an individual TestStand step, consider using a step property. If you require a unique variable for each instance of a step, you should probably create a step property instead. To add a property to a step, you must first create a custom step type for the step. Refer to the Custom Step Types section for more information.
Use Custom Data Types to Represent Common Sets of Data
For common sets of data that you need to store, consider creating a custom data type in the Types Palette. For example, you might create a data type called phone that contains a number to represent a frequency band, a string to denote model type, and an array of Boolean values for the numeric keypad. You can then create variables and properties of type phone. For example, if at a later time you need to change the definition of the phone data type to add another property, TestStand automatically updates all instances of the phone data type to include this change.
Document the Sequence
Finally, just as with any code, a sequence should be well documented. In TestStand, you can document a sequence with comments and labels. Many objects in TestStand, including variables, steps, sequences, and sequence files, have a comments field. You can access the comments field of each object in its Properties dialog box. Use the comments field to describe the purpose of the object to future developers and to document the changes you make. Use Label steps to make a sequence more readable. You can place a label anywhere in a sequence. Label steps are also useful as a target for a Goto step when implementing a loop within a sequence. Using a label as a target, you can insert additional steps into the beginning of the loop at a later time without having to change the target in the Goto step.