Intelligent cabin stability test method, device and equipment and storage medium

Abstract

The invention discloses a stability test method, device and equipment of an intelligent cabin and a storage medium, relates to the technical field of vehicle testing, and discloses the stability test method of the intelligent cabin, which comprises the following steps: obtaining test demand data, version management data, hardware configuration information and historical defect data of a to-be-tested intelligent cabin project; performing project feature analysis according to the test demand data, the version management data, the hardware configuration information and the historical defect data to obtain project feature information; performing project type judgment according to the project feature information to obtain a target project type; generating a stability test strategy corresponding to the target project type according to the target project type to obtain a target stability test strategy; performing an automatic stability test according to the target stability test strategy and collecting test process data; and performing quantitative analysis according to the test process data to obtain a stability test result. By applying the technical scheme of the invention, the test efficiency and the problem detection rate can be improved.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to methods, apparatus, equipment and storage media for testing the stability of intelligent cockpits. Background Technology

[0002] With the continuous improvement of automotive intelligence and connectivity, the intelligent cockpit has evolved from a traditional information display unit into a highly integrated, software-intensive electronic system, widely carrying multiple functions such as infotainment, navigation, voice interaction, instrument display, and driver monitoring. Its software scale continues to expand, and the degree of functional coupling deepens, making system operational stability a key factor affecting vehicle safety, reliability, and user experience.

[0003] Against this technological backdrop, traditional intelligent cockpit stability testing typically employs a fixed testing strategy. This means that regardless of the scale of project changes, differences in hardware and software, or historical quality levels, the same testing content and intensity are applied, or the testing scope is manually determined based on the experience of the testers. While this approach either ensures safety through full-scale, long-term testing or achieves some efficiency improvements through automation, the testing strategy itself lacks an objective correlation with the project's risk characteristics. It fails to reasonably differentiate testing resource allocation based on the actual risk level of different projects, leading to wasted testing resources or insufficient exposure of stability risks.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, equipment and storage medium for testing the stability of intelligent cockpits, aiming to solve the technical problem that the investment of testing resources is not matched with the actual stability risks in the process of testing the stability of intelligent cockpits, and it is difficult to ensure both testing efficiency and reliability while ensuring quality.

[0006] To achieve the above objectives, this application proposes a stability testing method for an intelligent cockpit, the method comprising: Obtain test requirement data, version management data, hardware configuration information, and historical defect data for the smart cockpit project to be tested; Based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data, project feature analysis is performed to obtain project feature information; Based on the project characteristic information, the project type is determined to obtain the target project type; Generate a stability testing strategy corresponding to the target project type based on the target project type, and obtain the target stability testing strategy; Perform automated stability testing according to the target stability testing strategy and collect test process data; The stability test results are obtained by performing quantitative analysis on the test process data.

[0007] In one embodiment, the step of performing project feature analysis based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data to obtain project feature information includes: Extract version iteration cycle and code change scale information from the version management data; Extract hardware version identification information from the hardware configuration information; The frequency of historical defects and the distribution of defect levels are statistically analyzed from the historical defect data. Project feature information is obtained by performing project feature analysis on the version iteration cycle, code change scale information, hardware version identification information, historical defect occurrence frequency information, and defect level distribution information.

[0008] In one embodiment, the step of determining the project type based on the project feature information to obtain the target project type includes: The duration of the first iteration cycle, the first defect incidence rate threshold, the duration of the second iteration cycle, and the second defect incidence rate threshold are obtained, wherein the duration of the first iteration cycle is longer than the duration of the second iteration cycle, and the first defect incidence rate threshold is less than the second defect incidence rate threshold. When the project feature information satisfies at least one of the following conditions: the version iteration cycle is greater than or equal to the duration of the first iteration cycle, the hardware version identification information is unchanged, the code change scale information is a functional change, and the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is less than or equal to the first defect occurrence rate threshold, the target project type is determined to be an iterative project. When the project feature information satisfies at least one of the following: the hardware version identification information is a version change, the version iteration cycle is less than the duration of the second iteration cycle, or the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is greater than the second defect occurrence rate threshold, the target project type is determined to be a brand new project.

[0009] In one embodiment, the step of generating a stability testing strategy corresponding to the target project type based on the target project type, and obtaining the target stability testing strategy, includes: When the target project type is an iterative project, a focused stability testing strategy is determined as the target stability testing strategy, wherein the focused stability testing strategy includes functional testing, change point functional stress testing, and black screen testing; When the target project type is a brand new project, a comprehensive stability testing strategy is determined as the target stability testing strategy. The comprehensive stability testing strategy includes a combination of test modules such as full-function stress testing, mean time between failures (MTBF) testing, random event testing, full-specific testing, and resource monitoring testing.

[0010] In one embodiment, the step of performing automated stability testing and collecting test process data according to the target stability testing strategy includes: According to the target stability testing strategy, the corresponding test steps are loaded from the preset test case library to generate a testable script; Perform automated stability testing based on the testable script, and collect system log data, memory resource usage data, function operation result data, and abnormal event data during the automated stability testing. The test process data is determined based on the system log data, the memory resource usage data, the function operation result data, and the abnormal event data.

[0011] In one embodiment, the step of performing quantitative analysis based on the test process data to obtain the stability test results includes: The test quantitative indicators are calculated based on the test process data, including the functional pass rate, black screen occurrence rate, mean time between failures, random event crash rate, and average resource utilization rate. When all the quantitative indicators of the test meet the corresponding threshold requirements, the stability test result is determined to be satisfactory. If any of the test quantification indicators fails to meet the corresponding threshold requirements, the stability test result is determined to be unsatisfactory.

[0012] In one embodiment, after the step of performing quantitative analysis based on the test process data to obtain the stability test results, the method further includes: When the stability test result is satisfactory, a satisfactory test report is generated, which includes a trend chart of quantitative test indicators and data distribution. When the stability test result is that the test fails, a root cause analysis report is generated, wherein the root cause analysis report includes test process data before and after the associated anomaly timestamp; By comparing and analyzing the stability test results with historical test results, the fluctuation of the quantitative test indicators can be obtained. Based on the fluctuations and the compliance test report or root cause analysis report, test optimization suggestions are generated to adjust the stability test strategy according to the test optimization suggestions.

[0013] In addition, to achieve the above objectives, this application also proposes a stability testing device for a smart cockpit, which includes: a data acquisition module for acquiring test requirement data, version management data, hardware configuration information and historical defect data of the smart cockpit project to be tested; The project feature analysis module is used to perform project feature analysis based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data to obtain project feature information; The project type determination module is used to determine the project type based on the project feature information to obtain the target project type. The strategy determination module is used to generate a stability testing strategy corresponding to the target project type based on the target project type, thereby obtaining the target stability testing strategy. The stability testing module is used to perform automated stability testing according to the target stability testing strategy and collect test process data. The quantitative analysis module is used to perform quantitative analysis on the test process data to obtain stability test results.

