CN114036060A

CN114036060A - Method, system and computer readable medium for chip testing

Info

Publication number: CN114036060A
Application number: CN202111403458.8A
Authority: CN
Inventors: 陈参
Original assignee: Yangtze Memory Technologies Co Ltd
Current assignee: Yangtze Memory Technologies Co Ltd
Priority date: 2021-11-24
Filing date: 2021-11-24
Publication date: 2022-02-11

Abstract

Embodiments of the present invention provide methods, systems, and computer-readable media for chip testing. The method comprises the following steps: receiving a chip test request, wherein the chip test request is used for indicating a test item to be executed on a chip; determining at least one micro service related to a test item among a plurality of micro services for chip testing; running at least one microservice to perform test items on a chip; and determining a test report based on the operation result of the at least one micro service, wherein the test report is used for representing the test result of the test item executed on the chip.

Description

Method, system and computer readable medium for chip testing

Technical Field

The present invention relates generally to the field of chips, and more particularly, to methods, systems, and computer-readable media for chip testing.

Background

In recent years, with the rapid development of integrated circuit development and manufacturing technology, various chips have been produced to meet the demands of different industries. In the process of chip development, chip testing is an essential link, and mainly tests whether the functions of the chip can normally run. Therefore, how to efficiently perform chip testing becomes one of the problems to be solved.

Disclosure of Invention

In view of the above-identified problems of the prior art, embodiments of the present invention provide a method, system, and computer-readable medium for chip testing.

In one aspect, an embodiment of the present invention provides a method for chip testing, including: receiving a chip test request, wherein the chip test request is used for indicating a test item to be executed on a chip; determining at least one micro service related to the test item among a plurality of micro services for chip testing; running the at least one microservice to execute the test item on the chip; determining a test report based on the operation result of the at least one microservice, wherein the test report is used for representing the test result of the test item executed on the chip.

In some embodiments, the chip test is decomposed into a plurality of tasks which can be performed independently according to an execution flow, each of the plurality of microservices is used for completing one of the plurality of tasks, so that the plurality of microservices can run independently of each other, and each of the plurality of microservices has a calling interface which can be called by other microservices.

In some embodiments, the plurality of microservices communicate over the HTTP protocol.

In some embodiments, the programming language of each of the plurality of microservices is independent of the programming languages of other microservices.

In some embodiments, the plurality of microservices are implemented using a Python microservice architecture.

In some embodiments, running the at least one microservice comprises: sending an initiation message to each of the at least one microservice, wherein the initiation message is an HTTP protocol based message.

In some embodiments, the at least one microservice comprises at least one of: an authentication microservice for performing authentication for a user initiating the chip test request; the case management microservice is used for managing the test cases related to the test items; executing a scheduling microservice for scheduling at least one executor associated with the test item and collecting results of execution of the at least one executor; an executor microserver for executing a test script containing the test case on the chip through the at least one executor; a report microservice for generating the test report based on results of execution of the at least one actuator; a notification microservice for generating notifications related to the test item; a hardware microservice for storing information related to the chip.

In another aspect, an embodiment of the present invention provides a system for chip testing, including: a receiving unit configured to receive a chip test request, wherein the chip test request is used for indicating a test item to be executed on a chip; a micro-service determination unit configured to determine at least one micro-service related to the test item among a plurality of micro-services for chip testing; a micro-service execution unit configured to execute the at least one micro-service to execute the test item on the chip; a report determination unit configured to determine a test report based on the operation result of the at least one microservice, wherein the test report is used for representing a test result of the test item executed on the chip.

In some embodiments, the microservice operating unit is configured to: sending an initiation message to each of the at least one microservice, wherein the initiation message is an HTTP protocol based message.

In another aspect, an embodiment of the present invention provides a system for chip testing, including: at least one processor; a memory storing executable code which, when executed by the at least one processor, causes the at least one processor to implement the above method.

In another aspect, an embodiment of the present invention provides a computer-readable medium storing a computer program, which, when executed by a computer, causes the computer to implement the above-described method.

Drawings

The foregoing and other objects, features and advantages of embodiments of the invention will be apparent from the following more particular descriptions of embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like elements throughout.

FIG. 1 is a schematic block diagram of one example of a test scenario for chip testing.

FIG. 2 is a schematic diagram of a microservice in a server according to some embodiments.

FIG. 3 is a schematic flow diagram of a method for chip testing according to some embodiments.

FIG. 4 is a schematic block diagram of a system for chip testing according to some embodiments.

