An embedded component entity testing method and apparatus

Abstract

The application discloses an embedded component entity test method and device, and relates to the technical field of embedded software. The method is used to solve the problem that the existing component entity test method needs to analyze the source code of the component, thereby increasing the workload and difficulty. 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; generating an intermediate representation according to the component description file to be compiled; obtaining test data of the component entity to be tested according to the generation strategy of the intermediate representation; storing the test data to a test data root directory, wherein the test data root directory comprises subfiles corresponding to ports and interfaces of the component entity to be tested; performing type conversion on the ports and interfaces included in the intermediate representation to obtain a stub component description file and a stub program code of the component entity to be tested; and executing the test data and the stub program code according to the test instruction to obtain a test result of the component entity to be tested.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of embedded software technology, and more particularly, to an embedded component entity testing method and device. BACKGROUND

[0002] The command system software belongs to a typical distributed embedded software system. With the continuous enhancement of the function of the embedded software system, the scale and complexity of the embedded software are rapidly increasing. How to improve the design and development process of the embedded software, improve the development efficiency and enhance the product quality has become a hot spot of the embedded software research. The component-based software development method as a very promising solution has been gradually applied in the development of large-scale embedded software system.

[0003] With the wide application of the component-based software development method, new problems of component testing have also been brought. How to ensure that the existing component meets the functional requirements and meets the safety requirements of the software system. Revealing component errors, verifying component quality and revealing possible problems in assembling new systems by using components have become the main purpose of the component testing method.

[0004] The component testing is similar to the traditional software unit testing, which is a testing process for revealing component errors and verifying component quality. The component-based software integration testing is similar to the traditional software integration testing process, which mainly reveals the problems in the system when assembling new systems by using components.

[0005] In summary, the existing component entity testing method needs to analyze the source code of the component, which leads to the problems of increased workload and difficulty. SUMMARY

[0006] The embodiment of the present application provides an embedded component entity testing method and device. The problems of the existing component entity testing method, which needs to analyze the source code of the component, leading to the problems of increased workload and difficulty, are solved.

[0007] The embodiment of the present application further provides an embedded component entity testing method, which comprises:

[0008] After receiving a test instruction, the test instruction carries a component description file to be compiled corresponding to a component entity to be tested, and an intermediate representation is generated according to the component description file to be compiled. The test instruction corresponds to an interface class test and a port class test.

[0009] The intermediate means that the test data of the component entity to be tested is obtained according to the generation strategy, and the test data is stored in the test data root directory. The sub-files included in the test data root directory correspond to the ports and interfaces of the component entity to be tested. The test data root directory is located in the component directory corresponding to the component entity to be tested.

[0010] The ports and interfaces included in the intermediate representation are type-converted to obtain the pile component description file and pile program code of the component entity to be tested;

[0011] According to the test instructions, the test data and the piling program code are executed to obtain the test results of the entity to be tested.

[0012] This invention also provides an embedded component entity testing device, comprising:

[0013] A generation unit is configured to receive a test instruction, which carries a component description file to be compiled corresponding to the component entity to be tested, and generate an intermediate representation based on the component description file to be compiled; wherein, the test instruction corresponds to interface class testing and port class testing;

[0014] The storage unit is used for the intermediate representation to obtain the test data of the component entity to be tested according to the generation strategy, store the test data in the test data root directory, and the sub-files included in the test data root directory correspond to the ports and interfaces of the component entity to be tested, wherein the test data root directory is located in the component directory corresponding to the component entity to be tested;

[0015] The unit is used to convert the ports and interfaces included in the intermediate representation to obtain the pile component description file and pile program code of the component entity to be tested;

[0016] The testing unit is used to execute test data and the stub program code according to the test instructions to obtain the test results of the entity to be tested.

[0017] This invention provides an embedded component entity testing method and apparatus. The method includes: receiving a test instruction, the test instruction carrying a component description file to be compiled corresponding to the component entity to be tested; generating an intermediate representation based on the component description file to be compiled; wherein the test instruction corresponds to interface class testing and port class testing; the intermediate representation obtains test data of the component entity to be tested according to a generation strategy; storing the test data in a test data root directory, and the sub-files included in the test data root directory correspond to the ports and interfaces of the component entity to be tested; the test data root directory is located in the component directory corresponding to the component entity to be tested; performing type conversion on the ports and interfaces included in the intermediate representation to obtain a stub component description file and stub program code of the component entity to be tested; executing the test data and the stub program code according to the test instruction to obtain the test result of the component entity to be tested. This component entity testing method can assist users in testing component entities, simplify cumbersome testing processes, detect whether the functionality of the component entity meets expectations, detect the correctness and security of the component, and improve software reliability. Attached Figure Description

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

[0019] Figure 1 This is a schematic flowchart of an embedded component entity testing method provided by an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of the ECOM component meta-model structure provided in an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of a component entity generation method provided in an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram of the software unit interaction process provided in an embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram of the intermediate representation algorithm provided in an embodiment of the present invention;

[0024] Figure 6 This is a schematic diagram of the C++ language component code framework structure provided in an embodiment of the present invention;

[0025] Figure 7This is a schematic diagram of an embedded component entity testing device provided in an embodiment of the present invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] To further illustrate the component entities provided in the embodiments of the present invention, the following describes the testing methods for the corresponding component entities, such as... Figure 1 As shown, this testing method mainly includes the following steps:

[0028] Step 101: Receive a test instruction, which carries a component description file to be compiled corresponding to the component entity to be tested, and generate an intermediate representation based on the component description file to be compiled; wherein, the test instruction corresponds to interface class testing and port class testing;

[0029] Step 102, the intermediate means that the test data of the component entity to be tested is obtained according to the generation strategy, the test data is stored in the test data root directory, and the sub-files included in the test data root directory correspond to the ports and interfaces of the component entity to be tested. The test data root directory is located in the component directory corresponding to the component entity to be tested.

[0030] Step 103: Convert the types of the ports and interfaces included in the intermediate representation to obtain the pile component description file and pile program code of the component entity to be tested;

[0031] Step 104: According to the test instructions, execute the test data and the piling program code to obtain the test results of the entity to be tested.

