Automatic test system and method and vehicle

Abstract

The embodiment of the invention relates to the technical field of automatic testing, and discloses an automatic testing system and method and a vehicle, and the system comprises an upper computer main service module which is used for obtaining a testing script, carrying out the abstract conversion of the testing script, and obtaining a target abstract instruction; the target abstract instruction is a standardized target abstract instruction for describing a test operation type; the access and access control module is used for determining a corresponding virtual device node when the target abstract instruction is received; converting the target abstract instruction into an executable instruction corresponding to the operation equipment through the virtual equipment node; controlling the operation equipment to execute the executable instruction, and receiving a returned execution result; the virtual device node is created based on a device capability description model of the operating device. According to the technical scheme, the test script is converted into the standardized abstract instruction, so that the test script does not need to be modified for different devices or scenes, and cross-device and cross-scene efficient multiplexing is realized.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, specifically to an automated testing system, method, and vehicle. Background Technology

[0002] Currently, most automated testing solutions involve a host computer directly connecting to peripherals to execute automated tests. Within the software running on the host computer, the configurations and parameter settings for each peripheral are relatively fixed. Consequently, the automated testing functions implemented by the automated test scripts are also relatively fixed and cannot be reused in other scenarios. Summary of the Invention

[0003] In view of the above problems, embodiments of this application provide an automated testing system, method and vehicle to solve the problem of difficulty in reusing test scripts in related technologies.

[0004] According to one aspect of the embodiments of this application, an automated testing system is provided, the system comprising: The host computer main service module and the access and access control module; The host computer main service module is used to obtain the test script, perform abstract transformation processing on the test script, and obtain the target abstract instruction; the target abstract instruction is a standardized target abstract instruction that describes the test operation type. The access and control module is further configured to, upon receiving the target abstract instruction, determine the virtual device node corresponding to the target abstract instruction; convert the target abstract instruction into an executable instruction corresponding to the operating device through the virtual device node corresponding to the target abstract instruction; control the operating device to execute the executable instruction, and receive the execution result returned by the operating device based on the executable instruction; the virtual device node is created based on the device capability description model of the operating device.

[0005] According to another aspect of the embodiments of this application, an automated testing method is provided, including: Obtain the test script, perform abstract transformation on the test script to obtain the target abstract instruction; the target abstract instruction is a standardized target abstract instruction describing the test operation type; the target abstract instruction is a standardized instruction describing the test operation requirements. Determine the virtual device node corresponding to the target abstract instruction; the virtual device node is created based on the device capability description model of the operating device. The target abstract instruction is converted into an executable instruction corresponding to the operating device through the virtual device node corresponding to the target abstract instruction; Control the operating device to execute the executable instructions, and obtain the execution result returned by the operating device based on the executable instructions.

[0006] According to another aspect of the embodiments of this application, a vehicle is provided, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform some or all of the steps in the above method.

[0007] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements some or all of the steps in the above-described method.

[0008] In this embodiment, the test script is converted into a standardized target abstract instruction through the host computer main service module. This abstract instruction is independent of the specific operating device model, communication protocol and host computer fixed configuration, and only describes the test operation type. This allows the test script to be reused efficiently across devices and scenarios without modification for different devices or scenarios, and greatly reduces the cost of script development and maintenance.

[0009] The access and control module creates virtual device nodes based on the device capability description model of the operating device. Through virtual device node identifier matching and dynamic command conversion, it automatically adapts to the characteristics of different operating devices. It can be compatible with new operating devices without modifying the core logic of the host computer, realizing weak coupling between the system and the operating devices and improving the flexibility of device expansion.

[0010] The automated testing system isolates the differences between test scripts and hardware devices through an intermediate adaptation mechanism between abstract instructions and virtual device nodes. This ensures the universality of the host computer test logic and enables flexible replacement and expansion of operating devices. It not only improves the adaptation efficiency of automated testing but also reduces the deployment complexity in multi-device testing scenarios, providing an efficient and flexible solution for complex testing needs such as multi-module collaborative testing of vehicles.

[0011] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0012] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This diagram illustrates the structure of equipment deployment in conventional technologies. Figure 2 This diagram illustrates the architecture of automation testing software in traditional technologies. Figure 3 A schematic diagram of the structure of the automated testing system provided in this application is shown; Figure 4 A schematic diagram of the hardware architecture of the automated testing system provided in this application is shown; Figure 5 A flowchart illustrating the online process of the virtual device node provided in this application is shown; Figure 6 A flowchart illustrating the process of converting abstract instructions provided in this application into executable instructions is shown. Figure 7 This application illustrates a flowchart of the process for accessing operating devices and mounting virtual device nodes. Figure 8 This application provides a flowchart illustrating the execution of automated use cases. Figure 9 A flowchart illustrating the instruction scheduling process provided in this application is shown; Figure 10 A flowchart illustrating the automated testing method provided in this application is shown; Figure 11 A structural schematic diagram of an embodiment of the vehicle provided in this application is shown. Detailed Implementation

[0013] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0014] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0015] Current automated testing solutions used in the industry involve equipment deployment such as... Figure 1 As shown, the automated testing software architecture is as follows: Figure 2 As shown.

