引言

本文以移动端为载体，本来想拿公司名义发的，笔者（Testerhome 社区账号：jiazurongyu，hi_world）所就职公司是一家研发为主体公司，一直以来都比较努力在做游戏项目，在业内也是以研发实力和速度闻名的 cp，在过去 1 年各项目的大和小版本不包含出渠道包和海外渠道包，共计超过 200 个，测试如何使用错峰策略和紧密方式确保品质要求下完成测试列表验证，也抽出人力和大厂合作时，很好配合对方的品质需求。
因游戏业务点特殊性和自定义等问题，这里无法套用很多已经成熟的测试框架和知识点，所以在实践工作中会把可以通用的部分拆分出来，业务和关联的部分另外划分出来，进行一些实际操作和检查哪些东西的讲解。
本文笔者也是在有限的人力上完成了公司需求的 1 个覆盖很全的品质体系，因为一些小心得，所以有了这份文章，如果根据文档操作步骤和策略指引以及对比检查项和一些入手点，相信会带给大家不少帮助。
部分内容会受项目影响较大，所以具体数据以 x 来替代。
言归正题。

介入时间（策略）jiazurongyu

测试降低风险为基本条件，大部分公司在 close_beta 阶段才进入测试或者指望用户测试，没有测试介入，会因为问题堆积量得不到合理的梳理而导致后面为了质量把团队变成疲兵，也会较晚介入，测试内容较多，测试只能覆盖主要的，最终产生缺陷遗漏和失控，希望明确教训，所以做有了这段小分享。

游戏的版本阶段大体如下：

• Demo，aplha，open_beta，close_beta，RC（可以达到完美发布），release，gold_release（收费）
• 在 demo 阶段也可以对游戏有 1 个初步的了解，demo 的包可以根据演示手机的 os 和型号，使用 monkey1 小时稳定性测试，降低 crash 率（后续在兼容性章节看到内容）
• 游戏环节的 demo 版本也需要重视成 1 个单独项目，逻辑问题较多，实际测试记录 1 小时内内存峰值和内存转换较大的地方是需要的，介入时间是 demo 发布前 3 天左右。
• 测试介入点应该是在 alpha 阶段进入，在前期和项目组成员一起配合做单元测试或者熟悉功能点具体业务流程。前期的介入可以过度磨合期用于后期比较频繁的迭代，配合的方式使用 W 模型，不推荐游戏产业使用瀑布模型（线型），项目周期修复时间来不及，W 模型可以更好的控制时间成本。
• 测试初期介入其实还是准备测试用例和需求分析，根据当前项目的团队特色来进行测试人员分配和测试计划的设计，整体进行 PDCA。
• 移动游戏也会在一开始 pc 版本中进行测试，cocos2d-win32.vc2012.sln 生成 Release.win32 文件夹，等大部分问题通过后，才会在手机端进行。Unity 编译更直接。

版本条件（策略）jiazurongyu

随着进度推进，开发完成度验证版本阶段验收，根据条件判断是否满足，根据测试部门制定的一套标准，标准落实是否要执行根据项目判断，但个人对文中条件 3.以后环节是比较重视的。
aplha 版本会使用到几个重要概念 重要问题指 B 类至热门问题以上的，阶段完成度是指 alpha 版本内规划的内容，开发功能点列表会使用到 1 个 checklist 表单。

Aplha 版本到 open_beta 满足完成度要求还需要具体以下：
参考数据为 1.开发功能点列表完成度高于 x% 2.阶段完成度内容 100% 3.A 类 bug 低于 bug 总数的 20~30% 4.重要问题比例低于 bug 总数的 x%
Aplha 版本还不用使用到缺陷收敛，缺陷收敛的方式来源于统计学和传统软件，经常实践转化为可用的（缺陷收敛章节）

open_beta 开启后->close_beta，随着进度推进，会根据结果是否 close_beta，close_beta 正式进入上线阶段。满足完成度要求还需要具体以下：
参考数据为 1.开发功能点列表完成度高于 x% 2.阶段完成度内容 100% 3.A 类 bug 低于 bug 总数的 20%4.重要问题比例低于 bug 总数的 x% 5.缺陷密度数值健康 6.高密度模块修复率高于 x%

前面 2 条是硬性保证的，第一条具体数字根据项目实际情况。Beta 会使用到几个重要概念 缺陷密度根据问题级别数量和是否 100% 复现等获取 1 个数值，确保数值健康，不同阶段根据项目新增问题和修复问题会存在 1 个健康的曲线，按天为单位去确保曲线健康，何时需要堆积和补充问题，何时需要收敛问题，让大家共同参与缺陷收敛保障。高密度模块排出 top（1~3，1~5）的，同上，确保修复率高于多少百分比。高密度后者是前者数据缩影，也是关键部分的保障。

