梅子：探索式测试应用场景实战解析

2017年1月22日晚8点半，《测试架构师修炼之道》的作者梅子，一位拥有10年网络安全产品测试经验的新任产品经理，为大家带来主题为“一张涂鸦搞定探索式测试”的分享。以下是主持人刘静对精华内容做的实录整理。

问：对于敏捷度高的团队，基于业务的功能测试范围比较狭隘，有些测试同学认为不用太挖空心思的去设计就能基本保障版本功能ok，久而久之，这种情况导致测试技能徘徊不前。在不想向coding发展的状态下，晋级就成为障碍，请教怎么能帮助这样的同学唤醒激情保持职业化，并指出做为功能测试方向有哪些路可以走，可以提升自身，作为职业等级的晋升的基础。（在这个阶段很多同学会迷失方向。）

答：我感到现在大家普遍对功能测试存有某种偏见，一提到功能测试，就是“点点点”，没有技术含量。事实上，我的观察是，我身边测试做得好，最受重视的同学，都是功能测试高手。

功能测试帮助他们成为了熟悉产品的人（准确的说是最熟悉产品的“坑”的人）。很多反馈，用户答疑，只有对产品有足够的熟悉，才能很好的完成。我自己有十多年的测试经验，但我还是会做功能测试，通过功能测试来一直保持对产品的敏感性。

功能测试也能帮助我们理解业务，理解用户的需求。对业务和对用户的理解，是测试的宝贵经验，可以帮助产品在前期做缺陷预防。

从测试技能的角度来说，功能测试的方法，用例设计的方法也有很多很多值得我们分析和总结的地方。

所以功能测试并不是我们想象的那么low，有很多点都值得我们去钻研。

如何唤醒职业激情呢？

我想有这类问题的同学一般是测试团队的leader，可能整个组织对测试的重视度不够的，或者说领导可能对测试有些轻视。测试leader如果有办法改变领导对测试的团队的看法和期望，对提升整个测试团队的职业激情是有莫大帮助的，但这也很难——我们知道，最难的就是改变别人的思想，更何况是领导的思想。我觉得还有一个思路，就是测试leader不把眼光仅仅局限在公司，可以给测试团队的同学介绍一些业界做功能测试，做得很出色的人，建立一些榜样，多鼓励团队成员来研究功能测试的方法，做一些友商分析等，在团队中营造新的氛围，也会起到一定的作用。

从职业发展的角度来说，功能测试者，可以发展为某个行业的业务专家，也可以转岗做产品经理或者市场等，都是可以的。

问：文章中提到的7个特性，它们本身就有优先级吗？还是说所谓的优先级是需要测试者衡量？

答：文章中提到的7个特性，是特性的“分类”。为什么要进行分类呢，是因为探索式测试下还是有很多测试方法，每种方法都有些适用范围。我们把被测对象分类后，就可以根据分类，来为被测对象选择最合适的测试方法。所以并没有优先级这种说法。

例如，我现在想测试一个网页的收藏夹这个功能，我们首先可以分析，这个功能目前是一个噱头特性？一个销售特性？还是一个老特性？判断出来后，我们就可以根据分类来选择合适的测试方法来启发我们进行探索。有时候，被测对象可能会属于多个分类，这也没有关系，把这些分类里面的方法都过一遍来进行测试就可以了。

问：文章中讲述了测试特性以及测试方法，那么与传统手段相比，例如安全测试、性能测试、接口测试、单元测试、功能测试等，是划分为哪一类？测试方法和它们的关系是什么？是否在选择搜索测试这种方法后，传统的这些就去掉？

答：我们一定要理解这样一个概念，就是探索式测试是一种测试思想。探索式测试并不是一种新的测试方法，和我们提到的那些功能测试、单元测试等不是对等的。我们可以以“传统的测试方式“来进行功能测试，也可以以”探索式测试“的方式来进行功能测试。这点非常重要。并不存在问题中提到的“传统的要去掉”的问题。

问：那么最后做的事情是不是一样的？比如说最后还是要做接口测试或者功能测试？

答：我们该做什么事情，还是就做什么事情。比如测试分层，用例设计，接口测试，功能测试，性能测试等。只是做事情的方式、思路有所不同。

问：传统的测试方法其实就是常规的方法，对吗？

答：不是的，其实没有常规测试方法和非常规方法之说。所有的传统测试方法，都适用于探索式测试。事实上，不管现在团队有没有提探索式测试，大多数测试者都已经做着探索式测试的事情了。

我举例来说明一下。让我们来想想现在我们熟悉的测试活动是怎么进行的。

例如，我们测试一个功能，通过沟通和分析，小张设计了10个用例，并通过了评审。然后测试经理说，小张你的任务就是在这个版本，把这些用例执行了。小张在执行测试用例时，很可能发现这些用例中，有几个是冗余的，并发现一些在用例设计时没有考虑到的测试点。这时，通常情况下，小张还是会把这10个用例执行完。当然小张此时可能会有些心理活动，例如心里觉得不爽，觉得自己干了很多无用功之类。然后在有时间的情况下，小张可能会再去测试一下，那几个在用例设计时没有考虑到的地方。没时间可能就算了，反正也没人知道。

在探索式测试下，小张可以不执行他认为冗余的用例，然后新添加那些他认为漏掉的更需要测试的内容。当然，小张甚至不用一来就设计10个用例，他完全可以设计他认为优先级最高的几个用例，然后再根据测试情况补充测试用例。