FIG. 5 is a schematic diagram of a framework of a system for chip testing according to some embodiments.

FIG. 6 is a schematic block diagram of a system for chip testing according to some embodiments.

Detailed Description

The subject matter described herein will now be discussed with reference to various embodiments. It should be understood that these examples are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the claims. Various embodiments may omit, replace, or add various procedures or components as desired.

As used herein, the term "include" and its variants mean open-ended terms, which can mean "including, but not limited to. The term "based on" may mean "based at least in part on. The terms "one embodiment" and "an embodiment" may mean "at least one embodiment". The term "another embodiment" may mean "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below, and a definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

Chip testing is a very important link in chip development, and is mainly used for testing whether the functions of a chip can normally run or not. The present disclosure provides a technical solution for chip testing, which will be described below with reference to specific embodiments.

In this context, a chip may be various types of chips, such as a memory chip or the like.

As shown in fig. 1, the chip 140 to be tested may be connected to the terminal device 130, such as directly or indirectly through various suitable means (such as wired or wireless means). The terminal device 130 may typically be a user device capable of applying a chip of this type to be tested. For example, the terminal device 130 may be a smartphone, tablet, computer, wearable device, other type of smart device, or a non-smart device, among others.

In chip testing, the terminal device 130 may be connected to the test device 110. The test device 110 may be connected to a server 120. These connections may be direct connections or indirect connections, may be wired connections or wireless connections, and so on. This is not a limitation herein.

In this example, the testing device 110 may implement a chip testing platform in conjunction with the Server 120, such as via a Browser/Server (B/S) mode. In this case, the test equipment 110 may implement at least a portion of the front-end functionality, while the server 120 may implement the back-end service functionality. It should be understood that although only one server 120 is shown here, in a particular implementation, there may be multiple servers, that is, the back-end service functionality may be distributed across multiple servers. This is not a limitation herein.

In particular, the test device 110 may provide front-end functionality through a browser. A user may initiate a chip test request through an interface provided by a browser of the test equipment 110. For example, the chip test request may indicate a test item to be executed for the chip 140, such as the chip test request may include various information about the test item. The browser may transmit the received chip test request to the server 120, and the server 120 may run a corresponding service based on the test item to be executed, so as to execute the test item on the chip via the test device 110 and the terminal device 130. A service as referred to herein may generally refer to a process having an application programming interface that is capable of performing various functions related to chip testing.

Currently, in some implementations, the test service provided by the server is implemented in a single structure, that is, various functions related to chip testing are integrated into a single program. However, as chip testing becomes more complex, and due to factors such as chip testing needs involving hardware (e.g., the chip to be tested), chip testing may need to run on the hardware for a longer time, etc., such a single service may also become larger and more complex, thereby possibly causing problems. For example, when a single service is maintained, code collision may easily occur, which increases labor cost, and the system may be bulky and have poor scalability in the later period. In addition, such large and complex monolithic services may require server downtime while online, resulting in inefficiencies.

In view of this, in the embodiment of the present invention, the server 120 may provide the chip test service through the micro service architecture, for example, the server 120 may provide a plurality of micro services to complete the chip test service. Specifically, the chip test may be decomposed into a plurality of tasks that can be performed independently according to its execution flow. For example, the flow of chip testing may be divided into various tasks that may be performed relatively independently, such as user authentication, test case management, test script execution, execution scheduling, test result reporting, test notification, hardware management, and so on. In this way, different tasks may be accomplished by different microservices. For example, multiple microservices may each be responsible for one task related to chip testing, with each microservice responsible for a different task. These microservices may be run independently of each other, i.e., may be scheduled individually. Therefore, the micro service architecture is utilized to carry out chip testing, and great flexibility and expandability are achieved. For example, even though the entire process of chip testing may need to run on hardware for a longer period of time, it may also facilitate upgrade extensions, such as adding micro-services for performing additional functions, unlike monolithic services that require an overall downtime. For another example, a single micro service can be used to perform hardware management on a chip to be tested, rather than being fused with other tasks, and thus, the chip can be quickly switched to a different chip for testing.

For ease of understanding, the following description is made with reference to specific examples. FIG. 2 is a schematic diagram of a microservice in a server 120 according to some embodiments. It should be understood that the following examples are not intended to limit the scope of the present invention.

As shown in fig. 2, the server 120 may provide a plurality of different microservices. For example, the server 120 may provide an authentication microservice 121, a use case management microservice 122, an execution scheduling microservice 123, an executor microservice 124, a report microservice 125, a notification microservice 126, a hardware microservice 127, and so forth.

