Chip testing method, electronic device, storage medium, and program

Abstract

Embodiments of the present application disclose a chip testing method, electronic equipment, storage medium and program, wherein the method comprises: obtaining configuration information of a target chip and a specified test case set input by a target user; filtering the specified test case set according to the configuration information of the target chip to generate a to-be-executed test case set of the target chip; executing the to-be-executed test case set by using each test execution thread to obtain a test output result of each to-be-executed test case in the to-be-executed test case set; and classifying the test output result of each to-be-executed test case by using a result submission thread and submitting the test output result to a test board server in batches. The technical solution of the embodiments of the present application can optimize the chip automatic testing process, significantly improve the overall execution efficiency and task operation reliability of the test, and effectively reduce the test operation and configuration management cost.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of chip testing, and in particular to a chip testing method, electronic device, storage medium and program. Background Technology

[0002] With the rapid development of artificial intelligence technology, dedicated AI acceleration chips such as GPUs (Graphics Processing Units), NPUs (Neural Processing Units), and TPUs (Tensor Processing Units) have become the core hardware infrastructure for deep learning training and inference. AI chip software stacks are complex, and AI chip test cases range in the thousands to tens of thousands, requiring compatibility with multiple chip models and physical devices of various specifications. This places extremely high demands on the scheduling, adaptation, and result processing capabilities of automated testing frameworks.

[0003] Existing test-driven tools can automatically discover test cases, execute them in batches, and report results to the test dashboard in a unified manner, and are widely used in automated testing. However, in the large-scale professional testing scenario of AI chips, the architecture and scheduling mechanism of existing test-driven tools have inherent defects and cannot meet the actual business needs: (1) The serial logic of submitting results after all tests are completed not only lengthens the test cycle, but also makes it easy to lose the completed test results in case of sudden interruption, resulting in low reliability and efficiency; (2) It does not have the ability to perceive the hardware environment, and cannot select unsuitable test cases and dynamically adjust test parameters according to the chip model, resulting in high manual maintenance costs; (3) It can only report test results in general terms and cannot classify and collect fault types, which increases the difficulty of fault location and troubleshooting and is difficult to adapt to the testing needs of AI chips. Summary of the Invention

[0004] This invention provides a chip testing method, apparatus, electronic device, storage medium, and program, which can optimize the automated chip testing process, significantly improve the overall testing execution efficiency and task operation reliability, and effectively reduce the testing operation and maintenance and configuration management costs.

[0005] According to one aspect of the present invention, a chip testing method is provided, comprising: Obtain the configuration information of the target chip and the set of specified test cases input by the target user; The specified test case set is filtered based on the configuration information of the target chip to generate a set of test cases to be executed for the target chip; The set of test cases to be executed is executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed; The test output results of each test case to be executed are classified by the result submission thread and submitted in batches to the test dashboard server.

[0006] According to another aspect of the present invention, a chip testing apparatus is provided, comprising: The data acquisition module is used to acquire the configuration information of the target chip and the set of specified test cases input by the target user; The test case set generation module is used to filter the specified test case set according to the configuration information of the target chip and generate the test case set to be executed for the target chip. The test output module is used to execute the set of test cases to be executed using each test execution thread, and obtain the test output results of each test case to be executed in the set of test cases to be executed; The test output result classification and submission module is used to classify the test output results of each test case to be executed using the result submission thread, and submit them in batches to the test dashboard server.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the chip testing method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the chip testing method according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the chip testing method described in any embodiment of the present invention.

[0010] This invention, through obtaining the configuration information of the target chip and a specified set of test cases input by the target user, filters the specified set of test cases based on the target chip's configuration information to generate a set of test cases to be executed for the target chip. After generating the set of test cases to be executed, each test execution thread executes the set of test cases to obtain the test output results of each test case in the set. Furthermore, a result submission thread categorizes the test output results of each test case to be executed and submits them in batches to a test dashboard server. The above solution solves the technical drawbacks of existing chip testing methods, such as low testing efficiency, high configuration and maintenance costs, and difficulties in fault location and troubleshooting. It can optimize the automated chip testing process, significantly improve the overall test execution efficiency and task reliability, and effectively reduce test operation and maintenance and configuration management costs.

[0011] 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

[0012] 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.

[0013] Figure 1 This is a flowchart of a chip testing method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a chip testing method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the architecture of a target testing system provided in Embodiment 2 of the present invention; Figure 4 This is a schematic diagram of a chip testing device provided in Embodiment 3 of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0014] 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.

[0015] It should be noted that the terms "first," "second," and "target," 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 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 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.

[0016] Example 1 Figure 1 This is a flowchart of a chip testing method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where chip test output results are categorized and submitted in batches. This method can be executed by a chip testing device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. This electronic device can be a terminal device or a server device, as long as it can execute the chip testing method. The present invention does not limit the specific type of electronic device. Correspondingly, as... Figure 1 As shown, the method includes the following operations: S110. Obtain the configuration information of the target chip and the set of specified test cases input by the target user.

[0017] The target chip can be the chip to be tested. For example, the target chip may include, but is not limited to, GPUs, NPUs, and TPUs; this embodiment of the invention does not limit the specific type of target chip. The configuration information can be a set of various underlying parameters and functional configurations set for the target chip. For example, the configuration information may include, but is not limited to, the target chip's manufacturer number, device number, and supported functions; this embodiment of the invention does not limit the specific content included in the configuration information. The target user can be the user testing the target chip. The specified test case set can be a set of test cases input by the target user for the target chip.

[0018] During the test initiation phase, the target test system can obtain the target chip's configuration information via PCIe (Peripheral Component Interconnect Express) bus scan commands. Simultaneously, it can acquire a set of specified test cases input by the target user using three command-line parameters: regular expressions, tag expressions, or test case list files. In essence, the target test system is the system that performs the testing on the target chip.

