Method for 93K batch conversion of standard TESTSUITE names

Abstract

The invention discloses a method for converting standard TESTSUITE names in batches in 93K. The method comprises the following steps of: converting testflow in a default text format in a V93000 system into a csv table format through an export operation; the intercepted module content is independently stored as testflow tmp.csv. According to the method, name batch conversion is achieved through an automatic process, manual line-by-line modification or complex command writing is not needed, a multi-testflow parallel processing mechanism can dynamically allocate threads according to project priorities and server resources, waiting time consumption of serial processing is avoided, and the efficiency is improved. Meanwhile, manual intervention links in single-project full-process operation are reduced; and on the other hand, a rule self-iteration function can automatically adapt to a new customer Pattern format, and repeated manual specification configuration is not needed.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of ATE testing, and particularly relates to a method for converting standard TESTSUITE names in batches. BACKGROUND

[0002] In the field of ATE testing, the Advantest V93000 test system is a commonly used device for mass production testing of semiconductor chips, and the testflow file generated by the Advantest V93000 test system contains three types of core modules: Testsuites module (stores basic information of test suite), Parameters module (stores test parameter configuration information), and Tests module (stores specific test case information). In chip testing, Pattern conversion will automatically generate Testsuite names, and in actual application, the name needs to be standardized to the format of "project code_test phase_date" to meet the management requirements. In the prior art, Testsuite name standardization is mainly achieved by Vim command modification, manual line-by-line editing or simple batch processing tools, which can complete basic name replacement, generate modification logs in some scenarios, and can synchronize the standardized name to external systems such as MES system and test management platform through manual operation, to meet the testing requirements of single project or simple scenarios. The prior art has obvious limitations in actual application and is difficult to match the efficient and accurate requirements of chip mass production testing. In terms of processing efficiency, the existing method is mostly serial processing, and when multiple projects are processed at the same time, the previous project needs to be completed, and the Vim command needs to be repeatedly debugged for different Pattern formats, which takes a long time. In terms of accuracy, manual checking is easy to miss the associated items of Testsuites module and Parameters module and Tests module, and lacks an abnormal detection mechanism, so it cannot timely find problems such as name length exceeding limit and multiple standardized names corresponding to the same Pattern. In terms of ease of use, Vim command modification requires operators to master regular expressions, and ordinary test personnel need long-term training to be competent. In terms of scene adaptation, when the Pattern format of a new customer changes, the specification needs to be manually reconfigured, cross-system synchronization relies on manual login to multiple platforms, and there is no ability to receive the status identifier of external systems and automatically update, making it difficult to adapt to mass production scenarios with multiple customers and multiple systems. SUMMARY

[0003] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present application provide a method for converting standard TESTSUITE names in batches, which solves the problems of low efficiency, poor accuracy, low ease of use and weak adaptation of the prior art in the field of ATE testing.

[0004] To achieve the above-mentioned purpose, the present application provides the following technical solutions: A method for batch converting standard TESTSUITE names in 93K, applied to Advantest V93000 test program in ATE test field, comprising the following steps: S1, obtaining testflow.csv: converting the testflow in default text format in V93000 system into csv table format through export operation; S2, data preprocessing: identifying and intercepting the Testsuites module content of V93000 system in testflow.csv, the Testsuites module being a functional module for storing test suite basic information in V93000 system; storing the intercepted Testsuites module content as testflow_tmp.csv; S3, searching and naming: locating the row and column information corresponding to Pattern and Testsuite Name in testflow_tmp.csv, storing the Pattern and Testsuite Name in Pattern list and original Testsuite list respectively by row, and processing the Testsuite Name in original Testsuite list according to preset specification to generate specification Testsuite list, the preset specification being Testsuite Name naming rule set based on ATE test flow standardization requirement; S4, data processing: based on the original Testsuite list and specification Testsuite list, finding and replacing the content corresponding to original Testsuite Name in testflow.csv to obtain testflow_output.csv with standardized Testsuite name; S5, whole-process tracing and fault tolerance: performing accuracy verification and tracing record on testflow_output.csv generated in step S4 to confirm that it meets the requirements of ATE test flow; S6, data application: returning testflow_output.csv confirmed to be correct in step S5 to V93000 test program, importing and storing it as flw format through import operation to obtain optimized testflow; S7, cross-platform data synchronization: synchronizing testflow_output.csv confirmed to be correct in step S5 to external management system such as MES system and test management platform to realize data consistency across systems; And the execution order of the steps is: first performing step S4, then performing step S5 and completing the accuracy confirmation of testflow_output.csv; after step S5 is completed, it can be selected to perform step S6 first and then perform step S7, or step S6 and step S7 are performed in parallel; that is, step S6 and step S7 are both based on the error-free testflow_output.csv confirmed in step S5.

