目录
业界/团队内部普遍已经有的共识
- bug的预防/避免 优先于 bug的发现；
- BUG越早发现的越好
- bug给之后上线带来不同程度的风险
- bug尽可能扼杀在上线之前，不然上线后很可能带来线上问题
总之：BUG越早发现的越好，为了证明这个论点，还可以从不同时期bug修复代价入手。
业界几种评估不同时期bug修复代价的方法
一、修复的时间
开发人员自测/前后端联调时发现(30s~5min)
开发人员逻辑思维思维严谨，异常处理得当，测试时通过(30s~5min)
测试人员测试、反复重现并尽可能确定bug的场景，还要 抓日志并填写流程（5~20min）
开发人员根据提出的bug：
理解bug(30s~2min)
修复问题(5min)
重新发布(2~20min)
测试人员测试(1~5min)
不太顺利的情况下，增加的时间：
开发人员重现不了bug，拉QA一起重新复现一遍（创造某种特定场景，问题演示、日志抓取，接口返回等）(2~10min)
开发人员怀疑是操作步骤不对、环境不对等等原因，让QA重新操作几次/重置环境后重试(比如重新下载测试APP后重试)
bugfix后，QA重新验证后，发现问题仍然存在(重复上述过程)；
bugfix时，不小心引入了新的问题(重复上述过程)
二、修复时测试的次数
一轮测试中：
测试的次数越多，QA时间越紧迫，越疲劳
开发人员自测/前后端联调时发现(1次~2次)
开发人员逻辑思维思维严谨，异常处理得当，测试时通过(2次)
测试人员测试、反复重现并尽可能确定bug的场景，还要 抓日志并填写流程（0~2次，为了截图、拦截日志，重新复现问题）
开发人员根据提出的bug：
理解bug(0~1次)
修复问题(1次)
重新发布(0次)
测试人员测试(2次~5次)
不太顺利的情况下，增加的时间：
开发人员重现不了bug，拉QA一起重新复现一遍（创造某种特定场景，问题演示、日志抓取，接口返回等）(1~2次)
开发人员怀疑是操作步骤不对、环境不对等等原因，让QA重新操作几次/重置环境后重试(比如重新下载测试APP后重试)(1~4次)
bugfix后，QA重新验证后，发现问题仍然存在(重复上述过程)；
bugfix时，不小心引入了新的问题(重复上述过程)
三、修复花费的费用
《Google如何测试软件 —— 帮我像Google一样测试》
下面的数据是Google提供的样例成本,表示的是在不同的测试阶段发现bug并进行修复所需要的成本。这些数据清楚地说明:在开发过程中越早发现问题,修复这些问题所耗费的成本越低。
ps: 下一个阶段修复的代价是上一个阶段修复代价的10倍
四、修复对上线的风险
一般来说，除非重大问题会推迟上线，一般虽然线下会发现大量bug，尽管风险会不同程度存在，但一般都会如期上线。
这里暗含的意思有：
虽然明知道线下质量不是太高(这个可以通过线下的bug数量和严重级别看出来)，但90%+仍然会带着风险上线；
带着风险是指：由于线下问题太多，QA疲惫的忙于各种测试，回归，验收；越忙时间越短可能思路越短缺，极容易遗漏“显而易见”的问题。
bug暴露的方法探讨
ps: bug的预防方法众多，不同的业务也有不同的具体实施步骤，这里不做逐一介绍了。这里仅就bug暴露方面说一下自己的思考和经验吧。
- 相比模块/集成测试，代码review和单元测试更容易发现某些类型的问题
实际的例子：
回归场景-某个底层方法的修改，例如：影响了登录的用户账号，这种情况在实际的项目操作中，开发人员往往说自己修改了什么方法，影响了XXX登录，需要回归下；这时QA人员也会尽可能全面回归，但仍然有遗漏。
做法需要重新回到更全面的需要上来，比如当时要求用户账号必须是什么格式，有无特殊字符，具体的限制是什么？
经验参考： 根据业务具体特点，发现这类的典型测试场景，通过代码review和单元测试进行覆盖
- 不要把bug暴露压力完全放在QA肩膀上
实际的例子：
一次故障复盘会议上，大家针对为什么测试没有发现，对QA“开撕”；或者针对代码为什么这么实现，对开发“开撕”
经验参考：总和综合考虑不同测试深度和广度需要，将产品人员、开发人员、团队其他成员拉进来，一起进行bug暴露。因为任何人都可能犯错/遗漏，如果bug暴露仅仅是QA的话，势必不会100%保证bug的充分暴露了。
总结
通过计算不同时间段，修复问题的代价？ 成本？，并将此同步给团队其他成员，可以在团队内部，达到更好的对质量保证、bug暴露的共识和支持。反观项目每次迭代中的bug分布，bug数量，根源分布等等手段，并将此同步给团队其他成员，从而让QA的工作增加更多的认同。