问题 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 应该是首选工具。

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

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

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