Generality test system for digital products and test method thereof

Abstract

The invention discloses a generality test system for digital products and a test method thereof, and relates to the technical field of automatic test, and the system comprises an equipment management module which is used for searching, displaying and communication configuration of test resources and mapping management of a logic instrument and a physical instrument; the communication management module is used for loading and analyzing a communication protocol file compiled in an XML (Extensible Markup Language) format to realize data interaction and bus monitoring between a digital product and a test system; the test execution module is used for calling the generality test index library, generating and executing a test case of the digital product according to the configuration file, and completing automatic test and manual debugging; the data storage module is used for performing unified structured storage on the test process information and the test result; the invention further provides a testing method. According to the invention, the dependence of traditional test software on software personnel can be reduced, the development period of the test software is shortened, the reuse rate of general functions is improved, and the development and maintenance cost of the test software is reduced.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, specifically to a common testing system and method for digital products, which can be widely applied to the automated testing, verification, and quality inspection of various digital electronic products with communication interfaces or signal interaction capabilities. Background Technology

[0002] The statements in this section are provided only as background information in connection with this disclosure and may not constitute prior art.

[0003] With the widespread application of electronic information technology and embedded systems, the functions of digital products (such as communication equipment, control terminals, and measurement and control modules) are becoming increasingly complex, and the number of test items and test indicators is constantly increasing. To ensure product quality, it is usually necessary to develop dedicated automated testing systems for different models and series of digital products. Through coordinated operation with test instruments and test fixtures, the communication, signal output, functional performance, and other indicators of the products under test are detected and verified.

[0004] However, existing digital product testing systems (whose functions include...) Figure 2 As shown, the following problems are commonly found: 1. High degree of customization, poor reusability.

[0005] Existing testing systems typically rely on custom development based on specific product models and their communication protocols. The testing process, testing metrics, and communication protocols are highly coupled. When the product model changes or the protocol is upgraded, the testing program needs to be redeveloped or significantly modified, resulting in a large amount of repetitive work and low development efficiency.

[0006] 2. The testing instruments and systems are tightly bound together, making them difficult to port.

[0007] In existing solutions, the model, manufacturer, and driver interface of the test instrument are usually directly bound to the test program. When the test equipment is replaced or expanded, the instrument driver interface often needs to be rewritten, making it difficult for the test system to be universal and modular.

[0008] 3. Difficulty in adapting communication protocols.

[0009] Digital products have a variety of communication protocols and are frequently updated. There are differences in protocol formats, commands and parameter definitions between different products. Existing systems usually fix the protocol parsing and instruction processing logic in the program code. Once the protocol changes, the system needs to be recompiled, which makes maintenance work cumbersome.

[0010] 4. The testing process and metrics lack unified management.

[0011] Different product or project teams often maintain their own independent test metrics and process documents, lacking a common metric library and configuration management mechanism, which leads to inconsistent test standards, difficulties in version control, and affects test consistency and traceability.

[0012] 5. Data management is not standardized.

[0013] Existing test results are mostly stored in scattered text or log formats, with inconsistent data structures, making it difficult to perform statistical analysis and trace results later, thus reducing test management efficiency.

[0014] In summary, existing automated testing systems for digital products still have significant shortcomings in terms of reusability, scalability, protocol adaptability, and standardized data management. There is an urgent need for a common testing system that can achieve modular management of test resources, dynamic loading of communication protocols, common configuration of test indicators, and unified data storage, so as to improve the versatility, development efficiency, and ease of maintenance of the testing system. Summary of the Invention

[0015] The purpose of this invention is to address the shortcomings of existing automated testing systems for digital products, such as high degree of customization, poor reusability, difficulty in protocol adaptation, and non-standardized test data management, by providing a common testing system and testing method for digital products. This aims to achieve modular, configurable, and universal design of the testing system, significantly improving the reusability of the testing process and the efficiency of system maintenance.

[0016] Specifically, the present invention aims to achieve the following technical objectives: 1. Achieve unified management and reusability of test resources.

[0017] By establishing a mapping relationship between logical instruments and physical instruments, and adopting a dual-mapping driver management mechanism of DLL and XML files, the test instruments and fixtures can be plugged and played, enabling the system to quickly adapt to different models of test equipment without modifying the program code.

[0018] 2. Implement dynamic loading and parsing of communication protocols.

[0019] By designing an extensible XML protocol file structure, the data relationships and hierarchies in the communication protocol are defined in a configurable manner, enabling the test system to automatically complete initialization, command issuance, and data parsing according to the protocol file, thus solving the system reconstruction problem caused by frequent protocol updates.