It should be understood that the microservices that the server 120 may provide are not limited to those shown in fig. 2, and that the server 120 may provide various other different microservices in different scenarios or according to different implementation requirements.

It should also be understood that one or more of the microservices may be used in executing a test project, depending on the particular requirements of the test project. Thus, not all microservices are used at every chip test.

The authentication microservice 121 may be used to perform authentication for a user initiating a chip test. The use case management microservice 122 may be used to manage test cases related to chip testing, for example, the use case management microservice 122 may store an indicator (e.g., a pointer) indicating a test case.

Execution scheduling microservice 123 may be used to schedule one or more executors for performing chip testing and may collect the execution results of these executors. The executor microserver 124 may be used to execute test scripts including corresponding test cases on the chip through one or more executors.

The report microservice 125 may be used to obtain the execution results of the executors from the execution scheduling microservice 123 and generate test reports based on the execution results. The notification microserver 126 may be used to generate various notifications related to chip testing, such as notifications regarding completion of testing, anomalies in testing, and the like.

The hardware microservice 127 may be used to store information about the chip to be tested, such as the type, attributes, etc. of the chip.

Each microservice may have its own invocation interface to facilitate mutual invocation among each other or to be invoked by other services or microservices.

Therefore, the micro-service architecture is adopted on the server to provide chip testing service, maintenance and management are convenient, and labor cost can be greatly saved. For example, chip testing involves interaction with hardware (e.g., the chip to be tested), and the task of hardware management can be separately broken out through the microservice architecture to run as a microservice, thereby enabling convenient and clear maintenance of information for different chips. Furthermore, the architecture is easily scalable, for example by adding microservices when the functionality is not sufficient. In addition, the structure adopts a lightweight form, so that seamless online is facilitated, and the shutdown of the server is avoided. For example, the whole process of chip testing may often need to be executed on hardware for a long time, and then the micro service architecture is adopted to realize chip testing, so that seamless upgrade management can be facilitated, and the whole process does not need to be stopped for upgrade maintenance, thereby efficiently performing chip testing.

Additionally, while only a single server is shown in FIG. 2, it should be understood that in particular implementations, one or more servers may be present. Accordingly, multiple microservices may be distributed across multiple servers, rather than being centralized on a single server.

FIG. 3 is a schematic flow diagram of a method for chip testing according to some embodiments. For example, the method of fig. 3 may be implemented in the scenarios as shown in fig. 1 and 2.

As shown in fig. 3, in step 302, a chip test request may be received. The chip test request may be used to indicate a test item to be performed on the chip.

For example, a chip test request may be initiated by a user through a browser page rendered on the test device 110. The test items may represent the content of tests to be performed for the chip, such as for a memory chip, the test items may be read tests, write tests, erase tests, and so on.

In step 304, at least one microservice associated with the test item may be determined among a plurality of microservices for chip testing.

For example, in a plurality of micro services for chip testing, not every micro service needs to be used every time a test item is executed. Thus, among the plurality of micro-services, those micro-services that are relevant to the current test item may be selected.

In step 306, the at least one microservice may be run to execute test items on the chip.

In step 308, a test report may be determined based on the results of the operation of the at least one microservice. The test report may represent a test result of executing the test item on the chip.

It can be seen that the embodiments of the present invention execute the test items on the chip by running the micro-services related to the test items, and since different micro-services can be run relatively independently in a lightweight manner, the chip test can be efficiently implemented.

As described in connection with the previous examples, in some embodiments, chip testing may be broken down into multiple tasks that may be performed independently, in terms of execution flow. Each of the plurality of microservices may be used to complete one of a plurality of tasks such that the plurality of microservices may run independently of one another. Each microservice of the plurality of microservices may have a call interface that may be called by other microservices.

In some embodiments, multiple microservices may communicate via HyperText Transfer Protocol (HTTP), such as to invoke each other, exchange information, and so forth. In various embodiments, the plurality of microservices may communicate using other protocols, as the invention is not limited in this respect.

In some embodiments, the programming language of each of the plurality of microservices may be independent of the programming languages of the other microservices. For example, each microservice may be written in the same or different programming languages, thereby being more flexible in implementation and also easier to scale.

In some embodiments, the plurality of microservices may be implemented using a Python microservice architecture. The Python can provide an efficient high-level data structure, has simplicity, readability and expandability, and therefore can simply and conveniently realize the multiple micro services.

