游戏测试需要具备的能力

本文参考【美】Charles P.Schultz & Robert Denton Bryant 的Game Testing（精通游戏测试）。根据作者的观点结合实际的工作，我认为确实需要的一些能力，同时也补充了我的一些观点。有些理论实际工作中可能用不到，但是温故知新，在工作中可以给我们一些问题解决的思路和方向。

游戏测试的两条规则：

恐慌和信任：

恐慌和信任对一款成熟的游戏都是不利的。特别是没有游戏测试的新人，在实际的工作中会遇到各种各样的问题，比如对游戏发布前的测试，对自己所负责的模块质量，人力投入，版本迭代快不确认最终版本，过程中怎样去识别可信赖的，可依赖的内容。游戏项目特别是大型的游戏项目，涉及到的开发人员众多，管理和信息同步上并没有那么及时，甚至有时候是各自为战的状态。甚至是一些有经验的同学也会在上面犯错，过度相信合作伙伴，导致后续交付的时候出现问题。我们在实际的工作中是需要去识别，确认，再确认，最后才能做出正确判断。 

     恐慌和信任可能涉及：

1. 测试游戏版本，就好像：

   1. 这不是最后一个版本；
   2. 这是最后一个版本；

2. 可以依赖的有：

   1. 事实；
   2. 结果；
   3. 经验；

3. 不要信任的有：

   1. 道听途说的事情；
   2. 某些意见；
   3. 主观情感；

4. 通过以下方式避免恐慌：

   1. 意识到你需要帮助的时候，去寻求帮助；
   2. 为不可预料的事情做准备；
   3. 依靠工作流程；
   4. 充分的休息；

5. 恐慌给项目带来的损失：

   1. 不必要的返工；
   2. 浪费精力；
   3. 信心和信誉损失；

6. 恐慌会导致如下问题：

   1. 判断力和决策能力下降；
   2. 不可靠的测试结果；
   3. 过于强调短期；

合格的测试工程师：

想要成为一名合格的游戏测试工程师，不仅仅需要会玩游戏，对游戏有兴趣。还需要发现问题的能力，同时具备问题记录，报告缺陷，报告测试进度，以及帮助开发定位和解决问题：

1. 选择性的测试和验证：将精力集中到容易出错的模块和新增模块；
2. 通报问题：通报问题简单讲就是将发现的问题同步给项目。一般在实际的游戏测试中，会有对应的游戏模块的测试负责人。根据实际的开发模式和项目组调性进行信息同步，同步问题的过程中，建议重点突出严重/致命/紧急相关bug。其他的一般性bug（实在太多了，根本同步不完），所以需要根据项目版本的目标进行同步。
3. 放大问题：有的问题需要根据不同的阶段进行放大，才有可能被解决。非常真实且有用的方式，提高问题的严重等级和优先级。开发团队对严重及以上的bug修改率是有要求的，测试同学可以根据bug的影响情况适当调整优先级，会得到项目组的快速反应。当然，也不能乱用此方法（开发同学会冲出来打人的）。
4. 识别问题：识别是不是缺陷，这里我们一般情况下在评审完测试用例后，以测试用例的预期结果为导向，确认是否为bug。实际的项目中，改需求的情况比比皆是，所以在测试过程中存在批量的预期结果出现异常时，最好与对应模块的策划同学确认是否变更需求。推荐给功能测试同学的做法，可以在测试过程中记录问题，然后在集中确认问题。
5. 玩游戏：游戏人，玩游戏是必备技能，通过玩游戏提高对游戏的运营模式，功能，玩法的理解。在结合自身项目的内容可以提出建设性意见，玩家角度和对比竞品的角度下测试产品，提高游戏的可玩性和体验感。这部分算是有测试的软实力，甚至有一些测试场景需要一定的游戏水平才可以触发特定的测试场景。

为什么测试很重要：

