国庆休假的时光匆匆而去，想必对今年中秋四连和国庆七连的假期排期很熟悉了，今天跟大家分享下测试世界里如何制定测试排期。
测试排期是项目排期里面的一部分，所以了解项目排期对整体产品的全貌会有一个宏观的认知，甘特图能很好的体现项目排期，里面包含了参与角色和每个角色对应的排期。项目参与者和项目责任人都可以清晰的看到项目当前进展和项目耗时等。
甘特图可以很好从宏观上把控项目进度，可以查看阶段性任务的排期，也可以随着时间轴移动查看当前时间点处于哪个阶段。从产品立项到上线，测试排期处于整体项目排期的末端，这个很好理解，项目生产正式运行之前的阶段都是测试交付验收阶段。因为处于最后一个任务阶段，如果设定的测试排期过长会造成项目延期，但是排期太短又会导致无法最大范围有效把控质量。所以如何制定一个合理的测试排期是需要一定技巧的。
网上搜索测试排期的制定（仅限互联网软件测试），很多采取了研发排期一半原则，即研发总时长的一半。跟有经验的一些小伙伴通过沟通交流，大概归纳了一个测试排期的经验：测试时长=研发总时长*[30%-50%]，测试时长=所有测试任务总时长。很多小伙伴会疑问，有的项目开发时间很短，但是测试周期很长的情况很多，别急，后面会讲到。
测试排期制定参考2个原则，一个主要原则和一个次要原则。
主要原则之要素一:项目类型
首先根据需求发起方来判断，通过了解本次项目类型，可以最大程度避免排期严重偏离导致测试任务完不成。项目类型包含技术项目和产品项目，技术项目的需求方发起人通常是研发，产品项目的发起方几乎是产品经理。因为技术项目和产品项目的排期原则是不一样的。
技术项目不能按照研发排期的百分比来衡量，很多技术项目的测试排期可能超过研发排期。
比如统一种代码语言，迁移不同框架。研发只要改动入口、日志等，大部分平移方法函数等，所以较少的代码行数变动会给测试带来一种错觉:研发天数好短，那么测试排期也可以很短。其实很多接口测试、功能回归 会带来很长的排期。这种排期需要拆分接口数和罗列具体回归的核心功能点叠加计算测试排期。
再比如不同语言的代码迁移，研发需要从一种语言翻译编写成另一种语言，这会花费较多的研发时长，测试排期除了需要按照提测里面迁移的接口数、功能点来评估，通常需要额外花时间在性能和安全等方面做工作。
虽然产品项目的排期可以参考上面的通用经验，但是对于回归量大于新增量的测试工作，通常测试排期要翻倍。
对于一个完全新的产品1.0版本，我们不需要考虑回归，因为这个就是初版。但是我们测试的项目通常都是不断迭代优化的产品，所以测试产品=新增测试 原有功能测试。回归测试的测试时长判定，需要研发测试共同评估对现有产品带来了哪些影响，对核心功能还是次要功能。如果新增功能是在核心功能上，通常需要增加功能测试时长，具体分析需要罗列回归核心点。
如果是一个完全新的产品1.0，我们仍旧需要考虑众测、用户体验、兼容性、稳定性、美观等方面，根据产品特点重点增加相应的测试时长。
主要原则之要素二:研发人员
很多人会问测试排期为啥要看研发人员呢，这里面看的是研发人数、依赖。
研发总时长就是所有参与项目每个人的研发时长总和。研发如果多个人，通常意味这会有任务紧急拆分、研发联调的情况。联调意味着存在上下游关系。通常反馈到测试任务里面，我们可能需要有测试依赖和测试联调。测试该项目存在依赖，如果是一个系统级的项目，需要进行联调测试。所以测试不仅仅包含模块内的自测，以及系统间的联调测试。
主要原则之要素三:BUG回归
测试是一个通过测试验证并发现解决问题的过程，参与者不仅仅是测试人员，问题的解决需要研发来解决。除了正常测试时长分配，需要额外划出推动解决并回归验证bug的时间，该过程包括复现、提交bug，协同研发解决，回归验收等。bug发现越早越好，临近上线前发现bug数目较多，意味着上线后存在bug的几率较高。
次要原则之要素一:人为因素
研发和测试是否对业务足够熟悉，如果是研发是新人对业务不熟悉，需要从研发新人角度再补充测试用例，扩大测试用例范围来保证质量。如果测试是新人对业务不熟悉，设计的测试用例是不全的，需要进行用例评审来补充用例，并且测试时长根据测试的经验上手程度来判断是否需要额外增加。
哪怕研发对业务足够熟悉，但是不同的研发人员提测质量是有一定的区别的。通过一段时间的磨合，可以发现研发的开发习惯，哪些容易在需求理解上出偏差，哪些容易漏需求，哪些自测不充分，哪些编码习惯不好，哪些质量很高。提测质量不高的需求，测试时长通常要延长，因为要推动解决bug数是较多的，耗时也不少。
如果是研发人数较多且涉及多个跨部门，通过较长的研发直接的联调时长可以得到一个结论，该项目测试联调时长通常会更久，我们必须要提前明确更清晰的测试依赖和联调顺序，从而有利于制定最终的测试排期。
次要原则之要素二:项目因素
如果项目是倒排项目，（倒排意味着上线时间已经定了），这里注意，不可随意压缩测试时长，可以通过增加测试人力或者保核心功能上线等手段来解决。
如果架构复杂，数据链路长，我们要及时评估测试数据构造、测试环境搭建等前置测试时长。
通常项目高峰期，测试同学会出现并行测试的情况，所以测试排期的需要看项目并行情况。如果该项目明确后续要并行测试，适当增加测试buffer来预防并行测试遇到的未知风险。
