Test methods, apparatuses, devices, and media

CN117130893BActive Publication Date: 2026-07-24TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2022-05-19
Publication Date
2026-07-24

Smart Images

  • Figure CN117130893B_ABST
    Figure CN117130893B_ABST
Patent Text Reader

Abstract

The application discloses a test method, device, equipment and medium, relates to the computer technical field, and particularly relates to the software test technical field. The method comprises the following steps: acquiring test data of a first service instance of a test object; the test data of the first service instance carries a test environment identifier, and the test environment identifier is used for indicating a preset test environment of the test object; according to the test environment identifier, an actual test environment of the first service instance is determined, and the first service instance is tested based on the test data of the first service instance in the actual test environment; and if the test result of the first service instance in the actual test environment is failure, the first service instance is tested in an alternative test environment of the first service instance. The test flow interruption problem of the test object caused by the test failure of the service instance can be solved in the architecture for avoiding the repeated deployment of the service instance.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application generally relates to the field of computer technology, specifically to the field of software testing technology, and in particular to a testing method, apparatus, device, and medium. Background Technology

[0002] Before a network product (such as an application) is officially released, it typically requires service release testing. Because the current development model for network products involves collaborative development by multiple developers, multiple people may test service instances in the same test environment. This can result in different test versions of the service instances appearing within the same test environment, leading to instability in the test environment.

[0003] To address the aforementioned issues, a testing architecture is proposed. Specifically, a baseline environment with all service instances can be deployed. When adding a new testing environment, only the new version of the service instances needs to be deployed in the new environment, and the new testing environment can share the service instances in the baseline environment. However, when testing applications based on this architecture, the deployment characteristics of service instances under this architecture may lead to interruptions in the application testing process, severely impacting overall testing efficiency. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a testing method, apparatus, device and medium that can solve the problem of test process interruption caused by service instance test failure in an architecture that avoids repeated deployment of service instances.

[0005] In a first aspect, this application provides a testing method, which includes: obtaining test data of a first service instance of a test object; the test data of the first service instance carries a test environment identifier, the test environment identifier being used to indicate a preset test environment of the test object; determining the actual test environment of the first service instance based on the test environment identifier, and testing the first service instance in the actual test environment based on the test data of the first service instance; if the test result of the first service instance in the actual test environment is a failure, then testing the first service instance in an alternative test environment of the first service instance.

[0006] Secondly, this application provides a testing apparatus, comprising: an acquisition unit for acquiring test data of a first service instance of a test object; the test data carrying a test environment identifier, the test environment identifier indicating a preset test environment of the test object; a processing unit for determining the actual test environment of the first service instance based on the test environment identifier, and testing the first service instance in the actual test environment based on the test data of the first service instance; and a processing unit for testing the first service instance in an alternative test environment if the test result of the first service instance in the actual test environment is a failure.

[0007] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in embodiments of this application.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in embodiments of this application.

[0009] Fifthly, embodiments of this application provide a computer program product including instructions that, when executed, cause the method described in embodiments of this application to be performed.

[0010] The testing method, apparatus, equipment, and medium proposed in this application can be applied to a testing architecture that avoids duplicate deployment of service instances. When testing applications under this architecture, test management for a specific test object (e.g., an application) can be precisely managed down to each service instance of the test object. Specifically, test data for one service instance of the test object can be obtained, and the actual test environment of the service instance can be determined based on the test environment identifier carried in the test data. The test data of the service instance can then be routed to the actual test environment for testing. The test environment identifier can indicate a preset test environment for the test object, which can be the same as or different from the actual test environment of the service instance. The method provided in this application can route the test data of a service instance to the correct test environment using the test environment identifier in the test data, without being limited by the specific deployment form of the service instance in the architecture, thus ensuring a smooth testing process. While avoiding instability caused by deploying different versions of service instances in the same test environment using the above architecture, it also provides a flexible testing method for testing various test objects deployed based on this architecture. Furthermore, in the aforementioned architecture, if a service instance in the actual test environment of the test object fails to complete the test, not only will the test of that service instance be impossible to complete, but it will also affect the subsequent testing of other service instances. This means that the testing of the test object can only stop at that service instance. Therefore, the method provided in this application addresses the possibility of test instance failure by providing an alternative test environment for the service instance. The service instance is then tested in the alternative test environment, thus successfully completing the test for that service instance and avoiding the interruption of the test process due to the failure of that service instance, thereby ensuring the overall testing efficiency of the test object.

[0011] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0012] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0013] Figure 1 This is a schematic diagram of the structure of the test system provided in the embodiments of this application;

[0014] Figure 2 This is a schematic diagram of the structure of Istio provided in an embodiment of this application;

[0015] Figure 3 A flowchart illustrating the testing method provided in the embodiments of this application;

[0016] Figure 4a This is a schematic diagram of the structure of the test module provided in an embodiment of this application;

[0017] Figure 4b Another schematic diagram of the test module provided in the embodiments of this application;

[0018] Figure 5 Another schematic diagram of the testing method provided in the embodiments of this application;

[0019] Figure 6 Another flowchart illustrating the testing method provided in the embodiments of this application;

[0020] Figure 7 This is a schematic diagram illustrating the effect of the environment list interface provided in the embodiments of this application;

[0021] Figure 8 This is a schematic diagram illustrating the effect of the service interface provided in the embodiments of this application;

[0022] Figure 9 This is a schematic diagram illustrating the effect of the management and configuration information interface provided in the embodiments of this application;

[0023] Figure 10 This is a schematic diagram of the protocol conversion process provided in an embodiment of this application;

[0024] Figure 11 This is a schematic diagram of data transmission provided in an embodiment of this application;

[0025] Figure 12 This is a schematic diagram of the structure of the Envoy proxy provided in the embodiments of this application;

[0026] Figure 13 Another schematic diagram of the test apparatus provided in the embodiments of this application;

[0027] Figure 14 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0028] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0029] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] Because the same network product (i.e., the test object, such as an application) may have multiple test versions, the test environment becomes unstable. Furthermore, different test versions may have different code, leading to uncontrollable code versioning within the same test environment. A service instance deployment architecture has been proposed in this field. Under this architecture, service instances of the same application are not repeatedly deployed, which can alleviate the application environment instability problem to some extent. For example, when adding a new application environment, only the new version of the service instance needs to be deployed in the new environment, without having to repeatedly deploy all service instances of the application. However, currently, there is no solution for application testing based on this deployment architecture.

[0031] Based on this, embodiments of this application provide a testing method, apparatus, device, and medium capable of performing testing on a specific test object under the aforementioned deployment architecture. Specifically, the actual test environment of a service instance is determined based on the test environment identifier carried in the test data of that service instance, and the test data of that service instance is further routed to the actual test environment for testing. Furthermore, while utilizing the aforementioned deployment architecture to avoid instability caused by deploying different versions of service instances in the same test environment, it also provides a flexible testing method for testing various test objects deployed based on this architecture.

