CN114048143A

CN114048143A - Embedded component entity testing method and device

Info

Publication number: CN114048143A
Application number: CN202111402478.3A
Authority: CN
Inventors: 赵佐; 吴健; 邓磊; 陈健
Original assignee: Northwestern Polytechnical University
Current assignee: Northwestern Polytechnical University
Priority date: 2021-11-23
Filing date: 2021-11-23
Publication date: 2022-02-15

Abstract

The invention discloses a method and a device for testing an embedded component entity, and relates to the technical field of embedded software. The method is used for solving the problem that the workload and the difficulty are increased due to the fact that the source code of the component needs to be analyzed in the existing component entity testing method. The method comprises the following steps: receiving a test instruction, wherein the test instruction carries a component description file to be compiled corresponding to a component entity to be tested, and generating an intermediate representation according to the component description file to be compiled; the intermediate representation obtains test data of the entity of the component to be tested according to the generation strategy, the test data is stored in a test data root directory, subfiles included in the test data root directory correspond to ports and interfaces included in the entity to be tested, and the ports and the interfaces included in the intermediate representation are subjected to type conversion to obtain a pile component description file and a pile program code of the entity of the component to be tested; and executing the test data and the pile program code according to the test instruction to obtain a test result of the entity of the component to be tested.

Description

Embedded component entity testing method and device

Technical Field

The invention relates to the technical field of embedded software, in particular to a method and a device for testing an embedded component entity.

Background

The command control system software belongs to a typical distributed embedded software system. With the continuous enhancement of the system function of the embedded software, the scale and complexity of the embedded software are also rapidly improved, and how to improve the design and development process of the embedded software, improve the development efficiency and the product quality becomes a hotspot of the research of the embedded software. Component-based software development approaches have gradually gained application in large-scale embedded software system development as an extremely promising solution.

With the widespread use of component-based software development methods, new problems of testing of components are also brought about. How to ensure whether the existing components meet the functional requirements and the security required by the software system. The main objectives of component testing methods are to reveal component errors, verify component quality, and reveal possible problems when assembling new systems with components.

Component testing is similar to conventional software cell testing, which is a testing process that reveals component errors and verifies component quality. Component-based software integration testing is similar to the conventional software integration testing process, and mainly reveals the problems of the system when a new system is assembled by using components.

In summary, the existing component entity testing method needs to analyze the source code of the component, which results in the problem of increased workload and difficulty.

Disclosure of Invention

The embodiment of the invention provides a method and a device for testing an embedded component entity. The method is used for solving the problem that the workload and the difficulty are increased due to the fact that the source code of the component needs to be analyzed in the existing component entity testing method.

The embodiment of the invention also provides an embedded component entity testing method, which comprises the following steps:

receiving a test instruction, wherein the test instruction carries a component description file to be compiled corresponding to a component entity to be tested, and generating an intermediate representation according to the component description file to be compiled; the test instruction corresponds to an interface test and a port test;

the intermediate representation obtains test data of the component entity to be tested according to a generation strategy, the test data is stored in a test data root directory, subfiles included in the test data root directory correspond to the component directory corresponding to the to-be-tested construction entity, wherein the test data root directory is located under the component directory corresponding to the to-be-tested construction entity;

performing type conversion on the port and the interface included in the intermediate representation to obtain a pile component description file and a pile program code of the entity of the component to be tested;

and executing the test data and the pile program code according to the test instruction to obtain a test result of the to-be-tested member entity.

The embodiment of the invention also provides an embedded component entity testing device, which comprises:

the generating unit is used for receiving a test instruction, wherein the test instruction carries a component description file to be compiled corresponding to a component entity to be compiled, and generating an intermediate representation according to the component description file to be compiled; the test instruction corresponds to an interface test and a port test;

the storage unit is used for obtaining the test data of the component entity to be tested according to a generation strategy by the intermediate representation, and storing the test data into a test data root directory, wherein a subfile included in the test data root directory corresponds to a port and an interface of the component entity to be tested, and the test data root directory is positioned under the component directory corresponding to the component entity to be tested;

the obtaining unit is used for carrying out type conversion on the port and the interface included in the intermediate representation to obtain a pile component description file and a pile program code of the entity of the component to be tested;

and the test unit is used for executing the test data and the pile program code according to the test instruction to obtain a test result of the to-be-tested member entity.

The embodiment of the invention provides a method and a device for testing an embedded component entity, wherein the method comprises the following steps: receiving a test instruction, wherein the test instruction carries a component description file to be compiled corresponding to a component entity to be tested, and generating an intermediate representation according to the component description file to be compiled; the test instruction corresponds to an interface test and a port test; the intermediate representation obtains test data of the component entity to be tested according to a generation strategy, the test data is stored in a test data root directory, subfiles included in the test data root directory correspond to the component directory corresponding to the to-be-tested construction entity, wherein the test data root directory is located under the component directory corresponding to the to-be-tested construction entity; performing type conversion on the port and the interface included in the intermediate representation to obtain a pile component description file and a pile program code of the entity of the component to be tested; and executing the test data and the pile program code according to the test instruction to obtain a test result of the to-be-tested member entity. The method for testing the component entity can assist a user in testing the component entity, simplify a complex testing process, detect whether the function of the component entity meets expectations or not, detect the correctness and the safety of the component, and improve the reliability of software.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic flowchart of an embedded component entity testing method according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of an ECOM component meta-model structure according to an embodiment of the present invention;

FIG. 3 is a schematic flow chart of a component entity generation method according to an embodiment of the present invention;

FIG. 4 is a schematic diagram illustrating a software cell interaction flow according to an embodiment of the present invention;

FIG. 5 is a schematic flow chart of an intermediate representation algorithm provided in an embodiment of the present invention;

