Method and device for testing cross-unit access function and electronic equipment

Abstract

The invention discloses a testing method and device for a cross-unit access function and electronic equipment, and relates to the field of financial science and technology. The method comprises the following steps: performing Hash calculation on a routing source value used by a target system under a unitized architecture to obtain a Hash value corresponding to the routing source value; determining a routing rule of the target system according to the hash value corresponding to the routing source value; deploying a target module for each logic layer of each logic unit; and testing the cross-unit access function of the target system based on the target module and the routing rule. According to the method, the technical problem that in the prior art, whether the cross-unit access function of the system is normal or not is determined in a log query mode, so that the test efficiency of the cross-unit access function of the system is low, and then the solving timeliness of system faults is poor is solved.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and more specifically, to a method, device, and electronic device for testing cross-unit access functions. Background Art

[0002] Cross-unit access in a unitized architecture is prone to non-business failures such as performance and stability issues. If a failure or instability occurs during chaos testing, the cause of the problem is typically determined by searching various logs.

[0003] However, in chaos testing of a unitized architecture, determining whether the system's cross-unit access function is normal by querying logs will lead to low efficiency in testing the system's cross-unit access function, which in turn affects the timeliness of resolving system failures.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present application provide a method, device and electronic device for testing cross-unit access functions, so as to at least solve the technical problem in the prior art of determining whether the cross-unit access function of the system is normal by querying logs, resulting in low efficiency in testing the cross-unit access function of the system, and thus affecting the timeliness of solving system failures.

[0006] According to one aspect of an embodiment of the present application, a method for testing a cross-unit access function is provided, including: performing a hash calculation on a routing source value used by a target system under a unitized architecture to obtain a hash value corresponding to the routing source value, wherein the target system under the unitized architecture is divided into a mutually independent logical units and b logical layers, the routing source value represents an original data set used to determine a request routing direction under the unitized architecture, and both a and b are integers greater than 1; determining a routing rule of the target system based on the hash value corresponding to the routing source value; deploying a target module for each logical layer of each logical unit, wherein the target modules deployed in different logical units are used to realize cross-unit routing data transmission; and testing the cross-unit access function of the target system based on the target modules and the routing rules.

[0007] Optionally, a hash calculation is performed on the routing source value used by the target system under the unitized architecture to obtain a hash value corresponding to the routing source value, including: multiplying the number of logical units and the number of logical layers to obtain a first value; performing a modulus calculation on the first value to obtain a second value; and performing a hash calculation on the routing source value based on the second value to obtain a hash value corresponding to the routing source value.

[0008] Optionally, the routing rule includes a rule for constraining any two logic units corresponding to different logic layers of the target system to have only one common hash value through which traffic data corresponds.

[0009] Optionally, after deploying a target module for each logical layer of each logical unit, after detecting that the target module on the jth logical layer of the i-th logical unit receives the request data, the request data is transmitted to the target module on the j+1th logical layer, where i is a positive integer less than or equal to a, j is a positive integer less than b, the j+1th logical layer is the next logical layer of the j-th logical layer, and the logical unit corresponding to the j+1th logical layer is any logical unit; the request data is processed by the target module on the j+1th logical layer.

[0010] Optionally, based on the target module and routing rules, the cross-unit access function of the target system is tested, including: obtaining a test data set, wherein the test data set includes: K different target routing source values ​​and a target hash value corresponding to each target routing source value, wherein K is an integer greater than 1; inputting the target hash value in the test data set into the target system; based on the target module and routing rules, transmitting the target hash value in the test data set to the logical layers in different logical units of the target system; and determining the test result of the cross-unit access function of the target system based on the routing path information of the target hash value.

[0011] Optionally, the test result of the cross-unit access function of the target system is determined based on the routing path information of the target hash value, including: detecting the operating status of each logical layer of each logical unit in the process of transmitting the target hash value across units of the target system based on the routing path information of the target hash value, and obtaining the test result of the cross-unit access function of the target system.

[0012] Optionally, after determining the test result of the cross-unit access function of the target system based on the routing path information of the target hash value, if an abnormality is detected in the yth logical layer of the xth logical unit of the target system, the target hash value processed by the yth logical layer of the xth logical unit is obtained, and the target hash value is determined as the hash value to be verified, where x and y are both integers greater than or equal to 1; the target routing source value corresponding to the hash value to be verified is determined from the test data set; and the yth logical layer of the xth logical unit is repeatedly tested according to the target routing source value corresponding to the hash value to be verified.

