Multi-user testing methods, systems, and electronic devices

Abstract

The application provides a multi-user test method, system and electronic device, comprising: in response to receiving a session creation request, generating a test session corresponding to the session creation request and storing; in response to receiving at least one test instruction, obtaining a target test session corresponding to each test instruction in the at least one test instruction in at least one configured test session respectively, and respectively delivering test engineering information of each target test session to a corresponding test head, so that the test head corresponding to each target test session tests a device under test based on the corresponding test engineering in parallel. Thus, the same chip test equipment can support differentiated test tasks of different devices under test, greatly improving the utilization rate, test concurrency rate and execution efficiency of the chip test equipment, and significantly enhancing the business competitiveness.

Description

Technical Field

[0001] This application relates to chip testing technology, and in particular to a multi-user testing method, system, and electronic device. Background Technology

[0002] Automatic Test Equipment (ATE) is a system that uses automation technology to perform parameter measurement and functional verification on Device Under Test (DUT). It is widely used in critical stages such as wafer testing, finished product testing, and post-packaging testing of integrated circuits. To improve test throughput and equipment utilization, current mainstream ATE systems generally adopt a multi-test-head architecture, which integrates multiple independent or semi-independent test units in a single host to achieve parallel testing capabilities.

[0003] In existing technologies, the common operating mode of multi-test ATE systems is that a single user monopolizes all test resources. That is, the multi-test ATE system can only execute a single user task or a single test program at the same time. However, this mode causes the automated test equipment to be unable to achieve effective resource sharing across users or tasks when running a single task. Different R&D or production teams need to use it in a sequential queue, which reduces the overall utilization rate of the automated test equipment and thus delays the chip R&D and mass production process. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a multi-user testing method, system, and electronic device.

[0005] One aspect of this application provides a multi-user testing method applied to a chip testing device, the chip testing device including multiple test heads, the method comprising: in response to receiving a session creation request, generating and storing a test session corresponding to the session creation request, the test session including a session identifier, a test user identifier, test head information of at least one test head, and test project information of a test project; in response to receiving at least one test instruction, obtaining a target test session corresponding to each test instruction in the at least one configured test session; and distributing the test project information of each target test session to the corresponding test head, so that the test heads corresponding to each target test session can perform parallel testing on the device under test based on the corresponding test project.

[0006] Another aspect of this application provides a multi-user testing system applied to a chip testing device. The chip testing device includes a host computer and multiple test heads. The multi-user testing system is deployed in the host computer and includes: a command-line module for generating a session creation request for a test user and sending the session creation request to the multi-user management module; a multi-user management module for storing at least one configured test session, and generating and storing a test session corresponding to the session creation request upon receiving the session creation request. The test session includes a session identifier, a test user identifier, test head information of at least one test head, and test project information of a test project; and a test execution module for obtaining, upon receiving at least one test instruction, the target test session corresponding to each test instruction from the multi-user management module, and distributing the test projects of each target test session to the corresponding test head, so that the test heads corresponding to each target test session can perform parallel testing on the device under test based on the corresponding test projects.

[0007] In another aspect of this application, an electronic device is provided, comprising: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the method described above.

[0008] The multi-user testing method, system, and electronic device in this application create isolated test sessions for different test users (i.e., each test session independently binds test header information and test project information), enabling a single chip testing device to respond to multiple test commands in parallel and distribute different test projects to the corresponding test headers. This virtualizes a physical chip testing device into multiple logically independent chip testing devices, enabling the simultaneous support of differentiated test tasks for different devices under test on the same chip testing device. This significantly improves the utilization rate, test concurrency rate, and execution efficiency of chip testing devices, thereby significantly enhancing commercial competitiveness.

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

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

[0011] This application can be more clearly understood with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a flowchart illustrating a multi-user testing method provided in an exemplary embodiment of this application; Figure 2 This is a schematic diagram of the multi-user testing method provided in an application example of this application; Figure 3 This is a flowchart illustrating a multi-user testing method provided in another exemplary embodiment of this application; Figure 4 A schematic diagram illustrating modifications to a test project as provided in an exemplary embodiment of this application; Figure 5 This is a flowchart illustrating step S110 provided in an exemplary embodiment of this application; Figure 6 This is a flowchart illustrating a multi-user testing method provided in yet another exemplary embodiment of this application; Figure 7 This is a schematic diagram of the multi-user testing method provided in an application example of this application; Figure 8 This is a flowchart illustrating the multi-user testing method provided in an application example of this application; Figure 9 This is a schematic diagram of a multi-user testing method provided in another application example of this application; Figure 10 This is a schematic diagram of the test project loading provided in an application example of this application; Figure 11 This application provides an application example illustrating the creation of test session / test header resources; Figure 12 This application provides an example of deleting a test session; Figure 13 This application provides a schematic diagram of the lifecycle states of a test session in an application example. Figure 14 This is a structural block diagram of a multi-user testing system provided in an exemplary embodiment of this application; Figure 15 This is a schematic diagram of the structure of an application embodiment of the electronic device of this application. Detailed Implementation

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

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

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

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

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

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

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

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

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

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

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

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

[0024] In the process of developing this application, research revealed that the common operating mode of multi-test ATE systems is that a single user monopolizes all test resources. That is, the multi-test ATE system can only execute a single user task or a single test program at the same time. This mode leads to the following problems: First, the ATE cannot achieve dynamic resource sharing among multiple users or multiple tasks, and the equipment utilization is limited by the continuous occupation of a single task. Second, different R&D teams or production tasks need to queue up sequentially to wait for resource release, which not only increases the idle time of the equipment, but also prolongs the overall cycle of chip development verification to mass production.

[0025] Figure 1 This is a schematic flowchart of a multi-user testing method provided in an exemplary embodiment of this application. This embodiment can be applied to chip testing equipment, such as... Figure 1 As shown, this multi-user testing method includes the following steps: Step S100: In response to receiving a session creation request, generate and store the test session corresponding to the session creation request.

[0026] Chip testing equipment is used to test the functionality and / or performance of semiconductor devices (including but not limited to chips, wafers, and packaged devices). For example, chip testing equipment can be an Automatic Test Equipment (ATE). Chip testing equipment may include a host computer and multiple test subracks. The host computer communicates with each test subrack (i.e., the slave computer), for example, via gRPC (Remote Procedure Call). The host computer may be, for example, a computer, server, smartphone, or tablet computer. The test subracks can be used to test the functionality and / or performance of the device under test (DUT). The DUT may include, for example, at least one of the following: chips, integrated circuits, and wafers. In one example, a multi-user testing method can be applied to the host computer of the chip testing equipment.

