Bidirectional positioning method for test case and test data and related equipment

Abstract

The invention provides a bidirectional positioning method for test cases and test data and related equipment, and the method comprises the steps: scanning a directory of each test case in a test case set after the loading of the test case set is completed, and determining the test data position preference of each test case; when a test data positioning instruction is received, determining a target test case corresponding to the test data positioning instruction in the test case set, and positioning a test data file of the target test case based on test data position preference corresponding to the target test case in combination with naming rules and annotation information of the target test case; and when a test case positioning instruction is received, determining a target test data file corresponding to the test case positioning instruction, and positioning a test case corresponding to the target test data file in the test case set based on the storage path of the target test data file, the naming rule and each test data position preference. Therefore, the problems of loose association between the test case and the test data source and low positioning efficiency are solved.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a bidirectional positioning method and related equipment for test cases and test data. Background Technology

[0002] In API automation testing, a common practice is to separate the test logic code from the test-driven data. That is, the test class writes the API call logic, while the request parameters, preparation data, and expected results are stored in a separate test data source file to facilitate the maintenance and expansion of test cases.

[0003] In existing solutions, test classes typically load corresponding data files in JSON, YAML, or other formats at runtime by configuring data paths in the code. Generally, each test method corresponds to a data file, which records the request information and expected return results for that test case. As automated testing projects expand, the number of test classes and data files increases, and the storage locations of these data files vary across projects. Testers often need to manually locate the corresponding data files based on the path configuration when modifying test classes. Conversely, when viewing a specific data file, it's difficult to directly determine its corresponding test class and test method; manual code searching or directory structure analysis is usually required for reverse location.

[0004] Therefore, in existing automated interface testing solutions, test classes and test data sources are only loosely associated through path agreements. The two lack an intuitive, clear, and quick-to-locate correspondence, resulting in frequent manual searches and directory jumps during test case maintenance and troubleshooting, leading to low location efficiency. Summary of the Invention

[0005] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly in existing automated interface testing solutions where test classes and test data sources are loosely associated only through path agreements. The lack of an intuitive, clear, and quickly locating correspondence between the two leads to frequent manual searches and directory jumps during test case maintenance and troubleshooting, resulting in low location efficiency.

[0006] Firstly, this application provides a bidirectional positioning method for test cases and test data, the method comprising:

[0007] In response to the test case set loading completion command, scan the directory of each test case in the test case set to determine the test data location preference for each test case;

[0008] Upon receiving a test data location instruction, determine the target test case corresponding to the test data location instruction in the test case set, and locate the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case;

[0009] Upon receiving a test case location instruction, the target test data file corresponding to the instruction is determined, and the test cases corresponding to the target test data file are located in the test case set based on the storage path, naming rules, and location preferences of each test data file.

[0010] In one embodiment, the step of scanning the directory of each test case in the test case set to determine the test data location preference for each test case includes:

[0011] Count the number of test data files associated with each test case in the directory of each test case in the test case set;

[0012] For each test case, if the number of test data files associated with the test case is greater than a preset threshold, the test data location preference for the test case is determined to be stored in the same directory as the test case. If the number of test data files associated with the test case is less than or equal to the preset threshold, the test data location preference for the test case is determined to be uniformly stored in a preset test data directory.

[0013] In one embodiment, the step of locating the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case, includes:

[0014] Based on the test data location preferences corresponding to the target test cases, determine the candidate search directory for test data;

[0015] Based on the naming rules and annotation information of the target test cases, generate test data file identifiers corresponding to the target test cases;

[0016] In the test data candidate search directory, the test data file of the target test case is determined based on the test data file identifier.

[0017] In one embodiment, the step of generating a test data file identifier corresponding to the target test case based on the naming rules and annotation information of the target test case includes:

[0018] Obtain the class name and method name of the target test case;

[0019] Parse the annotation information used to identify test data from the target test cases and extract the annotation parameter values;

[0020] Based on the class name, method name, and annotation parameter values, a test data file identifier corresponding to the target test case is generated according to the naming rules of the target test case.

[0021] In one embodiment, the step of determining the test data file of the target test case based on the test data file identifier in the test data candidate search directory includes:

[0022] In the test data candidate search directory, check if there is a file corresponding to the test data file identifier. If it exists, identify the file as the test data file for the target test case.

[0023] If the file corresponding to the test data file identifier does not exist, a new test data file is created in the test data candidate search directory, and the new test data file is identified as the test data file of the target test case. The file name of the new test data file is generated based on the method name of the target test case and the preset file extension. The content of the new test data file is generated based on the existing test case structure, the annotation information of the target test case, or the standard skeleton template.

[0024] In one embodiment, the step of locating the test case corresponding to the target test data file in the test case set based on the storage path, naming rules, and location preferences of the target test data file includes:

[0025] Based on the storage path of the target test data file, determine the target test data location preference corresponding to the target test data file among the various test data location preferences;

[0026] Based on the location preference of the target test data, the range of candidate test cases is determined in the test case set;

[0027] Based on the naming rules of the target test data file, generate test case identifiers corresponding to the target test data file;

[0028] Within the candidate test case range, test cases corresponding to the target test data file are matched based on the test case identifier.

[0029] In one embodiment, the step of generating test case identifiers corresponding to the target test data file according to the naming rules of the target test data file includes:

[0030] Obtain the target filename of the target test data file;

[0031] If the target file name conforms to the naming rules of the target test data file, then based on the target file name, test case identifiers corresponding to the target test data file are generated according to the naming rules of the target test data file;

[0032] If the target file name does not conform to the naming rules of the target test data file, the storage path of the target test data file is parsed, the directory level field used to distinguish test cases is extracted, and a test case identifier corresponding to the target test data file is generated based on the directory level field.

