测试管理.md

测试管理

你认为测试经理的工作职责和内容是什么？

1. 负责建立和维护一个有效的测试流程;
2. 负责测试团队的日常管理工作;
3. 负责制定和安排测试计划、测试工作;
4. 带领测试团队进行软件测试工作、按照制定的测试计划执行，并监督和控制测试工作的进程;
5. 负责测试用例的质量，开发高效的测试用例;
6. 负责与其他部门的人员沟通协作，例如与开发人员和项目管理人员进行沟通，共同推动项目的顺利进行;
7. 负责测试团队的培训，培养团队队员的能力。

作为测试Leader,你应该怎么建立公司的测试管理体系并实施它?

一般应用过程方法和系统方法来建立软件测试管理体系，也就是把测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。其主要目标是在设定的条件限制下，尽可能发现和排除软件缺陷。测试系统主要由下面6个相互关联、相互作用的过程组成：

• 测试规划

确定各测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。 测试规划与软件开发活动同步进行。在需求分析阶段，要完成验收测试计划，并与需求规格说明一起提交评审。类似地，在概要设计阶段，要完成和评审系统测试计划；在详细设计阶段，要完成和评审集成测试计划；在编码实现阶段，要完成和评审单元测试计划。对于测试计划的修订部分，需要进行重新评审。

• 测试设计

根据测试计划设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计也与软件开发活动同步进行，其结果可以作为各阶段测试计划的附件提交评审。测试设计的另一项内容是回归测试设计，即确定回归测试的用例集。对于测试用例的修订部分，也要求进行重新评审。

• 测试实施

使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件缺陷，最终得到测试报告。

• 配置管理

测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。

• 资源管理

包括对人力资源和工作场所，以及相关设施和技术支持的管理。如果建立了测试实验室，还存在其他的管理问题。

• 测试管理

采用适宜的方法对上述过程及结果进行监视，并在适用时进行测量，以保证上述过程的有效性。如果没有实现预定的结果，则应进行适当的调整或纠正。

作为测试团队的负责人，如何提高测试团队的技术能力？

团队负责人，提高团队技术能力，总而言之需要提高团队的技术嗅觉，能够更好的问到技术的味道。

• 测试用例分享：在每周的周会中，分享团队里面比较好的测试用例和比较差的测试用例；分享好的是为了让其他人学习，分享差的让其他人远离这种写法
• 技术分享：每个人都需要做技术分享，说明该技术对测试工作带来的益处。倒逼测试人员去阅读资料，去总结，深入原理，并且还要以其他人能理解的方式讲出来。分享人和倾听者都会有收益，何乐而不为
• 每日技术新闻：每天早晨推送几则最新的技术相关的新闻，了解时事，提高技术嗅觉
• 轮岗制度：测试人员除了需要完成自己组内的工作之外，还需轮岗去其他项目组。这也会促使他更多的思考不同系统之间的差异性，学习更多的业务和技术相关的知识，不同项目底层的架构，实现方式等等
• 读书会：在一个人的能力象限中，我非常看重学习能力。原因很简单，一个人一旦停止了学习，就停止了进步。读书虽然不是学习的唯一方式，但一定是不可或缺的方式

列举你以往项目测试中遇到的风险以及你如何处理的？

• 测试人员：

1. 业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透侧、理解错误等。
2. 测试人员变动：离职，岗位调动，请假等。
3. 定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的。
4. 疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试显示出倦意和缺乏兴趣。
5. 同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出发的测试观察点。

• 测试相关文档， 在TQM（全面质量管理 Total Quality Management） 中指的是生产原材料：

1. Spec (详细规格说明书)缺失：只有PRD(项目需求概要说明书)，没有spec
2. 需求变更：这是最不想，但又最经常发生的事情
3. 测试用例/数据设计不充分：某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。
4. 质量标准不统一：如某些Bug的优先级方面，测试和开发的认同不一致。

• 测试方法和实施：

1. 错误或缺失测试方法：对功能点没有采用正确的测试方法，或某些测试方法没有被忽视，如边界测试等，导致测试不充分。
2. 场景的缺失或部分缺失：Spec非常详细，所有的精力放在功能点的测试上，忽视了业务场景(Spec中无定义)的全(100%)测试。
3. 测试用例实施不充分：测试用例由于各种原因没有完全测试，如在回归测试中。

• 测试环境：

1. 被测软件版本不统一：没有有效的配置管理，这种情况及易出现
2. 测试软件环境不一致：测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。
3. 测试硬件环境不一致：测试员之间或和开发的设备不一致，如CPU频率，内存大小等。
4. 测试硬件未及时到位
5. 测试环境不稳定，容易出现各种异常阻塞测试进展

• 测试时间：

1. 测试时间不足：里程碑之间留给测试的时间无法满足全测试要求。
2. 测试时间延长：由于需求方突然宣布原进度表中的里程碑时间点延后，导致项目的进度表一下松弛了许多。笔者参加过的两个项目就遇见过这种情况，我们为世界某著名品牌电脑供应商开发并提供随机软件。在项目进展到中后期时，客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装，要等到下一版本，时间延迟可能长达三个月，甚至更多。

• 风险应对方案分为两类，分别是预防和控制

针对还没有发生的风险，已经风险避免，转移或者降低。

