标签归档:测试策略

一页纸测试策略

【摘要】测试策略文档通常是篇幅较长、文字为主的形式,编写成本较高,并且写完了很少有人去看,形存实亡。本文介绍可视化的方式,将测试策略用图来表达,并且在一页纸上搞定,这样的策略图非常清晰,关键信息一目了然,并且提供更大的讨论空间,防止僵化,真正能够发挥策略的作用。


“测试策略是什么样的?”

“测试策略嘛,还不是包括#&~+-=~*-+$这些…”

“你们项目的策略有什么特别的吗?”

“我们项目嘛,测试策略的内容有点多,从哪说起呢?”

前面那个场景有没有似曾相识?你是否清楚目前你们正在使用的测试策略是什么样的?

01. 常见测试策略

测试策略的内容与形式

我们都知道,测试策略包括以下两方面的内容:

  1. 测什么(What)? 测什么是指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求。
  2. 怎么测(How)? 怎么测就是采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等。

为了描述清楚要测的内容以及如何来测,测试策略通常篇幅较长的文档,包含多个章节;以文字描述为主,只加上少量的配图。

常见测试策略目录结构

【图片来自网络:https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html

测试策略的痛点

长篇大论的文字给人带来居多不便:

1. 编写困难

篇幅较长的测试策略文档要写好还真不是件容易的事情,尤其是对于理工科出身的不是那么擅长写作的测试人员来说,更是比较麻烦,成本较高。

2. 不易阅读

长篇大论的测试策略文档,要从中快速找出关键信息可没那么容易,可能一不小心错过的细节就是最关键的部分,因为篇幅太长,通常不太重要的信息挺多的。

3. 维护、更新痛苦

策略文档不可能一成不变,这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好,随着时间推移,更新和维护越来越麻烦。

4. 失去了策略的价值

由于不易阅读,也不易维护和更新,事实上团队可能有很多人并不是很清楚策略文档上的内容,这样的策略文档形存实亡,不能真正起到策略的指南作用。

5. 反敏捷

敏捷开发强调的是缩短反馈周期,快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档,显然是不利于敏捷的,也是非常痛的。

测试策略的重要性不言而喻,是否可以找到一种更好的表达方式,让测试策略不那么痛呢?Jamie McIndoe在“Testing Stuff – A One-Page Test Strategy”中首次提出可以把测试策略图视化,用一页纸来搞定。

我们都知道,图示化的表达方式直观、清晰,容易识别关键信息,并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定,一定非常棒。

下面一起来看看图示化表达的测试策略是什么样的。

02. 图示化测试策略

一页纸搞定

顾名思义,图示化就是用图来描述测试策略的内容,但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分,并且绘在一页纸上。

当然,一页纸的测试策略只是将关键信息以图示化的方式呈现出来,并不是整个测试策略的全部,在一页纸的背后是团队的充分沟通和对策略各个方面达成的一致认识,是需要团队一起来做很多工作的。这种高度简化的呈现形式,是为了给团队更多的讨论空间,一页纸也更易于修改,从而更能适应变化,真正满足需求。

基于Jamie McIndoe的可视化测试策略思想,我建议的测试策略图包含下列信息:

  • 指导性原则:团队为质量负责
  • 如何测:测试左移、精益测试、测试右移,涵盖测试流程、测试类型、测试方法等
  • 测什么:包括功能、性能和安全等

下面将以蓝鲸项目为例来介绍这几个部分的内容。关于蓝鲸项目,是一个历经10年的离岸交付项目,采用的是敏捷开发的模式,每四到五周一次发布,遵循敏捷开发的各种实践。

例如,蓝鲸项目的测试策略如下图所示:

蓝鲸项目测试策略图

各部分详细介绍

下面,我们来看看该测试策略各组成部分的具体含义。

1. 指导性原则

蓝鲸项目采用的是敏捷开发模式,质量不是某个单一角色的事情,团队为质量负责是项目质量保障的指导性原则,需要所有团队成员对此有一致的认识,人人都要有关注质量的意识。更多关于团队为质量负责的内容,请参考我的博客文章说好的团队为质量负责呢

