Platformized test method, device, electronic equipment, medium and program product

Abstract

The application discloses a platformized test method and device, electronic equipment, medium and program product, and belongs to the technical field of hardware testing. The method comprises the following steps: configuring test parameters of a tested module, and saving the test parameters in extensible markup language format data; analyzing the extensible markup language format data, and converting test information in the extensible markup language format data into dictionary form data; traversing the dictionary form data, and determining a test parameter list of the tested module; and executing a test case according to the test parameter list, so as to realize the test of the tested module. The tested module in different projects can be converted into the test parameter list in the foregoing manner. When testing, the test case is executed according to the test parameter list, and it is not necessary to manually modify test case parameters. The same module in different projects can be tested by using the same test case, and the platformization of the test case is realized.

Description

Technical Field

[0001] This application relates to the field of hardware testing technology, and more specifically to a platform-based testing method, apparatus, electronic device, medium, and program product. Background Technology

[0002] The Automotive Open System Architecture (AUTOSAR) defines the software architecture for the controller. This software architecture separates the hardware and software of the device, puts the functional model software and software components together, and develops them independently by different manufacturers. Then, they are combined into a specific project through some automated configuration process.

[0003] Similar to other software and hardware development, each part of AUTOSAR requires testing after development. In existing AUTOSAR testing solutions, many test cases involving CAN communication have fixed parameters. If a new project needs to be adapted or configuration files modified, the parameters of the corresponding test cases need to be modified in batches. In today's era of big data, the amount of data is enormous, making manual modification of test case parameters impractical. Even if modification were possible, it would be time-consuming and laborious, and there is a high risk of missing or incorrectly modifying parameters. Summary of the Invention

[0004] The purpose of this application is to provide a platform-based testing method, device, electronic device, medium, and program product to solve the problem that the test case parameters are fixed in the existing CAN communication testing scheme, and the test cases need to be manually updated every time a new project is adapted.

[0005] To achieve the above objectives, the first aspect of this application provides a platform-based testing method, which includes:

[0006] Configure the test parameters of the module under test and save them as Extensible Markup Language (EXPLAIN) format data;

[0007] Parse the Extensible Markup Language (XML) format data and convert the test information in the XML format data into dictionary-style data;

[0008] Traverse the dictionary-style data to determine the list of test parameters for the module under test;

[0009] Test cases are executed according to the test parameter list to achieve the testing of the module under test.

[0010] In some feasible embodiments, configuring the test parameters of the module under test and saving them as Extensible Markup Language (XML) format data includes:

[0011] Import the CAN network database file and the driver file in Extensible Markup Language format of the module under test into the configuration interface;

[0012] Identify test parameter items in CAN network database files and driver files in Extensible Markup Language format;

[0013] Adjust the configuration of the test parameters and save them as Extensible Markup Language (XML) data.

[0014] In some feasible embodiments, parsing the Extensible Markup Language (XML) format data and converting the test information in the XML format data into dictionary-like data includes:

[0015] Traverse the Extensible Markup Language (XML) formatted data to obtain key fields;

[0016] Obtain the test parameters contained in the key field based on the key field;

[0017] The key fields and the test parameters are converted into dictionary data, which contains the test parameters of the module under test.

[0018] In some feasible embodiments, converting the key fields and the test parameters into dictionary-like data includes:

[0019] Use the key fields as keys in dictionary-style data;

[0020] The test parameters corresponding to the key fields are used as the values ​​of the corresponding keys to generate dictionary-style data.

[0021] In some feasible embodiments, the step of traversing dictionary-style data to determine the test parameter list of the module under test includes:

[0022] Determine the dictionary type based on the module being tested;

[0023] The test parameter list of the module under test is obtained from the dictionary-formatted data according to the dictionary type.

[0024] In some feasible embodiments, executing test cases according to the test parameter list includes:

[0025] Based on the global variables in the test case, retrieve the corresponding values ​​of the global variables from the test parameter list to execute the test case;

[0026] Alternatively, based on the function in the test case, obtain the corresponding input parameters of the function from the test parameter list to execute the test case.

[0027] In some feasible embodiments, the testing method further includes:

[0028] Collect message data after test cases are executed;

[0029] Determine whether the message data matches the expected execution of the test case.

[0030] A second aspect of this application provides a platform-based testing apparatus, the platform-based testing apparatus comprising:

[0031] The parameter configuration unit is used to configure the test parameters of the module under test and save them as Extensible Markup Language (EXPLAIN) format data.

[0032] The conversion unit is used to parse the Extensible Markup Language (XML) format data and convert the test information in the XML format data into dictionary-style data.

[0033] The list determination unit is used to traverse dictionary-style data to determine the list of test parameters for the module under test.

[0034] An execution unit is used to execute test cases according to the test parameter list in order to verify the test cases.

[0035] A third aspect of this application provides an electronic device, comprising:

[0036] The memory is configured to store instructions; and

[0037] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the platform-based testing method.

[0038] A fourth aspect of this application provides a machine-readable storage medium storing instructions that cause a machine to execute the platform-based testing method described above.

[0039] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the platform-based testing method.

[0040] Through the above technical solution, the testing method of this application stores the adjusted test parameters of each module under test in the project as Extensible Markup Language (XML) format data. By parsing the XML format data, the test information for testing each module can be converted into a more concise and intuitive dictionary-style data. Then, the test parameter list of the module under test is determined from the dictionary-style data. The test parameter list only contains the test information of the module under test. Modules under test in different projects can all be converted into test parameter lists using the aforementioned method. During testing, test cases are executed according to the test parameter list without the need for manual modification of test case parameters. The same module in different projects can be tested using the same test cases, achieving test case platformization. When a new project adaptation occurs, the test cases of the corresponding module can be automatically adapted according to the determined test parameter list, without the need for manual adjustment of test parameters. This method can automatically parse XML format data, which is convenient, fast, and easy to use.

[0041] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0042] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0043] Figure 1 The illustration shows a flowchart of a platform-based testing method according to an embodiment of this application;

[0044] Figure 2 This illustration schematically depicts a platform-based testing method for parsing Extensible Markup Language (XML) format data flow according to an embodiment of this application.

[0045] Figure 3 This illustration schematically shows a message test case execution diagram for one test transmission direction according to an embodiment of this application;

[0046] Figure 4 This illustration schematically shows a message test case execution diagram for one test receiving direction according to an embodiment of this application;

[0047] Figure 5 This illustration schematically shows a platform-based testing method step diagram according to an embodiment of this application;

[0048] Figure 6 This schematic diagram illustrates a structural block diagram of a platform-based testing apparatus according to an embodiment of this application;

[0049] Figure 7The diagram illustrates a complete technical flowchart of a testing method according to an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0051] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0052] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0053] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0054] Figure 1 The illustration schematically shows a flowchart of a platform-based testing method according to an embodiment of this application. For example... Figure 1 As shown, this method can be applied to terminal devices, such as PDAs, tablets, laptops, and all-in-one computers. It is understood that the dialogue method provided in this disclosure can also be applied to other scenarios.

[0055] In the embodiments of this application, "engineering" refers to software based on a hardware chip. Different hardware chips correspond to different engineering projects, such as engineering projects based on ARM chips. The module under test is the corresponding functional module in the engineering project. The platform-based testing method of this application mainly realizes the adaptation of test cases for different engineering projects.

[0056] This application provides a platform-based testing method, which includes:

[0057] S1: Configure the test parameters of the module under test and save them as Extensible Markup Language (XML) format data. In some feasible embodiments, configuring the test parameters of the module under test and saving them as XML format data includes:

[0058] Import the CAN network database file and Extensible Markup Language (ARXML) driver file of the module under test into the configuration interface. File import requires user intervention. In some feasible embodiments, the user can select the corresponding project on the configuration interface, then determine the module under test from the modules included in the corresponding project, and then select the CAN network database file (DBC) and Extensible Markup Language (ARXML) driver file of the module under test for import.

