Bluetooth device automated testing method, apparatus and storage medium

Abstract

This application relates to the field of automated testing, and provides a method, apparatus, and storage medium for automated testing of Bluetooth devices. The method includes: acquiring a structured test instruction set; pre-encrypting the instruction content in the structured test instruction set to generate a ciphertext instruction file, enabling direct invocation of ciphertext instructions during test execution, eliminating real-time encryption overhead; constructing a unified device driver abstraction layer, encapsulating the communication code of different hardware interface protocols into driver subclasses; sending instruction content to the Bluetooth device under test through the unified device driver abstraction layer and receiving response data, automatically comparing the response data with the expected response mode, and generating a pass or fail result; for multiple Bluetooth devices under test, starting an independent test instance for each device through an operating system-level multi-process mechanism, with each test instance executing the process defined in the preceding steps in parallel.

Description

Technical Field

[0001] This application relates to the field of automated testing, and in particular to an automated testing method, apparatus, and storage medium for Bluetooth devices. Background Technology

[0002] Bluetooth technology, as a short-range wireless communication standard, is widely used in consumer electronics, IoT devices, smart homes, and other fields. As Bluetooth devices become increasingly complex, verifying their functional correctness and stability has become a crucial aspect of product development and quality control. Traditional Bluetooth device testing typically relies on manual operation or simple automated scripts. Testers need to manually connect devices, send commands one by one, and observe responses, which is inefficient and prone to errors.

[0003] In existing technologies, some automated testing solutions attempt to replace manual operations by writing test scripts. However, these solutions generally suffer from the following drawbacks: 1) Test instructions are usually stored and transmitted in plaintext, lacking security protection mechanisms. Especially in scenarios involving sensitive instructions (e.g., firmware upgrades, key configurations, etc.), the content of the instructions is easily stolen or tampered with; 2) The hardware interface protocols of different Bluetooth devices vary greatly. For example, HID (Human Interface Device), UART (Universal Asynchronous Receiver / Transmitter), SPI (Serial Peripheral Interface), etc. Test programs often need to develop communication modules separately for each interface, resulting in high code duplication, high maintenance costs, and difficulty in supporting concurrent testing of multiple devices; 3) When a large number of Bluetooth devices need to be tested in batches, the traditional serial execution method is time-consuming and cannot meet the needs of rapid testing on the production line. Summary of the Invention

[0004] This application provides an automated testing method, apparatus, and storage medium for Bluetooth devices, which improves the security, compatibility, and efficiency of Bluetooth device testing through pre-encryption, abstract driver layer, and parallel multi-processing.

[0005] On the one hand, this application provides an automated testing method for Bluetooth devices, the method comprising:

[0006] Step S1: Obtain a structured test instruction set, which contains multiple instructions, each of which includes at least the instruction content to be sent and the expected response mode;

[0007] Step S2: Pre-encrypt the instruction content in the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption.

[0008] Step S3: Construct a unified device driver abstraction layer, encapsulate the communication code of different hardware interface protocols into driver subclasses, and define an abstract driver interface for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface.

[0009] Step S4: Send instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive response data, automatically compare the response data with the expected response mode, and generate a pass or fail judgment result.

[0010] Step S5: For at least one Bluetooth device under test, when there are multiple Bluetooth devices under test, an independent test instance is started for each device through the operating system-level multi-process mechanism. Each test instance executes the processes defined in steps S1 to S4 in parallel without interfering with each other.

[0011] On the other hand, this application provides an automated testing apparatus for Bluetooth devices, the apparatus comprising:

[0012] The acquisition module is used to acquire a structured test instruction set, which contains multiple instructions, each of which includes at least the instruction content to be sent and the expected response mode.

[0013] The first generation module is used to pre-encrypt the instruction content of the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption.

[0014] The encapsulation module is used to build a unified device driver abstraction layer, which encapsulates the communication code of different hardware interface protocols into driver subclasses and defines an abstract driver interface for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface.

[0015] The second generation module is used to send instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive response data, automatically compare the response data with the expected response mode, and generate a pass or fail judgment result.

[0016] The parallel execution module is used to start an independent test instance for each Bluetooth device under test (at least one device under test) or when there are multiple devices under test, through an operating system-level multi-process mechanism. Each test instance executes the processes defined by the acquisition module, the first generation module, the encapsulation module, and the second generation module in parallel without interfering with each other.

[0017] Thirdly, this application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the technical solution of the Bluetooth device automated testing method described above.

[0018] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the technical solution of the above-described automated testing method for Bluetooth devices.

[0019] As can be seen from the technical solution provided in this application, on the one hand, by pre-encrypting the instruction content in the structured test instruction set to generate a ciphertext instruction file, the ciphertext instructions can be directly called during test execution, avoiding the computational overhead of real-time encryption, while ensuring the security of the instruction content during storage and transmission, effectively preventing the leakage or illegal tampering of sensitive instructions; on the other hand, by constructing a unified device driver abstraction layer, the communication code of different hardware interface protocols is encapsulated into driver subclasses, and an abstract driver interface is defined for test scheduling logic to call, thus achieving decoupling between the test program and the underlying hardware interface. When it is necessary to adapt to a new interface, only the corresponding driver subclass needs to be added. First, without modifying the core testing logic, the system's scalability and code reusability are significantly improved. Second, by automatically comparing response data with the expected response pattern and generating pass / fail results, the test results are judged instantly and objectively, eliminating subjective errors from manual interpretation and improving the accuracy and consistency of the test. Third, by using an operating system-level multi-process mechanism to launch independent test instances for multiple Bluetooth devices under test, each instance executes the complete test process in parallel without interference. This design fully utilizes the computing power of multi-core CPUs, significantly reducing the total time for batch testing, and is particularly suitable for the high-efficiency testing needs in production line environments. In summary, the technical solution of this application improves the security, compatibility, and efficiency of Bluetooth device testing through pre-encryption, abstract driver layer, and parallel multi-process. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0021] Figure 1 This is a flowchart of the automated testing method for Bluetooth devices provided in the embodiments of this application;

