一般 UI 自动化不会做全量的业务吧。
我们公司一般是接口全量，UI 自动化只做关键业务和 TOP 业务。

如果确实用例多，除了增加执行机器外，还可以优化下框架代码，脚本代码，比如减少初始化操作时长，提前处理测试数据等等

这不完全是开发的问题吗？你们既然可以测到问题，那么由此产生问题的原因难道就没有推着去解决呢？还能反复因为代码合并的问题导致缺陷不断？

出去多面试吧，领导要是觉得你值得留，就会给你涨到外面差不多的工资，如果不留你，你就直接去外面看看吧。

换不起~

实际上，公司层面不管是领导还是开发都觉得既然你要做自动化就应该自己解决所有自动化过程中中遇到的问题，比如验证码识别，双因素登陆校验，文件上传下载。尤其是自动化需要运行在生产环境中的时候，执行 UI 自动化过程中需要解决太多棘手的问题（测试数据，业务回滚冲正，验证码，短信等）。

开源么？

正常的测试都是手工 + 一点点自动化 + 一点点性能，我想没几个公司会有能力专门养几个工资比开发还高的测试测试去专门搞那些花里胡哨的东西吧。

如果一开始就有能力做开发我觉得没人会选择测试。
时间太长就算技术能力高了又会碍于累积的多年测试经验不想换赛道。
我建议技术能力可以，学习能力可以的人可以往高级开发，架构师方面发展。
除了一些大厂，中小厂里的测试真的没啥发展前途，开发和你同一天进去，人家涨薪的速度可能是你 2 倍以上。

这样返回没问题，正常框架都是这么做的；
严格点，开发需要对这种代码层面的 Exception 堆栈进一步封装成可阅读内容，可以提一个级别低的漏洞缺陷：
漏洞名称：异常信息泄漏
漏洞描述：未自定义统一错误返回导致信息泄漏，抛出异常信息泄漏，错误详情信息泄漏
漏洞风险：后端接口服务在出现异常报错时，没有进行合适的包装便将所有信息返回给前端，通过抓包工具或者 Chrome 开发者工具可以查看这些异常信息，可能包含例如表结构，代码包名，业务逻辑等敏感信息，极大可能被黑客所利用。
漏洞修复建议：Java 后台对所有异常出错进行包装，返回合适友好的提示信息，禁止将异常中所有信息返回给前台。

不管是偏业务测开还是偏工具测试真的如同楼主所说的需要料理这么多方向的事情？

这个薪资是说工作年限为 0 也有可能拿到 12K 嘛？

他制裁他的，我依然用我的，他都制裁了，还担心他会告到我们？

frame 层有考虑到吗？

编程语言封了 还不是照用。

天天用你们的 PTS，那我只能在你的平台上点点点，那我怎么涨工资。

没人用 LR？

论坛里的开源项目或者码云上找一找，有不少，但是可能不是 100% 满足你的需求，建议拿来开源的项目，再二次开发吧。
可以看一看 AgileTC、MeterSphere、LuckyFrame 等。

国企，尤其是这些所谓设计院，我是真不想吐槽什么了。

既然是 UDP 协议的，那我觉得你们测试也并不需要考虑排序的问题吧？如果对接受顺序要求这么严格，也不会用 UDP 了吧。

有能够转开发的机会还不好好把握啊。
如果我当年有点开发基础我可能早就成为纯开发了。

说真的，当年和我一起去干 IT 的开发同学，同样干 7-8 年，工资差距那确实是大的很。

闲的蛋疼是吧？

Python 自己封装的框架 ，还有自己开发的 UI 测试平台。

ruby+cucumber 是我们公司大概 8 年前用的技术，早在几年前就被淘汰了。
BDD 在测试框架中的使用说真的，就和 RF 的关键字封装一个样，确实没啥亮点，只是换成了中文而已。
如果只是为了不懂技术的人方便编写或者读懂 UI 自动化用例，我建议直接做成 UI 自动化平台会更清晰易懂。
比起这个，我觉得是数据驱动，用例报告管理以及录制调试这些功能的拓展更加重要。

羡慕还有时间看书的人哈！