游戏测试萌新学习

备注：未经博主允许禁止转载

个人笔记（整理不易，有帮助，收藏+点赞+评论，爱你们！！！你的支持是我写作的动力）

笔记目录：学习笔记目录_pytest和unittest、airtest_weixin_42717928的博客-CSDN博客

个人随笔：工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

参考：游戏开发团队及流程简介_游戏测试入门-慕课网

目录

一：游戏团队

二：游戏项目流程

三：游戏测试主要内容

（1）功能测试

（2）客户端性能测试

（3）服务端压力测试

（4）兼容测试

（5）安全测试

（6）接口测试

（7）日志测试

（8）网络测试

（9）GM测试

（10）SDK测试

四：测试用例

五：其他测试

---

在YY做app软件测试（语音直播社交类型的app），突然有一天，看到游戏测试的岗位，我就在想，游戏测试是做什么的呢，虽然我是一个很喜欢游戏的人，但是我不了解

于是疫情那年，有一天晚上，我就百度了一下游戏测试是什么玩意，碰巧看到了这个视频，于是我就看了一下

游戏开发团队及流程简介_游戏测试入门-慕课网

ps：注意看完一节后面还有很多节

于是我的游戏测试之旅开始了。。。。。。

下面是我工作几年后，对这个行业的一些认知，这里简单总结一下，希望对萌新有所帮助

一：游戏团队

一个游戏团队，大致有这些岗位

制作人	服务端	客户端
策划	测试	美术
运营	后台	pm

二：游戏项目流程

1：执行策划出需求文档

2：UE把控文档的交互体验

3：策划就UE反馈，修改文档

4：主策划审核文档，没通过就打回，让执行策划改到通过为止

5：PM和策划组织三方会议，有改动策划需要调整文档

比如系统逻辑有问题，或者某个逻辑难实现，或者有更好的建议，都会导致文档有所改动

然后讨论开发周期，测试周期，提测节点，上线节点等，达成共识

6：美术开工，产出资源；程序开工，开发功能；测试开工，设计用例

7：程序提测，UI/UE/QC验收，UI重视觉表现，UE重体验流程，QC重功能

8：程序修BUG，QC验BUG，问题多的时候要整体回归

9：封包，维护更新

10：收集玩家反馈、线上数据复盘，持续迭代

备注：其中，7-9的过程非常多，这里简单的列了下

详情可见个人随笔-测试流程

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

三：游戏测试主要内容

（1）功能测试

功能测试其实就是黑盒测试了，方法论其实跟软件测试差不多

作为一个游戏测试人员，我们要多玩自己的产品，这样才能在心中建立一个大致的玩法框架，设计测试用例才能游刃有余（所以为什么招测试要问你玩了什么游戏）

在测试前期，对不合理的需求要与策划battle，因为版本迭代快，减少无谓的返工，才能减少延期的风险

相比软件测试，游戏测试更看中体验，测试人员在测试的时候，会产生很多易用性，可玩性建议，这时候要保持和策划的沟通，将这些建议按照排期一个个落实，所以测试也是半个策划

有时候我认为测试也是半个GS，你深入玩家群体，这样才能了解更多玩家的想法，同时玩家出现刷道具，BUG等各种骚操作，你也能快速去应对

当然，你想测好一个游戏，你肯定得对标竞品，所以了解竞品，也是你要去做的事情

 详情可见个人随笔-测试用例设计的方法

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

（2）客户端性能测试

详情可以去看工作随笔-性能测试

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

（3）服务端压力测试

详情可以去看工作随笔-性能测试

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

（4）兼容测试

兼容测试，除了常规的测试项外（比如分辨率），我们也要关注其他测试点，比如

1：版本兼容

在服务器会存在两种新旧版本的问题（比如不强制升级），一些玩家没更新，这要测试新旧版本的交互）

2：老功能添加新类型可能会导致兼容问题

比如最开始做头像功能，没考虑到拓展，只做了男女默认头像，后面做了头像功能后，一些旧玩家可能会出现无法更换头像的情况，导致出现该问题的原因可能是数据不兼容，这时候程序要对旧数据做兼容处理

