What's New in NI TestStand 4.2
Print
Overview
The speed at which a test engineer can develop and deploy automated test software has a direct impact on the time to market, and therefore revenue, of the products they are testing. The latest version of NI TestStand simplifies the development of automated test software by improving integration with NI LabVIEW, NI LabWindows™/CVI, .NET, and scripting languages. NI TestStand 4.2 also reduces test development time through improved customization of report design and increased control of multicore systems. The new features in NI TestStand 4.2 for improved integration, customization, and optimization make it even easier to incorporate NI TestStand into an existing test system.
Table of Contents
- Simplified Integration with Scripting Languages
- Accelerated Deployment of LabVIEW Files in NI TestStand
- Validation of LabVIEW Code Modules
- Support for Visual Studio 2008
- Memory Leak Detection with LabWindows/CVI
- Improved Report Performance and Customization
- Processor Affinity Control for Improving Multicore Performance
- Support for PropertyObject Attributes
- Additional Resources
Simplified Integration with Scripting Languages
NI TestStand 4.2 provides a more powerful interface for calling common scripting languages such as Python, Perl, and Tcl via a completely redesigned Call Executable step type. Developers can more effectively use scripts by calling the script interpreter directly from a Call Executable step or running the script by specifying the script’s name directly. By capitalizing on either command line arguments or the application’s standard input, NI TestStand can pass data into the script. Similarly, the application’s standard output and standard error can be accessed from NI TestStand to retrieve information after the application’s execution is complete.
Read the following white paper to learn more on how to call Python, Perl, and Tcl with NI TestStand.
Figure 1. The redesigned Call Executable step type simplifies access to an application’s standard input, output, and error.
Accelerated Deployment of LabVIEW Files in NI TestStand
Using improved internal caching, the NI TestStand 4.2 deployment utility accelerates the analysis and build time of deployments. Additionally, developers creating deployments with LabVIEW files will notice tighter integration between NI TestStand and LabVIEW 8.6.1 or later. The deployment utility can now natively deploy advanced LabVIEW features such as LabVIEW object-oriented programming. Developers also have improved control over the trade-off between improved build time performance and increased deployment error handling using the new LabVIEW VI Options dialog box seen in Figure 2.
Figure 2. With the NI TestStand 4.2 Deployment Utility, developers can choose between improved performance and error handling.
Validation of LabVIEW Code Modules
Using the new software engineering tools for LabVIEW, NI TestStand developers creating LabVIEW code modules can ensure that their high-quality, reliable test code works correctly every time. Starting the software engineering process with NI Requirements Gateway for requirements management, developers can simplify requirements traceability for NI TestStand and LabVIEW by automating the linking of development and verification documents to formal requirements. Using the LabVIEW Desktop Execution Trace Toolkit, developers can view detailed low-level run-time information about LabVIEW applications to assist in debugging, troubleshooting, and optimizing LabVIEW code. Lastly, the LabVIEW Unit Test Framework Toolkit gives NI TestStand developers using LabVIEW the ability to automate the validation of individual software units (VIs) with a set of test vectors. The toolkit helps automate functional testing of each LabVIEW code module and generates validation result reports.
Learn more about software engineering with LabVIEW.
Figure 3. The LabVIEW Unit Test Framework Toolkit gives users the ability to automate the process of code module validation.
Support for Visual Studio 2008
Developers who use Microsoft Visual Studio to create code modules benefit from better integration with the latest version of the Microsoft environment. NI TestStand 4.2 supports direct integration with Visual Studio 2008 and the ability to target the .NET 3.5 framework. Using NI TestStand 4.2, developers can create, edit, and debug code modules from within the NI TestStand environment. Developers can also automatically generate code templates and perform out-of-process debugging. Using the .NET Adapter Configuration dialog box, seen in Figure 4, developers with multiple versions of Visual Studio can choose which version to use for code creation, editing, and debugging. Although previous versions of NI TestStand can call code written in Visual Studio 2008, with NI TestStand 4.2 developers can be more productive through improved debugging and code module template generation.
Figure 4. NI TestStand 4.2 now supports code creation, editing, and debugging with Microsoft Visual Studio 2008.
Memory Leak Detection with LabWindows/CVI
When integrating NI TestStand 4.2 with LabWindows/CVI 9.0, developers can capitalize on the new Resource Tracking Window in LabWindows/CVI, which gives test developers the ability to quickly jump to places in code where memory was allocated but not released. Rather than discovering memory leaks late in the development process, or worse, after test system deployment, LabWindows/CVI developers can now detect memory leaks sooner and reduce the amount of time required to debug complex test code.
Figure 5. The Resource Tracking Window in LabWindows/CVI 9.0 offers test developers the power to quickly identify the presence and source of memory leaks.
Improved Report Performance and Customization
Report Path Customization Using Expressions
With NI TestStand 4.2, developers can use expressions to customize the path where reports are stored. By using expressions and a list of predefined macros, as show in Figure 6, to programmatically generate report paths, test developers have the ability to dynamically include detailed information about a test and its results in the report’s path. This feature unlocks the potential to store passing and failing reports in different directories, name reports by unit under test (UUT) serial number, generate reports to locations based upon test date or operator, and more.
Figure 6. Using the new Specify Report File Path by Expression option, developers can programmatically decide where to generate their reports based on a number of predefined macros.
Faster XML Style Sheet Performance and Enhanced Documentation
NI TestStand 4.2 style sheets have been completely restructured to enhance report generation efficiency in both traditional and on-the-fly reporting scenarios. In conjunction with a style sheet redesign focused on organization for both performance and understanding, common XML report customization scenarios have been clearly documented – complete with tutorials – to provide easy modification of a test report’s aesthetic appearance based on a test developer’s needs.
Figure 7. Improved style sheets make customizing reports simple and intuitive.
Processor Affinity Control for Improving Multicore Performance
Using the NI TestStand 4.2 functionality for specifying processor and core affinity, test system developers have improved control over optimizations for symmetric multiprocessing performance. Though Windows operating systems automatically optimize performance by distributing work performed by concurrently executing threads across multiple CPUs, test developers need the power to control processor affinity in instances where automatic allocation adversely affects performance. NI TestStand 4.2 delivers on this need by giving developers the ability to set the processor affinity of an entire station, target processors in a Sequence Call step, or even surround a block of one or more steps using a new CPU Affinity step type for ultimate control of multicore performance optimization.
Figure 8. Developers have three different options of varying precision for specifying CPU affinity in NI TestStand 4.2.
Support for PropertyObject Attributes
Developers can capitalize on new PropertyObject attributes – available for any PropertyObject in NI TestStand 4.2 including variables, steps, sequences, and sequence files – to store customizable additional information about PropertyObjects. Rather than creating custom containers to store subproperties of existing PropertyObjects, developers can now use PropertyObject attributes to document label-value information about a PropertyObject that will be stored in a sequence file or type palette file.
Figure 9. PropertyObject Attributes give NI TestStand 4.2 developers the ability to store custom information about any PropertyObject in NI TestStand.
Additional Resources
Download the NI TestStand 4.2 evaluation software to try these new features
View a webcast on new features in NI TestStand 4.2
See how you can now call Perl, Python, and Tcl code from NI TestStand
Learn how to implement parallel test in this 20-minute webcast
The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries.
Print
Reader Comments | Submit a comment »
Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).