阿里云薛冰洋：边缘云自动化测试解决方案—TestMaster

2022年7月8日-7月9日，QECon全球软件质量&效能大会在深圳正式召开。本次大会聚焦“研发效能、卓越工程、质量工程、数智化测试”四大主题展开讨论，邀请多位企业一线技术专家，共同关注软件的质量保障与研发效能，激发质量新动能，铸就效能新时代。

阿里云智能测试开发专家薛冰洋受邀参加大会，并分享了以《边缘云自动化测试解决方案—TestMaster》为主题的演讲，介绍了边缘云质量保障工作中的多重挑战，解读了以平台化技术全面赋能测试服务的创新实践，以下为整理内容：

边缘云是基于云计算技术的核心和边缘计算能力，构筑在边缘基础设施之上的云计算平台。

近年来，随着视频直播、物联网等应用场景快速发展，近80%的数据和计算都发生在边缘上，因此边缘云具备降低时延、减轻云端压力、降低带宽成本、全网调度与算力分发能力等优势，其业务也与公有云类似，包括计算、网络、存储、安全等类型。

目前，阿里云在全球拥有2800+节点，全网带宽输出能力达150+Tbps，业务范围覆盖了CDN、直播加速、全站加速、安全加速、边缘节点、边缘游戏等。

阿里云在资源覆盖上的超大规模、在业务范围上的多样性与纵深性对于质量保障工作造成了多方面挑战。

边缘云客户来自金融、电商、政企、直播、短视频等行业，覆盖着当前互联网上大部分流量。同时，边缘云还为重大活动，如双十一、大型活动晚会、大型体育赛事等提供底层支持。因此，作为云服务提供商，边缘云的研发、测试团队面临着以下方面问题：

• 稳定性问题。如果稳定性不佳，将面临巨额赔付、大额资损，甚至是大规模舆情；

• 性能问题。边缘云提供超大规模流量支撑，对于性能有较高要求，尤其短视频、直播领域的快速发展催生了高并发、低延时等方面的需求；

• 技术问题。目前大部分互联网公司采用新兴技术，作为服务商同样需要快速迭代，比如对HTTP3、QUIC等协议的支持；传统行业如金融、政企等类型公司则可能采用传统技术，作为服务方需要进行同步，在技术跨度方面上无疑是不小的挑战；

• 需求问题。针对不同类型业务与应用场景，边缘云需要在短时间内满足大量客户差异化、定制化的需求。

边缘云与移动端、电商类业务有明显差别，其测试范围更加关注底层业务：如超大规模分布式节点测试，音视频类测试，稳定性保障等。

• 机房分布：公共云机房分布为集中式，节点较少；边缘云机房全球分布，有数千个分布在不同城市的节点；

• 节点规模：公共云节点规模较大；边缘云资源有限，机房相对较小；

• 流量调度：公共云采用单region调度；边缘云采用全局调度，复杂性较高；

• 运维管控：公共云采用集中管控方式；由于节点多、机房全球分布，边缘云需要自治能力；

• 弹性能力、网络能力、存储架构与资源架构：公共云的单机房在建设初期采用系统与机型多为统一采购较为标准，网络可靠性与存储性能相对较高；边缘云网络可靠性相对较低，不适合持久化存储，系统异构性强但成本较低。

在上述前提下，边缘云的质量保障复杂度与公共云差异较大，且难度有所提升，需要在全局调度策略上提供支持。

边缘云与移动端、电商类业务有明显差别，其测试范围更加关注底层业务：如超大规模分布式节点测试，音视频类测试，稳定性保障等。

在发布与交互方面，由于边缘云的分布特性要求，最终全球版本需保持一致性，为此，需要对大规模节点同时进行测试，维护难度较大；由于需要对大量不同业务线进行测试，且发布周期在1~30天，发布频次平均每周近百次，客户要求紧急修改时还需要短时间内对大量服务进行回归性验证，对测试平台的性能响应度与压力承受能力提出了较高要求。

在测试团队方面，边缘云建设了测试基础设施，通过平台化赋能团队，保障了其业务的稳定性，也为团队未来发展奠定了基础。

TestMaster平台目标用户包括了研发、测试、产品、运维、PDSA、合作方，目的是让各方参与到自动化开发过程中，从而解决在质量保证过程中业务线覆盖不足、测试周期长、人力紧缺等问题。

TestMaster对接平台包括审批系统、发布系统、Aone、缺陷系统等，作为发布流程中连通研发与运维桥梁，帮助研发体系中不同角色融入研发流程中，改善不合理现状。

TestMaster平台架构从下往上可以分为：物理层、系统层、分布式自动化层、管控层、微服务层、网关层以及应用层，按照测试基座、自动化引擎、测试服务、测试应用共四个方面进行介绍。

测试基座主要是为了解决在自动化测试过程中的资源问题。

总结来说，TestMaster测试平台的测试基座具有三个特点：简单、强大、丰富。开发者无需关注底层资源问题，特殊需求如网络线路连通测试、相关地域机器使用，TestMaster都将提供相应API进行调用。

