持续测试持续反馈

对于持续测试这个话题，最近也比较火，大家都有不同的实践和认知。所以借这个机会和大家分享一下我的看法。也感谢当时线上听讲的小伙伴们。本文主要针对议题内容做一个整体的回顾，若有疑问，欢迎私聊。

–1. 什么是持续测试–

首先，关于什么是持续测试，个人的理解是：贯穿整个研发周期，不断验证和反馈的测试活动。至于形式是手动还是自动化，并不是那么重要。基于场景和探索性的测试，完全可以持续进行，我们要自动化的部分主要是那些重复性的工作。而自动化测试一定是可持续的么？也并不一定，不稳定的业务及复杂的测试数据构造，依然困扰着大部分团队（关于自动化的问题，可以参考我的另一个文章：从团队的角度理解自动化）。所以，持续测试的形式并不是那么重要，重要的是能够得到持续的反馈。

–2. 为什么要做持续测试–

我们为什么进行持续测试呢？原来传统的测试模式存在什么问题？在传统的测试环节中，测试人员关注的是功能需求，以完善的功能需求说明书（虽然也不一定有）为依据，验证软件的有效性验证。而在当下的敏捷测试大环境下，测试的职能已经发生了一定的变化。需要我们做到快速、持续的价值验证，并快速给出反馈。

–3. 持续测试实践–

那么我们如何落地持续测试呢，我分成了两部分的能力来解释：业务能力层面和工程能力层面。针对研发活动中的主要环节，进行了测试左移和右移，以达到快速验证和反馈的目标。

–3.1 业务侧能力实践：DOD活动–

需求，是测试活动基线，是我们判定缺陷的根本。在当下的VUCA时代，对于需求的理解充满了不确定性（有些需求我们看起来很奇葩，但就是有人买单，也许是我们不懂新一代的年轻人？）。我们需要有效的对齐产、研、测三者对需求理解，定义好什么是“完成需求”。所以，我会在需求分析阶段，引入DOD的活动（Definition of Done “完成的定义”。理论上这个事应该由产品来完成的）。通过Given-When-Then模式来定义什么是“需求完成了”（这种形式并没有严格执行，形式并不重要）。以避免由于认知不统一引发的返工风险。后续更高级的玩法，是需求实例化。

–3.2 业务侧能力实践：冒烟测试用例–

开发提测试的版本质量不好？那就让他们先自测吧。单元测试是不可能的（现实就这样，希望能有所改善）。所以需要测试人员在开发转测时，提供核心功能的测试用例，让开发人员自测并完成ShowCase，尽可能地保障转测质量。

–3.3 业务侧能力实践：功能测试–

如果前面的环节做得比较好，结合工程能力的各项自动化测试（后续会提到），在功能测试阶段，通过合理的测试策略设计，进行针对性的测试，就可以较好的覆盖当前版本的需求，然后花较多的时间在探索性测试及UE测试上。这里有个比较核心的问题，就是功能测试用例写到什么程度？测试用例是一定存在的（因为测试用例的本质是约束人性的自由，防止漏执行），用例的形式并不重要。团队能接受，大家看得懂就可以。这也是一种团队资产。

–3.4 业务侧能力实践：用户行为探索–

现在的互联网产品基本上都处于过剩的状态，每一个品类都有大量的同质化产品。如何让自家的产品更具有竞争力？我们需要更清楚的去了解用户的使用场景和真实痛点（烧钱补贴是另一种方式）。在这点上，对于To B的产品，我们会和产品经理一起下放到业务团队当中去，看用户如何操作，收集真实的痛点。

对于测试人员的工程能力，现在的要求越来越高了。不懂代码的测试人员终将生存艰难（可以抬杠，不接受反驳）。但是懂代码的人测试人员并不一定是测试开发人员（可参考：你对测试开发是否有误解）。

–3.5 工程能力实践：TDD尝试–