[0032] Figure 1 This is a schematic diagram of a testing system provided in an embodiment of this application. The testing method provided in this embodiment can be applied to this testing system. (Reference) Figure 1 The system includes one or more clients 101 (e.g. Figure 1 The client devices 101a, 101b, and 101c are shown in the diagram, as well as the test device 102. It should be noted that, although... Figure 1 Only three clients, 101a, 101b, and 101c, are depicted, but those skilled in the art will understand that this application can support any number of clients.

[0033] It is understood that one or more clients 101 and the test device 102 may be deployed on the same computer device or on different computer devices; similarly, each client 101 in one or more clients 101 may be deployed on the same computer device or on different computer devices, and this application embodiment does not limit this.

[0034] Optionally, client 101 may include various types of computer devices, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, etc. These computer devices can run various types and versions of software applications and operating systems, such as Microsoft Windows, Apple iOS, UNIX-like operating systems, Linux or Linux-like operating systems (such as Google Chrome OS); or include various mobile operating systems, such as Microsoft Windows Mobile OS, iOS, Windows Phone, and Android. The computer devices are capable of executing various applications, such as various Internet-related applications, communication applications (such as email applications), short message service applications, and can use various communication protocols.

[0035] In one possible implementation, the test device 102 may include an access node 1021 and a test module 1022. The access node 1021 can be understood as an application programming interface (API) gateway or a software development kit (SDK) entry point.

[0036] For example, the testing device 102 can acquire traffic data generated by the client 101 of the test object and perform tests on the test object based on the traffic data generated by the client 101. The test object can be an application, and the client 101 can be a client of that application. Specifically, the access node 1021 can provide an interface for interaction between the client 101 and the testing module 1022. The access node 1021 can intercept the traffic data generated by the client 101 and can also perform traffic coloring on the traffic data to obtain test data for the test object. Then, the test data is routed to the test environment of the testing module 1022, where the test object is tested based on the test data.

[0037] It is understood that the test device 102 in this application embodiment is built on a cloud container management platform (such as Tencent Cloud Container Service (Tencent Kubernetes Engine, TKE)) combined with Istio. The combination method is to deploy service instances of various test environments in the cloud container management platform and use Istio to manage and implement the calls and communication between the service instances deployed in the cloud container management platform.

[0038] Specifically, the cloud container management platform provides management functions for services (i.e., service instances or microservices) and containers within the test environment of test module 1022. Service management primarily involves: 1) service compilation and packaging capabilities; 2) service image building, incremental updates, querying, and deployment capabilities; 3) service performance control, deployment strategies, status monitoring, configuration analysis, and management capabilities; and 4) service discovery capabilities. Container management primarily involves: 1) quota management and resource scheduling strategies for service-level containers; 2) elasticity capabilities, scaling up and down, and failover strategies and capabilities for service-level containers; and 3) image building and deployment capabilities.

[0039] Furthermore, refer to Figure 2 For traffic data interception and tampering, Istio can be used as the basic technical framework for traffic coloring. Istio is an open-source service mesh that controls how data is shared between microservices (i.e., service instances). Istio's architecture consists of two parts: the data plane and the control plane. The data plane is composed of a set of Sidecar proxies (i.e., proxy nodes Envoy or proxies) that appear in pairs with service instances. Its main function is to take over the incoming and outgoing traffic of service instances, and to pass and control all network communication between service instances and the Mixer component. Specifically, by deploying Envoy in the test environment, it routes test requests from service instances to other proxy nodes or receives test requests routed from other proxy nodes. These proxy nodes together form a network mesh that can intercept network communication between services. The control plane processes the control flow during request processing, and mainly includes Pilot, Mixer, and Istio-auth for service identity and security. Pilot is a management system that provides intelligent routing and resilience features, enabling service discovery, routing rules, and the discovery and configuration of proxy nodes (disicovery & data to envoys). Mixer is an adapter that integrates various policies and backend data acquisition or telemetry systems, enabling policy checks and telemetry, thus achieving isolation and convergence between the frontend proxy and the backend system. Istio-auth provides verifiable identities and protection services for services in the mesh, one function of which is to provide Transport Layer Security (TLS) authentication for the proxy. TLS stands for Transport Layer Security, and the cache is used to store the input signatures and check results.

[0040] In addition, for Figure 2 The statement "traffic is transparently intercepted and proxied, App is unaware of Envoy's presence" can be understood as traffic being transparently intercepted and proxied; the application service is unaware of the proxy node's existence. This represents the relationship between the proxy node and the application service (i.e., service instance, such as service A). The proxy node's interception and proxying of the application service can be achieved through the network firewall IPtable. Specifically, it obtains the application service's IP address and port through the IP table and intercepts and proxies the application service's traffic based on its IP address and port. The proxy node primarily handles communication between application services; therefore, it can be understood as a communication proxy. Here, IP stands for Internet Protocol.

[0041] Specifically, the embodiments of this application utilize Istio in conjunction with a cloud container management platform to build the test environment in test device 102. Through rich routing rules, retries, failover, and fault injection, fine-grained control over traffic data can be achieved. Istio enables traffic coloring processing of the traffic data, resulting in test data carrying test environment identifiers. Therefore, under the service instance deployment architecture, the embodiments of this application can route the test data of service instances to the correct test environment using the test environment identifiers in the test data, without being limited by the specific deployment form of the service instances in the deployment architecture, thus ensuring the smooth progress of the testing process.

[0042] The following will combine Figure 1 and Figure 2 The technical solutions of this application and how they solve the aforementioned technical problems will be described in detail with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0043] like Figure 3 As shown in the embodiments of this application, a testing method is provided, which can be applied to... Figure 1 The test apparatus 102 shown herein, the method specifically includes the following steps:

[0044] 201. Obtain the test data of the first service instance of the test object; the test data of the first service instance carries a test environment identifier, which is used to indicate the preset test environment of the test object.

[0045] The test data for the first service instance refers to the traffic data used to test the first service instance, which can also be understood as the input data used when testing the first service instance.

[0046] Optionally, the test object can be one version of the same application, or one version of a function within the application. The application can be, for example, a shopping application, a web browser application, a search application, an instant messaging tool, an email client, or a social media platform. This application does not limit the specific category of the client application.

[0047] Understandably, the default test environment is one that is intended to test all service instances corresponding to the test object.

[0048] In one implementation, the test environment identifier is used to characterize an independent operating environment provided by the testing device, in which the test object can be tested; it can also be called the test environment ID (identity document). The test environment identifier can be generated based on the user ID or based on environment information. The environment information is used to characterize the service instance version information within the test environment.

[0049] Specifically, one test environment identifier corresponds to one test object, and different environment identifiers correspond to different test objects. The test environment identifier can be numbers, letters, strings, etc., such as 1, 2, a, ert, etc. The application's functionality can be a newly developed feature or an upgraded version of an existing feature. For example, for a social chat application, the functionality could be requirements for expanding contacts, group messaging, message identification, etc.

[0050] As an example, the test data for the first service instance is related to the order in which it is called within the test object. Specifically, if the first service instance is the first service instance tested in the test environment, then its test data can be obtained based on the client traffic data of the test object. If the first service instance is not the first service instance tested in the test environment, and its operation depends on the test results of the previous service instance, then its test data can be obtained based on the test results of the previous service instance it depends on.

[0051] 202. Based on the test environment identifier, determine the actual test environment of the first service instance, and test the first service instance in the actual test environment based on the test data of the first service instance.

[0052] In this embodiment, when a first service instance exists in the preset test environment, the preset test environment is the actual test environment; when the first service instance does not exist in the preset test environment, the actual test environment is another test environment corresponding to the preset test environment. The other test environment corresponds to the same application or the same function of that application as the preset test environment. In this case, although the first service instance is not deployed in the preset test environment, the actual test environment grants access to the test object for this test, allowing testing of the first service instance of the test object in the actual test environment.

[0053] Specifically, based on a preset routing strategy, all test environments can be matched using test environment identifiers to determine the actual test environment of a service instance (such as the first service instance).

[0054] Specifically, the routing strategy can be a matching strategy based on certain priorities. For example, the priority of a preset test environment + service instance is higher than that of a default test environment + service instance; where preset test environment + service instance means that if the required service instance exists in the preset test environment, then the service instance in the preset test environment will be selected; and secondly, default test environment + service instance means that if the required service instance does not exist in the preset test environment, but exists in the default test environment, then the service instance in the default test environment will be selected.

[0055] In one implementation, the test module may include multiple test environments, which may include at least one baseline environment and at least one feature environment corresponding to each baseline environment. The baseline environment deploys all service instances of the test object (e.g., all service instances of the test object under the same version); the feature environment may be a test environment set up for certain service instances of the test object, where not all service instances of the test object may be deployed. The service instances in the baseline environment have access to this test of the test object, allowing testing of the service instances required by the test object within the baseline environment. Alternatively, each feature environment only needs to deploy the service instances modified from those in the baseline environment. In this way, the feature environment does not need to deploy service instances of the same version as the baseline environment, thereby reducing the consumption of test resources.

[0056] In practice, communication and calls between service instances in the baseline and feature environments can be achieved through Istio's proxy (i.e., proxy nodes). It should be noted that data transmission between different feature environments does not interfere with each other.

[0057] For example, assuming the preset test environment is a feature environment, the corresponding service instance is searched first in the feature environment. If the corresponding service instance is not found in the feature environment, the corresponding service instance in the baseline environment is then searched.