[0019] S120. Based on the configuration information of the target chip, the specified test case set is filtered to generate a test case set to be executed for the target chip.

[0020] The set of test cases to be executed can be a set of test cases applicable to testing the target chip.

[0021] Accordingly, after obtaining the configuration information of the target chip and the specified test case set input by the target user, the model of the target chip can be determined by matching the manufacturer number and device number in the target chip's configuration information with a chip model mapping table. Furthermore, the specified test case set can be filtered based on the target chip's model, thereby obtaining a set of test cases to be executed for the target chip.

[0022] S130. Execute the set of test cases to be executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed.

[0023] The test execution thread can be a thread used to perform tests on the target chip. The test output can be the execution result produced by each test execution thread after running the test cases on the target chip.

[0024] Accordingly, after generating the set of test cases to be executed for the target chip, the target testing system can create multiple test execution threads. These threads can then execute the set of test cases in parallel, thereby obtaining the test output results for each test case in the set. S140. Use the result submission thread to classify the test output results of each test case to be executed and submit them in batches to the test dashboard server.

[0025] The result submission thread can be a thread used to submit test output results. The test dashboard server can be a server used to display test output results and distribute them to downstream platforms.

[0026] The target testing system can simultaneously create a result submission thread when creating a test execution thread. The result submission thread can classify and process multiple test outputs from each test execution thread, and submit them in batches to different sub-projects on the test dashboard server, without waiting for all test cases to be executed before submitting them all at once.

[0027] Therefore, the chip testing method provided in this invention generates a set of dedicated test cases adapted to the target chip based on the chip's configuration information, enabling intelligent screening of test cases and effectively reducing the configuration management cost of chip testing. Simultaneously, this invention achieves parallel processing of test case execution and test result reporting through the collaborative work of the test execution thread and the result submission thread, significantly improving test throughput. Furthermore, the result submission thread can classify and organize test output results, categorizing and reporting various test output results separately, thereby optimizing the automated chip testing process and significantly improving overall test execution efficiency and task reliability.

[0028] This invention, through obtaining the configuration information of the target chip and a specified set of test cases input by the target user, filters the specified set of test cases based on the target chip's configuration information to generate a set of test cases to be executed for the target chip. After generating the set of test cases to be executed, each test execution thread executes the set of test cases to obtain the test output results of each test case in the set. Furthermore, a result submission thread categorizes the test output results of each test case to be executed and submits them in batches to a test dashboard server. The above solution solves the technical drawbacks of existing chip testing methods, such as low testing efficiency, high configuration and maintenance costs, and difficulties in fault location and troubleshooting. It can optimize the automated chip testing process, significantly improve the overall test execution efficiency and task reliability, and effectively reduce test operation and maintenance and configuration management costs.

[0029] Example 2 Figure 2 This is a flowchart of a chip testing method provided in Embodiment 2 of the present invention. This embodiment is a specific embodiment based on the above embodiment. In this embodiment, a specific optional implementation method is given, which uses a result submission thread to classify the test output results of each test case to be executed and submit them in batches to the test dashboard server. Correspondingly, as Figure 2 As shown, the method in this embodiment may include: S210. Obtain the configuration information of the target chip and the set of specified test cases input by the target user.

[0030] S220. Based on the configuration information of the target chip, the specified test case set is filtered to generate a test case set to be executed for the target chip.

[0031] In an optional embodiment of the present invention, the step of filtering the specified test case set according to the configuration information of the target chip to generate a set of test cases to be executed for the target chip may include: parsing the test description files of each specified test case in the specified test case set to determine the compatible chip identifier and compatible test function of each specified test case; matching the configuration information of the target chip with the compatible chip identifier of each specified test case to obtain a first set of disabled test cases for the target chip; parsing the hardware feature configuration file of the target chip to determine the dedicated hardware functions of the target chip; matching the dedicated hardware functions of the target chip with the compatible test functions of each specified test case to obtain a second set of disabled test cases for the target chip; and determining the set of test cases to be executed for the target chip based on the specified test case set, the first set of disabled test cases, and the second set of disabled test cases.

[0032] The test description file can be a configuration file that standardizes and defines information related to each specified test case. The compatible chip identifier can be the identification information of the chip to which the test case is adapted. The compatible test function can be the specific function that the test case can adapt to, cover, and be used to detect the target chip's capabilities. The first disabled test case set can be test cases from the specified test case set that do not match the target chip's model. The dedicated hardware function can be a specific function possessed by the target chip. The second disabled test case set can be test cases from the specified test case set that do not match the target chip's dedicated hardware function.

[0033] Figure 3 This is a schematic diagram of the architecture of a target testing system provided in Embodiment 2 of the present invention. In a specific example, such as Figure 3 As shown, the target testing system can include a test orchestration and scheduling layer, a multi-threaded execution and submission layer, a pluggable extension plugin layer, and a multi-platform result aggregation and distribution layer. The test orchestration and scheduling layer is responsible for hardware awareness, test case selection, and environment configuration; the multi-threaded execution and submission layer decouples test execution and result submission into independent parallel pipelines using a producer-consumer pattern; the pluggable extension plugin layer supports extending the framework's functionality without modifying the core logic through a lifecycle hook mechanism; and the multi-platform result aggregation and distribution layer is responsible for synchronously distributing test output results to multiple downstream systems.

