《游戏测试》-第１２章

１２.１

游戏

ＵＩ自动化测试简介

１２.１.１概述ＵＩ指的是用户可以用肉眼看到的页面，不论是Ｗｅｂ端还是移动端，ＵＩ层自动化测试的原理都是一样的，就是基于页面元素的识别和定位来进行模拟用户行为。首先识别到某个元素，如一个按钮，然后定义一个动作，如单击，这样就通过代码模拟完成了一次按钮的单击，代替了人工去单击。如果后期再加入数据驱动和ＰａｇｅＯｂｊｅｃｔ思想就基本形成了一个ＵＩ层自动化测试框架了。现在许多游戏项目要么跳票严重，要么发布时Ｂｕｇ多多，当然，这样的现象并不仅存于游戏行业，然而，游戏是软件开发复杂性的最佳代表，不同技能的人需要协同工作，这也就是某些人所说的游戏项目中高风险因素所在。软件项目延期、Ｂｕｇ满天飞和失败的原因是多种多样的，但看起来除了随产品特性不断变化之外，测试和品质管理是永恒的问题。经过长期的观察，相当多的游戏开发工作室完全依靠人工的方式来测试游戏引擎、开发工具和游戏代码，几乎没有采用自动化测试。下一页返回１２.１

游戏

ＵＩ自动化测试简介

人工测试不仅不够全面和彻底，同时还会花费很多时间。代码在修改或添加之后，它应运行预定义的人工测试集来保证修改不会产生新的问题。人工测试花费的时间越来越多，并给开发者带来挫折感，打击他们执行测试的积极性，而且，测试的工作量使得开发者不愿意改进或优化现有的代码。同时开发者测试他们自己的代码时，总是潜意识地不愿执行最苛刻的测试用例，因此就导致了上述测试行为出现了不仅容易出错而且测试全面性很差的情况。因此，我们决定采用自动化测试，游戏自动化测试是指在无人工直接参与的情况下，计算机按照特定的测试需求执行游戏测试的技术。通过自动化测试技术可以自动执行大批量的测试用例，也可以完成某些手工测试难以完成的测试操作，从而节省了人力、时间和硬件资源。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

１２.１.２为什么要做游戏自动化测试这里的游戏自动化测试，更准确地说就是游戏功能自动化测试，趋向于验证逻辑。验证逻辑是指验证ＱＱ是否登录成功，验证到了好友列表，就是登录成功，甚至有登录成功的日志都可以。自动化测试可以解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。此外游戏自动化测试还有以下优点。１.提高测试效率自动化测试执行用例的速度比手工测试更快。２.更快、更早地发现Ｂｕｇ自动化测试可与人工测试同时进行，快速完成回归测试工作，帮助项目更快、更早地发现Ｂｕｇ。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

３.更好地利用资源将重复的测试任务交给程序处理，将测试人员解放出来进行体验性测试和探索性测试，如此将产生更大的价值。４.提高测试质量自动化测试是通过脚本进行检测，可避免人为疏忽出现低级失误而造成严重Ｂｕｇ漏测。５.降低测试成本自动化测试具有一致性、可重复性、可复用性，可大大降低回归测试的成本。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

１２.１.３游戏自动化测试的缺点不同情况下，有的自动化测试目标比较容易达到，而有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高，测试人员必须充分理解自动化测试，从而通过自动化测试不断发现软件的缺陷。因此，在开始自动化测试之前应该先了解游戏自动化测试的主要缺点。（１）需要花费一定的时间去编写和维护脚本，脚本编写的质量与维护成本是成反比的。脚本编写投入的时间越少，相同情况下后期投入的维护成本越高，如果脚本是依赖录制得来的，那么维护成本将大大提高。（２）对测试人员的水平要求较高。（３）对于需要主观判断测试结果的操作，自动化无法实现，目前的游戏自动化测试还无法做到完全智能地测试，如测试界面是否人性化。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

