CN111797013A

CN111797013A - Interface detection tool generation method, interface detection method, device, equipment and medium

Info

Publication number: CN111797013A
Application number: CN202010608403.XA
Authority: CN
Inventors: 管伟; 张祖俭
Original assignee: Beijing ByteDance Network Technology Co Ltd
Current assignee: Beijing ByteDance Network Technology Co Ltd
Priority date: 2020-06-29
Filing date: 2020-06-29
Publication date: 2020-10-20

Abstract

The embodiment of the disclosure discloses an interface detection tool generation method, an interface detection device and a medium, wherein the interface detection tool generation method comprises the following steps: generating a rule resolver according to rule content of the interface export rule; generating a local interface detection plug-in according to the rule parser and a first preset plug-in; and generating an external interface detection plug-in according to the rule parser and a second preset plug-in. According to the technical scheme of the embodiment of the disclosure, the interfaces of the modules can be detected on the premise of not reconstructing the Android engineering module, so that the interface export rules of different modules are controlled.

Description

Interface detection tool generation method, interface detection method, device, equipment and medium

Technical Field

The embodiment of the disclosure relates to the technical field of android development, in particular to a method, a device, equipment and a medium for generating and detecting an interface detection tool.

Background

The construction tool of the Android project is Gradle. Gradle manages the whole Android project in the concept of Module. A plurality of modules may exist in an Android project, including a main Module and a plurality of sub modules. The master Module may rely on multiple child modules. A huge Android project is split into different modules, decoupling between different service modules can be achieved, modular reconstruction of the project is completed, and therefore the purpose of project optimization is achieved. Gradle realizes the description of the dependency relationship between different modules in engineering through a set of DSL (Domain specific language) languages based on Groovy built by Gradle. FIG. 1a is a diagram illustrating the effect of dependency relationship between different modules in the prior art, as shown in FIG. 1a, Module A depends on Module lib1 and Module lib 2.

Gradle provides a code multiplexing and packaging infrastructure of Module granularity for developers, but the application of the Module has a problem of how to limit an API (application programming Interface) exposed to the outside by the Module. FIG. 1B is a schematic diagram illustrating the effect of the dependency relationship between different modules in the prior art, as shown in FIG. 1B, Module A depends on Module B, and Module B internally includes InnerUtil, which is only used internally by Module B. When a developer declares the dependency relationship between the Module A and the Module B through the Groovy code, the developer cannot be limited to continue using InnerUtil in the Module A. Module B exposes APIs that should not be exposed to other modules that depend on itself, resulting in the boundaries and responsibilities of the modules no longer being clear.

In the prior art, there are generally two schemes for keeping a module clearly bounded. The first scheme is a basic scheme, and particularly divides a Module into an Interface Module and an Implementation Module. I.e. the interface is separated from the implementation, and the modules rely on the interface and not on the implementation. Fig. 1c is a schematic diagram illustrating the effect of dependencies between different modules via interfaces in the prior art. As shown in FIG. 1c, the API not required to be exposed to the external Module can be sunk into the Implementation Module, and the external only interacts with the API exposed by the Interface Module B. The second scheme is an evolution scheme, in particular, a Module boundary is exposed by creating an api file. FIG. 1d is a diagram illustrating the effect of preserving module boundaries by creating an api file in the prior art. As shown in fig. 1d, in a Module, API, Class or other resources that can be used by the outside Module are chosen, suffixed with "API", and custom DSL is used in the engineering document to introduce dependencies. That is, the sinking process of the non- ". about.api" files, resources is achieved by copying all ". about.api" files to another "SDK" project. Other modules rely solely on "SDK" engineering.

In the process of implementing the present disclosure, the inventors found that the following defects exist in the prior art: the basic scheme can increase the number of modules, influence the compiling progress, and have higher cost for reconstructing and migrating the existing modules. The basic scheme can realize separation of interface and implementation, but also reduces convergence of the module. Moreover, the existing Module engineering is quite complicated. The evolution scheme needs to introduce additional Gradle plug-ins, which causes great invasion of the configuration of the Gradle, and simultaneously needs to introduce a ". about.api" file to influence the semantization. The principle of the evolution scheme is to realize Module sinking processing by self-defining DSL functions, and for modules containing only a ". about.api" resource, the evolution scheme still belongs to the basic scheme of automation in nature.

Disclosure of Invention

The embodiment of the disclosure provides interface detection tool generation and interface detection methods, devices, equipment and media, which are used for detecting interfaces of an Android engineering module on the premise of not reconstructing the Android engineering module, so that interface export rules of different modules are controlled.

In a first aspect, an embodiment of the present disclosure provides an interface detection tool generation method, including:

generating a rule resolver according to rule content of the interface export rule;

generating a local interface detection plug-in according to the rule parser and a first preset plug-in;

and generating an external interface detection plug-in according to the rule parser and a second preset plug-in.

In a second aspect, an embodiment of the present disclosure further provides an interface detection method, including:

acquiring an object to be detected; the object to be detected is configured with an interface export rule aiming at the API of each module;

performing local detection on the API of the object to be detected through a local interface detection plug-in to generate a local test object;

and carrying out external detection on the API of the local test object through an external interface detection plug-in to generate a target detection result.

In a third aspect, an embodiment of the present disclosure further provides an interface detection tool generating apparatus, including:

the rule resolver generation module is used for generating a rule resolver according to the rule content of the interface export rule;

the local interface detection plug-in generation module is used for generating a local interface detection plug-in according to the rule parser and the first preset plug-in;

and the external interface detection plug-in generation module is used for generating an external interface detection plug-in according to the rule parser and a second preset plug-in.

In a fourth aspect, an embodiment of the present disclosure further provides an interface detection apparatus, including:

the to-be-detected object acquisition module is used for acquiring the to-be-detected object; the object to be detected is configured with an interface export rule aiming at the API of each module;

the local detection module is used for carrying out local detection on the API of the object to be detected through the local interface detection plug-in to generate a local test object;

and the external detection module is used for carrying out external detection on the API of the local test object through the external interface detection plug-in to generate a target detection result.

In a fifth aspect, an embodiment of the present disclosure further provides an electronic device, where the electronic device includes:

one or more processors;

storage means for storing one or more programs;

when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the interface detection tool generation method of any of the first aspects.

In a sixth aspect, the disclosed embodiments also provide a computer storage medium, on which a computer program is stored, where the program, when executed by a processor, implements the interface detection tool generation method described in any of the first aspects.

In a seventh aspect, an embodiment of the present disclosure further provides an electronic device, where the electronic device includes:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the interface detection method of any of the second aspects.

In a sixth aspect, the disclosed embodiments also provide a computer storage medium, on which a computer program is stored, which when executed by a processor implements the interface detection method according to any of the second aspects.

The disclosed embodiment generates a rule parser by deriving rule content of a rule according to an interface, and generates a local interface detection plug-in according to the rule parser and a first preset plug-in, generating an external interface detection plug-in according to the rule parser and a second preset plug-in to locally detect the API of the object to be detected through a local interface detection plug-in to generate a local test object, and the external interface detection plug-in is used for carrying out external detection on the API of the local test object to generate a target detection result, so that the problems of the existing Android engineering module interface boundary processing method, such as influence on compilation progress, high reconstruction cost, reduction in module convergence, large configuration invasion, influence on semantization and the like, are solved, and on the premise of not reconstructing the Android engineering module, and detecting the interfaces of the Android engineering module so as to control the interface export rules of different modules.

Drawings

FIG. 1a is a diagram illustrating the effect of dependency relationship between different modules in the prior art;

