Simulation test method, system and equipment for solid state disk chip and medium

Abstract

The invention discloses a simulation test method, system and device for a solid state disk chip and a medium, and relates to the technical field of chip testing, and the method comprises the steps that a test platform end and a virtual machine end mount a shared directory, the test platform end copies an adaptive test script library to a first shared folder according to a test scheduling item, and the first shared folder is used for testing the test script library; after each script execution environment is determined through analysis, a starting instruction is generated and sent to the corresponding virtual machine; and the virtual machine end generates a response after receiving the instruction, creates a second shared folder and an execution directory, executes the to-be-tested script information in the execution directory, and returns a script execution result to the test platform end, so that the technical problem that batch and multifunctional test scripts are difficult to execute in a traditional test is solved, the batch test scripts are executed through an automatic process, and the test efficiency is improved. And resource synchronization and log management are realized by utilizing the shared directory, fault environment reservation or automatic reset is supported, the test efficiency and traceability are improved, the flow continuity is guaranteed, and the technical effect of efficiently executing batch scripts is achieved.

Description

Technical Field

[0001] The present application relates to the field of chip testing technology, and in particular to a simulation testing method, system, device and medium for a solid-state drive chip. Background Art

[0002] The current new generation of information technology represented by cloud computing, big data, and artificial intelligence is changing with each passing day. The rapid development of the Internet, mobile terminals, and the Internet of Things has led to an explosive growth in the information data of corporate customers and an increasing demand for storage. In the existing technology, the main control chip designer provides a hardware project for ZeBu simulation and downloads the compiled solid-state drive (Solid State Disk or Solid State Drive, SSD) firmware to this hardware project directory. Submit and start the ZeBu resources for hardware simulation through commands in the command line of the simulation client, and then start the firmware execution. During the firmware execution process, start the virtual machine. After the virtual machine is started, fio read and write, NVMe protocol test, PCIe protocol test, etc. can be performed on the simulated SSD disk in the virtual machine.

[0003] Compared to physical SSDs and servers, simulation test environments are slower and have smaller capacity, making them suitable for debugging and self-testing single functions during firmware development. However, executing batch, multi-function NVMe SSD test scripts is more difficult. Summary of the Invention

[0004] The present application provides a simulation test method, system, device and medium for solid-state drive chips to at least solve the problem of difficulty in executing batch and multi-functional test scripts in related technologies.

[0005] In a first aspect, the present application provides a simulation test method for a solid-state drive chip, the method being used on a test platform side, comprising:

[0006] Mounting a shared directory shared with the virtual machine on the test platform side, and selecting a test script library from the test script list according to the test scheduling project and copying it to the first shared folder, wherein the shared directory includes the first shared folder;

[0007] Parse the test script library to determine the execution environment of each test script in the test script library, and generate a startup instruction based on the execution environment and send it to the corresponding virtual machine, on which the solid-state drive chip to be tested is installed;

[0008] Receive a response instruction from the virtual machine, and based on the response instruction, filter information of each script to be tested from the test script library and send it to the virtual machine;

[0009] Receive the script execution results sent by the virtual machine in sequence.

[0010] In a second aspect, the present application further provides a simulation test method for a solid-state drive chip, the method being used on a virtual machine having a solid-state drive chip to be tested installed, comprising:

[0011] Mount the shared directory shared with the test platform on the virtual machine side, and create a second shared folder in the shared directory;

[0012] Receive the start instruction, and generate a response instruction based on the start instruction and send it to the test platform end;

[0013] Receive information about the script to be tested and create an execution directory in the second shared folder;

[0014] The information of the script to be tested is copied to the execution directory, and the script to be tested is executed in the execution directory, and the generated script execution result is sent to the test platform.

[0015] The present application also provides a simulation test system for a solid-state hard disk chip, the system including: a test execution module, a script execution module, and a test scheduling module.

[0016] A test execution module, located on the test platform side, configured to execute the simulation test method for the solid-state drive chip according to any one of the first aspects;

[0017] A script execution module, located at the virtual machine end, for executing the simulation test method for the solid-state drive chip of any one of the second aspects;

[0018] The test scheduling module is used to create a test scheduling project and call the test execution module to implement the test of the solid-state drive chip to be tested. The test scheduling project includes a test script list and preset auxiliary parameters.

[0019] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned simulation test methods for a solid-state hard disk chip when executing the computer program.