[0013] According to another aspect of an embodiment of the present application, a testing device for a cross-unit access function is also provided, including: a first processing unit, used to perform hash calculation on the routing source value used by the target system under the unitized architecture to obtain a hash value corresponding to the routing source value, wherein the target system under the unitized architecture is divided into a mutually independent logical units and b logical layers, the routing source value represents the original data set used to determine the request routing direction under the unitized architecture, and both a and b are integers greater than 1; a determination unit, used to determine the routing rules of the target system based on the hash value corresponding to the routing source value; a deployment unit, used to deploy target modules for each logical layer of each logical unit, wherein the target modules deployed in different logical units are used to realize cross-unit routing data transmission; a testing unit, used to test the cross-unit access function of the target system based on the target modules and routing rules.

[0014] According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program runs, the device where the computer-readable storage medium is located executes the above-mentioned test method for the cross-unit access function.

[0015] According to another aspect of an embodiment of the present application, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors execute the above-mentioned test method for the cross-unit access function.

[0016] According to another aspect of an embodiment of the present application, a computer program product is further provided, wherein the computer program product includes a computer program or instructions, and the computer program or instructions implement the above-mentioned testing method for cross-unit access function when executed by a processor.

[0017] From the above content, it can be seen that the present application performs a hash calculation on the routing source value used by the target system under the unitized architecture to obtain a hash value corresponding to the routing source value, wherein the target system under the unitized architecture is divided into a mutually independent logical units and b logical layers, and the routing source value represents the original data set used to determine the request routing direction under the unitized architecture, and both a and b are integers greater than 1; the routing rules of the target system are determined based on the hash value corresponding to the routing source value; the target module is deployed for each logical layer of each logical unit, wherein the target modules deployed in different logical units are used to realize cross-unit routing data transmission; based on the target modules and routing rules, the cross-unit access function of the target system is tested.

[0018] In an embodiment of the present application, a method based on hash calculation and modular deployment is adopted. By dividing the target system under the unitized architecture into multiple independent logical units and multiple logical layers, and performing hash calculation on the routing source value to determine the routing rules, and at the same time deploying the target module for each logical layer of each logical unit to realize cross-unit routing data transmission, the purpose of efficiently determining the routing direction and performing cross-unit access function testing is achieved, thereby achieving the technical effect of improving the efficiency of the cross-unit access function testing of the test system, and thus solving the technical problem in the prior art of determining whether the system's cross-unit access function is normal by querying logs, resulting in low efficiency of the system's cross-unit access function testing, which in turn affects the timeliness of solving system failures. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0020] Figure 1 is a flowchart of an optional method for testing a cross-unit access function according to an embodiment of the present application;

[0021] Figure 2 This is a flowchart of an optional unitized architecture link call according to an embodiment of the present application;

[0022] Figure 3 This is a schematic diagram of an optional testing device for cross-unit access function according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0025] It should also be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) collected by this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or institution through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or institution.

[0026] According to an embodiment of the present application, an embodiment of a testing method for cross-unit access functions is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0027] Optionally, according to an embodiment of the present application, a test system for cross-unit access function (hereinafter referred to as the test system) is provided as the execution subject of the test method for cross-unit access function in the embodiment of the present application, wherein the test system can be a software system or an embedded system combining software and hardware. Of course, the method execution subject in the embodiment of the present application can also be other forms of execution subjects, such as devices, equipment, etc. Those skilled in the art should know that this application does not specifically limit the specific form of expression of the method execution subject.

[0028] Figure 1 is a flow chart of an optional method for testing cross-unit access functions according to an embodiment of the present application, such as Figure 1As shown, the method includes the following steps:

[0029] Step S101 : performing a hash calculation on a routing source value used by a target system under a unitized architecture to obtain a hash value corresponding to the routing source value.

[0030] In step S101, the target system under the unitized architecture is divided into a mutually independent logical units and b logical layers. The routing source value represents the original data set used to determine the request routing direction under the unitized architecture. Both a and b are integers greater than 1.

[0031] Alternatively, a modular architecture is an architectural design that uses unified segmentation rules to split the data and application layers into three-dimensional "zones" (logical units). In this architecture, logic calls and data access are closed within the logical unit. Most requests can be processed within the local unit, reducing the need for cross-regional access and improving target system stability and fault isolation.

