Multi-environment interface automation testing method, device, equipment, medium and product

Abstract

This application discloses a method, apparatus, device, medium, and product for automated interface testing in multiple environments. The method includes: obtaining multi-dimensional test data from a recruitment platform in both a baseline environment and a colored environment by executing the same automated interface test cases; classifying the multi-dimensional test data according to data structure type and matching corresponding comparison rules for different data structure types; comparing basic data types, multi-level nested structured data, arrays, and multi-table relational data in the multi-dimensional test data under both environments according to the comparison rules to obtain difference information; filtering the difference information using a permanent whitelist and a temporary whitelist, where the permanent whitelist filters common non-core parameters for recruitment scenarios, and the temporary whitelist filters fields expected to change; and generating a comparison report based on the filtered difference information. This application can improve the efficiency and accuracy of automated interface testing for recruitment platforms.

Description

Technical Field

[0001] This application relates to the fields of recruitment and interface testing technology, and in particular to a multi-environment interface automated testing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] In the R&D and iteration process of internet platforms such as recruitment platforms, interfaces, as the core carriers of business functions, directly determine the normal operation of the business due to their data consistency and functional stability. To ensure the quality of the launch of core business functions such as resume parsing, job posting, candidate matching, interview invitations, and VIP membership purchases after the recruitment platform version iteration, it is necessary to conduct automated interface testing in both a baseline environment (an environment deploying stable versions) and a colored environment (an environment to be verified by deploying iterative changes / new functional code). By comparing the test results of the two environments, it is verified whether the interface functions and data consistency in the colored environment meet business expectations.

[0003] Currently, most automated testing methods for multi-environment interfaces of recruitment platforms follow common interface testing logic. Although they can achieve basic test data comparison, due to the complexity of recruitment platform business data and the specificity of scenarios, there are still problems such as omissions and misjudgments in core business data comparison, a lot of noise, and high costs for manual investigation. Summary of the Invention

[0004] In view of the above, embodiments of this application provide a multi-environment interface automated testing method, apparatus, electronic device, computer-readable storage medium, and computer program product to solve at least one of the above-mentioned technical problems.

[0005] Firstly, this application provides a multi-environment interface automated testing method, comprising: obtaining multi-dimensional test data of a recruitment platform in a baseline environment and a colored environment by executing the same interface automated test cases; the multi-dimensional test data includes interface return parameters, database query results, and message queue output results; classifying the multi-dimensional test data according to data structure type and matching corresponding comparison rules for different data structure types; comparing basic type data, multi-level nested structured data, arrays, and database multi-table association data in the multi-dimensional test data in the two environments according to the comparison rules corresponding to each data structure type to obtain difference information; filtering the difference information through a preset permanent whitelist and a temporary whitelist, wherein the permanent whitelist is used to filter general non-core parameters in the recruitment scenario, and the temporary whitelist is used to filter field information expected to change in the version iteration of the recruitment platform; and generating a comparison report based on the filtered difference information.

[0006] Secondly, this application provides a multi-environment interface automated testing device, comprising: an acquisition module, used to acquire multi-dimensional test data of a recruitment platform in a baseline environment and a colored environment by executing the same interface automated test cases, wherein the multi-dimensional test data includes interface return parameters, database query results, and message queue output results; a matching module, used to classify the multi-dimensional test data according to data structure type and match corresponding comparison rules for different data structure types; a comparison module, used to compare basic type data, multi-level nested structured data, arrays, and database multi-table association data in the multi-dimensional test data in the two environments according to the comparison rules corresponding to each data structure type, and obtain difference information; a filtering module, used to filter the difference information through a preset permanent whitelist and a temporary time-limited whitelist, wherein the permanent whitelist is used to filter general non-core parameters in the recruitment scenario, and the temporary time-limited whitelist is used to filter field information that is expected to change in the version iteration of the recruitment platform; and a generation module, used to generate a comparison report based on the filtered difference information.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the multi-environment interface automated testing method described above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the multi-environment interface automated testing method described above.

[0009] Fifthly, embodiments of this application provide a computer program product, which includes computer program instructions that, when executed by a processor, implement the steps of the multi-environment interface automated testing method described above.

[0010] The multi-environment interface automation testing method, apparatus, device, medium, and product provided in the embodiments of this application, on the one hand, expands the comparison dimensions from interface return parameters to database query results and message queue output results during interface automation testing. This enables multi-dimensional consistency verification of the interface layer, data layer, and message layer, reducing the omission of core business data anomalies in resume parsing, candidate matching, job posting, and VIP membership benefit distribution, thereby improving the quality and stability of recruitment platform function launches. On the other hand, complex data structures such as multi-layered nested JSON, arrays, and multi-table related data that frequently occur in recruitment platforms cannot be effectively compared, easily leading to misjudgments of superficial consistency but deep anomalies. This application matches corresponding comparison rules to different data structure types, performing precise layer-by-layer comparison of complex data structures such as multi-layered nested JSON, arrays, and multi-table related data in the baseline environment and the colored environment. This achieves accurate identification of implicit differences in complex business data in recruitment scenarios, effectively avoiding recruitment business anomalies caused by incomplete resume parsing, disordered candidate matching results, and inconsistent multi-table related data, thus improving the data consistency and user experience of the recruitment platform's core business. On the other hand, this application achieves permanent filtering of common non-core parameters in recruitment scenarios by setting a permanent whitelist, effectively filtering out noise interference and reducing the workload of manual investigation. Based on the permanent whitelist, a temporary whitelist is introduced to accurately filter fields expected to change during version iterations, reducing the interference of expected change differences on test results and further reducing the workload of manual investigation.

[0011] Furthermore, through the overall synergy of the aforementioned technical features, this application has formed a fully automated comparison system that covers the entire process from multi-dimensional data collection and in-depth comparison of complex data structures to refined difference filtering. This system can be efficiently integrated into the CI / CD pipeline of recruitment platforms, meet the high-frequency regression testing needs of recruitment platforms before release, and improve the efficiency and accuracy of automated testing of recruitment platform interfaces. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0013] Figure 1 This is a flowchart illustrating a multi-environment interface automated testing method provided in an embodiment of this application.

[0014] Figure 2 This is another flowchart illustrating the multi-environment interface automation testing method provided in the embodiments of this application.

[0015] Figure 3 This is a flowchart illustrating step S105 of the multi-environment interface automated testing method provided in the embodiments of this application.

[0016] Figure 4 This is a structural block diagram of a multi-environment interface automated testing device provided in an embodiment of this application.

[0017] Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0020] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0021] Various modifications and variations can be made to this application without departing from its spirit or scope, which will be apparent to those skilled in the art. Therefore, this application is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.

[0022] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the prior art: In the R&D and iteration process of internet platforms such as recruitment platforms, interfaces, as the core carriers of business functions, directly determine the normal operation of the business due to their data consistency and functional stability. To ensure the quality of the launch of core business functions such as resume parsing, job posting, candidate matching, interview invitations, and VIP membership purchases after the recruitment platform version iteration, it is necessary to conduct automated interface testing in both a baseline environment (an environment deploying stable versions) and a colored environment (an environment to be verified by deploying iterative changes / new functional code). By comparing the test results of the two environments, it is verified whether the interface functions and data consistency in the colored environment meet business expectations.

[0023] Currently, most automated testing methods for multi-environment interfaces of recruitment platforms follow common interface testing logic. Although they can achieve basic test data comparison, due to the complexity of recruitment platform business data and the specificity of scenarios, there are still problems such as omissions and misjudgments in core business data comparison, a lot of noise, and high costs for manual investigation.

[0024] Specifically, most current automated testing solutions for recruitment platform interfaces only compare the parameters returned by the interface, without covering the data in the database related tables and the business process messages in the message queue. For example, in a candidate matching scenario, the matching results returned by the interface may be normal, but the application status in the database may not be updated, and the interview invitation message in the message queue may not be sent. These hidden problems, where the interface returns normally but the underlying data is abnormal, are currently difficult to detect, which can lead to interruptions in the recruitment process or damage to the candidate's experience.

[0025] Secondly, current automated testing solutions for recruitment platforms use simple comparison methods, mostly employing shallow field matching. These methods fail to perform in-depth comparisons of complex data structures frequently encountered on recruitment platforms, such as multi-layered nested JSON, arrays, and multi-table joins. This easily leads to misjudgments based on superficial consistency but underlying data anomalies. For example, in candidate matching scenarios, the candidate matching result arrays may have the same length, but the internal element order might be disordered. The candidate with the highest match score should be listed first, but is actually listed last. Such deep anomalies are difficult for existing technologies to identify, thus affecting the accuracy of recruitment recommendations.

[0026] Furthermore, the current automated testing solutions for recruitment platforms include differences in non-core parameters (such as timestamps, random IDs, log numbers, etc.) in the comparison process, which generates a lot of noise interference, increases the cost of manual investigation for testers, and reduces the accuracy of the comparison.

[0027] To address at least one of the aforementioned technical problems, embodiments of this application provide a multi-environment interface automated testing method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0028] The following section first introduces the multi-environment interface automation testing method provided in the embodiments of this application. This method can be applied to interface automation testing scenarios such as recruitment platforms. In the embodiments of this application, the multiple environments may include a baseline environment and a colorized environment. The baseline environment is the environment in which the stable online release version of the recruitment platform is deployed, also known as the production environment or pre-release environment. The colorized environment is the environment in which the iterative changes or new functional code of the recruitment platform is deployed for verification, also known as the grayscale environment or test environment.

[0029] Figure 1 This is a flowchart illustrating a multi-environment interface automated testing method provided in an embodiment of this application. Figure 1 As shown, the multi-environment interface automation testing method may include the following steps S101 to S105.

[0030] S101: By executing the same automated test cases for the interface, obtain multi-dimensional test data of the recruitment platform in the baseline environment and the colored environment respectively. The multi-dimensional test data includes interface return parameters, database query results and message queue output results.

[0031] Different automated test cases can be set up for different core business processes of the recruitment platform. For example, for resume parsing, automated test cases can be set up to cover different resume formats and sources. For job posting, automated test cases can be set up to cover different job types and posting channels. Automated test cases can also be set up for core business processes such as candidate matching, interview invitations, or VIP membership purchases.

[0032] Each automated test case for an API can include core elements such as input data, execution steps, and expected results. Input data can include API request parameters and pre-prepared data (such as pre-configured database data and message queue messages). Execution steps can include the execution order and timing of operations such as API calls, database queries, and message queue listening. Expected results can include the expected values ​​of API return parameters, database status changes, and message queue output.

