CN115827437A - Static code analysis method and device, electronic equipment, readable storage medium and chip - Google Patents

Static code analysis method and device, electronic equipment, readable storage medium and chip Download PDF

Info

Publication number
CN115827437A
CN115827437A CN202211421463.6A CN202211421463A CN115827437A CN 115827437 A CN115827437 A CN 115827437A CN 202211421463 A CN202211421463 A CN 202211421463A CN 115827437 A CN115827437 A CN 115827437A
Authority
CN
China
Prior art keywords
code
service
determining
attribute information
version
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211421463.6A
Other languages
Chinese (zh)
Inventor
唐家宇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Volcano Engine Technology Co Ltd
Original Assignee
Beijing Volcano Engine Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Volcano Engine Technology Co Ltd filed Critical Beijing Volcano Engine Technology Co Ltd
Priority to CN202211421463.6A priority Critical patent/CN115827437A/en
Publication of CN115827437A publication Critical patent/CN115827437A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Stored Programmes (AREA)

Abstract

The application discloses a static code analysis method and device, electronic equipment, a readable storage medium and a chip, and belongs to the technical field of software testing, wherein the static code analysis method comprises the following steps: responding to a call request of a code compatibility detection service; detecting a first target remote procedure call service framework used by a first target code warehouse, analyzing a first syntax tree, and analyzing first interface content and attribute information of a first interface description language file from the first syntax tree; detecting a second target remote procedure call service framework used by a second target code warehouse, analyzing a second syntax tree, and analyzing second interface content and attribute information of a second interface description language file from the second syntax tree; and determining whether the compatibility problem exists between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file.

Description

