Hardware equipment-oriented open type automatic test system

Abstract

The invention relates to an open type automatic testing system for hardware equipment, and belongs to the technical field of automatic testing. Aiming at the situation that an original automatic testing system does not have the new product testing capability due to the newly-added product type of an enterprise, an open and extensible component integration mode is constructed, and the testing system side component expansion and the testing agent side component expansion are performed respectively; test management content of new product characteristics and a test agent are accessed to an original test system, and information intercommunication between the test agent and a test server is realized by constructing a message bus which is loosely coupled with the test, so that the original test system has the test capability of the new product. According to the automatic test system, special test contents of newly added equipment can be conveniently integrated in the aspects of the server side, the client side and the communication mode between the client side and the server side, and the system is supported to adapt to the new product test capability.

Description

Technical Field

[0001] The invention belongs to the technical field of automated testing, and in particular relates to an open automated testing system for hardware devices. Background Art

[0002] Product automated testing technology has been widely used in product manufacturing, information technology and other fields, and has played a very important role in reducing personnel costs and improving product quality. However, with the rapid development of enterprises, the number of enterprise products has gradually increased, and the number of test items and test methods for new products has also gradually increased. In this case, the automated testing system planned based on the characteristics of the company's early products and business will be difficult to adapt to the testing requirements of new products. In order to meet the testing requirements of new and old products, many enterprises have to re-plan and design a new generation of automated testing systems, which has increased the cost of enterprise investment.

[0003] A typical automated testing system consists of two parts: a testing server and a testing agent. The present invention focuses on solving three types of problems, so that the automated testing system has expansion capabilities.

[0004] 1) Server-side integration: Building server-side scalability capabilities so that the server can easily integrate new product testing management content.

[0005] 2) Client integration: building client scalability capabilities so that the client can more easily integrate new product testing functions.

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

[0007] In view of the above situation, the present invention designs an open and extensible testing platform framework according to the characteristics of software and hardware products. It is capable of facing new product forms and can be connected to this system through a small amount of expansion and development, so that the original testing system has the ability to test new products, constantly adapt to the needs of enterprise development, and reduce enterprise investment costs. Summary of the invention

[0008] 1. Technical issues to be resolved

[0009] The technical problem to be solved by the present invention is how to provide an open automatic test system oriented to hardware devices to solve the expansion problem of the automatic test system.

[0010] (II) Technical solution

[0011] In order to solve the above technical problems, the present invention proposes an open automated testing system for hardware devices, the testing system comprising: a testing server, a testing client and a communication agent;

[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 provide information management for testers, identify the identities of access users, and ensure the legality of the identities;

[0014] The task management module is used to send different test items of different test devices to the test client in the form of 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 test process is traceable;

[0016] The device management module is used to centrally manage the devices supported by the test and to support the construction and execution of test tasks as device information;

[0017] The test script configuration management module is used to provide unified test script management for different test tasks and support sending to test clients for execution;

[0018] The test record management module is used to record product test information from the product test perspective;

[0019] The test component engine is used to provide the functions of loading, starting, stopping and updating the test components, ensuring that the dedicated management related functions of the tested equipment are integrated into the system, so as to achieve unified management;

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

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

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

[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 perform automated testing based on the test task being executed;

[0025] Test agent component, a functional module for providing customized test item functions for the device under test;

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

[0027] The communication agent adopts communication message packaging, one-to-one message distribution, and one-to-many message distribution methods;

[0028] The communication message package constructs an extensible message communication format to ensure that the test server and test client can support new test communication types after integrating the test components and test agent components respectively.

[0029] (III) Beneficial effects

[0030] The present invention proposes an open automated testing system for hardware devices. Through the design of this solution, the automated testing system can conveniently integrate new device-specific testing content in terms of the server, the client, and the communication mode between the client and the server, and support the system to adapt to the testing capabilities of new products. The invention has the following technical effects:

[0031] Openness: The present invention does not focus on a specific field and has wide adaptability.

[0032] Extensibility: All packaging requirements of test components and test agent components can be connected to this system.

[0033] Economical: The automated testing system constructed according to the present invention can meet expansion requirements within a period of time, can be continuously integrated and deployed according to development needs, has strong adaptability, is easy to upgrade, and saves costs. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0035] Figure 2 It is a functional composition diagram;

[0036] Figure 3 Packaging components and directory structure diagram;

[0037] Figure 4 It is a component executable program directory map;

[0038] Figure 5 It is a general message packet diagram;

[0039] Figure 6 Load the proxy process map for the client;

[0040] Figure 7 This is the B / S interface integration diagram;

[0041] Figure 8 This is a diagram of the test system composition. DETAILED DESCRIPTION

[0042] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0043] The present invention belongs to the field of automated testing technology, and specifically is an open, extensible, and universal automated testing platform framework design method for hardware equipment. Aiming at the situation that the original automated testing system does not have the ability to test new products due to the addition of new product types by enterprises, the present invention constructs an open and extensible component integration method, and respectively connects the test management content and test agent of the new product characteristics to the original test system through the method of component expansion on the test system side and component expansion on the test agent side, and by constructing a message bus loosely coupled with the test, the test agent and the test server can realize information exchange, so that the original test system has the ability to test new products.

