探索式软件测试助力软件测试人员更高效地测试

因工作需要，由软件开发转为软件测试人员。原本以为测试只是点点看看无须动脑的体力活，但从事了大半年的软件测试工作后，

却发现负责任地测试并不比开发容易，并非是件简单的可以拿起来就做的事情。正如James A.Whittaker在《探索式软件测试》

一书中提到的“它要求有计划、有准备、有策略和有多变的战术，这是成功进行软件测试的前提”。

最近研读了《探索式软件测试》一书，勾起了我许多零散地测试记忆，让我有了写这篇博客的冲动。

最初接到的软件测试任务是对一个刚完成一期开发的电商平台进行手工测试。由开发转测试，并没有师傅带你入门，因为大家都觉得

软件测试任务是上手就能做的工作，无须指导或引导。属于测试小白的我先了解了该项目的软件需求说明书，然后便开始根据每条需

求编写测试用例，然后再根据自己编写的用例测试系统，说白了，就是去验证功能点是否可用的。发现与需求不符的问题就给开发人

员开Bug。待Bug被修复后，再对该功能点进行复测。这样测试，似乎是全面了，因为我觉得测试就是为了验证需求中所有的功能点

都可用。就这样结束了测试任务，项目交付给甲方进行验收测试。一周后收到了甲方的验收测试结果，问题列表中的问题主要分为三

类，一类是浏览器的兼容性问题，一类是功能逻辑问题，还有一类是非常规操作引发的错误。很显然，仅根据需求验证功能点这种测

试方式很容易忽略掉以上三类问题。而依据探索式测试方法则可较为容易地将问题及早揪出来。如破坏测试法会很容易定位到非常规

操作引发的问题。

接到的第二个测试任务是对一个智能园区的项目进行手工测试。该项目包括一个后台及三个APP，算是比较大型的系统了。我们成立

了三人的测试小组，并借助禅道对测试用例及Bug的生命周期进行管理。首先，我们根据功能模块进行编写测试用例的分工；其次，

相互审阅补充测试用例，主要是尽可能多地补充Raining Day的用例，当然有些用例是在测试过程中再做补充和完善；最后，再开展

测试工作。值得一提地是为测试用例创建了版本，这样便于回归测试，也适用于敏捷开发。此外，吸取上次的教训，测试了主流浏览

器的兼容性以及主流品牌手机的兼容性，且关注了逻辑性问题。在项目交付前，我们测试小组依据一百多条Case，找出了约一千条

Bug。但到了甲方质量部那里依旧发现了约三四十条的问题。所幸，严重的功能性问题只有几个，经分析，是后期改需求引发的逻辑

问题，而因时间紧迫，我们并未完整地做好回归测试，仓促地交付势必存在问题。更主要地是我们缺乏探索式测试地意识。

再后来又接手过几个项目的部分测试工作（并未从头跟到尾），逐渐找到了测试的激情，但并未形成自己的一套有效的测试方法，直

到最近看了《探索式软件测试》，才意识到，软件测试也可以有形象且有效地测试方法，而大部分的测试方法在之前的测试工作中确

实有实践过，只是未将其抽象为测试方法。

读完《探索式软件测试》一书后，再回顾之前的测试工作，发现做得并不全面。James A.Whittaker 在书中运用旅行中的词汇比喻探

索式测试类型。将旅行中所涉及到的区域分为商业区、历史区、旅游区、娱乐区、旅馆区和破旧区。再将这些区域映射到被测系统，

从逻辑上划分系统的特性。如商业区对应的是被测系统中的重要特性，历史区对应的是被测系统中的包含、修改或使用遗留代码来实现

的特性，娱乐区则对应被测系统中的辅助特性等。商业区测试类型中又包含多种探索式测试方法，如指南测试法，即按照用户手册进行

测试，发现与手册中描述的不符之处则可认为是Bug（这是Beta测试中主要用到的方法）；商业区测试类型中的极限测试法可用于测试

商城购物中的购物车这一功能。对一个系统做测试，不仅仅是着眼其商业区，也要兼顾到历史区、旅游区、娱乐区、旅馆区和破旧区。

针对被测系统中不同区的特点，选用合适的探索测试方法，更有针对性更有效地发现系统的缺陷或错误，是读了这本书后最大的感触，

当然如何从逻辑上划分不同区，以及如何选用适合的方法，还须在今后的测试工作中逐渐摸索和总结。

从事软件测试工作的人或有意向从事软件工作的人，建议研读一下《探索式软件测试》，可以照亮你的测试之路。