我没做过真正意义的游戏测试，只是说说自己的看法。

• 功能测试，我尝试分解一个游戏构成要素：

  • 客户端：数值系统（任务属性、装备属性、技能属性）、视觉交互（技能效果、交互效果）、对战系统（匹配机制、房间机制、副本机制、地图系统）、世界系统（频道机制）、通信协议（协议细节、消息广播），以及围绕着装备、技能、属性等各种强化机制玩法。本质上一方面是游戏业务逻辑的功能测试，一方面可能会把 Unity 做一层或轻或薄的封装，可能也需要对封装的引擎接口做一些测试（UI 级的、函数接口级的）
  • 服务端：这就是普通的服务端接口测试，没什么特别的，前面提及的各种数值计算、数据下发、匹配等都属于服务端逻辑

• 性能测试：

  • 客户端：有现成的性能测试工具，如腾讯 perfdog 是大家都在用的。就关注 cpu、内存、帧率/流畅度，结合业务需求去设计测试场景即可
  • 服务端：常规压测

• 稳定性测试：更多是客户端概念，最简单的实践就是上个 monkey 随即遍历点击，进阶的就是将随机点击化为有效点击只点能交互的要素 + 遍历策略算法

• 兼容测试：游戏客户端，不同的机型系统版本

• 其他专项测试：安全测试一般是游戏必不可少的，服务端和客户端都的越权、加密、注入等；当然还可以有其他的专项测试，比如资金、数据流量……

看团队，卷不卷很大部分由 leader 和同事决定。

大多数时候公司对产出的压迫没那么恐怖，大家都是正常人也并不想卷的，排期合理评估好按计划走。但是，可能你的 leader 10 点还不下班，可能你的同事晚上 12 点还在群里发消息 @ 你。
其实大家本心不坏，有时候确实周期到了要加快产出，然而当卷王集体出现你还不卷就显得十分 “突出”。

总体来说，测试肯定没有研发卷。

你这个说法挺可怕【现在测试组每天都是正常打卡上下班，几个月没加班了】，意味着潜意识里把加班当成常态，不加班就是闲，细思极恐😂。

不过既然闲下来，是不是可以搞一些更高价值的事情来丰满大家的工作。

一般这种送命问题：

1. 说有优化空间，那直接砍
2. 说刚刚人够用，领导观察一段时间，找你说还是砍一点，辛苦大家压力大一点，分担一下吧
3. 说人不够还要加人，领导说别加了，就这么多吧

1. 是否有推行代码扫描：看团队，有些团队有有些团队没，但总体来说更多团队愿意尝试
2. 开发配合：这个是强要求开发配合的项目，在推广之前就需要和开发从上至下对齐这个事情的重要性和解决问题的方式；除非测试自己有权力和能力去直接改开发的代码，不然扫出问题就是要开发修改，开发如果一开始就不打算配合那测试单方面做是自嗨
3. 测试单方面配置有无必要：同上，我觉得测试单方面是无法开展的
4. 效果：代码扫描分两种，一种是单纯的编码风格扫描，这个一般开发内部自己推广；另一种是我们更关注的代码缺陷扫描，它本身就是一种前置发现潜在问题的手段。从这边的数据简单去看，尤其是一些线上空指针问题，这种工具在发现能力上是相对可以的，但其实也没有说很多线上问题它都能发现，很多时候它是一个治理隐患的手段，发现效果也因工程的复杂度而异，越是复杂的工程越容易有隐患，用这种工具理论上可以更有帮助

在具体开展上，我觉得可以这样去尝试：

1. 先拿到线上问题数据，拿有问题的代码去扫，看能不能通过扫描发现问题 —— 这一步是回答整个代码扫描的实际价值，如果这里发现代码扫描根本没有抓到多少历史线上问题，那就没必要做了
2. 和开发商量好启用什么扫描规则，不同扫描规则扫出来的问题是否提成 bug 去跟进，对应的优先级又是什么
3. 每个版本，甚至开发每一次的代码合入（Merge Request），开始卡口，先卡增量问题，保证每个版本没有新增问题，再慢慢消费存量问题

基本上大家的套路就是这样

持续输出，确实考验意志力，还会倒逼自己去加深学习

工作半年多就开始焦虑这个问题，我那会还不知道在哪里玩泥沙呢 😂。

我的建议是：

1. 多留意身边，多关注上下游，认清自己的工作是为业务质量负责，还是从业务角度而不是技术角度去思考问题
2. 测试开发和业务开发是两种截然不同的选择，两者无法直接对比好坏，也不存在因为编程语言不一样而无法转开发的说法，本质上看的是编程熟练度，其次是解决问题的技术复杂度（我个人感觉熟练度是转型第一位，其实业务开发也不见得技术一定有多好）
3. 可以多看看测试开发大会，了解一下同行做什么比较高精尖的事情，这样也方便对测试开发这个岗位做的一些相对有难度的东西建立一些认知

手动点赞

问题 1：像这种入参非常多的接口，测试用例一般怎么设计，覆盖到什么程度比较合适？

我的经验是有几个思路

1. 从代码覆盖率上去看，你的用例是否达到一定水平的覆盖率，比如 80% 以上；是否覆盖了关键业务路径，如果对代码熟悉可自行判断，不行的话可以拉开发一起过一下
2. 和开发一起评估对齐出哪些优先覆盖，哪些可以不覆盖那么全，其实就是用例评审的时候强调好测试的取舍
3. 其实这类参数校验，开发的代码一般就是一个 validator 定义好校验逻辑，或者开发框架上有提供对应的校验功能，基本是可复用的，直接白盒看代码去确定自己有没有必要搞这么多用例。如果参数校验很完整，其实可以适当删减无效用例

问题 2：工具生成用例

