Playback test method and apparatus, network device, and storage medium
By storing and retrieving insurance application interface data in the baseline database and performing automated comparisons in conjunction with configuration rules, the problem of low accuracy in replay testing caused by manual comparisons is solved, achieving more efficient replay testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PICC INFORMATION TECH CO LTD
- Filing Date
- 2026-02-06
- Publication Date
- 2026-06-09
AI Technical Summary
Existing replay testing methods rely on manual comparison, resulting in low accuracy and difficulty in ensuring consistency of insurance logic between the old and new systems.
By storing datasets in a baseline database and merging calls to the insurance application interface at different time points, and combining this with configuration rules to compare the data, a baseline environment is established to simulate a distributed system, reducing manual intervention and improving test accuracy.
It improves the convenience and accuracy of replay testing, reduces the need for manual investigation and analysis, and lowers the difficulty of setting up a replay testing environment.
Smart Images
Figure CN122179350A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and in particular to a replay test method, apparatus, network device, and storage medium. Background Technology
[0002] With the development of science and technology, more and more services are provided to users, and improving service quality has become a key focus for users. During the reconstruction of the insurance application interface based on the old system, replay testing is required to ensure the consistency of the insurance application logic between the old and new systems. For example, the message data and application results of the old system's insurance application interface can be manually recorded. The same message data can then be used to call the new system's insurance application interface to query the new system's application results. Finally, the old and new application results can be verified and compared. However, manual comparison results in low accuracy during replay testing. Summary of the Invention
[0003] This disclosure provides a replay testing method, apparatus, network device, and storage medium to improve the convenience and accuracy of replay testing. The technical solution of this disclosure is as follows: According to a first aspect of the present disclosure, a replay test method is provided, comprising: Insurance application messages are collected through the first insurance application interface in the production environment; If any table in the baseline database triggers the operation, the data set of that table is stored in a temporary table, wherein the data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. According to the insurance application message, the first insurance application interface is called to obtain the first data from the temporary table, and in the baseline database, according to the insurance application message, the second insurance application interface is called to obtain the second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; Using configuration rules corresponding to the production environment, the first data and the second data are compared to obtain the replay test results.
[0004] According to some embodiments, the method further includes: The Kafka system is used to collect a baseline data set, which includes messages from the first insurance application interface in the production environment, as well as request and return data from calling the application interface. The baseline dataset is saved to a distributed search and analysis engine; Every preset time interval, the tables corresponding to the production environment are synchronized to the baseline data set, the configuration table is obtained, and the data in the configuration table is synchronized to the baseline library.
[0005] According to some embodiments, the method further includes: Establish a baseline simulation environment using Wiremock; In the baseline simulation environment, the request data and the return data are configured to the Wiremock service to provide a simulation interface, which is used to simulate the application call of the first insurance application interface.
[0006] According to some embodiments, the step of calling the first insurance application interface to obtain the first data from the temporary table based on the insurance application message includes: Based on the insurance application message, the simulation interface is invoked to obtain the first data from the temporary table.
[0007] According to some embodiments, the method further includes: Obtain system stability information corresponding to the replay test results, and issue a prompt message corresponding to the system stability information.
[0008] According to some embodiments, the method further includes: Set corresponding trigger conditions for each table in the baseline database, where different tables correspond to different trigger conditions.
[0009] According to a second aspect of the present disclosure, a playback testing apparatus is provided, comprising: The message acquisition unit is used to collect insurance application messages through the first insurance application interface in the production environment. The temporary table acquisition unit is used to store the data set of any table in the baseline database into a temporary table when any table is triggered. The data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. The data acquisition unit is configured to, according to the insurance application message, call the first insurance application interface to obtain first data from the temporary table, and in the baseline database, call the second insurance application interface to obtain second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; The replay test unit is used to compare the first data and the second data using configuration rules corresponding to the production environment, and obtain the replay test results.
[0010] According to a third aspect of the present disclosure, a network device is provided, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the replay test method described in any one of the preceding aspects.
[0011] According to a fourth aspect of the present disclosure, a storage medium is provided that, when instructions in the storage medium are executed by a processor of a network device, enables the network device to perform the replay test method described in any one of the preceding aspects.
[0012] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method described in any one of the preceding aspects.
[0013] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: In some or related embodiments, insurance application messages are collected through a first insurance application interface in the production environment; if any table in the baseline database triggers an event, the data set of that table is stored in a temporary table, wherein the data set includes at least one of table name, operation type, primary key field name, and primary key field data; based on the insurance application message, the first insurance application interface is called to obtain first data from the temporary table, and in the baseline database, based on the insurance application message, a second insurance application interface is called to obtain second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; using configuration rules corresponding to the production environment, the first data and the second data are compared to obtain replay test results. Therefore, by establishing a baseline environment, standard data can be collected as a baseline database. Collected messages and data from other application interfaces can simulate a distributed environment as baseline data. After replaying the old interface in the baseline environment, triggers are used to collect data affected by the old insurance application interface. After replaying the baseline data, the baseline result is obtained. After replaying the new insurance application interface in the baseline environment, triggers are used to collect data affected by the new interface. Verification is performed using configured verification relationships. This reduces situations where there are many fields in the insurance application data that require manual intervention. It also reduces the need for extensive manual investigation and analysis to find suitable verification relationships and determine whether the replay test is inaccurate, thus improving the convenience and accuracy of replay testing.
[0014] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.
[0016] Figure 1 This is a flowchart illustrating a replay test method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a replay test method according to an exemplary embodiment; Figure 3 This is a block diagram illustrating a playback test apparatus according to an exemplary embodiment; Figure 4 This is a block diagram illustrating a network device according to an exemplary embodiment. Detailed Implementation
[0017] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.
[0018] This disclosure provides a playback test method, apparatus, network device, and storage medium. In some embodiments, the terms "playback test method" and "information processing method," "communication method," etc., can be used interchangeably; the terms "playback test apparatus" and "information processing apparatus," "communication apparatus," etc., can be used interchangeably; and the terms "information processing system," "communication system," etc., can be used interchangeably.
[0019] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.
[0020] In each of the disclosed embodiments, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.
[0021] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure.
[0022] In this disclosure, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun following the article can be understood as either a singular or a plural expression.
[0023] In the embodiments disclosed herein, "multiple" refers to two or more.
[0024] In some embodiments, the terms “at least one of,” “one or more,” “a plurality of,” and “multiple” may be used interchangeably.
[0025] In some embodiments, the notation "at least one of A and B", "A and / or B", "A in one case, B in another", "in response to one case A, in response to another case B", etc., may include the following technical solutions depending on the situation: in some embodiments, A (executes A regardless of B); in some embodiments, B (executes B regardless of A); in some embodiments, execution is selected from A and B (A and B are selectively executed); in some embodiments, both A and B are executed. The same applies when there are more branches such as A, B, C, etc.
[0026] In some embodiments, the apparatus and device may be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. In some cases, they may also be understood as "equipment", "device", "circuit", "network element", "node", "function", "unit", "section", "system", "network", "chip", "chip system", "entity", "body", etc.
[0027] In some embodiments, "terminal" or "terminal device" may be referred to as "user equipment (UE)," "user terminal," "mobile station (MS)," "mobile terminal (MT)," "subscriber station," "mobile unit," "subscriber unit," "wireless unit," "remote unit," "mobile device," "wireless device," "wireless communication device," "remote device," "mobile subscriber station," "access terminal," "mobile terminal," "wireless terminal," "remote terminal," "handset," "user agent," "mobile client," "client," etc.
[0028] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0029] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0030] Figure 1 This is a flowchart illustrating a replay test method according to an exemplary embodiment, such as... Figure 1 As shown, it includes the following steps: In step S11, the insurance application message is collected through the first insurance application interface in the production environment; In some embodiments, the executing entity of this disclosure may be a network device, and the name of the network device is not limited. For example, the network device may also be called a server, base station, or server cluster, etc. This disclosure does not limit this. The technical solutions of this disclosure can be applied to software testing scenarios, for example. The executing entity of this disclosure may also be an electronic device. The electronic device does not specifically refer to a fixed device. For example, when the device identifier or device structure of the electronic device changes, the electronic device may also change accordingly.
[0031] According to some embodiments, the technical solution of this disclosure is replay testing, where "replay testing" is a method in software testing, mainly used to verify the stability and consistency of a system. Its basic idea is to reapply previously captured system inputs (e.g., user operations, network requests, etc.) to the system, and then compare the replayed system output with the original output to see if they are consistent.
[0032] According to some embodiments, the production environment may be, for example, a business environment that provides services to the outside world. This production environment is not specifically defined as a fixed environment. For example, it may be a replay testing environment. For instance, when the services provided by the production environment change, the production environment may also change accordingly.
[0033] In some embodiments, the insurance application interface may be, for example, an application programming interface (API) for submitting insurance applications. This application interface is not specifically defined by a single, fixed interface. For example, when the interface identifier of the application interface changes, the application interface may also change accordingly. Different production environments may include different application interfaces.
[0034] According to some embodiments, the first insurance application interface may be, for example, the insurance application interface corresponding to the production environment. The "first" in the first insurance application interface is used to distinguish it from other insurance application interfaces. This first insurance application interface does not specifically refer to a fixed insurance application interface. For example, when the interface identifier of the first insurance application interface changes, the first insurance application interface may also change accordingly. For example, when the capability corresponding to the first insurance application interface changes, the first insurance application interface may also change accordingly.
[0035] In some embodiments, the message may be the specific data content transmitted through the interface, and the message may be a standardized format message. The insurance application message may be the core data carrier in the insurance system interface. This insurance application message does not specifically refer to a single fixed message. For example, if the information included in the insurance application message changes, the insurance application message may also change accordingly.
[0036] According to some embodiments, insurance application messages can be collected through the first insurance application interface in the production environment. This first insurance application interface can also be referred to as the old insurance application interface.
[0037] In step S12, if any table in the baseline database triggers the operation, the data set of the table is stored in a temporary table, wherein the data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. According to some embodiments, the baseline database may refer, for example, to a standard reference data set established during system construction or project initiation. A trigger for any table may be, for example, the fulfillment of triggering conditions by relevant information in a particular table. This "any table" does not specifically refer to a fixed table. For example, when the triggering conditions of a table change, the trigger for any table may also change accordingly.
[0038] According to some embodiments, a temporary table can be used to store data from any table, specifically storing newly added data or data that needs to be stored. This temporary table does not specifically refer to a particular fixed table. For example, when the stored data or the temporary table identifier changes, the temporary table can also change accordingly.
[0039] In some embodiments, a data set may be a collection of data associated with any table. This data set does not specifically refer to a fixed set. For example, the data set may change accordingly when the types or amounts of data included in it change. Similarly, the data set may change accordingly when a specific piece of data within it changes. The data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. That is, the data set may include one or more of these components.
[0040] According to some embodiments, when any table in the baseline database is triggered, the data set of the table is stored in a temporary table, wherein the data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data.
[0041] In step S13, according to the insurance application message, the first insurance application interface is called to obtain the first data from the temporary table, and in the baseline database, according to the insurance application message, the second insurance application interface is called to obtain the second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; In some embodiments, the configuration time of the second insurance application interface may be later than that of the first insurance application interface. The second insurance application interface may, for example, be an interface that reapplies system input to the system for data acquisition. The second insurance application interface may, for example, be an insurance application interface replayed in a production environment.
[0042] In some embodiments, the first data may be data collected by a first insurance application interface, and the second data may be data collected by a second insurance application interface. The "first" in the first data is used to distinguish it from the second data and does not specifically refer to a fixed set of data. For example, the first data may change accordingly when the collection time changes.
[0043] According to some embodiments, the first insurance application interface can be called to obtain first data from the temporary table based on the insurance application message, and the second insurance application interface can be called to obtain second data from the temporary table in the baseline database based on the insurance application message, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface.
[0044] In step S14, the first data and the second data are compared using configuration rules corresponding to the production environment to obtain the replay test results.
[0045] According to some embodiments, the configuration rule may be a pre-set rule. This configuration rule may, for example, be a rule that compares first data and second data. The configuration rule does not specifically refer to a single fixed rule. For example, when a modification instruction for the configuration rule is received, the configuration rule may also change accordingly. For example, when the specific content of the configuration rule changes, the configuration rule may also change accordingly.
[0046] In some embodiments, the replay test result may be the result obtained by comparing the first data and the second data. For example, the replay test result may be the result of reapplying the previously captured system input to the system and comparing whether the replayed system output is consistent with the original output. This replay test result does not refer to a specific fixed result. For example, when the acquisition time of the replay test result changes, the replay test result may also change accordingly. For example, when the first data or the second data changes, the replay test result may also change accordingly.
[0047] According to some embodiments, the first data and the second data are compared using configuration rules corresponding to the production environment to obtain the replay test results.
[0048] In some or related embodiments, insurance application messages are collected through a first insurance application interface in the production environment; if any table in the baseline database triggers an event, the data set of that table is stored in a temporary table, wherein the data set includes at least one of table name, operation type, primary key field name, and primary key field data; based on the insurance application message, the first insurance application interface is called to obtain first data from the temporary table, and in the baseline database, based on the insurance application message, a second insurance application interface is called to obtain second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; using configuration rules corresponding to the production environment, the first data and the second data are compared to obtain replay test results. Therefore, by establishing a baseline environment, standard data can be collected as a baseline database. Collected messages and data from other application interfaces can simulate a distributed environment as baseline data. After replaying the old interface in the baseline environment, triggers are used to collect data affected by the old insurance application interface. The baseline result is obtained after replaying the baseline data. Similarly, after replaying the new insurance application interface in the baseline environment, triggers are used to collect data affected by the new interface. Verification is performed using configured verification relationships. This reduces the need for manual intervention when there are many fields in the insurance application data. It also reduces the need for extensive manual investigation and analysis to find suitable verification relationships and determine whether the replay test is inaccurate, thus improving the convenience and accuracy of replay testing. Furthermore, storing relevant data in temporary tables allows for the retrieval of modified data without needing to analyze data from all logical branches. This reduces the application complexity of the technical solution, improves the convenience of replay testing, and lowers the difficulty of setting up the replay test environment.
[0049] Figure 2 This is a flowchart illustrating a replay test method according to an exemplary embodiment, such as... Figure 2 As shown, it includes the following steps: In step S21, the insurance application message is collected through the first insurance application interface in the production environment; In some embodiments, the implementing entity of this disclosure may be a network device, and the name of the network device is not limited. For example, the network device may also be called a server, a base station, or a server cluster, etc. This disclosure does not limit this.
[0050] The relevant processes can be as described above, and will not be repeated here.
[0051] According to some embodiments, the method further includes: Each table in the baseline database is assigned a corresponding trigger condition, with different tables corresponding to different trigger conditions. Therefore, different tables can correspond to different trigger conditions, and the decision to store data can be made based on the trigger conditions of each table, thus improving the accuracy of data storage.
[0052] In some embodiments, the trigger condition can be used, for example, as a condition for storing data in each table. When the trigger condition is met, the data in that table can be stored.
[0053] According to some embodiments, the method further includes: The Kafka system is used to collect a baseline data set, which includes messages from the first insurance application interface in the production environment, as well as request and return data from calling the application interface. The baseline dataset is saved to a distributed search and analysis engine; Every preset time interval, the tables corresponding to the production environment are synchronized to the baseline data set, the configuration table is obtained, and the data in the configuration table is synchronized to the baseline library.
[0054] In some implementations, the Kafka system is a high-throughput distributed publish-subscribe messaging system.
[0055] According to some embodiments, the baseline dataset does not specifically refer to a fixed set. For example, the baseline dataset may change when the request data for calling the application interface changes. Similarly, the baseline dataset may change when the time point at which it was acquired changes.
[0056] In some embodiments, the preset duration does not specifically refer to a fixed duration. For example, when a modification instruction for the preset duration is received, the preset duration may also change accordingly. For example, when different production environments correspond to different preset durations, the preset duration may also change accordingly when the production environment changes.
[0057] In some embodiments, the configuration table may be a table obtained by synchronizing the table corresponding to the production environment to the baseline data set. This configuration table does not specifically refer to a fixed table. For example, when the time point at which the configuration table is obtained changes, the configuration table may also change accordingly.
[0058] Among these, a distributed search and analysis engine can be, for example, a distributed, highly scalable, and real-time search and data analysis engine. This engine can enable the search, analysis, and exploration of large amounts of data.
[0059] According to some embodiments, the method further includes: Establish a baseline simulation (mock) environment using wiremock; In the baseline simulation environment, the request data and the return data are configured to the Wiremock service to provide a simulation interface, which is used to simulate the application call of the first insurance application interface.
[0060] According to some implementations, WireMock is an open-source testing tool that supports HTTP response stubs, request verification, proxying / interception, logging, and replay.
[0061] According to some embodiments, a baseline simulation environment can be used, for example, to simulate a test environment for externally dependent systems. A baseline simulation environment can also be used, for example, to simulate a baseline environment.
[0062] According to some embodiments, the step of calling the first insurance application interface to obtain the first data from the temporary table based on the insurance application message includes: Based on the insurance application message, the simulation interface is invoked to obtain the first data from the temporary table.
[0063] In step S22, if any table in the baseline database triggers the operation, the data set of the table is stored in a temporary table, wherein the data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. The relevant processes can be as described above, and will not be repeated here.
[0064] In step S23, according to the insurance application message, the first insurance application interface is called to obtain the first data from the temporary table, and in the baseline database, according to the insurance application message, the second insurance application interface is called to obtain the second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; The relevant processes can be as described above, and will not be repeated here.
[0065] In step S24, the first data and the second data are compared using configuration rules corresponding to the production environment to obtain the replay test results; The relevant processes can be as described above, and will not be repeated here.
[0066] In step S25, system stability information corresponding to the replay test result is obtained, and a prompt message corresponding to the system stability information is issued.
[0067] The relevant processes can be as described above, and will not be repeated here.
[0068] In some embodiments, the technical solutions of this disclosure may include: 1. Data Acquisition: Use Kafka to collect data, including messages from the old insurance application interface in the production environment, as well as request and response data from calls to other application interfaces; and save the collected data to Elasticsearch (ES). 2. Establish a baseline database environment: Configure the Jenkins pipeline to synchronize the production environment tables to the newly created baseline database at preset intervals, creating tables with the same structure; at the same time, synchronize the data of the configuration tables to the baseline database; 3. Establish an interface mock environment: Establish a baseline mock environment using Wiremock, and configure the request data and return data of other application interfaces collected in step 1 to the Wiremock service to provide mock interfaces to simulate other applications calling the insurance application interface; 4. Add triggers to all tables in the baseline database: When data is added or saved, save the table name, operation type, primary key field name, and primary key field data in a temporary table to record the data affected by this insurance application. 5. Establish baseline applications: Deploy the insurance application interface in the baseline environment, including both new and old insurance applications; 6. Establish baseline data: Use the messages collected in step 1 to call the old insurance application interface (use Wiremock to simulate calling other application interfaces). After the call is successful, query all impact data from the temporary table and save it as baseline data. 7. Replay Test: Configure a pipeline in Jenkins, use the messages collected in step 1 to call the new insurance application interface (calling other application interfaces is simulated using Wiremock), after the call is successful, query all impact data from the temporary table and save it as new data; compare the baseline data and the new data according to the pre-configured rules to obtain the replay test results.
[0069] Figure 3 This is a block diagram illustrating a playback test apparatus according to an exemplary embodiment. (Refer to...) Figure 3 The playback test apparatus 300 includes: The message acquisition unit 301 is used to collect insurance application messages through the first insurance application interface in the production environment. The temporary table acquisition unit 302 is used to store the data set of any table in the baseline database into a temporary table when any table is triggered. The data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. The data acquisition unit 303 is used to call the first insurance application interface to obtain first data from the temporary table according to the insurance application message, and to call the second insurance application interface to obtain second data from the temporary table in the baseline database according to the insurance application message, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; The replay test unit 304 is used to compare the first data and the second data using configuration rules corresponding to the production environment, and obtain the replay test results.
[0070] According to some embodiments, the message acquisition unit 301 is further configured to: The Kafka system is used to collect a baseline data set, which includes messages from the first insurance application interface in the production environment, as well as request and return data from calling the application interface. The baseline dataset is saved to a distributed search and analysis engine; Every preset time interval, the tables corresponding to the production environment are synchronized to the baseline data set, the configuration table is obtained, and the data in the configuration table is synchronized to the baseline library.
[0071] According to some embodiments, the message acquisition unit 301 is further configured to: Establish a baseline simulation environment using Wiremock; In the baseline simulation environment, the request data and the return data are configured to the Wiremock service to provide a simulation interface, which is used to simulate the application call of the first insurance application interface.
[0072] According to some embodiments, the message acquisition unit 301, when calling the first insurance application interface to obtain first data from the temporary table based on the insurance application message, is specifically used for: Based on the insurance application message, the simulation interface is invoked to obtain the first data from the temporary table.
[0073] According to some embodiments, the message acquisition unit 301 is further configured to: Obtain system stability information corresponding to the replay test results, and issue a prompt message corresponding to the system stability information.
[0074] According to some embodiments, the message acquisition unit 301 is further configured to: Set corresponding trigger conditions for each table in the baseline database, where different tables correspond to different trigger conditions.
[0075] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0076] Figure 4 This is a block diagram of a network device 400 provided in an embodiment of this disclosure. For example, the network device 400 can be provided as a network-side device. See also... Figure 4 The network device 400 includes a processing component 422, which further includes at least one processor, and memory resources represented by memory 432 for storing instructions, such as applications, that can be executed by the processing component 422. The applications stored in memory 432 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 422 is configured to execute instructions to perform any of the methods described above applied to the network-side device.
[0077] Network device 400 may also include a power supply component 427 configured to perform power management of network device 400, a wired or wireless network interface 450 configured to connect network device 400 to a network, and an input / output (I / O) interface 458. Network device 400 can operate on an operating system stored in memory 432, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.
[0078] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0079] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to the processor or controller of a general-purpose computer, special-purpose computer, or other programmable playback test apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0080] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0081] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0082] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.
[0083] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service system that addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.
[0084] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.
[0085] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A replay test method, characterized in that, include: Insurance application messages are collected through the first insurance application interface in the production environment; If any table in the baseline database triggers the operation, the data set of that table is stored in a temporary table, wherein the data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. According to the insurance application message, the first insurance application interface is called to obtain the first data from the temporary table, and in the baseline database, according to the insurance application message, the second insurance application interface is called to obtain the second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; Using configuration rules corresponding to the production environment, the first data and the second data are compared to obtain the replay test results.
2. The method according to claim 1, characterized in that, The method further includes: The Kafka system is used to collect a baseline data set, which includes messages from the first insurance application interface in the production environment, as well as request and return data from calling the application interface. The baseline dataset is saved to a distributed search and analysis engine; Every preset time interval, the tables corresponding to the production environment are synchronized to the baseline data set, the configuration table is obtained, and the data in the configuration table is synchronized to the baseline library.
3. The method according to claim 2, characterized in that, The method further includes: Establish a baseline simulation environment using Wiremock; In the baseline simulation environment, the request data and the return data are configured to the Wiremock service to provide a simulation interface, which is used to simulate the application call of the first insurance application interface.
4. The method according to claim 3, characterized in that, The step of calling the first insurance application interface to obtain the first data from the temporary table based on the insurance application message includes: Based on the insurance application message, the simulation interface is invoked to obtain the first data from the temporary table.
5. The method according to claim 1, characterized in that, The method further includes: Obtain system stability information corresponding to the replay test results, and issue a prompt message corresponding to the system stability information.
6. The method according to claim 1, characterized in that, The method further includes: Set corresponding trigger conditions for each table in the baseline database, where different tables correspond to different trigger conditions.
7. A playback test apparatus, characterized in that, include: The message acquisition unit is used to collect insurance application messages through the first insurance application interface in the production environment. The temporary table acquisition unit is used to store the data set of any table in the baseline database into a temporary table when any table is triggered. The data set includes at least one of the following: table name, operation type, primary key field name, and primary key field data. The data acquisition unit is configured to, according to the insurance application message, call the first insurance application interface to obtain first data from the temporary table, and in the baseline database, call the second insurance application interface to obtain second data from the temporary table, wherein the configuration time of the second insurance application interface is later than the configuration time of the first insurance application interface; The replay test unit is used to compare the first data and the second data using configuration rules corresponding to the production environment, and obtain the replay test results.
8. A network device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the replay test method as described in any one of claims 1 to 6.
9. A storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the network device, the network device is able to perform the replay test method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the replay test method according to any one of claims 1 to 6.