CN113392032B - 一种api发现的方法、确定测试覆盖率的方法及装置 - Google Patents

Abstract

本申请公开的实施例提供了一种API发现的方法、确定测试覆盖率的方法及装置。其中，前者API发现的方法，包括：通过预先插桩的第一探针获取路由系统注册的URL路径与实际处理程序的映射集合，并根据其中的URL路径与实际处理程序的映射关系信息，获得相应的API信息。上述方案能够全面地、有效地掌握目标Web应用的对外API信息。而后者确定测试覆盖率的方案，则基于前者方案，通过获取目标Web应用中全量的对外API信息，使其能够在测试过程中统计得到准确、可靠的对外API测试覆盖率，进而更有效地评估测试完整性，以客观认识软件质量和更好改进测试工作。

Description

一种API发现的方法、确定测试覆盖率的方法及装置

技术领域

本申请公开的实施例主要涉及Web应用测试领域，且更具体地，涉及一种API发现的方法、确定测试覆盖率的方法及装置。

背景技术

测试覆盖率（Test Coverage）是衡量软件测试完整性的重要指标。掌握可靠的测试覆盖率数据，有利于客观认识软件质量，正确了解测试状态，有效改进测试工作。然而，若欲以测试覆盖率指标评估测试效果，则首先要面对如何去度量测试覆盖率的问题。不同的测试覆盖率定义，会产生完全不同的测试覆盖率数据以及与之相应的度量方法。其中，测试人员可以采用定义接口相关的测试覆盖率（例如接口覆盖率）的方式，来恰当地评估相关测试在接口/对外接口等相关维度的覆盖程度。一般来说，测试覆盖率数据主要是通过计算至少被执行一次的项目（Item）数与该项目总数的比值而获得的（所述项目，即例如前面述及的接口/开放接口）。因此，要获得可靠的接口覆盖率数据，除了准确记录测试执行接口信息外，还需要尽可能地获取应需测试的全部接口信息。

然而，对于以基于前后端分离架构开发的Web应用为测试对象的灰/黑盒测试而言，无论是通过开发团队人工统计，还是通过传统手段——爬虫爬取，往往都很难全面地、不遗漏地获取目标Web应用的对外的API信息。因此，如何获取目标Web应用中全部的对外API信息，成为一个技术难题。

发明内容

根据本申请公开的实施例，提供了一种API发现的方案，以及基于此提供了一种确定测试覆盖率的方案。

在本公开的第一方面中，提供了一种API发现的方法。该方法包括：在目标Web应用程序的路由规则注册过程中或路由规则注册完成后，通过预先插桩的第一探针获取注册的URL路径与实际处理程序的映射集合；根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息，分别生成相应的API信息，并输出所述API信息；所述API信息包括相应的URL路径信息，而每条API信息中的URL路径信息，即所述映射集合中根据其生成该条API信息的URL路径与实际处理程序的映射关系信息中的URL路径信息。

在本公开的第二方面中，提供了一种确定测试覆盖率的方法。该方法包括：对于目标Web应用程序，以第一方面述及的方法，获取目标Web应用程序中全量的对外API信息；对待确定对外API覆盖率的测试，在所述测试过程中，记录目标Web应用程序中被执行的对外API信息，并根据记录的至少被执行一次的对外API数与所述的全量对外API的总数，确定所述测试关于对外API的测试覆盖率。

在本公开的第三方面中，提供了一种装置，用于Web应用程序的API发现。该装置包括：探取模块和API信息生成模块；其中，探取模块，被配置为在目标Web应用程序的初始化路由规则注册过程中或路由规则注册完成后，获取注册的URL路径与实际处理程序的映射集合；API信息生成模块，被配置为根据所述映射集合中的URL路径与实际处理程序的映射关系信息生成、输出相应的API信息；所述API信息包括相应的URL路径信息，其中每条API信息中的URL路径信息，即所述映射集合中根据其生成该条API信息的URL路径与实际处理程序的映射关系信息中的URL路径信息。

