A cross-platform dynamically adjustable SSD automated production testing method and system

Abstract

The application discloses a kind of cross-platform dynamically adjustable SSD automated production test method and system, belong to SSD production test field.Method includes: user is configured test procedure by interface;Test end detects disc information and uploads;Control end issues test instruction;Test end executes test and feedback result.The core is, control end is based on the antecedent test result data of feedback, through data analysis and preset adjustment rule decision, dynamically adjust the parameter or order of subsequent test.The system includes user interface, control end and test end, control end is equipped with dynamic process adjustment module to realize the above-mentioned intelligent adjustment function, and is equipped with cross-platform communication module to be compatible with different operating systems and test equipment.The application realizes the one-stop automation and intelligentization of SSD production test, significantly improves test efficiency, precision and system reliability.

Description

Technical Field

[0001] This invention relates to the field of SSD production testing, and in particular to a cross-platform, dynamically adjustable automated SSD production testing method and system. Background Technology

[0002] Solid State Drives (SSDs) are the mainstream storage devices in current computer systems, and their production testing is a crucial step in ensuring the quality of products leaving the factory. A typical SSD production testing process involves multiple stages, including card opening (such as OC2, OC4), functional testing, performance testing, and reliability testing, requiring the execution of numerous and complex test items.

[0003] Currently, the commonly used testing methods in the SSD production testing field have the following significant drawbacks, which seriously restrict further improvements in production efficiency and product quality: First, the automation level is low, and the process relies heavily on manual labor. Most existing testing processes depend on testers manually executing each test step on a single testing device. For example, when conducting production testing on large batches of SATA or PCIe interface SSDs, testers need to manually configure test parameters for each SSD, generate test procedure sheets, and move equipment and switch test tools between different testing sites. This model is not only cumbersome and time-consuming, leading to low testing efficiency, but it is also highly susceptible to human error in data input and device configuration, affecting the accuracy of test results and potentially causing defective products to enter the market, posing quality risks.

[0004] Second, testing tools are fragmented and lack collaboration and integration. Existing technical solutions typically consist of multiple testing tools with independent or even partially overlapping functions. These tools lack coordination and cannot achieve the sharing and linkage of test data, test scripts, and test status. Operators need to frequently switch between different tool interfaces, increasing operational complexity and learning costs. At the same time, functional overlap leads to a waste of R&D, computing, and storage resources. In addition, production data is scattered across various independent tools, making centralized management and in-depth analysis difficult, and hindering the effective use of data to optimize testing processes and predict potential problems.

[0005] Third, the testing process is rigid and lacks intelligent adjustment capabilities. Existing automated or semi-automated testing solutions typically have pre-set and fixed testing processes. During testing, even if previous test results show some abnormal signs (such as a slight deviation in a performance parameter), the system cannot dynamically adjust the intensity, order, or parameters of subsequent tests based on real-time data. This "one-size-fits-all" testing model lacks specificity, which may lead to unnecessary over-testing of normal products, wasting resources, or insufficient detection of potentially problematic products, missing defects and making it difficult to achieve the optimal balance between testing accuracy and efficiency.

[0006] Fourth, the system has poor compatibility, making cross-platform deployment difficult. Production testing environments often include different operating system platforms (such as Windows and Linux) and different brands of test hardware. Existing testing solutions are usually customized for specific platforms or devices, lacking a unified communication interface and adaptation layer. This makes it difficult to quickly deploy and expand the testing system across different platforms and devices, increasing the complexity and cost of setting up and maintaining the testing environment.

[0007] In summary, existing SSD production testing methods have significant shortcomings in terms of automation level, tool integration, process intelligence, and system compatibility, leading to problems such as low testing efficiency, resource waste, inaccurate quality risk control, and difficulties in deployment and maintenance. Therefore, there is an urgent need in this field for an automated SSD production testing solution that can achieve tool integration, process automation, and dynamic intelligent adjustment of testing strategies based on real-time test data, while also possessing good cross-platform compatibility. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a cross-platform, dynamically adjustable automated production testing method and system for SSDs.