[0020] 3. Achieve commonality in test metrics and parameterized generation of test cases.

[0021] By establishing a common test indicator library, the test indicators of digital products are decoupled from the test process. Combined with the parameterized loading method of Excel configuration files, corresponding test cases can be flexibly generated according to different product models, thereby improving the reusability of the test process.

[0022] 4. Implement data-driven management of the testing process and results.

[0023] Through a unified data storage module, the test process, test results, and environmental information are stored in a structured manner and displayed visually. It supports result query, statistics, and export, thereby improving the traceability and analysis efficiency of test data.

[0024] 5. Improve system development efficiency and maintenance convenience.

[0025] Through the modular, configurable, and decoupled design described above, the reusability of the test system across different products is significantly improved, reducing the amount of repetitive development work and shortening the development and testing cycle of the test system.

[0026] The technical solution of the present invention is as follows: A common testing system for digital products includes: The device management module is used to search, display, configure communication with, and manage the mapping between logical and physical instruments for test resources. The communication management module is used to load and parse communication protocol files compiled in XML format to realize data interaction and bus monitoring between digital products and the testing system; The test execution module is used to call the common test indicator library, generate and execute test cases for digital products according to the configuration file, and complete automatic testing and manual debugging. The data storage module is used to store test process information and test results in a unified structure, and supports data querying, display and export.

[0027] Furthermore, the device management module includes: The logical instrument to physical instrument mapping unit is used to map the logical instrument names defined in the test cases to the actual connected physical instruments one by one. The driver management unit is used to establish a mapping relationship between instrument models and driver interfaces based on a combination of dynamic link libraries (DLLs) and XML configuration files, enabling dynamic loading and reuse of test instrument drivers.

[0028] Furthermore, when the drive management unit detects the access of a new model of test instrument, it parses the XML driver description file corresponding to that model and calls the matching DLL interface to realize instrument initialization and communication, thereby completing the device replacement without modifying the test program.

[0029] Furthermore, the communication management module includes: The protocol file management unit is used to load, parse, and manage communication protocol files, and automatically generate communication instructions and parameter mappings based on the data structure defined in the file. The bus monitoring unit is used to display the sending and receiving information of protocol messages in real time, enabling monitoring and debugging of the communication process.

[0030] Furthermore, the communication protocol file is in XML format, and its file structure includes a Head node, a Bus node, a Config node, and a Frame node, which are used to define the protocol header information, communication bus type, communication parameter configuration, and frame format definition, respectively.

[0031] Furthermore, the test execution module includes: A common metrics library is used to store common test metrics for digital products; The test case generation unit is used to automatically generate test cases for digital products based on a common indicator library and combined with test grouping, wiring relationships, test indicators and parameter settings in an Excel configuration file. The execution control unit is used to execute tests according to the generated test cases, and provides two operating modes: automatic test mode and manual debugging mode.

[0032] Furthermore, the Excel configuration file includes the following fields: The test group, the corresponding row number of the logic instrument, the test indicator name, the execution module name, the configuration parameter name and parameter value are all specified. After loading this configuration file, the test execution module will automatically generate the corresponding test case sequence.

[0033] Furthermore, the data storage module uses a unified data structure to store test process data and test results, and realizes real-time data display, historical query and file export through human-computer interaction interface.

[0034] Furthermore, through modular and configurable design, the system enables the test environment to be configured and test cases to be loaded without modifying the test program code when switching between different digital products, thus achieving universal reuse of the test process.

[0035] This invention also proposes a common testing method for digital products, based on the aforementioned common testing system for digital products, comprising: Step S1: Configure test resources through the device management module, complete the mapping between logical instruments and physical instruments, and load the corresponding drivers; Step S2: Load and parse the communication protocol file of the digital product through the communication management module to establish a communication connection; Step S3: Read the configuration file through the test execution module and generate test cases based on the common indicator library; Step S4: Execute the automatic test or manual debugging process, and monitor the communication data and test status in real time; Step S5: The test process and results are stored, displayed, and exported in a structured manner through the data storage module.

[0036] Compared with existing technologies, the advantages of this invention are: 1. The common testing system and testing method proposed in this invention reduce the dependence of traditional testing software on software personnel, shorten the development cycle of testing software, improve the reusability of common functions, and reduce the development and maintenance costs of testing software. Experimental data shows that the efficiency of test process development and joint testing is improved by 60%, and the software reusability rate increases from 10% to 80%.

