# PCBA Functional Test Acceptance-Criteria Review Matrix

Version 1.1 · PCBA functional-test acceptance planning

This original engineering checklist helps a customer design authority and a PCBA manufacturing/test interface turn an agreed function into a controlled, reviewable acceptance criterion. It is editorial synthesis, not an IPC standard, a certified test method, a Huitai factory procedure, or measured test-coverage evidence. Product limits, electrical conditions, actual equipment and disposition remain project-specific approvals.

## Review the decision path

Use each row as a release-review question. The entries provide concrete checks and a next action; they are not an empty test-record template.

| Row | Decision question and why it matters | Evidence/action to agree | If evidence is missing | Approval interface | Basis |
| --- | --- | --- | --- | --- | --- |
| M1 | Can the result be traced to the exact function being accepted? | Link requirement ID/revision to criterion ID and its recorded result; state what the step excludes | Return the ambiguous requirement; do not infer untested functions from its pass | Design authority confirms requirement; test interface maps method | [NI requirement/result mapping](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html) |
| M2 | Does the criterion describe the board state in which the answer is meaningful? | Control board revision, firmware/config identity, mode, power/load and connection; define observation point/reference | Hold the affected criterion until state/stimulus is approved | Design authority defines permitted conditions; test interface confirms implementation | [NI stimuli guidance](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html) |
| M3 | Does the method distinguish “ready to measure” from “we waited”? | Identify readiness event, settling condition, range/function, trigger/acquisition window and sample processing; verify supported configuration | Resolve instrument/method prerequisites; do not import another instrument's numeric delays | Test interface supplies method evidence; design authority accepts its relevance | [Keysight triggering](https://www.keysight.com/blogs/en/tech/bench/2019/08/25/advanced-triggering-and-fast-measurement-throughput-with-a-multimeter), [BenchVue AC settings](https://helpfiles.keysight.com/BenchVueSoftware_HDML5HelpFiles/DMMApp/English/Content/GUI/Instrument%20Settings/Measurement/AC%20Voltage.htm) |
| M4 | Can two reviewers reproduce the comparison? | State unit, conversion, acceptance bounds, inclusive/exclusive operators and which result is compared | Do not choose limits from a nominal value or screenshot | Design authority approves limits/logic; test interface implements comparison | [NI May 2008 Chapter 4](https://download.ni.com/support/manuals/373435c.pdf), [JCGM definitions](https://www.bipm.org/documents/20126/50065304/JCGM_106_2012_E.pdf/fe9537d2-e7d7-e146-5abb-2649c3450b25) |
| M5 | Is the product limit distinguished from the measured-value acceptance rule? | Reference the approved uncertainty/near-limit decision rule; identify evidence required by that rule | Escalate the unresolved decision; do not silently widen limits or add a margin | Design authority and test authority agree decision rule | [JCGM sections 3.3,5.1,8.2–8.3](https://www.bipm.org/documents/20126/50065304/JCGM_106_2012_E.pdf/fe9537d2-e7d7-e146-5abb-2649c3450b25) |
| M6 | Is a change of method visible? | Control fixture/connection and method revision; review an authorized trial and relevant reference/error responses; define changes requiring revalidation | Resolve the method/control gap before production use of the affected test | Test interface owns implementation evidence; design authority approves acceptance | [NI limits/stimuli](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html), [JCGM5.1](https://www.bipm.org/documents/20126/50065304/JCGM_106_2012_E.pdf/fe9537d2-e7d7-e146-5abb-2649c3450b25) |
| M7 | Could an incomplete run be mistaken for an accepted board? | Define product failure, invalid reading, test error, abort and missing mandatory-step outcomes, plus approved retest/disposition | Retain cause and incomplete state; apply the agreed hold/review path | Quality/disposition owner agreed by both parties | [NI error handling](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html); Engineering synthesis (review exception paths, no executed trial). |
| M8 | Can the final decision be reconstructed later? | Retain unit/board ID, relevant revisions, criterion ID, measured/observed result, unit, acceptance rule, execution status and linked retests; verify output fields | Resolve absent mandatory evidence before the release decision | Both parties agree record set and release authority | [NI evaluation/logging](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html), [NI archived result-property conditions](https://download.ni.com/support/manuals/373435c.pdf) |

Every row is ENGINEERING_RECOMMENDATION. The linked documents substantiate the stated technical concepts; the complete matrix and responsibility arrangement are the author's synthesis. A review row alone does not verify the instrument, procedure, actual board behavior or customer acceptance.

## Three worked criteria with named parameters

The symbols below are example parameter names. No thresholds, actual readings, device capability, test coverage or executed trial are supplied. Each example specifies what the parties must replace with an approved value or controlled reference before production use.

| Example | Defined function and observation | Executable form once inputs are approved | Evidence and exception handling |
| --- | --- | --- | --- |
| E1: controlled rail | For REQ_RAIL, board REV_BOARD and FW_STATE, apply VIN_APPROVED and LOAD_STATE. Observe V_RAIL in volts relative to REF_NODE after READY_EVENT and the settling condition in METHOD_REV | Obtain a valid measurement using RANGE_RAIL and ACQUISITION_RULE. Apply DECISION_RULE_REV and the explicit comparison A_LOW_V ≤ V_RAIL ≤ A_HIGH_V only if that inclusive interval is approved | Record state, value/unit, method revision, bounds/operator and decision. An invalid/over-range acquisition follows the agreed error path; it is not a valid rail measurement. Sources: [NI fields](https://download.ni.com/support/manuals/373435c.pdf), [Keysight configuration](https://www.keysight.com/blogs/en/tech/bench/2019/08/25/advanced-triggering-and-fast-measurement-throughput-with-a-multimeter), [JCGM rule](https://www.bipm.org/documents/20126/50065304/JCGM_106_2012_E.pdf/fe9537d2-e7d7-e146-5abb-2649c3450b25) |
| E2: protocol response | For REQ_COMMAND in FW_STATE, with PROTOCOL_CONFIG and CONNECTION_REV, issue COMMAND_APPROVED and observe the actual reply | Evaluate VALID_REPLY against EXPECTED_REPLY_REV within TIMEOUT_RULE. Define reply validation and comparison rather than merely requiring “communication OK” | Record sent/received evidence as agreed, firmware/config and outcome. Distinguish unexpected valid reply from inability to transact; disposition is approved in ERROR_RULE_REV. No bytes, timing limits or instrument modes are invented. Sources: [NI stimuli/error concepts](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html) |
| E3: sensor-channel observation | For REQ_SENSOR with SENSOR_INPUT_APPROVED, FW_STATE and METHOD_REV, observe SENSOR_OUTPUT at the specified point/reference after READY_EVENT | If the requirement uses converted units, calculate RESULT_UNIT through CONVERSION_REV, then apply ACCEPTANCE_RULE_REV to the approved result/statistic. State separately how raw observations become the result | Record input identity, raw or retained supporting evidence, conversion identity, units and result. Missing conversion or invalid input leaves the criterion incomplete; it does not establish calibration or sensor accuracy. Sources: [NI raw/processed result handling](https://www.ni.com/en/support/documentation/supplemental/09/teststand-code-module-development-best-practices.html), [JCGM measured-value acceptance](https://www.bipm.org/documents/20126/50065304/JCGM_106_2012_E.pdf/fe9537d2-e7d7-e146-5abb-2649c3450b25) |

These examples add a decision path to the existing article's field list. E1 makes state, valid acquisition and measured-value acceptance separable; E2 makes a protocol transaction and test-execution error separable; E3 makes a raw observation and converted acceptance result separable. None is a real product specification.

## Attribution, method and reuse

Suggested citation: Huitai PCB, “PCBA Functional Test Acceptance-Criteria Review Matrix”, version 1.1. Original editorial synthesis for customer-approved board functions.

The matrix and worked rows are original editorial content (OWN_ORIGINAL). Source documents are CITATION_ONLY: no source table, diagram, screenshot, translated document, logo, customer record or factory photograph is reproduced. Source links do not grant rights to copy those documents. The JCGM guide retains its own protected publication rights.

Related parent article: [PCBA testing before shipment](https://huitaipcb.com/knowledge/pcba-testing-before-shipment).

## Application limits

Product-specific inputs and methods must be agreed for the build. This matrix supplies no safety/qualification, complete functional coverage, shipment-release or commercial performance guarantee.

© 2026 深圳市会泰精密科技有限公司. Published under the Huitai PCB brand. Attributed quotation and links are welcome; full article reproduction or copying a complete chart requires permission. Uses permitted by applicable law remain unaffected.