Method, apparatus, device, storage medium and computer program product for generating

Abstract

The application discloses a generation method and device, equipment, storage medium and computer program product, relates to the technical field of data processing, and the method comprises the following steps: acquiring all first migration edges of a target field, and acquiring all second migration edges of the target field which have occurred from historical change data; each first migration edge corresponds to a test scene, the test scene to which each second migration edge belongs is determined, the hit count of each test scene is obtained, and the density deviation of the corresponding test scene is determined according to each hit count; in the case that a new migration edge is generated in the target field, the new migration edge is taken as a third migration edge, the target test scene to which the third migration edge belongs is determined, and the third migration edge is reserved to the historical change data to generate shadow data of the target field according to the density deviation of the target test scene. The application can improve test efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a generation method, apparatus, device, storage medium, and computer program product. Background Technology

[0002] In database-driven business system testing, the quality of test data directly determines the effectiveness of the test. To ensure that the data in the test environment possesses both the realistic characteristics of production data and complies with privacy compliance requirements, the industry commonly adopts "shadow data" technology, which involves extracting or synthesizing datasets with consistent structure and semantics from the production environment for use in the test environment.

[0003] Existing methods for generating shadow data typically involve collecting and storing all historical change data. This means first obtaining historical change data for a field, and then writing this data into the shadow dataset according to a full retention strategy. Summary of the Invention

[0004] The main purpose of this application is to provide a generation method, apparatus, device, storage medium, and computer program product, which aims to solve the technical problem in the prior art that the full collection and storage of historical change data leads to a large amount of sampling resources being repeatedly allocated to common scenarios that have been fully covered, while some scenarios lack sufficient samples for a long time, ultimately resulting in low testing efficiency.

[0005] To achieve the above objectives, this application provides a generation method, the method comprising: Obtain all first migration edges of the target field, and obtain all second migration edges of the target field that have occurred from the historical change data. All first migration edges of the target field include all second migration edges of the target field that have occurred and all migration edges of the target field that have not occurred. The migration edges are used to characterize the numerical change relationship of the target field. Each first migration edge corresponds to a test scenario, the test scenario to which each second migration edge belongs is determined, the hit count of each test scenario is obtained, and the density deviation of the corresponding test scenario is determined based on each hit count. The density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio. When a new migration edge is generated for the target field, the new migration edge is used as the third migration edge. The target test scenario to which the third migration edge belongs is determined, and the third migration edge is retained in the historical change data to generate the shadow data of the target field according to the density deviation of the target test scenario.

[0006] In one embodiment, the step of determining the density deviation corresponding to the test scenario based on each hit count includes: Obtain the expected occurrence count of the test scenario corresponding to each of the first migration edges, and obtain the total expected occurrence count of all test scenarios corresponding to the first migration edges based on the expected occurrence count of each of the first migration edges; Based on the expected occurrence count for each and the total expected occurrence count, the preset expected occurrence percentage for the test scenario corresponding to each first migration edge is obtained; Obtain the hit count of the test scenario to which each second migration edge belongs, and obtain the total hit count of all test scenarios to which all second migration edges belong based on each hit count; Based on each hit count and the total hit count, the actual occurrence percentage of the test scenario to which each second migration edge belongs is obtained; The density deviation for each test scenario is determined based on the expected occurrence percentage and the corresponding actual occurrence percentage.

[0007] In one embodiment, before the step of using the new migration edge as the third migration edge when the target field generates a new migration edge, the method further includes: The retention probability for each density deviation is obtained for the corresponding test scenario, and the density deviation is positively correlated with the retention probability. The step of retaining the third migration edge in the historical change data to generate the shadow data of the target field based on the density deviation of the target test scenario includes: Based on the retention probability of the target test scenario, the third migration edge is retained in the historical change data to generate shadow data of the target field.

[0008] In one embodiment, the step of obtaining the retention probability corresponding to each of the density deviations for the test scenario includes: Obtain the preset nonlinear exponent, the adjustment step size of the previous period, and the sampling weight of the test scenario in the previous period; Each density deviation is adjusted according to the adjustment step size and the preset nonlinear index to obtain each adjusted density deviation; The sampling weights are adjusted according to each adjusted density deviation to obtain the adjusted sampling weights corresponding to each test scenario; The retention probability for the corresponding test scenario is obtained based on each of the adjusted sampling weights.

[0009] In one embodiment, the step of adjusting each density deviation according to the adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation includes: The number of test scenarios that meet the target in the current period is determined based on each hit count, and the total number of scenarios for all test scenarios is obtained. The scene coverage rate for the current period is determined based on the number of qualified scenarios and the total number of scenarios. If the scene coverage rate in the current period is not higher than the preset coverage threshold, each density deviation is adjusted according to the adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation. If the scene coverage rate in the current period is higher than the preset coverage threshold, the adjustment step size is attenuated according to the preset default attenuation coefficient, and each density deviation is adjusted according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation.

[0010] In one embodiment, the step of adjusting each density deviation according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation includes: Obtain the scene coverage rate of the previous period and determine the coverage increment between the scene coverage rate of the current period and the scene coverage rate of the previous period; If the coverage increment is not lower than the preset increment threshold, each density deviation is adjusted according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation. If the coverage increment is lower than a preset increment threshold, the adjustment step size after attenuation is pulled back, and each density deviation is adjusted according to the adjusted step size after the pull-back and the preset nonlinear exponent to obtain each adjusted density deviation.

[0011] In one embodiment, the step of attenuating the adjustment step size according to a preset default attenuation coefficient includes: Obtain the cycle number of the current cycle, and determine the attenuation level based on the cycle number and the preset attenuation ratio; The preset default attenuation coefficient is attenuated according to the attenuation level to obtain the attenuated preset default attenuation coefficient; The adjustment step size is attenuated by the preset default attenuation coefficient after attenuation.

[0012] In one embodiment, the step of obtaining all first migration edges of the target field includes: Obtain all possible semantic value domains for the target field, and determine the semantic label corresponding to each semantic value domain according to the first mapping table; All first migration edges of the target field are obtained by enumerating each of the semantic labels.

[0013] In one embodiment, before the step of obtaining all possible semantic value ranges of the target field, the method further includes: If the target field has the field annotation, the field annotation is obtained and parsed to obtain the first semantic tag corresponding to each semantic domain value; If the target field is a foreign key, determine the associated field in the parent table to which the foreign key points, and obtain the second semantic tag corresponding to each semantic field value in the associated field; Obtain the ending field of the target field, and infer the third semantic tag corresponding to each semantic domain value based on the ending field; Obtain the semantic value domain types and semantic value domain frequencies of the target field, and infer the fourth semantic tag corresponding to each semantic domain value based on the semantic value domain types and semantic value domain frequencies; A first mapping table is constructed based on each semantic value domain and its corresponding first semantic label, second semantic label, third semantic label, and fourth semantic label.

[0014] In one embodiment, the step of constructing a first mapping table based on each semantic value domain and the corresponding first semantic tag, second semantic tag, third semantic tag, and fourth semantic tag includes: When all the first semantic tags to the fourth semantic tags are the same, a first mapping table is constructed based on each semantic value domain and the first semantic tag, the second semantic tag, the third semantic tag, or the fourth semantic tag; If there are differences among the first semantic tags to the fourth semantic tags, obtain the first confidence level of the first semantic tag to the fourth confidence level of the fourth semantic tag, and select the target semantic tag from the first semantic tags to the fourth semantic tags to construct a first mapping table based on the first confidence level to the fourth confidence level.

[0015] In one embodiment, the first confidence level is the ratio of the number of enumerated values ​​covered by the field annotation to the different values ​​that the target field actually takes, multiplied by a first preset coefficient. The second confidence level is a second preset coefficient multiplied by the discrimination index of the parent table of the target field. The discrimination index is used to characterize the degree of dispersion of the value of the referenced field in the parent table in the data distribution. The third confidence level is a third preset coefficient, and the fourth confidence level is a fourth preset coefficient; The preset coefficients, ordered from highest to lowest, are the first preset coefficient, the second preset coefficient, the third preset coefficient, and the fourth preset coefficient.

[0016] In one embodiment, prior to the step of obtaining all first migration edges of the target field, the method further includes: Determine the field type of the target field, which is a status field, a categorical field, or an exclusion field. The status field is a field with unidirectional ordered flow characteristics. The categorical field is a field whose value has no temporal dependency. The exclusion field is a continuous numerical, free text, or timestamp type field. If the field type is the state field, perform the step of obtaining all the first migration edges of the target field.

[0017] In one embodiment, the step of mapping each first migration edge to a test scenario includes: Obtain multi-dimensional information of the target field, including all theoretically existing changed table names of the target field, the source tag of the target field, the amount segment of the target field, and the cross-transaction label of the target field; Based on the multi-dimensional information and each of the first migration edges, a multi-dimensional scene vector is constructed, and each of the multi-dimensional scene vectors corresponds to a test scene.

[0018] In one embodiment, the steps of assigning each first migration edge to a test scenario, determining the test scenario to which each second migration edge belongs, obtaining the hit count for each test scenario, and determining the density deviation corresponding to the test scenario based on each hit count include: Determine all business domains of the target field, assign each first migration edge to the corresponding business domain, and assign each first migration edge in each business domain to a test scenario in the business domain. Determine the test scenario within the business domain to which each second migration edge belongs, obtain the hit count for each test scenario within each business domain, and determine the density deviation for the corresponding test scenario within the corresponding business domain based on each hit count; The steps of generating a new migration edge in the target field, using the new migration edge as a third migration edge, determining the target test scenario to which the third migration edge belongs, and retaining the third migration edge in the historical change data to generate shadow data of the target field according to the density deviation of the target test scenario include: When a new migration edge is generated in the target field, the new migration edge is used as the third migration edge, and the target test scenario under the target business domain to which the third migration edge belongs is determined. Based on the density deviation of the target test scenario under the target business domain, the third migration edge is retained in the historical change data to generate shadow data of the target field.

[0019] Furthermore, to achieve the above objectives, this application also provides a generating apparatus, the apparatus comprising: The acquisition module is used to acquire all first migration edges of the target field and acquire all second migration edges that have occurred in the target field from historical change data. All first migration edges of the target field include all second migration edges that have occurred in the target field and all migration edges that have not occurred in the target field. The migration edges are used to characterize the numerical change relationship of the target field. The determination module is used to assign each first migration edge to a test scenario, determine the test scenario to which each second migration edge belongs, obtain the hit count of each test scenario, and determine the density deviation of the corresponding test scenario based on each hit count. The density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio. The generation module is used to, when a new migration edge is generated in the target field, take the new migration edge as the third migration edge, determine the target test scenario to which the third migration edge belongs, and retain the third migration edge in the historical change data to generate the shadow data of the target field according to the density deviation of the target test scenario.

[0020] In addition, to achieve the above objectives, this application also provides a generation apparatus, the generation apparatus comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the generation method as described above.

[0021] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the generation method described above.

[0022] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the generation method described above.

[0023] This application provides a generation method, which includes: obtaining all first migration edges of a target field, and obtaining all second migration edges that have occurred in the target field from historical change data, wherein all first migration edges of the target field include all second migration edges that have occurred in the target field and all migration edges that have not occurred in the target field, and the migration edges are used to characterize the numerical change relationship of the target field; assigning each first migration edge to a test scenario, determining the test scenario to which each second migration edge belongs, obtaining the hit count of each test scenario, and determining the density deviation of the corresponding test scenario based on each hit count, wherein the density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio; when a new migration edge is generated in the target field, using the new migration edge as a third migration edge, determining the target test scenario to which the third migration edge belongs, and retaining the third migration edge in the historical change data according to the density deviation of the target test scenario to generate shadow data of the target field.

[0024] This application defines each theoretically possible state transition relationship as an independent test scenario, and calculates the frequency of occurrence of each scenario in the actual data. Then, it calculates the density deviation between the expected proportion and the actual proportion of each scenario. Finally, it uses this density deviation as the basis for decision-making to perform differentiated sampling of new changed data. Compared with the existing full-volume collection and storage method, this application can automatically prioritize the allocation of limited storage and processing resources to under-covered test scenarios, avoiding the repeated waste of sampling resources on common scenarios that are already fully covered. Thus, under the same data volume conditions, the shadow dataset covers more complete business scenarios and improves testing efficiency. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a flowchart illustrating the method for generating the first embodiment of this application. Figure 2 This is a flowchart illustrating the second embodiment of the method for generating the present application. Figure 3 This is a flowchart illustrating the method for generating the third embodiment of this application. Figure 4 This is a flowchart illustrating the generation method of embodiment four of this application; Figure 5 This is a structural block diagram of the generating device in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the generating device in the embodiments of this application.

[0028] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0029] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0030] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0031] The main solution proposed in this application is that, in database-driven business system testing, the quality of test data directly determines the effectiveness of the test. To ensure that the data in the test environment possesses both the realistic characteristics of production data and complies with privacy compliance requirements, the industry commonly adopts "shadow data" technology, which involves extracting or synthesizing datasets with consistent structure and semantics from the production environment for use in the test environment.

[0032] Existing methods for generating shadow data typically rely on the full collection and storage of historical change data. This involves first acquiring historical change data for each field, and then writing this data into the shadow dataset using a full retention strategy. For clarity, consider an e-commerce system's order table: the `status` field in the database uses numbers 0, 1, 2, 3, and 4 to represent five business states: "Pending Payment," "Paid," "Shipped," "Refunded," and "Order Closed After Timeout." When a change record shows `status` changing from 0 to 1, this change actually represents a complete testable business scenario: "an order migrates from the pending payment state to the paid state." Here, 0 is translated into the semantic label "Pending Payment," 1 into the semantic label "Paid," and "Pending Payment → Paid" constitutes a migration edge. Semantic labels translate the raw field values ​​in the database into textual descriptions with business meaning, while migration edges represent the migration relationship from one semantic label to another. Each migration edge corresponds to an independently testable business scenario. Therefore, by collecting enough historical data, various business scenarios will naturally be reflected in the samples.

[0033] However, the full-data collection method cannot distinguish the importance and scarcity of test scenarios, resulting in a large amount of sampling resources being repeatedly allocated to common scenarios that have been fully covered, while some scenarios lack sufficient samples for a long time (such as long-tail scenarios and areas with potential high failure rates), ultimately leading to low testing efficiency with the same amount of data.

[0034] Specifically, in real-world business systems, the frequency of different migration edges (i.e., different business scenarios) varies significantly. Some high-frequency migration edges, such as "pending payment → paid," may account for over 90% of the sample size in historical changes, while a large number of low-frequency but high-risk migration edges, such as "timeout closing" (pending payment → timeout closing), "batch settlement write-back" (shipped → refunded), and "reverse status transition" (refunded → pending payment), may only account for a very small number. When the system adopts a full-data collection strategy, the shadow data will be filled with a large number of duplicate high-frequency migration edge samples, resulting in a serious waste of storage resources, while the absolute number of low-frequency migration edges remains scarce, making it difficult to support effective testing.

[0035] To address the aforementioned technical issues, this embodiment defines each theoretically possible state transition relationship as an independent test scenario. It then calculates the frequency of each scenario's occurrence in the actual data, thereby determining the density deviation between the expected and actual proportions of each scenario. Finally, using this density deviation as the basis for decision-making, it performs differentiated sampling of new changed data. Compared to existing full-data collection and storage methods, this embodiment automatically prioritizes the allocation of limited storage and processing resources to under-covered test scenarios, avoiding the repeated waste of sampling resources on already fully covered common scenarios. This allows the shadow dataset to cover more complete business scenarios under the same data volume conditions, improving testing efficiency.

[0036] It should be noted that the execution subject of the following embodiments can be a generation device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a generation device capable of performing the above functions. This embodiment does not specifically limit this. The following uses a generation device (hereinafter referred to as the device) as the execution subject to describe this embodiment and the following embodiments.

[0037] Based on this, this application proposes a generation method for the first embodiment, please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the generation method of this application. The generation method includes steps S11A to S14A: Step S11A: Obtain all first migration edges of the target field, and obtain all second migration edges that have occurred in the target field from the historical change data. The first migration edges of the target field include all second migration edges that have occurred in the target field and all migration edges that have not occurred in the target field. The migration edges are used to characterize the numerical change relationship of the target field.

[0038] It should be explained that the target fields mentioned above can refer to fields in a database table that require business semantic restoration, such as status fields, type fields, and source fields in an order table. The migration edges mentioned above can represent directed changes in the value of the target field from one numerical value to another. For example, changing the value of the order status field from 0 to 1 constitutes one migration edge, and changing it from 1 to 2 constitutes another. This can also be understood as a directed migration relationship where the target field changes from one semantic label to another. For example, changing from "pending payment" to "paid" constitutes one migration edge, and changing from "paid" to "refunded" constitutes another. The direction of the migration edges can have business meaning; from semantic label A to semantic label B and from semantic label B to semantic label A represent two different migration relationships.

[0039] It should also be explained that the aforementioned semantic tags can be used to translate the raw field values ​​stored in the database into text descriptions with business meaning. For example, the value 0 stored in the order status field can be translated as "pending payment" and the value 1 can be translated as "paid". The aforementioned "pending payment" and "paid" are semantic tags.

[0040] Understandably, the aforementioned first migration edge can refer to all theoretically feasible state migration paths that may exist in the business of the aforementioned target field, including all the second migration edges that have occurred for the aforementioned target field and all the migration edges that have not occurred for the aforementioned target field. For example, if an order status field contains five business statuses: "pending payment", "paid", "shipped", "refunded", and "order closed after timeout", then theoretically, there may be a migration relationship between any two different statuses. The system will combine these five statuses in pairs to generate all possible directed migration relationships as the first migration edge.

