Test case reuse method, apparatus, device, medium, and product

Abstract

The present disclosure provides a test case reuse method, device, equipment, medium and product. In response to target verification on a to-be-tested chip, a basic test case is obtained. A parent class of the basic test case is configured as a variable. The variable of the parent class in the basic test case is defined to a base class corresponding to the target verification, to obtain a target test case. The target test case is run. The target test case calls the base class corresponding to the target verification inherited by the parent class, to perform the target verification on the to-be-tested chip. Thus, by abstracting the parent class of the basic test case as a configurable variable, and by pointing the variable to the base class corresponding to the target verification at different verification compilation times, the same set of basic test case codes can be seamlessly reused between different verifications without any modification.

Description

Technical Field

[0001] This disclosure relates to chip testing technology, and in particular to a test case reuse method, apparatus, device, medium, and product. Background Technology

[0002] Chip verification is the process of functionally confirming the design code using a simulation platform before chip tape-out, ensuring that the chip's behavior conforms to the design specifications. Chip verification typically follows a three-level verification process: module (IP) level verification, subsystem level verification, and system-on-a-chip (SoC) level verification. Due to significant differences in the verification environments at each level, test cases developed and verified at one level often cannot be directly migrated and reused at other levels. In actual engineering, for the same chip under test, it is usually necessary to develop separate test cases for IP-level verification, subsystem-level verification, and SoC-level verification, even if these test cases verify the same functional scenarios. This parallel development and independent maintenance of multiple sets of test cases leads to a significant increase in verification workload, a substantial extension of project cycles, and a continuous rise in human resource costs. Furthermore, the lack of synchronization mechanisms between multiple versions of test cases can introduce inconsistencies in behavior, reducing the reliability of verification results. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this disclosure provide a method, apparatus, device, medium, and product for reusing test cases.

[0004] One aspect of this disclosure provides a test case reuse method, comprising: in response to performing target verification on a chip under test, obtaining basic test cases, wherein the parent class of the basic test cases is configured as a variable; defining the variable of the parent class in the basic test cases to the base class corresponding to the target verification to obtain a target test case; and running the target test case, wherein the target test case calls the base class corresponding to the target verification inherited by the parent class to perform the target verification on the chip under test.

[0005] In another aspect of this disclosure, a test case reuse apparatus is provided, comprising: a test case acquisition module, configured to acquire basic test cases in response to target verification of a chip under test, wherein the parent class of the basic test cases is configured as a variable; a parent class definition module, configured to define the variables of the parent class in the basic test cases to the base class corresponding to the target verification, thereby obtaining a target test case; and a verification execution module, configured to run the target test case, wherein the target test case calls the base class corresponding to the target verification inherited by the parent class to perform the target verification on the chip under test.

[0006] In another aspect of this disclosure, an electronic device is provided, comprising: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, the test case reuse method of the above-mentioned claims is implemented.

[0007] In another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that, when the computer program is executed by a processor, it implements the above-described test case reuse method.

[0008] In another aspect, this disclosure provides a computer program product including computer program instructions, characterized in that the computer program instructions, when executed by a processor, implement the above-described test case reuse method.

[0009] Based on the test case reuse method, apparatus, device, medium, and product disclosed herein, by abstracting the parent class of the basic test cases into a configurable variable, and pointing this variable to the base class of the corresponding target verification during the compilation of different verifications, the same set of basic test case code can be seamlessly reused between different verifications without any modification. This eliminates the problem of repeated test case development caused by differences in the environmental hardware access conditions of verification at each level, significantly reduces the verification workload, shortens the chip verification cycle, reduces human maintenance costs, and ensures a high degree of consistency in verification behavior for the same functional scenario at different levels, thereby improving the credibility of verification results.

[0010] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0011] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0012] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a flowchart illustrating a test case reuse method provided in an exemplary embodiment of this disclosure.

[0013] Figure 2 This is a flowchart illustrating the test case reuse method provided in an application example of this disclosure.

