Automatic test system and method for intelligent cabin middleware

Abstract

The invention relates to an automatic test system and method for intelligent cabin middleware, and the system comprises a cloud test module and a cabin end test module, the cloud test module is used for receiving a test scene and interfaces of to-be-tested middleware, arranging and configuring test data for the interfaces of the to-be-tested middleware, and transmitting the test data to the cabin end test module; generating a test task according to the test data and a series-parallel hybrid strategy of a preset task dependency relationship, issuing the test task to a cabin end test module, receiving and processing test results of a plurality of to-be-tested middleware of the cabin end test module, and generating a test report based on the test results; and the cabin end test module is used for controlling the plurality of to-be-tested middleware to execute the test task according to the test task issued by the cloud end test module, and uploading the test result to the cloud end test module. Therefore, the problems that a traditional cockpit middleware automatic testing scheme is single in testing scene, the number of scripts is large during full-function testing, single-device execution efficiency is low, and parallel execution needs to be conducted with the help of multiple devices are solved.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to an automated testing system and method for smart cockpit middleware. Background Art

[0002] The smart cockpit system middleware is a software layer located between the underlying operating system and the upper-layer application. It provides a unified interface and service, including multiple functions such as infotainment, driving assistance, and intelligent control. As the degree of automobile intelligence continues to increase, the quality and stability requirements for middleware are also getting higher and higher. Therefore, the testing of the smart cockpit system middleware is also particularly important.

[0003] The traditional cockpit middleware automation testing solution is to write junit test scripts based on functional requirements and execute these scripts on the vehicle side. However, this method has many limitations. First, the test scenario is single and it is difficult to cover complex actual driving scenarios. Second, due to the serial execution characteristics of junit, the number of scripts is huge during full-function testing, and the execution efficiency of a single device is low. It is necessary to use multiple devices for parallel execution to improve efficiency. Summary of the invention

[0004] The present application provides an intelligent cockpit middleware automation testing system and method to solve the problems of traditional cockpit middleware automation testing solutions, such as single testing scenarios, a large number of scripts during full-function testing, low execution efficiency on a single device, and the need for parallel execution on multiple devices.

[0005] The first aspect of the present application provides an automated testing system for intelligent cockpit middleware, comprising: a cloud test module and a cabin-side test module, the cabin-side test module comprising a plurality of middleware to be tested, the cloud test module establishing a communication connection with the cabin-side test module, the cloud test module being used to receive a target test scenario and interfaces of a plurality of middleware to be tested, perform interface orchestration and configure test data for the interfaces of the plurality of middleware to be tested based on the target test scenario, generate a current test task for each middleware to be tested according to a series-parallel hybrid strategy of the orchestrated interfaces, the test data and preset task dependencies, publish the current test task to the cabin-side test module, receive and process test results of the plurality of middleware to be tested of the cabin-side test module based on the current test task, and generate a test report based on the test results; the cabin-side test module is used to control the plurality of middleware to be tested to execute the current test task according to the current test task issued by the cloud test module, and upload the test results to the cloud test module.

[0006] Optionally, the cabin-side test module includes: a monitoring unit, used to monitor and receive the current test task issued by the cloud-side test module; a task parsing unit, used to parse the current test task and obtain a task execution strategy list; a task scheduling unit, used to allocate the current test task to the multiple middleware to be tested based on the task execution strategy list; an execution unit, used to control the multiple middleware to be tested to execute the current test task; and a collection unit, used to collect performance data, test logs and test results of the multiple middleware to be tested when executing the current test task.

[0007] Optionally, the cloud-based test module includes: an import unit for importing the target test scenario and the interfaces of the multiple middleware to be tested; a configuration unit for performing interface orchestration and configuring test data for the interfaces of the multiple middleware to be tested based on the target test scenario; a task planning unit for generating a current test task according to a series-parallel hybrid strategy of the orchestrated interface, the test data and preset task dependencies; and a test publishing unit for publishing the current test task to the cabin-end test module when a preset trigger time is reached.

[0008] Optionally, the cloud-based testing module further includes: an analyzing unit, configured to receive the performance data, test logs and test results collected by the collecting unit, and generate a test report for the plurality of middlewares to be tested.

