关于美团:基于接口数据变异的App健壮性测试实践

33次阅读

共计 5830 个字符,预计需要花费 15 分钟才能阅读完成。

本文整顿自美团技术沙龙第 77 期《美团亿级流量零碎的品质危险防控和稳定性治理实际》,次要介绍了对网络返回数据进行变异的客户端健壮性测试实践经验。文章第一局部介绍客户端健壮性测试的基本概念;第二局部分享了基于接口返回数据变异的 App 健壮性测试方案设计的思路;第三局部次要解读了变异数据的结构和异样检测方案设计;第四局部介绍了精简变异数据的摸索计划。

01 什么是客户端健壮性

在维基百科的定义中,健壮性(Robustness)是指一个计算机系统在执行过程中处理错误,以及算法在遭逢输出、运算等异样时持续失常运行的能力。IEEE 中将健壮性定义为零碎或组件在存在有效输出或压力环境条件下能够失常运行的水平。早在 1989 年,Barton Miller 首次提出了含糊测试的概念,通过向指标利用抛出随机字符串的形式来测试 UNIX 应用程序的健壮性;而在 1996 年的 Ballista 我的项目中,钻研人员摸索依据 API 定义的数据类型,对操作系统或软件接口进行自动化测试方法。两个我的项目均以“无应用程序解体或挂起”作为测试验证通过的规范。

在挪动端 App 畛域,健壮性能够了解为 App 运行时遭逢环境异常或者输出异样时客户端可能持续失常运行的能力。

其中,环境异常次要分为操作系统异样、外部环境异样、硬件环境异常三大类。比方内存不足、CPU 负载过高、线程池满载、内存调配失败、网络连接失败等。输出异样次要分为零碎输出和用户输出。比方网络接口返回的数据异样、利用内缓存、数据库文件读写异样,这类的异样属于在零碎输出异样;在电话号码输入框场景,用户输出的空格、富文本则属于用户输出异样。

对于这些危险,如果 App 没有解决,实践上都可能会产生展现异样、交互异样、性能、平安等问题,导致用户无奈持续应用或在应用过程中产生不好的体验。比方用户操作 App 下单过程中,API 申请呈现故障未返回状态码为 200 的响应,App 因为没有获取到预期接口响应的信息而产生解体,就会中断用户的应用流程。

02 基于接口数据变异的 App 健壮性测试方案设计

在理论的客户端测试执行过程中,测试人员会思考测试异样输出的场景,但因为老本无奈做到无穷尽的测试,同时还存在人工执行脱漏的危险。

从美团 App 平台业务的历史故障剖析中,咱们发现:网络申请返回的数据与实现预期不符引发的 Crash 或外围性能缺失问题导致的故障占比最高,且影响面较广。比方接口返回非预期数据时,客户端解决数据类型转换异样导致闪退,即便 5 分钟内操作降级仍影响了百万量级的用户。因而美团平台业务 App 的健壮性测试摸索优先从发现网络申请返回数据导致的异样开始。

针对于发现申请接口返回客户端非预期数据导致的 Crash,或者外围模块缺失问题这个诉求,咱们调研后发现计划的基本原理都是类似的,即以网络申请的原始响应为根底,依据规定进行变异结构,应用代理工具改写响应体返回给客户端,在端上设施做异样检测。然而都存在一些问题不能满足诉求,比方测试变异数据是依据预置或者自定义规定随机生成组合,随机性过大,不能无效拦挡健壮性问题;但如果不做随机,产生的用例组合量过大,测试不能在正当工夫范畴内完结;另外在检测能力方面,不具备发现业务异样或功能模块异样的能力。

因而,咱们联合通用计划做了一些自定义革新,整体检测计划蕴含动态检测和动静检测两局部。

  • 动态检测,次要是指动态代码扫描,将典型代码编写标准问题转化为自定义动态代码扫描规定,管控增量代码,同时长期治理存量危险。比方自定义了 PrimitiveParseDetector、ColorParseDetector,管控业务必须应用健壮性测试通过的工具类。
  • 动静检测是指联合触发机会,结构并注入变异数据后,辨认 App 运行时是否呈现解体、挂起或业务功能模块异样。比方在集成事件 / 回归事件触发自动化测试运行,结构触发异样的数据进行动静测试,而后监测是否呈现了异样。外围动作蕴含结构变异数据和实现检测两局部。比方将接口响应体中示意色彩含意的 Key 对应的 Value 值结构成非色值,而后检测客户端申请解决接口数据时是否呈现解体或挂起。

下文重点介绍端到端的动静检测计划。

03 变异数据的结构和异样检测

对于美团 App 来说,首页有多种状态,对于某种特定状态,除了管制申请数据外还须要管制试验、策略等一系列因素,能力保障测试对象的唯一性。一个页面中蕴含多个异步申请,因而申请的结构也须要和页面门路关联。这些都是采集变异所需的根底数据时须要关注和管制的。

响应体由根本类型数据和复合类型数据组成,雷同根本类型的数据可能具备不同的业务语义,须要依据语义的类型做变异规定的辨别看待,能力保障业务场景笼罩。

