Automatic testing method and system based on program file and storage medium

Abstract

The invention discloses an automatic testing method and system based on a program file and a storage medium, and belongs to the technical field of communication. According to the method, the number of all signals of the id and the kill command of the protection process is obtained firstly, and the tedious process of manual searching is avoided. And traversing all signal numbers of the kill command, sending a termination signal to the process id through the kill command, obtaining a kill command execution log, and finally obtaining a test report file. According to the invention, the reaction and performance of the process under various signals can be tested more comprehensively, unwanted processes can be terminated in time, occupied system resources are released, and the utilization efficiency of the resources is improved. Through the automatic test method, the situation that a certain key service process cannot be normally terminated under a specific signal can be quickly found, so that the key service process is repaired in advance, and the serious problem of service interruption in actual operation is avoided. Therefore, the testing method provided by the invention can be used for quickly and accurately testing a large number of processes.

Description

Technical Field

[0001] The present invention belongs to the field of communication technology and relates to an automatic testing method, system and storage medium based on program files. Background Art

[0002] In today's highly digital age, the construction and maintenance of trusted software systems have become the key to ensuring information security and stable system operation. As one of the important components of the underlying modules of trusted software systems, the process protection function plays a vital role. When the process protection function is enabled and a well-designed process protection strategy is configured for a specific program file, the expected effect is significant. Once the program file is started, it can effectively resist various attempts to illegally terminate the operation. The implementation of this function provides a solid guarantee for the continuity of key business processes and the stability of the system.

[0003] In the Linux operating system, which is widely used in servers and many professional fields, when a running program needs to be terminated forcibly, it is usually achieved with the help of the kill command. However, a phenomenon worthy of attention is that the number of kill signals supported by the kill command in different Linux system versions is not completely consistent. In some versions, the number of kill signals supported is 64; in other versions, this number climbs to 128. This difference has brought great challenges to the testing of process protection. If the kill command is executed manually and each signal is called one by one to test the forced termination of the protected process, this is undoubtedly an extremely tedious and time-consuming task.

[0004] Take an enterprise-class Linux server with a complex business architecture as an example. Assume that there are multiple critical applications running on the server, each of which is configured with a process protection policy. To ensure the effectiveness of these protection policies, each protected process is fully tested. If each process needs to undergo testing for all possible kill signals, then testing just one process may take hours. Assuming that each kill signal test takes an average of 1 minute (including executing the command, observing the results, and recording the data), for a 64-signal system, it takes 64 minutes to complete the test of one process; for a 128-signal system, it takes 128 minutes. If there are 10 processes that need to be tested at the same time, then in a 64-signal system, it takes a total of 640 minutes; in a 128-signal system, it takes 1280 minutes. Consider further that if a complex system environment or unstable network conditions are encountered during the test process, the test time may be further extended. For example, due to network latency, the response time of command execution increases, or the test process itself becomes stuck due to system resource constraints, the test time for each signal may be extended from 1 minute to 2 minutes or even longer.

[0005] In addition, manual testing is also susceptible to human factors. Operators may make mistakes due to fatigue, negligence or unfamiliarity with commands, which not only wastes time but also may produce erroneous test results. Moreover, manual testing cannot achieve automation and standardization of the test process, and it is difficult to ensure that the conditions and steps of each test are completely consistent, which affects the reliability and repeatability of the test results. For example, on the server of a large financial institution, key transaction processing programs are running. In order to ensure that these programs can still run stably in the face of various abnormal situations, their process protection functions need to be strictly tested. Due to the manual execution of the kill command for testing, the testers became fatigued and made mistakes during the long operation process, resulting in inaccurate test results. This means that in the subsequent actual operation, when encountering similar abnormal situations, process protection fails to play its due role, which brings certain risks and losses to financial transactions. For another example, in a high-performance computing cluster of a scientific research institution, complex scientific computing tasks are running. In order to ensure the continuity of computing tasks and the accuracy of results, process protection of related programs is crucial. However, due to the low efficiency of manual testing, comprehensive testing of all processes could not be completed in a timely manner, resulting in some processes that had not been fully tested being terminated unexpectedly during the system upgrade, seriously affecting the progress of scientific research projects.