[0014] In addition, to achieve the above objectives, this application also proposes a stability testing device for an intelligent cockpit, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the stability testing method for the intelligent cockpit as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the stability testing method for the intelligent cockpit described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the intelligent cockpit stability testing method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: By first acquiring test requirement data, version management data, hardware configuration information, and historical defect data of the smart cockpit project under test, and then performing project feature analysis based on this data to obtain project feature information, the target project type is determined based on the project feature information, and a target stability testing strategy corresponding to the target project type is generated. Automated stability testing is carried out according to this strategy, and test process data is collected. The stability test results are obtained by quantitative analysis of the test process data. This approach specifically solves the technical problems of mismatch between test strategies and project risks and the inability to quantify test results in existing technologies. Compared with existing technologies, it achieves precise matching between test strategies and project risks, avoids over-testing or under-testing, and reduces human intervention by automated testing processes, ensuring test continuity. Quantitative analysis allows test results to be compared with historical version data, which not only improves test efficiency and resource utilization, but also enhances the relevance of problem detection and the credibility of test results, achieving a quantitative balance between test resource investment and project stability risk control. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating the first embodiment of the stability testing method for the intelligent cockpit in this application; Figure 2 A schematic diagram of the script deployment and environment initialization process provided in Embodiment 1 of the stability testing method for the intelligent cockpit of this application; Figure 3 This is a schematic diagram of the concurrent execution and scenario simulation process provided in Embodiment 1 of the stability testing method for the intelligent cockpit of this application; Figure 4 A schematic diagram of the real-time data acquisition process provided in Embodiment 1 of the stability testing method for the intelligent cockpit of this application; Figure 5 A schematic diagram of the breakpoint resume mechanism provided in Embodiment 1 of the stability testing method for the intelligent cockpit of this application; Figure 6 A schematic diagram of the test completion process provided in Embodiment 1 of the stability test method for the intelligent cockpit of this application; Figure 7This is a flowchart illustrating Embodiment 2 of the stability testing method for the intelligent cockpit in this application. Figure 8 A simplified flowchart illustrating the stability testing method for the intelligent cockpit provided in Embodiment 2 of this application; Figure 9 This is a schematic diagram of the module structure of the stability testing device for the intelligent cockpit according to an embodiment of this application; Figure 10 This is a schematic diagram of the hardware operating environment involved in the stability testing method of the intelligent cockpit in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is as follows: Acquire test requirement data, version management data, hardware configuration information, and historical defect data of the intelligent cockpit project to be tested; perform project feature analysis based on the test requirement data, version management data, hardware configuration information, and historical defect data to obtain project feature information; determine the project type based on the project feature information to obtain the target project type; generate a stability testing strategy corresponding to the target project type to obtain the target stability testing strategy; perform automated stability testing based on the target stability testing strategy and collect test process data; perform quantitative analysis based on the test process data to obtain the stability test results.

[0025] In this embodiment, for ease of description, the following description will focus on the stability testing equipment for identifying the smart cockpit.

[0026] Because existing technologies for intelligent cockpit stability testing often fail to match the investment of testing resources with actual stability risks, making it difficult to ensure both quality and testing efficiency and reliability, this application provides a solution. This solution involves first acquiring test requirement data, version management data, hardware configuration information, and historical defect data for the intelligent cockpit project under test. Then, based on this data, project characteristic analysis is performed to obtain project feature information. Following this, the target project type is determined, and a target stability testing strategy corresponding to that type is generated. Automated stability testing is then conducted based on this strategy, and test process data is collected. Quantitative analysis of the test process data yields the stability test results. This solution specifically addresses the technical problems of mismatch between testing strategies and project risks, and the inability to quantify test results in existing technologies. Compared to existing technologies, this solution achieves precise matching between testing strategies and project risks, avoiding over-testing or under-testing. The automated testing process reduces manual intervention, ensuring testing continuity. Quantitative analysis allows for comparison of test results with historical version data, improving testing efficiency and resource utilization, enhancing the specificity of problem detection, and increasing the credibility of test results. This achieves a quantitative balance between testing resource investment and project stability risk control.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as a stability testing device for a smart cockpit. The following description uses a stability testing device for a smart cockpit as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a method for testing the stability of an intelligent cockpit, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the stability testing method for the intelligent cockpit of this application.

[0029] In this embodiment, the stability testing method for the intelligent cockpit includes steps S10 to S60: Step S10: Obtain test requirement data, version management data, hardware configuration information, and historical defect data for the smart cockpit project to be tested; It should be noted that the test requirement data describes the test objectives, scope, core functionalities, and acceptance requirements of the smart cockpit project to be tested. It originates from the test requirement document and clearly defines the infotainment, instrument display, and other functional modules to be covered, as well as their test priorities.

[0030] Additionally, version control data records the code iteration process of the smart cockpit project and is stored in the version control tool Git. It includes the number of commits, a list of changed files, records of increases, decreases, and changes in lines of code, the version number, and the iteration cycle.

[0031] Additionally, the hardware configuration information consists of detailed parameter data for the hardware devices related to the smart cockpit under test, sourced from the hardware configuration management library. It covers core parameters such as ECU hardware version number, system-on-a-chip model, memory capacity, and screen resolution.

[0032] Furthermore, historical defect data consists of information related to issues discovered during testing or use in previous versions of the project, stored in a historical defect database. It includes key information such as the number, occurrence rate, type, and remediation status of historical A / B category issues.

[0033] Understandably, the process involves extracting test requirement data from the test requirement document to clarify the core test objectives and scope; obtaining version management data such as the number of commits and a list of changed files through the version management tool interface; accessing the hardware configuration management library to extract hardware configuration information such as the ECU hardware version number; and querying the historical defect database to statistically analyze the number and occurrence rate of A / B type issues in the most recent three versions. In this embodiment, a project obtains an iteration cycle of 5 days from the version management tool and confirms from the hardware configuration management library that there have been no changes to the core hardware.

[0034] Step S20: Perform project feature analysis based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data to obtain project feature information; It should be noted that project feature analysis is a process of in-depth analysis, filtering, and refinement of the four types of data acquired. It follows standardized rules to extract the core attributes of the project and is a crucial step in connecting the raw data with project type determination.

[0035] Furthermore, project characteristic information is a set of information reflecting the core attributes of a project, obtained after project characteristic analysis. It includes characteristics that determine the project's risk level, such as iteration cycle, whether core hardware has changed, and the historical occurrence rate of A / B type problems.

[0036] Understandably, this involves analyzing version management data to extract features such as iteration cycles and code change scales; analyzing hardware configuration information to determine whether core hardware has changed, or whether new hardware or operating systems have been integrated; compiling historical defect data to statistically analyze the occurrence rate of A / B type issues in the last three versions; and combining test requirement data to supplement and verify functional optimization directions, thus forming project feature information.

[0037] In one feasible implementation, step S20 may include steps S21 to S24: Step S21: Extract version iteration cycle and code change scale information from the version management data; It's important to note that the version iteration cycle is the time span from when project requirements are frozen to when a version is released. It's a key indicator reflecting the pace of project iteration, and different cycle lengths can reflect the urgency and scale of project changes.

[0038] Additionally, code change scale information describes the extent of code modifications made to the project, including the number of commits, a list of changed files, and records of increases, decreases, and modifications to lines of code. It provides a clear picture of the scope of functional adjustments or refactoring within the project.

[0039] Understandably, the version iteration cycle of a project can be accurately extracted from version control data, along with relevant data such as the number of commits, the list of changed files, and changes in lines of code, which can then be integrated to form information on the scale of code changes. In this embodiment, if version control data shows that a project took 6 days from requirement freezing to release, with 12 commits, the corresponding version iteration cycle and code change scale information can be extracted.

[0040] Step S22: Extract hardware version identification information from the hardware configuration information; It should be noted that hardware version identification information is a unique identifier used to distinguish hardware device versions, including core hardware parameters such as ECU hardware version number, system-on-a-chip model, memory capacity, and screen resolution. It is the core basis for determining whether the core hardware has changed.

[0041] Understandably, key identifiers such as the ECU hardware version number and system-level chip model are filtered and extracted from the acquired hardware configuration information to form hardware version identifier information.

