Firmware update testing method and apparatus, testing device, and storage medium

Abstract

Embodiments of the present application provide a firmware update testing method and device, testing equipment and a storage medium, and relate to the technical field of testing. A partition table of a start disk is acquired according to an Android version type of the testing equipment, and a to-be-replaced partition is determined from the partition table. A partition position and partition data of the to-be-replaced partition are replaced by firmware position and firmware data of to-be-updated firmware. The Android system of the testing equipment is controlled to start to an LK stage, attribute information of a to-be-tested disk is acquired, and firmware data is acquired according to the firmware position. A test command is constructed according to the firmware data, and firmware update testing is performed on the to-be-tested disk according to the test command and the attribute information. Since the testing equipment can perform single-threaded operation in the Android LK state, an independent testing environment can be provided for firmware update testing, thereby reducing the influence of the system of the testing equipment on firmware update testing and improving the accuracy of the testing result.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of testing, in particular to a firmware update testing method and device, testing equipment and a storage medium. BACKGROUND

[0002] At present, firmware update testing for storage devices generally needs to be performed at the system level of testing equipment, for example, FFU (Field Firmware Update) testing for UFS (Universal Flash Storage) devices. This approach may affect the accuracy of test results due to the influence of the system of testing equipment on firmware update testing. SUMMARY

[0003] Therefore, the present application aims to provide a firmware update testing method and device, testing equipment and a storage medium to avoid the influence of the system of testing equipment on firmware update testing, thereby improving the accuracy of test results.

[0004] To achieve the above-mentioned purpose, the technical solutions adopted by the embodiments of the present application are as follows:

[0005] In a first aspect, the present application provides a firmware update testing method applied to testing equipment, wherein the testing equipment comprises a start-up disk and a disk to be tested, and the method comprises the following steps:

[0006] obtaining a partition table of the start-up disk according to the Android version type of the testing equipment, and determining a partition to be replaced from the partition table;

[0007] replacing the partition position and partition data of the partition to be replaced with the firmware position and firmware data of firmware to be updated;

[0008] controlling the Android system of the testing equipment to start up to the LK stage, obtaining attribute information of the disk to be tested, and obtaining the firmware data according to the firmware position;

[0009] constructing a test command according to the firmware data, and performing firmware update testing on the disk to be tested according to the test command and the attribute information.

[0010] In an optional implementation, the step of obtaining a partition table of the start-up disk according to the Android version type of the testing equipment, and determining a partition to be replaced from the partition table, comprises:

[0011] determining the partition mode of the start-up disk according to the Android version of the testing equipment, and obtaining the partition table of the start-up disk according to the partition mode;

[0012] determining a to-be-replaced partition from partitions in the partition table that are not used in the LK stage.

[0013] In an optional implementation, the obtaining of the attribute information of the to-be-tested disk and the obtaining of the firmware data according to the firmware position comprises:

[0014] obtaining a firmware update function field of the to-be-tested disk, and determining whether the to-be-tested disk supports a firmware update function according to the firmware update function field;

[0015] if the to-be-tested disk supports the firmware update function, obtaining attribute information of the to-be-tested disk, and obtaining the firmware data according to the firmware position to-be-updated firmware to-be-updated firmware to-be-updated firmware to-be-updated firmware.

[0016] In an optional implementation, the constructing of the test command according to the firmware data and the firmware update test of the to-be-tested disk according to the test command and the attribute information comprises:

[0017] constructing a corresponding firmware update command according to the firmware data, and sending the firmware update command to the to-be-tested disk, so that the to-be-tested disk updates a current firmware of the to-be-tested disk to the to-be-updated firmware according to the firmware update command when the to-be-tested disk receives the firmware update command;

[0018] obtaining first response information of the to-be-tested disk, and determining a test result of the firmware update test according to the attribute information and the first response information to-be-updated firmware to-be-updated firmware to-be-updated firmware to-be-updated firmware to-be-updated firmware to-be-updated firmware.

[0019] In an optional implementation, the attribute information comprises a timeout duration and a first revision level of the current firmware.

[0020] The obtaining of the first response information of the to-be-tested disk and the determining of the test result of the firmware update test according to the attribute information and the first response information comprises:

[0021] if the first response information is obtained within the timeout duration and the first response information indicates that the firmware update command is successful, activating the to-be-updated firmware, obtaining firmware update information of the UFS device, and obtaining a second revision level corresponding to the updated current firmware when the firmware update information indicates that the to-be-updated firmware is activated successfully;