[0037] 2. The common testing system and testing method proposed in this invention can solve the problems of high code maintenance costs caused by continuous iteration and modification of device communication protocols, diverse combinations of testing resources (instruments, equipment, switch matrices), highly repetitive hardware driver development, and the conflict between the rapid development of product models and the inability of the testing system to be quickly reused when developing automatic testing systems for such products.

[0038] 3. The common testing system and testing method proposed in this invention can realize the dynamic loading and monitoring of bus protocols; complete the virtualization characterization of test resources and realize plug-and-play instruments; decouple the test process and test indicators, enabling rapid development of test processes and reuse of test indicators. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0040] Figure 1 A block diagram illustrating the principle of a common testing system for digital products; Figure 2 This is a functional diagram of a typical automated testing software. Figure 3 This is a diagram illustrating the logic relationship between the instrument driver and management. Figure 4 This is a diagram showing the data relationships in the protocol file. Figure 5 This is a schematic diagram of the monitoring function interface; Figure 6 A diagram showing the relationship between test cases and common metrics; Figure 7 Configure instances for logical and physical devices; Figure 8 This is an example of the correspondence between underlying instrument models and drivers; Figure 9 This is a schematic diagram of the agreement document; Figure 10 This is an example of an interface bus monitoring interface; Figure 11 The configuration diagram of the logic instruments for the test cases; Figure 12 A diagram showing the configuration of test cases based on common metrics; Figure 13 This is the interface for executing test cases. Detailed Implementation

[0041] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0042] The features and performance of the present invention will be further described in detail below with reference to embodiments.

[0043] Example 1 Please see Figure 1 A common testing system for digital products, specifically including the following modules: The device management module is used to search, display, configure communication for test resources, and manage the mapping between logical instruments and physical instruments. Specifically, it is mainly used to manage test resources (test instruments, test fixtures, and other equipment) and instrument driver management. The management of test resources includes resource search, display, and communication functions, as well as the configuration function of the correspondence between logical instruments and physical instruments. The communication management module loads and parses communication protocol files compiled in XML format, enabling data interaction and bus monitoring between digital products and the testing system. Specifically, it mainly implements the interface communication functions between digital products and the automated testing system, including protocol file management and bus monitoring. The protocol file management function is developed using the general-purpose extensible markup language XML, and the data relationships and structural hierarchy of the protocol are designed. The bus monitoring function loads the protocol files and provides a human-machine interface to monitor bus protocol transmission and reception. The test execution module is used to call the common test indicator library, generate and execute test cases for digital products according to the configuration file, and complete automatic testing and manual debugging. Specifically, it is mainly used to implement the test case loading and test case execution functions. The common testing system decouples the automatic testing function, encapsulates the common test indicators of digital products into a common indicator library, and generates test cases for different products by logically combining and configuring parameters based on the common indicator library.

[0044] The data storage module is used to store test process information and test results in a unified structure, and supports data querying, display, and export. Specifically, it is mainly used to realize the structured and unified storage of test process data and test results, and the functions of querying, displaying, and exporting test data.

[0045] In this embodiment, specifically, the device management module includes: The logic instrument to physical instrument mapping unit is used to map the names of logic instruments defined in the test cases to the actual physical instruments connected; that is, it defines the types of instruments that digital products such as signal sources, spectrum analyzers, and oscilloscopes may use. Users can specify the physical instruments found to be mapped to specific logic instruments, as shown in Table 1. Table 1. Logical Device to Physical Device Mapping Table

[0046] The driver management unit is used to establish a mapping relationship between instrument models and driver interfaces based on a combination of dynamic link libraries (DLLs) and XML configuration files, enabling dynamic loading and reuse of test instrument drivers. In this embodiment, specifically, when the driver management unit detects the access of a new model of test instrument, it parses the XML driver description file corresponding to the model and calls the matching DLL interface to realize instrument initialization and communication, thereby completing the device replacement without modifying the test program; That is, Figure 3As shown, this implements the logical relationship between the programmable instruction library for common instrument types and the corresponding instrument types. Based on the development manual provided by the instrument manufacturer, the instrument function interfaces of the common testing system are implemented. Dynamic link library files are edited, optimized, and extended. Simultaneously, XML files are used to establish the correspondence between dynamic link library files and instrument models, enabling the use of the same driver without requiring code modification when expanding to different models.

[0047] In this embodiment, specifically, the communication management module includes: The protocol file management unit is used to load, parse, and manage communication protocol files, and automatically generate communication instructions and parameter mappings based on the data structure defined in the file. The bus monitoring unit is used to display the sending and receiving information of protocol messages in real time, enabling monitoring and debugging of the communication process.

