A661 widget dynamic parameter verification automation testing method

Abstract

The application provides an A661Widget dynamic parameter verification automatic test method, which comprises the following steps: step 1, defining a normalized input interface file; step 2, defining a normalized output interface file format; step 3, generating a test case information library according to the normalized input interface file; step 4, automatically generating a runtime message file according to the test case information library; step 5, automatically generating a normalized test case file; and step 6, creating a UADF file corresponding to a general test UA according to a high-level requirement of software.

Description

Technical Field

[0001] The field of software development and verification for the A661Server avionics cockpit display system implemented using the ARINC 661 standard interface. Background Technology

[0002] The A661 standard defines the Widget Library, which is used to implement Application Definition File (UADF) design and dynamic interaction between applications (UA) and A661 Widgets.

[0003] The A661 standard defines the following for Widgets:

[0004] 1) Widget parameter definitions include parameter types at definition time ('D'), dynamic parameter types at runtime ('R'), and some parameters belong to both at-definition and runtime parameters ('DR'). Widget parameter definitions cover all Widget property parameters;

[0005] 2) Widget static structure definition: Defines the structure of the Widget when it is created in the UADF file, which is used by A661Server to parse and implement static display;

[0006] 3) Widget runtime message structure definition (unique to interactive Widgets): This defines the structure of all interactive events during the Widget runtime phase, used to enable message communication with the User Agent when events are triggered.

[0007] 4) Widget dynamic parameter definition, including parameter name, type, size, parameter ID, parameter structure. All runtime parameters can be interacted between the UA and the A661 Server through the Set Parameter runtime message.

[0008] Currently, the A661 Server dynamic testing environment and technology can achieve requirement-based dynamic testing of A661 Server (including A661Widget) through simulation test UA and simulation test UADF design, and through the A661 Server testing engine. The testing process mainly includes requirement-based test case design and test case (or test program) execution. The requirement-based test case design process mainly uses software requirements in text form as input. According to test case templates and test case design methods, test engineers manually design each test case, defining test descriptions, test requirements, test steps, etc. The manual design method makes it difficult to guarantee the sufficiency and correctness of test cases, and the workload is large. Due to the lack of automation methods, it results in a large demand for human resources and a long time cycle.

[0009] During the A661 Server testing process, it is necessary to test the validity of dynamic parameters of A661 Widgets, covering all dynamic parameters of all Widgets. Summary of the Invention

[0010] The purpose of this invention is to transform the testing of the Widget dynamic parameter verification requirement in the A661 Server requirement from manual test case design and testing to fully automated testing through automation methods. This eliminates the need for testers to design and execute test cases, avoiding errors introduced during manual test case design and insufficient test case sufficiency, while ensuring software quality, greatly shortening the testing cycle and saving labor costs.

[0011] Technical solution: An automated testing method for dynamic parameter verification of A661 Widget, the method comprising:

[0012] Step 1: Define a standardized input interface file. The input interface file is used to define the information required for automated test case generation, including test case file template, Widget ID, Widget Name, Parameter Type, parameter structure, software requirements under test, exception messages, test type, and test case input related information.

[0013] Step 2: Define a standardized output interface file format. The output interface file is used for A661Server test stimuli. It sends commands through runtime messages and periodically communicates with the A661 Server to send A661 Widget runtime parameter dynamic SetParameter messages. Define a standardized output interface file format according to the A661 standard.

[0014] Step 3: Generate a test case information library based on the standardized input interface file; parse the standardized input interface file, and obtain the information required for all A661 Widget dynamic parameter verification test cases by searching and processing the input interface file, and generate a test case information library;

[0015] Step 4: Automatically generate runtime message files based on the test case information library; these runtime message files convert the input values ​​of specific dynamic parameter verification test cases into the actual A661 runtime messages sent; according to the dynamic parameters and message structure defined in the A661 standard, the dynamic parameter data is encapsulated into complete SetParameter runtime messages through automated means, and a Widget runtime parameter runtime message file is generated according to the standardized output interface file format; this serves as the command parameter for dynamically sending A661 messages in the test cases.

[0016] Step 5: Using the test case file template as input, extract the information required to generate test cases from the test case information library and runtime message file list, and automatically generate standardized test case files based on the customized normal / robust test case template;

[0017] Step 6: Test UADF: Based on the software's high-level requirements, create a UADF file corresponding to a general test UA. A661 adopts a Client-Server model. The test UADF is automatically loaded and parsed on the A661 Server side, and the test UA is simulated on the Client side to realize the interaction between the test UA and the A661 Server. The standardized dynamic parameter verification test case file is loaded and run through the automated testing framework, and the test results are automatically generated, thus fully realizing the automation of A661 Widget dynamic parameter verification testing.

[0018] Specifically, step 1 includes:

[0019] Step 11: Define the A661 Widget data file, and define the DR parameter, R parameter Parameter Name, Parameter Type, and data type of all Widgets according to the A661 standard;

[0020] Step 12: Define the A661 standard constant file. Based on the A661 standard, define the general structure of the A661 standard constant file, including constant definitions for Parameter Type, Boolean type constants, integer constants, Widget extended structures, runtime commands, etc.

[0021] Step 13: Define the WidgetID configuration file, defining the mapping relationship between all A661 Widget data files and Widget IDs;

[0022] Step 14: Define the requirements traceability file. Taking the A661 Widget software requirements as input, identify the Widget dynamic parameter verification software requirements based on different WidgetNames, establish the traceability relationship between Widget Names and high-level requirements of dynamic parameter verification software, and define the requirements traceability file in a standardized XML file format.

[0023] Step 15: Define the test case design file. Classify the dynamic parameters of all Widgets according to the ParameterStructure defined in the A661 standard. For each parameter structure, design normal and robust test cases according to the requirements of DO-178B, and determine the required normal and robust data values ​​for each dynamic parameter. Based on the software requirements and the A661 standard, determine the exception messages returned by the A661 Server after processing the robust test case inputs. Complete the design and definition of test cases for the A661 Widget dynamic runtime parameters according to the test case design structure.