在本公开的第四方面中，提供了一种装置，用于确定测试覆盖率。该装置包括：API发现模块和测试统计模块；其中，API发现模块，被配置为用于实现第一方面述及的方法，获取目标Web应用程序中全量的对外API信息/获取、输出目标Web应用程序中全量的对外API信息；对应地，测试统计模块，被配置为在测试过程中记录目标Web应用程序中被执行的对外API信息及根据记录的至少被执行一次的对外API数与所述API发现模块获取到的全量对外API的总数来确定当前测试关于对外API的测试覆盖率/在测试过程中记录并输出目标Web应用程序中被执行的对外API信息。

在本公开的第五方面中，提供了一种装置，用于发现Web应用程序的API/确定测试覆盖率。该装置包括：至少一个处理器，和至少一个处理器耦合的存储器，以及存储在存储器中的计算机程序；其中的处理器执行所述计算机程序，能够实现第一方面述及的API发现的方法，和/或，第二方面述及的确定测试覆盖率的方法。

在本公开的第六方面中，提供了一种计算机可读存储介质。该介质上存储有测试相关的计算机指令，该计算机指令在被计算机处理器执行时能够实现第一、第二方面述及的方法中的部分方法或全部方法。

在本公开的第七方面中，提供了一种计算机程序产品。该程序产品包括计算机程序，该计算机程序在被计算机处理器执行时能够实现第一、第二方面述及的方法中的部分方法或全部方法。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标注表示相同或相似的元素，其中：

图1示出了本公开的多个实施例能够在其中实现的示例环境、及在该示例环境中请求访问过程的示意图；

图2示出了在上述实施例中的一些公开的路由系统的示例、以及基于此请求进入到应用程序的路由过程的示意图；

图3示出了在上述实施例中的一些公开的路由发现模块的示例、以及基于此请求进入到应用程序的路由过程的示意图；

图4示出了在上述实施例中的一些公开的请求进入到MVC应用程序的路由、及路由到控制器等MVC模块实际处理的过程的示意图；

图5示出了在上述实施例中的一些公开的请求进入到MVC应用程序的路由、实际处理的过程的示意图；

图6示出了在上述实施例中的一些公开的请求进入到MVT应用程序的路由、及路由到视图等MVT模块实际处理的过程的示意图；

图7示出了根据本公开的实施例的API发现的过程的示意图；

图8示出了根据本公开的实施例的基于插桩获取URL路径与实际处理程序的映射集合的过程的示意图；

图9示出了根据本公开的实施例的通过触发相关插桩获取URL路径与实际处理程序的映射集合的过程的示意图；

图10示出了根据本公开的实施例的确定测试覆盖率的过程的示意图；

图11示出了根据本公开的实施例的基于插桩记录被执行API的过程的示意图；

图12示出了根据本公开内容示例性实现的一种用于API发现的装置的框图；

图13示出了根据本公开内容示例性实现的一种确定测试覆盖率的装置的框图；

图14示出了根据本公开示例性内容实现的一种用于确定测试覆盖率的相关装置的框图；

图15示出了能够实施本公开的多个实施例的计算设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实施例的描述中术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

在本公开的实施例的描述中技术术语“插桩”，又称“程序插桩”，是指在保证被测程序原有逻辑完整性的基础上在程序中插入“探针”，通过“探针”的执行获取程序的运行特征数据（即运行时数据）；通过对目标特征数据的分析，可以获得程序的控制流、数据流、逻辑覆盖等动态信息，实现相应的测试目的的技术手段。其中的“探针”，本质上是进行信息采集的代码片段。在本公开的实施例的“探针”除了用于获取请求数据和返回数据、获取代码执行中传递的数据、监听内存中特定的值、识别受污染的输入等外，还可以根据插桩点、测试目的、涉及需求等的不同，设计并实现具有相应自定义功能的“探针”。

在本公开的实施例的描述中技术术语“目标Web应用”，是指在被作为测试对象的Web应用，也即一些实施例中的待发现其全量对外API信息的目标对象，和一些实施例中以其为测试对象进行测试、并待确定其在该测试中测试覆盖率的对象。在本公开的实施例的描述中技术术语“目标Web应用程序”，特别是在API发现的方案、确定测试覆盖率的方案中涉及的“目标Web应用程序”，主要是指Web后端应用程序，即如无特殊说明，“目标Web应用程序”具体是指对外暴露API的Web后端应用程序。

统计测试覆盖率，一直是软件测试领域评估测试完整性时最为直观和有效的手段。一般地，被广泛采用的是通过测试覆盖率的计算公式确定相关测试的覆盖率。测试覆盖率的计算公式通常如下：

