A test case accurate selection method, device and equipment based on dependency collection

Abstract

The application discloses a kind of based on the accurate selection method, device and equipment of test case of dependence collection. Including: the baseline version of code repository is extracted in time, after being successively run after compiling construction, the dependence file path generated by running is collected, and reverse mapping table is generated;Code change patch is applied to baseline version to obtain temporary change version, the hash value of each compilation file is calculated after being executed respectively after compiling construction, baseline hash association list and change hash association list are generated, and the substantial difference file list is generated by comparing two hash association lists;Fine-grained splitting is carried out to compilation file, and the reverse mapping table is adapted and revised based on corresponding target dependence file path;According to each target dependence file path, the test case to be dispatched is screened out in reverse mapping table, and accurate test case set is formed by summarizing. The present application can accurately identify effective code changes, automatically match corresponding test cases, and greatly improve test efficiency and selection accuracy.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, and in particular to a method, apparatus, and device for accurately selecting test cases based on dependency collection. Background Technology

[0002] In the continuous integration process of large-scale system software such as chip compilers and operator libraries that adapt to multiple hardware architectures, automated testing needs to be run after each code change submission to ensure overall code quality and version stability. Currently, the industry commonly adopts the method of comparing source code differences and manually sorting out various dependency relationships to define the test execution scope and match corresponding test cases to carry out testing. This implementation method is also a relatively common testing implementation method in the current software version iteration process.

[0003] Traditional continuous integration testing only identifies changes at the source code level, failing to determine the extent of changes based on the actual state of the compiled files. It struggles to distinguish between substantial changes and insignificant, non-substantial changes, easily leading to a large number of repetitive and redundant tests. Furthermore, it lacks a method to uniformly collect dependency file paths and establish persistent reverse mapping relationships through process behavior monitoring. Dependency relationships rely on manual organization and maintenance, which is prone to omissions and errors. It also cannot adjust mapping relationships based on fine-grained differences in compiled files, ultimately resulting in a broad range of test cases with insufficient precision, significantly increasing testing resource consumption and reducing the overall efficiency of development and testing workflows. Summary of the Invention

[0004] Based on this, the present invention provides a method, apparatus and equipment for accurate selection of test cases based on dependency acquisition, so as to solve the problems of inaccurate change identification, inconvenient dependency management and low test selection accuracy in traditional continuous integration testing.

[0005] In a first aspect, embodiments of the present invention provide a method for accurately selecting test cases based on dependency collection, including:

[0006] According to the agreed time window, the complete project source code in the code repository is extracted as the baseline version. After compilation and building, all test cases in the baseline version are run in sequence. The process behavior monitoring tool is used to collect the dependency file paths generated by the execution of each test case, generate a reverse mapping table representing the mapping relationship between dependency file paths and test cases, and persist the data.

[0007] When the code repository receives a code change patch submission request, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, the corresponding baseline compiled file set and changed compiled file set are obtained.

[0008] Calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, generate the baseline hash association list and the modified hash association list. Compare the two hash association lists with the dependent file path as the matching benchmark, and generate a list of substantially different files based on the comparison results.

[0009] The compilation files in the list of substantially different files are split into multiple independent fine-grained compilation files according to the preset splitting dimensions. Based on the target dependency file paths corresponding to each fine-grained compilation file, the mapping relationships in the persistently stored reverse mapping table are adapted and revised.

[0010] Based on the paths of the dependent files of each target, test cases to be scheduled are selected from the adapted and revised reverse mapping table. The test cases to be scheduled are then aggregated to form a precise set of test cases corresponding to the code change patch, thus completing the precise selection of test cases.

[0011] Secondly, embodiments of the present invention also provide a device for precise selection of test cases based on dependency acquisition, comprising:

[0012] The mapping relationship construction module is used to periodically extract the complete project source code from the code repository as a baseline version according to the agreed time window. After compilation and construction, all test cases in the baseline version are run sequentially. The process behavior monitoring tool collects the dependency file paths generated by the execution of each test case, generates a reverse mapping table representing the mapping relationship between dependency file paths and test cases, and persists the data.

[0013] The version compilation module is used to apply the code change patch to the baseline version to obtain a temporary changed version when the code repository receives a code change patch submission request. After performing compilation and building on the baseline version and the temporary changed version respectively, the corresponding baseline compilation file set and change compilation file set are obtained.

[0014] The hash value calculation module is used to calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, it generates a baseline hash association list and a modified hash association list. The two hash association lists are compared with the dependent file path as the matching benchmark, and a list of substantially different files is generated based on the comparison result.

[0015] The fine-grained splitting module is used to perform fine-grained splitting of the compiled files in the list of substantially different files according to the preset splitting dimensions, resulting in multiple independent fine-grained compiled files. Based on the target dependency file paths corresponding to each fine-grained compiled file, the mapping relationship in the persistently stored reverse mapping table is adapted and revised.

[0016] The test case filtering module is used to filter out the test cases to be scheduled in the adapted and revised reverse mapping table according to the paths of each target dependency file, and summarize the test cases to be scheduled to form a precise set of test cases corresponding to the code change patch, thus completing the precise selection of test cases.

[0017] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0018] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute a method for precise selection of test cases based on dependency acquisition as described in any embodiment of the present invention.