测试对于任何一个软件产品都至关重要，关系到产品上线后客户的体验。游戏本身对于用户体验需要更重视，玩家留存决定了一款游戏的成功与否。游戏的质量就显得尤其突出，测试是游戏质量的最后一个环节。这里简单列举一下游戏测试重要的几个点：

1. 游戏软件很容易出错；
2. 游戏软件非常复杂；
3. 游戏中有大量的资金流动（最重要的模块，关系到饭碗）；
4. 游戏必须在多种配置和多平台下运行；
5. 游戏开发同学毕竟是人，难免出现错误；
6. 游戏玩家对高质量的游戏，玩法预期高；
7. 游戏开发平台也并非完美；

其实，不论是游戏测试还是软件测试，本质都是一样的，只是复杂度不同，项目管理方式不同，以及应用到的开发技术和最终上线的运营获利方式各有千秋。但是，开发大方向基本是相同，复杂的项目流程上更复杂，涉及的内容更多元，系统测试成本也更高。

游戏测试阶段：

准备阶段：

1. 计划任务：决定项目所需的测试范围，测试经理会评审【游戏设计文档】【技术设计文档】【项目进度表】，根据以上内容，为发布游戏所需测试资源及数量进行概述，包括游戏完全测试所需时间，人员和资金；
2. 任命测试主管：测试主管是测试经理的副手，测试主管的经验，性格和技能会对游戏的周期和执行产生巨大的影响。因此，测试主管需要具备：
   1. 领导者：能够激励测试团队，能让他们保持专注和高效工作；（吐槽一下，有些测试主管真的不行，也不知道怎么到那个位置的，曾经遇到一个团队几乎所有人都想离职，不愿意呆在项目，原因就是领导力不足。祝愿大家都能遇到一个好的leader，真的太重要了）
   2. 团队的一员：能够意识到测试作为产品的一部分所扮演的角色；
   3. 沟通者：能够清楚，简洁地收集并表达信息；
   4. 外交官：在冲突发生时，能够处理得当；
3. 确定阶段验收标准：测试主管应该尽可能收集相关信息，并为游戏Alpha版本，beta版本和Gold编写一个规范。通过每一个测试阶段建立清晰而明确的准入验收标准，当组织的不同部门感受到压力时，可以避免在项目后期发生冲突。
   1. 准入标准：在进入某一个阶段之前，版本必须通过某一个测试集。
   2. 准出标准：在完成某一个阶段之前，版本必须通过某一个测试集。
   3. 目标日期：开发团队和测试团队都在为特定的发布阶段而工作的日期。【里程碑】
4. 参与游戏设计评审：测试主管或主要测试人员，应该定期参与游戏设计评审。他们的主要责任不是设计游戏，而是与最新的设计变化保持同步，并向项目经理汇报任何可预见的特性修改可能会带来的技术挑战和测试复杂度。游戏范围的变更会决定游戏测试的流程变更，因此，这样的变更测试主管越早知道越容易更改测试计划以适应这些变更。在实际工作中，游戏的复杂度决定了测试主管没有办法通晓所有模块的。通常，由模块测试负责人，功能测试的同学（腾讯模式）参加相关会议。游戏设计本身也会有多个版本的更新，有些是需求部分变更，甚至直接推翻重来的。参加评审的同学需要对变更内容进行梳理，并同步给测试负责人。需求不明确的，测试负责人需要继续推进确认相关信息，直到确认。
5. 建立缺陷跟踪数据库；【提单工具如Tapd，Jira等】，缺陷管理系统基本上都是类似的，毕竟bug提单的必要信息是不可或缺的。在使用tapd(举例)的过程中，需要定义好测试所需的信息的模版，严格要求测试同学提单规范。比如：必要的设备信息，发生bug时的时间，视频/图片，复现步骤，日志文件等。编写缺陷单，要养成简单的语言表述复杂问题的方法，可以结合界面图进行指示性说明。
6. 起草测试计划和设计测试用例
   1. 测试计划：确定团队的目标，以及实现目标所需要的资源（人力，时间，工具和设备）和方法。测试目标一般根据时间的范围来定义。
   2. 测试用例：一般是功能测试用例的编写，一般要求在功能模块转测前完成编写，评审。自动化框架的搭建，为后续的自动化做好铺垫。
   3. 测试套件：

