分析需求，写用例，执行用例，回归测试，上线测试，这些是一个测试新人日常要完成的工作。随着时间发展，当我们对测试流程越来越熟悉，从新人变成了老人，有越来越多的任务会交到我们手上，当领导需要我们独立完成甚至带领新人完成某个版本的测试时，我们需要做的就不仅仅是写用例了。
作为一个合格的leader，我们需要制定测试计划，把握整体的测试进度。按时间顺序来说，我们需要完成以下事情。
一、分析需求，制定测试策略
这个时候分析需求不是为了写测试用例，而是大概了解需求的难度，以便制定测试计划，这个计划中需要包括测试人员、每个时间段需要完成的事。例如我们有一个版本，计划从10月1日开始版本开发，10月30日上线，那么我们可以先制定一个大体的测试计划。
作为一个合格的leader，我们需要制定测试计划，把握整体的测试进度。按时间顺序来说，我们需要完成以下事情。
一、分析需求，制定测试策略
这个时候分析需求不是为了写测试用例，而是大概了解需求的难度，以便制定测试计划，这个计划中需要包括测试人员、每个时间段需要完成的事。例如我们有一个版本，计划从10月1日开始版本开发，10月30日上线，那么我们可以先制定一个大体的测试计划。
测试人员：A、B、C
时间
计划
参与人员
10.1-10.3
版本计划会、需求评审会
A、B、C
10.4-10.6
进行测试需求分析，完成思维导图
A、B、C
10.7-10.9
编写测试用例并完成评审；整理需要的测试资源
A、B、C
10.10-10.17
进行第一轮测试（敏捷测试）；申请测试相关资源
A、B、C；申请资源由A完成
10.18-10.25
进行第二轮测试；
A、B、C
10.26-10.29
进行系统测试；在预投产环境测试
A、B、C
10.30
上线测试；生成测试报告
A
二、控制整体测试进度
在有了测试计划之后，后续的工作都应该按照计划进行，各个阶段完成的时间点多少存在偏差，这是正常的，可以根据需要提前或延后进度，并且各个阶段之间都需要有明确的界限，每个阶段都有特定的任务需要完成。
测试需求分析
根据需求的难易程度判断是否需要对思维导图进行评审，参与评审的通常是相关的测试人员，需要跟进大家的完成进度，主持需求评审会。评审完成后，测试人员修改各自的思维导图，形成最终版本，并根据思维导图开始写测试用例。
用例编写
同样需要跟进用例完成的情况，要求大家在某个时间点前完成，召开并主持用例评审会，与会人员包括开发、测试、产品，所以需要提前与各方沟通，确定时间。
三、随时沟通
与项目经理沟通
时常向项目经理汇报测试进度，反馈测试过程中遇到的外力阻碍，例如某个项目组的人员不配合测试工作等，这些需要由项目经理出面去协调。
与开发经理沟通
了解开发进度，并反馈测试进度，功能没有按时提测、bug遗留太多未及时修复，这些情况需要向开发经理反馈，督促开发人员保质保量的完成开发工作。
与产品经理沟通
开发和测试过程中也会发现一些需求存在的问题，或是开发和测试出现分歧，这个时候要尽早与产品经理沟通，确定最新的需求。并且整个版本中的风险问题也要及时反馈。
与资源提供者沟通
测试需要什么资源，尽早的整理出来，以邮件形式发送给资源提供者，并且随时关注资源下发的进度。
与测试人员沟通
了解手下每一位测试人员的工作状态、工作进度，合理的分配测试任务，帮助他们及时解决测试过程中出现的问题。
四、上线之后的其它工作
上线完成之后，我们要进行各种善后工作。
测试报告与上线报告
这两份报告分别对应不同阶段的测试结果，测试了哪些功能，哪些功能由于什么原因未测试或不能测试，哪个地方存在风险，这些都需要在报告中体现。
剩余资源处理
我们申请的测试资源，哪些已经使用，用在了哪里，哪些没有使用，上线之后需要以邮件形式发送资源提供者，请对方及时回收资源
版本总结会
总结包括整个项目组的总结会和测试组单独的总结会。我们要做的是主导总结会，找出版本过程中的好与不好，优化下一个版本的测试工作。
总之，作为测试负责人，我们需要兼顾多个方面，协调各方资源，牢牢的把握住测试进度。要在各方之间做好平衡，我还有很长的路要走。
————————————————
版权声明：本文为CSDN博主「你不知道的我-」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jxl1994/java/article/details/102468640