FIG. 1b is a diagram illustrating the effect of dependency relationship between different modules in the prior art;

FIG. 1c is a schematic diagram illustrating the effect of dependencies between different modules via interfaces in the prior art;

FIG. 1d is a diagram illustrating the effect of preserving module boundaries by creating an api file in the prior art;

fig. 2 is a flowchart of an interface detection tool generation method provided by an embodiment of the present disclosure;

fig. 3a is a flowchart of an interface detection tool generation method provided by an embodiment of the present disclosure;

fig. 3b is a schematic view of monitoring when an engineering is opened according to an embodiment of the present disclosure;

fig. 3c is a schematic diagram of a trigger logic corresponding to a click Action according to an embodiment of the present disclosure;

FIG. 3d is a schematic diagram of a first core detection logic provided by an embodiment of the present disclosure;

fig. 4a is a flowchart of an interface detection tool generation method provided by an embodiment of the present disclosure;

fig. 4b is a schematic diagram illustrating an effect of implementing rule parsing logic by a module according to an embodiment of the present disclosure;

FIG. 4c is a schematic diagram of a second core detection logic provided by an embodiment of the present disclosure;

FIG. 4d is a schematic diagram of a configuration file for searching for interface export rules according to an embodiment of the present disclosure;

fig. 5a is a flowchart of an interface detection method provided by an embodiment of the present disclosure;

fig. 5b is a flowchart of interface detection provided by the embodiment of the present disclosure;

fig. 6 is a schematic diagram of an interface detection tool generation apparatus provided in an embodiment of the present disclosure;

fig. 7 is a schematic diagram of an interface detection apparatus provided in an embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of an electronic device according to an embodiment 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.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order, and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "include" and variations thereof as used herein are open-ended, i.e., "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Relevant definitions for other terms will be given in the following description.

It should be noted that the terms "first", "second", and the like in the present disclosure are only used for distinguishing different objects or different devices, modules, or units, and are not used for limiting the order or interdependence of the functions performed by the devices, modules, or units.

It is noted that references to "a", "an", and "the" modifications in this disclosure are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that "one or more" may be used unless the context clearly dictates otherwise.

The names of messages or information exchanged between devices in the embodiments of the present disclosure are for illustrative purposes only, and are not intended to limit the scope of the messages or information.

Examples

Fig. 2 is a flowchart of a method for generating an interface detection tool according to an embodiment of the present disclosure, where the embodiment is suitable for generating an interface detection tool according to a module interface export rule to detect an Android engineering module interface, and the method may be executed by an interface detection tool generation apparatus, and the apparatus may be implemented by software and/or hardware, and may generally be integrated in an electronic device. The electronic device may be a terminal device, may include a notebook computer and the like, or may also be a server. Accordingly, as shown in fig. 2, the method includes the following operations:

and S110, generating a rule resolver according to the rule content of the interface export rule.

In an optional embodiment of the present disclosure, the rule parser is configured to parse an obtained interface export rule of an object to be detected, where the object to be detected is developed based on an Android system. And the object to be detected is configured with an interface export rule aiming at the API of each module.

The interface export rule may be a rule about an exposed interface declared for each Module in the Android project, and interface information that each Module may be exposed to the outside is defined, and the interface information exposed to the outside may include, but is not limited to, class, interface, or package. The object to be detected can be a certain Android project developed by a developer. And configuring the API of each internal module by the object to be detected by using a preset interface export rule.

In the embodiment of the present disclosure, since the interface export rule of the object to be detected is formulated according to an agreement, the interface export rule needs to be parsed by the rule parser, so that the interface export rule takes effect. The rule parser may convert the rule definition in plain text form into some custom data structure to provide a unified parsing logic for the local interface detection module and the external interface detection module. Correspondingly, the rule content generation rule parser for deriving the rule according to the interface may be: and generating a matched rule resolver according to the file format, the file position, the DSL definition and other rule contents related in the interface export rule.

For example, in order to simplify the configuration of the interface export rule to the utmost and consider readability and non-invasiveness of the original Module configuration, the interface export rule of each Module may be configured in the following manner:

the "file format" interface export rule configuration file is a plain text file, and is named: module. export;

the 'file position' is the position of the configuration file of the interface export rule under the root directory of the Module which needs to configure the interface export rule;

the "DSL definition" interface export rule profile includes limited DSL identifiers, such as: module, modulePackage, export Ex, export.

Wherein the identifier Module can declare the current Module identity. For example, the configuration information of the identifier module is: module (": app: features: resource-fetcher") indicates that the current Module name is app: features: resource-fetcher. The identifier modulePackage is used to declare the packet name of the current Module. The identifier export is used to declare the specific definition to be derived. Specifically, if the configuration information of the identifier export is: an export (export type: String, targetOrPattern: String), when export type ═ class, it means that class named targetOrPattern is explicitly derived; when exportType is interface, it means that interface named targetOrPattern is explicitly derived; when exportType is equal to package, it indicates that the package named targetorpottern is explicitly derived, and wildcards may be specified to match the rules, for example: ", indicates a match for the non-recursive current package layer only; "x", indicates recursive matching. The identifier exportEx can explicitly derive a certain package and declare the items that need to be excluded. The identifier exclude exists in the identifier exportEx, and can declare items that the exportEx does not need to export. For example, assume that the configuration information of identifier exportEx is:

exportEx("package","com.example.push.thread2.**",{

exclude("class","com.example.push.thread2.util.CachedThreadPool")

exclude("interface","com.example.push.thread2.util.ICachedThreadPool")})

the meaning of the above configuration information is: the two class/interfaces under the package are explicitly removed, and the rest of interface information can be derived.

Therefore, by the method, different interface information export rules can be defined for different modules in the Android project. In a specific example, it is assumed that Module a and Module B exist in the Android project, and Module B is Module a dependent. Module. export configuration information in Module A is:

module(":app:business:A")；

modulePackage("com.ss.abc.a")；

export("class","com.ss.abc.a.Abaseutils")；

export("interface","com.ss.abc.a.package_mn.IHelper")；

it can be seen that Module a only exposes two pieces of interface information, namely, import com.s.abc.a.abaseutils and import com.s.abc.a.package _ mn.ihelper, to the outside, and any calling behavior using the other interfaces cannot pass the check of the interface detection tool. Therefore, when the development of the service logic is performed in the Module B, only two interface information of the Module a, i.e., the interface com.ss.abc.a.abaseutils and the interface com.ss.abc.a.package _ mn.ihelper, can be used, so as to achieve the purpose of controlling the interface boundary of the Module.

And S120, generating a local interface detection plug-in according to the rule parser and the first preset plug-in.

In an optional embodiment of the present disclosure, the local interface inspection plug-in is configured to perform local inspection on the API of the object to be inspected, and generate a local test object. The first preset insert may include: an IDE (Integrated development Environment) plug-in. The IDE plug-in is also an IDE interface check plug-in, a pointer checks the interface of the IntelliJ Idea platform, and the IntelliJ Idea platform is a basic platform of the Android Studio and is compatible with the Android Studio. The first interface detection requirement may be a requirement for implementing interface detection using an IDE plug-in, such as determining an interaction event and an error message prompting manner.

