Software anomaly risk detection methods, computer equipment and storage media

Abstract

This application relates to a software anomaly risk detection method, computer equipment, and storage medium. By acquiring software interface information of the software to be tested that meets preset risk conditions, function call relationship information is obtained from the software interface information. Based on the function call relationship information, software anomaly risk scanning logic is derived. An anomaly risk scanning toolkit is generated based on the software anomaly risk scanning logic. During the software development process compilation, the anomaly risk scanning toolkit scans the software for software anomaly risks and outputs the software anomaly risk scanning results. Compared to traditional testing through manual execution of test cases, this solution improves the comprehensiveness of software anomaly risk detection by performing risk scanning on the compiled software before software testing, using scanning logic generated based on the function call relationships in the software, and identifying the software anomaly risk scanning results.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for detecting software anomalies and risks, a computer device, a storage medium, and a computer program product. Background Technology

[0002] With the development of computer technology, online singing and other functions can now be achieved through singing software. To ensure the normal operation of singing software, it is necessary to detect any anomalies during the software testing phase. Currently, anomaly detection in singing software is usually performed manually by executing test cases. However, manually executing test cases makes it difficult to detect accidental problems, resulting in an inability to comprehensively detect all potential anomalies and risks within the software.

[0003] Therefore, current software anomaly risk detection methods suffer from low detection comprehensiveness. Summary of the Invention

[0004] Therefore, it is necessary to provide a software anomaly risk detection method, computer equipment, computer-readable storage medium, and computer program product that can improve the comprehensiveness of detection in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for detecting software anomalies and risks, the method comprising:

[0006] Obtain software interface information of the software to be tested that meets the preset risk conditions;

[0007] Based on the software interface information, obtain the corresponding function call relationship information;

[0008] Based on the function call relationship information, the corresponding software anomaly risk scanning logic is obtained;

[0009] Based on the software anomaly risk scanning logic, an anomaly risk scanning toolkit is generated; the anomaly risk scanning toolkit is used to import the development project of the software to be tested, and scan the software anomaly risk of the software to be tested according to the software anomaly risk scanning logic during the compilation of the development project, and output the software anomaly risk scanning results.

[0010] In one embodiment, obtaining the software interface information corresponding to the software to be tested that meets the preset risk conditions includes:

[0011] Obtain historical software anomaly information corresponding to the software to be tested; the historical software anomaly information includes information about software anomalies that occurred in historical versions of the software to be tested.

[0012] Based on the historical software anomaly information, obtain software interface information that meets preset risk conditions.

[0013] In one embodiment, obtaining software interface information that meets preset risk conditions based on the historical software anomaly information includes:

[0014] Obtain multiple risk levels corresponding to multiple historical software anomaly information;

[0015] Obtain software interface information corresponding to historical software anomaly information with a risk level greater than a preset threshold, and obtain software interface information that meets the preset risk conditions.

[0016] In one embodiment, obtaining the corresponding function call relationship information based on the software interface information includes:

[0017] The called interface information corresponding to the software interface information is detected by the bytecode instrumentation plugin;

[0018] Based on the called function corresponding to the called interface information and the function corresponding to the software interface information, function call relationship information is obtained.

[0019] In one embodiment, obtaining function call relationship information based on the called function corresponding to the called interface information and the function corresponding to the software interface information includes:

[0020] Obtain the called class name, called method name, and called parameters of the called function;

[0021] Obtain the class name, method name, parent class, parameters, and interface list of the function corresponding to the software interface information;

[0022] Based on the association between the class name, method name, parent class, parameter and interface list and the called class name, called method name and called parameters, a corresponding call tree is generated as function call relationship information.

[0023] In one embodiment, the step of obtaining the corresponding software anomaly risk scanning logic based on the function call relationship information includes:

[0024] Obtain the software anomaly risk type and the corresponding business information for the function call relationship information input;

[0025] The software anomaly risk scanning logic is derived based on the software anomaly risk type and the business information.

[0026] In one embodiment, the anomaly risk scanning toolkit is further used for:

[0027] During the compilation of the development project, candidate code nodes with software anomaly risks are detected in the software to be tested according to the software anomaly risk scanning logic;

