手游测试（测试内容、测试流程、测试用例）

文章目录

游戏测试的主要内容
游戏测试基本流程
游戏测试用例
游戏bug
游戏弱网测试
游戏功能性测试
游戏接口测试

游戏测试的主要内容

功能测试
- 主要验证功能是否符合需求设计
- 主要考虑功能正确性，不考虑游戏底层结构及代码错误
- 通常从界面着手测试，尽量模拟用户可能出现的操作
性能测试
- 测试点
  - 客户端CPU使用率
  - 客户端内存占用率
  - 客户端网络流量使用情况
  - 客户端耗电量
  - 客户端帧率（FPS）
- 测试方法
  - 分析代码
  - 工具监测
    - iOS：xcode自带的instrument
    - 安卓：emmage和GT（需要root权限）
压力测试
- 服务器CPU使用率
- 服务器内存占用率
- 系统吞吐量（TPS）
- 事务响应时间
- 事务成功率
兼容测试
- 机型适配测试
- 操作系统兼容测试
- 屏幕分辨率兼容测试
- 游戏版本兼容测试
安全测试
- 内存修改测试
- 客户端加密测试
- 客户端反编译测试
- 网络安全测试（用抓包工具测试避免重复抓包）
接口测试
- 服务器各个接口数据测试，主要用工具来实现
- 接口安全测试，重复发送请求，查看接口处理情况
日志测试
- 客服端日志
- 服务端日志
弱网测试
- 测试点
  - 不同网络情况下游戏的运行情况
  - 不同丢包率情况下游戏的运行情况
  - 通过工具设置网络代理来实现
    - 常用的工具 win:fiddle、mac:network link conditioner
gm工具测试（运营、客服人员使用）
- 测试gm工具的功能实现，需要关注工具的设置是否在游戏中起作用
- 测试gm工具的数据读取、存储
SDK测试
- 用户数据测试
- 充值、消费测试
- 与各个渠道对接测试

游戏测试基本流程

流程
- 功能会议->测试用例书写->冒烟测试->详细测试->回归测试->checklist检查
冒烟测试
- 详细测试之前的环节
- 快速发现比较明显的bug
- 快速确保主逻辑流程跑通
- 快速明确功能开展状态
详细测试
- 细致的测试每个逻辑分支、资源、配置
- 尽量模拟玩家的每一种操作可能
- 测试异常情况，如断网、断电、事件中断、进程中断等
- 测试数据读取、存储、网络等内容
- 新功能对原功能的影响
checklist检查（用于上线,，可通过代码提交记录进行简单测试，确定最终包含有所有功能及bug修复点）
- 简要快速的检查功能的主要逻辑点
- 简要检查与该功能有关联的任何其他功能点

游戏测试用例

设计步骤
- 需求文档分析->功能模块划分->测试用例编写->测试用例整理与维护
需求文档分析
- 文档阅读（至少读三遍，注意细节）
- 功能细节沟通探讨
  - 尽早确认细节
  - 不明白的地方不能脑补想当然
  - 关注需求变更，跟程序和策划确认
- 逻辑梳理
  - 梳理出框架后，逐步细化
- 功能拓展思考
  - 设计缺陷思考
  - 测试难点思考
  - 关联度思考
  - 特殊情况思考
- 兼容相关思考
  - 版本兼容
  - 功能兼容（新增的功能和以往）
  - 操作系统版本兼容
  - 分辨率兼容
功能模块划分
- 模块划分原则
  - 高内聚、低耦合
  - 重整体、轻局部
- 模块划分方法
  - 功能流程法
    - 将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，再细化和查漏补缺（不要纠结细节）
- 层次划分法
  - 按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等。
- 类型划分法
  - 按照功能包含内容的不用类型进行划分
  - 适合功能种类比较独立，种类之间的耦合度比较低的情况
测试用例编写
- 格式
  - 一个清晰的格式为什么很重要
    - 让用例的脉络更清晰明了
    - 方便需求变化后的更新维护
    - 方便执行人员快速入手
  - 首页内容（用例的纲要）
    - 用例名称
    - 用例对应的游戏版本
    - 编写人、编写日期、备注
    - 修改人、修改日期、修改备注
    - 需求文档的链接或地址
  - 正文页内容
    - 功能逻辑图（可有可无）
    - 用例id
    - 模块名称
    - 测试先决条件
    - 输入信息
    - 输出结果
    - 备注信息
  - 关于格式的一些注意点
    - 尽量保证逻辑清晰
    - 尽量保证一个输入只对应一个输出
    - 保证每次更新用例后都有明确的记录标注
    - 尽量保证一个用例内格式统一
测试用例常用编写方法
- 等价类
- 边界值
- 因果图&判定表
- 注意点
  - 输入条件一定要单一明确，不用引起误会的词
  - 输出要可判断且明确，不用“显示正确”这种词
  - 测试步骤要可执行
  - 保持尽量高的覆盖度
  - 能抽象的尽量抽象出来，避免无意义的冗余，用比较有代表性的数据
- 测试用例的整理和维护
  - 需求变化后需要即使更新老的测试用例，并写清修改情况的备注（修改内容，产品和开发负责人）
  - 测试用例应该尽量避免冗余，如果遇到重复的用例，需要根据实际情况进行修改
  - 注意测试用例的备份，写完后最好自己本地备份，避免线上被人误删除

游戏bug

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

bug的界定标准
- 与需求设计不符
- 违背常识
bug的生命周期
- 发现bug->提交给开发->开发修复->测试验证->通过后关闭->（上线前回归）
- 发现bug->提交给开发->开发修复->测试验证->不通过->重复流程->通过后关闭
bug的等级划分
- p0：致命错误
  - 需要立即修复，如宕机、重启性报错等
- p1：严重错误
  - 需要紧急修复，如功能流程错误、数值错误等
- p2：一般错误
  - 允许一段时间内修复，如功能的简单错误、界面错误等
- p3：无关紧要的错误
  - 允许延期修复，如文字错误、某个像素点缺失等
bug的提报标准
- 标题：[模块名称]+简短描述
- 测试环境：表名测试用的版本，系统，服务器，账号等
- 描述：bug的详细描述
- 重现步骤：重现bug的详细流程步骤及复现频率
- 期望结果：希望bug修复后的结果
- 备注：log，截图等
bug的验证标准
- 严格按照复现步骤验证
- 去除测试环境的影响
- 验证标注：需要注明验证的版本、服务器等
- 拓展：是否对其他功能有影响，做简单回归，因为系统间的逻辑耦合性很高
- 注意点：验证不能只看前端表现，更应该关注后端数据
bug的跟踪与推动
- 每个人都有责任跟踪自己的bug修复状态
- 及时与开发沟通，了解修复状态并提供修复过程中的支持
- 久不修复的bug需要与开发和上级确认如何处理
- bug修复后，需要即使验证
bug的数据分析
- 项目各个bug等级数量的矩形图
- 项目各个开发者bug数量的饼图
- 项目各个功能模块bug数量的矩形图

游戏弱网测试

要解决的问题
- 网络信号差的情况下，对游戏运行的影响
- 高丢包率的情况下，对游戏运行的影响
- 不同网络信号之间切换时，对游戏运行的影响
- 断线重连对游戏运行的影响
前后端数据一致的问题
- 测试方法
  - mac：network link conditioner或charles
  - win：fiddle