[0027] A test session includes: a session ID, a user ID, test header information for at least one subrack, and test project information. The session ID uniquely identifies a test session. The user ID identifies the test user. The test header information includes the subrack ID and the test header's Internet Protocol (IP) address. The test project information may include the test project's file directory and / or file paths. In one example, a test session may include test header information for one or more test headers. The test project includes the code and configuration information used for testing, allowing configuration of tests for different functionalities.

[0028] In one implementation, test sessions are used to isolate the testing activities of different test users. Each test session can only access the test headers and test projects it holds, and is not visible to the resources of other test sessions. To ensure the accuracy of test results, the same test project can only be occupied by one test session at a time.

[0029] For example, before testing the device under test (DUT), a test session can be configured on the host computer. Specifically, the host computer receives a session creation request sent by the test user and performs the following configuration operations: generating a session identifier, determining the test header and test project corresponding to the session creation request, obtaining the test header identifier of the test header as test header information, and obtaining the test project information of the test project. The test session corresponding to the session creation request is constructed using the test user's test user identifier, the session identifier, the test header information, and the test project information. The session identifier can be bound to the test user identifier, the test header information, and the test project information respectively, and the configured test session is stored on the host computer.

[0030] Step S110: In response to receiving at least one test instruction, obtain the target test session corresponding to each test instruction in at least one configured test session.

[0031] The host computer stores multiple configured test sessions. In this embodiment, the test session corresponding to the test command can be determined as the target test session for that test command.

[0032] In one example, multiple test users can send test commands to the host computer simultaneously. The host computer processes these multiple test commands in parallel. For each test command, the host computer performs the following: among the multiple test sessions stored in the host computer, it determines the target test session corresponding to the test command, and then obtains the test header information (such as test header identifier) ​​and test project information (such as the file directory and file path of the test project) included in the target test session.

[0033] Step S120: The test project information of each target test session is sent to the corresponding test head so that the test head corresponding to each target test session can perform tests on the device under test in parallel based on the corresponding test project.

[0034] For example, for each target test session, the host computer obtains the test project corresponding to the target test session based on the test project information included in the target test session, and loads the test project corresponding to the target test session into the corresponding test header based on the test header information in the target test session. The test headers corresponding to each target test session execute their respective test projects, completing the test of the device under test in parallel. When the target test session includes multiple test header information, it indicates that the target test session corresponds to multiple test headers. In this case, the host computer loads the test project corresponding to the target test session into its respective test header.

[0035] In this embodiment, by creating isolated test sessions for different test users (i.e., each test session independently binds test header information and test project information), a single chip testing device can respond to multiple test commands in parallel and send different test projects to the corresponding test headers. This virtualizes a physical chip testing device into multiple logically independent chip testing devices, enabling the simultaneous support of differentiated test tasks for different devices under test on the same chip testing device. This significantly improves the utilization rate, test concurrency rate, and execution efficiency of the chip testing device, thereby significantly enhancing commercial competitiveness.

[0036] In some optional implementations, the session creation request in this application embodiment includes: test user identifier, test header information, and test project information.

[0037] In one example, a test user can remotely log in to the host computer via their terminal and generate a session creation request on the host computer that includes the test user identifier, test header information, and test project information; alternatively, the test user can also directly generate a session creation request locally on the host computer.

[0038] In this embodiment of the application, the host computer can generate a test session corresponding to the session creation request in the following ways: Based on the test header information and the test project information, the status of the test project and the test header corresponding to the session creation request are determined; in response to the fact that the status of the test project and the test header are both unoccupied, a session identifier is generated, and the session identifier is bound to the test user identifier, the test header information and the test project information respectively to obtain the test session corresponding to the session creation request.

[0039] In one example, both test projects and test headers have two states: occupied and unoccupied. An occupied test project indicates it is bound to a test session, while an unoccupied state indicates it is idle. Similarly, a occupied test header indicates it is bound to a test session, while an unoccupied state indicates it is idle. When either the test project or the test header is occupied, the current test session creation process is terminated, and the test user is notified of the occupied resources (including the occupied test header and / or test project).

[0040] When the test session is created, the status of the test header and the test project are both updated to occupied. The session identifier of the test session is also sent to the test header corresponding to the test session so that the session identifier can be applied to global variables. In subsequent tests, the test header can use the session identifier to query the corresponding test parameters.

[0041] In this embodiment, a resource status check mechanism is introduced, that is, a test session is created only when both the status of the test project and the status of the test head are unoccupied. This fundamentally avoids conflicts and data corruption caused by multiple users concurrently requesting the same resource, and ensures the exclusive binding of each test session to the test project and the test head. Thus, while virtualizing multiple test devices, the atomicity and consistency of resource allocation are guaranteed, and the reliability and security of multi-user parallel testing are significantly improved.

[0042] In some optional implementations, the multi-user testing method in this application embodiment may further include: updating the test user identifier to the file attributes of the test project, so that the test user has editing permissions for the test project.

[0043] File attributes include access permissions, as well as the owner and group. File attributes are a core set of metadata used by the operating system to manage files or directories. They include read / write / execute permissions, as well as information such as the owner and group, fully covering the implications of access permissions plus the owner and group. The test user identifier is written into the file attributes of the test project within the test session corresponding to that test user, granting the test user read, write, and execute permissions for that test project.

[0044] For example, Figure 2 This is a schematic diagram of the multi-user testing method provided in an application example of this application. For example... Figure 2 As shown, file attributes can include: folder permissions (i.e., access permissions), owner user, and owner group. The session identifier is bound to the test project information. Upon successful binding, the test project is confirmed to be successfully bound. The folder permissions, owner user, and owner group of the test project are then modified. Specifically, the owner user is updated to the test user's identifier, the owner group is changed to the test user's private group, and the folder permissions are changed to 755. 755 is the software system's folder permission code, representing: 7 indicates the folder owner (creator / administrator) has full read, write, and execute permissions; the first 5 indicates users in the same group only have read and execute permissions and cannot modify / delete; the second 5 indicates all other users only have read and execute permissions and cannot modify / delete. In other words, the test user can read, write, and execute the test project, while other test users cannot write to prevent other users from modifying the project. If binding fails, the process is terminated and an error is reported.