测试覆盖率=（至少被执行一次的项目）数/项目的总数

其中的项目，可以是语句、判定、分支、函数等等。

而按照测试方法的不同，测试覆盖率又可大致分为三类：白盒测试覆盖率、黑盒测试覆盖率和灰盒测试覆盖率。其中，以白盒测试覆盖率为例，通常可定义语句、判定、条件、路径等代码层面的项目的覆盖率，甚至更直观地以代码为项目定义代码覆盖率；而对于黑/灰盒测试来说，黑盒测试覆盖率，则可定义功能测试覆盖率、性能测试覆盖率等，更具体地还可以定义黑盒扫描过程中攻击指向的目标应用程序对外暴露接口的覆盖率；灰盒测试覆盖率，则通常定义接口以及接口相关的覆盖率，用于度量相关测试的完整性。

对于基于前后端分离架构开发的Web应用项目来说，大多数的Web应用程序都是基于主流开源Web框架开发的，故较之白盒测试，灰、黑盒测试（特别是灰盒测试）都能更高效地发现Web应用程序中的漏洞和缺陷。为实现有效的解耦，前后端分离的Web应用程序通常采用使后端对外暴露API供前端请求调用的方式实现前后端交互。显然，无论是灰盒测试，还是黑盒测试，在相关测试过程中对上述API的覆盖，无疑都能反映相关测试的完整性。然而，越来越多的开发者在开发Web应用时，都追求使其具有大型分布式架构、弹性计算架构、微服务架构、多端化服务等的特点；这样的Web应用项目开发，仅要求开发人员内部人工统计Web应用项目后端对外暴露API是无法做到全面且无遗漏的，况且一些框架（例如JavaSpringMVC）本身就支持在初始化过程中通过注解扫描自动配置对外API及访问路径，而无需开发者人工编写URL路径配置文件。而开发者虽然也可以利用传统的爬虫手段爬取Web后端的对外API，例如通过利用Requests抓取页面时，取得AJAX异步加载的数据来确定一些后端对外暴露的API；但是，对于例如需要在前端页面输入交互才能访问的后端接口（即能被动态生成的链接访问的接口）等API，通过爬虫也是无法直接爬取的。因此，若要确定灰/黑盒测试关于对外API的测试覆盖率，就需要通过有效手段全面地、无遗漏地掌握目标Web应用中对外的API信息。

根据本公开的实施例，提供了一种API发现的方案，和提供了一种确定测试覆盖率的方案。在前者API发现的方案中，通过预先插桩的第一探针获取路由系统注册的URL路径与实际处理程序的映射集合，并根据其中的每条URL路径与实际处理程序的映射关系信息，获得相应的API信息。较之现有技术，上述方案能够全面地、有效地掌握目标Web应用的对外API信息。而后者确定测试覆盖率的方案，基于前者方案，通过获取目标Web应用中全量的对外API信息，使其能够在测试过程中统计得到准确、可靠的对外API测试覆盖率，进而更有效地评估测试完整性，以客观认识软件质量和更好改进测试工作。

以下将参照附图来具体描述本公开的实施例。图1示出了本公开的多个实施例能够在其中实现的示例环境及请求访问时路由过程的示意图。如图1所示，示例环境100中包括：发出请求的浏览器等Web前端应用、分发请求到应用程序的Web服务器，以及请求进入应用程序后涉及的路由系统110和实际处理程序120。在示例环境100中，浏览器等Web前端应用发出的请求经由Web服务器分发到目标Web应用程序，而目标Web应用程序中的路由系统110，则能够为Web应用程序提供路由功能，其能够实现各种请求到实际处理程序之间的映射。而采用路由机制，可以实现前后端实质意义的分离，通过有效的前后端程序解耦和确定统一规范请求URL，即便后续开发过程中前端页面发生变化，也可以不影响到后端，进而简化维护难度；而且，路由机制还可以屏蔽物理路径，提高应用系统安全性。

