CN114003506A

CN114003506A - 一种基于日志录制的接口测试以及监控的方法

Info

Publication number: CN114003506A
Application number: CN202111323284.4A
Authority: CN
Inventors: 梁锦文; 白剑; 黄海亮; 梁瑛玮; 张海林; 鲁和平; 李长杰; 陈焕然; 李乐; 王浩; 洪行健; 冷冬; 丁一
Original assignee: Guangzhou Easefun Information Technology Co ltd
Current assignee: Guangzhou Easefun Information Technology Co ltd
Priority date: 2021-11-10
Filing date: 2021-11-10
Publication date: 2022-02-01

Abstract

本发明公开了一种基于日志录制的接口测试以及监控的方法，包括如下步骤：在对应服务器上按照自定义的日志格式收录访问的接口数据，定时上传到平台；在线管理收集到的接口数据，自动替换登录授权/签名权限/测试数据，在前台页面按应用系统进行管理和发起接口测试，过程中根据对应的校验规则进校验测试结果；在线实时查看接口测试结果，把结果推送到内部应用群，监控系统接口情况。本发明的接口自动录制，不需要人工编写，减少开发成本；录制后的接口数据可在线管理，减轻后续维护成本；从Nginx收录的接口可做到一个不漏，并且接口数据来源于真实的请求访问，更好模拟线上接口请求情况；在定时任务下，能及时对环境中的接口进行测试和监控。

Description

一种基于日志录制的接口测试以及监控的方法

技术领域

本发明涉及计算机测试领域，尤其涉及到一种基于日志录制的接口测试以及监控的方法。

背景技术

在应用程序开发过程中，日常进行接口测试，要么使用postman、jmeter等工具按照接口文档格式编写接口测试脚本，要么通过抓包工具抓取需要的接口发起接口测试任务，前期编写准备过程和日后脚本维护消耗时间不少，此外，当遇到一些历史悠久的接口没有对应接口文档时，不清楚如何编写测试脚本，因为不清楚接口的具体参数，需花费大量时间挖掘测试脚本；编写出来的接口往往偏向于前端到后台部分，缺小系统与系统等更深层次的接口调用，会存在接口不全情况。

发明内容

针对上述技术问题，本发明的目的在于提供一种基于日志录制的接口测试以及监控的方法。

本发明的技术方案如下：

一种基于日志录制的接口测试以及监控的方法，其特征在于，包括如下步骤：

步骤S1：在对应服务器上按照自定义的日志格式收录访问的接口数据，定时上传到平台；

步骤S2：在线管理收集到的接口数据，自动替换登录授权/签名权限/测试数据，在前台页面按应用系统进行管理和发起接口测试，过程中根据对应的校验规则进校验测试结果；

步骤S3：在线实时查看接口测试结果，把结果推送到内部应用群，监控系统接口情况。

根据本发明的优选实施例，步骤S1中，在不同微服务Nginx配置中增加日志格式打印以区分不同服务域名配置。

根据本发明的优选实施例，步骤S1中，微服务Nginx配置中增加的日志格式包含以下数据：请求cookie、来源ip、请求协议、请求域名、请求body、返回内容、请求连接、请求状态码、请求时间、请求user_agent。

根据本发明的优选实施例，步骤S1中，在服务器中使用crontab定时任务指令，以特定同一时间同步服务器收录的接口数据到平台，平台接收到新的数据后会自动做接口唯一性识别，遇到特殊接口无法去重则标记，按照不同域名对应的应用系统存储起来。

根据本发明的优选实施例，在步骤S2中，

对于接口带签名权限，系统根据业务系统的签名权限规则进行匹配与替换，在发起测试时自动替换签名值，其中签名权限规则包括：直播通用sign规则、点播通用sign规则、聊天室通用sign规则；

如果3个签名规则无法匹配，则在线人工编辑自定义sign规则，在发起测试时自动替换签名值；

对于接口需要登录授权，应用系统使用已配置的测试账号进行授权验证，在发起测试时自动替换授权信息。

根据本发明的优选实施例，步骤S2中，在线管理收集到的接口数据之后，接口数据自动替换成测试数据，其中测试数据包括：频道id、账号userid、应用id、视频id。

根据本发明的优选实施例，步骤S2中，对应的检验规则包括字段取值校验、功能逻辑校验、异常校验、其他校验，以此实现校验规则在线增删改查。

根据本发明的优选实施例，步骤S2中，在应用系统中配置DNS，针对特定应用系统的域名ip发起测试。

根据本发明的优选实施例，步骤S3中，应用系统发起接口测试，接口请求返回数据与校验规则进行比较，满足一个校验规则不通过则标记该应用系统测试失败。

