工行数据中心高级经理 李雁南：接口冒烟测试方法

➠更多技术干货请戳：听云博客

今年遇到了几个问题，与接口的功能和性能相关，恰巧最近公司也在组织以冒烟测试为主题的活动，因而乎突发奇想，寻思着可否将接口测试与冒烟测试结合起来，发掘一些新的接口测试思路与方法。

平时对接口测试关注的比较少，大部分接口功能都是经过应用前段的功能测试案例覆盖了，并无单独安排针对接口安排测试案例，所以真正到了实施时，我才发现对于接口测试还缺少一个准确的定义。求助度娘，百度知道上的定义以下：接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。这个定义与咱们以前的理解并无太大差别，简而言之，开放平台应用经过接口服务实现应用间消息和数据交换，所以咱们的测试重点就聚焦在消息和交换两个问题上了。

设计思路：

交换这个问题会简单一些，毕竟应用经常使用的接口服务类型主要就是HTTP和SOCKET两种，而针对这两种类型服务的测试方法也不少，百度一下会有不少相关测试方法和框架。对于咱们这些不懂编程的小白，python天然是首选。python提供了最基本的request和httplib2库实现报文的发送和接收，固然对于HTTP类型接口还会区分为post和get，这个在request库中也都有对应的方法，咱们经过一张接口登记表来记录每个接口的类型、地址和方法，这些信息均可以从配置管理系统中得到。

消息能够简单的视为接口测试案例，比交换问题复杂不少，须要考虑不少因素，咱们总结为如下四个主要问题：

一、消息获取的途径有哪些；

二、消息是否可以覆盖全部的程序分支；

三、如何判断返回结果的正确性；

四、测试效率问题。

下面我将逐一介绍咱们的解决方案：

一、消息获取的途径问题：

传统的接口测试方法主要采用手工编辑接口报文的方法，这种方法只要按照接口文档的描述构造测试报文就OK了，虽然简单，可是有失高效。因而这个方法有了升级版本，就是经过参数化报文中的关键字段，批量生成测试案例，这也是接口性能测试的主要方法之一。这个方法虽然解决了获取报文的效率问题，可是并不能很好解决覆盖率的问题，毕竟报文是人工构造出来的，并不能很是真实的体现实际的业务交易场景，实际测试结果也印证了这一观点。因而，咱们想既然传统的接口测试是在正常的业务交易测试中覆盖了，那么咱们干脆去直接捕获前段发起交易产生的接口消息报文。很是幸运，公司绝大部分的开发部门都是严格按照LOG4J格式记录应用交易日志的，所以咱们只要按照必定的规则去分析应用的交易日志，就可以提取出咱们所须要的内容。

二、消息是否可以覆盖全部的程序分支问题：

根据消息内容的不一样，应用程序会选择不一样的程序逻辑分支，如何可以覆盖全部的分支，传统方法只有经过白盒测试实现，可是验收测试更偏重于黑盒或灰盒测试，所以过去常常由于测试案例不全面，致使某一个未覆盖分支的程序问题流入生产环境。咱们目前想到的方法，是经过在系统中导入存量的接口测试案例，并经过日志中捕获的测试案例，通过一段时间的积累，逐渐造成一个较为完整的接口测试案例库。若是可以旁路一台生产环境应用服务器日志，效果会更好，毕竟生产的交易种类和场景是最全面的，固然这里还要解决生产数据脱敏等问题，对于金融行业还要面对不少制度流程的问题。

三、如何判断消息返回结果的正确性问题：

每个应用对于接口报文的设计都是遵守必定的规范和习惯，咱们只须要梳理出标记交易成功状态的字段就能够了。某些交易不包含这个字段，咱们就须要进行人工判断，并对成功的结果进行格式化（好比timestamp，流水号等），提取MD5特征值，做为判断接口后续测试结果正确性的依据。不过，状态字段是成功并不表明接口测试经过，毕竟返回结果中还包含了不少业务数据字段须要验证。若是这些字段值变化比较规律（好比一直不变、持续增长或减小），咱们准备定义一些模型规则去判断它们。而那些上蹿下跳的数据，那就留给人去判断了。其实，对于冒烟测试而言，咱们认为并不须要苛求去判断每一笔交易的正确性，只须要统计大量测试案例结果的成功率，并与前期成功率进行比较，以判断测试结果是否正常。

