Pressure measurement protocol coverage rate detection method and device, equipment and medium

Abstract

The invention provides a pressure test protocol coverage rate detection method and device, equipment and a medium, and the method comprises the steps: carrying out the pressure test of a target test case in response to a test instruction, and obtaining the protocol attribute data of at least two pressure test stages, performing coverage rate calculation on the protocol attribute data of the at least two pressure measurement stages to obtain a target coverage rate of the target protocol; wherein the protocol attribute data is attribute data associated with the target protocol, and the target protocol is deployed in the target test case. According to the technical scheme of the embodiment, the protocol attribute data of the different pressure testing stages are obtained through the multi-stage pressure testing, the protocol attribute data reflect the performance of the target protocol in the different pressure testing stages, coverage rate calculation is carried out on the basis, protocol behaviors in the different pressure testing stages can be comprehensively covered, and the coverage rate of the target protocol is improved. Therefore, the detection precision of the protocol coverage rate in the pressure test is effectively improved, and the method can be widely applied to the technical field of computers.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, equipment and medium for testing the coverage of a stress test protocol. Background Technology

[0002] Stress testing is a testing method that evaluates a system's stability, reliability, and error handling capabilities by simulating extreme loads or resource constraints. Protocol coverage refers to the coverage of protocols during stress testing. Protocol coverage detection is an indispensable evaluation tool in stress testing, as it verifies the integrity and correctness of protocols under extreme loads, thereby reasonably assessing the system's stability and fault tolerance.

[0003] In related technologies, test cases are typically subjected to single-stage stress testing, and protocol coverage is determined based on the results of this single-stage stress test, thus enabling the detection of protocol coverage during stress testing. However, these technologies rely solely on the results of single-stage stress tests to detect protocol coverage, which makes it difficult to comprehensively reflect the objective situation of protocol coverage, resulting in low accuracy in protocol coverage detection. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a method, apparatus, device, and medium for detecting protocol coverage under stress testing, which can improve the detection accuracy of protocol coverage in stress testing.

[0005] On one hand, embodiments of this application provide a method for detecting the coverage of a stress testing protocol, including: In response to a test command, stress tests are performed on the target test case to obtain protocol attribute data for at least two stress test phases; wherein, the protocol attribute data is used to indicate attribute data associated with the target protocol, which is deployed in the target test case; Coverage calculations are performed on protocol attribute data from at least two of the stress testing phases to obtain the target coverage of the target protocol.

[0006] On the other hand, embodiments of this application provide a stress testing protocol coverage detection device, including: The testing module is used to perform stress testing on the target test case in response to test instructions, and obtain protocol attribute data for at least two stress testing phases; wherein, the protocol attribute data is used to indicate attribute data associated with the target protocol, and the target protocol is deployed in the target test case; The processing module is used to perform coverage calculation on the protocol attribute data of at least two stress testing phases to obtain the target coverage of the target protocol.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned stress testing protocol coverage detection method.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the aforementioned stress testing protocol coverage detection method.

[0009] At least one of the above technical solutions has the following advantages or beneficial effects: This application provides a method, apparatus, device, and medium for detecting protocol coverage under load testing. This solution responds to a test command, performs load testing on a target test case, obtains protocol attribute data for at least two load testing phases, and calculates the coverage of the protocol attribute data for the at least two load testing phases to obtain the target coverage of the target protocol. The protocol attribute data indicates attribute data associated with the target protocol, and the target protocol is deployed in the target test case. According to the technical solution of this embodiment, at least two load testing phases are set. By performing multi-stage load testing on the target test case, protocol attribute data for at least two load testing phases is obtained. The protocol attribute data reflects the performance of the target protocol in different load testing phases. Using this as a benchmark for coverage calculation can comprehensively cover the protocol behavior under different load testing phases, enabling the target coverage to objectively reflect the protocol's coverage in different load testing phases, thereby effectively improving the detection accuracy of protocol coverage in load testing. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a stress testing protocol coverage detection method according to an embodiment of this application; Figure 2 yes Figure 1 A flowchart illustrating step S102; Figure 3 This is a schematic diagram illustrating the principle of coverage calculation for the protocol name dimension provided in one embodiment of this application; Figure 4 This is a schematic diagram illustrating the principle of coverage calculation for structure field dimensions provided in one embodiment of this application; Figure 5 yes Figure 1 Another flowchart for step S102; Figure 6 This is a detailed implementation process diagram of a stress testing protocol coverage detection method provided in one embodiment of this application; Figure 7This is a flowchart illustrating another specific implementation of a stress testing protocol coverage detection method provided in one embodiment of this application. Figure 8 This is a schematic diagram of the structure of a stress testing protocol coverage detection device provided in one embodiment of this application. Detailed Implementation

[0011] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0012] In the description of this application, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0013] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0014] In the description of this application, unless otherwise expressly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0015] First, the terms and concepts involved in one or more embodiments of this application will be explained.

[0016] 1) Stress testing is a type of software testing that primarily evaluates a system's performance under extreme load or resource-constrained conditions. The purpose of stress testing includes identifying system failure points under extreme conditions (such as server crashes or memory leaks), verifying the system's recovery capabilities under high pressure (such as automatic scaling and failover mechanisms), and verifying whether the system can maintain basic functionality under abnormal circumstances (e.g., a payment system prioritizing transactions during traffic surges).

[0017] 2) Protocol coverage is an indicator that measures the completeness of test cases in implementing the communication protocol specification. It is primarily used to verify whether the system meets all the functional, state, and exception handling requirements defined by the protocol. Protocol coverage testing is an indispensable evaluation method in stress testing; it verifies the integrity and correctness of the protocol under extreme loads, thereby reasonably assessing the system's stability and fault tolerance. Broadly speaking, protocol coverage refers to the extent to which the protocol is covered during testing.

[0018] 3) A test case is a set of repeatable steps designed to verify a specific function or scenario. It includes input data, operation procedures, and a basis for comparing expected and actual results. Its core objective is to systematically verify whether the software meets the requirements and to discover potential defects.

[0019] Traditional protocol coverage testing involves running test cases and adding logs to them to track protocol transmission. After the test cases are completed, coverage is manually calculated based on the logs. However, this traditional method relies on manual inspection, resulting in low efficiency and failing to meet the requirement of rapid protocol coverage checking. To address this, related technologies have proposed an automated testing method: performing single-stage stress testing on test cases and determining protocol coverage based on the results of this single-stage stress test, thus achieving protocol coverage detection during stress testing. However, due to the influence of the stress testing environment, protocol coverage often varies in different stress testing stages. Since the current technology relies solely on single-stage stress test results, it cannot comprehensively reflect the objective situation of protocol coverage, leading to low accuracy in protocol coverage detection.

[0020] For example, consider a large-scale game system that supports mainstream clients such as Windows, Xbox, and PS5. Each client generates a large amount of data and uploads it to the server while running the game. To ensure server performance during game operation, stress testing is needed to verify the server's stability under high concurrency scenarios. Related technologies pre-configure test cases and protocols for the game system, perform stress testing on the test cases in a single stress testing phase, and determine the protocol coverage accordingly. However, stress testing phases are easily affected by factors such as temporary network jitter and script execution anomalies, leading to varying protocol coverage across different phases. For instance, stress testing phase A, affected by temporary network jitter, has a protocol coverage of only 75%; stress testing phase B, affected by script execution anomalies, has a protocol coverage of only 65%; while stress testing phase C, with stable network and normal script execution, boasts a protocol coverage as high as 85%. In this situation, relying solely on a single stress testing phase to determine protocol coverage fails to objectively assess the actual protocol coverage during stress testing, resulting in low accuracy in protocol coverage detection.

[0021] In view of this, embodiments of this application provide a method, apparatus, device, and medium for detecting protocol coverage under load testing. This solution responds to a test command, performs load testing on a target test case, obtains protocol attribute data for at least two load testing phases, and calculates the coverage of the protocol attribute data from the at least two load testing phases to obtain the target coverage of the target protocol. The protocol attribute data indicates attribute data associated with the target protocol, which is deployed in the target test case. According to the technical solution of this embodiment, at least two load testing phases are set. By performing multi-stage load testing on the target test case, protocol attribute data for at least two load testing phases is obtained. The protocol attribute data reflects the performance of the target protocol in different load testing phases. Using this as a benchmark for coverage calculation can comprehensively cover protocol behavior under different load testing phases, ensuring that the target coverage objectively reflects the protocol's coverage in different load testing phases, thereby effectively improving the detection accuracy of protocol coverage in load testing.

[0022] The load testing protocol coverage detection method, apparatus, device, and medium provided in this application embodiment mainly involve various application scenarios such as peak processing of financial transaction systems, stability verification of game servers, and fault tolerance verification of microservice architectures. Those skilled in the art will understand that the load testing protocol coverage detection method, apparatus, device, and medium provided in this application embodiment can be executed in various application scenarios. Specifically, taking the load testing protocol coverage detection method in this application embodiment as an example: For example, the stress testing protocol coverage detection method provided in this application embodiment can be applied to peak processing scenarios in financial trading systems. For instance, financial trading systems typically need to handle tens of thousands of transaction requests per second, requiring them to have the ability to cope with sudden surges in requests to handle peak processing scenarios. Accordingly, corresponding test cases and protocols are set for the financial trading system. Using the stress testing protocol coverage detection method in this application embodiment, multi-stage stress testing can be performed on its test cases to simulate peak processing scenarios, and the target coverage of its protocol can be accurately determined based on this. This helps verify whether the financial trading system has the ability to cope with sudden surges in requests, thereby ensuring that the protocol parsing of the financial trading system is error-free under peak processing scenarios and reducing the risk of data loss or transaction delays.

[0023] For example, the stress testing protocol coverage detection method provided in this application embodiment can be applied to the stability verification of game servers. For instance, a game system typically has one upper-level server and multiple lower-level clients. Users run the game through clients such as laptops, desktop computers, and mobile phones. When running the game, the clients generate a large amount of game data and upload it to the server. The impact of large-scale connections may cause the server to experience issues such as communication delays or crashes. To address this, by setting corresponding test cases and protocols for the game system, the stress testing protocol coverage detection method in this application embodiment can perform multi-stage stress testing on its test cases to simulate large-scale connection scenarios. Based on this, the target coverage of its protocol can be accurately determined. This helps verify whether the protocol can maintain long-term connections between the server and each client under extreme concurrency scenarios, thereby ensuring the stability of the server when facing large-scale connections.