[0033] For example, taking an automated test case for a resume parsing interface as an example, the input data can include resume file paths in different formats, resume data identifiers from different sources, and parsing template IDs. The execution steps can include: calling the resume parsing interface by passing in the resume file path and parsing template ID; after parsing, querying the candidate table (candidate) to obtain basic information such as the generated candidate ID, name, gender, and education; querying the work experience table (work_experience) to obtain the parsed work experience data; querying the education experience table (education) to obtain the parsed education experience data; and listening to the message queue (MQ) to receive a notification message indicating successful parsing. Expected results can include: the interface returning a 200 response code, a parsing status of "complete," and a non-empty candidate ID; the returned candidate information JSON structure containing basic candidate information, an array of work experience data, an array of education experience data, and a list of certificates; the database query results showing a newly added record in the candidate table with complete fields, new work experience data in the work experience table matching the resume content, and new education experience data in the education experience table matching the resume content; and a message queue output showing a successful resume parsing message containing the correct candidate ID, parsing time, and resume file name.

[0034] In S101, the same set of automated interface test cases can be executed in both the baseline and colored environments of the recruitment platform. The set of automated interface test cases can include at least one automated interface test case, such as automated interface test cases for resume parsing, automated interface test cases for candidate matching, and / or automated interface test cases for VIP member purchases, etc.

[0035] For each API automated test case, multi-dimensional test data (referred to as the first multi-dimensional test data) can be collected from the recruitment platform in a baseline environment and multi-dimensional test data (referred to as the second multi-dimensional test data) in a colored environment. Both the first and second multi-dimensional test data can include API return parameters, database query results, and message queue output results.

[0036] The parameters returned by an API can include the response data from the API being tested. For example, the resume parsing API returns a JSON structure of candidate information, which may include basic candidate information, an array of work experience, an array of education experience, a list of certificates, etc. Similarly, the candidate matching API returns an array of matching results, which may include candidate ID, matching score, matching dimension details, etc.

[0037] Database query results can include database table data related to the business logic of the interface under test. For example, in a resume parsing scenario, queries can be made to the candidate table, work experience table, and education experience table to obtain fields such as candidate ID, name, gender, education level, job description, and enrollment / graduation dates. Similarly, in a VIP membership purchase scenario, queries can be made to the order table and membership benefits table to obtain fields such as order amount and membership validity period.

[0038] The message queue output can include business process messages triggered by the API call being tested. For example, after resume parsing is complete, the message queue can output a resume parsing success message, which may include the candidate ID, parsing time, and resume file name. Similarly, after an interview invitation is sent, the message queue can output an interview status change message, which may include the interview ID, candidate ID, interviewer ID, interview time, and invitation status.

[0039] S102: Classify the multi-dimensional test data according to the data structure type, and match the corresponding comparison rules for different data structure types.

[0040] In S102, the collected multi-dimensional test data can be identified and categorized by data structure type. For example, data structure types can be divided into basic data types, multi-level nested structured data, arrays, and multi-table joins in a database, and corresponding comparison rules can be matched for each data structure type. Different comparison rules correspond to different data structure types, thereby achieving accurate comparison of data of different data structure types.

[0041] Basic data types can include simple data types such as strings, numbers, and booleans. For example, strings can include job IDs, candidate IDs, etc., numbers can include matching scores, etc., and booleans can include resume parsing status, etc. This application does not limit these types.

[0042] Multi-level nested structured data refers to JSON objects containing multiple levels of nesting relationships. For example, the candidate information returned by the resume parsing interface contains three levels of nesting: basic information (such as name, age) → work experience (such as company name, position, job description) → project experience (such as project name, project responsibilities).

[0043] For example, an array could include a list of candidate desired work cities, a list of work experience, a list of skills, and / or a list of matching results. Multi-table joins in a database refer to the aggregated results of multiple tables obtained through join queries. For example, a candidate-application-job join query could aggregate the candidate table, application table, and job table into structured JSON based on candidate identifier and job identifier.

[0044] S103: Based on the comparison rules corresponding to each data structure type, compare the basic type data, multi-level nested structured data, arrays and database multi-table related data in the multi-dimensional test data under the two environments to obtain the difference information.

[0045] Specifically, based on the comparison rules corresponding to each data structure type, the basic type data, multi-level nested structured data, arrays, and database multi-table related data in the multi-dimensional test data under the two environments can be compared, and the differences between the multi-dimensional test data under the two environments can be recorded.

[0046] For example, in the resume parsing scenario, the candidate information JSON in the two environments is recursively compared layer by layer. If a candidate's work experience array contains 3 experiences in the baseline environment and only 2 experiences in the colorized environment, the difference can be recorded as the third element "workExperience[2]" of the work experience array, and the colorized environment is marked as lacking this work experience. If the job description field of a work experience in the baseline environment contains 5 responsibilities and only 3 responsibilities in the colorized environment, the difference can be recorded as the job description field "workExperience[1].responsibilities" in the second element of the work experience array, and the baseline value is recorded as 5 and the colorized value as 3.

[0047] For example, in a candidate matching scenario, the matching result arrays under two different environments can be compared. If the length of the matching result arrays is the same, but the order of the elements has changed, such as the candidate ID that should have the highest matching degree changing from C001 to C003, they can be compared one by one according to the index order. The difference is recorded at the candidate identifier field "matchResults[0].candidateId" in the first element of the matching result array, and the order is marked as disordered. If the length of the matching result arrays is inconsistent, the difference in array length can be recorded directly.

[0048] For example, in a VIP membership purchase scenario, the results of the correlation between order data and membership benefit data in two environments can be compared. If the order status in the baseline environment is "payment successful" and the membership benefit validity period is 365 days, while the order status in the colored environment is "payment successful" and the membership benefit validity period is 0 days, the difference can be recorded in the "membership.validityDays" field of the membership benefit validity period, and the validity period can be marked as abnormal.

[0049] Through the above comparison, difference information including the location of the difference, the baseline value, the coloring value, the data type, the associated use case identifier, and the interface identifier can be generated.

[0050] S104: Filter discrepancies by using a preset permanent whitelist and a temporary whitelist. The permanent whitelist is used to filter common non-core parameters in the recruitment scenario, while the temporary whitelist is used to filter field information that is expected to change during the version iteration of the recruitment platform.

[0051] A permanent whitelist can be used to filter common, non-core parameters in recruitment scenarios. For example, common non-core parameters in recruitment scenarios may include timestamps, request IDs, parsing time, message IDs in the message queue, send times, and / or test environment identifiers. These parameters change with each API call but have no business meaning and are considered noise differences. By setting a permanent whitelist, these differences can be automatically filtered out, eliminating the need for testers to configure them repeatedly.

[0052] Temporary whitelists can be used to filter field information that is expected to change during version iterations of recruitment platforms. In some embodiments, the temporary whitelist is configured with a valid time range and the target field to be changed, and the temporary whitelist automatically expires and restores the difference statistics of the target field upon expiration.

[0053] For example, this iteration added a social media account field to the resume parsing interface. This field was considered an expected difference before the version release and theoretically should not be marked as abnormal. A temporary whitelist with a set effective and expiration time was configured for this field. Within the effective timeframe, differences in this field can be automatically filtered. After the timeout, the whitelist automatically expires. If differences still exist for this field (e.g., the newly added field did not launch as expected), difference statistics are restored to avoid omissions caused by long-term filtering.

[0054] By combining permanent and temporary whitelists, this application achieves precise filtering of noise differences while adapting to the pace of recruitment platform version iterations. This reduces the cost of manual screening and ensures the accuracy of difference statistics.

[0055] S105: Generate a comparison report based on the filtered difference information.

[0056] In S105, the filtered difference information (i.e., valid difference information) can be organized to generate a standardized comparison report.

[0057] In some embodiments, the comparison report may include a comparison overview, difference details, whitelist filtering details, association information, and / or difference levels. For example, the comparison overview may include the total number of use cases, the number of successful comparisons, and the number of valid differences. Difference details may include the difference location, baseline value, coloring value, and data type. Whitelist filtering details may include the number of filtered differences, the filtering type, and the effective and expiration times of temporary whitelists. Association information may include associated use case identifiers, associated interface identifiers, and business scenario types.

[0058] In some embodiments, the comparison report can be viewed online in HTML format and downloaded in multiple formats. It can also be pushed to the test management platform, chat groups, or emails, adapting to the test management process of the recruitment platform, making it easier for testers to quickly locate problems and determine the scope of impact.

[0059] The multi-environment interface automation testing method provided in this application, on the one hand, expands the comparison dimensions from interface return parameters to database query results and message queue output results during interface automation testing. This enables multi-dimensional consistency verification at the interface layer, data layer, and message layer, reducing the omission of core business data anomalies in resume parsing, candidate matching, job posting, and VIP membership benefit distribution, thereby improving the quality and stability of recruitment platform function launches. On the other hand, it addresses the common problem of ineffective comparison of complex data structures frequently encountered in recruitment platforms, such as multi-layered nested JSON, arrays, and multi-table related data, which can easily lead to misjudgments of superficial consistency but deep anomalies. This application matches corresponding comparison rules to different data structure types, performing precise layer-by-layer comparison of complex data structures such as multi-layered nested JSON, arrays, and multi-table related data in the baseline and colored environments. This achieves accurate identification of implicit differences in complex business data in recruitment scenarios, effectively avoiding recruitment business anomalies caused by incomplete resume parsing, disordered candidate matching results, and inconsistent multi-table related data, thus improving the data consistency and user experience of the recruitment platform's core business. On the other hand, this application achieves permanent filtering of common non-core parameters in recruitment scenarios by setting a permanent whitelist, effectively filtering out noise interference and reducing the workload of manual investigation. Based on the permanent whitelist, a temporary whitelist is introduced to accurately filter fields expected to change during version iterations, reducing the interference of expected change differences on test results and further reducing the workload of manual investigation.

[0060] Furthermore, through the overall synergy of the aforementioned technical features, this application has formed a fully automated comparison system that covers the entire process from multi-dimensional data collection and in-depth comparison of complex data structures to refined difference filtering. This system can be efficiently integrated into the CI / CD pipeline of recruitment platforms, meet the high-frequency regression testing needs of recruitment platforms before release, and improve the efficiency and accuracy of automated testing of recruitment platform interfaces.

[0061] To facilitate understanding, the following section provides a detailed introduction to multi-environment interface automation testing methods using specific examples.

[0062] According to some embodiments of this application, optionally, during multi-round automated interface testing, the frequency of obtaining multi-dimensional test data of the recruitment platform in the benchmark environment by executing automated interface test cases can be lower than the frequency of obtaining multi-dimensional test data of the recruitment platform in the stained environment. That is, the multi-dimensional test data of the benchmark environment can be reused for multi-round stained environment test comparison after a single collection.

