场景模型驱动自动化测试在盒马的探索及实践

简介: 盒马业务有如下几个特点:线上线下一体化、仓储配送一体化、超市餐饮一体化、经营作业一体化、多业态与平台化。在以上的种种原因,生鲜及物流体验是盒马的特点,但仓储配送一体化作业中,如何能更高效的提升测试效率也是盒马质量团队的重点探索。

image.png

作者 | 钦伟
来源 | 阿里技术公众号

一 引言

盒马业务有如下几个特点:线上线下一体化、仓储配送一体化、超市餐饮一体化、经营作业一体化、多业态与平台化。

在以上的种种原因,生鲜及物流体验是盒马的特点,但仓储配送一体化作业中,如何能更高效的提升测试效率也是盒马质量团队的重点探索。

二 背景及待解决问题介绍

1 盒马自动化体系发展新挑战

在盒马,前期业务在狂奔,自动化基础较薄弱,近三年来,经过盒马人的不断突破,已经具备了一定的自动化体系,因为盒马业务的特点,盒马属于麻雀虽小但五脏俱全,有独立App,有自营的物流体系,有自己的供应链体系,因此在自动化方面,我们从最基础的单元测试、到接口测试、再到领域场景自动化及跨领域的自动化以及端的自动化方面都有积累。即便如此,我们的代码覆盖率在超过50%之后很难有比较大的提升,另外,代码的覆盖并不能全部代表业务场景的覆盖,一些线上漏测的问题仍然偶尔发生,因此,对于盒马来说,基于较全场景的测试是必须。

image.png

在这种背景下,盒马质量团队进行了较全场景驱动自动化测试的探索,利用线上数据建立测试场景模型。下面会更加详细的进行讲述。

2 业务场景全覆盖的挑战

从业界来说,比较难的也同样是如何用比较简单的手段做到业务的全场景覆盖,对盒马来说也同样。

首先,盒马的业务场景众多,包括inbound与outbound全流程,端到端的全流程多业态,含O2O模式、B2C模式、F2模式、Mini模式、Mall模式、X会员店模式、产地量贩模式、盒马邻里模式等。这么多种业务场景很难一一枚举。

其次,业务场景自动化编写效率也较低,在人工枚举场景,脚本化实现,这种效率比较低,场景难以枚举全,容易遗漏。

业务场景的真实覆盖率也难以度量,人工枚举的业务场景极易有遗漏,线上已频发漏测问题,无法覆盖线上全量场景,同时测试的场景覆盖率难以衡量,需要找到线上场景分母。

传统自动化来说,校验一般基于字段级别,容易遗漏。传统校验方式根据预期逐个字段加断点校验,新增字段或缺失字段极容易造成遗漏。

image.png

因此,在这种多种挑战下,我们尝试了基于线上海量数据模型构建全行经模型,同时用场景驱动自动化执行的方案。

3 场景模型驱动自动化的思考

回到本文初心,我们希望通过线上场景来驱动自动化测试的方式进行测试场景的全量覆盖。思路如下:

一、场景业务模型构建:重点在于如何自动化的构建出场景化的模型数据。大致的思路为:1)线上执行过后的订单数据存在诸多特征;2)根据线上落盘数据进行特征值分析;3)构建数据特征集合与对应的样本数据;

二、执行链路构建:重点在于如何自动构建出克执行的系统调用链路。大致思路为:1)基于落盘数据获取线上执行全链路的所有鹰眼;2)根据鹰眼(trace)及系统调用关系构建执行链路;3)执行链路编排构建链路执行能力;

三、执行结果的校验:重点在于如何自动的进行结果数据的一致性校验。大致思路为:1)所有的数据最终会持久化落盘;2)基于持久化数据进行全字段对比;3)忽略规则配置;

image.png

三 解决思路

1 模型驱动自动化解决策略

结合上文的背景及思考,推演出本文的模型驱动自动化解决策略包含:特征提取、场景建模、链路执行、结果验证、覆盖率分析、缺陷定位及报告。

image.png

2 业务场景建模问题定义

针对业务场景模型,我们首先要思考我们面向的是什么系统,系统的规律是什么,该系统的哪些数据可以被规则化出来的,如何规则出来,最终如何表达,带着这些问题我们一步步介绍我们的解决方案。

image.png

业务场景建模-特征提取方法

