Transparent perception multi-hardware platform test method, system and device and storage medium

Abstract

The invention discloses a transparent perception multi-hardware platform test method, system and device, and a storage medium, and relates to the technical field of multi-hardware platform test.A unified interface designed by the test system is designed with a keyword-driven idea, so that the distance between a test requirement and a program code is shortened, and the test efficiency is improved. Unlike a general keyword-driven framework, a uniform interface does not establish direct mapping of keywords to test scripts, but provides higher flexibility through a set of objects, behaviors, and data (i.e., keyword descriptions). Meanwhile, the unified interface is further used for generating function step description corresponding to the target hardware according to the keyword description, the unified interface is located on the uppermost layer of the whole test system and is responsible for transmitting high-level description in the test case downwards and converting the high-level description into structured information used in the system, and the efficiency of the test process is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-hardware platform testing, and in particular to a transparent perception multi-hardware platform testing method and system, device, and storage medium. Background Art

[0002] The use scenarios of multiple hardware platforms are becoming more and more extensive, with common scenarios such as cloud computing, edge computing, and embedded systems. In the use of multiple hardware platforms, due to the significant differences in the functions and forms of hardware devices, different hardware architectures, drivers, and performance characteristics bring great challenges to developers. Taking edge computing as an example, in order to test edge devices, traditional testing methods often require the development of test cases for each platform separately, resulting in increased development and testing costs.

[0003] In order to shield hardware differences, an existing solution is to abstract different hardware features through an abstraction layer to provide a unified hardware access interface, such as the HAL library. The HAL library is the hardware abstraction layer implementation of the STM32 series, and its design goal is to make STM32 products with similar peripherals compatible. Specifically, the HAL library implements the corresponding HAL module for each peripheral, including initialization, configuration and other functions, through which a high-level integration of specific hardware features is achieved.

[0004] Although the HAL library greatly simplifies the operation in the development process on STM32 hardware, it still has some limitations in the application scenario of multi-platform testing. First, compared with the abstract level of test requirements, the interface division granularity of the HAL library is too fine, resulting in the need to write additional redundant code in the actual test process, which is inefficient.

[0005] On the other hand, the keyword-driven framework is generally considered to be a way to implement the automated test framework. Its core concept is to decouple programming logic from test cases and test steps. By introducing the concept of keyword-driven into the design of the hardware abstraction layer, a direct mapping between test cases and test scripts can be achieved, thereby simplifying the writing of test scripts and reducing reliance on manual programming. However, under multiple hardware platforms, complex test scenarios are often encountered. Predefined keywords may not be sufficient to cope with complex test scenarios, requiring the writing of new keywords or manual intervention, which lacks flexibility.

[0006] Therefore, it is necessary to propose a new multi-hardware platform test system to improve the efficiency and flexibility of the existing multi-hardware platform test system. Summary of the invention

[0007] The present invention provides a transparent perception multi-hardware platform testing method and system, device, and storage medium, which are used to improve the use efficiency and flexibility of the existing multi-hardware platform testing system.

[0008] In order to solve the above technical problems, the first aspect of the present invention discloses a transparent perception multi-hardware platform testing system, the system comprising:

[0009] A unified interface, used to receive a keyword description, wherein the keyword description includes an object description, an action description, and a data description, wherein the object description is used to indicate the corresponding target hardware, the action description is used to indicate the target function corresponding to the target hardware, and the data description is used to indicate the specification of input data and output data corresponding to the target function;

[0010] The unified interface is also used to generate a functional step description corresponding to the target hardware according to the keyword description;

[0011] The hardware function service layer includes a hardware function library, a hardware type library and a plug-in system, wherein the hardware function library encapsulates the functional interfaces of all hardware in the multi-hardware platform; the hardware type library is used to define the functional interfaces and attribute specifications of each type of hardware;

[0012] And, the plug-in system includes a plug-in manager and a plurality of plug-ins, wherein each of the plug-ins is used to control the hardware to perform a corresponding operation according to a corresponding functional interface and attribute specification, and the plug-in manager is used to dynamically load a corresponding target plug-in according to the functional step description, so that the target plug-in controls the target hardware to perform a corresponding target operation;

[0013] The result acquisition module is used to acquire the test result according to the execution status of the target operation.

[0014] As an optional implementation, in the first aspect of the present invention, the unified interface includes a plurality of description parsers having a mutual mapping relationship;

[0015] And, the specific operation of the unified interface generating the functional step description corresponding to the target hardware according to the keyword description includes:

[0016] The meta description parser in the description parser parses the keyword description, and the meta description parser selects the next corresponding applicable description parser to parse the keyword according to the description of the keyword, and each applicable description parser selects the next corresponding applicable description parser to parse the keyword according to the description of the keyword until the parsing is completed;

[0017] After parsing the keyword, the meta description parser and each applicable description parser save the parsing result to the common context, and after the parsing is completed, obtain the functional step description saved in the common context.

