现状：
1.测试同事已经在用例平台上创建了比较稳定的接口，UI 的回归案例，但平时版本同事有时会运行回归用例，有时并不会，而且部门现在也没有相关 kpi 指标要求达到自动化率多少才达标。在平台根据版本自己触发回归案例执行这件事情上，最终敲定靠测试同事自主去筛选案例手动执行，所以自动触发案例执行走不通。
2.目前自动化案例库新增案例也变得很少，原因沟通过后是主要是如下几个原因，第一是新项目部分需求还未稳定，第二是功能复杂，需要花时间去分析是否可以写成案例，第三是测试同事要着重于手工验证，因本人分工与他们不同，所以我想帮他们写案例效率也不高。
求问：
我现在想让他们回归时多执行回归案例以及在新增案例，大家有没有好的解决方案，或者自己公司有已经落地且较成功的做法，可以分享的，非常感谢
每天晚上定时跑一把呢，闲着也是闲着
如果全量执行耗时不长，就自动触发全量执行好了。这个还是看项目责任心，要是怕 bug 泄露，还是会主动去执行自动化回归的。
没有自动化对你们现在的质量有影响吗, 有了后会有提高吗, 或者可以提高效率?
不要为自动化而自动化.
第一点，所谓的走不通我感觉还是懒吧，我们现在就是全量测试用例跑，由于业态原因某个业务线的 2700 多条测试用例一次跑完要 10 分钟。已经符合部门要求，如果想更快就是加机器加并发数，拆数据维度。所以你所谓的选取类似精准测试我觉得不是万级别甚至 10 万级别的测试用例，无所屌谓就是全量就是去研究什么写法能跑的更快。
第二点，测试分工一定会导致最终维护不下去，除非这个测试人员有前进的动力。针对低代码平台我知道的大多数是没有前进的动力的，因为除了自动化用例设计（可能他们也没意识到），技术无任何提升。这就导致了恶性循环，你让他们怎么有激情有动力去做这件事情，它没有收益只有成本，这就是人性。第二点只有制度改变或者像大厂以利诱惑强制要求你这么做。不然解决不了的，自发性自驱型的人永远是少数。
一般来说测试人员更希望自己测的产品稳定省去后面的不必要的麻烦，他们都不想执行的原因是什么？
吼猴
回复
目前自动化是做回归用，老板的意思还是有最好，但并没有 kpi 去要求同事去整，毕竟数据容易造假，但做这件事确实需要测试同事有很强的自驱力，没的话你追着他去搞，效率和质量永远是个问题
royzou
回复
你确定是做的回归用例？那跑起来就不会有大量报错，除非是用例自身的问题造成的误报。如果真是 bug，那就是效益，效益的话测试人员怎么会抵触？
每天自动化跑起来，出结果先不管，有人问再去看。如果不严重就排到后面去，如果严重就提高优先级。主要是怕有非提测的改动或者环境导致线上出现大面积异常
一日之纪
回复
之前执行过十几次，总结了下主要是这几个问题导致 1.用例不规范 2.测试环境重启，网络不稳定 3.测试数据问题，倒没听说测试反馈是接口或者业务逻辑问题，执行几次之后测试有时忘记了就不执行了，我评估下只能我这边全量自动去跑了，没有问题最好，如果是上述问题就要和测试讨论是否修改案例或者删除容易报错的案例了
royzou
回复
主要是投入和收益 (比如使用后线上 bug 率是否明显降低, 显著减少回归时间), 很多时候迭代一个一个接着来, 每个迭代改一堆东西, 历史的自动化就会有很多需要重新维护的. 如果又不给这块工作留出足够的时间, 那最后维护成本越来越高, 导致变成吃灰用例.
所以最终还是这个工具能带来多大的收益, 能不能提高大家的工作效率. 如果一个工具带来了额外的工作量, 解决的问题又少, 又不能带来个人能力上的成长, 然后又不安排额外的工时, 那么肯定是难以维持下去的.
最后自驱力也是要有收益 (无论是否滞后) 才行. 不然用这份精力学点别的不好嘛
好用肯定就用咯，没人用那就是不好用。