[0009] The objective of this invention is achieved through the following technical solution: The first aspect of this invention provides: a cross-platform dynamically adjustable automated SSD production testing method, used in a cross-platform dynamically adjustable automated SSD production testing system, comprising the following steps: S1. Users select SSD materials through the user interface, configure and generate test processes and test items corresponding to the selected SSD materials, and then start the test through the control terminal start interface. S2. After the disk to be tested is inserted into the test terminal, the disk status information of the disk to be tested is detected by the driver and uploaded to the control terminal. S3. The control terminal receives and displays the disk status information. After manual confirmation, it uploads and selects the test script package, and then sends the test script package and test instructions to the test terminal. S4. After receiving the test script package and test instructions, the test terminal decompresses and executes the test task, saves the test log, and sends the test results back to the control terminal. S5. During the execution of the test task, the control terminal dynamically adjusts the subsequent test process based on the previous test results data fed back by the test terminal; specifically including: S51. Data Analysis: Standardize, detect outliers, perform correlation analysis, and trend analysis on the collected preliminary test results data; S52. Adjustment Decision: Based on the analysis results of S51, determine whether to adjust the test parameters and / or test order of subsequent tests according to at least one of the adjustment rules based on the degree of deviation of indicators, the adjustment rules based on outliers, and the adjustment rules based on correlation analysis. S53. If adjustments are required, generate adjustment instructions and a new test script package, and send them to the test end. Then, the test end continues to execute the test according to the adjusted process.

[0010] Preferably, S51, data analysis, includes the following steps: Data standardization: Collect all data values ​​for each test metric in the current batch of tests and apply a linear normalization formula. The data values ​​for each test metric are standardized, whereby... x norm These are the standardized data values. x The original data values, min and max These are the minimum and maximum values ​​of the target test metric in the current batch of test data, respectively. Outlier detection: Sort the standardized data values ​​in ascending order and identify outliers in the standardized data based on the interquartile range method; Correlation analysis: By calculating the Pearson correlation coefficient r, the degree of linear correlation between different test indicators is analyzed; Trend Analysis: The simple moving average method is used to analyze the changing trend of test indicators over time or in the order of testing.

[0011] Preferably, the test metrics include sequential read / write speed, random read / write IOPS, and response time.

[0012] Preferably, the adjustment rule based on the degree of deviation of the indicator is as follows: If the standardized data value of a certain test indicator x norm If the deviation from its standard value is within ±10%, it is considered a slight deviation, and the number of tests for that indicator will be increased. If the deviation is within 10%-30%, it is judged as a moderate deviation, and the number of tests for this test indicator is increased and the test parameters are adjusted. If the deviation exceeds 30%, it is judged as a severe deviation. The current test process is paused and the tested SSD is subjected to hardware detection and firmware version confirmation. At the same time, the subsequent test order is adjusted, and in-depth tests related to the test indicators of severe deviation are given priority.

[0013] Preferably, the adjustment rule based on outliers is as follows: If the proportion of outliers to total data is less than the first preset threshold, the outliers and the test conditions related to them are recorded. The outliers are analyzed separately to determine whether they are caused by accidental factors in the test environment. Monitoring of the test environment is then added in subsequent tests. If the number of outliers accounts for a proportion of the total data volume greater than or equal to the second preset threshold, the current test will be stopped immediately and a comprehensive check will be performed on the test system, including checking the hardware status and software configuration of the test equipment. At the same time, preventive testing will be performed on other SSDs in the same batch.

[0014] Preferably, the preventative testing includes a data integrity test and a hardware health check.

[0015] Preferably, the adjustment rule based on correlation analysis is as follows: If the Pearson correlation coefficient between two test indicators is 0.8≤|r|≤1, it is determined to be a strong correlation. When one of the indicators is abnormal, the test parameters and / or test order of the other indicator are adjusted. If |r|<0.5, it is determined to be a weak correlation. When adjusting test parameters and / or test order, the deviation and outlier of each test indicator should be the primary basis, and correlation factors should be a secondary reference for adjusting the decision-making strategy.

[0016] Preferably, when the test terminal is performing a test, if the abnormal self-recovery module detects an abnormality in the control terminal or the network, it triggers the locally cached test process to complete the test independently and temporarily stores the test results locally, and then sends the test results back after the control terminal or the network returns to normal.

[0017] Preferably, the control terminal and the test terminal communicate across operating system platforms and different brands of test equipment through a unified interface protocol and adapter driver.

[0018] The second aspect of the present invention provides: a cross-platform dynamically adjustable SSD automated production testing system for implementing any of the above-mentioned cross-platform dynamically adjustable SSD automated production testing methods, including a user interface, wherein the user interface is connected to a control terminal, and the control terminal is connected to a testing terminal; The user interface includes a material selection module, a test process / test item generation module, and a control terminal startup interface, which are used to receive user configuration and trigger tests. The control terminal includes: The disk information receiving / display module is used to receive and display disk status information uploaded by the test terminal; The script management / command distribution module is used to manage test script packages and distribute test scripts and commands to the test client. A cross-platform communication module is used to enable communication with test terminals on different platforms and devices; The dynamic process adjustment module is used to analyze the test result data fed back from the test end and generate test process adjustment instructions based on preset rules. The automatic error handling module is used to automatically generate an error log address when receiving error information from the test end, and submit the error log address to the issue tracking database for issue tracing and management. The testing terminal includes: The disk detection module is used to detect the disk status information of the inserted disk and upload it to the control terminal; The script decompression / execution module is used to receive and execute test scripts and instructions sent from the control terminal; The log storage module is used to save test logs; The result feedback module is used to send the test results back to the control terminal; The local process caching module is used to cache the complete test process and test script locally after the test script and test process are issued from the control terminal. The anomaly self-recovery module is used to trigger the locally cached test process to independently complete the test when an anomaly is detected in the control terminal or network, and temporarily store the test results until the control terminal or network returns to normal.