[0014] Figure 3 This is a schematic diagram of the structure of a test case reuse device provided in an exemplary embodiment of this disclosure.

[0015] Figure 4 This is a schematic diagram of the structure of an application embodiment of the electronic device disclosed herein. Detailed Implementation

[0016] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0017] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0018] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0019] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

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

[0021] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0022] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0023] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0024] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0025] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0026] The embodiments disclosed herein can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate together with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0027] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are executed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0028] In implementing the technology disclosed herein, research revealed that during chip verification, significant differences exist in hardware access conditions such as bus topology, driving methods, clock reset strategies, register access paths, and VIP interface types across different verification levels. This means that test cases developed and fully verified at one level often cannot be migrated to other levels for reuse. In practice, it becomes necessary to develop and maintain independent test cases for the same functional scenario at different verification levels. For example, migrating from IP-level verification to SoC-level verification involves independent verification environments and incompatible test cases. The SoC-level verification stage requires rewriting stimulus sequences, drivers, checkers, and even complete test cases, or copying and pasting existing IP-level test cases and manually modifying them extensively to adapt to the SoC environment. This practice necessitates maintaining multiple sets of functionally similar but incompatible test case versions for the same verification scenario, resulting in significant duplication of development, a prolonged verification cycle, and continuously increased labor costs.

[0029] Figure 1 This is a flowchart illustrating a test case reuse method provided in an exemplary embodiment of this disclosure. This embodiment can be applied to electronic devices, such as... Figure 1 As shown, this test case reuse method may include the following steps: Step S100: In response to the target verification of the chip under test, basic test cases are obtained.

[0030] Among them, a basic test case is a documented description of a set of test inputs, execution conditions, and expected results designed to verify a certain function, reflecting the test plan, methods, techniques, and strategies. In other words, a basic test case defines what to test, how to stimulate it, how to observe the results, and what kind of results are correct.

[0031] The parent class of the basic test cases is configured as a variable. In one implementation, the basic test cases may include: class declaration, environment component creation and configuration, test stimuli and business processes, and result checking and reporting. The class declaration includes the fully qualified class name of the basic test case and declares its inherited parent class using keywords such as `extends`. This inheritance relationship determines the position of the basic test case in the verification environment inheritance hierarchy and its callable base class. Environment component creation and configuration is responsible for instantiating and configuring various components required for verification, such as proxies and scoreboards. Test stimuli and business processes include a series of operation steps arranged in the sequence of "configuration → stimulus → wait → check," with each operation step corresponding to calling at least one underlying task encapsulated in the base class. Result checking and reporting provide a clear verification conclusion of pass or failure. In the class declaration, the basic test cases define the inherited parent class as a variable to decouple the basic test cases from the specific verification. The target verification can be any verification in the chip verification process, such as module-level verification. The chip under test can be, for example, a system-on-a-chip (SoC).

[0032] Step S110: Define the variables of the parent class in the basic test case to the base class corresponding to the target verification to obtain the target test case.

[0033] The base class is the parent class that encapsulates all the details of low-level hardware operations and provides a unified and standardized service interface for upper-level test cases. The base class includes a base class identifier and multiple low-level tasks. A low-level task is a basic operational unit that directly interacts with the hardware; it is an abstraction and standardized encapsulation of hardware access behavior in the verification environment. Each low-level task completes a well-defined atomic operation. A low-level task consists of two parts: an external interface, an internal implementation, and a concrete implementation. The external interface defines the task name, input parameters, and return value, while the internal implementation contains the specific operation code adapted to the current hardware architecture being verified.

[0034] In one example, a macro definition can be used to replace the variable after the `extends` keyword in the class declaration of the base test case with the base class identifier of the base class corresponding to the target verification. This allows the base test case to inherit from the base class, thus obtaining the target test case and enabling the target base class to gain hardware access capabilities adapted to the target verification environment.

[0035] Step S120: Run the target test case. The target test case calls the base class corresponding to the target verification inherited from the parent class to perform target verification on the chip under test.