针对边缘云的自动化测试工作存在以下业务痛点：

• 单节点内包含至少数十台机器，测试过程中需要大流量、高性能支持；

• 产品形态差异大，如计算类、视频流量类、CDN类、安全类等，所需测试工具种类多；

• 底层测试或系统测试耗时长，若涉及全网下发耗时加倍，效率难以保证；

• 发布窗口固定，需支撑多业务线大批量同时测试；

• 节点分布涉及全国，需支持跨区域测试；

• 开发技术栈不同，需减少学习成本，帮助开发者快速理解业务。

解决以上问题需要从多方面入手，采用平台提供的不同服务逐一解决。

图中所示为自动化系统中的测试用例，使用自然语言以markdown的形式进行编写，经过解析生成开发者所熟悉的语言并在测试机上运行，进一步生成markdown测试报告，与最初的测试用例形式完全一致，仅添加日志与错误信息。

使用自然语言进行撰写能够助力用户快速理解业务，减少上手难度，短时间内可以积累数千集成测试用例，并且单人可以负责多条业务线，减少人工成本。以自然语言方式进行交互还方便了开发人员、测试人员相互理解，降低了沟通成本，还可以通过钉钉将业务自动分发到不同群组，使问题定位更加迅速。

测试工作运行流程如图所示：

• 从业务上来说，每个job运行的业务可以是计算类、流量类或安全类，测试场景跨度大，共积累了300+小时的复杂场景测试用例；

• 从性能上来说，每个worker可以并行运行多个用例，在2小时之内可以完成全业务线的全量测试工作；

• 从稳定性上来说，每个job、worker与节点之间完全隔离，不同业务之间运行没有影响，同时支撑型服务实现节点内自治，相互之间没有影响，与发布进行强管控，保证24小时不因测试系统问题而中断发布；

• 从能力上来说，支持markdown、yaml、UI等方式撰写测试用例，数十种工具包与上百种library可以调用，支持了并行、串行、回滚、清理等打标的按需运行；

• 从易用性上来说，只需用户自行选择运行方式、关注自身业务，其中的worker、job、service报告、通知、调度等对于用户完全透明、无需感知。

测试平台相较于单一的自动化框架面临的业务场景与技术难度有着明显区别，其主要体现在：

• 承载十几条不同种类的业务线，数百种测试场景；

  
  

• 数量庞大的全链路用例，运行时间长达几百小时；

  
  

• 测试过程中资源分配、运行策略等复杂度极高；

• 自动化用例动态变化过程中如何精准测试；

基于微服务架构设计的TestMaster,在整个运行过程中通过在 数据准备-计算与调度 - 管控 -回收 4个阶段应用不同微服务解决了上述问题，在边缘云、视频云得到了良好应用。

与业界常见的发布方式不同，边缘云采用了并行发布方式，单次发布规模大，要求测试平台具备支撑多业务线同时发布测试能力。

如上图所示，TestMaster平台使用其丰富的微服务提供的能力，在整个集成测试过程中连通上下游系统，实时反馈测试进展，精确到commitID与开发者，通过钉钉推进研发对BUG定位与解决。

同时集成测试服务在效率、覆盖度、复杂度上为不同业务线提供了强有力支撑，300+小时的全链路自动化用例仅需2小时即可完成回归测试。

测试平台用户包括产品、研发、测试、运维与PDSA。以产品用户为例，通过任意点击测试场景选择被测节点，运行即可得到对应结果，自主掌控验收过程，无需测试、研发等技术人员参与。

对比前文流量类测试，边缘节点ENS验收测试为计算类测试。由于初期业务量较小，每个产生的虚拟机都需要经过计算资源、存储资源、网络资源等类型的资源校验后才能最终交付给用户，出现问题后接收通知进行排障。随着业务量突增，业务流程进行加速，通过TestMaster平台对接建设系统实现了自动化处理，大幅提升了验收时间与验收次数，显著优化了交付效率。

边缘网络内部不通、测试权限问题、大规模异常测试导致的节点异常验收中断等，导致测试不能覆盖关键应用，部分应用不可测问题。基于上述情况TestMaster平台开发了保护伞应用，打通了节点内部限制，提升了测试覆盖精度，扩大了测试范围。同时根据各业务线差异，设计了严格的权限管控，保障业务测试隔离。该应用解决了测试团队核心难题，上线后使用量激增，效率提升数十倍。

TestMaster于2020年4月立项进行开发，在质量保障上为业务提供重要支持。应用上线至今，支撑了10条业务线、数百种场景测试，业务范围包括了电商、直播、短视频、政企等，大幅提升交付效率，节省用人成本，实现了故障大幅收敛。

随着边缘云业务不断发展，外部产品形态持续变化，内部技术不断提升，测试平台也需要伴随产品与技术的发展，提供用途广泛稳定的测试服务。

同时TestMaster平台通过打通边缘云的不同系统，具备了数据整合能力，我们希望通过这些数据能够输出质量指标，为体系化建设边缘云提供数据基础。