Intelligent cockpit voice visible can say automation test method and system

Abstract

The application discloses a kind of intelligent cockpit voice visible can say automation test method and system, belong to automobile technical field, comprising: according to voice visible can say use scene and write test case;Test case is generated robot file and resource file by Python script, and the voice parameter required in resource file is configured in test scene;Judge whether the execution visible can say test case is dynamic name;Tactics, voice configuration parameter is input into speech synthesis model to generate wav audio file;Audio file is played by acoustic dummy-artificial mouth;Vehicle machine log and RF script assertion are grabbed by ADB command, and the vehicle machine log and RF script assertion are compared and verified;Test report is automatically generated by RF framework.The method designs test set according to visible can say use scene and process, can improve the coverage of test case, simulates intelligent cockpit user real use scene to the greatest extent.

Description

Technical Field

[0001] This invention belongs to the field of automotive technology, specifically relating to an automated testing method and system for intelligent cockpit voice recognition that allows users to speak directly. Background Technology

[0002] Currently, the "see-and-talk" functionality in smart cockpits is widely used, and a complete "see-and-talk" system can cover all usage scenarios of the in-vehicle system, significantly improving the user experience. However, automated testing of in-vehicle "see-and-talk" systems is rare, with most tests relying on manual execution. The lack of a complete automated testing solution leads to low testing efficiency, especially when the data is highly generalized and there are complex voice scenarios requiring specific timbre and noise levels. Furthermore, for dynamic names obtained from interfaces on the in-vehicle system, such as artist names, album names, and music titles, there is currently no automated testing for this scenario. Due to the efficiency limitations of manual testing, "see-and-talk" tests can only be selectively executed for this scenario, resulting in low test coverage when performed manually. Summary of the Invention

[0003] To address the problems of low testing efficiency, high time and manpower consumption, insufficient scenario coverage, and difficulty in simulating complex scenarios in existing technologies, this invention provides an automated testing method and system for intelligent cockpit voice control that allows users to speak as soon as they see it. By designing test sets according to the usage scenarios and processes of "seeing and speaking as soon as they see it," the coverage of test cases can be improved, simulating real-world usage scenarios of intelligent cockpit users to the greatest extent possible.

[0004] This invention is achieved through the following technical solution:

[0005] An automated testing method for intelligent cockpit voice recognition, which includes the following steps:

[0006] Step 1: Write test cases based on the "voice visible, speakable" use case;

[0007] Step 2: Before testing, connect the vehicle's infotainment system via USB and enable the system's ADB debugging mode;

[0008] Step 3: Generate robot and resource files from the test cases using a Python script, and configure the voice parameters required for the test scenario in the resource file;

[0009] Step 4: Determine whether the test case has a dynamic name (i.e., the name is visible upon execution).

[0010] If so, import it into the OCR model to generate a text file, filter it, and then generate the script.

[0011] If not, proceed directly to step five;

[0012] Step 5: Input the speech script from Step 4 and the voice configuration parameters from Step 3 into the speech synthesis model to generate a WAV audio file;

[0013] Step Six: Play the produced WAV audio file through an acoustic dummy – an artificial mouth;

[0014] Step 7: During the audio playback process, the vehicle system logs and RF script assertions are captured using ADB commands, and the vehicle system logs and RF script assertions are compared and verified.

[0015] If the vehicle log is the same as the RF script assertion, the test case passes.

[0016] If the vehicle logs differ from the assertions in the RF script, the test case fails.

[0017] Step 8: The test report is automatically generated by the RF framework.

[0018] Furthermore, the test cases are in EXCEL format, and the test case set is written into the robot file and resource file using Python's xlwings module.

[0019] Furthermore, during the process of writing the test case set into the robot file and resource file by the xlwings module of Python, the Python script identifies the dynamic name scripts obtained from the interface in the visible scripts in the resource file, and marks the test scenarios on the test scripts in the robot file to facilitate selective execution of multiple rounds of testing.

[0020] Furthermore, in step four, the process of importing the text file into the OCR model, filtering it, and then generating the script specifically includes the following:

[0021] If it is a dynamic name, the screen is captured by the Android ADB command `screecap`, downloaded to the local machine using the `pull` command, and then imported into the OCR model. The OCR model is PP-OCRv3. After the model outputs text, it is filtered and can be used as a dynamic name phrase for testing. This filtering process is completed by a Python script, which mainly filters out other recognized text.

[0022] On the other hand, the present invention provides an automated testing system for intelligent cockpits that allows for visible and spoken voice communication, comprising:

[0023] The test case writing module is used to write test cases based on the use case of "voice visible and speakable".

[0024] The configuration module is used to generate robot and resource files via Python scripts, and configure the voice parameters required for the test scenario in the resource file;

[0025] The judgment module is used to determine whether the executed test case has a dynamic name;

[0026] The speech synthesis module is used to generate WAV audio files from the speech script and voice configuration parameters;

[0027] The playback module is used to play the produced WAV audio file through an acoustic dummy – an artificial mouth;

[0028] The execution module is used to capture vehicle logs and RF script assertions via ADB commands during the playback of the audio file, and to compare and verify the vehicle logs and RF script assertions.

[0029] The RF framework is used to automatically generate test reports.

[0030] Furthermore, the RF framework consists of a robot file and a resource file. The robot file is used to store test scripts, and the resource file is used to store voice configuration, visible-to-speak scripts, test assertions, and encapsulated keywords.

[0031] Compared with the prior art, the advantages of the present invention are as follows:

[0032] (1) This invention uses the Robot Framework automated testing framework, or RF framework for short, for automated testing. This framework is written in Python and can quickly and easily modify the visible and speakable corpus configuration file. Test sets can be quickly generated into RF scripts using Python scripts;

[0033] (2) This invention selectively executes test sets for different scenarios through the built-in tagging mechanism of RF;

[0034] (3) This invention uses speech synthesis technology to generate audio corpus of various scenarios with different speech speeds, timbres, pitches, volumes, and background noise through configuration files, and plays it through an acoustic dummy such as an artificial mouth to improve testing efficiency and realize speech visibility and speech test in complex scenarios.

[0035] (4) This invention can quickly identify dynamic names on the vehicle's infotainment system using OCR technology, and then generate test corpus;

[0036] (5) This invention compares and verifies the execution data visible in the vehicle log with the assertions in the RF script. If they match, it passes; if they do not match, it fails. The RF framework can automatically generate a test report after the test is completed.

[0037] (6) The present invention only requires manual design and writing of test cases, and then inputting the test cases to complete the visible and speakable test execution, saving a lot of time and labor costs. Attached Figure Description

[0038] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0039] Figure 1 This is a flowchart illustrating an automated testing method for intelligent cockpit voice recognition based on the present invention.

[0040] Figure 2 This is a system block diagram of an intelligent cockpit voice-activated automated testing system according to the present invention.

[0041] Figure 3 This is a comparison chart of experimental results using the testing method of the present invention and existing technologies. Detailed Implementation

[0042] To clearly and completely describe the technical solution and its specific working process of the present invention, the specific embodiments of the present invention are as follows, in conjunction with the accompanying drawings:

[0043] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0044] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0045] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0046] Example 1

[0047] like Figure 1 As shown in the figure, this embodiment provides an automated testing method for intelligent cockpit voice recognition, which includes the following steps:

[0048] Step 1: Write test cases based on the "voice visible, speakable" use case;

[0049] Step 2: Before testing, connect the vehicle's infotainment system via USB and enable the system's ADB debugging mode;

[0050] Step 3: Generate robot and resource files from the test cases using a Python script, and configure the voice parameters required for the test scenario in the resource file;

[0051] Step 4: Determine whether the test case has a dynamic name, i.e., whether the execution is visible.

[0052] If so, import it into the OCR model to generate a text file, filter it, and then generate the script.

[0053] If not, proceed directly to step five;

[0054] Step 5: Input the speech script from Step 4 and the voice configuration parameters from Step 3 into the speech synthesis model to generate a WAV audio file;