[0032] It should be noted that before introducing the component entity testing method, we will first introduce the ECOM component meta-model, component description, and component description file.

[0033] like Figure 2As shown, the ECOM component metamodel mainly includes 11 elements, namely Component, ComAttribute, Interface, Port, ComParameter, Operation, Struct, Union, Sequence, Enumeration, and Fundamental Types.

[0034] It should be noted that the core component of the ECOM component metamodel is the component, followed by component attributes, interfaces, ports, and component parameters, which have the characteristics of structured data; other auxiliary meta-objects include operations, structures, unions, sequences, enumeration types, and basic data types.

[0035] The following is a basic introduction to the above 11 elements:

[0036] 1) Components

[0037] A component can contain zero or more component parameters, zero or more component attributes, zero or more interfaces, and zero or more ports.

[0038] In this embodiment of the invention, the interfaces included in the component are divided into Provide interfaces that provide services to the outside of the component and Require interfaces that require services from other external components; the ports included in the component are divided into Publish ports that publish data to the outside and Consume ports that receive data published by other components.

[0039] A component definition can include zero or more other predefined components. This is a component composition mechanism to support the combination of existing components into larger components, thereby forming a hierarchical relationship based on inclusion between components so that users can grasp and use components at different levels.

[0040] 2) Component parameters

[0041] Component parameters can only be set when creating a component instance. They are used to specify the component's operating parameters and operating mode, such as operating in BIT mode or ground test mode.

[0042] It should be noted that in practical applications, a component instance does not refer to a specific component, but rather to a component in general; a component instance is, in effect, a real-world representation of that component. A component is a virtual entity, while a component instance brings that component to life.

[0043] The parameters of a component can only have basic data types or enumeration types.

[0044] 3) Component properties

[0045] Component attributes represent the state displayed by a component and are used by the component's internal business logic. Component attributes must be set during component initialization, but can also be set by the component's internal business logic during component execution.

[0046] Attributes can only have basic data types or enumeration types.

[0047] 4) Port

[0048] A port is a mechanism for a component to communicate data with other external components.

[0049] A component can have zero or more Publish ports, each used to publish data to other external components. The definer, developer, and implementer of a component do not need to know which components are subscribing to the data published by the Publish ports.

[0050] A component can also have zero or more Consume ports, each used to subscribe to data published by the Publish ports of other external components. The definer, developer, and implementer of a component do not need to know which component published the data received by the Consume port.

[0051] Both the Publish and Consume ports must specify a data type, which can be a basic data type, an enumeration type, a structure type, a sequence, or a union data type.

[0052] When assembling components into a specific application, it is necessary to specify the corresponding connection relationship between the Publish port and Consume port of different component instances. The corresponding Publish port and Consume port must be associated with compatible data types.

[0053] 5) Interface

[0054] The interfaces included in a component are divided into Provide interfaces, which provide services to the outside of the component, and Require interfaces, which require services from other external components.

[0055] The Provide interface of a component is used to provide services to the outside world, while the Require interface indicates that services provided by the corresponding interfaces of other components need to be called. An interface can contain one or more operations.

[0056] When assembling applications using components, a component's Provide interface can connect to multiple other components' Require interfaces; however, a component's Require interface can only connect to another component's Provide interface.

[0057] 6) Operation

[0058] Operations are components of the component interface and take the form of functions.

[0059] Each operation can have zero or more parameters and a return value.

[0060] The types of parameters and return values ​​can be basic data types, enumeration types, structure types, sequence types, or union data types. You can also use `void` to indicate that there is no return value.

[0061] The parameters in an operation can be passed using three modes: in, out, and inout. Specifically, the in indicator indicates that the corresponding parameter is an input parameter, meaning it is used in the operation's business process but its value cannot be changed. The out indicator indicates that the corresponding parameter is an output parameter; its value cannot be used during the operation's business processing, but the result can be passed (output) to the caller through this parameter. The inout indicator indicates that the corresponding parameter is both an input and an output parameter, meaning it possesses the characteristics of both.

[0062] 7) Basic data types

[0063] The meanings of basic data types are the same as those in the CORBA IDL specification.

[0064] 8) Enumeration type

[0065] An enumeration data type is a simple data type. An enumeration type specifies a finite number (at least one) of named symbolic values.

[0066] 9) Structure

[0067] A structure represents the structural type of an ECOM component metamodel. A structure can have one or more data members, called the structure's attributes. The data type of each attribute can be a basic data type, an enumeration type, a structure type, or a union data type.

[0068] 10) Consortium

[0069] A union represents the union type of an ECOM component metamodel. A union can have one or more data members, called union attributes. The data type of each attribute can be a basic data type, an enumeration type, a structure type, or a union data type.

[0070] 11) Sequence

[0071] A sequence represents the sequence type of an ECOM component metamodel. A sequence type can be divided into fixed-length sequences and variable-length sequences. The attribute types in a 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 union data type.

[0072] In this embodiment of the invention, the ECOM component meta-model describes the aforementioned multiple elements and the relationships between them. It should be noted that... Figure 2 The ECOM component meta-model shown includes 11 elements, but in practical applications, the ECOM component meta-model may only include a few of the above 11 elements. That is, the specific number of elements included in the ECOM component meta-model is not limited in the embodiments of the present invention.

[0073] In practical applications, the ECOM component metamodel defined using the UML extension mechanism is a visual and easy-to-read model, but its syntax is not rigorous. A more rigorous context-free grammar is needed to further accurately define the ECOM component metamodel. In this embodiment of the invention, the ECOM component metamodel uses BNF production rules to define its syntax, and BNF adopts the notation specified by YACC. The start symbol for this grammar is CDL_declare, and the component description language defined by this grammar is abbreviated as CDL (Component Description Language) in this specification. The alphabet used by CDL is the ASCII standard character set.

[0074] In CDL, terminal symbols are divided into named terminal symbols and unnamed terminal symbols. There are 29 named terminal symbols in total, listed below:

[0075] ENUM Identifier

[0076] VOIDIN OUT INOUT INTERFACE SHORT UNSIGNED LONG FLOAT DOUBLE CHARBOLEAN OCTET STRING CONSUME PUBLISH PROVIDE REQUIRE PORT COMPONENT STRUCTUNION SEQUENCE