[0033] Secondly, this application provides a bidirectional positioning device for test cases and test data, the device comprising:

[0034] The test data location preference determination module is used to scan the directory of each test case in the test case set in response to the test case set loading completion instruction, and determine the test data location preference for each test case;

[0035] The test data file location module is used to determine the target test case corresponding to the test data location instruction in the test case set when a test data location instruction is received, and locate the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case;

[0036] The test case location module is used to determine the target test data file corresponding to the test case location instruction when a test case location instruction is received, and to locate the test case corresponding to the target test data file in the test case set based on the storage path, naming rules and location preferences of each test data file.

[0037] Thirdly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of any of the bidirectional location methods for test cases and test data in the above embodiments.

[0038] Fourthly, this application provides a computer device, including: one or more processors, and a memory;

[0039] The memory stores computer-readable instructions, which, when executed by one or more processors, perform the steps of any of the bidirectional location methods for test cases and test data in the above embodiments.

[0040] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0041] The bidirectional location method and related equipment for test cases and test data provided in this application scan the directory of each test case after the test case set is loaded and determine its test data location preference, thus achieving an initial association between test cases and test data. This provides a clear basis for subsequent location operations and avoids the inefficiency of relying on manual searching and path inference. Upon receiving a test data location instruction, the method can quickly and accurately locate the corresponding test data file based on the target test case's test data location preference, naming rules, and annotation information. This allows testers to obtain the required test data without frequent directory jumps or manual comparisons, significantly improving data retrieval and test case maintenance efficiency. Upon receiving a test case location instruction, the method quickly finds the corresponding test case in the test case set based on the target test data file's storage path, naming rules, and test data location preference, achieving reverse tracing from test data to test cases. This establishes an intuitive, clear, and quickly searchable correspondence, thereby solving the problem of loose association between test cases and test data sources and low location efficiency. Attached Figure Description

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

[0043] Figure 1 A flowchart illustrating the bidirectional location method for test cases and test data provided in the embodiments of this application;

[0044] Figure 2 This is a schematic diagram of the structure of the bidirectional positioning device for test cases and test data provided in the embodiments of this application;

[0045] Figure 3 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0046] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] This application provides a bidirectional positioning method for test cases and test data. The following embodiments illustrate this method using a computer device as an example. It is understood that the computer device can be any device with data processing capabilities, including but not limited to a single server, server cluster, personal laptop, desktop computer, etc. Figure 1 As shown, the method may include the following steps:

[0048] S101: In response to the test case set loading completion instruction, scan the directory of each test case in the test case set to determine the test data location preference for each test case.

[0049] Among them, the test case set refers to a set of test case files organized according to preset rules. Each test case corresponds to an automated verification script for a specific function or interface in the software system. The test case directory refers to the folder path where a single test case file is stored. The test data location preference refers to the storage location and organizational structure of the test data files that the test case prioritizes to access or associate during execution.

[0050] Specifically, after responding to the test case set loading completion command, each test case file in the test case set can be accessed sequentially, and its directory path can be obtained. By reading the directory structure and file name information, the folder hierarchy and file naming rules of each test case can be analyzed to determine the location of test data that the test case may access during execution. By scanning the directory structure, the relative location of the test data files can be identified, and preliminary association information between test cases and corresponding test data locations can be recorded, providing basic data for subsequent localization.

[0051] During processing, each test case directory and its corresponding test data location preferences can be saved in a computer-readable format, forming a data structure that can be quickly retrieved. This data structure can directly provide the test data storage path information for the target test case when a test data location or test case location instruction is received, avoiding repeated scanning and manual searching, and improving data access efficiency. Furthermore, by analyzing directory hierarchy, naming rules, and historical access records, the determination of test data location preferences can be further optimized, enabling each test case to quickly locate the most likely test data file during execution.

[0052] Furthermore, during the scanning process, annotations or metadata in the test case files can be used to supplement and verify the test data location preferences, making the recorded test data locations more accurate and reliable. This approach ensures that the correspondence between test cases and test data is intuitive and clear throughout the entire testing process, providing a stable basis for subsequent bidirectional positioning operations. This automates and streamlines test data management, providing a reliable data foundation and execution guarantee for the entire automated interface testing process.

[0053] By scanning the directory of each test case in response to the test case set loading completion command and determining the test data location preference of each test case, the storage information and access preferences of the test cases and their related test data can be obtained in advance. This allows test cases to directly reference the pre-determined location when executing or locating test data without manual searching or frequent directory jumps, thus significantly improving the speed and accuracy of test data location. This method can establish a clear and intuitive correspondence between test cases and test data, providing a reliable foundation for subsequent test data retrieval and test case maintenance, reducing maintenance costs, and improving the overall efficiency and controllability of the testing process.

[0054] S102: Upon receiving a test data location instruction, determine the target test case corresponding to the test data location instruction in the test case set, and locate the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case.

[0055] Among them, the test data location instruction refers to the operation signal or instruction used to trigger the computer to automatically find a specific test data file. The target test case corresponding to the instruction refers to the specific test case file associated with the test data location instruction in the test case set. The naming rule of the test case refers to the file naming specification used to identify the content or function of the test case file. The annotation information refers to the mark or description embedded in the test case file to provide additional information or metadata. The test data file refers to the computer-readable file containing input data, expected results or configuration information used to verify the function of the test case.

[0056] Upon receiving a test data location instruction, the system first searches the test case set for the target test case related to that instruction. By reading the identification information contained in the instruction or the metadata associated with the test case file, it precisely matches the unique target test case file within the test case set and obtains its storage path and related attribute information. This method ensures that subsequent operations are based on the correct test case, thus avoiding test data location failures due to instruction parsing or file matching errors.

