A chip testing method, device, electronic equipment, storage medium and program

Abstract

Embodiments of the present application disclose a chip test method, device, electronic equipment, storage medium and program, wherein the method comprises: obtaining a standardized chip test configuration file; wherein the standardized chip test configuration file comprises a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure and a test execution description area structure; parsing each data structure of the standardized chip test configuration file to obtain a chip test configuration field; and automatically executing pipeline test tasks of each test scene in a staged manner according to the chip test configuration field. The technical solution of the embodiments of the present application can quickly and accurately reproduce a special test scene of a chip.

Description

Technical Field

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

[0002] Due to the inherent complexity of chip companies' software stacks, their testing pipelines also exhibit correspondingly higher complexity.

[0003] Currently, when testing chips, whether ordinary chips or AI (Artificial Intelligence) chips, the industry generally adopts CI (Continuous Integration) / CD (Continuous Delivery) pipelines for automated testing. This CI / CD pipeline automated testing method uses common configuration files, such as JSON (JavaScript Object Notation) or YAML (YAML Ain't Markup Language, a lightweight and data-centric serialization language), to define the test process and configure parameters.

[0004] However, in chip testing, testers often provide chip-specific configuration files based on the specific testing requirements of the chip. These configuration files may include chip-specific fields and other specialized information. Current general-purpose test pipelines lack the ability to understand chip-specific configurations, and their generic configuration parsers cannot recognize the meaning of chip-specific fields in these configuration files, making it difficult to accurately reproduce chip testing scenarios. Summary of the Invention

[0005] This invention provides a chip testing method, apparatus, electronic device, storage medium, and program that can quickly and accurately reproduce specific testing scenarios for chips.

[0006] According to one aspect of the present invention, a chip testing method is provided, comprising: Obtain a standardized chip test configuration file; wherein the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure; The data structures of the standardized chip test configuration file are parsed to obtain the chip test configuration fields; Based on the chip test configuration fields, pipeline test tasks for each test scenario are executed automatically in a phased manner.

[0007] According to another aspect of the present invention, a chip testing apparatus is provided, comprising: The chip test configuration file acquisition module is used to acquire a standardized chip test configuration file; wherein, the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure; The chip test configuration field parsing module is used to parse the data structures of the standardized chip test configuration file to obtain the chip test configuration fields. The pipeline test task execution module is used to automatically execute pipeline test tasks for each test scenario in a phased manner according to the chip test configuration fields.

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

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

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

[0011] This invention provides a standardized chip test configuration file. This file includes various data structures such as metadata, hardware environment description, software environment description, environment configuration, and test execution description. The file's data structures are then parsed to obtain chip test configuration fields. Based on these fields, pipeline testing tasks for each test scenario are automatically executed in stages. This chip testing method effectively solves the problem that existing general-purpose pipeline testing tools struggle to understand chip-specific configuration information, thus failing to reproduce chip test scenarios. It enables rapid and accurate reproduction of chip-specific test scenarios.

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

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

[0014] Figure 1 This is a flowchart of a chip testing method provided in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the structure of a chip testing device provided in Embodiment 1 of the present invention; Figure 3 This is a flowchart of a chip testing method provided in Embodiment 2 of the present invention; Figure 4 This is a flowchart of a chip testing method provided in Embodiment 3 of the present invention; Figure 5 This is a flowchart of a chip testing method provided in Embodiment 4 of the present invention; Figure 6 This is a schematic diagram of an eight-stage test environment reconstruction process provided in Embodiment 4 of the present invention; Figure 7 This is a schematic diagram of the lifecycle state machine for a test work scenario provided in Embodiment 4 of the present invention; Figure 8 This is a schematic diagram of a chip testing device provided in Embodiment 5 of the present invention; Figure 9 This is a schematic diagram of the structure of an electronic device provided in Embodiment Six of the present invention. Detailed Implementation

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

[0016] It should be noted that the terms "first," "second," "third," "fourth," "fifth," "sixth," "seventh," and "eighth," etc., used 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 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.

[0017] 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 the automated parsing of chip test configuration files including specific data structures to automatically execute pipeline testing tasks for various chip test scenarios. 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 a standardized chip test configuration file; wherein the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure.

[0018] The chip test configuration file can be a configuration file specifically designed for testing the chip. Optionally, the chip for which the chip test configuration file needs to be generated can be an AI chip or a regular chip; this embodiment of the invention does not limit the type of chip to which the chip test configuration file is adapted.

[0019] In this embodiment of the invention, various test scenarios for a chip can be quickly and accurately reproduced using a chip test configuration parsing and execution device (hereinafter referred to as the chip test device) based on chip-specific configuration specifications. First, the chip test device can obtain a standardized chip test configuration file. Optionally, the standardized chip test configuration file can adopt a five-zone structure to integrate the configuration information required by the chip during testing. The five-zone structure of the standardized chip test configuration file may include a metadata zone structure, a hardware environment description zone structure, a software environment description zone structure, an environment configuration zone structure, and a test execution description zone structure.

[0020] The metadata area structure (which can be simply referred to as the metadata area) can be used to store the metadata required for chip testing. Metadata is data that describes data; it does not contain the data itself, but rather provides key information about the data's structure, meaning, source, and purpose, helping people and systems understand, manage, discover, and use the data. Optionally, the metadata area structure can use metadata fields to store metadata, and these metadata fields can be relevant fields that describe the metadata.

[0021] The hardware environment description area structure (which can be referred to as the software environment description area) can be a data structure used to describe the chip driver, runtime library, and container environment. The hardware environment description area structure can use chip hardware environment detection fields to store chip hardware environment detection data. Chip hardware environment detection fields can be relevant fields that describe the chip hardware environment detection data. Chip hardware environment detection data mainly refers to real-time monitoring parameters of the physical environment and the chip's own operating status during chip operation or testing, used to ensure stability, reliability, and security. This data is typically collected by on-chip sensors or external monitoring systems, covering multiple dimensions such as temperature, voltage, power consumption, humidity, and vibration.

[0022] The software environment description area structure (hereinafter referred to as the software environment description area) can be a data structure used to describe the chip driver, runtime library, and container environment. The software environment description area structure can use chip software environment fields to store chip software environment data. Chip software environment fields can be relevant fields that describe the chip software environment data. Chip software environment data refers to the configuration, status, and behavioral information closely related to its software system during chip operation, testing, or development. It is used to ensure normal software and hardware collaboration and to support functional verification, performance tuning, and fault diagnosis.

[0023] The environment configuration area structure (referred to as the environment configuration area) is a data structure used to describe the environment settings within the host machine and containers. The environment configuration area structure can use environment configuration fields to store environment configuration data. Environment configuration fields can be related fields used to describe the environment configuration data. Environment configuration data is a set of key parameters that ensures the stable operation of the chip during the development, testing, and operation phases. It covers hardware, software, and physical environment settings and directly affects system compatibility, performance, and reliability.

[0024] The test execution description area structure (hereinafter referred to as the test execution description area) can be a data structure used to describe test commands and result data. The test execution description area structure can use test execution fields to store test execution data. Test execution fields can be relevant fields used to describe the test execution data. Test execution data consists of all raw records and result information generated by the software or hardware during the testing process. It is used to evaluate system functionality, performance, and stability, and is the core basis for quality assurance and problem tracing.

[0025] Building upon this foundation, the standardized chip test configuration file's data structure can be further extended to accommodate the testing needs of different chip types. For example, a dependency description area structure (referred to as dependencies) can be added. Exemplarily, the dependency description area structure can configure fields including, but not limited to, framework, framework_version, model_artifacts, and dataset_paths. The framework field specifies the type of development framework or system framework, and framework_version specifies the version number of the development framework or system framework. model_artifacts is a field applicable to AI chip types, used to configure all critical files and resources generated during model training, compilation, or deployment. The dataset_paths field refers to the path to a dataset file or folder.

[0026] Therefore, the five-zone structure of the chip test configuration file ensures the integrity of the chip test scenario. The configuration information in the metadata zone can provide scenario identification and traceability; the configuration information in the hardware environment description zone can ensure that hardware dependencies are verifiable; the configuration information in the software environment description zone can ensure that the software version is reproducible; the configuration information in the environment configuration zone can ensure that environment variables and settings are recoverable; and the configuration information in the test execution description zone can ensure that test cases can be re-executed.

[0027] S120. Parse each data structure of the standardized chip test configuration file to obtain the chip test configuration fields.

[0028] Among them, the chip test configuration field can be a field specific to the chip industry.

[0029] Figure 2 This is a schematic diagram of a chip testing device provided in Embodiment 1 of the present invention. In a specific example, such as... Figure 2 As shown, the chip testing device can adopt a three-layer architecture, divided into a user interface layer, a core processing layer, and an infrastructure layer from top to bottom. The user interface layer is essentially a CLI (Command Line Interface) that provides a variety of standardized commands, covering the entire lifecycle of configuration parsing, environment building, test execution, and scenario management. Optionally, the user interface layer can provide users with commands such as automatically setting up the test environment, running test cases with one click, entering a container for interactive debugging, listing all working scenarios, selecting and switching to a specific working scenario, displaying detailed information about the current scenario, clearing working scenarios, and resetting the chip device.

[0030] For example, the command to automatically set up the test environment can be efdbg setup.<config_file> This command can automatically set up the test environment based on the standardized chip test configuration file `config_file`, thereby enabling core reproduction functionality. `efdbg setup`<config_file> By reading the chip test configuration file config_file, the system parses the fields of the five data structures in the chip test configuration file, namely the metadata area structure, hardware environment description area structure, software environment description area structure, environment configuration area structure, and test execution description area structure, and automatically executes the eight-stage environment construction process.

[0031] For example, the command to run test cases with one click can be efdbg run.<config_file> This command integrates the complete setup and test execution process, and can automatically enter the container and execute the test commands defined in the tests field of the chip test configuration file.

[0032] For example, the command to enter the container for interactive debugging can be efdbg enter. This command allows engineers to manually enter the container and execute arbitrary debugging commands, supporting operations such as breakpoint debugging, log viewing, and file inspection.

[0033] For example, the command to list all work scenarios can be `efdbg list`. This command can be used to display all created work scenarios in the current system. Each work scenario corresponds to a jobid (workspace ID), and each work scenario is a chip test scenario. This command can also display the status of the test scenarios, such as CREATED, RUNNING, and PAUSED.

[0034] For example, the command to select and switch to a specified work scene can be efdbg select. <jobid>This command enables second-level test scenario switching without rebuilding the environment and supports parallel management of multiple test scenarios.

[0035] For example, the command to display detailed information about the current scenario can be the efdbg show command, which can be clearly divided into two subcommands. One subcommand can display the complete sequence of commands executed in the scenario, and the other subcommand can analyze the crash stack of the test scenario if a core dump file is known to exist.

[0036] For example, the command to clean up a workspace can be efdbg clean, which can delete the working directory and containers of a specified workspace and supports batch cleaning and automatic cleaning strategies.

[0037] For example, the command to reset a chip device can be efdbg reset, which can be used to restore the chip device when the device is in an abnormal state.

[0038] Therefore, the user interface layer provides users with various testing function entry points by adopting a unified entry command efdbg plus subcommands. The correspondence between the subcommands and the core processing layer modules is as follows: the setup / run subcommand is used to trigger configuration parsing and environment reproduction; the enter subcommand is used to enter the reproduced container; the list / select / show / clean subcommands are used to manage the reproduced scenario; and the reset subcommand is used to control the chip device.

[0039] The core processing layer of a chip testing device can be configured with multiple functional modules, each with its own specific function and working collaboratively. One of the more important functional modules in the core processing layer is the configuration parsing module. Accordingly, the chip testing device can obtain standardized chip test configuration files through this module. After obtaining the standardized chip test configuration file, the device can parse its various data structures, including the metadata area structure, hardware environment description area structure, software environment description area structure, environment configuration area structure, and test execution description area structure, to obtain chip test configuration fields specific to the chip testing field. Optionally, partial chip test configuration fields can be parsed from each type of data structure in the chip test configuration file.

[0040] The infrastructure layer of a chip testing device provides three fundamental capabilities. For example, the infrastructure layer can utilize Docker (an open-source containerization platform) containers, allowing users to isolate test scenarios. Each jobid field in the chip test configuration file can correspond to an independent container instance. The infrastructure layer can store workspace data through a file system (cache directory). Furthermore, the infrastructure layer can download software packages and core dump files over the network. In short, the infrastructure layer primarily provides support functions for the chip testing device, including container execution, cache storage, and software package downloading.

[0041] In summary, the chip testing device achieves decoupling of interface, logic, and infrastructure through a three-layer separation design. The various modules in the core processing layer collaborate through working directories and configuration files, with clearly defined responsibilities. The user interface layer provides unified CLI commands, thereby hiding internal complexity and facilitating user operation.

[0042] S130. Based on the chip test configuration fields, the pipeline test tasks for each test scenario are automatically executed in a phased manner.

[0043] In this context, pipeline testing tasks refer to the testing tasks performed by a general-purpose chip testing pipeline when testing a chip. The general-purpose chip testing pipeline can be any common pipeline currently used for chip testing, such as a chip CI / CD pipeline. This embodiment of the invention does not limit the type of general-purpose chip testing pipeline or the testing process.

[0044] Optionally, the core processing layer of the chip testing device can also be configured with a phased environment construction module and a test execution module. The phased environment construction module can execute a phased environment reconstruction process based on the chip test configuration fields parsed from the chip test configuration file, according to the reproduction requirements of the chip test scenario. During the phased environment reconstruction process, the module can support breakpoint resumption, automatically skipping completed stages through a checkpoint mechanism to improve environment reconstruction efficiency. Correspondingly, after the test environment reconstruction for the test scenario is completed, the core processing layer of the chip testing device can, in conjunction with the infrastructure layer, execute the test commands defined in the relevant test fields of the chip test configuration fields through the test execution module to reproduce test cases in the general chip test pipeline, thereby automating the pipeline test tasks for the corresponding test scenario. Optionally, the test execution module can support test case filtering and coverage to improve testing efficiency.

[0045] This invention provides a standardized chip test configuration file. This file includes various data structures such as metadata, hardware environment description, software environment description, environment configuration, and test execution description. The file's data structures are then parsed to obtain chip test configuration fields. Based on these fields, pipeline testing tasks for each test scenario are automatically executed in stages. This chip testing method effectively solves the problem that existing general-purpose pipeline testing tools struggle to understand chip-specific configuration information, thus failing to reproduce chip test scenarios. It enables rapid and accurate reproduction of chip-specific test scenarios.

[0046] Example 2 Figure 3 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, and provides several specific optional implementation methods for obtaining a standardized chip test configuration file. Accordingly, as... Figure 3 As shown, the method in this embodiment may include: S310: Collects real-time status information of each testing stage in the chip testing pipeline.

[0047] Among them, the real-time status association information can be multi-dimensional status information collected in real time at each test stage of the chip test pipeline.

[0048] In this embodiment of the invention, a configuration instance generation tool can be used to automatically generate chip-specific test configuration files based on information collected from a general chip testing pipeline. The configuration instance generation tool can include a state capture module and a configuration file generation module. The state capture module and the configuration file generation module maintain a communication connection. The state capture module is responsible for collecting state information from each relevant test stage of the general chip testing pipeline during chip testing, and integrating the collected state information from each test stage to obtain real-time state association information. For example, the state capture module can collect state information in real-time at each stage of the CI / CD pipeline, including environment preparation, driver installation, software configuration, and test execution. The state capture module can store the collected real-time state association information in an internal data structure, such as a StateCollector object, and pass it to the configuration file generation module after pipeline execution is complete. Further, after pipeline execution is complete, the state capture module sends the real-time state association information to the configuration file generation module. The configuration file generation module can parse and integrate the real-time state association information sent by the state capture module to generate the final standardized chip test configuration file.

[0049] Since a typical chip testing pipeline may include multiple testing stages, and the status information collected in each stage may include multiple types, the status capture module can classify the real-time status-related information according to chip testing requirements. Correspondingly, the configuration file generation module can extract key information from each type of real-time status-related information and organize this extracted key information according to standard requirements to generate a structured configuration file, thus obtaining a standardized chip test configuration file. Compared to traditional methods that require manual configuration file writing, which is prone to missing key information or inconsistencies, the configuration instance generation tool, through the cooperation of the status capture module and the configuration file generation module, achieves automatic conversion from pipeline execution to configuration file generation, ensuring the completeness, accuracy, and consistency of configuration information.

[0050] S320. Fill the preset data structure of the chip test configuration file according to the real-time status association information to obtain the initial chip test configuration file.

[0051] The preset data structure can be a dedicated data structure specifically configured for the chip test configuration file, taking into account the chip's characteristics. In this embodiment of the invention, the preset data structure can include, but is not limited to, various data structures such as metadata area structure, hardware environment description area structure, software environment description area structure, environment configuration area structure, and test execution description area structure. The initial chip test configuration file can be a chip test configuration file initially generated based on the preset data structure of the real-time status association information and the chip test configuration file.

[0052] In this embodiment of the invention, when the configuration file generation module receives all the real-time state association information collected by the state capture module and generates a standardized chip test configuration file based on the real-time state association information, the standardized chip test configuration file can be generated collaboratively by three components: a template filling engine, a pattern verifier, and a file serializer. Correspondingly, the configuration file generation module can use the template filling engine to fill the received real-time state association information into a preset data structure of the chip test configuration file to obtain the initial chip test configuration file.

[0053] In an optional embodiment of the present invention, the acquisition of real-time status association information of the general chip testing pipeline at each test stage during chip testing may include: acquiring chip device hardware information during the environment preparation stage of the general chip testing pipeline; acquiring chip software version association information during the driver installation stage of the general chip testing pipeline; acquiring environment variable snapshot information during the software configuration stage of the general chip testing pipeline; and acquiring test command execution record information during the test execution stage of the general chip testing pipeline.

[0054] The environment preparation phase of a general-purpose chip testing pipeline is fundamental to ensuring high accuracy and reliability during testing. It primarily involves ensuring the comprehensive readiness of the testing environment, equipment, samples, and solutions. The driver installation phase is crucial for stable communication between automated test equipment and the host system. This phase mainly involves the correct deployment of debugger / programmer drivers, USB (Universal Serial Bus) to serial port drivers, and chip manufacturer-specific drivers. Chip software version association information can be information associated with the chip's software version, including but not limited to driver version number, driver installation commands, and driver parameters. The software configuration phase of a general-purpose chip testing pipeline mainly involves the initialization and parameterization of test programs, test environment, automation scripts, and toolchains. Its purpose is to ensure that the testing process can efficiently and accurately perform chip functional and performance verification. The test execution phase of a general-purpose chip testing pipeline mainly includes wafer testing, packaging testing, and system-level testing to verify the chip's functionality, performance, and reliability. Test command execution log information can include, but is not limited to, test command sequences and core dump file paths, as well as other information related to the execution of test commands.

[0055] Optionally, the status capture module can include various types of data collectors, such as hardware information collectors, software version recorders, environment variable snapshotters, and command execution recorders. Hardware information collectors can collect chip hardware information, such as GCU (General Computing Unit) device ID, quantity, and operating mode. Software version recorders can record information such as driver versions, runtime versions, and container image versions. Environment variable snapshotters can capture key environment variables within the host machine and containers. Command execution recorders can record the command sequences executed at each stage, such as the chip detection command: target_check_cmd, and the driver installation command: kmd_install_cmd.

[0056] Specifically, the hardware information acquisition module can collect chip device hardware information during the environment preparation phase of the general-purpose chip testing pipeline, such as detecting GCU device IDs and quantities using the `lspci` (List PCI devices) command. Optionally, during the environment preparation phase, the status capture module can also capture host environment variables using an environment variable snapshotter and record system check commands such as `system_check_cmd` and chip detection commands such as `target_check_cmd` using a command execution recorder. Correspondingly, during the driver installation phase of the general-purpose chip testing pipeline, the status capture module can collect and store chip software version-related information using a software version recorder and a command execution recorder. For example, the status capture module can record driver version information using a software version recorder and record driver installation commands such as `kmd_install_cmd` and the driver installation parameters included in the command using a command execution recorder.

[0057] Correspondingly, the status capture module can collect environment variable snapshot information of the storage chip during the software configuration phase of the chip test pipeline using a software version recorder and a command execution recorder. Optionally, the environment variable snapshot information may include, but is not limited to, container image version, container startup parameters, SDK (Software Development Kit) version, and environment variable setting commands. For example, the status capture module can record information such as the chip's container image version and SDK version using the software version recorder, and record container startup commands such as `docker_launch_cmd` and container environment setting commands using the command execution recorder. For instance, when installed via the SDK, the container environment setting command could be `container_env_setup`. Correspondingly, the status capture module can record various test command information of the storage chip during the test execution phase of the chip test pipeline using the command execution recorder. For example, the status capture module can record storage test command prefixes and test command sequences consisting of various types of test commands using the command execution recorder. If the chip crashes during the test execution phase of the chip test pipeline, the core dump file path for crash analysis can also be recorded. The core dump file path refers to the specified location on disk where the test state is saved when the test process terminates abnormally.

[0058] It can be seen that the status capture module collaborates with various data acquisition devices at each stage of the general chip testing pipeline to collect all the status information required by the chip test configuration file.

[0059] In an optional embodiment of the present invention, the step of filling the preset data structure of the chip test configuration file according to the real-time status association information may include: extracting metadata fields from the real-time status association information and filling the metadata area structure of the chip test configuration file according to the metadata fields; extracting chip hardware environment detection fields from the real-time status association information and filling the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection fields; extracting chip software environment fields from the real-time status association information and filling the software environment description area structure of the chip test configuration file according to the chip software environment fields; extracting environment configuration fields from the real-time status association information and filling the environment configuration area structure of the chip test configuration file according to the environment configuration fields; and extracting test execution fields from the real-time status association information and filling the test execution description area structure of the chip test configuration file according to the test execution fields.

[0060] Optionally, the preset data structure can be organized according to the five-zone structure configured in the chip test configuration specification. The template filling engine can perform data filling operations on the real-time status association information according to the five-zone data structure configured in the chip test configuration specification. Specifically, the template filling engine can extract metadata fields from the real-time status association information and fill the metadata zone structure of the chip test configuration file according to the metadata fields. For example, metadata fields can include, but are not limited to, version (version number), jobid (workspace ID), repo (configuration item), job_url (workspace link), and cdash_url. Among them, the version field is used to record the version number of the configuration specification for backward compatibility management, and is identified by the version number when the specification is upgraded; the jobid field is a unique identifier for the test task, supports variable substitution, and is used to distinguish different test tasks; the repo field is the associated code repository address, used to trace the source code version corresponding to the test scenario; the job_url field is the URL (Uniform Resource Locator) of the associated chip test general pipeline task, used to trace the generation source of the chip test configuration file; the cdash_url field is the test result dashboard URL, used to view test execution results and history.

[0061] Specifically, the template filling engine can also extract chip hardware environment detection fields from real-time status association information and fill the hardware environment description area structure of the chip test configuration file based on these fields. The description data in the hardware environment description area structure are core differentiating fields from general test configuration files, reflecting the specificity of chip testing. For example, chip hardware environment detection fields may include, but are not limited to, the `target_check_cmd` field and the `system_check_cmd` field. The `target_check_cmd` field may include a list of chip detection commands used to verify the existence and status of the target chip (such as a target AI accelerator card or general-purpose chip). For example, the `lspci` command can be used to detect the vendor ID and device ID of the GCU device. The `system_check_cmd` field may include a list of system environment check commands used to verify whether system-level dependencies such as operating system mount points and kernel versions meet the requirements.

[0062] Specifically, the template filling engine can also extract chip software environment fields from real-time status association information and fill the software environment description area structure of the chip test configuration file according to the chip software environment fields. For example, chip software environment fields may include, but are not limited to, fields such as image (container image), container (container example), package_url (package URL), kmd_install_cmd (driver installation command), docker_launch_cmd (container startup command), container_env_prefix (adding a uniform prefix to environment variables injected into the container from external resources), and download_cmds (package download commands). The `image` field can include the complete address of the container image (including the repository path and version tag); the `container` field can include the container instance name, supporting variable substitution to achieve multi-scenario isolation; the `package_url` field can include the download address of software packages (such as SDKs and toolchains); the `kmd_install_cmd` field can include the installation command for the Kernel Mode Driver (KMD), which includes driver installation parameters such as `--driver -y --no-auto-load`; the `docker_launch_cmd` field can include a list of container startup commands, which include parameters such as mount paths and device mappings; the `container_env_prefix` field can include a prefix for command execution within the container, such as `docker exec -it {container}`, used for concatenating subsequent commands; and the `download_cmds` field can include a sequence of software package download commands, which can be executed sequentially to obtain the required files.

[0063] Specifically, the template filling engine can also extract environment configuration fields from real-time status association information and fill the environment configuration area structure of the chip test configuration file according to the environment configuration fields. For example, environment configuration fields may include, but are not limited to, the host_env_setup (host machine environment settings) field, the container_env_setup (container in-container environment settings) field, and the test_env_type (test environment type identifier) ​​field. The host_env_setup field may include a list of host machine environment setting commands, such as setting environment variables and creating directories; the container_env_setup field may include a list of container in-container environment setting commands, such as installing SDKs and configuring library paths; the test_env_type field may include a test environment type identifier, such as dev (development), CI (Continuous Integration), and prod (production), used to distinguish configuration strategies for different environments.

[0064] Specifically, the template filling engine can also extract test execution fields from real-time status association information and fill the test execution description area structure of the chip test configuration file according to the test execution fields. For example, test execution fields may include, but are not limited to, fields such as test_prefix (test command prefix), tests (test command sequence), and corefile (core dump file path). The test_prefix field can include a common prefix for test commands, such as changing directories or activating environments; the tests field can include a sequence of test commands, which can be executed sequentially; the corefile field can include the path to the core dump file, used for debugging and analysis of crash issues.

[0065] Once the five-zone structure of the preset data structure is filled in, an initial chip test configuration file in dict (a dictionary data structure, essentially a collection of key-value pairs) structure format can be generated.

[0066] The five-zone structure of the aforementioned pre-defined data structure intuitively reflects the dependency hierarchy of the chip testing environment: metadata → hardware → software → environment → execution. Each layer has a clear responsibility, facilitating automated parsing. Fields such as `target_check_cmd` and `kmd_install_cmd` in the chip test configuration file are specialized abstractions for AI chip testing scenarios, filling the gaps in general configuration formats. Simultaneously, the chip test configuration file supports an automatic variable replacement mechanism for placeholders such as `{user}` and `{version}`, enabling chip configuration templates and reuse. All execution-related fields in the chip test configuration file are list types, clearly defining the command execution order and dependencies.

[0067] S330. Standardize and verify the configuration data in the initial chip test configuration file.

[0068] To further ensure the usability and accuracy of the chip test configuration file, after generating the initial chip test configuration file, the configuration data in the initial chip test configuration file can be further standardized and verified to verify whether the configuration data in the initial chip test configuration file conforms to the chip test configuration specifications.

[0069] In an optional embodiment of the present invention, the standardization verification of the configuration data in the initial chip test configuration file may include: verifying the completeness of the required fields in the initial chip test configuration file; verifying the correctness of the field types in the initial chip test configuration file; verifying the validity of the chip-specific fields in the initial chip test configuration file; and verifying the coverage of the necessary fields for the test scenario in the initial chip test configuration file.

[0070] Specifically, the configuration file generation module can use a pattern validator to standardize and validate the configuration data in the initial chip test configuration file, checking field completeness and data types. The pattern validator can verify the completeness of required fields in the initial chip test configuration file. Optionally, required fields may include, but are not limited to, `meta.version` (metadata structure version), `meta.jobid` (the workspace to which the metadata belongs), and `software.image` (a field recording the container image containing the runtime library). Simultaneously, the pattern validator can verify the correctness of field types in the initial chip test configuration file. For example, it needs to verify that the `tests` field type must be `list`, and the `kmd_install_cmd` field type must be `string`. The pattern validator can also verify the validity of chip-specific fields in the initial chip test configuration file, such as verifying whether the `target_check_cmd` field contains AI chip detection commands. Finally, the pattern validator can also verify the coverage of necessary fields for test scenarios in the initial chip test configuration file. Optionally, test scenarios may include, but are not limited to, core dump scenarios, device test scenarios, and library API (Application Programming Interface) test scenarios. Correspondingly, necessary fields for test scenarios can be fields that must be configured for the aforementioned test scenarios.

[0071] Accordingly, if the initial chip test configuration file passes verification, the subsequent process can continue; if the initial chip test configuration file fails verification, an error report can be automatically generated based on the errors detected during the verification process.

[0072] S340. If the initial chip test configuration file is verified, the initial chip test configuration file is serialized to obtain the standardized chip test configuration file.

[0073] If the initial chip test configuration file passes verification, the configuration file generation module can further serialize it using a file serializer, such as serializing the configuration data into JSON and / or YAML format. In an optional embodiment of the invention, during the serialization process of the file serializer, the initial chip test configuration file can be formatted and indented according to a set standard format to improve readability; a configuration file generation timestamp and generation system identifier can also be added to the initial chip test configuration file. After serializing the initial chip test configuration file, the file serializer can output a standardized and highly readable self-describing configuration file, thereby obtaining a standardized chip test configuration file.

[0074] Optionally, the generated standardized chip test configuration file, as an output of the general chip testing pipeline, can be archived in the artifact repository. It can also be associated with test tasks in the general chip testing pipeline via fields such as job_url to test the target chip, or it can be provided to supporting devices for rapid reproduction of the chip testing environment. This embodiment of the invention does not limit the specific application scenarios of the standardized chip test configuration file.

[0075] S350. Parse each data structure of the standardized chip test configuration file to obtain the chip test configuration fields.

[0076] S360. Based on the chip test configuration fields, the pipeline test tasks for each test scenario are automatically executed in a phased manner.

[0077] The above technical solution addresses the problem that existing general-purpose testing pipelines lack a standardized configuration description language specifically for chip testing scenarios, making it difficult to accurately describe and reproduce the chip testing environment. It provides a method for generating domain-specific test configuration files to describe chip testing scenarios. This method uses a hierarchical partitioning structure to fill and organize the real-time status association information of each testing stage in the chip testing process of the general-purpose chip testing pipeline. The complete description information of the chip testing environment is organized into five functional areas, each containing several fields. This allows for a complete and accurate description of the hardware environment, software environment, dependencies, and execution configuration required for chip software stack testing. It achieves structured standardization of field constraints in the chip testing domain and systematic abstraction of domain knowledge related to chip testing reproduction problems. This improves the completeness, accuracy, and standardization of configuration information in the chip test configuration file, facilitating the standardized expression and accurate reproduction of chip testing scenarios.

[0078] Example 3 Figure 4 This is a flowchart of a chip testing method provided in Embodiment 3 of the present invention. This embodiment is a specific embodiment based on the above embodiments. In this embodiment, various specific optional implementation methods for parsing the data structures of the standardized chip test configuration file are given. Correspondingly, as... Figure 4 As shown, the method in this embodiment may include: S410: Obtain standardized chip test configuration files.

[0079] The standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure.

[0080] It is understandable that the generated standardized chip test configuration files need to be parsed and executed to reproduce chip-specific test scenarios. However, current general-purpose configuration parsers cannot recognize the meaning of chip-specific fields such as target_check_cmd and kmd_install_cmd in standardized chip test configuration files, and cannot perform chip-specific field verification processes, such as detecting the presence of AI accelerator cards via LSPCI. Furthermore, general-purpose configuration parsers lack the ability to understand the configuration data of each test stage, including chip hardware detection, driver installation, and container deployment dependencies. Therefore, the chip testing device provided in this embodiment of the invention enhances the parsing capability of chip test configuration information for chip-specific test data.

[0081] Specifically, the chip testing device can obtain standardized chip test configuration files through a configuration parsing module using various optional methods. The core capability of the configuration parsing module is understanding the field constraints and variable substitutions of the chip testing scenario, and it can include three parts: an input interface, internal components, and an output interface. Optionally, the input interface of the configuration parsing module supports three input methods for chip test configuration files, and obtains the chip test configuration file through the configuration loader in the internal components. For example, the configuration loader can configure the path of the local chip test configuration file through the `receipt_path` field (a custom field referring to the local or server path where the receipt file is stored), such as " / path / to / receipt.json," and read the chip test configuration file from the local file system through the `load_from_file(path)` method (a custom or context-dependent method for loading data from a specified file path). This is suitable for use cases where test engineers have already downloaded the chip test configuration file locally, or where the chip test configuration file is automatically generated by a script. The configuration loader can throw an exception when the chip test configuration file does not exist, and can report syntax problems when the format is incorrect.

[0082] Alternatively, the configuration loader can remotely configure the chip test configuration file URL via the `receipt_url` field (typically a URL pointing to a receipt, used for programmatic access or verification of the receipt content), and download the chip test configuration file from the remote server using the `load_from_url(url)` method (a custom helper function for downloading and loading resources from a specified URL). This is suitable for use cases where the chip test configuration file is stored in the build artifact repository and can be directly accessed via a URL. The configuration loader can retry when a network error occurs and throw an exception if the download fails.

[0083] Alternatively, the configuration loader can maintain a tag mapping table that records the mapping relationship between chip test configuration files and preset tag strings. Accordingly, the configuration loader can specify a tag string through the `tag_string` field (usually a field in some encoding, format, or metadata used to identify a tag in string form), and use the `load_from_tag(tag)` method (a custom deserialization / loading method used to restore a state or object from storage based on the tag) to query the tag mapping table based on the specified tag string to obtain the path to the corresponding chip test configuration file. Users can quickly locate and download the chip test configuration file without having to remember the complete configuration file path. This method of quickly locating and obtaining the chip test configuration file via tag string eliminates the need to manually specify the configuration file path, making it suitable for scenarios that quickly reproduce common test scenarios. The configuration loader can throw an exception if the specified tag string does not exist. Optionally, during the generation of standardized chip test configuration files, a corresponding tag string can be configured for each completed chip test configuration file as needed.

[0084] S420. Parse and verify each data structure of the standardized chip test configuration file to obtain the initial chip test configuration field.

[0085] The initial chip test configuration field can be the field obtained by the chip test device through preliminary parsing of the various data structures of the standardized chip test configuration file.

[0086] The configuration parsing module's internal components may also include a pattern validator, a variable substitute, and an output formatter. The configuration parser can parse the various data structures of the acquired chip test configuration file, including the metadata area structure, hardware environment description area structure, software environment description area structure, environment configuration area structure, and test execution description area structure, to obtain the parsed fields. Furthermore, the configuration parsing module uses the pattern validator to verify the fields obtained from parsing each data structure of the chip test configuration file. During this process, the configuration parsing module can also perform automatic variable substitution operations on the parsed fields using the variable substitute.

[0087] In an optional embodiment of the present invention, the parsing and verification of the data structures of the standardized chip test configuration file may include: parsing the chip detection command field and the driver installation command field according to the target data structure of the standardized chip test configuration file; automatically detecting target replacement variables according to the pipeline test task of the current test scenario, and automatically replacing the target placeholders in the parsed fields according to the target replacement variables; and verifying the standardization of required fields, field types, chip-specific fields, and target dependencies.

[0088] Specifically, after the configuration parsing module obtains the chip test configuration file through the configuration parser, it can parse the target data structure of the chip test configuration file. For example, the configuration parser parses the hardware environment description area structure to obtain the chip detection command field `target_check_cmd`, and parses the software environment description area structure to obtain the driver installation command field `kmd_install_cmd`. The variable substitute can handle placeholder variables in the configuration file. Specifically, during testing, the variable substitute can automatically detect target substitution variables in the test environment and automatically replace the target placeholders in the parsed fields based on the detected target substitution variables. For example, target placeholders in the chip test configuration fields can include, but are not limited to, `{user}` (representing user) and `{version}` (representing version), and correspondingly, target substitution variables in the test environment can include, but are not limited to, `{'user': 'zhangsan', 'version': 'v1.0'}`. Optionally, the variable substitute can iterate through all string type fields in the chip test configuration file to find placeholder patterns to determine the target placeholder. If the target substitution variable is empty, the variable substitute can use a default value or throw a warning. For example, assuming the original value of the chip test configuration field is: container: "{user}_test_{version}", the variable substitute will update it to: container: "zhangsan_test_v1.0" after performing the variable substitution.

[0089] Specifically, the configuration parsing module can use a pattern validator to verify whether the data structures and corresponding fields of the chip test configuration file conform to the chip test configuration specifications. For example, when verifying the conformity of required fields, the pattern validator can verify the existence of required fields such as `meta.version`, `meta.jobid`, and `software.image`; when checking the conformity of field types, it can verify whether the `tests` field is a list type and whether `kmd_install_cmd` is a string type, etc. When verifying the conformity of chip-specific fields, it can verify whether the format of chip test domain-specific fields such as `target_check_cmd` and `kmd_install_cmd` is correct. Simultaneously, the pattern validator can also check the conformity of dependencies. For example, if the pattern validator determines that the `corefile` field is not empty, then a download command must be provided. If the verification fails, the pattern validator can return detailed error information, such as which fields are missing and which field types are incorrect. After verification, the pattern validator can output a verification result object including whether the verification passed and / or error list information.

[0090] It is evident that the verification content of the pattern verifier and the content that needs to be verified during the generation process of the chip test configuration file have some overlap and some differences.

[0091] S430. Extract chip domain-specific fields from the initial chip test configuration fields.

[0092] S440. Perform structured configuration on the chip-specific fields to obtain the chip test configuration fields.

[0093] Correspondingly, the configuration parsing module can further filter the parsed initial chip test configuration fields using the output formatter. This allows it to extract chip-specific fields such as `target_check_cmd` and `kmd_install_cmd` from the full set of fields and organize them into structured, dedicated configuration information. Specifically, the output formatter can extract the five-section structure fields of the chip test configuration file to generate execution plans for the test commands at each stage based on the extracted fields. These plans can be categorized according to the eight-stage environment build process and ultimately generate the working directory path based on the jobid. In other words, the output formatter can output internal configuration objects for use by other modules, such as the scenario management module and the phased environment build module.

[0094] S450. Based on the chip test configuration fields, the pipeline test tasks for each test scenario are automatically executed in a phased manner.

[0095] The configuration parsing module's output interface can output the original chip test configuration file and the internal representation of the chip test configuration fields generated by parsing it. It can also output the verification results of the chip test configuration fields for use by other functional modules in the core processing layer. If any step fails, the output interface will throw an exception and provide detailed error information. Correspondingly, other functional modules in the core processing layer can automatically execute pipeline test tasks for each test scenario in a phased manner based on the chip test configuration fields output by the configuration parsing module.

[0096] In a specific example, the following is a formal definition of the configuration parsing module of the core processing layer within a chip testing device: ConfigParserModule { / / Input interface - supports multiple input methods input: { receipt_path: string / / Local file path receipt_url: string / / Remote URL tag_string: string / / Preset tag (e.g., topsinference:3.6.105) } / / Internal components components { / / Configuration loader ConfigLoader { load_from_file(path) → dict load_from_url(url) → dict load_from_tag(tag) → dict / / Load from a pre-defined template } / / Variable Substitute (Core Component) VariableReplacer { / / Supported variable types supported_variables: { "{user}": getpass.getuser(), "{version}": tag_version, "{topsrider_url}": package_url } replace_variables(config) → dict } / / Preset Tag Manager TagManager { tags: { "topsinference": {path, description, versions}, "vllm": {path, description, versions}, "train-ds": {path, description, versions} } has_tag(tag) → bool get_versions(tag) → list get_latest_version(tag) → string get_path(tag, version) → string } / / Field extractor FieldExtractor { get_jobid(config) → string get_container(config) → string get_image(config) → string get_tests(config) → list / / ... Other field extraction methods } } / / Output interface - structured configuration information output: ParsedConfig { jobid: string container: string image: string receipts: dict / / Complete chip test configuration file work_dir: string / / Working directory release_dir: string / / Release directory } } The above technical solution parses and verifies the chip test configuration file through a chip testing device. It can identify and process special fields in the chip testing scenario, supports direct input of configuration files in two ways: local files and remote URLs, as well as indirect location of configuration files through preset tags, which can improve the ease of use of the chip testing device. It supports configuration file templates and configuration reuse through variable replacement. The integrity and correctness of the configuration file are ensured through a pattern validator.

[0097] Example 4 Figure 5 This is a flowchart of a chip testing method provided in Embodiment 4 of the present invention. This embodiment is based on the above embodiments and is further specified. In this embodiment, various specific optional implementation methods for automating pipeline testing tasks in various test scenarios are given. Correspondingly, as... Figure 5 As shown, the method in this embodiment may include: S510: Obtain standardized chip test configuration files.

[0098] The standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure.

[0099] S520. Parse each data structure of the standardized chip test configuration file to obtain the chip test configuration fields.

[0100] S530. Create and maintain independent test workspaces for pipeline test tasks in each of the aforementioned test scenarios.

[0101] Currently, general-purpose chip testing pipelines often face difficulties in managing multiple test scenarios in parallel when implementing chip testing tasks. When troubleshooting different problems, different test environments need to be switched, and there may be mutual contamination between test environments. There is also a lack of a test scenario isolation mechanism based on jobid.

[0102] To solve the above-mentioned technical problems, for example, such as Figure 2 As shown, the core processing layer of the chip testing device can also be configured with a scenario management module to manage the lifecycle of multiple test scenarios and achieve mutual isolation between test scenarios. Optionally, the test workspace can be identified by a jobid and stored in a cache directory. Specifically, the scenario management module can create and maintain independent test workspaces for pipeline test tasks of each test scenario. A pipeline test task can use a jobid to identify a test workspace, and can manage the lifecycle of multiple test scenarios, including the creation, running, pausing, and destruction of test scenarios, supporting parallel processing and second-level switching of multiple test scenarios. The scenario management module can use various different types of data structures to define the core data structures required for scenario management and can provide various types of scenario management methods.

[0103] In a specific example, the first data structure can be an adaptive data structure for a work scenario, representing complete information about a single test scenario. The meanings of the fields in this adaptive data structure can be as follows: `jobid` field: A unique identifier for the task, derived from the `meta.jobid` field in the configuration file, used to distinguish different test scenarios and as part of the working directory name; `receipt_path` field: The local path of the configuration file, used to record the location of the configuration file corresponding to this test scenario, for subsequent configuration reloading; `container` field: The associated Docker container name, used to record the container instance name used by this test scenario, derived from the `software.container` field in the chip test configuration file, allowing quick entry into the corresponding container when switching scenarios; `status` field: The current status of the scenario (enumeration type), with possible values ​​including: `CREATED`: The scenario has been created and the environment has been built, but the container is not running; `RUNNING`: The container is running and can be entered at any time; `PAUSED`: The container has been paused (via Docker). (pause); STOPPED: The container has stopped; the status field can be used to determine the availability of the scene and decide whether the container needs to be restarted; the created_at field: the scene creation timestamp, used to record the creation time of the scene, and can also be used to automatically clean up expired scenes; the release_dir field: the working directory path of the scene, used to store all files such as the scene's configuration files, core dumps, and logs.

[0104] In a specific example, the second data structure can be the data structure of the adaptation scenario registry. This data structure can manage global test scenario information, and the meanings of each field are as follows: cache_dir field: cache root directory path, the working directory of all test scenarios is stored in this root directory; latest_setup_receipt field: the chip test configuration file path used by the most recent setup command, used to record the currently active test scenarios. Commands without parameters such as efdbg enter will enter this scenario. This field will be updated every time the efdbg setup or efdbg select command is executed; cache_dirs field: a list of historical cache directories, used to record all previously created test scenario directories for use by the efdbg list command. The data type of this field is a list, and each element is the directory path of a test scenario.

[0105] In a specific example, the third data structure can be an adaptation of the scenario status file. This data structure can be stored in the job_status.json file under each scenario directory, recording the scenario's build status. The meanings of each field are as follows: setup_efdbg field: Whether the scenario has completed environment build. Its optional values ​​include "yes" or "no". It is used to determine whether the test scenario has completed the setup process to avoid duplicate builds. Its update timing is: set to "yes" after the efdbgsetup command successfully completes; receipt_url field: The original URL of the configuration file (if the configuration file comes from a remote location). It is used to record the source of the chip test configuration file for tracing and re-downloading; receipt_path field: The local path of the configuration file. It is used to record the location where the configuration file is saved in the working directory; release_dir field: The absolute path of the working directory. It is used to record the working directory location of this test scenario; container field: The associated container name. It is used to record the container instance name used by this test scenario.

[0106] In a specific example, the scenario management module can provide a method for setting up a work scenario: cmd_setup, corresponding to efdbg setup.<config_file> The command, and the execution flow of this method, are as follows: Step 1: Load and parse the chip test configuration file, call the parse() method of the configuration parsing module (usually referring to the operation of parsing a string or text in a specific format and converting it into the corresponding data type or structure) to verify the validity of the chip test configuration file, and extract the jobid field as the test scenario identifier.

[0107] Step 2: Create a working directory based on jobid: Copy the chip test configuration file to the working directory, initialize the test workspace status file: job_status.json file, setup_efdbg: "no".

[0108] Step 3: Build and execute the phased test environment: Call the build() method (creation method) of the phased environment building module to build the environment according to the eight-stage process. The eight stages can be various stages such as downloading the core dump, downloading the software package, system environment check, chip hardware detection, host environment setting, driver installation, container startup, and container environment setting.

[0109] Step 4: Update the test scenario status: Update the job_status.json file: setup_efdbg: "yes", update the recently used json scenario configuration file: WorkspaceRegistry.latest_setup_receipt to the current configuration file path, add the test scenario to the list of all scenario cache directories: WorkspaceRegistry.cache_dirs, return value: true (success) or false (failure).

[0110] In a specific example, the scene management module can also provide a method to list all scenes: cmd_list, corresponding to the efdbg list command. The execution flow of this method is as follows: Step 1: Scan the cache directory: Traverse all subdirectories under cache_dir. Each subdirectory represents a scenario, and the directory name is the jobid.

[0111] Step 2: Read test scenario status: Read the job_status.json file in the directory of each test scenario, extract information such as jobid, container, receipt_path and setup_efdbg, and check the container status.

[0112] Step 3: Return the scenario list: list[WorkspaceInfo]. Each WorkspaceInfo element in the list contains information such as the scenario index, jobid, status, and creation time.

[0113] In a specific example, the scenario management module can also provide a method for selecting a work scenario: cmd_select, corresponding to the efdbg select command. The execution flow of this method is as follows: Step 1: Obtain test scenario information based on the index: Get the test scenario directory of the specified index from the cache_dirs list, read the job_status.json of the test scenario directory, and extract the receipt_path field.

[0114] Step 2: Update active scenario: Update WorkspaceRegistry.latest_setup_receipt to the configuration file path for this scenario. Subsequent commands such as efdbg enter and efdbg run will automatically use this test scenario. Return value: true (success) or false (scenario does not exist).

[0115] In a specific example, the scenario management module can also provide a method for cleaning up work scenarios: cmd_clean, corresponding to the efdbg clean or efdbg clean command. The execution flow of this method is as follows: Step 1: Locate the test scenario: Find the corresponding test scenario directory based on the test space identifier workspace_id (i.e., jobid or index). If the "--all" parameter is specified, all test scenarios will be located.

[0116] Step 2: Stop and delete the container: Execute the command `docker stop {container}` to stop the container, and execute the command `docker rm {container}` to delete the container instance.

[0117] Step 3: Delete the working directory of the test scenario and remove the test scenario from WorkspaceRegistry.cache_dirs. Return value: true (success) or false (scenario does not exist).

[0118] In a specific example, the scenario management module can also provide an automatic method for cleaning up expired scenarios: `auto_clean_up`. This method is automatically triggered when the `efdbg setup` command is executed, and the execution flow is as follows: Step 1: Scan all scenarios: Traverse all test scenario directories under cache_dirs and read the created_at timestamp of each test scenario.

[0119] Step 2: Clean up expired scenarios: If the current time minus the created_at time is greater than a preset threshold, the test scenario is considered expired. The cmd_clean() method can be called to clean up the test scenario. Return value: The number of scenarios cleaned.

[0120] The aforementioned scenario management module provides test scenario isolation functionality, with each test scenario having its own independent working directory and container instance, ensuring no interference between them; by updating the active scenario pointer, test scenarios can be switched in seconds without rebuilding the environment; scenario status is persisted through the job_status.json file, supporting breakpoint resume and status persistence; and automatic cleanup effectively prevents the cache directory from growing indefinitely.

[0121] In a specific example, the following is the formal definition of the scene management module: WorkspaceManagerModule { / / Data Structure data_structures { Workspace { jobid: string / / Task identifier (from configuration file) receipt_path: string / / Configuration file path container: string / / The name of the associated container status: enum[CREATED, RUNNING, PAUSED, STOPPED] created_at: timestamp release_dir: string / / Working directory } WorkspaceRegistry { cache_dir: string / / Root directory for cache (e.g., ~ / efdbg_cache / ) latest_setup_receipt: string / / Path to the most recently set configuration file cache_dirs: list / / List of historical cache directories } JobStatus { setup_efdbg: string / / Sets the status (yes / no) receipt_url: string / / Configuration file URL receipt_path: string / / Local configuration file path release_dir: string / / Release directory container: string / / Container name } } / / Operation Interface operations { / / Set up the work scenario (corresponding to the setup command) cmd_setup(receipt: string) → bool { 1. Load and parse the configuration file 2. Create the working directory (cache_dir / jobid / ) 3. Perform phased environment setup 4. Update JobStatus } / / List all scenarios (corresponding to the list command) cmd_list() → list[WorkspaceInfo] { 1. Scan subdirectories under the cache directory 2. Read the job_status.json file from each directory. 3. Return to the scene list } / / Select the work scenario (corresponding to the select command) cmd_select(index: int) → bool { 1. Obtain the configuration file path based on the index. 2. Update latest_setup_receipt } / / Clean up the work environment (corresponding to the clean command) cmd_clean(workspace_id: string, all: bool) → bool { 1. Stop the associated container 2. Delete the working directory 3. Supports cleaning up single or all scenes. } / / Automatically clean up expired scenes auto_clean_up(outdate_days: int) → int { 1. Scan the cache directory 2. Delete scenarios that exceed a specified number of days. } } } S540. Within each of the test workspaces, an eight-stage test environment reconstruction process is executed according to the chip test configuration fields to obtain the reconstructed test environment corresponding to each pipeline test task.

[0122] Reconstructing the test environment can mean rebuilding the test environment that was previously reproduced.

[0123] Currently, general-purpose chip testing pipelines often lack chip-specific verification during the environment building process when implementing chip testing tasks. This makes it impossible to execute the target_check_cmd command to verify the existence of the chip, unable to automatically process the driver installation parameters in kmd_install_cmd, and lacking the ability to build in stages and resume from breakpoints.

[0124] To address the aforementioned technical issues, exemplarily, such as Figure 2 As shown, the core processing layer of the chip testing device can also be configured with a phased environment construction module. This module employs a phased pipeline design and, based on the chip test configuration fields parsed from the chip test configuration file, automatically executes an eight-stage environment reconstruction process for each test workspace requiring pipelined testing tasks. This allows for rapid reproduction of the reconstructed test environment corresponding to each pipelined testing task. Optionally, the eight-stage test environment reconstruction process can include stages such as downloading core dumps, downloading software packages, system checks, hardware detection, host environment settings, driver installation, container startup, and container environment settings. Each stage of the test environment reconstruction process can correspond to a portion of the chip test configuration fields.

[0125] In an optional embodiment of the present invention, the step of performing an eight-stage test environment reconstruction process according to the chip test configuration fields in each of the test workspaces may include: downloading the core dump file according to the first chip test configuration field and saving it to the working directory of the corresponding test workspace; reading the software package list according to the second chip test configuration field and downloading each software package in sequence; reading the system environment check command list according to the third chip test configuration field and executing each system environment check command in sequence; reading and executing the chip detection command list according to the fourth chip test configuration field, parsing the chip detection command output value, and extracting target key information; reading the environment setting command list according to the fifth chip test configuration field and executing each environment setting command in sequence to update the host environment variables and create a directory; reading and executing the driver installation command according to the sixth chip test configuration field to install the chip's kernel driver module; reading and executing each container startup command in the container startup command list according to the seventh chip test configuration field and storing and recording the container ID information; reading the container internal environment setting command according to the eighth chip test configuration field, adding a container execution prefix to each of the container internal environment setting commands, and executing each of the container internal environment setting commands in sequence.

[0126] The first chip test configuration field can be used to complete part of the test environment reconstruction operation in the first stage of the test environment reconstruction process, namely the core dump file download stage. The second chip test configuration field can be used to complete part of the test environment reconstruction operation in the second stage, namely the software package download stage. The third chip test configuration field can be used to complete part of the test environment reconstruction operation in the third stage, namely the system environment check stage. The fourth chip test configuration field can be used to complete part of the test environment reconstruction operation in the fourth stage, namely the chip hardware detection stage. The fifth chip test configuration field can be used to complete part of the test environment reconstruction operation in the fifth stage, namely the host environment setup stage. The sixth chip test configuration field can be used to complete part of the test environment reconstruction operation in the sixth stage, namely the driver installation stage. The seventh chip test configuration field can be used to complete part of the test environment reconstruction operation in the seventh stage, namely the container startup stage. The eighth chip test configuration field can be used to complete part of the test environment reconstruction operation in the eighth stage, namely the container environment setup stage. The key information of the target can be related hardware device information of the chip to be tested, such as including but not limited to chip device ID and quantity.

[0127] Figure 6 This is a schematic diagram of an eight-stage test environment reconstruction process provided in Embodiment 4 of the present invention. In a specific example, such as... Figure 6 As shown, the eight-stage test environment reconstruction process mainly includes the following stages: downloading the core dump file, downloading the software package, system environment check, chip hardware detection, host environment setup, driver installation, container startup, and container environment setup. The chip testing device can use this eight-stage test environment reconstruction process to implement each test scenario for chip reproduction.

[0128] Correspondingly, such as Figure 6 As shown, in the first phase of the core dump file download process, the required first chip test configuration field can be the `execution.corefile` field, which is a query field used to retrieve the core dump file. In the first phase, if the phased environment build module determines that the `corefile` field is not empty, it indicates a crash has occurred in the chip test pipeline. At this point, the phased environment build module can parse the URL of the `corefile` field and use command-line tools or `wget` to download the core dump file to the working directory of the corresponding test workspace. After downloading, the phased environment build module can also verify the integrity of the downloaded core dump file, for example, by checking the file size and MD5 (Message-Digest Algorithm 5) checksum. The first phase returns `true` (success) or `false` (download failed). This phase can provide the core dump file for subsequent crash analysis using GDB (GNU Debugger) during testing.

[0129] Correspondingly, such as Figure 6 As shown, in the second phase of the software package download process, the required second chip test configuration field can be `software.download_cmds`, which can represent the commands used to download the software. In the second phase, the phased environment building module can read the software package list, i.e., the `download_cmds` (download command sequence) list, and execute each download command sequentially, thus downloading the software packages in order. Before downloading, the existence of the downloaded software packages can be verified. The return value of the second phase is `true` (all commands succeeded) or `false` (any command failed). This phase can download various types of software packages, such as the chip's SDK, toolchain, and test data.

[0130] Correspondingly, such as Figure 6 As shown, in the third-stage system environment check process, the required third-chip test configuration field can be the `hardware.system_check_cmd` field. This field represents the hardware system check command and can be used to check the system environment. In the third stage, the phased environment building module can read the `system_check_cmd` (execute system status check commands) list to execute each check command, verifying dependencies such as system mount points and kernel versions. If the phased environment building module determines that any check has failed, it aborts the environment building process and reports an error. The return value of the third stage is `true` (check passed) or `false` (check failed). This stage ensures that the host system meets the basic dependencies of various chip tests, such as specific kernel versions and mount points.

[0131] Correspondingly, such as Figure 6 As shown, in the fourth stage of the chip hardware detection process, the required fourth chip test configuration field can be the `hardware.target_check_cmd` field. This field represents the status or performance of the hardware target being checked and can be used to check chip hardware information. In the fourth stage, the phased environment construction module can read the `target_check_cmd` (chip detection command) list, execute each chip detection command, verify the existence of the target chip, and parse the output values ​​of the chip detection commands to extract key target information such as device ID and quantity. If the detection fails (the chip device does not exist), the phased environment construction module can abort the environment construction process and prompt the user. The return value of the fourth stage is `true` (chip detected) or `false` (chip not detected). This stage is a dedicated step for chip testing scenarios, and the general testing framework does not include this type of hardware detection logic. For example, this stage can implement the detection of devices with a specific vendor ID using the `lspci` command.

[0132] Correspondingly, such as Figure 6 As shown, in the fifth stage of the host environment setup process, the required fifth chip test configuration field can be the `environment.host_env_setup` field. This field represents the environment variables and configurations set in the host environment and can be used to set up the host environment. In the fifth stage, the phased environment building module can read the `host_env_setup` (environment setup command) list to execute each environment setup command in sequence, update host environment variables, and create directories, etc. The return value of the fifth stage is `true` (all commands succeeded) or `false` (any command failed). This stage can prepare the host environment for chip driver installation, such as setting library paths and creating necessary directories.

[0133] Correspondingly, such as Figure 6 As shown, in the sixth stage of the driver installation process, the required sixth chip test configuration field can be the `software.kmd_install_cmd` field. This field represents the kernel-mode driver (KMD) installation command and can be used to set up the host environment. In the sixth stage, the phased environment build module can read the `kmd_install_cmd` string (kernel-mode driver installation command) to execute the driver installation command, install the chip's kernel driver module (KMD), and verify whether the driver is loaded successfully. For example, the driver module can be checked using the `lsmod` command (used to list all modules currently loaded into the kernel). If the driver installation fails, the phased environment build module can abort the environment build process and report an error. The return value of the sixth stage is `true` (driver installation successful) or `false` (installation failed). This stage is the core step of the chip testing scenario. The `kmd_install_cmd` field can contain complete parameters for driver installation, such as `--driver` indicating that only the driver is installed, `-y` indicating automatic confirmation, and `--no-auto-load` indicating that the driver is not loaded automatically.

[0134] Correspondingly, such as Figure 6 As shown, in the seventh stage of the container startup process, the required seventh-stage chip test configuration field can be the `software.docker_launch_cmd` field. This field represents the command to start a Docker container and can be used to configure the container startup settings. In the seventh stage, the phased environment building module can read the `docker_launch_cmd` (container startup command) list, execute each container startup command sequentially, and wait for the container to start. For example, the container status can be checked using the `docker ps` command (the command in the Docker command line used to list currently running containers) to determine if the container has started successfully. Simultaneously, the phased environment building module can record the container ID for use by subsequent commands. The return value of the seventh stage is the `ContainerID` (container instance ID). This stage can create isolated test environments, mount chip devices such as AI accelerator cards, set network modes, and mount SDK directories, etc.

[0135] Correspondingly, such as Figure 6 As shown, in the eighth stage of the container environment setup process, the required eighth chip test configuration field can be the `environment.container_env_setup` field. This field represents the environment variables set when the container starts, and can be used to set environment variables at container startup. In the eighth stage, the phased environment build module can read the `container_env_setup` (container environment setup commands) list and add a container execution prefix to each command. The container execution prefix can be obtained from other container-related fields, and the container execution prefix can be, for example, "docker exec -it {container}". The phased environment build module can execute each container environment setup command sequentially to install the SDK, configure library paths, and install Python dependencies within the container, and verify whether the environment setup is successful, such as checking whether critical files exist. The return value of the eighth stage is `true` (all commands succeeded) or `false` (any command failed). This stage can complete the final preparation work such as chip SDK installation and environment variable setting within the container.

[0136] Optionally, the phased environment construction module can employ a checkpoint mechanism. This mechanism records the completion status of each stage and supports various skip functions based on the recorded completion status. For example, the checkpoint mechanism can support skipping functions such as skipping driver installation, skipping system checks, skipping host machine settings, skipping debug symbols, and skipping core dumps. This effectively skips completed steps and operations during the rebuilding of the test environment, significantly improving chip testing efficiency.

[0137] In summary, the phased environment building module, starting from downloading the core dump and software packages, constructs the corresponding test environment through various stages, including system checks, hardware detection, host environment setup, driver installation, container startup, and container environment setup, before finally entering test execution. Each stage of the phased environment building module corresponds to the relevant configuration fields in the chip test configuration file, supports a checkpoint mechanism, and writes the completed phase to the job_status.json file. Completed phases are automatically skipped upon re-execution, and breakpoint resumption is supported. It also supports multiple skip options, such as skipping driver installation, skipping system checks, and skipping host settings.

[0138] S550. In the refactored test environment, the corresponding pipeline test tasks are automatically executed according to the target test command and the target test case.

[0139] The target test command and the target test case are obtained based on the chip test configuration fields. The target test command can be a command applicable to pipeline test tasks. The target test case can be a test case capable of testing pipeline test tasks.

[0140] For example, such as Figure 2 As shown, the core processing layer of the chip testing device can also be configured with a test execution module (also known as a test case management module) to manage the execution of test cases. It supports regular expression matching, environment variable coverage, and interactive mode, and is responsible for executing the test list in the chip test configuration file, entering the container interactive mode (enter), and other functions related to test execution.

[0141] In an optional embodiment of the present invention, the step of automatically executing the corresponding pipeline test task according to the target test command and the target test case in the reconstructed test environment may include: filtering chip test associated fields from the chip test configuration fields and determining the test case operation method; filtering the target test command from the chip test associated fields according to the task type of the pipeline test task, and filtering the target test case from the test case operation method; automatically executing the corresponding pipeline test task according to the target test case using the target test command; and storing and managing test execution logs during the automated execution of the corresponding pipeline test task; wherein the test case operation method includes a test case running method, a container interaction mode entering method, a command sequence display method, and a crash stack display method.

[0142] Among them, the chip test associated fields can be fields related to chip testing.

[0143] In this embodiment of the invention, optionally, the test execution module can be used to execute test execution steps, manage test case operation methods, and maintain the log recorder. Specifically, during the execution of test execution steps, the test execution module can filter the parameters related to test execution in the chip test configuration fields parsed from the standardized chip test configuration file to determine the chip test associated fields. For example, the chip test associated fields may include the `receipt_keyword` field, the `test_prefix` field, the `replace_test_regex` field, and the `overrides` field. The `receipt_keyword` field corresponds to the field name in the chip test configuration file, with a fixed value of "tests", used to indicate the extraction of the test command list from the `tests` field of the chip test configuration file. The `test_prefix` field represents the common prefix of the test commands, used to automatically add a prefix before each test command. For example, if `test_prefix="cd / workspace"` and `tests=["pytest test_a.py"]`, then the actual executed test command is "cd / workspace && pytest test_a.py". The `replace_test_regex` field represents the regular expression used to filter test cases. It can be specified using the `-R` or `--tests-regex` parameter of the `efdbg run` command (which specifies that only test cases whose test names match the given regular expression should be executed). For example, if `replace_test_regex="test_conv"` and `tests=["pytest test_conv.py", "pytest test_pool.py"]`, then only `pytest test_conv.py` will be executed. The `overrides` field represents the list of environment variable overrides. It can be specified using the `-O` or `--override` parameter of the `efdbg run` command (which forces overrides of default configurations, test parameters, or behaviors). It overrides environment variables within the container by adding an `export` statement before the test command.

[0144] The test execution module can manage various types of test case operation methods and parse the task type of pipeline test tasks. Then, based on the specific task type, it can filter the required target test commands from the chip test association fields and filter the required target test cases from the test case operation methods. The target test commands are then used to automatically execute the corresponding pipeline test tasks based on the target test cases.

[0145] In a specific example, the test execution module can provide a method `cmd_run` to run test cases, which corresponds to `efdbg run`.<config_file> The execution flow of the [options] command and the cmd_run method is as follows: Step 1: Call the `cmd_setup()` command in the scenario management module to set up the environment. If the test scenario to be set up already exists and the environment has been built, the environment building step can be skipped; otherwise, the eight-stage test environment reconstruction process will be executed.

[0146] Step 2: Extract the tests list from the chip test configuration file. Specifically, the test execution module can read the list of test commands from the tests field of the chip test configuration file.

[0147] Step 3: If the user specifies the "--tests-regex" parameter, then the matching tests are filtered. Specifically, the test execution module can use regular expressions to match test commands and only keep the matching tests. For example, if the regular expression is "conv", then only the test "pytest test_conv.py" will be kept.

[0148] Step 4: Execute the test commands sequentially within the container. Specifically, the test execution module can add a `test_prefix` prefix to each test command, and use the container execution prefix to execute each test command in sequence, outputting test logs to the console and log files in real time.

[0149] Step 5: Record execution logs. Specifically, all test commands and outputs can be recorded to the run_log file, including the exit code for each test, such as success or failure.

[0150] The return value of the cmd_run method can be a test result object, which may include, but is not limited to, the total number of tests, the number of successes, the number of failures, and the log path.

[0151] In a specific example, the test execution module can provide a method `cmd_enter` to enter the container's interactive mode, which corresponds to `efdbg enter`.<config_file> The execution flow of the command, cmd_enter method, is as follows: Step 1: Check if the container exists. Specifically, the test execution module can read the `container` field from `job_status.json` and execute the `docker ps -a` command to check the container status. If the container does not exist or has stopped, the test execution module can report an error.

[0152] Step 2: Obtain the working directory. The test execution module can read the release_dir field of the release directory from job_status.json, switch to the working directory, and make it easier for users to access configuration files, logs, etc.

[0153] Step 3: Execute `docker exec` (an instruction used to execute new commands inside an already running container) to enter the container. The test execution module can execute the command `docker exec -it {container} bash` to enter the container's interactive shell (a shell refers to a command-line interpreter and its scripting language, used to automate system-level operations in the test process). Users can manually execute debugging commands, view files, and run GDB, etc. After the user exits the shell using the exit command, the container continues to run.

[0154] The cmd_enter method returns an interactive session called ShellSession.

[0155] In a specific example, the test execution module can provide the `show_commands` method to display the command sequence. This method corresponds to the `efdbg show -c` command, and the execution flow of the `show_commands` method is as follows: Step 1: Traverse all build steps. The test execution module can read all commands executed in the eight-stage test environment rebuild process, such as extracting command records from log files.

[0156] Step 2: Generate an executable shell script. The test execution module can organize all commands into an executable bash script in execution order. Add comments to indicate the name of each stage, such as "#Stage 1: Download core dump", and output to the console or save it as a script file.

[0157] The `show_commands` method returns a string containing a sequence of commands, which can help users understand the complete process of environment setup or manually execute certain steps for debugging.

[0158] In a specific example, the test execution module can provide a method called `show_backtrace` to display the crash stack trace. This method corresponds to the `efdbg show -b` command, and the execution flow of the `show_backtrace` method is as follows: Step 1: Check the corefile directory. Specifically, the test execution module can check if a core dump file exists in the working directory. If it does not exist, it will prompt the user "No core dump file found".

[0159] Step 2: Execute the `gdb bt -` (short for the backtrace command, used to display the function call stack of the current thread) command on each core dump file, and then execute gdb. <program> <corefile>The `-batch -ex "bt"` command is used with gdb. <program> <corefile>The `-batch -ex "bt"` command loads executable files non-interactively using GDB in automated tests. <program>and core dump files <corefile>It automatically prints the command that exits immediately after printing the call stack. Furthermore, the test execution module can extract the crash stack, parse the GDB output, extract key information such as the crash location and function call stack, and format the output to the console.

[0160] The `show_backtrace` method has no return value and outputs directly to the console, allowing you to quickly view the crash stack without having to manually start GDB.

[0161] In this embodiment of the invention, the test execution module can also manage test execution logs through a logger. These test execution logs can be logs generated during the pipelined test task's testing process. For example, the logger can manage the log directory path through the `log_dir` field, where all log files can be stored; manage the environment build log file path through the `setup_log` field, used to record all commands and outputs of the eight-phase environment build; and manage the test execution log file path through the `run_log` field, used to record the execution commands, outputs, and exit codes of test cases. For example, the logger can also append log content to the log file using the `write(line)` method, and simultaneously output it to the console; and generate a timestamped log file path using the `get_logger_path(type)` method, returning the path of the corresponding log file based on its type, thus generating an independent log file for each pipelined test task's execution for easy traceability.

[0162] In summary, the test execution module can provide a test filtering mechanism, specifically by matching test cases using regular expressions to achieve flexible execution of test subsets; it supports temporary adjustments to the test environment without modifying configuration files, achieving environment variable coverage; it allows entry into the container through relevant methods, supporting manual debugging and problem analysis, and enabling interactive debugging; and it generates re-executable scripts and exports command sequences for easy manual reproduction.

[0163] In a specific example, the following is the formal definition of the test execution module: TestCaseManagerModule { / / Test execution steps StepTest { receipt_keyword: "tests" test_prefix: string / / Prefix for test commands replace_test_regex: string / / Regular expression for matching test cases overrides: list / / List of environment variable overrides } / / Test case operations operations { / / Run test cases (corresponding to the run command) cmd_run(receipt: string) → TestResult { 1. Call cmd_setup() to set up the environment. 2. Extract the list of tests from the configuration. 3. If test_regex exists, filter out matching tests. 4. Execute the test commands sequentially within the container. 5. Record execution logs. } / / Enter container interactive mode (corresponding to the enter command) cmd_enter() → ShellSession { 1. Check if the container exists. 2. Obtain the working directory 3. Execute `docker exec` to enter the container. } / / Display the command sequence (corresponding to the show -c command) show_commands() → string { 1. Traverse all build steps 2. Generate an executable shell script } / / Display the crash stack trace (corresponding to the show -b command) show_backtrace() → void { 1. Check the corefile directory 2. Execute gdb bt on each core file. } } / / Execution Log Logger { log_dir: string / / Log directory (workspace / logs / ) setup_log: string / / Sets the log run_log: string / / Run log write(line) → void get_logger_path(type) → string / / Generates a log path with timestamps. } } In an optional embodiment of the present invention, the above-mentioned chip testing method may further include: obtaining real-time running status information of pipeline test tasks for each of the test scenarios; wherein, the real-time running status information includes configuration file path, container name, and completion information of each stage of environment construction; the real-time running status information is used to skip completed stages during the automated execution of pipeline test tasks for each of the test scenarios.

[0164] For example, such as Figure 2 As shown, the core processing layer of the chip testing device can also be configured with a state management module to maintain the construction and running status of each working scenario, providing status query and update interfaces for the scenario management module and the environment construction module. Optionally, the real-time running status information of the pipeline test tasks in each test scenario is stored in the working directory of each scenario in the form of a job_status.json file, recording information such as the configuration file path, container name, and completion status of each stage of environment construction. Before executing each stage, the phased environment construction module queries is_done (completed) through the state management module; completed stages can be skipped directly; after completion, it calls the update method to write the status. The scenario management module can also read the status from the state management module for display when listing and displaying; the configuration parsing module does not directly read or write the status, but only provides the parsing results for the above modules to use. Figure 2 As shown, the status management module is listed alongside the scenario management module, the phased environment construction module, and the test execution module. It collaborates with the above modules through the shared job_status.json file in the working directory to achieve breakpoint resume and status display.

[0165] Optionally, the scenario management module and the state management module can work together to achieve isolation of test scenarios and management of their lifecycles. Figure 7 This is a schematic diagram of the lifecycle state machine for a test work scenario provided in Embodiment 4 of the present invention. In a specific example, such as Figure 7 As shown, a test scenario identified by jobid enters the created state after creation. When the test is executed via the run command, it enters the running state. During execution, it can be suspended using the pause() command, entering the paused state, and resumed using the resume() command. The enter command allows manual debugging in the container's interactive mode, which can be exited to resume execution. Finally, it can be manually deleted using the clean command or automatically reclaimed by the auto_clean_up policy based on the expiration date, entering the destroyed state. The scenario management module records and controls the state machine transitions completely through the independent job_status.json file for each workspace.

[0166] like Figure 7 As shown, after the test scenario is created, it enters a runnable state. Users can view scenarios using commands in the list, switch between scenarios using the select command, and delete scenarios using the clean command. Expired scenarios can also be automatically cleaned up in the background based on the number of days past their expiration. Each scenario corresponds to an independent working directory, and... Figure 6 The execution directory for the eight-stage pipeline is consistent. The job_status.json file can be stored in this directory and maintained by the status management module to record the completion status of each build stage, achieving consistency with... Figure 6 The corresponding checkpoints at each stage are defined. The CLI commands such as list, select, show, and clean mentioned above are the entry points for the scene management module.

[0167] In an optional embodiment of the present invention, the chip testing apparatus may provide the following standardized command-line interface: # ============ Environment Setup Commands =========== efdbg setup<receipt.json> [options] # Function: Configure the debugging environment based on the configuration file # Parameter: receipt.json - Path or URL to the chip test configuration file # Options: # -n, --dry-run This option does not actually execute the command; it only prints the command. # -v, --verbose Print detailed information # --skip-kmd skip driver installation # --skip-check Skip system checks # --skip-host Skip host environment settings # --skip-debug Skip debugging symbol loading # --skip-corefile Skip core dump processing # ============ Test Execution Command =========== efdbg run [<receipt.json> [options] # Function: Set up the environment and run test cases # Parameter: receipt.json - Path to the chip test configuration file (optional, defaults to using the most recent configuration) # Options: # -R, --tests-regex Run tests according to regular expression matching # -O, --override Override test environment variables # ============ Container Interaction Commands =========== efdbg enter [<receipt.json> ] # Function: Enter the container interaction mode of the current scene # Parameter: receipt.json - Path to the chip test configuration file (optional) # ============ Scene Management Commands =========== efdbg list [-t|--tags] [-v|--verbose] # Function: List all work scenarios # Options: # -t, --tags Lists available preset tags efdbg select <index> # Function: Select work scene by index efdbg show [<receipt.json> [options] # Function: Display work scene information # Options: # -s, --status Displays task status # -r, --root Displays root configuration # --log Displays a list of log files # -b, --backtrace Displays the crash stack trace (if available). # -c, --commands Displays a sequence of commands. # ============ Cleanup Commands =========== efdbg clean [<receipt.json> [options] # Function: Clean up the work scene # Options: # -a, --all Clean up all workspaces # -y, --confirm Confirm and delete directly # -o, --outdated Clean up expired job scenes # ============ Device Management Commands =========== efdbg reset [devices...] # Function: Reset AI Accelerator Card Device # Parameters: devices - A list of device IDs, such as 0 1 2 The core function of a chip testing device is rapid reproducibility based on standardized chip test configuration files. This means it reads these files and automatically reconstructs the test environment within a general chip testing pipeline. In a specific example, the following three typical scenarios demonstrate the workflow of this rapid reproducibility function: Scenario 1: Reproduce the environment with one click using a standardized chip test configuration file.

[0168] When test engineers need to reproduce test scenarios in a CI / CD pipeline locally, they only need to perform two steps: Step 1: Execute the `efdbg setup receipt.json` command to read the configuration. The chip testing device reads the JSON-formatted chip test configuration file and automatically parses the five structural fields of the chip test configuration file: metadata area structure, hardware environment description area structure, software environment description area structure, environment configuration area structure, and test execution description area structure. It then automatically executes an eight-stage test environment reconstruction process: if the `corefile` field is not empty, it downloads the core dump file, downloads the software package, performs a system environment check, detects the chip hardware, sets up the host environment, installs the driver, starts the container, and sets up the environment within the container. After the environment is built, a test workspace is created, with its `jobid` being the value of the `meta.jobid` field in the chip test configuration file.

[0169] Step 2 (optional): Execute other commands for debugging. For example, execute the `efdbg enter` command to enter the container for interactive debugging; execute the `efdbg run receipt.json` command to execute the test cases in the chip test configuration file with one click; execute the `efdbg show -c` command to view the complete command history of the scenario execution, etc.

[0170] Scenario 2: Comparative analysis of test scenarios in different versions.

[0171] When test engineers need to compare the differences in test environments between two versions of a test scenario, they can follow this process: Step 1: Set up the first scenario. For example, create a test job scenario with jobid v1_test using the command efdbg setup v1_receipt.json.

[0172] Step 2: Set up the second scenario. For example, create a test job scenario with jobid v2_test using the command efdbg setup v2_receipt.json.

[0173] Step 3: Quickly switch between two test scenarios. For example, you can switch to scenario v1 in seconds using the `efdbg select v1_test` command; and switch to scenario v2 in seconds using the `efdbg select v2_test` command.

[0174] Step 4: Compare test scenario information. For example, you can use the `efdbg show -c` command to display the command sequence of the current test scenario, and quickly locate environmental differences by comparing the command history of the two test scenarios.

[0175] Scenario 3: Crash problem analysis.

[0176] When a program crash occurs in the CI / CD pipeline, the following procedure can be executed: Step 1: Reproduce the crash environment using a standardized chip test configuration file. For example, using the `efdbg setupcrash_receipt.json` command, the `corefile` field of the chip test configuration file contains the path to the core dump file, and the chip test device automatically downloads the core dump file to the working directory.

[0177] Step 2: Enter the container and analyze the crash stack. For example, enter the container using the command `efdbg enter`, and use the command `gdbprogram corefile` to analyze the core dump file.

[0178] Step 3 (optional): Use the shortcut commands of the chip testing device, such as the efdbg show -b command, to automatically parse the core dump file and display the crash stack summary.

[0179] The core of the aforementioned function for quickly reproducing chip test scenarios lies in a deep understanding and analysis of the configuration specifications of the chip test configuration file, especially the automated execution capability of chip-specific fields in the chip test configuration file. Below is a typical command usage example: # Typical command usage examples # Basic reproduction operation efdbg setup receipt.json # Read the configuration and automatically rebuild the complete environment efdbg run receipt.json # Execute test cases with one click efdbg enter # Enter container interactive debugging # Scene Management Operations efdbg list # List all work scenarios efdbg select 1 # Switch to the specified scene efdbg clean --all # Clean up all scenes # Information viewing operation efdbg show -c # Display command sequence efdbg show -b # Show crash stack trace efdbg show -s # Display scene status # Preset Tag Usage (Optional) efdbg run topsinference:3.6.105 # Quickly reproduce using preset labels like Figure 2 As shown, the core processing layer of the chip testing device can be expanded with other functional modules as needed, such as a log management module. The configuration parsing module, scenario management module, phased environment construction module, test execution module, log management module, and state management module of the core processing layer collaborate with the chip test configuration file through the working directory to complete configuration loading, variable replacement, scenario isolation, eight-stage environment construction, test execution, and state persistence.

[0180] Table 1 lists the technical effects of the chip testing device provided in this embodiment of the invention compared with existing general pipeline testing methods. For example, as shown in Table 1, the chip testing device achieves input standardization, receiving a standardized chip test configuration file as the sole input, and can automatically complete the eight-stage environment construction, enabling one-click reconstruction. Simultaneously, based on state management, the chip testing device can automatically skip completed stages and implement breakpoint resume functionality; based on jobid-based work directory isolation, it can support parallel processing of multiple test scenarios and achieve second-level scenario switching without reconstructing the test scenario.

[0181] Table 1 Comparison of the technical effects of chip testing devices

[0182] The above technical solution provides a configuration parsing and execution device based on standardized chip testing field specific configuration specifications. It can understand the meaning of special fields in chip testing scenarios, support variable substitution, provide a preset label fast location mechanism, automatically execute phased environment construction, and achieve accurate reproduction of test scenarios.

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

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

[0185] Example 5 Figure 8 This is a schematic diagram of a chip testing device provided in Embodiment 5 of the present invention, as shown below. Figure 8 As shown, the device includes: a chip test configuration file acquisition module 810, a chip test configuration field parsing module 820, and a pipeline test task execution module 830, wherein: The chip test configuration file acquisition module 810 is used to acquire a standardized chip test configuration file; wherein, the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure. The chip test configuration field parsing module 820 is used to parse the data structures of the standardized chip test configuration file to obtain the chip test configuration fields. The pipeline test task execution module 830 is used to automatically execute pipeline test tasks for each test scenario in a phased manner according to the chip test configuration fields.

[0186] This invention provides a standardized chip test configuration file. This file includes various data structures such as metadata, hardware environment description, software environment description, environment configuration, and test execution description. The file's data structures are then parsed to obtain chip test configuration fields. Based on these fields, pipeline testing tasks for each test scenario are automatically executed in stages. This chip testing method effectively solves the problem that existing general-purpose pipeline testing tools struggle to understand chip-specific configuration information, thus failing to reproduce chip test scenarios. It enables rapid and accurate reproduction of chip-specific test scenarios.

[0187] Optionally, the chip test configuration file acquisition module 810 is also used to: collect real-time status association information of each test stage of the chip test pipeline during chip testing; and generate a standardized chip test configuration file based on the real-time status association information.

[0188] Optionally, the chip test configuration file acquisition module 810 is further configured to: fill the preset data structure of the chip test configuration file according to the real-time status association information to obtain an initial chip test configuration file; perform normalization verification on the configuration data in the initial chip test configuration file; and, if it is determined that the initial chip test configuration file has passed verification, serialize the initial chip test configuration file to obtain the standardized chip test configuration file.

[0189] Optionally, the chip test configuration file acquisition module 810 is further configured to: extract metadata fields from the real-time status association information and fill the metadata area structure of the chip test configuration file according to the metadata fields; extract chip hardware environment detection fields from the real-time status association information and fill the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection fields; extract chip software environment fields from the real-time status association information and fill the software environment description area structure of the chip test configuration file according to the chip software environment fields; extract environment configuration fields from the real-time status association information and fill the environment configuration area structure of the chip test configuration file according to the environment configuration fields; and extract test execution fields from the real-time status association information and fill the test execution description area structure of the chip test configuration file according to the test execution fields.

[0190] Optionally, the chip test configuration field parsing module 820 is further configured to: parse and verify each data structure of the standardized chip test configuration file to obtain the initial chip test configuration field; extract chip domain-specific fields from the initial chip test configuration field; and perform structured configuration on the chip domain-specific fields to obtain the chip test configuration field.

[0191] Optionally, the chip test configuration field parsing module 820 is also used to: parse the chip detection command field and driver installation command field according to the target data structure of the standardized chip test configuration file; automatically detect target replacement variables according to the pipeline test task of the current test scenario, and automatically replace the target placeholders in the parsed fields according to the target replacement variables; and verify the standardization of required fields, field types, chip-specific fields, and target dependencies.

[0192] Optionally, the pipeline test task execution module 830 is further configured to: create and maintain independent test workspaces for pipeline test tasks in each test scenario; execute an eight-stage test environment reconstruction process within each test workspace according to the chip test configuration fields to obtain a reconstructed test environment corresponding to each pipeline test task; and automatically execute the corresponding pipeline test task in the reconstructed test environment according to the target test command and the target test case; wherein the target test command and the target test case are obtained based on the chip test configuration fields.

[0193] Optionally, the pipeline test task execution module 830 is further configured to: download the core dump file according to the first chip test configuration field and save it to the working directory of the corresponding test workspace; read the package list according to the second chip test configuration field and download each package in sequence; read the system environment check command list according to the third chip test configuration field and execute each system environment check command in sequence; read and execute the chip detection command list according to the fourth chip test configuration field, parse the chip detection command output value, and extract the target key information; read the environment setting command list according to the fifth chip test configuration field and execute each environment setting command in sequence to update the host environment variables and create a directory; read and execute the driver installation command according to the sixth chip test configuration field to install the chip's kernel driver module; read and execute each container startup command in the container startup command list according to the seventh chip test configuration field and store the container ID information; read the container internal environment setting command according to the eighth chip test configuration field, add a container execution prefix to each of the container internal environment setting commands, and execute each of the container internal environment setting commands in sequence.

[0194] Optionally, the pipeline test task execution module 830 is further configured to: filter chip test associated fields from the chip test configuration fields and determine test case operation methods; filter the target test command from the chip test associated fields according to the task type of the pipeline test task, and filter the target test case from the test case operation methods; automatically execute the corresponding pipeline test task according to the target test case using the target test command; and store and manage test execution logs during the automated execution of the corresponding pipeline test task; wherein the test case operation methods include a test case running method, a container interaction mode entering method, a command sequence display method, and a crash stack display method.

[0195] Optionally, the above device further includes a real-time running status management module, used to: obtain real-time running status information of pipeline test tasks for each of the test scenarios; wherein, the real-time running status information includes configuration file path, container name, and completion information of each stage of environment construction; the real-time running status information is used to skip completed stages during the automated execution of pipeline test tasks for each of the test scenarios.

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

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

[0198] Example 6 Figure 9 A schematic diagram of an electronic device 10, which 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 (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.

[0199] like Figure 9 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 into the RAM 13 from storage unit 18. 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.

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

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

[0202] Optionally, the chip testing method may include: obtaining a standardized chip test configuration file; wherein the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure; parsing each data structure of the standardized chip test configuration file to obtain chip test configuration fields; and automatically executing pipeline test tasks for each test scenario in a phased manner according to the chip test configuration fields.

[0203] 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).

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

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

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

[0207] 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).

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

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

