Software test case generation method and system oriented to interface dependency relationship

Abstract

The invention relates to the technical field of software automatic testing and case generation, and discloses a software test case generation method and system oriented to an interface dependency relationship, and the method comprises the steps: obtaining interface call log data and tenant configuration data of a target system, and extracting a call record sequence with a tenant tag and a tenant-compliance tag attribution table; generating a tenant-level interface dependency directed graph based on the weighted dependency intensity matrix of each tenant, and generating a tenant-level dependency graph set with compliance label propagation path labels; performing rule verification on each boundary crossing point based on the tenant compliance boundary mapping matrix to generate a tenant compliance conflict risk point set; and generating a test case for the tenant compliance conflict risk point set, and outputting a multi-tenant interface dependency chain test case set. According to the method, the technical defects that the dependency characteristics of the tenants cannot be differentially identified and the problem of isolation and compliance propagation interaction of the tenants cannot be found in the existing method are overcome.

Description

Technical Field

[0001] This invention relates to the field of software automated testing and test case generation technology, and more specifically, to a method and system for generating software test cases oriented towards interface dependencies. Background Technology

[0002] With the development of cloud computing technology, multi-tenant SaaS (Software as a Service) platforms have become the mainstream deployment model for enterprise software. In a multi-tenant architecture, multiple tenants share the same software system and infrastructure, and each tenant's data is distinguished through logical isolation. Especially in SaaS platforms operating across borders, different tenants may belong to different jurisdictions, and their data needs to comply with the data protection regulations of the respective regions.

[0003] When performing interface testing on a multi-tenant SaaS platform, test cases need to be generated based on the dependencies between interfaces. Interface dependencies are usually quantified by analyzing the call frequency in the interface call logs, and dependency paths with higher call frequency generally have higher test priority. However, in a multi-tenant environment, due to differences in the business scale and usage patterns of each tenant, the interface call heat distribution (i.e., the distribution of call frequency among interface pairs) of different tenants shows significant differences.

[0004] Existing methods for generating interface test cases have the following technical shortcomings when dealing with multi-tenant scenarios: First, traditional heatmap calculation methods merge all tenants' call log data, and the resulting dependency weights reflect the average of each tenant's call patterns. This approach can lead to a dilution of critical business dependency paths for large tenants due to differences in call patterns compared to other tenants, while the special call patterns of smaller tenants are overwhelmed by the smaller data volume. Consequently, the generated test cases cannot specifically cover the core business dependency paths of each tenant.

[0005] Second, tenant isolation mechanisms and data compliance propagation mechanisms are typically verified as two independent testing dimensions. Tenant isolation testing focuses on the correctness of data attribution, i.e., verifying that tenant A's data will not flow into tenant B's processing chain; compliance propagation testing focuses on the correctness of data processing constraints, i.e., verifying that compliance labels can be correctly propagated when data carrying specific compliance labels is passed in the interface call chain. However, when a shared service interface processes data from multiple tenants simultaneously, these two mechanisms present overlapping risks: in data aggregation scenarios, data from different tenants carrying different compliance labels may be mixed, leading to confusion or loss of compliance labels; in tenant switching scenarios, data compliance labels may not be correctly migrated to the new tenant's processing chain along with the data. Because existing methods perform the two tests independently, they cannot discover the overlapping risk points between tenant isolation boundaries and compliance constraint propagation, resulting in defects under certain boundary conditions not being covered by the tests.

[0006] Therefore, a software test case generation method oriented towards interface dependencies is needed, which can differentiate the dependency characteristics of each tenant in a multi-tenant scenario, and perform correlation analysis between tenant isolation boundaries and compliance constraint propagation to generate test cases that can simultaneously cover tenant-specific business paths and tenant-compliance cross-risk points. Summary of the Invention

[0007] This invention provides a method and system for generating software test cases based on interface dependencies, which solves the technical problems in related technologies where traditional methods cause tenant characteristics to be overwhelmed by merging multi-tenant call logs, and where existing methods cannot differentiate the dependency characteristics of each tenant or discover the interaction between tenant isolation and compliance propagation.

[0008] This invention provides a method for generating software test cases based on interface dependencies, comprising: Obtain the interface call log data and tenant configuration data of the target system, and extract the call record sequence with tenant tags and the tenant-compliance tag attribution table; Based on the call record sequence with tenant tags, the call records are grouped according to the tenant identifier. The interface call frequency matrix is ​​calculated for each tenant's call record subsequence, and the weighted dependency strength matrix of each tenant is generated by combining the tenant priority weight coefficient. Based on the tenant-compliance label attribution table and interface definition data, a tenant compliance boundary mapping matrix is ​​generated. The tenant compliance boundary mapping matrix is ​​indexed by tenant as the row index and by compliance label type as the column index. The cell value includes access permissions and conversion rules. A tenant-level interface dependency directed graph is generated based on the weighted dependency strength matrix of each tenant, and the propagation path of compliance labels is traced along the data flow to generate a set of tenant-level dependency graphs with compliance label propagation path annotations. For the set of tenant-level dependency graphs, a boundary crossing detection algorithm is used to identify the boundary crossing points of data across the tenant isolation boundary. Based on the tenant compliance boundary mapping matrix, rule verification is performed on each boundary crossing point to generate a set of tenant compliance conflict risk points. Test cases are generated for the set of tenant compliance conflict risk points, and a set of test cases for multi-tenant interface dependency chain is output.

[0009] Furthermore, an interface call frequency matrix is ​​calculated for each tenant's call record subsequence, including: Divide the time range of the called record subsequence into multiple time windows; For each time window, the number of calls to each interface pair is counted to form a call frequency matrix for that time window; The call frequency matrix of all time windows is averaged to generate the interface call frequency matrix for each tenant.