[0022] Figure 2 This is a schematic diagram of the structure of the automated testing device for Bluetooth devices provided in the embodiments of this application;

[0023] Figure 3 This is a schematic diagram of the device provided in the embodiments of this application. Detailed Implementation

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

[0025] In this specification, adjectives such as "first" and "second" are used only to distinguish one element or action from another, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be construed as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0026] For ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale.

[0027] Existing technologies have included some automated testing solutions that attempt to replace manual operations by writing test scripts. However, these solutions generally suffer from the following drawbacks: 1) Test commands are typically stored and transmitted in plaintext, lacking security protection mechanisms. This is especially problematic in scenarios involving sensitive commands (e.g., firmware upgrades, key configurations, etc.), where the command content is easily stolen or tampered with; 2) Different Bluetooth devices have significantly different hardware interface protocols (e.g., HID, UART, SPI, etc.), requiring test programs to develop separate communication modules for each interface. This results in high code duplication, high maintenance costs, and difficulty in supporting concurrent testing of multiple devices; 3) When batch testing a large number of Bluetooth devices is required, traditional serial execution methods are time-consuming and cannot meet the needs of rapid testing on production lines. Therefore, there is an urgent need for an automated testing method for Bluetooth devices that balances security, compatibility, and high efficiency.

[0028] To address the aforementioned problems in the prior art, this application proposes an automated testing method for Bluetooth devices, the flowchart of which is attached. Figure 1 As shown, it mainly includes steps S1 to S5, which are detailed below:

[0029] Step S1: Obtain the structured test instruction set, which contains multiple instructions, each of which includes at least the instruction content to be sent and the expected response mode.

[0030] In current Bluetooth device testing, test commands are typically stored as plain text in .bat files, with each command consisting of only a single line of hexadecimal strings, lacking a description of the expected response. Testers must manually consult the device specifications to determine if the response is correct, which is inefficient and prone to errors. Furthermore, the plain text format cannot carry metadata such as the specific timeout or retries for each command, leading to a rigid testing strategy.

[0031] To address the aforementioned issues, this application proposes a structured instruction format: obtaining a structured test instruction set. The structured test instruction set contains multiple instructions, each including at least the instruction content to be sent and the expected response pattern. Here, the structured test instruction set refers to a file stored in JSON Lines format (usually with the .bat.json extension), where each line is an independent JSON object representing a test instruction. Each instruction contains at least two core fields: a `cmd` field to store the instruction content to be sent (usually a hexadecimal string or byte array representation), and an `expect` field to store the expected response pattern. The expected response pattern can be a regular expression or an exact hexadecimal match (e.g., 0xAA55), thus supporting flexible response validation.

[0032] This structured storage not only includes the data to be sent but also the expected response criteria, laying the foundation for subsequent automatic assertions. Furthermore, the JSON format is easily extensible, allowing for the addition of other metadata (e.g., timeout, number of retries), as detailed in subsequent steps.

[0033] Furthermore, the structured test instruction set is stored in JSON Lines format. Each instruction is a JSON object, and the JSON object contains at least a `cmd` field and an `expect` field. The `cmd` field stores the instruction content to be sent, and the `expect` field stores the expected response pattern, which supports exact matching using regular expressions or hexadecimal notation. In practical applications, a typical instruction entry is shown below:

[0034] {"cmd": "0x01 0x02 0x03", "expect": "0x04 0x05", "timeout_ms": 500, "retry": 3}

[0035] In this example, the `cmd` field specifies the three-byte instruction to be sent, the `expect` field specifies the expected two-byte response, and `timeout_ms` and `retry` are optional fields used for fine-grained control over the execution behavior of this instruction. In regular expression matching mode, the `expect` field can be written as `"^ACK.*"` to match any response that begins with "ACK".

[0036] Step S2: Pre-encrypt the instruction content in the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption.

[0037] In existing technologies, the encryption of test commands is performed in real time during test execution. Whenever sat.py needs to send a command, it calls an RSA public-key encryption function to encrypt the plaintext command and then sends the ciphertext to the device. This real-time encryption mode has significant performance drawbacks: the same set of commands contains identical content across multiple test rounds, but the same encryption calculations are repeated with each execution, leading to wasted computing resources and accumulated test latency. This overhead is particularly amplified linearly in batch testing scenarios, severely impacting test throughput. Therefore, this application proposes a command preprocessing mechanism. Specifically, the command content in the structured test command set is pre-encrypted to generate a ciphertext command file, allowing the ciphertext commands in the ciphertext command file to be directly called during test execution, eliminating the real-time encryption overhead. The core idea of ​​this solution is to shift the encryption operation from the "hot path" of test execution to the "cold path" of test preparation. That is, encryption is performed only once during the initial preparation of the instruction set, and the generated ciphertext file is reused in all subsequent tests. This effectively solves the problem in existing technologies where each instruction needs to call the encryption function in real time during test execution, leading to accumulated encryption computational overhead in batch tests and severely slowing down the testing speed. In other words, the above instruction preprocessing mechanism, by shifting the encryption operation from the "hot path" of test execution to the "cold path" of test preparation, ensures that the same instruction set only needs to be encrypted once. All subsequent tests can directly call the ciphertext file, completely eliminating the computational overhead of repeated encryption and significantly improving testing efficiency while maintaining the same level of security.

