关于「测试时间/测试周期」7 点参考
关于测试时间的话题，一直在讨论、一直在解答，却一直有人存在疑惑和不解；
在老徐的文章底部，或者个人微信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如何实现 ？，很多同学觉得做不到，很难 ？也许没去试过 ；