[0018] As an optional implementation, in the first aspect of the present invention, the hardware function library includes a handle, a management function and a function function, wherein:

[0019] The handle includes a parameter set for describing device properties and control behaviors of the hardware, wherein the handle also includes additional information, the additional information stores location information and type information of fields in the handle, and the additional information is used to dynamically modify the handle according to the functional step description;

[0020] The management function is used to provide a management interface for managing private data of each of the hardware;

[0021] The functional functions are used to be mapped to the management interface so as to provide the functions of each of the hardware.

[0022] As an optional implementation, in the first aspect of the present invention, the functional function includes:

[0023] An initialization function, used to be mapped to the management interface to provide functions of configuring and preparing hardware;

[0024] An operation function, used to be mapped to the management interface so as to provide the hardware's own functions;

[0025] A control function, used to be mapped to the management interface to provide functions for managing and configuring the operating status of the hardware;

[0026] The status function is used to be mapped to the management interface to provide a function of querying hardware status information.

[0027] As an optional implementation, in the first aspect of the present invention, the hardware type library is further used to load the target hardware and the private data of the target hardware before the target plug-in controls the target hardware to perform the corresponding target operation.

[0028] The hardware type library defines the functional interfaces that each type of hardware should have, including:

[0029] The hardware type library includes a number of function pointers, each of which is used to represent a corresponding hardware function. The function pointers are also used to be dynamically bound to the target hardware so that the target hardware performs a corresponding target operation.

[0030] As an optional implementation manner, in the first aspect of the present invention, the unified interface includes:

[0031] Functional verification interface, used to match the test requirements of the correctness of the basic functions of the multiple hardware platforms;

[0032] An indicator verification class interface, used to match the testing requirements of hardware-related measurement information in the multiple hardware platforms;

[0033] Performance verification class interface, used to match the testing requirements of hardware-related performance information in the multiple hardware platforms;

[0034] Task verification class interface, used to match the test requirements of whether the hardware in the multiple hardware platforms is compatible with the software;

[0035] and stability verification class interfaces, for matching the test requirements of periodicity and / or stability of the multiple hardware platforms.

[0036] As an optional implementation manner, in the first aspect of the present invention, the specific manner in which the unified interface receives the keyword description includes:

[0037] Each interface in the unified interface obtains a keyword description, and the description parser corresponding to each interface determines whether the keyword description corresponds to the interface. If the description parser corresponding to the current interface determines that the keyword description corresponds to the current interface, the current interface is selected to receive the keyword description.

[0038] The second aspect of the present invention discloses a transparent perception multi-hardware platform testing method, which is implemented based on the transparent perception multi-hardware platform testing system disclosed in the first aspect of the present invention, and comprises:

[0039] Receive a keyword description, the keyword description including an object description, an action description and a data description, wherein the object description is used to indicate the corresponding target hardware, the action description is used to indicate the target function corresponding to the target hardware, and the data description is used to indicate the specification of input data and output data corresponding to the target function;

[0040] Generate a functional step description corresponding to the target hardware according to the keyword description;

[0041] Dynamically load a corresponding target plug-in according to the functional step description, wherein the target plug-in controls the target hardware to perform a corresponding target operation;

[0042] A test result is obtained according to the execution status of the target operation.

[0043] A third aspect of the present invention discloses a transparent perception multi-hardware platform testing device, the device comprising:

[0044] A memory storing executable program code;

[0045] a processor coupled to the memory;

[0046] The processor calls the executable program code stored in the memory to execute the transparent perception multi-hardware platform testing method disclosed in the second aspect of the present invention.

[0047] A fourth aspect of the present invention discloses a computer storage medium, wherein the computer storage medium stores computer instructions, and when the computer instructions are called, they are used to execute the transparent perception multi-hardware platform testing method disclosed in the second aspect of the present invention.

[0048] Compared with the prior art, the present invention has the following beneficial effects:

[0049] The unified interface designed by the test system in the present invention is designed with the idea of ​​keyword-driven interface, thereby reducing the distance between test requirements and program codes. Unlike the general keyword-driven framework, the unified interface does not establish a direct mapping from keywords to test scripts, but provides higher flexibility through a collection of objects, behaviors and data (i.e., keyword descriptions). At the same time, the unified interface is also used to generate functional step descriptions corresponding to target hardware based on keyword descriptions. The unified interface is located at the top layer of the entire test system, responsible for passing the high-level descriptions in the test cases downward and converting them into structured information used within the system, thereby improving the efficiency of the test process. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0051] Figure 1 It is a structural diagram of a transparent perception multi-hardware platform testing system disclosed in an embodiment of the present invention;

[0052] Figure 2 It is a flowchart of a transparent perception multi-hardware platform testing method disclosed in an embodiment of the present invention;

[0053] Figure 3 It is a structural schematic diagram of a transparent perception multi-hardware platform testing device disclosed in an embodiment of the present invention. DETAILED DESCRIPTION

