写机器人模拟人进行压力测试

服务端日志：记录玩家操作行为

客户端日志：客户端崩溃等

笔记

功能模块划分：

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

模块划分原则：

1、高内聚，低耦合

2、重整体，轻局部

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

模块划分方法1：

功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺；

举例：请就银行ATM的取款功能进行模块划分

插卡环节-密码登录环节-输入金额环节-取卡环节-取走钱币环节

模块划分方法2：

层次划分法：按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等；

举例：请就dota的这款游戏进行模块划分

dota-战斗外内容-战斗内内容-账号登录-按键设置-英雄-道具

动画-技能

模块划分方法3：

类型划分法：按照功能包含内容的不同类型进行划分

举例:兵种测试，道具测试等

兵种测试-可训练兵种-不可训练兵种

道具测试-可消耗道具-不可消耗道具

类型划分比较适用于一个功能种类相对独立，种类之间关联度较低的情况

模块划分注意事项

不同的划分方法适用不同的场景，要具体问题具体分析

有时候一个功能需要结合多种方法进行划分

划分方法不重要，划分原则更重要一些

划分完毕后，要结合需求文档重新梳理，确保模块清晰，覆盖完整

游戏测试基本流程：

功能会议-测试用例书写-详细测试-冒烟测试-回归测试-CHECKLIST检查

功能会议：1、了解功能需求内容2、提出可能存在的风险点3、思考功能的测试重点和难点，如需要工具辅助，需提出开发需求4、思考可以优化的地方，并提出讨论；

测试用例书写：

1、根据需求书写测试用例2、关注功能逻辑实现3、考虑各种特殊情况，如边界值、网络中断、进程中断等；

4、关注需求变更情况，需求经常发生变更，需要及时调整测试用例

冒烟测试:1、详细测试之前的一个环节2、快速发现比较明显的bug3、快速确保主逻辑流程跑通4、快速明确功能开展状态

详细测试：1、细致的测试每个逻辑分支、资源、配置2、尽量模拟玩家的每一种操作可能3、测试异常情况、如断网、断电、事件中断、进程中断等情况4、测试数据读取、存储、网络等内容5、测试该功能对其他功能的影响

回归测试：

测试已经被修复的内容、测试需求调整后的内容、再次详细测试各逻辑分支

checklist检查

1、简要快速的检查功能的主要逻辑点

2、简要检查与该功能有关联的任何其他功能点

游戏测试工作内容：

功能测试、性能测试、压力测试、兼容测试、安全测试、接口测试、日志测试、弱网测试、gm工具测试、SDK测试

功能测试：

1、是游戏测试中的最常见的模式、主要测试方法为黑盒测试；

2、主要用来验证功能是否符合需求设计

3、主要考虑功能正确性，而不考虑游戏底层结构及代码错误

4、通常从界面着手开始测试，尽量模拟用户可能出现的操作；

客户端性能测试：

1、客户端CPU使用率2、客户端内存占用率3、客户端网络流量使用情况4、客户端耗电量5、客户端帧率(FPS)

IOS常用工具xcode自带的instrument  安卓常用工具emmage和GT

服务端压力测试：

1、服务器CPU使用率 2、服务器内存占用率3、系统吞吐量（TPS）事务响应时间、事务成功率

兼容测试：机型适配测试、操作系统兼容测试、屏幕分辨率兼容测试、游戏版本兼容测试

安全测试：内存修改测试、客户端加密测试、客户端反编译测试、网络安全测试（）

接口测试：

1、服务器各个接口数据测试，主要通过工具来实现

2、接口安全测试，重复发送请求，查看接口处理情况；

日志测试：

客户端日志、服务端日志

弱网测试：不同网络情况，游戏的运行情况，如edge、2g、3g、4g情况

不同丢包率情况下游戏的运行情况

通过工具设置网络代理来实现，常用的fiddler、network link conditioner

gm工具测试：

1、测试gm工具的功能实现，需要关注工具的设置是否在游戏中起作用

2、测试gm工具的数据读取、存储

sdk测试：