FIG. 6 is a structural diagram of a C + + language component code framework according to an embodiment of the present invention;

fig. 7 is a schematic structural diagram of an embedded component physical testing apparatus according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

To further describe the component entity provided in the embodiment of the present invention, a testing method of the corresponding component entity is described as follows, as shown in fig. 1, the testing method mainly includes the following steps:

step 101, receiving a test instruction, wherein the test instruction carries a component description file to be compiled corresponding to a component entity to be compiled, and generating an intermediate representation according to the component description file to be compiled; the test instruction corresponds to an interface test and a port test;

102, the intermediate representation obtains test data of the component entity to be tested according to a generation strategy, the test data is stored in a test data root directory, and subfiles included in the test data root directory correspond to ports and interfaces included in the to-be-tested construction entity, wherein the test data root directory is located under the component directory corresponding to the to-be-tested construction entity;

103, performing type conversion on the port and the interface included in the intermediate representation to obtain a pile component description file and a pile program code of the entity of the component to be tested;

and 104, executing the test data and the pile program code according to the test instruction to obtain a test result of the to-be-tested member entity.

It should be noted that before introducing the component entity testing method, the ECOM component meta-model, the component description and the component description file are introduced.

As shown in fig. 2, the ECOM Component meta model mainly includes 11 elements, which are, in order, a Component (Component), a Component attribute (ComAttribute), an Interface (Interface), a Port (Port), a Component parameter (ComParameter), an Operation (Operation), a structure (Struct), a complex (Union), a Sequence (Sequence), an Enumeration type (Enumeration), and a basic data type (Fundamental Types).

It should be noted that the core component of the ECOM component meta-model is a component, and then component attributes, interfaces, ports and component parameters with the characteristics of structured data; other auxiliary meta-objects include operations, constructs, complexes, sequences, enumerated types, and primitive data types.

The basic information of the above 11 elements is described as follows:

1) component

A component may contain zero or more component parameters, zero or more component properties, zero or more interfaces, and zero or more ports.

In the embodiment of the invention, the interfaces included by the component are divided into a Provide interface for providing services to the outside of the component and a Require interface for providing services to other external components; the ports included in the component are divided into a Publish port for publishing data to the outside and a Consume port for receiving data published by other components.

Zero or more other defined components may be included in a component definition, which is a component assembly mechanism for supporting the assembly of existing components into larger components, thereby forming a hierarchical relationship based on inclusion between components so that a user can hold and use components at different levels.

2) Parameters of the component

The component parameters can only be set when creating a component instance for specifying the operating parameters and operating mode of the component, e.g. operating in BIT mode, ground test mode, etc.

It should be noted that, in practical applications, a component example refers not only to a specific component but also to a certain component, and the component example actually exists in the component. The component is a virtual one, and the component instance realizes the actualization of the component.

The parameters of a component can only have basic data types or enumerated types.

3) Component Properties

The component attributes are used for representing the states displayed by the component and are used by the internal processing business logic of the component. The component attributes must be set at the time of component initialization, and during component operation, they can also be set by the component internal business logic process.

The properties of a piece can only have basic data types or enumerated types.

4) Port(s)

A port is a mechanism by which a component communicates data with other components outside.

A fabric may have zero or more Publish ports, each for publishing data to other external fabrics. The definition, development and implementer of a component does not need to know to which components the data published by the Publish port is subscribed.

A fabric may also have zero or more Consume ports, each for subscribing to data published by the Publish port of another fabric outside. The definition, development and implementer of the fabric does not need to know by which fabric the data received by the Consume port was published.

Both the Publish port and the Consume port must specify data types, and the associated data types may be basic data types, enumerated types, structured types, sequential or federated data types.

When the components are assembled to form a specific application, the corresponding connection relationship between the Publish port and the Consume port of different component instances needs to be specified. The Publish port and the Consume port of the corresponding connection must be associated with compatible data types.

5) Interface

The interfaces included in the component are classified into a Provide interface for providing services to the outside of the component and a Require interface for providing services to other components outside.

The Provide interface of the component is used for providing services to the outside, and the Require interface indicates that the services provided by the corresponding interfaces of other components need to be called. One or more operations may be included in an interface.

When the components are assembled by application, the Provide interface of one component can be connected with the Require interfaces of a plurality of other components; while the Require interface of one component can only be connected with the Provide interface of another component.

6) Operation of

An operation is an integral part of a component interface, in the form of a function.

Each operation may have zero or more parameters Parameter, a return value, return value.

The types of parameters and return values may be basic data types, enumerated types, structured types, sequential types, or federated data types. There may also be no return value indicated by void.

The parameter in operation may have indicators of three transfer modes of in, out, and inout, specifically, an in indicator, indicating that the corresponding parameter is an input parameter, i.e., the parameter substituted into operation is used by the business process of operation, but the value of the substituted parameter cannot be changed. An out indicator indicating that the corresponding parameter is an output parameter whose value cannot be used in the course of the business process of the operation, but through which the result can be passed (output) to the caller. An inout indicator indicating that the corresponding parameter is both an input parameter and an output parameter, i.e. it has the characteristics of both an input parameter and an output parameter.

7) Basic data types

The primitive data types have the same meaning as the primitive data types in the CORBA IDL specification.

8) Enumeration type

An enumerated data type is a simple data type. The enumerated type specifies a limited number (at least one) of named symbol values.

9) Structural body

The structure represents the structure type of the ECOM building block meta-model. One structure may have one or more data members, called attributes of the structure. The data type for each attribute may be a basic data type, an enumerated type, a structured type, or a federated data type.

10) Combination body

The associations represent the association types of the ECOM building block meta-model. There may be one or more data members in a complex, called the attributes of the complex. The data type for each attribute may be a basic data type, an enumerated type, a structured type, or a federated data type.