[0054] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0055] The terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, device, product or end including a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units inherent to these processes, methods, products or ends.

[0056] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0057] Embodiment 1

[0058] See also Figure 1 , Figure 1 A transparently perceived multi-hardware platform test system disclosed in an embodiment of the present invention can be configured in multiple hardware platforms or as a test system outside multiple hardware platforms, such as Figure 1 As shown, the system may include a unified interface 10, a hardware service layer 20 and a result acquisition module 30, wherein:

[0059] The unified interface 10 is used to receive keyword descriptions, which may include object descriptions, action descriptions and data descriptions, wherein the object description is used to indicate the corresponding target hardware, the action description is used to indicate the target function corresponding to the target hardware, and the data description is used to indicate the specifications of the input data and output data corresponding to the target function.

[0060] In the embodiment of the present invention, the unified interface 10 (KDI) provides access to specific functions in a keyword-driven manner, supports direct mapping of test cases to test scripts, and thus realizes efficient test task switching.

[0061] Furthermore, the unified interface 10 is also used to generate a functional step description corresponding to the target hardware based on the keyword description. The functional step description is used to indicate the specific operation steps that the target hardware needs to perform to achieve the target function. The unified interface 10 (KDI) is located at the top layer of the entire test system. It is a keyword-driven interface (KDI) and can include a set of typed interfaces oriented to test targets. It is responsible for passing the high-level description in the test case downward and converting it into structured information used within the system to solve the problem that the interface division granularity of the HAL library in the prior art is too fine, resulting in the need to write additional redundant code in the actual testing process, which is inefficient.

[0062] It can be seen that the unified interface 10 (KDI) designs the interface with the idea of ​​keyword-driven, thereby reducing the distance between test requirements and program codes. Unlike the general keyword-driven framework, the unified interface 10 (KDI) does not establish a direct mapping from keywords to test scripts, but provides higher flexibility through a collection of objects, behaviors and data (i.e., keyword descriptions). This solves the problem that the predefined keywords in the prior art are not sufficient to cope with complex test scenarios, and new keywords need to be written or manual intervention is required.

[0063] The hardware service layer 20 may include a hardware function library 21, a hardware type library 22, and a plug-in system, wherein:

[0064] The hardware function library 21 is responsible for providing a mechanism for direct interaction with the underlying hardware. The hardware function library 21 encapsulates the functional interfaces of all hardware in the multi-hardware platform.

[0065] The hardware type library 22 is used to define the functional interface and attribute specifications of each type of hardware. The hardware type library 22 is a component that abstracts a specific type of hardware (such as a hard disk device). The library does not involve the implementation details of specific hardware functions, but defines the functional interface and attribute specifications that this type of hardware should have. By aggregating functions and standardizing interfaces, the hardware type library 22 provides a unified abstract layer for different hardware devices.

[0066] Furthermore, the plug-in system may include a plug-in manager 231 and several plug-ins 232, wherein each plug-in 232 is used to control the hardware to perform a corresponding operation according to a corresponding functional interface and property specification, and the plug-in manager 231 is used to dynamically load a corresponding target plug-in according to a functional step description so that the target plug-in controls the target hardware to perform a corresponding target operation.

[0067] For the plug-in system, optionally, the plug-in system meets the scalability requirements and the ability to implement dynamic binding at runtime. Through the dynamic link mechanism, the hardware service layer 20 (HFS) can realize dynamic loading and unloading of plug-ins. Each plug-in can implement a specific hardware functional module according to a predefined interface specification and provide corresponding services for the upper-level interface through dynamic binding at runtime.

[0068] The plug-in manager 231 is responsible for the key tasks of plug-in loading, initialization and destruction. When it is detected that a certain hardware device needs to be used, the plug-in manager 231 loads the corresponding plug-in by means of a dynamic link library. Each plug-in must implement a set of standardized interfaces, which generally include functions such as device initialization, data operation, and status query. After the plug-in is successfully loaded by the plug-in manager 231, the initialization method of the plug-in is first called to ensure its correct integration with the system. In this process, the function implementation in the plug-in is associated with the abstract interface in the core system through a function pointer or an interface binding mechanism, so that the upper layer application can transparently call the hardware functions in different plug-ins. This dynamic binding mechanism ensures that the needs of different hardware devices can be adapted at runtime.

[0069] The result acquisition module 30 is used to acquire the test result according to the execution status of the target operation. For example, the result acquisition module 30 continuously samples the execution status of the target operation and obtains the test result based on the sampling result analysis.

[0070] In an optional embodiment, the unified interface 10 may include a number of description parsers that have a mutual mapping relationship;

[0071] Furthermore, the specific operation of the unified interface 10 generating the functional step description corresponding to the target hardware according to the keyword description may include:

[0072] The meta description parser in the description parser parses the keyword description, and the meta description parser selects the next corresponding applicable description parser to parse the keyword according to the description of the keyword, and each applicable description parser selects the next corresponding applicable description parser to parse the keyword according to the description of the keyword until the parsing is completed;

[0073] After parsing the keywords, the meta description parser and each applicable description parser save the parsing results into the common context. After the parsing is completed, the functional step description saved in the common context is obtained.

[0074] In this optional embodiment, the purpose of introducing keyword description is to enhance the applicability of KD I interface through configuration and fine-grained control of the specific behavior of KD I. First, keyword description is expressed as a triple consisting of object, action, and data, where the action represents a brief description of the function, which can be agreed in advance.

[0075] Optionally, the keyword description can be data in YAML format. The following pseudo code shows how to represent the keyword description in YAML format:

[0076]

[0077] The above pseudo code shows the YAML format definition of keyword description. It is divided into three main parts: metadata, activity, and data. The metadata part describes the basic information of the target hardware, such as name, model, etc., which is mainly used to distinguish different hardware. The activity part describes the actions performed on the target hardware, such as the read operation of the hard disk. The fields in this part are not fixed, and different hardware has different fields. The data part describes the input and output specifications. The system will use data according to the input specifications and output data according to the output specifications.

[0078] The keyword description is consistent throughout the entire execution process, and the format is unified by the implementation agreement in the hardware service layer 20 (HFS). The keyword description parser is responsible for parsing the keyword description. Each interface in KDI accepts a configuration file (that is, a keyword description in YAML format or Json format) as input. The parser first performs a preliminary legitimacy check on the incoming description, mainly verifying the legitimacy of each field and whether the current interface supports these fields. For missing necessary fields, the description parser will fill them with predefined default values. The parser then generates the corresponding hardware function description steps based on the keyword description, reducing direct intervention in the code.

[0079] In order to expand the functions of keyword description, the keyword description parser can be modularized and dynamically combined. The keyword description parser gradually combines new parsers during the parsing process and saves the parsed keyword description by maintaining a common context. Specifically, the meta description parser in the description parser first parses the triple of the keyword description. After reading the basic information, it selects the next appropriate parser from the dictionary maintained internally to continue parsing until the entire parsing process is completed or terminated due to failure. When a new keyword description needs to be expanded, the corresponding parser needs to be implemented and a mapping relationship between the parsers needs to be established.

[0080] In another optional embodiment, the hardware function library 21 may include a handle, a management function and a function function, wherein:

[0081] The handle may include a set of parameters for describing the device attributes and control behaviors of the hardware, wherein the handle may also include additional information, the additional information storing the location information and type information of the fields in the handle, and the additional information is used to dynamically modify the handle according to the functional step description;

[0082] The management function is used to provide a management interface for managing private data of each hardware;

[0083] Functions are used to be mapped to management interfaces to provide the functionality of each hardware.

[0084] In this optional embodiment, for each specific hardware device, the hardware function library 21 can be represented by a set of data structures and a set of functions. The data is used to describe the properties of the hardware device and control the behavior of the hardware, which is called a handle. The function set is divided into two categories: one is a management function, which is used to allocate data space and establish a mapping relationship between function pointers; the other is a function function, which is used to provide specific functions for operating the hardware device.

[0085] In the hardware function library 21, a handle represents a structure, which is a collection of hardware-related parameters. In order to achieve dynamics, the handle can also include additional information, which stores the location information and type information of the fields in the handle. The additional information is used to dynamically modify the handle according to the functional step description. For example, the handle is defined by the macro HANDLE_DEF I NE. The handle consists of a name and multiple attributes, and each attribute is declared in the format of "(type)name". As shown in the following pseudo code:

[0086]

[0087] The above pseudo code describes how to define a handle, adding additional type and location information through a series of macro definitions.

[0088] The structure defined by the macro HANDLE_DEF I NE will be expanded at the end. During the expansion, in addition to defining the corresponding structure, additional information can also be defined to save the location information and type information of the fields in the handle. This additional information can be used to implement dynamic data binding during runtime.

[0089] As shown in the following pseudo code:

[0090]

[0091]

[0092] The above pseudo code describes the expanded form of the macro definition. The additional information is organized as a class template FI ELD, which is used internally by the system to implement dynamic data binding.

[0093] In this optional embodiment, the management function provides a transparent data access mechanism for the upper layer interface. Since the parameters of different hardware devices are significantly different and difficult to describe through a unified data structure, each hardware abstract implementation has a private data, and the upper layer interface cannot directly access the private data of a specific hardware. The interface provided by the management function can be divided into the following categories according to function:

[0094] HFS_Alloc(): Allocates private data and returns a unique identifier to represent the private data.

[0095] HFS_Free(): Frees up space for private data based on the identifier.

[0096] HFS_DataMapp i ng(): Maps corresponding fields to private data.

[0097] HFS_FuncMapp i ng(): Maps the underlying implementation function to the upper layer.