[0038] To implement this mechanism, this application provides a separate preprocessing tool (e.g., sat_preencrypt.py) that pre-encrypts the instruction content in the structured test instruction set to generate a ciphertext instruction file. The specific technical solution is as follows: the separate preprocessing tool reads the instruction content in the structured test instruction set; it calls the RSA public-key encryption function to encrypt each instruction; and it saves the encryption result as a ciphertext instruction file with the suffix .bat.enc. This ciphertext instruction file is generated once when the instruction set is first prepared and reused in all subsequent tests. Specifically, the preprocessing tool first reads the .bat.json file, iterates through each instruction, and extracts the plaintext instruction content from its cmd field; then it calls the system's existing RSA public-key encryption function (the public key can be obtained from the device configuration or license file) to convert the plaintext into ciphertext; finally, it writes all the ciphertext sequentially into a binary file with the suffix .bat.enc, which is the ciphertext instruction file. This file is managed in conjunction with the device's license file (.lic) and configuration file (.opt) and provided to the test execution phase. The above solution achieves standardization and reusability of encryption operations through independent preprocessing tools, RSA public key encryption, and .bat.enc file format, providing a secure and efficient source of instructions for subsequent testing, and seamlessly integrating with the original system.

[0039] It is worth noting that the pre-encrypted ciphertext file may be copied or tampered with, allowing unauthorized devices to execute the test, posing a security risk. Therefore, a mechanism is needed to ensure that the ciphertext file can only be used by legitimate devices. To ensure security, this application further introduces an association verification mechanism: the RSA public key used in the pre-encryption process is paired with the private key of the target device, and the ciphertext command file is associated with the corresponding device's license file and configuration file using a hash checksum for verification, ensuring that the ciphertext command file can only be correctly decrypted and executed by authorized devices. In the actual implementation, when the preprocessing tool generates the .bat.enc file, it simultaneously calculates the hash value (e.g., SHA-256) of the file and records this hash value along with information such as the device identifier and license number in an association file. During test execution, before loading the ciphertext command file, sat.py first verifies whether the file's hash value matches the association record and checks whether the license file is valid. Execution is only allowed after all verifications pass. In this way, even if the ciphertext file is copied to other devices, it will be rejected due to hash verification failure, thus preventing the misuse of the ciphertext.

[0040] Furthermore, incremental updates to the pre-encryption process can be optimized. Specifically, after the initial generation of the ciphertext instruction file, when partial changes occur to the structured test instruction set, only the changed instruction content is re-encrypted, and the corresponding ciphertext block in the ciphertext instruction file is updated, while a change log is recorded. For example, if a test engineer only modifies the third instruction in the .bat.json file, the preprocessing tool only needs to re-encrypt that instruction, locate the third ciphertext block in the .bat.enc file for overwriting, and record a change log (including timestamp, changed instruction number, old hash, and new hash information). This incremental update method avoids the overhead of full encryption, further improving the efficiency of instruction set maintenance.

[0041] Through the aforementioned pre-encryption process, the ciphertext instructions in the .bat.enc file can be directly read during the subsequent test execution phase (i.e., subsequent step S4), sent to the target device through the device driver abstraction layer, and then decrypted and executed by the device using the corresponding private key. Throughout the entire process, the encryption computation is performed only once during the preprocessing phase, and there is no further encryption overhead during the test execution phase. This significantly reduces the total time required for batch testing while maintaining the same security level (RSA encryption).

[0042] Step S3: Construct a unified device driver abstraction layer, encapsulate the communication code of different hardware interface protocols into driver subclasses, and define an abstract driver interface for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface.

[0043] In existing Bluetooth device testing systems, the communication module is deeply coupled with specific hardware interface libraries. For example, for devices with HID interfaces, the test program directly calls the API of the pywinusb library; for devices with UART interfaces, it directly calls the API of the pyserial library. This tightly coupled design results in the core test scheduling code being filled with conditional branches for different interfaces (e.g., if interface == "HID"). When new interface types need to be added (e.g., SPI, I2C), developers have to deeply modify the core scheduling logic, resulting in highly invasive code, high maintenance costs, and a high risk of introducing regression errors.

[0044] To address the issues of deep coupling between communication modules and specific hardware interface libraries in existing technologies, where the core test scheduling code directly depends on specific interface implementations and requires significant modifications to the core code when new interface types are needed, resulting in low development efficiency and high maintenance costs, this application introduces an object-oriented abstract design pattern: constructing a unified device driver abstraction layer. This layer encapsulates the communication code of different hardware interface protocols into driver subclasses and defines abstract driver interfaces for the test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interfaces. Essentially, this layer is an abstract base class (e.g., named DeviceDriver), which specifies four core interface methods that all hardware interface drivers must implement: open(config) to open a device connection based on configuration parameters, send(data) to send data to the device, receive(imeout) to receive data from the device and support timeouts, and close(config) to close the device connection based on configuration parameters. The core test scheduling code (i.e., the main logic of sat.py) depends only on this abstract base class and is unrelated to the specific hardware interface implementations.

[0045] In this embodiment, the aforementioned unified device driver abstraction layer is implemented by defining an abstract base class `DeviceDriver`. This abstract base class contains at least four core interface methods: `open(config)` to open a device connection based on configuration parameters, `send(data)` to send data to the device, `receive(timeout)` to receive data from the device and support timeout, and `close(config)` to close the device connection based on configuration parameters. Driver subclasses for different hardware interface protocols inherit from and implement this abstract base class. In actual coding, `DeviceDriver` can be defined as a Python abstract base class (ABC), and the `@abstractmethod` decorator can be used to force subclasses to implement these four methods. For example, the `HidDriver` subclass for the HID interface encapsulates the calling logic of the `pywinusb` library, while the `UartDriver` subclass for the UART interface encapsulates the calling logic of the `pyserial` library. When SPI interface support is needed in the future, simply add a new SpiDriver subclass (which can be implemented using the pyftdi library in conjunction with USB bridge chips such as FTDI FT232H) and implement the four interface methods mentioned above. No modification to any core code in sat.py is required.

