FrameWork 的工作量会较大，需要拦截所有的第三方中间件的调用。如果公司统一技术栈还好，如果不统一，各个业务线自己搞一套，支持工作会很难做。同时比较好奇，你们 Framework 是基于什么技术开发的，类似 jvm-sandbox？

建议弄一个视频专栏

写的很棒

你太敏感了，27 楼只是说哪种方式更适合女性，并没有否定的意思。如果真的一心向技术，转战一线 RD 也没什么。随便讨论讨论直接就被扣上三观不正的帽子，也是醉了

说的很棒~

这个其实就是选择的问题。我自己目前不会向纯工具开发转了，我的优势不在这里，虽然工作这些年也做了不少工具。选择了不同的方向其实也决定了你以后学习的侧重，如果真的转向工具开发，就像其他同学说的，可能要比很多 RD 都要精通，侧重的是技术的深度。如果选择高级业务测试，其实你更需要关注对于某些问题的测试保障方案，可能更关注于广度，当然也要对技术有较为深入的了解。具体如何选择，还是要结合个人的情况决定

这确实是很多公司都存在的一个状况

没有遇见过，不过你可以打断点调试下看看是什么原因

很有意思~

开源的越多，确实使技术门槛变低，不用再去重复开发一些通用型工具 (比如接口测试啊)，但是解决方案的变多不会大幅减少实践落地成本。现在这部分是有些脱节的，我们有很多高效好用的工具，但是由于各种原因，落地情况其实并不理想，这后续会成为测试开发同学能力提现的地方

方向 2 的话是要求你根据实际需要定制性的开发一些工具，毕竟通用型效率工具不能解决所有问题。但是这也不是必须的，如果有完善的效率团队支持，也可以将痛点梳理出来，交由相关同学来开发。如果测试开发绝大部分时间都在开发一些业务耦合度较高的工具，后续迭代以及维护会成为一个不小的挑战，造轮子可以，但是不能一直造烂轮子

嗯，分析的比较到位，专业的事情还是交给专业的人去做，其实我们现在已经有很多优秀的工具，不管是公司内部的还是开源的，现在是落地比较难。传统的手工测试人员的比例会逐渐降低，高级业务测试的比例会提高，有效的承接效率工具的输入将会变成一项重要的能力，什么都想搞，可能什么都搞不好

在国内的公司有独立的工具研发组的少之又少，特别在一些大公司，通用效率工具的研发是由 RD 来进行，而不是由测试开发来做。我也说几乎等于测试，不过这样的公司应该不多，你知道哪些公司可以放出来给大家看看，可能是我孤陋寡闻了

专注于测试工具开发的团队，是要深入的业务中，了解业务面临的痛点，然后抽象成工具。这个部分很考验一个测试开发的能力，不懂业务不可能做好工具的，即使按照业务测试同学的要求来做，也不一定做的完美，让工具开发同学深入业务会是一个不错的实践。

关于测试开发的产出问题，目前确实没有比较好的度量标准，之前发的如何度量测试开发的产出比较有启发性，对于部分兼职测试开发和业务测试的同学有一个好的借鉴

看到理财部分，忍不住笑了出来，今年的行情太差

这么好的文章，竟然一条评论都没有。。。。

很好的实践。。。。

职业规划这个事情，最好有自己的思考，自己为什么跳槽要想清楚，即使你真是为了钱也不要直接说

现在也还不算太晚，后续要多加注意了。。。

整理的很好~~~

当时主要还是功能测试，部门开发了一些辅助工具，来完成数据写入和读取，主要来验证数据流程的正确性，没有涉及到性能方面。

赞一个，我现在也碰到了一些问题，感觉坑有点多

说的是这个事，将用到代码就约等于白盒测试的同学，应该是入行不久，入行几年后就发现在当今的互联网公司，绝大部分的测试都是黑盒，白盒基本上很少用到。相反一些传统的公司，比较重要的服务白盒还多些

#11 楼 @simple