软件测试就像是一场旅行，目的地往往不由我们来定。准备得再充分，也要一试方知好坏。通过圈地盘、找变量、写实例、再探索这四步，可以让我们深入了解探索式测试的精华所在。
每次看到或听到别人问起“怎么做探索式测试？”，或者困惑于功能测试、自动化测试、性能测试和新型的探索式测试之间该如何选择职业道路时，不知为什么总有一种矛盾的感觉，很好笑但又感到一种悲伤。
相信每个已经加入或正在考虑加入软件测试工作的朋友，都曾经有过这样的好奇：软件测试到底是干什么的？大家估计都会到一本叫做《软件测试的艺术》的书里去找答案。然而，当今的软件的含义和应用范围已经远远超过这本书出版的那个时代，时代对测试工作的要求也有了很大变化：软件越来越复杂和庞大，以前不可能测完所有的用例，如今更不可能；以前测试人手很短缺，如今更为短缺。测试自动化则是一柄双刃剑，用得好能做到事半功倍，用不好则很可能会大伤元气；而且测试工作效率、效果的提升，也不再完全由专职测试人员所能决定。
检查已知、探索未知
或许正是在这种情况下，探索式测试走上了历史的舞台，俨然一副测试行业未来方向和救星的模样。目前普遍认为，测试活动其实分为两类，一类是针对已知的情况，而另一类则是针对未知的情况。第一类被称为“检查”（Checking），主要是确认系统是否做到它应该做到的事，主要根据是我们已经知道或已经确信的知识；而第二类则被称为“探索”（Exploring），主要是回答“还有什么是我们不知道的”这种问题，目的在于发现关于系统的新信息或可能存在的薄弱之处。
写到这里，我被心中的一个疑问所吸引：对于我所生活的这个世界，不管是大到整个宇宙，还是小到身边的人，甚至是地上的昆虫，到底是我们已知的更多还是我们未知的更多呢？
当我们接手测试任务时，对于我们即将要测试的这部分代码或是整个软件、系统，到底是我们已经知道的更多还是我们不知道的更多呢？该怎样才能从不知道变成知道呢？
不懂就问，不会就学。
对于所要测试的软件产品或系统，我们怎么也都还是知道一些的，当然也有很多信息是我们不知道但别人知道的。不过即便把所有人都知道的信息全部加起来，对于所要测试的这个软件产品或系统，仍然有很多未知之处需要我们去探索。此外，我们的理解和用户的真正期待是否吻合也是个未知数，更别说在这个快节奏的时代，用户自己的想法也经常地会发生变化。
一场测试的旅行
软件测试就像是一场旅行，目的地往往不由我们来定。旅行之前，我们努力收集目的地的各种信息，包括各种官方或非官方的信息。权威地图固然好，却缺少了很多必要的细节，也无法告诉我们当地好玩的景点、好吃的美食在哪里。驴友的游记虽好，却又过于随意，且带有个人偏好，难以一一遵循。准备得再充分，也还是要到现场去试试看才知道到底是什么样。
这些地图、游记、景点的官方简介，就好比是软件的需求文档，仔细研读，圈出重点，记录下来，就是我们的测试用例。等到了现场，就拿出这些用例逐个执行，检查软件的反应是否如同预期。我还依稀记得当年去黄山旅游，最为惦记的也就是迎客松、光明顶、飞来石这些早有所耳闻的知名景色，以满足我到此一游的感受。这就像是一款软件产品，总有那么一些功能大家记忆深刻，也最不能容忍它出问题。
即便如此，在旅行途中，也会发现其他的惊喜。黄山上游客众多，虽然我并非有意偷听，但也听到莲花峰、天都峰、鲫鱼背这些景点的名字频繁地被人提及，感觉很有名的样子。不过遗憾的是我却不很清楚这些峰到底有什么特点，更不知道它们到底在黄山的什么地方，可我又很好奇想知道到底值不值得去看看。这就好似我们在刚开始测试工作的时候，只知道自己要测试某个软件或某个子系统，却不清楚它们到底是什么。
幸好当时在黄山上附近有很多工作人员，就赶紧找他们去问，这才知道原来莲花峰得名于它的形状，传说是观音将其莲花宝座点化而成，鲫鱼背则是因为极窄而绵长、两侧千仞悬崖的奇险而得名，而且鲫鱼背就是攀登天都峰峰顶的必经之路。后来在下山的途中，还经过了一个很窄且非常陡峭的山间夹缝，经过时前后都有很多人，无暇停步，走完台阶回头一望才发现两边的巨石硕大无比，仿佛整个天空都被它遮住，只有从中间的夹缝才能看到一丝蓝天。再后来，才听人说这个景点叫一线天，倒是很贴切。这样的旅行情况放在做任何测试时，就是总会有些文档有些人可以为你提供很多非常有用的信息，帮助你对所要测试的对象有更多的了解。但也有那么一些功能，是需要我们直接入手操作使用才能有更直观感受的，而这些就很适合采用探索的方式。
游览途中，我还看到很多游客不知道该算是有冒险精神还是不守规矩，总是喜欢往小路上跑、越过栏杆去外面拍照观景，有时候蛮担忧，觉得很危险会出事，有时候又心痒痒也想跟着去。有一年貌似北海大峡谷刚刚开放，还不算是很成熟的景点，而且安全措施也不够完善，可这恰恰激起了我的好奇心很想去看看，纠集身旁志同道合的几位同事就冲了过去。峡谷里景色的确不错，人工雕琢的痕迹极少，游客也不多，不用担心被人打扰，可以随心所欲地停留、欣赏和拍照。只不过，峡谷里的山峰更为险峻，供游客行走的阶梯就好像是横插在山峰之上，大多数还没有栏杆，路面也更湿滑，必须更谨慎地做到“走路不观景、观景不走路”才行。这种情况放在测试中就是一定要提高敏感度。因为软件功能更新很快，尤其是在敏捷开发的方式下就更是每2~4周都会有新东西出来，而这些新功能也是最容易出问题的地方，这样就需要我们在测试的时候提高敏感度，紧密观察测试执行的情况和系统的反应，一旦发现值得深入探究的蛛丝马迹，就要动态地调整后续测试方案迅速跟进。
说到旅行中不满的地方，黄山能挑得出来的就是有需要时附近经常找不到卫生间，到比较大的聚集点才有，而且往往会是人满为患的状态；另外，缆车有时候也会出问题，游客就得走路下山或者上山，这对体力和毅力可是非常大的考验。这种情景就好比任何系统里总会有那么一些公共资源，如果它们数量太少或者总是被少数功能长期占用的话会怎样呢？或者某些临界资源暂时无法工作的话，系统又会怎样呢？
测试第一步：圈地盘
温伯格在《完美软件》一书中已经告诉我们，并不是只有把软件运行起来敲敲点点才叫测试，任何的文档、流程，甚至是人们对软件的理解，都是可以测试的对象。而测试的最好方法，就是问问题。我们接到任务之后的第一件事，就是要问清楚“到底要测什么？”
很久以来，提到要测试的对象，最常用的词就是“SUT”（System Under Test），也即“被测系统”。这个词汇制造了很多的困惑，它似乎意味着我们只需要在系统层级对软件进行测试即可，而系统层级之下还有其他层级，也就有了模块测试、集成测试等一些测试类型的说法，以及黑盒测试、白盒测试方法的区别。
事实上，测试的第一件事就是“圈地”，画出被测对象与非被测对象之间的边界。时间和精力有限，谁也不可能无止境地随便乱测，必须得有目标。我们就想象自己是在绘制一张地图，拿一张大白纸，先把被测对象和相关的非被测对象画出来，接下来可以用不同颜色的白板笔，把被测对象的那条边再描一遍，或者再画一条虚线框将它围起来也行。如果要测试的是整个系统，那么画在图上的内容可能是：被测系统A、配合系统D、配合系统E；如果要测试的只是某一段代码或某一个函数方法，那么画在图上的内容可能是：被测方法a、上层方法b、下层方法c等（如图1所示）。
接下来，就需要摸清楚关于这个被测对象具体要怎样使用。这可能需要花点时间，应该有个故事或者是任务什么的东西把这事记录一下，可以使用一个三段式模板来记录这些信息：
探索 （目标）
使用 （资源）
以图发现 （信息）
被测系统的例子显得有些庞大，我们姑且认为通过一些分析和问问题的过程，决定先从被测系统的“购汇还款”功能开始，方法的例子则选中了sendPhoneValidateCode()。接下来就把前面的例子写下来：
（章程1） （章程2）
探索 购汇还款 sendPhoneValidateCode()
使用 各种文档或问问题 设计文档、源代码，或问问题
以图发现 具体测试用例 具体测试用例
测试第二步：找变量
这种时候，我最关心的是作为一名用户，我想要使用它的功能，究竟该提供什么东西或信息给它，然后应该怎样去检查和接收它的输出或返回。注意，“用户”在这里是一个相对的概念，任何被测对象都有“用户”，但不都是活生生的人，对于某个方法来说，只要是传输信息或数据给它并且期待它执行一些操作甚至返回一些信息或数据的，就是这个方法的“用户”。理解此概念之后，我们就要关注从“用户”的角度来看，到底有什么信息和数据是需要提供给这个被测对象的，以及被测对象应该提供哪些数据或信息告知结果，也即是该被测对象相关的变量。那都有些什么变量呢？测试大牛Elisabeth Hendrickson总结了一份“测试启发法速查表”，接受过她培训的人都知道这张表，在业内非常有名气，如今也被收录进了她的新书《探索吧！深入理解探索式测试》。当然这本书不只是讲变量这么一点事了，她在书中把整个探索式测试究竟是什么玩意儿，可以说全都给抖了个底，非常值得读一读。
废话少说，我们继续讲。关于购汇还款，我们发现，用户需要用户名登录后，才可以查看到自己某张银行卡的欠款金额，然后可以使用某张已注册的银行卡还款，并只可以选择还款方式以及具体的还款金额。罗列出来就是如下一些变量：用户名、欠款卡号、欠款金额、还款卡号、还款卡余额、还款方式、还款金额、结果。
测试第三步：写实例
下一步，就是要摸清楚这些变量各自可能会发生些什么变化，或者说有几种可能的状态。例如，还款方式有全额还款、最少额还款或部分还款这几种，而还款额大致会有小于最低还款额、等于最低、大于最低、带小数点共11位数、等于0、非法字符、0123、123.45678等情况，至于结果则不外乎成功与失败两种。接下来再给它们做一张表格（画在白板上或者是A4纸上即可，不必非得用电子版），选用一些测试数据，把输入和输出之间的关系体现出来。例如图2（此表格是半成品，为未完工状态）。
在填写表格的时候，我们又发现之前的理解还有些不太正确的地方，尤其是询问过一位业务比较熟悉的同事之后，更发现了一些遗漏或者说理解错误的地方。
例如用户的用户名、欠款卡和还款卡的卡号都不是非常重要，或者说并不影响测试效果，但该用户名在系统里的状态、欠款卡和还款卡的状态却会对结果产生影响。这意味着，在准备测试数据的时候，用户名、卡号我们可以随便用哪个都行，但最关键的是要让它们在系统里的状态符合我们的测试需要。
测试第四步：再探索
同时我们发现，欠款卡和还款卡除了几个确定应该可用的状态以外，“其他”状态之下应该都无法成功才对，但具体应该在什么时候失败、以什么方式失败，在场的人都不是很清楚。还有人提到最后的结果还会有一种情况，叫做“未明”，即还款的具体状态不清楚，绝对没有成功也肯定不是失败，可问了一圈，没几个人能说清楚“未明状态有几种以及不同的未明状态如何暴露给用户”。于是，我们决定用如下章程进行记录，以备后续跟进：
（章程3 （章程4）
探索 购汇还款 购汇还款
使用 “其他”卡状 业务规则文档，或问问题
以图发现 惊喜 制造“未明”状态结果的方法
至此，章程1已结束，团队有了一张数据不够完整的实例表，以及新增加的两个章程：章程3和章程4。接下来，团队就会根据各个变量的不同变化，相应地挑选测试数据填入实例表，然后参照执行这些用例即可，也可以直接使用robotframework等一些支持数据驱动或关键字驱动的测试自动化框架直接编写实例表，并转化为可执行脚本。这些工作都是可以实现计划并估算时间的，而新增的两个章程则需要使用限定时间的方式来管理。
