Document testing methods, apparatus, electronic devices, and program products

Abstract

This application provides a file testing method, apparatus, electronic device, and program product, relating to the field of computer technology. The method includes: inputting a first file to be run into a pre-created first runtime environment, and running the first file in the first runtime environment; acquiring multiple first actions executed during the execution of the first file, and first parameter information of the first runtime environment; identifying a first abnormal action among the multiple first actions, and identifying a second abnormal action based on the first parameter information; determining a first repair strategy for the first file based on the first and second abnormal actions; and repairing the first file based on the first repair strategy to obtain a second file. This can improve the efficiency of script testing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a document testing method, apparatus, electronic device, and program product. Background Technology

[0002] In automated operation and maintenance scenarios of operating systems (such as server cluster maintenance, network device configuration distribution, etc.), batch (BAT) scripts can be used to perform high-frequency operations such as batch file processing, service start-up and shutdown, and log cleanup. Before running BAT scripts in the operating system, BAT scripts need to be tested.

[0003] Currently, during the testing of BAT scripts, when abnormal behavior occurs (such as infinite loops, resource leaks, etc.), manual intervention is required to investigate the cause of the abnormality and modify the BAT script. However, the above method has low testing efficiency for BAT scripts. Summary of the Invention

[0004] This application provides a document testing method, apparatus, electronic device, and program product to improve the efficiency of testing scripts.

[0005] In a first aspect, embodiments of this application provide a document testing method, including:

[0006] The first file to be run is input into the pre-created first runtime environment, and the first file is run in the first runtime environment;

[0007] Obtain the first actions executed during the execution of the first file, as well as the first parameter information of the first execution environment;

[0008] Among multiple first behaviors, a first abnormal behavior is determined, and a second abnormal behavior is determined based on the first parameter information;

[0009] Based on the first abnormal behavior and the second abnormal behavior, determine the first repair strategy for the first file;

[0010] Based on the first repair strategy, the first file is repaired to obtain the second file.

[0011] In one possible implementation, among a plurality of first behaviors, determining a first anomalous behavior includes:

[0012] Get multiple preset abnormal behaviors;

[0013] For each of the multiple first behaviors, match the first behavior with multiple abnormal behaviors;

[0014] If the first behavior is the same as any abnormal behavior, then the first behavior is identified as the first abnormal behavior.

[0015] In one possible implementation, determining the second abnormal behavior based on the first parameter information includes:

[0016] Obtain multiple preset parameter conditions;

[0017] Based on each parameter in the first parameter information, determine the parameter condition corresponding to the parameter from multiple preset parameter conditions;

[0018] If the parameter does not meet the corresponding parameter conditions, the behavior associated with the parameter will be identified as the second abnormal behavior.

[0019] In one possible implementation, a first repair strategy for the first file is determined based on the first abnormal behavior and the second abnormal behavior, including:

[0020] Determine the type of the first abnormal behavior and the type of the second abnormal behavior;

[0021] Determine the behavioral information corresponding to the first and second abnormal behaviors. The behavioral information includes the cause of the behavior and the result of the behavior.

[0022] Based on the type of the first abnormal behavior, the type of the second abnormal behavior, the behavior information corresponding to the first abnormal behavior, and the behavior information corresponding to the second abnormal behavior, a first repair strategy for the first file is determined.

[0023] In one possible implementation, determining the type of the first abnormal behavior and the type of the second abnormal behavior includes:

[0024] Obtain the log file and the first rule base. The log file includes the first abnormal behavior and the second abnormal behavior. The first rule base includes multiple preset abnormal behavior types.

[0025] The type of the first abnormal behavior is obtained by matching the first abnormal behavior in the log file with the types of multiple abnormal behaviors in the first rule base.

[0026] The type of the second abnormal behavior is obtained by matching the second abnormal behavior in the log file with the types of multiple abnormal behaviors in the first rule base.

[0027] In one possible implementation, determining the behavioral information corresponding to the first abnormal behavior and the second abnormal behavior includes:

[0028] The log files were analyzed to obtain the behavioral information corresponding to the first and second abnormal behaviors.

[0029] In one possible implementation, after repairing the first file based on the first repair strategy to obtain the second file, the method further includes:

[0030] The second file is run in the first runtime environment;

[0031] Obtain multiple third actions executed during the execution of the second file, as well as the second parameter information of the first execution environment;

[0032] Based on multiple third behaviors and second parameter information, determine whether there are any third abnormal behaviors during the execution of the second file;

[0033] In the event of a third abnormal behavior, a second repair strategy for the second file is determined based on the third abnormal behavior, and the second file is repaired based on the second repair strategy to obtain the third file;

[0034] If no third abnormal behavior is found, save the second file.

[0035] Secondly, embodiments of this application provide a document testing apparatus, comprising: a first processing module, an acquisition module, a first determining module, a second determining module, and a second processing module, wherein...

[0036] The first processing module is used to input the first file to be run into the pre-created first running environment, and to run the first file in the first running environment;

[0037] The acquisition module is used to acquire multiple first actions executed during the execution of the first file, as well as the first parameter information of the first execution environment;

[0038] The first determining module is used to determine a first abnormal behavior among multiple first behaviors, and to determine a second abnormal behavior based on first parameter information;