[0058] For example, refer to Figure 4a This application provides a schematic diagram of the structure of a test module 1022 in a test device 102. The test module 1022 includes two test environments: a baseline environment 01 and a characteristic environment 02 corresponding to the baseline environment 01. Figure 4a The baseline environment 01 shown includes two service instances, service instance a1 and service instance a2, while the feature environment 02 includes service instance b2. Service instance b2 is another version of service instance a2 in the baseline environment. Assuming a dependency exists between service instance a1 and service instance a2 (service instance a2 depends on service instance a1), and since there is no other version of service instance a1 in the feature environment, service instance b2 also depends on service instance a1. It's understandable that each service instance in each test environment has a corresponding proxy node, Envoy. It should be noted that service instance a2 depending on service instance a1 specifically means that after testing service instance a1, service instance a2 needs to be called for testing. Therefore, service instance a2 depending on service instance a1 can also be understood as service instance a1 needing to call service instance a2. The dependencies of other service instances are similar and will not be elaborated here.

[0059] As an example, when the preset test environment is feature environment 02, and the access node 1021 obtains the test data of the first service instance of the test object, it is first necessary to determine whether the first service instance of the test object exists in feature environment 02; wherein, the first service instance of the test object in feature environment 02 corresponds to the service instance a1 in the baseline environment. However, Figure 4a If there is no first service instance in the characteristic environment 02 shown that corresponds to service instance a1 in the baseline environment, then service instance a1 is the first service instance, and baseline environment 01 is the actual test environment of the first service instance.

[0060] As another example, when the preset test environment is feature environment 02, and the first service instance of the test object is obtained by the proxy node of service instance a1, it is first necessary to determine whether the first service instance of the test object exists in feature environment 02. At this time, the first service instance is the service instance in feature environment 02 that depends on service instance a1. Based on the dependency relationship between service instances, it is determined that the service instance in feature environment 02 that depends on service instance a1 is service instance b2. Then, service instance b2 is the first service instance, and feature environment 02 is the actual test environment of the first service instance.

[0061] Optionally, the test data of the first service instance is routed to the proxy node of the first service instance (i.e., the first proxy node). After the proxy node of the first service instance identifies the test data of the first service instance, if it determines that the test is for the first service instance it proxies, the test data of the first service instance is transmitted to the first service instance so that the first service instance can be tested based on the test data of the first service instance.

[0062] It is understood that the testing method in this application embodiment is used for test environment multiplexing. Test environment multiplexing specifically uses limited test resources to logically isolate multiple environments (i.e. feature environments) on the basis of a baseline environment, so as to support the needs of parallel development and joint debugging on the basis of the baseline environment.

[0063] 203. If the test result of the first service instance in the actual test environment fails, then the first service instance shall be tested in the alternative test environment of the first service instance.

[0064] In one possible implementation, alternative test environments can be selected from one or more target test environments.

[0065] Understandably, different versions of the first service instance are deployed in the target test environment.

[0066] Specifically, if there is only one target test environment, then the target test environment is used as a backup test environment, and the test data of the first service instance is routed to the first service instance in the backup test environment, so as to test the first service instance in the backup test environment of the first service instance.

[0067] When there are multiple target test environments, the multiple target test environments can be prioritized, or the first service instances of each target test environment can be prioritized, and the target test environment with the highest priority can be selected as the alternative test environment, or the target test environment corresponding to the first service instance with the highest priority can be selected as the alternative test environment. The test data of the first service instance can be routed to the first service instance of the alternative test environment, so as to test the first service instance in the alternative test environment of the first service instance.

[0068] As an example, suppose the actual test environment is the preset test environment 501 of the first service instance. This means that the first service instance exists in the preset test environment 501. When the test result of the first service instance in the preset test environment 501 fails, then, in combination with the above method of determining the alternative test environment in multiple target test environments, the test environment with the highest priority among the target test environments 502 and 503 is selected as the alternative test environment. Assuming that the target test environment 502 has the highest priority, the first service instance in the target test environment 502 is tested.

[0069] As another example, in Figure 4a Based on, refer to Figure 4b Assume the preset test environment is Feature Environment 02, the actual test environment is Baseline Environment 01, and the alternative test environment is Feature Environment 03. Feature Environment 02 contains service instance b2, Baseline Environment 01 contains service instance a1, and Feature Environment 03 contains service instance c1; where service instance c1 is a different version of service instance a1. First, access node 1021 routes the test data of the first service instance to service instance a1. If the test of service instance a1 fails, the proxy node of service instance a1 can feed back the failed test data to access node 1021. Access node 1021 then routes the test data of the first service instance to service instance c1 through the proxy node of service instance c1, and service instance c1 completes the test of the first service instance of the test object. Alternatively, the proxy node of service instance a1 routes the test data of the first service instance to service instance c1 through the proxy node of service instance c1, and service instance c1 completes the test of the first service instance of the test object.

[0070] Additionally, if the test of service instance a1 fails, the proxy node of service instance a1 can route the test data of the first service instance to the first service instance c1 through the proxy node of service instance c1.

[0071] The testing method proposed in this application can be applied to a testing architecture that avoids duplicate deployment of service instances. When testing applications under this architecture, test management for a specific test object (e.g., an application) can be precisely managed down to each service instance of the test object. Specifically, test data for one service instance of the test object can be obtained, and the actual test environment of the service instance can be determined based on the test environment identifier carried in the test data. The test data of the service instance can then be routed to the actual test environment for testing. The test environment identifier can indicate a preset test environment for the test object, which can be the same as or different from the actual test environment of the service instance. The method provided in this application can route the test data of a service instance to the correct test environment using the test environment identifier in the test data, without being limited by the specific deployment form of the service instance in the architecture, thus ensuring a smooth testing process. While using the above architecture to avoid instability caused by deploying different versions of service instances in the same test environment, it also provides a flexible testing method for testing various test objects deployed based on this architecture.

[0072] Furthermore, in the aforementioned architecture, if a service instance in the actual test environment of the test object fails to complete the test, not only will the test of that service instance be impossible to complete, but it will also affect the subsequent testing of other service instances. This means that the testing of the test object can only stop at that service instance. Therefore, the method provided in this application embodiment addresses the possibility of test failure for the aforementioned service instance by providing an alternative test environment for the service instance. The service instance is then tested in the alternative test environment, thereby successfully completing the test for the service instance and avoiding the interruption of the test process due to the failure of the service instance test, thus ensuring the overall testing efficiency of the test object.

[0073] In one embodiment of this application, alternative test environments can be determined within one or more target test environments. Specifically, the determination method is as follows: one or more target test environments in which the first service instance is deployed are identified; alternative test environments for the first service instance are determined based on the test performance of the one or more target test environments; the test performance is related to the historical test success rate of the first service instance in the target test environments.

[0074] Optionally, the test performance of each target test environment can be determined based on its historical test success rate. It is understood that a higher test success rate for a target test environment indicates better test performance.

[0075] Specifically, the overall historical test success rate of all service instances in each target test environment is determined as the historical test success rate of that target test environment; or, the historical test success rate of the first service instance in that target test environment is determined as the historical test success rate of that target test environment. Then, the target test environment with the most stable test performance is selected as the alternative test environment.

[0076] Furthermore, by statistically analyzing the historical test success rates of each service instance in the target test environment and weighting the historical test success rates of all service instances in the target test environment, the overall historical test success rate of all service instances in the target test environment can be obtained.

[0077] In one implementation, determining the alternative test environment in one or more target test environments can be done in advance during the configuration of the first service instance in the preset test environment, or it can be determined after the test result of the first service instance in the actual test environment fails. This application embodiment does not limit this.

[0078] As an example, when multiple target test environments exist, the historical test success rates of these environments can be prioritized, or the historical success rates of the first service instance within each target test environment can be prioritized. The target test environment with the highest priority, or the target test environment corresponding to the highest-priority first service instance, can be selected as a backup test environment. Test data for the first service instance can then be routed to the first service instance within that backup test environment, allowing the first service instance to be tested within its backup test environment. Prioritization can be based on success rate from highest to lowest.

[0079] In another possible implementation, one or more target test environments are identified where the first service instance is deployed, and alternative test environments for the first service instance are identified based on the version number of the one or more target test environments.

[0080] For example, if multiple target test environments include target test environment v1.0, target test environment v2.0, and target test environment v3.0, where v1.0, v2.0, and v3.0 represent the version numbers of the target test environments, and a first service instance exists in all three target test environments, then the target test environment v1.0 can be selected as the candidate test environment first, sorted by version number from smallest to largest. Similarly, the target test environment v3.0 can be selected as the candidate test environment first, sorted by version number from largest to smallest.