[0046] Considering that traditional testing systems require manual driver configuration or test process restarts when adding new devices, which cannot adapt to the dynamic scenarios of frequent device plugging and unplugging in production lines, the unified device driver abstraction layer mentioned in the above embodiments also includes a driver registry to achieve an automated plug-and-test experience and improve the flexibility and unattended operation of the testing system. This registry is used to dynamically register and unregister driver subclasses at runtime. When a new Bluetooth device is detected, the corresponding driver subclass is automatically found and instantiated based on the device identifier, without restarting the test process. In this embodiment, the driver registry can be a dictionary data structure, with the key being the device identifier (e.g., a combination of VID / PID or device name) and the value being a reference to the corresponding driver subclass. When the system detects a new device through a device discovery mechanism (e.g., the `sat.py list -s` command), the driver registry automatically matches and instantiates the corresponding driver subclass based on the device identifier, thereby achieving an automated plug-and-test experience. For example, when a HID Bluetooth device is plugged in, the system automatically identifies its VID / PID, finds the `HidDriver` class in the registry and instantiates it, and then it can be used directly for communication.

[0047] Furthermore, the unified device driver abstraction layer in the above embodiment dynamically selects the corresponding driver subclass for instantiation at runtime by reading the interface field value in the configuration file. The configuration file is in .opt format, and its interface field value includes "HID" or "UART". Before test execution, sat.py loads the .opt configuration file, reads the interface field (e.g., interface=HID), and then selects the corresponding driver subclass from the driver registry based on the value of this field, calling its open(config) method to establish a connection. This dynamic selection mechanism based on the configuration file allows the same set of test code to adapt to different types of devices without modification.

[0048] By constructing a unified device driver abstraction layer, this application achieves complete decoupling between test scheduling logic and specific hardware interface protocols. The technical advantages are: when extending to new hardware interface protocols, only one new driver subclass needs to be added, significantly improving development efficiency and system maintainability; simultaneously, the driver registry supports dynamic discovery and instantiation, further enhancing the system's flexibility and automation.

[0049] Step S4: Send the instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive the response data, automatically compare the response data with the expected response mode, and generate a pass or fail result.

[0050] After completing the construction of the driver abstraction layer in step S3, test execution enters the core stage. In existing technologies, the test program is only responsible for sending commands and recording raw logs. The determination of test results relies entirely on manual review of log files afterward, which is inefficient and prone to missed or incorrect judgments. Furthermore, due to the lack of automated timeout control and retry mechanisms, a single communication failure may lead to the entire command being misjudged as a failure, affecting the accuracy of the test.

[0051] To address these issues, this application integrates command sending, response receiving, and automatic assertion into a single, coherent step: a unified device driver abstraction layer sends command content to the Bluetooth device under test, receives response data, and automatically compares the response data with the expected response pattern to generate a pass or fail result. Specifically, after loading the encrypted command file (.bat.enc), sat.py extracts the encrypted commands line by line, sends the encrypted commands to the device using the send(data) method of the instantiated driver subclass (e.g., HidDriver), and then calls the receive(timeout) method to wait for the device's response. Upon receiving the response data, the system compares the response with the corresponding expect field in the structured command set from step S1, automatically determining a PASS or FAIL result, and recording it in the structured test log.

[0052] Specifically, as one embodiment of this application, automatically comparing the response data with the expected response pattern to generate a pass or fail result can be as follows: if the `expect` field of the instruction is defined, then it is checked whether the response arrives within the timeout and whether its content matches the expected response pattern; if the `expect` field of the instruction is not defined, then it is only checked whether a response is received within the timeout; based on the comparison result, a decision result of PASS or FAIL is generated for each instruction. This embodies two decision strategies: when the `expect` field of the instruction exists, the system performs a strict double check—ensuring both that the response arrives within the timeout and that the response content matches the expected pattern (supporting regular expressions or hexadecimal exact matching); when the `expect` field is missing, the system only checks whether a response is returned (i.e., any data received within the timeout), using this as the pass criterion. This flexibility allows test engineers to choose different verification granularities based on the nature of the instruction.

[0053] Because device responses may fail during testing due to interference or delays, a simple one-time timeout judgment can lead to misjudgments; a configurable retry strategy is needed to distinguish between transient and permanent failures. Therefore, Figure 1The example method also introduces a refined timeout and retry mechanism. Step S4 above further includes: setting a unique timeout (timeout_ms) and a maximum number of retries (retry) for each instruction in the structured instruction set; if no response is received within the timeout period or the response is mismatched, the instruction is resent for the maximum number of retries and compared again, until the retry limit is reached, at which point it is considered a failure. For example, if an instruction is set to timeout_ms=1000 and retry=3, the system waits 1 second after the first transmission. If no response is received or the response is mismatched, it is immediately resent and the timer is reset, with a maximum of 3 retries. Only after all 3 retries fail is the instruction marked as FAIL. This mechanism effectively filters out occasional communication jitter and improves the robustness of the test.

[0054] Furthermore, step S4 above may also include: generating structured test logs. Each record in the structured test logs should contain at least the instruction sequence number, sent content, actual response, expected pattern, judgment result, and time consumption information, so that downstream tools can directly parse and analyze it. In actual implementation, after each instruction is executed, the system will assemble the relevant information into a JSON object and append it to a log file (e.g., test_result.jsonl). For example:

[0055] {"seq": 1, "cmd": "0x010203", "response": "0x0405", "expected": "0x0405", "result": "PASS", "elapsed_ms": 120}

[0056] This structured log is easy for subsequent automated analysis tools (such as dashboards or report generators) to parse directly without manual conversion.

[0057] Considering that long-running tests may be interrupted due to license expiration, leading to test task failure or repetitive work, an automated renewal scheme is needed to avoid human intervention. Therefore, before step S4 in the above embodiment, the following can be included: after loading the license file, verifying the validity and expiration date of the license file; if the license is about to expire, automatically triggering a license renewal request during the test, obtaining a temporary extension period by communicating with a remote license server to ensure that the test is not interrupted. In actual deployment, the license file (.lic) usually contains expiration date information. When loading the license, sat.py checks the remaining expiration date. If it finds that the remaining time is less than a preset threshold (e.g., 30 minutes), it automatically sends a renewal request to the remote license server. After verifying the device identity, the server returns a temporary extension period (e.g., an additional 24 hours). The entire renewal process is completed silently in the background, without affecting the ongoing test process, thus ensuring the continuity of long-term batch testing.

