A method for converting standard TESTSUITE names in batches of 93K

Abstract

The application discloses a method for batch conversion of standard TESTSUITE names of 93K, comprising the following steps: converting testflow in the default text format in V93000 system into the csv table format through the export operation; and storing the intercepted module content as testflow_tmp.csv separately, wherein the application realizes batch conversion of names through an automatic process, without manual line-by-line modification or complicated command writing; a multi-testflow parallel processing mechanism can dynamically allocate threads according to project priorities and server resources, avoids waiting time consumption of serial processing, and reduces manual intervention in the whole process operation of a single project; on the other hand, a rule self-iteration function can automatically adapt to the new customer Pattern format, without repeated manual configuration of specifications.

Description

Technical Field

[0001] This invention belongs to the field of ATE testing technology, and in particular relates to a method for batch conversion of standard TESTSUITE names in 93K. Background Technology

[0002] In the field of ATE testing, the Advantest V93000 test system is a commonly used device for mass production testing of semiconductor chips. Its generated testflow files contain three core modules: Testsuites (stores basic test suite information), Parameters (stores test parameter configuration information), and Tests (stores specific test case information). During chip testing, Pattern conversion automatically generates Testsuite names. In practical applications, these names need to be standardized to the format "Project Code_Test Phase_Date" to meet management requirements. Currently, Testsuite name standardization is mainly achieved through Vim commands, manual line-by-line editing, or simple batch processing tools. This can complete basic name replacement, generate modification logs in some scenarios, and allow manual synchronization of the standardized names to external systems such as the MES system and test management platform, meeting the testing needs of single projects or simple scenarios.

[0003] Existing technologies have significant limitations in practical applications, making it difficult to meet the high-efficiency and accurate requirements of chip mass production testing. In terms of processing efficiency, current methods are mostly serial, requiring waiting for the previous project to complete when multiple projects are being processed simultaneously. Furthermore, Vim commands require repeated debugging for different pattern formats, resulting in significant time consumption. Regarding accuracy, manual verification is prone to missing related items between the Testsuites module and the Parameters and Tests modules, and lacks an anomaly detection mechanism, failing to promptly identify issues such as name length exceeding limits or multiple specification names corresponding to the same pattern. In terms of usability, modifying Vim commands requires operators to master regular expressions, necessitating extensive training for ordinary testers. Finally, in terms of scenario adaptability, new customer pattern format changes require manual reconfiguration of specifications, and cross-system synchronization relies on manual login to multiple platforms, lacking the ability to receive external system status indicators and automatically update, making it difficult to adapt to mass production scenarios involving multiple customers and multiple systems. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a method for batch conversion of standard TESTSUITE names in 93K, which solves the problems of low efficiency, poor accuracy, low usability, and weak adaptability of the existing Testsuite specification in the ATE testing field.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A method for batch conversion of standard testsuit names using 93K, applied to the Advantest V93000 test program in the ATE testing field, includes the following steps:

[0007] S1. Obtain testflow.csv: Convert the testflow in the default text format in the V93000 system to CSV table format using the export operation;

[0008] S2. Data Preprocessing: Identify and extract the Testsuites module content of the V93000 system from the testflow.csv file. The Testsuites module is a functional module in the V93000 system that stores basic information about test suites. Store the extracted Testsuites module content separately as testflow_tmp.csv.

[0009] S3. Search and naming: Locate the row and column information corresponding to Pattern and Testsuite Name in the testflow_tmp.csv, store the Pattern and Testsuite Name in the Pattern list and the original Testsuite list respectively by row, and then process the Testsuite Name in the original Testsuite list according to the preset specification to generate the standardized Testsuite list. The preset specification is the TestsuiteName naming rule set based on the ATE test process standardization requirements.

[0010] S4. Data Processing: Based on the original Testsuite list and the standardized Testsuite list, find and replace the content corresponding to the original Testsuite Name in the testflow.csv to obtain the standardized Testsuite name testflow_output.csv;

[0011] S5. Full-process traceability and fault tolerance: Verify the accuracy and trace the source of testflow_output.csv generated in step S4 to confirm that it meets the requirements of the ATE test process.

[0012] S6. Data Application: The testflow_output.csv file, which has been confirmed to be correct in step S5, is sent back to the V93000 test program. It is imported and stored as flw format through the import operation to obtain the optimized testflow.

[0013] S7. Cross-platform data synchronization: Synchronize the testflow_output.csv file, which has been confirmed to be correct in step S5, to external management systems such as MES systems and test management platforms to achieve data consistency across systems.

[0014] The execution order of the steps is as follows: first execute step S4, then execute step S5 and complete the accuracy verification of testflow_output.csv; after step S5 is completed, you can choose to execute step S6 first and then step S7, or execute step S6 and step S7 in parallel; that is, both step S6 and step S7 are based on the testflow_output.csv that has been verified to be correct in step S5.

[0015] Preferably, step S2, which involves identifying and extracting the Testsuites module content of the V93000 system from the testflow.csv file, specifically includes:

[0016] Iterate through each row of data in testflow.csv. When a row is detected that starts with the system identifier of the Testsuites module, record the starting index of that row. The system identifier of the Testsuites module is a unique marker used in the V93000 system to distinguish this module from other modules. Continue to iterate through subsequent rows until a row is detected that starts with the system identifier of another module but is not the identifier of the Testsuites module. Record the ending index of that row. Extract all rows of data between the starting index and the ending index as the content of the Testsuites module.

[0017] Preferably, step S3, which processes the Testsuite Names in the original Testsuite list according to a preset specification, specifically includes:

[0018] The preset specification configures the length or position of the string to be extracted for different pattern naming formats provided by different customers; according to the configuration, the target character fragment is extracted from the pattern name associated with the Testsuite Name, and the target character fragment is stored in the specified Testsuite list as the specified Testsuite Name.

[0019] Preferably, it also includes step S21, module association verification:

[0020] When parsing testflow.csv in step S2, the ParameterID (parameter identifier) ​​and TestCaseID (test case identifier) ​​corresponding to each TestsuiteName in the Testsuites module are recorded synchronously, and a module association mapping table containing TestsuiteName, ParameterID, TestCaseID and the test stage to which they belong is generated; the ParameterID corresponds to the Parameters module of the V93000 system, which is a functional module in the V93000 system that stores test parameter configuration information; the TestCaseID corresponds to the Tests module of the V93000 system, which is a functional module in the V93000 system that stores specific test case information;

[0021] After replacing the Testsuite Name in step S4, the Parameters and Tests modules in the testflow.csv are traversed, and the Testsuite Name corresponding to ParameterID and TestCaseID is verified to be consistent with the standard Testsuite list based on the module association mapping table. If they are inconsistent, the Testsuite Name in the Parameters and Tests modules is automatically corrected, or a highlighted prompt message is generated. The execution result of step S21 is used to assist in the accuracy verification of step S5.

[0022] Preferably, before processing the Testsuite Names in the original Testsuite list according to preset specifications in step S3, the method further includes:

[0023] Build a rule knowledge base: Store the original pattern format-preset specification mapping relationship that has been verified in historical projects. The mapping relationship includes the correspondence between the separator type, keyword position, fixed length field of the pattern name and the preset specification.

[0024] Intelligent parsing and matching: After importing a new customer's Pattern file, the system automatically scans the separator type, keyword position, and fixed-length field features of the Pattern name, matches these features with the mapping relationship in the rule knowledge base, and outputs recommended specifications.

[0025] Rule self-iteration: If the user adjusts the recommended specification, the original pattern format-adjusted specification mapping relationship is incorporated into the rule knowledge base; when the adjusted mapping relationship is verified to be valid in 3 or more projects, it is marked as a high-confidence mapping relationship.

[0026] Preferably, step S5, full-process traceability and fault tolerance, specifically includes:

[0027] S51. Generate replacement log: Record the original value, specification value, matching preset specification, processing time and operator corresponding to each Testsuite Name in the original Testsuite list, generate a structured log that supports export in Excel or HTML format, and highlight the record types that are automatically matched or manually adjusted in the log.

[0028] S52. Visual Comparison: A left-right split comparison interface is set up. The left side displays the Testsuite Name in the original testflow.csv, and the right side displays the specification Testsuite Name in testflow_output.csv. It supports filtering difference data by module type and error type. The module types include Testsuites, Parameters, and Tests modules. The error types are name length exceeding the limit or missing keywords. When clicking on the difference data, it jumps to the corresponding preset specification configuration page.

[0029] S53. Accuracy Confirmation: If any of the following situations are detected, subsequent steps S6 and S7 will be automatically interrupted and a prompt message will be output. Step S4 will be re-executed after the user corrects the error. If no abnormality is detected, it is confirmed that testflow_output.csv can be used for import in step S6 and synchronization in step S7:

[0030] The standardized Testsuite Name exceeds the 20-character limit specified by the V93000 system.

[0031] The same pattern name can correspond to multiple different specification testsuite names;

[0032] The standardized Testsuite Name is duplicated.

[0033] Preferably, step S7, cross-platform data synchronization, specifically includes:

[0034] S71. Build a cross-system interface adaptation layer: Connect to the MES system, test management platform and defect management system through API, configure Testsuite name synchronization rules, the synchronization rules include automatically pushing to the test process module of the MES system within 10 minutes after confirming the accuracy of testflow_output.csv in step S5, or after completing the import of V93000 system in step S6.

[0035] S72. Data consistency verification: After pushing the Testsuite name according to the synchronization rules, compare the consistency between the Testsuite name stored in each external system and testflow_output.csv; if there is a discrepancy, trigger the retry push mechanism or send an alarm email to the administrator.

[0036] S73. Reverse Synchronization: When the status identifier of the Testsuite in the MES system has been verified or is to be optimized, the status identifier is sent back to the V93000 test program through the cross-system interface adaptation layer, and the status identifier is added after the corresponding Testsuite Name.

[0037] Preferably, before obtaining testflow.csv in step S1, the process also includes step S0, parallel processing of multiple testflows and task scheduling:

[0038] S01. Set up a task scheduling center: Receive multiple testflow files to be processed uploaded by users in batches. The testflow files to be processed are text format testflows exported by the V93000 system. The files contain complete information of the Testsuites module, Parameters module, and Tests module.

[0039] S02, Task Queue Management: When users upload testflow files to be processed, they can manually mark each file as high, medium, or low priority; the system sorts multiple testflow files to be processed according to the rule of priority first, and then file size in ascending order under the same priority, generating a task queue and supporting manual adjustment of the order of files in the queue;

[0040] S03. Parallel Resource Allocation: Real-time collection of server CPU utilization and memory usage. When CPU utilization is below 80% and memory usage is below 75%, a new thread is started to retrieve testflow files to be processed from the task queue. The maximum number of threads is set to 3-5. Each thread executes steps S1-S7 independently or executes steps S1-S5 first and then executes steps S6 and S7 in parallel. The server resources occupied by step S6 (V93000 system import) and step S7 (external system synchronization) are independent of each other and do not affect the import efficiency of the V93000 system or the synchronization stability of the external system. The memory space occupied by each thread is also independent of each other.