[0034] Specifically, the test orchestration and scheduling layer of the target test system can parse the test description files of each specified test case in a given test case set to determine the compatible chip identifier and compatible test function for each specified test case. Simultaneously, the target chip model can be determined through its configuration information. Further, the target chip model can be matched with the compatible chip identifiers of each specified test case to obtain a first set of disabled test cases that do not match the target chip model. At the same time, the hardware characteristic configuration file of the target chip can be parsed to determine its unique hardware functions. Further, the unique hardware functions of the target chip can be matched with the compatible test functions of each specified test case to obtain a second set of disabled test cases that do not match the unique hardware functions of the target chip. Based on this, the specified test case set input by the target user can be filtered according to the first and second sets of disabled test cases, thereby generating a set of test cases to be executed for the target chip.

[0035] Understandably, the more chips there are, the more intense the competition for resources among them becomes. Therefore, the target testing system can count the total number of chips on the current machine and then dynamically adjust the timeout threshold of each test case to be executed based on the total number of chips, thereby avoiding false timeouts caused by resource contention.

[0036] The above solution leverages the PCIe bus device enumeration mechanism to automatically identify the chip model and quantity. Combined with the tag attributes of the test cases to be executed and the hardware characteristic configuration file of the target chip, it achieves automatic trimming of the test case set and dynamic adjustment of timeout thresholds. Simultaneously, it enables the same set of test code and configuration files to run adaptively on different chip devices, eliminating the need to maintain separate, dedicated test configurations for various hardware devices.

[0037] S230. Execute the set of test cases to be executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed.

[0038] In an optional embodiment of the present invention, the step of using each test execution thread to execute the set of test cases to be executed and obtaining the test output results of each test case to be executed in the set of test cases to be executed may include: obtaining the parallelism parameter input by the target user; creating multiple test execution threads and a result submission thread according to the parallelism parameter input by the target user; using each test execution thread to obtain the test case identifier of the target test case to be executed corresponding to each test execution thread from the set of test cases to be executed; using the test execution thread to construct a test command line according to the test case identifier of the target test case to be executed, and executing the test command line to obtain the test output results of the target test case to be executed; encapsulating the associated attribute information of the test output results of the target test case to be executed into a result node and writing it into a result message queue.

[0039] The parallelism parameter can be the number of test execution threads that can run in parallel, as set by the target user. The target test cases to be executed can be the test cases corresponding to each test execution thread. The test case identifier can be an identifier used to uniquely distinguish the test cases to be executed. The test command line can be the command line used to specify the test cases to be executed. The result node can be an encapsulation unit used to encapsulate a single test output result. The result message queue can be a message cache queue used to store the result nodes corresponding to each test output result.

[0040] During the test initiation phase, the multi-threaded execution and submission layer of the target test system can obtain the parallelism parameters input by the target user and create multiple test execution threads and one result submission thread based on these parameters. For example, assuming the parallelism parameter is N, N test execution threads can be created. Simultaneously, each test execution thread can be configured with an independent working directory. This working directory includes an independent copy of the test description file and data storage space, ensuring that multi-threaded execution does not interfere with each other.

[0041] Furthermore, each test execution thread can use locking to retrieve target test cases from the shared global list of test cases, ensuring that each test case is assigned to only a single test execution thread. After retrieving the target test case, the test execution thread can construct a test command line based on its test case identifier to specify that each thread should only execute the target test case corresponding to that thread. The test command line can also configure the size limit and output format of the test output results. After each test execution thread executes its corresponding target test case using the test command line, it can output the test output results of the target test case. Once the target test case has been executed, the corresponding test execution thread can encapsulate the XML (Extensible Markup Language) file path of the target test case's test output results, the test case identifier, and the execution status into a result node, and push this result node to a thread-safe result message queue.

[0042] Optionally, before and after the execution of each test case, system kernel log snapshots can be collected and saved separately. The saved log snapshots can be used for subsequent backtracking and troubleshooting to accurately locate hardware errors and the causes of various anomalies during the test process.

[0043] Optionally, if a test case fails to execute, the target test system can reset the target chip using the PCIe device hot reload mechanism, restoring it to a normal operating state. Furthermore, the system can poll and iterate through the target chip's device status file, and only schedule the next test case to be executed after confirming that all nodes of the target chip have returned to normal operation. If the target chip still has not recovered after exceeding the preset maximum number of waits, an error log can be recorded and saved. This automatic recovery mechanism avoids the problem of a large number of subsequent test cases failing due to hardware failure, thereby improving the proportion of effective results and equipment utilization during long-term testing.

[0044] S240. Determine whether the test output submission conditions are met. If they are met, execute S250; otherwise, return to execute S230.

[0045] Specifically, the result submission thread continuously monitors the result message queue. If it determines that the number of result nodes in the message queue exceeds a preset node threshold, or that the queuing interval for result nodes exceeds a preset waiting threshold, it determines that the test output submission conditions are met. The preset node threshold can be a pre-defined threshold for the number of result nodes. The preset waiting threshold can be a pre-defined waiting duration. If the queuing interval for result nodes exceeds the preset waiting threshold, it indicates that the current test process has ended.

[0046] Optionally, after all test execution threads have completed their execution, a termination flag can be pushed into the result message queue. Upon detecting the termination flag, the result submission thread can submit all remaining test outputs in the result message queue and then exit execution. After the result submission thread finishes, the main thread can compile and output the final test summary report.

[0047] S250. Perform feature matching on the test output results of each of the test cases to be executed to obtain the test classification results of each of the test cases to be executed.

[0048] The test classification result can be the classification result obtained by classifying the test output results of each test case to be executed according to preset rules.

[0049] Accordingly, after determining that the conditions for submitting test output results are met, feature matching operations can be performed on the test output results of each test case to be executed. Based on the matching results, the test output results can be classified and divided, thereby obtaining the test classification results corresponding to each test case to be executed.