本节重点介绍特征提取的通常方法,当前阶段,我们是以数据库的全量数据作为特征提取的来源,当然不少团队也在尝试使用接口调用过程中的全量入参数据。具体为:

1)DB全量数据查询:通过odps查询方式获取全量多表关联数据,用以作为分析的数据源。

2)数据的聚合:对于查询的数据进行信息补齐后,字段打平,采用聚类的方式针对每一字段进行聚合,以出现有限数量的字段作为特征字段进行基线特征的沉淀,对于离散型的数据会选择合适的区间进行分段处理。

3)特征推荐:针对上述聚合的内容进行推荐,此部分会将潜在的特征字段全量进行推荐。

4)特征基线沉淀:基于推荐的数据,结合专家经验进行特征字段的选取,并进行标注选择为基线特征。

image.png

接下来一一根据细化场景进行介绍。

业务场景的建模-特征提取过程

如下图所示,为数据表数据示例,从数据层面可以看出,有一部分字段是有意义的,如isParent是否主单,businessType业务类型,orderTerminal订单终端类型等等,也有一部分字段是离散且无意义的,如orderId订单ID,itemId商品id,GMTCreate创建时间等。特征提取的过程目标就是自动的提取出有意义的字段,忽略无意义的字段。

image.png

实际实践过程中,我们通过不断的迭代以提升特征的精准度与全面度,具体的核心几个提取过程为:

1、特征扩充:元数据中的字段有可能为原始数据,这部分需要关联到具体数据表并找出有意义的字段。

2、特征分类:根据数据的聚合,对于有意义的离散类型数据,比如订单总价,往往我们希望得到零价订单,高值订单及普通订单三类,这三类是未自动打标的,需要我们聚合出范围在特征提取过程中动态识别并分类。

3、特征聚合:依赖于特征的规则,进行所有字段的聚合,最终根据枚举类型字段出现次数进行有效判断,目前我们设定的值为20,这个值可以动态调整,仅仅为参考值而已。

4、特征决策:针对聚合出来的潜在特征,进行基于代码、经验、默认值等多种维度的判断,最终进行特征的推荐,这部分因为业务属性比较重,我们在推荐出来的同时,最终更依赖于专家经验进行字段的最终判断,目前推荐出来和最终采纳的比例约为50%,我们后续会升级算法和参考维度进一步提升采纳率。

image.png

接下来,针对以上流程中关键环节会进行一一介绍。

1)特征提取-特征扩充

本文举例商品及仓的场景,对于商品根据商品id关联找到对应商品明细,再将商品明细中有意义的字段,比如:是否是危险品、是否是紧急配送商品、商品的标签、商品的状态等等查询出来关联主数据,对于仓关联查出仓的类型和仓的标签,如此可基于场景的主模型数据进行分支场景的多层级关联,将需要关注到的场景维度值尽可能多的纳入到数据模型中。

image.png

2)特征提取-特征聚类

本文举例对于加工时长bomCost字段,对于标品来说是0,对于加工品来说,比如鱼类,需要增加15分钟宰杀作业时间,对于凉拌菜等需要增加10分钟进行制作等等。此处会单独将特定字段进行区间分类,如此将分类后的值进行特征的挖掘基础,即可将离散的值变得有意义。

image.png

3)特征提取-特征聚合

将所有数据进行扩充完毕后,将所有相关字段进行打平处理,根据相同字段进行值的聚合,相同值记录次数,不相同时进行归类,如此便可将相关数据进行初始化的数据处理,然后根据聚合出来的数据进行默认值个数的判断进行特征的推荐。

image.png

4)特征提取-特征决策

依赖上述聚合出来的全量潜在特征数据,在特征决策模块会基于代码中抽象出的特征字段进行匹配,当然最重要的是依赖于业务领域的测试专家经验进行主动识别标注,最终沉淀出领域的基线特征集合。

image.png

以盒马某业务领域为例,下图展示的是最终有效的特征集合,根据基线特征,我们的做法是都标注了具体的含义,如此,便可很容易根据一个领域的业务特征识别出该领域的数据场景。

image.png

同样,根据特征情况,也可以刻画出每个领域的特征模型,如下图所示,很轻松的看出领域的全量特征,同时根据每个特征,可以清晰的看出每个特征值的分布占比情况。

image.png

业务场景建模-场景提取

