An alarm rate detection method, device, equipment and storage medium

Abstract

Embodiments of the present application provide a kind of alarm rate detection method, device, equipment and storage medium, the method can create and target test equipment same and one-to-one corresponding coroutine, then call each coroutine continuously through the way of mutual exclusion, constantly from the ordered acquisition of preset rule set in measured rule package, then measured rule package is sent to target test equipment to carry out the test of rule package, each coroutine can be realized uninterrupted continuous testing, and after completing the test of all measured rule package, the alarm result of each measured rule package is determined and alarm rate is determined, without waiting target test equipment to spit alarm after each time sending rule package, so that the test efficiency of rule package can be improved.

Description

An alarm rate detection method, apparatus, device and storage medium Technical Field

[0001] This application relates to the field of network testing technology, and in particular to an alarm rate detection method, apparatus, device, and storage medium. Background Technology

[0002] We conducted simulated attack tests on versions of some products and verified the test results as expected, involving thousands of rule packages.

[0003] Currently, when testing these rule packages, it is necessary to replay them one by one, wait for a certain period of time after each replay, wait for the test device to alarm, and then perform the expected verification after the alarm, until all the rule packages that need to be tested have been replayed, which is very time-consuming. Summary of the Invention

[0004] This application provides an alarm rate detection method, apparatus, device, and storage medium to improve the testing efficiency of rule packages.

[0005] In a first aspect, embodiments of this application provide an alarm rate detection method, including:

[0006] Create a number of coroutines equal to the number of target test devices, and load multiple test rule packages one by one into a preset rule set, wherein each coroutine corresponds to one of the target test devices;

[0007] For any given coroutine, the coroutine continuously retrieves test rule packages from the preset rule set using a mutex lock, based on the actual resource lock acquisition status. The retrieved test rule packages are then sent to the target test device corresponding to the coroutine, while the retrieved test rule packages are simultaneously deleted from the preset rule set.

[0008] After all test rule packets have been sent, the alarm result of each test rule packet is determined based on the alarm status of the target test device during the sending of each test rule packet.

[0009] Based on the alarm results of each rule package to be tested, the alarm rate is determined.

[0010] In some embodiments, prior to creating the number of coroutines equal to the target number of test devices, the method further includes:

[0011] Based on the network connection status of each test device, the target test device is determined from among the test devices.

[0012] In some embodiments, determining the target test device from among the test devices based on the network connection status of each test device includes:

[0013] Obtain the ping and SSH connection status of each test device;

[0014] If both the ping connection status and the SSH connection status are online, then the test device is determined to be the target test device.

[0015] In some embodiments, determining the alarm result of each rule packet under test based on the alarm status of the target test device during the transmission of each rule packet under test includes:

[0016] If the target test device has an alarm status during the transmission of each of the rule packets under test, then the alarm result of each rule packet under test is determined as the first alarm result used to characterize the performance of each rule packet under test; or

[0017] If the alarm status of the target test device is no alarm during the transmission of each of the rule packets to be tested, then the alarm result of each rule packet to be tested is determined as a second alarm result used to characterize the performance of each rule packet to be tested.

[0018] In some embodiments, after determining the alarm result of each of the rule packages to be tested as the first alarm result, the method further includes:

[0019] Based on the rule identifier of each rule packet to be tested and the alarm identifier of the target test device during the transmission of each rule packet to be tested, the alarm type of each rule packet to be tested is determined.

[0020] In some embodiments, determining the alarm type of each rule packet under test based on the rule identifier of each rule packet under test and the alarm identifier of the target test device during the transmission of each rule packet under test includes:

[0021] If the rule identifier of each of the rule packets under test is the same as the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the first alarm type used to characterize the performance of each rule packet under test; or

[0022] If the rule identifier of each rule packet under test is different from the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the second alarm type used to characterize the performance of each rule packet under test.

[0023] Secondly, embodiments of this application also provide an alarm rate detection device, comprising:

[0024] A creation unit is used to create the same number of coroutines as the target test devices, and to load multiple test rule packages one by one into a preset rule set, wherein the coroutines correspond one-to-one with the target test devices;