[0041] It is also understandable that the aforementioned second migration edge can refer to the migration relationship that has actually occurred in the historical change data of the target field. For example, if the status of an order record changes from 0 to 1 when read from the historical change log, a second migration edge of "pending payment → paid" is generated accordingly. The aforementioned historical change data can refer to all data change operations recorded in the database change log, such as insert, update, and delete operation records obtained from the database log through change data capture technology.

[0042] In the specific implementation, the device first obtains all the first migration edges that theoretically exist in the target field, and then obtains the second migration edges that have occurred in the target field from the historical change data.

[0043] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, in an e-commerce order system, the target field is the "Status" field of the order table. The value of this field is 0, 1, 2, 3, and 4, corresponding to the semantic labels "Pending Payment," "Paid," "Shipped," "Refunded," and "Order Closed After Timeout," respectively. The device first obtains all theoretical first migration edges of the "Status" field: that is, the device obtains the five semantic labels of the "Status" field, and then combines the five semantic labels in pairs to generate all possible directed migration relationships, totaling 5 × 4 = 20 first migration edges, including "Pending Payment → Paid," "Pending Payment → Order Closed After Timeout," "Paid → Refunded," and "Refunded → Pending Payment," etc. Next, the device obtains the second migration edges of the "Status" field that have occurred from historical change data: that is, it reads the order status change logs over a period of time, extracts each status change record, translates the value before the change and the value after the change into semantic labels, and generates the corresponding directed migration relationship. For example, if the log records a change in order status from 0 to 1, the device translates this as "pending payment → paid," treating it as a second migration edge. If the log also records a change in order status from 0 to 4, the device translates this as "pending payment → timed out," treating it as another second migration edge. After traversing all historical change records, the device obtains all the second migration edges that have occurred in the aforementioned "status" field.

[0044] Step S12A: Assign each first migration edge to a test scenario, determine the test scenario to which each second migration edge belongs, obtain the hit count of each test scenario, and determine the density deviation of the corresponding test scenario based on each hit count. The density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio.

[0045] It should be understood that the above test scenarios can refer to an independently testable business state transition scenario, with each test scenario corresponding to a first transition edge. For example, the transition edge "Pending payment → Paid" corresponds to one test scenario, while the transition edge "Pending payment → Timeout and order closure" corresponds to another independent test scenario.

[0046] It should also be understood that the aforementioned hit count can refer to the cumulative number of times a test scenario is hit in the historical change data. Each time a second migration edge belongs to a test scenario, the hit count of that test scenario increases by 1. For example, if there are 100 records in the historical change data that all contain the migration edge "Pending Payment → Paid", then the hit count of the corresponding test scenario is 100.

[0047] It should be noted that the density deviation mentioned above can be used to characterize the degree of deviation between the actual occurrence percentage of the corresponding test scenario in historical change data and the preset expected occurrence percentage. The actual occurrence percentage can refer to the proportion of the hit count of a certain test scenario to the total hit count of all test scenarios. The preset expected occurrence percentage can refer to the expected percentage value set by the system for each test scenario in advance, which can be used to represent the proportion of data that the test scenario should occupy under ideal conditions.

[0048] In its implementation, after acquiring all first migration edges and all second migration edges, the device can assign each first migration edge to an independent test scenario. There is a one-to-one correspondence between test scenarios and first migration edges; that is, each first migration edge uniquely corresponds to one test scenario, and each test scenario uniquely corresponds to one first migration edge.

[0049] Next, the device determines the test scenario to which each second migration edge belongs. The device can obtain the migration relationship carried by a second migration edge, match this migration relationship with all first migration edges, find the first migration edge that matches the migration relationship, and determine the test scenario corresponding to the found first migration edge as the test scenario to which the second migration edge belongs. This matching operation is performed on each second migration edge until all second migration edges are assigned to their corresponding test scenarios.

[0050] Then, the device can maintain a counter for each test scenario. Whenever a second migration edge is determined to belong to a test scenario, the device increments the counter corresponding to that test scenario by 1. After traversing all second migration edges, the device obtains the hit count for each test scenario. Finally, the device can determine the density deviation of the corresponding test scenario based on the hit count for each test scenario.

[0051] It is important to emphasize that, considering the potential differences in importance and risk levels among different test scenarios in actual business systems, the aforementioned preset expected occurrence percentages can be evenly distributed, meaning all test scenarios have the same expected percentage; alternatively, they can be configured differently based on business importance, for example, assigning a higher expected percentage to high-risk scenarios (such as timeout order closures, abnormal return requests, etc.). The specific configuration method for the aforementioned preset expected occurrence percentages can be preset by the system or manually set through a configuration interface.

[0052] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. Continuing with the aforementioned e-commerce order system example, assume that the device generates 20 first migration edges, corresponding to 20 test scenarios. The device obtains 10,000 second migration edges from historical change data. The device assigns each of the 10,000 second migration edges to its corresponding test scenario. After assignment, assume that the hit count for the test scenario "Pending Payment → Paid" is 9,000, the hit count for the test scenario "Pending Payment → Timeout Closure" is 100, the hit count for the test scenario "Paid → Refund" is 50, and the total hit count for the remaining 17 test scenarios is 850, with varying hit count distributions across test scenarios.

[0053] The aforementioned device can calculate the actual occurrence percentage of each test scenario. For example, the actual occurrence percentage of the "Pending Payment → Paid" test scenario is 9000 / 10000 = 90%, and the actual occurrence percentage of the "Pending Payment → Timeout Closure" test scenario is 100 / 10000 = 1%. Then, it obtains the preset expected occurrence percentage. Assuming the system defaults to a uniform distribution, the preset expected occurrence percentage for each test scenario is 1 / 20 = 5%. For the "Pending Payment → Paid" test scenario, the device subtracts its actual occurrence percentage of 90% from its preset expected occurrence percentage of 5%, resulting in a density deviation of -85%. For the "Pending Payment → Timeout Closure" test scenario, the device subtracts its actual occurrence percentage of 1% from its preset expected occurrence percentage of 5%, resulting in a density deviation of +4%. For the remaining 17 test scenarios with zero hits, the device subtracts its actual occurrence percentage of 0% from its preset expected occurrence percentage of 5%, resulting in a density deviation of +5%.

[0054] Step S13A: If a new migration edge is generated for the target field, the new migration edge is used as the third migration edge. The target test scenario to which the third migration edge belongs is determined, and the third migration edge is retained in the historical change data to generate the shadow data of the target field according to the density deviation of the target test scenario.

[0055] Specifically, before the step of using the new migration edge as the third migration edge when the target field generates a new migration edge, the method further includes: Step S131A: Obtain the retention probability corresponding to the test scenario based on each density deviation, wherein the density deviation is positively correlated with the retention probability.

[0056] Understandably, the aforementioned retention probability refers to the probability that changed data in a test scenario will be retained in the shadow dataset. This retention probability is positively correlated with the aforementioned density deviation; specifically, a larger density deviation (i.e., a larger coverage gap) corresponds to a higher retention probability, while a smaller density deviation (i.e., more sufficient coverage) corresponds to a lower retention probability. In this embodiment, the retention probability ranges from 0 to 1, where 0 indicates that data in the test scenario will definitely not be retained, and 1 indicates that data in the test scenario will definitely be retained.

[0057] In its implementation, after acquiring the density deviation of each test scenario, the device calculates the retention probability of the corresponding test scenario based on each density deviation. The retention probability is positively correlated with the density deviation. Specifically, a positive density deviation indicates that the actual occurrence rate of the corresponding test scenario is lower than the preset expected occurrence rate, meaning the test scenario is under-covered, and the device assigns a high retention probability to this test scenario. A negative density deviation indicates that the actual occurrence rate of the corresponding test scenario is higher than the preset expected occurrence rate, meaning the test scenario is over-covered, and the device assigns a low retention probability to this test scenario. A zero density deviation indicates that the actual occurrence rate of the corresponding test scenario is equal to the preset expected occurrence rate, and the device assigns a moderate retention probability to this test scenario.

[0058] Accordingly, the step of retaining the third migration edge in the historical change data to generate shadow data of the target field based on the density deviation of the target test scenario includes: Step S132A: Based on the retention probability of the target test scenario, retain the third migration edge in the historical change data to generate shadow data of the target field.

[0059] It is also understood that the aforementioned third migration edge can refer to a new migration relationship generated during the system operation of the target field, that is, the latest change record of the target field changing from one semantic label to another. For example, if the system captures a change record of an order status changing from "pending payment" to "paid" in real time, then this change record corresponds to a new "pending payment → paid" migration edge, which is the third migration edge.

[0060] It is important to emphasize that the aforementioned shadow data can refer to datasets extracted or synthesized from the production environment and used in the test environment. The aforementioned target test scenario can refer to the test scenario to which the aforementioned third migration edge belongs; that is, when the migration relationship corresponding to the aforementioned third migration edge is consistent with a certain first migration edge, the test scenario corresponding to that first migration edge is the target test scenario.

[0061] In its implementation, after calculating the retention probability for each test scenario, the device continuously monitors changes to the target field. When a new change record is generated for the target field, the device extracts the pre-change and post-change values ​​of the target field from the change record and translates them into pre-change and post-change semantic labels respectively based on a pre-established semantic mapping table. The device defines the directed migration relationship from the pre-change semantic label to the post-change semantic label as the newly generated third migration edge for the target field. Next, the migration relationship carried by the third migration edge is matched with all first migration edges to find the first migration edge that matches the migration relationship. The test scenario corresponding to the found first migration edge is determined as the target test scenario to which the third migration edge belongs. Finally, based on the retention probability of the target test scenario, it is decided whether to retain the third migration edge in the shadow data.

[0062] Furthermore, when the aforementioned device writes the change record corresponding to the third migration edge into the shadow database, the device first performs anonymization processing on the sensitive information fields in the change record. Anonymization processing includes, but is not limited to, replacing or obfuscating personal identification information fields such as name, phone number, ID number, and email address to generate alternative data that is consistent with the original data format but does not contain any real privacy information. The anonymized change record is then written into the shadow database according to the database table structure.

[0063] Continuing with the previous example, assume the device has already calculated the retention probability for 20 test scenarios, with the "Pending Payment → Timeout Closure" test scenario having a retention probability of 0.994. During system operation, the device captures a new order status change record: order number 1001, status changed from 0 to 4. The device translates the pre-change value 0 into the semantic label "Pending Payment" and the post-change value 4 into the semantic label "Timeout Closure," determining the new third migration edge as "Pending Payment → Timeout Closure." The device matches this third migration edge with all first migration edges, finding the test scenario corresponding to "Pending Payment → Timeout Closure" as the target test scenario. The retention probability of this target test scenario is 0.994. The device then anonymizes the change record according to this 0.994 probability and writes it into the shadow database.

[0064] In this embodiment, when a new third migration edge is generated for the target field, the device determines the target test scenario to which the third migration edge belongs, and retains the third migration edge in the historical change data to generate shadow data for the target field based on the retention probability of the target test scenario. Compared with the existing technology of collecting all change data in its entirety, the above steps in this embodiment enable data in test scenarios with insufficient coverage to be retained in the shadow data with a higher probability, while data in test scenarios that have been fully covered is retained with a lower probability. This maximizes the coverage integrity of the shadow dataset for various business scenarios with limited storage resources, and avoids the problem of low test efficiency caused by a large amount of redundant data in high-frequency scenarios and a serious lack of data in low-frequency scenarios.

[0065] Furthermore, in order to enable the coverage status of each test scenario to be tracked and quantified, in this embodiment, the steps of determining the test scenario to which each second migration edge belongs, obtaining the hit count of each test scenario, and determining the density deviation of the corresponding test scenario based on each hit count include: Step S21A: Discretize the first migration edge corresponding to each test scenario into a grid cell to construct a coverage grid; Step S22A: Determine the grid cell corresponding to the test scenario to which each of the second migration edges belongs, and obtain the hit count of each grid cell; Step S23A: Obtain the total number of grid cells in the coverage grid, and determine the density deviation corresponding to the test scene based on the total number of grid cells and the hit count of each grid cell.

[0066] It should be noted that the coverage grid mentioned above can refer to a discretized metric space composed of grid cells corresponding to all test scenarios. Each grid cell in the coverage grid uniquely corresponds to a test scenario, and the total number of grid cells is equal to the total number of test scenarios.

[0067] It should also be noted that the total number of grid cells mentioned above can refer to the sum of the number of all grid cells in the coverage grid, that is, the total number of test scenarios corresponding to all first migration edges, which can be denoted as |Ω| in this embodiment.

[0068] It should be emphasized that the density deviation in the above test scenario can be determined based on the total number of grid cells and the hit count of each grid cell. The specific calculation formula is: density deviation = preset expected occurrence percentage - actual occurrence percentage, where the preset expected occurrence percentage = 1 / total number of grid cells (under uniform distribution conditions), and the actual occurrence percentage = hit count of grid cells / sum of hit counts of all grid cells.

[0069] In its implementation, the device obtains the total number of all first migration edges and assigns an independent grid cell to each first migration edge. All grid cells together constitute the coverage grid. There is a one-to-one mapping between the grid cells in the coverage grid and the test scenarios; that is, one grid cell uniquely corresponds to one test scenario. Furthermore, the total number of grid cells in the coverage grid equals the total number of all first migration edges, which is equal to the total number of test scenarios. Next, the device obtains the migration relationship carried by a second migration edge, matches this migration relationship with all first migration edges, finds the first migration edge that matches the migration relationship, and determines the grid cell corresponding to the found first migration edge as the grid cell to which the second migration edge belongs. The device performs the above matching operation on each second migration edge until all second migration edges are assigned to their corresponding grid cells.

[0070] The above-mentioned device obtains the hit count for each grid cell, denoted as . , where k represents the k-th grid cell. Next, the total number of grid cells in the coverage grid is obtained, which is the total number of all test scenarios. The device then determines the density deviation for each test scenario based on the total number of grid cells and the hit count of each grid cell.

[0071] Furthermore, in order to calculate the density deviation, in this embodiment, the step of determining the density deviation corresponding to the test scenario based on each hit count includes: Step S31A: Obtain the expected occurrence count of the test scenario corresponding to each of the first migration edges, and obtain the total expected occurrence count of all test scenarios corresponding to the first migration edges based on the expected occurrence count of each of the first migration edges.

[0072] It should be noted that the expected occurrence count mentioned above can refer to the number of times the system expects each test scenario to be hit, pre-set. This expected occurrence count can be an absolute value or a relative weight value. Under uniform distribution, the expected occurrence count for each test scenario is the same, equal to the total number of all second transition edges divided by the total number of test scenarios. Under differentiated configuration, different test scenarios can be assigned different expected occurrence counts; for example, high-risk scenarios are assigned a higher expected occurrence count.

[0073] It should also be noted that the expected total number of occurrences mentioned above can refer to the sum of the expected number of occurrences for all test scenarios.

[0074] Step S32A: Based on the expected occurrence count of each and the total expected occurrence count, obtain the preset expected occurrence percentage of the test scenario corresponding to each first migration edge.

[0075] It is understood that the aforementioned preset expected occurrence percentage can refer to the proportion of occurrence expected for each test scenario in all test scenarios, which is set in advance. In this embodiment, the aforementioned preset expected occurrence percentage can be a relative proportion value, and its value range can be [0, 1], and the sum of the preset expected occurrence percentages of all test scenarios equals 1.

[0076] Step S33A: Obtain the hit count of the test scenario to which each second migration edge belongs, and obtain the total hit count of all test scenarios to which all second migration edges belong based on each hit count; Step S34A: Based on each hit count and the total hit count, obtain the actual occurrence percentage of the test scenario to which each second migration edge belongs; Step S35A: Determine the density deviation of the corresponding test scenario based on each expected occurrence percentage and the corresponding actual occurrence percentage.

[0077] It is also understandable that the total hit count mentioned above could refer to the sum of the hit counts for all test scenarios, i.e., the total number of all second migration edges.

[0078] In its implementation, the device first obtains the expected number of occurrences of the test scenario corresponding to each first migration edge. This expected number of occurrences can be determined by the system according to a preset distribution strategy. Under the default uniform distribution strategy, the device obtains the total number of all second migration edges, denoted as N_total, and the total number of test scenarios, denoted as |Ω|. The expected number of occurrences for each test scenario is N_total / |Ω|. Then, the expected number of occurrences for all test scenarios is summed, and the sum is taken as the total expected number of occurrences.

[0079] Next, divide the expected occurrence count of each test scenario by the total expected occurrence count mentioned above, and use the result of the division as the preset expected occurrence percentage of that test scenario. Under the uniform distribution strategy, the preset expected occurrence percentage of each test scenario is equal to 1 divided by the total number of test scenarios |Ω|, that is, the preset expected occurrence percentage of all test scenarios is 1 / |Ω|.

[0080] The aforementioned device can then read the hit count for each test scenario from the maintained counter. The above equipment sums the hit counts for all test scenarios to obtain the total hit count for all test scenarios, denoted as . , where j represents the total number of test scenarios. Then, the hit count for each test scenario is calculated. Divide by the total number of hits mentioned above The result of the division is taken as the actual proportion of the test scenario in the historical change data.

[0081] Finally, the aforementioned device can subtract the actual occurrence rate of each test scenario from the preset expected occurrence rate, and use the result of the subtraction as the density deviation of that test scenario. The mathematical expression for the density deviation is: .in, This represents the k-th test scenario. This can represent the density deviation of the k-th test scenario. This can represent the expected number of occurrences of the k-th test scenario. This can represent the total expected occurrence count of all test scenarios. This can represent the hit count for the k-th test scenario. It can represent the total hit count for all test scenarios.

[0082] Furthermore, in order to determine whether to retain based on the retention probability, in this embodiment, the step of retaining the third migration edge in the historical change data to generate the shadow data of the target field according to the retention probability of the target test scenario includes: Step S211A: Generate a random number based on the third migration edge; Step S212A: If the random number is less than or equal to the retention probability of the target test scenario, then the third migration edge is retained in the historical change data to generate the shadow data of the target field.

