需求及项目测试过程中合作上遇到哪些问题，导致测试效率低下
产品侧：
1. 需求排期完毕后，产品临时加需求
2. 需求排期完毕后，临时改方案
3. 需求排期完毕后，产品需求范围评估不准确临时增加回归量
4. 需求测试完毕准备上线，产品放弃需求了
5. 需要多方共同上线的需求，单侧封板等待上线期间出现需求变更
6. 临时所谓“紧急”需求插入，影响正常的排期；
以上行为导致浪费研发和测试资源
解决方案：测试人员提升自己对业务的理解能力及对研发架构的熟悉度，在需求评估、设计评审中对产品需求进行查漏补缺，当产品需求不合理时，拒绝需求；需求封板后待上线期间出现需求变更后由产品侧提出变更优化需求，进行二次排期；紧急需求插入时，评估其紧急度，抄送领导同意后，沟通上下游，进行排期调整，可定期统计紧急需求的个数，对产品侧能力进行逆向评估。
测试侧
1. 本侧无修改，上下游联调未排期，临时需要支持联调，影响正常测试的内容进度；
2. 环境不稳定或数据需要外部协助，影响测试进度；
解决方案：需要在日常工作中增加联调支持的工期排期；
研发侧
1. 不及时更新Jira状态，影响及时回归
2. 提测后才告诉有新的改造或者合并了其他需求，需要重新评估影响范围，增加测试工作量；
3. 给了排期时间又临时调整，影响测试原有排期
4. 预发环境频繁发布，发布不同步测试，影响测试进度
5. 同一时间排期改动相同的应用，导致开发和测试阶段都相互干扰，需要合并分支，开发需要频繁合代码，测试增加回归量
解决方案：定时发送JIRA统计邮件，设定日清规则，指定回归时间；各个需求间独立分支，合并上线时预留合并测试时间，除紧急BUG修复外禁止临时增加提测内容；预发布环境划归测试管理；同一时间多个需求测试走test分支部署，考虑用自动化用例覆盖部分回归工作。