[0059] The CAN network database file defines the CAN network nodes, messages, and signals, as well as which messages each node sends and receives, the signals contained in each message, and the location of the signals. The DBC file can contain information about the nodes participating in CAN communication within a specific vehicle network, such as the number of nodes, which messages each node sends and receives, and information that nodes can exchange (e.g., vehicle speed, steering wheel angle), as well as the conversion relationship between the raw and physical values ​​of these signals. For software development engineers, the DBC file can serve as an input configuration file for developing CAN node communication, diagnostics, and calibration functions; for test engineers, the DBC file can serve as a configuration parsing file to assist in parsing message signals.

[0060] ARXML is an XML (Extensible Markup Language) file format in the AUTOSAR standard, used to describe the software architecture and configuration information of automotive electronic software systems. It is a general configuration / database file. ARXML files contain system information such as definitions of various AUTOSAR software components, interface definitions, module definitions, configuration data, and metadata.

[0061] The driver is used to implement the conversion between binary code streams and differential signals of CAN protocol messages, and the driver file is a file containing the driver implementation program.

[0062] In this embodiment of the application, the configuration interface is the user interface of the configuration tool. The configuration tool can interpret and graphically display the tested module and test parameters contained in the CAN network database file and the driver file in Extensible Markup Language format, so that the user can modify the configuration on the configuration interface.

[0063] The system identifies test parameter items in the CAN network database file and the driver file in Extensible Markup Language (XML) format. These test parameter items are the input parameters during the test process and can be adjusted according to different test requirements. The identified test parameter items can be displayed on the configuration interface.

[0064] Adjust the configuration of the test parameters and save them as Extensible Markup Language (XML) data. In some feasible embodiments, users can adjust the configuration of test parameters by entering their values ​​in the configuration interface. For example, for numerical parameters, users can enter the adjusted value in the corresponding numerical field to adjust the test parameter. For instance, if the test parameter is the document issuance frequency parameter, a frequency value can be entered as needed.

[0065] Alternatively, the configuration of test parameters can be adjusted by modifying their options. For example, a test parameter with only two configuration options, true and false, might have corresponding checkboxes on the configuration interface. When an option is checked, the test parameter is configured as true; when it is unchecked, it is configured as false. Users can adjust the configuration of such test parameters by changing whether the checkboxes are checked. Another example is test parameters that can only be tested with a few fixed parameters. These parameters can be set as options for the corresponding test parameter. For instance, a dropdown list can be used on the configuration interface, allowing users to adjust the configuration of the test parameter by selecting different options from the dropdown. This allows for quick configuration, provides an easy-to-use interface, and requires minimal programming skills from the user.

[0066] S2: Parse the Extensible Markup Language (XML) format data and convert the test information in the XML format data into dictionary-style data.

[0067] In some feasible embodiments, parsing the Extensible Markup Language (XML) format data and converting the test information in the XML format data into dictionary-like data includes:

[0068] The Extensible Markup Language (XML) format data is traversed to obtain key fields; in this embodiment, key fields refer to the fields corresponding to test parameter items.

[0069] The test parameters contained in the key field are obtained based on the key field. The test parameters are the configuration information corresponding to the test parameter items, which can be numerical information, etc. The same key field may include one or more test parameters.

[0070] The key fields and test parameters are converted into dictionary-style data, which contains the test parameters of the module under test. In this embodiment, AutosarUtil data is converted into PYTHON dictionary-style data. PYTHON is a computer programming language with characteristics such as object-oriented, interpreted, interactive, easy to learn, easy to read, and easy to maintain. In PYTHON, a dictionary (dict) is a mutable container model that can store objects of any type. Each key-value pair (key=>value) in the dictionary is separated by a colon, and each key-value pair is separated by a comma, with the entire dictionary enclosed in curly braces. When converting AutosarUtil data into PYTHON dictionary-style data, different modules can be used as different dictionary types, with each key field of the same module used as the key in that dictionary type, and the test parameters of the corresponding key fields used as the values ​​of the corresponding keys to form the dictionary-style data. For example, the can_if module can be used as a dictionary type, the sending frequency corresponding to can_if can be used as a key, and the value of the sending frequency can be used as the value corresponding to the key of sending frequency.

[0071] In some feasible embodiments, dictionary tools can be used to convert key test information into dictionary-style data.