很多公司都有实践，如果要自己做也不难，大体思路是定义好不同参数类型的取值集合，如 int 就对应整型最大最小值、0、正负数、不同形式的整数写法等，预定义好一些取值，这些预定义的取值去替换测试用的 json 数据。再实现一个 json 解析替换的功能就可以是一个简单版工具了。最后的目标就是通过输入一个 json 范例，或一个 json scheme，自动生成不同的 json 数据供测试输入。开源工具不了解，我自己没有找过

可能大家最近确实忙，我自己本身这几个月也经历了一波团队变动。

分享的想法没变，不过时间少了，一些想法需要时间丰满一下才会分享出来，那时间变少了只能拉长单次分享的时间间隔了。

说到招聘，这一块很有感触，一方面是外头的公司资深和 leader 岗位一直招不到合适的人，一方面市场上又很多领了大礼包的人。有个迷幻的感觉是，裁员是公司的决定，招人是团队的决定，这两个是有些相互矛盾的。我在的团队也在招人，招聘帖子见：https://testerhome.com/topics/34978

上面是官方的招聘信息，细节想了解可以评论（勾上，仅楼主可见），或者直接加我微信 zingphoy 私聊细节 ~

目前还有 HC，主要缺口是有七八年经验的同学，当然小几年经验的同学同样欢迎。

我的建议：面向问题去寻找解决方案，如果资源不允许，优先找现成可用能短时间看到效果的方案，你就会发现在应用的过程中，越是万金油的方案，就越是不好用，逐渐就会有你的想法，在里面加入越来越多的公司和项目特色了。

我其实想表达的点是：不要什么都想着自己亲自造轮子，解决一堆技术难题什么的，因为拿不到收益看不到结果，事情往往都活不下去……敲黑板的重点是，做什么事情都要面向问题，哪个选择明显效率更高成本更低，就是小学加减法了。

一般是给固定涨幅，现在大环境不好，供大于求，肯定会压涨幅，我自己没试过，猜测是 10-30%。
没有说值多少绝对数的薪酬，寥寥数语也不清楚楼主是什么定位和具体什么深度广度。如果本来就很低，大概率跳完之后也不会很高；如果本来就很高，再跳就是更高（废话文学）。

测试环境被攻击有更多信息么？

测试环境是否对外？
测试环境攻击的是什么，危害大不大？
测试环境被攻击那线上会不会有机会受到同样攻击？

你问要不要增加安全测试，当然回答是要增加，这不是肯定的么？前提是你有没有人再说

理由要说就真的太多，postman 只是一个执行工具，它没办法低成本铺开大家添砖加瓦，没办法结合到公司的研发流程，也没办法度量相关数据，更没办法向上汇报质量。

当然不能说它不好，如果目标是追求快速完成接口自动化，把这个事情执行好，postman 应该是首选工具。

建议很简单：尽量往技术侧靠拢（做测试也尽量找技术性的岗位）。
为什么：主要是因为技术方向的工资能更高天花板也更高，有技术能解决更多问题，有技术影响力也更大。

或许也可以想想，培训是不是真的有意义，是不是真的帮到大家或者解决大家的问题？

能力提升确实是个人的事情，但是如果想团队持续发展，大家更优归属感更忠诚，管理者如果能帮大家更快地提升个人能力，也是管理者的能力体现。

多数情况都是学习氛围的问题，而要解决这个问题，可能需要关注一下这些因素：

1. 是不是所有人都没有学习的意愿，还是缺少一个带头学习的人把大家带起来【我觉得这个是最重要，团队里没一个特别热爱的人，做什么都是假的】
2. 有没有机制来保障大家的学习有效有输出有沉淀，如定期分享会，学习课题池，对应的奖励机制
3. 基础条件是否提供到位，如有没有团队经费为购买书籍服务
4. 学习到的东西是否有真正的工作价值，如以工作中某些话题去开展学习，最后应用到工作上

新的芯片多多少少会有坑，但普通使用估计也没多少机会能遇上，原则上买新不买旧

瞎回答一下：会不会是 jmeter 这个显示就只代表本机的数据，我记得好像是在压测结束后，slave 才会把数据统一返回和 master 去做分析。试想一下，作为 master 自己既要压测干活，还要在压测的时候接受 slave 的数据信息去处理，其实是干不过来的。

Keep 不是一个专业的运动工具 app，而是做成了运动社区，这些数据我认为仅供娱乐（For 社交），认真就输
不过这里说的是数据覆盖的问题，也确实恼人

综合看起来简历是属于业务骨干，不适合 leader，也许有机会做储备 leader。

从互联网大厂的要求来看，这个年纪的要求是做一个子方向的 owner，带几个同学一起去负责把这个方向做起来（也会要极少数的岗位是技术专家的角色，攻坚问题管事不管人），看的是胜任力。对比楼主的简历，一定要说不合适的话，要不就是业务领域不匹配，要不就是做的深度不足够（有时候所谓深度，前提是先有业务体量才会出现深度）。

不需要妄自菲薄，至少在核心技能上应该没问题，建议后续多花些时间做系统的思考，留意落地上遇到的问题，除了传统的各类自动化外，看看其他地方的质效建设，如灰度线上、研发期间等，把体系知识呈现出来，同时了解一些管理方法论，就能继续平稳进步。

我注意到的点可能比较奇怪，为什么这个小伙伴可以摆烂 3 个月，才和他一对一沟通了解问题。
从老板角度去想，是不是意味着少着一个人也没有什么影响，然后就顺理成章地优化掉（无恶意），可能楼主也要想想在日常沟通上是不是要定期开展来及时了解小伙伴们的想法。

一开始选择 apscheduler 就是想轻量快速，搞着搞着我们发现不适合有坑，就只能回去大家都用的 celery 上，目前还没出现问题