[0024] Step 16: Define a dynamic parameter validation test case file template, including the test case file framework, test case file name, test case description, test requirement traceability, and test steps;

[0025] Step 17: Define the Widget static parameter definition file. Based on the test case design file for normal / robust dynamic parameters, define the settings of relevant static parameters MaxStringLength, MaxFormatStringLength, MaxLegendStringLength, and MaxNumberOfEntries in the Widget during the test UADF design, ensuring that the static parameter values ​​match the test case design. Define the Widget Name, Widget ID, Parameter Name, data type, and static parameter values ​​for all Widgets with the above static parameters according to the A661 standard.

[0026] Specifically, step 2 includes:

[0027] Define a standardized output interface file format to standardize the runtime message file format. The specific format definition is as follows:

[0028]

[0029] Specifically, step 3 includes:

[0030] Iterate through the WidgetID configuration file to get a list of all Widgets, which contains Widget ID, WidgetName, and information about the Widget data file;

[0031] Iterate through each Widget in the Widget list, parse the requirement traceability file, retrieve the requirement traceability file based on the Widget Name keyword, and obtain the dynamic parameter verification requirement corresponding to the Widget.

[0032] Parse the A661 Widget data file, search the Widget data file by keyword, and obtain a list of all dynamic parameter information contained in the Widget, including Parameter Type and data type; traverse the dynamic parameter list, parse the test case design file, and search by Parameter Type keyword to obtain the parameter structure and test case design set corresponding to the parameter.

[0033] Each test case in the test case design set is processed, and the test type of the test case is set according to the test type field. At the same time, based on different parameter structures, random number switch, maximum / minimum value for generating random numbers, etc., the input value of the test case and the corresponding exception message are obtained.

[0034] Specifically, step 4 includes:

[0035] Step 41: For each test case in the test case information database, extract the Parameter Type and test case input value, and use these as keywords to search the constant definition list to obtain the corresponding hexadecimal unique identifier. This hexadecimal value will be used as the command value for the relevant fields in the standardized output interface file. Extract the parameter structure information. For the 18 parameter structures defined in 4.5.4.5 of the A661 standard, define the corresponding output function for each parameter structure. This output function meets the requirements of the standardized output interface file format definition. Define the corresponding command values ​​and line comment information for different fields in different parameter structures to obtain the {A661_ParameterStructure} structure.

[0036] Step 42: Based on Table 4.5.4.2-1 of the A661 standard, expand the {A661_ParameterStructure} structure to obtain the command values ​​and line comment information of the A661_CMD_SET_PARAMETER, Widget ID, Command Size, and UnusedPad fields, thus obtaining the A661 runtime parameter setting command structure information; based on Table 4.5.4.1-1 of the A661 standard, expand the A661 runtime parameter setting command structure information into complete runtime block structure information;

[0037] Step 43: Traverse the test case information database and consult the constant definition list. Encapsulate the input of each test case into a runtime block structure, and save the final output of the runtime block structure as a runtime message file in the output interface file format. By traversing the test case information database, generate runtime message files for all test case inputs one by one.

[0038] Specifically, step 5 includes:

[0039] Step 51: Generate a single test case structure;

[0040] Step 52: Generate a single test case file structure based on the individual test case structure;

[0041] Step 53: Generate a set of test case files based on the structure of a single test case file.

[0042] Step 5 specifically includes:

[0043] Step 51: Define the normal / robust test case template for A661 Widget dynamic parameter validation; the test case template includes test case description, test requirement traceability, and test steps; based on the test case information library, runtime message file, and constant definition list, update the content of the corresponding fields in the normal / robust test case structure template to generate a single test case structure;

[0044] Step 52: Based on the Widget Name, encapsulate the necessary elements to generate all test case structures for all dynamic parameters contained in the Widget, resulting in the test case file information structure; define the dynamic parameter validation test case file structure template based on the dynamic parameter validation test case file template; generate each test case in the test case information set in the test case file information structure one by one according to the method for generating a single test case structure, resulting in all test case structures for the test case file; update the corresponding part of the dynamic parameter validation test case file structure template with the obtained test case file all test case structures, resulting in a single test case file structure;

[0045] Step 53: Traverse the test case information database and generate the test case file structure corresponding to each Widget one by one, finally obtaining a list of all test case file structures; generate the test case file corresponding to each Widget one by one by traversing the list of test case file structures.

[0046] Specifically, step 6 includes:

[0047] The test UADF should support the validation of all dynamic parameters of all Widgets, define UADF design constraints, specify the Layer ID, and ensure that it is consistent with the LayerIdent in the generated runtime message file;

[0048] The Widget in UADF contains all Widget types, and the Widget ID is consistent with the configuration in the WidgetID configuration file;

[0049] The settings for the Widget's static parameters MaxStringLength, MaxFormatStringLength, MaxLegendStringLength, and MaxNumberOfEntries should be consistent with those in the Widget's static parameter definition file.

[0050] In summary, the beneficial effects of the present invention are as follows:

[0051] 1) The automated generation of dynamic parameter runtime message files solves the problem that testers need to be familiar with the specific message structure when designing manually, and that errors may be introduced during the design process, thus saving runtime message design and debugging time;

[0052] 2) By standardizing the naming rules for dynamic parameter runtime message files, the purpose and expected results of normal and robust testing can be understood intuitively. If the test fails, the problem phenomenon can be quickly and intuitively revealed, which helps to quickly locate software problems.

[0053] 3) Using standardized input interface files, runtime message files, and test case templates as input, test case files are automatically generated, completely transforming the original process of manually writing test cases into an automated process, while effectively ensuring correctness and sufficiency.