[0072] It should be noted that the dictionary-style data contains key fields and test parameters for all modules in the corresponding project.

[0073] In some feasible embodiments, since the test parameter configuration and Extensible Markup Language (XML) format data parsing are implemented in different programs, the corresponding XML format data can be obtained and parsed by setting the storage path of the XML format data; alternatively, the corresponding XML format data can be obtained and parsed by setting the file name of the XML format data.

[0074] S3: Traverse the dictionary-style data to determine the test parameter list for the module under test. The test parameter list only contains the key fields and test parameters of the module under test.

[0075] In some feasible embodiments, the step of traversing dictionary-style data to determine the test parameter list of the module under test includes:

[0076] The dictionary type is determined based on the module under test. In this embodiment, when generating dictionary data, it is generated based on the module. Therefore, the dictionary type from which the test parameters originate is determined based on the module under test.

[0077] The test parameter list of the module under test is obtained from the dictionary-formatted data according to the dictionary type. The test parameter list contains the configuration data of the module under test. In some feasible embodiments, for general parameters, the configuration data in the dictionary can be directly obtained. For parameters that exist in multiple dictionaries, the corresponding key fields can be traversed using a for loop to obtain the corresponding test parameters, that is, by traversing the keys in the dictionary to find the corresponding values.

[0078] like Figure 2 As shown, when parsing Extensible Markup Language (ARXML) format data, the path to the current ARXML format data storage is first determined: `XXX_ARXML_PATH = os.path.join(CFG_PRJ_PATH,"Config / Bsw / XXX / XXX_ecuc.arxml")`. This path can be entered into a utility function. When the utility function runs, it directly retrieves the ARXML from the corresponding path for parsing: `XXX_autosar = AutosarUtil.parse_arxml(XXX_ARXML_PATH)`. After parsing, the tool converts the parsed data into a dictionary, for example, `XXXcfg_raw = utosarUtil.to_bsw_dict(XXX_autosar)`, which converts the data from the XXX module into a dictionary. Finally, the data in the dictionary is retrieved to form a test parameter list: XXX_cfg = XXXcfg_raw["ArPackages"]["ActiveEcuC"]["XXX"]. Different methods are used to retrieve the data depending on its type. For example, for general parameters, the configuration data in the dictionary is retrieved directly, such as: canm_cfg["CanNmGlobalConfig"]["CanNmRemoteSleeplndEnabled"]["Value"]. For parameters in multiple dictionaries, a for loop can be used to iterate through the corresponding key fields to obtain the corresponding test parameters, i.e., by iterating through the keys in the dictionary to find the corresponding values. For example, CanNmChannelConfig_dict = canm_cfg["CanNmGlobalConfig"][channelkey] CanNmChannelConfig_dict["CanNmMsgCycleTime"]["Value"].

[0079] S4: Execute test cases according to the test parameter list to test the module under test.

[0080] A test case is a description of a testing task for a specific software product, including the test plan, methods, techniques, and strategies. The main purpose of a test case is to verify whether the software meets specific requirements through a set of test inputs, execution conditions, and expected results. In this embodiment, the test cases mainly refer to test cases for CAN communication.

[0081] In some feasible embodiments, executing test cases according to the test parameter list includes:

[0082] Based on the global variables in the test cases, the values ​​corresponding to the global variables are retrieved from the test parameter list to execute the test cases. Global variables are variables that can be accessed throughout the entire program; they can be accessed and modified from anywhere in the program. Test parameters are defined using global variables in the test cases. When the test cases are executed, the values ​​corresponding to the global variables are called to perform the tests. In this embodiment, the test parameter list is used as the global variables in the test cases, and the values ​​in the test parameter list are used as the values ​​of the global variables. This facilitates the subsequent transfer of test cases to other platforms, reducing the programming development cycle and complexity.

[0083] In other feasible embodiments, the input parameters corresponding to the functions in the test cases are obtained from the test parameter list to execute the test cases. Function input parameters refer to the numerical values ​​of the corresponding parameters passed to the function when it is called. In test cases, test parameters are defined using functions, allowing the corresponding input parameters to be called during test case execution. In this embodiment, the test parameter list is used as the function in the test cases, and the values ​​in the test parameter list are used as the function's input parameters. Using function input parameters also facilitates the subsequent transfer of test cases to other platforms, reducing programming development cycle and complexity.

