论坛已经有太多讨论测试、测试开放、职业规划、学习计划的帖子了，可以搜一下看看能不能帮助渡过迷茫期。

既然觉得毫无希望，那还不赶紧跑路？

真的回答得有点腻了，同样的问题换着花式问

别笑，我 21 年定点无脑入场，年化起码 -30% 起步 弃疗了

小公司主要是事情太多太杂，很多基础不完善，什么都要亲力亲为，意味着要花费大量时间做初级事情，这样子进步速度肯定就不够快了。

也不是不行，只要面试能圆过去，简历不过是敲门砖

哈哈，没事没事，我也不是杠，就随手写的【不用怀疑】 。
现在虽然环境不好但是还是给得到，甚至很多大厂测试毕业生就 20k。只能李佳琦一下自己，这么多年工资不涨就得卷自己了

主要是你不说是什么厂，就没法给建议。但是至于那一个月的的中厂经验，你就直接并到空窗期里去就好了，简历上呈现以小厂开始，没人会关注，即使知道了大概也不会有想法。毕竟工作不合适还有更好的机会，人家要过去这不正常嘛

大厂三年，测试都是有 20+ 的，不用怀疑，测开就更高了

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

• 编程基础（主要考察项）
  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、差异化文件标记等，方案是如何识别到这些差异源关联的功能，在细节上也会有各种人工保证的前提，没说起来那么简单与智能），最后每个版本节省了 “海量” 回归人力。

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

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

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