[0042] Step S23: Calculate the frequency of historical defects and the distribution of defect levels from the historical defect data; It should be noted that the historical defect frequency information is data on the number of times defects occurred in previous versions of the project, usually with the average occurrence rate of the most recent 3 versions as the main reference. It can reflect the historical quality stability level of the project.

[0043] Additionally, defect severity distribution information is data that categorizes historical defects by severity, primarily including the percentage of A / B category issues affecting driving safety or core functions. It clearly shows the distribution of severity among historical defects in the project.

[0044] Understandably, historical defect data is used to calculate the total number of defects and the average occurrence rate for the most recent three versions. Simultaneously, the number and proportion of defects at different severity levels (A / B, etc.) are calculated, forming historical defect frequency information and defect severity distribution information. In this embodiment, if 12 defects occurred in the most recent three versions, with an average occurrence rate of 3%, and A / B type defects accounted for 25%, these data will be statistically analyzed as corresponding feature information.

[0045] Step S24: Perform project feature analysis on the version iteration cycle, code change scale information, hardware version identification information, historical defect occurrence frequency information, and defect level distribution information to obtain project feature information.

[0046] Understandably, the extracted version iteration cycle, code change scale information, hardware version identification information, historical defect frequency information, and defect level distribution information are integrated and sorted out to explore the correlations between various data, extract key features reflecting the core risk attributes of the project, and ultimately form project feature information. In this embodiment, if a project has a version iteration cycle of 6 days, the core hardware version number has not changed, and the historical A / B type problem occurrence rate is 3%, these key features will be integrated into project feature information.

[0047] Step S30: Determine the project type based on the project feature information to obtain the target project type; It should be noted that project type determination is a process that determines the type of a project based on its characteristic information, according to preset rules and arbitration logic. It is executed automatically and does not rely on subjective human judgment, ensuring consistent and impartial results.

[0048] Furthermore, the target project type is the classification result after project type determination, mainly including iterative projects and brand-new projects. Iterative projects have lower risk, while brand-new projects have higher risk, directly determining the direction of subsequent testing strategy formulation.

[0049] Understandably, the project characteristics are checked to see if they meet any of the criteria for an iterative project, namely, a version iteration cycle of ≥3 days, no changes to core hardware but only optimization of software functions, and a historical A / B type problem incidence rate of ≤5%; then, it is checked whether it meets any of the criteria for a completely new project, namely, the first integration of new hardware or a new operating system, an iteration cycle of <2 days, no historical test data or a historical A / B type problem incidence rate of >10%; when there is a conflict in characteristics, the high-risk priority arbitrator is triggered to determine that it is a completely new project.

[0050] In one feasible implementation, step S30 may include steps S31 to S33: Step S31: Obtain the first iteration cycle duration, the first defect occurrence rate threshold, the second iteration cycle duration, and the second defect occurrence rate threshold, wherein the first iteration cycle duration is longer than the second iteration cycle duration, and the first defect occurrence rate threshold is less than the second defect occurrence rate threshold. It should be noted that the duration of the first iteration cycle is a preset standard used to determine the version iteration time of an iterative project. It is the lower limit of the time from the freezing of project requirements to the release of a version, and is used to distinguish the speed of project iteration.

[0051] Additionally, the first defect incidence rate threshold is a preset standard used to determine the severity of historical defects in iterative projects. It represents the upper limit of the incidence rate of historical A / B type problems, reflecting the acceptable level of historical project quality.

[0052] Additionally, the second iteration cycle duration is a preset standard for determining the version iteration time of entirely new projects. It is the upper limit of the time from project requirements being frozen to version release, used to identify projects with a fast pace.

[0053] Furthermore, the second defect incidence threshold is a preset standard for determining the severity of historical defects in brand-new projects. It is the lower limit of the historical A / B category problem incidence rate, used to identify projects with high historical quality risks.

[0054] Understandably, four key threshold parameters are obtained from the preset judgment rules, where the duration of the first iteration cycle is set to 3 days, the duration of the second iteration cycle is set to 2 days, the first defect incidence rate threshold is set to 5%, and the second defect incidence rate threshold is set to 10%, satisfying the relationship that the duration of the first iteration cycle is greater than the duration of the second iteration cycle and the first defect incidence rate threshold is less than the second defect incidence rate threshold.

[0055] Step S32: When the project feature information satisfies at least one of the following: version iteration cycle is greater than or equal to the duration of the first iteration cycle, hardware version identification information is unchanged, code change scale information is a functional change, and the defect occurrence rate of historical defect occurrence frequency information or defect level distribution information is less than or equal to the first defect occurrence rate threshold, the target project type is determined to be an iterative project. Understandably, the project's characteristic information should be checked against the criteria for determining an iterative project. If a project's version iteration cycle is ≥3 days, or the hardware version identification information remains unchanged while only software functions have been modified, or the historical defect incidence rate is ≤5%, then the target project type can be determined as an iterative project.

[0056] Step S33: When the project feature information satisfies at least one of the following: the hardware version identification information is a version change, the version iteration cycle is less than the duration of the second iteration cycle, or the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is greater than the second defect occurrence rate threshold, the target project type is determined to be a brand new project.

[0057] Understandably, the project's characteristic information is checked against the criteria for determining a completely new project. If the project's hardware version identification information changes, or the version iteration cycle is less than 2 days, or the historical defect rate is greater than 10%, then the target project type can be determined to be a completely new project.

[0058] In this embodiment, if a project's characteristics simultaneously meet the criteria for both iterative and entirely new projects, such as an iteration cycle of ≥3 days but with hardware changes, the decision engine triggers a high-risk priority arbitrator to classify it as an entirely new project, thus ensuring sufficient testing.

[0059] Step S40: Generate a stability testing strategy corresponding to the target project type based on the target project type, and obtain the target stability testing strategy; It should be noted that the stability testing strategy is a comprehensive testing scheme developed to verify the stability of the intelligent cockpit, defined as a combination of test modules, a list of equipment configurations, a test parameter matrix, and a pass standard threshold quadruple.

[0060] Furthermore, the target stability testing strategy is an adaptation strategy loaded based on the target project type. Iterative projects correspond to a focused strategy, focusing on testing core functions and change points; brand new projects correspond to a comprehensive strategy, covering all functions and multi-scenario testing.

[0061] Understandably, if the target project type is an iterative project, a focused strategy is loaded from the strategy knowledge base, and the test module combination includes three types such as functional smoke testing. One core test bench is configured, and corresponding test parameters and pass standards are set. If it is a brand new project, a comprehensive strategy is loaded, and the test module combination includes five types such as full-function stress testing. Two parallel test benches and expansion equipment are configured, and more stringent parameters and standards are set.

[0062] In this embodiment, the test hardware mainly includes a core test bench, an extended test bench, and an IO control unit. The core test bench is adapted to the basic testing requirements of various projects and is equipped with a programmable power supply that supports precise adjustment from 0-32V / 0-10A, a high-definition industrial camera with ≥2 megapixels and HDR support, a CAN analyzer that supports CAN / CAN-FD bus and has an adjustable baud rate of 5Kbps-5Mbps, and the vehicle's infotainment system under test. The extended test bench is designed for parallel testing of new projects and, in addition to the core test bench, is a voice isolation box with a background noise of ≤30dB and support for multilingual audio playback, a WiFi / Bluetooth jammer with a shielding range of ≥5 meters and an adjustable frequency of 2.4GHz / 5GHz, and a temperature and humidity control box with a temperature range of -40℃ to 85℃ and an accuracy of ±1℃. The IO control unit is based on an STM32 / Arduino embedded controller and can receive commands to control power on / off, button simulation, touch screen clicks, and other physical operations in real time. All kinds of hardware work together to meet the testing environment and operational requirements of projects with different risk levels. In a feasible implementation, step S40 may include steps S41~S42: Step S41: When the target project type is an iterative project, determine the focused stability testing strategy as the target stability testing strategy, wherein the focused stability testing strategy includes functional testing, change point functional stress testing, and black screen testing. It should be noted that the focused stability testing strategy is a testing plan adapted to iterative projects, focusing on testing core functions and points of change. It streamlines the testing scope and parameters, avoids wasting resources, and ensures that no key risk points are overlooked.