[0005] Preferably, the identification and interception of the content of the Testsuites module of the V93000 system in the testflow.csv in step S2 specifically includes: Traverse each row of data of the testflow.csv, and record the starting index of the row when detecting the row with the system identifier of the Testsuites module as the starting identifier, the system identifier of the Testsuites module being a special mark used to distinguish the module from other modules in the V93000 system; continue to traverse the subsequent rows, and record the ending index of the row when detecting the row with the system identifier of other modules as the starting identifier and not the identifier of the Testsuites module; extract all row data between the starting index and the ending index as the content of the Testsuites module.

[0006] Preferably, the processing of the Testsuite Name in the original Testsuite list according to the preset specification in step S3 specifically includes: The preset specification configures the length or position of the to-be-extracted string according to the Pattern naming format provided by different customers; the target character segment is extracted from the Pattern name associated with the Testsuite Name according to the configuration, and the target character segment is stored as the standardized Testsuite Name in the standardized Testsuite list.

[0007] Preferably, it further includes step S21, module association verification: In step S2, when parsing testflow.csv, the ParameterID corresponding to each TestsuiteName in the Testsuites module and the TestCaseID are recorded synchronously, and a module association mapping table containing TestsuiteName, ParameterID, TestCaseID and the test phase 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 for storing test parameter configuration information; the TestCaseID corresponds to the Tests module of the V93000 system, which is a functional module in the V93000 system for storing specific test case information; After completing the replacement of Testsuite Name in step S4, the Parameters module and the Tests module in testflow.csv are traversed, and based on the module association mapping table, it is checked whether the TestsuiteName corresponding to ParameterID and TestCaseID is consistent with the specification Testsuite list; if not, the Testsuite Name in the Parameters module and the Tests module is automatically corrected, or a highlighted prompt information is generated; the execution result of step S21 is used to assist the accuracy check of step S5.

[0008] Preferably, before the processing of Testsuite Name in the original Testsuite list according to the preset specification in step S3, it further includes: Building a rule knowledge base: storing the verified original Pattern format-preset specification mapping relationship in historical projects, the mapping relationship contains the corresponding relationship between the delimiter type, keyword position, fixed length field of the Pattern name and the preset specification; Intelligent analysis and matching: after importing the Pattern file of a new customer, the delimiter type, keyword position and fixed length field characteristics of the Pattern name are automatically scanned, the characteristics are matched with the mapping relationship in the rule knowledge base, and the recommended specification is output; Rule self-iteration: if the user adjusts the recommended specification, the adjusted original Pattern format-adjusted specification mapping relationship is included in 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.

[0009] Preferably, step S5 full-process tracing and fault tolerance specifically includes: S51, generating a replacement log: recording the original value, the standard value, the matched preset standard, the processing time and the operator corresponding to each Testsuite Name in the original Testsuite list, generating a structured log supporting Excel or HTML format export, and highlighting the record type of automatic matching or manual adjustment of rules in the log; S52, visual comparison: setting a comparison interface with left and right columns, displaying Testsuite Name in the original testflow.csv on the left side and displaying standard Testsuite Name in testflow_output.csv on the right side, supporting filtering of difference data by module type and error type, the module type including Testsuites module, Parameters module and Tests module, and the error type being name length exceeding the limit or keyword missing; clicking the difference data jumps to the corresponding preset standard configuration page; S53, accuracy confirmation: if any of the following conditions is detected, the subsequent steps S6 and S7 are automatically interrupted and a prompt message is output, and after the user corrects it, the step S4 is executed again; 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: The length of the standard Testsuite Name exceeds the upper limit of 20 characters specified by the V93000 system; The same Pattern name corresponds to multiple different standard Testsuite Names; The standard Testsuite Name exists repetition.

