组织相关测试人员学习系统规格书，并组织安排测试用例的编写及评审，同时在系统的整个进行过程中注意督促测试人员对测试用例的维护、更新及评审，确保测试用例与系统规格及当前的系统实现的一致性以及测试用例的正确性。

　　根据目前项目特点，在SDV测试阶段、甚至包括版本发布前，都存在规格需求反复修改、增删、自相矛盾的可能性，如果动态的维护测试用例，保证测试用例的及时性、正确性和完整性，是测试负责人需要克服和解决的问题。

　　因为是内嵌文件《由需求形成测试用例》，很多人容易忽略其中的内容。在分解分配测试用例，测试用例编写的阶段，很容易出现一些问题，比如：测试人员为新手，对业务不熟悉，构建测试用例时间较长，但用例适用性不大对需求规格没有达成一致，测试用例细化后，修改起来比较痛苦需求规格的变更，导致测试用例跟随变化成本太大，无法维护。

　　4、任务的分解分配

　　在项目进入系统测试之前，项目测试负责人需根据项目规格书分解分配测试任务并制定WBS计划，在制定WBS计划时需考虑项目的整体计划及系统发布的时间点，以及测试执行人对系统的熟悉程度。

　　例如：一个功能如果交给一个对系统非常熟悉的人进行测试可能只需要一天而给一个对系统不是很熟悉的新人进行测试可能就需要两天。

　　在制定WBS计划时若发现在系统发布时间点无法及时完成所有功能的测试，则需对整个系统功能的优先级进行排序，并及时提出预警信息，同时与SE和LPMT确认版本测试的基调：是调整发布时间或增加测试人员还是要求测试覆盖度到某一阀值，或对一部分优先级较低的功能只进行基本测试。

　　而在测试时间充裕的情况下，则需充分考虑各项功能点的测试，特别是一些容易出问题或曾经出过问题的功能点需加强测试。

　　五、测试进度跟控

　　在项目的系统测试过程中，要及时了解测试进度，跟踪BUG提交、修复及验证情况以及系统的拷机情况。

　　★ 在开发初期阶段，测试组执行BBFV时，很多模块、功能点的开发完成进度和原计划会存在一定的偏差，就需要测试负责人动态的刷新WBS计划，根据实际的开发进度调整测试计划。

　　★ 在开发阶段，存在版本编译不出来导致无法测试，开发人员修复代码太随意导致版本稳定性反复，需求变更过大导致后端测试开发变更严重等现象，会导致测试工作无法正常进行。就需要测试负责人及时反馈出来，根据项目本身的特点进行对应的处理。

　　★ 当测试进度出现延期时，要及时确认问题原因，如果是问题协查导致，则需及时与研发人员进行沟通协商，看问题是否必须在测试环境进行排查，若为必现问题可与研发协商要求其在自己环境进行排查，若必须占用测试环境，则需及时调整测试计划，若因此可能影响版本的发布，则应及时与SE确认。

　　★ 若发现有较多BUG未解决，则应主动联系SE及研发人员召开BUG会确定问题的解决时间。若发现有较多BUG未验证，则应提醒项目组的测试人员及时进行验证，对于一些拷机或非必现的BUG，建议测试人员在此BUG上现做拷机标记，连续拷机一周未再复现的做关闭处理，若再次复现则继续进行排查。

　　★ 疑难问题的跟控：比较难复现的问题，怎么去尝试复现。比较难定位的问题，怎么驱动、反馈给SE，协调开发人员定位问题。比较难处理的问题，怎么跟控反馈进度等。

　　★ 每天下班前需确认拷机内容，每天上班第一件事需确认拷机结果，只有这样才能保证拷机的效果，实现拷机的真正意义。

　　实际上，作为一个项目测试负责人，这部分工作是最重要和核心工作。

　　很多测试的风险点，需要测试人员及时反馈出来，否则无法保证测试质量，也无法反馈产品真正的问题所在。同时，测试计划受到冲击太大的话，对测试计划和项目计划都是重大的风险，需要项目负责人及时反馈，以便解决问题，规避风险。比如：

　　★ 版本未编译通过

　　★ 版本不稳定

　　★ 版本反复崩溃，上周bug较少本周bug较多等

　　★ 开发人员占用测试环境时间太长，导致测试无法进行

　　★ 需求变更较大，测试执行无法保证