最关键的 bug 产出没有写啊哈哈 ，产出了多少 P0 P1 BUG，对比手工测试 节约了多少人力

非也， 是团队正常扩招，上面又给 HC 了。

大佬请教下你们接口用例一般怎么写呢，是单个接口 + 不同参数组合吗， 还是一条用例对应一个完整的功能流程（比如打开某个页面下单）

那个是我们兄弟公司米哈游
不过我们年终也是可以的 业绩平均水平应该是有的哈哈

1.游戏服务器由开发提供，接口测试平台我们自己 Docker 部署
2.用例是手写啊，根据功能用例和分析协议 自己写接口用例 ，异常参数的话可以膨胀生成
3.除了这些之外 ，剩下的都是平台功能，比如批量执行用例，生成报告，数据持久化等等
4.用例里需要写断言条件 ，主要是判断回包的协议和参数
5.每次新版本做回归测试的时候跑 ，
6.新功能的话来不及写就下次补上，一般都是跑全量。

1 个人能做成这样已经蛮不错了 。。
如果你们公司只有游戏业务，那可以考虑下这些：

• 接口测试平台 主要用于每个版本的接口测试回归。 你做的 Untiy 插件更适合一些新功能的测试，但是不太适合大规模的回归测试。 我们接口测试全量用例一个游戏得有 1W 多条
• 项目组如果是主干开发，可以考虑帮忙搭建一套 CI 流程 ，每次提交会触发该流程，从策划表检查、美术资源检查 到客户端拉起检查、服务器起服检查 等等
• 游戏配套的辅助工具，比如帮忙批量造号 模拟批量玩家战斗 移动 、抽卡概率检查工具 等等 ，具体得跟项目组 QA 同学沟通
• 压测工具， 主要针对服务器端的压力测试

然后已有的工具可以不断调优 加入新功能，比如策划表检查 可以支持更多规则； Airtest 可以给对自动化有兴趣的 QA 同学培训，赋能给向项目组 QA 一些简单的脚本开发能力 等等等

好文 ，，，坐等后续两篇

主要看你想干啥 ，要是想做游戏 可以考虑转游戏策划；如果想写代码可以转测试开发或者开发；如果只是想测试，那游戏测试也能一直干下去。。 后期可以考虑转测试经理主管这种管理岗

学习了。 刚好前阵子写了一个差不多的 每小时定时检查版署包服务器情况。。。