还未发布过话题
  • 那就很难办,开发发布分支你可以做个钩子回调自动去跑用例,完了测试同事看到问题再让开发改

  • 先估摸下领导想要啥,别瞎意见。之前就有同事在会议上一顿说同类竞争公司的产品多好多好,领导一脸黑线。。

  • 如何确认是前端还是后台的问题 楼上的回答就可以了

  • 你的问题不在做不做平台上,而是没有人帮你推动,在保证 CI 没问题的情况下,如果是用例或者代码出了问题,就让相关负责业务的人员自己去排查,想进一步完善流程,自己去带一个产线,和业务人员一样去使用,这样才能避免闭门造车~

  • 兄弟,没人会装睡,希望你借前车之鉴做好,测试行业需要正确的方向推动。

  • 让所有的测试变成测试开发,测试开发为自己服务。两者合一的产出大家都看得见。测开的产出,自己能感受到。
    老哥,看你其他帖子的回复,我也觉的以后还有测试岗位趋势也正如你所说的那样,测试开发不分家。我若是管理我也会往这块儿去做,目前我还是觉的测试平台对于大多数公司是非必要的,测试深入技术去保证质量这是最应该去做到的,但是现在人员水平参差不齐,能力强的同学需要突出自己于是有了测试开发岗位,所以初期阶段测试开发经验的不足加上管理水平差,才会导致了开发平台没有人的囧事!

  • 再说个在群里发生的小故事吧,有小伙儿伴在群里说要找人一起做测试平台,一是练练技术,二是找工作也能撑下台面。于是大家开始讨论,A 说我们差个技术架构,找个做架构的来指导下我们;B 说我会写 Python,前端不太好再招个前端帮我们写写页面吧。C 说我们还差个产品,没有需求我们做的也是瞎做。恩,这就是来自一个真实的测试群里的对话。这也让我发现一个问题,想要做好测试平台远没有想象中的那么简单,就像做一个产品一样需要测试开发产品。测试平台开发好了,大家说难用那说明需求没想好,测试平台有 BUG,因为没有人测试啊。。

  • 接上面,我们深入下以下问题:测试平台有必要吗?这些很难去回答,但我们可以从以下角色去研究下;

    1. 测试人员,平台上线后最终交付给的是负责业务线的测试人员,这些同事每天忙于业务的梳理,需求的跟进测试,在没有测试平台前,有很多工具供他们选择,接口 JMETER,POSTMAN 等等,这些都是主流开源的工具也都是官方开发的,做的相对完善也容易上手,对一般工作需求 来讲还是可以满足的;现在做一个测试平台来替换这些工具,换谁谁都不愿意,所以他们觉得你这个东西不好用且没必要,哪天跳槽了对自己也没啥积累。
    2. 测试经理,测试平台推进的人,身处管理职位,不得不考虑如何建立高效的测试流程。因此凡是市面上正在推行的技术方案都会尽力在公司内部推行。但是不乏有不少管理人员水平低,没有分析去盲目推行技术的。
    3. 测试开发,总算不再点点点了,听上去也和开发平齐,相信没有代码搞不定的自动化,你们天天点点点有啥意思?点也点不出 bug 来,感觉用我们新开发出来的平台吧。
  • 看 LZ 写这么多我也说下感受吧,其实我转行过来没多久,之前想着做开发无奈准备不足,再加上生活压力先入了测试的坑。虽然没做多久,但是通过这一年多来的工作也对测试岗位有不少感触。现身处某公司,规模较大 IT 部门管理混乱,每个部门都有自己测试的管理方式,这让我在一家公司就感受到了不同测试管理的差异。第一,附和 LZ 的关于测试平台这块先说,LZ 其实不止你,我目前所处的测试团队也做了相关的测试平台,从 19 年初就已经在投入使用,然而如楼主一样,团队内没有人愿意使用,尽管你吹的天花乱转也很少有成员愿意去学习,到了第二季度的时候,部门老大坐不住了,招了几个测试开发造出来的东西没人用多尴尬,于是强行推行让每个成员编写脚本使用,并纳入到绩效考核中去,于是组里每个人不得不为了绩效去使用这个平台,但是每个人也是为了迎合一下只是写几个脚本跑起来交个差就行,对外宣称自动化平台多牛逼...说下来是不是和 LZ 情况差不多?这种情况我们不得不去深度思考一下这背后的问题。

  • 没太清楚问题点,monkey 和 appium 使用上不在同一个维度吧