我们这样做容器分层性能测试

前言

目前闲鱼不少业务正在从H5/Weex升级到Kun（基于W3C尺度&Flutter打造的肴杂高性能终端容器），从测试角度来看，我们盼望这种升级迭代对于用户体验是正向的，所以用好性能测试这把尺度尺就显得格外重要。 早期做性能保障时，我们在一些焦点场景要上线或者上线之后遇到问题时，才去跑一些性能测试，这种方式只知道性能变差了，至于差在那里，就只能反推开发去查问题，效率低且容易出问题。 本年我们提出了基于容器分层的性能测试，目的是提前将性能风险点抛的更前置、更明白，特殊对于Kun，除了容器自己的影响，Flutter引擎也会影响性能体验。
我们要测什么

一、性能指标对齐

在确定我们要做性能分层测试后，第一个问题就随之而来——性能测试到底要测什么，什么样的指标才能够去权衡一个页面的好坏。我们有两个选择： A、业界通用的指标，和友商APP的度量尺度对齐； B、开发打点，测试侧对数据进行洗濯； 我们毫不犹豫选择了方案A，由于我们期望的性能测试并不但是在闲鱼内部赛马，而是说这些数据也能与友商以及业界标杆APP看齐，追求更加极致的用户体验。最终我们KO确定的指标如下：

我们对现有的主干业务场景以及技术栈进行了梳理，并结合焦点的业务场景和关键本领组件，建立对于引擎电商领域焦点的数据观察计谋，沉淀各个本领层和领域层度量体系，用于权衡在各个领域层开展相关性能优化取得的效果。

• 明白基于Flutter引擎层，对齐Flutter页面和Kun页面的度量体系尺度；
  
• 分别基于组件层面和焦点业务，搭建benchMark测试场景；
  
• 回归业务，从焦点业务层观测判断性能优化结果
  

二、分层性能场景

我们按照上文中提及的分层计谋，确定了最终测试的场景，在benchMark中，我们侧重于关注组件和焦点组件场景的性能环境，最后会在闲鱼APP的上层业务中，验证对大盘整体水位的影响，如下图所示为我们性能测试分层覆盖的内容：

三、多维度度量

闲鱼APP是肴杂技术栈，其中包含H5、Weex、Native以及Flutter、KUN，目前闲鱼有许多业务正在逐渐从H5/Weex升级到Kun，那我们如何拉齐尺度，保证APP性能的稳定性呢？ 为此我们通过多维度的测试，来保障性能的稳定：

• 极限压测门槛：使用中、低端机压测，关注在极限场景下，APP是否会出现Abort或crash；
  
• 横向对比：横向对比我们会将技术栈升级前后的两个版本进行对比；
  
• 版本对比：业务迭代跟随版本需做回归，确定版本的颠簸指标；
  
• benchMark测试：构建极速验证版benchMark工具平台，部分场景通过mock数据扫除网络等不稳定因素的干扰，快速验证组件层面的性能颠簸；
  

除此之外，不同的应用场景，我们对指标的使用也略有不同：

 通过以上过程分析，和多维度性能度量体系的建立，我们已经明白了整个性能分层测试的纲领——怎么度量、度量什么内容。接下来就是实操过程——如何更方便、更快捷的把这些数据测出来，同时更直观的展示给开发同学，让他们能够确定自己的优化是有用的。
我们该怎么测

一、测试脚本

滑动速度的快慢，对性能稳定性数据的产出起到关键性作用，我们在性能测试过程中，通过不停的调试优化脚本，最终使滑动的方式只管贴适用户的操作风俗，区分快慢滑场景，对性能数据进行采集。如下图所示为我们模拟用户快慢滑场景的测试录屏。

另外，为了保障脚本的通用性和易用性，我们封装了通用脚本库，在这些库中包含了如何提取环境变量、如何开始性能网络以及一些关于录屏、分帧等操作。对于简单的测试需求，大多数使用者只需要在前台勾勾选选就能够完成测试需求，而不需要每个业务方都投入精力去维护一套测试代码。
二、基建建立与本领升级

我们分析闲鱼现有的性能平台本领，虽然一定水平上能够支持性能分层测试，但是在易用性、扩展性上照旧存在一些缺陷，重要存在以下4个问题：

