质量是决定产品能否成功、企业能否持续发展的关键因素之一。如何做好质量体系建设，这是个比较大的话题，包含的范围很广，也没有固定的衡量标准。

打开一个互联网公司招聘网站，搜索「测试工程师」岗位时，你会发现几乎全部 JD 都包含一条要求「建设或者参与建设所负责业务的质量体系」。那么，是不是谈到质量保障就只是测试团队的职责？测试团队在这个过程中如何发挥价值？本文将结合马蜂窝大交通测试团队在质量体系从无到有搭建过程中的实践，来谈一下对质量体系建设的看法和理解。

质量管理的常见误区

在谈到质量管理的时候，很多团队在开始时会容易进入几个误区：

测试环节再关注

在实际项目中，很多时候都在测试阶段才发现大量实现类 bug，测试人员每天拉着研发修 bug；要么就是在临近上线的时候发现了一个重大问题，导致修复验证时间不够，但又只能「硬着头皮」上线。质量保障是要贯穿项目实施从需求提出到研发到测试全阶段的，如果到测试环节才来关注，已经晚了。

质量保障是 QA 的事

有了良好的质量我们才能提升用户体验和留存率。和第一个问题相类似，很多人会认为质量只是 QA 的事，和其他角色没有太大的关系。而实际上，软件的质量是在整个研发过程中逐步形成的，离不开 QA 团队，但只靠 QA 团队关注肯定是不够的，业务中的全部角色都需要提升质量意识：开发要增强自测；产品要提前规划和测试好要上线的内容，当在质量和上线时间发生冲突时应该首选质量；运营同学对自己配置的运营页面要经过测试后再上线等等。

测试人员不需要懂代码

在开发快速迭代的环境下，对测试工作的技能要求越来越高，测试和开发之间的合作更加快速紧密。全手工测试的方式主要有两个问题，一是时间成本高，无法满足当前快速迭代的需求，而且容易出错；二是测试人员自身的技术水平得不到提升，成长性受限。

除了手工测试之外，需要根据业务和团队的需要适时开展接口自动化、UI 自动化、Code Review 等提升效率的工作。两者有效的结合才是测试质量保证的关键。

正常上线就大功告成

一个项目从需求提出、开发、测试、发布只是走完了线下流程，虽然系统经过了严格的测试，但是毕竟线上的情况和场景会更加复杂多变，上线后才是真正经受线上用户考验的时候，我们必须关注线上日志、用户反馈、线上报警等，及时修复线上问题，并将用户提出的合理化建议转为产品优化或产品需求并实现，形成整个闭环。

大交通研发质量体系建设

为了帮助用户更好地完成消费决策闭环，马蜂窝上线了大交通业务，为用户提供购买机票、火车票等服务。为了提升系统的稳定性、更好地支持高并发，大交通将原有 PHP 架构的交通业务重构成支持高并发和更稳定的 Java 集群架构，同时逐渐将各模块的业务容器化，来提升系统的整体性能并且可维护。

大交通测试团队主要负责机票、火车票和用车业务的测试。为了避免上面说的四个误区并结合研发团队的具体情况，大交通研发质量体系建设主要是从项目流程、业务测试、线上事件和工具建设四个方面来进行的。现阶段质量体系建设的目标有 2 点：

缩短线下项目的工期，减少线下 bug 数量
减少线上问题数量

质量体系大盘如下图所示，其中虚线框中的部分是规划中或者正在进行中的，实线框中的部分已经完成。

1. 管控项目流程，提升交付质量

产品的质量不是依靠一个团队或一个阶段就可以保障的，需要在研发的整个流程、每一个阶段进行控制和管理。

1.1 分类需求，明确项目周期

大交通业务从无到有，业务功能开发需要具有快速迭代和交付的能力，目前采用的是双周迭代模式，挑战性是比较强的。为了在项目快速上线的同时保证质量，我们按照需求的不同类型和等级梳理了交付的核心时间节点。

目前大交通客户端页面较少，大多为 H5 前端页面。以双周迭代为前提，需求一共分为 3 类：

日常 - 开发工期较短，1 个迭代内完成。
项目 - 开发工期 3 天以上，大约 2 个迭代内完成。
线上事件 – 计划外的突发状况，通常来说紧急程度高，可能会直接影响线上业务，需要及时响应。

需求包含产品需求和技术需求。为了合理安排开发资源，日常需求和项目需求进行双周 PK，根据项目价值、优先级、资源情况等确认后续 2 周的需求范围。日常、项目主要流程如下图所示：

1.2 项目进度可视化管理