[0058] Step S5: For at least one Bluetooth device under test, when there are multiple Bluetooth devices under test, start an independent test instance for each device through the operating system-level multi-process mechanism, and execute the processes defined in steps S1 to S4 in parallel for each test instance.

[0059] In batch testing scenarios, the shortcomings of the traditional serial blocking model are particularly prominent. In existing solutions, sat.py can only test one device at a time, and the next device can only start after the previous one has been tested. The total testing time for multiple devices is the sum of the testing times for each device. Since the CPU is idle while waiting for device I / O responses, this serial mode seriously wastes computing resources, resulting in low production line testing efficiency. In view of this, this application introduces an operating system-level multi-process parallel mechanism, including: for at least one Bluetooth device under test, when there are multiple Bluetooth devices under test, an independent test instance is launched for each device through the operating system-level multi-process mechanism. Each test instance executes the process defined in steps S1 to S4 in parallel without interfering with each other. Here, the operating system-level multi-process mechanism refers to using the process creation function provided by the operating system (e.g., Python's subprocess module or multiprocessing module) to create an independent child process for each device under test. Each child process runs a complete sat.py instance, binds to its own target device, and executes the instruction sequence independently. Since each process has an independent address space and Python interpreter instance, there are no resource sharing conflicts between them, nor are they restricted by the global interpreter lock, thus achieving true parallel execution.

[0060] As one embodiment of this application, launching an independent test instance for each device through an operating system-level multi-process mechanism can be achieved as follows: A top-level scheduling script receives a device list, where each item in the list contains at least the target device's interface identifier, configuration file path, encrypted command file path, and license file path. The scheduling script uses the Python subprocess module to launch an independent `sat.py` subprocess for each device. Each subprocess is bound to its respective target device and outputs the test results to an independent log file. In actual deployment, the top-level scheduling script (e.g., `sat_runner.py`) first reads a device list file (e.g., CSV or JSON format). Each line in this file describes a device under test, including its HID path or serial port number (interface identifier), the corresponding `.opt` configuration file path, the corresponding `.bat.enc` encrypted command file path, and the corresponding `.lic` license file path. Then, the scheduling script iterates through the device list, calling `subprocess.Popen` to launch a `sat.py` subprocess for each item, passing in the corresponding parameters. The output of each child process (including standard output and standard error) is redirected to a separate log file, such as device_001.log, device_002.log, etc., to facilitate subsequent troubleshooting.

[0061] In existing technologies, during multi-process parallel testing, the output of each instance is scattered across independent log files, lacking a unified means of progress monitoring and result aggregation, which is detrimental to managers' understanding of the overall test status. Therefore, in this embodiment, the independent log files output by each test instance are monitored in real time by a top-level scheduling script. The test progress and judgment results of each instance are aggregated to the main process via shared memory or a message queue to generate a global test report. In practical implementation, the top-level scheduling script can start a monitoring thread to periodically scan the log files of each child process, extract the latest progress information and judgment results, and pass them to the main process via shared memory (e.g., multiprocessing.Value) or a message queue (e.g., queue.Queue). After collecting information from all child processes, the main process can dynamically update a global progress panel and generate a comprehensive test report after all child processes have completed, including the pass rate of each device, total time consumption, and details of failure instructions. This real-time monitoring mechanism enables test managers to grasp the overall test status immediately and promptly identify and intervene in abnormal situations.

[0062] By employing the aforementioned multi-process parallel scheduling, this application reduces the total testing time for multiple devices from the sum of the individual device times to the testing time of the slowest device plus a small amount of process scheduling overhead, significantly improving the throughput of batch testing. Simultaneously, the processes do not interfere with each other, maintaining the stability and reliability of the system.

[0063] In actual testing, a series of preparatory tasks need to be completed before the formal execution of the test command, including device discovery, configuration generation, and license generation. These preparatory tasks are prerequisites for the smooth execution of subsequent steps. This application designs a complete device preparation process before step S1 to ensure the correctness and legality of the test environment. That is, before step S1, the following device preparation process is also included: listing all available Bluetooth devices through the device discovery command, from which the user selects the target device; generating a configuration file for the target device, which at least records the interface type and device identifier; and generating a license file for the target device to authorize the test run. Here, the device discovery command refers to the sat.py list -s command, which scans the HID and UART devices currently connected to the system and lists the interface identifier (e.g., HID path or serial port number) and other basic information of each device. After the user selects the target device for this test according to the list, the system generates the corresponding configuration file (.opt format) and license file (.lic format) for it. The configuration file records the interface type (e.g., interface=HID), device identifier (e.g., vid=0x1234, pid=0x5678), and communication parameters (such as baud rate, timeout, etc.). The license file is generated by a dedicated license generation tool (e.g., sat_licgen.py) and contains information such as the device's unique identifier, validity period, and licensing algorithm version to ensure that the device runs tests under licensed conditions.

[0064] Furthermore, the device discovery command, by executing `saty.py list -s`, lists all available HID and UART devices and their interface identifiers. The configuration file is in .opt format, containing an `interface` field to specify the interface type. Based on a pre-defined device template library, the system automatically generates the corresponding configuration and license files, eliminating the need for manual user input. In practice, the system has a built-in device template library that pre-stores configuration templates for common Bluetooth devices (e.g., device name, default communication parameters, interface type, etc.). When a user selects a target device, the system automatically matches the record in the template library based on the device identifier. If a match is successful, the configuration and license files are directly generated without requiring manual parameter input. If a match fails, the system prompts the user to manually enter the necessary information and saves the new device information to the template library for later reuse. This template-based mechanism greatly simplifies device access configuration, making it particularly suitable for the rapid deployment of a large number of identical devices in a production line environment.

[0065] In practical applications, JSON Lines format command files (.bat.json) not only contain the cmd and expect fields, but can also include optional fields such as timeout_ms and retry as needed. For example, a complete command might look like this:

[0066] {"cmd": "0xAABBCCDD", "expect": "^OK\\d{2}$", "timeout_ms": 2000, "retry": 2}

[0067] This command indicates that sending the hexadecimal command 0xAABBCCDD expects a response starting with "OK" followed by two digits, with a timeout of 2 seconds and a maximum of 2 retries on failure. The regular expression syntax supported by the `expect` field follows Python's `re` module specification, while hexadecimal exact matching directly compares byte sequences. This flexibility allows test engineers to choose appropriate matching strategies based on the characteristics of different commands, ensuring both accuracy and development efficiency.

[0068] Furthermore, the preprocessing tool `sat_preencrypt.py` ignores non-instruction fields such as `expect`, `timeout_ms`, and `retry` when reading the `.bat.json` file, extracting only the plaintext instructions from the `cmd` field. During encryption, the system uses the device's RSA public key (obtainable from the license file or configuration file) to encrypt the plaintext of each instruction, generating a fixed-length ciphertext block. The length of the ciphertext block depends on the RSA key length (e.g., 2048-bit RSA encryption results in a ciphertext length of 256 bytes). All ciphertext blocks are concatenated sequentially, and a metadata block is added to the file header, recording the total number of instructions, the ciphertext offset and length of each instruction, and the file hash value. This allows `sat.py` to quickly locate and extract the ciphertext of any instruction when reading the `.bat.enc` file, without needing to sequentially scan the entire file.

[0069] In the above embodiments, the specific implementation of associating the encrypted instruction file with the corresponding device's license file and configuration file using a hash checksum can be as follows: After generating the .bat.enc file, the preprocessing tool calculates the SHA-256 hash value of the file and writes this hash value along with information such as the device identifier, license number, and timestamp into an associated file (e.g., .manifest). During test execution, sat.py first loads the .manifest file and verifies whether the hash value of the current .bat.enc file matches the record; then it verifies the validity of the license file (including signature verification and validity period check); finally, it verifies whether the device identifier matches. Only when all three verifications pass is the test allowed to proceed. This multi-layered verification mechanism effectively prevents the encrypted file from being tampered with or stolen.

[0070] The aforementioned incremental update of the structured test instruction set involves re-encrypting only the changed instruction content and updating the corresponding ciphertext block in the ciphertext instruction file when partial changes occur. The preprocessing tool maintains a version database (e.g., an SQLite file) to record snapshots of each encryption operation. When a change is detected in the .bat.json file, the tool precisely locates the changed instruction line by comparing the differences between the old and new files. Only these changed instructions are re-encrypted, and the corresponding ciphertext block in the .bat.enc file is then overwritten and updated. Simultaneously, the timestamp of this change, the changed instruction number, the old hash value, and the new hash value are recorded in the version database. This incremental update method significantly reduces encryption time in large-scale instruction set scenarios.

[0071] The DriverRegistry in the above embodiment is a global singleton object that internally maintains a dictionary where the keys are interface type strings (e.g., "HID", "UART") and the values ​​are references to the corresponding driver subclasses. The registry provides the `register(interface_type, driver_class)` and `unregister(interface_type)` methods for dynamically adding or removing drivers. When the system detects a new device connection via a device discovery command, the driver registry automatically finds and instantiates the corresponding driver subclass based on the interface type reported by the device. For example, if the new device declares an HID interface, the registry automatically calls the HidDriver constructor, passes in the configuration parameters, and returns a driver instance. The entire process does not require restarting the test process, thus achieving hot-plug support.

[0072] The aforementioned unified device driver abstraction layer dynamically selects the corresponding driver subclass for instantiation at runtime by reading the interface field value in the configuration file. This can be achieved by: sat.py loading the .opt configuration file at startup, reading the value of the interface field (e.g., "HID"), retrieving the corresponding driver subclass from the driver registry, and calling its open(config) method to establish a connection. This mechanism allows the same test code to adapt to devices with different interface types without modification, greatly improving the system's versatility.

[0073] In the aforementioned embodiments, the license renewal function (i.e., obtaining a temporary extension period by communicating with a remote license server) can be handled by a background thread in sat.py. This thread starts at the beginning of the test and checks the remaining validity period of the current license at regular intervals (e.g., 60 seconds). When the remaining validity period is lower than a preset threshold (e.g., 30 minutes), the thread constructs a renewal request, including information such as the device identifier, the current license number, and the request timestamp, and sends it to the remote license server via an HTTPS connection. After verifying the validity of the request, the server returns a new temporary license (usually extended for 24 hours), which includes the new validity period and the server's digital signature. After receiving the new license, sat.py updates its local license file and continues to execute the test. If the server does not respond or verification fails, the thread logs a warning message but does not interrupt the test to ensure its continuity. This automatic renewal mechanism is particularly suitable for large-scale test tasks that need to run continuously for several days, avoiding the problem of unexpected test interruptions due to license expiration.

[0074] From the above appendix Figure 1The example of automated Bluetooth device testing demonstrates two key advantages. First, by pre-encrypting the instruction content in the structured test instruction set to generate ciphertext instruction files, the ciphertext instructions can be directly invoked during test execution, avoiding the computational overhead of real-time encryption. This also ensures the security of the instruction content during storage and transmission, effectively preventing the leakage or unauthorized modification of sensitive instructions. Second, by constructing a unified device driver abstraction layer, the communication code of different hardware interface protocols is encapsulated into driver subclasses, and an abstract driver interface is defined for test scheduling logic to call. This decouples the test program from the underlying hardware interface. When adapting to new interfaces, only the corresponding driver subclass needs to be added. First, without modifying the core testing logic, the system's scalability and code reusability are significantly improved. Second, by automatically comparing response data with the expected response pattern and generating pass / fail results, the test results are judged instantly and objectively, eliminating subjective errors from manual interpretation and improving the accuracy and consistency of the test. Third, by using an operating system-level multi-process mechanism to launch independent test instances for multiple Bluetooth devices under test, each instance executes the complete test process in parallel without interference. This design fully utilizes the computing power of multi-core CPUs, significantly reducing the total time for batch testing, and is particularly suitable for the high-efficiency testing needs in production line environments. In summary, the technical solution of this application improves the security, compatibility, and efficiency of Bluetooth device testing through pre-encryption, abstract driver layer, and parallel multi-process.

[0075] Please see the appendix Figure 2 This application provides an automated testing device for Bluetooth devices, comprising an acquisition module 201, a first generation module 202, an encapsulation module 203, a second generation module 204, and a parallel execution module 205, as detailed below:

[0076] The acquisition module 201 is used to acquire a structured test instruction set, wherein the structured test instruction set contains multiple instructions, and each instruction includes at least the instruction content to be sent and the expected response mode;

[0077] The first generation module 202 is used to pre-encrypt the instruction content of the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption.

[0078] The encapsulation module 203 is used to build a unified device driver abstraction layer, which encapsulates the communication code of different hardware interface protocols into driver subclasses and defines an abstract driver interface for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface.

[0079] The second generation module 204 is used to send instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive response data, automatically compare the response data with the expected response mode, and generate a pass or fail judgment result.

[0080] The parallel execution module 205 is used to start an independent test instance for each Bluetooth device under test when there are multiple Bluetooth devices under test through an operating system-level multi-process mechanism. Each test instance executes the process defined in steps S1 to S4 in parallel without interfering with each other.

[0081] From the above appendix Figure 2 As illustrated by the example of the automated Bluetooth device testing device, on the one hand, by pre-encrypting the instruction content in the structured test instruction set to generate ciphertext instruction files, the ciphertext instructions can be directly called during test execution, avoiding the computational overhead of real-time encryption. This also ensures the security of the instruction content during storage and transmission, effectively preventing the leakage or unauthorized modification of sensitive instructions. On the other hand, by constructing a unified device driver abstraction layer, the communication code of different hardware interface protocols is encapsulated into driver subclasses, and an abstract driver interface is defined for test scheduling logic to call. This decouples the test program from the underlying hardware interface. When adapting to new interfaces, only the corresponding driver subclass needs to be added. First, without modifying the core testing logic, the system's scalability and code reusability are significantly improved. Second, by automatically comparing response data with the expected response pattern and generating pass / fail results, the test results are judged instantly and objectively, eliminating subjective errors from manual interpretation and improving the accuracy and consistency of the test. Third, by using an operating system-level multi-process mechanism to launch independent test instances for multiple Bluetooth devices under test, each instance executes the complete test process in parallel without interference. This design fully utilizes the computing power of multi-core CPUs, significantly reducing the total time for batch testing, and is particularly suitable for the high-efficiency testing needs in production line environments. In summary, the technical solution of this application improves the security, compatibility, and efficiency of Bluetooth device testing through pre-encryption, abstract driver layer, and parallel multi-process.

[0082] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 3 in this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program for an automated testing method for Bluetooth devices. When the processor 30 executes the computer program 32, it implements the steps described in the above-described automated testing method embodiment for Bluetooth devices, for example... Figure 1 Steps S1 to S5 are shown. Alternatively, when processor 30 executes computer program 32, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 2 The functions of the acquisition module 201, the first generation module 202, the encapsulation module 203, the second generation module 204, and the parallel execution module 205 are shown.

[0083] For example, the computer program 32 of the Bluetooth device automated testing method mainly includes: acquiring a structured test instruction set, wherein the structured test instruction set contains multiple instructions, each instruction including at least the instruction content to be sent and the expected response mode; pre-encrypting the instruction content in the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption; constructing a unified device driver abstraction layer, encapsulating the communication code of different hardware interface protocols into driver subclasses, and defining an abstract driver interface for test scheduling logic to call, wherein the unified device driver abstraction layer defines the abstract driver interface; sending instruction content to the Bluetooth device under test through the unified device driver abstraction layer and receiving response data, automatically comparing the response data with the expected response mode, and generating a pass or fail judgment result; for at least one Bluetooth device under test, when there are multiple Bluetooth devices under test, starting an independent test instance for each device through an operating system-level multi-process mechanism, and executing the process defined in the aforementioned steps in parallel without interfering with each other. Computer program 32 can be divided into one or more modules / units, which are stored in memory 31 and executed by processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, describing the execution process of computer program 32 in electronic device 3. For example, computer program 32 can be divided into the functions of an acquisition module 201, a first generation module 202, an encapsulation module 203, a second generation module 204, and a parallel execution module 205 (a module in a virtual device). The specific functions of each module are as follows: Acquisition module 201 is used to acquire a structured test instruction set, wherein the structured test instruction set contains multiple instructions, each including at least the instruction content to be sent and the expected response mode; the first generation module 202 is used to pre-encrypt the instruction content in the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating real-time encryption overhead; the encapsulation module 203 is used to construct a unified device driver abstraction layer, connecting different hardware interfaces... The communication code of the interface protocol is encapsulated into a driver subclass, and an abstract driver interface is defined for test scheduling logic to call. Among them, the unified device driver abstraction layer defines the abstract driver interface. The second generation module 204 is used to send instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive response data, automatically compare the response data with the expected response mode, and generate a pass or fail judgment result. The parallel execution module 205 is used to start an independent test instance for each device through the operating system-level multi-process mechanism when there are multiple Bluetooth devices under test, for at least one Bluetooth device under test. Each test instance executes the process defined by the acquisition module 201, the first generation module 202, the encapsulation module 203, and the second generation module 204 in parallel without interfering with each other.

[0084] Electronic device 3 may include, but is not limited to, processor 30 and memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0085] The processor 30 may be a Central Processing Unit (CPU), or 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. A general-purpose processor may be a microprocessor or any conventional processor.