[0081] In this embodiment, in order to successfully test the first service instance, alternative test environments for the first service instance are determined based on the test performance of one or more target test environments in which the first service instance is deployed. Since the test performance is related to the historical success rate of the first service instance in the target test environment, the success rate of testing the first service instance in the finally determined alternative test environments is higher.

[0082] In one embodiment of this application, after the first service instance in the alternative test environment has been tested, in order to complete the testing of the target object, test data of the next service instance of the first service instance is generated based on the test environment identifier, so that the test data of the next service instance of the first service instance can be routed back to the preset test environment. Therefore, after the first service instance in the alternative test environment has been tested, the test result of the first service instance is obtained; the test result of the first service instance carries the test environment identifier; the test result of the first service instance is determined as the test data of the second service instance; the execution of the second service instance depends on the test result of the first service instance, and the test data of the second service instance is used to request the test of the second service instance in the preset test environment.

[0083] It is understandable that the completion of the test of the first service instance in the alternative test environment indicates that the first service instance in the alternative test environment has successfully completed the test.

[0084] In one possible implementation, if the test result of the first service instance in the alternative test environment fails, the first service instance can continue to be tested in another alternative test environment of the first service instance in the remaining target test environment. The specific selection method can be referred to the above, and will not be repeated here.

[0085] In this embodiment, after the first service instance in the alternative test environment is tested, in order to continue testing subsequent service instances in the preset test environment, the test result of the first service instance carries a test environment identifier, and the test result of the first service instance is determined as the test data of the second service instance that depends on the result, so that the test data can be transferred to the second service instance in the preset test environment. Therefore, the method provided by the embodiments of this application can ensure that the test data of the subsequent service instance can be routed back to the preset test environment after calling the service instance of another test environment by carrying the test environment identifier in the test data of the subsequent service instance, thereby achieving the purpose of testing the service instance of the test object in the preset test environment.

[0086] In one embodiment of this application, a specific implementation method for determining the actual test environment of the first service instance is provided. When determining the actual test environment of the first service instance, it is first necessary to determine whether the first service instance exists in the preset test environment. Therefore, in one possible implementation, determining the actual test environment of the first service instance based on the test environment identifier can be: if the preset test environment deploys the first service instance, then the preset test environment is determined to be the actual test environment.

[0087] For example, in combination Figure 4a Assuming the preset test environment of the first service instance is feature environment 02, the test data of the first service instance is obtained by the proxy node of service instance a1. The proxy node of service instance a1 determines whether there is a service instance b2 that needs to be called in feature environment 02. Specifically, it determines whether there is a service instance b2 containing the test environment identifier (i.e., the identifier corresponding to feature environment 02) based on the test environment identifier, so as to identify service instance b2, and thus obtain the result that service instance b2 is deployed in feature environment 02, thereby determining that feature environment 02 is the actual test environment.

[0088] Optionally, the mapping between the service instance of the test object (which may refer to the first service instance, but is not limited to the first service instance) and the test environment identifier can be obtained. This mapping function can be provided by the cloud container management platform. In some embodiments, when deploying a test object through the cloud container management platform, the user can set the mapping between the service instance of the test object and the test environment identifier so that when testing the test object in subsequent testing work, the mapping between the service instance of the test object and the test environment identifier can be obtained based on the test environment identifier.

[0089] In this implementation, by determining the existence of a first service instance in a preset test environment, the preset test environment is designated as the actual test environment, thereby achieving correct routing of the test data of the first service instance.

[0090] In one embodiment of this application, a specific implementation method for determining the actual test environment of the first service instance is provided. Based on the embodiments of this application, a baseline environment is provided that deploys all service instances of the test object. When there is no first service instance in the preset test environment, it indicates that the first service instance has not been modified in the preset test environment. Therefore, the test of the service instance can be achieved through the first service instance in the baseline environment to complete the test of the test object. In one possible implementation, determining the actual test environment of the first service instance based on the test environment identifier may further include: if the preset test environment does not deploy the first service instance, then determining a baseline environment matching the preset test environment based on the test environment identifier; if the baseline environment deploys the first service instance, then determining the baseline environment as the actual test environment; the baseline environment deploys all service instances of the test object.

[0091] For example, in combination Figure 4a Assuming the preset test environment for the first service instance is feature environment 02, the access node obtains the test data for the first service instance. The access node determines whether the feature environment 02 has a service instance a1 that needs to be called. Specifically, it determines whether there is a service instance a1 containing the test environment identifier (i.e., the identifier corresponding to feature environment 02) based on the test environment identifier. Since the feature environment 02 does not contain a service instance corresponding to service instance a1, it is necessary to determine whether there is a service instance a1 in the baseline environment 01 corresponding to the preset test environment. After determining that there is a service instance a1 in the baseline environment 01, the baseline environment 01 is then determined to be the actual test environment.

[0092] In this implementation, by using the baseline environment of all service instances of the test object deployed, it is possible to identify the real test environment of the service instance as the baseline environment by using the test environment identifier in the test data of the first service instance when the test object is not deployed in the preset test environment. This is not limited by the specific deployment form of the service instance in the deployment architecture, and the test of the first service instance can be carried out smoothly.

[0093] In another embodiment of this application, considering that the test data of the first service instance is obtained by the access node, the access node needs to color the initial traffic data sent from the client for the test object to obtain the test data of the first service instance of the test object. Therefore, referring to Figure 5 Obtaining test data for the first service instance of the test object specifically includes the following steps:

[0094] 2011. Receive initial traffic data from the client of the test object.

[0095] Specifically, initial traffic data refers to test requests for the test object, which may include requests to call the first service instance.

[0096] 2012. Based on the test environment identifier, the initial traffic data was colored to obtain the test data of the first service instance.

[0097] Specifically, the test environment identifier is determined based on the user traffic characteristics in the initial traffic data, and then the initial traffic data is colored based on the test environment identifier to obtain the test data of the first service instance.

[0098] Optionally, a test environment identifier can be added to a preset location in the initial traffic data to obtain test data for the first service instance.

[0099] In one implementation, traffic coloring based on the test environment identifier means labeling the initial traffic data; it can also be understood as labeling specific traffic data. Here, the specified traffic data is the initial traffic data, and the label is the traffic coloring marker (i.e., the test environment identifier). It's important to note that the specified traffic data specifically refers to the traffic data generated when requesting to test the test object.

[0100] Furthermore, traffic coloring refers to setting corresponding traffic coloring rules according to the traffic protocol, marking specific traffic data (such as test traffic data) with color, and carrying this coloring mark throughout the entire service call chain of the test object. The purpose of traffic coloring is to enable the searching or routing of specific traffic data, thus traffic coloring can be used in testing scenarios. For example, in A / B testing scenarios, before the official release of the application, traffic coloring technology can be used for small-scale verification. By collecting user experience data, the functionality, performance, and stability of the new version of the application can be evaluated, and then an upgrade can be made based on the evaluation results. Even if a problem occurs in a new version or a certain node, it will only affect the colorized traffic and will not spread the problem to the entire application system, thus ensuring the normal operation of the entire application system.

[0101] In this embodiment, during client-side testing, initial traffic data can be tagged using traffic coloring to obtain test data for the first service instance. This marks the test branches of the first service instance's test data, allowing the test data to be routed to the corresponding test environment based on its test environment identifier. When these service instances call each other, the service instance is invoked based on the test environment identifier, ensuring the accuracy of service instances throughout the entire test chain. Therefore, this embodiment utilizes traffic coloring to provide a flexible testing method for testing various test objects deployed based on a service instance deployment architecture.

[0102] In another embodiment of this application, when coloring the initial traffic data, a preset field in the initial traffic data is identified, and then matched with the test environment description information of the test object based on the preset field, thereby determining the identifier of the test traffic to be tagged in the initial traffic data. Therefore, referring to... Figure 6 The process of coloring the initial traffic data according to the test environment identifier to obtain the test data for the first service instance may include the following steps:

[0103] 601. Determine the preset fields in the initial traffic data.

[0104] Optionally, the preset fields in the initial traffic data can be understood as data used to characterize traffic features.