[0098] In yet another optional embodiment, the functional function may include:

[0099] Initialization function, which is used to be mapped to the management interface to provide the functions of configuring and preparing the hardware;

[0100] Operation functions are used to be mapped to the management interface to provide the hardware's own functions;

[0101] A control function is used to be mapped to a management interface to provide functions for managing and configuring the operating status of the hardware;

[0102] The status function is used to be mapped to the management interface to provide the function of querying hardware status information.

[0103] In this optional embodiment, the function functions of the specific functions of the operating hardware devices in the test system can be implemented without any restrictions to ensure maximum flexibility. For example, they can be mapped to a unified interface definition in HFS_FuncMapping(). According to the nature of the function, the function functions can be divided into four categories: initialization function, operation function, control function and status function. Among them:

[0104] Initialization functions are used to be mapped to the management interface to provide the functions of configuring and preparing the hardware. For example, the initialization function is responsible for configuring and preparing the hardware device to ensure that it can operate normally. Usually, this type of function is called when the system starts or the device is used for the first time. Its main responsibility is to allocate necessary resources for the device, configure related registers, initialize internal data structures, or set the working mode of the device. This process may include loading drivers, resetting devices, or initializing interrupt handling mechanisms. Through the initialization function, the system can ensure that the hardware is in an operational state and prepare for subsequent function calls.

[0105] Operation functions are used to be mapped to the management interface to provide the hardware's own functions. For example, operation functions implement the core functions of the device and are directly responsible for interacting with the hardware. They handle specific operations such as data reading and writing, command execution, etc., and are the key interface between upper-level applications and hardware devices. For example, in the hard disk abstraction, operation functions include reading and writing sectors, data block transfer, etc. These functions are usually the most frequently called parts of the system, so they need to be optimized to ensure operational efficiency. Operation functions are the core of the hardware abstraction layer and directly determine the actual functional performance of the device.

[0106] Control functions are used to be mapped to the management interface to provide functions for managing and configuring the operating state of the hardware. For example, control functions manage and configure the operating state of the device and provide control over the behavior of the hardware. This type of function allows certain parameters or functional modes of the device to be adjusted to suit different application requirements. The role of control functions may include changing the operating mode of the device, adjusting the transfer rate, configuring the cache policy, etc. For example, in the hard disk abstraction, control functions can be used to set the data transfer mode or activate the power management function of the device.

[0107] The status function is used to be mapped to the management interface to provide the function of querying hardware status information. For example, the status function queries the current operating status of the device or obtains the status information of the device. By calling the status function, the system can obtain the device's error information, performance indicators or current working status.

[0108] In another optional embodiment, the hardware type library 22 is also used to load the target hardware and the private data of the target hardware before the target plug-in controls the target hardware to perform the corresponding target operation.

[0109] The hardware type library 22 defines the functional interfaces that each type of hardware should have, which may include:

[0110] The hardware type library 22 may include a number of function pointers, each of which is used to represent a corresponding hardware function. The function pointers are also used to be dynamically bound to the target hardware so that the target hardware executes the corresponding target operation.

[0111] In this optional embodiment, the hardware type library 22 is a component that abstracts a specific type of hardware (such as a hard disk device). The library does not involve the implementation details of specific hardware functions, but defines the functional interfaces and attribute specifications that this type of hardware should have. By aggregating functions and standardizing interfaces, the hardware type library 22 provides a unified abstraction layer for different hardware devices.

[0112] In this optional embodiment, the implementation of the hardware type library 22 includes:

[0113] The initialization phase is responsible for loading the corresponding hardware implementation and its related data preparation. The second is the functional interface and attribute specification, where the functional interface is defined by a set of function pointers, which are dynamically bound at runtime. The attribute specification is transparent to the hardware type library 22 and can be implemented by the hardware function library 21. Finally, functional aggregation implements specific functions through standardized processes, such as hard disk read operations, including initialization and data reading steps. This aggregation process effectively avoids repeated code writing.

[0114] In this optional embodiment, the process of dynamically binding a pointer at runtime is exemplified as follows:

[0115] S1. Based on the functions implemented by the functional interface, a specification is pre-defined in the form of a set of function pointers, each of which represents a specific function.

[0116] S2. Abstract a unified function binding interface. Each specific hardware implementation module must implement this interface and bind to the corresponding function pointer according to the corresponding specifications.

[0117] S3. The runtime context loads the corresponding module according to the input and calls the function binding interface to implement dynamic binding at runtime.

[0118] In yet another optional embodiment, the unified interface 10 may include:

[0119] Functional verification interface, used to match the test requirements of basic functional correctness of multiple hardware platforms;

[0120] Indicator verification interface, used to match the testing requirements of hardware-related measurement information in multiple hardware platforms;

[0121] Performance verification interface, used to match the testing requirements of hardware-related performance information in multiple hardware platforms;

[0122] Task verification interface, used to match the test requirements of whether the hardware is compatible with the software on multiple hardware platforms;