[0057] Subsequently, the previously determined test data location preferences of the target test case can be read. These preferences record the storage paths and organizational structures of test data that the target test case prioritizes for access during execution. Combining the naming rules and annotation information of the target test case, files in the test data directory are filtered and matched to quickly identify the test data file corresponding to the target test case. In this process, filenames, paths, and data association information described in test case annotations can be used as criteria. Rule matching and path comparison are used to determine the most likely corresponding test data file, achieving accuracy and stability in location.

[0058] After processing, the mapping relationship between the target test cases and their corresponding test data files can be stored as a data structure that can be quickly retrieved by the computer, allowing for direct access during subsequent test data access or test case debugging. This approach avoids repeatedly scanning the entire test case set and test data directory, improving the efficiency and accuracy of data location, and ensuring that the relationship between test cases and test data is clear and traceable. This provides a reliable data foundation for automated interface testing, reduces manual searching and frequent directory jumps, and improves the overall efficiency of test execution, maintenance, and troubleshooting.

[0059] By first determining the target test case corresponding to the received test data location instruction, and then locating the test data file of the target test case based on its test data location preferences, combined with naming rules and annotation information, a clear correspondence between test cases and test data can be established in advance. This allows test data to be located quickly and accurately during execution or debugging without the need for manual searching or frequent directory jumps, thereby significantly improving the efficiency and accuracy of test data retrieval. It also ensures the reliability and traceability of the association between test cases and test data, providing a stable data foundation for automated interface testing and improving the overall efficiency of test execution, maintenance, and troubleshooting.

[0060] S103: Upon receiving a test case location instruction, determine the target test data file corresponding to the instruction, and locate the test case corresponding to the target test data file in the test case set based on the target test data file's storage path, naming rules, and the location preferences of each test data file.

[0061] Among them, the test case location instruction refers to the operation signal or instruction used to trigger the computer to find the test case corresponding to a specific test data file; the target test data file refers to a computer-readable file containing input data, expected results or configuration information used to verify the software function; the storage path refers to the location of the test data file in the storage system; the naming rule of the target test data file refers to the file naming convention used to identify the content or function of the test data file; and the target test case refers to the specific test case file in the test case set that corresponds to the target test data file.

[0062] Upon receiving a test case location instruction, the system first identifies the target test data file from the test data storage system. By reading the identification information or metadata associated with the test data file contained in the instruction, the unique location and related attribute information of the target test data file are determined. This ensures that subsequent operations are based on the correct test data file, thus avoiding test case location failures due to instruction parsing errors or inaccurate file matching.

[0063] Subsequently, based on the storage path, naming conventions, and location preferences of the target test data file, the storage path, file name, and related annotation information of each test case file in the test case set can be analyzed one by one to filter and match test cases that may be associated with the target test data file. By comparing file names, path levels, and test data preferences, the test cases corresponding to the target test data file can be accurately determined, thereby achieving rapid reverse location from test data to test cases.

[0064] After location is complete, the mapping relationship between the target test data file and the corresponding test case can be saved in a computer-searchable format for direct retrieval during subsequent test execution or debugging, avoiding repeated scanning of test case sets and test data directories. This processing method establishes a clear and reliable correspondence between test data and test cases, enabling test cases to quickly locate relevant test data during debugging and maintenance, significantly improving the efficiency and accuracy of test case location, ensuring the traceability of the correlation, providing a stable data foundation for interface automated testing, and improving the overall efficiency of test execution, troubleshooting, and maintenance.

[0065] By first determining the target test data file corresponding to the test case location instruction upon receiving it, and then locating the corresponding test case in the test case set based on the storage path, naming rules, and location preferences of the target test data file, a clear and reliable association between test data and test cases can be established. This enables test cases to quickly and accurately locate relevant test data during execution or debugging without manual searching or frequent directory jumps, thus significantly improving the efficiency and accuracy of test case location. At the same time, it ensures the traceability of the association, provides a stable data foundation for interface automated testing, and improves the overall efficiency of test execution, maintenance, and troubleshooting.

[0066] In the above embodiments, by scanning the directory of each test case after the test case set is loaded and determining its test data location preference, a preliminary association between test cases and test data is achieved, providing a clear basis for subsequent location operations and avoiding the inefficiency of relying on manual searching and path inference. Upon receiving a test data location instruction, the system can quickly and accurately locate the corresponding test data file based on the target test case's test data location preference, naming rules, and annotation information. This allows testers to obtain the required test data without frequent directory jumps or manual comparisons, significantly improving data retrieval and test case maintenance efficiency. Upon receiving a test case location instruction, the system quickly finds the corresponding test case in the test case set based on the target test data file's storage path, naming rules, and test data location preference, achieving reverse tracing from test data to test cases. This establishes an intuitive, clear, and quickly searchable correspondence, thereby solving the problem of loose association between test cases and test data sources and low location efficiency.

[0067] In one embodiment, the step of scanning the directory of each test case in the test case set to determine the test data location preference for each test case includes:

[0068] Count the number of test data files associated with each test case in the directory of each test case in the test case set;

[0069] For each test case, if the number of test data files associated with the test case is greater than a preset threshold, the test data location preference for the test case is determined to be stored in the same directory as the test case. If the number of test data files associated with the test case is less than or equal to the preset threshold, the test data location preference for the test case is determined to be uniformly stored in a preset test data directory.

[0070] Among them, test data files refer to computer-readable files that contain input data, expected results, or configuration parameters used to verify the functionality of test cases. The preset threshold is a value used to determine whether the number of test data files associated with a test case is sufficient to determine its storage strategy. The preset test data directory is a specified storage path for uniformly storing a small number of test data files.

[0071] In this embodiment, the test data files under each test case directory in the test case set can be counted first. By traversing each test case directory, the number and file names of the test data files associated with that test case are read, thereby obtaining the total number of test data files associated with each test case. This processing method can provide basic data for subsequently determining the test data storage strategy for test cases and ensure that each test case can accurately understand the distribution of its associated test data.

