Chip driver program testing method and testing system

Abstract

The application provides a chip driver program test method and a test system. The method comprises the following steps: uploading a plurality of system platform images, wherein the system platform image comprises a running environment of a system platform and a test case set for execution under the running environment; uploading a driver program, and managing the driver program and generating a smoke test task for the driver program; sequentially executing each smoke test task according to a generation sequence of the smoke test task to perform smoke test on the corresponding driver program through the corresponding system platform image; performing image packaging on the driver program, the running environment, a hardware RTL program and the test case set that pass the smoke test to obtain a smoke test image; and running the smoke test image and switching the hardware RTL program to perform regression test. The application provides a driver program test method and system that can be synchronized with a development process, can automatically manage a development version and automatically perform smoke test and regression test on a driver program.

Description

Technical Field

[0001] This invention relates to the field of chip testing, and more particularly to a chip driver testing method and testing system. Background Technology

[0002] Traditionally, embedded software was only used when building a complete system using chips. However, as SOC chips become increasingly complex, simply providing a system chip is no longer sufficient for users; they expect integrated system application solutions. The task of developing system solutions, previously undertaken by system manufacturers, has been increasingly transferred to chip design companies. Chip application solutions centered on embedded software have become a crucial bridge between chips and products. Therefore, in the SOC era, system chips and embedded software (drivers) have become interdependent and bound together. Chip driver development is carried out concurrently with the chip design phase. The main problems currently existing in chip driver development and verification are as follows:

[0003] 1) Generally, due to limitations in the hardware resources of the testing platform, one development environment corresponds to one testing platform. Chip driver developers only develop, compile, debug, and verify on a unified, conventional system platform A (such as CentOS), and then port the developed program to another system platform B (such as SUSE or Ubuntu) for compilation and debugging. This is because a mature chip driver needs to be compatible with multiple operating systems and needs to be tested under various operating environments. The advantage of this approach is that it allows developers to focus on developing and testing basic functions on one platform, and the development and verification environments use the same system platform, ensuring sufficient overall R&D resources. However, there are also corresponding disadvantages. The developed system code is very large. When the development program and development environment are migrated to another system platform B for testing, compilation issues, system platform compatibility issues, and other migration problems are often mixed together, making it relatively complex to locate and resolve driver issues. Furthermore, if the modifications also affect the already verified system platform A, it is necessary to migrate back to system platform A for testing, and redeploying the operating environment is time-consuming and labor-intensive.

[0004] 2) In collaborative software and hardware development, a main version line and respective branch versions are defined for both software and hardware. The branch versions are used for internal iterative development and self-testing by each collaborating party, while the collaborative version is used for joint testing of the software and hardware versions. During joint testing, the chip driver software typically runs on a PC, and the hardware RTL version runs on the HEMU. As testing iterates, multiple driver versions, hardware RTL versions, and joint testing versions will be generated. Migrating between these versions can easily lead to confusion and make management difficult.

[0005] Therefore, how to provide an efficient solution that can automatically deploy and switch runtime environments, as well as manage and test corresponding program versions, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] To achieve efficient driver testing that automatically deploys and switches runtime environments and manages corresponding program versions, a chip driver testing method is proposed in a first aspect of the invention. The method includes: uploading multiple system platform images, each system platform image including a system platform runtime environment and a set of test cases for execution within the runtime environment; uploading a driver, managing the driver, and generating smoke test tasks for the driver; sequentially executing each smoke test task according to the generation order to perform smoke testing on the corresponding driver using the corresponding system platform image; packaging the driver, runtime environment, hardware RTL program, and test case set that pass the smoke test into a smoke test image; and running the smoke test image and switching the hardware RTL program for regression testing.

[0007] In one or more embodiments, managing the driver and generating smoke test tasks for the driver includes: partitioning and storing the driver according to version number and branch number; performing program analysis on the driver and determining the runtime environment involved in the driver; generating a smoke test task, the smoke test task including retrieval parameters corresponding to the runtime environment, the version number and branch number, and the test case set.

[0008] In one or more embodiments, program analysis is performed on the driver to determine the runtime environment involved in the driver, including: determining the runtime environment involved by analyzing the driver; in response to the inability to determine the runtime environment involved by analyzing the driver, obtaining other branch programs based on the branch number of the driver, and determining the runtime environment involved by analyzing the other branch programs.

