游戏自动化测试指南（上）

所谓自动化测试，就是模拟手工测试步骤，通过执行程序语言编制的测试脚本，自动地实施产品的单元测试、功能测试、负载测试或性能测试等。

本次《游戏自动化测试指南》将会分2期推送，上篇着重介绍一下自动化测试框架的搭建，下篇将会和大家探讨一下自动化测试用例脚本的编写和自动化框架的其它应用。

01 前言

1.1 什么是自动化测试

测试工作中，很大一部分需要依靠手工进行，对于游戏产品而言，手工测试有着不可替代的意义，可以在操作游戏的同时，直接观察到游戏产品的行为是否正常，玩法的趣味性等。但其所带来的人员开销也是必不可少的，况且不能保证100%不会出错。而自动化测试，可以将一部分测试工作从手工中解放出来，用代码来代替人工执行，用以提高测试效率。

自动化测试的应用场合：

1.适用于流程比较稳定的场合，比如基本功能、主线任务、日常任务、系统类玩法等等，这类功能流程一旦确定，后期大改可能性较小，在一定程度上能避免自动化测试脚本反复迭代的工作，自动化最忌讳的就是需求不稳定，频繁的变更会导致自动化测试用例的维护成本直线上升。

2.适用于流程比较复杂的系统或者手工成本太高，比如主线任务，所涉及到的任务类型多、整体流程繁琐，人工测试费时费力，寻找某些种类缺陷时效率并不高，可能覆盖不全或者忽略了部分重点，采用自动化测试的方法能很好地规避这类问题。

3.适用于高可用性的场合，也就是尽量不会出错的场合，在游戏中，存在一些功能有一定的容错机制，比如弱网下的状态就不太适合采用自动化的方式来测试。

4.需要频繁执行回归的测试，游戏的生命周期一般都比较长，通常会有多个版本持续发布，每次版本发布都会有大量的回归测试需求。当然如果是短期的一次性项目，从技术上讲自动化测试的可行性很高，但从投入产出比考虑通常并不建议使用自动化，比如像节日活动这类玩法。

游戏的开发周期是一个高效开发、快速迭代的过程，游戏系统相对来说都比较复杂，面对如此快速开发的产品，自动化测试的意义主要体现在：

1.无人执守，自动执行；

2.回归测试中，可以快速验证版本的稳定性；

3.避免重复测试；

4.节省劳动力；

5.监控版本的性能数据。

通常情况下，自动化测试流程一旦形成，除了上班时间以外，可以充分利用下班后的空闲时间、空闲机器自动执行测试脚本，充分利用资源来保障产品质量，日后的测试工作便可以高效循环进行，这是产品长期回归测试的高效方法，可以避免在产品上线或交付的最后一刻，还深陷软件问题的泥潭中。

万物皆有阴阳两面，尽管自动化测试有诸多好处，当然也有它的劣势。主要有以下几个方面：

1.对测试人员要求相对较高；

2.自动化测试的开发、测试结果分析、测试脚本编写及维护有一定的维护成本；

3.自动化测试用例也分“好”、“坏”，测试结果不一定100%准确。

所以产品组做到多大程度“自动化”需要根据各个项目组的具体情况来决定，切不可盲目追求自动化。

02 自动化测试框架的搭建

自动化测试框架，可以理解为，驱动所有测试用例持续执行的一套流程。这套流程从项目组打包就开始了，直到产出测试报告，全程由代码自动执行。自动化测试框架，可以由项目组内自己搭建，也可以借助合适的第3 方工具完成。接下来会介绍这两种不同的方式。

如果由项目组内搭建，测试框架的灵活性、可扩展性更高，不过对组内人员的代码要求也更高。若借助第3 方工具，比如网易自研的Airtest Project，可以在短期内快速搭建一套完整的测试框架，在用例的编写上，对测试人员的代码要求相对较低，可以脱离项目组的产品代码独立存在。至于采用哪种方式，可以根据各个项目组的人员配置、项目组的具体情况来决定。一般来说，如果是项目组内编写的框架，分为这样几部分：外围流程搭建、服务器框架搭建、客户端框架搭建。如果使用第3 方工具，参考官方文档即可。

