Test method and device, storage medium and program product

Abstract

The embodiment of the invention discloses a test method and device, a storage medium and a program product, and the method comprises the steps: generating a plurality of test threads, concurrently executing the plurality of test threads, obtaining target instance data corresponding to a target test thread from a cache space when each test thread is executed, and sending the target instance data to a server; and generating a target test vector based on the target instance data, storing the target test vector in a storage space, and executing the target test vector based on the target test thread. In the application, the target instance data used for generating the target test vector is stored in the cache space, and the finally obtained target test vector is stored in the storage space, so that when the target test vector is debugged and tested, only the target instance data needs to be adjusted in the cache space, and data in the storage space does not need to be frequently accessed and modified; the adjusting and testing period of the testing vector is shortened, and the overall testing efficiency is improved.

Description

Technical Field

[0001] This application relates to chip testing technology, and in particular to a testing method, apparatus, storage medium, and program product. Background Technology

[0002] Chip testing involves using chip testing equipment to inspect the parameters, functions, or performance of a chip or wafer. Currently, the mainstream chip testing technology is D2S (Dynamic to Static). In D2S technology, test vectors (patterns) for each test item must first be generated, loaded into the test system, and then run within the test system to perform the chip testing.

[0003] In implementing this application, chip testing typically involves a large number of test items. Furthermore, when generating test vectors, D2S technology requires frequent calls to the internal memory interface of the test machine, and the sheer number of test vectors results in low testing efficiency. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a testing method, apparatus, storage medium, and program product.

[0005] One aspect of this application provides a testing method, comprising: generating multiple test threads and concurrently executing the multiple test threads, each test thread being used to run a test item; while executing each test thread, obtaining target instance data corresponding to the target test thread from a cache space, the target instance data including data for generating a target test vector corresponding to the target test item; generating the target test vector based on the target instance data, and storing the target test vector in a storage space to execute the target test vector based on the target test thread.

[0006] Another aspect of this application provides a testing apparatus, comprising: a thread generation module for generating multiple test threads and concurrently executing the multiple test threads, each test thread being used to run a test item; a first thread execution module for obtaining target instance data corresponding to a target test thread from a cache space when executing each test thread, the target instance data including data for generating a target test vector corresponding to a target test item; and a second thread execution module for generating the target test vector based on the target instance data and storing the target test vector in a storage space to execute the target test vector based on the target test thread.

[0007] In another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described method.

[0008] In another aspect of this application, a computer program product is provided, including computer program instructions that, when executed by a processor, implement the method described above.

[0009] The testing method, apparatus, storage medium, and program product in this application embodiment are described. Multiple test threads are generated and executed concurrently. Each test thread runs one test item. During the execution of each test thread, target instance data corresponding to the target test thread is obtained from a cache space. The target instance data includes data used to generate target test vectors corresponding to the target test item. Target test vectors are generated based on the target instance data and stored in the storage space, so that the target test vectors are executed based on the target test thread. In this application embodiment, a test thread is configured for each test item, and the test threads for multiple test items are set to execute concurrently, thereby improving the debugging efficiency and mass production efficiency of chip testing, and thus improving the overall chip testing efficiency. Furthermore, the target instance data used to generate the target test vector is stored in the cache space, and the final target test vector is also stored in the storage space. This means that when debugging the target test vector, only the target instance data in the cache space needs to be adjusted, without frequent access to and modification of the data in the storage space, thereby shortening the debugging cycle of the test vector and further improving the overall testing efficiency.

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

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

[0012] This application can be more clearly understood with reference to the accompanying drawings and the following detailed description, wherein:

[0013] Figure 1 This is a flowchart illustrating a testing method provided in an exemplary embodiment of this application.

[0014] Figure 2 This is a schematic diagram illustrating the example data acquisition method provided in this application.

[0015] Figure 3 This is a flowchart illustrating step S120 provided in an exemplary embodiment of this application.

[0016] Figure 4 This is a flowchart illustrating a testing method provided in another exemplary embodiment of this application.