[0210] This invention 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 invention. This program product shares the same inventive concept as the chip testing methods disclosed in the embodiments of this invention, and therefore will not be described in detail here.

[0211] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the embodiments of the present invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in the embodiments of the present invention can be achieved, and this is not limited herein.

[0212] 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.< / index> < / corefile> < / program> < / corefile> < / program> < / corefile> < / program> < / jobid>

Claims

1. A chip testing method, characterized in that, include: Obtain a standardized chip test configuration file; wherein the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure; The data structures of the standardized chip test configuration file are parsed to obtain the chip test configuration fields; Based on the chip test configuration fields, pipeline test tasks for each test scenario are executed automatically in a phased manner. The process of parsing the data structures of the standardized chip test configuration file yields chip test configuration fields, including: The data structures of the standardized chip test configuration file are parsed and verified to obtain the initial chip test configuration fields; Extract chip-specific fields from the initial chip test configuration fields; The chip-specific fields are configured in a structured manner to obtain the chip test configuration fields; The step of automatically executing pipeline test tasks for each test scenario in a phased manner based on the chip test configuration fields includes: Create and maintain independent test workspaces for pipeline test tasks in each of the aforementioned test scenarios; Within each of the aforementioned test workspaces, an eight-stage test environment reconstruction process is executed based on the chip test configuration fields to obtain the reconstructed test environment corresponding to each of the aforementioned pipeline test tasks; wherein, the eight-stage test environment reconstruction process includes downloading core dump, downloading software packages, system environment check, chip hardware detection, host environment setting, driver installation, container startup, and container environment setting; In the refactored test environment, the corresponding pipeline test tasks are automatically executed according to the target test commands and target test cases; The target test command and the target test case are obtained based on the chip test configuration field.

