先做基线盘点：明确核对范围与准备材料
本文围绕亚星平台的功能核对展开，把它当成一条有阶段、有门槛的路线来走，而不是一次性把功能点全部点一遍。开始之前先做基线盘点，目的是让后续每一步都有可对照的起点。
准备阶段建议先确认三件事：核对范围（哪些功能必须覆盖）、参与人（谁操作、谁记录、谁复核）、记录方式（截图、步骤文字、异常描述放在同一份文档里）。范围不清时，后续验证很容易变成漫无目的的点击。
- 列出本次必须核对的功能清单，并按核心与次要分组。
- 确认账号与权限条件，记录每个账号对应的角色。
- 准备统一记录模板：功能名、操作步骤、预期结果、实际结果。
- 约定异常记录口径，避免同一现象被描述成多种说法。
基线阶段的退出标准很简单：功能清单、账号角色、记录模板三样齐备，且参与人对范围没有分歧。达不到就先补齐，不要急着进入第一阶段。
第一阶段：跑通核心功能并记录可复现步骤
第一阶段的目标是让核心功能在固定条件下跑通，并留下别人能照着复现的步骤。这一步不追求覆盖面，追求的是步骤清晰、结果稳定。
输入是基线阶段的功能清单与记录模板；输出是一份带步骤的核心功能记录。操作时按下面的顺序推进：
- 第一步，从核心功能中挑出使用频率最高的几项，逐项操作。
- 第二步，每完成一项就立刻写下步骤，不要事后补记。
- 第三步，换一个账号重做一遍，确认结果是否一致。
- 第四步，把不一致的地方单独标记，留到第二阶段处理。
这一步常见的坑是“只记结果不记路径”。结果看起来正常，但换个人操作就走不通，说明步骤记录不合格。另一个坑是把偶发现象当成稳定结论，建议对同一操作至少重复一次再下判断。
退出标准：核心功能均有可复现步骤，且至少经过一次换账号复核。
第二阶段：验证权限边界与异常处理路径
第二阶段处理第一阶段留下的不一致项，重点是权限边界与异常路径。目标是搞清楚“谁能做什么”和“做不成时系统给什么反馈”。
- 用不同角色账号分别尝试同一操作，记录允许与拒绝的差异。
- 对拒绝场景记录提示信息是否清晰、是否可据此判断原因。
- 模拟输入缺失或格式不符的情况，观察处理路径是否可预期。
- 把每个异常现象对应到具体步骤，避免只写结论。
这一阶段最容易踩的坑是把权限问题误判为功能故障。遇到操作失败，先确认当前账号角色，再判断是否为功能本身的问题。另一个坑是只测正常路径，异常路径完全空白，交接时对方无从判断边界。
退出标准：权限差异有明确记录，主要异常路径均有对应说明，遗留问题已标注优先级。
第三阶段：固化使用说明并完成交接材料
第三阶段把前两阶段的记录整理成可直接使用的材料，目标是让未参与核对的人也能按说明操作。
输入是前两阶段的步骤记录与异常清单；输出是一份使用说明加一份遗留问题清单。整理时注意： 亚星平台
- 按功能分组写步骤，每一步只做一件事。
- 把权限前提写在步骤之前，而不是藏在末尾。
- 异常处理单独成节，写清现象与建议动作。
- 遗留问题标注影响范围，便于后续排期。
这一步的坑是材料写成“结论集”，只有判断没有过程。读者需要的是怎样操作、遇到什么现象该怎么做，而不是一句“功能正常”。
退出标准：使用说明可被未参与者独立读懂，遗留问题有明确归属。
评审门与交接：怎样判定可以进入下一阶段
每个阶段之间设一道评审门，用统一问题判断是否可以推进：范围是否覆盖、步骤是否可复现、异常是否有说明、材料是否可交接。四项中有任何一项缺失，就回到对应阶段补齐，而不是带着缺口进入下一阶段。
交接时建议做一次口头走查：由接手人按使用说明独立操作一遍，记录卡住的位置。卡住的地方就是说明需要补充的地方。完成走查后，把使用说明、异常清单、遗留问题一并移交，这条从基线到交接的路线才算走完。