详情可以去看工作随笔-兼容测试

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

（5）安全测试

安全测试，我理解是外挂测试，我只粗略测试过，就是用GG修改器，去修改内存，看下是否存在漏洞

（6）接口测试

接口测试，在游戏测试中又叫协议测试，是比较重要的测试项

针对协议，进行重发，篡改等一系列操作，检查服务端是否存在逻辑问题，避免刷道具等行为

详情可以去看工作随笔-接口测试

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

（7）日志测试

大概意思可能是打点日志，打点日志就是，比如你登录成功，会记录下你的行为，方便运营去分析在哪一步，用户容易流失，针对流失比较多的地方去进行优化

我们平时测试的时候，客户端，服务端报错也会有日志，不过这块一般不用我们去测试

（8）网络测试

 详情可以去看工作随笔-弱网测试

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

（9）GM测试

我们在测试的时候，经常要依赖一些GM进行构造环境，程序把GM写好后，我们肯定要验收一下GM的正确性，要不你拿着有问题的GM去构造环境，这样测试没有意义

（10）SDK测试

游戏要接入各种SDK，那我们就要正常去跑测是否能安装，登录，拉起充值等一系列的功能测试

四：测试用例

用例的设计是测试基础技能，方法论其实跟软件测试是差不多的，举个例子：边界值分析法

设计测试用例，如果时间比较充裕，你可以先写思维导图，发散思维，然后再写详细的测试用例

对用例的编写，有个说法：好的测试用例是没有看过需求的人，看了你的用例都能正确的测试

在一些规范化的公司，可能还要写程序自测用例，然后通过邮件形式去通知程序

对文档这块，要注意下面2点

1：在阅读文档过程，要自己带着是否有更优的方案的态度去看需求点，不要觉得策划的想法就一定是最好的，可以和策划讨论，遇到含糊的需求点，一定要找策划确认

2：需求变更这个点，一定要群里同步，以前就遇到在测试的时候，发现我更新的用例和开发的功能不一致，原因是策划没有同步给开发，开发不知道需求更新了

沟通-同步，沟通-同步，沟通-同步，是这个过程一直要保持的事情

一个复杂的系统，要怎么去设计用例？

举个java的例子：

如果类中的方法是一组相关的行为,则称该类是高内聚的,反之称为低内聚的。（我的理解是把该类的行为都统一写在里面，而不是这个类写一个，那个类写一个）

低耦合就是尽量不要让一个类含有太多的其他类的实例的引用,以避免修改系统的其中一部分会影响到其他部分,（比如子类父类就是强耦合关系，修改父类必然导致子类变化）

写用例比较忌讳需求点改了一点，你就要对整个用例修修修改改，这是有问题的，一定要拆分清楚，一个测试用例针对一个测试点，一个点可能关联很多模块，不要纠结它属于谁，导致浪费时间

 详情可见个人随笔-如何设计测试用例

工作总结随笔_8、以前工作中都接触过哪些类型的测试文档-CSDN博客

五：其他测试

（1）冒烟测试

主要作用是快速的确保主流程跑通

现在我对冒烟的理解有三个方面

一个是提测前的冒烟，本来这个环节应该是策划做的，但是实际情况策划可能没空介入，或者开发周期比实际要久，可能会导致提测延后，但是封包节点又不变的情况，作为测试就要提前介入，先跑通主流程，这样开发提测，测试就能舒服很多，避免那些阻塞流程的问题，影响你测试

另一层是我们要维护前，比如生产环境提交到正式环境，我们会在内网线上分支跑一轮冒烟，确保新功能没问题，也确保旧功能正常，然后才能打补丁。在维护阶段，关闭入口后，测试人员就要在内网更新补丁去再跑一轮（注意这里是正式环境了），没问题才能开服

最后一层是，我们平时要打包什么的，或者游戏接入SDK，这时候游戏就要冒烟，确保充值、功能等内容没问题

（2）回归测试

我们测试一个功能，出现大量的BUG，修复后，要整体过一轮，确保修复后没有引发新问题， 在实际中，出现新问题的概率非常大