[0010] Furthermore, a weighted dependency strength matrix for each tenant is generated by combining the tenant priority weight coefficients, including: Obtain the service level agreement data for each tenant and extract the tenant priority weight coefficient; Multiply the tenant priority weight coefficient by the tenant's interface call frequency matrix to generate the tenant's weighted dependency strength matrix.

[0011] Furthermore, based on the tenant-compliance label attribution table and interface definition data, a tenant compliance boundary mapping matrix is ​​generated, including: Obtain interface definition data, identify the data access scope attributes of each interface, the data access scope attributes include three types: single-tenant, cross-tenant, and shared, and generate an interface tenant isolation level table; Parse the input and output parameter definitions of each interface, identify the position of the compliance label field in the parameters, establish the correspondence between the compliance label field and the data field, and generate an interface compliance label mapping table; Based on the tenant-compliance label attribution table, the interface tenant isolation level table, and the interface compliance label mapping table, a tenant compliance boundary mapping matrix is ​​generated, where the cell value is a triple. The triple includes: the tenant's access rights to the compliance type data, the constraint rules to be followed when processing the compliance type data, and the compliance label conversion rules when data flows in from other tenants.

[0012] Furthermore, a tenant-level interface dependency directed graph is generated based on the weighted dependency strength matrix of each tenant, including: For each tenant's weighted dependency strength matrix, a tenant-level interface dependency directed graph is generated with interfaces as nodes and call relationships as edges, and the edge weights are the values ​​of the corresponding elements in the weighted dependency strength matrix. By comparing the structural differences of each tenant dependency graph, edges that exist only in a single tenant dependency graph are labeled as tenant-specific dependency edges, and edges that exist in multiple tenant dependency graphs are labeled as shared dependency edges.

[0013] Furthermore, the path of tracking compliance labels along the data flow includes: For each directed edge in the dependency graph, based on the interface compliance label mapping table, determine the mapping relationship between the compliance label field in the output parameters of the upstream interface and the compliance label field in the input parameters of the downstream interface. If a mapping relationship exists, mark the compliance label propagation attribute on the edge where the mapping relationship exists; Traverse all paths in the dependency graph and connect the compliance label propagation attributes on each edge of the path to form a complete compliance label propagation path.

[0014] Furthermore, boundary crossing detection algorithms are used to identify boundary crossing points of data across tenant isolation boundaries, including: Based on the interface tenant isolation level table, a set of interfaces with shared tenant isolation level is selected as candidate points for boundary crossing; For each tenant's dependency graph, identify dependency paths that cross candidate points through the boundary; For each dependency path that passes through a candidate boundary crossing point, check whether the upstream and downstream interfaces of the path belong to different tenant isolation domains. If so, mark the candidate points where the upstream and downstream interfaces of the path belong to different tenant isolation domains as boundary crossing points.

[0015] Furthermore, based on the tenant compliance boundary mapping matrix, rule verification is performed on each boundary crossing point to generate a set of tenant compliance conflict risk points, including: Obtain the tenant to which the upstream interface of the boundary crossing point belongs and its compliance label; Obtain the tenant to which the downstream interface of the boundary crossing point belongs; Query the corresponding cell value in the tenant compliance boundary mapping matrix to obtain the downstream tenant's access permissions and conversion rules for upstream compliance type data; If the access permission is prohibited or the conversion rule is blocked, the corresponding boundary crossing point will be marked as a compliance constraint conflict point; if the access permission is restricted or the conversion rule is upgraded, the corresponding boundary crossing point will be marked as a label conversion risk point. All compliance constraint conflict points and label conversion risk points are merged to generate a set of tenant compliance conflict risk points.

[0016] Furthermore, test cases are generated for the set of tenant compliance conflict risk points, including: For each risk point in the set of tenant compliance conflict risk points, construct test scenarios that trigger data flow across tenants. The test scenarios include test input data carrying specific compliance tags, interface call sequences that trigger data flow through boundary crossing points, and verification assertions that verify whether the compliance tags are correctly converted or blocked. For interfaces with shared tenant isolation levels and involving data aggregation operations, construct multi-tenant data inputs with different compliance labels, and verify that the compliance labels of the aggregated output data satisfy the strictest label inheritance principle. For each tenant dependency path marked as tenant-specific in the dependency graph, test cases are generated in descending order based on the tenant priority weight coefficient.

[0017] This invention provides a software test case generation system oriented towards interface dependencies, comprising: The data acquisition module is used to acquire interface call log data and tenant configuration data of the target system, and extract call record sequences with tenant tags and tenant-compliance tag attribution tables; The dependency strength calculation module is used to group the call record sequence with tenant labels by tenant identifier and calculate the weighted dependency strength matrix for each tenant. The boundary mapping matrix generation module is used to generate a tenant compliance boundary mapping matrix based on the tenant-compliance label attribution table and interface definition data; The dependency graph generation module is used to generate a set of tenant-level dependency graphs with compliance-labeled propagation paths based on the weighted dependency strength matrix of each tenant. The risk point identification module is used to generate a set of tenant compliance conflict risk points for the tenant-level dependency graph set using boundary crossing detection algorithms and rule verification algorithms. The test case generation module is used to generate a set of test cases for multi-tenant interface dependency chains based on a set of tenant compliance conflict risk points.