Alpha（内部）测试：

项目经理交付给你一个Alpha版本的游戏，你需要根据你的计划阶段确立的Alpha标准验证该版本。终于，全量型测试开始。

1. 典型的主机游戏Alpha 准入标准：
   1. 所有主要的游戏功能都存在且可以被测试，为了达到测试目的，有些可能仍然处于单独的模式内。
   2. 测试工程师可以自始而终的沿着某条路径导航游戏。
      1. 这里假设游戏是线性的，或者有一些线性的成分。
      2. 如果是非线性的，测试主管和项目经理必须事先对这种游戏的内容完成目标达成共识；
   3. 代码至少通过平台的技术需求清单的50%。（每一个主机游戏都有一套由该平台的制造商发布并测试的标准。）
   4. 基本界面是完整的，且初始文档可供QA使用；
   5. 该游戏与大多数指定硬件和软件配置相兼容，对于一个跨平台主机游戏，这意味着游戏将可以在任何一个目标平台进行最初的商业发布；而对于一个PC游戏，该标准规定游戏必须可以在不同的配置系统上运行。
   6. 关卡脚本已经实现，主要适合单机情景模式。要求测试工程师手动加载关卡的Alpha版本将不符合此标准；
   7. 第一方控制器和其他外围设备正常工作；（控制器和外设要么是平台商自己生产，要么是授权生产，由于平台技术需求清单需要支持这些第一方外围设备，而且大多数测试都是通过第一方外围设备通过测试的，因此，在Alpha测试阶段，这部分设备需要得到支持）
   8. 游戏所有区域的美术必须定稿或者已经占位。
   9. 在线多人联机模式可以测试；
   10. 需要实现声音占位；

Beta（公开）测试：

Beta测试常常指外部测试，但只有在Beta测试早期阶段才应该让设计团队以外的公司员工来进行最终的试玩测试。真正的Beta测试是报告缺陷和负载测试，大部分测试工作是外部的Beta测试工程师来完成的。为了便于后续发布补丁或续集，应该持续将游戏反馈和建议记录下来。在Beta测试阶段的某一个时间点，项目经理应该宣布游戏处于【设计锁定】的状态（有时候又称为【功能锁定】），此时游戏试玩测试已经结束，平衡性问题得到了最好的解决。测试团队【关键任务】是继续针对构建反复运行测试用例来检验迭代版本，因为此时为一个修复的缺陷都有可能会在游戏的其他地方引入另一个新的缺陷。

1. 典型的主机游戏Beta测试阶段准入标准：
   1. 实现所有功能和选项，游戏是【功能完整的】；
   2. 代码通过平台技术需求清单100%，在Beta测试即将结束时，游戏应该为平台制造商的【预验收】做好准备；这个过程允许平台制造商的QA团队根据最新技术需求清单测试游戏，并对任何潜在的合规性问题提出警告；
   3. 游戏可以在所有路径上通过，有可能隔离游戏的各个部分的任何缺陷都要被清楚；
   4. 整个用户图形界面确定为最终版；
   5. 游戏与所有指定的硬件和软件配置都兼容；
   6. 游戏逻辑和人工智能是最终版。【游戏情节】是完整的。游戏规则和所有的人工智能配置文件都是完整的；
   7. 所有控制器都能正常的工作，游戏支持开发团队和发行商选择的第三方外设；
   8. 美术部分制作完成，不存在任何美术占位。在Beta阶段，大多数的游戏截图、预告片和游戏片段都将用于包装和宣传；
   9. 最终音频都制作完成，所有未完成的声音片段都要使用最终素材；（有可能有一些”反工“或”改善“尚未合并，但这些不应影响游戏内的事件或者关卡脚本）
   10. 所有网络模式都是完整的，并可以进行测试的；
   11. 所有语言版本的文本都已经完成，而且为同时发布做好准备。游戏内的语言包都已经准备好，可以灵活转化到游戏的其他语言版本。
