从周报问题清单到可复现的排障记录

周报里写“记录问题 8 条”或“重新测试 14 条”，能够说明一周做了多少工作，却不一定能让另一个人重新找到同一个问题。

最近的工作记录里同时出现了修改优化、测试问题、待解决、重新测试和待修改等状态。我越来越感觉到，问题数量适合做阶段汇总，但真正帮助排查和复测的，是每条问题背后的环境、步骤、结果和状态变化。

数量和明细要分开记录

2024 年 3 月 1 日的周报中，测试明细记录为 9 条，自我总结写成了 8 条。两处原始记录不一致，不能为了让数字看起来整齐就直接改成同一个数。

更稳妥的处理方式是：

• 明细保留 9 条；
• 汇总保留原始的 8 条；
• 说明两处存在 1 条差异；
• 后续统计时明确采用哪个口径。

这样既不会丢失明细，也不会把原始汇总悄悄覆盖。数字差异本身也是需要追踪的信息。

一条问题至少要回答什么

问题清单如果只有一句“页面显示错误”，开发和测试往往会从不同的入口理解它。为了让问题能够复现，我会尽量补齐几个基本部分：

问题位置
    -> 前置条件
    -> 操作步骤
    -> 实际结果
    -> 预期结果
    -> 当前状态

具体可以记录：

• 所属模块和页面入口；
• 使用的角色或数据状态；
• 按顺序执行的操作；
• 实际出现的页面、接口或数据结果；
• 期望系统怎样响应；
• 是否稳定出现；
• 当前是待确认、待修改、已修改还是已复测。

公开文章不展开内部模块、账号、服务器和真实业务数据。这里描述的是通用记录结构，不是对原始周报中每条问题过程的补写。

状态不能只有“完成”和“未完成”

3 月 8 日的周报记录了“还有三个问题待解决”，3 月 15 日又记录了“已重新测试 14 条，待修改 1 条”。这说明问题会经过多个阶段，不能只用一个勾选框表示结束。

可以使用更清楚的状态流转：

新发现
    -> 已确认
    -> 待修改
    -> 已修改待复测
    -> 复测通过
    -> 重新打开

如果复测仍然失败，就回到待修改或重新打开，而不是因为曾经修改过就继续标记为完成。

不同团队可以使用不同名称，重点是每个状态要有明确含义，并记录状态发生变化的依据。

复测要回到原始条件

复测不是简单打开页面看一眼。原问题是在什么角色、什么数据状态和什么操作顺序下发生，修复后就应该尽量使用相同条件重新验证。

复测时可以检查：

1. 原始步骤是否不再出现问题；
2. 修改是否影响相邻功能；
3. 正常路径和异常路径是否仍符合预期；
4. 数据和页面状态是否一致；
5. 是否需要补充新的边界条件。

如果原始记录没有环境、步骤和预期结果，复测很容易变成“看起来没问题”。这也是为什么问题记录要在第一次发现时尽量写完整。

不要把问题描述和解决方案混在一起

问题描述应该先说明现象和预期，解决方案则记录原因、修改范围和验证结果。如果一开始就在标题中写“增加非空判断”，可能会让后续排查只关注这一种处理方式。

更清楚的结构是：

现象：提交后页面没有得到预期反馈
证据：请求结果、页面状态或脱敏日志
原因：经过排查后确认
修改：实际改动的范围
复测：原路径和相关路径的结果

这是一份通用模板，不对应某个真实故障。原始周报没有记录的日志、根因和修改代码，不能根据问题标题自行补写。

周报用于汇总，问题单用于追踪

周报适合记录一周处理了多少修改、发现多少问题、复测多少条和还剩多少待处理项。问题单则应该保存每个问题的细节和状态历史。

两者可以互相引用，但不应该互相替代：

• 周报回答“本周推进到哪里”；
• 问题单回答“这个问题如何复现和处理”；
• 复测记录回答“依据什么确认已经解决”。

当汇总和明细数量不一致时，先保留差异，再检查统计范围、重复项和状态口径，不能只选一个数字覆盖另一个。

从周报问题清单走向可复现的排障记录，关键不是把文字写得更长，而是让现象、步骤、预期、证据和状态能够对应起来。这样即使过一段时间重新查看，也能知道问题当时处于什么阶段，以及后续结论是怎样得到的。