游戏自动化测试实践_百度百科
声明：百科词条人人可编辑，词条创建和修改均免费，绝不存在官方及代理商付费代编，请勿上当受骗。
游戏自动化测试实践
本词条缺少名片图，补充相关内容使词条更完整，还能快速升级，赶紧来吧！
《游戏自动化测试实践》是2015年1月出版的图书，作者是陈大卫，李建玲。
游戏自动化测试实践图书信息
作 译 者：陈大卫,李建玲
出版时间：2015-01
千 字 数：249
游戏自动化测试实践内容简介
本书中所探讨的主题，业界目前尚无统一理论与实现体系，因此在书籍的第一部分（1～3章）阐述完游戏测试的特点、工具及自动化测试在游戏测试中的引入与理解等主旨思想后，更多的篇幅放在了实践上，从相对孤立的自动化测试实现各阶段技术点与思路掌握（4～6章），到完整的测试任务实现（第7章），实例贯穿始终。[1]
实例代码会由书籍内容本身和可下载的资源包两部分构成，两部分都是相对完整的。即使缺少该资源包也不会导致书籍体系的不完整，但是测试代码总要在被测对象上才有用武之地。因此除测试代码外的实际被测游戏也不应忽视，该资源包正是为了促进读者学习理解而准备的。[1]
游戏自动化测试实践前言
本书介绍的是游戏软件的自动化测试实现，讲解内容以实践为主，理论为辅。实例将会贯穿整书。虽然本书不会过多讲解测试理论，但是并不能说明我们的自动化测试实现可以脱离测试思想而单独存在。反而实际情况是，游戏软件的自动化测试首先应该是软件测试，然后是游戏软件的测试，最后才是游戏软件测试的自动化实现。专注程度不断提高，实践性逐渐加强。[1]
游戏自动化测试实践目录
第1章 游戏测试
1.1 游戏测试的特点
1.2 游戏测试的三个层次
1.2.1 常规软件测试
1.2.2 游戏参数调节
1.2.3 游戏性测试
1.3 游戏自动化测试的可行性
第2章 软件测试工具运用
2.1 什么是软件测试工具
2.2 幸福五子棋9连测试
2.3 拖拉机纸牌游戏测试
2.4 斗地主游戏测试
2.5 测试工具在测试中的思想体现
第3章 自动化测试思想
3.1 目标决定了实现方式与思考方法
3.2 脚本语言在自动化测试中的优越性
3.3 自动化测试实现的工具无关性
3.4 功能自动化测试实现三要点
第4章 自动执行
4.1 直接控件操作
4.1.1 控件操作
4.1.2 窗口/控件信息的获取
4.2 模拟键盘和鼠标
4.2.1 模拟键盘和鼠标操作
4.2.2 窗口的定位与激活
4.2.3 绝对坐标与相对坐标
4.2.4 坐标的获取
4.2.5 录制脚本
4.2.6 有效的延时等待
4.3 收发网络消息交互
4.3.1 TCP连接的建立
4.3.2 UDP连接的建立
4.3.3 局域网游戏——拱猪
第5章 状态识别
5.1 不进行状态识别
5.2 直接获取所需状态信息
5.3 通过状态伴随表现间接识别
5.4 进行状态推算
5.5 通过屏幕的像素扫描
5.5.1 打苍蝇
5.5.2 扫雷
5.5.3 连连看
5.6 直接读取内存
5.6.1 扫雷
5.6.2 九宫格
5.7 程序后门
第6章 逻辑处理
6.1 顺序执行
6.2 使用简单算法完成常规处理
6.2.1 扫雷
6.2.2 局域网拱猪
6.3 利用计算机优势，得到较优解
6.3.1 点灯游戏
6.3.2 连连看
6.4 移花接木，利用外部逻辑
第7章 综合实例演示
7.1 中国象棋
7.1.1 测试策略的选定
7.1.2 实例源码
7.1.3 实例点评
7.2 幸福跳棋
7.2.1 测试策略的选定
7.2.2 实例源码
7.2.3 自动化测试实现的工具无关性
7.2.4 脚本的优化与完善
7.2.5 实例点评
7.3 幸福五子棋
7.3.1 测试策略的选定
7.3.2 实例源码
7.3.3 实例点评
7.4 手机模拟器
7.4.1 翻方块
7.4.2 打地鼠
7.4.3 实例点评
7.5 手机游戏
7.5.1 一划到底
7.5.2 2048
7.6 九宫格
7.6.1 测试策略的选定
7.6.2 实例源码
7.6.3 Nokia数独游戏
7.6.4 实例点评
7.7 仙剑Online防外挂码识别
7.7.1 备选答案识别
7.7.2 防外挂码识别
7.7.3 防外挂码识别的正确率
7.7.4 实例源码
7.7.5 实例点评
附录A AutoIt v3简介
附录B 中国象棋棋谱规则
附录C 因果图分析之中国象棋走马
．电子工业出版社[引用日期]175被浏览63827分享邀请回答8617 条评论分享收藏感谢收起22 条评论分享收藏感谢收起查看更多回答收藏的论坛
手游与App测试如何快速转型 分析手游与App测试四大区别
　　随着智能设备的普及和移动互联网的兴起，各家互联网巨头纷纷在往移动端布局和转型，同时初创的移动互联网公司也都盯着这个市场希望分一杯羹。在这个大环境下，互联网的重心已经慢慢从Web端转向了移动端，而移动端的软件测试也变得越来越重要了。　　在移动端的软件里，手游又是其中非常大的一块。从下面的图可以看出，智能手机的普及和手游玩家的增长是密切相关的： 　　笔者曾经从事过手机App的测试开发工作。1年前加入鹅厂后转行做了手游测试工作，通过摸索实践，发现两者在相同的测试理论基础之上，其实有着非常不同的测试场景和测试需求。下面就为大家整理一下其中的基础部分，涵盖了两者在手工和自动化测试方面的不同，希望能帮到想从App测试转到手游测试的朋友们。　　1.APP自动化测试完全不同于手游自动化测试　　手机App和手游的开发技术不同，这导致了两者的自动化测试技术是截然不同的。　　以安卓开发举例，手机App一般使用Android SDK开发，使用Java编写。通过Android提供的服务，我们可以获取App当前窗口的视图信息，进而查找和操作按钮等控件，以完成自动化测试，如Uiautomator。这个过程是标准化的，从技术上来说没有任何难度，因此各个公司各个App自动化测试的方法都大同小异。　　但手游的开发却不是这样。手游一般使用引擎开发，现在著名的有cocos2d和unity3d。两者都是使用引擎自带的语言进行开发，主流的分别是c++和c#，虽然在开发过程中也有按钮等控件的概念，但当运行时由引擎渲染后就变成了一副简单的图片：　　游戏中看到的只是一副简单的图片，按钮已经不是控件了　　因此，我们就无法通过Android自带的服务来找出游戏中的按钮了，也就没法进行常规的自动化测试。　　如果有人说自己的技术是基于Android原生控件识别的，那就一定做不了手游自动化测试。这个问题大家都在探索解决方案，我们现在通过注入引擎SDK到安装包反射出引擎层控件的方法进行自动化测试，实践下来具有很好的效果。　　2.玩法不同导致功能测试更复杂　　2.1 随机性　　游戏的场景和过程是动态并且伴有随机要素的，这体现在两点。　　1.你重复玩一个游戏关卡，很可能两次出现敌人以及游戏过程是不同的。　　2.你玩一个手游的时候不进行操作，敌人和周围的场景也在时刻发生改变。　　这两点对自动化测试带来了极大的挑战，如果测试脚本写的不够灵活，很容易导致上一次运行成功的脚本这一次就无法运行了。我们需要在测试脚本里适当的加入探索和自适应的功能。　　App测试就没有这个问题，大部分App的使用方式都是静态且可以重复的。因此自动化测试可以完全按照测试脚本进行编写并执行。　　2.2 探索性　　手游和App的第二个玩法不同在于探索性。App一般都是功能性的，好的App需要把它的功能简单明了地告诉用户。而游戏重在娱乐性，需要给玩家一定的探索要素。因此在做手游测试的时候，我们需要测试游戏的用户帮助说明是否清晰，同时后续的游玩和探索过程和前面给出的说明之间是否有合理联系，规则的指示是否有足够的提示性。　　2.3 难度测试　　App希望做的越简单，用户的使用成本越低越好。而手游是有难度设置的。我们在做手游功能测试的时候，会把资源和等级调到最大以方便后期功能的执行，但当所有的功能测试都做完后，我们需要把自己的资源初始化，以&回归&一个普通玩家的水平，通过普通玩家的视角来查看游戏的难度提升是否合理，资源分配是否均匀。　　2.4 关卡测试　　App的使用是功能性的，一个功能的重复使用总是一样的。而手游具有关卡的概念，即便是同一种玩法，关卡和关卡之间也有细微的差别，前面的关卡测试正确了，并不表示后面的关卡一定是正确的。作者曾经碰到过一个手游的Bug，当游戏进行到某个后期关卡时，游戏一定会崩溃。而导致这个Bug的原因也很简单：这个关卡的图片资源在打包客户端的时候没有加入。因此当我们玩前面的关卡时并不会触发这个Bug，但一到后面的关卡就出错了。　　这类Bug虽然原因简单，但确实非常难测试到。因为各个关卡的玩法虽然都一致，但一个游戏的关卡数却是非常多。如果我们要遍历所有的关卡走一遍，那耗费的人力成本将是非常大的。对于这类重复性的关卡测试，建议使用自动化脚本进行遍历。　　2.5 PvP测试　　App的使用普遍是单人的，而手游往往有玩家对战的PvP模式，好的手游更是具有实时的PvP模式。由于两个玩家实时进行游戏合作或者对战，因此网络延迟的测试就变得非常关键了。我们在测试中需要模拟不同的网络对游戏延迟的影响，观察两个玩家的状态和数据是否一致，同时体验网络延迟对游戏手感的影响，这在传统的App测试中是完全不需要的。　　3.手游测试更看重商业类测试　　3.1 支付测试　　现在的手机App基本上以广告收入为主，并不会直接向用户收取费用。而手游的直接消费群体就是玩家，在游戏过程中伴随着玩家大量的支付操作。由于这类操作和玩家的金钱密切相关，因此支付类的测试在任何游戏中都要做最高优先级的保证。　　我们需要在各种严格的环境下保证玩家的支付操作被正确执行或者得到了正确的失败提醒。例如当网络状况很差的时候，用户在支付界面的多次确认操作必须只能被执行一次。当用户在支付过程中断网，未收到货物时，游戏需要在玩家的网络恢复后第一时间补发货物，并作出明显的提示。另外支付操作需要在大量不同系统、不同型号的手机上进行适配操作，以降低出错的可能性。　　3.2 安全测试　　对于大多数非支付类App来说，安全并不是一个特别大的问题，只需要保证登录鉴权的安全性即可。App是一个方便用户的工具，没有人会在用自己的计算器App时候锁定内存，或者把加法操作变为乘法操作。　　手游在这点上很不一样，手游与玩家在某种程度上具有&对抗&要素，玩家要战胜游戏关卡获得奖励，而游戏关卡要设置一定的难度阻止玩家。如果游戏的外挂横行，玩家不需要任何对抗就能获得胜利，一方面会对游戏的平衡性造成影响，使得某些玩家的资源大大超过别的玩家;另一方面从长远看会使得这个游戏变得无趣，从而造成玩家的离开。　　对游戏进行安全测试的普遍方法为通过锁定/修改内存来锁定和修改游戏资源、通过修改游戏内存来改变游戏逻辑简化游戏流程等。　　3.3 收益测试　　一般的手游App没有付费用户的概念，所有的用户都是使用同一个功能。即便有付费用户，他们和普通用户的区别也非常明显：付费用户可以使用一些额外功能。手游的付费用户和非付费用户的界线并没有这么明显。手游里根据用户付费的多少分为非R用户，小R用户，大R用户等。我们需要在策划的时候就计算好这些付费用户的投入和回报，并在测试的过程中验证这些。举两个例子，如果一个大R用户获得的回报，非R用户只用很少的时间就能获得，那大R用户一定不满意，这个收费项目的设置就是不合理的;如果两个购买项的金额相同，而收益明显不同，那也会造成玩家的不满。　　4.后台性能不同　　虽然我们这里讨论App和手游主要是前端客户端，但其实两者的后台性能也有区别。相比一般的App，手游的在线人数明显更有规律性且更集中，一般在中午12点和晚上8点是两个明显的高峰。因此手游的性能测试就要贴合这种用户模型，能够处理极值情况下的服务器性能负载。当然，两者都会受到节假日较大的影响，这个对于App和手游来说是一致的。　　也来谈下相似之处　　除了上面提到的这么多手游测试和App测试的不同点，其实两者也有很多相似之处，在测试的时候都不能遗忘，例如手机来电、短信的中断测试，碎片化的兼容性测试(尤其是安卓)，客户端运行在手机上的性能测试，网络较差或者网络频繁切换的弱网络测试，已经用户体验和UI测试等。
近期游戏热闻
类型:3V3 MOBA
厂商:Supercell
类型：MOBA
类型：动作射击
类型：角色扮演
类型：音乐舞蹈
类型：换装养成
类型：休闲益智
类型：ARPG1558被浏览77819分享邀请回答/Tencent/GAutomator/blob/master/doc/image/1.gif性能自动化测试
性能自动化有几个优点，1、一致性，人工测试的时候难以控制游戏的激烈程度，使用脚本测试多次测试之间激烈程度基本一致。2、快熟反馈，人工测试比如说王者荣耀测试一次5V5对战就需要10个人，不可能非常频繁的测试。引入性能自动化测试后，每个性能优化的结果，开发都能掌握。以前通常都是不同版本之间性能对比，开发压根不知道自己的优化效果怎么样。现在CI每日构建的版本都可以测试一次性能，然后每天都能收到性能对比报告。适配兼容性测试
android碎片化严重，适配测试必不可少。腾讯内部游戏的适配测试以前均是交给适配实验室，每次测试100部不同的手机。但是缺点就是，次数有限，还需要排期。所以wetest这边设计的unity手游自动化测试框架，一开始就是适配测试考虑进去。GAutomator写的脚本在本地自己pc上可以运行，上传到平台就能在平台上所有几百部手机上同时运行。运行过程中只要出现crash、UI问题、Anr等会发现并且归类，日志、截图都会全部保存下来。这就有一个好处，现场保存完整，适配测试成本极大减轻。
现在基本上，使用GAutomator进行自动化的游戏，都会顺带利用这个进行适配测试。crash发现能够提前大约5天，给开发预留更多的时间。“上医治未病”。还有一种腾讯内部有很多重量级的SDK，比如Apollo、MSDK、QT等，这些SDK的兼容性、性能要求都极高，需要测试top300以上的手机。使用也都自动化进行测试。特殊问题
各个游戏自己面临的问题。特别是一些低概率极难复现的问题，可以利用自动化在大量手机上大规模的测试发现问题。现在实时对战的游戏很对会采用帧同步，可能会出现不同步问题，这个问题出现的概率非常低。使用自动化测试非常适合。重复性问题
最为典型的是新手引导，每次数值调整之后都需要对这部分进行测试，对测试人员本身的价值和意义不大，交给自动化来进行测试。ps:功能测试，现在部分项目组有部分特殊的需求有尝试做。但是，大部分功能测试可能现在还不适用于自动化，太复杂，成本很难收回来。除非以后有更好的测试方案。15719 条评论分享收藏感谢收起}