【游戏测试专题】自寻探索式测试

来源：好游戏攻略时间：2024-11-28 00:40

游戏测试也就是我们俗称的QA，ta们是游戏上线前的守门员，我们今天邀请到了一位网易游戏雷火的游戏测试大大来和大家交流探讨一下游戏测试中的“探索式测试”。欢迎大家与我们探讨交流

开始讲解探索式测试之前，先来和大家谈谈传统软件测试。下图是一个最基本的测试流程1：

QA同学应该都很熟悉这个完美的流程，但是也不得不承认受限于现实工作中的各种状况，这个完美的流程只存在于理想中。我的上一份工作虽然也没法完全严格的按照这个流程来做，但是也算可以勉强坚持做到七八成的样子。

可是入职网易作为一名游戏QA之后，随着项目玩法功能的丰富，自己负责的模块越来越多，迭代也越来越频繁。为了适应游戏测试的工作节奏，我的工作习惯慢慢转变成了一种“不符合常规测试流程”的方式：

在项目初期，我不再花时间去做深入的测试分析，不再去写详尽的测试用例。了解功能、测试设计、测试执行几乎变成了同时在进行。测试重心会随着项目进程发生变化，比如项目前期我不再抓着一些细节BUG不放。

虽然这个方法不是那么的“光明正大”，但是最终的测试质量和测试效率倒是意外的不错。所以这两年间我在一种纠结的情绪中坚持使用并优化着这种测试方式。

几个月前了解到了“探索式测试”，惊喜的发现这个概念与我的测试方式有诸多相似之处。我开始查阅相关书籍和网上的资料，发现其中部分内容可能有些颠覆认知，部分内容可能有些难以理解，部分内容可能并不一定能直接应用到游戏测试中。为了能够更好地理解这个概念，看这些资料的时候我会不断的问自己一些为什么，然后再结合自己之前的经历与感悟回答自己的问题。

下面我把这些自问自答整理出来。如果你未接触过探索测试并且测试工作也遇到了瓶颈，希望这个文档可以带给你一些启发；如果你也像我一样误打误撞使用了探索式测试，希望这个文档可以帮你整理思路排除疑惑；如果你是一个熟练掌握探索式测试思维的老司机，希望可以一起进行探讨共同进步。

温馨提示1：为了提升阅读体验，建议不了解探索式测试概念的同学至少先看一下百度百科的词条介绍。

温馨提示2：探索式测试初看起来像是一个很玄学的概念，但我觉得其实它有很具象的内涵，建议配合自己的工作经历来看待它。

注1：为了方便展示我剔除掉了诸如用例评审或回归失败等情况的节点，以及其他职能工作的节点。

一、探索式测试概念介绍

如果你去搜索探索式测试的概念，可以得到类似的答案——探索式测试是一种强调测试人员的主观能动性的测试思维，让测试人员可以同时设计测试和执行测试，测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多关于测试的设计。下面针对这个定义，谈谈我的理解。

1.1怎么理解探索式测试是一种测试思维？

类似面向对象或面向过程的概念，它们本身并不是工具，而是作为思维模式来指导开发。同样探索式测试，它本身并不能直接拿来发现BUG。但是测试人员可以在各种软件的测试中通过这种思维模式的指导，选择合适的技术或工具，开展黑盒测试或者白盒测试，提高测试效率的同时确保软件有更高的质量。比如我会在探索式测试的过程中，学习各种玩法的用例设计方法来提升自己的用例场景覆盖率，也会麻烦测开同学或者程序同学帮我写一些GM命令或者小工具来提升测试效率。

1.2如何强调QA的主观能动性？

可以把传统测试比作跟团游：

我们的行程是预先设计好的，去哪些景点、每个景点玩什么项目、每个项目玩多久等等吃住行的细节都是固定的，甚至可能是风雨无阻的。不感兴趣的景点耗费了不少时间，感兴趣的景点反倒没有时间深度游玩，天气不好甚至还要硬着头皮出门。一趟旅行结束，可能只剩糟糕的体验。

相对的探索式测试就像是自由行：

旅行前——我们会预先确定目的地（待测试模块），也会提前做一下攻略（需求分析，了解竞品），预定酒店和车票（里程碑节点），但是攻略不会像跟团游那样精确到细枝末节（不需要完整的测试分析和用例）。