[0048] In this embodiment, for details, please refer to... Figure 4 and Figure 5 The communication protocol file is in XML format, and its file structure includes a Head node, a Bus node, a Config node, and a Frame node, which are used to define the protocol header information, communication bus type, communication parameter configuration, and frame format definition, respectively.

[0049] In this embodiment, for details, please refer to... Figure 6 The test execution module includes: A common metrics library is used to store common test metrics for digital products; The test case generation unit is used to automatically generate test cases for digital products based on a common indicator library and combined with test grouping, wiring relationships, test indicators and parameter settings in an Excel configuration file. The execution control unit is used to execute tests according to the generated test cases, and provides two operating modes: automatic test mode and manual debugging mode.

[0050] In this embodiment, specifically, the Excel configuration file includes the following fields: The test group, the corresponding row number of the logic instrument, the test indicator name, the execution module name, the configuration parameter name and the parameter value are all specified. After loading this configuration file, the test execution module will automatically generate the corresponding test case sequence. In short, the test case execution function enables automated testing and manual debugging of digital products. Automated testing includes functions such as selecting different product models, inputting product numbers, testers, test environments, starting / stopping tests, displaying test data charts, and real-time display of test process logs. Manual debugging mainly encapsulates the bus monitoring function provided by data management, translates the underlying protocol, and makes it easier for various personnel to use.

[0051] In this embodiment, the data storage module uses a unified data structure to store test process data and test results, and enables real-time data display, historical query, and file export through a human-computer interaction interface.

[0052] In this embodiment, specifically, the system, through modular and configurable design, enables the test environment configuration and test case loading to be completed without modifying the test program code when switching between different digital products, thus achieving universal reuse of the test process.

[0053] In the embodiments, it should also be noted that the common testing system for digital products described in this invention can be implemented through computer software. Each functional module of the system can be stored in a computer-readable storage medium in the form of software modules, program instructions, or executable code, and executed by a computer or test control platform to complete the aforementioned functions.

[0054] Therefore, based on the above system architecture, those skilled in the art can easily develop corresponding common testing software for digital products to achieve all the functions of this invention, which will not be elaborated further here.

[0055] In this embodiment, a common testing method for digital products is also proposed, based on the aforementioned common testing system for digital products, including: Step S1: Configure test resources through the device management module, complete the mapping between logical instruments and physical instruments, and load the corresponding drivers; Step S2: Load and parse the communication protocol file of the digital product through the communication management module to establish a communication connection; Step S3: Read the configuration file through the test execution module and generate test cases based on the common indicator library; Step S4: Execute the automatic test or manual debugging process, and monitor the communication data and test status in real time; Step S5: The test process and results are stored, displayed, and exported in a structured manner through the data storage module.

[0056] Example 2 Figures 7 to 13 The screenshots shown are screenshots of the interface and text used to demonstrate the automatic testing function for a digital product based on this common testing software.

[0057] Figure 11 This demonstration shows the unique identifier of the logic device required by the product in this implementation example—signal source 1, port 1, and RF output X1. Figure 7 It provides a screenshot showing the physical mapping of the logic device (signal source 1, port 1, RF output X1) to the user; Figure 8This refers to the mapping relationship between instrument drivers used by different instrument models. For example, the DriverName used by Agilent's E8257D is SigAgilentCommon. This functional architecture allows physical devices to be used plug-and-play in the test system without modifying test cases.

[0058] Figure 9 This document showcases the interface protocol file of the product used in this implementation example. Based on XML, the file defines a Head node describing the document's designer, development time, version, project number, etc.; a Bus node describing the type of bus used by the product, such as RS232 serial port, TCP, UDP, etc.; and a Config node under Bus describing the bus's configuration information, such as the serial port number, baud rate, stop bits, etc.; and a Frame node describing the specific commands.

[0059] Figure 10 This demonstrates the bus monitoring interface after loading the protocol file, showcasing functions such as bus initialization, distribution, reporting and parsing, and shutdown. This functional architecture allows for arbitrary modifications to the protocol file (adding or removing fields, increasing or decreasing the number of commands, etc.) without altering the test software, provided the interface protocol remains unchanged.

[0060] Figure 12 This demonstration showcases the product test case configuration file for this implementation example. The file, created using Excel, defines test groups, wiring relationships, test metrics, execution modules, configuration parameter names, and parameter values ​​to describe the test cases. Test groups are used to display the hierarchical relationship of the test metric tree structure; the numbers mentioned in the wiring relationships indicate... Figure 11 The row number of the logic instrument required in the test; the test index refers to the name of the index that this product needs to test; the execution module refers to the name of the common index corresponding to the test index; the configuration parameter name refers to the name of the configurable parameter provided to the public by the common index; the parameter value is provided to the user to configure the parameter to the specific value required by this product.