在一些实施例中，在Web应用程序初始化过程中，路由规则即被注册到路由系统中，而在请求访问时，路由系统中负责路由发现的业务逻辑根据其（注册到路由系统的路由规则）将请求映射到相应的实际处理程序。附加地，在Web应用程序初始化过程中，可以是由路由系统中负责路由规则注册的相关模块将路由规则注册到路由系统中为应用提供路由发现的相关模块中，例如，注册到所述模块中的路由对象（所述路由对象，其具体实现可以是一种预先定义的数据结构），而所述路由对象能够被访问/调用；注册了的路由对象，就载有了URL路径与实际处理程序的映射集合的信息。图2即示出了上述实施例中的路由系统的示例，以及进一步示出了请求进入到应用程序后的以所述路由系统路由的过程的示意图。如图2所示，路由系统110可以包括：路由注册模块210和路由发现模块220；在Web应用初始化过程中，路由注册模块210将配置文件中的（或应用程序初始化相关模块根据注解配置等自动配置的）路由规则注册到路由发现模块220的路由对象（这里的路由对象，即可以是一种预先定义的数据结构）中；而请求进入上述示例应用程序的路由过程200，包括：请求进入到应用程序的路由系统110中，经其中的路由发现模块220获得路由结果，并根据路由结果将请求映射到相应的实际处理程序120。

在一些实施例中，上述的路由对象，可以是采用路由表的形式；而上述的路由发现模块，则可以是包括：路由表，以及路由匹配子模块。图3示出了上述实施例中的路由发现模块的一种实现方式的示例，以及进一步示出了请求进入到应用程序的所述路由发现模块后的具体路由过程的示意图。如图3所示，路由发现模块220包括：路由匹配子模块和路由表320；在Web应用初始化过程中，路由注册模块210即将路由规则注册到路由表320中；而请求进入上述示例应用程序的路由过程300，包括：请求进入到应用程序，当进入到路由系统110中的路由发现模块220时，首先到达路由匹配子模块310，经查询已注册路由规则的路由表320返回指定动作方法（Action Methods）或控制器（类）后，根据上述路由结果将请求映射到相应的实际处理程序——执行指定方法或执行指定控制器及其他相关操作。以上实施例公开的示例方案，可以是ASP.NET Web API（或ASP.NET MVC API）的一种实现。

在一些实施例中，为提高应用程序效率，上述的实际处理程序，可以是采用在MVC框架下开发实现的；所述实际处理程序，主要包括：控制器（即C，Controller）、模型（即M，Model）、视图（即V，View）；其中，控制器（Controller），主要负责业务逻辑处理，在路由指定控制器后，与模型（Model）、视图（View）交互，并返回响应；模型（Model）封装了对数据库层的访问，负责数据处理；视图（View），负责界面显示，用于封装结果，生成页面展示的HTML。图4则示出了上述实施例中的请求进入到MVC应用程序的路由、及路由到控制器等MVC模块实际处理的过程的示意图。如图4所示，请求进入到MVC应用程序的路由及处理过程400，包括：请求进入到MVC应用程序，当进入到路由系统110中的路由发现模块220时，首先到达路由匹配子模块310，经查询已注册路由规则的路由表320返回指定控制器，将请求交到指定控制器开始实际处理；其中，控制器410通过模型420进行数据交互，通过视图430进行试图处理，并将结果作为响应返回；而事实上，控制器410、模型420、视图430，即本实施例的实际处理程序120。以上实施例公开的示例方案，具体地，可以是ASP.NET MVC框架下的Web应用程序的一种实现。

在一些实施例中，所述的目标Web应用程序，可以是MVC应用程序。本实施例中的MVC应用程序，主要包括：控制层（即C，Controller）、模型层（即M，Model）、视图层（即V，View）；其中，不同于前面实施例中的MVC应用程序，控制层（即C，Controller），主要负责接收、处理请求以及业务逻辑处理；控制层（Controller）通常包括前端控制器和后端控制器；一般地，前端控制器接收、处理请求，并访问路由系统的路由发现模块，以便将请求映射到相应的后端控制器上，后端控制器则可以与模型层（Model）、视图层（View）交互，获得视图结果和返回响应；模型层（Model）封装了对数据库层的访问，用于数据处理，对数据库中的数据进行增、删、改、查操作；视图层（View），负责界面显示，用于封装结果，生成页面展示的HTML内容。图5则示出了上述实施例中的请求进入到MVC应用程序的路由、实际处理的过程的示意图。如图5所示，请求进入到MVC应用程序的路由及处理过程500，包括：请求进入到MVC应用程序时，控制层510（具体地，一般是控制器510的前端控制器）访问路由发现模块220，得到返回路由，根据路由将请求映射到相应的后端控制器，继而使控制层510与模型层520进行数据交互，获得所述数据，以及交视图层530进行视图处理，获得用于页面展示的HTML，以返回响应。以上实施例公开的示例方案，可以是例如Java Spring MVC等框架下的Web应用程序的一种实现。

