An open automated testing system for hardware devices

Abstract

This invention relates to an open automated testing system for hardware devices, belonging to the field of automated testing technology. Addressing the situation where existing automated testing systems lack the capability to test new product types due to new product additions, this invention constructs an open and scalable component integration method. Through component expansion on both the test system and test agent sides, test management content for new product features and test agents are integrated into the existing test system. By constructing a loosely coupled message bus, information exchange between the test agent and the test server is achieved, enabling the existing test system to fully acquire the capability to test new products. This automated testing system can easily integrate new device-specific test content in terms of server-side, client-side, and client-server communication methods, supporting the system's adaptation to new product testing capabilities.

Description

Technical Field

[0001] This invention belongs to the field of automated testing technology, specifically relating to an open automated testing system for hardware devices. Background Technology

[0002] Automated product testing technology has been widely applied in product manufacturing, information technology, and other fields, playing a crucial role in reducing labor costs and improving product quality. However, with rapid business growth and an increasing number of products, the number of test items and methods for new products also grows. In this situation, automated testing systems designed based on the characteristics of earlier products and business operations become increasingly inadequate to meet the testing requirements of new products. To satisfy the testing requirements of both new and old products, many companies have had to redesign and replan their next-generation automated testing systems, leading to increased costs.

[0003] A typical automated testing system consists of two parts: a test server and a test agent. This invention focuses on solving three types of problems, enabling the automated testing system to have scalability.

[0004] 1) Server-side integration: Build server-side scalability capabilities, making it relatively easy to integrate new product testing management content into the server.

[0005] 2) Client integration: Build client scalability capabilities, making it relatively easy for clients to integrate new product testing functions.

[0006] 3) Client-server communication integration: Client-server communication needs to have a certain degree of scalability and support new system messages.

[0007] In response to the above situation and considering the characteristics of software and hardware products, this invention designs an open and scalable testing platform framework. It is capable of adapting to new product forms and can be integrated into the system with minimal extension development, enabling the existing testing system to test new products, continuously adapting to the needs of enterprise development, and reducing enterprise investment costs. Summary of the Invention

[0008] (a) Technical problems to be solved

[0009] The technical problem this invention aims to solve is how to provide an open automated testing system for hardware devices to address the expansion problem of automated testing systems.

[0010] (II) Technical Solution

[0011] To address the aforementioned technical problems, this invention proposes an open automated testing system for hardware devices, which includes a test server, a test client, and a communication proxy.

[0012] The test server includes: personnel maintenance module, task management module, task log module, device under test management module, test script configuration management module, test record management module, test component engine and test components;

[0013] The personnel maintenance module is used to manage test personnel information and authenticate the identities of accessing users to ensure their legitimacy.

[0014] The task management module is used to distribute different test items for different test devices to the test client as tasks. The test client executes the test tasks and returns the test results.

[0015] The task log module is used to record the status of the task execution process to ensure that the testing process is traceable;

[0016] The Device Under Test (DUT) management module is used to centrally manage the DUTs supported by the test, and to provide device information support for the construction and execution of test tasks.

[0017] The test script configuration management module provides unified test script management for different test tasks and supports the distribution of test scripts to test clients for execution.

[0018] The test record management module is used to record product test information from a product testing perspective.

[0019] The test component engine provides functions for loading, starting, stopping, and updating test components, ensuring that the dedicated management functions of the device under test are integrated into the system, thereby achieving unified management.

[0020] Test components are used to encapsulate the dedicated management functions of the device under test in a component manner, upload them to the test server for unified management and configuration, and the test component engine completes the full lifecycle management of the test components based on the configuration;

[0021] The test client includes: a task proxy module, a test status detection module, a test item management module, a test proxy component, and a proxy component engine;

[0022] The task proxy module is used to provide the functions of receiving specific test tasks and returning results;

[0023] The test status detection module is used to provide the worker status of its own client and its components and report it to the test server;

[0024] The test item management module is used to manage test scripts and their test items, and to notify the test component to call the test script to execute automated tests based on the test task being executed.

