项目经历说要看测试，意思是问测试同不同意上线吧？

不用怼，拿数据说话，明白人都会懂。bug，轮数，过程分析

不是先产品功能验证通过才给提测吗

扔数据给 PM，PM 不作为就扔给 CTO

直接给他们 cto，或者研发经理看数据啊：看看你们还有这么多 bug 没有改完
千万别和小兵怼，没啥实际用处，你也管不了他们。给他们领导说，让他们领导管他们

现身说法。。。

测试完后，出具测试报告就可以了
明确说明产品功能 BUG 太多，准入无法通过，暂不具备上线条件
项目经理如果非要上线，让他找 CTO 报备就好了，你的结论就是不能上线就 OK 了 说多了没用

据说之前网易有这么个事情（记得好像是那样），有个项目组的人总是到版本日才把单子拖完成，测试才去测，弄得测试每次到版本日都要加班到很晚，之后他们的测试主管什么都不说，只是做统计，把项目组里每个人每个单子所用的时间都做了统计，从那统计里可以一眼得看出哪个人都是最后拖完成，哪个人影响了效率，之后报告给了上头，最后上头下令整改

如果实在要上，把风险说清楚，让产品决定

第一步，先把开发裤子脱了。。。。然后。。。。

这种开发，怼他根本没用的。就是不负责任，而且没有质量意识的。要是我，在打回版本的时候就把问题和风险以及量化的数据反映给项目经理或 cto，让管理层都知道这个风险，把问题抛给项目经理去解决。还有，反映问题还是要做到对事不对人！

有必要装孙子吗，求着改 bug。

这种事情就要勇于承担责任 不要怂 直接怼 开发质量不好 BUG 多 这本身就是 对应开发的问题 作为测试我们不是只是质量的检查者 质量真正的保证者还是开发 这种开发 讲真开了就好 我们要有原则 对方提交晚 这就是他的责任我们逾期或者加班好了 不过这种事情你只要忍了一次以后就要继续忍着 你要确定你要忍着？

本是同根生，相煎何太急，你只需提出问题、确认问题，改不改是开发的事，做好自己的事情。

每次测环境提测冒烟必定不通过，开发联调环境在本地而不是测试环境，开发表示从来不看 bug 管理工具上提的 bug。。。。要被气死了。特别理解楼主！测试时间被占用做联调。。。

开发不行 自己改

我是这么做的：
1、让测试经理、研发经理、项目经理商量好，所有的 BUG 要在 jira 系统回复，就算不予解决也要备注原因
2、写了个 python 脚本，每天下班前 1 小时，统计 jira 系统中在研项目的研发人员名下未解决的 BUG 数据，按项目分组发送邮件给项目经理，抄送对应项目组内研发人员，由项目经理跟进进度，测试人员不催，不怼
3、脚本还实现了汇总所有在研项目的 BUG 数据，邮件抄送公司几个大佬
4、测试人员只需要提 BUG，保持充分沟通就好，怼是解决不了问题的

楼主描述的这个开发，好像我一朋友

必须在冒烟测试阶段直接打回，每次冒烟不通过都邮件出来

一些看法供参考，欢迎讨论：
1.提前说明各方职责这是基本原则：PM 需要对项目发布时间点，以及顺利发布负责；QA 需要对项目质量负责。
1.1 如果 QA 也要对项目发布时间点负责的话，项目 KO 时间不变，发布时间不变，只会出现一种情况，那就是压缩测试时间，测试怎么办呢，加班支持，或者加班也完不成，就草草上线。但如果这样上线后出现问题，那背锅的肯定是测试了。
1.2 基本原则的情况下，在评估好测试自身工作量和可承受风险的情况下，发布延期未尝不可。
2.及时说明测试过程的各种风险：邮件、或者当面向上汇报都可以，因为测试除了保障质量外，另一个重要任务就是及时暴露风险，目的就是让大家不 suprise。
2.1 比如冒烟测试不通过，比如日报中说明 bug 太多，比如风险知会，这些关键的项目测试节点，建议都正式邮件知会项目相关方。别把压力暴露在最后，也别把压力抗在测试身上
3.打铁还需自身硬，让开发和其他项目组同学明白测试的质量保障到底在做什么，测试时间到底能不能被压缩，压缩后会有什么结果？
3.1 要有详细的测试计划，做什么事情，花多少时间，比如手工多少，自动化多少，其他。。。其实有些时候这也是测试心虚的事情，因为工作量不可量化，引来合作方质疑。所以一定要量化，一是自己明白时间花哪里了，二是其他人也能明白测试工作到底在做些什么。

最后，回到怼开发的问题上，我基于以上总结下。
项目过程用数据说话，No data No BB，对谁都适用。

默认是个匿名帖，重发一次，一些看法供参考，欢迎交流讨论：
1.提前说明各方职责这是基本原则：PM 需要对项目发布时间点，以及顺利发布负责；QA 需要对项目质量负责。
1.1 如果 QA 也要对项目发布时间点负责的话，项目 KO 时间不变，发布时间不变，只会出现一种情况，那就是压缩测试时间，测试怎么办呢，加班支持，或者加班也完不成，就草草上线。但如果这样上线后出现问题，那背锅的肯定是测试了。
1.2 基本原则的情况下，在评估好测试自身工作量和可承受风险的情况下，发布延期未尝不可。
2.及时说明测试过程的各种风险：邮件、或者当面向上汇报都可以，因为测试除了保障质量外，另一个重要任务就是及时暴露风险，目的就是让大家不 suprise。
2.1 比如冒烟测试不通过，比如日报中说明 bug 太多，比如风险知会，这些关键的项目测试节点，建议都正式邮件知会项目相关方。别把压力暴露在最后，也别把压力抗在测试身上
3.打铁还需自身硬，让开发和其他项目组同学明白测试的质量保障到底在做什么，测试时间到底能不能被压缩，压缩后会有什么结果？
3.1 要有详细的测试计划，做什么事情，花多少时间，比如手工多少，自动化多少，其他。。。其实有些时候这也是测试心虚的事情，因为工作量不可量化，引来合作方质疑。所以一定要量化，一是自己明白时间花哪里了，二是其他人也能明白测试工作到底在做些什么。

最后，回到怼开发的问题上，我基于以上总结下。
项目过程用数据说话，No data No BB，对谁都适用。

• 做好记录交给党
• 说明公司整体不成,包括开发水平和管理水平,反应出来就是自己水平也高不了哪去,加紧锻炼去好的公司,别指望个人能救一个国

你这个回复比较牛

这是项目进度把控的问题，如果提前规定的上线的 deadline，楼主要合理的把控测试的进度，尤其是质量差的情况，建议每天组织产品和开发以及相关 ld 对个进度，说明现在的情况，让大家周知一下问题卡在哪里（是开发而不是测试），说明一下由于 bug 太多已经影响了测试的进度，以及延期的风险，并且要发日报暴露问题，让相关的人员提前有个心理准备，知道问题在哪~到最后延期责任在谁一目了然啦~~