质量是决定一个产品成功与否、企业可持续发展的关键因素之一。如何做好质量体系建设是一个比较大的课题，涉及面广，没有固定的衡量标准。当你打开互联网公司招聘网站搜索“测试工程师”职位时，你会发现几乎所有的JD都包含了“负责业务的质量体系建设或参与建设”的要求。那么，在质量保证方面是否只是测试团队的责任？测试团队如何在此过程中增加价值？本文将结合马蜂窝流量测试团队在从无到有的质量体系建设过程中的实践，谈谈对质量体系建设的看法和理解。质量管理的常见误区谈到质量管理，很多团队一开始往往会进入几个误区：测试过程以实际项目为中心，很多时候在测试阶段就发现了大量的实现bug。拉动研发来修复错误；或者在即将上线时发现重大问题，导致修复和验证时间不足，只能“硬着头皮”上线。质量保证必须贯穿项目实施的整个阶段，从需??求到研发再到测试。如果只关注测试环节，就来不及了。质量保证是质量保证的问题。只有质量好，才能提高用户体验和留存率。和第一个问题类似，很多人认为质量只是QA的问题，和其他角色关系不大。其实，软件的质量是在整个研发过程中逐渐形成的，离不开QA团队，但光靠QA团队的重视肯定是不够的。业务中的所有角色都需要提高质量意识：开发要加强自测；产品要上线的内容要提前规划和测试。当质量和上线时间发生冲突时，质量应该是第一选择；运维同学上线前必须对自己配置的操作页面等进行测试测试人员不需要懂代码在快速开发迭代的环境下，对测试技能的要求越来越高，测试和开发的配合也越来越快和更近。手动测试方法存在两个主要问题。一是时间成本高，不能满足当前快速迭代的需求，容易出错；二是测试人员技术水平无法提升，增长有限。除了人工测试，还需要根据业务和团队的需要，进行界面自动化、UI自动化、CodeReview等工作来提高效率。两者的有效结合是测试质量保证的关键。正常上线就完成了。一个项目只经历了需求提出、开发、测试、发布的线下流程。虽然系统经过了严格的测试，但毕竟线上情况和场景会更加复杂多变。测试在线用户时，要关注在线日志、用户反馈、在线告警等，及时修复在线问题，将用户的合理建议转化为产品优化或产品需求并落实，形成一个整体封闭环形。为了帮助用户更好地完成消费决策闭环，马蜂窝推出了大交通业务，为用户提供购买机票、火车票等服务。为了提高系统的稳定性，更好的支持高并发，大同将原有PHP架构的流量业务重构为支持高并发、更稳定的Java集群架构，并逐步将各模块业务容器化，完善系统整体性能和可维护性。大流量测试团队主要负责机票、火车票、汽车业务的测试。为避免上述四个误区，结合研发团队的具体情况，大同交通研发质量体系建设主要从项目流程、业务测试、线上活动和工具建设四个方面进行。现阶段质量体系建设的目标有两个：缩短线下项目建设周期，减少线下BUG数量，减少线上问题数量，实线框内的部分已经完成。1.控制项目过程，提高交付质量。产品质量不能靠一个团队或一个阶段来保证。需要在研发的全过程和各个阶段进行控制和管理。1.1对需求进行分类，明确项目周期。交通业务从无到有，业务功能的开发需要快速迭代交付的能力。目前采用双周迭代模式，难度较大。为了在项目快速上线的同时保证质量，我们根据不同类型、不同层次的需求，梳理出核心交付时间节点。目前大同客户端页面很少，大部分是H5前端页面。基于每两周迭代一次的前提，将需求分为3类：每天——开发周期相对较短，1次迭代内即可完成。项目——开发周期超过3天，大约2个迭代完成。在线事件——计划外的紧急情况，通常具有高度的紧急性，可能直接影响在线业务，需要及时响应。要求包括产品要求和技术要求。为合理安排开发资源，将日常需求与项目需求进行为期两周的对比，根据项目价值、优先级、资源情况确定后两周的需求范围。项目日常主要流程如下图所示：1.2项目进度可视化管理要缩短交付周期，如何让团队更好地协作，敏捷地推进产品开发，是需要考虑的问题。整体思路是由SCRUM的敏捷方法论推动的。这样的登陆工具有很多。我们选择TAPD来管理整个研发生命周期。例如，利用故事墙可视化管理大型项目的迭代规划状态；利用看板进行特殊任务的阶段性同步等，团队工作透明化，让每个角色直接负责进度，提高协作效率。1.3持续集成工作流程越晚发现bug，修复bug的时间越长，项目工期越长。为了提高每个环节的交付质量，减少线下BUG，加快项目进度，我们针对流程中的每个角色逐步推进以下机制：i)对于产品和UI，我们同意在需求PK通过后3天，提升需求交付速度；参与开发联调后测试前的ShowCase，尽快对产品进行验收。ii)研发方面，在测试环境CI/CD中加入Sonar静态代码扫描，通过qualityvalve后才能部署；联调后，运行自测用例，并在用例管理工具中标记结果；并组织ShowCase，展示产品、运营和测试的主要过程。iii)测试方面，提前测试用例评审时间，尽量与开发技术方案评审时间一致，测试前2天开始部署隔离测试环境进行开发自测。（隔离测试环境用于多项目并行，后续章节会详细介绍。）iv）对于运维同学提出的要求，第一时间邀请运维参与产品验收在展示案例期间可能。1.4培养全员项目管理意识。目前交通技术团队没有专职PM，所有项目的PM均为技术兼职。为确保所有例程和项目都能如期甚至提前完成，更好的落实项目流程，优化项目流程，测试组长等三人同时担任PMO，与大家分享讨论研发和产品学生在项目过程中遇到的问题。培训提升研发人员的项目管理能力和产品学生的过程意识。良好的项目流程制定和优化，项目流程的实施，每个环节负责人对下一环节负责人的高质量交付，是保证产品质量的第一步。2、加强业务测试，实现功能保障。业务规模的快速发展，业务逻辑越来越复杂，系统级的交互越来越多，这些都给测试团队带来了巨大的挑战。大流量测试团队主要从五个方面提升业务测试能力：2.1熟悉业务流程和功能对于测试人员来说，只有熟悉业务流程、功能等需求，才能在测试过程中思路开阔、有的放矢。比如大通运输的机票业务，对基础数据的准确性要求很高，还有虚拟仓库、改票、改签、运价、报到等独特功能，这些都是需要测试人员深入理解。我们会不定期邀请产品和运营学员进行机票业务培训。同时，考试也会对开发学员进行一些业务培训。随着团队新人的加入，系统的数量和复杂度越来越高，为了避免漏测，我们开始了整理各个业务功能和功能入口的矩阵图的工作。例如，除了机票保险的C端用户页面，运营后台和供应商后台也有相应的功能，所以我们需要考虑机票保险相关业务的所有入口。矩阵图为技术方案评审、测试计划和测试计划制定提供指导。2.2阅读后台代码作为系统测试工程师，不一定要熟知开发代码，掌握每一种方法，但需要正确阅读代码和代码逻辑。大同研发的后台代码主要是基于Java的。有Java代码基础的测试人员在熟悉业务的前提下，每季度都会设定读取后端微服务代码的性能目标，阅读代码，了解微服务、数据库或缓存、调度之间的调用关系tasks，沉淀成文档，反馈给微服务开发，开发判断读取效果。阅读部分甚至全部代码后，可以在后续的新项目中更自如地把控产品质量，比如技术方案是否合理，对增量代码进行CodeReview，提前发现bug，协助开发定位问题的原因，并促进未来的发展。编码前进行技术方案、接口协议、数据库审核。下图是机票测试同学在阅读机票接入基础数据相关代码时整理出的部分流程图：2.3测试覆盖率统计覆盖率是衡量测试完整性和有效性的常用手段。在大型交通业务系统中，一些项目的逻辑分支非常复杂。为了评估手动、界面自动化、UI自动化等黑盒测试方法是否能够覆盖代码的所有逻辑分支。最近，我们推出了增量代码覆盖率统计项目，目前正在小项目中试用。一轮测试完成后，我们可以查看覆盖率统计。在第二轮测试中，我们将重点覆盖第一轮没有覆盖的部分。有时对于一些逻辑分支构建测试场景非常困难，需要引入CodeReview等手段进行覆盖。需要注意的是，即使增量代码100%覆盖，也不代表万事大吉。有时开发会漏掉某部分代码。这种情况下，最好的情况是回顾技术方案，结合功能矩阵，用图设计测试用例时发现，但建议在测试后期检查是否有遗漏开发。除了增量代码测试，每个项目上线前还需要对主要业务流程进行回归测试。2.4推进项目自测一些比较简单的日常和项目测试不涉及一些比较简单的日常和项目测试，采用开发自测+产品验收直接上线的模式。测试同学会不定期对开发同学和产品同学进行测试基础知识培训，比如：部署隔离的Java测试环境、部署PHP代码、切换前端微服务、使用Mock平台等。一些项目测试也会提供产品要执行的测试用例，通过培训，没有测试介入的项目也能保证质量。2.5数据统计分析在提升代码质量的同时，我们需要按月对项目和Bug数据进行汇总，通过数据分析，发现和总结项目过程中存在的问题及其原因，提出项目优化和解决方案。问题。质量改进建议，并在项目组推动落实。月报侧重于项目质量的提升，而不是统计数据本身。通过数据展示，大家也可以了解到我们的工程质量在不断提升。比如在多个大型机票项目并行的情况下，今年Q1的线下BUG总数比去年Q4下降了1/4。通过数据可以看到项目的整体质量越来越好，也是对团队很好的鼓励。3、聚焦线上，形成问题闭环。在文章的第一部分，我们说只关注线下是不够的。一定要重视线上，线下和线上相结合，形成闭环。大同在线问题发现、处理和总结主要做了以下工作：3.1规范反馈流程测试团队制定了一套完整的在线问题处理和反馈机制，明确了工作流程，使用工具（TAPD）落地。内部用户和外部客服人员反馈问题后，将操作和产品记录在TAPD中，技术支持人员对问题进行过滤、复现并确认问题是否有效。如果有效，判断问题类型：如果是咨询问题，技术支持直接回复；如果是bug（即线上失败），会转发给开发解决方案；如果是产品改进，将转发到产品记录中。如遇重大开发问题，将通知TeamLeader关注。问题，无论类型如何，都将流经TAPD，直到问题报告者验证并关闭为止。最终将处理结果反馈给内部和外部用户。优先级高的问题优先处理，处理后尽快组织故障复查。3.2主动发现问题除了线上告警，技术支持还会定期巡查各项业务，预防线上重大问题，通过数据盘、数据库异常数据、小时报表等异常数据，主动发现线上问题并推动解决。3.3质量会议每周召开一次质量会议，由技术支持发起，参与开发、测试、产品、运营，对前一周上线的问题一一进行回顾，分析故障问题原因，解决所有问题点对点的类似问题；咨询问题转需求和运维??工具，解放人力；产品缺陷转移到产品要求。每月月初的质量会议还将对上月上线问题进行全面回顾，针对问题提出质量建议并推动落实。目前，大流量线上故障月度数据呈下降趋势，这与线下项目质量提升、每周质量例会、全员质量意识培养密不可分。而且，随着产品改进需求的推出，用户体验也越来越好。.4.完善工具建设，提高测试效率，靠人工一点点做是远远不够的。结合大流量的实际业务场景，测试团队的工具建设主要围绕环境支撑、压力测试、测试平台、UI自动化、界面自动化等展开。4.1环境支持无论CodeReview有多完善，最终还是需要集成测试。良好的测试环境是测试效率和工程质量的保证。同时，测试环境是否合适对于测试结果的真实性和正确性也非常重要。大通有3套测试环境：Dev环境、QA环境、pre-release环境。之前在测试环境中出现过一些明显的问题。比如在抢占开发Dev环境的情况下，只能同时测试两个Java改码项目（QA和Dev各测试一个），严重影响效率。QA环境中的频繁部署导致测试中断。在QA环境下开出真票，造成资金损失。Dev环境下开发自测完美，但是测试部署到QA环境后，连主进程都不行。为了解决以上问题，我们进行了测试环境的改造和预发布环境的开放。4.1.1测试环境改造针对上述问题，我们将提高测试环境的稳定性、并行性、隔离性、实时性作为测试环境改造的关键指标：相对稳定性：-QA部署必要时-Java代码：回收开发同学Jenkins权限-PHP代码：推动公司PHP部署平台（AOS）改造，只有所有者和共享者可以部署并行：-Java：所有微服务引入测试环境隔离插件-ins，同时支持多项目并行测试隔离性能：-测试环境下的订单无法在线发送-票据接入：订单拦截实时性能：-除了被测代码，其他代码也必须实时更新。良好的测试环境有效保障了多个项目的并行开发、联调和测试。测试前两天，测试同学开始协助开发和部署项目的隔离环境，在隔离环境中协调开发和自测。自测通过后，测试同学直接在项目的隔离环境中进行测试，大大节省了从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，也没有引入优质Valve。它需要专职人员监督开发、扫描和检查扫描结果。引入静态扫码效果不是很好。为了让Sonar能够自动发挥其代码检查效率，我们将Sonar引入测试环境CD平台，制定了统一的质量阀。未通过质量阀的声纳扫描无法部署到测试环境。最初，一个项目被用作试点。为了发现和解决问题，现在所有项目都需要通过Sonar代码扫描并通过质量阀才能提交测试。合格后方可送检。2、业务测试和工具开发的时间冲突比较大。Traffic没有专职的测试和开发职位。在有冲突的情况下，优先进行业务测试，在业务测试的间隙进行工具开发。在这样的情况下，有的结合业务测试。紧密的自动化工作相对缓慢。目前，我们的界面自动化仅涵盖核心回归用例。后面我们需要把接口自动化和大部分项目测试结合起来，才能真正把接口自动化应用到项目测试中。综上所述，大流量测试团队成立不到一年。经过一段时间的探索和实践，研发质量有了一定的提高，但我们在质量体系建设的道路上才刚刚起步。随着业务系统越来越复杂，对测试人员和质量体系的要求也会越来越高，需要全体成员不断提升质量思维，追求质量。未来，我们将不断积累方法，优化流程，完善工具，确保高质量的持续交付。本文作者：孙海燕，马蜂窝大流量业务测试专家，大流量测试团队负责人。（题图来源于网络）关注马蜂窝技术，发现更多你想要的内容
