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

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

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

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

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

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

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

接上面，我们深入下以下问题：测试平台有必要吗？这些很难去回答，但我们可以从以下角色去研究下；

1. 测试人员，平台上线后最终交付给的是负责业务线的测试人员，这些同事每天忙于业务的梳理，需求的跟进测试，在没有测试平台前，有很多工具供他们选择，接口 JMETER，POSTMAN 等等，这些都是主流开源的工具也都是官方开发的，做的相对完善也容易上手，对一般工作需求 来讲还是可以满足的；现在做一个测试平台来替换这些工具，换谁谁都不愿意，所以他们觉得你这个东西不好用且没必要，哪天跳槽了对自己也没啥积累。
2. 测试经理，测试平台推进的人，身处管理职位，不得不考虑如何建立高效的测试流程。因此凡是市面上正在推行的技术方案都会尽力在公司内部推行。但是不乏有不少管理人员水平低，没有分析去盲目推行技术的。
3. 测试开发，总算不再点点点了，听上去也和开发平齐，相信没有代码搞不定的自动化，你们天天点点点有啥意思？点也点不出 bug 来，感觉用我们新开发出来的平台吧。

看 LZ 写这么多我也说下感受吧，其实我转行过来没多久，之前想着做开发无奈准备不足，再加上生活压力先入了测试的坑。虽然没做多久，但是通过这一年多来的工作也对测试岗位有不少感触。现身处某公司，规模较大 IT 部门管理混乱，每个部门都有自己测试的管理方式，这让我在一家公司就感受到了不同测试管理的差异。第一，附和 LZ 的关于测试平台这块先说，LZ 其实不止你，我目前所处的测试团队也做了相关的测试平台，从 19 年初就已经在投入使用，然而如楼主一样，团队内没有人愿意使用，尽管你吹的天花乱转也很少有成员愿意去学习，到了第二季度的时候，部门老大坐不住了，招了几个测试开发造出来的东西没人用多尴尬，于是强行推行让每个成员编写脚本使用，并纳入到绩效考核中去，于是组里每个人不得不为了绩效去使用这个平台，但是每个人也是为了迎合一下只是写几个脚本跑起来交个差就行，对外宣称自动化平台多牛逼...说下来是不是和 LZ 情况差不多？这种情况我们不得不去深度思考一下这背后的问题。

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