Network anomaly testing method, device, equipment, storage medium and program

Abstract

The application provides a network exception test method and device, equipment, storage medium and program, relates to the artificial intelligence technical field, can be applied to cloud technology, artificial intelligence, intelligent transportation, auxiliary driving and various scenes, including: obtaining the service call link corresponding to the execution process of the system use case in the micro-service system; respectively identifying the service types of each called micro-service in the service call link; in the case of identifying the target business service and the micro-service to be tested, obtaining and identifying the interface log data generated by the micro-service to be tested in the execution process of the system use case, obtaining the corresponding target business meaning information; calling the corresponding target exception injection rule, injecting exceptions for the system use case to generate processing, obtaining the network exception test case; in the micro-service system, executing the network exception test case through the service call link to obtain the corresponding exception test result. The application can effectively improve the network exception test efficiency.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus, device, storage medium, and program for testing network anomalies. Background Technology

[0002] Network anomalies refer to deviations in network traffic behavior from its normal course. These anomalies may be caused by external attacks or network instability. During network system operation, artificially created error scenarios can be used to test the system's response to erroneous operations / messages, checking whether the system provides clear and sufficient prompts or constraints, thus achieving anomaly testing. However, existing anomaly testing methods rely on manually setting and combining anomaly data, specifying anomaly types, and retrieving test log files to determine the correctness of test results in conjunction with business logic. This process is cumbersome, time-consuming, and inefficient. Therefore, an improved network anomaly testing scheme is needed to improve testing efficiency and reduce testing costs. Summary of the Invention

[0003] This application provides a method, apparatus, device, storage medium, and program product for network anomaly testing.

[0004] On the one hand, this application provides a method for network anomaly testing, the method comprising:

[0005] Obtain the service call chain corresponding to the execution process of the system test cases in the microservice system; the system test cases are test cases used to test the business functions of the microservice system.

[0006] Based on the interface parameters of each called microservice in the service call chain, the service type of each called microservice is identified.

[0007] If it is identified that each of the called microservices includes a target business service and a microservice under test, obtain the interface log data generated by the microservice under test during the execution of the system use case;

[0008] The interface log data of the microservice under test is used to identify the business meaning and obtain the corresponding target business meaning information.

[0009] Based on the target anomaly injection rules corresponding to the target business meaning information, injection anomaly generation processing is performed on the system test cases to obtain the corresponding network anomaly test cases.

[0010] In the microservice system, the network anomaly test cases are executed through the service call chain to obtain the corresponding anomaly test results.

[0011] On the other hand, a network anomaly testing device is provided, the device comprising:

[0012] Call chain acquisition module: used to acquire the service call chain corresponding to the execution process of system test cases in the microservice system; the system test cases are test cases used to test the business functions of the microservice system;

[0013] Service type identification module: used to identify the service type of each called microservice based on the interface parameters of each called microservice in the service call chain;

[0014] Interface log data acquisition module: used to acquire interface log data generated by the microservice under test during the execution of the system use case when it is identified that each called microservice includes a target business service and a microservice under test;

[0015] Business meaning identification module: used to identify the business meaning of the interface log data of the microservice under test, and obtain the corresponding target business meaning information;

[0016] Injection Anomaly Generation Module: Based on the target anomaly injection rules corresponding to the target business meaning information, injection anomaly generation processing is performed on the system test cases to obtain the corresponding network anomaly test cases;

[0017] Anomaly testing module: Used in the microservice system to execute the network anomaly test cases through the service call chain and obtain the corresponding anomaly test results.

[0018] On the other hand, a computer device is provided, the device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the network anomaly testing method as described above.

[0019] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement the network anomaly testing method as described above.

[0020] On the other hand, a server is provided, the server including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the network anomaly testing method as described above.

[0021] On the other hand, a computer program product is provided, which includes computer instructions that, when executed by a processor, implement the network anomaly testing method described above.

[0022] The network anomaly testing method, apparatus, equipment, storage medium, server, and computer program product provided in this application have the following technical effects:

[0023] This application obtains the service call chain corresponding to the execution process of system test cases in a microservice system. The system test cases are used to test the business functions of the microservice system. Based on the interface parameters of each called microservice in the service call chain, the service type of each called microservice is identified. If the identified called microservices include both the target business service and the microservice under test, the interface log data generated by the microservice under test during the execution of the system test cases is obtained. The business meaning of the interface log data of the microservice under test is identified to obtain the corresponding target business meaning information. Based on the target exception injection rules corresponding to the target business meaning information, injection exception generation processing is performed on the system test cases to obtain the corresponding network exception test cases. In the microservice system, the network exception test cases are executed through the service call chain to obtain the corresponding exception test results. This application can utilize existing functional test cases to automatically generate exception data and corresponding exception test cases through service type identification and business meaning identification, without rewriting basic test cases or manually combining exception data, effectively improving the efficiency and utilization of test case generation. Meanwhile, by using preset exception injection rules and system test case replay for exception testing, the system can inherit the test result analysis capabilities obtained during functional testing, thereby reducing the complexity of exception test result analysis. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application;

[0026] Figure 2 This is a flowchart illustrating a network anomaly testing method provided in an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of a test task creation window provided in an embodiment of this application;

[0028] Figure 4 This is a schematic diagram of a task report display window provided in an embodiment of this application;

[0029] Figure 5 This is a schematic diagram of the architecture of a testing system provided in an embodiment of this application;

[0030] Figure 6 This is a flowchart illustrating another network anomaly testing method provided in an embodiment of this application;

[0031] Figure 7 This is a flowchart illustrating another network anomaly testing method provided in an embodiment of this application;

[0032] Figure 8 This is a flowchart illustrating a network anomaly testing method provided in an embodiment of this application;

[0033] Figure 9 This is a schematic diagram of the framework of a network anomaly testing device provided in an embodiment of this application;

[0034] Figure 10 This is a hardware structure block diagram of an electronic device for a network anomaly testing method provided in an embodiment of this application;

[0035] Figure 11 This is a schematic diagram of the structure of a blockchain system provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or sub-modules is not necessarily limited to those steps or sub-modules explicitly listed, but may include other steps or sub-modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0038] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0039] Anomaly testing: Test the system's response to erroneous operations / error messages by artificially creating error scenarios, and check whether the system provides clear and sufficient prompts or constraints.

[0040] Network anomaly: Network traffic behavior deviates from its normal behavior, which may be caused by external attacks or network instability.

[0041] Mock: In testing, a virtual object is created to test certain objects that are not easy to construct or obtain. That is, various technical means are used to simulate various necessary resources for testing.

[0042] Automated testing: The process of using other software, independent of the software under test, to automatically perform tests, compare actual results with expectations, and generate test reports.