[0072] Subsequently, for each test case, the number of test data files obtained from the statistics can be compared with a preset threshold. If the number of test data files associated with a test case is greater than the preset threshold, the test data location preference is set to be stored in the same directory as the test case, so that a large number of test data files can be quickly accessed during execution, improving data retrieval efficiency and execution efficiency. If the number of test data files is less than or equal to the preset threshold, the test data location preference is set to be uniformly stored in a preset test data directory, so as to centrally manage a small number of test data files and simplify the data maintenance and search process.

[0073] After processing, the test data location preferences for each test case can be recorded as a data structure that can be quickly accessed by the computer. This data can be directly used when executing tests, locating data, or maintaining test cases, without the need to rescan directories or repeatedly count files. This approach allows for flexible determination of test data storage strategies based on the actual data volume of each test case, achieving efficient and stable data access and ensuring a clear, intuitive, and traceable relationship between test cases and test data. This improves data management, execution, and maintenance efficiency during automated interface testing.

[0074] By counting the number of test data files associated with each test case directory and comparing the file count with a preset threshold to determine the preferred test data location for each test case, different storage strategies can be adopted for test data of different magnitudes, thereby optimizing the access efficiency and management of test data. For test cases with a large number of associated test data files, storing their test data in the same directory reduces data retrieval paths and improves data access speed during execution. For test cases with a small number of associated test data files, storing their test data centrally in a preset test data directory facilitates unified management and maintenance, reducing the management complexity caused by scattered storage. This approach ensures that each test case can quickly and accurately access the required test data during execution, while maintaining clear and orderly storage and management of test data. This improves the execution efficiency, data retrieval efficiency, and maintenance efficiency of interface automation testing, and guarantees the reliable and traceable relationship between test cases and test data.

[0075] In one embodiment, the step of locating the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case, includes:

[0076] Based on the test data location preferences corresponding to the target test cases, determine the candidate search directory for test data;

[0077] Based on the naming rules and annotation information of the target test cases, generate test data file identifiers corresponding to the target test cases;

[0078] In the test data candidate search directory, the test data file of the target test case is determined based on the test data file identifier.

[0079] Among them, the test data candidate search directory refers to the storage path used to retrieve potentially related test data files, determined based on test data location preferences, and the test data file identifier refers to the identifier used to uniquely identify the corresponding test data file, generated according to the naming rules and annotation information of the target test cases.

[0080] In this embodiment, candidate search directories for test data can first be determined based on the test data location preferences of the target test cases. By reading the preferred access paths or associated directories recorded in the test cases, these paths can be mapped to one or more storage paths that can be used to retrieve test data files. In practice, the test case directory structure and historical execution records can be analyzed to use these paths as candidate search scopes, ensuring that subsequent searches can cover potentially associated test data files and avoid omissions or mismatches.

[0081] Subsequently, test data file identifiers corresponding to the target test cases can be generated based on the naming rules and annotation information of the target test cases. During processing, the naming conventions and annotation content in the test case files can be parsed and converted into unique identifiers for matching test data files. This step establishes a direct association between test cases and their potentially associated test data files, facilitating the rapid selection of target files from a large number of test data files and improving the accuracy and efficiency of data location.

[0082] After identifying the test data file, files can be compared and matched in the candidate search directory. By matching filenames, paths, and other metadata, the test data file of the target test case can be accurately located. After matching, the target test case, its corresponding test data file path, and related information can be saved as a quickly searchable data structure for direct retrieval during test execution or debugging, eliminating the need to repeatedly scan the entire test data storage system. This approach ensures that test cases quickly and accurately retrieve their corresponding test data files during execution, avoiding manual searches or frequent directory jumps, improving the efficiency and accuracy of test data location. It also ensures that the relationship between test cases and test data is intuitive and reliable, providing a stable data foundation for automated interface testing and improving the overall efficiency of test execution, maintenance, and troubleshooting.

[0083] By determining the candidate search directory for test data based on the test data location preferences of the target test cases, and generating test data file identifiers by combining the naming rules and annotation information of the target test cases, the test data files of the target test cases can be accurately matched in the candidate search directory. This establishes a clear and quickly searchable correspondence between test cases and test data, enabling test cases to directly access the corresponding test data files during execution or debugging without manual searching or frequent directory jumps. This significantly improves the efficiency and accuracy of test data location, ensures the reliability and traceability of the association, provides a stable data foundation for interface automated testing, and enhances the overall efficiency of test execution, maintenance, and troubleshooting.

[0084] In one embodiment, the step of generating a test data file identifier corresponding to the target test case based on the naming rules and annotation information of the target test case includes:

[0085] Obtain the class name and method name of the target test case;

[0086] Parse the annotation information used to identify test data from the target test cases and extract the annotation parameter values;

[0087] Based on the class name, method name, and annotation parameter values, a test data file identifier corresponding to the target test case is generated according to the naming rules of the target test case.

[0088] Among them, the class name refers to the name of the class to which the target test case belongs, which is used to identify the logical affiliation of the test case; the method name refers to the name of the test method specifically executed in the target test case, which is used to identify the specific operation of the test function; and the annotation parameter value refers to the parameter value in the annotation information that is specifically used to describe or identify the test data.

[0089] In this embodiment, the class name and method name of the target test case can be obtained first. By reading the structure information or metadata of the test case file, the class to which the target test case belongs and the name of the specific method to be executed can be identified. This step clarifies the logical affiliation and specific function of the test case, providing basic information for the subsequent generation of test data file identifiers. After obtaining the class name and method name, the annotation information used to identify test data can be parsed in the test case. By analyzing the annotation content, annotation parameter values ​​can be extracted. These parameter values ​​contain key identification information corresponding to the test data file, providing a basis for accurately matching test data.

