编者注：在2022年11月5日举办的“2022 MeterSphere开源持续测试平台城市遇见· 上海站”活动中，商米科技的云部门测试负责人樊嘉分享了题为《基于MeterSphere的全球化云服务接口测试实践》的主题演讲。以下内容根据本次演讲整理而成
上海商米科技集团股份有限公司（以下简称为商米）是一家致力于为商用领域提供智能IoT（Internet of Things，物联网）设备及相应配套的“端、云”一体化服务的物联网科技公司。从2016年推出第一款智能手持终端至今，商米已经推出移动、金融、台式、自助、网络/视频等丰富的商用IoT设备，覆盖多种业态场景。
2020年，商米正式对外发布了BIoT（Business Internet of Things，商业物联网）战略，希望通过智能商用IoT设备、商用操作系统与IoT云管理平台所构成的商米产品及服务体系将数字化带入到每个商业场景中。与此同时，商米还向合作伙伴提供标准化应用开发服务与高可靠全球化设备远程管理与控制服务，赋能合作伙伴快速实现对设备及应用的商业化管理与运营。
一、背景介绍
自2016年开始生产智能设备至今，商米的设备已经从一代机演进到二代机，且正在进行三代机的开发。商米的产品影响范围遍及全球，拥有全球化的服务、全球化的技术支持和全球化的线下数据建设。
在平台升级至BIoT战略之前，公司使用的早期SUNMI云架构如下图所示。早期SUNMI云的模式相对比较简单，即线下设备搭载定制于Android的Sunmi OS（Sunmi Operating System，商米操作系统），再通过Sunmi OS搭载各种软件，商米则通过一套内部管理平台和一套合作伙伴的开放平台，去形成简单的联动生态。
后期升级至BIoT模式后，商米业务架构的复杂度加大。除了在基础的各种系列设备上搭载Sunmi OS，以及搭载OTA（Over The Air，空中下载）、远程协助、应用商店、商米收银台、流量服务、证件云解等各种设备软件以外，商米还为客户提供了两种开放平台以及两种解决方案。在商米的开放平台上，客户可以通过开放平台去看护、管控自己的设备，在自己的渠道上添加各种黑、白名单，并定向推送各种应用版本至终端的某一台设备上。商米可以为客户定制软硬件一体的解决方案，也可以直接提供一些通用的方案。
二、商米平台的基本现状
■ 目前商米拥有多个技术栈，线上ECS（Elastic Compute Service，云服务器）的数量已经达到500多台，有近20个线上集群、近千个活跃服务、上百个域名（不包括通过CDN加速的域名），统一网关的每日调用量已达到6亿次；
■ 商米云平台对应多种线下环境；
■ 商米的设备需要保证网络安全并具有一定的记忆力，所以需要在网关添加各种加密、解密插件；
■ 商米的后端技术栈主要包括Java、Golang等；
■ 近年来，商米架构逐渐走向微服务化和云原生化，这使得平台架构更加复杂；
■ 业务接口量暴增至几千个，在这种情况下，如何保障接口与技术栈质量对商米技术团队来说就成了一项较大的挑战。
三、测试中的技术难点与技术选型
1. 技术难点
商米从2020年开始走向国外。为了满足各个国家对于数据安全的要求，商米已经在海外建立了多个数据中心。在设备跟随客户移动、客户可能移动至不同地域的情况下，为了满足每个数据中心将业务数据留存在当地的要求，商米打造了全球化的运维平台架构。
商米有一套全球通用的大数据分析平台，对其所有数据中心进行统一的管控运营。但是由于商米在不同地域的数据中心使用不同的云，在中国数据中心使用的是阿里云，在海外的数据中心使用的则是谷歌云或亚马逊AWS。要打通这些不同的云平台存在一定难度。
2. 技术选型
目前，商米云平台测试主要包括接口测试和UI测试。其中接口测试的接口按照属于研发域与测试域进行区分，又可以划分为外部接口和内部接口。
商米测试团队进行的主要是外部接口测试和UI测试。基于这一点，团队早期制定了接口测试的平台化方案，基于JMeter进行二次开发，通过Jenkins触发流水线，也自研了接口测试框架，但实际效果并不理想。这套平台化方案存在的问题包括：
① 早期业务的接口规范与所使用的技术栈不统一；
② 早期测试人员的个人能力有限，不同测试人员使用的测试工具难以通用；
③ 因为商米的业务往往有各种各样的加签规则，以及多种不同的接口，仅靠一款固定工具难以满足业务需求，需要团队持续投入，去定制开发并维护工具，成本过高；
④ 早期商米测试团队对前端的外部接口仅进行手工测试。后期团队进行基于代码方法的测试，也因为UI元素识别的难度和成本较高而暂时没有进行UI测试。
四、为什么选择MeterSphere？
对于测试工作来说，成本、准确性和速度这三个方面应该达成三角平衡。在进行测试平台选型时，商米测试团队对照自身诉求和痛点梳理、对比了很多测试平台工具，希望能够测试平台能够满足以下条件：
① 成本方面
■ 团队希望所选用的测试工具可以满足测试代码及其依赖环境无需在本地部署的条件；
■ 希望能够避免云上部署的资源浪费情况。
② 准确性方面
■ 团队希望选用的测试工具可以实现测试数据、用例的统一协作。因为测试团队中每个人都有一套自己的测试脚本，但不同的脚本在合并地址时往往会出现冲突，后续也只能由不同的脚本负责人各自进行维护，依然难以达到协调的效果，所以需要一个平台工具来帮助全体测试人员展开统一协作；
■ 团队经调研、实践发现，自研的测试框架往往不太稳定；而一般大公司开发的测试框架又相对局限，只能支持某一种协议，或者只支持某一种使用方式。如果要应用到具体的纵向场景中，会有很多需要定制开发的内容。商米的测试团队希望能够解决这个问题。
③ 速度方面
■ 平时测试人员自行整理，或者根据一些原有的开源框架输出的测试报告都不够清晰美观，且写报告的过程耗时较长；
■ 虽然商米的测试团队有自己的DevOps流水线，但早期流水线的结构较为简陋，只能支持测试任务的并行。而基于成本的限制，测试用的设备也需要控制在一定数量内，这对测试速度产生了负面影响。
2022年4月，商米的测试团队接触到了MeterSphere开源持续测试平台，发现它能较好地满足以上测试工作中的诉求，试用后很快就选定其作为商米的测试工具。
对商米测试团队来说，MeterSphere的优势如下：
① MeterSphere平台支持云化部署；
② MeterSphere支持Kubernetes集群的动态调度，避免环境长期弃置造成资源浪费，一次性使用后即可直接销毁；
③ MeterSphere支持测试团队方便地进行多人协作，且提供长期维护的稳定版本；
④ MeterSphere平台可以通过一对多的方式同时控制多个节点，能够为测试团队提供接口测试与压力测试方案；
⑤ 测试团队之前在JMeter上的测试工作量较大，沉淀较多，但依然可以通过Jar包的方式将这些测试工作的内容全部快速导入到MeterSphere平台。
五、MeterSphere平台的落地成果
商米研发阶段的流水线包括需求管理、交付协作、提测、开发验证、研发自测、SIT（System Integration Testing，系统集成测试）验证、预发验证、上线审核、生产发布等多个环节。其中，MeterSphere测试平台主要应用于商米的研发自测和SIT验证环节。
测试团队通过Kubernetes集群的方案部署了MeterSphere平台，并将其接入了商米的DevOps流水线。目前商米使用阿里云的云效平台作为DevOps平台，主要使用其中的代码管理和流水线功能部分。团队希望产品上线之后，依然能有监控线上环境稳定情况的途径。在流水线接入MeterSphere平台之后就基本可以实现自动化测试的良好运行，并得到及时的结果反馈。
以下是MeterSphere平台在商米测试工作中的一些实际应用场景：
■ 接口场景化
在接口中编排测试步骤，通过这些步骤将流程链路串连起来。
■ 用例跨环境执行
需要测试的接口可以分布在多个设备上。由于端上的组件和网络库的版本不一样，它们的验签方式也不一样。为了验证这些签名，让业务逻辑在每个版本上都能成功实现，使用的测试平台需要具有同时满足多种环境配置的能力。MeterSphere能够很好地满足这一需求。
此外，团队在接口测试方面，也尽可能避免了一套数据只能在一套环境上执行的情况，而是通过MeterSphere平台使得一套数据可以在多套环境上执行。这样就可以直接满足线下环境、预发环境等在内的所有阶段的签名验证。
■ 接口同步插件
为了更好地支持整个研发测试协作，测试团队也在研发端配合制作了一款IDE插件。这款插件支持研发团队将通过注解的方式写出来的接口信息自动投入到MeterSphere平台，及时将接口变动情况同步给测试人员。测试人员可以直接根据接口变更信息去维护对应的用例，有效降低了沟通成本。
■ 海外拨测节点
由于具有全球化的业务背景，商米需要有能力去巡检全球各个数据中心的服务，确认各集群是不是正常可用、CDN有无异常，以及网络链路是否通畅。目前商米还不能满足所有端上的APN（Access Point Name，接入点）设置，但在MeterSphere平台接入、DevOps的末端上线之后，商米可以通过全球各节点去巡检各服务、业务、域名及网络链路是否正常，及时排查业务中出现的问题。
■ 结合DataEase制作仪表板大盘
商米的测试团队还使用FIT2CLOUD飞致云旗下的另一款开源产品——DataEase开源数据可视化分析工具制作了测试仪表板大屏。
测试人员可以通过仪表板监测接口测试的用例数量、API接口或场景自动化的用例数量、用例数量等级的分布、用例增长数量、用例数量增长趋势等指标，更好地辅助测试团队内部进行日常管理工作和问题识别工作。团队现在也将这个仪表板融入了生产质量的全生命周期管理，更加方便地进行缺陷和故障的排查。
六、未来规划
引入MeterSphere开源持续测试平台半年时间以来，商米的测试团队获得了良好的使用体验，提高了工作效率，并通过MeterSphere平台解决了一系列测试工作中遇到的问题。在之后的工作中，团队希望能够继续开发MeterSphere平台的各种功能，也结合自身业务总结出了一些想通过MeterSphere平台实现，或希望MeterSphere平台未来能够支持的功能：
■ 代码覆盖率检测
目前MeterSphere平台还无法进行代码覆盖率的检测。希望未来MeterSphere平台可以并入全量或增量的代码覆盖率检测功能；或者搭建覆盖率平台，并将其与MeterSphere平台的接口测试打通；
■ 全球服务压测
由于自身采用的是全球化的服务模式，商米的测试工作也会面临容量规划的问题。商米在各地区的业务增速并不均衡，工作人员无法作出准确的预判，也不能及时感知容量的使用情况，往往在线上业务的内存资源告急或发生故障时才能收到反馈。团队希望在全球化的业务中，可以根据每个地域或节点的实时用户量，通过MeterSphere平台去建立每个地区的用户压力模型，并进行全球化的服务压测；
■ 基线性能测试
以往商米的性能基线测试一般是在其他测试工作结束之后进行的。团队希望以后能通过MeterSphere平台将性能基线测试加入到整个发布流水线之中，希望业务应用在上线前可以通过基线性能测试。因为早期测试代码效率较低，且目前商米业务量增长需要提升整体的开发测试效率，团队需要以基线性能测试为门禁，将其加入商米的测试环境，防止线上事故发生；
■ UI自动化回归
商米的测试团队希望2023年能够引入MeterSphere的UI自动化功能。商米云服务有很多外部站点平台，比如合作伙伴平台、内部管理平台、门户网站、其他开发者中心等，对于这些Web网站，团队希望通过使用MeterSphere的UI自动化测试能力降低测试的工作量。