[0084] Using the aforementioned techniques, the testing method stores the adjusted test parameters of each module under test in the project as Extensible Markup Language (XML) format data. By parsing this XML data, the test information for each module can be converted into a more concise and intuitive dictionary format. Then, the test parameter list for each module under test is determined from this dictionary data. This list contains only the test information for the module under test. Modules under test in different projects can all be converted into test parameter lists using the aforementioned method. During testing, test cases are executed according to the test parameter list without manual modification of test case parameters. The same modules in different projects can be tested using the same test cases, achieving test case platformization. When a new project is introduced, the test cases for the corresponding module can automatically adapt based on the determined test parameter list, eliminating the need for manual parameter adjustment. This method automatically parses XML format data, offering convenience, speed, and ease of use.

[0085] In some feasible embodiments, the testing method further includes:

[0086] Collect message data after the test cases are executed. A message is a data unit exchanged and transmitted in a network. In this embodiment, message data refers to the messages sent or received by the module under test after executing the test cases. In this embodiment, the project under test can be connected to a computer via a data cable, and then the message data after the project under test is executed can be collected using monitoring tools on the computer.

[0087] Determine whether the message data matches the execution expectation of the test case. The execution expectation of the test case is the result after the test case is correctly executed. For example, if a message sending test is performed on a corresponding channel, the monitoring software should be able to receive the message data sent on the corresponding channel after the test case is executed.

[0088] For example, suppose the test case is a message test case testing the sending direction, such as... Figure 3As shown, when executing test cases, the CanTool library is used to parse the DBC: db = cantools.database.load file{file}, then iterates through and retrieves messages from the DBC. The message content is parsed; if the message ID is between 0x400 and 0x4FF, the message is considered a network management message; if the message attribute GenMsgILSupport is 0, the message is considered a routing message; if neither is true, it is an application message. This allows obtaining the expected execution result of the message test case. During the above steps, the serial port and channel data (get_serial_and_channel_from_dbc) are continuously monitored synchronously, capturing messages for 30 seconds. msg_list = capture_msgs{dut,serial,channel.True,CHECK_MSG_CAPYURE_MSG_TIME}. Similarly, message IDs and attributes are checked to distinguish message types, thus obtaining the actual sent messages. Then, the messages in the DBC are compared with the actual sent messages (network management messages, routing messages, and application messages). Based on the messages in the DBC and the actual sent messages, the following judgments can be made: For example, test whether the corresponding channel of the test board sends messages and whether they are consistent with the DBC. If they are sent and consistent, the message sending test passes; otherwise, the message sending test fails. Another example is whether the message period of the corresponding channel of the test board is consistent with the arxml. If they are consistent, the message period test passes; otherwise, the message period test fails. Other sending tests can also be performed on the message test cases in the sending direction, which are not listed here.

[0089] Assuming the test cases are for testing messages in the receiving direction, such as... Figure 4As shown, when executing the test case, firstly, all messages in the receiving direction in the DBC are parsed, and messages are continuously sent for 30 seconds. The sending period Tp is defined in the DBC. The received message status of CANIF is continuously observed. The CANIF_rx_message statistic[CANIF_MAX_NOF_RX_PDU] is used to first determine if the number of messages received by CANIF is greater than zero (CANIF_rx_message statisticf[ldx]>0). If it is not greater than zero, CANIF is considered to have failed to receive messages. If the number of received messages is greater than zero, the message receiving test passes, and CANIF successfully receives messages. Next, it is determined whether the received message statistic f[ldx] is equal to the duration / sending period. If it is, the packet loss rate test in the receiving direction passes, and the packet loss rate is zero. Otherwise, the CANIF packet loss rate test in the receiving direction fails, and the packet loss rate is canif_rx_messagestatistic[ldx] / duration / sending period*100%. The receive direction test for other modules is the same as that for the CANIF module, such as the COM module, CANNM module, etc.