[0025] The calling unit is used to call any coroutine to continuously obtain test rule packages from the preset rule set through a mutex lock according to the actual resource lock acquisition situation, and send the obtained test rule packages to the target test device corresponding to the coroutine, while deleting the obtained test rule packages from the preset rule set.

[0026] The first determining unit is used to determine the alarm result of each rule packet under test based on the alarm status of the target test device during the transmission of each rule packet under test after all the rule packets under test have been sent.

[0027] The second determining unit is used to determine the alarm rate based on the alarm results of each of the rule packets to be tested.

[0028] In some embodiments, a third determining unit is also included;

[0029] The third determining unit is used to determine the target test device from among the test devices based on the network connection status of each test device.

[0030] In some embodiments, the third determining unit is specifically used for:

[0031] Obtain the ping and SSH connection status of each test device;

[0032] If both the ping connection status and the SSH connection status are online, then the test device is determined to be the target test device.

[0033] In some embodiments, the first determining unit is specifically used for:

[0034] If the target test device has an alarm status during the transmission of each of the rule packets under test, then the alarm result of each rule packet under test is determined as the first alarm result used to characterize the performance of each rule packet under test; or

[0035] If the alarm status of the target test device is no alarm during the transmission of each of the rule packets to be tested, then the alarm result of each rule packet to be tested is determined as a second alarm result used to characterize the performance of each rule packet to be tested.

[0036] In some embodiments, the first determining unit is further configured to:

[0037] Based on the rule identifier of each rule packet to be tested and the alarm identifier of the target test device during the transmission of each rule packet to be tested, the alarm type of each rule packet to be tested is determined.

[0038] In some embodiments, the first determining unit is specifically used for:

[0039] If the rule identifier of each of the rule packets under test is the same as the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the first alarm type used to characterize the performance of each rule packet under test; or

[0040] If the rule identifier of each rule packet under test is different from the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the second alarm type used to characterize the performance of each rule packet under test.

[0041] This application provides an alarm rate detection method, apparatus, device, and storage medium. The method includes creating a number of coroutines equal to the number of target test devices, and loading multiple test rule packages one by one into a preset rule set, wherein each coroutine corresponds one-to-one with a target test device; for any given coroutine, the coroutine continuously retrieves test rule packages from the preset rule set using a mutex lock according to the actual resource lock acquisition status, and sends the retrieved test rule packages to the target test device corresponding to the coroutine, while simultaneously deleting the retrieved test rule packages from the preset rule set; after all test rule packages have been sent, the alarm result of each test rule package is determined based on the alarm status of the target test device during the sending of each test rule package; and the alarm rate is determined based on the alarm results of each test rule package. Because it is possible to create coroutines that correspond one-to-one with the number of target test devices, and then call each coroutine to continuously and orderly obtain test rule packages from the preset rule set through mutex locks, and then send the test rule packages to the target test devices for testing, it is possible to achieve uninterrupted continuous testing of each coroutine. Furthermore, after completing the testing of all test rule packages, the alarm results and alarm rates of each test rule package are uniformly determined, without having to wait for the target test device to output alarms after each rule package is sent, thereby improving the testing efficiency of rule packages. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 is a flowchart illustrating an alarm rate detection method provided in an embodiment of this application;

[0044] Figure 2 is a schematic diagram showing the correspondence between a target testing device and a coroutine provided in an embodiment of this application;

[0045] Figure 3 is a schematic diagram of the dictionary structure inside a coroutine provided in an embodiment of this application;

[0046] Figure 4a is a schematic diagram of the dictionary structure inside a coroutine for determining alarm results and alarm types according to an embodiment of this application;

[0047] Figure 4b is a schematic diagram of the dictionary structure inside the coroutine for determining alarm results and alarm types, provided in another embodiment of this application.

[0048] Figure 4c is a schematic diagram of the dictionary structure inside the coroutine for determining alarm results and alarm types according to another embodiment of this application;

[0049] Figure 4d is a schematic diagram of the dictionary structure inside the coroutine for determining alarm results and alarm types, provided in another embodiment of this application.

