CN118779232A - Test case execution method, device and server - Google Patents

Abstract

The present application provides a test case execution method and server. It relates to the field of computer technology. It includes: the process information of the test case can be obtained, and then whether there is an abnormal process in the process of the test case is determined according to the process information. When it is determined that there is an abnormal process in the process, it can be further determined whether the abnormal process is a simulated abnormal process, that is, whether the abnormal process is a simulated abnormal process. When it is determined that the abnormal process is not a simulated abnormal process, the abnormal process is terminated. In this way, the present application can terminate the abnormal process that cannot execute the test task normally and is not simulated, and only retain the process that can execute the test case normally, thereby preventing the test process from being blocked. After the main process executes the currently executed test case, the next test case can be executed, thereby improving the efficiency of the test.

Description

Test case execution method, device and server

Technical Field

The present application relates to the field of computer technology, and in particular to a test case execution method, device and server.

Background Art

A testing tool is software or a platform used to test the interface or performance of a computing device or a virtual machine.

Taking the server as an example of a computing device, currently, the server can use testing tools to execute test cases, thereby automatically testing whether the functions of the software and applications in the server meet expectations, whether some interfaces in the server can work properly, and whether there are security vulnerabilities and potential risks.

The server can call or create a main process to execute the test case to perform the above test. In some cases, the main process can create multiple sub-processes to execute the test case. Due to resource competition, deadlock and other reasons between the multiple sub-processes, the execution process may be stuck, resulting in process congestion and inability to continue to execute the next test case. The process congestion leads to low efficiency of computing device application test tools for testing.

Summary of the invention

The embodiments of the present application provide a test case execution method and a server, the purpose of which is to reduce process congestion of test cases and improve test efficiency.

In a first aspect, an embodiment of the present application provides a test case execution method, the method comprising:

Obtain the process information of the test case, and then determine whether there is an abnormal process in the process of executing the test case based on the process information, where the abnormal process is a process whose process status meets the preset abnormal conditions. The process whose process status meets the preset abnormal conditions refers to sleeping processes and zombie processes and other processes that cannot execute test tasks normally.

When it is determined that there is an abnormal process in the process, it is determined whether there is a simulated abnormal process in the abnormal process. When there is a simulated abnormal process, the simulated abnormal process is retained and the abnormal process that is not a simulated abnormal process is processed. In this way, the abnormal process is analyzed based on the process information, and it is terminated when necessary based on the type of the abnormal process, which can avoid long-term and continuous blocking of the process, and the test case is executed normally afterwards, thereby improving the efficiency of the test.

In some possible implementations, the process information may include a process identifier. Before determining whether the abnormal process has a simulated abnormal process, the following may be done: configure code to simulate the abnormal process, and when the code runs, store the process identifier corresponding to the code in memory.

Then you can determine whether the abnormal process is a simulated abnormal process by:

When the process identifier of the abnormal process matches the process identifier corresponding to the code, it is determined that a simulated abnormal process exists; when the process identifier of the abnormal process does not match the process identifier corresponding to the code, it is determined that no simulated abnormal process exists.

For example, if the process identifier corresponding to the code, that is, the PID of the simulated abnormal process is 2315, then determine whether the process identifier (PID) of the abnormal process is 2315. If so, determine that the abnormal process is a simulated abnormal process. Otherwise, determine that the abnormal process is not a simulated abnormal process.

In some possible implementation methods, since different types of abnormal processes have different states and behaviors, different types of abnormal processes need to be handled in different ways. Therefore, in this application, a process termination method that matches the type of abnormal process can be determined based on the type of the abnormal process, and then the abnormal process can be terminated using the process termination method that matches the type of the abnormal process.

Abnormal processes including sleeping processes, zombie processes, and stopped processes are introduced as examples.

If the type of the abnormal process is a sleeping process or a stopped process, it can be determined that the process termination method is to execute a kill command, wherein the stopped process is a process that has been stopped or is being tracked by a debugger.

If the type of the abnormal process is a zombie process, then the process termination method may be determined to be to recycle the zombie process using the parent process of the zombie process.

In some possible implementations, the present application may also determine whether the abnormal process is successfully terminated;

When it is determined that the abnormal process is not successfully terminated, a forced termination method matching the type may be determined according to the type of the abnormal process, and the abnormal process may be forcibly terminated using the forced termination method matching the type.

Exemplarily, if the type of the abnormal process is a sleeping process or a stopped process, determining the forced termination method is to execute a kill-9 command, and forcibly terminating the abnormal process by executing the kill-9 command;

If the type of the abnormal process is a zombie process, the forced termination method is determined to be executing a kill command or a kill-9 command. The parent process of the zombie process is terminated or the parent process is restarted by executing the kill command or the kill-9 command to forcibly terminate the zombie process.

In some possible implementations, when it is determined that the abnormal process is not a simulated abnormal process, an attempt may be made to repair the abnormal process.

Specifically, it can be determined whether the abnormal process is a repairable process. If the type of the abnormal process is a zombie process or the process state of the abnormal process is not an interruptible sleep state, it can be determined that the abnormal process is an unrepairable process, and the abnormal process is terminated.

If the type of the abnormal process is a sleep process and the process state of the abnormal process is an interruptible sleep state, the abnormal process can be determined to be a repairable process, and then a corresponding repair method can be executed to repair the abnormal process to wake up the abnormal process.