[0020] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned simulation test methods for solid-state hard disk chips are implemented.

[0021] Through this application, since the test scheduling module creates test scheduling projects and manages test scripts, the test script list in the test scheduling project covers all possible test scripts. By mounting a shared directory and copying the possible test script library to the test platform end, and utilizing the shared directory and message interaction mechanism between the test platform end and the corresponding virtual machine, it supports multiple virtual machines to execute different test scripts in parallel, thereby realizing parallel testing of the solid-state drive chip to be tested. Therefore, it can solve the technical problem of difficulty in executing batch and multi-functional test scripts, and achieve the technical effect of improving test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0023] Figure 1 A schematic diagram of a flow chart of a solid-state drive chip simulation test method provided in an embodiment of the present application applied to a test platform;

[0024] Figure 2 A flowchart of a simulation test method for a solid-state drive chip provided in an embodiment of the present application applied to a virtual machine side;

[0025] Figure 3 A schematic diagram of the process of data interaction between the test platform and the virtual machine in the simulation test method of the solid-state drive chip provided in an embodiment of the present application;

[0026] Figure 4 This is a structural block diagram of a simulation test system for a solid-state drive chip provided in an embodiment of the present application;

[0027] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0030] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0031] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the simulation test method of the solid-state drive chip depends, the specific application environment architecture or specific hardware architecture is described herein.

[0032] Solid-state drives (SSDs) that adhere to the Non-Volatile Memory express (NVMe) host controller interface specification use non-volatile memory chips as storage media, along with NVMe and the high-speed Peripheral Component Interconnect Express (PCIe) interface. Compared to traditional hard drives, these drives offer significantly improved read and write speeds, significantly reduced latency, and advantages in energy consumption and reliability. ZeBu, a high-performance hardware-assisted verification tool developed by Synopsys, is primarily used to accelerate the verification of large-scale digital systems. By running system-on-chip (SoC) design prototypes on hardware, ZeBu achieves faster speeds and greater capacity than pure software simulation, significantly shortening verification cycles. ZeBu provides strong support, particularly during software development and system integration.

[0033] During the NVMe SSD development process, it may be necessary to verify the main control chip functions on a simulation platform such as ZeBu. The ZeBu simulation platform, combined with a physical server and open-source virtual machine management software (such as VirtualBox), can create a complete host computer and NVMe SSD test environment. This environment allows verification of NVMe and PCIe protocol-related functions, such as input / output read / write, Admin management commands, PCIe reset, and PCIe base address registers.

[0034] The usage process of the ZeBu simulation platform generally includes: SSD firmware preparation, ZeBu resource application and submission, SSD firmware starting, virtual machine starting, and performing fio read and write (fio is an open source input / output performance test tool, mainly used for evaluating the performance of a storage device) on the simulated SSD disk, NVMe protocol test, PCIe protocol test, and the like. The existing simulation test has the following problems:

[0035] (1) It is difficult to execute batch and multifunctional NVMe SSD disk test scripts.

[0036] (2) There is a lack of test script scheduling and test log and test result management functions.

[0037] (3) When the simulation test environment encounters a firmware assertion fault during execution of a test script in a virtual machine, the ZeBu resource can only be exited and the entire ZeBu simulation test is restarted.

[0038] Based on the above problems, the embodiment of the application provides a simulation test method and system for a solid state disk chip, by setting a shared directory of a test platform end and a corresponding virtual machine, and using a test scheduling module to manage test scripts, so as to efficiently execute batch and multifunctional test scripts.

[0039] The embodiment of the application provides a simulation test method for a solid state disk chip, Figure 1 is a flowchart of the simulation test method for the solid state disk chip according to the embodiment of the application. The method is applied to a test platform end, as shown in FIG. 1, and the flowchart includes the following steps: Figure 1

[0040] Step S101, mounting a shared directory shared by a test platform end and a virtual machine end, and copying a test script library from a test script list to a first shared folder according to a test scheduling project, the shared directory including the first shared folder.

[0041] Specifically, the test platform end can be a ZeBu simulation client. In order to facilitate the test platform end and the virtual machine end to exchange test script libraries, test logs and the like, a shared directory of a network file system (Network FileSystem, NFS) is mounted on the test platform end and the virtual machine end, and a first shared folder and a second shared folder are newly created in the shared directory, where the first shared folder can be a scripts directory used for storing the test script library, and the second shared folder can be a work directory used for executing the test script and storing log files in the test script execution process. Before testing, the test script library used for this test needs to be copied to the first shared folder of the NFS shared directory according to the test requirements.

