![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
我现在真的是对游戏测试又爱又恨,爱的是我正在做这个,这是对游戏行业很重要的一个岗位;恨的是水平良莠不齐,很多人工作多年连用例都不会写,难怪一直被说游戏测试门槛低。
记得刚开始工作的时候,网上游戏测试相关的文章很少,大家也都不懂,什么都是一板一眼学软件测试的,比如测试前都会认真的分析策划文档,找测试点,画状态图,画流程图;然后认认真真在excel表上写用例,操作步骤一步步写下来。
现在你在让大家这样写用例,大家会像见到外星人一样看你。
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
我们先看看大家写用例经常出现的问题:
1、格式问题
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
- 极简主义(标题和正文没有任何区分,正常用例要素不全)
- 花里胡哨(搞了太多颜色,相当刺眼)
2、用例基础
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
- 用例要素缺失,BUG单号、用例描述测试目的、这两项是大家经常会缺失的部分,实际这两部分内容对用例来说也很重要,BUG单号是缺陷平台里BUG单的ID,方便测试人员关注该BUG的处理进度。用例描述测试目的,是简要说明该条用例想要测试的点。
- 多个测试点混在一条用例里这个是用例里面最常见的问题了,很多时候为了偷懒,就一条用例测N多内容,甚至一整个界面,就是一条测试用例。(记住测试用例的原则:一条用例只测试一个功能点)
- 测试步骤条理不清很多时候大家写用例都只是给自己看,写的测试步骤跟月底的钱包一样,要多干净有多干净。详细的测试步骤除了方便其他人看之外,也能最大还原当时的测试情况,方便你去重现问题。错误(×)
正确(✔)
- 测试内容过于冗余有些同学写等级相关用例的时候,真的是每一级都写,我真的是谢谢你了。
- 测试数据不是具体数据,喜欢用符号或者其他量词代替。
3、逻辑不清
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
大家写用例的时候,思路比较混乱,基本上都是按照策划文档从头到尾的顺序来写用例,写的过程中会发现前面好像已经写过这里了,怎么又要写。同类型的模块又没有整理到一起,前面一部分,后面一部分,很不方便后期阅读。
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
像我这边一般会按照流程图的方式来写用例,从头到尾,简单又清晰。
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
5、补充学习
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
游戏测试同学很少有在校接触过理论学习,自己也不大喜欢看理论资料,要学习估计也是去学自动化测试、性能测试、大数据测试、AI智能测试。没办法,不学这些,连简历都过不了。
对游戏行业来说,业务测试也是很重要的,打好基础会让你的工作更加一帆风顺。
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
测试原则–测试证明存在缺陷
这句话很有意思,有很深的意味。可以从深层知道你做测试的动机,然后影响到你的测试质量。
正常我们测一个功能,是不是会顺着功能,验证功能都实现了而且没有什么问题。
如果一开始是带着这个目的的话,我们设计的测试用例,做的测试数据基本上都是为了验证功能正常,从而只能发现很少的BUG。
相反,如果一开始就觉得这个功能会有各种各样的问题,测试是为了找到这些问题,那我们设计的测试用例,做的测试数据就会各种刁钻,从而能够发现更多、更深层的问题。
声明:文中观点不代表本站立场。本文传送门:https://eyangzhen.com/235250.html