做过几个项目的测试执行负责人，有自己单独负责测试的小项目，也有8、9个人组成的团队进行的大项目测试，以下总结下测试执行负责人的职责和整个项目把控过程中的注意事项。实际项目测试活动主要有三部分组成：测试计划，实际测试和总结文档，以下也主要从这三个部分来介绍。
测试计划
当老大告知要来一个项目，并让我们作为测试执行负责人时，欣喜之余也要开始着手准备工作，也就是制定我们的测试计划。首先要询问老大，开发人员对应的项目负责人是谁，测试执行周期多长，测试人员有哪些，环境资源能提供多少。接下来就是与开发人员项目负责人沟通，要来的项目是个全新项目还是维护项目，测试的重点是什么，如是进行主要功能测试还是详细测试等等，项目什么时候过来，有无产品需求说明书或说明文档，各个模块对应开发人员是谁及联系方式等等。在这个过程中要特别注意几点（这也是工作中遇到的问题）：项目中的功能可能有些是直接从其他开发团队引进的，如图片服务器，当我们发现图片服务器bug时，上报bug时对应的开发责任人是谁，如果是其他组的开发人员，负责人是否提前与他们沟通，毕竟这不是他们本组的项目，可能出现不接或者不处理情况；召开测试和开发人员会议，或者直接与开发人员负责人沟通，统一对bug的定义，之所以这么说是因为我遇到过一个接口测试的项目，开发人员提供一个demo，让我们测试接口调用是否正常。我是临时接的这个项目，之前已测试几轮，因为不能看源码，就与开发人员沟通，因为有些缺陷看起来是提供的demo问题，但是接口有返回码，函数对输入值的具体处理或者是否处理我们不知道，为避免遗漏bug，如我们不能判断是demo问题还是程序问题就都上报，他们最终同意这个处理意见，通过这种策略测试，发现了一些前两轮没有发现的问题。
当我们与老大和开发人员负责人沟通过之后，就开始执行测试计划，这里要强调下要注重制定测试计划过程，而不是测试计划文档结果。首先要进行任务分配，任务分配前要与各测试成员先沟通，了解下情况。就拿前阶段负责的项目来说，包括我自己有9个人参加项目测试，有几个是经验丰富的老员工，几个是刚入职的新人。因为对老员工平时的能力及负责的模块都很了解，与他们沟通后，就把相关的主要模块分配到个人，新员工主要是测试次线模块和学习。分配完任务后，制定测试方案，制定测试说明文档，测试说明文档包括项目的简单介绍，测试策略，测试重点，测试进度安排，各个测试人员负责模块，各个模块对应开发人员及联系方式，测试时间等说明，然后邮件发给各个测试人员。如果能联系到销售人员或者技术支持人员更好，邀请他们给我们测试人员讲解用户使用习惯及用户关注的主要功能，避免我们对主要功能的把握有偏差（可惜一直没有做起来）。
接下来就是具体的准备工作了，这个过程是所有测试人员都参与的，如阅读相关文档，编写测试用例（老员工编写，新员工学习），评审测试用例，搭建测试环境等，这里略过。
实际测试
实际测试直接决定测试质量。作为测试执行负责人，我们大多数情况下也是参与测试的，执行负责人与测试执行人的区别就是要放眼于整个项目，把控整个项目的进度，这意味着你要承担更多职责。还是拿上面的项目来说，首先安排冒烟测试，我们知道冒烟测试的侧重点和观察点是项目的主要功能是否有问题，是否影响后续测试，根据冒烟测试结果评估风险，判断项目是否进入系统测试。但是对于新员工来说，什么是主要功能不是很好把握，如果有整理的有冒烟checklist好办，没有的话就很纠结，当时我就给他们讲解冒烟测试，如何去测试，有什么问题问老员工，让老员工辅导新员工，但是如果冒烟测试时间很紧的话，还是有点力不从心，老员工也没有那么多时间，真心感觉到基础的培训很有必要。接着进入系统测试，当时提出让每个测试成员每天反馈执行进度及发现的主要bug，这样方便把控项目，实时调节人力资源。但是有些同事可能工作太忙很容易忘记写，没办法只能硬着头皮每天一个一个去问执行进度怎么样，能不能按时完成测试任务等等。我得出的结论就是：作为测试执行负责人，能调节大家的积极性最好，不行的话，同事不积极，你就得积极。把发现的重大问题及时向上级反映，并每天报告测试进度，让领导知道你在做什么，做到什么程度。
经手过几个项目发现，有些老同事执行测试时，不按照测试用例来走，完全按照自己的思路来走，这个问题我也想过，如果按照执行用例来走，提高不了老员工的积极性，不按照测试用例走，可能是测试用例是自己写的，每个测试点他们都知道，但是又怕同事遗漏测试点，到现场有问题。我自己的解决方法是等项目功能稳定以后按测试用例详细测试一遍，后面几轮按照员工自己执行策略来测，涉及到回归测试用例筛选和探索式测试等等。说是这么说，但是有些同事不是这么做的，感觉这个问题还是没有很好的解决，还在思考具体的解决方法，等待大侠指点。
实际执行中还遇到新员工看不懂测试用例的情况（真心感觉到测试用例很重要，特别是团队中有新人），一般测试用例都是老员工来写，新员工执行。这里主要有两个原因，一是测试用例写的不详细明了，如是这种情况，及时更新测试用例；二是新人对业务不熟悉，可通过老员工给新员工讲解业务流程或实际测试前让开发人员给测试人员进行简要培训解决。主要还是编写出高质量的测试用例最重要，我一直认为测试用例的颗粒度取决于时间和用例的可重用性，测试用例是一定要写的，时间紧的话至少有个主要功能checklist，这也是工作成果物展示的一部分。具体测试用例的编写就不介绍了，这里要提醒下编写测试用例的人员，你们编写的测试用例的质量及语言描述真的很重要。
还有就是与开发沟通问题，有些开发人员不是很好沟通，特别是新人与开发人员沟通时会遇到各种问题，这时测试执行负责人充当中间协调者的角色，一边向同事了解情况，一边与开发人员沟通，实在不行，就上报给老大，让老大跟开发人员老大沟通，现实中发现一个很奇怪的问题：测试人员软开发人员就硬，测试人员强硬点开发人员就很客气。当然和气最好，呵呵呵
总结文档
测试结束后，所有测试人员要上交测试用例执行报告或测试记录，测试执行负责人汇总后形成测试报告和总结，分析bug趋势及原因；编写主要问题说明，分析其风险，并反馈给上级和开发人员。整理出开发人员犯的低级错误，如reopen的bug，给的程序有毒，打包有误等等，提交给老大，让老大与开发负责人沟通，避免犯同样的错误，影响我们的测试。
测试结束后测试活动，我总感觉组内少了一个很重要环节：bug分类分析，持续跟踪。多数同事对提交的bug很少跟踪，提交了就提交了，没有尽量确保提交的bug修复了。缺少对bug没有分类，如哪些是功能问题，哪些是UI问题，哪些是控件问题，这样可以为下轮测试提供参考。还有就是开发人员置成Not A bug的缺陷，是测试人员理解错误还是开发人员的问题，以免下次犯同样的错误。这也是自己以后应该注意的地方。（个人感觉这个问题还是小组老大出面处理好点，因为我发现测试执行负责人的权利不够，呵呵）
名称之所以为经验总结一，我想刚作为测试执行负责人不久，对测试执行负责人的职责及项目各个阶段的把握和掌控还有很多不足和需要提高的地方，但愿明年再写一篇总结二，对测试执行负责人的职责有不一样的看法和更多的经验总结。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/