其实领导是知道这个不稳定的，但是自动化这个事情是整个测试组做了差不多两三个季度才做起来的，如果一下子放弃不用，之前的时间精力就是白费了，所以领导给的思路就是：遇到问题不能放弃，而是要解决问题，既然不稳定那就解决不稳定的问题。我感觉他不会放弃，而测试人员又很抵触这个事情，所以才无解

“数据驱动” 的定义：
基于精益分析和数据闭环理念，通过业务数据化和数据业务化，采集数据并将数据作为生产资料，通过数据分析和挖掘方法提炼规律、获取洞见，再应用到业务过程中，循环做出正向反馈，促进业务优化，实现以数据为中心进行业务决策和行动
换句话说，体现一个东西好与不好可以从两个方向出发，一个是有他怎么好，一个是没他怎么不好

喊领导招聘一个专职人员，专门每天负责自动化搭建、维护

这种事情太常见的了，首先和领导理性探讨，判断这套方案是否真的适用于当前的业务现状，这个过程需要你有一些数据准备，包括有这个系统前和有这个系统后的测试工作量对比（占用了多少人天），解决完问题之后节省的工作量人天可不可以将历史付出掰回来。

• 如果得出的结论是不可以，就不要碍于面子不把它撤掉。如果领导就是要坚持用，他愿意背锅，那倒无所谓，听话配合就好了。
• 如果得出的结论是可以，那就去解决发现的问题。这个过程是系统性周期性的，需要长期投入人力，可以先把历史遇到的问题盘点出来做个简单分析（这里就体现出保留历史数据的重要性），找到 Top3 的问题一个一个解决。网络不行那就改善网络状态或者增加重试逻辑，开发改动就要看是开发随便改没规范还是测试没及时跟进维护好…… 解决完之后再看新的工作量再来一次分析循环……

到底是环境问题导致失败还是平台不行导致。如果平台稳定性就是差，自身存在问题，就直接上报需要考虑其他解决方案。如果项目自身的问题那就具体分析到底哪些问题导致的。
像你说的用于发版前执行怎么还会因为开发改动导致失败，这样流程中肯定有问题。
如果是脚本误报多，可以考虑优化一下测试脚本，断言优化、等待机制、元素处理这些。或者给脚本瘦瘦身，只做最核心的链路那些，也能减少点负担。
如果说网不好经常失败，测试组要去协调稳定的网络，根据具体场景做调整和优化。

没有人喜欢自己的方案被否，自己冲上去当黑脸也不好。楼主可以整理一下现阶段的问题，写一些解决方案提上去看看领导的反应。有个自动化，述职的时候也能给你刷数据不是

可能需要先搞明白几个问题
1、现在的不稳定， 是否是可以优化的，如果有优化空间，现在的人员，是否有能力优化，优化后的稳定性， 能否满足要求， 第三方平台这种，用过的都知道， 要不要考虑换个方式。
2、要做自动化，必要的成本投入是必须的， 那就看做完之后的长期收益， 能否与投入匹配，是否需要安排专人投入。
3、有一点非常重要， 自动化不是万能的， 要给自动化一个正确的期望， 而不是想着自动化能让人一劳永逸。

这样不就有事情做了吗？对于普通员工来说 多了一份 一直能够持续的 KPI，测试稳定性的改进和优化，对于整个组来说，多了一个平台的维护工作

我们之前也用数据驱动方式（也就是上面说第三方平台），开始很简单很有激情，随着用例数或者需求变更频繁，慢慢就不适用了，所以建议还是写代码方式更好，更直接。 但是这样就需要有人牵头自动化脚本编写，并组织培训，定目标

领导看中的多是结果和效果，要是我就偷偷摸摸搞，等有一定效果能拿的出手了再找领导，否则领导不会认可，应为自动化测试接口自动化见效快，UI 的见效慢

