探索性测试（游戏向）

一、前言

  前面的一些文章总结了测试用例设计方法的各个理念与理论知识，学习的过程中也能够参考实战了解大概的应用场景，截止目前而言，对于测试用例设计方法的相关知识就已经结束了，如果大家想要了解可以参阅笔者前面的文章哦： https://kingkou.blog.csdn.net/
  本文将介绍测试人员的必备掌握技能——探索性测试，一起来看看吧~~

二、探索性测试

2.1 什么是探索性测试?

  探索性测试严格而言是一种测试思维的技术方式，抛开了测试计划与测试用例的繁琐与复杂，更加强调策略性，探索性测试明显超出测试范围的场景，是敏捷开发里测试的必备手段

2.2 探索性测试的理念

  探索性测试的理念特点就是在测试的过程中学习测试对象、探索与测试并行

  可以理解为一个陌生的玩法，但你不需要去了解这个玩法的策划案（需求文档），你只需要打开游戏，进入到对应的玩法里直接上手操作，以此来了解玩法的规则，并在了解的过程中结合学习过的测试方法以及玩法规则进行更好的测试，使测试过程更加精致、更具有思想，典型的探索性测试过程如下图所示：

          
  
2.3 探索性测试的过程

  （1）识别游戏目的；

  （2）识别游戏所提供的功能；

  （3）识别游戏中潜在的不稳定的区域；

  （4）在探索游戏的过程中记录关于游戏的信息和问题；

  （5）收集被测对象的更多信息后，加以复测；

  需要注意的是，上述所介绍的测试过程是思维过程，并非执行过程，我们完全可以先收集信息，在收集信息的过程中不断产生新的测试想法，进而延伸测试，也可以按照序号所标识的顺序逐一进行测试，没有严格的流程要求，大致的思维形式如下图所示：

  
2.4 探索性测试 VS 错误推测法

  很多测试同学会把探索性测试与错误推测法混淆，认为两个内容差不多，但其实是有本质上的区别：

  
2.5 探索性测试的优缺点

优点：

  （1）鼓励创造性，发散思维

  （2）探索的时间约长，找到新的、未知Bug的可能性就越大

  （3）可较快速的对被测系统做出一个质量的预估性衡量

  （4）快速暴露出预期体验问题，易用性等

  （5）可变通，有弹性

  （6）不会过于枯燥，丰富有趣，具有多样性，重复性低
  
缺点：

  （1）不容易被协调，团队配合比较困难

  （2）无法对系统进行全方位测试，很可能仍然会存在致命错误

  （3）提供有局限的测试可信度

  （4）非常依靠测试人员的专业知识以及技术

  （5）对于需要长时间执行的测试，不便于使用

  
2.6 探索性测试的应用时机

  （1）测试人员属于行业新手或新入职员工

  （2）需要对程式进行快速的评估

  （3）脚本所发现一些问题需要快速排查确认

  （4）进行组内同学的验收工作或工作支援

  （5）测试团队中有熟悉某一个领域知识的专项或特定领域的测试人员

  （6）项目使用的开发模式为敏捷开发模式

  （7）策划案表述不清或难以理解

  （8）针对一些偶现Bug的深度复现或定位排查测试

  （9）当开发人员有需要进行烟雾测试

  （10）想要扩大脚本测试的多样性，想要进行系统逻辑的深度探索学习