[0077] In BNF productions of unnamed terminal symbols, all symbols are enclosed in single quotes. The lexical requirements for named terminal symbols are as follows:

[0078] 1) Identifier

[0079] In the CDL language, identifiers must be strings of symbols that begin with a letter or an underscore, and all subsequent symbols must be letters, numbers, or underscores. All named terminals in the CDL language, except for NAME_DELIMITER, must conform to the identifier syntax rules.

[0080] All named terminal symbols except Indentifier are called reserved words.

[0081] From a lexical analysis perspective, identifiers other than reserved words are used by component definers to name the components they define.

[0082] 2) Reserved words in CDL

[0083] The lexical symbol strings corresponding to CDL reserved words are all the same as the lexical names of the reserved words, but must be all lowercase letters. CDL reserved words are not allowed in component names, interface names, port names, structure type names, enumeration type names, component member names, operation names in interfaces, parameter names in interface operations, and value symbol names in enumeration types.

[0084] In this embodiment of the invention, the ECOM component metamodel describes the elements required in the ECOM component metamodel and the relationships between these elements. The ECOM component metamodel is merely an abstract description, not a concrete entity. In contrast, the component description (CDL) is a description of a specific component, that is, the elements corresponding to the component, the basic information of each element, and the specific description of the relationships between each element and the component.

[0085] In practical applications, a component description may include multiple components or only one component. In this embodiment of the invention, the component description is referred to as a component description file.

[0086] Furthermore, the methods for generating component entities are introduced, such as... Figure 3 As shown, the method mainly includes:

[0087] Step 301: Obtain the compilation instructions and the component description file to be compiled carried by the compilation instructions; generate an intermediate representation of the reduced component description file based on the component description file to be compiled; wherein, the component description file reduction records at least one element included in the component description file to be compiled and the basic information of the element through the first keyword entity; the component description file to be compiled is used to define the ECOM component metamodel.

[0088] Step 302: The first keyword entity generates a C++ language component code framework according to the framework mapping rules, and the C++ language component code framework is compiled to generate component entities; the component entities are stored in the component directory included in the C++ language component code framework.

[0089] In step 301, compilation instructions are obtained from an external source. In practical applications, these compilation instructions at least carry a component description file to be compiled. That is, the processor performs lexical analysis and syntax analysis on the received component description file to be compiled to obtain an intermediate representation.

[0090] Specifically, this process can be combined with Figure 4 The provided software unit interaction flowchart will be used to explain in detail:

[0091] like Figure 4 As shown, Figure 4 The software shown includes: 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 all five units can be understood as internal data interactions within the processor.

[0092] Step 301-1: The main control unit first calls the intermediate representation unit. Based on the compilation instructions obtained from the outside, it stores the input filename (the filename of the component description file to be compiled), output pathname, and overwrite indication obtained from the compilation switch instruction into the intermediate representation IR data structure. Simultaneously, the main control unit opens the component description file to be compiled and saves its file pointer as a global variable, so that the lexical analysis unit can use this file pointer to scan the component description file to be compiled and perform lexical analysis.

[0093] Specifically, the compiler switches are divided into setting the input path, setting the output path, and specifying whether to use overwrite generation.

[0094] The `-i` compiler switch specifies the input path for the component description file to be compiled (the path where the component description file is stored). Multiple `-i` switches can be specified, meaning multiple input paths can be specified. If multiple input paths are specified, and these paths contain multiple component description files to be compiled, an error will occur because the software is unsure which component description file to select. If the `-i` compiler switch is not used, the CDL compiler will only search in the default path.

[0095] The `-o` compiler switch specifies the output path for the generated C++ component code framework. The `-o` compiler switch is the output path specified immediately after my argument. Multiple `-o` compiler switches are allowed, but the C++ component code framework will only be generated in the output path following the last `-o` compiler switch instruction. If the component modeler does not use the `-o` compiler switch, only the default path will be supported for generating the C++ component code framework.

[0096] The `-f` compiler switch specifies overlay-style generation of C++ language component code frameworks. No arguments are required after `-f`. If the `-f` compiler switch is used, the component code generation tool does not scan the output path for a C++ language component code framework associated with the component description file to be compiled; it directly generates the C++ language component code framework in the output path. If the `-f` compiler switch is not used, the component code generation unit scans the output path for a C++ language component code framework associated with the component description file to be compiled: if it exists, it does not generate a C++ language component code framework; if it does not exist, it directly generates a C++ language component code framework in the output path.

[0097] Step 301-2: The main control unit calls the syntax analysis unit to perform syntax analysis on the uncommented component description file corresponding to the input component description file to be compiled.

[0098] The lexical analysis unit reads characters from the component description file to be compiled, analyzes them to obtain an uncommented component description file, and then passes the words included in the uncommented component description file to the syntax analysis unit. Each time the syntax analysis unit calls the lexical analysis unit, it obtains one word (token) from the input CDL file stream.

[0099] In addition, an important function of the lexical analyzer is to remove comments.

[0100] When the lexical analysis unit encounters a comment identifier:

[0101] If the identifier is " / / ", the lexical analysis unit enters single-line comment mode. In this mode, all words encountered by the lexical analysis are treated as empty until a newline character is encountered.

[0102] If the identifier is " / *", the lexical analysis unit enters multi-line comment mode. In this mode, all words encountered by the lexical analysis are treated as empty, and the line number is incremented by 1 when a newline character is encountered. This mode continues until the identifier "* / " is encountered. For the case of " / *...* / ...* / ", the lexical analysis unit will delete the content between " / *" and the first "* / ".

[0103] Step 301-3: During the syntax analysis process, the syntax analysis unit continuously calls the lexical analysis unit to obtain words from the unannotated component description file and performs syntax checks and semantic analysis on the input word stream. The lexical analysis unit uses a pointer to the component description file to be compiled, stored in the main control unit, to read characters from the input unannotated component description file, analyzes them, and then passes the analyzed words to the syntax analysis unit.

[0104] Step 301-4: During the syntax analysis process, the syntax analysis unit calls the intermediate representation unit to fill the intermediate representation data structure (IR) with the component definition information of the analyzed and collected unannotated component description files.