有了基线特征后,基于基线特征形成解析规则,再将全量数据基于特征规则匹配处理,对于命中规则的进行打标处理,即可识别出匹配基线特征的数据集合,这些数据集合对于每一条数据代表的特征组我们称之为场景。具体的处理流程如下图所示。

image.png

进行特征规则匹配处理后,可识别出场景集,这些场景的集合对我们来说至关重要,因为这些场景集合从一定意义上要代表我们的线上全量场景。如下图所示,除了有场景的推荐,还有场景对应的数据的推荐。这些数据后续我们会进行处理并进行执行链路的驱动。

image.png

以下为推荐以驱动链路自动化执行的场景及数据情况。

image.png

3 执行链路分析及构建

前文有介绍盒马很多业务领域都是链路式驱动类型,所以对于如何构建出领域的执行链路很关键,我们的思路是通过系统的调用日志及鹰眼trace相结合的方式进行聚合清洗得到领域的大概执行链路推荐,这里面的推荐会有多种情况。整体的思路如下图。

image.png

执行链路推荐出来后,这时候的链路还是无法执行的,我们的目标是根据推荐能够自动生成执行链路,只是当前基于进展的考虑,我们先将推荐的链路进行人工链路编排以执行场景模型中的数据。以盒马"履约"领域的系统执行流程链路为例,如下,我们将对所有业态的数据的处理进行统一流程编排,如此,即可更大限度和真实的处理模型数据。

image.png

4 数据校验

数据执行完成之后,对于自动化来说一个最关键且有意义的事情是进行结果的校验,为了能够更全面的比对结果,我们将执行链路进行线上生产环境和测试环境的双向执行,对于两套环境的结果数据进行全量的数据比对,可将比对结果精确到像素级别。

image.png

5 场景覆盖率分析

针对场景覆盖率,我们将场景模型所转换的测试数据对应的全量场景与线上全量场景进行比较得出场景覆盖率。在今年的OKR目标下,我们也是目标将业务场景覆盖率达到80%以上。

image.png

四 产品解决方案

1 产品解决方案架构图

结合以上核心模块的介绍,系统的产品解决方案框图如下所示,基于核心的场景模型驱动自动化执行过程为基准,分为业务场景建模模块、测试数据生产模块、回归策略执行选择模块、链路用例执行、结果校验以及结果推送模块。基于运维视角,包含统计大盘、用例管理等。

image.png

在盒马场景探索的场景模型驱动自动化,已经在交易、履约、商品、配送、自提等诸多领域进行了实践,并取得了一定的成果。同时在发布回归、小量数据的常规化压测、系统重构、线上业务巡检等诸多场景中获得了不错的使用。

五 实践结果

基于场景模型驱动自动化的模式,已经在盒马事业群内多个团队进行了推广接入使用,整体上累计沉淀有效的场景化用例2000以上,场景的特征覆盖率均大于90%,各个领域新接入业务的自动化构建成本直线降低80%以上,有效的解决了传统脚本方式的人工依赖过重,引流方式无法覆盖链路场景的问题,也成为团队内重要的发布前的回归可信赖保障手段。

1 在盒马交易领域的实践

盒马交易域是比较早的实践方之一,基于上述方案,交易域进行了整体的方案对接,沉淀了大量的场景及回归用例。尤其交易领域在覆盖率提升方面做了较多的工作。

在交易领域的特征覆盖率的提升经过了以下几个阶段,初始的测试单据(日常测试单据+链路自动化单据)特征覆盖率仅50%左右,覆盖率确实不高,通过覆盖率报告的分析发现,除了确实无单据覆盖的特征,还有一类问题是有单据覆盖但是平台无法匹配上的特殊字符类特征值或不可穷尽枚举类特征值,经过二次处理后,特征覆盖率提高到65%左右;第三阶段,现有的全业态全场景用例构建出来后覆盖率提升到90%左右,剩余的10%特征基本是线上特定时期小概率出现场景阶段性单据没分析到或暂时无法构建数据的特征,经过指定单据有针对性地补充后特征覆盖率达到96%,至此覆盖率达到我们期望的95%以上,基线用例搭建完成。

image.png

因此,从最终结果看,交易领域属于基于最终结果反推过程执行,整体接入过程,基于场景构建与链路编排的执行能力,结合自身能力的构建,接入过程约三周,推荐场景累计2000多例,对8种业态进行全面支撑,能够做到快速的回归覆盖,很好的做到需求的高质量持续交付。