[0090] The platform-based testing method of this application will be explained below in conjunction with specific applications.

[0091] like Figure 5As shown, firstly, the project to be tested is determined from multiple projects (e.g., ACU, ADMAX_MCU). Then, the test cases to be executed are determined. Next, the monitoring tool, such as the Tongxing TsMaster device, is initialized. The CAN network database file is obtained based on the project name. In this embodiment, the corresponding CAN network database file is obtained based on the directory where the CAN network database file is located. The directory containing the CAN network database file stores multiple DBC files, such as EEA25_CAN_Matrix_V0.22_20231013_M2CU_ZCAN.dbc, EEA25_CAN_Matrix_V0.22_20231013_M2CU_BLECAN.dbc, etc. After obtaining the file, it is imported into the configuration interface. At this time, the configuration interface displays the names of different channels in the project, such as ZCAN, BLECAN, etc. Expanding these displays the test parameter items for the corresponding channels. The CAN network database file corresponding to each channel is obtained sequentially and saved as Extensible Markup Language (XML) format data according to the corresponding channel number, such as ZCAN_TSUN_CHN, BLECAN_TSUN_CHN. Then, the Extensible Markup Language (XML) format data is parsed and saved as a dictionary. The numerical values ​​of the corresponding parameters of the module under test (DUT), such as the channel number and message ID, are retrieved from this dictionary. The channel number and message ID are then passed to the test case as global variables. The message `msg` related to the test case in the DBC file is parsed, the test case is executed, and the execution result is judged to meet expectations. Thus, by parsing the XML format data, the test information for each module can be converted into a more concise and intuitive dictionary format. The test parameters of the DUT can then be determined from this dictionary data. Modules under test in different projects can all be converted into test parameters of the same format using the aforementioned method. During testing, test cases are executed according to the test parameters without the need for manual modification of the test case parameters. The same module in different projects can be tested using the same test cases, achieving test case platformization.

[0092] The second aspect of this application provides a platform-based testing device, such as... Figure 6 As shown, the platform-based testing device includes:

[0093] The parameter configuration unit is used to configure the test parameters of the module under test and save them as Extensible Markup Language (EXPLAIN) format data.

[0094] The conversion unit is used to parse the Extensible Markup Language (XML) format data and convert the test information in the XML format data into dictionary-style data.

[0095] The list determination unit is used to traverse dictionary-style data to determine the list of test parameters for the module under test.

[0096] An execution unit is used to execute test cases according to the test parameter list in order to verify the test cases.

[0097] In some feasible embodiments, the parameter configuration unit is further configured to:

[0098] Import the CAN network database file and the driver file in Extensible Markup Language format of the module under test into the configuration interface;

[0099] Identify test parameter items in CAN network database files and driver files in Extensible Markup Language format;

[0100] Adjust the configuration of the test parameters and save them as Extensible Markup Language (XML) data.

[0101] In some feasible embodiments, the conversion unit is further configured to:

[0102] Traverse the Extensible Markup Language (XML) formatted data to obtain key fields;

[0103] Obtain the test parameters contained in the key field based on the key field;

[0104] The key fields and the test parameters are converted into dictionary data, which contains the test parameters of the module under test.

[0105] In some feasible embodiments, the inventory determination unit is further configured to:

[0106] Use the key fields as keys in dictionary-style data;

[0107] The test parameters corresponding to the key fields are used as the values ​​of the corresponding keys to generate dictionary-style data.

[0108] In some feasible embodiments, the conversion unit is further configured to:

[0109] Determine the dictionary type based on the module being tested;

[0110] The test parameter list of the module under test is obtained from the dictionary-formatted data according to the dictionary type.

[0111] In some feasible embodiments, the execution unit is further configured to:

[0112] Based on the global variables in the test case, retrieve the corresponding values ​​of the global variables from the test parameter list to execute the test case;

[0113] Alternatively, based on the function in the test case, obtain the corresponding input parameters of the function from the test parameter list to execute the test case.