[0050] Figure 5 is a schematic diagram of an alarm rate detection device provided in an embodiment of this application;

[0051] Figure 6 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art are within the scope of protection of this application.

[0053] Currently, when conducting simulated attack tests on rule packets, a serial approach is used. Performing tens of thousands of simulated attack tests is inherently time-consuming. After conducting a simulated attack test on each rule packet, a certain amount of time needs to be waited for the device to issue an alarm for verification. The total time spent waiting for the device to issue an alarm is: the time spent waiting for the device to issue an alarm for each simulated attack test multiplied by the total number of rule packets in the simulated attack tests. In other words, the more rule packets there are, the more time-consuming it becomes.

[0054] In addition, to improve testing efficiency, multiple testing devices can be used to test the rule package simultaneously. However, currently, when using multiple testing devices, the rule package is manually assigned to the corresponding testing devices to execute the test scripts. After all devices have completed testing, statistics need to be manually compiled. During the testing process, some testing devices have already completed testing while others are still in the process, which is a serious time-consuming issue. Furthermore, due to human involvement, there may be some errors that affect the test results.

[0055] To improve the testing efficiency of rule packages, this application provides an alarm rate detection method, as shown in Figure 1. The method includes:

[0056] S101. Create the same number of coroutines as the target test devices, and load multiple test rule packages one by one into the preset rule set, where each coroutine corresponds to a target test device.

[0057] S102. For any coroutine, the coroutine continuously obtains the test rule package from the preset rule set through the mutex lock according to the actual resource lock acquisition situation, and sends the obtained test rule package to the target test device corresponding to the coroutine, while deleting the obtained test rule package from the preset rule set.

[0058] S103. After all test rule packets have been sent, determine the alarm result of each test rule packet based on the alarm status of the target test device during the sending of each test rule packet.

[0059] S104. Determine the alarm rate based on the alarm results of each rule package to be tested.

[0060] The alarm rate detection method provided in this application embodiment can create coroutines that are the same number as the number of target test devices and correspond one-to-one. Then, each coroutine is called to continuously and orderly obtain test rule packets from a preset rule set through a mutex lock. The test rule packets are then sent to the target test devices for testing. This can achieve uninterrupted continuous testing for each coroutine. After the testing of all test rule packets is completed, the alarm results of each test rule packet are uniformly determined and the alarm rate is determined. There is no need to wait for the target test device to output an alarm after each rule packet is sent, thereby improving the testing efficiency of rule packets.

[0061] It is worth noting that in this embodiment, the sending of the rule package under test is equivalent to the playback of the rule package under test in related technologies, which is the testing process of the rule package under test. If the test device generates a corresponding alarm during the sending of the rule package under test to the test device, it means that the corresponding rule package under test is performing well and can achieve its corresponding function. If there is no alarm, it means that the corresponding rule package under test has a problem. By testing thousands of rule packages under test and determining the alarm rate based on the alarm results of each rule package under test, the performance of the corresponding product version can be characterized.

[0062] In some embodiments, before creating the same number of coroutines as the target test devices, the method may further include: determining the target test devices from among the test devices based on the network connection status of each test device.

[0063] Specifically, the ping and SSH connection statuses of each test device can be obtained. If both the ping and SSH connection statuses are online, the test device is identified as the target test device. Each test device can be a pre-configured device corresponding to its version, and can be presented as a device list. Then, based on the ping and SSH connection statuses, the system automatically determines the target test device that can be used to test the execution version. Only when both the ping and SSH connection statuses are online is the device identified as the target test device.

[0064] Since it is necessary to create the same number of coroutines as the target test devices, and then call each coroutine to perform rule package testing on the corresponding target test devices, if the determined target test devices have problems and cannot run, then the corresponding coroutines will also be unable to perform the corresponding tests, resulting in wasted resources and affecting testing efficiency. Therefore, it is essential to accurately determine the target test devices.

[0065] The prerequisite for ensuring the reliable operation of the target test device is that the network status must be connected. If only the ping connection status is online, it cannot necessarily guarantee that the network status of the target test device is connected. Therefore, this application provides a method for determining the target test device. The target test device can be quickly and accurately determined by the ping connection status and SSH connection status, thereby improving the testing efficiency.