三、探索性测试类型

  针对不同的游戏，探索性的测试类型也可以采取截然不同的方式，以下列举部分主流的方式供大家参考学习：

  （1）自由度探索：自由度探索更在乎自由度，测试人员可以毫无拘束、随心所欲的进行探索，自由度探索中没有任何的规则以及次序，适用于所有类型的游戏

  （2）剧情式探索：针对于一些MMORPG类的游戏，例如天涯明月刀、斗破苍穹等类似的游戏，就可以从剧情入手，由剧情为主干延展各类分支进行探索，过程中可不考虑功能或其他规则限制

  （3）场景式探索：此场景非游戏场景，说明的是根据各个条件与场景的补充，把测试的应用范围扩大到了更改、调整和改变玩家执行路径的范畴，不以人们初始认知的行为和想法开始，换句话说就是不走寻常路

  （4）策略式探索：具备熟练的专业经验、技能为一体，就成为基于策略的探索式测试。它属于自由式的探索，通常测试人员在现有的错误搜索技术、以及已知的测试方法技术中进行结合，来指引测试人员进行测试

  （5）体验式探索：基于玩家反馈的探索式测试缘于自由式测试，测试人员会根据玩家反馈以及游戏评测师的反馈结果，根据反馈内容模拟玩家行为，从玩家的思考点触发进行逐步的系统、玩法探索，能够在玩家的角度，发现到更多的问题

四、实战演练

  探索性测试的难易度较大，要求较高，笔者仍然决定进行一次实战演练，本次讲解采用游戏“梦幻新诛仙”中的法宝系统为大家梳理讲解，让我们先来熟悉一下系统的大致结构吧，如下图所示：





  以上内容就是梦幻新诛仙手游中法宝系统的截图，法宝系统可以理解为对玩家职业具有一定的辅助功效，主要针对于战斗中会提供一些战斗帮助，让我们开始吧~
  （测试人员务必需要牢记，探索性测试是抛开测试方案以及测试用例，在学习、探索、测试三合一的情况下并行执行）
  

  step1：第一步：以笔者的工作情况以及自身需求而言，个人通常会在介入某一个系统前熟悉该系统的规则

  从图片中我们可以得知什么是法宝的类型、法宝的修炼、法宝的血炼、法宝灵力以及灵力的获取等内容，这些内容会在第二步为我们打下更好的探索基础
  

  step2：第二步：笔者会在心中大致把整个法宝系统分为几个子模块

  （1）主动法宝

  （2）被动法宝

  （3）法宝灵力

  （4）法宝交互（装配、卸下、展示、强化）

  （5）法宝规则

  （6）其他交互系统的集成牵连

  
  step3：第三步：会从每一个子模块中验证核心的功能

  比较类似于冒烟测试，但与冒烟测试不同的是，笔者的思想是从子模块进行延伸的，每一个子模块中验证核心功能，而不是整个系统的核心功能

  （这是探索性测试的关键步骤，任何的探索都需要基础功能的保障支持，否则无法进行探索性测试，测试的目的也是为了暴露缺陷，故此进行一次模块核心的“冒烟”是很有必要的~，不仅仅能够查看到功能的实现，还能看到交互的界面表现，也可能为后续的步骤提供一些发散性的思路）

  
  step4：第四步：笔者个人更喜欢使用策略性探索测试方式，在测试前会思考很可能出现问题的点在哪里？

（1）数据的交互，例如消耗灵力注灵、强化法宝

（2）数据的落地，确保每一个内容存储到了数据库并真实保存，且以不可修改的方式存储

（3）法宝触发的概率与数值交互计算，在战斗场景的触发概率、进行的数值换算

（4）部分集成内容，在聊天系统中、战斗场景、跳转场景、跳转链接等方式进入到法宝系统，或提前进入等待触发

  
  step5：策略性方式列举出可能会出现的问题点，在根据这些问题点进行测试

  支援性的测试，通常会进行抽样检查，在某一个列举的可能出现的问题点中，找1到2个并结合测试方法例如边界值分析法，尽可能的看关于边界上的数据问题，做到测试方法与可能发生问题点的相结合进行试探性的测试，进而验证系统的健壮性

  日常的需求测试可以先行考虑到这些问题之后快速进行检查，避免基础功能测试完成后找到发生的问题点再进行改动，过度影响曾经测试过的内容，造成二次问题的发生

  需求不明确或暂时不清楚规则，那么可以结合自身经验对该系统进行一个基础判断，从而快速测试问题点

  
  
  好啦~以上就是本次文章分享的全部内容啦，你学会了吗？希望能给大家带来帮助哦！