问题分析与规避

线上bug率是项目质量的衡量标准，线上漏测bug是如何产生，又该如何规避呢。

通常我们都会做一个CaseStudy，在团队内进行缺陷分析和学习。

 

CaseStudy需要包含的元素：bug描叙、事故时间线、原因分析、解决方法、经验教训、Todo

日常必填的分析指标：漏测bug分类、漏测bug等级、漏测原因、发现人、发现时间、定位时间、解决时间、是否已知问题

每个元素和指标都很值得深入分析。

 

漏测原因

测试用例没覆盖	原因：测试进行用例设计时，未考虑到该测试场景 措施：1、补充该测试用例，加强日常用例设计评审，输出评审记录。 2、整理测试用例集，每次发布和漏测都要及时更新用例，以做参考和规避。
测试用例覆盖，执行不到位	原因：测试用例覆盖到位，在测试执行过程执行步骤有问题或没有执行 措施：规范测试用例编写格式，描叙清楚操作步骤，用例关联执行，标识执行结果。
测试用例覆盖，环境问题未执行	原因：测试环境与真实环境的差异，无法验证功能的完整过程，比如每日统计转账记录 措施：1、尽可能保证测试环境和真实环境的服务器，数据库等配置一致。2、灰度验证
测试用例覆盖，无真实数据验证	原因：和环境问题有些类似，依赖服务不稳定或无指定环境，无法进行反馈，比如短信验证码、授权 措施：1、灰度验证 2、外部依赖服务可mock模仿验证。
回归策略问题	原因：开发修复bug+代码优化，产品改需求，在测试回归验证后，频繁改动，无法保证改动范围 措施：1、约定封板时间，回归测试后的改动需要审核，review改动代码评估影响范围。 2、验证bug后需要再回归改动范围的功能。
开发修复bug新引入	原因：在时间比较紧凑，临时需要紧急修复bug，或未经过完整验证过程 措施：1、在做bug修复前，需要定位bug原因，以及评估改动的影响范围，降低影响面。 2、开发B进行code review，merge经过审核。3、事后还是需要进行完整的回归验证。
开发改动未提交测试	原因：悄悄做了代码优化，或bugfix 措施：1、beta环境加入自动化ci，代码改动部署触发各种检查，并且通知测试。 2、上线环节加入测试审核流程，保证每次上线测试都能收到通知。
已知问题，需求未定义	原因：需求没有定义的场景 措施：需求评审阶段、测试用例审核阶段，提前暴露问题，避免测试过程才发现，带问题上线。 需要落地一个临时的解决方案。