[0090] After extracting the class name, method name, and annotation parameter values, this information can be combined according to the naming rules of the target test case to generate a test data file identifier corresponding to the target test case. During processing, the class name, method name, and annotation parameter values ​​can be concatenated or mapped according to a preset format to form a unique identifier used to accurately match the corresponding test data file in the test data candidate search directory. This processing method establishes a direct and unique association between test cases and test data, ensuring the accuracy and stability of test data during the retrieval process.

[0091] The above processing ensures that each test case generates a unique and identifiable test data file identifier, enabling test cases to quickly locate the corresponding test data file during execution or debugging without manual searching or frequent directory jumps, thus significantly improving the efficiency and accuracy of test data location. Simultaneously, this method guarantees an intuitive, reliable, and traceable relationship between test cases and test data, providing a stable data foundation for automated interface testing and improving the overall efficiency of test execution, maintenance, and troubleshooting.

[0092] By obtaining the class name and method name of the target test case, parsing the annotation information used to identify test data from the test case and extracting the annotation parameter values, and then generating a test data file identifier based on the class name, method name, and annotation parameter values ​​according to the naming rules of the target test case, a unique and identifiable test data identifier can be established for each test case. This allows the test case to quickly and accurately locate the corresponding test data file during execution or debugging without manual searching or frequent directory jumps, thus significantly improving the efficiency and accuracy of test data location. At the same time, it ensures that the relationship between test cases and test data is clear, reliable, and traceable, providing a stable data foundation for interface automated testing and improving the overall efficiency of test execution, maintenance, and troubleshooting.

[0093] In one embodiment, the step of determining the test data file of the target test case based on the test data file identifier in the test data candidate search directory includes:

[0094] In the test data candidate search directory, check if there is a file corresponding to the test data file identifier. If it exists, identify the file as the test data file for the target test case.

[0095] If the file corresponding to the test data file identifier does not exist, a new test data file is created in the test data candidate search directory, and the new test data file is identified as the test data file of the target test case. The file name of the new test data file is generated based on the method name of the target test case and the preset file extension. The content of the new test data file is generated based on the existing test case structure, the annotation information of the target test case, or the standard skeleton template.

[0096] The new test data file refers to a usable test data file generated based on the target test cases when the target test data file does not exist. The file name is generated based on the method name of the target test case and the preset file extension. The file content is generated based on the existing test case structure, the annotation information of the target test case, or the standard skeleton template, in order to ensure the consistency and integrity of the test data format.

[0097] In this embodiment, the system first checks the candidate search directory for test data to see if a file corresponding to the test data file identifier exists. By traversing the file names and related metadata information in the directory, the file matching the test data file identifier is identified and determined to be the test data file for the target test case. This process ensures that test cases can directly access existing test data files during execution or debugging, avoiding duplicate creation or redundant storage and improving data access efficiency.

[0098] If no file corresponding to the test data file identifier is found in the candidate search directory, a new test data file can be created and designated as the test data file for the target test case. During creation, a file name can be generated based on the method name of the target test case and a preset file extension to ensure that the new file can uniquely identify the corresponding test case. Simultaneously, file content can be generated based on the existing test case structure, the annotation information of the target test case, or a standard skeleton template, ensuring that the newly created test data file has a complete format and necessary initial data, facilitating subsequent test execution and maintenance.

[0099] After testing or creation, the determined test data file paths and related information can be saved as a quickly searchable data structure. This structure can be directly accessed during test execution or debugging without repeatedly scanning directories or regenerating files. This approach ensures that each target test case can quickly and accurately retrieve its corresponding test data file from the test data candidate search directory, avoiding manual searching and frequent directory jumps. This improves the efficiency of test data location and management, while ensuring a clear, reliable, and traceable relationship between test cases and test data. This provides a stable data foundation for automated interface testing and enhances the overall efficiency of test execution, maintenance, and troubleshooting.

[0100] By checking the candidate search directory for test data to see if a file corresponding to the test data file identifier exists, and if it does, it is directly identified as the test data file for the target test case; otherwise, a new test data file is created and identified as the test data file for the target test case. This ensures that each target test case always has a unique and identifiable test data file, enabling test cases to quickly and accurately access the corresponding test data file during execution or debugging without manual searching or frequent directory jumps. It also ensures that the name and content of newly created files conform to preset specifications, guaranteeing data format and structure consistency. This significantly improves the efficiency and accuracy of test data location, management, and maintenance, ensuring a clear, reliable, and traceable relationship between test cases and test data. It provides a stable data foundation for automated interface testing and improves the overall efficiency of test execution, maintenance, and troubleshooting.

[0101] In one embodiment, the step of locating the test case corresponding to the target test data file in the test case set based on the storage path, naming rules, and location preferences of the target test data file includes:

[0102] Based on the storage path of the target test data file, determine the target test data location preference corresponding to the target test data file among the various test data location preferences;

[0103] Based on the location preference of the target test data, the range of candidate test cases is determined in the test case set;

[0104] Based on the naming rules of the target test data file, generate test case identifiers corresponding to the target test data file;

[0105] Within the candidate test case range, test cases corresponding to the target test data file are matched based on the test case identifier.

[0106] Among them, the candidate test case range refers to the set of test cases that may be associated with the target test data file, which are filtered according to the location preference of the target test data. The test case identifier is a unique identifier generated according to the naming rules of the target test data file, which is used to match the corresponding test case.

[0107] In this embodiment, the target test data file's storage path is first compared with various test data location preferences to determine the target test data file's corresponding target test data location preference. During processing, the test data location preference records for each test case can be traversed, and the target test data file's storage path can be matched with these preferences to identify the most likely associated storage location for that test data file. By determining the target test data location preference, a range constraint can be provided for subsequent test case matching, reducing unnecessary full searches and improving processing efficiency.