[0028] For each candidate code node, if it is detected that there is no security protection strategy for the software anomaly risk in the candidate code node, the candidate code node is determined to be the target code node.

[0029] The software anomaly risk scan results are obtained based on information from at least one target code node.

[0030] In one embodiment, after generating the anomaly risk scanning toolkit according to the software anomaly risk scanning logic, the method further includes:

[0031] Obtain at least one code node from the software anomaly risk scan results; the at least one code node corresponds to at least one business type;

[0032] For each code node, the code node information is uploaded to the software anomaly risk handling center corresponding to the business type of that code node, so that the software anomaly risk handling center can perform software anomaly risk repair on that code node.

[0033] Secondly, this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0034] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0035] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0036] The aforementioned software anomaly risk detection method, computer equipment, storage medium, and computer program product acquire software interface information of the software under test that meets preset risk conditions. Based on this information, they obtain function call relationship information, derive software anomaly risk scanning logic, and generate an anomaly risk scanning toolkit. During software development and compilation, this toolkit scans for software anomalies and risks, outputting the scanning results. Compared to traditional methods that rely on manual execution of test cases, this approach improves the comprehensiveness of software anomaly risk detection by performing a risk scan on the compiling software before testing, using scanning logic generated based on function call relationships. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating a software anomaly risk detection method in one embodiment;

[0038] Figure 2 This is a flowchart illustrating the software anomaly risk detection steps in one embodiment;

[0039] Figure 3 This is a flowchart illustrating the scanning steps in one embodiment;

[0040] Figure 4 This is a flowchart illustrating a software anomaly risk detection method in another embodiment;

[0041] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0043] In one embodiment, such as Figure 1 As shown, a software anomaly risk detection method is provided. This embodiment illustrates the method by applying it to a terminal. It is understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. The method includes the following steps:

[0044] Step S202: Obtain software interface information of the software to be tested that meets the preset risk conditions.

[0045] The software to be tested can be any software requiring anomaly risk detection, such as a singing app. Software anomaly risk detection refers to detecting potential risks within the software. This detection can be at the code level, identifying code that might cause software anomalies, such as software interface information that could lead to crashes. Software interface information includes, but is not limited to, API (Application Programming Interface) information. The terminal can obtain software interface information that meets preset risk conditions during the code development phase. These preset risk conditions can be pre-determined based on the risk level of the software interface information. Therefore, the terminal can identify software anomaly risks during the compilation phase before actual testing, thus improving the comprehensiveness of software anomaly risk detection.

[0046] Step S204: Obtain the corresponding function call relationship information based on the software interface information.

[0047] In software, various functions, also known as methods, can implement corresponding functionalities. These functions can be called through interfaces, thus establishing call relationships between them. After obtaining software interface information that meets preset risk conditions, the terminal can retrieve the corresponding function call relationship information based on this information. For example, the terminal can parse the functions associated with each software interface to obtain the corresponding function call relationship information.

[0048] Step S206: Based on the function call relationship information, obtain the corresponding software anomaly risk scanning logic.

[0049] The function call relationship information represents the call relationships between various functions in the software under test. Since software can generate exceptions due to incorrect function calls, such as an IllegalStateException which can cause software crashes, the terminal needs to utilize the function call relationship information to detect potential anomalies in the software.

[0050] IllegalStateException is an exception class in the Java programming language, typically representing an exception caused by performing an operation or method call at an inappropriate time or in an inappropriate context, i.e., due to logical errors in the code or incorrect use of methods or operations. Usually, it is caused by the misuse of an object or the accidental modification of its state. For example, because Android does not allow time-consuming operations to be performed on the main thread, attempting to do so will throw an IllegalStateException; or, in some cases, when an Activity has been destroyed but a view is still accessed, the software will throw an IllegalStateException; and, if a Fragment (a fragment within an Activity) has not been added to the Activity, attempting to access the Fragment or perform operations related to it will throw an IllegalStateException.