[0105] intermediate representation generation algorithm such as Figure 5 As shown, the task of the intermediate representation generation algorithm is to record the ECOM component metamodel defined in the component description file to be compiled into the IR data structure for easy use by the component code framework generation unit. The syntax analysis unit fills in the contents of the intermediate representation data structure by populating the IR interface. Whenever the component description file analysis process completes the reduction of a CDL entity (component entity) definition in the component description file to be compiled, the definition of that component entity is added to the CDLEntity list of the current CDLFile accordingly. Based on the type of the component entity reduced by the current component description file, it creates and records the relevant attributes and methods of Component, Port, Interface, Enum, Struct, and Union in the component description file to be compiled.

[0106] Specifically, such as Figure 5 As shown:

[0107] Steps 301-501: The parsing unit scans the unannotated component description file;

[0108] Steps 301-502: Determine whether the unannotated component description file contains an import directive. If an import directive exists, proceed to steps 101-503; otherwise, proceed to steps 101-404.

[0109] Steps 301-503: Push the current component description file onto the processing stack, search for the imported component description file in the same directory, and then go back to steps 101-501 to process the newly found component description language.

[0110] Steps 301-504: If a comment is encountered while scanning the component description file, skip the comment and scan the next line.

[0111] Steps 301-505: Scan the words contained in the unannotated component description file and determine whether the read words match the first keyword name included in the keyword entity; if they match, proceed to steps 301-506; if they do not match, proceed to steps 301-508.

[0112] Steps 301-506: Identify the word that matches the first keyword name as the first word, and then add the first word and its basic information to the matching first keyword entity.

[0113] Steps 301-507: Add the pointer to the first keyword entity to the component description file reduction corresponding to the unannotated component description file, and add the definition of the first keyword entity to the component description file reduction.

[0114] Steps 301-508: Identify the word that does not match the first keyword name as the second word, generate a first keyword entity based on the second word, and add the new first keyword entity to the component description file for reduction.

[0115] Steps 301-509: Determine whether the unannotated component description file has been processed. If not, proceed to steps 301-501; if it has been processed, proceed to steps 301-510.

[0116] Steps 301-510: Determine if the stack to be processed is empty. If it is empty, the process ends. If it is not empty, pop the top file of the stack to be processed and set it as the current file, then execute steps 301-501.

[0117] It should be noted that the primary keyword name here includes at least components, interfaces, ports, enumerations, structures, and unions.

[0118] Steps 301-511: After completing the full syntax analysis of the input uncommented component description file, all the information of the component description given by the component description file to be compiled has been recorded in the IR. At this time, the main control unit calls the component framework code generation unit to generate the C++ language component code framework.

[0119] In step 302, consistent with steps 301-511, the component code framework generation unit calls the intermediate representation unit. The intermediate representation unit stores the component description file reduction, which includes the first keyword entity. The first keyword entity generates a C++ language component code framework according to the framework mapping rules.

[0120] In this embodiment of the invention, the frame mapping rules mainly include the following:

[0121] 1) Basic data type mapping

[0122] There are 12 basic data types in the CDL language, and the mapping rules between them and the basic data types in C++ are shown in Table 1.

[0123] Table 1. C++ Mapping of Basic CDL Data Types

[0124]

[0125] These basic data types do not need to be explicitly defined in the generated code framework file. They are only used in the C++ code according to the mapping rules described above when they appear in other types (port, interface, struct, etc.).

[0126] 2) Enumeration entity type mapping

[0127] The syntax for defining enum entities in CDL is the same as that for enum types in C++, requiring only direct mapping.

[0128] 3) Sequence entity type mapping

[0129] In the CDL language, sequence entity types can be defined, similar to the vector type in C++. There are two definition forms, as shown in the examples below:

[0130] Vector form 1:

[0131] sequence <x>Cars;

[0132] Vector form 2:

[0133] sequence<X, 10> Cars;

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

[0135] First vector form in CDL: In C++, "vector <long>Years; " defines a vector type variable Years, while in CDL "sequence <long>Years;", which simply defines a vector data type Years of member type int, this Years is not a variable. For example, the following CDL structure declaration:

[0136]

[0137] In this declaration, Years is apparently used as an entity type name.

[0138] This vector entity type declaration of CDL, when converted to C++ code, correspondingly generates the following declaration in the header file: typedef std::vector <int>Years;

[0139] The second vector form in CDL: Suppose there is a declaration in CDL as follows: sequence<long,20> Years;

[0140] Then the corresponding C++ declaration for it in the header file is as follows: typedef int Years

[20] ;

[0141] After that, the type name Years can be used directly in C++ code to define a variable of int

[20] type.

[0142] 4) Struct entity type mapping

[0143] The syntax of struct entity definition in CDL file is similar to C++, but not exactly the same. An example is given to illustrate the struct entity mapping rules. The following is a fragment of struct entity definition in CDL:

[0144]

[0145] The mapping to C++ code is as follows:

[0146]

[0147] The serialization and deserialization code related to the struct is used to support communication between different components in a distributed environment. The serialization and deserialization here are implemented with the help of the boost class library.

[0148] 5) Port entity type mapping

[0149] The port in CDL should be mapped to class in C++. The general form of port definition in CDL is as follows (without the upper and lower bound constraints of data values in the example):

[0150] port port_type_name port_data_type;

[0151] Where port is a reserved word for port type declaration, port_type_name is the name taken for the port entity type being defined, and port_data_type is the data type associated with the port. port_data_type can be any of the basic data types given in Table 25-1, or a previously defined type name. A specific example is as follows:

[0152] port Sampling PostData;

[0153] This indicates that a port entity type called Sampler has been defined, and the data type for its publication or subscription is the structure type PostData.

[0154] The port entity type is mapped to a class in C++, which is divided into two categories: publish and subscribe, mainly distinguished by namespaces in C++.

[0155] 6) Interface entity type mapping

[0156] Interfaces in a CDL should be mapped to classes in C++. The general form of an interface definition in a CDL is as follows (the example does not include upper and lower bound constraints for data values):

[0157]

