引言
写这个工具，主要有几个原因：
-
最近老大在尝试不同视角的测试----健壮性测试，任务下来，所以挽起袖子就开撸了
-
app很可能因为后端api做了变更，返回了一个异常的值而出现难以预知的问题，健壮性受到碰撞，所以这种测试是有实际价值的
-
思寒的一篇帖子《基于 fuzz 技术验证移动端 app 的健壮性》我觉得挺好玩，这里要非常非常感谢他提供的思路，从下面的回复也可看出来大家还是比较感兴趣，而他因为遇到一些问题尚未开源，所以我挽起袖子就开撸了
-
社区里最近用anyproxy的挺多，我想说我们厂应该是最早开始用anyproxy的，流量测试中也使用到了这个工具。现在大家都开始定制，我表示不服，所以挽起袖子就开撸了
-
最近有幸被拉到了社区的技术专家群，趁着分红前多发一篇吧，哈哈
0x00
关于健壮性测试，模糊测试的一些描述，我希望大家可以去思寒的帖子里看，我也是从他那里出发的，我想做的东西，和他帖子里讲到的差不多，不过我又加上了另外的一些规则，总的来说，第一阶段我总结了下需求，大致如下：
-
只支持json结果的mock和fuzz
-
该走线上的还走线上，可针对某个具体api做修改
-
能够记录原始的request和response
-
在json结果中，能够指定某个key or value 进行增、删、改
-
fuzzy化，根据原值随机返回fuzz值
-
轻量级 ，方便用于CI，自动化测试，而并非动辄就写个系统
-
跨平台
0x01
调研阶段，为了实现第一阶段的需求，并且结合公司的技术栈（python），主要是搜github 和 google，排除了下面这些：
-
whistle ，太复杂
-
rap，GUI界面很贴心，但是主要是为了方便前端调试，生成模板，适合后端服务还没有起来的情况
-
mock-server，虽然python很贴合，文件保存这点做的好，但是不太方便做mock和fuzz
-
moco，东西很好，也有点重，java栈，之前社区有同学也做过moco + anyproxy的分享
所以，最后选用的技术栈和工具是：
-
nodejs
-
anyproxy
-
jsonpath
-
mockjs
可以方便的模块化，打包成命令行工具，只有一个字，轻
0x02
因为这是一个依附于anyproxy的mock工具，所以anyproxy的rule_file这部分是一定要研究研究的，文档也很清楚了，我说说我踩过的坑：
-
截取https的请求，并不是在anyproxy的启动options里把type设置为‘https’，而是把根据rule_file里的
shouldInterceptHttpsReq -
做值的替换，肯定要用到
replaceServerResDataAsync，这个方法的serverResData参数，是一个Buffer对象 -
在用jsonpath 定位后，因为我的需求里面是有api 级别的mock和global级别的mock，也有两者都有的（api会覆盖global），这在怎么区分命令行参数，以及对类似 $..name 这样的值做mock或fuzz时，增加了一定难度
已有功能：
-
-s 参数是指定原始的request和response的保存路径
-
-p 指定anyproxy启动端口
-
-a 指定具体api，可以只针对这个api的返回数据做mock
-
-m 后面跟jsonpath表达式和值，比如$..name=fenfenzhong，即可把返回的结果里，所有name属性都改为fenfenzhong
-
-i 后面跟jsonpath表达式和值，可以在返回数据里置入你想要的值，对于一些由字段控制的UI特别有效
-
-d 后面跟jsonpath表达式，比如$..title，可以把返回结果里的所有title属性都删除
有了-i（增），-d（删），-m（改），可适应的需求范围就比较广了
0x03
看看效果
原图是：
全局mock，把所有name都换成fenfenzhong，所有text都换成66666，所有title都换成lgtm
$ anymocker -s save -m $..name=fenfenzhong $..text=66666 $..title=lgtm
解析之后，mock规则长这样：
{
"global": {
"mock": [
"$..name=fenfenzhong", "$..text=66666", "$..title=lgtm"
]
}, "api": {}}
效果图是：
//全局mock，把所有text都换成66666，所有title都换成lgtm，删除所有的name属性，并且植入一个属性 qa=douban
// 本来想删除所有的title 属性的，结果。。崩溃啦
$ anymocker -s save -m $..text=66666 $..title=lgtm -i $.qa=douban -d $..name
解析之后，mock规则长这样：
{
"global": {
"mock": [
"$..text=66666", "$..title=lgtm"
], "inject": [
"$.qa=douban"
], "delete": [
"$..name"
]
}, "api": {}}
效果图是：
摘取某一个返回的json：
当既指定了api，又有全局规则的时候，会先应用全局的规则，然后再应用api的规则，当两者涉及到的属性名一样时，api的会覆盖全局的。如果指定了api但是却没有命中，则只应用全局的，或者直接返回原始值
//全局mock，把所有text都换成66666，所有title都换成lgtm，所有name都换成fenfenzhong，再针对具体的/api/v2/note ，把text换成sixsixsix，再增加一个属性qa=douban
$ anymocker -a /api/v2/note/ -i $..qa=douban -d -m $..text=sixsixsix -m $..name=fenfenzhong $..text=66666 $..title=lgtm
解析之后，mock规则长这样：
{
"global": {
"mock": [
"$..name=fenfenzhong", "$..text=66666", "$..title=lgtm"
]
}, "api": {
"/api/v2/note/": {
"mock": [
"$..text=sixsixsix"
], "inject": [
"$..qa=douban"
], "delete": []
}
}}
全局mock的效果图，和之前一样
但是一个具体的日记条目里，可以看到返回的值里已经多了一个qa=douban，mock后的text值全变为了sixsixsix：
0x03
上述的几种方法可以适用于值的修改，但是有的时候需要根据原始值来进行fuzzy化处理再返回，也是可以做到的，需要把jsonpath的值指定为FUZZ，fuzzy化的规则主要有以下几个：
-
number，string，和boolean类型的才能被fuzzy化
-
每种类型都有一定几率返回null
-
数字会随机放大缩小倍数，string会随机变为空串‘’
//全局mock，把text，title，name都模糊处理
$ anymocker -m $..title=FUZZ $..name=FUZZ
效果图：
可见第一个“小脚太太和” 的title被随机减去了一些字符，name返回了空；第二个name“萌宠”前后都加了随机字符，title返回了空，第三个“人文” 的name 和title 前都加了随机字符
最后
由上述的实验看来，工具的完成情况还不错，对于mock和fuzz都能做到，我举得栗子比较浅，但实际上它可以构造出很复杂的规则，测试数据和该走线上的可以很好的分离，而且由于是轻量级命令行的（就是个node模块），跨平台也能使用，也可以很方便的集成到CI。我自己对这种类型的测试还有一点别的思考：
-
这种类型的测试，主要是用随机的值，或者人为构造的极限值去挑战app，在一定程度上，能够检测app的健壮性
-
外部服务的失效往往会对重依赖的app产生比较大影响，拿到null值的可能性增加
-
这类问题的优先级可能不是那么高，怎样去构造一个现实可能出现的异常数据（如果真实不可能出现，那即使崩溃了其实也说明不了什么），对测试人员能力有较高要求
长按二维码识别关注，您的支持是我们最大的动力。
公众号：测试梦工厂
QQ一群：300897805
