User Overview

User Overview#

Introduction#

This page presents an architectural overview of Fuze™ Test.

Person in the Lab#

Fuze™ Test is meant to act as a “person in the lab.” Therefore, its architecture and operating presentation closely resembles what a person would see and use in the same context.

_images/fuze-test-person-in-the-lab.png

Fuze™ Test as Person in the Lab Model#

Note

Fuze™ Test utilizes a Product Test Adapter (PTA) module that executes on the DUT host or host controller. This piece of code acts as the person-in-the-lab interface to the Fuze™ Test Executive for DUT control and results acquisition.

The PTA closes the loop so that Fuze™ Test can perform as the person-in-the-lab in the fully automated lab environment. It receives the commands from the executive and executes them on the host. It then receives the test output and sends it back to the executive.

_images/fuze-test-pta-model.png

PTA Closes the Loop in the Automated Environment#

Configuration-As-Code#

Fuze™ Test is designed around the concept of Configuration as Code (CasC). CasC in this context provides the following benefits:

  • You maintain the configuration, which is specific to your environment and needs, separately from the execution functionality, which is generic

  • You configure how the Fuze™ Test operates, rather than change the functional code

  • All configurations can be kept in your repository under configuration management

  • You define configuration through human-readable JSON files

Operating Interfaces#

The operating interfaces present the same as if a person was operating the test system.

Host or Host Controller#

Fuze™ Test requires a host or host controller associated with each DUT system. The host or host controller is the machine/entity that the person-in-the-lab would use to command, control, and gather results from the DUT system and its control and acquisition entities. It can be anything that supports standard transport layer protocols on a network, from a low-cost rPi to full-blown Windows laptop.

_images/fuze-test-pc-embedded.png

Fuze™ Test Communicates with Either the Host Directly or a Host Controller#

Fuze™ Test supports a simultaneous heterogeneous mix of host and host controller systems. In addition, both the 1:1 and 1:N models for host/controller-to-DUT system are supported.

_images/fuze-test-1to1.png

1:1 Host/Controllers to DUTs#

Note

Both the 1:1 and 1:N models for host-to-DUT system(s) are supported. However, in keeping with the person-in-the-lab architecture, native Fuze™ Test distributes test case execution across the farm assuming a 1:1 PTA Host/Controller to DUT ratio. Therefore, if a DUT farm implementation employs a 1:N PTA Host/Controller to DUT ratio, the test case design must consider it. Accordingly, such a test case’s implementation must implement the more granular details implied by the 1:N PTA Host/Controller to DUT ratio.

_images/fuze-test-1tomany.png

1:N Host/Controllers to DUTs#

Device Under Test (DUT)#

The DUT interface is through the host or host controller. The host is assumed to have and manage the connection to the DUT platform. It may be a direct connection, such as USB, or it may be an indirect connection, such as a network. Fuze™ Test supports any type of host-DUT connection because it only interacts with the host, not the DUT itself.

Control and Acquisition#

Fuze™ Test supports control and acquisition devices through the host or host controller. As with the DUT, the host is assumed to have a connection to other required control apparatus, such as power supplies, switches, etc and data acquisition apparatus such as scopes, logic analyzers, etc. In addition, if the DUT requires an external device for system programming, such as a JTAG/SWD debugger, it is supported through the host.

Control and acquisition commands are suppored within the context of a test case, as well as outside of a test case. When outside of a test case, the control commands are associated with power cycling and/or resetting of DUT system.

Mechanisms#

Fuze™ Test supports and abstracts mechanism control, such as robots. As with control and acquisition, mechanism control is through the host or host controller.

Mechanism commands are supported within the context of a test case, as well as outside of a test case. When outside of a test case, the mechanism control commands are associated with power cycling and/or resetting of DUT system.

Test Content#

Fuze™ Test test content is comprised of test cases and test suites. Test cases are atomic units of test. Test suites are logical grouping of test cases. Test suites can include test cases that are also included in other test suites.

_images/c2l-atf-test-suites-cases.png

Test Suites are Logical Grouping of Test Cases#

Test developers write test content in JSON files. One JSON format for test case files, and a second for test suite files. The Test Content Creation page gives the detailed information about test content creation and formatting.

Test Results#

Test results are generically created as CSV files. These files offer the ultimate flexibility and portability for automated parsing, interpretation, and publishing. Results can be published to various endpoints such as a Wiki, a test management tool, database, or shared file location. The Results Handling page gives the detailed information about test results handling.

Contents