[0032] Optionally, in a unitized architecture, the routing source value may include the client ID, the request source IP address, and other distinguishing information, which can be used to calculate a hash value to determine which logical unit the request should be routed to.

[0033] Optionally, hash calculation is an algorithm that converts input (such as a routing source value) into a fixed-size output (a hash value). The hash value is used to determine the logical unit and logical layer to which a request is routed in a unitized architecture, thereby ensuring that requests are evenly distributed within the target system, thereby avoiding overloading certain logical units or logical layers and improving the overall performance and stability of the target system. Furthermore, the test system can ensure the efficiency and effectiveness of hash calculations through technologies such as compressed hash values ​​and distributed hashing algorithms, helping the target system maintain efficiency and stability when processing large numbers of requests.

[0034] Alternatively, in a modular architecture, a logical unit refers to a module with independent processing capabilities. These can be physical servers, virtual machines, or containers, or logical services or processes. Logical layers refer to the different levels within the target system architecture, divided by function or processing stage. Each layer can be responsible for different tasks, such as the access layer, processing layer, and data layer.

[0035] Step S102: determining the routing rule of the target system according to the hash value corresponding to the routing source value.

[0036] Optionally, the test system can map the calculated hash value to a specific routing rule. The routing rule defines which logical unit and logical layer the request should be sent to. Specifically, the test system can first ensure that the hash value is evenly distributed across the logical units and logical layers by selecting an appropriate hash function and adjusting the parameters of the hash algorithm. Subsequently, the test system can set routing rules based on the distribution of hash values. For example, a rule can be set so that requests with hash values ​​within a certain range are routed to a specific logical unit and logical layer.

[0037] Optionally, during the target system's operation, the test system may need to dynamically adjust routing rules based on actual load conditions and performance indicators. To improve the efficiency and stability of the target system, the test system can also optimize routing rules. This optimization can include reducing routing conflicts, optimizing request paths, and ensuring load balancing. Furthermore, routing rules can include fault tolerance and failover mechanisms. This means that if a logical unit or layer fails, the routing rules can automatically redirect requests to other available logical units or layers.

[0038] For example, according to the normal algorithm, user A's guest editor should access logical unit 1, application A. The business process calls application B and finds that user A is in logical unit 2. This requires error correction based on the failover mechanism (the routing information of applications A and B is inconsistent, one of them has changed, and it needs to be corrected through the routing rule table).

[0039] Step S103 : deploying a target module for each logical layer of each logical unit.

[0040] In step S103, target modules deployed in different logical units are used to implement cross-unit routing data transmission.

[0041] Alternatively, in a unitized architecture, since data and applications are split into different logical units, a cross-unit routing data transmission mechanism is required to implement data transmission and communication between different logical units.

[0042] Optionally, deploying the target module may include the following process: First, when designing the target module, the test system needs to consider its functionality, performance, and scalability. The target module should be able to handle data transmission across units and be able to adapt to different logical layers. Next, the test system can deploy the target module to each logical layer of each logical unit. At the same time, the test system needs to ensure that the target module can be integrated with other system components (such as databases, message queues, other services, etc.) to achieve cross-unit data transmission. After the deployment is completed, the test system needs to test the target module to ensure that it can correctly handle cross-unit data transmission and will not introduce new failure points.

[0043] Step S104: testing the cross-unit access function of the target system based on the target module and routing rules.

[0044] Optionally, the test system's test of the cross-unit access function of the target system may include the following aspects: verifying whether the cross-unit access function can correctly route requests to the target logical units and logical layers according to routing rules; evaluating the performance of the cross-unit access function under different loads, including response time, throughput and resource utilization, etc.; checking whether the cross-unit access function is stable through long-term running tests, and whether there are memory leaks or other problems that cause instability in the target system; ensuring that data transmission during the cross-unit access process is secure and there is no risk of data leakage or unauthorized access; testing whether the cross-unit access function can automatically route requests to other available logical units or logical layers when a logical unit or logical layer fails.

[0045] Optionally, the test system can test the target system's cross-unit access capabilities based on chaos testing. Chaos testing is a system-state-based testing method. By measuring the state of the target system, the test system can test its operating state under different conditions. Over time, the target system can undergo uncertain transformations. When a new target system experiences a failure during use, its performance needs to be reassessed to determine whether it is stable and sustainable in the actual environment. This method tests the target system based on known target system states and records their changing trends to understand its performance in real-world applications.