[0051] Because the aforementioned software anomalies are easily overlooked during testing, the terminal can use the acquired function call relationship information to derive the software anomaly risk scanning logic for the software under test. This software anomaly risk scanning logic can be determined based on the call relationships between functions within the function call relationship information. For example, by classifying functions according to business functions, it can analyze whether there are call defects between the functions corresponding to each business function and their corresponding called functions, thereby determining how to scan for software anomaly risks in the software under test. In some embodiments, the aforementioned function call relationship information can be analyzed by relevant technical personnel, and the corresponding software anomaly risk scanning logic can be input into the terminal.

[0052] Step S208: Generate an anomaly risk scanning toolkit according to the software anomaly risk scanning logic; the anomaly risk scanning toolkit is used to import the development project of the software to be tested, scan the software anomaly risks of the software to be tested according to the software anomaly risk scanning logic during the compilation of the development project, and output the software anomaly risk scanning results.

[0053] The terminal can utilize the aforementioned software anomaly risk scanning logic to generate a corresponding anomaly risk scanning toolkit. This toolkit may include detection functions rewritten using the software anomaly risk scanning logic to scan for anomalies in the software code. The terminal can then import the generated toolkit into the development project of the software to be tested. During the compilation phase of the development project, the toolkit can scan for software anomalies in the software according to the scanning logic and output the scan results. These results may include information about defective code within the software that could cause anomalies.

[0054] The code of the software to be tested may contain code corresponding to multiple services. For different services, the terminal can process the software anomaly risk scan results accordingly. For example, in one embodiment, the software anomaly risk scan results include multiple code nodes, and the terminal can obtain information on at least one code node from the scan results. Each code node corresponds to at least one service type. For each code node, the terminal can upload it to the software anomaly risk processing center corresponding to that service type, so that the center can perform software anomaly risk repair. The software anomaly risk scan results may include code nodes corresponding to multiple service types.

[0055] Specifically, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating the software anomaly risk detection steps in one embodiment. The terminal can retrieve an ASM (Bytecode Instrumentation) plugin from the server using a configuration file. This plugin participates in project compilation and outputs function call relationship information (also known as the function call chain) in the software under test. A scanning pipeline is configured on the terminal, for example, by pulling the project code of the software under test through a Git plugin and defining custom rules using lint (Static Language Testing). An anomaly risk scanning toolkit, including a JAR file and corresponding XML files, is generated by compiling these static code rules. The toolkit is then imported into the project to execute the scanning task and generate corresponding software anomaly risk scanning results, such as a scan report. Furthermore, the terminal can identify defective code corresponding to each business type in the software anomaly risk scanning results and submit the corresponding defective code information to the corresponding business code submission center (i.e., the anomaly risk processing center for the aforementioned business type) via incremental bug reports. This allows for risk remediation of defective code with anomaly risks through bug reports, proactively addressing software anomaly issues caused by function call defects in the software.

[0056] The aforementioned software anomaly risk detection method obtains software interface information of the software under test that meets preset risk conditions. Based on this information, function call relationships are derived. Software anomaly risk scanning logic is then generated based on this logic. An anomaly risk scanning toolkit is generated based on this logic. During software development and compilation, the toolkit scans for software anomalies and risks, and the scanning results are output. Compared to traditional methods that rely on manual execution of test cases, this approach improves the comprehensiveness of software anomaly risk detection by performing a risk scan on the compiling software before testing, using scanning logic generated based on function call relationships.

[0057] In one embodiment, obtaining software interface information that meets preset risk conditions corresponding to the software under test includes: obtaining historical software anomaly information corresponding to the software under test; the historical software anomaly information includes information on software anomalies generated in historical versions of the software under test; and obtaining software interface information that meets preset risk conditions based on the historical software anomaly information.

[0058] In this embodiment, the terminal can determine the software interface information that meets the preset risk conditions by combining the historical software anomaly information of the software under test. The historical software anomaly information may include information about software anomalies generated in previous versions of the software under test. Therefore, after obtaining the historical software anomaly information corresponding to the software under test, the terminal can obtain the software interface information that meets the preset risk conditions based on the historical software anomaly information.

