遗漏Bug之后你会怎么办？（下）

草帽路飞UU

三、对于开发角度侧思考

　　3.1  自测背景

　　开发人员做好自测，非常必要，也是大趋势。前期都是开发自测，后期才是用户体验方面的测试。从成本和时间上分析，Bug越晚发现修复成本越高；从修改的效率来讲，越早处理会越快。一个优秀的开

发者，自测的Bug一定会多于测试发现的Bug，也就是轮到测试的时候Bug数量相当少。

　　3.2  疑难问题思考

　　·时间和进度太紧张，排期紧凑。

　　· 对自己代码过于自信，自认为有很强的健壮性，不忍心去修改。

　　· 认为这是测试的责任，多度依赖测试。

　　· 不知如何有效的做好自测，覆盖全面。

　　· 开发冒烟测试对于QA创建指定的用例理解不透彻，执行简约。


　　3.3  思维转变

　　· 代码质量、项目质量均是我们的责任。

　　· 测试和开发人员思考问题不同，开发是在制造软件，测试是在破坏软件，想办法去找出问题。

　　· 任何功能都有正常场景和异常场景，多数使用等价类和边界值去选择数据，覆盖全面。

　　· 不要相信任何开发的代码是无Bug。

　　· 走出具体实现时用的开发思维，站在需求和用户的角度去自测是否通过，假如自己是用户去测试你的功能。

　　3.4  不仔细认真自测带来的痛处和隐患

　　需求遗漏：一旦被用户发现此问题，用户印象会大打折扣，可能直接从开始使用即放弃使用，将带来非常大的客户流失。

　　功能事故：主流程功能没有测试到位，或者异常场景没有测试到位，导致线上频繁报错，体验极度不好，直接认为就是事故。

　　需求延期上线：如果自测不充分，测试花大量的时间去沟通低等级bug，甚至主流程走不下去，这样无疑会给开发带来返工、重复测试、耗时、需求延期、项目延期等一系列问题。

　　3.5  制定自测报告规范

　　功能模块介绍及背景介绍

　　· 功能、背景介绍

　　· 使用用户群体介绍

　　环境信息

　　· 版本号

　　· Hosts、代码发布分支

　　· 预发or正式

　　· 功能设计文档以及UI设计图等

　　· 数据库数据同步、环境配置、开关设定等

　　梳理好的自测点

　　· 编写代码时候记录的业务点和测试点

　　· 需求变更的自测点

　　· 正向、逆向、异常场景测试点

　　· 兼容性

　　· 开发此功能是否会对其他功能造成影响，一行代码是否会引发新的问题出现

　　自测实际结果：

　　· 高等级Bug数量、影响冒烟核心流程

　　· 中等级Bug数量、串联流程链路

　　· 低等级Bug数量、页面展示UI效果

　　· 开发冒烟自测阶段覆盖率

　　· 一轮、集成阶段覆盖率

　　期望结果：

　　· 符合测试SOP规定准出标准

　　· 冒烟自测以及集成阶段覆盖率标准

　　· 测试阶段Bug数量的控制

　　· 上线后Bug数量的控制，质量月复盘满足数量控制标准

　　四、总结

　　缺陷漏测发生后我们需要深入分析漏测的Bug，思考哪方面做的不够，是业务逻辑理解误差？用例评测遗漏？技术方案存在不合理？思考设计用例方向出现了偏差？多问一些几个为什么，换位思考角度想

问题，合理设计评测。确保类似的Bug能被预防提前发现暴露出来，从而尽可能的降低缺陷的产生，提高产品质量。在每个不同阶段做好用例测试计划执行，增加精细化测试以及探索性测试环节，需要开拓新

的测试思想思维，走出惯用常规的测试思想。同时也要站在开发侧、编写代码设计的思维逻辑去考虑，降低可能在测试阶段出现Bug漏测、遗漏的出现，开发侧也需严格执行自测和覆盖率SOP要求准出。

oliver.tang

复盘，记录