In the embodiment of the disclosure, the IDE plug-in may be developed secondarily according to the first interface detection requirement and the rule resolver. The so-called secondary development, namely, the customized modification and the extension of functions are carried out on the existing software, and then the functions required by the user are achieved, and generally, the kernel of the original system is not changed. In the embodiment of the present disclosure, the secondary development is that customized modification, function extension, and the like are performed on the basis of the existing Android-related development software. Correspondingly, the IDE plug-in is developed secondarily according to the rule resolver, and mainly the resolution logic of the rule resolver is multiplexed. The local interface detection plug-in generated by carrying out secondary development on the first preset plug-in can be used for carrying out local detection on the API of the object to be detected and generating a local test object. The local test object may be Push view, that is, the developer local code is tested well. The local test object can be submitted to the external interface test plug-in to continue testing.

And S130, generating an external interface detection plug-in according to the rule parser and the second preset plug-in.

In an optional embodiment of the present disclosure, the external interface detection plug-in is configured to perform external detection on an API of the local test object to generate a target detection result, and the second preset plug-in may include: CI (continuousnetention) plug-ins. The CI plug-in is also a CI interface check plug-in, and is an interface check tool for a Jenkins CI construction environment, and the incorporation of codes can be strictly controlled. The second interface detection requirement can realize the requirement of interface detection by using a CI plug-in, such as determining an interaction form, generating a text retrieval engine, and prompting an error message.

In the embodiment of the disclosure, the CI plugin may be developed secondarily according to the second interface detection requirement and the rule parser. And carrying out secondary development on the CI plug-in according to the rule parser, wherein the secondary development is mainly used for multiplexing the parsing logic of the rule parser. The external interface detection plug-in generated by carrying out secondary development on the second preset plug-in can be used for carrying out external detection on the API of the local test object, so that a final target detection result is generated. Specifically, the Push view can be used as a local test object and submitted to an external interface detection plug-in for external detection, the code can be incorporated into the object to be detected after the detection is passed, and the code can be rejected from being incorporated into the object to be detected if the detection is not passed. Therefore, the dual detection of the object to be detected is carried out through the two interface detection tools of the local interface detection plug-in and the external interface detection plug-in, and the interface export rule of the Module can be completely limited.

In the interface detection method, the interface rule of the object to be detected is simple and non-invasive to configure, configuration is convenient, and the IDE plug-in is more convenient to use as the local interface detection plug-in. And meanwhile, the method is deployed to a CI environment, and can effectively control the interface export rules of different modules in the engineering, so that the problems of influence on compilation progress, high reconstruction cost, reduction in Module convergence, large configuration intrusion, influence on semantization and the like of the conventional method for processing the interface boundary of the Android engineering Module are solved.

Fig. 3a is a flowchart of an interface detection tool generation method provided in an embodiment of the present disclosure, and in this embodiment, a specific implementation manner of generating a rule parser according to rule content of an interface export rule and generating a local interface detection plug-in according to the rule parser and a first preset plug-in is given. Accordingly, as shown in fig. 3a, the method of the present embodiment may include:

s210, generating a rule resolver according to the rule content of the interface export rule, wherein the rule resolver is used for resolving the acquired interface export rule of the object to be detected; the object to be detected is developed based on an Android system.

Accordingly, S210 may specifically include the following operations:

s211, defining a rule structure according to the interface export rule; the rule structure body is used for bearing and analyzing the interface export rule of the object to be detected to obtain a rule result set.

The rule structure may be configured to carry a rule result set obtained by analyzing an interface export rule of an object to be detected, that is, the rule structure is mainly configured to carry a rule result set defined in a configuration file corresponding to the interface export rule in a text format. The rule structure may include a plurality of fields, for example, a module field may be used to represent a parsed module ("xxx") definition, an exportClazz field may be used to represent a list of interfaces from which the module may be exported, and so on. Whose individual fields match the definitions of the fields in the interface export rule.

S212, generating a regular analysis logic; and the regular analysis logic is used for performing text pattern matching on the interface export rule of the object to be detected to obtain the rule structure definition of each module.

And the rule structure body can bear a rule result set obtained by analyzing the interface export rule. And the regular analysis logic is used for analyzing the interface derivation rule. Specifically, the regular parsing logic may perform text pattern matching on the configuration file corresponding to the interface export rule by using a regular expression, so as to parse the rule structure definition of each Module.

It should be noted that the regular parsing logic can be multiplexed in the local interface detection plug-in and the external interface detection plug-in at the same time, and therefore, method functions related in the regular parsing logic can be designed in a generic way to implement processing for File objects of an IDE platform, and can also process File objects of a JVM level required by a CI environment.

In a specific example, the parsing process corresponding to the rule parser may be: reading file objects in the configuration file inputresults list corresponding to the imported interface export rules one by one, and analyzing the content of a specific character string level; establishing an ExportRuleStruct instance of a rule structure body; matching module and module Packages rules by regular mode, and writing into ExportRuleStruct instance; further analyzing an export rule, an export Ex rule and an export rule through the regular rule, and writing the rules into an export RuleStruct instance; and (5) adding the rule result set result queue and finally returning the rule result.

S220, carrying out secondary development on the first preset plug-in according to the first interface detection requirement and the rule resolver to generate a local interface detection plug-in, wherein the local interface detection plug-in is used for carrying out local detection on the API of the object to be detected to generate a local test object.

Optionally, the first preset plug-in may be an IDE plug-in, and accordingly, S220 may specifically include the following operations:

s221, determining a basic interaction form of a basic interaction event of the local interface detection plug-in and a local error information prompt form.

In an optional embodiment of the present disclosure, the basic interaction event may include: and opening the object to be detected, triggering a pull-down menu and triggering at least one of file change.

Because the IDE plug-in is directly oriented to the developer, in order to enable the developer to perform interface detection when the development is completed, three trigger scenarios of interface detection can be considered: 1. opening a project to finish the start rule check when the project is synchronous; providing a special pull-down menu through a plug-in to actively trigger interface detection; in the process of editing the file, the detection of the interface is triggered by monitoring the change of the file.

In the embodiment of the present disclosure, the local error information prompting form may include a pop-up box or a text file.

S222, generating a monitoring mode matched with each basic interactive mode.

After determining the basic interaction form of the basic interaction event of the local interface detection plug-in, the method can be specifically implemented for the trigger condition of each basic interaction event. It will be appreciated that different trigger conditions may need to be implemented using different snooping means.

For a basic interaction event for opening an object to be detected, monitoring when the object to be detected is opened, that is, monitoring when a project is opened, needs to be realized. Fig. 3b is a schematic view of monitoring when the engineering is opened according to an embodiment of the present disclosure. Specifically, as shown in fig. 3b, the project component provided by the IntelliJ Idea platform calls the project open function to check the trigger opportunity. The project open function requires that some logic be defined in advance that needs to be executed when the project is opened.

Listening needs to be done in several steps for the basic interaction event that triggers the pull down menu. Drop-down menus are represented in the form of drop-down lists that appear in the top level menus of the IDE when the IDE obtains focus, And may include menu items such as Sync Rules/Check, Run Check, Check And Save, Enable Open Check, And Show Version. The following is a detailed description taking the menu item of "Run Check" as an example:

(1) registering Action: each item in the menu needs to be registered, and only the declaration needs to be made in the plugin.

(2) And (3) realizing a specific Action class: the implementation class of each Action needs to be inherited from the AnAction class provided by the IntelliJ IDEA platform. Fig. 3c is a schematic diagram of trigger logic corresponding to a click Action provided in the embodiment of the present disclosure, and as shown in fig. 3c, when a specific Action is clicked, the callback method of "actionPerformed" corresponding to the Action is triggered, so that specific logic of the Action can be completed.