[0066] In practice, based on the number of target test devices obtained, the main process dynamically creates coroutines equal to the number of target test devices. Simultaneously, a dictionary is created, using the coroutines as keys and the target test devices as values, corresponding one-to-one. For example, as shown in Figure 2, taking 3 coroutines and 3 target test devices as an example, coroutine 1 corresponds to target test device 1, coroutine 2 corresponds to target test device 2, and coroutine 3 corresponds to target test device 3.

[0067] The preset rule set in this application embodiment can be, for example, a rule table. After creating the same number of coroutines as the target test devices, the full paths of multiple test rule packages can be loaded into the rule table by traversing them one by one. The rule table can record the rule identifiers, i.e., rule IDs, of all test rule packages. By traversing the paths of the test rule packages and saving the obtained data as binary data, if no new test rule IDs are added, the binary data can be directly read into memory in subsequent tests, thereby accelerating the acquisition of test rule packages by each coroutine.

[0068] In practice, each coroutine continuously retrieves test rule packages from the preset rule set. Each coroutine can retrieve test rule packages according to the loading order of the test rule packages based on its own resource preemption situation (for example, always retrieving the last loaded test rule package in the current preset rule set). Here, a pop method can be used to retrieve them, that is, each time the rule ID of a test rule package is retrieved, and after retrieving the rule ID of the test rule package is removed from the preset rule set, so as to ensure that each test rule package is tested only once. Since there are multiple coroutines, when a test rule package is retrieved by a coroutine, by deleting the test rule package from the preset rule set, other coroutines will not retrieve the rule package again, which can ensure that a test rule package is tested only once, thereby ensuring the accuracy of the final alarm rate.

[0069] It's worth noting that each goroutine simultaneously and continuously acquires the rule packages to be tested from the preset rule set using mutex locks. The acquisition of these rule packages depends on the goroutine's actual acquisition of the resource lock. In other words, each goroutine continuously initiates the acquisition of the rule table (preset rule set) resource. When any goroutine discovers that the rule table resource is available, it will lock it (other goroutines will be unable to occupy it). During the lock-up period, it will extract the last rule package to be tested from the rule table, delete this rule package from the table, and then release the lock-up of the rule table resource for other goroutines to acquire. If a goroutine acquires this resource first, it will obtain the complete rule table containing all the rule packages to be tested. After various goroutines continuously acquire and delete these packages, this table resource will eventually be exhausted, indicating that all the rule packages to be tested have been acquired. For example, before goroutine 1 requests to retrieve the rule packet to be tested from the preset rule set, it first checks whether the preset rule set is locked. If it is unlocked, it locks it. After retrieving the rule packet to be tested, it unlocks the preset rule set. At this point, goroutine 3 finds the preset rule set is unlocked, locks it again, retrieves the rule packet to be tested, and then unlocks it again, and so on. By retrieving the rule packet to be tested in this way, after each goroutine has completed sending its rule packet, it repeatedly retrieves the rule packets to be tested from the preset rule set until all the rule packets to be tested in the preset rule set have been retrieved. This achieves uninterrupted continuous testing for each goroutine, achieving dynamic resource balancing and thus improving overall testing efficiency.

[0070] In some embodiments, determining the alarm result of each rule packet under test based on the alarm status of the target test device during the transmission of each rule packet under test may include:

[0071] If the target test device has an alarm status during the transmission of each rule packet under test, the alarm result of each rule packet under test is determined as the first alarm result used to characterize the performance of each rule packet under test; or if the target test device has no alarm status during the transmission of each rule packet under test, the alarm result of each rule packet under test is determined as the second alarm result used to characterize the performance of each rule packet under test.

[0072] For example, the start time of sending a certain rule packet to be tested is 2:20:00 and the end time is 2:21:00. Taking the sending duration of a certain rule packet to be tested as 1 minute as an example, if the target test device has an alarm during the sending process, the alarm result is determined as the first alarm result. If there is no alarm during the sending process, the alarm result is determined as the second alarm result.