If the type of the abnormal process is a stopped process, it can be determined that the abnormal process is a repairable process, and a corresponding repair method is executed to repair the abnormal process to wake up the abnormal process, wherein the repair method can be, for example, executing the kill command to send a SIGCONT signal to the abnormal process, and the SIGCONT signal can be used to wake up the stopped process. Even for a process in an interruptible sleep state, sending SIGCONT is usually effective because it wakes up the process and allows it to continue execution. Of course, the repair method here is only an example and is not limited here.

When the abnormal process repair fails, the abnormal process can be terminated.

You can determine whether the abnormal process is repaired successfully in the following ways.

If after repair, the STAT column status code of the abnormal process changes to R, it can be determined that the process state of the abnormal process changes to the running state, and further it can be determined that the abnormal process is successfully repaired and the abnormal process is successfully awakened. Among them, the STAT column status code is used to represent the process state of the process, and the STAT column status code is R, which indicates that the process state of the process is in the running state.

If, after repair, the status code of the STAT column of the abnormal process does not change or changes to a status code other than R, it is determined that the repair of the abnormal process has failed and the abnormal process is terminated.

In some possible implementations, the abnormal process can also be stack traced, and the problem can be located based on the stack trace information, that is, the cause of the abnormal process being abnormal can be located so that relevant personnel can take corresponding measures to repair it.

In some possible implementation methods, the abnormal processes can be integrated at preset time intervals, and then the integrated abnormal processes can be processed in batches. In this way, the abnormal processes can be integrated at preset time intervals and multiple abnormal processes can be processed in batches, which can reduce the number of times the exceptions are processed, thereby improving the utilization of system resources. The preset time period can be set according to actual needs, for example, it can be 0.5s, which is not limited here.

In some possible implementation methods, in order to timely recycle the simulated exception process and avoid wasting system resources (such as memory, CPU time, etc.), the present application can also determine whether there are any unrecycled simulated exception processes after the execution of the currently executed test case is completed. When it is determined that there are unrecycled simulated exception processes, the unrecycled simulated exception processes are recycled.

In a second aspect, the present application provides a test case execution device, comprising:

An acquisition unit is used to obtain the process information of the test case;

A first determining unit, configured to determine whether there is an abnormal process in the process of the test case according to the process information;

A second determining unit is used to determine whether there is a simulated abnormal process in the abnormal process when there is an abnormal process in the process;

The processing unit is used for retaining the simulated abnormal process when there is a simulated abnormal process, and processing the abnormal process which is not the simulated abnormal process.

In some possible implementations, the process information includes a process identifier, and the device may further include:

A configuration unit, used to configure the code for simulating abnormal processes;

A storage unit, used for storing a process identifier corresponding to the code in a memory when the code is executed;

The second determining unit is specifically configured to:

When the process identifier of the abnormal process matches the process identifier corresponding to the code, it is determined that a simulated abnormal process exists;

When the process identifier of the abnormal process does not match the process identifier corresponding to the code, it is determined that there is no simulated abnormal process.

In some possible implementations, the device may further include:

The recycling unit is used to recycle the simulated abnormal process that has not been recycled after the test case is executed when there is a simulated abnormal process.

In some possible implementations, the processing unit may be specifically configured to:

Determining, according to the type of the process, a process termination method of the process;

The process is terminated by using a process termination method.

In some possible implementations, the device may further include:

a judging unit, configured to judge whether the abnormal process can be repaired according to the process state of the abnormal process which is not a simulated abnormal process;

The third determining unit is used to determine a process termination mode of the process when the abnormal process is determined to be an unrepairable process.

In a third aspect, an embodiment of the present application provides a server, wherein the server includes:

Memory and processor;

The memory is coupled to the processor; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the implementation method of the first aspect.

It can be seen from the above technical solution that the present application has the following beneficial effects:

In this application, the process information of the test case can be obtained, and then whether there is an abnormal process in the process of the test case can be determined based on the process information. When it is determined that there is an abnormal process in the process, it can be further determined whether the abnormal process is a simulated abnormal process, that is, whether the abnormal process is a simulated abnormal process. When it is determined that the abnormal process is not a simulated abnormal process, the abnormal process is terminated. In this application, the abnormal process is analyzed based on the process information, and terminated when necessary in combination with the type of abnormal process, which can avoid long-term and continuous blockage of the process, and the test case is executed normally afterwards, thereby improving the efficiency of the test.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of an application scenario of a test case execution method provided in an embodiment of the present application;

FIG2 is a flow chart of a test case execution method provided in an embodiment of the present application;

FIG3 is a flow chart of another test case execution method provided in an embodiment of the present application;

FIG4 is a structural block diagram of a test case execution device provided in an embodiment of the present application;

FIG5 is a schematic diagram of the hardware structure of a computing device provided in an embodiment of the present application.

DETAILED DESCRIPTION

The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

The term "and/or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects rather than to describe a specific order of objects. For example, a first target object and a second target object are used to distinguish different target objects rather than to describe a specific order of target objects.

In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" refers to two or more than two. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

Testing tools: refers to software or platforms used to help testers test servers or virtual machines. Testing tools can automatically execute test cases, thereby automating the testing process, reducing manual operations and improving testing efficiency.

