你还记得测试策略么
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 小结
三思而后行,在敏捷的环境中,我们虽然不再需要一份大而全的测试策略文档,但是在迭代开始前,还是要好好思考一下如何开展更有效的测试方法,我们需要提前为这个迭代的测试活动做些什么,它将指导我们更好的开展测试活动。而不是接到测试任务就开始测试,等遇到问题后,才开始想着如何处理。
注:想要了解传统的测试活动中关于测试策略的设计及开展,可参考《测试架构师修炼之道:从测试工程师到测试架构师》一书,有大量的篇幅介绍,这也是测试架构师的核心技能之一。