[0025] Test agent component, a functional module used to provide customized test items for the device under test;

[0026] The proxy component engine provides full lifecycle management functions for loading, starting, stopping, and updating test components;

[0027] The communication agent employs communication message packetization, one-to-one message distribution, and one-to-many message distribution methods.

[0028] The communication message packet constructs an extensible message communication format, ensuring that after the test server and test client integrate the test components and test proxy components respectively, they can support the addition of new test communication types.

[0029] (III) Beneficial Effects

[0030] This invention proposes an open automated testing system for hardware devices. Through this design, the automated testing system can easily integrate new device-specific test content in terms of server-side, client-side, and communication methods between the client and server, supporting the system's ability to adapt to new product testing. The invention has the following technical effects:

[0031] Openness: This invention is not focused on any specific field and has broad applicability.

[0032] Scalability: Test components and test proxy components that meet the packaging requirements can all be integrated into this system.

[0033] Economic efficiency: The automated testing system constructed according to the present invention can meet the expansion needs for a period of time, can be continuously integrated and deployed according to development needs, has strong adaptability, is easy to upgrade and saves costs. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the automated testing system architecture of the present invention;

[0035] Figure 2 Functional composition diagram;

[0036] Figure 3 Package the components and provide a directory structure diagram;

[0037] Figure 4 This is a directory diagram of the component's executable program;

[0038] Figure 5 A general message packet diagram;

[0039] Figure 6 Graph of the proxy loading process for the client;

[0040] Figure 7 This is a diagram showing the integration of the B / S interface.

[0041] Figure 8 This is a diagram of the test system. Detailed Implementation

[0042] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0043] This invention belongs to the field of automated testing technology, specifically a design method for an open, scalable, and general-purpose automated testing platform framework for hardware devices. Addressing the situation where existing automated testing systems lack the capability to test new product types due to new product additions, this invention constructs an open and scalable component integration method. By extending components on both the test system and test agent sides, the test management content for new product features and the test agent are integrated into the existing test system. Through the construction of a loosely coupled message bus, information exchange between the test agent and the test server is achieved, enabling the existing test system to fully acquire the capability to test new products.

[0044] 1) Test object

[0045] This product's testing system is designed for testing various product forms, including boards, modules, and complete machines. Boards and modules cannot be tested independently and require testing fixtures to complete the testing.

[0046] 2) Test system architecture

[0047] This testing system is centered around a test agent, supporting customized project testing software for individual devices at the upper level and integrating customized project tooling or the host machine under test at the lower level, achieving vertical interconnection. It drives various products to complete automated testing, and the test results are sent back to the test server. The overall architecture of the testing system is as follows: Figure 1 As shown.

[0048] The test system architecture includes a management layer, a communication layer, a proxy layer, a basic support layer, and a product layer.

[0049] The management layer, or test server, is responsible for managing the testing process of all products, including its own general test modules and various integrated custom test components.

[0050] The communication layer, or communication proxy, provides a communication channel between the test server and the test client;

[0051] The proxy layer, or test proxy software, runs on the device under test or the host tooling and drives the completion of various tests.

[0052] The basic support layer includes customized tooling for various equipment, and the installation and deployment of test agent software on the host equipment.

[0053] The product layer includes various devices under test, such as circuit boards and complete machines. Test agents can be directly installed on complete machines as needed.

[0054] 3) Functional Components

[0055] The automated testing system of this invention comprises three parts: a test server, a test client, and a communication proxy, as follows: Figure 2 As shown.

[0056] 4) Function Introduction

[0057] The test server includes: personnel maintenance module, task management module, task log module, device under test management module, test script configuration management module, test record management module, test component engine, and test components.

[0058] The personnel maintenance module mainly provides information management for testers and authenticates the identities of accessing users to ensure their legitimacy.

[0059] The task management module distributes different test items for different test devices to the test client as tasks. The test client executes the test tasks and returns the test results.

[0060] The task log module records the status of the task execution process, ensuring that the testing process is traceable.

