我是如何做测试项目管理的

带项目差不多1个季度了，针对这一季度的工作做一个总结，分析一下成长和遇到的问题，希望后面可以做的更好。

以下内容有自己的总结，也有参考蔡为东老师的步步为赢—软件测试管理全程实践。

项目内容：IOS端项目

人员：测试组内——4人（包含我）；开发组——10人（包含开发leader）；产品组——1人（单独跟进IOS相关进度）

测试组主要工作职责：做好测试工作，以最少的人力、物力和cost产出符合需求、保障质量的产品。

测试项目管理主要内容：

项目就是一件事，那么项目管理就是通过某种方式来做成这件事情。测试项目管理主要包含测试流程的制定、根据制定的测试流程，控制三方（包含需求方、开发方、测试方）工作进度、工作流程以及沟通等，最终保障产出需要的东西。

 

作为测试组长，站在这个角度上，对于测试管理的理解是什么？

 

1、心态的转变——从一个初级工程师，到一个中级工程师，是对自己手头被分配的任务有了一个更深入的认知和理解；再到测试组长，就需要完成从点到面的过渡，看问题需要有大局观，需要把握整个项目，很多边缘边界的问题，以及互相牵扯的模块，互相有交互工作的团队，都需要考虑到，对于你的思维的整体性、沟通的能力、考虑问题的全面性，以及多线程工作的能力，都会是一个考验。

 

2、构建测试体系——明确测试流程，该流程是各方都需要明确的，这样协调工作起来才能有条不紊，主要是指：需要测试尽早介入；需要给测试留出时间和准备资源；软件测试小组需要编写正式的测试计划和测试用例，并且需要做评审；管理好测试环境（保证测试环境的单一性，不受其他的影响，能够尽快确认是问题并且能够尽快定位问题）；为提测版本做验证测试（验证测试就是从用例中挑选出最精简的测试用例集合）；测试正式开始前开发需要自测；测试正式开始前要做可接受性测试（即从用例中挑选出P0级别的，也就是本次提测内容的最主要功能实现），不满足的打回；明确bug管理流程（包括需求bug——由产品提出；提测后功能性bug——由测试产出；在这个过程中只有测试有权利关闭bug，要及时三方对bug情况）；

测试组需要写测试报告（目前为每天晚上针对当天的测试情况给出报告：包括提测情况、测试情况、bug情况、明日计划；其中bug情况需要统计当日bug总数、当日修复bug数、各个模块的bug、严重bug数、reopen的bug数，这些数据主要是为版本发布后的项目复盘做统计的；其中bug情况要针对当天的bug情况做一个总体说明，严重bug亟待解决的需要重点标出，产品上的bug也要说明，请产品尽快跟进解决）；项目发布后要做项目复盘（当前我们主要是每个版本结束后，做一次项目总结，针对整个版本从需求到最终的发布阶段的各种问题，以及解决方案，以及上一期遗留问题及解决情况等一一做说明和汇总，只有不断总结和推进解决，才能够让整个项目组的情况越来越好）

 

组建测试团队（该内容当前我并没有做过，因为项目人员是由上面分配的，但是对组内人员确实要进行关心，你的真诚是基本）

 

编写各种模板文件（当前组内已经推广建立起来的包含：开发的提测模板、测试的bug模板、开发的bugfix模板、测试报告的基本模板、测试总结的模板；当然各个版本都可以视情况进行专项调整；那么没有建立起来的包括：测试计划，该内容在当前环境下因为是推进产品比较紧张，所以一直没有做过，后期确实需要做出来：最主要是严禁开发提测晚，压缩测试的时间）

 

搭建Bug管理系统、测试用例管理系统，我们现在用的Bug管理系统是Bugzilla、测试用例管理系统是TestLink，主要使用过程中感觉Bugzilla比较好用，TestLink的话就稍显逊色，但目前还没有发现更好用的，也许excel更好用，哈哈。（注：确实要有机会要自己搭建一下这两个系统，这样才有真正的实战经验啊！）

 

其实说到底，这些就是：人、流程、模板、以及对流程中的产出的管理。

 

3、关于测试计划的编写：测试计划的编写，我这里确实有疏漏，因为一直没怎么做过，没有很好的经验，这些后期要逐渐补上来。

 

4、沟通，沟通其实就包含对内和对外两种，对内又包含对上和对下，以及同级三种，对外又包含对开发、对产品、对总的负责leader

 