[0105] Specifically, the traffic characteristics of initial traffic data can be unique data that identifies the initial traffic data, such as the user domain name. Traffic characteristics can include single or combined features. Assuming a single feature refers to any one of the three preset fields in the data packet: source IP address, destination IP address, and user domain name, combined feature data refers to combinations of these three preset fields, which may be combinations of two or more cases. For example, with a single feature, the user domain name in the initial traffic data can be used as a preset field; with multiple features, the source IP address + user domain name in the initial traffic data can be used as preset fields.

[0106] 602. Based on the preset fields and the test environment description information of the test object, determine the test environment identifier corresponding to the preset fields; the test environment description information includes the test environment identifier for each of the multiple test environments and the preset fields corresponding to the test environment identifier.

[0107] In some embodiments, a pre-configured traffic strategy is used to match the test environment identifier in the test environment description information with preset fields in the initial traffic data.

[0108] Specifically, dynamically configured test environment description information can be obtained through the cloud container management platform in the test device. This test environment description information describes the correspondence between preset fields of initial traffic data and test environment identifiers, in order to indicate the routing of initial traffic data from different test objects to the corresponding service instances. For example, assuming the preset field is a domain name field, which is used to represent user domain names, the correspondence between a single domain name field and the test environment identifier can be set when configuring the test environment description information.

[0109] 603. Perform traffic coloring processing on the initial traffic data according to the test environment identifier corresponding to the preset field to obtain the test data of the first service instance.

[0110] For example, for traffic of the Hypertext Transfer Protocol (HTTP), a test environment identifier can be added to the header of the initial traffic data to obtain test data for the first service instance; for traffic of the modern open-source remote procedure call framework (gRPC), a test environment identifier can be added to a reserved field of the initial traffic data to obtain test data for the first service instance.

[0111] In this embodiment, the test environment identifier corresponding to the preset field in the initial traffic data is determined by the test environment description information of the test object, which includes the test environment identifier of each test environment in multiple test environments and the preset field corresponding to the test environment identifier. This enables traffic coloring processing of the initial traffic data, obtains the test data of the first service instance, and ensures that the test data of the first service instance is correctly routed, avoiding calls to the wrong service instance.

[0112] In another embodiment of this application, when creating a test environment and service instances in the test environment, configuration items for each test environment can be displayed, and the identifier and preset fields of each test environment can be obtained through the configuration items of each test environment.

[0113] Optionally, during the creation of a service instance for the test environment, the configuration items of the test environment are displayed, and user input is received for each test environment identifier and preset fields. In response to the input, each test environment identifier and preset fields are obtained.

[0114] For example, the configuration items of each test environment are used to provide users with a custom input area for test environment identifiers and / or preset fields, or to display pre-configured test environment identifiers and / or preset fields to users, and provide a confirmation area for the information, so that users can confirm, modify and / or cancel the pre-configured test environment identifiers and / or preset fields. The specific display method of the configuration items of each test environment is not limited in this application embodiment.

[0115] Furthermore, during the creation of service instances in the test environment, the controls corresponding to the created environments in the environment management interface are triggered to display, for example... Figure 7 The environment list interface 71 shown displays environment information for multiple created test environments. Each environment's information may include, but is not limited to, one or more of the following: Environment ID (environment name), description, environment type, inherited environment, administrator, creation time, and operation. By triggering the display control 711 for each environment's information, the following can be displayed: Figure 8 The test environment service interface 81 is shown. Service instances can be created by triggering the create service control 811 in service interface 81, and existing service instances can be deployed by triggering the deploy existing service control 812 in service interface 81. Figure 8 The service information shown for each created service instance may include, but is not limited to, one or more of the following: service name, update time, and responsible person. Furthermore, by triggering the service information display control 8121 for each service instance, a management and configuration information interface for that service instance is displayed to the user; for example, by triggering... Figure 8 The display control 8121, with service name x1 as shown, can display, for example, Figure 9 The management and configuration information interface 91 shown can display node management control 911, image version control 912, and framework configuration control 913. By triggering any one of the node management control 911, image version control 912, and framework configuration control 913, the user can be shown corresponding data information and other operation controls. For example... Figure 9 As shown, when the image version control 912 is triggered, the image version data information and the build control 9121 are displayed. The image version data information may include, but is not limited to, one or more of the following: image name, status, git address / branch, compiled image, creator, creation time, and description.

[0116] In one possible implementation, when the test environment identifier and preset fields are obtained, they can be stored as key-value pairs for later querying.

[0117] In this embodiment, by displaying the configuration items of each test environment, the configuration items of each test environment can be intuitively shown to the user. By setting the configuration items, the identifier of each test environment and the preset fields can be obtained, so that when the initial traffic data of the test object is received, the test environment identifier corresponding to the initial traffic data can be identified based on the preset fields in the initial traffic data.

[0118] In another embodiment of this application, when a next service instance is called for testing after the previous service instance has been tested, the test data for the next service instance can be determined based on the test results of the previous service instance. Specifically, obtaining the test data of the first service instance of the test object includes: obtaining the test results of the third service instance of the test object; wherein the execution of the first service instance depends on the test results of the third service instance, and the test results of the third service instance carry a test environment identifier; and the test results of the third service instance are determined as the test data of the first service instance.

[0119] Understandably, after the third service instance test is completed, a call request to the first service instance will be initiated. The proxy node of the third service instance (i.e. the second proxy node) will intercept the traffic data corresponding to the call request to the first service instance and add a test environment identifier to the traffic data corresponding to the call request in order to generate the test results of the third service instance.

[0120] The traffic data in this embodiment may include call requests to service instances, and the proxy nodes of each service instance intercept the traffic data of their respective service instances. For a specific service instance call (e.g., the service call chain in the entire test process is service instance a calling service instance b, and service instance b calling service instance c), the process of service instance a calling service instance b specifically includes: after service instance a completes the test, it initiates call request 1 to service instance b, generates traffic data 1 corresponding to call request 1, and transmits it to the proxy node of service instance a. Upon receiving traffic data 1, the proxy node of service instance a appends a test environment identifier to traffic data 1 to generate test data 1 for service instance b, and transmits test data 1 to the proxy node of service instance b based on the test environment identifier. Upon receiving test data 1, the proxy node of service instance b records the test environment identifier in test data 1. The process of service instance b calling service instance c includes: after service instance b completes the test, it initiates call request 2 to service instance c, generates traffic data 2 corresponding to call request 2, and transmits it to the proxy node of service instance b. After receiving traffic data 2, the proxy node of service instance b adds a test environment identifier to traffic data 2 to obtain test data 2 for service instance c, and then transmits test data 2 to the proxy node of service instance c. It should be noted that this test environment identifier uniquely corresponds to the service call chain, thus enabling the test environment identifier to color the traffic data of the service call chain throughout the entire testing process.

[0121] Specifically, during the execution of a call request by a specified service instance, it may also initiate call requests to other service instances. In this case, the proxy node can use the aforementioned test environment identifier to color the traffic data of call requests to other service instances, thereby triggering the proxy nodes corresponding to other service instances and achieving precise service invocation. The service invocation mentioned here may involve parallel invocations of multiple service instances. For example, service A makes a service invocation to service B, and while service B is executing the test corresponding to the service invocation, service C initiates a call to service B. These service invocations form a parallel service invocation chain. The traffic data involved in the service invocations of different service instances will be collected and stored separately by the proxy nodes corresponding to service A, service B, and service C.

[0122] In this embodiment, when the third service instance needs to initiate a call to the first service instance after the test is completed, the test environment identifier from the test data of the first service instance is carried in the test result of the third service instance, thereby obtaining the test data of the first service instance. By carrying the test environment identifier, the correct routing of the test data of the first service instance is ensured, while the environment isolation of the service instance is achieved.

[0123] In one embodiment of this application, considering that the communication protocols of service instances, proxy nodes, and access nodes may differ during actual testing, this application provides a protocol conversion scheme to address the situation where the communication protocols of service instances, proxy nodes, and access nodes are different. Specifically, testing the first service instance based on test data of the first service instance in an actual test environment includes: performing protocol conversion processing on the test data of the first service instance according to the protocol requirements of the first service instance to obtain processed test data of the first service instance; and testing the first service instance in the actual test environment based on the processed test data of the first service instance.