[0022] if the second revision level is different from the first revision level, determining that a test result corresponding to the firmware update test is successful;

[0023] If the response information is not acquired within the timeout duration, or the response information indicates the firmware update command, or the firmware update information indicates that the activation of the firmware to be updated fails, or the second revision level is the same as the first revision level, it is determined that the test result corresponding to the firmware update test is update failure.

[0024] In an optional implementation, the method further comprises:

[0025] constructing an abnormal test command according to the firmware data, and sending the abnormal test command to the disk to be tested;

[0026] acquiring second response information returned by the disk to be tested based on the abnormal test command, and determining a test result corresponding to the abnormal test according to whether the second response information meets preset abnormal processing criteria.

[0027] In an optional implementation, the method further comprises:

[0028] If the test result corresponding to the firmware update test is test success, a success identifier is generated.

[0029] If the test result corresponding to the firmware update test is test failure, a failure identifier is generated, and a failure reason corresponding to the firmware update test is determined according to node print information of a failure node for which it is determined that the test fails.

[0030] In an optional implementation, the firmware to be updated comprises firmware to be upgraded and firmware to be rolled back.

[0031] In a second aspect, the application provides a firmware update testing device applied to a testing device, the testing device comprising a startup disk and a disk to be tested, and the device comprising:

[0032] a replacement module configured to acquire a partition table of the startup disk according to an Android version type of the testing device, and determine a partition to be replaced from the partition table;

[0033] the replacement module is further configured to replace a partition position and partition data of the partition to be replaced with a firmware position and firmware data of firmware to be updated;

[0034] an acquisition module configured to control an Android system of the testing device to start to an LK stage, acquire attribute information of the disk to be tested, and acquire the firmware data according to the firmware position;

[0035] a testing module configured to construct a test command according to the firmware data, and perform firmware update test on the disk to be tested according to the test command and the attribute information.

[0036] In a third aspect, the present application provides a test device, comprising a processor and a memory, wherein the memory stores a computer program capable of being executed by the processor, and the processor can execute the computer program to implement the method according to any one of the preceding embodiments.

[0037] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method according to any one of the preceding embodiments.

[0038] The firmware update test method, device, test device and storage medium provided by the embodiments of the present application, the test device comprises a start-up disk and a to-be-tested disk, the test device can acquire a partition table of the start-up disk according to an Android version type, and determine a to-be-replaced partition from the partition table, replace a partition position and partition data of the to-be-replaced partition with a firmware position and firmware data of to-be-updated firmware, then control an Android system of the test device to start up to an LK (Little Kernel) stage, acquire attribute information of the to-be-tested disk, and acquire firmware data according to the firmware position, so that a test command can be constructed according to the firmware data, and the to-be-tested disk is tested for firmware update according to the test command and the attribute information. Since the test device can perform single-thread operation in the Android LK state, an independent test environment can be provided for firmware update test, so that the influence of the system of the test device on the firmware update test is reduced, and the accuracy of the test result is improved.

[0039] In order to make the above objectives, characteristics and advantages of the present application more apparent, the following will describe preferred embodiments in detail, and the accompanying drawings will be referred to, and the detailed description will be as follows. BRIEF DESCRIPTION OF DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments, and it should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation to the scope, and for those skilled in the art, other related drawings can also be obtained without paying creative labor on the basis of these drawings.

[0041] Figure 1 A test system schematic diagram is shown;

[0042] Figure 2 A block schematic diagram of the test device provided by the embodiments of the present application is shown;

[0043] Figure 3 A flow schematic diagram of the firmware update test method provided by the embodiments of the present application is shown;

[0044] Figure 4A functional module diagram of the firmware update testing device provided in the embodiment of the present application is shown.

[0045] Icon: 10-test equipment; 100-memory; 110-processor; 120-communication module; 20-terminal equipment; 200-replacement module; 210-obtaining module; 220-testing module. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations.

[0047] Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0048] It should be noted that the relational terms such as "first" and "second" and the like are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or device including the element.

[0049] At present, the firmware update test for storage devices generally needs to be performed at the system level of the test equipment, for example, the FFU test for UFS devices. However, this method often has the following defects:

[0050] 1. Since the current firmware update test needs to be performed on the storage device under the condition that the system is running, and multiple background processes often exist when the system is running, the firmware update test for the storage device cannot provide an independent test environment, thereby affecting the normal operation of the test, and further affecting the accuracy of the test result, for example, the test may fail due to interference of the background process.

[0051] In addition, understandably, this approach also makes it difficult to pinpoint the problem. For example, when a test fails, it is difficult to determine whether the failure is due to a problem with the storage device.

