这是鼎叔的第九十六篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

如果在测试部门只能推行一个技术建设项目,那鼎叔就会选择 “持续测试”。

持续测试(Continuous Test,CT),也有公司称为每日测试(Daily Test),就是每天都有新版本生成并完成相应的测试活动,绝大部分测试都是自动化测试,但是也可以推送新生成的安装包到成员的终端上进行人工 dogfood(内部探索测试)。尽可能在当天就发现是否有基本功能被新代码破坏掉,缩短解决问题的闭环,并让大团队对新代码提交保持信心,这样的实践契合 “频繁测试”、“集体对质量负责” 的敏捷原则。

相关前文:聊聊测试左移到开发阶段 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484498&idx=1&sn=82a4bf3f3680220f89bf12b02924211e&scene=21#wechat_redirect

持续测试的健康度指标

带领团队全力投入持续测试之前,鼎叔会不厌其烦地强调:持续测试不是普通的自动化测试,健康度比覆盖率更重要。

以往测试团队在设立自动化测试目标时,都把重心放在自动化覆盖率上,比如所有测试用例被自动化的比率,或者接口/代码行的覆盖率。只看这一类指标很容易带来临时抱佛脚,有不少 QA 会在考核末期把自动化率提上去,用例没有通过也不去深究原因,整个自动化下来累计发现的问题非常有限。

鼎叔推荐以下几个健康度指标:

1 持续测试卡点失败的恢复时长(MTBF)

持续测试的卡点就像安灯绳,指定的基础功能一失败就应该停下来检查。

为了保障持续测试能顺利开启,团队首先要确保持续构建的成功率,必要时督促开发立刻处理失败,建立对健康构建的重视态度比完善工具更重要。

有一部分不太稳定的,优先级也不高的持续测试用例集可以不设置卡点,或者设置低阈值卡点,以免经常失败导致人员精力的过度耗费。但这种用例集数量应该尽量控制,可以放在员工本地运行,稳定后再放在团队流水线中。

2 测试还需要关注项目的构建和执行速度,通常应在几分钟以内。在实践中发现,导致构建耗时太长的原因经常来自于测试,比如包含了远程服务(如数据库)。

3 度量团队和项目持续测试的前置缺陷发现率,就是持续测试回归自动化过程中累计发现的所有有效问题。这个指标不管用什么自动化框架,不管黑猫白猫,只要发现尽量多的问题就是好猫。

这个指标主要看遗留测试资产(回归自动化)的效果,包括利用各种无需 QA 人工投入的自动化能力,能在人工测试之前拦截多少有效问题。

持续测试人员可以用各种手段客观记录有效缺陷,不一定要录入缺陷管理系统,更多是度量持续测试的产出价值。

持续测试实践的成效是,后期的系统测试阶段发现的缺陷数量大幅下降了。没错,在测试左移中,系统测试中发现的缺陷占比越少,越有可能是件好事。

4 测试用例通过率。有的流水线卡点会设置为 100% 通过,也有设置为 90% 通过的。关键是只要有失败就要快速排查,是脚本问题、产品沟通问题、环境问题,还是缺陷。

通过率的治理可以倒逼 QA 优化用例集,剔除不稳定的,或没想清楚的用例,避免 “用例越多越好” 的误区。

5 测试人员除了参与验收标准和验收用例的评审,还可以在开发完成单个需求(用户故事)自测后,马上开始针对性的验收测试(如果产品经理能先行做用户验收测试则更佳),快速反馈该单个需求的质量情况(最好当天完成),降低迭代版本测试或系统级测试的风险。反馈周期越短,开发修复的效率越高,而传统的等待版本提测模式,会拉长开发的等待时间,加大切换任务的注意力耗费。

持续测试的技术栈

产品和项目质量交付是一个整体,包括客户端/前端,和后端的代码测试与发布。但是从自动化技术层面,客户端和服务端的测试框架和执行速度还是有很大差异。

所以持续测试建设团队需要从两套技术栈去分头建设流水线,一套是客户端,一套是服务端,分头掌握不同的自动化能力,但最终的质量标准和指标看板要整合为一个结果,面向产品的整体来输出。

客户端持续测试流水线

客户端的自动化测试成本在很多时候是高于服务端的,可以借用的行业技术成果也更加的丰富多彩。

一,因为客户端面向用户体验视角,所以具备 AI 图像识别能力的 UI 自动化测试框架有不错的潜力。

二,三端合一测试技术,即用一套脚本在 Android,iOS,PC/Website 上同时完成自动化测试,这是客户端测试的热点,在持续测试中非常有价值潜力。

三,真机集群适配自动化测试,这个将来有机会可以专题分享。不同机型的 APP 适配质量是很多开发团队的噩梦,行业已经有很多针对性的解决方案。因为真机适配 UI 自动化通常速度慢,失败率较高,所以更适合作为非卡点异步任务。