[0083] It should be understood that the aforementioned random number can refer to a random value generated by the device that is uniformly distributed between 0 and 1. The random number can be generated using pseudo-random number generation algorithms commonly used in the art, such as the linear congruential method or the Mason tween rotation algorithm. Of course, other methods can also be used, and this embodiment does not limit them.

[0084] In this embodiment, the random number mentioned above can be compared with the retention probability mentioned above to determine whether to retain the change record corresponding to the third migration edge in the shadow data. The retention probability mentioned above can be a probability value between 0 and 1. When the random number mentioned above is less than or equal to the retention probability mentioned above, it means that the sampling decision is successful, that is, the data is retained.

[0085] In its implementation, after calculating the retention probability for each test scenario, the device continuously monitors changes to the target field. When a new change record is generated for the target field, the device extracts the pre-change and post-change values ​​of the target field from the change record and translates them into pre-change and post-change semantic labels respectively according to a pre-established semantic mapping table. The device defines the directed migration relationship from the pre-change semantic label to the post-change semantic label as the newly generated third migration edge for the target field. Next, the device matches the migration relationship carried by the third migration edge with all first migration edges, finds the first migration edge that matches the migration relationship, and determines the test scenario corresponding to the found first migration edge as the target test scenario to which the third migration edge belongs. Then, a random number generation function is called to generate a random value r uniformly distributed between 0 and 1. The generation of the random number r is independent of the specific content of the third migration edge and is only generated by the random number generation algorithm. The retention probability P_keep of the target test scenario is obtained. The random number r is then compared with the retention probability P_keep of the target test scenario. The above random number r is compared. If the above random number r is less than or equal to the above retention probability P_keep( If the above-mentioned device performs anonymization processing on the change record corresponding to the third migration edge and writes it into the shadow database, it generates shadow data for the target field. If the above-mentioned random number r is greater than the above-mentioned retention probability P_keep( If the above device discards the change record corresponding to the third migration edge, it will not write it to the shadow database.

[0086] This embodiment uses the above-mentioned random number comparison method, which is simple to implement, has low computational overhead, and can support online sampling and decision-making for real-time data streams.

[0087] Furthermore, considering that some test scenarios may never occur, i.e., never be hit, in this embodiment, to improve the comprehensive coverage of test scenarios, after the step of retaining the third migration edge in the historical change data to generate the shadow data of the target field according to the retention probability of the target test scenario, the method further includes: Step S221A: Obtain the test scenarios where the hit count is lower than a preset count threshold, and use them as zero-hit test scenarios; Step S222A: If the duration of the hit count being lower than a preset count threshold in the zero-hit test scenario reaches a preset zero-hit duration threshold, generate shadow data of the target field in the zero-hit test scenario based on the zero-hit test scenario.

[0088] It should be noted that the aforementioned preset counting threshold can refer to a pre-set critical value used to determine whether a test scenario has a zero hit. In this embodiment, the default value of the preset counting threshold can be 1. When the hit count of a certain test scenario is lower than the aforementioned preset counting threshold of 1, it indicates that the test scenario has never been hit in the historical change data, that is, it is in a zero hit state.

[0089] It should also be noted that the aforementioned preset zero-hit duration threshold can refer to a pre-set critical duration for determining whether the zero-hit state persists for too long. The aforementioned preset zero-hit duration threshold can be 30 days. When the zero-hit state of a certain test scenario lasts for 30 days, it indicates that the natural change flow has failed to cover the scenario within this duration, and an active synthesis operation needs to be triggered.

[0090] In its implementation, the device can compare the hit count of each test scenario with the preset count threshold (default is 1). If the hit count of a test scenario is lower than the preset count threshold (i.e., hit count = 0), the device marks the test scenario as a zero-hit test scenario.

[0091] Next, the device can start timing from the moment the zero-hit test scenario is first marked as a zero-hit, and record the duration for which the zero-hit test scenario maintains a zero-hit state. This duration is compared to a preset zero-hit duration threshold (default 30 days). If the duration reaches the preset zero-hit duration threshold, it indicates that the zero-hit test scenario has not been covered throughout the 30-day natural change stream, and the natural change stream cannot provide sample data for this scenario. In this case, the device automatically generates shadow data of the target field for the zero-hit test scenario.

[0092] This embodiment defines each theoretically possible state transition relationship as an independent test scenario, and counts the frequency of occurrence of each scenario in the actual data. Then, it calculates the density deviation between the expected proportion and the actual proportion of each scenario, and determines the retention probability of each scenario based on the positive correlation of the density deviation. That is, the scenario with a larger density deviation has a higher retention probability, and the scenario with a smaller density deviation has a lower retention probability. Finally, the new changed data is sampled differentially based on the retention probability. Compared with the existing full-volume collection and storage method, this application can automatically prioritize the allocation of limited storage and processing resources to the under-covered test scenarios, avoiding the repeated waste of sampling resources on common scenarios that are already fully covered. Thus, under the same data volume conditions, the shadow dataset covers more complete business scenarios and improves testing efficiency.

[0093] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, a second embodiment of the generation method of this application is proposed, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the generation method of this application.

[0094] To obtain all theoretically existing first migration edges for the target field, such as Figure 2 As shown, in this embodiment, the step of obtaining all first migration edges of the target field includes: Step S91B: Obtain all possible semantic value domains of the target field, and determine the semantic label corresponding to each semantic value domain according to the first mapping table; Step S92B: Enumerate all the first migration edges of the target field according to each of the semantic labels.

[0095] It should be noted that the semantic value domain mentioned above can refer to the set of semantic labels corresponding to all possible values ​​of the target field in business context, which can be denoted as Ω(f). For example, the semantic value domain of the order status field is {pending payment, paid, shipped, refunded, order closed after timeout}.

[0096] It should also be noted that the aforementioned first mapping table can refer to a pre-established correspondence table used to map the original values ​​of the target field to semantic labels. For example, the first mapping table records mapping relationships such as original value 0 corresponding to the semantic label "pending payment" and original value 1 corresponding to the semantic label "paid". Each semantic label in the aforementioned semantic value domain corresponds to at least one original value in the aforementioned first mapping table.

[0097] In a specific implementation, the device can first obtain the semantic value domain through various means. In one implementation, the device reads the field annotation of the target field, parses the field annotation, extracts the enumerated value list defined in the field annotation and its corresponding semantic tags, and uses the set of semantic tags as the semantic value domain of the target field. Of course, other methods can also be used, which will not be elaborated in this embodiment. Then, each semantic tag in the semantic value domain can be traversed, and the original value corresponding to the semantic tag can be found in the first mapping table to establish a reverse mapping relationship from the semantic tag to the original value.

[0098] Then, the semantic labels in the aforementioned semantic value domain are paired up to generate all possible directed migration relationships. Specifically, let the number of semantic labels in the aforementioned semantic value domain be N. Then, the number of first migration edges generated by the device is N×(N-1). Each first migration edge represents a directed migration relationship between any two different semantic labels in the aforementioned semantic value domain, that is, a migration relationship from semantic label sem_i to semantic label sem_j, where sem_i and sem_j both belong to the aforementioned semantic value domain Ω(f), and sem_i is not equal to sem_j. The complete set of the aforementioned first migration edges can be represented as: E_all(f)={sem_i→sem_j|sem_i, sem_j∈Ω(f), sem_i≠sem_j}. Finally, all the directed migration relationships generated by enumeration can be regarded as all the first migration edges that theoretically exist in the aforementioned target field.

[0099] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. Continuing with the aforementioned e-commerce order system example, assuming the target field is the "status" field of the order table, the device obtains the semantic value domain Ω(f) of this field = {pending payment, paid, shipped, refunded, order closed due to timeout}, a total of 5 semantic tags.

[0100] The aforementioned equipment determines the following based on the first mapping table: original value 0 corresponds to "pending payment", original value 1 corresponds to "paid", original value 2 corresponds to "shipped", original value 3 corresponds to "refunded", and original value 4 corresponds to "timeout closing order". Based on these five semantic tags, all possible directed migration relationships are generated, totaling 5 × 4 = 20. These 20 first migration edges can include: "pending payment → paid", "pending payment → shipped", "pending payment → refunded", "pending payment → timeout closing order", "paid → pending payment", "paid → shipped", "paid → refunded", "paid → timeout closing order", "shipped → pending payment", "shipped → paid", "shipped → refunded", "shipped → timeout closing order", "refund → pending payment", "refund → paid", "refund → shipped", "refund → timeout closing order", "timeout closing order → pending payment", "timeout closing order → paid", "timeout closing order → shipped", "timeout closing order → refunded". The above 20 directed migration relationships are considered as all the first migration edges that theoretically exist in the above "state" field.

[0101] Since the device described in this embodiment can obtain all the theoretically possible semantic value domains of the target field, and determine the semantic label corresponding to each semantic value domain according to the first mapping table, and then enumerate all the theoretically existing first migration edges of the target field according to each semantic label, compared with the existing technology that only identifies test scenarios based on historical data, this embodiment can include all possible state migration paths in the business in the test scenario through the complete enumeration of semantic value domains, so that theoretical migration paths that have never appeared in actual data can also be identified, thereby ensuring the completeness of the test scenario.

[0102] Furthermore, in order to construct the aforementioned first mapping table, in this embodiment, before the step of obtaining all semantic value ranges that the target field can take, the following steps are also included: Step S101B: If the target field has the field annotation, obtain the field annotation and parse the field annotation to obtain the first semantic tag corresponding to each semantic domain value.

[0103] It should be noted that the above-mentioned field comments refer to descriptive text appended to fields in the database table creation statement. These comments are typically located after the field definition and are used to explain the field's business meaning, value range, or enumeration definition. For example, in the SQL statement `status tinyint COMMENT '0=Pending payment, 1=Paid, 2=Sold, 3=Refunded, 4=Timeout closing order'`, the content enclosed in single quotes is the field comment.

[0104] It should also be noted that the first semantic tag mentioned above may refer to the semantic tag obtained by parsing the above field annotations. The first semantic tag corresponds one-to-one with the values ​​in the above semantic value domain and is used to translate the original numerical values ​​in the database into text descriptions with business meaning.

[0105] In practical implementation, when the target field has field comments, the device can obtain the field comments by reading the system tables or system views of the database. For example, in a MySQL database, the device can obtain the comment information of a specified field by querying the COLUMN_COMMENT field in the information_schema.COLUMNS table. Then, the device can perform structured parsing of the field comments according to various preset matching patterns to extract the enumeration values ​​defined in the field comments and their corresponding semantic tags.

[0106] In this embodiment, the device can try the following four matching modes sequentially according to a preset priority. The first matching mode is taken as the parsing result, and subsequent modes are not tried: Mode 1, equal sign separated format: The above devices match the format "number=Chinese" or "number=English", for example, match the equal sign separated structure in "0=waiting for payment, 1=paid, 2=shipped".

[0107] Mode 2, colon-separated format: The above devices match the format "number:Chinese", "number:English", or "number:Chinese", for example, matching the colon or Chinese colon-separated structure in "0:waiting payment, 1:paid" or "0:waiting payment, 1:paid".

[0108] Mode 3, hyphen-separated format: The above devices match the format "number-Chinese" or "number-English", for example, matching the hyphen-separated structure in "0-pending payment, 1-paid".

[0109] Mode 4, bracket annotation format: The above devices match the format of "Chinese (numerals)" or "English (numerals)," for example, matching the bracket structure in "Pending payment (0), Paid (1)."

[0110] If any of the four matching modes is successful, the device extracts the mapping relationship between each pair of "original value - semantic label" from the matching result and determines the semantic label as the first semantic label corresponding to the semantic value domain. If none of the four matching modes are matched, the device determines that the field annotation does not contain a structured enumeration definition, and the device cannot obtain the first semantic label from the field annotation.

[0111] Step S102B: If the target field is a foreign key, determine the associated field in the parent table pointed to by the foreign key, and obtain the second semantic tag corresponding to each semantic field value in the associated field.

[0112] Understandably, the aforementioned foreign key can refer to a field in a database table used to establish a reference relationship with a parent table. The value of the foreign key can reference the primary key or unique key in the parent table. For example, if the user_id field in the order table references the id primary key in the user table, then user_id is a foreign key.

[0113] The parent table mentioned above can refer to the data table referenced by the foreign key, i.e., the target table pointed to by the foreign key. The related fields mentioned above can refer to fields in the parent table referenced by the foreign key, typically the primary key field of the parent table. These related fields also relate to business attribute fields in the parent table that have already been semantically labeled. For example, when the `user_id` foreign key in the order table points to the `id` primary key in the user table, the `user_level` field in the user table (which has already been semantically labeled "1=regular user, 2=VIP, 3=SVIP" through annotation parsing) is the business attribute field that needs to be propagated to the order table.

[0114] It is also understood that the second semantic tag mentioned above can refer to the semantic tag obtained from the related field of the parent table through the foreign key relationship and propagated to the current target field.

[0115] In the specific implementation, when the target field is a foreign key, the device can trigger the foreign key propagation process after completing the knowledge base query and field annotation parsing. If there is no record in the knowledge base and the field annotation does not contain a structured enumeration definition or the parsing fails.

[0116] The aforementioned device can first locate the foreign key constraint definition of the target field by querying the database metadata (e.g., querying the information_schema.KEY_COLUMN_USAGE system table in MySQL), and then extract the name of the parent table referenced by the target field from the foreign key constraint definition. Next, it extracts the name of the associated field from the foreign key constraint definition; this associated field is typically the primary key field of the parent table. Simultaneously, it can also identify business attribute fields in the parent table that already have semantic tags. These business attribute fields can reside in the same parent table as the associated field, and their semantic tags can have been pre-obtained through annotation parsing or other methods.

[0117] Then, read the established semantic value domain and semantic tag mapping relationship of the above business attribute fields, and determine the above semantic tags as the second semantic tags of the above target fields.

[0118] Step S103B: Obtain the ending field of the target field, and infer the third semantic tag corresponding to each semantic domain value based on the ending field.

[0119] It should be understood that the aforementioned ending field can refer to the last part of the character sequence in the field name of the target field, which is usually located at the end of the field name and separated by underscores. For example, for the field name order_status, its ending field is "status"; for the field name pay_type, its ending field is "type".

[0120] It should also be understood that the aforementioned third semantic tag can refer to a semantic tag inferred by analyzing the character sequence of the aforementioned ending field and matching it with a preset pattern library. The aforementioned ending field and the third semantic tag are associated through a preset mapping relationship, for example, the ending field "status" corresponds to the "status field", and the ending field "type" corresponds to the "type field".

[0121] In practical implementation, the device can first obtain the field name of the target field by reading the system table or system view of the database. For example, in a MySQL database, the device can obtain the field name of the specified field by querying the COLUMN_NAME field in the information_schema.COLUMNS table.

[0122] Next, the field names are segmented according to a preset delimiter (usually an underscore "_"), and the last part of each field name is extracted as the ending field. For example, for the field name "order_status", the device segments it into "order" and "status", and extracts "status" as the ending field; for the field name "pay_type", the device segments it into "pay" and "type", and extracts "type" as the ending field. The ending fields are then matched against a preset pattern library, which records the correspondence between ending fields and field types. Based on the matching results, the field type direction of the target field is determined, and the third semantic tag corresponding to each semantic value domain of the target field is inferred accordingly.

[0123] Step S104B: Obtain the semantic value domain types and semantic value domain frequencies of the target field, and infer the fourth semantic tag corresponding to each semantic domain value based on the semantic value domain types and semantic value domain frequencies.

[0124] It should be explained that the aforementioned semantic value range types can refer to the number of different original values ​​that the target field has actually taken in the historical change data. For example, if the target field has only taken three different values ​​(0, 1, and 2) in the historical data, then the aforementioned semantic value range types are 3.

[0125] It should also be explained that the semantic value range frequency mentioned above can refer to the number of times or percentage of each original value of the target field appears in the historical change data. For example, if the target field appears 1000 times in the historical data, with the original value 0 appearing 800 times, the original value 1 appearing 150 times, and the original value 2 appearing 50 times, then the semantic value range frequencies mentioned above are 800 times, 150 times, and 50 times, respectively.

[0126] The aforementioned fourth semantic label can refer to a semantic label inferred by analyzing the statistical distribution characteristics of the aforementioned semantic value range types and frequencies.

[0127] In the specific implementation, after the aforementioned device completes knowledge base query, field annotation parsing, foreign key propagation, and naming pattern matching, if there are no records in the knowledge base, the field annotation does not contain a structured enumeration definition or parsing fails, the target field is not a foreign key or semantic tags cannot be obtained through foreign key propagation, and the naming pattern matching fails to match a valid pattern library entry, then the aforementioned device can obtain the semantic value domain types of the target field appearing in the historical change data. The aforementioned device reads all historical records of the target field from the historical change data, performs deduplication and statistical analysis on the values ​​of the target field, and obtains the number of different original values ​​of the target field that have appeared in the historical data. This number is used as the semantic value domain type. Next, the occurrence frequency of each original value of the target field in the historical data is counted to obtain the occurrence frequency corresponding to each original value. Based on the semantic value domain types and the semantic value domain frequencies, the fourth semantic tag corresponding to each semantic value domain is inferred.

[0128] Step S105B: Construct a first mapping table based on each semantic value domain and its corresponding first semantic tag, second semantic tag, third semantic tag, and fourth semantic tag. In a specific implementation, after obtaining the semantic labels of the target field from four sources—field annotation parsing, foreign key propagation, naming pattern matching, and value range distribution inference—the device summarizes each of the semantic value ranges with the corresponding first semantic label, second semantic label, third semantic label, and fourth semantic label to construct the first mapping table of the target field.

[0129] Furthermore, in order to improve the query speed, the device can first query the confirmed knowledge base and the manual patch knowledge base before step S101B.

[0130] It should be explained that the aforementioned verified knowledge base can refer to a persistent storage unit used to store field semantic information that has been verified over a long period and has not been refuted. The records stored in the aforementioned verified knowledge base have the highest level of trust, and their confidence level is considered to be the highest value.

[0131] The aforementioned manual patching knowledge base can refer to a persistent storage unit used to store semantic information of fields that has been manually reviewed and confirmed. The semantic tags in the aforementioned manual patching knowledge base are directly specified by humans through the review interface, and their confidence level is also considered to be the highest value.

[0132] The device queries the confirmed knowledge base to check if a historical confirmed semantic tag exists for the target field. If a confirmed semantic tag for the target field exists in the confirmed knowledge base, the device directly uses the confirmed semantic tag as the semantic tag for the target field to construct the first mapping relationship.

[0133] If the confirmed semantic tag for the target field does not exist in the aforementioned confirmed knowledge base, the device continues to query the aforementioned manual patching knowledge base to check if a manual patching semantic tag for the target field exists. If a manual patching semantic tag for the target field exists in the aforementioned manual patching knowledge base, the device prioritizes using the aforementioned manual patching semantic tag as the semantic tag for the target field to construct the first mapping relationship. The aforementioned manual patching semantic tag has a higher priority than all other inference sources, and its confidence level is considered the highest value.

[0134] If neither the confirmed knowledge base nor the manual patch knowledge base contains a semantic record for the target field, the device proceeds to step S101B.

[0135] Furthermore, in order to construct the aforementioned first mapping table, the step of constructing the first mapping table based on each semantic value domain and the corresponding first semantic label, second semantic label, third semantic label, and fourth semantic label includes: Step S111B: When the first semantic tag to the fourth semantic tag are all the same, construct a first mapping table based on each semantic value domain and the first semantic tag, the second semantic tag, the third semantic tag or the fourth semantic tag; Step S112B: If there are differences among the first semantic tags to the fourth semantic tags, obtain the first confidence level of the first semantic tag to the fourth confidence level of the fourth semantic tag, and select target semantic tags from the first semantic tags to the fourth semantic tags to construct a first mapping table based on the first confidence level to the fourth confidence level.

[0136] It should be noted that the aforementioned first confidence level can refer to the quantified confidence value of the aforementioned first semantic label (obtained through field annotation parsing), which can be used to reflect the reliability of the inference source. The aforementioned second confidence level can refer to the quantified confidence value of the aforementioned second semantic label (obtained through foreign key propagation). The aforementioned third confidence level can refer to the quantified confidence value of the aforementioned third semantic label (obtained through naming pattern matching). The aforementioned fourth confidence level can refer to the quantified confidence value of the aforementioned fourth semantic label (inferred through value range distribution).

[0137] It should also be noted that the aforementioned target semantic label can refer to the semantic label ultimately selected from the aforementioned first semantic label to the aforementioned fourth semantic label according to a preset confidence comparison rule, and used to construct the aforementioned first mapping table. In this embodiment, the semantic label with the highest confidence can be selected as the aforementioned target semantic label.

[0138] In a specific implementation, after associating the semantic value domain with the first semantic label, the second semantic label, the third semantic label, and the fourth semantic label, the device compares the four semantic labels to determine whether they are all the same.

[0139] If the first to the fourth semantic tags are all the same, the device determines that the four inference sources have reached a consensus on the semantic interpretation of the semantic value domain and there is no conflict. In this case, the device directly constructs the first mapping table based on the semantic value domain and any one of the first, second, third, or fourth semantic tags.

[0140] If there are differences among the first to fourth semantic labels, the device determines that there is a conflict in the semantic interpretation of the semantic value domain by the four inference sources. In this case, the device obtains the first confidence level corresponding to the first semantic label, the second confidence level corresponding to the second semantic label, the third confidence level corresponding to the third semantic label, and the fourth confidence level corresponding to the fourth semantic label. The device compares the first to fourth confidence levels, selects the semantic label with the highest confidence level from the first to fourth semantic labels as the target semantic label, and constructs the first mapping table based on the semantic value domain and the target semantic label.

[0141] Furthermore, in order to obtain the first to fourth confidence levels mentioned above, in this embodiment, the first confidence level is the ratio of the number of enumerated values ​​covered by the field annotation to the different values ​​that actually appear in the target field multiplied by a first preset coefficient. The second confidence level is a second preset coefficient multiplied by the discrimination index of the parent table of the target field. The discrimination index is used to characterize the degree of dispersion of the value of the referenced field in the parent table in the data distribution. The third confidence level is a third preset coefficient, and the fourth confidence level is a fourth preset coefficient; The preset coefficients, ordered from highest to lowest, are the first preset coefficient, the second preset coefficient, the third preset coefficient, and the fourth preset coefficient.

[0142] It is understood that the aforementioned first preset coefficient may refer to a pre-set basic weight value used to calculate the aforementioned first confidence level. In this embodiment, the aforementioned first preset coefficient may be 0.95.

[0143] The aforementioned second preset coefficient may refer to a pre-set basic weight value used to calculate the aforementioned second confidence level. In this embodiment, the aforementioned second preset coefficient may be 0.70.

[0144] The aforementioned third preset coefficient can refer to a pre-set basic weight value used to calculate the aforementioned third confidence level. In this embodiment, the aforementioned third preset coefficient can be 0.40.

[0145] The aforementioned fourth preset coefficient can refer to a pre-set basic weight value used to calculate the aforementioned fourth confidence level. In this embodiment, the aforementioned fourth preset coefficient can be 0.30.

[0146] It is also understood that the above-mentioned discrimination index can refer to the quantitative value of the dispersion of the value of the above-mentioned referenced field in the data distribution in the above-mentioned parent table. The above-mentioned discrimination index can be calculated by "1 minus the maximum frequency ratio", where the maximum frequency ratio can be the proportion of the most frequently occurring value of the above-mentioned referenced field in the above-mentioned parent table to the total number of records.

[0147] In this embodiment, the first preset coefficient of 0.95 is greater than the second preset coefficient of 0.70, the second preset coefficient of 0.70 is greater than the third preset coefficient of 0.40, and the third preset coefficient of 0.40 is greater than the fourth preset coefficient of 0.30. This indicates that field annotation parsing is the most reliable, followed by foreign key propagation, then naming pattern matching, and value range distribution inference has the lowest reliability.

[0148] In a specific implementation, when the device determines that there is a conflict between the first semantic tag and the fourth semantic tag, it obtains the first confidence level corresponding to the first semantic tag, the second confidence level corresponding to the second semantic tag, the third confidence level corresponding to the third semantic tag, and the fourth confidence level corresponding to the fourth semantic tag.

[0149] The device calculates the first confidence level as follows: It obtains the number of enumerated values ​​covered by the field annotation, i.e., the number of successfully parsed "original value-semantic tag" mapping relationships in the field annotation. It then obtains the number of different values ​​actually appearing in the target field, i.e., the total number of original values ​​of the target field after deduplication in the historical change data. The device divides the number of enumerated values ​​covered by the field annotation by the number of different values ​​actually appearing in the target field to obtain a ratio. This ratio is multiplied by the first preset coefficient 0.95, and the product is used as the first confidence level. The upper limit of the first confidence level is no more than 0.95. For example, if the field annotation covers 5 enumerated values, and the target field actually has 5 different values, then the ratio is 5 / 5 = 1.0, and the first confidence level is 0.95 × 1.0 = 0.95.

[0150] The device calculates the second confidence level as follows: It statistically analyzes the value distribution of the referenced field in the parent table and calculates the maximum frequency percentage (the proportion of the most frequent value of the referenced field in the parent table to the total number of records). This maximum frequency percentage is subtracted from 1 to obtain the discrimination index. The discrimination index is then multiplied by the second preset coefficient of 0.70, and the product is used as the second confidence level. The upper limit of the second confidence level is no more than 0.70. For example, if the user level field in the user table has 99% ordinary users and 1% VIP users, the maximum frequency percentage is 0.99, the discrimination index is 1 - 0.99 = 0.01, and the second confidence level is 0.70 × 0.01 = 0.007.

[0151] The device calculates the third confidence level as follows: it directly obtains the third preset coefficient of 0.40 as the third confidence level. In this embodiment, the third confidence level does not depend on any data distribution or coverage calculation and is a fixed value of 0.40. If the device detects that the name of the target field matches an entry in the preset pattern library, the third confidence level is increased by 0.20 based on the 0.40, that is, the third confidence level is 0.60 (but constrained by the upper limit of 0.40, the actual value is 0.40). For example, when the name of the target field ends with "_status" and the pattern exists in the preset pattern library, the device sets the third confidence level to 0.40.

[0152] The above-mentioned device calculates the fourth confidence level as follows: the device directly obtains the fourth preset coefficient of 0.30 as the fourth confidence level. The fourth confidence level is also a fixed value of 0.30. If the device detects that the value distribution of the target field exhibits a highly concentrated characteristic (i.e., the concentration index is higher than the preset concentration threshold of 0.7), the fourth confidence level is increased by a certain value based on the above 0.30, but is constrained by the upper limit of 0.30, and the actual value is 0.30.

[0153] After obtaining the first to fourth confidence levels, the device compares the four confidence levels, selects the semantic label with the highest confidence level as the target semantic label, and constructs the first mapping table based on the target semantic label. If the difference between the highest and second-highest confidence levels is lower than a preset conflict threshold (e.g., 0.25), the device does not select any semantic label and marks the semantic value range as pending conflict.

[0154] Further, the step of selecting target semantic labels from the first semantic labels to the fourth semantic labels to construct the first mapping table based on the first confidence level to the fourth confidence level includes: Step S121B: If the difference between the highest and second highest confidence levels among the first to the fourth confidence levels is not less than a preset difference threshold, construct a first mapping table based on the semantic label corresponding to the highest confidence level among the first to the fourth confidence levels for each semantic value range as the target semantic label; It should be understood that the aforementioned preset gap threshold can refer to a pre-set critical value used to determine whether the difference between the highest confidence level and the second highest confidence level is sufficiently large. When the difference between the highest confidence level and the second highest confidence level is greater than or equal to the aforementioned preset gap threshold, it indicates that the source of the highest confidence level has a significant advantage, and the system can trust and adopt the semantic label of that source. In this embodiment, the default value of the aforementioned preset gap threshold can be set to 0.25.

[0155] It should also be understood that the aforementioned first preset confidence threshold can refer to a pre-set lower limit value used to filter high-confidence semantic tags. That is, when the confidence of a semantic tag is higher than or equal to the aforementioned first preset confidence threshold, the semantic tag is considered an acceptable high-confidence tag. In this embodiment, the default value of the aforementioned first preset confidence threshold can be set to 0.5.

[0156] Step S122B: Alternatively, take the semantic labels with confidence levels not lower than the first preset confidence threshold from the first confidence level to the fourth confidence level, and the preset undetermined labels with confidence levels higher than the second preset confidence threshold and lower than the second preset confidence threshold, and use the preset undetermined labels and the semantic labels with confidence levels not lower than the first preset confidence threshold as target semantic labels to construct a first mapping table.

[0157] It should be noted that the aforementioned second preset confidence threshold can refer to a pre-set upper limit threshold used to determine whether a semantic tag is in the medium confidence interval (uncertainty interval). When the confidence level of a semantic tag is lower than or equal to the aforementioned second preset confidence threshold, it is considered a low-confidence tag and is not adopted. When the confidence level of a semantic tag is higher than the aforementioned second preset confidence threshold but lower than the aforementioned first preset confidence threshold, the semantic tag is determined to be in the uncertainty interval.

[0158] It should also be noted that the aforementioned preset pending label can refer to a placeholder label uniformly attached to the semantic value domain within the aforementioned uncertain interval. This label can be used to mark that the semantic value domain has an original value but its semantics have not yet been confirmed. The aforementioned preset pending label is used to retain the placeholder position of the semantic value domain in the coverage grid, ensuring that the semantic value domain can still be included in the coverage statistics, while also indicating that the semantic value domain requires manual review. The default value of the aforementioned second preset confidence threshold is 0.25. The aforementioned first preset confidence threshold (0.5) is higher than the aforementioned second preset confidence threshold (0.25), and the two can constitute an uncertain interval (0.25 < confidence ≤ 0.5).

[0159] In its specific implementation, after obtaining the first to fourth confidence levels, the device selects a target semantic label from the first to fourth semantic labels based on these confidence levels, and constructs the first mapping table. This selection process can be performed using either of the following two strategies: Strategy 1: The device first compares the first to fourth confidence levels to determine the highest and second-highest confidence values. It then calculates the difference between the highest and second-highest confidence values. This difference is compared to a preset gap threshold. If the difference is greater than or equal to the preset gap threshold (default 0.25), it indicates that the inference source corresponding to the highest confidence level has a significant advantage, and the semantic label corresponding to the highest confidence level is selected as the target semantic label. A first mapping table is then constructed based on the semantic value range and the target semantic label.

[0160] Strategy Two: The device first compares the first to fourth confidence levels with the first preset confidence threshold (default 0.5). If a confidence level is greater than or equal to the first preset confidence threshold, the device adopts the semantic label corresponding to that confidence level as a high-confidence semantic label and directly uses it as the target semantic label. Next, the unadopted confidence levels from the first to the fourth confidence levels are compared with the second preset confidence threshold (default 0.25). If a confidence level is greater than the second preset confidence threshold but less than the first preset confidence threshold (i.e., within the uncertain range of 0.25 to 0.5), a preset pending label is added to the semantic value range corresponding to that confidence level. The high-confidence semantic label and the preset pending label are used together as the target semantic label to construct the first mapping table. Specifically, for semantic value ranges with a defined interval (confidence level ≥ 0.5), the first mapping table records the specific semantic labels; for semantic value ranges with an uncertain interval (0.25 < confidence level < 0.5), the first mapping table records the aforementioned preset undetermined labels. For semantic value ranges with a low confidence interval (confidence level ≤ 0.25), the device excludes contributions from this source and does not include this semantic value range in the first mapping table.

[0161] It should be emphasized that after writing the preset pending labels into the first mapping table, the device also writes the semantic value domain records corresponding to the preset pending labels into the manual review list, so that the true business meaning of the semantic value domain can be confirmed during subsequent manual review.

[0162] Furthermore, considering that a large number of semantic value domains may lead to dimensionality explosion during subsequent migration edge enumeration, in this embodiment, the step of obtaining all possible semantic value domains of the target field and determining the semantic label corresponding to each semantic value domain according to the first mapping table includes: Step S141B: Obtain all possible semantic value ranges for the target field; Step S142B: If the number of all the semantic value domains does not exceed the first preset number threshold, determine the semantic label corresponding to each semantic value domain according to the first mapping table; Step S143B: If the number of all the semantic value domains exceeds a first preset number threshold, compress all the semantic value domains and determine the semantic label corresponding to each of the compressed semantic value domains according to the first mapping table.

[0163] It should be noted that the aforementioned first preset quantity threshold can refer to a pre-set critical value used to determine whether the aforementioned semantic value domains need to be compressed. When the number of the aforementioned semantic value domains exceeds the aforementioned first preset quantity threshold, it indicates that the number of the aforementioned semantic value domains is too large, which may lead to dimensionality explosion during subsequent migration edge enumeration generation, thus requiring a compression operation to be triggered. In this embodiment, the default value of the aforementioned first preset quantity threshold can be set to 15. The aforementioned compression can refer to the operation of reducing the number of the aforementioned semantic value domains through merging or bucketing.

[0164] In a specific implementation, the device can obtain the semantic value domains as described above, and merge the semantic value domains from different sources to form a complete set of semantic value domains for the target field. Then, the total number of semantic value domains in the set is counted, denoted as M. The total number M of the semantic value domains is compared with the first preset threshold (default 15).

[0165] If the total number M of the aforementioned semantic value domains does not exceed the first preset number threshold (i.e., M≤15), the device determines that the number of the aforementioned semantic value domains is within a controllable range and no compression operation is required. At this time, the device directly queries the semantic tag corresponding to each semantic value domain in the aforementioned semantic value domain set according to the aforementioned first mapping table, and establishes a complete mapping relationship between the aforementioned semantic value domains and the aforementioned semantic tags.

[0166] If the total number M of the aforementioned semantic value domains exceeds the first preset threshold (i.e., M>15), the device determines that the number of semantic value domains is too large. If the aforementioned semantic value domains are directly used for migration edge enumeration, more than M×(M-1) migration edges will be generated (for example, when M=20, the number of migration edges is 20×19=380), which will lead to a surge in the number of grid cells in the subsequent coverage grid, possibly exceeding the global upper limit Kmax (which can be 10000 by default), resulting in a decrease in computational performance. Therefore, the device triggers a compression operation to compress all the aforementioned semantic value domains, so that the number of compressed semantic value domains does not exceed the first preset threshold. Then, based on the compressed set of semantic value domains, the device queries the first mapping table to determine the semantic label corresponding to each compressed semantic value domain.

[0167] Furthermore, to achieve compression, in this embodiment, the step of compressing all the semantic value domains and determining the semantic tag corresponding to each of the compressed semantic value domains according to the first mapping table includes: Step S151B: When all the semantic value domains are enumerated, determine the frequency of occurrence of each semantic value domain, take the semantic value domains of the second preset number threshold sequentially starting from the highest frequency, merge the remaining semantic value domains, and determine the semantic label corresponding to each semantic value domain of the second preset number threshold and each merged semantic value domain according to the first mapping table, wherein the second preset number threshold is less than the first preset number threshold.

[0168] It is understandable that the aforementioned enumeration type can refer to the value type of the aforementioned semantic value domain being discrete, exhaustive category values ​​or status values. For example, the values ​​{0, 1, 2, 3, 4} of the order status field are enumeration types. The aforementioned frequency of occurrence can refer to the number of times or frequency of occurrence of each semantic value domain (i.e., the original value) in the aforementioned historical change data.

[0169] It is also understood that the aforementioned second preset quantity threshold can refer to the upper limit of the number of semantic value domains retained after compression. The aforementioned second preset quantity threshold is less than the aforementioned first preset quantity threshold (default 15), and the default value of the aforementioned second preset quantity threshold can be set to the aforementioned first preset quantity threshold minus 1, i.e., 14. The aforementioned merging can refer to grouping multiple low-frequency semantic value domains into a unified label, for example, uniformly marking multiple values ​​with the lowest occurrence frequency as the "other" label. The aforementioned "other" label, as a merged semantic value domain, participates in subsequent migration edge enumeration and coverage calculation.

[0170] In specific implementation, when all the aforementioned semantic value domains are enumerated and the total number of the aforementioned semantic value domains exceeds the first preset quantity threshold, the device first reads each change record related to the aforementioned target field from the aforementioned historical change data, counts the occurrence frequency of each original value, and obtains the occurrence frequency corresponding to each semantic value domain. Then, it sorts all the aforementioned semantic value domains in descending order of occurrence frequency. From the sorting results, starting from the highest frequency, the aforementioned second preset quantity threshold (default 14) semantic value domains are sequentially extracted, and the extracted semantic value domains are used as reserved semantic value domains.

[0171] Simultaneously, all remaining semantic value domains (i.e., the least frequent ones) in the above sorting results are merged into a single merged semantic value domain, which can be labeled "Other". For example, if the above set of semantic value domains contains 21 semantic value domains and the second preset quantity threshold is 14, then the device retains the top 14 most frequent semantic value domains and merges the remaining 7 least frequent semantic value domains into one "Other" semantic value domain.

[0172] Next, the device determines the semantic label corresponding to each semantic value domain in the second preset threshold of retained semantic value domains according to the first mapping table. For the merged semantic value domain, the device determines the semantic label corresponding to the merged semantic value domain as "other". Finally, the retained semantic value domains and the merged semantic value domains together constitute a compressed set of semantic value domains. The number of the compressed set of semantic value domains is the second preset threshold plus 1 (i.e., 14+1=15), and does not exceed the first preset threshold of 15.

[0173] Step S152B: When all the semantic value domains are continuous, perform equal-frequency binning on all the semantic value domains to obtain the binned semantic value domains, determine the quantile of each binned semantic value domain, and determine the semantic label corresponding to the semantic value domain corresponding to each quantile according to the first mapping table.

[0174] It should be understood that the aforementioned "continuous type" can refer to the semantic value domain having continuous numerical values. For example, the order amount field can have any positive real number, which is a continuous value. The aforementioned "equal frequency binning" can refer to sorting the continuous semantic value domain according to its numerical value and then dividing it into several intervals, so that each interval contains approximately the same number of data samples. For example, after sorting 1000 amount records from smallest to largest, they can be divided into 3 intervals, each containing approximately 333 records.

[0175] It should also be understood that the semantic value domain after binning can refer to each value interval obtained after equal-frequency binning, with each value interval participating in subsequent processing as an independent discretized semantic value domain. The quantile point can refer to the boundary value used to divide the above intervals. For example, when dividing the amount field into 3 intervals, it is necessary to determine the first quantile point and the second quantile point. The first quantile point divides the data into the first 33% and the last 67%, and the second quantile point divides the data into the first 67% and the last 33%.

[0176] In specific implementation, when all the aforementioned semantic value domains are continuous and the number of such semantic value domains exceeds the first preset threshold, the device first sorts all the value records in ascending order according to their numerical values. Next, a preset number of buckets is determined, typically 3 to 5 intervals. Based on this number of buckets, the sorted value records are equally divided into the specified number of intervals, ensuring that each interval contains approximately the same number of data samples, thereby obtaining the bucketed semantic value domains.

[0177] Simultaneously, when dividing the data into intervals, the device determines the boundary values ​​of each interval as quantiles. For example, when the number of buckets is 3, the device determines the first and second quantiles. The first quantile divides the data into the first third and the last two-thirds, and the second quantile divides the data into the first two-thirds and the last third. Then, based on these quantiles, the semantic value range of each bucket is determined. For example, the first interval is from the minimum value to the first quantile, the second interval is from the first quantile to the second quantile, and the third interval is from the second quantile to the maximum value. According to the first mapping table, the semantic label corresponding to the semantic value range of each quantile is determined. The semantic value ranges after bucketing are used as a compressed set of semantic value ranges. The number of compressed semantic value ranges is equal to the number of buckets (i.e., 3 to 5), and does not exceed the first preset threshold of 15.

[0178] Furthermore, considering that there may still be some illegal migration edges, in this embodiment, the step of enumerating all the first migration edges of the target field according to each semantic label includes: Step S161B: Enumerate all theoretical migration edges of the target field according to each semantic label.

[0179] It should be noted that the theoretical transfer edges mentioned above can refer to all directed transfer relations generated based on pairwise pairings of all semantic labels in the semantic value domain. For example, if the number of semantic labels in the semantic value domain is N, then the number of theoretical transfer edges is N×(N-1), and each theoretical transfer edge represents a directed transfer relation from semantic label sem_i to semantic label sem_j (sem_i≠sem_j).

[0180] Step S162B: Prune all the theoretical migration edges according to the preset configuration rules to obtain the retained theoretical migration edges and the pruned theoretical migration edges.

[0181] It should also be noted that the aforementioned preset configuration rules can refer to a pre-defined set of rules used to determine which theoretical migration edges are legal in business and which are illegal. In this embodiment, the aforementioned preset configuration rules may include at least two types: a whitelist of legal migration edges and a blacklist of illegal migration edges.

[0182] The aforementioned retained theoretical migration edges refer to those theoretical migration edges that are deemed legal and retained according to the aforementioned preset configuration rules. The aforementioned pruned theoretical migration edges refer to those theoretical migration edges that are deemed illegal and pruned according to the aforementioned preset configuration rules.

[0183] Step S163B: Manually determine the theoretical migration edge of the trimmed edge to obtain the manually determined theoretical migration edge; Step S164B: The retained theoretical migration edge and the manually determined theoretical migration edge are taken as the first migration edge.

[0184] In its implementation, after obtaining all semantic tags of the target field, the device can enumerate and generate all theoretically existing migration edges for the target field based on these semantic tags. For example, if the semantic value domain contains five semantic tags: "pending payment," "paid," "shipped," "refunded," and "timeout clearance," the device generates 5 × 4 = 20 theoretical migration edges, including but not limited to "pending payment → paid," "pending payment → timeout clearance," "paid → shipped," "paid → refunded," "refunded → pending payment," and "timeout clearance → paid."

[0185] Next, the aforementioned device obtains a whitelist of legal migration edges and a blacklist of illegal migration edges based on the preset configuration rules. The whitelist of legal migration edges records migration edges that are permitted in the business logic, such as "Pending Payment → Paid," "Pending Payment → Timeout Closure," "Paid → Shipped," "Paid → Refund," and "Shipped → Refund." The blacklist of illegal migration edges records migration edges that are prohibited in the business logic, such as "Refund → Pending Payment," "Timeout Closure → Paid," and "Refund → Shipped." These prohibition rules indicate that these migration edges are logically impossible; for example, once an order is "Refunded" or "Timeout Closure," it is considered a final state, and no further forward or reverse state migrations are allowed.

[0186] The device then matches each theoretical migration edge with the aforementioned whitelist of legal migration edges and the aforementioned blacklist of illegal migration edges. If a theoretical migration edge appears in the whitelist of legal migration edges, the device marks it as a retained theoretical migration edge. If a theoretical migration edge appears in the blacklist of illegal migration edges, the device marks it as a pruned theoretical migration edge.

[0187] The aforementioned pruned theoretical migration edges are then used to generate review tasks and added to a manual review checklist. Manual reviewers examine each pruned theoretical migration edge in the review interface, determining whether it is indeed an illegal migration edge based on business logic. If the manual reviewer confirms the migration edge is illegal, the pruned state is maintained; if the manual reviewer determines the migration edge is actually legal (e.g., "refund → pending payment" is allowed in certain special business scenarios), the manual reviewer marks the migration edge as restored, removes it from the pruned list, and adds it to the retention list. After this manual review, the device obtains the manually reviewed theoretical migration edges, which represent the final retention state confirmed by manual review.

[0188] Finally, the theoretical migration edges that were retained and the theoretical migration edges that were manually determined (i.e., the migration edges that were manually restored) are used together as the first migration edge.

[0189] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the method for generating the third embodiment of this application.

[0190] Considering that some target fields may be unsuitable for subsequent steps, such as potential omissions, this embodiment only allows enumeration of migration edges when the target field type is suitable. This is to avoid generating meaningless migration edges for categorized fields, thus polluting the coverage mesh, and to avoid unnecessary semantic inference for excluded fields, thus wasting computational resources. Therefore, in this embodiment, before the step of obtaining all first migration edges of the target field, the following step is also included: Step S171C: Determine the field type of the target field. The field type is a status field, a sub-type field, or an exclusion field. The status field is a field with unidirectional ordered flow characteristics. The sub-type field is a field whose value has no temporal dependency. The exclusion field is a continuous numerical, free text, or timestamp type field. Step S172C: If the field type is the state field, perform the step of obtaining all the first migration edges of the target field.

[0191] It should be noted that the above field type refers to the type of the target field at the business semantic level. In this embodiment, different field types may correspond to different subsequent processing paths.

[0192] The aforementioned status fields refer to fields with unidirectional ordered flow characteristics. This unidirectional ordered flow characteristic means that the values ​​of the target fields evolve gradually in a preset direction throughout the lifecycle of the business entity. When changes occur, they follow a pattern of gradually progressing from the initial state to the final state along the preset direction. The values ​​of these status fields have temporal dependencies and directionality. For example, the order status fields "Pending Payment → Paid → Shipped → Refunded" are status fields, with values ​​flowing unidirectionally in chronological order, and rollbacks are extremely rare.

[0193] The aforementioned categorization fields can refer to fields whose values ​​have no temporal dependency. This lack of temporal dependency means that the values ​​of the target field are equal to each other, have no sequential order or direction of evolution, and exhibit random jumps or a distribution pattern without directional preference when changes occur. For example, the payment method field can have values ​​such as "Alipay," "WeChat," and "Bank Card," and since there is no sequential relationship between these three values, it is a categorization field.

[0194] The excluded fields mentioned above can be continuous numeric, free text, or timestamp fields. Continuous numeric fields are fields whose values ​​can be any real number within a certain range, such as order amount. Free text fields are fields whose values ​​are described in unstructured natural language, such as remarks. Timestamp fields are fields whose values ​​are recorded at a specific time, such as creation time. These excluded fields do not participate in the generation of migration edges or the calculation of coverage.

[0195] In specific implementation, before the device executes the step of obtaining all theoretically existing first migration edges of the target field, it can first determine the field type of the target field and determine whether the field type is a state-type field. If the field type is a state-type field, the device executes the step of obtaining all theoretically existing first migration edges of the target field. If the field type is a categorical field, the device skips the step of obtaining all first migration edges of the target field, only extracts the semantic label of the current value of the target field, and includes it in the semantic label set dimension of the test scenario, without generating migration edges. If the field type is an exclusion-type field, the device skips the steps of semantic label extraction and migration edge generation, and the original value of the exclusion-type field is retained but not included in the coverage calculation dimension of the test scenario feature vector.

[0196] Furthermore, in order to determine the field type, in this embodiment, the step of determining the field type of the target field includes: Step S181C: Obtain the annotation information of the target field; Step S182C: If the annotation information contains preset keywords, determine the field type of the target field based on the preset keywords.

[0197] It should be explained that the aforementioned annotation information may refer to descriptive text attached to fields in the database table creation statement, which may include explanations of the business meaning of the fields or definitions of enumerated values. The aforementioned preset keywords may refer to a pre-defined set of keywords used to identify field types. In this embodiment, the aforementioned preset keywords may include at least two types: a status keyword library and a category keyword library. The aforementioned status keyword library may include words such as "status," "step," "stage," "progress," "status," "phase," and "step," while the aforementioned category keyword library may include words such as "type," "method," "source," "channel," "category," and "channel."

[0198] In its implementation, the device first obtains the annotation information of the target field. It then matches this annotation information with the preset keywords. If the annotation information contains keywords from the status keyword library, the device classifies the target field as a status field; if the annotation information contains keywords from the category keyword library, the device classifies the target field as a category field; if the annotation information contains both status and category keywords, the device makes the determination according to a preset priority (status keywords take precedence over category keywords).

[0199] Step S183C: If the annotation information does not contain preset keywords, obtain the change directionality score of the target field in the historical change data, and determine the field type of the target field based on the change directionality score. The change directionality score is used to characterize the ratio of the probability that the semantic value range of the target field changes along a preset increasing direction to the probability that it changes along a preset decreasing direction.

[0200] Understandably, the aforementioned change direction score can reflect whether the target field exhibits a unidirectional evolution trend or a random jump trend in historical changes.

[0201] In a specific implementation, if the above annotation information does not contain any of the words in the above preset keywords, the above device can read each change record related to the above target field from the above historical change data, and count the number of times the value of the above target field changes in the increasing direction and the number of times it changes in the decreasing direction.

[0202] The above-mentioned change along the increasing direction can refer to the original value of the target field changing from a smaller value to a larger value (e.g., from 0 to 1, from 1 to 2), and the above-mentioned change along the decreasing direction can refer to the original value of the target field changing from a larger value to a smaller value (e.g., from 2 to 1, from 1 to 0).

[0203] The device divides the number of changes in the increasing direction by the total number of all change records to obtain the probability of change in the increasing direction, denoted as P_forward; it also divides the number of changes in the decreasing direction by the total number of all change records to obtain the probability of change in the decreasing direction, denoted as P_backward. The device then divides P_forward by P_backward, and the result of the division is taken as the change directionality score, denoted as D = P_forward / P_backward.

[0204] Step S184C: When the annotation information does not contain preset keywords and the change direction score of the target field in the historical change data cannot be obtained, determine the unique value ratio of the target field, and determine the field type of the target field according to the unique value ratio. The unique value ratio is the ratio of the number of different values ​​of the target field to the total number of records of the target field.

[0205] It is also understandable that a higher unique value ratio indicates that the target field's values ​​are more dispersed, and closer to a continuous numeric or free text field. In specific implementation, if the above annotation information does not contain any of the preset keywords, and the device cannot obtain the change directionality score of the target field in the historical change data (for example, the number of historical change samples for the target field is insufficient to calculate P_forward and P_backward), then the device can count the number of different values ​​of the target field in the historical change data, denoted as distinct_count; and count the total number of records of the target field in the historical change data, denoted as total_count. The device divides distinct_count by total_count, and the result of the division is used as the unique value ratio, denoted as U=distinct_count / total_count.

[0206] The device then compares the unique value ratio with a preset base threshold (e.g., 0.3). If the unique value ratio is higher than the preset base threshold, it indicates that the proportion of different values ​​of the target field to the total number of records is too high, and the value type of the target field is closer to continuous numerical rather than discrete enumeration. In this case, the device can classify the target field as an exclusion field. If the unique value ratio is not higher than the preset base threshold, the device will default to classifying the target field as an exclusion field and generate a manual review prompt, asking the user to confirm the actual business meaning of the field.

[0207] Furthermore, to improve the comprehensiveness of the test scenarios, in this embodiment, the step of mapping each first migration edge to a test scenario includes: Step S191C: Obtain multi-dimensional information of the target field, including all change table names that theoretically exist for the target field, the source tag of the target field, the amount segment of the target field, and the cross-transaction label of the target field; Step S192C: Construct a multi-dimensional scene vector based on the multi-dimensional information and each of the first migration edges, and assign each of the multi-dimensional scene vectors to a test scene.

[0208] It should be noted that the aforementioned multi-dimensional information can refer to a set of information in other dimensions besides the first migration edge used to describe a test scenario. In this embodiment, the aforementioned multi-dimensional information includes at least four dimensions: changed table name, source label, amount segmentation, and cross-transaction annotation.

[0209] The aforementioned change of table name can refer to the name of the data table to which the target field belongs, and can be used to distinguish fields with the same name in different data tables.

[0210] The aforementioned source tag can refer to the category tag of the source of the change trigger for the aforementioned target field. The aforementioned source tag can include two types: application change tag and implicit change tag. The aforementioned application change tag can be used to mark changes triggered by normal calls from the application, and the aforementioned implicit change tag can be used to mark changes triggered by internal database mechanisms. The aforementioned internal database mechanisms can include triggers, stored procedures, and timed event schedulers.

[0211] The aforementioned amount segmentation can refer to the amount range labels obtained by discretizing a continuous amount field through equal-frequency binning, such as "low-amount order", "medium-amount order", and "high-amount order".

[0212] The aforementioned cross-transaction annotation can refer to the annotation information used to mark whether a change record is a joint change across business domains. It includes two values: composite scenario and non-composite scenario. When the same database transaction involves field changes of multiple tables in different business domains at the same time, the aforementioned cross-transaction annotation is used to mark the composite scenario so as to identify cross-domain association scenarios in the subsequent matching process.

[0213] The aforementioned multidimensional scene vector can refer to a structured vector formed by combining each dimension of the aforementioned multidimensional information with the aforementioned first migration edge. Each dimension of the aforementioned multidimensional scene vector can take a specific value, and a specific combination of values ​​of the multidimensional scene vector uniquely corresponds to a test scene.

[0214] In the specific implementation, during the aforementioned process, after acquiring all the first migration edges, the device assigns each of the first migration edges to a test scenario.

[0215] However, in this embodiment, in order to improve comprehensiveness, the device can obtain all the change table names that theoretically exist in the target field, the source label of the target field, the amount segment of the target field, and the cross-transaction label of the target field.

[0216] The changed table name can be directly extracted from the data, while the source tag can be obtained through subsequent methods. For the amount segment, the device can determine whether the target field is an amount field. If the target field is an amount field and is determined to be an excluded field, the device can discretize the continuous amount values ​​into 3 to 5 amount intervals using equal-frequency bucketing. These amount intervals can include "low amount interval," "medium amount interval," and "high amount interval," etc., and the amount segment is used as one dimension of the multi-dimensional information. When obtaining cross-transaction annotations, the device can analyze the transaction identifier of the change record to detect whether there are field changes involving multiple tables in different business domains within the same transaction. If so, a cross-transaction annotation is added to the change record. This results in five dimensions, including all first migration edges, all changed table names, the source tag of the target field, the amount segment of the target field, and the cross-transaction annotation of the target field.

[0217] Next, the device combines the changed table name, source label, amount segment, cross-transaction label, and first migration edge to form a five-dimensional structured vector. Semantic label set can also be added as a dimension, forming a six-dimensional structured vector; however, since the semantic label set does not generate a grid, a five-dimensional approach is used. That is, the multi-dimensional scenario vector can include the changed table name, source label, amount segment, cross-transaction label, and first migration edge, and can be denoted as v = (table, trigger_src, trans_edge, amount_band, meta). Here, table is the changed table name, trigger_src is the source label (which can be SILENT / APP), trans_edge is the first migration edge, amount_band is the amount segment, and meta is the cross-transaction label.

[0218] Then, each specific value combination of the above multi-dimensional scenario vector is mapped to a test scenario. That is, each of the above first migration edges is combined with each value of the above source label, each value of the above amount segment, the above table name, and each value of the above cross-transaction label to form an independent multi-dimensional scenario vector. Each multi-dimensional scenario vector is used as an independent test scenario, that is, as an independent test grid.

[0219] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. Assume the target field is the "Status" field of the order table, and the device obtains 20 first migration edges for this field. The device may obtain three different table names (e.g., order table, order history table, order log table); source tags include "Application Change" (APP) and "Implicit Change" (SILENT); amount segments include "Low-Amount Orders" (0 to 3000 yuan), "Medium-Amount Orders" (3000 to 15000 yuan), and "High-Amount Orders" (above 15000 yuan); cross-transaction annotations include both composite and non-composite scenarios.

[0220] Based on the aforementioned multi-dimensional information, the device combines the 20 migration edges with 3 types of table names, 2 types of source tags, 3 types of amount segments, and 2 types of cross-transaction annotations using Cartesian products to construct multi-dimensional scenario vectors. For example, for the first migration edge "Pending payment → Paid", the device constructs the following multi-dimensional scenario vectors: combined with "Order Table", "Application Change Tag", "Low-Amount Order", and "Non-Composite Scenario" to form one test scenario; combined with "Order Table", "Application Change Tag", "Low-Amount Order", and "Composite Scenario" to form another test scenario; combined with "Order Table", "Application Change Tag", "High-Amount Order", and "Non-Composite Scenario" to form yet another test scenario; combined with "Order Table", "Implicit Change Tag", "Low-Amount Order", and "Non-Composite Scenario" to form yet another test scenario; and so on, combining with 3 types of table names, 2 types of source tags, 3 types of amount segments, and 2 types of cross-transaction annotations respectively.

[0221] For a single migration edge, 3 x 2 x 3 x 2 = 36 multi-dimensional scenario vectors can be constructed, corresponding to 36 test scenarios. Since the device acquires 20 first migration edges, and each first migration edge is combined with 3 types of changed table names, 2 types of source tags, 3 types of amount segments, and 2 types of cross-transaction annotations, a total of 20 x 3 x 2 x 3 x 2 = 720 multi-dimensional scenario vectors are constructed. The device then assigns these 720 multi-dimensional scenario vectors to 720 independent test scenarios. After constructing the multi-dimensional scenario vectors, each second migration edge, when assigned, is matched with these 720 multi-dimensional scenario vectors to determine the target test scenario to which each second migration edge belongs, and the hit count for the corresponding test scenario is incremented by 1. This significantly refines the granularity of test scenario segmentation, expanding from simply 20 first migration edges corresponding to 20 test scenarios to 720 test scenarios based on multi-dimensional information combinations.

[0222] Considering that in real-world business systems, a single database transaction may modify fields in multiple tables across different business domains simultaneously, processing each table independently would result in the loss of cross-table correlation information. Therefore, the aforementioned cross-transaction annotation allows scenarios involving cross-domain joint changes within the same transaction to be marked as composite scenarios. In subsequent steps, the device can merge changes from multiple tables belonging to the same transaction into a single multi-dimensional scenario vector based on these cross-transaction annotations. This enables subsequent coverage calculations to independently measure the coverage of cross-domain linkages, preventing the fragmentation and loss of cross-domain correlation information. The specific determination method and merging logic of the aforementioned cross-transaction annotation will be detailed in subsequent steps.

[0223] Furthermore, in order to obtain the source tag, the multi-dimensional information includes the source tag of the target field; The step of obtaining the multi-dimensional information of the target field includes: Step S201C: Obtain the database change log and determine the change record of the target field based on the change log; Step S202C: Obtain the session context of the target field under this change operation from the change record; Step S203C: Extract information from the session context and determine the source tag of the target field based on the extraction results and preset judgment conditions; Step S204C: Obtain the transaction identifier of the change record, group the change records according to the transaction identifier, obtain all change records belonging to the same transaction, determine the business domain to which each change record belongs, and determine the cross-transaction label of the target field according to the business domain.

[0224] It should be noted that the aforementioned change log may refer to a log file in the database system used to record all data change operations. The change log contains detailed information for each insert, update, and delete operation.

[0225] The aforementioned change record can refer to a specific change operation record related to the aforementioned target field in the change log. This change record may at least include the operation type, data values ​​before and after the change, operation timestamp, and session context information. The aforementioned session context can refer to the environmental information related to this database operation recorded in the aforementioned change record. The session context may at least include the client ID, connection username, thread type identifier, and trigger source information.

[0226] The thread type identifier mentioned above can be used to distinguish whether the current operation is a user connection thread or a background thread; the trigger source information mentioned above can be used to indicate whether the current operation is triggered by a regular user connection, a trigger, a stored procedure, or an event scheduler.

[0227] It should also be noted that the aforementioned preset judgment conditions may refer to a set of pre-defined logical rules. The aforementioned preset judgment conditions are used to determine whether the source of the change of the aforementioned target field is an application change or an implicit change based on the information in the aforementioned session context.

[0228] Understandably, the trigger source information mentioned above can be used to indicate whether the current operation was triggered by a regular user connection, a trigger, a stored procedure, or an event scheduler. The transaction identifier mentioned above can refer to a unique identifier for a database transaction in the database system; all change operations within the same transaction have the same transaction identifier. The business domain mentioned above can refer to a collection of data tables divided according to business entities; for example, all tables related to orders belong to the order domain, and all tables related to users belong to the user domain.

[0229] It is also understood that the aforementioned cross-transaction annotation can refer to annotation information used to mark whether a change record is a joint change across business domains. The aforementioned cross-transaction annotation includes two values: composite scenario and non-composite scenario. When the same database transaction involves field changes of multiple tables in different business domains at the same time, the aforementioned cross-transaction annotation value is composite scenario. When the same database transaction involves only table field changes of a single business domain, the aforementioned cross-transaction annotation value is non-composite scenario.

[0230] In practical implementation, the aforementioned device can subscribe to the database's log stream using change data capture technology to obtain all data change operations in the database in real time. It captures each insert, update, and delete operation by reading the database's binary log (such as MySQL's Binlog).

[0231] Next, the device filters out the change operations related to the target field from the change log, and extracts each change operation record related to the target field from the change log. The change record contains the transaction number of this change operation, the operation type (insert, update or delete), the data mirror before the change, the data mirror after the change, the operation timestamp, and the session context information.

[0232] The session context field is extracted from the aforementioned change record. This session context field includes at least the client ID, connection username, thread type identifier, and trigger source information. The following four key pieces of information are then extracted from the session context: the client ID value, the thread type identifier value, the trigger source information value, and the connection username value. The device then matches these four key pieces of information with the aforementioned preset judgment conditions.

[0233] In this embodiment, the above-mentioned preset judgment conditions may include the following five judgment rules. Satisfying any one of the above five judgment rules determines that the source of the change of the target field is an implicit change (i.e., SILENT): Rule 1: If the above client number is empty and the above thread type is identified as a background thread, it is determined to be an implicit change.

[0234] Rule 2: If the aforementioned trigger source information belongs to a preset database internal source set, it is determined to be an implicit change. The preset database internal source set includes event schedulers, triggers, and stored procedures.

[0235] Rule 3: If the transaction containing the above change record contains write operations to a database system table, it is determined to be an implicit change. The above database system table can refer to the system table that stores database metadata (such as the table in the mysql system database of MySQL).

[0236] Rule 4: If the transaction containing the above change record does not contain a prepared statement and the number of rows affected by the transaction exceeds the preset batch threshold, it is determined to be an implicit change. The default value of the preset batch threshold is 100 rows.

[0237] Rule 5: If the aforementioned connection username belongs to the preset set of operation and maintenance accounts, it is determined to be an implicit change. The preset set of operation and maintenance accounts includes at least the database administrator account, the data extraction account, and the scheduler account.

[0238] If none of the above five judgment rules are met, the device determines that the source of the change in the target field is an application change (i.e., an APP). Based on the judgment result, the device sets the source tag of the target field to an application change tag or an implicit change tag, and uses the source tag as one dimension of the multi-dimensional information in the construction of the multi-dimensional scene vector.

[0239] Furthermore, the device can extract the transaction identifier of the target field under the current change operation from the change record, group the change records according to the transaction identifier, and group all change records with the same transaction identifier into the same transaction group. Then, it can determine the business domain to which the change record belongs. Based on the table name of the data table involved in the change record, it can determine the business domain to which each change record belongs by querying the pre-established table-to-business domain mapping relationship. Then, it can count the number of business domain types involved in all change records within the transaction group. If there are at least two change records in the transaction group that belong to different business domains, the device sets the cross-transaction label of the target field to a composite scenario. If all change records in the transaction group belong to the same business domain, the device sets the cross-transaction label of the target field to a non-composite scenario.

[0240] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the generation method of embodiment four of this application.

[0241] Considering that after retaining the newly received third migration edge according to the retention probability, since the test scenario already exists, continuing to use the original retention probability might still lead to data duplication, affecting test efficiency. Therefore, if... Figure 4 As shown, in this embodiment, the step of obtaining the retention probability corresponding to each density deviation for the test scenario includes: Step S41D: Obtain the preset nonlinear exponent, the adjustment step size of the previous cycle, and the sampling weight of the test scenario in the previous cycle; Step S42D: Adjust each density deviation according to the adjustment step size and the preset nonlinear index to obtain each adjusted density deviation.

[0242] It should be noted that the aforementioned preset nonlinear index can refer to a pre-set exponential parameter used to control the adjustment range of sampling weights by density deviation, and can be denoted as β. This preset nonlinear index can be used to adjust the shape of the response curve of the density deviation, enabling the system to produce different degrees of response to density deviations of different magnitudes. The aforementioned adjustment step size can refer to a pre-set coefficient used to control the maximum adjustment range of weights in a single round, and can be denoted as α.

[0243] Understandably, the aforementioned sampling weights can refer to the relative importance scores of the aforementioned test scenarios in the current period, which can be denoted as w_cur( The adjusted density deviation mentioned above can refer to the product obtained by first performing an exponential operation on the density deviation and then multiplying it by the adjustment step size, i.e., α× ^β.

[0244] In its implementation, the aforementioned device can obtain a preset nonlinear exponent β, the adjustment step size α of the previous cycle, and the sampling weight w_cur of each test scenario in the previous cycle. Next, the density deviation for each test scenario was calculated. Using the aforementioned preset nonlinear exponent β as the base, the calculation is performed. ^β, then multiply the above calculation result by the above adjustment step size α, that is, calculate α× ^β, the product result is used as the adjusted density deviation mentioned above. The above device can perform the same exponential and multiplicative operations on each test scenario until the density deviation of all test scenarios is adjusted to the adjusted density deviation.

[0245] Step S43D: Adjust the sampling weights according to each adjusted density deviation to obtain the adjusted sampling weights corresponding to each test scenario; Step S44D: Obtain the retention probability of the corresponding test scenario based on each of the adjusted sampling weights.

[0246] It should be understood that the adjusted sampling weights mentioned above may refer to the updated sampling weight values ​​used in the current period for the aforementioned test scenario, denoted as w_next( ).

[0247] In its implementation, the aforementioned device obtains the adjusted density deviation (i.e., α×gap) for each test scenario. After )^β), it can be adjusted according to the following formula: w_next( =w_cur( )×(1+α×gap( )^β); Among them, w_next( ) can represent the adjusted sampling weight of the k-th test scenario in the current period, w_cur( ) represents the current sampling weight of the k-th test scenario in the previous cycle, α represents the adjustment step size of the previous cycle, β represents the preset nonlinear exponent, and gap( ) can represent the density deviation of the k-th test scenario.

[0248] The aforementioned device can perform the same weight adjustment operation on each test scenario until all test scenarios have obtained the corresponding adjusted sampling weights. Then, the adjusted sampling weights of all test scenarios can be normalized to obtain the retention probability of each test scenario.

[0249] The specific method for the above normalization process can be to find the maximum value of the adjusted sampling weights in all test scenarios, max(w_next), and then set the adjusted sampling weights w_next(w_next) for each test scenario. Divide the result by the maximum value max(w_next) and use the result as the retention probability for the corresponding test scenario. That is, P_keep( =w_next( ) / max(w_next). After the above normalization process, the retention probability of the test scenario with the highest adjusted sampling weight is 1, and the retention probabilities of the other test scenarios are between 0 and 1.

[0250] Furthermore, considering that consistently adjusting the sampling weights according to a fixed adjustment step size could easily lead to over-adjustment and neglect of already covered scenes, in this embodiment, the step of adjusting each density deviation according to the adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation includes: Step S51D: Determine the number of qualified test scenarios in the current period based on each hit count, and obtain the total number of scenarios for all test scenarios; Step S52D: Determine the scene coverage rate for the current period based on the number of qualified scenes and the total number of scenes.

[0251] It should be noted that the aforementioned number of successful tests can refer to the number of test scenarios with a hit count not lower than a preset count threshold (the default value can be 1) in the current period. The aforementioned total number of scenarios can refer to the total number of all test scenarios, i.e., the total number of grid cells in the coverage grid, which can be denoted as |Ω|. The aforementioned scenario coverage can refer to the proportion of successful tests to the total number of scenarios in the current period, which can be used to measure the proportion of test scenarios currently covered by the system to all test scenarios, and can be denoted as Cov(Ω). The formula for calculating the aforementioned scenario coverage can be the number of successful tests divided by the total number of scenarios, i.e., Cov(Ω) = number of successful tests / |Ω|.

[0252] Step S53D: If the scene coverage rate in the current period is not higher than the preset coverage threshold, adjust each density deviation according to the adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation. Step S54D: If the scene coverage rate in the current period is higher than the preset coverage threshold, the adjustment step size is attenuated according to the preset default attenuation coefficient, and each density deviation is adjusted according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation.

[0253] It is understandable that the aforementioned preset coverage threshold can refer to a pre-set critical value used to determine whether the system has reached the target coverage level, which can be denoted as: The aforementioned preset default attenuation coefficient can refer to a pre-set proportional coefficient used to attenuate the aforementioned adjustment step size, denoted as γ. The default value of the aforementioned preset default attenuation coefficient can be 0.9. The aforementioned attenuated adjustment step size can refer to the new adjustment step size value obtained by multiplying the aforementioned adjustment step size by the aforementioned preset default attenuation coefficient, i.e., α_new = α × γ.

[0254] In a specific implementation, after obtaining the scene coverage Cov(Ω) for the current period, the device can compare the scene coverage for the current period with the preset coverage threshold. In comparison, the default value for the aforementioned preset coverage threshold can be 90%.

[0255] If the scene coverage rate in the current period is not higher than the preset coverage threshold (i.e., Cov(Ω) ≤ ... This indicates that the aforementioned equipment has not yet reached the target coverage level, and the system is still in a stage where new test scenarios need to be actively explored. At this time, the aforementioned equipment can maintain the aforementioned adjustment step size α unchanged, and directly adjust each of the aforementioned density deviations according to the aforementioned adjustment step size α and the aforementioned preset nonlinear exponent β to obtain each adjusted density deviation, that is, directly execute the aforementioned adjusted density deviation calculation operation (α×gap( )^β).

[0256] If the scene coverage rate in the current period is higher than the preset coverage threshold (i.e., Cov(Ω) > 0.05), then the coverage rate in the current period is higher than the preset coverage threshold (i.e., Cov(Ω) > 0.05). This indicates that the aforementioned equipment has reached the target coverage level, and the system no longer needs to conduct large-scale active exploration. At this time, the aforementioned equipment attenuates the aforementioned adjustment step size according to the aforementioned preset default attenuation coefficient γ. The aforementioned equipment obtains the aforementioned preset default attenuation coefficient γ (the default value is 0.9), multiplies the aforementioned adjustment step size α by the aforementioned preset default attenuation coefficient γ, and obtains the attenuated adjustment step size α_new = α × γ. For example, if the current adjustment step size α = 0.3 and the preset default attenuation coefficient γ = 0.9, then the attenuated adjustment step size α_new = 0.3 × 0.9 = 0.27. Next, the aforementioned equipment adjusts each of the aforementioned density deviations according to the aforementioned attenuated adjustment step size α_new and the aforementioned preset nonlinear exponent β, and obtains each adjusted density deviation, that is, calculates α_new × gap( After completing the above comparisons and selecting or attenuating the adjustment step size, the adjusted density deviation for each test scenario is calculated using the finally determined adjustment step size, which is then used to adjust the subsequent sampling weights.

[0257] Furthermore, considering that the above method may cause the system to get stuck in a local optimum for a long time, this embodiment can temporarily increase the adjustment step size to break the deadlock when a small adjustment step size cannot find a new scenario. Specifically, the step of adjusting each density deviation according to the decayed adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation includes: Step S61D: Obtain the scene coverage rate of the previous cycle and determine the coverage increment between the scene coverage rate of the current cycle and the scene coverage rate of the previous cycle.

[0258] It should be noted that the scene coverage rate in the previous cycle mentioned above can refer to the scene coverage rate value calculated at the end of the previous feedback cycle, which can be denoted as Cov_prev. The coverage rate increment mentioned above can refer to the difference between the scene coverage rate Cov_curr in the current cycle and the scene coverage rate Cov_prev in the previous cycle, i.e., ΔCov=Cov_curr-Cov_prev. The coverage rate increment mentioned above can be used to measure the improvement in system coverage within a single feedback cycle.

[0259] Step S62D: If the coverage increment is not lower than the preset increment threshold, adjust each density deviation according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation. Step S63D: When the coverage increment is lower than the preset increment threshold, the adjustment step size after attenuation is pulled back, and each density deviation is adjusted according to the adjusted step size after pullback and the preset nonlinear exponent to obtain each adjusted density deviation.

[0260] Understandably, the aforementioned preset incremental threshold can refer to a pre-set critical value used to determine whether the exploration is in a stagnant state, which can be denoted as δ_min. When the aforementioned coverage increment is lower than the aforementioned preset incremental threshold, it indicates that the system is finding it difficult to discover new test scenarios at the current adjustment step size, i.e., it is in an exploration stagnation state. The aforementioned pullback can refer to the operation of increasing the already decayed adjustment step size back to the value before decay, used to break the exploration stagnation state. The aforementioned pullback-after adjustment step size can refer to the new adjustment step size value obtained by multiplying the aforementioned decayed adjustment step size by the reciprocal of the aforementioned preset default decay coefficient (i.e., dividing by the preset default decay coefficient γ), i.e., α_new=α / γ.

[0261] In its implementation, after calculating the scene coverage rate for the current period, the device first obtains the scene coverage rate for the previous period, denoted as Cov_prev. Then, it subtracts the current period's scene coverage rate Cov_curr from the previous period's Cov_prev, using the result as the coverage increment: ΔCov = Cov_curr - Cov_prev. Finally, it compares this coverage increment with the preset increment threshold δ_min (default value is 0.01, or 1%).

[0262] If the aforementioned coverage increment is not lower than the aforementioned preset increment threshold (i.e., ΔCov≥δ_min), it indicates that the system can still continuously discover new test scenarios under the current adjustment step size and has not entered a stagnant state. At this time, the aforementioned device keeps the aforementioned attenuated adjustment step size unchanged, and directly adjusts each of the aforementioned density deviations according to the aforementioned attenuated adjustment step size and the aforementioned preset nonlinear exponent to obtain each adjusted density deviation.

[0263] If the aforementioned coverage increment is lower than the aforementioned preset increment threshold (i.e., ΔCov < δ_min), it indicates that the system is finding it difficult to discover new test scenarios at the current adjustment step size and has entered an exploration stagnation state. At this time, the device pulls back the attenuated adjustment step size. The device obtains the aforementioned preset default attenuation coefficient γ (default 0.9), divides the attenuated adjustment step size by the aforementioned preset default attenuation coefficient γ, and obtains the pulled-back adjustment step size α_new = α / γ, that is, restoring the adjustment step size to the value before attenuation (for example, if α attenuates from 0.3 to 0.27 and then stagnates, it is pulled back to 0.3). Finally, based on the pulled-back adjustment step size and the aforementioned preset nonlinear exponent, each of the aforementioned density deviations is adjusted to obtain each adjusted density deviation.

[0264] It should be emphasized that the above pullback operation is only triggered when the coverage is lower than the preset coverage threshold and the coverage increment is lower than the preset increment threshold. If the coverage has already met the target, the pullback will not be executed.

[0265] Furthermore, considering that using a fixed preset default attenuation coefficient for attenuation could easily lead to excessive attenuation, this embodiment adopts a method of gradually attenuating the preset default attenuation coefficient. That is, the step of attenuating by adjusting the step size includes: Step S71D: Obtain the cycle number of the current cycle, and determine the attenuation degree based on the cycle number and the preset attenuation ratio; Step S72D: Attenuate the preset default attenuation coefficient according to the attenuation degree to obtain the attenuated preset default attenuation coefficient; Step S73D: Attenuate the adjustment step size using the preset default attenuation coefficient after attenuation.

[0266] It should be understood that the aforementioned cycle number can refer to the number of feedback cycles experienced by the system from startup, denoted as t. The aforementioned cycle number increases by 1 for each round of coverage calculation and weight adjustment. The aforementioned preset attenuation ratio can refer to a pre-set rate parameter, denoted as η, used to control the attenuation of the preset default attenuation coefficient as the cycle number increases. The default value of the aforementioned preset attenuation ratio is 10% (i.e., 0.1).

[0267] It should also be understood that the above-mentioned attenuation level can refer to the specific magnitude of attenuation required by the preset default attenuation coefficient in the current cycle, that is, the above-mentioned preset attenuation ratio η multiplied by the above-mentioned cycle number t. For example, when η=10% and t=1, the attenuation level is 10%; when t=2, the attenuation level is 20%.

[0268] In the specific implementation, if the scene coverage in the current cycle is higher than the preset coverage threshold, the cycle number t of the current cycle is first obtained. The preset attenuation ratio η is multiplied by the cycle number t, and the product is used as the attenuation level, i.e., attenuation level = η × t. Since the default value of η is 10%, the attenuation level is 10% in the first cycle, 20% in the second cycle, 30% in the third cycle, and so on, accumulating 10% in each cycle.

[0269] Next, the aforementioned attenuation level is subtracted from the preset default attenuation coefficient γ, and the result of the subtraction is taken as the preset default attenuation coefficient after attenuation, i.e., γ_new = γ - (η × t). For example, when γ = 0.9, η = 10%, and t = 1, γ_new = 0.9 - 0.1 = 0.8; when t = 2, γ_new = 0.9 - 0.2 = 0.7; and when t = 3, γ_new = 0.9 - 0.3 = 0.6. The preset default attenuation coefficient after attenuation decreases by 10% with each cycle.

[0270] Next, multiply the above adjustment step size α by the preset default attenuation coefficient γ_new, and use the product as the attenuated adjustment step size α_new, that is, α_new=α×γ_new=α×[γ-(η×t)]. For example, if the current adjustment step size α=0.3, γ=0.9, η=10%, and t=1, then γ_new=0.8, α_new=0.3×0.8=0.24; when t=2, γ_new=0.7, α_new=0.3×0.7=0.21; and when t=3, γ_new=0.6, α_new=0.3×0.6=0.18.

[0271] The aforementioned equipment uses the above method to accelerate the decay of the adjustment step size round by round after the coverage rate reaches the target, and the system gradually shifts from an active exploration mode to a stable maintenance mode.

[0272] Furthermore, to constrain the sampling weights, the sampling weights cannot be too small or less than 0, to prevent situations where, for example, even if a certain test scenario has sufficient coverage, it cannot be completely ignored. Conversely, the sampling weights cannot be too large, otherwise, the entire sampling budget might be spent on covering an extremely unpopular scenario. Therefore, in this embodiment, the step of obtaining the retention probability of the corresponding test scenario based on each adjusted sampling weight includes: Step S81D: If the adjusted sampling weight is less than the preset minimum threshold, set the adjusted sampling weight to the preset minimum threshold to obtain the minimum sampling weight, and obtain the retention probability corresponding to the test scenario based on the minimum sampling weight; Step S82D: If the adjusted sampling weight is higher than the preset maximum threshold, set the adjusted sampling weight to the preset maximum threshold to obtain the maximum sampling weight, and obtain the retention probability of the corresponding test scenario based on the maximum sampling weight.

[0273] It should be noted that the aforementioned preset minimum threshold can refer to a pre-set lower limit of the sampling weight, denoted as w_min, and the default value of the aforementioned preset minimum threshold is 0.01. When the adjusted sampling weight of a certain test scenario is lower than the aforementioned preset minimum threshold, the device will forcibly set the sampling weight of that test scenario to the aforementioned preset minimum threshold to prevent any test scenario from being completely abandoned for sampling.

[0274] It should also be noted that the aforementioned preset maximum threshold can refer to a pre-set upper limit for sampling weights, denoted as w_max, with a default value of 10.0. When the adjusted sampling weight of a test scenario exceeds the aforementioned preset maximum threshold, the device will forcibly set the sampling weight of that test scenario to the aforementioned preset maximum threshold to prevent a single test scenario from monopolizing the entire sampling budget.

[0275] It is understandable that the aforementioned minimum sampling weight can refer to the sampling weight value obtained after the aforementioned preset minimum threshold truncation process, that is, when the adjusted sampling weight is lower than w_min, w_min is used. The aforementioned maximum sampling weight can refer to the sampling weight value obtained after the aforementioned preset maximum threshold truncation process, that is, when the adjusted sampling weight is higher than w_max, w_max is used.

[0276] In the specific implementation, after obtaining the adjusted sampling weights for each test scenario, the aforementioned device can obtain a preset minimum threshold w_min (default value is 0.01). For each test scenario, the adjusted sampling weight w_next( The above-mentioned device will adjust the sampling weights w_next( It is compared with the preset minimum threshold w_min mentioned above.

[0277] If the above adjusted sampling weight w_next( If the sample weight is less than the preset minimum threshold w_min, the device sets the adjusted sampling weight to the preset minimum threshold w_min to obtain the minimum sampling weight for the test scenario. The minimum sampling weight is then used in subsequent normalization processing; that is, the retention probability of the test scenario is w_min / max(w).

[0278] Meanwhile, the aforementioned devices acquire a preset maximum threshold w_max (default value is 10.0). For each test scenario, the adjusted sampling weight w_next( ), and the above adjusted sampling weights w_next( It is compared with the preset maximum threshold w_max mentioned above.

[0279] If the above adjusted sampling weight w_next( If the sample weight is higher than the preset maximum threshold w_max, the device will set the adjusted sample weight to the preset maximum threshold w_max to obtain the highest sample weight for the test scenario. The highest sample weight will then be used in subsequent normalization processing, meaning the retention probability of the test scenario is w_max / max(w) (when the weights of all test scenarios are truncated to w_max, the retention probability is 1).

[0280] Finally, after performing the aforementioned truncation process on all test scenarios, the device normalizes all truncated sampling weights to obtain the retention probability of each test scenario. This ensures that each test scenario still has a greater than zero retention probability even with extremely comprehensive coverage, preventing the omission of potential future business changes due to completely abandoning a scenario. Simultaneously, it prevents a single test scenario from acquiring excessively high sampling weights due to extreme density deviations and monopolizing the entire sampling budget, thus guaranteeing the stability of the sampling strategy and fairness among the test scenarios.

[0281] Furthermore, considering that the frequency of changes in different service domains varies too much, causing high-frequency domain samples to overwhelm low-frequency domain coverage gaps, in this embodiment, The steps of assigning each first migration edge to a test scenario, determining the test scenario to which each second migration edge belongs, obtaining the hit count for each test scenario, and determining the density deviation corresponding to the test scenario based on each hit count include: Step S141D: Determine all business domains of the target field, assign each first migration edge to the corresponding business domain, and assign each first migration edge in each business domain to a test scenario in the business domain. Step S142D: Determine the test scenario within the business domain to which each second migration edge belongs, obtain the hit count of each test scenario within each business domain, and determine the density deviation of the corresponding test scenario within the corresponding business domain based on each hit count; The steps of generating a new migration edge in the target field, using the new migration edge as a third migration edge, determining the target test scenario to which the third migration edge belongs, and retaining the third migration edge in the historical change data to generate shadow data of the target field according to the density deviation of the target test scenario include: Step S143D: If a new migration edge is generated in the target field, the new migration edge is used as the third migration edge, and the target test scenario under the target business domain to which the third migration edge belongs is determined. Step S144D: Based on the density deviation of the target test scenario under the target business domain, retain the third migration edge in the historical change data to generate the shadow data of the target field.

[0282] It should be noted that the aforementioned business domain can refer to a set of data tables divided according to business entities. For example, all tables related to orders (including the order table, order history table, order log table, etc.) belong to the order domain, and all tables related to users belong to the user domain. These business domains are used to isolate test scenarios for different business entities, allowing each business domain to independently perform coverage measurement and sampling decisions, avoiding interference between scenarios from different business entities. The aforementioned density deviation can be used to characterize the degree of deviation between the actual occurrence percentage of the corresponding test scenario in the aforementioned historical change data and the preset expected occurrence percentage, which can be denoted as gap(…). ),in This represents the k-th test scenario.

[0283] In its implementation, after acquiring all first migration edges, the device first determines the business domain to which the target field belongs. The device can determine the business domain to which the target field belongs by querying a pre-established mapping relationship between tables and business domains, based on the table name containing the target field.

[0284] Next, the device acquires all business domains of the target field. In one implementation, the table containing the target field belongs to only one business domain, and that business domain is identified as the business domain of the target field. In another implementation, the table containing the target field may involve multiple business domains simultaneously (e.g., cross-domain join tables), and all business domains involved in the target field are identified as the business domain of the target field.

[0285] After determining all business domains for the aforementioned target field, each of the aforementioned first migration edges is assigned to its corresponding business domain. Specifically, the device queries the business domain to which the table name belongs based on the table name containing the target field corresponding to the first migration edge, assigns the first migration edge to that business domain, and then groups all the first migration edges according to their respective business domains, so that each business domain contains all the first migration edges belonging to that business domain. Next, each of the aforementioned first migration edges within each of the aforementioned business domains is assigned to a test scenario within that business domain. That is, within each of the aforementioned business domains, each first migration edge independently corresponds to a test scenario, and test scenarios between different business domains are isolated from each other.

[0286] Subsequently, the aforementioned device determines the test scenario within the business domain to which each of the aforementioned second migration edges belongs. The device acquires the numerical change relationship carried by a second migration edge, matches this numerical change relationship with all first migration edges, finds the first migration edge that matches the numerical change relationship, and then determines the test scenario within the business domain to which the second migration edge belongs based on the business domain and corresponding test scenario of the found first migration edge. This matching operation is performed on each second migration edge until all second migration edges are assigned to the corresponding test scenario within their respective business domains.

[0287] Next, the aforementioned device maintains a counter for each test scenario within each business domain. Whenever a second migration edge is determined to belong to a test scenario within a business domain, the device increments the counter corresponding to that test scenario by 1. After traversing all second migration edges, the device obtains the hit count for each test scenario within each business domain.

[0288] Finally, the aforementioned device determines the density deviation of the corresponding test scenario within each business domain based on the hit count of each test scenario within each business domain. The device calculates the density deviation within each business domain by comparing the hit count of the test scenario with the sum of the hit counts of all test scenarios within that business domain, and then calculating the density deviation of the test scenario based on a preset expected occurrence percentage.

[0289] When making a retention decision in the subsequent process, if a new migration edge is generated in the target field, the device will take the new migration edge as the third migration edge, determine the numerical change relationship corresponding to the third migration edge, match the numerical change relationship with all the first migration edges, find the first migration edge that matches the numerical change relationship, determine the target business domain to which the third migration edge belongs based on the business domain of the first migration edge found, and then determine the target test scenario of the third migration edge in the target business domain based on the test scenario corresponding to the first migration edge found.

[0290] Subsequently, the aforementioned device acquires the density deviation of the target test scenario under the target business domain, and determines whether to retain the third migration edge in the historical change data to generate shadow data for the target field based on the density deviation. The density deviation is positively correlated with the retention probability; that is, the larger the density deviation, the higher the probability that the third migration edge will be retained in the shadow data.

[0291] Compared to the existing technology that mixes all test scenarios together to calculate coverage metrics, this embodiment allows each service domain to conduct coverage assessment independently. This avoids the situation where high-frequency domain samples overwhelm low-frequency domain coverage gap signals due to excessively different frequencies of changes in different service domains. It enables each service domain to independently identify and prioritize the supplementation of coverage-deficient scenarios, thereby ensuring balanced coverage of test scenarios in each domain even in multi-service domain scenarios.

[0292] Furthermore, in order to obtain the aforementioned business domains, in this embodiment, the step of determining all business domains of the target field includes: Step S151D: Obtain the table name of the data table where the target field is located, and use the table name of the data table as the first business domain of the target field; Step S152D: Obtain the foreign key constraint information of the data table where the target field is located. If the foreign key constraint information indicates that the data table has a foreign key pointing to the parent table, obtain the table name of the parent table. Step S153D: If the table name of the data table where the target field is located does not satisfy at least one of the conditions of inclusion relationship and N:1 cardinality relationship with the table name of the parent table, the first business domain shall be used as the business domain of the target field. Step S154D: Or, if the table name of the data table contains the prefix of the table name of the parent table and the foreign key is an N:1 cardinality relationship, the table name of the parent table is used as the second business domain of the target field, and the second business domain is used as the business domain of the target field. Step S155D: Alternatively, query a preset business domain mapping table. If there is a business domain overriding record corresponding to the table name of the data table where the target field is located in the preset business domain mapping table, determine the business domain in the business domain overriding record as the third business domain of the target field, and use the third business domain as the business domain of the target field.

[0293] It should be noted that the foreign key constraint information mentioned above can be the metadata of foreign key constraints defined in the database table structure. The foreign key constraint information mentioned above includes at least the foreign key field name, the name of the parent table it references, and the name of the parent table field it references.

[0294] It should also be noted that the parent table mentioned above can be the data table referenced by the foreign key, that is, the target table pointed to by the foreign key. The N:1 cardinality relationship mentioned above can refer to a foreign key reference relationship where multiple child table records correspond to one parent table record, that is, the foreign key field can appear repeatedly in the child table, while the primary key field of the parent table remains unique.

[0295] Understandably, the aforementioned inclusion relationship can refer to the determination of whether a string contains another string as its prefix, for example, the string "t_order_log" contains the string "t_order" as its prefix. The aforementioned preset business domain mapping table can refer to a persistent storage structure that is pre-established and stored in the knowledge base to record the mapping relationship between data table names and business domains. The aforementioned preset business domain mapping table can be manually written to and modified through the configuration interface.

[0296] It is also understood that the aforementioned business domain overriding record may refer to the business domain configuration entry stored in the aforementioned preset business domain mapping table for a certain data table name, which is used to overridden the automatic inference results.

[0297] In its implementation, when determining the business domain of the target field, the device first obtains the table name of the data table containing the target field and uses that table name as the first business domain of the target field. This first business domain serves as the initial value for the business domain of the target field.

[0298] Next, the device obtains the foreign key constraint information of the data table containing the target field. The device obtains this information by querying the database's system tables or system views. This information records whether the data table has a foreign key, the name of the parent table the foreign key points to, and the cardinality of the foreign key. Based on this foreign key constraint information, the device determines whether the data table has a foreign key pointing to the parent table. If the foreign key constraint information indicates that the data table has a foreign key pointing to the parent table, the device obtains the name of the parent table.

[0299] Based on the relationship between the table names of the aforementioned data tables and the table names of the aforementioned parent tables, the business domain of the aforementioned target field is determined according to at least one of the following three methods: Method 1: If the table name of the data table containing the target field does not satisfy at least one of the conditions of inclusion relationship and N:1 cardinality relationship with the table name of the parent table, the device will use the first business domain as the business domain of the target field. That is, if the table name of the data table does not contain the prefix of the parent table name, or the foreign key cardinality relationship is not an N:1 cardinality relationship, the device will not merge business domains and will keep the business domain of the target field as the first business domain.

[0300] Method 2: If the table name of the aforementioned data table contains the prefix of the parent table name, and the aforementioned foreign key has an N:1 cardinality relationship, the aforementioned device will use the parent table name as the second business domain of the aforementioned target field, and the aforementioned second business domain as the business domain of the aforementioned target field. That is, when both the naming common origin condition and the foreign key combination relationship condition are met, the aforementioned device will merge the child table into the business domain corresponding to the parent table.

[0301] Method 3: The device queries a preset service domain mapping table. If a service domain overriding record exists in the preset service domain mapping table corresponding to the table name of the data table containing the target field, the device determines the service domain in the service domain overriding record as the third service domain of the target field and uses the third service domain as the service domain of the target field. That is, manually configured service domain mapping has the highest priority, overriding the automatic inference results of Methods 1 and 2.

[0302] It should be noted that there is a priority relationship between Method 1, Method 2, and Method 3. After the device determines the business domain of the target field according to the automatic inference rules of Method 1 and Method 2, it then performs the query operation of Method 3, using the overriding record in the preset business domain mapping table as the final determination basis. When a corresponding record exists in the preset business domain mapping table, the device overwrites the first or second business domain with the third business domain; when no corresponding record exists in the preset business domain mapping table, the device uses the determination result of Method 1 or Method 2 as the business domain of the target field.

[0303] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, the device obtains that the table name of the data table containing the target field is "t_order_log", and uses "t_order_log" as the first business domain of the target field. Querying the database metadata information reveals that the "t_order_log" table has a foreign key constraint, which points to the primary key field of the parent table "t_order", and the foreign key cardinality is N:1. The data table name "t_order_log" is compared with the parent table name "t_order" to determine if "t_order_log" contains the prefix "t_order". The comparison result is yes; simultaneously, the foreign key cardinality is determined to be N:1, which satisfies the condition. The parent table name "t_order" is used as the second business domain of the target field, and "t_order" is used as the business domain of the target field.

[0304] In another example, the device obtains that the table name of the data table where the target field is located is "t_order". This table has a foreign key pointing to the parent table "t_user", but "t_order" does not contain the prefix "t_user" and does not meet the naming same-origin condition. Therefore, the device uses the first business domain "t_order" as the business domain of the target field and does not use "t_user" as the business domain of the target field.

[0305] In another example, suppose the device determines the business domain of "t_order_log" as "t_order" using method two. However, when querying the preset business domain mapping table, the device finds a business domain overriding record for "t_order_log" that specifies the business domain of "t_order_log" as "order domain". The device then determines "order domain" as the third business domain of the target field and uses "order domain" to override "t_order" as the final business domain of the target field.

[0306] Considering that relying solely on foreign key relationships for business domain merging may lead to erroneous merging, the aforementioned device employs a dual-condition design when merging parent and child tables. This design requires both naming similarity and foreign key combination relationships to be met simultaneously, preventing the erroneous merging of cross-entity tables into the same business domain based solely on foreign key connectivity. Furthermore, the aforementioned preset business domain mapping table can be manually configured to override automatically inferred results. When automatic inference is inaccurate, manual correction can ensure the accuracy of business domain partitioning.

[0307] In this embodiment, the device uses the table name of the data table as the first business domain, determines the second business domain by combining foreign key constraint information with the naming same-origin condition and the N:1 cardinality condition, and determines the third business domain by querying the preset business domain mapping table and manually configured coverage records. The third business domain covers the automatically inferred results. Compared with the existing technology that lacks business domain division or relies on a single rule for division, this embodiment can ensure the system is immediately available during the cold start phase by using default table names. When foreign key associations are available, the related tables are automatically grouped by merging the two conditions of naming same-origin and foreign key combination relationship. At the same time, the deviation of the automatic inference is corrected by the manually configured coverage mechanism. Thus, the business domain division has both automation capabilities and retains the flexibility of manual correction, providing an accurate domain division basis for subsequent independent coverage measurement of each business domain.

[0308] This application also provides a generating apparatus, please refer to... Figure 5 , Figure 5 This is a structural block diagram of the generating device in the embodiments of this application, such as... Figure 5 As shown, the generating apparatus includes: The acquisition module 501 is used to acquire all first migration edges of the target field and acquire all second migration edges that have occurred in the target field from historical change data. All first migration edges of the target field include all second migration edges that have occurred in the target field and all migration edges that have not occurred in the target field. The migration edges are used to characterize the numerical change relationship of the target field. The determination module 502 is used to assign each first migration edge to a test scenario, determine the test scenario to which each second migration edge belongs, obtain the hit count of each test scenario, and determine the density deviation of the corresponding test scenario based on each hit count. The density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio. The generation module 503 is used to, when a new migration edge is generated in the target field, take the new migration edge as the third migration edge, determine the target test scenario to which the third migration edge belongs, and retain the third migration edge in the historical change data to generate the shadow data of the target field according to the density deviation of the target test scenario.

[0309] Compared with the prior art, the beneficial effects of the generation device provided in this application embodiment are the same as those of the generation method provided in the above embodiments, and other technical features in the generation device are the same as those disclosed in the method of the above embodiments, and will not be repeated here.

[0310] This application provides a generation apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the generation method in Embodiment 1 above.

[0311] The following is for reference. Figure 6 , Figure 6 This is a schematic diagram of the structure of the generation device in the embodiments of this application, showing a structural schematic diagram suitable for implementing the generation device in the embodiments of this application. The generation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6The generating device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0312] like Figure 6 As shown, the generating device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the generating device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the generating device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows generating devices with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0313] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0314] Compared with the prior art, the beneficial effects of the generation device provided in this application are the same as those of the generation method provided in the above embodiments, and other technical features of the generation device are the same as those disclosed in the method of the previous embodiment, which will not be repeated here.

[0315] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0316] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0317] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the generation method in the above embodiments.

[0318] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having 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 thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0319] The aforementioned computer-readable storage medium may be included in the generating device or may exist independently and not assembled into the generating device.

[0320] The aforementioned computer-readable storage medium carries one or more programs, and the aforementioned method is executed when the one or more programs are executed by the generating device.

[0321] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0323] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0324] Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the generation method provided in the above embodiments, and will not be repeated here.

[0325] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the generation method described above.

[0326] Compared with the prior art, the beneficial effects of the computer program product provided in this application embodiment are the same as the beneficial effects of the generation method provided in the above embodiment, and will not be repeated here.

[0327] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A generation method, characterized in that, The method includes: Obtain all first migration edges of the target field, and obtain all second migration edges of the target field that have occurred from the historical change data. All first migration edges of the target field include all second migration edges of the target field that have occurred and all migration edges of the target field that have not occurred. The migration edges are used to characterize the numerical change relationship of the target field. Each first migration edge corresponds to a test scenario, the test scenario to which each second migration edge belongs is determined, the hit count of each test scenario is obtained, and the density deviation of the corresponding test scenario is determined based on each hit count. The density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio. When a new migration edge is generated for the target field, the new migration edge is used as the third migration edge. The target test scenario to which the third migration edge belongs is determined, and the third migration edge is retained in the historical change data to generate the shadow data of the target field according to the density deviation of the target test scenario.

2. The method as described in claim 1, characterized in that, The step of determining the density deviation corresponding to the test scenario based on each hit count includes: Obtain the expected occurrence count of the test scenario corresponding to each of the first migration edges, and obtain the total expected occurrence count of all test scenarios corresponding to the first migration edges based on the expected occurrence count of each of the first migration edges; Based on the expected occurrence count for each and the total expected occurrence count, the preset expected occurrence percentage for the test scenario corresponding to each first migration edge is obtained; Obtain the hit count of the test scenario to which each second migration edge belongs, and obtain the total hit count of all test scenarios to which all second migration edges belong based on each hit count; Based on each hit count and the total hit count, the actual occurrence percentage of the test scenario to which each second migration edge belongs is obtained; The density deviation for each test scenario is determined based on the expected occurrence percentage and the corresponding actual occurrence percentage.

3. The method as described in claim 1, characterized in that, Before the step of using the new migration edge as the third migration edge when a new migration edge is generated in the target field, the method further includes: The retention probability for each density deviation is obtained for the corresponding test scenario, and the density deviation is positively correlated with the retention probability. The step of retaining the third migration edge in the historical change data to generate the shadow data of the target field based on the density deviation of the target test scenario includes: Based on the retention probability of the target test scenario, the third migration edge is retained in the historical change data to generate shadow data of the target field.

4. The method as described in claim 3, characterized in that, The step of obtaining the retention probability corresponding to each test scenario based on each density deviation includes: Obtain the preset nonlinear exponent, the adjustment step size of the previous period, and the sampling weight of the test scenario in the previous period; Each density deviation is adjusted according to the adjustment step size and the preset nonlinear index to obtain each adjusted density deviation; The sampling weights are adjusted according to each adjusted density deviation to obtain the adjusted sampling weights corresponding to each test scenario. The retention probability for the corresponding test scenario is obtained based on each of the adjusted sampling weights.

5. The method as described in claim 4, characterized in that, The step of adjusting each density deviation according to the adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation includes: The number of test scenarios that meet the target in the current period is determined based on each hit count, and the total number of scenarios for all test scenarios is obtained. The scene coverage rate for the current period is determined based on the number of qualified scenarios and the total number of scenarios. If the scene coverage rate in the current period is not higher than the preset coverage threshold, each density deviation is adjusted according to the adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation. If the scene coverage rate in the current period is higher than the preset coverage threshold, the adjustment step size is attenuated according to the preset default attenuation coefficient, and each density deviation is adjusted according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation.

6. The method as described in claim 5, characterized in that, The step of adjusting each density deviation according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation includes: Obtain the scene coverage rate of the previous period and determine the coverage increment between the scene coverage rate of the current period and the scene coverage rate of the previous period; If the coverage increment is not lower than the preset increment threshold, each density deviation is adjusted according to the attenuated adjustment step size and the preset nonlinear exponent to obtain each adjusted density deviation. If the coverage increment is lower than a preset increment threshold, the adjustment step size after attenuation is pulled back, and each density deviation is adjusted according to the adjusted step size after the pull-back and the preset nonlinear exponent to obtain each adjusted density deviation.

7. The method as described in claim 5, characterized in that, The step of attenuating the adjustment step size according to a preset default attenuation coefficient includes: Obtain the cycle number of the current cycle, and determine the attenuation level based on the cycle number and the preset attenuation ratio; The preset default attenuation coefficient is attenuated according to the attenuation degree to obtain the attenuated preset default attenuation coefficient; The adjustment step size is attenuated by the preset default attenuation coefficient after attenuation.

8. The method as described in claim 1, characterized in that, The step of obtaining all first migration edges of the target field includes: Obtain all possible semantic value domains for the target field, and determine the semantic label corresponding to each semantic value domain according to the first mapping table; All first migration edges of the target field are obtained by enumerating each of the semantic labels.

9. The method as described in claim 8, characterized in that, Before the step of obtaining all possible semantic value ranges of the target field, the method further includes: If the target field has the field annotation, the field annotation is obtained and parsed to obtain the first semantic tag corresponding to each semantic domain value; If the target field is a foreign key, determine the associated field in the parent table to which the foreign key points, and obtain the second semantic tag corresponding to each semantic field value in the associated field; Obtain the ending field of the target field, and infer the third semantic tag corresponding to each semantic domain value based on the ending field; Obtain the semantic value domain types and semantic value domain frequencies of the target field, and infer the fourth semantic tag corresponding to each semantic domain value based on the semantic value domain types and semantic value domain frequencies; A first mapping table is constructed based on each semantic value domain and its corresponding first semantic label, second semantic label, third semantic label, and fourth semantic label.

10. The method as described in claim 9, characterized in that, The step of constructing a first mapping table based on each semantic value domain and the corresponding first semantic tag, second semantic tag, third semantic tag, and fourth semantic tag includes: When all the first semantic tags to the fourth semantic tags are the same, a first mapping table is constructed based on each semantic value domain and the first semantic tag, the second semantic tag, the third semantic tag, or the fourth semantic tag; If there are differences among the first semantic tags to the fourth semantic tags, obtain the first confidence level of the first semantic tag to the fourth confidence level of the fourth semantic tag, and select the target semantic tag from the first semantic tags to the fourth semantic tags to construct a first mapping table based on the first confidence level to the fourth confidence level.

11. The method as described in claim 10, characterized in that, The first confidence level is the ratio of the number of enumerated values ​​covered by the field annotation to the different values ​​that actually appear in the target field, multiplied by a first preset coefficient. The second confidence level is a second preset coefficient multiplied by the discrimination index of the parent table of the target field. The discrimination index is used to characterize the degree of dispersion of the value of the referenced field in the parent table in the data distribution. The third confidence level is a third preset coefficient, and the fourth confidence level is a fourth preset coefficient; The preset coefficients, ordered from highest to lowest, are the first preset coefficient, the second preset coefficient, the third preset coefficient, and the fourth preset coefficient.

12. The method as described in claim 1, characterized in that, Before the step of obtaining all first migration edges of the target field, the method further includes: Determine the field type of the target field, which is a status field, a categorical field, or an exclusion field. The status field is a field with unidirectional ordered flow characteristics. The categorical field is a field whose value has no temporal dependency. The exclusion field is a continuous numerical, free text, or timestamp type field. If the field type is the state field, perform the step of obtaining all the first migration edges of the target field.

13. The method as described in claim 1, characterized in that, The step of mapping each first migration edge to a test scenario includes: Obtain multi-dimensional information of the target field, including all theoretically existing changed table names of the target field, the source tag of the target field, the amount segment of the target field, and the cross-transaction label of the target field; Based on the multi-dimensional information and each of the first migration edges, a multi-dimensional scene vector is constructed, and each of the multi-dimensional scene vectors corresponds to a test scene.

14. The method as described in claim 1, characterized in that, The steps of assigning each first migration edge to a test scenario, determining the test scenario to which each second migration edge belongs, obtaining the hit count for each test scenario, and determining the density deviation corresponding to the test scenario based on each hit count include: Determine all business domains of the target field, assign each first migration edge to the corresponding business domain, and assign each first migration edge in each business domain to a test scenario in the business domain. Determine the test scenario within the business domain to which each second migration edge belongs, obtain the hit count for each test scenario within each business domain, and determine the density deviation for the corresponding test scenario within the corresponding business domain based on each hit count; The steps of generating a new migration edge in the target field, using the new migration edge as a third migration edge, determining the target test scenario to which the third migration edge belongs, and retaining the third migration edge in the historical change data to generate shadow data of the target field according to the density deviation of the target test scenario include: When a new migration edge is generated in the target field, the new migration edge is used as the third migration edge, and the target test scenario under the target business domain to which the third migration edge belongs is determined. Based on the density deviation of the target test scenario under the target business domain, the third migration edge is retained in the historical change data to generate shadow data of the target field.

15. A generating apparatus, characterized in that, The device includes: The acquisition module is used to acquire all first migration edges of the target field and acquire all second migration edges that have occurred in the target field from historical change data. All first migration edges of the target field include all second migration edges that have occurred in the target field and all migration edges that have not occurred in the target field. The migration edges are used to characterize the numerical change relationship of the target field. The determination module is used to assign each first migration edge to a test scenario, determine the test scenario to which each second migration edge belongs, obtain the hit count of each test scenario, and determine the density deviation of the corresponding test scenario based on each hit count. The density deviation is used to characterize the deviation between the actual occurrence ratio of the corresponding test scenario in the historical change data and the preset expected occurrence ratio. The generation module is used to, when a new migration edge is generated in the target field, take the new migration edge as the third migration edge, determine the target test scenario to which the third migration edge belongs, and retain the third migration edge in the historical change data to generate the shadow data of the target field according to the density deviation of the target test scenario.

16. A generating apparatus, characterized in that, The generating apparatus includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the generating method as described in any one of claims 1 to 14.

17. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the generation method as described in any one of claims 1 to 14.

18. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the generation method as described in any one of claims 1 to 14.

Images