[0010] Preferably, the step S7 cross-platform data synchronization specifically includes: S71, building a cross-system interface adaptation layer: through API, the MES system, the test management platform and the defect management system are connected, the Testsuite name synchronization rule is configured, and the synchronization rule includes the Testsuite name synchronization rule pushed to the test flow module of the MES system within 10 minutes after the accuracy of testflow_output.csv is confirmed in step S5 or after the V93000 system import is completed in step S6; S72, data consistency check: after pushing the Testsuite name according to the synchronization rule, the consistency of the Testsuite name stored in each external system and testflow_output.csv is compared; if there is inconsistency, a retry pushing mechanism is triggered or an alarm email is sent to the administrator; 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.

[0011] Preferably, before obtaining testflow.csv in step S1, the process also includes step S0, parallel processing of multiple testflows and task scheduling: 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. 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; 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 board, and show the status of each testflow file to be processed according to the classification of to-be-processed, processing, completed and failed; for the files being processed, mark the current step through the progress bar, and the marking methods include two kinds: the first kind is that the file first enters the preprocessing stage, then enters the naming processing stage, then enters the data replacement stage, then enters the traceability fault tolerance stage, then enters the data application stage, then enters the cross-system synchronization stage, and finally enters the import completion stage; the second kind is that the file first enters the preprocessing stage, then enters the naming processing stage, then enters the data replacement stage, then enters the traceability fault tolerance stage, then enters the data application and cross-system synchronization parallel stage, and finally enters the import completion stage; when the file processing is completed or failed, a system pop-up window is triggered to prompt and send an email containing a testflow_output.csv download link to the user; if the processing fails, the email synchronously contains a failure reason file format error or server resource shortage; Through the parallel processing and task scheduling of step S0, the processing efficiency of multiple testflows is improved by 3-5 times compared with serial processing, and server resource overload is avoided.

[0012] Preferably, in step S02, the upper limit of single upload of multiple testflow files uploaded by the user in batch is configurable, and the default upper limit is 50.

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

[0014] The technical effects and advantages of the method for converting the names of 93K batch test suites to standard TESTSUITE names according to the application are as follows: 1. The application realizes batch conversion of Testsuite names through an automatic process, without manual line-by-line modification or complex command writing: 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 the manual intervention link in the operation of the whole project flow; on the other hand, the rule self-iteration function can automatically adapt to the new customer Pattern format, without the need to repeatedly manually configure the specification, greatly shortening the adaptation time in new scenarios, and significantly improving the overall processing efficiency compared with the traditional manual or command modification method.

[0015] 2、The application guarantees data accuracy and reduces test risk by module association verification function, which can verify the association consistency of Testsuites module and Parameters module, Tests module synchronously, avoid missing associated parameters or test case references by modifying Testsuite name only, and prevent parameter call failure in subsequent V93000 system test; at the same time, full-process traceability and fault-tolerant mechanism can detect abnormality such as length exceeding limit, repetition, and multiple corresponding of the same Pattern in specification name in real time, automatically interrupt error process and prompt correction, avoid error data from entering test link from the source, reduce error processing rate to the minimum, and guarantee test data effectiveness and equipment operation stability.

[0016] 3、The application reduces operation threshold and improves ease of use The method does not need to rely on professional tool skills, realizes task scheduling, progress monitoring and abnormality comparison through visual interface, and ordinary test personnel can operate after simple training: task scheduling center supports batch file uploading and priority visual adjustment, abnormality annotation and configuration jump function of traceability fault-tolerant link simplifies problem troubleshooting, cross-platform synchronous automatic push and verification reduces repeated operation of manual login to multiple systems, significantly reduces technical threshold, and improves universality and ease of use of the method.

[0017] 4、The application enhances scene adaptability and meets diversified needs The method can cover multiple core scenes in semiconductor chip mass production test: cross-platform data synchronization can be realized to realize data collaboration with MES system, test management platform and defect management system, support receiving external system state identification reversely and automatic updating, meet multi-system linkage demand; through rule self-iteration and parallel processing, the method can adapt to multiple customer Pattern format differences and multiple project batch processing demand, flexibly cope with different priority project delivery rhythm, and provide efficient and stable technical support for industrial mass production test. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 is a flowchart of a method for converting 93K batch standard TESTSUITE name proposed by the application. DETAILED DESCRIPTION

[0019] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.