[0041] S04. Real-time Progress Monitoring: A visual task dashboard is set up to display the status of each pending testflow file, categorized as pending, processing, completed, and failed. For files in processing, a progress bar indicates their current stage, with two annotation methods: The first is that the file first enters the preprocessing stage, then the naming stage, followed by the data replacement stage, then the source tracing and fault tolerance stage, then the data application stage, followed by the cross-system synchronization stage, and finally the import completion stage; the second is that the file first enters the preprocessing stage, then the naming stage, then the data replacement stage, then the source tracing and fault tolerance stage, then the data application and cross-system synchronization stages in parallel, and finally the import completion stage. When a file completes processing or fails, a system pop-up notification is triggered, and an email containing a download link for testflow_output.csv is sent to the user. If processing fails, the email also includes the reason for the failure: incorrect file format or insufficient server resources.

[0042] Through parallel processing and task scheduling in step S0, the efficiency of multi-testflow processing is improved by 3-5 times compared to serial processing, and server resource overload is avoided.

[0043] Preferably, in step S02, the user uploads multiple testflow files to be processed in batches, and the maximum upload limit per batch is configurable, with a default limit of 50 files.

[0044] Preferably, the maximum number of threads in step S03 can be adjusted according to the number of CPU cores on the server: when the server has an 8-core CPU, the maximum number of threads is set to 5, and 3 CPU cores are reserved for basic operations of the V93000 system.

[0045] The technical effects and advantages of the method for batch conversion of standard TESTSUITE names in 93K according to the present invention are as follows:

[0046] 1. This invention achieves batch conversion of Testsuite names through an automated process, eliminating the need for manual line-by-line modification or writing complex commands. On the one hand, the multi-testflow parallel processing mechanism can dynamically allocate threads according to project priority and server resources, avoiding the waiting time of serial processing and reducing manual intervention in the entire process of a single project. On the other hand, the rule self-iteration function can automatically adapt to the new customer pattern format, eliminating the need for repeated manual configuration of specifications, greatly shortening the adaptation time in new scenarios, and significantly improving the overall processing efficiency compared to traditional manual or command modification methods.

[0047] 2. This invention ensures data accuracy and reduces testing risks. Through the module association verification function, it can simultaneously verify the consistency of association between the Testsuites module, the Parameters module, and the Tests module, avoiding the omission of associated parameters or test case references when only the Testsuite name is modified, and preventing parameter call failures during subsequent V93000 system testing. At the same time, the full-process traceability and fault tolerance mechanism can detect anomalies such as excessive length of specification names, duplication, and multiple correspondences of the same Pattern in real time, automatically interrupting the error process and prompting corrections, preventing erroneous data from entering the testing stage from the source, minimizing the error rate, and ensuring the validity of test data and stable equipment operation.

[0048] 3. This invention lowers the operational threshold and improves usability. This method does not rely on professional tools and skills. It realizes task scheduling, progress monitoring and anomaly comparison through a visual interface. Ordinary testers can operate it after simple training. The task scheduling center supports batch file upload and priority visualization adjustment. The anomaly labeling and configuration jump function in the source tracing and fault tolerance link simplifies problem investigation. The automated push and verification of cross-platform synchronization reduces the repetitive operation of manually logging into multiple systems, significantly lowering the technical threshold and improving the universality and ease of use of the method.

[0049] 4. This invention enhances scenario adaptability and meets diverse needs. This method can cover multiple core scenarios in semiconductor chip mass production testing: it can achieve data collaboration with MES system, test management platform, and defect management system through cross-platform data synchronization, support reverse reception of external system status identifiers and automatic updates, and meet the needs of multi-system linkage; it can also adapt to the differences in pattern formats of multiple customers and the needs of batch processing of multiple projects through rule self-iteration and parallel processing, flexibly respond to the delivery rhythm of projects with different priorities, and provide efficient and stable technical support for industrial-grade mass production testing. Attached Figure Description

[0050] Figure 1 This is a flowchart of a method for batch conversion of standard TESTSUITE names using 93K data, as proposed in this invention. Detailed Implementation

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

[0052] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0053] refer to Figure 1 This invention provides a method for batch conversion of standard test suite names using the 93K testing system. Based on the Advantest V93000 testing system, it addresses the issue of non-standard Testsuite names generated by Pattern conversion in the ATE testing field by employing a batch conversion method to achieve standardization. All tests are based on semiconductor chip mass production projects. The testflow file contains three core modules of the V93000 system: the Testsuites module (stores basic test suite information), the Parameters module (stores test parameter configuration information), and the Tests module (stores specific test case information). The standardized Testsuite names must follow the format "Project Code_Test Phase_Date", for example, "MCU_01_S03_202407".

[0054] Example 1: This example provides a method for batch conversion of 93K standard testsuite names, used for end-to-end batch conversion. Specific implementation details include:

[0055] Scenario setting: Process an industrial-grade MCU chip project (project code MCU_01). The file to be processed is a text format testflow file exported from the V93000 system, with a file size of 3.1MB and 250 associated patterns. The pattern names are in the format of "PAT_20240720_M01" and "PAT_20240720_M03". All Testsuite names need to be standardized to "MCU_01_S03_202407".

[0056] Detailed operation steps:

[0057] To obtain testflow.csv: Log in to the V93000 system, open the text format testflow file of the project in the SmarTest software, and perform the operation of "File → Export → CSV format". Set the encoding to UTF-8 and the field separator to comma. The exported file is stored in the path "E:\V93000\TestData\MCU_01" and the file name is "testflow_MCU01.csv".