[0042] ​The test scheduling project is created by using Jenkins software. Jenkins is an open source continuous integration and continuous delivery / deployment software for automating various tasks, including building, testing and deploying software. Jenkins supports various running modes, and can be run through a system package, Docker or a standalone Java program. Docker is a software platform that can quickly build, test and deploy applications. Docker packages software into standardized units called containers. A test scheduling project Jenkins Job is created on the Jenkins Web page as an entry for test execution and configuration. The test scheduling project Jenkins Job contains a test script list, which includes all possible test script libraries. Each line of the test script list represents a test script and related information.

[0043] Before testing the solid state disk chip, a ZeBu simulation client is configured on Jenkins as a test execution node, and is associated to the test execution node in the Jenkins Job. When the Jenkins Job is started, the ZeBu simulation client is logged in through an encrypted network protocol, and a test execution module of the ZeBu simulation client is called.

[0044] The test execution module selects a test script library that may be used for this test from the test script list according to the solid state disk chip to be tested, and copies the test script library to a first shared folder.

[0045] In step S102, the test script library is parsed to determine the execution environment of each test script in the test script library, and a start instruction is generated based on the execution environment and sent to the corresponding virtual machine. The virtual machine is installed with the solid state disk chip to be tested.

[0046] Specifically, the test script library contains multiple test scripts and related information. Each test script is checked and filtered in turn, and seven parameter values are parsed: ZeBu hardware engineering directory, firmware file, ZeBu simulation test resource, virtual machine, test script library, test script and test script. Among them, the ZeBu hardware engineering directory, firmware file, ZeBu simulation test resource and virtual machine constitute the execution environment of the corresponding test script, and the test script library, test script and test script constitute the test script information of the corresponding test script.

[0047] When initially executed, the test execution module copies the firmware file to the ZeBu hardware engineering directory according to the execution environment of the first valid test script, submits and starts the ZeBu simulation test resource, and generates a start instruction and sends it to the corresponding virtual machine during firmware execution. The virtual machine is installed with a solid state disk containing the solid state disk chip to be tested.

[0048] Step S103: receiving a response instruction from the virtual machine, and filtering information of each script to be tested from the test script library based on the response instruction and sending the information to the virtual machine.

[0049] Specifically, after the test execution module receives the response instruction of the virtual machine, it filters the script information to be tested from the test script library and sends it to the virtual machine, and continues to wait until the test execution result. It should be noted that the communication between the test execution module and the virtual machine can be achieved by configuring a mosquitto server or a message queue telemetry transmission (Message Queuing Telemetry Transport, MQTT) server. Install and configure the mosquitto service to provide the MQTT message publish / subscribe service. The test execution module on the test platform end and the script execution module on the virtual machine end all subscribe to the same channel during execution. In this embodiment, the virtual machine name is used as the channel name, and then the message that needs to be transmitted to the other party is published in the channel. The channel can also be divided into two opposite channels to distinguish messages in different directions. This is only for example, but not limited to this.

[0050] The test execution module is used to parse the test script list and check the content of the current line. The check items include: verifying whether the ZeBu hardware project directory, firmware file, test script library exist, whether the ZeBu resources and virtual machine are idle, etc. After the check passes, the test execution module will execute the test script of the current line and determine whether the execution environment of the current line test script is the same as the execution environment of the previous line test script. If they are the same, the current execution environment will be used to execute the current script. If they are not the same, a new test execution environment will be started according to the execution environment of the current line test script.

[0051] Step S104: receiving the script execution results sent by the virtual machine in sequence.

[0052] Specifically, the virtual machine executes the received test scripts in sequence and feeds back the script execution results. After receiving the script execution results, the test execution model analyzes and records them in the test result file.

[0053] After the test execution environment of the test execution module is started, it interacts with the script execution module on the virtual machine. The script execution module executes the test script and sends it to the test execution module. The test execution module receives the test result message of the script execution result and makes a judgment based on the result. If the result is "PASS", the current test script result is recorded as a successful pass. If the result is "FAIL", the current test script result is recorded as a failure. If the result is "ENV_RESET", the current test script result is recorded as a failure and the current ZeBu test execution environment is exited. Then, the next line of the test script is executed until all test scripts are executed.