[0044] 1) Test object

[0045] The test objects of this product testing system include various product forms such as boards, modules, and complete machines. Boards and module devices cannot be tested independently and require the help of test tools to complete the test.

[0046] 2) Test system architecture

[0047] This test system is based on the test agent, which supports customized project test software for equipment upwards, integrates customized project tooling or tested hosts downwards, realizes vertical interconnection, drives various products to complete automated testing, and transmits test results back to the test server. The overall architecture of the test system is as follows: Figure 1 shown.

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

[0049] The management layer, i.e. the test server, is used to manage the test process of all products, including its own common test modules and various integrated customized test components;

[0050] The communication layer, i.e. the communication agent, provides a communication channel between the test server and the test client;

[0051] The agent layer, i.e. the test agent software, runs on the device under test or the host tooling to drive the completion of various tests;

[0052] Basic support layer, customized tooling for various devices, installation and deployment of test agent software on host devices;

[0053] The product layer includes various types of devices to be tested, such as boards, complete machines, etc., among which the test agent can be directly installed on the complete machine as needed.

[0054] 3) Functional composition

[0055] The automated testing system of the present invention comprises three parts: a testing server, a testing client and a communication agent. Figure 2 shown.

[0056] 4) Functional 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 tester information management, authenticates the identities of accessing users, and ensures the legitimacy of the identities.

[0059] The task management module sends different test items of different test devices to the test client in the form of 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 to ensure that the test process is traceable.

[0061] The device management module centrally manages the devices supported by the test and provides 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 sending to test clients for execution.

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

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

[0065] The test component encapsulates the dedicated management function part of the device under test in a component manner, uploads it to the test server for unified management and configuration, and the test component engine completes the full life cycle management of the test component based on the configuration.

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

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