• 设备列队久：开发同学常常会问使命为什么一直在执行中，然后排查之后发现各人的使命都会集成一台设备上执行。
  
• 使命创建复杂：随着老平台的使用，创建使命表单字段在不停的增长，从而导致创建使命时常常会选错或填错。
  
• 陈诉对比难：老性能平台大多数应用场景是在版本的性能测试，所以陈诉对比本领较弱，许多时候需要各人手动整理几个陈诉来查看差异。
  
• 数据需频繁订正：老性能平台在页面加载时长测试本领上一直比较薄弱，需要测试同学订正每个录屏数据，确定页面加载的起始帧和结束帧，在有大量benchMark测试需求时，这种订正本钱袒露的更加明显。
  

针对以上问题，我们计划了性能实验室2.0，其整体架构如下图所示

1、设备库优化
起首针对设备列队问题，我们扩展了闲鱼的手机设备池，从原有的8台设备扩展到了16台，覆盖了低、中、高机型。同时针对开发同学不知道该选什么设备的问题，我们对各类设备进行了分组圈选打标，以保障各类使命都有不同的设备在执行，在同组设备中，如果开发选择的设备正在执行使命，我们的使命调理体系会在该设备组中选择同样型号的设备来执行使命，这样在进步使命的执行效率的根本上，同时也能让机器分担的使命更加匀称，确保设备的性能水位是基本持平。
2、性能使命模板
针对于使命创建流程长，参数填写复杂容易堕落的问题，我们引入了使命模板的概念。在计划使命模板时只管考虑高扩展性，用户如果有需要额外的字段，只需要通过动态添加相关环境变量即可传入，脚本底层也封装了相关参数获取方法。通过该计划使脚本使命的参数和平台的参数进行解耦，用户在使用模板创建使命时，不需要考虑脚本内部需要的参数以及细节，只需要调整安装包地址即可。

3、建立数据归档
办理了使命创建复杂、执行慢的问题后，遗留下来的问题就是各种类型陈诉的比较。在容器分层性能测试中，我们除了对业务场景进行性能测试，还需要对不同的容器、不同的benchMark进行测试比较，如果仍然采用手工整理数据进行比较本钱高、容易堕落且回溯困难。因此我们对结果展示功能进行了扩展，用户不仅能够查看单次陈诉数据，还能够挑选任意的其他陈诉进行比较，这样开发同学可以在使命结束之后，通过筛选对比，一目了然地确定优化是否有用。

有什么效果

经过一阶段的实践，目前性能实验室2.0已经上线试运行约15天，累计执行使命360余个：

• 人力本钱降低：之前开发创建使命时总是找相关同学答疑，新平台上线后，除了新增模板以及设备需求，该类问题已不存在。同时对于启动时长的起始帧/结束帧的订正问题也给予相识决，从之前的10分钟手动订正降低至2-3分钟确认无误即可。
  
• 高效稳定：使命乐成率94%，设备列队问题得到一定缓解。
  
• **数据分析便捷：**通过新平台，开发同学可以直接任意比较相关实验数据，更快得到测试结论，开释了整理数据的人力。
  
• **分层验证效果：**通过benchMark的建立，负责不同优化点的同学使用对应的benchMark模板即可快速验证其优化效果，各行其是，也能够快速定位到问题。
  
• **问题深入化：**通过新平台的使用以及对比，我们发如今Flutter的一些性能数据网络上存在问题，通过调研相识到相关原因，并找到了新的网络方法。
  

我们还要做什么

目前针对于容器分层性能测试已经实现了一个小的闭环，开发同学已经能够完全自助测试并且分析相关数据，在后期我们会持续深入发掘相关工作。

• 丰富完成benchMark，更细化地确定优化效果以及最终收益
  
• 减少性能测试的等待时间，提升测试效率
  
• 订定尺度的发布尺度要求，保障新技术演进有质有量
  
• 将性能测试前置到版本集成前，性能问题发现更前置
  
• 探索问题定位本领
  

最后： 如果你平时有许多问题想要办理，你的测试职业规划也需要一点光亮，你也想跟着各人一起分享探讨，我给你推荐一个 「软件测试学习互换群：746506216」 你缺的知识这里有，你少的技能这里有，你要的大牛也在这里……

---

资源分享【这份资料必须领取~】

下方这份完备的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。