Several testing tools are introduced below as examples.

Defect management testing tools: usually provide defect management capabilities, allowing testers to record, track and report defects found during the testing process. This helps ensure that defects are fixed in a timely manner and provides detailed information about defect status, repair progress and regression testing.

Performance testing tools: can simulate a large number of users' concurrent access and test the server's load capacity and performance. These tools can collect and analyze performance indicators to help testers identify performance bottlenecks and optimization opportunities.

Interface testing tools: can send requests and verify responses to ensure that the application's interface works as expected. These tools support multiple protocols and formats, enabling comprehensive testing of the functionality and performance of the API.

User Interface (UI) testing tools: can simulate user interactions with applications to verify whether the functions and appearance of UI elements meet the requirements. These tools can record user operations, generate test scripts, and automatically perform UI testing.

Security testing tools: used to detect security vulnerabilities and potential risks in software. These tools can perform tasks such as vulnerability scanning and penetration testing to help testers assess the security of software and take appropriate protective measures.

Currently, the server can use testing tools to execute test cases to automatically test whether the functions of the software and applications in the server meet expectations, whether some interfaces in the server can work properly, and whether there are security vulnerabilities and potential risks.

Furthermore, when executing test cases in the test tool, the server can call the main process and the main process can create multiple sub-processes to execute the test cases for testing. In some cases, the test tool needs to execute multiple test cases in sequence, that is, the main process needs to execute multiple test cases for testing. For example, the main process needs to execute test case A, test case B, and test case C for testing. Taking the test case currently executed by the main process as test case A as an example, as shown in Figure 1, when the main process executes test case A, it creates sub-processes A1, A2, and A3 to execute test case A. Resource competition and deadlock may occur between different sub-processes, which may lead to abnormal processes in the sub-processes executing test case A, resulting in the main process being unable to end the execution of test case A, causing the main process to be blocked and unable to continue to execute the next test case B.

In view of this, the present application provides a test case execution method and a server, which can obtain the process information of the test case, and then determine whether there is an abnormal process in the process of the test case based on the process information. When it is determined that there is an abnormal process in the process and the abnormal process is not a simulated abnormal process, the abnormal process is terminated. In this way, the present application can terminate the abnormal process that cannot execute the test task normally and is not simulated, and only retain the process that can execute the test case normally, thereby preventing the test process from being blocked. After the main process completes the execution of the currently executed test case, the next test case can be executed, thereby improving the efficiency of the test.

The test case execution method provided in this application can be applied to a computing device, which can be, for example, a server, which can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), and basic cloud computing services such as large databases and artificial intelligence platforms. When the above-mentioned server is a server cluster composed of multiple physical servers, or a distributed system, multiple physical servers can form a blockchain, and each physical server is a node on the blockchain. The physical type of the service area can be a rack server, a high-density server, a GPU server, a tower server, and can also be a blade server, a whole cabinet server, etc., which is not specifically limited in this application.

In conjunction with FIG. 2 , the execution logic of the test case execution method provided in the present application is introduced, which may be referred to as Embodiment 1. Taking the method in Embodiment 1 as an example in which the method is executed in a computing device and the operating system in the computing device is a Linux system, the method may include:

S201: Execute test.

The computing device may execute the test case for testing.

In some possible implementations, a computing device may perform tests using a testing tool, wherein the testing tools may include multiple types. For example, an interface testing tool, a UI testing tool, and a performance testing tool. The testing tool to be executed may be determined based on the test task posted by the user. For example, if the test task is to test the performance of the server, the computing device may determine that a performance testing tool needs to be executed. For example, if the test task is to test whether the interface of the server is working properly, the computing device may determine that an interface testing tool needs to be executed. After determining the test tool to be executed, a necessary test environment may be set up for the test tool. For example, this includes installing relevant software, configuring hardware, and setting up a network, and then deploying the determined test tool into the test environment and integrating the test framework into the test environment. This may include configuring test parameters and setting up a test execution plan. Finally, the computing device may execute the deployed test tool for testing.

Specifically, the computing device can use the deployed test tools to execute test cases for testing.

When executing test cases in a test tool, the computing device can call the main process corresponding to the test tool to execute the test cases. In some possible implementations, in order to improve test efficiency and better balance system load, the main process can also create sub-processes to jointly execute test cases.

In some possible implementations, before executing the deployed test tool for testing, the process may also be configured. The process configuration may include configuring the main process command and configuring the PID of the main process, wherein the PID refers to an identifier of each process, which is used to uniquely identify the process. The name of the process is generally a descriptive string so that the user can identify and understand the meaning of the process based on the process name. The process status may include running status, stopped status, sleeping status, and zombie status.

For example, the PID of the main process executing the test tool may be configured as 2216, so that the main process executing the test tool may be subsequently determined according to the PID.

In some possible implementations, in order to test the stability and reliability of the system when facing abnormal situations, and to evaluate the performance of the system when facing abnormal situations, when configuring the process, the server can also configure a simulated abnormal process, where the simulated abnormal process is a process used to simulate the occurrence of abnormal situations.

Exemplarily, before executing the test, code for simulating an abnormal process can be configured, such as "simulation":["command1", "command2"], which can represent that the code in the command1 and command2 lines is the code for configuring a simulated abnormal process. After the test is executed, when the test case is run, the computing device will save the PID of the process corresponding to the generated code in memory.

