Automatic test method for firmware upgrade, storage medium and terminal device

Abstract

The application discloses an automatic testing method for firmware upgrading, a storage medium and a terminal device. The automatic testing method is applied to a terminal device carrying a communication module; the method comprises the following steps: in the process of executing firmware upgrading of the communication module, an interface image of an upgrading prompt interface of the firmware upgrading is automatically captured; the interface image is processed to identify progress indication data of the firmware upgrading; whether the firmware upgrading is successfully executed is judged according to the progress indication data; and in the case that the firmware upgrading is successfully executed, function verification is automatically executed on the communication module. The application improves the objectivity and accuracy of the upgrading state judgment by automatically capturing the interface image of the upgrading prompt interface and processing the interface image. The function verification is automatically executed after the upgrading is successful, the testing efficiency is improved, and the labor cost is reduced.

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology, specifically to an automated testing method, storage medium, and terminal device for firmware upgrades. Background Technology

[0002] Laptops, tablets, and other terminal devices often have built-in communication modules (such as 4G / 5G modules) to enable cellular network connectivity. To ensure module performance, fix vulnerabilities, or adapt to new operators, the firmware of these communication modules needs to be upgraded regularly. In related technologies, monitoring the firmware upgrade process and verifying related functions after the upgrade both rely on manual operation, leading to technical problems such as low testing efficiency and low anomaly reproduction rates. Summary of the Invention

[0003] This application provides an automated testing method, storage medium, and terminal device for firmware upgrades, aiming to automate the testing of communication module firmware upgrades and solve technical problems such as reliance on manual operation, low testing efficiency, and low anomaly reproduction rate in the firmware upgrade process.

[0004] On one hand, this application provides an automated testing method for firmware upgrades, applied to a terminal device equipped with a communication module. The method includes: automatically capturing an interface image of the firmware upgrade prompt interface during the firmware upgrade process performed by the communication module; processing the interface image to identify the progress indication data of the firmware upgrade; determining whether the firmware upgrade was successfully performed based on the progress indication data; and automatically performing functional verification on the communication module if the firmware upgrade was successfully performed.

[0005] In some embodiments, processing the interface image to identify the progress indication data of the firmware upgrade includes: performing binarization preprocessing on the interface image using an image processing algorithm to obtain a binary image; and identifying the progress indication data from the binary image.

[0006] In some embodiments, identifying the progress indication data from the binary image includes: locating a progress bar region in the binary image using a template matching algorithm, and identifying a progress percentage from the progress bar region; wherein the progress indication data includes the progress percentage; and / or, identifying result prompt information from the binary image using optical character recognition technology; wherein the progress indication data includes the result prompt information.

[0007] In some embodiments, before the communication module performs a firmware upgrade, the method further includes: automatically uninstalling the current driver; automatically installing a preset version of the driver package to determine whether to trigger a firmware upgrade.

[0008] In some embodiments, after the automated installation of a preset version of the driver package, the method further includes: determining whether the communication module meets the upgrade triggering conditions; and triggering the communication module to perform a firmware upgrade if the communication module meets the upgrade triggering conditions; wherein the upgrade triggering conditions include at least one of the following: the firmware version contained in the driver package is a whitelisted version; the communication module is in an unregistered network state; the terminal device identifies user identification modules of different operators and determines, based on the identified public terrestrial mobile network, that it needs to upgrade to the firmware version of the corresponding region; the terminal device does not detect a user identification module, and the communication module is in an emergency download mode.

[0009] In some embodiments, after the automated installation of a preset version of the driver package, the method further includes: determining whether the communication module meets the upgrade suppression conditions; if the communication module meets the upgrade suppression conditions, preventing the communication module from performing a firmware upgrade; wherein the upgrade suppression conditions include at least one of the following: the firmware version contained in the driver package is a non-whitelisted version; the firmware version contained in the driver package is consistent with the current firmware version of the communication module; the terminal device does not detect a user identification module, and the communication module is not in emergency download mode; the battery level of the terminal device is lower than a preset battery threshold.

[0010] In some embodiments, before automatically performing functional verification on the communication module, the method further includes: during the firmware upgrade process of the communication module, in response to a restart operation on the terminal device, after the terminal device restarts, re-triggering the firmware upgrade of the communication module.

[0011] In some embodiments, before automatically performing function verification on the communication module, the method further includes: during the firmware upgrade process of the communication module, in response to the disappearance of the emergency download port, controlling the terminal device to enter a sleep state; after the terminal device wakes up from sleep, determining whether the firmware upgrade was successfully performed.

[0012] On the other hand, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in any of the automated testing methods for firmware upgrades provided in embodiments of this application.

[0013] On the other hand, embodiments of this application also provide a computer-readable storage medium storing a computer program or instructions thereon, wherein when the computer program or instructions are executed by a processor, they implement the steps in any of the automated testing methods for firmware upgrades provided in embodiments of this application.

[0014] On the other hand, embodiments of this application also provide a terminal device, which is equipped with a communication module and includes a memory and a processor. The memory stores computer programs or instructions. When the computer programs or instructions are executed by the processor, they implement the steps in any of the automated firmware upgrade testing methods provided in embodiments of this application, so as to achieve automated testing of the firmware upgrade.

[0015] This application discloses an automated testing method, storage medium, and terminal device for firmware upgrades. The automated testing method is applied to a terminal device equipped with a communication module. The method includes: automatically capturing an interface image of the firmware upgrade prompt screen during the firmware upgrade process; processing the interface image to identify firmware upgrade progress indication data; determining whether the firmware upgrade was successful based on the progress indication data; and automatically performing functional verification on the communication module if the firmware upgrade was successful. This application improves the objectivity and accuracy of upgrade status judgment by automatically capturing and analyzing the interface image of the upgrade prompt screen; and improves testing efficiency and reduces labor costs by automatically performing functional verification after a successful upgrade.

