手游测试-学习笔记

文章目录

      • 游戏测试的主要内容
      • 游戏测试基本流程
      • 游戏测试用例
      • 游戏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修复点)
    • 简要快速的检查功能的主要逻辑点
    • 简要检查与该功能有关联的任何其他功能点

游戏测试用例

  • 设计步骤
    • 需求文档分析->功能模块划分->测试用例编写->测试用例整理与维护
  • 需求文档分析
    • 文档阅读(至少读三遍,注意细节)
    • 功能细节沟通探讨
      • 尽早确认细节
      • 不明白的地方不能脑补想当然
      • 关注需求变更,跟程序和策划确认
    • 逻辑梳理
  • 层次划分法
  • 测试用例编写
    • 格式
      • 一个清晰的格式为什么很重要
        • 让用例的脉络更清晰明了
        • 方便需求变化后的更新维护
        • 方便执行人员快速入手
      • 首页内容(用例的纲要)
        • 用例名称
        • 用例对应的游戏版本
        • 编写人、编写日期、备注
        • 修改人、修改日期、修改备注
      • 关于格式的一些注意点
        • 尽量保证逻辑清晰
        • 尽量保证一个输入只对应一个输出
        • 保证每次更新用例后都有明确的记录标注
        • 尽量保证一个用例内格式统一
  • 测试用例常用编写方法
    • 等价类
    • 边界值
    • 因果图&判定表
    • 注意点
      • 输入条件一定要单一明确,不用引起误会的词
      • 输出要可判断且明确,不用“显示正确”这种词
      • 测试步骤要可执行
      • 保持尽量高的覆盖度
      • 能抽象的尽量抽象出来,避免无意义的冗余,用比较有代表性的数据
    • 测试用例的整理和维护
      • 需求变化后需要即使更新老的测试用例,并写清修改情况的备注(修改内容,产品和开发负责人)
      • 测试用例应该尽量避免冗余,如果遇到重复的用例,需要根据实际情况进行修改
      • 注意测试用例的备份,写完后最好自己本地备份,避免线上被人误删除
  • 游戏bug

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

    • bug的界定标准
      • 与需求设计不符
      • 违背常识
    • bug的生命周期
      • 发现bug->提交给开发->开发修复->测试验证->通过后关闭->(上线前回归)
      • 发现bug->提交给开发->开发修复->测试验证->不通过->重复流程->通过后关闭
    • bug的等级划分
      • p0:致命错误
        • 需要立即修复,如宕机、重启性 错等
      • p1:严重错误
        • 需要紧急修复,如功能流程错误、数值错误等
      • p2:一般错误
        • 允许一段时间内修复,如功能的简单错误、界面错误等
      • p3:无关紧要的错误
        • 允许延期修复,如文字错误、某个像素点缺失等
    • bug的提 标准
      • 标题:[模块名称]+简短描述
      • 测试环境:表名测试用的版本,系统,服务器,账 等
      • 描述:bug的详细描述
      • 重现步骤:重现bug的详细流程步骤及复现频率
      • 期望结果:希望bug修复后的结果
      • FPS
        手游测试-学习笔记

    游戏接口测试

    • 常见接口分类
      • 程序自身内部的模块接口
      • 程序暴露给外部其他程序调用的接口
    • 游戏接口测试内容
      • 客户端与服务端之间的 络接口测试
        • 修改传输参数
        • 大量发送数据
    • 游戏接口测试工具
      • jmeter(基于Java,需要安装Java环境)
      • 自己写脚本语言

    声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

    上一篇 2019年5月8日
    下一篇 2019年5月8日

    相关推荐