2. 测试左移与质量内建

敏捷测试最关键的两点就是尽早测试和频繁测试(Test early, test often),也就是测试左移与质量内建的思想。

测试左移要求在需求分析阶段开始对需求本身的合理性进行验证,不仅要正确的构建产品,更重要的是构建正确的产品,这就需要把好源头需求这一关。因此,我们可以看到策略里的流程是从需求分析开始的。

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动,把质量融入到开发的每一个步骤,通过CI/CD等方式获取快速反馈,做好软件缺陷的预防,以减轻缺陷暴露太晚带来的大量修复成本。

蓝鲸项目的开发生命周期主要体现在下图的七个环节,每个环节都有相应测试活动的开展,并且每个活动都有不同角色的参与。

蓝鲸项目开发生命周期的测试活动

3. 精益测试

精益测试可以理解为以业务价值为目标,以尽量少的成本交付高质量的软件,也就是说测试要测在能体现价值的点上,要做到有效覆盖、减少浪费。蓝鲸项目的策略图里有两个框架帮我我们更有效的测试,分别是测试象限和测试分层。

测试象限

在Lisa Crispin和Janet Gregory合著的书籍《敏捷软件测试:测试人员与敏捷团队的实践指南》中,我们看到了敏捷测试象限的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境,我在这里称之为测试象限。

测试象限矩阵一共四个部分,称为四个象限。下侧是面向技术的测试,上侧是面向业务的测试;左侧是支持团队的测试,右侧则是评价产品的测试。

1) 支持团队的测试

支持团队的测试是用来告诉团队要写什么代码,起到明确需求、辅助设计的作用。其中,第一象限是面向技术的支持团队的测试,主要是TDD,帮助构建产品的内部质量,也就是代码质量的保障,比如单元测试和API测试等;第二象限则是面向业务的支持团队的测试,从更高层次以业务专家可以理解的方式确定系统期望的行为,做到产品外部质量的保障。

这两个象限的测试能够快速提供反馈信息,并确保快速的解决问题,既指导了功能的开发,又提供了防止重构和新代码的引入而导致不期望行为发生的安全网。

2) 评价产品的测试

程序员编写的代码可以使得左侧面向业务的测试通过,但也可能没有产生客户真正想要的东西,因此还需要第三、第四象限的评价产品的测试。

第三象限是面向业务的评价产品的测试,通过模仿真实用户使用应用的方式,帮助确认是否构建了真正需要的产品;第四象限是面向技术评价产品的测试,主要采用工具和相应的技术来评价产品的性能、健壮性和安全性等非功能特性,并且在开发周期的每一步都要考虑这些测试的开展。

这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧,并用于创建新的测试来驱动下一步开发,形成良性的增强环路。

3) 测试象限的使用

象限的顺序跟测试执行的顺序无关,敏捷开发往往开始于客户测试(面向业务的测试)。与测试执行时机相关的因素通常有:

  • 产品发布的风险
  • 客户方对产品目标的要求
  • 是基于遗留系统的开发还是从零开始构建的新系统
  • 可利用的测试资源等

测试象限提供一种需要哪些测试来保障质量的思考框架,可以根据项目具体情况,结合考虑以开展对应的测试。策略图所示蓝鲸项目的测试象限体现的测试类型跟Lisa书里介绍的就不太一样,这是根据项目当前跟客户的合作方式、业务需求、质量要求等来确定的当下需要执行的测试,比如其中的安全测试就分为业务部分和技术部分。

测试分层

关于测试分层的思想,大家可能比较熟悉的是测试金字塔,主要是针对自动化测试,根据测试所能覆盖的范围分成不同的层。金字塔的含义是测试比例的多少,体现为底层单元测试较多,越往上层测试比例越少,呈现为金字塔结构。

越往底层的测试越接近代码,编写成本更低、执行速度更快、定位问题也更准确,但是离业务较远,不能很好的体现业务价值;越往上层的测试越接近业务,更能反应业务价值,但有着不够稳定、执行速度慢、实现成本较高的不足。因此,需要权衡利弊,根据项目具体情况,真实的目标来确定每层测试的比例。