[0019] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute a method for accurately selecting test cases based on dependency acquisition as described in any embodiment of the present invention.

[0020] Fifthly, embodiments of the present invention also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements a method for precise selection of test cases based on dependency acquisition as described in any embodiment of the present invention.

[0021] This invention, through automated collection of all dependency paths during test runs, establishes a standardized mapping relationship. Combined with compiled file hash comparison, it accurately identifies truly modified files and performs fine-grained decomposition and optimization of dependency matching logic on the compiled artifacts. This allows for the rapid selection of precise test cases that match code changes, significantly reducing invalid test tasks, saving test resources and manpower costs, and improving the accuracy and scientific rigor of test case selection. Simultaneously, it enables the orderly scheduling of targeted regression testing, providing reliable data support for code review and version release. This solves the problems of cumbersome dependency analysis, inaccurate change identification, and redundant test scope in traditional methods, effectively saving test resources and improving test efficiency and code quality control.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0024] Figure 1 This is a flowchart of a method for accurately selecting test cases based on dependency acquisition according to Embodiment 1 of the present invention;

[0025] Figure 2 This is a flowchart of another method for accurately selecting test cases based on dependency acquisition, provided in Embodiment 2 of the present invention;

[0026] Figure 3 This is a schematic diagram of a device for accurately selecting test cases based on dependency acquisition according to Embodiment 3 of the present invention;

[0027] Figure 4 This is a schematic diagram of the structure of an electronic device that implements a method for accurately selecting test cases based on dependency acquisition, according to an embodiment of the present invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] Example 1

[0031] Figure 1This is a flowchart illustrating a method for precise test case selection based on dependency collection, provided in Embodiment 1 of the present invention. This embodiment is applicable to continuous integration testing scenarios in the development of large-scale multi-architecture system software, where precise test case selection is achieved based on differences in compiled files. This method can be executed by a device for precise test case selection based on dependency collection. This device can be implemented in hardware and / or software and can be configured within a software development continuous integration management platform. Figure 1 As shown, the method includes:

[0032] S110. According to the agreed time window, extract the complete project source code from the code repository as the baseline version, compile and build it, and run all test cases in the baseline version in sequence. Use the process behavior monitoring tool to collect the dependency file paths generated by the execution of each test case, generate a reverse mapping table representing the mapping relationship between the dependency file paths and the test cases, and persist the data.

[0033] The agreed-upon time window is a pre-defined fixed execution cycle used to periodically update baseline project data, ensuring the timeliness of the baseline version. The baseline version refers to a complete source code project in the code repository that has not undergone any temporary modifications and is in a stable state. Process behavior monitoring tools refer to underlying monitoring programs used to capture file access, resource loading, and path call behavior during program runtime, providing full coverage of compile-time and runtime file call behavior. An example is the strace tool in a Linux environment. Dependency file paths refer to the storage addresses of compiled artifacts, configuration files, library files, and other resources that must be called, read, or loaded during the normal operation of test cases. The reverse mapping table uses the dependency file path as the primary key, binding all test cases that call that file, enabling quick location of test cases from the file. Persistent storage involves storing the mapping relationship data in a database or local persistent files, retaining the data even when the program is not running, and allowing for retrieval and reuse at any time.

[0034] In reality, test case execution relies not only on the source code but also on various resource files generated during compilation. Traditional static dependency statistics can only count source code dependencies and cannot cover runtime dynamic dependencies. Process monitoring can capture all real runtime dependencies, establishing complete relationships from the program's underlying runtime. In this embodiment, complete source code is retrieved at fixed intervals to build a stable baseline. After the overall compilation is completed and all test cases are run, all runtime dependency paths for each test case are captured synchronously. These are then organized into a reverse data table of file paths corresponding to test cases and permanently stored, completing the initial construction of comprehensive dependency data.

[0035] S120. When the code repository receives a code change patch submission request, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, the corresponding baseline compiled file set and changed compiled file set are obtained.

[0036] Code change patches refer to partial code modification packages submitted by developers, containing only modified code snippets and not the complete project source code. Temporary change versions are temporary project versions generated by merging and overlaying change patches onto the baseline version, awaiting verification. Version comparison must ensure complete uniformity of the compilation environment, compilation scripts, and compilation parameters. Local changes should be overlaid on a stable baseline to avoid comparison errors caused by environmental and compilation differences, ensuring fair comparison between the two sets of compiled outputs.

[0037] The system monitors code repository commit behavior in real time. After a code modification is committed, it merges the patch to generate a temporary project. The same compilation process is then performed on the baseline project and the modified project. All compiled output files of the two types of projects are collected separately to form two sets of comparable compiled file datasets.

[0038] S130. Calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, generate the baseline hash association list and the modified hash association list. Compare the two hash association lists with the dependent file path as the matching benchmark, and generate a list of substantially different files based on the comparison results.

[0039] A compiled file hash value is a unique characteristic value calculated from the complete file content using a hash encryption algorithm. Files with identical content will have identical hash values; any changes to the content will inevitably change the hash value, regardless of file name or storage location. The hash association list is a structured lookup table that binds the compiled file hash characteristics to their respective storage dependencies. Substantially different files refer to files whose compiled output content has undergone real changes, directly affecting the program's execution and functional logic. Non-substantial changes refer to actions such as modifying source code comments, formatting code, modifying disabled macro definitions, or adjusting idle code; these changes do not alter any compiled output content. Modifications to the source code text do not equate to changes in the program's actual execution logic; only changes to the compiled output will affect program execution. By comparing file hash values, we can directly penetrate the surface-level changes in the source code, accurately determine the actual valid changes to the program, and filter out invalid changes at the root.