旅行中——我们在感兴趣的景点中可能会多做停留（重要功能或不稳定功能），不感兴趣的景点少做停留甚至砍掉（次要功能或稳定功能），具体娱乐项目或餐厅点单也可能是临时决定的（鼓励QA发挥主观能动性）。如果假期充足（上线期限）或者天气变化（开发进度受阻，需求变更），我们还可以改签酒店或者车票（重新安排测试计划）。

旅行后——我们会觉得这次旅行虽然带有小小的遗憾（测试不可能发现所有BUG），但是我们这次旅行的目的基本达到（排除了发布风险，确保了产品质量）。

越是有经验的测试人员使用探索式测试越能发挥更好的效果，因为他们清楚与其对着后面必然会被改的面目全非的设计文档编写详细的测试计划，不如省下时间轻装上路，在实际探索的过程中发挥自己的主观能动性，制定更符合当前情况的测试策略，让测试工作可以更贴合实际的开发工作。

1.3如何理解概念中软件学习、测试设计、测试执行“同时”进行？

去网上搜索“探索式测试”基本都可以看到上面这张图，其中学习、探索、测试三个步骤是“同时进行”的。但是依照我的理解这里并不是指真正的“同时”，只是相对传统软件测试而言这些步骤更像是并行的，分别从周期和流程两方面谈谈我的理解：

从周期上来讲，传统软件测试会在软件学习、测试设计、测试执行这三个阶段分别投入比较多的时间。而探索式测试并不要求测试人员在模块开发前就花大量时间完成全部内容的学习以及深入的测试设计，测试人员可以在模块中的每个功能点做好后只用很短时间就可以完成一轮软件学习、测试设计、测试执行。

从流程上来讲，传统软件测试中软件学习、测试设计、测试执行是分阶段顺序执行的。而使用探索式测试的测试人员，可以在学习待测试功能后直接去软件中通过实际操作来强化理解，也可以在执行过程中发现了用例设计之外的状况再去完善设计。在探索式测试中，学习、设计、执行三个步骤不再有明确的界限。

综上，对软件学习、测试设计、测试执行会在短时间内互相切换，这样快速的迭代起来，从宏观上看起来它们就像是“同时”在进行。

二、关于探索式测试的“自问自答”

了解了探索式测试的概念，疑问反倒更多了：探索式测试看起来很随意？用例还要不要写？测试质量是否有保障？会不会很难应用到工作中？这一节会针对这些问题谈谈我的理解。

2.1 探索式测试、传统测试、即兴测试有什么关系？

传统测试——测试人员按照软件测试流程，按部就班的做测试工作。

优点：这个测试流程很完美，如果执行下来可以确保不出大差错。

缺点：需要相应的开发流程制定与执行，否则直接生硬套上的传统测试流程并不能很好的执行下去，质量得不到保障的同时QA同学也容易感受到挫败。

即兴测试——是指没有准备、随性而发的BUG搜索过程。

优点：没有门槛，谁都可以去做这个事情，有时还会打破测试人员的固有思维，发现测试死角的BUG。

缺点：缺乏测试理论的支持和明确的目标，导致发现BUG的效率并不高。而且往往因为随性而发，就算发现了BUG也很难复现。一次测试过后，可能不会产出可以留存下来的经验。

关于探索式测试，我觉得与其说是一种全新的思维方式，更像是传统测试和即兴测试按一定比例混合而成，而且QA同学可以根据实际情况充分发挥自己的主观能动性去调整这个比例。

比如在做冒烟测试的时候，我会先“随性”的去尝试各种方法使用这个功能，在这个过程中发现BUG，同时学习了解需求文档中可能并未说明的内容。但是这种“随性”是依赖于测试技术以及测试直觉的，避免漫无目的的浪费时间；是会先进行设计再去执行的，避免发现BUG又无法复现的尴尬。

相应的，功能稳定后的探索式测试中传统测试的比例就会提高了。

探索式测试，在我看来保留了测试技术支持的同时又可以充分发挥测试人员的主观能动性，让QA的测试工作可以更柔软的贴合现实中的开发过程，让测试质量得到保障的同时测试过程也更有乐趣。

2.2 前面提到，探索式测试不在测试初期花时间去做完整的测试分析或写详尽的测试用例。那么完整的测试用例是否还有必要？