[0018] The beneficial effects of this invention are as follows: This invention overcomes the problem of tenant feature overload caused by merging multi-tenant call logs in traditional methods by grouping call logs at the tenant level and calculating independent heatmap distributions. This is achieved by making the interface call frequency matrix of each tenant independent and unaffected by the call patterns of other tenants. Specifically, in step 200, the call record sequences are grouped and aggregated by tenant identifier, and the call frequency matrix is ​​calculated independently for each tenant subsequence. This ensures that the dependency weight of each tenant only reflects its own call pattern, enabling accurate identification of both the critical business dependency paths of large customer tenants and the special call patterns of small tenants.

[0019] This invention explicitly establishes a two-dimensional association between tenant isolation boundaries and compliance constraints through a tenant compliance boundary mapping matrix. This makes tenant isolation verification and compliance propagation verification no longer independent, but rather correlated within a unified data structure. Specifically, the tenant compliance boundary mapping matrix generated in step 300, with tenants as rows and compliance label types as columns, records each tenant's access permissions and conversion rules for various compliance types of data, providing a basis for subsequent identification of cross-risk points.

[0020] This invention identifies the intersection of risk points between tenant isolation and compliance propagation through the collaborative work of a boundary crossing detection algorithm and a rule verification algorithm. Specifically, the boundary crossing detection algorithm in step 500 first identifies situations where data flows across the tenant isolation boundary when passing through the shared service interface. Then, the rule verification algorithm verifies whether there are compliance label compatibility issues when crossing the boundary based on the tenant compliance boundary mapping matrix. This collaborative detection mechanism can discover intersection risk points that cannot be covered by conducting tenant isolation testing or compliance propagation testing alone. For example, a scenario where tenant A's GDPR data flows through the shared service interface into the processing link of tenant B, which is not subject to GDPR, resulting in the loss of compliance labels.

[0021] Therefore, the test cases generated by this invention can simultaneously cover the complete verification scenario of the core business dependency path of each tenant and the multi-tenant compliance boundary, solving the technical defects of existing methods that cannot differentiate the dependency characteristics of each tenant and cannot discover the interaction between tenant isolation and compliance propagation. Attached Figure Description

[0022] Figure 1 This is a flowchart of a software test case generation method based on interface dependency relationships according to the present invention; Figure 2 This is a bar chart comparing the frequency distribution of multi-tenant interface calls according to the present invention; Figure 3 This is a heatmap of the tenant T001 weighted dependency strength matrix of the present invention; Figure 4 This is the multi-tenant interface dependency graph of the present invention; Figure 5 This is a matrix diagram showing the distribution of tenant compliance conflict risk points according to the present invention; Figure 6 This is a hybrid bar chart of test case coverage and priority analysis of the present invention; Figure 7 This is a mixed scatter plot of bar graphs showing the verification results of the compliance label propagation path integrity of this invention. Detailed Implementation

[0023] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0024] At least one embodiment of the present invention discloses a method for generating software test cases based on interface dependencies, such as... Figure 1 As shown, it includes the following steps: Step 100: Obtain the interface call log data and tenant configuration data of the target system, and extract the call record sequence with tenant tags and the tenant-compliance tag attribution table.

[0025] Specifically, API call log data within a preset time range is retrieved from the log storage system of the target multi-tenant SaaS platform. For each call record in the API call log data, the following fields are extracted: tenant identifier, caller API identifier, callee API identifier, and call timestamp. The extracted fields are assembled into call records with tenant tags, and all call records are sorted by timestamp to form a sequence of call records with tenant tags.

[0026] Simultaneously, tenant configuration data is obtained from the target platform's tenant management system, and the regional affiliation information of each tenant is extracted. Based on the regional affiliation information, the applicable data compliance label type for each tenant is determined. A mapping relationship is established between the tenant identifier and its applicable compliance label type, generating a tenant-compliance label affiliation table.

[0027] It should be noted that the above-mentioned compliance label types include, but are not limited to: GDPR label (applicable to tenants in the European Union), CCPA label (applicable to tenants in California, USA), and PIPL label (applicable to tenants in China). A tenant may be subject to multiple compliance label types simultaneously; for example, a multinational enterprise tenant may be subject to both GDPR and CCPA.

[0028] Taking a multinational enterprise-level collaborative office SaaS platform as an example, this platform provides customer relationship management services to global clients. Currently, it has three active tenants: T001 is a German manufacturing company, T002 is a retail company in California, USA, and T003 is a Chinese technology company. The platform includes five core business interfaces: I001 (user authentication interface), I002 (customer data query interface), I003 (report generation interface), I004 (data aggregation and analysis interface), and I005 (data export interface). The interface call log data for the fourth quarter of 2024 was obtained from the log storage system, and the extracted call record sequence with tenant tags is as follows: Table 1. Partial sequence of call records with tenant labels: After obtaining tenant configuration data from the tenant management system, a tenant-compliance label attribution table is generated based on each tenant's region information, as follows: Table 2 Tenant-Compliance Label Attribution Table: Step 200: Based on the call record sequence with tenant labels, group the tenants according to their identifiers using a grouping aggregation algorithm, and calculate the weighted dependency strength matrix for each tenant.

[0029] Specifically, a grouping and aggregation operation is performed on the call record sequence with tenant labels. The tenant identifier is used as the grouping key to divide the call record sequence into multiple tenant subsequences. Each tenant subsequence contains all the call records of that tenant.

[0030] For each tenant's call record subsequence, a sliding time window statistical algorithm is used to calculate the interface call frequency matrix. The processing procedure of the sliding time window statistical algorithm is as follows: Step 201: Divide the time range of the called record subsequence into multiple time windows of equal length. The window length is configurable, and the overlap ratio between adjacent windows can be set. Step 202: For each time window, count the number of calls to each interface pair (caller interface, callee interface) to form an interface call frequency matrix for that time window; Step 203: Take the average of the call frequency matrices for all time windows to generate the interface call frequency matrix for this tenant. ,in Representing tenant identifiers, matrix elements Indicates tenant interface Calling the interface The average frequency.