1. 在做测试计划时，对资源、时间、成本等估计要留有余地，避免风险发生时没有相应的资源及时支持应急方案。
2. 测试开始前，对测试环境、测试工具等难以控制的因素进行检查，将这些因素纳入风险管理计划中。
3. 通过培训提高测试人员的综合素质，降低由于质量目标不明确、项目背景不熟悉、测试技术及工具不能熟练掌握导致的测试风险。关键技术岗位要培养后备人员。
4. 对所有过程做好日常跟踪，并进行完善的文档管理。
5. 对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换。

针对已经发生的风险，需要及时控制和调整

1. 需求增加：增加测试时间，人员，资源；协商，延迟交付日期；推迟或者删除低优先级的功能或者特性；降低对低优先级的功能和特性的测试质量
2. 测试人员变动：测试人员加班；推迟发布日期；抽调测试人员；
3. 测试环境不稳定或者与生产环境不一致：测试接入之前便需要对环境逐个检查；增加测试资源

如果当时间不充裕时,该如何安排测试？

1. 跳出这个问题本身：能够讲如何从项目初期就做到避免测试时间不够（如果以前有过很成功的案例是很好的加分项）。
2. 懂得基于风险的测试：如何估算时间，设计测试策略，把最有限的时间分配在项目风险最大的地方。这是项非常重要的能力有非常成熟的形式化方法，也有非常多的实战 CheckList（做过大项目的人肯定能够讲出不少条）
3. 如何保证项目状态清晰：让主要干系人随时知道现在项目的状态，特别是质量情况，未来可能的走势，大概什么可能达到发布状态。QA 就像是一个在夜间走山路的汽车的大灯，他的职责就是最及时有效的发现项目所有的大坑，并明确的告诉司机（项目主要干系人）。这里面隐含着对风险管理的能力的考察，也隐含着对沟通能力的考察。
4. 项目管理能力：如何让团队对现状，对现在的项目计划是否能够有效进行下去有一个清晰的认识，并且引导团队 Work Smart 搞定挑战。你不一定是团队 Leader，但在系统测试阶段，从某种意义上 QA 就是项目 Leader。在关键时刻，项目的成败，重要决策是否能够被做出，与负责项目的 QA 有重大关系。
5. 软技能：推动能力，OwnerShip，协调能力，抗压能力，能否激励团队，给团队信心等等。

列举你曾经做过的测试(你认为有技术含量的或者提高了测试管理能力的),并说下你从中如何受益？

在开发和测试存在不合作甚至对立的情况下，你如何平衡和协调工作？

先简述不合作甚至对立的几个可能原因：

1. 出现的缺陷容易阻塞测试流程的正常进行
2. 修复完并验证完关闭后的bug重复出现
3. 测试人员发现同一个模块缺陷太多，抱怨开发质量太差
4. 轻易复现的bug，开发硬是复现不了
5. 测试时间紧迫
6. 开发提供的文档非常粗略，无法下手测试
7. 开发抱怨测试提过来的bug根本不是bug，而是没有认真查看相关文档
8. 测试提的bug质量不高，没写前提，步骤不清晰，日志截图也没提供等
9. 测试提的bug需要极端情况才出现，用户一般不会这么用
10. 等等

应对方案：

• 从项目立项开始，做好全盘计划，包括需求设计时间，开发编码时间，测试时间，运维部署等等，其中任何一个非测试节点出现延误，都不应该导致测试的时间被压缩
• 制定完整的项目流程，从开发提测的要求，到测试提交bug要求，更加规范和约束开发与测试的行为
• 每一个参加开发的开发人员，和参加测试的测试人员都要尽可能的参加到需求评审会，开发设计，架构设计，测试用例评审会
• 测试人员提供冒烟测试用例给开发，开发执行完再移交给测试人员，测试人员执行冒烟不通过，打回重新开发
• 规范开发提供的文档，提测内容包括文档
• 规范测试提交的bug，规定的提交内容必须有，其他可提供的内容尽可能提供帮助开发更快的定位问题
• 重复reopen的缺陷记录在案，并在项目总结会上提出：适当的施加开发压力
• 阻塞测试流程的bug优先解决
• 不易复现的bug，多复现几次，写明出现概率，以及提供当时的环境和日志信息等
• 更长远的看，开发/测试应该多提高自身的工作质量，提高技术水平，沟通能力，情商等等

如何推动某个测试框架落地

在我个人看来这个问题有点类似与战略实施，只不过没有这么宏伟。框架落地一定是需要上层建筑（领导层意愿，企业价值观等）以及下层基础设施（CI/CD，测试平台等）的全面支持，否则很难进行。

• 评估阶段：发动一部分有经验的人员来调查，取样，分析，试用等过程，全方位的评估该框架（方案）的可行性，能否降低当前面临的一个或者多个痛点，若可行，继续下面的步骤，不可行及时停止并说明不可行的理由
• 计划阶段：需要将框架的落地目标细分，编写出每一个不同阶段的子目标，时间/进度/目标期望/参与人员等等；每一个阶段不同的策略实施，相应的方针等，全面统筹规划
• 运行阶段：每一个子阶段运行过程，都需要及时处理出现的问题，及时调整计划；让测试人员对框架的学习，设计，执行和结果之间相互支持，并行着进行
• 总结阶段：每一个阶段的结束，需要进行总结。包括：整个实施过程，实施结果，实施效应，面临的问题，解决的问题，待改善的地方等，另外还需要对下一个阶段计划适当的调整。