转载

一页纸测试策略

“测试策略是什么样的?”
“测试策略嘛,还不是包括#&~+-=~*-+$这些…”
“你们项目的策略有什么特别的吗?”
“我们项目嘛,测试策略的内容有点多,从哪说起呢?”

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

一、常见测试策略

(一)测试策略的内容与形式

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

1. 测什么(What)?

测什么是指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求。

2. 怎么测(How)?

怎么测就是采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等。

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

一页纸测试策略

图1 常见策略文档目录结构

【图片来源: https://www.softwaretestingmaterial.com/test-strategy/ 】

(二)测试策略的痛点

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

1. 编写困难

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

2. 不易阅读

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

3. 维护、更新痛苦

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

4. 失去了策略的价值

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

5. 反敏捷

工作的软件高于详尽的文档

-- 敏捷宣言

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

测试策略的重要性不言而喻,是否可以找到一种更好的表达方式,让测试策略不那么痛呢?

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

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

二、图示化测试策略

(一)一页纸搞定

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

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

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

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

一页纸测试策略

图2 蓝鲸项目策略图

(二)各部分详细介绍

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

1. 指导性原则

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

2. 测试左移与质量内建

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

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

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动,把质量融入到开发的每一个步骤,通过CI/CD等方式获取快速反馈,做好软件缺陷的预防,以减轻缺陷暴露太晚带来的大量修复成本。蓝鲸项目的开发生命周期主要体现在图示的七个环节,每个环节都有相应测试活动的开展,并且每个活动都有不同角色的参与。

一页纸测试策略

图3 蓝鲸项目生命周期的测试活动

3. 测试精益

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

(1)测试象限

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

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

a. 支持团队的测试

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

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

b. 评价产品的测试

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

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

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

c. 测试象限的使用

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

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

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

(2)测试分层

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

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

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

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

4. 测试右移

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

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

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

5. 测什么

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

这三个方面的测试类似,都是从需求分析到生产环境每个环节都要考虑相关测试,做到质量内建、安全内建和持续的性能测试。

一页纸测试策略

图4 蓝鲸项目的非功能测试

三、测试策略的正确打开方式

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

1. 目标驱动

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

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

2. 演进式

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

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

四、总结

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

延伸阅读

1.Jamie McIndoe的一页纸测试策略: https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/

2.说好的团队为质量负责呢:

https://www.jianshu.com/p/f81795a23554

3.QA in Production: https://martinfowler.com/articles/qa-in-production.html

4.生产环境下的QA: https://www.jianshu.com/p/20b454a88bdb

5.QA与Ops通力合作打造反脆弱的软件系统: https://www.jianshu.com/p/1f456d91c3ab

更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

原文  https://insights.thoughtworks.cn/testing-strategy-one-page/
正文到此结束
Loading...