[0009] In one or more embodiments, each smoke test task is executed sequentially according to the generation order of the smoke test tasks to perform smoke tests on the corresponding drivers through the corresponding system platform images, including: pulling a first system platform image from the image library and starting it; in response to the inability to start the first system platform image, modifying the first system platform image in the image library and starting it again until it starts successfully; downloading the driver and a preset hardware RTL program from the code library according to the version number and Commit ID; compiling the driver; in response to the compilation failure, modifying the driver in the code library and compiling it again until it compiles successfully; running the test cases in the first system platform image to automatically perform joint smoke tests on the driver and the RTL program using the test cases therein; repeating the above process until the testing of all system platform images involved in the driver is completed.

[0010] In one or more embodiments, a chip driver testing method of the present invention further includes: in response to a system platform image startup failure, driver compilation failure, or a problem with the smoke test, stopping the execution of the current smoke task and executing the next smoke task.

[0011] In one or more embodiments, a chip driver testing method of the present invention further includes: in response to a problem occurring during joint smoke testing, mirroring and packaging the driver, operating environment, hardware RTL program, and test case set of the problem site to obtain a smoke problem image.

[0012] In one or more embodiments, a chip driver testing method of the present invention further includes: in response to a problem occurring during joint smoke testing, and determining that the cause of the problem is a hardware RTL program, modifying the hardware RTL program; storing the modified hardware RTL program in a regression testing RTL version library; running the smoke problem image and extracting the hardware RTL program and the corresponding joint debugging program from the RTL version library for joint testing with the driver program.

[0013] In one or more embodiments, running the smoke test image and switching the hardware RTL program for regression testing includes: running the smoke test image and extracting the hardware RTL program and the corresponding integration program from the RTL repository to perform joint testing with the driver.

[0014] In one or more embodiments, a chip driver testing method of the present invention further includes: in response to a regression test passing, deleting the corresponding smoke test image or smoke problem image from the image library.

[0015] In a second aspect of the invention, a chip driver testing system is proposed, comprising: a continuous integration server configured to receive uploaded drivers, manage the drivers, and generate smoke test tasks for the drivers; a testing platform pre-configured with multiple system platform images, each system platform image including a system platform runtime environment and a set of test cases for execution within the runtime environment, the testing platform being configured to sequentially execute each smoke test task according to the generation order of the smoke test tasks to perform smoke testing on the corresponding drivers through the corresponding system platform images; image packaging of the drivers, runtime environment, hardware RTL program, and test case sets that pass the smoke test to obtain a smoke test image; running the smoke test image and switching the hardware RTL program to perform regression testing.

[0016] The beneficial effects of this invention include: this invention proposes a driver testing method and testing system that can be performed synchronously with the development process; through the method and system of this invention, the development version can be managed automatically and the smoke test and regression test of the driver can be performed automatically, and since the testing process only needs to be carried out on one testing platform, many problems existing in the existing solutions are avoided. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the chip driver testing method of the present invention.

[0019] Figure 2 This is a schematic diagram of the main interaction process of the smoke test in this invention;

[0020] Figure 3 This is a flowchart illustrating a complete embodiment of the chip driver testing method of the present invention.

[0021] Figure 4 This is an interactive flowchart of the main objects of the backtesting test in this invention;

[0022] Figure 5 This is a schematic diagram of the structure of a chip driver testing system according to the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to specific examples and the accompanying drawings.

[0024] It should be noted that all uses of "first" and "second" in the embodiments of the present invention are for the purpose of distinguishing two entities or parameters with the same name but different names. It is clear that "first" and "second" are only for the convenience of expression and should not be construed as limiting the embodiments of the present invention. Subsequent embodiments will not explain this in detail.

[0025] To test chip drivers (hereinafter referred to as drivers or driver versions) under various operating environments, avoid migration issues, manage and effectively test various program versions (driver version, RTL version, and integration version), and improve testing efficiency, a chip driver testing method is proposed in a first aspect of this invention.