[0158] Here, `interface` is a reserved word for declaring the interface entity type, and `interface_type_name` is the name given to the interface entity type being defined. Operations are components of the interface, taking the form of functions. Each operation can have one or more parameters and a return value. The types of parameters and return values ​​can be primitive data types, enumeration types, struct types, etc., or `void` can be used to indicate no return value. The parameters in the operations can have three passing modes: `in`, `out`, and `inout`.

[0159] The `in` directive indicates that the parameter being used is an input parameter, meaning it is substituted into the operation for use in the business process. However, the value of the substituted parameter cannot be changed. In the mapped C++ code, the `const` modifier should be added to indicate that the parameter value cannot be changed.

[0160] The `out` directive indicates that the corresponding parameter is an output parameter. The value of this parameter cannot be used during the business processing of the operation, but the result can be passed to the caller through this parameter. In C++ code, it is mapped as a reference. Adding `&` before the parameter name indicates that the parameter can be changed.

[0161] The inout directive indicates that the corresponding parameter is both an input parameter and an output parameter; that is, it has the characteristics of both input and output parameters. It maps C++ code in the same way as the out directive.

[0162] A specific example is as follows:

[0163]

[0164] In the code, IExample1 represents the interface type name, and the interface has two operations, Op1 and Op2.

[0165] The mapping to C++ code is mainly divided into two categories: providing externally, externally requesting and interface operation return value, parameter serialization declaration, which is also distinguished by namespace in C++.

[0166] 7) C++ code mapping of CDL component entity

[0167] According to the provisions of the CDL language, the core elements in the component are interfaces and ports. The interface is used to support remote method invocation between components, and the port is used to support data interaction between components in a publish / subscribe manner. In addition, the interface in the component is divided into two different types: Provide and Require. The Provide type interface (P-Interface for short) in the component is used to provide services to the outside world, which can be called by other components or application programs (remotely), while the Require type interface (R-Interface for short) in the component indicates that the component needs to call the services provided by this type of interface. The port in the component is also divided into two different types: Publish and Consume. The Publish type port (P-Port for short) in the component is used to publish data externally, while the Consume type port (C-Port for short) is used to subscribe and receive externally published data.

[0168] Further, the C++ language component code framework is compiled to generate a component entity, and the component entity is stored in the component directory included in the C++ language component code framework.

[0169] In the embodiment of the present application,

[0170] The component directory can include the following three directories:

[0171] 1) include directory

[0172] A C++ header file with the same name as the file name of the component description file to be compiled will be generated in the include directory. The C++ header file saves the C++ code after the mapping conversion of the entities such as vectors, enumerations, structures, ports and interfaces declared in the component description file to be compiled using the mapping conversion rule.

[0173] 2) sources directory

[0174] A C++ source file with the same name as the file name of the component description file to be compiled will be generated in the sources directory. The C++ source file saves the implementation of the method in the C++ class after the mapping conversion of the port and interface entities declared in the component description file to be compiled using the mapping conversion rule.

[0175] 3) Component directory

[0176] For each component defined in the component description file to be compiled, the component code generation software generates a subdirectory with the same name as the component in the Component directory, that is, if there are N components defined in the component description file to be compiled, there should be N subdirectories with the same name as the N components in the Component directory. All C++ codes after component entity mapping are stored in the subdirectories of Component by the component code generation software.

[0177] Two subdirectories, an include subdirectory and a sources subdirectory, are generated in each subdirectory with the same name as the component. The include subdirectory generates a C++ header file with the same name as the component, which saves the declaration of the C++ class after component entity mapping. The sources subdirectory generates a C++ source file with the same name as the component, which saves the implementation of the method in the C++ class after component entity mapping.

[0178] A project file based on vs2010 is stored in each component subdirectory to facilitate the component implementer to fill in the business code logic.

[0179] In the embodiment of the application, the C++ language component code framework is as shown in Figure 6 ComSer is a service component type, which is mapped to a class in C++ and must inherit the fixed Component class. The ComSer component provides an interface pInterface of type IExample1 to the outside, requests an interface rInterface of type IExample1, publishes a port pPort of type Sampling to the outside, and subscribes to a port cPort of type Sampling.

[0180] pInterface is an internal class in the ComSer class, the pInterface class inherits the IExample1 class under the namespace Provide, and the pInterface class implements the operations in the interface. The operation specific logic needs to be actively designed by the component implementer according to the demand. Figure 6 The rInterface in the ComSer class is also an internal class, and the rInterface class inherits the IExample1 class under the namespace Require.

[0181] Figure 6 The pPort is an internal class in the ComSer class, which inherits the Sampling class under the namespace Publsih. The cPort is also an internal class in the ComSer class, which inherits the Sampling class under the namespace Consume. The specific logic of the DataProcess function in the cPort needs to be designed by the component implementer according to the requirements.

[0182] In addition, the ComSer class is designed to point to the object instance of each internal class. When the component implementer fills in the logic, the external request interface only needs to call the Op1 or Op2 function in the rInterface class, and the external publishing port only needs to assign the port data and then call the Publsih function in the pPort class.

[0183] The build entity is an information entity containing the functions of the component code framework. The business code filled in the component code framework can be called and used in the component entity. After the user fills in the business logic in the corresponding position in the component code framework, the user can directly compile the code framework in VS2010 to generate a component entity dll file. Each component generates a corresponding dll. The component entity contains the specific implementation of the methods in the Provide interface of the user. The specific implementation of the business logic is written by the user. The component entity contains the business logic of processing the results after the request data in the Require interface, the logic of publishing data in the Publish port, and the business processing logic after the Consume accepts data. At the same time, the underlying communication mechanism is encapsulated.

[0184] The component entity is no longer a code framework, but an information entity that can be called. In the windows platform, the build entity is loaded through the dynamic link library. The component entity can be run and the business written by the user in the component code framework can be called.

[0185] In step 101, a test instruction is received, which carries a component description file to be compiled corresponding to a component entity to be tested. Further, the test instruction generally corresponds to two types of port class testing and interface class testing included in the component entity to be tested.

[0186] It should be noted that the generation of the component entity can refer to the above embodiments. Further, the process of generating the intermediate representation of the component description file corresponding to the component entity to be compiled can also refer to the above embodiments, which will not be repeated here.