2. 在临近Beta测试阶段尾声时，必须做出很多艰难的决定。这时候项目组必须要做出如下重要决定：
   1. 是否实现最后时刻的功能改进。
   2. 是否移除似乎不那么有趣的关卡。
   3. 哪些缺陷可以随着游戏发布出去？
3. 遗漏缺陷：尤其在项目后期，开发团队会确认他们不能再（或不会再）修复缺陷。一旦缺陷不在修复，让团队中的人知道该缺陷不会被修复尤为重要，因为这个缺陷是被放弃的，并不意味着它是一个不合理的缺陷，也不意味着团队成员不应该继续用同样的努力去发现缺陷。测试工程师有义务将有关游戏状态可能的最佳信息提供给测试主管，项目经理和业务部门主管，以便他们做出最佳的商业决定。
   1. 修复过程中的风险会超过缺陷的负面影响；
   2. 技术团队能为遇到缺陷的玩家提供帮助，从而绕过该缺陷；
   3. 根本没有时间修复。

Gold（验收）测试：

1. 一旦Beta测试接近尾声，游戏就应该为发布做好准备。一旦符合发布标准，游戏就会被宣布处于【代码锁定】状态。接着进入一个短暂而紧张的测试时期。预发布测试游戏测试质量的最后一道屏障，发现严重缺陷都需要重新执行Gold测试。
   1. 以下是发布测试的典型准入标准：
      1. 所有已知严重性为一级的缺陷都已经被修复【崩溃、卡死、主要功能故障】
      2. 超过90%的已知严重性二级的缺陷都已修复；
      3. 超过85%的已知严重性三级的缺陷都已修复；
      4. 任何公开的已知问题都有一个与技术支持部门沟通过的解决方案（或者记录在FAQ或者readme.txt文件中）
      5. 以达到发布要求的性能标准【列如，游戏帧率60fps】
   2. 最后一分钟发现的缺陷：测试团最好对情绪化评价淡然处之，并记住游戏开发中不可违背的几个真理
      1. 对于任何项目，都很少有充足的时间找出所有缺陷；
      2. 任何时候程序员修改代码，都可能引入缺陷；
      3. 代码变更随时间积累，几次迭代积累的变更会导致这些上下游产生缺陷；
      4. 临近项目结束时，程序员更加疲惫且容易出错；
      5. 临近项目结束时，测试工程师更加疲惫而且容易遗漏缺陷；
   3. 认证发布：
      1. 对于PC游戏、网页游戏和其他开放平台的游戏，游戏发行商或者融资实体时决定是否发布产品的唯一仲裁者。
      2. 主机游戏，最后把关者是平台开发商（例如：任天堂，微软，索尼或苹果，）他们需要对代码进行最后的认证。这最后的程序验证被称为【认证测试】
      3. 认证测试：
         1. 标准测试阶段，根据技术需求清单测试代码。
         2. 功能测试阶段，测试代码的功能稳定性。
         3. 认证结束：平台商会发布一个缺陷报告，平台商和出版商代表就缺陷进行讨论，双方就清单上必须修复的缺陷达成一致。
         4. 正式版：一旦提交获得平台开发商认证，就被称为正式版。

发布后的测试：

        发布游戏补丁，进一步优化游戏。

“活力团队”：

        团队的建设是从项目立项到发布后运营一直贯通其中的，一个富有活力的团队对项目极其重要。团队建设依赖于领导这的个人性格和魅力，突出一个领导者对于团队的重要性，千军易得，一将难求。团队建设有几点建议：