[0016] In traditional automated testing solutions, the hardware architecture mostly involves a host computer directly connecting to the operating devices to execute automated testing tasks. In the software running on the host computer, the configuration and parameter settings of each operating device are relatively fixed. The automated testing functions implemented by the automated test scripts during operation are also relatively fixed and cannot be reused in other scenarios.

[0017] Current automated testing solutions have the following problems: The test scripts heavily rely on specific testing frameworks, such as Appium and UIAutomator. Scripts written for Android devices cannot run directly on embedded devices and must be rewritten or extensively modified.

[0018] The communication protocols, control commands, operating systems, and interaction methods of different devices are quite different, which makes it impossible to reuse test logic.

[0019] When a new device type is added to the test device pool or a related device firmware upgrade causes a change in the protocol, a large number of test scripts and underlying drivers need to be modified, resulting in a large maintenance workload.

[0020] When a script fails to execute, it cannot be automatically resumed and requires manual triggering or scheduling.

[0021] Figure 3 A schematic diagram of the automated testing system of this application is shown to address the aforementioned problems. For example... Figure 3 As shown, the automated testing system 100 includes: The host computer main service module 110 and the access and access control module 120.

[0022] The host computer main service module 110 is used to obtain test scripts, perform abstract transformation on the test scripts, and obtain target abstract instructions. Target abstract instructions are standardized target abstract instructions that describe the test operation type.

[0023] In this embodiment, the test script is written by testers based on a predefined unified abstract instruction set. The predefined unified abstract instruction set is shown in Table 1 below. Table 1 includes the identifier of the abstract instruction and its corresponding name and description information, where the description information can be customized and added. User-defined abstract instructions are supported, and the abstract instructions in Table 1 can be dynamically updated to adapt to personalized testing needs. An abstract instruction management module can be added to the host computer main service module to support testers in entering custom abstract instructions.

[0024] Table 1 Abstract Instruction Set

[0025] In this application embodiment, the test operation types include click operations, swipe operations, text input operations, etc., which correspond to the abstract instruction names in Table 1. For example, if the test script corresponds to test operation types including click operations, swipe operations, and assertion operations, then the corresponding abstract instructions include: Touch, Slide, and Assert. Abstract instructions are standardized test operation instructions used to uniformly describe test operation types, free from the limitations of specific devices and frameworks. In this application, virtual device nodes, operating devices, abstract instructions, and executable instructions have a one-to-one correspondence.

[0026] The access and control module 120, upon receiving a target abstract instruction, determines the virtual device node corresponding to that instruction. It then converts the target abstract instruction into an executable instruction corresponding to the operating device using the virtual device node. The module controls the operating device to execute the executable instruction and receives the execution result returned by the operating device based on the executable instruction. The virtual device node is created based on the operating device's device capability description model.

[0027] In this embodiment, the executable instructions are the native instructions for operating the device. The device capability description model describes the functions of the operating device in a unified way, such as: "This device supports simulated touch," "This device has image recognition function," "This device can play audio and receive audio input," etc. When each operating device registers with the automated testing system 100, it not only reports its type and connection information, but also reports a capability description file that conforms to the capability meta-model. A virtual device node refers to the status representation of a peripheral device registered in the virtual gateway submodule, including device type, supported instructions, etc.

[0028] The automated testing system 100 of this application includes a hardware architecture and a software architecture. Through the cooperation of the hardware architecture and the software architecture, automated testing of loosely coupled multiple peripheral devices (operating devices / peripheral devices) is realized.

[0029] The software architecture of the automated testing system 100 includes a host computer main service module 110 and an access and access control module 120.

[0030] The host computer main service module 110 is used to control the current operating equipment to complete the test tasks, accept the input of automated test tasks from upstream, and provide an interactive software and operating equipment configuration entry.

[0031] The host computer main service module 110 receives test scripts from upstream, performs abstract transformation on the scripts, removes redundant information related to specific devices and frameworks, and generates standardized abstract instructions that only describe the test operation types. The test scripts are written based on unified abstract instructions, such as the script to verify that the online radio application is open: Go_home, Pause (1000), Touch (online radio), Assert (online radio application is open, UI is displayed normally).

[0032] After receiving the target abstract instruction, the access and control module 120 queries the list of currently online virtual device nodes based on the device capability description model of the operating device, and determines the virtual device node corresponding to the instruction, including key information such as the registered device type and supported instructions.

[0033] The access and control module 120 uses the adaptation mechanism corresponding to the virtual device node to convert standardized target abstract instructions into instructions that the operating device can recognize and execute (executable instructions). For example, it converts "Touch (online radio)" into the touch device's coordinate click instruction Tap(100, 200) and drives the operating device to execute the instruction. After the operating device completes the execution, it feeds back the execution result to the access and control module 120. The execution result may include success / failure status, execution logs, device status data, etc.

