System mobility testing method, mobility testing system, device and storage medium

Abstract

The present application relates to a system mobility test method, a mobility test system, a device and a storage medium, and relates to the field of system testing technology. The method includes: receiving a business request in real time, the business request includes a first business request, and the first business request is one of the business requests received in real time in the interface corresponding to the original system; inputting the first business request into the original system and the target system for processing respectively in a first order; obtaining a first original processing result and a first test processing result; and determining the portability of the target system based on the first original processing result and the first test processing result. Through the above method, during the system mobility test process, the system portability test can be performed based on real online business requests, which expands the coverage of the test data and improves the accuracy of the target system test.

Description

Technical Field

[0001] The present application relates to the technical field of system testing, and in particular to a system mobility testing method, a mobility testing system, a device and a storage medium. Background Art

[0002] The upgrading of business systems is often accompanied by the need to transfer business requests that were originally responded to in the old business systems to the new business systems.

[0003] Before transferring the business in the old business system to the target system, the portability of the new business system needs to be tested to ensure that when the business system changes, it will not affect the business execution of the applications that originally relied on the old business system. In related technologies, when testing the portability of the new business system, the portability of the new business system is generally tested by obtaining a part of the business requests that have been processed historically by the old business system.

[0004] However, in the above-mentioned related technologies, the portability of the new business system is tested by using offline business requests, and the real-time performance of the data is poor, which leads to low accuracy in testing the new business system. Summary of the invention

[0005] This application is about a system migration test method, migration test system, device and storage medium, which conducts system migration test based on real online business requests, expands the coverage of test data, and improves the accuracy of target system testing. The technical solution is as follows:

[0006] In one aspect, a system mobility testing method is provided, the method comprising:

[0007] receiving a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in the interface corresponding to the original system;

[0008] Inputting the first service request into the original system and the target system respectively for processing in a first order;

[0009] Acquire a first original processing result and a first test processing result; the first original processing result is a processing result obtained by the original system in response to the first service request; the first test processing result is a processing result obtained by the target system in response to the first service request;

[0010] The migration feasibility of the target system is determined based on the first original processing result and the first test processing result.

[0011] In a possible implementation, inputting the first service request into the original system and the target system for processing in a first order includes:

[0012] Connecting the first service request to the original system for processing;

[0013] In response to the first service request in the original system being processed completely, the first service request is played back to the target system.

[0014] In a possible implementation, in response to the first service request in the original system being processed completely, playing the first service request back to the target system includes:

[0015] In response to the first service request in the original system having been processed, the first service request is played back to the target system through an API (Application Programming Interface) agent.

[0016] In a possible implementation manner, determining the migration feasibility of the target system based on the first original processing result and the first test processing result includes:

[0017] In response to the first original processing result being the same as the first test processing result, determining that the target system is migratable;

[0018] In response to the first original processing result being different from the first test processing result, it is determined that the target system is not migratable.

[0019] In a possible implementation manner, in response to the first original processing result being the same as the first test processing result, the method further includes:

[0020] inputting the second service request into the original system and the target system respectively for processing in a second order; the second service request is at least one of the service requests received in real time in the interface corresponding to the original system, and the second order is different from the first order;

[0021] Acquire a second test processing result and a second original processing result; the second original processing result is a processing result obtained by the original system in response to the second service request; the second test processing result is a processing result obtained by the target system in response to the second service request;

[0022] Based on the second test processing result and the second original processing result, the migration feasibility of the target system is determined.

[0023] In a possible implementation, the inputting the second service request into the original system and the target system respectively for processing in the second order includes:

[0024] Connecting the second service request to the target system;

[0025] In response to the second service request in the target system being processed completely, the second service request is played back to the original system.

[0026] In a possible implementation, the method further includes:

[0027] In response to the first original processing result being different from the first test processing result, replaying and retrying the first service request in the target system;

[0028] Within a preset retry number threshold, in response to the first original processing result being different from the first test processing result, it is determined that the target system cannot be migrated.

[0029] In a possible implementation, the method further includes:

[0030] In response to the second original processing result being different from the second test processing result, replaying and retrying the second service request in the original system;

[0031] Within a preset retry number threshold, in response to the second original processing result being different from the second test processing result, it is determined that the target system cannot be migrated.

[0032] In a possible implementation, the first system portability determination process is performed at least once until the number of the first service requests is the same as the number of the service requests received in real time in the interface corresponding to the original system; the first system portability determination process includes:

[0033] Inputting the first service request into the original system and the target system respectively for processing according to the first order;

[0034] Obtaining the first original processing result and the first test processing result;

[0035] In response to the first original processing result being the same as the first test processing result, increasing the number of the first service requests based on the current number of the first service requests;

[0036] The determining the migration feasibility of the target system based on the first original processing result and the first test processing result includes:

[0037] In response to the number of the first service requests being the same as the number of the service requests received in real time in the interface corresponding to the original system, the migration feasibility of the target system is determined based on the first original processing result and the first test processing result.

[0038] In a possible implementation, the method further includes:

[0039] Performing at least one second system migration determination process until the number of the second service requests is the same as the number of the service requests received in real time in the interface corresponding to the original system; the second system migration determination process includes:

[0040] inputting the second service request into the original system and the target system respectively for processing according to the second order;

[0041] Obtaining the second test processing result and the second original processing result;

[0042] In response to the second original processing result being the same as the second test processing result, increasing the number of the second service requests based on the current number of the second service requests;

[0043] The determining the migration feasibility of the target system based on the second test processing result and the second original processing result includes:

[0044] In response to the number of the second service requests being the same as the number of the service requests received in real time in the interface corresponding to the original system, the migration feasibility of the target system is determined based on the second test processing result and the second original processing result.

[0045] On the other hand, a migration test system is provided, the system comprising: an application program interface API agent and a data comparison tool;

[0046] The API agent is used to input the first business request into the original system and the target system respectively for processing in a first order; the first business request is at least one of the business requests received in real time in the interface corresponding to the original system;

[0047] The data comparison tool is used to determine the portability of the target system based on the first original processing result and the first test processing result, wherein the first original processing result is the processing result obtained by the original system in response to the first business request; and the first test processing result is the processing result obtained by the target system in response to the first business request.

[0048] In a possible implementation, the API agent is used to, in response to the first original processing result being the same as the first test processing result, input a second business request into the original system and the target system for processing respectively in a second order; the second business request is at least one of the business requests received in real time in the interface corresponding to the original system, and the second order is different from the first order;

[0049] The data comparison tool is used to determine the portability of the target system based on the second test processing result and the second original processing result, wherein the second original processing result is the processing result obtained by the original system in response to the second business request; and the second test processing result is the processing result obtained by the target system in response to the second business request.

[0050] On the other hand, a system mobility testing device is provided, the device is applied to a mobility testing system, and the device comprises:

[0051] A service request receiving module, used for receiving a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in the interface corresponding to the original system;

[0052] A first business request processing module, used for inputting the first business request into the original system and the target system respectively for processing in a first order;

[0053] A first processing result acquisition module is used to acquire a first original processing result and a first test processing result; the first original processing result is a processing result obtained by the original system in response to the first service request; the first test processing result is a processing result obtained by the target system in response to the first service request;

[0054] The first portability determination module is used to determine the portability of the target system based on the first original processing result and the first test processing result.

[0055] In a possible implementation, the first service request processing module includes:

[0056] A first service request processing submodule, used for connecting the first service request to the original system for processing;

[0057] The second service request processing submodule is configured to, in response to the first service request in the original system having been processed, play the first service request back to the target system.

[0058] In a possible implementation, the second service request processing submodule is configured to, in response to the first service request in the original system having been processed, replay the first service request to the target system through an application programming interface (API) proxy.

[0059] In a possible implementation, the first portability determination module includes:

[0060] A first migration determination submodule, configured to determine that the target system is migrateable in response to the first original processing result being the same as the first test processing result;