1. 团队公平，每位同学具有相同的竞争机会；
2. 松紧结合的工作氛围，在项目紧张的时候高效，紧张投入，其他时间做好相对松弛的管理；
3. 提高团队归属感，领导者一身作则，带头模范；
4. 适当的团建活动，创造团队沟通娱乐环境，增加团队信任和建立良好友谊；
5. 人员技能储备/业务覆盖备份，提高团队健壮性，允许团队人员寻求更好发展，但不会影响项目本身进度。
6. 团队人员技术技能特长梳理，以及工作内容从事倾向，内容适当满足相应诉求；
7. 领导者自省，需要回顾自己做的好的和做的不好的，及时调整方向。

游戏的测试流程：

黑盒测试：

        黑盒测试是从应用程序的外部进行测试的，玩家通过一系列的输入，然后检查对应的输出情况来判断输出是否符合预期。黑盒测试是基于用户，功能，体验的测试。

适用于黑盒测试内容：

1. 游戏设备输入输出的直接游戏反馈，基本功能测试；
2. 游戏UI，动画，声音，震动等；
3. 游戏性能测试；
4. 兼容性测试；
5. 压力测试；

白盒测试：

        白盒测试是从代码层进行的测试，测试工程师可以看到一段游戏代码，通过执行代码逻辑预测执行结果。从测试难度上白盒测试门槛更高，需要具备预读代码的能力。

适用于白盒测试内容：（白盒测试概括起来适用于多平台，宏定义，全局可调用模块或方法。原因：具有这样属性的代码从逻辑功能上来说是非常明确且清晰的，在整个游戏中调用率高，采用黑盒测试去覆盖成本很高。通过白盒测试从底层逻辑上验证正确性的性价比和可靠性都相对更好）

1. 在开发工程师提交新的代码和其余游戏代码集成前，由开发工程师执行的测试；
2. 被测试的代码模块是跨多个游戏或平台的可复用的代码库的一部分；
3. 被测试的方法和功能是游戏引擎或中间件产品里不可缺少的部分；
4. 被测试的代码模块可能会被第三方开发工程师或”游戏改编者“所使用。“游戏改编者”可以通过自己的喜好对游戏行为进行扩展或者修改；
5. 对用于支持最新的硬件设备（如显卡或音频处理器）中特定的功能的底层模块进行的测试。

构建的生命周期：

1. 基本的游戏测试流程：
   1. 规划和设计测试：每一次构建都会或多或少有不同的测试重点，我们需要根据实际的形况对新的构建进行规划和设计，以满足于该构建的目标；实际的项目组，会有多条流水线，负责构建不同目的的包体。一般情况下，分为主干流水线和分支流水线两种，主流水线是每天新增功能和修改代码在当天都会直接合入的流水线（开发流水线），其他分支流水线，则是基于相对稳定的功能拉出来的流水线，其目的是为了提高相对稳定的包给测试或者开发同学验证功能使用。
   2. 测试准备：代码，测试，文档和测试环境由各自的负责人来更新并相互协调。开发团队需要对已经修复的缺陷进行标识，测试团队根据修复情况对这些缺陷进行验收，并关闭缺陷；（测试内容确认：测试包体，测试服务器，测试内容，预期交付时间）
   3. 执行测试：在新的构建版本上执行测试套件，并详细记录测试过程并收集缺陷信息；
   4. 报告结果：记录已完成的测试套件并上报你发现的任何缺陷；
   5. 修复缺陷：开发修复缺陷过程中，测试团队需要和开发团队进行讨论沟通缺陷，执行定向测试，为开发工程师跟踪缺陷提供线索；
   6. 回归测试：新的一次构建，重复上面的步骤。

测试用例和测试套件：

准入标准：

1. 游戏代码构建没有编译错误；
2. 代码发布说明应该是完整的，应该提供给测试工程师一些细节，他们可以用来规划哪些用例或者在这个构建上重新运行哪些测试用例；
3. 新版本中关闭的任何缺陷都应该在记录中更新，以便测试工程师可以参考它们来决定在新版本中运行多少测试用例；
4. 测试和构建应该有合适的版本控制；（版本控制：跟踪构建过程并确保开发团队的所有成员将代码和素材提交到当前版本中的过程称为版本控制）
5. 检查媒体提供的游戏是否包含你将提供给客户的所有文件。