[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 perform automated testing based on the test task being executed.

[0070] The test agent component is a functional module that provides customized test item functions for the device under test.

[0071] The agent component engine provides full life cycle management functions such as loading, starting, stopping, and updating of test components.

[0072] The communication agent adopts communication message packaging, one-to-one message distribution, one-to-many message distribution and other methods.

[0073] The communication message package constructs an extensible message communication format to ensure that the test server and test client can support new test communication types after integrating the test components and test agent components respectively.

[0074] Embodiment 1:

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

[0076] devinfo.json is a component description file, which serves as an entry file. The typical structure of devinfo.json is as follows. It should be noted that the following is only an example and can be expanded as needed.

[0077] {

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

[0079] "manufacture":"Manufacturer",

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

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

[0082] "function":"Device purpose",

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

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

[0085] "linuxstart":"Startup script path under Linux system",

[0086] "linuxstop":"Stop script path under Linux system",

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

[0088] "windowsstart":"Startup component script path under Windows system",

[0089] "windowsstop":"Stop component script path under Windows system"

[0090] }

[0091] The component directory is the executable program of the component. Its directory structure is as follows Figure 4 shown.

[0092] The bin directory is used to store executable programs, the config directory is used to store configuration files, and the lib directory is the path for storing dependency libraries. startup.bat and startup.sh are used for startup scripts on different platforms, and stop.sh and stop.sh are used for stop scripts on different platforms. They can be configured based on devinfo.json.

[0093] In order to ensure that the test server and test client can process new messages generated by new products when testing new products after integrating the test proxy components, the message package needs to be designed to support message scalability. The communication medium between the test server and the client can choose a message queue that supports one-to-one and one-to-many communication, and on this basis, the message is repackaged. The packaging result is as follows: Figure 5 shown.

[0094] The message consists of a header and a body, where the header consists of a message header, device type, device identifier, message type, and message length. The message header marks the beginning of the message, with a length of 2 bytes; the device type identifies the length of the device under test, with a recommended length of 4 bytes. The device identifier is the devID in devinfo.json, with a recommended length of 4 bytes; the message type is based on actual needs, with a recommended length of 4 bytes; the message length is the length of the message body, with a recommended length of 4 bytes.

[0095] The test client test agent component loading process is as follows Figure 6 As shown below.

[0096] After the client main program is started, the proxy component engine scans the test proxy component storage path, checks the various component directories under the path, and scans and identifies devinfo.json. The identified json file is verified according to the format requirements. If the format is illegal, an error log is generated and the current component stops loading. If the format is legal, the file content is parsed, the file information is loaded, and the startup script location is determined based on the file information. The script is called to start the component. If the startup fails, an error log is generated and the startup of the current component stops. If the 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 it, 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 opened. At this point, the component loading process ends.

[0097] The process of loading the server component is the same as the process of loading the test agent component on the client. The difference is that the test component contains a human-machine interface. When the user accesses the component, the server splices the url attribute value and the messageport attribute value in the devinfo.json configuration file to obtain the complete URL for accessing the component interface. It is recommended to use the B / S integration method. The integration effect is as follows: Figure 7 shown.

[0098] Test environment such as Figure 8 As shown. The test server is deployed on a remote server. The device under test includes the whole machine, boards and modules. The boards and modules are completed with the help of test fixtures. The test client is deployed on the main control board of the test fixture to integrate the test boards and modules corresponding to the test agent components. The whole machine is directly connected to the test network. The test client and the corresponding test agent components are deployed inside the whole machine. The test server and the test client each integrate a communication agent as a medium for data communication during the test process. After the test starts, the user accesses the test server through the test machine, sets the test task and executes it. The automated test system sends the test task to the test client of the device under test fixture or the host of the device under test through the network. The test client identifies the test device category, calls the test agent to complete the relevant test, and returns the result to the test client, which then returns the result to the server.

[0099] When executing 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 testing system.

[0100] Beneficial effects:

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

[0102] Openness: The present invention does not focus on a specific field and has wide adaptability.

[0103] Extensibility: All packaging requirements of test components and test agent components can be connected to this system.

[0104] Economical: The automated testing system constructed according to the present invention can meet expansion requirements within 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 is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. An open automated testing system for hardware devices, characterized in that: The test system includes: a test server, a test client and a communication agent; 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 provide information management for testers, identify the identities of access users, and ensure the legality of the identities; The task management module is used to send different test items of different test devices to the test client in the form of 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 test process is traceable; The device management module is used to centrally manage the devices supported by the test and to support the construction and execution of test tasks as device information; The test script configuration management module is used to provide unified test script management for different test tasks and support sending to test clients for execution; The test record management module is used to record product test information from the product test perspective; The test component engine is used to provide the functions of loading, starting, stopping and updating the test components, ensuring that the dedicated management related functions of the tested equipment are integrated into the system, so as to achieve unified management; Test components are used to encapsulate the dedicated management function part of the device under test in a component manner, upload it to the test server for unified management and configuration, and the test component engine completes the full life cycle management of the test component based on the configuration; The test client includes: a task agent module, a test status detection module, a test item management module, a test agent component and an agent component engine; The task agent module is used to provide the functions of receiving and returning results of specific test tasks; 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 perform automated testing based on the test task being executed; Test agent component, a functional module for providing customized test item functions for the device under test; The proxy component engine is used to provide full life cycle management functions for loading, starting, stopping, and updating test components; The communication agent adopts communication message packaging, one-to-one message distribution, and one-to-many message distribution; The communication message package constructs an extensible message communication format to ensure that the test server and the test client can support new test communication types after integrating the test components and the test agent components respectively.

2. The open automated testing system for hardware devices according to claim 1, characterized in that: The test system supports customized project test software for equipment upward, and integrates customized project tooling or tested hosts downward to achieve vertical interconnection, drive various products to complete automated testing, and transmit the test results back to the test server.

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

4. The open automated testing system for hardware devices as claimed in claim 3, characterized in that: The component directory includes: the bin directory is used to store executable programs, the config directory is used to store configuration files, the lib directory is the dependency library storage path, startup.bat and startup.sh are used for startup scripts on different platforms, and stop.sh and stop.sh are used for stop scripts on different platforms. They are configured based on devinfo.json.

5. The open automated testing system for hardware devices as claimed in claim 3, characterized in that: The communication medium between the test server and the client is a message queue that supports one-to-one and one-to-many communication, and the message is repackaged on this basis.

6. The open automated testing system for hardware devices as claimed in claim 5, characterized in that: The message consists of a packet header and a packet body, where the packet header consists of a message header, device type, device identifier, message type, and message length. The message header marks the beginning of the message and has a length of 2 bytes. The device type identifies the length of the device under test, and 4 bytes are recommended. The device identifier is the devID in devinfo.json, and the recommended length is 4 bytes. The message type is based on actual needs, and 4 bytes are recommended. The message length is the length of the message body, and the recommended length is 4 bytes.

7. The open automated testing system for hardware devices according to claim 1, characterized in that: The test client test proxy component loading process includes: after the client main program is started, the proxy component engine scans the test proxy component storage path, checks the various component directories under the path, and scans and identifies devinfo.json; the identified json file is verified according to the format requirements. If the format is illegal, an error log is generated and the current component stops loading; if the format is legal, the file content is parsed, the file information is loaded, and the startup script location is determined based on the file information, and the script is called to start the component. If the startup fails, an error log is generated and the startup of the current component stops; if the 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 opened; at this point, the test proxy component loading process ends.

8. The open automated testing system for hardware devices according to claim 6, characterized in that: The server-side test component includes a human-computer interface. When a user accesses the component, the server concatenates the url attribute value and the messageport attribute value in the devinfo.json configuration file to obtain the complete URL for accessing the component interface.

9. The open automated testing system for hardware devices according to claim 1, characterized in that: The test environment of the test system is as follows: the test server is deployed on a remote server, and the tested equipment includes the whole machine, boards and modules, wherein the boards and modules are completed with the help of test fixtures, and the test client is deployed on the main control board of the test fixture to integrate the test boards and the test agent components corresponding to the modules, and the whole machine is directly connected to the test network, and the test client and the corresponding test agent components are deployed inside the whole machine; the test server and the test client are each integrated with a communication agent as the medium for data communication during the test process; after the test starts, the user accesses the test server through the test machine where he is located, sets the test task and executes it; The automated testing system sends the test task to the test client of the device under test tooling or the device under test host through the network. The test client identifies the test device category, calls the test agent to complete the relevant tests, and returns the results to the test client, which then returns the results to the server.

10. The open automated testing system for hardware devices according to claim 9, characterized in that: When executing test tasks, different testers 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 testing system.

Images