11) Sequence of

The sequence represents a sequence type of the ECOM building block meta-model. A sequence type can be divided into a fixed-length sequence and an indefinite-length sequence, the attribute types in the sequence must be consistent, and the data type of each attribute can be a basic data type, an enumeration type, a structure type or a combined data type.

In the embodiment of the present invention, the ECOM component meta-model describes the relationship between the plurality of elements and the plurality of elements, and it should be noted that the ECOM component meta-model shown in fig. 2 includes 11 elements, but in practical applications, the ECOM component meta-model may include only some of the 11 elements, that is, the embodiment of the present invention does not limit the specific number of elements included in the ECOM component meta-model.

In practical application, the ECOM component meta-model defined by the UML extension mechanism is a visual and readable model, but the syntax of the expressed component model is not strict, and the ECOM component meta-model needs to be further accurately defined by using a more strict context-free grammar. In the embodiment of the invention, the ECOM component meta-model uses a BNF generation formula to define the syntax of the ECOM component meta-model, and the BNF uses the writing method specified by YACC. The beginning symbol of the grammar is CDL _ definition, and the component Description language defined by the grammar is abbreviated as CDL (component Description language) language in the present specification. The alphabet used in the CDL language is the ASCII standard character set.

The terminals in the CDL language are classified into named terminals and nameless terminals. There are 29 named terminators, listed below:

ENUM Identifier

VOIDIN OUT INOUT INTERFACE SHORT UNSIGNED LONG FLOAT DOUBLE CHAR BOOLEAN OCTET STRING CONSUME PUBLISH PROVIDE REQUIRE PORT COMPONENT STRUCT UNION SEQUENCE

the BNF generation formula of the nameless terminal is defined by an apostrophe, and the lexical requirements of the nameless terminal are as follows:

1)Identifier

an identifier in the CDL language specifies that it must be a string of symbols beginning with a letter or an underline, and the symbols following the first symbol must be letters, numbers, or underlines. All named terminals of the CDL language, except NAME _ DELIMITER, are required to comply with the grammatical rules of the identifier.

The named terminals, except for the identifier, are called reserved words.

From a lexical analysis perspective, identifiers other than reserved words are used to name the component that the component definer defines for itself.

2) Reserved words of CDL

The lexical symbol strings corresponding to the CDL reserved words are all the same as the lexical names of the reserved words, but all the lexical symbol strings are required to be lower case letters. The CDL reserved words are not allowed to be used by component names, interface names, port names, structure name type names, enumeration type names, component member names, operation names in interfaces, parameter names in interface operations, value symbol names in enumeration types and the like.

In the embodiment of the present invention, the ECOM component meta-model describes the elements that need to be in the ECOM component meta-model and the relationship between the elements, and the ECOM component meta-model is only an abstract description, which is not a concrete thing. The Component Description (CDL) is a description of a specific component, i.e., a specific description of the corresponding elements of the component, the basic information of each element, and the relationship between each element and the component.

In practical applications, one component description may include a plurality of components, or may include only one component. In the embodiments of the present invention, the component description is referred to as a component description file.

Further, a method for generating a component entity is introduced, as shown in fig. 3, the method mainly includes:

step 301, acquiring a compiling instruction and a component description file to be compiled carried by the compiling instruction, and generating an intermediate representation for storing the reduction of the component description file according to the component description file to be compiled; the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled is used for defining an ECOM component meta-model;

step 302, the first keyword entity generates a C + + language component code frame according to a frame mapping rule, and the C + + language component code frame is compiled to generate a component entity; and storing the component entities into a component directory included in the C + + language component code framework.

In step 301, a compiling instruction is obtained from the outside, and in practical application, the compiling instruction at least carries a component description file to be compiled, that is, the processor performs lexical analysis and syntactic analysis on the received component description file to be compiled to obtain an intermediate representation process.

Specifically, the process may be described in detail in connection with the software element interaction flow diagram provided in fig. 4:

as shown in fig. 4, the software shown in fig. 4 includes: the device comprises a main control unit, a CDL lexical analysis unit, a CDL syntax analysis unit, an intermediate representation unit and a component code framework generation unit. It should be noted that, the above 5 units can be understood as processor internal data interaction.

Step 301-1: the main control unit firstly calls the intermediate representation unit, and stores an input file name (a file name of a component description file to be compiled), an output path name and an indication of whether to be covered, which are obtained from the compiling switch instruction, into the intermediate representation IR data structure according to the compiling instruction obtained from the outside. Meanwhile, the main control unit opens the component description file to be compiled, and saves a file pointer of the component description file as a global variable, so that the lexical analysis unit can conveniently scan the component description file to be compiled by using the file pointer and carry out lexical analysis.

Specifically, the compiling switch is divided into setting an input path, setting an output path, and whether overlay generation is designated or not.

-i compile a switch: an input path of the component description file to be compiled (a storage path of the component description file to be compiled) is specified. Wherein, i compile switch can have a plurality, namely appoint a plurality of input paths. If a plurality of input paths are specified and the specified input paths contain a plurality of component description files to be compiled, an error is reported because the software does not determine which component description file to be compiled is selected. If the-i compile switch is not used, the CDL compiler only looks under the default path.

-o compile a switch: and specifying an output path of the generated C + + language component code framework. The o compile switch is me parameter followed by the specified output path. There may be multiple-o compiler switches, but only the C + + language building block code framework is generated in the output path after the last-o compiler switch instruction. If the component modeler does not use the-o compiler switch, then the generation of the C + + language component code framework under the default path can only be supported.