[0059] The aforementioned preset risk conditions can be determined based on the risk level of each historical software anomaly. For example, in one embodiment, the terminal can acquire multiple risk levels corresponding to multiple historical software anomaly information, and acquire software interface information corresponding to historical software anomaly information with a risk level greater than a preset threshold. Thus, the terminal can obtain software interface information that satisfies the preset risk conditions based on the software interface information corresponding to the historical software anomaly information with a risk level greater than the preset threshold. The aforementioned risk level can be determined based on preset risk judgment rules, which can be pre-set by relevant technical personnel.

[0060] Specifically, taking a singing software as an example, where the software exception risk is IllegalStateException, the terminal can obtain IllegalStateException exceptions from all historical versions of the singing software. By analyzing the risk level of each exception, the terminal compiles the software interface information corresponding to IllegalStateException exceptions with a risk level greater than a preset threshold into a document of risky software interfaces. This software interface information may include method names and corresponding class names. The document may also include the discovery stage of historical software exceptions, such as functional testing, system testing, external network testing, and gray-scale testing. The document also includes the exception type, such as the aforementioned IllegalStateException exception, and detailed links to the software exception information, including the number of times the exception was triggered, the result caused by the exception, the type of business that experienced the exception, and the number of users affected. Furthermore, in some embodiments, the document may also include information on the historical handling process of the exception by relevant technical personnel when it occurred. Thus, the terminal can utilize the various software interface information obtained based on historical exception information to determine the function call relationships corresponding to each software interface, and then perform exception risk detection on the singing software under test based on these function call relationship information.

[0061] Through the above embodiments, the terminal can determine the software interface information with higher risk based on the risk level of the historical software anomaly information of the software under test. Thus, the terminal can perform software anomaly risk detection on the software under test based on the software interface information, and can detect the anomaly risks of the software under test before actual testing, thereby improving the comprehensiveness of risk detection.

[0062] In one embodiment, obtaining the corresponding function call relationship information based on the software interface information includes: detecting the called interface information corresponding to the software interface information through a bytecode instrumentation plugin; and obtaining the function call relationship information based on the called function corresponding to the called interface information and the function corresponding to the software interface information.

[0063] In this embodiment, the terminal can utilize software interface information to determine the calling relationships between various functions in the software to be tested. Specifically, the terminal can pre-introduce an ASM (Bytecode Instrumentation) plugin via a configuration file. This allows the terminal to detect the called interface information corresponding to the aforementioned software interface information. The called interface information represents the interface information of the functions directly called by the function corresponding to the software interface information. The terminal can obtain the called functions corresponding to the called interface information and, based on these called functions and the functions corresponding to the software interface information, obtain function call relationship information.

[0064] The aforementioned function call relationship information may include information about the called function and information about the function corresponding to the software interface information. For example, in one embodiment, when the terminal outputs function call relationship information based on the called function and the function corresponding to the software interface information, it can obtain the called class name, called method name, and called parameters of the called function. The called class name, called method name, and called parameters respectively represent the class name, method name, and parameters of the called function that are called by the function corresponding to the software interface information. The terminal can also obtain the class name, method name, parent class, parameters, and interface list of the function corresponding to the software interface information, and generate a corresponding call tree as the function call relationship information based on the association between the class name, method name, parent class, parameters, and interface list and the called class name, called method name, and called parameters. The interface list can represent the interface information contained in the function corresponding to the software interface information. The aforementioned function call relationship information can be a function call relationship chain, presented in a tree structure.

[0065] Specifically, for each software interface information, the terminal can use the aforementioned bytecode instrumentation plugin to obtain the function itself corresponding to the software interface information and related information between functions, and generate a corresponding text file. This text file contains the relationship between the function corresponding to the software interface information and the functions it directly calls. This relationship can be presented in a tree structure, for example, in the form of "Class A -- Function A -- Parameter A -- Parent Class A -- Interface List A {Class B -- Called Function B -- Parameter B, Class C -- Called Function C -- Parameter C, ...}". Here, A represents the function corresponding to the software interface information, and B and C represent the called functions directly called by the function corresponding to the software interface information. Thus, the terminal can obtain the function call relationship information based on the above relationship.

