Intelligent cabin test method and system, electronic device and storage medium

Abstract

The application discloses an intelligent cockpit test method and system, an electronic device and a storage medium. The method comprises the following steps: obtaining a test case file, wherein the test case file comprises at least one target test case; obtaining test data corresponding to the target test case; generating at least one event anchor point based on the test data, and determining the type of the target test case based on the test data; generating a test report of the intelligent cockpit based on the type of the target test case, the test data and the at least one event anchor point; wherein the event anchor point is used to identify the occurrence node of a target event in the test data. The application improves the vehicle test efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to a smart cockpit testing method, system, electronic device and storage medium. Background Technology

[0002] With the development of intelligent, connected, and software-defined vehicles, the functions integrated into intelligent cockpit systems are becoming increasingly complex, involving multiple functions such as in-vehicle applications, display control, voice interaction, and network communication. These functions are typically accomplished by multiple software modules, controllers, and communication links. During real-vehicle testing, if a problem occurs, developers often need to conduct a comprehensive analysis combining test procedures, test information, and the operational paths before and after the problem occurred. Currently, real-vehicle testing of intelligent cockpits still suffers from problems such as inaccurate fault localization, inappropriate log extraction scope, scattered key evidence, lack of causal correlation between evidence and evidence, and incomplete reproduction information, resulting in low efficiency in anomaly investigation and vehicle testing. Summary of the Invention

[0003] This application provides at least one intelligent cockpit testing method, system, electronic device, and storage medium.

[0004] This application provides a method for testing a smart cockpit, comprising: acquiring a test case file, the test case file including at least one target test case; acquiring test data corresponding to the target test case; generating at least one event anchor point based on the test data, and determining the type of the target test case based on the test data; generating a test report of the smart cockpit based on the type of the target test case, the test data, and the at least one event anchor point; wherein the event anchor point is used to identify the occurrence node of a target event in the test data.

[0005] In some embodiments, generating a test report for the smart cockpit based on the type of the target test case, the test data, and the plurality of event anchors includes: in response to the target test case being of an exception type, extracting target data from the test data based on the event anchors to generate a structured record of the target event; and obtaining a fault reproduction data packet based on the structured record to generate a test report for the smart cockpit.

[0006] In some embodiments, the target test cases for the anomaly types include at least one of the following: page response anomaly test cases, in which the page fails to complete the redirection within a preset time; vehicle control execution anomaly test cases, in which the vehicle status signal does not change within a preset time after the vehicle control command is issued, or the vehicle control receipt fails to return; display anomaly test cases, in which the instrument panel screen does not refresh synchronously when the data signal changes, or the displayed content is inconsistent with the expected result; crash anomaly test cases, in which the application process exits, the page is black, white, or unresponsive; and network anomaly test cases, in which request timeouts, interface failures, network disconnections, weak network switching, or page loading failures occur.

[0007] In some embodiments, generating at least one event anchor point based on the test data includes: generating the event anchor point corresponding to the target event in response to the presence of the target event in the test data; wherein the target event includes at least one of user operation, screen change, vehicle signal change, log anomaly, and network anomaly.

[0008] In some embodiments, generating at least one event anchor based on the test data further includes: associating the at least one event anchor with the test data, wherein the test data and the at least one event anchor use a unified timestamp.

[0009] In some embodiments, the event anchor includes at least one of the following information: event number, event type, event trigger time, associated test case, associated test step, associated data source, event description, and evidence index.

[0010] In some embodiments, the event anchors include at least one of the following types: a test case start anchor, used to indicate that the target test case has started execution; a step start anchor, used to indicate that a step in the target test case has started execution; a user operation anchor, used to indicate that a click, swipe, voice input, key operation, or vehicle control operation has occurred; a screen change anchor, used to indicate that a page jump, pop-up, black screen, white screen, lag, crash, control state change, or page element change has been detected; a signal change anchor, used to indicate that a change in vehicle signals has been detected, including window, air conditioning, seat, instrument panel, volume, door, gear, vehicle speed, and power status; a log anomaly anchor, used to indicate that a system error log, application crash log, interface call failure log, network anomaly log, or controller communication anomaly log has been detected; a network status change anchor, used to indicate that a network connection interruption, request timeout, interface failure, domain name system anomaly, weak network switching, or network recovery has been detected; a test case failure anchor, used to indicate that the target test case does not meet preset conditions; and a test case end anchor, used to indicate that the target test case has completed execution.

[0011] A second aspect of this application provides an intelligent cockpit testing system, comprising: a startup module configured to acquire a test case file, the test case file including at least one target test case; and a generation module configured to: acquire test data corresponding to the target test case; generate at least one event anchor point based on the test data, and determine the type of the target test case based on the test data; and generate a test report of the intelligent cockpit based on the type of the target test case, the test data, and the at least one event anchor point. The event anchor point is used to identify the occurrence node of the target event in the test data.

[0012] A third aspect of this application provides an electronic device including a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement the above-described smart cockpit testing method.

[0013] A fourth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the above-described intelligent cockpit testing method.

[0014] The beneficial effects of this application include: obtaining test case files, which include at least one target test case; obtaining test data corresponding to the target test case; generating at least one event anchor point based on the test data; determining the type of the target test case based on the test data, wherein the event anchor point is used to identify the occurrence node of the target event in the test data; and generating a test report for the intelligent cockpit based on the type of the target test case, the test data, and at least one event anchor point. By associating the evidence chain of the test process through event anchor points and generating a test report, problem data can be quickly located, and the anomaly reproduction information of the target test case can be made complete and standardized, thereby improving the efficiency of vehicle testing.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0017] Figure 1 This is a flowchart illustrating the intelligent cockpit testing method according to an embodiment of this application; Figure 2 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application; Figure 3This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application; Figure 4 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application; Figure 5 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of the intelligent cockpit testing system according to an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a non-volatile computer-readable storage medium according to an embodiment of this application. Detailed Implementation

[0018] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0019] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, "many" in this document means two or more. Additionally, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C. Furthermore, the terms "first," "second," and "third" in this application are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0020] During real-vehicle testing, if a problem occurs, developers often need to conduct a comprehensive analysis by combining test steps, in-vehicle infotainment screens, in-vehicle and out-of-vehicle videos, vehicle status signals, system logs, application logs, network status, and the operation path before and after the problem occurred. For example, current real-vehicle testing methods typically involve testers manually executing tests on a real vehicle according to test cases, manually recording the problem symptoms, capturing videos, retrieving logs, and creating problem tickets after discovering a problem. Among these issues, testers can typically only record the approximate time of the problem, making it difficult to accurately identify key operational nodes, screen change nodes, and vehicle signal change nodes before and after the problem occurs; logs are usually pulled as a whole according to the test start and end times, or extracted according to fixed time periods, which can easily lead to an excessively large log range, too much invalid information, and a lack of highlighting key logs; there is a lack of unified event-based correlation between vehicle screen recordings, camera videos, vehicle status signals, system logs, application logs, network status, and test steps, requiring developers to manually compare video times, log times, and test steps; the reproduction steps, actual phenomena, key evidence, and vehicle status in the problem report rely on manual entry, which can easily result in incomplete or non-standard descriptions, missing evidence, or inaccurate problem times; when reproducing the problem, developers often need to repeatedly confirm the operation path, vehicle status, software version, vehicle model configuration, and problem triggering conditions with testers, leading to low efficiency in problem localization and defect closure.

[0021] To address these issues, this application proposes a smart cockpit testing method, system, electronic device, and storage medium.

[0022] To enable those skilled in the art to better understand the technical solution of this application, the technical solution of this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] Please see Figure 1 , Figure 1 This is a flowchart illustrating the intelligent cockpit testing method according to an embodiment of this application. The subject executing this method can be an electronic device with computing capabilities, such as a microcomputer, a server, and mobile devices such as laptops and tablets.

[0024] It should be noted that if substantially the same result is obtained, the method of this application is not based on... Figure 1 The sequence of processes shown is limited.

[0025] In some possible implementations, this method can be implemented by the processor calling computer-readable instructions stored in memory, such as... Figure 1 As shown, the method may include the following steps: Step S11: Obtain the test case file, which includes at least one target test case.

[0026] Test case files can be guidelines for testing smart cockpits, including test interfaces, test steps, and judgment methods.

[0027] Obtain test case files, such as parsing the test case number, test case name, test object, test steps, expected results, associated vehicle signals, associated applications, observation methods, and exception types in the test case files, and generate at least one of the following in the test task context:

[0028] Step S12: Obtain the test data corresponding to the target test case.

[0029] The test data corresponding to the target test case can be data generated during the execution of the target test case, including at least one of the following: vehicle screen recording data, camera video data, vehicle status signals, system logs, application logs, and network status.

[0030] For example, select a target test case from the test case file to start testing, and initiate vehicle screen recording, camera video capture, vehicle status signal capture, system log capture, application log capture, and network status capture, thereby obtaining test data corresponding to the target test case.

[0031] Step S13: Generate at least one event anchor point based on the test data, and determine the type of the target test case based on the test data.

[0032] Event anchors are used to identify the occurrence nodes of target events in test data. For example, an event anchor can be generated at the occurrence node of the target event in the test data. Event anchors can be structured data units used to identify the occurrence nodes of key events during real vehicle testing.

[0033] At least one event anchor is generated based on the test data, and the type of the target test case is determined based on the test data. For example, during the execution of the target test case, a corresponding event anchor can be generated for each test operation performed, or a corresponding event anchor can be generated when an exception occurs. Furthermore, the type of the target test case is determined; the type of the target test case includes normal type and exception type.

[0034] Step S14: Generate a test report for the smart cockpit based on the type of the target test case, the test data, and at least one event anchor point.

[0035] By combining the type of the target test case, test data, and at least one event anchor point, a test report for the intelligent cockpit is generated. For example, if the target test case is of the exception type, test data related to at least one event anchor point is obtained, and a test report for the intelligent cockpit is generated. The test report may include test items, software version, test cases, pass rate, number of failed issues, and issue severity level, etc.

[0036] In this embodiment, a test case file is obtained, including at least one target test case. Test data corresponding to the target test case is obtained. At least one event anchor point is generated based on the test data, and the type of the target test case is determined based on the test data. The event anchor point is used to identify the occurrence node of the target event in the test data. Based on the type of the target test case, the test data, and at least one event anchor point, a test report for the intelligent cockpit is generated. By associating the evidence chain of the test process through event anchor points and generating a test report, problem data can be quickly located, and the anomaly reproduction information of the target test case is complete and standardized, thereby improving the efficiency of vehicle testing.

[0037] In some embodiments, generating at least one event anchor point based on test data includes: responding to the existence of a target event in the test data and generating an event anchor point corresponding to the target event; wherein the target event includes at least one of user operation, screen change, vehicle signal change, log anomaly, and network anomaly.

[0038] In one implementation, if there is a user operation in the response and test data, an event anchor point corresponding to the user operation is generated; and / or if there is a screen change in the response and test data, an event anchor point corresponding to the screen change is generated; and / or if there is a vehicle signal change in the response and test data, an event anchor point corresponding to the vehicle signal change is generated; and / or if there is a log anomaly in the response and test data, an event anchor point corresponding to the log anomaly is generated; and / or if there is a network anomaly in the response and test data, an event anchor point corresponding to the network anomaly is generated; and / or if there is an occasional anomaly in the response and test data, an event anchor point corresponding to the occasional anomaly is generated.

[0039] For example, a step start anchor is generated for each test step executed; when a click, swipe, voice input, key operation, or vehicle control operation is detected, the system generates a user operation anchor; when a page change, vehicle signal change, log anomaly, or network anomaly is detected, the system generates a corresponding screen change anchor, vehicle signal change anchor, log anomaly anchor, or network status change anchor.

[0040] In some embodiments, generating at least one event anchor based on test data further includes: associating the at least one event anchor with the test data, wherein the test data and the at least one event anchor use a unified timestamp.

[0041] After generating at least one event anchor point based on the test data, the event anchor point can be associated with the test data based on a unified timestamp. For example, based on the unified timestamp, various event anchor points can be synchronously associated with vehicle screen recordings, camera videos, vehicle status signals, system logs, application logs, network status, and key screenshots to form a chain of evidence for the test process.

[0042] In some embodiments, the types of event anchors include at least use case start anchors, step start anchors, user operation anchors, screen change anchors, signal change anchors, log exception anchors, network status change anchors, use case failure anchors, and use case end anchors.

[0043] The test case start anchor indicates the start of execution of the target test case. The step start anchor indicates the start of execution of a specific step within the target test case. User action anchors indicate clicks, swipes, voice input, button presses, or vehicle control operations. Screen change anchors indicate detected page jumps, pop-ups, black screens, white screens, lag, crashes, changes in control states, or changes in page elements. Signal change anchors indicate detected changes in vehicle signals such as windows, air conditioning, seats, instruments, volume, doors, gear position, speed, and power status. Log anomaly anchors indicate detected system error logs, application crash logs, API call failure logs, network anomaly logs, or controller communication anomaly logs. Network status change anchors indicate detected network connection interruptions, request timeouts, API failures, Domain Name System (DNS) anomalies, weak network switching, or network recovery. Test case failure anchors indicate that the target test case does not meet preset conditions. Test case end anchors indicate the completion of execution of the target test case.

[0044] Understandably, by using the aforementioned event anchors, the testing process can be transformed from recording a single time period into recording multiple key event nodes, making the process of the problem more traceable.

[0045] In some embodiments, the event anchor includes at least one of the following: event number, event type, event trigger time, associated test case, associated test step, associated data source, event description, and evidence index.

[0046] For example, if a target event exists in the response and test data, an event anchor point corresponding to the target event is generated. This event anchor point includes the target event number, target event type, target event trigger time, test case to which the target event belongs, test step to which the target event belongs, data source associated with the target event, target event description, and evidence index.

[0047] In some embodiments, a test report for the intelligent cockpit is generated based on the type of the target test case, test data, and multiple event anchors, including: in response to the target test case being of an exception type, extracting target data from the test data based on the event anchors to generate a structured record of the target event; and obtaining a fault reproduction data packet based on the structured record to generate a test report for the intelligent cockpit.

[0048] In one implementation, in response to the target test case being of an exception type, target data is extracted from the test data based on event anchors to generate a structured record of the target event. Further, based on the structured record, a fault reproduction data packet is obtained, thereby generating a test report for the smart cockpit.

[0049] In one implementation, in response to the target test case being of a normal type, a target test case can be retrieved from the test case file for testing.

[0050] The structured record can be a structured problem sheet, including the target test case, abnormal steps, expected results, actual results, abnormal event anchors, key evidence, and vehicle status snapshots. The fault reproduction data package includes the corresponding test steps, as well as test cases, abnormal steps, expected results, actual results, abnormal event anchors, key evidence, and vehicle status snapshots, i.e., a standardized, packaged dataset of the abnormal portion of the target test case.

[0051] For example, the target test case is identified as exception type A. Based on exception type A, log and video capture windows are determined, and key video clips, key log clips, vehicle status snapshots, key screenshots, and page status information before and after the exception occur are extracted from the evidence chain of the test process. Furthermore, based on the target test case, the exception step, expected result, actual result, exception event anchor point, key evidence, and vehicle status snapshot, a structured issue form is generated. Further, a reproduction data package associated with the structured issue form is generated, and the issue form, evidence chain, and reproduction data package are uploaded to the cloud testing platform. After the testing task is completed, a test report for the current smart cockpit can be generated based on information such as the test project, software version, test cases, pass rate, number of failed issues, and issue severity level.

[0052] In this embodiment, in response to the target test case being of an exception type, target data is extracted from the test data based on the event anchor point to generate a structured record of the target event. Based on the structured record, a fault reproduction data package is obtained, thereby generating a test report for the intelligent cockpit. This improves the efficiency of problem localization and defect closure, as well as ensuring the completeness of the reproduction steps and evidence.

[0053] In some embodiments, the target test cases for the exception type include at least one of page response exception test cases, vehicle control execution exception test cases, display exception test cases, crash exception test cases, and network exception test cases.

[0054] Among the various test cases, the following are considered: Page Response Anomaly Test Case: The page fails to redirect within a preset time. vehicle Control Execution Anomaly Test Case: After a vehicle control command is issued, the vehicle status signal does not change within a preset time, or the vehicle control receipt fails to return. Display Anomaly Test Case: When data signals change, the instrument panel does not refresh synchronously, or the displayed content is inconsistent with the expected result. Crash Anomaly Test Case: The application process exits, the page displays a black screen, a white screen, or is unresponsive. Network Anomaly Test Case: Request timeout, interface failure, network disconnection, weak network switching, or page loading failure.

[0055] In one implementation, taking the test case of "opening the vehicle infotainment system settings page and entering the Bluetooth settings interface" as an example, the abnormal page response test case is explained. When the settings entry is clicked, the system generates a user operation anchor point; when the vehicle infotainment system page begins to redirect, the system generates a vehicle infotainment system screen change anchor point; if the page does not complete the redirection within a preset time, the system generates a page response abnormality anchor point.

[0056] Based on the type of page response anomaly, the system automatically captures user operation anchor points, in-vehicle screen change anchor points, and in-vehicle screen recordings, key screenshots, application logs, system logs, page loading status, CPU usage, memory usage, and network status within a preset time range before and after the page response anomaly anchor points. Furthermore, based on the above evidence, a structured issue form is generated, with the actual result automatically filled in as "After clicking the settings entry, the page did not redirect within a preset time, remaining on the original interface or experiencing loading lag." Simultaneously, a reproduction data package containing the operation path, key video clips, page screenshots, application logs, and system logs is generated.

[0057] In one implementation, the test case of "closing the car window via the vehicle infotainment system" is used as an example to illustrate an abnormal vehicle control execution test case. When the window closing button is clicked, the system generates a user operation anchor point; when the vehicle infotainment system issues a vehicle control command, the system generates a control command anchor point; when the vehicle signal changes, the system generates a vehicle signal change anchor point. If it is detected that a vehicle control command has been issued but the window status signal has not changed within a preset time, or the vehicle control receipt fails to return, an abnormal vehicle control execution anchor point is generated.

[0058] Based on the type of vehicle control execution anomaly, the system automatically captures user operation anchor points, control command anchor points, vehicle signal change anchor points, and in-vehicle screen recordings, vehicle signals, control receipts, communication logs, and system logs before and after the vehicle control command is issued. The system automatically populates the generated issue report with test cases, abnormal steps, expected results, actual results, vehicle control command time, window status changes, and key log segments, and generates a corresponding reproduction data package.

[0059] In one implementation, the test case of "the instrument panel displaying the corresponding theme after switching driving modes" is used as an example to illustrate the display anomaly test case. In response to switching driving modes, the system generates a user operation anchor point; when the driving mode signal changes, the system generates a vehicle signal change anchor point; when the instrument panel display changes, the system generates an instrument panel display change anchor point. If a change in the driving mode signal is detected but the instrument panel display is not updated synchronously, or if the displayed content is inconsistent with the expected result, an instrument panel display anomaly anchor point is generated.

[0060] Based on the type of instrument display anomaly, the system automatically captures user operation anchor points, instrument screen, vehicle screen recording, driving mode signals, instrument refresh logs, and key video frames, and generates a structured problem form containing the abnormal steps, signal changes, the actual instrument display, and key logs.

[0061] In one implementation, the crash exception test case is illustrated using the test case of "performing the launch or switching operation of a vehicle infotainment application" as an example. When performing the launch or switching operation of a vehicle infotainment application, the application lifecycle log, system log, and vehicle infotainment screen recording are continuously monitored. When an application process exits, the page displays a black screen, a white screen, or becomes unresponsive, an application exception anchor point is generated.

[0062] Based on the application exception type, the system automatically captures user operation anchor points, application lifecycle logs before and after the exception anchor point, system crash logs, memory status, CPU status, in-vehicle screen recordings, and key screenshots, and generates a structured issue form. The issue form automatically associates the exception application, exception time, exception page, crash logs, key screenshots, and reproduction data package, making it easier for developers to quickly locate the problem.

[0063] In one implementation, taking the "using a web application" test case as an example, the network anomaly test case is explained. When executing network-dependent test cases such as online music playback, online navigation, app store downloads, or account logins, the system collects network status, interface request logs, page loading status, and application logs in real time. When request timeouts, interface failures, network disconnections, weak network switching, or page loading failures are detected, network status change anchor points or network anomaly anchor points are generated.

[0064] Based on the type of network anomaly, the system automatically captures the user's operation anchor point, the network status before and after the anomaly anchor point, request and response logs, page loading status, in-vehicle screen recording, and application logs, and generates an issue ticket and a reproduction data package that includes the network anomaly time, requested interface, failure reason, page status, and reproduction path.

[0065] To facilitate understanding, an example of a smart cockpit testing method according to an embodiment of this application is provided, including the following steps: S1: Enter the real vehicle test mode through the vehicle-mounted interactive interface or test terminal, log in to the test account, and select the corresponding test items, vehicle configuration, and software version.

[0066] S2: Import test case file. The system parses the test case number, test case name, test object, test steps, expected results, associated vehicle signals, associated applications, observation methods, and exception types in the test case file, and generates a test task context.

[0067] S3: Select the target test case to start testing. The system generates the test case start anchor point and starts the vehicle screen recording, camera video acquisition, vehicle status signal acquisition, system log acquisition, application log acquisition, and network status acquisition.

[0068] S4: Perform the operation according to the test steps. For each test step, the system generates a step start anchor point; when a click, swipe, voice input, button operation, or vehicle control operation is detected, the system generates a user operation anchor point; when a page change, vehicle signal change, log anomaly, or network anomaly is detected, the system generates a corresponding screen change anchor point, vehicle signal change anchor point, log anomaly anchor point, or network status change anchor point.

[0069] S5: The system uses a unified timestamp to synchronously link various event anchors with vehicle screen recordings, camera videos, vehicle status signals, system logs, application logs, network status, and key screenshots, forming a chain of evidence for the testing process. For example, ... Figure 2 As shown, Figure 2 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application.

[0070] S6: When the current test case is determined to pass, the system saves the test result of the test case and continues to the next test case; when the current test case is determined to fail, or a preset abnormal event is detected, the system generates a test case failure anchor point and enters the issue ticket generation process.

[0071] S7: Determine the log and video capture windows based on the anomaly type, and extract key video clips, key log clips, vehicle status snapshots, key screenshots, and page status information before and after the anomaly occurs from the evidence chain of the testing process. For example, Figure 3 As shown, Figure 3 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application.

[0072] S8: The system generates a structured question sheet based on test cases, abnormal steps, expected results, actual results, abnormal event anchors, key evidence, and vehicle status snapshots. For example, Figure 4 As shown, Figure 4 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application.

[0073] S9: The system generates a reproduction data package associated with the structured issue ticket and uploads the issue ticket, evidence chain, and reproduction data package to the cloud testing platform. For example, Figure 5 As shown, Figure 5 This is a partial flowchart illustrating a smart cockpit testing method according to an embodiment of this application. After acquiring anomaly anchor points and key evidence, the problem form fields are automatically filled in, and it is determined whether additional description is needed. If additional description is needed, actual phenomena or confirmation information can be further added; if no additional description is needed, a structured problem form can be directly generated.

[0074] S10: After the test task is completed, the system generates a test report based on information such as test item, software version, test cases, pass rate, number of failed issues, and severity level of issues.

[0075] Understandably, by unifying and associating test steps, user operations, changes in the vehicle's infotainment screen, changes in vehicle signals, log anomalies, and problem ticket information as events, and dynamically extracting key evidence based on anomaly types, the system solves problems such as inaccurate problem occurrence points, unreasonable log extraction scope, scattered key evidence, lack of causal relationships between evidence, and incomplete reproduction information in real-vehicle testing of smart cockpits.

[0076] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an intelligent cockpit testing system according to an embodiment of this application. The intelligent cockpit testing system 60 includes a startup module 61 and a generation module 62.

[0077] The startup module 61 is configured to obtain a test case file, which includes at least one target test case.

[0078] The generation module 62 is configured to acquire test data corresponding to the target test case, generate at least one event anchor point based on the test data, determine the type of the target test case based on the test data, and generate a test report for the smart cockpit based on the type of the target test case, the test data, and at least one event anchor point. The event anchor point is used to identify the occurrence node of the target event in the test data.

[0079] In this embodiment, a test case file is obtained, including at least one target test case. Test data corresponding to the target test case is obtained. At least one event anchor point is generated based on the test data, and the type of the target test case is determined based on the test data. The event anchor point is used to identify the occurrence node of the target event in the test data. Based on the type of the target test case, the test data, and at least one event anchor point, a test report for the intelligent cockpit is generated. By associating the evidence chain of the test process through event anchor points and generating a test report, problem data can be quickly located, and the anomaly reproduction information of the target test case is complete and standardized, thereby improving the vehicle testing efficiency of the intelligent cockpit testing system.

[0080] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0081] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. The electronic device 70 includes a memory 71 and a processor 72 coupled to each other. The processor 72 is used to execute program instructions stored in the memory 71 to implement the steps in any of the above-described intelligent cockpit testing method embodiments. In a specific implementation scenario, the electronic device 70 may include, but is not limited to, a microcomputer or a server. Furthermore, the electronic device 70 may also include mobile devices such as laptops and tablets, without limitation.

[0082] Specifically, processor 72 controls itself and memory 71 to implement the steps in any of the above-described embodiments of the smart cockpit testing method. Processor 72 can also be referred to as a CPU (Central Processing Unit). Processor 72 may be an integrated circuit chip with signal processing capabilities. Processor 72 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. Furthermore, processor 72 can be implemented using integrated circuit chips.

[0083] Please see Figure 8 , Figure 8This is a schematic diagram of the structure of a non-volatile computer-readable storage medium according to an embodiment of this application. The non-volatile computer-readable storage medium 80 stores program instructions 801 that can be executed by a processor. The program instructions 801 are used to implement the steps in the above-described intelligent cockpit testing method embodiment.

[0084] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0085] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0086] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0087] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0088] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] Those skilled in the art will readily recognize that numerous modifications and variations can be made to the apparatus and method while maintaining the teachings of this application. Therefore, the above disclosure should be considered limited only by the scope of the appended claims.

Claims

1. A method for testing an intelligent cockpit, characterized in that, include: Obtain a test case file, which includes at least one target test case; Obtain the test data corresponding to the target test case; At least one event anchor is generated based on the test data, and the type of the target test case is determined based on the test data; A test report for the smart cockpit is generated based on the type of the target test case, the test data, and the at least one event anchor point. The event anchor point is used to identify the occurrence node of the target event in the test data.

2. The method according to claim 1, characterized in that, The process of generating a test report for the intelligent cockpit based on the type of the target test case, the test data, and the multiple event anchors includes: In response to the fact that the target test case is of an exception type, target data is extracted from the test data based on the event anchor to generate a structured record of the target event; Based on the structured records, fault reproduction data packets are obtained, and then a test report for the intelligent cockpit is generated.

3. The method according to claim 2, characterized in that, The target test case for the exception type includes at least one of the following: Page response error test cases, in which the page fails to redirect within a preset time; Vehicle control execution exception use case, in which the vehicle status signal does not change within a preset time after the vehicle control command is issued, or the vehicle control receipt fails to return; Displaying abnormal cases, in which the instrument screen does not refresh synchronously when the data signal changes, or the displayed content is inconsistent with the expected result; Crash exception test cases, in which the application process exits, the page is black, white or unresponsive; Network anomaly use cases, including request timeout, interface failure, network disconnection, weak network switching, or page loading failure.

4. The method according to claim 1, characterized in that, The generation of at least one event anchor point based on the test data includes: In response to the presence of the target event in the test data, an event anchor point corresponding to the target event is generated; The target events include at least one of user operation, screen change, vehicle signal change, log anomaly, and network anomaly.

5. The method according to claim 4, characterized in that, The step of generating at least one event anchor point based on the test data further includes: The at least one event anchor is associated with the test data, wherein the test data and the at least one event anchor use the same timestamp.

6. The method according to claim 1, characterized in that, The event anchor includes at least one of the following information: Event number, event type, event trigger time, associated test case, associated test step, associated data source, event description, and evidence index.

7. The method according to claim 1, characterized in that, The event anchor includes at least one of the following types: The test case start anchor is used to indicate that the target test case has started execution; A step start anchor is used to indicate the start of execution of a certain step in the target test case; User operation anchors are used to represent actions such as clicking, swiping, voice input, button operation, or vehicle control operation. Screen change anchor points are used to represent detected page jumps, pop-ups, black screens, white screens, stutters, crashes, changes in control states, or changes in page elements; Signal change anchor points are used to characterize the detected changes in vehicle signals, including window, air conditioning, seat, instrument panel, volume, door, gear, vehicle speed, and power status. Log anomaly anchors are used to characterize the detection of system error logs, application crash logs, interface call failure logs, network anomaly logs, or controller communication anomaly logs. Network status change anchors are used to characterize the detection of network connection interruption, request timeout, interface failure, domain name system anomaly, weak network switching, or network recovery. Test case failure anchors are used to characterize that the target test case does not meet preset conditions; The end anchor point of the test case is used to indicate that the target test case has been executed.

8. A smart cockpit testing system, characterized in that, include: The startup module is configured to acquire a test case file, which includes at least one target test case. The generation module is configured as follows: Obtain the test data corresponding to the target test case; At least one event anchor is generated based on the test data, and the type of the target test case is determined based on the test data; A test report for the smart cockpit is generated based on the type of the target test case, the test data, and the at least one event anchor point. The event anchor point is used to identify the occurrence node of the target event in the test data.

9. An electronic device, characterized in that, The system includes a memory and a processor coupled to each other, the processor being used to execute program instructions stored in the memory to implement the smart cockpit testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the intelligent cockpit testing method according to any one of claims 1 to 7.

Images