2. The method according to claim 1, characterized in that, The process of obtaining a standardized chip test configuration file includes: Collect real-time status correlation information of each test stage in the chip testing process of a general chip testing pipeline; A standardized chip test configuration file is generated based on the real-time status association information.

3. The method according to claim 2, characterized in that, The step of generating a standardized chip test configuration file based on the real-time status association information includes: The initial chip test configuration file is obtained by filling the preset data structure of the chip test configuration file with the real-time status association information. The configuration data in the initial chip test configuration file is standardized and verified. If the initial chip test configuration file is verified, the initial chip test configuration file is serialized to obtain the standardized chip test configuration file.

4. The method according to claim 3, characterized in that, The step of filling the preset data structure of the chip test configuration file according to the real-time status association information includes: Extract metadata fields from the real-time status association information, and populate the metadata area structure of the chip test configuration file according to the metadata fields; Extract the chip hardware environment detection field from the real-time status association information, and fill the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection field; Extract the chip software environment field from the real-time status association information, and fill the software environment description area structure of the chip test configuration file according to the chip software environment field; Extract the environment configuration field from the real-time status association information, and fill the environment configuration area structure of the chip test configuration file according to the environment configuration field; The test execution field is extracted from the real-time status association information, and the test execution description area structure of the chip test configuration file is filled according to the test execution field.