在一些实施例中，所述的目标Web应用程序，可以是MVT应用程序。MVT框架是MVC框架的一种延伸，相较于基于典型MVC框架开发的应用程序，MVT应用程序则在请求实际处理部分采取了进一步抽象，以及对实际处理的具体过程实现了进一步分工、解耦。具体地，所述MVT应用程序，主要包括：视图（即V，View）、模型（即M，Model）、模板（即T，Template）；其中，由于高度抽象出了视图函数对象，故视图（View）与典型MVC框架中的控制层（Controller）功能近似，用于接收、处理请求，与模型（Model）、模板（Template）交互，获得视图结果和返回响应；模型（Model），与典型MVC中的模型层（Model）功能相同，负责和数据库交互，进行数据处理；模板（Template），则与典型MVC中的视图层（View）的一部分功能相似，负责封装构造要返回的HTML；以上则构成了MVT应用程序的实际处理程序；在MVT应用程序中，由于有着高度抽象的视图函数的存在，请求进入到MVT应用程序时，直接经由路由系统（具体地，主要是指路由系统中的路由发现模块）映射到相应的视图函数进行实际处理。图6则示出了上述实施例的请求进入到MVT应用程序的路由、及路由到视图等MVT模块实际处理的过程的示意图。如图6所示，请求进入到MVT应用程序的路由及处理过程600，包括：请求进入到MVT应用程序时，经路由系统110的路由发现模块220的路由，映射给指定的视图函数进行实际处理；实际处理过程则包括：被指定视图函数后，请求进入视图610，并通过与模型620的数据交互，和请求模板630构造HTML，得到响应结果后，响应并输出视图结果；其中，在请求进入到MVT应用程序时，路由系统110的路由发现模块220将请求映射给指定的视图函数的过程，可以是使请求通过路由发现模块220中的URL匹配模块进行匹配，以及进而根据路由发现模块220中的URL-视图映射（所述URL-视图映射，即前面述及的路有对象在本实施例中的一种实现方式）将该请求映射到相应视图函数（即指定视图函数）。以上实施例公开的示例方案，可以是例如Django框架等框架下的Web应用程序的一种实现。

下文将参考图7至图15来详细地描述API发现的过程和确定测试覆盖率的过程。图7示出了根据本公开的一些实施例的API发现的过程的示意图。如图7所示，API发现过程700即示例了一种API发现的过程的实现，过程700可以在示例环境100中来实现。为更清楚地描述所述API发现的过程，以下将结合图1描述过程700。

其中，过程700，主要包括：通过预先插桩的第一探针获取注册的URL路径与实际处理程序的映射集合（参考框701）；以及根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息，分别生成相应的API信息，并输出所述API信息（参考框702）。其中，获取所述映射集合，可以是在目标Web应用程序的例如初始化时等的路由规则注册过程中，也可以是在路由规则注册完成后，以上时间节点，如果安排得当，均能保证获得完整的路由规则信息（具体地，即获得载有完整路由规则的所述映射集合；例如，在一些实施例中，即可以是，直接获取注册的路由表内容，等等）；而所述的API信息，具体地，则包括相应的URL路径信息，而每条API信息中的URL路径信息，即所述映射集合中根据其生成该条API信息的URL路径与实际处理程序的映射关系信息中的URL路径信息。

在一些实施例中，参考框701，所述的获取所述映射集合的实现过程，可以是包括：将所述第一探针插桩在目标Web应用程序路由系统的路由注册模块中，并且配置得使其能够在路由注册模块将路由规则注册到路由系统的过程中，获取所述映射集合。具体地，图8示出了在上述实施例中的一些的基于插桩获取URL路径与实际处理程序的映射集合的过程的示意图。如8所示，获取所述映射集合的过程800，包括：将第一探针810插桩在路由注册模块210，并在其将路由规则注册到路由发现模块220的过程中，获取所述映射集合。