-f compiling a switch: and the designated coverage type generates a C + + language component code framework. No parameters need to be entered after the-f parameters. If the-f compiling switch is used, the component code generating tool does not scan whether a C + + language component code frame related to the component description file to be compiled exists under an output path, and generates the C + + language component code frame under the output path directly. If the-f compiling switch is not used, the component code generating unit scans a C + + language component code framework related to the component description file to be compiled under an output path: if the code exists, a C + + language component code framework is not generated; if not, the C + + language component code framework is generated directly under the output path.

Step 301-2: and the main control unit calls a syntax analysis unit to carry out syntax analysis on the comment-free component description file corresponding to the input component description file to be compiled.

The lexical analysis unit reads in characters from the component description file to be compiled, analyzes the characters to obtain an unannotated component description file, and then transmits words included in the unannotated component description file to the syntax analysis unit. The parsing unit obtains one word (token) from the input CDL file stream each time the parsing unit is invoked.

In addition, an important function of the lexical analyzer is to remove annotations.

When the lexical analysis unit encounters an annotation identifier:

if it is the designator "/", the lexical analysis unit enters the single line annotation mode. In this mode, all words encountered by the lexical analysis are considered as empty until a line break is encountered.

If it is the designator "/", the lexical analysis unit enters a multi-line annotation mode. In this mode, all words encountered by the lexical analysis are considered to be null, wherein a line feed is encountered requiring a line number +1, and this mode continues until the designator "/" is encountered. In the case of "/../,", the lexical analysis unit deletes the contents between "/" and the first "/".

Step 301-3: and the grammar analysis unit continuously calls the lexical analysis unit in the grammar analysis process, obtains words from the description file of the non-annotation component, and performs grammar check and semantic analysis on the input word stream. The lexical analysis unit reads characters from the input comment-free component description file by using a pointer of the component description file to be compiled, which is stored by the main control unit, analyzes the characters, and then transmits words obtained by analysis to the grammar analysis unit.

Step 301-4: the syntax analysis unit calls the intermediate representation unit during the syntax analysis to fill the intermediate representation data structure (IR) with the component definition information of the unannotated building block description file that was analyzed and collected.

Intermediate representation generation algorithm as shown in fig. 5, the task of the intermediate representation generation algorithm is to record the ECOM component meta-model defined by the component description file to be compiled into the data structure of IR for the convenience of the component code framework generation unit. The parsing unit populates the IR interface to fill in the content of the intermediate representation data structure. Whenever the analysis process of the building block description file to be compiled completes the reduction of the building block description file of a CDL entity (building block entity) definition, the definition of the building block entity is added to the cdlength list of the current CDLFile accordingly. The method comprises the steps of respectively creating and recording relevant attributes and methods of Component, Port, Interface, Enum, Struct and Union in a Component description file to be compiled according to the type of a Component entity reduced by the current Component description file.

As shown in fig. 5:

step 301-;

step 301-; if there is no import command, execute step 101 and 404;

step 301-.

Step 301-.

Step 301-; if yes, go to step 301 and 506; if not, go to step 301-508;

step 301-.

Step 301-.

Step 301-; if so, execute step 301 and 510;

step 301-; if not, the stack top file to be processed is popped and set as current, and step 301 and step 501 are executed.

It should be noted that the first keyword name herein at least includes a component, an interface, a port, an enumeration, a structure, and a complex.

Step 301-511: after the complete syntax analysis of the input unannotated component description file is completed, all information of the component description given by the component description file to be compiled is recorded in the IR, and at this time, the main control unit calls the component framework code generation unit to generate the C + + language component code framework.

In step 302, consistent with step 301-.

In the embodiment of the present invention, the framework mapping rule mainly includes the following:

1) basic data type mapping

There are 12 primitive data types in the CDL language, and the mapping rules between them and C + + primitive data types are shown in table 1.

TABLE 1C + + mapping of CDL base data types

These basic data types do not have to be specifically defined in generating the code framework file. These primitive data types are used in the C + + code according to the above mapping rules only when they occur in other types (port, interface, struct, etc.).

2) Enumerating (enum) entity type mappings

The syntax of the enum entity definition in the CDL language is consistent with the enum type in C + +, and only direct mapping is needed.

3) Sequence entity type mapping

Sequence entity types can be defined in the CDL language, which is consistent with the vector type in C + +, and has two definition forms, for example, as follows:

vector form 1:

sequence<X>Cars；

vector form 2:

sequence<X，10>Cars；

where X is an entity type name previously defined, or a basic type, and Cars is a newly defined entity type name of a sequence type. The first is used to define an array of indefinite length, the second is used to define an array of definite length.

The first vector form in CDL, in C + +, vector < long > Years; "defines a vector-type variable Years, and in CDL" sequence < long > Years; ", which simply defines a vector data type Years with a member type int, which is not a variable. For example, the following one CDL structure claims:

in this specification, Years is obviously used as an entity type name.

When the vector entity type specification of the CDL is converted into C + + code, the following statement is correspondingly generated in a header file: typedefstd vector < int > Years;

the second vector form in the CDL is stated as follows: sequence < long,20> Years;

then the corresponding C + + is generated for it in the header file as follows: typedef int Years [20 ];

thereafter, the type name Years can be used directly in C + + code to define a variable of int [20] type.

4) Struct entity type mapping

The syntax of the definition of the structure entity in the CDL file is similar to, but not identical to, C + +, and illustrates the structure entity mapping rule as an example. The following is a structural entity-defining fragment of CDL:

mapping to C + + code is:

and related serialization and deserialization codes in the structure body are used for communication support between different components in a distributed environment. The serialization and deserialization here is achieved by means of a boost class library.

5) Port (port) entity type mapping

Ports in CDL should map to class in C + +. The general form of port definition in CDL is (upper and lower bound parts of data values are not contained in the example):

port port_type_name port_data_type；

