项目级测试负责人的工作要点总结
序：
随着测试团队的不断增加，同时并行的项目越来越多，这就要求我们的测试人员快速的成长，要求我们每一个测试人员能够尽快培养具备基本的独立负责一个项目的整体测试及技术支持工作的能力。同时，项目并行会出现很多项目级别测试负责人的工作角色，对这个工作角色的主要工作内容进行汇总，供相关测试人员参考，给刚走向管理岗位的测试人员一些建议。
整体而言，项目测试负责人主要承担的工作内容为：根据项目规格书制定测试策略及计划、根据项目规格书分解分配测试任务、及时了解测试进度、版本发布资料的整理和准备以及在项目后期对整个测试工作的总结，另外，对于大多数有相应试验局测试的版本，作为项目测试负责人还需要负责完成一部分试验局的工作。
针对上述的一些工作点，以及日常工作中的一些工作重点，在下文做具体的说明：
1、工作时间划分
2、制定测试策略与计划
3、构建测试用例和学习规格书
4、任务的分解分配
5、测试进度跟控
6、测试用例testlab的选取
7、测试任务落实和协调
8、测试设备的控制
9、版本发布资料的整理和准备
10、注意事项的填写
11、CQ的跟控
12、遍历每日打的bug单
13、Bug沟通
14、每日拷机督促，上班确认拷机结果
15、5分钟碰头会的控制
16、未验证bug的类型和情况
17、项目的保密和核心技术的保护意识
18、测试工作总结
19、版本文档备份
20、主导试验局的实施
正文：
1、工作时间划分
项目级别的测试负责人，除了项目管理、测试进度跟控之外，同时还会承担项目负责和测试工作。根据经验，项目级别测试负责人因为本身就是资深的测试人员，所以承担的测试模块往往是最核心的部分。 希望在分解分配任务时，大家能合理的分配属于自己的工作时间安排。
因为日常的bug例会，bug的跟踪，和开发需求人员的交互，疑难问题的定位太过频繁，会影响自己本身测试工作的状态和效率。如果项目级测试负责人承担过多测试任务，肯定会成为项目测试的瓶颈点，表现结果为自己做了最多的事情，反而是测试执行最不利的一个环节。
按照常规统计经验，建议项目整体跟控管理工作和具体测试工作的时间分配为6：4，或者5：5。
2、制定测试策略与计划
制定和刷新测试计划，是一个测试项目负责人最核心的工作，直观点说，就是对测试的整体把握和控制。在项目的计划阶段，测试负责人需要根据项目的计划安排（部分项目存在deadline）和规格书制定完成该项目的测试策略与计划。
在开发阶段根据当前的项目进展情况及时进行更新。实际执行时，在BBFV阶段，新功能开发的进度往往和原定计划有出入，测试人员和测试设备可能有变动，可能有其他优先级更高的项目冲击等等情况。就需要项目测试负责人及时和SE、LPMT沟通，实时刷新计划。
3、构建测试用例和学习规格书
在项目初始阶段，测试用例的编写及更新是工作重点之一，因此在此阶段项目测试负责人需加强与需求、研发人员的沟通，对规格书应有一个全面深刻的了解，只有充分了解规格书的要求才能制定合理的测试策略与计划，才能编写出符合规格书的测试用例。
关于测试用例编写的任务分配，在《由需求形成测试用例指导书》已经有相关建议：
在学习规格书的时候需要注意对于系统原有功能的继承性、新功能的可测试性以及系统整体功能的实用性，并及时提出自己的意见和建议，从而规避当系统整体开发完成后发现系统无法实现客户的需求。
组织相关测试人员学习系统规格书，并组织安排测试用例的编写及评审，同时在系统的整个进行过程中注意督促测试人员对测试用例的维护、更新及评审，确保测试用例与系统规格及当前的系统实现的一致性以及测试用例的正确性。
根据目前项目特点，在SDV测试阶段、甚至包括版本发布前，都存在规格需求反复修改、增删、自相矛盾的可能性，如果动态的维护测试用例，保证测试用例的及时性、正确性和完整性，是测试负责人需要克服和解决的问题。
因为是内嵌文件《由需求形成测试用例》，很多人容易忽略其中的内容。在分解分配测试用例，测试用例编写的阶段，很容易出现一些问题，比如：测试人员为新手，对业务不熟悉，构建测试用例时间较长，但用例适用性不大对需求规格没有达成一致，测试用例细化后，修改起来比较痛苦需求规格的变更，导致测试用例跟随变化成本太大，无法维护。
4、任务的分解分配
在项目进入系统测试之前，项目测试负责人需根据项目规格书分解分配测试任务并制定WBS计划，在制定WBS计划时需考虑项目的整体计划及系统发布的时间点，以及测试执行人对系统的熟悉程度。
例如：一个功能如果交给一个对系统非常熟悉的人进行测试可能只需要一天而给一个对系统不是很熟悉的新人进行测试可能就需要两天。
在制定WBS计划时若发现在系统发布时间点无法及时完成所有功能的测试，则需对整个系统功能的优先级进行排序，并及时提出预警信息，同时与SE和LPMT确认版本测试的基调：是调整发布时间或增加测试人员还是要求测试覆盖度到某一阀值，或对一部分优先级较低的功能只进行基本测试。
而在测试时间充裕的情况下，则需充分考虑各项功能点的测试，特别是一些容易出问题或曾经出过问题的功能点需加强测试。
五、测试进度跟控
在项目的系统测试过程中，要及时了解测试进度，跟踪BUG提交、修复及验证情况以及系统的拷机情况。
★ 在开发初期阶段，测试组执行BBFV时，很多模块、功能点的开发完成进度和原计划会存在一定的偏差，就需要测试负责人动态的刷新WBS计划，根据实际的开发进度调整测试计划。
★ 在开发阶段，存在版本编译不出来导致无法测试，开发人员修复代码太随意导致版本稳定性反复，需求变更过大导致后端测试开发变更严重等现象，会导致测试工作无法正常进行。就需要测试负责人及时反馈出来，根据项目本身的特点进行对应的处理。
★ 当测试进度出现延期时，要及时确认问题原因，如果是问题协查导致，则需及时与研发人员进行沟通协商，看问题是否必须在测试环境进行排查，若为必现问题可与研发协商要求其在自己环境进行排查，若必须占用测试环境，则需及时调整测试计划，若因此可能影响版本的发布，则应及时与SE确认。
★ 若发现有较多BUG未解决，则应主动联系SE及研发人员召开BUG会确定问题的解决时间。若发现有较多BUG未验证，则应提醒项目组的测试人员及时进行验证，对于一些拷机或非必现的BUG，建议测试人员在此BUG上现做拷机标记，连续拷机一周未再复现的做关闭处理，若再次复现则继续进行排查。
★ 疑难问题的跟控：比较难复现的问题，怎么去尝试复现。比较难定位的问题，怎么驱动、反馈给SE，协调开发人员定位问题。比较难处理的问题，怎么跟控反馈进度等。
★ 每天下班前需确认拷机内容，每天上班第一件事需确认拷机结果，只有这样才能保证拷机的效果，实现拷机的真正意义。
实际上，作为一个项目测试负责人，这部分工作是最重要和核心工作。
很多测试的风险点，需要测试人员及时反馈出来，否则无法保证测试质量，也无法反馈产品真正的问题所在。同时，测试计划受到冲击太大的话，对测试计划和项目计划都是重大的风险，需要项目负责人及时反馈，以便解决问题，规避风险。比如：
★ 版本未编译通过
★ 版本不稳定
★ 版本反复崩溃，上周bug较少本周bug较多等
★ 开发人员占用测试环境时间太长，导致测试无法进行
★ 需求变更较大，测试执行无法保证
六、测试用例testlab的选取
（以TD为例）
比如测试用例的执行约定都在TD上进行。关于testlab曾经有过讨论，如何制订统一的规范。比如部门约定的规范如下：
TestLab修改要求：要求建立“第一轮SDV测试”、“第二轮SDV测试”、“第三轮SIT测试”、“SVT测试”、“冒烟测试”等文件夹，然后将相关测试用例分别导入。
理论上未封闭版本不强制要求在TD上执行，但封闭版本的几轮测试在TD上必须有用例有执行记录。
在实际的执行中，有两种习惯做法：
1、由测试负责人统一拉去测试的testlab，在测试用例库中选择每轮次、每个功能点要执行的测试用例。
2、由测试执行人自行拉去每个分配的功能点所要执行的测试用例。
从测试控制和测试管理的角度，我们推荐使用第一种方式，这种方式，可以让测试负责人真正的知道测试执行和测试覆盖度，避免出现功能点已经覆盖但是漏测的现象。
从长远来讲，在TD上为每轮测试、每个功能点的测试选择相应的测试用例，构建testlab，是测试负责人必需要完成的一项工作任务。
七、测试任务落实和协调
分解分配测试任务时应该注意几点：
1、颗粒度
对一些主动性好、测试经验丰富的人，安排任务的颗粒度可以大一些，其中一些优先级、测试任务的顺序安排也依赖自主性调控。
对一些主动性较差，或测试经验较少的人，安排任务的颗粒度要细一些。以免出现测试人员面对一个庞大的系统，感觉无处入手，或者借口不知道怎么测试，测试什么的情况。
2、找到主体负责人
如果一个测试任务分配给一个测试人员，毫无疑问，这个测试人员对这个任务、这个模块就是主体负责人。
如果一个测试任务分配给多个测试人员，那么一定要找一个主体负责人，对这个测试任务进行负责---可能不是从测试能力的角度指定，而是从责任心的角度考虑。
3、及时跟控
对项目组所有的测试人员，希望对测试执行加强跟控频率。我们希望测试工程师都有主动性，如果有测试风险或测试延时都会主动站出来反馈问题。
实际上，大多数人还是有惰性思维，总会找出一大堆借口理由拖延着不去工作。这就依赖于项目负责人的跟控程度。可能有这样的员工，你一天不过问，他就拖延着一天不做事情，而且理由还非常充分。
实例：
A员工测试某项目，早上版本未编译出，A员工也不向项目负责人反馈，开始在测试环境逛圈。下午项目负责人发现后，才反馈说版本未编译出。实际上，完全可以一早通知，由项目负责人重新安排工作，或者回退到上个版本执行测试。
B员工和开发人员纠结在一起，反复的帮开发人员捕获信息，测试临时版本，对自己的测试计划造成严重冲击，也没有和项目负责人说明，导致项目测试计划延期。
C员工测试执行一直不太好，他所负责的模块，是否需要安排人重新复测？
项目的跟踪、控制非常考验一个项目负责人的工作能力，也是需要花费心思去做的事情。
八、测试设备的控制
一般的测试项目，比如增量开发、软件开发都不会触发到测试设备的变更。当然，还有一些测试项目，测试设备的变动比较大，这点就需要测试负责人注意记录设备的进出和分配情况。比如：
★ 新硬件项目开发，demo板卡较多
★ 硬件改版较多，A、B、C、D多批次硬件混杂，并分批退帐
★ 有外厂商设备或共用设备，在测试、硬件、开发多环节反复流转
★ 试验局，大批设备物资借用分配出账
★ 系统集成设备选型，不同厂家不同型号设备较多
涉及到测试设备的控制，就需要对设备进入测试环境和离开测试环境进行明细的跟踪、设备和借条收据同步进行，再此不在赘述。
九、版本发布资料的整理和准备
在系统测试临近结束时，大体工内容如下：
1、首先需要整理一套完整的待发布版本，此版本要包含业务程序、操作系统、boot文件、conf配置文件、debug文件以及硬件文件（如：红外文件等）。
2、要求项目组测试人员使用此整理好的版本进行回归测试，同时完成版本发布检查表中的各项检查。
3、对此版本的遗留问题及BUG数等数据进行统计，并提供产品测试报告和版本发布说明。
特别要注意的是：
第一、若所发布的是补丁版本一定要注意对版本发布维护表的更新，以便于客服、销售、生产对系统的新增功能及解决问题的了解；
第二、若此项目的硬件存在多个版本，则需注意当前软件版本对不同硬件版本的兼容性，若出现无法同时兼容所有硬件版本时，需提供软硬件兼容列表，同时要注意及时更新。
十、注意事项的填写
版本说明中“注意事项”部分内容，属于版本发布资料的一种，因和其他版本发布资料有其特殊点，故在此单独列举出来。
其他的版本发布资料，在版本发布阶段，可以根据各种工具的导出，整理为数据和表格，比如：
从CQ中得到已经打出的bug数量、bug组别分布、bug时间分别、遗留bug列表；从TD可以得到测试覆盖率、测试轮次、测试覆盖需求的百分比。
只有“注意事项”，是需要根据测试过程中的日常沟通，产品线就产品特性和应用达成共识的积累。如果平时不注意记录，最后编写此部分时，肯定会有所疏漏。
所以建议在版本测试开始，就自己形成一份文档，对日常沟通交流时的一些要点都记录下来，以便最后形成版本发布的注意事项。比如：功能的遗失、升级的注意事项、暂时不支持的功能、新功能的注意要点、版本和版本之间的差异性等等。
十一、BUG的跟控
测试执行过程中，bug是测试管理人员需要关注的核心之一。简单点说，bug可以分析软件质量，评估测试人员绩效等。从测试的角度，稍微扩展出去，bug的作用大致如下：
1、备忘与沟通
备忘是一个Bug管理系统最朴素、最基本的作用，好记性不如烂笔头，道理就这么简单。您什么时候测出了Bug、怎么测的、当时环境怎样，开发人员解决了没有、什么时候解决的、如何解决的，需要及时记录下来；
问题一多，您靠记忆是记不住的。没有遗漏地记下所有问题点并确保适当地处理掉，是Bug管理的基本要求。Bug的产生、变更需及时通知相关人员，他们也应能随时查询不同状况的Bug 数据，良好的沟通才能保证有效的协作。
2、监控
作为项目管理者，您需要及时全面了解目前的项目状况，有些Bug是影响全局的严重错误，需要立即做出处理、决策；有些Bug需要决定改还是不改，或是放入以后版本、分配给其他人等等。所以项目管理者应该能够监控Bug状况。
3、定量分析
对Bug数据作定量的统计分析是更进一步的需求，如：bug数量随时间变化的趋势图、从测试者、责任人、缺陷级别、缺陷原因等不同角度统计缺陷数量等等。
一个BUG管理平台，比如CQ，那么作为一个合格的测试负责人，就必需熟悉掌握CQ的各种查询设置。方便从不同的角度去统计分析bug。
十二、遍历每日打的bug单
结合上点，测试负责人需要对每日所打的bug单进行遍历，查看有无描述错误，有无错别字，描述是否清晰，是否有一些可以扩展出去的测试点而漏测。
通过遍历bug，并且和实际的测试执行人员沟通交流，可以加强测试执行人员分析问题的思路，对测试组所打出去的bug的细节做到了解和掌握，从而对整体质量做到心中有数。
如果测试团队成员都是富有工作经验，并且团队经过多次磨合的人，可适当的调整每日遍历bug单的做法。如果测试团队的新人比较多，通过遍历bug，并且一起讨论bug的细节，可以很好的指导新人工作，形成严谨的工作态度。
另外，根据自己的经验，可以初步判定某一模块、某一功能所暴露的bug是否正常，从而判定软件质量、开发人员和测试人员效率、执行力等。
遍历新人的bug单，对新人的成长特别有帮助，针对这点，不仅仅希望项目负责人员能做到，更希望新人能主动反馈，比如把自己的bug单整理出来，请ltm来过目，这样，对提高自己的排查问题思路，提高自己描述问题的能力，会有针对性的提高。
十三、Bug沟通
贯穿整个测试周期，关于Bug的沟通交流，肯定是测试负责人、测试执行人所要面对的工作难点之一。
在关于Bug的沟通上，每个团队、每个当事人的风格都不一致，而且人和人之间的勾通交流，也没有死板的流程或套路，如何应用、如何勾通，还需要大家的自行把握。大体而言，会有如下的场景，以供大家参考：
◆ 一个bug，当时很容易出现，打给开发人员后，无法复现
◆ 一个bug，无法定位具体的开发小组，几个开发小组之间互相推诿
◆ 一个bug，修复后又再次出现
◆ 一个bug，开发人员定位过程中重启设备，然后要求复现
◆ 一个bug，反复复现，开发人员没有明确的思路，还是要求不断复现
◆ 一个bug，需要和开发人员描述bug产生时的应用场景
◆ 一个bug，测试人员误打，被开发人员指责
◆ 一个bug，可以上层业务修改，也可以低层业务修改，无法决定
◆ 提出的一些易用性的建议，不被受理
十四、每日拷机环节
关于研发，有个说法，大家做的是智力劳动，而智力劳动是看效率的，如果思路清晰，也许短世间内成果显著，如果思路不清晰，那么再磨时间，工作成果也不明显。或者直白点，研发工作，不能以单纯的工作时间来考核工作业绩。
但是工作时间无疑是一个重要的因素。特别是针对测试人员，面向目前以黑盒测试为主，以手动执行+部分自动化测试覆盖为方法的现阶段。
有一个很重要的评判点，就是每日的拷机测试。每日的拷机的任务有两个来源：
1、按照测试计划和测试用例分解分配的每日性能测试：主要针对规格书中，要求的2、4、8、12小时的功能性能点。
2、需要复现的bug，或bug例会沟通分配的专项拷机性能测试。
涉及到性能测试、拷机，不是简单的随手运行起来就ok。必然涉及到一系列的操作：比如连结串口、捕获保存打印信息、录制自动化脚本、搭建拷机环境、确认设备运行情况等。这些操作都是需要时间的。
所以从个人的角度，大家可以观察一下，所有考核较好的同事，肯定很少有卡点下班的。
从测试负责人的角度，怎么有效的利用每日的拷机环节，在复现bug、专项测试、性能测试之间平衡安排，以及确认拷机环境搭建运行完毕。第二天收集拷机执行结果，是在性能测试方面，必需要做好的一个工作要点。
增加每日拷机流程示意图如下：
拷机测试的难点在于打印信息的捕获，原始状态的采集，以及第二天拷机结果的确认环节。
十五、5分钟碰头会的控制
较长期的项目，测试控制可以通过周例会、周报、半周例会、bug例会等方式进行控制。如果周期特别短，或重要性特别强，需要重点控制的项目，可采用5分钟碰头会的方法及时确认。
5分钟碰头会：
项目组测试人员，在每天的早晨、中午上班、下午下班三个时间点，召开减短的碰头会，就工作进度进展进行沟通，快速的确认工作进度，方面及时调整和反馈。
这种方式的例会，适合短期高强度的打标项目。做为最高效的跟控方法，不建议一般项目使用。针对一般项目，可以根据项目周期进行每日、双日、半周碰头既可。
十六、未验证bug的类型和情况
根据QA和TE关于Bug责任人的沟通确认，当Bug处于Resolved（待验证） 状态，此Bug的主体负责人将属于测试人员。Resolved 未关闭的bug，对项目来说属于未解决的bug。
在版本发布前，测试人员有工作职责把所有未验证的问题处理掉。
对此，作为测试负责人，当bug处于Resolved 状态时，必需及时进行验证操作。如果未能及时验证bug，也必需在bug上标注原因。作用有二：
1、说明此bug未及时关闭的原因：硬件变更、小概率需长考、环境设备拆除变更
2、证明测试人员已经关注此问题，不是没有及时处理。
十七、项目的保密和核心技术的保护意识
做为一个测试负责人，一般的测试任务中，有必要和测试执行人员探讨需求、讨论评审测试用例，让所有的人掌握业务的原理、从而能深层次的设计测试用例，完成测试任务。
但是一些特殊的项目，涉及到公司保密的技术方案，就需要测试负责人有相关的项目保密意识，一些测试用例可以由自己单独构建，不需要把系统实现原理展示出来。
面对测试执行人员、外围的客服和销售人员，可以不用系统的讲述实现原理，如果有必要，只需要描述黑盒的输入、输出结果即可。
否则一些核心的算法，或业务逻辑，甚至公司的一些特殊处理策略暴露出去，容易导致公司的损失，希望测试人员在此类项目上有风险意识和保密意识。
十八、测试工作总结
在版本发布后，建议召集项目组的所有测试人员一起对此项目测试过程中遇到的问题、解决的方法进行整理总结，这样既能加强组内人员的沟通交流也有助于组内人员的互相学习，从而提高测试人员的整体能力。
总结能力是一种很好的能力。在这里请允许我再次引用这句话：
人的能力提升10％来自培训，20％来自从他人身上的观察和学习，70％来自实践后的总结。
十九、版本文档备份
在版本测试后期，项目负责人会编写一系列的文档，比如测试报告等。建议项目负责人对测试报告的各个版本都进行保存，以便后续追踪问题使用。
原来在某产品线有相关教训：测试人员给出的1.0版本的测试报告中说了一堆问题，实话实说了测试时间不够，测试用例未执行，还有很多问题没有解决。然后经过一次次评审和谐，最后形成的测试报告是2.0版本。结果在1.0版本中提到的一个已知问题，在2.0版本被和谐了，然后暴露在客户现场，最后追究责任很是头疼。
所以，希望各项目负责人对测试报告的各个版本都进行保存，方面后续跟踪问题。
关于版本备份：
除了将版本放在发布服务器之外，为了方便我们自己更换版本，维护项目，应该在组内的ftp服务器和个人pc进行发布版本和发布文档的备份。避免每次都要到苏州版本发布服务器取版本的操作。节省更换版本的时间。
二十、主导试验局的实施
虽然不是所有项目都有相应的试验局，在此仅针对有试验局的项目简要说一下作为测试负责人需要完成的工作内容。
首先，根据销售及客服人员提供的客户需求及客户现场的网络拓扑，制定试验局测试计划以及试验局测试方案及用例；其次，在试验局的实施过程中提供及时有效的技术支持；最后，在试验局结束后，若该项目有多个试验局，则需在每个试验局结束后提供一份局点测试报告，在所有试验局结束后提供一份试验局总结报告。
若该项目只有一个试验局，则可只提供一份试验局总结报告。
总结：
本文对一个项目测试负责人在整个项目进行过程中的主要工作内容进行了一些总结、整理、汇总，以便相关测试人员进行参考，从而帮助我们的测试人员尽快掌握独立负责一个项目整体测试工作的重点，确保各个项目的顺利进行以及项目质量。