【项目排期】测试排期问题思考

测试时间：不成文的原则“开发砍半”

这只是行业中对于测试排期的泛泛估计，具体情况还要具体分析，也有测试时间会远远大于开发时间的情况

项目前

需求评审已过，交互已明确，开发已完成技术调研，就可以输出各个环节的排期了

测试排期和开发排期是相互依赖的，测试排期依赖开发的实现逻辑和开发量，在某些项目中开发需要测试提前补充功能场景来确认实现逻辑

 具体排期输出时间：

开发测试可以一起评估给出整体项目时间

开发模块排期提出后，测试依据开发提测模块排期

开发最好以功能维度提测，开发测试并行进行，缩短项目时间

 

项目周期，开发整体周期，单个开发人员开发时长，2D/人！=两个人1D/人

用例设计，评审（逻辑整理）应该在提测前完成(最好在开发联调过程中)，不延长项目周期

测试时间=功能测试时间（bug整理时间）+相关功能测试时间……同步产品功能时间+数据校验时间+bug验证时间+功能回归时间……产品验证时间……功能调整时间+整体功能回归时间（现在预上线验证不正常）+上线准备……执行上线……线上验证

线上跟进（数据，功能观察，反馈跟进）

排期要留有冗余时间：
提测前：

项目周期较长（开发超过3天，个人观点（经验之谈）：开发测试都应该0.5天冗余）
单个开发周期超过3天，中间插入0.5小时左右沟通会（相关开发，测试加入）
单个开发周期超过5天，建议任务拆分，插入两次沟通会
涉及跨部门联调（开发启动前应该确认双方信息同步，数据，接口已沟通并落地确认，最好有文档记录），测试也要提前沟通
用例评审应该安排在开发提测前，最好0.5或1天前，方便产品，开发自我校验，提高测试质量，统一功能理解，并强调关注点
提供准入用例，准备测试环境（测试使用的环境），知悉执行的数据脚本，功能所需配置

需求改动：调整测试范围，重新考虑排期，梳理整体功能，补充用例
阻碍问题：环境，bug，再次梳理功能，可以回顾已测试功能，调整测试计划，争取不影响整体排期