编者注：在2022年8月13日举办的 “2022 MeterSphere 开源持续测试平台城市遇见· 深圳站” 活动中，深圳思为科技有限公司测试经理雷华清分享了题为《MeterSphere 在微服务架构中的自动化测试应用》的主题演讲。以下内容根据本次演讲整理而成。
深圳思为科技有限公司（以下简称为思为科技）成立于 2011 年，总部位于深圳，是一家致力于用领先技术驱动房地产营销数字化升级的 SaaS 服务商。思为科技面向开发商提供以数字内容工业化制作、营销流程一体化打通、客户资产沉淀及运营为核心的全场景营销解决方案，通过实现楼盘数字化、场景线上化、数据资产化、营销自动化，助力开发商打造线上线下一体、前后端打通的房地产数字化营销闭环。文章源自玩技e族-https://www.playezu.com/239720.html
目前，思为科技已经在全球 30 多个城市设立分公司和办事处，为 500 个以上的开发商提供服务，其中百强开发商覆盖率超 80%。文章源自玩技e族-https://www.playezu.com/239720.html
深圳思为科技有限公司测试经理 雷华清文章源自玩技e族-https://www.playezu.com/239720.html
一、微服务架构中的测试难点文章源自玩技e族-https://www.playezu.com/239720.html
起初，思为科技的营销云产品以需求迭代为核心，在服务架构的设计上较为简单，采用了传统的大单体架构。后来，随着业务的增长，业务复杂度越来越高，传统的大单体架构不足以支撑业务迭代。文章源自玩技e族-https://www.playezu.com/239720.html
为此，思为科技在架构上进行了升级，选择了如今的微服务架构。因微服务架构具备高灵活、易拓展、高可用的优势，能够有效支撑公司复杂的业务系统。文章源自玩技e族-https://www.playezu.com/239720.html
微服务架构对测试提出了更高的要求，总结下来包括以下几个方面：文章源自玩技e族-https://www.playezu.com/239720.html
之前的大单体架构以业务型测试为主，微服务架构还需更多地关注组件测试，以及每个服务进程内部的功能及对外暴露的能力；
维护环境体量变大。大单体架构时只需维护少量环境，比如测试环境和生产环境。微服务架构则需维护整个架构：包括开发环境、测试环境、灰度环境及生产环境等；
API 接口数量变多，且变更频繁。微服务要把传统的一些服务进行拆分，接口会变多，整个拆分的时候有内部接口、对外暴露接口，接口变更非常频繁；
重构次数增多导致面临大量的回归测试。微服务因为便利性可以支持快速重构，每次重构对测试来说都会面临大量的回归测试；
在微服务场景下，各个服务可独立部署，可独立迭代，这样一来交付时间会缩短，测试的时间被压缩。
在引入测试平台前，思为科技研发团队采用的是传统的软件测试方法。然而传统测试存在着诸多弊端。
相信很多测试人员都知道测试金字塔模型，从模型可以看出，单元测试在最底层，测试成本最低，最上面的是 UI 测试，由此也能看出越早做测试收益越高。
而实际的测试工作中往往与模型相反，呈现出倒金字塔模型。为了适应业务快速的迭代和市场变化，很多开发团队没有强制要求也没有做很多的单元测试，有些团队基本上是不要求就不会去做。比如开发人员比起单元测试，更多地喜欢进行上面一层的 UI 测试。
思为科技在使用测试平台前，在实际测试工作中面临着以下困境：
超过 80% 测试都是手工进行功能测试，执行收益非常低；
自动化测试需要编码能力，有一定门槛；
开发团队和测试团队对立，认为质量保障是测试环节的工作；
测试周期长，产品迭代速度慢。
因为测试资源紧张，产品开发完提测后，测试环节若有问题需要多次回归，又因为面临上线节点导致团队经常加班赶进度或发版延期等问题。若卡着时间节点上线产品，会产生很多生产问题，产品质量难以保障。
另外，因为整个测试的工作量非常大，且都是手工测试。开发人员在面临一些底层架构不支持需要重构的情况时，考虑到每一次重构需要大量测试、大量时间而不敢重构，最终造成测试成为交付的瓶颈。
二、MeterSphere 打破持续交付瓶颈
为了打破这一瓶颈，思为科技的测试团队尝试了很多方法。起初团队尝试过做自动化，专门建立了自动化测试团队。然而自主研发测试自动化平台对团队人员的技术要求非常高，且测试工作中不同测试状态比较分散，使用的工具都不统一，用例无法统一管理。
因此，思为科技就考虑需要引入一个测试平台，在市场上调研了各种各样的测试平台。思为科技也尝试过自研，但是自研一个测试平台成本还是较高，且投入了一个开发团队进行研发，成果却并不理想。
最终，思为科技的测试团队选择了 MeterSphere 开源持续测试平台来支撑内部测试工作，满足当时面临的主要需求。
以下为 MeterSphere 在思为科技测试环境中的实际应用效果：
- 使用 MeterSphere 平台跟踪功能测试
思为科技营销云在引入 MeterSphere 作为测试平台后，做的第一个事情就是把整个功能测试的一系列动作、流程全部搬到了 MeterSphere 平台上。
应用特点：
■测试用例：使用脑图编写用例，快捷高效；用例在线管理，易维护；
■测试计划：按照测试阶段创建测试计划跟踪过程，有效把控进度；
■测试报告：自动生成测试报告以采集数据，减少手工统计的工作。之前测试人员需要使用 Word 写测试报告，并进行相应的统计工作。使用 MeterSphere 平台后这部分工作得以简化。
- 通过 MeterSphere 插件打通 IDEA 与测试平台的接口同步
团队最开始做接口测试时面临一个难点，就是如何对接口进行管理、维护及更新。虽然 MeterSphere 是支持 Swagger 形式自动同步，但团队内部不是用这种形式管理接口。这主要是考虑到 Swagger 有一定的代码入侵，所以没有用这种形式。
当时我们的接口布局比较散，分别放置在 YApi 平台、共享文档和线下文档等位置。另外，使用 MeterSphere 平台做接口测试需要保证接口实时更新，接口维护一定要实施及时。
在没有使用 MeterSphere 的 “metersphere-idea-plugin” 插件时，导入接口是手动将接口从 YApi 平台导出后，再导入到平台进行更新。因手动导入、导出很麻烦，开发人员也不想做这些事，导致推动很难。但如果接口前期不维护好，后续工作开展起来也很困难，所以想做这样一个插件装置在 IDEA 里。
应用特点：
■ 根据服务的类型配置不同的同步策略，便于接口管理；
■ 在接口有变更时，IDEA 上一键同步至测试平台，确保接口信息的及时更新和维护。
注意：接口同步很关键，这是做好自动化测试的前提。
- 在线管理接口
上面提到，我们产品内部的接口管理是比较分散的，使用 MeterSphere 可以将所有接口放在平台进行统一管理。由于采用的是微服务的形式，所以我们会把每个服务的接口单独合并进行管理。
应用特点：
■ 统一接口管理工具，每个服务接口进行归档管理；
■ 接口实时更新，支持在线查看；
■ 开发人员线上联调、自测。之前开发的线上调试使用的是 Postman，由于 Postman 只能本地部署，很多参数配置无法共享。使用 MeterSphere 之后，其他人去访问调试的结果非常方便；
■ 数据统计，便于管理。在微服务的架构内，我们可以非常直观地了解每个服务的接口状态。
- 微服务的接口测试
微服务接口测试是一个复杂的流程，接口文档采用插件形式，如果服务中的接口有变更可以自动同步到 MeterSphere 平台上，这样就不需要维护接口文档，接口文档就是 MeterSphere 平台。
开发进行 Mock 前后端联调也是在 MeterSphere 平台上完成的。之前的瓶颈在于测试会觉得开发的质量很低，导致每次提测的版本都需要重复测试。但是由于业务的快速发展，又不能要求开发逐个去写单元测试。针对这种情况，测试团队开始让开发人员在需求提测时自己在 MeterSphere 平台上做接口测试，每个接口变动保存一条用例，确保该用例能够跑通。有了这个前提，测试团队才会进行下一步的接口验证，验证前面的接口用例是否更新且能够跑通，然后再考虑进行接口自动化测试。
应用特点：
■ 测试工作左移，在开发过程中就开始做接口测试；
■ 开发参与到接口测试的过程中，用测试检验开发的过程质量。开发团队需要保证提测产品的质量，主动开展单元测试或者自测，开发实际参与到测试过程中；
■ 整个接口测试的流程都是在 MeterSphere 持续测试平台上进行的，整个过程可追溯。
- 按照业务流程编排场景自动化测试
除了对单服务进行接口测试，团队还会按照实际业务流程涉及的接口进行编排，进行场景化的自动化测试。
所有用例会进行每日定巡，通过写定时任务，根据业务重要程度的不同，设定不同的时间跑一遍。跑的结果会与飞书系统打通，只要结果有异常都会通知到飞书群，通知到对应的人员去处理更新。
更新后会进行自动触发，因为整个过程结合到了 DevOps 流程里，只要版本触发了构建部署，就会去执行。触发有结果了相关技术人员就可以查看是接口有问题还是场景编排有问题，然后进行持续改善、持续维护，最终完成测试的持续集成。
- MeterSphere 打通 DevOps，实现微服务自动化测试全流程闭环
场景自动化的应用，最终离不开 DevOps 的经典流程。思为科技研发团队所做的自动化测试，最终目的就是为了提效、回归，减少手工的测试执行，必然会将场景自动化加到整个 DevOps 流水线中。
因为采用了微服务部署的形式，思为科技整个流程的架构较为复杂。我们将其归纳为的五个步骤：
第一步是构建。包含 Apollo 配置中心、GitLab-CI 和 Jenkins；
第二步是检查。每一个服务只要有构建，版本都会提升，如果涉及单元测试就会跑一次单元测试用例。因配置了 Sonar，会进行代码的质量检测，如果代码质量检测不通过，就无法到达下一步；
第三步是部署。根据提交代码的类型，部署到不同的服务及应用上；
第四步是测试。部署完成后会自动触发整体的测试，此步骤通过 MeterSphere 测试平台提供的能力实现。比如说接口测试，接口编排完后，最终会把接口做成自动化，而后将每一个服务归纳成一个合集。当某一项服务有更新，只会执行这一个服务的自动化测试直至通过。当系统中有多个服务同时去部署、发布的时候，测试团队会去跑场景化的测试。场景化的测试就是相当于系统中的核心业务，需要保证核心业务所需测试的功能是通过的，最终测试的结果会生成一个测试报告，这些工作均是自动化完成；
第五步是回滚。如果前面的测试通过了，就代表正常的部署成功了；如果测试不通过的话，它会自动回归到上一个稳定版本，然后会将测试结果进行通知。
在整个流程中，还配合着各种各样的监控：包括事件监控、调用监控及资源监控等。监控之后还配合着整个系统的通知机制。任何一个环节出了问题，系统都会进行及时通知。
现在，思为科技内部的通知机制已经可以较好地支撑实际工作。当服务出现问题或者是有任何其他问题时，通知系统配置的机器人会自动拉群，把对应的人员拉到群里。然后对应人员会立即去处理，处理完成后告知机器人，机器人便会关闭问题通知群，落地效果非常灵活。
最终，思为科技使用 MeterSphere 持续测试平台打通了 DevOps 流程，实现了微服务自动化测试的全流程闭环。
三、MeterSphere 带来了哪些效果和转变？
在将 MeterSphere 测试平台融入到 DevOps 流程后，思为科技打破了持续交付的瓶颈，在实际生产环境中所获得的价值收益体现在四个方面：
■ 测试提效：在线进行用例的编写与评审，跟踪执行过程自动生成测试报告，功能测试周期缩短了 1/3。原来需要 6 天的功能测试现在缩短至 4 天；
■ 测开协作：测试与开发人员使用同一平台，开发参与到测试过程中，共同维护接口，为自动化测试提供保障。开发与测试从对立关系转变为协作关系；
■ 快速迭代：核心业务的自动化测试，可以支撑一周两次的版本迭代和多次重构升级，进而快速适应市场，满足用户需求；
■ 质量保障：把控业务质量的同时，检验产研的过程质量，提高所有人的质量意识，共同保障产品质量。质量保障不再仅仅是测试团队的事情，测试驱动开发成为可能。
最后来梳理一下思为科技在 MeterSphere 持续测试平台各功能模块的应用实践：
■ 功能测试：测试用例在线编写、评审，持续维护；对应各测试阶段的测试计划；在线生成测试报告，便于测试总结；跟进测试过程，及时发现风险并做出调整。
■ 接口测试：接口文档及时更新在线维护；单服务接口测试覆盖 100%；业务场景化接口编排覆盖 80%；每日定巡，结合 DevOps 持续集成 。
■ UI 自动化：模拟用户真实操作，发现前端界面问题；Web 端常用业务主流程覆盖 20%；App 端核心业务流程覆盖 10%；每日定巡，持续集成。
■ 性能测试：单服务性能压测，制定性能指标；混合场景性能压测，满足业务使用指标；服务重构、业务重大变更，满足性能指标；性能压测环境、压测资源在线维护，减少资源浪费和重复性工作。
■ 监测体系：服务运行监控，及时发现服务异常；业务运行检测，记录业务报错信息；环境资源监控，资源占用达到阈值及时告警；信息自动通知。
评论