[0050] In an optional embodiment of the present invention, the step of performing feature matching on the test output results of each of the test cases to be executed to obtain the test classification results of each of the test cases to be executed may include: performing feature matching on the test output results of each of the test cases to be executed with preset memory detection feature keywords to determine memory detection abnormal test output results; performing first-level hardware feature matching on the test output results and kernel addresses of each of the test cases to be executed with transmission engine detection features to obtain first-level hardware feature matching results; and, if it is determined that the first-level hardware feature matching is not successful, performing feature matching on the test output results and runtime race condition detection results of each of the test cases to be executed. The test report features are used for second-level hardware feature matching to obtain second-level hardware feature matching results. If the second-level hardware feature matching fails, the test output results of each test case to be executed and the fatal error features of the address detection tool are used for third-level hardware feature matching to obtain third-level hardware feature matching results. The hardware error detection anomaly test output results are determined based on the first-level hardware feature matching results, the second-level hardware feature matching results, or the third-level hardware feature matching results. The test classification results of each test case to be executed are determined based on the memory detection anomaly test output results and the hardware error detection anomaly test output results.

[0051] The test output includes three main components: Preset memory detection keywords (which can be predefined and used to identify and locate memory detection errors from the test output); Memory detection anomaly test outputs (which can match the preset memory detection keywords); Kernel address and data transfer engine detection features (which can be predefined and used to identify and locate kernel address errors and data transfer engine errors from the test output); First-level hardware feature matching results (which can match the kernel address and data transfer engine detection features); Runtime race condition report features (which can be predefined and used to identify and locate race condition errors and data race anomalies during program execution from the test output); Second-level hardware feature matching results (which can match the runtime race condition report features); and Fatal error features of the address detection tool (which can be predefined and used to identify and locate fatal errors such as address access violations, memory out-of-bounds errors, or null pointer references from the test output); and Third-level hardware feature matching results (which can match the fatal error features of the address detection tool). The hardware error detection anomaly test output can be the feature matching result of the test output obtained based on the first-level hardware feature matching result, the second-level hardware feature matching result, or the third-level hardware feature matching result.

[0052] In this embodiment of the invention, when performing feature matching on the test output results of each test case to obtain the test classification results of each test case, the target test system can call the memory detection separation plugin to read the XML file content of the test output results corresponding to each test case to be executed, and perform line-by-line matching with preset memory detection feature keywords, thereby obtaining the memory detection anomaly test output results. For example, the preset memory detection feature keywords may include, but are not limited to, address detection digest tags and thread detection digest tags, etc. This embodiment of the invention does not limit the specific content included in the preset memory detection feature keywords.

[0053] Simultaneously, the target testing system can also invoke the hardware error detection plugin to perform fine-grained classification and matching of the log content of each test output result using regular expressions, and match step by step according to a set priority. First, the log content of each test output result can be matched against kernel addresses and transmission engine detection features to obtain the first-level hardware feature matching result. If the first-level hardware feature matching fails, the test output log content of each test output result can be matched against runtime race condition detection report features to obtain the second-level hardware feature matching result. If the second-level hardware feature matching still fails, the test output log content of each test output result can be matched against fatal error features from address detection tools to obtain the third-level hardware feature matching result. Based on this, the abnormal test output results of hardware error detection can be determined according to the successfully matched hardware features.

[0054] Optionally, before performing feature matching on the test output results of each test case to obtain the test classification results, a Sanitizer feature matching can be performed on the test output log content of each test output result. If no match is found, it indicates that the test output result of the test case to be executed is normal and can be directly reported to the test dashboard server; if a match is found, it is determined that the test output result of the test case to be executed is abnormal and further memory detection and hardware feature matching processing are required.

[0055] S260. Based on the test classification results of each test case to be executed, add a target suffix tag to the result node corresponding to the test output result of each test case to be executed.

[0056] Among them, the target suffix tag can be a pre-set suffix tag that matches various detection features.

[0057] Accordingly, after obtaining the test classification results of each test case to be executed, target suffix tags can be added to the result nodes corresponding to the test output results of each test case to be executed based on the test classification results of each test case to be executed. Thus, the test output results can be classified and merged based on the target suffix tags of each result node.

[0058] S270. The test output logs in the test output results of each of the test cases to be executed are truncated to obtain the truncated test output logs corresponding to each of the test output logs.

[0059] Among them, truncated test output logs can be test output logs obtained by truncating the test output logs in the test output results.

[0060] Specifically, the test output of each test case to be executed includes a complete test output log. For test cases with large output volumes, the log data can reach tens of megabytes, consuming significant system memory resources. Therefore, the target test system can intelligently truncate the test output log based on a preset truncation threshold, retaining only the first and last segments of the log. This means the first and last segments each occupy half the storage space of the preset truncation threshold. Furthermore, a truncation warning marker can be inserted in the middle of the truncated test output log, indicating the reason for truncation and the preset truncation threshold parameters. This "first and last segment retention" log truncation strategy can completely preserve the environment configuration information at the beginning of the test and the abnormal error information at the end of the test, avoiding the loss of critical log content.

[0061] S280. Upload each of the truncated test output logs to the file archive storage server and obtain the URL of each of the truncated test output logs; replace the test output logs in each of the test output results with the URLs of each of the truncated test output logs.

[0062] Accordingly, after obtaining the truncated test output logs corresponding to each test output log, these truncated logs can be uploaded to a file archive storage server. Upon successful upload, the file archive storage server generates a corresponding URL (Uniform Resource Locator) for each truncated test output log. Based on this, the result submission thread can replace the test output logs in each test output result with the URLs of the truncated test output logs. Log truncation significantly reduces the overall size of the XML file, effectively improving the efficiency of subsequent test output result submission, while also supporting direct access and viewing of the complete log content via the URL in a browser.