用户数据测试、充值、消费测试、与各个渠道对接测试

游戏研发团队简介：

制作人（项目整体负责人）：

1、负责游戏研发环节

2、负责游戏运营环节

3、负责项目人员管理

4、负责项目事务管理

策划：

1、剧情：负责规划游戏中的各种剧情、故事、背景等；

2、系统：设计游戏中各种系统的规则

3、数值：规划游戏中各种资源的产出、消耗等；

4、关卡：设计游戏中各种关卡；

程序员：代码实现人员，负责把策划的设计及美术资源等通过编码实现成可玩的程序；

前端程序：实现游戏客户端的展现与逻辑

后端程序：实现服务器端的逻辑，数据验证等；

美术：制作游戏中的各类美术资源（场景、UI、原画、动画）

测试：项目的质量保证人员，主要工作是发现游戏中存在的缺陷并及时返回出来；

功能测试、性能测试、压力测试、兼容测试、自动化测试、安全测试

游戏开发流程：

制作人：制作项目目标，规划

策划：将项目目标拆解成细致的需求，并将需求细化成文案

测试-程序-美术：将需求用代码和美术资源实现出来，测试写测试用例

测试：对项目各个方面进行质量控制，将发现的缺陷反映出来

游戏接口测试的主要内容

1. 客户端与服务端之间的网络接口测试【修改参数】【重复发包】

2. Jmeter或者脚本语言

3. 
   

Bug详解

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

2. bug的界定标准

1. 与需求设计不符

2. 违背常识

3. bug提报标准

1. 标题【模块】+简短描述

2. 测试环境：版本，系统，服务器，账号

3. 描述：详细描述

4. 重现步骤：重新啊bug的详细流程步骤及复现概率

5. 希望结果：修复后结果

6. 备注：log，截图
   

4. bug验证标准

1. 严格按照复现步骤验证

2. 去除测试环境的影响

3. 验证标注：注明时间

4. 扩展：是否对其他肝功能有影响，做简单回归

5. 注意点：验证不能只看前段展现，更应关注后端数据

5. bug的跟踪与推动

1. 有责任跟踪

2. 及时与开发沟通，了解修复状态病提供修复过程中的支持

3. 不修复的bug需要与开发和上级确认

4. bug修复后，需要及时验证
   

测试用例编写

1. 格式

1. 为什么重要？

1. 脉络清晰明了

2. 方便需求变化后的更新维护

3. 方便执行人员上手
   

2. 首页内容

1. 名称

2. 对应版本

3. 编写人，编写日期，备注

4. 需求文档链接
   

3. 正文页内容

1. 功能逻辑图

2. 用例id

3. 模块名称

4. 测试先决条件

5. 输入信息

6. 输出结果

7. 备注信息
   

2. 常用的测试用例编写方法

1. 等价类：金币不足时购买道具10【有效等价类】10,11+【无效等价类】9

2. 边界值：【刚好相等】【刚刚小于】【刚刚大于】数值测试，字符串测试

3. 因果图&判定表：自动售货机，找钱和产品
   

3. 测试用例整理与维护

1. 更新测试用例，并修改备注

2. 尽量避免冗余

3. 用例的备份，本地也备份一份，避免线上误删除
   

功能模块划分

1. 遵循原则

1. 高内聚，低耦合【货币购买，月卡+普通货币购买】

2. 重整体，轻局部【货币购买，UI购买】
   

2. 划分的方法

1. 功能流程法：画出来，根据流程每个大环节进行模块划分，然后再细化和查漏补缺

2. 层次划分法：逻辑层次，比较适合UI划分【战斗内【账号登陆，按键】、战斗外【英雄【动画，技能】，道具】】

3. 类型划分法：道具测试【可消耗、不可消耗道具】

3.注意事项

    1.具体问题具体分析


    2.原则更重要


    3.根据需求文档重新梳理，模块清晰，功能完整

测试用例

1. 需求文档分析

1. 文档阅读--至少读3遍文档？意图，遗漏，深入理解，带着思考（设计的角度）

2. 细节沟通探讨--不明白的地方，细节确认，关注需求变更