For example, after the test case is executed, the PID of the process corresponding to the code command1 is 2315, then the computing device can save 2315 in the memory, and subsequently determine whether the abnormal process is a simulated abnormal process based on the PID of the simulated abnormal process and whether the PID of the process matches.

S202: Obtain process information of the test process.

The computing device may obtain process information of the test process.

In some possible implementations, the computing device may use a monitoring tool (such as nmon, htop, glances, etc.) to obtain process information of the test process. The test process may be the process that executes the test case in step S201, and the obtained process information of the test process may include information of each sub-process in the main process, and the sub-process information may include a process identifier (exemplarily, PID) and a process status.

In some possible implementations, the child process information may further include a process name.

The process status can include the following states:

Running state: The process is running on the CPU and is in the execution state. A process that enters the running state can be called a running process.

Sleep state (also called blocking state): refers to the process pausing while waiting for an event, such as waiting for a resource to become available or waiting for I/O to complete. Even if the CPU is idle, the process cannot run. When the waiting condition is met, the process changes from the sleep state to the ready state.

Sleep states usually include: S (interruptible sleep) or D (non-interruptible sleep) state. Interruptible sleep (S state) state: refers to the process waiting for certain conditions to be ready, such as the completion of I/O operations, the arrival of signals, etc. When these conditions are met, the process can be awakened and continue to execute. Non-interruptible sleep (D state) state: The process is in an uninterruptible sleep state, usually used to wait for disk I/O operations to complete. In this state, the process cannot be awakened until the disk I/O operation is completed. A process that enters the sleep state can be called a sleeping process.

Stopped state: The process has completed the tasks it needs to perform, or terminated for some reason (such as an error). At this time, the operating system will handle the aftermath and release the resources occupied by the process. The process that enters the terminated state will no longer be executed, but will remain in the operating system waiting for the aftermath. Once other processes have completed the information extraction of the terminated process, the operating system will release the space it occupies. The process that enters the stopped state can be called a stopped process.

Zombie state: refers to when the child process ends before the parent process, and the parent process does not recycle the child process and release the resources occupied by the child process, the child process will become a zombie process. The process that enters the zombie state can be called a zombie process. The zombie process no longer occupies any system resources (such as memory, CPU, etc.) except the process table entry, but the process table entry is still retained in the memory to record the exit status and other related information of the zombie process.

In some possible implementations, the computing device may obtain the process status of a process in the following manner.

The computing device can execute the ps command to view the STAT column, and then view the process status of all test processes currently executing the test task, wherein the ps command is a command for reporting the process status of the current system.

When the server executes the ps command to view the STAT column, the server can determine the STAT column status code of each test process. The STAT column status code may include R, S, D, T, Z, and I.

Specifically, the meanings of different STAT column status codes are as follows:

The process with the status code R in the STAT column is a running process. The process status of the process is in the running state, which means that the process is running or waiting in the running queue.

The process with the status code S in the STAT column is a sleeping process. The process state of the process is in an interruptible sleeping state, indicating that the process is waiting for certain conditions to occur, such as waiting for an I/O operation to complete.

The process with the status code D in the STAT column is also a sleeping process. The process state of the process is in an uninterruptible sleeping state, which can also be called a disk hibernation state, indicating that the process is waiting for the disk I/O operation to complete. In this state, the process cannot be awakened until the disk I/O operation is completed.

The process with the status code T in the STAT column is a stopped process. The process status of the process is in the stopped state, indicating that the process has been stopped or is being tracked by a debugger.

The process with the status code Z in the STAT column is a zombie process. The process status of the process is in the zombie state, which means that the process has ended, but its parent process has not read its end status information.

The status code in the STAT column is I, indicating that the process status of the process is in idle state.

In this way, the computing device can view the STAT column by executing the ps command, and then obtain the process status of all test processes currently executing the test task.

S203: Determine whether there is an abnormal process based on the information of the test process.

After obtaining the process information of the test process, the computing device can determine whether there is an abnormal process based on the process information of the test process, where the abnormal process may be a process whose process status meets the preset abnormal conditions. The process whose process status meets the preset abnormal conditions refers to sleeping processes, zombie processes and other processes that cannot execute test tasks normally.

Exemplarily, the following is an introduction using the types of abnormal processes including sleep processes and zombie processes as examples. When there are processes with STAT column status codes of S, D, and Z, it can be determined that there are abnormal processes in the test process, that is, the process with STAT column status code of S or D is a sleep process, and the process with STAT column status code of Z is a zombie process.

Of course, the above description is only based on the example that the abnormal process includes the sleep process and the abnormal process. It should be noted that the abnormal process is not limited to only include the sleep process and the abnormal process.

In a possible implementation, the abnormal process may also include other processes, such as a stopped process.

In some possible implementations, after it is determined that there is an abnormal process in the test process, step S205 may be executed to process the abnormal process.

When it is determined that there is no abnormal process in the test process, you can wait for the test to end or execute steps S202 and S203 again after a preset interval to perform the next round of process status judgment, wherein the preset interval time can be set according to demand, for example, setting the preset interval time to 0.3 seconds, and there is no specific limitation on the preset interval time here.