[0019] The beneficial effects of this invention are: 1) Significantly Improved Production Efficiency and Automation: This invention achieves end-to-end automation from material configuration and test execution to result feedback by constructing a collaborative automation architecture of "user interface - control terminal - test terminal". Compared to the traditional mode that relies on single-machine manual operation, this system automatically completes test script distribution, execution, log recording, and result feedback, freeing testers from tedious and repetitive manual operations, avoiding human error, and resulting in a qualitative leap in testing speed. Test time can be reduced to a fraction or even a tenth of the original time, greatly improving the SSD test throughput per unit time and effectively meeting the needs of large-scale production testing.

[0020] 2) Comprehensive Improvement in Testing Quality and Accuracy: First, through one-stop integration, multiple previously scattered and overlapping testing tools are integrated into a cohesive whole, enabling multi-dimensional and systematic collaborative testing of SSDs, thus improving the comprehensiveness of test coverage. More importantly, the core innovation of this invention—the "dynamic process adjustment mechanism"—transforms the testing process from "fixed and rigid" to "flexible and intelligent" through real-time data analysis and intelligent decision-making. The system can dynamically adjust the intensity, parameters, or sequence of subsequent tests based on the results of preceding tests (such as performance index deviations or the appearance of outliers). For example, it can increase the number of tests for platters with slight performance deviations and immediately switch to in-depth testing for platters with serious anomalies. This data-driven adaptive testing strategy enhances the ability to detect and intercept potential defects, thereby improving the overall quality of the product before it leaves the factory.

[0021] 3) Optimized resource utilization and cost control: On the one hand, the system achieves "normalization" of testing tools, solving the problems of redundant functions and high maintenance costs of multiple independent tools, thus saving R&D resources and software licensing fees. On the other hand, through a cross-platform communication module (with a unified interface protocol and adapter driver), the system is compatible with different operating systems such as Windows and Linux, as well as different brands of testing hardware, achieving "cross-platform integration." This allows enterprises to make full use of existing, heterogeneous testing equipment environments without the need for large-scale hardware replacements to deploy new systems, significantly reducing the investment cost of new production testing environments and achieving full utilization of resources.

[0022] 4) Guaranteed System Reliability and Testing Continuity: This invention incorporates a local process caching module and an anomaly self-recovery module at the testing end. When the testing end detects a network interruption with the control end or an anomaly in the control end itself, it can immediately trigger the locally cached process to independently complete all tests and temporarily store the results. Once communication is restored, the results are automatically transmitted back. This mechanism achieves "decoupling" between the control end and the testing end, ensuring that the entire production testing process is not interrupted in the event of a partial failure, greatly improving the robustness and reliability of the system under large-scale, long-term operation scenarios.

[0023] 5) Enhanced Operational Standardization and Problem Traceability: Through standardized user interfaces, control panel processes, and testing panel processes, this invention standardizes testing operations. Different operators follow the same configuration and execution steps, ensuring consistency in the testing process and comparability of test results, which is beneficial for standardized production quality management. Simultaneously, the automatic error handling module can automatically capture errors during testing and generate log records with addresses, submitting them to the problem tracking database. This provides complete data chain support for quickly locating, tracing, and reproducing problems encountered in production testing, improving the efficiency and accuracy of production quality management. Attached Figure Description

[0024] Figure 1 This is a flowchart of the method of the present invention; Figure 2 The flowchart is dynamically adjusted to adapt to the testing process; Figure 3 This is a system architecture diagram of the present invention. Detailed Implementation

