# Test Record
URL: /test-record

Complete reference for the OpenHTF test record structure including test outcomes, phase records, measurement data, attachments, and diagnosis results.

Understand the complete test record that OpenHTF produces after every test execution.

Every test execution produces a `TestRecord` — a structured object containing everything that happened: outcomes, measurements, phase results, logs, attachments, and diagnoses. Output callbacks receive this record to write JSON, send to a database, or integrate with systems like TofuPilot.

Serial number or identifier of the device under test.

Identifier of the test station that ran the test.

Overall test result: `PASS`, `FAIL`, `ERROR`, `TIMEOUT`, or `ABORTED`.

Additional context for the outcome, such as which phase caused a failure.

Test start timestamp in milliseconds since epoch.

Test end timestamp in milliseconds since epoch.

Ordered list of phase execution records.

All log entries captured during test execution.

Test-wide metadata: every keyword argument passed to `htf.Test(...)` plus `test_name` and the loaded `config`. See Metadata.

Name, docstring and (when `capture_source` is on) source of the test module.

All diagnosis results from phase and test diagnosers.

Whether the test passed but with marginal measurements.

All phases passed and all measurements met their validators.

One or more measurements failed validation, or a phase returned `STOP` or `FAIL_AND_CONTINUE`.

An unhandled exception occurred during test execution.

A phase exceeded its `timeout_s` setting.

The operator or system aborted the test before completion.

Each phase produces a `PhaseRecord` with its own outcome and measurements.

Phase function name or overridden name from `PhaseOptions`.

Phase-level outcome: `PASS`, `FAIL`, `SKIP`, or `ERROR`.

The `PhaseResult` returned by the phase function.

Mapping of measurement names to their outcomes and values.

Phase start timestamp.

Phase end timestamp.

Source code and location of the phase function.

Keyword arguments to `htf.Test()` end up in `test_record.metadata`. Use them for a part number, a firmware version, or anything a downstream tool needs. TofuPilot reads `part_number`, `revision_number`, `batch_number` and `sub_units` (plus `procedure_id` with `upload()`).

`config` is reserved — OpenHTF fills it with the loaded configuration. Phases can add to the dictionary at run time through `test.test_record.metadata[...]`, as shown below.

You can access the test record directly within a phase through `test.test_record`, though this is generally discouraged in favor of using the `test.measurements` interface.

The most common way to inspect a test record is via JSON output. See Output Callbacks for details on writing test records to files.

The resulting JSON file contains the complete test record: DUT ID, station ID, outcome, all phase records with their measurements, logs, and timing data. Field-by-field documentation of that file is in the JSON format reference.

A JSON file per run is fine on one bench. With several stations you'll want the runs in a database. TofuPilot takes this record as is: `tofupilot run` uploads it, or add the `upload()` callback.

<Card title="JSON format reference" href="/reference/json-schema" description="Every field of the serialized record." />

<Card title="Output Callbacks" href="/output-callbacks" description="Writing the record to JSON or elsewhere." />

<Card title="Diagnoses" href="/diagnoses" description="Where the diagnoses list comes from." />