[0034] This system resolves the strong coupling issue between test scripts and operating devices. The scripts are written based on standardized abstract instructions and can be reused across Android and embedded devices, enabling "write once, use everywhere." Through the collaboration of the device capability description model and virtual device nodes, it masks the heterogeneous differences (communication protocols, control commands, etc.) of different operating devices, reducing device adaptation difficulty. It reduces maintenance workload caused by device changes (additions, upgrades) without requiring modifications to core test scripts and underlying drivers, lowering maintenance costs. It provides a foundation for subsequent instruction caching and breakpoint resumption, improving the flexibility and reliability of script execution. The host computer main service module 110 acquires the test script and performs abstract transformation processing, outputting standardized target abstract instructions describing the test operation type. It relies on the main control server in the hardware architecture to receive the test script and, based on the abstract instruction set defined by the automated testing system 100 (as shown in Table 1), completes the conversion of the script into standardized abstract instructions, solving the cross-platform reuse problem of test scripts.

[0035] In this application, the host computer main service module 110 specifically includes: a central software submodule, a scheduling and task management submodule, and an abstract instruction parsing submodule.

[0036] The central software submodule interfaces with the input of automated test tasks and the parameter configuration of the automated test system 100, such as standby, device status, execution records, etc.

[0037] The scheduling and task management submodule manages the execution configuration, execution scheduling, and execution status statistics of tasks assigned to the current automated testing system 100.

[0038] The abstract instruction parsing submodule parses the test scripts and data in the test task, and converts the test scripts or test task descriptions into unified abstract instructions.

[0039] The access and control module 120 interfaces with the abstract command and distributes and maps the abstract command to the corresponding device node service submodule through the virtual gateway submodule.

[0040] The access and control module 120 specifically includes: a virtual gateway submodule, a device service management submodule, and a device node service submodule.

[0041] The virtual gateway submodule mainly converts abstract instructions into executable instructions corresponding to the current operating devices by dynamically bridging virtual node adapters and combining them with the operating devices currently mounted on the automated testing system 100, and maintains virtual device nodes.

[0042] The device service management monitors and manages the mounting and access of operating devices, and creates corresponding device node service sub-modules according to the type of operating device, and manages the working status of the device node service sub-modules, that is, the start and stop of the device node service sub-modules.

[0043] The device node service submodule is a collective term for the operation device node service submodules. Each operation device has a corresponding device node service submodule. The device node service submodule communicates directly with the operation device and is the specific business implementation of the operation device.

[0044] like Figure 4 As shown, the hardware architecture of the automated testing system 100 includes a main control server, access control devices, and operating devices.

[0045] The master control server is a local or cloud-based test script control and distribution device, primarily responsible for collecting automated test tasks, abstracting and converting test scripts, and forwarding them. The master control server receives test scripts uploaded by testers and forwards them to the host computer's main service module 110.

[0046] Access control devices are primarily used to receive control commands from the master control server, manage and control the access of operating devices, and create device node service sub-modules. They also provide virtual device nodes and abstract peripheral access APIs within the device node service sub-modules for executing executable commands.

[0047] Operating devices are the execution end of automated testing, including touch devices, audio devices, barcode scanners, etc., and are the actual carriers of executable instructions.

[0048] In one optional implementation, the host computer main service module 110 includes: The abstract instruction parsing submodule is used to acquire and parse the test script to obtain an abstract instruction sequence. It then determines the test operation type corresponding to each initial abstract instruction in the sequence and assigns a corresponding virtual device node identifier to each initial abstract instruction based on its test operation type. Finally, it adds the virtual device node identifier to the corresponding initial abstract instruction to obtain the target abstract instruction.

[0049] In this embodiment, the virtual device node identifier is used to distinguish virtual device nodes and may be a virtual device ID.

[0050] This application's embodiments parse test scripts into standardized abstract instruction sequences, decoupling the strong binding relationship between scripts and specific test frameworks or target devices (Android / embedded devices). For example, a script for "verifying the opening of an online radio application" written based on abstract instructions can run on multiple platforms without modification, completely solving the problem of traditional scripts requiring different scripts for different devices. This achieves "write once, use for multiple parties," significantly improving script reusability.

[0051] Script writers do not need to concern themselves with device communication protocols or underlying driver logic; they only need to describe test operations based on standardized abstract commands such as Touch and Slide, thus lowering the barrier to script writing. Furthermore, when a new device type is added or the device firmware is upgraded, existing scripts do not need to be modified; only the virtual node identifier of the new device needs to be matched through modules, reducing maintenance workload and costs.

[0052] Virtual device node identifiers are assigned based on the test operation type of the initial abstract instruction (e.g., "scan code" corresponds to a scanning device, "voice input" corresponds to an audio device), to avoid mismatching instructions to devices that do not support the operation. For example, the Scan_code instruction will be accurately assigned to a scanning device node, not a touch device node, ensuring the accuracy of instruction execution and reducing test failures caused by device mismatch.

[0053] The generated target abstract instructions (including virtual device node identifiers) can be directly used as input to the virtual gateway submodule without additional processing, thus shortening the instruction flow path and improving overall testing efficiency.

[0054] In one alternative implementation, the access and control module 120 includes: The virtual gateway submodule, upon receiving a target abstract instruction, extracts the virtual device node identifier from the target abstract instruction, determines the virtual device node corresponding to the target abstract instruction, and the virtual node adapter corresponding to the virtual device node based on the virtual device node identifier. It then forwards the target abstract instruction to the virtual device node, where the virtual node adapter converts the target abstract instruction into executable instructions corresponding to the operating device.

