The goal of the object-oriented test sequence framework design is to establish a modular reusable structure that allows creation, editing, and execution of a test sequence composed of plug-in objects. Test sequences are used in almost all automated test system designs to provide for changing test requirements over time in more complex applications. The test sequence is a GDS (GOOP (Graphical Object Oriented Programming) Development Suite) object that contains an array of test step object child classes. The test step class is an abstract class (not created as an abstract class in GDS, so it can technically be instantiated, though not very useful on its own) that is the parent to all the specific varieties of test steps. Test steps are required for all applications and can be organized in categories relevant to the type of testing performed.
The framework is comprised of DQMH (Delacor Queued Message Handler) modules. The three modules described below are the primary modules used in this framework.
Test sequencer - A module that runs with no visible UI and sequentially calls each of the test steps’ execute methods when it receives the start sequence event containing the file path to the test sequence.
Sequence editor - a user interface that allows creation and editing of a test sequence file; it waits hidden until receiving an Open Sequence File event containing the path to a test sequence.
Testing user interface (UI) - the main user interface that the test operator sees when the software is running, where tests will be selected to run, and where the resulting data will be displayed.
The object-oriented plug-in style architecture is designed to allow a great deal of flexibility in future test system software design and substantial reuse over time. Instead of having to change code in the test sequencer or test editor there are just three methods that need to be overridden to add a new type of test step. The three overrides are:
The editing user interface - for configuring the test step parameters appears in the sequence editor through a subpanel interface when a test step is selected.
The testing user interface - appears in the testing UI in a subpanel while a test step is running.
The step execution method - is the heart of the test step’s functionality where the actual processing takes place; it is called directly by the test sequencer and does not show its user interface at runtime.
Three test step child classes have been implemented to validate the utility of the framework architecture. The first class is a user prompt that will display a pop-up dialog box with a configurable message that can be configured to have a single okay button or two buttons labeled “pass” and “fail.” The second test step implemented is a wait step that simply waits for a configurable amount of seconds with the option to display a countdown or just the total amount of waiting time. The third step implemented is an AI (Analog Input) Limit Check step which has a channel selection drop down, selectable upper and lower limits, and an option to decide whether or not to stop the test on failure. The AI Limit check makes several calls to the MAL (Measurement Abstraction Layer) which is an API and related code allowing the sources of measurements to change without having to change the testing framework that uses the measurement sources.
With the proper formatting and placement of the test step child class objects in the test sequence object, all available types of steps will automatically be included in the testing software. This will facilitate the creation of a flexible reusable test sequencing solution for most customers’ mid-to-high complexity automated testing applications.
To see how Ball Systems can help with your specific testing challenges, contact us here.
Ball Systems designs, develops, and delivers custom test systems and produces comprehensive build-to-print systems for companies creating or manufacturing critical electronic or electro-mechanical components for automotive, aerospace and defense and consumer appliance applications.