[0086] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0087] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed. That is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above-described device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0090] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0091] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0092] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0093] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program for the Bluetooth device automated testing method can be stored in a storage medium. When executed by a processor, this computer program can implement the steps of the various method embodiments described above, namely, obtaining a structured test instruction set, wherein the structured test instruction set contains multiple instructions, each instruction including at least the instruction content to be sent and the expected response mode; pre-encrypting the instruction content in the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the need for... Real-time encryption overhead; constructing a unified device driver abstraction layer, encapsulating the communication code of different hardware interface protocols into driver subclasses, and defining abstract driver interfaces for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface; sending instructions to the Bluetooth device under test through the unified device driver abstraction layer and receiving response data, automatically comparing the response data with the expected response mode, and generating a pass or fail result; for at least one Bluetooth device under test, when multiple Bluetooth devices are under test, an independent test instance is launched for each device through an operating system-level multi-process mechanism, and each test instance executes the process defined in the aforementioned steps in parallel without interference. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. The storage medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, external hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of the storage medium may be appropriately added to or subtracted from the contents according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the storage medium may not include electrical carrier signals and telecommunication signals.

[0094] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the protection scope of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An automated testing method for Bluetooth devices, characterized in that, Includes the following steps: Step S1: Obtain a structured test instruction set, which contains multiple instructions, each of which includes at least the instruction content to be sent and the expected response mode; Step S2: Pre-encrypt the instruction content in the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption. Step S3: Construct a unified device driver abstraction layer, encapsulate the communication code of different hardware interface protocols into driver subclasses, and define an abstract driver interface for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface. Step S4: Send instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive response data, automatically compare the response data with the expected response mode, and generate a pass or fail judgment result. Step S5: For at least one Bluetooth device under test, when there are multiple Bluetooth devices under test, an independent test instance is started for each device through the operating system-level multi-process mechanism. Each test instance executes the processes defined in steps S1 to S4 in parallel without interfering with each other.