[0063] In addition, functional testing involves selecting core priority test cases to cover the core functions of the intelligent cockpit. In this embodiment, over 1500 P0-level test cases are selected, covering four core functions: navigation, media, voice, and instrumentation, with an execution time of ≤2 hours.

[0064] Furthermore, the change point functional stress test is based on code change parsing to identify affected modules and then performing targeted repetitive operation tests. It uses Gitdiff to parse change files and generate 1000+ repetitive operations such as continuous clicks, swipes, and voice commands.

[0065] Furthermore, the black screen test is a specialized test that simulates power-on and power-off cycles and detects the screen status. At 30-second intervals, the screen's RGB values ​​are captured using a high-definition camera, with ΔE > 30 used as the criterion for determining a black screen anomaly.

[0066] Understandably, when the target project type is determined to be an iterative project, a focused stability testing strategy is directly adopted as the target stability testing strategy. This strategy explicitly includes three core modules: functional testing, changepoint functional stress testing, and black screen testing. Each module is tested according to a preset number of test cases, execution duration, and operation method.

[0067] Step S42: When the target project type is a brand new project, a comprehensive stability testing strategy is determined as the target stability testing strategy. The comprehensive stability testing strategy includes a combination of test modules such as full-function stress testing, mean time between failures (MTBF) testing, random event testing, full-specific testing, and resource monitoring testing.

[0068] It should be noted that the comprehensive stability testing strategy is a testing plan adapted to new projects, covering full functionality, multiple scenarios, and multi-dimensional testing. It strengthens testing intensity and environment simulation to ensure full verification in high-risk scenarios.

[0069] Additionally, full-function stress testing covers all test cases and runs continuously under extreme conditions. In this embodiment, it covers over 3000 test cases, runs continuously 24 / 7, and includes high and low temperature cycles from -30℃ to 70℃.

[0070] Additionally, the mean time between failures (MTBF) test is a reliability test based on the GB / T25000.51 standard. The system operates for 100 hours, and the failure interval is recorded; a result of ≥200 hours is required.

[0071] Additionally, the random event test (Monkey test) involves injecting a large number of random events to monitor the system status. Over 10,000 random events are injected daily, with touch events accounting for 70%, voice events for 20%, and button events for 10%, with each test lasting 12 hours.

[0072] Furthermore, the comprehensive specialized testing covers a variety of specific scenarios for verification. This includes over 20 specific scenarios such as black screen, lag, CAN signal loss, and audio stuttering, with each scenario executed over 50 times.

[0073] Furthermore, resource monitoring testing involves real-time collection of system resource consumption data. It collects CPU utilization, memory usage, GPU load, and temperature data every second, and plots resource consumption curves.

[0074] Understandably, when the target project is determined to be a completely new project, a comprehensive stability testing strategy is adopted as the target stability testing strategy. This strategy explicitly includes a combination of modules such as full-function stress testing, mean time between failures (MTBF) testing, random event testing, comprehensive specialized testing, and resource monitoring testing. Each module is executed according to preset parameters and standards.

[0075] Reference Figure 2 , Figure 2 This is a schematic diagram of the script deployment and environment initialization process for the first embodiment of the intelligent cockpit stability testing method of this application.

[0076] like Figure 2 As shown, the strategy quadruple SMEPC is loaded first. This quadruple contains the test module combination, device configuration list, test parameter matrix, and pass standard threshold. Then, the script generation and scheduling unit issues a test start command, extracts YAML description test cases from the test case library and converts them into executable Python scripts based on the Appium and UIO frameworks. At the same time, an initialization command is issued to the IO control unit, covering three key actions: power timing, camera calibration, and DBC loading. After receiving the command, the programmable power supply presses IGN. The strict power-on sequence from ON to ACC to Boot supplies power to the vehicle's infotainment system under test. Upon power-on, an acknowledgment signal is immediately returned. The high-definition industrial camera simultaneously performs focus and exposure parameter calibration and enables HDR mode to ensure the accuracy of subsequent image recognition. After calibration, an acknowledgment is also sent back. The CAN analyzer then loads a DBC file with a baud rate range of 5Kbps to 5Mbps to parse the bus signals. After loading, an acknowledgment is also sent. Once all initialization actions have been successfully reported, the environment initialization completion status is set. The platform then sends the test script to the vehicle's infotainment system under test through the ADB channel. The vehicle's infotainment system returns a script reception confirmation. At this point, the script deployment and environment initialization phase is complete, providing a consistent and reproducible hardware and software environment for subsequent concurrent testing.

[0077] Reference Figure 3 , Figure 3 This is a schematic diagram of the concurrent execution and scenario simulation process of the first embodiment of the stability testing method for the intelligent cockpit of this application.

[0078] like Figure 3As shown, the platform first loads the strategy quadruple SMEPC, which contains the test module combination, equipment configuration list, test parameter matrix, and pass standard threshold. Then, the script generation and scheduling unit issues a test start command, extracts YAML description test cases from the test case library and converts them into executable Python scripts based on the Appium and UIO frameworks. Simultaneously, it issues initialization commands to the IO control unit, covering three key actions: power sequence, camera calibration, and DBC loading. Upon receiving the command, the programmable power supply powers the vehicle's system under test according to a strict power-on sequence from IGN ON to ACC to Boot, and immediately returns a response signal after power-on. The high-definition industrial camera simultaneously performs focus and exposure parameter calibration and enables HDR mode to ensure subsequent image recognition accuracy; it also sends a response upon calibration completion. The CAN analyzer then loads DBC files with baud rates ranging from 5Kbps to 5Mbps to parse bus signals, and also sends a response upon completion. Once all initialization actions have been successfully completed, the environment initialization completion status is set. The platform then sends the test script to the vehicle's infotainment system under test via the ADB channel. The vehicle's infotainment system returns a confirmation of script receipt. This concludes the script deployment and environment initialization phase, providing a consistent and reproducible hardware and software environment for subsequent concurrent testing.

[0079] Step S50: Perform automated stability testing according to the target stability testing strategy and collect test process data; It should be noted that automated stability testing is the process of executing test cases and simulating usage scenarios using automated means according to the target stability testing strategy. It requires no manual intervention, can perform continuous long-term testing, and includes various types such as functional smoke testing and stress testing.

[0080] Furthermore, the test process data consists of multi-dimensional data collected during the automated stability test execution, including log data, resource data, image data, controller area network data, etc., which comprehensively reflect the operating status of the intelligent cockpit during the test.

[0081] Understandably, test scripts are assembled based on test module combinations, the test environment is initialized including power timing control, equipment parameter calibration, etc., automated testing is started and multi-dimensional data is collected; tests are executed on a single rack for iterative projects, and two racks are tested in parallel for new projects, and the test is resumed from the breakpoint when interrupted.

[0082] In one feasible implementation, step S50 may include steps S51 to S53: Step S51: Load the corresponding test steps from the preset test case library according to the target stability test strategy and generate a testable script; It should be noted that the preset test case library is a database that stores predefined test cases. These cases are described in YAML format and include the specific operational procedures and verification standards for different test modules. It is categorized by functional module and risk level and supports dynamic recall based on the test strategy.