[0020] It should be noted that, in the present document, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0021] Reference Figure 1 The present application provides a method for converting standard TESTSUITE names in batches of 93K, based on Advantest V93000 test system, aiming at the non-standard problem of Testsuite name generated by Pattern conversion in the field of ATE test, and adopting batch conversion method to realize standardization. All tests are based on semiconductor chip mass production projects, and the testflow file contains three types of core modules of the V93000 system: Testsuites module (stores test suite basic information), Parameters module (stores test parameter configuration information), and Tests module (stores specific test case information). The standardized Testsuite name needs to follow the format of "project code_test stage_date", for example, "MCU_01_S03_202407".

[0022] Embodiment 1: The embodiment provides a method for converting standard TESTSUITE names in batches of 93K, which is used for full-process batch conversion, and the specific implementation content includes: Scenario setting: processing an industrial-grade MCU chip project (project code MCU_01), the file to be processed is a text format testflow file exported by the V93000 system, the file size is 3.1MB, and it is associated with 250 Patterns. The Pattern name format is "PAT_20240720_M01" and "PAT_20240720_M03". All Testsuite names need to be uniformly standardized to "MCU_01_S03_202407".

[0023] Specific operation steps: Obtain testflow.csv: Log in to the V93000 system, open the text format testflow file of the project in SmarTest software, perform the "File -> Export -> CSV format" operation, set the encoding to UTF-8, the field separator to comma, and the export file to be stored in the "E:\V93000\TestData\MCU_01" path, and the file name to be "testflow_MCU01.csv".

[0024] Data preprocessing: Use Python3.10 to write a data processing program, call the pandas data processing library to read the above CSV file, and scan the content line by line: when detecting a line starting with the Testsuites module identifier of the V93000 system default (file line 18), record the starting index 18; continue to scan to the line starting with the Parameters module identifier (file line 272), record the termination index 271; extract the line data of index 18-271 (only contains the Testsuites module content), save it as "testflow_tmp_MCU01.csv" separately, and store it in the same path as the original CSV file.

[0025] Search and naming: In the temporary CSV file generated by preprocessing, locate the 5th column storing the Pattern name and the 7th column storing the Testsuite name, arrange the 250 Pattern names into a Pattern list, and arrange the original Testsuite name consistent with the Pattern name into an original Testsuite list. Process the original name according to the preset specification: extract the 4-9th character from the Pattern name (such as "PAT_20240720_M01" extracts "202407"), concatenate the project code "MCU_01" and the test phase "S03" to generate the specification Testsuite list (all elements are "MCU_01_S03_202407").

[0026] Data processing: Build 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 corresponding specification names, and save as "testflow_output_MCU01.csv".

[0027] Full-process traceability and fault tolerance: Generate replacement log: Record the original value, standard value, matched preset standard, processing time (2024-07-22 14:35:22), operator (TEST_ENG02), log type (rule automatic matching) of each data in Excel format. The log is stored in the "E:\V93000\Log\MCU01" path.

[0028] Visual comparison: Open the comparison interface developed based on PyQt6, load the Testsuite name of the initial CSV file on the left side, load the processed standard name on the right side, filter by "Module Type = Testsuites", and there is no difference in the 250 data.

[0029] Accuracy confirmation: Detect the length of the standard name as 18 characters (the upper limit of V93000 system characters is 20 characters), there is no repetition, and there is no multiple standard name corresponding to the same Pattern; find that 1 associated parameter is not synchronized (to be corrected later), confirm that the file is accurate and can be used for subsequent steps.

[0030] Data application: Upload the processed CSV file to the V93000 system, perform "File -> Import -> FLW format" operation, select "overwrite original file", and generate FLW format testflow file after import. Open the file and confirm that all names meet the specifications through the "Testsuite management" function of SmarTest software.

[0031] Cross-platform data synchronization: Within 10 minutes after the accuracy of the file is confirmed, the standard name is pushed to the MES system of the SAPMII brand through the RESTful transmission protocol. The interface of this system is based on the unified domain name of the enterprise, and the access path is "mes business module path + api sub-path + ts_sync interface identifier under the enterprise domain name", which is used for Testsuite name synchronization. After 15 minutes of pushing, the query interface of the MES system is called (the access path logic is consistent with the pushing interface, and the interface identifier is replaced with "ts_list"), and it is confirmed that the 250 names are completely consistent with the processed CSV file.