[0124] For example, the protocol requirement of the first service instance is a private protocol, while the protocol of the test data of the first service instance is a public protocol. During the testing of the first service instance in the instance test environment, the proxy node of the first service instance needs to convert the public protocol of the test data of the first service instance into the private protocol of the first service instance, and test the first service instance in the actual test environment based on the test data of the first service instance converted to the private protocol.

[0125] In practical applications, Istio extends the Istio control plane based on Envoy's xDS protocol. Envoy's listeners implement rich traffic control strategies based on filter chains, allowing for custom protocol conversion logic to be executed within the listener through configuration of custom filters, thus adapting to proprietary protocols. For example, suppose there are two service instances, A and B. Service A uses the tRPC protocol (a proprietary protocol), while service B uses the HTTP protocol. When service A needs to call service B, a custom filter, such as `trpc_to_http_filter`, can be configured to convert service A's tRPC protocol to HTTP, enabling service A to call service B.

[0126] It's important to note that the xDS protocol is short for "X Discovery Service." The "X" indicates that it doesn't refer to a specific protocol, but rather a collective term for a set of service discovery protocols based on different data sources, including detection discovery services, route discovery services, cluster discovery services, and endpoint discovery services. In the Istio architecture, the xDS protocol provides a standard control plane specification, which is used to transmit service information and governance rules to the data plane. In Envoy, xDS is referred to as the data plane API and serves as the communication protocol between the control plane Pilot and the data plane Envoy.

[0127] In practical applications, custom filters can be programmed using C++, Lua scripting, or web assembly (WASM) languages ​​to perform protocol conversion.

[0128] In this embodiment, the protocol of the test data of the first service instance is converted according to the protocol requirements of the first service instance, so as to obtain test data that the first service instance can recognize, thereby avoiding the situation where the first service instance cannot recognize the test data of the first service instance, and enabling service testing for the first service instance to be realized.

[0129] In one embodiment of this application, to improve the applicability of the testing method, when data is transmitted between a service instance and a proxy node, or between various nodes (including proxy nodes and access nodes), it is necessary to achieve seamless data transmission based on the interaction protocols of each node and the service instance. Therefore, the test data of the first service instance is processed by protocol conversion according to the protocol requirements of the first service instance, including: converting the test data of the first service instance according to the interaction protocol between the source node of the test data of the first service instance and the proxy node of the first service instance to obtain initial converted data; and performing protocol conversion processing on the initial converted data according to the protocol requirements of the first service instance.

[0130] Optionally, the source node can be either an access node or a proxy node. In one example, when the source node is an access node, the interaction protocol between the access node and the proxy node of the first service instance is compared with the interaction protocol of the test data of the first service instance. If they are different, the access node uses its internal custom filter to transform the interaction protocol of the test data of the first service instance to obtain initial transformed data, and then transmits this initial transformed data to the proxy node of the first service instance. The proxy node of the first service instance determines whether the protocol of the initial transformed data conforms to the protocol requirements of the first service instance. If it does not conform, the proxy node of the first service instance uses its internal custom filter to perform protocol transformation on the initial transformed data, thereby obtaining the processed test data of the first service instance.

[0131] In another example, when the source node is a proxy node of a third service instance, the proxy node intercepts traffic data from the third service instance and generates test data for the first service instance based on the traffic data. It then identifies the protocol in the test data of the first service instance. If the protocol differs from that of the proxy node of the first service instance, the proxy node of the third service instance performs protocol conversion processing on the test data of the first service instance using its internal custom filter to obtain initial converted data, which is then transmitted to the proxy node of the first service instance. The proxy node of the first service instance determines whether the protocol of the initial converted data conforms to the protocol requirements of the first service instance; if not, it performs protocol conversion processing on the initial converted data using its internal custom filter to obtain the processed test data for the first service instance.

[0132] Reference Figure 10This document provides a schematic diagram of a protocol conversion process. Assume there are two service instances, Service A and Service B, both using the proprietary xRPC protocol. The interaction protocol between proxy node 10 of Service A and proxy node 20 of Service B uses gRPC. When Service A needs to call Service B, Service A transmits the first data to proxy node 10 based on IP tables. Proxy node 10 uses an internal custom filter to convert the xRPC protocol of the first data to the gRPC protocol (i.e., xrpc_to_grpc_proxy or xrpc2grpc-proxy) to obtain the second data, and then transmits the second data to proxy node 20 via IP tables. Proxy node 20 uses an internal custom filter to convert the gRPC protocol of the second data to the xRPC protocol (i.e., grpc_to_xrpc_proxy or grpc2xrpc--proxy) to obtain the third data, and then transmits the third data to Service B. Here, PodA is the container corresponding to Service A; PodB is the container corresponding to Service B. A Pod is the basic or smallest unit managed by a cloud container management platform. Inside a Pod, there are service instances and proxy nodes for those service instances.

[0133] In this embodiment, when the protocol in the test data of the first service instance differs from the interaction protocol between the nodes forwarding it, the test data of the first service instance is transformed using the interaction protocol between the source node and the proxy node of the first service instance to obtain initial transformed data. Then, the initial transformed data undergoes protocol transformation processing according to the protocol requirements of the first service instance. This avoids situations where the first service instance cannot recognize its own test data, enables data access between service instances, and allows service testing targeting the first service instance to be implemented.

[0134] To better understand the testing methods provided in the embodiments of this application, combined with Figure 1 , refer to Figure 11 The data transmission diagram shown illustrates the test method as an example. Figure 11The test module 1022 shown includes a baseline environment 01, a feature environment 02, and a feature environment 03. Baseline environment 01 includes three service instances: service instance a1, service instance a2, and service instance a3. Feature environment 02 includes service instance b2. Feature environment 03 includes service instance c1 and service instance c3. Service instance b2 in feature environment 02 is another version of service instance a2 in the baseline environment. Service instance c1 in feature environment 03 is another version of service instance a1 in the baseline environment, and service instance c3 in feature environment 03 is another version of service instance a3 in the baseline environment. Assume that the traffic data of client 101a corresponds to feature environment 02, the traffic data of client 101b corresponds to baseline environment 01, and the traffic data of client 101c corresponds to feature environment 03; feature environment 03 is an alternative test environment for feature environment 02.

[0135] In summary, the communication between service instances in the baseline and feature environments of this application embodiment is implemented based on Istio. Each service instance is based on the sidecar agent service governance model and has its own corresponding proxy node, Envoy. Communication between service instances is conducted through their respective proxy nodes, and communication between service instances and clients can be achieved through the service instance's proxy node and access node 1021.

[0136] For the case where the preset test environment is the baseline environment 01, the test data flow of the service instance call chain L1 is as follows: from the client 101b through the access node 1021 to the service instance a1 in the baseline environment 01, then to the service instance a2, and finally to the service instance a3.

[0137] For the preset test environment being feature environment 02, since there is no service instance corresponding to service instance a1 in feature environment 02, the data flow of service call chain L2 is as follows: it flows from client 101a through access node 1021 to service instance a1 in baseline environment 01. When the test result of service instance a1 fails, it flows directly to service instance c1. Then, it flows to service instance b2 in feature environment 02, and finally to service instance a3 in baseline environment 01.

[0138] For the preset test environment being feature environment 02, since there is no service instance corresponding to service instance a1 in feature environment 02, the data flow of service call chain L3 is as follows: from client 101a, it flows through access node 1021 to service instance a1 in baseline environment 01. When the test result of service instance a1 fails, it flows through access node 1021 to service instance c1. Then, it flows to service instance b2 in feature environment 02, and finally to service instance a3 in baseline environment 01.

[0139] It should be noted that the test data for each service instance includes the test environment identifier corresponding to the preset test environment.

[0140] In one implementation, refer to Figure 12 This document provides a structural diagram of the Envoy proxy, illustrating the process of entity hostA accessing hostB via Envoy. HostA initiates a request, which is then intercepted by the sidecar proxy (i.e., Envoy). Each host may run multiple service instances, and Envoy may contain multiple listeners. Each listener may contain multiple filters forming a filter chain. For protocol conversion in this embodiment, a custom filter can be added to the filter chain; for example, the data format of the custom filter could be grpc_to_xrpc_proxy. Furthermore, Envoyproxy also provides functions such as admin management, tracing lookup, and statistic analysis.

[0141] Specifically, Figure 12 The explanations of the names involved are as follows:

[0142] 1. A host refers to an entity capable of network communication (an application on a mobile phone or server, etc.). In Envoy, a host refers to a logical network application. As long as each host can be addressed independently, multiple hosts can run on a single physical piece of hardware.

[0143] 2. Listener Discovery Service (LDS).

[0144] 3. Route discovery service (RDS).

[0145] 4. Cluster discovery service (CDS).

[0146] 5. Endpoint discovery service (EDS).

[0147] 6. Downstream: Downstream hosts connect to Envoy, send requests, and receive responses.

[0148] 7. Upstream: The upstream host receives connection requests and responses from Envoy.

[0149] 8. Sidecar proxy (Evenoy XDS Protocol / Mesh Configuration Protocol): Sidecar proxy (Envoy xDSProtocol / Mesh Configuration Protocol).

[0150] 9. Listener: A listener or detector is a named network location (e.g., port, Unix domain socket, etc.) that can be connected to by downstream clients. Envoy exposes one or more listeners for downstream host connections. Typically, one Envoy runs per host, using a single process, but each process can start any number of listeners (detectors). Currently, it only detects TCP connections, and each detector is independently configured with a certain number of (L3 / L4) network filters. Listeners can also be dynamically obtained through the Listener Discovery Service (LDS).

[0151] 10. Secret Discovery Service (SDS).

[0152] 11. Metric service (MS).

[0153] 12. Rate limiting service (RLS).

[0154] 13. Health discovery service (HDS).

[0155] 14. xDS (original): Represents the xDS protocol, the original service.

[0156] 15. Host:Port / URL: host:port / URL, where URL represents the Uniform Resource Locator.

[0157] 16. Request intercepted by sidecar proxy.

[0158] 17. Route action: Route / Redirect / Direct response: Route forwards the request message to the appropriate cluster; Redirect redirects the request message to another domain name or host; Direct response means directly returning the response to the request message.

[0159] 18. Envoy API: Represents the application programming interface for proxy nodes.

[0160] 19. The filter_chain includes: client authorization (envoy.client_ssl_auth), output printing (envoy.echo, gRPC) protocol to gRPC protocol conversion (grpc_to_grpc_proxy), HTTP connection management (envoy.http_connection_manager), MongoDB proxy (envoy.mongo_proxy), rate limiting (envoy.rate_limit, redis) database proxy (envoy.redis_proxy), cluster scheduling (sni_cluster), HTTP filter (http_filter), Trift protocol filter (trift_filter), and other authorization filters (ext_authz_filter).

[0161] It should be noted that the schematic diagram of the Envoy proxy architecture in the embodiments of this application only illustrates a part of the structure and does not represent all the structures of Envoy proxy. The Envoy proxy architecture used in the embodiments of this application is not limited to the structure shown above.

[0162] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed in order to achieve the desired result.

[0163] Figure 13 This is a block diagram of a test apparatus according to an embodiment of this application.

[0164] like Figure 13 As shown, the testing device includes: an acquisition unit 1301 and a processing unit 1302.

[0165] The acquisition unit 1301 is used to acquire test data of the first service instance of the test object; the test data carries a test environment identifier, which is used to indicate the preset test environment of the test object.

[0166] The processing unit 1302 is also configured to determine the actual test environment of the first service instance based on the test environment identifier, and to test the first service instance based on the test data of the first service instance in the actual test environment.

[0167] The processing unit 1302 is used to test the first service instance in an alternative test environment if the test result of the first service instance in the actual test environment fails.

[0168] In some embodiments, the processing unit 1302 is specifically configured to determine one or more target test environments in which the first service instance is deployed, and to determine alternative test environments for the first service instance based on the test performance of the one or more target test environments; the test performance is related to the historical test success rate of the first service instance in the target test environments.

[0169] In some embodiments, the processing unit 1302 is specifically configured to obtain the test result of the first service instance after the test of the first service instance in the alternative test environment is completed; the test result of the first service instance carries a test environment identifier; determine the test result of the first service instance as the test data of the second service instance; the execution of the second service instance depends on the test result of the first service instance, and the test data of the second service instance is used to request the test of the second service instance in the preset test environment.

[0170] In some embodiments, the acquisition unit 1301 is specifically used to determine that the preset test environment is the actual test environment if a first service instance is deployed in the preset test environment.

[0171] In some embodiments, the acquisition unit 1301 is specifically used to determine a baseline environment matching the preset test environment based on the test environment identifier if the preset test environment does not deploy the first service instance. If the baseline environment deploys the first service instance, the baseline environment is determined as the actual test environment; the baseline environment deploys all service instances of the test object.

[0172] In some embodiments, the acquisition unit 1301 is specifically used to receive initial traffic data from the client of the test object. The initial traffic data is then processed by traffic coloring according to the test environment identifier to obtain test data for the first service instance.

[0173] In some embodiments, the acquisition unit 1301 is specifically used to determine preset fields in the initial traffic data. Based on the preset fields and the test environment description information of the test object, a test environment identifier corresponding to the preset fields is determined; the test environment description information includes the test environment identifier for each of multiple test environments and the preset fields corresponding to the test environment identifiers. The initial traffic data is then subjected to traffic coloring processing based on the test environment identifiers corresponding to the preset fields to obtain the test data for the first service instance.

[0174] In some embodiments, the testing apparatus further includes a display unit 1303; specifically, the display unit 1303 is used to display the configuration items of each test environment. The acquisition unit 1301 is used to acquire the identifier of each test environment and preset fields by displaying the configuration items of each test environment through the display unit 1303.

[0175] In some embodiments, the acquisition unit 1301 is specifically used to acquire the test results of a third service instance of the test object, the execution of the first service instance depends on the test results of the third service instance, the test results of the third service instance carry a test environment identifier; and determine the test results of the third service instance as the test data of the first service instance.

[0176] In some embodiments, the processing unit 1302 is specifically configured to perform protocol conversion processing on the test data of the first service instance according to the protocol requirements of the first service instance, to obtain processed test data of the first service instance. Based on the processed test data of the first service instance, the first service instance is tested in an actual test environment.

[0177] In some embodiments, the acquisition unit 1301 is specifically used to transform the test data of the first service instance according to the interaction protocol between the source node and the proxy node of the test data of the first service instance to obtain initial transformed data. The processing unit 1302 is specifically used to perform protocol transformation processing on the initial transformed data according to the protocol requirements of the first service instance.

[0178] The testing apparatus proposed in this application can be applied to a testing architecture that avoids duplicate deployment of service instances. When testing applications under this architecture, test management for a specific test object (e.g., an application) can be precisely managed down to each service instance of the test object. Specifically, test data for one service instance of the test object can be obtained, and the actual test environment of the service instance can be determined based on the test environment identifier carried in the test data. The test data of the service instance can then be routed to the actual test environment for testing. The test environment identifier can indicate a preset test environment for the test object, which can be the same as or different from the actual test environment of the service instance. The apparatus provided in this application can route the test data of a service instance to the correct test environment using the test environment identifier in the test data, without being limited by the specific deployment form of the service instance in the architecture, thus ensuring a smooth testing process. While avoiding instability caused by deploying different versions of service instances in the same test environment using the above architecture, it also provides a flexible testing apparatus for testing various test objects deployed based on this architecture. Furthermore, in the aforementioned architecture, if a service instance in the actual test environment of the test object fails to complete the test, not only will the test of that service instance be impossible to complete, but it will also affect the subsequent testing of other service instances. This means that the testing of the test object can only stop at that service instance. Therefore, the device provided in this application also provides an alternative test environment for the service instance in case of test failure, and tests the service instance in the alternative test environment, thereby successfully completing the test of the service instance and avoiding the problem of interruption of the test process due to the failure of the service instance test, thus ensuring the overall testing efficiency of the test object.

[0179] It should be understood that the units described in the test apparatus are related to the reference. Figure 3 The steps in the described method correspond to each other. Therefore, the operations and features described above for the method also apply to the test apparatus and the units contained therein, and will not be repeated here. The test apparatus can be pre-implemented in the browser or other security applications of the computer device, or it can be loaded into the browser or other security applications of the computer device by downloading or other means. The corresponding units in the test apparatus can cooperate with the units in the computer device to implement the solutions of the embodiments of this application.

