Test program generation method, computer equipment and computer readable storage medium

Abstract

The invention provides a test program generation method, computer equipment and a computer readable storage medium, and belongs to the technical field of product testing. The method comprises the following steps: acquiring the type of test equipment and the number of test objects according to program header information input by a user, and determining target test equipment according to the type of the test equipment; according to the test specification of each to-be-tested object, generating structured test information corresponding to each to-be-tested object; according to the structured test information of each to-be-tested object, allocating hardware resources in the target test equipment to each to-be-tested object; and according to the program header information, the structured test information corresponding to each to-be-tested object and the hardware resources allocated to each to-be-tested object, generating a test program conforming to the platform specification of the target test equipment for each to-be-tested object. According to the method, the effects of simplifying the test program development difficulty, shortening the test program development period, improving the test program development efficiency and further improving the test program development stability and reliability can be achieved.

Description

Technical Field

[0001] This application relates to the field of product testing technology, and more specifically, to a test program generation method, a computer device, and a computer-readable storage medium. Background Technology

[0002] Integrated Circuit (IC) testing is a critical step in ensuring that the functionality, performance, and reliability of chips meet design requirements. Automatic Test Equipment (ATE), as the core tool for performing IC testing, directly controls the test process, measurement parameters, and result interpretation. This means that the quality and efficiency of ATE test program development significantly impact chip time-to-market and testing costs. However, to fulfill the testing tasks of a specific IC product, the ATE needs to develop corresponding test programs to define the test process, pin configuration, resource allocation, test item sequence, and judgment logic.

[0003] In related technologies, the development of specific test programs for ATEs mainly relies on text editors. Developers need to have a deep understanding of the target ATE's dedicated instruction set, hardware architecture, and the file organization specifications of specific test programs (such as project file xxx.prj and program source file xxx.prg). Then, using C language or a dedicated scripting language, they must strictly follow the program structure specified by the target ATE and manually write specific test programs in a text editor, including test program headers, pin definitions, file mappings, test item code, and test item execution order.

[0004] However, developing test programs for ATE based on related technologies requires developers to have a deep understanding of the ATE's underlying control instructions, program structure specifications, and hardware resource management mechanisms. This leads to long development cycles and high maintenance difficulty. Furthermore, the complex structure and numerous machine instructions of ATE test programs significantly increase the difficulty of development, impacting their stability and reliability. Summary of the Invention

[0005] The purpose of this application is to provide a test program generation method, computer equipment, and computer-readable storage medium, which can simplify the development of test programs, shorten the development cycle, improve the development efficiency of test programs, and thus enhance the stability and reliability of test program development.

[0006] The embodiments of this application are implemented as follows: A first aspect of this application provides a test program generation method, the method comprising: Based on the program header information input by the user, obtain the type of test equipment and the number of objects to be tested concurrently, and determine the target test equipment based on the type of test equipment and the number of objects to be tested concurrently; Based on the test specifications of each test object, generate structured test information corresponding to each test object. The structured test information includes: test program information, test item information, test clock information, and test logic information. The test program information includes: pin definition information and binary pin definition information. Based on the structured test information of each test object, hardware resources in the target test equipment are allocated to each test object. The hardware resources include power hardware resources and pin hardware resources. Based on the program header information, the structured test information corresponding to each test object, and the hardware resources allocated to each test object, a test program conforming to the platform specifications of the target test equipment is generated for each test object. The test program includes: project files and program source files.

[0007] As one possible implementation, based on the structured test information of each object under test, hardware resources in the target test equipment are allocated to each object under test, including: Based on the number of objects under test, the pin definition information of each object under test, and the available hardware resources of the target test device at the current moment, power hardware resources and pin hardware resources in the target test device are allocated to each object under test in the concurrent test.

[0008] As one possible implementation, the aforementioned idle hardware resources include: an upper limit on the number of idle power supplies and an upper limit on the number of idle pins. Based on the number of objects under test, the pin definition information of each object under test, and the idle hardware resources of the target test device at the current moment, the power supply hardware resources and pin hardware resources of the target test device are allocated to each object under test, including: Based on the number of objects under test and the pin definition information of each object under test, determine the total power supply required for all objects under test in parallel. Based on the total number of power supplies and the upper limit of the number of idle power supplies, determine the target number of power supplies that the target test equipment will provide for all the objects under test in parallel. Based on the number of target power supplies, determine the number of target power supply boards in the target test equipment, and based on the number of target power supply boards, allocate at least one power supply channel for each test object to be tested concurrently. Based on the pin definition information of each test object, determine the number of pins of each test object and the total number of pins of all test objects tested in parallel; Based on the total number of pins and the upper limit of the number of free pins, determine the number of target pins that the target test device provides for all objects under test in parallel. Based on the number of pins corresponding to each chip under test and the number of target pins, logic pins are assigned to each object under test to be tested in parallel, and the mapping relationship between the logic pins of each object under test and the physical logic board is determined.

[0009] As one possible implementation, based on the program header information, the structured test information corresponding to each object under test, and the hardware resources allocated to each object under test, a test program conforming to the platform specifications of the target test device is generated for each object under test, including: Based on the program header information, the pin definition information of each object under test, the pin definition information of each object under test, and the pin hardware resources allocated to each object under test, generate the project file corresponding to each object under test. Based on the test item information, test logic information, and preset test item templates for each test object, the corresponding program source file for each test object is generated.

[0010] As one possible implementation, based on the program header information, the pin definition information of each object under test, the pin definition information of each object under test, and the pin hardware resources allocated to each object under test, a project file corresponding to each object under test is generated, including: Generate the first configuration information based on the program header information; Based on the pin definition information of each test object and the pin hardware resources allocated to each test object, generate the second configuration information; Generate third configuration information based on the Bin pin definition information of each object under test; Based on the first configuration information, the second configuration information, and the third configuration information, project files corresponding to each object to be tested are generated.

[0011] As one possible implementation, the aforementioned test item information includes: multiple test items; based on the test item information of each test object, the test logic information of each test object, and the preset test item template, generating the corresponding program source file for each test object, including: Based on the test items in the test item information of each test object, the standard test template corresponding to each test item is called from the preset test item template, and the test instruction set corresponding to each test item is called through each standard test template respectively; Based on the test instruction set corresponding to each test item, the test parameters contained in each test item are filled into the corresponding standard test template to generate the executable test instruction set corresponding to each test item. The standard test template includes: at least one parameter placeholder, which is used to indicate the variable position of the test parameter to be filled. Based on the test logic information of each test object, the executable test instruction set corresponding to each test item is sequentially written into the control flow code segment to obtain the program source file of each test object.

[0012] As one possible implementation, based on the test logic information of each object under test, the executable test instruction set corresponding to each test item is sequentially written into the control flow code segment to obtain the program source file of each object under test, including: Based on the test logic information of each object under test, determine the execution order of each test item in the test item information of each object under test; In the order of execution, the executable test instructions corresponding to each test item are written into the control flow code segment in sequence to obtain the program source file of each test object.