[0063] Specifically, during the version iteration of the recruitment platform, different coloring environments may be used for testing, or the coloring environment may be adjusted and optimized before multiple rounds of testing. Each round of testing requires executing automated interface test cases and comparing them with the benchmark environment. In some embodiments, multi-dimensional test data of the benchmark environment can be collected only during the initial execution or when the benchmark environment changes, and the multi-dimensional test data of the benchmark environment can be stored in the benchmark database. In subsequent rounds of coloring environment testing, the stored multi-dimensional test data of the benchmark environment can be retrieved directly from the benchmark database, without repeatedly calling the benchmark environment interface, querying the database and message queue; only the test data of the coloring environment needs to be collected to complete the comparison.

[0064] For example, within a certain version iteration cycle, the colorized environment may undergo 10 rounds of code fixes and functional verifications. If existing technologies are used, multi-dimensional test data of the baseline environment needs to be re-collected in each round, requiring a total of 10 collections. However, using this embodiment, multi-dimensional test data of the baseline environment is collected only once at the beginning of the version iteration, and the data is directly reused in the subsequent 9 rounds, reducing the number of times multi-dimensional test data of the baseline environment needs to be collected by 90%.

[0065] In this way, by storing and reusing multi-dimensional test data from the benchmark environment, the frequency of benchmark environment calls and collection costs are reduced. Simultaneously, the impact of benchmark environment network fluctuations, data changes, or temporary failures on the comparison results is avoided, thus improving comparison efficiency and stability. Furthermore, the low-frequency collection and multi-round reuse mechanism of multi-dimensional test data from the benchmark environment effectively adapts to the high-frequency regression testing needs of the recruitment platform's CI / CD pipeline, shortening test execution time and improving version iteration efficiency.

[0066] According to some embodiments of this application, the multi-environment interface automation testing method may optionally include steps one and two.

[0067] Step 1: Standardize the multi-dimensional test data of the recruitment platform under the benchmark environment. The standardization process includes at least one of the following: format unification, null value unification, numerical precision normalization, and field naming unification.

[0068] Specifically, since the multi-dimensional test data collected for the benchmark environment comes from different systems, such as JSON data returned by interfaces, table structure data from databases, and string messages from message queues, their data formats, field names, null value representations, and / or numerical precision may differ. Direct comparison can easily lead to misjudgments due to format differences. Therefore, this application standardizes the multi-dimensional test data collected for the benchmark environment. Standardization may include at least one of the following: format unification, null value unification, numerical precision normalization, and field name unification. It should be noted that the same or similar standardization processes can also be applied to the multi-dimensional test data collected for the colorized environment. Here, the standardization of multi-dimensional test data for the benchmark environment is used as an example for illustration.

[0069] For example, regarding format standardization, non-JSON formatted data such as database table structure data and string messages from message queues can be uniformly converted to JSON format, ensuring they are all stored using a unified JSON structure. Regarding unified null value identification, fields in the database that haven't been updated can be uniformly marked as "no update," and optional fields in the message queue that are empty can be uniformly marked as "no value," avoiding comparison discrepancies caused by inconsistent null value representations. Regarding numerical precision normalization, numerical data such as VIP member prices and matching scores can be uniformly retained to two decimal places to avoid misjudgments due to precision differences (e.g., 92.00 in the baseline environment and 92 in the colorized environment). Regarding unified field naming, synonymous fields in different recruitment scenarios can be normalized, such as unifying candidate identifier, candidate_id, and candidateId as candidateId, ensuring consistent field names.

[0070] Step 2: Store the standardized multi-dimensional test data in the benchmark database, and establish a benchmark data index according to the test case identifier, interface identifier, data source, and data structure type.

[0071] In step two, the standardized benchmark environment's multi-dimensional test data can be stored in the benchmark database. Simultaneously, a benchmark data index is created for each data entry based on test case ID, interface ID, and data structure type for subsequent quick querying and retrieval. The test case ID is used to associate specific test cases, and the interface ID is used to associate specific interfaces under test. Data source is used to distinguish test data from different dimensions, such as interface return parameters, database query results, and message queue output results. Data structure type is used to identify the specific structural category of the data, such as basic data types, nested structured data, ordered arrays, unordered arrays, and table joins, facilitating subsequent matching with corresponding comparison rules.

[0072] For example, taking a basic data type from multi-dimensional test data in a benchmark environment as an example, the test case identifier is RESUME_PARSE_001, the interface identifier is API_REC_PARSE, the data source is interface (indicating interface return parameters), and the data structure type is basic (indicating basic data type). This data is stored in the benchmark database, and an index of "test case identifier + interface identifier + data source + data structure type" is created. When this basic data type needs to be retrieved later, the corresponding data can be quickly located and obtained through "test case identifier + interface identifier + data source + data structure type" without the need for re-collection.

[0073] Accordingly, S101: Obtaining multi-dimensional test data from the recruitment platform in both baseline and chromatic environments may include the following steps: The system detects whether the baseline environment has changed. If the baseline environment has not changed, it retrieves multi-dimensional test data of the recruitment platform in the baseline environment from the baseline database, and collects multi-dimensional test data of the recruitment platform in the colored environment by executing interface automated test cases with the same test case identifier.

[0074] During multiple rounds of testing, changes to the baseline environment can be detected, such as whether a new online version has been released or whether the multi-dimensional test data of the baseline environment has expired. If the baseline environment has not changed, the stored multi-dimensional test data of the baseline environment is retrieved directly from the baseline database, without needing to re-call the baseline environment's interfaces, query the database, or the message queue. Simultaneously, multi-dimensional test data of the colored environment is collected by executing automated test cases with the same test case identifier associated with the baseline data.

[0075] If the benchmark environment changes, the benchmark data acquisition process is re-executed by executing interface automated test cases, and the benchmark database is updated.

[0076] Thus, by standardizing the multi-dimensional test data of the benchmark environment, differences in format, naming, and precision between different data sources are eliminated, reducing misjudgments caused by format inconsistencies and improving the accuracy of comparisons. By storing and indexing the multi-dimensional test data of the benchmark environment, rapid and accurate location and reuse of this data are achieved. Through a benchmark environment change detection mechanism, multi-dimensional test data is only re-collected when the benchmark environment changes; in other rounds, stored data is directly reused. This reduces the frequency of benchmark environment calls and collection costs, effectively adapting to the high-frequency regression testing needs of the recruitment platform's CI / CD pipeline, shortening test execution time, and improving version iteration efficiency.

[0077] According to some embodiments of this application, optionally, the basic data type may include at least one of strings, numbers, and boolean values. The comparison rules for the basic data type may include checking whether the data types are consistent; if the data types are inconsistent, it is determined as a difference; if the data types are consistent, the data values ​​are compared to see if they are identical.

[0078] Specifically, basic data types are common in automated testing of recruitment platform interfaces, characterized by their simple structure and single value. This embodiment addresses these characteristics by designing a two-tiered comparison rule: first verifying the data type, then comparing the data values, to ensure consistency in both data type and data value.

[0079] For example, in a candidate matching scenario, the matching score should be a numeric type, such as 92.5. If the matching score returned in the baseline environment is a numeric type 92.5, while the matching score returned in the colorized environment is a string type 92.5, although the data values ​​are the same, the data types are inconsistent. This will be considered a difference, and the difference will be recorded in the matching score field, marking the data type inconsistency. Similarly, in a resume parsing scenario, the parsing status should be a boolean type or a string enumeration type. If the parsing status in the baseline environment is a boolean value "true" (indicating parsing completion), while the parsing status in the colorized environment is a string "complete" (also indicating parsing completion), although the business meaning is the same, the data types are inconsistent, and this will also be considered a difference. This reduces data processing errors caused by data type differences.

[0080] For cases where data types are consistent, further comparison is made to check if the data values ​​are consistent. For example, if the matching score returned in the baseline environment is 92.5 for a numeric type, and the matching score returned in the coloring environment is also 92.5 for a numeric type, then both the data types and data values ​​are consistent, and the result is considered a pass. If the matching score returned in the baseline environment is 92.5 for a numeric type, and the matching score returned in the coloring environment is 95 for a numeric type, then the result is considered a difference. The difference is recorded at the matching score, and the baseline value is recorded as 92.5 and the coloring value as 95.

[0081] Furthermore, it supports configuring error thresholds for numerical data. For example, in candidate matching scenarios, the matching score is allowed an error range of ±1%. If the matching score in the baseline environment is 92.5 and the matching score in the coloring environment is 92.8, the difference between the two is within the allowable error range, and they can be judged as consistent, avoiding misjudgments caused by minor differences in precision.

[0082] Thus, by employing a two-tiered comparison rule that first verifies the data type and then compares the data values, it can accurately identify two types of discrepancies: inconsistent data types and inconsistent data values, avoiding business logic errors caused by differences in data types (such as numerical values ​​versus strings). Furthermore, by configuring numerical error thresholds, noise differences caused by variations in precision can be filtered out, improving the accuracy and flexibility of the comparison and adapting to the actual business needs of numerical fields such as matching scores and prices in recruitment platforms.

[0083] According to some embodiments of this application, optionally, the comparison rules for multi-layer nested structured data may include recursively decomposing each nested field from the top-level field layer by layer, comparing the field values ​​of each field in each layer in turn; when the field value of a certain field is inconsistent, the difference position of the field is recorded, and the comparison of subsequent fields is continued recursively without interrupting the comparison process.

[0084] Multi-layered nested structured data is a frequently occurring data type in recruitment platforms. Its characteristics include deep data hierarchy and tightly interrelated fields. Using shallow comparisons or methods that interrupt comparisons upon encountering differences can easily miss deep anomalies or fail to fully present all differences. This embodiment employs a recursive comparison method, starting from the top-level field of the JSON structure and progressively disassembling each nested field. The values ​​of each field in each layer are compared sequentially, without interruption even if differences are found, continuing to compare subsequent fields to ensure that differences at all levels are completely recorded.

[0085] For example, in a resume parsing scenario, the candidate information JSON structure contains three levels of nesting: basic information (such as name, gender, education, etc.), a work experience array (each element contains company name, position, job description, project experience array, etc.), and an education experience array. Using the recursive comparison rule in this embodiment, the top-level fields, such as candidate identifier, basic information, work experience, or education experience, are compared first. If a field has a nested structure, such as basic information, the comparison is recursively entered at that level, continuing to compare fields such as name, gender, and education within the basic information. If the name field value in the basic information is inconsistent, the difference is recorded in the name field "basicInfo.name" in the basic information, and the comparison continues with subsequent fields such as gender and education in the basic information, without interrupting the comparison due to name inconsistencies.