对内——对上：让领导知道你在做什么，及时沟通，有问题当然要自己掌握度，不能事无巨细全部问领导如何处理，一般领导只喜欢做选择题也不喜欢做问答题，你需要有自己的判断，然后从中选择一些你不好推动或者需要他出面，或者一些事情上首次处理无很多经验的情况下，要及时跟领导沟通，告知当下情况，当然要说出你的解决方案或者你的见解，并在领导推进解决问题，或者他提出一些方案之后能够尽快学**到自己身上；当然及时告知也是为了避免出现事后无法补救才打脸的情况，提前告知风险，提前预知情况，能够有更好的心理准备。领导其实也是你的老师，要跟他多学**，不要怕，学**他的经验，学**他处理事情的方式，并主动在一段工作时间之后进行个人汇报总结以及小组汇报总结，及时反馈和得到上级反馈，如此才能不断进步，往更好的方向走。

 

对内——对下：要真诚；要有个人的能力和德行作为服众的一个基础，所以要不断学**、总结、提高个人工作能力；要开放和公平，营造出这样的氛围才能人心不失；要量才用人；要及时沟通；对于自己指导的学员，更要及时沟通，能够让学员从工作中学到东西；建立起整个组内的学**、创新意识和氛围（这是我觉得需要做的，虽然当前项目太紧张，做的很不好，只是自己在之前不是组长时做过，但上任组长之后事情太多自己也搁置了，确实是需要调整）

 

对内——对同级：对同级也抱着学**的心态，多沟通，多聊多问，解自己的工作疑惑，也听他人的五味杂陈，吸取经验和教训，尽量减少坑和弯路，哈哈。

 

对外——对开发：要实事求是，遇到问题就事论事，测试与开发可能经常会因为一些问题争吵，但不要影响互相之间的合作，这是前提，否则将来的工作无法继续开展；要尽快沟通：大多数情况下确实是应该直接找单人私下沟通，比如一些比较严重的问题（涉及到类似提测失败、reopen率太高这样的情况），让此人了解自己的问题，但不可纵容，对这种情况的纵容就是对测试工作的阻碍；对一些严重问题，还需要找开发的上级领导沟通，让他做到心中有数，也将自己的观点和期望表达清楚，但一切都是建立更好的做好工作的基础上；对一而再、再而三的出现严重问题的情况，需要严厉、严重、特别的提出来，如此才能够推进一些改革和改进的更好推行，方便开发建立起流程，也是对测试工作的一种支持。

 

对外——对产品：说实话，每个人站的立场是不同的，产品是关注功能和体验更多，关注我怎么做能用的更好；开发关注的是我实现起来有木有难度，测试是测试这个流程和逻辑有没有漏洞、也包含这个体验是不是不好。很多产品人员确实不懂技术，在一些逻辑和流程的考虑上可能确实不够周全，这些问题尽量要尽早提出来。对产品而言，要站在更多的用户角度上，来对其讲解自己对流程及逻辑上不合理的地方；当然也要自己多发现新产品和多使用竞争对手的产品（这里目前做的还不够好），这样才能更有说服力，因为很多产品都是从竞争对手和其他类似产品那里借鉴来的东西。

 

对外——对总的负责leader：定期汇总上报工作内容，目前是通过项目总结的方式来做的，这样能让最上面的leader知道问题在哪里，并尽快借力来推进很多问题的解决。

 

5、测试用例的编写：用例的编写最重要，用例考虑的详尽、步骤清晰，关注多个不同方面，才能够从多个方面发现问题。

 

组织编写测试用例，流程主要分为以下几步：

 

明确任务和进度

提供相关的资料和条件

全面深入理解软件需求

编写测试用例的概要（测试点）

做测试用例的评审

细化测试用例

 

对测试用例保持动态更新（一定要坚持做，并且要总结出易错点，保证每次回归时覆盖到，并在之后的测试中关注类似的方面）

 

之前在其他文章中也提过用例的编写的一些考虑点，比如需要从：兼容性（包含大环境和小环境下的兼容；包含新旧版本的兼容）、基本功能和逻辑、用户体验、异常情况处理、不同网络情况处理（比如当前测试app相关基本上都跟网络关系密切，必须对不同的网络情况做处理）、针对所测试的内容做特殊case的测试（比如与声音相关的：做不同距离测试等）

 

主要包括：测试点的梳理（测试点很重要，需要从不同方面、以及大面大点上全部涵盖到）；测试点及测试概要的用例评审（这个很重要，有两个评审时间：测试开始前和一轮测试之后；其实一轮测试之后，大家拿到实际产品测试使用了，能够对产品理解更深入，也能够想到更多方面或者问题等）；测试点的细化（细化到具体的测试用例，需要明确测试步骤和预期结果）

 