在一些实施例中，参考框701，所述的其获取所述映射集合的实现过程，还可以是包括：将所述第一探针插桩在目标Web应用程序中的在路由注册模块后执行的其他初始化过程相关模块中、或插桩在目标Web应用程序中初始化后执行的相关模块中，并配置得在路由规则注册完成后才使被插桩模块触发所述第一探针，及配置得使所述第一探针访问路由系统（具体地，可以是访问路由系统中的路由发现模块），获取所述映射集合。具体地，图9示出了在上述实施例中的一些的通过触发第一插桩获取URL路径与实际处理程序的映射集合的过程的示意图。如9所示，获取所述映射集合的过程900，包括：将第一探针910插桩在目标Web应用程序中的在路由注册模块后执行的其他初始化过程相关模块中、或插桩在初始化后执行的相关模块中；对应地，在路由规则注册完成后的初始化过程/初始化后的过程中，通过被插桩模块920的执行，触发第一探针910，使其访问路由系统，访问其中的路由发现模块220，通过查表/调用路由发现模块220对外暴露的方法，返回路由，获取所述映射集合。

在一些实施例中，可以是采用运行时插桩的方式，插桩所述探针。所述运行时插桩方式，是指在目标程序运行时对目标插桩位点插桩探针。具体地，参考框701，可以是，在目标Web应用程序启动过程中，对目标插桩位点插桩第一探针。例如，对于Java编程的目标Web应用程序，可以在其类加载时，通过如手动、字节码插桩工具修改等方式对目标插桩点插桩所述探针。

在一些实施例中，参考框702，生成、输出的所述API信息中，还包括：所述URL路径信息映射的实际处理程序信息，已对外暴露更多、更有意义的信息，辅助开发、测试、安全人员分析判断。在不同的Web框架中，所述实际处理程序信息，对应地，可以是所述URL路径信息对应的动作方法信息、处理函数信息、视图函数信息等等。

基于如此（上述的API发现）的方式，本公开的实施例可以通过获取目标Web应用程序内部的URL路径与实际处理程序的映射集合数据，进而不遗漏地掌握其全量对外API信息。

图10则示出了根据本公开的实施例的确定测试覆盖率的过程的示意图。如图7所示，确定测试覆盖率的过程1000，基于上述实施例公开的内容，可以是全部过程在示例环境100中来实现；也可以是部分过程在示例环境100中实现，部分过程输出到例如管理平台等的外部模块实现。为更清楚地描述所述API发现的过程，以下将结合图1、图7等描述过程1000。

其中，过程1000，主要包括：对于目标Web应用程序，以上述实施例公开的API发现的方式，获取目标Web应用程序中全量的对外API信息（参考框1001）；对待确定对外API覆盖率的测试，在其测试过程中，记录目标Web应用程序中被执行的对外API信息（参考框1002）；以及根据记录的至少被执行一次的对外API数与所述的全量对外API的总数，确定所述测试关于对外API的测试覆盖率（参考框1003）。

在一些实施例中，在框1001，获取全量的对外API信息可以是用于本端的对外API的测试覆盖率的确定，并直接对外输出所述测试覆盖率结果；也可以是被输出到外部以用于显示、计算（所述测试关于对外API的测试覆盖率）。对应地，在框1002，记录目标Web应用程序中被执行的对外API信息，可以是在测试过程中的本端进行，或也可以是在测试端进行。对应地，在框1003，确定所述测试覆盖率结果，可以是在本端利用本端计算资源和相应的业务逻辑完成，也可以是利用外部计算资源，例如外部管理平台的计算单元等，根据输出的、外部记录获取的全量对外API信息、被执行的对外API信息等，计算所述测试关于对外API的测试覆盖率。

在一些实例中，参考框1002，所述的记录目标Web应用程序中被执行的对外API信息的实现方式，可以是包括：在测试过程中通过目标Web应用程序预先插桩的第二探针获取所述测试的测试请求访问过的URL路径，记录所述URL路径信息或记录所述URL路径对应的API信息作为所述被执行的对外API信息。其中，具体地，所述第二探针，可以是被插桩在负责请求处理的函数中，具体地，例如接收和处理请求的位点、请求和返回路由发现结果的位点等。具体地，图11示出了上述实施例的基于插桩记录被执行API的过程的示意图。如11所示，基于插桩记录被执行API的过程1100，包括：将第二探针1110插桩在目标Web应用程序相关模块，在例如浏览器等Web前端应用发出的请求，被目标Web应用程序接收和开始处理的过程中，在进行到相应的插桩点时，触发预先插桩的第二探针获取所述测试的测试请求访问过的URL路径。