[0083] In addition, the test steps are the specific operational steps that constitute the test cases, including key elements such as the operation object, operation method, waiting time, and expected result.

[0084] Furthermore, test scripts are executable code files formed after integrating and loading test steps, developed based on the Appium or UIO framework. They can be recognized and executed by automated testing tools, enabling test operations without manual intervention.

[0085] Understandably, based on the test module combination in the target stability testing strategy, corresponding test cases are selected from a preset test case library, the test steps for each test case are extracted, and they are dynamically assembled according to execution logic to generate a testable script based on the Appium or UIO framework. In this embodiment, the functional smoke test of the iterative project will load the test steps of 1500+ test cases from the library and assemble them into the corresponding Python script.

[0086] Step S52: Perform automated stability testing according to the testable script, and collect system log data, memory resource usage data, function operation result data and abnormal event data in the automated stability test; It should be noted that the system log data refers to the system operation records generated during the operation of the intelligent cockpit, specifically the Android system logs. These logs are captured in real-time using the Android debugging bridge log capture tool ADB logcat and stored in timestamp-based chunks. They record key information such as the system and application's operating status and error messages.

[0087] Additionally, memory resource usage data refers to the system resource consumption data of the intelligent cockpit during the testing process, including CPU utilization, memory usage, GPU load, and device temperature. This data is collected by calling the system interfaces of the DUT (Device Under Test), such as / proc / stat and / proc / meminfo.

[0088] Additionally, the functional execution result data refers to the verification results after the test cases are executed, including information such as the number of passed test cases, the number of failed test cases, and the reasons for failure. It directly reflects whether the functional implementation of each test module meets the preset standards.

[0089] Furthermore, the abnormal event data refers to data related to abnormal phenomena that occur during the testing process, including the occurrence time, duration, and related log fragments of events such as black screens, application unresponsiveness (ANR), crashes, and controller LAN packet errors. This data is obtained through parsing by the anomaly detection engine.

[0090] Understandably, the generated testable script initiates automated stability testing, simultaneously collecting four types of data during test execution. System log data is stored in real-time with timestamps; memory resource usage data is collected every second and written to the cache; functional execution result data is recorded in the order of test case execution; and abnormal event data is parsed and marked in real-time by the anomaly detection engine. In this embodiment, a high-definition camera captures 5 frames of screen images per second to assist in the collection of abnormal event data.

[0091] Step S53: Determine the test process data based on the system log data, the memory resource usage data, the function operation result data, and the abnormal event data.

[0092] Understandably, the collected system log data, memory resource usage data, function operation result data, and abnormal event data are integrated and sorted, and then matched according to the test stage, test module, and timestamp. Redundant data is removed and data identifiers are added to form complete and structured test process data. In this embodiment, abnormal event data is stored in association with the corresponding timestamp of system log data and memory resource usage data for easy traceability and analysis later.

[0093] Reference Figure 4 , Figure 4 This is a schematic diagram of the real-time data acquisition process for the first embodiment of the stability testing method for the intelligent cockpit of this application.

[0094] like Figure 4As shown, the platform is uniformly controlled through script generation and scheduling units. First, it uses ADB Logcat to capture Android system logs and stores them in chunks by timestamp to ensure the log stream is complete and traceable. Simultaneously, it calls system interfaces to read the stat and meminfo files in the proc directory to obtain real-time CPU and memory usage data. A high-definition industrial camera captures screen images at a rate of five frames per second. Then, OpenCV is used to calculate the RGB mean and variance of each frame, providing quantitative evidence for judging black screens or distorted screens. A CAN analyzer synchronously records the bus load rate and the number of error frames. All the above data is immediately written to the Redis real-time data cache, forming a high-throughput log and resource data stream. The anomaly detection engine runs two detection paths in parallel within the same cycle. One uses regular expressions to match keywords in the log stream, capturing abnormal words such as black screen, ANR, and crash. The other calls a pre-trained isolated forest model to perform mutation detection on resource data. Once a momentary abnormal fluctuation in CPU or memory is detected, it is judged as a suspicious event. When any detection path triggers an anomaly, the engine immediately generates an anomaly flag, records the current test case ID, anomaly type, and timestamp, and writes the event to the Redis anomaly event area. The subsequent quantitative judgment engine can directly call these flags to perform root cause correlation analysis, achieving problem discovery and location within seconds, and ensuring the stability and data integrity of the entire testing process.

[0095] Reference Figure 5 , Figure 5 This is a schematic diagram of the breakpoint resume mechanism in the first embodiment of the stability testing method for the intelligent cockpit of this application.

[0096] like Figure 5As shown, the breakpoint resumption mechanism consists of two main parts: the test interruption phase and the recovery execution phase. During the test interruption phase, when an abnormal situation such as a power outage or equipment failure occurs, the test interruption loop begins. At this time, the anomaly detection engine first sends an interruption signal to the script generation and scheduling unit, and simultaneously writes a checkpoint record to the process data cache Redis. This record contains four key fields: test case ID, execution result, timestamp, and resource snapshot, used to completely save the state information at the moment of the test interruption. Subsequently, the script generation and scheduling unit reports the interruption status to the automated testing platform, completing the upward transmission of interruption information. After the interruption occurs, the system enters the manual intervention or automatic recovery phase. At this time, test execution is paused, waiting for the fault to be resolved or the automatic recovery conditions to be met. Once the recovery condition is met, the automated testing platform sends a recovery command to the script generation and scheduling unit. The script generation and scheduling unit then reads the latest checkpoint record from the process data cache Redis and continues to execute subsequent test steps from that test case ID based on the checkpoint. During this process, because the checkpoint mechanism completely saves the execution state before the interruption, there is no need to repeat the execution of completed test cases, achieving seamless resumption of test breakpoints. This mechanism effectively solves the problem of test data loss and wasteful repeated execution caused by power outages or equipment failures in long-cycle stability tests such as MTBF tests, ensuring the continuity and validity of test data and significantly improving the reliability and resource utilization efficiency of the automated testing system.

[0097] Step S60: Perform quantitative analysis based on the test process data to obtain the stability test results.

[0098] It should be noted that quantitative analysis is the process of calculating and comparing thresholds to test data, transforming qualitative test phenomena into quantitative indicators. It follows unified calculation rules to ensure the objectivity and comparability of the analysis results.

[0099] Furthermore, the stability test results are a comprehensive conclusion reflecting the stability of the smart cockpit project, obtained through quantitative analysis. This includes the determination of whether the standards are met, a detailed test report, a problem location report, and strategy optimization suggestions.

[0100] Understandably, quantitative indicators such as the pass rate of calculation functions, the black screen occurrence rate, and the mean time between failures are compared with the pass standard threshold to output a conclusion of compliance or non-compliance; qualified projects generate detailed test reports and archive them, while unqualified projects trigger root cause analysis and generate problem location reports; the results of this test are compared with historical data of similar projects to trigger strategy optimization suggestions.

[0101] Reference Figure 6 , Figure 6 This is a schematic diagram of the test completion process for the first embodiment of the stability testing method for the intelligent cockpit of this application.

[0102] like Figure 6 As shown, the platform sends a test termination command to the IO control unit through the script generation and scheduling unit. The programmable power supply gradually cuts off the power supply to the vehicle under test according to the preset power-down sequence to ensure safe hardware reset. Subsequently, the IO control unit reports the test completion status, and the platform immediately returns a Redis key used to index all data. This key points to the logs, resources, images, CAN frames, and exception markers stored in the process data cache. The platform uses this key to obtain the complete test dataset at once and starts batch exception analysis. It performs time alignment, classification, and weight sorting on all exception events recorded in Redis, and finally forms a summary table containing exception type, occurrence frequency, and associated test case ID, providing structured input for the subsequent quantitative judgment engine to generate risk scores and root cause reports.

[0103] This embodiment provides a stability testing method for intelligent cockpits. It automatically acquires test requirement data, version management data, hardware configuration information, and historical defect data of the intelligent cockpit project under test, and performs project characteristic analysis. Based on the analysis results, it accurately determines whether the project type is an iterative project or a completely new project, and then loads the corresponding focused or comprehensive stability testing strategy. It automatically generates test scripts and controls the test bench cluster to complete environment initialization, concurrent execution, real-time multi-dimensional data acquisition, anomaly detection at the second level, and breakpoint resumption. It quantitatively analyzes the test process data and outputs compliance conclusions, detailed test reports, problem location reports, and strategy optimization suggestions. This method solves the technical problems in existing technologies such as mismatch between test strategies and project risks, single test coverage dimensions, non-automated testing processes, unquantifiable test results leading to resource waste, high problem escape rates, low problem location efficiency, and inability to continuously optimize. It achieves the technical effect of accurately matching test resource investment with project risks.

[0104] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 The stability testing method for the intelligent cockpit further includes steps S61 to S63 in step S60: Step S61: Calculate test quantitative indicators based on the test process data, wherein the test quantitative indicators include functional pass rate, black screen occurrence rate, mean time between failures, random event crash rate, and average resource utilization rate. It should be noted that the quantitative test indicators are a set of quantitative metrics calculated from the test process data. They transform various phenomena during the test into comparable numerical values ​​and are the core basis for determining the stability of the intelligent cockpit.

[0105] Additionally, the functional pass rate is an indicator reflecting the pass rate of test case execution. It is calculated by the ratio of the number of pass test cases to the total number of test cases, directly reflecting the implementation quality of the core functions of the intelligent cockpit.

[0106] Additionally, the black screen occurrence rate is an indicator reflecting abnormal black screen situations. It is calculated by statistically analyzing the ratio of black screen occurrences to the total number of power-on / off cycles, focusing on the stability of the intelligent cockpit display function.

[0107] In addition, mean time between failures (MTBF) is an indicator of system reliability. It is based on the GB / T25000.51 standard and is calculated by dividing the total uptime by the number of failures, with a requirement that the result be no less than 200 hours.

[0108] Furthermore, the random event crash rate is an indicator reflecting the stability of a system in the face of random operations. It corresponds to the Monkey test, a random event test, and is calculated as the ratio of crashes to the total number of events, reflecting the system's resilience to interference.

[0109] Furthermore, average resource utilization is an indicator reflecting system resource consumption. It includes average CPU utilization, average memory utilization, etc., and is calculated by summing the resource utilization of all sampling points and dividing by the number of sampling points.

[0110] Understandably, based on the collected test process data, various quantitative test indicators are calculated separately. Functional pass rate is calculated by dividing the number of test cases by the total number of test cases and then multiplying by 100%; black screen occurrence rate is calculated by dividing the number of black screens by the number of power-on / off cycles and then multiplying by 100%; mean time between failures (MTBF) is calculated by dividing the total runtime by the number of failures; random event crash rate is calculated by dividing the number of crashes by the total number of events and then multiplying by 100%; average resource utilization is calculated by summing the resource utilization of all sample points and dividing by the number of sample points.

[0111] Step S62: When all the test quantitative indicators meet the corresponding threshold requirements, the stability test result is determined to be a test success. Understandably, each calculated quantitative test indicator is compared with its corresponding threshold requirement. For example, the functional pass rate must be ≥99%, the black screen occurrence rate must be ≤1%, the mean time between failures (MTBF) must be ≥200 hours, the random event crash rate must be 0%, and the average CPU utilization rate must be ≤70%. When all indicators meet their respective threshold requirements, the stability test result is considered to have passed the test.

[0112] Step S63: When there is a test quantification index that does not meet the corresponding threshold requirement, the stability test result is determined to be unqualified.

[0113] Understandably, each calculated quantitative test indicator is compared with its corresponding threshold requirement. If any indicator fails to meet its corresponding threshold requirement, such as a random event crash rate exceeding 0% or a mean time between failures (MTBF) below 200 hours, the stability test result is determined to be unsatisfactory, regardless of whether other indicators meet the standards.

[0114] In one possible implementation, after step S60, the following may also be included: When the stability test result is satisfactory, a satisfactory test report is generated, which includes a trend chart of quantitative test indicators and data distribution. When the stability test result is unsatisfactory, a root cause analysis report is generated, which includes test process data before and after the associated anomaly timestamp. The stability test result is compared and analyzed with historical test results to obtain the fluctuation of quantitative test indicators. Based on the fluctuation and the satisfactory test report or root cause analysis report, test optimization suggestions are generated to adjust the stability test strategy.

[0115] It should be noted that the compliance test report is a comprehensive report generated when the stability test results show that the test has met the standards. It includes trend charts of quantitative test indicators and data distribution. The trend charts show the changing trends of each indicator, and the data distribution shows the distribution characteristics of the test data, providing a clear basis for project stability assessment.

[0116] Additionally, the root cause analysis report is an issue analysis report generated when stability testing results show that the test failed to meet standards. Its core components include test process data before and after the timestamp of the anomaly. By integrating this data, it uncovers the root cause of the anomaly, providing targeted support for problem remediation.

[0117] Additionally, historical test results comprise test data and conclusions from previous stability tests conducted on similar smart cockpit projects. This includes key information such as quantitative test indicators, compliance status, and test reports from past projects, serving as a benchmark for comparing the results of this test.

[0118] Furthermore, the volatility profile is derived by comparing and analyzing the results of this stability test with historical test results. It presents the fluctuation range and trend of the quantitative indicators through methods such as box plots, clearly demonstrating the differences between the current test indicators and historical benchmarks.

[0119] Furthermore, the test optimization suggestions are targeted recommendations generated based on indicator fluctuations and compliance test reports or root cause analysis reports. They are used to guide adjustments to stability testing strategies, making the strategies more aligned with the actual project situation and achieving dynamic optimization.

[0120] Understandably, when the stability test result is satisfactory, a satisfactory test report is automatically generated. The report includes trend charts of quantitative test indicators such as pass rate trend charts and resource consumption curves, and data distribution information such as defect distribution pie charts. This content is automatically archived to the knowledge base. When the stability test result is unsatisfactory, root cause analysis is triggered and a root cause analysis report is generated. The report links test process data before and after the abnormal timestamp, including key information such as peak resource usage, CAN signal mutations, and changes in screen RGB values. Then, the various quantitative test indicators of this stability test are compared and analyzed with data from similar projects in historical test results. Box plots are used to analyze the fluctuation range and trend of the indicators, obtaining the fluctuation situation of the quantitative test indicators. Finally, combining this fluctuation situation with the previously generated satisfactory test report or root cause analysis report, test optimization suggestions are generated. In this embodiment, if the black screen occurrence rate of three consecutive iterations is <0.5%, an optimization suggestion is generated to adjust the black screen cycle count of the iteration from 100 to 50. This suggestion is manually reviewed and used to adjust the stability test strategy.

[0121] This embodiment provides a stability testing method for intelligent cockpits. It automatically calculates quantitative indicators such as function pass rate, black screen occurrence rate, mean time between failures (MTBF), random event crash rate, and average resource utilization rate. Based on corresponding thresholds, it strictly determines whether the test meets the standards. When standards are met, it generates a compliance test report including trend charts and distribution data; when standards are not met, it generates a root cause analysis report including the correlation between data before and after the abnormal timestamp. Furthermore, it compares the current results with historical similar projects to obtain indicator fluctuations and automatically generates test optimization suggestions to guide dynamic strategy adjustments. This method solves the technical problems in existing technologies, such as the lack of unified quantitative standards for test results, the inability to automatically determine compliance, the lack of comparison with historical data, and the lack of a strategy self-optimization mechanism, leading to highly subjective test conclusions, low problem location efficiency, and static and rigid test strategies that are difficult to continuously improve. It achieves the beneficial effects of objectively quantifying test results, automatically determining compliance, and pinpointing root causes within seconds.

[0122] For example, to help understand the implementation process of the intelligent cockpit stability testing method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 8 , Figure 8 A simplified flowchart of a stability testing method for an intelligent cockpit is provided, specifically: The process originates from four external data sources: GitLab or SVN repository, historical defect database, project management system, and hardware configuration management repository. The project feature extraction unit obtains the list of commit and change files via API, queries historical defect rates via SQL, obtains iteration cycles via API, and extracts feature data by comparing hardware version numbers. This data is then fed into the project type determination engine, which outputs a project type label based on built-in rules. The strategy knowledge base loads the corresponding strategy quadruple based on this label. The script generation and scheduling unit converts the strategy into an executable script and distributes it to the test bench cluster. The cluster consists of two hardware layers: a core test bench and extended test benches. The core test bench comprises a programmable power supply, a high-definition industrial camera, a CAN analyzer, and the vehicle's infotainment system under test. The extended test benches are additionally equipped with a voice isolation box, a WiFi / Bluetooth jammer, and a temperature and humidity chamber. The IO control unit receives platform commands based on an STM32 or Arduino controller and precisely executes physical operations such as power on / off, camera triggering, and signal shielding. During testing, real-time data streams from the high-definition camera, CAN analyzer, and the vehicle's infotainment system are aggregated into a Redis in-memory database. A process data cache continuously supplies logs and resource data to the data acquisition and analysis module. The anomaly detection engine uses regular expression matching and an isolated forest model to scan the data stream in parallel, marking abnormal events in real time and writing them to Redis. The root cause analysis unit then acquires complete test data and aligns anomalies with resource peaks, signal mutations, and screen image changes through time-series correlation analysis, outputting the localization results. The quantitative judgment engine generates test reports or problem localization reports by comprehensively considering pass rate, black screen rate, MTBF, and crash rate metrics. Simultaneously, it compares historical data to generate strategy optimization suggestions, which are then pushed to the development team to ensure accurate matching and continuous evolution of test resources and project risks.

[0123] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the stability testing method of the smart cockpit of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0124] This application also provides a stability testing device for an intelligent cockpit, please refer to... Figure 9 The stability testing device for the intelligent cockpit includes: Data acquisition module 10 is used to acquire test requirement data, version management data, hardware configuration information and historical defect data of the smart cockpit project to be tested; Project feature analysis module 20 is used to perform project feature analysis based on the test requirement data, the version management data, the hardware configuration information and the historical defect data to obtain project feature information; The project type determination module 30 is used to determine the project type based on the project feature information to obtain the target project type. The strategy determination module 40 is used to generate a stability testing strategy corresponding to the target project type based on the target project type, thereby obtaining the target stability testing strategy. The stability testing module 50 is used to perform automated stability testing according to the target stability testing strategy and collect test process data. The quantitative analysis module 60 is used to perform quantitative analysis based on the test process data to obtain stability test results.

[0125] The intelligent cockpit stability testing device provided in this application, employing the intelligent cockpit stability testing method described in the above embodiments, can solve the technical problem of mismatch between testing resource investment and actual stability risks during intelligent cockpit stability testing, making it difficult to simultaneously ensure quality and test efficiency and reliability. Compared with the prior art, the beneficial effects of the intelligent cockpit stability testing device provided in this application are the same as those of the intelligent cockpit stability testing method provided in the above embodiments, and other technical features in the intelligent cockpit stability testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0126] In one embodiment, the project feature analysis module 20 is further configured to extract version iteration cycle and code change scale information from the version management data; extract hardware version identification information from the hardware configuration information; statistically analyze the frequency of historical defects and the distribution of defect levels from the historical defect data; and perform project feature analysis on the version iteration cycle, the code change scale information, the hardware version identification information, the frequency of historical defects, and the distribution of defect levels to obtain project feature information.

[0127] In one embodiment, the project type determination module 30 is further configured to obtain a first iteration cycle duration, a first defect occurrence rate threshold, a second iteration cycle duration, and a second defect occurrence rate threshold, wherein the first iteration cycle duration is longer than the second iteration cycle duration, and the first defect occurrence rate threshold is less than the second defect occurrence rate threshold; when the project feature information satisfies at least one of the following: the version iteration cycle is greater than or equal to the first iteration cycle duration, the hardware version identification information is unchanged, the code change scale information is a functional change, and the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is less than or equal to the first defect occurrence rate threshold, the target project type is determined to be an iterative project; when the project feature information satisfies at least one of the following: the hardware version identification information is a version change, the version iteration cycle is less than the second iteration cycle duration, and the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is greater than the second defect occurrence rate threshold, the target project type is determined to be a new project.

[0128] In one embodiment, the strategy determination module 40 is further configured to determine a focused stability testing strategy as the target stability testing strategy when the target project type is an iterative project, wherein the focused stability testing strategy includes functional testing, change-point functional stress testing, and black screen testing; and to determine a comprehensive stability testing strategy as the target stability testing strategy when the target project type is a brand new project, wherein the comprehensive stability testing strategy includes a combination of test modules such as full-function stress testing, mean time between failures (MTBF) testing, random event testing, full-specific testing, and resource monitoring testing.

[0129] In one embodiment, the stability testing module 50 is further configured to load corresponding test steps from a preset test case library according to the target stability testing strategy, generate a testable script; perform automated stability testing according to the testable script, and collect system log data, memory resource usage data, function operation result data, and abnormal event data in the automated stability testing; and determine test process data based on the system log data, the memory resource usage data, the function operation result data, and the abnormal event data.

[0130] In one embodiment, the quantitative analysis module 60 is further configured to calculate test quantitative indicators based on the test process data, wherein the test quantitative indicators include functional pass rate, black screen occurrence rate, mean time between failures (MTBF), random event crash rate, and average resource utilization rate; when all the test quantitative indicators meet the corresponding threshold requirements, the stability test result is determined to be a test that meets the standards; when there are test quantitative indicators that do not meet the corresponding threshold requirements, the stability test result is determined to be a test that does not meet the standards.

[0131] In one embodiment, the quantitative analysis module 60 is further configured to: generate a pass / fail test report when the stability test result is a pass / fail result, wherein the pass / fail test report includes a trend chart of test quantitative indicators and data distribution; generate a root cause analysis report when the stability test result is a fail / fail result, wherein the root cause analysis report includes test process data before and after the associated anomaly timestamp; compare and analyze the stability test result with historical test results to obtain the fluctuation of test quantitative indicators; and generate test optimization suggestions based on the fluctuation and the pass / fail test report or root cause analysis report, so as to adjust the stability test strategy according to the test optimization suggestions.

[0132] This application provides a stability testing device for a smart cockpit. The smart cockpit stability testing device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the smart cockpit stability testing method in the first embodiment described above.

[0133] The following is for reference. Figure 10 The diagram illustrates a structural schematic of a stability testing device suitable for implementing the embodiments of this application's intelligent cockpit. The stability testing device for the intelligent cockpit in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The stability testing equipment for the smart cockpit shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0134] like Figure 10As shown, the stability testing equipment for the intelligent cockpit may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the stability testing equipment for the intelligent cockpit. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the smart cockpit stability testing equipment to communicate wirelessly or wiredly with other devices to exchange data. Although a smart cockpit stability testing equipment with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0135] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0136] The intelligent cockpit stability testing equipment provided in this application, employing the intelligent cockpit stability testing method described in the above embodiments, can solve the technical problem of mismatch between testing resource investment and actual stability risks during intelligent cockpit stability testing, making it difficult to simultaneously ensure quality and test efficiency and reliability. Compared with the prior art, the beneficial effects of the intelligent cockpit stability testing equipment provided in this application are the same as those of the intelligent cockpit stability testing method provided in the above embodiments, and other technical features of this intelligent cockpit stability testing equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0137] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0138] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0139] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the stability testing method for the smart cockpit in the above embodiments.

[0140] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0141] The aforementioned computer-readable storage medium may be included in the stability testing equipment for the smart cockpit; or it may exist independently and not be installed in the stability testing equipment for the smart cockpit.

[0142] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the stability testing equipment for the intelligent cockpit, the stability testing equipment for the intelligent cockpit performs the following actions: acquires test requirement data, version management data, hardware configuration information, and historical defect data of the intelligent cockpit project to be tested; performs project feature analysis based on the test requirement data, version management data, hardware configuration information, and historical defect data to obtain project feature information; determines the project type based on the project feature information to obtain a target project type; generates a stability testing strategy corresponding to the target project type to obtain a target stability testing strategy; performs automated stability testing based on the target stability testing strategy and collects test process data; and performs quantitative analysis based on the test process data to obtain stability test results.

[0143] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0145] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0146] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described intelligent cockpit stability testing method. This solves the technical problem of mismatch between testing resource investment and actual stability risks during intelligent cockpit stability testing, making it difficult to balance testing efficiency and reliability while ensuring quality. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the intelligent cockpit stability testing method provided in the above embodiments, and will not be elaborated upon here.

[0147] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described intelligent cockpit stability testing method.

[0148] The computer program product provided in this application can solve the technical problem of mismatch between test resource investment and actual stability risks during intelligent cockpit stability testing, making it difficult to ensure both test efficiency and reliability while guaranteeing quality. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the intelligent cockpit stability testing method provided in the above embodiments, and will not be repeated here.

[0149] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for testing the stability of an intelligent cockpit, characterized in that, The method includes: Obtain test requirement data, version management data, hardware configuration information, and historical defect data for the smart cockpit project to be tested; Based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data, project feature analysis is performed to obtain project feature information; Based on the project characteristic information, the project type is determined to obtain the target project type; Generate a stability testing strategy corresponding to the target project type based on the target project type, and obtain the target stability testing strategy; Perform automated stability testing according to the target stability testing strategy and collect test process data; The stability test results are obtained by performing quantitative analysis on the test process data.

2. The method as described in claim 1, characterized in that, The step of performing project feature analysis based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data to obtain project feature information includes: Extract version iteration cycle and code change scale information from the version management data; Extract hardware version identification information from the hardware configuration information; The frequency of historical defects and the distribution of defect levels are statistically analyzed from the historical defect data. Project feature information is obtained by performing project feature analysis on the version iteration cycle, code change scale information, hardware version identification information, historical defect occurrence frequency information, and defect level distribution information.

3. The method as described in claim 1, characterized in that, The step of determining the project type based on the project feature information to obtain the target project type includes: The duration of the first iteration cycle, the first defect incidence rate threshold, the duration of the second iteration cycle, and the second defect incidence rate threshold are obtained, wherein the duration of the first iteration cycle is longer than the duration of the second iteration cycle, and the first defect incidence rate threshold is less than the second defect incidence rate threshold. When the project feature information satisfies at least one of the following conditions: the version iteration cycle is greater than or equal to the duration of the first iteration cycle, the hardware version identification information is unchanged, the code change scale information is a functional change, and the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is less than or equal to the first defect occurrence rate threshold, the target project type is determined to be an iterative project. When the project feature information satisfies at least one of the following: the hardware version identification information is a version change, the version iteration cycle is less than the duration of the second iteration cycle, or the defect occurrence rate of the historical defect occurrence frequency information or defect level distribution information is greater than the second defect occurrence rate threshold, the target project type is determined to be a brand new project.

4. The method as described in claim 1, characterized in that, The step of generating a stability testing strategy corresponding to the target project type based on the target project type, and obtaining the target stability testing strategy, includes: When the target project type is an iterative project, a focused stability testing strategy is determined as the target stability testing strategy, wherein the focused stability testing strategy includes functional testing, change point functional stress testing, and black screen testing; When the target project type is a brand new project, a comprehensive stability testing strategy is determined as the target stability testing strategy. The comprehensive stability testing strategy includes a combination of test modules such as full-function stress testing, mean time between failures (MTBF) testing, random event testing, full-specific testing, and resource monitoring testing.

5. The method as described in claim 1, characterized in that, The steps of performing automated stability testing and collecting test process data according to the target stability testing strategy include: According to the target stability testing strategy, the corresponding test steps are loaded from the preset test case library to generate a testable script; Perform automated stability testing based on the testable script, and collect system log data, memory resource usage data, function operation result data, and abnormal event data during the automated stability testing. The test process data is determined based on the system log data, the memory resource usage data, the function operation result data, and the abnormal event data.

6. The method as described in claim 1, characterized in that, The step of performing quantitative analysis based on the test process data to obtain the stability test results includes: The test quantitative indicators are calculated based on the test process data, including the functional pass rate, black screen occurrence rate, mean time between failures, random event crash rate, and average resource utilization rate. When all the quantitative indicators of the test meet the corresponding threshold requirements, the stability test result is determined to be satisfactory. If any of the test quantification indicators fails to meet the corresponding threshold requirements, the stability test result is determined to be unsatisfactory.

7. The method as described in claim 1, characterized in that, After the step of performing quantitative analysis based on the test process data to obtain the stability test results, the method further includes: When the stability test result is satisfactory, a satisfactory test report is generated, which includes a trend chart of quantitative test indicators and data distribution. When the stability test result is that the test fails, a root cause analysis report is generated, wherein the root cause analysis report includes test process data before and after the associated anomaly timestamp; By comparing and analyzing the stability test results with historical test results, the fluctuation of the quantitative test indicators can be obtained. Based on the fluctuations and the compliance test report or root cause analysis report, test optimization suggestions are generated to adjust the stability test strategy according to the test optimization suggestions.

8. A stability testing device for an intelligent cockpit, characterized in that, The device includes: The data acquisition module is used to acquire test requirement data, version management data, hardware configuration information, and historical defect data of the smart cockpit project to be tested. The project feature analysis module is used to perform project feature analysis based on the test requirement data, the version management data, the hardware configuration information, and the historical defect data to obtain project feature information; The project type determination module is used to determine the project type based on the project feature information to obtain the target project type. The strategy determination module is used to generate a stability testing strategy corresponding to the target project type based on the target project type, thereby obtaining the target stability testing strategy. The stability testing module is used to perform automated stability testing according to the target stability testing strategy and collect test process data; The quantitative analysis module is used to perform quantitative analysis on the test process data to obtain stability test results.

9. A stability testing device for an intelligent cockpit, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the stability testing method for an intelligent cockpit as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the stability testing method for the intelligent cockpit as described in any one of claims 1 to 7.

Images