51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 966|回复: 0
打印 上一主题 下一主题

[转贴] 一招教您解决自动化测试--TestMaster边缘云

[复制链接]
  • TA的每日心情
    擦汗
    13 小时前
  • 签到天数: 1048 天

    连续签到: 1 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-8-9 10:21:32 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    边缘云介绍
      边缘云是基于云计算技术的核心和边缘计算能力,构筑在边缘基础设施之上的云计算平台。
      近年来,随着视频直播、物联网等应用场景快速发展,近80%的数据和计算都发生在边缘上,因此边缘云具备降低时延、减轻云端压力、降低带宽成本、全网调度与算力分发能力等优势,其业务也与公有云类似,包括计算、网络、存储、安全等类型。

    目前,阿里云在全球拥有2800+节点,全网带宽输出能力达150+Tbps,业务范围覆盖了CDN、直播加速、全站加速、安全加速、边缘节点、边缘游戏等。
      质量挑战
      阿里云在资源覆盖上的超大规模、在业务范围上的多样性与纵深性对于质量保障工作造成了多方面挑战。
      来自客户侧的挑战
      边缘云客户来自金融、电商、政企、直播、短视频等行业,覆盖着当前互联网上大部分流量。同时,边缘云还为重大活动,如双十一、大型活动晚会、大型体育赛事等提供底层支持。因此,作为云服务提供商,边缘云的研发、测试团队面临着以下方面问题:

      稳定性问题。 如果稳定性不佳,将面临巨额赔付、大额资损,甚至是大规模舆情;
      性能问题。 边缘云提供超大规模流量支撑,对于性能有较高要求,尤其短视频、直播领域的快速发展催生了高并发、低延时等方面的需求;
      技术问题。 目前大部分互联网公司采用新兴技术,作为服务商同样需要快速迭代,比如对HTTP3、QUIC等协议的支持;传统行业如金融、政企等类型公司则可能采用传统技术,作为服务方需要进行同步,在技术跨度方面上无疑是不小的挑战;
      需求问题。 针对不同类型业务与应用场景,边缘云需要在短时间内满足大量客户差异化、定制化的需求。
      技术差异造成的挑战
      边缘云与移动端、电商类业务有明显差别,其测试范围更加关注底层业务:如超大规模分布式节点测试,音视频类测试,稳定性保障等。
      机房分布: 公共云机房分布为集中式,节点较少;边缘云机房全球分布,有数千个分布在不同城市的节点;
      节点规模: 公共云节点规模较大;边缘云资源有限,机房相对较小;
      流量调度: 公共云采用单region调度;边缘云采用全局调度,复杂性较高;
      运维管控: 公共云采用集中管控方式;由于节点多、机房全球分布,边缘云需要自治能力;
      弹性能力、网络能力、存储架构与资源架构: 公共云的单机房在建设初期采用系统与机型多为统一采购较为标准,网络可靠性与存储性能相对较高;边缘云网络可靠性相对较低,不适合持久化存储,系统异构性强但成本较低。

    在上述前提下,边缘云的质量保障复杂度与公共云差异较大,且难度有所提升,需要在全局调度策略上提供支持。
      测试自身面临的挑战
      边缘云与移动端、电商类业务有明显差别,其测试范围更加关注底层业务:如超大规模分布式节点测试,音视频类测试,稳定性保障等。
      在发布与交互方面, 由于边缘云的分布特性要求,最终全球版本需保持一致性,为此,需要对大规模节点同时进行测试,维护难度较大;由于需要对大量不同业务线进行测试,且发布周期在1~30天,发布频次平均每周近百次,客户要求紧急修改时还需要短时间内对大量服务进行回归性验证,对测试平台的性能响应度与压力承受能力提出了较高要求。
      在测试团队方面, 边缘云建设了测试基础设施,通过平台化赋能团队,保障了其业务的稳定性,也为团队未来发展奠定了基础。
      技术方案
      给谁用?用在哪?
      TestMaster平台目标用户包括了研发、测试、产品、运维、PDSA、合作方,目的是让各方参与到自动化开发过程中,从而解决在质量保证过程中业务线覆盖不足、测试周期长、人力紧缺等问题。
      TestMaster对接平台包括审批系统、发布系统、Aone、缺陷系统等,作为发布流程中连通研发与运维桥梁,帮助研发体系中不同角色融入研发流程中,改善不合理现状。

    平台核心目标
      简单高效:通过提供简单稳定高效的自动化手段,提供快速提升自动化的覆盖能力;
      多区域精准测试:对分布在全球不同区域的大规模节点提供分布式测试方案;
      丰富的测试服务:为差异化场景与业务线提供相应的测试服务;
      应对复杂场景的测试方案:以应用的形式提供面向不同测试场景的解决方案,为用户解决相关的质量问题。
      TestMaster测试平台架构
      TestMaster平台架构从下往上可以分为:物理层、系统层、分布式自动化层、管控层、微服务层、网关层以及应用层,按照测试基座、自动化引擎、测试服务、测试应用共四个方面进行介绍。

    资源充沛的测试基座
      测试基座主要是为了解决在自动化测试过程中的资源问题。
      如视频类测试对带宽要求高且线路覆盖全。TestMaster平台提供了100G带宽,电信、联通、移动三种线路。在直播回归测试过程中,预估总流量在20G左右,所以多个用户同时进行测试,100G带宽可以满足其需求。
      对于海量测试任务与不同硬件架构场景,平台提供了百台客户端,支持X86与ARM架构,满足主流硬件测试场景。
      对于多种存储需求提供自动化的数据存储、大型文件存储方案,最高可达1PB的分布式文件存储能力能够应对如直播类业务线中对4K、8K视频的推流本地存储;针对长久存储需求,还提供无限制的对象存储。
      对于自动化开发与运行支持目前主流操作系统Linux、Mac、WindowsAndroid
      对于边缘测试提供面向不同地域的测试节点。主要包含在华北、华东、华南三个大区,能够应对全国不同区域节点与新增节点的边缘测试。
      总结来说,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验收应用
      对比前文流量类测试,边缘节点ENS验收测试为计算类测试。由于初期业务量较小,每个产生的虚拟机都需要经过计算资源、存储资源、网络资源等类型的资源校验后才能最终交付给用户,出现问题后接收通知进行排障。随着业务量突增,业务流程进行加速,通过TestMaster平台对接建设系统实现了自动化处理,大幅提升了验收时间与验收次数,显著优化了交付效率。
      测试团队核心能力扩展
      边缘网络内部不通、测试权限问题、大规模异常测试导致的节点异常验收中断等,导致测试不能覆盖关键应用,部分应用不可测问题。基于上述情况TestMaster平台开发了保护伞应用,打通了节点内部限制,提升了测试覆盖精度,扩大了测试范围。同时根据各业务线差异,设计了严格的权限管控,保障业务测试隔离。该应用解决了测试团队核心难题,上线后使用量激增,效率提升数十倍。






    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-18 22:51 , Processed in 0.064059 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表