[0017] Figure 5This is a schematic diagram of the testing method provided in an application example of this application.

[0018] Figure 6 This is a schematic diagram comparing the testing efficiency of D2S mode and PA mode under the debugging test mode provided in an application example of this application.

[0019] Figure 7 This is a structural block diagram of a test apparatus provided in an exemplary embodiment of this application.

[0020] Figure 8 This is a schematic diagram of the structure of an application embodiment of the electronic device of this application. Detailed Implementation

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

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

[0023] It should also be understood that in the embodiments of this application, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.

[0024] It should also be understood that any component, data or structure mentioned in the embodiments of this application can generally be understood as one or more unless explicitly defined or given contrary guidance in the context.

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

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

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

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

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

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

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

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

[0033] In the field of semiconductor chip testing, D2S follows a traditional test vector generation process. First, a test vector template is defined. Then, in the debugging test mode (Learning mode) of the test system, a large number of CAP files are generated according to the specific chip test protocol and the test vector template. These CAP files then need to be manually compiled into CBP files. The test equipment then performs debugging based on the CBP files. The CAP files are manually editable text files, while the CBP files are compiled binary files that can be directly executed by the test equipment hardware. When the test system switches to production test mode (Production mode), the compiled CBP files need to be reloaded before chip functional testing can be performed. Existing D2S technology has significant limitations and efficiency bottlenecks in application, specifically low debugging efficiency: when generating test vectors, D2S needs to frequently modify the internal memory interface of the test equipment to modify the test vectors stored in memory. In complex test scenarios, the number of generated test vectors is often enormous, resulting in low debugging efficiency in this mode, especially when dealing with massive numbers of test vectors, significantly lengthening the debugging cycle.

[0034] Figure 1 This is a schematic flowchart of a testing method provided in an exemplary embodiment of this application. This embodiment can be applied to testing equipment, such as... Figure 1 As shown, the testing method may include the following steps:

[0035] Step S100: Generate multiple test threads and execute multiple test threads concurrently.

[0036] Each test thread runs one test instance. A test instance tests a single functional unit of the Device Under Test (DUT). A functional unit represents the smallest unit that implements a function of the DUT. The DUT can be, for example, a chip or a wafer. The test vector corresponding to a test instance can include the test data used to test the corresponding functional unit. For example, when the DUT is a chip, the functional unit could be a Bluetooth function or a timing function. Accordingly, the test vector corresponding to the test instance testing the functional unit could include: input stimulus signals, expected signals, microinstructions, pins for input stimulus signals, and pins for acquiring response signals.

[0037] In one implementation, multiple test threads can be created, with one test thread assigned to each test item. The concurrent execution of multiple test threads can be achieved using the tools and singleton pattern in the Boost library for implementing Thread Local Storage (TLS).

[0038] Step S110: When executing each test thread, retrieve the target instance data corresponding to the target test thread from the cache space.

[0039] In this embodiment of the application, the test item corresponding to the target test thread can be referred to as the target test item, and the instance data corresponding to the target test item can be determined as the target instance data corresponding to the target test thread.

[0040] The target instance data includes the data used to generate the target test vectors corresponding to the target test items. The target test thread is one of multiple test threads, and the target instance data is stored in a cache. Instance data may include, for example, pins, periods, input signal values, and expected signals.

[0041] In one implementation, the instance data corresponding to each test thread can be stored in a cache space.

[0042] For example, a vector template can be pre-created, which may include the correspondence between test items and test interfaces. The test interfaces corresponding to each test item can be called according to the vector template. Then, the parameter values ​​that need to be configured in the test data to be configured included in each test interface are created. Instance data is constructed from the test interface and the parameter values, and the instance data is stored in the cache space. When the target test thread starts, the instance data corresponding to the target test item is searched in the cache space and used as the target instance data.

[0043] Step S120: Based on the target instance data, generate the target test vector and store the target test vector in the storage space so as to execute the target test vector based on the target test thread.

[0044] In this embodiment, the test vector corresponding to the target test thread can be referred to as the target test vector.