[0046] It's important to note that chaos testing can include false positives in the test system's test results. A false positive occurs when a test mistakenly indicates a failure or instability in the target system, even though the target system is actually functioning normally. In other words, a test triggers an alarm or error report indicating a problem with the target system, but this is a false positive because the target system isn't actually experiencing any issues.

[0047] From the above content, it can be seen that the present application adopts a method based on hash calculation and modular deployment. By dividing the target system under the unitized architecture into multiple independent logical units and multiple logical layers, and performing hash calculation on the routing source value to determine the routing rules, and at the same time deploying the target module for each logical layer of each logical unit to realize cross-unit routing data transmission, the purpose of efficiently determining the routing direction and performing cross-unit access function testing is achieved, thereby achieving the technical effect of improving the efficiency of the cross-unit access function testing of the test system, and thus solving the technical problem in the prior art of determining whether the system's cross-unit access function is normal by querying logs, resulting in low efficiency of the system's cross-unit access function testing, which in turn affects the timeliness of solving system failures.

[0048] In an optional embodiment, a hash calculation is performed on the routing source value used by the target system under the unitized architecture to obtain a hash value corresponding to the routing source value, including: multiplying the number of logical units and the number of logical layers to obtain a first value; performing a modulus calculation on the first value to obtain a second value; and performing a hash calculation on the routing source value based on the second value to obtain a hash value corresponding to the routing source value.

[0049] Optionally, a is the number of logical units, and b is the number of logical layers. The first value (i.e., a*b) can be used to determine the range of the hash value corresponding to the routing source value. The second value is obtained by performing a modulo calculation on the first value. Modulo calculation is generally used to limit the range of the hash value corresponding to the routing source value so that it falls within the interval of (0, a*b-1). The hash value corresponding to the routing source value obtained by performing a hash calculation on the routing source value based on the second value can be used to determine the routing direction of the request.

[0050] In an optional embodiment, the routing rule includes a rule for constraining any two logic units corresponding to different logic layers of the target system to have only one common hash value corresponding to traffic data passing through.

[0051] Optionally, the test system controls traffic flow through routing rules, ensuring that only traffic corresponding to specific hash values ​​can pass through the connection between two logical units, thereby preventing data congestion and improving data transmission efficiency. Furthermore, since traffic data is evenly distributed across different logical units, it prevents overloading of some logical units while leaving others idle, thus facilitating load balancing. By restricting traffic to only traffic corresponding to specific hash values, the test system can also enhance the security of the target system, preventing unauthorized data access and potential network attacks.

[0052] Alternatively, if a logical unit fails, the impact of the failure can be limited to a smaller area because each logical unit only shares a common hash value with the other units, thereby improving the target system's fault tolerance. Furthermore, this routing rule design allows the target system to add or remove logical units by simply updating the relevant hash values ​​and routing rules, without requiring large-scale adjustments to the entire target system architecture.