image.png

2 在盒马其他典型领域的实践

在商品领域,从全新的领域对接,整体投入2天,完成500+线上场景的接入,整体投入成本下降高达90%,代码覆盖率在原有脚本自动化基础上提升了28%,快速达到50%以上。

在履约领域:整体沉淀场景化链路用例1000+,成功率95%以上,特征覆盖率95%以上,链路的仿真精准度90%以上,全面保障履约域的质量。

在配送领域:配送域沉淀场景化链路用例300+,作为作业操作的系统,链路场景的覆盖率97%以上,特征覆盖率100%,新业务的自动化成本下降80%以上。

image.png

六 未来展望

基于场景模型驱动自动化实现,只是开始,远没有终结,前期只是针对一部分领域进行了探索实践落地,接下来希望能够扩展更多领域的同时,更加深入的挖掘自动化用例自动生成及测试数据保活的能力,使之能够更好的服务好盒马的各团队业务,也希望通过本文的分享,启发更多的团队一起投入进行探索并做出尝试。

image.png

七 结束语

本文的探索方案前后历时近一年半的时间,从0开始投入,团队也累计多人参与,投入虽大,但给我们的质量保障工作带来了不错的回报,接下来的时间里也会继续前行探索,勇于尝试。

原文链接
本文为阿里云原创内容,未经允许不得转载。 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/512081.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

基于 KubeVela 的 GitOps 交付

简介: KubeVela 是一个简单、易用、且高可扩展的云原生应用管理和交付平台,KubeVela 背后的 OAM 模型天然解决了应用构建过程中对复杂资源的组合、编排等管理问题,同时也将后期的运维策略模型化,这意味着 KubeVela 可以结合 GitOp…

BCS2022大会将提前至5月 网络安全产业空间扩容将成热门话题

年度网络安全的盛会即将开启。 2022年3月30日,2022年北京网络安全大会(BCS2022)新闻发布会在北京奇安信安全中心召开,宣布2022年北京网络安全大会“提档”至5月24日至26日,并与北辰集团国家会议中心达成战略合作&#…

基于 Istio 的全链路灰度方案探索和实践

简介: 本文介绍的基于“流量打标”和“按标路由” 能力是一个通用方案,基于此可以较好地解决测试环境治理、线上全链路灰度发布等相关问题,基于服务网格技术做到与开发语言无关。同时,该方案适应于不同的7层协议,当前已…

图像检索在高德地图POI数据生产中的应用

简介: 高德通过自有海量的图像源,来保证现实世界的每一个新增的POI及时制作成数据。在较短时间间隔内(小于月度),同一个地方的POI 的变化量是很低的。 作者 | 灵笼、怀迩 来源 | 阿里技术公众号 一 背景 POI 是 Poin…

Redis HyperLogLog 是什么?这些场景使用它~

作者 | 就是码哥呀来源 | 码哥字节在移动互联网的业务场景中,数据量很大,我们需要保存这样的信息:一个 key 关联了一个数据集合,同时对这个数据集合做统计。统计一个 APP 的日活、月活数;统计一个页面的每天被多少个不…

matlab三角形分割,MATLAB 2014b及以上版本中带有画家渲染器的三角形拆分补丁

在解决实际问题之前,这是一个值得怀疑的解决方法:对角线只是三角形之间的空白区域,所以我们看到的是补丁后面的白色空间.愚蠢的想法:让我们用匹配的颜色填充该空间而不是白色.为此,我们将复制所有对象,并通过一个tiiiiny位来抵消新对象.码:hi…

网易云音乐音视频算法的 Serverless 探索之路

简介: 网易云音乐最初的音视频技术大多都应用在曲库的数据处理上,基于音视频算法服务化的经验,云音乐曲库团队与音视频算法团队一起协作,一起共建了网易云音乐音视频算法处理平台,为整个云音乐提供统一的音视频算法处理…

小小的 likely 背后却大有玄机!

作者 | 张彦飞allen来源 | 开发内功修炼今天我给大家分享一个内核中常用的提升性能的小技巧。理解了它对你一定大有好处。在内核中很多地方都充斥着 likely、unlikely 这一对儿函数的使用。随便揪两处,比如在 TCP 连接建立的过程中的这两个函数。//file: net/ipv4/t…