[0061] The Device Under Test (DUT) management module centrally manages the DUTs supported by the test, providing device information to support the construction and execution of test tasks.

[0062] The test script configuration management module provides unified test script management for different test tasks and supports the distribution of test scripts to test clients for execution.

[0063] The test record management module records product test information from the perspective of product testing.

[0064] The test component engine provides functions such as loading, starting, stopping, and updating test components, ensuring that the dedicated management functions of the device under test are integrated into the system, thereby achieving unified management.

[0065] The test component encapsulates the dedicated management functions of the device under test in a component manner, uploads them to the test server for unified management and configuration, and the test component engine completes the full lifecycle management of the test component based on the configuration.

[0066] The test client includes: a task proxy module, a test status detection module, a test item management module, a test proxy component, and a proxy component engine.

[0067] The task agent module provides the functions of receiving specific test tasks and returning results.

[0068] The test status detection module provides the worker status of its own client and its components and reports it to the test server.

[0069] The test item management module provides management of test scripts and their test items, and notifies the test component to call the test script to execute automated tests based on the test task being executed.

[0070] The test agent component is a functional module that provides the ability to customize test items for the device under test.

[0071] The proxy component engine provides full lifecycle management functions for test components, including loading, starting, stopping, and updating.

[0072] Communication agents employ methods such as communication message packetization, one-to-one message distribution, and one-to-many message distribution.

[0073] The communication message packet constructs an extensible message communication format, ensuring that after the test server and test client integrate the test components and test proxy components respectively, they can support the addition of new test communication types.

[0074] Example 1:

[0075] Test components and test proxy components are packaged according to a unified packaging structure, such as... Figure 3 As shown, this includes: devinfo.json and the component directory;

[0076] `devinfo.json` is the component's description file and serves as the entry point. A typical structure for `devinfo.json` is as follows. It should be noted that the following is merely an example and can be extended as needed.

[0077] {

[0078] "name":"Device Name",

[0079] "manufacture": "manufacturer"

[0080] "version":"Proxy version number",

[0081] "devID":"Device ID",

[0082] "function":"Equipment Purpose",

[0083] "componenttype":"Client-side component / Server-side component",

[0084] "messageport":"Local communication port number",

[0085] "linuxstart":"Path to the Linux system startup script",

[0086] "linuxstop":"Path to the stop script in Linux system",

[0087] "uiurl":"URL of the access interface",

[0088] "windowsstart":"Path to the Windows system startup component script",

[0089] "windowsstop": "Path to the script for stopping the component in Windows system"

[0090] }

[0091] The component directory contains the executable programs for the components, and its directory structure is as follows: Figure 4 As shown.

[0092] The bin directory stores executable programs, the config directory stores configuration files, and the lib directory contains dependency libraries. startup.bat and startup.sh are startup scripts for different platforms, and stop.sh and stop.sh are stop scripts for different platforms. These can be configured based on devinfo.json.

[0093] To ensure that the test server and test client, after integrating the test proxy component, can process new messages generated by new products during testing, the message encapsulation design needs to support message extensibility. The communication medium between the test server and client can be a message queue that supports one-to-one or one-to-many communication. Based on this, messages are further encapsulated, with the encapsulation result as follows: Figure 5 As shown.

[0094] The message consists of a header and a body. The header comprises a message header, device type, device identifier, message type, and message length. The message header marks the start of the message and is 2 bytes long. The device type identifies the length of the device under test, 4 bytes is recommended, and the device identifier is the devID from devinfo.json, also 4 bytes long. The message type is determined based on actual needs, 4 bytes is recommended. The message length is the length of the message body, 4 bytes is recommended.

[0095] The test client tests the proxy component loading process as follows: Figure 6 As shown below.

