https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483945&idx=1&sn=1ea7699d28acb2f51e94fc0cfc7dadc9&chksm=c0fb141cf78c9d0ae4c20162f78b68106e6a16e2dfd15e02aa97b33694c007e57af6dc266312&cur_album_id=1979310371207184387&scene=189#wechat_redirect
你有多久没听过测试策略这个词了？它就像个走失的小孩，慢慢迷失在快速迭代的敏捷潮流中。曾何几时，测试策略是测试活动的重要一环，它指导着整个测试活动的开展，是高阶测试人员必备的技能。今天，我们来聊聊这个被逐渐忽略的测试技能。
01 什么是测试策略
维基百科上有一大段关于测试策略的定义，这里就不贴出来了，简单来说，测试策略主要关注两个问题：
测什么： 测什么是指质量需求是什么、需要关注质量的哪些方面，比如应用的功能范围、性能、安全、易用性等非功能需求。
怎么测： 怎么测就是采用什么办法来帮助系统实现质量需求，而不仅仅是手动和自动化的测试方法，也包括一切为质量保障服务的流程、环境、基础设施和人员等。
设计测试策略的目标是“减少缺陷的出现和发布”。其中“减少缺陷的出现”可以通过测试前移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷；而“减少缺陷发布”可以使用各种测试方法、技术来验证和测试编码完成的功能。
02 传统测试活动中的测试策略设计
在传统的测试活动中，测试策略一般会在项目目标明确后开始设计。整个测试策略会包含但不仅限于以下几个方面：
测试的对象和范围是什么（测试什么东西，哪些不需要测试）
测试目标是什么（为了让产品完全符合商业化的标准，还是小范围适用等）
测试的重点和难点有哪些（测试难点在哪里，需要什么样的支持）
如何安排各类测试活动（先测试什么再测试什么，什么时候集成测试等）
资源投入情况（测试时长、人员配置、环境等）
类似的文档结构如下：
03 它为什么会被逐渐忽略
看了上面的介绍，你大概也能猜到测试策略为什么会被逐渐忽略了，个人的看法如下：
1. 没有时间
在敏捷研发的大环境下，每个迭代相对于传统版本的测试时间更少了，我们没有时间去写这么重的文档了，而且它看起来与敏捷的理念相反。
2. 测试内容明确
在一个迭代周期内，通过需求实例化，每个迭代测试的内容更清晰且聚焦了，那么原来的很多内容都不再需要了。如下所示：
测试的对象和范围是什么（测试什么东西，哪些不需要测试）
测试目标是什么（为了让产品完全符合商业化的标准，还是小范围适用等）
测试的重点和难点有哪些（测试难点在哪里，需要什么样的支持）
如何安排各类测试活动（先测试什么再测试什么，什么时候集成测试等）
资源投入情况（测试时长、人员配置、环境等）
3. 测试惯性作用
与传统的测试不同，敏捷测试是一直在持续地进行，持续的反馈。所以不需要像传统的测试那样在项目初期去初始化一个环境（会一直存在），不需要关心测试时长（每个迭代相对固定），对于各类测试活动也变得不再敏感（本质上是一直在做集成测试）。所以由于敏捷测试的连贯性，测试策略中的部分内容也不再需要关注了，如下所示：
测试的对象和范围是什么（测试什么东西，哪些不需要测试）
测试目标是什么（为了让产品完全符合商业化的标准，还是小范围适用等）
测试的重点和难点有哪些（测试难点在哪里，需要什么样的支持）
如何安排各类测试活动（先测试什么再测试什么，什么时候集成测试等）
资源投入情况（测试时长、人员配置、环境等）
所以，还剩下什么呢？个人认为，剩下的东西，才是测试策略最核心的东西：测试难点在哪里？如何识别出来并给出解决方案。
04 敏捷测试中是否需要测试策略
先给结论，还是要有的。但不并不是每个迭代都需要，在一些核心特性的迭代中，在一些基础能力构建的迭代中，还是需要停下来，好好思考一下如何开展更有效的测试方法，我们需要提前为这个迭代的测试活动做些什么。同时，这份测试策略不宜太长，一页内最好，要保证团队所有成员能够随时看到这份策略并得到团队的整体认可。
个人的经验小结如下，（希望得到更多的建议）
1. 目标导向：本次迭代的内容是否完全推向用户？用户在哪些场景下会使用到这些功能？客户最关心的指标是什么？可用性，还是稳定性？这些需要在迭代计划会开始前，沟通并确认清楚。除了卡片上的显式需求，是否有些隐式的需求，如合规、安全、性能、可靠性等等。
2. 识别风险：测试过程中可能出现的风险有哪些？在需求端，风险主要来自于需求的优先级调整，团队对需求的理解是否到位。在研发设计阶段，风险有常见的几种：研发是否引入了新技术？前后端的人员是否能配合到位？是否有外部依赖？对老功能的影响会有哪些等等。测试团队自身的风险，常见的有人员的变更、测试能力不足等。
如何应对这些风险呢？常见的思路有4种：回避风险、转移风险、减轻风险以及接受风险。具体的就不展开了，需要结合项目和团队的具体情况来说，减轻风险是最常见的方案。
3. 测试难点：当前迭代或者项目的测试难点在哪里，是否需要前置准备一些关联数据？是否需要自己搭建一个项目来验证（笔者所带的团队经常需要测试一些底层的项目，比如SDK，比如网关组件，比如一些数据统计类的项目等等）？当测试团队遇到问题时，如何帮助他们解决这类问题。
05 具体案例分享
在网关项目的某个迭代中，测试人员找到我，希望我能够协助他们完成迭代的测试策略制定，因为他们在了解需求的过程中发现了部分业务的测试难点，没有具体的测试思路（底层应用的测试相对于业务层的测试，更加考验测试人员的能力）。经过和项目组及测试人员沟通后，形成了一份如下的测试策略：
基于这份测试策略，在迭代的测试过程中，就可以相对有信心的开展测试活动，而不是在测试过程中遇到问题了，再想办法处理。
06 小结
三思而后行，在敏捷的环境中，我们虽然不再需要一份大而全的测试策略文档，但是在迭代开始前，还是要好好思考一下如何开展更有效的测试方法，我们需要提前为这个迭代的测试活动做些什么，它将指导我们更好的开展测试活动。而不是接到测试任务就开始测试，等遇到问题后，才开始想着如何处理。
注：想要了解传统的测试活动中关于测试策略的设计及开展，可参考《测试架构师修炼之道：从测试工程师到测试架构师》一书，有大量的篇幅介绍，这也是测试架构师的核心技能之一。
原文地址：http://www.cnblogs.com/ceshi2016/p/16800406.html