[0066] Through the above embodiments, the terminal can obtain the call relationship between functions through the bytecode instrumentation plugin, and then analyze the software anomaly risk in the software under test based on the generated function call relationship information, thereby improving the comprehensiveness of software anomaly risk detection.

[0067] In one embodiment, the corresponding software anomaly risk scanning logic is obtained based on function call relationship information, including: obtaining the software anomaly risk type input for the function call relationship information and the business information corresponding to the software risk type; and obtaining the software anomaly risk scanning logic based on the software anomaly risk type and the business information.

[0068] In this embodiment, the terminal can utilize the aforementioned function call relationship information to determine the scanning logic for software anomaly risks. The function call relationship information can correspond to multiple types of software anomaly risks. The terminal can obtain the software anomaly risk types input by relevant technical personnel regarding the function call relationship information, as well as the corresponding business information. The software risk type represents a risk type present in the function call relationship information that may cause the software under test to malfunction. The corresponding business information represents the business information of the business that generates the anomaly risk function of that software risk type within the function call relationship information. That is, the function call relationship information can include code nodes for multiple business processes and multiple software anomaly risk types. Therefore, the terminal can obtain the software anomaly risk scanning logic based on the aforementioned software anomaly risk types and business information.

[0069] Specifically, after determining the function call relationship information, the terminal can, according to the static scanning scheme, have relevant technical personnel analyze the call chain relationship of the software interface information within the function call relationship information. Then, using an AST (Abstract Syntax Tree) framework, they can develop custom static code analysis scanning rule logic. This logic determines the software anomaly risk scanning logic, allowing the terminal to generate an anomaly risk scanning toolkit. Here, AST is a data structure used in the compilation process of a programming language. It is an intermediate representation of source code in the compiler, used for semantic analysis, optimization, and code generation during compilation. AST typically represents the syntactic structure of a program in a tree structure, with each node representing a syntactic unit in the program.

[0070] When determining the software anomaly risk scanning logic, the types of software anomalies and risks need to be predefined. These types can be input by relevant technical personnel based on function call relationship information. For example, the terminal obtains the error types and related information defined by the technical personnel based on function call relationship information. Taking the error type "IllegalStateException" as an example, the error type information includes, but is not limited to, the node identifier where the IllegalStateException occurred, the node name (e.g., function name), the explanation information for the IllegalStateException, the priority of the IllegalStateException, and the risk level of the IllegalStateException. Each function in the aforementioned function call relationship information can include multiple code nodes. The terminal can also determine the type of code node to be acquired based on the aforementioned software anomaly risk types. This code node type can represent a node with a software anomaly risk. Thus, the terminal can obtain the rewrite information of the scanning function based on the code node type determined by the technical personnel based on the static scanning scheme. For example, if the scanning function is "getApplicableUastTypes()", the terminal can determine the type of code node to be scanned by obtaining the rewrite information for this scanning function. Thus, the terminal can generate a corresponding anomaly risk scanning toolkit based on the above scanning functions, software anomaly risk types and their corresponding business information.

[0071] Through this embodiment, the terminal can obtain the software anomaly risk scanning logic based on function call relationship information, and then generate a corresponding anomaly risk scanning toolkit based on the software anomaly risk scanning logic. This toolkit can be used to accurately scan for defective code with anomaly risks in the software to be tested at the compilation node, thereby improving the comprehensiveness of software anomaly risk detection.

[0072] In one embodiment, the anomaly risk scanning toolkit is further used to: during the compilation of the development project, detect candidate code node information in the software to be detected that has software anomaly risk according to the software anomaly risk scanning logic; for each candidate code node information, if it is detected that there is no security protection strategy for software anomaly risk in the candidate code node information, determine the candidate code node information as target code node information; and obtain the software anomaly risk scanning result based on at least one target code node information.