2.1 外围流程框架搭建

外围流程，是指与测试用例的具体执行无关，但又是自动化测试过程中必不可少的步骤，比如测试包的下载、安装、启动、进入游戏、用例日志的收集、上传、分析、报告的生成、发送等等。一般来说，包括如下步骤：

图2.1 外围流程图

上述流程图，称之为自动化测试的外围流程，与用例执行不同，外围流程不需要依赖产品代码，属于纯人力操作转为代码执行的过程。该流程可以使用各自擅长的语言来开发，只要能保证整一套流程完整运行下来就可以。每一步操作大致如下：

1）检查build 版本是否完成

build 版本结束后，有包体才能开始测试，所以第一步需要检查build 版本是否完成。一般来说，项目组里的打包，同一个版本，服务器包会更早完成，客户端的包会晚一些，当然，特殊项目组、特定打包除外。因此，与服务器包相关的操作可以优先进行，待客户端出包后，再进行客户端相应操作。

2）部署自动化测试的服务器

服务器包打好后，代表可以进行服务器的部署了，客户端包打好后，代表可以进行客户端包的相关操作。在进行服务器部署时，有的项目组可能需要去下载相应的服务器包，再部署自动化测试服务器，部署好后再启动服务器。有的项目组，服务器包的下载、服务器版本的部署、启动服务器等功能绑定在一起，这几步操作可以一起执行，直到服务器成功启动。

3）下载客户端并解压

待客户端打包结束后，会将包放在特定的目录下，这时根据服务器的版本号，找到对应客户端包体，下载、解压缩即可。

4）启动客户端进入游戏

待客户端包体下载后，如果用例要运行在手机端，还需要进行包体的安装，后面第四部分会介绍手游自动化测试的差异性。

接下来，启动客户端，进行登陆操作，进入服务器。登陆操作，根据不同项目组产品代码架构的特点，会有些许差异。例如有的项目组，在进到登陆界面时，客户端和登陆进程的连接就会建立，此时登陆操作可以通过客户端产品代码UI 结构上的点击、输入等完成登陆操作，也可以直接调用登陆相应的接口；而有的项目组，在初始的登陆界面，客户端和登陆进程并没有建立连接，也就无法通过服务器向客户端发送协议的方式来完成登陆，这种情况下，可以通过增加额外客户端登陆代码来实现登陆。与此同时，外围流程会增加代码替换操作，将新增的客户端代码进行打包再替换。或者另辟蹊径，将登陆绑定在一个特定的操作上来实现。只要能实现登陆自动化，无论采取哪种方式都是可行的。

5）执行自动化测试用例

成功登陆，进入游戏后，可以开始执行用例了，这部分会在接下来框架搭建里详细介绍。

6）收集用例日志、分析、生成报告

自动化测试用例执行过程中，会产生一些日志，这里的日志，包括文本日志、游戏截图、游戏录制视频等等。由于自动化测试用例的执行过程无人执守，可以通过分析用例执行过程中生成的特定日志来判定一个用例是否运行成功。

有了日志分析结果后，需要将分析结果展示给项目组的同学，让大家知道当前版本运行用例的情况，结果展示要求尽可能做到清新、简洁、明了。在项目组上班之前给出当天要用版本的报告，以便在第一时间发现版本中的问题。目前雷火这边，由测试日志生成测试报告的过程，可以由各个项目组根据具体情况来决定格式和展示方式，不过为了数据展示的美观和统一，也可以借助MTL 或者平台组来设计相应的展示界面。下图2.2 为倩女手游项目组的日常自动化测试报告，报告里会展示出测试时间、测试的版本号、测试平台、用例总数、总的运行时间等信息，并且会详细列出每个用例的具体执行情况。

图2.2 自动化测试报告