[0055] This application uses a dynamic bridging adapter mechanism to convert standardized target abstract instructions into native instructions (executable instructions) for different operating devices. For example, it converts Touch (online radio) into Tap (100, 200) instructions for touch devices and Voice_input into recording instructions for audio devices. This shields the differences in communication protocols and control instruction formats between different devices and solves the heterogeneous problem of needing to modify instructions for different devices in traditional solutions.

[0056] The virtual gateway submodule maintains a virtual device node-adapter mapping table and synchronizes the device status reported by the device service management submodule in real time. When a device is added or removed, only the mapping table and the corresponding adapter need to be updated; no modification to the gateway's core logic is required. For example, when adding a new touch device, only the adapter for that device needs to be added to achieve command conversion, support hot-swapping of devices, and improve the scalability of the automated testing system.

[0057] The virtual gateway submodule accurately matches the corresponding node and adapter based on the virtual device node identifier, avoiding redundant forwarding of commands across multiple devices. Simultaneously, the adapter's built-in device capability description model and command mapping rules ensure that the converted native commands fully comply with device operation requirements (such as coordinate range and command parameter format), reducing command conversion error rates and improving test stability.

[0058] As the intermediate hub between the host computer main service module 110 and the device node service submodule, the virtual gateway submodule receives the target abstract instructions and forwards them to the device node service submodule, forming a complete link of instruction parsing, instruction conversion and instruction execution, ensuring a smooth testing process and avoiding data gaps between modules.

[0059] In one optional implementation, the access and control module 120 further includes a device node service submodule, which corresponds one-to-one with the operating device.

[0060] The device node service submodule communicates with the operating device to control the operating device to execute executable instructions and to receive the execution results returned by the operating device based on the executable instructions.

[0061] In this application, each operating device corresponds to a unique device node service submodule. This service contains the device's built-in driver logic and communication protocol parsing rules, isolating the device control logic from the core logic of the automated testing system. For example, the device node service submodule for touch devices focuses on driving operations such as coordinate clicks and swipes, while the device node service submodule for barcode scanners focuses on barcode recognition logic. These modules do not interfere with each other, facilitating future maintenance. For instance, when upgrading the driver for a barcode scanner, only the corresponding device node service submodule needs to be modified, without affecting other devices.

[0062] The device node service submodule establishes a direct communication connection with the operating device, issuing native commands without requiring multiple layers of forwarding. For example, after receiving the Tap(100, 200) command, the touch device node service submodule can directly drive the device to perform a click operation. Compared to the traditional method of direct control by the host computer, this reduces command transmission links, lowers execution latency, and improves testing efficiency.

[0063] The service receives execution results from the operating devices in real time and performs initial standardization processing, such as standardizing the result format, to provide accurate data support for subsequent result feedback and anomaly troubleshooting. For example, if a barcode scanning device fails to execute, the service can collect a "barcode scanning timeout" log to help testers quickly locate the problem.

[0064] Each device node service submodule corresponds one-to-one with the operating device, avoiding command conflicts caused by multiple devices sharing the control unit. For example, when multiple touch devices execute different click commands simultaneously, each device node service submodule will drive the device independently, preventing command confusion and ensuring the stability of parallel testing of multiple devices.

[0065] In one alternative implementation, the access and control module 120 further includes a device service management submodule.

[0066] The Device Service Management submodule is used to create a device node service submodule corresponding to the operating device when the operating device is connected, and to manage the working status of the device node service submodule.

[0067] The device service management submodule automatically listens for USB, network, and Bluetooth interfaces. After a device is connected, no manual configuration is required to complete capability model verification, device node service submodule creation, and startup, significantly reducing the difficulty of device deployment. For example, after a touch device connects to the access control device via USB, the module can complete verification and create the corresponding device node service submodule within 1 second, saving deployment time compared to traditional manual configuration methods.

[0068] By verifying the device capability description model, incompatible devices are rejected from accessing the system, such as older barcode scanners that do not support the "Assert" command. This avoids system crashes or test task interruptions caused by device compatibility issues and improves the overall stability of the system.

[0069] The module manages the lifecycle of device node service submodules in real time (starting services when the device is online and stopping and releasing resources when it is offline), avoiding unnecessary services consuming CPU and memory resources. For example, when a touch device disconnects, the module immediately stops its device node service submodule, releasing approximately 50MB of memory resources to ensure efficient use of system resources.

[0070] The device access / disconnection status and the working status of the device node service submodule are synchronized to the virtual gateway submodule to ensure that the "online device node list" of the virtual gateway submodule is updated in real time. This provides an accurate basis for the abstract instruction parsing submodule to assign node identifiers and for the virtual gateway submodule to match nodes, avoiding instruction assignment errors caused by lagging node status.

[0071] In one alternative implementation, the device node service submodule is further configured to forward the execution result to the virtual gateway submodule after receiving the execution result returned by the operating device based on the executable instruction.

[0072] The virtual gateway submodule is also used to send the received execution results to the host computer main service module 110.