[0040] The hash values ​​of the two sets of compiled files are calculated uniformly. After binding the paths, two comparison lists are generated. The files are compared item by item with the file paths as the alignment standard. Compiled files with inconsistent hash values ​​are filtered out, invalid modifications that change the source code but do not change the output are eliminated, and finally the files with substantial differences that truly affect the operation of the program are filtered out.

[0041] S140. Perform fine-grained splitting of the compilation files in the list of substantially different files according to the preset splitting dimensions to obtain multiple independent fine-grained compilation files. Based on the target dependency file paths corresponding to each fine-grained compilation file, adapt and revise the mapping relationships in the persistently stored reverse mapping table.

[0042] Predefined splitting dimensions refer to pre-defined file splitting standards, including division criteria such as functional modules, business layers, hardware architecture, and program units. Fine-grained compiled files are the smallest independent executable units obtained by splitting a large, integrated compiled file according to its function and architecture. Large software projects often integrate multiple architectures and modules into a single large library file; differences in overall performance can trigger numerous irrelevant tests. Splitting large files into the smallest independent units allows for precise targeting of local changes and narrows down dependency matching.

[0043] The different compilation files are split according to the established splitting rules to obtain independent sub-compilation units. Based on the new file dependency paths after splitting, the previously persistent reverse mapping relationship is updated and corrected to ensure that the dependency relationship is consistent with the actual file structure after splitting.

[0044] S150. Based on the paths of the dependent files of each target, select the test cases to be scheduled from the adapted and revised reverse mapping table, and summarize the test cases to be scheduled to form a set of accurate test cases corresponding to the code change patch, thus completing the accurate selection of test cases.

[0045] Test cases awaiting scheduling refer to test cases that have runtime dependencies on substantially different compiled files and need to participate in regression testing. Using the truly modified, finely segmented compiled files as the search entry point, and relying on pre-built and corrected dependency mappings, only test cases with direct runtime dependencies are matched, avoiding triggering unrelated full-scale tests, thus minimizing the test scope.

[0046] Using the fine-grained file paths of the differences as the query criteria, the corresponding bound test cases are retrieved from the revised reverse mapping table. All matching results are summarized and integrated to form a set of test cases specifically for the current code change patch, ultimately achieving fully automated and precise selection of test cases.

[0047] This invention, through automated collection of all dependency paths during test runs, establishes a standardized mapping relationship. Combined with compiled file hash comparison, it accurately identifies truly modified files and performs fine-grained decomposition and optimization of dependency matching logic on the compiled artifacts. This allows for the rapid selection of precise test cases that match code changes, significantly reducing invalid test tasks, saving test resources and manpower costs, and improving the accuracy and scientific rigor of test case selection. Simultaneously, it enables the orderly scheduling of targeted regression testing, providing reliable data support for code review and version release. This solves the problems of cumbersome dependency analysis, inaccurate change identification, and redundant test scope in traditional methods, effectively saving test resources and improving test efficiency and code quality control.

[0048] Optionally, a process behavior monitoring tool can be used to collect the paths of dependency files generated by the execution of each test case, and a reverse mapping table representing the mapping relationship between dependency file paths and test cases can be generated, which may include:

[0049] The process behavior monitoring tool captures all the dependency file paths accessed by each individual test case during its execution, and the dependency file paths are normalized and deduplicated to obtain a set of dependency file paths that uniquely correspond to each individual test case.

[0050] For each test case, establish the association between the test case and the corresponding set of dependent file paths, and build a forward mapping table with the test case as the index and the corresponding dependent file paths as the association.

[0051] The forward mapping table is reordered by key-value inversion to generate a reverse mapping table that uses each dependent file path as an index and associates all test cases that can access the corresponding dependent file path.

[0052] Process behavior monitoring tools rely on the system's underlying call listening capabilities to intercept file opening, reading, and loading operations initiated by test processes in real time. During the execution of a single test case, the same file may be read repeatedly, and system path writing conventions may result in format differences. Directly collecting raw data would lead to bloated data and chaotic relationships. By first accurately capturing all access behaviors, and then standardizing the format and removing duplicates, we can ensure that the dependency path data for each test case is concise, standardized, and free of redundancy.

[0053] A forward mapping table uses test cases as the primary key for retrieval and links them to all the dependent file paths required by that test case. It is a conventional and intuitive form of dependency record. Establishing relationships starting from the test execution entity aligns with the typical dependency management logic of developers. It allows for a direct query of which resource files any test case depends on, providing a foundational data source for subsequent inversion transformations.

[0054] Key-value inversion refers to swapping the index subject and the associated object in the mapping relationship; the reverse mapping table sets the dependency file path as the retrieval primary key, summarizes and binds all test cases that access the file at runtime, and realizes the reverse tracing of associated test cases from the file. The data structure of the existing forward mapping table is reorganized, the correspondence between the index and the associated object is swapped, and finally a reverse mapping table is generated that uses the dependency file path as the query basis and can quickly match all associated test cases, thus completing the finalization of the mapping relationship.