[0024] For example, the stress testing protocol coverage detection method provided in this application embodiment can be applied to the fault tolerance verification scenario of microservice architecture. For instance, a distributed microservice system has multiple service nodes, each responsible for executing its corresponding microservice type. When one or more service nodes fail, it may affect the operation of other service nodes, thereby affecting the normal operation of the entire microservice architecture. To address this, by setting corresponding test cases and protocols for the distributed microservice system, the stress testing protocol coverage detection method in this application embodiment can perform multi-stage stress testing on its test cases to simulate the scenario of single or multiple service node failures, and accurately determine the target coverage of its protocol based on this. This helps to test the circuit breaker mechanism and load balancing strategy of the protocol under node failure scenarios, thereby ensuring that other services remain available even when some services are degraded.

[0025] It is understood that the above application scenarios are merely illustrative and do not imply any limitation on the actual application of the load testing protocol coverage detection method provided in this application embodiment. Those skilled in the art will understand that the load testing protocol coverage detection method provided in this application embodiment can be used to perform specified tasks in different application scenarios.

[0026] The specific implementation methods of the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0027] The stress testing protocol coverage detection method provided in this application embodiment can cover most stress testing scenarios, enabling testers to quickly and accurately determine the actual coverage of protocols during stress testing. Specifically, before the stress test begins, testers can use interactive tools such as operating systems or websites to set corresponding protocols for the system to be tested and set corresponding test cases accordingly. During stress testing, testers send test commands to the backend through interactive tools such as operating systems or websites. The backend responds to the test commands, performs stress testing on the test cases, and obtains protocol attribute data for at least two stress testing phases. This data serves as the result of the multi-phase stress test, and the target coverage of the protocol is determined accordingly. This allows for accurate determination of the actual coverage of the protocol. This application embodiment sets at least two stress testing phases. By performing multi-phase stress testing on the target test cases, protocol attribute data for at least two stress testing phases is obtained. The protocol attribute data reflects the performance of the target protocol in different stress testing phases. Using this as a benchmark for coverage calculation can comprehensively cover protocol behavior under different stress testing phases, thereby effectively improving the detection accuracy of protocol coverage in stress testing.

[0028] The stress testing protocol coverage detection method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, set-top box, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms; the software can be an application implementing image processing methods, etc., but is not limited to the above forms.

[0029] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0030] Reference Figure 1 , Figure 1 This is a flowchart of a stress testing protocol coverage detection method provided in an embodiment of this application. The stress testing protocol coverage detection method may include, but is not limited to, steps S101 to S102: S101, in response to the test instruction, stress test the target test case to obtain protocol attribute data for at least two stress test phases; wherein, the protocol attribute data is used to indicate attribute data associated with the target protocol, and the target protocol is deployed in the target test case.

[0031] Specifically, the target test case refers to the test case of the target system, and the target protocol refers to the protocol deployed in the target test case, which is part of the target system. The target system refers to the system applicable to the stress testing protocol coverage detection method in this embodiment, such as a financial transaction system or a game system. Accordingly, the test instructions are used to execute stress tests on the target test cases. Through stress testing, protocol attribute data can be obtained, which reflects the performance of the target protocol in different stress testing phases.

[0032] Optionally, the type of target protocol can be set according to actual conditions, and this application embodiment does not limit this. For example, the target protocol can be the Message Queuing Telemetry Transport (MQTT) protocol, which is a lightweight message transmission protocol based on the publish / subscribe model. Another example is the Protobuf protocol, which is a binary data serialization protocol used for the storage and transmission of structured data, and is widely used in scenarios such as network communication data exchange and storage.

[0033] Furthermore, the presentation of protocol attribute data can be flexibly set according to the actual situation. For example, protocol attribute data can be presented in the form of a protocol file, which is associated with the target protocol's protocol name, structure fields, default values, service interface definitions, etc., but is not limited to this.

[0034] It is worth noting that the stress test setup has at least two stress test phases, and there is a one-to-one correspondence between the stress test phases and the protocol attribute data, meaning that each stress test phase has its own independent protocol attribute data. The types of each stress test phase can be the same or different, and can be flexibly set according to actual conditions; this application embodiment does not limit this.

[0035] For example, the type of load testing phase can be stability load testing, single-scenario performance load testing, normal load testing, and progressive load testing, but is not limited to these. Specifically, stability load testing refers to continuous stress testing simulating a real-world environment to verify the long-term operational reliability of the system; single-scenario performance load testing refers to continuous full-load stress testing to verify the core business limits of the system; normal load testing refers to continuous performance stress testing under non-full-load conditions to verify the system's regular functions; and progressive load testing refers to starting from zero load and increasing the load rate at regular intervals to continuously test performance under gradually increasing pressure to verify the system's performance.

[0036] It should be understood that the duration of each load test type in the above examples can be flexibly set according to actual conditions. For example, the duration of the stability test type can be 48 hours, the duration range for the single-scenario performance load test type and the normal load test type can be [10 minutes, 15 minutes], and the duration of the progressive load test type can be 24 hours, but is not limited to this. Furthermore, the interval and gradient of increasing load rate in the progressive load test type can also be flexibly set according to actual conditions. For example, the interval of increasing load rate in the progressive load test type can be 10 minutes, and the gradient of increasing load rate can be 10%, but is not limited to this. In addition, the load rate in the normal load test type can also be flexibly set according to actual conditions. For example, the load rate in the normal load test type can be 70%, but is not limited to this.

[0037] In practical applications, the target protocol is pre-configured for the target system, and target test cases are designed accordingly. The target protocol is deployed within the target test cases. After pre-configuration, in response to test commands, multi-stage stress testing is initiated on the target test cases. Stress testing yields protocol attribute data for at least two stress testing phases. The protocol attribute data for a single stress testing phase reflects the performance of the target protocol in that phase.

[0038] For example, in the stress test, two stress test phases, both of which are stability stress tests, are set up. In response to the test command, the target test case is subjected to two stability stress tests, thereby obtaining the protocol attribute data of these two stress test phases. The two stability stress tests can be performed simultaneously or sequentially, and this application embodiment does not impose any restrictions on this.

[0039] For example, continuing with the above example, three stress testing phases are set up in the stress test. One stress testing phase is of the stability test type, and the other two stress testing phases are of the normal test type. In response to the test command, one stability test and two normal tests are performed on the target test case to obtain the protocol attribute data of the three stress testing phases. The stability test and the normal test can be performed simultaneously or sequentially. For example, the stability test can be performed first, followed by two normal tests, or the normal test can be performed first, followed by the stability test, and then the second normal test. This application embodiment does not limit this.

[0040] S102, calculate the coverage of protocol attribute data for at least two stress testing phases to obtain the target coverage of the target protocol.

[0041] Specifically, target coverage refers to the actual coverage of the target protocol throughout the entire stress test process, reflecting the overall coverage of the target protocol relative to the entire stress test process. A higher target coverage indicates better coverage of the target protocol throughout the stress test.

[0042] In practical applications, after completing stress testing, protocol attribute data from at least two phases is obtained. This data reflects the target protocol's performance at different stress testing phases and is highly correlated with the target protocol's actual coverage during stress testing. Therefore, coverage calculation is performed using the protocol attribute data from at least two stress testing phases as a benchmark. This coverage calculation accurately determines the target protocol's actual coverage during stress testing.

[0043] For example, when calculating the coverage of protocol attribute data for at least two load testing phases, machine learning methods can be used to calculate the coverage of the protocol attribute data for at least two load testing phases, obtaining the target coverage of the target protocol. This machine learning method can learn the mapping relationship between protocol attribute data and the target coverage. Here, machine learning methods have superior performance in data processing, and can quickly and accurately determine the target coverage. The machine learning method can be flexibly set according to the actual situation; for example, it can be logistic regression, support vector machines, etc., but is not limited to these.

[0044] At least one of the above technical solutions has the following advantages or beneficial effects: The embodiments of this application set at least two stress testing stages. By performing multi-stage stress testing on the target test cases, protocol attribute data of at least two stress testing stages are obtained. The protocol attribute data reflects the performance of the target protocol in different stress testing stages. Based on this, coverage calculation can comprehensively cover the protocol behavior under different stress testing stages, so that the target coverage objectively reflects the coverage of the protocol in different stress testing stages, thereby effectively improving the detection accuracy of protocol coverage in stress testing.

[0045] In one implementation of the embodiments of this application, reference is made to Figure 2 The aforementioned at least two stress testing phases may include, but are not limited to, at least two dynamic stress testing phases; the aforementioned calculation of the coverage of protocol attribute data from at least two stress testing phases to obtain the target coverage of the target protocol may further include, but is not limited to, the following steps: Coverage calculations are performed on protocol attribute data from at least two dynamic stress testing phases to obtain the protocol coverage for at least two dynamic stress testing phases; the protocol coverage from at least two dynamic stress testing phases is then integrated to obtain the target coverage.

[0046] Specifically, the entire stress testing process can be subdivided into several test rounds, with each test round being a fine-grained dynamic stress testing phase. The method of dividing the stress test can be flexibly set according to actual circumstances, and this embodiment does not impose any limitations on it.

[0047] For example, the entire stress test process is divided into 100 test rounds, and the type of each test round is set sequentially. For example, the first to 20th test rounds are dynamic stress test phases of the normal stress test type, the 21st to 70th test rounds are dynamic stress test phases of the stability stress test type, and the 71st to 100th test rounds are dynamic stress test phases of the single-scenario performance stress test type.

[0048] For example, continuing with the example above, the entire stress test process is divided into 100 test rounds, and the type of each test round is randomly set. For example, test rounds with odd numbers are dynamic stress test phases of stability stress test type, while test rounds with even numbers are dynamic stress test phases of single-scenario performance stress test type, but are not limited to this.

[0049] It is understood that the types of each dynamic stress testing stage can be the same or different, and can be flexibly set according to the actual situation. This embodiment does not limit this. The description of the types of dynamic stress testing stages in this embodiment can refer to the description of the types of stress testing stages in the above embodiments, and will not be repeated here.

[0050] It's important to note that protocol coverage during dynamic stress testing refers to the coverage of the target protocol within that phase, reflecting its local coverage relative to the dynamic stress testing stage. A higher protocol coverage during dynamic stress testing indicates better overall coverage of the target protocol within that stage. It should be understood that there is a one-to-one correspondence between dynamic stress testing stages and protocol coverage; each dynamic stress testing stage has its own independent protocol coverage.

[0051] In practical applications, related technologies typically rely on a single stress testing phase. However, during actual stress testing, a single phase is susceptible to unforeseen factors such as temporary network fluctuations and script execution anomalies. Furthermore, relying on a single stress testing phase for protocol coverage assessment is biased, resulting in low accuracy of protocol coverage for related technologies. To address this, this embodiment divides the entire stress testing process into at least two dynamic stress testing phases at a fine-grained level and performs stress testing accordingly. The stress test yields protocol attribute data for at least two dynamic stress testing phases. This data reflects the performance of the target protocol in different dynamic stress testing phases, including protocol name, message structure fields, default values, and service interface definitions. This data is highly correlated with the actual coverage of the target protocol during the dynamic stress testing phases. After completing the stress test, firstly, coverage is calculated based on the protocol attribute data of at least two dynamic stress test phases to determine the protocol coverage of at least two dynamic stress test phases. This protocol coverage reflects the local coverage of the target protocol relative to the dynamic stress test phases. Then, since the protocol coverage of a single dynamic stress test phase reflects the local coverage of the target protocol under that single dynamic stress test phase, after obtaining the protocol coverage of at least two dynamic stress test phases, these protocol coverages need to be integrated into the target coverage to accurately locate the global coverage of the target protocol throughout the entire stress test process.