[0025] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] See Figures 1-3 The first aspect of this invention provides: a cross-platform dynamically adjustable automated SSD production testing method, used in a cross-platform dynamically adjustable automated SSD production testing system, comprising the following steps: S1. Users select SSD materials through the user interface, configure and generate test processes and test items corresponding to the selected SSD materials, and then start the test through the control terminal start interface. S2. After the disk to be tested is inserted into the test terminal, the disk status information of the disk to be tested is detected by the driver and uploaded to the control terminal. S3. The control terminal receives and displays the disk status information. After manual confirmation, it uploads and selects the test script package, and then sends the test script package and test instructions to the test terminal. S4. After receiving the test script package and test instructions, the test terminal decompresses and executes the test task, saves the test log, and sends the test results back to the control terminal. S5. During the execution of the test task, the control terminal dynamically adjusts the subsequent test process based on the previous test results data fed back by the test terminal; specifically including: S51. Data Analysis: Standardize, detect outliers, perform correlation analysis, and trend analysis on the collected preliminary test results data; S52. Adjustment Decision: Based on the analysis results of S51, determine whether to adjust the test parameters and / or test order of subsequent tests according to at least one of the adjustment rules based on the degree of deviation of indicators, the adjustment rules based on outliers, and the adjustment rules based on correlation analysis. S53. If adjustments are required, generate adjustment instructions and a new test script package, and send them to the test end. Then, the test end continues to execute the test according to the adjusted process.

[0027] In this embodiment, the overall process is as follows: Figure 1 As shown, it includes the following steps: 1) First, the user selects the SSD material and generates the corresponding test process in the operation interface, and then starts the test through the control terminal start interface.

[0028] 2) After inserting the disk into the test terminal, the self-developed driver is used to detect the disk status and upload it to the control terminal.

[0029] 3) The control terminal receives the disk information. After the operator manually confirms that the disk is ready, they upload and select the appropriate test script package, and then send instructions to the test terminal.

[0030] 4) After receiving the script package and instructions, the test end decompresses the script and executes the test, while saving the test log.

[0031] 5) After the test is completed, the test terminal sends the results back to the control terminal. After receiving the results, the control terminal displays the results and sets the color of the disk test board light according to the results.

[0032] 6) Simultaneously, the dynamic process adjustment module analyzes the test results to determine whether subsequent test processes need adjustment. If adjustment is required, the script package is reselected and the adjusted instructions are sent to the test server, which continues to execute the test according to the new instructions; if no adjustment is required, the test continues according to the normal process.

[0033] 7) During test execution, the test server will continuously monitor the control server or network for any anomalies. If an anomaly is detected, the test server will cache the test results locally and send them back to the control server once the control server or network returns to normal. If no anomaly is detected, the test results will be sent back directly.

[0034] The dynamic adjustment process of the testing process is as follows: Figure 2 As shown, it includes the following steps: 1) After the test results are returned from the test end, the dynamic process adjustment module of the control end begins to collect these result data.

[0035] 2) This module uses a preset algorithm to perform in-depth analysis of the collected data, such as comparing the differences between various test indicators and standard values, and analyzing the fluctuations in test results.

[0036] 3) Based on the analysis results and the preset rules, determine whether the subsequent testing process needs to be adjusted.

[0037] 4) If adjustments are needed, the dynamic process adjustment module generates corresponding adjustment instructions and sends them to the script management / instruction distribution module. This module then distributes the adjusted script package and instructions to the testing end to change the parameters or order of subsequent tests.

[0038] 5) If it is determined that no process adjustment is needed, continue with the subsequent operations according to the normal process.

[0039] In some embodiments, S51, data analysis includes the following steps: Data standardization: Collect all data values ​​for each test metric in the current batch of tests and apply a linear normalization formula. The data values ​​for each test metric are standardized, whereby... x norm These are the standardized data values. x The original data values, min and max These are the minimum and maximum values ​​of the target test metric in the current batch of test data, respectively. Outlier detection: Sort the standardized data values ​​in ascending order and identify outliers in the standardized data based on the interquartile range method; Correlation analysis: By calculating the Pearson correlation coefficient r, the degree of linear correlation between different test indicators is analyzed; Trend Analysis: The simple moving average method is used to analyze the changing trend of test indicators over time or in the order of testing.

[0040] In this embodiment, 1. Data standardization algorithm: Purpose: To make test index data with different units and value ranges comparable. Steps: For each test index (such as sequential read / write speed v, random read / write IOPS, response time (t), etc.), collect all data values ​​of that index in the current batch of tests; Calculate the minimum value (min) and maximum value (max) of this indicator data; Each data value x is standardized using a linear normalization formula, as follows: This maps the data to the [0, 1] interval. For example, for sequential read / write speeds, if the minimum value in the current batch is 100MB / s and the maximum value is 500MB / s, and a certain test data is 200MB / s, then the standardized value is... .

[0041] 2. Outlier Detection Algorithm (based on IQR method): Objective: To identify potential outliers in the dataset and prevent them from misleading the overall analysis. Steps: Sort the standardized data in ascending order; Calculate the first quartile, Q1, which is the 25th percentile of the data. For example, for a dataset with n data points, if n × 0.25 is an integer k, then... If n × 0.25 is not an integer, round it up to k. .

[0042] The third quartile, Q3, which is the 75th percentile of the data, is calculated in a similar way to Q1.

[0043] Calculate the interquartile range IQR = Q3 - Q1.