wherein, port is a reserved word for port type declaration, port _ type _ name is a name taken by a port entity type being defined, and port _ data _ type is a data type associated with the port. The port _ data _ type may be any one of the basic data types given in table 25-1, or may be a type name once defined. One specific example is as follows:

port Sampling PostData；

the representation defines a port entity type called Sampling, whose published or subscribed data type is the structure type PostData.

The port entity type is mapped to class in c + +, and is divided into two types of publishing and subscribing, and the two types are mainly distinguished by a namespace in c + +.

6) Interface entity type mapping

The interface in CDL should map to class in C + +. The general form of the interface definition in CDL is (upper and lower bound parts of data values are not contained in the example):

the interface is a reserved word declared by the interface entity type, and the interface _ type _ name is a name taken by the interface entity type being defined. The operation is a component of a component interface, the form of the operation is a function, each operation can have another or a plurality of parameters, a return value, and the types of the parameters and the return values can be basic data types, enumeration types, structure types and the like, and also can use void to represent that no return value exists. The parameters in the operation can have indicators of three transfer modes of in, out and inout:

and an in indicator, which indicates that the used parameter is an input parameter, namely the parameter substituted into the operation is used by the business process of the operation, but the value of the substituted parameter cannot be changed, and a const modifier is added in the mapping C + + code to indicate that the parameter value cannot be changed.

out indicator, indicating that the corresponding parameter is an output parameter, the value of the parameter cannot be used in the operation business process, but the result can be passed (output) to the caller via the parameter, the c + + code is mapped as a reference, and the parameter index can be changed by adding & indicating the parameter name.

The inout indicator, indicating that the corresponding parameter is both an input parameter and an output parameter, i.e. it has the characteristics of both an input parameter and an output parameter, maps the c + + code as well as the out indicator.

One specific example is as follows:

IExample1 in the code represents the name of the type of the interface, and the interface has two operations of Op1 and Op 2.

Mapping into C + + code is mainly divided into two categories: external supply, external requests and operation return values in the interface, and parameter serialization statements are also distinguished by namespaces in C + +.

7) C + + code mapping of CDL building block entities

The core elements in a building block are interfaces and ports as specified in the CDL language. The interface is used for supporting remote method calling among the components, and the port is used for supporting data interaction among the components in a publish/subscribe mode. In addition, the interfaces in the components are distinguished into two different types, namely Provide and Require. The provider-type Interface (abbreviated as P-Interface) in a component is used for providing services to the outside, and can be called by other components or application programs (remotely), and the Require-type Interface (abbreviated as R-Interface) in the component indicates that the component needs to call the services provided by such Interface. The ports in the member are classified into two different types, namely Publish and Consume. The public type Port (abbreviated as P-Port) in the building block is used for publishing data to the outside, and the Consume type Port (abbreviated as C-Port) is used for subscribing and receiving externally published data.

Furthermore, the component entity is compiled into a C + + language component code framework and is stored in a component directory included in the C + + language component code framework.

In the embodiment of the present invention, it is,

the building block catalog may include the following three catalogs:

1) include directory

And generating a C + + header file with the name consistent with the file name of the component description file to be compiled in the include directory, wherein the C + + header file stores C + + codes converted by using mapping conversion rules by the entities such as vectors, enumerations, structures, ports and interfaces declared in the component description file to be compiled.

2) sourcedirectories

The sources directory generates a C + + source file with a name consistent with the file name of the component description file to be compiled, and the C + + source file stores the implementation of the method in the C + + class after the port and the interface entity stated in the component description file to be compiled are converted by using the mapping conversion rule.

3) Component directory

For each Component defined in the Component description file to be compiled, the Component code generation software generates a sub-directory in the Component directory for which the name is consistent with the name of the Component, i.e. if N components are defined in the Component description file to be compiled, there should be N sub-directories in the Component directory that are consistent with the name of the N components. All C + + codes after the Component entity mapping are stored in the subdirectory of Component by the Component code generation software.

Two subdirectories are generated in each subdirectory with the same name as the component name: include subdirectories and sources subdirectories. And generating a C + + header file with the name consistent with the component name in the include subdirectory, wherein the C + + header file stores the statement of the C + + class after the component entity mapping. A C + + source file with the name consistent with the component name is generated in the Sources subdirectory, and the implementation of the method in the C + + class after the component entity mapping is stored in the C + + source file.

A project file based on vs2010 is stored under each component sub-directory, so that the component implementation personnel can conveniently fill in the service code logic.

In the embodiment of the present invention, the C + + language Component code framework is shown in fig. 6, wherein, commar is a service Component type, which is mapped as a class in C + + and must inherit the fixed Component class. The CommER component provides an interface pInterface of IExample1 type externally, and requests an interface rInterface of IExample1 type; and externally issuing a port pPort of a Sampling type and externally subscribing a port cPort of the Sampling type.

The pInterface is an internal class in the CommER class, inherits the IExample1 class under the namespace Provide, realizes the operation in the interface, and the specific logic of the operation needs the member realization personnel to design according to the requirement actively. rInterface in FIG. 6 is also an internal class in the ComSer class, which inherits the IExample1 class under namespace Require.

In FIG. 6, pPort is an internal class in the ComSer class, inheriting the Sampling class under namespace Publsih. The cPort is also an internal class in the ComSer class and inherits the Sampling class under the namespace Consume, and the specific logic of the DataProcessfunction in the class needs component implementation personnel to design according to requirements.

In addition, a pointer pointing to each internal class object instance is designed in the ComSer class, when a component implementation personnel fills in logic, an external request interface only needs to call Op1 or Op2 functions in the rInterface class, an external release port only needs to assign values to port data, and then a publish function in the pPort class is called.