[0043] Please see Figure 1 , Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application, such as... Figure 1 As shown, the application environment may include at least server 01 and terminal 02. In practical applications, terminal 01, server 01, and terminal 02 can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0044] In this embodiment, server 01 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides 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, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0045] Specifically, cloud technology refers to a managed technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It distributes computing tasks across a resource pool composed of numerous computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." Artificial intelligence cloud services are generally also known as AIaaS (AI as a Service). This is currently a mainstream service model for artificial intelligence platforms. Specifically, AIaaS platforms break down several common AI services and provide them as independent or packaged services in the cloud. This service model is similar to opening an AI-themed marketplace: all developers can access and use one or more AI services provided by the platform through API interfaces. Some experienced developers can also use the AI ​​framework and AI infrastructure provided by the platform to deploy and maintain their own dedicated cloud AI services.

[0046] Specifically, the servers mentioned above may include physical devices, such as network communication submodules, processors, and memory, as well as software running on the physical devices, such as applications.

[0047] In this embodiment, terminal 02 may include physical devices such as smartphones, desktop computers, tablets, laptops, digital assistants, augmented reality (AR) / virtual reality (VR) devices, smart voice interaction devices, smart home appliances, smart wearable devices, and in-vehicle terminal devices, and may also include software running on the physical device, such as applications.

[0048] In this embodiment, terminal 02 can send a network anomaly test command to server 01 to trigger network anomaly test operations on server 01. This command carries identification information and test environment information for one or more microservices under test. The identification information can be the name or ID of the microservice under test, and the test environment information can include environment ID and environment type. Terminal 02 can also send a test data acquisition request to server 01 and receive network anomaly test results, anomaly test assertion results, anomaly test reports, and anomaly test operation data from server 01. Specifically, server 01 can provide system test case execution services and network anomaly test services to obtain system test case execution results, network anomaly test results, anomaly test assertion results, anomaly test reports, and anomaly test operation data, and send a test completion notification to terminal 02. In response to terminal 01's test data acquisition request, server 01 feeds back the system test case execution results, network anomaly test results, anomaly test assertion results, anomaly test reports, and anomaly test operation data to terminal 02. Furthermore, Server 01 can also provide data storage services for network anomaly testing, such as providing target knowledge bases, system test case execution results, network anomaly test results, anomaly test assertion results, anomaly test reports, anomaly test operation data, and related test logs. Specifically, test completion notification information may include, but is not limited to, the number of network anomaly test cases generated, statistical data on network test case anomaly test assertion results, and instructions for obtaining network anomaly test task reports.

[0049] In this embodiment, the terminal can provide a human-computer interaction interface (HCI) to receive test trigger operations. In response to the test trigger operation, the terminal displays a corresponding test task creation window on the HCI to receive the identification information and test environment information of the microservice under test. In response to the identification information and test environment information, the terminal generates corresponding network anomaly test instructions. Furthermore, the terminal can also display test completion notification information, system test case execution results, network anomaly test results, anomaly test assertion results, anomaly test reports, and anomaly test operation data through the HCI. Please refer to [reference needed]. Figure 3 , Figure 3 The diagram illustrates a test task creation window. The test trigger operation can be initiated by submitting a task creation request address, including " / task / task_create_and_run", to the user interface. The test task creation window displays input options such as the name of the microservice under test (server_name), the test request identifier (req_id), the test environment identifier type (env_id), and the test environment type (env_type). Please refer to [reference needed]. Figure 4 , Figure 4This is a schematic diagram of a task report display window.

[0050] Furthermore, it is understandable that Figure 1 The example shown is merely an application environment for a network anomaly testing method. This application environment may include more or fewer nodes, and this application does not impose any restrictions here.

[0051] The application environment involved in this application embodiment, or the terminal 02 and server 01 in the application environment, can be a distributed system formed by connecting clients and multiple nodes (any form of computing device accessing the network, such as servers and user terminals) through network communication. The distributed system can be a blockchain system, which can provide the aforementioned network anomaly testing service and data storage service, etc.

[0052] See Figure 11 , Figure 11 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system. It consists of multiple nodes (any form of computing device in the network, such as servers or user terminals) and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0053] Blockchain, an emerging application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms, is essentially a decentralized database. It consists of a chain of data blocks linked using cryptographic methods, each containing information about a batch of network transactions used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer. The blockchain underlying platform can include modules for user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic service module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication (interface adaptation), and then encrypts the business information using a consensus algorithm (consensus management). The blockchain process involves several key steps: First, encryption and secure transmission of data to the shared ledger (network communication) for recording and storage. Second, the smart contract module handles contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Execution is triggered by calling keys or other events based on the contract terms, completing the contract logic. The module also provides contract upgrade and cancellation functionality. Third, the operation and monitoring module handles deployment, configuration modification, contract settings, cloud adaptation, and real-time visualization of the product's operational status, including alerts, network status monitoring, and node device health monitoring. The platform's product service layer provides basic capabilities and implementation frameworks for typical applications. Developers can leverage these capabilities and add business characteristics to implement business logic on the blockchain. Finally, the application service layer provides blockchain-based application services to business stakeholders.

[0054] The following describes a testing system based on the above application environment. Please refer to it. Figure 5 , Figure 5This diagram illustrates the architecture of a testing system provided in an embodiment of this application. The testing system is interdependent with the trace platform, mock platform, and fitauto test platform. The trace platform provides capabilities such as service chain tracing, the mock platform provides mock testing capabilities, and the fitauto test platform provides test implementation capabilities. A RESTful interface serves as the external entry point for the testing system, through which it outputs test service capabilities. A database (DB) provides data access capabilities during network anomaly testing. The testing system includes a task app, a test case app, a mockup app, and a mockup app. The task app schedules test tasks, the test case app automatically generates network anomaly test cases, the mockup app records service call chains and their hierarchical relationships to assist in test case generation, and the mockup app performs anomaly data generation and injection processing. Each app in the testing system establishes dependencies with its external platforms to collaboratively implement network anomaly testing.

[0055] The following describes a network anomaly testing method based on the aforementioned application environment. This method is applied to the server side, and its embodiments can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving. Please refer to... Figure 2 , Figure 2 This is a flowchart illustrating a network anomaly testing method provided in this application. This specification provides the method operation steps as shown in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many, and does not represent the only execution order. In actual system or server product execution, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 2 As shown, the method may include the following steps.

[0056] S201: Obtain the service call chain corresponding to the execution process of the system use cases in the microservice system.

[0057] In this embodiment, system use cases are test cases used to test the business functions of a microservice system. These can include, but are not limited to, black-box use cases covering various scenarios, including requests to the microservice system and first result assertions. Specifically, a microservice system is a system running on a microservice framework, which can include multiple microservices. Each microservice in the system can be deployed independently and can be loosely coupled. Each microservice can be configured to perform one or more tasks, each task representing a business capability with corresponding business functions. System use cases can be test cases used during the development of the microservice system or its related microservices to test the business functions of the microservice system or microservices, such as testing whether the business functions can be implemented normally. For example, in an account transaction scenario, system use cases can be used to test whether the payment function can be implemented. System use cases can be manually written in the above process or automatically generated in batches based on prior knowledge.