[0054] The simulation test method for solid-state drive chips provided in this embodiment includes a test script list in the test scheduling project that covers all possible test scripts. By mounting a shared directory and copying the possible test script library to the test platform end, manpower investment and operation time are reduced. Through the shared directory and message mechanism between the test platform end and the corresponding virtual machine, multiple virtual machines are supported to execute different test scripts in parallel, thereby realizing the execution of batch and multi-functional test scripts and greatly improving test efficiency.

[0055] In some optional implementations, the script execution result includes: success, failure, or firmware failure, and the method further includes:

[0056] If the script execution result is a firmware failure, preset auxiliary parameters are obtained based on the test scheduling project.

[0057] If the preset auxiliary parameter is the first preset flag, the current fault environment is retained and the test state is exited.

[0058] If the preset auxiliary parameter is the second preset flag, the current simulation test resource is exited and the execution environment is restarted according to the next script to be tested.

[0059] Specifically, the specifications of the script execution results fed back by the virtual machine include "PASS", "FAIL", and "ENV_RESET", where "PASS" indicates that the test script is executed successfully, "FAIL" indicates that the test script fails to execute, and "ENV_RESET" indicates that a firmware failure occurs during the script execution.

[0060] If the script execution result has an "ENV_RESET" signal, it is necessary to further judge by obtaining the preset auxiliary parameters. The values ​​of the preset auxiliary parameters are preset in advance according to the test requirements before the test is executed. The preset auxiliary parameters are input into the test execution module together with the test script list as input parameters of the test scheduling module. If the preset auxiliary parameter is_ZEBU_ENV_RESET is the first preset flag (for example, "0"), the test execution module exits and retains the current fault environment for developers to analyze; if the preset auxiliary parameter is_ZEBU_ENV_RESET is the second preset flag (for example, "1"), it is considered that a firmware failure has occurred and subsequent test scripts cannot be continued on the current virtual machine. At this time, it is necessary to exit the current ZeBu resources and then restart the ZeBu simulation environment according to the execution environment in the information of the next valid test script in the test script list.

[0061] A "fault injection" interface can be added to the script execution module. When the preset auxiliary parameter is the first preset flag, abnormal data similar to the current fault (such as simulated PCIe link errors and NAND bad blocks) is automatically injected based on historical fault data to verify the fault tolerance of the firmware. For example, when an ENV_RESET is triggered by a "PCIe timeout", subsequent tests can actively inject a slight PCIe delay to observe whether the firmware can recover normally and avoid serious faults. This is just an example, but not limited to this.

[0062] In a specific embodiment, the PCIe protocol stability of the NVMe master chip is tested, specifically including:

[0063] (1) Test script library: including pcie_reset_test.py (used to verify the PCIe hot restart function) and multi_queue_test.py (used for multi-queue concurrent reading and writing).

[0064] Set the value conditions of the preset auxiliary parameter is_ZEBU_ENV_RESET in advance: during debugging in the development phase, set it to 0 (retain the fault environment); during the batch regression testing phase, set it to 1 (automatically restart and continue testing).

[0065] (2) When executing the script pcie_reset_test.py, the virtual machine returns the execution result ENV_RESET, indicating that the firmware assertion failed after the PCIe reset, resulting in a lost disk. At this point, the test execution module exits, retaining the current ZeBu resources and virtual machine environment. Developers can view the following contents through the shared directory: the PCIeERROR log in the virtual machine's / var / log / dmesg; the firmware debug log of the ZeBu simulation client (such as firmware_debug.log); and the code line where the assertion failed (such as pcie_reset.c:line 1245).

[0066] (3) When executing the script multi_queue_test.py, the virtual machine returns ENV_RESET, indicating that the firmware memory exceeded the bounds under high concurrency, resulting in a disk failure. The test execution module automatically exits the current ZeBu resource and restarts the simulation environment based on the execution environment of the next valid script data_retention_test.py (e.g., different firmware versions, ZeBu resource nodes), continuing to execute subsequent tests while recording the location of the faulty script and environment parameters (e.g., queue depth = 64, input / output depth = 32).