[0055] Furthermore, when the code repository receives a code change patch submission request, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, corresponding baseline compiled file sets and changed compiled file sets are obtained, which may include:

[0056] Monitor the code repository and capture code change patch commit requests;

[0057] While keeping the original code of the baseline version unchanged, the code change patch is merged into the baseline version to generate a temporary changed version;

[0058] A unified compilation configuration is used to perform compilation and build operations on the baseline version and the temporary modified version respectively;

[0059] The first type of compiled files, generated from the baseline version, constitute the baseline compiled file set, while the second type of compiled files, generated from the temporary modified version, constitute the modified compiled file set.

[0060] In this embodiment, the code repository's runtime status is continuously monitored. Once a developer pushes incremental code changes, the commit is immediately captured, and the subsequent version processing flow is initiated. The entire original code content of the established baseline version is preserved, and only the received incremental modification patches are merged and embedded into the baseline source code to create a temporary project version containing only the specified changes. A unified compilation configuration can include a complete set of fixed compilation rules, including compilation instructions, compilation parameters, dependency environment, and build scripts. The same set of fixed compilation rules and runtime environment are invoked to sequentially execute the complete compilation and build process on both the original baseline version and the temporary modified version after merging patches.

[0061] The first type of compiled files represents all binary files, library files, executable files, and other artifacts output after compiling the baseline version; the second type of compiled files represents all similar artifacts generated by compiling the temporary modified version. The compiled artifacts are categorized and grouped according to their version origin, and the two groups of artifacts are stored independently, providing a well-organized and complete comparison data source for subsequent file-by-file hash comparisons and identification of substantial changes.

[0062] Optionally, the hash value of each compiled file in the baseline compiled file set and the modified compiled file set are calculated separately. After establishing a mapping relationship between the hash values ​​and the dependent file paths, a baseline hash association list and a modified hash association list are generated, which may include:

[0063] Iterate through each Class 1 compilation file in the baseline compilation file set and calculate the hash value of each Class 1 compilation file one by one using a predefined hash function;

[0064] Bind the hash value of each first-class compilation file to its corresponding dependency file path, and generate a baseline hash association list after sorting and summarizing it according to a preset format.

[0065] Iterate through each second-type compilation file in the set of modified compilation files, and use a predefined hash function to calculate the hash value corresponding to each second-type compilation file;

[0066] Bind the hash value of each compiled file to its corresponding dependent file path, and then organize and summarize them according to the same preset format to generate a change hash association list.

[0067] The predefined hash function is a standard hash algorithm that is selected and used in advance and is not changed arbitrarily throughout the process to ensure consistent calculation. The first type of compiled files refers to various output files generated by compiling the baseline version. Using a fixed hash algorithm ensures that files with the same content will produce completely identical feature values, eliminating judgment errors caused by algorithm differences at the calculation level and achieving file content uniqueness verification. All compiled files within the baseline compiled file set are traversed sequentially, and the pre-defined hash calculation method is called to calculate the unique hash feature value for each compiled file. The hash value calculated for each baseline compiled file is bound one-to-one with its corresponding dependent storage path, and then organized and summarized according to a pre-defined unified format to finally form a standardized baseline hash association list.

[0068] The second type of compiled files refers to all output files compiled from the temporary change version after merging patches. A complete traversal of all compiled files within the change compiled file set is performed, using the same preset hash function as before to calculate the hash value of each compiled file on the change side. The hash values ​​of the change-side compiled files are then bound to their corresponding dependency file paths. The data is then strictly organized using the previously unified format, ultimately generating a change hash association list aligned with the baseline list format.

[0069] Example 2

[0070] Figure 2 This is a flowchart of another method for precise selection of test cases based on dependency acquisition provided in Embodiment 2 of the present invention. This embodiment is a refinement based on Embodiment 1, specifically as follows: Figure 2As shown, the method includes:

[0071] S210. According to the agreed time window, extract the complete project source code from the code repository as the baseline version, compile and build it, and run all test cases in the baseline version in sequence. Use the process behavior monitoring tool to collect the dependency file paths generated by the execution of each test case, generate a reverse mapping table representing the mapping relationship between dependency file paths and test cases, and persist the data.

[0072] S220. When the code repository receives a code change patch submission request, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, the corresponding baseline compiled file set and changed compiled file set are obtained.

[0073] S230. Calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependency file path, generate the baseline hash association list and the modification hash association list. Using the dependency file path as the matching benchmark, traverse all compiled files in the baseline hash association list and the modification hash association list, and compare the dependency file paths of each compiled file.

[0074] Within the project, files are located physically based on their actual storage paths. Using these paths as a matching standard, the system can accurately pinpoint source files in the same location in both the baseline and modified versions. By using the dependent file paths as a unified reference standard and sequentially traversing all entries in both the baseline hash association list and the modified hash association list, the system can verify the location information of compiled files on both sides one by one.

[0075] S240, identify the compiled files corresponding to the dependency file paths that only exist in the change hash association list as new files, identify the compiled files corresponding to the dependency file paths that only exist in the baseline hash association list as deleted files, and identify the compiled files corresponding to the dependency file paths that exist in both hash association lists as common files.