[0063] It should be noted that the embodiments of the present invention do not limit the order of S250-S260 and S270-S280. That is, S250-S260 and S270-S280 can be performed simultaneously or sequentially.

[0064] S290. Merge each test output result according to the target suffix mark corresponding to each test output result to obtain the integrated test output result corresponding to each target suffix mark.

[0065] The integrated test output can be the result of merging multiple test outputs with the same target suffix.

[0066] After completing the log processing and suffix tagging of each test output, multiple test outputs with the same target suffix tag can be merged to obtain the integrated test output corresponding to each target suffix tag. It should be noted that during the merging process, the integrity of the test nodes and test lists for each test case to be executed must be maintained, and the summarized time information must be updated.

[0067] Optionally, test outputs without anomalies can be left unmarked with a target suffix, allowing for the merging of such test outputs without a target suffix.

[0068] S2100, Batch submit the integrated test output results corresponding to each of the target suffix tags to different sub-projects of the test dashboard server.

[0069] Accordingly, after obtaining the integrated test output results corresponding to each target suffix tag, these results can be submitted in batches to different sub-projects on the test dashboard server. This allows different teams to independently view and analyze the test output results they are interested in, thereby achieving automatic fault routing and independent tracking. Furthermore, sub-projects with abnormal test output results can serve as input for the rerun of failed test cases, enabling targeted regression verification.

[0070] The above solution refactors the traditional serial processing flow of testing tools—execution followed by submission—into a multi-threaded parallel pipeline architecture. In this architecture, the test execution thread acts as the producer, and the result submission thread acts as the consumer, with business logic decoupled through a thread-safe result message queue. After a test case finishes execution, the test output is immediately encapsulated into a result node and written to the result message queue. The test execution thread can then directly schedule and execute the next test case without waiting for the submission process to complete. Simultaneously, the result submission thread runs independently and asynchronously, supporting batch merging and submission of test results, and dynamically adjusting the batch submission size. This architecture eliminates the synchronization blocking problem between test execution and network input / output, significantly improving overall test throughput in scenarios with large-scale test case execution, while ensuring that submitted test results are not lost due to abnormal interruptions in subsequent test tasks.

[0071] After the result submission thread submits the test output results, the multi-platform result aggregation and distribution layer of the target test system can extract the build identifier from the response file returned by the test dashboard. The build identifier is persistently stored for subsequent result queries and aggregation reporting. Simultaneously, the multi-platform result aggregation and distribution layer of the target test system can also distribute the integrated test output results to downstream platforms for data storage and analysis. (1) The test dashboard server can be used to display test output results and provide multi-dimensional browsing by build, site and sub-project; (2) The CI (Continuous Integration) task management platform can be used to update the execution status and log links of each test case to be executed in the pipeline task; (3) The Quality Analysis Center can be used to upload structured test output data and supports quality trend analysis across versions and builds; (4) File archiving can be used to save the complete contents of the original test output logs for detailed analysis afterward.

[0072] In an optional embodiment of the present invention, the chip testing method may further include: when starting the current test process of the target chip, if it is determined that a local tag file exists in the target test system, matching the session tag parameters of the local tag file with the test parameters of the current test process to obtain a session tag matching result; if it is determined that the session tag matching result is a successful match, submitting the test output result of the current test process to the test board session corresponding to the local tag file; if it is determined that the session tag matching result is a failed match, generating a new test identifier tag, and creating a new test board on the test board server to submit the test output result of the current test process to the new test board.

[0073] The current test process can be the test process currently being executed by the target test system. The local tag file can be a local configuration file deployed in the target test system for classifying and identifying test output results. Session tag parameters can be parameters used to uniquely identify the local tag file. Test parameters can be a set of control parameters pre-configured and effective for the current test process, which can be used to limit test execution methods, log processing rules, test output result collection, and uploading archiving, among other business logic. Session tag matching results can be the results indicating whether the session tag parameters in the local tag file match the test parameters of the current test process. Test identification tags can be attribute markers used to distinguish, identify, and classify test objects; they can be stored in the local tag file and used as the basis for judging, matching, and merging test output results. Test dashboard construction can be a test dashboard used to visualize test output results.

[0074] In this embodiment of the invention, when starting the current test process of the target chip, the target test system can check whether a local tag file exists. If the target test system does not have a local tag file, it can generate a session tag in the format of "year-month-day-hour-minute" based on the current UTC (Coordinated Universal Time) time, and persist the tag, site name, build name, and version number to the local tag file. Subsequent test output submissions reuse the same tag to ensure that all test outputs belong to the same test dashboard build.

[0075] If a local tag file exists in the target test system, the session tag parameters of the local tag file, such as site name, build number, or version number, can be matched with the test parameters of the current test process to obtain the session tag matching result. Based on this, if the session tag matching result is successful, the test output of the current test process can be submitted to the test dashboard session corresponding to the local tag file; if the session tag matching result fails, a new test identifier tag can be generated, and a new test dashboard build can be created on the test dashboard server. The test output of the current test process can then be submitted to the new test dashboard build.

[0076] Optionally, before each test output submission, the target testing system can compare the date portion of the tag in the current working directory with the date portion of the cached tag. If the two dates are inconsistent, it indicates that the current test process has crossed UTC midnight. In this case, the current update information XML can be backed up to the directory corresponding to the old tag, while the local tag file and update status flag are reset. The original tag will be used in subsequent submissions to ensure that all test results are still aggregated into the test dashboard construction corresponding to the same date.