[0058] In practical applications, a service call chain represents the sequence and hierarchy of microservices traversed during the execution of a system use case in a microservice system. Specifically, a service call chain includes at least two called microservices; for example, a service call chain could be microservice A-microservice B-microservice C, with communication between the called microservices based on microservice interfaces. Specifically, a database can pre-store a system use case library for microservice systems, allowing for the periodic batch execution of some or all system use cases in the library, recording and storing the service call chain during the execution of each system use case. The information corresponding to the service call chain includes, but is not limited to, the identification information of each called microservice and the call hierarchy. The test system can leverage the capabilities of a trace platform to trace and record the aforementioned service call chains. After obtaining the service call chain corresponding to a system use case from the trace platform, it parses it to obtain the identification information of the relevant called microservices and the call hierarchy, records and stores this information, and constructs the correspondence between service call chains and system use cases. Understandably, different service call chains may exist in different execution processes of the same system use case; these different service call chains of the same system use case can be marked separately, for example, using version numbers. During network anomaly testing, the latest version of the service call chain can be selected. Understandably, one service call chain can correspond to multiple system test cases; that is, different system test cases can share the same service call chain.

[0059] In a specific embodiment, in response to a network anomaly test command triggered by the terminal, the above-mentioned S201 is executed.

[0060] By using pre-stored system test cases as the base test cases for network anomaly testing, the original capabilities of business function testing can be leveraged, eliminating the need to repeatedly write base test cases in batches. In some cases, batch running of system test cases can pre-select system test cases that can execute successfully and whose execution results conform to the first assertion information, thereby ensuring the quality of network anomaly test cases.

[0061] S203: Based on the interface parameters of each called microservice in the service call chain, identify the service type of each called microservice.

[0062] In this embodiment, the service type of each microservice in the microservice system can be predefined. The service type can represent the business type to which the microservice belongs, such as an accounting-related microservice. Specifically, a target knowledge base can be pre-built to store the knowledge required during network anomaly testing. This target knowledge base pre-stores the correspondence between the interface parameters of microservices and their service types, for example, stored in a list format. Based on this correspondence between interface parameters and service types, the service type of each called microservice in the service call chain is identified to obtain the service type of each called microservice.

[0063] S205: If it is found that each called microservice includes the target business service and the microservice under test, obtain the interface log data generated by the microservice under test during the execution of the system test case.

[0064] In this embodiment, the network anomaly test instruction carries the identification information of the microservice under test. By traversing the service call chain, it can be determined whether the identification information of the microservice under test exists in the identification information of each called microservice, and thus whether the microservice under test exists in the chain. After determining the service type of each called microservice, it can be determined whether a target business service belonging to the target business type exists in the service call chain based on the service type. For example, it can be determined whether there is a microservice for account movement belonging to the account movement business type. Account movement microservices refer to services that involve changes in funds. The existence of such a target business service indicates that the service call chain of the current system use case belongs to the business scenario corresponding to the target business type. For example, the existence of an account movement microservice indicates a business scenario involving changes in funds, such as a transaction scenario or a property savings scenario. By identifying the service call chain including the target business service and the microservice under test, network anomaly testing for different business scenarios can be automatically implemented separately without the need to classify system use cases into scenarios, thus improving the efficiency of anomaly testing.

[0065] In practical applications, log data during the execution of system use cases is pre-recorded and stored, including interface log data. Interface log data refers to log data generated by the called microservice during the execution of system use cases, related to the called interface of the called microservice. Specifically, log data during the execution of system use cases can be recorded and stored based on a trace platform.

[0066] S207: Identify the business meaning of the interface log data of the micro-test service to obtain the corresponding target business meaning information.

[0067] In this embodiment, the interface log data records communication data between the microservice under test and other called microservices in the service call chain, including but not limited to message information of network packets received or sent by the microservice under test during system test case execution. The target knowledge base may pre-store the correspondence between message information and business meaning. Accordingly, the target business meaning information includes target message information and the target business meaning corresponding to the target message information; S207 may include: based on the correspondence between message information and business meaning in the target knowledge base, performing business meaning identification on the interface log data to obtain the target message information and the target business meaning corresponding to the target message information in the interface log data.

[0068] In practical applications, the message information in interface log data takes the form of message fields. The business meaning can be predefined, representing the business subtype to which the message field belongs. For example, payment services have multiple payment methods, each corresponding to a specific business meaning. Similarly, under the account transaction type, the message field "total_fee" is an amount field, and its business meaning can be "transaction amount." Business meanings can also include preset field formats. One or more message fields can be combined to correspond to a business meaning. By identifying the business meaning, the specific business function corresponding to the called interface can be determined.

[0069] In a specific embodiment, the target message information can be the request / response string of the microservice under test being invoked. By scanning the log fields in the interface log data and using pre-stored message fields in the target knowledge base to perform field matching on each log field (e.g., regular expression matching), the matched log fields are determined as target message fields. Based on the business meaning corresponding to the matched log fields in the target knowledge base, the target business meaning is obtained. Specifically, multiple message fields can correspond to one business meaning.

[0070] In one embodiment, the business type of the target business service is the transaction business type. Accordingly, the target message information of the payment type is matched. For example, the regular expression {"key":"total_fee|(amount.*)"} can be used to perform regular expression matching on the amount field of the request / response string. The corresponding business meaning is "transaction amount". The meaning of this regular expression is to match key-value pairs in the request / response string where the key is "total_fee" or "amount.*" and the key and value represent the amount.

[0071] S209: Based on the target anomaly injection rules corresponding to the target business meaning information, perform injection anomaly generation processing on system test cases to obtain the corresponding network anomaly test cases.

[0072] In this embodiment, if the service call chain includes both the microservice under test and the target business service, abnormal test cases corresponding to the system test cases are generated. If the service call chain corresponds to multiple system test cases, i.e., based on the correspondence between the service call chain and the system test cases constructed after batch running of the system test cases, it is determined that multiple system test cases share the same service call chain. Then, the interface log data generated by the microservice under test during the execution of each system test case corresponding to the service call chain is obtained, and steps S207 and S209 are executed to generate network abnormal test cases in batches for the system test cases and the microservice under test corresponding to this service call chain. Thus, by parsing a service call chain, multiple network abnormal test cases corresponding to the microservice under test can be generated, improving the efficiency of test case generation.

[0073] In practical applications, the target knowledge base can pre-store the correspondence between message information (such as message fields) and / or business meanings, and the target anomaly injection rules. Accordingly, prior to S209, the method could include: determining the target anomaly injection rule corresponding to the target business meaning information based on the correspondence between message information and target anomaly injection rules in the target knowledge base, or the correspondence between business meanings and target anomaly injection rules. That is, determining one or more anomaly injection rules corresponding to the target message field or target business meaning in the interface log data; and generating injection anomalies based on these one or more anomaly injection rules for relevant system use cases to obtain network anomaly use cases. For example, the target anomaly injection rule corresponding to the amount field could include mock tampering rules and mock transmission anomaly injection rules, and could also include mock re-entry rules and mock delay rules.

