如何做好开发自测

  最近做研发质量分析，大家共同提到了一个改进措施：加强开发自测！

  但是如何加强开发自测、怎么做好开发自测？带着这个问题，进入我们今天的分享：

一、开发测试小记

  开发同学功能开发完成后，简单自测通过后，填写提交单提交测试，然后：

  制作的补丁，打到测试环境，发现丢了一些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