本文来源于 DevOps 的线上 MeetUp 演讲。
首先，关于什么是持续测试，个人的理解是：贯穿整个研发周期，不断验证和反馈的测试活动。至于形式是手动还是自动化，并不是那么重要。
基于场景和探索性的测试，完全可以持续进行，我们要自动化的部分主要是那些重复性的工作。
而自动化测试一定是可持续的么？也并不一定，不稳定的业务及复杂的测试数据构造，依然困扰着大部分团队（关于自动化的问题，可以参考我的另一个文章：从团队的角度理解自动化）。
所以，持续测试的形式并不是那么重要，重要的是能够得到持续的反馈。
我们为什么进行持续测试呢？原来传统的测试模式存在什么问题？在传统的测试环节中，测试人员关注的是功能需求，以完善的功能需求说明书（虽然也不一定有）为依据，验证软件的有效性验证。而在当下的敏捷测试大环境下，测试的职能已经发生了一定的变化。需要我们做到快速、持续的价值验证，并快速给出反馈。
那么我们如何落地持续测试呢，我分成了两部分的能力来解释：业务能力层面和工程能力层面。针对研发活动中的主要环节，进行了测试左移和右移，以达到快速验证和反馈的目标。
需求，是测试活动基线，是我们判定缺陷的根本。在当下的 VUCA 时代，对于需求的理解充满了不确定性（有些需求我们看起来很奇葩，但就是有人买单，也许是我们不懂新一代的年轻人？）。我们需要有效的对齐产、研、测三者对需求理解，定义好什么是 “完成需求”。所以，我会在需求分析阶段，引入 AC（Acceptance Criteria）。通过 Given-When-Then 模式来定义什么是 “需求完成了”（这种形式并没有严格执行，形式并不重要）。以避免由于认知不统一引发的返工风险。后续更高级的玩法，是需求实例化。
开发提测试的版本质量不好？那就让他们先自测吧。单元测试是不可能的（现实就这样，希望能有所改善）。所以需要测试人员在开发转测时，提供核心功能的测试用例，让开发人员自测并完成 ShowCase，尽可能地保障转测质量。
如果前面的环节做得比较好，结合工程能力的各项自动化测试（后续会提到），在功能测试阶段，通过合理的测试策略设计，进行针对性的测试，就可以较好的覆盖当前版本的需求，然后花较多的时间在探索性测试及 UE 测试上。这里有个比较核心的问题，就是功能测试用例写到什么程度？测试用例是一定存在的（因为测试用例的本质是约束人性的自由，防止漏执行），用例的形式并不重要。团队能接受，大家看得懂就可以。这也是一种团队资产。
现在的互联网产品基本上都处于过剩的状态，每一个品类都有大量的同质化产品。如何让自家的产品更具有竞争力？我们需要更清楚的去了解用户的使用场景和真实痛点（烧钱补贴是另一种方式）。在这点上，对于 To B 的产品，我们会和产品经理一起下放到业务团队当中去，看用户如何操作，收集真实的痛点。
对于测试人员的工程能力，现在的要求越来越高了。不懂代码的测试人员终将生存艰难（可以抬杠，不接受反驳）。但是懂代码的人测试人员并不一定是测试开发人员（可参考：你对测试开发是否有误解）。
当测试人员有一定的代码能力后，就可以尝试做一些 TDD 的工程实践，例如基于 JUnit 的测试代码编写，利用 Spring Cloud 自带的 @ RunWith 注解基于 Controller 层的测试等等。这里区别于单元测试的点在于，我们更关注的是接口层的调用。做得更好的，可以基于 SOA，封装好不同类型的切面测试，让测试活动自然而然的发生。这类测试的好处在于，可以直接集成到开发库中，进行统一的管理。当我们的分支发生变化时，测试用例自然而然地也跟着切换，非常方便。
在自动化测试环节，也是当下测试人员最关注的场景，有非常多的工具可以帮助我们进行有效的自动化测试（更多的时候指的是接口自动化）。在这里就不展开了，可以看下 PPT 上的信息。对这块有了解的同学基本上都能找到相关的工具。在这里主要提两点：
一是所有自动化的前提是标准化。如果不能标准化而强推自动化，个人是非常不推荐的（比如经常有人在群里问的，如何通过抓包进行接口自动化测试。你想想，你连接口信息都要自己去抓，而不是开发提供，那接口变了你怎么办？再抓一次包？那怎么可能自动化地起来。）
二是要想清楚做自动化的目标是什么？因为不同的目标带来的策略是不一样的。盲目的自动化测试带来的结果只能是存在于 PPT 上，汇报时用一下。
对于发布的生产上的包，我们如何能保证就是我们测试过的版本呢？开发上线前私自带货的情况经常发生。我们是否做到了 “一次编译，多次部署”？（业内主流的方案已经非常成熟了）。如果没有，你怎么敢说发布的内容就是你测试过的内容？
对于已经发布到生产的功能点，我们如何确认真的是有用户在使用了？使用的频率是否增加了？如果我们发布了一个新功能，它的点击量远没达到预期，那么我们是否还需要持续优化这个功能？我们是否做到了发布价值？这些都可以通过数据埋点的方式得到用户的真实数据，为我们指导后续的产品路线图，或者 PBL 的优先级排序。
以上，我们对研发过程中的核心流程的持续测试做了相关的介绍。测试的同学做了很多左移和右移的事，但这并不表示我们可以在别人的领域指手画脚。“不是用你的业余去挑战别人的职业，而是通过自己的能力和经验，让别人做得更好 “。我们的角色是协助，而不是决定。例如，对于某个需求的价值，有很多前置条件我们是不清楚的（信息差随时存在），所以，我们不能直接判断这个需求的价值有多大，我们能做的是去理解这个需求的完成标准是什么，是否会影响现在的业务，影响面有多大。提前预警，提出风险，才是我们应该做的事。右移也是同样的道理。
关注反馈的价值，让每次的反馈都能促进质量的提升。减少因为理解误差带来的风险和返工。同时，通过及时地反馈，来保证研发进度，让全体成员知道项目的风险和进展，适时调整需求的优先级。不要全体进度的 90%，而需要可交付价值的 100%。
反馈并不一定会带来提升，在这中间还缺一个东西，就是改进清单。没有改进的反馈，很容易让反馈者疲劳，直到不反馈。忙碌的团队原地打转，优秀的团队螺旋提升，不管是团队还是个人，都需要阶段性地停下来，发现问题并解决问题，持续改进。敏捷当中的回顾会其实是非常重要的活动，但往往这个会都会流于形式，有机会可以细聊。
最后做个总结，之所以测试的活动会发生如此大的变化，理论上是因为大家对于测试的认知发生了变化。原先，我们对测试的理解是验证质量，发现问题。但现在，我们都在强调质量内建，我们需要构建质量，预防问题。因为，我们不生产问题。
原文连接：https://mp.weixin.qq.com/s/mADVauTn7GKXv_uD4Sk_uw