close_beta-> RC 上线前版本关注点也是一样的，这里需要关注上线前准备的内容，满足一定的条件下就是完美发布，release 正式服到 gold_release 大家字面上也可以理解。

手游项目流程（操作内容）hi_world

拿到 1 款手游从立项到 sdk 到充值调通上线，然后我们会按以后每个阶段和环节的列成 excel 进行勾选验证。

1） 立项后，到了可进入测试阶段，分配测试人员根据策划案，进行需求分析后，编写测试用例（这部分内容可以预判提前进行的）。这里需要研发人员提供给测试策划文档或功能的详细说明，需求不明确的地方在写用例过程中确定后维护。随着项目推进，部分调整过的用例需要维护优化。

2） 参加研发人员项目例会：测试人员需要参加项目例会，了解项目进度和最新更改的内容。可以测试阶段，功能测试和逻辑环节完善测试用例，跟踪重要 bug 到 bug 修复关闭，每日确保修复率。

3） 项目中期，新功能测试迭代回归测试，功能点也有业务的优先级别，会根据复杂度，功能点可以集中测试，需要使用错峰策略。

4） 项目堆积和缺陷密度健康后的稳定期，严重级别较高的 bug 全部修复，级别低或建议内延后修复，产生 checklist 对应反馈。

5） 出包测试前，需要验证完游戏埋点内容和音效，兼容性适配，部分性能测试和 sdk 测试。（这里扩展会在后续章节讲）

6） 上线前准备:
6.1（客户端）确认应用版本号，游戏资源号，记录存放位置，明确客户端 Icon，登陆页面和闪屏，sdk 参数已更新，包名正确，充值已调通，并且完成一单的充值，外部渠道可以考虑用沙盒支付。
6.2（服务器）服务器列表可见与资源版本号映射的上限版本号，对应区服读取正确，测试服修改为正式服（上国外渠道需保留测试服，重新搭建正式服），正式服和测试服 1:1 的配置，海外 CDN 资源服务是否已有，CDN 支持区域是否正确，如果不是 CDN 就检查对应其他的，数据库时区是否一致
6.3（国内，海外），游戏内容推送流程，增量更新，补丁包更新是否顺畅，热更新每个项目是否都验证过。
6.4（活动环节）游戏内活动，游戏外平台活动确定。（SDK 测试）打包 CI 策略，sdk 基本 monkey 稳定性测试，基础适配测试，安装/反安装测试，sdk 消息推送，sdk 登陆注销，悬浮按钮，用户中心以及充值接口验证，接口辅以参数修改后验证。

7） 渠道包管理，渠道测试账号备份，被打回渠道包和正确的渠道包区分，渠道包测试文档及时更新。
多渠道会使用矩阵表格，会做几个字段（区分 ios 越狱，安卓），测试账号的内容和该渠道剩余问题。
做账号管理模式，备份的账号标注 useid，password，role_name,账号配置信息。

8） 后期维护，开新服预登陆测试，创建角色平台发道具测试；更新补丁，在内网测试通过后在测试服更新补丁，再上正式服开白名单测试，通过后告知开服。后期渠道包出包，sdk 更新出包，因补丁包内容较多出包；合服测试（合服测试会放在专项里面讲）

测试组降低项目发布时的风险，提高版本的健壮性，思考遗漏点加以补充。

上线客户端性能 - 专项 Memory&cpu（一）jiazurongyu

除了上面游戏制作中的品质管理流程外，还需要关注基础性能标准，客户端、服务器、数据库性能测试等。
这里先来描绘下手机端客户端性能测试，这里应该分为安卓和 ios 二部分。
客户端性能这个大环节主要参数是 cpu，gpu，memory，fps，首先从运行游戏的载体差异到,到用户觉察到版本交付时通过验收,到内存泄露,到场景设计。
性能测试的开始依据是逻辑问题大部分解决情况下，在进行性能测试，由大到小检查，从大开始优化更好的可以提升项目组的信心，如果逻辑问题较多，过早优化也是无用功。