[0067] The simulation test method for solid-state drive chips provided in this embodiment adds preset auxiliary parameters. When a firmware failure occurs, it further determines to exit the current simulation test resources based on the preset auxiliary parameters and restart the execution environment according to the next script to be tested. There is no need to restart the entire test process, thereby ensuring the continuity of the test and reducing the time wasted due to failures.

[0068] In some optional implementations, the process of determining the test script library includes:

[0069] Get the type and function of the solid-state drive chip to be tested.

[0070] Specifically, the test involves obtaining the type of SSD chip to be tested, such as the main control chip, flash memory chip, or cache chip, and the functions to be tested of the SSD chip to be tested, including but not limited to protocol compatibility testing, performance testing, firmware function testing, and multi-queue and concurrency testing. For example, a random read and write test is performed continuously for 48 hours at a constant temperature of 60°C on the main control chip of an enterprise-class NVMe SSD. The fluctuation range of the parameter "number of read and write operations per second" is monitored using the fio tool to ensure that performance degradation under temperature drift does not exceed 10%.

[0071] The test script library is determined based on the type of the solid-state drive chip to be tested and the function to be tested.

[0072] Specifically, based on different types of solid-state drive chips and functions to be tested, test scripts need to be designed specifically, but the types of solid-state drive chips and functions to be tested are limited, so the test script list includes test scripts for testing different functions of different solid-state drive chips. When conducting tests, multiple test scripts are selected from the test script list to form a test script library based on the type of solid-state drive chip to be tested and the function to be tested.

[0073] The simulation test method for solid-state drive chips provided in this embodiment determines the script library according to the chip type and function, ensures the targeted test, avoids invalid tests, improves test efficiency, dynamically adjusts the script library according to the chip type and function, adapts to different test requirements, improves the adaptability of the test platform, avoids blind testing, reduces resource waste, and at the same time improves test accuracy and shortens the R&D cycle.

[0074] Figure 2 Flowchart of a simulation test method for a solid-state hard disk chip according to an embodiment of the present invention, the method is used for installing a virtual machine end having a solid-state hard disk chip to be tested, such as Figure 2 As shown, the process includes the following steps:

[0075] Step S201: Mount a shared directory shared with the test platform on the virtual machine side, and create a second shared folder in the shared directory.

[0076] Specifically, a solid-state drive is installed on the virtual machine side, and the chip on the solid-state drive is the solid-state drive chip to be tested. The virtual machine side adds the mounted NFS shared directory to the / etc / fstab file to ensure that the virtual machine side can be automatically mounted without manual intervention after booting. Before the test, the test platform side will copy the script library required for this test to the scripts folder of the shared directory. After the virtual machine side is started, it automatically obtains the resources of the test script library through the NFS shared directory. The second shared folder created under the shared directory can be a work directory, which is used to execute test scripts and store log files during the execution of test scripts. Through the isolation mechanism of the work directory, the confusion of logs and script files of different test tasks is avoided, and the degree of automation of the test process and the traceability of results are improved. For example, when a firmware failure occurs during the test process, developers can directly access the log files under the work directory through the shared directory, quickly locate the time point of the failure and related operation records, without the need to manually export data within the virtual machine, greatly shortening the failure analysis cycle.

[0077] Step S202: receiving a start instruction, and generating a response instruction based on the start instruction and sending it to the test platform.

[0078] Specifically, after the virtual machine is started according to the startup instruction, the script execution module is started through the startup service configured by the system daemon systemd on the virtual machine. After the module is started, it will send a response instruction (such as the "virtual machine ready" message) to the ZeBu simulation client through MQTT, and continue to wait for the simulation client's test script information.

[0079] Step S203: Receive information about the script to be tested, and create an execution directory in the second shared folder.

[0080] Specifically, the virtual machine receives the test script information sent by the test platform through a message queue (such as MQTT). The content includes the script name (such as nvme_temp_stress_test.py), execution parameters (such as test duration of 48 hours and temperature of 60°C), and dependent environment (such as fio tool version). The system automatically parses the task ID, chip type, and function tag (such as "high temperature performance") in the information to provide a basis for subsequent directory creation and script screening.

[0081] Automated creation of execution directories: Under the second shared folder (such as / mnt / nfs_share / work / ), generate execution directories according to the rule of {timestamp}_{task ID}_{chip type}_{function label}. For example, the execution directory for the NVMe controller chip high-temperature test performed on June 24, 2025 is named 202506241530_007_nvme_controller_temp_stress, which is only an example and is not limited thereto.