四、执行效率的问题

咱们理解的冒烟测试是要在尽量短的时间内，对新的版本或测试环境进行一个准入测试，以判断其是否具备开展后续是验收及适应性测试的条件，所以冒烟测试的效率相当重要。咱们的策略是经过异步小批量做业的方式不间断的扫描日志处理报文，每日定时并发的方式去执行测试案例，执行时间取决于版本安装时间或测试任务的须要，目前2万笔测试案例，基本能够控制在10分钟以内。

实现方案：

实现架构很是简单，就是一套开源的ELK日志采集架构，加上python开发的接口测试框架和结果统计功能，以下图所示：

主要步骤以下：

1，经过开源ELK实现应用日志的采集与管理。在客户端部署logstash agent，并配置日志采集策略；日志记录以key-value的格式上送REDIS内存数据库，这个设计主要是为了在client和server之间作一个缓冲，保证了日志记录的0丢失；ELSTICSEARCH提供了日志的全文检索功能，并提供了API服务用来外部调用

2，利用python的pyes库调用ELSATICSEARCH的API服务，根据特征字段抓取xml和json格式的接口报文。

3，对采集到的接口报文进行格式化处理，格式化日期、流水号或时间戳等字段，并对格式化后的报文作MD5的校验。

4，利用python的http和socket接口库实现接口测试案例，这里可能要根据不一样应用作一些客户化，尽可能经过通用的方式实现。

5，对于异常的测试案例进行自动退出。为了保证案例集的可用性，咱们这里作了一个简单的接口退出规则，若是执行超过三次且每次都失败的接口案例，会被系统自动定义为失效案例。

6，对案例的执行结果进行成功率分析和错误归因分析，最终发现存在的接口问题。这里再也不关注每个测试案例返回的成功和失败，而是针对每一类接口的成功率、失败率和错误类型进行统计，从数值和数量变化的角度去发现问题。

7，接口定义平台提供了一个web的接口定义模块，帮助业务测试人员根据接口文档编辑接口要素，并拼装成接口报文进行测试。对于复杂的交易场景（好比流程长或交互次数多），能够在平台上编排接口的调用顺序和先后项逻辑关系，实现一个比较复杂场景的接口测试。虽然这个功能更偏重于自动化测试，可是这个功能帮助咱们实现了没法经过应用前段功能测试覆盖的接口测试，是很是好的补充。

经过上述方法，咱们在一周的时间里，在3个应用进行了试验，发现了30多个接口，接近2万笔报文案例，案例的有效性能够达到了97%。经过每日对这些案例进行自动化测试，发现了一些接口功能和应用环境配置的问题。

上述这种测试方法还只是从技术的角度测试，为了知足实际业务测试的需求，咱们也实现一些简单的功能：好比咱们提供了多维度的测试结果统计；提供基于业务关键字的报文案例和测试结果的检索功能，以便业务测试人员快速的找到本身的测试案例；容许业务测试人员手工修改报文案例库，这样就能够跳过应用前端，直接针对接口开展测试；最后咱们对每一次执行时间都进行记录，造成了报文案例响应时间的基线，用于后续的接口性能评估。

总结和问题：

以上方法是一个很是简单的接口冒烟测试方法，前提是功能测试覆盖过接口案例，而且接口报文会记录在日志中。随着案例和执行结果的不断积累，接口测试覆盖会更加充分，统计结果会更加精确。若是可以从生产环境日志中获取案例，那么测试效果会更好。上述方法还有不少不成熟的地方，好比对于测试结果的利用上、在失败报文的归类和归因分析上，还应该会有更好的方法。若是全面推广实施，测试的效率，尤为是测试报文提取和分析的效率还须要进一步提高。

欢迎你们拍砖。

 

原文连接：http://blog.tingyun.com/web/article/detail/1340