生产压测一般选择在流量低峰时间段去搞（比如凌晨大半夜），再考虑上数据、消息、日志等隔离避免污染线上，只要限制做到位，其实不会有明显影响。

从工程化角度来说，就应该区分原子操作和组合操作。

在这个业务场景，查询信息和查询站点我理解就是一个原子业务操作，无法再继续下拆，所以它们肯定要分开写。两者代码一定要分开，无论是定义为两个不同方法、或者两个不同类，甚至是两个不同代码文件（具体看整个自动化项目别人怎么写，就顺着大家的风格去搞）。

最后在测试用例层面去组合两个原子操作，分别进行校验。这样一来，原子粒度的操作区分开了很容易找到并维护，业务功能层面的一个用例通过组装可读更高（可能十行以内代码量，一行代码调用封装好的查询信息，一行代码调用封装好的查询站点，然后分别校验）；而不是在一个用例里堆砌一堆 “请求业务接口，拿到返回数据，拆分数据校验” 这类和抽象的测试用例不直接相关的底层代码。

看起来没什么实质信息量，打广告也请把内容写完整再发。

信息量不太多，我尝试宏观给点建议：

1. 同步比异步执行效率低的前提是你可以有多个操作可以并行完成，如果平台中 piece 层的操作互相独立不耦合，那肯定是异步更快。更具体的说，用例之间是可以并行跑提高效率的，而一个用例中的三个 piece 看起来似乎只能顺序执行。
2. 没什么信息量，502 加载不出来可能是图片存储服务扛不住那么多 QPS 挂了，如果是这个原因而且你无法优化存储服务，你就只能考虑把图片进一步压缩，或者把多张图片打成一个压缩包去存储与读取以减少磁盘小文件 IO；又或者降低你请求的 QPS 如引入请求队列来控制请求峰值。
3. 这种弹窗什么典型的解决办法就是图像识别 + 控件识别点掉。图像识别是为了识别到弹窗，但想要去除弹窗就只能去点击（除非让开发留后门或配置去关弹窗）。单一技术栈的解决办法是等待一段时间，然后控件识别是否有弹窗，有就点掉。
4. 爱怎么做都行，但 chatgpt 真的免了，这玩意儿就一本正经的胡说八道，你引入这个工具要考虑到它引入错误的风险，如果能接受那可以试试。

对于连编程语法基础都没有掌握的新人，我的建议一律是找本 python 书完整看完它。

什么书都行，你就在豆瓣读书上搜索 python，哪本看着书名像入门书，哪本评分最高，你就只管买回来死磕，不要只看书要自己写，即使你对着书抄也行，看完之后就出山了。

之所以这么说，是因为我大概就这样做

补充一下答案
字节移动端 ui 自动化一直有专门的中台质量团队开发（这些人理解为测开或者纯开发都行，和业务线没半毛钱关系）。早期移动端 ui 自动化就是使用 UIautomator 的封装，具体来说在 20 年及以前基本都还是在用它，大概 20 年中后期开始大范围推广自研 ui 自动化框架（本质上是腾讯 QT4A 的二次开发，核心开发者是从腾讯过来的）。
截止至 2023 年 9 月，字节内部的 UI 自动化框架已经支持很多端拓展，包括但不仅限于 Win、Mac、Android、iOS、Flutter、Cocos、Unity、Ue 以及一些内部技术栈等，依然是专门团队在做它以及周边扩展（部分核心老成员我还认识），包括集成到研发体系的云真机平台、集成到 vscode 的调试插件等。

这位是我的前同事，我可以作证他本人是很硬核的技术爱好者，可惜时运不济没找到合适的岗位

如果我来回答我估计和帖主回答得一模一样，我会觉得面试官纯粹是在找茬……
这种情况我一定会在面试结束的提问环节里反问他会怎么做。

可能这个面试官就是一个硬刚派，或许他想听到的答案就是你直接把问题打回给产品让产品自行细化，不占用研发测试双方的时间。但，这种在现实并不实际，但凡遇到哪怕有一点不配合的产研都无法如此执行，反而只会让测试背上臭名，让人觉得很难配合。

是 wenjie 本人吗？