[0045] In this embodiment, by writing the test user identifier into the file attributes of the test project, only the test user can obtain editing permissions for the test project. This achieves exclusive binding and access isolation between the test session and test project resources at the operating system level, ensuring data security and non-interference in multi-user parallel testing.

[0046] Figure 3 This is a flowchart illustrating a multi-user testing method provided in another exemplary embodiment of this application. In some alternative implementations, such as... Figure 3 As shown, the following steps may be included after step S100: Step S200: In response to receiving an operation request for any test project, and the test user corresponding to the operation request has editing permission for any test project, file locking is performed on any test project based on the read-write lock mechanism.

[0047] The operation request includes: the index of the test project (e.g., file directory and / or file path) and the test user identifier. The host computer retrieves the index of the test project and determines whether the file attributes of the test project include the test user identifier from the operation request. If it does, the host computer determines that the test user corresponding to the operation request has edit permissions for the test project; otherwise, it determines that the test user does not have edit permissions. If it is determined that the test user does not have edit permissions for the test project, the current operation is terminated, and the target operation corresponding to the operation request is no longer executed.

[0048] A read-write lock is a concurrency control mechanism used to manage access to shared resources in a multi-threaded or multi-process environment. Read-write locks allow multiple test users to access the test project simultaneously, but guarantee exclusive access during writes, thereby maximizing concurrency performance while ensuring test data consistency.

[0049] It should be noted that in the embodiment, steps S200 and S110 are not executed in any particular order.

[0050] Step S210: In response to the successful locking of any test project, execute the target operation corresponding to the operation request on any test project.

[0051] The target operations include at least one of the following: opening, reading, editing, and executing the test project.

[0052] In one example Figure 4 This is a schematic diagram illustrating modifications to a test project as provided in an exemplary embodiment of this application. For example... Figure 4 As shown, taking Test Project I as an example, Test Project I is bound to Test Session I: After receiving an operation request for Test Project I, the host computer first verifies whether the test user corresponding to the operation request has editing permissions for Test Project I; if so, it locks the executable file of Test Project I. If the locking is successful, the developtool (host computer software) is allowed to open and read / write Test Project I, and can continue to execute subsequent debugging (testing) processes for the device under test; if the locking fails, the developtool is prohibited from opening or reading / writing Test Project I, and the current operation process is terminated.

[0053] In this embodiment, by introducing a dual protection mechanism of permission verification and file locking, it is further ensured that only one operator can open and modify the test project at the same time, based on the fact that the test user already has the project editing permission. This completely avoids data corruption or logical errors caused by multiple users or multiple operators editing the same project concurrently.

[0054] Figure 5 This is a flowchart illustrating step S110 provided in an exemplary embodiment of this application. In some alternative embodiments, such as Figure 5 As shown, step S110 may include the following steps: Step S111: Obtain the test session list.

[0055] The host computer stores a test session list, which includes at least one configured test session. Each time a test session is successfully created, the host computer updates the test session list with the newly created test session.

[0056] Step S112: Based on the session identifier in each test instruction, use the test session list to obtain the corresponding test session as the target test session.

[0057] In one implementation, for each test instruction, the corresponding test session can be queried from the test session list based on the session identifier included in the test instruction, and used as the target test session for that test instruction.

[0058] In this embodiment of the application, by introducing a test session list, the host computer can quickly and accurately locate the corresponding target test session from the test session list according to the session identifier in the test command, thus avoiding resource confusion and misoperation.

[0059] In one embodiment, the multi-user testing method in this application further includes: in response to receiving a session deletion request for any test session, obtaining the status of the test header corresponding to the test session, and deleting the test session from the test session list when the status of the test header is initialized.

[0060] The test header's state also includes initialization. The test header's state is determined to be initialized when the test project within it has been unloaded. In one implementation, if any test header's state is not initialized, then deleting that test session is refused.

[0061] For example, the operation process for deleting session I (any test session) is as follows: First, check whether the subrack occupied by the session I to be released is in the initialization state; where, the initialization state means that the subrack has completed the unloading of the test project, that is, after the test user performs the unload operation through the developtool tool, the subrack is restored to the initialization state.

[0062] By sending a status query command to the subrack occupied by session I, the status of the subrack is obtained. If the subrack is in an initialized state, deletion of session I is permitted and the deletion operation is performed; otherwise, deletion is refused. After successful deletion, the updated session list is synchronized to the file system to ensure that session I resource information can be restored and used normally after the system or host restarts.

[0063] In this embodiment, the corresponding test session can only be deleted when the test head is in the initialized state, ensuring that the test head is in a safe and idle state without task occupation before the resources are released. This avoids resource residue or abnormal occupation caused by forcibly deleting the test session, and ensures the complete recovery of test head resources and the correct allocation of subsequent test sessions.

[0064] Figure 6 This is a flowchart illustrating a multi-user testing method provided in another exemplary embodiment of this application. In some alternative implementations, such as... Figure 6 As shown, the following steps may be included before step S100: Step S300: Obtain the test header list and test project information.

[0065] The host computer stores a list of test heads, which includes test head information and status for at least one available test head. In one example, the test user retrieves the test head list and test project information, which is then displayed on a visual interactive interface.

[0066] Step S310: Determine available test head information based on the status of at least one available test head.

[0067] Specifically, from at least one available test header, available test headers with an unoccupied status are selected, and at least one of them is selected as a test header for creating a session request, and the test header information of the selected test header is obtained as available test header information.

[0068] Step S320: Create a session creation request based on the test user identifier, available test header information, and test project information.

[0069] The session creation request is constructed from the test user identifier, available test header information, and test project information.

[0070] In this embodiment of the application, available test headers with an unoccupied status are identified and selected from the test header list before the test session is created, ensuring that the test header resources allocated when the test session is created are actually available, and avoiding creation failure due to resource conflicts.

[0071] In some optional implementations, the multi-user testing method in this application embodiment may further include: in response to receiving a test head deletion request, determining the status of the test head to be released corresponding to the test head identifier in the test head deletion request; in response to the test head to be released being in an unoccupied state, deleting the test head information of the test head to be released from the test head list.