外围流程基本不涉及和产品代码相关的内容，接下来会详细介绍框架的搭建，如果项目组内开发框架，可以参考2.2 小节；如果使用第3 方工具Airtest Project，可以参考2.3 小节。

2.2 项目组内框架搭建

组内开发自动化测试框架一般分为两部分：服务器和客户端，服务器端为驱动引擎，用来控制、调配用例；客户端一方面作为两个用例间的连接桥梁，另一方面，需要实现用例在客户端执行期间可能涉及到的功能需要。

2.2.1 服务器框架搭建

为便于理解，以倩女服务器架构为例来介绍服务器框架，下图2.3 为倩女服务器的简易架构，先简单介绍倩女服务器的各个服务器进程：

图2.3 倩女服务器简易架构

master 进程：中央调度进程，负责整组服务器集中控制，每组服务器只有唯一一个master进程，主要提供全局信息的检索和管理。鉴于master 进程这些特性，会将用例的管理、调度、分配等放到master 进程上来处理，避免多进程下状态异步的问题。

gas 进程：负责处理具体的服务器端游戏逻辑，会与master、DB 等进程保持连接，通常一组服务器会有多个gas 进程。用例具体的执行逻辑会放到gas 进程上，通过gas 进程，将用例脚本发送给相应的客户端(gac)执行。

gac 客户端：游戏客户端，比如手机、PC 等等，玩家操作都是在客户端，所以为了更真实地模拟人工测试，通常测试脚本会在客户端执行。

用例的驱动过程：当一个新客户端gac1 登陆进入游戏，gac1 会向gas 进程发送请求，表示gac1 现在空闲，可以执行用例。gas 收到gac1 的请求后，会向master 发送请求，表示gac1 现在空闲，请求执行用例。master 进程收到请求后，在本进程上查询用例状态，找出下一个需要执行的用例，并将用例名返回给gas 进程。gas 进程拿到用例名后，将测试用例脚本发送到gac1 的客户端执行。同样地，当一个客户端执行完用例后，依然会向gas 进程发送请求，表示我现在空闲，可以执行用例，以此循环，直到所有用例全部执行。

框架搭建初期，可以使用一个客户端，逐个执行用例。随着用例积累，整体用例运行时间会逐渐增加，以倩女手游为例，如果使用一台机器逐个执行用例，所有用例一轮跑完需要50 小时左右，而每天至少会对一个日常版本进行自动化用例回归，总时长显然无法接受。所以在框架设计之初，最好能提前考虑多客户端并发执行。目前倩女手游这边，每次会启动10 个客户端同时执行用例，能大大缩短测试时长，让项目组同学尽早看到测试报告。

2.2.2 客户端框架搭建

自动化测试用例的脚本，可以运行在服务器端，也可以运行在客户端。运行在服务器端的脚本，主要是通过接口来测试，从客户端发起的这部分逻辑验证会被忽略。针对功能验证的自动化测试用例，更建议用例脚本运行在客户端，通过模拟用户操作的行为来测试。

编写测试用例之前，客户端需要提前实现以下几部分功能：其一，日志系统；其二，模拟用户操作的各类接口；其三，性能数据采样接口。

一般来说，游戏产品会有自己的日志系统，产品的日志系统更多用来服务游戏产品本身，进行信息记录以及BUG 定位等，通常不太适合用来分析测试用例。根据自动化测试用例的特点，自己开发相应的日志系统，测试用例的日志系统不用太复杂，轻量级即可。

为了能更有效分析用例运行情况，回放出错用例执行过程，日志系统会包括文本日志、报错日志、游戏截图、游戏视频等等。文本日志用来记录用例运行期间产生的有效日志，在用例执行结束后，可以通过扫描日志知道当前用例的执行情况，比如执行时间、执行时长、用例名、日志级别等等。执行时间和执行时长通过记录日志的时间点来获取，用例名在记录日志的时候一并写入，日志级别需要根据用例执行过程中有可能出现的情形来区分。游戏运行期间产生的报错，能及时捕捉并放入测试分析中。