Aiming at the basic interaction event triggering the file change, the real-time change monitoring function of the file can be started when the current file is edited. For example, a listener listening to changes in the content of the project file may be registered at project open time to trigger listening of basic interaction events for file changes by the listener. It should be noted that, in practical applications, detecting a file change in real time is not good for the engineering experience during development, and may interfere with a developer, so the monitoring function of the basic interaction event of the file change may not be selected to be opened to the developer.

And S223, generating a first core detection logic of the local interface detection plug-in according to the rule resolver.

The first core detection logic may be a core detection logic corresponding to the local interface detection plug-in.

In an optional embodiment of the disclosure, the first core detection logic to generate the local interface detection plug-in according to the rule parser may include: monitoring each basic interaction event of the object to be detected according to the monitoring mode matched with the basic interaction event; after the basic interaction event is determined to be triggered, searching a configuration file of an interface export rule of the object to be detected; reading and analyzing the configuration file of the searched interface export rule according to the rule analyzer to generate a local rule result set; generating a local blacklist list of each module in the object to be detected according to the local rule result set; scanning the object to be detected according to the local blacklist list, and adding the scanned error calling API into a local scanning interface set; and if the local scanning interface set is determined not to be empty, adopting the error information prompting mode to perform error prompting.

The basic interaction event can be an interaction event detected by a trigger interface set by a local interface detection plug-in, and different basic interaction events correspond to different basic interaction forms. The set of local scan interfaces may be a set for storing locally detected error call APIs.

In the use of the local interface detection plug-in, a developer mainly triggers the use of the local interface detection plug-in through two scenes of 'project opening time' and 'pull-down menu triggering'. The basic checking logic for both scenarios is similar, described with "when project is open" as an exemplary trigger condition. Namely: when the condition that a developer opens a project is met, the detection flow is started to be executed. Fig. 3d is a schematic diagram of a first core detection logic according to an embodiment of the disclosure. The detection logic "when project is open" is described below in connection with FIG. 3 d.

After the developer opens the project (i.e., the object to be detected), the indexing begins. Monitoring each basic interaction event of the object to be detected, which may specifically be: and realizing the monitoring of the IDE index. Under the IntelliJ IDEA platform, when a developer opens a project, the developer often needs to wait for the codes in the project to synchronize and index. The developer can start further development or debugging after this process has started. The developer of the native interface detection plug-in needs to rely on the infrastructure provided by the platform to perform this listening. Similarly, the two trigger events of "pull-down menu" and "file change" can also be monitored in a matched monitoring mode.

After determining that the basic interaction event is triggered, searching for a configuration file of an interface export rule of the object to be detected may specifically be: the configuration file of the interface export rule (i.e. module. export rule file in fig. 3 d) in the whole project is scanned by the local interface detection plug-in.

The rule parser reads and parses the configuration file of the found interface export rule to generate a local rule result set, which may specifically be: the content of the configuration file of the interface export rules is read one by the rule parser and the configuration of the rules is parsed, generating a local rule result set (i.e. the rule set in fig. 3 d). The local rule result set may be a Map data structure with Key as the current module and Value as the interface export rule definition for this module.

Generating a local blacklist list of each module in the object to be detected according to the local rule result set, which may specifically be: and generating a local blacklist WrongList corresponding to each Module according to the local rule result set. The local blacklist mainly refers to: for a Module existing in the project, a list of interface information that the Module cannot export. Optionally, a local blacklist may be stored by the variable Map data structure for checking against each Module. The Key Value of the variable Map data structure is the current Module name, and the Value is the list of interface information that cannot be exposed in the Module.

Scanning the object to be detected according to the local blacklist list, and adding the scanned error call API to the local scanning interface set, which may specifically be: and starting to carry out full-scale inspection on the whole project according to the generated local blacklist. Namely: and searching the appearance position of each interface C in the local blacklist list in each Module X in the whole project. If interface C appears in other modules than ModuleX, it needs to be put into the local scan interface set, which represents that the interface export rule is not met. It should be noted that the local scan interface set may directly adopt a local rule result set, or may be a new result set created independently, which is not limited by the embodiment of the present disclosure.

If it is determined that the local scanning interface set is not empty, performing error prompt by using the error information prompt mode, which may specifically be: and if the local scanning interface set is determined not to be empty, showing specific error information in a form of Popup and the like.

And S224, generating a local error information prompting mode matched with each local error information prompting mode.

In an optional embodiment of the present disclosure, the error information prompting manner may include: displaying error information by a self-defined pop-up box; and outputting the error information as a text file with a set name.

The implementation manner of displaying the error information by the user-defined pop-up box specifically may be: after taking a set of scan interfaces that do not comply with the interface export rules, the developer is prompted by the IDE plugin's own Popup. The method comprises the following steps: and traversing the elements included in the scanning interface set one by one, splicing, and generating final error information. After popping up the custom pop-up box, some class names may be involved in the custom pop-up box. In order to facilitate the developer to quickly locate the problem, the function of clicking the class name to jump to the specific class file (namely, keyword jump) can be realized. The implementation of this function can be done using a mechanism similar to event binding. Finally, a Popup Popup box needs to be displayed, and the Popup Popup box can be realized by using a Notification tool provided by the intelliJ IDEA platform.

The output of the error information as the text file with the set name may be: through the function of 'Check And Save' in menu options of the IDE plug-in, the operation of exporting the interface to the file after the detection of the interface is finished can be realized. The setting name may be set according to actual requirements, and the embodiment of the present disclosure does not limit this. For example, the set name of the text file containing the error information may be in the form of "result _ [ [ DATE _ TIME ] ]. txt", so as to distinguish the interface detection results at different TIME points and be accurate to seconds. The error information prompting mode of outputting the error information as the text file with the set name is suitable for the condition that the Popup display is incomplete due to too many errors.

And S230, carrying out secondary development on a second preset plug-in according to a second interface detection requirement and the rule resolver to generate an external interface detection plug-in, wherein the external interface detection plug-in is used for carrying out external detection on the API of the local test object to generate a target detection result.

By adopting the technical scheme, the monitoring mode matched with each basic interaction mode is generated by determining the basic interaction mode and the local error information prompting mode of the basic interaction event of the local interface detection plug-in, the first core detection logic of the local interface detection plug-in is generated according to the rule parser, and the local error information prompting mode matched with each local error information prompting mode is generated, so that the local interface detection plug-in can be generated, and the API of the object to be detected is locally detected through the local interface detection plug-in.

Fig. 4a is a flowchart of a method for generating an interface detection tool according to an embodiment of the present disclosure, and in this embodiment, a specific implementation manner of generating an external interface detection plug-in according to the rule parser and a second preset plug-in is given. Accordingly, as shown in fig. 4a, the method of the present embodiment may include:

s310, generating a rule resolver according to the rule content of the interface export rule, wherein the rule resolver is used for resolving the acquired interface export rule of the object to be detected; the object to be detected is developed based on an Android system.

S320, generating a local interface detection plug-in according to the rule parser and the first preset plug-in, wherein the local interface detection plug-in is used for carrying out local detection on the API of the object to be detected and generating a local test object.

S330, generating an external interface detection plug-in according to the rule parser and a second preset plug-in, wherein the external interface detection plug-in is used for carrying out external detection on the API of the local test object and generating a target detection result.