[0074] In practical applications, please refer to Figure 6 S209 may include the following steps.

[0075] S2091: Construct target anomaly data corresponding to target message information based on target anomaly injection rules.

[0076] S2092: Generate network anomaly test cases based on target anomaly data and system test cases.

[0077] In some embodiments, network anomaly test cases refer to normally executed system test cases plus target anomaly data to be injected. After obtaining the target anomaly data corresponding to the target packet information, the association between the target anomaly data and the system test cases is constructed to generate network anomaly test cases. Specifically, the association between the target anomaly data and the target packet information (or the target network packet corresponding to the target packet information) also needs to be constructed to perform corresponding anomaly injection processing when the network anomaly test cases are executed. By automatically generating anomaly data, network anomaly test cases can be generated automatically.

[0078] In some cases, the network anomalies to be injected may include, but are not limited to, tampered anomaly data corresponding to mock tampering rules and transmission anomaly data corresponding to mock transmission anomaly injection rules.

[0079] In some embodiments, the target anomaly injection rule includes mock tampering rules. The target anomaly data includes tampered anomaly data. Accordingly, please refer to... Figure 7 S2091 may include the following steps.

[0080] S301: When the target exception injection rule is a mock tampering rule, obtain the associated message information corresponding to the target message information from the historical interface log data of the microservice under test.

[0081] S302: Construct tampering anomaly data corresponding to the target message information based on mock tampering rules and associated message information.

[0082] Specifically, mock tampering rules are exception injection rules used to instruct the generation of tampering anomaly data and to tamper with the target packet information to generate a target network packet carrying tampering anomaly data. Specifically, the historical interface log data of the microservice under test can be historical log data pre-stored by the platform and associated with the called interface corresponding to the aforementioned interface log data, such as some or all of the past log data of the called interface, or it can be historical log data related to the called interface generated by the microservice under test during the execution of other system use cases.

[0083] Specifically, based on at least one of the following: the identifier information of the microservice under test, the interface parameter information of the called interface, or the task type information, historical interface log data of the microservice under test can be filtered from the pre-stored log data in the system (such as a trace platform). Once the historical interface log data is obtained, information identification and matching can be performed between the target message information and the historical interface log data. Similar identification and matching methods to those in S207 can be used, such as regular expression matching or other field matching methods. Then, associated message information corresponding to the target message information can be filtered from the historical interface log data. This associated message information can be message fields with the same business meaning as the target message information. For example, the field can be in key-value format. The same message fields in the associated message information and the target message information refer to the same key, while the field values ​​are different.

[0084] Specifically, when both the target message information and the associated message information are message fields, the field values ​​of the associated message information are determined, and these values ​​differ from those of the target message information. The field values ​​of the associated message information are then treated as tampering anomaly data. In subsequent anomaly injection processes, the field values ​​of the target message information in the target network message can be modified to these tampering anomaly data, i.e., modified to the field values ​​of the associated message information. For example, in a scenario where the target business service's business type is an account activity business, the aforementioned amount field "total_fee" has a total amount value, such as 100. This total amount value can be modified to the total amount value of the associated message field, such as changing it to 200.

[0085] In this way, by using mock tampering rules, the message fields that need to be tampered with and the required tampered values ​​are determined. A correlation is established between the tampered anomaly data and the target message information (or the corresponding target network message) to automatically generate network anomaly test cases that include system test cases and tampered anomaly data. Furthermore, using field values ​​that actually exist in the system as tampered anomaly data, such as existing monetary values, existing account numbers, or order numbers (e.g., order IDs marked as existing in the system), increases the authenticity of the tampered anomaly data, thereby improving the accuracy of related network anomaly tests.

[0086] The mock tampering rules include request tampering rules and response tampering rules. Correspondingly, the tampering exception data can include request tampering exception data and response tampering exception data. Request tampering exception data is used to tamper with field values ​​in the target request message corresponding to the target message information during the execution of network anomaly test cases. Response tampering exception data is used to tamper with field values ​​in the target response message corresponding to the target message information during the execution of network anomaly test cases.

[0087] In some embodiments, the target anomaly injection rule includes a mock transmission anomaly injection rule, and the target anomaly data includes transmission anomaly data. Accordingly, S2091 may include: when the target anomaly injection rule is a mock transmission anomaly injection rule, constructing transmission anomaly data corresponding to the target packet information based on the mock transmission anomaly injection rule. The transmission anomaly is used to indicate the transmission method of the target network packet corresponding to the target packet information during the execution of the network anomaly test case.

[0088] Specifically, mock transmission anomaly injection rules are used to instruct the generation of transmission anomaly data and modify the transmission parameters of the target network packet corresponding to the target packet information, thereby modifying the transmission mode of the target network packet. Specifically, mock transmission anomaly injection rules can include reentry rules and response delay rules. Correspondingly, transmission anomaly data can include reentry anomaly data and delay anomaly data, etc. For example, reentry anomaly data can specifically include the number of reentries of the target request packet and establish a correlation with the target request packet; delay anomaly data can include the delay duration of the target response packet and establish a correlation with the target response packet. For instance, through network anomaly test cases carrying reentry anomaly data, it is possible to instruct the upstream microservice under test to repeatedly send the target request packet to the microservice under test based on the number of reentries; through network anomaly test cases carrying delay anomaly data, it is possible to instruct the downstream microservice under test to delay the feedback of the target response packet to the microservice under test based on the delay duration.

[0089] S211: In a microservice system, network anomaly test cases are executed through the service call chain to obtain the corresponding anomaly test results.

[0090] In this embodiment of the application, network anomaly test cases are executed through the service call chain. When the service call chain corresponds to multiple system test cases, and thus to multiple network anomaly test cases, each network anomaly test case can be executed sequentially to obtain its respective anomaly test result.

[0091] In practical applications, network anomaly test cases refer to normally executed system test cases plus the target anomaly data to be injected. Accordingly, S211 may include the following steps.

[0092] S2111: Re-execute the system test case through the service call chain. During the execution of the system test case, the network packets of the microservice under test in the service call chain, as well as the network packets of the called microservice adjacent to the microservice under test, are forwarded through the preset mock module.

[0093] S2112: During the execution of system test cases, the preset mock module is used to perform anomaly injection processing on the target network packets corresponding to the target packet information to obtain the anomaly test results.

[0094] In some embodiments, a correlation is established between system use cases and target anomaly data to form network anomaly test cases, and a correlation is also established between target anomaly injection rules and network anomaly test cases. The corresponding system use cases are replayed sequentially through the service call chain, and the target anomaly data is injected into the replay process using the associated target anomaly injection rules. Specifically, communication messages between the microservice under test and its upstream and downstream called microservices must be received and sent through a preset mock module. In some cases, the preset mock module only forwards communication messages between the microservice under test and its upstream and downstream called microservices; in other cases, communication messages between adjacent called microservices in the service call chain must be forwarded through the preset mock module, meaning that every request or response sent from microservice A to microservice B will first pass through the preset mock module. This preset mock module can run in the aforementioned mock app and depends on the external capabilities of the mock platform.