[0072] The test header deletion request includes the test header identifier of the test header to be released.

[0073] For example, when a subrack becomes unavailable, its resources can be released via a command-line tool. Specifically, on the host computer, the test user generates a test header deletion request, including the subrack ID, based on the subrack ID of the test header to be released. The command-line tool on the host computer forwards this subrack ID to the multi-user management program, which then performs the deletion operation. The deletion process includes: determining the subrack to be released based on the subrack ID and checking whether the subrack to be released is occupied by a session (i.e., whether its status is occupied); if the subrack to be released is occupied, the deletion of the test header information of the subrack to be released from the test header list is prohibited; if the subrack to be released is unoccupied, the deletion of the test header information of the subrack to be released from the test header list is allowed. After successful deletion, the updated test header list information is synchronized to the file system to ensure that the subrack resource information can be restored and used normally after the software or host restarts.

[0074] In this embodiment of the application, by verifying the status of the test header before deleting it, it is ensured that only test headers in an unoccupied state can be removed from the test header list, thereby preventing test interruption or data abnormality caused by accidental deletion of resources occupied by the test session.

[0075] In some optional implementations, the multi-user testing method in this application embodiment may further include: in response to receiving a test project update instruction for any test session, and the status of the new test project corresponding to the test project update instruction is unoccupied, binding the new test project to any test session; in response to the successful binding of the new test project to any test session, sending the new test project to the test header corresponding to any test session, so that the test header performs testing on the device under test based on the new test project.

[0076] The host computer of the chip testing equipment may include a test project memory, which stores multiple test projects. The test project memory may be, for example, read-only memory (ROM) or random access memory (RAM). Test project update instructions include: the index of the new test project (e.g., file directory and / or file path) and the session identifier of any test session.

[0077] For example, the host computer receives a test project update instruction for session I (any test session). The host computer identifies session I based on the session identifier in the update instruction and locates the new test project from the test project memory based on the index of the new test project in the update instruction. Then, it checks whether the new test project has been bound to another test session: if it has not been bound (i.e., its status is unoccupied), the new test project is bound to session I, and the previously bound test project in session I is released; if it has been bound (i.e., its status is occupied), the operation is terminated. After the new test project is successfully bound to session I, the host computer loads the new test project into the test header corresponding to session I.

[0078] In this embodiment of the application, by supporting dynamic updates and binding between test projects and test sessions, test users are allowed to replace the original test project with a new test project during the operation of the test session, and the new test project is automatically sent to the corresponding test head for execution, thereby realizing flexible switching of test tasks and efficient utilization of resources.

[0079] In some optional implementations, step S110 in this application embodiment may further include the following steps: For each test instruction, in response to the test instruction indicating mass production testing, and the test instruction including a session identifier, the target test session corresponding to the test instruction is determined based on the session identifier.

[0080] The host computer includes a cache module, which can be, for example, Random Access Memory (RAM). On the host computer side, when the test instruction includes a session identifier and indicates mass production testing, the following process is executed based on the session identifier: First, it checks if a test session corresponding to the session identifier exists in the cache module; if it does, the test session is directly designated as the target test session; if it does not exist, the corresponding test session is located in the test session list based on the session identifier and designated as the target test session. The test project corresponding to the target test session can be loaded into the test header corresponding to the target test session, and the test header executes the test project to perform batch testing on the device under test.

[0081] In response to the test instruction indicating mass production testing, since the test instruction does not include a session identifier and the cache module stores the test session corresponding to the test user identifier included in the test instruction, the test session is identified as the target test session.

[0082] On the host computer side, if the test instruction indicates mass production testing and does not carry a session identifier, the cache module is queried based on the test user identifier in the test instruction; when a test session corresponding to the test user identifier exists in the cache module, the test session is identified as the target test session.

[0083] In response to the test instruction indicating mass production testing, since the test instruction does not include a session identifier and the cache module does not store the test session corresponding to the test user identifier in the test instruction, the target test session is determined based on the test user identifier and the test session list.

[0084] On the host computer side, if the test instruction indicates mass production testing, does not carry a session identifier, and the cache module does not store the test session corresponding to the test user identifier, then the corresponding test session is located in the test session list based on the test user identifier and identified as the target test session.

[0085] In response to the test instruction to perform debugging tests, the target test session is determined using the test session list based on the test user identifier or session identifier in the test instruction.

[0086] On the host computer side, when the test instruction indicates debugging testing, if the test instruction includes a session identifier, the corresponding test session is located in the test session list based on the session identifier and designated as the target test session. If no session identifier is included, the corresponding test session is located in the test session list based on the test user identifier in the test instruction and designated as the target test session. The test project of the target test session can be loaded into the test header corresponding to the target test session, and the test header executes the test project to debug the device under test. In one embodiment, multiple test instructions may simultaneously include test instructions indicating debugging testing and test instructions indicating mass production testing.

[0087] In this embodiment, differentiated test session matching strategies are constructed for mass production testing and debugging testing respectively. In the mass production scenario, the default test session is automatically selected using a caching module and user identifier. In the debugging scenario, precise matching based on session identifier or test user identifier is flexibly supported. This allows the same host computer to process mass production and debugging test commands sent by different test users in parallel or concurrently, and efficiently route them to the corresponding test session without manual intervention.

[0088] In some optional implementations, the multi-user testing method in this application further includes: in response to receiving a session operation instruction sent by the current test user for any test session, obtaining the status of the any test session; in response to the status of the any test session being occupied, determining that the current test user performs a read-only operation on the any test session; and in response to the status of the any test session being unoccupied, determining that the current test user performs the operation corresponding to the session operation instruction on the any test session.

[0089] The session operation instruction corresponds to at least one of the following operations: modifying, deleting, and executing the test session. The session operation instruction includes a session identifier for any test session. For example, after receiving a session operation instruction, the host computer queries the status of the corresponding test session based on the session identifier in the instruction: if the test session is in an occupied state (i.e., currently being used by another test user), the current test user only has read-only permissions; if it is in an unoccupied state, the current test user can execute the operation corresponding to the instruction (such as modifying or deleting).

[0090] In this embodiment of the application, when multiple test users concurrently operate on the same test session, the occupied session is automatically switched to read-only mode, thereby effectively avoiding resource conflicts and data inconsistencies caused by concurrent writing, realizing intelligent isolation of read and write operations, and significantly improving the stability and data integrity of the system.

