Visible-to-speak short link test method, device, equipment and medium
By embedding a data acquisition switch into the vehicle's infotainment system, information about the interface components is obtained and voice test commands are generated in the cloud. This solves the problem of long testing cycles for the "see-and-say" function and enables efficient automated testing and dynamic content coverage.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-09
- Publication Date
- 2026-03-24
AI Technical Summary
The existing "see and say" functionality has a long testing cycle and poor adaptability to dynamic content. It requires manual writing of test cases and relies on hardware devices, resulting in low efficiency.
By embedding a data acquisition switch into the vehicle's infotainment system, the system can directly obtain the type information and entity word information of the interface components, generate voice test commands using preset generalization rules, and perform matching and verification in the cloud, thus building a short-link test architecture and reducing reliance on hardware devices.
It achieves full automation of test cases, shortens testing time, improves testing efficiency, reduces dependence on dedicated hardware, and enhances the coverage of dynamic content.
Smart Images
Figure CN121725818A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle voice function testing technology, specifically to a short-link testing method, apparatus, equipment, and medium that allows for both visibility and speech. Background Technology
[0002] With the increasing popularity of smart cockpits, the "see and speak" function has become one of the core features for improving driving safety and interaction efficiency. This function allows users to operate directly by speaking the text or control names displayed on the screen. To ensure the accuracy of this function in various complex interfaces and dynamic content scenarios, it is essential to conduct automated testing of this function.
[0003] Current "see-and-say" functionality typically requires testers to manually write a large number of test cases beforehand, convert them into executable test scripts, and then play synthesized speech using hardware devices such as acoustic dummies to complete the end-to-end verification in a real vehicle infotainment environment. Finally, the test results are judged by capturing and analyzing system logs. However, this method has a lengthy verification chain, involving multiple stages such as hardware playback, vehicle infotainment system response, and log capture. The execution time of a single test case can be as long as tens of seconds, resulting in low testing efficiency and strong dependence on dedicated hardware devices. Summary of the Invention
[0004] This application provides a method, apparatus, device, and medium for testing short links that can be seen and said, which can solve the technical problems of long testing cycles and poor adaptability to dynamic content in the prior art.
[0005] In a first aspect, embodiments of this application provide a method for testing short links that are visible and indicative of shortness of link performance, the method comprising: Obtain the type information and entity word information of all interactive components in the current vehicle infotainment interface; Based on the type information of each interactive component, multiple voice test commands and the expected results corresponding to each voice test command are generated for each interactive component through preset generalization rules; Each voice test command is matched with the entity word information, and the matching results are verified according to the type information to obtain the matching result of each voice test command. The expected result and the corresponding matching result for each voice test command are compared to generate a test verification conclusion.
[0006] In conjunction with the first aspect, in one implementation, obtaining the type information and entity word information of all interactive components in the current vehicle infotainment interface includes: Set the data acquisition switch in the debug mode of the vehicle infotainment system page framework; Activate the data acquisition switch via ADB command or interface call; In response to the activation of the data acquisition switch, the vehicle system traverses the current vehicle interface view tree and extracts the type information and entity word information of all interactive components in the current vehicle interface.
[0007] In conjunction with the first aspect, in one implementation, after the vehicle system responds to the activation of the data acquisition switch, traverses the current vehicle interface view tree, and extracts the type information and entity word information of all interactive components in the current vehicle interface, the process includes: Export a structured file in JSON format containing type information and entity word information of all interactive components in the current vehicle infotainment interface; The structured file uses the page function modules in the current vehicle infotainment interface as keys and the array of interactive components as keys. The type information includes Tab, Switch, Button, Checkbox, and Slider. The entity word information is the readable text labels of all interactive components displayed on the current vehicle infotainment interface.
[0008] In conjunction with the first aspect, in one implementation, the step of generating multiple voice test commands and the expected result corresponding to each voice test command for each interactive component based on the type information of each interactive component and through preset generalization rules includes: The set of sentence templates corresponding to the type information of each interactive component is obtained by means of a preset generalization rule. The preset generalization rule includes the mapping relationship between type information and sentence template set. Substitute the entity word information of each interactive component into the corresponding sentence template set of each interactive component to generate multiple candidate voice test commands; The candidate voice test commands are deduplicated and prioritized to obtain the final voice test command set; Generate the expected result for each voice test command. The expected result includes at least the identifier of the interactive component corresponding to the voice test command and the expected operation corresponding to the voice test command.
[0009] In conjunction with the first aspect, in one implementation, matching each voice test instruction with the entity word information includes: Submit all voice test commands and entity word information to the cloud-based "Speak Now" service; The cloud-based "Visible and Speakable" service converts the voice test commands into text commands and extracts keywords from the text commands. Calculate the similarity between the keywords and each entity word; Based on similarity ranking, at least one entity word is selected as a candidate matching result.
[0010] In conjunction with the first aspect, in one implementation, the step of verifying the matching results based on the type information to obtain the matching result for each voice test command includes: The operation type corresponding to the user's intent is parsed from the voice test command; The parsed operation type is compared with the type information of the interactive component corresponding to the candidate matching result; Determine whether the type information of the interactive component supports the parsed operation type. If yes, the candidate matching result passes the verification and is used as the final matching result. If no, the verification fails and the candidate matching result is discarded. The matching results include at least the identifier of the interactive component corresponding to the voice test command.
[0011] In conjunction with the first aspect, in one implementation, comparing the expected result and the corresponding matching result for each voice test command to generate a test verification conclusion includes: The identifiers of interactive components in the expected results corresponding to each voice test command are compared with the identifiers of interactive components in the matching results corresponding to each voice test command. A consistency score between the matching result and the expected result is calculated based on the comparison results. The consistency score is compared with a preset threshold to generate a verification result for the voice test instruction based on the comparison result.
[0012] Secondly, embodiments of this application provide a visible-to-say short link testing device, the visible-to-say short link testing device comprising: The acquisition module is used to acquire the type information and entity word information of all interactive components in the current vehicle infotainment interface; The generation module is used to generate multiple voice test commands and the expected results for each voice test command for each interactive component based on the type information of each interactive component and through preset generalization rules. The matching module is used to match each voice test command with the entity word information, and to verify the matching results according to the type information to obtain the matching result of each voice test command. The testing module compares the expected result and the corresponding matching result for each voice test command to generate test verification conclusions.
[0013] Thirdly, embodiments of this application provide a visible and describable short link testing device, which includes a processor, a memory, and a visible and describable short link testing program stored in the memory and executable by the processor. When the visible and describable short link testing program is executed by the processor, it implements the steps of the visible and describable short link testing method as described in any of the above embodiments.
[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a visible-and-say short link test program, wherein when the visible-and-say short link test program is executed by a processor, it implements the steps of the visible-and-say short link test method as described in any of the above embodiments.
[0015] The beneficial effects of the technical solutions provided in this application include: This application embodiment achieves full automation of test case design by directly acquiring structured data of interface components from the vehicle's infotainment system and automatically generating diverse test instructions and assertions based on component types and entity words. This eliminates the cost of manually writing and maintaining test cases and enables dynamic content coverage. This application embodiment also constructs a short-link verification architecture by converging the entire verification chain from "acoustic hardware-vehicle infotainment system-logs" to the input and output of the "cloud-visible and speakable module." By directly calling cloud interfaces for verification, the execution time of a single test case is shortened, significantly improving test execution efficiency and reducing dependence on and occupation of dedicated hardware devices. Attached Figure Description
[0016] Figure 1 This is a flowchart illustrating the short link testing method that can be described as visible in this application; Figure 2 This is a schematic diagram of the functional modules of the short-link test device as can be seen in this application; Figure 3 This is a schematic diagram of the hardware structure of the visible and ineffable short link test device involved in the embodiments of this application. Detailed Implementation
[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0019] This application provides a method, apparatus, device, and medium for testing short links that can be seen and said, which can solve the technical problems of long testing cycles and poor adaptability to dynamic content in the prior art.
[0020] Firstly, embodiments of this application provide a method for testing short links that are visible and describable.
[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the short-link testing method described in this application. Figure 1 As shown, the short link testing method includes the following steps: Step S1: Obtain the type information and entity word information of all interactive components in the current vehicle infotainment interface.
[0022] In this embodiment of the application, step S1 specifically includes the following steps: Step S11: Set the data acquisition switch in the debug mode of the vehicle infotainment system page frame.
[0023] Specifically, what can be seen and spoken, also known as a voice-activated touchscreen, refers to the ability to control current page elements via voice commands on devices with smart screens, such as car infotainment systems. During the car infotainment system software development phase, developers embed an externally triggerable data acquisition switch into the debug module of the car infotainment operating system or application framework. This data acquisition switch is essentially a piece of program logic that can be remotely triggered, enabling the system to output the current state information of its internal car infotainment interface component tree. This allows for direct data acquisition from within the car infotainment system, ensuring the accuracy of component information and avoiding recognition errors that may be introduced by technologies such as Optical Character Recognition (OCR). Furthermore, since the data acquisition switch is embedded during the development phase for testing purposes, it allows for early intervention of testing requirements, avoiding the repetitive work of testers independently developing data parsing modules later.
[0024] Step S12: Activate the data acquisition switch via ADB command or interface call.
[0025] Specifically, during the test execution phase, the test script or test platform activates the data acquisition switch set in step S11 via external commands. Specific commands or broadcast intents can be sent to the vehicle's infotainment system via the Android Debug Bridge (ADB) to trigger the system's debugging service to perform data acquisition. Alternatively, the data acquisition function can be directly invoked through the inter-process communication (IPC) interface provided by the vehicle's infotainment system. This allows the test execution end to remotely control data acquisition on the vehicle's infotainment system, facilitating execution in complex continuous integration environments.
[0026] Step S13: In response to the activation of the data acquisition switch, the vehicle system traverses the current vehicle interface view tree and extracts the type information and entity word information of all interactive components in the current vehicle interface.
[0027] Specifically, when the data acquisition switch is activated, the vehicle system recursively traverses the entire vehicle interface view hierarchy, starting from the root view of the currently active window. For each view node encountered, the system checks its attributes to determine whether it is an interactive component (such as buttons, switches, sliders, tabs, etc., excluding purely decorative views). For interactive components, its type information and entity information are extracted.
[0028] Type information refers to the class name or type identifier of the interactive component, which defines the basic behavioral paradigm of the interactive component. Entity information refers to the core text label or content description displayed on the interactive component, which is the object that the user refers to by voice in the "see and speak" function.
[0029] In this embodiment of the application, after step S13, the following steps are also included: Export a structured file in JSON format containing type information and entity word information of all interactive components in the current vehicle infotainment interface.
[0030] The structured file uses the page function modules in the current vehicle infotainment interface as keys and the array of interactive components as keys and values. The type information includes Tab, Switch, Button, Checkbox, and Slider, and the entity word information is the readable text labels of all interactive components displayed on the current vehicle infotainment interface.
[0031] Specifically, the extracted type and entity information of all interactive components are organized into a structured data format (such as JSON or XML) and returned. This structured data typically reflects the hierarchy or grouping relationship of the interactive components. Key names represent an independent functional area or module, usually corresponding to a visually or logically aggregated group of controls, such as "Exterior Lighting Settings," "Air Conditioning Control Area," or "Media Playback Control Bar." Key values are an array containing all interactive component objects belonging to that functional module, with each interactive component object describing its own properties. When searching for or verifying components in a specific functional area, the relevant component array can be accessed directly through the key name, eliminating the need to traverse the entire flattened list, thus improving data access and processing efficiency.
[0032] In the type information, Tab or Button indicates an instantaneous action, Switch or Checkbox indicates a binary on / off or selected / unselected state, and Slider indicates a numerical selection within a continuous range. Entity words are directly taken from the text seen by the user, enabling the generated voice test commands to realistically simulate user behavior and verify the correctness of the function from the user's perspective.
[0033] In one specific embodiment, assuming the current vehicle infotainment interface is the vehicle lighting settings page, the test script sends a command via ADB to activate the data acquisition switch. The vehicle infotainment system traverses this settings page and finds four interactive components: a radio button group containing three radio buttons with text labels "Off," "Low Beam," and "Automatic Headlights," and a Switch component (i.e., on / off function) with the text label "Rear Alignment Lights." The vehicle infotainment system generates a JSON file, and the test engine parses the JSON file, generating commands such as "Turn on Rear Alignment Lights" and "Rear Alignment Lights On" for Switch type components, and "Switch to Low Beam" for Tab type components.
[0034] Step S2: Based on the type information of each interactive component, generate multiple voice test commands and the expected results corresponding to each voice test command for each interactive component through preset generalization rules.
[0035] In this embodiment of the application, step S2 specifically includes the following steps: Step S21: Obtain the set of sentence templates corresponding to the type information of each interactive component through preset generalization rules. The preset generalization rules include the mapping relationship between type information and sentence template set.
[0036] Specifically, the preset generalization rules use the type information of the interactive component as an index, associating a set of sentence templates with each type. Each sentence template is a string containing placeholders that describes a common spoken expression pattern when users interact with this type of component. For example, for the Switch type, its sentence template set may include: open {entity word}, enable {entity word}, open open {entity word}, {entity word} open, {entity word} enable, {entity word} open open. For the Tab type, it generates direct expression test instructions containing "switch to {entity word}", "select {entity word}", and omitting the verb. The preset generalization rules can generate standard expressions, colloquial variations, and dialect expressions to ensure that test cases cover common expressions used by real users.
[0037] Step S22: Substitute the entity word information of each interactive component into the corresponding sentence template set of each interactive component to generate multiple candidate voice test commands.
[0038] Specifically, for each interactive component, the vehicle system sequentially substitutes its entity word information into the placeholders of each sentence template corresponding to that interactive component obtained in step S21 to generate multiple complete voice command texts. For example, for the Switch component with the entity word "rear taillight", substituting "turn on {entity word}" generates the specific voice test command "turn on rear taillight". By combining the same entity word with multiple different sentence templates, the system can simulate the diverse expression habits of different users in different contexts, thereby more comprehensively testing the generalization ability of the voice recognition system.
[0039] Step S23: Deduplicate and prioritize the candidate voice test commands to obtain the final voice test command set.
[0040] Specifically, since different components may have the same entity words, or the same entity word may generate semantically similar instructions under different templates, all candidate voice test instructions are deduplicated to ensure the uniqueness of each voice test instruction in the set. Subsequently, priority ranking is performed, based on the instruction's syntactic complexity, frequency of occurrence in real user corpora, effectiveness in discovering potential defects, or cost of test execution. High-priority instructions are ultimately selected to form the set of voice test instructions for actual execution. Deduplication avoids the repeated execution of identical instructions, saving computational and verification resources. Prioritization ensures that limited testing time is used to execute the scenarios most likely to expose problems or the most critical scenarios, maximizing test utility.
[0041] Step S24: Generate the expected result for each voice test command. The expected result includes at least the identifier of the interactive component corresponding to the voice test command and the expected operation corresponding to the voice test command.
[0042] Specifically, the expected result is a data structure generated synchronously with each voice test command, used to describe the correct execution result of the voice test command. The identifier of the interactive component is the unique representation of the source interactive component on which the voice test command is based. The expected action is the user intent action parsed from the sentence template that generated the voice test command. Thus, the expected result is determined at the time of test generation, avoiding the subjectivity and inconsistency that may arise from manual verification or dynamic judgment, ensuring the reliability of the test results. Furthermore, when the test fails, directly comparing the actual returned result with the pre-generated expected result allows for rapid problem location, greatly improving troubleshooting efficiency.
[0043] Step S3: Match each voice test command with entity word information, and verify the matching results according to the type information to obtain the matching result of each voice test command.
[0044] In this embodiment of the application, step S3, matching each voice test instruction with entity word information, specifically includes the following steps: Step S301: Submit all voice test commands and entity word information to the cloud-based "Visible and Speakable" service.
[0045] Specifically, all test tasks are submitted to a unified cloud service endpoint for processing, ensuring the consistency of the test execution environment, eliminating interference caused by differences in vehicle hardware or system status, and making the test results more comparable and repeatable.
[0046] Step S302: The cloud-based visible and speakable service converts voice test commands into text commands and extracts keywords from the text commands.
[0047] Specifically, the cloud-based "See and Speak" service utilizes technologies such as word segmentation, part-of-speech tagging, and named entity recognition to identify and extract keywords from the command text. Keywords typically include operation words (such as "open" and "switch to") and target object words (such as "rear vehicle indicator light" and "air conditioner"). By extracting keywords, irrelevant information such as interjections or modifiers in the voice test commands is filtered out, reducing noise interference with subsequent similarity calculations and making the matching process more accurate.
[0048] Step S303: Calculate the similarity between the keywords and each entity word information.
[0049] Specifically, the similarity algorithm can use a string edit distance algorithm to calculate glyph similarity, a word vector model to calculate semantic similarity, and then weighted and fused the glyph and semantic similarity to obtain a comprehensive similarity score. The string edit distance algorithm can use the Levenshtein distance algorithm, and the word vector model can use models such as Word2Vec and BERT.
[0050] Step S304: Based on similarity ranking, select at least one entity word as a candidate matching result.
[0051] Specifically, all entity words are sorted in descending order according to their similarity scores with keywords. One or more entity words with the highest rankings are selected as candidate matching results from the sorted list. The entity word with the highest score can be selected as the primary candidate matching result, or all entity words with similarity scores exceeding a preset threshold can be selected as the candidate set. Sorting and selecting candidate matching results transforms the similarity calculation into a clear candidate list, indicating the interface elements that the cloud-based "visible and speakable" service believes are most likely to be the user's intended meaning.
[0052] In this embodiment of the application, step S3, which verifies the matching result based on the type information to obtain the matching result for each voice test command, specifically includes the following steps: Step S311: Parse the operation type corresponding to the user's intent from the voice test command.
[0053] Specifically, it identifies the operation type corresponding to the operands in the keywords. For example, words like "open," "start," and "open briefly" in voice test commands may be uniformly mapped to the standardized operation type "open." By uniformly converting diverse verb expressions from different users and with different speaking habits into operation commands that the machine can process accurately, the variability in natural language is eliminated.
[0054] Step S312: Compare the parsed operation type with the type information of the interactive component corresponding to the candidate matching result.
[0055] Specifically, the vehicle infotainment system predefines a component type-supported operation mapping table. This table defines all standardized operations supported by each type of component in the vehicle infotainment interaction model. For example, the Switch type supports on / off operations, and the Button type supports click or press operations. This ensures that user-issued commands are executable on the target component, preventing situations where a voice test command like "turn up the air conditioning temperature" is matched to a Switch component that only supports on / off operations and not adjustment.
[0056] Step S313: Determine whether the type information of the interactive component supports the parsed operation type. If yes, the candidate matching result passes the verification and is used as the final matching result. If no, the verification fails and the candidate matching result is discarded.
[0057] The matching results include at least the identifier of the interactive component corresponding to the voice test command.
[0058] Specifically, if the parsed operation type belongs to one of the operation sets supported by the component type information, it is determined to be supported, and the candidate result passes the logical rationality check. Otherwise, it is determined to be unsupported, and the candidate result is considered an invalid match and discarded. If a command has multiple candidate matching results, the system usually iterates through all candidates and selects the result with the highest similarity that passes the check as the final matching result. Outputting a matching result containing a valid component identifier means that the result can be directly used to drive subsequent tests to trigger actual interface operations, completing a closed-loop mapping from voice commands to precise interaction targets.
[0059] Step S4: Compare the expected result and the corresponding matching result for each voice test command to generate a test verification conclusion.
[0060] In this embodiment of the application, step S4 specifically includes the following steps: Step S41: Compare the identifier of the interactive component in the expected result corresponding to each voice test command with the identifier of the interactive component in the matching result corresponding to each voice test command.
[0061] Specifically, the comparison operation involves a precise equality check of two strings, thereby verifying whether the cloud service has correctly associated the voice command with the intended target interactive component. Deterministic comparison based on explicit identifiers eliminates subjective judgment differences, visual errors, or fatigue factors that may exist in manual verification, ensuring consistent verification results for the same input at all times.
[0062] Step S42: Calculate the consistency score between the matching result and the expected result based on the comparison results.
[0063] Specifically, a binary rating model can be used to calculate the score; if the identifiers match, the score is 1, and if they do not match, the score is 0.
[0064] Step S43: Compare the consistency score with a preset threshold to generate a verification result for the voice test instruction based on the comparison result.
[0065] Specifically, consecutive consistency scores are mapped to readable verification conclusions. For example, a preset threshold of 0.9 can be set. If the consistency score is greater than or equal to 0.9, a verification result of "pass" is generated; if it is less than 0.9, a verification result of "fail" is generated. The preset threshold can be dynamically configured according to the rigor of the test type. For binary scores, the threshold is typically set to 0.5. This verification result represents the final state of a single test instruction. After the threshold is determined, a test report is automatically generated, eliminating the need for manual result processing and thus shortening the testing cycle.
[0066] This application embodiment achieves full automation of test case design by directly acquiring structured data of interface components from the vehicle's infotainment system and automatically generating diverse test instructions and assertions based on component types and entity words. This eliminates the cost of manually writing and maintaining test cases and enables dynamic content coverage. This application embodiment also constructs a short-link verification architecture by converging the entire verification chain from "acoustic hardware-vehicle infotainment system-logs" to the input and output of the "cloud-visible and speakable module." By directly calling cloud interfaces for verification, the execution time of a single test case is shortened, significantly improving test execution efficiency and reducing dependence on and occupation of dedicated hardware equipment.
[0067] Secondly, embodiments of this application also provide a visible-to-talk short link testing device.
[0068] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the functional modules of the short-link test device as described in this application. Figure 2 As shown, it can be said that the short link testing device includes: The acquisition module is used to acquire the type information and entity word information of all interactive components in the current vehicle infotainment interface; The generation module is used to generate multiple voice test commands and the expected results for each voice test command for each interactive component based on the type information of each interactive component and through preset generalization rules. The matching module is used to match each voice test command with entity word information and to verify the matching results according to the type information to obtain the matching result of each voice test command. The testing module compares the expected result and the corresponding matching result for each voice test command to generate test verification conclusions.
[0069] The functions of each module in the above-mentioned visible and describable short link test device correspond to the steps in the above-mentioned visible and describable short link test method embodiment, and their functions and implementation processes will not be described in detail here.
[0070] Thirdly, embodiments of this application provide a visible and describable short link testing device, which includes a processor, a memory, and a visible and describable short link testing program stored in the memory and executable by the processor. When the visible and describable short link testing program is executed by the processor, it implements the steps of the visible and describable short link testing method as described in any of the above embodiments.
[0071] It can be seen that short-link testing equipment can be personal computers (PCs), laptops, servers, or other devices with data processing capabilities.
[0072] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of the visible-and-say short link test device involved in the embodiments of this application. In the embodiments of this application, the visible-and-say short link test device may include a processor, a memory, a communication interface, and a communication bus.
[0073] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.
[0074] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting components within the visible-and-say-short-link test equipment, as well as interfaces used for interconnecting the visible-and-say-short-link test equipment with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.
[0075] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.
[0076] The processor can be a general-purpose processor, which can call the visible-and-say short link test program stored in memory and execute the visible-and-say short link test method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the visible-and-say short link test program is called can be referred to in the various embodiments of the visible-and-say short link test method of this application, and will not be repeated here.
[0077] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0078] Fourthly, embodiments of this application provide a computer-readable storage medium storing a visible-and-say short link test program, wherein when the visible-and-say short link test program is executed by a processor, it implements the steps of the visible-and-say short link test method as described in any of the above embodiments.
[0079] The present application provides a computer-readable storage medium storing a visible and describable short link test program, wherein when the visible and describable short link test program is executed by a processor, it implements the steps of the visible and describable short link test method as described above.
[0080] The method implemented when the visible-to-say short link test program is executed can be referred to in various embodiments of the visible-to-say short link test method of this application, and will not be repeated here.
[0081] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0082] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.
[0083] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.
[0084] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.
[0085] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.
[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.
[0087] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.
Claims
1. A short-link testing method that is visible and describable, characterized in that, The aforementioned short-link testing method includes: Obtain the type information and entity word information of all interactive components in the current vehicle infotainment interface; Based on the type information of each interactive component, multiple voice test commands and the expected results corresponding to each voice test command are generated for each interactive component through preset generalization rules; Each voice test command is matched with the entity word information, and the matching results are verified according to the type information to obtain the matching result of each voice test command. The expected result and the corresponding matching result for each voice test command are compared to generate a test verification conclusion.
2. The short link testing method according to claim 1, characterized in that, The step of obtaining the type information and entity word information of all interactive components in the current vehicle infotainment interface includes: Set the data acquisition switch in the debug mode of the vehicle infotainment system page framework; Activate the data acquisition switch via ADB command or interface call; In response to the activation of the data acquisition switch, the vehicle system traverses the current vehicle interface view tree and extracts the type information and entity word information of all interactive components in the current vehicle interface.
3. The short link testing method according to claim 2, characterized in that, After the vehicle infotainment system responds to the activation of the data acquisition switch, it traverses the current vehicle infotainment interface view tree, extracts the type information and entity word information of all interactive components in the current vehicle infotainment interface, including: Export a structured file in JSON format containing type information and entity word information of all interactive components in the current vehicle infotainment interface; The structured file uses the page function modules in the current vehicle infotainment interface as keys and the array of interactive components as keys. The type information includes Tab, Switch, Button, Checkbox, and Slider. The entity word information is the readable text labels of all interactive components displayed on the current vehicle infotainment interface.
4. The short link testing method according to claim 1, characterized in that, Based on the type information of each interactive component, multiple voice test commands and the expected results corresponding to each voice test command are generated for each interactive component through preset generalization rules, including: The set of sentence templates corresponding to the type information of each interactive component is obtained by means of a preset generalization rule. The preset generalization rule includes the mapping relationship between type information and sentence template set. Substitute the entity word information of each interactive component into the corresponding sentence template set of each interactive component to generate multiple candidate voice test commands; The candidate voice test commands are deduplicated and prioritized to obtain the final voice test command set; Generate the expected result for each voice test command. The expected result includes at least the identifier of the interactive component corresponding to the voice test command and the expected operation corresponding to the voice test command.
5. The short link testing method according to claim 4, characterized in that, The step of matching each voice test instruction with the entity word information includes: Submit all voice test commands and entity word information to the cloud-based "Speak Now" service; The cloud-based "Visible and Speakable" service converts the voice test commands into text commands and extracts keywords from the text commands. Calculate the similarity between the keywords and each entity word; Based on similarity ranking, at least one entity word is selected as a candidate matching result.
6. The short link testing method according to claim 5, characterized in that, The step of verifying the matching results based on the type information to obtain the matching result for each voice test command includes: The operation type corresponding to the user's intent is parsed from the voice test command; The parsed operation type is compared with the type information of the interactive component corresponding to the candidate matching result; Determine whether the type information of the interactive component supports the parsed operation type. If yes, the candidate matching result passes the verification and is used as the final matching result. If no, the verification fails and the candidate matching result is discarded. The matching results include at least the identifier of the interactive component corresponding to the voice test command.
7. The short link testing method according to claim 6, characterized in that, The step of comparing the expected result and the corresponding matching result for each voice test command to generate a test verification conclusion includes: The identifiers of interactive components in the expected results corresponding to each voice test command are compared with the identifiers of interactive components in the matching results corresponding to each voice test command. A consistency score between the matching result and the expected result is calculated based on the comparison results. The consistency score is compared with a preset threshold to generate a verification result for the voice test instruction based on the comparison result.
8. A short-link testing device that allows for immediate assessment of short links, characterized in that, The visible, or in other words, short-link testing device includes: The acquisition module is used to acquire the type information and entity word information of all interactive components in the current vehicle infotainment interface; The generation module is used to generate multiple voice test commands and the expected results for each voice test command for each interactive component based on the type information of each interactive component and through preset generalization rules. The matching module is used to match each voice test command with the entity word information, and to verify the matching results according to the type information to obtain the matching result of each voice test command. The testing module compares the expected result and the corresponding matching result for each voice test command to generate test verification conclusions.
9. A short-link testing device that allows for immediate assessment of short links, characterized in that: The visible and describable short link test device includes a processor, a memory, and a visible and describable short link test program stored in the memory and executable by the processor, wherein when the visible and describable short link test program is executed by the processor, it implements the steps of the visible and describable short link test method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a visible and describable short link test program, wherein when the visible and describable short link test program is executed by a processor, it implements the steps of the visible and describable short link test method as described in any one of claims 1 to 7.