当测试人员有一定的代码能力后，就可以尝试做一些TDD的工程实践，例如基于JUnit的测试代码编写，利用Spring Cloud自带的@ RunWith注解基于Controller层的测试等等。这里区别于单元测试的点在于，我们更关注的是接口层的调用。做得更好的，可以基于SOA，封装好不同类型的切面测试，让测试活动自然而然的发生。这类测试的好处在于，可以直接集成到开发库中，进行统一的管理。当我们的分支发生变化时，测试用例自然而然地也跟着切换，非常方便。

–3.6 工程能力实践：各类专项测试–

在自动化测试环节，也是当下测试人员最关注的场景，有非常多的工具可以帮助我们进行有效的自动化测试（更多的时候指的是接口自动化）。在这里就不展开了，可以看下PPT上的信息。对这块有了解的同学基本上都能找到相关的工具。在这里主要提两点：一是所有自动化的前提是标准化。如果不能标准化而强推自动化，个人是非常不推荐的（比如经常有人在群里问的，如何通过抓包进行接口自动化测试。你想想，你连接口信息都要自己去抓，而不是开发提供，那接口变了你怎么办？再抓一次包？那怎么可能自动化地起来。）二是要想清楚做自动化的目标是什么？因为不同的目标带来的策略是不一样的。盲目的自动化测试带来的结果只能是存在于PPT上，汇报时用一下。

–3.7 工程能力实践：线上监控–

对于发布的生产上的包，我们如何能保证就是我们测试过的版本呢？开发上线前私自带货的情况经常发生。我们是否做到了“一次编译，多次部署”？（业内主流的方案已经非常成熟了）。如果没有，你怎么敢说发布的内容就是你测试过的内容？对于已经发布到生产的功能点，我们如何确认真的是有用户在使用了？使用的频率是否增加了？如果我们发布了一个新功能，它的点击量远没达到预期，那么我们是否还需要持续优化这个功能？我们是否做到了发布价值？这些都可以通过数据埋点的方式得到用户的真实数据，为我们指导后续的产品路线图，或者PBL的优先级排序。

以上，我们对研发过程中的核心流程的持续测试做了相关的介绍。测试的同学做了很多左移和右移的事，但这并不表示我们可以在别人的领域指手画脚。“不是用你的业余去挑战别人的职业，而是通过自己的能力和经验，让别人做得更好“。我们的角色是协助，而不是决定。例如，对于某个需求的价值，有很多前置条件我们是不清楚的（信息差随时存在），所以，我们不能直接判断这个需求的价值有多大，我们能做的是去理解这个需求的完成标准是什么，是否会影响现在的业务，影响面有多大。提前预警，提出风险，才是我们应该做的事。右移也是同样的道理。

–4. 持续反馈与提升–

关注反馈的价值，让每次的反馈都能促进质量的提升。减少因为理解误差带来的风险和返工。同时，通过及时地反馈，来保证研发进度，让全体成员知道项目的风险和进展，适时调整需求的优先级。不要全体进度的90%，而需要可交付价值的100%。

反馈并不一定会带来提升，在这中间还缺一个东西，就是改进清单。没有改进的反馈，很容易让反馈者疲劳，直到不反馈。忙碌的团队原地打转，优秀的团队螺旋提升，不管是团队还是个人，都需要阶段性地停下来，发现问题并解决问题，持续改进。敏捷当中的回顾会其实是非常重要的活动，但往往这个会都会流于形式，有机会可以细聊。

–5. 总结–

最后做个总结，之所以测试的活动会发生如此大的变化，理论上是因为大家对于测试的认知发生了变化。原先，我们对测试的理解是验证质量，发现问题。但现在，我们都在强调质量内建，我们需要构建质量，预防问题。因为，我们不生产问题。

最后的最后，分享一段朱少民老师提出的，关于软件测试的底层逻辑：尽早尽快地获取必要的质量信息、揭示质量风险。为此，延伸出来的软件测试底层逻辑有：

• 贯穿整个研发周期，形成闭环，并持续改进测试流程
• 基于风险的测试策略是必不可少的
• 以终为始、系统地分析测试需求，在资源和测试目标之间寻求平衡
• 测试设计是艺术，更要创新、融合
• 在分析和设计的基础上，尽可能地实现自动化测试
• 讲好测试故事，和各方一致、协同工作

PPT获取方式：