配置准备：

1. 是新版本开始测试前的后勤工作，适配主管必须和测试工程师沟通合适的硬件配置。
   1. 新增配置或首次测试：配置准备需要提前沟通好，比如：首次支持网络，新增输入设备等
   2. 测试中：一般情况下配置准备好，过程中是很少变化的。
2. 新构建对于不同的游戏需要初始化测试环境：
   1. 网页游戏：应该从每个浏览器的缓存中清除，并且应该在你打开新的游戏构建之前重启浏览器；
   2. iOS游戏：应该从IOS设备，以及计算机上和iOS设备同步的iTunes客户端中删除。确保完全删除后将新的构建复制到测试环境中；
   3. Android游戏：与iOS游戏一致，需要完全从设备和计算机中卸载。

冒烟测试：

在收到新的构建，正式测试之前需要对新的构建进冒烟测试，确保该构建版本值得进一步测试。目前自动化技术还是相对比较成熟的，一般冒烟测试可以使用自动化实现。手动冒烟测试根据自动化水平和覆盖情况进行灵活补充即可。

回归测试：

回归测试的测试套件是一张游戏开发认为已修复的缺陷列表【回归列表】，一般情况可以通过缺陷数据库得到。（回归测试做好bug不能完全修复的心里准备，做好二次回归计划，甚至三轮回归的准备。）在实际项目中，在制定测试计划的时候关于回归最好预留两轮回归时间（经验之谈，哈哈哈）。

围绕一个缺陷做测试：

测试报告编辑之前，请先问自己一些问题。下面这些问题都是你可能被测试主管、项目经理或开发工程师问到的问题类型。

1. 这是缺陷发生的唯一位置或者关卡吗？
2. 使用其他的角色或单位时缺陷是否还会发生？
3. 在其他的游戏模式（例如：多人游戏和单人游戏，小战役和大战役）中缺陷是否还会发生？
4. 我能省略掉复现缺陷路径中的任何步骤吗？
5. 缺陷是否在所有的平台都会发生？
6. 是否时特定机器上的缺陷？

               这类问题时常被提到，往往测试任务紧张的时候是不可能做到面面具到的。所以，提单 了就等吧，有些问题开发可以直接定位问题，这样的就不需要在上面花费太多时间。特别的需要进行复现，确认以上信息。有些时候需要注意，策划同学的测试需求（可能是他们自己的工作内容），项目紧张时可以拒绝。一般情况，将此类事情交由测试的领导统一收口，不接私活。当然和策划关系好另当别论。

写好缺陷报告：

缺陷报告即Tapd，Jira提单，对缺陷进行有条理的记录。因为，你永远不知道谁会阅读你的缺陷报告，所以你需要尽可能的清晰、客观和冷静的方式来写报告。即使一个对游戏不熟悉的也可以很清晰的知道问题所在。

1. 缺陷单的预读者并非只有游戏开发，还有如：
   1. 测试主管或者主测，他们可能会在缺陷追踪数据库中对缺陷进行评审；
   2. 项目经理，他们会看缺陷单并将其分配给合适的开发团队成员；
   3. 市场人员和其他业务主管，他们可能会被要求衡量缺陷修复（或不修复）可能带来的商业影响；
   4. 第三方（如中间件开发工程师），他们可能会被要求评审缺陷，而这个缺陷可能与他们提供给项目团队的项目相关；
   5. 客户服务代表，他们可能会被要求设计出绕过缺陷的方法；
   6. 其他测试工程师，如果在回归测试期间要求验证缺陷是否已经修复，他们将按照步骤去复现。