[0039] The second determining module is used to determine the first repair strategy for the first file based on the first abnormal behavior and the second abnormal behavior.

[0040] The second processing module is used to repair the first file based on the first repair strategy to obtain the second file.

[0041] The document testing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0042] In one possible implementation, the first determining module is specifically used for:

[0043] Get multiple preset abnormal behaviors;

[0044] For each of the multiple first behaviors, match the first behavior with multiple abnormal behaviors;

[0045] If the first behavior is the same as any abnormal behavior, then the first behavior is identified as the first abnormal behavior.

[0046] In one possible implementation, the first determining module is specifically used for:

[0047] Obtain multiple preset parameter conditions;

[0048] Based on each parameter in the first parameter information, determine the parameter condition corresponding to the parameter from multiple preset parameter conditions;

[0049] If the parameter does not meet the corresponding parameter conditions, the behavior associated with the parameter will be identified as the second abnormal behavior.

[0050] In one possible implementation, the second determining module is specifically used for:

[0051] Determine the type of the first abnormal behavior and the type of the second abnormal behavior;

[0052] Determine the behavioral information corresponding to the first and second abnormal behaviors. The behavioral information includes the cause of the behavior and the result of the behavior.

[0053] Based on the type of the first abnormal behavior, the type of the second abnormal behavior, the behavior information corresponding to the first abnormal behavior, and the behavior information corresponding to the second abnormal behavior, a first repair strategy for the first file is determined.

[0054] In one possible implementation, the second determining module is specifically used for:

[0055] Obtain the log file and the first rule base. The log file includes the first abnormal behavior and the second abnormal behavior. The first rule base includes multiple preset abnormal behavior types.

[0056] The type of the first abnormal behavior is obtained by matching the first abnormal behavior in the log file with the types of multiple abnormal behaviors in the first rule base.

[0057] The type of the second abnormal behavior is obtained by matching the second abnormal behavior in the log file with the types of multiple abnormal behaviors in the first rule base.

[0058] In one possible implementation, the second determining module is specifically used for:

[0059] The log files were analyzed to obtain the behavioral information corresponding to the first and second abnormal behaviors.

[0060] In one possible implementation, the document testing apparatus further includes a third processing module, which is used for:

[0061] The second file is run in the first runtime environment;

[0062] Obtain multiple third actions executed during the execution of the second file, as well as the second parameter information of the first execution environment;

[0063] Based on multiple third behaviors and second parameter information, determine whether there are any third abnormal behaviors during the execution of the second file;

[0064] In the event of a third abnormal behavior, a second repair strategy for the second file is determined based on the third abnormal behavior, and the second file is repaired based on the second repair strategy to obtain the third file;

[0065] If no third abnormal behavior is found, save the second file.

[0066] Thirdly, embodiments of this application provide an electronic device, including: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to perform the file testing method as described in the first aspect and various possible designs of the first aspect.

[0067] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the file testing method described in the first aspect and various possible designs of the first aspect.

[0068] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the first aspect and various possible designs of the first aspect as described above, and a file testing method.

[0069] In a sixth aspect, embodiments of this application provide a chip, the chip including at least one processor, the processor being configured to execute program instructions to implement the first aspect as described above and the document testing method for various possible designs of the first aspect.

[0070] This application provides a file testing method, apparatus, electronic device, and program product. By running a first file to be tested in a pre-created first running environment, it synchronously collects multiple first behaviors and first parameter information executed during the execution of the first file. It automatically identifies the first abnormal behavior at the behavior level and the second abnormal behavior at the parameter level in a two-dimensional manner, and then determines the repair strategy and completes the script repair in a targeted manner. This can realize the full automation of the anomaly detection and repair process, reduce labor costs, and improve the efficiency of script testing. Attached Figure Description

[0071] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0072] Figure 1 A flowchart illustrating a document testing method provided in an embodiment of this application;

[0073] Figure 2 A flowchart illustrating a method for determining a first repair strategy provided in an embodiment of this application;

[0074] Figure 3 This is a schematic diagram of the structure of a document testing device provided in an embodiment of this application;

[0075] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0076] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0077] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0078] 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. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0079] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0080] It should be noted that the document testing method, apparatus, electronic device and program product provided in this application can be used in the field of computer technology, or in any field other than computer technology. The application field of the document testing method, apparatus, electronic device and program product in this application is not limited.

[0081] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0082] In automated operation and maintenance scenarios of operating systems (such as server cluster maintenance, network device configuration distribution, etc.), BAT scripts can be used to perform high-frequency operations such as batch file processing, service start-up and shutdown, and log cleanup. Before running BAT scripts in the operating system, BAT scripts need to be tested.

[0083] Currently, during the testing of BAT scripts, when abnormal behavior occurs (such as infinite loops, resource leaks, etc.), manual intervention is required to investigate the cause of the abnormality and modify the BAT script. However, the above method has low testing efficiency for BAT scripts.

[0084] To address the aforementioned issues, this application provides a file testing method, which involves inputting a first file to be run into a pre-created first runtime environment and running the first file within that environment; acquiring multiple first actions executed during the execution of the first file, as well as first parameter information of the first runtime environment; identifying a first abnormal action among the multiple first actions, and identifying a second abnormal action based on the first parameter information; determining a first repair strategy for the first file based on the first and second abnormal actions; and repairing the first file based on the first repair strategy to obtain a second file.