[0073] In this embodiment, the virtual gateway submodule is further configured to send the received execution results to the scheduling and task management submodule in the host computer main service module 110. This forms a result flow link between the operating device, the device node service submodule, the virtual gateway submodule, and the host computer main service module 110, ensuring that the execution results are synchronized to the testers without loss or delay. For example, after a touch device performs a click operation, the result can be fed back to the host computer interface within 500ms, allowing testers to monitor the test progress in real time and solving the problem of untimely result feedback in traditional solutions.

[0074] Based on the feedback results, the host computer main service module 110 can statistically analyze the progress of test tasks in real time (e.g., 3 / 5 instructions have been executed), mark failed instructions (e.g., Scan_code execution failed), and trigger corresponding exception handling mechanisms (e.g., notifying the virtual gateway submodule to cache instructions). For example, if an instruction fails to execute, the system can locate the device communication interruption through the feedback results and automatically start the retransmission mechanism without manual intervention.

[0075] The feedback results can include key information such as the executable instruction ID, virtual device ID, and execution timestamp. Testers can use this information to trace the instruction execution process (e.g., instruction 102 failed to execute on touch device A because the coordinates were outside the screen range) and quickly locate the root cause of the problem (e.g., incorrect script parameters or device hardware failure). Compared with traditional non-traceable solutions, this shortens the problem investigation time.

[0076] The standardized result format (including execution logs and device status) can be archived and stored for a long time, meeting the compliance requirements of enterprise-level testing scenarios (such as auditing and test report review), and facilitating the later tracing of the execution status of a batch of tests.

[0077] In one optional implementation, the virtual gateway submodule further includes an instruction caching unit, which is used to cache the converted executable instructions and the corresponding target abstract instructions to obtain cache information, and to trigger an instruction retransmission mechanism based on the cache information when the retransmission condition is met, so as to resend the executable instructions to the device node service submodule.

[0078] The cached executable instructions and target abstract instructions can automatically trigger a resend mechanism when the execution failure is recoverable, such as when the device is temporarily disconnected and then reconnected, or when network fluctuations are resolved. For example, if a barcode scanning device fails to execute due to QR code offset, the unit can automatically resend the scanning instruction after the QR code is repositioned, without requiring manual restart of the test task, thus improving the level of test automation.

[0079] If a test task is interrupted due to a device malfunction, such as a touch device suddenly going offline, the unit can resume execution from the breakpoint based on the cached unexecuted instructions after the fault is resolved, without having to rerun the entire script. For example, in a cockpit stability test containing 20 instructions, if the device goes offline at instruction 15, it can resume directly from instruction 15 after recovery, saving the time of repeatedly executing 14 instructions, approximately 20 minutes.

[0080] For example, it can support three command resends by default, which can handle occasional problems such as network fluctuations and temporary device failures. For instance, if a command fails to execute on the first attempt due to network latency, it can be successfully executed after resend, improving the success rate of test tasks and enhancing the system's anti-interference capabilities.

[0081] The weak coupling in this application is mainly reflected in two dimensions. One dimension is the weak coupling between the test tasks and test scripts and the operating equipment. The other dimension refers to the weak coupling between the operating equipment in the automated testing system and the automated test bench.

[0082] The implementation of loose coupling in the test script: Device dependency primarily refers to the versatility of test scripts (test scripts for Android devices are not applicable to other embedded devices). The fundamental reason why test scripts extracted from related solutions cannot be applied across different operating devices is that the writing of automated test scripts is heavily reliant on a fixed framework and format. To address this issue, this application provides a new software architecture and implementation path. The implementation path is as follows: During test script writing, specific abstract instructions are used to describe the execution process of the test script. For example, an automated test script might read: "Verify that the online radio application functions correctly."

[0083] The abstract instructions at this point are as follows: Go_home, Pause(1000), Touch(online radio), Assert(online radio application opens, UI displays normally).

[0084] After the test script is written, it is called and triggered by the host computer main service module. The abstract instruction parsing submodule reads the currently online virtual device nodes (types) from the virtual gateway submodule and assigns the corresponding virtual device ID (virtual device node identifier) ​​to the abstract instruction.

[0085] By using the virtual device ID in the virtual gateway submodule, abstract instructions are converted into a set of instructions that can be executed by the device node service submodule through dynamic protocol adaptation and conversion.

[0086] Figure 5 This indicates the process of bringing virtual device nodes online, such as... Figure 5 As shown, after the virtual device node service submodule starts, it notifies the virtual gateway submodule.

[0087] The virtual gateway submodule is used to find the virtual node adapter corresponding to the virtual device node.

[0088] The virtual gateway submodule starts the virtual node adapter (virtual device ID).

[0089] After the virtual node adapter starts, it binds the virtual device node using the virtual device ID.

[0090] Figure 6 This represents the process of converting abstract instructions into executable instructions, such as... Figure 6 As shown, the host computer main service module forwards abstract instructions to the virtual gateway submodule.

[0091] The virtual gateway submodule locates the corresponding virtual device node based on the node type and ID.

[0092] The virtual gateway submodule forwards abstract commands to non-virtual device nodes.

[0093] Virtual device nodes use the virtual node adapter corresponding to the current node to convert abstract instructions into device-specific executable instructions.

[0094] The virtual node adapter sends executable instructions to the device node service submodule.

[0095] The device node service submodule executes the set of executable device instructions.