[0187] But in the component entity testing method, the component entity includes the Require interface, the Provide interface, the Publish port and the Consume port; the intermediate representation includes the Require interface, the Provide interface, the Publish port and the Consume port; the later involved stub component description file also includes the Require interface, the Provide interface, the Publish port and the Consume port. In the introduction of the testing method, in order to avoid the ambiguity caused by the use of the Require interface, the Provide interface, the Publish port and the Consume port, the Require interface, the Provide interface, the Publish port and the Consume port included in the intermediate representation are respectively called the first Require interface, the first Provide interface, the first Publish port and the first Consume port; the Require interface, the Provide interface, the Publish port and the Consume port included in the stub component description file are respectively called the second Require interface, the second Provide interface, the second Publish port and the second Consume port; and the Require interface, the Provide interface, the Publish port and the Consume port included in the component entity are called the third Require interface, the third Provide interface, the third Publish port and the third Consume port.

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

[0189] In step 102, the testing data of the component entity to be tested is generated according to the obtained intermediate representation. It needs to be explained that in the embodiment of the present application, the specific generation method of the testing data is not limited.

[0190] The selection rule of the parameter value in the testing data is as follows:

[0191] When a parameter set (defined as a structure) to be generated contains n components (x_1, x_2,, x_n), a special input test case is considered:

[0192] (max(x_1), max(x_2),, max(x_n))

[0193] For each x_i (0 < i < n+1) and a small offset r > 0, replace max(x_i) with min(x_i)-r and max(x_i)+r in turn, and 2n+1 test cases can be obtained;

[0194] Symmetrically, replace the input test cases

[0195] (min(x_1),min(x_2),,min(x_n))

[0196] 2n+1 test cases can also be obtained;

[0197] Thus, 4n+2 test cases are generated in total. Careful analysis of the 4n+2 test cases shows that all of them take values on or outside the boundary of the parameter set input space; in order to detect the processing of the input space inside, some test inputs need to be added, which are two test points within the input boundary:

[0198] (max(x_1)-r,max(x_2)-r,,max(x_n)-r)

[0199] (min(x_1)+r,min(x_2)+r,,min(x_n)+r)

[0200] Therefore, a total of 4n+4 boundary test points are selected. The number of test points is only related to the dimension of the input parameter set input component, and is independent of the path number, and compared with robust worst-case testing (which requires 7^n test points), the test cost is greatly reduced.

[0201] The boundary test data generated by this method is a proper subset of the robust worst-case test data, which not only embodies the concept of robust testing, but also contains test points outside the worst-case test data set, while taking into account both requirements, and improves the boundary coverage with lower test cost.

[0202] Storage and configuration of test data

[0203] 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 test data occupies a row in the text file and is stored in the form of Json.

[0204] It should be noted that in the embodiment of the present application, after the test data is generated according to the intermediate representation, the test data needs to be stored. In order to facilitate the calling of the test data in the later stage, preferably, the test data is stored in the root directory of the to-be-tested component entity, wherein the test data root directory includes sub-files corresponding to the ports and interfaces included in the to-be-tested construction entity.

[0205] Specifically, the test data root directory at least includes interface sub-files named by interface names; each interface sub-file is divided into an interface type folder according to an interface type name of the interface, and the interface type folder stores test data corresponding to the interface type; further, each third Provide interface included in the to-be-tested component entity respectively corresponds to a P-type interface sub-file included in the test data root directory; and each third Require interface included in the to-be-tested component entity respectively corresponds to an R-type interface sub-file included in the test data root directory.

[0206] It should be noted that the interface sub-files included in the test data are P-type interface sub-files and R-type interface sub-files respectively.

[0207] In step 103, the ports and interfaces included in the intermediate representation are type-converted to obtain a stub component description file of the to-be-tested component entity. Specifically, the N first Require interfaces included in the intermediate representation are all modified into second Provide interfaces to obtain the second Provide interfaces included in the stub component description file; and the N first Publish ports included in the intermediate representation are all modified into second Consume ports to obtain the second Consume ports included in the stub component description file.

[0208] Further, the stub component description file is input into a component entity generation process to obtain a stub program code.

[0209] 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 to-be-tested component entity.

[0210] It should be noted that the test instruction includes port testing and interface testing, and the ports include two and the interfaces also include two, therefore, the test instruction generally includes four cases, which will be introduced below.

[0211] When the test instruction is to test the third Require interface, an R-type interface sub-file corresponding to the third Require interface is read from the component directory, and the R-type interface sub-file includes test data corresponding to the R-type interface type;

[0212] The second Provide interface included in the stub program code is bound to the third Require interface included in the to-be-tested component entity, the second Provide interface reads the test data corresponding to the R-type interface type, and the test data corresponding to the R-type interface type is run to obtain a test result of the third Require interface.

[0213] Specifically, the test platform loads the component entity to be tested into memory, and the third Require interface in the component entity to be tested only maintains an interface pointer. Then the stub program is started, and (since the stub component description file is obtained by modifying the N first Require interfaces included in the intermediate representation into second Provide interfaces, and modifying the N first Publish ports included in the intermediate representation into second Consume ports) the third Require interface of the component entity to be tested is bound to the second Provide interface of the stub component description file, the test platform points the interface pointer maintained by the third Require interface to the implementation body of the second Provide interface, and when the third Require interface is tested, the implementation body of the second Provide interface is called, the second Provide interface reads specific data in the test data file to perform business processing and returns the result to the third Require interface.

[0214] When the test instruction is to test the third Provide interface, the P-type interface sub-file corresponding to the third Provide interface is read from the component directory, and the P-type interface sub-file includes test data corresponding to the P-type interface type; the test data corresponding to the P-type interface sub-file is run to obtain the test result of the third Provide interface. It should be noted that before the P-type interface sub-file corresponding to the third Provide interface is read from the component directory, the processor provides a function P_test, the P_test function obtains the entry pointer of the third Provide interface of the component entity to be tested, the third Provide interface is called through P_test, and the third Provide interface reads the data in the test data file.