Static code analysis method and device, electronic equipment, readable storage medium and chip
Technical Field
The application belongs to the field of software testing, and particularly relates to a static code analysis method, a static code analysis device, electronic equipment, a readable storage medium and a chip.
Background
In the development process, a code generation tool provided by a framework through a specific interface description language is utilized to convert the code into product code applied to engineering. However, projects are iterated continuously, files programmed by using an interface description language are often changed, different compatibility risks exist in the changing process, if verification is not performed and the files are directly on-line, the projects cannot be used normally, in the related art, static inspection is usually performed directly on the files of the interface description language when the files are changed, and even if the inspection results pass, the files cannot be used normally after products are applied to the projects.
Disclosure of Invention
The embodiment of the application aims to provide a static code analysis method and device, an electronic device, a readable storage medium and a chip, which can solve the problem that after static inspection is finished, compatibility exists when a product is applied to a project, and the product cannot be normally used.
In a first aspect, an embodiment of the present application provides a static code analysis method, where the method includes: responding to a calling request of the code compatibility detection service, wherein the calling request is used for requesting to detect whether a compatibility problem exists between the second version code and the first version code; determining a first target code warehouse where the first version code is located, detecting a first target remote procedure call service frame used by the first target code warehouse, analyzing a first syntax tree of a frame directory under the first target remote procedure call service frame, analyzing first interface content of corresponding services from the first syntax tree, and constructing attribute information of a first interface description language file based on a structural body in the first syntax tree; determining a second target code warehouse where a second version code is located, detecting a second target remote procedure call service frame used by the second target code warehouse, analyzing a second syntax tree of a lower frame directory of the second target remote procedure call service frame, analyzing second interface content of corresponding services from the second syntax tree and constructing attribute information of a second interface description language file based on a structural body in the second syntax tree; and determining whether the compatibility problem exists between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file.
In a second aspect, an embodiment of the present application provides a static code analysis apparatus, including: the request module is used for responding to a calling request of the code compatibility detection service, and the calling request is used for requesting to detect whether a compatibility problem exists between the second version code and the first version code; the first parsing module is used for determining a first target code warehouse where the first version code is located, detecting a first target remote procedure call service framework used by the first target code warehouse, parsing a first syntax tree of a framework directory under the first target remote procedure call service framework, parsing first interface content of corresponding services from the first syntax tree and constructing attribute information of a first interface description language file based on a structure body in the first syntax tree; the second parsing module is used for determining a second target code warehouse where the second version code is located, detecting a second target remote procedure call service framework used by the second target code warehouse, parsing a second syntax tree of a lower framework directory of the second target remote procedure call service framework, parsing second interface content of corresponding services from the second syntax tree and constructing attribute information of a second interface description language file based on a structure body in the second syntax tree; and the judging module is used for determining whether the compatibility problem exists between the second version code and the first version code according to the first interface content, the attribute information of the first interface description file and the attribute information of the second interface content and the second interface description file.
In a third aspect, embodiments of the present application provide an electronic device, which includes a processor, a memory, and a program or instructions stored on the memory and executable on the processor, where the program or instructions, when executed by the processor, implement the steps of the method according to the first aspect.
In a fourth aspect, embodiments of the present application provide a readable storage medium on which a program or instructions are stored, which when executed by a processor, implement the steps of the method according to the first aspect.
In a fifth aspect, embodiments of the present application provide a chip, where the chip includes a processor and a communication interface, where the communication interface is coupled to the processor, and the processor is configured to execute a program or instructions to implement the steps of the method according to the first aspect.
In the embodiment of the application, a call request is acquired first to detect the compatibility of the codes of the two versions, that is, the call request is used for requesting to detect whether a compatibility problem exists between the code of the second version and the code of the first version, and after the call request is received, the code products of the codes of the two versions are determined respectively. Specifically, for a first version code, a warehouse where the code is located, that is, a first target code warehouse is determined, a first syntax tree of a frame directory under a service frame is determined by detecting a target remote procedure call service frame used by the code warehouse, and a corresponding service can be analyzed according to the first syntax tree, so that first interface content is determined, and meanwhile, a first interface description language file is constructed based on a structure body in the first syntax tree, and finally attribute information of the first interface description language file is determined. For the second version code, the specific algorithm flow is the same as the first version code, but the specifically adopted target code warehouse, the target remote procedure call service framework and the syntax tree are different, so that the finally analyzed interface contents of the two versions and the attribute information of the interface description language file of the component have the problem of compatibility. It should be emphasized that, in the solution of the present application, it is through comparing the code products of the two versions before and after the update, that is, comparing the attribute information of the first interface content and the first interface description file with the attribute information of the second interface content and the second interface description file, it is finally determined whether there is a compatibility problem between the two versions of the code.
It should be emphasized that the code product is a final file applied to a project, and the present application determines whether a compatibility problem exists by determining the code products of the two previous and subsequent versions, that is, comparing and checking the changed code product with the code product of the previous version.
According to the method and the device, the code product is directly subjected to static inspection, the modification cost is greatly reduced, and the service interface can be recalled under the condition of no compatibility problem.
Drawings
FIG. 1 shows a flow diagram of a static code analysis method according to an embodiment of the present application;
FIG. 2 shows a flow diagram of a static code analysis method according to an embodiment of the present application;
FIG. 3 shows a flow diagram of a static code analysis method according to an embodiment of the present application;
FIG. 4 shows a flow diagram of a static code analysis method according to an embodiment of the present application;
FIG. 5 shows a schematic structural diagram of a static code analysis apparatus according to an embodiment of the present application;
FIG. 6 shows a schematic structural diagram of a static code analysis apparatus according to an embodiment of the present application;
FIG. 7 shows a schematic structural diagram of an electronic device according to an embodiment of the present application;
fig. 8 shows a schematic structural diagram of an electronic device according to an embodiment of the application.
Wherein, the correspondence between the reference numbers and the part names in fig. 5 to 8 is:
100: an electronic device; 101: a radio frequency unit; 102: a network module; 103: an audio output unit; 104: an input unit; 1041: a graphics processor; 1042: a microphone; 105: a sensor; 106: a display unit; 1061: a display panel; 107: a user input unit; 1071: a touch panel; 1072: other input devices; 108: an interface unit; 1109: a memory; 1110: a processor; 900: a static code analysis device; 901: a request module; 902: a first parsing module; 903: a second parsing module; 904: a judgment module; 905: calling a module; 906: and an early warning module.
Detailed Description
The technical solutions in the embodiments of the present application will be described clearly below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of the present disclosure.
The terms first, second and the like in the description and in the claims of the present application are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that embodiments of the application may be practiced in sequences other than those illustrated or described herein, and that the terms "first," "second," and the like are generally used herein in a generic sense and do not limit the number of terms, e.g., the first term can be one or more than one. In addition, "and/or" in the specification and claims means at least one of connected objects, a character "/" generally means that a preceding and succeeding related objects are in an "or" relationship.
The static code analysis method and apparatus, the electronic device, the readable storage medium, and the chip provided in the embodiments of the present application are described in detail below with reference to fig. 1 to 8 through specific embodiments and application scenarios thereof.
The embodiment provides a static code analysis method, as shown in fig. 1, including:
step S102: responding to a call request of a code compatibility detection service;
the calling request is used for requesting to detect whether a compatibility problem exists between the second version code and the first version code;
step S104: determining a first target code warehouse where the first version code is located, detecting a first target remote procedure call service frame used by the first target code warehouse, analyzing a first syntax tree of a frame directory under the first target remote procedure call service frame, analyzing first interface content of corresponding services from the first syntax tree, and constructing attribute information of a first interface description language file based on a structural body in the first syntax tree;
step S106: determining a second target code warehouse where a second version code is located, detecting a second target remote procedure call service frame used by the second target code warehouse, analyzing a second syntax tree of a lower frame directory of the second target remote procedure call service frame, analyzing second interface content of corresponding services from the second syntax tree and constructing attribute information of a second interface description language file based on a structural body in the second syntax tree;
step S108: and determining whether the compatibility problem exists between the second version code and the first version code according to the first interface content and the attribute information of the first interface description file and the attribute information of the second interface content and the second interface description file.
In the static code analysis method provided in this embodiment, a call request is first obtained to detect compatibility between codes of two versions, that is, the call request is used to request to detect whether there is a compatibility problem between a code of a second version and a code of a first version, and after the call request is received, code products are determined for the codes of the two versions respectively. Specifically, for a first version code, a warehouse where the code is located, that is, a first target code warehouse, is determined, a first syntax tree of a frame directory under a service frame is determined by detecting a target remote procedure call service frame used by the code warehouse, a corresponding service can be analyzed according to the first syntax tree, so that first interface content is determined, meanwhile, a first interface description language file is constructed based on a structure body in the first syntax tree, and finally attribute information of the first interface description language file is determined. For the second version code, the specific algorithm flow is the same as the first version code, but the specifically adopted target code warehouse, the target remote procedure call service framework and the syntax tree are different, so that the finally analyzed interface contents of the two versions and the attribute information of the interface description language file of the component have the problem of compatibility. It should be emphasized that, in the solution of the present application, it is through comparing the code products of the two versions before and after the update, that is, comparing the attribute information of the first interface content and the first interface description file with the attribute information of the second interface content and the second interface description file, it is finally determined whether there is a compatibility problem between the two versions of the code.
For example, if there is a thrift _ gen directory in the first target code repository, the current repository is considered to use the Kite framework (i.e., the first target remote procedure call service framework), and if there is a KiteX _ gen directory in the second target code repository, the current repository is considered to use the KiteX framework (the second target remote procedure call service framework). And finding a syntax tree according to the frame, specifically, according to a first syntax tree of a lower frame directory of a first target remote process call service frame or according to a second syntax tree of a lower frame directory of a second target remote process call service frame, analyzing the syntax tree to determine a code product (namely, the first interface content, the second interface content, the attribute information of the first interface description language file and the attribute information of the second interface description language file), wherein it is emphasized that the code product is a final file applied to a project.
The method and the device have the advantages that static inspection is directly carried out on the code product, the modification cost is greatly reduced, and the service interface can be recalled without compatibility problems.
It should be added that the first target remote procedure call service framework and the second target remote procedure call service framework can be Golang RPC micro-service frameworks, such as a KiteX framework or a Kite framework, and describe interfaces to the outside of the service by using two interface description languages, namely, thread or Protobuf.
For the whole process of the static code analysis method, a SatCheck framework can be selected, has the characteristics of light weight and convenience in access, supports the code comparison inspection of two versions in an MR stage or a pipeline stage, and has low influence on the original research and development process.
Optionally, as shown in fig. 2, the method further includes:
step S1102: determining a target remote procedure call service framework used by a target code repository;
step S1104: and determining the type of the code root directory contained in the object code warehouse according to the file structure of the object code warehouse.
Step S1042: if the target code warehouse comprises the first code root directory, determining a target remote calling service framework used by the target code warehouse as a first target remote calling service framework;
step S1062: and if the second code root directory is contained in the target code warehouse, determining the target remote calling service framework used by the target code warehouse as a second target remote calling service framework.
In the scheme, for the code warehouses of two versions, when the corresponding code root directories are searched, a target remote procedure call service framework used by the code warehouse needs to be determined, and then the type of the code root directory contained by the code warehouse is determined according to the file structure of the code warehouse. Specifically, for a first object code repository, a first object remote procedure call service frame used by the first object code repository, for example, a Kite frame, is determined, and according to a file structure of the first object code repository, a corresponding first code root directory, that is, thrift _ gen, is determined, and then a subsequent determination step is performed, if the object code repository includes the first code root directory, the current object code repository is considered as the first object code repository, and the object remote procedure call service frame used by the object code repository can be directly determined as the first object remote procedure call service frame, and similarly, for a second object code repository, if the object code repository includes the second code root directory, for example: and the KiteX _ gen directory considers that the current target code warehouse is the second target code warehouse, and can directly determine that the target remote calling service frame used by the target code warehouse is the second target remote calling service frame, namely a KiteX frame.
Optionally, as shown in fig. 3, the method includes:
step S1082: determining a first service method of a first interface description file and a second service method of a second interface description file;
step S1084: when the first service method is the same as the second service method, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists;
step S1086: and when the attribute information of the first interface description file is the same as the attribute information of the second interface description file, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists.
When judging whether compatibility problems exist between the two versions of codes, the method can judge through the interface description file, specifically, one of the judging modes is that a service method is utilized, after a first interface description file and a second interface description file are obtained, a corresponding first service method and a corresponding second service method can be respectively determined, and when the service methods of the two versions are the same, the compatibility problem is not found. The other judgment method is attribute information, after acquiring the attribute information of the interface description files of the two versions, the attribute information can be directly compared, and if the attribute information of the two versions is the same, the problem of no compatibility is considered.
In a specific embodiment, the first target remote invocation service framework is a Kite framework, the second target remote invocation service framework is a KiteX framework, the first service method may be a packet used by using a right value in a statement assigned to a Kite.
For the main package, go files defining the interfaces of the external services are respectively found, and the two service methods can be judged whether to be the same or not by analyzing and comparing the go files. If the go files of the interfaces corresponding to the main package obtained by the two service methods are consistent after being analyzed, the two service methods are considered to be the same.
Further, constructing attribute information of the first interface description language file based on the structure in the first syntax tree specifically includes: determining a first service primary packet according to the first syntax tree; determining, within the first service primary package, a plurality of first labels based on a structure in a first syntax tree; and constructing attribute information of the first interface description file according to the plurality of first tags.
In this embodiment, the construction of the attribute information of the first interface description language file is mainly explained, specifically, after the first syntax tree is obtained, the corresponding first service primary package is determined, and at this time, a plurality of first tags may be determined based on a structural body in the first syntax tree, so as to construct the corresponding attribute information.
Taking the first target remote procedure call service framework as the Kite framework as an example, at this time, the first service primary package can be determined from the syntax tree of Kite.
Further, constructing attribute information of the second interface description language file based on the structure in the second syntax tree specifically includes: determining a second service primary packet according to the second syntax tree; determining a plurality of second tags based on the structure in the second syntax tree within the second service master package; and constructing attribute information of the second interface description file according to the plurality of second tags.
Similarly, taking the second target remote procedure call service framework as the KiteX framework as an example, the second service main package may be determined from the syntax tree of main.
In a specific embodiment, when determining whether there is a compatibility problem between the two versions of codes, the service parameter is considered, that is, when the service parameter in the first interface content is different from the service parameter in the second interface content, it is determined that there is a compatibility problem between the second version of codes and the first version of codes.
In this embodiment, whether the service method parameters corresponding to the two version code products change is detected.
In another specific embodiment, when determining whether there is a compatibility problem between the two versions of codes, the service scope type is considered, that is, when the service return type in the first interface content is different from the service return type in the second interface content, it is determined that there is a compatibility problem between the second version of codes and the first version of codes.
In this embodiment, whether the service method return types corresponding to the two version code products change is detected.
In another specific embodiment, when determining whether there is a compatibility problem between the two version codes, it is determined that there is a compatibility problem between the second version code and the first version code in consideration of the service name, that is, in the case where the service name in the first interface content is different from the service name in the second interface content.
The present embodiment detects whether the service method name corresponding to the two version code products is renamed or discarded.
In another specific embodiment, when determining whether there is a compatibility problem between two versions of codes, it may be determined that there is a compatibility problem between the second version of codes and the first version of codes in consideration of the necessary field of the structure, that is, in the case where the necessary field of the structure in the attribute information of the first interface description file is different from the necessary field of the structure in the attribute information of the second interface description file.
In this embodiment, whether a required field is added to the structure corresponding to the two version code products is detected.
In another specific embodiment, when determining whether there is a compatibility problem between two versions of codes, it may determine that there is a compatibility problem between the second version of codes and the first version of codes in consideration of the structure field type, that is, when the structure field type in the attribute information of the first interface description file is different from the structure field type in the attribute information of the second interface description file.
The specific embodiment is to detect whether the structure field types corresponding to the two version code products change.
In another specific embodiment, when determining whether there is a compatibility problem between two versions of codes, it may determine that there is a compatibility problem between the second version of codes and the first version of codes in consideration of the structure field number, that is, when the structure field number in the attribute information of the first interface description file is different from the structure field number in the attribute information of the second interface description file.
In this embodiment, whether the field id of the structure corresponding to the two version code products changes is detected.
It is understood that the tags can be used to indicate the field names in the communication process, the sequence of the serialization process, and whether the feature is necessary. Based on the information, attribute information of the IDL file is reversely constructed, namely the attribute information of the two versions can be compared, and whether compatibility risks exist can be judged.
Further, under the condition that the compatibility problem exists between the second version code and the first version code, alarm information is generated according to the compatibility problem, and an alarm basis is sent to the outside.
Once compatibility between the two versions of codes is in problem, corresponding warning information is generated, and accordingly a warning is sent out to the outside to output the problem and perform early warning by using a testing framework. Specifically, a SatCheck framework can be used for detecting whether compatibility exists between two versions, and an alarm message can be generated when a compatibility problem occurs by using the framework.
Furthermore, the external alarm can be sent in a mode of information, images, audio and the like so as to remind related personnel of revising the codes.
In another embodiment, as shown in fig. 4, responding to the call request of the code compatibility detection service specifically includes: step S1022, in the working mode of merging the codes, or in the mode of static code checking, responding to the call request of the code compatibility detection service.
As shown in fig. 5, an embodiment of the present application provides a static code analysis apparatus 900. The static code analysis device comprises a request module 901, a first analysis module 902, a second analysis module 903 and a judgment module 904.
The request module 901 is configured to respond to a call request of a code compatibility detection service, where the call request is used to request to detect whether a compatibility problem exists between a second version code and a first version code; a first parsing module 902, configured to determine a first target code repository where the first version code is located, detect a first target remote procedure call service framework used by the first target code repository, parse a first syntax tree of a framework directory under the first target remote procedure call service framework, parse first interface content of a corresponding service from the first syntax tree, and construct attribute information of a first interface description language file based on a structure in the first syntax tree; a second parsing module 903, configured to determine a second target code repository where the second version code is located, detect a second target remote procedure call service framework used by the second target code repository, parse a second syntax tree of a lower framework directory of the second target remote procedure call service framework, parse second interface content of a corresponding service from the second syntax tree, and construct attribute information of a second interface description language file based on a structure in the second syntax tree; the determining module 904 is configured to determine whether there is a compatibility problem between the second version code and the first version code according to the first interface content and the attribute information of the first interface description file, and the second interface content and the attribute information of the second interface description file.
Optionally, as shown in fig. 6, the method further includes: a calling module 905, configured to determine a target remote procedure call service framework used by the target code repository; determining the type of a code root directory contained in the target code warehouse according to the file structure of the target code warehouse; the first parsing module 902 is further configured to, in a case that the target code repository includes the first code root directory, determine that a target remote invocation service framework used by the target code repository is a first target remote invocation service framework; the second parsing module 903 is further configured to determine, if the target code repository includes the second code root directory, that the target remote invocation service framework used by the target code repository is the second target remote invocation service framework.
Optionally, the determining module 904 is further configured to determine a first service method of the first interface description file and a second service method of the second interface description file; when the first service method is the same as the second service method, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists; and when the attribute information of the first interface description file is the same as the attribute information of the second interface description file, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists.
Optionally, the first parsing module 902 is further configured to determine a first service primary package according to the first syntax tree; determining, within the first service primary package, a plurality of first labels based on a structure in a first syntax tree; constructing attribute information of a first interface description file according to a plurality of first tags; the second parsing module 903 is further configured to determine a second service primary packet according to the second syntax tree; determining a plurality of second tags based on the structure in the second syntax tree within the second service master package; and constructing attribute information of the second interface description file according to the plurality of second tags.
Optionally, the determining module 904 is further configured to determine that a compatibility problem exists between the second version code and the first version code when the service parameter in the first interface content is different from the service parameter in the second interface content; and/or determining that a compatibility problem exists between the second version code and the first version code under the condition that the service return type in the first interface content is different from the service return type in the second interface content; and/or determining that there is a compatibility problem between the second version code and the first version code if the service name in the first interface content is different from the service name in the second interface content; and/or determining that the compatibility problem exists between the second version code and the first version code under the condition that the necessary field of the structure body in the attribute information of the first interface description file is different from the necessary field of the structure body in the attribute information of the second interface description file; and/or determining that the compatibility problem exists between the second version code and the first version code under the condition that the structure field type in the attribute information of the first interface description file is different from the structure field type in the attribute information of the second interface description file; and/or determining that the compatibility problem exists between the second version code and the first version code under the condition that the structure field number in the attribute information of the first interface description file is different from the structure field number in the attribute information of the second interface description file.
Optionally, as shown in fig. 6, the method further includes: and the early warning module 906 is configured to generate warning information according to the compatibility problem and send a warning to the outside when the compatibility problem exists between the second version code and the first version code.
Optionally, the requesting module 901 is further configured to: responding to a calling request of a code compatibility detection service in a working mode of merging codes; or in a static code checking mode, in response to a request for invocation of a code compatibility detection service.
The static code analysis device in the embodiment of the present application may be a device, or may be a component, an integrated circuit, or a chip in a terminal. The device can be mobile electronic equipment or non-mobile electronic equipment. By way of example, the mobile electronic device may be a mobile phone, a tablet computer, a notebook computer, a palm top computer, a vehicle-mounted electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a Personal Digital Assistant (PDA), and the like, and the non-mobile electronic device may be a server, a Network Attached Storage (NAS), a Personal Computer (PC), a Television (TV), a teller machine or a self-service machine, and the like, and the embodiments of the present application are not particularly limited.
The static code analysis device in the embodiment of the present application may be a device having an operating system. The operating system may be an Android (Android) operating system, an ios operating system, or other possible operating systems, and embodiments of the present application are not limited specifically.
The static code analysis device provided in the embodiment of the present application can implement each process implemented by the method embodiments of fig. 1 to fig. 4, and is not described here again to avoid repetition.
Optionally, as shown in fig. 7, an electronic device 100 is further provided in this embodiment of the present application, and includes a processor 1110, a memory 1109, and a program or an instruction stored in the memory 1109 and executable on the processor 1110, where the program or the instruction is executed by the processor 1110 to implement each process of the embodiment of the static code analysis method, and can achieve the same technical effect, and is not described herein again to avoid repetition.
It should be noted that the electronic devices in the embodiments of the present application include the electronic devices and the non-electronic devices described above.
Fig. 8 is a schematic diagram of a hardware structure of an electronic device implementing an embodiment of the present application.
The electronic device 100 includes, but is not limited to: a radio frequency unit 101, a network module 102, an audio output unit 103, an input unit 104, a sensor 105, a display unit 106, a user input unit 107, an interface unit 108, a memory 1109, a processor 1110, and the like.
Those skilled in the art will appreciate that the electronic device 100 may further comprise a power source (e.g., a battery) for supplying power to the various components, and the power source may be logically connected to the processor 1110 via a power management system, so as to implement functions of managing charging, discharging, and power consumption via the power management system. The electronic device structure shown in fig. 8 does not constitute a limitation to the electronic device, and the electronic device may include more or less components than those shown, or combine some components, or arrange different components, and thus, the description is omitted here.
The processor 1110 is configured to respond to a call request of a code compatibility detection service, where the call request is used to request to detect whether a compatibility problem exists between the second version code and the first version code; determining a first target code warehouse where the first version code is located, detecting a first target remote procedure call service frame used by the first target code warehouse, analyzing a first syntax tree of a frame directory under the first target remote procedure call service frame, analyzing first interface content of corresponding services from the first syntax tree, and constructing attribute information of a first interface description language file based on a structural body in the first syntax tree; determining a second target code warehouse where a second version code is located, detecting a second target remote procedure call service frame used by the second target code warehouse, analyzing a second syntax tree of a lower frame directory of the second target remote procedure call service frame, analyzing second interface content of corresponding services from the second syntax tree and constructing attribute information of a second interface description language file based on a structural body in the second syntax tree; and determining whether the compatibility problem exists between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file.
By the scheme, the call request is acquired first to detect the compatibility of the codes of the two versions, namely the call request is used for requesting to detect whether the compatibility problem exists between the codes of the second version and the codes of the first version, and after the call request is received, the code products are determined according to the codes of the two versions respectively. Specifically, for a first version code, a warehouse where the code is located, that is, a first target code warehouse, is determined, a first syntax tree of a frame directory under a service frame is determined by detecting a target remote procedure call service frame used by the code warehouse, a corresponding service can be analyzed according to the first syntax tree, so that first interface content is determined, meanwhile, a first interface description language file is constructed based on a structure body in the first syntax tree, and finally attribute information of the first interface description language file is determined. For the second version code, the specific algorithm flow is the same as the first version code, but the specifically adopted target code warehouse, the target remote procedure call service framework and the syntax tree are different, so that the finally analyzed interface contents of the two versions and the attribute information of the interface description language file of the component have the problem of compatibility. It should be emphasized that, in the solution of the present application, it is determined whether there is a compatibility problem between the two versions of the code by comparing the code products of the two versions before and after the update, that is, comparing the attribute information of the first interface content and the first interface description file with the attribute information of the second interface content and the second interface description file.
Optionally, the processor 1110 is further configured to implement the following steps: determining a target remote procedure call service framework used by the target code repository: determining the type of a code root directory contained in the target code warehouse according to the file structure of the target code warehouse; if the target code warehouse comprises the first code root directory, determining a target remote calling service framework used by the target code warehouse as a first target remote calling service framework; and if the second code root directory is contained in the target code warehouse, determining the target remote calling service framework used by the target code warehouse as a second target remote calling service framework.
Optionally, the processor 1110 is further configured to determine a first service method of the first interface description file and a second service method of the second interface description file; when the first service method is the same as the second service method, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists; and when the attribute information of the first interface description file is the same as the attribute information of the second interface description file, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists.
Optionally, the processor 1110 is further configured to determine a first service home packet according to the first syntax tree; determining, within the first service primary package, a plurality of first labels based on a structure in a first syntax tree; constructing attribute information of a first interface description file according to a plurality of first tags; determining a second service primary packet according to the second syntax tree; determining a plurality of second tags based on a structure in a second syntax tree within a second service main package; and constructing attribute information of the second interface description file according to the plurality of second tags.
Optionally, the processor 1110 is further configured to determine that there is a compatibility problem between the second version code and the first version code if the service parameter in the first interface content is different from the service parameter in the second interface content; and/or determining that a compatibility problem exists between the second version code and the first version code under the condition that the service return type in the first interface content is different from the service return type in the second interface content; and/or determining that there is a compatibility problem between the second version code and the first version code if the service name in the first interface content is different from the service name in the second interface content; and/or determining that the compatibility problem exists between the second version code and the first version code under the condition that the necessary field of the structure body in the attribute information of the first interface description file is different from the necessary field of the structure body in the attribute information of the second interface description file; and/or determining that the compatibility problem exists between the second version code and the first version code under the condition that the structure field type in the attribute information of the first interface description file is different from the structure field type in the attribute information of the second interface description file; and/or determining that the compatibility problem exists between the second version code and the first version code under the condition that the structure field number in the attribute information of the first interface description file is different from the structure field number in the attribute information of the second interface description file.
Optionally, the processor 1110 is further configured to generate alarm information according to a compatibility problem and issue an alarm to the outside when there is a compatibility problem between the second version code and the first version code.
Optionally, the processor 1110 is further configured to respond to a request for calling a code compatibility detection service in an operating mode of merging codes; or in a static code checking mode, in response to a request for invocation of a code compatibility detection service.
It should be understood that, in the embodiment of the present application, the input Unit 104 may include a Graphics Processing Unit (GPU) 1041 and a microphone 1042, and the Graphics Processing Unit 1041 processes image data of a still picture or a video obtained by an image capturing device (such as a camera) in a video capturing mode or an image capturing mode. The display unit 106 may include a display panel 1061, and the display panel 1061 may be configured in the form of a liquid crystal display, an organic light emitting diode, or the like. The user input unit 107 includes a touch panel 1071 and other input devices 1072. The touch panel 1071 is also referred to as a touch screen. The touch panel 1071 may include two parts of a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which are not described in detail herein. The memory 1109 may be used for storing software programs and various data including, but not limited to, application programs and an operating system. Processor 1110 may integrate an application processor that handles primarily operating systems, user interfaces, applications, etc. and a modem processor that handles primarily wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 1110.
The embodiments of the present application further provide a readable storage medium, where a program or an instruction is stored on the readable storage medium, and when the program or the instruction is executed by a processor, the program or the instruction implements each process of the static code analysis method, and can achieve the same technical effect, and in order to avoid repetition, details are not repeated here.
The processor is the processor in the electronic device in the above embodiment. Readable storage media, including computer-readable storage media, such as computer Read-Only Memory (ROM), random Access Memory (RAM), magnetic or optical disks, etc.
The embodiment of the present application further provides a chip, where the chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is configured to run a program or an instruction to implement each process of the static code analysis method embodiment, and the same technical effect can be achieved.
It should be understood that the chips mentioned in the embodiments of the present application may also be referred to as system-on-chip, system-on-chip or system-on-chip, etc.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a component of' 8230; \8230;" does not exclude the presence of another like element in a process, method, article, or apparatus that comprises the element. Further, it should be noted that the scope of the methods and apparatus of the embodiments of the present application is not limited to performing the functions in the order illustrated or discussed, but may include performing the functions in a substantially simultaneous manner or in a reverse order based on the functions involved, e.g., the methods described may be performed in an order different than that described, and various steps may be added, omitted, or combined. In addition, features described with reference to certain examples may be combined in other examples.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present application may be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, or a network device) to execute the method of the embodiments of the present application.
While the present embodiments have been described with reference to the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiments described above, which are meant to be illustrative and not restrictive, and that various changes may be made therein by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (17)