[0044] Define the outlier range as follows: the lower limit is Q1 - 1.5 IQR, and the upper limit is Q3 + 1.5 × IQR. Data values ​​below the lower limit or above the upper limit are considered outliers.

[0045] 3. Correlation Analysis Algorithm (Pearson Correlation Coefficient): Purpose: To measure the degree of linear correlation between different test indicators. Steps: Assume there are two test indicators X and Y, each with n data points. and .

[0046] Calculate the mean of X and the mean of Y .

[0047] The Pearson correlation coefficient r is calculated using the following formula: The value of r ranges from -1 to 1. The closer |r| is to 1, the stronger the linear correlation between the two indicators; the closer |r| is to 0, the weaker the correlation. For example, if r = 0.8, it indicates a strong positive linear correlation between X and Y.

[0048] 4. Trend Analysis Algorithm (Simple Moving Average Method): Purpose: To analyze the changing trend of a test indicator over time or in test order, and to predict potential future changes. Steps: For a time series or test indicator data arranged in test order... .

[0049] Set the moving average window size k (e.g., k = 3).

[0050] Calculate the moving average: Starting from the k-th data point, the i-th moving average is: For example, when k = 3 and i = 3, By observing the changing trend of the moving average, we can determine the direction of the indicator's change, such as rising, falling, or remaining stable.

[0051] In some embodiments, the test metrics include sequential read / write speed, random read / write IOPS, and response time.

[0052] In some embodiments, the adjustment rule based on the degree of indicator deviation is as follows: If the standardized data value of a certain test indicator x normIf the deviation from its standard value is within ±10%, it is considered a slight deviation, and the number of tests for that indicator will be increased. If the deviation is within 10%-30%, it is judged as a moderate deviation, and the number of tests for this test indicator is increased and the test parameters are adjusted. If the deviation exceeds 30%, it is judged as a severe deviation. The current test process is paused and the tested SSD is subjected to hardware detection and firmware version confirmation. At the same time, the subsequent test order is adjusted, and in-depth tests related to the test indicators of severe deviation are given priority.

[0053] In this embodiment, the rule is based on the degree of deviation of the indicator: Slight deviation (standardized data deviates from the standard value within ±10%): If a certain test index x norm The value deviates from its standard value x std-norm A deviation within ±10% is considered slight. For example, if the standard value is 0.5, and the current value is between 0.45 and 0.55, the decision is to increase the number of tests for this indicator, for example, from 5 to 7. After retesting, calculate the new mean and standard deviation, and compare them with the previous results. If the deviation is still slight, consider fine-tuning the test parameters. For example, for read / write speed tests, adjust the data block size by 10% and test again.

[0054] Moderate deviation (standardized data deviating from the standard value within [10%, 30%]): When x norm Deviation x std-norm A deviation within the range of (10%, 30%) is considered moderate. Decision: Not only increase the number of tests (e.g., from 5 to 10), but also significantly adjust the test parameters. For example, for sequential read / write speed tests, adjust the queue depth from 1 to 4 and the data block size from 4KB to 8KB. After retesting, based on the new test results, if the deviation decreases, continue subsequent tests with the new parameters; if the deviation remains significant, consider checking and adjusting the test environment, such as checking hardware connections and updating drivers.

[0055] Severe deviation (standardized data deviates from the standard value by more than 30%): If x norm Deviation x std-normA deviation exceeding 30% is considered a severe deviation. Decision: Immediately pause the current testing process and conduct a comprehensive inspection of the SSD, including hardware testing (such as using professional tools to check for faults in the flash memory chip, controller chip, etc.) and firmware version confirmation (checking if the current firmware is up-to-date and matches the test requirements). Simultaneously, adjust the subsequent testing order, prioritizing in-depth tests closely related to this metric. For example, for severe read / write speed deviations, conduct low-level performance tests on the flash memory chip, including read / write latency and bandwidth tests, to determine the root cause of the problem.

[0056] In some embodiments, the adjustment rule based on outliers is: If the proportion of outliers to total data is less than the first preset threshold, the outliers and the test conditions related to them are recorded. The outliers are analyzed separately to determine whether they are caused by accidental factors in the test environment. Monitoring of the test environment is then added in subsequent tests. If the number of outliers accounts for a proportion of the total data volume greater than or equal to the second preset threshold, the current test will be stopped immediately and a comprehensive check will be performed on the test system, including checking the hardware status and software configuration of the test equipment. At the same time, preventive testing will be performed on other SSDs in the same batch.