[0006] In summary, the method of manually executing the kill command to call each signal to forcibly terminate the protected process not only takes a lot of time and energy, but is also easily interfered and affected by various factors, resulting in low test efficiency and inaccurate results. Therefore, in order to improve the test efficiency and reliability of the process protection function, it is urgent to develop more automated and intelligent testing tools and methods. Summary of the invention

[0007] The purpose of the present invention is to solve the problems in the prior art and to provide an automated testing method, system and storage medium based on program files.

[0008] In order to achieve the above object, the present invention adopts the following technical solutions:

[0009] The present invention proposes an automated testing method based on program files, comprising:

[0010] Get the total number of signals protecting the process ID and the kill command;

[0011] Traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log;

[0012] Get the test report file based on the kill command execution log to implement automated testing of the file.

[0013] Preferably, the method for obtaining the protected process id is:

[0014] Configure the program file as the program file of the process protection policy, and automatically obtain the process ID number through the ps query daemon process command, grep filtering command and awk command, that is, obtain the protected process ID.

[0015] Preferably, the method for obtaining the protected process id is:

[0016] Operate the trusted software system command to configure the process protection policy for the customer's business program. After the customer's business program is started, manually query the process ID of the customer's business program after running through the query daemon process command to obtain the protection process ID.

[0017] Preferably, the number of signals supported by the kill command in the operating system is automatically obtained through the kill -1 command, that is, the total number of signals of the kill command.

[0018] Preferably, the traversal of all signal numbers of the kill command is performed by executing each kill signal in sequence through a while statement to perform forced termination operations on the process ID of the automatically generated program one by one.

[0019] Preferably, the method of sending a termination signal to the process ID through the kill command and obtaining the kill command execution log is specifically as follows: after each forced termination operation of the kill signal, an if statement is used in combination with the echo$? command to determine whether the process protection function is normal, and if the process protection function is normal, a test success message is output; if the process protection function is abnormal, a test failure message is output; wherein the kill command execution log includes the test success message and the test failure message.

[0020] The present invention proposes an automatic test system based on program files, comprising:

[0021] An information acquisition module, the information acquisition module is used to obtain the protection process ID and the total signal number of the kill command;

[0022] An information processing module, the information processing module is used to traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log;

[0023] The information summary module is used to obtain a test report file based on the kill command execution log to achieve automated testing of the file.

[0024] Preferably, the method of sending a termination signal to the process ID through the kill command and obtaining the kill command execution log is specifically as follows: after each forced termination operation of the kill signal, an if statement is used in combination with the echo$? command to determine whether the process protection function is normal, and if the process protection function is normal, a test success message is output; if the process protection function is abnormal, a test failure message is output; wherein the kill command execution log includes the test success message and the test failure message.

[0025] A terminal device comprises a memory, a processor and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of an automated testing method based on a program file are implemented.

[0026] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of an automated testing method based on a program file.

[0027] Compared with the prior art, the present invention has the following beneficial effects:

[0028] The present invention proposes an automated testing method based on program files, which obtains the protection process ID and all signal numbers of the kill command, avoids the tedious process of manual search, and saves time and energy. All signal numbers of the kill command are traversed, and a termination signal is sent to the process ID through the kill command to obtain the kill command execution log; the reaction and performance of the process under various signals can be tested more comprehensively, unnecessary processes can be terminated in time, occupied system resources can be released, and resource utilization efficiency can be improved. Through this automated testing method, it can be quickly discovered that a certain key service process cannot be terminated normally under a specific signal, so that it can be repaired in advance, avoiding the serious problem of service interruption in actual operation. Therefore, the testing method proposed by the present invention helps to effectively and quickly test and verify the underlying module function process protection function of the trusted software system, and can quickly and accurately complete the testing of a large number of processes. At the same time, they can also automatically analyze and report the test results, helping developers and operation and maintenance personnel to find potential problems in time, and take corresponding measures to optimize and improve.