In some possible implementations, when a computing device is pre-configured with a simulated abnormal process, after determining that an abnormal process exists in the test process, step S204 can be executed to determine whether the abnormal process is a pre-configured simulated abnormal process. It should be noted that the number of abnormal processes existing in the test process may be one or more.

S204: Determine whether there is a simulated abnormal process in the abnormal process.

The computing device may determine whether there is a simulated abnormal process in the abnormal process, thereby determining whether the abnormal process is a simulated abnormal process or a real abnormal process.

Further, when the number of abnormal processes is one, it can be determined whether the abnormal process is a simulated abnormal process. When the number of abnormal processes is multiple, it can be determined whether there is a simulated abnormal process among the multiple abnormal processes.

The following takes the case where the number of abnormal processes is one as an example.

Specifically, it can be determined whether the PID of the abnormal process is the PID of the simulated abnormal process stored in step 201. If so, it can be determined that the abnormal process is a simulated abnormal process. If not, it can be determined that the abnormal process is not a simulated abnormal process.

When it is determined that the abnormal process is a simulated abnormal process, the process can be retained because it is a simulated abnormal process rather than a real abnormal process.

When it is determined that the abnormal process is not a simulated abnormal process, the abnormal process may be processed.

S205: When there is a simulated abnormal process, the simulated abnormal process is retained, and the abnormal process that is not the simulated abnormal process is processed.

The computing device may retain the abnormal process that simulates the abnormal process, and then wait for the test to end or execute step S202 and step S203 again after a preset time interval to perform the next round of judgment on the process status.

Furthermore, the computing device processes the abnormal process that is not a simulated abnormal process, and can process the abnormal process according to the type of the abnormal process, that is, according to the type of the abnormal process, execute the corresponding process termination method to terminate the abnormal process. The types of abnormal processes here are introduced by taking sleep processes and zombie processes as examples.

In a possible implementation, when the server needs to process an abnormal process, it can determine a process termination method that matches the type of the abnormal process and then terminate the abnormal process using the process termination method that matches the type of the abnormal process. For example, when the type of the abnormal process is determined to be a sleeping process, the corresponding process termination method can be to execute a kill command. When the server executes the kill command, it can send a SIGTERM signal to the sleeping thread, where the SIGTERM signal is a signal requesting the process to terminate its operation. After receiving the SIGTERM signal, the sleeping process usually completes necessary cleanup work (such as closing files, releasing resources, etc.) and then terminates.

Since the zombie process itself has terminated, it is not possible to directly "kill" or "terminate" a zombie process. Therefore, when the abnormal process is determined to be a zombie process, the corresponding process termination method can be to recycle the zombie process using the parent process of the zombie process. That is, the parent process of the zombie process can be determined, and then the parent process can be used to call the wait() function or waitpid() function to recycle the zombie process.

In some possible implementations, the types of abnormal processes may include sleeping processes, zombie processes, and stopped processes. The process termination method of a stopped process may be the same as that of a sleeping process, namely, executing a kill command. When the server executes the kill command, a SIGTERM signal is sent to the stopped thread. After receiving the SIGTERM signal, the stopped process usually completes necessary cleanup work (such as closing files, releasing resources, etc.) and then terminates.

It can be understood that when there is no simulated abnormal process, the computing device can directly process the abnormal process that is not a simulated abnormal process.

In some possible implementation methods, in order to timely recycle the simulated exception process and avoid wasting system resources (such as memory, CPU time, etc.), the present application can also determine whether there are any unrecycled simulated exception processes after the execution of the currently executed test case is completed. When it is determined that there are unrecycled simulated exception processes, the unrecycled simulated exception processes are recycled.

In this application, the process information of the test case can be obtained, and then whether there is an abnormal process in the process of the test case can be determined based on the process information, wherein the abnormal process is a process whose process status meets the preset abnormal conditions. When it is determined that there is an abnormal process in the process, it can be further determined whether there is a simulated abnormal process in the abnormal process, that is, whether there is a simulated abnormal process in the abnormal process, and then the abnormal process that is not a simulated abnormal process can be terminated. In this way, in this application, the abnormal process that cannot execute the test task normally and is not simulated can be terminated, and only the process that can execute the test case normally can be retained, thereby preventing the test process from being blocked. After the main process executes the currently executed test case, the next test case can be executed, thereby improving the efficiency of the test.

The present application provides another embodiment, which is referred to as Embodiment 2. The difference between Embodiment 2 and Embodiment 1 is that in Embodiment 2, when it is determined that the abnormal process is not a simulated abnormal process, an attempt can be made to repair the abnormal process and after the abnormal process is processed for the first time, it can be further determined whether the abnormal process is successfully processed. If the abnormal process is not successfully processed, the abnormal process can be processed again by a preset forced termination method, which can improve the efficiency of the present application in processing abnormal processes and greatly reduce the probability of process blockage. The method of Embodiment 2 can also be applied to computing devices, as shown in FIG3, including:

S301: Execute test.

S302: Obtain process information of the test process.

S303: Determine whether there is an abnormal process according to the process information of the test process.

S304: Determine whether there is a simulated abnormal process in the abnormal process.

S305: When there is a simulated abnormal process, retain the simulated abnormal process.

The implementation and principle of steps S301-S305 are similar to those of steps S201-S205, and can be referred to the introduction in the first embodiment, and no redundant description is given here. It can be understood that in S305, when processing an abnormal process that is not a simulated abnormal process, the following S306-S310 can be included.

