测试用例规范

本目录保存可执行的测试用例。测试用例是需求验收条件的落地形式：它回答“用哪些步骤、在哪个环境、观察到什么结果才算验收条件成立”，但不替代真实环境验收记录，也不把本地构建结论升级为目标环境结论。

文档	内容
FNOS-001 1Panel 应用转换测试用例	T0—T2 批次的构建、安装、数据落盘、权限、资源集成用例
FNOS-001 T0 试点批次第 1 轮测试报告	首批 3 个应用（`fn-it-tools`/`fn-linux-command`/`fn-adminer`）的执行记录
FNOS-001 T0 收尾批次测试报告	收尾 11 个应用的执行记录 + 真机验收回填
FNOS-001 T1 批次第 1 组测试报告	T1 首批 14 个应用的状态落盘、权限与向导字段核对
FNOS-001 批量真机验收规程	把单应用验证批量化：通道选择、七步流程、填参规则、五级判定、失败取证与设备清理纪律
FNOS-001 全量真机验收报告（189 应用）	全部 189 个应用的真机验收结果：判定分布、失败归因、已修复缺陷与遗留风险

报告与用例的分工：FNOS-001-test-cases.md 是用例的权威定义（编号、追踪依据、步骤、预期与实际结果）；FNOS-001-t0-round*-report.md 是某一轮执行的记录（环境、命令、逐条结果、缺陷）。报告不得新增或放宽判定口径，口径变更只改用例集并记入其变更记录。

用例编号规则

用例编号继承需求功能 ID，格式为 <功能 ID>-TEST-##：

对象	格式	示例
需求功能	`FNOS-###-##`	`FNOS-001-04`
验收条件	`<功能 ID>-AC-##`	`FNOS-001-04-AC-01`
测试用例	`<功能 ID>-TEST-##`	`FNOS-001-04-TEST-01`
环境证据	`<功能 ID>-ENV-##`	`FNOS-001-04-ENV-01`

编号规则与 SDD 规格驱动维护规范的「追踪 ID」保持一致。同一功能下的用例按 -01 起连续编号，删除用例后不重排既有编号。

追踪关系

每个 P0/P1 功能形成以下链路，任一环节缺失都要在用例集中显式登记为「待确认」，不得自行补充验收口径：

text

需求功能 FNOS-001-04
  ├─ 验收条件 FNOS-001-04-AC-01 …（docs/requirements/，唯一口径）
  ├─ 计划任务 PLAN-FNOS-001-T01-01（docs/plans/，实施步骤）
  ├─ 测试用例 FNOS-001-04-TEST-01（本目录，可执行步骤）
  └─ 环境证据 FNOS-001-04-ENV-01（docs/validation/，目标 NAS 结论）

约束：

验收条件的唯一来源是需求文档。用例的「预期结果」必须能逐句回指某个 -AC-##；需求没有定义的行为一律标为「待确认」并提给需求维护者，不允许在用例里发明通过标准。
只覆盖已进入计划的优先级。P2、后续计划和尚未确认的能力（例如 FNOS-001 的 T3/T4 批次）不进入本目录的用例集，符合「未进入计划的 P2 不得出现在测试清单中」的约束。
本地验证与目标环境结论必须分开。用例的「状态」只描述该用例自身是否已执行并得出结论，不改变需求或计划的状态字段。

用例状态

状态只允许以下四种取值：

状态	含义	使用条件
未执行	尚未运行	用例已定义但没有执行记录
通过	预期结果全部观察成立	已完成执行，且证据可复核
失败	观察到与预期不符的结果	已完成执行，实际结果与预期存在差异
阻塞	无法执行或无法判定	缺少环境、权限、工具或前置依赖，且有原样错误输出为证

口径约束：

状态值只有上表四个。「部分通过」「基本通过」这类带限定词的取值不允许出现在状态字段——部分完成时按「最保守的未达成项」取整值（例如「启停通过、卸载未执行」应判「阻塞」，而非「部分通过」），把已完成部分的细节写进正文「实际结果」。
禁止把「本地构建通过」写成「已完成」「通过真机验证」。本地 fnpack build 成功只说明打包动作完成，不构成目标 fnOS 设备上的安装、启动或数据结论。
一条用例同时含本地静态与设备端运行两部分时，「通过」只对静态部分成立，必须在正文显式写出未覆盖的运行时部分，不得用整条「通过」暗示运行时也已验证。
涉及 fnOS 设备的用例，在无法执行时状态一律为「阻塞」，并附原样错误输出与解锁条件；不得用推断、经验或上游文档结果代替实测结果。
「通过」必须能追溯到可复核证据：命令行与关键输出，或仓库内文件路径加行号。