[0123] and stability verification class interfaces to match the periodicity and / or stability testing requirements of multiple hardware platforms.

[0124] In this optional embodiment, the unified interface 10 (KDI) summarizes the test items related to the hardware from the perspective of test requirements, and divides the types at a coarse granularity. The unified interface 10 (KDI) divides all interfaces into five types, as described below:

[0125] Functional verification: mainly tests the correctness of the basic functions of the system, such as whether the system or device can start normally, whether the serial port can send and receive data normally, etc.

[0126] Metric verification: mainly collects system and device-related measurement information, such as power consumption, temperature, etc., and is usually used in conjunction with other types of interfaces.

[0127] Performance verification: Mainly used to test devices with performance requirements, such as the write speed of a hard disk, and is usually designed as a timing interface.

[0128] Task verification: mainly used to test whether a hardware device is compatible with the software, such as whether the MLU device can adapt to the Pytorch framework.

[0129] Stability verification: Mainly used to periodically test the stability of a system or device, implemented in the form of a scheduled task.

[0130] The common test types, test items and test standards divided in this optional embodiment are shown in Table 1.

[0131] Table 1 Common test items

[0132]

[0133]

[0134] In this optional embodiment, for the five categories divided above, combined with the underlying hardware and system functions, the specific definition of the unified interface 10 (KD I) is shown in Table 2.

[0135] Table 2 Application function library interface

[0136]

[0137] In yet another optional embodiment, the specific manner in which the unified interface 10 receives the keyword description may include:

[0138] Each interface in the unified interface 10 obtains a keyword description, and the description parser corresponding to each interface determines whether the keyword description corresponds to the interface. If the description parser corresponding to the current interface determines that the keyword description corresponds to the current interface, the current interface is selected to receive the keyword description.

[0139] In this optional embodiment, in order to enhance the flexibility of the KDI interface, the KDI adopts a design method that combines type and configuration. On the one hand, the interface division of the KDI adopts the coarsest possible granularity to reduce redundancy, and on the other hand, the behavior of the interface is controlled at a fine granularity through the configuration mechanism, thereby achieving more flexible operation.

[0140] In another optional embodiment, the transparent perception multi-hardware platform test system is written in C++ and modularly organized according to the abstract level. The first is KD I, which provides a unified interface 10 for accessing hardware functions, aiming to simplify user operations. For ease of use, the input parameter of the interface is a YAML configuration file, through which users can directly access and call hardware-related functions without having to deeply understand the underlying implementation details. The middle layer is the runtime library, whose main responsibility is to provide support functions within the abstract layer. These functions include parsing incoming configuration files, dynamically loading hardware plug-ins, allocating private data to plug-ins, etc. Finally, the plug-in system is responsible for implementing specific hardware functions. Each hardware function is encapsulated as an independent plug-in and provides services according to predefined interface specifications.

[0141] Furthermore, the test system is integrated into the test program in the form of a library, and the required plug-in dynamic library is packaged together and deployed to the target hardware platform for execution.

[0142] It can be seen that the test system in this optional embodiment adopts a hierarchical structure. The top layer is the keyword-driven interface (KDI), which is a set of typed interfaces oriented to the test target, responsible for passing the high-level description in the test case downward and converting it into structured information used inside the system. The middle layer is the runtime support library of the system, which provides internal functions such as data parsing and task scheduling. The bottom layer is the hardware function service (HFS), whose main function is to abstract and shield the underlying hardware details to ensure that it can run on different hardware platforms without being affected by the underlying differences. Specifically, the test system in this optional embodiment supports dynamic selection of different hardware functions. Specifically, 1) a hardware-independent unified interface 10 is abstracted for the test type, and hardware-related functions are accessed by means of configuration files. 2) A hardware function service (HFS) for specific hardware is designed to dynamically select different hardware functions in the form of plug-ins.

[0143] like Figure 2 As shown, based on the transparent perception multi-hardware platform testing system disclosed in the embodiment of the present invention, the embodiment of the present invention further discloses a transparent perception multi-hardware platform testing method, which is implemented based on the above-mentioned testing system and may include:

[0144] Step 201: Receive keyword description.

[0145] Among them, the keyword description may include object description, action description and data description, wherein the object description is used to indicate the corresponding target hardware, the action description is used to indicate the target function corresponding to the target hardware, and the data description is used to indicate the specifications of the input data and output data corresponding to the target function.

[0146] Step 202: Generate a functional step description corresponding to the target hardware according to the keyword description.

[0147] Step 203: dynamically load the corresponding target plug-in according to the functional step description, and the target plug-in controls the target hardware to perform the corresponding target operation.

[0148] Step 204: Obtain test results based on the execution status of the target operation.

[0149] Embodiment 2

[0150] The transparently perceived multi-hardware platform testing system in the first embodiment is applied to the test pipeline to realize automated testing, as follows:

[0151] In the test pipeline, automated test scripts are the key prerequisite for realizing automated execution of the pipeline. However, frequent modification of these test scripts may have an adverse effect on the execution efficiency of the pipeline. By introducing the test system in Example 1, the need for direct modification of test scripts and pipelines can be effectively reduced, thereby improving the efficiency and stability of the overall test process. The specific implementation steps are as follows:

[0152] Phased division of the test pipeline: First, the test process is designed in stages according to the specific application scenario. Each stage undertakes specific tasks, and the output of the previous stage will serve as the input of the subsequent stage to achieve the sequential connection and processing of tasks.

[0153] Writing of test program: By introducing the test system in Embodiment 1, the test program establishes a mapping relationship between the test target and the application function in the hardware abstraction layer. According to the input configuration file, the program calls the corresponding function to achieve transparent conversion of the test target without repeated code writing.

[0154] On-demand distribution of functional plug-ins: In order to reduce the size of the distribution file, only the functional plug-ins that are actually needed can be distributed. The test system maintains the mapping relationship between the hardware identifier and the functional plug-in, locates the location of the plug-in file, and transfers the specified plug-in file to the target hardware platform, thereby achieving efficient plug-in distribution.

[0155] Testing of multiple hardware targets: Without modifying the test pipeline stage, different hardware targets can be adapted and tested by simply adjusting the configuration file. This method effectively reduces the amount of repetitive work in the test process and improves the flexibility and efficiency of the test.

[0156] Optimization of parallel pipelines: When testing multiple hardware platforms, pipeline tasks at the same stage can be assigned to multiple different target platforms at the same time through parallel scheduling. In this process, you only need to adjust the configuration data of the incoming pipeline to achieve multi-platform parallel testing, which significantly improves the overall testing efficiency.

[0157] Embodiment 3

[0158] Applying the transparent perception multi-hardware platform test system in Example 1 to heterogeneous intelligent processors in a cloud scenario can achieve flexible performance analysis, as follows:

[0159] The dynamic resource scheduling and virtualization technology of the cloud computing environment provide flexibility for the use of heterogeneous processors, but lack a flexible way to collect the indicator data of the intelligent processor. The test system in Example 1 can be used to collect the runtime indicators of the intelligent processor in a transparent way as a basis for performance analysis. The implementation steps include:

[0160] Metrics collection container: First, a special container is written for the test system in Example 1. This container collects specific targets on specific target hardware according to a specified configuration file and writes them to a path in the form of logs.

[0161] Scheduling of deep learning tasks: In the Kubernetes cluster, deep learning tasks are scheduled by writing specific YAML files. During the task startup process, the si decar container mode is used to start the performance indicator collection container at the same time to monitor the resource usage during the task execution process.

[0162] Transparent adjustment and data collection: The performance indicator collection container can dynamically select the plug-in that is compatible with the target intelligent processor based on the configuration, and sample the system performance through regularly executed tasks. The collected data will be stored in the specified path at regular intervals, thus providing a reliable basis for subsequent performance analysis and system optimization. This process minimizes interference with the main task during task execution and maintains the transparency of system operation.

[0163] Embodiment 4

[0164] See also Figure 3 , Figure 3 Schematic diagram of the structure of a transparent sensing multi-hardware platform testing device disclosed in an embodiment of the present invention. Figure 3As shown, the transparent perception multi-hardware platform testing device may include:

[0165] A memory 301 storing executable program codes;

[0166] a processor 302 coupled to the memory 301;

[0167] The processor 302 calls the executable program code stored in the memory 301 to execute the steps of the transparent perception multi-hardware platform testing method described in the first embodiment of the present invention.

[0168] Embodiment 5

[0169] An embodiment of the present invention discloses a computer storage medium, which stores computer instructions. When the computer instructions are called, they are used to execute the steps in the transparent perception multi-hardware platform testing method described in the first embodiment of the present invention.

[0170] Embodiment 6

[0171] An embodiment of the present invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to enable a computer to execute the steps in the transparent-aware multi-hardware platform testing method described in Embodiment 1.

[0172] The device embodiments described above are only illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, i.e., they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative work.

[0173] Through the specific description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the above technical solution can be essentially or partly contributed to the prior art in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, and the storage medium includes a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable rewritable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0174] Finally, it should be noted that the transparently perceived multi-hardware platform testing method and system, device, and storage medium disclosed in the embodiments of the present invention only disclose the preferred embodiments of the present invention, which are only used to illustrate the technical solution of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features therein can be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A transparent perception multi-hardware platform testing system, characterized in that: The system comprises: A unified interface, used to receive a keyword description, wherein the keyword description includes an object description, an action description, and a data description, wherein the object description is used to indicate the corresponding target hardware, the action description is used to indicate the target function corresponding to the target hardware, and the data description is used to indicate the specification of input data and output data corresponding to the target function; The unified interface is also used to generate a functional step description corresponding to the target hardware according to the keyword description; The hardware function service layer includes a hardware function library, a hardware type library and a plug-in system, wherein the hardware function library encapsulates the functional interfaces of all hardware in the multi-hardware platform; the hardware type library is used to define the functional interfaces and attribute specifications of each type of hardware; And, the plug-in system includes a plug-in manager and a plurality of plug-ins, wherein each of the plug-ins is used to control the hardware to perform a corresponding operation according to a corresponding functional interface and attribute specification, and the plug-in manager is used to dynamically load a corresponding target plug-in according to the functional step description, so that the target plug-in controls the target hardware to perform a corresponding target operation; The result acquisition module is used to acquire the test result according to the execution status of the target operation.