[0096] After the client's main program starts, the proxy component engine scans the storage path of the test proxy components, checks each component directory under that path, and scans and identifies the devinfo.json file. It validates the identified JSON file according to format requirements; if the format is invalid, an error log is generated, and the current component stops loading. If the format is valid, the file content is parsed, file information is loaded, and the location of the startup script is identified based on the file information. The script is then invoked to start the component. If startup fails, an error log is generated, and the current component stops starting. If startup is successful, the proxy component engine publishes its own port information to the test proxy component port configured in the JSON file. The test proxy component receives this information and stores its own port, thus establishing a local communication channel between the client's proxy component engine and the test proxy component. At this point, the component loading process ends.

[0097] The server-side component loading process is the same as the client-side test proxy component loading process. The difference is that the test component includes a human-computer interface. When a user accesses the component, the server constructs the complete URL of the accessed interface by concatenating the url and messageport attribute values ​​from the devinfo.json configuration file. A B / S integration approach is recommended, and the integration effect is as follows: Figure 7 As shown.

[0098] Test environment such as Figure 8 As shown. The test server is deployed on a remote server. The device under test (DUT) includes complete machines, boards, and modules. Boards and modules are implemented using test fixtures. The test fixture's main control board deploys a test client that integrates the corresponding test agent components for the test boards and modules. The complete machine is directly connected to the test network, and its internal components include the test client and corresponding test agent components. Both the test server and the test client integrate communication agents, serving as the medium for data communication during the test. After the test begins, the user accesses the test server through their test machine, sets up test tasks, and executes them. The automated test system sends the test tasks to the test client of the DUT fixture or the DUT host via the network. The test client identifies the test device category, invokes the test agent to complete the relevant tests, and returns the results to the test client, which then returns the results to the server.

[0099] When performing test tasks, different testers can access the test server through the test machine network to carry out multiple test tasks in parallel, and the test results are sent back to the general automated test system.

[0100] Beneficial effects:

[0101] Through this design, the automated testing system can easily integrate new equipment-specific test content in terms of server-side, client-side, and communication methods between the client and server, supporting the system's ability to adapt to new product testing. The invention has the following technical effects:

[0102] Openness: This invention is not focused on any specific field and has broad applicability.

[0103] Scalability: Test components and test proxy components that meet the packaging requirements can all be integrated into this system.

[0104] Economic efficiency: The automated testing system constructed according to the present invention can meet the expansion needs for a period of time, can be continuously integrated and deployed according to development needs, has strong adaptability, is easy to upgrade and saves costs.

[0105] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An open automated testing system for hardware devices, characterized in that, The testing system includes: a test server, a test client, and a communication proxy; The test server includes: personnel maintenance module, task management module, task log module, device under test management module, test script configuration management module, test record management module, test component engine and test components; The personnel maintenance module is used to manage test personnel information and authenticate the identities of accessing users to ensure their legitimacy. The task management module is used to distribute different test items for different test devices to the test client as tasks. The test client executes the test tasks and returns the test results. The task log module is used to record the status of the task execution process to ensure that the testing process is traceable; The Device Under Test (DUT) management module is used to centrally manage the DUTs supported by the test, and to provide device information support for the construction and execution of test tasks. The test script configuration management module provides unified test script management for different test tasks and supports the distribution of test scripts to test clients for execution. The test record management module is used to record product test information from a product testing perspective. The test component engine provides functions for loading, starting, stopping, and updating test components, ensuring that the dedicated management functions of the device under test are integrated into the system, thereby achieving unified management. Test components are used to encapsulate the dedicated management functions of the device under test in a component manner, upload them to the test server for unified management and configuration, and the test component engine completes the full lifecycle management of the test components based on the configuration; The test client includes: a task proxy module, a test status detection module, a test item management module, a test proxy component, and a proxy component engine; The task proxy module is used to provide the functions of receiving specific test tasks and returning results; The test status detection module is used to provide the worker status of its own client and its components and report it to the test server; The test item management module is used to manage test scripts and their test items, and to notify the test component to call the test script to execute automated tests based on the test task being executed. Test agent component, a functional module used to provide customized test items for the device under test; The proxy component engine provides full lifecycle management functions for loading, starting, stopping, and updating test components; The communication agent employs communication message packetization, one-to-one message distribution, and one-to-many message distribution methods. The communication message packet constructs an extensible message communication format, ensuring that after the test server and test client integrate the test components and test proxy components respectively, they can support the addition of new test communication types.