[0032] Technical effect: The whole process takes 10 minutes, which is 11 times more efficient than traditional manual modification (120 minutes); the error rate is 0, and the error rate of manual modification is about 7%, which fully meets the project specifications.

[0033] Embodiment 2: The embodiment provides a method for converting standard TESTSUITE names in batches of 93K, which is used for parallel processing of multiple testflows, and the specific implementation content includes: Scenario setting: The testflow files of 7 MCU chip projects were processed at the same time, and the server was configured with a 16-core Intel Xeon Gold 6430 central processor and 64 GB DDR5 memory. The 7 files were in text format exported by V93000, and the specific information is as follows: Project 1 (MCU_01): file size 3.1 MB, associated with 250 patterns, high priority (next day production); Project 2 (MCU_02): file size 2.2 MB, associated with 180 patterns, medium priority (test in 3 days); Project 3 (MCU_03): file size 1.0 MB, associated with 90 patterns, medium priority (test in 3 days); Project 4 (MCU_04): file size 4.8 MB, associated with 400 patterns, low priority (test in 1 week); Project 5 (MCU_05): file size 2.5 MB, associated with 210 patterns, low priority (test in 1 week); Project 6 (MCU_06): file size 1.7 MB, associated with 150 patterns, low priority (test in 1 week); Project 7 (MCU_07): file size 0.8 MB, associated with 70 patterns, low priority (test in 1 week).

[0034] The system sets the upper limit of single file upload to 50, and processes them according to priority and file size.

[0035] Specific operation steps: Build a task scheduling center: develop a Web platform based on the SpringBoot framework, users can upload 7 text files by batch dragging, the system automatically checks the format (all in UTF-8 encoding), and there is no format error.

[0036] Task queue management: after the user marks the priority of the file on the Web, the system sorts according to "high priority first, same priority small file first", generates the queue: MCU_01→MCU_03→MCU_02→MCU_07→MCU_06→MCU_05→MCU_04; supports drag adjustment, this case is not adjusted.

[0037] Parallel resource allocation: Start resource monitoring process (collect every 8 seconds), initial CPU usage 20%, memory 25%, start the first thread to handle MCU_01; 7 minutes later, MCU_01 enters the trace fault tolerance phase, CPU 65%, memory 40%, start the second thread to handle MCU_03; 10 minutes later, MCU_03 completes the trace fault tolerance, CPU 48%, memory 32%, start the third thread to handle MCU_02; 13 minutes later, MCU_01 completes the data application, CPU 58%, memory 38%, start the fourth thread to handle MCU_07; 16 minutes later, MCU_02 enters the trace fault tolerance, CPU 78%, memory 72%, no fifth thread is started (close to 80% / 75% threshold). All threads independently occupy memory (3-6GB), data application and cross-platform synchronization occupy different CPU cores, with no resource conflict.

[0038] Progress real-time monitoring: The web visual board displays the progress according to "to be processed, in processing, completed, failed": at 32 minutes, MCU_01 / 03 / 07 have completed, MCU_02 is in the data application stage, and the rest are to be processed; the specific stage (such as "data application 85%") is marked, and the operation details are displayed in suspension. At 45 minutes, all projects are completed, and the system sends an email with a download link to the user's mailbox, with no failed tasks.

[0039] Subsequent process: The 7 projects are completed according to the "acquisition-preprocessing-naming-processing-trace fault tolerance-application-synchronization" process, and the high-priority projects are delivered on time for mass production.

[0040] Technical effect: The total time consumption is 45 minutes, which is 35.7% more efficient than serial processing (70 minutes); the server's maximum CPU is 78%, and the memory is 72%, without overloading; high-priority projects are completed first, meeting urgent needs.

[0041] Embodiment 3: This embodiment provides a method for converting 93K batch standard TESTSUITE names, which is used for module association verification, and the specific implementation content includes: Scenario setting: Based on the MCU_01 project in embodiment 1, it is necessary to ensure the consistency of the association between the Testsuites module and the Parameters and Tests modules, and to avoid the situation that after the Testsuite name is modified, the associated "voltage parameter P038" (value 5.0V) and "test case TC125" (IO port driving capability test) still refer to the original name, resulting in parameter call failure.

