问题背景：

在测试&部署监控过程中，我们常常会遇到外部接口返回数据不靠谱的时候。最常见的场合是从某个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.用什么代码？

1.如何抽取特征？

无论是json还是xml，本质上都是树形结构。基于我们最终目的是进行验证的考虑，把json/xml解析为树是个不错的主意。既然预期结构完全相同，那么我们可以依照key，依次遍历检查树的每个节点，比对被比较object是否一致。 
以json为例，我们输入两个json字符串，将其转化为object。如果是复杂结构，则再对object进行递归比较，如果是int或者string，则按既定规则比较。

compare_all(obj2) 进行遍历，先判断类型再进行比较，返回布尔值检查结果向上传递。 
如图，我们举个例子，查询某个小组成员的数据，根据json生成的树

对应的结构

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进行检查。

我们输出检查结果为false，发现了一条不符合预期的数据。

4. 如何基于历史特征进行统计？

在以上部分我们了解如何提取特征后，我们可以考虑将其按照结构化保存在mysql里。在前几步执行过程中我们已经遍历了json对应object的树状结构，以及通过xpath等树状描述对节点进行定位。将这几个步骤组合起来即可：以接口为key，按需要保存若干特征描述，对后续提取的结果进行检查。 
以上面的样例json为例，我们可以保存每次抓取检查时，/members[]数组下的元素个数，当和历史平均值波动大于80%时认为是有问题报警。

5. 基于字符串的检查…

除了上述的详细检查外，我们依然需要对字符串进行一些检查，例如编码、总长度和结构完整性。最后一点比较简单，考虑调用lib时parse失败，如果失败说明json/xml结构不完整，保存现场供人工查看，调整case。

以上就是关于数据接口检查类的自动化测试思路，在设计上我们考虑到现在一些自动化监控/测试实践中遇到的问题，和趋向最新机器学习思路提取特征的想法提出的想法。