[0052] For example, when calculating the coverage of protocol attribute data for at least two dynamic stress testing phases, for each dynamic stress testing phase, the number of protocols used in the current dynamic stress testing phase can be extracted from the protocol attribute data of the current dynamic stress testing phase, and the ratio of the number of protocols used in the current dynamic stress testing phase to the total number of protocols in the current dynamic stress testing phase is determined as the protocol coverage of the current dynamic stress testing phase. The protocol coverage of at least two dynamic stress testing phases can be obtained by traversing at least two dynamic stress testing phases. Here, the number of protocols used refers to the number of target protocols actually triggered during the stress test, while the total number of protocols is the number of target protocols that are pre-configured and expected to be triggered before the stress test. Here, since the number of protocols used is easy to extract and can directly reflect the coverage of target protocols, this embodiment uses the number of protocols used and the total number of protocols as a benchmark to determine the protocol coverage. This can quickly and accurately quantify the local coverage of target protocols relative to the dynamic stress testing phase, thereby effectively improving the calculation efficiency and accuracy of protocol coverage in the dynamic stress testing phase.

[0053] For example, when integrating the protocol coverage of at least two dynamic stress testing phases, the average of the protocol coverage of all dynamic stress testing phases can be used as the target coverage. Alternatively, a weighted summation method can be employed, where each dynamic stress testing phase's protocol coverage is assigned a corresponding weight value, and then the sum of the weighted protocol coverage values ​​across all dynamic stress testing phases is calculated as the target coverage. Here, the sum of the corresponding weight values ​​for each dynamic stress testing phase is 1.

[0054] It is understandable that in the weighted summation method, the weight values ​​corresponding to each dynamic stress test stage can be set according to the actual situation, and this embodiment does not limit this.

[0055] For example, taking the Protobuf protocol as an example, during the dynamic execution of the Protobuf protocol, different protocol proportions will be distributed according to the specific usage. Accordingly, when the dynamic load testing phase is any of the following types: stability load testing, single-scenario performance load testing, or normal load testing, the execution method of normal load testing is relatively simple, and it is usually designed for non-full load conditions, resulting in lower importance in stress testing. Therefore, the initial weight value of the dynamic load testing phase belonging to the normal load testing type is set to the first value. The load testing time cost of stability load testing is higher, and it is executed fewer times, but stability load testing is often designed for simulating real-world environments, resulting in certain importance in stress testing. Therefore, the initial weight value of the dynamic load testing phase belonging to the stability load testing type is set to the second value. The load testing time cost of single-scenario load testing is lower, it can be executed multiple times, and it is usually designed for full load conditions, resulting in higher importance in stress testing. Therefore, the initial weight value of the dynamic load testing phase belonging to the single-scenario load testing type is set to the third value. In this embodiment, the first value is less than the second value, and the second value is less than the third value. These values ​​can be flexibly set according to the actual situation. For example, the first value can be 1, the second value can be 2, and the third value can be 3, but it is not limited to this. Here, this embodiment determines the weight values ​​of each dynamic stress test stage by fully considering the characteristics of each stage. This can comprehensively reflect the importance of each dynamic stress test stage in stress testing, thereby helping to accurately capture the actual coverage of the target protocol.

[0056] It is important to note that since the initial weight values ​​for each dynamic load testing phase are greater than 1, the initial weight values ​​for each phase need to be processed so that they fall between 0 and 1, thus obtaining the weight value for each dynamic load testing phase. For example, calculate the sum of the initial weight values ​​for all dynamic load testing phases, and for each dynamic load testing phase, determine the weight value for that phase as the ratio of its initial weight value to this sum.

[0057] For example, continuing with the above example, taking the Protobuf protocol as an example, when the dynamic load testing phase is any one of the stability load testing type, single-scenario performance load testing type, or normal load testing type, for each dynamic load testing phase, the product of the basic weight value corresponding to the current dynamic load testing phase type and the current dynamic load testing phase number is used as the accumulated weight value of the current dynamic load testing phase. Then, the sum of the basic weight value of the load test and the accumulated weight value of the current dynamic load testing phase is determined as the initial weight value of the current dynamic load testing phase. For example, each time a normal load testing phase is executed, the basic weight value corresponding to the normal load testing type is accumulated on the basis of the basic weight value of the load test; each time a stability load testing phase is executed, the basic weight value corresponding to the stability load testing type is accumulated on the basis of the basic weight value of the load test; each time a single-scenario performance load testing phase is executed, the basic weight value corresponding to the single-scenario performance load testing type is accumulated on the basis of the basic weight value of the load test. Here, adjacent dynamic stress testing phases often exhibit continuity, and the stress testing depth typically increases gradually. For example, it may transition from a normal stress testing type (i.e., regular functional verification) to a single-scenario performance stress testing type (i.e., core business limits), and then to a stability stress testing type (i.e., long-term stability). Therefore, this embodiment introduces a weight setting method for phase continuity. This method uses the basic weight value of the stress test as the global benchmark and the cumulative weight value of the dynamic stress testing phase as the local benchmark. The initial weight value of the dynamic stress testing phase is determined based on the global and local benchmarks. This allows the weight of the dynamic stress testing phase to increase dynamically as the stress test progresses through phases, which can more comprehensively reflect the importance of various dynamic stress testing phases in the stress test. It can also reduce the risk of the early dynamic stress testing phases having too low a weight, ensuring the importance of the early dynamic stress testing phases while strengthening the importance of the later dynamic stress testing phases. This helps to more accurately capture the actual coverage of the target protocol.

[0058] It should be understood that since the initial weight values ​​of each dynamic load testing stage are greater than 1, it is necessary to process the initial weight values ​​of each dynamic load testing stage so that they fall between 0 and 1, thereby obtaining the weight values ​​of each dynamic load testing stage. The processing method in this example can refer to the processing method in the previous examples, and will not be repeated here.

[0059] Optionally, the base weight value corresponding to the current dynamic load testing phase type can be flexibly set according to the actual situation. For example, the base weight value of a dynamic load testing phase belonging to the normal load testing type can be set to the first value, the base weight value of a dynamic load testing phase belonging to the stability load testing type can be set to the second value, and the base weight value of a dynamic load testing phase belonging to the single-scenario load testing type can be set to the third value, but it is not limited to these. The first value is less than the second value, and the second value is less than the third value; these can be flexibly set according to the actual situation, for example, the first value could be 1, the second value 2, and the third value 3, but it is not limited to these. Furthermore, the base weight value of the stress test can be flexibly set according to the actual situation; for example, the base weight value of the stress test can be 1, but it is not limited to this.

[0060] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment first calculates the coverage rate based on the protocol attribute data of at least two dynamic stress testing phases, determining the protocol coverage rate of at least two dynamic stress testing phases, thereby fully exploring the local coverage of the target protocol under different dynamic stress testing phases, which is targeted for a single dynamic stress testing phase; then, the protocol coverage rates of at least two dynamic stress testing phases are integrated into the target coverage rate, thereby comprehensively exploring the global coverage of the target protocol under all dynamic stress testing phases, which is targeted for all dynamic stress testing phases. In this way, this embodiment can comprehensively cover the protocol behavior under different stress testing phases, enabling the target coverage rate to objectively reflect the protocol coverage in different stress testing phases, and effectively reducing the impact of accidental and one-sided factors on protocol coverage detection, thereby effectively improving the detection accuracy of protocol coverage in stress testing.

[0061] In one implementation of this application, the above-mentioned calculation of protocol attribute data for at least two dynamic stress testing phases to obtain protocol coverage for at least two dynamic stress testing phases further includes, but is not limited to, the following steps: Information extraction processing is performed on the protocol attribute data of at least two dynamic stress testing phases to obtain dynamic protocol information for at least two dynamic stress testing phases; wherein, the dynamic protocol information is used to indicate the descriptive information associated with the protocol name and structure fields of the target protocol in the dynamic stress testing phase; based on the dynamic protocol information of at least two dynamic stress testing phases, coverage is calculated to obtain the protocol coverage of at least two dynamic stress testing phases.

[0062] Specifically, dynamic protocol information refers to two aspects: firstly, descriptive information associated with the protocol name of the target protocol; and secondly, descriptive information associated with the structure fields of the target protocol. It should be understood that structure fields refer to the fields of a structure. The core function of a structure is to combine multiple related fields into an organic whole to describe the attributes or record information of complex objects. The structure can be a message structure, but is not limited to it.

[0063] Optionally, the dynamic protocol information can be flexibly set according to the actual situation, and this embodiment does not limit it. For example, the dynamic protocol information mentioned above may include, but is not limited to, protocol name string, protocol name enumeration value, field data type, field name, field quantity, field label, etc., but is not limited to these. Among them, the protocol name string is a variable-length text data used to represent the protocol name, which may contain at least one protocol name; the protocol name enumeration value is a finite protocol name constant predefined by the enumeration type (enum), which is usually multiple; the field data type refers to the data type of the field in the structure, such as integer, string, character, floating point, etc., or it can be other structure types such as array, pointer, or even nested implementation; the field name refers to the identifier of the field in the structure, which is used to identify the meaning of the field in the structure; the field quantity refers to the number of fields contained in the structure; the field label is additional meta-information bound to the structure field, usually defined in the form of a string enclosed in backticks, used to control the behavior rules of operations such as serialization and database mapping.

[0064] It should be understood that under stress testing, the target protocol can have multiple protocol names. Taking the Protobuf protocol as an example, it can be associated with transport protocols such as Hypertext Transfer Protocol (HTTP) and Message Queuing Telemetry Transport (MQTT). In this case, the protocol names displayed by the Protobuf protocol during stress testing can include HTTP, MQTT, etc. These protocol names can be combined into a string to obtain the protocol name string. Typically, a single protocol name has an independent enumeration value. Since there can be multiple protocol names, there will also be multiple protocol name enumeration values ​​in this case. Furthermore, the target protocol's structure often includes multiple fields, and each field has independent data type, name, quantity, and label characteristics. Since there can be multiple fields, there will also be multiple data types, field names, field quantities, and field labels in this case.

