手游测试内容、测试流程、测试用例设计
- 格式:docx
- 大小:130.84 KB
- 文档页数:11
手游测试内容、测试流程、测试用例设计游戏测试的主要内容
功能测试
主要验证功能是否符合需求设计
主要考虑功能正确性,不考虑游戏底层结构及代码错误
通常从界面着手测试,尽量模拟用户可能出现的操作
性能测试
测试点
客户端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的详细描述