[0061] The second migration determination submodule is configured to determine that the target system is not migrationable in response to the first original processing result being different from the first test processing result.

[0062] In a possible implementation manner, the device further includes:

[0063] a second business request processing module, configured to, in response to the first original processing result being the same as the first test processing result, input a second business request into the original system and the target system for processing in a second order; the second business request is at least one of the business requests received in real time in the interface corresponding to the original system, and the second order is different from the first order;

[0064] The second processing result acquisition module is used to obtain a second test processing result and a second original processing result; the second original processing result is a processing result obtained by the original system in response to the second business request; the second test processing result is a processing result obtained by the target system in response to the second business request;

[0065] The second portability determination module is used to determine the portability of the target system based on the second test processing result and the second original processing result.

[0066] In a possible implementation, the second service request processing module includes:

[0067] A third service request processing submodule, used for connecting the second service request to the target system for processing;

[0068] The fourth service request processing submodule is used to play the second service request back to the original system in response to the second service request in the target system having been processed.

[0069] In a possible implementation manner, the first portability determination module further includes:

[0070] A first playback and retry submodule, configured to, in response to the first original processing result being different from the first test processing result, replay and retry the first service request in the target system;

[0071] The second migration feasibility determination submodule is configured to determine that the target system is not migratable in response to the first original processing result being different from the first test processing result within a preset retry number threshold.

[0072] In a possible implementation manner, the second portability determination module further includes:

[0073] A second playback and retry submodule, configured to, in response to the second original processing result being different from the second test processing result, replay and retry the second service request in the original system;

[0074] The fourth migration submodule is configured to determine that the target system is not migrateable in response to the second original processing result being different from the second test processing result within a preset retry number threshold.

[0075] In a possible implementation manner, the device further includes:

[0076] The first loop execution module is used to execute the first system migration determination process at least once until the number of the first service requests is the same as the number of the service requests received in real time in the interface corresponding to the original system; the first system migration determination process includes:

[0077] Inputting the first service request into the original system and the target system respectively for processing according to the first order;

[0078] Obtaining the first original processing result and the first test processing result;

[0079] In response to the first original processing result being the same as the first test processing result, increasing the number of the first service requests based on the current number of the first service requests;

[0080] The first portability determination module is used to determine the portability of the target system based on the first original processing result and the first test processing result in response to the number of the first business requests being the same as the number of the business requests received in real time in the interface corresponding to the original system.

[0081] In a possible implementation manner, the device further includes:

[0082] The second loop execution module is used to execute the second system migration determination process at least once until the number of the second service requests is the same as the number of the service requests received in real time in the interface corresponding to the original system; the second system migration determination process includes:

[0083] inputting the second service request into the original system and the target system respectively for processing according to the second order;

[0084] Obtaining the second test processing result and the second original processing result;

[0085] In response to the second original processing result being the same as the second test processing result, increasing the number of the second service requests based on the current number of the second service requests;

[0086] The second portability determination module is used to determine the portability of the target system based on the second test processing result and the second original processing result in response to the number of the second business requests being the same as the number of the business requests received in real time in the interface corresponding to the original system.

[0087] On the other hand, a computer device is provided, which includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the system mobility testing method provided in an embodiment of the present application.

[0088] On the other hand, a computer-readable storage medium is provided, in which at least one instruction, at least one program, code set or instruction set is stored, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the system mobility testing method provided in the above-mentioned embodiment of the present application.

[0089] On the other hand, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the system mobility test method provided in the above various optional implementations.

[0090] The beneficial effects of the technical solution provided by this application include at least:

[0091] By acquiring all or part of the online business requests received in real time in the original system as the first business request, replaying the first business request in the target system, and comparing the processing results of the first business request in the original system and the target system, the portability of the target system is determined based on the comparison results. In this way, during the system portability test, the system portability test can be performed based on the real online business requests, which expands the coverage of the test data and improves the accuracy of the target system test. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0093] Figure 1 A schematic diagram of a proxy mode shown in an exemplary embodiment of the present application is shown;

[0094] Figure 2 A schematic diagram of a mobility testing system provided by an exemplary embodiment of the present application is shown;

[0095] Figure 3 A flow chart of a system mobility testing method shown in an exemplary embodiment of the present application is shown;

[0096] Figure 4 A flow chart of a system mobility testing method shown in an exemplary embodiment of the present application is shown;

[0097] Figure 5 A flow chart of a system mobility testing method shown in an exemplary embodiment of the present application is shown;

[0098] Figure 6 A schematic diagram showing the switching of the execution order of service requests during a system migration test process shown in an exemplary embodiment of the present application is shown;

[0099] Figure 7 A schematic diagram of a mobility testing system shown in an exemplary embodiment of the present application is shown;

[0100] Figure 8 A schematic diagram of a test API proxy and a service proxy shown in an exemplary embodiment of the present application is shown;

[0101] Fig. 9 A working schematic diagram of a target system shown in an exemplary embodiment of the present application is shown;

[0102] Fig.10A structural block diagram of a system mobility testing device provided by an exemplary embodiment of the present application is shown;

[0103] Fig.11 It is a structural block diagram of a computer device according to an exemplary embodiment. DETAILED DESCRIPTION

[0104] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0105] First, a brief introduction is given to the terms involved in the embodiments of the present application:

[0106] 1) Grayscale test

[0107] Grayscale testing is to select a specific group of people to use a product or application before it is officially released, and gradually expand the number of users so that problems can be discovered and corrected in a timely manner, thereby avoiding possible risks in a timely manner.

[0108] There are two ways to perform grayscale testing. One is to use a grayscale testing release system built into the software system; the other is to use third-party tools to assist.

[0109] 2) Proxy service

[0110] Proxy is a design pattern that provides another way to access the target object, that is, access the target object through the proxy object. In this way, additional functional operations can be enhanced based on the implementation of the target object, that is, the function of the target object can be extended. Figure 1 A schematic diagram of an agent mode shown in an exemplary embodiment of the present application is shown in FIG. Figure 1 As shown, the user 110 can access the target object 130 through the proxy object 120 , and the information in the target object 130 can also be fed back to the user 110 through the proxy object 120 .

[0111] Proxies are divided into static proxies, dynamic proxies, and Cglib proxies. When using static proxies, you need to define interfaces or parent classes. The target object and the proxy object must implement the same interface or inherit the same parent class. In static proxy mode, the proxy object and the target object must implement the same interface, and then call the target object's method by calling the same method. Dynamic proxies, also known as JDK proxies and interface proxies, do not require the proxy object to implement an interface when using dynamic proxies, but the target object does. The generation of proxy objects uses the JDK API to dynamically build proxy objects in memory. Cglib proxies, also known as subclass proxies, can build a subclass object in memory to expand the functionality of the target object. Cglib proxies can implement proxies when the target object does not implement an interface.

[0112] Optionally, the proxy object can be implemented as a server; the target object can be implemented as a terminal or a server.

[0113] 3) Idempotence

[0114] Idempotence means that the same request is executed multiple times and the processing results are the same. That is, an idempotent operation can be executed any number of times and the impact will be the same.

[0115] Figure 2 A schematic diagram of a mobility testing system provided by an exemplary embodiment of the present application is shown. Figure 2 As shown, the mobility testing system 200 includes an API (Application Programming Interface) agent 201 and a data comparison tool 202 .

[0116] API proxy 201 is used to proxy the original external interface of the business system, such as Figure 2 In the embodiment of the present application, double write control and request distribution can be implemented inside the API proxy, where double write refers to whether to repeat the execution, which is manifested in the present application as executing once in the old business system (new business system) and then executing again in the new business system (old business system); double write control refers to determining which business requests that call the corresponding interface are double written and which are not; request distribution refers to which business system the business request is imported into first and which business system is imported later when double writing is performed; for example, in the group purchase order query API proxy, it supports querying group purchase orders in the old business system, and also supports querying group purchase orders in the new business system after migration.

[0117] In the embodiment of the present application, the old business system is referred to as the original system, and the new business system is referred to as the target system.