[0009] Optionally, the cloud-based testing module further includes: a display unit, which is connected to the analysis unit and is used to display test reports of the multiple middlewares to be tested.

[0010] Optionally, the cloud-based testing module further includes: an alarm unit, which is connected to the analysis unit and is used to generate an acoustic alarm and / or an optical alarm when the test results of the plurality of middlewares to be tested are failure results.

[0011] Optionally, the interfaces of the multiple middlewares to be tested are Java interfaces.

[0012] The second aspect of the present application provides an automated testing method for intelligent cockpit middleware, which adopts the above-mentioned automated testing system for intelligent cockpit middleware, and includes the following steps: using a cloud test module to receive a target test scenario and interfaces of multiple middleware to be tested, and based on the target test scenario, performing interface orchestration and configuring test data for the interfaces of the multiple middleware to be tested, and generating a current test task for each middleware to be tested according to a series-parallel hybrid strategy of the orchestrated interface, the test data and preset task dependencies, publishing the current test task to the cabin-end test module, receiving and processing the test results of the multiple middleware to be tested of the cabin-end test module based on the current test task, and generating a test report based on the test results; using the cabin-end test module according to the current test task issued by the cloud test module, and controlling the multiple middleware to be tested to execute the current test task, and uploading the test results to the cloud test module.

[0013] Optionally, before using the cabin-side test module to control the multiple middleware to be tested to execute the current test task according to the current test task issued by the cloud test module, it includes: checking whether the current test task depends on the test result of the predecessor test task; if the current test task depends on the test result of the predecessor test task, then executing the current test task after the test result of the predecessor test task is a success result, if the test result of the predecessor test task is a failure result, then continuing to execute the current test task.

[0014] Optionally, when controlling the multiple middleware to be tested to execute the current test task based on a series-parallel hybrid strategy of preset task dependencies, it also includes: monitoring whether the test scenarios to be tested are missing when the multiple middleware to be tested are executing the current test task; if the test scenarios to be tested are missing, terminating the current test task, adjusting the current test task, and re-controlling the multiple middleware to be tested to execute the adjusted current test task after the adjustment is completed.

[0015] In the above implementation, the cloud test module is used to receive the target test scenario and the interfaces of multiple middlewares to be tested, and the interfaces of multiple middlewares to be tested are arranged and test data is configured based on the target test scenario. The current test task of each middleware to be tested is generated according to the serial-parallel hybrid strategy of the arranged interface, test data and preset task dependency, and the current test task is published to the cabin test module, and the test results of multiple middlewares to be tested based on the current test task of the cabin test module are received and processed, and a test report is generated based on the test results. The cabin test module is used according to the current test task issued by the cloud test module, and multiple middlewares to be tested are controlled to execute the current test task, and the test results are uploaded to the cloud test module. Thus, the traditional cockpit middleware automation test scheme has a single test scenario, a large number of scripts during full-function testing, low execution efficiency of a single device, and the need to use multiple devices for parallel execution. The problems can be solved, and a rich cockpit middleware interface test scenario can be realized, so that the test scenario of the middleware interface is closer to the actual driving use scenario, and the actual user can more accurately reflect the problems that may be encountered when using the system, improve the test efficiency and coverage, and there is no need to complete the full-scenario test by adding more devices.

[0016] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0018] Figure 1 A schematic diagram of an automated testing system for smart cockpit middleware provided according to an embodiment of the present application;

[0019] Figure 2 A schematic diagram of the structure of an end-to-end intelligent cockpit middleware automated test according to an embodiment of the present application;

[0020] Figure 3 A flowchart of cloud test task planning according to an embodiment of the present application;

[0021] Figure 4 The following is a flowchart of executing tasks of a cabin end test module according to one embodiment of the present application;

[0022] Figure 5 A schematic diagram of a task execution strategy formulated for the orchestration according to an embodiment of the present application;

