A stability testing method, system, device and storage medium for UFS devices

Abstract

The present invention discloses a stability testing method, system, device, and storage medium for a UFS device. The method includes: dividing a storage unit of the UFS device into m storage partitions, and obtaining n target tasks; randomly assigning the n target tasks to the m storage partitions; randomly obtaining n target operation commands corresponding to the n target tasks; asynchronously sending the n target operation commands to the m storage partitions; randomly sending a task termination command to one or more target tasks to perform a termination test and obtain a target test result; and generating a stability test report based on the target test result. The target operation command is randomly selected to execute the operation of the target task to ensure a comprehensive test of the operation relative to the target task, and the task termination command is randomly sent to one or more target tasks to ensure a comprehensive test, thereby improving the accuracy of the test.

Description

Technical Field

[0001] The present invention relates to the field of UFS testing technology, and in particular to a stability testing method, system, device, and storage medium for a UFS device. Background Art

[0002] Universal Flash Storage (UFS), as a common storage device, is widely used in various electronic devices.

[0003] There are many different types of UFS storage device controllers available, and each Android version's controller task management module handles exceptions differently. Inconsistent command timings often lead to UFS device firmware freezes, command timeouts, and firmware command processing errors. Therefore, accurately testing the stability of UFS devices is a pressing technical challenge. Summary of the Invention

[0004] In view of this, an object of the embodiments of the present invention is to provide a stability testing method, system, apparatus, and storage medium for a UFS device, which can accurately perform stability testing on a UFS device.

[0005] In a first aspect, an embodiment of the present invention provides a stability testing method for a UFS device, which is applied to a UFS test board. The UFS test board is communicatively connected to a UFS device, and the UFS device is provided with a storage unit. The stability testing method for the UFS device includes:

[0006] Divide the storage unit of the UFS device into m storage partitions, and obtain n target tasks, where m and n both represent positive integers greater than or equal to 1;

[0007] Randomly assigning the n target tasks to the m storage partitions;

[0008] Randomly acquiring n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of the preset command types;

[0009] asynchronously sending n target operation commands to m storage partitions, where the target operation commands correspond to the target tasks one by one, and the UFS device asynchronously performs target operations on the target tasks according to the target operation commands;

[0010] Randomly sending a task termination command to one or more of the target tasks, so that a termination test is performed after the target task is terminated to obtain a target test result, the task termination command including a first termination command and a second termination command, the first termination command being used to terminate the target task being executed or not being executed, and the second termination command being used to terminate the target task that has been completed;

[0011] Generate a stability test report based on the target test results.

[0012] In some optional embodiments, dividing the storage unit of the UFS device into m storage partitions includes:

[0013] Obtaining configuration parameters, where the configuration parameters represent partition data of the Android system;

[0014] determining a partitioning scheme of the storage unit according to the configuration parameters;

[0015] The storage unit is divided into m storage partitions according to the partitioning scheme, and the storage partitions have corresponding capacity sizes, data storage types and access permissions.

[0016] In some optional embodiments, randomly allocating the n target tasks to the m storage partitions includes:

[0017] Marking the m storage partitions in sequence to obtain m partition labels;

[0018] Randomly matching the n target tasks with the m partition labels in sequence, so that the n target tasks correspond to different partition labels;

[0019] Asynchronously sending the n target tasks to the corresponding storage partitions.

[0020] In some optional embodiments, the randomly acquiring n target operation commands corresponding to the n target tasks includes:

[0021] Execute for each of the n target tasks:

[0022] Randomly selecting the target operation command stored in the array;

[0023] The array subscript corresponding to the target operation command is mapped to the target task, so that the target task corresponds to the target operation command.

[0024] In some optional embodiments, randomly sending a task termination command to one or more target tasks so as to perform a termination test after the target tasks are terminated to obtain a target test result includes:

[0025] In a case where the task termination command represents the first termination command, the first termination command is randomly sent to k target tasks; after the k target tasks are all successfully terminated, a first target response corresponding to the target task is obtained; and a first test result is determined based on a first number and a first response time of the first target responses, where k represents a positive integer less than or equal to n.

[0026] In the case where the task termination command represents the second termination command, the second termination command is randomly sent to k target tasks; the second target response corresponding to the target task is obtained; the command execution time of the second termination command is obtained, and the task data corresponding to the target task is obtained; the second test result is determined according to the second quantity and second response time corresponding to the second target response, the command execution time and the task data; the first test result and the second test result both represent the target test result, and the first target response and the second target response are received by the created receiving sub-thread.

[0027] In some optional embodiments, determining a first test result according to a first number and a first response time of the first target response includes:

[0028] When the first number is not equal to nk, configuring the first test result as stability abnormal;

[0029] When the first number is equal to nk, if the first response time is greater than the preset response time, the first test result is configured as abnormal stability; if the first response time is less than or equal to the preset response time, the first test result is configured as normal stability.