相信看到这里，大家已经可以理解探索式测试和传统测试的差别了吧：在探索式测试思想指导下，测试者需要根据上下文（即被测对象当前的状况）来展开测试，然后还要在测试过程中，根据探索的结果再来实时调整测试的内容。

除此之外，探索式测试更强调人和人之间的信任，还有测试者自身的责任感。比如测试经理要信任小张不测试一些内容是基于认真分析的。小张要有责任感，敢于说出来要删一些内容，敢于增加一些内容。

探索式测试并不仅仅是大家想的，有很多新的方法，开拓测试思维什么的。本质还是测试者的测试态度。

问：文章中提到了发散测试和探索测试区别。实际测试过程中在用例测试基础上，很容易思维发散然后就发散测试了，有些确实不知道预期该是什么样子，然后找产品经理确认这种情况下预期是不是这样。当然这可能是用例设计的遗漏。那这种发散测试该如何向探索测试靠拢？

答：在回答问题之前，先明确一下探索式测试和发散测试的概念。现实中我们常常会混淆探索式测试和发散测试。在文章以及前面的问题中，我们已经知道了探索式测试的几个重要要素：

• 基于被测对象上下文进行测试；

• 不断回顾测试结果并由此调整测试；

• 测试前需要分析测试结果和确定优先级；

• 测试者的责任感和测试管理者的信任和放权。

而发散测试可能就是测试者测到某个用例，突然灵光一闪，想试试在XXX情况下系统的反应，然后就测试了。发散测试也是一种基于上下文的测试，但是我们一般不会在发散测试中考虑去调整一下后面的测试的范围或者内容，也一般不会对我们发散测试中的测试点来制定优先级。

因此，发散测试要像探索式测试靠拢的方法就比较明显了：在测试中，不断回顾测试结果并由此来调整测试内容或范围；测试前分析测试结果并确定优先级；测试leader在管理上营造测试者的主人翁精神，并多多放权给测试团队的成员。

问：这么说还有用例设计这个阶段吗？

答：有的。所有的测试活动都适合。探索式测试更强调人的主观能动性、责任感、放权，还有就是测试策略的思想。

这也是探索式测试很难在国内真正推开的原因。国内对探索式测试，还是会以测试补充的方式来进行。安排给你的工作是要做的，做完后再探索一把，多测点，就是这样。

问：这个会有信息同步的问题吗？正常情况下。策略的改变还是要同步给其他同事的，不管是开发产品还是主管什么的。

答：会有信息同步的问题，但信息同步的内容可能没有想象的那么大——因为不是所有的测试细节都需要同步。

问：在敏捷的情况下，业务频繁变化，但是有部分可以复用，如何高效利用这部分数据、用例等？同时，时间能节约多少？

答：针对用例可以这样：基线化用例，建立特性树，维护管理用例，使得用例可以复用。

时间能节省多少，这个可以算。比如人写用例的效率是每人每天写10个用例。你看多少用例复用了后面不用写了，就可以估算了。

问：旅馆区的懒汉测试法，能否举一个实际的应用场景？

答：懒汉测试法就是在少配置，尽量使用默认配置的情况下来进行测试。比如，用默认的用户名、默认的配置文件来测试。

用我熟悉的功能来说，比如vpn。vpn要配置加密套件，有默认的加密套件和默认的拨入用户，就可以用这些来测试。

问：探索测试作为我们组今年的课题，想用它在没有用例的情况下改进过程，请问切入点或者入手怎么做，什么场景或者情况下可以进行探索测试？是测试后期还是根据项目。

答：探索式测试并不等于不写用例，而是一种测试思想。我们平时测试的时候多多少少都有用探索式测试的思想。

还要再强调一句：探索式测试不是说没有用例边写边探索。有用例也可以是探索式测试。

在没有用例的时候，我们当然可以用探索式测试的思维来测试。可以按照文章中的步骤，先确定要测试的范围（全局***那三个），然后确定它的特点（噱头区那七个），然后再选择合适的方法，结合车轮图等来进行测试。

其次写出探索地图。探索地图可以用我上次在GitChat分享的一句话用例的描述方式来进行。

然后在一个执行时间窗完成后，再回顾一下测试项是否需要修改，是否需要继续探索。

在项目中开展，可以在项目任何一个阶段开展，没有一定的要求。不过很多公司会在测试完用例后安排探索式测试。这比较符合现状。你也可以这样考虑。

问：如果结合你上次在GitChat分享的车轮测试法以及这次的探索性测试法，在时间比较短、迭代快的敏捷项目里，应该以怎样的步骤来做测试？（我们一些敏捷项目里一人会身兼多角色。）

答：探索式测试可以和车轮图一起来用的。用起来效果非常好。具体方法和上面是一样的。

问：有没有一些探索性测试方面比较新的好书推荐？

答：《探索式测试实践之路》这本书写得非常不错，推荐阅读。

问：上面的图和梅子文章中的图（下面的图）有差异，应该怎么理解呢？

答：下面这张图是cpie，上面那张图是iape。总体思路是一样的。

不过，文章中这个图有个重要的内容：它有优先级的排序，还有对预期的分析和预判。优先级是根据测试业务需求和产品价值来定的，价值应当优先于分析。而且任何分析都应该有排序。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文：《梅子：探索式测试应用场景实战解析》）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF92DEC000014E36A4CDBA261C32