• Cpu 是性能测试中占 35% 以上的优化点，在游戏过程中主要负责物理效果演算和 AI 运算
• Memory 是物理内存，一开始会根据启动时分配，一开始如何在 loading 等环节降低内存使用，确保一定时间内，不会出现 out memory of error 这类信息。
• Gpu 通常情况下不可被设置，在 3d 游戏里需要考虑优化地方较多，需要验证像素填充率和 Shader（后面会单独提到 GPU 环节，如果有技术专才可以用 OD 来实现检查 mov 数量并且优化）同时如果发布时开硬件加速后，gpu 和 cpu 的比例就不是那么重要了，引擎本身可以提供该功能，并且可以把纹理传输和处理串行并行分开，更多情况下是确保合理性。
• Fps 代表每秒显示帧数，游戏会设定 1 个标准，也是通过测试的场景来验证，当某个场景下帧数降低是需要关注的，高于标准上限帧数也是无意义的，帧数同 cpu 在对应场景需要的是越平缓越好。
• 手机上数据采集的方式使用联线手机开启 debug 调式模式，adb shell，top -d 1 | grep 包名

• Pc 上数据采集使用 System\%Total Processor Time 性能计数器，Window 系统下自带的性能监控。

• “CPU 和 memory 都和硬件本身和系统有关联，产品本身问题也会影响硬件和系统” 这章会主要讲述 cpu 和内存，游戏本身当 cpu 和内存任意一项出现远超过阈值会导致 ANR 和 Crash，会影响用户流失。

• 游戏占用的资源较其他 app 较大，在游戏启动后，也需要对 im 工具和常用的手机 app 进行一些组合的验证。

一个良好的游戏会根据一般上线任务时间来衡量多少分钟后内存超过 xx 数值和手机逐渐发热 cpu 温度。这里的内存是指内存泄露，内存泄露分为 3 个类型，前 2 类，常发性和偶发性的危害并不大，通过划分模测试点和对于测试点进行行为组合的分析后，可以基本全部找到。偶发性可以借助 wins 自带性能监察工具来查看。隐性多发于服务器，客户端的隐性需要通过检查内存堆栈，从内存对象类型到引用对象看具体程序下方变化，需要有环境权限，这个也是程序员常用审查的方式。
内存泄露原理这里就不多做介绍了，常用参数包含在测试场景内，内存问题和 cpu 是关联的，可以从 cpu 浮动的区域，去定位精细测试内存的地方（这个也是外部检查隐性内存泄漏的办法）

测试场景如下，具体测试时 excel 的形式
不变的主题，先设计操作方式，在对应场景内执行。
操作方式如下：

• 触发 比如强化到某个等级，出现特殊的特效；比如升级到某个等级，触发新的引导或者事件等
• 跳转 包含打开某个界面，前往某个界面，返回某个界面
• 关闭 跳转回 1 级界面 【操作方式】+【测试场景】+ 操作多少次 测试场景需要确定是几级界面，几级界面跳转和返回，平级页面拖拽和切换都有关系。

测试场景 + 设计用例如下：

• 1 级主界面-2 级背包界面 这里增加内存大小会和背包里物品数量有关。
• 1 级主界面-2 级图鉴界面 打开图鉴界面，图鉴内激活数量也有关系
• 1 级主界面-2 级战役界面-2 级战斗 回到主界面后内存回收率降低，回到哪里才开始回收
• 1 级主界面-2 级活动界面 舞台元件回收，主界面效果等资源切换到另外 1 个复杂界面
• 2 级活动界面-2 级领取多次奖励 触发型的领取奖励
• 2 级活动界面第一个分页-2 级活动界面最后 1 个分页 依次每个分页图片资源解引用成功和回收率 … …

先确保内存池内存 xx 数值后，当上个事务结束后会强制回收多少，如果一直战斗不退回上级界面会如何。泄露的回收率，每次增加多少 mb，操作多少次后，平缓期后内存浮动变化和增量，回收率是多少。当发现被测场景出现疑似内存问题，可以采用冲击的办法，用多少次的行为来使现有的内存翻倍等（做测试数据用，证明该部份存在内存泄漏）
平缓期部分内容记录数字和平缓时间（数字可能分段注意看内存增量和减量是不是全记录了）
如果是 flash 或者其他制作的网页游戏测试起这个较简单，手机游戏最终 pc 和手机上误差是较大的，采取的记录方式是【初始内存记录】和【内存环节增量】和【回收率记录】
如果有条件的话，也可以开发自动化工具（代号 monkey），从各种分场景的做 xx 场景 - 事务下，1 个自动化采集 cpu 和内存，cpu 浮动和内存浮动，cpu 和内存高于某个数值时出现多少次这样的。
场景可以用开始和关闭事务来区分，打开某个界面可以调用 ccbi 等方式，关闭某个界面或者跳转也可以用这种方式（类似跳转 url）行为可以用动作序列实现，调用触屏 api，支持点击，滑动，按压。
横竖的 UI 需要记录瞄点，这里采用的就是录制手段，每个行动间隔时间可以设置 1000~3000 毫秒
生成的数据如下（如果打标签）：执行多少时间内 +【xx 事务】+【xx 行动】+【cpu 高于 xx 值】xx 次数 +【cpu 浮动率高于 xx%】次数 +【内存高于 xx 值】次数【内存浮动率高于 xx%】次数。
这里也可以集成 ANR 来一起做，不过我没有集成，内存-cpu 浮动不分家，内存以 cpu 做为 1 个重要参照，这里把 cpu 问题给一起做了。