[0054] 4) This invention fully automates the testing of dynamic parameter verification requirements for A661 Widget. The testing workload that originally required multiple people and months is directly transformed into automatic computer processing and execution, greatly shortening the cycle and reducing labor costs. Attached Figure Description

[0055] Figure 1Generate schematic diagrams for dynamic parameter validation test case files;

[0056] Figure 2 A schematic diagram illustrating the process of generating the test case information database;

[0057] Figure 3 Automatically generate schematics for runtime message files;

[0058] Figure 4 Automatically generate schematic diagrams for test case files. Detailed Implementation

[0059] Example 1

[0060] Based on the current A661 Server dynamic testing technology, this application fully automates the testing of A661 Widget dynamic parameters by sampling and standardizing the definition of Widget dynamic parameters, defining the required categories and expected results for parameter validation test cases of each parameter type, and using these as inputs to generate the Set Parameter runtime message file and corresponding test case file for each parameter. The test cases are then automatically loaded, run, and generate test results.

[0061] This application provides an automated testing method for dynamic parameter verification of the A661 Widget, comprising the following steps:

[0062] Step 1: Standardize the input interface file definition: The input interface file is used to define the information required for the generation of automated test cases, including the test case file template, Widget ID, Widget Name, Parameter Type, parameter structure, software requirements under test, exception messages, test type, and test case input related information.

[0063] The test types include normal and robust.

[0064] Step 2: Standardize the output interface file format definition: The output interface file is used for A661Server test stimuli, sending commands via runtime messages and periodically communicating with the A661 Server to send A661 Widget runtime parameter dynamic SetParameter messages. Based on the A661 standard, and considering file readability and maintainability, a standardized output interface file format is defined.

[0065] Step 3: Test Case Information Base Generation: Parse the standardized input interface file. Through searching and processing the input interface file, obtain the information required for all A661 Widget dynamic parameter validation test cases, and generate a test case information base. The test case information base will serve as the basis for the automatic generation of runtime message files and test case files.

[0066] Step 4: Automatic Generation of Runtime Message Files: The runtime message file, also known as the output interface file, is primarily responsible for converting the input values ​​of specific dynamic parameter validation test cases into the actual A661 runtime messages sent. Based on the dynamic parameters and message structure defined in the A661 standard, the dynamic parameter data is automatically encapsulated into complete Set Parameter runtime messages, and a Widget runtime parameter runtime message file is generated according to the standardized output interface file format. This serves as the command parameter for dynamically sending A661 messages in the test cases.

[0067] Step 5: Automatic generation of test case files: To meet the needs of automated testing, the system takes the test case file template as input, extracts the information required to generate test cases from the test case information library and the runtime message file list, and automatically generates standardized test case files based on the custom normal / robust test case templates.

[0068] Step 6: Test UADF Design: Based on the high-level software requirements, testers create a generic test UADF file corresponding to the test UA. This UADF file supports the verification of all dynamic parameters of all widgets. A661 adopts a Client-Server model. The test UADF is automatically loaded and parsed on the A661 Server side, and the test UA is simulated on the Client side to realize the interaction between the client and the A661 Server. The standardized dynamic parameter verification test case file is loaded and run through the automated testing framework, and the test results are automatically generated, fully realizing the automation of A661 widget dynamic parameter verification testing.

[0069] Specifically, step 1 includes:

[0070] Step 11: Define the A661 Widget data file. Define the Parameter Name, Parameter Type, and data type of the "DR" and "R" parameters of all Widgets according to the A661 standard.

[0071] Step 12: Define the A661 standard constant file. Based on the A661 standard, define the general structure of the A661 standard constant file, mainly including constant definitions for Parameter Type, Boolean type constants, integer constants, Widget extended structures, runtime commands, etc. The constant definition includes the name, data size, and corresponding hexadecimal unique identifier.

[0072] Step 13: Define the WidgetID configuration file, defining the correspondence between all A661 Widget data files and Widget IDs.

[0073] Step 14: Define the requirement traceability file. Taking the A661 Widget software requirement as input, identify the Widget dynamic parameter validation software requirement based on different WidgetNames, establish the traceability relationship between Widget Name and the high-level requirement of dynamic parameter validation software, and define the requirement traceability file in a standardized XML file format.

[0074] Step 15: Define the test case design file. Classify all dynamic parameters of Widgets according to the ParameterStructure defined in the A661 standard. For each parameter structure, design normal and robust test cases according to DO-178B requirements, determining the required normal and robust data values ​​for each dynamic parameter. Based on software requirements and the A661 standard, determine the exception messages returned by the A661 Server after processing the robust test case inputs. Define the test case design file structure, mainly including Parameter Structure, ParameterType, test type (normal or robust), test case input, random number generation switch, maximum / minimum values ​​for generating random numbers, and the exception messages corresponding to robust tests. Complete the A661Widget dynamic runtime parameter test case design definition according to the test case design structure.

[0075] Step 16: Define the dynamic parameter validation test case file template, which mainly includes the test case file framework, test case file name, test case description, test requirement traceability, and test steps. The test case file framework defines the identifiers for each part of the test case and the start and end markers for each part; the test case file name defines the main testing purpose of the test case file; the test case description defines the input conditions and expected results of the test case, with the description field consisting of fixed and variable parts, the variable part derived from the actual test case information; the test requirement traceability defines the dynamic parameter validation requirement number currently being tested; the test steps definition includes a fixed test command description and specific test command parameters, the test command parameters being determined based on the actual dynamic runtime message file and the actual results of the test case.

[0076] Step 17: Define the Widget static parameter definition file. Based on the test case design file for normal / robust dynamic parameters, define the settings for the relevant static parameters MaxStringLength, MaxFormatStringLength, MaxLegendStringLength, and MaxNumberOfEntries in the Widget during the test UADF design, ensuring that the static parameter values ​​match the test case design. Define the Widget Name, Widget ID, Parameter Name, data type, and static parameter values ​​for all Widgets with the above static parameters according to the A661 standard.

