带项目差不多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的版本，基于比较重要的版本，基本上都做了回顾，重要的还是基于问题，要找到解决方案，并且重要的是：跟开发负责人、产品负责人沟通，跟自己组内人员沟通，一起来执行解决方案，并且要确实严格执行（针对不执行的，要有一定的惩罚制度，让大家都理解执行的重要性和必要性）