本来想专门看一下调研过程，了解一下不同工具优缺点对比以及选型的判断依据，结果刚好这块省略了……

这么笼统的问题先百度、必应、谷歌。
实话说我连问什么都没看明白……

在学校先写 C++，后来为了找工作学 Java，实际工作后开始用 Python，工作 N 年因为要业务有需求又用了 Golang 和 TypeScript……

实际证明，做 QA 的话，编程语言只是纯纯的工具，写的东西又不需要追求极致性能或者什么，基本还是围绕业务技术栈或开发效率去选择。

所以我还是建议 Python。

补充：如果精力足够，个人建议掌握 Python 是必须的，同时再掌握一门高性能高热度的平台后端开发语言，Java / Golang 都可以（建议 Golang）

我没用过呢，不过看着框架有在迭代，说不定 bug 已经被解决了，不过之前有个帖子说这个玩意儿不好用😂，可能得慎重考虑一下。
https://testerhome.com/topics/37406

小程序官方的 ui 自动化框架：https://minitest.weixin.qq.com/#/minium/Python/readme

太长不看：前团队的同事最近几个月成功在内部某大型业务里落地了。

精准测试方案，基本都是围绕这测试覆盖率和代码调用链技术做各种手段。标准的精准测试方案，无论是服务端还是客户端，大多都离不开前期的人工成分，比如客户端的关键思路是通过录制用例的方式将覆盖的代码路径和这个测试用例绑定起来，最后通过代码路径上的变更感知来推荐对应用例，可以是手工用例，也可以是 UI 自动化用例；同理服务端也大差不差。

之所以不好落地是因为 “录制” 这个事情本身就有很大成本，再加上历史录制的用例还要定期更新，意味着还有不小的长期维护成本，除此之外甚至还有 “打标” 等更多人工成本在里面，除非项目足够的大且足够的稳定，不然效果很差。至少据我所知，在字节跳动内部，头条、西瓜、抖音这些 app 都没有大范围落地这种标准的精准测试。

再来说我身边的成功案例，是一个非标准的精准测试方案。回到精准测试本身，无非是想通过某些手段将执行的用例数量删减到一个合理范围，从而聪明地降低测试工作量的同时还能保证相近的测试效果。这个落地业务本身有国内国外版本，之前的策略是两个版本发版都需要全量回归用例，通过落地精准测试，在国内版本依然全量回归的前提下，针对国外版本只做 diff 上的回归（这里就涉及国内国外版本的差异的引入源，主要是 编译配置、Feature Gateway、差异化文件标记等，方案是如何识别到这些差异源关联的功能，在细节上也会有各种人工保证的前提，没说起来那么简单与智能），最后每个版本节省了 “海量” 回归人力。

而这个精准测试案例，最重要的是它带了业务特性，相比于标准的方案，它满足了更多前提条件，需要解决的问题不需要那么 “广泛”。

这…… 确实尴尬，业务类型这么特殊的吗

所以就要挑时间压测了，只能选择业务流量低峰。举个例子就是凌晨两三点的，这时候线上没什么流量，大把线上机器资源空闲，你怎么压都不至于把资源打满到影响用户体验的级别😂

影响是有的，主要风险是否可控。

假设是一个亿级日活的产品，如果压测只是影响个位数或百位数的用户很短暂的使用体验（比如稍微服务端卡几分钟），那大概率收益大于损失，在风险可控的前提下可能会这么去做，甚至往往对线上根本就无实际影响。（我这个假设不一定合理，意思上就差不多这样）

单独的压测环境也是可以的，看具体情况。如果线上环境本身部署起来就不复杂，确实可以单独做压测环境。但如果业务体量足够大的话，部署压测环境对齐线上的成本、压测环境机器资源的开销，都是不得不考虑的。

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

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

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

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

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

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

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，现在代码排版应该能看了