[0065] In practical applications, after obtaining protocol attribute data for at least two dynamic stress testing phases, dynamic protocol information for at least two dynamic stress testing phases is extracted from these protocol attribute data. The dynamic protocol information is associated with the protocol name and structure fields of the target protocol. Then, coverage is calculated based on the protocol name and structure fields of the target protocol to obtain the protocol coverage for at least two dynamic stress testing phases, thereby accurately locating the local coverage of the target protocol in a single dynamic stress testing phase.

[0066] For example, during information extraction and processing, the protocol attribute data for each dynamic load testing phase is often presented in the form of a protocol file. By parsing the protocol file, the dynamic protocol information for the current dynamic load testing phase can be obtained. Taking the Protobuf protocol as an example, the protocol attribute data for the current dynamic load testing phase is presented in the form of a protocol.proto file. By calling the request API of the requests library, the code in the target test case and the protocol.proto file are retrieved. Then, the enum PF enumeration in the protocol.proto file is parsed to obtain the protocol name string, protocol name enumeration value, and other data of the Protobuf protocol. At the same time, the defined structure is parsed to obtain the data such as the data type, field name, and number of fields of the Protobuf protocol. Thus, the dynamic protocol information of the Protobuf protocol under the current dynamic load testing phase is obtained.

[0067] For example, when calculating coverage based on dynamic protocol information from at least two dynamic stress testing phases, a machine learning method can be used to calculate the coverage of the dynamic protocol information in the current dynamic stress testing phase for each phase, thus obtaining the protocol coverage for the current dynamic stress testing phase. This machine learning method can learn the mapping relationship between dynamic protocol information and protocol coverage. Here, the machine learning method has superior performance in data processing, and can quickly and accurately calculate the protocol coverage.

[0068] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment first extracts dynamic protocol information for at least two dynamic stress testing phases from the protocol attribute data of at least two dynamic stress testing phases. The dynamic protocol information is highly correlated with the protocol name and structure fields of the target protocol. The actual situation of the protocol name and structure fields can more accurately reflect the actual performance of the target protocol in the dynamic stress testing phase. Then, based on this, the coverage is calculated to obtain the protocol coverage for at least two dynamic stress testing phases. In this way, by fully considering multi-dimensional factors that are highly correlated with the protocol coverage, such as the protocol name and structure fields, the protocol coverage for the dynamic stress testing phase can be determined, which can more accurately reflect the local coverage of the target protocol in the dynamic stress testing phase, thereby effectively improving the accuracy of the protocol coverage in the dynamic stress testing phase.

[0069] In one implementation of this application, the above-mentioned coverage calculation based on dynamic protocol information from at least two dynamic stress testing phases to obtain protocol coverage for at least two dynamic stress testing phases further includes, but is not limited to, the following steps: Based on the description information associated with the protocol name of the target protocol in at least two dynamic stress testing phases, a first coverage rate for at least two dynamic stress testing phases is obtained; based on the description information associated with the structure fields of the target protocol in at least two dynamic stress testing phases, a second coverage rate for at least two dynamic stress testing phases is obtained; the first coverage rate and the second coverage rate of at least two dynamic stress testing phases are summarized to obtain the protocol coverage rate for at least two dynamic stress testing phases.

[0070] Specifically, the first coverage rate indicates the local coverage of the target protocol during the dynamic stress testing phase, from the perspective of protocol name. A higher first coverage rate indicates better local coverage of the target protocol during the dynamic stress testing phase, as indicated by the protocol name. Furthermore, the second coverage rate indicates the local coverage of the target protocol during the dynamic stress testing phase, from the perspective of structure fields. A higher second coverage rate indicates better local coverage of the target protocol during the dynamic stress testing phase, as indicated by the structure fields.

[0071] In practical applications, protocol coverage is divided into two dimensions: protocol name and structure fields. Accordingly, for the protocol name dimension, coverage is calculated based on the descriptive information associated with the target protocol's name in at least two dynamic stress testing phases, yielding a first coverage for at least two dynamic stress testing phases. Simultaneously, for the structure fields dimension, coverage is calculated based on the descriptive information associated with the target protocol's structure fields in at least two dynamic stress testing phases, yielding a second coverage for at least two dynamic stress testing phases. These two coverage dimensions are then integrated into the final protocol coverage, thereby pinpointing the local coverage of the target protocol during the dynamic stress testing phases.

[0072] It should be noted that the method for determining the first coverage rate can be set according to the actual situation, and this embodiment does not limit it.

[0073] For example, such as Figure 3 As shown, the dynamic protocol information includes a protocol name string and protocol name enumeration values. When determining the first coverage, for each dynamic load testing phase, the first sub-coverage of the current dynamic load testing phase can be obtained based on the protocol name string and the expected string of the current dynamic load testing phase. The second sub-coverage of the current dynamic load testing phase can be obtained based on the protocol name enumeration value and the expected enumeration value of the current dynamic load testing phase. The first and second sub-coverages of the current dynamic load testing phase are then integrated into the first coverage of the current dynamic load testing phase. Here, the expected string refers to the expected string of the protocol name pre-configured before the load test begins, and the expected enumeration value refers to the expected enumeration value of the protocol name pre-configured before the load test begins. Here, this embodiment further subdivides the protocol name dimension into two sub-dimensions: string and enumeration value. Coverage detection is performed on the string to obtain the first sub-coverage, thereby focusing on the named strings in the protocol; coverage detection is performed on the enumeration value to obtain the second sub-coverage, thereby focusing on the named constants in the protocol; then, the sub-coverages of these two sub-dimensions are integrated into the final first coverage. In this way, since the subdivided dimensions of the protocol name, such as named constants and named strings, can accurately reflect the actual situation of the protocol name, determining the coverage for the protocol name dimension by fully considering the above subdivided dimensions can accurately locate the actual coverage of the target protocol for the protocol name dimension during the dynamic stress testing phase, thereby effectively improving the accuracy of the first coverage.

[0074] Optionally, the method for determining the first sub-coverage can be set according to the actual situation, and this embodiment does not limit it.

[0075] For example, when determining the first sub-coverage, the edit distance between the protocol name string and the expected string in the current dynamic load testing phase can be calculated, and the edit distance can be converted into a similarity value in the range [0, 1], which is then used as the first sub-coverage for the current dynamic load testing phase. Here, this embodiment introduces an edit distance calculation method. The edit distance indicates the minimum number of operations required to convert one string into another. The smaller the edit distance, the closer the content of the actual string is to the content of the expected string, and the greater the protocol coverage at the protocol name string level. This can directly reflect the difference between the expected string and the actual string at the character content level, and reduce the misleading differences caused by situations such as the same length but unrelated content, or different lengths but highly similar content. This more accurately quantifies the degree of difference between the expected string and the actual string, effectively improving the accuracy of the first sub-coverage. It should be understood that the above method of converting the edit distance into similarity can be flexibly set according to the actual situation. For example, the conversion method can be to calculate the sum of the edit distance and one, and calculate the ratio of one to the sum as the similarity, but it is not limited to this.

[0076] For example, continuing with the above example, the edit distance between the protocol name string and the expected string in the current dynamic load testing phase can be calculated, and the edit distance can be converted into a similarity value in the range [0, 1]. Simultaneously, the ratio of the length of the protocol name string in the current dynamic load testing phase to the length of the expected string in the current dynamic load testing phase can be calculated. Then, the mean of the similarity and the ratio is calculated as the first sub-coverage rate for the current dynamic load testing phase. Here, the edit distance can capture the differences between the expected string and the actual string at the character content level, and the ratio processing can capture the differences between the expected string and the actual string at the string length level. This embodiment, by focusing on the differences in character content and character length between the expected string and the actual string, can comprehensively and objectively explore the protocol coverage for the protocol name string, thereby further improving the accuracy of the first sub-coverage rate.

[0077] Alternatively, the method for determining the second sub-coverage rate can be set according to the actual situation, and this embodiment does not limit it.

[0078] For example, there are usually multiple protocol name enumeration values, which means that multiple integer constants of protocol name enumeration values ​​can constitute a sequence of data, and multiple integer constants of expected enumeration values ​​can also constitute a sequence of data, which can be called an integer constant sequence. Since the number of protocol name enumeration values ​​may not be equal to the number of expected enumeration values, the integer constant sequence of protocol name enumeration values ​​may not be of equal length to the integer constant sequence of expected enumeration values. Based on this, when determining the second sub-coverage, for two integer constant sequences of unequal length, this embodiment calculates the edit distance between the integer constant sequence of protocol name enumeration values ​​and the integer constant sequence of expected enumeration values ​​in the current dynamic stress test stage, and converts the edit distance into a similarity in the range [0, 1], which is used as the second sub-coverage of the current dynamic stress test stage. Here, this embodiment introduces a method combining serialization and edit distance calculation. The enumeration value is serialized into an integer constant sequence, and the second sub-coverage is determined based on this sequence and the edit distance. The edit distance indicates the minimum number of operations required to convert one sequence into another. The smaller the edit distance, the closer the constant content of the actual enumeration value is to the constant content of the expected enumeration value, and the greater the protocol coverage at the protocol name enumeration value level. This accurately and intuitively reflects the difference between the actual and expected enumeration values ​​at the enumeration content level, and reduces the misleading differences caused by situations such as identical lengths but unrelated content, or different lengths but highly similar content. Therefore, it accurately quantifies the degree of difference between the expected and actual enumeration values, effectively improving the accuracy of the second sub-coverage. It should be understood that the description of converting edit distance to similarity in this embodiment can refer to the description of converting edit distance to similarity in the previous example, and will not be repeated here.

[0079] For example, continuing with the above example, the edit distance between the integer constant sequence of protocol name enumeration values ​​and the integer constant sequence of expected enumeration values ​​in the current dynamic stress test phase can be calculated, and the edit distance can be converted into a similarity in the range [0, 1]. Simultaneously, the ratio of the number of protocol name enumeration values ​​in the current dynamic stress test phase to the number of expected enumeration values ​​in the current dynamic stress test phase can be calculated. Then, the mean of the similarity and the ratio is calculated as the second sub-coverage rate for the current dynamic stress test phase. Here, the edit distance can capture the difference between the expected enumeration values ​​and the actual enumeration values ​​at the enumeration content level, and the ratio processing can capture the difference between the expected enumeration values ​​and the actual enumeration values ​​at the enumeration quantity level. This embodiment, by focusing on the differences in enumeration content and the differences in enumeration quantity between the expected enumeration values ​​and the actual enumeration values, can comprehensively and objectively explore the protocol coverage for protocol name enumeration values, thereby further improving the accuracy of the second sub-coverage rate.

[0080] Alternatively, the integration method for the first coverage rate can also be set according to the actual situation, and this embodiment does not limit it.

[0081] For example, when integrating the first sub-coverage and the second sub-coverage into a first coverage, the average of the first and second sub-coverages can be used to determine the first coverage. Alternatively, a weighted summation method can be employed, where the sum of the first sub-coverage with a first weight and the second sub-coverage with a second weight is used to determine the first coverage. Both the first and second weights can be preset, and their sum is 1.

