距离我一次写测试相关话题的文章,已经有相当长的一段时间了。对于自动化测试相关的内容,我大抵还算是熟悉的。毕竟,开发人员写测试这件事在 ThoughtWorks 是自然而然的,它也体现在我的开源项目上。恰好,最近我正在帮助客户设计和实施测试策略。
我便有了想法重新写一篇文章,体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客,正好缺失这样的一篇文章。
PS:我并非一个专业的测试工程师,其中若有偏颇之处,欢迎大家指正。
什么是测试策略?
测试策略是一份在特定环境约束之下,描述软件开发周期中关于测试原则、方法、方式的纲要,并阐述了它们之间如何配合,以高效地减少缺陷、提升质量。在这份策略中,需要描述测试的类型、目标、方法、准入准出条件、所需的时间、资源以及环境等信息。
测试策略是一个因地制宜地策略模式,针对于不同的公司、不同的团队、不同类型的项目,相关的内容内容或多或少会出现变化。如对于快速迭代的互联网公司来说,单元测试、UI 自动化测试不一定会被采用。
对于测试策略来说,我们主要关注于两部分的内容:
测什么?需要包含哪些测试及对应的测试范围?
怎么测?包含哪些测试方法?以及如何通过各种手法配合完成测试?
如《测试架构师修炼之道》一书所说,它考虑的实际上是:
测试的对象和范围是什么?
测试的目标是什么?
测试的重点和难点是什么?
测试深度和广度是什么?
如何安排各种测试活动?
如何评价测试的效果?
这样一看,测试策略看上去还是蛮复杂的。但是,事实并非如此,因为现有的测试体系和架构已经非常丰富,并且我们可以看到各种各样的测试策略示例。
测试策略设计
在进行测试策略设计之前,我们确立好基本思想:每个人为质量负责。不是 QA,也不止是 QA 和 开发,而是所有人。
对应的,我们要做好关于尝试策略的演进式规划:
尽早测试、不断测试
将犯错提前,以加快反馈。
测试策略不是一成不变的,而是不断演进的
在我们继续设计之前,我们还需要:
收集、分析现有的缺陷类型、修复时间等
寻找适合项目的测试类型、方式
确认方案所需要的度量体系
定义『测什么?』
测什么是指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求。
在这里,我的同事林冰玉在那篇《一页纸测试策略》中提到测试的三个方面:功能、安全、性能,结合其中定义的开发生命周期中的测试活动。
我们就有了关于『测什么』的设计过程:
可视化软件开发生命周期
定义现有的每个环节已实施的内容
添加新的测试活动
与团队讨论可行性
在迭代优化中更新『测什么』部分
定义『怎么测?』
怎么测就是采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等。
这部分的定义依赖于有一定的测试经验的 QA 进行编写。如下是一份定义特定测试活动的模板示例:
测试类型
测试说明
测试范围
技术
准入标准
准出标准
注意事项
环境
……
相似的,这里只是提供一个模板,针对于不同的组织来说会存在一些差距。
记录测试策略
记录,没啥说的,单纯的记录。只是呢,在记录的时候需要注意一下:
保持测试策略的团队可见性。
和团队达到一致意见。
持续更新。在线随时可更新的文档优于二进制形式
可视化
没啥说的,只是单纯的可视化。
在这里,提供一份我 Ledge 的可视化示例。
总体实施方案
尽管有了上述的内容,但是实施起来并非那么容易——至少我们需要一个总的大纲。于是,在与我的同事于晓南讨论之后,大致有了一个总体方案设计和实施的过程:
明确总体目标。即我们做这件事的价值是什么?
可测试性调研。评估自动化测试的可行性;定位
设计测试策略。适配项目需要,确认分层策略;
测试 MVP。结合项目进行环境准备、框架选型、Demo 准备
落地测试策略。
管理数据和用例。
持续更新和优化。
针对于不同的项目来说,计划会存在一些区别,如:
可测试性调研。评估自动化可行性;定位自动化测试的测试目的;
进行测试策略赋能。测试赋能计划;制定自动化测试目标比例;
制定和落地分级测试策略。通用的应用级测试策略模板;设计环境管理、数据管理、用例管理方案;
对齐标准的测试环境。打通自动化测试环境;
进行测试数据管理。
持续优化。建立可持续性的测试知识库;
测试策略的实施
这部分也不复杂,主要依旧是:
测试的 MVP 示例。框架选型、准备 DEMO
结合项目的示例。准备环境
项目中落地。集成 CI、本地踊
对团队进行赋能。
大规模落地。新增代码测试覆盖、存量代码优化
进行测试评审。
持续更新。
相关的工具见:常见测试工具
参考文章:
《从测试策略到测试架构》
《测试架构师修炼之道》
《一页纸测试策略》
领取专属 10元无门槛券
私享最新 技术干货