[0016] This application's embodiments automatically capture the interface image of the upgrade prompt screen and automatically analyze whether the upgrade was successful, replacing manual visual observation and judgment, thus improving the objectivity and accuracy of upgrade status judgment. Simultaneously, it automatically performs functions such as port checks, version verification, network registration, and dialing verification, freeing testers from repetitive and tedious manual operations. The time consumed in a single test cycle is significantly shortened, improving testing efficiency and reducing labor costs, making it particularly suitable for batch testing of multiple versions and scenarios. Because the upgrade method provided by this application's embodiments is automated, testers can easily write scripts to repeatedly execute various preconditions (such as different SIM cards, different battery levels, different network states, etc.), systematically covering normal and abnormal upgrade scenarios, improving the anomaly reproduction rate, thereby discovering potential defects earlier and improving product quality. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a structural block diagram of a terminal device provided in an embodiment of this application; Figure 2This is a flowchart illustrating an automated testing method for firmware upgrades provided in an embodiment of this application. Figure 3 A schematic diagram of an upgrade prompt interface for firmware upgrade provided in an embodiment of this application; Figure 4 A schematic diagram of another upgrade prompt interface provided in an embodiment of this application; Figure 5 A schematic diagram of another upgrade prompt interface provided in an embodiment of this application; Figure 6 A schematic diagram of another upgrade prompt interface provided in an embodiment of this application; Figure 7 This is a flowchart illustrating another automated testing method for firmware upgrades provided in an embodiment of this application. Detailed Implementation

[0019] 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 skilled in the art without creative effort are within the scope of protection of this application.

[0020] In the following description, specific embodiments of the invention will be illustrated with reference to steps and symbols performed by one or more computers, unless otherwise stated. Therefore, these steps and operations will be referred to several times as being performed by a computer, and computer execution as referred to herein includes operations by a computer processing unit representing electronic signals of data in a structured format. This operation transforms the data or maintains it at a location in the computer's memory system, which can be reconfigured or otherwise alter the operation of the computer in a manner well known to those skilled in the art. The data structure maintained by the data is the physical location of the memory, which has specific characteristics defined by the data format. However, the principles of the invention described above are not intended to be limiting, and those skilled in the art will understand that many of the steps and operations described below can also be implemented in hardware.

[0021] The terms "module" or "unit" as used herein can be considered as software objects executing on the computing system. The various components, modules, engines, and services described herein can be considered as implementations on the computing system. While the apparatus and methods described herein are preferably implemented in software, they can also be implemented in hardware, both of which are within the scope of this invention.

[0022] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when an element is “connected” or “coupled” to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein may include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0023] Laptops, tablets, and other terminal devices typically have built-in communication modules (such as 4G / 5G modules) to enable cellular network connectivity. To ensure module performance, fix vulnerabilities, or adapt to new operators, the firmware of the communication module needs to be upgraded regularly.

[0024] In related technologies, the process for firmware upgrades of terminal devices (taking laptops as an example) with built-in communication modules is as follows: Testers first need to manually download the driver package matching the current device model and communication module model from the server or a designated path. After downloading, testers manually install the driver package onto the laptop under test. The installation process triggers a firmware update for the communication module. During the update, a progress bar window will pop up in the lower right corner of the laptop screen. Testers need to visually observe the progress bar to confirm that the progress has been completed normally and visually identify whether the pop-up window displays "success" or "failure". In addition, the firmware update in this technology requires strict preconditions, such as the laptop's battery level must be greater than 25% and the Subscriber Identity Module (SIM card) must be able to be recognized normally. To verify the robustness of the communication module under various conditions, testers also need to simulate various test scenarios, such as: changing SIM cards from different operators, upgrading without a SIM card, attempting to upgrade when the laptop's battery level is below 25%, and manually restarting or hibernating the computer during the upgrade process. Testers need to repeat the above manual operation process for each scenario.

[0025] The manual operation method in related technologies has the following technical drawbacks: (i) High reliance on manual operation, resulting in low efficiency. With each firmware version iteration, testers need to repeatedly perform all the steps from downloading and installing the driver, visually observing the upgrade process, to manually verifying the module's functionality. A single testing cycle may take several hours, and when multiple versions or multiple scenarios need to be tested, the workload increases exponentially, severely slowing down product development and testing progress.

[0026] (ii) Insufficient test scenario coverage makes it difficult to reproduce abnormal issues. Due to the time and effort required for manual operation, testers can often only sample a few typical scenarios (such as normal upgrades). For abnormal scenarios (such as power outages, restarts, hibernation during upgrades, or boundary conditions like low battery, no SIM card, or switching between different carriers), time and energy constraints make it difficult to systematically cover each one. Insufficient test scenario coverage means many potential defects cannot be discovered during the testing phase, potentially leading to user complaints or quality incidents after the product is released. Even if some abnormal issues occur occasionally, the lack of automated process recording and reproduction capabilities makes it difficult for developers to locate and fix the problems.

[0027] (iii) Manual judgment is subject to subjectivity and the risk of misjudgment. The display of the upgrade progress bar, the recognition of pop-up text, whether the module port is loading normally, and whether the version number is correct all rely on the testers' visual observation and subjective judgment. Long-term repetitive work can easily lead to visual fatigue, which may result in omissions and misjudgments, affecting the accuracy and consistency of test results.