5. The method according to claim 1, characterized in that, The parsing and verification of each data structure in the standardized chip test configuration file includes: The chip detection command field and driver installation command field are obtained by parsing the target data structure of the standardized chip test configuration file. The system automatically detects target replacement variables based on the pipeline test task of the current test scenario, and automatically replaces the target placeholders in the parsed fields based on the target replacement variables. Verify the compliance of required fields, field types, chip-specific fields, and target dependencies.

6. The method according to claim 1, characterized in that, The process of reconstructing the eight-stage test environment within each test workspace according to the chip test configuration fields includes: Download the core dump file according to the first chip test configuration field and save it to the working directory of the corresponding test workspace; The software package list is read based on the second chip test configuration field, and each software package is downloaded sequentially. The system environment check command list is read from the third chip test configuration field, and each system environment check command is executed in sequence. Read and execute the list of chip detection commands based on the fourth chip test configuration field, parse the output value of the chip detection commands, and extract the key target information; The system reads the list of environment setting commands based on the fifth chip test configuration field, and executes each environment setting command in sequence to update the host machine environment variables and create directories. The driver installation command is read and executed based on the sixth chip test configuration field to install the chip's kernel driver module; Based on the seventh chip test configuration field, read and execute each container startup command in the container startup command list, and store and record the container ID information; The container environment setting commands are read from the eighth chip test configuration field. After adding a container execution prefix to each of the container environment setting commands, the container environment setting commands are executed in sequence.