[0052] 2. In existing technologies, when conducting firmware update tests, only the test result is often visible, i.e., the test was successful or failed. If the result is a test failure, the specific reason for the failure cannot be determined, i.e., it is impossible to trace the problem to which test stage it occurred in, nor can it be determined whether the firmware update test process was standardized.

[0053] 3. In the existing technology, it is not possible to accurately inject exceptions at each stage to test the storage device for exception handling during firmware update testing, thus resulting in low accuracy of exception testing.

[0054] Based on this, embodiments of this application provide a firmware update testing method, apparatus, testing equipment, and storage medium to solve the above-mentioned problems.

[0055] Specifically, Figure 1 For a schematic diagram of the test system, please refer to [link / reference]. Figure 1 The testing system includes a testing device 10 and a terminal device 20, and the testing device 10 and the terminal device 20 are communicatively connected.

[0056] Optionally, the test device 10 includes a boot disk and a disk to be tested.

[0057] In one possible implementation, the boot disk can be an eMMC (Embedded Multi Media Card), and the disk to be tested refers to a storage device, such as a UFS device.

[0058] Optionally, the test device is equipped with Android LK and may have a test program configured to perform firmware update tests on the disk to be tested.

[0059] Optionally, Android LK provides a set of interfaces and tools related to the Fastboot mode, which can be used to connect the test device and the terminal device via serial port tools by adding a debugging interface in Fastboot.

[0060] Furthermore, in Figure 1 On this basis, Figure 2 For a block diagram of the test device 10 provided in the embodiments of this application, please refer to [link / reference]. Figure 2The test device 10 comprises a memory 100, a processor 110 and a communication module 120. The memory 100, the processor 110 and the communication module 120 are electrically connected with each other directly or indirectly to realize data transmission or interaction. For example, the elements can be electrically connected with each other through one or more communication buses or signal lines.

[0061] The memory 100 is configured to store computer programs or data that can be executed by the processor. The memory 100 can be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM) and the like.

[0062] The processor 110 is configured to read / write the data or computer programs stored in the memory and execute the computer programs to implement the firmware update test method provided in the embodiments of the present application.

[0063] The communication module 120 is configured to establish a communication connection between the test device and other communication terminals through a network or a wired mode such as a USB, a serial port and the like, and is configured to receive and transmit data through the network.

[0064] It should be understood that Figure 2 The structure shown is only a structural schematic diagram of the test device, and the test device can further comprise more or less components than those shown in the drawings or have a different configuration from that shown in the drawings. Figure 2 The components shown in the drawings can be realized in hardware, software or a combination thereof. Figure 2 The components shown in the drawings can be realized in hardware, software or a combination thereof. Figure 2 The components shown in the drawings can be realized in hardware, software or a combination thereof.

[0065] Next, the test device in the above Figure 1 will be taken as an execution subject, and the firmware update test method provided in the embodiments of the present application will be exemplarily introduced in combination with a flowchart.

[0066] Specifically, Figure 3 A flowchart of the firmware update test method provided in the embodiments of the present application is shown in FIG. 2. The method comprises the following steps. Figure 3

[0067] In step S20, a partition table of the start disk is acquired according to the Android version type of the test device, and a to-be-replaced partition is determined from the partition table.​

[0068] Optionally, the partition table is a data structure for managing and defining different areas on the storage device, and the storage area in the test device can be defined.

[0069] Optionally, the data in the partition to be replaced should not be used in the LK stage of the Android system, and replacing it will not affect the firmware update test in the LK stage.

[0070] In step S21, the partition position and partition data of the partition to be replaced are replaced by the firmware position and firmware data of the firmware to be updated.

[0071] In step S22, the Android system of the test device is controlled to start to the LK stage, the attribute information of the test disk is obtained, and the firmware data is obtained according to the firmware position.

[0072] Optionally, the firmware to be updated refers to the firmware used for firmware update test.

[0073] Optionally, replacing the partition position of the partition to be replaced by the firmware position of the firmware to be updated refers to redefining the partition position as the position corresponding to the firmware to be updated in the partition table.

[0074] Optionally, the test device can obtain the attribute information and firmware data by constructing a query instruction.

[0075] It should be noted that the Android LK is a bootloader of the Android system, which is mainly responsible for initializing hardware and loading the main operating system when the device starts.

[0076] In a possible implementation manner, the related system code of the test device can be modified in advance, so that the test device can be controlled to start to the LK stage when it is necessary to test.