[0023] Figure 6 The present invention is a flowchart of an automated testing method for smart cockpit middleware according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0025] The following describes the intelligent cockpit middleware automation test system and method of the embodiment of the present application with reference to the accompanying drawings. In view of the problems mentioned in the above background technology that the traditional cockpit middleware automation test scheme has a single test scenario, a large number of scripts during full-function testing, low execution efficiency of a single device, and requires the use of multiple devices for parallel execution, the present application provides an intelligent cockpit middleware automation test system, in which a cloud test module is used to receive the target test scenario and the interfaces of multiple middlewares to be tested, and interface arrangement and test data are configured for the interfaces of multiple middlewares to be tested based on the target test scenario, and the current test task of each middleware to be tested is generated according to the series-parallel hybrid strategy of the arranged interface, test data and preset task dependency, and the current test task is published to the cabin-side test module, and the test results of multiple middlewares to be tested based on the current test task of the cabin-side test module are received and processed, and a test report is generated based on the test results, and the cabin-side test module is used according to the current test task issued by the cloud test module, and the multiple middlewares to be tested are controlled to execute the current test task, and the test results are uploaded to the cloud test module. This solves the problems of traditional cockpit middleware automation testing solutions, such as a single test scenario, a large number of scripts during full-function testing, low execution efficiency on a single device, and the need to use multiple devices for parallel execution. It can achieve rich cockpit middleware interface test scenarios, making the middleware interface test scenarios closer to actual driving scenarios, and can more accurately reflect the problems that actual users may encounter when using the system, improving test efficiency and coverage, without the need to add more devices to complete full-scenario testing.

[0026] Specifically, Figure 1 A flowchart of an automated testing system for intelligent cockpit middleware provided in an embodiment of the present application.

[0027] like Figure 1 As shown, the intelligent cockpit middleware automated testing system 10 includes: a cloud test module 100 and a cabin test module 200, the cabin test module 200 includes a plurality of middleware to be tested, and the cloud test module 100 establishes a communication connection with the cabin test module 200, wherein:

[0028] like Figure 2As shown, the cloud-side test module 100 is used to receive the target test scenario and the interfaces of multiple middleware to be tested, perform interface arrangement and configure test data for the interfaces of the multiple middleware to be tested based on the target test scenario, and generate the current test task according to the arranged interface, test data and the series-parallel hybrid strategy of the preset task dependency, publish the current test task to the cabin-side test module 200, and receive and process the test results of the multiple middleware to be tested of the cabin-side test module 200 based on the current test task, and generate a test report based on the test results; the cabin-side test module 200 is used to control the multiple middleware to be tested to execute the current test task according to the current test task issued by the cloud-side test module 100 and the series-parallel hybrid strategy based on the preset task dependency, and upload the test results to the cloud-side test module 100.

[0029] Optionally, in some embodiments, the cabin-side test module 200 includes: a monitoring unit, used to monitor and receive the current test task issued by the cloud-side test module 100; a task parsing unit, used to parse the current test task and obtain a task execution strategy list; a task scheduling unit, used to allocate the current test task to multiple middleware to be tested based on the task execution strategy list; an execution unit, used to control multiple middleware to be tested to execute the current test task; and a collection unit, used to collect performance data, test logs and test results of multiple middleware to be tested when executing the current test task.

[0030] Optionally, in some embodiments, the cloud-based test module 100 includes: an import unit for importing a target test scenario and multiple interfaces of middleware to be tested; a configuration unit for performing interface orchestration and configuring test data for multiple interfaces of middleware to be tested based on the target test scenario; a task planning unit for generating a current test task based on a series-parallel hybrid strategy of the orchestrated interface, test data and preset task dependencies; and a test publishing unit for publishing the current test task to the cabin-end test module 200 when a preset trigger time is reached.

[0031] Optionally, in some embodiments, the cloud testing module 100 further includes: an analyzing unit, configured to receive the performance data, test logs and test results collected by the collecting unit, and generate test reports for multiple middlewares to be tested.

[0032] Optionally, in some embodiments, the cloud testing module 100 further includes: a display unit, which is connected to the analysis unit and is used to display test reports of multiple middlewares to be tested.

[0033] Optionally, in some embodiments, the cloud test module 100 further includes: an alarm unit, which is connected to the analysis unit and is used to make an acoustic alarm and / or an optical alarm when the test results of the plurality of middlewares to be tested are failure results.

