-
哈哈查看全部
-
哈哈查看全部
-
测试用例：需求文档分析 功能模块划分 测试用例编写 测试用例整理与维护
查看全部 -
测试：功能、性能、压力、兼容、接口、安全、日志、弱网
、gm工具、SDK
查看全部 -
游戏开发团队：制作人，策划，程序，美术，测试
查看全部 -
性能测试关注哪些指标？
CPU、内存、FPS（帧率）、网络、电量等等
查看全部 -
弱网测试的测试点：
网络信号差的情况下，高丢包率的网络环境，不同网络信号之间的切换，断线重连等对游戏运行的影响，前后数据一致的问题。
工具：macx系统：Network link Conditioner或Charles（Charles本是抓包工具但可以用于改变网络）
Windows系统：fiddler
查看全部 -
Bug的详解：
1.Bug的界定准则：是否符合需求和是否违反常识
2.Bug的生命周期：发现bug->和开发人员反应，修复bug->验证bug->通过后 关闭bug意味bug死亡（若是在验收bug时bug仍未修复，则重复以上步骤）
3.Bug的等级划分：一般4或5个等级（P0致命错误P1严总错误P2一般错误P3无关紧要错误）
4.Bug的提案标准：
a.标题：【模块名称】+简短描述
b.测试环境:标明测试试用的版本，系统，服务器，账号等
c.描述：bug的详细描述
d.重现步骤（重要）：重现bug的详细流程步骤及复现概率，让开发人员节省时间
e.期望结果：希望bug修复后的结果
f.备注（不重要）：日志信息（log），截图信息等
5.Bug验收标准：
a.严格按照复现步骤验证
b尽量使用发现bug时的测试环境
c.验证标注：需要注明验证的版本、服务器等
d.拓展：尽量思考，是否对其它功能有影响，做简单回归
e.注意点：验证不能只看前端展现，更应该关注后端数据。（比如前端显示的数据正确，但后端的数据库不正确）
5.BUG的跟踪与推动：
a.每个人都有责任跟踪自己的bug的修复状态
b.及时与开发沟通，了解修复状态并提供修复过程中的支持（比如需要bug的详细信息）
c.久不修复的bug需要与开发沟通，如果开发认为bug问题不大可以和需求确认如何处理，若真的问题不大就可以直接关闭bug了
d.bug修复后，需要及时验证
6.最好课以做个bug的数据分析，比如项目中bug等级的统计，各开发人员中未修复bug的统计等等
查看全部 -
（2）如何写好测试用例之——功能模块划分：
（老师个人观点，经验所得）
功能模块划分原则：
a.高内聚，低耦合（模块内的功能紧密联合若尝试分拆则分拆后的内容很难单独继续存在。模块与模块间的联系关联度低无法合并为一个模块）
b.重整体，轻局部（在划分模块式须有大局观，从功能整体的层面上去关注模块的构成，如模块的逻辑，模块的覆盖范围等等。划分模块时不要纠结于某些具体的细节）
功能模块划分方法：
a.功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺。
举例：请就银行ATM的取款功能进行模块划分？
插卡->密码登录->输入金额->取出钱币->取卡
b.层次划分法：按照逻辑层次逐层细化模块的过程，比较适用于UI划分，大的系统模块划分等。
举例：请就Dota这款游戏进行模块划分？
->账号登录
->战斗外内容 ......
->按键设置
DOTA
->英雄
->战斗内内容 ......
->道具
c.类型划分法：按功能内容的类型划分。适用于一种功能的种类相对独立，而且种类间的耦合度较低的情况。
举例：兵种测试，道具测试等。
兵种测试分（可训or不可训）
道具测试分（可消耗or不可消耗）
PS：具体问题具体分析，有时候一个功能可结合多种方法划分，注重划分原则，划分完毕后结合需求文档重新梳理。
查看全部 -
（1）如何写好测试用例——需求分档分析：
文档阅读：细读需求分档，加深对功能的理解，理解功能的设计意图和思路
细节沟通讨论：不明白的地方需要及时确认，尽早确认细节，关注需求变更，并在变更后与开发和策划确认
逻辑梳理：文档中的功能顺序有可能混乱，需梳理出框架后，逐步细化。
功能拓展思考
a.设计缺陷思考（看看策划人员是否策划周全）
b.测试难点思考（比如刷新问题：时间太长，测试需借助手段）
c.关联度思考（比如领取道具存放背包中，需考虑背包存放有无上限，领取的道具是叠加在一个框还是排列，若叠加一个框，一个框课叠加多少道具等）
d.特殊情况思考（比日领取道具时断网等等情况）
兼容相关思考：
a.版本兼容（同时存在两个版本的情况下功能兼容问题）
b.功能兼容（新功能添加文题，比如增加英雄，会不会导致老英雄功能的改变等等）
c.操作系统版本兼容（安卓系统或者ios系统or其它系统兼容问题）
d.分辨率兼容（不同的分辨率显示的效果可能不一样）
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容。ce shi gai gong neng dui qi ta gong neng de ying xiang (you xi de ou he du fei chang gao)
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试此功能对其他功能的影响。
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试。该功能。对其他。功能的。影响（游戏的。耦合度。非常的高）
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试该功能对其他功能的影响（游戏的耦合度非常的高）
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试该功能对其他功能的影响（游戏的耦合度非常的高）
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试该功能对其他功能的影响（游戏的耦合度非常的高）
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试该功能对其他功能的影响（游戏的耦合度非常的高）
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试该功能对其他功能的影响（游戏的耦合度非常的高）
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
查看全部 -
游戏测试基本流程（6个环节）：
功能需求会议——>测试用例编写——> 冒烟测试——>详细测试——>回归测试——>Checklist检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容，测试该功能对其他功能的影响（游戏的耦合度非常的高）
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
查看全部 -
游戏测试主要内容：
（1）功能测试：主要测试方法为黑盒测试。主要用来检验功能是否符合需求设计。主要用来考虑功能正确性，而不考虑游戏底层结构及代码错误。通常从界面着手测试，尽量模拟用户可能出现的操作。
（2）客户端性能测试：主要测试客户端的CPU使用率，内存占用率，网络流量使用情况，耗电量，帧率（FPS）。
iOS常用工具：xcode自带的instrument
安卓常用工具：emmage和GT
（3）服务端压力测试：服务器的CPU使用率，内存占用率，系统的吞吐量（TPS），事务响应时间，事务成功率
可使用工具：Jmeter
（4）兼容测试：机型匹配测试，操作系统兼容测试，屏幕分辨率兼容测试，游戏版本兼容测试。
（5）安全测试：内存修改测试，客户端加密测试，客户端反编译测试，网络安全测试。
（6）接口测试：主要测试服务端是否能正确分辨多个接口，接口安全测试，重复发送请求，查看接口处理情况。
测试工具：可用Jmeter工具实现或代码实现
（7）日志测试：客户端日志测试（通过玩家平时的日志，可以帮助我们排查游戏平时出现的bug），服务端日志测试（需要记录玩家平时详细的操作行为，方便我们根据玩家的行为作出数据分析）
（8）弱网测试：不同网络情况下，游戏的运行情况（如Edge,2g,3g,4g）。不同丢包率情况下游戏的运行情况（网络不好的情况下，丢包率严重）
可通过工具设置网络代理来实现，常用工具：fiddler,network link conditioner
（9）gm工具测试(一般运营人员和客服使用，方便规划游戏的活动或查询玩家数据)
（10）SDK测试（前端和后端数据库的存储及相关日志记录是否正确）：用户数据测试，充值、消费测试，与各个渠道对接测试
查看全部 -
游戏测试查看全部
-
游戏测试查看全部
-
1、游戏团队的简介 2、游戏流程的简介查看全部
举报