[0077] Specifically, step 2 includes:

[0078] The standardized output interface file format definition is used to standardize the runtime message file format. The specific format definition is as follows:

[0079]

[0080]

[0081] For example, the structural format reference style for {A661_ParameterStructure} is as follows:

[0082]

[0083] Each line of the standardized output interface file consists of a command value, a comment identifier "#", and a line comment. The command value field is a hexadecimal value, and the numerical descriptions in the line comments are all decimal values.

[0084] The output interface file is organized into a three-level hierarchical structure according to the A661 standard:

[0085] 1) The outermost layer is the runtime block structure, which is identified by the keywords B0 and D0, 000000 (32-bit aligned). B0 is the start identifier of the runtime block structure, and D0 is the end identifier of the runtime block structure. The runtime block structure contains LayerIdent, Context Number, and Block Size in sequence. Between Block Size and the D0 end identifier is the next outermost A661 runtime parameter setting command structure.

[0086] 2) The outermost layer is the A661 runtime parameter setting command structure, which is identified by the keyword CA02. The command structure contains Command Size, Widget ID, and 0000 (32-bit aligned) in sequence. After 0000 (32-bit aligned) is the innermost A661 dynamic parameter structure.

[0087] 3) The innermost layer is the A661 dynamic parameter structure. This structure mainly contains the dynamic parameter ID, parameter value, and 32-bit alignment. The A661 dynamic parameter structure corresponds to the actual dynamic parameter type. Specifically, it is determined according to the parameter structure of each type defined in section 4.5.4.5 of the A661 standard, based on the A661 Widget dynamic parameter type. Its format and comments are consistent with the standard.

[0088] Specifically, step 3 includes: traversing the WidgetID configuration file to obtain a list of all Widgets, containing Widget ID, Widget Name, and Widget data file information. For each Widget in the list, parse the requirement traceability file, retrieve the requirement traceability file based on the Widget Name keyword, and obtain the dynamic parameter validation requirements corresponding to that Widget; parse the A661 Widget data file, retrieve the Widget data file by keyword, and obtain a list of all dynamic parameter information contained in that Widget, including Parameter Type and data type; traverse the dynamic parameter list, parse the test case design file, retrieve the parameter structure and test case design set corresponding to that parameter by the Parameter Type keyword. For each test case in the test case design set, process it, set the test type (normal / robust) according to the test type field, and obtain the input values ​​and corresponding exception messages of the test case based on different parameter structures, random number switches, maximum / minimum values ​​used to generate random numbers, etc.

[0089] As can be seen, by processing the standardized input interface file, the dynamic parameter validation test case information for each A661 Widget is extracted, ultimately generating a test case information library for all dynamic parameters of all Widgets. Each dynamic parameter validation test case includes Widget ID, Widget Name, Parameter Type, parameter structure, exception message, test type (normal / robust), test case input value, and dynamic parameter validation requirements.

[0090] Specifically, step 4 includes:

[0091] Step 41: For each test case in the test case information database, extract the Parameter Type and test case input value. Using these as keywords, search the constant definition list to obtain the corresponding hexadecimal unique identifier. This hexadecimal value will be used as the command value for the relevant field in the standardized output interface file. Extract the parameter structure information. For the 18 parameter structures defined in section 4.5.4.5 of the A661 standard, define the corresponding output function for each parameter structure. According to the requirements of the standardized output interface file format definition, the output function defines the corresponding command values ​​and line comment information for different fields in different parameter structures, obtaining the {A661_ParameterStructure} structure.

[0092] Step 42: Based on Table 4.5.4.2-1 of the A661 standard, expand the {A661_ParameterStructure} structure to obtain the command values ​​and line comment information for the A661_CMD_SET_PARAMETER, Widget ID, Command Size, and UnusedPad fields, thus obtaining the A661 runtime parameter setting command structure information. Then, based on Table 4.5.4.1-1 of the A661 standard, expand the A661 runtime parameter setting command structure information into complete runtime block structure information.

[0093] Step 43: Traverse the test case information database and consult the constant definition list. Encapsulate the input of each test case into a runtime block structure, and save the final output of the runtime block structure as a runtime message file in the output interface file format. Generate runtime message files for all test case inputs one by one by traversing the test case information database.

[0094] The naming rules for runtime message files are as follows:

[0095] (1) Non-array parameters

[0096] Regular type

[0097] <widgetname>-[Valid / Invalid]- <parametertype>_value

[0098] String

[0099] <widgetname>-[Valid / Invalid]- <parametertype> _ <string> + <padding>WithStringSizeOf <stringsize>

[0100] (2) Array parameters

[0101] Two-element array type

[0102] <widgetname>-[Valid / Invalid]- <parametertype> _ <value1> , <value2>

[0103] StringArray multi-element array type

[0104] <widgetname>-[Valid / Invalid]- <arrayname> _ <arrayitemname> _ <value>

[0105] <widgetname>-[Valid / Invalid]- <arrayname>_StringAndSize_ <string> + <padding>And <stringsize>

[0106] Multi-element array types: EnabelArray / PictureArray / 1ByteArray / 2ByteArray

[0107] <widgetname>-[Valid / Invalid]- <arrayname> _ <arrayitemname> _ <value>

[0108] <widgetname>-[Valid / Invalid]- <arrayname>_ParameterValue_ <value>

[0109] EntryPopUpArray / EntryListArray multi-element array type

[0110] <widgetname>-[Valid / Invalid]- <arrayname> _ <arrayitemname> _ <value>

[0111] <widgetname>-[Valid / Invalid]- <arrayname> _ <cellitemname> _ <value>.

[0112] It should be noted that the A661 standard constant file is parsed according to its file structure to obtain a list of all constant definitions. Based on this list of constant definitions and the test case information database, runtime message files can be automatically generated.

