大家好我是 SiKi老师。修完“暂停后角色不能动”沿原步骤检查没有再出现接下来能写“这个包测试通过”吗我建议先停一下这条问题的复查结果与整份试玩包已经检查的范围是两件事。本文适合课程案例或小组小游戏修改后的交付整理讨论测试记录不提供引擎修复代码。下文暂停菜单、重开和输入方式都是假想例子没有真实项目测试次数或通过率表格也不代表任何包已经运行通过。一、先区分原问题复查和改动影响检查ISTQB CTFL v4.0.1 的2.2.3节区分了确认测试与回归测试前者关注原缺陷是否修复后者关注改动有没有带来不利影响包括已确认的修复可能影响其他部分。这里借用概念不把练习表称为认证标准。ISTQB CTFL v4.0.12.2.3节该大纲版权归ISTQB及原作者。对一个假想暂停问题我会分别问“原来的操作还会出错吗”和“改动可能影响哪些相邻操作”第二个问题不能靠第一个问题的通过结果来回答。例如退出暂停、从暂停菜单重开、暂停时打开设置可能需要分别列为候选检查路径。是否真的相关要看项目设计和改动内容我不能仅凭按钮名字就断言它们共用某段代码。二、每条记录只描述一组明确条件用“菜单测试”做一行会把多个入口和设备混在一起。我更倾向写成“包A在指定场景中用键盘打开暂停再返回”。包标识、设备、入口和操作确定以后这条结果才有可追溯的范围。如果后来换了包或改变测试条件就另写一条记录或明确标注替代关系。不要覆盖旧结果后让读者以为旧包当时也得到同样结论。预期结果应来自项目已确认的规则。如果规则还没确定例如结算画面是否允许重开这条先记为规则待确认。不能把自己临时设想的行为直接当成失败标准。三、给未测和阻塞留下位置我建议为小项目使用下列工作状态名称可以按团队习惯调整。它们是记录建议不是软件测试工具的统一枚举。状态适用情况还需要写什么通过已执行约定检查观察符合预期实际条件、观察结果和证据位置失败已执行出现不符合预期的现象具体差异及关联问题单未测尚未执行这条检查未测原因和下一步安排阻塞准备执行但被前置条件挡住缺失条件、阻塞点、后续处理不适用确认不属于本次约定范围排除理由及需求依据缺少手柄不是“手柄通过”也不自动是“不适用”。如果本次承诺支持手柄只是设备暂时拿不到应保留未测或阻塞并写清原因。如果首版明确不含手柄才有依据把它排除出这次范围。同样登录后才能到达的功能如果连登录前置条件都没满足就不能把该功能写成“没发现问题”。前置阻塞和功能本身的观察结果要分开。四、用空白表安排下一次检查下面把假想改动拆成候选路径。全部状态都留为未测方便你先制定计划再按实际执行填写不能直接复制成验收结果。假想候选路径选择它的原因预期依据当前状态从暂停返回游玩对应原问题待填项目规则未测暂停菜单内重新开始相邻入口待核对待填项目规则未测暂停中进入设置再返回界面切换待核对待填项目规则未测更换约定输入设备后操作输入条件变化待填支持范围未测实际记录还应补充包标识、环境、操作步骤、实际结果和证据位置。先核对这些路径在自己的项目中是否存在不存在的不要为了凑表而编造。只有一个小时可测试时可以先按故障影响和改动关联性排序。把没排到的项目保留下来并说明原因。删掉未测行虽然能让表格更整齐却让交付者看不见剩余风险。五、汇总时同时说清范围和缺口一次检查结束后不要只发“已测完”。我会分别说明本次执行了哪些路径、发现了什么、哪些还没执行以及这些缺口会影响哪项交付判断。一段可填写的说明可以是“包标识为____本次检查范围为____实际结果见____仍未检查____原因是____下一步由____在____条件下补查。”空白项必须根据真实情况填不知道就明确保留未知。不要把“已执行项目都符合预期”改写成“所有功能正常”。前一句有明确范围后一句扩大了结论。也不要在测试项目数量还没定义完整时用一个百分比包装成整个游戏的质量分数。附件只放定位观察所需的信息。设备账号、私人目录、访问凭据和真实玩家数据要排除对外分享时证据位置可以改成团队认可的非敏感标识不能把个人文件路径直接公开。六、把未测项变成下一步而不是备注角落检查表的用途是支持下一次行动。原问题复查完成后还需要哪些条件才能判断这次交付可用设备由谁提供哪个入口先检查哪些承诺需要暂缓都应有明确去向。如果某条未测项直接关系到本次必交功能我会先暂停“已通过”的交付结论补足证据或重新确认交付范围而不是把未测改成通过。你最近一次修复以后还有哪条相邻路径没检查先写明它为什么没测以及拿到什么条件后才能继续这比一个笼统的“测试完成”更有用。