2. The transparent perception multi-hardware platform testing system according to claim 1 is characterized in that: The unified interface includes a number of description parsers that have a mutual mapping relationship; And, the specific operation of the unified interface generating the functional step description corresponding to the target hardware according to the keyword description includes: The meta description parser in the description parser parses the keyword description, and the meta description parser selects the next corresponding applicable description parser to parse the keyword according to the description of the keyword, and each applicable description parser selects the next corresponding applicable description parser to parse the keyword according to the description of the keyword until the parsing is completed; After parsing the keyword, the meta description parser and each applicable description parser save the parsing result to the common context, and after the parsing is completed, obtain the functional step description saved in the common context.

3. The transparent perception multi-hardware platform testing system according to claim 1 is characterized in that: The hardware function library includes handles, management functions and function functions, wherein: The handle includes a parameter set for describing device properties and control behaviors of the hardware, wherein the handle also includes additional information, the additional information stores location information and type information of fields in the handle, and the additional information is used to dynamically modify the handle according to the functional step description; The management function is used to provide a management interface for managing private data of each of the hardware; The functional functions are used to be mapped to the management interface so as to provide the functions of each of the hardware.

4. The transparent perception multi-hardware platform testing system according to claim 3 is characterized in that: The functional functions include: An initialization function, used to be mapped to the management interface to provide functions of configuring and preparing hardware; An operation function, used to be mapped to the management interface so as to provide the hardware's own functions; A control function, used to be mapped to the management interface to provide functions for managing and configuring the operating status of the hardware; The status function is used to be mapped to the management interface to provide a function of querying hardware status information.

5. The transparent perception multi-hardware platform testing system according to claim 3 is characterized in that: The hardware type library is also used to load the target hardware and the private data of the target hardware before the target plug-in controls the target hardware to perform the corresponding target operation. The hardware type library defines the functional interfaces that each type of hardware should have, including: The hardware type library includes a number of function pointers, each of which is used to represent a corresponding hardware function. The function pointers are also used to be dynamically bound to the target hardware so that the target hardware performs a corresponding target operation.

6. The transparent perception multi-hardware platform testing system according to claim 2, characterized in that: The unified interface includes: Functional verification interface, used to match the test requirements of the correctness of the basic functions of the multiple hardware platforms; An indicator verification class interface, used to match the testing requirements of hardware-related measurement information in the multiple hardware platforms; Performance verification class interface, used to match the testing requirements of hardware-related performance information in the multiple hardware platforms; Task verification class interface, used to match the test requirements of whether the hardware in the multiple hardware platforms is compatible with the software; and stability verification class interfaces, for matching the test requirements of periodicity and / or stability of the multiple hardware platforms.

7. The transparent perception multi-hardware platform testing system according to claim 6, characterized in that: The specific manner in which the unified interface receives the keyword description includes: Each interface in the unified interface obtains a keyword description, and the description parser corresponding to each interface determines whether the keyword description corresponds to the interface. If the description parser corresponding to the current interface determines that the keyword description corresponds to the current interface, the current interface is selected to receive the keyword description.

8. A transparent perception multi-hardware platform testing method, characterized in that: The method is implemented based on the transparent perception multi-hardware platform testing system described in any one of claims 1 to 7, and the method comprises: Receive a keyword description, the keyword description including an object description, an action description and a data description, wherein the object description is used to indicate the corresponding target hardware, the action description is used to indicate the target function corresponding to the target hardware, and the data description is used to indicate the specification of input data and output data corresponding to the target function; Generate a functional step description corresponding to the target hardware according to the keyword description; Dynamically load a corresponding target plug-in according to the functional step description, wherein the target plug-in controls the target hardware to perform a corresponding target operation; A test result is obtained according to the execution status of the target operation.

9. A transparent perception multi-hardware platform testing device, characterized in that: The device includes: a memory storing executable program code; a processor coupled to the memory; the processor calls the executable program code stored in the memory to execute the transparent perception multi-hardware platform testing method as described in claim 8.

10. A computer storage medium, characterized in that: The computer storage medium stores computer instructions, and when the computer instructions are called, they are used to execute the transparent perception multi-hardware platform testing method as claimed in claim 8.

Images