[0118] The data comparison tool 202 is used to verify the consistency of the processing results of the target system of the original system, so as to determine the portability of the target system.

[0119] Figure 3 A flow chart of a system mobility testing method according to an exemplary embodiment of the present application is shown. The method can be executed by a mobility testing system. The mobility testing system can be Figure 2 Migration test systems such as Figure 3 As shown, the method may include the following steps:

[0120] Step 310: receiving a service request in real time, wherein the service request includes a first service request, and the first service request is one of the service requests received in real time in the interface corresponding to the original system.

[0121] The original system is the business system before the business request is migrated. The relevant application programs can call the interface provided by the original system, that is, Figure 2 The original API in the target system is used to send the business request to the original system. When performing portability testing on the target system, all or part of the business requests received in real time in the interface corresponding to the original system are used as the first business request. For example, if the original system receives 10 business requests in real time, all 10 business requests can be obtained as the first business request; or, 3 of the 10 business requests can be obtained as the first business request, and the first business request is a business request for testing the portability of the target system. The number of first business requests can be adjusted according to the test requirements. The target system can be a system that is updated based on the original system, or a business system that expands its business based on the original system. The target system needs to meet the requirements of being able to realize the functions of the original system. The target system has an interface provided to the outside, namely the target API. During the portability testing of the target system, the application cannot directly call the target API to send a business request.

[0122] Illustratively, adjustment of the number of first business requests is achieved based on adjustment of the proportion of first business requests to business requests received in real time in the original system; for example, 50% of the business requests received in real time in the interface corresponding to the original system may be obtained as first business requests, or 20% of the business requests received in real time in the interface corresponding to the original system may be obtained as first business requests.

[0123] Indicatively, based on adjusting the period for obtaining service requests as first service requests, adjustment of the number of first service requests is achieved; for example, when the number of obtained first service requests is small, a service request may be obtained as a first service request every 10 minutes; when the number of obtained first service requests is large, a service request may be obtained as a first service request every 1 minute.

[0124] It should be noted that the above-mentioned method for controlling the number of first service requests is illustrative, and the present application does not limit the method for controlling the number of first service requests.

[0125] By obtaining the first business request from the business requests received in real time from the interface corresponding to the original system, the first business request relied on for the target system test can be the latest online business request. Therefore, during the target system test, even if there are business updates in the original system, the target system can be tested accordingly, thereby making the coverage of test scenarios more comprehensive. At the same time, due to the diversity of online business request types, it can be ensured that various business requests of the application can be covered when testing the target system, thereby making the test of the target system more complete.

[0126] In a possible implementation, business requests correspond to different types. For example, business requests include order requests, payment requests, refund requests, and the like.

[0127] Step 320: input the first service request into the original system and the target system respectively for processing according to the first order.

[0128] In an embodiment of the present application, the first order means that the first business request is first input into the original system, the original system processes the first business request, and then the first business request is input into the target system, and the target system processes the first business request again; or, the first business request is first input into the target system, the target system processes the first business request, and then the first business request is input into the original system, and the original system processes the first business request again.

[0129] In a possible implementation, to ensure the immediacy of the service request response, the first service request is first input into the original system, and then the first service request is input into the target system.

[0130] Step 330, obtaining a first original processing result and a first test processing result; the original processing result is a processing result obtained when the original system responds to the first business request; the first test processing result is a processing result obtained when the target system responds to the first business request.

[0131] The first business request is a general term for the business requests received in real time in the interface corresponding to the original system, which are used to test the portability of the target system. If the number of business requests received in real time in the interface corresponding to the original system is m, and the number of first business requests is n, then n≤m. Each first business request corresponds to an original processing result and a first test processing result. When testing the target system, it is necessary to ensure that the first original processing result and the first test processing result corresponding to each first business request are consistent in order to confirm the portability of the target system, so as to ensure that after the business request is migrated, the application program that depends on the original system can obtain the correct feedback result through the target system.

[0132] In a possible implementation, in response to the existence that the first original processing result corresponding to any one of the first service requests is different from the first test processing result, the corresponding fields and the corresponding values ​​are printed, and an alarm operation is performed at the same time.

[0133] Since this system migration test is based on online real-time business requests, while completing the system migration test, it is also necessary to ensure the response to online real-time business requests. In order to avoid instability in the business request processing results due to the instability of the target system, in a possible implementation method, in this embodiment, the first original processing result obtained by processing in the original system is used as the feedback result corresponding to the first business request, and the result is fed back to the corresponding application, and the first test processing result obtained by processing in the target system is stored as data for comparison, and no feedback is given to the corresponding application. For example, when the first business request is an order request, the original system responds to the order request and performs relevant processing, creates corresponding order data, and feeds back the order data to the corresponding application; then, the order request is input into the target system, and the target system also creates an order data after performing relevant processing on the order request, but for the same order request, only one corresponding processing result feedback is given to the corresponding application; if multiple result feedback is given for the same order request, for example, the order data is fed back to the user twice for the same order request, it will affect the user experience and cause system data errors. Therefore, the order data obtained by the target system is only used for data storage comparison, and the relevant feedback steps are not performed. In other words, for the same first business request, only one feedback is given to the corresponding application.

[0134] Step 340: Determine the migration feasibility of the target system based on the first original processing result and the first test processing result.

[0135] In one possible implementation, when the first business request is replayed, that is, when the first business request is re-entered into the target system for processing, due to reasons such as network transmission quality, the target system will appear to have successfully executed a processing operation based on the first business request, such as generating corresponding processing data or generating corresponding calling parameters, but the database write operation for the processing data of the processing operation, or the calling operation on the external interface based on the calling parameters corresponding to the processing operation, fails. This situation will also cause the target system's processing result for the first business request to be different from the original system's processing result for the first business request, but it does not mean that there is a problem with the target system.

[0136] In order to avoid the impact of the above situation on system testing, in a possible implementation, in response to the successful execution of the first business request in the original system and the failure of the first business request in the target system, the first business request is retried in the target system. Taking the first business request as an order request as an example, the target system has created the corresponding order data based on the order request, but has not written the corresponding data of the order data creation into the corresponding database. The first test processing result is a failure to create an order, but the original processing result is a success in creating an order. In this case, the processing result of the target system for the order request is different from the processing result of the original system for the order request, and the order request needs to be replayed and retried, that is, the order request is re-entered into the target system and reprocessed.

[0137] In one possible implementation, the test of the target system is performed continuously, that is, within a preset time period, steps such as step 310 to step 340 are continuously executed until the preset time ends. During this period, if the first original processing result corresponding to the first business request obtained in real time is always consistent with the first test processing result, it is determined that the target system can be migrated.

[0138] In summary, the system mobility test method provided by the embodiment of the present application obtains all or part of the online business requests received in real time in the interface corresponding to the original system as the first business request, inputs the first business request into the original system and the target system for processing according to a certain input order, and determines the portability of the target system based on the processing results of the first business request in the original system and the target system. Therefore, in the process of testing the system mobility, the system portability test can be performed based on the real online business requests, which expands the coverage of the test data and improves the accuracy of the test on the target system.

[0139] In a possible implementation, in a system mobility test, when processing a first service request, the first service request is first input into an original system, and then the first service request is input into a target system. Figure 4 A flow chart of a system mobility testing method according to an exemplary embodiment of the present application is shown. The method can be executed by a mobility testing system. The mobility testing system can be Figure 2 Migration test systems such as Figure 4 As shown, the method may include the following steps:

[0140] Step 410: receiving a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in the interface corresponding to the original system.

[0141] In one possible implementation, in order to ensure that the system migration test does not affect the external system, the interface provided by the migration test system to the outside is kept unchanged, that is, it is kept as the interface corresponding to the original system; for the business requests received in the interface of the original system, dual-write control and traffic distribution are performed through the API proxy to realize the migration test of the target system.

[0142] Step 420: Connect the first service request to the original system for processing.