至于具体的比例是金字塔结构,还是蜂巢结构或其他,并不是一定的,也不会是一成不变的,可能受到价值目标、痛点、质量要求、技术架构、技能水平等因素的影响。

蓝鲸项目的策略图里的是当前的测试分层结构,类似于蜂巢机构,那是因为基于微服务架构的特点,蓝鲸项目更多的自动化测试是保障服务间连通性的API测试部分,而对于单元测试和端到端测试的比例则都有减弱。更多的关于蓝鲸项目测试策略的详情,请参考我的博客文章微服务测试的思考与实践

4. 测试右移

由于软件系统所处生态环境越来越复杂,技术架构的演进、业务复杂度和数据量的增加、基础设施的发展带来更多的不确定性,软件系统的质量保障在测试环境已经搞不定了,我们需要把目光右移到生产环境。这就是测试右移的思想,其实也就是生产环境下的QA(QA in Production)。

生产环境有着不同于测试环境的特点,生产环境的QA并不是测试环境的QA的直接后延,而是需要利用其特点通过技术手段收集生产环境一切可利用的数据,包括日志、用户行为、用户反馈等,利用这些数据来分析和优化业务以及开发过程的开发和测试工作,形成一个开发过程与生产环境信息分析的良性循环系统。

蓝鲸项目在这方面做了不少工作,更多相关的详细内容,请参考我的博客文章生产环境下的QAQA与Ops通力合作打造反脆弱的软件系统

5. 测什么

之所以把这个放到最后介绍,是因为前面介绍“怎么测”的各个部分都已经涵盖到要测试的内容,蓝鲸项目的测试内容主要有:功能、性能和安全。

这三个方面的测试类似,都是从需求分析到生产环境每个环节都要考虑相关测试,做到质量内建、安全内建和持续的性能测试。关于功能方面的质量内建,前面【测试左移与质量内建】部分有介绍,对于安全和性能方面的策略,可以参考如下图示,由于篇幅有限,本文不做赘述。

蓝鲸项目的跨功能测试

03. 测试策略的正确打开方式

一页纸搞定的测试策略,优势非常明显,比传统策略文档更加简洁、清晰,关键信息一目了然。我们再来看一下测试策略图示化以后,还有哪些需要注意的方面。

目标驱动

虽然上网搜索能找到很多测试策略模板,但测试策略不应该是千篇一律的,不可以死搬硬套通用的模板。测试策略受到多种因素的影响,比如:业务价值、质量要求、当时痛点、技术架构、技术能力、工作重心、绩效要求、项目状态等等。

制定测试策略需要明确目标,综合考虑各种因素,权衡利弊,找到最适合自己项目当前状态的策略。也就是说,测试策略应该是目标驱动的。

演进式

项目处于不同阶段会有不同的质量目标,同时随着架构的演进和业务的发展,对软件系统的质量保障工作也需要随之调整。因此,测试策略还应该是演进式的、随需调整的。

图示化的测试策略是高度精简的,具有更大的讨论和发挥空间,在防止僵化、保持演进方面的优势明显。

04. 总结

测试策略举足轻重,内容很重要,需要以价值目标驱动,持续度量,并根据项目特定情况适时调整、演进。策略文档不要拘泥于形式,利用图示化的方法,直观、清晰的表达,是非常好的组织形式,能有效克服常规文字为主的文档所带来的痛,推荐大家使用。

05. 延伸阅读

  1. Jamie McIndoe的Testing Stuff – A One-Page Test Strategy:https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
  2. 说好的团队为质量负责呢:https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
  3. QA in Production:https://martinfowler.com/articles/qa-in-production.html
  4. 蓝鲸项目测试策略之微服务测试的思考与实践:https://www.bylinzi.com/2018/06/28/microservices-testing/
  5. 生产环境下的QA:https://www.bylinzi.com/2016/06/13/qa-in-production/
  6. QA与Ops通力合作打造反脆弱的软件系统:https://www.bylinzi.com/2018/10/15/qaops/

