你还记得大明湖畔的“测试策略”么

你有多久没听过测试策略这个词了？它就像大明湖畔的夏雨荷，慢慢迷失在快速迭代的敏捷潮流中。曾何几时，测试策略是测试活动的重要一环，它指导着整个测试活动的开展，是高阶测试人员必备的技能。今天，我们来聊聊这个被逐渐忽略的测试技能。

01 什么是测试策略

维基百科上有一大段关于测试策略的定义，这里就不贴出来了，简单来说，测试策略主要关注两个问题：

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

设计测试策略的目标是 “减少缺陷的出现和发布”。其中 “减少缺陷的出现” 可以通过测试前移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷；而 “减少缺陷发布” 可以使用各种测试方法、技术来验证和测试编码完成的功能。

02 传统测试活动中的测试策略设计

在传统的测试活动中，测试策略一般会在项目目标明确后开始设计。整个测试策略会包含但不仅限于以下几个方面：

测试的对象和范围是什么（测试什么东西，哪些不需要测试）

测试目标是什么（为了让产品完全符合商业化的标准，还是小范围适用等）

测试的重点和难点有哪些（测试难点在哪里，需要什么样的支持）

如何安排各类测试活动（先测试什么再测试什么，什么时候集成测试等）

资源投入情况（测试时长、人员配置、环境等）

类似的文档结构如下：

03 它为什么会被逐渐忽略

看了上面的介绍，你大概也能猜到测试策略为什么会被逐渐忽略了，个人的看法如下：

1.没有时间

在敏捷研发的大环境下，每个迭代相对于传统版本的测试时间更少了，我们没有时间去写这么重的文档了，而且它看起来与敏捷的理念相反。

2.测试内容明确

在一个迭代周期内，通过需求实例化，每个迭代测试的内容更清晰且聚焦了，那么原来的很多内容都不再需要了。如下所示：

测试的对象和范围是什么（测试什么东西，哪些不需要测试）

测试目标是什么（为了让产品完全符合商业化的标准，还是小范围适用等）

测试的重点和难点有哪些（测试难点在哪里，需要什么样的支持）

如何安排各类测试活动（先测试什么再测试什么，什么时候集成测试等）

资源投入情况（测试时长、人员配置、环境等）

3.测试惯性作用

与传统的测试不同，敏捷测试是一直在持续地进行，持续的反馈。所以不需要像传统的测试那样在项目初期去初始化一个环境（会一直存在），不需要关心测试时长（每个迭代相对固定），对于各类测试活动也变得不再敏感（本质上是一直在做集成测试）。所以由于敏捷测试的连贯性，测试策略中的部分内容也不再需要关注了，如下所示：

测试的对象和范围是什么（测试什么东西，哪些不需要测试）

测试目标是什么（为了让产品完全符合商业化的标准，还是小范围适用等）

测试的重点和难点有哪些（测试难点在哪里，需要什么样的支持）

如何安排各类测试活动（先测试什么再测试什么，什么时候集成测试等）

资源投入情况（测试时长、人员配置、环境等）

所以，还剩下什么呢？个人认为，剩下的东西，才是测试策略最核心的东西：测试难点在哪里？如何识别出来并给出解决方案。

04 敏捷测试中是否需要测试策略

先给结论，还是要有的。但不并不是每个迭代都需要，在一些核心特性的迭代中，在一些基础能力构建的迭代中，还是需要停下来，好好思考一下如何开展更有效的测试方法，我们需要提前为这个迭代的测试活动做些什么。同时，这份测试策略不宜太长，一页内最好，要保证团队所有成员能够随时看到这份策略并得到团队的整体认可。

个人的经验小结如下，（希望得到更多的建议）

1. 目标导向：本次迭代的内容是否完全推向用户？用户在哪些场景下会使用到这些功能？客户最关心的指标是什么？可用性，还是稳定性？这些需要在迭代计划会开始前，沟通并确认清楚。除了卡片上的显式需求，是否有些隐式的需求，如合规、安全、性能、可靠性等等。

2. 识别风险：测试过程中可能出现的风险有哪些？在需求端，风险主要来自于需求的优先级调整，团队对需求的理解是否到位。在研发设计阶段，风险有常见的几种：研发是否引入了新技术？前后端的人员是否能配合到位？是否有外部依赖？对老功能的影响会有哪些等等。测试团队自身的风险，常见的有人员的变更、测试能力不足等。

如何应对这些风险呢？常见的思路有 4 种：回避风险、转移风险、减轻风险以及接受风险。具体的就不展开了，需要结合项目和团队的具体情况来说，减轻风险是最常见的方案。

3. 测试难点：当前迭代或者项目的测试难点在哪里，是否需要前置准备一些关联数据？是否需要自己搭建一个项目来验证（笔者所带的团队经常需要测试一些底层的项目，比如 SDK，比如网关组件，比如一些数据统计类的项目等等）？当测试团队遇到问题时，如何帮助他们解决这类问题。

05 具体案例分享

在网关项目的某个迭代中，测试人员找到我，希望我能够协助他们完成迭代的测试策略制定，因为他们在了解需求的过程中发现了部分业务的测试难点，没有具体的测试思路（底层应用的测试相对于业务层的测试，更加考验测试人员的能力）。经过和项目组及测试人员沟通后，形成了一份如下的测试策略：

基于这份测试策略，在迭代的测试过程中，就可以相对有信心的开展测试活动，而不是在测试过程中遇到问题了，再想办法处理。

06 小结

三思而后行，在敏捷的环境中，我们虽然不再需要一份大而全的测试策略文档，但是在迭代开始前，还是要好好思考一下如何开展更有效的测试方法，我们需要提前为这个迭代的测试活动做些什么，它将指导我们更好的开展测试活动。而不是接到测试任务就开始测试，等遇到问题后，才开始想着如何处理。

注：想要了解传统的测试活动中关于测试策略的设计及开展，可参考《测试架构师修炼之道：从测试工程师到测试架构师》一书，有大量的篇幅介绍，这也是测试架构师的核心技能之一。

福利（关注公众号领取）