[0143] In one possible implementation, after confirming that a business request is a first business request, the API proxy first inputs the business request into the original system for processing, and determines the time to replay the business request to the target system based on the processing progress of the business request in the original system.

[0144] Step 430: In response to the first service request in the original system being processed, the first service request is played back to the target system.

[0145] In a possible implementation, in response to the first service request in the original system being processed, the first service request is played back to the target system through the API proxy.

[0146] In response to the failure of processing the first business request in the original system, the step of replaying the first business request into the target system is stopped. Since the original system is the business system that has passed the test, if it fails to respond to the first business request, it proves that the first business request is illegal or invalid, and it is meaningless to replay it into the target system. Therefore, by using a multi-threaded method, the first business request that has been processed in the original system is asynchronously replayed into the target system, which can avoid repeated execution of illegal business requests and save processing resources of the mobility test system.

[0147] In one possible implementation, the first business request can be distributed to the original system and the target system at the same time through the API proxy, and the original system and the target system synchronously process the same first business request, but the feedback result to the external system is the processing result of the original system based on the first business request.

[0148] This application takes the asynchronous playback of the first service request as an example to illustrate the method provided by this application.

[0149] Step 440, obtain a first original processing result and a first test processing result; the first original processing result is a processing result obtained when the original system responds to the first business request; the first test processing result is a processing result obtained when the target system responds to the first business request.

[0150] In a possible implementation, the business system calls an external service based on the first business request and / or modifies data in a corresponding database based on the first business request. The business system may be an original system or a target system.

[0151] In one possible implementation, the processing result includes at least one of an interface return value fed back to a corresponding application based on the first business request, an input parameter used when calling an external service based on the first business request, and database data generated based on the first business request.

[0152] The interface return value of the business system will be fed back to the application through the API proxy. The interface return value of the business system can be obtained through the API proxy for comparison.

[0153] When the business system calls an external service based on the first business request, the business system generates input parameters used when calling the external service interface based on the first business request. When the target system is migratable, the input parameters generated by it for processing the first business request are consistent with the input parameters generated by the original system for processing the same first business request. Therefore, in order to test the portability of the target system, the consistency of the input parameters used when calling the external service interface generated by the business system based on the first business request can be compared.

[0154] In one possible implementation, in order to avoid repeated calls to external services by the original system and the target system based on the same business request during the system portability test, a service agent is set in the mobility test system to receive input parameters generated by the original system and the target system respectively based on the same business request, and access the external service based on the input parameters generated by the business request received first, and cache the access results; in response to the input parameters generated by the target system based on the business request being the same as the input parameters generated by the original system based on the business request, the cached corresponding access results are fed back to the business system that plays back the business request, thereby avoiding repeated access to external services.

[0155] During the system portability test phase based on the first business request, the original system first generates corresponding input parameters based on the first business request. The service agent accesses the external service based on the input parameters generated by the original system and caches the access results. When the input parameters generated by the target service based on the same first business request are received, if the two are the same, the service agent feeds back the cached corresponding access results to the target system to avoid repeated access to the external service.

[0156] Based on the above description, in a possible implementation, the process of obtaining the input parameters used when calling the external service interface generated by the business system based on the first business request is implemented as follows:

[0157] The service proxy obtains input parameters used by the original system when calling the external service interface based on the first business request, and input parameters used by the target system when calling the external service interface based on the first business request.

[0158] When the business system modifies the data in the corresponding database based on the first business request, the storage data related to the first business request is obtained from the original database corresponding to the original system, and the storage data related to the first business request is obtained from the target database corresponding to the target system.

[0159] Step 450 , in response to the first original processing result being the same as the first test processing result, determining that the target system is migrateable.

[0160] In a possible implementation, the number of first service requests played back in the system mobility test is gradually increased until the number of first service requests is the same as the number of service requests received in real time in the interface corresponding to the original system. The process of determining system mobility based on the first service requests is implemented as follows:

[0161] The first system migration determination process is performed at least once until the number of first service requests is the same as the number of service requests received in real time in the interface corresponding to the original system; the first system migration determination process includes:

[0162] Step 451: input the first service request into the original system and the target system respectively for processing according to the first order.

[0163] Step 452, obtaining a first original processing result and a first test processing result.

[0164] Step 453: In response to the first original processing result being the same as the first test processing result, the number of first service requests is increased based on the current number of first service requests.

[0165] That is to say, the target system is tested in stages.

[0166] In the process of testing the target system, the number of first business requests is gradually increased until the number of first business requests is the same as the number of business requests received in real time by the original system. For example, at the beginning of the test, 1% of the business requests received in real time by the original system are used as first business requests and played back into the target system. When it is confirmed that the processing results of this part of the first business requests in the target system are consistent with the processing results in the original system, the proportion of the first business requests to the business requests received in real time by the interface corresponding to the original system is gradually increased, such as 2%, 5%, 10%, 50%, and finally 100%.

[0167] If there is a problem with the target system, the problem can be exposed by testing a gradually increasing number of first business requests without replaying all business requests, thereby alleviating the testing pressure of the migration test system.

[0168] Step 454 , in response to the number of the first service requests being the same as the number of service requests received in real time in the interface corresponding to the original system, determine the migration feasibility of the target system based on the first original processing result and the first test processing result.

[0169] When the number of first business requests is the same as the number of business requests received in real time in the original system, and the processing result of each first business request in the target system corresponds to the same processing result in the original system, it is determined that the target system can be migrated.

[0170] Step 460 , in response to the first original processing result being different from the first test processing result, determining that the target system is not migratable.

[0171] Based on the above description, it can be known that the first original processing result and the first test processing result include the interface return value fed back to the corresponding application based on the first business request, the input parameters used when calling the external service based on the first business request, and at least one sub-processing result in the storage data related to the first business request in the corresponding database. When the processing result includes at least two of the above sub-processing results, when each sub-processing result in the first original processing result and the first test processing result are the same, it is confirmed that the first original processing result is the same as the first test processing result; when there is a different sub-processing result in the first original processing result and the first test processing result, it is confirmed that the first original processing result and the first test processing result are different.

[0172] In a possible implementation, in order to avoid misjudgment of system portability due to different processing results caused by network quality, in response to the first original processing result being different from the first test processing result, the first service request is replayed and retried in the target system;

[0173] Within a preset retry number threshold, in response to the first original processing result being different from the first test processing result, it is determined that the target system cannot be migrated.

[0174] In one possible implementation, a retry count threshold is set, and in response to the playback retry count reaching the retry count threshold, there is still a difference between the corresponding processing result of the target system and the corresponding processing result of the original system, and it is determined that the first original processing result and the first test processing result are different.

[0175] In one possible implementation, when the processing result corresponding to the first business request is to modify the data in the corresponding database, in response to the target system replaying the first business request, the corresponding operation has been completed, that is, the data modification operation on the corresponding database has been completed, but due to reasons such as network transmission quality, the corresponding data modification successful processing result is not returned to the target system, resulting in the target system's processing result being different from that of the original system. To avoid the above situation, the first request needs to be replayed and retried. To avoid multiple modifications to the database during replay, a method proxy is set in the mobility test system to cache the input data and return result of the replayed first business request. When the first business request is processed again, the cached return result is returned to the target system to achieve replay idempotence, thereby avoiding repeated modifications to the corresponding database.

[0176] Taking the first business request as an order request as an example, in the target system, when the order request is replayed for the first time, the deduction of inventory in response to the order request has been completed, but when the write operation of the successful inventory deduction is performed, the write is not successful, resulting in the processing result of the target system being different from that of the original system; when replaying and retrying, the target system is still required to respond to the order request, but for the same order request, the corresponding inventory is only deducted once, therefore, the result of the inventory deduction recorded in the method proxy is returned to the target system to avoid repeated deduction of inventory for the same order request.

