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

乐哈哈yoyo

带项目差不多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模板、测试报告的基本模板、测试总结的模板；当然各个版本都可以视情况进行专项调整；那么没有建立起来的包括：测试计划，该内容在当前环境下因为是推进产品比较紧张，所以一直没有做过，后期确实需要做出来：最主要是严禁开发提测晚，压缩测试的时间）

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

　　

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

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

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

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

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

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

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

　　

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

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

• 　　明确任务和进度
• 　　提供相关的资料和条件
• 　　全面深入理解软件需求
• 　　编写测试用例的概要（测试点）
• 　　做测试用例的评审
• 　　细化测试用例
  

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

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

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

　　

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

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

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

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

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

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

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

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

　　

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

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