这是《落叶》文集里第 266 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
老师，我发现每次测试的时候，都很慢，别人问进度做到什么程度，总是没法很好回答，总觉得还有很多东西没有测到，然后会陷入无尽的细节之中，有些没测全，又有些测得太细。
【你问】
总是不清楚自己的测试进度，怎么办？
【我答】
这是很多人在做项目时的一个常见问题，每天下班前同步项目进度的时候，总会有几个人很难说出自己当前的进度，有人会说不知道怎么算，有人会说不知道自己到底测了哪些。
我先站在项目经理的角度简单说下这个进度的要求，其实它就是一个概数，并不需要你给我一个很精确的数值，只需要你基于你在这个项目里所有的任务的一个体量，和你截止到当下已经完成的一个体量的百分比。
我要这个干吗呢？就是为了用你给的实际完成百分比，去和理论上截止到当下你应该完成的一个百分比作比对，以此来判断你的进度是正常还是不正常。
其实要求并不高，对吧？
再说下，其实有些公司的测试人员其实并不需要每天或定期汇报测试进度。为什么呢？因为他们的测试任务都是细化到用例级别的，每个项目要执行几轮 Test Run，每轮 Run 有多少条 Test Case，每个人分配到的执行任务其实就是每个人要执行多少条 Test Case，而且都是有用例管理系统去管理和执行的，所以只要测试人员每天及时地更新用例执行状态，那进度在系统里就是一目了然的，项目管理人员可以从系统里直接查看总的 Test Run 的进度，每个人的进度，简单吧。
之所以也有很多同学面临本文的这个问题，大多都是因为没有上述那么细的用例管理和执行，任务的颗粒度基本也就是在测试模块或测试点这个粗细程度，所以在设计和计划阶段，对于任务就不是很好量化，于是在执行阶段就很难去量化进度。
所以想要解决这个问题，需要从根源上入手，但并不是说都要做到上述那种很规范、很细致的流程模式，还有相应的系统支撑。而是说在你对自己的测试任务做设计时，就要做到相对细化，当你拿到某个某块或功能的测试任务时，也许你的领导并没有要求你必须写测试用例或梳理测试点，只是让你完成就行。但你自己需要根据你的可用时间，去尽可能地细化你的设计，最低标准也需要梳理出来所有的测试点。
这么做有什么好处呢？
第一、你根据梳理出来的测试点的数量和单测试点的规模，就可以较为精确的估算出你测试执行的工作量，这在测试计划阶段是比较重要的，特别是测试时间经常被压缩的项目环境；
第二、你可以将梳理出来的测试点设定不同的优先级，这样你在执行阶段就可以根据实际可用时间，来制订你的执行策略了，从高优先级到低优先级，有条不紊地进行测试；
第三、参照第一个好处，你在执行阶段，根据总的测试点数，和你当下已完成的测试点数，你是不是很容易就能计算出你当下的测试进度了？
第四、有了测试点作为测试策略的依据，你也可以避免在优先级不高的测试点上做过度的纠缠，而应该把时间和精力都花在高优先级的测试点上；
第五、当你的测试时间被各种外界原因压缩时，你也可以有策略、有目的性的放弃低优先级测试点的测试；
《测试路上你问我答》里的 Q&A 79，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