[0036] The target test cases can run on a simulation test platform. This platform runs on an Electronic Design Automation (EDA) simulator, such as Synopsys VCS or Cadence Xcelium. The simulation test platform integrates a verification methodology (UVM). UVM is a standard verification framework and library based on SystemVerilog, providing standardized mechanisms for component creation, configuration, communication, and execution phase management for the base classes and target test cases of each verification.

[0037] In one implementation, the target test case runs on a simulation test platform, calling the underlying tasks corresponding to each operation step from its inherited base class to execute the business process in the target test case in order to perform target verification on the chip under test.

[0038] In this embodiment of the disclosure, by abstracting the parent class of the basic test cases into a configurable variable, and pointing this variable to the base class of the corresponding target verification during the compilation of different verifications, the same set of basic test case code can be seamlessly reused between different verifications without any modification. This eliminates the problem of repeated development of test cases caused by differences in the environmental hardware access conditions of verification at each level, significantly reduces the verification workload, shortens the chip verification cycle, reduces human maintenance costs, and ensures a high degree of consistency in verification behavior for the same functional scenario at different levels, thereby improving the credibility of the verification results.

[0039] In some alternative implementations, in the embodiments of this disclosure, target verification includes at least one of the following: module-level verification, subsystem-level verification, and system-level verification.

[0040] IP-level verification focuses on a single reusable intellectual property (IP) module within a chip. In its independent, idealized operating environment, it comprehensively verifies the module's functional correctness and design specification compliance by directly driving the module's boundary signals and local bus interface. IP modules include, for example, at least one of the following: Universal Asynchronous Receiver / Transmitter (UART), Serial Peripheral Interface (SPI), Inter-Integrated Circuit Bus (I2C), Direct Memory Access (DMA) controller, USB Physical Layer (USB PHY), etc. Subsystem-level verification focuses on a logical collection of multiple functionally related IP modules. Within the integrated internal interconnects and local bus environment, it verifies the correctness of interactions such as inter-module collaboration, data flow paths, resource sharing and arbitration, and subsystem-level interrupt handling. SoC-level verification focuses on the complete chip system. In a fully integrated environment including the processor, bus matrix, interrupt controller, clock / reset management, memory system, and all peripherals, it verifies the overall system functionality, performance, and correctness of hardware and software collaboration by simulating real-world application scenarios and end-to-end data flow.

[0041] In some optional implementations, the step S100 in this embodiment may further include: for module-level verification, subsystem-level verification and system-level verification, encapsulating multiple underlying tasks in the base class of the verification based on a preset interface protocol.

[0042] The preset interface protocol includes the task name, parameter information, and return value information. Parameter information may include, for example, the number, type, and order of parameters, while return value information may include, for example, the type and structure of the return value.

[0043] Each base class for verification has underlying tasks with the same functionality, and these tasks have the same task name, parameter information, and return value information. In other words, underlying tasks with the same functionality correspond to the same external interface across all base classes.

[0044] For example, `ip_base_test` represents the base class for module-level verification, `subsystem_base_test` represents the base class for subsystem-level verification, and `soc_base_test` represents the base class for system-level verification. `ip_base_test`, `subsystem_base_test`, and `soc_base_test` all include the following underlying tasks: write register task (`task write_reg`), read register task (`task read_reg`), reset device task (`task reset_device`), trigger IP action task (`tasktrigger_ip_action`), wait for transmission completion task (`task wait_trans_done`), and check result task (`taskcheck_result`). An interface protocol can be predefined, which may include, for example, task name, input parameters (parameter information), and return value / output parameters (return value information). Each of the above underlying tasks in `ip_base_test`, `subsystem_base_test`, and `soc_base_test` strictly follows this predefined interface protocol; that is, underlying tasks with the same function have the same task name, parameter information, and return value information.

