CN113392034B

CN113392034B - API self-discovery method and test coverage statistical method and device based on same

Info

Publication number: CN113392034B
Application number: CN202110940190.5A
Authority: CN
Inventors: 张涛; 宁戈; 刘恩炙; 周幸
Original assignee: Beijing Anpro Information Technology Co ltd
Current assignee: Beijing Anpro Information Technology Co ltd
Priority date: 2021-08-17
Filing date: 2021-08-17
Publication date: 2021-10-15
Anticipated expiration: 2041-08-17
Also published as: CN113392034A

Abstract

The embodiment disclosed by the application provides an API self-discovery method and a test coverage rate statistical method and device based on the API self-discovery method. Wherein the aforementioned API self-discovery method comprises: initializing a routing rule by a target Web application program, registering the routing rule in a routing system, and then automatically discovering a total amount of APIs in the target Web application program based on instrumentation; the API self-discovery method described above can acquire the entire amount of API information (initially registered) of the target Web application at once with low overhead. The test coverage rate statistical method can obtain accurate and reliable API test coverage rate through statistics/real-time statistics in the test process, and further more effectively evaluate test integrity so as to objectively know software quality and better improve test work.

Description

API self-discovery method and test coverage statistical method and device based on same

Technical Field

The embodiments disclosed in the present application mainly relate to the technical field related to Web backend APIs and the technical field related to software testing, and more particularly, to an API self-discovery method and a test coverage statistical method and apparatus based on the same.

Background

Web applications typically employ a master-slave architecture. A Web application in a master-slave architecture is considered to be a front-end (generally, a browser, a part running on a client program, or the client program itself) and a back-end (generally, a part running on a server). Thanks to the development of front-end technology, front-end and back-end separation has become a standard matching mode for developing internet projects and related Web application programs in the industry. Through effective decoupling of the front end and the rear end, separation of the front end and the rear end is achieved, the front end starts to pay more attention to engineering and automation of page development, the rear end is more focused on providing of an API (the API is mainly an important rear end routing implementation mode in a front-rear end separation mode) and guaranteeing of a database, and therefore the possibility is provided for a large-scale distributed architecture, an elastic computing architecture, a micro-service architecture, multi-end service and the like of a software system.

In the whole life cycle of the software project, because of the important role (back-end routing) and significance (front-end and back-end decoupling) of the API provided by the back end, if the whole API provided by the back end in the Web application program can be mastered, the development of the work of development, testing, operation and maintenance and the like of the software project can be facilitated; especially, in the test process, if the whole API of the Web back end can be mastered, the test coverage rate statistics can be facilitated.

However, whether by development team manual statistics or by traditional means-crawler crawling, the goal of obtaining the Web backend full-scale API is unjustly. Therefore, how to obtain the full API provided by the back end of the target Web application program, especially how to obtain the full API at one time to reduce the overhead of the obtaining process, and further provide reliable full API information for the coverage rate statistics of the subsequent related tests, is a technical problem to be solved in the art.

Disclosure of Invention

According to the embodiment disclosed by the application, an API self-discovery scheme (note: the API is provided by the Web backend and mainly refers to a very important backend routing implementation mode in a front-end and back-end separation mode) and a test coverage rate statistic scheme based on the API self-discovery are provided.

In a first aspect of the disclosure, an API self-discovery method is provided. The method comprises the following steps: after a target Web application program initializes a routing rule and registers to a routing system, a full amount of APIs in the target Web application program are found based on instrumentation self; which comprises the following steps: acquiring a mapping set of a URL path corresponding to a routing rule and an actual processing program through a first probe inserted in advance; respectively generating corresponding API information according to the mapping relation information of each URL path in the mapping set and the actual processing program, and outputting the full API information; each piece of the API information includes corresponding URL path information.

In a second aspect of the present disclosure, correspondingly, an API self-discovery apparatus is provided. The device includes: an API self-discovery module and an insertion module; the API self-discovery module is configured to self-discover a full amount of APIs in the target Web application program based on instrumentation after the target Web application program initializes the routing rule to register to the routing system; an API self-discovery module comprising a first probe; specifically, the method comprises the steps of acquiring a mapping set of a URL path corresponding to a routing rule and an actual processing program through a pre-instrumented first probe; respectively generating corresponding API information according to the mapping relation information of each URL path in the mapping set and the actual processing program, and outputting the full API information; wherein, each piece of API information comprises corresponding URL path information; an instrumentation module configured to instrumentation the first probe for a target Web application.

In a third aspect of the present disclosure, a test coverage statistical method based on the API self-discovery is provided. The method comprises the following steps: for the target Web application program, the method mentioned in the first aspect is used for self-discovering and acquiring the total API information in the target Web application program; for the target test in progress (namely the test needing to count the API coverage rate), in the test process, counting/real-time counting the executed API information in the target Web application program, and determining the API test coverage rate of the test according to the recorded number of the APIs executed at least once and the total number of the APIs.