[0096] Implementation of weak coupling in operating devices: The loose coupling of operating devices is mainly achieved through two approaches. One is to separate the automated test task execution control unit from the device execution unit at the hardware level. The other approach is to abstract the hardware device into a virtual device node, isolating the hardware device from its control code and the business logic it executes. This involves the processes of operating device access and virtual device node mounting, such as... Figure 7 As shown, the automated testing system operations administrator activates the automated access control device.

[0097] The access control device starts the device node service submodule, which then runs and monitors the network interface, USB interface, and Bluetooth interface of the access control device.

[0098] The access control device starts the service of the virtual gateway submodule and waits for virtual device nodes to join.

[0099] The operating device is connected to the access control device via USB, network card, or other means.

[0100] When the device node service submodule detects a change in the operating device, it attempts to read the corresponding device capability model description from the access point, and parses the abstract instruction types supported by the node and the instruction mapping set from abstract instructions to device-related instructions (or dynamically configured background instruction mapping service) based on the capability model description, and verifies the completeness of the parameters provided by the device node.

[0101] After verification, the device node service submodule creates a virtual device node and sends a node registration request to the virtual gateway submodule.

[0102] The virtual gateway submodule records device node information, sends a message notification that the device node service submodule has successfully registered, and the virtual device node has successfully come online.

[0103] The overall automated testing process of this application includes preliminary preparations and the specific testing process.

[0104] Preliminary preparations include: setting up the hardware framework, including the main control server, access control equipment, and operating equipment; connecting the operating equipment; and creating virtual device nodes.

[0105] After the preparations are complete, the testers write test scripts based on the defined unified abstract instruction set.

[0106] The testers upload the scripts they have written to the main control server, which then forwards the scripts to the central software submodule of the host computer's main service module.

[0107] The abstract instruction parsing submodule of the host computer main service module starts working, parses the abstract instruction sequence in the script, and extracts the test operation type (such as click, pause, assertion) and parameters (such as the 1000ms delay of Pause, the target object of Touch) for each instruction.

[0108] Query the list of currently online virtual device nodes from the virtual gateway submodule, and assign a corresponding virtual device ID to each abstract instruction based on the test operation type (e.g., touch operation corresponds to touch device node, voice input corresponds to audio device node).

[0109] The host computer main service module forwards the abstract instruction (target abstract instruction) with the virtual device ID to the virtual gateway submodule.

[0110] The virtual gateway submodule searches for the corresponding virtual device node and its dedicated virtual node adapter in the list of online device nodes based on the virtual device ID.

[0111] The virtual gateway submodule forwards abstract instructions to the virtual device node, and the virtual node adapter initiates the conversion logic: combining the instruction mapping rules in the device capability description model, the abstract instructions are converted into native device instructions (executable instructions) that can be executed by the operating device, such as converting Touch (online radio) into the coordinate click instruction Tap(100, 200) of the touch device.

[0112] The virtual node adapter sends the converted native device commands to the corresponding device node service submodule.

[0113] After receiving the device's native instructions (executable instructions), the device node service submodule directly establishes communication with the operating device (based on the communication protocols in the device capability description model, such as ADB and TCP), and drives the operating device to perform specific operations (such as a touch device performing coordinate clicks or an audio device playing a prompt tone).

[0114] After the operation is completed, the execution results (success / failure, execution log, device status data) will be fed back to the device node service submodule.

[0115] The device node service submodule forwards the execution result to the virtual gateway submodule, which then synchronizes it to the scheduling and task management submodule of the host computer main service module.

[0116] The scheduling and task management submodule provides real-time statistics on the execution progress of test tasks. If 3 / 5 instructions have been executed, the progress and results are synchronized to the central software submodule.

[0117] The central software submodule displays the test progress and execution results to testers through an interactive interface, facilitating real-time monitoring.

[0118] Figure 8 A flowchart illustrating the execution of automated use cases provided in this application is shown. For example... Figure 8 As shown, the process for executing automated test cases is as follows: Begin by starting the automated test case execution process.

[0119] Test case step conversion transforms the steps of automated test cases into executable operation instructions or test operation types.

[0120] Operation instructions, generating a specific set of operation instructions.

[0121] Abstract instructions: Look up Table 1 to convert operation instructions or test operation types into system-defined standardized abstract instructions, such as Touch, Slide, Assert, etc.

[0122] Access scheduling, enter the instruction scheduling stage, and query the status of the target device node (the virtual device node corresponding to the abstract instruction).

[0123] Target node status determination: Determine whether the target device node is online.

[0124] If online, the distribution node service step is executed, distributing the abstract instructions to the corresponding device node service submodule.

[0125] If offline, the instruction queue caching step is executed to temporarily store the instructions in the queue.

[0126] The instruction queue cache temporarily stores unexecuted abstract instructions, waiting for the target device node to come online.

[0127] Wait for the node to come online and continuously monitor the online status of the target device node.

[0128] Node online detection determines whether the target device node is online.

[0129] If it is not online, continue to wait for the node to come online.

[0130] If it is already online, the distribution node service step is executed to distribute the cached instructions to the corresponding device node service submodule.

[0131] The distribution node service distributes abstract instructions to the device node service submodule corresponding to the target device.