In some embodiments, in step 306, an initiation message may be sent to each of the at least one microservice. For example, the initiation message may be a message based on the HTTP protocol.

In some embodiments, the determined at least one microservice may be associated with a test item. For example, the determined at least one microservice may include at least one of:

an authentication microservice for performing authentication for a user initiating a chip test request;

the case management microservice is used for managing test cases related to the test items;

executing a scheduling microservice for scheduling at least one executor associated with a test item and collecting results of execution of the at least one executor;

the executor microservice is used for executing a test script containing a test case on a chip through at least one executor;

a report microservice for generating a test report based on results of execution by at least one actuator;

a notification microservice for generating notifications related to test items;

a hardware microservice for storing information relating to the chip.

These micro-services are run for specific test items and thus may be understood as specific examples of the corresponding micro-services shown in FIG. 2.

As shown in fig. 4, the system 400 may include a receiving unit 402, a micro-service determining unit 404, a micro-service operating unit 406, and a report determining unit 408.

The receiving unit 402 may receive a chip test request. The chip test request may be used to indicate a test item to be performed on the chip. The micro-service determination unit 404 may determine at least one micro-service related to the test item among a plurality of micro-services for chip testing. The micro-service execution unit 406 may execute at least one micro-service to execute a test item on a chip. The report determination unit 408 may determine a test report based on the result of the operation of the at least one microservice. The test report may be used to represent the results of tests performed on the chip to test the item.

In some embodiments, chip testing may be broken down into multiple tasks that may be performed independently, according to the execution flow. Each of the plurality of microservices may be used to complete one of a plurality of tasks such that the plurality of microservices may run independently of one another. Each microservice of the plurality of microservices may have a call interface that may be called by other microservices.

In some embodiments, multiple microservices may communicate via the HTTP protocol.

In some embodiments, the programming language of each of the plurality of microservices may be independent of the programming languages of the other microservices.

In some embodiments, the plurality of microservices may be implemented using a Python microservice architecture.

In some embodiments, the microservice execution unit 406 may send a startup message to each of the at least one microservice. The initiation message is a message based on the HTTP protocol.

In some embodiments, the at least one microservice may include at least one of:

a notification microservice for generating notifications related to test items;

a hardware microservice for storing information relating to the chip.

The various units of the system 400 may perform the specific processes described in conjunction with fig. 1-3, and therefore, for brevity of description, the specific operations and functions of the various units of the system 400 are not described in detail herein.

The system 400 may be implemented in hardware, software, or a combination of hardware and software.

In the example of fig. 5, the frame 500 may include a front end portion 502, a middle piece portion 504, and a rear end portion 506. It should be understood that fig. 5 does not show all of the portions of the frame 500, but only some of the portions that may be relevant to embodiments of the present invention. In particular implementations, the framework 500 may also include other components, such as a code management component, a test case implementation layer, and so forth.

The front-end portion 502 may be used to build a user interface, such as a browser interface for chip testing. For example, the front-end portion 502 may receive a chip test request from a user. The front-end portion 502 may be implemented by various suitable techniques, such as vue.

The back-end portion 506 may provide a plurality of microservices, such as the various microservices mentioned in FIG. 2 and other related microservices. The back-end portion 506 may be implemented by various suitable techniques, such as by Python Django.

The middleware portion 504 may correspond to a gateway between the front-end portion 502 and the back-end portion 506. For example, the middleware component 504 may receive a chip test request from the front-end component 502 and determine at least one microservice associated with the test item. Middleware component 504 can then send initiation messages, such as HTTP protocol based messages, to the determined microservices in backend component 506, causing the determined microservices to begin running.

When the execution of these microservices is complete and a test report is obtained, the back-end portion 506 (specifically, the reporting microservices) may send the test report to the middleware portion 504. Middleware portion 504 may send test reports to front-end portion 502. The front end portion 502 may present the test report on a browser interface for viewing by a user.

In some implementations, the notification microservice in the back-end portion 506 may generate notifications that need to be presented on the browser interface. In this case, the notification microservice may send the notification to the middleware component 504. Middleware portion 504 may send the notification to front end portion 502. The front end portion 502 can present the notification on a browser interface for viewing by a user.

Middleware portion 504 may be implemented by any suitable technique. For example, the middleware section 504 may include Nginx, or the like.

As shown in fig. 6, system 600 may include at least one processor 602 and memory 604. The at least one processor 602 and the memory 604 may be coupled together via a bus.