In a fourth aspect of the present disclosure, there is correspondingly provided an apparatus for statistical API test coverage based on API self-discovery. The device includes: a full API discovery module and an API test coverage statistic module; the full API discovery module is configured to implement the method described in the first aspect, and self-discover and acquire full API information in the target Web application program; and the API test coverage counting module is configured to count/count the API information executed in the target Web application program in real time in the test process of the target test, and determine the test API test coverage rate of the test according to the recorded number of the APIs executed at least once and the total number of the full amount of APIs.

In a fifth aspect of the present disclosure, an apparatus is provided. The device includes: at least one processor, a memory coupled to the at least one processor, and a computer program stored in the memory; wherein the processor executes the computer program to implement the API self-discovery method according to the first aspect and/or the test coverage statistical method according to the third aspect.

In a sixth aspect of the disclosure, a computer-readable storage medium is provided. The medium has stored thereon test-related computer instructions capable, when executed by a computer processor, of implementing the API self-discovery method as described in the first aspect and/or the test coverage statistics method as described in the third aspect.

In a seventh aspect of the disclosure, a computer program product is provided. The program product comprises a computer program which, when executed by a computer processor, is capable of implementing the API self-discovery method as described in the first aspect and/or the test coverage statistics method as described in the third aspect.

It should be understood that the statements herein reciting aspects are not intended to limit the critical or essential features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, like or similar reference characters designate like or similar elements, and wherein:

FIG. 1 illustrates a schematic diagram of an example environment in which embodiments of the present disclosure can be implemented, and a request access process in the example environment;

FIG. 2 shows a schematic diagram of an example of some of the disclosed routing systems in the above embodiments, and the routing process for incoming requests to applications based on this request;

FIG. 3 shows a schematic diagram of an example of some of the disclosed route discovery modules in the above embodiments, and a routing process for entering an application based on this request;

FIG. 4 is a schematic diagram illustrating the routing of some of the disclosed requests into an MVC application and the actual processing of the requests by an MVC module, such as a controller, in the above embodiments;

FIG. 5 is a schematic diagram illustrating the routing, actual processing, of some of the disclosed requests into an MVC application in the above embodiments;

fig. 6 is a schematic diagram illustrating the process of actual processing of the MVT module, such as routing of some disclosed requests into the MVT application and routing to the view, in the above embodiment;

FIG. 7 shows a schematic diagram of a process for API self-discovery in accordance with an embodiment of the present disclosure;

FIG. 8 illustrates a block diagram of an API self-discovery apparatus in accordance with an exemplary implementation of the present disclosure;

FIG. 9 shows a schematic diagram of a process for statistical test coverage based on API self-discovery, in accordance with an embodiment of the present disclosure;

FIG. 10 illustrates a block diagram of an apparatus for testing coverage statistics based on API self-discovery in accordance with exemplary implementations of the present disclosure;

FIG. 11 illustrates a block diagram of a computing device capable of implementing various embodiments of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.

The terms "include" and its similar terms are to be understood as open-ended inclusions, i.e., "including but not limited to," in the description of the embodiments of the present disclosure. The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first" and the like may refer to different or the same object. Other explicit and implicit definitions are also possible below.

In the description of the embodiments of the present disclosure, the technical term "instrumentation", also called "program instrumentation", refers to inserting a "probe" into a program on the basis of ensuring the original logic integrity of the program under test, and acquiring running characteristic data (i.e. running data) of the program through the execution of the "probe"; by analyzing the target characteristic data, dynamic information such as control flow, data flow, logic coverage and the like of a program can be obtained, and a corresponding testing purpose is realized. The probe is essentially a code segment for information collection. The "probe" in the embodiments of the present disclosure may be designed and implemented with a corresponding custom function according to differences in peg points, test purposes, requirements, etc., in addition to being used for acquiring request data and return data, acquiring data transferred in code execution, monitoring specific values in memory, recognizing contaminated inputs, etc.

In the description of the embodiments of the present disclosure, the technical term "target Web application" refers to a Web application that is taken as a test object, that is, a target object whose entire amount of external API information is to be found in some embodiments, and an object whose test coverage is to be determined in a test performed on the target Web application as the test object in some embodiments. In the description of the embodiments of the present disclosure, the technical term "target Web application" mainly refers to a Web backend application, that is, unless otherwise specified, "target Web application" specifically refers to a Web backend application that exposes an API to the outside.

The Web, the World Wide Web, is a system of linked hypertext documents accessed through the internet. The Web (world wide Web) is the core of the development of the information age and is the main tool for billions of people to interact on the internet. Unlike the internet, which is a worldwide interconnected computer network system, the world wide web is a worldwide collection of documents and other resources connected by hyperlinks and uniform resource identifiers. The Web can be understood as a Web service built on the internet that makes it possible to provide users with graphical, easy-to-operate access services (e.g., to find and browse information, etc.) on the internet. Generally, when a Web page or other network resource is to be accessed, a Uniform Resource Locator (URL) of the Web page to be accessed is usually keyed into a browser or linked to the corresponding Web page or network resource in a hyperlink manner; after determining the IP address of the server through a series of operations such as domain name resolution and the like, sending an HTTP request to the server working at the IP address; typically, HTML text, pictures, and all other documents that make up the web page are quickly requested and sent back to the user one by one. The Web application is an application that can be accessed through the Web; it can load specific business logic and implement the above access process more efficiently in the business processing process.

