我个人作为面试官，对三年工作经验的要求大概如下，楼主可以做个参考，挑自身不足的去补充：

• 编程基础（主要考察项）
  1. 熟悉掌握任意一门编程语言，可以独立实现一个小于 100 行代码的具体需求
  2. 了解常用数据结果（大学课本上那些链表、队列、堆栈、树），懂这些概念并能独立实现出简单版
  3. 有基础的算法思维，对代码性能有感知和分析能力，能独立解决 simple 等级的算法题
• 测试基础（主要考察项）
  1. 有丰富的用例设计经验，有用例设计思想框架
  2. 参与过自动化、性能、稳定性、兼容性测试，对其中某一项有除了执行之外更深入的理解
  3. 熟悉需求研发测试流程等各类测试接触过的上下游工具和规范
• 其他补充
  1. 有一定的业务领域知识，对业务的盈利模式和发展方向有基本的了解
  2. 有一定的目标感，对任务能自行做拆解排期，最好做过别人的导师

过于资深以至于找不到足够牛逼的坑位哈哈哈哈，我级别太 low，不知道大部门还有没有 leader 坑

只要帖子不【关闭讨论】，就代表依然还在招哦~

很多人刚出来工作那会劲头最热烈，虽然不说想要改变世界，但总想做一些事情来证明自己，很能理解。一般这种状态的原因可能是：是想得太多，做得太少，驱动力不够强，缺少真正让自己动起来的紧迫感。

建议：

1. 一个明确的目标：要 “在多久之后完成一个具体什么样的东西”，不要 “在多久之后学会什么东西”
2. 一份可执行的计划：以自动化为例，你需要前期先了解自动化拆解下来是哪些东西，如编程语言、测试框架、工程搭建、实战项目等，值得注意 “前期了解” 也是有 deadline 的计划中的一部分，而不是无限拖延的东西
3. 一次真正的实践：如楼主所说，自己学习的东西往往无法在工作实践，我们无法左右这个现实，我建议找一个你经常用的、不复杂的实体（如做 web ui 自动化，选简单网站做靶子），针对性做一次实践。你会发现越做越停不下来，至少在做的过程会遇到很多单纯靠看和写三四十行 demo 代码无法察觉的问题
4. 一个鞭策自己的理由：之所以精神内耗到底是想追求什么？你是不是真的有那么地渴望？如果不是就放过自己，如果是那先行动起来再说

还有一些内容可能和话题不直接相关，但属于 UI 自动化必须要一并做的，主要是从运营角度让 UI 自动化做得更好，补充一下：

1. 不稳定的用例要做隔离观察：收集用例运行结果数据（一般云测平台都有），通过这些数据去识别用例稳定性并做不同处理策略，如高频失败的用例要聚类凸显出来；或将不稳定用例自动下线隔离运行，当运行连续通过 N 次后再自动上线
2. 除了将用例做正向划分（如业务模块、用例优先级等常用思路），还可以做反向划分，如用例稳定区、漏测区、不稳定区、有效拦截区等等，会发现用例有更好的分级

看起来应该不需要框架，市面上大概也没有解决这么具体问题的东西。

简单点想，只要引入一个定时任务的库做好定时检查的配置，而对应的 “SVN 监控、检查用例、结果通知” 都是在这个业务场景下具体的需求，按需自行实现难度应该不高。所以我理解关键就是 “定时触发”，然后跑各种各样的自定义能力即可。

复杂点想，引入一个 web 框架，把检查流程封成一个接口对外暴露，可以在外面做个定时任务来定期调用，以及某些场景通过 webhook 去触发（如策划改完配置之后立马触发检查）。

调研过程大概花了多长时间左右？以天为单位的话

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

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

在学校先写 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 本人吗？