漏侧bug解决策略

解决“漏测”问题

第一要紧事情是处理bug，确认影响范围，优先保证用户使用恢复正常；

分析bug漏测原因

1. Bug是需求阶段引入的，需求本身有遗漏/描述不清楚，主要是产品人员的责任，但是设产品、开发、测试人员没有评审出问题，同样也有责任；
2. Bug是开发阶段引入的，测试人员设计用例的时候没有考虑到，是测试人员的责任，但是测试用例同样是要经过开发、产品的评审才会使用的；
3. bug同样是开发阶段引入的，由于开发修改bug的时候引入了新的bug，恰好那个用例之前测试过，不会再重新测试了，遗漏主要责任就在开发，修改bug控制影响范围是开发必须做到的，但是测试人员也没有做到代码看护的工作；
4. 产品人员变更需求后，只是告诉开发要改，没有同步给测试，造成测试漏测，这就是项目研发流程有问题了，项目经理要负主要责任；

如何避免再次“漏测”

• 规范工作流程，制定标准。可以主动推动项目团队就项目工作流程认知达成一致，明确项目排期，严格按照项目计划时间进行。
• 规范测试计划，做好PlanB。计划要明确测试范围、测试方法，以及准入准出标准；同时要考虑项目过程中的可能风险问题，做好PlanB。
• 统一用例编写规范，选好回归用例。可以统一团队用例编写标准，明确优先级并得到项目团队的认可。P0优先级的用例可用于回归测试，确保功能可用（一般影响功能正常使用的均为P0）。
• 严格执行用例、拒绝模糊验收。将用例上传至同一平台进行管理，执行时直接在平台做好记录，避免执行过程中遗漏或者测试人员“偷懒”导致执行不完全。而且执行失败的用例可跟bug关联起来，最终输出报告。
• 拒接口头需求，拒提口头Bug。所有工作对接需要有文字形式的记录，包括提测、提bug、上线通知。
• 此外，测试还可以推动一下项目上线策略的制定，例如：可推动灰度发布策略，明确灰度范围，可选一些容忍度较好的客户群加入灰度名单，上线前先进行灰度试用，若规定时间内有异常，随时回滚修复；若规定时间无异常问题上报，即可全量推送​​​