[0082] It is understood that the method for determining the second coverage rate can be set according to the actual situation, and this embodiment does not limit it.

[0083] For example, such as Figure 4As shown, when determining the second coverage rate, assuming the dynamic protocol information includes field data types, field names, and field quantities, for each dynamic load testing phase, the third sub-coverage rate of the current dynamic load testing phase can be obtained based on the field data types and expected data types of the current dynamic load testing phase. The fourth sub-coverage rate is obtained by processing the field names and expected names of the current dynamic load testing phase using an edit distance function. The fifth sub-coverage rate is determined by the ratio of the number of fields in the current dynamic load testing phase to the expected number of fields in the current dynamic load testing phase. Subsequently, the third, fourth, and fifth sub-coverage rates of the current dynamic load testing phase are integrated into the second coverage rate of the current dynamic load testing phase. Here, the expected data type refers to the expected data type of the structure field pre-configured before the load test begins; the expected name refers to the expected identifier of the structure field pre-configured before the load test begins; and the expected quantity refers to the expected number of fields contained in the target protocol structure pre-configured before the load test begins. Here, this embodiment further subdivides the structure field dimension into three sub-dimensions based on the content of the field format: field data type, field name, and field quantity. Coverage testing is performed on the data type of the structure fields to obtain a third sub-coverage, thus focusing on the field types in the protocol structure; coverage testing is performed on the names of the structure fields to obtain a fourth sub-coverage, thus focusing on the meaning of the fields in the protocol structure; and coverage testing is performed on the number of structure fields to obtain a fifth sub-coverage, thus focusing on the number of fields in the protocol structure. Then, the sub-coverages of these three sub-dimensions are integrated into the final second coverage. Since the subdivided dimensions such as field type, field meaning, and field quantity in the protocol structure accurately reflect the actual situation of the structure, determining the coverage for the structure field dimension by fully considering the above subdivided dimensions can accurately locate the actual coverage of the target protocol for the structure field dimension during the dynamic stress testing phase, thereby effectively improving the accuracy of the second coverage.

[0084] It is worth noting that when determining the fourth sub-coverage, the structure typically includes multiple fields, each with a distinct and unique name. This means that multiple field names can constitute sequence data, and multiple desired names can also constitute sequence data, which can be referred to as a name sequence. Since the number of field names may not equal the number of desired names, the name sequence of field names may not be of equal length to the name sequence of desired names. Based on this, when determining the fourth sub-coverage, for two name sequences of unequal length, this embodiment calculates the edit distance between the name sequence of field names and the name sequence of desired names in the current dynamic load testing phase, and converts the edit distance into a similarity value in the range [0, 1], which is then used as the fourth sub-coverage for the current dynamic load testing phase. Here, this embodiment introduces a method combining serialization and edit distance calculation. The field name is serialized, and the fourth sub-coverage is determined based on this serialization and the edit distance. The edit distance indicates the minimum number of operations required to convert one sequence into another. The smaller the edit distance, the closer the essence of the actual name is to the essence of the expected name, and the greater the protocol coverage at the field name type level of the structure. This can directly reflect the difference between the actual name and the expected name at the field meaning level, and reduce the misleading differences caused by situations such as the same length but unrelated content, or different lengths but highly similar content. Thus, it accurately quantifies the degree of difference between the expected name and the actual name of the structure field, and effectively improves the accuracy of the fourth sub-coverage.

[0085] Furthermore, when determining the fifth sub-coverage, the ratio of the number of fields in the current dynamic load testing phase to the expected number in the current dynamic load testing phase is used as the fifth sub-coverage for the current dynamic load testing phase. Here, this embodiment introduces a ratio processing method. The larger the ratio, the closer the actual number of fields is to the expected number of fields, and the greater the protocol coverage at the field count level of the structure. This allows for a direct measurement of the difference between the expected number of fields and the actual number of fields in the structure, thereby helping to quickly and accurately determine the fifth sub-coverage.

[0086] Optionally, the method for determining the third sub-coverage can be set according to the actual situation, and this embodiment does not limit it.

[0087] For example, a structure typically includes multiple fields, each with potentially the same or different data types. Accordingly, before the stress test begins, each field is assigned a corresponding identifier value based on its data type. For instance, an integer field might be assigned an identifier value of 1, a character field a identifier value of 2, etc., but this is not a limitation. Thus, multiple field data types can be converted into a sequence of data composed of the identifier values ​​of each field. Similarly, multiple desired data types can also be converted into a sequence of data composed of the identifier values ​​of each field; this sequence of data is called an identifier sequence. Since the number of field data types may not equal the number of desired data types, the identifier sequences of the field data types may not be of equal length to the identifier sequences of the desired data types. Based on this, when determining the third sub-coverage, for two identifier sequences of unequal length, this embodiment calculates the edit distance between the identifier sequences of the field data types and the identifier sequences of the desired data types in the current dynamic stress test phase, and converts the edit distance into a similarity in the range [0, 1], which is then used as the third sub-coverage for the current dynamic stress test phase. This embodiment introduces a method combining serialization and edit distance calculation. Data types are serialized, and the third sub-coverage is determined based on this serialization and the edit distance. Edit distance indicates the minimum number of operations required to convert one sequence into another. A smaller edit distance indicates that the essence of the actual data type is closer to the essence of the expected data type, and the greater the protocol coverage at the field data type level of the structure. This directly reflects the differences between the expected and actual data types at the field type content level, reducing misleading differences caused by situations such as identical lengths but unrelated content, or different lengths but highly similar content. Therefore, it accurately quantifies the degree of difference between the expected and actual data types, effectively improving the accuracy of the third sub-coverage. It should be understood that the description of converting edit distance to similarity in this embodiment can refer to the description of converting edit distance to similarity in the previous example, and will not be repeated here.

[0088] For example, continuing with the above example, the edit distance between the identifier sequence of the field data type and the identifier sequence of the expected data type in the current dynamic load testing phase can be calculated, and the edit distance can be converted into a similarity in the range [0, 1]. Simultaneously, the ratio of the number of field data types in the current dynamic load testing phase to the number of expected data types in the current dynamic load testing phase can be calculated. Then, the mean of the similarity and the ratio is calculated as the third sub-coverage rate for the current dynamic load testing phase. Here, the edit distance can capture the differences between the expected data type and the actual data type at the field type content level, and the ratio processing can capture the differences between the expected data type and the actual data type at the field type quantity level. This embodiment, by focusing on the differences in field type data and field type content between the expected data type and the actual data type, can comprehensively and objectively explore the protocol coverage of field data types for the structure, thereby further improving the accuracy of the third sub-coverage rate.

[0089] Alternatively, the integration method for the second coverage rate can be set according to the actual situation, and this embodiment does not limit it. For example, when integrating the third, fourth, and fifth sub-coverage rates into the first coverage rate, the average of the third, fourth, and fifth sub-coverage rates can be used to determine the first coverage rate. Of course, in addition to the averaging method, a weighted summation method can also be used, that is, the sum of the third sub-coverage rate assigned a third weight, the fourth sub-coverage rate assigned a fourth weight, and the fifth sub-coverage rate assigned a fifth weight can be used to determine the second coverage rate. The third, fourth, and fifth weights can all be preset, and the sum of the third, fourth, and fifth weights is 1.

[0090] It should be noted that the method for summarizing protocol coverage can be set according to actual circumstances, and this embodiment does not limit it. For example, when summing the first coverage and the second coverage to obtain the protocol coverage, the average of the first and second coverage can be used as the protocol coverage. Of course, in addition to the averaging method, a weighted summation method can also be used, that is, the sum of the first coverage with a sixth weight and the second coverage with a seventh weight is determined as the protocol coverage. The sixth and seventh weights can both be preset, and their sum is 1.

[0091] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment divides the protocol coverage into two dimensions, one being the protocol name and the other being the structure field; coverage detection is performed on the protocol name to obtain a first coverage, thereby focusing on the protocol triggering situation; coverage detection is performed on the structure field to obtain a second coverage, thereby focusing on the integrity of the protocol message field; then, the coverage of these two dimensions is integrated into the final protocol coverage. In this way, by fully considering the strong correlation between the protocol triggering situation and the integrity of the protocol message field and the protocol coverage, the protocol coverage can be determined, which can accurately locate the local coverage of the target protocol in the dynamic stress testing phase and reduce the superficial coverage misleading caused by situations such as the protocol name meeting the standard but the structure field being missing, thereby effectively improving the accuracy of the protocol coverage.

[0092] In one implementation of the embodiments of this application, reference is made to Figure 5 The aforementioned at least two stress testing phases may include, but are not limited to, a static stress testing phase and at least one dynamic stress testing phase; the aforementioned calculation of the coverage of protocol attribute data from at least two stress testing phases to obtain the target coverage of the target protocol may further include, but is not limited to, the following steps: Coverage is calculated for protocol attribute data in the static stress testing phase to obtain the protocol coverage for the static stress testing phase; coverage is calculated for protocol attribute data in at least one dynamic stress testing phase to obtain the protocol coverage for at least one dynamic stress testing phase; the protocol coverage for the static stress testing phase and the protocol coverage for at least one dynamic stress testing phase are integrated to obtain the target coverage.

[0093] Specifically, the entire stress testing process can be referred to as the static stress testing phase, which is a coarse-grained stress testing phase. The entire stress testing process can be further subdivided into several test rounds, with each test round being the dynamic stress testing phase, which is a fine-grained stress testing phase. The division of stress testing can be flexibly set according to actual conditions. The division method for stress testing in this embodiment is similar to that in the previous embodiments and will not be repeated here.

[0094] It is understood that the types of each dynamic load testing stage can be the same or different, and can be flexibly set according to the actual situation. This embodiment does not limit this. The description of the types of dynamic load testing stages in this embodiment can be found in the description of the types of load testing stages in the above embodiments, and will not be repeated here. Similarly, the type of static load testing stage can be the same as or different from any of the dynamic load testing stages, and can be flexibly set according to the actual situation. This embodiment does not limit this.

[0095] It's important to note that protocol coverage in the static load testing phase refers to the initial coverage of the target protocol during this phase, reflecting its preliminary coverage during stress testing. A higher protocol coverage in the static load testing phase indicates better initial coverage of the target protocol. Similarly, protocol coverage in the dynamic load testing phase refers to the initial coverage of the target protocol during this phase, reflecting its partial coverage relative to the dynamic load testing phase. A higher protocol coverage in the dynamic load testing phase indicates better partial coverage of the target protocol within that phase. It should be understood that there is a one-to-one correspondence between dynamic load testing phases and protocol coverage rates; each dynamic load testing phase has its own independent protocol coverage rate.