[0082] Internal substructure of execution directories by function: scripts / - stores test script bodies; config / - stores execution parameter configuration files (such as temp = 60℃, duration = 48h); logs / - records real-time script running logs; results / - saves final test result files (such as IOPS data report).

[0083] Each execution directory is independently assigned user permissions (such as ssd_test:ssd_test) to avoid resource conflicts when multiple tasks are running in parallel; set the directory executable permission through chmod 755 to ensure that the test script can be normally called.

[0084] In step S204, the information of the test script to be tested is copied to the execution directory, and the test script to be tested is executed in the execution directory to generate a script execution result sent to the test platform end.

[0085] Specifically, after receiving the test script information, the script execution module creates a new execution directory in the work directory to execute the current test job, and copies the test script library containing the test script information to the execution directory. The test script is executed in the execution directory, and the script execution result is sent to the test execution module of the test platform end.

[0086] The virtual machine end copies the target script and its associated files (such as configuration files, tool function libraries) from the script library in the shared directory according to the received script information (such as name, version) to the subdirectory of the execution directory. For example, the pcie_reset_test.py script for testing the NVMe controller chip needs to synchronize the dependent nvme_utils.py tool module, and the cp-r command is used to ensure file integrity. The cp-r command is a Linux system command for recursively copying files or directories. After copying is completed, the system automatically verifies file correctness through hash value comparison. If the verification fails, an error feedback is sent to the test platform end, and the current task is terminated to avoid test misjudgment caused by damaged scripts.

[0087] Based on the parameters in the test task information (such as temperature and queue depth), a real-time configuration file is generated in a subdirectory of the execution directory. For example, during high-temperature testing, a temp_config.ini file is generated with target_temp = 60°C. This file is automatically read when the script starts to adapt to different test scenarios. Use chmod + x to grant executable permissions to the script to ensure that the bash script.py or python3 script.py command can be called normally. Temporarily set environment variables (such as exportFIO_DIR = / usr / bin) to specify the path of dependent tools to prevent execution failures due to environmental differences.

[0088] Start a parallel real-time monitoring thread and check the script process status and hardware indicators every 10 seconds.

[0089] After the script is executed, the execution results, task duration, process flags, key log fragments, etc. are automatically summarized to form a complete test result and test log.

[0090] The simulation test method for solid-state drive chips provided in this embodiment realizes automatic synchronization of test scripts by mounting a shared directory shared with the test platform end, eliminating the need to manually deploy scripts in the virtual machine, reducing configuration errors, and automatically creating an execution directory according to test requirements to ensure isolation of the test environment and avoid interference between scripts. The execution results of each test script are independently stored in the corresponding directory to avoid log confusion and accelerate fault problem location.

[0091] In some optional embodiments, the method further comprises:

[0092] During the execution of the script to be tested, a test log is generated and stored in the execution directory of the second shared folder.

[0093] Specifically, the test logs generated during the test script execution are stored in the execution directory. By sharing the directory, the test scripts and log files in the execution directory can be directly viewed on the ZeBu simulation client, and the path or partial content information can be displayed on the Jenkins software.

[0094] The simulation test method for solid-state hard drive chips provided in this embodiment is that the test logs generated during the execution of the test script will be stored in a specified shared folder of the shared directory, and the scripts, logs and other files in the test execution directory can be directly viewed on the test platform through the shared directory. The path or partial content information can also be displayed on the test scheduling software, forming a complete test log collection and test result recording system, which is convenient for tracing the test process and troubleshooting.

[0095] In some optional implementations, executing the script to be tested in the execution directory to generate the script execution result includes:

[0096] A parallel thread is started to monitor the solid state drive detection information to determine whether a preset fault keyword exists in the solid state drive detection information.

[0097] Specifically, the script execution module will start parallel threads to monitor the NVMe SSD drive letter on the virtual machine and preset fault keywords such as "ERROR" and "TIMEOUT" in the system DMESG (a command line tool used to access the kernel ring buffer in the Linux system, belonging to the util-linux project. Its main function is to display log information such as hardware detection, driver loading and error events generated by the kernel during the system startup phase and runtime, and is stored in files by default).

[0098] If the preset fault keyword exists in the solid-state drive detection information, the script execution result is that a firmware fault occurs.

