LabVIEW Unit Validation Test Procedure

This content in this article contains information about LabVIEW that does not apply or is no longer applicable to the latest version. Click here to view recent documents on software engineering.

This application note was created for industrial application developers and end-user developers who need a standard procedure for unit validation of LabVIEW or BridgeVIEW code. This procedure describes a minimum set of functional testing and documentation to be done before releasing code that must meet certain quality standards. This procedure does not replace program debugging by the code developer.

The VI undergoing testing is referred to as the unit under test (UUT). Unit testing is necessary before system integration testing. System integration testing evaluates how your VIs perform with devices and software external to LabVIEW. This procedure does not provide for system integration testing, which typically is less language-dependent. However, the output of the unit testing procedure might be useful in performing system integration because it provides structure information about the LabVIEW application code. Use this procedure as one of many tools, methods, and activities to help ensure quality software. Exceptions to this procedure might be appropriate for your company culture, internal procedures, code performance requirements, or other reasons.

Related Documentation

The following documents contain information you might find helpful as you read this document:

• LabVIEW Help (linked below)
• Visual Programming with LabVIEW
  Jeff Kodosky and Jack MacCrisken
  IEEE Workshop 1991

  See Also:
  LabVIEW Development Guidelines manual
  LabVIEW User Manual (LabVIEW 7.1 or earlier)
  LabVIEW Help
  

  Conventions
  

monospace -- Text in this font is used for the proper names of disk drives, paths, directories, functions, filenames, and extensions.

monospace italic -- Italic text in this font denotes text that is a placeholder for a word or value that you must supply.

Installation

You can download the software tools for testing from the NI Developer Zone (linked below). Search the database for the string LabVIEW Unit Validation Test Procedure. These tools are delivered complete with source code and can be copied and modified within your organization without restriction. You can use them on all LabVIEW supported platforms. Screen resolution of 1024 ´ 768 or higher is recommended.

Install the VERITOOL directory and its contents to your internal drive or network drive. Complete access rights are needed for anyone authorized to perform the validation testing. veritool.llb must be accessible during testing with read and execute privileges, but not write or create.

See Also:
NI Developer Zone: Search/Upload Example Code

LabVIEW Language and Protocol

LabVIEW is based on dataflow theory that requires all VI input data be present before execution takes place. The Unit Validation Test Procedure also is based on this premise, with data inputs to a VI defining the VI test parameters and data outputs providing execution result of the VI.

LabVIEW also can execute VIs without explicit data inputs to the VI. In these cases, the input data for the VI comes from sources external to the VI and/or external to LabVIEW. Likewise, a VI may output its data results to an external sink. VI external sources and sinks are divided into four categories: Global, file, device, and system sinks and sources.

Global Sinks and Sources
Global sinks and sources are external to the VI but internal to LabVIEW, so LabVIEW globals are treated as additional dataflow I/O to the UUT. Each global data input and output must be identified and included as part of the test procedure for proper dataflow testing. This category refers only to LabVIEW globals.

File Sinks and Sources
File sinks and sources are external to both the VI and to LabVIEW. You can include file sinks in the test evaluation of a VI by requiring that the data written to a file also be a defined output (indicator) in the VI code and that the Unit Validation Test Procedure fails any UUT that does not conform to this requirement. There is no requirement for the file source data; however, to help diagnose VI functionality, place an indicator on the VI front panel to indicate the data read from a file.

Devices Sinks and Sources
Device sinks and sources are common with LabVIEW applications interfacing to instruments via software drivers. This category also includes I/O to devices such as serial ports, parallel ports, memory ports, bus cards, and so on. Device sinks and sources are external to the VI and to LabVIEW. You can include device sinks in the test evaluation of a VI by requiring that the data written to a device also be a defined output (indicator) in the VI code, typically a string, and that the Unit Validation Test Procedure fails any UUT that does not conform to this requirement. There is no requirement for the device source data; however, to help diagnose VI functionality, place an indicator on the VI front panel to indicate the data read from a file. This is especially true for devices because confirmation handshaking and error checking should always be performed when possible.

System Sinks and Sources
System sinks are calls to the system for data such as date and time or outputs such as DDE strings to applications or other system controlled events external to LabVIEW. System sinks and sources are external to both the VI and to LabVIEW. You can include system sinks in the test evaluation of a VI by requiring that the data written to a system event or object also be a defined output (indicator) in the VI code, typically a string, and the Unit Validation Test Procedure fails any UUT that does not conform to this requirement. There is no requirement for the system source data; however, to help diagnose VI functionality, place an indicator on the VI front panel to indicate the data read from a file.

A VI may have any combination of input and output data categories. The test procedure requires identification of these data categories for each VI to ensure proper testing of the UUT.

Test Procedure

The test procedure provides test files that are separate from the source code VIs, so you can manage the test files separately from the source code files under test.

Test files created by this procedure are VI Test (.VITST) files. Each UUT has a corresponding .VITST test file that contains the input data values for each test case and all test results. You can save these files as individual files or in LabVIEW libraries. When you modify and revise a VI, a corresponding new revision of the .VITST test file for the VI replaces the previous revision. If your internal procedures require archiving previous source code revisions, use the same archival and storage procedures for the .VITST test files. If you use a LabVIEW library, the operating system sees all of the test files as one library file, which may cause conflicts if your management procedures are based on operating system file control because a revision of any .VITST file in the library produces a revision of the library file.

In addition to the .VITST files (one for each VI tested), a VI group file (.VIGRP) is produced to track the unit testing for an entire group of VIs. This procedure generally considers a group of VIs as a complete VI hierarchy defining an application. You also can group a set of VIs for use across multiple applications and then run the test procedure to provide validation release control for each VI in the controlled group.

VITST Test Files
The VITST test file maintains the documented test results and the referenced association to the VI tested. The VITST test file configuration must be managed in parallel with the VI source code. The test files contain reference to the source code. The procedure requires that each VITST contain a revision designation of date and time separate from the associated VI revision information.

Use the VITST tool as a template to create the .VITST file for each UUT (select File»Save As). Use the .VITST file to define all test case definitions, test evaluation criteria, test execution data, and test results. Select Operate»Make Current Values Default then File»Save to store all values and results. You might use one of the following possible organizational structures:

• Place the .VITST test files in the same directories or libraries as the source code with like names so that you maintain tight coupling with the source code files for configuration management and archival procedures.
• Place the .VITST test files in mirrored but separate directories (or libraries) from the source code so that you maintain separate file configuration management for source and test files, but rely on manual or other system association between the source and test files.
  

VIGRP Group Tracking File
You use the .VIGRP file to define all VIs in the test group and help establish the test order and record the test results for each UUT. This file maintains the association of VIs tested as a group. This group normally consists of the entire LabVIEW application that is tested. It also might be a group of reusable VIs that are released and controlled for use across multiple LabVIEW applications. The VIGRP file also is used to store the summary of test results for the group. The VIGRP tool exports the data into a standard tab-delimited ASCII file. The VIGRP file can be used to link the unit validation testing described in this procedure and the system integration testing described by your internal procedures.

Application Design and Specification

 

Reader Comments | Submit a comment »