[0076] New files refer to compiled files that appear only in the changed version list and whose corresponding paths do not exist in the baseline version; deleted files refer to compiled files that exist only in the baseline list and whose corresponding paths no longer exist in the temporary changed version; shared files refer to compiled files that have the same dependency paths in both lists and whose locations have not changed. This embodiment first classifies files based on their existence status, distinguishing three basic change forms at the project compilation output level: addition, removal, and retention, thus completing the first layer of coarse-grained difference classification.

[0077] S250. For each common file, retrieve its hash value in the baseline hash association list and the change hash association list respectively, and define the common files with overlapping dependent file paths and consistent hash values ​​as non-substantial change files.

[0078] Non-substantial changes refer to files whose storage path has not changed and whose internal content has remained completely unchanged. These changes only involve adjustments to source code comments or modifications to idle code, and do not affect the compilation output, thus having no practical impact on functionality. In fact, identical paths only indicate that the file location has not changed; they cannot determine whether the internal content has been modified. Therefore, a second verification is performed using the uniqueness of hash values. If the content has not changed, the hash values ​​will be exactly the same, thereby eliminating invalid changes without practical significance. Any shared files with overlapping paths and identical hash values ​​are directly identified as non-substantial changes and are not included in subsequent processes as valid modified files.

[0079] S260. Combine the common files after removing non-substantial change files with the newly added and deleted files to form a list of substantively different files.

[0080] The list of materially changed files is a summary of all compiled files that have undergone real and effective changes that will affect program operation and test execution. Specifically, adding and deleting files will inevitably change the project's dependency structure, but inconsistent hashes in common files indicate that their internal content has been modified. All three types of files will affect the original test dependencies and must be included in the diff scope. The remaining modified files after removing non-materially changed files from the common files, along with the newly added and deleted compiled files identified earlier, are then uniformly summarized and integrated to form the complete list of materially changed files.

[0081] S270. Based on the preset file hierarchy and business function dimensions, each compiled file in the list of substantially different files is decomposed into units.

[0082] During implementation, the preset file hierarchy dimension can refer to the vertical division standard defined by the project directory hierarchy, compilation architecture hierarchy, and module hierarchy; the business function dimension can refer to the horizontal division standard defined by the specific functions implemented by the program, its service purpose, and the hardware architecture it adapts to. In large projects, integrated compilation files often aggregate multi-level and multi-category business functions, and a single overall file cannot accurately locate local modification points. Combining the decomposition based on both hierarchical and functional dimensions can align with the actual project architecture and business division logic, ensuring that the decomposition results conform to the actual usage logic of the project.

[0083] S280. Based on internal calls and dependency relationships, divide the split boundaries, and encapsulate the split units independently along the split boundaries to form several fine-grained compilation files that are independent of each other.

[0084] Internal calls and dependencies refer to the inherent linkages between various functional units within a compiled file, such as data calls, function references, and resource calls. The splitting boundary is a unit division boundary defined by the principle of no strong mutual dependencies and no overlapping calls. Fine-grained compiled files are the smallest compiled functional units that are decoupled from each other and can be run and called independently after splitting. By analyzing the internal calls and resource dependencies between the decomposed units, a reasonable splitting boundary is determined. Functional units are then divided along this boundary, and each divided unit is individually encapsulated and processed, ultimately generating a batch of independent, undependent fine-grained compiled files.

[0085] S290. Based on the target dependency file paths corresponding to each fine-grained compilation file, adapt and revise the mapping relationships in the persistently stored reverse mapping table.

[0086] S2100. Based on the paths of the dependent files of each target, select the test cases to be scheduled from the adapted and revised reverse mapping table, summarize the test cases to be scheduled to form a set of accurate test cases corresponding to the code change patch, and complete the accurate selection of test cases.

[0087] Optionally, after summarizing the test cases to be scheduled to form a precise set of test cases corresponding to the code change patch, and completing the precise selection of test cases, the process may further include:

[0088] Associate and bind precise test case sets with code change patches for different versions;

[0089] Based on the dependency hierarchy of the compiled files, the scheduling priority of the test cases to be scheduled in the precise test case set is sorted.

[0090] According to the sorting order, the corresponding test cases to be scheduled are scheduled in sequence, and targeted regression tests are performed on the code change patches;

[0091] The results of targeted regression tests are collected and used as the basis for determining the acceptance of subsequent code change patch merging and version release.

[0092] Since multiple batches of code change patches are submitted in parallel, and the test scopes corresponding to different changes are different, binding relationships can achieve one-to-one correspondence management, avoiding confusion and mismatch of test tasks between different patches. Version association binding refers to establishing a unique association between the currently selected exclusive test case group and the code change patch submitted this time, forming a fixed matching relationship, and locking the change content and test scope one by one.

[0093] Dependency hierarchy refers to the hierarchical relationship defined by the order in which compiled files are called, the order in which resources are loaded, and the hierarchy of modules. Scheduling priority refers to the order in which tests are executed based on the dependency order. Referring to the inherent dependency hierarchy between fine-grained compiled files, the determined test cases to be executed are rearranged, and different execution scheduling priorities are assigned. Test cases corresponding to the underlying basic compiled files need to be executed first, while upper-level business test cases are executed later. This hierarchical sorting aligns with the actual program execution logic.

