首先非常感谢你们使用 sonic。

楼主感觉偏向往开发方向，我这边有三个建议

1. 可以参考一些比较著名的开源项目，如 appium，了解启动机制，底层调用等等，理解怎么跑起来的，甚至可以提 pr 给这些项目，对自己提升是非常大的。（这么一说你可能感觉不到，但是真正了解之后真的学习很多
2. 可以深入了解一些开源产品的原理和缺点，就像 Sonic 纯 UI 形式拼接自动化也不是万能的，所以我才新版本暴露了可以跑自定义脚本。
3. 当然你有想法也可以提交贡献代码（不一定是 sonic 和 appium，任何简单的工具提一个 pr 都是让自己大进步的过程）。提交了，你的开发技术就能在全世界范围内应用了，让你的 coding 变得有意义，（也可以写到简历上）

如果不是往开发方向走，那楼主的想法其实是很多测试的想法，我的看法是这样

1. 工具落地其实很多工作，不是用了就行，怎么有产出效果才是最重要的。如果 Sonic 走 ui 自动化（当然不一定是 sonic），能给你们节省 70% 回归时间，其实就是有效的。给你们用例覆盖了 30%，那就可以思考怎么覆盖到 40%。而且设计一条真的【有意义】的自动化用例不是一件容易的事情
2. 另一个是打通流程，怎么做到开发 jenkins 出包就能触发测试、测试完毕发送报告等等整个链路打通，也是一个不简单的点，总的来说一个工具放在这，不是用了就完事的，其实很多很琐碎的工作。

lz 加油

不太清楚楼主在团队里是什么角色。正文里提到有测试的 leader，而且他已经有搭起来直接能用的 sonic 框架，那这个结论很正常啊？
从团队来说，学习和搭建一个可能是全新的框架是有成本和风险的。如果你有很充足的理由觉得纯 UI 的框架不适合你们团队，或者说不适用于长期维护，不妨找个时间和测试的 leader 讨论一下。但是要做好准备，也就是说你已经有足够的把握能把这一整套都掌握了，才可能说服对方。

感谢，比起闭门造车去看开源项目带来的提升更大，点醒我了

我的定位是自动化测试，但是项目组只有我一个，而且我也是实习毕业转正的，有点人微言轻。

我的建议：面向问题去寻找解决方案，如果资源不允许，优先找现成可用能短时间看到效果的方案，你就会发现在应用的过程中，越是万金油的方案，就越是不好用，逐渐就会有你的想法，在里面加入越来越多的公司和项目特色了。

我其实想表达的点是：不要什么都想着自己亲自造轮子，解决一堆技术难题什么的，因为拿不到收益看不到结果，事情往往都活不下去……敲黑板的重点是，做什么事情都要面向问题，哪个选择明显效率更高成本更低，就是小学加减法了。

是，像我看 appium 源码是学习了不少。当然你如果接口方向也可以看其他的。

因为像我以前面试来说，简历上写什么开发过 ui 自动化平台、接口自动化平台，面试官根本不会在意，因为别人已经沉淀好几年的玩意了。但是假如你能跟面试官点出（sonic 为例）

1. sonic 设计可能有缺陷，我会 xxxx 这样处理觉得更好
2. 给 sonic 提交过 pr，修复了 xxx 重大 bug，给开源项目贡献
3. 二开了 sonic 在部门内部落地 xxxx

哈哈哈自私点，我拿 sonic 举例。这样会比造轮子给人感觉靠谱很多，因为面试官很难知道你自己平台到哪个水平，问是问不完的，但是你能点出 xxx 的缺陷，xxxx 的设计很优秀，xxxx 这样的问题你怎么去兜底解决，那不仅对你成长有很大帮助，以后真要自己上手做也能避开这些坑

万分感谢，你这两段话给我指明方向了。

如果是想做纯工具开发，那直接去干开发，干嘛还干测试。

因为喜欢测试才干测试

你傻啊，你自己写不管对组内有用没用，你至少简历能多点东西，你老大肯定是考虑真的能提高点效率。屁股决定脑袋

当我们采用平台化来做专项测试时，封装好功能，降低对测试人员的要求，只要通过页面编排就能够执行相关的测试。那么，测试人员如何提升自己呢？这里涉及到的角色有两个：个人与组织，这两个角色对平台的诉求是不一样的。

组织：从组织的角度来说，希望的是有统一规划和管理，同时能够有效降低准入门槛，通过简单的培训，让更多的测试人员能够开展专项测试，所以更需要平台化的管理方式，能够提供标准化的、可视化的、操作方便的服务 。

个人：当你进入到一个团队中，有现成的平台给你使用时，一定不能满足于使用平台，而是应该抓住机会去了解平台的具体实现，甚至参与到平台的研发过程中，把别人的开发设计和解决问题的思路变成自己的心得体会。如果只会依赖公司平台开展专项测试，那是平台的能力，而不是个人的能力。这也是为什么很多面试官不太喜欢大厂出来的同学，因为离开了平台，个人的能力有可能出现断崖式的下跌，切记（其实很多岗位都会有类似的问题，要学会区分哪些是自己的能力，哪些是平台给你的加成）。