[0030] In some optional embodiments, determining the second test result according to the second quantity and second response time corresponding to the second target response, the command execution time, and the task data includes:

[0031] If the second number is not equal to n, configuring the second test result as stability abnormal;

[0032] When the second number is equal to n, comparing the second response time with a preset response time to obtain a first comparison result;

[0033] If the first comparison result indicates that the second response time is greater than a preset response time, configuring the second test result as stability abnormality;

[0034] If the first comparison result indicates that the second response time is less than or equal to the preset response time, comparing the command execution time with the preset execution time to obtain a second comparison result;

[0035] If the second comparison result indicates that the command execution time is greater than the preset execution time, configuring the second test result as stability abnormality;

[0036] If the second comparison result indicates that the command execution time is less than or equal to the preset execution time, comparing the task data with the backup data to obtain a third comparison result, where the backup data indicates data of the target task before the second termination command is executed;

[0037] If the three comparison results indicate that the task data is not equal to the backup data, configuring the second test result as stability abnormality;

[0038] When the three comparison results indicate that the task data is equal to the backup data, the second test result is configured as normal stability.

[0039] In a second aspect, an embodiment of the present invention provides a stability testing system for a UFS device, including:

[0040] A first module is configured to divide a storage unit of the UFS device into m storage partitions and obtain n target tasks, where m and n are both positive integers greater than or equal to 1;

[0041] The second module is used to randomly allocate the n target tasks to the m storage partitions;

[0042] A third module is used to randomly obtain n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of the preset command types;

[0043] a fourth module, configured to asynchronously send n target operation commands to the m storage partitions, wherein the target operation commands correspond to the target tasks one-to-one, and the UFS device asynchronously performs the target operation on the target tasks according to the target operation commands;

[0044] A fifth module is configured to randomly send a task termination command to one or more of the target tasks, so that a termination test is performed on the target task after the task is terminated to obtain a target test result. The task termination command includes a first termination command and a second termination command. The first termination command is used to terminate the target task that is being executed or not executed, and the second termination command is used to terminate the target task that has been completed.

[0045] The sixth module is used to generate a stability test report based on the target test results.

[0046] In a third aspect, an embodiment of the present invention provides a stability testing device for a UFS device, which is applied to a smart card. The device includes:

[0047] at least one processor;

[0048] at least one memory for storing at least one program;

[0049] When the at least one program is executed by the at least one processor, the at least one processor implements the method described above.

[0050] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing a program executable by a processor, wherein the program executable by the processor is used to perform the method described above when executed by the processor.

[0051] Implementation of the embodiments of the present invention includes the following beneficial effects: The embodiments of the present invention provide a stability testing method for a UFS device, comprising: dividing a storage unit of the UFS device into m storage partitions, and obtaining n target tasks, where m and n both represent positive integers greater than or equal to 1; randomly allocating the n target tasks to the m storage partitions; randomly obtaining n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of preset command types; asynchronously sending the n target operation commands to the m storage partitions, where the target operation commands correspond one-to-one to the target tasks, and the UFS device asynchronously performs a target operation on the target tasks according to the target operation commands; randomly sending a task termination command to one or more target tasks, so that a termination test is performed after the target task is terminated to obtain a target test result, where the task termination command includes a first termination command and a second termination command, the first termination command is used to terminate the target task that is being executed or not executed, and the second termination command is used to terminate the target task that has been completed; and generating a stability test report based on the target test result. By randomly assigning n target tasks to corresponding storage partitions, the stability test is improved to be more comprehensive, tailored to actual applications. The target operation command is randomly selected to execute the target task operation, ensuring comprehensive testing of the operation relative to the target task. Task termination commands are randomly sent to one or more of the target tasks, ensuring comprehensive testing and thus improving test accuracy. Therefore, this application can accurately test the stability of UFS devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 This is a structural block diagram of a test system provided by an embodiment of the present invention;

[0053] Figure 2 1 is a schematic flow chart of the steps of a stability testing method for a UFS device provided by an embodiment of the present invention;

[0054] Figure 3 This is a structural block diagram of a stability testing system for a UFS device provided by an embodiment of the present invention;

[0055] Figure 4 This is a structural block diagram of a stability testing device for a UFS device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0057] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and the like in the specification, claims, or accompanying drawings are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0058] An embodiment of the present invention provides a stability testing method for a UFS device, comprising: dividing a storage unit of the UFS device into at least one storage partition, and establishing a first mapping table corresponding to the storage partition; updating mapping data of the first mapping table in real time according to an operation command of the storage partition; storing the mapping data of the first mapping table to the storage device when the UFS device is powered off; and copying the mapping data stored in the storage device to a second mapping table when the UFS device is powered on again, wherein the second mapping table indicates a re-established mapping table corresponding to the storage partition. When the UFS device is powered off, the original data is saved to the storage device by the first mapping table, and when the UFS device is powered on again, the original data stored in the storage device is copied to the re-established second mapping table, thereby restoring the original data; therefore, the present application can save the original data when the UFS device is powered off and restore it after powering on, thereby improving the testing efficiency of the UFS device.

