《游戏测试》你真的会写用例吗？

我现在真的是对游戏测试又爱又恨，爱的是我正在做这个，这是对游戏行业很重要的一个岗位；恨的是水平良莠不齐，很多人工作多年连用例都不会写，难怪一直被说游戏测试门槛低。

记得刚开始工作的时候，网上游戏测试相关的文章很少，大家也都不懂，什么都是一板一眼学软件测试的，比如测试前都会认真的分析策划文档，找测试点，画状态图，画流程图；然后认认真真在excel表上写用例，操作步骤一步步写下来。

现在你在让大家这样写用例，大家会像见到外星人一样看你。

我们先看看大家写用例经常出现的问题： 

1、格式问题

1. 极简主义（标题和正文没有任何区分，正常用例要素不全）
2. 花里胡哨（搞了太多颜色，相当刺眼）

2、用例基础

1. 用例要素缺失，BUG单号、用例描述测试目的、这两项是大家经常会缺失的部分，实际这两部分内容对用例来说也很重要，BUG单号是缺陷平台里BUG单的ID，方便测试人员关注该BUG的处理进度。用例描述测试目的，是简要说明该条用例想要测试的点。
2. 多个测试点混在一条用例里这个是用例里面最常见的问题了，很多时候为了偷懒，就一条用例测N多内容，甚至一整个界面，就是一条测试用例。（记住测试用例的原则：一条用例只测试一个功能点）
3. 测试步骤条理不清很多时候大家写用例都只是给自己看，写的测试步骤跟月底的钱包一样，要多干净有多干净。详细的测试步骤除了方便其他人看之外，也能最大还原当时的测试情况，方便你去重现问题。错误（×）正确（✔）
4. 测试内容过于冗余有些同学写等级相关用例的时候，真的是每一级都写，我真的是谢谢你了。
5. 测试数据不是具体数据，喜欢用符号或者其他量词代替。

3、逻辑不清

大家写用例的时候，思路比较混乱，基本上都是按照策划文档从头到尾的顺序来写用例，写的过程中会发现前面好像已经写过这里了，怎么又要写。同类型的模块又没有整理到一起，前面一部分，后面一部分，很不方便后期阅读。

像我这边一般会按照流程图的方式来写用例，从头到尾，简单又清晰。

5、补充学习

游戏测试同学很少有在校接触过理论学习，自己也不大喜欢看理论资料，要学习估计也是去学自动化测试、性能测试、大数据测试、AI智能测试。没办法，不学这些，连简历都过不了。

对游戏行业来说，业务测试也是很重要的，打好基础会让你的工作更加一帆风顺。

测试原则–测试证明存在缺陷

这句话很有意思，有很深的意味。可以从深层知道你做测试的动机，然后影响到你的测试质量。

正常我们测一个功能，是不是会顺着功能，验证功能都实现了而且没有什么问题。

如果一开始是带着这个目的的话，我们设计的测试用例，做的测试数据基本上都是为了验证功能正常，从而只能发现很少的BUG。

相反，如果一开始就觉得这个功能会有各种各样的问题，测试是为了找到这些问题，那我们设计的测试用例，做的测试数据就会各种刁钻，从而能够发现更多、更深层的问题。