[0073] In some embodiments, after determining the alarm result of each rule packet under test as the first alarm result, the method may further include: determining the alarm type of each rule packet under test based on the rule identifier of each rule packet under test and the alarm identifier of the target test device during the transmission of each rule packet under test.

[0074] Specifically, if the rule identifier of each rule packet under test is the same as the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the first alarm type used to characterize the performance of each rule packet under test; or

[0075] If the rule identifier of each rule packet under test is different from the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the second alarm type used to characterize the performance of each rule packet under test.

[0076] In this embodiment, the alarm result and alarm type are determined by the dictionary within each coroutine. The dictionary structure within each coroutine is shown in Figure 3. The rule ID of the rule packet to be tested is used as the key, and the value is a list containing 5 elements. The first element t1 is the time when the rule packet to be tested is sent, the second element t2 is the time when the rule packet to be tested is sent, the third element ruleid is the alarm identifier of the target test device, the fourth element time is the alarm time of the target test device, and the fifth element flag is the judgment of the alarm result and alarm type.

[0077] The rules for determining alarm results and alarm types can be as follows:

[0078] 1. If the target test device generates an alarm during the transmission of the rule packet under test, and the alarm identifier is completely consistent with the rule ID of the rule packet under test, then the alarm result is determined to be the first alarm result, and the alarm type is the first alarm type. As shown in Figure 4a, if an alarm occurs at 2:20:30 and during the transmission process (2:20:00-2:21:00), the alarm identifier and the rule ID of the rule packet under test are both 01, which are completely consistent. Therefore, the fifth element, flag, can be marked as 0.

[0079] 2. If the target test device generates an alarm during the transmission of the rule packet under test, and the alarm identifier matches the rule ID of the rule packet under test, and there are also alarm identifiers that do not match the rule ID, i.e., there are multiple alarm identifiers, one of which matches the rule ID of the rule packet under test, then the alarm result is determined to be the first alarm result, and the alarm type is the first alarm type. As shown in Figure 4b, there are two alarm identifiers (01 and 10). The alarm time of alarm identifier 01 (2:20:30) and the alarm time of alarm identifier 10 (2:20:35) are both during the transmission of the rule packet under test (2:20:00-2:21:00). Alarm identifier 01 matches the rule ID of the rule packet under test, while alarm identifier 10 does not match the rule ID of the rule packet under test. The fifth element, flag, can be marked as 1.

[0080] 3. If the target test device generates an alarm during the transmission of the rule packet under test, and the alarm identifier is different from the rule ID of the rule packet under test, then the alarm result is determined to be the first alarm result, and the alarm type is the second alarm type. As shown in Figure 4c, the fifth element, flag, can be marked as 2.

[0081] 4. If the target test device does not issue any alarms during the transmission of the rule packet to be tested (marked as none), then the alarm result is determined as the second alarm result. As shown in Figure 4d, the fifth element, flag, can be marked as 3.

[0082] After the data is written to the dictionary within each coroutine, it can be sent to the main process. The main process waits for the signal that all coroutines have completed their tasks before merging the dictionaries. Then, it verifies whether the number of keys in the merged dictionary matches the number of rule packets in the preset rule set. If they do not match, it means that packet loss or other problems may have occurred.

[0083] Finally, the alarm rate can be determined based on the alarm results of each rule package under test. Of course, the number of successful alarms, the number of failed alarms, the number of false alarms, etc. can also be determined. Specifically, the data in the dictionary inside the merged coroutine can be directly read and the corresponding calculations and statistics can be performed.

[0084] The alarm rate detection method provided in this application can improve the testing efficiency of rule packets. For example, in the prior art, simulating an attack test with 10,000 rule packets, each rule packet waits for the device to output an alarm for 10 seconds, and the total time is 10,000 * 10 seconds ≈ 28 hours. However, by using the alarm rate detection method provided in this application, multiple coroutines can be directly called to obtain rule packets. After the test of all rule packets is completed, the alarm result is determined uniformly without waiting, which can save 28 hours. The whole process does not require manual intervention and can avoid the impact of human intervention errors on the test results.