[0059] In one embodiment, if Figure 1As shown, the test system of the present application includes a UFS test board and a UFS device and a storage device respectively connected to the UFS test board for communication. The UFS device is provided with a storage unit, and the storage unit is divided into m storage partitions. The UFS test board randomly assigns n target tasks to the m storage partitions and randomly assigns k target operation commands to the target tasks. Figure 1 The target tasks assigned to different storage partitions are only examples; there are no specific restrictions on the target tasks for each storage partition. The UFS test board includes a first algorithm module, a second algorithm module, and a third algorithm module. The first algorithm module implements the following: based on n target tasks and m storage partitions, it labels each storage partition and uses a random function to randomly select a storage partition from the m storage partitions to store the target task, and so on until the total number of tasks for all storage partitions reaches n. The second algorithm module uses an array to pre-store command types and uses a random function (provided in the C language library) to randomly select the target operation command for the target task from multiple command types. The third algorithm module is used to process test results and generate stability test reports. UFS devices are tested using the UFS test board. The UFS test board is connected to a host computer via a USB cable, allowing the test case executable program to be burned from the host computer into the UFS test board to facilitate the execution of the test cases and complete stability testing, UFS protocol testing, and gray-box testing of the UFS device. The power supply module provides 5V to the UFS test board to enable startup. The actual UFS test board is also equipped with a serial port board to provide serial port printing. Specifically, the host computer is a PC device. The UFS test board can be an electronic device or electronic device equipped with the test board; this application does not impose specific restrictions on the model of the test board.

[0060] Those skilled in the art will understand that the system structure shown in the figure does not constitute a limitation on the embodiments of the present application, and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0061] The system embodiment described above is merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0062] Those skilled in the art will understand that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will know that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0063] Based on the above system structure, various embodiments of the UFS private partition management verification method of the present application are proposed below.

[0064] The embodiments of the present invention are further described below with reference to the accompanying drawings.

[0065] like Figure 2 As shown, the embodiment of the present invention provides a stability test method for a UFS device, which is applied to Figure 1 In the UFS test board shown, the steps included are as follows.

[0066] S100: Divide the storage unit of the UFS device into m storage partitions, and obtain n target tasks, where m and n both represent positive integers greater than or equal to 1.

[0067] Specifically, the UFS host test board is used to partition the available storage space of the UFS device into m storage partitions. There are n target tasks configured, and one storage partition can correspond to one or more target tasks. This means that one or more target tasks can be sent to a storage partition. Different target tasks can be the same or different, and the specific target task type is not limited.

[0068] In some optional embodiments, dividing the storage unit of the UFS device into m storage partitions includes:

[0069] S110, obtaining configuration parameters, where the configuration parameters represent partition data of the Android system;

[0070] S120, determining a partitioning scheme of the storage unit according to the configuration parameters;

[0071] S130. Divide the storage unit into m storage partitions according to the partitioning scheme, where the storage partitions have corresponding capacity sizes, data storage types, and access permissions.

[0072] Specifically, the UFS test board first obtains configuration parameters representing the Android system partition data. Based on these configuration parameters, it obtains the actual partition properties of the Android device, such as the Android system's boot, system, and data partitions. It also obtains the capacity of each partition based on the configuration parameters (e.g., 1GB for the system partition and 6GB for the data partition). It also obtains the data storage type of each partition based on the configuration parameters. Furthermore, it obtains the access permission identifiers for each partition based on the configuration parameters (e.g., setting the system partition to "read-only" and the data partition to "read-write" to match the Android system's partition permission control). Configuration parameters can be input through the UFS test board's parameter transfer interface or loaded from a preset Android partition template.

[0073] Based on the obtained configuration parameters, a specific partitioning scheme is generated for the UFS device's storage units. This scheme incorporates the UFS device's hardware characteristics (such as total capacity, available capacity, physical block size, and bad block distribution) to transform abstract Android partition parameters into executable physical partitioning logic: The scheme calculates the start and end addresses of each partition (ensuring that partitions do not overlap and the total capacity does not exceed the total capacity of the UFS device's storage units); matches the UFS device's block alignment requirements (e.g., partitioning by 4KB or 8KB physical block boundaries to avoid performance losses caused by cross-block storage); and associates partition attributes with the UFS device's functional support (e.g., mapping "read-only" permissions to the UFS device's hardware-level write protection mechanism).

[0074] According to the defined partitioning scheme, storage units are divided using UFS protocol commands (such as UFS partition management commands), ultimately forming m storage partitions. Each partition has characteristics corresponding to the configured parameters: the capacity strictly matches the Android system's requirements for that type of partition; the data storage type is adapted to Android application scenarios; and access rights are controlled through the UFS device's controller-level permissions.