2. The open automated testing system for hardware devices as described in claim 1, characterized in that, This testing system supports customized project testing software for equipment at the top and integrates customized project tooling or host under test at the bottom, achieving vertical interconnection, driving various products to complete automated testing, and sending test results back to the testing server.

3. The open automated testing system for hardware devices as described in claim 1, characterized in that, Test components and test proxy components are packaged according to a unified packaging structure. devinfo.json is the component description file and serves as the entry file, including devinfo.json and the component directory; The devinfo.json file includes: manufacturer, agent version number, device identifier, device purpose, client / server components, local communication port number (messageport), path to the startup script under Linux, path to the stop script under Linux, URL of the access interface, path to the startup component script under Windows, and path to the stop component script under Windows. The component directory contains the executable programs for the components.

4. The open automated testing system for hardware devices as described in claim 3, characterized in that, The component directory includes: the bin directory for storing executable programs, the config directory for storing configuration files, the lib directory for storing dependency libraries, startup.bat and startup.sh for startup scripts on different platforms, and stop.sh and stop.sh for stopping scripts on different platforms, all configured based on devinfo.json.

5. The open automated testing system for hardware devices as described in claim 3, characterized in that, The communication medium between the test server and client is a message queue that supports one-to-one and one-to-many communication, and the messages are encapsulated a second time.

6. The open automated testing system for hardware devices as described in claim 5, characterized in that, The message consists of a header and a body. The header comprises a message header, device type, device identifier, message type, and message length. The message header marks the start of the message and is 2 bytes long. The device type identifies the length of the device under test, with 4 bytes recommended. The device identifier is the devID from devinfo.json, with a recommended length of 4 bytes. The message type is determined based on actual needs, with 4 bytes recommended. The message length is the length of the message body, with a recommended length of 4 bytes.

7. The open automated testing system for hardware devices as described in claim 1, characterized in that, The loading process of the test proxy component on the test client includes: After the client main program starts, the proxy component engine scans the storage path of the test proxy component, checks the various component directories under the path, and scans and identifies devinfo.json; the identified JSON file is validated according to the format requirements. If the format is invalid, an error log is generated, and the current component stops loading; if the format is valid, the file content is parsed, the file information is loaded, and the location of the startup script is identified based on the file information. The script is then called to start the component. If startup fails, an error log is generated, and the current component stops starting; if startup is successful, the proxy component engine publishes its own port information to the test proxy component port configured in the JSON file. After receiving the information, the test proxy component stores its own port, and the local communication channel between the client proxy component engine and the test proxy component is established; at this point, the loading process of the test proxy component ends.

8. The open automated testing system for hardware devices as described in claim 6, characterized in that, The server-side test component includes a human-machine interface. When a user accesses the component, the server concatenates the url and messageport attribute values ​​in the devinfo.json configuration file to obtain the complete URL of the component's interface.

9. The open automated testing system for hardware devices as described in claim 1, characterized in that, The testing environment of this testing system is as follows: the test server is deployed on a remote server, and the devices under test include complete machines, boards, and modules. The boards and modules are completed using test fixtures. The test client, which integrates the test agent components corresponding to the test boards and modules, is deployed on the main control board of the test fixture. The complete machine is directly connected to the test network, and the test client and corresponding test agent components are deployed inside the complete machine. Both the test server and the test client integrate communication agents, which serve as the medium for data communication during the test. After the test begins, the user accesses the test server through their test machine to set up and execute test tasks. The automated testing system sends test tasks to the test client via the network to the tooling or host of the device under test. The test client identifies the type of test device, calls the test agent to complete the relevant tests, and returns the results to the test client. The test client then returns the results to the server.

10. The open automated testing system for hardware devices as described in claim 9, characterized in that, When executing test tasks, different testers access the test server through the test machine network to enable multiple test tasks to be carried out in parallel, and the test results are sent back to the general automated test system.

Images