[0028] (iv) Difficulty in anomaly localization and incomplete debugging information. When anomalies occur during upgrade testing (such as upgrade failure, module inability to register networks, etc.), testers can usually only describe the problem based on memory or scattered notes, and cannot provide structured, timestamped, complete logs. Developers often find it difficult to reproduce the problem, leading to a prolonged defect repair cycle.

[0029] Therefore, there is an urgent need for an automated testing method for firmware upgrades that can reduce manual intervention and improve the level of automation and reliability of testing.

[0030] Figure 1 This is a structural block diagram of a terminal device provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The terminal device 10 may be equipped with a communication module 100.

[0031] Terminal device 10 can be any type of smart device, including mobile terminals and terminals with relatively fixed locations. For example, terminal device 10 can be a mobile phone, computer, game console, e-reader, wearable device, smart home device, vehicle, IoT device, etc. Specifically, terminal device 10 can be a desktop terminal or a mobile terminal, such as a mobile phone, tablet computer, or laptop computer.

[0032] The terminal device 10 equipped with the communication module 100 provided in this application embodiment can be a portable computing terminal running a Windows operating system. For example, the terminal device 10 can be a laptop computer equipped with the communication module 100, including various forms such as thin and light laptops, gaming laptops, and business laptops, running mainstream desktop operating systems such as Windows 10 / 11, and possessing a wireless Fidelity (WiFi) communication module and a power management module, supporting power / network working state switching such as sleep, hibernation, and airplane mode.

[0033] Figure 2 This is a flowchart illustrating an automated testing method for firmware upgrades provided in an embodiment of this application. Please refer to [link / reference]. Figure 2 The automated testing method for this firmware upgrade can be applied to Figure 1 The terminal device 10 shown is equipped with a communication module 100. For example, the automated testing method can be provided by... Figure 1 The terminal device 10 with the communication module 100 shown performs this operation. Figure 2 As shown, the automated testing method includes the following steps (steps S210 to S230): Step S210: During the firmware upgrade process of the communication module, automatically capture the interface image of the firmware upgrade prompt interface. When the firmware upgrade of the communication module 100 is triggered, the operating system of the terminal device 10 will typically display an upgrade prompt interface 201 on the screen, such as a pop-up window or a progress bar window, to show the user the current upgrade progress and status. For example, the terminal device 10 uses a laptop computer as an example. Figure 3 This is a schematic diagram of a firmware upgrade prompt interface provided in an embodiment of this application, as shown below. Figure 3 As shown, an upgrade prompt interface 201 is displayed as a pop-up window in the lower right corner of the display window 200 (such as a display screen) of the terminal device 10. The pop-up window displays upgrade progress information and upgrade result information, etc. In this embodiment, the terminal device 10 automatically captures the interface image data of the upgrade prompt interface 201. The capture methods include, but are not limited to: calling the operating system's screenshot application programming interface, or periodically capturing the content of the currently active window through a background service. The capture action does not require user intervention and can be automatically executed in a loop after the upgrade process starts, for example, capturing once every certain time interval (such as 0.5 seconds or 1 second) until the firmware upgrade is completed or exits abnormally. The captured interface image can be saved in memory or temporary storage space for subsequent analysis.

[0034] Step S220: Process the interface image and identify the firmware upgrade progress indicator data. After capturing the interface image of the upgrade prompt interface 201, the terminal device 10 analyzes and processes the interface image data. The progress indicator data may include, but is not limited to, progress bars, text information, etc. Through automated image analysis and processing, the step of manually observing the upgrade pop-up window can be replaced, avoiding human fatigue and misjudgment.

[0035] Step S230: Based on the progress indicator data, determine whether the firmware upgrade was successfully performed. The specific implementation of this determination may include, but is not limited to: identifying whether the progress bar in the progress indicator data has reached 100%, whether keywords indicating completion such as "success" or "Success" appear, or detecting whether the pop-up window contains specific text information such as "upgrade complete".

[0036] If the progress indicator data indicates that the upgrade has not yet been completed (e.g., the progress bar has not reached 100%, or a pop-up window displays "Upgrading in progress"), the terminal device 10 can continue to cycle through steps S210 to S230, that is, continue to capture new images and reprocess and recognize them until the upgrade is successful or an anomaly is detected. If the progress indicator data indicates that the upgrade has been successfully completed, then proceed to step S240.

[0037] Step S240: If the firmware upgrade is successful, automatically perform functional verification on the communication module.

[0038] After confirming that the firmware upgrade has been successful, the terminal device 10 automatically initiates a functional verification process to check whether the upgraded communication module 100 can function properly. Functional verification may include at least one of the following four items: To check the port loading status of communication module 100: Terminal device 10 enumerates network adapter categories in the device manager by calling the device management interface provided by the operating system. Specifically, it can call the `check_module_network_card_loaded` function in the Windows API, passing in the globally unique identifier (GUID) of the network adapter class, to obtain information about all network adapter devices. Then, it iterates through these devices to check if there are any Wireless Wide Area Network (WWAN) network card devices whose hardware ID contains a specific vendor ID (VID) and product ID (PID). If such a device exists, the WWAN network card is considered to be loaded normally. In addition, other functional nodes of communication module 100 can be further checked, such as the Global Navigation Satellite System (GNSS) node. The `get_gps_driver_info` function can be used to query whether there is a device node named "Quectel(R) Location" to confirm that the positioning function port is loaded normally.

[0039] Verifying the firmware upgrade version number: Terminal device 10 can send a version query command to communication module 100 via the AT interface. For example, the `send_at_by_mbim` function can be called to send the AT command `AT+EGMR` through the Mobile Broadband Interface Model (MBIM) channel. Terminal device 10 compares the version number string returned by communication module 100 with the preset target version number. If they match, the version upgrade is considered correct; otherwise, the version verification is considered to have failed.

