A system verification method, device, equipment, storage medium and program product
By statistically analyzing and setting the proportion of requests sent to each request object, and extracting test requests for consistency verification, the problem of input limitations in the refactored system was solved, and the accuracy of system consistency verification was improved.
Patent Information
- Application Number
- CN202210523528.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-13
- Publication Date
- 2026-08-25
- Estimated Expiration
- 2042-05-13
AI Technical Summary
The input of the reconstructed system in the existing technology has limitations, resulting in low accuracy of system consistency verification and failure to fully cover the request characteristics of the access object.
By counting the number of requests sent to each request object and setting a request extraction ratio, test requests are extracted from real business requests and input into the system to be verified for consistency verification.
It improves the accuracy of system consistency verification, ensures that the input of the system to be verified covers the request characteristics of all request sending objects, and breaks the input limitations of the reconstructed system.
Smart Images

Figure CN117093469B_ABST
Abstract
Description
Technical Field
[0001] This application relates to cloud computing technology, and more particularly to a system verification method, apparatus, device, storage medium, and program product. Background Technology
[0002] With the development of cloud computing, more and more application processing and computing processes are implemented in backend service systems. However, in actual business, due to reasons such as code redundancy and function updates, it is necessary to refactor the backend service systems. The refactored system needs to pass consistency verification, that is, to ensure that the processing logic of the refactored system is consistent with that of the original service system before it can be put into use.
[0003] However, in related technologies, when performing consistency verification on a reconstructed system, there are limitations in the input of the reconstructed system, which ultimately results in low accuracy of the system consistency verification. Summary of the Invention
[0004] This application provides a system verification method, apparatus, device, computer-readable storage medium, and program product, which can improve the accuracy of system consistency verification.
[0005] The technical solution of this application embodiment is implemented as follows:
[0006] This application provides a system verification method, including:
[0007] The number of business requests sent by each request sending object to the baseline system is counted to obtain the number of requests for each request sending object;
[0008] Based on the number of requests for each of the request sending objects, a request extraction ratio is set for each of the request sending objects;
[0009] Based on the aforementioned request extraction ratio, test requests for the system to be verified are extracted from the business requests of each of the request sending objects; the system to be verified is reconstructed from the baseline system.
[0010] The test request is input into the system to be verified, and the processing result of the system to be verified in response to the test request is collected.
[0011] Based on the processing results and the benchmark results of the benchmark system for the test request, the consistency verification between the system to be verified and the benchmark system is performed to obtain the verification results.
[0012] This application provides a system verification device, including:
[0013] The quantity statistics module is used to count the number of business requests sent by each request sending object to the baseline system, and obtain the number of requests for each request sending object;
[0014] The ratio setting module is used to set the request extraction ratio for each request sending object based on the number of requests for each request sending object.
[0015] The request extraction module is used to extract test requests for the system to be verified from the business requests of each request sending object based on the request extraction ratio; the system to be verified is reconstructed from the benchmark system.
[0016] The request processing module is used to input the test request into the system to be verified and to collect the processing results of the system to be verified in response to the test request.
[0017] The result verification module is used to perform consistency verification between the system to be verified and the benchmark system based on the processing result and the benchmark result of the benchmark system for the test request, and obtain the verification result.
[0018] In some embodiments of this application, the ratio setting module is further configured to: set the request extraction ratio of the request sending object to a fixed ratio when the number of requests of the request sending object is less than or equal to a first threshold; and set the request extraction ratio for the request sending object based on the number of requests and the first threshold when the number of requests of the request sending object is greater than the first threshold and less than or equal to a second threshold; wherein the second threshold is greater than the first threshold; and set the request extraction ratio for the request sending object based on the number of requests when the number of requests of the request sending object is greater than the second threshold.
[0019] In some embodiments of this application, the ratio setting module is further configured to normalize the first threshold using the number of requests to obtain a normalized value, and set the normalized value as the request extraction ratio.
[0020] In some embodiments of this application, the ratio setting module is further configured to normalize the square root of the number of requests using the number of requests to obtain an initial extraction ratio; reduce the initial extraction ratio and set the reduced initial extraction ratio as the request extraction ratio.
[0021] In some embodiments of this application, the quantity statistics module is further configured to parse the multiple network requests received by the benchmark system to obtain the identity identifier corresponding to each network request; and based on the correspondence between the identity identifier and the request sending object, to filter out the service request of each request sending object from the multiple network requests.
[0022] In some embodiments of this application, the system verification device further includes: a data retrieval module; the data retrieval module is used to submit a data request script to the data management platform corresponding to the benchmark system; the data request script is used to retrieve the request log of the benchmark system; and the request log returned by the data management platform in response to the data request script is parsed to obtain the multiple network requests received by the benchmark system.
[0023] In some embodiments of this application, the result verification module is further configured to generate a verification result indicating consistency between the system to be verified and the benchmark system when the processing result is the same as the benchmark result of the benchmark system for the test request, thereby completing the consistency verification between the system to be verified and the benchmark system; and to generate a verification result indicating inconsistency between the system to be verified and the benchmark system when the processing result is different from the benchmark result of the benchmark system for the test request, thereby completing the consistency verification between the system to be verified and the benchmark system.
[0024] In some embodiments of this application, the request extraction module is further configured to randomly generate sampling coefficients for the business requests from the coefficient generation interval; normalize the sampling coefficients using the maximum value of the coefficient generation interval to obtain a normalization ratio; and determine the business requests whose normalization ratio is less than or equal to the request extraction ratio as the test requests.
[0025] In some embodiments of this application, the system verification device further includes: an information registration module; the information registration module is used to register authentication information and signature verification information for the test request in the relay service of the system to be verified, so that the system to be verified can obtain the authentication information and signature verification information from the relay service in response to the test request, and process the test request in response to the authentication information and signature verification information.
[0026] In some embodiments of this application, the system verification device further includes: a system adjustment module; the system adjustment module is used to parse the test request when the verification result indicates that the system to be verified and the benchmark system are inconsistent, to obtain compatibility anomaly information between the system to be verified and the benchmark system; the compatibility anomaly information indicates that the benchmark system is compatible and the system to be verified is incompatible; based on the compatibility anomaly information, adjustments are made to the compatibility of the system to be verified to obtain the adjusted system.
[0027] In some embodiments of this application, the system adjustment module is further configured to add an anomaly prompt function to the system to be verified based on the compatibility anomaly information, thereby obtaining an adjusted system; the anomaly prompt function is used to generate a modification prompt based on the compatibility anomaly information.
[0028] This application provides a system verification device, including:
[0029] Memory, used to store executable instructions;
[0030] The processor, when executing executable instructions stored in the memory, implements the system verification method provided in the embodiments of this application.
[0031] This application provides a computer-readable storage medium storing executable instructions for implementing the system verification method provided in this application when executed by a processor.
[0032] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the system verification method provided in this application.
[0033] The embodiments of this application have the following beneficial effects: The system verification device can determine the corresponding request extraction ratio for each request sending object based on the number of requests made by each request sending object to the benchmark system. Then, according to the request extraction ratio, test requests are extracted from the real business requests of each request sending object. This ensures that the input of the system to be verified can not only cover the real business requests of each request sending object, but also cover the request characteristics of all request sending objects. This breaks the limitation problem of the input of the system to be verified obtained by reconstruction, and thus improves the accuracy of system consistency verification. Attached Figure Description
[0034] Figure 1 This is a schematic diagram of the system verification system provided in the embodiments of this application;
[0035] Figure 2 This is provided by the embodiments of this application. Figure 1A schematic diagram of the server structure in the diagram;
[0036] Figure 3 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 1 ;
[0037] Figure 4 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 2 ;
[0038] Figure 5 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 3 ;
[0039] Figure 6 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 4 ;
[0040] Figure 7 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 5 ;
[0041] Figure 8 This is a schematic diagram illustrating the process of verifying and authenticating requests through a proxy relay provided in this application embodiment. Detailed Implementation
[0042] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0043] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0044] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.
[0045] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0046] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.
[0047] 1) Cloud computing refers to the delivery and usage model of IT infrastructure, meaning obtaining necessary resources in an on-demand and easily scalable manner through a network. In a broader sense, cloud computing also refers to the delivery and usage model of services, meaning obtaining necessary services in an on-demand and easily scalable manner through a network. These services can be IT and software related, internet-related, or other services. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.
[0048] With the development of the internet, real-time data streams, the diversification of connected devices, and the driving force of demands for search services, social networks, mobile commerce, and open collaboration, cloud computing has rapidly developed. Unlike previous parallel distributed computing, cloud computing will revolutionize the entire internet model and enterprise management model from a conceptual standpoint.
[0049] 2) Big Data refers to data sets that cannot be captured, managed, and processed within a certain timeframe using conventional software tools. It represents massive, rapidly growing, and diverse information assets that require novel processing models to achieve stronger decision-making, insightful discovery, and process optimization capabilities. With the advent of the cloud era, Big Data has attracted increasing attention. Big Data requires specialized technologies to effectively process large amounts of data within a tolerable timeframe. Technologies utilizing Big Data include massively parallel processing databases, data mining, distributed file systems, distributed databases, cloud computing platforms, the Internet, and scalable storage systems.
[0050] 3) A big data platform is a network platform that provides services through content sharing, resource supply, channel co-construction, and data sharing. Big data platforms can provide processing frameworks such as commonly used data warehouses (e.g., Hive), computing engines (Spark), programming models (MapReduce), and interactive query engines (Presto).
[0051] 4) API (Application Programming Interface) modules refer to modules that are relatively cohesive and loosely coupled, derived from the decomposition of cloud computing backend services. Each module has basic processing logic to handle incoming external requests. Different API modules are responsible for different processing tasks. For example, the access service module is responsible for receiving external requests and performing basic logic such as contract verification, permission verification, and frequency limiting on external requests, as well as forwarding external requests to the actual domain processing module.
[0052] 5) Merchant API refers to a contractual interface between the merchant system and the payment system, using an agreed-upon standard format and the HTTP protocol (Hypertext Transfer Protocol).
[0053] 6) Hiram's Law states that when an API module has a sufficient number of access objects, all the behaviors observed in the system will be depended upon by some of these access objects.
[0054] With the development of cloud computing, more and more application processing and computing processes are implemented in the background service system. For example, when an access object is transferring resources, it needs to send a business request to the background service system. After the service system authenticates and verifies the business request, it will perform the corresponding resource transfer processing.
[0055] However, in actual business operations, due to reasons such as code redundancy and function updates, it is necessary to refactor the backend service system. The refactored system needs to pass consistency verification, that is, to ensure that the processing logic of the refactored system is consistent with that of the original service system before it can be put into use.
[0056] In related technologies, there are two ways to perform consistency verification on the reconstructed system. One is to build test cases for the reconstructed system based on business rules, analyze the processing results of the reconstructed system on the test cases, and determine whether the reconstructed system has passed the consistency verification. The other is to extract some historical requests of access objects from the log files of the service system, reproduce the processing process of these historical requests in the reconstructed system, and finally determine whether the reconstructed system has passed the consistency verification based on the processing results of the historical requests in the reconstructed system.
[0057] However, different access objects will generate different requests to the backend service system. For example, some access objects may have non-standard usage patterns. Therefore, test cases built based on business rules cannot cover the request characteristics of all access objects, resulting in limitations in the input reflected in the refactoring and affecting the accuracy of consistency verification for the refactored system. Similarly, historical requests from some access objects cannot cover the request characteristics of all access objects, limiting the input to the refactored system and affecting the accuracy of consistency verification for the refactored system.
[0058] Therefore, it can be seen that in the relevant technologies, when performing consistency verification on the reconstructed system, there is a limitation in the input of the reconstructed system, which ultimately results in low accuracy of the system consistency verification.
[0059] Furthermore, when reproducing historical requests of access objects in the refactoring system, since the test environment lacks object attribute data from logs in the real environment, it is necessary to add attribute parameters such as signature verification information, authentication information, identity identifiers, and timestamps to the historical requests. However, adding extra attribute parameters to historical requests distorts the historical requests, thus failing to promptly expose problems in the refactoring system after they are input, further affecting the accuracy of system consistency verification.
[0060] This application provides a system verification method, apparatus, device, computer-readable storage medium, and program product, which can improve the accuracy of system consistency verification. The exemplary application of the system verification device provided in this application is described below. The system verification device provided in this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, and mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), or as a server. The exemplary application of the system verification device as a server is described below.
[0061] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the system verification system provided in the embodiment of this application. In order to support a system verification application, in the system verification system 100, terminal 400-1 and terminal 400-2 (request sending objects) are connected to server 200 (system verification device, running the system to be verified) and server 500 (running the benchmark system) through network 300. Network 300 can be a wide area network or a local area network, or a combination of the two.
[0062] Terminal 400-1 and server 400-2 are used to send service requests to server 500. Server 500 receives the service requests, generates benchmark results for the service requests, and sends the benchmark results to server 200 through network 300.
[0063] Server 200 is used to count the number of service requests sent from terminals 400-1 and 400-2 to server 500, obtaining the number of requests from terminals 400-1 and 400-2 respectively; based on the number of requests from terminals 400-1 and 400-2 respectively, a request extraction ratio is set for each terminal 400-1 and 400-2; based on the request extraction ratio, test requests for the system to be verified are extracted from the service requests of terminals 400-1 and 400-2 respectively, the system to be verified being reconstructed from the benchmark system; the test requests are input into the system to be verified, and the processing results of the system to be verified in response to the test requests are collected; based on the processing results and the benchmark results of the benchmark system in response to the test requests, consistency verification is performed between the system to be verified and the benchmark system to obtain the verification result.
[0064] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal 400 may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, smart home appliance, in-vehicle terminal, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment of the invention.
[0065] See Figure 2 , Figure 2 This is provided by the embodiments of this application. Figure 1 A schematic diagram of the structure of the server (an implementation of a system verification device) in the diagram. Figure 2 The server 200 shown includes at least one processor 210, memory 250, at least one network interface 220, and a user interface 230. The various components of server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 240.
[0066] Processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.
[0067] User interface 230 includes one or more output devices 231 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.
[0068] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices physically located away from the processor 210.
[0069] Memory 250 may include volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM), and volatile memory may be random access memory (RAM). The memory 250 described in this application embodiment is intended to include any suitable type of memory.
[0070] In some embodiments, memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.
[0071] Operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;
[0072] The network communication module 252 is used to reach other computing devices via one or more (wired or wireless) network interfaces 220, such as Bluetooth, Wi-Fi, and Universal Serial Bus (USB).
[0073] Presentation module 253 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 231 (e.g., a display screen, a speaker, etc.) associated with user interface 230;
[0074] The input processing module 254 is used to detect and translate one or more user inputs or interactions from one or more input devices 232.
[0075] In some embodiments, the system verification apparatus provided in this application can be implemented in software. Figure 2 A system verification device 255 stored in memory 250 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a quantity statistics module 2551, a ratio setting module 2552, a request extraction module 2553, a request processing module 2554, a result verification module 2555, a data retrieval module 2556, an information registration module 2557, and a system adjustment module 2558. These modules are logically connected and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.
[0076] In other embodiments, the system verification device provided in this application can be implemented in hardware. As an example, the system verification device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the system verification method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.
[0077] In some embodiments, a terminal or server (both possible implementations of a system verification device) can implement the system verification method provided in this application by running a computer program. For example, the computer program can be a native program or software module in an operating system; it can be a native application (APP), i.e., a program that needs to be installed in the operating system to run, such as a conformance verification APP; it can also be a small program, i.e., a program that only needs to be downloaded to a browser environment to run; or it can be a small program that can be embedded in any APP. In short, the above-mentioned computer program can be any form of application, module, or plugin.
[0078] The embodiments of this application can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, and vehicle-mounted systems. Below, the system verification method provided by the embodiments of this application will be described in conjunction with exemplary applications and implementations of the system verification equipment provided in the embodiments of this application.
[0079] See Figure 3 , Figure 3 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 1 , will combine Figure 3 The steps shown are explained.
[0080] S101. Count the number of business requests sent by each request sending object to the baseline system to obtain the number of requests for each request sending object.
[0081] This application embodiment is implemented in a scenario where consistency verification is performed on a reconstructed system to be verified. For example, consistency verification is performed between the reconstructed resource transfer system and the original resource transfer system, and consistency verification is performed between the reconstructed authentication system and the original authentication system. In this application embodiment, the system verification device first counts the number of business requests sent by each request sending object to the baseline system, thus obtaining the number of requests made by each request sending object to the baseline system. The baseline system is the system before reconstruction, i.e., the original system, such as the original resource transfer system, the original authentication system, etc.
[0082] It should be noted that the request sending object refers to any object connected to the baseline system, such as a resource transfer initiating object or an authentication initiating object. The business request can be a resource transfer request, an authentication request, or other types of requests; this embodiment does not limit the specific type of request.
[0083] In some embodiments, the system verification device counts the number of all service requests for each request sending object since it accesses the benchmark system, and obtains the number of requests. In other embodiments, the system verification device can set a time range and count the number of service requests for each request sending object within the set time range, and obtain the number of requests. This application embodiment does not limit this.
[0084] S102. Based on the number of requests for each request sending object, set the request extraction ratio for each request sending object.
[0085] After counting the number of requests for each request sending object, the system verification device sets a corresponding request extraction ratio for each request sending object based on the request count. This extraction ratio is used to extract test requests from the business requests corresponding to each request sending object, and these test requests are then used as input for system consistency verification.
[0086] In some embodiments, the system verification device sets multiple different quantity ranges and sets a fixed extraction ratio for each quantity range. Then, it determines the extraction ratio corresponding to each request sending object based on the extraction ratio of the quantity range to which the request quantity of each request sending object falls.
[0087] In other embodiments, the system verification device may use the number of requests for each request sending object to normalize a specific threshold to obtain the request extraction ratio, or set different extraction ratio determination methods for different quantity ranges, and then determine the request extraction ratio based on the extraction ratio determination method of the quantity range in which the number of requests for each request sending object falls.
[0088] S103. Based on the request extraction ratio, extract the test requests of the system to be verified from the business requests of each request sending object.
[0089] The system verification device calculates the number of requests to be extracted based on the request extraction ratio corresponding to each request sending object and the number of requests corresponding to each request sending object. Then, it randomly or sequentially extracts the required number of requests from the business requests of each request sending object. The extracted requests are then designated as test requests, which will be used as input for verification information in subsequent verification processes.
[0090] It is understandable that the system to be verified is reconstructed from the baseline system; that is, the system to be verified is the system obtained after reconstructing the baseline system.
[0091] It should be noted that, in this embodiment of the application, the system verification device extracts test requests from the business requests corresponding to each request sending object according to the request extraction ratio corresponding to each request sending object. It can perform reasonable sampling of the real historical requests of each request sending object, so that the request characteristics of each request sending object can be input into the system to be verified, so as to comprehensively verify the consistency of the system to be verified.
[0092] S104. Input the test request into the system to be verified and collect the processing results of the system to be verified in response to the test request.
[0093] The system verification device inputs test requests into the system to be verified, instructing the system to process the test requests. Once the system to be verified has completed processing the test requests and generated processing results, the system verification device collects these results to determine whether the system to be verified has passed consistency verification.
[0094] S105. Based on the processing results and the benchmark results of the benchmark system for the test request, perform consistency verification between the system to be verified and the benchmark system to obtain the verification results.
[0095] The system verification device acquires the benchmark results generated by the benchmark system in response to the test request, and compares the benchmark results with the processing results generated by the system to be verified in response to the test request to determine whether the system to be verified and the benchmark system have consistent business logic for the business request of the request sending object, and obtains the verification result of the consistency verification of the system to be verified.
[0096] It should be noted that the test request is part of the business request. The system verification device can directly read the response results of the benchmark system for all business requests from the log file of the benchmark system, and select the response result corresponding to the test request from these response results as the benchmark result corresponding to the test request. The system verification device can also input the test request back into the benchmark system to reproduce the benchmark system's processing process for the test request and obtain the benchmark result. This embodiment of the application does not specifically limit this.
[0097] Understandably, compared to related technologies, the input of the reconstructed system has limitations, resulting in lower accuracy of system consistency verification. In this embodiment, the system verification device can determine the corresponding request extraction ratio for each request sending object based on the number of requests made by each request sending object to the benchmark system. Then, according to the request extraction ratio, test requests are extracted from the real business requests of each request sending object. This ensures that the input of the system to be verified can not only cover the real business requests of each request sending object, but also cover the request characteristics of all request sending objects. This overcomes the limitations of the input of the reconstructed system to be verified, thereby improving the accuracy of system consistency verification.
[0098] based on Figure 3 See Figure 4 , Figure 4 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 2 In some embodiments of this application, the request extraction ratio is set for each request sending object based on the number of requests for each request sending object. That is, the specific implementation process of S102 may include any one of S1021-S1023, as follows:
[0099] S1021. When the number of requests for the request sending object is less than or equal to the first threshold, the request extraction ratio of the request sending object is set to a fixed ratio.
[0100] The system verification device compares the number of requests for sending objects with a first threshold. When it determines that the number of requests for sending objects is less than or equal to the first threshold, the system verification device reads a pre-set fixed ratio and directly sets that fixed ratio as the threshold.
[0101] It is understood that the fixed ratio can be set to 100% or 50%, and this application embodiment does not limit it. The fixed ratio can also be obtained by the system testing equipment using artificial intelligence technology to analyze the specific functions of the benchmark system, the number of access objects, etc., and this application embodiment does not limit it.
[0102] The first threshold can be set to 10 or 100, and this embodiment of the application does not limit it.
[0103] S1022. When the number of requests for the request sending object is greater than the first threshold and less than or equal to the second threshold, set the request extraction ratio for the request sending object based on the number of requests and the first threshold.
[0104] It should be noted that the second threshold is greater than the first threshold. Therefore, when the system verification device determines that the request data of the request sending object is between the first threshold and the second threshold (including the case where it is equal to the second threshold), it will use the number of requests and the first threshold together as the parameters for determining the extraction ratio, so as to set the request extraction ratio corresponding to the request sending object.
[0105] In some embodiments of this application, the process by which the system verification device sets a request extraction ratio for the request sending object based on the number of requests and a first threshold may include:
[0106] S1022a. Normalize the first threshold using the number of requests to obtain a normalized value, and set the normalized value as the request extraction ratio.
[0107] The system verification device uses the number of requests as the denominator in the normalization process, determines the first threshold as the numerator in the normalization process, and then performs proportional calculations to obtain the normalized value.
[0108] For example, when the number of requests is N and the first threshold is 10, the normalized value is 10 / N, and thus the request extraction ratio is 10 / N.
[0109] In other embodiments of this application, the system verification device sets a request extraction ratio for the request sending object based on the number of requests and a first threshold, and may further include:
[0110] S1022b: Perform a ratio calculation on the difference between the number of requests and the first threshold, as well as the number of requests, to obtain a ratio result, and set the ratio result as the request extraction ratio.
[0111] The system verification device first calculates the difference between the number of requests and the first threshold, then calculates the ratio of the difference to the number of requests, and uses this ratio as the request extraction ratio.
[0112] For example, when the number of requests is N and the first threshold is 10, the ratio is (N-10) / N, and thus the request extraction ratio is (N-10) / N.
[0113] At this point, the system verification device has completed the process of determining the request extraction ratio corresponding to the request sending object based on the number of requests and the first threshold.
[0114] S1023. When the number of requests to the request sending object is greater than the second threshold, set the request extraction ratio for the request sending object based on the number of requests.
[0115] When the number of requests for a request object exceeds the second threshold, the system verification device will only use the number of requests as a parameter for calculating the extraction ratio to determine the request extraction ratio corresponding to the request object.
[0116] In some embodiments of this application, the process of setting a request extraction ratio for the request sending object based on the number of requests may include:
[0117] S1023a. Using the number of requests, normalize the square root of the number of requests to obtain the initial extraction ratio.
[0118] S1023b: Reduce the initial sampling ratio and set the reduced initial sampling ratio as the requested sampling ratio.
[0119] The system verification device first calculates the square root of the number of requests. Then, using the square root as the numerator and the number of requests as the denominator, it performs normalization. The normalized result, which is between 0 and 1, is used as the initial extraction ratio. Next, the system verification device reduces the initial extraction ratio according to a fixed or random reduction factor, and determines the reduced initial extraction ratio as the request extraction ratio corresponding to the request sending object.
[0120] For example, when the number of requests is N and the reduction factor is 0.1, the request extraction ratio can be expressed as (N^1 / 2)N*0.1.
[0121] In other embodiments of this application, the process of setting a request extraction ratio for the request sending object based on the number of requests may include:
[0122] S1023c. The ratio of the number of requests to the total number of business requests received by the baseline system is determined as the request extraction ratio.
[0123] Thus, this embodiment of the application completes the process of determining the request extraction ratio corresponding to the request sending object based on the number of requests.
[0124] It is understandable that, based on the processing steps from S1021 to S1023, when the number of requests for the request sending object is larger, the request sampling ratio determined for the request sending object is smaller. However, if the number of requests is large, even if the request sampling ratio is small, the number of test requests for the request sending object will be large. Thus, the system verification device implements the principle that the more requests there are, the lower the sampling ratio and the larger the sampling number, and extracts test requests. In this way, the number of test requests for different request sending objects can be reasonably distributed.
[0125] based on Figure 3 See Figure 5, Figure 5 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 3 In some embodiments of this application, before counting the number of service requests sent by each request sending object to the baseline system to obtain the number of requests for each request sending object, i.e., before S101, the method may further include: S106-S107, as follows:
[0126] S106. Parse the multiple network requests received by the baseline system to obtain the identity identifier corresponding to each network request.
[0127] The system verification device extracts the request body text from each network request received from the benchmark system, then parses the request body text to obtain the information contained in the request body text, and then extracts the identity identifier corresponding to each network request from this information.
[0128] It is understood that the identity identifier can be a unique identifier assigned by the benchmark system to represent the requesting object when the requesting object registers with the benchmark system, such as an identity ID, merchant number, etc., or it can be the network address of the requesting object, such as an IP address, domain name, etc., which is not limited in this embodiment of the application.
[0129] In some embodiments, the system verification device can match the information contained in the request body text according to a pre-defined matching rule, and identify the matched information as an identity identifier. For example, if the matching rule is set to an 18-bit numeric sequence, when an 18-bit numeric sequence is read from the information contained in the request body text, that numeric sequence will be identified as an identity identifier.
[0130] In other embodiments, the system verification device may also use an information classification model to classify the various information contained in the request body text, extract information categorized as identity, and identify the information as an identity identifier.
[0131] It is understood that the request body text can be either XML or JSON text, and this application does not make any specific restrictions here.
[0132] S107. Based on the correspondence between the identity identifier and the request sending object, filter out the business request of each request sending object from multiple network requests.
[0133] There is a correspondence between identity identifiers and request sending objects. Based on this correspondence, the system verification device can filter out network requests with the same identity identifier from multiple network requests, and use these as the business requests for the request sending object corresponding to that identity identifier. In other words, the system verification device can aggregate network requests with the same identity identifier to obtain the corresponding business request for that identity identifier.
[0134] In this embodiment of the application, the system verification device can parse the network requests received by the benchmark system, and then determine the service requests sent by each request sender based on the parsed identity identifier, so as to facilitate the subsequent statistics of the number of requests for each request sender.
[0135] based on Figure 5 See Figure 6 , Figure 6 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 4 In some embodiments of this application, the method further includes S108-S109, as follows, whereby multiple network requests received by the baseline system are parsed separately to obtain the identity identifier corresponding to each network request, i.e., before S106:
[0136] S108. Submit a data request script to the data management platform corresponding to the benchmark system.
[0137] Before parsing the multiple network requests received by the benchmark system, the system verification device needs to first obtain these network requests. At this point, the system verification device creates a data request script and submits it to the data management platform corresponding to the benchmark system. The data request script then retrieves the request logs from the benchmark system through this platform. In other words, the data request script is used to retrieve the request logs from the benchmark system.
[0138] It should be noted that the request log records every network request received by the benchmark system, as well as information such as the time and processing result of the network request.
[0139] S109. Parse the request log returned by the data management platform for the data request script to obtain the multiple network requests received by the benchmark system.
[0140] After submitting the data request script, the system verification device monitors whether it receives a request log from the data management platform. Once the system verification device receives the request log, it parses it to extract the network requests received by the baseline system.
[0141] It is understood that in this embodiment of the application, the system verification device will directly obtain multiple network requests received by the benchmark system from the request log at one time. That is, it can obtain each network request received by the benchmark system without interacting with the benchmark system, making the process of obtaining network requests more efficient.
[0142] In some embodiments of this application, based on the processing result and the benchmark result of the benchmark system for the test request, the consistency verification between the system to be verified and the benchmark system is performed to obtain the verification result. The specific implementation process of S105 may include: S1051 or S1052, as follows:
[0143] S1051. When the processing result is the same as the benchmark result of the benchmark system for the test request, generate a verification result that indicates that the system to be verified is consistent with the benchmark system, and complete the consistency verification between the system to be verified and the benchmark system.
[0144] The system verification device compares the processing result with the benchmark result generated by the benchmark system in response to the test request. When the processing result is consistent with the benchmark result, the generated verification result indicates that the system to be verified is consistent with the benchmark system. At this time, the system to be verified has passed the consistency verification.
[0145] It is understood that the benchmark results can be obtained by the system verification device from the request log, or the test request can be re-entered into the benchmark system, that is, the benchmark system can reproduce the processing of the test request. This application embodiment does not limit this.
[0146] S1052. When the processing result is different from the benchmark result of the benchmark system for the test request, generate a verification result that is inconsistent between the system to be verified and the benchmark system, and complete the consistency verification between the system to be verified and the benchmark system.
[0147] When the processing result is inconsistent with the benchmark result, the verification result generated by the system verification device will indicate that the system to be verified is inconsistent with the benchmark system. In this case, the system to be verified has not passed the consistency verification.
[0148] In this embodiment of the application, the system verification device determines whether the system to be verified and the benchmark system are consistent by checking whether the benchmark result and the processing result are consistent, thereby completing the consistency verification of the system to be verified.
[0149] based on Figure 3 See Figure 7 , Figure 7 This is a flowchart illustrating the system verification method provided in the embodiments of this application. Figure 5In some embodiments of this application, based on the request extraction ratio, test requests for the system to be verified are extracted from the business requests of each request sending object. The specific implementation process of S103 may include: S1031-S1033, as follows:
[0150] S1031. Randomly generate sampling coefficients for business requests from the coefficient generation interval.
[0151] The system verifies that the device obtains the coefficient generation range, and then generates a random number from the coefficient generation range (the random number needs to be less than or equal to the maximum value of the coefficient generation range and greater than or equal to the minimum value of the coefficient generation range). The generated random number is then determined as the sampling coefficient corresponding to the business request.
[0152] S1032. Using the maximum value of the coefficient generation interval, normalize the sampling coefficient to obtain the normalized ratio.
[0153] The system verification device uses the randomly generated sampling coefficient as the numerator and the maximum value of the coefficient generation interval as the denominator for normalization processing to obtain the normalization ratio. For example, when the sampling coefficient is 2 and the coefficient generation interval is [1, 10], the normalization ratio is 0.2.
[0154] S1033. Business requests with a normalization ratio less than or equal to the request extraction ratio are identified as test requests.
[0155] The system verification device compares the normalization ratio with the calculated request extraction ratio. When the normalization ratio is less than the request extraction ratio, the system verification device will extract the business request corresponding to the normalization ratio, and that is, identify the business request as a test request.
[0156] In this embodiment of the application, the system verification device controls the sampling of test requests by randomly generating sampling coefficients, coefficient generation intervals and request sampling ratios, so as to ensure the randomness of test requests while meeting the quantity requirements during sampling.
[0157] In some embodiments of this application, before inputting the test request into the system to be verified and collecting the processing result of the system to be verified in response to the test request, i.e. before S104, the method may further include: S110, as follows:
[0158] S110. Register authentication and signature information for the test request in the relay service of the system to be verified, so that the system to be verified can obtain the authentication and signature information from the relay service in response to the test request and process the test request in response to the authentication and signature information.
[0159] It should be noted that, in order to make the consistency verification process of the system under test as close as possible to the actual online use of the baseline system, the system verification equipment must input the dependency attribute parameters required by the system under test during runtime. To ensure that the test request data is not distorted and to expose problems in the system under test in a timely manner, the system verification equipment needs to input the actual attribute parameters of the test request into the system under test, such as the actual signature and authentication information of the test request. To address this, before inputting a test request into the system to be verified, the system verification device sets up a relay service for the system to be verified. Then, it registers the authentication and signature information of the test request in the relay service (the baseline system calls the signature and authentication services to obtain the signature and authentication information when processing the test request; here, the signature and authentication information obtained from the baseline service can be directly registered in the relay service). This allows the system to be verified to directly extract the true authentication and signature information of the test request object from the relay service after it begins processing the test request. This enables the system to obtain the true attribute parameters of the test request, ensuring that the test request data is not distorted and improving the accuracy of system consistency verification.
[0160] Meanwhile, the system verification device no longer needs to call the authentication and signature verification services through the relay service to initiate the real authentication and signature verification process for the test request, saving the processing time of the system to be verified for the test request. This allows the system verification device to obtain the processing results of the system to be verified for the test request more quickly, thus accelerating the efficiency of consistency verification of the system to be verified.
[0161] It is understandable that the system can verify the authentication information of the device registered in the relay service, which may directly indicate whether the authentication has passed or failed. Similarly, the system can verify the signature verification information of the device registered in the relay service, which may directly indicate whether the signature verification has passed or failed.
[0162] In some embodiments of this application, based on the processing result and the benchmark result of the benchmark system for the test request, the consistency verification between the system to be verified and the benchmark system is performed to obtain the verification result. That is, after S105, the method may further include: S111-S112, as follows:
[0163] S111. When the verification results indicate that the system to be verified and the benchmark system are inconsistent, the test request is parsed to obtain compatibility anomaly information between the system to be verified and the benchmark system.
[0164] In this embodiment, when the verification result indicates inconsistency between the system to be verified and the benchmark system, i.e., the system to be verified fails the consistency verification, the system verification device can also adjust the system to be verified to make it consistent with the benchmark system. To do this, the system verification device parses the test request to obtain various input information of the system to be verified, and analyzes this input information to determine whether it is compatibility anomaly information. Here, compatibility anomaly information indicates information that is compatible with the benchmark system but incompatible with the system to be verified; for example, fields that cannot be used in the system to be verified but can be used in the benchmark system.
[0165] S112. Based on the compatibility anomaly information, adjustments are made to the compatibility of the system to be verified to obtain the adjusted system.
[0166] The system verification device can adjust the compatibility of the system to be verified in response to compatibility anomalies, so that the adjusted system can be normally compatible with the anomaly information. In some embodiments, to avoid frequent modifications to the system to be verified, the system verification device can also adjust the compatibility of the system to be verified only when the usage of anomaly compatibility information exceeds a certain threshold, so that the compatibility of the system to be verified can meet the needs of most access objects.
[0167] In some embodiments of this application, after parsing the test request to obtain compatibility anomaly information between the system to be verified and the benchmark system, i.e., after S111, the method may further include: S113, as follows:
[0168] S113. Based on compatibility exception information, add exception prompt function to the system to be verified to obtain the adjusted system.
[0169] The anomaly alert function is used to generate modification prompts for compatibility anomalies. In other words, the system verification device can adjust the system to be verified by adding this function. This allows the adjusted system to return modification prompts to the access object when a received network request contains compatibility anomalies. The access object then regenerates the network request based on the modification prompts, and the regenerated network request no longer contains the compatibility anomaly information. This allows the adjusted system to process the regenerated network request normally, just like the baseline system.
[0170] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.
[0171] This application embodiment is implemented in a scenario where the server performs consistency verification on the reconstructed module (system to be verified) of the resource transfer module (baseline system). The resource transfer system (system to be verified) is connected to a merchant (the request sending object).
[0172] First, the server sets a sampling ratio (request sampling ratio) based on the merchant's request volume (number of requests). Then, the server pushes the business-reported data to a unified data management platform. On the data management platform, an SQL script (data request script) is submitted to record the merchant's request volume. This script filters out requests (network requests) from the merchant between July 30, 2021, and September 1, 2021, and breaks these requests down into request headers and request bodies. The original request body is XML text and does not display the merchant ID and sub-merchantment ID fields. The server can use a Python slicing module to extract the merchant ID or sub-merchantment ID (identification) from the XML text and aggregate the total number of requests based on the merchant ID and sub-merchantment ID.
[0173] For example, Table 1 shows the distribution of the total number of requests.
[0174] Table 1
[0175] ≤10 199 781 ≤100 459 12,000 ≤1000 885 200,000 ≤10000 1329 2.15 million >10000 650 1.3 billion
[0176] It is evident that the number of requests varies among different merchants and is not evenly distributed. If the same sampling ratio is set for each merchant, merchants with a large number of requests will have more requests sampled, while merchants with a small number of requests will have very few requests sampled, thus affecting the sample sampling situation for different merchants.
[0177] To ensure that all merchants have a reasonable probability of being sampled, the server samples according to the principle of "the more requests, the lower the sampling ratio, and the larger the sample size." For example, Table 2 shows the server's sampling results for merchants with different numbers of requests.
[0178] Table 2
[0179]
[0180]
[0181] It is evident that sampling according to the principle of lower sampling ratio and larger sample size for more requests ensures that requests from different merchants have a probability of being selected, and the total number of samples from different types of merchants (i.e., types categorized by the number of requests) will not differ too much.
[0182] When the server extracts samples according to the sampling ratio, it first parses out the merchant ID and sub-merchant ID, uses the merchant ID and sub-merchant ID to associate the number of requests of the merchant or sub-merchant, sets the sampling ratio according to the number of requests, and then uses the Rand tool to generate random numbers (sampling coefficients). It then checks whether the random number hits the sampling ratio range (i.e., the range from 0 to the sampling ratio). If it does, it exports the request (test request).
[0183] If the extracted requests are sent directly to the test environment for execution, execution will fail due to missing merchant information, permissions, etc., making it impossible to compare with the results of successful execution. Therefore, the server will uniformly route the services that the refactoring module depends on to the proxy relay (relay service), and set mock data to be returned for the requests in the proxy relay.
[0184] For example, Figure 8 This is a schematic diagram illustrating the process of verifying signatures and authenticating authorization for requests through a proxy relay, as provided in this embodiment of the application. Server 8-A registers mock stub 8-1 in proxy relay 8-B, that is, it provides proxy relay 8-B with the signature verification mock (signature verification information) and authorization mock (authentication information) of the request. Then, it replays the merchant's original request 8-2 to the reconstruction module 8-C to initiate a test. After receiving the original request, reconstruction module 8-C needs to perform parameter verification, such as calling dependent services for authentication, signature verification, and frequency limiting. That is, reconstruction module 8-C will call proxy relay 8-B to perform signature verification 8-3 and authorization 8-4. In response to the call from reconstruction module 8-C, proxy relay 8-B checks the mock record 8-D to see if it matches the registered mock 8-5. If it matches, it immediately returns the set mock data without calling the signature verification service 8-E and the authorization service 8-F to initiate the actual signature verification 8-6 and authorization 8-7 process (the dotted line indicates that this step will not be actually executed). In this way, we can eliminate complex dependency calls, speed up the testing process, and also eliminate the reliance on actual merchant data.
[0185] By verifying the consistency between the resource transfer module and the reconstruction module, the server was able to discover two implementation anomalies in the reconstruction module and 47 non-standard usages by merchants.
[0186] For non-standard usage, when the number of calls is low and there are few merchants, reminders can be used to encourage merchants to make modifications. For example, reminders can be sent to set the request body to a non-XML format or to prompt the removal of non-standard fields. If the number of calls is high, in order to ensure that merchants are unaware of the changes after the refactoring, compatibility adjustments can be made to the refactoring module. For example, invalid or redundant fields can be made compatible. However, it is important to limit the types of non-standard usage to prevent abuse by non-standard users.
[0187] It is understood that in the embodiments of this application, user information, such as network requests, business requests and other related data, is involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0188] The following description continues to illustrate the exemplary structure of the system verification device 255 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the system verification device 255 of the memory 250 may include:
[0189] The quantity statistics module 2551 is used to count the number of business requests sent by each request sending object to the baseline system, and obtain the number of requests for each request sending object.
[0190] The ratio setting module 2552 is used to set a request extraction ratio for each request sending object based on the number of requests for each request sending object.
[0191] The request extraction module 2553 is used to extract test requests for the system to be verified from the business requests of each request sending object based on the request extraction ratio; the system to be verified is reconstructed from the benchmark system;
[0192] The request processing module 2554 is used to input the test request into the system to be verified and collect the processing result of the system to be verified in response to the test request.
[0193] The result verification module 2555 is used to perform consistency verification between the system to be verified and the benchmark system based on the processing result and the benchmark result of the benchmark system for the test request, and obtain the verification result.
[0194] In some embodiments of this application, the ratio setting module 2552 is further configured to: set the request extraction ratio of the request sending object to a fixed ratio when the number of requests of the request sending object is less than or equal to a first threshold; and set the request extraction ratio for the request sending object based on the number of requests and the first threshold when the number of requests of the request sending object is greater than the first threshold and less than or equal to a second threshold; wherein the second threshold is greater than the first threshold; and set the request extraction ratio for the request sending object based on the number of requests when the number of requests of the request sending object is greater than the second threshold.
[0195] In some embodiments of this application, the ratio setting module 2552 is further configured to normalize the first threshold using the number of requests to obtain a normalized value, and set the normalized value as the request extraction ratio.
[0196] In some embodiments of this application, the ratio setting module 2552 is further configured to normalize the square root of the number of requests using the number of requests to obtain an initial extraction ratio; reduce the initial extraction ratio and set the reduced initial extraction ratio as the request extraction ratio.
[0197] In some embodiments of this application, the quantity statistics module 2551 is further configured to parse the multiple network requests received by the benchmark system to obtain the identity identifier corresponding to each network request; and based on the correspondence between the identity identifier and the request sending object, to filter out the service request of each request sending object from the multiple network requests.
[0198] In some embodiments of this application, the system verification device 255 further includes: a data retrieval module 2556; the data retrieval module 2556 is used to submit a data request script to the data management platform corresponding to the benchmark system; the data request script is used to retrieve the request log of the benchmark system; and the request log returned by the data management platform in response to the data request script is parsed to obtain the multiple network requests received by the benchmark system.
[0199] In some embodiments of this application, the result verification module 2555 is further configured to generate a verification result indicating consistency between the system to be verified and the benchmark system when the processing result is the same as the benchmark result of the benchmark system for the test request, thereby completing the consistency verification between the system to be verified and the benchmark system; and to generate a verification result indicating inconsistency between the system to be verified and the benchmark system when the processing result is different from the benchmark result of the benchmark system for the test request, thereby completing the consistency verification between the system to be verified and the benchmark system.
[0200] In some embodiments of this application, the request extraction module 2553 is further configured to randomly generate sampling coefficients for the business requests from the coefficient generation interval; normalize the sampling coefficients using the maximum value of the coefficient generation interval to obtain a normalization ratio; and determine the business requests whose normalization ratio is less than or equal to the request extraction ratio as the test requests.
[0201] In some embodiments of this application, the system verification device 255 further includes: an information registration module 2557; the information registration module 2557 is used to register authentication information and signature verification information for the test request in the relay service of the system to be verified, so that the system to be verified can obtain the authentication information and signature verification information from the relay service in response to the test request, and process the test request in response to the authentication information and signature verification information.
[0202] In some embodiments of this application, the system verification device 255 further includes: a system adjustment module 2558; the system adjustment module 2558 is used to parse the test request when the verification result indicates that the system to be verified and the benchmark system are inconsistent, to obtain compatibility anomaly information between the system to be verified and the benchmark system; the compatibility anomaly information indicates that the benchmark system is compatible and the system to be verified is incompatible; based on the compatibility anomaly information, adjustments are made to the compatibility of the system to be verified to obtain the adjusted system.
[0203] In some embodiments of this application, the system adjustment module 2558 is further configured to add an anomaly prompt function to the system to be verified based on the compatibility anomaly information, thereby obtaining an adjusted system; the anomaly prompt function is used to generate a modification prompt based on the compatibility anomaly information.
[0204] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the system verification method described in this application.
[0205] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute the system verification method provided in this application. For example, ... Figure 3 The system verification method is shown.
[0206] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EP ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.
[0207] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0208] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).
[0209] As an example, executable instructions can be deployed to execute on a single computing device (an implementation of a system verification device), or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.
[0210] In summary, through the embodiments of this application, the system verification device can determine the corresponding request extraction ratio for each request sending object based on the number of requests made by each request sending object to the baseline system. Then, according to the request extraction ratio, test requests are extracted from the real business requests of each request sending object. This ensures that the input of the system to be verified not only covers the real business requests of each request sending object but also covers the request characteristics of all request sending objects, breaking the limitation problem of the input of the reconstructed system to be verified, thus improving the accuracy of system consistency verification. After the system to be verified begins processing the test requests, it directly extracts the real authentication information and signature information of the test request objects from the relay service, thereby enabling the system to be verified to obtain the real attribute parameters of the test requests, ensuring that the test request data is not distorted, and improving the accuracy of system consistency verification. The system verification device can obtain the processing results of the system to be verified for the test requests more quickly, accelerating the efficiency of consistency verification for the system to be verified.
[0211] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.
Claims
1. A system verification method, characterized in that, The method includes: The number of business requests sent by each request sending object to the baseline system is counted to obtain the number of requests for each request sending object; For each request sending object, when the number of requests of the request sending object is less than or equal to a first threshold, the request extraction ratio of the request sending object is set to a fixed ratio; when the number of requests of the request sending object is greater than the first threshold and less than or equal to a second threshold, the request extraction ratio is set for the request sending object based on the number of requests and the first threshold; wherein, the second threshold is greater than the first threshold; when the number of requests of the request sending object is greater than the second threshold, the request extraction ratio is set for the request sending object based on the number of requests. Based on the aforementioned request extraction ratio, test requests for the system to be verified are extracted from the business requests of each of the request sending objects; the system to be verified is reconstructed from the baseline system. The test request is input into the system to be verified, and the processing result of the system to be verified in response to the test request is collected. Based on the processing results and the benchmark results of the benchmark system for the test request, the consistency verification between the system to be verified and the benchmark system is performed to obtain the verification results.
2. The method according to claim 1, characterized in that, The step of setting the request extraction ratio for the request sending object based on the number of requests and the first threshold includes: The first threshold is normalized using the number of requests to obtain a normalized value, and the normalized value is set as the request extraction ratio.
3. The method according to claim 1, characterized in that, The step of setting the request extraction ratio for the request sending object based on the number of requests includes: Using the number of requests, the square root of the number of requests is normalized to obtain the initial extraction ratio; The initial extraction ratio is reduced, and the reduced initial extraction ratio is set as the requested extraction ratio.
4. The method according to any one of claims 1 to 3, characterized in that, Before counting the number of service requests sent by each request sending object to the baseline system to obtain the number of requests for each request sending object, the method further includes: The system parses the multiple network requests received by the benchmark system to obtain the identity identifier corresponding to each network request. Based on the correspondence between the identity identifier and the request sending object, the service request of each request sending object is obtained from multiple network requests.
5. The method according to claim 4, characterized in that, Before parsing the multiple network requests received by the benchmark system to obtain the identity identifier corresponding to each network request, the method further includes: For the data management platform corresponding to the benchmark system, submit a data request script; the data request script is used to retrieve the request record log of the benchmark system; The data management platform parses the request log returned by the data request script to obtain the multiple network requests received by the benchmark system.
6. The method according to any one of claims 1 to 3, characterized in that, Based on the processing result and the benchmark result of the benchmark system for the test request, the consistency verification between the system to be verified and the benchmark system is performed to obtain the verification result, including: When the processing result is the same as the benchmark result of the benchmark system for the test request, a verification result is generated to characterize the consistency between the system to be verified and the benchmark system, thus completing the consistency verification between the system to be verified and the benchmark system. When the processing result is different from the benchmark result of the benchmark system for the test request, a verification result is generated to characterize the inconsistency between the system to be verified and the benchmark system, thus completing the consistency verification between the system to be verified and the benchmark system.
7. The method according to any one of claims 1 to 3, characterized in that, The step of extracting test requests for the system to be verified from the business requests of each request sending object based on the request extraction ratio includes: Randomly generate sampling coefficients for the business request from the coefficient generation interval; The sampling coefficients are normalized using the maximum value of the coefficient generation interval to obtain the normalized ratio; The business requests whose normalization ratio is less than or equal to the request extraction ratio are identified as the test requests.
8. The method according to any one of claims 1 to 3, characterized in that, Before inputting the test request into the system to be verified and collecting the processing result of the system to be verified in response to the test request, the method further includes: In the relay service of the system to be verified, authentication information and signature verification information for the test request are registered, so that the system to be verified can obtain the authentication information and signature verification information from the relay service in response to the test request, and process the test request in response to the authentication information and signature verification information.
9. The method according to any one of claims 1 to 3, characterized in that, After verifying the consistency between the system to be verified and the benchmark system based on the processing result and the benchmark result of the benchmark system for the test request, and obtaining the verification result, the method further includes: When the verification result indicates that the system to be verified and the benchmark system are inconsistent, the test request is parsed to obtain compatibility anomaly information between the system to be verified and the benchmark system; the compatibility anomaly information indicates that the benchmark system is compatible and the system to be verified is incompatible. Based on the compatibility anomaly information, adjustments are made to the compatibility of the system to be verified, resulting in an adjusted system.
10. The method according to claim 9, characterized in that, After parsing the test request to obtain compatibility anomaly information between the system to be verified and the benchmark system, the method further includes: Based on the compatibility anomaly information, an anomaly prompt function is added to the system to be verified to obtain the adjusted system; the anomaly prompt function is used to generate modification prompts in response to the compatibility anomaly information.
11. A system verification device, characterized in that, The device includes: The quantity statistics module is used to count the number of business requests sent by each request sending object to the baseline system, and obtain the number of requests for each request sending object; A ratio setting module is used to, for each request sending object, set the request extraction ratio of the request sending object to a fixed ratio when the number of requests of the request sending object is less than or equal to a first threshold; and set the request extraction ratio for the request sending object based on the number of requests and the first threshold when the number of requests of the request sending object is greater than the first threshold and less than or equal to a second threshold; wherein the second threshold is greater than the first threshold; and set the request extraction ratio for the request sending object based on the number of requests when the number of requests of the request sending object is greater than the second threshold. The request extraction module is used to extract test requests for the system to be verified from the business requests of each request sending object based on the request extraction ratio; the system to be verified is reconstructed from the benchmark system. The request processing module is used to input the test request into the system to be verified and to collect the processing results of the system to be verified in response to the test request. The result verification module is used to perform consistency verification between the system to be verified and the benchmark system based on the processing result and the benchmark result of the benchmark system for the test request, and obtain the verification result.
12. The apparatus according to claim 11, characterized in that, The ratio setting module is further configured to normalize the first threshold using the number of requests to obtain a normalized value, and set the normalized value as the request extraction ratio.
13. The apparatus according to claim 11, characterized in that, The ratio setting module is further configured to normalize the square root of the number of requests using the number of requests to obtain an initial extraction ratio; reduce the initial extraction ratio and set the reduced initial extraction ratio as the request extraction ratio.
14. The apparatus according to any one of claims 11 to 13, characterized in that, The quantity statistics module is also used to parse the multiple network requests received by the benchmark system to obtain the identity identifier corresponding to each network request. Based on the correspondence between the identity identifier and the request sending object, the service request of each request sending object is obtained from multiple network requests.
15. The apparatus according to claim 14, characterized in that, The device further includes: a data retrieval module; the data retrieval module is used to submit a data request script to the data management platform corresponding to the benchmark system; the data request script is used to retrieve the request log of the benchmark system; and the request log returned by the data management platform in response to the data request script is parsed to obtain the multiple network requests received by the benchmark system.
16. The apparatus according to any one of claims 11 to 13, characterized in that, The result verification module is further configured to generate a verification result characterizing the consistency between the system to be verified and the benchmark system when the processing result is the same as the benchmark result of the benchmark system for the test request, thereby completing the consistency verification between the system to be verified and the benchmark system. When the processing result is different from the benchmark result of the benchmark system for the test request, a verification result is generated to characterize the inconsistency between the system to be verified and the benchmark system, thus completing the consistency verification between the system to be verified and the benchmark system.
17. The apparatus according to any one of claims 11 to 13, characterized in that, The request extraction module is further configured to randomly generate sampling coefficients for the business requests from the coefficient generation interval; normalize the sampling coefficients using the maximum value of the coefficient generation interval to obtain a normalization ratio; and determine the business requests whose normalization ratio is less than or equal to the request extraction ratio as the test requests.
18. A system verification device, characterized in that, The system verification equipment includes: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the system verification method according to any one of claims 1 to 10.
19. A computer-readable storage medium storing executable instructions, characterized in that, When the executable instructions are executed by the processor, they implement the system verification method according to any one of claims 1 to 10.
20. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the system verification method according to any one of claims 1 to 10.
Citation Information
Patent Citations
Application testing method, system and device, medium and computer program product
CN113238935A
Verification method and device for reconstruction system
CN114049125A