当内存泄露的问题基本减低后，在考虑做纹理等内存警报的问题，关于这部分纹理内存警报批量修复和延伸部分可以减少 crash 数量的问题，后面交代。
内存泄漏也不是可以被完美解决的，设计场景更细一点这样修复也可以只针对某些场景进行修复。产品来说，主要还是确保在一定时间内内存不会超过某个定量的数值。内存问题这里告一个段落。

上线客户端性能 - 专项 Memory&cpu（二）jiazurongyu

关于 Cpu，游戏的分场景 Cpu：

• 登陆游戏
• 加载进入主界面 loading
• 主界面复杂场景 - 动态 - 移动 - 转向
• 主界面复杂场景 - 静态 - 远离 - 回到
• 进入战斗

• 任何场景结算数据

  游戏测试操作分场景进行，cpu 使用率在游戏每个环节内是基本固定的，需要关注的二个视角，用户操作视角的参数和指向操作目标用户的参数。
  Cpu 不同内存，需要集成一起做才有意义，根据分场景 1 个完整的性能报告包含：

• 响应时间 fiddler 热点来做。

• 加载效率 从 Activity 开始

• fps 根据场景设计，fps 浮动控制。

• GPU GPU 与 cpu 比例，渲染

• Memory 物理内存/虚拟内存转化控制

插入 1 个响应时间的部分，第一个请求和指定某个请求，这个已经是很成熟的技术了。网页游戏测试加载策略常用的工具 Fiddler,经过验证平移在手机游戏。
基本工作流:
打开 Fiddler 菜单项 Tools->Fiddler Options，点击 HTTPS 的 TAB，选中 Decrypt https traffic 和 Ignore server certificate errors(unsafe) 两项，配置 Fidder 允许监听 HTTPS.
配置 Fiddler 允许远程连接。点击 Connections，选中 Allow remote computers to connect，默认监听端口为 8888.
然后用 pc 机设置 1 个 wifi(比如猎豹 wifi)，设置端口号，用手机连接同区域网的 wifi，然后就可以对游戏进行抓包，分析相关流量数据。
验证结果:
可以根据这个验证残留资源，错误资源，缓存资源和资源大小去评估进入一些场景加载的时间。
也可以根据这个来计算资源消耗内存的大小，如果做了预加载这部分内容就不能这样计算。

Cpu 的场景可以用到从检查内存用例抽出一部分来，可以说先做内存方面的验证，可以具备这个优点。
当内存产生变化时，cpu 浮动也有变化，然后对这部分内容做疑似点，抽取出来测试。、
如果已经具备了自动化的团队，根据代号 monkey 也可以同时具备测试 Cpu 的情况。如果没有自动化，请看以下：
CPU>90%，整个机器会很卡，同时不重启，CPU 基本是很难降下来，为不可逆转的。当然你可以说用某电脑管家释放内存，当进程未结束时，内存释放的都是虚拟内存的那部分。一旦出现这样的阈值参数，是无效的。ps:这里需要注意 linux 可接受上限一般不超过 85%。
个人手机中配阈值是 75%~80%，根据系统本身硬件情况，基本去吃掉 30~35% 加上其他一些常用的 IM 工具算 10% 左右，产品程序是需要低于 40%，35% 更佳，在什么场景下高于 50% 是一定出现问题的。自动化可以帮你统计在什么场景，出现过几次。
有别内存的，额外几例场景：
#Cpu 在 Ui 层操作以外，会存在一些逻辑问题（多发在战斗中，战斗中取决多少个对象）。
#[活动关卡] 顺时针 [竞技场] 停顿 2 秒，cpu 变化最高点和浮动
# 连续顺时针走 1 圈，察看 cpu 是否平缓（观察），cpu 变化最高点和浮动
… …

以上是根据业务通用的，但是根据游戏类型和引擎有所区别，cpu 在游戏中承担较大的就是场景管理和绘制，cpu 过高一样会带来 fps 和 Gpu 的损耗，在后面专项客户端性能环节讲到。