[0091] Figure 7 This is a schematic diagram of the multi-user testing method provided in an application example of this application. Figure 8 This is a flowchart illustrating the multi-user testing method provided in an application example of this application. For example... Figure 7-8 As shown, in this application example, the chip testing equipment includes a host computer and four test heads: test head 1 (subrack1), test head 2 (subrack2), test head 3 (subrack3), and test head 4 (subrack4). The host computer independently deploys command-line tools, developtool, mass production tools (not shown in the figure), a multi-user management program, and a file system.

[0092] The multi-user management program can be used for subrack management, session management, and persistent synchronization. Specifically, subrack management includes maintaining an internal list of subracks (test header list) visible to all test users. This list records user-defined subrack information (such as subrack ID, IP address, etc.) and supports adding, deleting, modifying, and querying subracks. When a subrack is not in an initialized state, it cannot be released by the session holding it (i.e., it cannot become available to other sessions). A subrack can only be modified when it is not held by any session to ensure the correctness of test results.

[0093] Session Management: The program maintains an internal list of sessions (test session list) visible to all test users. This list records sessions created by different test users (including session ID, test header information of the subracks they hold, and test project information of the test projects they occupy). It supports adding, deleting, modifying, and querying sessions. Test users can only query and use sessions they created to ensure that tests from different users do not interfere with each other. Persistent Synchronization: Any changes to the contents of the two lists will trigger a synchronization of the list information to the file system, ensuring that historical information can be restored and reused after a system or host restart.

[0094] Communication between the host computer and the slave computer (test head) uses gRPC (Remote Procedure Call). Both developtool and mass production tools are host computer operating software. Test users can obtain relevant resources for the test session through developtool or mass production tools and send them to the slave computer to perform functional tests (such as debugging). For example, they can perform DC (Direct Current) or AC (Alternating Current) debugging on the device under test, or perform mass production tests such as open / short circuit tests.

[0095] The steps for a multi-user (assuming 4 test users A, B, C, and D) test example are as follows: Step 1: Configure test header resources.

[0096] Any test user can log in to the host computer via a remote terminal (such as Secure Shell Protocol SSH or Virtual Network Computing VNC) and manually configure test header information, including the subrack ID and its corresponding IP address, using a command-line tool. The command-line tool sends the configured test header information to the multi-user management program, which adds the corresponding record to the test header list and synchronizes the updated test header list to the file system for persistent storage, ensuring that the test header resource information can be restored after the host computer restarts. The test header list is limited to a maximum of four entries (i.e., subrack1 to subrack4), and all test users have permissions to add, delete, modify, and query the test header list. Based on the user management mechanism of the software operating system, different test users can operate the same host computer simultaneously.

[0097] Step 2: Query the test header information.

[0098] After completing the test header resource configuration in step 1, the test user can send a query request to the multi-user management program via the command-line tool. After receiving the request, the multi-user management program returns the subrack ID and corresponding IP address recorded in the test header list, which is then displayed by the command-line tool.

[0099] Step 3, create a test session.

[0100] Four test users (A, B, C, and D) create test sessions using a command-line tool and a multi-user management program. The test users first specify parameters such as the session ID, the subrack IDs (1-4), and the file directory of the test project (session creation request) via the command-line tool, and then send this to the multi-user management program. The multi-user management program generates test sessions based on the specified information. The created test sessions include: Test user A's test session A (sessionA) includes: session_A (session identifier), subrackID1 (test header identifier of subrack1), the file destination of test project FuncA, and UserA ID (test user identifier of test user A); Test user B's test session B (sessionB) includes: session_B (session identifier), subrackID2 (test header identifier of subrack2), the file destination of test project FuncB, and UserB ID (test user identifier of test user B); Test user C's test session C (sessionC) includes: session_C (session identifier), subrackID3 (test header identifier of subrack3), the file destination of test project FuncC, and UserC ID. ID (test user identifier of test user C), test user D's test session D (sessionD) includes: session_D (session identifier), subrackID4 (test header identifier of subrack4), file target of test project FuncD, and UserD ID (test user identifier of test user D). After creating a test session, the multi-user management program adds the test session to the test session list (including session ID, occupied subrack ID, and the file target of the bound test project) and synchronizes it to the file system for persistence. Simultaneously, the multi-user management program uses multi-threading to distribute the session IDs of each test session in parallel to the corresponding test headers occupied by those test sessions. The test headers can then access the multi-user management program using this session ID. If multiple test users simultaneously request the same subrack or the same test project (determined by whether the file directories are identical), only the first request succeeds, and the others fail. During test session creation, if a test user does not specify a test header, the multi-user management program will identify and allocate an idle (unoccupied) test header to that test session based on the status of currently configured test headers.

[0101] Step 4: Execute the test process.

[0102] After a test session is successfully created, test users can use developtool or production tools to query the multi-user management program for the test resource information held by that test session, including test header information and test project information, based on the session ID. They can then execute a complete testing (such as debugging) process on the retrieved resources, such as using developtool to load the test project, execute the test, and unload the test project.

[0103] Step 5: Release test session resources.

[0104] After the test process is completed, the test user specifies the session ID to be released via the command-line tool and sends the session ID to the multi-user management program, which then performs the deletion and resource release operations for the test session. Before deletion, it is necessary to verify whether the test header occupied by the test session is in an initialized state (i.e., after the user executes the unload test project operation via developtool, the test header is restored to the initialized state). The multi-user management program obtains the status of the test header through the status query command. If it is in an initialized state, the deletion of the corresponding record in the test session list is allowed; if it is not in an initialized state, deletion is refused. After successful deletion, the updated test session list is synchronized to the file system for persistent storage. Different test users can modify and edit the test project bound to the session on the host computer using developtool or mass production tools without uploading the project from the local computer to the host computer.

[0105] Step 6: Release the test header resources.

[0106] When a test header becomes unusable, the user specifies the subrack ID of the test header to be released via a command-line tool and sends this subrack ID to the multi-user management program, which then performs the test header deletion operation. Before deletion, it is necessary to verify whether the test header is occupied by any test session: if it is occupied, deletion of the corresponding record in the test header list is prohibited; if it is not occupied, deletion is allowed. After successful deletion, the updated test header list is synchronized to the file system for persistent storage.

