一、游戏测试用例设计思路

1、需求分析

面对一个逻辑性较强或较大的系统、模块时，需求分析能够帮助我们快速理解策划“想要的”、需求要“做什么”、“怎么做”，更重要的是需求分析是为了给测试用例的设计做铺垫，而用例设计是否优秀的一部分则来源于对需求理解是否足够透彻。

2、合理拆解测试模块

拆解游戏整体划分出子模块的分支测试点可以帮助测试人员更好的理解需求，梳理需求，为后续的测试用例设计进行铺垫，因游戏设计不同，拆解模块会存在差异

通常按照两个大类去拆解，即【功能性需求】与【非功能性需求】

功能性需求

·通过测试 文档中明确的需求规定，得到的结果均是通过的、正确的

· 失败测试 需求中所有是非判断，得到的结果均是否定的、不允许的

· 边界值测试 需求衍生出的边界值，介于允许与不被允许之间

非功能性需求

· 安全性测试 账号密码传输是否加密，多端登录是否互踢

· 性能压力测试 登录接口响应时间，高并发响应时间，高并发服务内存变化

· 兼容性测试 不同设备登录，不同分辨率显示是否正确

· 异常事件测试

· 网络相关测试 无网，断线，弱网

3、合理利用测试方法

等价类划分法

把所有可能输入的数据，即程序的输入域划分策划若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。也就是选用少量具有代表性的值来获得较好的测试结果。等价类分析法的重点是要正确的分析有效等价类和无效等价类，利用有效等价类来判定功能是否实现，利用无效等价类来判定功能无异常。在游戏中关于游戏关卡、游戏升级、属性等测试等价类划分的使用尤为常见。

边界值分析法

对输入或输出的边界值进行测试的一种测试方法，在一定程度上说来边界值分析法是等价类划分的补充。重点在于对临界值的验证，所以编写测试用例时要找对临界点，不过临界点可能有一个也可能是多个，有几个临界点便都做为边界值进行测试。需要选取刚刚大于或者刚刚小于的数据作为数据进行测试。边界的测试不仅仅局限于数值方面的边界，还包括空间位置和时间的边界值。

错误推断法

基于我们在平时的工作中的经验和直觉进行的，积累的经验越丰富也就越容易发觉我们所测功能的bug。重点就在于需要列举出易出错和可能出错的特殊情况，根据列举出来的进行测试用例的设计。

功能图法

针对逻辑复杂、功能庞大的功能来说的，它主要依附于功能的业务流程和业务逻辑进行。采用功能图（业务流程图、状态迁移图、菜单树）将功能的逻辑形象直观的展示出来，并确保路径和逻辑全都覆盖到。在某一逻辑复杂的游戏模块中，功能图可以快速的帮我们理清思路，将功能以测试用例的形式展示出来。

用户体验测试

还原用户场景，避免成为工具人，QA由于对需求的深度了解，对玩法规则的熟悉，很容易陷入惯性思维，思维麻木不敏感，则容易忽略新手体验，忽略测试case以外的bug和潜在需求，需要抛开自身的专业素养，把自己当成一个大众玩家，从玩家的角度和自身的游戏经验出发，发掘功能在实际运用中可能出现的需求，当了解两者的需求后，更有目的的编写测试用例，当两者的需求出现分歧或者差异时，需要格外留意

4、用例设计规范

系统性：业务需求梳理清晰，系统与系统、玩法之间的关系明确，列举出系统集成与数据牵连

全面性：设计内容覆盖全面、考虑周全，能够深入分析需求并解析为独立的测试用例

结构性：用例设计从上至下，从简单到复杂，设计结构清晰明确

可执行性：用例从上至下，用例具有顺序性，部分用例进行整合，便捷统一执行

可阅读性：用例语句通顺，无错别字、错误语句，阅读性高，易理解，清晰明了

可维护性：用例设计有维护信息，编写作者，最新修改时间等，用例维护更加便捷高效

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取