[0013] As one possible implementation, before allocating hardware resources from the target test equipment to each object under test based on its structured test information, the following steps are also included: The structured test information of each object under test is stored in a pre-built database, and corresponding target codes are generated for the structured test information of each object under test. When the program header information or the test specifications of each object under test change, the corresponding structured test information to be modified is retrieved from the database according to the target code, and the structured test information to be modified is modified.

[0014] A second aspect of this application provides a test program generation apparatus, the apparatus comprising: The device determination module is used to obtain the type of test device and the number of objects to be tested in parallel based on the program header information input by the user, and to determine the target test device based on the type of test device and the number of objects to be tested in parallel. The test information input module is used to generate structured test information for each test object based on the test specifications of each test object. The structured test information includes: test program information, test item information, test clock information, and test logic information. The test program information includes: pin definition information and binary pin definition information. The resource allocation module is used to allocate hardware resources in the target test equipment to each test object based on the structured test information of each test object. The hardware resources include power hardware resources and pin hardware resources. The program generation module is used to generate test programs that conform to the platform specifications of the target test equipment for each test object based on the program header information, the structured test information corresponding to each test object, and the hardware resources allocated to each test object. The test program includes: project files and program source files.

[0015] A third aspect of this application provides a computer device comprising: a memory and a processor, wherein the memory stores a computer program executable on the processor, and when the processor executes the computer program, it implements the steps of the test program generation method described in the first aspect.

[0016] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the test program generation method described in the first aspect.

[0017] The beneficial effects of the embodiments of this application include: This application provides a test program generation method that receives user-input program header information through a graphical testing tool's human-computer interaction interface, parses the header information to obtain the type of test equipment and the number of concurrent test objects, indexes the target test equipment that meets the current testing requirements from multiple test equipment based on the type of test equipment and the number of concurrent test objects, generates structured test information for each test object based on its test specifications, allocates power hardware resources and pin hardware resources from the target test equipment to each test object based on the structured test information, and generates a test program for each test object that conforms to the platform specifications of the target test equipment based on the program header information, the structured test information of each test object, and the allocated hardware resources. Therefore, this application transforms the complex, knowledge-intensive, manually coded test program development work into an intuitive graphical information input graphical test program development tool, which automatically generates the test program. This eliminates the need for developers to deeply understand the underlying control instructions, program structure specifications, and hardware resource management mechanisms of the ATE (Automatic Test Equipment), significantly lowering the development threshold for test programs. In this way, the difficulty of test program development can be simplified, the test program development cycle can be shortened, the test program development efficiency can be improved, and thus the stability and reliability of the test program development can be enhanced. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the first test program generation method provided in this application embodiment; Figure 2A flowchart illustrating the second test program generation method provided in this application embodiment; Figure 3 A flowchart illustrating the third test program generation method provided in this application embodiment; Figure 4 A flowchart illustrating the fourth test program generation method provided in this application embodiment; Figure 5 A flowchart illustrating the fifth test program generation method provided in this application embodiment; Figure 6 A flowchart illustrating the sixth test program generation method provided in this application embodiment; Figure 7 A flowchart illustrating the seventh test program generation method provided in this application embodiment; Figure 8 This is a schematic diagram of the structure of a test program generation device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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 some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] Currently, the development of specific test programs for automated testing equipment mainly relies on text editors. Developers must thoroughly understand the target automated testing equipment's proprietary instruction set, hardware architecture, and the file organization specifications for specific test programs. Then, using C or a dedicated scripting language, they manually write the specific test program in a text editor, strictly adhering to the program structure specified by the target automated testing equipment. This includes the test program header, pin definitions, file mappings, test item code, and test item execution order. However, this approach requires developers to have a deep understanding of the automated testing equipment's low-level control instructions, program structure specifications, and hardware resource management mechanisms. This leads to long development cycles and high maintenance difficulty. Furthermore, the complex structure and numerous machine instructions of automated testing equipment's test programs significantly increase the difficulty of test program development, affecting its stability and reliability.

[0023] To address this, this application provides a test program generation method. The method involves: obtaining the test device type and the number of concurrent test objects input by the user to determine the target test device; generating structured test information for each test object based on its test specifications; allocating hardware resources of the target test device to each test object based on its structured test information; and generating a test program conforming to the platform specifications of the target test device for each test object based on its program header information, the structured test information corresponding to each test object, and the allocated hardware resources. This simplifies test program development, shortens the development cycle, improves development efficiency, and ultimately enhances the stability and reliability of the developed test program.

[0024] The test program generation method provided in the embodiments of this application will be explained in detail below with reference to the accompanying drawings.

[0025] Figure 1 A flowchart illustrating a test program generation method provided in this application is shown. This method can be applied to graphical test program development tools in computer devices. See also... Figure 1 This application provides a test program generation method, including: S101. Based on the program header information input by the user, obtain the type of test equipment and the number of objects to be tested concurrently, and determine the target test equipment based on the type of test equipment and the number of objects to be tested concurrently.

[0026] Optionally, the user inputs program header information through the human-computer interaction interface provided by the graphical test program development tool. The specific program header information is determined by the test development requirements, the test specifications of the object under test, the technical documents of the target test equipment, etc. This application does not make specific limitations on this.

[0027] Optionally, the program header information entered by the user includes: test program name, test program version, test program creation date, author, test device type, and number of concurrent test objects. The test program name, test program version, test program creation date, and author are used to uniquely identify and track the development history of the test program, facilitating version control and document management. The test device type refers to the model of the automated testing device running the currently developed test program. The number of concurrent test objects indicates the number of test objects that the target testing device can simultaneously test in a single run.

[0028] It should be noted that the test program name refers to the name of the test program currently generated by the graphical test development tool, which is also the unique identifier of the test program currently developed by the graphical test development tool. The specific test program name can be customized by the user, and this application does not impose any specific restrictions on it.

[0029] Furthermore, the test program version refers to the version of the test program currently generated by the graphical test development tool; the test program creation time refers to the specific creation time of the test program currently generated by the graphical test development tool; and the author refers to the identifier or name of the developer currently using the graphical test development tool to generate the test program.

[0030] It is worth noting that different automated testing equipment provides testing platforms with different instruction sets, hardware resources, and file format requirements. The type of testing equipment determines the platform specifications followed by the test programs subsequently generated by the graphical test program development tool, ensuring that the generated test programs can be correctly loaded and executed on the target testing equipment. The configuration parameter of the number of concurrent test objects directly affects the hardware resource allocation and testing efficiency of the target testing equipment. The graphical test program development tool can automatically schedule the hardware resources of the target testing equipment according to this configuration parameter during the test program generation process.

[0031] Optionally, the graphical test program development tool determines which test devices meet the customer's specified type based on the type of test device in the program header information entered by the user. Then, based on the number of concurrent test objects in the program header information entered by the user, it selects test devices with available hardware resources to meet the number of concurrent test objects from the test devices that meet the specified type, so as to obtain test devices that meet the test requirements of the test program to be developed, and uses the test device as the target test device for running the final generated test program.