[0132] Parsing and execution: The device node service submodule parses abstract instructions and drives the device to perform specific operations.

[0133] Figure 9 A flowchart illustrating the instruction scheduling process provided in this application is shown. Figure 9 As shown, Start initiates the instruction scheduling process.

[0134] Query the current virtual nodes to obtain information on the currently online virtual device nodes in the system, and clarify the device type and supported command types of each node.

[0135] The instruction decomposes the abstract target instruction to be executed into identifiable operation units, and extracts the operation type, parameters and corresponding virtual device node requirements of the instruction.

[0136] The peripheral device matching determination is based on the decomposed instruction requirements to determine whether the currently online virtual device node (peripheral) matches the instruction.

[0137] If there is no match, the instruction caching step is executed to temporarily store the instruction in the cache queue, waiting for the matching peripheral to come online and be rescheduled.

[0138] If a match is found, the instruction is issued and the execution steps are performed.

[0139] Instruction cache temporarily stores mismatched instructions, which are then re-entered into the instruction decomposition stage for scheduling after subsequent peripheral status changes.

[0140] The command is issued and executed by sending the matching command to the corresponding device node service submodule, which then drives the device to perform the specific operation.

[0141] The technical solution of this application, on the one hand, adds an access control device to the hardware layout to manage the mounting of operating devices and the operation of device node service submodules. By establishing abstract operating device access interfaces and virtual device nodes in the access and access control modules, the coupling of operating devices in the access automation testing system is reduced, solving the problems of device heterogeneity and maintenance costs. On the other hand, by abstracting automated operation instructions in the architecture and business implementation of the automation software, encapsulating unified abstract instructions for operation automation, the solution addresses the problem of non-reusable test scripts, enabling cross-platform applicability of test scripts. Furthermore, by abstracting control execution instructions and using instruction caching and recovery technologies, the recoverable execution of automated tests is achieved.

[0142] Compared to traditional solutions, the main advantages of this application lie in reducing the coupling between external automated test scripts and operating devices, as well as reducing the coupling between the automated test system's operating devices and the automated main control device. By reducing the coupling between test scripts and operating devices, the coverage of automated test scripts can be improved, maintenance costs can be reduced, and "write once, use everywhere" can be achieved. Furthermore, by reducing the coupling between operating devices and the main control device, operating devices can be replaced more flexibly, enabling hot-swappable devices, high reusability, and reduced device dependency and maintenance costs.

[0143] Figure 10A flowchart illustrating the automated testing method provided in this application is shown, as follows: Figure 10 The automated testing method shown includes: Step 110: Obtain the test script, perform abstract transformation on the test script to obtain the target abstract instructions. The target abstract instructions are standardized instructions describing the test operation type. The target abstract instructions are standardized instructions describing the test operation requirements.

[0144] The test script is obtained through the host computer main service module, and the test script is abstracted and transformed to obtain the target abstract instruction.

[0145] Step 120: Determine the virtual device node corresponding to the target abstract instruction. The virtual device node is created based on the device capability description model of the operating device.

[0146] Step 130: Convert the target abstract instruction into an executable instruction corresponding to the operating device through the virtual device node corresponding to the target abstract instruction.

[0147] Step 140: Control the operating device to execute executable instructions and obtain the execution results returned by the operating device based on the executable instructions.

[0148] Steps 120, 130, and 140 are executed through the access and control module.

[0149] In one optional implementation, step 110 performs an abstract transformation on the test script to obtain the target abstract instructions, including: Parse the test script to obtain an abstract instruction sequence.

[0150] Determine the test operation type corresponding to each initial abstract instruction in the abstract instruction sequence.

[0151] Each initial abstract instruction is assigned a corresponding virtual device node identifier based on the test operation type it corresponds to.

[0152] Add the virtual device node identifier to the corresponding initial abstract instruction to obtain the target abstract instruction.

[0153] In one optional implementation, step 120, determining the virtual device node corresponding to the target abstract instruction, includes: The virtual device node identifier is extracted from the target abstract instruction by the virtual gateway submodule, and the virtual device node corresponding to the target abstract instruction is determined based on the virtual device node identifier.

[0154] In an optional implementation, step 130, which converts the target abstract instruction into an executable instruction corresponding to the operating device through the virtual device node corresponding to the target abstract instruction, includes: The virtual gateway submodule determines the virtual node adapter corresponding to the virtual device node based on the virtual device node identifier.

[0155] The target abstract instruction is forwarded to the virtual device node, and the target abstract instruction is converted into the executable instruction corresponding to the operating device through the virtual node adapter of the virtual device node.

[0156] In one optional implementation, step 140, controlling the operating device to execute executable instructions and obtaining the execution result returned by the operating device based on the executable instructions, includes: The device node service submodule controls the operation device to execute executable instructions and receives the execution results returned by the operation device based on the executable instructions. There is a one-to-one correspondence between the device node service submodule and the operation device.

[0157] In an optional implementation, the automated testing method further includes: when the operating device is accessed, creating a device node service submodule corresponding to the operating device through the device service management submodule, and managing the working status of the device node service submodule.