证据位置

「证据位置」写仓库根相对路径，不写开发机绝对路径。需要引用 fnOS 设备端位置时（例如应用数据目录 /var/apps/fn-<app>/var/），必须注明它指向目标 NAS，而不是开发机。

可接受的证据形式：

目标 NAS 验收记录：docs/validation/<功能 ID>-<环境>-<日期>.md 的对应小节。
命令与输出：在验收记录中贴出执行的命令和关键输出。
UI 自动化证据（Midscene 驱动 fnOS Web UI）：在验收记录中写明动作序列、观察到的界面文案与截图文件路径。截图放仓库外临时目录，不提交二进制；验收记录里保留可读的界面文字与结论。
仓库内文件：仓库根相对路径，必要时加行号。

目标环境验证工具

设备端验证分两个通道，结论等效，但工具来源必须写清：

通道	工具	适用	限制
设备端 CLI	`appcenter-cli`	目标设备上直接安装与检查	需要设备侧 `/run/trim_app_cgi/rpcbroker` 权限，权限不足时启动即 panic
Web UI 自动化	Midscene（`@midscene/web``，Bridge 模式）	`appcenter-cli` 不可用时，复用用户已登录的 Chrome 走应用中心 UI	只能观察界面呈现，不能直接读取容器日志；状态判定以界面按钮文案为准

无论走哪个通道，判定口径都是同一条：本地构建通过不构成目标环境结论；目标环境结论必须有可复核的界面观察或命令输出。通道不同不改变「阻塞 / 通过 / 失败」的状态取值。

敏感信息纪律

测试文档、报告、脚本与结果文件一律不记录下列内容：

禁止记录	替代写法
目标设备的 IP / 主机名 / 完整 URL	「目标测试设备」；命令示例用 `${FNOS_HOST}` 占位
SSH / 应用中心账号	`<NAS 账号>`；由环境变量传入脚本
口令、令牌、API 密钥、OAuth code	完全不出现；密钥只存于平台安全存储或本地临时文件，且不入库
桥模型接入密钥	同上，只出现在本地 `.env`，不入库

取证用的命令输出也要先脱敏再粘贴进文档。设备标识用代号即可，可追溯性靠文件名与日期保证，不靠地址。

维护方式

新增批次或新增应用形态时，先补需求验收条件，再在本目录增加用例；顺序不可颠倒。
用例执行后回填「实际结果」「状态」「证据位置」，并把目标环境结论写入真实环境验收记录规定的位置。
用例的预期结果发生变化时，必须同步核对需求文档的验收条件是否也变化；只改用例不改需求视为口径漂移。
「证据位置」优先指向当轮报告的对应小节；当轮报告不存在时再写配置文件路径或行号。

变更记录

日期	变更
2026-10-09	建立规范：编号规则、追踪链路、四值状态口径。
2026-10-10	补充「状态值只有四个、不允许带限定词」与「本地静态 + 设备端运行混合用例须显式标注未覆盖部分」两条约束，依据是 T0 收尾轮发现 TEST-04 被记为「部分通过」；登记两轮 T0 报告并说明报告与用例的分工。
2026-10-10	登记 T1 第 1 组报告（14 个应用）。该组的未验证项以遗留风险（R-01~R-05）形式登记，与缺陷（defect）区分：未验证是 unknown，不得记为缺陷，也不得记为已验证。
2026-10-20	新增「敏感信息纪律」小节，明确设备地址、账号、口令、令牌、桥密钥一律不入文档，替代写法为「目标测试设备」与 `${FNOS_HOST}` 占位；同次新增「目标环境验证工具」小节，登记设备端 `appcenter-cli` 与 Web UI 自动化（Midscene）两个通道并声明结论等效、口径不变；「证据位置」新增 UI 自动化证据形式（动作序列 + 界面文案 + 截图路径，截图不入库）。依据是 `appcenter-cli` 在目标设备上因 rpcbroker 权限 panic，而 UI 通道完成了同一批安装与启停验收。
2026-10-28	登记全量真机验收报告（189 个应用，103 PASS / 54.5%）。该轮把「原生应用不常驻 `running`」与「等待超时但应用已安装」两处把成功判成失败的口径错误写回规程；结论为：`FAIL` 的主因集中在非 root 运行时目录属主未对齐，而非上游镜像缺陷。

测试用例规范 ​

目录 ​

用例编号规则 ​

追踪关系 ​

用例状态 ​

证据位置 ​

目标环境验证工具 ​

敏感信息纪律 ​

维护方式 ​

变更记录 ​