In this embodiment, when it is determined that there is an abnormal process that is not a simulated abnormal process, step S306 may be executed to determine whether the abnormal process can be repaired.

S306: Determine whether the abnormal process can be repaired according to the process status of the abnormal process that is not a simulated abnormal process.

The computing device can determine whether the abnormal process can be repaired according to the process status of the abnormal process (the types of abnormal processes are introduced by taking sleeping processes and zombie processes as examples).

When the abnormal process is a sleeping process and the process state is an interruptible sleeping state, that is, the STAT column status code is S, the abnormal process can be determined to be a repairable process. In addition, when the abnormal process is a stopped process, that is, the STAT column status code is T, the abnormal process can also be determined to be a repairable process.

When the abnormal process is a zombie process, that is, the STAT column status code is Z, the abnormal process can be determined to be an unrepairable process. In addition, when the abnormal process is a sleep process and is in an uninterruptible sleep state, that is, the STAT column status code is D, the abnormal process can also be determined to be an unrepairable process.

Specifically, a process in an interruptible sleep state is usually indicated by the status flag TASK_INTERRUPTIBLE. This sleep state allows a process to release CPU resources while waiting for a specific event so that other processes can use it. At the same time, it also provides a flexible mechanism so that the process can be awakened by other events during the waiting period. Therefore, when the abnormal process is a sleep process and the process state is an interruptible sleep state, that is, the STAT column status code is S, it can be determined that the abnormal process is a repairable process.

A process in the stopped state can also be awakened, mainly because a process in the stopped state generally enters the stopped state through a specific signal mechanism. For example, it is usually triggered by receiving a SIGSTOP signal. When a process is in this state, it is suspended and waits for further signals or operations. The process in the stopped state can be exited by sending a corresponding signal to it. Therefore, when the abnormal process is a stopped process, that is, the STAT column status code is T, it can be determined that the abnormal process is a repairable process.

A zombie process is a child process that ends and the parent process has not yet recovered the child process's resources. A zombie process is actually no longer running. It is just an entry reserved in the process table to record the child process's exit status and other information. Since a zombie process no longer executes any code, it cannot be awakened. Therefore, when the abnormal process is a zombie process, that is, the STAT column status code is Z, it can be determined that the abnormal process is an unrepairable process or when the abnormal process is a sleeping process in an uninterruptible sleeping state waiting for the disk I/O operation to complete, the process is in a blocked state and cannot perform other operations or be awakened by other processes or signals. It can only wait for the disk I/O operation to complete and the operating system to automatically wake up the process. Therefore, when the abnormal process is a sleeping process and is in an uninterruptible sleeping state, that is, the STAT column status code is D, it can be determined that the abnormal process is an unrepairable process.

When it is determined that the abnormal process is a repairable process, step S307 may be executed to repair the abnormal process.

When it is determined that the abnormal process is an unrepairable process, step S308 may be executed to process the abnormal process.

S307: Repair the abnormal process.

The computing device can repair the abnormal process.

Specifically, the computing device may use a repair method to repair the abnormal process.

Exemplary repair methods include, for example, executing a kill command to send a SIGCONT signal to the abnormal process, wherein the SIGCONT signal can be used to wake up the stopped process. Even for a process in an interruptible sleep state, sending SIGCONT is usually effective because it wakes up the process and allows it to continue execution.

In some possible implementations, after the computing device executes the repair method to repair the abnormal process, it can be determined whether the abnormal process is successfully repaired, that is, whether the abnormal process is successfully awakened.

Specifically, whether the process is repaired successfully can be determined according to the state of the abnormal process.

Exemplarily, for example, the type of abnormal process is a stopped process, that is, a process with a STAT column status code of T. The repair method can be used to repair the process, and then it can be determined whether the process state of the abnormal process has changed to a running state. That is, after the abnormal process is repaired using the repair method, it can be determined whether the STAT column status code of the abnormal process has changed from T to R. When it is determined that the STAT column status code of the abnormal process has changed from T to R, it can be determined that the process state of the abnormal process has changed to a running state, and then it can be determined that the abnormal process has been repaired successfully and the abnormal process has been successfully awakened.

For another example, after the abnormal process is repaired using the repair method, the STAT column status code of the abnormal process does not change, or changes to a status code other than R, which means that the repair of the abnormal process has failed and the abnormal process has not been successfully awakened.

When repairing the abnormal process fails, step S308 may be executed to terminate the abnormal process.

When the abnormal process is repaired successfully, you can wait for the test to end or execute steps S302 and S303 again after a preset interval to perform the next round of process status judgment, where the preset interval time can be set according to needs, for example, setting the preset interval time to 3s, and there is no limit on the preset interval time here.

S308: Terminate the abnormal process.

The method of handling the abnormal process is similar to the method of terminating in step S205, and no redundant description is given here.

In some possible implementations, the abnormal process can also be stack traced, and the problem can be located based on the stack trace information, that is, the cause of the abnormal process being abnormal can be located so that relevant personnel can take corresponding measures to repair it.

In some possible implementation methods, the abnormal processes can be integrated at preset time intervals, and then the integrated abnormal processes can be processed in batches. In this way, the abnormal processes can be integrated at preset time intervals and multiple abnormal processes can be processed in batches, which can reduce the number of times the exceptions are processed, thereby improving the utilization of system resources. The preset time period can be set according to actual needs, for example, it can be 0.5s, which is not limited here.