对 qt 不了解，我猜测一下如果 qt 绘制出来的桌面应用程序，应该是可以用 Windows 的 IAccessible 机制来识别控件并点击，也就是可以去找找有没有工具支持这个机制。Mac 一般实现基于 XCTest，这个我不了解市面有什么工具。至于 Linux 就更加没接触过了，绝对意义上的小众，可以先不被 Linux 束缚，解决完 Windows 和 Mac 再来考虑它也行。

简历上可以写，但最好补充了解到什么程度，比如补充说明能用 java 大概开发什么程度的东西（如简单程序或实现算法），或者直接说你只是了解 java 语法基础，能使用 java 实现一些简单 Demo。

翻到这个老帖，因为这几天有另一个帖子在探讨测试行业的问题，很多测试同行会选择在这种帖子下去发泄自己过往所遭遇的不公，楼主就客观看待吧。

• 技术行业还算是一个相对公平的行业，因为同行更多是单纯的技术人员，所以多多少少会少一些没必要的职场勾心斗角，这种相对平等的氛围在初创公司或者互联网大厂可能会明显一点（只是多多少少会少一些，不是没有）。
• 前面说了这个行业相对公平，言下之意就是看个人能力。如果你没有足够的自我驱动和技术爱好，想通过加入测试行业尽快躺平可能不会如愿，因为这个行业很卷，待遇好的大厂更加如此。如果是希望奋斗拼搏，那测试、开发、运维各行各业都可以挑，具体就看你自己的技术储备程度。门槛最低的确实就是测试（也就是你的竞争对手会相对弱一些，但是待遇也低一些）。
• 至于考研，如果你自己没想明白你未来要做什么，考研确实多给你一段缓冲时间，让你想明白你想做什么，如果你本身是个非常懂得利用时间的人也许会在这两三年快速成长实现关键超车；但同理，如果你本身自律性不强，考研也可能让你更加麻痹，只是当下开摆直至下一次选择的时间节点到来。
• 最后，技术行业讲究技术硬实力，学历本身对这个岗位提升不大（但是可以让你获得优先被选择的机会），而你学过什么实践过什么技能储备如何自驱力强弱对这个岗位提升才大

所以这个问题，其实是要问你自己。

在 pycharm 配置里看看有无 “点击运行按钮运行测试，是对应跑了什么命令” 这个信息。
如果没有，那可能 ide 可能额外包装了一些东西进去（可能性不大，因为 ide 视角根本没必要这么做）。

我的做法是：

1. 明确自己想学习什么语言下的哪个 web 框架
2. 上 github 关键字搜索
3. 扒拉 5 个以上搜索到的关联性最强、star 最多的项目
4. 逐个快速看，哪个看起来逻辑性强，分层明显，业务表现最容易理解，就细看哪一个

这个步骤适用于我所有的新框架试水，包括昨天才开始尝试的 python fastapi，我也是这么做的，有一些 web 开发基础，只要对一个 web 工程 “写得好不好” 有基本判断力，就能独立去找。

首先我们可以认清自己的水平，大多数测试同学因为工作和精力关系，很难短时间内积累 AI 需要的数学理论和实践经验，所以我先排除掉测试手撸 AI 的无效建议。从更实际的角度出发是：

1. 可有快速了解一些算法包，现在的算法包封装得很完善（所以出现调包侠、调参侠的叫法），如果实际工作有需要的场景其实在编码上可以很快引入简单 AI 来提高效率（至于有什么应用场景，我一时想不到，因为我也没引入什么）。
2. 多了解 AI 的概念和思维，虽然不一定能用上 AI 技术，但是有了理论基础就不容易被忽悠，当有人说 xxx 可以用 AI 解决，可以很快识别结论真伪。
3. 与其焦虑 AI，不如多花点时间打牢质量保障基础，质量保障领域这么多事情可以做，这个世界上多一个人会 AI 不多，少一个人会 AI 也不少，为了跟时髦去卷自己毫无优势的领域，不一定真的有用。

我直接帮帖主调整了一下代码的 markdown，现在代码排版应该能看了

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

嗯对，我有特别强调的是大多数小项目小公司，确实有顶级体量的，小程序会是 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. 具体行业的情况我确实太了解，如观点不一先当我是错的，纯属个人交流。我也算是第一次总结我对安全的理解。