要缩短交付周期，如何让团队更好的协作，敏捷的推进产品研发是需要考虑的问题。整体思路采用 SCRUM 敏捷的方法论来推进，此类落地工具有很多，我们选择的是 TAPD 来管理整个研发生命周期。比如用故事墙对大型项目的迭代规划状态进行可视化管理；对于专项任务使用看板进行阶段性同步等，透明团队工作，让每个角色都能对进度直接负责，提升协作效率。

1.3 持续集成工作流

Bug 发现的时机越晚，修复 bug 所需的时间就越长，项目工期就越长。为了提升每一个环节的交付质量从而减少线下 bug 和加速项目进度，我们在流程中针对各角色逐步推进了以下机制：

i）**针对产品和 UI **，我们约定需求 PK 通过后 3 天内进行需求评审，提升需求的交付速度；开发联调结束后和提测前参与 Show Case，第一时间验收产品。

ii) 针对研发，在测试环境 CI/CD 中加入了 Sonar 静态代码扫描，只有通过质量阀后才能部署；联调结束后运行自测用例并将结果标注在用例管理工具中；并组织 Show Case，给产品、运营、测试展示主流程。

iii）针对测试，将测试用例评审时间提前，尽量跟开发技术方案评审时间一致，在提测前 2 天就开始部署隔离的测试环境供开发连调和自测。

（隔离的测试环境是为了多项目并行而使用，会在后续章节中详细介绍。）

iv）运营同学提出的需求，会在 Show Case 时邀请运营第一时间参与产品验收。

1.4 培养全员项目管理意识

大交通技术团队目前没有专职 PM，所有项目的 PM 均为技术兼职。为了保障所有日常和项目均能如期甚至提前完成、更好的让项目流程落地以及优化项目流程，由测试团队负责人等 3 人兼任 PMO，针对项目流程中的问题为研发和产品同学进行分享和培训，提升研发人员的项目管理能力和产品同学的流程意识。

良好的项目流程制定和优化、项目流程落地、每个环节负责人都高质量地交付给下一个环节的负责人，是保障产品质量的第一步。

2. 加强业务测试，实现功能保障

业务规模快速发展，业务逻辑越来越复杂，系统级别交互越来越多，都给测试团队带来极大挑战。大交通测试团队内部主要是从 5 个方面来提升业务测试能力：

2.1 熟悉业务流程和功能

对于测试人员来说，熟悉业务流程、功能等需求，才能打开思维，在测试过程中做到有的放矢。比如大交通的机票业务对基础数据准确性要求很高，还有虚仓、改签、航变、运价、值机等特有的功能，这些都需要测试人员去深入了解。我们会非定期邀请产品、运营同学进行机票业务的培训，同时测试也会给开发同学反讲和培训一些业务。

随着团队新人的加入和系统越来越多以及越来越复杂，为了避免漏测，我们启动了梳理各业务功能、功能入口矩阵图的工作。举个例子，机票保险除了 C 端用户页面，运营后台和供应商后台也有相应功能，那么机票保险相关的业务我们需要把全部入口都考虑到。矩阵图给技术方案评审、测试计划和测试方案制定提供了指导性意义。

2.2 阅读后端代码

作为系统测试工程师，不需要对开发代码了如指掌、掌握每一个方法，但是适当的阅读代码和代码的逻辑是有必要的。

大交通研发后端代码以 Java 为主，在熟悉业务的前提下，有 Java 代码基础的测试人员每个季度都会设定阅读后端微服务代码的绩效目标，阅读代码、搞清微服务、数据库或缓存、定时任务之间的调用关系、沉淀成文档、并反讲给编写该微服务的开发，由开发来判断阅读效果。读完部分甚至全部代码之后，后续的新项目中可以更加自如地从头把控产品质量，如技术方案是否合理、对增量代码进行 Code Review 提前发现 bug、协助开发定位问题原因，并推动开发在编码前进行技术方案、接口协议、数据库评审。

下图是机票测试同学阅读机票接入基础数据相关代码时梳理的部分流程图：

2.3 测试覆盖率统计

覆盖率是度量测试完整性和有效性的一个常用手段。在大交通业务体系中，有些项目的逻辑分支非常复杂，为了评估手工、接口自动化、UI 自动化等黑盒测试手段是否能覆盖全部代码逻辑分支。近期我们启动了增量代码覆盖率统计项目，目前在小型项目中试用，一轮测试完成后查看覆盖率统计数据，在二轮测试中则重点覆盖第一轮中未涉及的部分。

有时候某些逻辑分支构造测试场景非常困难，这时需要引入 Code Review 等手段来进行覆盖。需要注意的是，即使把增量代码百分百覆盖掉，也不代表就万事大吉了，有时候开发会漏开发某部分代码，这种情况下最好的情况是在技术方案评审和结合功能矩阵图来设计测试用例时发现，但我们建议在测试后期仍要再来审视一次是否有遗漏开发的情况。

除了增量代码测试，每次项目上线前还需要对业务主流程进行回归测试。