因而,如何保障变异数据结构的全面性和准确性,是咱们面临的首要挑战。

要解决数据结构全面性问题,首先要解决页面形容计划,这样能力管制获取根底数据的唯一性。在解决方案中,咱们构建了页面形容的特色规定,解决用户视角的页面标识问题。须要的信息蕴含端信息、页面路由信息、试验策略账号信息、页面标识模块合集等。通过页面申请数据主动录制的形式,自动更新迭代申请数据和页面之间的绑定关系,使得根底数据可能随需要迭代更新,从而通过变异规定结构生成的用例也可能自动更新。

在用例变异生成结构上,对于响应体里的 Value 设置了语义匹配规定,比方字符串的语义可能代表色彩、页面跳转路由、动动态资源链接(即图片资源数据 / 视频文件 /GIF 文件),须要辨别特色别离按语义结构异样数据。比方在图片的变异数据结构里,除了须要结构非图片链接状况外,还要思考不同图片格式、非图片格式以及非非法的图片剪裁格局拼接等场景。

咱们对接口返回数据应用脚本做了初步的语义剖析,人工二次校对后建设了根本数据类型和语义的映射汇合,联合根本数据类型边界值和语义定义了初始的变异规定。而后对历史的线上健壮性问题和线下测试发现的健壮性 Bug 的变异数据进行整顿,作为增补的变异规定。

在自动化测试执行过程中,咱们基于 App 可测性革新提供的能力,对测试场景进行了管制,同时基于布局视图的解析 SDK、App 异样上报 SDK 提供的能力,实现了对 App 异样的通用检测。

04 变异数据的精简计划

随同着变异规定的丰盛,主动生成的数据量级是微小的,数据的变异组合如果依照全笼罩形式来生成组合数量就是指数级增长。比方对于 1 种有 7 种变异取值的变量,如果存在 n 个此类型变量,就会产生 7^n 种数据组合,并且在理论业务场景中很多组合状况是没有意义的。

如何在保障用例结构全面性的状况下精简变异结构的用例数,是咱们面临的第二个挑战。解决方案蕴含 2 个策略:1)数组元素构造统一时,删减结构的用例数;2)构造不完全一致的数组元素,引入编辑间隔和并查集算法判断节点相似性,节点不类似,能够在一次数据生成里做合并结构。

咱们能够把申请响应的 JSON 了解成树,第一个解决思路是判断树中节点、门路的类似度,类似节点删减结构。

如果门路、节点类似,能够揣测门路即业务逻辑也是统一的,比方页面上的一些列表元素,可能是数据结构对象完全一致数组,如果对每个数组对象中的每个元素进行全用例结构,生成的变异数据量极大,且对业务场景或代码逻辑的增量笼罩无限,因而咱们决定将结构逻辑优化,进行删减结构。即如果数组中元素的构造完全一致,那么同含意的字段能够为他们调配不同的变异结构值,而后删减掉有效的结构状况。利用这种办法能够无效升高 28% 左右的用例结构数量。

如图数组的 3 个元素中均存在“resourceName”键值对,如果每个键值对有 3 种变异取值,依照全排列形式进行用例结构将会生成有 9 份变异数据,在删减结构状况下,能够别离为它们结构一个特定的变异值,这样变异生成用例数量能够从 9 缩小为 1。

在对业务接口返回数据的数据结构进行剖析后,咱们发现在层级越深的场景下,间隔根节点越近的两个节点,业务逻辑耦合和构造类似水平越低,它能够进行合并结构,互相逻辑之间不会产生影响,比方有两个键值对,每个键值对的 Value 有 3 种变异取值,在合并结构状况下,能够从排列组合的 6 份数据缩小到 3 份数据。

基于这个个思路,咱们在实践中引入了编辑间隔和并查集算法,以节点门路为参照,对树的每一层的每两个节点计算编辑间隔,生成一个 n * n 矩阵;同时以树的高度减去节点位于的层数作为权重,修改编辑间隔。基于这样的计算,会产生多个编辑间隔矩阵。

为了尝试最大化合并结构用例成果,咱们把编辑间隔做了 0,1 矩阵转化。其中,因为编辑间隔为 1 的两个节点可能存在业务逻辑耦合关系,必须放在同一个组里别离结构,所以咱们把编辑间隔大于 1 的状况转化成了 0,最初失去了一个 0,1 的编辑间隔矩阵。

在 0,1 矩阵状况下,咱们应用了图的连通性概念,如果 A 和 B 连通,B 和 C 连通,那咱们认为 A 和 C 连通,转化到这里的概念就是 A 和 B 类似,B 和 C 类似,那么 A 和 C 类似,它们应该被放在同一个组里离开进行结构,那么在同层元素结构时,咱们会从每个分组里取到一个节点,对这些规定进行变异组合结构。

基于以上两个策略进行精简后生成的变异数据量较精简前升高了 40%,同时代码覆盖率没有显著变动,并且放弃不变的健壮性问题发现能力。

美团 App 和优选 App 都接入了这个工具,在新需要阶段能够人工触发运行,还能够联合客户端组件集成事件和回归事件做主动触发。至今利用一年工夫内,发现了几十个问题。

05 总结及瞻望

在健壮性工具建设一期里,咱们实现了 App 页面加载展现场景的健壮性问题检测,反对解体、卡死和局部性能异样这三类异样检测。另外,基于节点相似性优化变异数据生成策略可能在放弃成果不变的状况下无效管制测试时长,但是否有更优的合并算法和举荐算法,还须要更多的尝试。

在后续工具的迭代还会持续围绕异样结构和异样检测这两个方向,反对更丰盛的结构能力和检测能力,以及更高效的结构效率。短期建设上,咱们将会从业务视角登程丰盛自动化变异数据生成建模,欠缺客户端异样通用异样检测能力,实现通用前后端交互的数据构造类型(比方:长连贯音讯)的笼罩;长期建设上,须要反对更丰盛的数据和环境结构能力,通过智能化用例生成,晋升测试效率。

06 Q&A

Q1:节点类似的判断根据是什么?

A:从理论的 response 剖析来说,两个节点的门路齐全类似就是从根节点到最终的叶子节点上,它们的门路命名齐全类似,数组里两个对象的构造齐全一样。

Q2:用例的生成能举个例子吗?

A:比方色彩色值的格局是 #+ 6 位字符,通常经营配置会呈现的状况是遗记增加#,或色值复制中少了一位。在这种状况下,咱们会结构一个色值,比方没有返回#、色值位数不对、色值增加透明度,把这种场景作为结构状况,在配置里增加上,最初用代码生成。

Q3:健壮性平时执行的频率是什么样的?

A:第一个基于需要维度,需要维度须要人工触发;第二个基于变更维度,当组件产生变更时,能够关联到这段代码或者组件变更的页面,而后触发页面对应的健壮性测试,执行频率会受到组件变更频率的影响;第三个在回归测试时,App 的回归测试两周一次,咱们会把所有页面以及它关联的所有的用例都执行一次。

Q4:对于裸露给前端开发的接口,大部分是人为调用参数的变动,随机性绝对比拟高,对于必填和非必填参数如何确认用例的范畴?

A:目前咱们在实现的计划里,没有辨别参数是必填参数还是非必填参数,所以对于整个数据接口返回里的所有后果都会进行结构,产生的问题是对于非必返回的参数可能产生的问题,到底是否是须要解决的问题,这部分目前通过经营伎俩做确认。

Q5:首页可能调用 10 个接口,而后针对每个字段都进行异样验证吗?

A:对于首页关联的接口,咱们在接口申请、录制过程中和录制完数据后,会对接口进行确认到底有哪些接口是咱们须要验证的,这是一次性的老本,录制实现后,会对每个字段都进行异样验证,当然会有一些黑白名单的设置。

Q6:对色号这种状况有一种生成规定嘛,这个规定是怎么制订?

A:刚刚我只是举了一个色号的例子,其实对于图片、申请的资源文件、配置文件、跳转链接,每一个对应到的业务语义,咱们都有对应的用例生成规定,咱们会依据参考根据,比方第一个是自身咱们在通用的根底库里怎么解决这些问题,这里有一个根底的规定;第二个是咱们积攒了线上问题状况理论可能会产生的谬误或者变异状况,生成第一版根底规定,在第一期工具里找相干研发达成共识,这样的话,数据变异是处于正当范畴。

Q7:执行的时候,如何晓得页面对应哪些规定提前配置?

A:执行时,在测试接入过程中有一个配置过程,它不是配置这个页面和接口的关联关系,而是配置咱们要测试哪些页面,主动触发自动化录制过程,就是到这个页面时,会触发哪些接口申请,生成这个页面和这个接口申请的对应关系,给到对应的配置人做确认,保障哪些接口是真正可能想要结构的,哪些接口不须要结构,最初以这个为基准测试,基于录制过程,比方业务迭代外面产生了新接口,咱们在录制中可能感知到它关联的接口产生了变动,在发生变化时发消息给对应的测试提交人 / 负责人,TA 确认这条规定放到黑名单里还是更新到须要结构的接口里。

Q8:是否有做页面显示的一个校验?怎么做的?

A:目前咱们在页面里的模块做了“是否展现”校验,基于以后集成到美团的可测性 SDK,这个 SDK 会获取到以后页面是否渲染里是否展现了对应模块的信息,通过申请把对应模块形容传给 SDK,通过返回来校验是否展现。

07 参考资料

  • [1] 健壮性:https://en.wikipedia.org/wiki/Robustness
  • [2] IEEE 健壮性:https://ieeexplore.ieee.org/document/7438745
  • [3] Ballista:Carnegie Mellon 大学的钻研我的项目,通过黑盒自动化测试的形式,发现导致系统解体或异样终止的零碎调用或接口调用。
  • [4] 基于布局视图的解析 SDK:美团 App 页面视图可测性革新实际 -XraySDK

| 在美团公众号菜单栏对话框回复【2023 年货】、【2022 年货】、【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词,可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品,著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容,敬请注明“内容转载自美团技术团队”。本文未经许可,不得进行商业性转载或者应用。任何商用行为,请发送邮件至 tech@meituan.com 申请受权。

正文完
 0