接口冒烟测试方法
今年遇到了几个问题，与接口的功能和性能相干，碰巧最近公司也在组织以冒烟测试为主题的活动，于是乎突发奇想，寻思着能否将接口测试与冒烟测试联合起来，发掘一些新的接口测试思绪与方法。
平常对接口测试关注的比较少，大部门接口功能都是通过应用前段的功能测试案例覆盖了，并没有单独安排针对接口安排测试案例，因此真正到了实施时，我才发现对于接口测试还缺乏一个正确的定义。求助度娘，百度知道上的定义如下：接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要查抄数据的互换，传递和控制管理过程，以及系统间的相互逻辑依靠关系等。这个定义与我们之前的理解并没有太大差异，简而言之，开放平台应用通过接口服务实现应用间消息和数据互换，因此我们的测试重点就聚焦在消息和互换两个问题上了。
设计思绪：
互换这个问题会简单一些，毕竟应用常用的接口服务类型主要就是HTTP和SOCKET两种，而针对这两种类型服务的测试方法也很多，百度一下会有很多相干测试方法和框架。对于我们这些不懂编程的小白，python自然是首选。python提供了最根本的request和httplib2库实现报文的发送和接收，当然对于HTTP类型接口还会区分为post和get，这个在request库中也都有对应的方法，我们通过一张接口登记表来记载每一个接口的类型、地址和方法，这些信息都可以从配置管理系统中获得。
消息可以简单的视为接口测试案例，比互换问题复杂很多，须要思量很多因素，我们总结为以下四个主要问题 ：
1、消息获取的途径有哪些；
2、消息是否可以或许覆盖全部的步伐分支；
3、怎样判定返回效果的正确性；
4、测试效率问题。
下面我将逐一介绍我们的解决方案：
1、消息获取的途径问题：
传统的接口测试方法主要采用手工编辑接口报文的方法，这种方法只要按照接口文档的描述构造测试报文就OK了，虽然简单，但是有失高效。于是这个方法有了升级版本，就是通过参数化报文中的关键字段，批量天生测试案例，这也是接口性能测试的主要方法之一。这个方法虽然解决了获取报文的效率问题，但是并不能很好解决覆盖率的问题，毕竟报文是人工构造出来的，并不能非常真实的体现实际的业务交易场景，实际测试效果也印证了这一观点。于是，我们想既然传统的接口测试是在正常的业务交易测试中覆盖了，那么我们干脆去直接捕获前段发起交易产生的接口消息报文。非常幸运，公司绝大部门的开发部门都是严酷按照LOG4J格式记载应用交易日志的，因此我们只要按照肯定的规则去分析应用的交易日志，就可以或许提取出我们所须要的内容。
2、消息是否可以或许覆盖全部的步伐分支问题：
根据消息内容的不同，应用步伐会选择不同的步伐逻辑分支，怎样可以或许覆盖全部的分支，传统方法只有通过白盒测试实现，但是验收测试更侧重于黑盒或灰盒测试，因此已往常常因为测试案例不全面，导致某一个未覆盖分支的步伐问题流入生产环境。我们现在想到的方法，是通过在系统中导入存量的接口测试案例，并通过日志中捕获的测试案例，经过一段时间的积累，逐渐形成一个较为完整的接口测试案例库。如果可以或许旁路一台生产环境应用服务器日志，效果会更好，毕竟生产的交易种类和场景是最全面的，当然这里还要解决生产数据脱敏等问题，对于金融行业还要面对很多制度流程的问题。
3、怎样判定消息返回效果的正确性问题：
每一个应用对于接口报文的设计都是依照肯定的规范和习惯，我们只须要梳理出标记交易乐成状态的字段就可以了。某些交易不包含这个字段，我们就须要举行人工判定，并对乐成的效果举行格式化（比如timestamp，流水号等），提取MD5特征值，作为判定接口后续测试效果正确性的依据。不外，状态字段是乐成并不代表接口测试通过，毕竟返回效果中还包含了很多业务数据字段须要验证。如果这些字段值变化比较规律（比如不停不变、连续增加或减少），我们准备定义一些模型规则去判定它们。而那些上蹿下跳的数据，那就留给人去判定了。实在，对于冒烟测试而言，我们认为并不须要苛求去判定每一笔交易的正确性，只须要统计大量测试案例效果的乐成率，并与前期乐成率举行比较，以判定测试效果是否正常。
4、执行效率的问题
我们理解的冒烟测试是要在尽大概短的时间内，对新的版本或测试环境举行一个准入测试，以判定其是否具有开展后续是验收及顺应性测试的条件，因此冒烟测试的效率至关告急。我们的策略是通过异步小批量作业的方式不间断的扫描日志处理报文，每日定时并发的方式去执行测试案例，执行时间取决于版本安装时间或测试任务的须要，现在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%。通过每日对这些案例举行主动化测试，发现了一些接口功能和应用环境配置的问题。
上述这种测试方法还只是从技术的角度测试，为了满足实际业务测试的需求，我们也实现一些简单的功能：比如我们提供了多维度的测试效果统计；提供基于业务关键字的报文案例和测试效果的检索功能，以便业务测试职员快速的找到自己的测试案例；答应业务测试职员手工修改报文案例库，这样就可以跳过应用前端，直接针对接口开展测试；最后我们对每一次执行时间都举行记载，形成了报文案例相应时间的基线，用于后续的接口性能评估。
总结和问题：
以上方法是一个非常简单的接口冒烟测试方法，前提是功能测试覆盖过接口案例，并且接口报文会记载在日志中。随着案例和执行效果的不停积累，接口测试覆盖会更加充实，统计效果会更加精确。如果可以或许从生产环境日志中获取案例，那么测试效果会更好。上述方法另有很多不成熟的地方，比如对于测试效果的利用上、在失败报文的归类和归因分析上，还应该会有更好的方法。如果全面推广实施，测试的效率，尤其是测试报文提取和分析的效率还须要进一步提升。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