[0108] Subsequently, based on the determined target test data location preference, a range of candidate test cases can be filtered from the test case set. During processing, the storage paths, directory structures, or association information of all test cases in the test case set can be compared with the target test data location preference. Only test cases whose storage paths or directories match the target test data location preference are retained, forming a candidate subset. By limiting the candidate range, invalid searches across the entire test case set can be avoided, improving matching accuracy and processing speed.

[0109] After determining the scope of candidate test cases, test case identifiers can be generated according to the naming rules of the target test data file. During processing, the file name, structure information, or related tags of the target test data file can be parsed and converted into unique test case identifiers for precise matching within the candidate scope. Subsequently, within the candidate test case scope, by comparing the test case identifiers, test cases corresponding to the target test data file can be matched, thereby establishing a precise association between test data and test cases.

[0110] By determining the target test data location preference corresponding to the target test data file based on its storage path within various test data location preferences, and then filtering the range of candidate test cases in the test case set based on this preference, and finally generating test case identifiers according to the naming rules of the target test data file and matching the corresponding test cases within the candidate range, precise location of test data to test cases can be achieved. This allows each target test data file to quickly and accurately find its corresponding test case without manual searching or frequent directory jumps, thus significantly improving the efficiency and accuracy of test case matching and location. At the same time, it ensures that the relationship between test data and test cases is clear, reliable, and traceable, providing a stable data foundation for interface automated testing and improving the overall efficiency of test execution, maintenance, and troubleshooting.

[0111] In one embodiment, the step of generating test case identifiers corresponding to the target test data file according to the naming rules of the target test data file includes:

[0112] Obtain the target filename of the target test data file;

[0113] If the target file name conforms to the naming rules of the target test data file, then based on the target file name, test case identifiers corresponding to the target test data file are generated according to the naming rules of the target test data file;

[0114] If the target file name does not conform to the naming rules of the target test data file, the storage path of the target test data file is parsed, the directory level field used to distinguish test cases is extracted, and a test case identifier corresponding to the target test data file is generated based on the directory level field.

[0115] The directory hierarchy field refers to the names of the various directories in the storage path of the target test data file, which are used to distinguish different test cases.

[0116] In this embodiment, the target filename of the target test data file can be obtained first, and then compared with a preset naming rule. When the filename conforms to the naming rule, a test case identifier corresponding to the test data file can be directly generated according to the filename and the naming rule. In this way, a unique and identifiable matching relationship can be established for each test data file, enabling the corresponding test case to be quickly and accurately located during test execution, debugging, or troubleshooting without the need for manual searching or frequent directory jumps, thereby significantly improving the efficiency and accuracy of location.

[0117] When the target filename does not conform to the naming rules, the storage path of the test data file can be parsed to extract the directory hierarchy field used to distinguish test cases. By analyzing the names and structure of each directory level, test case identifiers corresponding to the test data file can be generated. In this way, even if the filename is not standardized or there are differences, the association between the test data file and the corresponding test case can be accurately established, avoiding manual searching or error location due to matching failures. This improves the completeness and reliability of the association between test data and test cases, while ensuring the overall efficiency and stability of test execution, maintenance, and troubleshooting in interface automated testing.

[0118] By first obtaining the target filename of the target test data file and determining whether it conforms to the preset naming rules, test case identifiers corresponding to the test data file can be directly generated if the filename conforms to the rules. This establishes a unique and identifiable matching relationship, enabling test data to quickly and accurately locate the corresponding test cases during test execution, debugging, and troubleshooting without manual searching or frequent directory jumps. When the filename does not conform to the naming rules, test case identifiers are generated by parsing the storage path and extracting the directory hierarchy field used to distinguish test cases. This ensures the accurate association between test data files and corresponding test cases even when filenames are not standardized or differ. Through this processing method, each test data file can establish a clear, reliable, and traceable association with its corresponding test case, significantly improving the efficiency of test case matching and location, enhancing the overall efficiency of interface automated testing execution, maintenance, and troubleshooting, while ensuring the integrity and accuracy of the association between test data and test cases.

[0119] To facilitate understanding of the scheme in this application, specific examples are provided below.

[0120] This example provides a bidirectional location method for test cases and test data in automated testing projects. This method runs in an integrated development environment and works in conjunction with the editor, project structure, and syntax parsing capabilities to achieve rapid association and jump between test code and driving data. It is used to solve the problem that test classes and test data files in existing automated testing projects rely only on path conventions for loose association and have high manual location costs.

[0121] In automated API testing, test cases typically employ a design that separates test classes from test data sources. Test classes organize test methods, prepare the execution environment, and load test data, while test data files contain API request parameters, environment preparation data, and expected response results. Test classes usually use pre-defined data directory configurations to point to the data source location, with different test methods corresponding to different data files. These data files record test case descriptions and structured test content using agreed-upon fields. However, as projects grow in scale and test package layers and data directory structures become increasingly complex, testers frequently switching between test classes and data files must rely on manual path retrieval or repeated file searches, resulting in low efficiency and a high learning curve.

[0122] To address the aforementioned issues, this example method first performs a test case location preference detection on the test project structure when the project is opened by the integrated development environment. This process scans the test source code directory and related data file directories in the background, counts the number of test data files distributed across different locations, and determines, based on a preset threshold, whether the current project prefers to store data files in a unified test data directory or in a directory at the same level or adjacent to the test classes. This preference result is stored as a project-level configuration for consistent use in subsequent path inference processes, thereby maintaining the consistency and stability of inference rules across different project agreements.