[0095] Specifically, when the target anomaly injection rule is a mock tampering rule, based on the mock tampering rule, the target packet information in the target network packets passing through the microservice under test is tampered with according to the tampered anomaly data to achieve anomaly injection. Specifically, the values ​​of the target packet information can be modified to the tampered anomaly data. This target packet information can be a target packet field in a request or response string, and the tampered anomaly data can be historical real values ​​existing in the system, such as the aforementioned "total_fee" and "amount," etc., whose field values ​​are modified to the "total_fee" and "amount" values ​​existing in historical interface log data.

[0096] Specifically, when the mock tampering rule is a request tampering rule, the preset mock module receives target request messages sent from the upstream microservice being modulated to the microservice under test, parses the request string, finds the target message field to be tampered with, modifies its value to the value corresponding to the tampering anomaly data, and concatenates them into a new request string to generate a target request message carrying the tampering anomaly data. This message is then sent to the microservice under test. The preset mock module also sends the target response message from the microservice under test in response to the anomaly in the target request message back to the upstream microservice being modulated. Alternatively, the preset mock module can also receive target request messages sent from the microservice under test to the downstream microservice being modulated, parse the request string, find the target message field to be tampered with, modify its value to the value corresponding to the tampering anomaly data, and concatenate them into a new request string to generate a target request message carrying the tampering anomaly data. This message is then sent to the downstream microservice being modulated. The preset mock module also sends the target response message from the downstream microservice being modulated in response to the anomaly in the target request message back to the microservice under test.

[0097] Specifically, when the mock tampering rule is a response tampering rule, a preset mock module receives the target response message sent by the downstream microservice being tuned to the microservice under test, parses the response string, finds the target message field to be tampered with, modifies its value to the value corresponding to the tampered abnormal data, and concatenates it into a new response string to generate a target response message carrying the tampered abnormal data, which is then sent to the microservice under test. Alternatively, the preset mock module can also receive the target response message sent by the microservice under test to the downstream microservice being tuned, parse the response string, find the target message field to be tampered with, modify its value to the value corresponding to the tampered abnormal data, and concatenate it into a new response string to generate a target response message carrying the tampered abnormal data, which is then sent to the downstream microservice being tuned.

[0098] In scenarios involving account transactions or payments, the target message fields that can be tampered with may include the amount field, transaction object data field, payment order number field, and signature field. The corresponding tampered abnormal data may include the payment amount, transaction object data, payment order number, and signature information.

[0099] The above method enables the execution of network anomaly test cases carrying tampered and abnormal data, thereby obtaining the corresponding anomaly test results.

[0100] Specifically, when the target anomaly injection rule is a mock transmission anomaly injection rule, the transmission parameters of the target network packets passing through the microservice under test are tampered with according to the mock transmission anomaly injection rule to achieve anomaly injection.

[0101] Specifically, when the mock transmission exception injection rule is a reentrancy rule, the transmission exception data includes reentrancy exception data. The preset mock module receives target request messages sent by the upstream modulated microservice to the microservice under test, and modifies the number of times the target request messages are sent based on the reentrancy exception data, for example, twice. This means the upstream modulated microservice sends the target request messages to the microservice under test twice. The preset mock module then sends the target response messages from the microservice under test in response to these repeatedly sent target request messages back to the upstream modulated microservice. Alternatively, the preset mock module receives target request messages sent by the microservice under test to the downstream modulated microservice, and modifies the number of times the target request messages are sent based on the reentrancy exception data, for example, twice. This means the microservice under test sends the target request messages to the downstream modulated microservice twice. The preset mock module then sends the target response messages from the downstream modulated microservice in response to these repeatedly sent target request messages back to the microservice under test.

[0102] Specifically, when the mock transmission anomaly injection rule is a response delay rule, the transmission anomaly data includes delay anomaly data. After receiving the target response message from the microservice under test responding to the request message sent by the upstream microservice under test through the preset mock module, the target response message is sent back to the upstream microservice under test after a preset delay based on the delay anomaly data. The response result of the upstream microservice under test to the target response message of the delay anomaly is then received through the preset mock module. Alternatively, after receiving the target response message from the downstream microservice under test responding to the request message sent by the microservice under test through the preset mock module, the target response message is sent back to the microservice under test after a preset delay based on the delay anomaly data. The response result of the microservice under test to the target response message of the delay anomaly is then received through the preset mock module.

[0103] In this embodiment of the application, after S211, the method may further include a test result assertion step S213: based on the first assertion information corresponding to the system test case and the second assertion information corresponding to the target anomaly injection rule, assertion analysis is performed on the anomaly test result to obtain the anomaly test assertion result corresponding to the network anomaly test case.

[0104] In practical applications, the first assertion information is correlated with system use cases. In some cases, system use cases may include the first assertion information corresponding to a request sent to the microservice system, where the first assertion information is the result assertion corresponding to the request. The use case assertion corresponding to the first assertion information can include various types, including but not limited to validating return values, validating key fields in the return string, or validating the database, etc. The second assertion information is correlated with the target exception injection rule. The assertion corresponding to the second assertion information may include validating error codes or key fields in the return string, etc.

[0105] In practical applications, anomaly test results include at least one of the following: system test case execution results and anomaly feedback information. System test case execution results refer to the test case results obtained by replaying the service call chain. Anomaly feedback information refers to the information returned regarding the target anomaly injection data after injection processing during system test case replay. For example, anomaly feedback information regarding tampered anomaly data could be the microservice's response to a received tampered target request or response message, or the microservice's response to a received re-entrant target request or delayed target response message.

[0106] Accordingly, S213 may include the following steps.

[0107] S2131: When the abnormal test results include the system test case execution results, the execution status of the system test case execution results is verified based on the first assertion information to obtain the execution status results of the system test cases.

[0108] In practical applications, the execution status of a system use case can include success and failure. Successful execution means that the system use case execution result is included in the assertions in the first assertion information, while failure means that the system use case execution result is not included in the assertions in the first assertion information.

[0109] S2132: If the abnormal test results include abnormal feedback information, perform feedback information verification on the abnormal feedback information based on the second assertion information to obtain the abnormal verification result corresponding to the network abnormal test case.

[0110] In practical applications, abnormal feedback information can include, but is not limited to, return strings or return error codes. The assertions corresponding to the second assertion information can include verifying error codes or key fields of the return string. When abnormal feedback information exists, such as the request error code returned for a tampered target request message, the feedback information is verified based on the corresponding assertion. It is determined whether the returned request error code matches the verification error code corresponding to the request tampering rule. If they match, the abnormal verification result is a match with the second assertion information; that is, it is within the assertion. If the returned request error code is not within the preset error code range, the abnormal verification result is a mismatch with the second assertion information, i.e., it is not within the assertion. Specifically, the verification error code refers to the possible error codes preset according to the type of abnormal injection rule. For example, the verification error code for a mock reentrancy rule is 1, the verification error code for a mock delay rule is 2, and the verification error code for a mock tampering abnormality is 3.

