DevOps 进阶：测试策略设计

prtyaa 2023-12-25 13:34:17  66089

分类专栏：资讯

距离我一次写测试相关话题的文章，已经有相当长的一段时间了。对于自动化测试相关的内容，我大抵还算是熟悉的。毕竟，开发人员写测试这件事在 ThoughtWorks 是自然而然的，它也体现在我的开源项目上。恰好，最近我正在帮助客户设计和实施测试策略。

我便有了想法重新写一篇文章，体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客，正好缺失这样的一篇文章。PS：我并非一个专业的测试工程师，其中若有偏颇之处，欢迎大家指正。

什么是测试策略？

测试策略是一份在特定环境约束之下，描述软件开发周期中关于测试原则、方法、方式的纲要，并阐述了它们之间如何配合，以高效地减少缺陷、提升质量。在这份策略中，需要描述测试的类型、目标、方法、准入准出条件、所需的时间、资源以及环境等信息。

测试策略是一个因地制宜地策略模式，针对于不同的公司、不同的团队、不同类型的项目，相关的内容内容或多或少会出现变化。如对于快速迭代的互联网公司来说，单元测试、UI 自动化测试不一定会被采用。对于测试策略来说，我们主要关注于两部分的内容：

测什么？ 需要包含哪些测试及对应的测试范围？
怎么测？ 包含哪些测试方法？以及如何通过各种手法配合完成测试？

如《测试架构师修炼之道》一书所说，它考虑的实际上是：

测试的对象和范围是什么？
测试的目标是什么？
测试的重点和难点是什么？
测试深度和广度是什么？
如何安排各种测试活动？
如何评价测试的效果？

这样一看，测试策略看上去还是蛮复杂的。但是，事实并非如此，因为现有的测试体系和架构已经非常丰富，并且我们可以看到各种各样的测试策略示例。

测试策略设计

在进行测试策略设计之前，我们确立好基本思想：每个人为质量负责。不是 QA，也不止是 QA 和开发，而是所有人。

对应的，我们要做好关于尝试策略的演进式规划：

尽早测试、不断测试
将犯错提前，以加快反馈。
测试策略不是一成不变的，而是不断演进的

在我们继续设计之前，我们还需要：

收集、分析现有的缺陷类型、修复时间等
寻找适合项目的测试类型、方式
确认方案所需要的度量体系

定义『测什么？』

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

在这里，我的同事林冰玉在那篇《一页纸测试策略》中提到测试的三个方面：功能、安全、性能，结合其中定义的开发生命周期中的测试活动。

我们就有了关于『测什么』的设计过程：

可视化软件开发生命周期
定义现有的每个环节已实施的内容
添加新的测试活动
与团队讨论可行性
在迭代优化中更新『测什么』部分

定义『怎么测？』

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

这部分的定义依赖于有一定的测试经验的 QA 进行编写。如下是一份定义特定测试活动的模板示例：

测试类型
测试说明
测试范围
技术
准入标准
准出标准
注意事项
环境
……

相似的，这里只是提供一个模板，针对于不同的组织来说会存在一些差距。

记录测试策略

记录，没啥说的，单纯的记录。只是呢，在记录的时候需要注意一下：

保持测试策略的团队可见性。
和团队达到一致意见。
持续更新。在线随时可更新的文档优于二进制形式

可视化

没啥说的，只是单纯的可视化。

在这里，提供一份我 Ledge 的可视化示例。

总体实施方案

尽管有了上述的内容，但是实施起来并非那么容易——至少我们需要一个总的大纲。于是，在与我的同事于晓南讨论之后，大致有了一个总体方案设计和实施的过程：

明确总体目标。即我们做这件事的价值是什么？
可测试性调研。评估自动化测试的可行性；定位
设计测试策略。适配项目需要，确认分层策略；
测试 MVP。结合项目进行环境准备、框架选型、Demo 准备
落地测试策略。
管理数据和用例。
持续更新和优化。

针对于不同的项目来说，计划会存在一些区别，如：

可测试性调研。评估自动化可行性；定位自动化测试的测试目的；
进行测试策略赋能。测试赋能计划；制定自动化测试目标比例；
制定和落地分级测试策略。通用的应用级测试策略模板；设计环境管理、数据管理、用例管理方案；
对齐标准的测试环境。打通自动化测试环境；
进行测试数据管理。
持续优化。建立可持续性的测试知识库；

测试策略的实施

这部分也不复杂，主要依旧是：

测试的 MVP 示例。框架选型、准备 DEMO
结合项目的示例。准备环境
项目中落地。集成 CI、本地踊
对团队进行赋能。
大规模落地。新增代码测试覆盖、存量代码优化
进行测试评审。
持续更新。