1. A static code analysis method, comprising:
responding to a calling request of a code compatibility detection service, wherein the calling request is used for requesting to detect whether a compatibility problem exists between the second version code and the first version code;
determining a first target code warehouse where a first version code is located, detecting a first target remote procedure call service frame used by the first target code warehouse, analyzing a first syntax tree of a lower frame directory of the first target remote procedure call service frame, analyzing first interface content of a corresponding service from the first syntax tree, and constructing attribute information of a first interface description language file based on a structure body in the first syntax tree;
determining a second target code warehouse where a second version code is located, detecting a second target remote procedure call service frame used by the second target code warehouse, analyzing a second syntax tree of a lower frame directory of the second target remote procedure call service frame, analyzing second interface content of a corresponding service from the second syntax tree, and constructing attribute information of a second interface description language file based on a structure body in the second syntax tree;
and determining whether a compatibility problem exists between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file.
2. The static code analysis method of claim 1, further comprising:
determining a target remote procedure call service framework used by the target code repository:
determining the type of a code root directory contained in the target code warehouse according to the file structure of the target code warehouse;
the determining a first target code repository where the first version code is located, and detecting a first target remote procedure call service framework used by the first target code repository specifically include:
if the target code warehouse comprises the first code root directory, determining a target remote calling service framework used by the target code warehouse as a first target remote calling service framework;
the determining a second target code repository where a second version code is located, and detecting a second target remote procedure call service framework used by the second target code repository specifically include:
and if the second code root directory is contained in the object code warehouse, determining the target remote calling service framework used by the object code warehouse as a second target remote calling service framework.
3. The static code analysis method according to claim 1, wherein the determining whether there is a compatibility problem between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file specifically comprises:
determining a first service method of the first interface description file and a second service method of the second interface description file;
when the first service method is the same as the second service method, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists;
and when the attribute information of the first interface description file is the same as the attribute information of the second interface description file, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists.
4. The method of claim 1, wherein the constructing attribute information of a first interface description language file based on a structure in the first syntax tree comprises:
determining a first service primary packet according to the first syntax tree;
determining, within the first service primary package, a plurality of first labels based on a structure in the first syntax tree;
constructing attribute information of the first interface description file according to the plurality of first tags;
the constructing of the attribute information of the second interface description language file based on the structure body in the second syntax tree includes:
determining a second service primary packet according to the second syntax tree;
determining, within the second service host package, a plurality of second tags based on a structure in the second syntax tree;
and constructing attribute information of the second interface description file according to the plurality of second tags.
5. The method of claim 1, wherein the determining whether there is a compatibility problem between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file comprises:
determining that there is a compatibility problem between the second version code and the first version code if the service parameters in the first interface content are different from the service parameters in the second interface content; and/or
Determining that there is a compatibility problem between the second version code and the first version code if the service return type in the first interface content is different from the service return type in the second interface content; and/or
Determining that there is a compatibility problem between the second version code and the first version code if the service name in the first interface content is different from the service name in the second interface content; and/or
Determining that a compatibility problem exists between the second version code and the first version code when a structure body necessary field in the attribute information of the first interface description file is different from a structure body necessary field in the attribute information of the second interface description file; and/or
Determining that a compatibility problem exists between the second version code and the first version code under the condition that the structure field type in the attribute information of the first interface description file is different from the structure field type in the attribute information of the second interface description file; and/or
And determining that the second version code and the first version code have a compatibility problem when the structure field number in the attribute information of the first interface description file is different from the structure field number in the attribute information of the second interface description file.
6. The static code analysis method according to any one of claims 1 to 5, further comprising:
and under the condition that the compatibility problem exists between the second version code and the first version code, generating alarm information according to the compatibility problem and sending an alarm to the outside.
7. The static code analysis method according to any one of claims 1 to 5, wherein the responding to the call request of the code compatibility detection service specifically includes:
responding to a calling request of a code compatibility detection service in a working mode of merging codes; or
In the static code checking mode, responding to a calling request of a code compatibility detection service.
8. A static code analysis apparatus, comprising:
the request module is used for responding to a calling request of a code compatibility detection service, and the calling request is used for requesting to detect whether a compatibility problem exists between the second version code and the first version code;
the system comprises a first parsing module, a first target code warehouse and a first interface description language file, wherein the first target code warehouse is used for determining a first target code, the first target remote procedure call service frame is used by the first target code warehouse, a first syntax tree of a lower frame directory of the first target remote procedure call service frame is parsed, first interface contents of corresponding services are parsed from the first syntax tree, and attribute information of the first interface description language file is constructed on the basis of a structure body in the first syntax tree;
the second parsing module is used for determining a second target code warehouse where a second version code is located, detecting a second target remote procedure call service framework used by the second target code warehouse, parsing a second syntax tree of a framework directory under the second target remote procedure call service framework, parsing second interface content of a corresponding service from the second syntax tree and constructing attribute information of a second interface description language file based on a structure body in the second syntax tree;
and the judging module is used for determining whether the compatibility problem exists between the second version code and the first version code according to the attribute information of the first interface content and the first interface description file and the attribute information of the second interface content and the second interface description file.
9. The static code analysis device of claim 8, further comprising:
the calling module is used for determining a target remote procedure calling service framework used by the target code warehouse; determining the type of a code root directory contained in the target code warehouse according to the file structure of the target code warehouse;
the first analysis module is further used for determining a target remote calling service framework used by the target code warehouse as a first target remote calling service framework under the condition that the target code warehouse comprises the first code root directory;
and the second analysis module is also used for determining that the target remote calling service framework used by the target code warehouse is a second target remote calling service framework under the condition that the target code warehouse comprises a second code root directory.
10. The static code analysis device of claim 8, wherein the determining module is further configured to determine a first service method of the first interface description file and a second service method of the second interface description file; when the first service method is the same as the second service method, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists; and when the attribute information of the first interface description file is the same as the attribute information of the second interface description file, determining that no compatibility problem exists between the second version code and the first version code, otherwise, determining that the compatibility problem exists.
11. The static code analysis device according to any one of claims 8 to 10, characterized by further comprising:
the first parsing module is further configured to determine a first service primary packet according to the first syntax tree; determining, within the first service primary package, a plurality of first labels based on a structure in the first syntax tree; constructing attribute information of the first interface description file according to the plurality of first tags;
the second parsing module is further configured to determine a second service primary package according to the second syntax tree; determining, within the second service primary package, a plurality of second tags based on a structure in the second syntax tree; and constructing attribute information of the second interface description file according to the plurality of second tags.
12. The static code analysis device of claim 9, wherein the determining module is further configured to determine that there is a compatibility problem between the second version code and the first version code if the service parameters in the first interface content are different from the service parameters in the second interface content; and/or
Determining that there is a compatibility problem between the second version code and the first version code if the service return type in the first interface content is different from the service return type in the second interface content; and/or
Determining that there is a compatibility problem between the second version code and the first version code if the service name in the first interface content is different from the service name in the second interface content; and/or
Determining that a compatibility problem exists between the second version code and the first version code when a structure body necessary field in the attribute information of the first interface description file is different from a structure body necessary field in the attribute information of the second interface description file; and/or
Determining that a compatibility problem exists between the second version code and the first version code under the condition that the structure field type in the attribute information of the first interface description file is different from the structure field type in the attribute information of the second interface description file; and/or
And determining that the second version code and the first version code have a compatibility problem when the structure field number in the attribute information of the first interface description file is different from the structure field number in the attribute information of the second interface description file.
13. The static code analysis device according to any one of claims 8 to 10, further comprising:
and the early warning module is used for generating warning information according to the compatibility problem and sending a warning to the outside under the condition that the compatibility problem exists between the second version code and the first version code.
14. The static code analysis device of any of claims 8-10, wherein the request module is further configured to: responding to a calling request of a code compatibility detection service in a working mode of merging codes; or in a static code checking mode, in response to a request for invocation of a code compatibility detection service.
15. An electronic device comprising a processor, a memory, and a program or instructions stored on the memory and executable on the processor, the program or instructions when executed by the processor implementing the steps of the static code analysis method of any of claims 1 to 7.
16. A readable storage medium, characterized in that it stores thereon a program or instructions which, when executed by a processor, implement the steps of the static code analysis method according to any one of claims 1 to 7.
17. A chip comprising a processor and a communication interface, the communication interface being coupled to the processor, the processor being configured to execute a program or instructions implementing the steps of the static code analysis method according to any of claims 1 to 7.
CN202211421463.6A 2022-11-14 2022-11-14 Static code analysis method and device, electronic equipment, readable storage medium and chip Pending CN115827437A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211421463.6A CN115827437A (en) 2022-11-14 2022-11-14 Static code analysis method and device, electronic equipment, readable storage medium and chip

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211421463.6A CN115827437A (en) 2022-11-14 2022-11-14 Static code analysis method and device, electronic equipment, readable storage medium and chip

