基于fuzz技术验证移动端app的健壮性
本帖已被设为精华帖!,
问题定义
app发布后经常容易出现各种诡异的crash, 这些crash固然可以通过各种崩溃分析服务去定位. 但是的确很影响用户体验.
在crash分类中有一类是后端接口引发的. 比如常见的引发app crash的原因
- 接口自身变更, 接口失效或者超时, 比如用户进地铁
- 接口格式变更. 字段缺失
- 接口内容变更, int string格式搞错了. 某些字段原本是有值后来就变成了null
一旦出了问题, 后端背锅或者做兼容是常见的方案. 但是对于app自身来说,也需要加强健壮性测试.
健壮性的英文名字是Robust, 音译为”鲁棒性”(也不知道是哪个文盲起的, 流传太广了, 很容易被听到 “撸棒性”…不忍直视啊 不建议使用…)
解决方案设计
在app和后端接口之间设置一个代理. 然后利用代理自身的技术来mock掉返回结果. 从而伪造返回值.
在伪造返回值的基础上, 判断原始的数值, 根据类型自动衍生出多种测试用例. 比如
- 如果是数字, 自动取几个典型场景. 放大和缩小N倍. 0 -1 2.00001等.
- 如果是字符串. 根据长度自动缩短和延长内容. 并适当的取典型值, 比如””
- 所有类型都会默认有机会出现null
工具介绍
工欲善其事必先利其器, 所以周末在公司加班了一天做了这样一个feature.
依赖的基础是我之前发帖介绍的接口测试框架. https://testerhome.com/topics/3614
这个代理工具自身已经被我剥离出来了.
startupapi
通用的接口测试工具, 基于录制并生成用例的设计.
测试技术交流 https://testerhome.com
Usage: startupapi [options]
-r | --record
录制模式, 会在特定的端口上开启代理, 或者mock模式
-e | --export
从数据文件中生成测试用例模板
-m <value> | --mock <value>
设定mock的规则, --mock $..name=xx,$..change=77 如果预期值是FUZZ则自动对特定字段进行fuzz, 比如--mock $..name=xx,$..change=FUZZ
-p <value> | --port <value>
监听的端口, 默认是7770
-f <value> | --file <value>
数据保存路径
-u <value> | --url <value>
限制mock使用的范围. --mock quote.json,search.json
-v | --verbose
是否展示更多debug信息
--help
startupapi --record --port 8787 --file proxy.har
startupapi --export har_file --url search,list
startupapi --mock --proxy 8787 --mock $..name=value,$..text=value2
startupapi --mock --proxy 8787 --mock $..name=FUZZ,$..text=value2 -url quote.json
startupapi -r -f /tmp/proxy.har -m $..name=xx -p 7777 -u quote.json
目前只支持了json结果的mock和fuzz.
可以设定只mock 特定接口 的 特定字段 内容. 使用JsonPath指定要mock或者fuzz的接口字段.
mock演示
这是一个mock的演示
#启动代理监听7777端口, 把所有接口返回内容里面的current字段设置为8888, 名字设置为testerhome. 原始的交互数据保存在/tmp/下.
startupapi -r -f /tmp/proxy.har -m $..name=testerhome,$..current=8888 -p 7777

来个精细化版本的
#把所有的文本内容ST改成DD, 把9.98替换为77.7. 然后修改json结构中的当前价格
startupapi -r -f /tmp/proxy.har -m $..current=8888,9.98=77.7,ST=DD -p 7777

fuzz测试
把mock的结果值修改为FUZZ即可对特定的内容自动替换为fuzz类型的数据.
把mock结果值修改为NULL, 即可模拟json里面的null情况.
#把所有的文本内容ST改成DD, 把9.98替换为77.7. 然后修改json结构中的当前价格
startupapi -r -f /tmp/proxy.har -m $..current=FUZZ,9.98=77.7,ST=DD -p 7777
效果
分别在Android和iOS的app上发现了较多的功能出现崩溃. 大多是某些小字段为null引发的.
因为结果太惨不忍睹了, 就不发截图了.
晚些时间我会挑选几个大厂app的crash演示下
这个工具本身可用于简单的mock和fuzz. 能快速有效的发现各种健壮性问题.
当然发现的这类bug大多优先级别也很低. 需要酌情处理.
想要吗
社区办个大会不容易, 为了支持下社区的活动.
我发一个福利, 凡报名参加大会的同学. 可以提前获得这个工具的预览版.

报名连接: http://www.bagevent.com/event/56573?bag_track=seveniruby
报名成功后关注TesterHome的微信号, 并发送自己报名的姓名和公司邮箱即可. 我会回复下载地址.
| 主持人 | topic |
|---|---|
| 大会组织者与社区贡献者 | 剪彩仪式, 庆祝社区注册工程师过万 |
| 恒温 Monkey 思寒 | 开幕致辞 |
| 淘宝 | 手淘移动测试性能保证体系 |
| 腾讯 | 腾讯应用宝质量保证体系 |
| 360 | Android安全测试体系 |
| 支付宝 | 跨平台自动化测试框架Macaca |
| 午餐 | |
| 阿里游戏 | 持续交付与代码静态分析 |
| ThoughtWorks | 移动测试的Mock实践 |
| Monkey | 测试到质量转变之路 |
| 百度 | 移动测试新模式 |
| 雪球 | 跨平台自动遍历技术的利用 |
| 360 | 代码静态分析与自定义规则应用 |
| 新浪 | 创业公司安全测试体系 |
| 恒温 Monkey 思寒 | 闭幕show |
| 晚宴 |
* 注:本文来自网络投稿,不代表本站立场,如若侵犯版权,请及时知会删除