[0032] Furthermore, once the graphical test program development tool uniquely identifies the target test device from the test device library based on the program header information, the tool will pre-configure the hardware constraint rules for that target test device as the basis for subsequent hardware resource allocation decisions. The hardware resources of the target test device include power supply hardware resources and pin hardware resources.

[0033] S102. Based on the test specifications of each test object, generate structured test information corresponding to each test object. The structured test information includes: test program information, test item information, test clock information, and test logic information. The test program information includes: pin definition information and binary pin definition information.

[0034] Optionally, the object to be tested may be a product such as an integrated circuit or a chip; this application does not make any specific limitation in this regard.

[0035] Optionally, the test specification is a basic specification prepared and published by the designer of the object under test. The test specification specifically includes: basic information of the object under test, functional definition of the object under test, test requirements list, test conditions, test vector file, pin definition requirements, parallel test configuration information, pin definition requirements, test equipment recommendation information, etc. This application does not make specific limitations on this.

[0036] The basic information of the device under test (DUT) refers to its model, process node, package type, and withstand temperature. The functional definition of the DUT refers to the pin names, pin types, and electrical characteristics. The test requirements list specifies the tests required for the DUT. Test conditions define the limitations for testing the DUT (e.g., test voltage thresholds, test temperature ranges, clock frequencies, load conditions). Test vector conditions refer to the functional test stimulus data for the DUT. Bin definition requirements specify the mapping rules between the software and hardware bins of the DUT. Pin definition requirements specify the pin definition constraints of the DUT. Parallel test configuration information refers to the board support for the DUT. Recommended test equipment information provides recommended test equipment models for the DUT.

[0037] Optionally, developers input the test requirements for each test object into the human-computer interaction interface provided by the graphical test program development tool, based on the test specifications of each test object. The graphical test program development tool automatically organizes these test requirements into structured test information to provide data support for the automatic generation of subsequent test programs.

[0038] Optionally, the structured test information includes: test program information, test item information, test clock information, and test logic information. The test program information includes: pin definition information and binary pin definition information. Pin definition information indicates the basic information of each pin of the device under test (DUT). Specifically, pin definition information includes: the logical name of each pin on the DUT, the electrical type of each pin (e.g., input IN, output OUT, bidirectional I / O, power supply VCC, ground GND, etc.), and the pin number. Bin definition information indicates the test result classification criteria for the DUT. Specifically, it defines the software and hardware bins of the DUT's test program. Bin definition information defines the test program's bin serial number, the bin name, the numerical designation of the software bin, and the numerical designation of the hardware bin, used to distinguish between test success, test failure, and different performance test results. In addition, the test item information includes multiple specific test items. Each test item specifies the test content that the test object needs to perform (such as open circuit and short circuit tests, functional tests, etc.), the pins of the test object to be tested, the excitation conditions applied to the test object to be tested (such as voltage value, current value, etc.), the expected test limits (such as pass limit, fail limit, etc.), and the Bin number to be assigned for test failure or test success.

[0039] Furthermore, the test clock information is used to define the master clock cycle for testing the object under test, providing a data reference for the timing-related test programs of the object under test. The test clock information is closely related to the accuracy and synchronization of various timing operations in the test items. Correct test clock settings are a prerequisite for ensuring the accuracy of test signal timing.

[0040] In addition, the test logic information defines the execution order of all test items of the object under test. This execution order determines the test flow of the test program. The execution order usually prioritizes fast and high-coverage test items to improve the testing efficiency of the object under test. This application does not make specific limitations on this.

[0041] S103. Based on the structured test information of each test object, allocate hardware resources in the target test equipment to each test object. The hardware resources include: power supply hardware resources and pin hardware resources.

[0042] Optionally, based on the structured test information of each test object and the hardware constraint rules of the target test device, physical hardware resources in the target test device are automatically allocated to each test object in parallel testing to realize the mapping from logical definition to physical channel.

[0043] The hardware resources in the target test equipment include: power hardware resources and pin hardware resources. Power hardware resources refer to the physical hardware resources that provide power channels for the object under test, and pin hardware resources refer to the physical hardware resources that provide logic pins for the object under test.

[0044] S104. Based on the program header information, the structured test information corresponding to each test object, and the hardware resources allocated to each test object, generate a test program for each test object that conforms to the platform specifications of the target test equipment. The test program includes: project files and program source files.

[0045] Optionally, the graphical test program generation tool synthesizes code based on the program header information, the structured test information of each test object, and the hardware resources allocated to each test object to obtain an executable test program that conforms to the platform specifications of the target test device. Specifically, the platform specifications refer to a complete set of rules, standards, formats, and constraints mandated by the target test device for writing and executing test programs; the platform specifications are the standard language connecting the test program logic and the physical hardware of the test device.

[0046] Specifically, the platform specifications for the target test equipment include: API, instruction set and programming interface specifications, compilation, linking and execution process specifications, hardware resources and architecture rules, and file format and organization structure specifications.

[0047] Optionally, the hardware resource and architecture rules define the physical capability limitations and configuration methods of the target test equipment. Specifically, the hardware resource and architecture rules include: board constraints, resource naming and addressing rules, and electrical characteristics and safety limitations. Board constraints specify the maximum number of power channels compatible with the programmable power supply provided by the target test equipment and the maximum number of digital channels supported by the physical logic board. Resource naming and addressing rules refer to the baseline requirements for identifying a specific hardware resource in the target test equipment. Electrical characteristics and safety limitations refer to the safety constraints on the hardware resources in the target test equipment.

[0048] Furthermore, the file format and organization specifications define the organization and storage method of the test program source code. These specifications include: file type and extension, internal file structure, and syntax and delimiters. Specifically, the file type and extension specify the names of the project file and the program source file (e.g., project file is xxx.prj, program source file is xxx.prg); the internal file structure specifies the specific tags, paragraphs, and syntax that must be used to organize the content within the project file and program source file; and the syntax and delimiters specify the syntax and delimiters used in the test program.

[0049] Furthermore, the API, instruction set, and programming interface specifications define how the target test device drives hardware resources based on software programs, forming the basis for generating specific instructions from test item templates. Specifically, the API, instruction set, and programming interface specifications include: API libraries, instruction syntax and parameter order, and reserved words and keywords. An API library is a standard function library providing a series of callable standard functions; instruction syntax and parameter order define the calling format, parameter types, and passing order of each function / instruction; reserved words and keywords are terms with special meanings defined by the target test device.

[0050] Furthermore, the compilation, linking, and execution process specification defines the entire process of a test program running from source code to hardware. Specifically, this specification includes: compilation commands and options, runtime environment requirements, and result feedback mechanisms. The compilation commands and options define how to use the compiler provided by the target test device to compile the program source files into intermediate code or machine code; the runtime environment requirements specify the system state and memory model that need to be initialized when the test program starts; and the result feedback mechanism refers to the feedback path through which test data, test results, and Bin sorting signals are transmitted from the physical hardware back to the software system.

