微信号:gh_2052d3e8c27d

介绍:TMQ全称是Tencent Mobile(MIG) Quality Center,腾讯移动品质中心.

浏览器Feeds契约测试方案简析

2019-03-14 15:51 lynnmi

背景

在浏览器Feeds的测试工作中,目标主要分为两个方面:

  • 样式

  • 其他功能

所谓样式,即为Feeds下滑过程中每一个条目所展现的形式,也是我们本文测试方案关注的重点,其具体形式如下图所示:

所有Feeds内容都通过服务器端下发,数据下发之后在终端Hippy框架中做Native处理,最终呈现给用户,其大概逻辑如下图所示:

目前Feeds中样式合计66个, 从下面的分布图中可以看出,top10的总量已经超过了95%。

图如下所示:

在分布如此不均衡的情况下,集成测试中为了尽可能覆盖全部样式,我们主要通过两种手段处理。

  1. 通过下拉更新方式刷现网数据,具体出现频率基本一如上图占比;

  2. 端到端测试:通过后台开发配置白名单指定下发样式。如下图所示:

在这种方案下,我们每次的集成测试消耗大致如下:

  1. 外网样式刷2个小时,只覆盖top 8的样式;

  2. 其余样式各业务后台开发,收集测试机器guid,配置白名单,重新发布,等待生效;

  3. 总时间消耗在6H+,后台配置下发时间消耗占比40%+;

  4. 两周发一个版本;

  5. 后台开发同事不堪重负(差点要打我:joy:)。


需求分析

基于以上问题分析,我们需要一套自动化的方案来精简与加速流程。具体需求如下:

  1. 减少后台频繁配置下发数据的频率;

  2. 能准确获取并存储外网真实数据;

  3. 能将外网数据准确发给客户端使用;

  4. 能分析数据格式,并对内容做修改;

  5. 能按需整合不同样式,并下发;

  6. 可简单开启与关闭;

  7. 定期更新维护成本低;

  8. 数据格式能清晰可见。


方案初想:

根据需求分析和固有测试的瓶颈,通过研究实验,我们引入了一个概念:契约测试。

所谓契约测试,简而言之,即在多个互相依赖的模块之间订立契约(Contract),每个模块都只对契约负责,不关心契约背后消费者(Consumer)。而消费者则只针对契约依赖,不关注契约背后的服务方(Provider)。

于是,端到端测试便做了衍生,最终结果如下图所示:

  1. 终端不再直接向后台请求数据,转而向Provider请求;

  2. 后台下发和请求全部由Mock层接管;

  3. Mock到的数据静态存储,并处理之后提供给Provider下发使用。


方案选型对比

基于上面表格对比确认,以及和开发讨论,我们最终决定借鉴Sinon.js来快速设计实现我们的契约测试方案。总体流程图如下图所示:

其中存储数据环节,同步使用python自动分析,并转存成excel与markdown,便于统计以及与产品,开发等同步信息。


应用场景

  • 前端开发同事自测依赖Provider提供数据

  • DailyBiuld自动化冒烟验证

  • 手工集成测试中使用

  • 自动化性能数据收集


最终收益

  • 版本发布周期由两周缩短至一个周

  • 集成测试时间6H+缩短至2.4H左右

  • 后台开发GG不再配置大量回归样式

  • 现网数据 Mock 30s可完全更新


通用性思考

当契约测试接入业务过多的时候,推荐将功能服务器化,做成契约Server 的形式提供,可以相当大的成都节省项目适配成本和维护成本。

 

后期我们会根据每个维度陆续写相关的测试文章,如果你有兴趣,请关注我们哦。



长按指纹识别图中的二维码,获取更多测试干货分享!

 将我们公众号置顶  不会漏掉我们的原创干货哦!

 
腾讯移动品质中心TMQ 更多文章 专项测试之HTTP接口测试还可以这么玩 腾讯视频Mac App自动化测试实践 腾讯视频国际版(Android)电量测试方法研究与总结 Appium+TestNG自动化测试环境搭建(Java版) 使用配置表+Mocha动态生成用例的JSAPI自动化测试
猜您喜欢 【技巧】如何快速按照日期分组 圣人韬光,贤人遁世 好吧,iOS 用户不能赞赏了 Spark专辑:从Scala开始(三),函数式编程 区块链-以太坊学习资料汇总