请选择 进入手机版 | 继续访问电脑版
查看: 604|回复: 0

移动端的快速健壮性测试探索

[复制链接]

353

主题

373

帖子

9万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
99935
发表于 2017-11-23 16:55:56 | 显示全部楼层 |阅读模式
一、前言
健壮性是指系统对于规范要求以外的各种输入进行处理的能力。是系统稳定性的重要指标之一。
在“云+瘦客户端”时代,app一般使用接口的方式,与云端进行资源交换。app的健壮性最直观的一部分就体现在与云端资源交换过程中的健壮性,比如:
  • 对云端返回的各种非规范要求数据返回值,app能否作出正常的反应。
  • 弱网条件下与云端交互,app能否作出正常的反应。
等等。这些是引发app crash的主要凶手之一,也应成为app功能测试中的重点。


二、项目背景

在我负责的项目app测试过程中,所有的服务都是采用api进行交互的,目前app已接入了数十个第三方系统api,未来还有扩展的趋势。如此健壮性测试就遇到以下难点:
  • 很多第三方系统,直接接线上环境。在测试环境要怎么测?
  • 就算在线上版本使用了线上环境,由于权限等限制,没有办法在线上第三方系统模拟各种非常规数据,怎么破?
  • 一般测试时间很紧张,采用搭建mock服务器的方式进行模拟,时间上完全来不及,该如何应对?
  • 模拟弱网条件,测试app的网络健壮性,怎样才能快速模拟?
......
因此,随着项目实践的深入,我一直在探索一种实用解决方案,不仅要能解决问题,还要能快速的解决问题。


三、解决方案

主要思路就是:Fiddler抓包+AutoResponder拦截并且Mock数据+Fdiddler Sricpt网络限速


1.Fiddler抓包

原理:通过设置手机无线网手动代理(设置ip和port),将app请求发送至Fiddler。由此Fiddler就可以抓取app发出的网络请求数据。
具体步骤不在此详述。重点要注意,如果抓取https包并且需要对内容进行解密,需要进行如下设置。



2.AutoResponder拦截和Mock数据

(1)AutoResponder支持多种拦截方式,如下图:

比如最常用的: 无前缀:表示基本搜索,表示搜索到字符串就匹配
前缀为Match:代表全匹配,大小写敏感。就是url必须完全一致的才能被Fiddler拦截
前缀为regex:代表匹配符合正则表达式规则的请求,并进行拦截
等等
小技巧:如果觉得url较长导致设置拦截url比较繁琐,可以直接把左侧抓取的接口,拖动到右边,然后适当的修改,这样效率很高。


(2)返回Mock数据
首先快速获取基础数据。如下图所示:

从抓取的待测试接口,保存正常情况下返回的数据,作为基础数据,进行保存,假设命名为:testdata.txt
然后打开testdata.txt,并对里面返回的数据内容根据测试用例进行修改,改成任意你想要测试数据,作为mock数据


(3)模拟服务器返回数据
将上述mock数据,作为待测试被拦截接口的返回值,返回给app。如下所示:

如上,在拦截接口的返回值里,选择find a file,然后选择testdata.txt作为返回数据。
至此,就可以对app的接口,给他模拟任何的非规范数据,测试app的处理健壮性了。


3.快速模拟弱网

Fiddler支持,通过script来快速控制网速,如下所示:

request-tricky-delay: 代表每上传1KB数据,延迟多少毫秒
response-tricky-delay:代表每下载1KB数据,延迟多少毫秒
修改之后,保存,可以模拟出网络的状态。并且是热切换的。保存生效,不需要重启Fiddler之类的。


四、应对的测试场景

在日常测试中,采用上述的方法,能快速灵活的应对哪些测试场景呢?
(1) 接口的各种异常返回码测试
只需要修改基准测试数据中的返回code即可
(2) 接口的各种异常返回字段值(比如,名字太长这样的值,在app端是否会自适应展示;各种边界值处理是否符合交互视觉定义等)
只需要修改,data中具体返回值内容即可
(3) 接口返回字段动态新增、缺失,app能不能正常处理,会不会crash之类的
只需要修改返回字段数即可
(4) 某些页面的数据,在24小时内,根据时间变化,app进行不同的展示和处理。但是给你的测试时间也许只有12小时
此时,就可以模拟24小时不同的数据返回,就可以测试app的处理逻辑是否正确
(5) 接口弱网下数据的返回,以及app是否能正常处理
采用script限制各种网速,然后观察app的反应即可
(6) 升级测试,在正式发布前,需要看看升级文案和升级逻辑是否正常。
就可以模拟高版本的返回值和升级文案,然后测试app的升级逻辑。
等等,都是可以根据具体的业务逻辑进行模拟测试。


五、 总结
如果你问我这是一种万能的测试方式吗?
答:与项目的具体业务相关。对于我所在的项目,接入的第三方系统接口提供的数据,数据本身的正确性,第三方系统已经测试过并且上线了。我需要关注的是我项目的待测app对这些数据的处理方式是否正确,app才是我测试的重点,测试目标要明确


如果你问有这种测试方法就够了吗?
答:这只是一种异常的辅助测试手段。他是对正向测试的补充和完善。在测试中,要优先保证app与真正的服务端交互正常,然后在利用这个辅助测试手段,进行异常和健壮性测试,主次要把握好。


如果你问这种解决方案最大的优点是什么?
答:快速且符合业务的需要。我知道有很些专业的弱网测试方案、Mock测试方案等,但是在日常快速迭代的产品中,介入的时间较长,一般会作为专项测试而存在。而本文描述的方法,可以渗透到日常测试,快速介入,尽可能早的发现缺陷。
总之,这只是在当前阶段的一些尝试,后续会继续深入探索。伴随着产品的成熟,而引入不同的测试手段和方法,持续探索!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表