[0077] Optionally, in order to facilitate subsequent expansion of firmware update test, the test device can first obtain the attribute information of the test disk and the firmware data of the firmware to be updated.

[0078] In step S23, a test command is constructed according to the firmware data, and the test disk is tested according to the test command and the attribute information.

[0079] In this embodiment, a plurality of test cases can be stored in the test device, and then the terminal device can send a calling instruction to the test device to call the corresponding test case. In this case, the test device can construct a test command according to the called test case and the firmware data of the firmware to be updated, so as to test the test disk.

[0080] Optionally, each test case can correspond to a specific test scenario, such as firmware upgrade test, firmware rollback test, write command exception test, etc.

[0081] In one example, the form of the calling command can be ffu test_a, where a represents the first use case of the firmware update test, for example, ffu test_1 refers to the first use case of the firmware update test.

[0082] In addition, after obtaining the firmware data and attribute information, the test device can also construct the corresponding test command according to the firmware data according to each test case to perform firmware update test on the disk to be tested.

[0083] In the embodiment, the test case can be compiled in the code of the Android LK stage to be called by the test device. The firmware update test method provided in the embodiment can obtain the partition table of the startup disk according to the Android version type, determine the to-be-replaced partition from the partition table, replace the partition position and partition data of the to-be-replaced partition with the firmware position and firmware data of the to-be-updated firmware, and then control the Android system of the test device to start to the LK stage, obtain the attribute information of the disk to be tested, and obtain the firmware data according to the firmware position, so as to construct the test command according to the firmware data, and perform firmware update test on the disk to be tested according to the test command and the attribute information. Since the test device can perform single-thread operation in the Android LK state, an independent test environment can be provided for firmware update test, thereby reducing the influence of the system of the test device on the firmware update test and improving the accuracy of the test result.

[0084] Further, since there is no environmental interference in the LK stage, the complexity of problem positioning can be reduced, and the possibility of test failure caused by environmental interference can be excluded.

[0085] Optionally, the to-be-updated firmware can include to-be-upgraded firmware and to-be-rolled-back firmware.

[0086] It can be understood that the to-be-upgraded firmware can be used for firmware upgrade test on the disk to be tested, and the to-be-rolled-back firmware can be used for firmware rollback test on the disk to be tested.

[0087] In one possible implementation, the Android version type is related to the partition mode of the startup disk. Next, a possible implementation is provided for how to obtain the partition table of the startup disk according to the Android version type of the test device, and determine the to-be-replaced partition from the partition table.

[0088] Specifically, the partition mode of the startup disk can be determined according to the Android platform basic document, and the partition table of the startup disk can be obtained according to the partition mode, and the to-be-replaced partition can be determined from the partition that is not used in the LK stage in the partition table.

[0089] In one example, the Android platform is Android R version, the Android R version partition mode introduces virtual AB partition with partition backup, so the partition table with suffix _ab is used. On this basis, the test device can obtain the partition table of the startup disk to obtain the partition information of the startup disk.

[0090] In this example, the eMMC is the startup disk, and the UFS device is the device to be tested. The partition information of each partition can be obtained in the AB partition table (partition_table_emmc_ab.csv) of the eMMC. Since the firmware to be updated includes the firmware to be upgraded and the firmware to be rolled back, two partitions that are not used in the LK stage can be selected as the replacement partitions.

[0091] In this example, the super partition in the partition table is a virtual partition that contains Android startup image, system image, vendor image and other data, and the userdata partition is a partition used by the Android system to store user data. Since these two partitions are not used in the LK stage, the super partition and the userdata partition can be directly determined as the replacement partitions, and the partition location and the partition data of the super partition and the userdata partition are replaced by the firmware location and the firmware data of the firmware to be upgraded and the firmware location and the firmware data of the firmware to be rolled back, respectively.

[0092] In one possible implementation, the super.img of the super partition can be modified to fw_1.bin to store the data of the firmware to be rolled back, and the userdata.img can be modified to fw_2.bin to store the data of the firmware to be updated.

[0093] Since the original userdata partition uses a file system to store user data, the data type is EXT4, and the fw here is specific data that should use Row data type, so the data type of the userdata partition needs to be modified from EXT4 to Row data.

[0094] After modification, the make lk command is executed again to generate a new scatter loading file, and the firmware location of the firmware to be updated has been stored in the newly generated scatter loading file. Then the firmware to be rolled back and the firmware to be upgraded are named as fw_1.bin and fw_2.bin respectively and placed in the flashing directory, and the newly generated scatter loading file and the firmware file are flashed into the startup disk using the flashing tool, so that the partition location and the partition data of the replacement partition are replaced by the firmware location and the firmware data of the firmware to be updated.