[0107] In an application testing scenario: For example, test user A performs DC function item testing on chip batch A (device under test) based on test project FuncA on subrack1 corresponding to session A; test user B performs AC function item testing on chip batch B based on test project FuncB on subrack2 corresponding to session B.

[0108] Figure 9 is a schematic diagram of a multi-user testing method provided in another application example of this application. For example... Figure 9 As shown, each test user's test session can hold two test header resources. Taking test users A and B as examples: test user A's test session A includes subrackID1, subrackID2, and the file directory of test project A (FuncA); test user B's test session B includes subrackID3, subrackID4, and the file directory of test project B (FuncB).

[0109] During the test execution phase, for each test session, its corresponding test project is simultaneously loaded onto the two test heads held by that test session. These two test heads then execute the test plan defined by the test project on different devices under test (DUTs). Specifically, test project A (FuncA) is loaded onto test head 1 (subrack1) and test head 2 (subrack2) to perform tests on DUT1 (DUT1) and DUT2 (DUT2), respectively; test project B (FuncB) is loaded onto test head 3 (subrack3) and test head 4 (subrack4) to perform tests on DUT3 and DUT4, respectively. The remaining steps are consistent with the four user scenarios described above.

[0110] Figure 10 This is a schematic diagram illustrating the loading of a test project provided in an application example of this application. For example... Figure 10 As shown, taking test user A as an example: Test Header 1 (subrack 1) includes a Hardware Test Interface (HTI) board and multiple function boards. On the host computer side, test user A loads test project A (FuncA) onto the HTI board of Test Header 1 (subrack 1) using developtool. Subsequently, the HTI board distributes test data to each function board, which then executes the test plan defined by test project A (FuncA) on the device under test (DUT). The function boards are responsible for implementing various functional tests of the DUT.

[0111] Figure 11 This application provides an application example illustrating the creation of test sessions / test header resources. Figure 12 This application provides an example of deleting a test session. Figure 13 This application provides a lifecycle state diagram of a test session provided in an application example.

[0112] like Figure 11As shown, to begin the operation, the test user can create a session creation request or a test header resource request via the command-line tool and send it to the multi-user management program. Upon receiving the session creation request or test header resource request, the multi-user management program begins the operation. Based on the session creation request, it creates a test session, writes the test session to the test session list, and persists the updated test session list to the file system. The multi-user management program can also create test header information based on the test header identifier and IP address carried in the test header resource request, writes the test header information to the test header list, and synchronizes the updated test header list to the file system. Afterward, both the command-line tool and the multi-user management program terminate their operations.

[0113] like Figure 12 As shown, the operation begins. The test user creates a session deletion request via the command-line tool. This request includes the session ID of the test session to be deleted and is sent to the multi-user management program by the command-line tool. In the multi-user management program, the operation begins, and the status of the test headers held by the corresponding test session is queried based on the session ID. If the test header status is in the initial state, deletion of the corresponding record in the test session list is allowed; otherwise, deletion is rejected. After the deletion operation is successful, the updated test session list is synchronized to the file system for persistent storage. The command-line tool and the multi-user management program then terminate their respective operations.

[0114] like Figure 13 As shown, the lifecycle states of a test session can include: initial state, modified state, test state, and termination state.

[0115] 1. Initial State Entry method: Create a test session. Complete the test session creation, including binding the test session with test project information and test header information, and enter the initial state.

[0116] Status meaning: The test session is in the ready state, the test project is in the unloaded state, and resource configuration or test preparation operations can be performed.

[0117] Transition operations can be triggered as follows: After loading the test project, the test project is loaded onto the bound test header, transitioning from the initial state to the test state; when binding / changing the test project or test header, the modified state is transitioned back to the initial state; when deleting the test session, all resources bound to the test session are released, transitioning from the initial state to the terminated state, ending the lifecycle of the test session.

[0118] 2. Modify status Entry method: Entered when the initial state triggers the binding / rebinding of test projects or test headers, and the test project must be in an unloaded state before entering.

[0119] Status meaning: The test session is in the resource configuration state. When the test project is in the unloaded state, the binding, unbinding or rebinding operation of the test project or test header is performed.

[0120] Can trigger conversion operation: After the completion of the binding / rebinding test project or test header operation, the state will be converted back to the initial state.

[0121] 3. Test Status Entry method: The initial state triggers the loading operation of the test project, which is then loaded into the bound test header before entry.

[0122] Status meaning: The test session is in the test execution state. The test project has been loaded into the hardware and the test task is being executed. Binding / changing test projects or test headers is prohibited.

[0123] Triggerable transition operation: Complete the test and perform the unload operation of the test project to unload the test project from the test header and transition it back to the initial state.

[0124] 4. Termination Status Entry method: Entered by responding to the test user's deletion of the session in the initial state.

[0125] Status meaning: The lifecycle of the test session has ended, and the bound test project and test header resources are released and can be reallocated to other test sessions.

[0126] For example, the following is a debugging and testing process in a practical application, including: 1. Select a test session: Open the developtool tool, select the target test session, and the interface will display the detailed information of the session (such as the bound test headers, test projects, etc.).

[0127] 2. Open the test project: Open the test project bound to the current session to prepare for debugging or testing.

[0128] 3. Initialize the test head (init): Click the "init" button in the developtool interface. The host computer sends an init request to the lower-level machine (test head). The lower-level machine performs initialization operations, including self-test and reset of each functional board.

[0129] 4. Loading the Test Project: After successful initialization, the load operation is executed. The host computer sends the test project to the slave computer and checks whether the test project configuration matches the actual board on the slave computer. Specifically, the host computer sends a load request to the slave computer, and the slave computer executes the load operation to complete the loading of the test project.

[0130] 5. Execute the test: After successful loading, the lower-level machine executes the corresponding test plan on the device under test (DUT) according to the loaded test project.

[0131] 6. Unload the test project: After the debugging is completed, execute the unload operation to restore the lower-level machine to the initial state (init state) and release the test resources.