[0045] For example, taking the write register task as an example, the underlying task in the three base classes of the above verification is as follows: the task name is task write_reg, the parameter information includes two input parameters, the first parameter is the register address (such as bit[31:0] addr), and the second parameter is the data to be written (such as bit[31:0] data). The parameter types, number and order are completely consistent; the return value information is that there is no return value.

[0046] In this embodiment of the disclosure, by pre-encapsulating multiple underlying tasks in the base classes of module-level verification, subsystem-level verification, and system-level verification, and by forcing the underlying tasks with the same function in the base classes of different levels of verification to keep the task name, parameter information, and return value information completely consistent, a unified and stable calling interface is provided for the upper-level test cases, eliminating the need to modify the code of test cases due to environmental differences, and realizing the key foundation for seamless reuse of the same set of test cases among the three levels of verification.

[0047] In some optional implementations, within the embodiments of this disclosure, the underlying tasks in the base class of the current verification can be encapsulated as follows: for multiple underlying tasks, based on a preset interface protocol, and based on the hardware architecture and access path corresponding to the verification, the underlying task is encapsulated. The current verification can be any of the following types of verification: module-level verification, subsystem-level verification, and system-level verification.

[0048] In one implementation, for each underlying task, a preset interface protocol is followed, and the task is encapsulated based on the hardware architecture and access path, such as the current verification bus path, address mapping, and driver method. Specifically, a Verification IP (VIP) is deployed in the simulation test platform. The component handle of the corresponding bus VIP is obtained through the configuration mechanism of the simulation test platform, and the operation functions provided by the component handle are called to encapsulate it into an underlying task adapted to the current verification hardware environment.

[0049] For example, consider a register write task: In the base classes for IP-level and subsystem-level verification, the corresponding hardware architecture is a UART directly connected to the Advanced Peripheral Bus (APB), with the register address being the local offset address; the access path is direct access via the APB VIP. The encapsulation process is as follows: obtain the driver component handle of the APB VIP, call its built-in apb_write function, send the passed offset address addr and the data to be written data directly to the APB bus, and encapsulate the above operation into a write register task with the task name taskwrite_reg, parameters (int addr, byte data), and no return value, following the preset interface protocol.

[0050] In the base class for SoC-level verification, the corresponding hardware architecture is that the UART is connected to the system bus via the Advanced Extensible Interface (AXI) to the APB Bridge. The access path is to initiate system bus access through the AXI VIP, traverse the bridge, and finally reach the UART. The encapsulation process is as follows: obtain the system base address of the UART in the SoC, add the passed local offset address addr to the base address to calculate the system physical address, then obtain the driver component handle of the AXI VIP, call its built-in axi_write function, send the system physical address and data to the AXI bus, and encapsulate the above operation into a write register task with the task name write_reg, parameters (int addr, byte data) and no return value, following the preset interface protocol. It can be seen that the internal implementation code of the same write register task is completely different in the base class of IP-level / subsystem-level verification and the base class of SoC-level verification, but the external interface write_reg(int addr, byte data) always remains strictly consistent.

[0051] In this embodiment of the disclosure, by specifically encapsulating the differences in hardware architecture and access paths into various underlying tasks, a unified and stable calling interface is built for the upper-layer test cases. This decouples the test logic from the hardware environment at the architecture level, enabling seamless reuse of the same set of test cases across layers.

[0052] In some alternative implementations, the step S100 in this embodiment of the present disclosure may further include: using a macro variable to place the parent class name field of the class declaration in the base test case, so as to configure the parent class in the base test case as a variable.

[0053] One approach is to use macro definitions to place the parent class (parent class name field) after the `extends` directive in the class declaration of the base test case using a macro variable. For example, if `BASE_CLASS` is a macro variable, and the base test case class is declared as `class xxx_test_case extends BASE_CLASS`, which defines a base test case class named `xxx_test_case` that inherits from a parent class specified by the macro variable `BASE_CLASS`.

[0054] In some optional implementations, step S110 in this embodiment of the present disclosure may include: defining the macro variable in the class declaration of the basic test case as the base class corresponding to the target verification, thereby obtaining the target test case.