2.4 推进项目自测

大交通有些较为简单的日常和项目测试没有介入，采用开发自测+产品验收后直接上线的模式。测试同学不定期会给开发和产品同学培训测试基础知识，比如：部署隔离的 Java 测试环境、部署 PHP 代码，前端微服务切换、Mock 平台使用等，有些项目测试也会提供测试用例由产品来执行，通过培训使没有测试介入的项目也能够保证质量。

2.5 数据统计分析

在推进代码质量时，我们以月为单位需对项目和 Bug 进行数据汇总，并通过对数据进行分析，发现和总结项目过程中的问题及产生原因，针对问题提出项目目优化和质量提升建议并在项目组中推动施行。

月度报告关注的是项目质量往更优发展，而不是统计本身。通过数据展示，大家也可以知道我们的项目质量在持续提高，比如在多个机票大项目并行的情况下，大交通今年 Q1 的线下 bug 总数比去年 Q4 下降了 1/4, 通过数据大家可以感受到项目的整体质量越来越好，也是对团队很好的鼓舞。

3. 关注线上，形成问题闭环

在文章最初部分我们讲过只关注线下是不够的，必须要关注线上，将线下和线上结合在一起形成闭环。大交通在线上问题的发现、处理、汇总上主要做了以下几个方面的工作：

3.1 标准化反馈流程

测试团队制定了一套完整的线上问题处理和反馈机制，明确工作流，并借助工具（TAPD）落地。

内部用户和外部客服人员反馈问题后，由运营、产品统一记录到 TAPD 中，由技术支持人员过滤问题，复现并确认问题是否有效，如果有效则判断问题类型：如是咨询类问题，则技术支持直接回复；如是 bug（即线上故障），则转交开发解决；如是产品改进，则转交产品记录。遇重大问题开发则通知 Team Leader 关注。无论何种类型的问题，都会在 TAPD 流转，直至问题问题报告人验证并关闭。最终，处理结果将反馈至内外部用户。

高优先级问题会被优先处理，处理完毕后也会尽快组织故障 Review。

3.2 主动发现问题

除了线上报警外，技术支持也会定期巡检各业务，预防重大线上问题发生，并通过数据大盘、数据库异常数据、小时报等异常数据来主动发现线上问题并推动解决。

3.3 质量会议

每周固定召开质量会议，由技术支持发起，开发、测试、产品、运营参加，对上周的线上问题逐个进行 Review，故障类问题分析原因、以点带面将类似问题全部解决；咨询类问题转需求和运营工具、释放人力；产品缺陷类转为产品需求。每月初的质量会议也会对上月的线上问题进行整体 Review，针对问题提出质量建议并推动落地。

目前大交通的线上故障月度数据呈下降趋势，与线下项目质量提升、每周的质量会议和全员质量意识培养密不可分，并且随着产品改进类需求上线，用户体验也越来越好。

4. 完善工具建设，提升测试效能

只有手工点点点是远远不够的，结合大交通的实际业务场景，测试团队的工具建设主要围绕环境支撑、压力测试、测试平台、UI 自动化、接口自动化等方面展开。

4.1 环境支撑

无论 Code Review 做得多么完美，最终都需要进行集成测试。良好的测试环境是对测试效率和项目质量的保障，同时测试环境适合与否会对测试结果的真实性和正确性很重要。

大交通的测试环境共有 3 套：Dev 环境、QA 环境、预发环境。之前测试环境出现过一些较明显的问题，比如：

在抢占开发 Dev 环境的情况下同时最多只能测试两个 Java 代码变更项目（QA 和 Dev 各测试一个），严重影响效率。
QA 环境上频繁部署引起测试中断。
QA 环境上出了真实的票产生了资损。
Dev 环境上开发自测的很完美，但提测后部署到 QA 环境之后连主流程都不工作。

为了解决以上问题，我们进行了测试环境改造及预发环境打通。

4.1.1 测试环境改造

针对以上问题，我们将提升测试环境的稳定性、并行性、隔离性、实时性作为重点指标进行测试环境改造：

相对稳定性：

- QA 有需要时部署

- Java 代码：回收开发同学 Jenkins 权限

- PHP 代码：推动公司 PHP 部署平台（AOS）进行改造，只有 owner 和分享的人才能部署
并行性：

- Java：所有微服务均引入测试环境隔离插件，同时支持多项目并行测试
隔离性：

- 测试环境的订单不能出到线上

- 机票接入：订单拦截
实时性：

- 除被测代码外，其他代码也要实时更新。

良好的测试环境有力的保障了多项目并行开发、连调和测试。提测前 2 天测试同学就开始协助开发部署项目隔离环境，开发在隔离环境中连调和自测，自测通过后测试同学直接在该项目隔离环境进行测试，大大节约了从 Dev 到 QA 的转换时间。