[0215] In actual application, since the third Provide interface provides services to the outside, the third Require interface needs to be requested before it is called, but there is no corresponding third requiere interface in the test process, so the driver generates a request function, the request function obtains the entry pointer of the third Provide interface operation, the request function reads the data in the test file and passes it to the third Provide interface, and the data returned by the third Provide interface after processing is recorded.

[0216] When the test instruction is to test the third Publish port, the second Consume port included in the stub program is bound to the third Publish port interface included in the component entity to be tested, and the data sent by the third Publish port is recorded through the second Consume port.

[0217] In the embodiment of the present application, the third Publish port of the component entity to be tested is tested, and the processor needs to simulate a second Consume port data and record the data sent by the third Publish port.

[0218] Since the third Publish port is only responsible for publishing data, it is only necessary to record what data is published by the third Publish port. The intermediate representation has analyzed the data type of the third Publish, and the stub program generates a second Consume port with the same data type as the third Publish to subscribe to the data published by the third Publish port of the component entity to be tested. When the second Consume port receives the data published by the third Publish port, the data is saved in the result file without additional operations.

[0219] When the test instruction is to test the third Consume port, the C-type port sub-file corresponding to the third Consume port is read from the component directory, and the C-type port sub-file includes test data corresponding to the C-type interface type; the second Publish port included in the stub program code is bound to the third Consume port included in the component entity to be tested, and the second Publish port reads the test data corresponding to the C-type interface type and sends the test data corresponding to the C-type interface type to the third Consume port.

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

[0221] Since the third Consume is a second Publish port that subscribes to accept the data published by the second Publish port. The driver generates a port data publishing function to simulate the data publishing of the second Publish port. The intermediate representation obtains the data type of the second Consume port, and the port data publishing function generated by the driver needs to keep the same data type as the third Consume port. Then the port data publishing function reads the data in the test data file and publishes it. The third Consume port will accept the published data and perform its own business logic operation.

[0222] Further, after the testing of the to-be-tested component entity ends, the test result is stored to a test record root directory, in the embodiment of the present application, the test record root directory comprises a P-type port result directory and a P-type interface result directory; wherein the test record root directory is located under a component directory corresponding to the to-be-tested component entity.

[0223] Specifically, the test result comprises a test result record file for testing the interface and a test result record file for testing the port. Wherein, for testing the interface of the to-be-tested component entity, the execution result of the interface function is recorded, the return value after the execution of the interface function and the Out or inout parameter are recorded for the convenience of the user to view. The record file of the port test is generated when the stub receives the data from the third Publish port of the to-be-tested component, the stub records the data in the format of Json with the time stamp.

[0224] Further, the directory organization of the test result record file is extended on the basis of the original directory organization of the user code file, that is, the test record root directory corresponding to the test result is stored under the component directory corresponding to the to-be-tested component entity. The test record root directory is divided into the P-type port result directory and the P-type interface result directory, the former is used for recording the received port data when the stub subscribes to the third Publish port included in the to-be-tested component entity, and the latter is used for recording the execution result of the interface function when the interface of the to-be-tested component entity is driven.

[0225] Based on the same inventive concept, the embodiment of the present application provides a kind of embedded component entity testing device, since the principle that the device solves technical problems is similar to a kind of embedded component entity testing method, therefore the implementation of the device can be referred to the implementation of method, and the repeated place is not repeated.

[0226] As shown in Figure 7 The component entity testing device mainly includes generation unit 701, storage unit 702, obtain single 703 and test unit 704.

[0227] Generation unit 701, for receiving test instruction, the test instruction carries in the to-be-tested component entity corresponding to the to-be-compiled component description file, generates intermediate representation according to the to-be-compiled component description file;Wherein, the test instruction corresponds to interface class test and port class test;

[0228] The storage unit 702 is configured to store the test data of the intermediate representation according to the generation strategy into a test data root directory, and the test data root directory includes sub-files corresponding to ports and interfaces of the to-be-tested component entity, and the test data root directory is located in a component directory corresponding to the to-be-tested component entity.

[0229] The obtaining unit 703 is configured to type convert the ports and interfaces included in the intermediate representation to obtain a stub component description file and a stub program code of the to-be-tested component entity.

[0230] The test unit 704 is configured to execute the test data and the stub program code according to a test instruction to obtain a test result of the to-be-tested component entity.

[0231] Preferably, the storage unit 702 is specifically configured to:

[0232] The test data root directory includes at least interface sub-files named by interface names; each of the interface sub-files is divided into an interface type folder according to an interface type name of the interface, and the interface type folder stores test data corresponding to the interface type; the interface sub-files include P-type interface sub-files and R-type interface sub-files; each third Provide interface included in the to-be-tested component entity corresponds to a P-type interface sub-file included in the test data root directory; and each third Require interface included in the to-be-tested component entity corresponds to an R-type interface sub-file included in the test data root directory.

[0233] The test data root directory includes at least port sub-files named by port names; each of the port sub-files is divided into a port type folder according to a port type name of the port, and the port type folder stores test data corresponding to the port type; the port sub-files include C-type port sub-files; and each Consume port included in the to-be-tested component entity corresponds to a C-type port sub-file included in the test data root directory.

[0234] It should be understood that the units included in the above-mentioned embedded component entity test device are only logical divisions according to the functions implemented by the device, and in actual application, the above-mentioned units can be stacked or split. The functions implemented by the embedded component entity test device provided in the embodiment correspond one-to-one to the functions implemented by the embedded component entity test method provided in the above-mentioned embodiment. For more detailed processing procedures of the device, the above-mentioned method embodiment one has been described in detail, and will not be described in detail here.

[0235] While the preferred embodiments of the application have been described, additional variations and modifications can be made to these embodiments by those skilled in the art once they have the benefit of the present disclosure without departing from the spirit and scope of the application. Accordingly, it is intended that the appended claims include all such modifications and variations as fall within the scope of the present application.

[0236] It is apparent that those skilled in the art can make various changes and modifications to the application without departing from the spirit and scope of the application. It is therefore intended that the present application cover all such changes and modifications that are within its scope.< / int> < / long> < / long> < / x>

Claims