[0113] Specifically, step 5 includes:

[0114] Step 51: Generating a Single Test Case Structure

[0115] Define a normal / robust test case template for A661 Widget dynamic parameter validation. The test case template includes a test case description, test requirement traceability, and test steps. The test steps for a normal test case are: clear the exception message cache, send the runtime message file to the A661 Server, receive messages from the A661 Server, and check if the exception message cache is empty. The test steps for a robust test case are: clear the exception message cache, send the runtime message file to the A661 Server, receive exception messages from the A661 Server and store them in the exception message cache, and check if the received exception messages match the expected exception messages.

[0116] Based on a test case information library, runtime message files, and a constant definition list, test case structures are automatically generated. Test type information is extracted from each test case in the test case information library, and normal / robust test case structure templates are defined according to normal / robust test case templates. Parameter Type, Widget Name, and test case input value information are extracted from the test cases in the test case information library, and variable fields in the test case description are updated. Combined with fixed field descriptions, a complete test case description is obtained. For robust test cases, exception message information is also extracted to obtain a complete robust test case description. Dynamic parameter validation requirement information is extracted from the test cases in the test case information library to obtain test requirement traceability. The runtime message file name corresponding to the test case is obtained to obtain the test command parameters for the A661Server test stimulus steps. For robust test cases, Widget ID information is also extracted from the test cases in the test case information library, and combined with the previously obtained Parameter Type and exception message information, the test command parameters for the A661Server test expectation steps are obtained.

[0117] Using the test case description, test requirement traceability, test command parameters for test stimulus steps, and test command parameters for test expectation steps described above, update the content of the corresponding fields in the normal / robust test case structure template to generate a single test case structure.

[0118] Step 52: Generating the structure of a single test case file

[0119] Based on the Widget Name, the necessary elements are encapsulated to generate the test case file information structure for all dynamic parameters contained in the Widget. This encapsulated information includes the Widget Name, a set of test case information, and a list of A661 Block message file names. The test case information set is a subset of the test case information repository, containing all test case information for the Widget. The A661 Block message file name list is a list of runtime message file names that correspond one-to-one with the set of test case information. One test case file information structure corresponds to one test case file.

[0120] The naming rules for test case files are as follows:

[0121] A661WL_ <widgetname>RTParamValid_HLR

[0122] Based on the dynamic parameter validation test case file template, a dynamic parameter validation test case file structure template is defined. The test case file name information is updated according to the test case file naming rules. Simultaneously, each test case in the test case information set within the test case file information structure is generated one by one according to the method for generating individual test case structures, resulting in the structure of all test cases in the test case file. The corresponding parts of the dynamic parameter validation test case file structure template are then updated using the obtained test case structures to obtain the structure of a single test case file.

[0123] Step 53: Generating the Test Case File Collection

[0124] The test case information database is traversed, and the test case file structure for each widget is generated one by one, ultimately resulting in a list of all test case file structures. This process is repeated to generate the corresponding test case file for each widget.

[0125] Specifically, step 6 includes: testing that the UADF supports validation of all dynamic parameters for all Widgets, defining UADF design constraints, specifying the Layer ID, and ensuring consistency with the LayerIdent in the generated runtime message file. The Widgets in the UADF should contain all Widget types, and the Widget IDs should match the configuration in the WidgetID configuration file. When designing related Widgets in the UADF, it should be ensured that testing a certain dynamic parameter does not affect the expected results of other related parameters. The settings of the Widget static parameters MaxStringLength, MaxFormatStringLength, MaxLegendStringLength, and MaxNumberOfEntries should be consistent with the settings in the Widget static parameter definition file.

[0126] In summary, the beneficial effects of the present invention are as follows:

[0127] 1) The automated generation of dynamic parameter runtime message files solves the problem that testers need to be familiar with the specific message structure when designing manually, and that errors may be introduced during the design process, thus saving runtime message design and debugging time;

[0128] 2) By standardizing the naming rules for dynamic parameter runtime message files, the purpose and expected results of normal and robust testing can be understood intuitively. If the test fails, the problem phenomenon can be quickly and intuitively revealed, which helps to quickly locate software problems.

[0129] 3) Using standardized input interface files, runtime message files, and test case templates as input, test case files are automatically generated, completely transforming the original process of manually writing test cases into an automated process, while effectively ensuring correctness and sufficiency.

[0130] 4) This invention fully automates the testing of dynamic parameter verification requirements for A661 Widget. The testing workload that originally required multiple people and months is directly transformed into automatic computer processing and execution, greatly shortening the cycle and reducing labor costs.

[0131] Example 2

[0132] To better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0133] Step 1: Standardize the input interface file definition

[0134] Define the A661 Widget data file, A661 standard constant file, WidgetID configuration file, requirements traceability file, test case design file, and A661 Widget static parameter definition file in XML format; define the dynamic parameter validation test case file template in XLSX format. The usage process of the input interface file is as follows: Figure 1 As shown, the specific implementation is as follows:

[0135] Step 11: The A661 Widget data file is defined as follows:

[0136]

[0137]

[0138] Step 12: The A661 standard constant file is defined as follows:

[0139] <consts>

[0140] <!--Comment-->

[0141] <const name="ConstName"size="n">0xXXYY…

[0142] < / consts>

[0143] Step 13: The Widget ID configuration file is defined as follows:

[0144]

[0145] Step 14: The requirements traceability document is defined as follows:

[0146]

[0147] Step 15: The test case design file is defined as follows:

[0148]

[0149] Step 16: The dynamic parameter verification test case file template is an Excel file, and the Excel template is defined as follows:

[0150] Test case file start marker:

[0151] START OF ALL TESTS

[0152] Test case file end marker:

[0153] END OF ALL TESTS

[0154] Test case start identifier:

[0155] START OF TEST CASE