After terminating the abnormal process, the computing device may execute step S309 to determine whether the abnormal process is terminated successfully.

S309: Determine whether the abnormal process is terminated successfully.

The computing device can determine whether the abnormal process is terminated successfully, that is, determine whether the abnormal process still exists.

When it is determined that the abnormal process has not been successfully processed, step S310 may be executed to process the abnormal process by forcibly terminating the process.

S310: Terminate the abnormal process by forced termination.

The computing device can use the forced termination method to handle abnormal processes. It should be noted that in order to ensure that zombie processes and sleeping processes can be forced to terminate, the forced termination means for handling zombie processes and the forced termination means for handling sleeping processes must be different. Therefore, according to the type of abnormal process, a pre-set forced termination method that matches the abnormal process type can be determined to forcefully terminate the abnormal process. For example, the forced termination method corresponding to the forced termination of the sleeping process is to execute the kill-9 command, and the forced termination method corresponding to the forced termination of the zombie process is to execute the kill command or the kill-9 command to terminate the parent process of the zombie process.

Specifically, when the type of abnormal process is a sleeping process, the corresponding forced termination method may be to execute the kill-9 command. When the server executes the kill-9 command, a SIGKILL signal may be sent to the sleeping process. The SIGKILL signal is a forced termination signal that cannot be captured, blocked, or ignored by the process. When the sleeping process receives the SIGKILL signal, it will be terminated immediately, thereby forcibly terminating the sleeping process.

When the abnormal process is a zombie process, the corresponding forced termination method can be to execute the kill command or kill-9 command to terminate the parent process of the zombie process. When the parent process of the zombie process is terminated, the zombie process will become an orphan process and will eventually be taken over by the No. 1 process (also called the init process). When the No. 1 process becomes the parent process of the zombie process, it will be responsible for cleaning up the zombie process. The No. 1 process refers to the first user space process started by the kernel.

In some possible implementations, the abnormal process can also be processed by restarting the parent process of the zombie process.

Specifically, the parent process of the zombie process can be terminated in a similar manner as described above, and the zombie process will become an orphan process and eventually be taken over by process number one, which will then become the parent process of the zombie process and be responsible for cleaning up the zombie process. In this way, the zombie process can be forcibly terminated by restarting the parent process of the zombie process.

In some possible implementation methods, abnormal processes may also include sleeping processes, zombie processes, and stopped processes. For example, the means for forcibly terminating the stopped process may be the same as the means for forcibly terminating the sleeping process, namely, executing the kill-9 command. When the server executes the kill-9 command, it may send a SIGKILL signal to the stopped process. When the stopped process receives the SIGKILL signal, the stopped process may be immediately terminated, thereby achieving the forced termination of the abnormal process.

In this embodiment provided by the present application, when it is determined that the abnormal process is not a simulated abnormal process, an attempt can be made to repair the abnormal process, that is, whether the abnormal process is a repairable process can be determined. When the abnormal process is determined to be an unrepairable process, the abnormal process can be terminated, and when the termination of the abnormal process fails, the abnormal process can be further processed again according to the abnormal process type through a preset forced termination method, that is, the abnormal process is forcibly terminated through a preset forced termination method, thereby improving the efficiency of the present application in processing abnormal processes, thereby reducing the probability of process blockage.

The above is some specific implementation methods of the test case execution method provided in the embodiment of the present application. Based on this, the present application also provides a corresponding device. The device provided in the embodiment of the present application will be introduced from the perspective of functional modularization. The device and the test case execution method described above can be referenced to each other.

FIG4 is a structural block diagram of a test case execution device provided in an embodiment of the present application. Referring to FIG4 , the device may include:

The acquisition unit 400 is used to acquire the process information of the test case;

A first determining unit 410 is used to determine whether there is an abnormal process in the process of the test case according to the process information;

The second determining unit 420 is used to determine whether there is a simulated abnormal process in the abnormal process when there is an abnormal process in the process;

The processing unit 430 is used to retain the simulated abnormal process when there is one, and process the abnormal process that is not the simulated abnormal process.

In some possible implementations, the process information includes a process identifier, and the device may further include:

A configuration unit, used to configure the code for simulating abnormal processes;

A storage unit, used for storing a process identifier corresponding to the code in a memory when the code is executed;

The second determining unit is specifically configured to:

When the process identifier of the abnormal process matches the process identifier corresponding to the code, it is determined that a simulated abnormal process exists;

When the process identifier of the abnormal process does not match the process identifier corresponding to the code, it is determined that there is no simulated abnormal process.

In some possible implementations, the device may further include:

The recycling unit is used to recycle the simulated abnormal process that has not been recycled after the test case is executed when there is a simulated abnormal process.

In some possible implementations, the processing unit may be specifically configured to:

Determining, according to the type of the process, a process termination method of the process;

The process is terminated using a process termination method.

In some possible implementations, the device may further include:

a judging unit, configured to judge whether the abnormal process can be repaired according to the process state of the abnormal process which is not a simulated abnormal process;

The third determining unit is used to determine a process termination mode of the process when the abnormal process is determined to be an unrepairable process.

