测试人社区

测试开发实战|高效测试 | 如何完成被拆解的任务?

前提

  • 最重要的一个前提:任务被拆解前,需求是明确的。
  • 什么样的需求是明确的需求呢?这是一个不小的问题。有一个很好的验证方法:这个需求是否可以写出来代入数据和步骤的测试用例。强烈推荐《实例化需求》这种实践方式,这是一个大话题,需要单独来说。
  • 确保工作量是可完成的,而不是 overload 的。对于团队生产力的估算能力,提高的最好的方法就是不断的总结上一个迭代产出了什么。
  • 越忙的时候,越要保证这两个前提,因为它本质上可以帮助你提升效率。

分工 & 步骤

  • 拆解的时候一定考虑可测性。在初期,QA 一定要与开发就可测性达成统一认知。
  • 任务分解后,除了开发,需要并行开展的工作是:测试案例编写。最好的实践方法是《实例化需求》方法,骨架的验收测试用例在开发前就作为需求 Ready 了。
  • 如果没有采取《实例化需求》,则应该马上开始发起测试案例编写工作,保证在 " 提测 " 之前,骨架测试案例是具备的。
  • 案例应该分级,如 P0,P1,P2。P0 是冒烟测试,P1 覆盖最核心,一定要保证的功能。P2. 是优先级略低的案例。
  • 开发应该充分利用上条提到的测试案例,最低要求是 P0 一定要全部通过,一个比较理想的状态是 P1 全部通过。
  • 案例自动化能够同期开发是最好的。在 “提测” 的时候,所有测试案例都是自动化案例的话,测试执行就会变得非常快,通常一日内可以搞定,提测的轮次会大幅度减少,大概率会一轮过,因为在自动化案例开发和调试的同时,就已经在做测试了。而 QA 可以花时间来做更多的异常情况的思考和探索性测试,发现隐藏的很深的问题。

技术上的难点

  • 如果是主干开发的分支策略,feature 之间的解耦是至关重要的。feature 开关是开发中必不可少的东西。
  • 任何一个新 feature,在开发完成前, 默认是关闭的 。这样可以保证合入代码不影响他人的工作,不影响主干的发布能力。
  • feature 开关不能解决所有问题,但如果设计很好,feature 开关可以解决绝大部分问题。仍然有其它方法可以解决 feature 开关解决不了的问题,如代理层,如抽象分支(branch by abstraction)等。
  • 同期自动化建设是非常难的事情。可以逐步实现,对应的 tips 如下:
    • 自动化一定是分层的, 测试金字塔 的理论是这么多年来,测试界被极少被证实了的极为正确的理论之一。
    • 单元测试作为最底层,一定要做到同期建设,这是最基本的要求。如果达不到这个要求,则很难在并行开发的模式下快起来。
    • 单元测试说着容易,但是全研发级别变为标准十分的难。特别在国内的大环境下,转型需要非常多的努力。
    • 接口层面的自动化建设,应该有完备的工具链来大幅度缩减实施时间。接口自动化最花时间的三样东西:1. mock 的编写。2. 入参的编写。3.assert 的编写。
    • 目前来看,录制回放类工具是最能提效的,它可以大幅度降低这三部分的成本。并且可以把开发调试阶段的成果记录下来变成自动化用例。很可惜的是,市面上完备的通用工具很少,只在大厂有相对成熟的应用。举个例子,在 Java 的 Server 端技术栈,目前开源的 JVM-sandbox-repeater 是一个不错的脚手架,可以在它的基础上做二次开发(大量的二次开发)实现。
    • 在有好工具支撑的基础上,接口自动化案例的建设,QA 和开发的良好协作是基础。没有好的协作,有工具也不行。
    • 端到端的自动化案例也推荐录制回放工具,分层 mock,各司其职,并且保证稳定性。
      为了保证代码质量, CR 是重中之重 ,必须做好。
    • CI 流水线也需要比较完善。一个明显的检查点是:1. 是否有有效的静态代码和单元测试卡点。2. 接口自动化是不是也放到标准 CI 流程里面去了。

收益

  • 真正做到了,系统测试会非常快(一天内)。
  • 基本上具备了每天发版的能力(这可以看成一个比较高的目标) 。