Concepts and Glossary

The OpenHTF vocabulary — DUT, station, test, phase, measurement, validator, plug, attachment, test record, output callback — each defined in one paragraph with a link to its page.

Last updated · Verified with OpenHTF 1.6.1

OpenHTF uses a small, fixed vocabulary. Most of it comes from the upstream README's "Nomenclature" section; the rest are terms you meet in the API. Terms are listed in the order you encounter them writing a test.

DUT (Device Under Test)

The physical unit being tested — a board, a module, an assembled product. Also called UUT (Unit Under Test) in some industries; OpenHTF's API says DUT. Every run is tied to one DUT through its DUT ID, normally the serial number, stored as dut_id in the record. Device Under Test →

Station

The computer, fixture and instruments a test runs on. Identified by station_id in every record (defaults to the hostname). One station usually runs one test script at a time; a line has many stations. Configuration → · Multi-station →

Test

An htf.Test(...) object: an ordered collection of phases plus test-wide options and metadata. Calling test.execute() runs the sequence once against one DUT and produces one test record. Phases → · Test Options →

Phase

One step of a test: a Python function that receives the test API object, does work, and returns a PhaseResult (CONTINUE, STOP, REPEAT, SKIP, FAIL_AND_CONTINUE, FAIL_SUBTEST). Phases carry measurements, plugs and options via decorators. Phases →

Phase group

A PhaseGroup of setup, main and teardown phases. Teardown runs whenever setup succeeded, even if main failed — the try/finally of hardware tests. Phase Groups →

Subtest

A named sequence of phases whose failure (FAIL_SUBTEST) does not stop the rest of the test. Lets one run report independent results for, say, Wi-Fi and Bluetooth. Subtests →

Checkpoint

A node in the sequence that stops the test (or, with action=FAIL_SUBTEST, fails the subtest) if earlier phases failed. Placed before expensive phases. Checkpoints →

Measurement

A named value a phase promises to record, declared with @htf.measures(htf.Measurement("name")...). May carry a unit, a docstring, dimensions and validators. Unset measurements fail the phase unless allow_unset_measurements is on. Measurements →

Validator

A rule attached to a measurement that decides PASS or FAIL: in_range, equals, matches_regex, within_percent, or any callable. Marginal limits flag values that pass but sit near the edge. Validators reference →

Unit

A UnitDescriptor (name, UNECE code, suffix) attached with .with_units(units.VOLT). Stored in the record so downstream tools can label and convert values. Units reference →

Dimension

An input axis of a multi-dimensional measurement (time, frequency, channel). A measurement with dimensions stores a table of coordinates → value instead of a scalar. Multi-dimensional measurements →

Monitor

A background thread that samples a function at a fixed interval while a phase runs, producing a time-series measurement. Monitors →

Plug

A class inheriting BasePlug that wraps a resource — instrument, DUT interface, operator prompt. Instantiated once per test before the first phase that needs it, torn down after the test. Injected into phases with @htf.plug(name=PlugClass). Plugs →

Operator UI

The browser interface served by station_server.StationServer: live phases and measurements, prompts, attachments, logs and per-station history. Operator UI →

Prompt

A question to the operator via the UserInput plug — a text field or an Okay button, in the console and in the Operator UI. prompt_for_test_start() is the prompt that asks for the DUT ID. User Input plug →

Diagnosis

A structured result (Diagnosis with a DiagResultEnum value) produced by a diagnoser after a phase or the whole test, classifying what happened — "over-voltage", "board defective". Branches and checkpoints can condition on diagnoses. Diagnoses →

Attachment

A file or binary blob stored in the record alongside a phase: a scope screenshot, a UART log, a calibration table. Attachments →

Test record

The TestRecord produced by every run: dut_id, station_id, outcome (PASS, FAIL, ERROR, TIMEOUT, ABORTED), timestamps, phases[] with their measurements and attachments, log_records, metadata, diagnoses. Test Record → · JSON format →

Output callback

A callable that receives the finished TestRecord. OutputToJSON writes a file; ConsoleSummary prints failures; TofuPilot's upload() sends it to a database. Several can run per test. Output Callbacks →

Configuration

Key/value settings declared with CONF.declare(...) and loaded from YAML/JSON, --config-value flags or code. Used for ports, addresses, limits and station identity. Configuration →

On this page

First-pass yield
0%4.1
Track with TofuPilot