导语

相信每一位测试小伙伴对于测试过程管理都有自己的独特见解。我所在的部门 2017 年初开始施行测试变革——“测试左移"。过程中有从技术层面的” 左移 “，也有从流程层面的” 左移 “等等，方式形态万千。今天和大家分享的是我在这个过程中，除了个人技术能力提升外，在测试过程管理上的一些感触。它让我目前作为业务测试负责人也算得心应手。希望对其他小伙伴也有一些借鉴。

年后，我负责的业务测试内容发生了一些变化，说实话，当时内心还是感受到一些慌乱。现在总算是风雨过去，再见彩虹。而在这个过程中有两个关键点让我的测试过程管理工作受益匪浅，一是努力培养项目团队全员的质量意识来改善过程质量，二是制定良好的测试策略来指导测试工作更清晰。

培养质量意识

我们必须承认，产品质量不是由测试同学测出来的。作为项目团队成员，产品、开发和测试的作用都是独一无二，不可替代的。我们都为提升产品质量一起奋斗。然而，在实际迭代过程中，产品同学会更加关心需求的如期上线，开发同学会更加关心编码的及时完成，导致质量工作的重担向测试这一方偏移。我们也知道，忽视了前期的质量工作，在后期的测试环节甚至版本发布上线后，我们需要为之前的行为买单，耗费更多的时间和精力。

在产品日益复杂化的今天，用户需求不断增多，我们的业务 KPI 压力骤增。在如此严峻的环境下，如何能够求得质量和收益的双赢呢？“测试左移” 应运而生，但施行测试左移的一个重要前提是：团队对于质量风险前置这个认知上的一致性。我们团队主要从以下几个方向来努力培养团队全体成员的质量意识：

图 1 提升团队质量意识的五个途径

第一， 质量宣讲

首先，普及产品质量度量参数。需要知道，除了业务 KPI 数据，产品还存在质量数据。而且我们通过质量数据来度量每个业务的开发质量和需求质量。质量宣讲能够在团队内普及这些度量数据的含义，明确指出核心数据会在正式场合进行汇报。对于异常的数据会标红显示，比如严重用户反馈数、主线不通过数、交付通过率、千行代码缺陷率、引入原因分类（包括设计缺陷、编码缺陷、需求缺陷等）等维度来衡量各个环节的质量以及我们产品的整体质量。

其次，部门团队横向对比，提升产品质量的敏感度。通过团队间的横向对比，以竞争和奖励的方式来提升团队成员对质量问题的敏感度。在桌管内部，针对严重用户反馈，我们改进质量监督机制，实施研发运营质量改进积分方案；同时按业务中心进行分类，实时监控每月各业务的严重用户反馈的趋势，鼓励从流程优化上进行了质量改进的团队，刺激各团队主动提升产品质量的氛围。每半年进行一次积分排行，前三名进行奖励，非常具有吸引力。

此外，落实项目总结，避免形式化。如何避免项目总结趋于形式化，如何敦促项目总结的方案能够闭环落地，都是产品质量的重要保证。针对这块，我们巧妙地发挥了 PM 的角色价值。如果没有 PM，测试也可以发挥自己的担当力去推动。主要工作就是明确需要改进的内容，并形成明文规范存档。规范一旦建立，在后续的执行过程中，如果再犯，需要明确指出，并予以相应的惩罚。比如，SVN 提交代码需要关联正确的需求，发现关联错误必须直接打回（影响交付通过率）。

第二， 主人翁意识

团队内部施行 owner 责任制，让每一个角色都有机会感受负责人的体验。上半年我们业务团队，开发同学主动承担负责人体验。他们的责任制体现在新需求的版本迭代、crash 率、用户反馈跟进以及主线大版本合入。一般情况下，我们建议轮流交替体验。这样做的好处有三点：（一）可以通过实操的方式了解各个流程的每个细节；（二）身为 owner 必须对整体过程负责，包括不按时提测，bug 解决不及时等问题，可以有效减少过程问题；（三）可以通过过程体验，发现过程中存在的一些问题，后续主动去避免，培养良好的研发习惯。

第三， 产品走查