[0057] In this embodiment, the first preset threshold and the second preset threshold can be set to the same value or different values. Rules based on outliers: A small number of outliers (outliers accounting for less than 5% of the total data): If the number of outliers in the dataset accounts for less than 5% of the total data. Decision: Record the outliers and their related test conditions, analyze the outliers individually, and determine whether they are caused by accidental factors in the test environment. Simultaneously, in subsequent tests, increase monitoring of the test environment, such as monitoring changes in environmental parameters like temperature and humidity. If a small number of outliers still appear in subsequent tests, consider calibrating the test equipment or replacing some test components.

[0058] Numerous outliers (outliers accounting for 5% or more of the total data): When the number of outliers accounts for 5% or more of the total data. Decision: Immediately stop the current test and conduct a comprehensive inspection of the test system, including the hardware status and software configuration of the test equipment. Simultaneously, conduct preventative outlier detection tests on other SSDs in the same batch, such as adding data integrity tests and hardware health checks, to avoid similar issues appearing in other samples.

[0059] In some embodiments, the preventative testing includes a data integrity test and a hardware health check.

[0060] In some embodiments, the adjustment rule based on correlation analysis is: If the Pearson correlation coefficient between two test indicators is 0.8≤|r|≤1, it is determined to be a strong correlation. When one of the indicators is abnormal, the test parameters and / or test order of the other indicator are adjusted. If |r|<0.5, it is determined to be a weak correlation. When adjusting test parameters and / or test order, the deviation and outlier of each test indicator should be the primary basis, and correlation factors should be a secondary reference for adjusting the decision-making strategy.

[0061] In this embodiment, the rules are based on correlation analysis: Strong positive correlation (0.8 ≤ r ≤ 1): If the Pearson correlation coefficient r of two test indicators X and Y satisfies 0.8 ≤ r ≤ 1, it indicates that there is a strong positive correlation between them. Decision: If one indicator (such as X) shows an anomaly (deviates from the standard value or shows an outlier), the test parameters and order of the other indicator (Y) should be adjusted. For example, if X is read / write speed and Y is flash memory chip temperature, and the read / write speed is abnormal, the flash memory chip temperature test should be scheduled in advance, and the temperature test parameters should be adjusted, such as setting different temperature gradients for testing, and observing the impact on read / write speed.

[0062] Strong negative correlation (-1≤r≤-0.8): When r satisfies -1≤r≤-0.8, it indicates a strong negative correlation between the two metrics. Decision: If one metric shows an anomaly, adjust the testing of the other metric accordingly. For example, if X is response time and Y is cache hit rate, and response time shows an abnormal increase, adjust the order of cache hit rate tests, prioritizing this test, and change the test conditions, such as increasing or decreasing cache capacity, observing the changes in response time to further analyze the relationship between the two.

[0063] Weak correlation (|r|<0.5): If |r|<0.5, it indicates a weak correlation between the two indicators. Decision-making: When adjusting test parameters and order, decisions are primarily based on the deviation and outlier occurrences of each indicator, with correlation factors serving as a secondary reference. However, it is still necessary to continuously monitor the relationships between indicators, and adjust the decision-making strategy promptly if changes in correlation are observed in subsequent tests.

[0064] In some embodiments, when the test terminal is performing a test, if the anomaly self-recovery module detects an anomaly in the control terminal or network, it triggers the locally cached test process to complete the test independently and temporarily stores the test results locally, and then sends the test results back after the control terminal or network returns to normal.

[0065] In some embodiments, the control terminal and the test terminal communicate across operating system platforms and test equipment of different brands through a unified interface protocol and adapter driver.

[0066] The second aspect of the present invention provides: a cross-platform dynamically adjustable SSD automated production testing system for implementing any of the above-mentioned cross-platform dynamically adjustable SSD automated production testing methods, including a user interface, wherein the user interface is connected to a control terminal, and the control terminal is connected to a testing terminal; The user interface includes a material selection module, a test process / test item generation module, and a control terminal startup interface, which are used to receive user configuration and trigger tests. The control terminal includes: The disk information receiving / display module is used to receive and display disk status information uploaded by the test terminal; The script management / command distribution module is used to manage test script packages and distribute test scripts and commands to the test client. A cross-platform communication module is used to enable communication with test terminals on different platforms and devices; The dynamic process adjustment module is used to analyze the test result data fed back from the test end and generate test process adjustment instructions based on preset rules. The automatic error handling module is used to automatically generate an error log address when receiving error information from the test end, and submit the error log address to the issue tracking database for issue tracing and management. The testing terminal includes: The disk detection module is used to detect the disk status information of the inserted disk and upload it to the control terminal; The script decompression / execution module is used to receive and execute test scripts and instructions sent from the control terminal; The log storage module is used to save test logs; The result feedback module is used to send the test results back to the control terminal; The local process caching module is used to cache the complete test process and test script locally after the test script and test process are issued from the control terminal. The anomaly self-recovery module is used to trigger the locally cached test process to independently complete the test when an anomaly is detected in the control terminal or network, and temporarily store the test results until the control terminal or network returns to normal.