[0040] Detecting the network registration status of communication module 100: Terminal device 10 can query the network registration status of the module using AT commands. For example, the command AT+QENG="SERVINGCELL" is sent. If communication module 100 successfully registers with the mobile network, the command will return valid serving cell data; if not registered, it will return an error or a null value. Terminal device 10 determines whether the network registration is normal based on the returned result.

[0041] Detecting the dialing status of communication module 100: Terminal device 10 performs an MBIM dialing test to attempt to establish a data connection. For example, a connection request is initiated through the MBIM interface, specifying parameters such as the Access Point Name (APN). After successful dialing, terminal device 10 checks whether a valid IP address has been obtained and can further perform network connectivity tests (e.g., pinging an external server). If dialing is successful and an IP address is obtained, the dialing function is considered normal; otherwise, the dialing is considered abnormal.

[0042] The above verification steps can be automatically executed sequentially by the terminal device 10 without manual intervention. If all selected verification items pass, the firmware upgrade test is deemed successful; if any verification item fails, the error message can be recorded and the test terminated.

[0043] This application embodiment automatically captures the interface image of the upgrade prompt interface 201 and automatically analyzes whether the upgrade was successful, replacing manual visual observation and judgment, thus improving the objectivity and accuracy of upgrade status judgment. Simultaneously, it automatically performs functions such as port checks, version verification, network registration, and dialing verification, freeing testers from repetitive and tedious manual operations. The time consumed in a single test cycle is significantly shortened, improving testing efficiency and reducing labor costs, making it particularly suitable for batch testing of multiple versions and scenarios. Because the upgrade method provided by this application embodiment is automated, testers can easily write scripts to repeatedly execute various preconditions (such as different SIM cards, different battery levels, different network states, etc.), systematically covering normal and abnormal upgrade scenarios, improving the anomaly reproduction rate, thereby discovering potential defects earlier and improving product quality.

[0044] In some embodiments, step S210 (automatically capturing the interface image of the firmware upgrade prompt interface) includes the following steps (steps S211 and S212): Step S211: Move the upgrade prompt interface to the top of the terminal device's display window; Step S212: Capture the upgrade prompt interface to generate an interface image.

[0045] To ensure that the captured interface image is clear and not obstructed by other windows, the terminal device 10 can activate the upgrade prompt interface 201 that pops up during the firmware upgrade process and place it on top of all other windows by calling the window management API provided by the operating system (such as the capture_upgrade_progress_images function). Through these steps, other windows can be prevented from obscuring the upgrade prompt interface 201, thereby ensuring the integrity and accuracy of subsequent screenshots.

[0046] After the upgrade prompt interface 201 is pinned to the top, the terminal device 10 can automatically invoke the screenshot function to capture the visible area of ​​the current upgrade prompt interface 201 and generate a screenshot file (i.e., interface image). For example, the screenshot file can be in bitmap format. The screenshot file can be named in the form of the current timestamp. The interface image can be saved in memory or temporary storage space for subsequent analysis. The capture action can be repeated at preset time intervals (e.g., every 0.5 seconds or 1 second) until the upgrade process ends or an anomaly is detected.

[0047] Terminal device 10 can also automatically invoke image analysis methods to analyze and process the interface images in the screenshot files. For example, the analyze_upgrade_progress_bar function is invoked to iterate and analyze each screenshot file. In some embodiments, step S220 (processing the interface image to identify firmware upgrade progress index data) includes the following steps (steps S221 and S222): Step S221: The interface image is pre-processed using an image processing algorithm to obtain a binary image. In this embodiment, the binarization pre-processing includes grayscale conversion and binarization. For example, the terminal device 10 uses the OpenCV library to first convert the color screenshot into a grayscale image, that is, each pixel retains only the brightness information and removes the color information to reduce the amount of subsequent calculations. Subsequently, an adaptive threshold or fixed threshold algorithm is used to binarize the grayscale image, converting the pixels in the interface image into a binary image with only black (0) and white (255). The binarization pre-processing can enhance the contrast between the progress bar area 203 and the background, making the boundary of the progress bar clearer. This application embodiment does not limit the use of a specific image processing algorithm; any technical means that can extract the information of whether the upgrade was successful or not from the upgrade prompt interface 201 image can be applied here.

[0048] Step S222: Identify the progress indication data from the binary image. In this embodiment, the progress indication data is identified from the binary image after binarization preprocessing. In this embodiment, the progress indication data may include at least one of the following: progress percentage, result prompt information. Through the above steps, the progress indication data can be automatically identified from the interface image for subsequent analysis of whether the firmware upgrade was successful.

[0049] In some embodiments, step S222 may include steps S223 and / or S224: Step S223: Locate the progress bar region in the binary image using a template matching algorithm, and identify the progress percentage from the progress bar region; wherein, the progress indication data includes the progress percentage. Template matching is a technique for finding the region in the image to be searched that best matches a preset template image. In this embodiment, a template image of the appearance of a progress bar (e.g., a typical progress bar rectangle) can be created in advance. The terminal device 10 uses the binary image generated in step S221 as the search image, the progress bar template as the matching kernel, and finds the region in the binary image that best matches the template, i.e., the location of the progress bar, by calculating similarity measures such as the normalized correlation coefficient. After successful localization, the current progress percentage (e.g., 30%, 50%, 100%, etc.) of the progress bar region 203 is further analyzed and calculated. Figures 4 to 6 This is a schematic diagram of another upgrade prompt interface provided in an embodiment of this application. The upgrade prompt interface 201 includes a progress bar area 203. The progress bar area 203 can visually display the current progress percentage.