[0034] Optionally, in some embodiments, the interfaces of the plurality of middlewares to be tested are Java interfaces.

[0035] In the embodiment of the present application, end-to-end refers to the cloud and the cabin side, the cloud side serves as a test service, the cabin side is responsible for test execution, and end-to-end communication and data transmission are realized through the network. The cloud test module 100 usually involves a series of high-performance and high-reliability hardware devices, as well as supporting software systems and network environments. These devices together constitute the infrastructure of the cloud test service, which is used to support a series of operations such as cockpit test task planning, test release, and report analysis. The cabin test module 200 refers to a software package running on the smart cockpit terminal system. Because the test target is the service and interface (Java interface form) open to the application by the smart cockpit middleware (i.e., the Framework layer of the on-board Android system), and involves the interaction of software, hardware, sensors and other modules, the test executor on the cabin side needs to run in a real environment. The cabin test executor is mainly responsible for receiving the test instructions issued by the cloud, executing the test according to the test instructions, and uploading the test results and other data to the cloud after the test is completed.

[0036] Specifically, Figure 3 As shown, the execution process of the cloud test module 100 is step S100, and in step S100, it includes:

[0037] Step S101: The import unit receives the target test scenario imported by the user. Scenario: can be a scenario or a scenario story, including but not limited to the actual usage scenario during driving and the test scenario corresponding to the functional requirements. Function: mainly the specific capabilities or services provided by the smart cockpit middleware, such as infotainment, driving assistance, intelligent control, etc.

[0038] Step S102: The import unit determines the interface range and imports the middleware interface based on the imported target test scenario and function. The configuration unit configures test data for the interfaces of multiple middleware to be tested based on the target test scenario, parses the interface information (such as interface name, class path, parameter type, description, etc.), assigns a unique ID to each interface, configures keywords according to the interface functional characteristics, and then stores them in the interface library. It should be noted that the test of the smart cockpit middleware is actually a test in the Java interface dimension. The imported middleware interface may be the original middleware interface or the encapsulated interface. Either one is a Java interface.

[0039] Step S103: The task planning unit generates the current test task according to the test data and the serial-parallel hybrid strategy of the preset task dependency.

[0040] First, based on the imported target test scenarios and interfaces, the corresponding test data is matched, the interface arrangement and combination are used as small functional requirements, and the test tasks generated by the small functional requirements are combined. Then, the test task set is selected to formulate a test plan, and the task planning is carried out based on the series-parallel hybrid strategy of the preset task dependency relationship, and the task execution strategy is formulated.

[0041] In principle, tasks without dependencies are executed in parallel, and those with dependencies are executed serially. Dependencies include but are not limited to tasks that rely on the results of previous tasks, or resource competition between tasks (such as making a phone call and playing music).

[0042] Step S104: the test issuing unit issues the current test task to the cabin end test module 200 when detecting that the current test task reaches a preset trigger time.

[0043] Step S105: The cloud test module 100 receives the test result related data of the cabin test module 200, and generates relevant statistical reports through the analysis unit, including but not limited to test reports, defect reports, performance reports, etc.

[0044] The execution process of the cabin end test module 200 is step S200, and in step S200, it includes:

[0045] Step S201: Figure 4 As shown, the monitoring unit of the cabin end test module 200 receives the current test task.

[0046] Step S202: The task parsing unit loads and parses the current test task, obtains a task execution strategy list, and then sends the task execution strategy list to the task scheduling unit.

[0047] Step S203: The task scheduling unit receives and parses the task execution strategy list, stores the task into the task pool, implements task scheduling based on the task execution strategy list, assigns the task in the task execution strategy list to a suitable execution unit (such as a thread, process, etc.), parses the current test task data through the task assembly component, configures the middleware test services and resources required for the task, executes the current test task on the assigned execution unit, tests the service of the middleware to be tested based on the order of the interface arrangement in the task and the test data, calls the interface or service of the middleware to be tested, and verifies whether the test result of each middleware to be tested meets expectations. If it meets expectations, the current API execution result is marked as passed, otherwise it is marked as failed. If the API interfaces of the middleware to be tested in the current test task are all executed successfully, then the current test task is executed successfully, otherwise the current test task fails.

[0048] If the current test task depends on the test result of the previous test task, the current test task will be executed after the test result of the previous test task is a success result. If the test result of the previous test task is a failure result, the previous test task will be skipped and the current test task will continue to be executed.

[0049] Step S204: During the task execution process, the collection unit collects performance data, test logs, test results and other data of multiple middlewares to be tested, and uploads the collected relevant data to the cloud after the task execution is completed.

[0050] Furthermore, the display unit displays the test reports of the plurality of middlewares to be tested, and the alarm unit issues an acoustic alarm and / or an optical alarm when the test results of the plurality of middlewares to be tested are failure results.

[0051] It should be noted that the cloud test module usually involves a series of high-performance and high-reliability hardware devices, as well as the supporting software system and network environment. These devices together constitute the infrastructure of the cloud test service, which is used to support a series of operations such as cockpit test task planning, test release and report analysis; the cabin test module refers to the software package running on the intelligent cockpit terminal system (here is the Android system). It should be noted that the test executor software package is a direct service or interface to the cockpit middleware, which needs to run in a real environment without a UI interface.

[0052] End-to-end communication and data transmission are carried out through the network, supporting dynamic planning of test tasks. For example, if a test scenario is suddenly found to be missing during test execution, the test can be terminated directly in the cloud and the test task planning can be adjusted and re-issued for execution.

[0053] Among them, it should be noted that:

[0054] Interface orchestration and test data design: The embodiment of the present application arranges and combines interfaces according to a certain logic and sequence based on actual usage scenarios and interface functions, and then designs test data for the arranged interfaces (including but not limited to interface input parameters, expected values, etc.) to ensure that the arranged interfaces can work as expected. The relationship between interface orchestration and test data is one-to-many, that is, one set of arranged interfaces can be equipped with one or more sets of test data.

[0055] Test task: A test task can be created by using a combination of one or more groups of interfaces.

[0056] Test plan: A test plan contains several test tasks.

[0057] Formulate task execution strategy: It aims to formulate execution strategy for the task set in the test plan. It is a task arrangement based on the serial and parallel mixed logic of task dependencies. In principle, tasks without dependencies are parallel, and tasks with dependencies are serial. The scenarios with dependencies include but are not limited to the dependence of tasks on the execution results of the predecessor tasks (such as Bluetooth switches and Bluetooth phones), or resource competition type dependence (that is, multiple tasks access the same resource, such as Bluetooth music and media music).

[0058] like Figure 5 It is a task execution strategy model diagram based on the serial-parallel hybrid logic of task dependency. Tasks without dependencies are parallel, such as task1 and task2, which are parallel as two independent tasks; while tasks with dependencies need to wait for the previous task to finish before they can start to execute. For example, task4 in the figure needs to depend on task3 to start execution, and task7 can only be executed after task5 and task6 are finished. Task10 and task11 have no dependencies on each other, but they both depend on task9, so after task9 is finished, task10 and task11 can start to execute in parallel.

[0059] In order to enable those skilled in the art to further understand the intelligent cockpit middleware automated testing system of the embodiment of the present application, it is elaborated in detail below in conjunction with specific embodiments.

[0060] Test module 100 in the cloud,

[0061] Import target test scenarios, functions and smart cockpit middleware interfaces (including but not limited to by importing interface documents), parse interface information (such as interface name, class path, parameter type, description, etc.), assign a unique ID to each interface, configure keywords according to the interface functional characteristics, and then store them in the interface library.

[0062] Further test task planning mainly includes four steps: interface arrangement and test data design, creating test tasks, creating test plans, and formulating task execution strategies:

[0063] Interface arrangement and test data design, based on the imported scenarios and functions, arrange and combine the interfaces according to a certain logic and order, and design necessary test data (including but not limited to the input parameters and expected values ​​of the interface) to ensure that the arranged interface can work as expected. The relationship between interface arrangement and test data is one-to-many, that is, a group of arranged interfaces can be equipped with one or more groups of test data. It should be noted that the test data should cover normal input, abnormal input, boundary values, etc., to ensure that the function of the interface under different input conditions is fully verified.

[0064] Create a test task. A test task can be created by using a combination of one or more groups of interfaces.

[0065] Create a test plan, set the task set, trigger time, and execution frequency.

[0066] Task set: A test plan contains several test tasks.

[0067] Trigger time: refers to the trigger time of the test plan, including but not limited to immediate trigger and scheduled trigger (such as sending the test plan to the test executor at 22:00 every day to start the test);

[0068] Execution frequency: refers to the number of times a single test plan is triggered and executed repeatedly. It can be a one-time execution or repeated execution. Repeated execution can be repeated a certain number of times (such as 100 times in a loop) or limited execution time (such as setting the execution time to 8 hours, then executing repeatedly within 8 hours);

[0069] Formulate the execution strategy of tasks. The formulation of task execution strategy is based on the serial and parallel mixed logic of task dependencies. In principle, tasks without dependencies are parallel (such as Bluetooth, WiFi, and air conditioning related tasks do not affect each other and can be executed in parallel), and tasks with dependencies are serial. The scenarios with dependencies include but are not limited to the dependence of tasks on the execution results of the predecessor tasks (such as Bluetooth switches and Bluetooth phones), or resource competition type dependence (that is, multiple tasks access the same resource, such as Bluetooth music and media music).

[0070] Finally, the test task is scanned periodically, and when the trigger time condition is met, the test task is sent to the cabin end test module 200.

[0071] Test module 200 at the cabin end,

[0072] The monitoring unit receives the test task sent by the cloud test module 100, then sends the test task to the test task parsing unit, and sets the status of the cabin-end test module 200 to in use.

[0073] The task parsing unit receives the test task, loads and parses the test task, obtains the task execution strategy list and sends it to the test task scheduling unit.

[0074] The scheduler of the task scheduling unit receives and parses the task execution strategy table, stores the task in the task pool, implements task scheduling based on the task execution strategy, allocates appropriate execution units (such as threads, processes, etc.) to tasks that meet the execution conditions (such as no predecessor task or the predecessor task has been completed), parses the task through the task assembly component, assembles the interface and data in the task, configures the middleware test service and resources required for the task, executes the task on the execution unit allocated by the scheduler, and calls the cockpit system middleware interface or service through the corresponding middleware test service, and verifies whether the result meets expectations. If the verification passes, the current interface call result is marked as passed, otherwise it is marked as failed. If all the middleware to be tested in the test task pass the test, the test task is executed successfully, otherwise the test task fails. It should be noted that if the task depends on the execution result of the predecessor task, it can only be executed after the predecessor task is successfully executed. If the predecessor task fails to execute, the predecessor task is directly skipped.

[0075] During the task execution process, the collection unit collects performance data, test logs, test results and other data of the middleware to be tested when executing the test task. After all tasks are completed, the collected relevant data will be uploaded to the cloud test module 100, and the status of the cabin-side test module 200 will be set to idle.

[0076] The cloud testing module 100 receives the test result related data and generates relevant statistical reports through the report analysis unit, including but not limited to test reports, defect reports, performance reports, etc.

[0077] According to the intelligent cockpit middleware automation testing system proposed in the embodiment of the present application, a cloud-based test module is used to receive a target test scenario and interfaces of multiple middleware to be tested, and interface orchestration and test data are configured for the interfaces of multiple middleware to be tested based on the target test scenario. The current test task of each middleware to be tested is generated according to a series-parallel hybrid strategy of the orchestrated interface, test data and preset task dependencies, the current test task is published to the cabin-side test module, and the test results of multiple middleware to be tested based on the current test task of the cabin-side test module are received and processed, and a test report is generated based on the test results. The cabin-side test module is used to control multiple middleware to be tested to execute the current test task according to the current test task issued by the cloud-based test module, and the test results are uploaded to the cloud-based test module. This solves the problems of traditional cockpit middleware automation testing solutions, such as a single test scenario, a large number of scripts during full-function testing, low execution efficiency on a single device, and the need to use multiple devices for parallel execution. It can achieve rich cockpit middleware interface test scenarios, making the middleware interface test scenarios closer to actual driving scenarios, and can more accurately reflect the problems that actual users may encounter when using the system, improving test efficiency and coverage, without the need to add more devices to complete full-scenario testing.

[0078] Next, the automated testing method for the smart cockpit middleware proposed in accordance with an embodiment of the present application will be described with reference to the accompanying drawings.

[0079] Figure 6 It is a block diagram of the automated testing method for the smart cockpit middleware according to an embodiment of the present application.

[0080] like Figure 6 As shown, the intelligent cockpit middleware automated testing method adopts the above-mentioned intelligent cockpit middleware automated testing system, wherein the method comprises the following steps:

[0081] In step S601, a cloud-based test module is used to receive a target test scenario and interfaces of multiple middleware to be tested, and interfaces are orchestrated and test data is configured for the interfaces of the multiple middleware to be tested based on the target test scenario. A current test task is generated for each middleware to be tested according to a series-parallel hybrid strategy of the orchestrated interfaces, test data, and preset task dependencies, and the current test task is published to the cabin-side test module. The test results of the multiple middleware to be tested of the cabin-side test module based on the current test task are received and processed, and a test report is generated based on the test results.

[0082] In step S602, the cabin-side test module controls multiple middlewares to be tested to execute the current test task according to the current test task issued by the cloud-side test module, and uploads the test result to the cloud-side test module.

[0083] Optionally, in some embodiments, before using the cabin-side test module to control multiple middleware to be tested to execute the current test task according to the current test task issued by the cloud test module, it includes: checking whether the current test task depends on the test result of the predecessor test task; if the current test task depends on the test result of the predecessor test task, then the current test task is executed after the test result of the predecessor test task is a successful result, if the test result of the predecessor test task is a failed result, then continue to execute the current test task.

[0084] Optionally, in some embodiments, when controlling multiple middleware to be tested to execute the current test task based on a series-parallel hybrid strategy of preset task dependencies, it also includes: monitoring whether the test scenarios to be tested are missing when the multiple middleware to be tested are executing the current test task; if the test scenarios to be tested are missing, terminating the current test task, adjusting the current test task, and re-controlling the multiple middleware to be tested to execute the adjusted current test task after the adjustment is completed.

[0085] It should be noted that the aforementioned explanation of the embodiment of the intelligent cockpit middleware automated testing system is also applicable to the intelligent cockpit middleware automated testing method of this embodiment, and will not be repeated here.

[0086] According to the automated testing method for intelligent cockpit middleware proposed in the embodiment of the present application, a cloud-based test module is used to receive a target test scenario and interfaces of multiple middleware to be tested, and interface orchestration and test data are configured for the interfaces of multiple middleware to be tested based on the target test scenario. A current test task is generated for each middleware to be tested based on a series-parallel hybrid strategy of the orchestrated interface, test data and preset task dependencies, and the current test task is published to the cabin-side test module. Test results of multiple middleware to be tested based on the current test task of the cabin-side test module are received and processed, and a test report is generated based on the test results. The cabin-side test module is used to control multiple middleware to be tested to execute the current test task according to the current test task issued by the cloud-based test module, and the test results are uploaded to the cloud-based test module. This solves the problems of traditional cockpit middleware automation testing solutions, such as a single test scenario, a large number of scripts during full-function testing, low execution efficiency on a single device, and the need to use multiple devices for parallel execution. It can achieve rich cockpit middleware interface test scenarios, making the middleware interface test scenarios closer to actual driving scenarios, and can more accurately reflect the problems that actual users may encounter when using the system, improving test efficiency and coverage, without the need to add more devices to complete full-scenario testing.

[0087] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0088] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0089] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0090] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer program product for use with an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purposes of this specification, a "computer program product" can be any device that can contain, store, communicate, propagate or transmit a program for use with an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer program products (a non-exhaustive list) include the following: an electrical connection with one or N wirings (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). Furthermore, the computer program product may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example by optically scanning the paper or other medium and then editing, interpreting or, if necessary, processing in another suitable manner, and then storing it in a computer memory.

[0091] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0092] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer program product, which, when executed, includes one or a combination of the steps of the method embodiment.

[0093] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer program product.

[0094] The computer program product mentioned above may be a read-only memory, a disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. An intelligent cockpit middleware automated testing system, characterized in that: include: A cloud test module and a cabin test module, wherein the cabin test module includes a plurality of middlewares to be tested, and the cloud test module establishes a communication connection with the cabin test module. The cloud-side test module is used to receive a target test scenario and interfaces of multiple middleware to be tested, perform interface orchestration and configure test data for the interfaces of the multiple middleware to be tested based on the target test scenario, generate a current test task for each middleware to be tested according to a series-parallel hybrid strategy of the orchestrated interface, the test data and preset task dependencies, publish the current test task to the cabin-side test module, receive and process test results of the multiple middleware to be tested of the cabin-side test module based on the current test task, and generate a test report based on the test results; The cabin-side test module is used to control the multiple middlewares to be tested to execute the current test task according to the current test task issued by the cloud-side test module, and upload the test results to the cloud-side test module.

2. The system according to claim 1, characterized in that The cabin end test module comprises: A monitoring unit, used to monitor and receive the current test task issued by the cloud test module; A task parsing unit, used to parse the current test task and obtain a task execution strategy list; A task scheduling unit, configured to allocate current test tasks to the plurality of middlewares to be tested based on the task execution strategy list; An execution unit, used for controlling the plurality of middlewares to be tested to execute the current test task; The collecting unit is used to collect the performance data, test logs and test results of the plurality of middlewares to be tested when executing the current test task.

3. The system according to claim 1, characterized in that The cloud testing module includes: An importing unit, used for importing the target test scenario and the interfaces of the plurality of middlewares to be tested; A configuration unit, configured to perform interface arrangement and configure test data for the interfaces of the plurality of middlewares to be tested based on the target test scenario; A task planning unit, used to generate a current test task according to a series-parallel hybrid strategy of the arranged interface, the test data and the preset task dependency; The test release unit is used to release the current test task to the cabin end test module when a preset trigger time is reached.

4. The system according to claim 2, characterized in that The cloud testing module further includes: The analyzing unit is used to receive the performance data, test logs and test results collected by the collecting unit, and generate a test report for the plurality of middlewares to be tested.

5. The system according to claim 4, characterized in that The cloud testing module further includes: A display unit is connected to the analysis unit and is used to display test reports of the plurality of middlewares to be tested.

6. The system according to claim 4, characterized in that The cloud testing module further includes: An alarm unit is connected to the analysis unit and is used for making an acoustic alarm and / or an optical alarm when the test result of the middleware to be tested is a failure result.

7. The system according to claim 1, characterized in that The interfaces of the multiple middlewares to be tested are java interfaces.

8. An automated testing method for intelligent cockpit middleware, characterized in that: The intelligent cockpit middleware automated testing system according to any one of claims 1 to 7 comprises: Utilize the cloud test module to receive the target test scenario and the interfaces of multiple middleware to be tested, perform interface orchestration and configure test data for the interfaces of the multiple middleware to be tested based on the target test scenario, generate the current test task of each middleware to be tested according to the series-parallel hybrid strategy of the orchestrated interface, the test data and the preset task dependency, publish the current test task to the cabin-end test module, receive and process the test results of the multiple middleware to be tested of the cabin-end test module based on the current test task, and generate a test report based on the test results; The cabin-side test module controls the multiple middlewares to be tested to execute the current test task according to the current test task issued by the cloud-side test module, and uploads the test result to the cloud-side test module.

9. The method according to claim 8, characterized in that Before using the cabin-side test module to control the plurality of to-be-tested middlewares to execute the current test task according to the current test task issued by the cloud-side test module, the method includes: Check whether the current test task depends on the test result of the previous test task; If the current test task depends on the test result of the previous test task, the current test task is executed after the test result of the previous test task is a success result. If the test result of the previous test task is a failure result, the current test task continues to be executed.

10. The method according to claim 8, characterized in that When the series-parallel hybrid strategy based on the preset task dependency is used to control the plurality of middlewares to be tested to execute the current test task, it also includes: Monitoring whether the test scenario to be tested is missing when the multiple middlewares to be tested execute the current test task; If the test scenario to be tested is missing, the current test task is terminated and adjusted, and after the adjustment is completed, the multiple middlewares to be tested are re-controlled to execute the adjusted current test task.

Images