[0051] Optionally, the test program generated by the graphical test program generation tool includes: a project file and a program source file. The project file serves as a resource configuration file, integrating the program header file, a pin definition table containing physical channel mappings, a Bin mapping table, etc.; the program source file serves as the test logic file, containing the specific test execution code.

[0052] In this embodiment, the program header information input by the user is received through the human-computer interaction interface provided by the graphical testing tool, and the program header information is parsed to obtain the type of test equipment and the number of concurrent test objects. Based on the type of test equipment and the number of concurrent test objects, the target test equipment that meets the current test requirements is indexed from multiple test equipment. Based on the test specifications of each test object, structured test information for each test object is generated. Based on the structured test information of each test object, power hardware resources and pin hardware resources in the target test equipment are allocated to each test object. Based on the program header information, the structured test information of each test object, and the hardware resources allocated to each test object, a test program conforming to the platform specifications of the target test equipment is generated for each test object. Therefore, this application transforms the complex, knowledge-intensive, manually coded test program development work into an intuitive graphical information input graphical test program development tool, which automatically generates the test program. This eliminates the need for developers to deeply understand the underlying control instructions, program structure specifications, and hardware resource management mechanisms of the ATE (Automatic Test Equipment), significantly reducing the development threshold for test programs. In this way, the difficulty of test program development can be simplified, the test program development cycle can be shortened, the test program development efficiency can be improved, and thus the stability and reliability of the test program development can be enhanced.

[0053] In one optional implementation, step S103 can specifically be performed as follows: Based on the number of objects under test, the pin definition information of each object under test, and the available hardware resources of the target test device at the current moment, power hardware resources and pin hardware resources in the target test device are allocated to each object under test in the concurrent test.

[0054] Optionally, based on the number of devices under test (DUTs) to be tested simultaneously (indicated by the number of DUTs), the pin list of each DUT (indicated by the pin definition information), and the remaining idle hardware resources of the target test equipment at the current moment, power hardware resources and pin hardware resources are allocated to each DUT being tested concurrently. The pin definition information of each DUT is used to determine the number of independent power supplies and digital channels required for each DUT.

[0055] Specifically, the graphical test program development tool retrieves the hardware configuration information of the target test device from a pre-built test device model database to obtain the board composition, connection method, and inherent resource limits of each board of the target test device.

[0056] The static hardware architecture of the target test equipment includes: the number of independent controllable power channels that each power supply board (DPS Board) can provide (e.g., a power supply board provides two independent controllable power channels, namely DSP1, DPS2, etc.), the number of digital signal channels or logic pins that each physical logic board (Digital Board) can provide (e.g., a physical logic board can provide 128 logic pins, etc.), and the electrical connection relationships between these boards.

[0057] In addition, graphical test program generation tools can query the idle hardware resources of the target test device at the current moment through the test device driver or resource management service interface to ensure that resource conflicts do not occur in subsequent test processes.

[0058] Furthermore, the graphical test program generation tool mainly queries which power supply boards in the target test equipment are occupied, which power channels are provided by the unoccupied power supply boards, which physical logic boards are occupied, which logic pins or digital signal channels are provided by the unoccupied physical logic boards, as well as the status of unoccupied power supply boards and physical logic boards that can be reserved for the current development of test programs, and other dedicated resources on the test equipment (such as precision measurement units, waveform generators, etc.). This application does not make specific limitations in this regard.

[0059] Optionally, the graphical test program generation tool, based on the number of concurrent test objects entered by the developer, the pin definition information of each test object, and the idle hardware resources of the target test device at the current moment, executes a built-in resource allocation algorithm to allocate specific physical hardware resources to each test object in the concurrent test.

[0060] It should be noted that the core objective of the resource allocation algorithm built into the graphical test program generation tool is to allocate the idle hardware resources of the target test equipment while meeting the test requirements of all the test objects being tested, so as to minimize hardware costs (such as reducing the number of power supply boards, physical logic boards, etc.) and ensure optimal electrical performance (such as shortening signal paths and reducing crosstalk).

[0061] In this embodiment, hardware resources are dynamically allocated to each device under test (DUT) based on the real-time status of the target test equipment, improving the overall utilization and scheduling flexibility of the test equipment resources. Furthermore, test developers do not need to understand the complex underlying hardware topology and resource usage of the test equipment, nor do they need to manually calculate power channel or logic pin numbers, eliminating program compilation failures or test anomalies caused by such errors. Moreover, this application uses intelligent algorithms to automatically generate resource layout schemes that are superior in terms of electrical performance and hardware cost, greatly improving the reliability and economy of testing.

[0062] In one optional implementation, the graphical test program generation tool reads idle hardware resources from the target device through the test device driver or resource management service interface, including: an upper limit on the number of idle power supplies and an upper limit on the number of idle pins. The upper limit on the number of idle power supplies refers to the maximum number of power boards corresponding to power channels that are currently unoccupied or unassigned among all programmable power channels of the target test device; the upper limit on the number of idle pins refers to the maximum number of digital signal channels or logic pins that are currently unoccupied or unassigned among all digital signal channels or logic pins of the target test device.

[0063] It should be noted that the number of free pins is usually calculated based on digital signal channels or logic pins that can be assigned in a continuous or logically grouped manner.

[0064] In one alternative implementation, see [link to implementation details]. Figure 2 The specific operation of step S103 above can be as follows: S201. Based on the number of objects under test and the pin definition information of each object under test, determine the total power supply required for all objects under test.

[0065] Optionally, the graphical test program generation tool parses the pin definition information of each test object, identifies which pins in each test object are marked as power types (such as VCC pin, VDD pin, AVDD pin, etc.), and determines an independent power domain for each test object based on its power supply architecture.

[0066] Furthermore, the graphical test program generation tool calculates the total number of independent power channels (i.e., the total number of power supplies) required to power all the test objects under test based on the number of test objects entered by the user, in order to determine the total power requirements of the test objects.

[0067] S202. Based on the total number of power supplies and the upper limit of the number of idle power supplies, determine the target number of power supplies that the target test equipment provides for all the objects under test in parallel.

[0068] Optionally, the graphical test program generation tool compares the total number of power supplies required for all the test objects being tested in parallel with the upper limit of the number of idle power supplies that the target test device can query in real time at the current moment to determine the number of power supplies that the target test device can provide for all the test objects being tested in parallel at the current moment (i.e., the target number of power supplies).

[0069] Specifically, if the upper limit of the number of idle power supplies of the target test equipment is greater than or equal to the total number of power supplies required by all the test objects being tested concurrently, it means that the target test equipment can meet the power requirements of all the test objects being tested concurrently. The graphical test program generation tool can then allocate the power hardware resources of the target test equipment according to the charging requirements of each test object.