[0086] In this way, by recursively breaking down the data layer by layer and comparing differences without interruption, it is possible to completely discover the differences at all levels in multi-layered nested structured data, avoiding the omission of differences due to shallow comparisons or premature interruptions. In addition, by accurately recording the location of each difference, testers can quickly locate the problem, improving the efficiency of problem investigation. This is suitable for core business scenarios in recruitment, such as resume parsing, which involve deeply nested data structures.

[0087] According to some embodiments of this application, optionally, based on business semantics, the arrays in the recruitment platform can be divided into two categories: ordered arrays and unordered arrays. The comparison requirements for the two types of arrays are different. Ordered arrays require that the order of elements be consistent. For example, candidate matching results are sorted from high to low according to matching scores. If the order is disordered, it will affect the accuracy of the recommendation results. Unordered arrays do not require that the order of elements be consistent. For example, in a list of candidate desired cities or a list of core skills, as long as the content of the elements is consistent, differences in order should not be considered abnormal. This embodiment designs differentiated comparison rules for the two types of arrays based on their characteristics.

[0088] The comparison rules for ordered arrays can include comparing array lengths; if the array lengths are inconsistent, record the differences; if the array lengths are consistent, compare the content of each array element one by one according to the index order. The comparison rules for unordered arrays can include comparing array lengths; if the array lengths are inconsistent, record the differences; if the array lengths are consistent, compare the content of each element one by one according to the field feature matching method.

[0089] For ordered arrays, the first step is to compare the array lengths in both environments. If the array lengths differ, the difference is recorded, and the positions of missing or redundant elements are marked. If the array lengths are the same, the contents of each array element are compared sequentially according to their index. If the element is a simple data type (such as a number or string), the data type and value are compared for consistency. If the element is a nested JSON object, the recursive comparison rules for multi-level nested structured data are applied, comparing each field within the element layer by layer.

[0090] For example, in a candidate matching scenario, the matching result array is an ordered array, sorted from highest to lowest matching score. In the baseline environment, the matching result array is: [{candidateId:"C001", score:95}, {candidateId:"C002", score:88}, {candidateId:"C003", score:76}], and in the coloring environment, the matching result array is: [{candidateId:"C001", score:95}, {candidateId:"C003", score:76},{candidateId:"C002", score:88}]. Although the array lengths are the same and all three elements exist, the order has changed—C002 and C003 are swapped. Therefore, the arrays are compared one by one according to their index order: at index 0, both are C001, which is consistent; at index 1, the base is C002 and the coloring is C003, which is inconsistent. The difference is recorded as "matchResults[1].candidateId" and the order is marked as disordered; the comparison continues at index 2, and the difference is recorded as "matchResults[2].candidateId". By comparing the index order of the ordered array, abnormal order can be accurately detected, avoiding inaccurate recommendation results caused by disordered order.

[0091] For unordered arrays, first compare whether the array lengths are consistent in the two environments. If the array lengths are inconsistent, directly record the difference in array lengths. If the array lengths are consistent, compare the element content one by one according to the field feature matching method. That is, establish a matching relationship based on the business feature fields of the elements (such as unique identifiers or key field combinations, etc.), and compare the elements in the base array and the colored array one by one, without requiring the index order to be consistent.

[0092] For example, in a resume parsing scenario, candidates expect the city array to be unordered, with no requirement on the order of the cities. In the baseline environment, the expected city array is: [City A, City B, City C], while in the colored environment, the expected city array is: [City C, City A, City B]. Although the order is different, the content of the elements is completely identical. Using the field feature matching method, the array elements are treated as an unordered set, and the elements in both sets are compared separately. Since all three cities are present, it is determined to be consistent, and the difference in order will not be mistakenly judged as an anomaly.

[0093] Thus, by distinguishing between ordered and unordered arrays and designing differentiated comparison rules for each, the comparison needs of different business scenarios on recruitment platforms can be accurately adapted. For ordered arrays, comparing according to the index order can accurately detect order discrepancies, ensuring the accuracy of recommendation results. For unordered arrays, such as desired cities, certificate lists, and skill tags, matching based on field features avoids misjudgments caused by order differences, effectively filtering out noise differences and improving the accuracy and reliability of the comparison.

[0094] According to some embodiments of this application, optionally, the comparison rules for multi-table related data in a database may include aggregating the results of multi-table related queries into structured JSON according to the related key fields, and then recursively comparing the aggregated data layer by layer according to the comparison rules for multi-level nested structured data.

[0095] Specifically, the core business of recruitment platforms often involves querying multiple database tables together. For example, candidate information involves candidate tables, work experience tables, and education experience tables. The application process involves application tables, job tables, and company tables. If the query results of each table are compared separately, it is easy to overlook whether the relationships between the tables are correct. This embodiment aggregates the results of multi-table join queries into structured JSON according to the key fields of the relationships, transforming the flat table structure data into a hierarchical nested structure. Then, it performs recursive comparison according to the comparison rules of multi-level nested structured data, thereby simultaneously verifying the correctness of the relationships and the consistency of field values.

[0096] For example, in a resume parsing scenario, it's necessary to verify the consistency of candidate information across the candidate table, work experience table, and education experience table. In the baseline environment, the candidate table stores candidate ID C001, name Zhang San, and education level Bachelor's degree. The work experience table stores two records, corresponding to work experience at company A and company B respectively. The education experience table stores one record, corresponding to a bachelor's degree from a specific university. In this embodiment, the data from the three tables can be aggregated into structured JSON based on the associated key field, candidate ID.

[0097] In the coloring environment, the data from the three tables can also be aggregated into JSON with the same structure based on the candidate ID. Then, according to the comparison rules for multi-level nested structured data, the aggregated JSON from the two environments is recursively compared layer by layer.

[0098] If the work experience table in the baseline environment contains two work experiences, while the work experience table in the colored environment contains only one work experience, then the process recursively enters the work experience array. When comparing the array lengths, if a discrepancy is found, the difference is recorded at the work experience array, and the colored environment is marked as lacking a work experience. If the job title for a work experience in the baseline environment is "Development Engineer," and the job title for the same work experience in the colored environment is "Junior Development Engineer," then the process recursively enters the corresponding element in the work experience array. The difference is recorded at the job title field of the first element of the work experience array, and the baseline value is recorded as "Development Engineer," while the colored value is recorded as "Junior Development Engineer."

[0099] If the length of the work experience arrays in the baseline environment and the colorized environment is the same, but the association between a certain work experience and the candidate is incorrect, such as the work experience record being associated with the wrong candidate ID, the work experience will not appear in the candidate's work experience array when aggregating by candidate ID, resulting in inconsistent array lengths or mismatched element content, thus identifying and recording this difference.

[0100] In this way, by aggregating the results of multi-table join queries into structured JSON based on key join fields, and then recursively comparing them according to the comparison rules for multi-level nested structured data, the correctness of the join relationships between multiple tables and the consistency of field values ​​in each table can be verified simultaneously. This avoids the problem of failing to detect join errors when comparing individual tables separately. In addition, the aggregated JSON structure is consistent with the multi-level nested data format returned by the interface, enabling the reuse of comparison rules and reducing comparison complexity.

[0101] Figure 2 This is another flowchart illustrating the multi-environment interface automated testing method provided in this application embodiment. For example... Figure 2 As shown, according to some embodiments of this application, optionally, the multi-environment interface automation testing method may further include the following steps S201 and S202.

[0102] S201: If at least one of the following anomalies is detected in any step of acquiring multi-dimensional test data, data classification, data comparison, and difference filtering: interface call anomaly, database connection anomaly, message queue acquisition anomaly, or network fluctuation anomaly, the current test process shall be paused, and the paused step node and the completed test process data shall be recorded.

[0103] Specifically, during multi-round automated interface testing, instability in the baseline or coloring environment may cause test interruptions, such as interface service restarts, database connection timeouts, message queue service unavailability, or network jitter. In this embodiment, by embedding monitoring points at each stage of the entire process, abnormal information is captured in real time, and the current test process is immediately paused when an abnormality occurs, preventing subsequent steps from being executed incorrectly or data from being corrupted. Simultaneously, the stage node at the time of pause and the test process data completed before that stage are recorded, such as collected multi-dimensional test data and completed intermediate comparison results, ensuring that completed test process data is not lost.

[0104] For example, during the data collection phase of the coloring environment, if the resume parsing interface is called, the coloring environment service might restart due to code deployment, causing the interface call to time out. Upon detecting this interface call anomaly, the current test process should be immediately paused, and the paused node recorded as the coloring environment data collection phase – resume parsing interface call. Completed test process data, such as multi-dimensional test data from the baseline environment, should also be recorded. Simultaneously, the anomaly type, anomaly time, associated test case identifier, and interface identifier can be recorded for subsequent troubleshooting.

[0105] S202: Once the anomaly is detected and resolved, reuse the completed test process data and continue executing the subsequent test process from the paused stage node.

[0106] Once testers fix the anomaly, they receive a resume command and automatically continue the test process from the paused stage, eliminating the need to re-execute all test steps from the beginning. In other words, completed test data is reused, and only the paused stage and any unfinished steps afterward are executed, reducing repetitive operations.

[0107] For example, if the data collection process in the coloring environment is paused due to an abnormal interface call, once the developers have completed the code deployment and restarted the service, they will receive a resume command and continue execution from the data collection process in the coloring environment - resume parsing interface call node. Other data that has already been collected can be reused directly without having to re-execute all the steps.

[0108] In this way, by monitoring for anomalies at each stage of the entire process, recording paused nodes and completed data, and supporting breakpoint resumption after anomaly recovery, the fault tolerance and execution continuity of the testing process are improved. On the one hand, this avoids the entire testing process from being rerun due to occasional anomalies, reducing repetitive execution time and improving testing efficiency. On the other hand, by reusing completed data, it ensures that test results are not lost due to abnormal interruptions, improving the stability and reliability of the testing process. This is suitable for multi-round, high-frequency automated regression testing scenarios in recruitment platform CI / CD pipelines.

[0109] According to some embodiments of this application, optionally, before filtering the difference information using a preset permanent whitelist and a temporary time-limited whitelist in S104, the multi-environment interface automated testing method may further include the following steps: Based on the degree of impact on the recruitment platform's business and the type of difference, multiple difference items in the difference information are divided into difference levels, including the first difference level, the second risk level, and the third risk level.

[0110] Specifically, after obtaining the discrepancy information through comparison, each discrepancy item can be classified into a discrepancy level based on its impact on the core business processes of the recruitment platform and the type of discrepancy. The degree of impact can be categorized as whether the discrepancy directly affects the core recruitment business, such as whether resume parsing is successful, candidate matching results are accurate, or VIP membership purchases are completed. The type of discrepancy can include inconsistent data types, missing fields, newly added fields, and abnormal values. In some examples, based on preset recruitment business rules, discrepancies with high impact that may lead to disruption of the core recruitment business can be classified as the first discrepancy level (P0 level); discrepancies that affect data integrity but do not directly cause disruption of the core recruitment business can be classified as the second discrepancy level (P1 level); and discrepancies with low impact or those belonging to expected changes in version iterations can be classified as the third discrepancy level (P2 level).

[0111] The first level of discrepancy (P0 level) corresponds to discrepancies such as inconsistent data types, abnormal values ​​in core business fields, or abnormal API service responses. These discrepancies directly affect the normal operation of the recruitment platform's core business and must be fixed immediately; they should not be filtered by any whitelist.

[0112] For example, in a candidate matching scenario, the matching score in the baseline environment is 92.5 for numeric type, while the matching score in the colored environment is 92.5 for string type. Although the numerical values ​​are the same, the data types are inconsistent, which may lead to calculation errors in subsequent business logic (such as sorting, filtering, etc.). This is a difference in data type inconsistency and is classified as P0 level.

[0113] For example, in a resume parsing scenario, the candidate ID is C001 in the baseline environment, but empty in the colored environment. The candidate ID is a core business field for resume parsing; its absence will prevent subsequent resumes from being associated with candidates and the application process from proceeding. This is considered an abnormal value for a core business field and is classified as P0 level.

[0114] For example, in a VIP membership purchase scenario, the interface response code is 200 in the baseline environment and 500 in the colored environment. An abnormal interface service response means that the purchase request has failed to process, directly affecting the issuance of membership benefits. This is considered an interface service response abnormality and is classified as P0 level.

[0115] The second level of difference (P1) corresponds to differences involving missing fields. These differences affect the completeness of recruitment data but do not directly cause core business disruptions. They require manual verification to determine whether the issue stems from a program malfunction or a change in requirements.

[0116] For example, in a resume parsing scenario, the candidate information in the baseline environment includes a certificate list field (certList), while this field is missing in the colored environment. The certificate list is a non-core business field; its absence does not affect the main resume parsing process, but it does affect the completeness of the candidate information. This is classified as a field missing difference and is categorized as P1 level.

[0117] For example, in an interview invitation scenario, the interview schedule table in the baseline environment includes an "interviewerPhone" field, while this field is missing in the colored environment. The missing interviewerPhone does not affect the sending of the interview invitation, but it may affect the convenience of subsequent interview communication. This is a difference related to missing fields and is classified as P1 level.

[0118] The third level of difference (P2) corresponds to differences in newly added fields in the coloring environment or abnormal values ​​in non-core business fields. These differences have a low impact and are usually expected changes in version iterations or tolerable fluctuations, and can be filtered by a whitelist under certain conditions.

[0119] Among them, the differences in newly added fields in the colorized environment can be fields added to the colorized environment relative to the base environment during version iteration. These fields are expected differences before the version release. For example, if a social account field is added to the resume parsing interface in a certain iteration, and this field does not exist in the base environment but exists in the colorized environment, this is a difference in newly added fields and is classified as P2 level.

[0120] Abnormal values ​​in non-core business fields can be fluctuations in field values ​​that do not affect core business logic, typically caused by factors such as environmental differences or performance fluctuations. For example, in a resume parsing scenario, parsing takes 100ms in the baseline environment and 150ms in the colored environment. Parsing time is a non-core business field, and its fluctuation does not affect the accuracy of the parsing results; therefore, it is considered a non-core business field abnormality and is classified as P2 level. Similarly, in message queue output, the message sending time is "2024-01-01 10:00:00" in the baseline environment and "2024-01-01 10:00:01" in the colored environment. This second-level difference in timestamps is a non-core business field abnormality and is classified as P2 level.

[0121] Accordingly, permanent whitelists and temporary whitelists can filter only the differences at the second and third difference levels, while the differences at the first difference level are not included in the filtering of permanent whitelists and temporary whitelists.

[0122] Specifically, after classifying the differences into different levels, each difference can be matched against a whitelist. For differences at the first level, the whitelist filtering process is skipped, and the differences are retained as valid, ensuring that core business anomalies are not blocked by any whitelist. For differences at the second and third levels, they are matched against permanent and temporary whitelists: if the difference matches a field in the permanent whitelist (such as timestamp, request identifier, etc.), it is filtered directly. If the difference matches a field in the temporary whitelist (such as a field expected to be added in a version iteration), and the current time is within the effective period of the temporary whitelist, the difference is filtered. If the temporary whitelist has expired, the difference is restored to statistics and is no longer filtered.

[0123] By dividing differences into three levels—first, second, and third—and implementing a mechanism where the first level is excluded from whitelist filtering while only the second and third levels are whitelisted, several advantages are achieved. First, it ensures that differences such as inconsistent data types, abnormal core fields, and API service anomalies are not masked by any whitelist, guaranteeing the timely exposure and remediation of core business anomalies. Second, the whitelist allows for flexible filtering of differences such as missing fields, newly added fields, and fluctuations in non-core values, effectively reducing noise interference and the workload of manual investigation. This linkage between difference levels and the whitelist mechanism satisfies both the short-term filtering needs for expected changes in fields during version iterations and effectively prevents the omission of core business anomalies, improving testing efficiency and accuracy.

[0124] Figure 3 This is a flowchart illustrating step S105 of the multi-environment interface automated testing method provided in an embodiment of this application. Figure 3 As shown, according to some embodiments of this application, optionally, S105: generating a comparison report based on the filtered difference information may include the following steps S301 to S304.

[0125] S301: Build a root cause knowledge base for automated testing of recruitment platform interfaces. The root cause knowledge base stores historical difference information and its corresponding root cause types.

[0126] The root cause knowledge base can store multiple knowledge records. Each knowledge record can include historical discrepancy information (such as discrepancy type, discrepancy location, related interfaces, business scenarios, etc.) and the corresponding root cause type (such as program logic error, data synchronization delay, etc.). The root cause knowledge base can be continuously updated and expanded through manual annotation or machine learning, thereby improving the real-time performance and accuracy of root cause analysis.

[0127] For example, in historical testing, a discrepancy in a resume parsing interface manifested as inconsistent lengths in the work experience array. After investigation, the root cause was identified as a program logic error, specifically that the parsing code failed to correctly extract multiple work experience segments. This information can be stored in the knowledge base, with the discrepancy type being inconsistent array lengths, the associated interface being the resume parsing interface, the business scenario being resume parsing, and the root cause type being a program logic error. Similarly, a discrepancy in a candidate matching interface manifested as a disordered matching result array. After investigation, the root cause was identified as version incompatibility, specifically that the new version's sorting algorithm differed from the old version. This information can also be stored in the knowledge base, with the root cause type being version incompatibility.

[0128] S302: Obtain the filtered difference information and its associated information. The associated information includes at least one of the following: use case identifier, interface identifier, and business scenario type.

[0129] Among them, test case identifiers can be used to locate specific test cases, facilitating the tracing of test scripts and input data from which discrepancies originate. For example, RESUME_PARSE_001 represents the first test case in the resume parsing scenario, and CANDIDATE_MATCH_003 represents the third test case in the candidate matching scenario. Interface identifiers can be used to locate specific interfaces under test, facilitating the quick identification of the interface module to which the discrepancy belongs. For example, API_REC_PARSE represents the resume parsing interface, API_CAND_MATCH represents the candidate matching interface, and API_VIP_BUY represents the VIP membership purchase interface. Business scenario types can be used to identify the business domain to which the discrepancy belongs, facilitating discrepancy statistics and issue categorization by business dimension, such as resume parsing, job posting, candidate matching, interview invitation, or VIP membership purchase.

[0130] S303: Input the filtered difference information and related information into the pre-trained AI root cause analysis model. The AI ​​root cause analysis model is based on the difference root cause knowledge base, performs feature matching on the difference type, difference location and related information of the difference information, and outputs at least one root cause conclusion and investigation priority.

[0131] The root cause conclusions may include at least one of the following: program logic error, data synchronization delay, configuration inconsistency, version iteration incompatibility, and abnormal environment dependency.

[0132] Specifically, the AI ​​root cause analysis model is a large language model that can be fine-tuned or trained using historical difference information from recruitment platforms and their corresponding root cause types. In S303, filtered difference information and related information can be input into the pre-trained AI root cause analysis model. Based on a constructed difference root cause knowledge base, the AI ​​root cause analysis model can extract and match features from the input information, retrieve the historical difference records with the highest similarity from the difference root cause knowledge base, and combine the characteristics of the current difference to output one or more possible root cause conclusions, while providing suggestions for investigation priority to help testers quickly locate problems.

[0133] For example, the input discrepancy information is that the length of the work experience array is inconsistent (3 segments in the baseline environment, 2 segments in the colored environment), and the related information is the resume parsing interface and the resume parsing scenario. The AI ​​root cause analysis model matches similar historical records in the discrepancy root cause knowledge base, outputs the root cause conclusion as a program logic error, and gives it a high priority for investigation, while also providing suggestions for investigation direction: check the work experience extraction logic in the resume parsing code, especially the handling of separators for multiple work experiences. Based on this recommendation, testers can directly locate the relevant code module for investigation, thereby reducing the time for problem localization.

[0134] For example, the input discrepancy information might be a disordered candidate matching result array, with related information including the candidate matching interface and candidate matching scenario. The AI ​​root cause analysis model matches historical records in the discrepancy root cause knowledge base, outputting root cause conclusions for two possibilities: version iteration incompatibility and configuration inconsistency. The priority for investigation is high and medium, respectively, with the following directions provided: check if the new version's sorting algorithm is consistent with the old version; check if the matching score calculation configuration has changed. Testers can then investigate according to priority to quickly locate the root cause of the problem.

[0135] S304: Generate a comparison report based on the filtered difference information, correlation information, root cause conclusions, and investigation priorities. The comparison report includes at least one of the following: comparison overview, difference details, whitelist filtering details, correlation information, difference level, root cause conclusions, and investigation priorities.