[0029] The present invention proposes an automated test system based on program files, which divides the system into an information acquisition module, an information processing module and an information summary module to obtain a test report file and realize automated testing of the file. The modularization concept is adopted to make each module independent of each other, which is convenient for unified management of each module. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0031] Figure 1 The present invention is a flowchart of the automated testing method based on program files.

[0032] Figure 2 The present invention is a flowchart of the execution of the program file-based automated testing method.

[0033] Figure 3 This is a diagram of the program file-based automated testing system of the present invention.

[0034] Figure 4 The figure is a schematic structural diagram of an electronic device of the present invention. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0036] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0037] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0038] The present invention is further described in detail below in conjunction with the accompanying drawings:

[0039] Example 1

[0040] The present invention proposes an automated testing method based on program files, such as Figure 1 As shown, including:

[0041] S1. Get the total number of signals of the protected process ID and kill command;

[0042] There are two ways to obtain the protected process ID:

[0043] Method 1:

[0044] Configure the program file as the program file of the process protection policy, and automatically obtain the process ID number through the ps query daemon process command, grep filtering command and awk command, that is, obtain the protected process ID.

[0045] Method 2:

[0046] Operate the trusted software system command to configure the process protection policy for the customer's business program. After the customer's business program is started, manually query the process ID of the customer's business program after running through the query daemon process command to obtain the protection process ID.

[0047] Use the kill -l command to automatically obtain the number of signals supported by the kill command in the operating system, that is, the total number of signals supported by the kill command.

[0048] S2. Traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log;

[0049] The whole number of signals of the kill command is traversed, specifically: each kill signal is executed in sequence through a while statement to perform a forced termination operation on the process ID of the automatically generated program one by one.

[0050] The kill command is used to send a termination signal to the process ID and obtain the kill command execution log, specifically: after each forced termination operation of the kill signal, an if statement is used in combination with the echo$? command to determine whether the process protection function is normal, and if the process protection function is normal, the test success information is output; if the process protection function is abnormal, the test failure information is output; wherein the kill command execution log includes the test success information and the test failure information.

[0051] S3. Obtain the test report file based on the kill command execution log to implement automated testing of the file.

[0052] The following is an explanation of the process id:

[0053] The process id number is a unique identifier assigned by the operating system to each running process. It can be understood as the "identity card number" used by the operating system to distinguish and manage different processes. Each process has its own unique pid in the system.

[0054] The main functions of pid are as follows:

[0055] First, it helps the operating system to accurately identify and track specific processes. When the operating system needs to operate a process, such as scheduling resources, monitoring status, terminating the process, etc., it uses pid to accurately find the target process.

[0056] Secondly, for various management tools and commands in the system, pid is the key basis for specifying the operation object. For example, when we want to check the resource usage of a process or forcefully terminate an abnormal process, we need to know its corresponding pid.

[0057] Furthermore, in inter-process communication, pid is sometimes used as an important parameter to identify and distinguish different processes. For example, suppose that in a multitasking operating system, three programs, a browser, a text editor, and a music player, are running at the same time. The operating system will assign a pid to the browser, such as 1234; another pid to the text editor, such as 5678; and another pid to the music player, such as 9101. When the system needs to allocate more memory resources to a process, or the user wants to close an unresponsive program, the corresponding pid can be used to perform the operation accurately.

[0058] Combine the following Figure 2 The method is described in detail:

[0059] First of all Figure 2 The right part describes:

[0060] This test method can be run by itself first, input the C code (which can continuously print the system time) into a .c text through the echo command, and then compile the .c text with the gcc command to generate a specified program file, and then configure it as a program file of the process protection policy and start the program; automatically obtain the protection pid (i.e., process id) of the program file through the ps query daemon command, the grep filter command, and the awk command;

[0061] Use the kill -l command to automatically obtain the number of signals that the kill command in the operating system can support, that is, the total number of signals of the kill command;

[0062] Call the kill command, and execute each kill signal in turn through the while statement to force the termination of the automatically generated program pid one by one. After each kill signal forced termination operation, the if statement will be used in combination with the echo$? command to determine whether the basic functions of the process protection function are normal, obtain the kill command execution log, and obtain the test report file based on the kill command execution log for the tester to view the results.

[0063] right Figure 2 The left part describes:

[0064] Use the trusted software system command to configure the process protection policy for the customer's business program. After the customer's business program is started, use the ps query daemon process command to manually query the pid (i.e., process id) of the customer's business program after it runs to obtain the protected process id.

[0065] The kill command is automatically called in the background, and each kill signal is executed in sequence through the while statement to force the termination of the pid of the customer business program one by one. At the same time, after each kill signal is forced to terminate, the if statement is automatically passed, combined with the echo$? command, to determine whether the basic functions of the process protection function are normal. The compatibility of the process protection function with the business program and the stability of the process protection function are automatically tested, and success or failure is output to the text of the test report for the tester to view the results.

[0066] Example 2

[0067] The present invention proposes an automated testing system based on program files, such as Figure 3 As shown, it includes an information acquisition module, an information processing module and an information aggregation module;

[0068] The information acquisition module is used to obtain the protection process ID and the total signal number of the kill command;

[0069] Method to obtain the protected process id:

[0070] Configure the program file as the program file of the process protection policy, and automatically obtain the process ID number through the ps query daemon process command, grep filtering command and awk command, that is, obtain the protected process ID.

[0071] Method to obtain the protected process id:

[0072] Operate the trusted software system command to configure the process protection policy for the customer's business program. After the customer's business program is started, manually query the process ID of the customer's business program after running through the query daemon process command to obtain the protection process ID.

[0073] Use the kill -l command to automatically obtain the number of signals supported by the kill command in the operating system, that is, the total number of signals supported by the kill command.

[0074] The information processing module is used to traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log;

[0075] The whole number of signals of the kill command is traversed, specifically: each kill signal is executed in sequence through a while statement to perform a forced termination operation on the process ID of the automatically generated program one by one.

[0076] The kill command is used to send a termination signal to the process ID and obtain the kill command execution log, specifically: after each forced termination operation of the kill signal, an if statement is used in combination with the echo$? command to determine whether the process protection function is normal, and if the process protection function is normal, the test success information is output; if the process protection function is abnormal, the test failure information is output; wherein the kill command execution log includes the test success information and the test failure information.

[0077] The information summary module is used to obtain a test report file based on the kill command execution log to achieve automated testing of the file.

[0078] Example 3

[0079] See also Figure 4 As shown, the present invention also provides an electronic device 100 for an automated testing method based on a program file; the electronic device 100 includes a memory 101, at least one processor 102, a computer program 103 stored in the memory 101 and executable on the at least one processor 102, and at least one communication bus 104.

[0080] The memory 101 can be used to store the computer program 103, and the processor 102 implements the steps of the program file-based automated testing method described in Example 1 by running or executing the computer program stored in the memory 101 and calling the data stored in the memory 101. The memory 101 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data (such as audio data) created according to the use of the electronic device 100, etc. In addition, the memory 101 can include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (FlashCard), at least one disk storage device, a flash memory device, or other non-volatile solid-state storage devices.

[0081] The at least one processor 102 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 102 may be a microprocessor or any conventional processor, etc. The processor 102 is the control center of the electronic device 100, and uses various interfaces and lines to connect various parts of the entire electronic device 100.