[0042] Specific operation steps: Mapping table construction: During the data preprocessing phase of parsing the CSV file, the Testsuites module synchronously records the association information of each name: such as the original name "PAT_20240720_M01" corresponding to the ParameterID "P038" (Parameters module), TestCaseID "TC125" (Tests module), and test phase "S03". An Excel format mapping table is generated, containing 6 columns of "Testsuite Name, ParameterID, TestCaseID, test phase, parameter value, test item", a total of 250 records, stored in the "E:\V93000\Mapping\MCU_01" path.

[0043] Association verification and correction: After data processing is completed, the Parameters module (file lines 272-510) and the Tests module (lines 511-780) are traversed, and it is found that the Testsuite name corresponding to "P038" and "TC125" is still the original value. The system automatically calls the batch replacement function to correct it to the standard name, and supplements the correction record in the traceability fault tolerance log.

[0044] Verification result application: The association verification result is used as an auxiliary basis for accuracy confirmation in the traceability fault tolerance phase, and it is confirmed that the 250 association records are consistent, and the file can enter the subsequent steps.

[0045] Technical effect: The association verification and correction takes 3 minutes, which is 13 times more efficient than manual verification (40 minutes); the error correction rate is reduced from 18% to 0, and there is no parameter call error in subsequent testing.

[0046] Embodiment 4: The embodiment provides a 93K batch conversion standard TESTSUITE name method for full-process traceability and fault tolerance details, and the specific implementation content includes: Scenario setting: Process a testflow file containing abnormal data (associate 120 patterns), simulate two abnormalities: 20 standard name lengths of 22 characters (exceeding the 20 character upper limit), and 5 standard names corresponding to the same pattern, verify the abnormal detection and processing capability of the traceability fault tolerance function.

[0047] Specific operation steps: Preprocessing and data processing: Generate a CSV file containing abnormalities according to the conventional process.

[0048] Traceability and fault tolerance: Log generation: Mark 20 "length exceeds limit" (record original value, over-limit standard value, length 22 characters), 5 "multiple corresponding" (record original value, two conflicting standard values), and abnormal record marked "manual intervention required".

[0049] 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.

[0050] 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.

[0051] Technical effects: 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.

[0052] Example 5: This example provides a method for batch conversion of 93K standard testsuit names, used for rule self-iteration. Specific implementation details include: 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.

[0053] Detailed operation steps: 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".

[0054] 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".

[0055] 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.

[0056] 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.

[0057] Example 6: This example provides a method for batch conversion of 93K standard testsuite names for cross-platform data synchronization. Specific implementation details include: 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.

[0058] Detailed operation steps: Build a cross-system interface adaptation layer: 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"; 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"; 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"; 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.

[0059] Data consistency verification: Eight minutes after MES synchronization, a query was performed using the "ts_list" interface, and 250 entries with the same name were found. Four minutes after TestRail synchronization, log in to the platform to confirm that "MCU_01 Project - Test Suite" is complete; Three minutes after Jira sync, open the defect report to confirm that the "Associated Test Suite" field is correct.

[0060] 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.

[0061] Technical effects: cross-system synchronization takes 30 minutes, 2 times more efficient than manual synchronization (90 minutes); data consistency is 100%, manual synchronization inconsistency rate is about 10%; reverse synchronization does not require manual modification, reducing operation cost.

[0062] Comparative Example 1: This comparative example provides a traditional technology: Vim command modification, which includes the following details: Scenario setting: using Vim command modification method to process the same 7 testflow files as in Example 2, the goal is to standardize the Testsuite name.

[0063] Specific operation steps: Single file processing: open Linux terminal, input Vim command to load file, write multiple replacement commands to adapt different Pattern formats (such as "PAT_" "PAT_V2_" prefix), single file takes 25 minutes (including debugging).

[0064] Multi-file processing: 7 files need to modify the project code in the command, total time 175 minutes; when processing files containing "FAIL" suffix, command debugging takes an additional 40 minutes.

[0065] Manual verification: line-by-line verification of associated modules, each file takes 20 minutes, total time 140 minutes.

[0066] Technical effects: total time 355 minutes, 7.9 times less efficient than parallel processing (45 minutes); error rate 3.0% (miss 22, wrong 18); need to master Vim regular expressions, high operation threshold.

[0067] Comparing Example 1-6 and Comparative Example 1, from the four core dimensions of processing efficiency, error control, operation threshold, and scene adaptation, the Vim command modification method of Example 1-6 and Comparative Example 1 is significantly different and Example is overall superior.

