测试没话语权，不重视质量的团队就这样。解决这个需要从上到下的共识和制度的支持。

以下做法供参考：

1. 设置准入标准，未达标不进行测试。——这个常年因为产品进度压力妥协
2. 尽早介入，每个环节介入——这个可能因为任务堆积被迫放弃，形成恶性循环
3. 测试驱动开发，结对编程——没基础和一些基本条件不建议搞
4. 要求开发自测——这个需要研发支持
5. 尽可能小的分解任务，每个研发周期控制在 1-2 周。——这个还是可以做的，解决研发周期过长的问题

至于压测试时间，一方面可以从自身效率解决问题（工具等，没资源不建议大规模做自动化测试），一方面可以把计划做好，提测结点约定好，压了多少时间，每次回顾会做到有据可查，时间成本很影响质量的。

你说的这些，其实都有在施行，但是效果不显著，不知道还有没有其他的方案呢？这种情况下，有没有必要将绩效做一个绑定？从利益的角度进行约束，但这种约束一定程度上也会造成研发的消极对待。

感觉小道消息可以侃一期这个话题~

问几个问题：
1、最终质量上，有因为时间被压缩导致的线上故障什么吗？——如果有，可以借这个对上级多说下，原因是因为时间被压缩太厉害
2、研发周期长，是指经常超时提测吗？超时率多高？——这个看是否有项管或者这类管理项目进度的角色，没有就相当于你和研发的上级在关注，可以向这些干系人多反映下。

这个情况我理解核心就是 1 楼说的，从上而下不重视质量这个观念是根本。多给上级和研发同级吹吹风，先思想上获得支持；然后是制度上，提测超时率（非需求变更引起）、提测打回率（提测后冒烟都跑不通的）统计一下，作为开发转正标准或者绩效的一部分，落到实处。

还有一个点，看研发团队里是否有一些比较有追求的人，自己会把控好自己工作的质量，这部分人可以多表扬，让大家多看到，让他们能发挥更大的影响力。

因为现在是理念上的差异，要改变要做好周期长、部分人消极应对、离职甚至反对的情况。所以得先和你的上级达成一致，才好继续往后推行。

这是个长期的、持续的过程，很难立竿见影。
观念不一致，没有质量共建的共识，绩效弄不好会起到反效果，搞得怨声载道，质量也没提高。

根据我个人的经验，绩效这个东西，很多就是瞎拍脑袋弄的，如果不持续优化改进，短时间起反效果的居多，如果实在要搞，指标尽量是间接指标（比如恒捷提到的提测超时率、提测打回率、压缩时间占比、压缩后线上缺陷遗留增长情况等），同时尽量以激励为主，如果出现线上缺陷，开发测试共同担责（这一点是质量共建的基础）。不过还是那句话，大家认为质量不重要，随便怎么搞，都没多大效果的。

另外，有时候确实是客观原因（实力不够、环境影响、没资源、人员流动）导致的，进度目标设置的时候，是不是合理呢？

已数据为武器，通过问题推动。
1、如果发现开发质量不达标，要记录测试、开发以及其他相关人员在提测反复消耗的时间。如果有做的好的团队和需求进行对比记录效果更好。积累一定数据后，在合适场合进行推动，比如有决策人员参加的回顾总结会议，开工会议风险沟通等;
2、通过线上问题、客户反馈的问题，通常领导比较重视的时候，拿出提测不达标或者提测不充分的数据进行推动，很多时候线上问题回溯也是推动团队改进的重要场景。

要求开发自测！主流程自测不然提测就打回，也是浪费时间

我们现在的方法是有自测用例，范围是正向业务流程，且通过开发及产品评审
每轮迭代自测用例 100% 通过的才接受提测
自测通过的用例被测试按同样的步骤、数据执行时发现有 bug 则打回该轮提测申请，要求开发修复后重新自测
定期统计测试打回次数

道理都懂 ，但 时间就是不允许 ，开发没搞完，只能延期提测 ； 但，发版时间，又提前确定了 。

测试的做法（建议）：客观出测试报告，注明风险（时间不够，测试没充分），以及已知 Bug ，别背锅就行
有问题，团队一起背 。