[0050] Step S224: Identify the result prompt information from the binary image using optical character recognition technology; wherein, the progress indication data includes the result prompt information. For example... Figures 4 to 6 As shown, in the upgrade prompt interface 201, in addition to the progress bar area 203, there is usually also a result prompt information 202, such as text information like "Updating", "Success", "Fail", "Success", and "Failure". The terminal device 10 uses an Optical Character Recognition (OCR) engine to recognize the text in the result prompt information 202 of the upgrade prompt interface 201 and extract keywords representing the upgrade result.

[0051] When the progress percentage identified in step S223 equals 100%, it indicates that the upgrade process has been completed; if the result message 202 identified in step S224 is "success," "successful," or "completed," indicating success, then it can also be determined that the firmware upgrade has been successfully completed. Figure 5 As shown. It should be noted that the progress index data is used to determine whether the firmware upgrade has been successfully performed. In actual use, you can choose to judge based solely on the progress percentage or the result prompt information 202, or you can choose to combine both. This application does not limit this. For example, if the progress percentage does not reach 100%, or the keyword indicates failure (such as "fail", "error", "failure"), then the upgrade is determined to have not been successful or has failed. The terminal device 10 can continue to loop through steps S210 and S220 until timeout or the upgrade is successful. Figure 4 and Figure 6As shown. It should be understood that, Figures 3 to 6 The content displayed in the upgrade prompt interface 201 is only a specific example, and this application does not limit it. In actual use, the text content in the result prompt information 202 can be set as needed, and the display format of the progress bar in the progress bar area 203 can also be set as needed.

[0052] Through the above image processing and recognition process, this application achieves automated and high-precision judgment of upgrade progress and results, replacing manual visual observation.

[0053] In some embodiments, before the communication module 100 performs a firmware upgrade, the automated testing method for the firmware upgrade further includes the following steps (steps S200 and S201): Step S200: Automatically uninstall the current driver; Step S201: Automatically install the preset version of the driver package to determine whether to trigger a firmware upgrade.

[0054] In this embodiment, the terminal device 10, by calling a custom driver management function (e.g., Driver.uninstall_install_driver_and_upgrade()), first automatically obtains the driver information currently being used by the communication module 100, and then automatically uninstalls the old driver (i.e., the current driver) through the operating system's device management interface. After uninstallation, the terminal device 10 downloads a preset version of the driver package from a local server, a network shared path, or a remote repository according to a preset test configuration. After downloading the preset version of the driver package from the specified path, the terminal device 10 initiates automated installation. Installation can be performed silently without user interaction. During the installation process, the driver package will burn the firmware image it contains into the communication module 100. After burning is complete, the communication module 100 will usually automatically restart and trigger the firmware upgrade process. At this point, the firmware version of the communication module 100 has been updated to the preset target version. Through the above steps, a fully automated closed loop from driver uninstallation, download to installation is achieved, without manual intervention.

[0055] In some embodiments, after step S201 (automatically installing a preset version of the driver package) described above, the automated testing method for firmware upgrade further includes the following steps (steps S2001 and S2002): Step S2001: Determine whether the communication module meets the upgrade trigger conditions; Step S2002: If the communication module meets the upgrade triggering conditions, trigger the communication module to perform a firmware upgrade. The upgrade triggering conditions include at least one of the following: the firmware version contained in the driver package is a whitelisted version; the communication module is in an unregistered network state; the terminal device identifies user identification modules of different operators and determines that it needs to be upgraded to the corresponding region's firmware version based on the identified public land mobile network; the terminal device does not detect user identification modules and the communication module is in emergency download mode.

[0056] A whitelist is a pre-defined list of firmware versions that are allowed to be upgraded. For example, testers can add certain verified stable versions to the whitelist, and only these versions are allowed to trigger the firmware upgrade process. The communication module 100 is in an unregistered network state, meaning it is not currently registered to any mobile network. For instance, testers can actively deregister from the network using the AT command AT+COPS=2 to cover test scenarios where upgrading can be triggered without network registration.

[0057] Firmware upgrades support FWSwitch testing. Terminal device 10 identifies SIM cards from different operators and, based on the identified Public Land Mobile Network (PLMN), determines the firmware version required for the corresponding region. This scenario primarily aims to meet the needs of different customer regions by identifying the PLMN of the SIM card to upgrade to the corresponding version. For example, testers can use a custom switching function `switch_simcard_win(simcard_server_ip, sim_id, sim_port)` to identify SIM cards from different operators. When switching to a Japanese operator, communication module 100 identifies the PLMN as a Japanese code and automatically matches and upgrades to the dedicated firmware version for Japan to meet the compliance requirements of the local operator. It should be noted that in this scenario, for SIM cards identified as belonging to non-Japanese operators, the default target version is automatically upgraded.

[0058] The terminal device 10 does not detect a SIM card, and the communication module 100 is in emergency download mode. Emergency download mode (such as QDLoader port mode) typically occurs when the firmware of the communication module 100 is corrupted or enters a forced flashing state. For example, testers can switch the environment to no SIM card using a custom switching function `switch_simcard_win(simcard_server_ip, sim_id, sim_port)`. The absence of a SIM card can be confirmed using AT commands, such as `AT+CPIN?` which returns an error. The custom port mode check function `verify_qdloader_port_available` checks if the communication module 100 is in emergency download mode. Even without a SIM card, this allows the communication module 100 to upgrade to the default version, restoring normal operation of the communication module 100.

[0059] If the communication module 100 meets any of the above upgrade trigger conditions, the terminal device 10 can use a custom firmware upgrade function, such as FirmwareUpdate().upgrade_whitelist_firmware_versions(versionQGMR, search_path), to call a one-click upgrade tool to burn the whitelist version. The burned version is lower than the current version, thereby triggering the Firmware Update firmware upgrade.