[0095] In another possible implementation, the storage locations of the super partition and the userdata partition in the eMMC can be found in the partition table, a debug interface is added in the Fastboot mode, and the to-be-rolled-back firmware fw_1.bin and the to-be-updated firmware fw_2.bin are transmitted to the test platform through the serial communication function of the serial port tool and written into the corresponding locations of the super and userdata partitions, so as to replace the partition location and the partition data of the to-be-replaced partition with the firmware location and the firmware data of the to-be-updated firmware.

[0096] Optionally, considering that there may be a case that some to-be-tested disks do not support the firmware update function, the test device can exclude this case before obtaining the attribute information and the firmware data for the firmware update test.

[0097] Specifically, the test device can obtain the firmware update function field of the to-be-tested disk, and determine whether the to-be-tested disk supports the firmware update function according to the firmware update function field.

[0098] In this embodiment, if the to-be-tested disk supports the firmware update function, the test device can obtain the attribute information of the to-be-tested disk, and obtain the firmware data according to the firmware location.

[0099] Optionally, the test device can obtain the firmware update function field of the to-be-tested disk by constructing a first query command, and determine whether the to-be-tested disk supports the firmware update function according to whether a fixed bit of the field is a preset value.

[0100] In this embodiment, if the to-be-tested disk does not support the firmware update function, the firmware update test is stopped.

[0101] In a possible implementation, the test command can include a firmware update command and an exception test command, where the firmware update command is used for normal test of firmware update of the to-be-tested disk, including whether the to-be-tested disk can normally perform firmware upgrade and firmware rollback, and the exception test command is used for abnormal test of firmware update of the to-be-tested disk, including whether the to-be-tested disk can correctly process an abnormal command.

[0102] Next, for a normal test scenario, how to construct a test command according to firmware data, and how to perform firmware update test on a to-be-tested disk according to the test command and attribute information are provided.

[0103] Specifically, the testing device can construct a corresponding firmware update command according to the firmware data, and send the firmware update command to the to-be-tested disk, so that the to-be-tested disk updates the current firmware of the to-be-tested disk to the to-be-updated firmware according to the firmware update command upon receiving the firmware update command, and then the first response information of the to-be-tested disk can be acquired, and the test result of the firmware update test can be determined according to the attribute information and the first response information.

[0104] Optionally, the testing device can construct the firmware update command according to the corresponding firmware data according to a specific test case.

[0105] In one example, if the test case is a test case corresponding to a firmware upgrade test, the testing device can construct a firmware update command according to firmware data corresponding to the to-be-upgraded firmware.

[0106] Optionally, since the first response information can represent whether the firmware update command is sent successfully and the execution of the test command by the to-be-tested disk after the sending is successful, the testing device can determine the test result corresponding to the target firmware update test in combination with the first response information.

[0107] Optionally, the testing device can send the test result to the terminal device for the user to view after determining the test result.

[0108] Optionally, the attribute information can include a timeout duration and a first revision level of the current firmware.

[0109] Next, a possible implementation manner for how to acquire the first response information of the to-be-tested disk and determine the test result of the firmware update test according to the attribute information and the first response information is provided.

[0110] In this embodiment, if the testing device acquires the first response information within the timeout duration and the first response information represents that the to-be-updated firmware update command is successful, the to-be-updated firmware is activated, firmware update information of the UFS device is acquired, and a second revision level corresponding to the to-be-updated firmware is acquired if the firmware update information represents that the to-be-updated firmware is activated successfully.

[0111] In this embodiment, if the testing device receives the first response information within the timeout duration, it can be determined that the firmware update command is sent successfully, and if the first response information includes a success identifier such as "GOOD", it indicates that the firmware update command is executed successfully, at which time the to-be-updated firmware can be activated.

[0112] Optionally, the testing device can activate the to-be-updated firmware by means of hardware reset or restart.

[0113] In the embodiment, the test device can construct a query command to obtain the firmware update information of the to-be-tested disk after the to-be-updated firmware is activated, so as to determine whether the to-be-updated firmware is activated successfully according to the firmware update information.

[0114] Optionally, the test device can determine whether the to-be-updated firmware is activated successfully according to whether the firmware update information is a preset activation success identifier.

[0115] In a possible implementation, the activation success identifier can be 1.