[0132] For example, the following are examples of mass production testing applications in practical applications, specifically including: The chip testing equipment includes a mass production program that controls the equipment for batch testing. Both the test program and the developtool software support test flow control (such as test machine initialization, adding / unloading test projects, starting / ending batches, and executing test programs). The mass production software supports multiple users and provides control commands for user equipment automation programs (EAPs) to call. These commands must include a session as an input parameter (this parameter can be omitted; if omitted, a default session is used). The default session generation method is as follows: When a session is created, it is cached in the system environment variables (only the latest session is cached from multiple creations). The environment variables are checked first; if the cache is valid, it is used as the default session. If no valid cache exists in the environment variables, the multi-user management program queries all sessions of the current user, and the first one is taken as the default session. The internal control of the test machine executes the test process in the same way as the developtool software.

[0133] In a mass production environment, the mass production software determines the test session in the following ways: user-specified, default allocation, or, if the user does not specify, the session that first completes the test project loading will automatically connect. Terminal device release rules: The session specified by the test user must not be in a batch-open state, and the test user must actively release the terminal or delete the session; for sessions connected using the default method: the terminal device is automatically released when the test project is unloaded.

[0134] Figure 14This is a structural block diagram of a multi-user testing system provided in an exemplary embodiment of this application. The multi-user testing system 400 is applied to a chip testing device, which includes a host computer and multiple test heads. The multi-user testing system 400 is deployed in the host computer and includes: Command line module 410 is used to generate a session creation request for the test user and send the session creation request to the multi-user management module. The multi-user management module 420 is used to store at least one configured test session, and to generate and store the test session corresponding to the session creation request when the session creation request is received. The test session includes a session identifier, a test user identifier, test header information of at least one test header, and test project information of the test project. The test execution module 430 is used to, upon receiving at least one test instruction, obtain the target test sessions corresponding to each test instruction from the multi-user management module, and send the test projects of each target test session to the corresponding test heads, so that the test heads corresponding to each target test session can perform tests on the device under test in parallel based on the corresponding test projects.

[0135] In some optional implementations, in the embodiments of this application, the session creation request includes the test user identifier, the test header information, and the test project information; Generate a test session corresponding to the session creation request, which is further used for: Based on the test header information and the test project information, the status of the test project and the status of the test header corresponding to the session creation request are determined; in response to the fact that the status of the test project and the status of the test header are both unoccupied, the session identifier is generated, and the session identifier is bound to the test user identifier, the test header information and the test project information respectively to obtain the test session.

[0136] In some optional implementations, the multi-user management module 420 in this application embodiment is further configured to update the test user identifier to the file attributes of the test project, so that the test user has editing permissions for the test project.

[0137] In some optional implementations, the multi-user management module 420 in this application embodiment is further configured to, in response to receiving an operation request for any test project, and the test user corresponding to the operation request having editing permissions for any test project, perform file locking processing on any test project based on a read-write lock mechanism; The test execution module 430 is further configured to, in response to the successful locking of any test project, perform the target operation corresponding to the operation request on any test project, wherein the target operation includes at least one of opening, reading, editing and executing any test project.

[0138] In some optional implementations, the multi-user management module 420 in this application embodiment is further configured to store a test session list, the test session list including at least one test session; The step of obtaining the target test session corresponding to each test instruction in at least one configured test instruction within at least one configured test session is further used for: Based on the session identifier in each test instruction, the corresponding test session is obtained as the target test session using the test session list; The multi-user management module 420 is further configured to, in response to receiving a session deletion request for any test session, obtain the status of the test header corresponding to the test session, and delete the test session from the test session list when the status of the test header is initialized.

[0139] In some optional implementations, the multi-user management module 420 in this application embodiment is further used to store a test head list, the test head list including test head information and status of at least one test head; The command-line module 410 is further configured to obtain the test head list from the multi-user management module and display it through a visual interactive interface; determine the available test head information based on the status of the at least one available test head; and create the session creation request based on the test user identifier, the available test head information, and the test project information.

[0140] In some optional implementations, the multi-user management module 420 in this application embodiment is further configured to, in response to receiving a test head deletion request, determine the status of the test head to be released corresponding to the test head identifier in the test head deletion request; and, in response to the test head to be released being in an unoccupied state, delete the test head information of the test head to be released from the test head list.

[0141] In some optional implementations, the host computer in this application embodiment includes a test project memory, which stores multiple test projects; The multi-user management module 420 is further configured to, in response to receiving a test project update instruction for any test session, and the status of the new test project corresponding to the test project update instruction is unoccupied, bind the new test project to the any test session; The test execution module 430 is further configured to, in response to the successful binding of the new test project with any test session, send the new test project to the test header corresponding to any test session, so that the test header performs tests on the device under test based on the new test project.

[0142] In some optional implementations, the multi-user testing system in this application embodiment further includes a caching module, and the test execution module 430 includes: a mass production testing submodule and a debugging submodule; The caching module is used to cache at least one configured test session; The mass production testing submodule is configured to, in response to each test instruction, determine the target test session corresponding to the test instruction based on the session identifier, provided that the test instruction indicates mass production testing and the test instruction includes a session identifier; determine the test session as the target test session if the test instruction indicates mass production testing, the test instruction does not include a session identifier, and the cache module of the host computer stores a test session corresponding to a test user identifier included in the test instruction; and determine the target test session based on the test user identifier and using the test session list if the test instruction indicates mass production testing, the test instruction does not include a session identifier, and the cache module does not store a test session corresponding to a test user identifier in the test instruction. The debugging submodule is used to respond to the test instruction to perform debugging tests, and determine the target test session based on the test user identifier or session identifier in the test instruction and the test session list.

[0143] In some optional implementations, the multi-user management module 420 in this application embodiment is further configured to: in response to receiving a session operation instruction sent by the current test user for any test session, obtain the status of the any test session; in response to the status of the any test session being occupied, determine that the current test user performs a read-only operation on the any test session; and in response to the status of the any test session being unoccupied, determine that the current test user performs the operation corresponding to the session operation instruction on the any test session.

[0144] The multi-user testing system of this application corresponds to the multi-user testing method described above, and the relevant content can be referred to each other, which will not be repeated here.

[0145] The beneficial technical effects of the exemplary embodiments of the multi-user testing system in this application can be found in the corresponding beneficial technical effects of the exemplary methods and systems described above, and will not be repeated here.