Jenkins is an open-source CI tool providing a friendly operation interface, and is mainly used for continuously and automatically building/testing software projects and monitoring the running of external tasks. Task (Job) is an execution plan of Jenkins, is a collection of a series of operations, and is constructed as one run of Jenkins' task. Gerrit is an open source code inspection software, using a web interface. Using a web browser, software developers from the same team can review each other's modified code to determine whether they can submit, rollback, or continue to modify. For example: automatic/manual review of code is accomplished by operations of +/-1. The code of-1 is not deliverable into the branch. In the embodiment of the disclosure, the external interface detection plug-in can be developed for the second time on the basis of the CI plug-in to form an interface detection tool in the CLI form. Therefore, the detection principle of the external interface detection plug-in the embodiment of the present disclosure may be: the developer, after submitting the local test object, may trigger logic to run interface detection on the external device. If the code of the local test object does not conform to the interface export rule, executing a-1 operation of the code Review, thereby strictly controlling the destruction of the interface export rule.

It will be appreciated that after the detection is completed by the local interface detection plug-in, no hard limit on interface detection can be completed. Therefore, in order to avoid the code entry development branch of the interface export rule, a tool for integrating the same detection rule in the construction task of submitting the code to Review by a developer is required to perform hard limitation. That is, the external interface detection plug-in detects that once finding that the code which is not in accordance with the specification is submitted, the external interface detection plug-in executes the operation of Gerrit-1, and does not allow the code to be merged in so as to prevent the interface boundary of the module from being damaged. That is, only by combining the detection of the local interface detection plug-in and the external interface detection plug-in, the "hard limit" for the module interface boundary check can be completed. The CLI interface detection and the IDE interface detection are complementary to each other and form an interface detection tool as a whole.

Correspondingly, S330 may specifically include the following operations:

s331, determining the interactive form of the external interface detection plug-in.

In an optional embodiment of the present disclosure, the determining the interaction form of the external interface detection plug-in may include: determining a trigger event of the external interface detection plug-in; and determining the calling mode of the external interface detection plug-in.

Specifically, after the developer submits the local test object, the logic for running the interface detection may be triggered on the external device through a submit Hook (Hook function) of Gerrit + Jenkins. Because the CLI detection tool constructs a final target detection result through the fatJar package, the CLI detection tool can be called in a command parser shell mode when determining a trigger event of the external interface detection plug-in.

And S332, multiplexing the rule parsing logic of the rule parser.

In embodiments of the present disclosure, the external interface detection plug-in may reuse the rule parsing logic of the rule parser. That is, the external interface detection plug-in and the local interface detection plug-in multiplex the same configuration file of the interface export rule and the rule parsing logic, so that the logic of the external interface detection plug-in and the logic of the local interface detection plug-in are consistent. In particular, the rule parsing logic may be implemented as a basic module.

Fig. 4b is a schematic diagram illustrating an effect of implementing the rule parsing logic by a module according to an embodiment of the present disclosure. For example, as shown in fig. 4b, the logic of profile parsing of the interface export rule may be placed in a module "baseComponents", a "checkerCiJar" module is an implementation module of the external interface detection plug-in, and a "checkerIde" module is an implementation module of the local interface detection plug-in. Both the "checkerCiJar" module and the "checkerIde" module rely on the "baseComponents" module.

And S333, generating a text retrieval engine.

The external interface detection plug-in is different from the local interface detection plug-in, and the logic of the local interface detection plug-in detection depends on IDEA (Intelligent J IDEA, an integrated environment for java language development) plug-in development environment and depends on specific objects and mechanisms under various IDEA platforms. For example: abstraction of PsiClass, referenceSearch search encapsulation and indexing mechanism, and the like. These mechanisms provide great convenience for the implementation of the native interface detection plug-in. However, the external interface detection plug-in does not have the support of the environments, so that the original text retrieval mechanism is required to traverse the code in a specific source file in the whole project for detection. In fact, whether the native interface detects the implementation of a plug-in or the external interface detects the implementation of a plug-in, the core function is to "retrieve" the blacklist.

In the embodiment of the disclosure, a ripcrep tool can be introduced into an external detection environment to realize a quick text retrieval function of an external interface detection plug-in. ripcrep can be installed as a running environment on a compiler that performs interface detection, embodied in the form of an executable binary file. The reason for choosing ripcrep is: ripcrep builds on the regex engine of Rust, and many optimized features of the regex engine of Rust make the search very fast. ripcrep supports incremental searching using memory mapping or through intermediate buffers. The memory mapping is more suitable for searching a single file, the incremental searching through the intermediate buffer area is more suitable for searching a large directory, and ripcrep can automatically select the optimal searching strategy. Meanwhile, ripcrep uses a lock-free parallel recursive directory iterator for retrieval and automatically ignores the ignore term defined in the gitignore document.

Correspondingly, on the final realization of the text retrieval engine, the search engine can realize the quick retrieval function of the specific mode text in the engineering by packaging the SearchEngineProvider class.

And S334, generating a second core detection logic of the external interface detection plug-in according to the rule resolver.

The second core detection logic may be a core detection logic corresponding to the external interface detection plug-in.

In an optional embodiment of the disclosure, the second core detection logic to generate the external interface detection plug-in according to the rule parser may include: searching a configuration file of an interface export rule of the object to be detected according to the text retrieval engine; reading and analyzing the configuration file of the searched interface export rule according to a rule analyzer to generate an external rule result set; generating an external blacklist list of each module in the object to be detected according to the external rule result set; scanning the object to be detected according to the external blacklist list, and adding the scanned error calling API into an external scanning interface set; and if the external scanning interface set is determined not to be empty, adopting the error information prompting mode to perform error prompting, interrupting the current detection operation, and returning a command of refusing code entry.

The second core detection logic of the external interface detection plug-in is similar to the first core detection logic of the local interface detection plug-in, and in summary, the detection logic is links such as rule searching, rule analysis, blacklist generation, scanning engineering, prompt giving and the like. Fig. 4c is a schematic diagram of a second core detection logic provided in an embodiment of the disclosure, and the second core detection logic is described below with reference to fig. 4 c.

After the developer submits the code (i.e., the local test object) to the external interface detection plug-in, the external interface detection plug-in begins to search the project (i.e., the local test object) by using the text search engine. Fig. 4d is a schematic diagram of a configuration file for searching for an interface export rule provided in the embodiment of the present disclosure, and referring to fig. 4d, the configuration file for searching for an interface export rule of the object to be detected according to the text search engine may specifically be: the configuration file of the interface export rule is found through an ExportRuleFinder, and the ExportRuleFinder completes the retrieval of a specific file through a searchEngineProvider in implementation.

The rule parser reads and parses the configuration file of the found interface export rule to generate an external rule result set, which may specifically be: the rule parser reads the contents of the configuration file of the interface export rule one by one and parses the configuration of the rule, generating an external rule result set (i.e. the rule set in fig. 4 c). The external rule result set may be a Map data structure with Key as the current module and Value as the interface export rule definition for this module.

Generating an external blacklist list of each module in the object to be detected according to the external rule result set, which may specifically be: the external rule result set is parsed by a modulelazpoilprovider method, a source file in each Module is retrieved, and an external blacklist (i.e., the blacklist wrongList in fig. 4 c) corresponding to each Module is generated by a corresponding export rule. The external blacklist mainly refers to: for a Module existing in a local test object, a list of interface information that the Module cannot export. Optionally, an external blacklist may also be stored by the variable Map data structure for checking against each Module. The Key Value of the variable Map data structure is the current Module name, and the Value is the list of interface information that cannot be exposed in the Module.

Scanning the object to be detected according to the external blacklist list, and adding the scanned error call API to an external scanning interface set, which may specifically be: and scanning the whole local test object according to the information of the external blacklist and aiming at each interface information in the external blacklist. Namely: and searching the appearance position of each interface D in the external blacklist list in each Module Y in the whole project. If interface D appears in other modules than ModuleY, it needs to be put into the external scanning interface set, which represents that the interface does not conform to the interface export rule. It should be noted that the external scan interface set may directly adopt an external rule result set, or may be a new result set created independently, which is not limited by the embodiment of the present disclosure.