[0070] Specifically, if the maximum number of idle power supplies of the target test equipment is less than the total number of power supplies required by all the test objects to be tested concurrently, it means that the idle power hardware resources of the target test equipment at the current moment are insufficient to support the power requirements of all the test objects to be tested concurrently. In this case, the graphical test program generation tool can set the target number of power supplies to the maximum number of idle power supplies of the target test equipment at the current moment, and reduce the actual number of test objects that can be tested concurrently accordingly. The graphical test program generation tool can also trigger a power hardware resource shortage alarm, prompting the test developers to select other test equipment or adjust the test plan. This application does not make specific limitations on this.

[0071] S203. Based on the number of target power supplies, determine the number of target power supply boards in the target test equipment, and based on the number of target power supply boards, allocate at least one power channel to each test object to be tested concurrently.

[0072] Optionally, the graphical test program generation tool can identify the power supply board (i.e., the target power supply board) that can provide power hardware resources from the target test equipment based on the actual number of target power supplies that the target test equipment can provide for all the test objects under test.

[0073] Furthermore, the graphical test program generation tool can determine the number of independent power channels that the target power board provided by the target test equipment can provide based on the static hardware architecture of the target test equipment.

[0074] Optionally, the graphical test program generation tool allocates at least one power channel to each test object under test based on the number of target power boards provided by the target test equipment, and establishes a precise mapping relationship between the pins of the test object and the power boards and power channels of the target test equipment.

[0075] It should be noted that the allocation of power hardware resources is the foundation for ensuring that each chip under test receives independent and stable power, and automated power resource allocation is the basis for ensuring that this step is carried out reliably.

[0076] S204. Based on the pin definition information of each test object, determine the number of pins of each test object and the total number of pins of all test objects tested in parallel.

[0077] Optionally, the graphical test program generation tool can exclude the assigned power supply pins and count the other unassigned pins (such as digital I / O pins, analog input / output pins, clock pins, etc.) based on the pin definition information of each test object to obtain the number of pins of each test object. By summing up the number of pins of each test object tested in parallel, the total number of pins of all test objects tested in parallel can be obtained.

[0078] It should be noted that the number of pins refers to the number of pins of each test object that has not been allocated resources, while the total number of pins refers to the total number of pins of all test objects that have not been allocated resources.

[0079] S205. Based on the total number of pins and the upper limit of the number of idle pins, determine the number of target pins that the target test device provides for all objects under test in parallel.

[0080] Optionally, the graphical test program generation tool compares the total number of pins required by all the test objects under test (DUTs) in parallel with the maximum number of idle pins available on the target test device at the current moment to determine the target number of pins that the target test device can provide for all the DUTs in parallel at the current moment. The maximum number of idle pins refers to the maximum total number of idle logic pins that the target test device can centrally and continuously allocate at the current moment.

[0081] Specifically, if the maximum number of idle pins of the target test device at the current moment is greater than or equal to the total number of pins required by all the test objects under test in parallel, it means that the target test device can meet the digital signal channel requirements of all the test objects under test in parallel. The number of target pins provided by the target test device for all the test objects under test in parallel is equal to the total number of pins required by all the test objects under test in parallel. The graphical test program generation tool can then allocate the pin hardware resources of the target test device to each test object according to the digital signal channel requirements of each test object.

[0082] It should be noted that when the graphical test program generation tool assigns logic pins to each test object, it must strictly adhere to the hardware constraints of the test equipment to ensure that all logic pins assigned to each test object do not exceed the capacity of a single physical logic board, and that the pins are assigned as centrally as possible to reduce the possibility of cross-board assignments.

[0083] S206. Based on the number of pins corresponding to each chip under test and the number of target pins, assign logic pins to each object under test to be tested in parallel, and determine the mapping relationship between the logic pins of each object under test and the physical logic board.

[0084] Optionally, the graphical test program generation tool assigns logic pins to each test object based on the hardware topology of the target test device (such as which logic pins belong to the same physical logic board) and the number and type of unassigned pins corresponding to each test object.

[0085] Furthermore, after the graphical test program generation tool assigns a logic pin to each pin of the unallocated hardware resources of each test object, it binds each pin assigned to each test object to a unique physical channel address to form a precise mapping relationship between pin number, logic pin number, physical logic board number, and digital signal channel.

[0086] In this embodiment, hardware resource requirements are accurately derived from the test specifications of the object under test, avoiding resource waste or insufficiency. Furthermore, the allocation decisions of the graphical test program generation tool are closely integrated with the available hardware resources of the target test device at the current moment, ensuring the executability of hardware resource allocation and improving the development efficiency and reliability of the test program.

[0087] In one alternative implementation, see [link to implementation details]. Figure 3 The specific operation of step S104 above can be as follows: S301. Based on the program header information, the pin definition information of each test object, the pin definition information of each test object, and the pin hardware resources allocated to each test object, generate the project file corresponding to each test object.

[0088] Optionally, the project file (such as the xxx.prj file) serves as a resource configuration list and outline for the test program, and its generation process is a highly structured and automated population process.

[0089] Specifically, the graphical test program generation tool gathers basic information such as program header information (e.g., program name, program version, author, test program creation date, test device type, and number of concurrent test objects), pin definition information of each test object (user-defined logical pin list), pin definition information of each test object (user-defined grading rule table), and pin hardware resources allocated to each test object (power channel mapping table and logical pin mapping table). Then, according to the syntax and tag structure specified by the target test device, it fills this basic information into the standard project file template to obtain the project file corresponding to each test object.

[0090] It should be noted that project documents that conform to the requirements of the target test equipment can accurately describe the hardware environment, resource binding, and classification rules of the test.

[0091] S302. Generate the program source file corresponding to each test object based on the test item information, test logic information, and preset test item templates of each test object.

[0092] Optionally, the program source file (usually an xxx.prg file) carries the specific execution logic and operation sequence of the test, and its generation process is to compile the parameterized test intent into low-level device instructions.

[0093] The test item information for each test object includes: multiple test items entered by the user based on the test specification of the test object and the test parameters corresponding to each test item. The test parameters may specifically be stimulus values, test limits, and criterion bins, etc., which are not specifically limited in this application.

[0094] Optionally, the test logic information for each object under test refers to the execution order of test items set by the developers; the preset test item templates are standard test templates stored in a pre-built test template library, each test item template corresponds to a type of test (such as open circuit and short circuit tests, leakage current tests, and functional tests, etc.), and each test item template is a code framework with parameter placeholders written using the native instructions of the target test device.

[0095] Optionally, for each test item in the test item information, a matching standard test template is called from a pre-built template database, and the specific parameters configured for the test item are automatically filled into the corresponding parameter placeholders of the selected standard test template. After parameter instantiation, the standard test template with filled parameters is converted into an executable program source file.

[0096] In one alternative implementation, see [link to implementation details]. Figure 4 The specific operation of step S301 above can be as follows: S401. Generate the first configuration information based on the program header information.

[0097] Optionally, the graphical test program generation tool processes the program header information, which includes global attributes and execution environment parameters, to obtain first configuration information that conforms to the platform specifications of the target test device.