阿里云马涛:因云进化的基础软件

简介: 基础软件的云原生化。 编者按:2021 年10 月20 日,在2021 云栖大会云计算产业升级峰会上,阿里云“因云而生”云原生心智大图正式发布,包含弹性计算、云网络、基础产品、基础设施、操作系统、云安全、开放平台等7个…

阿里云ECI如何6秒扩容3000容器实例?

简介: 2021年云栖大会现场,阿里云工程师演示了在6秒时间内成功启动3000个ECI,并全部进入到Running状态。本文将为你揭开阿里云ECI是如何做到极速扩容的。 引言 根据最新CNCF报告,有超过90%的用户在生产环境使用容器,…

巧用友盟+U-APM 实现移动端性能优化—启动速度

简介: 移动端性能对用户体验、留存有着至关重要的影响,作为开发者是不是被这样吐槽过,“这个 APP 怎么这么大?”、“怎么一直在 APP 封面图转悠,点不进去”、“进入详情效果有些卡”、“用 4G 使用你们的 APP&#xff…

第25版 OpenStack Yoga 已发布

OpenStack社区今日正式发布第25版-Yoga,该版本通过支持先进的硬件技术如SmartNIC DPUs,优化与云原生软件如Kubernetes、Prometheus等的集成以及减少技术债等方式来保持OpenStack内核的稳定性与可靠性。 OpenStack作为开源基础设施即服务(Iaa…

项目实战总结以及接入U-APM

简介: 导致 App 性能低下的原因有很多,除去设备硬件和软件的外部因素,其中大部分是开发者错误地使用线、系统函数、编程范式、数据结构等导致的。即便是较有经验的程序员,也很难在开发时就能避免所有导致性能低下的“坑”&#xf…

oracle redo 200mb,Oracle的redo log在各场景下的恢复

Oracle的redo log非常重要,redo log损坏将导致数据库开法开启或数据丢失,针对redo log在各种场景下如何打开或恢复数据库,特别模拟测试说明:各场景包括如下(共6个场景):场景一.非归档下inactive状态的redo 恢复场景二.非归档下act…

站在原地就是退步——除了死磕通道,云通讯服务商还该做些什么?

受访嘉宾:吴佳钊,杭州云片网络科技有限公司联合创始人、CTO 当前,全球通信云已经步入2.0时代,最大的变化在于通信形式的变革:传统短信语音的通信形式将逐步向包括即时通讯IM实时音视频RTC的互联网通信转变。尤其在5G时…

Cube 技术解读 | 详解「支付宝」全新的卡片技术栈

简介: 魔方卡片(Cube),让 App 首页实现敏捷更新。 CodeHub#7 正式落幕,来自蚂蚁集团的技术专家「京君」与掘金社区的开发者们分享了「支付宝」全新的卡片技术栈——魔方卡片(Cube)。 京君围绕 C…

庖丁解InnoDB之REDO LOG

简介: 数据库故障恢复机制的前世今生一文中提到,今生磁盘数据库为了在保证数据库的原子性(A, Atomic) 和持久性(D, Durability)的同时,还能以灵活的刷盘策略来充分利用磁盘顺序写的性能,会记录REDO和UNDO日志,即ARIES方…

Web 自动化神器,批量下载美图,可直接导入使用

‍‍作者 | 小碗汤来源 | 进击云原生今天为大家分享一款前端自动化操作神器: Automa。Automa介绍它是一款 Chrome 插件,即使你不会写代码,也能按照自己的需求,完成一系列自动化操作。利用它,你可以将一些重复性的任务实现自动化、…

RocketMQ 5.0 POP 消费模式探秘

简介: POP Consumer—使客户端无状态,更轻量! 作者:凯易&耘田 前言:随着 RocketMQ 5.0 preview 的发布,5.0 的重大特性逐步与大家见面。POP Consumer 作为 5.0 的一大特性,POP 消费模式展现…

【ESSD技术解读-01】 云原生时代,阿里云块存储 ESSD 快照服务如何被企业级数据保护所集成?

简介: 本文描述了阿里云块存储快照服务基于高性能 ESSD 云盘提升快照服务性能,提供轻量、实时的用户体验及揭秘背后的技术原理。依据行业发展及云上数据保护场景,为企业用户及备份厂商提供基于快照高级特性的数据保护的技术方案,满…