以前我们的产品走查总是在测试完成第一轮集成测试之后开展，现在发现完全没有必要。产品同学对客户的需求应该是最清楚明白的。如果把这个环节前置到开发提测之前，产品同学可以快速发现与需求实现不一致的地方，而且也可以将一些低级的错误在提测之前消灭掉，从而提升开发同学的交付质量，也减少了在后面匆忙走查导致的问题遗漏。

第四， 互相结盟

对于测试而言，和其他角色的结盟绝对是有利无弊的（切记：永远不要和团队小伙伴形成对立的局面）。我们可以和产品结盟，推动开发去解决体验上的问题单，提升开发的精品意识；我们可以和开发结盟，推动产品的需求文档更加规范化，便于后续的编码和测试分析；我们还可以和 PM 结盟，推动整个团队内部流程的优化。

第五， 上层推动

想要在项目团队内达成一个目标，团队内领导的支持比较关键。它能够推动产品实施过程中的问题解决。测试同学如果觉得自己号召力不够，可以求助于自己的 leader。

在团队内部，小伙伴们的质量意识提升后，彼此间的沟通也变得相对简单，而协作也相对容易执行。比如讨论质量相关的数据，他们可以抛出疑问并讨论解决；在团队内部推行一些新的研发流程的时候，产品和开发能够积极配合，并给出可行的实践方案。团队内细节上的把握让我们相信，测试工作可以逐步左移，而产品质量也能进一步提升。

制定测试策略

除了质量意识需要整个团队共同努力外，良好的测试策略也同样并不仅仅是测试角色的事情。我们必须承认，一个好的测试策略，绝对会让咱们后面的测试过程少操很多的心。

当被通知成为一个业务的测试负责人之后，我想我们的脑海里，或多或少都会去勾勒下我们将要如何把控这块业务的测试策略。本部分主要介绍游戏合作这个业务的测试策略设计。它主要包括全局测试策略和具体需求的详细测试策略。

1、全局测试策略

全局测试策略主要是从宏观上对我们的业务制定对应的测试策略。在我看来，想要从宏观上制定策略，必须要了解它的项目外向属性。而外向属性自然是包括人和产品特性，也就是团队属性和业务属性。在具体分析项目外向属性之前，我觉得首先需要对需求进行管理。因为不管是团队的人或是产品特性，最终和测试对接的都是需求，所以我们需要首先从需求上进行管理。

（1）需求管理

这里的需求管理主要讲的是需求的合理分类。它不仅有利于项目生产率的度量，还有利于测试人员实施正确的测试策略。下图展示了，我们的需求类别：

图 2 需求分类包括新需求、需求优化、技术需求、bug 转需求

我们的需求可以划分为四类：新需求，技术需求、需求优化和 bug 转需求。针对不同类型的需求，我们可以先制定它的宏观测试策略，在前期可以和开发、产品达成一致，并将其固化：

1）新需求：涉及客户端的需求，要求开发必须提供详细的技术方案，产品提测前进行走查，测试提供详细的测试分析进行评审，测试过程数据需要代码覆盖率支撑；而与客户端无关的需求，不强制要求（从另一面也反映该类需求对测试人员的能力要求不高，可以交由自己培养的合作伙伴 cover）。

2）技术需求：要求开发提供详细的技术方案，测试提供详细的测试分析，测试过程数据需要代码覆盖率支撑。

3）需求优化：不同的优化点可以采用不同的方法，需求优化包括，

4）体验上的优化：小的优化，交由合作伙伴 cover，测试 owner 采用 review 的方式；

5）运营优化：优先自动化实现，若自动化无法覆盖，需要具体分析；

6）数据上报优化：开发人员自测和测试 CR 完全 cover；

7）Bug 转需求：由开发人员自测、测试 CR 和合作伙伴回归 cover。

总体而言，技术实现上有比较大的变更时，开发人员需要提供详细技术方案；界面表现发生比较大的变化时，产品人员需求提前进行走查；其它情况优先自动化实现，不可以自动化的培养合作伙伴进行分析外加正式员工 review 的方式；以上均不是，则测试负责人再发起具体分析。

（2）团队属性

团队属性主要源于研发团队的组成、任务分工以及需求来源。一个研发团队，必然包括开发、产品、运营和测试，部分团队可能不存在项目经理。但是作为测试负责人，除了了解测试角色负责的内容，对于团队内部的其他角色必须也要非常熟悉，包括知道人员的比例，知道他们的不同分工。比如游戏合作项目，它的视图关系如下：