[0055] In SystemVerilog, the `define` keyword in the preprocessor syntax can be used to define macro variables as the base class corresponding to the target verification. For example, when the target verification is IP-level verification, in the base test case, `define BASE_CLASS xxx_ip_base_test` defines the macro variable `BASE_CLASS` in the base test case `xxx` as the IP-level verification `ip_base_test`, thus obtaining the target test case for IP-level verification. When the target verification is SoC-level verification, in the base test case, `define BASE_CLASS xxx_soc_base_test` defines the macro variable `BASE_CLASS` in the base test case `xxx` as the SoC-level verification, thus obtaining the target test case for SoC-level verification.

[0056] In one application example Figure 2 This is a flowchart illustrating the test case reuse method provided in an application example of this disclosure. For example... Figure 2 As shown, it includes: Step 1: For module-level verification, subsystem-level verification, and system-level verification, based on a preset interface protocol, multiple underlying tasks are encapsulated in the base class of the verification. Each base class of the verification has underlying tasks with the same function, and the underlying tasks with the same function correspond to the same task name, parameter information, and return value information. The preset interface protocol includes task name, parameter information, and return value information.

[0057] Step 2: Create basic test cases. In the basic test cases, the macro variable BASE_CLASS is followed by the class declaration keyword extends.

[0058] Step 3: During target verification, obtain the base test cases. Define the macro variables in the class declarations used for base testing as the base classes corresponding to the target verification to obtain the target test cases. For example, when the target verification is IP-level verification, define BASE_CLASS ip_base_test will be used to define the macro variables in the class declarations used for base testing as the base classes corresponding to IP-level verification to obtain the target test cases for IP-level verification. When the target verification is subsystem-level verification, define BASE_CLASS subsystem_base_test will be used to define the macro variables in the class declarations used for base testing as the base classes corresponding to subsystem-level verification to obtain the target test cases for subsystem-level verification. When the target verification is SoC-level verification, define BASE_CLASS soc_base_test will be used to define the macro variables in the class declarations used for base testing as the base classes corresponding to SoC-level verification to obtain the target test cases for SoC-level verification.

[0059] Step 4: Run the target test case. The target test case uses the target test case driver to call the base class inherited from the parent class to perform target verification on the chip under test.

[0060] Figure 3 This is a schematic diagram of the structure of a test case reuse device provided in an exemplary embodiment of this disclosure. Figure 3 As shown, the device includes: The test case acquisition module 200 is used to acquire basic test cases in response to target verification of the chip under test, wherein the parent class of the basic test cases is configured as a variable; The parent class definition module 210 is used to define the variables of the parent class in the basic test cases to the base class corresponding to the target verification, so as to obtain the target test cases; The verification execution module 220 is used to run the target test case. The target test case calls the base class corresponding to the target verification inherited from the parent class to perform the target verification on the chip under test.

[0061] In some alternative implementations, the target verification includes at least one of the following: module-level verification, subsystem-level verification, and system-level verification.

[0062] In some optional implementations, the test case reuse device in this embodiment further includes: The task encapsulation module is used to encapsulate multiple underlying tasks in the base class of the verification based on a preset interface protocol for the module-level verification, the subsystem-level verification, and the system-level verification. Each verification base class has underlying tasks with the same function, and the underlying tasks with the same function correspond to the same task name, parameter information, and return value information. The preset interface protocol includes task name, parameter information, and return value information.

[0063] In some optional implementations, the encapsulation of multiple underlying tasks in the base class of the verification in this embodiment is further used to: for the multiple underlying tasks, based on the preset interface protocol, based on the hardware architecture and access path corresponding to the verification, encapsulate the underlying tasks.

[0064] In some optional implementations, the test case reuse device in this embodiment further includes: The test case setting module is used to place the parent class name field of the class declaration in the basic test case using macro variables, so as to configure the parent class in the basic test case as a variable.