[0098] Specifically, the graphical test program generation tool, in accordance with the platform specifications of the target test equipment, uses the key fields corresponding to the contents of the program header information as key values ​​and fills them into a specific tag pair to set up the basic framework and running environment for the entire test program.

[0099] The specific tag pair can be the @@START_UP_TABLE tag and the @@END_START_UP_TABLE tag. The first configuration information finally output by the graphical test program generation tool is as follows: @@START_UP_TABLE PROGRAM_NAME = Test program name; PROGRAM_VERSION = Test program version; AUTHOR = author; CREATETIME = Date the test program was created; TESTER_TYPE = Type of test equipment SYSTEM_CLK = clock cycles; TEST_DIE = Number of concurrently tested objects @@END_START_UP_TABLE, this application does not make specific limitations on this.

[0100] Therefore, the first configuration information is a structured program header information used to define the global runtime environment and program framework of the test program.

[0101] S402. Generate second configuration information based on the pin definition information of each object under test and the pin hardware resources allocated to each object under test.

[0102] Optionally, the graphical test program generation tool associates and synthesizes the pin definition information of each test object entered by the user with the pin hardware resources allocated to each test object. For each pin of each test object, based on the pin definition information (such as pin name and pin type), the physical logic board number and logical pin number corresponding to each pin are automatically filled in to obtain a detailed, site-specific pin mapping table. This pin mapping table is then written into a set of specific tag pairs to obtain the second configuration information.

[0103] Specifically, this particular tag can be either the @@PIN_DEFINE_TABLE tag or the @@END_PIN_DEFINE_TABLE tag. The second configuration information ultimately output by the graphical test program generation tool is as follows: @@PIN_DEFINE_TABLE PIN NAME,PIN TYPE,PIN No;SITE1SITE2SITEN A,IN,1;4; 7;n1; B,OUT,2;5; 8;n2; C,IN,3;6; 8;n3; @@@@END_PIN_DEFINE_TABLE, this application does not impose specific limitations on this.

[0104] Therefore, the second configuration information is specifically a structured pin mapping table, which contains the mapping relationship between the pin name, pin type, pin number, physical logic board number corresponding to the pin, and logic pin number corresponding to the pin for each object under test.

[0105] S403. Generate third configuration information based on the Bin pin definition information of each object under test.

[0106] Optionally, the graphical test program generation tool converts the pin definition information of each test object into instructions (i.e., third configuration information) used by the target test device to classify the test results.

[0107] Specifically, the graphical test program generation tool reads the Bin definition information corresponding to each test item entered by the user, arranges the Bin definition information according to the syntax of the platform specification of the target test device, and fills in the specific tag pairs corresponding to the values ​​to obtain the third configuration information.

[0108] Specifically, the specific tag pairs include: @@BIN_MAP and @@END_BIN_MAP tags, @@SOFTWARE_BIN_GOOD_DVC and @@END_SOFTWARE_BIN_GOOD_DVC tags. The @@BIN_MAP tag pair is used to convert the Bin definition information of each test object into a structured Bin mapping table, and the @@SOFTWARE_BIN_GOOD_DVC tag is used to limit the test result classification rules for each test object. The third configuration information is as follows: @@BIN_MAP BIN SERIAL,BIN NAME,SBIN NO,HBIN NO; 1,PASS,1,1; 2,OS_FAIL,2,2; 3,OTHER_FAIL,3,3; @@END_BIN_MAP and @@SOFTWARE_BIN_GOOD_DVC GOOD1=1; @@END_SOFTWARE_BIN_GOOD_DVC, this application does not specifically limit this.

[0109] Therefore, the third configuration information provides the classification rules for each object under test and the correspondence between software Bin and hardware Bin.

[0110] S404. Based on the first configuration information, the second configuration information, and the third configuration information, generate the project file corresponding to each object to be tested.

[0111] Optionally, the graphical test program generation tool writes the first configuration information, the second configuration information, the third configuration information, and other necessary fixed-format paragraphs or tags into a standard project file template according to the file structure and tag order specified by the platform specifications of the target test equipment. After format verification, the project file corresponding to each test object is obtained.

[0112] It should be noted that this project file is a configuration file that conforms to the syntax requirements of the target test device and can be directly compiled or loaded and recognized by it. It accurately defines the test hardware environment, resource binding, and result classification rules.

[0113] In one alternative implementation, see [link to implementation details]. Figure 5 The above test item information includes: multiple test items, and the specific operation of step S302 can be as follows: S501. Based on the test items in the test item information of each test object, call the standard test template corresponding to each test item from the preset test item template, and call the test instruction set corresponding to each test item through each standard test template.

[0114] Optionally, the graphical test program generation tool retrieves and calls the corresponding standard test template from a pre-built test item template database for each test item in the test item information of each test object under test and the test type specified for each test item (such as open circuit and short circuit test, DC parameter test, etc.), and calls the test instruction set corresponding to the test item through the called standard test template.

[0115] Each standard test template is a pre-written code framework that conforms to the platform specifications of the target test device. Each standard test template includes one or more parameter placeholders, which indicate the location of the specific test parameters that need to be replaced when the template is instantiated.

[0116] It should be noted that each standard test template is essentially associated with a set of underlying, existing test instructions. When a standard test template is invoked, it means that the test instruction set associated with this standard test template will be used to build the final test code.

[0117] S502. Based on the test instruction set corresponding to each test item, fill the test parameters contained in each test item into the corresponding standard test template to generate an executable test instruction set corresponding to each test item. The standard test template includes: at least one parameter placeholder, which is used to indicate the variable position of the test parameter to be filled.

[0118] Optionally, the graphical test program generation tool reads the test parameters of each test item from the test item information of each object under test, and fills the test parameters contained in each test item into the parameter placeholders corresponding to the standard test template based on the underlying test instruction set corresponding to each test item. This achieves precise variable replacement, ensuring that each test parameter can be correctly deployed to the corresponding position in the instruction sequence. After completing the filling of all test parameters, the original abstract standard test template with parameter placeholders is transformed into a specific, executable test instruction set. This executable test instruction set is a complete and syntactically correct set of test instruction code that can drive the target test device to independently execute a specific test operation.

[0119] Specifically, graphical test program generation tools often encapsulate this set of executable test instructions within a specific tag pair. This specific tag pair can be the @@PLAN tag and the @@END_PAN tag, resulting in the following encapsulated content: @@PLAN Test Item Name / / Power on LOGIC_FORCE_DPS (Driver pin, 0.0V (voltage), 200mA (clamping current)); / / Machine instruction WAIT(1MS); / / Machine instruction LOGIC_CLOSE_DPS_OUTPUT_RELAY (Driver Pin, ON, WAIT=1.0MS); / / Machine instruction WAIT(3MS); / / Machine command LOGIC_SET_DRV_LEVEL(ALLPINS,0.0V,0.0V,0.0V,VR2); / / Machine instruction LOGIC_CLOSE_PE_RELAY(ALLPINS,WAIT=0.5MS); / / Machine command LOGIC_PMU_FI_MV_SHORT_PIN(ALLPINS,-2V,-100UA,I3,UP_LIMIT=-0.2V,DOWN_LIMIT=-1.2V,WAIT=300US,LOG_ALIAS=OS_GND_[GROUP],LOG_UNIT=V); LOGIC_CLOSE_PE_RELAY(NULL,WAIT=0.5MS); / / Machine instruction @@END_PLAN, this application does not specifically limit this.