[0096] In practical applications, related technologies typically rely on a single stress testing phase. However, during actual stress testing, a single phase is susceptible to unforeseen factors such as temporary network fluctuations and script execution anomalies. Furthermore, relying on a single stress testing phase for protocol coverage assessment is biased, resulting in low accuracy of protocol coverage for related technologies. Therefore, this embodiment defines the entire stress testing process as a coarse-grained static stress testing phase and divides it into at least one fine-grained dynamic stress testing phase, and performs stress testing accordingly. For example, if the entire stress testing process lasts 48 hours, a 48-hour stability stress test is first performed; this is called the static stress testing phase. After the static stress testing phase ends, these 48 hours are divided into 100 test rounds, resulting in 100 dynamic stress testing phases, and a second stress test is performed accordingly. Of course, these two types of stress testing phases can also be performed simultaneously; this embodiment does not limit this. Stress testing yields protocol attribute data for both static and dynamic stress testing phases. These attributes reflect the target protocol's performance in both phases, including protocol name, message structure fields, default values, and service interface definitions. This data is highly correlated with the target protocol's actual coverage during stress testing. After stress testing, coverage is first calculated based on the static stress testing data to determine the initial coverage of the target protocol. Then, coverage is calculated again based on the dynamic stress testing data to determine the coverage of at least one dynamic stress testing phase, reflecting the target protocol's partial coverage relative to the dynamic stress testing phases. Since the current coverage reflects only partial coverage, these coverage rates (static and dynamic) must be integrated into a target coverage rate to determine the overall global coverage of the target protocol throughout the stress testing process.

[0097] It is worth noting that in the aforementioned embodiments, the entire stress testing process was divided into fine-grained dynamic stress testing phases, and stress testing was performed accordingly. In this case, the aforementioned embodiments used fine-grained testing as a single benchmark to determine the target coverage. However, in this embodiment, the entire stress testing process is defined as a coarse-grained static stress testing phase, and the entire stress testing process is divided into fine-grained dynamic stress testing phases, and stress testing is performed accordingly. This embodiment uses both coarse-grained and fine-grained testing as dual benchmarks to determine the target coverage, which differs from the granularity level focused on in the aforementioned embodiments.

[0098] For example, when calculating the coverage of protocol attribute data for a static load testing phase or at least one dynamic load testing phase, the static load testing phase or dynamic load testing phase is defined as the target phase. The number of protocols used in the target phase is extracted from the protocol attribute data of the target phase, and the ratio of the number of protocols used in the target phase to the total number of protocols in the target phase is determined as the protocol coverage of the target phase. Here, the number of protocols used reflects the number of target protocols actually triggered during the load test, while the total number of protocols is the number of target protocols pre-configured and expected to be triggered before the load test. Since the number of protocols used is easily extracted and can directly reflect the coverage of the target protocols, this embodiment uses the number of protocols used and the total number of protocols as a benchmark to determine the protocol coverage of the target phase, which can quickly and accurately quantify the actual coverage of the target protocols in the target phase.

[0099] For example, during the integration process, machine learning methods can be used to integrate the protocol coverage from the static load testing phase and the protocol coverage from at least one dynamic load testing phase to obtain the target coverage of the target protocol. This machine learning method can learn the mapping relationship between the protocol coverage from the static and dynamic load testing phases and the target coverage. Here, machine learning methods have superior performance in data processing, allowing for the rapid and accurate calculation of the target coverage.

[0100] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment first uses the protocol attribute data of the static stress test stage as a benchmark to calculate the coverage rate and determine the protocol coverage rate of the static stress test stage. This can capture the coarse-grained protocol coverage situation, which is used to provide a rough coverage benchmark. At the same time, the coverage rate is calculated using the protocol attribute data of at least one dynamic stress test stage as a benchmark to determine the protocol coverage rate of at least one dynamic stress test stage. This can capture the fine-grained protocol coverage situation, which is used to provide detailed coverage values. Then, the target coverage rate is obtained by integrating the above coverage benchmark and the above coverage values. This can accurately capture the global coverage of the target protocol throughout the stress test process, further comprehensively cover the protocol behavior under different stress test stages, and make the target coverage rate objectively reflect the coverage of the protocol in different stress test stages. It can also effectively reduce the impact of accidental and one-sided factors on the protocol coverage detection, thereby effectively improving the detection accuracy of protocol coverage in stress testing.

[0101] In one implementation of this application, the above-mentioned calculation of the protocol attribute data in the static stress testing phase to obtain the protocol coverage in the static stress testing phase further includes, but is not limited to, the following steps: Information extraction and processing are performed on the protocol attribute data in the static load testing phase to obtain static protocol information. The static protocol information is used to indicate the descriptive information associated with the protocol name of the target protocol in the static load testing phase. Based on the static protocol information, the coverage is calculated to obtain the protocol coverage of the static load testing phase.

[0102] Specifically, static protocol information refers to descriptive information associated with the protocol name of the target protocol. It can be flexibly set according to the actual situation, and this embodiment does not limit it. For example, the above-mentioned static protocol information may include, but is not limited to, protocol name strings, protocol name enumeration values, etc.

[0103] In practical applications, after obtaining the protocol attribute data of the static stress test phase, the static protocol information of the static stress test phase is extracted from the protocol attribute data. The static protocol information is associated with the protocol name of the target protocol. The protocol name is highly correlated with the initial coverage of the target protocol in the stress test. Then, the coverage is calculated based on the protocol name of the target protocol to obtain the protocol coverage of the static stress test phase, thereby locating the initial coverage of the target protocol in the stress test.

[0104] It should be noted that the description of information extraction and processing in this embodiment can refer to the description of information extraction and processing in the previous embodiments, and will not be repeated here.

[0105] For example, when calculating coverage based on static protocol information, machine learning methods can be used to calculate the coverage of static protocol information during the static load testing phase, thus obtaining the protocol coverage for the static load testing phase. This machine learning method can learn the mapping relationship between static protocol information and protocol coverage. Here, machine learning methods have superior performance in data processing, and can quickly and accurately calculate protocol coverage.

[0106] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment first extracts the static protocol information of the static stress test stage from the protocol attribute data of the static stress test stage. The static protocol information is highly correlated with the protocol name of the target protocol. By using the actual situation of the protocol name, the initial performance of the target protocol in the stress test can be quickly and accurately located. Then, based on this, the coverage is calculated to obtain the protocol coverage of the static stress test stage. In this way, by fully considering the protocol name factor which is highly correlated with the protocol coverage, the protocol coverage of the static stress test stage is determined. This can accurately locate the initial coverage of the target protocol in the stress test, thereby effectively improving the accuracy of the protocol coverage in the static stress test stage.

[0107] In one implementation of this application, the aforementioned static protocol information may include, but is not limited to, protocol name strings and protocol name enumeration values; the aforementioned coverage calculation based on static protocol information to obtain the protocol coverage in the static load testing phase further includes, but is not limited to, the following steps: Based on the protocol name string and expected string from the static load testing phase, the third coverage rate of the static load testing phase is obtained; based on the protocol name enumeration value and expected enumeration value from the static load testing phase, the fourth coverage rate of the static load testing phase is obtained; the third and fourth coverage rates of the static load testing phase are integrated into the protocol coverage rate of the static load testing phase.

[0108] It should be noted that the description of determining the protocol coverage in the static load testing phase using the protocol name string and protocol name enumeration value in this embodiment can be referred to the description of determining the first coverage in the current dynamic load testing phase using the protocol name string and protocol name enumeration value in the previous embodiment, and will not be repeated here.

[0109] In one implementation of this application, the above-mentioned calculation of protocol attribute data for at least one dynamic stress testing stage to obtain the protocol coverage for at least one dynamic stress testing stage further includes, but is not limited to, the following steps: Information extraction processing is performed on the protocol attribute data of at least one dynamic stress testing phase to obtain dynamic protocol information for at least one dynamic stress testing phase; wherein, the dynamic protocol information is used to indicate the descriptive information associated with the protocol name and structure fields of the target protocol in the dynamic stress testing phase; coverage is calculated based on the dynamic protocol information of at least one dynamic stress testing phase to obtain the protocol coverage of at least one dynamic stress testing phase.

[0110] It is worth noting that in the aforementioned embodiments, the coverage calculation for the static load testing phase only used descriptive information associated with the protocol name. However, in this embodiment, the coverage calculation for the dynamic load testing phase uses not only descriptive information associated with the protocol name but also descriptive information associated with structure fields. The purpose of this is that the static load testing phase is a coarse-grained load testing phase, aiming to capture the initial coverage of the target protocol during stress testing. It requires approximate data; therefore, only descriptive information with low data volume that roughly reflects the protocol coverage (such as descriptive information related to the protocol name) is needed to achieve coverage. Coverage calculation is used to quickly locate the coarse-grained protocol coverage. The dynamic stress testing phase is a fine-grained stress testing phase, which aims to capture the local coverage of the target protocol in different dynamic stress testing phases. It requires more accurate data. Therefore, descriptive information with low data volume that can roughly reflect the protocol coverage (such as the relevant descriptive information of the protocol name) is introduced to align its local coverage with the initial coverage. At the same time, descriptive information with higher data volume that can better reflect the protocol coverage (such as the relevant descriptive information of the structure field) is introduced, and coverage calculation is performed based on this to accurately capture the fine-grained protocol coverage.

[0111] It should be noted that the description of coverage calculation for protocol attribute data in at least one dynamic stress test phase in this embodiment can be referred to the description of coverage calculation for protocol attribute data in at least two dynamic stress test phases in the above embodiment, and will not be repeated here.

[0112] In one implementation of this application, the above-mentioned integration of the protocol coverage in the static stress testing phase and the protocol coverage in at least one dynamic stress testing phase to obtain the target coverage further includes, but is not limited to, the following steps: The protocol coverage of at least one dynamic stress test phase is integrated to obtain the overall coverage; wherein, the overall coverage is used to indicate the coverage of the target protocol in all dynamic stress test phases; the overall coverage and the protocol coverage of the static stress test phase are integrated to obtain the target coverage.

[0113] Specifically, the overall coverage rate reflects the global coverage of the target protocol relative to all dynamic stress testing phases. A higher overall coverage rate indicates better global coverage of the target protocol across all dynamic stress testing phases.

[0114] In practical applications, the aforementioned coverage calculations can yield protocol coverage for at least one dynamic stress testing phase, reflecting fine-grained protocol coverage. Simultaneously, the protocol coverage for the static stress testing phase can also be obtained, reflecting coarse-grained protocol coverage. Based on this, this embodiment first integrates the fine-grained protocol coverage to obtain a comprehensive coverage rate, thereby capturing the global coverage of the target protocol relative to all dynamic stress testing phases. Then, this comprehensive coverage rate and the coarse-grained protocol coverage rate are integrated into a target coverage rate, thus locating the global coverage of the target protocol throughout the entire stress testing process.