[0058] Data preprocessing: A data processing program was written using Python 3.10 to call the pandas data processing library to read the above CSV file and scan the content line by line: When a line starting with the default Testsuites module identifier of the V93000 system (line 18 of the file) was detected, the starting index 18 was recorded; the scan continued to the line starting with the Parameters module identifier (line 272 of the file), and the ending index 271 was recorded; the data of the rows with indices 18-271 (containing only the Testsuites module content) was extracted and saved separately as "testflow_tmp_MCU01.csv", with the storage path consistent with the original CSV file.

[0059] Search and Naming: In the preprocessed temporary CSV file, locate the 5th column storing Pattern names and the 7th column storing Testsuite names. Organize the 250 Pattern names into a Pattern list, and organize the original Testsuite names that match the Pattern names into an original Testsuite list. Process the original names according to the preset specifications: Extract the 4th to 9th characters from the Pattern name (e.g., extract "202407" from "PAT_20240720_M01"), concatenate the project code "MCU_01" and the test phase "S03", and generate a standardized Testsuite list (all elements are "MCU_01_S03_202407").

[0060] Data processing: Construct a dictionary mapping of "original Testsuite name - specification Testsuite name", scan the 7th column of the initial CSV file line by line, replace all original names with the corresponding specification names, and save it as "testflow_output_MCU01.csv".

[0061] End-to-end traceability and fault tolerance:

[0062] Generate replacement logs: Record the original value, standard value, matching preset standard, processing time (July 22, 2024, 14:35:22), operator (TEST_ENG02), and record type (automatic rule matching) of each data entry in Excel format. The logs are stored in the path "E:\V93000\Log\MCU01".

[0063] Visual comparison: Open the comparison interface developed based on PyQt6. The left side loads the Testsuite name of the initial CSV file, and the right side loads the processed specification name. Filter by "Module type = Testsuites". There is no difference among the 250 data entries.

[0064] Accuracy Confirmation: The test specification name length is 18 characters (the character limit for the V93000 system is 20 characters), there are no duplicates, and no multiple specification names corresponding to the same pattern; one associated parameter was found to be out of sync (to be corrected later), confirming that the file is accurate and can be used for subsequent steps.

[0065] Data Application: Upload the processed CSV file to the V93000 system, execute "File → Import → FLW Format", select "Overwrite Existing File", and an FLW format testflow file will be generated after import. Open the file and use the "Testsuite Management" function of the SmarTest software to confirm that all names conform to the specifications.

[0066] Cross-platform data synchronization: Ten minutes after confirming the accuracy of the files, the standardized names are pushed to the SAPMII-branded MES system via a RESTful transport protocol. This system's interface is built on a unified internal domain name, and the access path is "mes business module path under the enterprise domain + api sub-path + ts_sync interface identifier," used for Testsuite name synchronization. Fifteen minutes after the push is complete, the MES system's query interface is called (the access path logic is consistent with the push interface, but the interface identifier is replaced with "ts_list") to confirm that the 250 names are completely consistent with the processed CSV file.

[0067] Technical results: The entire process takes 10 minutes, which is 11 times more efficient than traditional manual modification (120 minutes); the error rate is 0, while the error rate of manual modification is about 7%, which fully complies with project specifications.

[0068] Example 2: This example provides a method for batch conversion of standard TESTSUITE names to 93K records for parallel processing of multiple testflows. Specific implementation details include:

[0069] Scene setting:

[0070] Simultaneously processing testflow files from 7 MCU chip projects, the server is configured with a 16-core Intel Xeon Gold 6430 CPU and 64GB DDR5 memory. All 7 files are text files exported from V93000, with details as follows:

[0071] Project 1 (MCU_01): File size 3.1MB, associated with 250 patterns, high priority (mass production the next day).

[0072] Project 2 (MCU_02): File size 2.2MB, associated with 180 patterns, medium priority (to be tested in 3 days).

[0073] Project 3 (MCU_03): File size 1.0MB, associated with 90 patterns, medium priority (to be tested in 3 days).

[0074] Project 4 (MCU_04): File size 4.8MB, associated with 400 patterns, low priority (to be tested in 1 week).

[0075] Project 5 (MCU_05): File size 2.5MB, associated with 210 patterns, low priority (to be tested in 1 week).

[0076] Project 6 (MCU_06): File size 1.7MB, associated with 150 patterns, low priority (to be tested in 1 week).

[0077] Project 7 (MCU_07): File size 0.8MB, associated with 70 patterns, low priority (to be tested in 1 week).

[0078] The system has a maximum upload limit of 50 files per upload, and files are sorted by priority and size.

[0079] Detailed operation steps:

[0080] Set up a task scheduling center: Develop a web platform based on the Spring Boot framework. Users can upload 7 text files in batches by dragging and dropping. The system automatically verifies the format (all are UTF-8 encoded) and there are no format errors.

[0081] Task queue management: After users mark the priority of files on the web interface, the system sorts them according to "high priority first, smaller files of the same priority first", and generates queues as follows: MCU_01→MCU_03→MCU_02→MCU_07→MCU_06→MCU_05→MCU_04; drag and drop adjustment is supported, but no adjustment was made in this case.

[0082] Parallel resource allocation: A resource monitoring process is initiated (collecting data every 8 seconds). Initially, CPU utilization is 20% and memory utilization is 25%. Thread 1 is started to process MCU_01. After 7 minutes, MCU_01 enters the fault tolerance phase, with CPU utilization at 65% and memory utilization at 40%. Thread 2 is started to process MCU_03. After 10 minutes, MCU_03 completes fault tolerance, with CPU utilization at 48% and memory utilization at 32%. Thread 3 is started to process MCU_02. After 13 minutes, MCU_01 completes data application, with CPU utilization at 58% and memory utilization at 38%. Thread 4 is started to process MCU_07. After 16 minutes, MCU_02 enters fault tolerance, with CPU utilization at 78% and memory utilization at 72%. Thread 5 is not started (approaching the 80% / 75% threshold). All threads independently occupy memory (3-6GB). Data application and cross-platform synchronization use different CPU cores, with no resource conflicts.