[0077] Optionally, during the startup phase of the current test process, if the current UTC time is detected to be after 23:59:50, the target test system can proactively wait for 10 seconds to allow the clock to cross midnight, in order to avoid starting the test process at the critical moment of date switching and causing label confusion.

[0078] Optionally, in multi-round loop testing scenarios, a timestamp can be checked at the start of each new loop. If it falls within the same minute as the previous loop, a 60-second wait is initiated to ensure that each loop obtains a different timestamp, avoiding result overwriting between different loops. This approach ensures that the operating mechanism is unaffected by the test duration, allowing all test outputs to be accurately aggregated into the pre-defined test dashboard.

[0079] Optionally, an abstract base class can be defined in the pluggable extension plugin layer of the target testing system as the parent class of all plugins. This base class declares six lifecycle hook methods: global initialization hook, pre-test hook, post-test hook, pre-commit hook, post-commit hook, and global cleanup hook. The global initialization hook is called before the start of all test processes to prepare the environment; the pre-commit hook is called before the output results of each batch of tests are submitted to the test dashboard; the post-commit hook is called after the commit is completed; and the global cleanup hook is called after all tests are completed to perform resource cleanup and data termination. Each hook method within the base class can adopt a defensive design: first check if the subclass implements the corresponding internal method; if so, call the method; otherwise, return the default value.

[0080] Based on this, the target testing system can provide multiple built-in plugins. Each plugin can inherit from this abstract base class and implement the required hook methods to achieve specific functions. At the same time, the target testing system can maintain a global plugin registration list. When the test starts, based on the set of plugin names specified by the user through command-line parameters, the corresponding plugin object is instantiated and added to the registration list. At each stage of the test lifecycle, the core scheduling logic traverses the registration list and can call the corresponding hook method of each plugin in turn.

[0081] In a specific example, the target testing system may include, but is not limited to, memory detection and separation plugins, hardware error detection plugins, code coverage plugins, result aggregation and reporting plugins, operator statistics plugins, and loop testing plugins. This embodiment of the invention does not limit the specific types of plugins included in the target testing system. Wherein: The memory testing separation plugin can be used to scan test log content in the pre-commit hook, matching it with characteristic summary keywords from CPU (Central Processing Unit) memory testing tools. If a match is successful, a specific suffix tag is added to the result node, causing the result to be categorized into a separate sub-project when submitted to the test dashboard, and displayed separately from functional test failures.

[0082] The hardware error detection plugin can be used to match chip-specific error detection features in the pre-submission hook using regular expressions, such as kernel-mode address detection reports, runtime address detection reports, or runtime race condition detection reports. Different suffix tags can be added according to the specific feature type matched to achieve fine-grained classification of hardware errors.

[0083] The code coverage plugin can be used to set the collection path and path prefix stripping depth for coverage data in the global initialization hook, and to package the collected coverage data into an archive file in the global cleanup hook.

[0084] The results aggregation and reporting plugin can be used to collect build identifiers obtained from each commit in the post-commit hook, and in the global cleanup hook, it can batch query the details links of all committed test cases through the test dashboard's application programming interface, aggregate the results, and report them to the quality analysis center. It also supports timed incremental synchronization (at fixed intervals) to avoid accumulating too much unsynchronized data during long-term testing.

[0085] The operator statistics plugin can be used to parse the operator names of performance tests from the command-line arguments of test cases in the post-commit hook, and persist the cumulative list of operator names to a file in the global cleanup hook for use by subsequent performance analysis tools.

[0086] The loop testing plugin can be used to append the current loop number to the result suffix tag in the pre-commit hook, so that the results of multiple loop tests are displayed independently in the test dashboard.

[0087] This invention, in its embodiments, obtains the configuration information of the target chip and a specified test case set input by the target user. Then, it filters the specified test case set based on the target chip's configuration information to generate a set of test cases to be executed for the target chip. After generating the set of test cases to be executed, each test execution thread executes the set of test cases to obtain the test output results of each test case in the set. Further, it can be determined whether the test output result submission conditions are met. If not, execution returns to using each test execution thread to execute the set of test cases to obtain the test output results of each test case in the set. If the conditions are met, feature matching is performed on the test output results of each test case to obtain the test classification results of each test case. Based on the test classification results of each test case, a target suffix marker is added to the result node corresponding to the test output result of each test case. Simultaneously, the test output logs in the test output results of each test case are truncated to obtain the truncated test output logs corresponding to each test output log. Furthermore, the output logs of each truncated test are uploaded to a file archive storage server, and the URLs of each truncated test output log are obtained. These URLs are then used to replace the test output logs in each test output result. Based on this, the test output results are merged according to the target suffix tags corresponding to each test output result, resulting in integrated test output results corresponding to each target suffix tag. These integrated test output results are then submitted in batches to different sub-projects on the test dashboard server. This solution addresses the technical shortcomings of existing chip testing methods, such as low testing efficiency, high configuration and maintenance costs, and difficulties in fault location and troubleshooting. It optimizes the automated chip testing process, significantly improves overall test execution efficiency and task reliability, and effectively reduces test operation and maintenance and configuration management costs.

[0088] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0089] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant regions.

[0090] It should be noted that any arrangement or combination of the technical features in the above embodiments also falls within the protection scope of this invention.

[0091] Example 3 Figure 4 This is a schematic diagram of a chip testing device provided in Embodiment 3 of the present invention, as shown below. Figure 4 As shown, the device includes: a data acquisition module 310, a test case set generation module 320, a test output result output module 330, and a test output result classification and submission module 340, wherein: The data acquisition module 310 is used to acquire the configuration information of the target chip and the set of specified test cases input by the target user; The test case set generation module 320 is used to filter the specified test case set according to the configuration information of the target chip and generate the test case set to be executed for the target chip. The test output module 330 is used to execute the set of test cases to be executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed; The test output result classification and submission module 340 is used to classify the test output results of each test case to be executed using the result submission thread, and submit them in batches to the test dashboard server.