图 3 游戏合作团队组成

图 3 主要展示了游戏合作项目团队内部的组成，以及会直接和测试对接需求来源的关系图。从上图可见：

1）我们团队存在 1 个项目经理。项目经理可以从全局掌控项目的规划和资源的协调。在关键的时候，他可以充分发挥项目经理的优势帮助我们解决一些棘手的问题；

2）开发人员一共 11 人。从开发侧会产生技术需求或 Bug 转需求类，他们会直接对接测试人员。开发侧存在分工不同。客户端开发比较固定，需求频繁；而 web 端开发负责前端页面，属于资源池非固定人员，因此需求相对不频繁；

3）产品经理一共 2 人。从产品侧会产生新需求以及需求优化，优化主要是体验上的优化和数据上报上的优化。产品侧需求直接对接开发和测试人员。

4）运营人员一共 4 人。从运营侧会产生需求优化，但运营侧存在分工不同：活动类的运营要求对接的测试人员属于专属活动测试人员，因此无需关心；合作类分为两类合作，一类是谈到一些新的合作方式或针对已有的合作方式做一些优化，最终转换成需求会对接给产品经理（并非直接对接开发和测试），而另一类是将一些已有的合作方式运用到其它游戏会直接对接需求给到推广类；推广类主要负责运营，他会直接对接对应的开发和测试。

乍一看，整个团队 18 个人，测试只有 1 个人，测试开发比是 1：11，亚历山大。但了解团队的组成，以及各个人员的分工后，发现并没有想想中的严峻，因为实际常规开发的共 7 个人（6 个客户端 +1 个 web 端），1：7 还是可以应付的。

从上图，我们也知道：和测试直接对接需求的人员除了开发人员、产品经理，还有负责推广类的运营人员。我们在进行需求沟通时，包括针对需求的排期、需求的测试策略，需要找到正确的人。

（3）业务属性

业务属性主要源于分析业务的需求属性。游戏合作的业务划分如下图所示：

图 4 游戏合作业务属性宏观测试策略

游戏合作大致包括 7 个特性，还有 1 个特性是待开发的区域。开发、产品、运营人员在针对对应特性建立需求的时候，尽量按照我们的需求分类存放到需求池。对于不同类别的需求，我们首先采用该需求类型对应的宏观测试策略，接着针对具体的需求点再做详细的测试分析。如果需求策略需要做出调整，对应的发起人提前说明，这样不仅有利于测试人员进行测试分析，也有利于需求提测后可以得到及时的测试响应，避免由于测试资源紧张要依赖固定的负责人去处理对应的需求。

2、详细测试策略

详细测试策略，主要对具体的需求进行详细的测试分析，制定策略。针对具体需求的详细测试策略，每个团队可能不一样，在我们的团队，测试策略设计模型如下图所示（对这部分感兴趣的，可以线下沟通）：

图 5 详细测试策略设计模型

从左至右，依次是需求分析，开发实现分析，基于这两点得到测试分析点。里面有提到模型，关于测试建模可以参考我的另一篇文章《再不测试建模你就 out 了》。

总结

按照目前实施的游戏合作测试过程管理方法，游戏合作业务今年上半年的质量尚可，漏测率为 0，严重用户反馈为 0，千行代码缺陷率维持在 3 左右，其它核心质量指标数据也无异常。还有一点需要提下，就是当日常测试工作中遇到多个需求并行的时候，我们可以使用四象限法则（通过优先级和重要性）来排序，通过 PM 来帮助我们协调。在后续的测试过程中，如果团队或业务属性有大的变化，我们再灵活调整进行适配。原则上，整个项目可以和谐的运作，共同缔造高质量的产品。

本文主要从五个途径介绍了如何培养团队的质量意识，以及如何把控业务的测试策略。文中所提到的方法，主要是基于我自身实践感觉有价值的分享点，当然不能以偏概全。在后面的测试过程管理中，我们还需要更多的思考、实践来丰富完善。如果你看完之后，能够得到一些测试过程管理上启发，它便发挥了它的价值。期望对于想要改进测试过程的你有一些帮助，也期望对于即将走上测试岗位的小鲜肉有一些帮助。

获取更多测试干货分享,请搜索微信公众号：腾讯移动品质中心 TMQ！