[0116] Optionally, considering that there can be a case that the firmware data of the to-be-updated firmware obtained by the test device is incorrect, thereby causing incorrect firmware update, for example, the updated firmware is consistent with the firmware before the update, it is further needed to determine whether the revision level of the firmware is changed before and after the firmware update.

[0117] In the embodiment, the test device can further construct a query command to obtain a second revision level corresponding to the updated current firmware when it is determined that the to-be-updated firmware is activated successfully, and compare the second revision level with the first revision level. It can be understood that if the second revision level is different from the first revision level, it can be determined that the test result corresponding to the firmware update test is successful update.

[0118] Optionally, if the test device does not obtain the first response information within the timeout duration, or the first response information indicates that the to-be-updated firmware update command fails, or the firmware update information indicates that the to-be-updated firmware fails to be activated, or the second revision level is the same as the first revision level, it can be determined that the test result corresponding to the firmware update test is failed update.

[0119] Optionally, if the test device does not receive the first response information within the timeout duration, it indicates that the firmware update command fails to be sent, and thus it can be determined that the firmware update test fails, and the node printing information is “command timeout”.

[0120] Optionally, if the first response information indicates that the firmware update fails, the node printing information can be the first response information.

[0121] Optionally, if the firmware update information indicates that the to-be-updated firmware fails to be activated, the node printing information can be the firmware update information.

[0122] Optionally, if the second revision level is the same as the first revision level, it indicates that the update is incorrect, and the node printing information can be the second revision level and the first revision level.

[0123] Next, a possible implementation is provided for how to construct a test command according to firmware data and perform firmware update test on a to-be-tested disk according to the test command and attribute information in an abnormal test scenario.

[0124] Specifically, the test device can construct an abnormal test command according to the firmware data, and send the abnormal test command to the to-be-tested disk, acquire second response information returned by the to-be-tested disk based on the abnormal test command, and determine a test result corresponding to the abnormal test according to whether the second response information meets a preset abnormal processing standard.

[0125] It can be understood that, in the abnormal test process, the test device can construct some abnormal commands or make abnormal selections to send to the to-be-tested disk, so as to determine whether the to-be-tested disk can perform correct abnormal processing on the abnormal commands. For example, an abnormal firmware update command is constructed, or an error firmware to be updated is selected, and the like.

[0126] Optionally, the abnormal processing standard can be set in advance and stored in the test device.

[0127] Optionally, the abnormal test command is related to a specific abnormal test content.

[0128] In an example, if the abnormal test case is a test case for a write instruction abnormality, the test device can assemble a command different from firmware data of an actual firmware to be updated and send the command to the to-be-tested disk, for example, a size mismatch or incorrect information, and check whether the to-be-tested disk returns a command failure and indicates a firmware update test failure according to second response information returned by the to-be-tested disk.

[0129] In the example, if the device is dead or does not return a protocol specified value, it can be determined that the abnormal test fails, and at this time, the second response information returned by the to-be-tested disk can be taken as node printing information.

[0130] In the embodiment, the test device can perform abnormal injection on each link of the firmware update test by constructing an abnormal test command, so as to perform accurate abnormal processing test on each link of the firmware update test, and improve the accuracy of the abnormal test.

[0131] In the embodiment, if the test result corresponding to the target firmware update test is test success, a success identifier is generated. Otherwise, if the test result corresponding to the target firmware update test is test failure, a failure identifier is generated, and a failure reason corresponding to the firmware update test is determined according to node printing information corresponding to a failure node at which it is determined that the test fails.

[0132] In the embodiment, if the test result is success, a success identifier can be directly fed back, and if the test result is failure, the test device can output a failure identifier and a failure reason, so as to be viewed by a user.

[0133] Optionally, the failure reason information can be node print information output by a failed test link, and the user can determine the reason for the failure of the firmware update test according to the node print information and a preset storage device standard.

[0134] In addition, the failure reason information can also be the reason for the failure of the FFU determined by the test device according to the node print information and a preset UFS standard, and in this case, the user can directly view the failure reason.

[0135] Optionally, the test device can also send historical information of each link of the firmware update test, such as command parameters of a test command, returned data, and the like, to the terminal device, so as to determine whether the process of the firmware update test conforms to the test specification according to the historical information.

[0136] In the embodiment, since the test device can obtain the failure reason information when the test fails, the user can directly trace back to the test link where the problem occurs according to the failure reason information, and the convenience of locating the specific test problem is improved. In addition, whether the process of the firmware update test conforms to the test specification can also be determined according to the historical information, and therefore the specification of the firmware update test can be ensured.

