可以给开发设计转测卡点，转测前要求比如基本功能用例要能跑通且无其他阻塞性问题等，如果未达标为转测质量差导致要被打回，重新进行转测流程，最终上线时间也就跟着顺延了，如果不顺延比如让测试加班解决障碍也可以把压力给到项目经理或者你们的主管

1、列问题数据，给出预期数据和预期收益
2、找 +1 沟通寻求支持，和研发老板同步，再和一线开发同步指标
3、定期复盘。

测试帮忙写一些冒烟用例，走 jenkins 自动触发，冒烟过不了打回代码提交。

做项目复盘，搞 bug review，拉着研发经理对每个 bug 做代码 review，这一套下来是驴子是马都能现形

跟开发老大沟通，增加一个冒烟流程，让我们测试小伙伴多花几分钟写一份 P0 的 case，让开发提测之前自己跑 P0，P0 执行全部通过才算提测。

写用例的时候，给开发列出冒烟用例，让他自己测，通过了再提测

上面都已经说的差不多了，实际效果最好的还是得联合研发部制定开发绩效奖惩制度，BUG 少的并且提测准时的开发，年终奖多发一个月，你看质量、提测时效绝对蹭蹭上涨，没有奖惩制度，推啥措施都没用，开发都是本着事情能少就少来工作的，这个是人之天性，除非给真实的大饼。

一个页面七八个 BUG，得分情况，如果很简单的页面说明开发质量差，如果页面字段多，交互逻辑复杂，十个以上也算正常吧。
以前公司经营正常，测试还给开发弄自测用例；现在走下坡路，这些都是虚的，能按时提测就不错了，要求不了多高的质量

你有多大权利才能办多大事。