[0114] Figure 7This application illustrates a complete technical flowchart of a testing method provided in one embodiment, as shown below. Figure 7 As shown. The complete technology includes an input terminal, a processing terminal, and an output terminal. The input terminal determines the project to be tested based on the project name, then imports the corresponding project's DBC file and CAN driver ARXML file, and configures the corresponding configuration items in the UI interface. After configuration, it is saved as an ARXML file containing the configuration data. The processing terminal obtains the ARXML file containing the configuration data and parses it, generating the AUTOSAR-related data type AutosarUtil. Then, it converts the AutosarUtil data into a Python dictionary and retrieves the corresponding configuration data from the dictionary according to the module under test. The output module obtains the values ​​of the corresponding parameter configuration items as input parameters for the test cases, executes the test cases, and determines whether the test cases pass or fail based on the execution results.

[0115] A third aspect of this application provides an electronic device, comprising:

[0116] The memory is configured to store instructions; and

[0117] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the platform-based testing method.

[0118] A fourth aspect of this application provides a machine-readable storage medium storing instructions that cause a machine to execute the platform-based testing method described above.

[0119] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the platform-based testing method.

[0120] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0121] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0122] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0123] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0124] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0125] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0126] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0127] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0128] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A platform-based testing method, characterized in that, The platform-based testing methods include: Configure the test parameters of the module under test and save them as Extensible Markup Language (EXPLAIN) format data; Parse the Extensible Markup Language (XML) format data and convert the test information in the XML format data into dictionary-style data; Traverse the dictionary-style data to determine the list of test parameters for the module under test; Test cases are executed according to the test parameter list to achieve the testing of the module under test.

2. The platform-based testing method according to claim 1, characterized in that, The test parameters of the module under test are configured and saved as Extensible Markup Language (EXPLAIN) data, including: Import the CAN network database file and the driver file in Extensible Markup Language format of the module under test into the configuration interface; Identify test parameter items in CAN network database files and driver files in Extensible Markup Language format; Adjust the configuration of the test parameters and save them as Extensible Markup Language (XML) data.

3. The platform-based testing method according to claim 1, characterized in that, The step of parsing the Extensible Markup Language (XML) format data, converting the test information in the XML format data into dictionary-style data, includes: Traverse the Extensible Markup Language (XML) formatted data to obtain key fields; Obtain the test parameters contained in the key field based on the key field; The key fields and the test parameters are converted into dictionary data, which contains the test parameters of the module under test.

4. The platform-based testing method according to claim 3, characterized in that, The step of converting the key fields and the test parameters into dictionary-style data includes: Use the key fields as keys in dictionary-style data; The test parameters corresponding to the key fields are used as the values ​​of the corresponding keys to generate dictionary-style data.

5. The platform-based testing method according to claim 1, characterized in that, The dictionary-style data is traversed to determine the list of test parameters for the module under test, including: Determine the dictionary type based on the module being tested; The test parameter list of the module under test is obtained from the dictionary-formatted data according to the dictionary type.

6. The platform-based testing method according to claim 1, characterized in that, The step of executing test cases according to the test parameter list includes: Based on the global variables in the test case, retrieve the corresponding values ​​of the global variables from the test parameter list to execute the test case; Alternatively, based on the function in the test case, obtain the corresponding input parameters of the function from the test parameter list to execute the test case.

7. The platform-based testing method according to claim 1, characterized in that, The testing method also includes: Collect message data after test cases are executed; Determine whether the message data matches the expected execution of the test case.

8. A platform-based testing device, characterized in that, The platform-based testing device includes: The parameter configuration unit is used to configure the test parameters of the module under test and save them as Extensible Markup Language (EXPLAIN) format data. The conversion unit is used to parse the Extensible Markup Language (XML) format data and convert the test information in the XML format data into dictionary-style data. The list determination unit is used to traverse dictionary-style data to determine the list of test parameters for the module under test. An execution unit is used to execute test cases according to the test parameter list in order to verify the test cases.

9. An electronic device, characterized in that, include: The memory is configured to store instructions; as well as A processor configured to retrieve the instructions from the memory and, when executing the instructions, to implement the platform-based test method of any one of claims 1 to 7.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the platform-based test method as described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the platform-based testing method as described in any one of claims 1 to 7.

Images