2. The automated testing method for Bluetooth devices according to claim 1, characterized in that, The step of pre-encrypting the instruction content of the structured test instruction set to generate a ciphertext instruction file includes: The instruction content of the structured test instruction set is read using an independent preprocessing tool; Encrypt each message by calling the RSA public key encryption function; The encryption result is saved as a ciphertext instruction file with the suffix .bat.enc. This ciphertext instruction file is generated once when the instruction set is first prepared, and reused for all subsequent tests.

3. The automated testing method for Bluetooth devices according to claim 1, characterized in that, The unified device driver abstraction layer is implemented by defining an abstract base class DeviceDriver, which contains at least the following four core interface methods: open(config) to open a device connection according to configuration parameters, send(data) to send data to the device, receive(timeout) to receive data from the device and support timeout, and close(config) to close the device connection according to configuration parameters. Driver subclasses of different hardware interface protocols inherit from and implement the abstract base class.

4. The automated testing method for Bluetooth devices according to claim 3, characterized in that, The step of automatically comparing the response data with the expected response pattern to generate a pass or fail result includes: If the expect field of the instruction is defined, then it is also checked whether the response arrives within the timeout and whether the content matches the expected response pattern. If the expect field of the instruction is not defined, then only check whether a response is received within the timeout period; The result of each instruction is either PASS or FAIL, generated based on the comparison results.