The construction entity is an information entity containing the functions of the component code framework, and all the service codes filled in the component code framework can be called and used in the component entity. After the user fills the service logic in the corresponding position in the component code frame, the user can directly compile the code frame in the VS2010 to generate a component entity dll file, and each component generates a corresponding dll. The component entity comprises the specific implementation of the method in the user's Provide interface, the service logic of the specific implementation is compiled by the user, the service logic for processing the result after requesting data in the Require interface, the logic for issuing and distributing data by the Publish port, the service processing logic after receiving data by the Consume, and the bottom layer communication mechanism is encapsulated in the service processing logic.

The component entity is not a code frame any more, but an information entity which can be called, and in the windows platform, the building entity is loaded in a dynamic link library mode, so that the component entity can be operated, and a service written by a user in the component code frame can be called.

In step 101, a test instruction is received, where the test instruction carries a component description file to be compiled corresponding to a component entity to be tested, and further the test instruction generally corresponds to two types, namely a port type test and an interface type test, included in testing the component entity to be tested.

It should be noted that, reference may be made to the foregoing embodiment for generating a component entity, and further, a process of generating an intermediate representation for a component description file to be compiled corresponding to a component entity may also be referred to the foregoing embodiment, which is not repeated herein.

In the component entity testing method, however, the component entity comprises a Require interface, a Provide interface, a Publish port and a Consume port; the intermediate representation comprises a Require interface, a Provide interface, a Publish port and a Consume port; the post-related pile member description files also include a Require interface, a Provide interface, a Publish port, and a Consume port. When the test method is introduced, in order to avoid ambiguity of use of a Require interface, a Provide interface, a Publish port and a Consume port, the Require interface, the Provide interface, the Publish port and the Consume port included in the intermediate representation are respectively called a first Require interface, a first Provide interface, a first Publish port and a first Consume port; the pile component description file also comprises a Require interface, a Provide interface, a Publish port and a Consume port which are respectively called a second Require interface, a second Provide interface, a second Publish port and a second Consume port; the component entities including the Require interface, the Provide interface, the Publish port and the Consume port are referred to as a third Require interface, a third Provide interface, a third Publish port and a third Consume port.

Further, it should be noted that, an intermediate representation is obtained according to the component description file to be compiled, and includes at least one element and basic information of each element, where the element includes at least a component, an interface, a port, and an operation; further, the ports at least comprise N first Publish ports and N first Consume ports; the interfaces at least comprise N first Provide interfaces and N first Require interfaces; the operation comprises N parameters and N return values; wherein N is a natural number.

In step 102, test data of the component entity to be tested is generated according to the obtained intermediate representation. It should be noted that, in the embodiment of the present invention, a specific generation method of the test data is not limited.

The selection rule of parameter values in the test data is as follows:

when a parameter set (defined as a structure) to be generated contains n components (x _1, x _2, x _ n), consider a particular input example:

(max(x_1),max(x_2),,max(x_n))

for each x _ i (0< i < n +1) and a small offset r >0, gradually replacing max (x _ i) with min (x _ i) -r and max (x _ i) + r respectively to obtain 2n +1 test cases;

symmetrically, alternative input examples

(min(x_1),min(x_2),,min(x_n))

2n +1 test cases can also be obtained;

this resulted in a total of 4n +2 test cases. Carefully analyzing the 4n +2 measurement examples, wherein values are obtained on the boundary or outside the boundary of the parameter set input space; in order to detect the internal processing of the input space, some test inputs need to be added, and two test points are taken in the input boundary:

(max(x_1)-r,max(x_2)-r,,max(x_n)-r)

(min(x_1)+r,min(x_2)+r,,min(x_n)+r)

therefore, a total of 4n +4 boundary test points are selected. The number of test points is related only to the dimension of the input component of the input parameter set and not to the number of paths, and the test cost is greatly reduced compared to a robust worst case test (7 ^ n test points need to be generated).

The boundary test data generated by the method is used as a proper subset of robust worst-case test data, so that the concept of robustness test is embodied, test points outside the worst-case test data set are included, the requirements of the robust test and the test points are considered, and the boundary coverage degree is improved with lower test cost.

Storage configuration mode of test data

The test data set generates a test data set file in units of a single operation defined under the interface, and each file contains 4n +4 test data (n represents the number of parameters). Each piece of test data occupies one line in the text file and is stored in Json form.

It should be noted that, in the embodiment of the present invention, after the test data is generated according to the intermediate representation, the test data needs to be stored. In order to facilitate later calling of the test data, the test data is preferably stored in a root directory of the to-be-tested component entity, wherein a subfile included in the root directory of the test data corresponds to a port and an interface included in the to-be-tested construction entity.

Specifically, the test data root directory at least comprises interface subfiles named by interface names; each interface subfile is divided into interface type folders according to interface type names of the interfaces, and test data corresponding to the interface types are stored in the interface type folders; furthermore, each third Provide interface included by the to-be-tested construction entity corresponds to a P-type interface subfile included by the test data root directory; and each third Require interface included by the to-be-tested construction entity corresponds to the R-type interface subfile included by the test data root directory.

It should be noted that the interface subfiles included in the test data are a P-type interface subfile and an R-type interface subfile, respectively.

In step 103, performing type conversion on the ports and interfaces included in the intermediate representation to obtain a pile component description file of a component entity to be tested, specifically, modifying all N first Require interfaces included in the intermediate representation into second Provide interfaces to obtain second Provide interfaces included in the pile component description file; and modifying all the N first Publish ports included in the intermediate representation into second Consume ports to obtain the second Consume ports included in the pile member description file.

Further, the pile component description file is input into the component entity generation process, and then the pile program code can be obtained.

In step 104, according to the test instruction, the test data and the stub program code are executed to obtain a test result of the component entity to be tested.

