相信对于很多人来说，“降本增效”一词已经不绝于耳、烂熟于心了，而对于质量工作者而言，“提质”更是我们工作过程中需要保障的至关重要的一环，那么如何同时做到质量工作的提质降本增效呢，当然解决方案有很多，从质量保障的多个维度可以成立非常多的专项去实现，本文主要从质量保障的最基础却也是最核心的测试阶段具体执行工作聊起。

一、背景

为什么想写这个主题呢，出发点有两个：

其一：最近两年致力于研发流程的改进工作，经过多个迭代的优化升级，网易支付研发流程基本实现了80%的线上化，但是一直令我耿耿于怀的是，作为QA人员，测试阶段最基础的本职工作线上化流程始终不够理想，各环节严重断层，具体现象下文详述；

其二：在针对网易支付线上问题产生的原因归类中，有这几项：测试用例遗漏、用例执行错误、用例评审执行不到位、未考虑回归场景、测试范围覆盖不全面，而且这几项原因出现频次还不低，说明测试的基本工作没做到位。

二、现状问题

目前QA这个角色的定位是负责质量保障工作，而质量保障的内容非常丰富，这里我们抽丝剥茧，抽离出质量保障体系中最基础的部分，即：测试准备、测试设计、测试评审、测试执行、测试报告这部分内容，如下图所示：

测试阶段各环节需要完成的事项包括：

测试准备环节：主要是需求了解阶段，包括参加需求评审及设计评审等，在这个阶段一般通过文档阅读或评审会议形式，以便相关方能迅速熟悉需求；

测试设计环节：需求相关的测试人员根据需求文档及相关设计文档编写测试用例；

测试评审环节：根据测试用例评审规范，依据不同类型需求，安排测试评审；

测试执行环节：分为冒烟测试用例执行及全量测试用例执行；

测试报告环节：一般情况下，日常迭代需求无需发送正式测试报告，项目级别根据需要发送正式测试报告；

这几个环节，相信对于任何一位测试工作者来说，都是非常耳熟能详的了，测试阶段步骤清晰，过程简明，但是实际执行效果却并不理想，在落地过程中多少会产生各种各样的问题，例如前文背景中提到的线上原因归类的几个问题就是很好的例证。

那么接下来结合我们具体业务来阐述我们的实际执行过程，以及由此带来的问题：

1、测试准备环节，需求方及研发人员会安排需求评审及设计评审，这一环节流程比较固定，视需求复杂性采取线上文档或线下会议形式，这一环节主要任务是解决共识问题，需求相关方对该需求达成一致性认识，在这一环节最可能产生理解性偏差问题；

2、测试设计环节，在完成上述测试准备环节之后，进入测试设计环节，这一环节测试人员按自己对业务需求的理解产出所有测试用例，包括需求本身涉及的测试用例以及可能受到需求影响的相关业务的回归测试用例，同时需要标记冒烟测试用例供研发人员自测使用，对于测试工作人员来说，这一环节至关重要，需求理解是否准确，测试用例是否完整，回归范围是否全面，在一份测试用例文档上展现得淋漓尽致，好的测试用例属于非常优质的测试资产，需要持续积累沉淀，但是可惜，我们在这方面的有效积累较为欠缺，主要原因我认为有以下几个方面：

第一，测试设计过程未统一且具备强个人相关性，主要表现在用例编写工具多样性，目前广泛使用的测试用例编写工具是xmind，但也有部分测试用例使用的是杭研测试服务的用例管理平台（https://tc.hz.netease.com/），这两款工具各有优劣，xmind编写测试用例更为灵活便捷，但在协作与共享方面效果不理想，tc平台实现了协作与共享方面的能力，但在用例编写、扩展与可读性方面效果欠佳，两款工具均非最佳实践，只能视具体情况具体使用，最终结果就是线下xmind文档由各QA人员独自维护，部分线上用例通过tc平台维护，缺乏统一维护渠道；

第二，通用测试用例的可复用性及扩展性不佳，基于上述第一点原因，xmind用例文档由测试人员独自编写并保存在本地，tc用例平台上的用例按发布版本维度维护，对于同一个功能点，如果经由不同人员测试，则无法复用其他人编写的用例，最终导致同一个功能的部分用例重复，且针对同一个功能，多人维护不同的用例，对用例的完整性没有保障，在设计时可能造成测试点的遗漏；

第三，用例检索非常不便捷，如测试用例通过线下维护，则需要沟通共享用例，如通过tc平台维护，则需要先找到对应需求，然后查找关联发布版本，再找到对应测试用例，大大增加用例检索复杂度，降低检索效率；

3、测试评审环节，主要内容是测试用例评审，这一环节是解决需求理解性偏差问题的关键步骤，也是提升用例完整性的一道关键屏障，为了提升用例评审质量，我们特意设计了测试用例评审规范，其中包括引入交叉评审机制以及严格的评审步骤，当然规范的引入必然以牺牲效率为代价，如何同时把握质量与效率，找到平衡点是个关键，最终执行结果表明，按目前的评审规范操作，成本偏高，复杂度偏大，最终评审效果也大打折扣，评审质量未达预期， 举个例子，关于用例评审规范的部分内容如下图：