[0055] Step Six: Play the produced WAV audio file through an acoustic dummy – an artificial mouth;

[0056] Step 7: During the audio playback process, the vehicle system logs and RF script assertions are captured using ADB commands, and the vehicle system logs and RF script assertions are compared and verified.

[0057] If the vehicle log is the same as the RF script assertion, the test case passes.

[0058] If the vehicle logs differ from the assertions in the RF script, the test case fails.

[0059] Step 8: The test report is automatically generated by the RF framework.

[0060] In this embodiment, the test cases are in Excel format. The test case set, including assertions and statements, can be written into the robot file and resource file using Python's xlwings module. xlwings is a mature and excellent Python library for manipulating Excel files; it is simple and convenient to use and has powerful functionality. During the writing process, the Python script identifies dynamically named statements obtained from the interface in the statements visible in the resource file, and adds test scenarios to the test scripts in the robot file, facilitating selective execution of multiple rounds of testing.

[0061] In this embodiment, during the process of writing the test case set into the robot file and the resource file by the xlwings module of Python, the Python script identifies the dynamic name scripts obtained by the interface in the visible scripts in the resource file, and marks the test scenarios on the test scripts in the robot file to facilitate the selective execution of multiple rounds of testing.

[0062] In this embodiment, step four, which involves importing the text file into the OCR model, filtering it, and then generating the script, specifically includes the following:

[0063] If it is a dynamic name, the screen is captured by the Android ADB command `screecap`, downloaded to the local machine using the `pull` command, and then imported into the OCR model. The OCR model is PP-OCRv3. After the model outputs text, it is filtered and can be used as a dynamic name phrase for testing. This filtering process is completed by a Python script, which mainly filters out other recognized text.

[0064] Example 2

[0065] This embodiment provides an automated testing method for intelligent cockpit voice recognition, which includes the following steps:

[0066] Before testing, the system needs to be connected to the vehicle's infotainment system via USB and the ADB debugging mode needs to be enabled. When the automated script starts executing, it first checks the dialogue identifier in the resource file. If it's a dynamic name dialogue, it uses the Android ADB command `screecap` to take a screenshot of the vehicle's infotainment system, downloads it locally using the `pull` command, and imports the screenshot into the OCR model. This invention uses the PP-OCRv3 OCR engine, which is specifically designed for learning and training Chinese. After the model outputs text, it is filtered before being used as a dynamic name dialogue for testing. This filtering process is completed by a Python script, mainly filtering out other recognized text.

[0067] By encapsulating keywords in the RF framework, speech configuration and test scripts can be imported into the speech synthesis module, which is implemented by the PP-TTS model. The PP-TTS model is an open-source streaming speech synthesis system that performs well in Chinese scenarios such as tone sandhi and polyphonic characters. It can input Chinese text into the model to obtain WAV audio files with different timbres, pitches, speech rates, and background noise.

[0068] After the audio is played through the artificial mouth, the logs from the vehicle's infotainment system are collected using the ADB command logcat. The visible execution information in the vehicle's logs is then compared with the assertions in the RF script for verification. If they match, the test passes; otherwise, it fails. The RF framework can automatically generate a test report after the test is completed.

[0069] Example 3

[0070] like Figure 2 As shown, this embodiment provides an automated testing system for intelligent cockpits that allows for visible and spoken voice communication, including:

[0071] The test case writing module is used to write test cases based on the use case of "voice visible and speakable".

[0072] The configuration module is used to generate robot and resource files via Python scripts, and configure the voice parameters required for the test scenario in the resource file;

[0073] The judgment module is used to determine whether the executed test case has a dynamic name;

[0074] The speech synthesis module is used to generate WAV audio files from the speech script and voice configuration parameters;

[0075] The playback module is used to play the produced WAV audio file through an acoustic dummy – an artificial mouth;

[0076] The execution module is used to capture vehicle logs and RF script assertions via ADB commands during the playback of the audio file, and to compare and verify the vehicle logs and RF script assertions.

[0077] The RF framework is used to automatically generate test reports.

[0078] In this embodiment, the RF framework consists of a robot file and a resource file. The robot file stores test scripts, while the resource file stores voice configuration, visible speech scripts, test assertions, and encapsulated keywords. If it is necessary to change the visible speech scripts and voice configuration during testing, only the resource file needs to be modified.

[0079] The preferred embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the specific details of the above embodiments. Within the scope of the technical concept of the present invention, various simple modifications can be made to the technical solution of the present invention, and these simple modifications all fall within the protection scope of the present invention.

[0080] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable way without contradiction. In order to avoid unnecessary repetition, the present invention will not describe the various possible combinations separately.

[0081] Furthermore, various different embodiments of the present invention can be combined in any way, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed by the present invention.

Claims

1. An automated testing method for intelligent cockpits that allows for visible and spoken voice communication, characterized in that: Specifically, the steps include the following: Step 1: Write test cases based on the "voice visible, speakable" use case; Step 2: Before testing, connect the vehicle's infotainment system via USB and enable the system's ADB debugging mode; Step 3: Generate robot and resource files from the test cases using a Python script, and configure the voice parameters required for the test scenario in the resource file; Step 4: Determine whether the test case has a dynamic name (i.e., the name is visible upon execution). If so, import it into the OCR model to generate a text file, filter it, and then generate the script. If not, proceed directly to step five; Step 5: Input the speech script from Step 4 and the voice configuration parameters from Step 3 into the speech synthesis model to generate a WAV audio file; Step Six: Play the generated WAV audio file through an acoustic dummy – an artificial mouth; Step 7: During the playback of the audio file, capture the vehicle system logs and RF script assertions using ADB commands, and compare and verify the vehicle system logs and RF script assertions; If the vehicle log is the same as the RF script assertion, the test case passes. If the vehicle logs differ from the assertions in the RF script, the test case fails. Step 8: The test report is automatically generated by the RF framework.

2. The automated testing method for intelligent cockpit voice recognition as described in claim 1, characterized in that, The test cases are in EXCEL format, and the test case set is written into the robot file and resource file using the xlwings module of Python.

3. The automated testing method for intelligent cockpit voice recognition as described in claim 1, characterized in that, During the process of writing the test case set into the robot file and resource file using the xlwings module of Python, the Python script identifies the dynamic name messages obtained from the interface in the visible messages in the resource file, and marks the test scenarios on the test scripts in the robot file to facilitate selective execution of multiple rounds of testing.

4. The automated testing method for intelligent cockpit voice recognition as described in claim 1, characterized in that, Step four, which involves importing the text file into the OCR model, filtering it, and then generating the script, specifically includes the following: If it is a dynamic name, the screen is captured by the Android ADB command `screecap`, downloaded to the local machine using the `pull` command, and then imported into the OCR model. The OCR model is PP-OCRv3. After the model outputs text, it is filtered and can be used as a dynamic name phrase for testing. This filtering process is completed by a Python script, which mainly filters out other recognized text.

5. An automated testing system for intelligent cockpits that allows for visible and spoken voice communication, used to implement the method described in any one of claims 1-4, characterized in that, include: The test case writing module is used to write test cases based on the use case of "voice visible and speakable". The configuration module is used to generate robot and resource files via Python scripts, and configure the voice parameters required for the test scenario in the resource file; The judgment module is used to determine whether the executed test case has a dynamic name; The speech synthesis module is used to generate WAV audio files from the speech script and voice configuration parameters; The playback module is used to play the generated WAV audio file through an acoustic dummy – an artificial mouth; The execution module is used to capture vehicle logs and RF script assertions via ADB commands during the playback of the audio file, and to compare and verify the vehicle logs and RF script assertions. The RF framework is used to automatically generate test reports.

6. The intelligent cockpit voice-activated automated testing system as described in claim 5, characterized in that, The RF framework consists of a robot file and a resource file. The robot file stores test scripts, while the resource file stores voice configuration, visible-to-speak scripts, test assertions, and encapsulated keywords.

Images