测试排期问题：
时间：不成文的原则“开发砍半”
具体情况：项目周期，开发整体周期，单个开发人员开发时长，2D/人！=两个人1D/人
用例设计，评审（逻辑整理）应该在提测前完成(最好在开发联调过程中)，不延长项目周期
测试时间=功能测试时间（bug整理时间）+相关功能测试时间……同步产品功能时间+数据校验时间+bug验证时间+功能回归时间……产品验证时间……功能调整时间+整体功能回归时间（现在预上线验证不正常）+上线准备……执行上线……线上验证
线上跟进（数据，功能观察，反馈跟进）
排期要留有冗余时间：
提测前：项目周期较长（开发超过3天，个人观点（经验之谈）：开发测试都应该0.5天冗余）
单个开发周期超过3天，中间插入0.5小时左右沟通会（相关开发，测试加入）
单个开发周期超过5天，建议任务拆分，插入两次沟通会
涉及跨部门联调（开发启动前应该确认双方信息同步，数据，接口已沟通并落地确认，最好有文档记录），测试也要提前沟通
用例评审应该安排在开发提测前，最好0.5或1天前，方便产品，开发自我校验，提高测试质量，统一功能理解，并强调关注点
提供准入用例，准备测试环境（测试使用的环境），知悉执行的数据脚本，功能所需配置
测试中：高级bug，问题反复的及时与开发沟通，明确信息一致性
需求问题，及时产品，开发一起沟通
没有阻碍bug，但bug数量较多，及时整体问题，与开发一起梳理问题，有顺序，有条理解决，并确定问题解决的deadline
及时跟进bug状态，开发解决后及时回归
（1.验证后有问题方便开发再次跟进；
2.测试中验证bug，继续测试可以作为bug回归，节省时间；
3.避免bug积累，大量bug验证容易遗漏回归点；
4.将bug验证放在功能回归中，容易遗漏测试点，整体回归应该在稳定环境(没有问题，代码不在改动)执行）
需求改动：调整测试范围，重新考虑排期，梳理整体功能，补充用例
阻碍问题：环境，bug，再次梳理功能，可以回顾已测试功能，调整测试计划，争取不影响整体排期