4、测试执行环节，主要是用例执行，分为冒烟用例执行和全量用例执行，测试人员准予需求提测的卡点之一是开发自测通过，衡量自测通过的标准为冒烟用例全部执行通过，QA需要为开发提供冒烟用例，按照日常流程，QA需要把测试用例导入tc平台，筛选出冒烟用例，生成冒烟执行集，供开发人员执行，QA根据执行结果决定提测准入与否；而全量用例执行由QA人员自行完成，可以选择在tc平台创建执行集或者直接在xmind文档标记结果，执行结果由执行人员自行保障，这里缺乏完整的监控机制；

同时，这一环节操作步骤较为繁琐，tc平台对xmind文档的解析要求满足模板格式，否则可读性非常差，而按模板调整的结构失去了一定灵活性，部分结构无法适配正常认知特性；

综上所述，因为测试设计平台的多样性、用例存储的线下化、评审环节操作的复杂性、以及测试执行的独立性，导致测试阶段各环节严重断层，缺少关联关系，且大多数场景均在线下完成，无法实现测试用例这种QA内部优质测试资产的持续沉淀。

三、解决方案

如果说测试阶段以测试用例为核心，那么关键活动分为：用例编写→用例评审→用例执行→用例沉淀，如何保障这几个活动的最优化实现，是我们需要思考的方向。

经过分析，得出结论，我们希望有这样一个平台，具备如下特性：

1、实现连结，能够建立测试阶段各环节的串联关系；

2、实现团队协作与内容共享；

3、所有操作均可线上化；

4、适配现有操作习惯，降低迁移成本；

5、实现测试用例的可持续积累；

经过调研，我们引入了一款宝藏平台，由网易游戏质量保障中心研发的产品（evolute）可以很好的解决我们遇到的各种问题，且具备上述特性。

evolute支持的基本功能如下图：整合了用例编写（用例管理）、用例评审（review管理）、用例执行（测试任务）等多个功能，满足关键活动一站式管理需求；

用例管理模块，完全适配大众日常操作习惯，编写方式与xmind基本一致，支持线下文档上传解析（如图一），同时也支持线上文档导出为线下xmind文件，并且用例编写支持多人协作（如图二），同时，为满足通用用例沉淀需求，可以使用模板管理功能（如图三）：

图一

图二

在用例管理模块，关键词搜索功能也非常强大，针对同类功能，通过搜索可以查找到关联用例，避免重复编写造成冗余，如下图：

用例评审过程，QA人员发起review后，被邀人员需要在规定的时间内操作review，所有review列表均有参与人员及状态跟踪，如未在规定时间内完成将置为已失效或已逾期，review状态列表如下图所示：

review人员对有异议的测试用例做出标记并添加批注，完成后点【我已review】，提交review结果；

review人员完成用例review后，用例修订人员需针对review结果进行确认，如需调整用例，则完成修订，修订完成后，修订结果会更新到主用例集；

用例评审完成后，进入执行环节，根据不同执行类型，可以创建不同测试任务，日常最典型的测试任务分为冒烟用例执行任务及全量用例执行任务，每个独立测试任务均有测试进度条，可以实时跟踪用例执行进展。

最后，平台的数据统计中心可以展示整体数据情况：

四、效果

从支持业务发展的质量保障角度来说，如果能同时满足提质降本增效这个黄金三角需求，则说明解决方案具备一定的实现价值；

提质效果：从两个维度看，用例本身的质量以及用例评审的质量，多人协作与用例共享提升了用例可复用性， 所谓众人拾柴火焰高，通过持续积累不断保障用例完整性，相比个人线下维护单点用例，用例质量会逐步提高，同时完整性得到保障；另外，用例评审参与人非常明确，评审过程也全程透明，是否参与过评审，是否提交过评审记录，整个过程一目了然，即使未发起正式评审会议也能追踪到实际评审结果，避免评审过程流于形式，部分参与人蒙混其中，评审质量及效果得到较大提升；

降本效果：从成本角度考虑，主要是人力投入成本及使用成本，以及习惯迁移成本，人力投入成本主要包括前期调研、平台问题沟通成本，使用成本主要体现在团队成员使用该平台的准入门槛，习惯迁移成本主要体现在源用例活动的所有操作习惯迁移到新平台以及适应过程，因平台用例编写方式符合xmind风格，在使用成本及习惯迁移成本方面经过一个迭代版本的试用阶段基本可以解决，平台调研及问题沟通投入一个对接人力即可，相对原用例活动使用习惯，在用例维护成本、多平台操作成本、线下互动成本方面提升明显；

增效效果：测试阶段以用例为中心的各项活动通过线上平台一体化管理，节约了线下分步操作时间，平台的进度跟踪、数据统计功能让相关方能实时查阅数据，省去沟通环节，提升协作效率。

其实，真正有价值的效果评判标准应该是对本文在背景中提到的线上问题产生原因的那几类问题的解决能力，但因我们使用该平台时间尚短，目前仍处于过渡期，缺乏横向对比数据支撑，暂不纳入评判范畴。

最后，分享我们部门在引入该平台之后的整体数据情况，该平台从11月开始以一个研发项目为契机正式引入到项目过程中，从项目维度来看使用过程较为顺畅，之后逐渐渗透到其他项目，目前已覆盖到70%+的产研人员，下图是团队使用整体状况。

-- End --