6、测试执行：执行阶段需要明确责任，鼓励机制，并建立起整个测试组都及时发现问题、跟进、推进自己名下问题解决的氛围快速建立起来，不止是为了发现问题，最重要的是发现之后推进问题的解决；当然在测试组长的角度上，就需要同时做多项工作，需要自己做相关的部分测试工作，还需要及时跟进其他成员的测试情况（这里定期的沟通、抽查和咨询就很重要了），也需要对大家所报的bug有一个大概的认知，能从bug的情况以及bug的趋势上看出大概当前进行到什么测试阶段了

 

测试执行的安排也很重要，一般情况下重要的模块会分配给比较有经验的人来做；如果人手不太紧张，可以大家一起做，其他新人能够在这个过程中不断像其他经验丰富的人学**。

 

测试组长要阅读每一个Bug，这个要求并不过分，这个当前却做得很不好。

 

7、测试总结：测试总结很重要，包括项目整理的总结、个人的总结、小组的总结；做项目总结，是为了梳理整个过程，明确问题和找到原因，改进整个流程和推进项目状态越来越好。

 

自己目前所做的是项目的总结，会针对三方做一个总结，分别是开发、产品和测试，总结要主体上基于当前版本项目做，也需要对之前版本做回顾，以及在当前版本项目上之前的问题是否有所改进。因为当前基本上是10天一个app的版本，基于比较重要的版本，基本上都做了回顾，最重要的还是基于问题，要找到解决方案，并且最重要的是：跟开发负责人、产品负责人沟通，跟自己组内人员沟通，一起来执行解决方案，并且要确实严格执行（针对不执行的，要有一定的惩罚制度，让大家都理解执行的重要性和必要性）

 

那么一个基本通用的模板如下：

 

测试计划执行情况：看实际情况有么有按照计划执行，如果没有，找出阻碍和原因，是否可解

 

Bug库分析：包括Bug的有效率、各优先级的Bug所占的比率、各模块的Bug分布比率、测试工程师的Bug发现率、Bug的修复率、各阶段发现的Bug发现率、Bug的生命周期

 

其实可以通过问自己N个方面的问题，来丰满每次的总结：人员安排、时间安排、风险分析、测试执行、Bug、沟通、项目管理、员工管理，这些方面的总结需要根据不同的提交对象进行不同方面的删减和充实。

 

在自己带项目的整个过程中目前为止遇到的问题？如何处理的？目前自己认为可能需要加强或者需要后续更加关注的内容？

 

1、目前为止遇到的问题及处理措施：

 

跟开发团队之间的沟通问题：主要大家来自不同的团队，刚开始的工作态度都会有不同，这个时候视问题的严重程度，有些时候确实需要采取一些强硬措施，当然提前跟开发负责人打招呼是比较好的一种方式

 

开发团队遇到很多问题，因为对产品质量的认知不足导致不愿意解决，甚至有问题但是无法立即定位原因的，会拖N个版本也不解决：通过邮件方式、通过会议说明、通过项目总结、通过每天的项目测试情况的汇报，通过各种方式说明，并明显注明（需要告知开发负责人、开发组的上级leader），告知开发需要解决，并且需要组内指派人员单独跟进，并关注跟进的结果

 

对开发团队不断出现Bug反复、提测质量不高的问题：一个是态度问题，一个是能力问题；能力问题也需要找开发负责人沟通，由开发负责人来按照各人的能力分配工作模块，或者开发组内自己制定其他措施等，测试这方就是要告知开发需要明确的提测模板（包含提测文件名、提测路径、提测说明，提测说明中包含详细的信息：正式环境或测试环境等，提测模块，影响范围、建议重点关注内容、修复Bug）、提测标准（测试点提前准备好，给开发做自测，需要自测之后功能上无明显Bug才可提测）；态度问题就是：多沟通、测试人员单独找对应开发沟通，积极追自己名下的问题，将测试的情况及时反馈给开发负责人，让开发负责人来督促他们及时解决问题，制定各种模板，包含提测模板、bugfix模板、bugreopen率统计及处理措施等

 

2、后续需要关注的问题：

 

把项目带稳定，建立起一个积极的团队；具体的根据各人能力不同分派不同任务，让组内成员都能够工作舒心且有成就感，这一点很重要，也不好做到；个人能力的继续提升，包括测试基本知识及时补充和更新、测试技术的掌握、代码能力的提高、自动化的推进