Universal Functional Test (UFT):
A Cost-Effective Manufacturing Test Development Software Platform.
Compactness:
When writing a functional test a common step is to look for the appearance of a specific phrase, then continue to the next step OR come to an error/default condition after a preset timeout. The following 8-line tcl/expect code snippet is built on to make a number of the basic procedure calls that make up UFT. :
package require Expect
catch {open "com1:" r+} s
catch [exp_spawn -noecho -open $s]
set timeout 10
expect {
"Boot Menu" {set productType UbootMenu}
default {set productType generic}
}
This small amount of code performs the following functions:
Open a serial port and passes the port it to expect.
Sets a variable “productType” to “UbootMenu” if the string “Boot Menu” appears anywhere in the text produced by the port within 10 seconds. Program execution continues immediately upon this condition being met.
All other conditions including errors result in productType being set to “generic” execution to continue after 10 seconds.
For comparison, the following table shows the lengths of similar sample code in several other languages. Since these are publicly posted samples they do not have the exact behavior as described in the above Tcl/Expect snippet. The deviations are noted in red and would take more code to achieve the desired result.
Modularity:
Reliable use of test software with different hardware is a basic building block of this system. Each UUT/Tester operation is abstracted to a generic procedure call. For each UUT type and each Tester component, there is a “personality” script file containing these procedure calls. Included in the same file are any parameters required to perform each necessary operation on the given device. Devices that are out-of-rev can be upgraded automatically to current-rev prior to test. This simplifies the burden on the test engineer by minimizing the number of test varieties that must be maintained.
Custom content such as test machine configurations, test steps and limits are stored in configuration files.
Auto-Recognition of UUT:
The general-purpose UUT-thread is provided with specific strings output by the various product families early on in their boot processes. These are used in the “Waiting for UUT” state to determine which “personality” script to load for test. Further uniqueness broken down in the “personality” script defines the use of any combination of product characteristics such as model, HW revision, FW revision, SW revision. Each UUTs has a unique connection port, and is addressed from 1 to N by logical port number (whether local, terminal server, or chassis port number).
Ports may be reserved for special functions such as firmware upgrades, so your operators don’t need to press any buttons on the computer to perform these steps.
Disconnect Detection:
Non-idle disconnect detection or “Crash” of the product’s CLI is always a possibility. This expectation is built into the low-level routines for interacting with the product as a “Timeout” error, generally a failure. Alternatively, there is an accepted issue in your product that occasionally causes negative results like a crash, UFT can employ fault-tolerance to recover and continue the test.
Idle disconnects are disconnects detected during the idle state, when the Operator is expected to disconnect the product. UUT thread loops through simple commands such as LED diagnostics, receiving the appropriate command prompt back from the product. When a command prompt is not received within a UUT-appropriate timeout, the UUT is assumed to be disconnected. The UUT thread displays final results and prepares itself to detect the next new UUT. The results are cleared from the screen upon the detection of the next UUT.
Logging:
A unique logfile is generated for each UUT session. Taking advantage of the unique nature of physical interfaces, there can only be one UUT at a time per Terminal Server port. Adding a timestamp to those details makes a unique filename as follows:
[TestName]_UUT_[StationName]_[PortNumber]_[Time_Datestamp].log
At the end of each test, logs are immediately sent to the server via fault-tolerant mechanism so that production does not stop for network/server issues. This provides an indelible record of the test while permitting production to continue even while your network is down. If the same UUT returns to the tester several times, the logs are NOT appended nor overwritten – there is a unique log for each session.
All communication with the UUT or test equipment is in the form of a command-response dialog, which at times results in multiple dialogs going on simultaneously. Fortunately, there is a standardized, plain English way to track a dialog involving multiple parties. Logfiles are in playbill script format as follows:
[Timestamp][Speaker:Port]:[Message]
This allows technicians to view the events chronologically, or find specific events with a search. UUT logs do NOT key in on the keywords in the “expect” statements, instead recording comprehensive records of everything said by all parties.
Some tests produce graphical, directory structures, or other digital collateral. This is captured along with the log file and submitted to the central repository in zip format.
For More Information
If you have an questions or want to know more, click the button below to email us or schedule a meeting.
Commentaires