问题很简单，先说背景。我所在的业务线特点是业务复杂，耦合度高，经常是一个功能改一点，要测试覆盖一大片，所以我的测试范围一直都很大。现在产品着急出功能，就一直嫌弃测试效率低和进度慢。
所以我的问题是求改善或解决现状的方案或办法。
我目前在做的和打算实施的如下：
1、环境容器化，奔着 DEVOPS 去努力
2、和开发确认测试范围，但是结果经常不可靠（因为开发不熟悉业务）
3、开发宣讲（开发一直不太愿意配合）
4、主流程的接口自动化和 UI 自动化（UI 自动化投入产出比太低）
求各位大佬多提宝贵意见，救人于水火之中，跪谢！
我觉得啊
测试就是一个取舍的问题
如果是大公司可以招一大批测试进行覆盖
小公司就要考虑取舍了，主要精力放在 核心业务 付费 公司主流程，影响较大的模块
有些非核心业务，用户用的少且不重要的业务，并非每一次有可能受到影响而都要细致回归。
还有分工的问题，分工明确，不要一个业务很多人覆盖，节省人力
ui 自动化，同样要有取舍，一大堆人讲究封装 优化，说的难听点，小公司即使搞 ui 自动化，也很难有时间做这个，能快速结果导向，把业务有最短的时间自动化起来就不错了，
ui 自动化做好选型，哪个最适合你们，最节省时间用哪个，因为你即使封装的再好，应对频繁的改动，能提升的效率还是有限的。主要精力放在选型以及哪些业务需要自动化上，抓重点，
1 业务是设计到整个公司的，测试没有理由也不需要为整个技术的失败背锅。
2 要想从根本解决这个问题，需求，开发，测试，运维全部都要配合，这从来就不是一个部门的事情。
3 只从测试层面解决不了根本问题，只能说部分解决:从业务点着手，那个业务最需要改进，从小处着手，从最迫切需要解决的着手,一点点的改动，改动多了就是大的改动.不要追求大而全，那是绝对不可能做到的。
4 如何做到提高效率，那就看需要改什么: 需求的分析、用例的编写和评审、用例的执行方法、提高测试用例的执行效率、多种手段多种方法提高测试的覆盖率等等，都是可改进的点
做好自动化测试就行。
做自动化和做好自动化是两码事。
听楼主说的背景，这公司里测试就是个背锅的，开发不懂业务，坑是一定的，与其提升测试效率，还不如抓源头，bug 是谁生产的，明确责任分工才能往下谈，不然你就等着炸雷吧