[0085] In the above method, by running the first file to be tested in a pre-created first running environment, the first behavior and first parameter information executed during the execution of the first file are collected synchronously. The first abnormal behavior at the behavior level and the second abnormal behavior at the parameter level are automatically identified in two dimensions. Then, the repair strategy is determined in a targeted manner and the script is repaired. This can realize the full automation of the anomaly detection and repair process, reduce manual costs, and improve the efficiency of testing scripts.

[0086] Furthermore, by testing the first file in the first runtime environment, the impact on the real operating system during the test can be avoided (such as operating system crashes or data loss caused by accidental operation), thereby improving the security of script testing; by automatically determining the repair strategy and repairing the first file, the script testing process can be less affected by environmental changes (such as network data fluctuations or system configuration updates), thereby improving the success rate of script testing.

[0087] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0088] Figure 1 This is a flowchart illustrating a document testing method provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 As shown, the method may include the following steps:

[0089] S101. Input the first file to be run into the pre-created first running environment, and run the first file in the first running environment.

[0090] The execution subject of this application embodiment can be an electronic device or a file testing device installed in an electronic device. The file testing device can be implemented by software or by a combination of software and hardware.

[0091] In one possible implementation, the first file is the target file to be run. The first file can be understood as the BAT script mentioned in the above embodiments. The BAT script includes multiple disk operating system (DOS) commands and executable program instructions. The BAT script is used to implement automated batch operations.

[0092] In one possible implementation, the first runtime environment is a pre-created test environment used to isolate and run the first file. The first runtime environment can be built based on virtualization or containerization technology, and has the characteristics of simulating the key configuration of a real operation and maintenance environment without affecting the real operating system.

[0093] In one possible implementation, the first runtime environment can be created before the first file to be run is input into the pre-created first runtime environment. The specific implementation method for creating the first runtime environment is as follows:

[0094] Based on the first file, the environment configuration that the first file depends on during runtime (such as registry access path, network protocol configuration, system directory mapping path, environment variable parameters, etc.) is determined. Then, the environment configuration is parsed, and an image is pulled through Docker Desktop. The environment configuration is replicated in the image to build a first runtime environment consistent with the real operating system. At the same time, the file system, registry state, process initialization information, etc. of the first runtime environment are stored to save the initial state of the first runtime environment. After the script is tested, the first runtime environment can be rolled back to the initial state to achieve environment isolation and reuse during the testing process.

[0095] It should be noted that during the execution of the first file in the first runtime environment, the directory structure of the real operating system mapped to the first runtime environment can be accessed to simulate the real runtime scenario. Furthermore, the write operations during the execution of the first file are all confined to the first runtime environment and will not modify or pollute the core configurations of the real operating system, such as the file system and registry.

[0096] In one possible implementation, quota restrictions can be imposed on the configuration resources of the first runtime environment. For example, the upper limit of CPU utilization, memory usage, and disk input / output (I / O) rate can be limited when the first file runs in the first runtime environment. This can avoid the risk of resource exhaustion caused by abnormal execution of the first file and ensure the stable operation of the first runtime environment and the host system.

[0097] S102. Obtain multiple first actions executed during the execution of the first file, as well as the first parameter information of the first execution environment.

[0098] In one possible implementation, the first action refers to the specific operations performed by the first file during runtime, including file operations, registry changes, service status modifications, network connection attempts, process creation, and other captureable actions.

[0099] In one possible implementation, the first parameter information refers to the system status data of the first running environment during the execution of the first file. The first parameter information can indicate the occupation of environment resources and the stability of operation. The first parameter information can include quantitative indicators such as CPU utilization, memory usage, disk I / O rate, script execution time, and process recursion depth.

[0100] In one possible implementation, a monitoring agent can be deployed in the first runtime environment, which can obtain multiple first behaviors in real time through a preset interface.

[0101] In one possible implementation, the first parameter information can be obtained in real time through a pre-defined code library (such as the Python System and Process Utilities (psutil)).

[0102] S103. Among multiple first behaviors, determine the first abnormal behavior, and based on the first parameter information, determine the second abnormal behavior.

[0103] In one possible implementation, the first abnormal behavior refers to an operation that may pose a risk to the system or fail to meet operational expectations. The first abnormal behavior includes, but is not limited to: removing folders, formatting, and deleting registry entries.

[0104] In one possible implementation, the second abnormal behavior refers to the abnormal resource consumption or abnormal running state of the first file in the first runtime environment. The second abnormal behavior includes, but is not limited to, infinite loops and disk space exhaustion.

[0105] In some implementations, determining the first abnormal behavior among multiple first behaviors may include:

[0106] Obtain multiple preset abnormal behaviors; for each of the multiple first behaviors, match the first behavior with the multiple abnormal behaviors; if the first behavior is the same as any of the abnormal behaviors, then determine the first behavior as the first abnormal behavior.

[0107] In one possible implementation, multiple preset abnormal behaviors can be obtained from a second rule base. The second rule base refers to a set of preset rules for anomaly determination, which is the core basis for identifying abnormal behaviors. The second rule base may include multiple preset abnormal behaviors, the risk level corresponding to each abnormal behavior, and multiple parameter conditions.