Web applications typically employ a master-slave architecture. The master-slave mode structure mainly has two modes of C/S, B/S; wherein, the C/S is a client end/server end program, and generally operates independently; the B/S, i.e., browser-side/server-side application, generally needs to be run with the help of a browser. Generally, Web applications are mostly based on the B/S mode, and with the advent of the mobile internet era, more and more Web applications based on the C/S mode, such as APP, applet, H5, and the like, are emerging. For the development, operation and maintenance life cycle of software projects/products, whether B/S (browser end/server end) or C/S (client end/server end program), the Web application of the master-slave architecture is considered as two parts, namely a front end (generally, a browser, a part running on a client end program or a client end program itself) and a back end (generally, a server end program).

Thanks to the development of front-end technology, front-end and back-end separation has become a standard matching mode for developing internet projects and related Web application programs in the industry. Through effective decoupling of the front end and the rear end, separation of the front end and the rear end is achieved, the front end starts to pay more attention to engineering and automation of page development, the rear end is more focused on providing of an API (the API is mainly an important rear end routing implementation mode in a front-rear end separation mode) and guaranteeing of a database, and therefore the possibility is provided for a large-scale distributed architecture, an elastic computing architecture, a micro-service architecture, multi-end service and the like of a software system.

In the whole life cycle of the software project, because of the important role (back-end routing) and significance (front-end and back-end decoupling) of the API provided by the back-end, if the whole API provided by the back-end in the Web application program can be mastered, the development of the work of the software project, such as development, testing, operation and maintenance, and the like, can be facilitated. For example, it is an efficient use of API information to calculate API test coverage (note: test coverage, always the most intuitive and effective means for the software testing field to evaluate test integrity; where API test coverage = number of APIs executed at least once/total number of APIs). However, to obtain the API, it is only required that the developer manually counts the post-end of the Web application project to expose the API to the outside, which is not comprehensive and is not missed, and some frameworks (such as Java spring mvc) support to automatically configure the external API and the access path through annotation scanning in the initialization process, without the need for the developer to manually write the URL path configuration file. Although, the developer may also crawl the external APIs of the Web backend by using a traditional crawler means, for example, by using Requests to grab pages, and obtaining data asynchronously loaded by AJAX to determine some APIs exposed to the outside of the backend; however, APIs such as backend interfaces (i.e., interfaces accessible by dynamically generated links) that require input interaction on the front-end page to access cannot be crawled directly by a crawler. Therefore, how to obtain the full API provided by the back end of the target Web application program, especially how to obtain the full API at one time to reduce the overhead of the obtaining process, and further provide reliable full API information for the coverage statistics of the subsequent related tests is a technical problem that should be preferentially solved in the art.

According to embodiments of the present disclosure, a scheme for API self-discovery and a scheme for test coverage statistics based on the API self-discovery are provided. In the former API self-discovery scheme, the full amount of APIs in the target Web application program are self-discovered based on instrumentation after the target Web application program initializes the routing rule to register to the routing system; the above-described API self-discovery scheme can acquire the full amount of API information (initially registered) of the target Web application at a time and with low overhead. The latter test coverage rate statistical scheme can obtain accurate and reliable API test coverage rate through statistics/real-time statistics in the test process on the basis of the former scheme, and further more effectively evaluate the test integrity so as to objectively know the software quality and better improve the test work.

Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 illustrates a schematic diagram of an example environment in which embodiments of the present disclosure can be implemented and a routing process when requesting access. As shown in FIG. 1, an example environment 100 includes: a Web front-end application such as a requesting browser, a Web server that distributes requests to application programs, and the routing system 110 and actual handlers 120 involved in entering the requests into the application programs. In the example environment 100, requests issued by a Web front-end application, such as a browser, are distributed to a target Web application via a Web server, and the routing system 110 in the target Web application can provide routing functionality for the Web application that enables mapping of various requests to actual handlers. By adopting a routing mechanism, the separation of the essential significance of the front end and the back end can be realized, and the back end can not be influenced by effectively decoupling the front end program and the back end program and determining the uniform and standardized request URL even if the front end page changes in the subsequent development process, thereby simplifying the maintenance difficulty; in addition, the routing mechanism can shield the physical path and improve the safety of the application system.

In some embodiments, during the Web application initialization process, the routing rules are registered in the routing system, and when requesting access, the service logic in the routing system responsible for route discovery maps the request to the corresponding actual handler according to the routing rules (registered in the routing system). Additionally, during the initialization process of the Web application, the relevant module in the routing system responsible for the registration of the routing rule registers the routing rule into the relevant module in the routing system providing the routing discovery for the application, for example, a routing object (the specific implementation of the routing object may be a predefined data structure) registered in the module, and the routing object can be accessed/invoked; the registered route object carries information of the mapping set of the URL path and the actual handler. Fig. 2 is a schematic diagram showing an example of the routing system in the above embodiment, and further showing a process of routing with the routing system after a request enters an application program. As shown in fig. 2, the routing system 110 may include: a route registration module 210 and a route discovery module 220; in the Web application initialization process, the route registration module 210 registers the route rule in the configuration file (or automatically configured by the application initialization related module according to the annotation configuration, etc.) into the route object (here, the route object may be a predefined data structure) of the route discovery module 220; the routing process 200 for requesting entry into the exemplary application includes: the request enters the routing system 110 of the application program, obtains a routing result through the routing discovery module 220 therein, and maps the request to the corresponding actual handler 120 according to the routing result.

In some embodiments, the routing object may be in the form of a routing table; the route discovery module may include: a routing table, and a route matching submodule. Fig. 3 shows an example of an implementation manner of the route discovery module in the above embodiment, and further shows a schematic diagram of a specific route process after the route discovery module requests to enter into an application program. As shown in fig. 3, the route discovery module 220 includes: a route matching sub-module and a routing table 320; in the Web application initialization process, the routing registration module 210 registers the routing rule into the routing table 320; the routing process 300 for requesting entry into the example application includes: when entering the route discovery module 220 in the routing system 110, the request first reaches the route matching sub-module 310, and after a specified Action method (actions Methods) or controller (class) is returned by querying the routing table 320 with registered routing rules, the request is mapped to a corresponding actual processing program according to the routing result, i.e. the specified method is executed or the specified controller and other related operations are executed. The example solution disclosed in the above embodiment may be an implementation of asp.

In some embodiments, to improve the efficiency of the application program, the above actual processing program may be implemented by being developed under the MVC framework; the actual processing program mainly comprises: controller (i.e., C, Controller), Model (i.e., M, Model), View (i.e., V, View); wherein, the Controller is mainly responsible for the service logic processing, interacts with the Model and the View (View) after the Controller is assigned by the route, and returns a response; the Model (Model) encapsulates the access to the database layer and is responsible for data processing; and the View (View) is responsible for interface display, is used for packaging results and generates page display HTML. Fig. 4 is a schematic diagram illustrating the route of the request entering the MVC application and the actual processing procedure of the request routed to the MVC module such as the controller in the above embodiment. As shown in fig. 4, a process 400 for routing and processing a request into an MVC application includes: when entering the route discovery module 220 in the routing system 110, the request first reaches the route matching sub-module 310, returns to the designated controller by inquiring the routing table 320 with the registered routing rule, and delivers the request to the designated controller to start actual processing; wherein controller 410 performs data interaction through model 420, performs attempted processing through view 430, and returns the results as a response; in fact, the controller 410, the model 420, and the view 430 are the actual handler 120 of the present embodiment. Net MVC framework, and may be a Web application implemented under the asp.

In some embodiments, the target Web application may be an MVC application. The MVC application program in this embodiment mainly includes: a control layer (i.e., C, Controller), a Model layer (i.e., M, Model), and a View layer (i.e., V, View); wherein, unlike the MVC application in the previous embodiment, the control layer (i.e., C, Controller) is mainly responsible for receiving and processing requests and service logic processing; the control layer (Controller) typically includes a front-end Controller and a back-end Controller; generally, a front-end controller receives and processes a request, and accesses a route discovery module of a routing system so as to map the request to a corresponding back-end controller, and the back-end controller can interact with a Model layer (Model) and a View layer (View) to obtain a View result and return a response; the Model layer (Model) encapsulates the access to the database layer, is used for data processing and performs operations of adding, deleting, modifying and searching data in the database; and the View layer (View) is responsible for interface display and is used for packaging results and generating HTML content displayed by the page. Fig. 5 is a schematic diagram illustrating the routing and actual processing of the request entering the MVC application in the above embodiment. As shown in fig. 5, a process 500 for routing and processing a request into an MVC application includes: when a request enters an MVC application, the control layer 510 (specifically, a front-end controller of the controller 510 in general) accesses the route discovery module 220 to obtain a return route, maps the request to a corresponding back-end controller according to the route, and then performs data interaction between the control layer 510 and the model layer 520 to obtain the data, and performs view processing on the view layer 530 to obtain HTML for page display, so as to return a response. The example scheme disclosed in the above embodiment may be an implementation of a Web application under a framework such as Java Spring MVC.

In some embodiments, the target Web application may be an MVT application. Compared with an application program developed based on a typical MVC framework, the MVT application program adopts further abstraction in a part for requesting actual processing, and realizes further division and decoupling of the actual processing concrete process. Specifically, the MVT application program mainly includes: view (i.e., V, View), Model (i.e., M, Model), Template (i.e., T, Template); wherein, because the View function object is highly abstracted, the View (View) is similar to the control layer (Controller) function in the typical MVC framework, and is used for receiving and processing the request, interacting with the Model (Model) and the Template (Template), obtaining the View result and returning the response; the Model (Model) has the same function as a Model layer (Model) in the typical MVC, is responsible for interacting with a database and processing data; template (Template), which is functionally similar to a part of View layer (View) in typical MVC, is responsible for encapsulating HTML to be returned; the above constitutes an actual processing program of the MVT application program; in the MVT application, because of the existence of the highly abstract view function, when a request enters the MVT application, the request is directly mapped to the corresponding view function via the routing system (specifically, mainly referred to as a route discovery module in the routing system) to be actually processed. Fig. 6 is a schematic diagram illustrating the actual processing procedure of the MVT module, such as routing of the request to the MVT application and routing to the view, according to the above embodiment. As shown in fig. 6, a routing and processing procedure 600 for a request to enter an MVT application includes: when the request enters the MVT application program, the route of the route discovery module 220 of the routing system 110 is mapped to a designated view function for actual processing; the actual processing procedure includes: after the view function is designated, requesting to enter a view 610, and constructing HTML through data interaction with the model 620 and a request template 630, and after a response result is obtained, responding and outputting the view result; when a request enters the MVT application, the process of the route discovery module 220 of the routing system 110 mapping the request to the designated view function may be to match the request through a URL matching module in the route discovery module 220, and further map the request to the corresponding view function (i.e., the designated view function) according to a URL-view mapping (the URL-view mapping, i.e., an implementation manner of the aforementioned route object in this embodiment) in the route discovery module 220. The example scheme disclosed in the above embodiment may be an implementation of a Web application under a framework such as a Django framework.

The procedure of API self-discovery and the procedure of testing coverage based on statistics of the API self-discovery will be described in detail below with reference to fig. 7 to 11. FIG. 7 illustrates a schematic diagram of a process for API self-discovery in accordance with some embodiments of the present disclosure. Schematic diagram of the process of discovery. As shown in FIG. 7, an API self-discovery process 700 illustrates an implementation of an API self-discovery process, process 700 may be implemented in exemplary environment 100. To more clearly describe the process of API self-discovery, process 700 is described below in conjunction with FIG. 1.

The process 700 mainly includes: after a target Web application program initializes a routing rule and registers to a routing system, triggering corresponding instrumentation self-discovery of a total API in the target Web application program; specifically, the method comprises the following steps: acquiring a mapping set of a URL path corresponding to the registered routing rule and an actual processing program through a pre-instrumented first probe (refer to a block 701); generating and outputting full-scale API information according to the mapping relation information of each URL path in the mapping set and the actual processing program (refer to a box 702); the API information includes corresponding URL path information. The mapping set may be obtained after the routing rule in the initialization process is registered in the routing system, or after the initialization process is performed (generally, the default routing rule is also registered and is registered in the routing system); therefore, the first probe is triggered to acquire the mapping set, i.e. to self-discover the route.

In some embodiments, referring to block 701, obtaining a set of mappings of registered URL paths and actual handlers by the pre-instrumented first probe may be: according to the routing mechanism provided by the framework itself or the routing mechanism provided by the self-research project, a controller/view function of full route discovery (i.e. acquiring all routes) is added to the routing system (and corresponding routing rules can be correspondingly added), and the first probe is configured to include: the full route discovery controller/view function can be invoked and a set of mappings of URL paths and actual handlers corresponding to all the registered routing rules returned is received. In particular, in some of the above embodiments, the first probe may be triggered (for example, when the instrumentation code is invoked when being executed by the whole program code to the instrumentation point, so that the instrumentation point may be selected from the code executed after the routing rule registration is completed or the code executed after the whole initialization process is completed); the calling may be to call the full routing controller/view function according to the added corresponding new routing rule, and then return and receive a set of mapping relationships between URL paths corresponding to all the registered routing rules and the actual processing program. As will be described below with reference to more specific examples, in some of the above embodiments, the route of the target Web application may be: if the routing information is provided by a self-contained routing mechanism of the Java Spring MVC framework (developed based on the Java Spring MVC framework), adding a new routing rule of a full-route discovery controller (controller subclass) in the routing mapping, adding the full-route discovery controller and a matching method thereof, and configuring to enable the first probe to directly access and execute the full-route discovery controller and the matching method thereof through an ULR path in the default routing rule after being triggered, so as to further acquire all routing information (namely the mapping set); the above controller may match the following method to return all routing information (i.e. URL path and its corresponding controller, matching method, etc.): namely, acquiring an instance of RequestMappingHandlerMapping by a getBean method of WebApplicationContext of Spring; and calling getHandlermethods through an instance of RequestMappingHandlerMapping to acquire the URL path and corresponding method information. In some of the above embodiments, the routing of the target Web application may also be: if the mapping is provided by a self-contained routing mechanism of the framework (if the mapping is developed based on a Web framework of Python language such as Django, Flask and the like), a new full-route discovery view function and a corresponding URL path-view function mapping relation (namely an implementation form of a routing rule under the framework) are added into the routing mapping, and the configuration is carried out so that the URL path is accessed after the first probe is triggered to execute the full-route discovery view function; and then all routing information (namely a set of mapping relations between the URL path and the view function, namely a mode of the mapping set) is returned; the view function may specifically be a mapping relationship that outputs all URL paths and corresponding view functions through a path object (e.g., URL-part) in the circular routing system.

In some embodiments, referring to block 701, acquiring a mapping set of the registered URL path and the actual handler through the pre-instrumented first probe may further be: the configuration enables the first probe to traverse the routing objects in the routing system and acquire a set of mapping relations between URL paths corresponding to all registered routing rules and the actual processing program. For example, an instance of RequestMappingHandlerMapping is obtained by directly passing the first probe through the getBean method of WebApplicationContext by Spring; calling getHandlermethods through an instance of RequestMappingHandlerMapping to obtain URL paths and corresponding method information; for example, the first probe directly loops the route object (e.g., URL-part) in the routing system, and outputs all URL paths and the mapping relationship of the corresponding view functions.

In some embodiments, the instrumentation code may be directly written (e.g., compiled) into the code of the target Web application, and the instrumentation probe and thus the triggering of the first probe may be implemented when the code is executed in the initialization process, or the probe may be instrumented in a runtime instrumentation manner. The pile inserting mode during operation refers to inserting a probe into a target pile inserting site during the operation of a target program. Specifically, referring to block 701, a first probe may be instrumented at a target instrumentation site during a start-up process of a target Web application. For example, for a Java programmed target Web application, the probe may be instrumented at the target instrumentation point by means such as manual, bytecode instrumentation tool modification, etc. when its class is loaded.

In some embodiments, referring to block 702, generating and outputting the full API information further includes: the actual processing program information mapped by the URL path information has more and more meaningful information exposed to the outside, and assists development, testing and analysis and judgment of safety personnel. In a different Web framework, the actual handler information, correspondingly, may be action method information, processing function information, view function information, and the like corresponding to the URL path information.

Correspondingly, fig. 8 illustrates a block diagram of an apparatus 800 for API self-discovery in accordance with an exemplary implementation of the present disclosure. As shown in fig. 8, the apparatus 800 includes: API self-discovery module 810, and instrumentation module 820; the API self-discovery module 810 is configured to trigger corresponding instrumentation self-discovery of a full API in a target Web application after a routing rule in an initialization process of the target Web application is registered in a routing system (or after initialization registration); specifically, an API self-discovery module comprising a first probe; the method comprises the steps that a mapping set of a URL path corresponding to a routing rule and an actual processing program is obtained through a pre-instrumented first probe; respectively generating corresponding API information according to the mapping relation information of each URL path in the mapping set and the actual processing program, and outputting the full API information; wherein, each piece of API information comprises corresponding URL path information; and an instrumentation module 820 configured to instrument the first probe for a target Web application.

In some embodiments, this may be: enabling the API self-discovery module to specifically comprise a trigger submodule and a first probe; a trigger sub-module configured to be capable of triggering the first probe; for example, a first probe is instrumented in a correlation function after the routing rule registration in the initialization process, and the first probe is triggered by the sequential execution of the whole code (note: therefore, the instrumented point can be selected from the code executed after the routing rule registration is completed, or the code executed after the initialization process is completed); the first probe is specifically configured to acquire a mapping set of the URL path corresponding to the routing rule and the actual processing program after being triggered, and respectively generate corresponding API information and further output full-scale API information according to mapping relation information of each URL path in the mapping set and the actual processing program; and enabling each piece of API information to comprise corresponding URL path information.

In some embodiments, this may be: enabling the API self-discovery module to specifically comprise a trigger submodule, a first probe and an API information generation submodule; wherein a trigger submodule, such as the aforementioned trigger submodule, is configured to be able to trigger the first probe; the first probe is specifically configured to acquire a mapping set of a URL path corresponding to the routing rule and an actual processing program after being triggered; the API information generation submodule is configured to respectively generate corresponding API information and further output full-scale API information according to the mapping relation information of each URL path in the mapping set and the actual processing program acquired by the first probe; and enabling each piece of API information to comprise corresponding URL path information.

In some embodiments, this may be: correspondingly, a full route discovery controller/view function is added in the framework or the self-developed routing system (correspondingly, the corresponding routing rule can also be registered in the routing system); the first probe of the API self-discovery module can call the controller/view function of the full route discovery after being triggered; and further acquiring a mapping set of the URL path corresponding to the registered routing rule and the actual processing program. As will be described below with reference to more specific examples, in some of the above embodiments, the route of the target Web application may be: if the routing information is provided by a self-contained routing mechanism of the Java Spring MVC framework (developed based on the Java Spring MVC framework), adding a new routing rule of a full-route discovery controller (controller subclass) in the routing mapping, adding the full-route discovery controller and a matching method thereof, and configuring to enable an API to directly access and execute the full-route discovery controller and the matching method thereof through a ULR path in the default routing rule after a first probe of a self-discovery module is triggered so as to further acquire all routing information (namely the mapping set); the above controller may match the following method to return all routing information (i.e. URL path and its corresponding controller, matching method, etc.): namely, acquiring an instance of RequestMappingHandlerMapping by a getBean method of WebApplicationContext of Spring; and calling getHandlermethods through an instance of RequestMappingHandlerMapping to acquire the URL path and corresponding method information. In some of the above embodiments, the routing of the target Web application may also be: if the mapping is provided by a self-contained routing mechanism of the framework (if the mapping is developed based on a Web framework of Python language such as Django, Flask and the like), a new full-route discovery view function and a corresponding URL path-view function mapping relation (namely an implementation form of a routing rule under the framework) are added in the routing mapping, and the configuration is made so that an API accesses the URL path after a first probe of a discovery module is triggered to execute the full-route discovery view function; and then all routing information (namely a set of mapping relations between the URL path and the view function, namely a mode of the mapping set) is returned; the view function may specifically be a mapping relationship that outputs all URL paths and corresponding view functions through a path object (e.g., URL-part) in the circular routing system.

In some embodiments, it may then be: the direct configuration enables the first probe of the API self-discovery module to traverse the routing objects in the routing system and acquire the set of the mapping relations between the URL paths corresponding to all the registered routing rules and the actual processing program. For example, an instance of RequestMappingHandlerMapping is obtained by directly passing the first probe through the getBean method of WebApplicationContext by Spring; calling getHandlermethods through an instance of RequestMappingHandlerMapping to obtain URL paths and corresponding method information; for example, the first probe directly loops the route object (e.g., URL-part) in the routing system, and outputs all URL paths and the mapping relationship of the corresponding view functions.

In some embodiments, the instrumentation module may be instrumentation code configured to directly write (e.g., compile) instrumentation code into code of the target Web application, and implement instrumentation probes and further (automatic) triggering of the first probe according to sequential execution when executing the code in an initialization process, or may be to use runtime instrumentation to instrumentation the probes. The pile inserting mode during operation refers to inserting a probe into a target pile inserting site during the operation of a target program. Specifically, during the starting process of the target Web application, the target instrumentation site may be instrumented with a first probe. For example, for a Java programmed target Web application, the probe may be instrumented at the target instrumentation point by means such as manual, bytecode instrumentation tool modification, etc. when its class is loaded.

In some embodiments, the generating and outputting of the full amount of API information by the API self-discovery module further includes: the actual processing program information mapped by the URL path information has more and more meaningful information exposed to the outside, and assists development, testing and analysis and judgment of safety personnel. In a different Web framework, the actual handler information, correspondingly, may be action method information, processing function information, view function information, and the like corresponding to the URL path information.

Fig. 9 shows a schematic diagram of a process of statistical test coverage based on the API self-discovery scheme in the above embodiments according to an embodiment of the present disclosure. As shown in fig. 9, a process 900 for statistical test coverage includes: for the target Web application, the API self-discovery method in any of the above embodiments is used to discover and acquire the full amount of API information in the target Web application (refer to block 901); for the target test in progress, during the test process, the information of the executed APIs in the target Web application is counted/counted in real time (refer to block 902), and the API test coverage of the test is determined according to the recorded number of APIs executed at least once and the total number of the full amount of APIs (refer to block 903).

Correspondingly, fig. 10 shows a block diagram of an apparatus 1000 for testing coverage statistics based on API self-discovery according to an embodiment of the present disclosure. As shown in fig. 10, the apparatus 1000 includes: a full API discovery module 1010 and an API test coverage statistics module 1020; the full API discovery module 1010 is configured to implement the API self-discovery method in any one of the above embodiments, and discover and acquire full API information in the target Web application; the API test coverage statistics module 1020 is configured to, during a test process of the target test, count/perform real-time statistics on API information executed in the target Web application, and determine an API test coverage of the test according to the recorded number of APIs executed at least once and the total number of total APIs obtained by the total API discovery module 1010.

According to some embodiments of the present disclosure, there is also provided an apparatus for API self-discovery and/or API test coverage statistics as described above. The apparatus, in particular, may be a computing device; fig. 11 illustrates a block diagram of a computing device 1100, which may be used to implement some embodiments of the present disclosure, of the above-described embodiments. As shown in fig. 11, the computing device 1100 includes a Central Processing Unit (CPU) 1101 capable of executing various appropriate operations and processes according to computer program instructions stored in a Read Only Memory (ROM) 1102 or computer program instructions loaded from a storage unit 1108 into a Random Access Memory (RAM) 1103, and in the (RAM) 1103, various program codes, data required for the operation of the computing device 1100 may also be stored. The CPU1101, ROM1102, RAM1103 are connected to each other through a bus 1104, and an input/output (I/O) interface 1105 is also connected to the bus 1104. Some of the components of the computing device 1100 are accessed through the I/O interface 1105, including: an input unit 1106 such as a keyboard and mouse; an output unit 1107 such as a display or the like; a storage unit 1108 such as a magnetic disk, an optical disk, a Solid State Disk (SSD), etc., and a communication unit 1109 such as a network card, a modem, etc. The communication unit 1109 enables the computing device 1100 to exchange information/data with other devices over a computer network. The CPU1101 can perform various methods and processes described in the above embodiments, such as process 700 and/or process 900. In some embodiments, process 700 and/or process 900 may be implemented as a computer software program that is stored on a computer-readable medium, such as storage unit 1108. In some embodiments, part or all of the computer program is loaded or installed into the computing device 1100. When the computer program is loaded into RAM1103 and executed by CPU1101, some or all of the operations of process 700 and/or process 900 can be performed.

The functions described herein above may all be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a load programmable logic device (CPLD), and the like.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are depicted in a particular order, this should be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. An API self-discovery method, comprising:

after a target Web application program initializes a routing rule and registers to a routing system, a full amount of APIs in the target Web application program are found based on instrumentation self;