[0136] In S304, filtered valid difference information, correlation information, root cause conclusions output by the AI ​​root cause analysis model, and investigation priorities can be integrated to generate a structured comparison report. The comparison report can include not only a comparison overview (such as the total number of test cases, the total number of differences, and the distribution of differences at each level), difference details (such as difference location, baseline value, coloring value, etc.), and whitelist filtering details, but also root cause conclusions and investigation priorities, thus facilitating testers to quickly locate the root cause of the problem.

[0137] In this way, the AI ​​root cause analysis model, based on a differential root cause knowledge base, performs feature matching and root cause recommendation for newly generated differences, providing testers with direct guidance for problem localization, reducing manual investigation time, and improving problem localization efficiency. On the other hand, through root cause conclusions and investigation priorities, testers can prioritize high-priority, high-impact issues, rationally arrange the investigation order, and avoid wasting time due to blind investigation.

[0138] According to some embodiments of this application, optionally, the multi-environment interface automated testing method may further include the following steps: In response to the user's adjustment of the coloring environment, return to the steps of obtaining multi-dimensional test data of the recruitment platform in the coloring environment until the difference information between the coloring environment and the benchmark environment meets the preset comparison pass conditions.

[0139] After completing one round of comparison and generating a comparison report, testers can use the difference information in the comparison report to fix problems or adjust the configuration of the stained environment. In some embodiments, a closed-loop verification mechanism is supported. That is, after the testers complete the adjustment operation of the stained environment, such as code repair, configuration change, or data supplementation, the system automatically responds and returns to the step of obtaining multi-dimensional test data of the stained environment, and re-executes the complete process of stained environment data collection, in-depth comparison, hierarchical filtering, and report generation, forming a closed loop of comparison, repair, and re-comparison. This process is executed cyclically until the difference information between the stained environment and the baseline environment meets the preset comparison pass conditions, such as no first difference level (P0 level) difference, no second difference level (P1 level) difference, and the third difference level (P2 level) difference is all expected changes in the version iteration. At this time, the closed loop is completed.

[0140] For example, in the first round of comparison in a resume parsing scenario, the generated comparison report shows two differences: one is a P0-level difference (e.g., the candidate ID is empty), and the other is a P2-level difference (e.g., a newly added social media account field). Testers fix the colorized environment based on the comparison report, identifying the root cause of the empty candidate ID as a code logic error requiring code repair; they confirm that the social media account field is a new field expected in the version iteration and does not need repair. After completing the adjustments, the testers trigger a re-comparison command. At this point, they can return to the step of obtaining multi-dimensional test data for the colorized environment, re-collect the colorized data from the resume parsing interface, and compare it with the multi-dimensional test data of the benchmark environment already stored in the benchmark database. The second round of comparison results show that the P0-level difference has been fixed, the P2-level difference still exists (the social media account field is still newly added), and there are no other new differences, meeting the preset comparison pass conditions, thus completing the closed loop.

[0141] Thus, the closed-loop verification mechanism helps the staining environment achieve the same quality standards as the benchmark environment after multiple rounds of iterative verification. On the one hand, the closed-loop mechanism allows users to accurately locate problems and make targeted repairs based on the comparison report, avoiding blind troubleshooting. On the other hand, it automatically returns to the data acquisition step of the staining environment and repeats the comparison process without requiring users to manually reconfigure and start it, improving the automation and efficiency of the closed-loop verification.

[0142] To facilitate understanding, the following examples illustrate the multi-environment interface automation testing method provided in this application, using specific implementations of resume parsing.

[0143] S101: By executing the same automated test cases for the interface, obtain multi-dimensional test data of the recruitment platform in the baseline environment and the colored environment respectively. The multi-dimensional test data includes interface return parameters, database query results and message queue output results.

[0144] Specifically, a pre-release baseline environment was selected as the baseline environment, which deploys a stable online release version of the recruitment platform. A test coloring environment was selected as the coloring environment, which deploys iteratively changed code, such as the newly added social account parsing function. The same set of automated interface test cases was executed in both environments, covering core business scenarios of resume parsing, including resume files of different formats and resume data from different sources.

[0145] Taking one of the resume parsing interface automated test cases as an example, the input data can include the path to a PDF resume file and the parsing template ID. The execution steps include: calling the resume parsing interface by passing in the resume file path and the parsing template ID; after parsing, querying the candidate table to obtain basic information such as the candidate identifier, name, gender, and education; querying the work experience table to obtain the parsed work experience data (such as company name, position, job description, start time, end time, etc.); querying the education experience table to obtain the parsed education experience data (such as school name, degree, major, enrollment time, graduation time, etc.); and listening to the resume parsing completion message queue to obtain the parsing success notification message. Expected results include: the interface returns a response code of 200, the parsing status is "complete," the candidate identifier is not empty, the returned candidate information JSON structure contains basic candidate information, an array of work experience, an array of education experience, a certificate list, etc., the database query results show that the candidate table has a newly added record with complete fields, the newly added work experience data in the work experience table matches the resume content, the newly added education experience data in the education experience table matches the resume content, and the message queue output shows a resume parsing success message containing the correct candidate identifier, parsing time, resume file name, etc.

[0146] Collect the following three types of test data: Interface return parameters, i.e., the response data of the interface under test, such as the JSON structure of candidate information returned by the resume parsing interface. This JSON structure can include basic candidate information (such as name, gender, education, etc.), work experience arrays, education experience arrays, certificate lists, etc. Database query results, i.e., database table data related to the interface business, such as querying the candidate table, work experience table, and education experience table to obtain fields such as candidate identifier, name, gender, education, job description, enrollment and graduation dates. Message queue output results, i.e., the business process messages triggered by the interface call, such as the candidate identifier, parsing time, resume file name, etc., output by the message queue after resume parsing is completed.

[0147] S102: Classify the multi-dimensional test data according to the data structure type, and match the corresponding comparison rules for different data structure types.

[0148] Specifically, the collected multi-dimensional test data undergoes data structure type identification and classification. For example, data structure types can be categorized into basic data types, multi-level nested structured data, arrays, and multi-table joins in databases, and corresponding comparison rules are matched for each data structure type. Different comparison rules correspond to different data structure types, thereby achieving accurate and differentiated comparisons of different types of data. This avoids the problems of insufficient comparison for complex data structures and over-comparison or misjudgment for simple data structures caused by using a uniform comparison rule, thus improving the accuracy and reliability of the comparison results.

[0149] Basic data types include strings, numbers, and booleans. The comparison rule can be to directly compare the consistency of field values. For number types, an error threshold can be configured. Multi-layered nested structured data, such as candidate information JSON returned by the resume parsing interface (e.g., containing nested structures like basic information, work experience arrays, and education experience arrays), the comparison rule is to recursively break down the data layer by layer, starting from the top-level field. The comparison is performed on each field in each layer sequentially. When a field value is inconsistent, the difference is recorded, and the comparison continues with subsequent fields without interrupting the process. Arrays include ordered and unordered arrays. For ordered arrays, such as a work experience array, the comparison rule is to first compare the array length. If the lengths are the same, the content of each array element is compared sequentially by index. For unordered arrays, such as a list of candidate desired cities, the comparison rule is to first compare the array length. If the lengths are the same, the content of each element is compared sequentially by field feature matching. For database queries involving multiple tables such as candidate table, work experience table, and education experience table, the comparison rule is to aggregate the query results into structured JSON based on the key fields of the association, and then recursively compare the aggregated data layer by layer according to the comparison rules for multi-level nested structured data.

[0150] S103: Based on the comparison rules corresponding to each data structure type, compare the basic type data, multi-level nested structured data, arrays and database multi-table related data in the multi-dimensional test data under the two environments to obtain the difference information.

[0151] Specifically, based on the comparison rules corresponding to each data structure type, the test data collected in the staining environment is compared one by one with the benchmark data stored in the benchmark database, and the difference information of all levels is recorded.

[0152] For example, in a resume parsing scenario, the JSON data of candidate information in two environments is recursively compared layer by layer. If a candidate's work experience array contains 3 experiences in the baseline environment and only 2 experiences in the colored environment, the difference can be recorded at the third element of the work experience array, and the colored environment can be marked as lacking that work experience. If the job description field of a work experience in the baseline environment contains 5 responsibilities and the colored environment only contains 3 responsibilities, the difference can be recorded at the second element of the job description field in the work experience array, and the baseline value is recorded as 5 responsibilities and the colored value as 3 responsibilities.

[0153] Regarding array comparison, for the work experience array (ordered array), each work experience object is compared one by one according to the index order. If the order of the work experience array in the baseline environment is Company A→Company B→Company C, and the order in the colored environment is Company A→Company C→Company B, then the comparison is performed according to the index order. If the elements at index 1 and index 2 are inconsistent, the tag order is disordered. For the skill tag array (unordered array), the comparison is performed by field feature matching. If the baseline environment is "Java, Python, SQL" and the colored environment is "SQL, Java, Python", it is determined to be consistent, and there will be no misjudgment due to the difference in order.

[0154] In terms of comparing data from multiple tables in the database, the data from the candidate table, work experience table, and education experience table are aggregated into structured JSON based on the key field "candidate identifier." Then, a recursive comparison is performed according to the comparison rules for multi-level nested structured data. If the work experience table in the baseline environment contains two work experiences, while the work experience table in the colored environment contains only one, the comparison is recursively entered into the work experience array. When comparing the array lengths, if an inconsistency is found, the difference is recorded as the position in the work experience array, and the colored environment is marked as lacking a work experience. If the position of a certain work experience in the baseline environment is "Development Engineer," and the position of the same work experience in the colored environment is "Junior Development Engineer," the comparison is recursively entered into the corresponding element of the work experience array. The difference is recorded as the position field in the first element of the work experience array, and the baseline value is recorded as "Development Engineer," and the colored value as "Junior Development Engineer."

[0155] The above comparison generates discrepancy information including the location of the difference, baseline value, coloring value, data type, associated use case identifier, and interface identifier. For example, in some examples, three differences were found. Difference 1 is a difference in basic data type: the baseline value for the candidate identifier field is C001, and the coloring environment is empty. Difference 2 is a difference in multi-level nested structured data: the job title field for a certain work experience segment in the work experience array is inconsistent. Difference 3 is a difference in newly added fields: a social media account field has been added to the interface return parameters in the coloring environment.

[0156] S104: Filter discrepancies by using a preset permanent whitelist and a temporary whitelist. The permanent whitelist is used to filter common non-core parameters in the recruitment scenario, while the temporary whitelist is used to filter field information that is expected to change during the version iteration of the recruitment platform.

[0157] Specifically, after generating the difference information, the differences are filtered through a preset whitelist to reduce noise interference and reduce the workload of manual investigation.