[0156] Test case end marker:

[0157] END OF TEST CASE

[0158] The normal test case definition for A661 Widget dynamic parameter validation is as follows:

[0159] Test case description:

[0160] The A661 Server doesn't send an A661_NOTIFY_EXCEPTION event when theDR / R parameter[Parameter Type]of[Widget Name]is set to valid value[Test case input value]

[0161] Test requirement traceability:

[0162] [Dynamic parameter validation requirement]

[0163] Test steps:

[0164] 1.RESET_BUFFER Exception.A661_ExceptionType

[0165] 2.RESET_BUFFER Exception.OEM.A661_ExceptionReason

[0166] 3.RESET_BUFFER Exception.OEM.WidgetIdent

[0167] 4.RESET_BUFFERException.OEM.ParamIdent

[0168] 5. SEND_HEXA_OPAQUE_FROM_FILE

[0169] RuntimeMessage.A661_Message_Block[Runtime message file name]

[0170] 6.WAIT 2

[0171] 7.CHECK_BUFFER Exception.A661_ExceptionTypeNULL

[0172] 8.CHECK_BUFFER Exception.OEM.A661_ExceptionReason NULL

[0173] 9.CHECK_BUFFER Exception.OEM.WidgetIdent NULL

[0174] 10.CHECK_BUFFER Exception.OEM.ParamIdent NULL

[0175] The robust test cases for dynamic parameter validation of A661 Widget are defined as follows:

[0176] Test case description:

[0177] The A661 Server sends an A661_NOTIFY_EXCEPTION event when the DR / R parameter [Parameter Type] of [Widget Name] is set to an invalid value [Test Case Input Value].

[0178] Test requirement traceability:

[0179] [Dynamic parameter validation requirement]

[0180] Test steps:

[0181] 1.RESET_BUFFER Exception.A661_ExceptionType

[0182] 2.RESET_BUFFER Exception.OEM.A661_ExceptionReason

[0183] 3.RESET_BUFFER Exception.OEM.WidgetIdent

[0184] 4.RESET_BUFFERException.OEM.ParamIdent

[0185] 5. SEND_HEXA_OPAQUE_FROM_FILERuntimeMessage.A661_Message_Block[Runtime message file name]

[0186] 6.WAIT 2

[0187] 7.CHECK Exception.A661_ExceptionType EQUALS A661_ERR_SET_ABORTED

[0188] 8. CHECK Exception.OEM.A661_ExceptionReason EQUALS [Exception Message]

[0189] 9.CHECK Exception.OEM.WidgetIdent EQUALS[Widget ID]

[0190] 10. CHECK Exception.OEM.ParamIdent EQUALS [Parameter Type: Hexadecimal identifier]

[0191] Step 17: The Widget static parameter definition file is defined as follows:

[0192]

[0193]

[0194] Step 2: Standardize the output interface file format definition

[0195] The standardized output interface file format definition is described in step 2 of Example 1.

[0196] Step 3: Generation of Test Case Information Base

[0197] A test case information database is obtained by parsing and processing the A661 Widget data file, WidgetID configuration file, requirement traceability file, and test case design file. The specific implementation process is as follows: Figure 2 As shown.

[0198] The data structure corresponding to the test case information database is as follows:

[0199]

[0200]

[0201] Step 4: Automatic generation of runtime message files

[0202] The test case information database is traversed to generate runtime message files corresponding to the test case input values. Runtime message file generation includes A661 dynamic parameter structure encapsulation, A661 runtime parameter setting command structure encapsulation, runtime block structure encapsulation, runtime message file generation, and batch runtime message file generation. The specific implementation process is as follows: Figure 3 As shown.

[0203] The following is an example of naming runtime message files for non-array parameters:

[0204] Regular type:

[0205] Label-Valid-A661_FONT_1

[0206] Label-InValid-A661_FONT_255

[0207] String:

[0208] Label-InValid-A661_STRING_ax31+Nullx1WithStringSizeOf16

[0209] Label-Valid-A661_STRING_ax12+Nullx4WithStringSizeOf13

[0210] Here is an example of how to name the runtime message file for array parameters:

[0211] Two-element array type:

[0212] BasicContainer-Valid-A661_POS_XY_0,0

[0213] StringArray is a multi-element array type.

[0214] ScrollList-Valid-A661_STRING_ARRAY_NumberOfStrings_16

[0215] ScrollList-Valid-A661_STRING_ARRAY_StringAndSize_ax12+Nullx4And13

[0216] Multi-element array types: EnabelArray / PictureArray / 1ByteArray / 2ByteArray

[0217] PopUpMenu-InValid-A661_ENABLE_ENTRY_ARRAY_NumberOfEntries_32768

[0218] PopUpMenu-InValid-A661_ENABLE_ENTRY_ARRAY_ParameterValue_171

[0219] EntryPopUpArray / EntryListArray multi-element array type

[0220] ScrollList-Valid-A661_ENTRY_ARRAY_NumberOfEntries_16

[0221] PopUpMenu-Valid-A661_ENTRY_POP_UP_ARRAY_Picture_108

[0222] Taking the A661_VISIBLE parameter of the Label control as an example, when A661_VISIBLE is set to 2 and the Label's WidgetID is 45, the corresponding output interface file, i.e., the runtime message file, is as follows:

[0223]

[0224]

[0225] The runtime message file is saved as a .hexa file in text format.

[0226] Step 5: Automatic generation of test case files

[0227] Based on the dynamic parameter validation test case file template, the data storage structure for dynamic parameter validation test case files and the data storage structure for normal / robust test cases are defined. Test case files are automatically generated based on the test case information library, runtime message files, and constant definition lists. Automated test case file generation includes three stages: single test case structure generation, single test case file structure generation, and batch test case file generation. The specific implementation process is as follows... Figure 4 As shown.

