Test method and device of vehicle-mounted audio system, electronic equipment and storage medium
By building a test architecture and multiple test databases, dynamically generate test cases and conducting multi-threaded parallel testing, the problem that existing vehicle audio system testing methods cannot meet diverse needs is solved, and automated full measurement and efficient testing of vehicle audio systems are realized.
Patent Information
- Application Number
- CN202411878987.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-19
- Publication Date
- 2025-03-25
AI Technical Summary
The testing methods of existing in-vehicle audio systems cannot meet the diverse development and testing needs, resulting in long testing time, high energy consumption, and it is difficult to achieve automated testing based on human ears.
By building a test architecture based on the functional modules of the vehicle audio system, multiple test databases are established, each functional module corresponds to a test database, dynamically generates test cases, and through multi-threaded parallel testing, the similarity between the test audio and the input audio of the microphone is calculated, and the test results are automatically determined.
It realizes automated full measurement of the on-board audio system, reduces dependence on personnel, improves testing efficiency and accuracy, and can meet diverse development and testing needs.
Smart Images
Figure CN119690844A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of automated testing, and in particular to a testing method, device, electronic equipment and storage medium for a vehicle audio system. Background Art
[0002] Audio function is a must-have function for the smart cockpit of the vehicle system. The vehicle audio system has many channel levels and complex policy configuration. It requires multiple people to collaborate on development at the same time and multiple people to test for a long time. The current testing tools generally use fixed test cases to test the functions one by one. This cannot meet the diverse development and testing needs and will have an adverse impact on the stability of the vehicle audio: 1. If the audio software developer adds or modifies channels, a single test cannot rule out the impact on other channels; 2. Sound effect developers adjust the sound effects. If fixed test cases are used, they need to repeatedly develop test applications. 3. If the tester conducts full-function testing on the modification, testing each item one by one will consume a lot of time and energy; 4. Current audio testing relies on human hearing, making it difficult to achieve automation without human supervision; 5. There are many in-car audio scenarios, and it is difficult to cover multiple scenarios with audio conflicts through one-by-one and single testing; 6. There are many levels in the audio path. If the waveforms are not compared layer by layer, the problem cannot be located quickly. Summary of the invention
[0003] In view of the above technical problems, the present invention provides a test method, device, electronic equipment and storage medium for a vehicle audio system, which can realize automatic full measurement of the vehicle audio system.
[0004] A first aspect of the present invention provides a method for testing a vehicle audio system, comprising: Building a test framework based on the functional modules of the vehicle audio system, and establishing a plurality of test databases according to the test framework, so that each functional module corresponds to one test database, and the test database includes test variables corresponding to the functional module; Dynamically generate test cases corresponding to the functional modules based on the test database, and instantiate the test cases to test each functional module and capture the test audio transferred by each functional module within a test cycle based on the test architecture, wherein the test cases correspond to the functional modules one by one; The similarity between the test audio and the audio input by the microphone is calculated, a test result is determined according to the similarity, and record information is generated according to the test result.
[0005] In a possible implementation, establishing multiple test databases according to the test architecture so that each functional module corresponds to one test database includes: Variables of each functional module are extracted, and multiple test databases are established based on the test architecture and the values of the variables; each test database includes test entries generated based on the test variables, and multiple test entries constitute an ArrayList list.
[0006] In a possible implementation, instantiating the test case within a test cycle based on the test architecture to test each of the functional modules includes: Randomly generate an index value for the test case of each functional module based on the index of the ArrayList; A separate test thread is used to execute the test case of each functional module according to the index value.
[0007] In a possible implementation, calculating the similarity between the test audio and the audio input by a microphone includes: Calculating the similarity between the test audio and the audio input by the microphone based on the pure data algorithm; The test architecture includes an application architecture layer, an audio service layer, a hardware abstraction layer, and a digital signal processor.
[0008] In a possible implementation manner, determining a test result according to the similarity includes: The test is successful if the similarity between the audio used in the test case and the test audio transferred from the application architecture layer is more than 90%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the audio service layer is more than 70%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the hardware abstraction layer is more than 70%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the digital signal processor is more than 50%.
[0009] In a possible implementation, generating record information according to the test result includes: The test conditions, parameters, vehicle system status and test results of each test case are stored in an accessible storage space to form a test result database.
[0010] In a possible implementation, generating record information according to the test result includes: The test results are classified and stored according to the severity of the problem, and a corresponding test result database is formed according to the classification structure.
[0011] A second aspect of the present invention provides a testing device for a vehicle audio system, comprising: A database module, used to construct a test framework based on the functional modules of the vehicle audio system, and to establish multiple test databases according to the test framework, so that each functional module corresponds to one test database, and the test database includes test variables corresponding to the functional module; A test module, configured to dynamically generate test cases corresponding to the functional modules based on the test database, instantiate the test cases within a test cycle based on the test architecture to test each of the functional modules and capture the test audio transferred by each of the functional modules, wherein the test cases correspond to the functional modules one by one; The calculation module is used to calculate the similarity between the test audio and the audio input by the microphone, determine the test result according to the similarity, and generate record information according to the test result.
[0012] According to a third aspect of the present invention, there is provided an electronic device, comprising: At least one processor; and at least one memory in communication with the processor, wherein: the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the vehicle audio system testing method as described in the first aspect of the embodiment of the present invention.
[0013] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a computer, the method for testing the vehicle audio system according to the first aspect of the embodiment of the present invention is executed.
[0014] The present invention establishes multiple test databases according to the test architecture, so that each functional module corresponds to a test database, which can realize personalized customization of test cases and meet diverse needs; multiple functional modules reduce dependence on personnel by automatically executing various test cases, and at the same time perform multi-threaded parallel testing, simulate real usage scenarios in multiple dimensions, and verify the processing capabilities of each high-concurrency audio module. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] Figure 1 The figure is a flow chart of a method for testing a vehicle audio system according to an embodiment of the present invention.
[0016] Figure 2 Schematic diagram of the working principle of the vehicle technology system in an embodiment of the present invention.
[0017] Figure 3 The block diagram is a test device for a vehicle audio system according to an embodiment of the present invention.
[0018] Figure 4FIG. 1 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION
[0019] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0020] It should be understood that the terms "first", "second", and "third" etc. in the claims, specifications, and drawings of the present disclosure are used to distinguish different objects rather than to describe a specific order. The terms "include" and "comprise" used in the specification and claims of the present disclosure indicate the presence of the described features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their collections. It should also be understood that the terms used in this disclosure specification are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure.
[0021] See also Figure 1 and Figure 2 The present invention provides a method for testing a vehicle audio system, which specifically includes the following steps.
[0022] Step 100: construct a test framework based on the functional modules of the vehicle audio system, and establish multiple test databases according to the test framework, so that each functional module corresponds to one test database, and the test database includes test variables corresponding to the functional module.
[0023] In some embodiments, the test architecture includes an application architecture layer, an audio service layer, a hardware abstraction layer, and a digital signal processor. The present invention uses a customized test case strategy to implement rights testing of the application architecture layer, the audio service layer, the hardware abstraction layer, and the digital signal processor.
[0024] Specifically, the various functions of the audio may be decomposed to obtain multiple sub-functions, and then the test data may be constructed according to the multiple sub-functions. For example, the test data may include the following functional modules.
[0025] a) Audio dynamic routing module test: It tests the process of the application dynamically obtaining the audio bus.
[0026] b) Audio static routing module test: It tests the process of the application statically obtaining the audio bus.
[0027] c) Audio focus management strategy module test: It tests the process of the application applying for focus, releasing focus and losing focus.
[0028] d) Audio parameter module test: It is to test the parameter setting and acquisition process of the application sound effects.
[0029] e) Volume management module test: mainly tests the process of application setting and obtaining volume and volume range f) System sound module test: It is necessary to test the process of using system prompt sound by the application g) Mediaplayer module test: mainly tests the audio formats supported by the system's default player and the audio effects of playback.
[0030] h) AudioTrack module test: mainly tests the system's support for the number of channels, sampling frequency and number of bits per sample of PCM (pulse code modulation) audio data.
[0031] i) Audio Input Module Testing: It is the process of testing the application to capture audio.
[0032] Based on the test requirements, a test database corresponding to the functional modules of the vehicle audio system can be established according to the above sub-functions. Therefore, the test database includes an audio dynamic routing test library, an audio static routing test library, an audio focus management strategy test library, an audio parameter test library, a volume management test library, a system sound test library, a Mediaplayer test library, an AudioTrack test library, and an audio input test library.
[0033] Each test database includes test cases consisting of test variables. Variables of each functional module are extracted, and then multiple test databases are established based on the test architecture and the values of the variables. For example, the variables of audio dynamic routing are usage attributes (usage) and audio files (audioFile) with guided decisions. The value of the usage attribute is determined by the number and usage of the audio bus, and is generally determined by the vehicle system, such as between 0 and 20.
[0034] The variables of static routing are the address of the audio bus, audio files (audioFiles), and channel masks (channelMasks). The variables of audio focus management are mainly: focus id (usage is generally an integer number, and the range is determined by the number of focuses in the audio system); the rule for delaying audio focus requests (delayed), whether it can be delayed (generally true or false); the audio ducking rule (paused), whether to lower the volume or stop playing (generally true or false); audio files (audioFile); The variables of audio parameters are generally set to the audio system in the form of key and value, which are all strings. The function items that can be set are distinguished by key and the attributes of individual function items are distinguished by value. The variables of volume management are mainly volume groups and audio files. The variables of system sound test mainly include the system id (index), and the value is generally determined according to the index of system sound. MediaPlayer player test mainly tests the system's encapsulation format (type) of audio files (name) AudioTrack test, the variables are mainly for the number of channels supported by audiotrack, sampling frequency and the number of bits per sample. The variables of audio input are mainly the audio input source id, the number of channels of the audio input source, and the data format of the audio input source.
[0035] This step uses the test architecture to ensure that each functional module has its own database, ensuring the independence of the functional modules and the independence of the functional modules from each other. By automatically executing each test case, the dependence on personnel is reduced.
[0036] Step 200: Dynamically generate test cases corresponding to the functional modules based on the test database, and instantiate the test cases within a test cycle based on the test architecture to test each of the functional modules and capture the test audio transferred by each of the functional modules, wherein the test cases correspond one-to-one to the functional modules.
[0037] In this step, a test case list is generated based on the test case. In the present invention, each functional module has a test class, and each instance of the test class of each module corresponds to an XML file. Testers can customize test items according to the variables of each functional module. Personalized test cases can meet diverse needs. Each test database includes multiple test items generated based on the test variables, one test item corresponds to an instance of a test case class, each instance of the test case class has an index, and multiple test case classes form an ArrayList list.
[0038] In this step, the test program first instantiates the class (test case) corresponding to the functional module being tested and generates a test instance. The test instance obtains the test case in the xml file and converts it into a test instance through the test case class. The variable information of the test case is assigned to the test instance, and all test instances are saved in an ArrayList to form a list.
[0039] like Figure 2As shown, each of the above-mentioned functional modules (module 1 to module n) corresponds to a different test database. A test case list can be generated by accessing the storage area through a test case generator. The automated test program automatically and randomly runs the test cases. The application architecture layer, audio service layer, hardware abstraction layer, and digital signal processor in the test architecture respectively obtain their own transferred test audio.
[0040] For example, the application framework layer intercepts the audio data written to the audio system by the test application. The AudioTrack.cpp in the native framework layer can obtain all the data written to the audio system by the application and save them to the pcm file in the data partition. The file name is named according to the number of channels, sampling frequency, bits per sample and session id.
[0041] The audio service layer (audioflinger) will intercept the audio data generated by the audio mixer. Threads.cpp in audioflinger can intercept the mixed physical audio stream mSinkBuffer and write the audio data in mSinkBuffer to the pcm file in the data partition. The file name is named according to the number of channels, sampling frequency, bits per sample and audio bus address.
[0042] The hardware abstraction layer can intercept data written to the device node and store the data in the pcm file in the data partition. The file name is named according to the number of channels, sampling frequency, number of bits per sample and pcm device node id.
[0043] DSP (digital signal processor) audio interception can be achieved by using the echo reference input mechanism provided by the ODM manufacturer. The test application captures the echo reference input's returned audio data and saves it to the data partition pcm file. The file name is named according to the number of channels, sampling frequency, bits per sample and DSP. Generally, AudioRecord can be used directly to capture audio data.
[0044] Step 300: Calculate the similarity between the test audio and the audio input by the microphone, determine a test result according to the similarity, and generate record information according to the test result.
[0045] In some embodiments, the similarity between the test audio and the audio input by the microphone is calculated based on a pure data algorithm. Of course, those skilled in the art may adopt other algorithms for calculating audio similarity based on this heuristic.
[0046] As an application embodiment, the test is successful if the similarity between the audio used in the test case and the test audio transferred from the application architecture layer is more than 90%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the audio service layer is more than 70%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the hardware abstraction layer is more than 70%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the digital signal processor is more than 50%.
[0047] Of course, the value of the similarity can be adjusted and is not used to limit the present invention. The present invention avoids dependence on human ears by comparing audio similarity.
[0048] During the test cycle of a test case, the test result is determined based on the similarity comparison. If the similarity does not meet the requirements, it is necessary to capture the system log and record the test scene. For example, the test conditions, parameters, vehicle system status and test results of each test case are stored in an accessible storage space to form a test result database. The present invention captures the data of the test scene in real time to avoid the omission of important information.
[0049] Furthermore, the test results are classified and stored according to the severity of the problem, and a corresponding test result database is formed according to the classification structure.
[0050] For example, if a serious error level or above occurs during the test, such as continuous blasting sound, complete vehicle silence, etc., the test needs to be stopped, the system status needs to be recorded, the scene needs to be saved, and a warning needs to be issued. After the automated test is turned on, it will only be stopped by human intervention or when an error of a serious level or above occurs. Otherwise, it will continue to execute and the test results will be recorded in the result database.
[0051] In the present invention, after the automated test is turned on, each test case is randomly tested, each functional module can be tested in parallel, and each test case within the module can be tested in parallel. Multi-line parallel testing simulates real usage scenarios in multiple dimensions and verifies the processing capabilities of each high-concurrency audio module. Based on this, the present invention can implement full-function limit testing and critical testing to ensure the perfection and stability of the audio subsystem.
[0052] When the automated testing program randomly and automatically runs the test cases, in some embodiments, an index value is randomly generated for the test case of each functional module based on the index of the ArrayList; and a separate test thread is used to execute the test case of each functional module according to the index value.
[0053] The present invention automatically and randomly runs test cases based on the ArrayList list of the test cases. The test program starts the automatic test, and each functional module enables a polling thread. The java.util.Random class provided by Java is used to generate a random number within the list index range of the test case. The functional module of the test will execute the test case according to the random number, and each test case has an index, and the index value corresponding to the random number. The test program executes the test case in a separate test thread. In the process of executing the test case, the test thread determines the execution status according to the information returned by the audio system. If it is determined to be a failure, the case test ends, the test result is returned, and the test result of the test instance in the test list is updated. If it is determined to be successful, the data storage and display will continue to be executed. The present invention reduces the dependence on personnel by automatically executing each test case.
[0054] See also Figure 3 The present invention also provides a testing device for a vehicle audio system, comprising: a database module 31 , a testing module 32 , and a computing module 33 .
[0055] The database module 31 is used to construct a test architecture based on the functional modules of the vehicle audio system, and to establish multiple test databases according to the test architecture, so that each functional module corresponds to a test database, and the test database includes test variables corresponding to the functional module.
[0056] The test module 32 is used to dynamically generate test cases corresponding to the functional modules based on the test database, and to instantiate the test cases within a test cycle based on the test architecture to test each of the functional modules and capture the test audio transferred by each of the functional modules, wherein the test cases correspond to the functional modules one by one.
[0057] The calculation module 33 is used to calculate the similarity between the test audio and the audio input by the microphone, determine the test result according to the similarity, and generate record information according to the test result.
[0058] For the description of the testing device for the vehicle audio system, reference may be made to the above-mentioned testing method for the vehicle audio system, which will not be described in detail.
[0059] An embodiment of the present invention further discloses a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the vehicle audio system testing method described in any one of the above embodiments.
[0060] like Figure 4 As shown, an embodiment of the present invention further discloses an electronic device, including: At least one processor; and at least one memory in communication with the processor, wherein: the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the steps of the above-mentioned vehicle audio system testing method.
[0061] It can be understood that computer-readable storage media may include: any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. A computer program includes a computer program code. The computer program code may be in source code form, object code form, an executable file, or some intermediate form, etc. A computer-readable storage medium may include: any entity or device capable of carrying a computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.
[0062] In certain embodiments of the present invention, the electronic device may include a controller or a processor, and the controller is a single-chip microcomputer chip that integrates a processor, a memory, a communication module, etc. The processor may refer to a processor included in the controller. The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.
[0063] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention 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 the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present invention belong.
[0064] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.
[0065] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for testing a vehicle audio system, characterized in that: include: Building a test framework based on the functional modules of the vehicle audio system, and establishing a plurality of test databases according to the test framework, so that each functional module corresponds to one test database, and the test database includes test variables corresponding to the functional module; Dynamically generate test cases corresponding to the functional modules based on the test database, and instantiate the test cases to test each functional module and capture the test audio transferred by each functional module within a test cycle based on the test architecture, wherein the test cases correspond to the functional modules one by one; The similarity between the test audio and the audio input by the microphone is calculated, a test result is determined according to the similarity, and record information is generated according to the test result.
2. The test of the vehicle audio system according to claim 1, characterized in that: The step of establishing a plurality of test databases according to the test architecture so that each of the functional modules corresponds to one test database includes: Variables of each functional module are extracted, and multiple test databases are established based on the test architecture and the values of the variables; each test database includes test entries generated based on the test variables, and multiple test entries constitute an ArrayList list.
3. The test of the vehicle audio system according to claim 2, characterized in that: The instantiation of the test case in a test cycle based on the test architecture for testing each of the functional modules includes: Randomly generate an index value for the test case of each functional module based on the index of the ArrayList; A separate test thread is used to execute the test case of each functional module according to the index value.
4. The test of the vehicle audio system according to claim 1, characterized in that: The calculating the similarity between the test audio and the audio input by the microphone comprises: Calculate the similarity between the test audio and the audio input by the microphone based on the pure data algorithm; The test architecture includes an application architecture layer, an audio service layer, a hardware abstraction layer, and a digital signal processor.
5. The test of the vehicle audio system according to claim 4, characterized in that: Determining the test result according to the similarity includes: The test is successful if the similarity between the audio used in the test case and the test audio transferred from the application architecture layer is more than 90%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the audio service layer is more than 70%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the hardware abstraction layer is more than 70%; the test is successful if the similarity between the audio used in the test case and the test audio transferred from the digital signal processor is more than 50%.
6. The test of the vehicle audio system according to claim 1, characterized in that: The generating of record information according to the test result includes: The test conditions, parameters, vehicle system status and test results of each test case are stored in an accessible storage space to form a test result database.
7. The test of the vehicle audio system according to claim 6, characterized in that: The generating of record information according to the test result includes: The test results are classified and stored according to the severity of the problem, and a corresponding test result database is formed according to the classification structure.
8. A test device for a vehicle audio system, characterized in that: include: A database module, used to construct a test framework based on the functional modules of the vehicle audio system, and to establish multiple test databases according to the test framework, so that each functional module corresponds to one test database, and the test database includes test variables corresponding to the functional module; A test module, configured to dynamically generate test cases corresponding to the functional modules based on the test database, instantiate the test cases within a test cycle based on the test architecture to test each of the functional modules and capture the test audio transferred by each of the functional modules, wherein the test cases correspond to the functional modules one by one; The calculation module is used to calculate the similarity between the test audio and the audio input by the microphone, determine the test result according to the similarity, and generate record information according to the test result.
9. An electronic device, characterized in that: include: at least one processor; and at least one memory communicatively connected to the processor, wherein: the memory stores program instructions executable by the processor, and the processor calls the program instructions to execute the vehicle audio system testing method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a computer, the method for testing the vehicle audio system according to any one of claims 1 to 7 is executed.