[0158] A permanent whitelist can be used to filter common, non-core parameters that don't require attention in recruitment scenarios. For example, timestamps returned by all APIs, request identifiers, parsing time, message identifiers in the message queue, and sending times. These parameters change with each API call but have no business meaning and are considered noise differences. By pre-setting a permanent whitelist, these differences are automatically filtered out, eliminating the need for testers to configure them repeatedly.

[0159] A temporary whitelist is used to filter field information that is expected to change during version iterations of the recruitment platform. For example, if a social media account field is added to the colorized environment, this field is considered an expected difference before the version release and should not be marked as abnormal. A temporary whitelist can be configured for this field, setting its effective and expiration times. During the effective period, differences in this field are automatically filtered. After the timeout, the whitelist automatically expires. If differences still exist for this field, difference statistics are restored to avoid omissions caused by long-term filtering.

[0160] In some embodiments, the difference information can first be processed in a hierarchical manner: the first difference level (P0) corresponds to differences such as inconsistent data types, abnormal values ​​of core business fields, or abnormal interface service responses, such as an empty candidate identifier. The second difference level (P1) corresponds to differences such as missing fields, such as missing non-core business fields. The third difference level (P2) corresponds to differences such as newly added fields in the coloring environment or abnormal values ​​of non-core business fields, such as newly added social media account fields. The permanent whitelist and temporary whitelist only filter difference items of the second and third difference levels; difference items of the first difference level are not included in the whitelist filtering.

[0161] For example, difference 1 (such as an empty candidate identifier) ​​is a P0 level difference, which is not included in the whitelist filtering and is directly retained as a valid difference. Difference 2 (such as inconsistent job field) is a P1 level difference, is not in the whitelist, and is retained as a valid difference. Difference 3 (such as adding a social media account field) is a P2 level difference and has a temporary whitelist configured, which is currently in effect and will be filtered.

[0162] S105: Generate a comparison report based on the filtered difference information.

[0163] Specifically, the filtered valid discrepancies are organized to generate a standardized comparison report specific to the recruitment scenario. Continuing from the previous example, there are two valid discrepancies: discrepancy 1 (candidate identifier is empty) and discrepancy 2 (job title field is inconsistent).

[0164] The generated comparison report may include the following: Comparison Overview: A total of 10 resume parsing test cases were executed, with 2 valid differences, including 1 P0 level difference, 1 P1 level difference, and 0 P2 level differences. The business scenario was resume parsing.

[0165] Details of the differences and related information: Difference 1: The difference is in the interface return parameter "Candidate Identifier", with a baseline value of C001, a coloring value of null, a difference level of P0, a related use case of RESUME_PARSE_001, a related interface of API_REC_PARSE, and a business scenario of resume parsing. Difference 2: The difference is in the job title field of the first element of the work experience array, with a baseline value of "Development Engineer", a coloring value of "Junior Development Engineer", a difference level of P1, a related use case of RESUME_PARSE_003, a related interface of API_REC_PARSE, and a business scenario of resume parsing.

[0166] Whitelist Filtering Details: 1 difference in the filter count, temporary whitelist type, social media account as the filter field, and the temporary whitelist is effective from "2026-03-01 00:00:00" to "2026-03-15 18:00:00".

[0167] Root cause conclusions and investigation priorities: Difference 1 is caused by a program logic error, specifically an omission in the candidate identifier assignment logic in the resume parsing code. The investigation priority is high, P0 level, which directly affects the core function of resume parsing and needs to be fixed immediately. Difference 2 is caused by a data synchronization delay, specifically the failure to synchronize work experience table data to the coloring environment in a timely manner. The investigation priority is medium, P1 level, which affects data integrity but does not directly cause business interruption. It is recommended to investigate this first.

[0168] The comparison report supports online viewing in HTML format and downloading in multiple formats. It can also be pushed to the test management platform, chat groups, or emails, making it easier for testers to quickly locate problems and determine the scope of impact.

[0169] Testers repaired the colorization environment based on the comparison report. For example, they located the root cause of the empty candidate identifier as a code logic error, repaired it, and re-executed the comparison. They also confirmed that the inconsistency in the job title field was a program exception, repaired it, and re-executed the comparison. After the repair was completed, they returned to step S101 to re-collect the colorization environment data and execute the comparison process. The second round of comparison results showed no valid differences, meeting the preset comparison pass conditions, thus completing the comparison loop.

[0170] This application enables full-dimensional data collection for the resume parsing interface, in-depth and accurate comparison of complex data structures, difference classification, and whitelist filtering, effectively improving the comprehensiveness, accuracy, and efficiency of interface automated testing, and meeting the needs of high-frequency regression testing before release.

[0171] Based on the same technical concept as the multi-environment interface automated testing method provided in the above embodiments, this application also provides a multi-environment interface automated testing device.

[0172] Figure 4 This is a structural block diagram of a multi-environment interface automated testing device provided in an embodiment of this application. Figure 4 As shown, the multi-environment interface automated testing device 40 provided in this application embodiment may include the following modules: The acquisition module 401 is used to acquire multi-dimensional test data of the recruitment platform in the benchmark environment and the colored environment by executing the same interface automated test cases. The multi-dimensional test data includes interface return parameters, database query results and message queue output results. The matching module 402 is used to classify multi-dimensional test data according to data structure type and match corresponding comparison rules for different data structure types. The comparison module 403 is used to compare the basic type data, multi-level nested structured data, array and database multi-table related data in the multi-dimensional test data under two environments according to the comparison rules corresponding to each data structure type, and obtain the difference information. The filtering module 404 is used to filter the difference information through a preset permanent whitelist and a temporary time-limited whitelist, wherein the permanent whitelist is used to filter general non-core parameters in the recruitment scenario, and the temporary time-limited whitelist is used to filter field information that is expected to change in the version iteration of the recruitment platform. The generation module 405 is used to generate a comparison report based on the filtered difference information.

[0173] The multi-environment interface automation testing device provided in this application, on the one hand, expands the comparison dimensions from interface return parameters to database query results and message queue output results during interface automation testing. This enables multi-dimensional consistency verification of the interface layer, data layer, and message layer, reducing the omission of core business data anomalies in resume parsing, candidate matching, job posting, and VIP membership benefit distribution, thereby improving the quality and stability of recruitment platform function launches. On the other hand, it addresses the issue of ineffective comparison of complex data structures frequently encountered in recruitment platforms, such as multi-layered nested JSON, arrays, and multi-table related data, which can easily lead to misjudgments of superficial consistency but deep anomalies. This application matches corresponding comparison rules to different data structure types, performing precise layer-by-layer comparison of complex data structures such as multi-layered nested JSON, arrays, and multi-table related data in the baseline and colored environments. This achieves accurate identification of implicit differences in complex business data in recruitment scenarios, effectively avoiding recruitment business anomalies caused by incomplete resume parsing, disordered candidate matching results, and inconsistent multi-table related data, thus improving the data consistency and user experience of the recruitment platform's core business. On the other hand, this application achieves permanent filtering of common non-core parameters in recruitment scenarios by setting a permanent whitelist, effectively filtering out noise interference and reducing the workload of manual investigation. Based on the permanent whitelist, a temporary whitelist is introduced to accurately filter fields expected to change during version iterations, reducing the interference of expected change differences on test results and further reducing the workload of manual investigation.

[0174] Furthermore, through the overall synergy of the aforementioned technical features, this application has formed a fully automated comparison system that covers the entire process from multi-dimensional data collection and in-depth comparison of complex data structures to refined difference filtering. This system can be efficiently integrated into the CI / CD pipeline of recruitment platforms, meet the high-frequency regression testing needs of recruitment platforms before release, and improve the efficiency and accuracy of automated testing of recruitment platform interfaces.

[0175] According to some embodiments of this application, optionally, the common non-core parameters for recruitment scenarios include at least one of timestamp, request identifier, message identifier, interface processing time, sending time, and test environment identifier. The temporary whitelist is configured with a valid time range and the target field to be changed. The temporary whitelist automatically expires upon timeout and restores the difference statistics of the target field.

[0176] According to some embodiments of this application, optionally, in the process of multi-round interface automated testing, the frequency of obtaining multi-dimensional test data of the recruitment platform in the benchmark environment by executing interface automated test cases is lower than the frequency of obtaining multi-dimensional test data of the recruitment platform in the stained environment. The multi-dimensional test data of the benchmark environment can be reused for multi-round stained environment test comparison after a single collection.

[0177] According to some embodiments of this application, optionally, the multi-environment interface automation testing device 40 may further include a storage module for standardizing the multi-dimensional test data of the recruitment platform in a benchmark environment. The standardization process includes at least one of format unification, null value unification, numerical precision normalization, and field naming unification. The standardized multi-dimensional test data is stored in a benchmark database, and a benchmark data index is established according to the use case identifier, interface identifier, data source, and data structure type. Specifically, the acquisition module 401 can be used to detect whether the benchmark environment has changed. When the benchmark environment has not changed, it retrieves the multi-dimensional test data of the recruitment platform in the benchmark environment from the benchmark database and collects the multi-dimensional test data of the recruitment platform in a colored environment by executing interface automation test cases with the same use case identifier.

[0178] According to some embodiments of this application, optionally, the basic data type includes at least one of string, numeric, and boolean values. The comparison rules for the basic data type include checking whether the data types are consistent; if the data types are inconsistent, it is determined as a difference; if the data types are consistent, the data values ​​are compared to see if they are consistent. The comparison rules for multi-level nested structured data include recursively breaking down each nested field from the top-level field, comparing the field values ​​of each field in each level sequentially; when the field value of a certain field is inconsistent, the position of the difference in that field is recorded, and the comparison of subsequent fields is continued recursively without interrupting the comparison process.

[0179] According to some embodiments of this application, optionally, the array includes ordered arrays and unordered arrays; the comparison rules for ordered arrays include comparing array lengths, recording differences when array lengths are inconsistent, and comparing the content of each array element one by one according to the index order when array lengths are consistent; the comparison rules for unordered arrays include comparing array lengths, recording differences when array lengths are inconsistent, and comparing the content of each element one by one according to the field feature matching method when array lengths are consistent.

[0180] According to some embodiments of this application, optionally, the multi-environment interface automated testing device 40 may further include a breakpoint resume module, which is used to pause the current testing process and record the paused node and the completed testing process data if at least one of the following anomalies is detected in any of the stages of acquiring multi-dimensional test data, data classification, data comparison, and difference filtering: interface call anomaly, database connection anomaly, message queue acquisition anomaly, and network fluctuation anomaly; when the anomaly is detected to be resolved, the completed testing process data is reused, and the subsequent testing process is resumed from the paused node.