Publications (1)

Publication Number Publication Date
CN115827437A true CN115827437A (en) 2023-03-21

Family

ID=85528000

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211421463.6A Pending CN115827437A (en) 2022-11-14 2022-11-14 Static code analysis method and device, electronic equipment, readable storage medium and chip

Country Status (1)

Country Link
CN (1) CN115827437A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116361194A (en) * 2023-05-19 2023-06-30 深圳凡泰极客科技有限责任公司 Abnormal code identification method, system, electronic equipment and storage medium

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116361194A (en) * 2023-05-19 2023-06-30 深圳凡泰极客科技有限责任公司 Abnormal code identification method, system, electronic equipment and storage medium
CN116361194B (en) * 2023-05-19 2023-08-29 深圳凡泰极客科技有限责任公司 Abnormal code identification method, system, electronic equipment and storage medium

Similar Documents

Publication Publication Date Title
CA2684822C (en) Data transformation based on a technical design document
US10318595B2 (en) Analytics based on pipes programming model
CN112099684A (en) Search display method and device and electronic equipment
CN111723002A (en) Code debugging method and device, electronic equipment and storage medium
CN113268260A (en) Routing method and device for web front end
CN111008017B (en) Oclin-based pre-review method for files to be submitted and related components
CN115827437A (en) Static code analysis method and device, electronic equipment, readable storage medium and chip
CN112000566B (en) Method and device for generating test cases
CN113535587B (en) Target application detection method and device and computer equipment
CN111475237A (en) Menu processing method and device, electronic equipment and storage medium
US11663245B2 (en) Initial loading of partial deferred object model
CN115062084B (en) Method and device for constructing API (application programming interface) based on database metadata
CN114816389B (en) Management system building method, device, equipment and medium based on meta-model
CN116361184A (en) Data searching method, device, medium and computer equipment
CN115221290A (en) Label preposed data query method and device, electronic equipment and readable storage medium
CN112817782B (en) Data acquisition reporting method and device, electronic equipment and storage medium
CN114238391A (en) Data paging query method and device, electronic equipment and storage medium
CN113935847A (en) Online process risk processing method, device, server and medium
CN112698879A (en) Method and device for loading source file
CN113609154A (en) Data query method and device, electronic equipment and storage medium
CN114584616B (en) Message pushing method and device, electronic equipment and storage medium
CN112445790B (en) Report data storage method, device, equipment and medium
CN113961585A (en) Data processing method and device, electronic equipment and storage medium
CN116804926A (en) Method, apparatus, device and medium for recording and displaying change of business logic
CN116361100A (en) Application state query method and vehicle-mounted interaction system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination