A chip testing method and related equipment

Abstract

This application provides a chip testing method and related equipment. The method includes: performing state consistency processing on the device under test; running a current test case group on the device under test after state consistency processing and obtaining the test results of the current test case group; determining whether a next test case group exists; if so, using the next test case group as the current test case group, executing the steps of performing state consistency processing on the device under test, running the current test case group on the device under test after state consistency processing and obtaining the test results of the current test case group, and determining whether a next test case group exists, until the determination result is negative; if negative, the test ends. This application enhances the sustainability and stability of automated testing.

Description

Technical Field

[0001] This application relates to the field of chip technology, specifically to a chip testing method and related equipment. Background Technology

[0002] With the rapid development of information technology, chips, as core components of electronic devices, are crucial to the performance and reliability of the entire system. In the chip development and manufacturing process, testing plays a vital role in ensuring that the chip functions correctly, performs stably, and meets predetermined quality requirements. However, traditional chip testing methods, especially manual testing, are gradually revealing their limitations when faced with large-scale, highly complex chip testing needs.

[0003] Traditional chip testing processes rely heavily on manual operation. Testers need to manually configure the test environment, input test data, and observe and record test results according to a predetermined test plan and test cases. This testing method is not only inefficient but also prone to errors, especially when dealing with a large number of test cases, making it difficult to guarantee the accuracy and consistency of the tests.

[0004] In recent years, automated testing technology has been widely used in various fields of software development due to its advantages of efficiency, accuracy, and repeatability. However, the application of automated testing technology still faces many challenges. Summary of the Invention

[0005] In view of this, embodiments of this application provide a chip testing method and related equipment to enhance the sustainability and stability of automated testing.

[0006] To achieve the above objectives, the embodiments of this application provide the following technical solutions.

[0007] In a first aspect, embodiments of this application provide a chip testing method, including:

[0008] Perform state consistency processing on the device under test;

[0009] Run the current test case group in the device under test after the state is consistent and obtain the test results of the current test case group;

[0010] Determine if a next test case group exists;

[0011] If so, then the next test case group is used as the current test case group, and the steps of performing state consistency processing on the device under test, running the current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group, and determining whether there is a next test case group, until the determination result is no;

[0012] If not, the test ends.

[0013] Optionally, the step of performing state consistency processing on the device under test includes:

[0014] Determine whether the device under test and its corresponding operating system are bound together; if so, remove the binding relationship.

[0015] Perform a reset operation on the device under test;

[0016] Perform initialization operations on the device under test;

[0017] Bind the device under test to its corresponding operating system.

[0018] Optionally, the test case group is the test case group indicated in the incomplete list, the incomplete list is used to record the incomplete test case groups, and the test case groups are executed sequentially based on the order of the incomplete list;

[0019] Before the step of performing state consistency processing on the device under test, the method further includes: determining the current test case group based on the indications in the incomplete list;

[0020] The determination of whether there is a next test case group specifically involves determining whether there is a next test case group in the incomplete list.

[0021] If so, the next test case group is used as the current test case group. Specifically, based on the indication in the incomplete list, the next test case group is used as the current test case group.

[0022] Optionally, before the step of determining the current test case group based on the indications in the incomplete list, the method further includes:

[0023] Check if an incomplete list exists; if not, create an incomplete list.

[0024] Optionally, after the step of performing state consistency processing on the device under test, and before the step of running the current test case group in the state-consistentized device under test and obtaining the test results of the current test case group, the method further includes:

[0025] Remove the current test case group from the list of uncompleted test cases.

[0026] Optionally, when a synchronization file exists in the testing system, the synchronization file is used to indicate the running status of the test case group; wherein, if the synchronization file exists, the running status of the test case group is abnormal; if the synchronization file does not exist, the running status of the test case group is normal.

[0027] After the step of determining the current test case group based on the indications in the incomplete list, and before the step of performing state consistency processing on the device under test, the method further includes:

[0028] Delete the synchronized file.

[0029] Optionally, before the step of determining whether there is an incomplete list, the method further includes:

[0030] The communication mechanism controls the creation of communication files in the test system, which are used to indicate the status of the test system.

[0031] Optionally, after the step of determining the current test case group based on the indication in the incomplete list, and before the step of performing state consistency processing on the device under test, the method further includes:

[0032] The control test control system creates a runtime file that indicates the running status of the test case group.

[0033] Secondly, embodiments of this application provide a chip testing method applied to a test control system, comprising:

[0034] The control test system executes the chip testing method as described in the first aspect above.

[0035] Optionally, it also includes setting a test time, which is used to indicate the start and end of the test.

[0036] Optionally, setting the test time specifically involves:

[0037] Set the start and end times for the test;

[0038] If the current time is less than the start time, then wait; if the current time is greater than or equal to the start time and less than the end time, then control the test system to execute the chip test method as described in the first aspect above; if the current time is greater than or equal to the end time, then end the test.

[0039] Optionally, before the control test system performs the chip testing method as described in the first aspect above, the method further includes performing online test system operation on the test system to bring the test system online.

[0040] The online operation of the test system includes:

[0041] Perform a reset operation on the test system;

[0042] Perform initialization operations on the test system;

[0043] Establish an effective connection between the test system and the test control system to enable the test system to be online.

[0044] Optionally, after the step of performing online operation of the test system on the test system, and before the step of controlling the test system to perform the chip testing method as described in the first aspect above, the method further includes:

[0045] Determine whether the test system is online;

[0046] If so, the test case group to be tested is sent to the device under test in the test system, and the test system is controlled to execute the chip testing method as described in the first aspect above.

[0047] If not, the online testing system will be executed until the result is yes.

[0048] Optionally, after the step of sending the test case group to be tested to the device under test in the test system, and before the step of controlling the test system to execute the chip testing method as described in the first aspect above, the method further includes:

[0049] The test system is controlled to create a communication mechanism, which is used to control the test system to create communication files, which are used to indicate the status of the test system.

[0050] If the communication file exists, the test system is online; if the communication file does not exist, the test system is offline.

[0051] Optionally, while the control test system performs the chip testing method as described in the first aspect above, it further includes:

[0052] Determine whether the test system is online.

[0053] Optionally, the step of determining whether the testing system is online includes:

[0054] Based on the connection relationship between the test control system and the test system, determine whether the test system is online; or,

[0055] When the test system creates a communication mechanism, it determines whether the test system is online based on the communication file.

[0056] Optionally, in the step of determining whether the test system is online based on the connection relationship between the test control system and the test system while the control test system is executing the chip testing method as described in the first aspect above,

[0057] If the testing system is online, the running status of the test case group is determined based on the synchronization file.

[0058] If the test system is offline, then the step of performing the test system online operation to bring the test system online is executed.

[0059] Optionally, the step of determining whether the running status of the test case group is normal based on the synchronization file includes:

[0060] The test system is controlled to create synchronization files;

[0061] Clear the delay time count value of the synchronized file detection to 0;

[0062] Determine if the synchronization file exists;

[0063] If the synchronization file exists, wait for a preset time, and when the wait is complete, increment the delay time count value of the synchronization file detection by 1. If the delay time count value is greater than the preset value and the current time is less than the end time, then execute the step of performing online operation on the test system to make the test system online.

[0064] If the synchronization file does not exist, the step of determining whether the test system is online is executed, wherein the step of determining whether the test system is online is executed by the test control system while the control test system is executing the chip testing method as described in the first aspect above.

[0065] Optionally, while the control test system is executing the chip testing method as described in the first aspect above, during the step of determining whether the test system is online based on the communication file when the test system creates a communication mechanism,

[0066] If the testing system is online, the running status of the test case group is determined based on the runtime file.

[0067] If the test system is offline, then the step of performing the test system online operation to bring the test system online is executed.

[0068] Optionally, the step of determining whether the running status of the test case group is normal based on the runtime file specifically includes:

[0069] Determine whether the runtime file exists; wherein the runtime file is used to indicate the running status of the test case group; if the runtime file exists, the running status of the test case group is normal; if the runtime file does not exist, the running status of the test case group is abnormal.

[0070] If the running file exists, the running file is deleted, and the delay time count value detected by the running file is cleared to 0. Then, the step of determining whether the test system is online is executed. The step of determining whether the test system is online is executed by the test control system while the control test system is executing the chip testing method as described in the first aspect above.

[0071] If the running file does not exist, wait for a preset time, and when the wait is completed, increment the delay time count value of the running file detection by 1. If the delay time count value is greater than the preset value and the current time is less than the end time, then execute the step of performing online operation on the test system to make the test system online.

[0072] Thirdly, embodiments of this application provide an electronic device, including at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the chip testing method as described in the first aspect above, or to execute the chip testing method as described in the second aspect above.

[0073] Fourthly, embodiments of this application provide a storage medium that stores one or more computer-executable instructions. When the one or more computer-executable instructions are executed, they implement the chip testing method as described in the first aspect above, or implement the chip testing method as described in the second aspect above.

[0074] Fifthly, embodiments of this application provide a computer program product, including one or more computer-executable instructions, which, when executed, implement the chip testing method as described in the first aspect above, or implement the chip testing method as described in the second aspect above.

[0075] This application provides a chip testing method and related equipment. The method includes: performing state consistency processing on the device under test; running a current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group; determining whether there is a next test case group; if so, using the next test case group as the current test case group, executing the steps of performing state consistency processing on the device under test, running the current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group, and determining whether there is a next test case group, until the determination result is negative; if negative, the test ends.

[0076] As can be seen, the chip testing method provided in this application first performs state consistency processing on the device under test, and then runs the current test case group on the device under test after the state consistency processing and obtains the test results of the current test case group. This ensures that the running device of the test case group maintains state consistency, thereby effectively solving the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run, thus enhancing the sustainability and stability of automated testing. Attached Figure Description

[0077] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0078] Figure 1 This is an optional block diagram of a chip testing system;

[0079] Figure 2 This is a schematic diagram of the test process by which the test system tests the device under test;

[0080] Figure 3 This is a schematic diagram of an optional process for the chip testing method provided in the embodiments of this application;

[0081] Figure 4 This is an optional flowchart of step S100 provided in an embodiment of this application;

[0082] Figure 5 This is a schematic diagram of the hardware-level chip testing system provided in the embodiments of this application;

[0083] Figure 6 This is a schematic diagram of the structure of the software-level chip testing system provided in the embodiments of this application;

[0084] Figure 7 This is another optional flowchart of the chip testing method provided in the embodiments of this application;

[0085] Figure 8 This is a schematic diagram of the optional interaction process between the test control system and the test system provided in the embodiments of this application;

[0086] Figure 9 This is a schematic diagram of another optional interaction process between the test control system and the test system provided in the embodiments of this application;

[0087] Figure 10This is a schematic diagram of an optional structure for the effective connection between the test control system and the test system provided in the embodiments of this application. Detailed Implementation

[0088] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0089] As described in the background section, with the rapid development of information technology, chips, as core components of electronic devices, are crucial to the performance and reliability of the entire system. In the chip development and manufacturing process, testing plays a vital role in ensuring the chip functions correctly, performs stably, and meets predetermined quality requirements. However, traditional chip testing methods, especially manual testing, are gradually revealing their limitations when faced with large-scale, highly complex chip testing needs.

[0090] Traditional chip testing processes rely heavily on manual operation. Testers need to manually configure the test environment, input test data, and observe and record test results according to a predetermined test plan and test cases. This testing method is not only inefficient but also prone to errors, especially when dealing with a large number of test cases, making it difficult to guarantee the accuracy and consistency of the tests.

[0091] In recent years, automated testing technology has been widely used in various fields of software development due to its advantages of efficiency, accuracy, and repeatability. However, the application of automated testing technology still faces many challenges.

[0092] To facilitate understanding of chip testing systems, Figure 1 An exemplary block diagram of a chip testing system is shown. For example... Figure 1 As shown, the chip testing system may include a testing system 100 and a device under test (DUT) 101, where the DUT refers to the chip that needs to be tested. By testing the DUT 101 through the testing system 100, it is possible to verify whether the functions of the DUT meet the design specifications and standards, thereby ensuring that the DUT can function normally in practical applications.

[0093] Furthermore, the test process for the test system to test the device under test can be referenced. Figure 2 ,like Figure 2As shown, the testing process is as follows: first, run TestCase1 (test case 1), then run TestCase2 (test case 2), and so on, until all test cases have been run. Running a test case can include running the test script (TestCase.py) and generating test results (TestCase.log). For example, running TestCase1 can include TestCase1.py - running the test script and TestCase1.log - generating test results; running TestCase2 can include TestCase2.py - running the test script and TestCase2.log - generating test results, and so on, until all test cases have been run.

[0094] However, because test cases are executed sequentially—meaning they must run in order—there is a certain correlation between them. This can easily lead to situations where the state of the device under test changes after a previous test case has run, causing subsequent test cases to fail or be unable to continue execution. For example, if TestCase1 fails, TestCase2 and subsequent test cases cannot continue execution. Or, if TestCase1's execution causes a change in the state of the device under test, TestCase2 and subsequent test cases will fail.

[0095] In view of this, embodiments of this application provide a chip testing method, including: performing state consistency processing on the device under test; running a current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group; determining whether there is a next test case group; if so, then using the next test case group as the current test case group, executing the steps of performing state consistency processing on the device under test, running the current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group, and determining whether there is a next test case group, until the determination result is no; if no, then ending the test.

[0096] As can be seen, the chip testing method provided in this application first performs state consistency processing on the device under test, and then runs the current test case group on the device under test after the state consistency processing and obtains the test results of the current test case group. This ensures that the running device of the test case group maintains state consistency, thereby effectively solving the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run, thus enhancing the sustainability and stability of automated testing.

[0097] Based on the above ideas Figure 3An exemplary schematic diagram of an optional flow of a chip testing method provided in an embodiment of this application is shown. This chip testing method is applied to a testing system. Figure 3 As shown, the process of this method may include the following steps.

[0098] Step S100: Perform state consistency processing on the device under test.

[0099] The device under test (DUT) refers to the chip that needs to be tested. The DUT undergoes state consistency processing, and then the current test case group is run on the DUT after state consistency processing. The test results of the current test case group are obtained, thereby ensuring that the running device of the test case group maintains state consistency. This effectively solves the problem that subsequent test case groups cannot continue to execute or fail to run because the state of the DUT changes after the previous test case group has run, thus enhancing the sustainability and stability of automated testing.

[0100] In an optional implementation, state consistency processing of the device under test (DUT) can be achieved through the I / O (input / output) interface of the test system. Specifically, the processor in the test system, such as the CPU, can connect to the DUT via the I / O interface to perform state consistency operation control on the DUT.

[0101] In the optional implementation, to achieve consistent processing of the device under test, Figure 4 An exemplary schematic diagram of an optional process for step S100 in an embodiment of this application is shown. Figure 4 As shown, step S100 can specifically include the following steps:

[0102] Step S101: Determine whether the device under test and its corresponding operating system are bound together.

[0103] If yes, proceed to step S102 to release the binding relationship. If no, proceed to step S103.

[0104] By debinding the device under test (DUT) from its corresponding operating system, it is ensured that the operating system will not interfere with or control the DUT during subsequent reset and initialization operations. In an optional implementation, the DUT and its corresponding operating system can be bound via a device driver, allowing the operating system to control the DUT. Correspondingly, when it is necessary to debind, this can be achieved by uninstalling the device driver, thus providing the necessary conditions for subsequent reset and initialization operations.

[0105] Step S103: Perform a reset operation on the device under test.

[0106] refer to Figure 5 At the hardware level, the processor (e.g., CPU) in the test system can connect to the device under test (DUT) via an I / O (input / output) interface. The DUT may include a state consistency module to control its state consistency. Specifically, the CPU can connect to the reset function within the state consistency module of the DUT via the I / O interface to perform a reset operation on the DUT.

[0107] refer to Figure 6 At the software level, when running a TestCase, the DUT can be reset using the Reset API in the Device Under Test (DUT) application. Figure 6 In this context, DUTDevice Driver refers to the device driver for the device under test (DUT). The DUT and its corresponding operating system can be bound through the device driver so that the operating system can control the DUT.

[0108] It should be noted that the aforementioned binding of the device under test (DUT) and its corresponding operating system through a device driver is merely an example. In practice, the binding of the DUT and its corresponding operating system can also be achieved in other ways, and this application does not limit the specific implementation of the binding method.

[0109] Continue to refer to Figure 4 Then, execute step S104 to initialize the device under test.

[0110] refer to Figure 5 At the hardware level, the processor (e.g., CPU) in the test system can connect to the Device Under Test (DUT) via an I / O (input / output) interface. The DUT may include a state consistency module to control and maintain its state consistency. Specifically, the CPU can connect to the initialization module within the DUT via the I / O interface to perform initialization operations on the DUT.

[0111] refer to Figure 6 At the software level, when running a test case, the DUT can be initialized through the unified interface Init API in the device under test application (also known as the DUT APP).

[0112] Continue to refer to Figure 4 Then, execute step S105 to bind the device under test to its corresponding operating system.

[0113] In an optional implementation, the device under test and its corresponding operating system can be bound together by a device driver, after which the operating system can control the device under test.

[0114] It should be noted that the step of performing state consistency processing on the device under test can be set before running test cases or during the step of running test cases. For example, running test cases may include performing state consistency processing on the device under test, running test scripts, and generating test results. This application embodiment does not impose any limitations on this.

[0115] Continue to refer to Figure 3 Execute step S200, run the current test case group in the device under test after the state consistency processing, and obtain the test results of the current test case group.

[0116] The test case group consists of test cases, which may include one test case or multiple test cases.

[0117] The current test case group is run on the device under test after the state is consistent and the test results of the current test case group are obtained. This ensures that the running device of the test case group maintains the consistency of the state, thereby effectively solving the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run. This enhances the sustainability and stability of automated testing.

[0118] Step S300: Determine if there is a next test case group.

[0119] If so, then the next test case group is used as the current test case group, and the steps of performing state consistency processing on the device under test, running the current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group, and determining whether there is a next test case group, are executed until the determination result is no, that is, all test case groups have been processed.

[0120] If not, proceed to step S400 to end the test.

[0121] As can be seen, the chip testing method provided in this application first performs state consistency processing on the device under test, and then runs the current test case group on the device under test after the state consistency processing and obtains the test results of the current test case group. This ensures that the running device of the test case group maintains state consistency, thereby effectively solving the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run, thus enhancing the sustainability and stability of automated testing.

[0122] In the optional implementation, refer to Figure 7 , Figure 7 This is a schematic diagram of another optional process for the chip testing method provided in the embodiments of this application. For example... Figure 7 As shown, the process may include the following steps:

[0123] Step S110: Determine if there is an incomplete list.

[0124] The incomplete list is used to record groups of test cases that have not been completed.

[0125] If not, proceed to step S111 to create an incomplete list. If yes, proceed to step S112.

[0126] If no incomplete list is found, it indicates that this is the first time the test system has been started to test the device under test. An incomplete list needs to be created to determine the current test case group based on the instructions in the incomplete list.

[0127] Step S112: Based on the indications in the incomplete list, determine the current test case group.

[0128] The test case group is the test case group indicated in the incomplete list. The incomplete list is used to record incomplete test case groups, and the test case groups are executed sequentially based on the order of the incomplete list.

[0129] Step S100: Perform state consistency processing on the device under test.

[0130] The device under test is made consistent with its state. Then, the current test case group is run on the device under test after the state is made consistent and the test results of the current test case group are obtained. This makes the device running the test case group maintain the consistency of its state. This effectively solves the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run. This enhances the sustainability and stability of automated testing.

[0131] Step S210: Remove the current test case group from the list of uncompleted test cases.

[0132] To ensure that the incomplete list contains incomplete test case groups, the current test case group can be removed from the incomplete list after the device under test is processed to ensure state consistency.

[0133] Step S200: Run the current test case group in the device under test after the state consistency processing and obtain the test results of the current test case group.

[0134] The test case group consists of test cases, which may include one test case or multiple test cases.

[0135] The current test case group is run on the device under test after the state is consistent and the test results of the current test case group are obtained. This ensures that the running device of the test case group maintains the consistency of the state, thereby effectively solving the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run. This enhances the sustainability and stability of automated testing.

[0136] Step S300: Determine whether there is a next test case group.

[0137] Specifically, when processing test case groups based on the record content of the incomplete list, step S300 can be as follows: determine whether there is a next test case group in the incomplete list.

[0138] If so (i.e., there is a next test case group), then the next test case group is used as the current test case group. Specifically, based on the indication in the incomplete list, the next test case group is used as the current test case group, thereby returning to execution step S112 and subsequent steps.

[0139] If not (i.e., there is no next test case group), then proceed to step S400 to end the test.

[0140] It should be noted that if there is a next test case group, then the next test case group is used as the current test case group. Specifically, based on the indication in the incomplete list, the next test case group is used as the current test case group. The current test case group can be determined by executing step S112, based on the indication in the incomplete list.

[0141] In an optional implementation, a valid connection can be established between the test control system and the test system, allowing the test control system to control the test system (e.g., via...). Figure 10 The control module in the test control system controls the test system to complete the automated testing of the equipment under test. For details, please refer to... Figure 8 , Figure 8 This is a schematic diagram illustrating the optional interaction flow between the test control system and the test system provided in the embodiments of this application. For example... Figure 8 As shown, the test control system can control the test system to test the device under test. Specifically, the control test system can test the device under test by executing the test methods described above.

[0142] In an optional implementation, before controlling the test system to execute the steps of the test method as described above, the method may further include step S0010, setting the test time. The test time is used to indicate the start and end of the test.

[0143] In a specific implementation, setting the test time for the test control system involves setting the start and end times of the test; if the current time is less than the start time, the system waits; if the current time is greater than or equal to the start time and less than the end time, the system controls the test system to execute the test method applied to the test system as described above; if the current time is greater than or equal to the end time, the test ends.

[0144] Further reference Figure 10 The start and end times of the test can be set by the time setting module in the test control system. However, the start and end times can be set by the operator according to actual needs; this application does not impose any restrictions on this.

[0145] refer to Figure 8 After setting the test time in step S0010, and before controlling the test system to test the device under test in step S001, the following may also be included:

[0146] Execute step S0011 to perform online operation of the test system.

[0147] The test system is brought online by performing online test system operations. The steps of performing these online test system operations may include:

[0148] Step S1: Reset the test system.

[0149] refer to Figure 10 The test system can be reset via a state consistency module. Specifically, a reset function can be configured within the state consistency module to perform the reset operation. Alternatively, the state consistency module can be controlled via the I / O (input / output) interface of the test system to achieve the same reset operation.

[0150] It should be noted that if the test system and the device under test (DUT) are interdependent (e.g., they share a line), the DUT will be passively reset when the test system resets. If the test system and the DUT are independent, a separate state consistency module is required (e.g., ...). Figure 10The state consistency module located within the device under test (DUT) enables the reset of the DUT. Whether the test system and the DUT are independent can be configured according to actual needs; this application does not impose any restrictions on this.

[0151] Step S2: Initialize the test system.

[0152] refer to Figure 10 The test system can be initialized through a state consistency module. Specifically, initialization can be configured within the state consistency module to perform the initialization operation. Alternatively, the state consistency module can be controlled via the I / O (input / output) interface of the test system to achieve the same initialization.

[0153] It should be noted that if the test system and the device under test (DUT) are interdependent (e.g., they share a line), the DUT will be passively initialized simultaneously with the test system's initialization. If the test system and the DUT are independent, a separate state consistency module is required (e.g., ...). Figure 10 The state consistency module located within the device under test (DUT) initializes the DUT. Whether the test system and the DUT are independent can be configured according to actual needs; this application does not impose any restrictions on this.

[0154] Step S3: Establish a valid connection with the test system.

[0155] By establishing an effective connection between the test control system and the test system, the test system can be made online, thereby enabling the test control system to control the test system and complete the automated testing of the device under test.

[0156] Continue to refer to Figure 8 Then, proceed to step S0012 to determine whether the test system is online.

[0157] The test control system can determine whether the test system is online based on the connection between itself and the test system. In other words, the online status of the test system can be determined by checking whether the connection between the test control system and the test system is normal. If the connection is normal, the test system is online; if the connection is abnormal, the test system is offline.

[0158] If yes, the test control system sends the test case set to be tested to the device under test (DUT) and controls the test system to perform the test on the DUT. If no, step S0011 is executed to perform online operation of the test system until the judgment result is yes. The steps for performing online operation of the test system can be referred to the corresponding description above, and will not be repeated here.

[0159] In specific implementation, the test control system can send the test case group to be tested to the device under test of the test system by executing step S0013, and the test system can perform the test on the device under test by executing step S001.

[0160] Step S0013: Send the test case group to be tested to the device under test in the test system.

[0161] The test case group to be tested is sent to the device under test in the test system for testing.

[0162] Step S001: Control the test system to test the device under test.

[0163] While the control test system is testing the device under test, it may also include:

[0164] Step S0014: Determine whether the test system is online.

[0165] Specifically, the online status of the test system can be determined based on the connection between the test control system and the test system. In other words, the online status of the test system can be determined by checking whether the connection between the test control system and the test system is normal. If the connection between the test control system and the test system is normal, the test system is online; if the connection between the test control system and the test system is abnormal, the test system is offline.

[0166] If the test system is online, the running status of the test case group is determined based on the synchronization file; if not (the test system is offline), the step of performing the test system online operation to bring the test system online is executed. The online test system operation can be implemented by executing step S0011. The steps for performing the online test system operation are described above and will not be repeated here.

[0167] The step of determining whether the test case group is running normally based on the synchronization file may include:

[0168] Step S002: Control the test system to create a synchronization file.

[0169] The synchronization file is used to indicate the running status of the test case group; if the synchronization file exists, the running status of the test case group is abnormal; if the synchronization file does not exist, the running status of the test case group is normal. If the test case group in the test system is running normally, the synchronization file will be deleted. Therefore, when the test system has a synchronization file, after the step of running the current test case group in the device under test based on the preset status and obtaining the test results of the current test case group, and before the step of determining whether there is a next test case group, the following step may be included: Step S113, deleting the synchronization file.

[0170] After the test control system controls the test system to create a synchronization file, the delay time count value detected by the synchronization file is cleared to 0. The test control system can then execute step S0015 to determine whether the synchronization file exists. If the determination result is yes (the synchronization file exists), it waits for a preset time and increments the delay time count value detected by the synchronization file by 1 upon completion of the wait. If the delay time count value is greater than the pre-designed value and the current time is less than the end time (whether the delay time count value is greater than the pre-designed value can be determined by executing step S0016, and whether the current time is less than the end time can be determined by executing step S0017), then the step of performing online operation on the test system to bring the test system online is executed. The online operation can be achieved by executing step S0011. The steps for performing online operation can be referred to the corresponding description above and will not be repeated here.

[0171] If the test control system determines that the delay time count value is greater than the pre-designed value and the current time is not less than the end time, then execute step S400 to end the test. If the delay time count value is not greater than the pre-designed value and the current time is equal to or greater than the end time (whether the current time is equal to or greater than the end time can be determined by executing step S0018), then execute step S400 to end the test. If the delay time count value is not greater than the pre-designed value and the current time is not equal to or greater than the end time, then execute step S0015 to determine whether the synchronization file exists.

[0172] If the test control system determines that the result is negative (synchronization file does not exist), then step S0014 is executed to determine whether the test system is online.

[0173] In an optional implementation, step S0014, determining whether the test system is online, and step S0015, determining whether the synchronization file exists, can be determined by... Figure 10 The state detection module in the test control system is implemented.

[0174] In the optional implementation, refer to Figure 9 , Figure 9 This is a schematic diagram of another optional interaction process between the test control system and the test system provided in this application embodiment. For example... Figure 9 As shown, after the step of sending the test case group to be tested to the device under test in the test system, and before the step of controlling the test system to test the device under test, the following may also be included:

[0175] Step S003: Control the test system to create a communication mechanism. The communication mechanism controls the test control system to create a communication file, which indicates the status of the test system. If the communication file exists, the test system is online; if the communication file does not exist, the test system is offline. Correspondingly, on the test system side, before determining whether an incomplete list exists, the following step may also be included: Step S500: Control the test control system to create a communication file based on the communication mechanism (on the test system side, the process of creating a communication file and timed waiting in the test control system will be performed cyclically to ensure that the communication file always exists).

[0176] Furthermore, Figure 9 In step S0014, it is determined whether the test system is online. This can be based on the communication file. That is, if the communication file exists, the test system is online; if the communication file does not exist, the test system is offline.

[0177] If the test system is online, the running status of the test case group is determined based on the runtime file; if not (the test system is offline), the step of performing the test system online operation to bring the test system online is executed. The online test system operation can be implemented by executing step S0011. The steps for performing the online test system operation are described above and will not be repeated here.

[0178] In an optional implementation, when the test system is offline, a communication delay can be added to check the existence of the communication file multiple times. If the communication file is not found after multiple checks, it indicates that the test system is offline.

[0179] In an optional implementation, communication files can be deleted if they exist. Since the test system periodically and repeatedly controls the test control system to create communication files (the test control system is always online, so as long as the test system is online, it can create communication files within the test control system, which can be achieved through a communication mechanism such as a network), after a communication file is deleted from the test control system, it will be recreated within a certain period to determine whether the test system is online.

[0180] In the specific implementation, the step of determining whether the running status of the test case group is normal based on the runtime file is as follows:

[0181] Step S0019: Determine whether the executable file exists.

[0182] The runtime file is used to indicate the running status of the test case group; if the runtime file exists, the running status of the test case group is normal; if the runtime file does not exist, the running status of the test case group is abnormal. Accordingly, on the test system side, after the step of determining the current test case group based on the indication in the incomplete list, and before the step of performing state consistency processing on the device under test, the system may further include: step S600, controlling the test control system to create a runtime file.

[0183] If the judgment result is yes (the running file exists), then the running file is deleted, and the delay time count value detected by the running file is cleared to 0. The test control system can execute step S0014 to determine whether the test system is online.

[0184] Because the test system creates runtime files repeatedly when testing the device under test, after a runtime file is deleted in the test control system, it will be recreated by the test system within a certain period of time to determine the running status of the test case group.

[0185] If the judgment result is negative (the executable file does not exist), wait for a preset time, and increment the delay time count value for executable file detection by 1 upon completion of the wait. If the delay time count value is greater than the pre-designed value and the current time is less than the end time (whether the delay time count value is greater than the pre-designed value can be determined by executing step S0016, and whether the current time is less than the end time can be determined by executing step S0017), then execute the step of performing online operation on the test system to bring the test system online. The online operation can be achieved by executing step S0011. The steps for performing online operation can be referred to the corresponding description above and will not be repeated here.

[0186] If the delay time count is greater than the pre-designed value and the current time is not less than the end time, then execute step S400 to end the test. If the delay time count is not greater than the pre-designed value and the current time is equal to or greater than the end time (whether the current time is equal to or greater than the end time can be determined by executing step S0018), then execute step S400 to end the test. If the delay time count is not greater than the pre-designed value and the current time is not equal to or greater than the end time, then execute step S0014 to determine whether the test system is online.

[0187] In an optional implementation, when the executable file does not exist, the delay time count for executable file detection is incremented by 1. This process is repeated multiple times. If the executable file does not exist after multiple checks, the accumulated delay time count will exceed a pre-designed value, indicating that the test case group has run.

[0188] The status is abnormal.

[0189] In an optional implementation, step S0014, determining whether the test system is online, and step S0019, determining whether the runtime file exists, can be determined by... Figure 10 The state detection module in the test control system is implemented.

[0190] As can be seen, the chip testing method provided in this application first performs state consistency processing on the device under test, and then runs the current test case group on the device under test after the state consistency processing and obtains the test results of the current test case group. This ensures that the running device of the test case group maintains state consistency, thereby effectively solving the problem that the subsequent test case group cannot continue to be executed or fails to run because the state of the device under test changes after the previous test case group is run, thus enhancing the sustainability and stability of automated testing.

[0191] This application also provides an electronic device, which may include at least one memory and at least one processor. The memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the chip testing method applied to a test system as described above, or to execute the chip testing method applied to a test control system as described above.

[0192] This application embodiment also provides a storage medium that stores one or more computer-executable instructions. When the one or more computer-executable instructions are executed, they implement the chip testing method applied to the test system as described above, or implement the chip testing method applied to the test control system as described above.

[0193] This application also provides a computer program product, which may include one or more computer-executable instructions. When the one or more computer-executable instructions are executed, they implement the chip testing method applied to the test system as described above, or implement the chip testing method applied to the test control system as described above.

[0194] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0195] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A chip testing method, characterized in that, include: Perform state consistency processing on the device under test; Run the current test case group in the device under test after the state is consistent and obtain the test results of the current test case group; Determine if a next test case group exists; If so, then the next test case group is used as the current test case group, and the steps of performing state consistency processing on the device under test, running the current test case group in the device under test after state consistency processing and obtaining the test results of the current test case group, and determining whether there is a next test case group, until the determination result is no; If not, the test ends; The step of performing state consistency processing on the device under test includes: determining whether the device under test and its corresponding operating system are bound together; if so, removing the binding relationship; resetting the device under test; initializing the device under test; and binding the device under test to its corresponding operating system. The test case group is the test case group indicated in the incomplete list. The incomplete list is used to record incomplete test case groups, and the test case groups are executed sequentially based on the order of the incomplete list. Before the step of performing state consistency processing on the device under test, the method further includes: determining the current test case group based on the indications in the incomplete list; The determination of whether there is a next test case group specifically involves determining whether there is a next test case group in the incomplete list. If so, the next test case group is used as the current test case group. Specifically, based on the indication in the incomplete list, the next test case group is used as the current test case group.

2. The chip testing method according to claim 1, characterized in that, Prior to the step of determining the current test case group based on the indications in the incomplete list, the method further includes: Check if an incomplete list exists; if not, create an incomplete list.

3. The chip testing method according to claim 2, characterized in that, After the step of performing state consistency processing on the device under test, and before the step of running the current test case group in the state-consistentized device under test and obtaining the test results of the current test case group, the method further includes: Remove the current test case group from the list of uncompleted test cases.

4. The chip testing method according to claim 3, characterized in that, When applied to a testing system, if a synchronization file exists in the testing system, the synchronization file is used to indicate the running status of the test case group; wherein, if the synchronization file exists, the running status of the test case group is abnormal; if the synchronization file does not exist, the running status of the test case group is normal. After the step of determining the current test case group based on the indications in the incomplete list, and before the step of performing state consistency processing on the device under test, the method further includes: Delete the synchronized file.

5. The chip testing method according to claim 4, characterized in that, Before the step of determining whether there is an incomplete list, the following is also included: The communication mechanism controls the creation of communication files in the test system, which are used to indicate the status of the test system.

6. The chip testing method according to claim 3, characterized in that, After the step of determining the current test case group based on the indications in the incomplete list, and before the step of performing state consistency processing on the device under test, the method further includes: The control test control system creates a runtime file that indicates the running status of the test case group.

7. A chip testing method, applied to a test control system, characterized in that, include: The control test system executes the chip testing method as described in any one of claims 1 to 6.

8. The chip testing method according to claim 7, characterized in that, It also includes setting a test time, which is used to indicate the start and end of the test.

9. The chip testing method according to claim 8, characterized in that, The specific steps for setting the test time are as follows: Set the start and end times for the test; If the current time is less than the start time, then wait; if the current time is greater than or equal to the start time and less than the end time, then control the test system to execute the chip test method as described in any one of claims 1 to 6; if the current time is greater than or equal to the end time, then end the test.

10. The chip testing method according to claim 9, characterized in that, Before the control test system performs the chip testing method as described in any one of claims 1 to 6, the method further includes performing online operation on the test system to bring the test system online. The online operation of the test system includes: Perform a reset operation on the test system; Perform initialization operations on the test system; Establish an effective connection between the test system and the test control system to enable the test system to be online.

11. The chip testing method according to claim 10, characterized in that, After the step of performing online operation of the test system on the test system, and before the step of controlling the test system to perform the chip testing method as described in any one of claims 1 to 6, the method further includes: Determine whether the test system is online; If so, the test case group to be tested is sent to the device under test in the test system, and the test system is controlled to execute the chip testing method as described in any one of claims 1 to 6; If not, the online testing system will be executed until the result is yes.

12. The chip testing method according to claim 11, characterized in that, After the step of sending the test case group to be tested to the device under test in the test system, and before the step of controlling the test system to execute the chip testing method as described in any one of claims 1 to 6, the method further includes: The test system is controlled to create a communication mechanism, which is used to control the test system to create communication files, which are used to indicate the status of the test system. If the communication file exists, the test system is online; if the communication file does not exist, the test system is offline.

13. The chip testing method according to claim 12, characterized in that, While the control test system performs the chip testing method as described in any one of claims 1 to 6, it further includes: Determine whether the test system is online.

14. The chip testing method according to claim 13, characterized in that, The step of determining whether the test system is online includes: Based on the connection relationship between the test control system and the test system, determine whether the test system is online; or, When the test system creates a communication mechanism, it determines whether the test system is online based on the communication file.

15. The chip testing method according to claim 14, characterized in that, While the control and testing system executes the chip testing method as described in any one of claims 1 to 6, in the step of determining whether the testing system is online based on the connection relationship between the test control system and the testing system, If the testing system is online, the running status of the test case group is determined based on the synchronization file. If the test system is offline, then the step of performing the test system online operation to bring the test system online is executed.

16. The chip testing method according to claim 15, characterized in that, The step of determining whether the test case group is running normally based on the synchronization file includes: The test system is controlled to create synchronization files; Clear the delay time count value of the synchronized file detection to 0; Determine if the synchronization file exists; If the synchronization file exists, wait for a preset time, and when the wait is complete, increment the delay time count value of the synchronization file detection by 1. If the delay time count value is greater than the preset value and the current time is less than the end time, then execute the step of performing online operation on the test system to make the test system online. If the synchronization file does not exist, the step of determining whether the test system is online is executed, wherein the step of determining whether the test system is online is executed by the test control system while the control test system is executing the chip testing method as described in any one of claims 1 to 6.

17. The chip testing method according to claim 14, characterized in that, While the control test system executes the chip testing method as described in any one of claims 1 to 6, in the step of determining whether the test system is online based on the communication file when the test system creates a communication mechanism... If the testing system is online, the running status of the test case group is determined based on the runtime file. If the test system is offline, then the step of performing the test system online operation to bring the test system online is executed.

18. The chip testing method according to claim 17, characterized in that, The step of determining whether the running status of the test case group is normal based on the runtime file is as follows: Determine whether the runtime file exists; wherein the runtime file is used to indicate the running status of the test case group; if the runtime file exists, the running status of the test case group is normal; if the runtime file does not exist, the running status of the test case group is abnormal. If the running file exists, the running file is deleted, and the delay time count value detected by the running file is cleared to 0. Then, the step of determining whether the test system is online is executed. The step of determining whether the test system is online is executed by the test control system while the control test system is executing the chip test method as described in any one of claims 1 to 6. If the running file does not exist, wait for a preset time, and when the wait is completed, increment the delay time count value of the running file detection by 1. If the delay time count value is greater than the preset value and the current time is less than the end time, then execute the step of performing online operation on the test system to make the test system online.

19. An electronic device, characterized in that, The device includes at least one memory and at least one processor, the memory storing one or more computer-executable instructions, and the processor invoking the one or more computer-executable instructions to perform the chip testing method as described in any one of claims 1 to 6, or to perform the chip testing method as described in any one of claims 7 to 18.

20. A storage medium, characterized in that, The storage medium stores one or more computer-executable instructions, which, when executed, implement the chip testing method as described in any one of claims 1 to 6, or implement the chip testing method as described in any one of claims 7 to 18.

21. A computer program product, characterized in that, It includes one or more computer-executable instructions, which, when executed, implement the chip testing method as described in any one of claims 1 to 6, or implement the chip testing method as described in any one of claims 7 to 18.

Images