[0181] According to some embodiments of this application, optionally, the multi-environment interface automated testing device 40 may further include a difference grading module, used to classify multiple difference items in the difference information into difference levels according to the degree of impact on the recruitment platform business and the difference type. The difference levels include a first difference level, a second risk level, and a third risk level. The first difference level corresponds to differences such as inconsistent data types, abnormal values ​​of core business fields, or abnormal interface service responses; the second difference level corresponds to differences such as missing fields; and the third difference level corresponds to differences such as newly added fields in the colored environment or abnormal values ​​of non-core business fields. The permanent whitelist and temporary whitelist only filter difference items of the second and third difference levels; difference items of the first difference level are not included in the filtering of the permanent whitelist and temporary whitelist.

[0182] According to some embodiments of this application, optionally, the generation module 405 can be used to construct a root cause knowledge base for automated testing of recruitment platform interfaces. The root cause knowledge base stores historical difference information and its corresponding root cause types; obtain filtered difference information and its associated information, the associated information including at least one of use case identifier, interface identifier, and business scenario type; input the filtered difference information and associated information into a pre-trained AI root cause analysis model, the AI ​​root cause analysis model performing feature matching on the difference type, difference location, and associated information of the difference information based on the root cause knowledge base, and outputting at least one root cause conclusion and investigation priority; the root cause conclusion includes at least one of program logic error, data synchronization delay, configuration inconsistency, version iteration incompatibility, and environment dependency anomaly; generate a comparison report based on the filtered difference information, associated information, root cause conclusion, and investigation priority, the comparison report including at least one of comparison overview, difference details, whitelist filtering details, associated information, difference level, root cause conclusion, and investigation priority.

[0183] It should be noted that the multi-environment interface automated testing device provided in this application has the same or corresponding technical features as the multi-environment interface automated testing method provided in any of the above embodiments, and produces the same technical effects. For the sake of brevity, further details are omitted here.

[0184] Based on the same technical concept as the multi-environment interface automation testing method provided in the above embodiments, this application also provides an electronic device.

[0185] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 5This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. The electronic device may include a processor 501 and a memory 502 storing computer program instructions. When the processor 501 executes the computer program instructions, it implements the process or function of any of the methods described above.

[0186] Specifically, processor 501 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Memory 502 may include mass storage for data or instructions. For example, memory 502 may be at least one of the following: hard disk drive (HDD), read-only memory (ROM), random access memory (RAM), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, universal serial bus (USB) drive, or other physical / tangible memory storage device. Alternatively, memory 502 may include removable or non-removable (or fixed) media. Furthermore, memory 502 may be internal or external to an electronic device. Memory 502 may be non-volatile solid-state memory. In other words, typically memory 502 includes a tangible (non-transitory) computer-readable storage medium (such as a memory device) encoded with computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in the methods of the embodiments of this application. The processor 501 implements the process or function of any of the methods described in the above embodiments by reading and executing computer program instructions stored in the memory 502.

[0187] In one example Figure 5The illustrated electronic device may also include a communication interface 503 and a bus 510. The processor 501, memory 502, and communication interface 503 are connected via bus 510 and communicate with each other. Communication interface 503 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of this application. Bus 510 may include hardware, software, or both, and can couple components of the online data traffic billing device together. For example, the bus may include at least one of the following: Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, memory bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable buses. Bus 510 may include one or more buses. Although specific buses are described or illustrated in the embodiments of this application, any suitable bus or interconnection method may be considered in the embodiments of this application.

[0188] In conjunction with the methods in the above embodiments, this application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the process or function of any of the methods in the above embodiments.

[0189] In addition, this application also provides a computer program product that stores computer program instructions, which, when executed by a processor, implement the process or function of any of the methods described above.

[0190] The flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of this application have been exemplarily described above, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing a specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine that enables the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams, executable via such processor. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.

[0191] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0192] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.

Claims

1. A multi-environment interface automation testing method, characterized in that, include: By executing the same automated test cases for the interface, multi-dimensional test data of the recruitment platform were obtained in both the baseline environment and the colored environment. The multi-dimensional test data included interface return parameters, database query results, and message queue output results. The multi-dimensional test data are categorized according to the data structure type, and corresponding comparison rules are matched for different data structure types. Based on the comparison rules corresponding to each data structure type, the basic type data, multi-level nested structured data, array and database multi-table related data in the multi-dimensional test data under the two environments are compared to obtain the difference information; The difference information is filtered by a preset permanent whitelist and a temporary whitelist. The permanent whitelist is used to filter common non-core parameters in the recruitment scenario, and the temporary whitelist is used to filter field information that is expected to change in the version iteration of the recruitment platform. A comparison report is generated based on the filtered differences.

2. The method of claim 1, wherein, The common non-core parameters for the recruitment scenario include at least one of the following: timestamp, request identifier, message identifier, interface processing time, sending time, and test environment identifier. The temporary whitelist is configured with a valid time limit and the target field to be changed. The temporary whitelist will automatically expire when the time limit is exceeded and the difference statistics of the target field will be restored.

3. The method of claim 1, wherein, During multi-round automated interface testing, the frequency of obtaining multi-dimensional test data of the recruitment platform in the benchmark environment by executing automated interface test cases is lower than the frequency of obtaining multi-dimensional test data of the recruitment platform in the stained environment. The multi-dimensional test data of the benchmark environment can be reused for multi-round stained environment test comparison after a single collection.

4. The method of claim 1, wherein, The method further includes: The multi-dimensional test data of the recruitment platform under the benchmark environment is standardized. The standardization process includes at least one of the following: format unification, null value unification, numerical precision normalization, and field naming unification. The standardized multi-dimensional test data is stored in the benchmark database, and a benchmark data index is established according to the test case identifier, interface identifier, data source, and data structure type. Obtain multi-dimensional test data from the recruitment platform in both baseline and chromatic environments, including: The system detects whether the baseline environment has changed. If the baseline environment has not changed, it retrieves multi-dimensional test data of the recruitment platform in the baseline environment from the baseline database, and collects multi-dimensional test data of the recruitment platform in the colored environment by executing interface automated test cases with the same test case identifier.

5. The method of claim 1, wherein, The basic data type includes at least one of string, numeric, and boolean values. The comparison rules for the basic data type include checking whether the data types are consistent. If the data types are inconsistent, it is determined to be a difference. If the data types are consistent, the data values ​​are compared to see if they are consistent. The comparison rules for the multi-layered nested structured data include recursively breaking down each nested field from the top-level field, comparing the field values ​​of each field in each layer in turn; when the field value of a certain field is inconsistent, the difference position of the field is recorded, and the comparison of subsequent fields is continued recursively without interrupting the comparison process.

6. The method of claim 1, wherein, The arrays include ordered arrays and unordered arrays; The comparison rules for the ordered array include comparing the array lengths; if the array lengths are inconsistent, the differences are recorded; if the array lengths are consistent, the contents of each array element are compared one by one according to the index order. The comparison rules for the unordered array include comparing the array lengths; if the array lengths are inconsistent, the differences are recorded; if the array lengths are consistent, the contents of each element are compared one by one according to the field feature matching method.

7. The method of claim 1, wherein, The method further includes: If at any stage of acquiring multi-dimensional test data, data classification, data comparison, and difference filtering, an abnormality is detected, such as an interface call abnormality, database connection abnormality, message queue acquisition abnormality, or network fluctuation abnormality, the current test process is paused, and the paused stage node and the completed test process data are recorded. Once the anomaly is detected and resolved, the completed test process data is reused, and the subsequent test process continues from the paused node.

8. The method of claim 1, wherein, Before filtering the difference information using a preset permanent whitelist and a temporary whitelist, the method further includes: Based on the degree of impact on the recruitment platform's business and the type of difference, multiple difference items in the difference information are divided into difference levels, including a first difference level, a second risk level, and a third risk level. The first difference level corresponds to differences such as inconsistent data types, abnormal values ​​of core business fields, or abnormal interface service responses. The second difference level corresponds to differences such as missing fields. The third difference level corresponds to differences such as differences such as newly added fields in the coloring environment or abnormal values ​​of non-core business fields. The permanent whitelist and temporary whitelist only filter differences at the second and third difference levels. Differences at the first difference level are not included in the filtering of the permanent whitelist and temporary whitelist.

9. The method of claim 1, wherein, Based on the filtered difference information, a comparison report is generated, including: Construct a root cause knowledge base for automated testing of recruitment platform interfaces, wherein the root cause knowledge base stores historical difference information and its corresponding root cause types; Obtain the filtered difference information and its associated information, wherein the associated information includes at least one of the following: use case identifier, interface identifier, and business scenario type; The filtered difference information and the associated information are input into a pre-trained AI root cause analysis model. Based on the difference root cause knowledge base, the AI ​​root cause analysis model performs feature matching on the difference type, difference location and associated information of the difference information, and outputs at least one root cause conclusion and investigation priority. The root cause conclusion includes at least one of the following: program logic error, data synchronization delay, configuration inconsistency, version iteration incompatibility, and abnormal environment dependency. A comparison report is generated based on the filtered difference information, the correlation information, the root cause conclusion, and the investigation priority. The comparison report includes at least one of the following: comparison overview, difference details, whitelist filtering details, correlation information, difference level, root cause conclusion, and investigation priority.

10. A multi-environment interface automated testing apparatus, comprising: include: The acquisition module is used to acquire multi-dimensional test data of the recruitment platform in both the baseline environment and the colored environment by executing the same interface automated test cases. The multi-dimensional test data includes interface return parameters, database query results and message queue output results. The matching module is used to classify multi-dimensional test data according to data structure type and match corresponding comparison rules for different data structure types. The comparison module is used to compare basic data types, multi-level nested structured data, arrays, and multi-table database association data in the multi-dimensional test data under two different environments according to the comparison rules corresponding to each data structure type, and obtain the difference information. The filtering module is used to filter the difference information through a preset permanent whitelist and a temporary whitelist. The permanent whitelist is used to filter common non-core parameters in the recruitment scenario, and the temporary whitelist is used to filter field information that is expected to change in the version iteration of the recruitment platform. The generation module is used to generate a comparison report based on the filtered difference information.

11. An electronic device, comprising: The electronic device includes a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the multi-environment interface automated testing method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the multi-environment interface automation testing method as described in any one of claims 1-9.

13. A computer program product, characterised in that, It includes computer program instructions that, when executed by a processor, implement the multi-environment interface automation testing method as described in any one of claims 1-9.

Images