在一些实施例中，参考框1002，所述的记录目标Web应用程序中被执行的对外API信息的实现方式，还可以是包括：当所述测试为黑盒测试/基于主动攻击的灰盒测试时（以上测试的特点都是通过测试端主动的报文攻击实现的），在测试端根据所述测试已执行的测试请求获取其对应的URL路径及对外API信息，记录所述对外API信息作为所述被执行的对外API信息。

图12示出了根据本公开的实施例的一种用于API发现的装置1200的框图。如图12所示，装置1200包括：探取模块1210和API信息生成模块1220；其中，探取模块1210，被配置为在目标Web应用程序的初始化路由规则注册过程中或路由规则注册完成后，获取注册的URL路径与实际处理程序的映射集合；API信息生成模块1220，被配置为根据探取模块1210获取的所述映射集合中的URL路径与实际处理程序的映射关系信息生成、输出相应的API信息；所述API信息包括相应的URL路径信息，其中每条API信息中的URL路径信息，即所述映射集合中根据其生成该条API信息的URL路径与实际处理程序的映射关系信息中的URL路径信息。

图13示出了根据本公开的实施例的一种确定测试覆盖率的装置1300的框图。如图13所示，的装置1300包括：API发现模块1310和测试统计模块；其中，API发现模块1310，被配置为用于实现上述实施例的API发现的方法，获取目标Web应用程序中全量的对外API信息；测试统计模块1320，被配置为在测试过程中记录目标Web应用程序中被执行的对外API信息及根据记录的至少被执行一次的对外API数与所述API发现模块获取到的全量对外API的总数来确定当前测试关于对外API的测试覆盖率。

图14示出了根据本公开的实施例的一种用于确定测试覆盖率的相关装置1400的框图。如图14所示，装置1400包括：API发现模块1410和测试统计模块1420；其中，API发现模块1410，被配置为获取并输出目标Web应用程序中全量的对外API信息；测试统计模块1420，被配置为在测试过程中记录并输出目标Web应用程序中被执行的对外API信息。具体地，API发现模块输出的目标Web应用程序中全量的对外API信息、1410测试统计模块1420输出目标Web应用程序中被执行的对外API信息，通常都是输出给外部平台。一般地，外部平台，会利用自身的计算资源，例如运行相应的计算模块，根据记录的至少被执行一次的对外API数与所述的全量对外API的总数，确定所述测试关于对外API的测试覆盖率。此外，在外部平台，还可以是将全量对外API信息转化成全量API列表进行管理、以及基于此提供全量API的页面展示，和/或辅助记录、展示至少被执行一次的对外API以辅助确定对外API测试覆盖率等。

根据本公开的一些实施例，还提出了一种装置，用于发现Web应用程序的API/确定测试覆盖率。所述装置，具体地，可以是一种计算设备；图15则示出了上述实施例的可以用来实施本公开的一些实施例的计算设备1500的框图。如图15所示，计算设备1500，包括中央处理器（CPU）1501，其能够根据存储在只读存储器（ROM）1502的计算机程序指令或从存储单元1508加载到随机访问存储器（RAM）1503中的计算机程序指令，来执行各种适当的操作和处理，在（RAM）1503中，还可以存储计算设备1500操作所需的各种程序代码、数据。CPU1501、ROM1502、RAM1503通过总线1504彼此相连，且输入/输出（I/O）接口1505也与总线1504相连。计算设备1500的一些部件通过I/O接口1505接入，包括：输入单元1506，如键鼠等；输出单元1507，如显示器等；存储单元1508，如磁盘、光盘、固态硬盘（SSD）等，以及通信单元1509，如网卡、调制解调器等。通信单元1509能够使计算设备1500通过计算机网络与其他设备交换信息/数据。CPU1501能够执行上述实施例中描述的各种方法和处理过程，例如过程700和/或过程1000。在一些实施例中，过程700和/或过程1000，可以被实现为计算机软件程序，其被例如存储单元1508等的计算机可读介质。在一些实施例中，计算机程序的部分或全部被载入或安装到计算设备1500。当计算机程序被加载到RAM1503被CPU1501执行时，能够执行过程700和/或过程1000的部分或者全部操作。