[0085] Based on the same concept, this application also provides an alarm rate detection device. The implementation of this device can refer to the implementation of the above method, and repeated details will not be elaborated further. As shown in Figure 5, the alarm rate detection device includes:

[0086] Create unit 501, which is used to create the same number of coroutines as the target test devices, and load multiple test rule packages one by one into the preset rule set, wherein the coroutines correspond one-to-one with the target test devices;

[0087] Calling unit 502 is used to call any coroutine to continuously obtain test rule packages from the preset rule set through a mutex lock according to the actual resource lock preemption situation, and send the obtained test rule packages to the target test device corresponding to the coroutine, while deleting the obtained test rule packages from the preset rule set.

[0088] The first determining unit 503 is used to determine the alarm result of each rule packet under test based on the alarm status of the target test device during the transmission of each rule packet under test after all the rule packets under test have been sent.

[0089] The second determining unit 504 is used to determine the alarm rate based on the alarm results of each rule package to be tested.

[0090] In some embodiments, a third determining unit is also included;

[0091] The third determining unit is used for:

[0092] Based on the network connection status of each test device, the target test device is determined from among the test devices.

[0093] In some embodiments, the third determining unit is specifically defined as:

[0094] Obtain the ping and SSH connection status of each test device;

[0095] If both the ping and SSH connection statuses are online, then the test device is determined to be the target test device.

[0096] In some embodiments, the first determining unit 503 is specifically used for:

[0097] If the target test device has an alarm status during the transmission of each rule packet under test, then the alarm result of each rule packet under test is determined as the first alarm result used to characterize the performance of each rule packet under test; or

[0098] If the alarm status of the target test device is no alarm during the transmission of each rule packet under test, then the alarm result of each rule packet under test is determined as the second alarm result used to characterize the performance of each rule packet under test.

[0099] In some embodiments, the first determining unit 503 is further configured to:

[0100] Based on the rule identifier of each rule packet under test and the alarm identifier of the target test device during the transmission of each rule packet under test, the alarm type of each rule packet under test is determined.

[0101] In some embodiments, the first determining unit 503 is specifically used for:

[0102] If the rule identifier of each rule packet under test is the same as the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the first alarm type used to characterize the performance of each rule packet under test; or

[0103] If the rule identifier of each rule packet under test is different from the alarm identifier of the target test device during the transmission of each rule packet under test, then the alarm type of each rule packet under test is determined to be the second alarm type used to characterize the performance of each rule packet under test.

[0104] Based on the same inventive concept, this application also provides an electronic device, the implementation of which can refer to the implementation of the above method, and the repeated parts will not be described again. As shown in FIG6, the electronic device includes a memory 601 and a processor 602;

[0105] Memory 601 is used to store instructions;

[0106] The processor 602 is used to execute instructions stored in the memory 601. When the processor 602 executes the instructions stored in the memory, the device performs the alarm rate detection method described in any of the preceding claims.

[0107] Furthermore, embodiments of the present invention also provide a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the alarm rate detection method described in any of the preceding embodiments.

[0108] This application provides an alarm rate detection method, apparatus, device, and storage medium. The method includes creating a number of coroutines equal to the number of target test devices, and loading multiple test rule packages one by one into a preset rule set, wherein each coroutine corresponds one-to-one with a target test device; for any given coroutine, the coroutine continuously retrieves test rule packages from the preset rule set using a mutex lock according to the actual resource lock acquisition status, and sends the retrieved test rule packages to the target test device corresponding to the coroutine, while simultaneously deleting the retrieved test rule packages from the preset rule set; after all test rule packages have been sent, the alarm result of each test rule package is determined based on the alarm status of the target test device during the sending of each test rule package; and the alarm rate is determined based on the alarm results of each test rule package. Because it is possible to create coroutines that correspond one-to-one with the number of target test devices, and then call each coroutine to continuously and orderly obtain test rule packages from the preset rule set through mutex locks, and then send the test rule packages to the target test devices for testing, it is possible to achieve uninterrupted continuous testing of each coroutine. Furthermore, after completing the testing of all test rule packages, the alarm results and alarm rates of each test rule package are uniformly determined, without having to wait for the target test device to output alarms after each rule package is sent, thereby improving the testing efficiency of rule packages.