[0083] Real-time progress monitoring: The web-based visual dashboard displays progress categorized as "Pending, Processing, Completed, and Failed": At 32 minutes, MCU_01 / 03 / 07 are complete, MCU_02 is in the data application stage, and the rest are pending; projects in processing are marked with their specific stage (e.g., "85% in data application"), and operation details are displayed in a floating window. At 45 minutes, all projects are completed, and the system sends an email with a download link to the user's inbox; there are no failed tasks.

[0084] Subsequent processes: All 7 projects were completed according to the process of "acquisition-preprocessing-naming-processing-traceability and fault tolerance-application-synchronization", and high-priority projects were delivered for mass production on time.

[0085] Technical results: Total processing time was 45 minutes, a 35.7% improvement in efficiency compared to serial processing (70 minutes); the server's peak CPU usage was 78% and memory usage was 72%, without overload; high-priority projects were completed first, meeting urgent needs.

[0086] Example 3: This example provides a method for batch conversion of 93K standard testsuit names for module association verification. Specific implementation details include:

[0087] Scenario setting: Based on the MCU_01 project of Example 1, it is necessary to ensure the consistency of association between the Testsuites module and the Parameters and Tests modules. This is to avoid the situation where, after the Testsuites name is changed, the associated "Voltage Parameter P038" (value 5.0V) and "Test Case TC125" (IO port drive capability test) still refer to the original names, resulting in parameter call failure.

[0088] Detailed operation steps:

[0089] Construct an association mapping table: During the data preprocessing stage, while parsing the CSV file, synchronously record the association information for each name in the Testsuites module. For example, the original name "PAT_20240720_M01" corresponds to ParameterID "P038" (Parameters module), TestCaseID "TC125" (Tests module), and test phase "S03". Generate an Excel format mapping table containing 6 columns: "Testsuite Name, ParameterID, TestCaseID, Test Phase, Parameter Value, and Test Item", with a total of 250 records, stored in the path "E:\V93000\Mapping\MCU_01".

[0090] Correlation verification and correction: After the data processing is completed, the Parameters module (lines 272-510 of the file) and the Tests module (lines 511-780) are traversed. It is found that the Testsuite names corresponding to “P038” and “TC125” are still the original values. The system automatically calls the batch replacement function to correct them to the standard names and adds the correction record to the source fault tolerance log.

[0091] Application of verification results: The correlation verification results are used as an auxiliary basis for confirming the accuracy of the source tracing and fault tolerance stage. After confirming that all 250 correlation records are consistent, the file can proceed to the next step.

[0092] Technical results: The correlation verification and correction took 3 minutes, which is 13 times more efficient than manual verification (40 minutes); the omission rate dropped from 18% with manual modification to 0, and there were no parameter call errors in subsequent tests.

[0093] Example 4: This example provides a method for batch conversion of 93K standard testsuit names, used for full-process traceability and fault tolerance details. Specific implementation details include:

[0094] Scenario setting: Process a testflow file containing abnormal data (associated with 120 patterns), simulating two types of anomalies: 20 specification names with a length of 22 characters (exceeding the 20-character limit) and 5 identical patterns corresponding to two specification names, to verify the anomaly detection and handling capabilities of the source tracing and fault tolerance function.

[0095] Detailed operation steps:

[0096] Preprocessing and data processing: Generate a CSV file containing anomalies according to the standard process.

[0097] Origin and Fault Tolerance:

[0098] Logs generated: 20 entries marked "Length Exceeds Limit" (records the original value, the exceeded limit value, and the length of 22 characters), 5 entries marked "Multiple Correspondences" (records the original value and two conflicting limit values), and abnormal records marked "Manual Intervention Required".

[0099] Visual comparison: Filter and locate abnormal items by "abnormal type", marked in red; click on an abnormal item to jump to the standard configuration page to help troubleshoot errors.

[0100] Interruption and Correction: The system automatically interrupts subsequent steps, prompting "20 lines of length exceeded, 5 lines of multiple correspondences"; the user adjusts the specifications (shortening the prefix, correcting conflict rules), and after reprocessing and verification, there are no abnormalities, and the system proceeds to the next step.

[0101] Technical effects:

[0102] Anomaly detection takes 1.5 minutes, which is 16 times more efficient than manual inspection (25 minutes); it can locate anomalies 100% and prevent erroneous files from entering the testing process, thus reducing rework costs.

[0103] Example 5: This example provides a method for batch conversion of 93K standard testsuit names, used for rule self-iteration. Specific implementation details include:

[0104] Scenario setting: A new consumer-grade chip project (MCU_08) for customer Z is added. Its pattern name format is "V2_202407_MCU08_01" (different from the existing "PAT_20240720_M01" format). Adaptation specifications need to be generated through rule self-iteration to reduce manual configuration costs.

[0105] Detailed operation steps:

[0106] Build an initial knowledge base: Store existing customer rule mappings (such as "Pattern with 'PAT_' prefix → extract the 4th-9th digits of the date + 'MCU_XX_S03_' prefix) in a MySQL database. This rule has been verified by 6 projects and marked as "high credibility".

[0107] Intelligent parsing and matching: Import customer Z's Pattern file (100 entries). The system automatically scans for features: containing the separator "", date "202407" in the 3rd-8th position, prefix "V2", and containing "MCU08". No completely identical items are found in the knowledge base. Based on "date position similarity", the system outputs the recommended specification: "Extract the 3rd-8th date + 'MCU_08_S01_' prefix".

[0108] User Adjustment and Self-Iteration: The user adjusts the specification (supplementing the "V2" version number, changing it to "extract the 1st-2nd digit + the 3rd-8th digit + 'MCU_08_' prefix"). The system stores the adjusted rule in the knowledge base and marks it as "to be verified". The subsequent two customer Z projects adopted this rule without errors. After the third project passed the verification, the rule was automatically upgraded to "high credibility", and no further adjustments were needed for subsequent projects.

[0109] Technical results: The rule configuration for new customers takes 12 minutes, which is 73% more efficient than manual configuration (45 minutes); after the rules are self-iterated, subsequent projects do not need to be configured repeatedly, and the adaptation efficiency is significantly improved.

[0110] Example 6: This example provides a method for batch conversion of 93K standard testsuite names for cross-platform data synchronization. Specific implementation details include:

[0111] Scenario setting: Based on the MCU_01 project in Example 1, the specification name is synchronized to the SAPMII brand MES system, TestRail test management platform, and Jira defect management system, and the "verified" and "to be optimized" status indicators returned by the MES system are received.

[0112] Detailed operation steps:

[0113] Build a cross-system interface adaptation layer:

[0114] MES system: adopts RESTful protocol, the interface access path is "enterprise domain name + mes module + api + ts_sync", and the synchronization rule is "pull 10 minutes after file confirmation";

[0115] TestRail platform: Call the "Create Test Suite" interface of version 2.2, the access path is "platform domain name + testrail module + api + create_suite", and the synchronization rule is "push 5 minutes after MES synchronization";

[0116] Jira system: Call the "defect update" interface, the access path is "platform domain name + jira module + api + issue / update", the synchronization rule is "push 3 minutes after TestRail synchronization";

[0117] Reverse synchronization: Listen to the "status update" interface of the MES system (access path is "enterprise domain name + mes module + api + ts_status") and receive status change information.

[0118] Data consistency verification:

[0119] Eight minutes after MES synchronization, a query was performed using the "ts_list" interface, and 250 entries with the same name were found.

[0120] Four minutes after TestRail synchronization, log in to the platform to confirm that "MCU_01 Project - Test Suite" is complete;

[0121] Three minutes after Jira sync, open the defect report to confirm that the "Associated Test Suite" field is correct.

[0122] Reverse synchronization: 3 days later, the MES system will update the status of "MCU_01_S03_202407" to "verified". After receiving the information, the system will automatically send it back to the V93000 system, change the corresponding name to "MCU_01_S03_202407[verified]", and record the reverse synchronization log.

[0123] Technical benefits: Cross-system synchronization takes 30 minutes, which is twice as efficient as manual synchronization (90 minutes); data consistency is 100%, while the inconsistency rate of manual synchronization is about 10%; reverse synchronization does not require manual modification, reducing operating costs.

[0124] Comparative Example 1: This comparative example provides traditional techniques: Vim command modifications, specifically including:

[0125] Scenario setting: Using Vim commands to modify 7 testflow files, the same as in Example 2, the goal is to standardize Testsuite names.

[0126] Detailed operation steps:

[0127] Single file processing: Open the Linux terminal, enter the Vim command to load the file, write multiple replacement commands to adapt to different pattern formats (such as "PAT_" and "PAT_V2_" prefixes), and the processing time for a single file is 25 minutes (including debugging).

[0128] Multiple file processing: The project code in the command needs to be modified for 7 files, with a total time of 175 minutes; when processing files with the "FAIL" suffix, the command debugging takes an additional 40 minutes.

[0129] Manual verification: Verifying the associated modules line by line, each file takes 20 minutes, for a total of 140 minutes.

[0130] Technical results: Total time was 355 minutes, which is 7.9 times less efficient than parallel processing (45 minutes); error rate was 3.0% (22 missing corrections and 18 incorrect corrections); requires proficiency in Vim regular expressions, and has a high operating threshold.

[0131] Comparing Examples 1-6 with Comparative Example 1, from four core dimensions—processing efficiency, error control, operational threshold, and scenario adaptation—the Vim command modification methods of Examples 1-6 and Comparative Example 1 are compared. The differences are significant, and Examples 1-6 are superior in all aspects.

[0132] In terms of processing efficiency, Example 1, the entire process of batch conversion of a single project takes 10 minutes, which is 60% shorter than the 25 minutes for a single project in Comparative Example 1, and no manual debugging commands need to be written. Example 2, the parallel processing of 7 projects takes 45 minutes, while the same task in Comparative Example 1 takes 355 minutes, which is 7.9 times more efficient. It can also ensure the delivery of urgent projects through priority sorting. Example 3, the module association verification takes 3 minutes, which is 13 times more efficient than the 40 minutes of manual verification in Comparative Example 1. Example 5, the configuration of new customer rules only takes 12 minutes, which is 73% less than the 45 minutes of manual configuration in Comparative Example 1. Example 6, the cross-platform synchronization completes the data collaboration of multiple systems in 30 minutes, while manual synchronization in Comparative Example 1 takes 90 minutes. The efficiency advantages of each link are in line with the needs of mass production scenarios.

[0133] Regarding error control, the overall error rate for Examples 1-6 was 0%. Example 3 automatically corrected the parameters and test case association items through the association mapping table, avoiding the 18% omission of association modification issues in Comparative Example 1. Example 4, with the help of the source tracing and fault tolerance function, located 100% of the length exceeding the limit and multiple correspondence anomalies, eliminating the situation in Comparative Example 1 where 22 Patterns were omitted and 18 association parameters were incorrectly modified. The error rate was reduced from 3.0% in Comparative Example 1 to zero, ensuring the accuracy of the test data.

[0134] In terms of operational threshold, Examples 1-6 require no professional tools or skills, and ordinary testers can operate them after simple training. The task scheduling center in Example 2 and the rule self-iteration in Example 5 reduce the difficulty of operation through visualization or automation design; Comparative Example 1 requires proficiency in Vim regular expressions, repeated debugging of commands when facing different pattern formats, and manual modification of project codes when processing multiple projects, which has a high operational threshold and is prone to errors due to command writing mistakes.

[0135] In terms of scenario adaptation, Examples 1-6 cover a variety of scenarios such as full-process conversion, multi-project parallel processing, correlation verification, anomaly fault tolerance, new customer adaptation, and cross-system synchronization, which can meet the complex needs from single project to batch mass production and from local processing to multi-system collaboration. Comparative Example 1 can only process single-format files, cannot process multiple projects in parallel, does not support automatic anomaly detection and new customer rule reuse, and is difficult to adapt to the diverse scenarios of semiconductor chip mass production testing.

[0136] In summary, Examples 1-6, through automated and intelligent design, comprehensively surpass the traditional method of Comparative Example 1 in terms of efficiency, accuracy, ease of use, and scenario coverage, and are more in line with the high-efficiency, accurate, and flexible requirements of semiconductor chip mass production testing.

[0137] The above embodiments can be implemented in whole or in part by software, hardware, firmware or other arbitrary combinations. When implemented by software, the above embodiments can be implemented in whole or in part in the form of a computer program product.

[0138] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0139] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