[0075] S200: Randomly distribute the n target tasks to the m storage partitions.

[0076] Specifically, unique identifiers are set for m storage partitions (numbered from 0 to m-1), and a task counter is initialized for each partition (initial value 0) to record the number of tasks ultimately assigned to each partition. For each of the n target tasks, a random number is generated using the random function in the C language standard library. Each time, a partition number is randomly selected from the range 0 to m-1. If the random number points to a storage partition numbered i, the task counter for that storage partition is incremented by 1. This process is repeated until all n tasks are assigned, at which point the total task counter for each partition is n.

[0077] Due to the random selection mechanism, the number of tasks assigned to each partition may vary (for example, some partitions may receive three tasks, others may receive two). However, the overall probability distribution is followed, ensuring unbiased scheduling of tasks across m partitions. This simulates the real-world scenario of concurrent task processing across multiple partitions in the Android system, providing a diverse load environment for subsequent command type assignment and execution verification, thereby improving the comprehensiveness and accuracy of stability testing.

[0078] In some optional embodiments, randomly allocating the n target tasks to the m storage partitions includes:

[0079] S210, marking the m storage partitions in sequence to obtain m partition labels;

[0080] S220, randomly matching the n target tasks with the m partition labels in sequence, so that the n target tasks correspond to different partition labels;

[0081] S230: Asynchronously sending the n target tasks to the corresponding storage partitions.

[0082] Specifically, m storage partitions are sequentially numbered from 0 to m-1, giving each a unique numerical identifier (i.e., a partition label). These labels serve as the partition's "address" and are used for subsequent task assignment and data transfer. For each of the n target tasks, a random number between 0 and m-1 is generated, corresponding to a partition label. In this way, each target task is randomly assigned to a storage partition. For example, if the random number generated for the third task is 1, it is assigned to the partition labeled 1. This assignment process is repeated n times until all target tasks have received their corresponding partition labels. Random assignment may result in some storage partitions being assigned multiple tasks, while others may have no tasks. Therefore, if the number of tasks in a storage partition exceeds a preset multiple (e.g., 2) of the average number of tasks, the remaining target tasks in that partition are reassigned to other storage partitions. This prevents a single storage partition from being overloaded with target tasks, which could slow down the target tasks and affect subsequent testing.

[0083] Send n tasks in parallel to their corresponding storage partitions based on the results of random matching. "Asynchronous" sending means that the sending operation can proceed without waiting for the previous target task to complete. Each target task is processed independently on the storage partition side. For example, if target task 5 is assigned to storage partition 2 and target task 6 is assigned to storage partition 3, both target tasks will be sent to storage partitions 2 and 3 simultaneously, thereby improving overall testing efficiency.

[0084] S300: Randomly obtain n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of preset command types.

[0085] Specifically, each target task in each storage partition is assigned a target operation command type, based on the UFS protocol (including read, write, and erase commands). The target operation command types are pre-stored in an array. The UFS protocol has a total of L target operation command types. A random function (provided by the C language library) is used to randomly select from these L command types. The selected command type is determined by the array subscript, and the selected command type is matched with the corresponding target task, causing the target task to execute the target operation command of that command type.

[0086] In some optional embodiments, the randomly acquiring n target operation commands corresponding to the n target tasks includes:

[0087] Execute for each of the n target tasks:

[0088] S310, randomly selecting the target operation command stored in the array;

[0089] S320: Map the array index corresponding to the target operation command to the target task, so that the target task corresponds to the target operation command.

[0090] Specifically, all SCSI command types (a total of L types, such as read, write, erase, etc.) supported by the UFS protocol are stored in a static array in advance, and each command type corresponds to a unique array index (0 to L-1).

[0091] For each of the n target tasks, perform the following assignment: Use the random function in the C language standard library to generate a random integer between 0 and L-1 as the array index. Map the command type corresponding to the generated random index to the current target task. For example, if the random index is 2, the command stored in the array with index 2 is ERASE. Associate the ERASE command with the currently processed target task 6. Repeat these steps for all n target tasks, ultimately forming a task-command mapping table.

[0092] S400: asynchronously sending n target operation commands to m storage partitions, wherein the target operation commands correspond to the target tasks one by one, and the UFS device asynchronously performs target operations on the target tasks according to the target operation commands.

[0093] Specifically, the main thread asynchronously sends the assigned target operation command to the storage partition where the corresponding target task is located. For example, if target operation command 1 corresponds to target task 3, and target task 3 is assigned to storage partition 5, and target operation command 2 corresponds to target task 5, and target task 5 is assigned to storage partition 7, then the main thread will simultaneously send target operation command 1 to storage partition 5 and target operation command 2 to storage partition 7, and so on.