本文中以上描述的功能都可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、芯片上系统的系统（SOC）、负载可编程逻辑设备（CPLD）等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以独立地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (10)

1.一种API发现的方法，其特征在于，该方法包括：

在目标Web应用程序的路由规则注册过程中/路由规则注册完成后，通过预先插桩的第一探针获取注册的URL路径与实际处理程序的映射集合；

根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息，分别生成相应的API信息，并输出所述API信息；每条所述API信息都包括对应的URL路径信息。

2.根据权利要求1所述的方法，其特征在于，

所述第一探针被插桩在目标Web应用程序的路由注册模块中，并配置得使所述第一探针在所述路由注册模块将路由规则注册到路由系统的过程中，获取所述映射集合；

或，所述第一探针被插桩在路由注册模块后执行的其他初始化过程相关模块中/初始化后执行的相关模块中，并配置得在路由规则注册完成后才使被插桩模块触发所述第一探针，及配置得使所述第一探针访问路由系统，获取所述映射集合。

3.根据权利要求1所述的方法，其特征在于，

对目标Web应用程序插桩所述第一探针的实现方式，包括：以运行时插桩的方式对目标Web应用程序插桩所述第一探针。

4.根据权利要求1所述的方法，其特征在于，

所述API信息中，还包括：所述URL路径信息映射的实际处理程序信息；所述实际处理程序信息，包括：所述URL路径信息对应的动作方法/处理函数/视图函数的信息。

5.一种确定测试覆盖率的方法，其特征在于，该方法包括：

对于目标Web应用程序，以权利要求1-4任一所述的方法，获取目标Web应用程序中全量的对外API信息；

对待确定对外API覆盖率的测试，在所述测试过程中，记录目标Web应用程序中被执行的对外API信息；并根据记录的至少被执行一次的对外API数与所述的全量对外API的总数，确定所述测试关于对外API的测试覆盖率。

6.根据权利要求5所述的方法，其特征在于，

所述的记录目标Web应用程序中被执行的对外API信息的实现方式，包括：

在测试过程中通过预先插桩的第二探针获取所述测试的测试请求访问过的URL路径，记录所述URL路径对应的API信息作为所述被执行的对外API信息；

或，所述测试为黑盒测试/基于主动攻击的灰盒测试时，在测试端根据所述测试已执行的测试请求获取其对应的URL路径及对外API信息，记录所述对外API信息作为所述被执行的对外API信息。

7.一种API发现的装置，其特征在于，该装置包括：

探取模块和API信息生成模块；

所述探取模块，被配置为在目标Web应用程序的初始化路由规则注册过程中/路由规则注册完成后，获取注册的URL路径与实际处理程序的映射集合；

所述API信息生成模块，被配置为根据所述映射集合中的每条URL路径与实际处理程序的映射关系信息分别生成相应的API信息、输出所述API信息；每条所述API信息都包括对应的URL路径信息。

8.一种确定测试覆盖率的装置，其特征在于，该装置包括：

API发现模块和测试统计模块；

所述API发现模块，被配置为用于实现权利要求1-4任一所述的方法，获取目标Web应用程序中全量的对外API信息/获取、输出目标Web应用程序中全量的对外API信息；

对应地，测试统计模块，被配置为在测试过程中记录目标Web应用程序中被执行的对外API信息及根据记录的至少被执行一次的对外API数与所述API发现模块获取到的全量对外API的总数来确定当前测试关于对外API的测试覆盖率/在测试过程中记录并输出目标Web应用程序中被执行的对外API信息。

9.一种装置，其特征在于，该装置包括：

至少一个处理器，和至少一个处理器耦合的存储器，以及存储在存储器中的计算机程序；

其中的处理器执行所述计算机程序，能够实现权利要求1-4任一所述的API发现的方法；

和/或，权利要求5-6任一所述的确定测试覆盖率的方法。

10.一种计算机可读存储介质，其特征在于，

该介质上存储有测试相关的计算机指令，

该计算机指令在被计算机处理器执行时能够实现权利要求1-4任一所述的API发现的方法；

和/或，权利要求5-6任一所述的确定测试覆盖率的方法。

Images