微服务测试的思考与实践

最近几年,微服务架构越来越火爆,逐渐被企业所采用。随着软件架构的变化,对应的软件测试策略需要作何调整呢?本文将介绍微服务架构下的测试策略,并结合分享在业务和架构演变过程中,一个历经九年的项目测试策略的演进。

关于微服务

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的进程中,服务间采用轻量级通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体的业务进行构建,并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处:

  • 每个服务可以独立开发
  • 处理的单元粒度更细
  • 单个服务支持独立部署和发布
  • 更有利于业务的扩展

同时,独立开发导致技术上的分离,HTTP通信加上Queue的机制增加了问题诊断的复杂度,对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外,服务间的复杂依赖关系带来了很多的不确定性,要实现独立部署,对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面:

  • 服务间的依赖、连通性
  • 服务的容错、可用性
  • 数据的最终一致性
  • 独立部署
  • 不确定性

测试策略的选择

谈到微服务的测试策略,很容易就想到了老马网站上Toby Clemson的文章《Microservices Testing》,该文推荐的微服务框架下的测试策略是这样的:

经典测试策略

这个策略模型强调测试分层以及每一层的恰当覆盖,整体符合金字塔结构。它是最优的吗?

有人对此提出了质疑…认为策略模型应该是蜂巢形状的(请参考文章):


这个模型重点关注服务间的集成测试,两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的,服务间的集成依然是重点,单元测试较少,而顶层增加了安全和性能等非功能测试。

好像都有道理,到底选择什么样的策略模型好呢?不禁陷入了困境……怎么办?不妨先来听听我们项目的故事吧!

项目的故事

测试策略的演进

还是那个蓝鲸项目,不知不觉进入了第九个年头。在这九年里,随着业务的不断发展,系统架构也进行了多次演进和调整。相应的,测试策略也发生了有意思的演进变化。

测试策略的演进

最初单一用户系统、单体架构的时候,严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展,大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候,我们调整了策略,减少单元测试的编写,增加UI层E2E测试的覆盖,测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来,架构调整,开始服务化。此时,大量的E2E测试渐渐暴露出问题:

  • CI上的测试执行时间越来越长,而且定位问题的能力很弱,测试一旦失败需要很长时间修复,测试人员好几天也拿不到可以测试的版本,反馈周期过长;
  • 由于服务化带来的不稳定因素增加,E2E测试没法很好的覆盖到需要的场景,测试人员就算拿到可测的版本也总有各种缺陷发生。

因此,项目引入契约测试,停止编写新的E2E测试,将测试下移,分别用API测试和契约测试取代。

随着功能的不断增加,虽然E2E测试的量并不增加,但是其不稳定性、维护难、定位难的问题有增无减,此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益,项目考虑去掉大部分E2E测试,只保留少量的Smoke测试,将更多的测试下移。

同时,技术雷达上新的技术“生产环境下的QA”出现,项目也开始关心生产环境,并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

应对微服务的挑战

前文提到过微服务带来的挑战,下面来看项目是如何应对这些挑战的。

  • 服务间的依赖、连通性

微服务架构下,独立开发的服务要整合起来最具挑战,如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战,并不适合,而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性,取代一部分E2E集成测试。

  • 服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候,微服务架构有两种技术来确保系统的可用性:服务的熔断和降级。服务的熔断是指当某个服务出现故障时,为了保证系统整体的可用性,会关闭掉出现故障的服务;服务的降级则是当系统整体负荷过载的时候,考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括:

  1. 熔断:从性能角度,当系统负载达到某个熔断状态的时候,服务是否能正确熔断;同时,从功能角度验证熔断后系统的行为是否跟预期相符;
  2. 降级:从业务的角度,要能区分出核心业务和外围业务,在需要降级的时候不能影响核心业务;当某个服务降级后,从功能角度验证系统行为是否跟预期相符。
  • 数据的最终一致性

