平时对接口…接口冒烟测试方法

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

平时对接口测试关注的比较少大部分接口功能都是通过应用前段的功能测试案例覆盖了并没有单独安排针对接口安排测试案例因此真正到了实施时我才发现对于接口测试还缺乏一个准确的定义。

求助度娘百度知道上的定义如下接口测试是测试系统组件间接口的一种测试。

接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。

测试的重点是要检查数据的交换传递和控制管理过程以及系统间的相互逻辑依赖关系等。

这个定义与我们之前的理解并没有太大差异简而言之开放平台应用通过接口服务实现应用间消息和数据交换因此我们的测试重点就聚焦在消息和交换两个问题上了。

设计思路

交换这个问题会简单一些毕竟应用常用的接口服务类型主要就是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%。

通过每日对这些案例进行自动化测试发现了一些接口功能和应用环境配置的问题。

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

总结和问题

以上方法是一个非常简单的接口冒烟测试方法前提是功能测试覆盖过接口案例并且接口报文会记录在日志中。

随着案例和执行结果的不断积累接口测试覆盖会更加充分统计结果会更加精确。

如果能够从生产环境日志中获取案例那么测试效果会更好。

上述方法还有很多不成熟的地方比如对于测试结果的利用上、在失败报文的归类和归因分析上还应该会有更好的方法。

如果全面推广实施测试的效率尤其是测试报文提取和分析的效率还需要进一步提升。

作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。

视频文档获取方式

这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。