[0068] In terms of processing efficiency, Example 1 takes 10 minutes for the whole process of batch conversion of a single project, which is 60% shorter than the 25 minutes of Comparative Example 1, and does not require manual debugging command writing; Example 2 processes 7 projects in parallel, taking 45 minutes, while Comparative Example 1 takes 355 minutes for the same task, with an efficiency improvement of 7.9 times, and can also ensure urgent project delivery through priority sorting; Example 3 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 new customer rule configuration only takes 12 minutes, which is 73% less than the 45 minutes of manual configuration in Comparative Example 1; Example 6 cross-platform synchronization takes 30 minutes to complete multi-system data collaboration, while Comparative Example 1 takes 90 minutes for manual synchronization, and the efficiency advantage of each link meets the needs of mass production scenarios.

[0069] In terms of error control, the overall error rates of embodiments 1-6 are 0. Embodiment 3 automatically corrects the parameters associated with the use cases by associating the mapping table, avoiding the 18% association error correction problem in Comparative Example 1; Embodiment 4 uses the traceability fault-tolerant function to 100% locate the length overrun and multiple corresponding abnormalities, eliminating the 22 Pattern missing and 18 associated parameter errors in Comparative Example 1, reducing the error rate from 3.0% in Comparative Example 1 to zero, and ensuring the accuracy of the test data.

[0070] In terms of operation threshold, embodiments 1-6 do not require professional tool skills, and ordinary test personnel can operate after simple training. The task scheduling center of embodiment 2 and the rule self-iteration of embodiment 5 both reduce the operation difficulty through visual or automatic design; Comparative Example 1 requires a good command of Vim regular expressions, and needs to repeatedly debug the commands when facing different Pattern formats, and also needs to manually modify the project code when processing multiple projects, which has a high operation threshold and is prone to errors due to command writing mistakes.

[0071] In terms of scenario adaptation, embodiments 1-6 cover multiple scenarios such as full-process conversion, multiple project parallelism, association verification, abnormality fault tolerance, new customer adaptation, and cross-system synchronization, and can meet complex demands from single project to batch production, from local processing to multi-system collaboration; Comparative Example 1 can only process single format files and cannot handle multiple projects in parallel, does not support automatic detection of abnormalities and reuse of new customer rules, and is difficult to adapt to the diversified scenarios of semiconductor chip production testing.

[0072] In summary, embodiments 1-6, through automation and intelligent design, have comprehensively surpassed the traditional method of Comparative Example 1 in efficiency, accuracy, ease of use, and scenario coverage, and are more in line with the efficient, accurate, and flexible needs of semiconductor chip production testing.

[0073] The above embodiments can be realized wholly or partially by software, hardware, firmware, or any combination thereof, and when realized by software, the above embodiments can be realized in the form of a computer program product.

[0074] Those skilled in the art can realize that the modules and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware, and whether the functions are realized by hardware or software depends on the specific application and design constraints of the technical solutions. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0075] In addition, the functional modules in each embodiment of the present application can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module.

[0076] The above merely provides the specific implementation of the present application, but the protection scope of the present application is not limited to this. Any modification or replacement within the technical range disclosed by the present application can be easily thought by any person skilled in the art, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0077] Finally, the above merely provides the preferred embodiments of the present application, and is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application should be included in the protection scope of the present application.

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 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. 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 Testsuite Name 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 Testsuite Name in the testflow.csv to obtain the standardized Testsuite name testflow_output.csv; 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 external management systems such as MES systems and test management platforms 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 step S6 and step S7 are based on the testflow_output.csv that has been verified 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 from the testflow.csv file, specifically includes: 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.

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 Testsuite Names in the original Testsuite list according to preset specifications, 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, 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.

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 Testsuite Name 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 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.

5. The method for batch conversion of standard TESTSUITE names in 93K as described in claim 1, characterized in that, Before processing the Testsuite Names in the original Testsuite list according to the preset specifications in step S3, the following steps are also included: 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. 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 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.

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. 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. 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. 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: The standardized Testsuite Name exceeds the 20-character limit specified by the V93000 system. The same pattern name can correspond to multiple different specification testsuite names; The standardized Testsuite Name is duplicated.

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. 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. 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. 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.

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. 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. 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; 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: 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. 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.

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