If it is determined that the external scanning interface set is not empty, performing error prompt in the error information prompt mode, interrupting the current detection operation, and returning a command of rejecting code entry, which may specifically be: and if the external scanning interface set is determined not to be empty, displaying specific error information in a text form according to the external scanning interface set. Meanwhile, the execution of the detection task can be interrupted to interrupt the current detection operation (Job), and the rejection of code incorporation is completed through Gerrit, namely, the operation of-1 is executed to return an instruction for rejecting code incorporation. If the external scanning interface set is determined to be empty, it indicates that through detection, the permission of code entry can be completed through Gerrit, i.e. the operation of +1 is performed.

And S335, generating an output mode of the external error information.

In an optional embodiment of the present disclosure, the output manner of the external error information includes: and (4) a text output mode.

In the detection process of the external interface detection plug-in, once the Jenkins task detection interface has an out-of-specification use condition, the following external error information in the text form is output in a console of the interface detection task:

Module Exports Runner:[Debug:true]

1:In Module':app:features:xxx1',[[com.xxx.ICalendarMap]]has beendeclared as[Private]

But exist in Module':app:features:xxx5':[[com.xxx.CalendarMap]]

2:In Module':app:features:xxx2',[[com.xxx.ICalendarUtil]]has beendeclared as[Private]

But exist in Module':app:features:xxx5':[[com.xxx.CalendarMap]]

-------------------------

Module Exports Runner:[Debug:true]Check End

exception in thread "main" java. lan. Exception, please ensure before code is committed if the "module export configuration" is configured and used successfully! Please have to check with Android Studio plug-in!

The external error information can be output through the standard of a command line tool to prompt, and can be directly displayed in the journal of Jenkins Job, so that a developer can find errors in time. The output of the external error message may be encapsulated with the NoticeProvider.

By adopting the technical scheme, the external interface detection plug-in can be generated by determining the interaction form of the external interface detection plug-in, multiplexing the rule analysis logic of the rule analyzer, generating a text retrieval engine, generating the second core detection logic of the external interface detection plug-in according to the rule analyzer and generating the output mode of the external error information, so that the external detection can be continuously carried out on the API included in the local test object correspondingly generated by the object to be detected through the external interface detection plug-in.

It should be noted that any permutation and combination between the technical features in the above embodiments also belong to the scope of the present disclosure.

Fig. 5a is a flowchart of an interface detection method provided in an embodiment of the present disclosure, where the embodiment is applicable to a case of detecting an interface of an Android engineering module, and the method may be executed by an interface detection device, where the interface detection device may be implemented in a software and/or hardware manner, and may generally be integrated in an electronic device. The electronic device may be a terminal device, may include a notebook computer and the like, or may also be a server. Accordingly, as shown in fig. 5a, the method comprises the following operations:

s410, obtaining an object to be detected; and the object to be detected is configured with an interface export rule aiming at the API of each module.

In the embodiment of the disclosure, the object to be detected may be developed based on an Android system, and interface export rules are configured for the APIs of the modules. That is, the object to be detected configures the API of each internal module using the predetermined interface export rule.

S420, carrying out local detection on the API of the object to be detected through the local interface detection plug-in to generate a local test object.

S430, carrying out external detection on the API of the local test object through the external interface detection plug-in, and generating a target detection result.

Fig. 5b is a flowchart of interface detection provided in an embodiment of the present disclosure. In a specific example, as shown in fig. 5b, when a developer finishes developing a certain function to generate an object to be detected, the local interface detection plug-in described in any of the above embodiments needs to be used to perform first module interface boundary detection. And each Module in the object to be detected is configured with an explicit interface export rule. If the local interface detection plug-in (i.e. the IDE plug-in fig. 5 b) passes the detection, the Push Review can be submitted as the local test object, and any of the external interface detection plug-ins (i.e. the Jenkins CI plug-in fig. 5 b) in the above embodiments is used to perform the second detection on the API of the local test object. When the second detection is passed, the +1 can be executed as the target detection result, and the code of the local test object can be imported. If the Push Review is not forcibly submitted through the detection of the local interface detection plug-in, the external interface detection plug-in detects an error during the second detection and executes-1 as a target detection result, and the code of the local test object cannot be merged into a branch. The interface export rules of the Module can be completely restricted by the above mentioned local and external checks.

According to the method and the device, the acquired API of the object to be detected is locally detected by using the local interface detection plug-in to generate the local test object, the external detection plug-in is used for externally detecting the API of the local test object to generate the target detection result, the problems that the existing Android engineering module interface boundary processing method is influenced in compiling progress, high in reconstruction cost, low in module convergence, large in configuration intrusion, influenced in semantization and the like can be solved, the interface of the Android engineering module is detected on the premise that the Android engineering module is not reconstructed, and therefore interface export rules of different modules are controlled.

Fig. 6 is a schematic diagram of an interface detection tool generation apparatus provided in an embodiment of the present disclosure, and as shown in fig. 6, the apparatus includes: a rule parser generation module 510, a local interface detection plug-in generation module 520, and an external interface detection plug-in generation module 530, wherein:

a rule parser generation module 510, configured to generate a rule parser according to rule content of the interface export rule;

a local interface detection plug-in generation module 520, configured to generate a local interface detection plug-in according to the rule parser and the first preset plug-in;

and an external interface detection plug-in generation module 530, configured to generate an external interface detection plug-in according to the rule parser and a second preset plug-in.

Optionally, the rule parser is configured to parse the obtained interface export rule of the object to be detected; a rule parser generation module 510, comprising: a rule structure defining unit for deriving a rule structure according to the interface; the rule structure body is used for bearing and analyzing the interface export rule of the object to be detected to obtain a rule result set; the regular analysis logic generation unit is used for generating regular analysis logic; and the regular analysis logic is used for performing text pattern matching on the interface export rule of the object to be detected to obtain the rule structure definition of each module.

Optionally, the local interface inspection plug-in is configured to perform local inspection on an application program interface API of an object to be inspected, and generate a local test object; the local interface detection plug-in generation module 520 includes: the first form information determining unit is used for determining a basic interaction form and a local error information prompting form of a basic interaction event of the local interface detection plug-in; a monitoring mode generating unit, configured to generate a monitoring mode matched with each basic interaction mode; the first core detection logic generation unit is used for generating the first core detection logic of the local interface detection plug-in according to the rule resolver; and the local error information prompting mode prompting unit is used for generating a local error information prompting mode matched with each local error information prompting mode.

Optionally, the basic interaction event includes: opening the object to be detected; triggering a pull-down menu; triggering file change; the first core detection logic generation unit is specifically configured to search a configuration file of an interface export rule of the object to be detected after it is determined that the basic interaction event is triggered; reading and analyzing the configuration file of the searched interface export rule according to the rule analyzer to generate a local rule result set; generating a local blacklist list of each module in the object to be detected according to the local rule result set; and scanning the object to be detected according to the local blacklist list, and adding the scanned error calling API into a local scanning interface set.

Optionally, the first core detection logic generating unit is specifically configured to monitor each basic interaction event of the object to be detected according to a monitoring mode matched with the basic interaction event; if the local scanning interface set is determined not to be empty, adopting the error information prompting mode to perform error prompting; the error information prompting mode comprises the following steps: displaying error information by a self-defined pop-up box; and outputting the error information as a text file with a set name.