[0094] Targeted regression testing is a specific verification method that runs only test cases that are dependent on the current code change, without executing all test tasks within the project. It skips irrelevant and redundant test tasks, focusing solely on functional verification related to the current code change. This ensures the effectiveness of verification while minimizing overall test time and reducing server resource consumption.

[0095] Test execution results can include various runtime status data such as successful test case execution, execution failure, exception errors, and functional verification failures. Merge admission refers to the review and admission conditions for code change patches to be officially merged into the main code repository. Using automated test results as an objective and quantitative review standard to replace subjective human judgment can not only intercept code changes with functional defects in advance, but also standardize the version release process and control the overall code quality from the process level.

[0096] Example 3

[0097] Figure 3 This is a schematic diagram of a device for accurately selecting test cases based on dependency acquisition, provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes:

[0098] The mapping relationship construction module 310 is used to periodically extract the complete project source code in the code repository as a baseline version according to the agreed time window. After compilation and construction, all test cases in the baseline version are run sequentially. The process behavior monitoring tool collects the dependency file paths generated by the execution of each test case, generates a reverse mapping table representing the mapping relationship between the dependency file paths and the test cases, and persists the data.

[0099] Version compilation module 320 is used to apply the code change patch to the baseline version to obtain a temporary changed version when the code repository receives a code change patch submission request. After performing compilation and building on the baseline version and the temporary changed version respectively, the corresponding baseline compilation file set and change compilation file set are obtained.

[0100] The hash value calculation module 330 is used to calculate the hash value of each compiled file in the baseline compiled file set and the changed compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, it generates a baseline hash association list and a changed hash association list. It compares the two hash association lists with the dependent file path as the matching benchmark and generates a list of substantially different files based on the comparison result.

[0101] The fine-grained splitting module 340 is used to perform fine-grained splitting of the compilation files in the list of substantially different files according to the preset splitting dimensions, to obtain multiple independent fine-grained compilation files, and to adapt and revise the mapping relationship in the persistently stored reverse mapping table based on the target dependency file path corresponding to each fine-grained compilation file.

[0102] The test case filtering module 350 is used to filter out the test cases to be scheduled in the adapted and revised reverse mapping table according to the path of each target dependency file, and summarize the test cases to be scheduled to form a precise test case set corresponding to the code change patch, thus completing the precise selection of test cases.

[0103] This invention, through automated collection of all dependency paths during test runs, establishes a standardized mapping relationship. Combined with compiled file hash comparison, it accurately identifies truly modified files and performs fine-grained decomposition and optimization of dependency matching logic on the compiled artifacts. This allows for the rapid selection of precise test cases that match code changes, significantly reducing invalid test tasks, saving test resources and manpower costs, and improving the accuracy and scientific rigor of test case selection. Simultaneously, it enables the orderly scheduling of targeted regression testing, providing reliable data support for code review and version release. This solves the problems of cumbersome dependency analysis, inaccurate change identification, and redundant test scope in traditional methods, effectively saving test resources and improving test efficiency and code quality control.

[0104] Optionally, based on the above embodiments, the mapping relationship construction module 310 may include:

[0105] The dependency file path collection unit is used to capture all dependency file paths accessed by each single test case during the execution of the process behavior monitoring tool, and to perform normalization and deduplication processing on the dependency file paths to obtain a set of dependency file paths that uniquely correspond to each single test case.

[0106] The forward mapping table construction unit is used to establish the association between each test case and the corresponding set of dependent file paths, and to build a forward mapping table with the test case as the index and the corresponding dependent file paths as the association.

[0107] The reverse mapping table construction unit is used to perform key-value inversion association arrangement on the forward mapping table to generate a reverse mapping table indexed by each dependent file path and associated with all test cases that can access the corresponding dependent file path.

[0108] Optionally, based on the above embodiments, the version compilation module 320 may include:

[0109] The request monitoring unit is used to monitor the code repository and capture code change patch submission requests;

[0110] The temporary change version generation unit is used to merge code change patches into the baseline version and generate a temporary change version while keeping the original code of the baseline version unchanged.

[0111] The compilation and build unit is used to perform compilation and build on the baseline version and the temporary modified version respectively using a unified compilation configuration;

[0112] The compilation file set building unit is used to collect the first type of compilation files output by the baseline version to form the baseline compilation file set, and to collect the second type of compilation files output by the temporary change version to form the change compilation file set.

[0113] Optionally, based on the above embodiments, the hash value calculation module 330 may include:

[0114] The first hash value calculation unit is used to calculate the hash value of each first-class compilation file in the baseline compilation file set by traversing it and using a predefined hash function to calculate the hash value of each first-class compilation file one by one.

[0115] The baseline hash association list generation unit is used to bind the hash value of each first-type compiled file to its corresponding dependent file path, and generate the baseline hash association list after sorting and summarizing it according to a preset regular format.

[0116] The second hash value calculation unit is used to traverse each second type of compilation file in the modified compilation file set and calculate the hash value corresponding to each second type of compilation file one by one using a predefined hash function.

[0117] The change hash association list generation unit is used to bind the hash value of each compiled file to its corresponding dependency file path, and generate a change hash association list after organizing and summarizing them in the same preset format.

