项目级测试负责人的工作要点总结

 

项目级测试负责人的工作要点总结（一）

发布时间: 2011-10-13 14:33    作者: 柳舞随风    来源: 51Testing软件测试网采编

 　　序：

　　随着测试团队的不断增加，同时并行的项目越来越多，这就要求我们的测试人员快速的成长，要求我们每一个测试人员能够尽快培养具备基本的独立负责一个项目的整体测试及技术支持工作的能力。同时，项目并行会出现很多项目级别测试负责人的工作角色，对这个工作角色的主要工作内容进行汇总，供相关测试人员参考，给刚走向管理岗位的测试人员一些建议。

　　整体而言，项目测试负责人主要承担的工作内容为：根据项目规格书制定测试策略及计划、根据项目规格书分解分配测试任务、及时了解测试进度、版本发布资料的整理和准备以及在项目后期对整个测试工作的总结，另外，对于大多数有相应试验局测试的版本，作为项目测试负责人还需要负责完成一部分试验局的工作。

　　针对上述的一些工作点，以及日常工作中的一些工作重点，在下文做具体的说明：

　　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数等数据进行统计，并提供产品测试报告和版本发布说明。

　　特别要注意的是：

　　第一、若所发布的是补丁版本一定要注意对版本发布维护表的更新，以便于客服、销售、生产对系统的新增功能及解决问题的了解；

　　第二、若此项目的硬件存在多个版本，则需注意当前软件版本对不同硬件版本的兼容性，若出现无法同时兼容所有硬件版本时，需提供软硬件兼容列表，同时要注意及时更新。