先说答案，在我看来完整的测试用例很重要、很重要、很重要。

游戏软件并不是那种交付完了就完事儿的软件，测试工作基本会覆盖游戏的全生命周期。这个生命周期中玩法会迭代，人员会变动，甚至作为模块负责人的我们自己也可能会忘记细枝末节的功能。这种时候原始需求文档是必然靠不住的，零散的需求单也难以整理，最可靠的还是QA产出的完整的测试用例。既然完整的测试用例很重要，那么这份用例怎么来呢？

上文提到，探索式测试会让QA可以在很短的时间内就完成一轮软件学习、测试设计、测试执行，每一轮的测试设计过程就会有用例产出，最终整个大的模块测试完成时，完整的用例设计也就完成了1。

注1：这个具体操作见下文讲解。

2.3 模块处于不同的阶段时，探索式测试的重点有何不同？

关于这个问题的答案，《探索式软件测试》一书的作者给出了很好的解答，结合我的理解整理如下：

早期开发阶段，探索式测试的目标应该是为了“发现设计缺陷”，“发现被误用的设计”以及“发现与用户使用逻辑的矛盾”。这些目标让探索式测试更注重于把事情做成而不是以某种独特的方式做事情。

对于游戏开发初期，给出一个可供体验的demo是首要任务，玩法调优、配置铺量、美术资源都不是必要的。这个阶段QA的探索式测试像是一次“开荒”，在全新的玩法中趟出一条通畅的主流程。这个过程中QA不必花心思设计太过细节的测试方案1，如“玩法奖励是否合理”，“武器是否穿模”或者“每日任务的难度是否过大”这些后期方便调整的问题。省下的精力除了确保玩法的完整和通畅，还应该更多的思考如“玩法是否考虑了奖励投放”，“是否留有根据不同主角体型调整武器尺寸的字段”或者“每日任务是否考虑了刷新时间设置”这些可能对未来功能完善造成影响的隐患。

后期开发阶段，探索式测试的目标应该是为了“确保产品功能可以正常工作”，“确保用户数据的安全性”，“确保完工的软件符合要求”，“确保功能满足适用的范围”以及“确认以前的缺陷不再重现”。这些目标让探索式测试更注重于以一种特定方式来探索某一个特定的功能。

对于游戏开发后期，上线就是最终目标了。QA同学需要在原来探索的主流程上针对分支再开展深入探索。此外兼容性测试、压力测试、性能测试等也需要提上日程了，当然最后的回归测试也不能少。确保最终上线时玩法的质量没有致命问题的前提下，细节问题尽可能的少。

注1：这里并不是鼓励QA同学无视细节BUG，而是要视项目进度来调节测试的颗粒度。我个人认为，前期提的一些细节BUG对于产品最终质量并不会起到太大作用：一方面这些细节问题的复现场景可能会在后续玩法迭代中被删掉；另一方面前期项目开发目标是“能玩”而不是“好玩”，太多的细节BUG会阻碍开发同学的进度，也会让开发同学觉得QA同学与他们的目标不一致导致不愉快的合作关系。建议QA同学根据项目进度调整测试的颗粒度，前期将时间更多的用来思考潜在的隐患，避免后期铺量后会造成隐患扩散引发更多的BUG，后期再将注意力转移到探索细节问题上。

2.4 上面提到需要将一个大的模块拆成小的功能点进行探索式测试，这个如何进行？

这个问题涉及到两个点“如何拆分”以及“拆分后如何进行探索式测试”。

如何拆分：

拆分细的功能点可以简化分配测试资源和跟踪测试进度的难度，这个方法其实在传统测试中也会用到，每个QA同学应该都有自己的习惯，这里讲一下我的方法，供大家参考。

进行模块拆分时，我的原则是“保证拆分后的功能点仍然完整的前提下，尽可能的独立”。以主角动作为例：

一方面要确保待测试的功能是完整的。比如跳跃功能需要包含跳跃UI交互、主角动作资源、以及程序功能支持。我会等相关需求都完成后再进行测试，这样可以让我的探索过程不至于因为功能未实现受到阻碍，影响测试效率。当然 “跳跃UI可以点击”也是一个功能，但是它缺少实际的测试意义，也没有太多可测试的内容，我会放在跳跃功能中一并测试节约时间。

