研发效能 如何完成一个被拆解的任务?

刘晓光 · March 25, 2020 · Last by 恒温 replied at March 31, 2020 · Last modified by admin simple · 1028 hits

如何完成一个被拆解的任务?

前提

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

分工&步骤

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

技术上的难点

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

收益

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

顶一下,科学拆解任务还是比较难的

难,我们是做金融的,链路特别长,有一次mock事故就是上游mock了下游返回,下游mock了上游传入,两边都认为自己没问题,等到灰度时才发现对不上,实际就已经晚了

要做全链路测试呀。

拆解这个工作是从需求开始,然后开发执行,好的流水线只能保证流水线本身。开发对规则的遵守,才有作用。还有一个就是要增加进入sit之后,修改代码的成本。

肯定要有系统集成测试。
另一个需要注意的点就是:测试设计的时候,要对mock的等效性进行分析。
最好的办法是:跨系统的接口调用,在一开始就有明确的定义,而不是等到联调的时候再考虑细节(这是一种特别lowB,但很多团队一直在做的事情)

刘晓光 回复

跨系统的接口调用,在一开始就有明确的定义,而不是等到联调的时候再考虑细节(这是一种特别lowB,但很多团队一直在做的事情)

这个系分的时候确定吧。一般在开发联调阶段也会出现问题。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up