[0228] Taking the Label control's A661_VISIBLE parameter as an example, the normal test case for A661_VISIBLE being set to FALSE is as follows:

[0229] Test case description:

[0230] The A661 Server doesn't send an A661_NOTIFY_EXCEPTION event when theDR / R parameter A661_VISIBLE of Label is set to valid value FALSE

[0231] Test requirement traceability:

[0232] A661WL_HLR_2027

[0233] Test steps:

[0234] 1.RESET_BUFFER Exception.A661_ExceptionType

[0235] 2.RESET_BUFFER Exception.OEM.A661_ExceptionReason

[0236] 3.RESET_BUFFER Exception.OEM.WidgetIdent

[0237] 4.RESET_BUFFERException.OEM.ParamIdent

[0238] 5. SEND_HEXA_OPAQUE_FROM_FILE

[0239] RuntimeMessage.A661_Message_Block

[0240] Label-Valid-A661_VISIBLE_A661_FALSE.hexa

[0241] 6.WAIT 2

[0242] 7.CHECK_BUFFER Exception.A661_ExceptionTypeNULL

[0243] 8.CHECK_BUFFER Exception.OEM.A661_ExceptionReason NULL

[0244] 9.CHECK_BUFFER Exception.OEM.WidgetIdent NULL

[0245] 10.CHECK_BUFFER Exception.OEM.ParamIdent NULL

[0246] The robust test cases with A661_VISIBLE set to 2 are as follows:

[0247] Test case description:

[0248] The A661 Server sends an A661_NOTIFY_EXCEPTION(OEM_ERR_INVALID_PARAMETER_VALUE)event when the DR / R parameter A661_VISIBLE of Label is set toinvalid value 2

[0249] Test requirement traceability:

[0250] A661WL_HLR_2027

[0251] Test steps:

[0252] 1.RESET_BUFFER Exception.A661_ExceptionType

[0253] 2.RESET_BUFFER Exception.OEM.A661_ExceptionReason

[0254] 3.RESET_BUFFER Exception.OEM.WidgetIdent

[0255] 4.RESET_BUFFERException.OEM.ParamIdent

[0256] 5. SEND_HEXA_OPAQUE_FROM_FILE

[0257] RuntimeMessage.A661_Message_Block

[0258] Label-InValid-A661_VISIBLE_2.hexa

[0259] 6.WAIT 2

[0260] 7.CHECK Exception.A661_ExceptionType EQUALS

[0261] A661_ERR_SET_ABORTED

[0262] 8.CHECK Exception.OEM.A661_ExceptionReason EQUALS OEM_ERR_INVALID_PARAMETER_VALUE

[0263] 9.CHECK Exception.OEM.WidgetIdent EQUALS 0x2D

[0264] 10.CHECK Exception.OEM.ParamIdent EQUALS 0xB530

[0265] Step 6: Test the UADF design

[0266] Create a test UA DF file using SCADE UA Page Creator, setting the Layer ID to 81. When creating the UA DF, all widgets should be drawn, and the page layout and parent-child relationships of the widgets should be consistent with the higher-level software requirements. Set the Widget ID for each widget, ensuring the value matches the WidgetID configuration file. Set the static parameters for each widget; the settings of static parameters should not affect the expected results of test cases for dynamic parameters.

[0267] Taking Label as an example, the corresponding information in the WidgetID configuration file is as follows:

[0268]

[0269]

[0270] Therefore, when testing the UADF design, the WidgetIdent property of the Label control was set to 45, and the MaxStringLength property was set to 32.< / widgetname> < / value> < / cellitemname> < / arrayname> < / widgetname> < / value> < / arrayitemname> < / arrayname> < / widgetname> < / value> < / arrayname> < / widgetname> < / value> < / arrayitemname> < / arrayname> < / widgetname> < / stringsize> < / padding> < / string> < / arrayname> < / widgetname> < / value> < / arrayitemname> < / arrayname> < / widgetname> < / value1> < / parametertype> < / widgetname> < / stringsize> < / padding> < / string> < / parametertype> < / widgetname> < / parametertype> < / widgetname>

Claims

1. An automated testing method for dynamic parameter verification of A661 Widget, characterized in that, The method includes: Step 1: Define a standardized input interface file. The input interface file is used to define the information required for generating automated test cases. Step 2: Define a standardized output interface file format. The output interface file is used for A661Server test stimuli. It sends commands through runtime messages and periodically communicates with the A661 Server to send A661 Widget runtime parameter dynamic SetParameter messages. Define a standardized output interface file format according to the A661 standard. Step 3: Generate a test case information library based on the standardized input interface file; parse the standardized input interface file, and obtain the information required for all A661 Widget dynamic parameter verification test cases by searching and processing the input interface file, and generate a test case information library; Step 4: Automatically generate runtime message files based on the test case information library; according to the dynamic parameters and message structure defined in the A661 standard, encapsulate the dynamic parameter data into complete Set Parameter runtime messages through automated means, and generate Widget runtime parameter runtime message files in accordance with the standardized output interface file format, which serve as the command parameters for dynamically sending A661 messages in the test cases; Step 5: Using the test case file template as input, extract the information needed to generate test cases from the test case information library and runtime message file list, and automatically generate standardized test case files based on the custom normal / robust test case template; Step 6: Based on the high-level requirements of the software, create a UADF file corresponding to the general test UA. A661 adopts the Client-Server mode. The test UADF is automatically loaded and parsed on the A661 Server side. On the Client side, the test UA is simulated to realize the interaction between the test UA and the A661 Server. The standardized dynamic parameter verification test case file is loaded and run through the automated testing framework, and the test results are automatically generated.

2. The method according to claim 1, characterized in that, The information required for automated test case generation includes test case file template, Widget ID, Widget Name, Parameter Type, parameter structure, software requirements under test, exception messages, test type, and test case input information.