[0118] Optionally, based on the above embodiments, the hash value calculation module 330 may include:

[0119] The dependency file path comparison unit is used to traverse all compiled files in the baseline hash association list and the change hash association list based on the dependency file path, and compare the dependency file paths of each compiled file.

[0120] The file identification unit is used to identify the compiled files corresponding to the dependent file paths that only exist in the change hash association list as new files, the compiled files corresponding to the dependent file paths that only exist in the baseline hash association list as deleted files, and the compiled files corresponding to the dependent file paths that exist in both hash association lists as shared files.

[0121] The non-substantial change identification unit is used to retrieve the hash value of each common file in the baseline hash association list and the change hash association list, and define common files with overlapping dependent file paths and consistent hash values ​​as non-substantial change files.

[0122] The Non-Substantial Change Removal Unit is used to combine the common files after removing non-substantial change files with the newly added and deleted files to form a list of substantial difference files.

[0123] Optionally, based on the above embodiments, the fine-grained segmentation module 340 may include:

[0124] The compilation file decomposition unit is used to decompose each compilation file in the list of substantially different files according to the preset file hierarchy and business function dimensions.

[0125] Based on internal calls and dependency relationships, the split boundaries are defined, and the split units are independently encapsulated along the split boundaries to form several fine-grained compilation files that are independent of each other.

[0126] Optionally, based on the above embodiments, it may also include: a regression testing unit, used to form a precise test case set corresponding to the code change patch by summarizing the test cases to be scheduled, and after completing the precise selection of test cases, to bind the precise test case set with the code change patch for version association;

[0127] Based on the dependency hierarchy of the compiled files, the scheduling priority of the test cases to be scheduled in the precise test case set is sorted.

[0128] According to the sorting order, the corresponding test cases to be scheduled are scheduled in sequence, and targeted regression tests are performed on the code change patches;

[0129] The results of targeted regression tests are collected and used as the basis for determining the acceptance of subsequent code change patch merging and version release.

[0130] The test case selection device based on dependency collection provided in this embodiment of the invention can execute the test case selection method based on dependency collection provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0131] Example 4

[0132] Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0133] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0134] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0135] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a dependency-based test case selection method.

[0136] That is: according to the agreed time window, the complete project source code in the code repository is extracted as the baseline version, and after compilation and building, all test cases in the baseline version are run in sequence. The process behavior monitoring tool is used to collect the dependency file paths generated by the execution of each test case, generate a reverse mapping table representing the mapping relationship between dependency file paths and test cases, and persist it.

[0137] When the code repository receives a code change patch submission request, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, the corresponding baseline compiled file set and changed compiled file set are obtained.

[0138] Calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, generate the baseline hash association list and the modified hash association list. Compare the two hash association lists with the dependent file path as the matching benchmark, and generate a list of substantially different files based on the comparison results.

[0139] The compilation files in the list of substantially different files are split into multiple independent fine-grained compilation files according to the preset splitting dimensions. Based on the target dependency file paths corresponding to each fine-grained compilation file, the mapping relationships in the persistently stored reverse mapping table are adapted and revised.

[0140] Based on the paths of the dependent files of each target, test cases to be scheduled are selected from the adapted and revised reverse mapping table. The test cases to be scheduled are then aggregated to form a precise set of test cases corresponding to the code change patch, thus completing the precise selection of test cases.

[0141] In some embodiments, a method for precise test case selection based on dependency sampling can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for precise test case selection based on dependency sampling described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform a method for precise test case selection based on dependency sampling by any other suitable means (e.g., by means of firmware).

[0142] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0143] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0144] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0145] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0146] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0147] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0148] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0149] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for accurately selecting test cases based on dependency collection, characterized in that, include: According to the agreed time window, the complete project source code in the code repository is extracted as the baseline version. After compilation and building, all test cases in the baseline version are run in sequence. The process behavior monitoring tool is used to collect the dependency file paths generated by the execution of each test case, generate a reverse mapping table representing the mapping relationship between dependency file paths and test cases, and persist the data. When the code repository receives a code change patch submission request, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, the corresponding baseline compiled file set and changed compiled file set are obtained. Calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, generate the baseline hash association list and the modified hash association list. Compare the two hash association lists with the dependent file path as the matching benchmark, and generate a list of substantially different files based on the comparison results. The compilation files in the list of substantially different files are split into multiple independent fine-grained compilation files according to the preset splitting dimensions. Based on the target dependency file paths corresponding to each fine-grained compilation file, the mapping relationships in the persistently stored reverse mapping table are adapted and revised. Based on the paths of the dependent files of each target, test cases to be scheduled are selected from the adapted and revised reverse mapping table. The test cases to be scheduled are then aggregated to form a precise set of test cases corresponding to the code change patch, thus completing the precise selection of test cases.

2. The method according to claim 1, characterized in that, The process behavior monitoring tool collects the dependency file paths generated by each test case execution, and generates a reverse mapping table representing the mapping relationship between dependency file paths and test cases, including: The process behavior monitoring tool captures all the dependency file paths accessed by each individual test case during its execution, and the dependency file paths are normalized and deduplicated to obtain a set of dependency file paths that uniquely correspond to each individual test case. For each test case, establish the association between the test case and the corresponding set of dependent file paths, and construct a forward mapping table with the test case as the index and associated with the corresponding dependent file paths; The forward mapping table is reordered by key-value inversion to generate a reverse mapping table that uses each dependent file path as an index and associates all test cases that can access the corresponding dependent file path.

