马蜂窝大交通业务质量体系建设初步实践

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

打开一个互联网公司招聘网站，搜索「测试工程师」岗位时，你会发现几乎所有 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. 业务测试和工具开发时间冲突

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

 

总结

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

 

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

（题图来源于网络）

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