[0108] Among them, the risk level refers to the numerical index preset in the second rule base for each abnormal behavior to indicate the severity of the abnormality. The risk level can be set based on the degree of impact of the abnormal behavior on the system's security and stability. The higher the risk level, the greater the risk of the abnormality.

[0109] Among them, parameter conditions refer to the judgment criteria (including threshold range, numerical range, etc.) preset for the first parameter information in the second rule base, which are used to determine whether the parameter is within the normal operating range. Each parameter corresponds to a unique parameter condition, which is the core basis for determining the second abnormal behavior.

[0110] In one possible implementation, an alarm message can be issued based on the first abnormal behavior and the risk level corresponding to each first abnormal behavior can be obtained from the second rule base.

[0111] In another possible implementation, a fourth file can be input into the first runtime environment. The fourth file is used to indicate the function of the first file. The fourth file can include the risk level corresponding to the abnormal behavior performed by the first file. After the first abnormal behavior is determined, an alarm message can be issued based on the first abnormal behavior and its corresponding risk level in the fourth file.

[0112] In this way, by integrating preset abnormal behaviors, corresponding risk levels, and parameter conditions through the second rule base, multiple first behaviors of the first file are first matched with preset abnormal behaviors in the second rule base to determine the first abnormal behavior. Then, the risk level corresponding to the first abnormal behavior is obtained and an alarm is issued. This can realize the automated identification of the first abnormal behavior, replace manual investigation, and improve the efficiency of anomaly detection. Furthermore, by classifying the severity of abnormal behaviors by risk level, the alarms are more targeted, making it easier for operation and maintenance personnel to prioritize the handling of high-risk anomalies.

[0113] In some implementations, determining the second abnormal behavior based on the first parameter information may include:

[0114] Obtain multiple preset parameter conditions; based on each parameter in the first parameter information, determine the parameter condition corresponding to the parameter from the multiple preset parameter conditions; if the parameter does not meet the corresponding parameter condition, determine the behavior associated with the parameter as the second abnormal behavior.

[0115] In one possible implementation, multiple preset parameter conditions can be obtained from a second rule base.

[0116] For example, the parameter condition corresponding to the CPU utilization rate in the first parameter information is 0%-30%, the parameter condition corresponding to the memory utilization rate in the first parameter information is 0-2.5 gigabytes (GB), and the parameter condition corresponding to the execution time in the first parameter information is "less than or equal to 60 seconds".

[0117] In one possible implementation, for each parameter in the first parameter information, it can be determined whether each parameter meets the corresponding parameter conditions. If the parameter meets the corresponding parameter conditions (that is, the parameter is within the normal range defined by the parameter conditions), then the behavior associated with the parameter is determined to be normal; if the parameter does not meet the corresponding parameter conditions (that is, the parameter is not within the normal range defined by the parameter conditions), then the parameter is determined to not meet the corresponding parameter conditions, and the behavior associated with the parameter is determined to be the second abnormal behavior.

[0118] In this way, by accurately matching the corresponding parameter conditions for each parameter in the first parameter information to determine the second abnormal behavior, the second abnormal behavior can be identified automatically and in a standardized manner. This replaces the traditional method of manually monitoring resource parameters and checking for anomalies, improving detection efficiency and accuracy, and avoiding missed or incorrect judgments due to differences in human experience.

[0119] It should be noted that after identifying the first and second abnormal behaviors, the first and second abnormal behaviors can also be stored in the log file.

[0120] S104. Based on the first abnormal behavior and the second abnormal behavior, determine the first repair strategy for the first file.

[0121] In one possible implementation, the first repair strategy refers to a solution generated by combining the cause of the first abnormal behavior and the result of the second abnormal behavior. The first repair strategy is used to correct the logical defects or risky operations of the first file so that the repaired file meets the operational security and functional requirements.

[0122] S105. Based on the first repair strategy, repair the first file to obtain the second file.

[0123] In one possible implementation, the second file refers to the file obtained after the first file has been repaired by the first repair strategy. The second file may or may not have security. If the second file has security, it can be deployed to a real operating system for execution. If the second file does not have security, the second file can continue to be repaired until the repaired file has security, and then the repaired file can be deployed to a real operating system for execution.

[0124] In this embodiment, a first file to be run is input into a pre-created first running environment, and the first file is run in the first running environment; multiple first actions executed during the running of the first file and first parameter information of the first running environment are obtained; among the multiple first actions, a first abnormal action is determined, and a second abnormal action is determined based on the first parameter information; a first repair strategy for the first file is determined according to the first abnormal action and the second abnormal action; the first file is repaired based on the first repair strategy to obtain a second file.

[0125] In the above method, by running the first file to be tested in a pre-created first running environment, the first behavior and first parameter information executed during the execution of the first file are collected synchronously. The first abnormal behavior at the behavior level and the second abnormal behavior at the parameter level are automatically identified in two dimensions. Then, the repair strategy is determined in a targeted manner and the script is repaired. This can realize the full automation of the anomaly detection and repair process, reduce manual costs, and improve the efficiency of testing scripts.