[0177] In summary, the system mobility test method provided by the embodiment of the present application obtains the online business request received in real time in the interface corresponding to the original system as the first business request, and after the original system completes the processing of the first business request, the first business request is played back in the target system, and the portability of the target system is determined based on the processing results of the first business request in the original system and the target system. Therefore, in the process of testing the system mobility, the system portability test can be performed based on the real online business request, which expands the coverage of the test data and improves the accuracy of the test on the target system.

[0178] In order to further improve the accuracy of the target system test, Figure 3 or Figure 4 On the basis of the illustrated embodiment, a second phase of testing is added, that is, the target system first processes the second service request and then plays the second service request back to the original system for testing. Figure 5 A flow chart of a system mobility testing method according to an exemplary embodiment of the present application is shown. The method can be executed by a mobility testing system. The mobility testing system can be Figure 2 Migration test systems such as Figure 5 As shown, the method may include the following steps:

[0179] Step 510: receiving a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in the interface corresponding to the original system.

[0180] Step 520: input the first service request into the original system and the target system respectively for processing according to the first order.

[0181] Step 530, obtain a first original processing result and a first test processing result; the first original processing result is a processing result obtained when the original system responds to the first business request; the first test processing result is a processing result obtained when the target system responds to the first business request.

[0182] The steps from step 510 to step 530 can be referred to Figure 3 or Figure 4 The corresponding contents of the illustrated embodiment will not be repeated here.

[0183] Step 540, in response to the first original processing result being the same as the first test processing result, inputting the second business request into the original system and the target system for processing respectively in a second order; the second business request is at least one of the business requests received in real time in the interface corresponding to the original system, and the second order is different from the first order.

[0184] In one possible implementation, in response to the number of first business requests being the same as the number of business requests received in real time in the original system, and the first original processing result being consistent with the first test processing result, the second business requests are respectively input into the original system and the target system for processing in a second order.

[0185] That is, when the target system replays all business requests processed in real time in the original system and can achieve consistent processing results for both parties, the second business request is input into the original system and the target system respectively for processing in the second order.

[0186] In a possible implementation, in response to the first original processing result being consistent with the first test processing result within a preset time period, the second service request is input into the original system and the target system for processing according to the second sequence. That is, when the comparison results of the two sides are consistent when the processing is performed according to the first sequence, and after being maintained for a period of time, the second stage of the system test is started.

[0187] In a possible implementation, inputting the second service request into the original system and the target system for processing respectively according to the second order includes:

[0188] Connecting the second service request to the target system for processing;

[0189] In response to the second service request in the target system being processed completely, the second service request is played back to the original system.

[0190] In a possible implementation, the migration test system imports the second business request into the target system through the API proxy, that is, for the business request received through the original interface, the API proxy assigns the second business request therein to the target system for execution first, and in response to the second business request in the target system being processed, the second business request is played back to the original system. For non-second business requests in the business request, they are still assigned to the original system for processing.

[0191] Figure 6 A schematic diagram showing the switching of the execution order of service requests during a system migration test in an exemplary embodiment of the present application is shown. Figure 6 Part A in FIG. 1 shows a schematic diagram of the first stage of the system portability test, in which the original system 610 is the primary execution system and the target system 620 is the secondary execution system, that is, the API proxy first sends the first service request to the original system for processing, and when the original system completes the processing, the corresponding first service request is played back to the target system; Figure 6 Part B shows a schematic diagram of the second stage of the system portability test, in which the target system 620 is the main execution system and the original system 610 is the secondary execution system, that is, the API agent first sends the second business request to the target system for processing, and when the target system completes the processing, it plays the corresponding second business request back to the original system.

[0192] In one possible implementation, while the target system is executing the second business request first, the non-second business request processed in the original system will still be processed again in the target system. When providing feedback on the business request processing, the processing result of the business system that first processes the business request will be fed back, or the processing result of the business request by the original system will be fed back.

[0193] Among them, the primary execution system is the business system that processes the business request first, and the secondary execution system is the business system that processes the business request later.

[0194] Step 550, obtain a second test processing result and a second original processing result; the second original processing result is a processing result obtained by the original system in response to the second business request; the second test processing result is a processing result obtained by the target system in response to the second business request.

[0195] The steps of obtaining the second target processing result and the second original processing result can refer to Figure 3 or Figure 4The description of obtaining the first original processing result and the first target processing result in the illustrated embodiment will not be repeated here.

[0196] In one possible implementation, in the second stage of system testing, the processing result of the target system on the second business request can be used as the processing result of external feedback, or the processing result of the original processing playback of the second business request can be used as the processing result of external feedback. This application does not impose any restrictions on this.

[0197] Step 560: Determine the migration feasibility of the target system based on the second test processing result and the second original processing result.

[0198] In a possible implementation, in response to the second test processing result being the same as the second original processing result, it is determined that the target system is migrateable.

[0199] In a possible implementation, in the system mobility test, the number of the second service requests played back is gradually increased until the number of the second service requests is the same as the number of service requests received in real time in the interface corresponding to the original system. The process of determining the system mobility based on the second service requests is implemented as follows:

[0200] Performing at least one second system migration determination process until the number of the second service requests is the same as the number of service requests received in real time in the interface corresponding to the original system; the second system migration determination process includes:

[0201] Step 561: Input the second service request to the original system and the target system for processing in a second order, wherein the second order is different from the first order.

[0202] Step 562, obtaining the second test processing result and the second original processing result.

[0203] Step 563: In response to the second original processing result being the same as the second test processing result, the number of second service requests is increased based on the current number of second service requests.

[0204] Step 564 , in response to the number of the second service requests being the same as the number of service requests received in real time in the interface corresponding to the original system, determine the migration feasibility of the target system based on the second test processing result and the second original processing result.

[0205] In a possible implementation, in response to the second test processing result being different from the second original processing result, it is determined that the target system cannot be migrated.

[0206] In a possible implementation, in order to avoid the situation where the second test processing result is different from the second original processing result due to a network quality problem, in response to the second original processing result being different from the second test processing result, the second service request is replayed and retried in the original system;

[0207] In response to the second original processing result being different from the second test processing result within a preset retry number threshold, it is determined that the target system cannot be migrated.

[0208] The process of the original system replaying and retrying the second test request can be referred to Figure 4 In the illustrated embodiment, the process of the target system replaying and retrying the first test request is not described in detail here.

[0209] During the playback and retry process of the second test request, if the processing result corresponding to the second business request is to modify the data in the corresponding database, in response to the original system replaying the second business request, its corresponding operation has been completed, that is, its modification of the data in the corresponding database has been completed, but due to reasons such as network transmission quality, the corresponding data modification success result is not returned to the original system, resulting in the processing result of the original system being different from that of the target system. The second request needs to be replayed and retried. At this time, the method proxy will return the cached return result related to the second business request to the original system, so as to achieve playback idempotence and avoid multiple modifications to the database.

[0210] In a possible implementation, the system mobility testing system compares the original processing result with the target processing result through a data comparison tool.

[0211] In one possible implementation, different order numbers are generated in the original system and the target system for the same target business request. In order to associate the orders between the two, a playback request mark is set in the order generated by the system that plays back the target business request to establish a mapping relationship between the order number in the original system and the order number in the target system, that is, the order number of the target system can be queried through the order number of the original system, and the order number of the original system can be queried through the order number of the target system.

[0212] In one possible implementation, when comparing the original processing results with the target processing, it is possible to configure to exclude fields that do not need to be compared. For example, different order numbers are generated in the original system and the target system for the same target business request. If the two are compared, the comparison results will indicate inconsistencies. However, there is a corresponding mapping relationship between the two order numbers, corresponding to the same target business request. If this is used as a comparison field, it will affect the system portability test. Therefore, the order number can be obtained as a field that does not need to be compared.

[0213] In one possible implementation, due to the different data storage formats in the original system and the target system, the comparison results for the same content may indicate inconsistencies. For example, for the same content, the storage format in the target system is json string, while the storage format in the original system is json. For example, for the amount data storage, for a 1-yuan transaction, due to the different data storage formats, it is stored as 1.00 in the database corresponding to the target system, while it is stored as 1.0 in the database corresponding to the original system. Both are used to store 1-yuan transactions, but the different storage formats may cause the comparison results to indicate inconsistencies. Based on the above situation, the data comparison tool can be used to unify the data format before comparison to avoid misjudgment of the comparison results due to inconsistent data storage formats.