根据本发明的优选实施例，步骤S3中，统计应用系统下的所有接口对应校验规则的成功和失败的次数；记录失败的接口对应的校验规则与测试返回结果。

与现有技术相比，本发明具有以下有益效果：

本发明的接口自动录制，不需要人工编写，减少开发成本；录制后的接口数据可在线管理，减轻后续维护成本；

此外，本发明从nginx收录的接口可做到一个不漏，并且接口数据来源于真实的请求访问，更好模拟线上接口请求情况；

在定时任务下，能及时对环境中的接口进行测试和监控。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1为本发明基于日志录制的接口日志收集示意图；

图2为本发明的服务器收录接口数据示意图；

图3为本发明的基于日志录制的接口测试方法示意图；

图4为本发明的接口测试平台进行接口测试监控的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。

本发明公开了一种基于日志录制的接口测试以及监控的方法，包括如下步骤：

如图1所示，在对应服务器上按照自定义的日志格式收录访问的接口数据，定时上传到平台；

具体地，在不同微服务Nginx配置中增加日志格式打印以区分不同服务域名配置，Nginx配置加入收录格式配置，路径如：/data/nginx/conf/nginx.conf

APITEST_logformat '{"@timestamp":"$time_iso8601",'

'"http_cookie":"$http_cookie",' #请求cookie

'"client_ip":"$remote_addr",'#来源ip

'"remote_user":"$remote_user",'

'"request_method":"$request_method",'#请求协议

'"domain":"$host",'#请求域名

'"body_bytes_sent":"$body_bytes_sent",'

'"request_body":"$request_body",'#请求body

'"resp_body":"$resp_body",'#返回内容

'"user_agent":"$http_user_agent",'请求user_agent

'"xff":"$http_x_forwarded_for",'

'"upstream_addr":"$upstream_addr",'

'"upstream_response_time":"$upstream_response_time",'

'"request_time":"$request_time",'#请求时间

'"size":"$body_bytes_sent",'

'"idc_tag":"API_TEST",'

'"status":"$status",'#请求状态码

'"upstream_status":"$upstream_status",'

'"host":"$hostname",'

'"via":"$http_via",'

'"protocol":"$scheme",'

'"request_uri":"$request_uri",'#请求连接

'"http_referer":"$http_referer"}';

在不同服务配置中加入开启日志收录的代码，如在testservice服务中开启日志收录，修改路径如：/data/nginx/conf/servers/testservice

access_log logs/testservice.log APITEST_logformat;

lua_need_request_body on;

set $resp_body "-";

body_filter_by_lua '

local resp_body = string.sub(ngx.arg[1], 1, 10000)

ngx.ctx.buffered = (ngx.ctx.buffered or "") .. resp_body

if ngx.arg[2] then

ngx.var.resp_body = ngx.ctx.buffered

end

';。

上述代码是开启日志收录，其中 string.sub(ngx.arg[1], 1, 10000)为请求body的长度限制为10000，超过则裁减掉。

从Nginx入口收录的接口有一个明显的好处，可以把整个系统所有真实接口流量都收录，做到一个不漏，另外Nginx配置改动简单快捷，不需要额外接入日志系统那么繁琐，大大降低部署与投产时间。

如图2所示，在服务器中使用crontab定时任务指令，以特定同一时间同步服务器收录的接口数据到平台。具体配置：59 23 * * * /home/oracle/scripts/testservice_log_archive.sh >/dev/null 2>&1表示每天23点59分执行脚本/home/oracle/scripts/testservice_log_archive.sh，其中testservice_log_archive.sh则为数据切割以及上传脚本。

平台接收到新的数据后会自动遍历所有接口做接口唯一性识别，截取接口数据中request_uri值

符号前的内容做唯一性判断的其中一个条件，这样好处是降低同一个接口不同参数值的场景，能做到更准确的唯一性，如接口

和

接口

取

号前的值为/v2/user/getChannelAmount.do则两个接口识别为同一个接口，则不做重复收录。如遇到特殊接口无法去重则标记，需要后期人工干预进行识别是否重复接口，该场景主要是由于个别接口request_uri值

号前的内容上带有一些账号敏感信息/加密串等，如

和

实际上上述两个接口是同一个接口，需要标记。

平台按照不同域名对应的应用系统存储起来，使用接口数据domain的值做区分，归类同一个域名服务下的所有接口，如"domain":"xxx.xxx.test"归类到xxx.xxx.test服务。整个过程大大降低后期人工干预的时间，能做到只插入新收录的接口并且按域名服务归类好。

如图3所示，步骤S2：接口平台在线管理收集到的接口数据，自动替换登录授权/签名权限/测试数据，在前台页面按应用系统进行管理和发起接口测试，过程中根据对应的校验规则进校验测试结果。

