场景模型驱动自动化测试在盒马的探索及实践
简介： 盒马业务有如下几个特点：线上线下一体化、仓储配送一体化、超市餐饮一体化、经营作业一体化、多业态与平台化。在以上的种种原因，生鲜及物流体验是盒马的特点，但仓储配送一体化作业中，如何能更高效的提升测试效率也是盒马质量团队的重点探索。
文章图片
作者 | 钦伟
来源 | 阿里技术公众号
一 引言
盒马业务有如下几个特点：线上线下一体化、仓储配送一体化、超市餐饮一体化、经营作业一体化、多业态与平台化。
在以上的种种原因，生鲜及物流体验是盒马的特点，但仓储配送一体化作业中，如何能更高效的提升测试效率也是盒马质量团队的重点探索。
二 背景及待解决问题介绍
1 盒马自动化体系发展新挑战
在盒马，前期业务在狂奔，自动化基础较薄弱，近三年来，经过盒马人的不断突破，已经具备了一定的自动化体系，因为盒马业务的特点，盒马属于麻雀虽小但五脏俱全，有独立App，有自营的物流体系，有自己的供应链体系，因此在自动化方面，我们从最基础的单元测试、到接口测试、再到领域场景自动化及跨领域的自动化以及端的自动化方面都有积累。即便如此，我们的代码覆盖率在超过50%之后很难有比较大的提升，另外，代码的覆盖并不能全部代表业务场景的覆盖，一些线上漏测的问题仍然偶尔发生，因此，对于盒马来说，基于较全场景的测试是必须。
文章图片
在这种背景下，盒马质量团队进行了较全场景驱动自动化测试的探索，利用线上数据建立测试场景模型。下面会更加详细的进行讲述。
2 业务场景全覆盖的挑战
从业界来说，比较难的也同样是如何用比较简单的手段做到业务的全场景覆盖，对盒马来说也同样。
首先，盒马的业务场景众多，包括inbound与outbound全流程，端到端的全流程多业态，含O2O模式、B2C模式、F2模式、Mini模式、Mall模式、X会员店模式、产地量贩模式、盒马邻里模式等。这么多种业务场景很难一一枚举。
其次，业务场景自动化编写效率也较低，在人工枚举场景，脚本化实现，这种效率比较低，场景难以枚举全，容易遗漏。
业务场景的真实覆盖率也难以度量，人工枚举的业务场景极易有遗漏，线上已频发漏测问题，无法覆盖线上全量场景，同时测试的场景覆盖率难以衡量，需要找到线上场景分母。
传统自动化来说，校验一般基于字段级别，容易遗漏。传统校验方式根据预期逐个字段加断点校验，新增字段或缺失字段极容易造成遗漏。
文章图片
因此，在这种多种挑战下，我们尝试了基于线上海量数据模型构建全行经模型，同时用场景驱动自动化执行的方案。
3 场景模型驱动自动化的思考
回到本文初心，我们希望通过线上场景来驱动自动化测试的方式进行测试场景的全量覆盖。思路如下：
一、场景业务模型构建：重点在于如何自动化的构建出场景化的模型数据。大致的思路为：1）线上执行过后的订单数据存在诸多特征；2）根据线上落盘数据进行特征值分析；3）构建数据特征集合与对应的样本数据；
二、执行链路构建：重点在于如何自动构建出克执行的系统调用链路。大致思路为：1）基于落盘数据获取线上执行全链路的所有鹰眼；2）根据鹰眼(trace)及系统调用关系构建执行链路；3）执行链路编排构建链路执行能力；
三、执行结果的校验：重点在于如何自动的进行结果数据的一致性校验。大致思路为：1）所有的数据最终会持久化落盘；2）基于持久化数据进行全字段对比；3）忽略规则配置；
文章图片
三 解决思路
1 模型驱动自动化解决策略
结合上文的背景及思考，推演出本文的模型驱动自动化解决策略包含：特征提取、场景建模、链路执行、结果验证、覆盖率分析、缺陷定位及报告。
【场景模型驱动自动化测试在盒马的探索及实践】
文章图片
2 业务场景建模问题定义
针对业务场景模型，我们首先要思考我们面向的是什么系统，系统的规律是什么，该系统的哪些数据可以被规则化出来的，如何规则出来，最终如何表达，带着这些问题我们一步步介绍我们的解决方案。
文章图片
业务场景建模-特征提取方法
本节重点介绍特征提取的通常方法，当前阶段，我们是以数据库的全量数据作为特征提取的来源，当然不少团队也在尝试使用接口调用过程中的全量入参数据。具体为：
1）DB全量数据查询：通过odps查询方式获取全量多表关联数据，用以作为分析的数据源。
2）数据的聚合：对于查询的数据进行信息补齐后，字段打平，采用聚类的方式针对每一字段进行聚合，以出现有限数量的字段作为特征字段进行基线特征的沉淀，对于离散型的数据会选择合适的区间进行分段处理。
3）特征推荐：针对上述聚合的内容进行推荐，此部分会将潜在的特征字段全量进行推荐。
4）特征基线沉淀：基于推荐的数据，结合专家经验进行特征字段的选取，并进行标注选择为基线特征。
文章图片
接下来一一根据细化场景进行介绍。
业务场景的建模-特征提取过程
如下图所示，为数据表数据示例，从数据层面可以看出，有一部分字段是有意义的，如isParent是否主单，businessType业务类型，orderTerminal订单终端类型等等，也有一部分字段是离散且无意义的，如orderId订单ID，itemId商品id，GMTCreate创建时间等。特征提取的过程目标就是自动的提取出有意义的字段，忽略无意义的字段。
文章图片
实际实践过程中，我们通过不断的迭代以提升特征的精准度与全面度，具体的核心几个提取过程为：
1、特征扩充：元数据中的字段有可能为原始数据，这部分需要关联到具体数据表并找出有意义的字段。
2、特征分类：根据数据的聚合，对于有意义的离散类型数据，比如订单总价，往往我们希望得到零价订单，高值订单及普通订单三类，这三类是未自动打标的，需要我们聚合出范围在特征提取过程中动态识别并分类。
3、特征聚合：依赖于特征的规则，进行所有字段的聚合，最终根据枚举类型字段出现次数进行有效判断，目前我们设定的值为20，这个值可以动态调整，仅仅为参考值而已。
4、特征决策：针对聚合出来的潜在特征，进行基于代码、经验、默认值等多种维度的判断，最终进行特征的推荐，这部分因为业务属性比较重，我们在推荐出来的同时，最终更依赖于专家经验进行字段的最终判断，目前推荐出来和最终采纳的比例约为50%，我们后续会升级算法和参考维度进一步提升采纳率。
文章图片
接下来，针对以上流程中关键环节会进行一一介绍。
1）特征提取-特征扩充
本文举例商品及仓的场景，对于商品根据商品id关联找到对应商品明细，再将商品明细中有意义的字段，比如：是否是危险品、是否是紧急配送商品、商品的标签、商品的状态等等查询出来关联主数据，对于仓关联查出仓的类型和仓的标签，如此可基于场景的主模型数据进行分支场景的多层级关联，将需要关注到的场景维度值尽可能多的纳入到数据模型中。
文章图片
2）特征提取-特征聚类
本文举例对于加工时长bomCost字段，对于标品来说是0，对于加工品来说，比如鱼类，需要增加15分钟宰杀作业时间，对于凉拌菜等需要增加10分钟进行制作等等。此处会单独将特定字段进行区间分类，如此将分类后的值进行特征的挖掘基础，即可将离散的值变得有意义。
文章图片
3）特征提取-特征聚合
将所有数据进行扩充完毕后，将所有相关字段进行打平处理，根据相同字段进行值的聚合，相同值记录次数，不相同时进行归类，如此便可将相关数据进行初始化的数据处理，然后根据聚合出来的数据进行默认值个数的判断进行特征的推荐。
文章图片
4）特征提取-特征决策
依赖上述聚合出来的全量潜在特征数据，在特征决策模块会基于代码中抽象出的特征字段进行匹配，当然最重要的是依赖于业务领域的测试专家经验进行主动识别标注，最终沉淀出领域的基线特征集合。
文章图片
以盒马某业务领域为例，下图展示的是最终有效的特征集合，根据基线特征，我们的做法是都标注了具体的含义，如此，便可很容易根据一个领域的业务特征识别出该领域的数据场景。
文章图片
同样，根据特征情况，也可以刻画出每个领域的特征模型，如下图所示，很轻松的看出领域的全量特征，同时根据每个特征，可以清晰的看出每个特征值的分布占比情况。
文章图片
业务场景建模-场景提取
有了基线特征后，基于基线特征形成解析规则，再将全量数据基于特征规则匹配处理，对于命中规则的进行打标处理，即可识别出匹配基线特征的数据集合，这些数据集合对于每一条数据代表的特征组我们称之为场景。具体的处理流程如下图所示。
文章图片
进行特征规则匹配处理后，可识别出场景集，这些场景的集合对我们来说至关重要，因为这些场景集合从一定意义上要代表我们的线上全量场景。如下图所示，除了有场景的推荐，还有场景对应的数据的推荐。这些数据后续我们会进行处理并进行执行链路的驱动。
文章图片
以下为推荐以驱动链路自动化执行的场景及数据情况。
文章图片
3 执行链路分析及构建
前文有介绍盒马很多业务领域都是链路式驱动类型，所以对于如何构建出领域的执行链路很关键，我们的思路是通过系统的调用日志及鹰眼trace相结合的方式进行聚合清洗得到领域的大概执行链路推荐，这里面的推荐会有多种情况。整体的思路如下图。
文章图片
执行链路推荐出来后，这时候的链路还是无法执行的，我们的目标是根据推荐能够自动生成执行链路，只是当前基于进展的考虑，我们先将推荐的链路进行人工链路编排以执行场景模型中的数据。以盒马"履约"领域的系统执行流程链路为例，如下，我们将对所有业态的数据的处理进行统一流程编排，如此，即可更大限度和真实的处理模型数据。
文章图片
4 数据校验
数据执行完成之后，对于自动化来说一个最关键且有意义的事情是进行结果的校验，为了能够更全面的比对结果，我们将执行链路进行线上生产环境和测试环境的双向执行，对于两套环境的结果数据进行全量的数据比对，可将比对结果精确到像素级别。
文章图片
5 场景覆盖率分析
针对场景覆盖率，我们将场景模型所转换的测试数据对应的全量场景与线上全量场景进行比较得出场景覆盖率。在今年的OKR目标下，我们也是目标将业务场景覆盖率达到80%以上。
文章图片
四 产品解决方案
1 产品解决方案架构图
结合以上核心模块的介绍，系统的产品解决方案框图如下所示，基于核心的场景模型驱动自动化执行过程为基准，分为业务场景建模模块、测试数据生产模块、回归策略执行选择模块、链路用例执行、结果校验以及结果推送模块。基于运维视角，包含统计大盘、用例管理等。
文章图片
在盒马场景探索的场景模型驱动自动化，已经在交易、履约、商品、配送、自提等诸多领域进行了实践，并取得了一定的成果。同时在发布回归、小量数据的常规化压测、系统重构、线上业务巡检等诸多场景中获得了不错的使用。
五 实践结果
基于场景模型驱动自动化的模式，已经在盒马事业群内多个团队进行了推广接入使用，整体上累计沉淀有效的场景化用例2000以上，场景的特征覆盖率均大于90%，各个领域新接入业务的自动化构建成本直线降低80%以上，有效的解决了传统脚本方式的人工依赖过重，引流方式无法覆盖链路场景的问题，也成为团队内重要的发布前的回归可信赖保障手段。
1 在盒马交易领域的实践
盒马交易域是比较早的实践方之一，基于上述方案，交易域进行了整体的方案对接，沉淀了大量的场景及回归用例。尤其交易领域在覆盖率提升方面做了较多的工作。
在交易领域的特征覆盖率的提升经过了以下几个阶段，初始的测试单据（日常测试单据+链路自动化单据）特征覆盖率仅50%左右，覆盖率确实不高，通过覆盖率报告的分析发现，除了确实无单据覆盖的特征，还有一类问题是有单据覆盖但是平台无法匹配上的特殊字符类特征值或不可穷尽枚举类特征值，经过二次处理后，特征覆盖率提高到65%左右；第三阶段，现有的全业态全场景用例构建出来后覆盖率提升到90%左右，剩余的10%特征基本是线上特定时期小概率出现场景阶段性单据没分析到或暂时无法构建数据的特征，经过指定单据有针对性地补充后特征覆盖率达到96%，至此覆盖率达到我们期望的95%以上，基线用例搭建完成。
文章图片
因此，从最终结果看，交易领域属于基于最终结果反推过程执行，整体接入过程，基于场景构建与链路编排的执行能力，结合自身能力的构建，接入过程约三周，推荐场景累计2000多例，对8种业态进行全面支撑，能够做到快速的回归覆盖，很好的做到需求的高质量持续交付。
文章图片
2 在盒马其他典型领域的实践
在商品领域，从全新的领域对接，整体投入2天，完成500+线上场景的接入，整体投入成本下降高达90%，代码覆盖率在原有脚本自动化基础上提升了28%，快速达到50%以上。
在履约领域：整体沉淀场景化链路用例1000+，成功率95%以上，特征覆盖率95%以上，链路的仿真精准度90%以上，全面保障履约域的质量。
在配送领域：配送域沉淀场景化链路用例300+，作为作业操作的系统，链路场景的覆盖率97%以上，特征覆盖率100%，新业务的自动化成本下降80%以上。
文章图片
六 未来展望
基于场景模型驱动自动化实现，只是开始，远没有终结，前期只是针对一部分领域进行了探索实践落地，接下来希望能够扩展更多领域的同时，更加深入的挖掘自动化用例自动生成及测试数据保活的能力，使之能够更好的服务好盒马的各团队业务，也希望通过本文的分享，启发更多的团队一起投入进行探索并做出尝试。
文章图片
七 结束语
本文的探索方案前后历时近一年半的时间，从0开始投入，团队也累计多人参与，投入虽大，但给我们的质量保障工作带来了不错的回报，接下来的时间里也会继续前行探索，勇于尝试。
原文链接
本文为阿里云原创内容，未经允许不得转载。
推荐阅读
- 两感一练
- Flutter的ListView
- 一般模型化关系——从模型是什么到如何起作用的基本答案
- 呼和浩特市绿地广场景观管理局
- 190403|190403 - Jmeter压测接口
- 词（apt）
- Spring注解驱动第十讲--@Autowired使用
- Pytorch学习|sklearn-SVM 模型保存、交叉验证与网格搜索
- 旅途碎碎念
- jvm|【JVM】JVM08(java内存模型解析[JMM])