另外，在拿到测试报告分析失败用例，很多时候单纯依靠文本日志的分析，并不能完全定位原因，事后若能回放执行过程，往往更容易复现当时的测试场景，可以在用例执行期间，定时进行游戏截图或者直接录制游戏视频。游戏截图和视频录制对分析固然有用，但也需要注意在手游中的应用尺度，如果大量产生截图和视频，存储空间很快用尽，势必会影响用例的执行。

编写用例之前，需要实现人工测试中所有可能出现的操作接口，比如单击、双击、输入、拖拽、获取值等等。实现这些操作后，再指定相应的操作对象，就可以完成从人工操作到代码执行的转换了。

在实现这类接口时有两种方式，一种是纯用户操作模拟，以单击为例，向屏幕某个点，发送点击操作，后面提到的Airtest Project 为这种方式，可以更真实的模拟用户操作。另一种是从控件出发，让UI 上的某个控件响应某个事件（比如单击），采用这种方式，单击事件一定会成功。

比如下图2.4 中，界面有确认框，如果此时想要点击包裹，正常人工操作，必须先点击确认按钮，关闭确认框，再去点击包裹按钮。使用Airtest Project 的操作流程同人工操作一样，而这时如果让包裹的UI 控件直接响应单击事件，一般情况下，无论有无确认框，包裹面板均会打开（当然这里也和程序产品里实现的UI 响应事件有关）。unity 引擎中提供了响应某个事件（单击、输入等等）的接口，可以直接使用，使用之前，需要注意，相应的接口产品代码是否重写过。

图2.4 确认框

执行测试用例期间，记录各项性能数值，比如FPS、内存、网络流量等等，有助于分析版本潜在的性能问题。每个性能数值会有不同种类的计算方法，可以根据项目组的需要来记录，比如内存，可以记录整个游戏运行期间进程的内存变化。在生成用例报告的时候，将这些性能数据一并制成图表，可以与历史数据对比，设置一定的阈值进行预警，协助产品组发现问题。

实现了以上三部分内容，客户端相关框架已经完成，可以开始尝试编写测试用例了。

2.3 第3 方工具airtest 框架搭建

Airtest Project 是网易自研的一套自动化测试框架，这套框架采用图像识别和UI 树结构的技术，可以通过编写少量代码，甚至不用手动编写任何代码，就可以完成一个自动化测试用例，容易上手，学习成本低，编写用例操作也很简单。

Airtest Project 内部有两个框架：一个是Airtest，这是一套基于图像识别的UI 自动化测试框架，该框架的使用逻辑很简单：在编辑器上选择相应的操作，比如“click 点击”，截取需要点击按钮的图片，就可以实现点击某个按钮的操作。系统会通过图像识别，在当前UI界面中寻找截图所在的位置，然后在屏幕上发送一个click 的操作（注意这里的click 是完全模拟真机的点击）。操作虽然简单，但缺陷也同样存在：比如当前UI 界面中存在两个同样的截图；再比如很难进行非UI 操作或者逻辑验证。另外，图像识别有时候会有误差，Airtest会提供一个可选的精准度，这个值设得太高，容易出现误判，比如画面突然出现某个特效；精准度若设得太低，容易把一些非正确的图像区域筛选进来等等。

另一个框架是Poco，基于UI 树结构，类似于unity 里UI 树结构。根据unity 里控件的路径，来指定操作的对象。相比Airtest，这种方式可靠性更高，只要找到了正确的控件，不会出现图像识别不准确的问题。Poco 获取路径很方便，可以一键获取操作的元素。相比在unity 里纯人工找控件会方便许多。

Airtest Project 使用和操作起来都很方便，接入和使用官网提供了操作指引，可以参考官方文档：https://airtest.netease.com。Airtest Project提供了一些基础框架，有一定的局限性，比如无法进行逻辑验证，可以根据各个项目组的具体情形二次开发。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。