本渣刚刚跳槽成功
年薪：30 个达不溜
职位：测试开发
已经入职差不多 1 个月了，但是我发现一个问题，领导貌似不希望我只限于写写自动化，写写接口
还说 这些都是一个高级手工测试的技能，
应该让我发挥更大的价值，，
而我感觉 测开就是写自动化，写接口
难道测开就是必须动辄写平台？写平台的话，短期内又看不到什么业务价值，
而且哼哧哼哧开发个半年，还没有 postman，apifox，metersphere 之类的好用，还一堆 bug
别人开发好的平台直接拿过来用不好么？
迷茫了。。
求大佬们指点
你的关注点有点不对，关注点不是写脚本还是写平台，这个只是实现形式。关注点应该是做什么能帮助团队的质量保障做得更好。包括效率上的提升，以及一些深度上的扩展。
你领导认为不只是做自动化，我个人其实也认同，毕竟自动化用例这个大多是强耦合业务的，测开人力比业务测试少很多，测开干这个，投入产出比不匹配，而且写出来的自动化业务测试同学不一定信任，还是手动再测一遍才心安，那就是白写。
举几个以前带的团队做过提效的例子：
1、测试环境数据库 ddl 的维护提效。为了便于有需要时并行测试需求，一共有维护 4 套测试环境（此处先不追究是否合理，这个是当时现状）。经常遇到由于 DDL 维护不及时导致需求部署上去后，由于 DDL 过时导致部分核心流程不可用。前期是做了一个 Python 脚本能一键应用上线时的 DDL 到 4 个环境的数据库中，保障和线上 DDL 一致。后期是引入了 flyway ，能让服务自维护 DDL 的框架。
2、定时任务触发提效。开发的定时任务用的是 spring boot 自带的 @Schedule ，缺少手动触发机制，每次测都得等到时间才能触发。后续基于做了扩展方法，测试可以通过调用接口传入定时任务相关参数，就立即启动定时任务，不用干等。
这些都不涉及平台开发，也不是写自动化脚本，但都是能有效解决当时团队痛点的手段。视野拓宽点，不要只看到自动化。当然楼主说的开源有好工具直接用这个是认可的，只是开源工具平台很容易在接入业务的最后一公里不方便（最常见的是和公司账号体系的打通，开源工具不大可能适配每个公司自己的账号体系），所以一般还是要做点二次开发才更适合使用。
长期也要考虑后面怎么 show 的问题，从这个角度，搞个前端界面包一下， show 起来容易很多，所以领导一般也喜欢做成平台形式，ppt 展示起来，总归比配一个报告或者代码的图看起来好很多。
说下我的理解哈
从职业发展来讲，测试开发可以干自动化测试，效能工具或平台开发，或者是专项测试及相关工具。
其实对你来说，这个可能是一次比较好的机会。尤其是你的 leader 没有什么明确思路的时候，你发光的机会就来了。
先跟你 leader 对齐下目标，然后梳理思路，确定实现过程，最后就周期性跟他对齐结果就行了。
对齐目标类似就跟做规划一样，可以从 3 个角度去处理。1.你们所在部门的岗位职责。 2.你们部分承接的上级部门的 OKR 是啥？3.结合历史分析，比如去年你们哪里做的不够好，外部评价不够？ 就从这些角度跟你老大讨论下，看看你们要大概做成什么样子，对你的期望是啥？
梳理思路就是讨论下实现过程怎么搞，开源工具集成还是自研工具?分几个阶段做，里程碑怎么设置？到时候做完大概怎么推动落地等等，然后就是搞一搞跟 leader 同步下进度。如果搞得不错，指不定还能拉更多资源，你就升级当 leader 了。
思考了一下，还是以赋能为主
向上对齐，了解上级对这个岗位的期望
研发各种能提高测试团队工作效能的工具或者方法
都可以 不局限于表现形式 关键是你得熟悉工作流程 善于挖掘潜在的需求
测开最大的价值是解决业务测试流程中真正的痛点，而这个痛点，只有真正在手工点点点的同学知道。无论是 UI、接口自动化还是自建平台，在没有获得业务测试的认可和使用前都不算是有价值的内容，只能算是完成 kpi 式的向上管理。你现在要做的就是与各个业务测试团队沟通并确认真正的需求，并将其实现
向上对齐没毛病
领导让干啥就干啥呗，除非又让你干活，又不给你时间，还不给你钱。
不想打击你，主要是你领导太渣，跟他混没出路
让干啥就干啥呗
一步步来吧，先实现工具化，然后实现平台服务化
同意四楼的观点。应当解决业务测试流程中真正的痛点，测试执行可能只是其中一部分，环境准备，数据构造，报告分析等等环节就非常通顺么？有没有可能进一步提效呢？也可以多方面考虑下
树叶
回复
这种领导没有清晰的目标，甚至没有向上管理的能力，格局也不大，能干一年是一年那种，要是上面要找人背锅，只会送你去祭天，你不早点跑，还留着过年？
说下我的理解哈
从职业发展来讲，测试开发可以干自动化测试，效能工具或平台开发，或者是专项测试及相关工具。
其实对你来说，这个可能是一次比较好的机会。尤其是你的 leader 没有什么明确思路的时候，你发光的机会就来了。
先跟你 leader 对齐下目标，然后梳理思路，确定实现过程，最后就周期性跟他对齐结果就行了。
对齐目标类似就跟做规划一样，可以从 3 个角度去处理。1.你们所在部门的岗位职责。 2.你们部分承接的上级部门的 OKR 是啥？3.结合历史分析，比如去年你们哪里做的不够好，外部评价不够？ 就从这些角度跟你老大讨论下，看看你们要大概做成什么样子，对你的期望是啥？
梳理思路就是讨论下实现过程怎么搞，开源工具集成还是自研工具?分几个阶段做，里程碑怎么设置？到时候做完大概怎么推动落地等等，然后就是搞一搞跟 leader 同步下进度。如果搞得不错，指不定还能拉更多资源，你就升级当 leader 了。
你的关注点有点不对，关注点不是写脚本还是写平台，这个只是实现形式。关注点应该是做什么能帮助团队的质量保障做得更好。包括效率上的提升，以及一些深度上的扩展。
你领导认为不只是做自动化，我个人其实也认同，毕竟自动化用例这个大多是强耦合业务的，测开人力比业务测试少很多，测开干这个，投入产出比不匹配，而且写出来的自动化业务测试同学不一定信任，还是手动再测一遍才心安，那就是白写。
举几个以前带的团队做过提效的例子：
1、测试环境数据库 ddl 的维护提效。为了便于有需要时并行测试需求，一共有维护 4 套测试环境（此处先不追究是否合理，这个是当时现状）。经常遇到由于 DDL 维护不及时导致需求部署上去后，由于 DDL 过时导致部分核心流程不可用。前期是做了一个 Python 脚本能一键应用上线时的 DDL 到 4 个环境的数据库中，保障和线上 DDL 一致。后期是引入了 flyway ，能让服务自维护 DDL 的框架。
2、定时任务触发提效。开发的定时任务用的是 spring boot 自带的 @Schedule ，缺少手动触发机制，每次测都得等到时间才能触发。后续基于做了扩展方法，测试可以通过调用接口传入定时任务相关参数，就立即启动定时任务，不用干等。
这些都不涉及平台开发，也不是写自动化脚本，但都是能有效解决当时团队痛点的手段。视野拓宽点，不要只看到自动化。当然楼主说的开源有好工具直接用这个是认可的，只是开源工具平台很容易在接入业务的最后一公里不方便（最常见的是和公司账号体系的打通，开源工具不大可能适配每个公司自己的账号体系），所以一般还是要做点二次开发才更适合使用。
长期也要考虑后面怎么 show 的问题，从这个角度，搞个前端界面包一下， show 起来容易很多，所以领导一般也喜欢做成平台形式，ppt 展示起来，总归比配一个报告或者代码的图看起来好很多。
陈恒捷
回复
PS：如果发现找不到团队痛点，问业务、问领导都问不到（很常见，习惯了就会成为盲点），你自己直接跑去业务，和业务一起当一个月业务测试，一起测需求，哪些地方低效且容易提升效率，就立马可以发现了。
本质职责：保产品质量底线，如有余力，再来说提升研发测试效率
- 常见的标准质量体系是什么
- 业务形态相关的特型质量问题在哪里
- 你的数据度量大盘有没有
呈现上，你的能力地图（都已经有些什么能力），你的风险地图（盘点业务潜在的质量问题），早期通过度量大盘驱动业务建设，后期通过能力成熟度模型深化工程能力，这一套套看似官话套话的东西，理解下来，够做好多年。