[0126] Furthermore, by testing the first file in the first runtime environment, the impact on the real operating system during the test can be avoided (such as operating system crashes or data loss caused by accidental operation), thereby improving the security of script testing; by automatically determining the repair strategy and repairing the first file, the script testing process can be less affected by environmental changes (such as network data fluctuations or system configuration updates), thereby improving the success rate of script testing.

[0127] Next, combined Figure 2 The method for determining the first repair strategy is described. For example, Figure 2 A flowchart illustrating a method for determining a first repair strategy provided in an embodiment of this application is shown below. Figure 2 As shown, the method includes:

[0128] S201. Determine the type of the first abnormal behavior and the type of the second abnormal behavior.

[0129] In one possible implementation, the type of abnormal behavior refers to a classification definition of abnormal behavior, used to distinguish the nature of the abnormality (such as syntax error, logical error, resource abuse, etc.).

[0130] In some implementations, determining the type of the first abnormal behavior and the type of the second abnormal behavior includes:

[0131] Obtain the log file and the first rule base. The log file includes a first abnormal behavior and a second abnormal behavior. The first rule base includes multiple preset abnormal behavior types. Match the first abnormal behavior in the log file with the multiple abnormal behavior types in the first rule base to obtain the type of the first abnormal behavior. Match the second abnormal behavior in the log file with the multiple abnormal behavior types in the first rule base to obtain the type of the second abnormal behavior.

[0132] S202. Determine the behavioral information corresponding to the first and second abnormal behaviors. The behavioral information includes the cause of the behavior and the result of the behavior.

[0133] In one possible implementation, behavioral information refers to a set of data describing the specific details of abnormal behavior.

[0134] In some implementations, determining the behavioral information corresponding to the first and second abnormal behaviors includes analyzing log files to obtain the behavioral information corresponding to the first and second abnormal behaviors.

[0135] In one possible implementation, unstructured log files can be converted into structured data first, and then a large language model (LLM) can be used to perform deep semantic reasoning on the structured data to obtain the cause of the first abnormal behavior, the result of the first abnormal behavior, the cause of the second abnormal behavior, and the result of the second abnormal behavior.

[0136] S203. Based on the type of the first abnormal behavior, the type of the second abnormal behavior, the behavior information corresponding to the first abnormal behavior, and the behavior information corresponding to the second abnormal behavior, determine the first repair strategy for the first file.

[0137] In one possible implementation, an LLM model can be used to determine the first repair strategy for the first file based on the type of the first abnormal behavior, the type of the second abnormal behavior, the behavior information corresponding to the first abnormal behavior, and the behavior information corresponding to the second abnormal behavior.

[0138] For example, if the type of the second abnormal behavior is an infinite loop, then in the first rule base, it can be determined that the repair strategy corresponding to the infinite loop can be "insert timeout exit logic". Then, combined with the behavior information of the second abnormal behavior, the specific content of the timeout exit logic can be determined.

[0139] In this embodiment, the nature of the anomaly is first determined by matching the type of abnormal behavior. Then, the causes and consequences of the anomaly are explored through log structure transformation and deep semantic reasoning using an LLM model. Finally, a repair strategy is generated by combining the anomaly type and behavioral information. Furthermore, the basic repair direction can be matched with the first rule base and the strategy can be refined with specific information. This can improve the depth and accuracy of anomaly analysis, avoid the one-sidedness and inefficiency of manual analysis, reduce operation and maintenance costs, ensure the security and availability of the repaired files, and solve the problems of poor targeting and reliance on manual experience in traditional repair solutions.

[0140] Based on the above embodiments, after repairing the first file using the first repair strategy to obtain the second file, the following can also be done:

[0141] The second file is run in the first runtime environment; multiple third actions executed during the execution of the second file and the second parameter information of the first runtime environment are obtained; based on the multiple third actions and the second parameter information, it is determined whether there is a third abnormal action during the execution of the second file; if there is a third abnormal action, a second repair strategy for the second file is determined based on the third abnormal action, and the second file is repaired based on the second repair strategy to obtain the third file; if there is no third abnormal action, the second file is saved.

[0142] In one possible implementation, the second file refers to the intermediate file obtained after the first file has been repaired by the first repair strategy. Its core logic has been optimized for the first and second abnormal behaviors, but the repair effect and potential problems still need to be verified through running.

[0143] In one possible implementation, the third action refers to the specific operation performed by the second file when it runs in the first runtime environment. It has the same attributes as the first action, including file operations, registry changes, resource calls, etc., and is used to verify the compliance of the script's behavior after the repair.

[0144] In one possible implementation, the second parameter information refers to the system resource usage and running status data generated by the first running environment during the execution of the second file. It is consistent with the dimensions of the first parameter information (including CPU utilization, memory usage, execution time, etc.) and is used to verify whether the impact of the repaired script on the resources of the first running environment meets expectations.

[0145] In one possible implementation, the third abnormal behavior refers to a new abnormality or a residual abnormality that is not completely fixed during the execution of the second file, which is determined based on the third behavior and the second parameter information. It may be a potential problem not covered by the first repair strategy or a new defect introduced by the repair operation.

