智能淋浴测试需要证明什么？
智能淋浴测试要证明用户命令能够转化成正确水路动作，界面显示与真实状态一致，而且温度和安全行为在整个切换过程中受控。“能出水”只是测试的起点。
智能淋浴系统可能包括控制面板、主控器、温度传感器、冷热水执行器、出水口切换机构、显示或 LED，以及远程控制模块。有用的测试要把这些层放在同一条时间线上，才能判断延迟、出水口错误、温度波动或故障从哪里开始。
本文封面由 PASS 日志 TC-TEMP-STABILITY-001 生成，把 30°C → 40°C → 30°C 设定指令与实测温度、冷热水电机位置放在同一时间轴上；它属于内部观察记录，不代表通用产品规格。
好的测试先描述用户行为
可读的测试从真实操作开始，例如选择手持花洒、升高温度、调节流量、切换顶喷、启动预热或停止出水。自动化用例再用结构化数据描述准备条件、步骤、等待和预期行为，而不是把测试意图全部藏在脚本里。
例如，一条用例可以发送出水口命令，等待控制器报告目标模式，在规定时间内采集状态，再检查最终结果。这份定义属于测试方法和验收目标。只有实际运行记录能够关联到具体硬件、软件、夹具和条件时，才能证明某台设备是否通过。
从按键到水温的完整测试链路
一次端到端测试沿着产品运行：
- 按键、测试夹具或远程界面发出用户级命令。
- 命令被编码成产品通信协议。
- 主控器验证并解释命令。
- 产品状态机选择允许的状态转换。
- 冷水、热水和出水口执行器完成动作。
- 采集温度和状态反馈。
- LED、显示屏和状态帧反馈用户应看到的结果。
- 日志保存原始与结构化证据，供测试后复盘。
如果只检查最终状态，就可能漏掉命令延迟、指示灯提前变化、中途经过错误出水口、电机未到位或短时温度异常。
协议级测试：先确认主机收到了什么
在五工 FaucetCore 当前实现中，控制面板与主控器通过 9600 波特率 UART 通信。按键命令帧包含帧头、命令 ID 和校验；状态帧返回当前指示、实测温度、流量档位、目标温度和事件状态等字段。
这是一个具体项目实现，不是行业统一协议。但协议测试的通用问题相同：
- 合法命令是否产生文档规定的响应；
- 错误帧头、长度、ID 或校验能否被安全拒绝；
- 异常输入是否会误动阀门或破坏状态；
- 超时和半帧能否按定义恢复；
- 快速连续命令遵循最后命令、排队或其他明确策略；
- 状态数据是否足以支持后续诊断。
UART 测试通过，只能证明被测版本的通信行为。它不能证明机械阀已经到位、目标出水口确实有水，或水温足够舒适，这些层仍需独立观察。
出水口切换测试：不能只看最终模式
多出水口系统可能控制手持、顶喷、侧喷、浴缸出水或其他模式。用户感知的是切换过程，而不只是最终标签。测试记录应对齐：
- 请求的出水口和命令时间；
- 状态机变化和上报模式；
- 出水口执行器目标与观察位置；
- 用户可见的 LED 或显示状态；
- 夹具能够测量或观察到的水流行为；
- 被忽略的命令、超时和故障事件。
五工当前架构使用独立的出水口步进电机，与冷热水执行器分开。这样更容易定位问题：出水选择异常不必先假设由温控电机引起。但某个流量条件下的一次通过，也不能证明所有压力和所有阀体都具有相同切换表现。
温度和电机曲线怎样解释控制过程？
温度曲线说明水温是否接近并保持在目标附近；冷热水执行器曲线说明系统怎样改变混合比例。两者对齐后，可以发现响应过慢、超调、反复修正、机械边界、传感延迟或供水扰动。
单个最终温度不能代表稳定。分析前应定义开始事件、响应时间算法、允许区间、连续稳定时长、观察窗口，以及停止命令后的数据是否排除。具体指标见智能淋浴温度控制测试。
预热、安全与故障状态怎样测试？
有些功能更像状态机测试，而不是稳定值测量。预热或预排冷水应检查出水口、指示、温度条件、暂停或等待状态、用户停止和安全退出，并与热水循环系统区分。具体见智能淋浴预热模式。
安全测试可能包括过温、传感器异常、通信丢失、执行器边界、供水异常和停止后的恢复。运行前必须先定义安全状态。日志里没有错误码，并不能证明保护功能有效，除非该异常被有控制地引入并实际触发验证。
为什么要同时保存原始和结构化数据？
五工测试框架可以产生三层资料：
- 用于协议复原的二进制字节流；
- 包含采样、事件、摘要字段和判定数据的结构化 JSON；
- 便于快速阅读的 Markdown 摘要。
计算和画图应以结构化日志为来源。AI 辅助摘要可以标记过渡和异常，却可能简化时间区间、把配置阈值写成结果，或漏掉停止后的采样点。任何准备公开的数值，都应从结构化记录重新计算并带上测试条件。
一份有效测试报告应包含什么？
好的报告分为多层：
- 身份信息： 产品、控制器和固件版本、夹具、日期与运行编号。
- 测试条件： 可测得的冷热进水温度和压力、流量档位、目标温度、出水口、供电、采样率与时长。
- 方法： 测试定义、准备状态、命令、等待和验收标准。
- 判定： 哪些断言通过或失败，以及原因。
- 时间线： 命令、上报状态、执行器、温度、LED 和故障事件按时间对齐。
- 图表： 从结构化数据生成的可读视图。
- 原始证据： 可供重新计算和协议排查的文件。
摘要应该压缩证据，而不是代替证据。没有原始数据、单位、条件和计算方法的仪表盘截图，不足以支持性能结论。
怎样正确理解 PASS 和 FAIL？
PASS 表示这一次记录满足了该用例实际执行的断言，不代表整个产品已经验证完成、适合所有市场或不会在其他条件下出问题。FAIL 可能来自设备、夹具、方法、通信、错误预期或分析程序，仍需要通过时间线定位。
公开使用结果前，应检查：
- 断言是否真的评价了准备声称的行为；
- 需要真实供水的测试是否确实有水；
- 硬件和软件版本是否可识别；
- 条件是否覆盖目标安装范围；
- 重复运行能否得到一致结论；
- 计算是否排除了准备、停止或无效采样。
常见问题
仿真可以代替硬件测试吗？
不能。仿真和单元测试适合验证算法和软件路径，但真实阀门、传感器、水压、水温、公差和安装影响，需要在代表性硬件上验证。
为什么要记录电机或阀门位置？
它可以把命令问题与执行器或水路问题分开。上报模式可能正确，但机构仍可能延迟、未到位或机械卡住。
测试 PASS 是否代表可以量产？
不代表。它只说明该次运行满足当前断言。量产还要覆盖全部功能、安全、环境、公差、可靠性、制造波动和市场合规。
UART 正常是否就代表智能淋浴正常？
不代表。通信通过后，机械动作、真实出水、温控、界面时序和安全仍需要验证。
测试后应该保存哪些数据？
应保存测试定义、去除敏感信息的配置、产品和软件身份、结构化采样、事件、判定详情、图表，以及需要用于协议诊断的原始数据。