听起来有点温水煮青蛙，一直做没挑战的事情，容易导致学习能力下降。

可以自己找挑战来做，最好是工作上的挑战。这块建议你可以看看业内有什么实践公司可能用得上，又有一定挑战的，可以找 leader 沟通下，尝试引入。或者去推广需求自动化给更多的测试人员，让他们可以逐步自己完成，把你解放出来做其他也需要的事情。

我和你差不多，多少个达不溜了

培养一些管理思维

先归因看先都有哪些类型吧？然后专项治理

开始读源码吧

有没有对 metersphere 二开感兴趣的

大佬最终去哪家呢？

最大的成长不应该是学会了踢皮球吗

大厂钱多事多，要钱还是要闲

把代码跑起来，对感谢兴趣的模块进行学习改造。大佬要学那个，推荐下。

找开源项目就像看股票 前期找明星开源项目【就像龙头股】代表的是趋势 有的聊

测试的悲哀，去字节跳动这种公司，测试也逃不过点点点的命运，从你的描述来看，好像也是打杂的存在

可以结合工作需要，选择一个开源项目来使用，完成一些工作上的事情。过程中熟悉项目源代码，并在此基础上做一些二次开发进行练手。

二开

人都是被逼的.

请问下你是面试的什么职位？

大厂就这，刷新了对大厂的认知

大佬好强啊，感谢分享

记得之前我有个同事面字节测开，三面的时候，面试官问，我这里有两个方向，要么全职研发，我面的很难，要么带外包，我面简单点......看来字节进去带外包都是坑

想办法把需求测试时间掌控权弄到自己手上，再合理的制定计划，拉宽测试周期可能会减少压力，重复性的沟通工作可以以文档的形式输出（需求、背景、改动点等），挤一挤时间还是有机会去学习或者划水的。我一个字节朋友能跟我 wx 聊 2 个钟

谢谢群主分享经历

祝好

阿这，阿这，字节这么可怕的么，还是说大厂都这样？？？

一般发版之前重新拉一个代码分支然后进行回归测试，测试如果有问题再修改，一般是一周左右的时间，这个时候其实就是过一下 bug，验证正确就好了，自动化将常用功能跑一下，然后定版。因为我们是做平台，发版之后项目组升级，有问题开发会在版本和快照上修改，验证好之后，大概一到两周之内发补丁包

我们也头疼这种发版 bug
原因 1：代码分支错了 2.运维部署问题 可是这 2 种都跟测试没有关系