[0065] In some optional implementations, the parent class definition module 210 in this embodiment is specifically used to define the macro variables in the class declaration as the base class corresponding to the target verification, thereby obtaining the target test case.

[0066] The test case reuse apparatus of this disclosure corresponds to the test case reuse method described above, and the relevant contents can be referred to each other, which will not be repeated here.

[0067] The beneficial technical effects of the exemplary embodiments of the test case reuse device of this disclosure can be found in the corresponding beneficial technical effects of the exemplary methods and systems described above, and will not be repeated here.

[0068] In addition, this disclosure also provides an electronic device, including: Memory, used to store computer programs; A processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, it implements the test case reuse method described in any of the above embodiments of the present disclosure.

[0069] Figure 4 This is a schematic diagram illustrating the structure of an application embodiment of the electronic device disclosed herein. Below, reference is made to… Figure 4 This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0070] like Figure 4 As shown, the electronic device includes one or more processors and memory.

[0071] A processor can be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.

[0072] The memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and a processor may execute the program instructions to implement the test case reuse methods of the various embodiments of this disclosure described above and / or other desired functions.

[0073] In one example, the electronic device may also include input devices and output devices, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0074] In addition, the input device may include, for example, a keyboard, a mouse, etc.

[0075] This output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0076] Of course, for the sake of simplicity, Figure 4 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0077] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the test case reuse methods according to various embodiments of this disclosure as described in the foregoing sections of this specification.

[0078] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0079] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the test case reuse method according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0080] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0081] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0082] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0083] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0084] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0085] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0086] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0087] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0088] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A test case reuse method, characterized in that, include: In response to the target verification of the chip under test, basic test cases are obtained, and the parent class of the basic test cases is configured as a variable; Define the variables of the parent class in the basic test case to the base class corresponding to the target verification to obtain the target test case; The target test case is run, and the target test case calls the base class corresponding to the target verification inherited from the parent class to perform the target verification on the chip under test.

2. The method according to claim 1, characterized in that, The target verification includes at least one of the following: module-level verification, subsystem-level verification, and system-level verification.

3. The method of claim 2, wherein, Before responding to target verification of the chip under test and obtaining basic test cases, the process also includes: For the module-level verification, the subsystem-level verification, and the system-level verification, based on a preset interface protocol, multiple underlying tasks are encapsulated in the base class of the verification. Each base class of the verification has underlying tasks with the same function, and the underlying tasks with the same function correspond to the same task name, parameter information, and return value information. The preset interface protocol includes task name, parameter information, and return value information.

4. The method of claim 3, wherein, The base class for verification encapsulates multiple underlying tasks, including: For the multiple underlying tasks, the underlying tasks are encapsulated based on the preset interface protocol, the hardware architecture corresponding to the verification, and the access path.

5. The method according to any one of claims 1 to 4, characterized in that, Before responding to target verification of the chip under test and obtaining basic test cases, the process also includes: A macro variable is used to place the parent class name field in the class declaration of the basic test case, so that the parent class in the basic test case is configured as a variable.

6. The method of claim 5, wherein, The step of defining the variables of the parent class in the basic test cases to the base class corresponding to the target verification includes: Define the macro variables in the class declaration as the base class corresponding to the target verification to obtain the target test case.

7. A test case reuse apparatus, characterized by: include: The test case acquisition module is used to acquire basic test cases in response to target verification of the chip under test. The parent class of the basic test cases is configured as a variable. The parent class definition module is used to define the variables of the parent class in the basic test cases to the base class corresponding to the target verification, so as to obtain the target test cases; The verification execution module is used to run the target test case. The target test case calls the base class corresponding to the target verification, which is inherited from the parent class, to perform the target verification on the chip under test.

8. An electronic device, comprising: include: Memory, used to store computer programs; A processor for executing a computer program stored in the memory, wherein when the computer program is executed, it implements the method described in any one of claims 1-6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-6.

10. A computer program product comprising computer program instructions, characterised in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-6.

Images