[0094] S500. Randomly send a task termination command to one or more of the target tasks so that a termination test is performed after the target task is terminated to obtain a target test result. The task termination command includes a first termination command and a second termination command. The first termination command is used to terminate the target task that is being executed or not executed, and the second termination command is used to terminate the target task that has been completed.

[0095] Specifically, the first terminate command of this application is used to terminate a target task that is in execution or unexecuted. When this command is sent to the corresponding target task, it immediately interrupts the execution process of the target task (if the task is currently executing) or prevents its start (if the task has not yet executed). The second terminate command is only used to terminate a target task that has completed execution. This command is mainly used to detect boundary values ​​and to detect whether other abnormal situations occur when the UFS device sends a terminate command when there is no target task.

[0096] Randomly select one or more target tasks from all target tasks and send corresponding termination commands according to the test requirements: if the selected task is an executing or unexecuted task, the first termination command is sent; if the selected task is a completed task, the second termination command is sent.

[0097] In some cases, tasks are batch-selected by partition, for example, all tasks within a partition are selected and a kill command is sent simultaneously. Ensure that the command type matches the task status (the first kill command is used for executing / unexecuted tasks, and the second kill command is used for completed tasks).

[0098] If the first termination command is sent, verify whether the number of responses received by the child thread is n-1 (n is the total number of tasks) to confirm that the terminated task does not generate an abnormal response;

[0099] If a second termination command is sent, the system verifies that the number of responses is still n, since the termination of a completed task should not affect the total number of responses.

[0100] If the first termination command is sent to p tasks in a storage partition, verify whether the number of replies is ≥ np (allowing some tasks to be completed before the command arrives). If the second termination command is sent, verify whether the number of replies is ≥ n to ensure that the termination operation of the completed task does not interfere with other tasks.

[0101] Timeout detection: After all termination commands are sent, monitor whether the response is returned within the preset time. If the timeout exceeds, it is determined that the UFS device processing is abnormal.

[0102] By simulating task interruptions in real scenarios (such as system crashes and user-initiated terminations), the stability and data integrity of UFS devices under abnormal conditions are verified.

[0103] In some optional embodiments, randomly sending a task termination command to one or more target tasks so as to perform a termination test after the target tasks are terminated to obtain a target test result includes:

[0104] S510: If the task termination command represents the first termination command, randomly send the first termination command to k target tasks; after the k target tasks are all successfully terminated, obtain first target responses corresponding to the target tasks; determine a first test result based on a first number and a first response time of the first target responses, where k represents a positive integer less than or equal to n;

[0105] S520. When the task termination command represents the second termination command, randomly send the second termination command to k target tasks; obtain the second target response corresponding to the target task; obtain the command execution time of the second termination command, and obtain the task data corresponding to the target task; determine the second test result according to the second number and second response time corresponding to the second target response, the command execution time and the task data; both the first test result and the second test result represent the target test result, and the first target response and the second target response are received by the created receiving sub-thread.

[0106] Specifically, if k target tasks are terminated before or during execution, k target tasks are randomly selected (k ≤ n) and the first termination command (used to terminate tasks in progress or not) is sent to them. For example, if the total number of tasks n = 10, k = 3 tasks (such as tasks 2, 5, and 7) are randomly selected and the termination command is sent to them.

[0107] The receiving subthread collects responses from all tasks to form the first target response set. Under normal circumstances, after successfully terminating k tasks, the number of responses should be nk (for example, if 3 out of 10 tasks are terminated, 7 responses should be received). Therefore, by checking whether the actual number of responses received is equal to nk, the test is considered a failure if the first number of the first target responses is not equal to nk. The reception time of each response is calculated. If a timeout occurs (exceeding a preset threshold), the corresponding task is marked as abnormal. Combining quantity and time metrics, the system's ability to terminate executing / unexecuted tasks is evaluated.

[0108] Second termination command test process (terminating completed tasks): Similarly, randomly select k target tasks, ensure that these tasks have completed execution, and then send the second termination command (used to terminate completed tasks). Example: Select completed tasks 1, 4, and 9 to send the termination command. Second target response: Collect responses to the termination command through the receiving child thread. In theory, all k tasks should return a successful response. Command execution time: Record the time from sending the second termination command to receiving the response to evaluate the system's efficiency in clearing completed tasks. Task data: Extract metadata of the terminated tasks (such as execution status and return code) to verify data integrity.

[0109] Second quantity verification: Check whether the number of responses is equal to k. If not, it indicates that there are tasks that have not correctly responded to the termination command.

[0110] Second response time analysis: Detect whether there is a timeout response. If so, it indicates that there may be a bottleneck in the system cleaning mechanism.

[0111] Execution time evaluation: Analyze the distribution of the command execution time to judge the performance stability of the system in handling termination operations.

[0112] Task data verification: Compare the task data before and after termination to ensure that the termination operation does not cause data corruption or abnormal status.

[0113] In some optional embodiments, determining the first test result according to the first quantity and the first response time of the first target response includes:

[0114] S511. When the first quantity is not equal to n - k, configure the first test result as abnormal stability;

[0115] S512. When the first quantity is equal to n - k, if the first response time is greater than the preset response time, configure the first test result as abnormal stability; if the first response time is less than or equal to the preset response time, configure the first test result as normal stability.

[0116] Specifically, compare the actually received number of first target responses (denoted as A) with the theoretical expected value (n - k), where n is the total number of tasks and k is the number of terminated tasks. If A ≠ n - k (such as A > n - k or A < n - k), directly determine that the stability is abnormal.

[0117] When and only when A = n - k, further verify the reception time of each response. If the reception time of any response exceeds the preset threshold (such as 100 ms), determine that the stability is abnormal. If all response times are ≤ the preset threshold, determine that the stability is normal. A timeout response indicates that the UFS device is less efficient than expected in handling the termination command, and there may be a task scheduling bottleneck or insufficient hardware performance, resulting in insufficient stability.

[0118] In some optional embodiments, determining the second test result according to the second quantity, the second response time, the command execution time, and the task data corresponding to the second target response includes:

[0119] S521. When the second quantity is not equal to n, configure the second test result as abnormal stability;

[0120] S522. When the second quantity is equal to n, compare the second response time with the preset response time to obtain a first comparison result;

[0121] S523: If the first comparison result indicates that the second response time is greater than a preset response time, configure the second test result as abnormal stability;

[0122] S524: If the first comparison result indicates that the second response time is less than or equal to the preset response time, compare the command execution time with the preset execution time to obtain a second comparison result;

[0123] S525: If the second comparison result indicates that the command execution time is greater than the preset execution time, configure the second test result as stability abnormality;

[0124] S526. If the second comparison result indicates that the command execution time is less than or equal to the preset execution time, compare the task data with the backup data to obtain a third comparison result, where the backup data indicates data before the target task executes the second termination command.

[0125] S527: If the three comparison results indicate that the task data is not equal to the backup data, configure the second test result as stability abnormality;

[0126] S528: If the three comparison results indicate that the task data is equal to the backup data, configure the second test result as normal stability.

[0127] Specifically, when verifying the detection result of the second termination command, a multi-level verification is performed, including:

[0128] First-level verification: Compare the actual number of second target responses received with the total number of tasks n. If the second number ≠ n (for example, there are 10 tasks but 9 or 11 responses are received), the second test result is directly judged as a stability anomaly, indicating that some tasks did not correctly respond to the termination command or there were redundant responses.

[0129] Second-level verification: When the second number = n, the second response time is compared with the preset response time. If the second response time is greater than the preset response time (for example, the preset threshold is 50ms and the actual response time is 60ms), it is determined to be a stability anomaly and the response efficiency of the termination command processing is not up to standard.

[0130] Level 3 Verification: If the second response time is less than or equal to the preset response time, the actual execution time of the second terminate command is compared with the preset execution time. If the command execution time is greater than the preset execution time (for example, the preset execution threshold is 30ms, and the actual execution time is 40ms), a stability anomaly is detected, indicating that the command execution efficiency itself does not meet the requirements.

[0131] Level 4 Verification: If the command execution time is ≤ the preset execution time, the current data of the terminated task is compared with the backup data (task data before the termination command was sent, stored on the UFS test board, occupying 4KB of space; the space size here is for example only). If the task data ≠ the backup data (e.g., data missing, tampered with, or damaged), a stability abnormality is determined, indicating that the termination operation has affected the data integrity of the completed task. If the task data equals the backup data, the second test result is considered normal stability, indicating that all verification indicators meet the requirements.

[0132] Through multi-dimensional verification, the UFS device's ability to terminate completed target tasks was fully verified, and the data integrity and execution efficiency of the UFS device were comprehensively tested, thereby improving the accuracy of stability testing.

[0133] S600: Generate a stability test report according to the target test result.

[0134] Specifically, the stability test report integrates the first test result (the test conclusion for the first abort command) and the second test result (the test conclusion for the second abort command). For example, if the first test result is "Stability Anomaly (Response Count Disparity)" and the second test result is "Stability Anomaly (Command Execution Timeout)", the specific scenarios and triggering conditions for each type of anomaly must be documented in the report. The stability test report details the key parameters at the time of the anomaly, including: the total number of tasks n, the number of aborted tasks k, the actual number of responses (first number / second number), the exceeded response time or command execution time (specific values ​​and preset thresholds), and the differences between task data and backup data. For test items without anomalies, the verified parameters (e.g., "First response time ≤ 80ms" and "Task data and backup data are completely consistent") must also be recorded to demonstrate the completeness of the test. The stability test report provides a preliminary analysis of the cause of the anomaly and produces the corresponding analysis results. The stability test report ultimately provides a comprehensive stability assessment conclusion, clarifying whether the UFS device meets stability requirements under the current test scenario. If any anomalies are found, improvement suggestions are provided (such as optimizing the termination command transmission mechanism or adjusting the device task scheduling algorithm). If all test items pass, the device's stability in the task termination scenario is confirmed to meet the requirements. The report can also include raw data from the test process (such as response time logs and task data verification records) to support the conclusions and facilitate traceability and review.

