Chip testing automatic archiving method, device and storage medium
By using automated chip testing methods, we can establish a binding between chips and customer profiles, enabling automated test data generation and partition configuration. This solves the problem of cumbersome and time-consuming traditional chip testing, and improves testing efficiency and data accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- AXD (ANXINDA) MEMORY TECH CO LTD
- Filing Date
- 2026-05-11
- Publication Date
- 2026-06-19
AI Technical Summary
Traditional chip testing methods are cumbersome and time-consuming, and are prone to errors in the correspondence between data and chips due to human negligence, making it difficult to meet the needs of large-scale, high-efficiency testing.
By establishing a binding relationship between the storage chip under test and the customer's profile, the system automatically performs interface protocol testing, target disk identification, interface image data generation, and partition configuration, generating data packets associated with the binding relationship and reducing manual operations.
Reduce testing time, ensure the integrity and accuracy of archived data, avoid errors in manual recording and organization, and improve testing efficiency and accuracy.
Smart Images
Figure CN122245396A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of chip testing technology, and specifically to an automatic archiving method, device and storage medium for chip testing. Background Technology
[0002] Chip testing is a crucial step in ensuring the quality of memory chips. With the widespread application of memory chips in consumer electronics, industrial control, automotive electronics and other fields, higher demands are being placed on the efficiency of chip testing.
[0003] Currently, traditional chip testing methods typically include the following process: testers select the corresponding test fixture and test software based on the model of the memory chip under test, execute the corresponding test items, and record the test data; after the test is completed, the testers manually organize the test results and save the test data to a designated location; for scenarios that require partitioning and formatting, the testers also need to manually enter the disk management tool, execute the partition configuration and formatting operations in sequence, and take screenshots of the disk management tool as evidence of the operation.
[0004] However, when using existing testing methods to continuously test multiple memory chips, testers need to frequently perform operations such as chip loading, test script selection, interface screenshots, and data archiving. The process is cumbersome, time-consuming, and prone to errors in the correspondence between data and chips due to human negligence, making it difficult to meet the needs of large-scale, high-efficiency chip testing. Summary of the Invention
[0005] To address the shortcomings of existing technologies, this application provides an automated archiving method, device, and storage medium for chip testing. After establishing a binding relationship between the storage chip under test and its corresponding customer file, the method performs tests on the storage chip under test using its corresponding interface protocol. Based on the information of the storage chip under test, the method automatically identifies and selects the target disk, generates interface image data, and automatically performs partition configuration and formatting operations. The test data, operation records, interface image data, and partition configuration data are packaged into a data packet associated with the binding relationship. When testing multiple storage chips consecutively, there is no need to manually perform tedious operations such as chip loading, interface screenshotting, data archiving, and partition configuration, thereby reducing testing time and ensuring the integrity and accuracy of the archived data.
[0006] To address the above problems, the present invention provides the following technical solution: In a first aspect, embodiments of this application provide an automatic archiving method for chip testing, including: In some implementations, a binding relationship is established between the memory chip under test and the corresponding customer profile; For the memory chip under test, perform tests on its corresponding interface protocol and generate test data and operation records associated with the binding relationship; Identify the target disk corresponding to the storage chip under test, obtain the storage information of the target disk, verify the target disk according to the storage information, automatically select the target disk after the verification is passed, and generate interface image data associated with the binding relationship. Based on the actual available capacity of the storage chip under test, determine the partition parameters and execute the partition configuration to generate partition configuration data; Perform a formatting operation on the configured partition. After formatting, verify the partition result. If the verification passes, package the test data, operation records, interface image data, and partition configuration data into a data package associated with the binding relationship, and store the data package in the customer file. If the verification fails, trigger an exception message.
[0007] In some implementations, establishing a binding relationship between the memory chip under test and the corresponding customer profile includes: Perform permission verification in the test environment; After the verification is passed, the serial number, model and interface type of the memory chip under test are extracted, and the corresponding customer number is obtained. Based on the customer number, determine the corresponding customer file, and match the corresponding test script according to the model and / or interface type; The memory chip under test is bound to the customer file based on the serial number and customer number.
[0008] In some implementations, performing test environment permission verification includes: The hardware configuration information of the test environment and the operation permission information of the operators are verified separately. If any verification fails, the process is terminated and a record of violation is generated.
[0009] In some implementations, the interface protocol includes at least one of the eMMC protocol, SATA protocol, and PCIe protocol; the test includes at least one of basic read / write test, bad block detection, and bad sector scan; the test data includes at least one of total chip capacity, actual usable capacity, read / write speed, number of bad blocks, and whether the test passed.
[0010] In some implementations, a target disk corresponding to the storage chip under test is identified, its storage information is obtained, and the target disk is verified based on the storage information. If the verification passes, the target disk is automatically selected, and interface image data associated with the binding relationship is generated, including: Identify the corresponding target disk based on the device path or drive letter of the storage chip under test; Obtain its storage information and verify whether the storage information matches the model of the storage chip under test; If a match is found, the target disk will be automatically selected as the operation object; Generate interface image data, which includes the target disk's identification information and an image of the current disk management tool.
[0011] In some implementations, after generating the interface image data associated with the binding relationship, the method further includes: Based on the binding relationship, obtain the corresponding customer number and the serial number of the storage chip under test; Determine the corresponding customer file based on the customer number; The interface image data is stored in the customer file according to the preset naming rules, and an operation record is generated, which includes the storage path and storage time information.
[0012] In some implementations, the system automatically enters the partition configuration mode of the disk management tool, determines the partition parameters based on the actual available capacity of the storage chip under test, performs partition configuration, and generates partition configuration data, including: Invoke the disk management tool and automatically enter its partition configuration mode; Based on the actual available capacity of the storage chip under test and the preset partitioning strategy, determine the partitioning parameters, including the number of partitions, the capacity of each partition, the file system type, and the partition alignment method. Based on the partition parameters, the disk partition management interface is invoked to perform partition creation operations on the selected target disk in sequence; If the partitioning operation is successful, the partitioning result is read, and partition configuration data containing the start address, end address, partition identifier, and partition parameters of each partition is generated; if the partitioning operation fails, partition exception information is triggered.
[0013] In some implementations, a formatting operation is performed on the configured partitions. After formatting, the partition results are validated. If the validation passes, the test data, operation records, interface image data, and partition configuration data are packaged into a data packet associated with the binding relationship, and the data packet is stored in the customer file. If the validation fails, an exception message is triggered, including: Perform formatting operations on each partition according to the preset file system type; After formatting, read / write checks are performed on each partition to verify accessibility and data integrity. If the read / write verification passes, the test data, operation records, interface image data, and partition configuration data will be packaged into a data packet associated with the binding relationship, and the data packet will be stored in the customer file. If the read / write verification fails, a verification exception message will be triggered, and the exception partition information will be recorded.
[0014] Secondly, embodiments of this application provide an electronic device, the electronic device comprising: At least one processor; and, A memory that is communicatively connected to at least one processor; wherein, The memory stores instructions that can be executed by at least one processor, which enables the at least one processor to perform an automated documentation method for chip testing as described in the first aspect.
[0015] Thirdly, embodiments of this application provide a computer-readable storage medium storing an executable program, which is executed by a processor to implement the automatic archiving method for chip testing as described in the first aspect.
[0016] This application provides an automated archiving method, device, and storage medium for chip testing. By establishing a binding relationship between the storage chip under test and its corresponding customer file, test data, operation records, interface image data, and partition configuration data are all associated through this binding relationship, facilitating subsequent traceability. Based on this, testing, target disk identification, generation of interface image data, partition configuration, and formatting operations can be completed automatically. Compared to manual operation, this reduces testing time. Furthermore, since all data corresponds to each other through the binding relationship, errors or omissions that may occur during manual recording and organization are reduced. The packaged data packet can be directly used as the archiving data for the storage chip, ensuring the integrity and accuracy of the archiving data. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating the automatic archiving method for chip testing provided in this application embodiment.
[0018] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0019] Figure 3 This is a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation
[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0021] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.
[0022] The automatic archiving method for chip testing provided in this application will be described in detail below with reference to the accompanying drawings.
[0023] Please see Figure 1 , Figure 1 This is a flowchart illustrating the automatic archiving method for chip testing provided in an embodiment of this application. Figure 1 As shown, the automatic archiving method for chip testing includes steps S100 to S500, all of which are executed automatically. The execution entity for steps S100 to S500 in this application can be a test host, which is an electronic device with data processing capabilities and an internal automated test script library containing multiple test scripts. When the test host detects the connection of the storage chip under test, the test scripts are automatically triggered for execution, or the entire subsequent process is automatically executed in response to a single user start command. This ensures that the execution process of steps S100 to S500 requires no manual intervention in configuring parameters or manually classifying data, guaranteeing the efficiency and accuracy of the archiving process.
[0024] Step S100: Establish the binding relationship between the memory chip under test and the corresponding customer file.
[0025] In some embodiments, step S100 includes steps S110 to S140, and the specific steps are as follows: Step S110: Perform a test environment permission verification.
[0026] Specifically, the hardware configuration information of the test environment and the operator's access permissions are verified separately. If any verification fails, the process is terminated and a violation record is generated. This record includes the reason for the verification failure, a timestamp, and the operator's information.
[0027] Step S120: After the verification is passed, extract the serial number, model and interface type from the information of the memory chip under test, and obtain the corresponding customer number.
[0028] Optionally, the information of the storage chip under test can be automatically entered by scanning the chip's barcode with a barcode scanner. After scanning the barcode, the scanner parses it to obtain the barcode string. The barcode string uses a preset encoding rule and includes fields such as serial number, model, interface type, and customer number. When chip access is detected or scanning is completed, the automated test script on the test host automatically extracts the information of each field according to the preset encoding rule and fills it into the interface. The operating system is the basic software running on the test host, such as Windows, Linux, macOS, etc., which is responsible for managing the computer's hardware resources (CPU, memory, disk, peripherals, etc.) and providing a runtime environment and API for upper-layer applications.
[0029] Step S130: Determine the corresponding customer file based on the customer number, and match the corresponding test script according to the model and / or interface type.
[0030] Specifically, each test script in the test script library is associated with at least one applicable model and / or applicable interface type; the test script is searched in the test script library and a matching test script is selected based on the model and / or interface type of the memory chip under test.
[0031] Step S140: Bind the memory chip under test to the customer file according to the serial number and customer number.
[0032] The above technical solution binds the memory chip under test to the customer's profile, and this binding relationship is maintained throughout the entire testing process. This ensures that all subsequently generated test data, operation logs, interface images, and partition configuration data carry or are associated with the chip serial number and customer number from the binding relationship. This guarantees that the test has a unique identifier and is traceable, avoids data confusion during parallel testing of multiple chips, and ensures the accuracy and reliability of the test results.
[0033] Step S200: For the memory chip under test, perform the test of its corresponding interface protocol and generate test data and operation records associated with the binding relationship.
[0034] Specifically, the operating system performs tests on the storage chip under test according to the test script matched in step S130. The test script supports at least two interface protocols, including at least one of eMMC, SATA, and PCIe protocols; the tests include at least one of basic read / write tests, bad block detection, and bad sector scanning; during the test execution, test data is collected and generated in real time, and the test data includes at least one of the following: total chip capacity, actual usable capacity, read / write speed, number of bad blocks, and whether the test passed.
[0035] For the memory chip under test, the system can automatically identify the interface type and execute the corresponding protocol test. During the test, the system automatically records the operation log for each step. The operation log is generated synchronously during the test, and includes the operation step identifier, operation timestamp, operation execution result, operator identifier, and test equipment identifier. All test data and operation logs are associated with the binding relationship established in step S100, that is, each data record carries the serial number and customer number of the memory chip under test to achieve full-process traceability.
[0036] The above technical solution links all test data and operation records to the binding relationship, facilitating subsequent traceability. Furthermore, it enables multi-protocol compatibility testing to be completed on the same testing platform without requiring manual script changes, interface switching, or environment reconfiguration, significantly improving test versatility and efficiency.
[0037] Step S300: Identify the target disk corresponding to the storage chip under test, obtain the storage information of the target disk, verify the target disk according to the storage information, automatically select the target disk after the verification is passed, and generate interface image data associated with the binding relationship.
[0038] In some embodiments, step S300 includes steps S310 to S340, the specific steps of which are as follows: Step S310: The information of the storage chip under test includes the device path and drive letter of the storage chip under test. Based on the device path or drive letter of the storage chip under test, the corresponding target disk is identified.
[0039] Specifically, by obtaining the device paths or drive letters of all disks in the current operating system, the target disk corresponding to the operating system can be identified based on the matching relationship between the chip serial number of the storage chip under test and the disk serial number.
[0040] Specifically, the serial number of the storage chip under test is compared with the serial numbers of each disk one by one. If a disk serial number that is completely consistent with the chip serial number is found, the disk device is identified as the target disk and its device path or drive letter is obtained. If no matching disk serial number is found, an error message is output, and the operator is asked to insert the correct storage chip under test or terminate the process.
[0041] Step S320: Obtain its storage information and verify whether the storage information matches the model of the storage chip under test.
[0042] In some implementations, step S320 includes steps S321 to S325, the specific steps of which are as follows: Step S321: Call the disk access API provided by the operating system to open the device handle of the target disk. The device handle is used to uniquely identify the device object in the operating system kernel corresponding to the target disk.
[0043] Step S322: Send an I / O request to the operating system kernel through the device handle. The I / O request is received by the operating system's storage driver stack and converted into a command that conforms to the target disk interface protocol.
[0044] Specifically, I / O requests include query requests, which are used to obtain device identification information and storage information of the target disk. I / O requests are received by the operating system's storage driver stack and converted into commands conforming to the target disk interface protocol, including query commands.
[0045] Step S323: Send a query command to the target disk to query the storage information of the target disk. The storage information includes at least the actual available capacity of the target disk.
[0046] Step S324: Verify whether the storage information matches the model of the storage chip under test.
[0047] In some implementations, step S324 includes step S3241, the specific steps of which are as follows: Step S3241: Compare the actual available capacity of the disk with the actual available capacity of the storage chip under test. If the difference between the two is within the preset error threshold range, it is determined to be a match. If the difference exceeds the preset error threshold, it is determined to be a mismatch, triggering an exception, terminating the process, or prompting the operator to check.
[0048] Optionally, the verification also includes partition alignment verification, which checks whether the starting sector of each partition is an integer multiple of the physical block size of the storage device.
[0049] Alternatively, the physical block size of the storage device can be queried by calling a function.
[0050] In some implementations, to ensure a unique correspondence between the disk and the chip and to avoid connecting to the wrong device, it is necessary to verify whether the disk's partition layout and partition alignment conform to the specifications. Step S322 further includes: sending an I / O request to the operating system kernel through the device handle. The I / O request also includes a read-type request, which is used to obtain the partition table information of the target disk. The I / O request is received by the operating system's storage driver stack and converted into commands conforming to the target disk interface protocol, including read-type commands.
[0051] Step S323 further includes: sending a read command to the target disk to read the Master Boot Record (MBR) or Globally Unique Partition Table (GPT) of the target disk, and parsing the partition table information from it.
[0052] Step S324 further includes: reading the partition table information of the target disk, and verifying whether the partition layout of the target disk meets the preset conditions based on the partition table information.
[0053] Specifically, the partition table information includes the partition table type, the number of partitions, the size of each partition, and the starting sector of each partition.
[0054] Specifically, the preset conditions include at least one of the following: partition quantity verification, partition type verification, partition size verification, and partition alignment verification. If the preset conditions are met, the system is considered a match; otherwise, it is considered a mismatch, and the process is terminated or the operator is prompted to check.
[0055] Step S330: If a match is found, the target disk is automatically selected as the operation object.
[0056] Optionally, step S324 needs to verify whether the storage information matches the model of the storage chip under test, and whether the partition layout of the target disk meets the preset conditions. Only when both are determined to be a match will the target disk be automatically selected as the operation object.
[0057] Specifically, after automatic selection, the disk number or drive letter of the target disk is also recorded as the object of subsequent partition configuration and formatting operations.
[0058] The above technical solution compares the actual usable capacity of the disk with the actual usable capacity of the chip, and verifies whether the partition layout and partition alignment meet the specifications. This double verification ensures that the disk and the chip are uniquely matched, avoiding connection to the wrong device.
[0059] Step S340: Generate interface image data, which includes the identification information of the target disk and the image of the current disk management tool.
[0060] In some embodiments, step S340 includes steps S341 to S343, the specific steps of which are as follows: Step S341: Call the disk management tool startup command provided by the operating system to open the disk management tool. The disk management tool is used to visually display the information of the target disk and provide an operation interface for subsequent partition configuration and formatting operations.
[0061] Step S342: Call the screenshot API provided by the operating system to capture the window of the current disk management tool and generate interface image data. The screenshot area includes the disk list area and the target disk details area.
[0062] Step S343: Determine the hash value of the interface image data, store the hash value in the operation record, and associate it with the binding relationship.
[0063] The above technical solution enhances the anti-tampering capability of interface image data by determining the hash value. Any modification to the image file will cause the hash value to change. By comparing the stored hash value with the recalculated hash value, it is possible to quickly determine whether the image data has been tampered with.
[0064] In some implementations, step S300 further includes step S350.
[0065] Step S350: Based on the binding relationship, determine the customer profile corresponding to the storage chip under test, and store the interface image data as the initial evidence file in the customer profile.
[0066] In some implementations, step S350 includes steps S351 to S354, the specific steps of which are as follows: Step S351: Based on the binding relationship, obtain the corresponding customer number and the serial number of the memory chip under test.
[0067] Specifically, the customer number and chip serial number are extracted from the binding relationship established in step S100.
[0068] Step S352: Determine the corresponding customer file based on the customer number.
[0069] Step S353: Store the interface image data in the customer file according to the preset naming rules, and generate an operation record. The operation record includes storage path and storage time information.
[0070] Specifically, the generated interface image data is a static screenshot file, and its saved filename contains a binding relationship identifier, which facilitates subsequent traceability and verification.
[0071] Specifically, the testing system automatically generates operation records, which include storage path, storage timestamp, file size, and file hash value. The operation records are then automatically associated and bound to the database.
[0072] The above technical solution ensures that the interface image data is stored immediately after generation, preventing data loss during subsequent partitioning and formatting operations. Even if the process crashes later, the screenshot file is physically present on the hard drive, allowing customers or engineers to manually retrieve it afterward to prove that the disk selection process was correct during testing.
[0073] Step S400: Determine the partition parameters based on the actual available capacity of the storage chip under test and perform partition configuration to generate partition configuration data.
[0074] Specifically, the actual available capacity can be obtained from the test data in step S200.
[0075] In some embodiments, step S400 includes steps S410 to S440, and the specific steps are as follows: Step S410: Invoke the disk management tool and automatically enter its partition configuration mode.
[0076] Specifically, it invokes the disk management tool startup command provided by the operating system. For example, in the Windows operating system, it invokes the diskpart command-line tool and passes in the automation script to automatically enter its partition configuration mode.
[0077] Step S420: Determine the partition parameters based on the actual available capacity of the storage chip under test and the preset partitioning strategy. The partition parameters include the number of partitions, the capacity of each partition, the file system type, and the partition alignment method.
[0078] Specifically, when the storage chip under test is connected to the test host, the test host can obtain the actual usable capacity of the storage chip under test. The test script reads a preset partition policy configuration file, which can be stored in the corresponding directory. This configuration file can be read by a parser to obtain the partition policy. The partition policy includes the allocation mode, the number of partitions, and the partition alignment method. The allocation mode includes equal partitioning, proportional allocation, and specified size allocation. The number of partitions refers to the number of partitions the disk is divided into. The partition alignment method adjusts the starting sector position of each partition to an integer multiple of a certain alignment unit to match the physical sector size or optimal read / write unit of the storage device, thereby avoiding a single I / O operation spanning multiple physical sectors. Specifically, partition alignment methods can include traditional CHS alignment, 4KB alignment, 1MB alignment, etc.
[0079] Specifically, the capacity of each partition is calculated based on the actual available capacity and the number of partitions of the storage chip under test. For example, in equal partitioning mode, the actual available capacity is divided into equal partitions according to the number of partitions. In proportional allocation mode, the actual available capacity is multiplied by the proportional coefficient of each partition according to the preset capacity ratio of each partition to obtain the theoretical capacity of each partition, and then adjusted according to the alignment method. In specified size mode, the capacity of each partition is directly adopted from the user's preset value, and the system does not perform capacity calculation, but it needs to check whether the sum of the capacities of each partition exceeds the actual available capacity; if it exceeds, an exception is triggered; if it does not exceed, the remaining capacity is reserved as unallocated space; then the starting sector position of each partition is determined according to the preset alignment method.
[0080] Specifically, the file system type defines the file system format used when formatting each partition. It can be the default setting for the test host's operating system.
[0081] Step S430: According to the partition parameters, call the disk partition management interface to perform partition creation operations on the selected target disk in sequence.
[0082] Specifically, if the target disk is located in a Windows operating system environment, the diskpart command-line tool is used as the disk partition management interface to generate and execute diskpart scripts to complete the partition creation operation. If the target disk is located in a Linux operating system environment, the parted command-line tool is used as the disk partition management interface to complete the partition creation operation through scripted calls.
[0083] Before calling the disk partition management interface, a corresponding script needs to be generated based on the partition parameters obtained in step S520. The script content should include at least the target disk selection command and the partition creation command.
[0084] Step S440: If the partitioning operation is successful, read the partitioning result and generate partition configuration data containing the start address, end address, partition identifier and partition parameters of each partition; if the partitioning operation fails, trigger partition exception information.
[0085] Specifically, after the automated test script completes execution, it can trigger the operating system to rescan the disk to obtain the partition table information of the current target disk. The automated test script compares the current partition table information with the partition parameters generated in step S420 and generates partition identifiers. If they match, the partitioning is considered successful; otherwise, the partitioning is considered unsuccessful. If the partitioning is successful, partition configuration data containing the start address, end address, partition identifier, and partition parameters of each partition is generated.
[0086] Specifically, the start address of each partition is the starting position of the partition on the disk, represented by a logical block address or byte offset, and the end address is the ending position of the partition on the disk, also represented by a logical block address or byte offset. The partition identifier is used to indicate whether the partition parameters generated in step S420 correspond to the current partition table information. The partition parameters are the current partition table information.
[0087] The above technical solution eliminates the need for manual operation in the disk management interface, enabling partition settings to be completed automatically and improving testing efficiency. Automation of partition configuration is achieved by calling the underlying disk management interface or command-line tools.
[0088] Step S500: Perform a formatting operation on the configured partition. After formatting, verify the partition result. If the verification passes, package the test data, operation records, interface image data, and partition configuration data into a data packet associated with the binding relationship, and store the data packet in the customer file. If the verification fails, trigger an exception message.
[0089] In some embodiments, step S500 includes steps S510 to S540, the specific steps of which are as follows: Step S510: Perform formatting operations on each partition according to the preset file system type.
[0090] Specifically, since the partition created in step S430 only completes the writing of the partition table, the operating system cannot directly perform file read and write operations. In order to enable each partition to realize normal file storage and access functions, and to provide the corresponding file operation path for the read and write verification in the subsequent step S520, the automated test script performs automated formatting operations on each newly created partition in sequence according to the file system type recorded in the partition parameters determined in step S420.
[0091] Specifically, if the test host is running a Windows operating system, the operating system's formatting API or command-line tools are invoked. Command-line tools, such as the format command, perform formatting operations on each partition created in step S400.
[0092] Specifically, when executing each formatting command, the test script simultaneously checks whether each partition has been formatted successfully. If a partition is determined to have failed to format, a formatting exception message is triggered, and the formatting process for the storage chip under test is terminated.
[0093] Step S520: After formatting, perform read / write verification on each partition to verify the accessibility and data integrity of the partition.
[0094] Specifically, a test file is written to each partition, and the written data is read and written to verify the integrity of the partition by comparing the data consistency.
[0095] Step S530: If the read / write verification passes, the test data, operation records, interface image data, and partition configuration data are packaged into a data packet associated with the binding relationship, and the data packet is stored in the customer file.
[0096] Specifically, the interface image data can be obtained in step S350.
[0097] The test script calls the compression library provided by the operating system of the test host to add the above data into a compressed package. The name of the compressed package may include: the serial number of the memory chip under test, the customer file number created in step S100, and the test completion timestamp.
[0098] Specifically, the data packets are stored in the customer file storage area, which is a storage space used to store all customer archive data.
[0099] Step S540: If the read / write verification fails, trigger the verification exception information and record the exception partition information.
[0100] Specifically, if read / write verification fails, the system triggers verification exception information, records the failed partition number, the reason for failure, timestamp, and other information, and terminates the packaging operation.
[0101] The above technical solution uses the generated data packet as a record file for the test of the memory chip under test. This data packet contains test data, operation records, interface image evidence, and partition configuration information, and is bound to the memory chip under test and the customer file for easy traceability later.
[0102] In summary, the automatic archiving method for chip testing provided in this application has the following advantages: 1. Through steps S100 and S200, this application can automatically identify and switch between multiple interface protocols such as eMMC, SATA, and PCIe, and complete multi-protocol compatibility testing on the same test platform without the need for manual script replacement, interface switching, or environment reconfiguration, thus significantly improving test versatility and efficiency.
[0103] 2. This application can accurately locate the target disk by uniquely matching the chip serial number with the disk serial number, avoiding problems such as manual disk selection errors.
[0104] 3. This application uses command line and low-level interface to implement the entire process of partitioning and formatting in the background, which saves efficiency and avoids problems such as human error.
[0105] 4. This application uses a binding relationship throughout the entire process, so that test data, operation records, interface image data, and partition configuration data are all associated through this binding relationship, which facilitates subsequent traceability.
[0106] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 2 As shown, the electronic device 400 includes: one or more processors 410 and a memory 420. Figure 2 Take a processor 410 as an example.
[0107] In some implementations, the processor 410 and the memory 420 may be connected via a bus or other means. Figure 2 Taking the example of a connection between China and Israel via a bus.
[0108] In some implementations, the processor 410 is used to establish a binding relationship between the storage chip under test and the corresponding customer file; for the storage chip under test, it performs tests on its corresponding interface protocol, generates test data and operation records associated with the binding relationship; identifies the target disk corresponding to the storage chip under test, obtains the storage information of the target disk, verifies the target disk according to the storage information, automatically selects the target disk after verification, and generates interface image data associated with the binding relationship; determines partition parameters and performs partition configuration according to the actual available capacity of the storage chip under test, and generates partition configuration data; performs a formatting operation on the configured partition, verifies the partition result after formatting, and if the verification passes, packages the test data, operation records, interface image data, and partition configuration data into a data packet associated with the binding relationship and stores the data packet in the customer file; if the verification fails, it triggers an exception message.
[0109] In some implementations, memory 420 serves as a non-volatile computer-readable storage medium, used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules of the automatic chip testing documentation method in the embodiments of this application. Processor 410 executes various functional applications and data processing of electronic device 400 by running the non-volatile software programs, instructions, and modules stored in memory 420, thereby implementing the automatic chip testing documentation method of the above-described method embodiments.
[0110] In some embodiments, memory 420 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of electronic device 400, etc. Furthermore, memory 420 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 420 may optionally include memory remotely located relative to processor 410, and this remote memory may be connected to the controller via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0111] In some implementations, one or more modules are stored in memory 420. When executed by one or more processors 410, they perform the automatic archiving method for chip testing in any of the above method embodiments, for example, performing the methods described above. Figure 1 The method steps S100 to S500.
[0112] In some implementations, the electronic device can be a chip, such as a data processing unit (DPU) chip used in a data center. Alternatively, the electronic device can be a network interface card that includes a chip and multiple interfaces (such as PCI / PCIE interfaces, UART interfaces, USB interfaces, etc.). Or, the electronic device can be a traditional server, or a server that includes a network interface card or chip. The server includes a host and a data processor. The data processor is used to schedule packets to the host or the data processor itself for processing. The host is used to process the packets scheduled by the data processor.
[0113] Please refer to Figure 3 , Figure 3 This is a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable storage medium 500 stores program code 510, which can be called by a processor to execute the automatic archiving method for chip testing described in the above method embodiments.
[0114] The computer-readable storage medium 500 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium includes a non-volatile computer-readable storage medium. The computer-readable storage medium 500 has storage space for program code that performs any of the method steps of the automated documentation method for chip testing described above. This program code can be read from or written to one or more computer program products. The program code may, for example, be compressed in an appropriate form.
[0115] In summary, this application provides an automatic archiving method, device, and storage medium for chip testing. The automatic archiving method for chip testing includes: establishing a binding relationship between the memory chip under test and the corresponding customer file; For the storage chip under test, the system performs tests on its corresponding interface protocol, generating test data and operation records associated with the binding relationship; identifies the target disk corresponding to the storage chip under test, obtains the storage information of the target disk, verifies the target disk based on the storage information, and automatically selects the target disk after successful verification, generating interface image data associated with the binding relationship; determines partition parameters and performs partition configuration based on the actual available capacity of the storage chip under test, generating partition configuration data; performs formatting operations on the configured partitions, and verifies the partition results after formatting. If the verification passes, the test data, operation records, interface image data, and partition configuration data are packaged into a data packet associated with the binding relationship and stored in the customer file; if the verification fails, an exception message is triggered. This application can automatically complete testing, target disk identification, generation of interface image data, partition configuration, and formatting operations. Compared with manual operation, it reduces testing time. Furthermore, since all data corresponds to each other through binding relationships, it reduces errors or omissions that may occur during manual recording and organization. The packaged data packet can be directly used as archival data for the storage chip, ensuring the integrity and accuracy of the archival data.
[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. An automatic archiving method for chip testing, characterized in that, Includes the following steps: Establish a binding relationship between the memory chip under test and the corresponding customer profile; For the memory chip under test, perform tests on its corresponding interface protocol to generate test data and operation records associated with the binding relationship; Identify the target disk corresponding to the storage chip under test, obtain the storage information of the target disk, verify the target disk according to the storage information, automatically select the target disk after the verification is passed, and generate interface image data associated with the binding relationship. Based on the actual available capacity of the storage chip under test, determine the partition parameters and execute the partition configuration to generate partition configuration data; Perform a formatting operation on the configured partition. After formatting, verify the partition result. If the verification passes, package the test data, the operation record, the interface image data, and the partition configuration data into a data package associated with the binding relationship, and store the data package in the customer file. If the verification fails, an exception message will be triggered.
2. The automatic archiving method for chip testing according to claim 1, characterized in that, The process of establishing the binding relationship between the memory chip under test and the corresponding customer profile includes: Perform permission verification in the test environment; After the verification is passed, the serial number, model and interface type of the memory chip under test are extracted, and the corresponding customer number is obtained. Based on the customer number, determine the corresponding customer file, and match the corresponding test script according to the model and / or interface type; The storage chip under test is bound to the customer file based on the serial number and the customer number.
3. The automatic archiving method for chip testing according to claim 2, characterized in that, The execution test environment permission verification includes: The hardware configuration information of the test environment and the operation permission information of the operators are verified separately. If any verification fails, the process is terminated and a record of violation is generated.
4. The automatic archiving method for chip testing according to claim 1, characterized in that, The The interface protocol includes at least one of the eMMC protocol, SATA protocol, and PCIe protocol; the test includes at least one of the basic read / write test, bad block detection, and bad sector scan; the test data includes at least one of the total chip capacity, actual usable capacity, read / write speed, number of bad blocks, and whether the test passed.
5. The automatic archiving method for chip testing according to claim 1, characterized in that, The process involves identifying the target disk corresponding to the storage chip under test, obtaining the storage information of the target disk, verifying the target disk based on the storage information, automatically selecting the target disk after successful verification, and generating interface image data associated with the binding relationship, including: Identify the corresponding target disk based on the device path or drive letter of the storage chip under test; Obtain its storage information and verify whether the storage information matches the model of the storage chip under test; If a match is found, the target disk will be automatically selected as the operation object; Generate interface image data, which includes the identification information of the target disk and an image of the current disk management tool.
6. The automatic archiving method for chip testing according to claim 1, characterized in that, After generating the interface image data associated with the binding relationship, the method further includes: Based on the binding relationship, obtain the corresponding customer number and the serial number of the storage chip to be tested; Based on the customer number, determine the corresponding customer file; The interface image data is stored in the customer profile according to a preset naming rule, and an operation record is generated, which includes storage path and storage time information.
7. The automatic archiving method for chip testing according to claim 1, characterized in that, Based on the actual available capacity of the storage chip under test, determine the partition parameters and execute partition configuration to generate partition configuration data, including: Invoke the disk management tool and automatically enter its partition configuration mode; Based on the actual available capacity of the storage chip under test and the preset partitioning strategy, the partitioning parameters are determined. The partitioning parameters include the number of partitions, the capacity of each partition, the file system type, and the partition alignment method. According to the partition parameters, the disk partition management interface is invoked to perform partition creation operations on the selected target disk in sequence; If the partitioning operation is successful, the partitioning result is read, and partition configuration data containing the start address, end address, partition identifier, and partition parameters of each partition is generated; if the partitioning operation fails, partitioning exception information is triggered.
8. The automatic archiving method for chip testing according to claim 1, characterized in that, The configured partition is formatted. After formatting, the partition result is verified. If the verification passes, the test data, the operation record, the interface image data, and the partition configuration data are packaged into a data package associated with the binding relationship, and the data package is stored in the customer file. If the verification fails, an exception message will be triggered, including: Perform formatting operations on each partition according to the preset file system type; After formatting, read / write checks are performed on each partition to verify accessibility and data integrity. If the read / write verification passes, the test data, the operation record, the interface image data, and the partition configuration data are packaged into a data packet associated with the binding relationship, and the data packet is stored in the customer file. If the read / write verification fails, a verification exception message will be triggered, and the exception partition information will be recorded.
9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the automatic archiving method for chip testing as described in any one of claims 1-8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the automatic archiving method for chip testing as described in any one of claims 1-8.