另一方面要确保待测试功能是独立的。比如“跑步中跳跃”，我会先分别对独立的跑步功能和跳跃功能进行测试。这样可以让我学习了解功能的难度更低，也可以让测试设计与执行更容易开展。（关于功能点之间交互情况的测试会在下一个问题中讲解。）

拆分后如何进行探索式测试：

与传统测试相同的部分是都会从用户使用角度出发设计基本的测试场景。但是，不同点在于，探索式测试不要求测试人员一次性设计出尽可能多的测试场景（我一般会准备两三个最基础的测试场景就开始动手执行）。那么如何确保最终测试设计的覆盖率？我觉得很重要的一个点是探索式测试强调测试人员及时处理“反馈”，并以此做出下一步探索的计划。还是以跳跃这个功能为例：

我设计的第一个基础的测试场景就是“点击跳跃UI，主角播放跳跃动作”。如果发现主角并没有正常播放跳跃动作，那么就需要针对这个“反馈”开始“探索”背后的原因。我会怀疑是不是这个体型的动作资源缺失，是不是主角有什么特殊状态，是不是受到当前地形的影响等等。基于这些怀疑，一方面我可能需要向开发人员请教相关设计以及排查手段，根据他们的“反馈”加深对软件的学习；另一方面我还会补充设计如“不同体型跳跃”，“定身状态下跳跃”，“水中跳跃”这些测试场景。

当上面的问题解决后，再检查当前已有的测试设计是否还有遗漏，基于检查结果的“反馈”去设计新的测试场景如“连续快速点击跳跃UI”或者“跳跃的高度”。如此形成学习、设计、执行的快速迭代，逐步覆盖对跳跃功能进行“探索”，直至评估自己的测试设计已经覆盖全面。

2.5 仅对单一功能进行测试，会容易漏掉功能间交互时才会表现出来的BUG，探索式测试如何覆盖不同功能之间交互的情况？

回答这个问题，还是接着上面跳跃功能的例子讲讲我一般是怎么做的：

第一点，之前的探索中肯定会发现一些与其他功能交互的情况，如“跑步+跳跃”。这类测试设计可以在上一步想到的时候就记录下来，然后在测试模块间关联情况时进行执行。

第二点，需要结合自己对游戏的理解以及测试的经验进行测试设计，如思考是否可以和游戏内的重要模块进行交叉测试，针对战斗模块就可以设计“跳跃+受击”或者“跳跃+使用技能”的测试场景。

第三点，保持交流沟通，学习其他QA同学的分享或者向开发同学请教设计意图与代码实现，他们的讲解或者提醒也会成为重要的测试线索。

第四点，可以依靠听起来有点玄学的“测试直觉”，比如我觉得跳跃动作一定可以通过某种方式卡死，那么我就会开始设计各种场景去尝试达到这个目标。这个方法虽然不一定百分百会奏效，但是也不会让我空手而归，就算不能达到“动作卡死”这个目标，也会在这个过程中发现其他问题。

总结一下，个人觉得功能间交互的探索方式与单一功能本质是类似的，也是需要依据各种“反馈”作为探索的灵感来源。但是随着功能交互的复杂度提升，要求测试人员将自己的各种测试技能发挥到极致。测试人员需要不断丰富自己的测试经验、保持交流沟通、磨练自己的测试直觉，才能在更复杂的情况中探索的更深远。

2.6 部分资料中提到探索式测试模式下测试人员的设计可以写的笼统一些，方便测试人员在执行的时候留下更多自由发挥的空间，使用稍有变化的测试路径可能会发现一些遗漏的BUG。这么说测试设计是不是不用涉及太多细节？

我个人并不赞同这种说法，原因有两点：

首先，我认为探索式测试只是不强制要求测试人员在测试执行前就绞尽脑汁去做高覆盖率的测试设计，但是测试人员需要在测试的过程中基于反馈逐步完善测试设计。

其次，探索式测试确实鼓励测试人员在执行的时候跳出原有的测试设计去探索新的测试路径。但是探索式测试也要求测试人员避免测试工作的“健忘性”，及时将新探索的路径记录下来，否则这次探索可能就会变成无法复刻的即兴测试。

