1. 设计步骤

1. 需求文档分析

1.1 文档阅读

• 切忌不阅读需求文档，上来直接写用例，至少读三遍文档
  1 细致理解功能设计意图和设计思路
  2 避免粗略理解带来的用例遗漏
  3 一些重要数据可能隐藏在不起眼的语句中
  4 加深对功能的理解，否则随着时间推移，可能会遗忘很多内容
• 带着思考去阅读，如果让你设计这个功能，还有更优的选择吗？

1.2 功能细节沟通探讨

• 不明白的地方需要及时确认，切忌脑补想当然
• 尽早确认细节，最好在开始写之前就确认完毕
• 关注需求变更，需求变更后，一定要跟程序和策划确认

1.3 逻辑梳理

• 文档不一定是按照流程顺序写的，而且经常存在功能交叉的地方
• 我们需要先梳理出框架后，逐步细化

1.4 功能拓展思考

• 设计缺陷思考：升级；拆解；道具；领取道具的数量，次数
• 测试难点思考：领取次数，刷新（测试，不能直接等）
• 关联度思考：道具存储问题
• 特殊情况思考：断电，断网，服务器维护

1.5 兼容相关思考

• 版本兼容：同时存在两个版本时，不同的版本
• 功能兼容：老功能中添加新英雄
• 操作系统版本兼容：mac，windows
• 分辨率兼容：美术展示等

2. 功能模块划分

2.1 功能模块划分时应遵循什么样的规则？

• 高内聚，低耦合：购买月卡和购买单个分开
• 重整体，轻局部：从整体关注

2.2 功能模块划分有哪些比较好的方法

• 功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查缺补漏。
  举例：请就银行ATM的取款功能进行模块划分：
  插卡环节–>密码登录环节–>输入金额环节–>取走钱币环节–>取卡环节
• 层次划分法：按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等。
  举例：请就dota这款游戏进行模块划分
  dota–>战斗内的内容–>英雄–>动画；技能
  dota–>战斗内的内容–>道具
  dota–>战斗内的内容–>地图
  dota -->战斗外的内容–>账号登录；按键设置
• 类型划分法：按照功能包含的内容的不同类型进行划分。
  举例：兵种测试，道具测试等。
  兵种测试：可训练兵种和不可训练兵种
  道具测试：可消耗道具和不可消耗道具
  类型划分法比较适用于一个功能种类相对独立，种类之间关联度较低的情况。

2.3 模块划分注意事项

• 不同的划分方法适用不同的场景，要具体问题具体分析
• 有时候一个功能选哟结合多种方法进行划分
• 划分方法不重要，划分原则更重要一些
• 划分完毕后，要结合需求文档重新梳理，确保模块清晰、覆盖完整。

3. 测试用例编写

3.1 格式

• 一个清晰的格式很重要
  1 让用例的脉络更清晰明了
  2 方便需求变化后的更新维护
  3 方便执行人员快速入手

• 首页内容
  1 用例名称
  2 用例对应的游戏版本
  3 编写人、编写日期、备注
  4 修改人、修改日期、修改备注
  5 需求文档的链接或地址
  

• 正文页内容
  1 功能逻辑图(如果有)
  2 用例id
  3 模块名称
  4 测试先决条件
  5 输入信息
  6 输出结果
  7 备注信息
  

• 关于格式的一些注意点
  1 尽量保证逻辑清晰
  2 尽量保证一个输入只对应一个输出
  3 保证每次更新用例后都有明确的记录标注
  4 尽量保证一个用例内格式统一

3.2 常用的测试用例编写方法

• 等价类划分
  等价类：指的是一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，此时我们就可以选取少量代表性的测试数据来代表整体数据。
  等价类分为有效等价类和无效等价类
  有效等价类：是对输出来讲有意义的输入集合，可以验证程序的正常功能和流程。
  无效等价类：是对输出无意义的输入组合，用于验证非正常流程输入对输出的影响。
  

• 边界值分析
  1 边界值：对输入或输出的边界值进行分析的一种方法
  2 边界值的确定：一般选取正好等于，刚刚小于和刚刚大于3种情况作为测试数据
  3 通常适用的范畴：数值测试，字符串测试，数据类型测试等
  

• 因果图&判定表
  1 因果图：简单来说就是输入与输出之间因果关系的一种关系图
  2 判定表：可以通过因果图来生成的一种结果判定表格
  3 因果图常常与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例
  
  
  
  