接口收录到平台后，以域名应用区分，实现接口在线增删改查。在线管理收集到的接口数据之后，在发起测试时自动替换成测试数据，其中测试数据包括：频道id（channelId）、账号userid、应用id（appid）、视频id（vid）。

测试数据：

频道id=888、账号userid=testuserid、应用id=testappid、视频id=test888

测试接口：

发起测试时会自动替换成：

对于接口需要登录授权，应用系统使用已配置的测试账号进行授权验证，在发起测试时自动替换授权信息。具体根据接口数据"http_cookie"值来判断是否需要登录授权，当"http_cookie"值不为"-"则为需要登录授权，使用测试账号和密码登录我们公司系统后获取登录授权信息，替换原"http_cookie"值实现登录授权。

对于接口带签名权限，根据"request_uri"和"resp_body"值中是否带有sign参数来判断是否带签名权限。如果带有sign字段，根据业务系统的签名权限规则进行匹配与替换，在发起测试时自动替换签名值，sign规则是根据请求参数做加密处理，每个规则的加密处理方法是唯一的。

其中签名权限规则包括：直播通用sign规则、点播通用sign规则、聊天室通用sign规则；

直播通用sign规则，如接口:

提取参数appid=testappid&vid=test888&channelId=888按照已知的直播通用sign规则做加密运算生成，具体sign规则如下：

将请求所需参数（参数值非空的参数）按照参数名字典顺序排列，连接参数名与参数值，例如：appidtestappidvidtest888channelId888

并在拼接字符串首尾加上appSecret，加上appSecret，以appSecret为abc为例，得到：abcappidtestappidvidtest888channelId888abc

然后采用UTF-8编码计算MD5，将MD5结果转为大写字母，作为sign；

生成出新的sign值分别与"request_uri"中sign值做对比，如果匹配则标记为直播通用sign规则并且后续测试会使用直播通用sign规则生成的新sign值替换原来的sign签名值。

点播通用sign规则，如接口:

提取参数appid=testappid&vid=test888按照已知的点播通用sign规则做加密运算，具体sign规则如下：

将请求所需参数（参数值非空的参数）按照参数名字典顺序排列，连接参数名与参数值，例如：appidtestappidvidtest888

并在拼接字符串尾加上appSecret，以appSecret为abc为例，得到：appidtestappidvidtest888abc

生成出新的sign分别与"request_uri"中sign值做对比，如果匹配则标记为点播通用sign规则并且后续测试会使用点播通用sign规则生成的新sign值替换原来的sign签名值。

聊天室通用sign规则，如接口:

提取参数appid=testappid&channelId=888按照已知的聊天室通用sign规则做加密运算，具体sign规则如下：

将请求所需参数（参数值非空的参数）按照参数名字典顺序排列，连接参数名与参数值，例如：appidtestappidchannelId888

并在拼接字符串尾加上polyvChatSign，得到：polyvChatSignappidtestappidvidtest888polyvChatSign

生成出新的sign分别与"request_uri"中sign值做对比，如果匹配则标记为聊天室通用sign规则并且后续测试会使用聊天室通用sign规则生成的新sign值替换原来的sign签名值。

标记为直播通用sign规则、点播通用sign规则、聊天室通用sign规则的接口，在测试时会自动替换sign值，完成签名权限校验。

如果3个签名规则无法匹配，则标记为自定义sign规则，需要人工在线编辑自定义sign规则，在线选择加密算法MD5/SHA256，在线输入加密混淆字符，在线编排加密混淆字符位置，在线输入参数与值等。在发起测试时自动替换签名值；

自定义sign规则，如接口：

对应自定义sign规则为加密算法MD5、加密混淆字符为：void-api、加密混淆字符位置为：头尾、参数（参数值非空的参数）按照参数名字典顺序排列，按照该规则的字符串为：MD5（void-apiappidtestappidchannelId888void-api）

该接口标记为自定义sign规则并且后续测试会使该自定义sign规则生成的新sign值替换原来的sign签名值。

标记为自定义sign规则的接口，在测试时会自动替换sign值，完成签名权限校验。

接口测试时可以选择对应的测试环境发起测试，这里使用的是DNS域名绑定。

常用的测试环境有线上环境/预发布环境/测试环境，例如：

线上环境DNS为：172.xx.xx.xx api.xx.net

预发布环境DNS为：183.xx.xx.xx api.xx.net

测试环境DNS为：183.xx.xx.xx api.xx.net

选择不同的测试环境，实现不同环境的接口测试，能很好的在不同环境下一一测试通过确保接口质量。

在上述流程过后，接口已实现了测试数据自动替换、登录授权/签名授权验证、测试环境指向，接口正式进入测试流程了。可单独运行单个接口测试，可以应用系统发起多个接口测试，也可以对目前收录的所有接口发起测试，使用队列把所有接口组装后逐个发起测试，上一个接口测试完毕后进行下一个接口测试。