[0026] Figure 1 This is a flowchart illustrating the chip driver testing method of the present invention. Figure 1 As shown, the workflow of a chip driver testing method of the present invention includes: Step S1, uploading multiple system platform images, wherein the system platform image includes the system platform's operating environment and a set of test cases for execution in the operating environment; Step S2, uploading the driver, managing the driver, and generating smoke test tasks for the driver; Step S3, executing each smoke test task sequentially according to the generation order of the smoke test tasks to perform smoke testing on the corresponding driver through the corresponding system platform image; Step S4, packaging the driver, operating environment, hardware RTL program, and test case set that have passed the smoke test into an image to obtain a smoke test image; and Step S5, running the smoke test image and switching the hardware RTL program to perform regression testing.

[0027] Specifically, to avoid development migration between platforms, this invention proposes uploading multiple platform systems to the test platform as Docker images. The continuous integration server analyzes the uploaded drivers and sequentially pulls the corresponding system platform images for smoke testing. The uploaded drivers can be branches of a driver version or parts of that branch. Each time the continuous integration server receives an uploaded driver, it generates a smoke test task, automatically manages the driver, and then hands it over to the test platform for testing. This on-demand testing approach allows development and testing to proceed simultaneously, enabling timely correction of errors and effectively improving development efficiency and shortening the development cycle. Smoke testing is a strategy for quickly verifying basic software functionality, not in-depth testing of the software version package. In-depth testing requires combining hardware RTL programs to discover problems during joint testing. The main process of regression testing involves retesting the driver that has already undergone smoke testing by switching hardware RTL programs to confirm whether the driver is suitable for other hardware RTL versions and whether program modifications (including driver modifications and RTL program modifications) have introduced new errors or caused other error codes. In addition, the hardware RTL program is also involved in the smoke test, but it is only a simple test using a default RTL version and will not be tested in depth.

[0028] In one embodiment, managing the driver and generating smoke test tasks for the driver includes: partitioning and storing the driver according to its version number and branch number; performing program analysis on the driver and determining the runtime environment involved in the driver; and generating smoke test tasks, wherein the smoke test tasks include the corresponding runtime environment, version number, branch number, and call parameters for the test case set.

[0029] Specifically, in this embodiment, smoke testing and driver upload operations can be performed simultaneously. To avoid affecting the ongoing smoke test, the uploaded driver is first analyzed and stored, and a corresponding smoke test task is generated and queued. When uploading a driver, developers need to specify the driver version and its corresponding branch number.

[0030] In a further embodiment, program analysis is performed on the driver to determine the runtime environment involved in the driver, including: determining the runtime environment involved by analyzing the driver; in response to the inability to determine the runtime environment involved by analyzing the driver, obtaining other branch programs based on the branch number of the driver, and determining the runtime environment involved by analyzing the other branch programs.

[0031] Specifically, in this embodiment, the runtime environment involved in the driver is determined by analyzing macro definitions or special syntax in the program. If the uploaded driver is only a part of a branch program and cannot be analyzed solely by the currently uploaded driver, all branch programs under that branch number in the code repository will be extracted and analyzed to determine the runtime environment involved. More specifically, the continuous integration server in this embodiment can be implemented using a Gerrit server.

[0032] In one embodiment, each smoke test task is executed sequentially according to its generation order to perform smoke tests on the corresponding driver using the corresponding system platform image. This includes: pulling and starting a first system platform image from the image repository; modifying the first system platform image in the image repository and restarting it if it fails to start, until successful startup; downloading the driver and a pre-defined hardware RTL program from the code repository based on the version number and commit ID; compiling the driver; modifying the driver in the code repository and recompiling it if compilation fails, until successful compilation; running test cases from the first system platform image to automatically perform joint smoke tests on the driver and RTL program; repeating the above process until testing is completed on all system platform images involved in the driver. The code repository is managed by a continuous integration server.

[0033] Specifically, this implementation will sequentially retrieve and run the system platform image to establish the runtime environment based on the three types of retrieval parameters in the smoke test task. Then, it will retrieve, run, and compile the corresponding driver. After successful compilation, it will retrieve the corresponding smoke test suite for joint smoke testing. During the joint smoke test, the default hardware RTL program will be retrieved for joint testing with the driver. In the above process, if any issues arise such as the inability to establish the runtime environment, compilation failure, or / or problems in the joint test, the test will be stopped, and relevant personnel will be responsible for resolving the issues.