[0073] In this embodiment, after the terminal generates the aforementioned anomaly risk scanning toolkit, it can be imported into the development project of the software to be tested. During the compilation of the development project, the software anomaly risk scanning logic within the toolkit detects candidate code nodes in the software to be tested that contain software anomaly risks. The anomaly risk scanning toolkit can scan for multiple candidate code nodes. For each candidate code node, the toolkit can detect whether a security protection strategy for the software anomaly risk exists. If not, the toolkit determines that the candidate code node is a target code node, i.e., information related to defective code containing anomaly risks. Therefore, through this toolkit, the terminal can obtain software anomaly risk scanning results based on at least one target code node.

[0074] Specifically, the process of generating the toolkit and scanning on the terminal can be as follows: Figure 3 As shown, Figure 3 This is a flowchart illustrating the scanning steps in one embodiment. The terminal first organizes software interface information that meets preset risk conditions, and obtains function call relationship information through a bytecode instrumentation plugin. Simultaneously, the terminal can output and store this function call relationship information as a text document. The terminal can obtain software anomaly risk types and their corresponding business information input by relevant technical personnel through parsing the function call relationship information. Furthermore, the terminal can derive software anomaly risk scanning logic based on these software anomaly risk types and their corresponding business information, and further generate an anomaly risk scanning toolkit, which can be a toolkit in JAR (archived) format.

[0075] The function call relationship information obtained by the aforementioned bytecode instrumentation plugin can also include top-level business function information for each function call chain. This allows the terminal to scan each code node of the software under test using the anomaly risk detection toolkit, based on rules developed using the business function information, to obtain code nodes corresponding to the business type. For example, the terminal can use the `visitCallExpression()` function in the anomaly risk scanning toolkit to traverse the code nodes of the software under test. After scanning the corresponding target code node based on the aforementioned software anomaly risk scanning logic, it can call back the `visitCallExpression()` method and use the anomaly risk scanning toolkit to determine whether the scanned target code node has security protection, such as security protection strategies for existing software anomalies. Target code nodes without security protection are considered defective code. The terminal can then use the anomaly risk scanning toolkit to generate a corresponding scan report using the relevant information of the scanned defective code, serving as the software anomaly risk scanning result.

[0076] The defect code in the aforementioned scan report may include various information, such as the function name, interface name, call relationship information, and business type of the defect code. The terminal can also submit the aforementioned scan report to the software anomaly risk handling center corresponding to the business type of the defect code in the report for anomaly risk handling through incremental order submission.

[0077] Through this embodiment, the terminal can utilize the anomaly risk scanning toolkit to perform a traversal scan of the code nodes in the software under test based on the corresponding scanning logic during the code compilation stage. This allows the terminal to identify defective code with anomaly risks in the software under test, thereby improving the comprehensiveness of software anomaly risk detection.

[0078] In one embodiment, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating a software anomaly risk detection method in another embodiment. In this embodiment, taking the IllegalStateException exception as an example, the terminal can formulate a scanning plan for the software to be detected, addressing the software crash problem caused by the IllegalStateException. For the software to be detected, the terminal can first obtain software interface information that meets preset risk conditions, such as software interface information with a risk level greater than a preset threshold, and then introduce an ASM plugin. Through the ASM plugin and the aforementioned software interface information, the terminal obtains the corresponding function call relationship information, specifically the function call chain.

[0079] The terminal can also obtain software anomaly risk scanning logic input by relevant technical personnel after parsing the aforementioned function call relationship information. For example, through the aforementioned custom rules using lint (static code analysis), an anomaly risk scanning toolkit can be generated by compiling static code rules, specifically including a static code analysis JAR package and corresponding static code analysis XML files. The terminal can import the anomaly risk scanning toolkit into the project, execute the scanning task, and generate corresponding software anomaly risk scanning results, such as a scan report. The scan report can include information such as the defective code of the software under test detected by the anomaly risk scanning toolkit. Therefore, the terminal can call the automatic order submission interface to upload the scan report to the software anomaly risk processing center that handles the corresponding business type, according to the business type of the defective code, thus following up on the improvement of risky defective code through order submission.

[0080] In addition, in some embodiments, the terminal can also automatically trigger software anomalies corresponding to detected defective code nodes through an anomaly risk scanning toolkit. For example, when the anomaly risk scanning toolkit scans for a defective code node, it can obtain the software anomaly corresponding to that defective code. Thus, the anomaly risk scanning toolkit can actually trigger the software anomaly and record and store the triggering information of the software anomaly, improving the reliability of software anomaly risk scanning and thereby improving the efficiency of handling software anomaly risks.

