作为测试经理，测试进度管理是测试管理的重要组成部分，贯穿产品需求到产品发布整个测试活动。测试活动按阶段拆分为：测试需求分析、编写测试策略和测试计划，测试方案和测试用例设计，测试用例执行，测试发布。编写测试策略和测试计划、测试发布评估通常都是测试经理负责，测试方案和测试设计、用例执行是测试人员主体活动。因此，本文主要针对测试方案和测试设计、用例执行的测试进度管理阐述个人观点。
测试进度管理的目的就是按照当前团队测试人力、环境、工具等资源条件下，按照产品质量目标在版本发布时间内完成交付既定的版本需求。也就是说测试范围、发布时间、保证版本质量、人力投入、环境资源投入等前提下，管理好测试进度。保证版本保质高效完成，不出现测试原因导致版本发布延迟。根据个人经验认为，做好测试进度管理可以有以下几个方面：
1、精确评估版本工作量，划分需求优先级。
2、提前协调测试相关资源
3、多层布点，层层可控。
4、按照用例优先级执行用例。
5、版本测试进度日报。
6、测试范围变更管理
精确评估版本工作量
根据基线后的版本交付范围，利用WBS分解方法尽可能将需求分解，粒度在能力范围内越小越好。粒度越小，意味着工作量评估越准确。这里重点说明几点：1、随着测试活动的深入，对需求的了解会越来越全面，工作量评估会更准确，需要实时刷新工作量。如果工作量明显超过前期估值，需要及时与项目经理沟通，给PM留有充分的时间与客户沟通。然后调整测试分工和计划。2、除了显性的交付需求，需要注意隐性条件的输入，就是需要充分考虑现网的组网、业务特点、特殊业务测试等内容，评估时需要一并考虑，不能遗漏。
协调测试资源
在版本计划排定后需要开始协调测试资源，包括人力资源、环境资源、工具license等等，最晚需在版本转测试前协调到位。不能在版本转测试后才开始协调，特别是一些项目组间公用的资源。如果资源不到位，会严重影响测试进度执行甚至影响版本发布。
按照用例优先级执行用例
坚持贯彻按照用例优先级顺序执行，优先测试风险较高的用例。影响用例优先级的判定因素包括资源依赖、特性开发人员水平、需求复杂度等。优先执行风险高的用例，可以提前暴露风险，如果发现缺陷级别高的bug也可以留给开发充分的时间分析和解决。这一点其实在落实的时候会有偏差，原因是大部分人都有趋利的习惯。习惯捡软柿子捏，把困难留在最后，这样就以为着把问题和风险遗留到了最后。所以在进度管理时要特别注意。
多层布点，层层可控
多层布点的策略就是将单任务再进一步拆分，精细化管理每一个控制点，每个控制点可控通常目标达成就可控。举个简单的例子，假设完成版本升级任务需要3天工作量，拆解升级任务为：搭建基础环境（0.5人天） --> 执行基本用例（0.3人天） --> 升级目标环境（0.2人天） -->跑基本用例（0.3人天） --> 回退环境（0.2人天）--> 跑基础用例（0.3人天） --> 测试报告（0.2人天）。这样在每一个节点设置控制点跟踪进度，就可以有效保证测试进度的管理。
版本测试进度日报
版本测试日报是让测试进度透明管理的有效办法。通过每日发送测试日报给版本相关干系人，包括项目经理、开发、测试人员。可以让领导、测试人员实时清楚版本进展、版本风险等内容，尤其是特别紧急的测试任务，日报就更有必要了。对于日报的格式、需要呈现的内容各个项目组都会有不同的情况，依据产品特点、测试周期、项目组情况设计测试日报，但至少应该包括版本总体进展、测试风险、问题发现等内容。
测试范围变更管理
用户的需求唯一不变的就是变化。不仅仅是需求，还包括测试人员请假、环境资源异常、版本间测试优先级的调整等等。因此，测试管理人员要做的是积极应对这些变化、调整测试策略和测试计划并知会相关测试人员。如果有风险，及时沟通解决。
总结
测试进度管理是每个测试管理人员都在面对的问题，影响测试进度的因素很多。我们要做的就是主动识别影响进度的因素、积极寻找解决办法，能力或者职位范围内解决不了的问题就及时提出，将风险上升处理，给出自己认为能解决问题的几种方法。因为有可能在你眼里很棘手的问题在上一层领导手里轻易就可以解决，视角不同、决策权不同。另外，如果时间计划范围内无法完成工作或者无法保证测试质量，也不用担心延期。版本测试永远都是质量第一，效率第二。