[0111] In the aforementioned transaction types or payment scenarios, the second assertion information can be used for verification to prevent identity fraud, information tampering, duplicate deductions, and ensure data consistency among multiple parties.

[0112] In practical applications, when the mock is hit, the generation of the target abnormal data is triggered, and the injection processing of the target abnormal data is triggered during the execution of the system test case. The abnormal test assertion result of the network abnormal test case can be judged by combining the execution status result and the abnormal feedback information.

[0113] S2133: If the execution status result is execution failure, and the exception verification result is that the exception feedback information matches the second assertion information, then the exception test assertion result is determined to meet the test expectation.

[0114] Specifically, if the system test case fails to execute and the exception feedback information matches the second assertion information (e.g., the error code matches the corresponding verification error code or is within the preset range), then the exception test assertion result is in line with test expectations. If the system test case fails to execute and the exception feedback information does not match the second assertion information (e.g., the error code does not match the corresponding verification error code or is not within the preset range), then the exception test assertion result is indicative of a risk. If the system test case executes successfully, then the exception test assertion result does not meet expectations.

[0115] In some cases, the mock may not be hit, meaning the generation of the target exception data may not be triggered, or the target exception data may be generated but the injection processing of the target exception data may not be triggered during the execution of the system test case, such as not matching the target message information or not recognizing the business meaning. Accordingly, in the case of a mock miss, only the system test case execution result is obtained. If the system test case executes successfully, it means the exception test assertion result meets expectations. If the system test case executes unsuccessfully, it means the exception test assertion result does not meet expectations. Specifically, if the exception test assertion result does not meet expectations or poses a risk, a result alert should be issued.

[0116] In one embodiment, please refer to Figure 8Taking the transaction processing scenario as an example, the network anomaly testing process is as follows: First, the system test cases are run in batches, such as a full batch run of BTV; then, the service call chain is obtained, i.e., trace data is obtained from the trace platform; it is determined whether the transaction processing interface exists in the service call chain, i.e., whether the target business service exists; if so, it is determined whether the microservice to be tested exists; if so, the interface log data of the microservice to be tested is analyzed, and network anomaly test cases are generated; mock is set up, and the capabilities of the mock platform are called to associate the target anomaly data and the target anomaly injection rules; the system test cases are replayed, and the target anomaly data is injected using the preset mock module during the replay process to obtain the test results; the test results are analyzed based on the preset assertion information to obtain the anomaly test assertion results, and they are summarized and analyzed to obtain the anomaly test report.

[0117] Based on the above solution, this application can automatically select successfully executed test cases for a specific object or component under test in a microservice system, based on the execution status of existing system test cases, and use these test cases as base test cases to derive network anomaly test cases. This avoids repetitive test case writing and improves test case generation efficiency. Furthermore, it can analyze the types and business meanings of interface parameter fields based on existing historical interface logs to construct corresponding abnormal data for each selected system test case, and automatically build abnormal test scenarios through mocking to automatically generate abnormal test cases. During system test case replay, the target abnormal data is automatically injected, and the test results are automatically asserted. This process requires no manual intervention, greatly reducing labor costs and improving the level of testability.

[0118] This application also provides a network anomaly testing device 800, such as... Figure 9 As shown, Figure 9 The diagram shows a structural schematic of a network anomaly testing device provided in an embodiment of this application. The device may include the following modules.

[0119] Call chain acquisition module 10: used to acquire the service call chain corresponding to the execution process of system test cases in the microservice system; system test cases are test cases used to test the business functions of the microservice system.

[0120] Service type identification module 20: It is used to identify the service type of each called microservice based on the interface parameters of each called microservice in the service call chain.

[0121] Interface log data acquisition module 30: When it is identified that each called microservice may include the target business service and the microservice under test, the interface log data generated by the microservice under test during the execution of the system test case is acquired.

[0122] Business meaning identification module 40: Used to identify the business meaning of the interface log data of the microservice to be tested, and obtain the corresponding target business meaning information.

[0123] Injection Exception Generation Module 50: Based on the target exception injection rules corresponding to the target business meaning information, it performs injection exception generation processing on system test cases to obtain the corresponding network exception test cases.

[0124] Anomaly Testing Module 60: Used in microservice systems to execute network anomaly test cases through service call chains and obtain corresponding anomaly test results.

[0125] In some embodiments, the interface log data includes message information of network packets received or sent by the microservice under test during the execution of system use cases; the target business meaning information includes target message information and the target business meaning corresponding to the target message information. The business meaning identification module 40 can be specifically used to: identify the business meaning of the interface log data based on the correspondence between message information and business meaning in the target knowledge base, thereby obtaining the target message information and the target business meaning corresponding to the target message information in the interface log data.

[0126] In some embodiments, the injection exception generation module 50 may include the following sub-modules.

[0127] The abnormal data construction submodule is used to construct the target abnormal data corresponding to the target message information based on the target abnormal injection rules.

[0128] Test case generation submodule: Used to generate network anomaly test cases based on target anomaly data and system test cases.

[0129] In some embodiments, the anomaly testing module 60 may include the following sub-modules.

[0130] System test case execution submodule: Used to re-execute system test cases through the service call chain. During the execution of system test cases, network packets of the microservice under test in the service call chain, as well as network packets of the called microservice adjacent to the microservice under test, are forwarded through the preset mock module.

[0131] The exception injection handling submodule is used to perform exception injection processing on the target network packets corresponding to the target packet information during the execution of system test cases, using a preset mock module, to obtain exception test results.

[0132] In some embodiments, the target anomaly injection rule may include a mock tampering rule, and the target anomaly data may include tampered anomaly data. The anomaly data construction unit may include the following units.

[0133] Associated message information acquisition unit: When the target exception injection rule is a mock tampering rule, it is used to obtain the associated message information corresponding to the target message information from the historical interface log data of the microservice under test.

[0134] Tampering Anomaly Construction Unit: Used to construct tampering anomaly data corresponding to the target message information based on mock tampering rules and associated message information.

[0135] In some embodiments, the tampering exception construction unit can be specifically used to: obtain the historical field value corresponding to the target tampered field from the historical log file of the microservice system, wherein the historical field value is different from the field value of the target tampered field; and use the historical field value corresponding to the target tampered field as tampering exception data.

[0136] In some embodiments, the target anomaly injection rule may include a mock transmission anomaly injection rule, and the target anomaly data may include transmission anomaly data. The anomaly data construction submodule may specifically be used to: when the target anomaly injection rule is a mock transmission anomaly injection rule, construct transmission anomaly data corresponding to the target packet information based on the mock transmission anomaly injection rule; the transmission anomaly is used to indicate the transmission method of the target network packet corresponding to the target packet information during the execution of the network anomaly test case.