It should be noted that, the test instruction includes a port test and an interface test, the port includes two ports, and the interface includes two interfaces, so the test instruction generally includes four cases, and various test objects are described below.

When the test instruction is to test a third Require interface, reading an R-type interface subfile corresponding to the third Require interface from the component directory, wherein the R-type interface subfile comprises test data corresponding to the type of the R-type interface;

and binding a second Provide interface included by the pile program code with a third Require interface included by a component entity to be tested, reading test data corresponding to the type of the R-type interface by the second Provide interface, and operating the test data corresponding to the type of the R-type interface to obtain a test result of the third Require interface.

Specifically, the test platform loads the component entity to be tested into the memory, and the third Require interface is in the component entity to be tested, and only one interface pointer is maintained. And then, starting a pile program, (because the pile member description file modifies all the N first Require interfaces included in the intermediate representation into second Provide interfaces to obtain second Provide interfaces included in the pile member description file, modifies all the N first Publish ports included in the intermediate representation into second Consume ports to obtain second Consume ports included in the pile member description file), binding a third Require interface of a member entity to be tested with the second Provide interface of the pile member description file, and enabling an interface pointer maintained by the third Require interface to point to an implementation body of the second Provide interface by a test platform.

When the test instruction is to test a third Provide interface, reading a P-type interface subfile corresponding to the third Provide interface from the component directory, wherein the P-type interface subfile comprises test data corresponding to the type of the P-type interface; and running the test data corresponding to the subfile of the P-type interface to obtain the test result of the third Provide interface. It should be noted that, before reading the P-type interface subfile corresponding to the third provider interface from the component directory, the processor provides a function P _ test, where the P _ test function obtains an entry pointer of the third provider interface of the component entity to be tested, calls the third provider interface of the component entity to be tested through the P _ test, and the third provider interface reads data in the test data file.

In practical application, since the third Provide interface provides service to the outside, the third Require interface is called after a request is made, but there is no corresponding third requere interface in the test process, the driver generates a request function, the request function obtains an entry pointer operated by the third Provide interface, the request function reads data in the test file and transmits the data to the third Provide interface, and a data return value processed by the third Provide interface is recorded.

When the test instruction is to test a third Publish port, a second Consume port included in the stub program is bound with a third Publish port interface included in the entity of the component to be tested, and data sent by the third Publish port is recorded through the second Consume port;

in the embodiment of the invention, when a third Publish port of a component entity to be tested is tested, the processor is required to simulate a second Consume port data, and record the data sent by the third Publish port.

Since the third Publish port is only responsible for publishing data to the outside, it is only necessary to record what data the third Publish port publishes to the outside. The middle indicates that the data type of the third Publish is analyzed, the stub program generates a second Consume port which is the same as the data type of the third Publish and used for subscribing data issued by the third Publish port of the component entity to be tested, and the second Consume port receives the data issued by the third Publish port and stores the data in a result file without extra operation.

When the test instruction is to test a third Consume port, reading a C-type port subfile corresponding to the third Consume port from the component directory, wherein the C-type port subfile comprises test data corresponding to the type of the C-type interface; and a second Publish port included by the stub program code is bound with a third Consume port included by the component entity to be tested, reads test data corresponding to the type C interface, and sends the test data corresponding to the type C interface to the third Consume port.

Specifically, when the third Consume port of the to-be-tested component entity is tested, data is sent to all the third Consume ports of the to-be-tested component entity at one time, the driver needs to provide a function, and the function responds to an instruction of the user test port and sends data to all the third Consume ports of the to-be-tested component entity. The transmitted data is obtained by reading the test data.

Since the third Consume is the second Publish port subscribed to accept the data it publishes. And the driver generates a port data release function to simulate data release of the second Publish port, the middle part indicates that the data type of the second Consume port is obtained, the port data release function generated by the driver needs to be kept as same as the data type of the third Consume port, then the port data release function reads data in the test data file and releases the data, and the third Consume port receives the released data and performs own service logic operation.

Further, after the entity of the component to be tested is tested, the test result is stored in a test record root directory, and in the embodiment of the invention, the test record root directory comprises a P-type port result directory and a P-type interface result directory; and the test record root directory is positioned under the component directory corresponding to the entity to be tested.

Specifically, the test result includes a test result log file for testing the interface and a test result log file for testing the port. The method comprises the steps of testing an interface of a component entity to be tested, recording an execution result of an interface function, and recording a return value after the interface function is executed and an Out or inout parameter, so that a user can conveniently check the return value. The record file of the port test is generated when the stub program receives data sent by the third Publish port of the tested component, and the stub program records the data in a format of Json plus a timestamp.

Further, the directory organization of the test result record file is expanded on the directory organization of the original user code file, that is, the test record root directory corresponding to the test result is stored in the component directory corresponding to the entity to be tested. The test record root directory is divided into a P-type port result directory and a P-type interface result directory, the former is used for recording received port data when a third Publish port included by a component entity to be tested is subscribed in the stub program, and the latter is used for recording an execution result of an interface function when the interface of the component entity to be tested in the driver program is driven.

Based on the same inventive concept, embodiments of the present invention provide an embedded component entity testing apparatus, and since the principle of the apparatus for solving the technical problem is similar to an embedded component entity testing method, the implementation of the apparatus can refer to the implementation of the method, and repeated details are not repeated.

As shown in fig. 7, the component entity testing apparatus mainly includes a generating unit 701, a storing unit 702, a obtaining unit 703 and a testing unit 704.

A generating unit 701, configured to receive a test instruction, where the test instruction carries a component description file to be compiled corresponding to a component entity to be tested, and generate an intermediate representation according to the component description file to be compiled; the test instruction corresponds to an interface test and a port test;