[0180] The division of modules or units mentioned in the detailed description above is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0181] It should be noted that for details not disclosed in the testing device of this application embodiment, please refer to the details disclosed in the above embodiments of this application, which will not be repeated here.

[0182] The following is for reference. Figure 14 , Figure 14 A schematic diagram of a computer device suitable for implementing embodiments of this application is shown, such as... Figure 14 As shown, the computer system 1400 includes a central processing unit (CPU) 1401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1402 or programs loaded from storage section 1408 into random access memory (RAM) 1403. The RAM 1403 also stores various programs and data required for the system's operating instructions. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via a bus 1404. An input / output (I / O) interface 1405 is also connected to the bus 1404.

[0183] The following components are connected to I / O interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a LAN card, modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to I / O interface 1405 as needed. Removable media 1411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1410 as needed so that computer programs read from them can be installed into storage section 1408 as needed.

[0184] Specifically, according to embodiments of this application, the flowchart above refers to... Figure 3 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1409, and / or installed from removable medium 1411. When the computer program is executed by central processing unit (CPU) 1401, it performs the functions defined in the system of this application.

[0185] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0186] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0187] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor can be described as including a violator detection unit, a multimodal detection unit, and a recognition unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0188] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the test method described in this application. For example, it may execute... Figure 3 The steps of the test method shown.

[0189] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 3 The steps of the test method shown.

[0190] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A testing method, characterized in that, include: Obtain the test data of the first service instance of the test object; The test data of the first service instance carries a test environment identifier, which is used to indicate the preset test environment of the test object; Based on the test environment identifier, the actual test environment of the first service instance is determined, and the first service instance is tested in the actual test environment based on the test data of the first service instance. If the test result of the first service instance in the actual test environment is a failure, then the first service instance will be tested in an alternative test environment.

2. The test method according to claim 1, characterized in that, The method further includes: One or more target test environments are identified where the first service instance is deployed, and alternative test environments for the first service instance are determined based on the test performance of the one or more target test environments; the test performance is related to the historical test success rate of the first service instance in the target test environments.

3. The test method according to claim 1 or 2, characterized in that, The method further includes: After the first service instance in the alternative test environment has been tested, the test result of the first service instance is obtained; the test result of the first service instance carries the test environment identifier. The test results of the first service instance are used as the test data for the second service instance; the execution of the second service instance depends on the test results of the first service instance, and the test data of the second service instance is used to request testing of the second service instance in the preset test environment.

4. The test method according to claim 1, characterized in that, The step of determining the actual test environment of the first service instance based on the test environment identifier includes: If the preset test environment has the first service instance deployed, then the preset test environment is determined to be the actual test environment.

5. The testing method according to claim 1, wherein determining the actual test environment of the first service instance based on the test environment identifier includes: If the first service instance is not deployed in the preset test environment, a baseline environment matching the preset test environment is determined based on the test environment identifier; If the baseline environment has the first service instance deployed, then the baseline environment is determined as the actual test environment; the baseline environment has all service instances of the test object deployed.

6. The testing method according to claim 5, wherein obtaining the test data of the first service instance of the test object includes: Receive initial traffic data from the client of the test object; The initial traffic data is colored according to the test environment identifier to obtain the test data of the first service instance.

7. The testing method according to claim 6, wherein the step of performing traffic coloring processing on the initial traffic data according to the test environment identifier to obtain the test data of the first service instance includes: Determine the preset fields in the initial traffic data; Based on the preset field and the test environment description information of the test object, a test environment identifier corresponding to the preset field is determined; the test environment description information includes each test environment identifier in multiple test environments and the preset field corresponding to the test environment identifier. The initial traffic data is colored according to the test environment identifier corresponding to the preset field to obtain the test data of the first service instance.

8. The test method according to claim 7, characterized in that, The method further includes: Displays the configuration items for each test environment; The identifier and preset fields of each test environment are obtained through the configuration items of each test environment.

9. The testing method according to claim 1, wherein obtaining the test data of the first service instance of the test object includes: Obtain the test results of the third service instance of the test object. The execution of the first service instance depends on the test results of the third service instance. The test results of the third service instance carry the test environment identifier. The test results of the third service instance are used as the test data of the first service instance.

10. The testing method according to claim 1, wherein testing the first service instance based on the test data of the first service instance in the actual testing environment includes: According to the protocol requirements of the first service instance, the test data of the first service instance is processed by protocol conversion to obtain the processed test data of the first service instance. Based on the processed test data of the first service instance, the first service instance in the actual test environment is tested.

11. The testing method according to claim 10, wherein the step of performing protocol conversion processing on the test data according to the protocol requirements of the first service instance includes: The test data of the first service instance is transformed according to the interaction protocol between the source node of the test data of the first service instance and the proxy node of the first service instance to obtain the initial transformed data. The initial conversion data is processed according to the protocol requirements of the first service instance.

12. A testing device, characterized in that, include: The acquisition unit is used to acquire test data of the first service instance of the test object; The test data carries a test environment identifier, which is used to indicate the preset test environment of the test object; The processing unit is further configured to determine the actual test environment of the first service instance based on the test environment identifier, and to test the first service instance based on the test data of the first service instance in the actual test environment; The processing unit is configured to test the first service instance in an alternative test environment if the test result of the first service instance in the actual test environment fails.

13. The apparatus according to claim 12, characterized in that, The processing unit is specifically used to determine one or more target test environments in which the first service instance is deployed, and to determine alternative test environments for the first service instance based on the test performance of the one or more target test environments; the test performance is related to the historical test success rate of the first service instance in the target test environments.

14. The apparatus according to claim 12 or 13, characterized in that, The processing unit is specifically used to obtain the test result of the first service instance after the test of the first service instance in the alternative test environment is completed; the test result of the first service instance carries a test environment identifier; and the test result of the first service instance is determined as the test data of the second service instance. The execution of the second service instance depends on the test results of the first service instance. The test data of the second service instance is used to request the second service instance in the preset test environment.

15. The apparatus according to claim 12, characterized in that, The acquisition unit is specifically used to determine the preset test environment as the actual test environment if a first service instance is deployed in the preset test environment.

16. The apparatus according to claim 12, characterized in that, The acquisition unit is specifically used to determine a baseline environment that matches the preset test environment based on the test environment identifier if the preset test environment does not deploy the first service instance; and to determine the baseline environment as the actual test environment if the baseline environment deploys the first service instance. The baseline environment deploys all service instances of the test object.

17. The apparatus according to claim 16, characterized in that, The acquisition unit is specifically used to receive initial traffic data from the client of the test object; and to perform traffic coloring processing on the initial traffic data according to the test environment identifier to obtain the test data of the first service instance.

18. The apparatus according to claim 17, characterized in that, The acquisition unit is specifically used to determine preset fields in the initial traffic data; determine the test environment identifier corresponding to the preset fields based on the preset fields and the test environment description information of the test object; the test environment description information includes the test environment identifier of each test environment in multiple test environments and the preset fields corresponding to the test environment identifier; and perform traffic coloring processing on the initial traffic data based on the test environment identifier corresponding to the preset fields to obtain the test data of the first service instance.

19. The apparatus according to claim 18, characterized in that, The testing device further includes a display unit; the display unit is used to display the configuration items of each test environment; the acquisition unit is used to acquire the identifier of each test environment and preset fields by displaying the configuration items of each test environment through the display unit.

20. The apparatus according to claim 12, characterized in that, The acquisition unit is specifically used to acquire the test results of the third service instance of the test object. The execution of the first service instance depends on the test results of the third service instance. The test results of the third service instance carry a test environment identifier. The test results of the third service instance are used as the test data for the first service instance.

21. The apparatus according to claim 12, characterized in that, The processing unit is specifically used to perform protocol conversion processing on the test data of the first service instance according to the protocol requirements of the first service instance to obtain the processed test data of the first service instance; and to test the first service instance in the actual test environment based on the processed test data of the first service instance.

22. The apparatus according to claim 21, characterized in that, The acquisition unit is specifically used to transform the test data of the first service instance according to the interaction protocol between the source node and the proxy node of the first service instance to obtain initial transformed data; the processing unit is specifically used to perform protocol transformation processing on the initial transformed data according to the protocol requirements of the first service instance.

23. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the test method as described in any one of claims 1 to 11.

24. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the test method as described in any one of claims 1 to 11.

25. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1 to 11 to be performed.