3.3 测试用例编写注意事项

• 输入条件要单一明确，尽量不用容易引起误解的词，比如可能，大概等。
• 输出要可判断且明确。最好不用“显示正确”这种词汇
• 测试步骤要可执行
• 保持尽量高的覆盖度
• 能抽象的尽量抽象出来，避免无意义的冗余。

4. 测试用例整理与维护

• 需求变化后需要及时更新老的测试用例，并写清修改情况的备注(修改内容，产品和开发负责人)
• 测试用例应该尽量避免冗余，如果遇到重复的用例，需要根据实际情况进行修改
• 注意测试用例的备份，写完后最好自己本地也备份一份，避免线上被人误删

2. 游戏测试bug详解

2.1 BUG详解：

• 发现bug仅仅是测试工作的开始

2.2 BUG的鉴定标准：

• 与需求设计不符
• 违背常识

2.3 BUG的生命周期：

发现bug --> 提交给开发 --> 开发修复 --> 测试验证 --> 通过后关闭–> 上线前回归
测试验证如果不通过 --> 不通过继续指派给开发

2.4 BUG的等价划分：

• P0：致命错误，需要立即修复，如宕机，重起性报错等
• P1：严重错误，需要紧急修复，如功能流程错误、数值错误等
• P2：一般错误，允许一段时间内修复，如功能的简单错误、界面错误等
• P3：无关紧要的错误，允许延期修复，如错别字、某个像素点缺失等等

2.5 BUG的提报标准

• 标题：【模块名称】+ 简短描述
• 测试环境：标明测试用的版本，系统，服务器，账号等。
• 描述：bug的详细描述，卡住可继续前进，卡住不能走
• 重现步骤：重现bug修复后的结果
• 备注：log，截图等
  

2.6 BUG的验证标准：

• 严格按照复现步骤验证
• 去除测试环境影响
• 验证标准：需要注明验证的版本、服务器等
• 拓展：是否对其他功能有影响，做简单回归
• 注意点：验证不能只看前端展现，更应关注后端数据

2.7 BUG的跟踪与推动：

• 每个人都有责任跟踪自己的bug的修复状态
• 及时与开发沟通，了解修复状态并提供修复过程中的支持
• 久不能修复的bug需要与开发和上级确认如何处理
• bug修复后，需要及时验证

2.8 BUG的数据分析：

1 从bug级别：P2等级bug比较多，P0、P1较少，说明项目可以
2 从项目人员bug数据：
3 功能模块bug数据：

3. 弱网测试

弱网测试指：在客户端和服务器之间进行数据传输时发生的情况。
弱网测试案例：地铁、火车、边远地区、高层建筑、汽车经过隧道，边远地区等等。通过特定工具模拟

3.1 弱网测试要解决的问题

• 网络信号差的情况下，对游戏运行的影响
• 高丢包率的网络环境，对游戏运行的影响
• 不同网络信号之间切换时，对游戏运行的影响
• 断线重连对游戏运行的影响
• 前后端数据一致的问题

3.2 测试方法

• 不同的系统，使用的工具不一样
• mac系统可以借助于Network Link Conditioner或Charles
• windows系统借助于Fiddler这个工具
  xcode --> open developer tool --> more developer tools
  登录 – > 找 Hardware IO tools for xcode下载好
  打开，Network Link Conditioner安装， 系统偏好设置

4. 客户端性能测试–安卓

4.1 客户端性能测试指标

CPU

• 这里指的是游戏进程所占用的cpu占用率
• 抛开场景谈cpu性能无意义
• 安卓设备，90%的场景cpu占用小于60%
• ios设备，90%场景cpu占用小于80%

内存(举例)

FPS(举例)

使用emmagee或GT模拟工具，顶部会出现一些使用信息

5. 客户端性能测试–ios

xcode --> open developer tool -->instruments -->
测cpu和内存： instruments --> Activity Monitor
连接手机，选好app后点recode
测FPS：instruments --> core animation
连接手机，选好app后点recode

6. 游戏接口测试

接口：代码暴露出来的属性和方法

6.1 常见的接口分类

• 程序自身内部的模块接口
• 程序暴露给外部其他程序调用的接口

6.2 游戏接口测试的主要内容

• 客户端与服务器之间的网络接口测试

6.3游戏接口测试常用工具

使用Jmeter或者脚本语言自己写