[0081] Through the above embodiments, before software testing, the terminal performs a risk scan on the compiled software using scanning logic generated based on the function call relationships within the software, identifying software anomaly risks and improving the comprehensiveness of software anomaly risk detection. Furthermore, by utilizing the anomaly risk scanning toolkit to scan for defective code in the software engineering during the compilation stage, the timeliness of software anomaly risk detection is improved. Additionally, by developing the ASM plugin, static code scanning, and the software under test independently, the cost of adapting this software anomaly detection method to other projects is reduced, improving the portability of software anomaly risk detection.

[0082] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0083] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a software anomaly risk detection method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device casing, or an external keyboard, touchpad, or mouse.

[0084] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0085] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described software anomaly risk detection method.

[0086] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described software anomaly risk detection method.

[0087] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the software anomaly risk detection method described above.

[0088] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0089] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0090] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0091] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method of software exception risk detection, the method comprising: The method includes: Obtain software interface information of the software to be tested that meets the preset risk conditions; Based on the software interface information, obtain the corresponding function call relationship information; Based on the function call relationship information, the corresponding software anomaly risk scanning logic is obtained; Based on the software anomaly risk scanning logic, an anomaly risk scanning toolkit is generated. This toolkit is used to import the development project of the software to be tested. During the compilation of the development project, it scans the software anomaly risk of the software to be tested according to the software anomaly risk scanning logic and outputs the software anomaly risk scanning results. Further, during the compilation of the development project, it is used to detect candidate code node information in the software to be tested that contains software anomaly risks according to the software anomaly risk scanning logic. For each candidate code node information, if no security protection strategy for the software anomaly risk is detected in the candidate code node information, the candidate code node information is determined as target code node information. The software anomaly risk scanning results are obtained based on at least one target code node information.

2. The method of claim 1, wherein, The acquisition of software interface information that meets preset risk conditions corresponding to the software to be tested includes: Obtain historical software anomaly information corresponding to the software to be tested; the historical software anomaly information includes information about software anomalies that occurred in historical versions of the software to be tested. Based on the historical software anomaly information, obtain software interface information that meets preset risk conditions.

3. The method of claim 2, wherein, The step of obtaining software interface information that meets preset risk conditions based on the historical software anomaly information includes: Obtain multiple risk levels corresponding to multiple historical software anomaly information; Obtain software interface information corresponding to historical software anomaly information with a risk level greater than a preset threshold, and obtain software interface information that meets the preset risk conditions.

4. The method of claim 1, wherein, The step of obtaining the corresponding function call relationship information based on the software interface information includes: The called interface information corresponding to the software interface information is detected by the bytecode instrumentation plugin; Based on the called function corresponding to the called interface information and the function corresponding to the software interface information, function call relationship information is obtained.

5. The method of claim 4, wherein, The step of obtaining function call relationship information based on the called function corresponding to the called interface information and the function corresponding to the software interface information includes: Obtain the called class name, called method name, and called parameters of the called function; Obtain the class name, method name, parent class, parameters, and interface list of the function corresponding to the software interface information; Based on the association between the class name, method name, parent class, parameter and interface list and the called class name, called method name and called parameters, a corresponding call tree is generated as function call relationship information.

6. The method of claim 1, wherein, The step of obtaining the corresponding software anomaly risk scanning logic based on the function call relationship information includes: Obtain the software exception risk type and the corresponding business information for the function call relationship information input; The software anomaly risk scanning logic is derived based on the software anomaly risk type and the business information.

7. The method according to any one of claims 1 to 6, characterized in that, After generating the anomaly risk scanning toolkit according to the software anomaly risk scanning logic, the method further includes: Obtain at least one code node from the software anomaly risk scan results; the at least one code node corresponds to at least one business type; For each code node, the code node information is uploaded to the software anomaly risk handling center corresponding to the business type of that code node, so that the software anomaly risk handling center can perform software anomaly risk repair on that code node.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images