which comprises the following steps: acquiring a mapping set of a URL path corresponding to the registered routing rule and an actual processing program through a first probe inserted in advance; generating and outputting full API information according to the mapping relation information between each URL path in the mapping set and the actual processing program; the API information includes corresponding URL path information.

2. The method of claim 1,

the acquiring the mapping set through the pre-instrumented first probe includes: correspondingly adding a full route discovery controller/view function and configured such that said first probe comprises: the full route discovery controller/view function can be called, and a mapping set of URL paths corresponding to all returned registered routing rules and an actual processing program is obtained;

or the like, or, alternatively,

the acquiring the mapping set through the pre-instrumented first probe includes: the configuration enables the first probe to traverse the routing objects in the routing system and acquire a set of mapping relations between URL paths corresponding to all registered routing rules and the actual processing program.

3. The method of claim 1,

the implementation mode of the first probe for target Web application program instrumentation comprises the following steps: the first probe is inserted into a target Web application program in a runtime insertion mode;

and/or the presence of a gas in the gas,

making the API information further include: actual handler information mapped by the URL path information; the actual handler information includes: and the URL path information corresponds to the information of the action method/processing function/view function.

4. An apparatus for API self discovery, the apparatus comprising:

an API self-discovery module and a pile insertion module;

the API self-discovery module is configured to self-discover the full amount of APIs in the target Web application program based on instrumentation after the target Web application program initializes the routing rule to register to the routing system;

the API self-discovery module comprises a first probe; the API self-discovery module is specifically configured to include: acquiring a mapping set of a URL path corresponding to a routing rule and an actual processing program through the first probe which is pre-instrumented; respectively generating corresponding API information according to the mapping relation information of each URL path in the mapping set and the actual processing program, and outputting the full API information; wherein, each piece of API information comprises corresponding URL path information;

the instrumentation module is configured to instrumentation the first probe for a target Web application.

5. The apparatus of claim 4,

making the API self-discovery module specifically include:

the trigger submodule and the first probe are triggered; wherein the trigger sub-module is configured to be capable of triggering the first probe; the first probe is specifically configured to acquire a mapping set of a URL path corresponding to a routing rule and an actual processing program after being triggered, and respectively generate corresponding API information and further output full-scale API information according to mapping relation information of each URL path in the mapping set and the actual processing program; wherein, each piece of API information comprises corresponding URL path information;

or the like, or, alternatively,

making the API self-discovery module specifically include:

the trigger submodule, the first probe and the API information generation submodule; wherein the trigger sub-module is configured to be capable of triggering the first probe; the first probe is specifically configured to acquire a mapping set of a URL path corresponding to a routing rule and an actual processing program after being triggered; the API information generation submodule is configured to respectively generate corresponding API information and further output full-scale API information according to the mapping relation information of each URL path in the mapping set and the actual processing program acquired by the first probe; and enabling each piece of API information to comprise corresponding URL path information.

6. The apparatus of claim 4,

correspondingly adding a full-route discovery controller/view function, and configuring to enable a first probe of the API self-discovery module to call the full-route discovery controller/view function after being triggered, so as to obtain a mapping set of a URL path corresponding to the registered routing rule and an actual processing program; or, the first probe of the API self-discovery module is directly configured to traverse the routing object in the routing system, and obtain a set of mapping relationships between URL paths corresponding to all registered routing rules and the actual processing program;

and/or the presence of a gas in the gas,

the instrumentation module is configured to instrumentation the first probe to a target Web application in a runtime instrumentation manner;

and/or the presence of a gas in the gas,

the API information generated and output by the API self-discovery module further includes: actual handler information mapped by the URL path information; the actual handler information includes: and the URL path information corresponds to the information of the action method/processing function/view function.

7. A test coverage statistical method based on API self-discovery is characterized by comprising the following steps:

for a target Web application, self-discovering and obtaining the full amount of API information in the target Web application by the method of any one of claims 1-3;

for the target test, in the test process, counting/real-timely counting the executed API information in the target Web application program, and determining the test API test coverage rate of the test according to the recorded number of the APIs executed at least once and the total number of the APIs.

8. An apparatus for API self-discovery statistical API test coverage method, the apparatus comprising:

a full API discovery module and an API test coverage statistic module;

the full API discovery module is configured to implement the method of any one of claims 1 to 3, and self-discover and acquire full API information in the target Web application;

the API test coverage statistic module is configured to count/count API information executed in a target Web application program in real time in the test process of the target test, and determine the test API test coverage rate of the test according to the recorded number of the APIs executed at least once and the total number of the full-scale APIs.

9. An apparatus for API self-discovery and/or statistical API test coverage based on said API self-discovery, the apparatus comprising:

at least one processor, a memory coupled to the at least one processor, and a computer program stored in the memory;

wherein the processor executes the computer program to implement the API self-discovery method of any one of claims 1-3;

and/or the API self-discovery based test coverage statistical method of claim 7.

10. A computer-readable storage medium, characterized in that,

the medium having stored thereon test-related computer instructions,

the computer instructions, when executed by a computer processor, are capable of implementing the API self-discovery method of any of claims 1-3;