[0060] In some embodiments, after step S201 (automatically installing the preset version of the driver package) described above, the automated testing method for firmware upgrade further includes the following steps (steps S2003 and S2004): Step S2003: Determine whether the communication meets the upgrade suppression conditions; Step S2004: If the communication module 100 meets the upgrade suppression conditions, then prevent the communication module 100 from performing a firmware upgrade; wherein, the upgrade suppression conditions include at least one of the following: the firmware version contained in the driver package is a non-whitelisted version; the firmware version contained in the driver package is consistent with the current firmware version of the communication module 100; the terminal device 10 does not detect the user identification module and the communication module 100 is not in emergency download mode; the battery level of the terminal device 10 is lower than a preset battery threshold.

[0061] For non-whitelisted versions, meaning versions not included in the preset allowed upgrade list, upgrades should be blocked to avoid flashing untested firmware onto the module. If the firmware version included in the driver package is the same as the current firmware version of the communication module 100, upgrading is pointless and repeated upgrades should be prevented to avoid unnecessary flashing work.

[0062] Terminal device 10 has not detected a SIM card, and communication module 100 is not in emergency download mode (i.e., normal mode). For example, testers can switch the environment to SIM-free mode using a custom switching function `switch_simcard_win(simcard_server_ip, sim_id, sim_port)`. The absence of a SIM card can be confirmed using AT commands, such as `AT+CPIN?` which returns an error. Firmware upgrades should be prevented in this scenario.

[0063] Firmware updates are blocked when the battery level of terminal device 10 falls below a preset battery threshold. For example, the battery level of the laptop can be controlled to below 25% using a custom function `wait_until_battery_below_threshold(threshold)`, at which point a firmware update will not be triggered. This scenario simulates a low-battery boundary situation to prevent upgrades from being interrupted by power loss during the upgrade process, which could damage the module.

[0064] If at least one of the above upgrade suppression conditions is met, the terminal device 10 will prevent the communication module 100 from performing a firmware upgrade. At this time, although the automated installation step (S201) will still be executed (i.e., the driver package will still be installed), the subsequent firmware upgrade process will not be triggered after installation (i.e., steps S210 to S230 will not proceed). Through the above steps, this embodiment of the application can systematically simulate various scenarios where upgrades should not be performed, verifying whether the module's behavior under abnormal conditions meets expectations.

[0065] In some embodiments, before step S240 (automatically performing functional verification on the communication module), the automated testing method further includes: during the firmware upgrade process of the communication module, in response to the restart operation of the terminal device, after the terminal device restarts, re-triggering the communication module to perform the firmware upgrade.

[0066] During the firmware upgrade process of the communication module 100 (i.e., while steps S210 to S240 are being executed), if a tester or an automated script simulates a system reboot operation of the terminal device 10, the firmware upgrade process will be interrupted. After the terminal device 10 completes the reboot and re-enters the operating system, the automated testing method of this embodiment will automatically detect that the previous upgrade was incomplete and re-trigger the firmware upgrade process of the communication module 100.

[0067] Through the above steps, this application can simulate a real scenario where a user accidentally restarts their computer during the upgrade process, and verify the recovery capabilities of the communication module 100 and the upgrade software under such abnormal interruption.

[0068] In some embodiments, before step S240 (automatically performing functional verification on the communication module), the automated testing method further includes: during the firmware upgrade process of the communication module, in response to the disappearance of the emergency download port, controlling the terminal device to enter a sleep state; after the terminal device wakes up from sleep, determining whether the firmware upgrade was successfully performed.

[0069] During the firmware upgrade process of the communication module 100, the terminal device 10 continuously monitors the port status of the communication module 100 in the device manager. An emergency download port (e.g., the QDLoader port) is a special port status that appears during firmware burning and typically exists briefly in the early stages of the firmware upgrade. When the emergency download port is detected to disappear from the device manager (e.g., within two seconds of disappearing), the automated testing method of this embodiment immediately controls the terminal device 10 to enter a sleep state. The sleep state is maintained for a preset time (e.g., 2 minutes), and then the terminal device 10 is automatically woken up. After the terminal device 10 wakes up from the sleep state, this embodiment immediately checks whether the firmware version of the communication module 100 has been updated to the target version.

[0070] Through the above steps, this application can simulate the extreme scenario where the emergency download port briefly appears and then immediately goes into hibernation during the upgrade process, verifying the stability of the module upgrade process and the data persistence capability.

[0071] In some embodiments, after identifying the progress indication data of the firmware upgrade, the above-mentioned automatic testing method further includes: automatically recording the exception type and outputting a log file containing a timestamp in the event of an exception during firmware upgrade execution; and / or, after the communication module automatically performs verification, the above-mentioned automatic testing method further includes: automatically recording the exception type and outputting a log file containing a timestamp in the event of any failure in functional verification; wherein the exception type includes at least one of the following: driver installation failure exception, whitelist version acquisition exception, whitelist version upgrade failure exception, firmware upgrade triggering exception.

[0072] For example, after recognizing the firmware upgrade progress indicator data in step S230, an upgrade is deemed abnormal if any of the following occurs: the progress bar remains stuck at a certain percentage for an extended period (for example, exceeding a preset timeout threshold, such as 10 minutes); the progress bar reaches 100% but the OCR recognizes keywords such as "fail" or "error" indicating failure; the upgrade interface suddenly disappears without a success message; or an anomaly occurs during interface image processing (such as inability to locate progress bar area 203, OCR engine error, etc.). Once the above anomalies are detected, the terminal device 10 automatically records the type of the current anomaly, such as "firmware upgrade triggered anomaly" or "whitelist version upgrade failed anomaly," and generates a log record containing a timestamp.