每个接口请求返回数据保存到redis，并且使用校验规则做正确性校验。当前检验规则包括字段取值校验、功能逻辑校验、异常校验、其他校验，所有校验规则可在线增删改查。

字段取值校验，主要是校验返回数据内的具体字段值校验，适用场景如新增数据，或者数据敏感型的对比。如设置一个字段取值校验，校验内容为：

if ("data"!= "200") {

记录错误("data!=200");

return false;

}

return true;

接口返回内容如：

{"code":0,"message":"success","data":"200"}

根据校验规则，该接口校验通过。如果接口返回内容data为300，则校验不通过。

功能逻辑校验，主要是校验接口调用成功与否，适用场景如验证接口能否正常调用。如设置一个功能逻辑校验，校验内容为：

if ("code"!= 0) {

记录错误("code"!= 0);

return false;

}

return true;

接口返回内容如：

{"code":0,"message":"success","data":"200"}

根据校验规则，该接口校验通过。如果接口返回内容"code":1，则校验不通过。目前我们数据返回结构中code=0则为业务调用正常，code=403则为业务调用权限失败，code=1则为业务调用失败等，这里不一一罗列。规则校验可以单独给接口配置，也可以对应用系统配置，当对应用系统配置后可节省对所有接口配置校验规则的时间，特别适用于冒烟测试阶段，验证接口可用性。

接口测试中当接口对应其所有规则校验都成功，则标记该接口测试通过；如果对应其中一个规则校验失败，则标记该接口测试不通过；接口返回结果以及校验成功与否的信息都会保存起来，在线可查看。

在接口测试结束后，平台会自动统计应用系统下所有接口的结果，统计成功与失败情况。当应用系统下所有接口失败次数>=1则该应用系统接口测试失败，反之成功，最后汇总所有接口成功与失败信息，形成在线查看报告页面，方便大家查看接口测试情况。平台会把该应用系统的汇总信息通过IM系统推送到内部群，可实时看到应用系统下接口测试情况。如下IM内部群：

APS接口测试通知自:聊天室API接口测试，总接口数量:142,在112.xx.xx.89测试环境下全部验证通过，请点击查看详情！

APS接口测试通知自:API域名接口接口测试，总接口数量:178,在183.xx.xx.227预发布环境下出现1个接口校验失败，请点击查看详情！

点击该消息可通过超链接跳转到在线报告页面，可以查看每个接口测试情况，特别是失败的接口查看具体失败信息，方便排查问题。

需要注意的是，附图中的数字标记表示本发明基于日志录制的接口测试以及监控的方法的详细步骤的示意，并没有其他含义。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims

1.一种基于日志录制的接口测试以及监控的方法，其特征在于，包括如下步骤：

对于接口需要登录授权，应用系统使用已配置的测试账号进行授权验证，在发起测试时自动替换授权信息；

2.根据权利要求1所述的方法，其特征在于，步骤S1中，在不同微服务Nginx配置中增加日志格式打印以区分不同服务域名配置。

3.根据权利要求2所述的方法，其特征在于，步骤S1中，微服务Nginx配置中增加的日志格式包含以下数据：请求cookie、来源ip、请求协议、请求域名、请求body、返回内容、请求连接、请求状态码、请求时间、请求user_agent。

4.根据权利要求1所述的方法，其特征在于，步骤S1中，在服务器中使用crontab定时任务指令，以特定同一时间同步服务器收录的接口数据到平台，平台接收到新的数据后会自动做接口唯一性识别，遇到特殊接口无法去重则标记，按照不同域名对应的应用系统存储起来。

5.根据权利要求1所述的方法，其特征在于，步骤S2中，在线管理收集到的接口数据之后，接口数据自动替换成测试数据，其中测试数据包括：频道id、账号userid、应用id、视频id。

6.根据权利要求1所述的方法，其特征在于，步骤S2中，对应的检验规则包括字段取值校验、功能逻辑校验、异常校验、其他校验，以此实现校验规则在线增删改查。

7.根据权利要求1所述的方法，其特征在于，步骤S2中，在应用系统中配置DNS域名绑定，针对特定应用系统的域名ip发起测试，如线上环境/预发布环境/测试环境。

8.根据权利要求1所述的方法，其特征在于，步骤S3中，应用系统发起接口测试，接口请求返回数据与校验规则进行比较，满足一个校验规则不通过则标记该应用系统测试失败。

9.根据权利要求8所述的方法，其特征在于，步骤S3中，统计应用系统下的所有接口对应校验规则的成功和失败的次数；记录失败的接口对应的校验规则与测试返回结果。