[0099] Specifically, when a preset fault keyword exists, it is determined that a firmware fault has occurred, and "ENV_RESET" will be sent when a firmware fault occurs.

[0100] The script execution module is also responsible for starting a monitoring thread to continuously check whether the SSD under test on the current virtual machine has experienced any failures, such as disk dropout, due to assertions. An assertion is a pre-set logical judgment point in firmware development: when the program reaches a certain assertion location, it checks whether specific conditions (such as data integrity, status register values, operation timing, etc.) are met. If the conditions are not met (i.e., an "assertion failure"), it is considered a firmware logic error or hardware anomaly, which usually triggers the fault handling mechanism (such as stopping the current operation and recording the error log). In severe cases, it may cause the SSD to "drop out" (i.e., the system cannot recognize the drive).

[0101] The simulation test method for the solid-state drive chip provided in this embodiment starts parallel threads to monitor the solid-state drive detection information, which can detect firmware faults in real time and avoid missed faults. It can judge faults by pre-set fault keywords, quickly locate problems, and improve troubleshooting efficiency.

[0102] This embodiment also provides a method for implementing a simulation test of a solid-state hard disk chip by data interaction between a test platform and a virtual machine. Figure 3 The following is a flow chart: Figure 3 As shown, the process includes the following steps:

[0103] Step S301: Mount a shared directory shared with the virtual machine on the test platform, and select a test script library from a test script list according to a test scheduling project and copy it to a first shared folder. The shared directory includes the first shared folder.

[0104] Step S302 , parsing the test script library, determining the execution environment of each test script in the test script library, and generating a startup instruction based on the execution environment and sending it to the corresponding virtual machine, on which the solid state drive chip to be tested is installed.

[0105] Step S303: Mount the shared directory shared with the test platform on the virtual machine side, and create a second shared folder in the shared directory.

[0106] Step S304: receiving a start instruction, and generating a response instruction based on the start instruction and sending it to the test platform.

[0107] Step S305 , receiving a response instruction from the virtual machine, and filtering information of each script to be tested from the test script library based on the response instruction and sending the information to the virtual machine.

[0108] Step S306: Receive information about the script to be tested, and create an execution directory in the second shared folder.

[0109] Step S307 , copying the information of the script to be tested to the execution directory, executing the script to be tested in the execution directory, generating a script execution result and sending it to the test platform end.

[0110] Step S308: receiving the script execution results sent by the virtual machine in sequence.

[0111] The further detailed description of each of the above steps is the same as that of the above corresponding embodiments and will not be repeated here.

[0112] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0113] An embodiment of the present application also provides a simulation test system for a solid-state hard disk chip, which is used to implement the above-mentioned embodiments and preferred implementation methods. The description of the features in the embodiments corresponding to the simulation test system for the solid-state hard disk chip can be found in the relevant description of the embodiments corresponding to the simulation test method for the solid-state hard disk chip, and will not be repeated here one by one.

[0114] like Figure 4 As shown, the simulation test system for solid-state drive chips includes:

[0115] The test execution module 401 is located on the test platform side and is used to execute the simulation test method of the solid state drive chip of any one of the first embodiments.

[0116] The script execution module 402 is located at the virtual machine end and is used to execute the simulation test method of the solid state drive chip of any one of the second embodiments.

[0117] The test scheduling module 403 is used to create a test scheduling project and call the test execution module to implement the test of the solid-state drive chip to be tested. The test scheduling project includes a test script list and preset auxiliary parameters.

[0118] Specifically, in this embodiment, Jenkins is used as a test scheduling module, and a new test scheduling project is created on the Jenkins Web page. The test scheduling project includes a test script list, and each line of the test script list represents a test script, specifically including the test script and the corresponding execution environment and execution parameters. In addition to the test list, the test scheduling project also includes a Job-level preset auxiliary parameter is_ZEBU_ENV_RESET, which is used to indicate whether to restart the entire ZeBu simulation test when a fault occurs during script execution. When performing a test, the test scheduling project calls the test execution module on the test platform side and inputs the test script list and the preset auxiliary parameters into the test execution module.

[0119] The simulation test system for solid-state drive chips provided in this embodiment creates test scheduling projects and manages test scripts through a test scheduling module, realizes continuous batch execution of test scripts on the test platform side, executes test scripts on the virtual machine side, realizes parallel testing of the solid-state drive chips to be tested, and improves test efficiency.