3. 逻辑梳理--功能交叉，框架到细化

4. 功能拓展思考--设计缺陷，测试难点【活动更新时间】，关联度【item叠放，包压力】，特殊情况

5. 兼容相关思考--版本兼容【交易、对战】，功能兼容【老功能中新特性，英雄新】，操作系统版本兼容，分辨率兼容【图片缝隙，图片偏移，按钮挡住】
   

2. 功能模块划分

3. 测试用例编写
   

test content

testing

games

遊戲接口測試

什麼是接口?

常見的接口分類

程序自身內部的模塊接口

程序暴露給外部其他程序調用的接口

遊戲接口測試的主要內容

客戶端與服務端之間的網路接口測試

遊戲接口測試常用工具

Jmeter或者腳本語言(python)自己寫

客戶端性能測試指標

我們該關注哪些指標?

CPU 內存 FPS

客戶端性能測試指標-CPU

這裡指的是遊戲所占用的CPU占用率

拋開場景談CPU性能無意義

android設備，建議90%的場景CPU占用小於60%

ios設備，建議90%的場景占用小於80%

游戏接口测试

什么是接口？代码暴露出一部分属性或方法

常见的接口分类 1.程序自身内部的模块接口 2.程序暴露给其他程序调用的接口

弱网测试要解决的问题：1、网络信号差的情况下，对游戏运行的影响2、高丢包率的网络环境，对游戏的影响3、不同网络信号之间切换时，对游戏运行的影响4、短线重连对游戏运行的影响5、前后端数据一致的问题

BUG详解（发现BUG仅仅是测试工作的开始）

BUG 的界定标准；1.与需求设计不符 2.违背常识

测试用例编写
1.格式

一个清晰的格式为何重要？

a·首页内容：（用例关键信息）1.用例名称，2.用例对应的游戏版本，3.编写人，编写日期备注，3.修改人，修改日期、修改备注4.需求文档的链接地址

b·正文页内容：1功能逻辑图（若有，便于理解）、2用例id、3模块名称、4测试先决条件（入口）、5输入信息6、输出结果、7备注信息

c·关于格式的注意事项：1用例有清晰的逻辑2、一个输入只对应一个输出、3保证每次更新用例后都有明确的记录标注4、保证格式一致
2.常用编写方法
a·等价类：一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，所以选取少量代表性测试数据代表整个数据
有效等价类：有意义的输入集合，可以验证程序的正常功能和流程
无效等价类：无意义的输入集合，验证特殊情况

b·边界值：1.对于输入或输出的边界值进行分析2.边界值的确定；一般选取正好等于，刚刚小于和刚刚大于3种情况做为测试数据4·适用范畴：数值测试、字符串测试、数据类型测试等

c·因果图：1·输入与输出之间因果关系的一种关系图
适用于：输入条件较为复杂，存在多种可能组合（笛卡尔积）的情况
方法：识别出因（所有输入）、中间节点、果（所有输出），并且根据关系连接起来
2·判定表：可以通过因果图来生成的一种结果判定表格（因、中间节点、果，01表示是否存在）

3.因果图尝尝与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例

3·

4.注意事项
输入条件单一明确，不用容易引起误解的词，比如可能大概等
输出要可判断且明确，不用显示正确这种词汇
测试步骤要可执行
保证尽量高的覆盖度
能抽象合并的尽量抽象合并，避免无意义的冗余
5·测试用例整理与维护
需求变化后及时更新并备注修改情况（修改内容、产品和开发负责人）
遇到冗余的测试用例，如果遇到重复用例，根据实际情况及时修改
注意测试用例的备份

功能模块划分

（1）划分原则：（博主自己的总结，不存在与任何软件测试书籍中）

1、高内聚，低耦合：模块内关联度高；模块间关联度低，无法合并成一个模块

比如一个货币购买的功能，月卡的购买和普通货币的购买可以划分成两个单独的模块，因为两者几乎不存在任何关联度，购买其中任何一个模块不会对另一个模块产生影响，符合低耦合的原则；

如果就月卡的购买进行分拆的话，显然没必要继续划分成功能和UI两个模块，因为月卡的购买流程非常简单，而且功能之间的关联度非常高，符合高内聚的原则。

2、重整体，轻局部：功能整体上关注模块构成、逻辑和覆盖范围，轻局部不用纠结较为具体的细节

还是以货币的购买功能为例，整体上可以划分为UI、购买与领取、特殊情况等大模块，或许也可以划分成一些子模块；不用太关注细节，比如页面上显示的倒计时、UI按钮的位置等等

（2）划分方法：（博主自己的总结，不存在与任何软件测试书籍中）

1、功能流程法（小系统）：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺

举例;（银行取钱模块划分：插卡 -- 输密码 -- 输入金额 --取钱 -- 退卡）

2、层次划分法（大系统）：按照逻辑层次逐层细化出模块，比较适用于UI划分，大的系统模块划分等

（dota游戏模块划分：见截图）

3、类型划分法：按照功能内容的不同类型进行划分（如按照道具的不同类型进行划分）

注意点

不同方法适用于不同场景 具体问题具体分析

有时候一个功能要结合多种方法进行划分

划分方法不重要，划分原则更重要

划分完成后，结合需求文档重新梳理，确保模块清晰、覆盖完整、符合需求设计

游戏测试基本流程（6个环节）：

1.功能需求会议——>2.测试用例编写——> 3.冒烟测试——>4.详细测试——>5.回归测试——>6.Checklist检查

（1）功能需求会议(一般策划人员开)：1.测试人员需了解需求内容，2.提出可能存在的风险点，3.思考功能的测试重点和难点，如需工具辅助，需提出开发要求，4.思考可以优化的地方，并提出导论。

（2）测试用例编写：1.根据需求书写测试用例，2.关注功能逻辑实现，3.考虑各种特殊情况（如边界值，网络中断，进程中断等），4.关注需求变更情况，需要及时调整测试用例。

（3）冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：1.详细测试前的一个小环节，2.快速发现比较明显的bug3.快速确保主逻辑流程跑通，4.快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）

（4）详细测试：1.细致的测试每个逻辑分支、资源、配置，2.尽量模拟玩家的每一种操作可能3.，测试异常情况（如断网，断电，事件中断、进程中断等），4.测试数据读取、存储、网络等内容。5.测试该功能对其他功能影响

（5）回归测试：1.测试已经被修复的内容，2.需求调整后的内容，3.再次详细测试各逻辑分支。

（6）checklist（检查点，快速，不细测，可有可无，发布版本时测试）：1.简要快速的检查功能的主要逻辑点，2.检查与该功能有关联的任何其他功能点。

1、游戏开发团队：制作人、策划、程序、美术、测试

bug的生命周期

Bug的提报标准

• 

• 注意点

优先级P0 致命   立即修复

          p1 严重   紧急修复

          p2 一般   允许一段时间内修复

          p3 提示   允许延期修复

bug的提报标准

需求文档分析

功能模块划分

测试用例编写

测试用例整理与维护

文档阅读

细节沟通探讨

逻辑梳理

功能拓展思考

兼容相关思考

游戏测试基本流程

测试工作人员

功能会议

测试用例书写

冒烟测试

详细测试

回归测试

checklist检查

弱网测试

edge， 2g ，3g， 4g

不同丢包概率的情况

工具  fiddler  , network link conditioner(xcode提供的工具)

gm工具测试

测试gm工具的功能实现

测试gm工具的数据方面

sdk测试

用户数据测试

充值消费测试

各个渠道对接测试（日志数据，前后端数据对应）

功能测试

性能测试

压力测试

兼容测试

安全测试

接口测试

日志测试

弱网测试

gm测试

sdk测试

事务成功率，响应时间

兼容性测试

压力测试

性能测试

功能测试

游戏版本兼容测试

操作系统兼容测试

屏幕分辨率测试

安全测试

内存修改测试

加密测试

反编译测试

网络安全测试   明文or密文传输    

接口测试  

日志测试

客户端测试日志   服务器测试日志