[0053] Optionally, Figure 2 This is a flowchart of an optional unitized architecture link call according to an embodiment of the present application, such as Figure 2 As shown, the stock caller represents the client or user who initiates the request and provides information for identifying the client, as well as other additional information that may be used to distinguish different requests (i.e. Figure 2 The partitioned service routing layer (Application A, Application B, Application C, etc.), as the core routing layer of the target system, determines to which logical unit the request should be routed based on the information provided by the customer and the request type (such as the customer ID (request source IP address), other distinguishing information, Application A, Application B, Application C, etc.).

[0054] Zone01, Zone02, Zone03, and Zone04 are logical units within the target system. Each zone (logical unit) can independently process requests. Applications A, B, and C are assigned to the corresponding application processing module (i.e., the target module) within each logical unit based on the request type.

[0055] Below the application layer, the access layer is responsible for receiving and initially processing requests. Then, the processing layer is responsible for executing specific business logic and data processing.

[0056] Alternatively, the above process demonstrates how, within a modular architecture, a partitioned service routing layer can route requests to the correct logical unit and target module based on client information and request type. Each logical unit has its own access layer and processing layer (logical layering) to ensure that requests are handled correctly. This architecture improves the scalability, reliability, and maintainability of the target system, while also facilitating fault isolation and load balancing.

[0057] Optionally, Table 1 is a schematic table of an optional routing rule example according to an embodiment of the present application. As shown in Table 1, each cell in Table 1 represents a unitized Zone (logical unit), such as X1, X2, X3, etc., which are the basic processing units in the unitized architecture. The rows of Table 1 represent different logical layers, such as layer X, layer Y, layer Z, etc., and each layer may be responsible for different processing tasks. The numbers in the table (such as 00, 01, 02, etc.) represent link call identifiers, which are obtained from routing source values ​​(such as customer ID, request source IP, etc.) through methods such as hash operations and are used to determine the routing direction of the request data. Based on these link call identifiers, the target system can determine which logical unit and logical layer the request data should be routed to. For example, a request identified as 00 may be routed to logical unit X1 of layer X, logical unit X1 of layer Y, etc. In addition, Table 1 shows the calling relationship between different logical units, that is, cross-unit access. For example, a request may start from logical unit X1 of layer X and then be routed to logical unit X4 of layer Y.

[0058] Table 1

[0059]

[0060] In an optional embodiment, after deploying a target module for each logical layer of each logical unit, after detecting that the target module on the jth logical layer of the i-th logical unit receives the request data, the request data is transmitted to the target module on the j+1th logical layer, where i is a positive integer less than or equal to a, j is a positive integer less than b, the j+1th logical layer is the next logical layer of the j-th logical layer, and the logical unit corresponding to the j+1th logical layer is any logical unit; the request data is processed by the target module on the j+1th logical layer.

[0061] Optionally, a module (i.e., target module) based on AOP (Aspect-Oriented Programming) technology is set in each logical layer of each logical unit; when the target module on the jth logical layer receives request data from the existing caller, the target module will verify the validity of the request data, including the data format, integrity, and security. Once the verification is passed, the request data is transmitted to the target module on the j+1th logical layer (i.e., the target module of the next layer). Among them, if the j+1th logical layer is located in a logical unit different from the jth logical layer, the request data will be transmitted across units. After processing is completed, the result is returned to the previous layer or the existing caller. If an exception occurs during the processing process, the target module will capture the exception and perform corresponding error handling. Among them, during the entire request processing process, the target module will monitor performance indicators and record logs to facilitate subsequent analysis and debugging.

[0062] Specifically, AOP-based target modules horizontally penetrate various processing stages of the target system without changing the original business logic code, thereby implementing cross-cutting functions such as logging, performance monitoring, and transaction management. This design not only improves code reusability and maintainability, but also enhances the flexibility and scalability of the test system.

[0063] Optionally, the test system may dynamically select the logical unit where the j+1th logical layer is located according to the current load situation to achieve load balancing.

[0064] In an optional embodiment, the cross-unit access function of the target system is tested based on the target module and routing rules, including: obtaining a test data set, wherein the test data set includes: K different target routing source values ​​and a target hash value corresponding to each target routing source value, wherein K is an integer greater than 1; inputting the target hash value in the test data set into the target system; based on the target module and routing rules, transmitting the target hash value in the test data set to the logical layers in different logical units of the target system; and determining the test result of the cross-unit access function of the target system based on the routing path information of the target hash value.

[0065] Optionally, first, the test system can prepare a test data set, which contains K different target routing source values. Each target routing source value has a corresponding target hash value. For each routing source value, record the hash value obtained after hash calculation to ensure that the routing path of each routing source value can be traced during the test process of the test system. Subsequently, the target hash value in the test data set is input into the target system. The target hash value will be used to guide the routing of the request data. Based on the target module and routing rules, the test system can transfer the target hash value in the test data set to the logical layers in different logical units of the target system. This step simulates the actual cross-unit access scenario. Then, based on the routing path information of the target hash value, the test system can determine whether the cross-unit access function of the target system works as expected, including verifying whether the request is correctly routed to the specified logical unit and logical layer, and whether there are any problems in the routing process.

[0066] Optionally, the test system can run automated test scripts from existing callers, where these scripts use different target routing source values ​​to continuously verify the chaos test system (i.e., the target system). This process can automatically record the target hash value corresponding to each target routing source value, as well as their routing paths in the target system. Since hash operations are irreversible, it is impossible to trace back from the target hash value to the target routing source value. Therefore, each hash operation needs to record the corresponding relationship between the target hash value and the target routing source value.

[0067] Optionally, the test system can continuously verify the cross-unit access functionality of the target system by continuously running automated test scripts, thereby ensuring that the target system can operate stably under various conditions.

[0068] In an optional embodiment, the test result of the cross-unit access function of the target system is determined based on the routing information of the target hash value, including: detecting the operating status of each logical layer of each logical unit in the process of transmitting the target hash value across units of the target system based on the routing information of the target hash value, and obtaining the test result of the cross-unit access function of the target system.

[0069] Optionally, each target hash value corresponds to a specific routing path, which defines the data transmission path in the target system, including the logical units and logical layers that the data needs to traverse. In the process of transmitting the target hash value across units, the test system will detect the operating status of each logical layer of each logical unit, including monitoring the key performance indicators of the logical units and logical layers, such as response time, processing capacity, and error rate. Subsequently, by analyzing the operating status of each logical unit and logical layer, the test system can evaluate the cross-unit access function of the entire target system, including verifying whether the data can be correctly transmitted according to the expected routing path, and whether any problems occur during the transmission process. Combining the information from the above detection and evaluation, the test system can obtain the test results of the cross-unit access function of the target system. These results can reflect the performance and stability of the target system under actual operating conditions, and whether the cross-unit access function meets the design requirements.

[0070] Optionally, during testing, testers can inject anomalies to simulate potential failure scenarios, such as network delays or service outages. Using a distributed holographic monitoring mechanism, testers can observe the impact of these anomalies on the target system's cross-unit access capabilities. Test results will be used to continuously verify and optimize the target system's cross-unit access capabilities. If issues are discovered, timely adjustments can be made to improve the target system's reliability and performance.

[0071] In an optional embodiment, after determining the test result of the cross-unit access function of the target system based on the routing path information of the target hash value, if an abnormality is detected in the yth logical layer of the xth logical unit of the target system, the target hash value processed by the yth logical layer of the xth logical unit is obtained, and the target hash value is determined as the hash value to be verified, where x and y are both integers greater than or equal to 1; the target routing source value corresponding to the hash value to be verified is determined from the test data set; and the yth logical layer of the xth logical unit is repeatedly tested based on the target routing source value corresponding to the hash value to be verified.

[0072] Optionally, after detecting an abnormality in the yth logical layer of the xth logical unit of the target system, the test system can use the established routing rules to determine the target hash value (determined as the hash value to be verified) and its corresponding target routing source value involved in the yth logical layer of the xth logical unit, thereby identifying which request data is affected and requires further testing and verification.

[0073] For example, as shown in Table 1, if anomalies occur in logic unit X1 on the Z layer, logic unit X4 on the Y layer, and logic unit X3 on the X layer, the target hash value is obtained from the common subset {06} of the corresponding three identifier sets {00, 06, 11, 13}, {03, 06, 09, 12}, and {02, 06, 10, 14}, and the corresponding target routing source value is obtained. If anomalies occur in more layers, the target hash values ​​corresponding to the common subsets of the corresponding identifier sets of these layers are used as the hash values ​​to be verified, and the corresponding target routing source values ​​are then found in turn.

[0074] Optionally, the test data corresponding to the acquired target routing source values ​​is repeatedly validated. This involves sending the test data through the same routing path and monitoring its processing and results to ensure that the target system can correctly handle these requests. The test system then analyzes the results of the repeated tests, determines the cause of the anomaly, evaluates the performance and stability of the target system, and makes adjustments or optimizations to the target system as needed.

[0075] Optionally, during chaos testing, the target system may encounter a variety of causes leading to failures or instabilities. Only some of these causes are directly related to the test data. Therefore, in order to accurately locate the problem, in addition to analyzing the test data, other methods and tools are required. Among these, utilizing a test experience database to search for historical cases or known issues that may be related to the current issue based on the target routing source value is a supplementary tool. This can accelerate the problem diagnosis process by increasing the probability of problem reproduction and leveraging historical test data, but it does not preclude the use of other technical means for further analysis and resolution. This method can serve as a powerful supplement to problem location during chaos testing, helping developers to more comprehensively understand and resolve failures and instabilities in the target system.

[0076] According to another aspect of the present application, a testing device for cross-unit access function is provided, wherein: Figure 3 is a schematic diagram of an optional test device for cross-unit access function according to an embodiment of the present application, such as Figure 3 As shown, the testing device for the cross-unit access function includes: a first processing unit 301 , a determination unit 302 , a deployment unit 303 , and a testing unit 304 .

[0077] Optionally, the first processing unit 301 is used to perform a hash calculation on the routing source value used by the target system under the unitized architecture to obtain a hash value corresponding to the routing source value, wherein the target system under the unitized architecture is divided into a mutually independent logical units and b logical layers, and the routing source value represents the original data set used to determine the request routing direction under the unitized architecture, and both a and b are integers greater than 1; the determination unit 302 is used to determine the routing rules of the target system based on the hash value corresponding to the routing source value; the deployment unit 303 is used to deploy target modules for each logical layer of each logical unit, wherein the target modules deployed in different logical units are used to realize cross-unit routing data transmission; the testing unit 304 is used to test the cross-unit access function of the target system based on the target module and the routing rule.

[0078] Optionally, the first processing unit 301 includes: a first processing sub-unit, a second processing sub-unit, and a third processing unit. The first processing sub-unit is configured to perform a product calculation on the number of logical units and the number of logical layers to obtain a first value; the second processing sub-unit is configured to perform a modulo calculation on the first value to obtain a second value; and the third processing unit is configured to perform a hash calculation on the routing source value based on the second value to obtain a hash value corresponding to the routing source value.

[0079] Optionally, the test device for the cross-unit access function further includes: a second processing unit and a third processing unit. The second processing unit is configured to, after detecting that the target module on the jth logical layer of the i-th logical unit has received the request data, transmit the request data to the target module on the j+1th logical layer, where i is a positive integer less than or equal to a, j is a positive integer less than b, the j+1th logical layer is the next logical layer after the j-th logical layer, and the logical unit corresponding to the j+1th logical layer is any logical unit; and the third processing unit is configured to process the request data via the target module on the j+1th logical layer.

[0080] Optionally, the test unit 304 includes: an acquisition subunit, a fourth processing subunit, a fifth processing subunit, and a first determination subunit. A test data set is acquired, wherein the acquisition subunit is configured to test the data set including K different target routing source values ​​and a target hash value corresponding to each target routing source value, where K is an integer greater than 1; the fourth processing subunit is configured to input the target hash value in the test data set into the target system; the fifth processing subunit is configured to transmit the target hash value in the test data set to logical layers in different logical units of the target system based on the target module and routing rules; and the first determination subunit is configured to determine a test result of the cross-unit access function of the target system based on the routing path information of the target hash value.

[0081] Optionally, the first determination subunit includes a detection module, wherein the detection module is configured to detect, based on routing information of the target hash value, the operating status of each logical layer of each logical unit in the target system during the cross-unit transmission of the target hash value, and obtain a test result of the cross-unit access function of the target system.

[0082] Optionally, the testing unit 304 further includes: a sixth processing subunit, a second determining subunit, and a testing subunit. The sixth processing subunit is configured to, if an abnormality is detected in the yth logical layer of the xth logical unit of the target system, obtain a target hash value processed by the yth logical layer of the xth logical unit and determine the target hash value as the hash value to be verified, where x and y are both integers greater than or equal to 1; the second determining subunit is configured to determine a target routing source value corresponding to the hash value to be verified from a test data set; and the testing subunit is configured to repeatedly test the yth logical layer of the xth logical unit based on the target routing source value corresponding to the hash value to be verified.

[0083] According to another aspect of the present application, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program runs, the device where the computer-readable storage medium is located executes the above-mentioned test method for the cross-unit access function.

[0084] According to another aspect of the present application, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors execute the above-mentioned test method for the cross-unit access function.

[0085] The above-mentioned embodiments or examples disclosed in this application are not exhaustive, but are only illustrations of some embodiments or examples, and are not intended to be specific limitations on the scope of protection disclosed in this application. In the absence of contradiction, each step in a certain embodiment or example in this application can be implemented as an independent example, and the steps can be arbitrarily combined. For example, the solution after removing some steps in a certain embodiment or example can also be implemented as an independent example, and the order of the steps in a certain embodiment or example can be arbitrarily exchanged. In addition, the optional methods or optional examples in a certain embodiment or example can be arbitrarily combined; in addition, the various embodiments or examples can be arbitrarily combined. For example, some or all of the steps in different embodiments or examples can be arbitrarily combined, and a certain embodiment or example can be arbitrarily combined with the optional methods or optional examples of other embodiments or examples.

[0086] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0087] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0089] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected to achieve the purpose of the present embodiment according to actual needs.