[0034] In a further embodiment, if the system platform image fails to boot, the driver fails to compile, or the smoke test encounters a problem, the current smoke task is stopped and the next smoke task is executed to improve testing efficiency.

[0035] In a further embodiment, the method of the present invention further includes: in response to a problem occurring during joint smoke testing, mirroring and packaging the driver, runtime environment, hardware RTL program, and test case set of the problem scenario to obtain a smoke problem image. This smoke problem can be used for subsequent regression testing.

[0036] In one embodiment, the method of the present invention further includes: in response to a problem occurring during joint smoke testing, and identifying the cause of the problem as the hardware RTL program, modifying the hardware RTL program; storing the modified hardware RTL program in the RTL repository for regression testing; running the smoke problem image and extracting the hardware RTL program and the corresponding integration program from the RTL repository for joint testing with the driver. The repository is also managed by a continuous integration server.

[0037] Specifically, this invention establishes an RTL version repository to manage RTL versions. In one optional embodiment, each RTL version is bound to a corresponding integration testing version, and the corresponding integration testing version is switched simultaneously when switching RTL versions. In another optional embodiment, when regression testing encounters a problem, the driver, runtime environment, hardware RTL program, and test case set of the problem scenario need to be image-packaged to obtain a regression problem image.

[0038] In a further embodiment, running a smoke test image and switching the hardware RTL program for regression testing includes: running the smoke test image and extracting the hardware RTL program and the corresponding integration program from the RTL repository for joint testing with the driver.

[0039] In one embodiment, a chip driver testing method of the present invention further includes: deleting the corresponding smoke test image or smoke problem image from the image library in response to a successful regression test. The image library is managed by the testing platform.

[0040] In one specific embodiment, the complete smoke test process of the present invention is as follows:

[0041] Figure 2 This is a schematic diagram of the main interaction process of the smoke test in this invention. (For example...) Figure 2 As shown, smoke testing primarily involves three interacting objects: the client's development environment (development server), the continuous integration deployment server, and the smoke testing environment (provided by the testing platform). The development environment is used to develop, but is not limited to, drivers, hardware RTL programs, integration testing programs, and test cases. The continuous integration server manages the received programs and generates smoke test tasks. The testing platform runs the corresponding Docker images and executes the smoke test tasks for both smoke testing and regression testing.

[0042] Figure 3 This is a flowchart illustrating a complete embodiment of the chip driver testing method of the present invention. Figure 3As shown, Step 1 involves developers submitting their code to the Gerrit server (an existing web code review tool) after completing the coding; Step 2: The continuous integration application captures the code submission and triggers a code analyzer task to analyze the system platform affected by the submission; Step 3: Based on the analyzed system platform, a smoke test task is created, taking three parameters: the system platform information selected in Step 2, the submitted code repository, branch, and commit ID information, and the corresponding smoke test case information; Step 3.1: In the smoke test environment, based on the system platform selected in Step 3, a matching system platform image is selected from the Docker image repository and started. If it fails, it returns to Step 1, requiring manual intervention to analyze the reason for the container image's failure and fix it; Step 3.2: Based on the code repository information selected in Step 3, the code corresponding to the commit ID is pulled from the code repository and compiled. If it fails, return to step 1, where manual intervention is required to analyze the cause of the compilation failure and fix it; Step 3.3: Download the test automation project according to the smoke test suite selected in step 3, run the test cases in the smoke test suite, and generate a test report. The result is returned to the continuous integration application, and the result is pushed to the database personnel at the same time. Code repair and re-entry into the database for verification are required.

[0043] Figure 4 This is a flowchart illustrating the interaction process of the main objects involved in the backtesting of this invention. (For example...) Figure 4 As shown, the specific process includes (the numbers I, J, M, N, X, and Y in the steps have no actual meaning and only represent different version numbers):

[0044] 1. S201 is the Mth version of the hardware development and has undergone internal testing by the hardware testing team;

[0045] 2. S202 is the first version of the chip driver development and has been tested by the chip driver software testing team;

[0046] 3. S203 is the planned software and hardware version X, corresponding to hardware version N and chip driver version I;

[0047] 4. S204 is used to deploy the accompanying version X to the hardware and software integration simulation HEMU environment;

[0048] 5. S205 is for joint debugging and testing of the matching version X;