[0137] In some embodiments, the apparatus may further include a test assertion module: after executing network anomaly test cases through the service call chain and obtaining the corresponding anomaly test results, it performs assertion analysis on the anomaly test results based on the first assertion information corresponding to the system test cases and the second assertion information corresponding to the target anomaly injection rule, and obtains the anomaly test assertion results corresponding to the network anomaly test cases.

[0138] In some embodiments, abnormal test results may include at least one of system test case execution results and abnormal feedback information. The test assertion module may include the following sub-modules.

[0139] The execution status verification submodule is used to verify the execution status of the system test case execution results based on the first assertion information when the abnormal test results may include the system test case execution results, so as to obtain the execution status results of the system test cases.

[0140] Feedback Information Verification Submodule: When the abnormal test results include abnormal feedback information, it verifies the abnormal feedback information based on the second assertion information to obtain the abnormal verification result corresponding to the network abnormal test case.

[0141] The assertion result determination submodule is used to determine the abnormal test assertion result as meeting the test expectations if the execution status result is execution, failure, and the exception verification result is that the exception feedback information matches the second assertion information.

[0142] In some embodiments, the apparatus may further include an anomaly injection rule determination module: configured to determine the target anomaly injection rule corresponding to the target business meaning information based on the correspondence between message information in the target knowledge base and the target anomaly injection rule, or the correspondence between business meaning and the target anomaly injection rule, before performing injection anomaly generation processing on system use cases based on the target anomaly injection rule corresponding to the target anomaly meaning information to obtain the corresponding network anomaly test cases.

[0143] It should be noted that the above-described device embodiments and method embodiments are based on the same implementation methods.

[0144] This application provides a network anomaly testing device. The identification device can be a terminal or a server. The network anomaly testing device includes a processor and a memory. The memory stores at least one instruction or at least one program. The at least one instruction or at least one program is loaded and executed by the processor to implement the network anomaly testing method provided in the above method embodiments.

[0145] Memory is used to store software programs and modules. The processor executes these stored software programs and modules to perform various functional applications and data processing. Memory can primarily consist of a program storage area and a data storage area. The program storage area stores the operating system, application programs required for functionality, etc.; the data storage area stores data created based on device usage, etc. Furthermore, memory can include high-speed random access memory (RAM) and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory can also include a memory controller to provide the processor with access to the memory.

[0146] The methods and embodiments provided in this application can be executed in electronic devices such as mobile terminals, computer terminals, servers, or similar computing devices. Figure 10 This is a hardware structure block diagram of an electronic device for a network anomaly testing method provided in an embodiment of this application. For example... Figure 10As shown, the electronic device 900 can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) 910 (CPUs 910 may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), a memory 930 for storing data, and one or more storage media 920 (e.g., one or more mass storage devices) for storing application programs 923 or data 922. The memory 930 and storage media 920 may be temporary or persistent storage. The program stored in the storage media 920 may include one or more modules, each module may include a series of instruction operations on the electronic device. Furthermore, the CPU 910 may be configured to communicate with the storage media 920 and execute the series of instruction operations in the storage media 920 on the electronic device 900. Electronic device 900 may also include one or more power supplies 960, one or more wired or wireless network interfaces 950, one or more input / output interfaces 940, and / or one or more operating systems 921, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0147] The input / output interface 940 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 900. In one example, the input / output interface 940 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 940 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0148] Those skilled in the art will understand that Figure 10 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device 900 may also include... Figure 10 The more or fewer components shown, or having the same Figure 10 The different configurations shown.

[0149] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a network anomaly testing method in the method embodiments. The at least one instruction or the at least one program is loaded and executed by the processor to implement the network anomaly testing method provided in the above method embodiments.

[0150] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0151] According to one aspect of this application, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various alternative implementations described above.

[0152] As can be seen from the embodiments of the network anomaly testing method, apparatus, device, server, terminal storage medium, and program product provided in this application, this application obtains the service call chain corresponding to the execution process of system test cases in a microservice system; the system test cases are test cases used to test the business functions of the microservice system; based on the interface parameters of each called microservice in the service call chain, the service type of each called microservice is identified; when it is identified that each called microservice includes a target business service and a microservice under test, the interface log data generated by the microservice under test during the execution of the system test cases is obtained; the business meaning of the interface log data of the microservice under test is identified to obtain the corresponding target business meaning information; based on the target anomaly injection rules corresponding to the target business meaning information, injection anomaly generation processing is performed on the system test cases to obtain the corresponding network anomaly test cases; in the microservice system, the network anomaly test cases are executed through the service call chain to obtain the corresponding anomaly test results. This application can utilize existing functional test cases to automatically generate anomaly data and corresponding anomaly test cases through service type identification and business meaning identification, without rewriting basic test cases or manually combining anomaly data, greatly improving the efficiency and utilization of test case generation. Meanwhile, by using preset exception injection rules and system test case replay for exception testing, the system can inherit the test result analysis capabilities obtained during functional testing, thereby reducing the complexity of exception test result analysis.

[0153] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0154] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0155] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0156] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for testing network anomalies, characterized in that, The method includes: Obtain the service call chain corresponding to the execution process of the system test cases in the microservice system; the system test cases are test cases used to test the business functions of the microservice system. Based on the interface parameters of each called microservice in the service call chain, the service type of each called microservice is identified. If it is identified that each of the called microservices includes a target business service and a microservice under test, obtain the interface log data generated by the microservice under test during the execution of the system use case; The interface log data of the microservice under test is subjected to business meaning identification to obtain the corresponding target business meaning information; the target business meaning information includes target message information. Based on the target anomaly injection rules corresponding to the target business meaning information, injection anomaly generation processing is performed on the system use cases to obtain corresponding network anomaly test cases. The network anomaly test cases are generated based on the target anomaly data corresponding to the target packet information and the system use cases. The system use case is re-executed through the service call chain. During the execution of the system use case, the network packets of the microservice under test and the network packets of the called microservice adjacent to the microservice under test in the service call chain are forwarded through the preset mock module. During the execution of the system test case, the preset mock module is used to perform anomaly injection processing on the target network packet corresponding to the target packet information to obtain the anomaly test result.

2. The method according to claim 1, characterized in that, The interface log data includes message information of network packets received or sent by the microservice under test during the execution of the system use case; the target service meaning information includes the target service meaning corresponding to the target message information; The step of identifying the business meaning of the interface log data of the microservice under test to obtain the corresponding target business meaning information includes: Based on the correspondence between message information and business meaning in the target knowledge base, the business meaning of the interface log data is identified to obtain the target message information in the interface log data and the target business meaning corresponding to the target message information.

3. The method according to claim 2, characterized in that, The injection of target anomalies based on the target business meaning information, and the generation of injection anomalies for the system test cases, yields the corresponding network anomaly test cases, including: Based on the target anomaly injection rules, construct the target anomaly data corresponding to the target message information; The network anomaly test cases are generated based on the target anomaly data and the system test cases.