[0146] In addition, embodiments of this application also provide an electronic device, including: Memory, used to store computer programs; A processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, it implements the multi-user testing method described in any of the above embodiments of this application.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A multi-user testing method, characterized in that, Applied to a chip testing equipment, the chip testing equipment including multiple test heads, the method includes: In response to receiving a session creation request, a test session corresponding to the session creation request is generated and stored. The test session includes a session identifier, a test user identifier, test header information of at least one test header, and test project information of the test project. In response to receiving at least one test instruction, the target test session corresponding to each test instruction in the at least one configured test session is obtained; The test project information for each target test session is sent to the corresponding test head, so that the test head corresponding to each target test session can perform tests on the device under test in parallel based on the corresponding test project.

2. The method according to claim 1, characterized in that, The session creation request includes the test user identifier, the test header information, and the test project information; Generate the test session corresponding to the session creation request, including: Based on the test header information and the test project information, determine the status of the test project and the status of the test header corresponding to the session creation request; In response to the fact that both the status of the test project and the status of the test header are unoccupied, a session identifier is generated, and the session identifier is bound to the test user identifier, the test header information and the test project information respectively to obtain the test session.

3. The method according to claim 1, characterized in that, Also includes: Update the test user identifier to the file attributes of the test project so that the test user has editing permissions for the test project.

4. The method according to any one of claims 1-3, characterized in that, Also includes: In response to receiving an operation request for any test project, and the test user corresponding to the operation request has editing permission for the test project, file locking is performed on the test project based on a read-write lock mechanism; In response to the successful locking of any of the test projects, the target operation corresponding to the operation request is executed on any of the test projects, the target operation including at least one of opening, reading, editing and executing the test project.

5. The method according to any one of claims 1-3, characterized in that, Obtaining the target test session corresponding to each test instruction in the at least one configured test session, including: Obtain a list of test sessions, which includes at least one configured test session; Based on the session identifier in each test instruction, the corresponding test session is obtained as the target test session using the test session list; The method further includes: In response to receiving a session deletion request for any test session, the status of the test header corresponding to the test session is obtained. If the status of the test header is initialized, the test session is deleted from the test session list.

6. The method according to any one of claims 1-3, characterized in that, Also includes: Obtain the test head list and the test project information, wherein the test head list includes test head information and status of at least one available test head; Based on the status of the at least one available test head, determine the available test head information; The session creation request is created based on the test user identifier, the available test header information, and the test project information.

7. The method according to claim 6, characterized in that, Also includes: In response to receiving a test header deletion request, the status of the test header to be released corresponding to the test header identifier in the test header deletion request is determined. In response to the test head to be released being in an unoccupied state, the test head information of the test head to be released is deleted from the test head list.

8. The method according to any one of claims 1-3, characterized in that, The host computer of the chip testing equipment includes a test project memory, which stores multiple test projects. The method further includes: In response to receiving a test project update instruction for any test session, and the status of the new test project corresponding to the test project update instruction is unoccupied, the new test project is bound to the any test session; In response to the successful binding of the new test project with any of the test sessions, the new test project is sent to the test header corresponding to any of the test sessions, so that the test header can perform tests on the device under test based on the new test project.

9. The method according to claim 1, characterized in that, Obtaining the target test session corresponding to each test instruction in the at least one configured test session, including: For each of the test instructions, in response to the test instruction indicating mass production testing, and the test instruction including a session identifier, the target test session corresponding to the test instruction is determined based on the session identifier; In response to the test instruction indicating mass production testing, where the test instruction does not include a session identifier and the host computer's cache module stores a test session corresponding to the test user identifier included in the test instruction, the test session is identified as the target test session. In response to the test instruction indicating mass production testing, where the test instruction does not include a session identifier and the cache module does not store a test session corresponding to the test user identifier in the test instruction, the target test session is determined based on the test user identifier and using the test session list. In response to the test instruction indicating a debugging test, the target test session is determined using the test session list based on the test user identifier or session identifier in the test instruction.

10. The method according to claim 1, characterized in that, Also includes: In response to receiving a session operation instruction sent by the current test user for any test session, the status of the test session is obtained; In response to the fact that any of the test sessions is occupied, it is determined that the current test user performs a read-only operation on any of the test sessions. In response to the state of any of the test sessions being unoccupied, it is determined that the current test user performs the operation corresponding to the session operation instruction on any of the test sessions.

11. A multi-user testing system, characterized in that, A multi-user testing system is applied to chip testing equipment, the chip testing equipment including a host computer and multiple test heads, the multi-user testing system being deployed on the host computer, the multi-user testing system including: The command-line module is used to generate a session creation request for the test user and send the session creation request to the multi-user management module. A multi-user management module is used to store at least one configured test session, and when a session creation request is received, to generate and store a test session corresponding to the session creation request. The test session includes a session identifier, a test user identifier, test header information of at least one test header, and test project information of the test project. The test execution module is used to, upon receiving at least one test instruction, obtain the target test sessions corresponding to each test instruction from the multi-user management module, and distribute the test projects of each target test session to the corresponding test heads, so that the test heads corresponding to each target test session can perform tests on the device under test in parallel based on the corresponding test projects.

12. The system according to claim 11, characterized in that, The host computer includes a test project memory, which stores multiple test projects. The multi-user management module is also used to bind the new test project to the test session in response to receiving a test project update instruction for any test session, and the status of the new test project corresponding to the test project update instruction is unoccupied. The test execution module is further configured to, in response to the successful binding of the new test project with any test session, send the new test project to the test header corresponding to any test session, so that the test header performs tests on the device under test based on the new test project.

13. The system according to claim 11 or 12, characterized in that, It also includes a caching module, and the test execution module includes: a mass production test submodule and a debugging submodule; The caching module is used to cache at least one configured test session; The mass production testing submodule is configured to, in response to each test instruction, determine the target test session corresponding to the test instruction based on the session identifier, provided that the test instruction indicates mass production testing and the test instruction includes a session identifier; determine the test session as the target test session if the test instruction indicates mass production testing, the test instruction does not include a session identifier, and the cache module of the host computer stores a test session corresponding to a test user identifier included in the test instruction; and determine the target test session based on the test user identifier and using the test session list if the test instruction indicates mass production testing, the test instruction does not include a session identifier, and the cache module does not store a test session corresponding to a test user identifier in the test instruction. The debugging submodule is used to respond to the test instruction to perform debugging tests, and determine the target test session based on the test user identifier or session identifier in the test instruction and the test session list.

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

Images