关于移动游戏公司品质管理 (一)

本帖已被设为精华帖！,

引言

本文以移动端为载体，本来想拿公司名义发的，笔者（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的损耗，在后面专项客户端性能环节讲到。