[0031] Furthermore, the above matrix elements The value of is a non-negative real number, and the range of its values ​​is . , in This indicates the number of tenants within the statistical time frame. interface The interface has not been called. , This indicates the existence of a calling relationship, and the larger the value, the higher the calling frequency.

[0032] Because the differences in business scale among different tenants can lead to significant variations in the range of call frequencies, a call frequency matrix for each tenant is designed to eliminate the impact of these range differences on subsequent weighted calculations. Perform normalization. Specifically, use the maximum value normalization method, dividing each element in the interface call frequency matrix for each tenant by the maximum value in that matrix, so that the normalized frequency values ​​fall within the range... The interval is used to generate a normalized interface call frequency matrix. .

[0033] Based on step 200, obtain the service level agreement data for each tenant and extract the tenant priority weight coefficient. The tenant priority weight coefficient reflects the tenant's importance at the business level and can be quantified based on the tenant's payment tier, user scale, or contractually agreed service level. Simultaneously, the tenant priority weight coefficient undergoes normalization processing, mapping the original weight value to... Intervals, generating normalized weight coefficients .

[0034] Furthermore, the aforementioned tenant priority weighting coefficient The original value is a positive integer, and its specific value is directly read from the service level agreement (SLA) field in the service level agreement data. The value of the service level field corresponds to the service level number agreed upon in the tenant contract. For example, a value of 1 in the service level field indicates a basic tenant, a value of 2 indicates a standard tenant, and a value of 3 indicates an advanced tenant. The larger the value, the higher the service level and the greater the importance of the business.

[0035] The weighted fusion algorithm is used to multiply the normalized tenant priority weight coefficients with the normalized interface call frequency matrix to generate the weighted dependency strength matrix for each tenant. : in, For tenants The weighted dependency strength matrix, For tenants Normalized priority weight coefficients, For tenants The normalized interface call frequency matrix. The above normalization process ensures that the weighted dependency strengths between different tenants are comparable, avoiding interference from differences in business scale on dependency strength calculation.