数据一致性是微服务特别需要关注的。举个例子,电商平台某个订单支付成功以后,需要更新积分和订单状态,当订单服务或者积分服务其中有一个出现故障的时候,就会导致最终的数据不一致性。

测试这种情况,从业务的角度分析哪些服务会导致数据不一致性,制造对应的异常情况去测试数据的最终一致性。

  • 独立部署

微服务的独立部署需要有CI、CD的支持,跟DevOps实践分不开。同时,更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作,请参考王健的文章:你的微服务敢独立交付吗?

  • 不确定性

微服务架构使得系统复杂度增加不少,很多的事情发生都是不可预测的,只能在其发生以后找到产生的原因。因此,也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue,我们需要把目光转移到生产环境,利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA,请参考文章:生产环境下的QA

项目测试策略

从前面介绍的演进过程可以看到,项目测试策略在不同阶段结合参考了不同的策略模型:金字塔->近似钻石(除非功能测试外,类似于钻石模型)->蜂巢。后期全面服务化的时候,我们认为蜂巢模型是比较适合的。

当然,光有符合这个策略模型的自动化测试是远远不够的,我们项目还采用了针对微服务特点的探索式测试,保持持续交付节奏,践行DevOps实践,结合生产环境下的QA等技术把关注点右移到生产环境。

现在,项目整体测试策略演变成下图的形式:

  1. 项目采用的是敏捷迭代开发和持续交付的模式,每四周一个发布周期。
  2. 在开发过程中实现的自动化测试是分层实现的:底层少量的单元测试,中间量最多的是API测试(类似于老马推荐的策略模型里的组件测试),上面有一部分契约测试和少量的Smoke测试来保证服务间的契约和集成。除此之外,QA有手动的探索式测试,其中包括针对微服务特点进行的一些测试。整个测试结构是类似于蜂巢模型的。
  3. 采用生产环境下的QA技术,利用生产环境,进行error监控、用户行为分析、用户反馈收集,从而来影响和指导预生产环境的开发和测试工作。
  4. 利用DevOps实践,做到高效的部署和监控,跟生产环境下的QA结合,形成良性的环路,保证项目的正常交付。

测试策略再思考

项目上多次测试策略的调整,看似很简单,其实每次调整并不是一个轻松的过程,都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程,最后突然发现:当我们面对多个策略模型不知道如何选择的时候,其实我们陷入了一个太过于关注测试结构的误区,忘记了最初的目标是什么。

影响测试策略的因素

跳出误区,回到原点,重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

  • 业务价值

带来更大的业务价值、帮企业赢得更多的利润,是软件系统的目标;软件测试是软件系统成功的保障之一,业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展,考虑业务优先级,有效规避业务风险。

  • 质量要求

不同的系统、同一系统的不同利益干系人(参与的不同角色)对于质量的定义和要求都可能是不同的,这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统,关注的重心可能是系统的功能;而对外发布的产品,则要求更高,一个按钮位置的不恰当都可能带来大量用户的流失。

  • 痛点

真正的痛点往往也是优先级最高,迫切需要解决的。那些可以通过测试策略的调整来解决的痛点,自然成为了关键的影响因素之一。比如,CI Pipeline出包太慢,为了提高出包的效率,一方面在Pipeline本身想办法,另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

演进式测试策略

处在不同阶段的项目,在业务价值这个大目标下,其他影响因素也是会不一样的,跟技术架构的演进一样,测试策略也应该是演进式的。

从目标出发,综合所处阶段各个方面的影响因素,制定出适合当时的测试策略。随着时间的推移,对策略进行评估和度量,并进一步改进、提高,以更好的满足需求。这就是目标驱动的演进式测试策略。

总结

微服务架构下多个服务的整合是最具有挑战的,对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏,确保服务的连通性,有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事,可以利用这些不确定性,采用生产环境下的QA等技术,增强系统的反脆弱性,从中获益。

测试策略的影响因素不是唯一的,技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下,测试策略不是制定完了就可以束之高阁的,需要在整个软件系统构建过程中不断的度量和改进,是演进式的。