所以说，并不是说为了发现更多的BUG，所以故意把测试用例写的笼统一些。而是要在确保用例设计尽可能完善的前提下，还保持这探索精神去探索更多的测试路径。

补充说明：我自己确实会用一种“笼统”的用例写法，在不降低覆盖率的情况下减少用例的体量以及日常执行的负担，就是在用例备注中列出所有可能的选项，然后在每次执行时轮流使用不同的选项，达到一段时间内全覆盖的效果。如：任务确实会因为主角体型导致一些问题1，但是如果用例根据不同体型的主角分别写一遍会显得很冗余，执行起来也比较耗时，最重要的是这类问题出现的概率可能并不高。那么我会在用例中备注写明“请在任务执行中随机变化体型进行测试”，或者“日常测试执行注意轮流使用不同体型测试”，甚至可以注明“日常测试中单号日期用男号，双号日期用女号”。

注1：如“对话镜头高度没有适配”，“主角被地形卡住”等。

2.7 定义中提到探索式测试中测试工作是和软件学习同时进行的，那么最初需求文档出来后软件还未开发前，没有待测试的软件探索式测试是否就无法开展？QA是否还需要深入分析了解需求文档？

先说答案，深入的需求分析很重要、很重要、很重要。

需求阶段发现的BUG是极具价值的，可以避免后面项目开发走弯路，节省一系列的开发成本，这是不争的事实。既然有很高的价值，那就有必要去做。不过这么做的话是否和探索式测试理论矛盾呢？

翻阅的资料中并没有明确探讨过这个问题，不过可以说说我的方式供大家参考：

一方面，需求分析的时候我会在脑内模拟软件的实现，并设计并执行用例，思考逻辑矛盾的地方。

另一方面，现在游戏行业完全创新的玩法并不是很常见，竞品中可能就已经包含了需求文档中的部分内容。所以如果需要进行软件的学习，竞品就是一个不错的选择。

当然，上面的过程是在探索式测试思维的指导下进行的。

2.8 看起来探索式测试有点随性，与QA严谨的态度不太相符，实际使用中是否有效果？能否很好的确保产品质量？

先谈一下我自己的实际数据，去年初到目前近两年的时间内，我关闭的需求单总数是组内正职功能测试人员平均数的1.86倍，新建BUG数是组内正职功能测试人员平均数的1.56倍。测试质量和测试进度得到了一起合作的其他职能同学的认可，在几次对内对外测试中我负责的模块没有出现严重问题。当然这个数据不只是探索式测试的功劳，还与工作安排技巧和交流沟通技巧有关。这里只谈一下关于探索式测试带给我比较直观的感受吧。

首先，探索式测试优化了我写用例的时间消耗。第一，把完整详细的用例设计工作后移，可以让我在前期有更多时间进行实际的测试工作。第二，开发过程中模块调整必然会连带着需要调整用例结构甚至删除用例，探索式测试可以很大程度上规避这种情况造成的时间成本浪费。

其次，看我的数据会发现BUG单的倍率是低于需求单的。如2.4中介绍，不同时期的测试重点不同，前期我并不会花时间去挖掘细节的BUG。相应的，省下的时间我用来思考潜在的隐患，避免后期铺量后会造成隐患扩散引发更多的BUG1。因此，这样既减少了前期开的BUG数量，也可以减少后期开发产生的BUG数量。此外除了节省自己的时间，也可以节省一起合作的开发同学的时间。还可以避免因为一些琐碎的BUG影响我与开发同学之间的合作关系。

第三，探索式测试是一种小步快走的测试模式，在敏捷开发的大环境中，QA可以更快的响应开发工作，并且有更多时间进行实际的测试工作，最大可能避免需求单的积压，可以跟上快速且并发的开发节奏，不至于让测试工作成为项目开发的瓶颈。

第四，探索测试中一个重要环节就是“软件学习”，这一点鼓励QA与开发同学保持沟通，除了让QA可以更深入的了游戏功能外，还可以提升QA与开发同学配合的默契度。这个默契度在我看来是很宝贵的，让我和一起合作的开发同学们可以更高效的工作，工作效率甚至可能会高于由各种强力人士组成的临时团队。