（４）脚本本身比较死板且完全依赖测试用例，用例的质量在很大程度上决定了脚本的质量。（５）不能像手工测试那样发现全面且灵活地测试，有些Ｂｕｇ自动化测试无法发现。所以对于“游戏自动化测试应该覆盖所有的测试点”这种观点是很难实现的，应该合理分配游戏的测试点，对于不适合自动化测试的部分不能强行使用。１２.１.４游戏自动化测试的前提（１）测试需求变动不频繁，通常是对需求比较稳定的模块使用自动化测试技术。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

测试需求变动不频繁是指ＵＩ元素及布局在各个版本间变动不大，各个ＵＩ元素的关键属性（特别是用于唯一标识该ＵＩ元素的属性）保持稳定，其他属性可以根据需要发生变化。因为测试脚本是直接操作这些ＵＩ元素的，如果ＵＩ不够稳定，测试脚本就无法定位ＵＩ元素，也就无法有效地操控ＵＩ元素。很显然，一个项目的初期可能不太适合自动化。因为项目初期用户界面和接口不稳定，自动化脚本会被动地要求频繁改变，维护成本非常高，自动化收益不好。反而手动测试能够快速发现问题，反馈给开发人员。而到了项目后期和维护期，自动化再介入为回归测试做准备，可以最大化自动化收益。（２）项目周期要足够长，要有足够的时间进行自动化测试的设计与开发。因为ＵＩ自动化测试脚本的开发、维护成本都比较高，如果被测试产品的生命周期太短，或者只发几个版本，就会导致自动化测试的投入产出比太低，这也是大部分手游不适合做ＵＩ自动化测试的主要原因，手游项目开发、生命周期无法支持大范围自动化测试。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

（３）自动化测试脚本可重复利用。自动化测试脚本的重复使用要从３个方面来考量：所测试的项目之间是否具有很大的差异性（如Ｃ／Ｓ系统和Ｂ／Ｓ系统的差异）；所选择的测试工具是否适应这种差异；测试人员是否有能力开发出适应这种差异的自动化测试框架。（４）操作过程及结果可预期。这里是指交互的过程及预期结果是明确的，以ＱＱ的发送文本消息功能为例，其交互过程及预期结果都是相对明确的，即使有操作分支也是有限的，可以很容易遍历。这样测试脚本的设计就比较简单，基本是线性往下执行。如果交互过程及预期结果不明确，有太多的随机性，就会大大增加脚本的逻辑复杂度。过于复杂的脚本逻辑对于测试人员的能力要求高，而且会提高测试脚本的后期维护成本。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

１２.１.５我们是如何进行游戏自动化测试（以简体《魔域》为例）（１）使用图片匹配的方式搜索当前界面中的模板图片（即用于被匹配的资源图片），然后获取该图片在当前界面中的坐标，通过虚拟鼠标的方式对该坐标进行操作（单击、双击、右击等）。（２）在结果图片中会将被寻找到的模板图片以红框标识出来。（３）截取模板图片时的屏幕分辨率要和当前界面的分辨率一致。（４）自动化的脚本是以Ｐｙｔｈｏｎ脚本的形式存在，所以需要掌握基础的Ｐｙｔｈｏｎ知识。例如，ｕｉ.ｐｒｅｓｓＢｕｔｔｏｎ（＂ｓｈｏｐ＂）这条语句表示单击“ｓｈｏｐ”这张图片。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

①使用前需截取“ｓｈｏｐ”模板。②再有一张用于匹配的图片（一般是当前界面）。③执行这条语句后，会在当前界面圈出“ｓｈｏｐ”位置，并单击相应的坐标。ｓｈｏｐ模板图片如图１２－１所示。当前游戏界面，如图１２－２所示。１２.１.６为何采用ＵＩ方式进行自动化测试为什么不以获取控件句柄的方式进行自动化测试？很多游戏直接使用ＯｐｅｎＧＬ或ＡｃｔｉｖｅＸ进行自动化测试，但是传统的自动化工具无法通过获取视图元素或资源ＩＤ进行元素定位，只能在外部通过坐标单击和屏幕读取进行输入输出，而且坐标单击适用范围和场景固定，需要根据特定设备和测试案例进行坐标适配，这种方式通用性、可移植性和可维护性较差。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