[0090] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0091] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program code.

[0092] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for testing cross-unit access functions, characterized in that: include: Performing a hash calculation on a routing source value used by a target system in a unitized architecture to obtain a hash value corresponding to the routing source value, wherein the target system in the unitized architecture is divided into a number of mutually independent logical units and b number of logical layers, the routing source value represents a set of original data used to determine a request routing direction in the unitized architecture, and a and b are both integers greater than 1; Determining a routing rule of the target system according to a hash value corresponding to the routing source value; Deploy a target module for each logical layer of each logical unit, wherein the target modules deployed in different logical units are used to implement routing data transmission across units; Based on the target module and the routing rule, a cross-unit access function of the target system is tested.

2. The method according to claim 1, characterized in that Perform hash calculation on the routing source value used by the target system under the unitized architecture to obtain a hash value corresponding to the routing source value, including: multiplying the number of the logical units and the number of the logical layers to obtain a first value; Performing a modulo calculation on the first value to obtain a second value; A hash calculation is performed on the routing source value according to the second numerical value to obtain a hash value corresponding to the routing source value.

3. The method according to claim 1, characterized in that The routing rule includes a rule for constraining any two logic units corresponding to different logic layers of the target system to have and only have traffic data corresponding to a common hash value pass through.

4. The method according to claim 1, wherein After deploying the target module for each logical layer of each logical unit, the method further includes: After detecting that the target module on the jth logical layer of the i-th logical unit has received the request data, the request data is transmitted to the target module on the j+1th logical layer, where i is a positive integer less than or equal to a, j is a positive integer less than b, the j+1th logical layer is the next logical layer of the j-th logical layer, and the logical unit corresponding to the j+1th logical layer is any logical unit; The request data is processed by the target module on the j+1th logical layer.