[0135] Implementation of the embodiments of the present invention includes the following beneficial effects: The embodiments of the present invention provide a stability testing method for a UFS device, comprising: dividing a storage unit of the UFS device into m storage partitions, and obtaining n target tasks, where m and n both represent positive integers greater than or equal to 1; randomly allocating the n target tasks to the m storage partitions; randomly obtaining n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of preset command types; asynchronously sending the n target operation commands to the m storage partitions, where the target operation commands correspond one-to-one to the target tasks, and the UFS device asynchronously performs a target operation on the target tasks according to the target operation commands; randomly sending a task termination command to one or more target tasks, so that a termination test is performed after the target task is terminated to obtain a target test result, where the task termination command includes a first termination command and a second termination command, the first termination command is used to terminate the target task that is being executed or not executed, and the second termination command is used to terminate the target task that has been completed; and generating a stability test report based on the target test result. By randomly assigning n target tasks to corresponding storage partitions, the stability test is improved to be more comprehensive, tailored to actual applications. The target operation command is randomly selected to execute the target task operation, ensuring comprehensive testing of the operation relative to the target task. Task termination commands are randomly sent to one or more of the target tasks, ensuring comprehensive testing and thus improving test accuracy. Therefore, this application can accurately test the stability of UFS devices.

[0136] Secondly, refer to Figure 3 , an embodiment of the present invention provides a stability testing system for a UFS device, comprising:

[0137] A first module is configured to divide a storage unit of the UFS device into m storage partitions and obtain n target tasks, where m and n are both positive integers greater than or equal to 1;

[0138] The second module is used to randomly allocate the n target tasks to the m storage partitions;

[0139] A third module is used to randomly obtain n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of the preset command types;

[0140] a fourth module, configured to asynchronously send n target operation commands to the m storage partitions, wherein the target operation commands correspond to the target tasks one-to-one, and the UFS device asynchronously performs the target operation on the target tasks according to the target operation commands;

[0141] A fifth module is configured to randomly send a task termination command to one or more of the target tasks, so that a termination test is performed on the target task after the task is terminated to obtain a target test result. The task termination command includes a first termination command and a second termination command. The first termination command is used to terminate the target task that is being executed or not executed, and the second termination command is used to terminate the target task that has been completed.

[0142] The sixth module is used to generate a stability test report based on the target test results.

[0143] It can be seen that the contents of the above method embodiments are all applicable to the present system embodiments. The functions specifically implemented by the present system embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0144] Thirdly, refer to Figure 4 , an embodiment of the present invention provides a stability testing device for a UFS device, comprising:

[0145] at least one processor;

[0146] at least one memory for storing at least one program;

[0147] When at least one program is executed by at least one processor, the at least one processor implements the above method.

[0148] It can be seen that the contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0149] In a fourth aspect, in addition, an embodiment of the present application further discloses a computer program product or a computer program, which is stored in a computer-storable medium. The processor of a computer device can read the computer program from a computer-readable storage medium, and the processor executes the computer program so that the computer device performs the above-mentioned method or the above-mentioned system. Similarly, the contents of the above-mentioned method embodiment are all applicable to the present storage medium embodiment, and the functions specifically implemented by the present storage medium embodiment are the same as those of the above-mentioned method embodiment, and the beneficial effects achieved are also the same as those achieved by the above-mentioned method embodiment.

[0150] It is understood that all or some steps, systems in the disclosed method above can be implemented as software, firmware, hardware and appropriate combinations thereof. Some physical components or all physical components can be implemented as a processor, such as the software executed by a central processing unit, a digital information processor or a microprocessor, or are implemented as hardware, or are implemented as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those of ordinary skill in the art, the term computer storage medium is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data) and is volatile and non-volatile, removable and non-removable. Computer storage media includes but is not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, disk storage or other magnetic storage device, or can be used to store desired information and any other medium that can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in modulated data information such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0151] The embodiments of the present invention are described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Various changes can be made within the scope of knowledge possessed by ordinary technicians in the technical field without departing from the spirit of the present invention.

Claims