[0115] It should be noted that when integrating the protocol coverage of at least one dynamic stress testing phase, if there is only one dynamic stress testing phase, the protocol coverage of that dynamic stress testing phase can be directly determined as the comprehensive coverage. If there are at least two dynamic stress testing phases, the description of integrating the protocol coverage of at least one dynamic stress testing phase in this embodiment can refer to the description of integrating the protocol coverage of at least two dynamic stress testing phases in the previous embodiment, and will not be repeated here.

[0116] For example, when integrating the overall coverage rate and the protocol coverage rate during the static load testing phase, the average of the overall coverage rate and the protocol coverage rate during the static load testing phase can be determined as the target coverage rate. Of course, besides the averaging method, a weighted summation method can also be used, where the sum of the overall coverage rate (with an eighth weight) and the protocol coverage rate during the static load testing phase (with a ninth weight) is determined as the target coverage rate. Both the eighth and ninth weights can be preset, with the eighth weight being greater than the ninth weight, and the sum of the eighth and ninth weights being 1. Here, considering the different importance of coarse-grained and fine-grained load testing phases in stress testing, with the coarse-grained phase typically being less important than the fine-grained phase, this embodiment introduces a weighted summation method. This method fully considers the importance of different granularity load testing phases in stress testing, and assigns corresponding weight values ​​to the overall coverage and the protocol coverage of the static load testing phase accordingly. A higher weight value means higher importance. This makes the overall coverage with the eighth weight and the protocol coverage of the static load testing phase with the ninth weight more closely resemble the actual coverage of the target protocol in stress testing. The resulting target coverage can more accurately reflect the global coverage of the target protocol throughout the entire stress testing process, thereby further improving the accuracy of the target coverage.

[0117] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment first integrates the protocol coverage of at least one dynamic stress test stage into a comprehensive coverage, which reflects the global coverage of the target protocol relative to all dynamic stress test stages, i.e., the global coverage at the fine-grained level. Then, the comprehensive coverage and the protocol coverage at the coarse-grained level are integrated into a target coverage. Thus, the target coverage is determined by integrating the preliminary coverage at the coarse-grained level and the global coverage at the fine-grained level. This can accurately capture the global coverage of the target protocol throughout the stress test process, further comprehensively cover the protocol behavior under different stress test stages, and make the target coverage objectively reflect the coverage of the protocol in different stress test stages. It also effectively reduces the impact of accidental and one-sided factors on the protocol coverage detection, thereby effectively improving the detection accuracy of protocol coverage in stress testing.

[0118] In one implementation of this application, the aforementioned at least two load testing stages may include, but are not limited to, at least two dynamic load testing stages, and the aforementioned test instructions may include, but are not limited to, a first test instruction; in response to the test instructions, load testing is performed on the target test case to obtain protocol attribute data for at least two load testing stages, and specifically, this may include, but is not limited to, the following steps: In response to the first test instruction, determine the load test type for at least two dynamic load test phases; based on the load test type for at least two dynamic load test phases, perform load testing on the target test case to obtain protocol attribute data for at least two dynamic load test phases.

[0119] It should be noted that the description of the stress test type in the dynamic stress test stage in this embodiment can refer to the description of the stress test type in the stress test stage in the previous embodiment, and will not be repeated here.

[0120] In practical applications, the entire stress testing process is pre-divided into at least two dynamic stress testing phases. For example, if the entire stress testing process lasts 48 hours, this 48 hours can be divided into 100 test rounds, resulting in 100 dynamic stress testing phases. In this case, the first test command is received and a response is initiated. Upon response, the stress testing type for at least two dynamic stress testing phases is first determined. The stress testing type determines the stress testing operations performed in each dynamic stress testing phase. Then, based on the stress testing types of at least two dynamic stress testing phases, tests are performed on the target test cases. Once the tests are completed, the protocol attribute data for at least two dynamic stress testing phases can be obtained.

[0121] For example, when performing a stress test with at least two dynamic stress test stages, the same terminal can be used to perform the stress test with at least two dynamic stress test stages sequentially; of course, different terminals can also be used to perform the stress test with at least two dynamic stress test stages simultaneously, and this embodiment does not limit this.

[0122] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment receives a first test command and responds to it. When responding, it first determines the test type of at least two dynamic stress test stages, and then performs stress test based on this. This can make the stress test more in line with the actual test requirements and ensure the accuracy of the stress test, thereby helping to improve the detection accuracy of protocol coverage in stress test.

[0123] In one implementation of this application, the at least two stress testing stages may include, but are not limited to, a static stress testing stage and at least one dynamic stress testing stage, and the test instructions may include, but are not limited to, a second test instruction; the step of stress testing the target test case in response to the test instructions to obtain protocol attribute data for at least two stress testing stages further includes, but is not limited to, the following steps: In response to the second test instruction, determine the load test type for the static load test phase and the load test type for at least one dynamic load test phase; based on the load test type for the static load test phase, perform load testing on the target test case to obtain the protocol attribute data for the static load test phase; based on the load test type for at least one dynamic load test phase, perform load testing on the target test case to obtain the protocol attribute data for at least one dynamic load test phase.

[0124] It should be noted that the description of the stress test type in this embodiment can refer to the description of the stress test type in the previous embodiment, and will not be repeated here.

[0125] In practical applications, the entire stress testing process is pre-defined as a static stress testing phase, while simultaneously dividing it into at least one dynamic stress testing phase. For example, if the entire stress testing process lasts 48 hours, performing 48 hours of stress testing constitutes the static stress testing phase. This 48 hours is then divided into 100 test rounds, resulting in 100 dynamic stress testing phases. In this case, a second test command is received and responded to. Upon response, the stress testing type for the static stress testing phase and the stress testing type for at least one dynamic stress testing phase are first determined. The stress testing type determines the stress testing operations performed in both the dynamic and static stress testing phases. Then, based on the stress testing type of at least one dynamic stress testing phase, tests are performed against the target test cases. Upon completion of the tests, the protocol attribute data for at least one dynamic stress testing phase is obtained. Similarly, based on the stress testing type of the static stress testing phase, tests are performed against the target test cases, and upon completion of the tests, the protocol attribute data for the static stress testing phase is obtained.

[0126] For example, when performing stress tests in the dynamic stress test phase and the static stress test phase, the same terminal can be used to perform the stress tests in the dynamic stress test phase and the static stress test phase in sequence. For example, the static stress test phase can be performed first and then the dynamic stress test phase, or the dynamic stress test phase can be performed first and then the static stress test phase. Of course, different terminals can also be used to perform stress tests in the dynamic stress test phase and the static stress test phase simultaneously. This embodiment does not limit this.

[0127] For example, continuing with the above example, if there are at least two dynamic stress testing stages, when performing stress tests with at least two dynamic stress testing stages, the same terminal can be used to perform stress tests with at least two dynamic stress testing stages sequentially; of course, different terminals can also be used to perform stress tests with at least two dynamic stress testing stages simultaneously, and this embodiment does not limit this.

[0128] At least one of the above technical solutions has the following advantages or beneficial effects: This embodiment receives a second test command and responds. When responding, it first determines the test type of the static test stage and the test type of at least one dynamic test stage. Then, based on this, it performs stress tests for the static test stage and stress tests for the dynamic test stage respectively. This makes the stress test more in line with the actual test requirements and ensures the accuracy of the stress test, thereby helping to improve the detection accuracy of protocol coverage in stress testing.

[0129] To better illustrate the technical solution of this embodiment, a specific example is provided below. The target protocol in this example is the Protobuf protocol, and the example specifically includes, but is not limited to, the following steps: S00, Receive test command; if the test command is the first test command, proceed to steps S201-S203, such as... Figure 6 As shown; if the test instruction is the second test instruction, then proceed to steps S301-S305, as follows. Figure 7 As shown.

[0130] S201, determine the load testing types for multiple dynamic load testing phases, and perform load testing on the target test cases accordingly to obtain protocol attribute data for multiple dynamic load testing phases. This protocol attribute data is a protocol.proto file. It should be understood that the first test instruction can carry the load testing type of the dynamic load testing phase, thus enabling the backend to determine the load testing type of multiple dynamic load testing phases through the first test instruction.

[0131] S202, determine the protocol coverage for multiple dynamic stress testing phases, specifically through the following steps S2021-S2024: S2021, parse the enum PF enumeration of the protocol.proto file under the current dynamic load testing phase to obtain the protocol name string and protocol name enumeration value of the Protobuf protocol under the current dynamic load testing phase. Parse the defined structure to obtain the field data type, field name and field number of the Protobuf protocol under the current dynamic load testing phase, thereby obtaining the dynamic protocol information of the Protobuf protocol under the current dynamic load testing phase.

[0132] S2022, based on the protocol name string and expected string of the current dynamic stress test phase, obtain the first sub-coverage of the current dynamic stress test phase, based on the protocol name enumeration value and expected enumeration value of the current dynamic stress test phase, obtain the second sub-coverage of the current dynamic stress test phase, and integrate the first sub-coverage and the second sub-coverage of the current dynamic stress test phase into the first coverage of the current dynamic stress test phase.

[0133] S2023. Based on the field data type and expected data type of the current dynamic load testing phase, the third sub-coverage of the current dynamic load testing phase is obtained. The field name and expected name of the current dynamic load testing phase are processed by the edit distance function to obtain the fourth sub-coverage of the current dynamic load testing phase. The ratio of the number of fields in the current dynamic load testing phase to the expected number of fields in the current dynamic load testing phase is determined as the fifth sub-coverage of the current dynamic load testing phase. Then, the third, fourth and fifth sub-coverages of the current dynamic load testing phase are integrated into the second coverage of the current dynamic load testing phase.

[0134] S2024 integrates the first and second coverage rates of the current dynamic stress test phase into the protocol coverage rate of the current dynamic stress test phase.

[0135] S203 integrates the protocol coverage from multiple dynamic stress testing phases into the target coverage of the target protocol, thereby determining the actual coverage of the target protocol during stress testing.

[0136] S301, determine the load test type for multiple dynamic load test phases and the load test type for the static load test phase, and perform load tests on the target test cases accordingly to obtain the protocol attribute data for the static load test phase and the protocol attribute data for multiple dynamic load test phases. The protocol attribute data is the protocol.proto file.

[0137] S302, Determine the protocol coverage during the static stress test phase, specifically through the following steps S3021-S3022: S3021, parse the enum PF enumeration of the protocol.proto file during the static load testing phase to obtain the protocol name string and protocol name enumeration value of the Protobuf protocol during the static load testing phase, which is the static protocol information of the Protobuf protocol during the static load testing phase.

[0138] S3022, based on the protocol name string and expected string of the static load testing phase, obtain the third coverage rate of the static load testing phase, based on the protocol name enumeration value and expected enumeration value of the static load testing phase, obtain the fourth coverage rate of the static load testing phase, and integrate the third coverage rate and the fourth coverage rate of the static load testing phase into the protocol coverage rate of the static load testing phase.

