接入自动审批也是要💰的，其实人工审核一下还好，刚好切合一天上午下午晚上几个时间点定时过来看看

我可能是开发同学口中的傻逼用户

听起来是这个构建系统不是很完善，目前只是一个裸 jenkins 在做构建工作，其实很多上下游的事情可以稍微画点时间就能舒服很多，如：

1. 【可我们 Jenkins 里有一堆项目，如果版本更新了，开发要不忙就告诉我们构建哪些】，哪个版本要更新，理应是可以通过代码合入去感知的，这其实就是配置一个 merge request 的 webhook 就差不多了。如果有更严格的条件，那应该和开发一起制定规范，比如你有个 TAG 的严格自增，那稍微搞个数据库存一下最新序号做个匹配就只能哪里应该构建
2. 【我咔咔构建一堆之后，还有构建失败的，于是就得联系开发再查，他们修改完告诉我，我再试着构建，就挺麻烦】。有两个解决办法，一个办法是构建失败自动通知，不同项目配置好通知不好开发；一个办法是统计构建失败频率，选出 Top 失败的项目，推开发去做规范写文档，让大家可以自行解决常规的构建失败问题，让开发自己去关注构建成功率

其实谁去维护都一样，按照你的上下文本身没有很复杂，就是大家都懒得去做改进而已

第一次了解到比较真实的国外 IT 从业生活~

①接口测试是否需要针对必填参数验证？感觉必填参数校验，有一个脚本就够了
需要，而且很必要，P0 用例。具体在测试执行上，如果接口的必填参数很多逐个验证很麻烦，可以按场景去写需要的脚本，爱怎么搞就怎么搞，能测好不就达成目标了么

②接口测试数据，是否要枚举，比如：长度、特殊字符、中文
异常场景用例设计主要看测试时间，如果时间非常充裕，可以测得细一点，比如你说的各种异常情况枚举。如果时间相对紧迫，没条件这样去搞，那就要例行筛选优先级，适当砍用例。当然，更好的做法是直接看研发的代码，比如代码里都写清楚了，每个接口调用前都会有参数校验逻辑，校验逻辑已经统一把这些异常情况做过处理，那就可以大大简化这些用例，只要你在一个接口字段上验证过，就没必要再到处重复了。

这真的好吗，很多时候一旦定了指标，就会引导大家往指标体系意想不到的方向发展。

或者从另一个角度说，只负责搞日常业务测试的同学倒是可以比较好的融入，很多不同角色的同学在这个体系里估计很惨。

测试本质就是保质量，质量出问题一样背锅，所以其实写不写项目测试都差不多，这是本职工作，如果用 OKR 的话一个 O ，KR 里列出几个需要重点投入的项目足矣。
其他的无非就是围绕着质量领域的效率提升和成本降低。一般首先被关注到的，无非是流程优化、各个端的功能自动化、性能/安全等专项测试工具能力、监控建设、反馈跟进……说白了就是造框架、工具、平台、方案。
只要不是本身就对测试部门有怨气，其实是不会理解歪的。这个场景我觉得应该是测试部门之前做得不好，让楼主觉得这个目标是不务正业吧 。

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

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

  • 客户端：数值系统（任务属性、装备属性、技能属性）、视觉交互（技能效果、交互效果）、对战系统（匹配机制、房间机制、副本机制、地图系统）、世界系统（频道机制）、通信协议（协议细节、消息广播），以及围绕着装备、技能、属性等各种强化机制玩法。本质上一方面是游戏业务逻辑的功能测试，一方面可能会把 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. 学习到的东西是否有真正的工作价值，如以工作中某些话题去开展学习，最后应用到工作上