关于测试时间的话题，一直在讨论、一直在解答，却一直有人存在疑惑和不解；

在老徐的文章底部，或者个人微信PYQ，一些比较高频的留言，

如：

1)开发一个月、测试一周；

2)开发一周，测试3天 ；

3)开发一周，测试1天；

4)项目周期三个月，开发一个月，测试1天 ；

5)开发一周，测试周期1小时；

6)开发3天，测试周期0小时(未测试，直接上线)；

7)当天突然知道一个需求，当天就需要你测试，当天上线 ；

8)需求都不知道，让你估算测试时间 ；

...  等等，太多这种奇葩的问题 。

从底层逻辑来说，肯定是项目流程有问题，或者项目经理，关键节点把控的问题；

但，从做事的逻辑，从不背锅的逻辑，从线上质量的逻辑来聊；

如上，种种情况，都可以用一个套路来解决；

记得之前老徐写的文章否 ？

我是IDO老徐

，作为过来人，给大家几个参考思路 ：

1、严格来说，一定是从需求阶段，或者立项阶段，就参与到项目，根据最终的需求、开发排期，是估算合理的测试时间(测试时间估算，见文章：“测试时间估算”的现状 及 4点建议 )

2、如果测试时间，已经被其他人定死了，根本不给你时间估算的机会，那么就参考文章 ：项目周期已定死，重点把握哪些，保证按期上线？

3、常规来看，3天的测试预留时间，或者1周的预留时间，一定会被开发压缩的(即：在你的测试周期里，还会存在一些开发并行工作)，先做冒烟测试，开发阶段就多关注代码实现逻辑、接口情况、测试数据准备、环境准备，可以提前做很多事(别告诉我，说你并行多个项目，没时间提前准备)；

4、对于当天收到需求、当天测试、当天上线的，形成习惯，先用脑图梳理可能的测试点，给相关人(产品、开发、项目经理)确认你的点，是否有遗漏，测试报告，附上你的测试点、以及可能性的风险、结论，避免背锅；

5、少抱怨时间不够、多去想想如何更高效的解决问题、以及避免产生当前现状 ；

就算开发一个月、给你同样安排一个月的测试时间，上线后依然一堆Bug(你交付的系统、上线后、存在线上Bug，不是时间不够，本质是能力不够)；

6、当时间确实不够，系统会线上问题的容忍度又非常低的情况下，测试报告明确注明风险+结论(不同意上线)，且邮件发出来；最终，还是要一意孤行，锅，团队一起背 ；

7、确实很多非核心系统、内部系统、纯底层代码逻辑的底层框架，完全不需要测试，直接跳过测试、上线也是可以的(如果能做到 单元测试、代码检查、线上监控)；

参考文章：软件测试从业者终极目标，线上零BUG如何实现 ？，很多同学觉得做不到，很难 ？也许没去试过 ；