[0123] After determining the engineering-level preferences, when testers browse or edit test methods within a test class, the system uses syntax parsing capabilities to identify test methods that match the characteristics of the test cases. It also parses existing configuration information related to the data directory from the test class, generating a set of candidate data directory identifiers. Based on this, and combining the aforementioned engineering-level test case location preferences and the path information of the test class, the candidate directories are restructured and inferred to obtain one or more actual data directory paths. Subsequently, a corresponding set of candidate data file names is generated according to the naming conventions of the test methods, and an existence match is performed within the inferred data directories to determine whether the current test method is associated with test data files and their specific locations.

[0124] When an existing test data file is matched, a direct jump capability is provided in the editing area corresponding to the test method, allowing testers to open the associated data file with one click. When no data file is matched, it is clearly indicated that the current test method has not yet been configured with test data, and the data file creation process begins when the user triggers an operation. During the creation process, the test method name is used as the base filename, and the corresponding data file is generated according to the file type selected by the user. Priority is given to reusing the structure template from the data files of adjacent test cases to maintain data consistency under the same interface test scenario. If an existing template cannot be reused, recommended sample data is attempted to be generated based on the service meta information declared in the test class. If a valid template still cannot be obtained, a standard skeleton data file containing basic structure and test case description fields is generated to ensure that the newly created file has a legal structure that can be directly edited.

[0125] When testers operate from the data file side, this example also supports the reverse location process. When the data file is opened in the editor, it first determines whether it is located under the unified test data directory based on the actual path of the data file. If it is, the corresponding data directory identifier is calculated based on the path relative to the test data root directory; if it is not, a relative path identifier is generated based on the root path of the current module's test source code. Subsequently, using the same path inference rules as the aforementioned test class side, it reverse-matches potentially related test classes and test methods within the test source code scope, thereby enabling a quick jump from the test data file back to the test code location that drives the data.

[0126] To avoid impacting editor performance in scenarios involving large files or frequent scrolling, this example introduces a view-area-aware navigation control mechanism during the implementation of the aforementioned bidirectional positioning capability. By listening to changes in the editor's view area, the first visible logical line number in the current view is calculated in real time and temporarily stored in the editor context. When rendering the navigation entry point, a navigation marker is generated only at a representative position within the current view area. Furthermore, high-frequency events are merged through delayed refresh and debouncing control mechanisms to ensure timely response while avoiding unnecessary syntax scanning and UI redraw overhead.

[0127] Based on this, the method in this example achieves automatic association, bidirectional rapid location, and intelligent creation between test cases and test data without changing the existing automated test case design pattern and data organization method. This enables testers to switch efficiently between test code and data files, significantly reducing the cost of manual retrieval paths and memorizing project structures, thereby improving the overall efficiency of automated test case maintenance, analysis, and expansion.

[0128] The bidirectional positioning device for test cases and test data provided in the embodiments of this application is described below. The bidirectional positioning device for test cases and test data described below can be referred to in correspondence with the bidirectional positioning method for test cases and test data described above. Figure 2 As shown, this application provides a bidirectional positioning device for test cases and test data, the device comprising:

[0129] The test data location preference determination module 201 is used to scan the directory of each test case in the test case set in response to the test case set loading completion instruction and determine the test data location preference of each test case.

[0130] The test data file location module 202 is used to determine the target test case corresponding to the test data location instruction in the test case set when a test data location instruction is received, and locate the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case;

[0131] The test case location module 203 is used to determine the target test data file corresponding to the test case location instruction when a test case location instruction is received, and to locate the test case corresponding to the target test data file in the test case set based on the storage path, naming rules and location preferences of each test data file.

[0132] In one embodiment, the test data location preference determination module 201 includes:

[0133] The test data file count unit is used to count the number of test data files associated with each test case in the directory of each test case in the test case set;

[0134] The test data location preference determination unit is used to determine the test data location preference of each test case as being stored in the same directory as the test case when the number of test data files associated with the test case is greater than a preset threshold, and to determine the test data location preference of the test case as being uniformly stored in a preset test data directory when the number of test data files associated with the test case is less than or equal to the preset threshold.

[0135] In one embodiment, the test data file location module 202 includes:

[0136] The test data candidate search directory determination unit is used to determine the test data candidate search directory based on the test data location preference corresponding to the target test case;

[0137] The test data file identifier generation unit is used to generate a test data file identifier corresponding to the target test case based on the naming rules and annotation information of the target test case.

[0138] The test data file location unit is used to determine the test data file of the target test case in the test data candidate search directory based on the test data file identifier.

[0139] In one embodiment, the test data file identifier generation unit includes:

[0140] The class name retrieval sub-unit is used to obtain the class name and method name of the target test case;

[0141] The annotation parameter value extraction subunit is used to parse annotation information used to identify test data from the target test case and extract annotation parameter values;

[0142] The test data file identifier generation subunit is used to generate a test data file identifier corresponding to the target test case based on the class name, method name, and annotation parameter values, according to the naming rules of the target test case.

[0143] In one embodiment, the test data file location unit includes:

[0144] The first test data file location subunit is used to check whether there is a file corresponding to the test data file identifier in the test data candidate search directory. If it exists, the file is identified as the test data file of the target test case.

[0145] The second test data file location subunit is used to create a new test data file in the test data candidate search directory if the file corresponding to the test data file identifier does not exist, and to identify the new test data file as the test data file of the target test case. The file name of the new test data file is generated based on the method name of the target test case and the preset file extension. The content of the new test data file is generated based on the existing test case structure, the annotation information of the target test case, or the standard skeleton template.

[0146] In one embodiment, the test case location module 203 includes:

[0147] The target test data location preference determination unit is used to determine the target test data location preference corresponding to the target test data file in each test data location preference according to the storage path of the target test data file;

[0148] The candidate test case range determination unit is used to determine the range of candidate test cases in the test case set based on the location preference of the target test data.