[0049] 6. S206 is the step S205 test that found a problem that was ultimately located to be a problem in hardware version M. The problem is planned to be solved in hardware version N and a Bug List is added to the defect tracking library for tracking.

[0050] 7. S207 is to create a Docker image X of the software runtime environment of this version X, which will be convenient for later regression testing and verification.

[0051] 8. S301 is the Nth version of the hardware development and has undergone internal testing by the hardware testing team;

[0052] 9. S302 is the Jth version of the chip driver development and has been tested by the chip driver software testing team;

[0053] 10. S303 is the planned software and hardware version Y, corresponding to hardware version M and chip driver version J;

[0054] 11. S304 is used to deploy the matching version Y to the hardware and software integration simulation HEMU environment;

[0055] 12. S305:1 is to conduct joint debugging tests on the matching version Y;

[0056] 13. S306 is a defect issue that has entered the regression testing phase, prioritizing the verification of solutions. At this point, using Docker technology, the current version Y of the software runtime environment is created as a Docker image Y and archived.

[0057] 14. S307 is the Docker image X of the software environment corresponding to the time the problem ticket was generated;

[0058] 15. S308 is a regression test to verify whether the problem is resolved in the software environment where the problem was found, in conjunction with the new hardware version.

[0059] 16. S309 indicates that the verification problem has been resolved, and a "Image X verification successful" message is sent to the image library;

[0060] 17. S310 is the process of deleting image X after the image library receives a message;

[0061] 18. S311 restores the software testing environment to the integration test version Y before regression testing by running Docker image Y;

[0062] 19. S305:2 continues the integration testing of the corresponding version Y, and verifies in the new integration version whether the bug list in the regression test has also been successfully resolved; if not resolved, the Docker image Y of the current integration version Y will not be deleted after the test is completed.

[0063] 20. S312 is the integrated debugging version y. After testing, there are no remaining issues. Send the message "Image Y verification successful" to the image library.

[0064] 21. S313 means that the mirror library deletes mirror Y after receiving the message.

[0065] In a second aspect of the invention, a chip driver testing system is proposed. Figure 5 This is a schematic diagram of the structure of a chip driver testing system according to the present invention. Figure 5 As shown, the chip driver testing system of the present invention includes: a continuous integration server 100, configured to receive uploaded drivers, manage drivers, and generate smoke test tasks for drivers; a test platform 200, which has multiple system platform images pre-set, each system platform image including the system platform's runtime environment and a set of test cases for execution in the runtime environment; the test platform is configured to execute each smoke task sequentially according to the generation order of the smoke test tasks to perform smoke tests on the corresponding drivers through the corresponding system platform images; the driver, runtime environment, hardware RTL program, and test case set that pass the smoke test are image packaged to obtain a smoke test image; the smoke test image is run, and the hardware RTL program is switched to perform regression testing.

[0066] As described above, this invention proposes a driver testing method and system that can be performed synchronously with the development process. Through the method and system of this invention, the development version can be managed automatically, and smoke testing and regression testing of the driver can be performed automatically. Since the testing process only needs to be carried out on one testing platform, many problems existing in the existing solutions are avoided.

[0067] The above are exemplary embodiments disclosed in this invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the embodiments of this invention as defined by the claims. The functions, steps, and / or actions of the methods according to the disclosed embodiments described herein do not need to be performed in any particular order. Furthermore, although the elements disclosed in the embodiments of this invention may be described or claimed individually, they may be understood as multiple unless explicitly limited to a singular number.

[0068] It should be understood that, as used herein, the singular form “a” is intended to include the plural form as well, unless the context clearly supports an exception. It should also be understood that, as used herein, “and / or” refers to any and all possible combinations of one or more of the associated listed items.

[0069] The embodiment numbers disclosed in the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0070] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples. Within the framework of the invention, technical features of the above embodiments or different embodiments can be combined, and many other variations of different aspects of the invention exist, which are not provided in the details for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Claims