[0073] For example, verification failure includes at least one of the following: failure to check port loading status; inconsistency in firmware upgrade version number verification; failure to detect network registration status; failure to detect dialing status. When performing functional verification in step S230, if any of the above verification failures occur, the terminal device 10 will also automatically record the corresponding exception type, such as "driver installation failure exception", "whitelist version acquisition exception", etc., and output a log file containing timestamps.

[0074] Logs can be stored in text files, JSON format, or a structured database. Content includes the exact time the exception occurred (accurate to milliseconds), the exception type, the current upgrade progress percentage, and screenshots of keywords recognized by OCR. The output log files can be saved to a local disk or uploaded to a remote server for later analysis by testers or developers.

[0075] It should be noted that all the above-mentioned test scenarios (including normal triggering scenarios, suppressed triggering scenarios, restart interruption scenarios, hibernation interruption scenarios, etc.) can be implemented through automated scripts. Testers only need to pre-configure the test parameters (such as driver package path, whitelist version list, power threshold, etc.), and the terminal device 10 can automatically and repeatedly execute the complete test process under each scenario, including driver installation, condition judgment, upgrade monitoring, functional verification, and anomaly recording. In this way, the embodiments of this application realize the full automation of firmware upgrade testing, improving test coverage and execution efficiency.

[0076] As a concrete example, Figure 7 A flowchart illustrating another automated testing method for firmware upgrades provided in this application embodiment. The automated testing method includes the following steps: Step S500: Uninstall the old driver and install the current driver; Step S501: Test scenario determination. If the test scenario is any one of the following scenarios one to six, then proceed to step S502; if the test scenario is any one of the following scenarios seven to ten, then proceed to step S509.

[0077] The test scenario for this application embodiment is as follows: Scenario 1: Whitelisted version; that is, the firmware version included in the driver package is a whitelisted version.

[0078] Scenario 2: Unregistered network state; that is, communication module 100 is in an unregistered network state.

[0079] Scenario 3: Switching between different operators; that is, the terminal device 10 identifies the user identification module of different operators, and determines the firmware version that needs to be upgraded to the corresponding region based on the identified public land mobile network.

[0080] Scenario 4: No SIM card and emergency mode; that is, the terminal device 10 does not detect the user identification module, and the communication module 100 is in emergency download mode.

[0081] Scenario 5: Computer restarts during firmware upgrade; that is, during the firmware upgrade process of communication module 100, in response to the restart operation of terminal device 10, after the terminal device 10 restarts, communication module 100 is triggered to perform firmware upgrade again.

[0082] Scenario 6: Computer hibernation during firmware upgrade; that is, during the firmware upgrade process of communication module 100, in response to the disappearance of the emergency download port, control terminal device 10 to enter hibernation state; after terminal device 10 wakes up from hibernation, it is determined whether the firmware upgrade was successfully executed.

[0083] Scenario 7: Non-whitelisted version; that is, the firmware version included in the driver package is a non-whitelisted version.

[0084] Scenario 8: No SIM card; that is, the terminal device 10 does not detect the user identification module, and the communication module 100 is not in emergency download mode.

[0085] Scenario 9: Version consistency; that is, the firmware version contained in the driver package is consistent with the current firmware version of the communication module 100.

[0086] Scenario 10: The laptop battery is below 25%; that is, the battery of terminal device 10 is below the preset battery threshold.

[0087] Step S502: Trigger Firmware Update; Step S503: Upgrade progress bar check; Step S504: Determine if the upgrade progress bar is normal. If normal, proceed to step S505; if abnormal, proceed to step S512 and display the abnormal information.

[0088] Step S505: Functional verification. Functional verification specifically includes at least one of the following steps S506 to S508.

[0089] Step S506: Device successfully identified, network card loaded normally? That is, determine whether the device is successfully identified and whether the WWAN network card is loaded normally. If it is successfully identified and loaded normally, proceed to step S511 and report that the test is normal; if the module cannot be successfully identified or the network card fails to load, proceed to step S512 and display an error message.

[0090] Step S507: Module version number check normal? That is, determine whether the module version number check is normal? If the module version number is normal, proceed to step S511 and report that the test is normal; if the module version number is incorrect, proceed to step S512 and display an error message.

[0091] Step S508: Is network registration and network card dialing normal? That is, determine whether network registration and network card dialing are normal. If network registration is normal and network card dialing is normal, proceed to step S511 and report that the test is normal; if network registration is abnormal or network card dialing is abnormal, proceed to step S512 and display the abnormal information.

[0092] Step S509: Do not trigger a firmware update. Without triggering a firmware upgrade, the upgrade prompt interface 201 will not pop up.

[0093] Step S510: No upgrade progress bar? That is, determine if there is no upgrade progress bar? If there is no upgrade progress bar, proceed to step S511 and the test is normal; if an upgrade progress bar pops up, proceed to step S512 and an error message is displayed.

[0094] Step S511: Test normal.

[0095] Step S512: Test error.

[0096] By following the steps above, coverage testing of at least the ten test scenarios can be achieved. Analysis of the upgrade progress bar determines whether the upgrade was successful. If the upgrade was successful, functional verification is performed, improving testing efficiency and reducing labor costs.

[0097] It should be noted that the names of methods and functions involved in the embodiments of this application do not constitute a limitation on this application, but are only a specific example of this application.