[0120] The embodiment of the present application also provides an electronic device, such as Figure 5 As shown, it includes a memory 10 and a processor 20, the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any of the above-mentioned embodiments of the simulation test method for solid-state hard disk chips.

[0121] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned embodiments of the simulation test method for solid-state hard disk chips when running.

[0122] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0123] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. The above describes in detail the simulation test method, system, device and medium for a solid-state drive chip provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core ideas of this application. It should be noted that for those skilled in the art, without departing from the principles of this application, various improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A simulation test method for a solid state drive chip, characterized in that: The method is used for testing the platform side, and includes: Mounting a shared directory shared with the virtual machine on the test platform side, and screening a test script library from a test script list according to a test scheduling project and copying it to a first shared folder, wherein the shared directory includes the first shared folder; Parsing the test script library to determine the execution environment of each test script in the test script library, and generating a startup instruction based on the execution environment and sending it to a corresponding virtual machine, on which the solid-state drive chip to be tested is installed; receiving a response instruction from the virtual machine, and filtering information of each script to be tested from the test script library based on the response instruction and sending the information to the virtual machine; Receive the script execution results sent by the virtual machine in sequence.

2. The simulation test method for a solid-state hard disk chip according to claim 1, wherein: Parsing the test script library to determine the execution environment of each test script in the test script library includes: Parse the test scripts in the test script library respectively to determine the hardware engineering directory, firmware file, simulation test resource, virtual machine, and test script information of each test script, wherein the test script information includes: test script library, test script, and test script parameters; The execution environment of each test script is determined based on the hardware engineering directory, firmware files, simulation test resources, and virtual machines.

3. The simulation test method for a solid-state hard disk chip according to claim 1, wherein: The process of determining the test script library includes: Get the type of the solid-state drive chip to be tested and the function to be tested; A test script library is determined based on the type of the solid-state drive chip to be tested and the function to be tested.

4. The simulation test method for a solid-state hard disk chip according to any one of claims 1 or 2, characterized in that: The script execution result includes: success, failure, and firmware failure. The method further includes: If the script execution result is that a firmware fault occurs, obtaining preset auxiliary parameters based on the test scheduling item; If the preset auxiliary parameter is the first preset flag, retain the current fault environment and exit the test state; If the preset auxiliary parameter is the second preset flag, the current simulation test resource is exited and the execution environment is restarted according to the next script to be tested.

5. A simulation test method for a solid state drive chip, characterized in that: The method is used for a virtual machine terminal equipped with a solid-state hard disk chip to be tested, and the method comprises: Mount the shared directory shared with the test platform on the virtual machine side, and create a second shared folder in the shared directory; Receive a start instruction, and generate a response instruction based on the start instruction and send it to the test platform end; Receive information about the script to be tested and create an execution directory in the second shared folder; The information of the script to be tested is copied to the execution directory, and the script to be tested is executed in the execution directory, and the script execution result is generated and sent to the test platform end.

6. The simulation test method for a solid state drive chip according to claim 5, characterized in that: The method further comprises: During the execution of the script to be tested, a test log is generated and stored in the execution directory of the second shared folder.

7. The simulation test method for a solid state drive chip according to claim 5, wherein: Execute the script to be tested in the execution directory to generate a script execution result, including: Starting a parallel thread to monitor solid-state hard drive detection information, and determining whether a preset fault keyword exists in the solid-state hard drive detection information; If the preset fault keyword exists in the solid state drive detection information, the script execution result is that a firmware fault occurs.

8. A simulation test system for a solid-state hard disk chip, characterized in that: The system includes: a test execution module, a script execution module, and a test scheduling module, wherein: A test execution module, located on the test platform side, for executing the simulation test method for the solid-state drive chip according to any one of claims 1 to 4; A script execution module, located at the virtual machine end, for executing the simulation test method of the solid-state drive chip according to any one of claims 5 to 7; The test scheduling module is used to create a test scheduling project and call the test execution module to implement the test of the solid-state drive chip to be tested. The test scheduling project includes a test script list and preset auxiliary parameters.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor is used to implement the steps of the simulation test method of the solid-state hard disk chip as described in any one of claims 1 to 4 or claims 5 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the simulation test method of the solid-state hard disk chip as claimed in any one of claims 1 to 4 or claims 5 to 7 are implemented.

Images