持续测试持续反馈

周辰晨

发布于 2021-12-27 18:53:27

6070

发布于 2021-12-27 18:53:27

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

--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. 总结--

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

--现场同学的提问--

Q1：测试覆盖率的怎么计算？

这个问题本身比较抽象，因为没有问清楚是什么的测试覆盖率。常见的覆盖率类型有以下几种：

测试执行覆盖率：执行的用例/总的用例数；

需求测试覆盖率：有用例的需求/总的需求数；

自动化测试覆盖率：一般情况下指的是接口的自动化覆盖率，有自动化测试例的接口数/总接口数；

代码覆盖率：现在大家在谈论的比较多的，指的是这个类覆盖率，指的是测试执行完成后，覆盖了哪些代码行。

Q2：代码覆盖率怎么算的？

这个目前业内有比较成熟的方案来实践这种能力了，Jacoco、coverage等工具都可以实现。核心原理是通过插桩操作，记录每次手工执行测试时运行的代码函数，统计哪些代码被执行到，哪些没有。统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。但这类统计也有它的局限性，首先，它是基于现有代码的，并不能发现那些“未考虑某些输入”以及“未处理某些情况”形成的缺陷，也就是开发没有实现的功能缺陷。其次，我们不能过分的追求这个指标，盲目追求高代码覆盖率指标，所需要的成本过大，也容易出现为了测试而测试。

Q3：团队如何引入自动化测试？

参考：从团队的角度理解自动化

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