[0109] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied 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.

[0110] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0113] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for detecting alarm rate, characterized in that, include: Create a number of coroutines equal to the number of target test devices, and load multiple test rule packages one by one into a preset rule set, wherein each coroutine corresponds one-to-one with the target test device; for any coroutine, continuously retrieve test rule packages from the preset rule set using a mutex lock according to the actual resource lock acquisition status, send the retrieved test rule packages to the target test device corresponding to the coroutine, and delete the retrieved test rule packages from the preset rule set; After all test rule packets have been sent, the alarm result of each test rule packet is determined based on the alarm status of the target test device during the sending of each test rule packet; and the alarm rate is determined based on the alarm result of each test rule packet.

2. The alarm rate detection method as described in claim 1, characterized in that, Before creating the same number of coroutines as the target test devices, the method further includes: determining the target test devices from among the test devices based on the network connection status of each test device.

3. The alarm rate detection method as described in claim 2, characterized in that, The step of determining the target test device from among the test devices based on the network connection status of each test device includes: obtaining the ping connection status and SSH connection status of each test device; if both the ping connection status and the SSH connection status are online, then the test device is determined to be the target test device.

4. The alarm rate detection method as described in claim 1, characterized in that, The step of determining the alarm result of each rule packet under test based on the alarm status of the target test device during the transmission of each rule packet under test includes: if the alarm status of the target test device is "alarm present" during the transmission of each rule packet under test, then the alarm result of each rule packet under test is determined as a first alarm result used to characterize the performance of each rule packet under test; or if the alarm status of the target test device is "no alarm present" during the transmission of each rule packet under test, then the alarm result of each rule packet under test is determined as a second alarm result used to characterize the performance of each rule packet under test.

5. The alarm rate detection method as described in claim 4, characterized in that, After determining the alarm result of each of the rule packets to be tested as the first alarm result, the method further includes: determining the alarm type of each rule packet to be tested based on the rule identifier of each rule packet to be tested and the alarm identifier of the target test device during the transmission of each rule packet to be tested.

6. The alarm rate detection method as described in claim 5, characterized in that, The step of determining the alarm type of each rule packet under test based on the rule identifier of each rule packet under test and the alarm identifier of the target test device during the transmission of each rule packet under test includes: if the rule identifier of each rule packet under test and the alarm identifier of the target test device during the transmission of each rule packet under test are the same, then the alarm type of each rule packet under test is determined to be a first alarm type used to characterize the performance of each rule packet under test; or if the rule identifier of each rule packet under test and the alarm identifier of the target test device during the transmission of each rule packet under test are different, then the alarm type of each rule packet under test is determined to be a second alarm type used to characterize the performance of each rule packet under test.

7. An alarm rate detection device, characterized in that, include: A creation unit is used to create the same number of coroutines as the target test devices, and load multiple test rule packages one by one into a preset rule set, wherein each coroutine corresponds one-to-one with the target test device; a calling unit is used to, for any coroutine, continuously retrieve test rule packages from the preset rule set through a mutex lock according to the actual resource lock acquisition situation, send the retrieved test rule packages to the target test device corresponding to the coroutine, and delete the retrieved test rule packages from the preset rule set. The first determining unit is used to determine the alarm result of each rule packet under test based on the alarm status of the target test device during the transmission of each rule packet under test after all the rule packets under test have been sent. The second determining unit is used to determine the alarm rate based on the alarm results of each of the rule packets to be tested.

8. The alarm rate detection device as described in claim 7, characterized in that, It also includes a third determining unit, which is used to: determine the target test device from among the test devices based on the network connection status of each test device.

9. An electronic device, characterized in that, The device includes a memory and a processor; the memory is used to store instructions; the processor is used to execute the instructions stored in the memory, such that when the processor executes the instructions stored in the memory, the electronic device performs the method as described in any one of claims 1-6.

10. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed on the computer, cause the computer to perform the method as described in any one of claims 1-6.

Images