一种应用接口覆盖率统计方法和系统与流程

1.本发明涉及软件测试技术领域，具体涉及一种应用接口覆盖率统计方法和系统。


背景技术：

2.应用程序接口，即application programming interface(应用程序接口)，是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。软件功能测试及安全测试实际上也是通过访问应用程序来判断具体的功能是否正常实现以及是否存在安全问题，而实际情况中，通常存在软件功能测试或安全测试完成后，无法统计应用程序的应用程序接口是否全部完成测试的情况，因此应用程序覆盖率成为了软件功能测试及安全测试的重要指标。


技术实现要素：

3.本发明针对现有技术中的缺点，提供了一种应用接口覆盖率统计方法和系统，具有实现应用程序风险检测的优点，突破了无法计算软件功能测试及安全测试完成率的瓶颈。
4.为了解决上述技术问题，本发明通过下述技术方案得以解决：
5.一种应用接口覆盖率统计方法，包括以下步骤：
6.应用启动时，获取应用的开发语言和运行环境信息；
7.判断应用框架的类型，根据应用框架的类型、开发语言和运行环境信息织入应用程序接口发现代码，得到应用程序接口发现引擎；
8.根据所述应用程序接口发现引擎，计算应用程序接口的数量；
9.根据所述应用程序接口发现引擎，对应用程序接口进行数据解析，并获取每个应用程序接口的执行函数；
10.在所述执行函数上织入应用程序接口请求检测代码，得到应用程序接口请求引擎；
11.根据所述应用程序接口请求引擎判断各个应用程序接口是否被访问，计算被访问的应用程序接口数量，并计算测试覆盖率。
12.可选的，根据所述应用程序接口发现引擎，对应用程序接口进行数据解析，并获取应每个用程序接口的执行函数，包括以下步骤：
13.根据所述应用程序接口发现引擎，解析每个应用程序接口的应用程序路由；
14.根据所述应用程序路由，获取应用程序路由对应的请求方法；
15.根据所述请求方法获取每个应用程序接口的执行函数。
16.可选的，还包括以下步骤：
17.当织入所述应用程序接口发现代码时，织入应用程序接口上报代码，得到应用程序接口上报引擎。
18.可选的，所述应用程序接口上报引擎将所述应用程序路由、请求方法和执行函数
上报至服务终端。
19.可选的，计算被访问的应用程序接口数量，并计算测试覆盖率，测试覆盖率的计算公式为：测试覆盖率＝被访问的应用程序接口数量/应用程序接口的数量。
20.可选的，所述开发语言包括java、python、golang、ruby或php中的任意一种。
21.可选的，所述请求方法包括get方法、head方法、post方法、put方法、delete方法、connect方法、options方法trace方法和patch方法中的一种或多种。
22.可选的，还包括以下步骤：
23.根据所述应用程序接口发现引擎，织入风险检测代码，形成应用程序接口风险检测引擎；
24.判断是否对应用程序接口启动风险检测动作，若需要启动风险检测动作，则调用应用程序接口风险检测引擎，若不需要启动风险检测动作，则结束；
25.若应用程序接口风险检测引擎发现风险函数，则上报风险；反之，继续进行风险检测动作。
26.一种应用接口覆盖率统计系统，系统采用上述任意一种应用接口覆盖率统计方法。
27.一种计算机可读存储介质，计算机可读存储介质用于存储和执行上述一种应用接口覆盖率统计系统。
28.采用本发明提供的技术方案，与现有技术相比，具有如下有益效果：
29.通过在应用程序接口上织入应用程序接口发现代码得出应用程序的应用程序接口数量，并在应用检测时织入应用程序接口请求检测代码，获取被访问的应用程序接口数量从而计算得到应用程序的测试覆盖率，便于工作人员获取应用程序的测试结果，并通过在应用程序接口织入风险检测代码，使应用程序的各个应用程序接口都进行风险防护，提高应用程序的稳定性，且传统测试覆盖率计算为http路由匹配，相较于本技术，本技术的计算更加精确。
附图说明
30.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
31.图1为本发明实施例提出的一种应用接口覆盖率统计方法的流程图之一；
32.图2为本发明实施例提出的一种应用接口覆盖率统计方法的流程图之二。
具体实施方式
33.下面结合实施例对本发明做进一步的详细说明，以下实施例是对本发明的解释而本发明并不局限于以下实施例。
34.如图1所示，一种应用接口覆盖率统计方法，包括以下步骤：应用启动时，获取应用的开发语言和运行环境信息；判断应用框架的类型，根据应用框架的类型、开发语言和运行环境信息织入应用程序接口发现代码，得到应用程序接口发现引擎；根据应用程序接口发
现引擎，计算应用程序接口的数量；
35.在应用启动时，进行运行时字节码插桩，字节码插桩可以插入指定代码从而获取应用的开发语言和运行环境信息，如java可以通过插入system.getproperty方式获取开发语言和运行环境信息，其中开发语言包括java、python、golang、ruby或php中的任意一种。
36.框架为应用自身框架，可分为web框架和非web框架，其中web框架有java web框架和go web框架，而java web框架有spring、struts2、传统servlet等；go web框架有net/http、gin、bingo等；非web框架有dubbo、grpc等，上述列举仅对web框架和非web框架进行举例说明，但不限于上述框架种类。
37.不同的应用框架需要根据其自身的框架逻辑、开发语言和运行环境信息等，织入不同的应用程序接口发现代码，比如java传统servlet需要在doget、dopost等方法中织入servletroute discover方法，springboot需要在org.springframework.web.servlet.dispatcherservlet.gethandler方法中织入springbootroutediscover方法。
38.在对应用程序的各个应用程序接口织入应用程序接口发现代码后，形成应用程序接口发现引擎，通过应用程序接口发现引擎统计应用程序接口的数量，从而得到应用程序接口数量。
39.根据应用程序接口发现引擎，对应用程序接口进行数据解析，并获取每个应用程序接口的执行函数，其中根据应用程序接口发现引擎，对应用程序接口进行数据解析，并获取应每个用程序接口的执行函数，包括以下步骤：根据应用程序接口发现引擎，解析每个应用程序接口的应用程序路由；根据应用程序路由，获取应用程序路由对应的请求方法；根据请求方法获取每个应用程序接口的执行函数。
40.应用程序接口发现引擎用于解析应用程序路由，并获取请求方法，完成应用程序路由到执行函数的映射关系，即根据应用程序路由找到对应的执行函数，且请求方法包括get方法、head方法、post方法、put方法、delete方法、connect方法、options方法trace方法和patch方法中的一种或多种。
41.统计测试覆盖率的方法，还包括以下步骤：当织入应用程序接口发现代码时，织入应用程序接口上报代码，得到应用程序接口上报引擎，应用程序接口上报引擎将应用程序路由、请求方法和执行函数上报至服务终端。
42.应用程序接口上报引擎将应用程序路由、应用程序路由对应的请求方法和获取的应用程序接口的执行函数上报至服务终端后，服务终端会在界面上显示该应用程序所有的应用程序接口的相关数据，包括开发语言、运行环境信息、请求方法、应用程序路由以及执行函数，此时标记所有的应用程序接口均为“未请求”，且此时应用启动完成。
43.应用检测时，在执行函数上织入应用程序接口请求检测代码，得到应用程序接口请求引擎；根据应用程序接口请求引擎判断各个应用程序接口是否被访问，计算被访问的应用程序接口数量，并计算测试覆盖率。
44.在应用启动完成，进行测试时，首先调取应用程序的执行函数，并在应用程序的执行函数上织入应用程序接口请求检测代码，该应用程序接口请求检测代码含有检测应用程序接口是否被访问的代码，然后执行应用程序接口请求检测代码，应用程序接口请求检测代码完成执行后，若应用程序接口请求引擎检测到被访问的应用程序接口，则应用程序接口上报引擎会将检测到的被访问的应用程序接口的请求状态和对应的请求方法上报至服
务终端进行记录，且被上报的应用程序接口被标记为“已请求”。
45.计算被访问的应用程序接口数量，并计算测试覆盖率，测试覆盖率的计算公式为：测试覆盖率＝被访问的应用程序接口数量/应用程序接口的数量。
46.当应用在进行功能性检测或安全检测时，需要通过访问应用程序的接口进行，因此若应用程序接口检测到被访问过，则代表该应用程序接口已经经过功能性检测或安全检测，从而应用程序接口的被访问数量即为经过功能性/安全检测的接口的数量，进而得出测试覆盖率为被访问数量/应用程序接口总数量的结论。
47.如图2所示，应用接口覆盖率统计方法还包括以下步骤：根据应用程序接口发现引擎，织入风险检测代码，形成应用程序接口风险检测引擎；判断是否对应用程序接口启动风险检测动作，若需要启动风险检测动作，则调用应用程序接口风险检测引擎，若不需要启动风险检测动作，则结束；若应用程序接口风险检测引擎发现风险函数，则上报风险；反之，继续进行风险检测动作。
48.作为一种实施例，风险检测代码可以在织入应用程序接口发现代码后织入，此时应用程序接口风险检测引擎可以实现对应用程序的所有接口进行风险检测，为降低运行负荷，首先对应用的各个应用程序接口做是否启动风险检测动作的判断，然后根据判断结果执行，若需要对应用程序接口启动风险检测动作，则调用应用程序接口风险检测引擎，应用程序接口风险检测引擎会首先判断应用程序的请求类型，然后对请求的执行函数的内容进行排查，如果排查到危险的执行函数，如runtime.exec，则判定为风险函数，然后通过应用程序接口上报引擎将该应用程序接口以及排查到的风险函数进行上报，提醒工作人员存在风险，并进行人工审核，若未发现，则应用程序接口风险检测引擎进行周期性运行，即周期性执行风险检测动作。
49.在应用程序接口发现代码后织入应用程序风险检测代码有利于对所有的应用程序接口的风险进行防护，防止遗漏某个应用程序接口，导致在后期需要单独对未织入应用程序风险检测代码的应用程序接口进行单独风险检测，防止了事后诸葛亮事件发生，同时应用程序风险检测代码也可在完成测试覆盖率的统计后织入，而需要进行风险检测的应用程序接口主要为以下三种：jsp、php和asp，因此可根据应用程序接口的类型进行判断是否进行风险检测。
50.相较于现有的测试覆盖率的计算方法，本技术为执行方法级别，计算更加精确，例如一个带有正则匹配的模糊路由，使用传统方案会匹配失败，但本技术可以通过确定具体为哪个应用程序接口被执行而进行计算，且现有的测试覆盖率的方法对于无http路由的非web框架无法支持测试覆盖率统计，本技术可以不考虑应用框架，通过应用程序接口发现引擎将所有应用程序接口均获取并计算出，并在此基础上对应用程序接口的测试完成率进行统计以及应用程序接口的风险进行检测。
51.一种应用接口覆盖率统计系统，系统采用上述任意一种应用接口覆盖率统计方法。
52.一种计算机可读存储介质，计算机可读存储介质用于存储和执行上述一种应用接口覆盖率统计系统，计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线段、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线段的电连接、便携式计算机磁盘、硬盘、随机访问
存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
53.综合上述方法，通过在应用程序接口上织入应用程序接口发现代码得出应用程序的应用程序接口总数量，并在应用检测时织入应用程序接口请求检测代码，获取被访问的应用程序接口数量从而计算得到应用程序的测试覆盖率，便于工作人员获取应用程序的测试结果，并通过在应用程序接口织入风险检测代码，使应用程序的各个应用程序接口都进行风险防护，提高应用程序的稳定性，且本方法适用于web框架和非web框架的测试覆盖率计算，对应用框架适用性更强。
54.此外，需要说明的是，本说明书中所描述的具体实施例，其零、部件的形状、所取名称等可以不同。凡依本发明专利构思的构造、特征及原理所做的等效或简单变化，均包括于本发明专利的保护范围内。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，只要不偏离本发明的结构或者超越本权利要求书所定义的范围，均应属于本发明的保护范围。