2. 缺陷单遵循以下原则：
   1. 实事求是：在编写测试报告前，你必须确定你掌握了所有的事实。
   2. 简要描述：一般简要描述就是缺陷报告的标题；
   3. 完整描述：复现步骤和具体缺陷说明；
   4. 期望结果：在进行复现描述中，缺陷不明显需要增加预期结果和实际结果来对缺陷进行说明。明显的缺陷表现就不需要再描述了，减少不必要缺陷描述。
   5. 避免习惯：尽量避免太专业的术语，缩写，因为阅读你的缺陷报告的人可能并不具有这样的专业知识。

使用数据量度测试：

测试指标可以告诉你测试工作和测试结果的效率和有效性。测试工程师或主管可以根据这些量度指标来帮助规划、预测和执行游戏测试。

指标收集和原始数据：

1. 测试进度表：测试团队每天完成的测试数量，每天需要完成的测试数量
2. 测试完成度/测试天数：完成的测试数，每个测试工程师的测试天数；
3. 测试参与度：每个测试工程师的工作天数，每个测试工程师分配的测试天数；
4. 测试有效性：缺陷数，每个版本或测试工程师总的测试数；
5. 缺陷严重分析：每个版本的每一种缺陷的数量；

测试进度：

如何有效的对测试进度进行评估。

1. 首先，测试经理或测试主管需要对整体的工作任务进行评估，然后通过对实际执行的工作量和时间信息进行收集。
2. 通过一段时间的数据采样进行数据评估，计算出工作量与时间的关系。
3. 随着测试的深入，缺陷的积累需要对工作量与时间关系进行调整。
4. 尽量在前期每天多做一点测试工作，减少深入测试的压力。

测试有效性：

将所有缺陷数量除以完成的测试次数来度量测试有效性

测试工程师表现：

1. 可以设计一些量度手段来激励测试工程师，并使他们为自己的技能感到自豪。
2. 组合测试：配对组合测试是一种在游戏软件中找到缺陷并活得信心的方式，同时保持最少的测试集合以覆盖最多的功能。【配对组合】意味着你用于测试的每一个值至少需要与其余参数的其他值组合一次。
   1. 参数：是组合测试中所包含的游戏的各个元素。你可以通过查看各种类型的游戏元素、函数和选项来查找测试参数，如：
      1. 游戏活动；
      2. 游戏设置；
      3. 游戏选项；
      4. 自定义选项；
      5. 硬件配置；
      6. 角色属性；
   2. 值：
      1. 默认值；
      2. 枚举值；
      3. 范围；
      4. 边界值；
   3. 构建组合表：

测试流程图（TFD）：

是从玩家的视觉表示游戏行为的图形模式

元素：

1. 流：由一个状态到另一个状态的带箭头的线，箭头指向为变化后的结果；
2. 事件：是由用户，外围设备，多人网络或内部游戏机制发起的操作；
3. 操作：表现为对某一事件做出暂时或过渡的行为，对测试工程师而言，这是导致或执行事件时要检查的结果；
4. 状态：表示持续的游戏行为，并且是可重入的。用带有唯一名字的【气泡圈】来描绘一个状态；
5. 图元：事件、操作和状态也被称为图元；
6. 输入输出框：【IN框】通常指向一个状态流；【OUT框】通过有一个或者多个状态流指向【OUT框】

随机测试和游戏可玩性测试：

1. 随机测试：
2. 游戏可玩性测试：游戏可玩性测试涉及对游戏本身的主观判断，而不是客观事实：
   1. 平衡的艺术：
      1. 具有挑战性，但并不会让人过于愁眉不展；
      2. 入门容易，但要达到高阶就必须持续地玩；
      3. 简单但并不简化
      4. 复杂但不会让人觉得莫名其妙；
      5. 较长但不会太长
   2. 游戏平衡：不同单位之间的大致平等状态
      1. 近程战士与远程战士；
      2. 盗贼与魔法师；
      3. 狙击步枪与火箭发射器；
      4. 魔族与人族；
      5. 植物与僵尸

外部测试：

外部Beta测试：

1. 封闭式测试：
2. 开放式测试：