我们公司就是，领导只是说了一句要搞自动化，然后我和另外一位同时平时忙着测业务，忙里偷闲就写写自动化，现在是 UI 和接口的框架搭起来了，有时间就逐步优化，逐步往里面补充

为什么不稳定，找到原因，去解决它。领导也需要靠自动化出业绩，让领导承认做了几个季度的事情白费，是很难的。

起码得换了领导才能换的了，加入就行了，如果自动化问题多，你绩效也好写很多，有时也挺怕那种跑了一整年，但是没什么报错的自动化

那就自己合理排时间反馈，，做可以做 但是也有时间这些成本。。并且格局大点 你做的好把这些问题早点解决了 也说明你能力的体现

自动化确实是变成团队绩效性质的任务了，领导想推，下面的人不想做，我夹在中间两头为难。协商的结果就是再运行一个季度，尝试解决稳定性的问题，如果实在不行，就考虑放弃 (不知道领导是真的 ‘忍痛放弃’ 还是对我太失望....)。测试团队就两三个人，代码还都不行，平时就做做功能测试和接口自动化，用代码去做 ui 自动化之前也尝试过，技术能力根本不行。

我们的测试团队就 3 个人，代码能力都不行，在用第三方平台前尝试过写代码实现，发现能力不行，才找了第三方。

首先，从你的观点来看，其实你也偏向于放弃做这件事或者说抵触这件事。你应该先自我反思和总结一下落地到现在遇到的问题及阻碍。其次，让领导在周会上持续关注或者你持续汇报遇到的问题，来加强大家对此事的认可，认识到这并不是额外的工作，而是现有工作流程的加强和优化。最后，针对遇到的问题，重点突破，或者再来平台寻求帮助。说在最后，不是每一件事，都能有一个好结果，但是应该在推动过程中，去不断验证，踌躇不前和左右摇摆，只会导致半途而废！

——————个人拙见，仅供参考

我是领导的话肯定会问根因，到底为什么不稳定，每种不稳定因素占比多少，哪些做过优化，如果没有数据就不要随便喊不稳定。

那就把困难提给领导吧， 加能做自动化的人

1. 人力要用到高优的地方去，比如你们有特别高优的需求，这个需求做不完，公司就黄了！那么完全不用做什么自动化，核心人力都投入到高优需求去。
2. 领导有职责，就要找到当前阶段，团队最高优的几件事是什么。可能他能力有限，找到了这个，也可能你们团队很完备，剩下了这个，总之你领导认为这个是高优的事。
3. 你有能力，你发现了更高优的团队事情，你高瞻远瞩，可以私下跟领导聊聊，看看他是不是能转向，如果你的高优方案能让他上下都没有推进阻力，还有高绩效拿，那何乐而不为。
4. 你也不知道应该做啥，那么从本质上说，你们领导目前推进的自动化测试，是难而正确的事，要推进没啥问题。我赞成推进。这条是我最想说的，放弃谁都会，坚持才是最难的。
5. 你知道应该做啥，你伟光正，但是你领导真看不清楚，是个蠢材，那么建议划水，早日脱离苦海。

感觉你做的 UI 自动化，为什么要做 UI 自动化呢，本来就不稳定，人也少。三个人的项目，要做 UI 自动化，难上加难。

不要纠结于接口自动化还是 ui 自动化，真正在实现自动化场景的时候，ui 和接口都会用到，不用分的太清楚了，真正是为了尽可能代替手工来验证，降低风险的，觉得没有很大收益，从自动化用例设计上，自动化编写效率上去思考

必然是接口自动化

同样的问题，我们也是用了第三方公司的自动化测试工具，基于像素识别的那种，相关人员调研的不充分就强推，勉强用了 1 年，后面跟领导说实在用不了了，维护脚本成本太高，出问题还得协调第三方解决，自己完全解决不了 (第三方工具封装了很多层 API)，最后改用代码写了，同样有维护成本，这个自动化测试都避免不了，但代码写的起码自己能解决，省略沟通成本