深有同感，工作中不怎么用到的东西 学习起来 的确效果没那么好，而且容易忘记

那是很向往的工作

我现在就是 这个状态，快 4 年的测试，然后感觉啥都会一点，却都又不是 很精

很有道理，收获了，感谢

领导认为开发需要为质量负责，需要加强开发自测，因此交到测试手上应该是完成度比较高
------领导都这样认为了，那就提高转测要求，开发自测用例充分一点，冒烟测试严格一些，不通过的直接驳回，尽量给测试执行时减少一些阻塞性 bug 产生；

问题归根结底是排期和意识问题，测试本身没有推动能力，下个迭代依然如此
------说明 问题未得到及时解决，逐步往上层反应，直到彻底解决，不然下个迭代依然如此，就还是会反反复复遇到这问题；

这鱼 摸得好

话说 你的学习 计划是怎么做的？我做了学习计划，感觉零零散散，只会有个大概方向，具体到细节时，就有点模棱俩可了

也不会 主动学习一些 其他的东西吗？类似于当前工作也许用不到，但是不代表以后的工作 用不到的那种

会不会 觉得自己学的比较杂乱，然后 不会很深入

工作中遇到的问题去学习尝试解决，是一种学习；
工作之外，拓展学习一些新东西，也许是和当前工作无关，也是一种学习；
但是自己零零散散的学习，容易出现遗漏不全面，无法形成系统，就可能还是需要一些系统性的学习

我一直 没有搞懂 元类，MetaClass，麻烦问下你有推荐的文章我可以借鉴下，学习下这个吗？

就目前我们做的：
1、用例的管理其实用 yaml 和 xmind，我觉得都可以，看起来都会比 excel 的结构层次更好；
2、数据的依赖，看数据依赖的多少，不多的话 可以就放全局变量里，不需要使用后立即清除就行。或者使用过后就删除，下次需要时重新获取，较多的话 可以考虑变量写入文件、数据库之类的
3、基于场景的接口测试，本身一个场景就是很多接口的集合，要是想单独对一个接口进行测试，那数据依赖肯定是需要 提前准备好的

赞同，每一个岗位必有他存在的理由。

敌不动 我不动

现在往测试经理发展，是不是早了点，我以为还是会到工作 5 年以后 往这方面去靠近。

测试架构师修炼之道 想问下是第 2 版？我搜了下 看见有第 2 版

就是现在有找到 方向吗？

按照你写帖子的时间，我们俩工作时长应该是一样的，现在咋样勒？

适合全国普及一哈

很难被衡量，但不能代表完全不需要，所有的东西都是这样，没出现意外就觉得是理所应当，一旦出现事故，就觉得要是当初怎么的怎么的就好了。。。

用例评审 感觉不用逐条过，毕竟不是每个人都关心你的用例产出。讲清楚测试重点和方向即可，重点功能让开发给出个影响范围。