问题背景：
在测试&部署监控过程中，我们常常会遇到外部接口返回数据不靠谱的时候。最常见的场合是从某个http获取如json和xml等结构化的结果，进行解析并处理，在这时候出现以下这几种常见类型的错误：
（1）整个结构不完整。直接无法解析json/xml。
（2）编码错误，常见的gbk/utf8错误
（3）超长数据/非法字符。
（4）数据类型不匹配。需要是数字的给了字符串，该是数组的给了字符串等，对json本身来说没问题，程序处理就会错误或者崩溃。
（5）字段缺失或者为空，这个情况对json本身来说也是没问题的，处理进程固定要去取这里的字段就会出问题，或者进程本身没问题，但实际展现出问题。
例如，json描述一个商品最近30天的售价，提供一个数组里有30个数据来画点，json里这个数组为空，从数据格式上来说没问题，但实际画点时展现即为空。
截图是来自一份合作方的数据，箭头指向的是上证指数曲线的点，如果点数据完全缺失（为空）则画曲线的界面会显示为空。在json结构上则仍然验证为合法。
解决问题的现状：
对上述问题，我们有一些简单的自动化监控手段，通过定期抓取http接口再获取其中内容这一步比较简单，接下来我们会验证http状态码（200正常，非200认为是有问题）和长度，如果过短（例如少于20字节）则认为是无效。
还有一些自动化case会先人工看一下接口返回的具体内容，然后再作为case检查点，检查抓取接口中是否存在固定字符串片段，以此进一步验证返回结果的正确性。这里我们仍然进行的是字符串粒度上的检查。
解决问题思考：
如果只通过字符串的方式检测长度，这个粒度过于粗糙，难以发现上述详细一些问题。检查固定的字符串片段存在，能部分弥补上述不足，但仍然无法检查背景中提到的诸如字段缺失的问题。
但是若要检查字符串完全相同，则要求接口每次返回的数据完全相同，和实际应用情况不符，维护case难度大。那么，我们的思路就转向如何对数据结构体进行检查。
总的思路出于以下几条：
1.根据历史接口请求结果作为范本，提取特征作为约束对新数据进行检查。提高工具本身的适用范围。
2.接口返回的数据应该可以化为结构体，通过对结构体字段的条件约束来判断数据检查是否通过。
3.对有些字段内容可以进行二次解析，保障其中数据的合法性。
4.基于历史数据特征进行统计，辅助对数据字段进行正确性检查，进一步降低维护条件约束的难度。
接下来我们逐步来设计我们以上思考功能。
解决问题的设计：
0.用什么代码？
现在任何一种主流语言都有成熟的json/xml解析库，幸运的是作为正确性检查，这个规模我们基本不需要考虑性能问题。当速度不可接受的时候可以考虑多进程分开跑来环节压力。
推荐脚本语言python/php，开发起来更快一些。作为一个轻量的检查工具甚至只是个lib，它应该尽量简单，方便使用，方便纳入现有的测试框架之中。
1.如何抽取特征？
无论是json还是xml，本质上都是树形结构。基于我们最终目的是进行验证的考虑，把json/xml解析为树是个不错的主意。既然预期结构完全相同，那么我们可以依照key，依次遍历检查树的每个节点，比对被比较object是否一致。
以json为例，我们输入两个json字符串，将其转化为object。如果是复杂结构，则再对object进行递归比较，如果是int或者string，则按既定规则比较。
function compare_json($in_json, $diff_json){
$json = new Services_JSON();
$start_object = $json->decode($json_str_from_file);
$diff_object = $json->decode($json_str_diff_from_file);
return compare_all($start_object, $diff_object);
}
compare_all(obj2) 进行遍历，先判断类型再进行比较，返回布尔值检查结果向上传递。
如图，我们举个例子，查询某个小组成员的数据，根据json生成的树
{
"name":"name1",
"date":123,
"members":[
{
"name":"alice",
"level":5,
"lastpost":{
"title":"noname1",
"date":500
}
},
{
"name":"bob",
"level":0,
"lastpost":{
"title":"noname2",
"date":501
}
}
]
}
对应的结构
2.约束条件都有哪些类型？
根据实际应用情况的不同，可以按需求调整。特别是数组由于数量一般不一致，可以考虑在非空的条件下只取第一个进行结构验证，也可以考虑遍历取每一个节点进行相同的结构验证。
在这里举一些例子作为常见的检查参考：
(1)根据key进行遍历，如果对照的测试数据直接取不到key对应的object，则认为有问题。在取到数据的情况下进行比较：
(2)两边数据类型一致
(3)样板数据非空的情况下，检查数据应该非空
(4)样板数据为空，检查数据为非空或空都可以
(5)数组里的元素个数应该保持一致
(6)如果不是叶子节点，它下面还有某种结构的话，用相同规则处理下面的子树。
3.对其中个别节点的附加检查方式：
我们同样考虑，在一些case的执行中，要求对其中一些重要的节点做出复杂检查操作，这些检查操作是根据case来的，不能适用到其他case上。最重要的问题是如何定位节点。
例如上述每条json数据中，希望检查每个level都在5以上… 通过path定位需要一个辅助工具来索引json返回对应的数据。
对于xpath for json，php有第三方的lib提供了jsonpath来执行类似xpath的检索功能。通过实验检查可行，也可以单独根据xpath的语法写一个解析器，但这里不符合我们对快速实现最终检查目的这个目标。是否自己写lib来支持，取决于工期的长短。
http://goessner.net/articles/JsonPath/
一个简单的实例，对每个level进行检查。
//load library require_once ('lib/JSON.php'); require_once ('lib/jsonpath-0.8.1.php'); $json_newstr = '{"name": "name1", "date": 123, "members": [{"name":"alice", "level": 5, "lastpost": {"title": "noname1", "date": 500}} , {"name":"bob", "level": 0, "lastpost": {"title": "noname2", "date": 501}}]}'; echo "json str: $json_newstr "; $json = new Services_JSON(SERVICES_JSON_LOOSE_TYPE); $start_object = $json->decode($json_newstr); $result = jsonPath($start_object, "$..members..level"); echo "got all levels... "; var_dump($result); $check_result_ok = true; foreach($result as $level_to_check){ if($level_to_check <= 0){ $check_result_ok = false; } } var_dump($check_result_ok);
运行上述片段对json字符串进行检查
task start...
json str: {"name": "name1", "date": 123, "members": [{"name":"alice", "level": 5, "lastpost": {"title": "noname1", "date": 500}} , {"name":"bob", "level": 0, "lastpost": {"title": "noname2", "date": 501}}]}
got all levels...
array(2) {
[0]=>
int(5)
[1]=>
int(0)
}
bool(false)
task end. run check for0 time(s)
我们输出检查结果为false，发现了一条不符合预期的数据。
4. 如何基于历史特征进行统计？
在以上部分我们了解如何提取特征后，我们可以考虑将其按照结构化保存在mysql里。在前几步执行过程中我们已经遍历了json对应object的树状结构，以及通过xpath等树状描述对节点进行定位。将这几个步骤组合起来即可：以接口为key，按需要保存若干特征描述，对后续提取的结果进行检查。
以上面的样例json为例，我们可以保存每次抓取检查时，/members[]数组下的元素个数，当和历史平均值波动大于80%时认为是有问题报警。
5. 基于字符串的检查…
除了上述的详细检查外，我们依然需要对字符串进行一些检查，例如编码、总长度和结构完整性。最后一点比较简单，考虑调用lib时parse失败，如果失败说明json/xml结构不完整，保存现场供人工查看，调整case。
以上就是关于数据接口检查类的自动化测试思路，在设计上我们考虑到现在一些自动化监控/测试实践中遇到的问题，和趋向最新机器学习思路提取特征的想法提出的想法。