通用技术 测试开发到底应该干点啥

树叶 · 2022年03月18日 · 最后由 王稀饭 回复于 2022年03月22日 · 2319 次阅读

本渣刚刚跳槽成功

年薪: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 了。😀

共收到 18 条回复 时间 点赞

思考了一下,还是以赋能为主

向上对齐,了解上级对这个岗位的期望

研发各种能提高测试团队工作效能的工具或者方法

都可以 不局限于表现形式 关键是你得熟悉工作流程 善于挖掘潜在的需求

测开最大的价值是解决业务测试流程中真正的痛点,而这个痛点,只有真正在手工点点点的同学知道。无论是 UI、接口自动化还是自建平台,在没有获得业务测试的认可和使用前都不算是有价值的内容,只能算是完成 kpi 式的向上管理。你现在要做的就是与各个业务测试团队沟通并确认真正的需求,并将其实现

向上对齐没毛病

关键是领导让我自由发挥 😂

领导让干啥就干啥呗,除非又让你干活,又不给你时间,还不给你钱。

不想打击你,主要是你领导太渣,跟他混没出路

让干啥就干啥呗

一步步来吧,先实现工具化,然后实现平台服务化

树叶 #11 · 2022年03月20日 Author
保卫战 回复

怎样才算不渣?求大佬指点

同意四楼的观点。应当解决业务测试流程中真正的痛点,测试执行可能只是其中一部分,环境准备,数据构造,报告分析等等环节就非常通顺么?有没有可能进一步提效呢?也可以多方面考虑下

树叶 回复

这句话就能说明你们领导对于测开岗位本身的定位以及工作内容就不清晰,这个还是明确好来再开展工作更合适

树叶 回复

这种领导没有清晰的目标,甚至没有向上管理的能力,格局也不大,能干一年是一年那种,要是上面要找人背锅,只会送你去祭天,你不早点跑,还留着过年?

说下我的理解哈
从职业发展来讲,测试开发可以干自动化测试,效能工具或平台开发,或者是专项测试及相关工具。
其实对你来说,这个可能是一次比较好的机会。尤其是你的 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:如果发现找不到团队痛点,问业务、问领导都问不到(很常见,习惯了就会成为盲点),你自己直接跑去业务,和业务一起当一个月业务测试,一起测需求,哪些地方低效且容易提升效率,就立马可以发现了。

本质职责:保产品质量底线,如有余力,再来说提升研发测试效率

  1. 常见的标准质量体系是什么
  2. 业务形态相关的特型质量问题在哪里
  3. 你的数据度量大盘有没有

呈现上,你的能力地图(都已经有些什么能力),你的风险地图(盘点业务潜在的质量问题),早期通过度量大盘驱动业务建设,后期通过能力成熟度模型深化工程能力,这一套套看似官话套话的东西,理解下来,够做好多年。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册