摘要
多点作为一家先进的全渠道数字零售服务提供商,对接了百余家连锁零售商,每一个商家甚至每个门店都有独有的配置需求以及个性化推荐服务,而这些数据最终通过多点APP,微信小程序,支付宝小程序等前端呈现给我们的用户,就单单以某商家下的某个门店为例,其首页一级页包含了超过1800条的数据,关联的二级页中的数据量更是超过3000,而在数据接口下发正常的情况下如何保证这些数据的质量,这是值得我们去深入研究的一个方向。遇到的问题
多点APP首页的数据主要来源于后台配置和推荐下发两种,都是统一在我们的内容管理系统CMS(Content Management System)做配置然后通过垂直网关下发到前端的。对于推荐类的数据,我们则需要不断的对实际召回的数据做结果和效果方面的分析,从而持续优化我们的推荐算法;而配置类的内容,尤其是人为配置的部分,不可避免的会出现因为配置错误从而引发线上的一些体验问题,所以在走查早期的APP首页时,经常会出现如下的一些问题:业务和技术部门之间平平无奇的某一次对话
老板:首页上的某某商品在APP中点了没有任何反应呢?
研发:运营在配置商品时,选择了自定义跳转,但跳转的链接没有配置数据。
产品:我们联系下运营同学修改下配置。
运营:收到,我们马上处理。
测试:现在已经好了,点击商品可以跳转到商品详情页了。
业务和技术部门之间平平无奇的又一次对话
产品:首页上点击某个活动后页面报错了。
研发:这个活动页配置的链接前面多了两个无关的字符,导致链接无法打开。
运营:多余字符已去掉,但在Android中还是打不开,iOS可以。
研发:这个活动页链接最前面还多出来一个空格。
运营:额,那我再修改下链接。
业务和技术部门之间平平无奇的再一次对话
测试:线上某某活动页里商品都售罄了,好几个门店都是如此。
研发:我们马上排查下。
Two thousand years later ...
研发:后台系统和接口都是正常的,是不是活动配置的商品在这个门店都没库存了?
运营:活动页里面之前配置的商品都售罄了,我们先把链接下掉,更换商品后再重新发布。
类似的场景在日常的工作中经常遇到,面对海量的数据,我们不可避免的遇到很多数据不可用或者数据质量不佳的情况,而这些问题也会直接影响到我们的用户体验。作为专业的测试人员,我们该如何去从众多的商家、门店、业态等多维度下及早发现这些问题,从而推动我们后台的配置系统不断去迭代优化,最终从系统层面彻底解决这些问题。解决问题的前提是我们能发现问题。如果把我们线上所有门店展示的首页数据加起来,数据会在数十万甚至百万级别,以上面的门店为例,一个门店首页的数据量超过了1800,想要在这么多数据中间去找到有问题的数据,显然依靠传统的手工测试几乎是不可能的事情,加上这些数据也是随着后台配置,商品状态,促销活动,用户信息等维度的变化而随时变化的,因此建立起一套能够支持动态数据驱动的接口自动化测试框架就显得尤为重要。数据质量初定义
在开始去做自动化测试之前,我们需要梳理数据质量的一些关注点,并根据这些关注点去建设我们对于数据质量的一些度量标准。结合我们首页支持的数据单元,对于商品我们可能会去考虑:商品的状态
商品的价格
商品的标签
促销标签是否显示,显示的标签是否在二级页中存在
推荐标签是否显示,显示的标签是否与二级页中一致
活动页是否可以正常打开,打开的速度怎样,有没有特别慢的情况出现
活动页是否包含商品,文字,图片等内容,是否只是一个空白页或者只有兜底的图片
活动页中商品的状态是怎样,其中是否会显示下架的商品,售罄的商品占比是怎样
活动页中商品的利益点是否展示正确,价格是否和商品详情页中一致
当我们拿到整个首页的数据之后,我们还可以做一些更加深入的数量分析,比如是否有重复配置的数据,重复的数据分布是怎样的,配置的数据和推荐下发数据的重合度有多高,推荐的数据是否符合了一般的排序规则(如价格的升序降序排列,根据销量计算的热力值,根据价格计算的降价幅度等),而这些数据分析的结论有助于我们去帮助运营同学从宏观上把握首页整体的数据情况,从而有针对性的去调整我们首页数据的配置策略,从而达到不断改善运营效果的目的。
基于这些自动化的测试结果,我们结合实际的情况,衍生出一套初步的门店首页数据质量评估的算法DQI出来。DQI是Data Quality Index的缩写,这个指标其实就是首页这些数据质量的一个索引,详细的计算规则我们会在后续的分享中提出来。通过这个算法计算出来的DQI值,可以用于在不同门店之间做横向的对比,以及在不同的测试轮次中做纵向的对比,从而更加直观和明确的看出来线上各个商家门店中的首页质量情况。自动化测试框架autoPyHome
说到这里,我们的目标已经十分明确,那接下来如何通过自动化测试的方式来实现就是我们需要讨论的问题了。业界有很多非常不错的接口自动化测试框架,我们也逐一做了调研,但这些框架大部分都把重点放到了测试执行的过程处理,而不是测试结果的数据分析,所以我们最后秉着“没有最好的,只有最适用的”的理念自研了autoPyHome接口自动化测试框架。这个框架最早是在Python2.7的版本开发的,后来升级到3.x的版本,结合最基础的unittest+requests+HTMLTestReportCN这些库,最终实现了我们上述的自动化测试的目标,其中我们解决了如下几个主要的问题:构建动态测试数据
测试用例的自动化生成
动态变化的数据如何动态组装成测试用例
动态生成的测试用例如何体现到测试报告
接口数据的多层次断言
基于上述的一些梳理,我们最终形成了我们autoPyHome自动化测试框架的基本原理以及特点,基本上可以用如下的一张图来概括,详细的内容我们也将在后续的分享会上来做分享。
当然,在实际开发的过程中,我们还遇到了很多的挑战。比如在处理接口传参时,我们需要考虑单Key+单Value和多Key+多Value的形式。在单Key的接口类型中,其对应的Value中可能嵌套4层以上的子键值对,这对我们去组装测试参数提出了更高的要求。再比如当整个框架开发完成并部署到我们的CI系统后去实际运行的过程中,我们多次遇到请求接口时出现http.client.BadStatusLine异常导致测试用例初始化失败的情况,而在接口返回数据解析时出现JSONDecodeError("Extra data", s, end)错误导致数据解析失败而阻塞后续其他测试用例的情况,这需要我们在系统已有的异常之上做好代码保护以增强健壮性。另外,随着这个框架集成的自动化测试脚本越来越多,测试执行所需要的时间也直接上升,如何使用多线程的方式来并行执行测试用例也显得越来越重要,目前一轮常规自动化测试覆盖用例24000+,测试时长在90分钟左右,测试执行完成后将以如下的邮件形式发送到相关人员,如有重点关注的失败项则在测试执行时就会第一时间通过飞书机器人发到送指定人员。预告一波:今年10月24日下午14:00-18:00,D+Talks 2021多点技术大会将拉开帷幕,我们将分享更多autoPyHome接口自动化测试框架相关的内容,欢迎有兴趣的同学积极报名参与,与行业大咖共同探讨!