[0141] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for batch conversion of standard TESTSUITE names using 93K, applied to the Advantest V93000 test program in the ATE testing field, characterized in that... Includes the following steps: S1. Obtain testflow.csv: Convert the testflow in the default text format in the V93000 system to CSV table format using the export operation; S2. Data preprocessing: Identify and extract the contents of the Testsuites module of the V93000 system in the testflow.csv file. The Testsuites module is a functional module in the V93000 system that stores basic information about test suites. The extracted content from the Testsuites module is stored separately as testflow_tmp.csv; S3. Search and naming: Locate the row and column information corresponding to Pattern and TestsuiteName in the testflow_tmp.csv, store Pattern and TestsuiteName in the Pattern list and the original Testsuite list respectively by row, and then process the TestsuiteName in the original Testsuite list according to the preset specification to generate the standardized Testsuite list. The preset specification is the TestsuiteName naming rule set based on the ATE test process standardization requirements. S4. Data Processing: Based on the original Testsuite list and the standardized Testsuite list, find and replace the content corresponding to the original TestsuiteName in the testflow.csv to obtain the testflow_output.csv with standardized Testsuite names; S5. Full-process traceability and fault tolerance: Verify the accuracy and trace the source of testflow_output.csv generated in step S4 to confirm that it meets the requirements of the ATE test process. S6. Data Application: The testflow_output.csv file, which has been confirmed to be correct in step S5, is sent back to the V93000 test program. It is imported and stored as flw format through the import operation to obtain the optimized testflow. S7. Cross-platform data synchronization: Synchronize the testflow_output.csv file, which has been confirmed to be correct in step S5, to the external management system to achieve data consistency across systems; The execution order of the steps is as follows: first execute step S4, then execute step S5 and complete the accuracy verification of testflow_output.csv; After step S5 is completed, you can choose to execute step S6 first and then step S7, or execute step S6 and step S7 in parallel. That is, both steps S6 and S7 are carried out based on the testflow_output.csv file that has been confirmed to be correct in step S5.

2. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Step S2, which involves identifying and extracting the Testsuites module content of the V93000 system in testflow.csv, specifically includes: traversing each row of data in testflow.csv, and when a row with the system identifier of the Testsuites module as the starting identifier is detected, recording the starting index of that row. The system identifier of the Testsuites module is a unique marker used in the V93000 system to distinguish this module from other modules. Continue traversing subsequent lines until a line is detected that starts with the system identifier of another module and is not the identifier of the Testsuites module. Record the ending index of that line. Extract all rows of data between the starting index and the ending index, and use them as the content of the Testsuites module.

3. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Step S3, which processes the TestsuiteName in the original Testsuite list according to the preset specification, specifically includes: the preset specification configures the length or position of the string to be extracted for different Pattern naming formats provided by different customers; According to the configuration, extract the target character fragment from the Pattern name associated with TestsuiteName, and store the target character fragment as the standardized TestsuiteName in the standardized Testsuite list.

4. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, It also includes step S21, module association verification: When parsing testflow.csv in step S2, the ParameterID (parameter identifier) ​​and TestCaseID (test case identifier) ​​corresponding to each TestsuiteName in the Testsuites module are recorded synchronously, and a module association mapping table containing TestsuiteName, ParameterID, TestCaseID and the test stage to which they belong is generated; The ParameterID corresponds to the Parameters module of the V93000 system, which is a functional module in the V93000 system that stores test parameter configuration information; The TestCaseID corresponds to the Tests module of the V93000 system, which is a functional module in the V93000 system that stores specific test case information; After replacing TestsuiteName in step S4, the Parameters and Tests modules in testflow.csv are traversed, and the TestsuiteName corresponding to ParameterID and TestCaseID is verified to be consistent with the standard Testsuite list based on the module association mapping table. If there is a discrepancy, the TestsuiteName in the Parameters module and the Tests module will be automatically corrected, or a highlighted message will be generated. The execution result of step S21 is used to assist in the accuracy verification of step S5.

5. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Before processing the TestsuiteName in the original Testsuite list according to the preset specifications in step S3, the method further includes: building a rule knowledge base: storing the original Pattern format-preset specification mapping relationship verified in historical projects, wherein the mapping relationship includes the correspondence between the separator type, keyword position, fixed length field and preset specification of the Pattern name; Intelligent parsing and matching: After importing a new customer's Pattern file, the system automatically scans the separator type, keyword position, and fixed-length field features of the Pattern name, matches these features with the mapping relationship in the rule knowledge base, and outputs recommended specifications. Rule self-iteration: If the user adjusts the recommendation specification, the mapping relationship between the original pattern format and the adjusted specification will be incorporated into the rule knowledge base; When the adjusted mapping relationship is verified to be effective in 3 or more projects, it is marked as a high-confidence mapping relationship.

6. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Step S5, full-process traceability and fault tolerance, specifically includes: S51, generating a replacement log: recording the original value, specification value, matched preset specification, processing time and operator corresponding to each TestsuiteName in the original Testsuite list, generating a structured log that supports export in Excel or HTML format, and highlighting the record types that are automatically matched or manually adjusted in the log; S52. Visual Comparison: Set up a comparison interface with left and right columns. The left side displays the TestsuiteName in the original testflow.csv, and the right side displays the compliant TestsuiteName in testflow_output.csv. It supports filtering difference data by module type and error type. The module types include Testsuites, Parameters, and Tests modules. The error types are name length exceeding the limit or missing keywords. Clicking on the difference data will redirect you to the corresponding preset specification configuration page; S53. Accuracy Confirmation: If any of the following situations are detected, the subsequent steps S6 and S7 will be automatically interrupted and a prompt message will be output. Step S4 will be re-executed after the user makes the correction. If no anomalies are detected, it is confirmed that testflow_output.csv can be used for import in step S6 and synchronization in step S7: the length of the standardized TestsuiteName exceeds the character limit of 20 characters specified by the V93000 system; The same Pattern name can correspond to multiple different TestsuiteName specifications; The standardized TestsuiteName contains duplicates.

7. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Step S7 cross-platform data synchronization specifically includes: S71, building a cross-system interface adaptation layer: connecting to the MES system, test management platform and defect management system through API, configuring Testsuite name synchronization rules, the synchronization rules include automatically pushing to the test process module of the MES system within 10 minutes after confirming the accuracy of testflow_output.csv in step S5, or after completing the import of V93000 system in step S6. S72. Data consistency verification: After pushing the Testsuite name according to the synchronization rules, compare the consistency between the Testsuite name stored in each external system and testflow_output.csv. If any inconsistency exists, trigger the retry push mechanism or send an alert email to the administrator; S73. Reverse Synchronization: When the status identifier of the Testsuite updated in the MES system has been verified or is to be optimized, the status identifier is sent back to the V93000 test program through the cross-system interface adaptation layer, and the status identifier is added after the corresponding TestsuiteName.

8. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Before obtaining testflow.csv in step S1, the process also includes step S0, parallel processing of multiple testflows and task scheduling: S01, setting up a task scheduling center: receiving multiple testflow files to be processed uploaded by users in batches. The testflow files to be processed are text format testflows exported by the V93000 system, and the files contain complete information of the Testsuites module, Parameters module, and Tests module. S02, Task Queue Management: When a user uploads a testflow file to be processed, each file is manually marked as high, medium, or low priority. The system sorts multiple testflow files to be processed according to the rule of priority first, and then in ascending order of file size under the same priority, and generates a task queue and supports manual adjustment of the order of files in the queue; S03, Parallel Resource Allocation: Real-time collection of server CPU utilization and memory usage. When CPU utilization is below 80% and memory usage is below 75%, a new thread is started to retrieve testflow files to be processed from the task queue. The maximum number of threads is set to 3-5. Each thread executes steps S1-S7 independently or executes steps S1-S5 first and then executes steps S6 and S7 in parallel. The server resources occupied by step S6 (V93000 system import) and step S7 (external system synchronization) are independent of each other and do not affect the import efficiency of the V93000 system or the synchronization stability of the external system. The memory space occupied by each thread is also independent of each other. S04. Real-time progress monitoring: Set up a visual task dashboard to display the status of each pending testflow file in categories such as pending, processing, completed, and failed. For files in the process, the current step is marked by a progress bar. There are two marking methods: the first is that the file first enters the preprocessing stage, then the naming process stage, then the data replacement stage, then the source tracing and fault tolerance stage, then the data application stage, then the cross-system synchronization stage, and finally the import completion stage. The second method involves the file first entering the preprocessing stage, then the naming process stage, followed by the data replacement stage, then the source tracing and fault tolerance stage, then the data application and cross-system synchronization and parallel stage, and finally the import completion stage. When file processing is complete or fails, a system pop-up notification is triggered and an email containing a download link for testflow_output.csv is sent to the user; If the process fails, the email will simultaneously include the reason for the failure: incorrect file format / insufficient server resources.

9. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 8, characterized in that, In step S02, the user uploads multiple testflow files to be processed in batches. The maximum upload limit per batch is configurable, with a default limit of 50 files.

10. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 8, characterized in that, The maximum number of threads in step S03 can be adjusted according to the number of CPU cores on the server: when the server has an 8-core CPU, the maximum number of threads is set to 5, and 3 CPU cores are reserved for basic operations of the V93000 system.

Images