4.1.2 预发环境打通

大交通测试环境中的数据库、MQ、Redis 等中间件跟生产环境是分开的，账户是虚拟账户，出的票是模拟票，因此测试环境跟生产环境还是有很大差距的。过去测试环境结束后直接上线的项目中，有些服务上线后连启动都是失败的。

为了能在更加接近生产环境的条件下进行测试，提高一次上线成功率，我们启动了打通机票、火车票预发环境的技术项目，对预发环境我们的定位是：

上线前预演
真实账户、真实交易
代码与生产隔离

机票火车票的预发环境全部打通后，全部项目在测试环境结束后上预发进行主流程回归，然后上线。

目前采用的测试流程如下：

4.2 压力测试

在高并发的场景的搜索类项目和活动类项目中，我们进行压力测试。压测流程如下图所示。这里可以参考之前马蜂窝技术公众号发布过的一篇关于压力测试的文章，在此不过多展开。

4.3 测试平台

测试平台是大交通测试的门户网站，大交通研发业务线后端使用 Java，前端统一使用 VUE，为了让大家更快地熟悉大交通研发技术栈，测试平台采用了跟研发前、后端一致的架构。

测试平台的最终目标是将团队开发的工具，如代码覆盖率统计、数据工厂、压测结果展示等整合在一起，后续计划把接口自动化、UI 自动化等功能逐步加入，逐步完善测试平台功能，并以界面化的形式开放给团队内外部人员使用，提升测试效率。

4.4 数据工厂

数据工厂基于大交通测试平台开发。在一些逆向交易的需求测试中，需要先创建不同类型的订单作为测试前提，如果从前端下机票订单的话，一共需要操作5步：首页->列表页->报价页->订单填写页->乘机人选择页。为了简化创建订单的步骤和方便产品验收以及外部团队回归使用，我们设计并实现了机票数据工厂，希望可以实现国内国际机票测试一键生单，向研发、测试快速提供订单数据，为测试环境回归提供数据。

大交通机票测试环境中除了项目隔离环境外，还维护了一套稳定的主干环境，该环境中代码基本和线上保持一致，数据工厂基于主干测试环境来创建机票订单。

目前数据工厂一共分为四个模块：国内/国际机票生单模块、模拟支付模块、出票模块和日志记录模块。四个模块和机票服务端的调用关系如下图所示：

目前数据工厂实现了生单、模拟支付、出票和操作日志等功能，填写了参数之后，在前端页面直接点击相应按钮就可以了。

4.5 接口自动化

接口自动化的好处不言而喻，我们采用的是比较通用的接口自动化框架 TestNG+Rest-assured+Maven，目前在 Jenkins 上配置运行，后面要对接到测试平台。

目前覆盖主流程的回归测试用例在测试环境定期运行，搜索类接口的自动化在线上定期运行进行监控，有异常时会发邮件报警。除此之外接口自动化还用于数据创建、主流程回归和迁移类项目测试中。

遇到的一些困难

在搭建质量体系的过程中，我们也遇到了一些困难：

1. 流程改进中的困难

比如 Sonar 静态代码扫描的引入。之前 Sonar 只是放在了 CI 平台并没有跟 CD 绑定在一起也没有引入质量阀，需要专职人员来督促开发进行扫描和检查扫描结果，引入静态代码扫描的效果并不是很好。

为了让 Sonar 自动的发挥它的代码检查效能，我们将 Sonar 引入测试环境 CD 平台，制定了统一的质量阀，Sonar 扫描不通过质量阀的就无法部署到测试环境，最初以一个项目为试点启用、发现问题和解决问题，现在全部项目在提测前都需要通过 Sonar 代码扫描并通过质量阀，通过之后才可以提交测试。

2. 业务测试和工具开发时间冲突

大交通没有专职的测试开发岗位，发生冲突的情况下优先保障业务测试，业务测试间隙期来做工具开发工作，在这样的情况下有一些跟业务测试结合比较紧密的自动化工作开展的比较缓慢，目前我们的接口自动化只覆盖了核心回归用例，后面需要把接口自动化和大多数项目测试结合在一起，真正把接口自动化应用于项目测试中。

总结

大交通测试团队成立了不到一年，经过一段时间的摸索和实践，在研发质量上有了一定的提升，但我们在质量体系建设的道路上才刚刚起步。随着业务系统越来越复杂，对测试人员和质量体系的要求也会越来越高，也需要全体成员不断提升质量思维、持续追求质量。未来，我们将不断积累方法、优化流程和完善工具，保证高质量的持续交付。

本文作者：孙海燕，马蜂窝大交通业务测试专家、大交通测试团队负责人。

（题图来源于网络）

关注马蜂窝技术，找到更多你想要的内容