[0137] In order to perform the corresponding steps in the above-described embodiments and various possible manners, an implementation manner of a firmware update test device is given below, and optionally, the firmware update test device can adopt the device structure of the test device shown in Figure 2 . Further, please refer to Figure 4 , Figure 4 a functional module diagram of a firmware update test device provided by the embodiment of the present application. It should be noted that the firmware update test device provided by the embodiment has the same basic principles and technical effects as the above-described embodiments, and for brief description, the part not mentioned in the embodiment can be referred to the corresponding content in the above-described embodiments. The firmware update test device includes a replacement module 200, an acquisition module 210, and a test module 220.

[0138] The replacement module 200 is configured to obtain a partition table of a start-up disk according to an Android version type of a test device, and determine a to-be-replaced partition from the partition table.

[0139] It can be understood that the replacement module 200 can also be configured to perform the above-described step S20.

[0140] The replacement module 200 is further configured to replace a partition position and partition data of the to-be-replaced partition with a firmware position and firmware data of the to-be-updated firmware.

[0141] It can be understood that the replacement module 200 can also be configured to perform the above-described step S21.

[0142] The obtaining module 210 is configured to control the Android system of the test device to start to the LK stage, obtain attribute information of the to-be-tested disk, and obtain firmware data according to a firmware position.

[0143] It can be understood that the obtaining module 210 can also be configured to perform the step S22.

[0144] The testing module 220 is configured to construct a test command according to the firmware data, and perform firmware update testing on the to-be-tested disk according to the test command and the attribute information.

[0145] It can be understood that the testing module 220 can also be configured to perform the step S23.

[0146] Optionally, the replacing module 200 is further configured to determine a partition mode of the start-up disk according to an Android version of the test device, obtain a partition table of the start-up disk according to the partition mode, and determine a to-be-replaced partition from a partition that is not used in the LK stage in the partition table.

[0147] Optionally, the obtaining module 210 is further configured to obtain a firmware update function field of the to-be-tested disk, determine whether the to-be-tested disk supports a firmware update function according to the firmware update function field, obtain attribute information of the to-be-tested disk if the to-be-tested disk supports the firmware update function, and obtain firmware data according to a firmware position.

[0148] Optionally, the testing module 220 is further configured to construct a corresponding firmware update command according to the firmware data, and send the firmware update command to the to-be-tested disk, so that the to-be-tested disk updates a current firmware of the to-be-tested disk to a to-be-updated firmware according to the firmware update command if the to-be-tested disk receives the firmware update command, obtain first response information of the to-be-tested disk, and determine a test result of the firmware update testing according to the attribute information and the first response information.

[0149] Optionally, the testing module 220 is further configured to activate the to-be-updated firmware if the first response information is obtained within a timeout duration and the first response information indicates that the firmware update command is successful, obtain firmware update information of the to-be-tested disk, and obtain a second revision level corresponding to an updated current firmware if the firmware update information indicates that the to-be-updated firmware is activated successfully, determine that a test result of the firmware update testing is update success if the second revision level is different from a first revision level, and determine that the test result of the firmware update testing is update failure if the first response information is not obtained within the timeout duration, or the first response information indicates that the firmware update command fails, or the firmware update information indicates that the to-be-updated firmware fails to be activated, or the second revision level is the same as the first revision level.

[0150] Optionally, the test module 220 is further configured to construct an exception test command according to the firmware data, and send the exception test command to the disk to be tested; acquire second response information returned by the disk to be tested based on the exception test command, and determine a test result corresponding to the exception test according to whether the second response information meets a preset exception processing standard.

[0151] Optionally, if the test result corresponding to the firmware update test is test success, the test module 220 generates a success identifier; if the test result corresponding to the firmware update test is test failure, the test module 220 generates a failure identifier, and determines a failure reason corresponding to the firmware update test according to node printing information corresponding to a failure node which determines the test failure.

[0152] Optionally, the modules and the required data, program codes and the like thereof can be stored in the memory shown in the form of software or firmware (Firmware) or solidified in an operating system (OS) of the test device, and can be executed by the processor in the test device. Figure 2 Optionally, the modules and the required data, program codes and the like thereof can be stored in the memory shown in the form of software or firmware (Firmware) or solidified in an operating system (OS) of the test device, and can be executed by the processor in the test device. Figure 2

[0153] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the firmware update test method provided by the embodiment of the present application.

[0154] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented by other manners. The device embodiments described above are only schematic, for example, the flowcharts and block diagrams in the drawings show the possible implementation architectures, functions and operations of the devices, methods and computer program products according to the embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logical functions. It should also be noted that, in some alternative implementations, the functions noted in the blocks can occur in different orders from those noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and the combination of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system which executes the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0155] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.​