[0092] This invention, through obtaining the configuration information of the target chip and a specified set of test cases input by the target user, filters the specified set of test cases based on the target chip's configuration information to generate a set of test cases to be executed for the target chip. After generating the set of test cases to be executed, each test execution thread executes the set of test cases to obtain the test output results of each test case in the set. Furthermore, a result submission thread categorizes the test output results of each test case to be executed and submits them in batches to a test dashboard server. The above solution solves the technical drawbacks of existing chip testing methods, such as low testing efficiency, high configuration and maintenance costs, and difficulties in fault location and troubleshooting. It can optimize the automated chip testing process, significantly improve the overall test execution efficiency and task reliability, and effectively reduce test operation and maintenance and configuration management costs.

[0093] Optionally, the test case set generation module 320 is specifically used for: parsing the test description files of each specified test case in the specified test case set, determining the compatible chip identifier and compatible test function of each specified test case; matching the configuration information of the target chip with the compatible chip identifier of each specified test case to obtain a first disabled test case set for the target chip; parsing the hardware feature configuration file of the target chip to determine the dedicated hardware function of the target chip; matching the dedicated hardware function of the target chip with the compatible test function of each specified test case to obtain a second disabled test case set for the target chip; and determining the test case set to be executed for the target chip based on the specified test case set, the first disabled test case set, and the second disabled test case set.

[0094] Optionally, the test output module 330 is specifically used for: obtaining the parallelism parameter input by the target user; creating multiple test execution threads and a result submission thread based on the parallelism parameter input by the target user; using each test execution thread to obtain the test case identifier of the target test case corresponding to each test execution thread from the set of test cases to be executed; using the test execution thread to construct a test command line based on the test case identifier of the target test case to be executed, and executing the test command line to obtain the test output result of the target test case to be executed; encapsulating the associated attribute information of the test output result of the target test case to be executed into a result node and writing it into a result message queue.

[0095] Optionally, the test output result classification and submission module 340 is specifically used for: when it is determined that the number of result nodes in the result message queue exceeds a preset node threshold, or when it is determined that the queuing time interval of the result node exceeds a preset waiting threshold, performing feature matching on the test output results of each test case to be executed to obtain the test classification results of each test case to be executed; adding target suffix tags to the result nodes corresponding to the test output results of each test case to be executed according to the test classification results of each test case to be executed; merging the test output results according to the target suffix tags corresponding to each test output result to obtain the integrated test output results corresponding to each target suffix tag; and submitting the integrated test output results corresponding to each target suffix tag in batches to different sub-projects of the test dashboard server; wherein, the test dashboard server is used to distribute the integrated test output results to downstream platforms for data storage and analysis processing by the downstream platforms.

[0096] Optionally, the test output result classification and submission module 340 is further configured to: truncate the test output logs in the test output results of each of the test cases to be executed, to obtain truncated test output logs corresponding to each of the test output logs; upload each of the truncated test output logs to a file archiving storage server and obtain the URL of each of the truncated test output logs; and replace the test output logs in each of the test output results with the URLs of each of the truncated test output logs.

[0097] Optionally, the test output result classification and submission module 340 is further configured to: perform feature matching between the test output results of each of the test cases to be executed and preset memory detection feature keywords to determine memory detection abnormal test output results; perform first-level hardware feature matching between the test output results of each of the test cases to be executed and the kernel address and the transmission engine detection features to obtain first-level hardware feature matching results; if the first-level hardware feature matching fails, perform second-level hardware feature matching between the test output results of each of the test cases to be executed and the runtime race condition detection report features to obtain second-level hardware feature matching results; if the second-level hardware feature matching fails, perform third-level hardware feature matching between the test output results of each of the test cases to be executed and the fatal error features of the address detection tool to obtain third-level hardware feature matching results; determine hardware error detection abnormal test output results based on the first-level hardware feature matching results, the second-level hardware feature matching results, or the third-level hardware feature matching results; and determine the test classification results of each of the test cases to be executed based on the memory detection abnormal test output results and the hardware error detection abnormal test output results.

[0098] Optionally, the above-mentioned device may further include a result submission control module, used to, when starting the current test process of the target chip, if it is determined that a local tag file exists in the target test system, match the session tag parameters of the local tag file with the test parameters of the current test process to obtain a session tag matching result; if it is determined that the session tag matching result is a successful match, submit the test output result of the current test process to the test board session corresponding to the local tag file; if it is determined that the session tag matching result is a failed match, generate a new test identifier tag, and create a new test board on the test board server to submit the test output result of the current test process to the new test board.

[0099] The chip testing apparatus described above can execute the chip testing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the chip testing method provided in any embodiment of the present invention.

[0100] Since the chip testing apparatus described above is capable of executing the chip testing method in the embodiments of the present invention, those skilled in the art can understand the specific implementation and various variations of the chip testing apparatus in this embodiment based on the chip testing method described in the embodiments of the present invention. Therefore, how the chip testing apparatus implements the chip testing method in the embodiments of the present invention will not be described in detail here. Any apparatus used by those skilled in the art to implement the chip testing method in the embodiments of the present invention falls within the scope of protection of this application.

[0101] Example 4 Figure 5 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 processors, cellular phones, smartphones, wearable devices (such as 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.

[0102] like Figure 5 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.

[0103] 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.

[0104] 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 chip testing methods.

[0105] In some embodiments, the chip testing method may 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 may be loaded and / or mounted 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 chip testing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the chip testing method by any other suitable means (e.g., by means of firmware).

[0106] Optionally, the chip testing method may include: obtaining the configuration information of the target chip and a specified test case set input by the target user; filtering the specified test case set according to the configuration information of the target chip to generate a set of test cases to be executed for the target chip; executing the set of test cases to be executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed; and classifying the test output results of each test case to be executed using a result submission thread and submitting them in batches to a test dashboard server.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); 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).