[0098] This application discloses an automated testing method, storage medium, and terminal device 10 for firmware upgrades. The automated testing method is applied to a terminal device 10 equipped with a communication module 100. The method includes: automatically capturing an interface image of the firmware upgrade prompt interface 201 during the firmware upgrade process of the communication module 100; processing the interface image to identify firmware upgrade progress indication data; determining whether the firmware upgrade was successful based on the progress indication data; and automatically performing functional verification on the communication module 100 if the firmware upgrade was successful. This application improves the objectivity and accuracy of upgrade status judgment by automatically capturing and analyzing the interface image of the upgrade prompt interface 201; and improves testing efficiency and reduces labor costs by automatically performing functional verification after a successful upgrade.

[0099] Continue to refer to Figure 1As shown, the terminal device 10 is equipped with a communication module 100, and the terminal device 10 may also include one or more processors. The processor can support the terminal device 10 in implementing the methods described in the preceding method embodiments. The processor can be a general-purpose processor or a special-purpose processor. For example, the processor can be a central processing unit (CPU). Alternatively, the processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0100] The terminal device 10 may also include one or more memories. Computer programs are stored in the memories. The memories may be independent of the processor or integrated into the processor.

[0101] Terminal device 10 may also include a transceiver. The processor can communicate with other devices or chips via the transceiver. For example, the processor can send and receive data with other devices or chips via the transceiver.

[0102] The computer program in the memory can be executed by a processor, causing the processor to perform the steps in any of the above method embodiments provided in the embodiments of this application.

[0103] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0104] Therefore, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, the computer program being loaded by a processor to execute the steps described in the above-described method embodiments of this application. For example, the computer program, when loaded by a processor, can execute the steps in any of the above-described method embodiments provided by this application.

[0105] For details on the implementation of each of the above operations / steps, please refer to the previous examples, which will not be repeated here.

[0106] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0107] Since the computer program stored in the computer-readable storage medium can execute the steps in any of the above method embodiments provided in the embodiments of this application, the beneficial effects that the methods described in any of the above method embodiments can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0108] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The processor of the terminal device 10 reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the terminal device 10 to perform the methods provided in the various optional implementations of the above embodiments.

[0109] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0110] The above provides a detailed description of an automated testing method, storage medium, and terminal device for firmware upgrades provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An automated testing method for firmware upgrades, characterized in that, The method is applied to a terminal device, wherein the terminal device is equipped with a communication module; the method includes: During the firmware upgrade process of the communication module, the interface image of the firmware upgrade prompt interface is automatically captured; The interface image is processed to identify the progress indication data of the firmware upgrade; Based on the progress indication data, determine whether the firmware upgrade was successfully performed; If the firmware upgrade is successful, the communication module will be automatically verified.

2. The method according to claim 1, characterized in that, The process of processing the interface image to identify the firmware upgrade progress indication data includes: The interface image is pre-processed into a binary image by performing a binarization algorithm. Identify the progress indication data from the binary image.

3. The method according to claim 2, characterized in that, The step of identifying the progress indication data from the binary image includes: A template matching algorithm is used to locate the progress bar region in the binary image and identify the progress percentage from the progress bar region; wherein, the progress indication data includes the progress percentage; And / or, Optical character recognition technology is used to identify result prompt information from the binary image; wherein, the progress indication data includes the result prompt information.

4. The method according to claim 1, characterized in that, Before the communication module performs a firmware upgrade, the method further includes: Automatically uninstall the current driver; The system automatically installs a preset version of the driver package to determine whether to trigger a firmware upgrade.

5. The method according to claim 4, characterized in that, After the automated installation of the preset version of the driver package, the method further includes: Determine whether the communication module meets the upgrade trigger conditions; If the communication module meets the upgrade triggering conditions, the communication module will be triggered to perform a firmware upgrade. The upgrade triggering conditions include at least one of the following: The firmware version included in the driver package is a whitelisted version; The communication module is in an unregistered network state; The terminal device identifies user identification modules of different operators and determines, based on the identified public land mobile network, that it needs to be upgraded to the firmware version corresponding to the region. The terminal device did not detect the user identification module, and the communication module was in emergency download mode.

6. The method according to claim 4, characterized in that, After the automated installation of the preset version of the driver package, the method further includes: Determine whether the communication module meets the upgrade suppression condition; If the communication module meets the upgrade suppression condition, prevent the communication module from performing a firmware upgrade; The upgrade suppression condition includes at least one of the following: The firmware version included in the driver package is a non-whitelisted version; The firmware version contained in the driver package is consistent with the current firmware version of the communication module. The terminal device did not detect the user identification module, and the communication module was not in emergency download mode; The terminal device's battery level is lower than a preset battery threshold.

7. The method according to claim 1, characterized in that, Prior to the automatic execution of functional verification, the method further includes: During the firmware upgrade process of the communication module, in response to the restart operation of the terminal device, the firmware upgrade of the communication module is triggered again after the terminal device restarts.

8. The method according to claim 1, characterized in that, Prior to the automatic execution of functional verification, the method further includes: During the firmware upgrade process of the communication module, in response to the disappearance of the emergency download port, the terminal device is controlled to enter a sleep state. After the terminal device wakes up from sleep, it is determined whether the firmware upgrade was successfully performed.

9. A computer-readable storage medium, characterized in that, It stores computer programs or instructions that, when executed by a processor, implement the steps in the automated testing method for firmware upgrades as described in any one of claims 1 to 8.

10. A terminal device, characterized in that, The terminal device is equipped with a communication module. The terminal device includes a memory and a processor. The memory stores computer programs or instructions. When the computer programs or instructions are executed by the processor, the processor performs the steps of the automated testing method for firmware upgrades according to any one of claims 1 to 8, so as to realize automated testing of the firmware upgrade.

Images