[0120] S503. Based on the test logic information of each test object, write the executable test instruction set corresponding to each test item into the control flow code segment in sequence to obtain the program source file of each test object.

[0121] Optionally, the graphical test program generation tool determines the execution order of all test items corresponding to each test object based on the test logic information of each test object, and writes the executable test instruction set corresponding to each test item into the control flow code segment in sequence according to this execution order to obtain the program source file of each test object.

[0122] The control flow code segment is created by a graphical test program generation tool. The control flow code segment does not contain specific test instructions, but defines the execution blueprint of the test.

[0123] Specifically, the graphical test program generation tool writes the identifiers of the executable test instructions corresponding to each test item into the control flow code segment in the order specified by the test logic information to obtain the program source file.

[0124] Furthermore, the control flow code segment is encapsulated by a pair of dedicated flow control tags, specifically the @@BOOKING tag and the @@END_BOOKING tag. The control flow code segment is as follows: @@BOOKING Test item 1; Test item 2; Test item 3; … Test item N @@END_BOOKING.

[0125] Optionally, the graphical test program generation tool combines the control flow code segment with all the independent, encapsulated executable test instruction set code according to the file structure required by the platform specification of the target test device to obtain a complete program source file, which defines the test execution flow.

[0126] In one alternative implementation, see [link to implementation details]. Figure 6 The specific operation of step S403 above can be as follows: S601. Based on the test logic information of each test object, determine the execution order of each test item in the test item information of each test object.

[0127] Optionally, the graphical test program generation tool extracts the execution order of each test item of each test object from the test logic information of each test object to determine the order in which each test item of each test object is executed.

[0128] Furthermore, the graphical test program generation tool internally verifies the execution order of the extracted test lines to ensure that all test items are executed without duplication or conflict.

[0129] S602. In accordance with the execution order, write the executable test instructions corresponding to each test item into the control flow code segment in sequence to obtain the program source file of each test object.

[0130] Optionally, the graphical test program generation tool sequentially writes the executable test instruction set corresponding to each test item into the control flow code segment according to the platform specification requirements of the target test device, in the order of execution of each test item. After all test items of the object under test have been written into the control flow code segment, the program source file of each object under test can be obtained.

[0131] Therefore, it can be seen that the control flow code segment and each set of executable test instructions together constitute the main body of the program source file.

[0132] In one alternative implementation, see [link to implementation details]. Figure 7 Before "allocating hardware resources in the target test equipment to each test object based on the structured test information of each test object", the above test program generation method also includes: S701. Store the structured test information of each object under test into a pre-built database, and generate corresponding target codes for the structured test information of each object under test.

[0133] Optionally, the graphical test program generation tool saves the structured test information of each test object as a complete data set to a pre-built database. While storing the data, the graphical test program generation tool automatically generates a globally unique target code for the structured test information of each test object.

[0134] Specifically, the target code is usually generated using algorithms such as UUID (Universally Unique Identifier) ​​to ensure the uniqueness of the structured test information in the database. This target code serves as the primary key or unique index of the structured test information in the database and is the core basis for all subsequent retrieval, retrieval, version comparison, and association management operations.

[0135] S702. When the program header information or the test specifications of each object under test change, the corresponding structured test information to be modified is retrieved from the database according to the target code, and the structured test information to be modified is modified.

[0136] Optionally, when testing requirements change, such as when program header information (e.g., version number, author) needs to be updated, or when test specifications from the chip designer are revised (e.g., new test items are added, pin definitions are adjusted, or electrical parameters are changed), the graphical test program generation tool provides an efficient modification path instead of requiring users to start from scratch.

[0137] Optionally, the graphical test program generation tool uses this target code as a query condition to quickly retrieve the corresponding structured test information to be modified from the database. This modified structured test information is then reloaded into the user interface provided by the graphical test program generation tool in a user-friendly and editable format, and presented to the user. The user only needs to modify the parts that have changed. For example, updating the program version number, adding a pin to the pin definition table, modifying the limit parameter of a test item, or adjusting the execution order of test items.

[0138] The following describes the apparatus, computer equipment, and computer-readable storage medium used to execute the test program generation method provided in this application. The specific implementation process and technical effects are described above and will not be repeated here.

[0139] Figure 8 This is a schematic diagram of a test program generation device provided in this application. See also... Figure 8 The test program generation apparatus 80 provided in this application embodiment includes: The device determination module 801 is used to obtain the type of test device and the number of objects to be tested in parallel based on the program header information input by the user, and to determine the target test device based on the type of test device and the number of objects to be tested in parallel. The test information input module 802 is used to generate structured test information corresponding to each test object according to the test specification of each test object. The structured test information includes: test program information, test item information, test clock information and test logic information. The test program information includes: pin definition information and pin definition information. The resource allocation module 803 is used to allocate hardware resources in the target test equipment to each test object based on the structured test information of each test object. The hardware resources include: power hardware resources and pin hardware resources. The program generation module 804 is used to generate test programs that conform to the platform specifications of the target test equipment for each test object based on the program header information, the structured test information corresponding to each test object, and the hardware resources allocated to each test object. The test programs include: project files and program source files.

[0140] Optionally, the resource allocation module 803 can be used to allocate power hardware resources and pin hardware resources of the target test device to each of the concurrently tested objects based on the number of objects under test, the pin definition information of each object under test, and the idle hardware resources of the target test device at the current moment.

[0141] Optionally, the aforementioned idle hardware resources include: an upper limit on the number of idle power supplies and an upper limit on the number of idle pins. The resource allocation module 803 is specifically used to: determine the total number of power supplies required for all objects under test (DUTs) based on the number of DUTs and the pin definition information of each DUT; determine the target number of power supplies provided by the target test device for all DUTs based on the total number of power supplies and the upper limit on the number of idle power supplies; determine the number of target power boards in the target test device based on the target number of power supplies, and allocate at least one power channel to each DUT based on the number of target power boards; determine the number of pins for each DUT and the total number of pins for all DUTs based on the pin definition information of each DUT; determine the target number of pins provided by the target test device for all DUTs based on the total number of pins and the upper limit on the number of idle pins; allocate logic pins to each DUT based on the number of pins corresponding to each chip under test and the target number of pins, and determine the mapping relationship between the logic pins of each DUT and the physical logic board.

[0142] Optionally, the above-mentioned program generation module 804 is specifically used to: generate a project file corresponding to each test object based on the program header information, the pin definition information of each test object, the pin definition information of each test object, and the pin hardware resources allocated to each test object; and generate a program source file corresponding to each test object based on the test item information of each test object, the test logic information of each test object, and the preset test item template.

