风险分析：如果开发提交的测试版本，执行BVT测试未通过，则版本必须打回重新提交，这样可能造成计划进度延误，影响后续的测试工作安排。

　　规避方法：在提交测试版本前，开发应该抽出时间进行自测，如果没有进行单元测试和集成测试，则需要安排进行。如果到期提交的版本被测试打回，为了不影响整体计划的进度，需要开发人员适当安排增加人手或者加班。

　　2、开发进度延误

　　风险分析：如果开发到版本发布时不能按时发布测试版本，则造成后续测试工作的安排顺延，从而行程测试计划执行的风险。

　　规避方法：请开发组在项目进行过程中严格控制进度，如果有推迟的风险请立即通知测试人员，协商解决。如果到期仍然不能按时发布，则测试人员需要申请修改测试计划，并通知所有相关人员。如果版本发布时间不能修改，则测试人员需要申请加班，并通知主管领导。

　　3、难以修复的缺陷造成测试用例阻碍

　　风险分析：如果测试执行过程中，被测试版本发现难以修复的bug，造成被测试模块的功能阻碍无法执行测试，测试进度安排受到影响。

　　规避方法：出现这样的问题，需要开发人员全力配合测试，及时修改出现的问题。如果不能完全修复，也要给测试提供可以测试被阻碍模块的接口。

　　4、未修改缺陷过多导致测试不能结束

　　风险分析：在测试将要结束的时候，如果当前版本的现存缺陷过多，被测试版本的各个指标无法达到测试停止标准，那么测试不能结束，将会影响后续版本上线的进度。

　　规避方法：测试在执行过程中，需要不断的监控被测试项目的现存缺陷情况，如果发现缺陷数量保持一定数量或者不断上升，则需要立即和项目开发组以及领导进行沟通，共同处理。如果将近测试版本发布日期仍然不能有所改善，则需要申请版本延期发布。

　　5、需求的多次变更

　　风险分析：在开发过程中需求多次变更，造成开发进度延迟，测试设计依据发生变更，影响后续的测试以及上线计划。

　　规避方法：在设计期间，执行内部二次审核以及项目立项评审，尽量在设计初期完善需求。如果仍不可避免需求的变更，则需要申请版本延期发布。

　　6、测试过程中发现设计Bug和需求Bug

　　7、人员流失