TYX TestBase
Design
The design of TYX TestBase is founded on the following principles (click the hyperlinks to navigate to a detailed description of each principle):
 |
Architecture design principles:
|
||||||||
|
|
Programming interface design principles:
|
The highly modular architecture of the product enables users to build the optimal configuration for each application. It also enables system integrators to extend and customize the functionality of the product by modifying existing modules or developing add-on modules. To support customization, several modules are available in source format.
Modularity also gives TYX the ability to continuously enhance TestBase and thus ensure its long-term viability.
Optimized functional allocation
The design of TestBase realizes a good separation of generic functionality (e.g., database storage) from the application-specific functionality (test and diagnostics). The TestBase framework handles the generic functionality, freeing the the developer from the burden of implementing such functionality in the test code.
As an additional benefit, product enhancements implemented by TYX in the generic functionality area (e.g., integration of a new database engine) are instantly available to users, without requiring changes in the application code.
A large number of software interfaces exposed by TestBase are public, documented and supported by sample code. The open architecture of TestBase facilitates customization and extension, enabling system integrators and end-users to integrate third-party applications.
Because interfaces are backwards compatible, all custom and add-on components that were previously developed operate with newer versions of TestBase.
The graphical user interface of the TestBase Integrated Development Environment (IDE) and the underlying programming model provide the developer with a very simple, non-redundant programming interface. This shortens the learning curve and eliminates the need for extensive re-training.
In addition, the simple programming interface facilitates the extraction of design information during the maintenance and re-host stages of test applications. This helps reduce the reverse-engineering overhead that frequently impacts the lifecycle cost of Automatic Test System solutions.
Simplicity is achieved through the following means:
|
|
Visual Design: Engineers frequently use flowcharts to represent the control flow of complex test strategies. In TestBase, flowcharts are the native data input mechanism. |
|
|
Separation of control flow and data flow: In visual development environments, the representation of control flow and data flow on the same diagram leads to excessive visual complexity, compromising the readability in the case of large designs. The TestBase programming model provides separate mechanisms for representing the control flow and the data flow. The control flow is represented by flowcharts, while the data flow is handled through parametric data. |
|
|
Complete language independence: TestBase executes external test procedures that can be developed with various programming languages and test environments and implemented in different types of software modules (DLLs, COM servers, native file formats). When characterizing a test procedure call, the TestBase developer uses the same visual controls and the same programming model, regardless of the language and the type of module used to implement the test procedure. |
|
|
Data type unification: TestBase uses parameters to pass data to and from test procedures. These parameters accommodate many data types, such as: integer and floating-point numbers with various resolutions, boolean, string and arrays of the above. Each programming language and test environment usable for developing test procedures has its own set of data types. To shield the developer from the variability of data types, TestBase defines a set of native data types. Each time a test procedure is executed, the TestBase framework performs the appropriate conversions between the TestBase data types and the data types of the test procedure. |
The TestBase programming model favors the reuse of test procedure code for testing multiple Unit Under Test (UUT) models, within a given application domain. Reuse is supported through the following means:
|
|
Separation of diagnostic functionality from test functionality: The TestBase programming model enforces separation between diagnostic functionality and test functionality, as described in the following. The test functionality is implemented by test procedures. Typically, a test procedure verifies one characteristic of the UUT by applying stimuli, measuring the response, performing some calculations and comparing the results with predefined limits. The stimulus, measurement and calculation operations implemented by test procedures tend to be domain-specific (radio-frequency, digital, electro-optics, etc.). To enable reuse, all UUT-specfic information used by test procedures (stimulus parameters, nominal values, comparison limits, connectors and pins of various signals, etc.) must be transmitted through parameters. The diagnostic functionality is implemented by TestBase test strategies. Typically, a test strategy performs fault isolation by executing successive test procedure calls, organized in a "fault tree" flowchart. In addition, the test strategy holds the values of parameters passed to each test procedure call. Consequently, test procedures tend to be UUT-specific. The separation of functionality between UUT-independent test procedures and UUT-specific test strategies enables test procedures to be reused for multiple UUT models, within a given application domain. As an additional benefit, the development of test procedures, which requires programming expertise and familiarity with the test instrumentation, can be separated from the development of test strategies, which requires UUT expertise and is performed in the visual environment of TestBase. This enables the optimal use of resources during development. |
|
|
Test procedure encapsulation: The TestBase programming model enforces the encapsulation of test procedures, preventing direct access from the test procedure code to data that are specific to the execution context (e.g., the values of global parameters, the number of previous tests that passed or failed, etc.). All context-specific information must be transmitted via test procedure parameters. This approach prevents the creation of test procedures that work only in the context of a particular test strategy, thus stimulating the development of reusable code |
As previously described, the TestBase application can be extended by developing add-on modules. In addition, the underlying programming model can also be extended via custom data types. The custom data types are supported by add-on ActiveX components that can be developed by system integrators. TestBase users who access parameters with custom data type during development are provided with a an input form that uses familiar visual representations (e.g. S-params for radio-frequency).
This extension approach, unique to TestBase, enables TYX and system integrators to develop domain-specific extensions that encompass the visual interface of the IDE.
TestBase implements comprehensive error detection in the development stage of the application, through a specialized compiler. This enables the early detection of errors, reducing the total development time and simplifying verification and validation.
Download:
"Evaluating COTS ATS
Software – Beyond the Feature List, TYX White Paper" (PDF format,
199K). This paper analyzes the comparison criteria used for selecting a
COTS ATS software solution. It demonstrates that there are criteria more
important that solely an examination of features. While functional
features obviously are important, the software architecture of
the product and the programming interface of development tools
have at least equal importance when considering the on-going
maintenance and upgrading aspects over an entire lifecycle,
especially in large, distributed organizations.
TestBase Links:
 |
Learn more about TestBase:
|
|
Design |
|
|
|
|
|
|
|
|
|
|
|
Evaluate TestBase:
|
|
Purchase TestBase:
|
|