三、对于开发角度侧思考
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要求准出。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
