-
测试:功能，性能，压力查看全部
-
ios常用工具xcode自带的instrument；安卓常用工具emmage和GT查看全部
-
还好还好哈查看全部
-
。查看全部
-
游戏开发:制作人 美术 测试查看全部
-
内存占用标准查看全部
-
通过bug数量分布判断版本是否稳定查看全部
-
bug提交标准查看全部
-
接口测试，jmete工具查看全部
-
客户端性能测试：客户端CPU使用率，客户端内存占有率，客户端网络流量使用情况，客户端耗电量，客户端帧频 使用工具：ios常用工具xcode自带的instrument;安卓emmage和gt查看全部
-
讲的过于简单，老师出个稍微复杂深度点的课程吧，付费的课程也好查看全部
-
1:案例分析查看全部
-
1测试用例编写 A格式 首页内容：（用例关键信息）用例名称，游戏版本，编写人，编写日期，修改人，修改日期、需求文档路径、备注信息 正文页内容：功能逻辑图（若有，便于理解）、用例id、模块名称、测试先决条件（入口）、输入信息、输出结果、备注信息 注意事项：用例有清晰的逻辑、一个输入只对应一个输出、保证每次更新用例后都有明确的记录标注、保证格式一致 B常用编写方法 等价类：一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，所以选取少量代表性测试数据代表整个数据 有效等价类：有意义的输入集合，可以验证程序的正常功能和流程 无效等价类：无意义的输入集合，验证特殊情况 边界值：对于输入或输出的边界值进行分析 适用：数值测试、字符串测试、数据类型测试等 因果图：输入与输出之间因果关系的一种关系图 适用于：输入条件较为复杂，存在多种可能组合（笛卡尔积）的情况 方法：识别出因（所有输入）、中间节点、果（所有输出），并且根据关系连接起来 判定表：可以通过因果图来生成的一种结果判定表格（因、中间节点、果，01表示是否存在） C注意事项 输入条件单一明确，不用容易引起误解的词，比如可能大概等 输出要可判断且明确，不用显示正确这种词汇 测试步骤要可执行 保证尽量高的覆盖度 能抽象合并的尽量抽象合并，避免无意义的冗余 2测试用例整理与维护 需求变化后及时更新并备注修改情况（修改内容、产品和开发负责人） 遇到冗余的测试用例，根据实际情况及时修改 注意测试用例的备份查看全部
-
功能模块划分（重整体，不要纠结细节） 划分原则 高内聚，低耦合：模块内关联度高，模块间关联度低 重整体，轻局部：功能整体上关注模块构成、逻辑和覆盖范围，不用纠结较为具体的细节 划分方法 功能流程法（小系统）：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分（然后再细化和查漏补缺。银行取钱：插卡 -- 输密码 -- 输入金额 --取钱 -- 退卡） 层次划分法（大系统）：按照逻辑层次逐层细化出模块，直至不能划分 类型划分法：按照功能内容的不同类型进行划分（如按照道具的不同类型进行划分） 注意点 不同方法适用于不同场景 有时候一个功能要结合多种方法进行划分 划分方法不重要，原则更重要 划分完成后，结合需求文档重新梳理，确保模块清晰、覆盖完整、符合需求设计查看全部
-
游戏开发团队包括制作人、策划、程序、美术、测试查看全部
举报
0/150
提交
取消