Optionally, the external interface detection plug-in is configured to perform external detection on an API of a local test object, so as to generate a target detection result; an external interface detection plug-in generation module 530, comprising: the second form information determining unit is used for determining the interactive form of the external interface detection plug-in; the rule analysis logic multiplexing unit is used for multiplexing the rule analysis logic of the rule analyzer; the text search engine generating unit is used for generating a text search engine; the second core detection logic generation unit is used for generating second core detection logic of the external interface detection plug-in according to the rule parser; and the external error information generating unit is used for generating an output mode of the external error information.

Optionally, the second form information determining unit is specifically configured to determine a trigger event of the external interface detection plug-in; and determining the calling mode of the external interface detection plug-in.

Optionally, the second core detection logic generating unit is specifically configured to search, according to the text search engine, a configuration file of an interface export rule of the object to be detected; reading and analyzing the configuration file of the searched interface export rule according to a rule analyzer to generate an external rule result set; generating an external blacklist list of each module in the object to be detected according to the external rule result set; and scanning the object to be detected according to the external blacklist list, and adding the scanned error calling API into an external scanning interface set.

Optionally, the second core detection logic generating unit is specifically configured to, if it is determined that the external scanning interface set is not empty, perform error prompt in the error information prompt manner, interrupt current detection operation, and return an instruction to reject code entry; the output mode of the external error information comprises the following steps: and (4) a text output mode.

Optionally, the object to be detected is configured with an interface export rule for the API of each module; the first preset insert includes: an IDE plug-in; the second preset insert comprises: and (4) a CI plug-in.

The interface detection tool generation device can execute the interface detection tool generation method provided by any embodiment of the disclosure, and has corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in this embodiment, reference may be made to a method for generating an interface detection tool provided in any embodiment of the present disclosure.

Fig. 7 is a schematic diagram of an interface detection apparatus provided in an embodiment of the present disclosure, and as shown in fig. 7, the apparatus includes: an object to be detected acquisition module 610, a local detection module 620 and an external detection module 630, wherein:

an object to be detected acquisition module 610, configured to acquire an object to be detected; the object to be detected is configured with an interface export rule aiming at the API of each module;

the local detection module 620 is configured to perform local detection on the API of the object to be detected through the local interface inspection plug-in, so as to generate a local test object;

and the external detection module 630 is configured to perform external detection on the API of the local test object through the external interface detection plug-in, so as to generate a target detection result.

The interface detection device can execute the interface detection method provided by any embodiment of the disclosure, and has corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in this embodiment, reference may be made to an interface detection method provided in any embodiment of the present disclosure.

Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. Referring now to fig. 8, a schematic diagram of an electronic device (e.g., a terminal device or server) 700 suitable for use in implementing embodiments of the present disclosure is shown. The terminal device in the embodiments of the present disclosure may include, but is not limited to, a mobile terminal such as a mobile phone, a notebook computer, a digital broadcast receiver, a PDA (personal digital assistant), a PAD (tablet computer), a PMP (portable multimedia player), a vehicle terminal (e.g., a car navigation terminal), and the like, and a stationary terminal such as a digital TV, a desktop computer, and the like. The electronic device shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 8, electronic device 700 may include a processing means (e.g., central processing unit, graphics processor, etc.) 701 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)702 or a program loaded from storage 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data necessary for the operation of the electronic apparatus 700 are also stored. The processing device 701, the ROM 702, and the RAM 703 are connected to each other by a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

Generally, the following devices may be connected to the I/O interface 705: input devices 706 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; an output device 707 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 708 including, for example, magnetic tape, hard disk, etc.; and a communication device 709. The communication means 709 may allow the electronic device 700 to communicate wirelessly or by wire with other devices to exchange data. While fig. 8 illustrates an electronic device 700 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program containing program code for performing the method illustrated by the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via the communication means 709, or may be installed from the storage means 708, or may be installed from the ROM 702. The computer program, when executed by the processing device 701, performs the above-described functions defined in the methods of the embodiments of the present disclosure.

It should be noted that the computer readable medium in the present disclosure can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having 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. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.

In some embodiments, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperText transfer protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communications network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed network.

The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device.

The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: generating a rule resolver according to rule content of the interface export rule; generating a local interface detection plug-in according to the rule parser and a first preset plug-in; and generating an external interface detection plug-in according to the rule parser and a second preset plug-in.

Alternatively, the computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: acquiring an object to be detected; the object to be detected is configured with an interface export rule aiming at the API of each module; performing local detection on the API of the object to be detected through a local interface detection plug-in to generate a local test object; and carrying out external detection on the API of the local test object through an external interface detection plug-in to generate a target detection result.

Computer program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including but not limited to an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present disclosure may be implemented by software or hardware. Where the name of a module does not in some cases constitute a limitation on the module itself, for example, a rule resolver generation module may also be described as a "module for generating rule resolvers".