5. The automated testing method for Bluetooth devices according to claim 4, characterized in that, Step S4 also includes the following timeout handling and retry mechanisms: In the structured instruction set, a unique timeout (timeout_ms) and a maximum number of retries (retry) are set for each instruction; If no response is received within the timeout period or the response does not match, the instruction will be resent and compared again according to the maximum number of retries, until the retry limit is reached and the instruction is deemed to have failed.

6. The automated testing method for Bluetooth devices according to claim 1, characterized in that, The RSA public key used in the pre-encryption process is paired with the private key of the target device, and the ciphertext instruction file is associated with and verified with the corresponding device's license file and configuration file through a hash checksum, ensuring that the ciphertext instruction file can only be correctly decrypted and executed by authorized devices.

7. The automated testing method for Bluetooth devices according to claim 1, characterized in that, The unified device driver abstraction layer also includes a driver registry for dynamically registering and deregistering driver subclasses at runtime. When a new Bluetooth device is detected to be connected, the corresponding driver subclass is automatically found and instantiated based on the device identifier, without needing to restart the test process.

8. An automated testing device for Bluetooth devices, characterized in that, The device includes: The acquisition module is used to acquire a structured test instruction set, which contains multiple instructions, each of which includes at least the instruction content to be sent and the expected response mode. The first generation module is used to pre-encrypt the instruction content of the structured test instruction set to generate a ciphertext instruction file, so that the ciphertext instructions in the ciphertext instruction file can be directly called during test execution, eliminating the overhead of real-time encryption. The encapsulation module is used to build a unified device driver abstraction layer, which encapsulates the communication code of different hardware interface protocols into driver subclasses and defines an abstract driver interface for test scheduling logic to call. The unified device driver abstraction layer defines the abstract driver interface. The second generation module is used to send instruction content to the Bluetooth device under test through the unified device driver abstraction layer, receive response data, automatically compare the response data with the expected response mode, and generate a pass or fail judgment result. The parallel execution module is used to start an independent test instance for each Bluetooth device under test (at least one device under test) or when there are multiple devices under test, through an operating system-level multi-process mechanism. Each test instance executes the processes defined by the acquisition module, the first generation module, the encapsulation module, and the second generation module in parallel without interfering with each other.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images