[0082] The memory 101 in the electronic device 100 stores a plurality of instructions to implement an automated testing method based on a program file, and the processor 102 can execute the plurality of instructions to implement:

[0083] Get the total number of signals protecting the process ID and the kill command;

[0084] Traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log;

[0085] Get the test report file based on the kill command execution log to implement automated testing of the file.

[0086] Example 4

[0087] If the module / unit integrated in the electronic device 100 is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device that can carry the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory and read-only memory (ROM, Read-Only Memory).

[0088] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0090] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0091] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0092] Therefore, the present invention proposes an automated testing method based on program files, which supports two modes. One is that the process id number of a certain program can be manually queried and used as a parameter of the tool to perform the test; the other is that the tool automatically generates a specified program, automatically configures it as a program file of the process protection strategy, and the program can run continuously. Then, the total number of kill signals of the operating system is obtained, and then each kill signal is called through a while loop statement, and the kill operation is attempted on the pid of the program file of the started process protection strategy. At the same time, the result of the kill operation is judged, and the success or failure information is output to the test report file to improve the test efficiency. Through this method, it can help to effectively and quickly test and verify the process protection function of the underlying module function of the trusted software system. By programming to realize the automatic sending of the kill signal and the result monitoring, the test of a large number of processes can be completed quickly and accurately. At the same time, they can also automatically analyze and report the test results, helping developers and operation and maintenance personnel to find potential problems in time, and take corresponding measures to optimize and improve.

[0093] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. An automated testing method based on program files, characterized in that: include: Get the total number of signals protecting the process ID and the kill command; Traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log; Get the test report file based on the kill command execution log to implement automated testing of the file.

2. The automated testing method based on program files according to claim 1, characterized in that: Method to obtain the protected process id: Configure the program file as the program file of the process protection policy, and automatically obtain the process ID number through the ps query daemon process command, grep filtering command and awk command, that is, obtain the protected process ID.

3. The automated testing method based on program files according to claim 1, characterized in that: Method to obtain the protected process id: Operate the trusted software system command to configure the process protection policy for the customer's business program. After the customer's business program is started, manually query the process ID of the customer's business program after running through the query daemon process command to obtain the protection process ID.

4. The automated testing method based on program files according to claim 1, characterized in that: Use the kill -l command to automatically obtain the number of signals supported by the kill command in the operating system, that is, the total number of signals supported by the kill command.

5. The automated testing method based on program files according to claim 1, characterized in that: The whole number of signals of the kill command is traversed, specifically: each kill signal is executed in sequence through a while statement to perform a forced termination operation on the process ID of the automatically generated program one by one.

6. The automated testing method based on program files according to claim 1, characterized in that: The kill command is used to send a termination signal to the process ID and obtain the kill command execution log, specifically: after each forced termination operation of the kill signal, an if statement is used in combination with the echo$? command to determine whether the process protection function is normal, and if the process protection function is normal, the test success information is output; if the process protection function is abnormal, the test failure information is output; wherein the kill command execution log includes the test success information and the test failure information.

7. An automated testing system based on program files, characterized in that: include: An information acquisition module, the information acquisition module is used to obtain the protection process ID and the total signal number of the kill command; An information processing module, the information processing module is used to traverse all signal numbers of the kill command, send a termination signal to the process ID through the kill command, and obtain the kill command execution log; The information summary module is used to obtain a test report file based on the kill command execution log to achieve automated testing of the file.

8. The program file-based automated testing system according to claim 1, characterized in that: The kill command is used to send a termination signal to the process ID and obtain the kill command execution log, specifically: after each forced termination operation of the kill signal, an if statement is used in combination with the echo$? command to determine whether the process protection function is normal, and if the process protection function is normal, the test success information is output; if the process protection function is abnormal, the test failure information is output; wherein the kill command execution log includes the test success information and the test failure information.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the program file-based automated testing method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the program file-based automated testing method according to any one of claims 1 to 6 are implemented.

Images