为什么不以单击控件坐标的方式进行自动化测试？（１）桌面坐标是固定的，但是控件坐标会根据游戏界面的改变而不同，如果客户端最大化时，你脚本中ｓｈｏｐ的坐标是（１００，１００），在客户端非最大化时，（１００，１００）可能就不再指向ｓｈｏｐ的位置，并且以坐标形式编写脚本，脚本可读性非常差。（２）当按钮图片不变，坐标发生变化时，使用图片匹配方式不用维护脚本，而使用单击坐标的方式就要维护脚本。当然当ＵＩ变化时也要维护脚本，在游戏逻辑不变的情况下只需替换新版本的游戏ＵＩ即可。（３）采用图片匹配的单击方式能将单击流程保留下来，如果出现Ｂｕｇ，可以按照单击顺序重现Ｂｕｇ，在简体《魔域》实际测试中出现人工测试和游戏ＵＩ自动化测试同时发现某个Ｂｕｇ，但是人工无法稳定重现，最终通过游戏ＵＩ自动化测试的流程截图找到稳定重现的方式。上一页下一页返回１２.１

游戏

ＵＩ自动化测试简介

基于以上几个因素，采用ＵＩ的方式对游戏进行自动化测试是较为可行的方法，同时ＵＩ自动化与接口自动化、白盒测试等相比，它更贴近手工业务测试行为。对于刚起步测试左移、效率提升的团队来说，是最迅速的切入点，也是广大黑盒测试人员提升自身技术能力的起跑线。上一页返回１２.２游戏ＵＩ自动化测试框架１２.２.１什么是自动化测试框架在了解什么是自动化测试框架之前，先了解一下什么叫框架。框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法；另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面，而后者是从目的方面给出的定义。从框架的定义可以了解，框架可以是被重用的基础平台，框架也可以是组织架构类的东西。其实后者更为贴切，因为框架本来就是组织和归类所用的。所以自动化测试框架的定义为：由一个或多个自动化测试的基础模块、管理模块、统计模块等组成的工具集合。下一页返回１２.２游戏ＵＩ自动化测试框架按框架的定义来划分，自动化测试框架可以分为基础功能测试框架、管理执行框架；按不同的测试类型来划分，可以分为功能自动化测试框架、性能自动化测试框架；按测试阶段来划分，可以分为单元自动化测试框架、接口自动化测试框架、系统自动化测试框架；按组成结构来划分，可以分为单一自动化测试框架、综合自动化测试框架；按部署方式来划分，可以分为单机自动化测试框架、分布式自动化测试框架。本框架即功能自动化测试框架，整体工程结构和实现原理如下。上一页下一页返回１２.２游戏ＵＩ自动化测试框架１２.２.２整体工程结构１.整体工程结构（图１２－３）ｄａｔａ：存放各类数据，包括测试结果数据、测试脚本、ｌｏｇ数据、外部库、游戏数据等。２.脚本工程结构（图１２－４）ｄａｔａ＼ｓｃｒｉｐｔ＼ｃａｓｅ：存放各个流程模块的测试脚本。ｄａｔａ＼ｓｃｒｉｐｔ＼ｃｏｍｍｏｎ：存放游戏的通用操作脚本，如登录游戏操作。ｄａｔａ＼ｓｃｒｉｐｔ＼ｅｎｖｉｒｏｎｉｎｉｔ：存放各个流程模块需要查询的数据库语句。ｍａｉｎ：存放各类底层操作，如ＵＩ操作、数据库操作、进程操作、图像识别操作等。ｘｍｌｃｏｎｆｉｇ：存放各类配置文件，如数据库配置、内服测试账号配置、测试脚本优先级配置。上一页下一页返回１２.２游戏ＵＩ自动化测试框架１２.２.３核心实现原理简体《魔域》游戏自动化测试使用跨平台计算机视觉库ＯｐｅｎＣＶ进行测试，大致流程如下。（１）获取测试用例，根据测试用例熟悉相关的模块功能，然后收集模块相关控件的模板截图。（２）通过底层的ＵＩ操作获取主屏幕当前截图，将提供的模板截图和当前截图作为输入，使用ＯｐｅｎＣＶ的ｍａｔｃｈＴｅｍｐｌａｔｅ函数在模板截图和输入图像之间通过标准相关匹配ＣＶ＿ＴＭ＿ＣＣＯＥＦＦ＿ＮＯＲＭＥＤ寻找匹配，获得匹配结果图像，同时返回匹配结果图像的坐标，确定模板截图在屏幕中的坐标。（３）再通过Ｐｙｔｈｏｎ的Ｗｉｎ３２ａｐｉ库实现模拟键盘鼠标操作坐标。（４）对功能测试点进行模拟人工操作后，判断操作后的游戏效果是否符合测试用例的预期结果，并给出测试结果，完成测试。上一页下一页返回１２.２游戏ＵＩ自动化测试框架１.截图经验通过ＯｐｅｎＣＶ图像匹配的方式识别控件的方式并非１００％匹配成功，匹配误差的大小与传入的模板图片有关，项目组在实际使用中总结出以下几条截图经验。（１）截取最精确的源图片（最小化原则），提高匹配精确度。将需要匹配的控件图片拆分成较小的、唯一的元素，如图１２－５所示。缺点：图片小，获取到的特征点少，容易匹配失败，匹配成功率低。优点：匹配精确度高。其中图１２－５（ｂ）作为模板图片最适合。图１２－５（ａ）带上了背景（即树叶），当玩家发生移动时，背包的背景也会发生变化，从而导致模板图片在原图中无法被识别。上一页下一页返回１２.２游戏ＵＩ自动化测试框架图１２－５（ｃ）太小，特征点少，极容易被错误匹配，可能识别成其他的按钮。（２）将需要匹配的图片适当放大，提高匹配成功率，但匹配误差增大，精确度降低，此时可以根据实际测试过程对阈值进行调整来保证匹配准确度。缺点在于特征值增多，容易发生误匹配，精确度降低；需要根据实际情况修改匹配阈值。优点在于匹配成功率较高。（３）图片截取使用屏幕原生分辨率，这样可以保证截取的图片在不同的平台都能使用。（４）相对位置的截图。采用相对位置截图而不直接采用坐标是为了保证结果图片的可读性，不让结果图片出现“断层”，如图１２－６所示。上一页下一页返回１２.２游戏ＵＩ自动化测试框架如何截取守护骑士的任命？由于所有骑士任命的按钮都是一样的，若单独截取任命按钮，匹配误差较高，根本无法对某类骑士进行准确任命，故需要截取特征明显的图片作为模板，然后根据任命按钮相对于该模板图片的相对位置，调整单击坐标即可。此处可以选取作为模板图片，通过ｉｍａｇｅＰｏｓ获取图片中心坐标为（ｘ１，ｙ１），通过屏幕取点工具获取守护骑士的任命按钮的坐标是（ｘ２，ｙ２），假设ｘ２－ｘ１＝５０，ｙ２－ｙ１＝３６，那么最后单击的坐标是ｍｏｕｓｅ＿ｃｌｉｃｋ（ｘ１＋５０，ｙ１＋３６）即（ｘ２，ｙ２）。截图要点如下。上一页下一页返回１２.２游戏ＵＩ自动化测试框架（１）截图最重要的一点是要保证所截取的图片具有明显特征，当需单击部分本身已有明显特征时，则按正常“按钮”形式进行截图；若单击部分特征模糊，则需要扩大（或缩小）截图范围，使截图具有较明显的特征。（２）一般情况下，截图不建议包含背景，以避免背景变化导致模板识别失败。（３）截图时，若直接在客户端上截，应保证客户端最大化；若在图片上截，应保证图片显示比例为１∶１。（４）截图必须保证所截图片的中心点为按钮响应区域。上一页下一页返回１２.２游戏ＵＩ自动化测试框架２.模拟键盘鼠标主要使用模块Ｗｉｎ３２ａｐｉ、Ｗｉｎ３２ｃｏｎ、Ｗｉｎ３２ｇｕｉ，这里展示部分的键盘鼠标操作。１）鼠标移动２）鼠标单击上一页下一页返回１２.２游戏ＵＩ自动化测试框架３）鼠标右击４）键盘单击上一页下一页返回１２.２游戏ＵＩ自动化测试框架键盘单击并不是对所有输入框快捷键等都适用，游戏的账号和密码输入框有时会进行一些保护措施，继续使用以上的局部键盘输入方式将无法输入文本，需要将局部的键盘方式改为全局的键盘方式才可以。５）虚拟键码（１）每个厂家的键盘上的每个键都对应一个扫描码。例如，对于键盘上的左“Ａｌｔ”键，其扫描码是４。（２）键盘的驱动程序会把扫描码转成虚拟码。例如，将上面的扫描码４转化成虚拟码ＶＫ＿ＭＥＮＵ。（３）虚拟码通常可以认为是和硬件无关的。部分虚拟键码如表１２－１所示。上一页返回１２.３游戏ＵＩ自动化测试过程１２.３.１测试用例测试用例是游戏自动化测试的核心之一，测试用例的设计和编制是测试活动中非常重要的一环。测试用例是测试工作的指导，是测试必须遵守的准则，更是测试质量稳定的根本保障。很多公司在实施自动化测试的过程中有着许多不规范的做法。比如手工测试用例和自动化测试用例混用、让开发者（非游戏测试人员）去编写游戏的测试用例。这些不规范的做法都很有可能导致测试项目的失败。自动化测试用例的设计应该遵守以下几点原则。下一页返回１２.３游戏ＵＩ自动化测试过程原则１：自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。在选取自动化测试用例范围时，很多测试工程师可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。其实恰好相反，这样的想法往往会导致自动化测试最终失败。在一些大型项目中，往往测试用例的数量会很庞大，而且如果遇到一些繁杂的被测试程序，玩家交互复杂的模块，脚本开发工作往往会相当耗费时间，并且很多测试用例甚至根本就不能通过自动化来实现。例如，现在很多公司自动化测试都是刚起步，对自动化测试的了解程度只是停留在字面上，在公司对测试也不是非常重视的情况下，当然不太愿意去花精力招聘一个具有自动化测试开发经验的工程师，很多还是停留在使用工具的录制回放功能来完成自动化测试。上一页下一页返回１２.３游戏ＵＩ自动化测试过程正是存在这样的技术限制情况下，往往在实施中会出现很多录制回放不能解决的问题，测试工具完全无法识别测试对象，无法识别一些特殊的加密测试控件。还有，如果项目的更新频率、测试用例数量大，就增加了后期的维护成本等，这些都是造成最终失败的一些原因。为了能够充分发挥自动化测试的优势，我们会选取最核心的一些游戏模块或者是重复执行率较高的一些手工测试用例进行自动化测试。上一页下一页返回１２.３游戏ＵＩ自动化测试过程原则２：自动化测试用例的选择一般以“正向”为主。手工测试用例分正常情况和异常情况，在设计时可能往往会去设计很多异常情况来验证程序是否有Ｂｕｇ，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的预期结果。在自动化测试中，很多人喜欢将正常情况称为“正向”；反之，异常情况则称为“反向”。下面试想一下，如果将这些异常情况全部转化、反映到自动化测试脚本中，肯定需要非常烦琐的判断才能做到。上一页下一页返回１２.３游戏ＵＩ自动化测试过程这个对于自动化测试工程师来说，无论对现有的工作量还是对今后的脚本维护量都是不可小觑的。然而如同上面所述，游戏测试工程师往往遇到一个外部玩家奇葩操作带来的Ｂｕｇ就要求加入自动化测试之中，对于整个自动化测试项目来说，如果每个异常情况都要写进脚本中，那真是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。使每个东西都能发挥其最大的作用才是企业最想看到的。功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。而自动化测试的目的和目标则是让测试人员从烦琐而又枯燥的重复手工测试中解放出来。上一页下一页返回１２.３游戏ＵＩ自动化测试过程原则３：自动化测试用例不能完全等同于手工测试用例。这里纠正许多测试从业人员的一个错误观念，刚接触自动化测试的人普遍会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施时，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要去自动化测试的。例如，有些用例会牵涉硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有这样的重视程度的更不多）；再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，以及根据具体情况给予响应的，这些情况多数还是只能使用手工测试人为地完成。当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试，哪些是不需要的；否则测试工程师就会不知所措，没有一个标准。一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去对需要被转化的自动化测试用例进行相关的脚本开发工作了。上一页下一页返回１２.３游戏ＵＩ自动化测试过程原则４：手工测试用例可以不用回归原点，而自动化用例往往是必需的。很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻会报错，原因就是没有回归原点。回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态，如果没有回归原点，就会把此脚本称为死脚本。例如，添加用户功能，都知道每个用户名都是唯一的，当写完一个添加用户的脚本后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下就需要在自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据。上一页下一页返回１２.３游戏ＵＩ自动化测试过程比如ＡＴＭ机取款，假设需要执行取款１００元的操作，而银行卡余额是１２０元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成了死脚本，解决方案有两种：一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于１００即可）；第二种方法可以在用例执行前先查询下余额是否大于１００，若大于等于则继续，若小于则做一笔充值１００的操作，这样即可解决。两种方式可以看具体情况使用，数据初始化方便，但有时初始化之后可能会影响到其他自动化测试用例的执行，而第二种方式相对在脚本上需要稍微花点工夫。究竟使用哪种方式还需要具体情况具体分析。总之，在执行自动化测试用例之前做好数据准备，也是自动化测试的关键步骤。在简体《魔域》的自动化测试中，每次的测试是如何回归“原点”的？其实就是将原点所需的环境都存放在初始库中，测试时输入初始库，保证每个模块的用例都处于初始状态，从而保证每个脚本的重复使用。上一页下一页返回１２.３游戏ＵＩ自动化测试过程原则５：自动化测试用例和手工测试用例不同，不需要每个步骤都写预期结果。在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。但是，在自动化测试用例的设计中并不采用，在自动化测试用例中，只有准备在测试脚本中设置成检查点的步骤才有预期结果，其他所有的步骤只将它看作一个步骤，这样做的好处是一目了然、目的明显、层次分明，以后写测试脚本直接跟着自动化测试用例就行了。因为经过前面的探讨应该已经知道，自动化测试中并不是所有的东西都需要验证的。基本上手工测试用例多少都要进行一些转换，就是因为它们之间的格式是不一致的。上一页下一页返回１２.３游戏ＵＩ自动化测试过程例如，假设需要设计一个注册页面的自动化测试用例，有十几个表单需要填写，在手工测试用例中，每个表单的填写都一定会有预期结果，因为它的确在检查每一项是对了还是错了，只是用的是你的眼睛在检查而已，所以速度非常快，甚至你自己潜意识都忽略了其实你已经检查了。但是，在自动化测试中，我们知道如果你要检查，那一定需要写代码，如果每项都检查，那代码量有多大是可想而知的，不是说做不到，只是这样做根本不符合自动化测试的特点。所以，绝大部分时候，这些在自动化测试中可有可无的检查全部“不检查”，只当作一个业务流程和步骤，是不需要设立预期结果的。上一页下一页返回１２.３游戏ＵＩ自动化测试过程原则６：用例要具有独立性。一个用例的完整场景是从玩家启动游戏登录操作到退出游戏系统，用例之间不要产生关联性，也就是说，编写的每一个用例都是独立的，不能依赖或影响其他脚本。一个用例只验证一个功能点，不要试图登录操作后把所有的功能都进行验证。例如，一个军团用例，不要试图在一个用例中同时把军团的创建、军团的解散、军团的成员管理一次写完。用例的复杂性决定了脚本执行的成功率的高低，一个经验丰富的自动化测试工程师应当会筛选出用例中独立的功能模块进行编写，将用例细化成多个脚本，同时这样也会减少维护的成本，不至于出现“牵一发而动全身”的情况。上一页下一页返回１２.３游戏ＵＩ自动化测试过程１２.３.２测试脚本测试脚本依赖于测试用例，所以大部分的编写原则是一致的。（１）一个脚本是一个完整的场景，从玩家启动游戏登录操作到退出游戏系统。（２）一个脚本只验证一个功能点，不要试图登录操作后把所有的功能都进行验证。（３）尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证。（４）脚本测试区别于人工测试，可以进行一定的量级测试。（５）如果对数据进行了修改，需要对数据进行还原。（６）在整个脚本中只对验证点进行验证，不要对整个脚本每一步都做验证。上一页下一页返回１２.３游戏ＵＩ自动化测试过程１２.３.３测试环境与流程１.测试环境一般来说，游戏设计分为三大块：数据库设计；游戏逻辑Ｓｅｒｖｅｒ；游戏的逻辑Ｃｌｉｅｎｔ。这里的Ｓｅｒｖｅｒ是广义的Ｓｅｒｖｅｒ，不同公司的设计是不一样的，这里不细分。游戏Ｃｌｉｅｎｔ就是指平时运行的、可以实际“玩”的游戏，也就是运行在玩家的ＰＣ机上的可执行程序。其实实际做的自动化测试主要是游戏Ｓｅｒｖｅｒ的实际运行和与Ｃｌｉｅｎｔ的交互。要执行游戏自动化测试，必须要有一套相对独立于人工测试的游戏环境，即包括上面所述的数据库、服务器和客户端。２.测试流程框架整体的测试流程如图１２－７所示。Ｃｏｎｔｒｏｌｌｅｒ为测试的入口点，在配置好配置文件后，读取优先级配置文件按顺序运行功能模块。上一页下一页返回１２.３游戏ＵＩ自动化测试过程Ｍｏｄｅｌ即前面框架所述的ｄａｔａ，这里主要指脚本游戏客户端相关模块、功能模块、数据库查询语句模块。Ｖｉｅｗ即测试结果部分，通过Ｃｏｎｔｒｏｌｅｒ运行完Ｍｏｄｅｌ后，就会产生测试结果，测试结果包含了Ｅｘｃｅｌ和Ｉｍａｇｅ两大部分，Ｅｘｃｅｌ即测试报告，告知用户测试结果，主要有３种，即通过、不通过、失败。Ｉｍａｇｅ存放的是流程图片（即结果图片），当测试结果为不通过或者失败时，可以通过查看流程图片确认测试结果。上一页返回１２.４游戏ＵＩ自动化测试平台在一个游戏项目中引入自动化测试，会发觉运行它也需要一定的时间，有时一些项目甚至需要几个小时。如果让开发者在他们的开发用机上运行，测试会完全占用他们的机器，影响工作，那么结果就是他们不去运行测试用例，很显然，没有被运行的用例是没有任何价值的。为了使开发团队更有效地进行游戏自动化测试，同时也为了减少开发团队的压力和工作负荷，并且在开发过程中尽早发现Ｂｕｇ，应该在测试工作中使用更多的计算机。例如，如果测试人员被误导在单机上努力完成某些大容量的自动化测试执行工作，这种情况下由于错误地使用了测试设备、测试环境，导致测试没有效果。因此，自动化测试需要集中考虑所需要的支撑设备。为了能够同时对多台主机进行分布式自动化测试，搭建了一个游戏ＵＩ自动化测试平台，当项目需要进行回归测试时，通过上传测试环境，平台即可自动进行测试并反馈报告。下一页返回１２.４游戏ＵＩ自动化测试平台游戏ＵＩ自动化平台主要包括以下内容。１.产品测试分页（１）当前平台支持的游戏项目，目前包括端游和手游共４款游戏。（２）发现的Ｂｕｇ数，现已发现１００多个Ｂｕｇ，包括严重Ｂｕｇ有２９个。（３）记录测试次数、测试模块数。自动化平台产品测试分页如图１２－８所示。选择某个游戏项目进行测试，上传测试环境、选择服务端版本，同时勾选测试流程类型，即可开始流程测试，如图１２－９和图１２－１０所示。上一页下一页返回１２.４游戏ＵＩ自