The hardware structure of the computing device of the present application is introduced below, referring to FIG5 , which is a schematic diagram of the hardware structure of a computing device provided in an embodiment of the present application.

As shown in FIG. 5 , the computing device 1000 includes a processor 1010 and a memory 1020 ; wherein the memory 1020 stores computer instructions, and the processor 1010 is used to execute the computer instructions, so that the computing device 1000 executes the test case execution method shown above.

In some embodiments, the processor 1010 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, transistor logic devices, hardware components or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

In some embodiments, the memory 1020 may be a volatile memory or a non-volatile memory, such as a register. Specifically, a volatile memory refers to a memory in which the data stored inside will be lost when the power supply is interrupted. Among them, the volatile memory is mainly a random access memory (RAM), including a static random access memory (SRAM) and a dynamic random access memory (DRAM). A non-volatile memory refers to a memory in which the data stored inside will not be lost even if the power supply is interrupted. Common non-volatile memories include read-only memory (ROM), optical disks, magnetic disks, solid-state hard disks, and various memory cards based on flash memory technology.

In some embodiments, the memory 1020 has executable code, and the memory 1010 executes the code to implement the test case execution method.

The communication interface 1030 is used for communicating with the outside. For example, the communication interface 1030 is used as a first interface to realize communication with a real device.

The bus may be a peripheral component interconnect standard (PCI) bus, or an extended industry standard architecture (eisa) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of understanding, FIG. 5 is represented by only one thick line, but it does not mean that there is only one bus or one type of bus. The embodiment of the present application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on a computing device, the computing device executes the above-mentioned test case execution method. The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc. The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned test case execution method.

In some possible implementations, the computing device may be a server, which is of course only an example and does not constitute any limitation.

The descriptions of the processes or structures corresponding to the above-mentioned figures have different emphases. For parts that are not described in detail in a certain process or structure, please refer to the relevant descriptions of other processes or structures.

The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (11)

1. A test case execution method, characterized in that the method comprises: Get the process information of the test case; Determine whether there is an abnormal process in the process of the test case according to the process information; When there is an abnormal process in the process, determining whether there is a simulated abnormal process in the abnormal process; When the simulated abnormal process exists, the simulated abnormal process is retained, and an abnormal process that is not the simulated abnormal process is processed. 2. The method according to claim 1, wherein the process information includes a process identifier, and before determining whether the abnormal process includes a simulated abnormal process, the method further includes: Configure the code to simulate abnormal processes; When the code is executed, a process identifier corresponding to the code is stored in a memory; Then the step of determining whether the abnormal process includes a simulated abnormal process includes: When there is a match between the process identifier of the abnormal process and the process identifier corresponding to the code, it is determined that a simulated abnormal process exists; When the process identifier of the abnormal process does not match the process identifier corresponding to the code, it is determined that there is no simulated abnormal process. 3. The method according to any one of claims 1 to 2, characterized in that the method further comprises: When the simulated abnormal process exists, the simulated abnormal process that is not recovered after the test case is executed is recovered. 4. The method according to any one of claims 1 to 3, characterized in that the processing is not an abnormal process of the simulated abnormal process, comprising: Determining a process termination method of the abnormal process according to the type of the abnormal process; The abnormal process is terminated by using the process termination method. 5. The method according to claim 4, characterized in that before determining the process termination mode of the process according to the type of the process, the method further comprises: Determining whether the abnormal process can be repaired according to the process state of the abnormal process that is not a simulated abnormal process; When it is determined that the abnormal process is an unrepairable process, a process termination method of the abnormal process is determined. 6. A test case execution device, characterized in that the device comprises: An acquisition unit is used to obtain the process information of the test case; A first determining unit, configured to determine whether there is an abnormal process in the process of the test case according to the process information; a second determining unit, configured to determine, when an abnormal process exists in the process, whether the abnormal process has a simulated abnormal process; The processing unit is used to retain the simulated abnormal process when it exists, and process the abnormal process that is not the simulated abnormal process. 7. The device according to claim 6, wherein the process information includes a process identifier, and the device further comprises: A configuration unit, used to configure the code for simulating abnormal processes; A storage unit, used for storing a process identifier corresponding to the code in a memory when the code is executed; The second determining unit is specifically configured to: When the process identifier of the abnormal process matches the process identifier corresponding to the code, determining that a simulated abnormal process exists; When the process identifier of the abnormal process does not match the process identifier corresponding to the code, it is determined that there is no simulated abnormal process. 8. The device according to any one of claims 6 to 7, characterized in that the device further comprises: The recycling unit is used to recycle the simulated abnormal process that has not been recycled after the test case is executed when the simulated abnormal process exists. 9. The device according to any one of claims 6 to 8, characterized in that the processing unit is specifically used to: Determining a process termination method of the abnormal process according to the type of the abnormal process; The abnormal process is terminated by using the process termination method. 10. The device according to claim 9, characterized in that the device further comprises: A judging unit, configured to judge whether the abnormal process can be repaired according to the process state of the abnormal process which is not a simulated abnormal process; The third determining unit is used to determine a process termination mode of the abnormal process when the abnormal process is determined to be an unrepairable process. 11. A server, comprising a memory and a processor; a memory and a processor, the memory being coupled to the processor; The memory stores program instructions, and when the program instructions are executed by the processor, the server executes the method according to any one of claims 1 to 5.