Chip testing method, electronic device and computer-readable medium

Abstract

A chip testing method, an electronic device and a computer-readable medium. The method comprises: receiving a testing starting instruction sent by a testing upper computer, wherein the testing starting instruction specifies corresponding testing script data, and the testing script data is pre-stored in a testing lower computer; on the basis of the testing script data corresponding to the testing starting instruction, testing a target chip, so as to obtain a testing result; and sending the testing result to the testing upper computer.

Description

Chip testing method, electronic device, and computer-readable medium

[0001] Cross-references to related publications

[0002] This disclosure claims priority to a Chinese patent application filed with the State Intellectual Property Office on January 2, 2024, with application number CN202410004277.5 and invention name “Chip testing method, electronic device and computer-readable medium”. The entire contents of this application are incorporated by reference into this disclosure. Technical Field

[0003] The embodiments of the present disclosure relate to, but are not limited to, the field of testing technology, and in particular to a chip testing method, an electronic device, and a computer-readable medium. Background Art

[0004] SLT (System Level Test) is a chip-to-system screening method that systematically tests all chip components on the basis of a complete operating system. Referring to Figure 1, in existing system-level testing technology, a host computer (i.e., an SLT machine) generally sends test commands to an SLT test platform (i.e., an SLT test board) via a serial UART (Universal Asynchronous Receiver / Transmitter) port. After receiving the command, the test platform calls the user-mode driver interface provided by the operating system to test the chip components. Finally, the test results are fed back to the host computer via the UART port, completing a complete test process.

[0005] However, as chip integration becomes increasingly high, the core of the SOC (System on Chip) chip has evolved from a single core to multiple cores, and even heterogeneous systems, multi-level cache (a post-relational database) and high-speed SerDes (serial deserializer) PCIe (peripheral component interconnect express) interface connected to the NAE (Network Accelerator Engine), GPU (Graphics Processing Unit), DPU (Data Processing Unit) and other acceleration subsystems. Because SLT is a direct application-oriented screening test, its functional points may reach hundreds, and there may be coupling or repulsion between each functional point. Faced with such a complex SOC chip, if the traditional three-step method of sending, testing, and responding is used, the time complexity of completing a complete functional test of a chip will be unacceptable. Summary of the Invention

[0006] Embodiments of the present disclosure provide a chip testing method, an electronic device, and a computer-readable medium.

[0007] In a first aspect, an embodiment of the present disclosure provides a chip testing method, comprising: receiving a test start instruction sent by a test host computer, wherein the test start instruction specifies corresponding test script data, and the test script data is pre-stored in a test slave computer; testing a target chip according to the test script data corresponding to the test start instruction to obtain a test result; and sending the test result to the test host computer.

[0008] In the second aspect, an embodiment of the present disclosure provides a chip testing method, comprising: sending a test start instruction to a test slave computer, so that the test slave computer tests the target chip according to the test script data corresponding to the test start instruction; wherein, the test start instruction specifies the corresponding test script data, and the test script data is pre-stored in the test slave computer; and receiving the test results of the target chip fed back by the test slave computer.

[0009] In a third aspect, an embodiment of the present disclosure provides an electronic device, comprising: at least one processor; and a memory storing at least one program, wherein when the at least one program is executed by the at least one processor, the at least one processor implements the chip testing method described in the first aspect or the second aspect of the embodiment of the present disclosure.

[0010] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the chip testing method described in the first aspect or the second aspect of the embodiment of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG1 is a schematic diagram of the architecture of an existing system-level test;

[0012] FIG2 is a schematic diagram of a chip test architecture according to an embodiment of the present disclosure.

[0013] FIG3 is a schematic flow chart of a chip testing method according to an embodiment of the present disclosure;

[0014] FIG4 is a flowchart of some steps in another chip testing method according to an embodiment of the present disclosure;

[0015] FIG5 is a schematic structural diagram of a target storage module according to an embodiment of the present disclosure;

[0016] FIG6 is a schematic diagram of the structure of a script parsing module according to an embodiment of the present disclosure;

[0017] FIG7 is a flowchart of some steps in another chip testing method according to an embodiment of the present disclosure;

[0018] FIG8 is a schematic diagram of a distribution method for executing test cases according to an embodiment of the present disclosure;

[0019] FIG9 is a flow chart of concurrent execution of test cases numbered 0, 2, 4, 6, and 8 according to an embodiment of the present disclosure;

[0020] FIG10 is a flow chart showing the concurrent execution of test cases numbered 1, 3, 5, 7, and 9 according to test groups according to an embodiment of the present disclosure;

[0021] FIG11 is a flow chart of another chip testing method according to an embodiment of the present disclosure;

[0022] FIG12 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure;

[0023] FIG13 is a schematic diagram of the structure of a computer-readable medium according to an embodiment of the present disclosure;

[0024] FIG14 is a flow chart of a chip testing method according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] To enable those skilled in the art to better understand the technical solutions of the present disclosure, the chip testing method, electronic device, and computer-readable medium provided by the present disclosure are described in detail below with reference to the accompanying drawings.

[0026] Example embodiments will be described more fully hereinafter with reference to the accompanying drawings, but the example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of this disclosure to those skilled in the art.

[0027] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0028] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0029] The terms used herein are used only to describe specific embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a," "an," and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements, and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof is not excluded.

[0030] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined as such herein.

[0031] The following describes an exemplary system architecture and testing environment of a chip testing method with reference to the accompanying drawings:

[0032] In some examples, referring to FIG2 , the test slave computer receives instructions transmitted by the test host computer to implement testing of the target chip (such as the SOC to be tested). In some examples, the embodiments of the present disclosure do not specifically limit the test host computer and the test slave computer. The test host computer may be an SLT machine management module provided with a client, and the test slave computer may be an SLT single board management module provided with a server. The test of the target chip may be based on a C / S character communication management model. Compared with the traditional chip test CLI (command-line interface) method, the C / S character communication management model includes a test host computer and a test slave computer. The test host computer and the test slave computer are reserved with network ports and serial ports to implement data interaction, thereby achieving reliable communication.

[0033] In the embodiments of the present disclosure, there is no special limitation on the protocols involved in data interaction. The data interaction of the C / S character communication management model can be implemented using a private protocol or by referring to an open source protocol model.

[0034] In some optional embodiments, since the SLT machine management module and the SLT single board management module run in two different system environments, considering the cross-platform characteristics and the characteristics of the JSON-RPC protocol that can be compatible with both the network port and the serial port, serial port and network port communication is realized through the character-based JSON-RPC (Remote Procedure Call RPC transport protocol) protocol, and the cross-platform and scalability of JSON-RPC and the remote execution function interface are utilized to realize command interaction, status switching, result query and other operations between the SLT machine management module and the SLT single board management module.

[0035] In some examples, the test host computer includes a test command module, a timing management module, and a power-on management module. The test host computer can be used for the test host computer control management module, timing management, robotic arm management, slave computer power-on and power-off management, and client management. The test slave computer includes a test command processing module, a use case distribution module, and a storage management module. The test slave computer can be used for the slave computer test management module (including test command parsing, test thread allocation, etc.), storage management, and server management. The test script data is pre-stored in the storage management module of the test slave computer by the test host computer. When the chip is tested, the test host computer sends a test start instruction to the test slave computer so that the test slave computer determines the corresponding test script data and tests the SOC to be tested, thereby improving the efficiency of chip testing.

[0036] FIG3 is a flow chart of a chip testing method according to an embodiment of the present disclosure.

[0037] In a first aspect, referring to FIG. 3 , an embodiment of the present disclosure provides a chip testing method, including:

[0038] S301, receiving a test start instruction sent by a test host computer, wherein the test start instruction specifies corresponding test script data, and the test script data is pre-stored in the test slave computer;

[0039] S302, testing the target chip according to the test script data corresponding to the test start instruction to obtain a test result;

[0040] S303: Send the test result to the test host computer.

[0041] In embodiments of the present disclosure, test script data is pre-stored on a test slave computer. In some embodiments, after the test script data is transmitted from the test master computer to the test slave computer, the test slave computer stores the test script data in a storage management module. In some embodiments, the storage management module may be a hard disk or other non-volatile memory. When the test script data is subsequently executed, the test slave computer does not need to re-acquire it, effectively simplifying the communication process. During chip testing, the test slave computer receives a test start instruction from the test master computer, which specifies the test script data to be executed on the target chip. The target chip is tested using the corresponding test script data. The test results include a test log snapshot and test exception information for the target chip. This adds a log storage function to record exception information during the test process to facilitate problem location and test report printing. The embodiments of the present disclosure do not impose any specific restrictions on the number of target chips; the number may be one or more. Furthermore, the test script data can be used to test one or more target chips. When multiple target chips are tested sequentially according to the test script data, the test script data does not need to be repeatedly sent, significantly improving the testing efficiency of the target chips.

[0042] 4 , in some embodiments, before S301 , the chip testing method further includes:

[0043] S3001, receiving a power-on instruction sent by the test host computer;

[0044] S3002: Feedback the test environment status to the test host computer according to the power-on instruction.

[0045] 4 , in some embodiments, after S3002 , the chip testing method further includes:

[0046] S3003: When the test environment state does not meet the test conditions and / or it is the first time to be powered on, receive test script data sent by the test host computer;

[0047] S3004. Store the test script data.

[0048] In an embodiment of the present disclosure, test script data is sent to the test slave computer by the test host computer in advance. The test slave computer receives the power-on instruction sent by the test host computer and feeds back the test environment state to the test host computer, and the test environment state refers to the state of the hardware, software, network configuration, etc. for executing the test in the test slave computer. When the test slave computer is powered on for the first time or the test environment state does not meet the test conditions, it means that the current test slave computer does not have the test script data that can be used for executing the test on the target chip. Wherein, the test conditions refer to the environment or device status conditions that need to be met for executing the test script data. The test slave computer receives the test script data sent by the test host computer and stores it after parsing, without the need to transmit the test script data each time, thereby simplifying the communication process between the test host computer and the test slave computer. The test host computer sends a test start instruction, but does not need to send specific test entries (i.e., test script data) through the test host computer each time, thereby improving test efficiency.

[0049] Accordingly, in some embodiments, when the communication interface is a serial port, before S3003, the chip testing method further includes:

[0050] Switch to network port communication.

[0051] In the embodiment of the present disclosure, both the test host computer and the test slave computer are reserved with a network port or serial port for test communication transmission. Compared with the case of communicating with the test host computer only through the serial port, in this case, not only a test instruction needs to be sent to the test host computer, but also test results and test exception information, etc. need to be sent, which is inefficient and has no checksum and retransmission mechanism, and once the parsing command fails, the test will be invalid. Before the test script data of the test slave computer is tested, the serial port is switched to the network port communication. The network port can be used to transmit a large amount of data, that is, it is suitable for application scenarios with a large amount of data, and can speed up the communication transmission speed of the test script data between the two. Further, based on the simplicity and reliability of serial communication, after the test script data transmission is completed, the serial port communication is switched back to so that the test host computer can transmit the test start instruction through the serial port.

[0052] It is worth noting that a client is set up on the test host computer side, and a server is set up on the test slave computer side. When data is transmitted based on the serial port, the data transmitted by the client and the server has a data verification function to reduce the possibility of transmission errors.

[0053] In some optional embodiments, the lightweight character-based C / S (client-server model) communication model includes: an SLT board and an SLT machine, wherein the SLT board serves as a test lower computer and the SLT machine serves as a test upper computer.

[0054] After the SLT board is initialized for formal testing, the SLT machine can use the network port to batch send test script data to the SLT board to speed up communication. After the chip test is officially started, the network port communication is switched back to the serial port communication to achieve reliable communication between the SLT machine and the SLT board; the test results of each chip on the SLT board are then fed back to the SLT machine via the serial port. In addition, when the test of a batch of chips is completed, the test report of the test results of the batch can be fed back to the SLT machine by switching back to the network port. Switching between the network port and the serial port at different stages of the test can effectively avoid the possibility of communication errors in test cases and test results while facilitating the transmission of test commands.

[0055] Furthermore, in some embodiments, S3004 includes:

[0056] Parsing the test script data to obtain a parsing result;

[0057] The parsing results corresponding to the test script data are stored in a designated storage module in a preset data structure and according to a preset fixed format.

[0058] In an embodiment of the present disclosure, a test slave computer parses and stores test script data pre-received from a test master computer, facilitating reuse of test cases corresponding to the test script data. Compared to relying on serial communication to re-receive test script data from the master computer for each chip under test, and executing all test cases after re-parsing them on the test slave computer, pre-parsing and storing the data in a designated storage module reduces testing time and improves efficiency.

[0059] In some examples, the test case can be a KDT (Keyword-driven testing, keyword driven testing) script file format, and the parsing result includes various driver function entries, attributes, parameters, etc. Wherein, the KDT test case of the KDT script file format is parsed to obtain a driver function entry, and further, the driver function entry can be converted into an interface for calling an operating system (i.e., a call interface corresponding to the test case). Attributes are organized in the form of a preset data structure (such as Key-Value), which can be directly parsed for the test distribution engine in the tested lower computer when the test script data is subsequently reused, and provides basic parameters for determining the thread distribution mode for the test case corresponding to the test script data. In addition, the key-value data structure using standard attributes is more convenient for RPC (Remote Procedure Call, remote procedure call) transmission, and is also convenient for realizing the classification and dynamic persistence of the entry of the test case.

[0060] Referring to Figure 5 , the analysis results are stored in a designated storage module in a preset fixed format. If this is the first time the analysis results are stored, they must also be stored on a hard drive or other non-volatile memory so that they can be directly accessed during the next round of testing. The designated storage module can be a hard drive or other non-volatile memory, but this disclosure is not limited to this. The target storage module can be used for fixed data storage and / or dynamic data storage, and can store test results, database-formatted analysis results, and test process logs.

[0061] In some examples, fixed data is stored for the parsing results corresponding to the test script data sent in advance to the test slave computer through a designated storage module. The parsing results are stored in a preset fixed format (such as a designated database format) so that they can be directly parsed by the test distribution engine the next time the parsing results are called, reducing the communication pressure of the test host computer and improving the test efficiency. At the same time, the persistence property of the database can be used to solidify the parsing result data of all test cases corresponding to the test script data into the designated storage module. Subsequently, the pre-parsed parsing results can be read directly from the designated storage module without having to be re-imported from the test host computer, thereby improving the test efficiency. At the same time, the problem of data loss of the parsing results stored after the test slave computer is powered off or restarted, as well as the time-consuming problem of re-executing the test case distribution and parsing can be avoided.

[0062] Referring to Figure 6, in one example, the test slave computer is provided with a script parsing module for executing command processing on the test startup instruction, that is, parsing the test script data corresponding to the test startup instruction to obtain a parsing result. The parsing result includes the name, attributes, the calling interface (i.e., the driver function entry) corresponding to the test case, parameters, and the operating environment, etc., wherein the calling interface includes the Sysfs file system interface, the IO_CTRL command, and the chip SDK (Software Development Kit) library parsing module.

[0063] The analysis results are shown in Table 1:

[0064] Table 1

[0065] In some embodiments, when the communication interface is a network port, before step S302, the chip testing method further includes:

[0066] Switch to serial communication.

[0067] In this embodiment, considering that the use of network port communication during the chip test process may affect the test reliability of the target chip, more specifically, the chip network is also an important component of the chip. If the network port is used to transmit data during the chip test process, it may cause interference with the chip, resulting in inaccurate test results and other problems. Therefore, before the test lower computer tests the target chip, the network port is switched to serial port communication to ensure the reliability of the test results. Similarly, in order to ensure the reliability of the test results, when the serial port is used as the test item content of the chip to be tested, it is necessary to switch to network port communication when testing the test item content.

[0068] 7 , in some embodiments, S302 includes:

[0069] S3021. Determine a distribution mode corresponding to the test script data according to at least one use case description of a test case corresponding to the test script data, wherein the use case description represents a test requirement of the test script data;

[0070] S3022: Parse the test start instruction to determine the target call interface corresponding to the test script data;

[0071] S3023. According to the target calling interface, execute the test script data on the target chip in accordance with the distribution method to obtain a test result.

[0072] In an embodiment of the present disclosure, after the test lower computer receives the test start instruction, the test lower computer can determine at least one test case corresponding to the test script based on the test script data, and the use case description corresponding to the test case represents the test requirements of the test script data. The distribution method is used to represent the execution method of each test case of the test script data corresponding to the test start instruction during the target chip test process. In some examples, the use case description includes at least one of a thread group, a concurrency flag, the number of executions, a delay time, and a reset flag; wherein the thread group is used to group the test cases corresponding to the test script data according to the execution order, the concurrency flag represents the execution order of the test case, the number of executions represents the number of executions of the test case, the delay time represents the time required to complete the execution of the test case, and the reset flag represents restarting when executing the test case. In some embodiments, the use case description may also include a name, a function entry, function parameters, and an operating environment.

[0073] According to the relevance of the use case descriptions between each test case, each test case is abstracted into a sequential linked list and / or a one-way linked list, that is, each test case is arranged in the order of the sequential linked list and / or the one-way linked list to obtain a distribution method. Among them, the execution order of each element in the sequential linked list (i.e., the test cases divided into the list) is the same, that is, these test cases are executed in parallel. The execution order of each element in the one-way linked list (i.e., the test cases divided into the list) is a chain relationship, that is, each element (test case) on the one-way chain should be executed in sequence according to the one-way order and cannot be executed in parallel. It is worth noting that the distribution method disclosed herein is not limited to a sequential linked list or a one-way linked list, and can also be a combination of the two.

[0074] Compared with the traditional test scheme that can only be executed sequentially during the test process and can only be executed partially concurrently in the test driver or test function, the embodiments of the present disclosure can be applied in more complex scenarios. It can use multi-threading characteristics to implement complex scenarios such as thread groups for testing, concurrent execution, sequential execution, reset and recovery.

[0075] The test initiation instruction is parsed to determine the target call interface for each test case in the test script data corresponding to the test initiation instruction. Specifically, the target call interface (e.g., sysfs file system, IO_CTRL, SDK driver function, etc.) that should be invoked to execute the test initiation instruction is determined based on pre-stored parsing results. Using these multiple target call interfaces, the test script data is executed on the target chip in a distributed thread group based on the relevance of the test cases to obtain test results.

[0076] In this embodiment, based on a multi-threaded scheduler, functions such as execution thread groups, concurrent execution, sequential execution, and reset testing are implemented for target chip testing according to the use case descriptions of different test cases. By utilizing the multi-threaded nature and combining it with the flexible nature of test script data, sequential execution, concurrent execution, or breakpoint pauses can be set between test cases for complex testing. The test host computer can generate different test script data based on the use case descriptions of the test cases, increasing test efficiency and dynamically controlling the number of test cycles, thus avoiding the problem of test case coupling affecting actual test results.

[0077] In addition, it is worth noting that in some relevant examples, traditional SLT testing has problems such as long time consumption, low efficiency, and insufficient reliability during the chip screening process. In this embodiment, the test script data can be for one target chip or multiple target chips, and this disclosure is not limited to this. Testing multiple target chips in sequence can effectively solve the problem of whether the SOC can execute tests concurrently or sequentially, thereby increasing the reliability of SLT testing and improving testing efficiency.

[0078] 5, further, the test results are stored in a designated storage module. At the same time, the log snapshots generated during the entire test process can also be stored in the designated storage module to facilitate subsequent test failure analysis and final test report generation.

[0079] Accordingly, in some embodiments, S3021 includes:

[0080] According to the use case description, the test cases are grouped to obtain at least one test group; wherein the test cases in the same test group are non-independent, and the test cases in different test groups are independent of each other;

[0081] According to the test groups, a distribution mode is determined such that the test cases in the mutually independent test groups are executed concurrently, and the non-independent test cases in the test groups are executed sequentially.

[0082] In an embodiment of the present disclosure, test cases are grouped based on the relevance between the test cases, which is characterized by the use case description. In some examples, the relevance includes exclusivity and coupling, which reflect whether the test cases are sensitive to the timing of execution.

[0083] For test cases whose distribution method is determined to be a sequential list, the association with other test cases is non-exclusive and non-coupling, that is, it is not sensitive to execution timing. In one example, in a SOC, the I2C (Inter-Integrated Circuit, I2C bus) controller, SPI controller, and PCIE (Peripheral Component Interconnect Express, high-speed serial computer expansion bus standard) controller are not associated. In this case, the corresponding test cases can simultaneously generate separate threads to execute the test functions, that is, these test cases can be executed in parallel.

[0084] For test cases whose distribution method is determined to be a one-way linked list, there is exclusivity and coupling in the association with other test cases, which means that each test case should be executed in sequence, and each test case should be regarded as a node on the linked list. This ensures the sequential and hierarchical nature of the test, and also ensures the chronological order.

[0085] In one example, testing the memory access performance of a DDR (Double Data Rate) controller and a CPU (Central Processing Unit) cannot be performed simultaneously. If some test cases are destructive and can damage some functions of the target chip, then executing tests related to the damaged functions will affect the reliability of the test results. Therefore, a test interaction sequence should be constructed for the test items, that is, the order of the tests should be restricted (executed in the order of a one-way linked list) to ensure the reliability of the tests.

[0086] In the embodiments of the present disclosure, whether the test cases are independent is not specifically limited. It can be determined based on relevance (i.e., exclusivity and coupling) or in other ways. In some embodiments, the relevance of the test cases is determined according to the use case description, and the test cases are grouped to obtain at least one test group. The test cases in the same test group are non-independent, that is, these test cases can be executed concurrently, and the test cases in different test groups are independent of each other, that is, these test cases cannot be executed concurrently and should be executed sequentially in a certain order.

[0087] Referring to Figure 8, the execution of test cases can be concurrent (i.e., according to the sequence table) or in a certain order (i.e., according to a one-way chain). In some examples, the distribution method can be determined based on the number of executions, thread groups (test groups), delay duration, and reset mark in the use case description.

[0088] The following describes the sequence table and distribution method in detail through specific embodiments:

[0089] In one example, there are ten test cases numbered 0 to 9. The test distribution scenarios according to the distribution method of the sequence table are:

[0090] Referring to Figure 9, the test cases numbered 0, 2, 4, 6, and 8 are completely independent of each other. These test cases can be executed concurrently. These test cases are respectively grouped into sequential tables. When the test lower computer executes these test cases, its case distribution module reads the test vectors in the sequential table respectively and uses independent threads to execute these test cases concurrently.

[0091] The test distribution scenarios according to the distribution method of the one-way linked list are as follows:

[0092] Referring to Figure 10, there is some correlation between the test cases numbered 1, 3, 5, 7, and 9, that is, some different test cases are exclusive and coupled, and some test cases with correlation should be executed sequentially. Among them, there is correlation between the test cases numbered 1, 3, and 5, that is, these test cases are not independent of each other and should be grouped into one test group, group 0. The test cases numbered 7 and 9 are grouped into another group, group 1. Each execution group starts an independent thread, that is, group 0 and group 1 are executed in parallel. When executing each test group, the test thread reads and executes the test vectors in the one-way linked list (group 0 and / or group 1) in sequence, ensuring that while the threads (group 0 and / or group 1) are executed sequentially, the two threads, group 0 and group 1, themselves can run concurrently.

[0093] In some embodiments, S3021 further includes:

[0094] In the case where the use case description includes a reset flag, the test case corresponding to the reset flag is reset.

[0095] In this embodiment, the reset flag is one of the test case descriptions, and the reset flag is used to reset the target chip when executing a test case with the reset flag.

[0096] In some examples, when the target chip needs to undergo complex testing of an aging or restart model, the flag storage is restored according to the reset flag (reset) in the use case description, that is, dynamic storage is achieved through the reset flag to enable continuous testing after restart.

[0097] In one example, as shown in Table 2 and Table 3 below, the test case developed based on KDT is described as follows:

[0098] Table 2

[0099] Table 3

[0100] Reset is the reset flag. When the reset flag is 1, reset and restart are performed. When the reset flag is 0, reset and restart are not performed. Test case 3 (test3) in Table 2 is configured with the use case description reset = 1. When test3 is executed, test 5 will be continued after the restart is completed. At this time, test3 is considered to be a successful test in the test results. In another example (not shown in Table 2), test case 2 (test2) is configured with reset = 0. When test2 is executed, if a reset and restart occurs during the test process, test2 is considered to have failed in the test results, and the remaining unexecuted test cases need to be continued after the restart. At the same time, for each test command, considering the consistency of subsequent command parsing and storage, each test case includes all attribute configuration options to speed up storage parsing consistency and execution speed.

[0101] Table 3 shows the property configuration options for a test case, including variable definition, function execution result, return value, test result text storage, and expected result. The return value is determined by the function execution result. If the function execution result is 0x55, the return value indicates that the PCIE stress test succeeded; otherwise, the return value indicates that the PCIE stress test failed.

[0102] In some embodiments, when the communication interface is a serial port, before step S303, the chip testing method further includes:

[0103] Switch to network port communication.

[0104] In this embodiment, compared with serial port communication, network port communication is more suitable for transmission of large amounts of data. Therefore, when there is no conflict in test functions, network port communication is switched to speed up the transmission of test results.

[0105] The chip testing method in the embodiment of the present disclosure can be applicable to the scenario of complex chip testing, where the complex chip testing may be a scenario with many test items and a large number of chips. The method realizes the reliability communication between the test host computer and the test slave computer, and also realizes the flexible and dynamic combination of test cases (i.e., test start instructions), and optimizes the test function item execution grouping of the target chip. The test grouping can have the characteristics of concurrent execution, sequential execution, reset, recovery and other repeated operation. At the same time, the method also realizes the local storage of test cases and the storage record of the test process operation log and the printing of the final report, so that the test efficiency, scalability and maintainability of the target chip are increased, thereby improving the efficiency of screening chips before large-scale chips leave the factory.

[0106] FIG11 is a flowchart of another chip testing method according to an embodiment of the present disclosure.

[0107] In a second aspect, referring to FIG. 11 , an embodiment of the present disclosure provides a chip testing method, including:

[0108] S1101, sending a test start instruction to a test slave computer, so that the test slave computer tests the target chip according to the test script data corresponding to the test start instruction; wherein the test start instruction specifies the corresponding test script data, and the test script data is pre-stored in the test slave computer;

[0109] S1102: Receive the test result of the target chip fed back by the test slave computer.

[0110] In some embodiments, when the communication interface is a network port, after step 1101, the chip testing method further includes: switching to serial port communication. In this embodiment, since using the network port communication during the test process may affect the test reliability of the target chip, after the test host computer sends a test start instruction to the test slave computer, the serial port communication is switched to ensure the accuracy of the test results, wherein the test start instruction can be sent via the network port.

[0111] In some embodiments, when the communication interface is a serial port, before step 1102, the chip testing method further includes: switching to network communication. In this embodiment, compared to serial communication, network communication is more suitable for transmitting large amounts of data. Therefore, without affecting the reliability of the chip test results, the test host computer switches to network communication to receive the test results fed back by the test slave computer, thereby speeding up the transmission of the test results.

[0112] In an embodiment of the present disclosure, the test start instruction is used to instruct the test slave computer to test the target chip according to the test script data (including multiple test cases) corresponding to the test start instruction.

[0113] In the embodiments of the present disclosure, there is no special limitation on the way in which the test host computer obtains the test results. It can be direct reception, or it can be direct remote calling of the callback entry of the test slave computer to obtain the test results according to needs, or the test host computer can send a request to the test slave computer to realize the distribution of test scripts and the collection of test results.

[0114] In some examples, the receiving end (i.e., the test slave computer) of the test start instruction transmitted via the serial port should feedback the test results to the sending end (i.e., the test slave computer). When the test start instruction is transmitted based on the JSON-RPC request / response message character format, the request message (Request) format for requesting the execution of the test case (i.e., the test start instruction) is:

[0115] After the test is completed, the response message (Respond) format is:

[0116] In some embodiments, before S1101, the chip testing method further includes:

[0117] Sending a power-on instruction to the test slave computer;

[0118] Receive the test environment status fed back by the test slave computer according to the power-on instruction.

[0119] In some embodiments, after receiving the test environment status fed back by the test slave computer according to the power-on instruction, the chip testing method further includes:

[0120] When the test environment state does not meet the test conditions and / or is powered on for the first time, encapsulating the test case according to the test function points corresponding to the test case;

[0121] Combining at least one encapsulated test case to generate test script data;

[0122] The test script data is sent to the test slave computer.

[0123] In some embodiments, when the communication interface is a serial port, before sending the test script data to the test slave computer, the chip testing method further includes: switching to network port communication. That is, the test master computer sends the test script data to the test slave computer via the network port communication.

[0124] In the present embodiment, test script data is made up of at least one test case performed in a certain order. Each test case is developed by KDT model, thereby realizes based on retaining keywords and function keyword method, test case is encapsulated, obtains test script data. Such test script data can be reused after being sent to the test slave computer. Simultaneously based on the encapsulation of test function point, test case reuse efficiency can be improved. On the one hand, drive writing basic module (i.e. test case) by basic system, on the other hand, can drive these basic modules (i.e. test case) by combining and / or splitting structure more complicated, more functional test drive (i.e. test script data) by script test function point characteristic, to realize the parameterization of script.

[0125] In some embodiments, combining at least one encapsulated test case to generate test script data further includes:

[0126] A use case description is configured for the test case, wherein the use case description represents a test requirement of the test script data.

[0127] In the embodiment of the present disclosure, a use case description is configured for each test case in the test script data. Compared with the traditional test method based on the DDT (Data Driven Testing) method, a group of scripts can only process data in a specific format and the more test content, the more related test cases will not be able to be called and encapsulated by each other. The test granularity of the DDT-based test method is single, and a test case needs to be written for each function. However, this embodiment not only allows the test lower computer to directly call the target call interface of the test case, but also can encapsulate the specified "action" (test case). Through the mutual encapsulation inside the test script data, it can be constructed into a more complex test, and the test case reusability is strong. It is worth noting that a variety of tools that support the open source framework KDT feature test function can also be used to realize the generation of test script data.

[0128] In one example, for testing the external GPIO (General-purpose input / output) interrupt characteristics of the target chip, the test script data includes three steps: GPIO configuration, interrupt control configuration, and interrupt triggering. There are already test cases for GPIO configuration and test cases for interrupt control configuration. Therefore, the existing test cases for GPIO configuration and test cases for interrupt control configuration can be directly defined as the encapsulation and call of GPIO test cases, and the GPIO trigger source configuration (i.e., interrupt triggering) can be added, without having to rewrite the existing functional modules, thereby improving the test case reuse efficiency.

[0129] In some embodiments, configuring a use case description for the test case includes at least one of the following:

[0130] Configuring a thread group for the test case, the thread group is used to group the test cases corresponding to the test script data according to an execution order;

[0131] Configuring a concurrency flag for the test case, wherein the concurrency flag represents the execution order of the test case;

[0132] Configuring an execution count for the test case, where the execution count represents the number of times the test case is executed;

[0133] Configuring a delay time for the test case, wherein the delay time represents the waiting time for executing the test case next time;

[0134] A reset flag is configured for the test case, where the reset flag indicates restarting when executing the test case.

[0135] In an embodiment of the present disclosure, a use case description of a test case is explained. The use case description includes at least one of a thread group, a concurrency flag, a number of executions, a delay duration, and a reset flag. By configuring the use case description for the test case, the flexibility of the test content can be effectively improved. The use case description can be set according to the test requirements of the target chip.

[0136] Among them, the concurrency flag (concurrent) represents the execution order of the test cases. The concurrency flag of 0 represents the sequential execution of threads. It can be used together with the thread group (ThreadGroup) to determine the thread that runs the test case in the thread. Only one test thread is allowed to execute the test each time, and the others wait. The concurrency flag of 1 means that a test thread can be assigned to execute the current test case separately.

[0137] The thread group (ThreadGroup) is used to group the test cases corresponding to the test script data according to the execution order, that is, to organize different types of test cases. This flag and the concurrent flag (concurrent) of the test case jointly determine the execution mode of the test case.

[0138] The execution times (time) represents the number of times a test case is executed. In some examples, a test case needs to be executed multiple times. The default value of the execution times in the test case description is 1, which means that the test is only performed once.

[0139] The delay duration (delay) represents the waiting time for executing the test case next time. The default value of the delay duration in the test case description is 0, which means no delay.

[0140] The reset flag (reset) indicates that the test case will be restarted when executing the test case. The reset flag indicates that the test case will cause an active restart (not a fault restart) and continue to execute the remaining test cases after the restart. The default value of the reset flag is 0, which means no reset.

[0141] By pre-storing the test script data in the test slave computer, a test start instruction is sent to the test slave computer during chip testing, so that the test slave computer determines the test script data corresponding to the test start instruction, thereby improving the efficiency of chip testing.

[0142] In a third aspect, referring to FIG. 12 , an embodiment of the present disclosure provides an electronic device, including:

[0143] at least one processor 1201;

[0144] a memory 1202 storing at least one program, which, when executed by at least one processor, enables the at least one processor to implement any one of the aforementioned chip testing methods;

[0145] At least one I / O interface 1203 is connected between the processor and the memory and is configured to implement information exchange between the processor and the memory.

[0146] Among them, the processor 1201 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 1202 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) 1203 is connected between the processor 1201 and the memory 1202, and can realize information interaction between the processor 1201 and the memory 1202, including but not limited to a data bus (Bus), etc.

[0147] In a fourth aspect, referring to FIG. 13 , an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, which implements any of the above-mentioned chip testing methods when the program is executed by a processor.

[0148] In order to enable those skilled in the art to more clearly understand the technical solutions provided by the embodiments of the present disclosure, the technical solutions provided by the embodiments of the present disclosure are described in detail below through specific examples:

[0149] 2 and 14, the test host computer is the SLT machine, and the test slave computer is the SLT board. The interaction process between the SLT machine and the SLT board is as follows:

[0150] On the SLT machine side:

[0151] Communication module initialization: The SLT machine initializes the serial port and network port communication modules, and its communication mode defaults to the serial port mode;

[0152] Start the test lower computer: power on the SLT board and start the timer, which is used to indicate the status of the SLT board after power-on, so as to indirectly verify the basic power-on function of the target chip;

[0153] Client initialization: Initialize the client program in the C / S model and send a request to the SLT board to obtain basic SLT information;

[0154] If the SLT machine powers on the SLT board for the first time, the test script data is sent through the network interface, and after the sending is completed, it switches to serial port communication; if the SLT machine powers on the SLT board for the first time, it directly sends a test start instruction to the SLT board to notify the SLT board to start testing;

[0155] After the SLT board completes the SOC test of the target chip to be tested, it returns the test results uniformly. During this process, if the pre-set timer times out, the test of the target chip is considered to have failed. Otherwise, the SLT machine classifies the test results of the current target chip according to the test results, powers off the SLT board, and repeats the next round of testing;

[0156] Furthermore, after completing all chip tests, the SLT machine prints a test form and returns a test log.

[0157] On the SLT board side:

[0158] Start the test lower computer: receive the SLT board power-on, and start the SLT board system software using the network port, onboard hard disk or other non-volatile memory;

[0159] Communication module initialization: SLT board initializes serial port and network port communication modules, and its communication mode defaults to serial port mode;

[0160] Server initialization: Initialize the server in the C / S model, receive the request information sent by the SLT board, report the basic information of the SLT to the SLT machine, and wait for the host computer to send the test start command;

[0161] Start testing the target chip according to the test start command sent by the SLT machine;

[0162] When powered on for the first time, switch to the network port to receive the test script data sent by the SLT machine; when powered on for a different time, receive the test start command sent by the SLT machine;

[0163] When a test start instruction is received, if the test script data corresponding to the test start instruction is stored locally, the parsed result of the stored test script data can be called to start the test according to the target call interface corresponding to the parsed result; if the test script data corresponding to the test start instruction is not stored locally, a request is sent to the client of the SLT machine through the server to receive the corresponding test script data from the network port. More specifically: first, the test cases corresponding to the test start instruction are classified and organized: the distribution method is determined according to the use case description (concurrency, sequence, thread group, number of executions, etc.); then, the test start instruction is parsed to determine the target call interface to be called, such as the sysfs file system, IO_CTRL, and SDK driver function, etc.; finally, the parsed result of the test script data is stored in the memory in the form of key-value, and further, stored in the hard disk or other non-volatile memory to speed up the operation next time.

[0164] The test case distribution module in the SLT board calls different target call interfaces according to the database that stores the parsed results of the test script data to start testing the target chip, and at the same time switches the communication mode to the serial port mode and returns the test results to the SLT machine.

[0165] The test results and related logs of each target chip to be tested are stored in the hard disk or other non-volatile memory of the SLT board. After all test cases are executed, the SLT machine is notified so that the next chip can be tested.

[0166] By pre-storing the test script data in the test slave computer (if not stored, the test slave computer sends a request to the test host computer to obtain the test script data), when the chip is tested, the test slave computer receives the test start instruction and can determine the test script data corresponding to the test start instruction, thereby improving the efficiency of the chip test.

[0167] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0168] Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A chip testing method, comprising: Receiving a test start instruction sent by a test host computer, wherein the test start instruction specifies corresponding test script data, and the test script data is pre-stored in a test slave computer; Testing a target chip according to the test script data corresponding to the test start instruction to obtain a test result; Sending the test result to the test host computer.

2. The chip testing method according to claim 1, wherein, Before receiving the test start instruction sent by the test host computer, the method further comprises: Receiving a power-on instruction sent by the test host computer; Feedbacking a test environment status to the test host computer according to the power-on instruction.

3. The chip testing method according to claim 2, wherein, After feedbacking the test environment status to the test host computer according to the power-on instruction, the method further comprises: Receiving the test script data sent by the test host computer in the case that the test environment status does not meet the test conditions and / or for the first power-on; Storing the test script data.

4. The chip testing method according to claim 3, wherein, Before receiving the test script data sent by the test host computer in the case that the communication interface is a serial port, the method further comprises: Switching to network port communication.

5. The chip testing method according to claim 3, wherein, Storing the test script data includes: Parsing the test script data to obtain a parsing result; Storing the parsing result corresponding to the test script data in a specified storage module in a preset data structure according to a preset fixed format.

6. The chip testing method according to claim 1, wherein, Before testing a target chip according to the test script data corresponding to the test start instruction to obtain a test result in the case that the communication interface is a network port, the method further comprises: Switching to serial port communication.

7. The chip testing method according to claim 1, wherein Testing a target chip according to the test script data corresponding to the test start instruction to obtain a test result, including: Determining a distribution method corresponding to the test script data according to at least one use case description of a test case corresponding to the test script data, wherein the use case description characterizes a test requirement of the test script data; Parsing the test start instruction to determine a target call interface corresponding to the test script data; Executing the test script data on the target chip according to the target call interface according to the distribution method to obtain a test result.

8. The chip testing method according to claim 7, wherein, Determining a distribution method corresponding to the test script data according to at least one use case description of a test case corresponding to the test script data, including: Grouping the test cases according to the use case description to obtain at least one test group, wherein each test case in the same test group is non-independent, and the test cases in different test groups are independent of each other; Determining that the test cases of the test groups with independent distribution methods are executed concurrently according to the test group, and the non-independent test cases in the test group are executed sequentially.

9. The chip testing method according to claim 7 or 8, wherein, Determining a distribution method corresponding to the test script data according to at least one use case description of a test case corresponding to the test script data, further comprising: Resetting the test case corresponding to the reset flag in the case that the use case description includes a reset flag.

10. The chip testing method according to claim 1, wherein, Before sending the test result to the test host computer in the case that the communication interface is a serial port, further comprising: Switching to network port communication.

11. A chip testing method, comprising: Sending a test start instruction to a lower-level test machine, so that the lower-level test machine tests a target chip according to test script data corresponding to the test start instruction, wherein the test start instruction specifies corresponding test script data, and the test script data is pre-stored in the lower-level test machine; Receiving a test result of the target chip fed back by the lower-level test machine.

12. The chip testing method according to claim 11, wherein, Before sending the test start instruction to the lower-level test machine, the method further comprises: Sending a power-on instruction to the lower-level test machine; Receiving a test environment status fed back by the lower-level test machine according to the power-on instruction.

13. The chip testing method according to claim 12, wherein, After receiving the test environment status fed back by the lower-level test machine according to the power-on instruction, the method further comprises: When the test environment status does not meet the test conditions and / or it is the first power-on, encapsulating the test case according to a test function point corresponding to the test case; Combining at least one encapsulated test case to generate test script data; Sending the test script data to the lower-level test machine.

14. The chip testing method according to claim 13, wherein, Combining at least one encapsulated test case to generate test script data, including: Configuring a use case description for the test case, wherein the use case description represents a test requirement of the test script data.

15. The chip testing method according to claim 14, wherein, Configuring a use case description for the test case, including at least one of the following: Configuring a thread group for the test case, and the thread group is used to group the test cases corresponding to the test script data according to an execution order; Configuring a concurrency flag for the test case, and the concurrency flag represents the execution order of the test case; Configuring an execution count for the test case, and the execution count represents the execution count of the test case; Configuring a delay duration for the test case, and the delay duration represents a waiting time for executing the next test case; Configuring a reset flag for the test case, and the reset flag represents a restart in the case of executing the test case.

16. The chip testing method according to claim 13, wherein, When the communication interface is a serial port, before sending the test script data to the lower-level test machine, the method further comprises: Switching to network port communication.

17. The chip testing method according to claim 11, wherein, When the communication interface is a network port, after sending a test start instruction to the lower-level test machine, the method further comprises: Switching to serial port communication.

18. The chip testing method according to claim 11, wherein, When the communication interface is a serial port, before receiving a test result of the target chip fed back by the lower-level test machine, the method further comprises: Switching to network port communication.

19. An electronic device, comprising: At least one processor; A memory, on which at least one program is stored, and when the at least one program is executed by the at least one processor, the at least one processor implements the chip testing method according to any one of claims 1 to 18.

20. A computer-readable medium, on which a computer program is stored, and the program, when executed by a processor, implements the chip testing method according to any one of claims 1 to 18.

Images