[0139] S303, determine the protocol coverage of multiple dynamic stress testing phases. Specifically, based on the description information associated with the protocol name of the target protocol in at least one dynamic stress testing phase, obtain the fifth coverage of at least one dynamic stress testing phase; based on the description information associated with the structure fields of the target protocol in at least one dynamic stress testing phase, obtain the sixth coverage of at least one dynamic stress testing phase; summarize the fifth and sixth coverages of at least one dynamic stress testing phase to obtain the protocol coverage of at least one dynamic stress testing phase. It should be understood that the specific implementation of step S303 can be found in the operations shown in steps S2021-S2024 above, and will not be repeated here.

[0140] S304 integrates the protocol coverage from multiple dynamic stress testing phases to obtain the overall coverage.

[0141] S305 integrates the overall coverage rate and the protocol coverage rate during the static stress test phase to obtain the target coverage rate, thereby determining the actual coverage of the target protocol during stress testing.

[0142] Optionally, the target coverage can be visualized after it is obtained. Of course, the target coverage can also be printed as a report, which can be in Hyper Text Markup Language (HTML) format, but is not limited to this.

[0143] Alternatively, the above implementation process can be integrated into a Python script. When protocol coverage needs to be checked, a Blue Shield pipeline is built, a Docker public build machine is configured to execute the script, and an automated stress test task is started simultaneously. After completion, the protocol coverage is automatically checked, which can effectively improve the efficiency of protocol coverage detection. The Blue Shield pipeline can be set to execute automatically at regular intervals, and the execution results can be displayed and integrated into an execution report.

[0144] Corresponding to the above method embodiments, this application also provides a stress testing protocol coverage detection device. Figure 8 A schematic diagram of the structure of a stress testing protocol coverage detection device according to an embodiment of this application is shown, as follows: Figure 8 As shown, the stress testing protocol coverage detection device 400 may include, but is not limited to, a testing module 401 and a processing module 402. The testing module 401 is used to perform stress testing on the target test cases in response to test instructions, obtaining protocol attribute data for at least two stress testing phases; wherein the protocol attribute data is used to indicate attribute data associated with the target protocol, and the target protocol is deployed in the target test cases; the processing module 402 is used to calculate the coverage of the protocol attribute data for at least two stress testing phases to obtain the target coverage of the target protocol.

[0145] It should be noted that the above is a schematic scheme of a load testing protocol coverage detection device in this embodiment. The technical solution of the load testing protocol coverage detection device and the technical solution of the load testing protocol coverage detection method belong to the same concept. For details not described in detail in the technical solution of the load testing protocol coverage detection device, please refer to the description of the technical solution of the load testing protocol coverage detection method.

[0146] Corresponding to the above method embodiments, this application also provides a computer device, which may include a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described stress testing protocol coverage detection method.

[0147] It should be noted that the above is an illustrative scheme of a computer device according to this embodiment. The technical solution of this computer device and the technical solution of the above-described load testing protocol coverage detection method belong to the same concept. For details not described in detail in the technical solution of the computer device, please refer to the description of the technical solution of the above-described load testing protocol coverage detection method.

[0148] Corresponding to the above method embodiments, this application also provides a computer storage medium. The computer-readable storage medium stores multiple instructions, which are adapted for a processor to load and execute the above-described stress test protocol coverage detection method.

[0149] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate, and may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0151] The above provides a detailed description of the preferred embodiments of this application. However, this application is not limited to the above-described embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for detecting protocol coverage under load testing, characterized in that, include: In response to a test command, stress tests are performed on the target test case to obtain protocol attribute data for at least two stress test phases; wherein, the protocol attribute data is used to indicate attribute data associated with the target protocol, which is deployed in the target test case; Coverage calculations are performed on protocol attribute data from at least two of the stress testing phases to obtain the target coverage of the target protocol.

2. The method according to claim 1, characterized in that, The at least two stress testing phases include at least two dynamic stress testing phases; the step of calculating the coverage of the protocol attribute data of the at least two stress testing phases to obtain the target coverage of the target protocol includes: Coverage calculation is performed on the protocol attribute data of at least two of the dynamic stress testing phases to obtain the protocol coverage of at least two of the dynamic stress testing phases; The protocol coverage of at least two of the dynamic stress testing phases is integrated to obtain the target coverage.

3. The method according to claim 2, characterized in that, The step of calculating the protocol attribute data coverage for at least two stress testing phases to obtain the protocol coverage for at least two stress testing phases includes: Information extraction processing is performed on the protocol attribute data of at least two of the dynamic stress testing phases to obtain dynamic protocol information for at least two of the dynamic stress testing phases; wherein, the dynamic protocol information is used to indicate the descriptive information associated with the protocol name and structure field of the target protocol in the dynamic stress testing phase; Coverage is calculated based on dynamic protocol information from at least two of the dynamic stress testing phases to obtain the protocol coverage for at least two of the dynamic stress testing phases.

4. The method according to claim 3, characterized in that, The step of calculating the protocol coverage based on dynamic protocol information from at least two of the dynamic stress testing phases to obtain the protocol coverage for at least two of the dynamic stress testing phases includes: Based on the description information associated with the protocol name of the target protocol in at least two of the dynamic stress testing phases, a first coverage rate for at least two of the dynamic stress testing phases is obtained; Based on the description information associated with the structure fields of the target protocol in at least two of the dynamic stress testing phases, a second coverage of at least two of the dynamic stress testing phases is obtained; The first and second coverage rates of at least two dynamic stress testing phases are aggregated to obtain the protocol coverage rates of at least two dynamic stress testing phases.

5. The method according to claim 1, characterized in that, At least two of the stress testing phases include a static stress testing phase and at least one dynamic stress testing phase; the step of calculating the coverage of the protocol attribute data of the at least two stress testing phases to obtain the target coverage of the target protocol includes: The protocol attribute data of the static stress test phase is used to calculate the coverage rate, and the protocol coverage rate of the static stress test phase is obtained. Coverage calculation is performed on the protocol attribute data of at least one of the dynamic stress testing phases to obtain the protocol coverage of at least one of the dynamic stress testing phases; The target coverage rate is obtained by integrating the protocol coverage rate of the static stress testing phase and at least one of the dynamic stress testing phases.

6. The method according to claim 5, characterized in that, The step of calculating the protocol attribute data coverage during the static load testing phase to obtain the protocol coverage during the static load testing phase includes: The protocol attribute data in the static stress test phase is processed to extract static protocol information; wherein, the static protocol information is used to indicate the descriptive information associated with the protocol name of the target protocol in the static stress test phase. The coverage rate is calculated based on the static protocol information to obtain the protocol coverage rate during the static stress test phase.

7. The method according to claim 6, characterized in that, The static protocol information includes the protocol name string and expected string for the static load testing phase; the coverage calculation based on the static protocol information to obtain the protocol coverage for the static load testing phase includes: The third coverage of the static load testing phase is obtained based on the protocol name string and expected string of the static load testing phase. The fourth coverage rate of the static load testing phase is obtained based on the protocol name enumeration value and the expected enumeration value of the static load testing phase. The third and fourth coverage rates of the static stress testing phase are integrated into the protocol coverage rate of the static stress testing phase.

8. The method according to claim 5, characterized in that, The step of calculating the coverage of protocol attribute data for at least one of the dynamic stress testing phases to obtain the protocol coverage for at least one of the dynamic stress testing phases includes: Information extraction processing is performed based on protocol attribute data from at least one of the dynamic stress testing phases to obtain dynamic protocol information for at least one of the dynamic stress testing phases; wherein, the dynamic protocol information is used to indicate descriptive information associated with the protocol name and structure fields of the target protocol in the dynamic stress testing phase; Coverage is calculated based on dynamic protocol information from at least one of the dynamic stress testing phases to obtain the protocol coverage of at least one of the dynamic stress testing phases.

9. The method according to claim 8, characterized in that, The step of calculating the protocol coverage based on dynamic protocol information from at least one of the dynamic stress testing phases to obtain the protocol coverage for at least one of the dynamic stress testing phases includes: Based on the description information associated with the protocol name of the target protocol in at least one of the dynamic stress testing phases, a fifth coverage rate for at least one of the dynamic stress testing phases is obtained; Based on the description information associated with the structure field of the target protocol in at least one of the dynamic stress testing phases, a sixth coverage of at least one of the dynamic stress testing phases is obtained; The fifth and sixth coverage rates of at least one of the dynamic stress testing phases are aggregated to obtain the protocol coverage rate of at least one of the dynamic stress testing phases.

10. The method according to claim 5, characterized in that, The process of integrating the protocol coverage from the static stress testing phase and the protocol coverage from at least one dynamic stress testing phase to obtain the target coverage includes: The protocol coverage of at least one of the dynamic stress testing phases is integrated to obtain a comprehensive coverage; wherein the comprehensive coverage is used to indicate the coverage of the target protocol in all of the dynamic stress testing phases. The overall coverage rate and the protocol coverage rate during the static stress test phase are integrated to obtain the target coverage rate.

11. The method according to claim 1, characterized in that, The at least two stress testing phases include at least two dynamic stress testing phases, and the test instructions include a first test instruction; in response to the test instructions, stress testing is performed on the target test cases to obtain protocol attribute data for at least two stress testing phases, including: In response to the first test command, determine the test type for at least two of the dynamic stress test phases; Based on the stress test types of at least two of the dynamic stress test phases, stress test the target test case to obtain protocol attribute data for at least two of the dynamic stress test phases.

12. The method according to claim 1, characterized in that, At least two of the stress testing phases include a static stress testing phase and at least one dynamic stress testing phase, and the test instructions include a second test instruction; in response to the test instructions, stress testing is performed on the target test cases to obtain protocol attribute data for at least two stress testing phases, including: In response to the second test command, determine the test type of the static stress test phase and the test type of at least one of the dynamic stress test phases; Based on the stress test type in the static stress test phase, stress test is performed on the target test case to obtain the protocol attribute data of the static stress test phase. Based on the stress test type of at least one of the dynamic stress test stages, stress test is performed on the target test case to obtain protocol attribute data of at least one of the dynamic stress test stages.

13. A pressure testing protocol coverage detection device, characterized in that, include: The testing module is used to perform stress testing on the target test case in response to test instructions, and obtain protocol attribute data for at least two stress testing phases; wherein, the protocol attribute data is used to indicate attribute data associated with the target protocol, and the target protocol is deployed in the target test case; The processing module is used to perform coverage calculation on the protocol attribute data of at least two stress testing phases to obtain the target coverage of the target protocol.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the load testing protocol coverage detection method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to execute the load testing protocol coverage detection method according to any one of claims 1 to 12.

Images