最后，探索式测试可以充分发挥QA的主观能动性，依赖QA的测试经验以及测试直觉。在每一轮的学习、设计、执行中去更有风险的方向探索，发现更有价值的BUG。因为每一轮的探索周期比较短，QA的努力可以很快的得到反馈，激励自己不断提升测试能力，让下一轮的探索更深入、更快速。

2.9开展探索式测试的门槛会不会很高？

虽然可能之前没有了解过这个概念，但是看到前面的内容，你可能会发现自己已经在不知不觉中或多或少的使用了这种测试思维。就像前面说的探索式测试只是一种思维，在我看来入门难度并不高，但是难度在于怎么做好，探索式测试的效果非常依赖测试人员的能力。测试人员的测试设计能力、问题分析能力、时间安排能力、沟通表达能力等等都会影响到探索式测试的效果。如果你是测试新人，那么我有这几点建议：

首先，建议熟练掌握更多的测试技能。对于一个新的玩法，条件反射的就会清楚这类玩法需要考虑哪些测试点，坑点一般会埋在哪里，什么时候需要开展性能测试、兼容性测试。长此以往，测试直觉就会越来越准，能够快速决定出探索方向，减少无用的探索。

其次，建议合理安排自己的工作时间。把工作合理拆分，然后利用探索式测试小步快走的特性填充碎片化的工作时间，这样才能充分发挥探索式测试提升效率的特性。

最后，建议提升自己的沟通技巧。无论探索式测试“学习”“设计”“执行”中哪一步，我们都不可避免的要频繁与一起合作的同学们进行沟通，掌握良好的沟通技巧是必不可少的。

不过技能不纯熟也没关系，探索式测试鼓励测试人员边学习边测试，如果过程中发现自己不太会处理反馈那就去学习如何分析问题，如果过程中发现与开发同学合作不愉快那就去学习沟通技巧。所以在我看来，只要你能设计出一条测试路径并保持探索精神，那么就可以愉快的出发了。

2.10 如果是有一定经验的QA同学，打算开始或者已经开始了探索式测试，需要注意哪些问题？

首先，要避免漫无目的或重复的测试工作。起初有的时候我会在自己设计好的测试场景中兜兜转转很久但是一无所获，最终就会变成在游戏中漫无目的乱点。意识到这个问题后，我做了几件事情：

第一，我会按照2.3中说的分析当前的测试重心应该是什么，再按照2.4中说的方式拆分功能降低测试设计的难度，最后再按照2.5中说的逐步掌控整个模块的测试工作。

第二，当面对一个玩法无从下手的时候，可以先尝试从玩家角度出发设计探索的主要路径。如果是时间线性的玩法（如打副本），那就思考玩家的常规操作流程。如果是基础功能的玩法（如技能），那就思考玩家的使用场景。然后再在此基础上进行更深入的探索。

第三，这种情况目前我还是无法完全避免，但是现在它对我来说就是一个信号，告诉我要停下来，分析是测试方向不正确还是测试方法不正确，然后重新调整我的计划。

其次，要让自己的探索过程留下痕迹。我之前有一段时间负责游戏内十来个战斗单位的测试工作，包括他们的“模型”、“动作”、“培养”、“技能”等，其中技能测试是最复杂的部分，要考虑“主动还是被动”、“是否有CD”、“单体还是AOE”、“伤害技能还是加血技能”、“音效”、“特效”等等因素。工作中我发现虽然测试过好几个技能有了一定的测试经验，但是当开始一个新技能的测试时还是会漏掉一些边边角角的测试点。另外因为这种游戏内单位数量较多，还分配给了组内其他几个QA同学一起测试，他们的测试设计中也包含了我一直都没有考虑到的情况。

为了解决这个问题，我开始总结Chesklist，比如对于技能，测试工作都需要关注技能的“数值”、“效果”、“培养”、“特效”、“音效”等情况，那么我们就可以针对这些测试点做一份技能的Checklist。再和其他QA同学一起评审完善这份Checklist，之后当一个新的技能需要测试时，我只要依照这份Checklist就能基本完成主要的测试工作，省下的时间就能去更好的探索这个技能独有的一些细节。除Chesklist外，各种坑点总结与测试技术分享对我们这种团队测试的模式来说同样很重要，这些经过提炼记录下来的文字就像是地图，把一个QA的探索经验变成团队的探索经验，再在团队探索经验的支持下让每个QA可以探索的更深入。