[0061] Figure 13 This is the automated testing interface after loading the configuration file. Users input product information, test location, ambient temperature and humidity, etc., and then select the metrics to be tested. They can then start and stop the test, with test data displayed in real-time in chart format during the test. This functional architecture enables the scalability of test cases and the reusability of common test metrics.

[0062] The embodiments described above merely illustrate specific implementation methods of this application, and while the descriptions are detailed and specific, they should not be construed as limiting the scope of protection of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the technical solution of this application, and these modifications and improvements all fall within the scope of protection of this application.

[0063] This background section is provided to generally present the context of the invention. The work of the currently named inventors, the work to the extent described in this background section, and aspects of this section that did not constitute prior art at the time of application are neither expressly nor impliedly acknowledged as prior art to the invention.

Claims

1. A common testing system for digital products, characterized in that, include: The device management module is used to search, display, configure communication with, and manage the mapping between logical and physical instruments for test resources. The communication management module is used to load and parse communication protocol files compiled in XML format to realize data interaction and bus monitoring between digital products and the testing system; The test execution module is used to call the common test indicator library, generate and execute test cases for digital products according to the configuration file, and complete automatic testing and manual debugging. The data storage module is used to store test process information and test results in a unified structure, and supports data querying, display and export.

2. The common testing system for digital products according to claim 1, characterized in that, The device management module includes: The logical instrument to physical instrument mapping unit is used to map the logical instrument names defined in the test cases to the actual connected physical instruments one by one. The driver management unit is used to establish a mapping relationship between instrument models and driver interfaces based on a combination of dynamic link libraries (DLLs) and XML configuration files, enabling dynamic loading and reuse of test instrument drivers.

3. The common testing system for digital products according to claim 2, characterized in that, When the driver management unit detects the access of a new model of test instrument, it parses the XML driver description file corresponding to that model and calls the matching DLL interface to realize instrument initialization and communication, thereby completing the device replacement without modifying the test program.

4. The common testing system for digital products according to claim 1, characterized in that, The communication management module includes: The protocol file management unit is used to load, parse, and manage communication protocol files, and automatically generate communication instructions and parameter mappings based on the data structure defined in the file. The bus monitoring unit is used to display the sending and receiving information of protocol messages in real time, enabling monitoring and debugging of the communication process.

5. The common testing system for digital products according to claim 4, characterized in that, The communication protocol file is in XML format, and its file structure includes a Head node, a Bus node, a Config node, and a Frame node, which are used to define the protocol header information, communication bus type, communication parameter configuration, and frame format definition, respectively.

6. The common testing system for digital products according to claim 1, characterized in that, The test execution module includes: A common metrics library is used to store common test metrics for digital products; The test case generation unit is used to automatically generate test cases for digital products based on a common indicator library and combined with test grouping, wiring relationships, test indicators and parameter settings in an Excel configuration file. The execution control unit is used to execute tests according to the generated test cases, and provides two operating modes: automatic test mode and manual debugging mode.

7. The common testing system for digital products according to claim 6, characterized in that, The Excel configuration file includes the following fields: The test group, the corresponding row number of the logic instrument, the test indicator name, the execution module name, the configuration parameter name and parameter value are all specified. After loading this configuration file, the test execution module will automatically generate the corresponding test case sequence.

8. The common testing system for digital products according to claim 1, characterized in that, The data storage module uses a unified data structure to store test process data and test results, and enables real-time data display, historical query, and file export through a human-computer interaction interface.

9. A common testing system for digital products according to claim 1, characterized in that, The system, through its modular and configurable design, enables the configuration of the test environment and loading of test cases without modifying the test program code when switching between different digital products, thus achieving universal reuse of the test process.

10. A common testing method for digital products, characterized in that, A common testing system for digital products based on any one of claims 1-9 includes: Step S1: Configure test resources through the device management module, complete the mapping between logical instruments and physical instruments, and load the corresponding drivers; Step S2: Load and parse the communication protocol file of the digital product through the communication management module to establish a communication connection; Step S3: Read the configuration file through the test execution module and generate test cases based on the common indicator library; Step S4: Execute the automatic test or manual debugging process, and monitor the communication data and test status in real time; Step S5: The test process and results are stored, displayed, and exported in a structured manner through the data storage module.

Images