[0146] In one possible implementation, the second remediation strategy refers to a targeted remediation plan for the third abnormal behavior. The second remediation strategy is used to solve the problems found in the secondary verification and ensure that the script ultimately meets the operational security and functional requirements. Its formulation logic is consistent with that of the first remediation strategy.

[0147] In one possible implementation, the third file refers to the file obtained after the second file has been repaired using the second repair strategy.

[0148] In one possible implementation, since the first file may cause temporary modifications to the first runtime environment during its execution, in order to ensure that the test environment of the second file is consistent with the test environment of the first file, the first runtime environment can be rolled back to its initial state before the second file is run in the first runtime environment.

[0149] In one possible implementation, multiple third behaviors can be obtained through a preset interface in the first runtime environment, and second parameter information can be obtained in real time through a preset code library.

[0150] In one possible implementation, multiple third behaviors can be matched with a pre-defined list of abnormal behaviors in the second rule base. If a third behavior is the same as any abnormal behavior, then the third behavior is identified as the third abnormal behavior. Furthermore, based on each parameter in the acquired second parameter information, the parameter conditions corresponding to the parameter can be determined from the parameter conditions in the second rule base. If the parameter does not meet the corresponding parameter conditions, the behavior associated with the parameter is identified as the third abnormal behavior.

[0151] In this embodiment, after repairing the first file to obtain the second file, the first runtime environment is rolled back to its initial state to ensure consistency of the test benchmark. Then, the second file is run to collect third behavior and second parameter information. Combined with the second rule base, the third abnormal behavior is judged from the dual dimensions of behavior compliance and parameter rationality. For the third abnormal behavior, the second file is iteratively repaired to obtain the third file. If there is no third abnormal behavior, the second file is saved. This can not only verify the initial repair effect and identify potential residual anomalies or new defects, but also continuously optimize the script through iterative repair. Ultimately, it can ensure the security and stability of the saved file and avoid the risk of deploying an incompletely repaired script to a real operating system. At the same time, the automated collection, judgment and repair process reduces the cost of manual intervention and can improve the efficiency and reliability of script testing in operation and maintenance scenarios.

[0152] Based on the above embodiments, in the absence of any third abnormal behavior, a script test report can be generated after saving the second file. The script test report includes a behavior heatmap, a risk scoring model, and a repair link tracing.

[0153] The behavior heatmap refers to a visual chart that categorizes and statistically analyzes all operations performed by BAT scripts (first file, second file) in the first runtime environment based on system resource type (file system, registry, network) or resource path. The heatmap uses color variations to visually represent the density, frequency, and impact of these operations. Darker colors indicate more frequent and significant operations performed by the BAT scripts (first file, second file) on that resource, allowing for quick identification of resource-intensive operation areas and potentially risky operation ranges.

[0154] The risk scoring model is a system that quantifies and scores various behaviors (including abnormal and normal behaviors) during the execution of BAT scripts (first file and second file) based on preset operational risk level weighting rules. By assigning differentiated weights to different types of behaviors (e.g., the weight of system disk deletion is greater than that of ordinary file reading, and the weight of modifying key registry entries is greater than that of network connections), the initial risk value of the first file and the post-repair risk value of the second file are calculated cumulatively, using a quantitative index of 0-100 points to intuitively reflect the potential threat level of the BAT script to the system.

[0155] Repair tracking refers to an auditable link that fully records key nodes throughout the entire lifecycle of a BAT script, from the initial detection of abnormal behavior to the final successful repair. This includes details of the abnormal behavior, matching repair strategies, modifications to the BAT script, and verification results, presented in the form of time-series logs or flowcharts. This ensures the repair process is traceable and reproducible, providing complete evidence for operations and maintenance audits.

[0156] In one possible implementation, behavioral data (including the first behavior and the third behavior) collected during the execution of the first and second files can be categorized and statistically analyzed according to the type of operation (file operation, registry modification, network connection, service start / stop) or system resource path. The statistical results can then be mapped into a visual heatmap to obtain a behavioral heatmap.

[0157] In one possible implementation, a quantitative risk scoring model can be constructed, which scores the script's execution behavior based on preset risk weight rules. Different types of abnormal behavior are assigned different weight values ​​(for example, the weight of deleting the root directory of the system disk is 100, and the weight of reading a normal file is 1). The risk weights of each behavior are then added together and combined with the risk value after repair, so that the final risk score of the script (such as 0-100 points) can be calculated.

[0158] In one possible implementation, the script can record the entire lifecycle data from the initial detection of abnormal behavior to the final successful repair, and generate an auditable repair tracing log. The repair tracing log includes: the specific content of the abnormal behavior, the timestamp of the abnormality, the type of the triggered repair strategy, the specific changes to the repair code (such as inserting timeout exit logic on line 10 of the first file), and the verification result after repair (such as "the third abnormal behavior was not detected").

[0159] In this embodiment, when generating the script test report, a behavior heatmap is used to visually display the distribution of script operations on system resources, enabling operations and maintenance personnel to quickly locate core operation areas and potential risk points, thus improving their global awareness of script behavior. A risk scoring model quantifies script risk values ​​based on operational hazard levels, transforming ambiguous safe / unsafe judgments into precise quantitative indicators, providing objective data support for script deployment approval. By recording the self-healing process through repair link tracing and generating auditable repair logs, the entire process of anomaly investigation and repair can be made transparent and traceable, facilitating operations and maintenance personnel to review the causes of problems and verify the effectiveness of repair logic. In summary, this script test report improves the readability and intuitiveness of test results, constructs a complete security audit closed loop, and enhances the security and controllability of script management in automated operations and maintenance scenarios.