[0214] In summary, the system mobility test method provided by the embodiment of the present application obtains all or part of the online business requests received in real time in the interface corresponding to the original system as the first business request, replays the first business request in the target system, compares the processing results of the target business request in the original system and the target system respectively, gradually increases the proportion of the first business request in the online business requests received in real time in the interface corresponding to the original system in the above process, tests the target system to different degrees, and after determining that the target system replays the first business request correctly, in the process of gradually transferring the business request to the target system, replays and records the business requests processed by the target system in the original system, further tests are performed, and the portability of the target system is determined based on the comparison results. Thereby, in the process of testing the system mobility, the portability test of the system can be performed based on real online business requests, which expands the coverage of the test data and improves the accuracy of the test on the target system.

[0215] At the same time, in the second testing phase, when problems arise in the target system, since all business request data is saved in the original system, the business request can be switched to the original system for processing in a timely manner. Therefore, the security of the business system's external business is improved during the system testing process.

[0216] Please refer to Figure 7 , which shows a schematic diagram of a migration test system shown in an exemplary embodiment of the present application, such as Figure 7 As shown, the mobility testing system 700 is composed of an API agent 701 , a method agent 702 , a service agent 703 and a data comparison tool 704 .

[0217] The API agent 701 is used to input the first business request into the original system and the target system respectively for processing in a first order; the first business request is at least one of the business requests received in real time in the interface corresponding to the original system.

[0218] The API agent is also used to input the second business request into the original system and the target system for processing respectively in a second order in response to the first original processing result being the same as the first test processing result; the second business request is at least one of the business requests received in real time in the interface corresponding to the original system, and the second order is different from the first order.

[0219] The method agent 702 is used to record the operation result corresponding to the business request in response to the existence of an operation result corresponding to the business request when the processing result corresponding to the business request is to modify the data in the corresponding database; in response to replaying and retrying the first business request, give the same operation result to the business system that replays and retryes the business request, so that the system that replays and retryes the business request can obtain the corresponding processing result based on the operation result, thereby avoiding repeated modification of the database based on the same business request.

[0220] The service agent 703 is used to call the external service interface according to the input parameters to access the external service related to the first business request when the processing result corresponding to the business request is to generate the input parameters used when calling the external service interface;

[0221] At the same time, the feedback result of the external service is recorded, and in response to receiving the same input parameters sent by the business system for replaying the business request, the feedback result is returned to the business system for replaying the business request.

[0222] During the system testing process, the external service corresponding to the same type of business request in the original system and the target system is the same external service. For example, the original system needs to call the cashier service after processing the first business request, and the target system also needs to call the cashier service after processing the first business request. However, for the same business request, the external service should only respond once. If the same business request is responded to twice, it will affect the external system. Therefore, in order to avoid the impact of system testing on external services, the migration test system records the feedback results of the external service through the service agent. When receiving the same input parameters sent by the system that replays the business request, the corresponding feedback results are directly returned to the system that replays the business request without executing the call operation to the external service again, thereby not affecting the normal operation of the external service.

[0223] The data comparison tool 704 is used to determine the portability of the target system based on a first original processing result and a first test processing result. The first original processing result is a processing result obtained by the original system in response to a first business request; the first test processing result is a processing result obtained by the target system in response to the first business request; based on the first original processing result and the first test processing result, determine the portability of the target system.

[0224] The data comparison tool 704 is also used to determine the portability of the target system based on the second test processing result and the second original processing result, the second original processing result being the processing result obtained by the original system in response to the second business request; the second test processing result is the processing result obtained by the target system in response to the second business request; based on the second test processing result and the second original processing result, determine the portability of the target system.

[0225] In a possible implementation, the migration test system needs to perform grayscale testing on the API proxy and the service proxy before introducing the API proxy and the service proxy. Figure 8 A schematic diagram of a test API proxy and a service proxy shown in an exemplary embodiment of the present application is shown. Figure 8 As shown, Figure 8 Part A in the figure shows the working diagram of the original system, taking the application as an example. Figure 8 As shown in part A of the figure, the application sends the business request to the original system by calling the original API, and the original system modifies the stored data in its corresponding database and / or calls external services based on the business request. Figure 8 Part B in FIG. 1 shows a schematic diagram of testing the API proxy, such as Figure 8 As shown in part B of the figure, some of the business requests received by the original API are grayed out to the API proxy 810, and the API proxy 810 is monitored to see whether it can send these business requests to the original system. If it can be achieved, all business requests received through the original API interface are sent to the original system through the API proxy 810, that is, Figure 8 As shown in part C. Figure 8 Part C in FIG. 1 shows a schematic diagram of testing a service agent, such as Figure 8 As shown in part C of the figure, part of the calling steps of the original system calling external services based on business requests are grayed out in the service agent 820, which is manifested as the original system calling external services through the service agent 820 based on business requests. The service agent 820 is tested to be able to implement this part of the calling steps. If it can be implemented, the process of the original system calling external services based on business requests is replaced with the process of the original system calling external services based on business requests through the service agent 820, so as to prepare for the test of the target system.

[0226] In summary, the migration test system provided by the embodiment of the present application obtains all or part of the online business requests received in real time in the original system as the first business request, replays the first business request in the target system, compares the processing results of the first business request in the original system and the target system, and determines the migration of the target system based on the comparison results. Therefore, in the process of testing the migration of the system, the migration test of the system can be carried out based on the real online business requests, which expands the coverage of the test data and improves the accuracy of the test on the target system.

[0227] After the target system passes the system migration test, the target system is used to replace the original system, and the original system and related proxy services are taken offline to complete the system migration. Figure 8 The working diagram of the original system shown in part A. Fig. 9 FIG. 1 shows a schematic diagram of the operation of the target system shown in an exemplary embodiment of the present application, taking an application as an example. Fig. 9 As shown, the application sends a business request to the target system 910 by calling the target API corresponding to the target system. The target system modifies the stored data in its corresponding database and / or calls external services based on the business request, thereby completing the system migration.

[0228] Please refer to Fig.10 , which shows a structural block diagram of a system mobility testing device provided by an exemplary embodiment of the present application, the device is applied to a mobility testing system, and the mobility testing system can be Figure 2 Migration test systems such as Fig.10 As shown, the device comprises:

[0229] A service request receiving module 1010 is used to receive a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in the interface corresponding to the original system;

[0230] A first business request processing module 1020, configured to input the first business request into an original system and a target system for processing in a first order;

[0231] The first processing result acquisition module 1030 is used to acquire a first original processing result and a first test processing result; the first original processing result is a processing result obtained by the original system in response to the first service request; the first test processing result is a processing result obtained by the target system in response to the first service request;

[0232] The first portability determination module 1040 is configured to determine the portability of the target system based on the first original processing result and the first test processing result.

[0233] In a possible implementation, the first service request processing module 1020 includes:

[0234] A first service request processing submodule, used to connect the first service request to the original system for processing;

[0235] The second service request processing submodule is used to respond to the first service request in the original system having been processed and to play the first service request back to the target system.

[0236] In a possible implementation, the second service request processing submodule is used to respond to the first service request in the original system having been processed, and to replay the first service request to the target system through an application program interface (API) proxy.

[0237] In a possible implementation, the first portability determination module 1040 includes:

[0238] A first migration determination submodule, configured to determine that the target system is migrateable in response to the first original processing result being the same as the first test processing result;

[0239] The second migration determination submodule is used to determine that the target system is not migration-capable in response to the first original processing result being different from the first test processing result.

[0240] In a possible implementation, the device further includes:

[0241] a second business request processing module, configured to, in response to the first original processing result being the same as the first test processing result, input the second business request into the original system and the target system for processing in a second order; the second business request is at least one of the business requests received in real time in the interface corresponding to the original system, and the second order is different from the first order;

[0242] The second processing result acquisition module is used to obtain a second test processing result and a second original processing result; the second original processing result is a processing result obtained by the original system in response to the second business request; the second test processing result is a processing result obtained by the target system in response to the second business request;

[0243] The second portability determination module is used to determine the portability of the target system based on the second test processing result and the second original processing result.

[0244] In a possible implementation, the second service request processing module includes:

[0245] A third service request processing submodule is used to connect the second service request to the target system for processing;

[0246] The fourth service request processing submodule is configured to, in response to the second service request in the target system having been processed, replay the second service request to the original system.

[0247] In a possible implementation, the first portability determination module 1040 further includes:

[0248] A first playback and retry submodule, configured to, in response to the first original processing result being different from the first test processing result, replay and retry the first service request in the target system;

[0249] The second migration feasibility determination submodule is used to determine that the target system is not migrateable in response to the first original processing result being different from the first test processing result within a preset retry number threshold.

[0250] In a possible implementation, the second portability determination module further includes:

[0251] A second playback and retry submodule, configured to, in response to the second original processing result being different from the second test processing result, playback and retry the second service request in the original system;

[0252] The fourth migration submodule is used to determine that the target system is not migrateable in response to the second original processing result being different from the second test processing result within a preset retry number threshold.

[0253] In a possible implementation, the device further includes:

[0254] The first loop execution module is used to execute the first system migration determination process at least once until the number of first service requests is the same as the number of service requests received in real time in the interface corresponding to the original system; the first system migration determination process includes:

[0255] Inputting the first business request into the original system and the target system respectively for processing according to the first order;

[0256] Obtaining a first original processing result and a first test processing result;

[0257] In response to the first original processing result being the same as the first test processing result, increasing the number of first service requests based on the current number of first service requests;

[0258] The first portability determination module 1040 is used to determine the portability of the target system based on the first original processing result and the first test processing result in response to the number of first business requests being the same as the number of business requests received in real time in the interface corresponding to the original system.

[0259] In a possible implementation, the device further includes:

[0260] The second loop execution module is used to execute the second system migration determination process at least once until the number of second service requests is the same as the number of service requests received in real time in the interface corresponding to the original system; the second system migration determination process includes:

[0261] inputting the second business request into the original system and the target system respectively for processing according to the second order;

[0262] Obtaining a second test processing result and a second original processing result;

[0263] In response to the second original processing result being the same as the second test processing result, increasing the number of second service requests based on the current number of second service requests;

[0264] The second portability determination module is used to determine the portability of the target system based on the second test processing result and the second original processing result in response to the number of second business requests being the same as the number of business requests received in real time in the interface corresponding to the original system.

[0265] In summary, the system mobility testing device provided in the embodiment of the present application is applied to the mobility testing system, by obtaining all or part of the online business requests received in real time in the original system as the first business request, replaying the first business request in the target system, comparing the processing results of the first business request in the original system and the target system respectively, and determining the portability of the target system based on the comparison results. Therefore, in the process of testing the system mobility, the system portability test can be performed based on the real online business requests, which expands the coverage of the test data and improves the accuracy of the test on the target system.

[0266] Fig.11 1 is a structural block diagram of a computer device 1100 according to an exemplary embodiment. The computer device can be implemented as an API agent, a method agent, a service agent, and a data comparison tool in the mobility test system in the above solution of the present application.

[0267] The computer device 1100 includes a central processing unit (CPU) 1101, a system memory 1104 including a random access memory (RAM) 1102 and a read-only memory (ROM) 1103, and a system bus 1105 connecting the system memory 1104 and the central processing unit 1101. The computer device 1100 also includes a basic input / output system (I / O system) 1106 for facilitating information transmission between various components in the computer, and a large-capacity storage device 1107 for storing an operating system 1113, application programs 1114, and other program modules 1115.

[0268] The basic input / output system 1106 includes a display 1108 for displaying information and an input device 1109 such as a mouse and a keyboard for user inputting information. The display 1108 and the input device 1109 are connected to the central processing unit 1101 through an input / output controller 1110 connected to the system bus 1105. The basic input / output system 1106 may also include an input / output controller 1110 for receiving and processing inputs from a plurality of other devices such as a keyboard, a mouse, or an electronic stylus. Similarly, the input / output controller 1110 also provides output to a display screen, a printer, or other types of output devices.

[0269] The mass storage device 1107 is connected to the central processing unit 1101 through a mass storage controller (not shown) connected to the system bus 1105. The mass storage device 1107 and its associated computer readable medium provide non-volatile storage for the computer device 1100. That is, the mass storage device 1107 may include a computer readable medium (not shown) such as a hard disk or a compact disc read-only memory (CD-ROM) drive.

[0270] Without loss of generality, the computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, Erasable Programmable Read Only Memory (EPROM), Electronically-Erasable Programmable Read-Only Memory (EEPROM), flash memory or other solid-state storage technology, CD-ROM, Digital Versatile Disc (DVD) or other optical storage, cassettes, tapes, disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that the computer storage medium is not limited to the above. The above-mentioned system memory 1104 and mass storage device 1107 can be collectively referred to as memory.

[0271] According to various embodiments of the present application, the computer device 1100 can also be connected to a remote computer on the network through a network such as the Internet. That is, the computer device 1100 can be connected to the network 1112 through the network interface unit 1111 connected to the system bus 1105, or the network interface unit 1111 can be used to connect to other types of networks or remote computer systems (not shown).

[0272] The memory also includes one or more programs, which are stored in the memory. The CPU 1101 implements the Figure 3 Figure 4 or Figure 5 All or part of the steps of the method shown.

[0273] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented with hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein the communication media include any media that facilitates the transmission of a computer program from one place to another. The storage medium can be any available medium that a general or special-purpose computer can access.

[0274] The embodiment of the present application also provides a computer-readable storage medium for storing at least one instruction, at least one program, code set or instruction set, wherein the at least one instruction, the at least one program, the code set or instruction set is loaded and executed by a processor to implement the above-mentioned system mobility test method. For example, the computer-readable storage medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0275] The embodiment of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes all or part of the steps of the system mobility test method shown in the above embodiments.

[0276] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0277] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A system mobility testing method, characterized in that: The method is performed by a mobility testing system, and the method comprises: receiving a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in the interface corresponding to the original system; inputting the first service request into the original system and the target system respectively for processing in a first order, connecting the first service request to the original system for processing, and in response to the first service request in the original system having been processed, replaying the first service request to the target system through an application program interface (API) proxy; The method proxy is used to cache the input data and return result of the replayed first business request, and when the first business request is processed again, the cached return result is returned to the target system; the service proxy accesses the external service based on the input parameters generated by the original system, caches the access result, and when receiving the input parameters generated by the target service based on the same first business request, if the two are the same, the service proxy feeds back the cached corresponding access result to the target system; Acquire a first original processing result and a first test processing result; the first original processing result is a processing result obtained by the original system in response to the first service request; the first test processing result is a processing result obtained by the target system in response to the first service request; In response to the first original processing result being the same as the first test processing result, determining that the target system is migrateable; in response to the first original processing result being different from the first test processing result, determining that the target system is not migrateable; The first original processing result and the first test processing result include an interface return value fed back to the corresponding application program based on the first business request, an input parameter used when calling an external service based on the first business request, and at least one sub-processing result in the stored data related to the first business request in the corresponding database; The interface return values ​​of the original system and the target system are obtained for comparison to obtain a first sub-processing result; the input parameters used by the original system when calling the external service interface based on the first business request, and the input parameters used by the target system when calling the external service interface based on the first business request, are obtained for comparison to obtain a second sub-processing result; the storage data related to the first business request is obtained from the original database corresponding to the original system, and the storage data related to the first business request is obtained from the target database corresponding to the target system, for comparison to obtain a third sub-processing result; When the processing result includes at least two of the above-mentioned sub-processing results, when the first original processing result and the first test processing result have the same corresponding sub-processing results, it is confirmed that the first original processing result is the same as the first test processing result; when there is one sub-processing result that is different between the first original processing result and the first test processing result, it is confirmed that the first original processing result is different from the first test processing result.