[0143] Optionally, the above-mentioned program generation module 804 can be specifically used to: generate first configuration information based on the program header information; generate second configuration information based on the pin definition information of each test object and the pin hardware resources allocated to each test object; generate third configuration information based on the pin definition information of each test object; and generate project files corresponding to each test object based on the first configuration information, the second configuration information and the third configuration information.

[0144] Optionally, the aforementioned test item information includes multiple test items. The program generation module 804 can further be used to: call the standard test template corresponding to each test item from the preset test item template based on the test item information of each test item for each object under test; and call the test instruction set corresponding to each test item through each standard test template; based on the test instruction set corresponding to each test item, fill the test parameters contained in each test item into the corresponding standard test template to generate an executable test instruction set corresponding to each test item. The standard test template includes at least one parameter placeholder, which is used to indicate the variable position of the test parameter to be filled; and according to the test logic information of each object under test, sequentially write the executable test instruction set corresponding to each test item into the control flow code segment to obtain the program source file of each object under test.

[0145] Optionally, the above-mentioned program generation module 804 can also be used to: determine the execution order of each test item in the test item information of each test object according to the test logic information of each test object; and write the executable test instructions corresponding to each test item into the control flow code segment in the order of execution to obtain the program source file of each test object.

[0146] Optionally, the test program generation device 80 further includes an update module 805, which is specifically used to: store the structured test information of each test object in a pre-built database, and generate corresponding target codes for the structured test information of each test object; when the program header information or the test specification of each test object changes, retrieve the corresponding structured test information to be modified from the database according to the target code, and modify the structured test information to be modified.

[0147] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

[0148] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0149] Figure 9 This is a schematic diagram of the structure of a computer device provided in this application. See also: Figure 9 The computer device provided in this application includes a memory 901 and a processor 902. The memory 901 stores a computer program that can run on the processor 902. When the processor 902 executes the computer program, it implements the steps in any of the above method embodiments.

[0150] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0151] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, is used to perform any of the above-described test program generation method embodiments.

[0152] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0153] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0155] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute partial steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0156] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0157] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for generating a test program, characterized in that, The method includes: Based on the program header information input by the user, obtain the type of test equipment and the number of objects to be tested concurrently, and determine the target test equipment based on the type of test equipment and the number of objects to be tested concurrently; Based on the test specifications of each test object, generate structured test information corresponding to each test object. The structured test information includes: test program information, test item information, test clock information, and test logic information. The test program information includes: pin definition information and binary pin definition information. Based on the structured test information of each test object, hardware resources in the target test equipment are allocated to each test object. The hardware resources include: power hardware resources and pin hardware resources. Based on the program header information, the structured test information corresponding to each test object, and the hardware resources allocated to each test object, a test program conforming to the platform specifications of the target test device is generated for each test object. The test program includes: project files and program source files.

2. The test program generation method according to claim 1, characterized in that, The step of allocating hardware resources in the target testing device to each test object based on the structured test information of each test object includes: Based on the number of objects under test, the pin definition information of each object under test, and the idle hardware resources of the target test device at the current moment, power hardware resources and pin hardware resources in the target test device are allocated to each object under test in the concurrent test.

3. The test program generation method according to claim 2, characterized in that, The idle hardware resources include: an upper limit on the number of idle power supplies and an upper limit on the number of idle pins. The process of allocating power supply hardware resources and pin hardware resources from the target test device to each object under test based on the number of objects under test, the pin definition information of each object under test, and the idle hardware resources of the target test device at the current moment includes: Based on the number of objects under test and the pin definition information of each object under test, determine the total power supply required for all objects under test to be tested in parallel. Based on the total number of power supplies and the upper limit of the number of idle power supplies, the target number of power supplies that the target test equipment provides for all the objects under test in parallel is determined; Based on the number of target power supplies, determine the number of target power supply boards in the target test equipment, and based on the number of target power supply boards, allocate at least one power channel to each test object under test that is being tested concurrently. Based on the pin definition information of each test object, determine the number of pins of each test object and the total number of pins of all test objects tested in parallel; Based on the total number of pins and the upper limit of the number of free pins, the target number of pins provided by the target test device for all objects under test being tested concurrently is determined; Based on the number of pins corresponding to each chip under test and the target number of pins, logic pins are assigned to each object under test to be tested in parallel, and the mapping relationship between the logic pins of each object under test and the physical logic board is determined.

4. The test program generation method according to claim 1, characterized in that, The step of generating a test program for each test object that conforms to the platform specifications of the target test device, based on the program header information, the structured test information corresponding to each test object, and the hardware resources allocated to each test object, includes: Based on the program header information, the pin definition information of each test object, the pin definition information of each test object, and the pin hardware resources allocated to each test object, generate the project file corresponding to each test object. Based on the test item information, test logic information, and preset test item templates for each test object, the corresponding program source file for each test object is generated.

5. The test program generation method according to claim 4, characterized in that, The process of generating a project file corresponding to each test object based on the program header information, the pin definition information of each test object, the binary pin definition information of each test object, and the pin hardware resources allocated to each test object includes: Generate first configuration information based on the program header information; Based on the pin definition information of each test object and the pin hardware resources allocated to each test object, generate the second configuration information; Generate third configuration information based on the Bin pin definition information of each object under test; Based on the first configuration information, the second configuration information, and the third configuration information, project files corresponding to each object to be tested are generated.

6. The test program generation method according to claim 4, characterized in that, The test item information includes: multiple test items; the step of generating the program source file corresponding to each test object based on the test item information of each test object, the test logic information of each test object, and the preset test item template includes: Based on the test items in the test item information of each test object, the standard test template corresponding to each test item is called from the preset test item template, and the test instruction set corresponding to each test item is called through each standard test template respectively; Based on the test instruction set corresponding to each test item, the test parameters contained in each test item are filled into the corresponding standard test template to generate an executable test instruction set corresponding to each test item. The standard test template includes: at least one parameter placeholder, which is used to indicate the variable position of the test parameter to be filled. Based on the test logic information of each test object, the executable test instruction set corresponding to each test item is sequentially written into the control flow code segment to obtain the program source file of each test object.

7. The test program generation method according to claim 6, characterized in that, The step involves sequentially writing the executable test instruction set corresponding to each test item into the control flow code segment based on the test logic information of each test object, to obtain the program source file of each test object, including: Based on the test logic information of each object under test, determine the execution order of each test item in the test item information of each object under test; According to the execution order, the executable test instructions corresponding to each test item are written into the control flow code segment in sequence to obtain the program source file of each test object.

8. The test program generation method according to claim 1, characterized in that, Before allocating hardware resources from the target testing device to each test object based on its structured test information, the process further includes: The structured test information of each object under test is stored in a pre-built database, and corresponding target codes are generated for the structured test information of each object under test. When the program header information or the test specifications of each object under test changes, the corresponding structured test information to be modified is retrieved from the database according to the target code, and the structured test information to be modified is modified.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program executable on the processor, and when the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

Images