[0156] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the parts of the technical solutions that essentially contribute to the prior art or the parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0157] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A firmware update test method characterized by comprising: The method is applied to a test device, the test device comprising a start disk and a disk to be tested, and the method comprises: obtaining a partition table of the start disk according to an Android version type of the test device, and determining a partition to be replaced from the partition table; replacing a partition position and partition data of the partition to be replaced with a firmware position and firmware data of firmware to be updated; controlling an Android system of the test device to start to an LK stage, obtaining attribute information of the disk to be tested, and obtaining the firmware data according to the firmware position; constructing a test command according to the firmware data, and performing firmware update testing on the disk to be tested according to the test command and the attribute information.

2. The method of claim 1, wherein, The obtaining of the partition table of the start disk according to the Android version type of the test device, and the determining of the partition to be replaced from the partition table, comprises: determining a partition mode of the start disk according to an Android version of the test device, and obtaining the partition table of the start disk according to the partition mode; determining the partition to be replaced from a partition not applied to the LK stage in the partition table.

3. The method of claim 1, wherein, The obtaining of the attribute information of the disk to be tested, and the obtaining of the firmware data according to the firmware position, comprises: obtaining a firmware update function field of the disk to be tested, and determining whether the disk to be tested supports firmware update function according to the firmware update function field; if the disk to be tested supports firmware update function, obtaining the attribute information of the disk to be tested, and obtaining the firmware data according to the firmware position.

4. The method of claim 1, wherein, The constructing of the test command according to the firmware data, and the performing of firmware update testing on the disk to be tested according to the test command and the attribute information, comprises: constructing a corresponding firmware update command according to the firmware data, and sending the firmware update command to the disk to be tested, so that the disk to be tested updates current firmware of the disk to be tested to the firmware to be updated according to the firmware update command when the disk to be tested receives the firmware update command; obtaining first response information of the disk to be tested, and determining a test result of firmware update testing according to the attribute information and the first response information.

5. The method of claim 4, wherein, The attribute information comprises a timeout duration and a first revision level of the current firmware. The obtaining of the first response information of the disk to be tested, and the determining of the test result of firmware update testing according to the attribute information and the first response information, comprises: if the first response information is obtained within the timeout duration and represents that the firmware update command is successful, activating the firmware to be updated, obtaining firmware update information of the disk to be tested, and obtaining a second revision level corresponding to updated current firmware when the firmware update information represents that the firmware to be updated is activated successfully; if the second revision level is different from the first revision level, determining that a test result corresponding to the firmware update testing is update success. If the first response information is not acquired within the timeout duration, or the first response information indicates that the firmware update command fails, or the firmware update information indicates that the to-be-updated firmware fails to activate, or the second revision level is the same as the first revision level, it is determined that a test result corresponding to the firmware update test is update failure.

6. The method of claim 1, wherein, According to the firmware data, an exception test command is constructed, and the exception test command is sent to the to-be-tested disk. According to the firmware data, an exception test command is constructed, and the exception test command is sent to the to-be-tested disk. According to the second response information, whether a preset exception processing standard is met is determined, and a test result corresponding to the exception test is determined.

7. The method of claim 1, wherein, The method further includes: If the test result corresponding to the firmware update test is test success, a success identifier is generated. If the test result corresponding to the firmware update test is test failure, a failure identifier is generated, and a failure reason corresponding to the firmware update test is determined according to node print information of a failure node corresponding to the test failure.

8. The method according to any one of claims 1 to 7, characterized in that, The to-be-updated firmware includes to-be-upgraded firmware and to-be-rolled-back firmware.

9. A firmware update testing apparatus characterized by comprising: The device is applied to a test device, and the test device includes a start-up disk and a to-be-tested disk. The replacement module is configured to acquire a partition table of the start-up disk according to an Android version type of the test device, and determine a to-be-replaced partition from the partition table. The replacement module is further configured to replace partition position and partition data of the to-be-replaced partition with firmware position and firmware data of the to-be-updated firmware. The acquisition module is configured to control an Android system of the test device to start up to an LK stage, acquire attribute information of the to-be-tested disk, and acquire the firmware data according to the firmware position. The test module is configured to construct a test command according to the firmware data, and perform firmware update test on the to-be-tested disk according to the test command and the attribute information.

10. A test apparatus, characterized by, The computer program is executed by the processor to implement the method in any one of claims 1-8.

11. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method in any one of claims 1-8.

Images