服务端持续测试流水线

服务端持续测试肯定以协议测试/接口测试为主要形式,但是接口测试的框架也是五花八门。对于电商等复杂的线上流量业务,流量录制回放工具占据了越来越重要的比重。持续测试平台可以同时接入流量录制回放型自动化测试框架,和常规的人工创建型自动化测试框架。

持续测试看的是疗效,不追求执行框架越单一越好,只要能显著提升前面的健康指标,引入外部开源的或商业工具都行,甚至友商工具也可以拿来用。

持续测试流水线的分层(五层)

持续测试中的自动化测试是分层进行的,因为不同层次的自动化测试耗费的时间不同,修复成本不同。参考 HamVocke 的测试金字塔理论,自动化测试可以分为下面几个主要层次。

1)静态测试。即静态代码扫描,包括代码普通质量问题和代码安全问题,针对扫描结果,我们会关注扫描出来 Block 问题和 Major 问题,设立修复率目标,推动开发把精力放在前期。

2)单元测试。之前文章已有介绍。

3)接口测试。

4)跨链路测试或集成测试。在很多公司,集成测试被称之为联调测试,通常由开发人员负责,但是测试人员也可以共同建设。

集成测试可以分为狭义集成测试和广义集成测试。狭义集成测试聚焦被测对象的服务边界,触发本对象和外部(另一个服务,或数据库,或文件系统)的集成动作。而广义集成测试则是通过网络和外部服务进行集成,但是速度更慢,测试更脆弱。依托测试环境稳定的基础设施服务,集成测试通常按照从小到大的顺序联调,逐步提高服务的可用性。

从敏捷角度理解,联调意味着跨特性团队的协作,虽然难以避免,但也属于浪费的成本,应该尽可能降低联调的投入和时间。如果参与联调的各方都有非常清晰完备的接口定义,充分考虑了可能的错误场景,那么联调就可以在最短时间完成,甚至借助事先做好的自动化用例全自动完成。

因此,在微服务产品中,契约测试(作为一种特殊的集成测试)就流行开来,所有微服务的接口测试都根据定义好的接口契约,设计完整的稳定的测试用例套件,确保数据的生产者模块和消费者模块遵循契约。基于该套件的每天持续测试把关,研发团队便向自治团队迈出了一大步。

5)UI 测试/端到端测试。注意,UI 测试是端到端测试的一部分,即从交互界面上验证结果。端到端测试还有不少其他层面的验收标准,比如没有界面的功能,系统性能,安全性检查,日志正确性,交付规范的文档等。对于微服务架构的产品,需要有人面向整个系统,跨越多个服务来编写端到端测试用例。

这些自动化测试层次使用的测试框架各不相同,但持续集成平台都可以纳入,并行执行,根据团队的效能度量要求进行任务配置和结果治理。

哪怕不完美的自动化测试,只要能够频繁执行,也比很少执行的完美测试更有价值。

而前文提到的验收测试,和测试金字塔的各个层次是正交的,你可以依托单元测试来验收,也可以从接口验收,当然也可以在 UI 层验收。

如果一个功能验收可以同时在低层次和高层次自动化实现,那就应该保留低层次测试用例,而放弃高层次用例,以减少用例重复。但是,如果高层次的用例能够提高我们对于产品发布的信心,那就应该保留它。

这也就是我认为,单元测试及集成测试,不太可能完全替代端到端测试的原因。

持续测试与测试右移

持续测试贯穿产品研发生命周期,它的价值不仅限于左边,也适用于右边的质量活动。

持续测试就是要把前期积攒的测试资产在灰度、发布、上线后反复利用,测试框架设施不变,收益最大化。

具体实践可以包括:

埋点验证自动化测试。产品的关键指标埋点是一类对产品发展很重要的功能,除了在常规测试中验证,也可以在预发环境和线上环境进行测试和监控。

线上巡检自动化。出于商业目标的保障(如重大营销时期的价格风险检查),线上的关键页面处于不断变化中,老板对此关注力度大,甚至还需要和竞品对比,这就不是简单的指标监控就能保障的。测试自动化可以梳理出 UI 层面巡检的场景和脚本,把它拓展到正式环境进行采样巡检。

业务逻辑拨测。普通的接口可用性监控,对于运营团队和网络服务公司来说很容易,但是具体业务逻辑是否在现网保持正常,仍然没有确定答案。既然测试团队有各种核心业务场景的自动化脚本,就可以挑选少量场景,用很小的流量进行拨测,尽早发现问题。

下一篇我们聊聊持续测试实践的进阶思考。


↙↙↙阅读原文可查看相关链接,并与作者交流