[0036] After grouping the call record sequences with tenant tags by tenant identifier, a sliding time window statistical algorithm is used to calculate the interface call frequency matrix for each tenant subsequence. Taking tenant T001 as an example, the fourth quarter of 2024 is divided into a time window with a window length of 1 week. The number of calls to each interface pair is counted and averaged to generate the interface call frequency matrix for tenant T001. The maximum value in the matrix is ​​1200 (I001 calling I002). Dividing each element of the matrix by 1200 for normalization yields the normalized interface call frequency matrix. Retrieve the service levels of the three tenants from the service level agreement data: T001 is a high-level tenant ( T002 is a standard-level tenant. T003 is a basic tenant. After normalization, we get , , Taking tenant T001 as an example, its weighted dependency strength matrix... The calculation results are as follows: Table 3 Weighted Dependency Strength Matrix for Tenant T001 : Figure 2 The data shows the average weekly call frequency of three tenants (T001 German manufacturing company, T002 US retail company, and T003 Chinese technology company) to five core business interfaces in the fourth quarter of 2024.

[0037] Figure 3 This displays the weighted dependency strength matrix for tenant T001 (a German manufacturing company, a high-level tenant). .

[0038] Step 300: Generate a tenant compliance boundary mapping matrix based on the tenant-compliance label attribution table and interface definition data.

[0039] Specifically, the interface definition data of the target system is obtained, and the data access scope attributes of each interface are identified. Data access scope attributes include three types: single-tenant (the interface only processes data from a single tenant), cross-tenant (the interface may process data from multiple tenants but maintains data isolation), and shared (the interface aggregates and processes data from multiple tenants). Using a classification and labeling algorithm based on the access control configuration in the interface definition data, the tenant isolation level is labeled for each interface, generating an interface tenant isolation level table.

[0040] Furthermore, the above classification and labeling algorithm makes judgments based on the access control configuration field in the interface definition data: if the access control configuration of the interface contains tenant identifier filtering conditions and the data source is limited to a single tenant, it is labeled as "single tenant"; if the access control configuration contains tenant identifier filtering conditions but the data source can come from multiple tenants, it is labeled as "cross-tenant"; if the access control configuration does not contain tenant identifier filtering conditions or is explicitly declared as an aggregated service interface, it is labeled as "shared".

[0041] Simultaneously, the input and output parameter definitions of each interface are parsed to identify the location of compliance label fields within the parameters. Compliance label fields are typically appended to business data as metadata to identify the applicable compliance constraints. A mapping between compliance label fields and data fields is established, generating an interface compliance label mapping table.

[0042] Based on the tenant-compliance label attribution table, the interface tenant isolation level table, and the interface compliance label mapping table, a tenant compliance boundary mapping matrix is ​​generated using a matrix construction algorithm. .

[0043] The tenant compliance boundary mapping matrix is ​​defined as follows: the row index is the tenant identifier, the column index is the compliance label type, and the cell value... For a triple ,in:- Indicates tenant For compliance types Data access permissions (allow / deny / restricted); - Indicates tenant Handling compliance types Constraints that must be followed when processing data; This indicates that data flows from other tenants to the current tenant. At that time, compliance label The conversion rules (preserve / upgrade / block).

[0044] Furthermore, the values ​​of each element in the above triplet are determined in the following way: The value is based on the tenant in the tenant-compliance label attribution table. With compliant label types Determine the ownership relationship of the tenant. Belongs to the compliance label The corresponding jurisdiction is set to "Allowed" if the tenant If a data transmission protocol exists but the data does not belong to this area, the value is "restricted"; otherwise, the value is "prohibited". The value is obtained by querying the compliance rule library of the target platform. The compliance rule library is pre-configured with data processing constraint clauses corresponding to each compliance tag type. The value is determined based on the comparison of the compliance label strictness of the source tenant and the target tenant. If the compliance constraint strictness of the target tenant is higher than or equal to that of the source tenant, the value is "Reserve". If the compliance constraint strictness of the target tenant is lower than that of the source tenant and there is a compliance upgrade path, the value is "Upgrade". Otherwise, the value is "Block".

[0045] Furthermore, the "restricted" access permission mentioned above means that a tenant can access data of this compliance type, but must meet specific preconditions, including undergoing additional authorization and approval processes or performing data anonymization. The "upgrade" in the above conversion rules means that when data flows from a less restrictive compliance label type to a more restrictive tenant, the data's compliance label should be replaced with a stricter compliance label type applicable to the target tenant, ensuring that the data is subject to stricter compliance constraints throughout the target tenant's processing chain.

[0046] Based on the access control configuration fields in the interface definition data, tenant isolation levels are labeled for five core business interfaces: I001 and I002, whose access control configurations include tenant identifier filtering conditions and whose data sources are limited to a single tenant, are labeled "Single Tenant"; I003, whose access control configuration includes tenant identifier filtering conditions but can obtain data from multiple tenants, is labeled "Cross-Tenant"; I004, explicitly declared as an aggregation service interface, is labeled "Shared"; and I005, whose access control configuration includes tenant identifier filtering conditions, is labeled "Single Tenant". The generated interface tenant isolation level table is as follows: Table 4 Interface Tenant Isolation Level Table: Based on the tenant-compliance label attribution table, the interface tenant isolation level table, and the interface compliance label mapping table, a tenant compliance boundary mapping matrix is ​​generated using a matrix construction algorithm. Taking the cross-access relationship between tenants T001, T002, and T003 and compliance labels GDPR, CCPA, and PIPL as an example: Table 5 Tenant Compliance Boundary Mapping Matrix : Step 400: Based on the weighted dependency strength matrix of each tenant, use a directed graph construction algorithm to generate a set of tenant-level dependency graphs with compliance-labeled propagation paths.

[0047] Specifically, for each tenant's weighted dependency strength matrix The directed graph construction algorithm is used to generate the corresponding tenant-level interface dependency directed graph. ,in For a set of interface nodes, Let this be the set of dependent edges for this tenant. For the matrix... Add elements to the graph from nodes. Pointing to node A directed edge with weight . .

[0048] Furthermore, due to ,in and Therefore, edge weight The range of values ​​is The closer the edge weight value is to 1, the more likely the dependency is to occur in the tenant's domain. The more important a dependency is in a business context, the closer its edge weight value is to 0, indicating a lower level of importance.

[0049] In this embodiment of the application, in order to identify the differentiated dependency features of each tenant, a graph similarity calculation algorithm is also used to compare the structural differences of the dependency graphs of each tenant. Specifically, for any two tenants... and Dependency graph and Calculate the difference in edge sets between the two graphs. If a dependency edge exists only in a tenant... If a dependency edge is in the dependency graph of a tenant but not in the dependency graph of another tenant, then that dependency edge is marked as a tenant. Tenant-specific dependency edges are defined; if a dependency edge exists in the dependency graphs of multiple tenants, it is marked as a shared dependency edge. Tenant-specific dependency labels are generated and attached to the dependency graphs of each tenant.

[0050] Furthermore, the criterion for determining the aforementioned "unique dependency edge" is: when a certain edge originates from an interface... To the interface Dependency edge in tenant In the weighted dependency strength matrix that satisfies And in all other tenants ( All of the weighted dependency strength matrices satisfy the following conditions: At that time, the dependent edge is determined to be a tenant. The unique dependency edge.

[0051] Simultaneously, a label propagation tracing algorithm is used to track the transmission path of compliant labels along the data flow. The processing procedure of the label propagation tracing algorithm is as follows: Step 401: For each directed edge in the dependency graph Based on the interface compliance label mapping table, determine the interface. The compliance label field in the output parameters and the interface The mapping relationship of the compliance label field in the input parameters; Step 402: If a mapping relationship exists, mark the compliance label propagation attribute on the directed edge, indicating that the compliance label can be propagated from the interface along the directed edge. Pass to interface ; Step 403: Traverse all paths in the dependency graph and connect the compliance label propagation attributes on each edge of the path to form a complete compliance label propagation path.

[0052] Furthermore, the path traversal described above uses the interface node with an in-degree of zero in the dependency graph as the starting node and the interface node with an out-degree of zero as the ending node, and uses a depth-first search method to enumerate all directed paths from each starting node to each ending node. For each enumerated directed path, it checks whether each edge on the directed path has the compliance label propagation attribute. If all edges on the directed path have the compliance label propagation attribute, then the directed path is marked as a complete compliance label propagation path.

[0053] Output a set of tenant-level dependency graphs with propagation paths labeled with compliance tags.

[0054] Tenant-level interface dependency directed graphs are constructed based on the weighted dependency strength matrices of the three tenants. , , .

[0055] By comparing the differences in the edge sets of the three dependency graphs using a graph similarity calculation algorithm, the unique dependency edges of each tenant are identified: the dependency graph of tenant T001 contains edges... and In the dependency graph of tenants T002 and T003 and Therefore, the side The unique dependency edge labeled as tenant T001; similarly, the edge Edges that exist only in the dependency graph of tenant T002 and are marked as unique dependency edges of tenant T002; These edges exist only in the dependency graph of tenant T003 and are marked as unique dependency edges for tenant T003. The compliance label exists in the dependency graphs of all three tenants and is marked as a shared dependency edge. Using a label propagation tracing algorithm, the compliance label propagation path is traced along the data flow. Taking tenant T001 as an example, the complete compliance label propagation path is identified as follows: Each edge of this path has the property of propagating compliance labels, and GDPR labels can be passed from I001 to I005 along this path.

[0056] Figure 4 The interface dependency network of the three tenants is shown.

[0057] Figure 7The test results of the compliance label propagation path for each tenant are presented.

[0058] Step 500: For tenant-level dependency graphs with compliance-labeled propagation paths, use boundary crossing detection algorithms to identify a set of tenant compliance conflict risk points.

[0059] Specifically, the boundary crossing detection algorithm is used to identify cross-tenant isolation boundaries when data flows through a shared service interface. The algorithm's processing procedure is as follows: Step 501: Based on the interface tenant isolation level table, filter out the set of interfaces with a tenant isolation level of "shared" as candidate points for boundary crossing; Step 502: For each tenant's dependency graph, identify the dependency paths that cross the boundary and traverse candidate points; Step 503: For each dependency path that passes through a boundary crossing candidate point, check whether the upstream and downstream interfaces of the dependency path belong to different tenant isolation domains. If so, mark the boundary crossing candidate point as a boundary crossing point.

[0060] Furthermore, the aforementioned tenant isolation domain refers to the data processing boundary defined for a specific tenant within the system architecture. Interfaces belonging to the same tenant isolation domain can only access and process the data of that tenant. The tenant isolation domain to which an interface belongs is determined based on the interface tenant isolation level table: interfaces with a tenant isolation level of "single-tenant" belong to the isolation domain of the specific tenant they serve; interfaces with a tenant isolation level of "cross-tenant" or "shared" do not belong to any single tenant's isolation domain, but are located at the boundary of tenant isolation domains.

[0061] For each boundary crossing point, a rule-based verification algorithm is used to verify the compatibility of compliance labels based on the tenant compliance boundary mapping matrix. The processing procedure of the rule-based verification algorithm is as follows: Step 504: Obtain the tenant to which the upstream interface of the boundary crossing point belongs. and the compliance labels they carry ; Furthermore, the tenant to which the upstream interface belongs By querying the interface tenant isolation level table, it was found that for upstream interfaces with a tenant isolation level of "single tenant," the tenant to which it belongs is the specific tenant served by that upstream interface; and the compliance label it carries. This is obtained by querying the tenant-compliance label attribution table, i.e., the tenant. The set of applicable compliance label types.

[0062] Step 505: Obtain the tenant to which the downstream interface of the boundary crossing point belongs. ; Step 506: Query the cell values ​​in the tenant compliance boundary mapping matrix Get tenant For compliance types Data access permissions and transformation rules; Step 507: If the access permission is "prohibited" or the conversion rule is "blocked", then mark the boundary crossing point as a compliance constraint conflict point; if the access permission is "restricted" or the conversion rule is "upgraded", then mark the boundary crossing point as a label conversion risk point.

[0063] All compliance constraint conflict points and label conversion risk points are merged to generate a set of tenant compliance conflict risk points.

[0064] Based on the interface tenant isolation level table, interface I004, with a tenant isolation level of "shared," was selected as a candidate point for boundary traversal. In the dependency graph of tenant T001, the path... After passing through the boundary crossing candidate point I004, its upstream interface I002 belongs to the isolation domain (single-tenant level) of tenant T001, and its downstream interface I005 may serve tenants T002 or T003. Therefore, I004 is marked as a boundary crossing point. Rule verification is performed for this boundary crossing point: upstream tenant... Carrying compliance label If downstream tenants Query the tenant compliance boundary mapping matrix If the access permission is set to "prohibited" and the conversion rule is set to "block," the boundary crossing point is marked as a compliance constraint conflict point; if downstream tenants Query With access permissions set to "Restricted" and the conversion rule set to "Upgrade," this boundary crossing point is marked as a label conversion risk point. The generated set of tenant compliance conflict risk points is as follows: Table 6: Set of tenant compliance conflict risk points: Figure 5 It illustrates the distribution of compliance conflict risks during data flow between tenants.

[0065] Step 600: Generate a set of test cases for multi-tenant interface dependency chains based on the set of tenant compliance conflict risk points and tenant-specific dependency paths.

[0066] Specifically, the test case generation process is divided into three sub-processes: Step 601: For each risk point in the set of tenant compliance conflict risk points, construct test scenarios that trigger cross-tenant data flow. Test scenarios include: test input data (test data carrying specific compliance tags), call sequence (the order in which interfaces are called to trigger data flow through boundary crossing points), and verification assertions (verifying whether compliance tags are correctly converted or blocked at boundary crossing points).

[0067] Step 602: For interfaces with a tenant isolation level of "shared" and involving data aggregation operations, construct multi-tenant data inputs with different compliance labels. The verification assertion is: the compliance labels of the aggregated output data should satisfy the strictest label inheritance principle, that is, the compliance labels of the output data should inherit the most stringent compliance label among all input data.

[0068] Step 603: For each tenant's dependency path marked as tenant-specific in the dependency graph, generate test cases for each path, sorted in descending order based on the tenant priority weight coefficient. The higher the tenant priority weight, the earlier the test cases for its tenant-specific dependency paths are arranged.

[0069] The test cases generated by the above three sub-processes are combined to output a set of multi-tenant interface dependency chain test cases that integrate tenant isolation verification and compliance propagation verification.

[0070] It should be noted that the above principle of strictest label inheritance means that when multiple data sets carrying different compliance labels are aggregated, the aggregation result should inherit the compliance label with the strictest constraint. The strictness of the compliance labels can be predefined in a priority sequence, for example: GDPR > CCPA > PIPL > No label.

[0071] Furthermore, the priority sequence of the above compliance labels is determined based on the binding strength of each regulation on data processing. This binding strength is quantitatively assessed based on the following dimensions: the scope of data subject rights, the degree of restriction on cross-border data transfer, and the severity of penalties for violations. Compliance labels with higher binding strength are ranked higher in the priority sequence. When aggregated data contains multiple compliance labels, the output data inherits the compliance label ranked highest in the priority sequence.

[0072] For risk point R001 (GDPR data flow from T001 to T003), construct test case TC001: The test input data consists of customer records carrying GDPR compliance tags, and the call sequence is as follows: The verification assertion is "Data should be blocked at I004 and should not flow into the processing link of T003".

[0073] For risk point R002 (GDPR data flow from T001 to T002), construct test case TC002: The test input data is customer records carrying GDPR compliance tags, and the call sequence is: The verification assertion is that "the compliance label of the data at I004 should be upgraded from GDPR to GDPR (because GDPR is more stringent than CCPA, the original label should be kept), and the data must be anonymized before flowing into T002." For the data aggregation interface I004, test case TC003 is constructed: the test input data contains both GDPR data from T001 and CCPA data from T002, and the verification assertion is that "the compliance label of the aggregated output data should inherit GDPR (the most stringent label)." This is for the specific dependency path of tenant T001. Based on its normalized priority weight As the highest priority, test case TC004 is constructed and placed at the beginning of the test case set: the test input data is the customer data of T001, and the call sequence is... The verification assertion is "Customer data in T001 should correctly flow into the aggregation analysis interface and retain the GDPR label". The final output is a set of test cases for the multi-tenant interface dependency chain, integrating tenant isolation verification and compliance propagation verification, containing four test cases from TC001 to TC004.

[0074] Figure 6 The coverage and priority distribution of the generated test case set are shown.

[0075] This implementation overcomes the tenant feature overload problem caused by merging multi-tenant call logs in traditional methods by grouping call logs at the tenant level and calculating independent heatmap distributions. Specifically, step 200 groups and aggregates call record sequences by tenant identifier and calculates the call frequency matrix independently for each tenant subsequence. This ensures that the dependency weight of each tenant reflects only its own call pattern, allowing for accurate identification of critical business dependency paths for large customer tenants and special call patterns for small tenants.

[0076] This implementation explicitly establishes a two-dimensional association between tenant isolation boundaries and compliance constraints through a tenant compliance boundary mapping matrix. This makes tenant isolation verification and compliance propagation verification no longer independent, but rather correlated within a unified data structure. Specifically, the tenant compliance boundary mapping matrix generated in step 300, with tenants as rows and compliance label types as columns, records each tenant's access permissions and conversion rules for various compliance types of data, providing a basis for subsequent identification of cross-risk points.

[0077] This implementation uses a boundary crossing detection algorithm and a rule verification algorithm to locate the intersection risk points between tenant isolation and compliance propagation. Specifically, the boundary crossing detection algorithm in step 500 first identifies situations where data flows across the tenant isolation boundary when passing through the shared service interface. Then, the rule verification algorithm verifies whether there are compliance label compatibility issues when crossing the boundary based on the tenant compliance boundary mapping matrix. This collaborative detection mechanism can discover intersection risk points that cannot be covered when performing tenant isolation testing or compliance propagation testing alone. For example, a scenario where tenant A's GDPR data flows through the shared service interface into the processing link of tenant B, which is not subject to GDPR, resulting in the loss of compliance labels.

[0078] Therefore, the test cases generated by this implementation method can simultaneously cover the complete verification scenario of the core business dependency path of each tenant and the multi-tenant compliance boundary, solving the technical defects of existing methods that cannot differentiate the dependency characteristics of each tenant and cannot discover the interaction between tenant isolation and compliance propagation.

[0079] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for generating software test cases based on interface dependencies, characterized in that, Includes the following steps: Obtain the interface call log data and tenant configuration data of the target system, and extract the call record sequence with tenant tags and the tenant-compliance tag attribution table; Based on the call record sequence with tenant tags, the call records are grouped according to the tenant identifier. The interface call frequency matrix is ​​calculated for each tenant's call record subsequence, and the weighted dependency strength matrix of each tenant is generated by combining the tenant priority weight coefficient. Based on the tenant-compliance label attribution table and interface definition data, a tenant compliance boundary mapping matrix is ​​generated. The tenant compliance boundary mapping matrix is ​​indexed by tenant as the row index and by compliance label type as the column index. The cell value includes access permissions and conversion rules. A tenant-level interface dependency directed graph is generated based on the weighted dependency strength matrix of each tenant, and the propagation path of compliance labels is traced along the data flow to generate a set of tenant-level dependency graphs with compliance label propagation path annotations. For the set of tenant-level dependency graphs, a boundary crossing detection algorithm is used to identify the boundary crossing points of data across the tenant isolation boundary. Based on the tenant compliance boundary mapping matrix, rule verification is performed on each boundary crossing point to generate a set of tenant compliance conflict risk points. Test cases are generated for the set of tenant compliance conflict risk points, and a set of test cases for multi-tenant interface dependency chain is output.

2. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The calculation of the interface call frequency matrix for each tenant's call record subsequence includes: Divide the time range of the called record subsequence into multiple time windows; For each time window, the number of calls to each interface pair is counted to form a call frequency matrix for that time window; The call frequency matrix of all time windows is averaged to generate the interface call frequency matrix for each tenant.

3. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The step of generating a weighted dependency strength matrix for each tenant by combining tenant priority weight coefficients includes: Obtain the service level agreement data for each tenant and extract the tenant priority weight coefficient; Multiply the tenant priority weight coefficient by the tenant's interface call frequency matrix to generate the tenant's weighted dependency strength matrix.

4. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The process of generating a tenant compliance boundary mapping matrix based on the tenant-compliance label attribution table and interface definition data includes: Obtain interface definition data, identify the data access scope attributes of each interface, the data access scope attributes include three types: single-tenant, cross-tenant, and shared, and generate an interface tenant isolation level table; Parse the input and output parameter definitions of each interface, identify the position of the compliance label field in the parameters, establish the correspondence between the compliance label field and the data field, and generate an interface compliance label mapping table; Based on the tenant-compliance label attribution table, the interface tenant isolation level table, and the interface compliance label mapping table, a tenant compliance boundary mapping matrix is ​​generated, where the cell value is a triple. The triple includes: the tenant's access rights to the compliance type data, the constraint rules to be followed when processing the compliance type data, and the compliance label conversion rules when data flows in from other tenants.

5. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The generation of a tenant-level interface dependency directed graph based on the weighted dependency strength matrix of each tenant includes: For each tenant's weighted dependency strength matrix, a tenant-level interface dependency directed graph is generated with interfaces as nodes and call relationships as edges, and the edge weights are the values ​​of the corresponding elements in the weighted dependency strength matrix. By comparing the structural differences of each tenant dependency graph, edges that exist only in a single tenant dependency graph are labeled as tenant-specific dependency edges, and edges that exist in multiple tenant dependency graphs are labeled as shared dependency edges.

6. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The transmission path of the compliance label along the data flow includes: For each directed edge in the dependency graph, based on the interface compliance label mapping table, determine the mapping relationship between the compliance label field in the output parameters of the upstream interface and the compliance label field in the input parameters of the downstream interface. If a mapping relationship exists, mark the compliance label propagation attribute on the edge where the mapping relationship exists; Traverse all paths in the dependency graph and connect the compliance label propagation attributes on each edge of the path to form a complete compliance label propagation path.

7. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The method of using a boundary crossing detection algorithm to identify boundary crossing points of data across tenant isolation boundaries includes: Based on the interface tenant isolation level table, a set of interfaces with shared tenant isolation level is selected as candidate points for boundary crossing; For each tenant's dependency graph, identify dependency paths that cross candidate points through the boundary; For each dependency path that passes through a candidate boundary crossing point, check whether the upstream and downstream interfaces of the path belong to different tenant isolation domains. If so, mark the candidate points where the upstream and downstream interfaces of the path belong to different tenant isolation domains as boundary crossing points.

8. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The rule verification of each boundary crossing point based on the tenant compliance boundary mapping matrix generates a set of tenant compliance conflict risk points, including: Obtain the tenant to which the upstream interface of the boundary crossing point belongs and its compliance label; Obtain the tenant to which the downstream interface of the boundary crossing point belongs; Query the corresponding cell value in the tenant compliance boundary mapping matrix to obtain the downstream tenant's access permissions and conversion rules for upstream compliance type data; If the access permission is prohibited or the conversion rule is blocked, the corresponding boundary crossing point will be marked as a compliance constraint conflict point; if the access permission is restricted or the conversion rule is upgraded, the corresponding boundary crossing point will be marked as a label conversion risk point. All compliance constraint conflict points and label conversion risk points are merged to generate a set of tenant compliance conflict risk points.

9. The method for generating software test cases based on interface dependencies according to claim 1, characterized in that, The generation of test cases for the set of tenant compliance conflict risk points includes: For each risk point in the set of tenant compliance conflict risk points, construct test scenarios that trigger data flow across tenants. The test scenarios include test input data carrying specific compliance tags, interface call sequences that trigger data flow through boundary crossing points, and verification assertions that verify whether the compliance tags are correctly converted or blocked. For interfaces with shared tenant isolation levels and involving data aggregation operations, construct multi-tenant data inputs with different compliance labels, and verify that the compliance labels of the aggregated output data satisfy the strictest label inheritance principle. For each tenant dependency path marked as tenant-specific in the dependency graph, test cases are generated in descending order based on the tenant priority weight coefficient.

10. A software test case generation system based on interface dependencies, used to execute the software test case generation method based on interface dependencies as described in any one of claims 1-9, characterized in that, include: The data acquisition module is used to acquire interface call log data and tenant configuration data of the target system, and extract call record sequences with tenant tags and tenant-compliance tag attribution tables; The dependency strength calculation module is used to group the call record sequence with tenant labels by tenant identifier and calculate the weighted dependency strength matrix for each tenant. The boundary mapping matrix generation module is used to generate a tenant compliance boundary mapping matrix based on the tenant-compliance label attribution table and interface definition data; The dependency graph generation module is used to generate a set of tenant-level dependency graphs with compliance-labeled propagation paths based on the weighted dependency strength matrix of each tenant. The risk point identification module is used to generate a set of tenant compliance conflict risk points for the tenant-level dependency graph set using boundary crossing detection algorithms and rule verification algorithms. The test case generation module is used to generate a set of test cases for multi-tenant interface dependency chains based on a set of tenant compliance conflict risk points.

Images