4. The method according to claim 3, characterized in that, The target anomaly injection rule includes mock tampering rules; the target anomaly data includes tampered anomaly data; the construction of the target anomaly data corresponding to the target message information based on the target anomaly injection rule includes: When the target anomaly injection rule is a mock tampering rule, the associated message information corresponding to the target message information is obtained from the historical interface log data of the microservice under test; Based on the mock tampering rules and the associated message information, the tampering anomaly data corresponding to the target message information is constructed.

5. The method according to claim 3, characterized in that, The target anomaly injection rule includes a mock transmission anomaly injection rule, and the target anomaly data includes transmission anomaly data; the construction of the target anomaly data corresponding to the target packet information based on the target anomaly injection rule includes: When the target anomaly injection rule is a mock transmission anomaly injection rule, transmission anomaly data corresponding to the target packet information is constructed based on the mock transmission anomaly injection rule; the transmission anomaly is used to indicate the transmission method of the target network packet corresponding to the target packet information during the execution of the network anomaly test case.

6. The method according to any one of claims 1-5, characterized in that, After obtaining the abnormal test results, the method further includes: Based on the first assertion information corresponding to the system use case and the second assertion information corresponding to the target anomaly injection rule, assertion analysis is performed on the anomaly test results to obtain the anomaly test assertion results corresponding to the network anomaly test cases.

7. The method according to claim 6, characterized in that, The abnormal test results include at least one of the system test case execution results and abnormal feedback information; the assertion analysis of the abnormal test results based on the first assertion information corresponding to the system test case and the second assertion information corresponding to the target abnormal injection rule, to obtain the abnormal test assertion results corresponding to the network abnormal test case, includes: If the abnormal test result includes the system test case execution result, the execution status of the system test case execution result is verified based on the first assertion information to obtain the execution status result of the system test case; If the abnormal test result includes the abnormal feedback information, the abnormal feedback information is verified based on the second assertion information to obtain the abnormal verification result corresponding to the network abnormal test case. If the execution status result is execution failure, and the exception verification result is that the exception feedback information matches the second assertion information, then the exception test assertion result is determined to meet the test expectation.

8. The method according to any one of claims 1-5, characterized in that, Before generating network anomaly test cases by performing injection anomaly generation processing on the system test cases based on the target anomaly injection rules corresponding to the target business meaning information, the method further includes: Based on the correspondence between message information and target anomaly injection rules in the target knowledge base, or the correspondence between business meaning and target anomaly injection rules, the target anomaly injection rules corresponding to the target business meaning information are determined.

9. A network anomaly testing device, characterized in that, The device includes: Call chain acquisition module: used to acquire the service call chain corresponding to the execution process of system test cases in the microservice system; the system test cases are test cases used to test the business functions of the microservice system; Service type identification module: used to identify the service type of each called microservice based on the interface parameters of each called microservice in the service call chain; Interface log data acquisition module: used to acquire interface log data generated by the microservice under test during the execution of the system use case when it is identified that each called microservice includes a target business service and a microservice under test; Business meaning identification module: used to identify the business meaning of the interface log data of the microservice under test, and obtain the corresponding target business meaning information; the target business meaning information includes target message information; Injection Anomaly Generation Module: Used to perform injection anomaly generation processing on the system use cases based on the target anomaly injection rules corresponding to the target business meaning information, and to obtain the corresponding network anomaly test cases. The network anomaly test cases are generated based on the target anomaly data corresponding to the target packet information and the system use cases. Anomaly testing module: used to re-execute the system test case through the service call chain. During the execution of the system test case, the network packets of the microservice under test and the network packets of the called microservice adjacent to the microservice under test in the service call chain are forwarded through a preset mock module. Also, during the execution of the system test case, the preset mock module is used to perform anomaly injection processing on the target network packets corresponding to the target packet information to obtain anomaly test results.

10. The apparatus according to claim 9, characterized in that, The interface log data includes message information of network packets received or sent by the microservice under test during the execution of the system use case; the target service meaning information includes the target service meaning corresponding to the target message information; The business meaning recognition module is specifically used for: Based on the correspondence between message information and business meaning in the target knowledge base, the business meaning of the interface log data is identified to obtain the target message information in the interface log data and the target business meaning corresponding to the target message information.

11. The apparatus according to claim 10, characterized in that, The injection anomaly generation module includes: Anomaly data construction submodule: used to construct target anomaly data corresponding to the target message information based on the target anomaly injection rules; Test case generation submodule: used to generate network anomaly test cases based on the target anomaly data and the system test cases.

12. The apparatus according to claim 11, characterized in that, The target anomaly injection rule includes mock tampering rules; the target anomaly data includes tampered anomaly data; the anomaly data construction unit includes: Associated message information acquisition unit: used to acquire associated message information corresponding to the target message information from the historical interface log data of the microservice under test when the target anomaly injection rule is a mock tampering rule; Tampering Anomaly Construction Unit: Used to construct tampering anomaly data corresponding to the target message information based on the mock tampering rules and the associated message information.

13. The apparatus according to claim 11, characterized in that, The target anomaly injection rule includes a mock transmission anomaly injection rule, and the target anomaly data includes transmission anomaly data; the anomaly data construction submodule is specifically used for: When the target anomaly injection rule is a mock transmission anomaly injection rule, transmission anomaly data corresponding to the target packet information is constructed based on the mock transmission anomaly injection rule. The transmission anomaly is used to indicate the transmission method of the target network packet corresponding to the target packet information during the execution of the network anomaly test case.

14. The apparatus according to any one of claims 9-13, characterized in that, The device also includes a test assertion module: This is used to perform assertion analysis on the abnormal test results after obtaining the abnormal test results, based on the first assertion information corresponding to the system test case and the second assertion information corresponding to the target abnormal injection rule, to obtain the abnormal test assertion results corresponding to the network abnormal test test cases.

15. The apparatus according to claim 14, characterized in that, The abnormal test results include at least one of the system test case execution results and abnormal feedback information; the test assertion module includes: Execution status verification submodule: used to perform execution status verification on the system test case execution result based on the first assertion information when the abnormal test result includes the system test case execution result, to obtain the execution status result of the system test case; Feedback information verification submodule: When the abnormal test result includes the abnormal feedback information, it performs feedback information verification on the abnormal feedback information based on the second assertion information to obtain the abnormal verification result corresponding to the network abnormal test case; Assertion Result Determination Submodule: If the execution status result is execution failure and the exception verification result is that the exception feedback information matches the second assertion information, determine that the exception test assertion result meets the test expectation.

16. The apparatus according to any one of claims 9-13, characterized in that, The device also includes an anomaly injection rule determination module: Before generating network anomaly test cases for the system test cases based on the target anomaly injection rule corresponding to the target business meaning information, this method determines the target anomaly injection rule corresponding to the target business meaning information based on the correspondence between message information and target anomaly injection rule in the target knowledge base, or the correspondence between business meaning and target anomaly injection rule.

17. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the network anomaly testing method as described in any one of claims 1-8.

18. A computer device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the network anomaly testing method as described in any one of claims 1-8.

19. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the network anomaly testing method as described in any one of claims 1-8.

Images