[0160] Based on the above embodiments, the file testing method will be further illustrated below through two examples.

[0161] Example 1: A user uploads a file for log cleanup, which is used to clean up log files on the computer's system drive. This file is then input into the first runtime environment and run. During the process, the behavior of cleaning up log files on the system drive is captured. It is determined that this behavior is abnormal (first abnormal behavior) and can trigger an alarm. Subsequently, based on the type and context analysis of this abnormal behavior, a repair strategy is automatically generated, adding a path whitelist restriction to the file, allowing it to be used to clean up log files in a preset directory on the computer's system drive. Then, a regression test is performed on the repaired file (i.e., re-running it in the first runtime environment) to test whether the repaired file will produce abnormal behavior again. If no abnormal behavior occurs, the repaired file is saved, and a script test report is generated.

[0162] Example 2: A user uploads a file for batch image conversion. This file contains a risk of an infinite loop. The file is then input into the first runtime environment and run. During the run, if the file's execution time exceeds a preset threshold (e.g., 60 seconds), this behavior is determined to be abnormal (second abnormal behavior). Subsequently, based on the type and context analysis of this abnormal behavior, a repair strategy is automatically generated. Timeout exit logic is added to the file (e.g., automatically terminating when the execution time exceeds the preset threshold). Then, regression testing is performed on the repaired file (i.e., rerunning it in the first runtime environment) to test whether the repaired file will produce abnormal behavior again. If no abnormal behavior occurs, the repaired file is saved, and a script test report is generated.

[0163] For example, the fix tracing in the script test report is as follows:

[0164] Date A - Time A - Script begins execution; Date A - Time B - Execution exceeds 60 seconds, deemed a risk of infinite loop; Date A - Time C - Script is repaired, resulting in a repaired script: timeout exit logic added; Date A - Time D - Regression test passed: the repaired file completes within 58 seconds; Date A - Time E - Risk score: 1.2.

[0165] For example, Figure 3 This is a schematic diagram of a document testing device provided in an embodiment of this application. Please refer to [link / reference]. Figure 3 The document testing device 300 includes: a first processing module 301, an acquisition module 302, a first determining module 303, a second determining module 304, and a second processing module 305, wherein...

[0166] The first processing module 301 is used to input the first file to be run into the pre-created first running environment, and to run the first file in the first running environment;

[0167] The acquisition module 302 is used to acquire multiple first actions executed during the execution of the first file, as well as the first parameter information of the first execution environment;

[0168] The first determining module 303 is used to determine a first abnormal behavior among multiple first behaviors, and to determine a second abnormal behavior based on first parameter information;

[0169] The second determining module 304 is used to determine the first repair strategy for the first file based on the first abnormal behavior and the second abnormal behavior.

[0170] The second processing module 305 is used to repair the first file based on the first repair strategy to obtain the second file.

[0171] The document testing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0172] In one possible implementation, the first determining module 303 is specifically used for:

[0173] Get multiple preset abnormal behaviors;

[0174] For each of the multiple first behaviors, match the first behavior with multiple abnormal behaviors;

[0175] If the first behavior is the same as any abnormal behavior, then the first behavior is identified as the first abnormal behavior.

[0176] In one possible implementation, the first determining module 303 is specifically used for:

[0177] Obtain multiple preset parameter conditions;

[0178] Based on each parameter in the first parameter information, determine the parameter condition corresponding to the parameter from multiple preset parameter conditions;

[0179] If the parameter does not meet the corresponding parameter conditions, the behavior associated with the parameter will be identified as the second abnormal behavior.

[0180] In one possible implementation, the second determining module 304 is specifically used for:

[0181] Determine the type of the first abnormal behavior and the type of the second abnormal behavior;

[0182] Determine the behavioral information corresponding to the first and second abnormal behaviors. The behavioral information includes the cause of the behavior and the result of the behavior.

[0183] Based on the type of the first abnormal behavior, the type of the second abnormal behavior, the behavior information corresponding to the first abnormal behavior, and the behavior information corresponding to the second abnormal behavior, a first repair strategy for the first file is determined.

[0184] In one possible implementation, the second determining module 304 is specifically used for:

[0185] Obtain the log file and the first rule base. The log file includes the first abnormal behavior and the second abnormal behavior. The first rule base includes multiple preset abnormal behavior types.

[0186] The type of the first abnormal behavior is obtained by matching the first abnormal behavior in the log file with the types of multiple abnormal behaviors in the first rule base.

[0187] The type of the second abnormal behavior is obtained by matching the second abnormal behavior in the log file with the types of multiple abnormal behaviors in the first rule base.

[0188] In one possible implementation, the second determining module 304 is specifically used for:

[0189] The log files were analyzed to obtain the behavioral information corresponding to the first and second abnormal behaviors.

[0190] In one possible implementation, the document testing apparatus further includes a third processing module 306, which is configured to:

[0191] The second file is run in the first runtime environment;

[0192] Obtain multiple third actions executed during the execution of the second file, as well as the second parameter information of the first execution environment;

[0193] Based on multiple third behaviors and second parameter information, determine whether there are any third abnormal behaviors during the execution of the second file;

[0194] In the event of a third abnormal behavior, a second repair strategy for the second file is determined based on the third abnormal behavior, and the second file is repaired based on the second repair strategy to obtain the third file;

[0195] If no third abnormal behavior is found, save the second file.

[0196] The document testing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0197] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 may include: a transceiver 401, a processor 402, and a memory 403.

[0198] Processor 402 executes computer execution instructions stored in memory, causing processor 402 to perform the scheme in the above embodiments. Processor 402 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0199] The memory 403 is connected to the processor 402 via the system bus and completes communication between them. The memory 403 is used to store computer program instructions.

[0200] Transceiver 401 can be used to obtain the task to be run and its configuration information.

[0201] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0202] This application also provides a chip for executing instructions, which is used to execute the technical solution for file testing in the above embodiments.

[0203] This application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on a computer, the computer performs the technical solution of the file testing method described in the above embodiments.

[0204] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0205] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0206] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0207] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0208] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0209] It should be understood that the aforementioned processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0210] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0211] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0212] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0213] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic control unit or main control device.

[0214] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0215] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A file testing method, characterized in that, include: The first file to be run is input into the pre-created first runtime environment, and the first file is run in the first runtime environment; Obtain multiple first actions executed during the execution of the first file, as well as the first parameter information of the first execution environment; Among the plurality of first behaviors, a first abnormal behavior is determined, and a second abnormal behavior is determined based on the first parameter information; Based on the first abnormal behavior and the second abnormal behavior, determine the first repair strategy for the first file; Based on the first repair strategy, the first file is repaired to obtain the second file.

2. The method according to claim 1, characterized in that, The determination of a first abnormal behavior among the plurality of first behaviors includes: Get multiple preset abnormal behaviors; For each of the plurality of first behaviors, the first behavior is matched with the plurality of abnormal behaviors; If the first behavior is the same as any abnormal behavior, then the first behavior is identified as the first abnormal behavior.

3. The method according to claim 1, characterized in that, The determination of the second abnormal behavior based on the first parameter information includes: Obtain multiple preset parameter conditions; Based on each parameter in the first parameter information, determine the parameter condition corresponding to the parameter from the preset plurality of parameter conditions; If the parameter does not meet the corresponding parameter conditions, the behavior associated with the parameter is identified as the second abnormal behavior.

4. The method according to claim 1, characterized in that, The step of determining the first repair strategy for the first file based on the first abnormal behavior and the second abnormal behavior includes: Determine the type of the first abnormal behavior and the type of the second abnormal behavior; Determine the behavioral information corresponding to the first abnormal behavior and the second abnormal behavior, wherein the behavioral information includes the cause of the behavior and the result of the behavior; Based on the type of the first abnormal behavior, the type of the second abnormal behavior, the behavior information corresponding to the first abnormal behavior, and the behavior information corresponding to the second abnormal behavior, a first repair strategy for the first file is determined.

5. The method according to claim 4, characterized in that, Determining the type of the first abnormal behavior and the type of the second abnormal behavior includes: Obtain a log file and a first rule base, wherein the log file includes the first abnormal behavior and the second abnormal behavior, and the first rule base includes a plurality of preset abnormal behavior types; The type of the first abnormal behavior is obtained by matching the first abnormal behavior in the log file with the types of the plurality of abnormal behaviors in the first rule base. The type of the second abnormal behavior is obtained by matching the second abnormal behavior in the log file with the types of the plurality of abnormal behaviors in the first rule base.

6. The method according to claim 5, characterized in that, The step of determining the behavioral information corresponding to the first abnormal behavior and the second abnormal behavior includes: The log file is analyzed to obtain behavioral information corresponding to the first abnormal behavior and the second abnormal behavior.

7. The method according to claim 1, characterized in that, After repairing the first file based on the first repair strategy to obtain the second file, the method further includes: The second file is executed in the first runtime environment; Obtain multiple third actions executed during the execution of the second file, as well as the second parameter information of the first execution environment; Based on the multiple third behaviors and the second parameter information, it is determined whether there are any third abnormal behaviors during the execution of the second file; In the presence of the third abnormal behavior, a second repair strategy for the second file is determined based on the third abnormal behavior, and the second file is repaired based on the second repair strategy to obtain the third file; If the third abnormal behavior does not exist, save the second file.

8. A document testing device, characterized in that, include: The system comprises a first processing module, an acquisition module, a first determination module, a second determination module, and a second processing module, wherein... The first processing module is used to input the first file to be run into a pre-created first running environment, and to run the first file in the first running environment; The acquisition module is used to acquire multiple first actions executed during the execution of the first file, as well as first parameter information of the first running environment; The first determining module is configured to determine a first abnormal behavior among the plurality of first behaviors, and to determine a second abnormal behavior based on the first parameter information; The second determining module is used to determine a first repair strategy for the first file based on the first abnormal behavior and the second abnormal behavior; The second processing module is used to repair the first file based on the first repair strategy to obtain a second file.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images