The functions described herein above may 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: field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), systems on a chip (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.

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.

According to one or more embodiments of the present disclosure, the present disclosure provides an interface detection tool generation method, including:

According to one or more embodiments of the present disclosure, in the interface detection tool generation method provided by the present disclosure, the rule parser is configured to parse an obtained interface export rule of an object to be detected; the rule content generation rule parser for exporting rules according to the interface comprises the following steps:

defining a rule structure according to the interface export rule; the rule structure body is used for bearing and analyzing the interface export rule of the object to be detected to obtain a rule result set;

generating a regular parsing logic; and the regular analysis logic is used for performing text pattern matching on the interface export rule of the object to be detected to obtain the rule structure definition of each module.

According to one or more embodiments of the present disclosure, in the interface detection tool generation method provided by the present disclosure, the local interface inspection plug-in is configured to perform local detection on an application program interface API of an object to be detected, and generate a local test object; the generating of the local interface detection plug-in according to the rule parser and the first preset plug-in includes:

determining a basic interaction form and a local error information prompt form of a basic interaction event of the local interface detection plug-in;

generating a monitoring mode matched with each basic interactive mode;

generating a first core detection logic of the local interface detection plug-in according to the rule parser;

and generating a local error information prompting mode matched with each local error information prompting mode.

According to one or more embodiments of the present disclosure, in an interface detection tool generation method provided by the present disclosure, the generating, according to the rule parser, a first core detection logic of the local interface detection plug-in includes:

after the basic interaction event is determined to be triggered, searching a configuration file of an interface export rule of the object to be detected;

reading and analyzing the configuration file of the searched interface export rule according to the rule analyzer to generate a local rule result set;

generating a local blacklist list of each module in the object to be detected according to the local rule result set;

and scanning the object to be detected according to the local blacklist list, and adding the scanned error calling API into a local scanning interface set.

According to one or more embodiments of the present disclosure, in the interface detection tool generation method provided by the present disclosure, before determining that the basic interaction event is triggered, the method further includes:

monitoring each basic interaction event of the object to be detected according to the monitoring mode matched with the basic interaction event;

after the scanned error calling API is added into the local scanning interface set, the method further comprises the following steps:

and if the local scanning interface set is determined not to be empty, adopting the error information prompting mode to perform error prompting.

According to one or more embodiments of the present disclosure, in the interface detection tool generation method provided by the present disclosure, the external interface detection plug-in is used for performing external detection on an API of a local test object, and generating a target detection result; the generating of the external interface detection plug-in according to the rule parser and the second preset plug-in includes:

determining an interaction form of the external interface detection plug-in;

multiplexing rule parsing logic of the rule parser;

generating a text retrieval engine;

generating a second core detection logic of the external interface detection plug-in according to the rule parser;

and generating an output mode of the external error information.

According to one or more embodiments of the present disclosure, in an interface detection tool generation method provided by the present disclosure, the determining an interaction form of the external interface detection plug-in includes:

determining a trigger event of the external interface detection plug-in;

and determining the calling mode of the external interface detection plug-in.

According to one or more embodiments of the present disclosure, in an interface detection tool generation method provided by the present disclosure, the generating, according to the rule parser, a second core detection logic of the external interface detection plug-in includes:

searching a configuration file of an interface export rule of the object to be detected according to the text retrieval engine;

reading and analyzing the configuration file of the searched interface export rule according to a rule analyzer to generate an external rule result set;

generating an external blacklist list of each module in the object to be detected according to the external rule result set;

and scanning the object to be detected according to the external blacklist list, and adding the scanned error calling API into an external scanning interface set.

According to one or more embodiments of the present disclosure, in the interface detection tool generation method provided by the present disclosure, after adding the scanned error call API to the external scanning interface set, the method further includes:

and if the external scanning interface set is determined not to be empty, adopting the error information prompting mode to perform error prompting, interrupting the current detection operation, and returning a command of refusing code entry.

According to one or more embodiments of the present disclosure, there is provided an interface detection method including:

According to one or more embodiments of the present disclosure, there is provided an interface detection tool generation apparatus including:

According to one or more embodiments of the present disclosure, in an interface detection tool generation apparatus provided by the present disclosure, the rule parser is configured to parse an obtained interface export rule of an object to be detected; a rule parser generation module comprising: a rule structure defining unit for deriving a rule structure according to the interface; the rule structure body is used for bearing and analyzing the interface export rule of the object to be detected to obtain a rule result set; the regular analysis logic generation unit is used for generating regular analysis logic; and the regular analysis logic is used for performing text pattern matching on the interface export rule of the object to be detected to obtain the rule structure definition of each module.

According to one or more embodiments of the present disclosure, in an interface detection tool generation apparatus provided by the present disclosure, the local interface inspection plug-in is configured to perform local detection on an application program interface API of an object to be detected, and generate a local test object; the local interface detection plug-in generation module comprises: the first form information determining unit is used for determining a basic interaction form and a local error information prompting form of a basic interaction event of the local interface detection plug-in; a monitoring mode generating unit, configured to generate a monitoring mode matched with each basic interaction mode; the first core detection logic generation unit is used for generating the first core detection logic of the local interface detection plug-in according to the rule resolver; and the local error information prompting mode prompting unit is used for generating a local error information prompting mode matched with each local error information prompting mode.

According to one or more embodiments of the present disclosure, in an interface detection tool generation apparatus provided by the present disclosure, a first core detection logic generation unit is specifically configured to search a configuration file of an interface export rule of an object to be detected after determining that a basic interaction event is triggered; reading and analyzing the configuration file of the searched interface export rule according to the rule analyzer to generate a local rule result set; generating a local blacklist list of each module in the object to be detected according to the local rule result set; and scanning the object to be detected according to the local blacklist list, and adding the scanned error calling API into a local scanning interface set.

According to one or more embodiments of the present disclosure, in the interface detection tool generation apparatus provided by the present disclosure, the first core detection logic generation unit is specifically configured to monitor each basic interaction event of the object to be detected according to a monitoring mode matched with the basic interaction event; if the local scanning interface set is determined not to be empty, adopting the error information prompting mode to perform error prompting; the error information prompting mode comprises the following steps: displaying error information by a self-defined pop-up box; and outputting the error information as a text file with a set name.

According to one or more embodiments of the present disclosure, in an interface detection tool generation apparatus provided by the present disclosure, an external interface detection plug-in is used for performing external detection on an API of a local test object, and generating a target detection result; the external interface detects plug-in generating module, including: the second form information determining unit is used for determining the interactive form of the external interface detection plug-in; the rule analysis logic multiplexing unit is used for multiplexing the rule analysis logic of the rule analyzer; the text search engine generating unit is used for generating a text search engine; the second core detection logic generation unit is used for generating second core detection logic of the external interface detection plug-in according to the rule parser; and the external error information generating unit is used for generating an output mode of the external error information.

According to one or more embodiments of the present disclosure, in the interface detection tool generation apparatus provided by the present disclosure, the second form information determination unit is specifically configured to determine a trigger event of the external interface detection plug-in; and determining the calling mode of the external interface detection plug-in.

According to one or more embodiments of the present disclosure, in the interface detection tool generation apparatus provided by the present disclosure, the second core detection logic generation unit is specifically configured to search, according to the text search engine, a configuration file of an interface export rule of the object to be detected; reading and analyzing the configuration file of the searched interface export rule according to a rule analyzer to generate an external rule result set; generating an external blacklist list of each module in the object to be detected according to the external rule result set; and scanning the object to be detected according to the external blacklist list, and adding the scanned error calling API into an external scanning interface set.

According to one or more embodiments of the present disclosure, in the interface detection tool generation apparatus provided by the present disclosure, the second core detection logic generation unit is specifically configured to perform error prompt in the error information prompt manner, interrupt a current detection operation, and return an instruction to reject code entry if it is determined that the external scanning interface set is not empty; the output mode of the external error information comprises the following steps: and (4) a text output mode.

According to one or more embodiments of the present disclosure, in an interface detection tool generation apparatus provided by the present disclosure, an interface export rule is configured for an API of each module by an object to be detected; the first preset insert includes: an IDE plug-in; the second preset insert comprises: and (4) a CI plug-in.

According to one or more embodiments of the present disclosure, there is provided an interface detecting apparatus including:

Claims

1. An interface detection tool generation method, comprising:

2. The method according to claim 1, wherein the rule parser is configured to parse the obtained interface derivation rule of the object to be detected;

the rule content generation rule parser for exporting rules according to the interface comprises the following steps:

3. The method according to claim 1, wherein the local interface inspection plug-in is used for performing local inspection on an Application Program Interface (API) of an object to be inspected to generate a local test object;

the generating of the local interface detection plug-in according to the rule parser and the first preset plug-in includes:

generating a monitoring mode matched with each basic interactive mode;

4. The method of claim 3, wherein the first core detection logic that generates the local interface detection plug-in according to the rule parser comprises:

after determining that the basic interaction event is triggered, searching a configuration file of an interface export rule of the object to be detected;

5. The method of claim 4, prior to determining that the basic interaction event is triggered, further comprising:

6. The method of claim 1, wherein the external interface detection plug-in is configured to perform external detection on an API of a local test object to generate a target detection result;

the generating of the external interface detection plug-in according to the rule parser and the second preset plug-in includes:

determining an interaction form of the external interface detection plug-in;

multiplexing rule parsing logic of the rule parser;

generating a text retrieval engine;

and generating an output mode of the external error information.

7. The method of claim 6, wherein determining the interaction pattern of the external interface detection plug-in comprises:

determining a trigger event of the external interface detection plug-in;

and determining the calling mode of the external interface detection plug-in.

8. The method of claim 6, wherein the second core detection logic that generates the external interface detection plug-in according to the rule parser comprises:

9. The method of claim 8, after adding the scanned error call API to the external scanning interface set, further comprising:

10. An interface detection method, comprising:

11. An interface detection tool generation apparatus, comprising:

12. An interface detection apparatus, comprising:

13. An electronic device, characterized in that the electronic device comprises:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the interface detection tool generation method of any one of claims 1-9, or implement the interface detection method of claim 10.

14. A computer storage medium having stored thereon a computer program, characterized in that the program, when being executed by a processor, implements an interface detection method according to any one of claims 1-9, or implements an interface detection method according to claim 10.