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