[0111] 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.

[0112] 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.

[0113] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the chip testing method provided in any embodiment of this application. This program product and the chip testing methods disclosed in the embodiments of this application belong to the same inventive concept, and therefore will not be described in detail here.

[0114] 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.

[0115] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. 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 disclosure should be included within the scope of protection of this disclosure.

Claims

1. A chip testing method, characterized in that, include: Obtain the configuration information of the target chip and the set of specified test cases input by the target user; The specified test case set is filtered based on the configuration information of the target chip to generate a set of test cases to be executed for the target chip; The set of test cases to be executed is executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed; The test output results of each test case to be executed are classified by the result submission thread and submitted in batches to the test dashboard server.

2. The method according to claim 1, characterized in that, The step of filtering the specified test case set according to the configuration information of the target chip to generate a set of test cases to be executed for the target chip includes: Parse the test description files of each specified test case in the specified test case set to determine the compatible chip identifier and compatible test function of each specified test case; The configuration information of the target chip is matched with the chip identifier of each specified test case to obtain the first set of disabled test cases for the target chip. The hardware feature configuration file of the target chip is parsed to determine the exclusive hardware functions of the target chip; The dedicated hardware functions of the target chip are matched with the adaptation test functions of each specified test case to obtain a second set of disabled test cases for the target chip. Based on the specified test case set, the first disabled test case set, and the second disabled test case set, the set of test cases to be executed for the target chip is determined.

3. The method according to claim 1, characterized in that, The step of executing the set of test cases to be executed using each test execution thread to obtain the test output results of each test case to be executed in the set of test cases to be executed includes: Obtain the parallelism parameter input by the target user; Multiple test execution threads and one result submission thread are created based on the parallelism parameters input by the target user. The test case identifier of the target test case corresponding to each test execution thread is obtained from the set of test cases to be executed using each test execution thread; The test execution thread constructs a test command line based on the test case identifier of the target test case to be executed, and executes the test command line to obtain the test output result of the target test case to be executed; The associated attribute information of the test output results of the target test case to be executed is encapsulated into a result node and written into the result message queue.

4. The method according to claim 3, characterized in that, The process of using the result submission thread to categorize the test output results of each test case to be executed and submit them in batches to the test dashboard server includes: If it is determined that the number of result nodes in the result message queue exceeds a preset node threshold, or if it is determined that the queuing time interval of the result node exceeds a preset waiting threshold, feature matching is performed on the test output results of each test case to be executed to obtain the test classification results of each test case to be executed. Based on the test classification results of each test case to be executed, add a target suffix tag to the result node corresponding to the test output result of each test case to be executed; The test output results are merged according to the target suffix tags corresponding to each of the test output results to obtain the integrated test output results corresponding to each of the target suffix tags; The integrated test output results corresponding to each of the target suffix tags are submitted in batches to different sub-projects of the test dashboard server; The test dashboard server is used to distribute the integrated test output results to downstream platforms so that the downstream platforms can complete data storage and analysis.

5. The method according to claim 4, characterized in that, The step of using the result submission thread to classify the test output results of each of the test cases to be executed and submit them in batches to the test dashboard server also includes: The test output logs in the test output results of each of the test cases to be executed are truncated to obtain the truncated test output logs corresponding to each of the test output logs. Upload the output logs of each truncation test to the file archive storage server and obtain the Uniform Resource Locator (URL) of each truncation test output log; Replace the test output logs in each of the test output results with the URLs of the truncated test output logs.

6. The method according to claim 4, characterized in that, The step of performing feature matching on the test output results of each of the aforementioned test cases to obtain the test classification results for each of the aforementioned test cases to be executed includes: The test output results of each of the test cases to be executed are matched with the preset memory detection feature keywords to determine the abnormal test output results of memory detection. The test output results and kernel addresses of each of the test cases to be executed are matched with the detection features of the transmission engine to obtain the first-level hardware feature matching results. If the first-level hardware feature matching fails, the test output results of each test case to be executed and the features of the runtime race condition detection report are used for the second-level hardware feature matching to obtain the second-level hardware feature matching result. If the second-level hardware feature matching fails, the test output results of each test case to be executed and the fatal error characteristics of the address detection tool are used for third-level hardware feature matching to obtain the third-level hardware feature matching results. The hardware error detection anomaly test output result is determined based on the first-level hardware feature matching result, the second-level hardware feature matching result, or the third-level hardware feature matching result. The test classification results for each test case to be executed are determined based on the memory detection anomaly test output results and the hardware error detection anomaly test output results.

7. The method according to claim 1, characterized in that, The method further includes: When the current test process of the target chip is started, if it is determined that a local tag file exists in the target test system, the session tag parameters of the local tag file are matched with the test parameters of the current test process to obtain the session tag matching result. If the session tag matching result is determined to be a successful match, the test output result of the current test process is submitted to the test dashboard session corresponding to the local tag file; If the session tag matching result is determined to be a failure, a new test identifier tag is generated, and a new test dashboard is created on the test dashboard server to submit the test output results of the current test process to the new test dashboard.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that is executed by the at least one processor to enable the at least one processor to perform the chip testing method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the chip testing method according to any one of claims 1-7.

10. A computer program product, characterized in that, It includes a computer program / instruction, wherein the computer program / instruction, when executed by a processor, implements the chip testing method according to any one of claims 1-7.

Images