1. A stability testing method for a UFS device, characterized in that: Applied to a UFS test board, the UFS test board is communicatively connected to a UFS device, the UFS device is provided with a storage unit, and the stability testing method of the UFS device includes: Divide the storage unit of the UFS device into m storage partitions, and obtain n target tasks, where m and n both represent positive integers greater than or equal to 1; Randomly assigning the n target tasks to the m storage partitions; Randomly acquiring n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of the preset command types; asynchronously sending n target operation commands to m storage partitions, where the target operation commands correspond to the target tasks one by one, and the UFS device asynchronously performs target operations on the target tasks according to the target operation commands; Randomly sending a task termination command to one or more of the target tasks, so that a termination test is performed after the target task is terminated to obtain a target test result, the task termination command including a first termination command and a second termination command, the first termination command being used to terminate the target task being executed or not being executed, and the second termination command being used to terminate the target task that has been completed; Generate a stability test report based on the target test results.

2. The method according to claim 1, characterized in that The dividing the storage unit of the UFS device into m storage partitions includes: Obtaining configuration parameters, where the configuration parameters represent partition data of the Android system; determining a partitioning scheme of the storage unit according to the configuration parameters; The storage unit is divided into m storage partitions according to the partitioning scheme, and the storage partitions have corresponding capacity sizes, data storage types and access permissions.

3. The method according to claim 1, characterized in that Randomly allocating the n target tasks to the m storage partitions includes: Marking the m storage partitions in sequence to obtain m partition labels; Randomly matching the n target tasks with the m partition labels in sequence, so that the n target tasks correspond to different partition labels; Asynchronously sending the n target tasks to the corresponding storage partitions.

4. The method according to claim 1, wherein The randomly acquiring n target operation commands corresponding to the n target tasks includes: Execute for each of the n target tasks: Randomly selecting the target operation command stored in the array; The array subscript corresponding to the target operation command is mapped to the target task, so that the target task corresponds to the target operation command.

5. The method according to claim 1, wherein The step of randomly sending a task termination command to one or more target tasks so as to perform a termination test after the target tasks are terminated to obtain a target test result includes: In a case where the task termination command represents the first termination command, the first termination command is randomly sent to k target tasks; after the k target tasks are all successfully terminated, a first target response corresponding to the target task is obtained; and a first test result is determined based on a first number and a first response time of the first target responses, where k represents a positive integer less than or equal to n. In the case where the task termination command represents the second termination command, the second termination command is randomly sent to k target tasks; the second target response corresponding to the target task is obtained; the command execution time of the second termination command is obtained, and the task data corresponding to the target task is obtained; the second test result is determined according to the second quantity and second response time corresponding to the second target response, the command execution time and the task data; the first test result and the second test result both represent the target test result, and the first target response and the second target response are received by the created receiving sub-thread.

6. The method according to claim 5, characterized in that Determining a first test result according to a first number and a first response time of the first target response includes: When the first number is not equal to nk, configuring the first test result as stability abnormal; When the first number is equal to nk, if the first response time is greater than the preset response time, the first test result is configured as abnormal stability; if the first response time is less than or equal to the preset response time, the first test result is configured as normal stability.

7. The method according to claim 5, characterized in that Determining a second test result according to a second quantity and a second response time corresponding to the second target response, the command execution time, and the task data includes: If the second number is not equal to n, configuring the second test result as stability abnormal; When the second number is equal to n, comparing the second response time with a preset response time to obtain a first comparison result; If the first comparison result indicates that the second response time is greater than a preset response time, configuring the second test result as stability abnormality; If the first comparison result indicates that the second response time is less than or equal to the preset response time, comparing the command execution time with the preset execution time to obtain a second comparison result; If the second comparison result indicates that the command execution time is greater than the preset execution time, configuring the second test result as stability abnormality; If the second comparison result indicates that the command execution time is less than or equal to the preset execution time, comparing the task data with the backup data to obtain a third comparison result, where the backup data indicates data of the target task before the second termination command is executed; If the three comparison results indicate that the task data is not equal to the backup data, configuring the second test result as stability abnormality; When the three comparison results indicate that the task data is equal to the backup data, the second test result is configured as normal stability.

8. A stability testing system for a UFS device, characterized in that: include: A first module is configured to divide a storage unit of the UFS device into m storage partitions and obtain n target tasks, where m and n are both positive integers greater than or equal to 1; The second module is used to randomly allocate the n target tasks to the m storage partitions; A third module is used to randomly obtain n target operation commands corresponding to the n target tasks, where the type of the target operation command is any one of the preset command types; a fourth module, configured to asynchronously send n target operation commands to the m storage partitions, wherein the target operation commands correspond to the target tasks one-to-one, and the UFS device asynchronously performs the target operation on the target tasks according to the target operation commands; A fifth module is configured to randomly send a task termination command to one or more of the target tasks, so that a termination test is performed on the target task after the task is terminated to obtain a target test result. The task termination command includes a first termination command and a second termination command. The first termination command is used to terminate the target task that is being executed or not executed, and the second termination command is used to terminate the target task that has been completed. The sixth module is used to generate a stability test report based on the target test results.

9. A stability testing device for a UFS device, characterized in that: include: at least one processor; at least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that: The processor-executable program is configured to perform the method according to any one of claims 1 to 7 when executed by the processor.

Images