如果是什么都没传达，可以考虑一下这么做，我这里假设你关注的指标是接口 QPS

1. 找研发和产品要系统的历史线上性能峰值，比如业务高峰期最大 QPS 等类似的概念；如果研发和产品都给不了，那就看看有没有历史线上的数据监控，也可以拿来参考
2. 拿到这个业务峰值后，你的压测预期至少要高于这个峰值，一般来说是性能是峰值的 1.5~2 倍，具体倍率就看公司的资源，你验证到数据之后就和产研对齐是否符合预期即可。

再问问，这个分享有录播吗？

曾经在互联网的安全部门做 QA 做了两年多。我对安全这个领域的肤浅理解是：

• 安全领域细分方向十分多，每个方向都可以非常讲究技术深度，某种意义上安全就是最 hack 的技术方向，从技术积累上来看，可以说是积累越多越吃香。

  但不等价于越老越吃香，原因后面再说

• 相对优秀安全从业人员都是从学校就开始积累这个方向的技能，因为安全要做深需要大量研究、实践、打比赛的积累，对各种常见套路烂熟于心，工具信手拈来，甚至工程开发能力都不输于常规软件开发。

  为什么我会有这个结论，因为我工作后尝试往安全转，但是发现工作中常规的质量保障占了绝大部分时间，剩下的一点时间不足以让我系统地拓展广度和深度，我觉得自己没优势

• 实打实地说，国内的安全，技术积累大多在头部互联网、安全公司。没有业务就没有安全，面对百亿级流量的互联网公司如果安全不做好业务损害是很大的，可以看到非常多细分方向百花齐放的平台级建设方案；头部安全公司因为市场垄断和人才聚集的原因，有更多的资源和平台去支撑安全技术积累。

• 乙方小公司的技术积累虽然有限，不过可以见识到形形色色不同安全需求的客户，相比于大厂有更多时间涉猎更广泛的领域内容。

  我的意思是，小公司可能业绩压力会小很多，也不需要花太多时间务虚，所以研究的时间也更多

• 安全方向有个特点是入门迅速，因为最粗浅的安全问题都是有规律的，不外乎是写代码时没有安全意识和规范埋下了坑，这种问题早已被前人总结烂透并有对应工具去处理和遍历。安全入门常常就是学习工具使用，然后就能挖到实际问题（我自己就只是这个水平），这样容易导致心态浮躁，只是个 script kid 就以为自己很屌，阻碍了进一步深入

  这里对应第一点，不是越老越吃香，而是能力越强越吃香，是技术行业的普遍铁律，想躺平优先考虑国企外企，乙方公司安全需要业绩，甲方小公司对安全的要求有限

以上，供楼主参考交流。总结一下我的建议：

1. 如果觉得安全是一个随时进出的领域，想混进去躺平，个人竞争力只会加速流失。如果没有足够的信心和长期自驱力，不建议把安全作为职业核心路线。

2. 普通 QA，可以多学学安全概念和安全意识，再尝试把这些转化到质保工作中，去积累业务场景下的安全知识和安全规范，而不是局限在具体安全技术和安全测试上。其实大厂里很多安全团队就是把某种安全概念以工程化的形式引入业务，所以你的思路到位才是关键。

   说得很抽象，举个实际例子，比如公司有一万台 IDC 主机，里面安全了无数的常见系统（redis、nginx、mysql、tomcat、fastjson……），假设某天某个系统被爆出有严重安全漏洞，会被黑客利用直接获得 root 权限，公司要如何快速抢救？一个思路是做资产指纹识别，在每个 IDC 上部署 agent 定期收集机器上系统资产信息（这里的资产，意思是这个主机上有什么系统，是什么版本），然后通过版本匹配迅速定位有有问题的 IDC 马上升级。

3. 具体行业的情况我确实太了解，如观点不一先当我是错的，纯属个人交流。我也算是第一次总结我对安全的理解。

请问有录播吗，蹲了几天了

如果没有，那就先从使用工具开始，因为这是迈出去的第一步。

其实性能测试含金量是整个测试计划的制定、指标设计、数据分析以及问题定位的过程，工具可以随便选，只要达到发压目标，能收集到想要的数据就行。

【用 jmeter5 个线程运行，看到那占用 99% 的 CPU 束手无策😂】比如这种，就是在没有思路的情况下直接去操作，你要想想你去性能测试是为了什么。是为了发现系统的性能瓶颈或性能转折点？还是验证系统能否达到预期的性能？带着这两个问题再去想怎么办。我给两种建议：

1. 如果目标是前者，那应该降低线程数再压，直到 cpu 不再打满，找到那个边界。然后按照这个压力去评估当前系统的表现是否合理，是因为有 bug 或劣化点导致性能问题，还是说这个系统确实就是这样的性能很合理。
2. 如果目标是后者，那原本的性能预期是多少，现在的数据究竟符不符合要求。

不要把思路局限在怎么用好 jmeter 上，也许今天是 jmeter，明天 jmeter 没落没人维护了就换成其他工具，所以花太多时间在上面没意义，把各种报告 ui 性质的东西配满做得花里胡哨也没有意义，因为你或许根本就没在做一个正确的性能测试。

在有经验的同事的指导下，自己完整参与执行一次性能测试

我觉得学框架是最简单的，因为从使用层面来说，你只要记住约定的实现方式或者代码写法就行了，甚至可以不用理解它的运行原理，死记硬背也能用。如果真的觉得连死记硬背都不行，那就找个现成写好的模板，然后把自己的代码往上面替换更改。
对应地，库的使用也不外乎如此，大多数时候我们没充足的时间和精力去理解一个库怎么工作，那就随手拿到它的文档，知道它的接口怎么调能达成什么目标就够了。

好的学习方法，无非就是不停地写、不停地可看，堆实践量，熟能生巧。代码，本质上就是手艺活。

其他代码是怎么写的，以及是怎么运行起来的，可以截图完整一些。

直观例子：

1. 发起了一个业务请求，后端处理有几秒时延，异步等待 ui 页面的相应，期间主动去做一些中间过程数据、日志的检查，发现有问题直接中断，不需要等待完整 ui 响应过程消耗时间

非直观例子：

1. 业务接口是异步接口，想要做接口测试，天然就是写异步测试代码，强掰成同步反而更低效
2. 自研测试框架，要实现同时运行多个测试用例且互相独立，做到测试用例不互相阻塞，可考虑套用异步概念，还能保持比较小的资源消耗（因为大概只需要一个单例类就能完成用例运行、断言，有排队的感觉）

这种问题百度必应谷歌一大把答案吧。

简单来说，我们把代码执行看成是一条时间线（我这样比喻是不贴切计算机底层实际运行的，但是就这个问题入门级可以这么理解），它是有先后顺序的。

按我们最开始学编程时的思维，代码就是一行一行往下执行，它的执行顺序可以通过人眼看代码完全判断出来现在跑到哪里。但是一行一行执行代码，有些工作是阻塞性的，比如执行一行读取磁盘、网络请求的代码，要到秒级的耗时。这时如果没有其他实现方式，代码就会阻塞，我们只能等待其完成，这显然是不合理的。

为什么不合理？想想你在烧水的时候，会傻傻的站在水壶前哪里也不去等着水沸腾吗？肯定不会，你会在这段时间里去做其他事，同时

• 选择一：自己脑海里记着个时间，等到水差不多沸腾你自己跑回来确认 —— 定时轮询；不是异步，是同步非阻塞
• 选择二：水沸腾会自动断电，自己随便找个足够长的时间回来处理 —— 本质上也是定时轮询，只是 “定时” 拉得很长
• 选择三：水沸腾水壶会呼呼叫提醒你赶紧过来处理 —— 异步，水壶响就是事件，你听到水壶响就是接收到事件，你跑过来处理就是异步响应；怎么处理？你爱咋处理就咋处理，你可以关电、倒水、喝水，是你自己定义的处理逻辑

为什么会出现异步？应该解释清楚了，没有异步就只能各种同步或阻塞，效率低下，CPU 大量空转。

使用场景：你调用一个接口，这个接口要处理 10s 之后才会返回，怎么应用异步？

1. 实现定义好接口返回之后你的处理逻辑
2. 调用接口，把这个异步处理逻辑绑定上去，告诉它只要你接口返回，就运行这个处理逻辑

检测工具分静态和动态，多数按具体的编程语言区分（动态的如 C++ malloc 等监控、java 的虚拟机运行时监控等，各有各的实现也对应不用专用工具），所以建议补充具体做什么语言的内存泄露检测，否则就很难回答。

【作为 QA 技术能力强，方法论强真的有用吗？一定程度上肯定是有用的，但是在管理 QAteam 后，就有发现有的同学技术能力很强，但是项目质量不怎么样】

这一块我有点个人体会。每个人都有他的特长，让每个人去发挥他的特长，可能要比要求每个人在短板上有所提高达到不错的水平，要来得更简单也更舒服。

我之前待过的团队就属于后者，比如有一个同学不善言辞沟通，对事情的整体把控力也相对弱，当时的 QA 负责人就把 ta 推出去做交接人 own 一个专项，最后结果也是比较差，弄得大家都不太开心。有时候为了锻炼人 push 一把也是可以的，说不定就超越自我了呢，不过要看不同人的素质，可能这个人的性格和行为方式就注定了 ta 的短板改正起来成本非常大，那作为管理者就得考虑怎么去用好这个人，其次才是怎么帮 ta 成长帮他克服自己的弱点。

建议帖主尝试为这种类型的同学去创造更合适他们的工作内容，说不定有新的效果。

其他的不多说，就楼主的问题，城市首选一线北上广深，因为城市大机会多同行密集，更容易遇见好的团队好的同事好的老板；其次是二线城市，同理；再往下除非公司岗位特别好，或自己有特殊需求，不然不需要考虑。

不要被 测开、测试 title 所束缚。

是什么人，要做什么，取决于岗位的工作内容而不是 title，而工作内容是在你面试进去的时候就应该聊清楚的。title 可以是一个业务测试，但是实际工作可能参与很大部分的测试平台开发，那还能叫测试么？其实也不合适。

那为什么有人会顶着测试 title 做开发工作呢？人的能力有差异，不同的事情适合不同的人，可能当时团队里就这个测试同学开发能力最强，刚好又需要做一些事情，就理所当然选中 ta。同理，测开 title 也有时候需要做测试，业务缺人就要补位顶上扛迭代压力。换一种情况，如果 leader 判断长期质量非常重要，短期业务迭代压力可以放一放缓一缓，那定位测开的同学可能就不需要加入业务测试，继续做对应的提效开发工作。

虽然很多时候 title 会限制工作内容和范围，但去到最后的能力栈还是取决于你呆在这家公司里所做过的事情总和。至于测开到底是测试还是开发，这个就看在入职的时候是怎么聊定位的，应该是先有定位，再有 title。而 title 是死的，定位活的，定位可能会变，但是 title 大概率不变。是工作内容塑造一个人，而不是 title 塑造一个人。

故，狭义地说测开是测试还是开发，要不要干测试，能不能干测试，我觉得是看情况去讨论，下不了结论。

其实也还好，vim 进去不按 i 或者 a 或者什么编辑键，即使编辑了不保存一样不造成影响。
甲方其实可以选择教育你，没必要批评你，说白了可能就是甲方看你不顺眼而已 。

为什么这种问题还会一直有人问 ，选哪个自己有信心能赚更多就选择哪个得了。不需要这么多顾虑，敢想敢做才是关键

不太正常，它不像是前端展示的问题，重复关注算成了两个人关注我，所以应该是数据库已经有问题了

怀疑是脏数据，可能某些重试逻辑没做好前置检查就出现重复入库？

同意 11 楼的看法，就像我们做质量保障工作分优先级一样，测试用例也应该分优先级再定投入。

边缘的系统不需要花太多时间做太多保障，因为它本身即使出问题也不会带来足够大的影响；对等的，测试用例如果是面向不怎么重要的地方，其实也可以分开来追求效率或者质量。

没必要以一个过高的标准统一要求所有测试用例，因为时间是非常有限，尤其是互联网两周发版是常态，不太允许全部用例都是高质量的要求。

个人感觉，测试用例的灵魂不在于字字斟酌明确，而是在于用例本身的结构（脑图结构）能否体现出一个有逻辑可理解的测试思路，让读者跟上这个思路并且能独立判断思路遍历是否完整可靠。至于繁文缛节方面的事情，一定程度上可以忽略。

好书 +1，书上有个微信号还可以加作者的微信入群，和一帮大佬吹水

我最近也做了类似 B 的事情，出于让外包同学多方面成长的初衷，我让外包同学尝试去做一做自动化，还做了好一些专门的辅导工作，最后结果是……

1. 为什么自动化要我做，而不是别人做？为什么别人能更早下班，我就要呆在这搞自动化？
2. 本周自动化进度还是 0，原因是业务测试任务太重了搞不过来……
3. 同一个问题，说了三四遍还是搞不懂，只会死记硬背，不会理解问题……
4. 稍稍变式不一样的问题就没能力独立解决，即使他手头有着联通世界的互联网搜索工具……
5. 个人工作和生活分得比较开，下班之后就不再想碰工作了，所以上班的时候尽量多学一些（然后下班很早【摊手】，又不愿意比别人付出额外多的时间）

只能说，成长真的是个人的问题，作为外人不要想着自己能去改变什么，也没义务去帮任何人成长。尤其是每个人的 “个人强度” 还不一样，有些人很脆弱无法逼迫自己往前多走一步，但有些人却能越战越勇。并不是让大家去学，给大家空间学，大家就真的能成长起来，这一套理论在人的惰性前是完全无法经受考验的。
当然，除非你是他们的管理者，对他们的成长有一定责任，否则还是不要浪费时间（+ 浪费感情）了……

PDF Github 链接，有贴在文章开端部分。

请问有无线上直播和录播渠道？

有几个疑点：

1. 正如 10 楼所说，提效部分是否当前效率最大痛点，还是说为了让工作中体现提效而找个简单轻松的地方去落地
2. 提效工作做得够不够好，还是说勉强 60 分的形象工作，大家对提效工作根本没信心还是要人肉兜底
3. 提效有了但是人的理念有没有转变过来，还是说依然选择人肉兜底保心安

实际中比较多的是第 2 和第 3 种情况