对，你提及的就是图像识别自动化比较大的局限，我自己也没用过，个人感觉图像识别这种技术只能做一些比较简单的自动化，复杂的页面 + 复杂的路径的自动化还是通过控件定位好一些，它更加像一个工具箱里的工具，而不是一个完整方案。可以考虑用作一些特殊场景的补充吧，想用它解决问题那确实不实际。

嗯对，我有特别强调的是大多数小项目小公司，确实有顶级体量的，小程序会是 top 流量入口，这时去做这个肯定很有必要的。真不行或许可以考虑一下类似 airTest 那种图像识别

minium 框架，我猜测做出来很大程度是 for 绩效的😓。

试想一下，小程序千千万万，大多数小程序开发团队是工作室形式，几个人做出来，有多少开发者真的会为了一个短生命周期的小程序，选择投入专门人力去写一套完整的自动化代码。可能线下手工快速过回归测试性价比更高（这么说是因为小程序形态的业务相对简单一些）。

请问审核帖子有统一的准则吗？

公理：不要想趟着就能让事情变好，一切正向或熵减的变化都需要引入人的额外努力，总会有些人需要多做一些事情来维持。

如何避免开发改 bug 引起其他问题 + 修改 bug 如何避免引起其他问题

1. 流程和规范上的管控：开发变更，测试和其他开发在平台上做 review，开发的变更有规范的文档说明讲解，有基本的自动化工具做最初级的检测（如 lint、安全漏洞、内存泄露等，市面很多免费的）。其实只要认真完成这些步骤，有平台来做一些规范上的强制实施，就能排除掉很多低级的问题，譬如那种变量手误写错、判断手误写错、调用漏了重试等。当然这里也依赖于各方参与者投入的精力，本质上也不够可靠。
2. 自动化的介入：这个不用说，自动化最基本的功效就是回归兜底，先不说改哪里测哪里，至少得保证不会因为变更使得系统核心功能受损吧？

站在共同的角度：如何避免这种情况引起线上问题

1. 合理的灰度发布流程：需求上线 2 分钟给你干到全量，出问题只是迟早的事情。正确的操作是平台强制灰度发布流程，规范上要求开发（按需引入测试）人工观察灰度发布是否引发大量监控报警或指标异常，出问题及时回滚避免进一步劣化成严重线上问题，也就说守门员的工作得做好，这是最后一道抢救手段。
2. 合理的线上监控和反馈渠道：连线上监控都没有的，那就真的对线上质量一无所知，线上监控作为主动召回问题，无论是需求还是 bugfix 还是配置变更，都有着极度重要的作用；除了线上主动监控外还需要有客户可以操作容易触达的反馈渠道。

线上问题：开发改 bug 引起非本迭代的问题，导致线上问题，谁的责任最大

问这个问题我理解可能在帖主团队里，研发和测试没能站在一条线上，有点站对立面的意思。对事不对人，谁的责任大不是因为谁写了这个 bug 或者谁没测到这个 bug 这么单调的评价方式，如果想避免大家在这种问题上产生无效的争论，就应该由测试牵头制定一个迭代合码发布的规范，上面一条一条明确好什么角色要在什么时间做好什么事情，在研发测试层面达成共识。那事后就可以对着这个清单检查是谁没按要求做好某个事情，这个事情没做好对线上问题的贡献有多大，最终来确定责任已经明确改进手段。

以上都是临时想到的，肯定不太全，仅供参考。

没想到这个帖子会把这么多人炸出来……很客观地评价，为何技术帖子和其他质量保障帖子回帖人少，这种帖子回帖人这么多。你或许已经感受到一部分测试从业者的心态了吧 ，以及和测试行业相关的其他上下游岗位对测试岗位的一些看法。

如果是什么都没传达，可以考虑一下这么做，我这里假设你关注的指标是接口 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 或者什么编辑键，即使编辑了不保存一样不造成影响。
甲方其实可以选择教育你，没必要批评你，说白了可能就是甲方看你不顺眼而已 。

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

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

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