3. The method according to claim 1, characterized in that, When a code change patch submission request is detected in the code repository, the code change patch is applied to the baseline version to obtain a temporary changed version. After compiling and building the baseline version and the temporary changed version respectively, the corresponding baseline compiled file set and changed compiled file set are obtained, including: Monitor the code repository and capture code change patch commit requests; While keeping the original code of the baseline version unchanged, the code change patch is merged into the baseline version to generate a temporary changed version; A unified compilation configuration is used to perform compilation and build operations on the baseline version and the temporary modified version respectively; The first type of compiled files, generated from the baseline version, constitute the baseline compiled file set, while the second type of compiled files, generated from the temporary modified version, constitute the modified compiled file set.

4. The method according to claim 3, characterized in that, Calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash values ​​and the dependent file paths, generate a baseline hash association list and a modified hash association list, including: Iterate through each Class 1 compilation file in the baseline compilation file set and calculate the hash value of each Class 1 compilation file one by one using a predefined hash function; Bind the hash value of each first-class compilation file to its corresponding dependency file path, and generate a baseline hash association list after sorting and summarizing it according to a preset format. Iterate through each second-type compilation file in the set of modified compilation files, and use a predefined hash function to calculate the hash value corresponding to each second-type compilation file; Bind the hash value of each compiled file to its corresponding dependent file path, and then organize and summarize them according to the same preset format to generate a change hash association list.

5. The method according to claim 1, characterized in that, Using the dependent file paths as a matching benchmark, compare the two hash association lists, and generate a list of substantially different files based on the comparison results, including: Using the dependency file path as the matching benchmark, traverse all compiled files in the baseline hash association list and the change hash association list, and compare the dependency file paths of each compiled file. Compiled files corresponding to dependency file paths that only exist in the changed hash association list are identified as newly added files; compiled files corresponding to dependency file paths that only exist in the baseline hash association list are identified as deleted files; and compiled files corresponding to dependency file paths that exist in both hash association lists are identified as shared files. For each shared file, retrieve its hash value in the baseline hash association list and the change hash association list respectively. Shared files with overlapping dependent file paths and the same hash value are defined as non-substantial change files. The common files, after removing non-substantial change files, along with the newly added and deleted files, are combined to form a list of substantively different files.

6. The method according to claim 1, characterized in that, The compiled files in the list of substantially different files are split into multiple independent, fine-grained compiled files according to a preset splitting dimension, including: Based on the preset file hierarchy and business function dimensions, each compiled file in the list of substantially different files is decomposed into a unit; Based on internal calls and dependency relationships, the split boundaries are defined, and the split units are independently encapsulated along the split boundaries to form several fine-grained compilation files that are independent of each other.

7. The method according to claim 1, characterized in that, After compiling the test cases to be scheduled into a precise set of test cases corresponding to the code change patch, and completing the precise selection of test cases, the process also includes: Associate and bind precise test case sets with code change patches for different versions; Based on the dependency hierarchy of the compiled files, the scheduling priority of the test cases to be scheduled in the precise test case set is sorted. According to the sorting order, the corresponding test cases to be scheduled are scheduled in sequence, and targeted regression tests are performed on the code change patches; The results of targeted regression tests are collected and used as the basis for determining the acceptance of subsequent code change patch merging and version release.

8. A device for precise selection of test cases based on dependency acquisition, characterized in that, The device includes: The mapping relationship construction module is used to periodically extract the complete project source code from the code repository as a baseline version according to the agreed time window. After compilation and construction, all test cases in the baseline version are run sequentially. The process behavior monitoring tool collects the dependency file paths generated by the execution of each test case, generates a reverse mapping table representing the mapping relationship between dependency file paths and test cases, and persists the data. The version compilation module is used to apply the code change patch to the baseline version to obtain a temporary changed version when the code repository receives a code change patch submission request. After performing compilation and building on the baseline version and the temporary changed version respectively, the corresponding baseline compilation file set and change compilation file set are obtained. The hash value calculation module is used to calculate the hash value of each compiled file in the baseline compiled file set and the modified compiled file set respectively. After establishing a mapping relationship between the hash value and the dependent file path, it generates a baseline hash association list and a modified hash association list. The two hash association lists are compared with the dependent file path as the matching benchmark, and a list of substantially different files is generated based on the comparison result. The fine-grained splitting module is used to perform fine-grained splitting of the compiled files in the list of substantially different files according to the preset splitting dimensions, resulting in multiple independent fine-grained compiled files. Based on the target dependency file paths corresponding to each fine-grained compiled file, the mapping relationship in the persistently stored reverse mapping table is adapted and revised. The test case filtering module is used to filter out the test cases to be scheduled in the adapted and revised reverse mapping table according to the paths of each target dependency file, and summarize the test cases to be scheduled to form a precise set of test cases corresponding to the code change patch, thus completing the precise selection of test cases.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a method for precise selection of test cases based on dependency acquisition as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the method for precise selection of test cases based on dependency acquisition as described in any one of claims 1-7.

Images