[0158] In an optional implementation, the automated testing method further includes: after receiving the execution result returned by the operating device based on the executable instruction, forwarding the execution result to the virtual gateway submodule through the device node service submodule. The virtual gateway submodule then sends the received execution result to the host computer main service module.

[0159] In an optional implementation, the automated testing method further includes: caching the converted executable instructions and the corresponding target abstract instructions through the instruction caching unit in the virtual gateway submodule to obtain cache information; and triggering an instruction retransmission mechanism based on the cache information when the retransmission condition is met, and retransmitting the executable instructions to the device node service submodule.

[0160] In one optional implementation, the automated testing method further includes: receiving test scripts uploaded by testers through the main control server and forwarding the test scripts to the host computer main service module.

[0161] Figure 11 The diagram shows a structural schematic of an embodiment of the vehicle provided in this application. The specific embodiments of this application do not limit the specific implementation of the vehicle.

[0162] like Figure 11 As shown, the vehicle may include: a processor 402, a communications interface 604, a memory 406, and a communications bus 408.

[0163] The processor 402, communication interface 604, and memory 406 communicate with each other via communication bus 408. Communication interface 604 is used to communicate with other network elements such as clients or other servers. The processor 402 executes program 410, specifically performing the relevant steps described above in the automated testing system embodiment.

[0164] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0165] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The vehicle may include one or more processors of the same type, such as one or more CPUs, or processors of different types, such as one or more CPUs and one or more ASICs.

[0166] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0167] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the automated testing system described in any of the above method embodiments.

[0168] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments in this application are not directed to any particular programming language.

[0169] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. Similarly, for the purpose of simplification and aiding understanding of one or more aspects of the invention, in the above description of exemplary embodiments of this application, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0170] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0171] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. An automated test system, characterized by, The system includes: a host computer main service module and an access and access control module; The host computer main service module is used to obtain the test script, perform abstract transformation processing on the test script, and obtain the target abstract instruction; the target abstract instruction is a standardized target abstract instruction that describes the test operation type. The access and control module is further configured to, upon receiving the target abstract instruction, determine the virtual device node corresponding to the target abstract instruction; convert the target abstract instruction into an executable instruction corresponding to the operating device through the virtual device node corresponding to the target abstract instruction; control the operating device to execute the executable instruction, and receive the execution result returned by the operating device based on the executable instruction; the virtual device node is created based on the device capability description model of the operating device.

2. The system of claim 1, wherein, The host computer main service module includes: The abstract instruction parsing submodule is used to obtain a test script, parse the test script to obtain an abstract instruction sequence, determine the test operation type corresponding to each initial abstract instruction in the abstract instruction sequence, assign a corresponding virtual device node identifier to each initial abstract instruction according to the test operation type corresponding to each initial abstract instruction, and add the virtual device node identifier to the corresponding initial abstract instruction to obtain the target abstract instruction.

3. The system according to claim 2, characterized in that, The access and access control module includes: The virtual gateway submodule is used to, upon receiving the target abstract instruction, extract the virtual device node identifier from the target abstract instruction, determine the virtual device node corresponding to the target abstract instruction and the virtual node adapter corresponding to the virtual device node based on the virtual device node identifier, forward the target abstract instruction to the virtual device node, and convert the target abstract instruction into an executable instruction corresponding to the operating device through the virtual node adapter corresponding to the virtual device node.

4. The system according to claim 3, characterized in that, The access and access control module further includes: a device node service submodule, which corresponds one-to-one with the operating device; The device node service submodule is communicatively connected to the operating device and is used to control the operating device to execute the executable instructions and receive the execution results returned by the operating device based on the executable instructions.

5. The system according to claim 4, characterized in that, The access and access control module also includes: a device service management submodule; The device service management submodule is used to create a device node service submodule corresponding to the operating device when the operating device is connected, and to manage the working status of the device node service submodule.

6. The system according to claim 4, characterized in that, The device node service submodule is further configured to forward the execution result to the virtual gateway submodule after receiving the execution result returned by the operating device based on the executable instruction; The virtual gateway submodule is also used to send the received execution result to the host computer main service module.

7. The system according to claim 6, characterized in that, The virtual gateway submodule further includes an instruction caching unit, which is used to cache the converted executable instruction and the corresponding target abstract instruction to obtain cache information, and to trigger an instruction retransmission mechanism based on the cache information when the retransmission condition is met, so as to resend the executable instruction to the device node service submodule.

8. The system according to claim 1, characterized in that, The system also includes: a main control server; The main control server is used to receive test scripts uploaded by testers and forward the test scripts to the host computer main service module.

9. An automated testing method, characterized in that, The method includes: Obtain the test script, perform abstract transformation on the test script to obtain the target abstract instruction; the target abstract instruction is a standardized target abstract instruction describing the test operation type; the target abstract instruction is a standardized instruction describing the test operation requirements. Determine the virtual device node corresponding to the target abstract instruction; the virtual device node is created based on the device capability description model of the operating device. The target abstract instruction is converted into an executable instruction corresponding to the operating device through the virtual device node corresponding to the target abstract instruction; Control the operating device to execute the executable instructions, and obtain the execution result returned by the operating device based on the executable instructions.

10. A vehicle, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the automated testing method as described in claim 9.

Images