a storage unit 702, configured to obtain test data of the component entity to be tested according to a generation policy by the intermediate representation, and store the test data in a test data root directory, where a subfile included in the test data root directory corresponds to a port and an interface of the component entity to be tested, where the test data root directory is located under the component directory corresponding to the component entity to be tested;

an obtaining unit 703, configured to perform type conversion on the port and the interface included in the intermediate representation to obtain a pile component description file and a pile program code of the component entity to be tested;

the testing unit 704 is configured to execute the test data and the stub program code according to the test instruction, so as to obtain a test result of the to-be-tested component entity.

Preferably, the storage unit 702 is specifically configured to:

the test data root directory at least comprises interface subfiles named by interface names; each interface subfile is divided into interface type folders according to interface type names of interfaces, and test data corresponding to the interface types are stored in the interface type folders; the interface subfiles comprise a P-type interface subfile and an R-type interface subfile; each third Provide interface included by the to-be-tested construction entity corresponds to a P-type interface subfile included by the test data root directory; each third Require interface included by the entity to be tested corresponds to an R-type interface subfile included by the test data root directory;

the test data root directory at least comprises port subfiles named by port names; each port subfile is divided into port type folders according to port type names of ports, and test data corresponding to the port types are stored in the port type folders; wherein the port subfiles comprise type C port subfiles; and each Consume port included by the to-be-tested construction entity corresponds to a C-type port subfile included by the test data root directory.

It should be understood that the above embedded component entity testing apparatus includes only units that are logically divided according to the functions implemented by the apparatus, and in practical applications, the above units may be stacked or split. The functions implemented by the embedded component entity testing apparatus provided in this embodiment correspond to the embedded component entity testing method provided in the above embodiment one to one, and for the more detailed processing flow implemented by the apparatus, detailed description is already made in the above method embodiment, and detailed description is not given here.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method for testing an embedded component entity is characterized by comprising the following steps:

2. The testing method of claim 1, wherein the intermediate representation comprises at least one element and basic information for each of the elements, the elements comprising at least components, interfaces, ports, and operations;

the ports at least comprise N first Publish ports and N first Consume ports;

the interfaces at least comprise N first Provide interfaces and N first Require interfaces;

the operation comprises N parameters and N return values;

wherein N is a natural number.

3. The testing method according to claim 2, wherein performing type conversion on the port and the interface included in the intermediate representation to obtain a pile component description file of the component entity to be tested specifically includes:

modifying all the N first Require interfaces included in the intermediate representation into second Provide interfaces to obtain second Provide interfaces included in the pile member description file;

and modifying all the N first Publish ports included in the intermediate representation into second Consume ports to obtain the second Consume ports included in the pile member description file.

4. The method according to claim 1, wherein the storing the test data in a test data root directory specifically comprises:

the test data root directory at least comprises interface subfiles named by interface names;

each interface subfile is divided into interface type folders according to interface type names of interfaces, and test data corresponding to the interface types are stored in the interface type folders; the interface subfiles comprise a P-type interface subfile and an R-type interface subfile;

each third Provide interface included by the to-be-tested construction entity corresponds to a P-type interface subfile included by the test data root directory; and each third Require interface included by the entity to be tested corresponds to an R-type interface subfile included by the test data root directory.

5. The testing method of claim 4, wherein the executing the test data corresponding to the component entity to be tested and the stub program code according to the test instruction to obtain the test result of the component entity to be tested specifically comprises:

when the test instruction is used for testing a third Require interface, reading an R-type interface subfile corresponding to the third Require interface from the component directory, wherein the R-type interface subfile comprises test data corresponding to the type of the R-type interface; a second Provide interface included by the stub program code is bound with a third Require interface included by the component entity to be tested, the second Provide interface reads test data corresponding to the type of the R-type interface, and the test data corresponding to the type of the R-type interface is operated to obtain a test result of the third Require interface; or

When the test instruction is used for testing a third Provide interface, reading a P-type interface subfile corresponding to the third Provide interface from the component directory, wherein the P-type interface subfile comprises test data corresponding to the type of the P-type interface; and running the test data corresponding to the P-type interface subfile to obtain the test result of the third Provide interface.

6. The method according to claim 1, wherein the storing the test data in a test data root directory specifically comprises:

the test data root directory at least comprises port subfiles named by port names;

each port subfile is divided into port type folders according to port type names of ports, and test data corresponding to the port types are stored in the port type folders; wherein the port subfiles comprise type C port subfiles;

and each Consume port included by the to-be-tested construction entity corresponds to a C-type port subfile included by the test data root directory.

7. The testing method of claim 6, wherein the executing the test data corresponding to the component entity to be tested and the stub program code according to the test instruction to obtain the test result of the component entity to be tested specifically comprises:

when the test instruction is to test a third Publish port, a second Consume port included in the stub program is bound with a third Publish port interface included in the to-be-tested member entity, and data sent by the third Publish port is recorded through the second Consume port; or

When the test instruction is to test a third Consume port, reading a C-type port subfile corresponding to the third Consume port from the component directory, wherein the C-type port subfile comprises test data corresponding to a C-type interface type; and binding a second Publish port included by the stub program code with a third Consume port included by the component entity to be tested, reading test data corresponding to the type C interface by the second Publish port, and sending the test data corresponding to the type C interface to the third Consume port.

8. The testing method of claim 1, wherein after obtaining the testing result of the component entity to be tested, further comprising:

storing a test result to a test record root directory, wherein the test record root directory comprises a P-type port result directory and a P-type interface result directory; and the test record root directory is positioned under the component directory corresponding to the entity to be tested.

9. An embedded component physical testing device, comprising:

10. The test apparatus of claim 9, wherein the storage unit is specifically configured to: