如何作好开发自测

  最近作研发质量分析，你们共同提到了一个改进措施：增强开发自测！

  可是如何增强开发自测、怎么作好开发自测？带着这个问题，进入咱们今天的分享：

1、开发测试小记

  开发同窗功能开发完成后，简单自测经过后，填写提交单提交测试，而后：

  制做的补丁，打到测试环境，发现丢了一些SQL、Dll、配置，而后提交单被测试无情地打回。   

  即使补丁更新成功，扛不住测试用例的第一轮饱和测试，出现影响测试进展的Bug，或者Bug太多，知足打回标准，提交单继续被无情打回。

  提交单打回后，开发同窗集中修复了Bug，再次提交测试。正常状况下，第二轮功能测试发现的Bug会大幅减小，若是从新提交的补丁质量不佳，修复Bug的同时，带来了更多新的Bug，提交单仍是有可能继续被打回。

  功能测试经过后，进行性能测试，并发压力上来后，功能被打爆、数据库被打爆、MQ被打爆，提交单再次被打回。 

     ……

  上面的场景，你们都很熟悉，不少开发、测试同窗经过都经历过。咱们如何用真正的行动来增强开发自测，提高交付质量？咱们须要有一套开发自测方法论：

2、开发自测方法论

 

  

 咱们详细展开讲一下：

   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