The memory 604 may store executable code that, when executed by the at least one processor 602, may cause the at least one processor 602 to implement the specific processes described in connection with fig. 1-3.

Embodiments of the invention also provide a computer-readable medium. The computer readable medium may store a computer program. The computer programs, when executed by a computer, may cause the computer to perform the specific processes described above with reference to fig. 1-3.

For example, a computer-readable medium may include, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically-Erasable Programmable Read-Only Memory (EEPROM), Static Random Access Memory (SRAM), a hard disk, flash Memory, and so forth. Alternatively, the computer program may be downloaded from a server computer or from the cloud by a communications network.

It should be noted that not all steps and units in the above flows and system structure diagrams are necessary, and some steps or units may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or may be implemented by some components in a plurality of independent devices together.

The elements have been described in connection with various apparatus and methods. The units may be implemented using electronic hardware, computer software, or any combination thereof. Whether elements are implemented as hardware or software depends upon the particular application and overall design constraints imposed on the system. As an example, the units, any portion of the units, or any combination of the units given in this disclosure may be implemented as a microprocessor, microcontroller, Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), Programmable Logic Device (PLD), state machine, gated logic, discrete hardware circuitry, and other suitable processing means configured to perform the various functions described in this disclosure.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for chip testing, comprising:

receiving a chip test request, wherein the chip test request is used for indicating a test item to be executed on a chip;

determining at least one micro service related to the test item among a plurality of micro services for chip testing;

running the at least one microservice to execute the test item on the chip;

determining a test report based on the operation result of the at least one microservice, wherein the test report is used for representing the test result of the test item executed on the chip.

2. The method of claim 1, wherein the chip test is decomposed into a plurality of tasks that can be performed independently according to an execution flow, each of the plurality of microservices is used to complete one of the plurality of tasks such that the plurality of microservices can run independently of each other, and each of the plurality of microservices has a calling interface that can be called by other microservices.

3. The method of claim 1 or 2, wherein the plurality of microservices communicate over the HTTP protocol.

4. The method of claim 1 or 2, wherein the programming language of each of the plurality of microservices is independent of the programming languages of other microservices.

5. The method of claim 1 or 2, wherein the plurality of microservices are implemented using a Python microservice architecture.

6. The method of claim 1 or 2, wherein running the at least one microservice comprises:

sending an initiation message to each of the at least one microservice, wherein the initiation message is an HTTP protocol based message.

7. The method of claim 1 or 2, wherein the at least one microservice comprises at least one of:

an authentication microservice for performing authentication for a user initiating the chip test request;

the case management microservice is used for managing the test cases related to the test items;

executing a scheduling microservice for scheduling at least one executor associated with the test item and collecting results of execution of the at least one executor;

an executor microserver for executing a test script containing the test case on the chip through the at least one executor;

a report microservice for generating the test report based on results of execution of the at least one actuator;

a notification microservice for generating notifications related to the test item;

a hardware microservice for storing information related to the chip.

8. A system for chip testing, comprising:

a receiving unit configured to receive a chip test request, wherein the chip test request is used for indicating a test item to be executed on a chip;

a micro-service determination unit configured to determine at least one micro-service related to the test item among a plurality of micro-services for chip testing;

a micro-service execution unit configured to execute the at least one micro-service to execute the test item on the chip;

a report determination unit configured to determine a test report based on the operation result of the at least one microservice, wherein the test report is used for representing a test result of the test item executed on the chip.

9. The system of claim 8, wherein the chip test is decomposed into a plurality of tasks that can be performed independently according to an execution flow, each of the plurality of microservices is used to complete one of the plurality of tasks such that the plurality of microservices can run independently of each other, and each of the plurality of microservices has a calling interface that can be called by other microservices.

10. The system of claim 8 or 9, wherein the plurality of microservices communicate over the HTTP protocol.

11. The system of claim 8 or 9, wherein the programming language of each of the plurality of microservices is independent of the programming languages of the other microservices.

12. The system of claim 8 or 9, wherein the plurality of microservices are implemented using a Python microservice architecture.

13. The system of claim 8 or 9, wherein the microservice execution unit is configured to:

14. The system of claim 8 or 9, wherein the at least one microservice comprises at least one of:

a hardware microservice for storing information related to the chip.

15. A system for chip testing, comprising:

at least one processor;

a memory storing executable code that, when executed by the at least one processor, causes the at least one processor to implement the method of any one of claims 1 to 7.

16. A computer-readable medium, storing a computer program which, when executed by a computer, causes the computer to carry out the method according to any one of claims 1 to 7.