5. The method according to claim 1, wherein Testing the cross-unit access function of the target system based on the target module and the routing rule includes: Obtain a test data set, wherein the test data set includes: K different target routing source values ​​and a target hash value corresponding to each target routing source value, wherein K is an integer greater than 1; inputting the target hash value in the test data set into the target system; Based on the target module and the routing rule, transmitting the target hash value in the test data set to the logical layers in different logical units of the target system; A test result of the cross-unit access function of the target system is determined according to the routing path information of the target hash value.

6. The method according to claim 5, characterized in that Determining a test result of a cross-unit access function of the target system according to routing information of the target hash value includes: According to the routing information of the target hash value, the operating status of each logical layer of each logical unit in the target system during the cross-unit transmission of the target hash value is detected to obtain the test result of the cross-unit access function of the target system.

7. The method according to claim 5, characterized in that After determining a test result of the cross-unit access function of the target system according to the routing information of the target hash value, the method further includes: If an abnormality is detected in the yth logical layer of the xth logical unit of the target system, obtaining a target hash value processed by the yth logical layer of the xth logical unit, and determining the target hash value as the hash value to be verified, where x and y are both integers greater than or equal to 1; Determine the target routing source value corresponding to the hash value to be verified from the test data set; Repeat the test on the yth logical layer of the xth logical unit according to the target routing source value corresponding to the hash value to be verified.

8. A test device for cross-unit access function, characterized in that: include: a first processing unit, configured to perform a hash calculation on a routing source value used by a target system in a unitized architecture to obtain a hash value corresponding to the routing source value, wherein the target system in the unitized architecture is divided into a number of mutually independent logical units and b number of logical layers, the routing source value represents a set of original data used to determine a request routing direction in the unitized architecture, and a and b are both integers greater than 1; a determining unit, configured to determine a routing rule of the target system according to a hash value corresponding to the routing source value; A deployment unit, configured to deploy a target module for each logical layer of each logical unit, wherein the target modules deployed in different logical units are used to implement routing data transmission across units; The testing unit is used to test the cross-unit access function of the target system based on the target module and the routing rule.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the method for testing the cross-unit access function according to any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the testing method for cross-unit access function as described in any one of claims 1 to 7.

11. A computer program product, characterized in that The method comprises a computer program or an instruction, which implements the test method of the cross-unit access function according to any one of claims 1 to 7 when executed by a processor.

Images