[0045] A test pattern describes the input / expected vector values ​​for different pins within each cycle. Test patterns can include test information required to test the device under test (DUT), stored in binary code. For example, a test pattern can include input timing waveforms and expected timing waveforms in binary code. The chip test equipment can send a series of timing stimuli to the input pins of the DUT based on the input timing waveforms. The output pins of the DUT will then output a series of actual timing waveforms. These actual timing waveforms are compared with the expected timing waveforms; if they match, the DUT functions correctly; otherwise, there is a problem. Storage space can be, for example, located in Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM). Test patterns corresponding to each test thread can be stored in this storage space.

[0046] Based on the pins and cycles included in the target instance data, as well as the corresponding parameter values, a corresponding target test vector can be generated. The target test vector is then sent to the driver and storage space so that the device under test can be tested based on the target test vector.

[0047] For example, multiple test threads can be created and configured, i.e., the test items corresponding to each test thread can be configured, and the multiple test threads can be configured to execute concurrently, i.e., step S100 can be executed. Afterwards, the operations of steps S110 to S120 above can be executed in debug test mode or mass production test mode. Debug test mode is used to debug test vectors. Specifically, the device under test can be tested by executing each test vector to obtain the debugging results. The test vectors can be adjusted according to the debugging results, and then the above operations can be repeated until the test requirements are met to obtain the final test vectors. Mass production test mode is used to perform mass production testing on the device under test. That is, each test vector can be executed to perform mass production testing on the performance or function of the device under test to obtain the corresponding test results.

[0048] In this embodiment, a test thread is configured for each test item, and the test threads for multiple test items are set to execute concurrently. This improves the debugging and mass production efficiency of chip testing, thereby improving the overall testing efficiency of the chip. In addition, the target instance data used to generate the target test vector is stored in the cache space, and the final target test vector is stored in the storage space. This means that when debugging the target test vector, only the target instance data in the cache space needs to be adjusted, without frequent access to and modification of the data in the storage space. This shortens the debugging cycle of the test vector and further improves the overall testing efficiency.

[0049] In some alternative implementations, as described in this application, each test thread corresponds to a cache space.

[0050] Multiple cache spaces can be pre-configured, with one cache space allocated to each test thread. Instance data corresponding to each test thread is stored in that specific cache space. For example, in debug test mode, for each test thread, the instance data modified through Write / Read / Wait operations can be cached in the corresponding Application Programming Interface (API) memory (the cache space corresponding to that test thread).

[0051] Accordingly, step S110 in this application embodiment may include: in response to detecting that instance data is stored in the cache space corresponding to the target test thread, obtaining the instance data as target instance data; in response to detecting that no instance data is stored in the cache space corresponding to the target test thread, generating target instance data based on the target test item, and storing the target instance data in the cache space corresponding to the target test thread.

[0052] In one implementation, when the target test thread is started, the cache space corresponding to the target test thread is accessed to determine whether instance data is stored in the cache space. If instance data is stored in the cache space, the instance data is identified as the target instance data, and a target test vector is generated based on the target instance data. If no instance data is stored in the cache space, the target instance data can be generated using the double-checked locking mode, and the target instance data is stored in the cache space.

[0053] For example, Figure 2 This is a schematic diagram illustrating an example of how instance data is obtained, as provided in this application. For example... Figure 2As shown, multiple TLS stores (caching spaces) can be created using TLS. When the target test thread starts, the singleton factory is accessed to determine the TLS store corresponding to the target test thread. This TLS store is then accessed to check if instance data is stored. If instance data is stored, it is identified as the target instance data and returned. If no instance data is stored, the test interface corresponding to the target test item is obtained. A protocol file containing the parameter values ​​of each test data to be configured in the test interface is then generated. Using a double-checked locking mode, the target instance data is generated based on the test interface and the test protocol. The target instance data is stored in the TLS store and returned. When the target test thread finishes execution, the target test thread is destroyed, and the target instance data is destroyed using the destructor in TLS, thus reclaiming resources (TLS store).

[0054] In this embodiment of the application, when executing the target test thread, it is detected whether there is instance data in the cache space corresponding to the target test thread, and if there is no instance data, the target instance data is generated in a timely manner, thereby ensuring that multiple test threads can be executed concurrently.

[0055] In some alternative implementations, including those in this application, the target instance data can be generated in the following manner:

[0056] S1, obtain the test interface and protocol file corresponding to the target test item.

[0057] The test interface includes multiple test data sets to be configured. The test interface can be, for example, an API. The protocol file can include multiple parameter values, each of which can configure at least one test data set.

[0058] In one implementation, multiple test interfaces can be pre-generated. Each test interface can include multiple test data sets to be configured, and each test interface corresponds to at least one test item. The test data to be configured represents the data that needs to be configured according to the test requirements.

[0059] S2 generates target instance data based on the test interface and the protocol file.

[0060] The target instance data may include: the test interface and the test protocol corresponding to the target test item.

[0061] For example, based on the correspondence between test items and test interfaces in the vector template, the test interface corresponding to the target test item can be obtained, and parameter values ​​corresponding to each test data to be configured can be created based on multiple test data to be configured in the test interface. These parameter values ​​are then set in the protocol file, and the target instance data is composed of the test interface corresponding to the target test item and the protocol file.

[0062] In this embodiment, multiple test interfaces can be pre-generated to obtain the test interface corresponding to the target test item, and then a protocol file including the corresponding parameter values ​​can be generated based on the test interface, thereby improving the efficiency of generating target instance data.

[0063] In some optional implementations, in the embodiments of this application, each test thread also corresponds to a storage space, the test interface may include multiple test data to be configured, and the protocol file may include multiple parameter values.

[0064] Multiple storage spaces can be configured, with one storage space allocated to each test thread. The test vectors corresponding to each test thread can be stored in the storage space corresponding to that test thread. Multiple storage spaces can be configured, for example, in DDR memory.

[0065] Correspondingly, Figure 3 This is a flowchart illustrating step S120 provided in an exemplary embodiment of this application. Figure 3 As shown, step S120 in this embodiment may include the following steps:

[0066] Step S121: Configure multiple parameter values ​​into the corresponding test data to be configured, thereby obtaining multiple configuration test data.

[0067] In one implementation, for each piece of test data to be configured in the target instance data, the parameter value corresponding to that test data can be obtained from the protocol file, and then the parameter value can be configured into the test data to obtain the configured test data. For example, the test data to be configured may be, for instance,...<bit cycle=〝2″pin=〝DIOI″> This indicates that pin configuration is required for the second cycle. The parameter value can be BUS345 (pin identifier). This parameter value can be configured at DIOI to obtain configuration test data.<bit cycle=〝2″pin=〝BUS345″> .

[0068] Step S122: Use the preset test vector generation interface to perform binary conversion on multiple configuration test data to obtain the target test vector, and store the target test vector in the storage space corresponding to the target test thread.

[0069] The preset test vector generation interface is used to perform binary conversion on the data to generate test vectors.

[0070] In one implementation, a preset test vector generation interface (Label End) can be pre-set. The preset test vector generation interface can be called to perform binary conversion on each configured test data to obtain a binary target test vector. The target test vector is then sent to the driver and stored in the storage space corresponding to the target test thread.

[0071] In this embodiment, the pre-set test vector generation interface automatically converts the configured test data into binary data to generate target test vector data, eliminating the need for manual binary conversion and improving the efficiency of target test vector generation, thus enhancing the automation of chip testing.

[0072] Figure 4 This is a flowchart illustrating a testing method provided in another exemplary embodiment of this application. In some alternative implementations, such as... Figure 4 As shown, in the mass production test mode, the following may also be included before step S110:

[0073] Step S200: Check whether the target test vector is stored in the storage space corresponding to the target test thread.

[0074] In the mass production testing mode, before obtaining the target instance data corresponding to the target test thread, that is, when starting the target test thread, the storage space corresponding to the target test thread can be accessed first to determine whether the test vector is stored in the storage space.

[0075] Step S210: In response to the existence of the target test vector in the storage space, execute the target test vector.

[0076] Specifically, when it is determined that the storage space contains a test vector, the test vector is identified as the target test vector, and then the operation of executing the target test vector based on the target test thread is performed.

[0077] Step S220: In response to the absence of a target test vector in the storage space, perform the operation of retrieving the target instance data corresponding to the target test thread from the cache space.

[0078] Specifically, when it is determined that no test vector is stored in the storage space, and that no target test vector exists in the storage space, steps S110 to S120 are executed to generate a target test vector, store the target test vector in the storage space corresponding to the target test thread, and send it to the driver to execute the operation of executing the target test vector based on the target test thread.

[0079] In the application embodiment, there is no specific order of execution between steps S210 and S220.

[0080] In this embodiment of the application, in the mass production test mode, when the absence of a target test vector is detected, a target test vector can be generated immediately, thereby improving test efficiency.

[0081] In some optional implementations, in the embodiments of this application, the target test vector corresponds to a vector identifier, which includes: prefix information and digest information. The prefix information includes the business information corresponding to the target test vector, and the digest information includes the encryption information of the target test vector.

[0082] The target test vector has a unique vector identifier, which consists of prefix information and digest information. The service information indicates the function or performance of the device under test (DUT) to be tested using the target test vector. For example, the service information may include Bluetooth functionality, meaning the target test vector corresponding to this service information is used to test the Bluetooth function of the DUT. The target test vector can be encrypted using encryption algorithms such as Message Digest Algorithm 5 (MD5) to obtain an MD5 value (the encrypted information of the target test vector), which is then used as the digest information of the target test vector.

[0083] Accordingly, the testing method in this application embodiment further includes: in response to the existence of a test vector in the storage space that has the same prefix information as the vector identifier of the target test vector, setting the test vector to a preset file.

[0084] Specifically, when storing a target test vector in either debug or mass production test mode, the system can check the storage space to determine if a test vector with the same prefix information as the target test vector exists. If so, the test vector with the same prefix information is placed in the recycle bin (preset file), and then the target test vector is stored in the storage space. Otherwise, the target test vector is directly stored in the storage space. Simultaneously, the stored test vectors can be automatically categorized and displayed on the interactive interface.

[0085] In this embodiment of the application, the newly added recycle bin mechanism (preset file) can automatically classify batch test vectors based on the prefix information of the test vectors without the user being aware of the entire process. It can also automatically transfer previously existing test vectors with the same prefix information to the recycle bin (preset file), eliminating the need for manual maintenance by the user and improving the user experience.

[0086] In some optional implementations, the testing method in this application embodiment may further include: pre-setting a debug test mode and a mass production test mode, and mode options corresponding to the debug test mode and the mass production test mode respectively; in response to receiving a test selection instruction sent by the user based on the mode option, calling the test mode corresponding to the test selection instruction, and performing the above-mentioned operation of obtaining the target instance data corresponding to the target test thread from the cache space when executing each test thread in the test mode; in response to receiving a test mode switching instruction sent by the user based on the mode option, switching the test mode to the target test mode corresponding to the test mode switching instruction, and concurrently executing the test vectors corresponding to each test thread in the target test mode.

[0087] Both the test mode and the target test mode include: debug test mode and mass production test mode.

[0088] In one implementation, debug test mode and mass production test mode can be pre-created, as well as mode options (Run Option) corresponding to debug test mode and mode options corresponding to mass production test mode. The mode options can be displayed on the interactive display interface. Users can trigger the test selection command for the test mode corresponding to the mode option by selecting the corresponding mode option on the interactive display interface, so that they can enter the corresponding test mode according to the test selection command.

[0089] When switching between debug test mode and mass production test mode, you can select the target test mode to switch to through the mode option. In the target test mode, there is no need to reload the test vectors corresponding to each test thread. The test vectors corresponding to each test thread can be run concurrently directly.

[0090] In one implementation, a test mode interface, UserAPI, can also be set. By editing the code in UserAPI to debug test mode or mass production test mode, testing can be performed in debug test mode or mass production test mode, as well as switching between debug test mode and mass production test mode.

[0091] For example, the testing methods described in this application embodiment can be applied to a testing device. Specifically, the testing device can be a chip testing device. For example, the testing device can be an Automatic Test Equipment (ATE). The testing device may include a host computer and a test head, with a communication connection between the host computer and the test head. The host computer controls the test head to test the device under test. The host computer may include multiple cache spaces and multiple storage spaces.

[0092] In the testing equipment, multiple test threads are created and configured, including configuring the test items corresponding to each test thread and configuring the multiple test threads to execute concurrently. In debug test mode, steps S110 to S120 above can be executed. In mass production test mode, steps S200 to S220 and steps S110 to S120 above can be executed. Mode options can be displayed on the interactive display interface of the host computer, allowing users to select the corresponding test mode and switch between test modes.

[0093] In this embodiment, when switching between debug test mode and mass production test mode, it can be done directly through the mode options corresponding to debug test mode and mass production test mode respectively, without requiring users to manually code, which simplifies the switching method of test mode and improves the automation of chip testing.

[0094] For example, Figure 5 This is a schematic diagram of the testing method provided in an application example of this application. For example... Figure 5 As shown, vector templates can be created, which include the correspondence between test items and test interfaces. Usercode can be created, which includes test programs. Test vectors can be generated and run based on the usercode. Multiple test threads can be created and configured, i.e., configuring the test items corresponding to each test thread and configuring multiple test threads to execute concurrently. Debug test mode can be selected through the mode options corresponding to the debug test mode. In debug test mode, each test thread is executed concurrently. For each test thread, it is checked whether instance data is stored in the cache space corresponding to the test thread. When instance data is detected in the cache space, based on that... Instance data is automatically used to generate test vectors (CBP files). These test vectors are stored in the storage space corresponding to the test thread and also sent to the driver, thus enabling automatic batch loading of test vectors and execution of the test vectors based on the test thread. When it is detected that no instance data is stored in the cache space, the test interface corresponding to the test item of the test thread can be obtained based on the vector template, and a protocol file can be generated. Instance data is then generated based on the test interface and the protocol file, stored in the cache space, and test vectors are automatically generated based on the instance data. These test vectors are then stored in the storage space corresponding to the test thread and sent to the driver, where they are executed based on the test thread.

[0095] By switching the test mode from debug test mode to mass production test mode through the mode options corresponding to the mass production test mode, it is no longer necessary to reload each test vector. Each test thread can be executed in parallel. For each test thread, it checks whether the test vector is stored in the storage space corresponding to the test thread. If the test vector exists in the storage space, it is executed based on the test vector of the test thread. If the test vector does not exist in the storage space, it checks whether the instance data is stored in the cache space corresponding to the test thread. If the instance data is found in the cache space, a test vector is automatically generated based on the instance data, stored in the storage space corresponding to the test thread, and sent to the driver. The test vector is then executed based on the test thread. If the instance data is not found in the cache space, the test interface corresponding to the test item of the test thread can be obtained based on the vector template, and a protocol file can be generated. Instance data is generated based on the test interface and the protocol file, stored in the cache space, and then a test vector is automatically generated based on the instance data. The test vector is stored in the storage space corresponding to the test thread, sent to the driver, and then executed based on the test thread.

[0096] For example, the testing efficiency of the same test project is compared under D2S mode and PA mode (the testing method of this application). D2S mode only supports single-threaded execution and does not support multi-threaded concurrent execution. In debug test mode, each Write / Read / Wait operation in D2S mode modifies the test vector based on the vector template, and the corresponding registers are dynamically refreshed into DDR (memory space) before running the test vector. Additionally, in debug test mode, D2S mode generates a large number of CAP files based on the protocol file and the test vector template; these CAP files need to be manually compiled and converted into test vectors (CBP files).

[0097] Figure 6 This is a schematic diagram comparing the testing efficiency of D2S mode and PA mode under the debugging test mode provided in an application example of this application. For example... Figure 6 As shown, the horizontal axis represents the test mode selected (D2S mode or PA mode), and the vertical axis represents the test duration in milliseconds. Based on Figure 6 As can be seen, in the debug test mode, the test project took 238.572ms to complete in PA mode and 4067.9976ms in D2S mode. It can be seen that the test efficiency of PA mode is much higher than that of D2S mode, with a relative improvement of 94.14%.

[0098] Figure 7 This is a structural block diagram of a testing apparatus provided in an exemplary embodiment of this application. Figure 7 As shown, the testing apparatus may include:

[0099] The thread generation module 300 is used to generate multiple test threads and execute the multiple test threads concurrently, with each test thread used to run one test item;

[0100] The first thread execution module 310 is used to obtain target instance data corresponding to the target test thread from the cache space when executing each test thread. The target instance data includes data used to generate target test vectors corresponding to the target test items.

[0101] The second thread execution module 320 is used to generate the target test vector based on the target instance data, and store the target test vector in the storage space, so as to execute the target test vector based on the target test thread.

[0102] In some optional implementations, each test thread corresponds to a cache space; the step of obtaining the target instance data corresponding to the target test thread from the cache space is further used for:

[0103] In response to detecting that instance data is stored in the cache space corresponding to the target test thread, the instance data is obtained as the target instance data; in response to detecting that no instance data is stored in the cache space corresponding to the target test thread, the target instance data is generated and the target instance data is stored in the cache space corresponding to the target test thread.

[0104] In some optional implementations, generating the target instance data is further used to: obtain the test interface and protocol file corresponding to the target test item; and generate the target instance data based on the test interface and the protocol file.

[0105] In some optional implementations, each test thread also corresponds to a storage space, the test interface includes multiple test data to be configured, and the protocol file includes multiple parameter values;

[0106] The step of generating the target test vector based on the target instance data is further used to: configure the multiple parameter values ​​into the corresponding test data to be configured, thereby obtaining multiple configuration test data; perform binary conversion on the multiple configuration test data using a preset test vector generation interface to obtain the target test vector; and store the target test vector in the storage space corresponding to the target test thread.

[0107] In some optional implementations, in the mass production testing mode, the testing apparatus in this application embodiment further includes:

[0108] The third thread execution module is used to detect whether the target test vector is stored in the storage space corresponding to the target test thread;

[0109] The fourth thread execution module is used to execute the target test vector in response to the existence of the target test vector in the storage space;

[0110] The fifth thread execution module is used to perform the operation of obtaining the target instance data corresponding to the target test thread from the cache space in response to the absence of the target test vector in the storage space.

[0111] In some optional implementations, the target test vector corresponds to a vector identifier, the vector identifier including prefix information and digest information, the prefix information including business information corresponding to the target test vector, and the digest information including encryption information of the target test vector; the testing device in this embodiment further includes:

[0112] The vector classification module is used to set the test vector to a preset file in response to the existence of a test vector in the storage space that has the same prefix information as the vector identifier of the target test vector.

[0113] In some optional implementations, the testing apparatus in this application embodiment further includes:

[0114] The test mode setting module is used to pre-set the debug test mode and the mass production test mode, as well as the mode options corresponding to the debug test mode and the mass production test mode respectively;

[0115] The test selection module is used to respond to receiving a test selection instruction sent by the user based on the mode option, call the test mode corresponding to the test selection instruction, and perform the operation of obtaining the target instance data corresponding to the target test thread from the cache space when executing each test thread in the test mode;

[0116] The test mode switching module is configured to, in response to receiving a test mode switching command sent by the user based on the mode option, switch the test mode to the target test mode corresponding to the test mode switching command, and concurrently execute the test vectors corresponding to each test thread in the target test mode.

[0117] The testing apparatus in this application corresponds to the testing method described above, and the relevant content can be referred to each other. It will not be repeated here.

[0118] The beneficial technical effects of the exemplary test apparatus of this application can be found in the corresponding beneficial technical effects of the exemplary method section described above, and will not be repeated here.

[0119] In addition, embodiments of this application also provide an electronic device, including:

[0120] Memory, used to store computer programs;

[0121] A processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, it implements the test method described in any of the above embodiments of this application.

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

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

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

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

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

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

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

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

[0130] In addition to the methods and apparatus described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the test methods according to various embodiments of this application as described in the foregoing portion of this specification.

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

[0132] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the test methods according to various embodiments of this application described in the foregoing portion of this specification.

[0133] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

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

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

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

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

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

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

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

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

Claims

1. A testing method, characterized in that, include: Multiple test threads are generated and executed concurrently, with each test thread running one test item. When executing each test thread, the target instance data corresponding to the target test thread is obtained from the cache space. The target instance data includes data used to generate the target test vector corresponding to the target test item. Based on the target instance data, the target test vector is generated and stored in the storage space to execute the target test vector based on the target test thread.

2. The method according to claim 1, characterized in that, Each test thread corresponds to a cache space; The step of retrieving the target instance data corresponding to the target test thread from the cache space includes: In response to detecting that instance data is stored in the cache space corresponding to the target test thread, the instance data is obtained as the target instance data; In response to detecting that no instance data is stored in the cache space corresponding to the target test thread, the target instance data is generated and the target instance data is stored in the cache space corresponding to the target test thread.

3. The method according to claim 2, characterized in that, The generation of the target instance data includes: Obtain the test interface and protocol file corresponding to the target test item; Based on the test interface and the protocol file, the target instance data is generated.

4. The method according to claim 3, characterized in that, Each test thread also corresponds to a storage space, the test interface includes multiple test data to be configured, and the protocol file includes multiple parameter values; The step of generating the target test vector based on the target instance data includes: The multiple parameter values ​​are configured into the corresponding test data to be configured, resulting in multiple configured test data. The multiple configuration test data are converted into binary using a preset test vector generation interface to obtain the target test vector, and the target test vector is stored in the storage space corresponding to the target test thread.

5. The method according to any one of claims 1-4, characterized in that, In mass production testing mode, before retrieving the target instance data corresponding to the target test thread from the cache space, the following steps are also included: Detect whether the target test vector is stored in the storage space corresponding to the target test thread; In response to the existence of the target test vector in the storage space, the target test vector is executed; In response to the absence of the target test vector in the storage space, the operation of retrieving the target instance data corresponding to the target test thread from the cache space is performed.

6. The method according to any one of claims 1-5, characterized in that, The target test vector corresponds to a vector identifier, which includes prefix information and digest information. The prefix information includes business information corresponding to the target test vector, and the digest information includes encryption information of the target test vector. The method further includes: In response to the existence of a test vector in the storage space that has the same prefix information as the vector identifier of the target test vector, the test vector is set to a preset file.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: The debug test mode and the mass production test mode are preset, as well as the mode options corresponding to the debug test mode and the mass production test mode respectively; In response to receiving a test selection instruction sent by the user based on the mode option, the test mode corresponding to the test selection instruction is invoked, and the operation of retrieving the target instance data corresponding to the target test thread from the cache space is performed in the test mode when executing each test thread; In response to receiving a test mode switching instruction sent by the user based on the mode option, the test mode is switched to the target test mode corresponding to the test mode switching instruction, and the test vectors corresponding to each test thread are executed concurrently in the target test mode.

8. A testing apparatus, characterized in that, include: The thread generation module is used to generate multiple test threads and execute the multiple test threads concurrently, with each test thread used to run one test item; The first thread execution module is used to obtain target instance data corresponding to the target test thread from the cache space when executing each test thread. The target instance data includes data used to generate target test vectors corresponding to the target test items. The second thread execution module is used to generate the target test vector based on the target instance data, and store the target test vector in the storage space, so as to execute the target test vector based on the target test thread.

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

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

Images