3. The method according to claim 2, characterized in that, Step 1 includes: Step 11: Define the A661 Widget data file, and define the DR parameter, R parameter Parameter Name, Parameter Type, and data type of all Widgets according to the A661 standard; Step 12: Define the A661 standard constant file. Based on the A661 standard, define the general structure of the A661 standard constant file, including Parameter Type, Boolean type constants, integer constants, Widget extended structure, and constant definitions of runtime commands. Step 13: Define the WidgetID configuration file, defining the mapping relationship between all A661 Widget data files and Widget IDs; Step 14: Define the requirements traceability file. Taking the A661 Widget software requirements as input, identify the Widget dynamic parameter verification software requirements based on different WidgetNames, establish the traceability relationship between Widget Names and high-level requirements of dynamic parameter verification software, and define the requirements traceability file in a standardized XML file format. Step 15: Define the test case design file. Classify the dynamic parameters of all Widgets according to the parameter structure defined in the A661 standard. For each parameter structure, design normal and robust test cases according to the requirements of DO-178B, and determine the required normal and robust data values ​​for each dynamic parameter. Based on the software requirements and the A661 standard, determine the exception messages returned by the A661 Server after processing the robust test case inputs. Complete the design and definition of test cases for the A661 Widget dynamic runtime parameters according to the test case design structure. Step 16: Define a dynamic parameter validation test case file template, including the test case file framework, test case file name, test case description, test requirement traceability, and test steps; Step 17: Define the Widget static parameter definition file. Based on the test case design file for normal / robust dynamic parameters, define the settings of relevant static parameters MaxStringLength, MaxFormatStringLength, MaxLegendStringLength, and MaxNumberOfEntries in the Widget during the test UADF design, ensuring that the static parameter values ​​match the test case design. Define the Widget Name, Widget ID, Parameter Name, data type, and static parameter values ​​for all Widgets with the above static parameters according to the A661 standard.

4. The method according to claim 1, characterized in that, Step 3 includes: Iterate through the WidgetID configuration file to get a list of all Widgets, which includes Widget ID, Widget Name, and information about the Widget data file; Iterate through each Widget in the Widget list, parse the requirement traceability file, retrieve the requirement traceability file based on the Widget Name keyword, and obtain the dynamic parameter verification requirement corresponding to the Widget. Parse the A661 Widget data file, search the Widget data file by keyword, and obtain a list of all dynamic parameter information contained in the Widget, including ParameterType and data type; traverse the dynamic parameter list, parse the test case design file, and search by ParameterType keyword to obtain the parameter structure and test case design set corresponding to the parameter. For each test case in the test case design set, the test type of the test case is set according to the test type field. At the same time, based on different parameter structures, random number switch, and information on the maximum / minimum value of the random number generated, the input value of the test case and the corresponding exception message are obtained.

5. The method according to claim 1, characterized in that, Step 4 includes: Step 41: For each test case in the test case information database, extract the Parameter Type and test case input value, and use these as keywords to search the constant definition list to obtain the corresponding hexadecimal unique identifier. This hexadecimal value will be used as the command value of the relevant field in the standardized output interface file. Extract the parameter structure information. For the 18 parameter structures defined in 4.5.4.5 of the A661 standard, define the corresponding output function for each parameter structure. According to the requirements of the standardized output interface file format definition, the output function defines the corresponding command value and line comment information for different fields in different parameter structures to obtain the {A661_ParameterStructure} structure. Step 42: Based on Table 4.5.4.2-1 of the A661 standard, expand the {A661_ParameterStructure} structure to obtain the command values ​​and line comment information of the A661_CMD_SET_PARAMETER, Widget ID, Command Size, and UnusedPad fields, thus obtaining the A661 runtime parameter setting command structure information; based on Table 4.5.4.1-1 of the A661 standard, expand the A661 runtime parameter setting command structure information into complete runtime block structure information; Step 43: Traverse the test case information database and consult the constant definition list. Encapsulate the input of each test case into a runtime block structure, and save the final output of the runtime block structure as a runtime message file in the output interface file format. By traversing the test case information database, generate runtime message files for all test case inputs one by one.

6. The method according to claim 1, characterized in that, Step 5 includes: Step 51: Generate a single test case structure; Step 52: Generate a single test case file structure based on the individual test case structure; Step 53: Generate a set of test case files based on the structure of a single test case file.

7. The method according to claim 6, characterized in that, Step 5 specifically includes: Step 51: Define the normal / robust test case template for A661 Widget dynamic parameter validation; the test case template includes test case description, test requirement traceability, and test steps; based on the test case information library and runtime message file list, update the content of the corresponding fields in the normal / robust test case structure template to generate a single test case structure; Step 52: Based on the Widget Name, encapsulate the necessary elements to generate all test case structures for all dynamic parameters contained in the Widget, resulting in the test case file information structure; define the dynamic parameter validation test case file structure template based on the dynamic parameter validation test case file template; generate each test case in the test case information set in the test case file information structure one by one according to the method for generating a single test case structure, resulting in all test case structures for the test case file; update the corresponding part of the dynamic parameter validation test case file structure template with the obtained test case file all test case structures, resulting in a single test case file structure; Step 53: Traverse the test case information database and generate the test case file structure corresponding to each Widget one by one, finally obtaining a list of all test case file structures; generate the test case file corresponding to each Widget one by one by traversing the list of test case file structures.

8. The method according to claim 1, characterized in that, Step 6 includes: The test UADF should support the validation of all dynamic parameters of all Widgets, define UADF design constraints, specify LayerID, and ensure consistency with LayerIdent in the generated runtime message file; The Widget in UADF contains all Widget types, and the Widget ID is consistent with the configuration in the WidgetID configuration file; The settings for the Widget's static parameters MaxStringLength, MaxFormatStringLength, MaxLegendStringLength, and MaxNumberOfEntries should be consistent with those in the Widget's static parameter definition file.

Images