最后，要让探索式测试把自己的测试工作变得不无聊。我听到过一些QA同学抱怨测试工作很无聊，也有一些其他职能或者行业外的同学问我测试工作是不是很枯燥。当我还是一个测试萌新的时候，发现一个BUG就会让我很有成就感，但是渐渐的测单子、开BUG变成了平淡的日常工作。为了让工作有一些乐趣，我开始将注意力转向测试工作中一些更有创造性的事情上：如何做出更明智的测试决策、设计性价比更高的测试方案、应用新的测试技术或概念。恰巧探索式测试的短周期特性可以更快的反馈出自己的成长与不足，让我有动力去做下一轮探索。

2.11 探索式测试与自动化测试或者AI测试的关系？

探索式测试是测试思维，而自动化或者AI是测试工具，是两类概念，所以并不存在冲突。这两方面我都不是专家，简单谈谈我的理解：

先说自动化测试，自动化测试主要负责的是“测试执行”这个步骤。但是自动化维护成本较高，对于处于频繁迭代中的模块来说性价比不高。另外，让自动化脚本包含更复杂的执行步骤以及更全面的期望检查也需要测试人员投入更多的精力。但是编写检查基础流程的自动化脚本相对来说成本较低，再配合资源检查脚本可以很好的帮助QA同学排除掉那些低价值又反复出现的BUG带来的干扰，让QA同学可以有更多精力去设计更多有价值的测试场景。

至于AI，现在使用AI玩游戏已经是一件很常见的事情了，但这都是在让AI在游戏中找到“一种获胜”的方式。如果应用到测试工作中，首先需要让AI可以找到尽可能多的测试路径，目前已经有一些软件训练AI通过识别UI并进行点击，去探索不同功能界面之间切换的测试路径（我们的伏羲也在做相关的工作），但是对于复杂的游戏操作，如何更有策略的探索尽可能多的测试路径还是一件比较困难的事情。另外，我看到过一些视频中AI最终学会的是使用BUG来通关，这说明教会AI判断各种游戏表现是不是BUG显然要比教会AI什么是胜利困难很多，目前最常见的做法是在AI探索测试路径的过程中收集软件的报错，此外利用语音识别以及图像识别也可以让AI判断一些简单的表现是否正确，但是更复杂的情况仍然需要更多的研究。

虽然可能还很遥远，但是我对技术改变测试的前景还是很看好的，也欢迎各位大佬来一起探讨。另外，教会机器如何探索测试前，我们测试人员也可以先强化一下自身的学习。

三、我的探索式测试

这一节主要讲讲我自己对于探索式测试的理解，以及我自己是如何在测试工作中使用探索式测试的。

3.1 作为游戏QA，我对探索式测试的理解

常规软件的开发一般是基于甲方的需求或者市场的需求进行设计开发的，更像是满足用户需求的“工具”，从一开始它的设计目的就比较明确。游戏软件的设计则是在对市场口味的揣测过程中进行的，这个设计目的并不是很明晰，比起“工具”游戏更像是一件“工艺品”，在这件“艺术品”的打磨过程中对设计频繁的推翻再重建是在所难免的。需求的频繁迭代、需求单描述的不完善、开发流程的不理想、测试时间的不断压缩，这些都是我在游戏工作中的日常。我面对的第一个问题就是游戏测试工作开展的大环境并不理想。

作为QA大家应该清楚就算是一款功能简单的软件我们也很难列举出全部可能的执行路径，更不要说一款包含五花八门玩法的游戏了，可能的路径几乎可以说是无限多的。每一条路径上都可能埋着BUG，所以一款游戏的BUG是不可能被全部发现的。如果可以在游戏上线前排除掉所有可能会造成严重影响BUG的前提下，修复了尽可能多的细节BUG，那么可以认为这款游戏的测试质量已经是很不错的了。那么如何在“有限”的时间内，从“无限”的路径中选取有价值的路径来执行，这就是我面对的第二个问题了。

结合我的感受，探索式测试可以很好的解决了我在游戏测试中遇到的上面两个问题：

一方面，探索式测试在我看来是一种很务实的测试思维：它不鼓励直接硬套传统测试流程直接到开发流程上，导致测试工作难以开展。它也不是即兴测试，让测试工作变的漫无目的且没什么技术含量。它没有回避软件开发中流程中的“不理想”，而是鼓励QA同学积极面对这些“不理想”，充分发挥自己的主观能动性在有限的时间内，对这些“不理想”做出最优的决策1。

另一方面，探索式测试小步快走的模式也很贴合我们很多项目采用的敏捷开发模式。它让QA可以更好地为软件开发助力，而不是成为软件开发的阻力。同时也可以避免QA为了配合敏捷开发而造成过多的测试成本浪费。我想部分QA同学和我一样会不自觉的被“逼”上探索式测试这条道路，也是因为它与敏捷开发的契合特性。

在我看来，探索式测试解决的是“测试工作”的问题，而不是“测试技术”的问题。 “测试技术”的问题还是需要靠各种技能和工具来解决，不过这个过程可以在探索式测试思维的指导下进行。

注1：这里我要表明立场，面对不合理的流程，QA有责任也有义务去推动优化这个流程，不能听之任之，逆来顺受。流程本身的BUG，不仅不利于测试工作的开展，也不利于产品的健康发展。

3.2 下面讲讲我自己在工作中开展探索式测试的方式。

这算是对全文的总结，也是我目前的工作方式。

首先，需求文档出来后，我会在三方会议之前把文档分析一遍，当然是用探索式测试的思维指导来进行分析的，同时也就在思维导图上划分好了用例的大概框架。这么做一来可以充分发现需求中的潜在问题，也可以让三方会议的效率更高一些。

（这部分涉及到：2.7中提到的文档分析方式。）

之后，来到开发初期，这段时间我会去熟悉竞品（实际体验或者云体验），了解这类玩法玩家可能会在哪部分重度体验，哪些地方逻辑复杂或容易出现BUG，这都是后续开展探索式测试的方向。此外，还需要关注开发进度，与开发同学沟通，尽可能分段提交功能，让我可以更早的介入测试，这样可以降低测试难度，也会缩短整个开发周期。当然，这段时间还要安排好其他模块的测试工作。

（这部分涉及到：2.7中提到的文档分析方式的延伸；2.5中提到的拆分功能点的部分操作。）

接下来，游戏功能开始一个接一个的不断完成，我也在“学习”“设计”“执行”循环中跟进完成我的测试工作。此时测试重点在于“发现设计缺陷”，“发现被误用的设计”以及“发现与用户使用逻辑的矛盾”。测试工作先从拆分后的独立功能开始，之后再考虑这些功能间的交互情况。

（这部分涉及到：2.3中提到的项目前期的测试重点；2.4中提到的模块拆分测试；2.5中提到的模块间关联测试；需要关注2.10中提到的注意事项；需要借助如2.11中提到的资源检查、自动化等工具避免低价值又反复出现的BUG带来的干扰。）

来到开发中后期，开始玩法细节打磨。这时依然是使用小步快走的探索式测试跟进每一次改动。这期间测试重点转向“确保产品功能可以正常工作”，“确保用户数据的安全性”，“确保完工的软件符合要求”，“确保功能满足适用的范围”以及“确认以前的缺陷不再重现”。这时除了关注模块本身，还需要将探索的范围进一步扩大，更多的考虑这个模块与游戏其他功能间交互的情况。

（这部分涉及到：2.3中提到的项目后期的测试重点；2.5中提到的模块间关联测试的延伸；需要关注2.10中提到的注意事项；需要借助如2.11中提到的资源检查、自动化等工具避免低价值又反复出现的BUG带来的干扰。）

功能完成后，就可以开始把思维导图上的用例搬运到平台上了，这部分工作我有时会自己来做，有时也会安排给我们可爱的新人来做，这个工作对于新人来说是学习测试设计与用例编写的好机会。

（这部分涉及到：2.2中提到的用例编写的重要性。）

四、总结

到这里，本文就差不多结束了，写这篇文章的目的主要为了分享一下我关于探索式测试的理解。探索式测试除了指导QA对待测试软件探索外，也在指导QA对自身潜力的探索，鼓励QA“不择手段”的去把测试工作做得更好，无论是学习测试理论也好，开发测试工具也好，包括整理这篇文章的过程中我又有了新的收获，也希望这篇文章能给你带来一点帮助。如果大家关于测试方法有什么自己的观点欢迎一起讨论。