最近做研发质量分析，大家共同提到了一个改进措施：加强开发自测！
但是如何加强开发自测、怎么做好开发自测？带着这个问题，进入我们今天的分享：
一、开发测试小记
开发同学功能开发完成后，简单自测通过后，填写提交单提交测试，然后：
制作的补丁，打到测试环境，发现丢了一些SQL、Dll、配置，然后提交单被测试无情地打回。
即便补丁更新成功，扛不住测试用例的第一轮饱和测试，出现影响测试进展的Bug，或者Bug太多，满足打回标准，提交单继续被无情打回。
提交单打回后，开发同学集中修复了Bug，再次提交测试。正常情况下，第二轮功能测试发现的Bug会大幅减少，如果重新提交的补丁质量不佳，修复Bug的同时，带来了更多新的Bug，提交单还是有可能继续被打回。
功能测试通过后，进行性能测试，并发压力上来后，功能被打爆、数据库被打爆、MQ被打爆，提交单再次被打回。
……
上面的场景，大家都很熟悉，很多开发、测试同学通过都经历过。我们如何用真正的行动来加强开发自测，提升交付质量？我们需要有一套开发自测方法论：
二、开发自测方法论
我们详细展开讲一下：
1. 思想意识上，提升对自测的重视程度
- 开发阶段不仅是代码开发完成，编译通过，更重要的是自测通过。
- 自测工作投入应该占开发阶段整体投入的30%，如果保证不了资源投入，自测只是一个形式；
- 自测工作必须覆盖全面的自测场景：正向、逆向、正常、异常、并发性能等等；
- 自测是开发阶段最重要的一环，如果不重视自测，测试阶段可能会产生大量的Bug、提交单被打回、直接影响研发进度。
- 自测直接决定了产品的质量。
2. 自测的PDCA之-Plan计划
开发阶段，要加强自测工作的详细规划和资源投入：
这里我们用的Scrum 迭代研发，以下是自测任务计划情况：
自测工作在迭代拆分计划时，要尽可能的覆盖环境搭建、单元测试、联调测试等工作，并合理估计投入时间。
同时具备完整的自测表，功能覆盖度尽可能全。
3. 自测的PDCA之-Do执行
自测环境搭建：本机自测环境、Docker联调环境
单元测试：保证核心方法、接口、场景都能覆盖到，必须有完整的断言。主要包含：
- 测试数据准备、准备Mock方法
- 主流程正向测试
- 主流程逆向测试
- 详细功能-正常场景测试
- 详细功能-异常场景测试
- 并发性能测试
- 测试数据清理
接口自动化测试：基于接口自动化测试工具，实现接口的自动化测试
集成测试：补丁更新后全面功能测试，前后端联调，保证自测功能表上所有功能都能自测通过。
同时，自测尽可能的保证自动化、可重复执行！
3. 自测的PDCA之-Check评估
如何评估、衡量自测的质量：以关键结果为导向！
测试Bug检出率：
- 通过测试发现的Bug，要低于自测发现的Bug
- 如果测试检出率过高，需要详细做5why分析，为什么自测未发现
单元测试代码覆盖度
- 核心方法是否都通过了单元测试
- 单元测试代码覆盖度
单元测试通过率
- 所有单元测试必须包含完整的断言
- 所有单元测试必须全部测试通过
自测功能覆盖度
- 自测表是否覆盖所有的功能点
- 自测表功能测试全部通过
4. 自测的PDCA之-Act处理、完善
- 完善单元测试：增加核心方法测试覆盖、测试数据覆盖、单元测试场景覆盖
- 增加自测功能覆盖度：覆盖更多自测功能，很多没想到的测试点，增加到自测功能点中
- 增加资源投入和工作规划：通过实际评估，合理加大自测资源投入和工作规划
- 结对测试：自己开发的功能很多Bug可能测试不出来，结对测试，可以发现更多的Bug
- 功能演示&Review：以用户的视角、需求的视角，Review已实现的功能，发现更多的Bug，完善到自测场景中。
其实还有很多其他的方法和讨论来提升开发自测，同时提升自测的质量是一个不断完善和改进的过程！
以上是近期做开发自测的总结，欢迎大家继续补充。
周国庆
2019/10/15