[0067] In this embodiment, as Figure 3 As shown, the user interface includes: 1) Material selection module: Allows users to select materials based on SSD model, capacity, interface type, etc.

[0068] 2) Test Process / Test Item Generation Module: Users can freely generate test processes and test items for SSD production testing OC2-OC4 applicable to SATA PCIe, such as selecting processes like OC2 card opening, FT test, clearing (PEC / SMART / DATA), OC4 card opening, etc., and set specific test items for each process, such as read / write speed, stability test, etc.

[0069] 3) Control terminal startup interface: After completing the configuration, the user can start the automated test of the control terminal through this interface.

[0070] The control terminal includes: 1) Disk Information Receiving / Display Module: Receives disk status information uploaded by the test terminal and displays it intuitively through the interface using colors and icons to assist manual confirmation of whether the disk is ready.

[0071] 2) Script Management / Command Issuance Module: Supports users to upload test script packages and manage script packages. After selecting the script package required for this test, the module issues the script package and test start command to the test terminal.

[0072] 3) Cross-platform communication module: By designing a unified interface protocol and developing compatible drivers, communication can be achieved across mainstream operating system platforms such as Windows and Linux, as well as testing equipment from different brands, ensuring system compatibility.

[0073] 4) Dynamic process adjustment module: a) Data collection: Collect the preceding test results data from the test terminal in real time, including the values ​​of various test indicators, whether the test passed or failed, error types, etc.

[0074] b) Data analysis: Use preset algorithms to perform in-depth analysis of the collected data, such as comparing read and write speeds with standard values ​​to determine the degree of deviation, and analyzing the fluctuations in stability tests.

[0075] c) Adjustment Decisions: Based on the analysis results and preset logical rules, decide whether to adjust subsequent test parameters and order. For example, if the write speed is slightly low, the durability test duration can be increased; if errors occur, the test order can be adjusted to prioritize problem localization.

[0076] d) Instruction generation: Based on the adjustment decision, an adjustment instruction is generated and sent to the script management / instruction distribution module, which then distributes the adjusted test script package and instructions to the test terminal.

[0077] 5) Automatic error handling module: During the testing process, if error information is received from the testing end, the module automatically generates a relevant log address and submits the log address to the issue tracking database for easy issue tracing and management.

[0078] 3. Testing End 1) Disk detection module: After a disk is inserted, the driver quickly detects the disk status, obtains information such as disk model, capacity, and interface type, and sends it to the control terminal.

[0079] 2) Script decompression / execution module: Upon receiving the test script package and start command from the control terminal, the module decompresses the script package and executes various test tasks according to the fio and configuration information within the script package. If a dynamically adjusted script package and command are received, the tests are executed according to the new configuration.

[0080] 3) Log storage module: During test execution, detailed log information of the test process is saved in real time, including test steps, results, error messages, etc., for subsequent analysis.

[0081] 4) Result Feedback Module: After the test is completed, the test results will be fed back to the control terminal.

[0082] 5) Local process caching module: After the test script and process are issued from the control terminal, the complete test process and script package are automatically cached to local storage.

[0083] 6) Anomaly self-recovery module: When an anomaly is detected in the control terminal or network, the locally cached test process is triggered, and all test steps are completed independently according to the preset script. After the test is completed, the results are temporarily stored locally and sent back after the control terminal or network is restored, ensuring that the test is not interrupted.