[0149] The test case identifier generation unit is used to generate test case identifiers corresponding to the target test data file according to the naming rules of the target test data file;

[0150] The test case location unit is used to match the test cases corresponding to the target test data file within the candidate test case range, based on the test case identifier.

[0151] In one embodiment, the test case identifier generation unit includes:

[0152] The target filename acquisition subunit is used to obtain the target filename of the target test data file;

[0153] The first test case identifier generation subunit is used to generate a test case identifier corresponding to the target test data file based on the target file name and in accordance with the naming rules of the target test data file if the target file name conforms to the naming rules of the target test data file.

[0154] The second test case identifier generation subunit is used to parse the storage path of the target test data file if the target file name does not conform to the naming rules of the target test data file, extract the directory level field used to distinguish test cases, and generate a test case identifier corresponding to the target test data file based on the directory level field.

[0155] In one embodiment, this application also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the bidirectional location method for test cases and test data as described in any of the above embodiments.

[0156] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the bidirectional location method for test cases and test data as described in any of the above embodiments.

[0157] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the bidirectional localization method for test cases and test data of any of the above embodiments.

[0158] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0159] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0160] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only 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. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this document, "a," "an," "the," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. "Multiple" refers to at least two, such as 2, 3, 5, or 8, etc. "And / or" includes any and all combinations of the related listed items.

[0161] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0162] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A bidirectional positioning method for test cases and test data, characterized in that, The method includes: In response to the test case set loading completion instruction, the directory of each test case in the test case set is scanned to determine the test data location preference for each test case; Upon receiving a test data location instruction, the target test case corresponding to the test data location instruction in the test case set is determined, and the test data file of the target test case is located based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case. Upon receiving a test case location instruction, the target test data file corresponding to the test case location instruction is determined, and based on the storage path, naming rules, and location preferences of each test data file, the test case corresponding to the target test data file is located in the test case set.

2. The bidirectional positioning method for test cases and test data according to claim 1, characterized in that, The step of scanning the directory of each test case in the test case set and determining the test data location preference for each test case includes: Count the number of test data files associated with each test case in the directory of each test case in the test case set; For each test case, when the number of test data files associated with the test case is greater than a preset threshold, the test data location preference for the test case is determined to be stored in the same directory as the test case. When the number of test data files associated with the test case is less than or equal to the preset threshold, the test data location preference for the test case is determined to be uniformly stored in a preset test data directory.

3. The bidirectional positioning method for test cases and test data according to claim 1, characterized in that, The step of locating the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case, includes: Based on the test data location preferences corresponding to the target test cases, determine the candidate search directory for test data; Based on the naming rules and annotation information of the target test cases, generate test data file identifiers corresponding to the target test cases; In the test data candidate search directory, the test data file of the target test case is determined according to the test data file identifier.

4. The bidirectional positioning method for test cases and test data according to claim 3, characterized in that, The step of generating a test data file identifier corresponding to the target test case based on the naming rules and annotation information of the target test case includes: Obtain the class name and method name of the target test case; Parse the annotation information used to identify test data from the target test cases and extract the annotation parameter values; Based on the class name, the method name, and the annotation parameter value, a test data file identifier corresponding to the target test case is generated according to the naming rules of the target test case.

5. The bidirectional positioning method for test cases and test data according to claim 3, characterized in that, The step of determining the test data file of the target test case based on the test data file identifier in the test data candidate search directory includes: In the test data candidate search directory, check whether there is a file corresponding to the test data file identifier. If there is, determine the file as the test data file of the target test case. If the file corresponding to the test data file identifier does not exist, a new test data file is created in the test data candidate search directory, and the new test data file is identified as the test data file of the target test case. The file name of the new test data file is generated based on the method name of the target test case and the preset file extension. The content of the new test data file is generated based on the existing test case structure, the annotation information of the target test case, or the standard skeleton template.

6. The bidirectional positioning method for test cases and test data according to claim 1, characterized in that, The step of locating the test case corresponding to the target test data file in the test case set based on the storage path, naming rules, and location preferences of the target test data file includes: Based on the storage path of the target test data file, determine the target test data location preference corresponding to the target test data file among each of the test data location preferences; Based on the target test data location preference, a range of candidate test cases is determined in the test case set; Based on the naming rules of the target test data file, generate test case identifiers corresponding to the target test data file; Within the range of candidate test cases, test cases corresponding to the target test data file are matched according to the test case identifier.

7. The bidirectional positioning method for test cases and test data according to claim 6, characterized in that, The step of generating test case identifiers corresponding to the target test data file according to the naming rules of the target test data file includes: Obtain the target filename of the target test data file; If the target file name conforms to the naming rules of the target test data file, then based on the target file name, a test case identifier corresponding to the target test data file is generated according to the naming rules of the target test data file; If the target file name does not conform to the naming rules of the target test data file, then the storage path of the target test data file is parsed, the directory level field used to distinguish test cases is extracted, and a test case identifier corresponding to the target test data file is generated based on the directory level field.

8. A bidirectional positioning device for test cases and test data, characterized in that, The device includes: The test data location preference determination module is used to scan the directory of each test case in the test case set in response to the test case set loading completion instruction, and determine the test data location preference of each test case; The test data file location module is used to determine the target test case corresponding to the test data location instruction in the test case set when a test data location instruction is received, and locate the test data file of the target test case based on the test data location preference corresponding to the target test case, combined with the naming rules and annotation information of the target test case; The test case location module is used to determine the target test data file corresponding to the test case location instruction when a test case location instruction is received, and locate the test case corresponding to the target test data file in the test case set based on the storage path, naming rules and location preferences of the target test data file.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the bidirectional location method for test cases and test data as described in any one of claims 1 to 7.

10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the bidirectional location method for test cases and test data as described in any one of claims 1 to 7.

Images