1. A chip driver testing method, characterized in that, The method includes: Upload multiple system platform images, wherein the system platform images include the system platform's operating environment and a set of test cases to be executed in the operating environment; Upload the driver, manage the driver, and generate smoke test tasks for the driver; Each smoke test task is executed sequentially according to the generation order to perform smoke tests on the corresponding drivers using the corresponding system platform image; The driver, runtime environment, hardware RTL program, and test case set that pass the smoke test are image packaged to obtain the smoke test image; Run the smoke test image and switch the hardware RTL program to perform regression testing; The process involves executing each smoke test task sequentially according to the generation order to perform smoke tests on the corresponding drivers using the corresponding system platform images. This includes: pulling and starting the first system platform image from the image library; running test cases in the first system platform image to automatically perform joint smoke tests on the driver and the RTL program using the test cases therein; and repeating the above process until all system platform images involved in the driver are tested. In response to an issue that occurred during joint smoke testing, the driver, runtime environment, hardware RTL program, and test case set of the problematic site were image-packaged to obtain a smoke problem image; In response to a problem encountered during joint smoke testing, and with the cause identified as the hardware RTL program, the hardware RTL program is modified; the modified hardware RTL program is stored in the RTL version library for regression testing; the smoke problem image is run, and the hardware RTL program and the corresponding integration program are extracted from the RTL version library for joint testing with the driver.

2. The chip driver testing method according to claim 1, characterized in that, Managing the driver and generating smoke test tasks for the driver includes: The driver program is stored in partitions according to version number and branch number; The driver program is analyzed to determine the operating environment involved in the driver program; Generate a smoke test task, which includes the call parameters corresponding to the operating environment, the version number, the branch number, and the test case set.

3. The chip driver testing method according to claim 2, characterized in that, The driver is analyzed to determine the operating environment involved, including: The operating environment involved is determined by analyzing the driver. In response to the inability to determine the relevant runtime environment by analyzing the driver, other branch programs are obtained based on the branch number of the driver, and the relevant runtime environment is determined by analyzing the other branch programs.

4. The chip driver testing method according to claim 3, characterized in that, The smoke test tasks are executed sequentially according to their generation order to perform smoke tests on the corresponding drivers using the corresponding system platform images. This also includes: In response to the inability to start the first system platform image, the first system platform image is modified in the image library and restarted until it starts successfully; Download the corresponding driver and preset hardware RTL program from the code repository based on the version number and commit ID; Compile the driver program; In response to a compilation failure, modify the driver in the codebase and recompile until compilation succeeds.

5. A chip driver testing method according to claim 4, characterized in that, The method further includes: In response to system platform image startup failure, driver compilation failure, or smoke test problems, the current smoke task is stopped and the next smoke task is executed.

6. The chip driver testing method according to claim 1, characterized in that, Run the smoke test image and switch the hardware RTL program to perform regression testing, including: Run the smoke test image and extract the hardware RTL program and the corresponding integration program from the RTL repository to perform joint testing with the driver.

7. A chip driver testing method according to claim 1 or 6, characterized in that, The method further includes: In response to the regression test passing, the corresponding smoke test image or smoke problem image is removed from the image repository.

8. A chip driver testing system, characterized in that, include: A continuous integration server is configured to receive uploaded drivers, manage the drivers, and generate smoke test tasks for the drivers. The test platform has multiple pre-set system platform images. Each system platform image includes the system platform's runtime environment and a set of test cases to be executed within that runtime environment. The test platform is configured to execute each smoke test task sequentially according to the generation order of the smoke test tasks to perform smoke tests on the corresponding drivers through the corresponding system platform images. The drivers, runtime environment, hardware RTL program, and test case sets that pass the smoke test are image packaged to obtain a smoke test image. The smoke test image is then run, and the hardware RTL program is switched to perform regression testing. The test platform is further configured to pull a first system platform image from the image library and start it; run test cases in the first system platform image to automatically perform joint smoke tests on the driver and the RTL program using the test cases therein; repeat the above process until the tests under all system platform images involved in the driver are completed; In response to an issue that occurred during joint smoke testing, the driver, runtime environment, hardware RTL program, and test case set of the problematic site were image-packaged to obtain a smoke problem image; In response to a problem encountered during joint smoke testing, and with the cause identified as the hardware RTL program, the hardware RTL program is modified; the modified hardware RTL program is stored in the RTL version library for regression testing; the smoke problem image is run, and the hardware RTL program and the corresponding integration program are extracted from the RTL version library for joint testing with the driver.

Images