[0084] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A cross-platform, dynamically adjustable automated production testing method for SSDs, characterized in that: A cross-platform, dynamically scalable automated production testing system for SSDs includes the following steps: S1. Users select SSD materials through the user interface, configure and generate test processes and test items corresponding to the selected SSD materials, and then start the test through the control terminal start interface. S2. After the disk to be tested is inserted into the test terminal, the disk status information of the disk to be tested is detected by the driver and uploaded to the control terminal. S3. The control terminal receives and displays the disk status information. After manual confirmation, it uploads and selects the test script package, and then sends the test script package and test instructions to the test terminal. S4. After receiving the test script package and test instructions, the test terminal decompresses and executes the test task, saves the test log, and sends the test results back to the control terminal. S5. During the execution of the test task, the control terminal dynamically adjusts the subsequent test process based on the previous test results data fed back by the test terminal; specifically including: S51. Data Analysis: Standardize, detect outliers, perform correlation analysis, and trend analysis on the collected preliminary test results data; The S51 data analysis includes the following steps: Data standardization: Collect all data values ​​for each test metric in the current batch of tests and apply a linear normalization formula. The data values ​​for each test metric are standardized, whereby... x norm These are the standardized data values. x The original data values, min and max These are the minimum and maximum values ​​of the target test metric in the current batch of test data, respectively. Outlier detection: Sort the standardized data values ​​in ascending order and identify outliers in the standardized data based on the interquartile range method; Correlation analysis: By calculating the Pearson correlation coefficient r, the degree of linear correlation between different test indicators is analyzed; Trend Analysis: The simple moving average method is used to analyze the changing trend of test indicators over time or in the order of testing; S52. Adjustment Decision: Based on the analysis results of S51, determine whether to adjust the test parameters and / or test order of subsequent tests according to at least one of the adjustment rules based on the degree of deviation of indicators, the adjustment rules based on outliers, and the adjustment rules based on correlation analysis. S53. If adjustments are required, generate adjustment instructions and a new test script package, and send them to the test end. Then, the test end continues to execute the test according to the adjusted process. The adjustment rule based on outliers is as follows: If the proportion of outliers to total data is less than the first preset threshold, the outliers and the test conditions related to them are recorded. The outliers are analyzed separately to determine whether they are caused by accidental factors in the test environment. Monitoring of the test environment is then added in subsequent tests. If the number of outliers accounts for a proportion of the total data volume greater than or equal to the second preset threshold, the current test will be stopped immediately and a comprehensive check will be performed on the test system, including checking the hardware status and software configuration of the test equipment. At the same time, preventive testing will be performed on other SSDs in the same batch. When the test terminal is executing a test, if the abnormal self-recovery module detects an abnormality in the control terminal or network, it will trigger the locally cached test process to complete the test independently and temporarily store the test results locally. The test results will be sent back after the control terminal or network returns to normal. The adjustment rule based on the degree of deviation of the indicator is as follows: If the standardized data value of a certain test indicator x norm If the deviation from its standard value is within ±10%, it is considered a slight deviation, and the number of tests for that indicator will be increased. If the deviation is within 10%-30%, it is judged as a moderate deviation, and the number of tests for this test indicator is increased and the test parameters are adjusted. If the deviation exceeds 30%, it is judged as a severe deviation. The current test process is paused and the SSD under test is subjected to hardware detection and firmware version confirmation. At the same time, the subsequent test order is adjusted, and in-depth tests related to the test indicators of severe deviation are given priority. The adjustment rule based on correlation analysis is as follows: If the Pearson correlation coefficient between two test indicators is 0.8≤|r|≤1, it is determined to be a strong correlation. When one of the indicators is abnormal, the test parameters and / or test order of the other indicator are adjusted. If |r|<0.5, it is determined to be a weak correlation. When adjusting test parameters and / or test order, the deviation and outlier of each test indicator should be the primary basis, and correlation factors should be a secondary reference for adjusting the decision-making strategy.

2. The cross-platform, dynamically adjustable automated SSD production testing method according to claim 1, characterized in that: The test metrics include sequential read / write speed, random read / write IOPS, and response time.

3. The cross-platform, dynamically adjustable automated SSD production testing method according to claim 1, characterized in that: The preventative testing includes data integrity testing and hardware health checks.

4. The cross-platform, dynamically adjustable automated production testing method for SSDs according to claim 1, characterized in that: The control terminal and the testing terminal communicate across operating system platforms and testing equipment from different brands through a unified interface protocol and adapter driver.

5. A cross-platform, dynamically adjustable automated SSD production testing system, characterized in that: A method for implementing a cross-platform, dynamically adjustable automated SSD production testing method as described in any one of claims 1-4 includes a user interface connected to a control terminal, and the control terminal connected to a testing terminal. The user interface includes a material selection module, a test process / test item generation module, and a control terminal startup interface, which are used to receive user configuration and trigger tests. The control terminal includes: The disk information receiving / display module is used to receive and display disk status information uploaded by the test terminal; The script management / command distribution module is used to manage test script packages and distribute test scripts and commands to the test client. A cross-platform communication module is used to enable communication with test terminals on different platforms and devices; The dynamic process adjustment module is used to analyze the test result data fed back from the test end and generate test process adjustment instructions based on preset rules. The automatic error handling module is used to automatically generate an error log address when receiving error information from the test end, and submit the error log address to the issue tracking database for issue tracing and management. The testing terminal includes: The disk detection module is used to detect the disk status information of the inserted disk and upload it to the control terminal; The script decompression / execution module is used to receive and execute test scripts and instructions sent from the control terminal; The log storage module is used to save test logs; The result feedback module is used to send the test results back to the control terminal; The local process caching module is used to cache the complete test process and test script locally after the test script and test process are issued from the control terminal. The anomaly self-recovery module is used to trigger the locally cached test process to independently complete the test when an anomaly is detected in the control terminal or network, and temporarily store the test results until the control terminal or network returns to normal.

Images