2. The method according to claim 1, characterized in that In response to the first original processing result being the same as the first test processing result, the method further includes: inputting the second service request into the original system and the target system respectively for processing in a second order; the second service request is at least one of the service requests received in real time in the interface corresponding to the original system, and the second order is different from the first order; Acquire a second test processing result and a second original processing result; the second original processing result is a processing result obtained by the original system in response to the second service request; the second test processing result is a processing result obtained by the target system in response to the second service request; Based on the second test processing result and the second original processing result, the migration feasibility of the target system is determined.

3. The method according to claim 2, characterized in that The step of inputting the second service request into the original system and the target system respectively for processing in the second order includes: Connecting the second service request to the target system for processing; In response to the second service request in the target system being processed completely, the second service request is played back to the original system.

4. The method according to claim 1, characterized in that The method further comprises: In response to the first original processing result being different from the first test processing result, replaying and retrying the first service request in the target system; Within a preset retry number threshold, in response to the first original processing result being different from the first test processing result, it is determined that the target system cannot be migrated.

5. The method according to claim 2 or 3, characterized in that: The method further comprises: In response to the second original processing result being different from the second test processing result, replaying and retrying the second service request in the original system; Within a preset retry number threshold, in response to the second original processing result being different from the second test processing result, it is determined that the target system cannot be migrated.

6. The method according to claim 1, characterized in that The method further comprises: Performing at least one first system migration determination process until the number of the first service requests is the same as the number of the service requests received in real time in the interface corresponding to the original system; the first system migration determination process includes: Obtaining the first original processing result and the first test processing result; In response to the first original processing result being the same as the first test processing result, increasing the number of the first service requests based on the current number of the first service requests; The determining the migration feasibility of the target system based on the first original processing result and the first test processing result includes: In response to the number of the first service requests being the same as the number of the service requests received in real time in the interface corresponding to the original system, the migration feasibility of the target system is determined based on the first original processing result and the first test processing result.

7. The method according to any one of claims 2 or 3, characterized in that: The method further comprises: Performing at least one second system migration determination process until the number of the second service requests is the same as the number of the service requests received in real time in the interface corresponding to the original system; the second system migration determination process includes: inputting the second service request into the original system and the target system respectively for processing according to the second order; Obtaining the second test processing result and the second original processing result; In response to the second original processing result being the same as the second test processing result, increasing the number of the second service requests based on the current number of the second service requests; The determining the migration feasibility of the target system based on the second test processing result and the second original processing result includes: In response to the number of the second service requests being the same as the number of the service requests received in real time in the interface corresponding to the original system, the migration feasibility of the target system is determined based on the second test processing result and the second original processing result.

8. A migration test system, characterized in that: The system includes: an application program interface API agent, a method agent and a service agent, and a data comparison tool; The API proxy is used to input the first business request into the original system and the target system respectively for processing in a first order, connect the first business request to the original system for processing, and in response to the first business request in the original system being processed, play the first business request back to the target system through the API proxy; the first business request is at least one of the business requests received in real time in the interface corresponding to the original system; The method proxy is used to cache the input data and return result of the replayed first business request, and when the first business request is processed again, the cached return result is returned to the target system; The service agent accesses the external service based on the input parameters generated by the original system, caches the access results, and when receiving the input parameters generated by the target service based on the same first business request, if the two are the same, the service agent feeds back the cached corresponding access results to the target system; The data comparison tool is used to determine the portability of the target system based on a first original processing result and a first test processing result, wherein the first original processing result is a processing result obtained by the original system in response to the first service request; and the first test processing result is a processing result obtained by the target system in response to the first service request; In response to the first original processing result being the same as the first test processing result, determining that the target system is migrateable; in response to the first original processing result being different from the first test processing result, determining that the target system is not migrateable; The first original processing result and the first test processing result include an interface return value fed back to the corresponding application program based on the first business request, an input parameter used when calling an external service based on the first business request, and at least one sub-processing result in the stored data related to the first business request in the corresponding database; The interface return values ​​of the original system and the target system are obtained for comparison to obtain a first sub-processing result; the input parameters used by the original system when calling the external service interface based on the first business request, and the input parameters used by the target system when calling the external service interface based on the first business request, are obtained for comparison to obtain a second sub-processing result; the storage data related to the first business request is obtained from the original database corresponding to the original system, and the storage data related to the first business request is obtained from the target database corresponding to the target system, for comparison to obtain a third sub-processing result; When the processing result includes at least two of the above-mentioned sub-processing results, when the first original processing result and the first test processing result have the same corresponding sub-processing results, it is confirmed that the first original processing result is the same as the first test processing result; when there is one sub-processing result that is different between the first original processing result and the first test processing result, it is confirmed that the first original processing result is different from the first test processing result.

9. The system according to claim 8, characterized in that The API agent is configured to, in response to the first original processing result being the same as the first test processing result, input a second business request into the original system and the target system respectively for processing in a second order; The second service request is at least one of the service requests received in real time in the interface corresponding to the original system, and the second sequence is different from the first sequence; The data comparison tool is used to determine the migration feasibility of the target system based on the second test processing result and the second original processing result, where the second original processing result is a processing result obtained by the original system in response to the second service request; The second test processing result is a processing result obtained by the target system responding to the second service request.

10. A system mobility testing device, characterized in that: The device is applied to a mobility testing system, and comprises: A service request receiving module, configured to receive a service request in real time, wherein the service request includes a first service request, and the first service request is at least one of the service requests received in real time in an interface corresponding to an original system; A first business request processing module is used to input the first business request into the original system and the target system respectively for processing in a first order, connect the first business request to the original system for processing, and in response to the first business request in the original system having been processed, replay the first business request to the target system through an application program interface API proxy; cache the input data and return result of the replayed first business request through a method proxy, and when the first business request is processed again, return the cached return result to the target system; access external services based on input parameters generated by the original system through a service proxy, cache access results, and when receiving input parameters generated by a target service based on the same first business request, if the two are the same, feed back the cached corresponding access results to the target system; A first processing result acquisition module is used to acquire a first original processing result and a first test processing result; the first original processing result is a processing result obtained by the original system in response to the first business request; the first test processing result is a processing result obtained by the target system in response to the first business request; the first original processing result and the first test processing result include an interface return value fed back to the corresponding application based on the first business request, an input parameter used when calling an external service based on the first business request, and at least one sub-processing result of storage data related to the first business request in the corresponding database; the first processing result acquisition module is used to acquire the interface return values ​​of the original system and the target system for comparison to obtain the first sub-processing result, acquire the input parameters used when the original system calls the external service interface based on the first business request, and the input parameters used when the target system calls the external service interface based on the first business request, for comparison to obtain the second sub-processing result, and acquire the storage data related to the first business request from the original database corresponding to the original system, and acquire the storage data related to the first business request from the target database corresponding to the target system, for comparison to obtain the third sub-processing result; A first portability determination module is used to determine the portability of the target system based on the first original processing result and the first test processing result; in response to the first original processing result being the same as the first test processing result, determine that the target system is migratable; in response to the first original processing result being different from the first test processing result, determine that the target system is not migratable; when the processing result includes at least two of the above-mentioned sub-processing results, when the first original processing result and the first test processing result have the same corresponding sub-processing results, confirm that the first original processing result is the same as the first test processing result; when there is one sub-processing result that is different between the first original processing result and the first test processing result, confirm that the first original processing result is different from the first test processing result.

11. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the system mobility testing method as described in any one of claims 1 to 7.

12. A computer-readable storage medium, characterized in that: The readable storage medium stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the system mobility testing method as described in any one of claims 1 to 7.

Images