1. A method for testing embedded component entities, characterized in that, include: Upon receiving a test instruction, which carries a component description file to be compiled corresponding to the component entity to be tested, an intermediate representation is generated based on the component description file to be compiled; wherein, the test instruction corresponds to interface class testing and port class testing; The intermediate means that the test data of the component entity to be tested is obtained according to the generation strategy, and the test data is stored in the test data root directory. The sub-files included in the test data root directory correspond to the ports and interfaces of the component entity to be tested. The test data root directory is located in the component directory corresponding to the component entity to be tested. The ports and interfaces included in the intermediate representation are type-converted to obtain the pile component description file and pile program code of the component entity to be tested; According to the test instructions, the test data and the pile program code are executed to obtain the test results of the entity to be tested. The intermediate representation includes ports and interfaces that are type-converted to obtain the pile component description file of the component entity to be tested, specifically including: Modify all N first Require interfaces included in the intermediate representation to second Provide interfaces to obtain the second Provide interfaces included in the pile component description file; Modify all N first Publish ports included in the intermediate representation to second Consume ports to obtain the second Consume ports included in the pile component description file.

2. The test method as described in claim 1, characterized in that, The intermediate representation includes at least one element and basic information for each element, wherein the element includes at least a component, an interface, a port, and an operation; The ports include at least N first Publish ports and N first Consume ports; The interface includes at least N first Provide interfaces and N first Require interfaces; The operation includes N parameters and N return values; Where N is a natural number.

3. The test method as described in claim 1, characterized in that, The step of storing the test data in the test data root directory specifically includes: The test data root directory must include at least the interface sub-files named after the interface. Each of the interface sub-files is divided into an interface type folder according to the interface type name. The interface type folder stores the test data corresponding to the interface type. The interface sub-files include P-type interface sub-files and R-type interface sub-files. Each third Provide interface of the component entity under test corresponds to a P-type interface sub-file included in the test data root directory; each third Require interface of the component entity under test corresponds to an R-type interface sub-file included in the test data root directory.

4. The test method as described in claim 3, characterized in that, The step of executing the test data corresponding to the entity to be tested and the stub program code according to the test instruction to obtain the test result of the entity to be tested specifically includes: When the test instruction is to test the third Require interface, the R-type interface sub-file corresponding to the third Require interface is read from the component directory. The R-type interface sub-file includes test data corresponding to the R-type interface type. The second Provide interface included in the stub program code is bound to the third Require interface included in the component entity to be tested. The second Provide interface reads the test data corresponding to the R-type interface type and runs the test data corresponding to the R-type interface type to obtain the test result of the third Require interface; or When the test instruction is to test the third Provide interface, the P-type interface sub-file corresponding to the third Provide interface is read from the component directory. The P-type interface sub-file includes test data corresponding to the P-type interface type. The test data corresponding to the P-type interface sub-file is run to obtain the test result of the third Provide interface.

5. The test method as described in claim 1, characterized in that, The step of storing the test data in the test data root directory specifically includes: The test data root directory must include at least a port sub-file named after the port name; Each port sub-file is divided into a port type folder according to the port type name, and the port type folder stores the test data corresponding to the port type; wherein, the port sub-file includes a C-type port sub-file; Each Consume port of the entity to be tested corresponds to a C-type port subfile in the root directory of the test data.

6. The test method as described in claim 5, characterized in that, The step of executing the test data corresponding to the entity to be tested and the stub program code according to the test instruction to obtain the test result of the entity to be tested specifically includes: When the test instruction is to test the third Publish port, the second Consume port included in the stub program is bound to the third Publish port interface included in the component entity under test, and the data sent by the third Publish port is recorded through the second Consume port; or When the test instruction is to test the third Consume port, the C-type port sub-file corresponding to the third Consume port is read from the component directory. The C-type port sub-file includes test data corresponding to the C-type interface type. The second Publish port included in the stub program code is bound to the third Consume port included in the component entity to be tested. The second Publish port reads the test data corresponding to the C-type interface type and sends the test data corresponding to the C-type interface type to the third Consume port.

7. The test method as described in claim 1, characterized in that, After obtaining the test results of the entity to be tested, the method further includes: The test results are stored in the test record root directory, which includes a P-type port result directory and a P-type interface result directory; wherein, the test record root directory is located under the component directory corresponding to the component entity to be tested.

8. An embedded component entity testing device, characterized in that, include: A generation unit is configured to receive a test instruction, which carries a component description file to be compiled corresponding to the component entity to be tested, and generate an intermediate representation based on the component description file to be compiled; wherein, the test instruction corresponds to interface class testing and port class testing; The storage unit is used for the intermediate representation to obtain the test data of the component entity to be tested according to the generation strategy, store the test data in the test data root directory, and the sub-files included in the test data root directory correspond to the ports and interfaces of the component entity to be tested, wherein the test data root directory is located in the component directory corresponding to the component entity to be tested; The unit is used to convert the ports and interfaces included in the intermediate representation to obtain the pile component description file and pile program code of the component entity to be tested; The testing unit is used to execute test data and the stub program code according to the test instructions to obtain the test results of the entity to be tested. The obtaining unit is specifically used to: modify all N first Require interfaces included in the intermediate representation to second Provide interfaces, thereby obtaining the second Provide interface included in the pile component description file; and modify all N first Publish ports included in the intermediate representation to second Consume ports, thereby obtaining the second Consume port included in the pile component description file.

9. The testing apparatus as described in claim 8, characterized in that, The storage unit is specifically used for: The test data root directory includes at least interface sub-files named after the interface names; each interface sub-file is divided into an interface type folder according to the interface type name, and the interface type folder stores the test data corresponding to the interface type; wherein, the interface sub-files include P-type interface sub-files and R-type interface sub-files; each third Provide interface included in the component entity to be tested corresponds to a P-type interface sub-file included in the test data root directory; each third Require interface included in the component entity to be tested corresponds to an R-type interface sub-file included in the test data root directory. The test data root directory includes at least port sub-files named after port names; each port sub-file is divided into port type folders according to the port type name, and the port type folders store test data corresponding to the port type; wherein, the port sub-files include C-type port sub-files; each Consume port included in the component entity to be tested corresponds to a C-type port sub-file included in the test data root directory.

Images