第一层在开发阶段
质量的第一道关口在编写代码的人手里。自测不是把功能点一遍，而是按边界条件验证：空输入、极端值、重复操作、网络异常。把缺陷留到测试环节，修复成本会明显上升。
开发阶段还应完成必要的单元测试，重点覆盖判断逻辑复杂、分支较多的部分，而不是追求覆盖率数字。覆盖率很高的代码同样可能漏掉关键分支，数字好看不等于风险低。
代码评审是这一层的补充。评审者除了看实现，也应关注是否遗漏了异常分支，这往往能提前发现测试难以覆盖的问题，也能让处理方式在团队内保持一致。自测的具体范围应当在任务开始时说清楚，避免每个人对测到什么程度理解不同。
测试环节要验证什么
测试阶段的核心不是重复开发的自测，而是验证需求是否被正确实现，以及各模块组合后的行为是否符合预期。测试的价值在于独立视角与组合场景。
用例应当覆盖正常流程、异常流程与边界条件，并标注优先级。时间紧张时，优先保证核心链路的完整性，其余用例可以分批补充，但要明确后续补齐的时间。
对于涉及数据或权限的改动，要特别验证不同角色、不同数据状态下的表现。这类问题在单点测试中往往不会暴露，却最容易在真实使用中造成困扰。
测试用例也需要维护。需求变化后长期不更新的用例，会给出错误的通过信号，比没有用例更危险。可以按模块指定负责人，在改动时同步调整。
发布与线上验证
发布本身也是一个质量环节。除了检查清单中的配置与依赖，还应在发布后对核心链路做一次快速验证，确认行为与测试环境一致。线上环境永远存在测试环境无法复现的差异。
观察期内关注错误日志与业务指标，而不只是接口是否返回成功。技术指标正常但业务数据异常的情况并不少见，只看成功率容易错过问题。
发现问题时的处理顺序应当事先约定：先止损还是先定位、由谁决策、是否需要回滚。临场讨论会显著拉长恢复时间，而恢复速度往往比找到根因更重要。发布相关的操作步骤同样值得记录，尤其是第一次执行的流程，事后凭记忆复现容易出错。
缺陷复盘与预防
缺陷修复后要做简短归类，判断它属于实现疏漏、需求理解偏差，还是流程缺失。不同类别对应不同的改进方向。同一类缺陷反复出现，说明问题不在个人。
对高影响缺陷，应当补充相应的测试用例，避免回归。这类沉淀的性价比很高，尤其在频繁改动的模块上，一次投入能长期受益。
复盘不必每次都开长会。多数缺陷只需要一句记录加一条改进项，关键是形成习惯并定期回看，而不是等问题积累到无法忽视时才集中处理。归类结果可以按季度汇总一次，看看缺陷主要集中在哪些环节，改进方向会更清楚。