7. The method according to claim 1, characterized in that, The automated execution of corresponding pipelined test tasks based on target test commands and target test cases in the reconstructed test environment includes: Filter the chip test related fields from the chip test configuration fields and determine the test case operation method; Based on the task type of the pipeline test task, the target test command is filtered from the chip test association field, and the target test case is filtered from the test case operation method; The target test command is used to automatically execute the corresponding pipeline test task based on the target test case; During the automated execution of corresponding pipeline test tasks, test execution logs are stored and managed. The test case operation methods include methods for running test cases, entering container interactive mode, displaying command sequences, and displaying crash stacks.

8. The method according to claim 1, characterized in that, Also includes: Obtain real-time running status information of pipeline test tasks for each of the aforementioned test scenarios; wherein, the real-time running status information of the tasks includes configuration file path, container name, and completion information of each stage of environment construction; The real-time running status information is used to skip completed stages during the automated execution of pipeline test tasks for each of the test scenarios.

9. A chip testing device, characterized in that, include: The chip test configuration file acquisition module is used to acquire a standardized chip test configuration file; wherein, the standardized chip test configuration file includes a metadata area structure, a hardware environment description area structure, a software environment description area structure, an environment configuration area structure, and a test execution description area structure; The chip test configuration field parsing module is used to parse the data structures of the standardized chip test configuration file to obtain the chip test configuration fields. The pipeline test task execution module is used to automatically execute pipeline test tasks for each test scenario in a phased manner according to the chip test configuration fields. The chip test configuration field parsing module is further configured to: parse and verify the data structures of the standardized chip test configuration file to obtain the initial chip test configuration field; extract chip domain-specific fields from the initial chip test configuration field; and perform structured configuration on the chip domain-specific fields to obtain the chip test configuration field. The pipeline test task execution module is further configured to: create and maintain independent test workspaces for pipeline test tasks in each test scenario; execute an eight-stage test environment reconstruction process within each test workspace based on the chip test configuration fields to obtain a reconstructed test environment corresponding to each pipeline test task; wherein the eight-stage test environment reconstruction process includes downloading core dump, downloading software packages, system environment checks, chip hardware detection, host environment settings, driver installation, container startup, and container environment settings; automatically execute the corresponding pipeline test tasks in the reconstructed test environment based on the target test commands and target test cases; wherein the target test commands and target test cases are obtained based on the chip test configuration fields.

10. 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 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-8.

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

12. 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-8.

Images