Vehicle testing methods, apparatus, vehicles, and storage media

Abstract

This invention discloses a vehicle testing method, apparatus, vehicle, and storage medium. The vehicle testing method includes: acquiring vehicle model and target object profile data; determining multiple function weight coefficients for multiple required test functions of the vehicle based on the profile data and vehicle model, wherein each required test function corresponds to one function weight coefficient; determining multiple test priorities for the multiple required test functions based on the multiple function weight coefficients, wherein each required test function corresponds to one test priority; and testing the multiple required test functions based on the multiple test priorities. This invention solves the technical problem of unreasonable allocation of test resources in the prior art for testing intelligent cockpit functions.

Description

Technical Field

[0001] This invention relates to the field of automation control technology, and more specifically, to a vehicle testing method, apparatus, vehicle, and storage medium. Background Technology

[0002] As the functions integrated into vehicle smart cockpits become increasingly complex, how to conduct efficient and comprehensive testing and verification during software releases has become a critical issue for the industry. In practical applications, due to limited testing resources, a scientific method is needed to guide the allocation of testing resources, ensuring that high-value, frequently used functions receive sufficient test coverage to meet the demands of agile development.

[0003] However, existing technologies have the following shortcomings: First, the allocation of testing resources lacks a scientific basis. Existing methods (such as experience-based focused testing) rely on subjective judgment and lack a systematic evaluation model, resulting in insufficient depth of testing for high-frequency functions, while low-frequency functions may consume a large amount of resources. Second, they fail to consider actual user behavior. Different user groups have significant differences in the frequency and importance they attach to functions, and existing methods (such as defect history analysis) fail to take this into account. In addition, existing test evaluations mostly focus on function enabling, lacking a comprehensive evaluation of multiple dimensions such as performance, stability, user experience, compatibility, and security.

[0004] There is currently no effective solution to the above-mentioned technical problems. Summary of the Invention

[0005] This invention provides a vehicle testing method, apparatus, vehicle, and storage medium to at least address the technical problem of unreasonable allocation of testing resources for intelligent cockpit function testing in the prior art.

[0006] According to one embodiment of the present invention, a vehicle testing method is provided, comprising: acquiring vehicle model and target object profile data; determining multiple function weight coefficients for multiple required test functions of the vehicle based on the profile data and vehicle model, wherein each required test function corresponds to a function weight coefficient; determining multiple test priorities for the multiple required test functions based on the multiple function weight coefficients, wherein each required test function corresponds to a test priority; and testing the multiple required test functions based on the multiple test priorities.

[0007] Optionally, the vehicle testing method may also include: determining the target object based on the vehicle model; obtaining the target object's historical operation logs and platform object data; and determining profile data based on the historical operation logs and platform object data.

[0008] Optionally, the vehicle testing method further includes: determining multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement test functions of the target object; sorting the multiple requirement test functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged from largest to smallest according to the value of the corresponding target frequency; and determining profile data based on the target function sequence.

[0009] Optionally, the vehicle testing method further includes: determining multiple first weight coefficients for multiple requirement testing functions based on profile data; determining multiple second weight coefficients for multiple requirement testing functions based on vehicle model; and determining multiple function weight coefficients based on the multiple first weight coefficients and the multiple second weight coefficients.

[0010] Optionally, the vehicle testing method further includes: determining the testing frequency of the requirement testing function based on the test priority corresponding to the requirement testing function; determining the test allocation resources and test execution plan for the requirement testing function based on the test frequency; and testing the requirement testing function based on the test allocation resources and test execution plan.

[0011] Optionally, the vehicle testing method may also include: obtaining the vehicle's historical test logs; and updating the weight coefficients of multiple functions based on the historical test logs.

[0012] According to one embodiment of the present invention, a vehicle testing apparatus is also provided, comprising: a first acquisition module, configured to acquire vehicle model and target object profile data; a first determination module, configured to determine multiple function weight coefficients for multiple required test functions of the vehicle based on the profile data and vehicle model, wherein each required test function corresponds to one function weight coefficient; a second determination module, configured to determine multiple test priorities for the multiple required test functions based on the multiple function weight coefficients, wherein each required test function corresponds to one test priority; and a testing module, configured to test the multiple required test functions based on the multiple test priorities.

[0013] Optionally, the first acquisition module includes: a first determining unit, used to determine the target object based on the vehicle model; an acquisition unit, used to acquire the target object's historical operation logs and platform object data; and a second determining unit, used to determine profile data based on the historical operation logs and platform object data.

[0014] Optionally, the second determining unit includes: a first determining subunit, used to determine multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement testing functions of the target object; a sorting subunit, used to sort the multiple requirement testing functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement testing functions in the target function sequence are arranged in descending order according to the numerical value of their corresponding target frequencies; and a second determining subunit, used to determine profile data based on the target function sequence.

[0015] Optionally, the first determining module includes: a third determining unit, used to determine multiple first weight coefficients for multiple requirement testing functions based on profile data; a fourth determining unit, used to determine multiple second weight coefficients for multiple requirement testing functions based on vehicle model; and a fifth determining unit, used to determine multiple function weight coefficients based on multiple first weight coefficients and multiple second weight coefficients.

[0016] Optionally, the testing module includes: a sixth determining unit, used to determine the testing frequency of the requirement testing function based on the test priority corresponding to the requirement testing function; a seventh determining unit, used to determine the test allocation resources and test execution plan of the requirement testing function based on the test frequency; and a testing unit, used to test the requirement testing function based on the test allocation resources and test execution plan.

[0017] Optionally, the vehicle testing device further includes: a second acquisition module for acquiring historical test logs of the vehicle; and an update module for updating multiple functional weight coefficients based on the historical test logs.

[0018] According to one embodiment of the present invention, a vehicle is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the test method for the vehicle described in any of the preceding claims.

[0019] According to one embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the vehicle testing method described in any of the preceding claims.

[0020] According to one embodiment of the present invention, a non-volatile storage medium is also provided, wherein a computer program is stored in the non-volatile storage medium, wherein the computer program is configured to execute the vehicle testing method described in any of the above embodiments when running.

[0021] According to one embodiment of the present invention, a computer program product is also provided, which stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the vehicle testing method described in any of the above claims.

[0022] In this embodiment of the invention, by acquiring vehicle model and target object profile data, and determining multiple functional weight coefficients for multiple required test functions of the vehicle based on the profile data and vehicle model, wherein each required test function corresponds to a functional weight coefficient, the purpose of determining multiple test priorities for multiple required test functions based on multiple functional weight coefficients is achieved, wherein each required test function corresponds to a test priority, thereby achieving the technical effect of testing multiple required test functions based on multiple test priorities, and thus solving the technical problem of unreasonable allocation of test resources for intelligent cockpit function testing in the prior art. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0024] Figure 1 This is a flowchart of a vehicle testing method according to one embodiment of the present invention;

[0025] Figure 2 This is a flowchart of a method for acquiring portrait data according to one embodiment of the present invention;

[0026] Figure 3 This is a flowchart of a method for calculating functional weight coefficients according to one embodiment of the present invention;

[0027] Figure 4 This is a structural block diagram of a vehicle testing apparatus according to one embodiment of the present invention;

[0028] Figure 5 This is a structural block diagram of an electronic device according to one embodiment of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] According to an embodiment of the present invention, an embodiment of a vehicle testing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system containing at least one set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] This method embodiment can also be executed in an electronic device, similar control device, or vehicle-mounted terminal that includes a memory and a processor. Taking a vehicle-mounted terminal as an example, the vehicle-mounted terminal may include one or more processors and a memory for storing data. Optionally, the vehicle-mounted terminal may also include a communication device for communication functions and a display device. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the vehicle-mounted terminal. For example, the vehicle-mounted terminal may include more or fewer components than those described above, or have a different configuration than those described above.

[0033] A processor may include one or more processing units. For example, a processor may include a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processing (DSP) chip, a microprocessor, a field-programmable gate array (FPGA), a neural network processing unit (NPU), a tensor processing unit (TPU), or an artificial intelligence (AI) type processor. Different processing units may be independent components or integrated into one or more processors. In some instances, electronic devices may also include one or more processors.

[0034] The memory can be used to store computer programs, such as the computer program corresponding to the vehicle testing method in this embodiment of the invention. The processor implements the vehicle testing method by running the computer program stored in the memory. The memory may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to electronic devices via a grid. Examples of such grids include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] The communication device is used to receive or transmit data via a grid. Specific examples of the aforementioned grid may include a wireless grid provided by the mobile terminal's communication provider. In one example, the communication device includes a network interface controller (NIC), which can connect to other grid devices via a base station to communicate with the Internet. In another example, the communication device may be a radio frequency (RF) module used for wireless communication with the Internet. In some embodiments of this solution, the communication device is used to connect to mobile devices such as mobile phones and tablets, enabling the mobile device to send commands to the vehicle-mounted terminal.

[0036] The display device can be a touchscreen liquid crystal display (LCD) or a touch display (also referred to as a "touchscreen" or "touch display screen"). This LCD allows the user to interact with the user interface of the in-vehicle terminal. In some embodiments, the in-vehicle terminal has a graphical user interface (GUI), allowing the user to interact with the GUI through finger contact and / or gestures on a touch-sensitive surface. The human-machine interaction function may include a vehicle gear shifting function, and executable instructions for performing these functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0037] Figure 1 This is a flowchart of a vehicle testing method according to one embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0038] Step S101: Obtain the vehicle model and the profile data of the target object.

[0039] Optionally, the execution subject in this embodiment is a vehicle testing system. It should be noted that other electronic devices and processors can also serve as the execution subject, and no further limitations are imposed here.

[0040] In the technical solution provided by step S101 of the present invention, before the test begins, the system or tester first needs to identify the test object. Different car models (such as sedans and SUVs) or different configuration versions may have differences in the hardware configuration (such as the number of screens and chip performance) and software function set of their intelligent cockpits. Therefore, determining the vehicle model is to determine the boundaries of subsequent function classification and test scope.

[0041] Furthermore, the system needs to collect and construct multi-dimensional characteristic data of the target user group for this vehicle model. Specifically, it needs to collect basic user attributes, such as age, gender, driving experience, and location; it also needs to collect behavioral characteristics, such as analyzing user operation logs on the vehicle's infotainment system, including the frequency, duration, and common time periods and scenarios for function usage. In addition, it can also collect data on user preferences for functions, willingness to pay, historical complaint records, ratings, and suggestions.

[0042] In this application, the target audience refers to the actual users of the smart cockpit (i.e., vehicle owners or drivers). In the testing context, the target audience represents user groups with different characteristics in the real world, and the purpose of the test is to verify whether the cockpit functions meet the needs of these users.

[0043] The aforementioned user profile data refers to a multi-dimensional user profile constructed based on user behavior data. It is not a single data point, but a set of labeled data. Specifically, in this application, it refers to the basis used to quantify the importance of functions, including basic user attributes (age, driving experience, etc.), usage behavior characteristics (frequency, duration, etc.), function preference characteristics (frequently used, liked, etc.), and feedback characteristics (complaints, ratings, etc.).

[0044] As an optional implementation, the system uses data collection points (embedded points) pre-installed at the vehicle's factory to record every click, swipe, and voice command made by the user on the in-vehicle infotainment system in real time. This data is uploaded to the vehicle networking platform via T-BOX. The backend system cleans and analyzes the massive user operation logs, automatically calculating the usage frequency and duration of each functional module (such as navigation, music, and air conditioning), thereby constructing objective behavioral profile data.

[0045] As an alternative implementation, the system distributes survey questionnaires to target users through online or offline channels, directly inquiring about their level of importance, liking, and willingness to pay for various functions. Simultaneously, user complaint records and feedback are exported from the after-sales service system. The subjective ratings from the questionnaires and the after-sales feedback text are then structured and transformed into quantifiable data on importance and feedback characteristics.

[0046] It's worth noting that the shift from reliance on subjective testers' experience to quantitative decision-making based on real user behavior data (such as usage frequency and complaint rates) eliminates the bias of human judgment. Furthermore, by introducing user profiles, it's possible to identify the true concerns of different user groups (e.g., younger users prioritize entertainment, while older users prioritize driver assistance), ensuring that testing resources are prioritized for the most frequently used functions, thereby maximizing user satisfaction with limited resources.

[0047] Step S102: Based on the profile data and vehicle model, determine multiple function weight coefficients for multiple requirement test functions of the vehicle, wherein each requirement test function corresponds to a function weight coefficient.

[0048] In the technical solution provided by step S102 of the present invention, the system analyzes the acquired user profile data to identify the main user group types of the vehicle model and their proportion in the total user base. For example, analysis reveals that among users of a certain vehicle model, 60% are "single users" and 40% are "family users." Therefore, the weight of the "single user" group is 0.6, and the weight of the "family user" group is 0.4, reflecting the importance of different user groups in the overall test.

[0049] Furthermore, for specific user groups, the importance of each specific function to that user group is calculated by combining their user profile data with usage behavior characteristics (such as function usage frequency) and function preference characteristics (such as favorite functions).

[0050] Furthermore, based on the vehicle model's positioning and version characteristics, weights are assigned to the five evaluation dimensions of the vehicle (functionality, performance / stability, user experience, compatibility, and safety). For example, if the vehicle being tested is a luxury model that emphasizes safety, the weight of the safety dimension may be set higher; if it is a model that emphasizes a smooth experience, the weight of performance / stability will be increased accordingly.

[0051] Finally, the user dimension weights are combined with the function weights in the user dimension, and the evaluation dimension weights and the actual performance of the function in each evaluation dimension are incorporated. Through weighted calculation, a comprehensive and quantitative function weight coefficient is generated for each requirement test function.

[0052] The aforementioned requirements testing functions refer to all intelligent cockpit functions that need to be tested on a specific vehicle model. Specifically, in this application, these functions can be pre-divided into six modules (cockpit control, vision, intelligent assisted driving interaction, entertainment and navigation, intelligent voice, and system-level applications), forming a complete test checklist.

[0053] The aforementioned functional weight coefficient is a quantifiable value used to characterize the overall importance and testing priority of a single functional point. A higher coefficient indicates that the functional point is more important to the target user, and therefore requires more resources to be allocated during testing. It serves as the direct basis for generating subsequent test plans (such as classifying core mandatory tests, key tests, etc.).

[0054] As an optional implementation, the system automatically reads user operation logs uploaded to the vehicle networking platform, and calculates the usage frequency and duration of each function. For example, it calculates that the daily usage frequency of the navigation planning function is much higher than that of the lighting control. Furthermore, this objective usage frequency data is directly used as the main input for calculating the weight value of the function in the user dimension. That is, the higher the frequency of use of a function, the higher its weight value.

[0055] As an alternative implementation, the system can also allow users to rate the importance of various functions directly through online questionnaires. Furthermore, the average rating of a function (such as "surround view") can be used as the basis for calculating its weight in the user dimension. This method can capture the user's subjective level of importance, and is particularly suitable for functions that are not frequently used but are crucial in critical moments (such as emergency rescue).

[0056] It is worth noting that transforming the vague concept of importance into precise functional weight coefficients provides a scientific and objective quantitative basis for the allocation of testing resources, effectively reducing subjective biases caused by relying on personal experience. Furthermore, it incorporates the vehicle model's positioning requirements for different quality dimensions such as safety and performance, ensuring that the final calculated weight coefficients more comprehensively and accurately reflect the overall value of each function.

[0057] Step S103: Determine multiple test priorities for multiple requirement test functions based on multiple function weight coefficients, wherein each requirement test function corresponds to one test priority.

[0058] In the technical solution provided by step S103 of the present invention, the system receives and summarizes the function weight coefficients of all required test functions, and arranges them in descending order or divides them into intervals according to their numerical values. For example, in the case of a smart cockpit containing hundreds of functions, the system will first identify the functions with the highest weight coefficients (such as navigation and voice interaction), and place them at the top of the list, thereby macroscopically determining which functions need to be prioritized for testing.

[0059] Furthermore, based on preset mapping rules or thresholds, continuous functional weight coefficient values ​​are transformed into discrete test priority levels. For example, the system sets functions with weight coefficients between 0.8 and 1.0 to be mapped as "core mandatory test (P0)", those between 0.6 and 0.8 to "key test (P1)", those between 0.4 and 0.6 to "routine test (P2)", and those below 0.4 to "low priority (P3)". Through this mapping, abstract weights are transformed into priority labels that testers can directly recognize.

[0060] Finally, the determined test priority tags are bound to the corresponding required test functions one by one, generating a final test priority list. Specifically, the system will output a list containing all functions and their priorities. During test execution, the system or testers only need to execute test cases in the order of this list (e.g., P0 first, then P1) to ensure that high-weight functions are verified first.

[0061] The test priority mentioned above refers to the order in which various test tasks or test cases are executed or their level of importance during the test execution process. It is usually represented by labels such as P0 (highest), P1 (high), P2 (medium), and P3 (low), which directly determine the allocation order of test resources (time, manpower, equipment).

[0062] The above mapping rule refers to a preset algorithm or threshold standard that converts the calculated continuous numerical values ​​(functional weight coefficients) into discrete labels (test priorities).

[0063] As an optional implementation, the boundary thresholds for the weighting coefficients (such as 0.8, 0.6, 0.4) can be pre-set by testing experts or the system. After calculating the weighting coefficients for all functions, the system directly substitutes the values ​​into the intervals for comparison, assigning the corresponding test priority (P0 / P1 / P2 / P3) to the interval in which the value falls.

[0064] As an alternative implementation, the system does not set a fixed absolute threshold. Instead, it allocates priorities in descending order of weight coefficients based on the total testing resources available in the current testing cycle (such as total working hours or total number of devices). For example, if resources are only sufficient to test the first 30% of the functions, then these 30% of functions are automatically assigned the highest priority, and the rest are downgraded accordingly.

[0065] It's worth noting that by directly translating the calculated objective weighting coefficients into explicit test priorities, test execution no longer relies on testers' subjective experience or traditional fixed sequences, but rather proceeds strictly according to user value and functional importance. Furthermore, through clear priority division, it ensures that high-value, frequently used core functions are verified first when testing time is tight or resources are limited, thereby exposing high-risk defects as early as possible and maximizing the return on investment in testing.

[0066] Step S104: Test multiple requirement test functions based on multiple test priorities.

[0067] In the technical solution provided by step S104 of the present invention, the system reads the determined test priorities, sorts all required test functions according to their priority, and generates a test task queue with an execution order. During the test execution phase, the test platform or testers no longer randomly select functions, but directly call the queue. The high-priority functions at the front of the queue (such as P0-level core mandatory test functions) will be automatically retrieved by the system and prepared to enter the test process.

[0068] Furthermore, based on the priority of the functions in the current test queue, the system dynamically allocates corresponding test resources (such as test equipment, automated test scripts, and test personnel man-hours). Specifically, for high-priority functions that are ranked first, the system will prioritize allocating the best-performing and most stable test benches or equipment, or prioritize triggering automated regression tests; while for low-priority functions that are ranked later, testing will be conducted when resources are available.

[0069] Finally, test cases for each required testing function are triggered sequentially according to the queue order, and the pass, failure, or blocking status of the tests is recorded in real time. Specifically, testers or automated scripts begin executing tests for high-priority functions. If insufficient time is found during the testing process, the system can ensure that high-priority functions have been tested, while low-priority functions, even if skipped, will not affect the release quality of the core version of the vehicle.

[0070] The aforementioned test execution queue refers to the list of tasks generated by the system according to test priority, which specifies the order in which test tasks are executed.

[0071] The aforementioned test resource scheduling refers to the actions of rationally allocating and managing limited test elements (including testers, test equipment, test environment, test time, etc.) during the testing process. Specifically, in this application, it refers to allocating these resources preferentially according to their priority.

[0072] As an optional implementation, the system imports a priority list of test tasks into the automated testing platform. The platform, according to a predefined strategy, prioritizes triggering automated test scripts for P0-level functions. If there are multiple test devices, all devices are given priority to execute high-priority tasks in parallel. Once all high-priority tasks are completed, lower-priority tasks are then assigned to other devices.

[0073] As an alternative implementation, test priorities can be transformed into a visual task dashboard. After testers log into the dashboard, the system automatically prioritizes high-priority tasks. Testers then claim and execute these prioritized tasks daily, only claiming lower-priority tasks when all high-priority tasks are cleared or blocked.

[0074] It's worth noting that directly translating the preliminary quantitative assessment results into the actual test execution sequence allows the entire testing process to proceed sequentially, avoiding the blind spots and arbitrariness that testers might encounter when facing multiple functionalities. Furthermore, by prioritizing the execution of high-priority tasks, it ensures that core, high-frequency, and high-risk functions are verified first, even under extreme circumstances of tight testing time or limited resources. This minimizes the risk of dangerous defects before release, guaranteeing a superior intelligent cockpit experience for users.

[0075] Steps S101 to S104 above show that, in this invention, by acquiring vehicle model and target object profile data, and determining multiple functional weight coefficients for multiple required test functions of the vehicle based on the profile data and vehicle model, each required test function corresponds to one functional weight coefficient. This achieves the purpose of determining multiple test priorities for multiple required test functions based on multiple functional weight coefficients, where each required test function corresponds to one test priority. This achieves the technical effect of testing multiple required test functions based on multiple test priorities, thereby solving the technical problem of unreasonable allocation of test resources for intelligent cockpit function testing in the prior art.

[0076] The method described in this embodiment will now be described in further detail.

[0077] Step S201: Determine the target object based on the vehicle model;

[0078] Step S202: Obtain the historical operation logs and platform object data of the target object;

[0079] Step S203: Determine profile data based on historical operation logs and platform object data.

[0080] In this embodiment, such as Figure 2 As shown, specific vehicle models are used as search criteria or filter tags to select specific user groups from the database that match the characteristics of that vehicle model. For example, because the target audiences of different vehicle models (such as family SUVs and sports sedans) differ significantly, the system first needs to filter by vehicle model to ensure that the subsequently extracted data comes only from real owners of that model, avoiding interference from data from users of other models.

[0081] Furthermore, through the vehicle network interface or backend database, two types of data are retrieved from the aforementioned targeted users: first, "historical operation logs" generated by the user on the vehicle's infotainment system (such as data from clicks, swipes, and voice commands); and second, "platform object data" stored in the cloud or business systems (such as user registration information, membership level, vehicle configuration, and after-sales maintenance records). Specifically, historical operation logs reflect the user's objective behavior, while platform object data supplements the user's basic attributes and static tags; the combination of the two can form a complete understanding of the user.

[0082] Furthermore, the two types of raw data are cleaned, correlated, and fused to extract structured tags that represent user characteristics, ultimately generating user profile data specific to the vehicle model. Specifically, the system cross-references objective behavior logs with static platform data (e.g., associating operation logs of "frequent navigation use" with platform attributes of "frequent long-distance inter-provincial travel") to extract accurate user profiles (e.g., "navigation-dependent long-distance commuters"), providing a reliable data foundation for subsequent calculations of function weights.

[0083] The aforementioned historical operation logs refer to the time-series data automatically recorded by the system when users interact with the intelligent cockpit vehicle infotainment system. This includes, but is not limited to, interface clicks, menu switching, voice wake-up and commands, and function usage duration, and is core objective data reflecting users' actual usage habits.

[0084] The aforementioned platform object data refers to structured business data bound to users or vehicles within the vehicle manufacturer's or connected vehicle cloud platform. This typically includes static information such as basic user attributes (age, gender, region), vehicle configuration information, membership benefits, historical orders, and after-sales feedback.

[0085] The aforementioned profile data refers to a structured set of user features generated through the fusion and analysis of multi-source data.

[0086] As an optional implementation, the system utilizes a big data processing framework to write ETL (Extract, Transform, Load) tasks. The system automatically filters the corresponding user IDs from the database based on the vehicle model, pulls user information from the vehicle's embedded logs and CRM system in parallel, and automatically clusters and generates user profile tags through machine learning algorithms.

[0087] As an alternative implementation, test engineers use SQL queries to export user operation log tables and user information tables for specific vehicle models from the data warehouse. Then, using Excel or BI tools, they correlate and match the two tables by user ID, manually or semi-automatically filtering out high-frequency operation characteristics and compiling them into a user profile report.

[0088] It is worth noting that by using a pre-filtering mechanism based on vehicle model to determine the target object, data noise from irrelevant models is effectively eliminated, ensuring that the final generated profile data fully matches the actual situation of the current test model and avoiding evaluation bias caused by mixing cross-model data.

[0089] Furthermore, by combining dynamic historical operation logs with static platform object data, the limitations of a single data source are overcome. This captures both the user's actual interactive behavior and their background attributes, resulting in more comprehensive user profile data and providing reliable data support for subsequent scientific calculation function weight coefficients.

[0090] Step S301: Determine multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement test functions of the target object;

[0091] Step S302: Sort the multiple requirement test functions corresponding to the multiple target frequencies based on multiple target frequencies to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged from largest to smallest according to the value of the corresponding target frequency.

[0092] Step S303: Determine the profile data based on the target function sequence.

[0093] In this embodiment, the system parses and statistically analyzes the acquired historical operation logs, and combines this with the function definitions in the platform object data to calculate the actual usage frequency or percentage of each required test function for a specific target group. For example, the system found that among 1,000 target car owners, 800 used the "voice wake-up" function more than 10 times per week, while only 50 used the "ambient lighting adjustment" function. Based on this, the system calculates the target frequency corresponding to these two functions, thereby objectively quantifying the user's true dependence on each function.

[0094] Furthermore, the system uses the calculated target frequency value as the sorting basis to sort all required test functions in descending order (from largest to smallest), generating an ordered sequence of target functions. Through this step, the system transforms the originally chaotic list of functions into a sequence with a clear gradient, where the functions at the front of the sequence are high-frequency core functions (such as navigation and multimedia), and the functions at the back are low-frequency peripheral functions.

[0095] Finally, the generated target function sequence and its frequency values ​​are structured and encapsulated to output the core profile data of the target vehicle.

[0096] The target frequency mentioned above refers to the frequency or activity level of the target group in testing a specific feature for a particular need. It is a core quantitative indicator for measuring the importance of this feature in users' daily use.

[0097] The aforementioned target function sequence refers to the ordered list of functions generated by the system after arranging the target frequency values ​​from high to low. It intuitively reflects the popularity and usage priority of each function among the target user group.

[0098] As an optional implementation, the system sets a standard time window (e.g., the last 30 days), iterates through the historical operation logs of all target objects within this time window, and counts the absolute number of times each function is triggered. Then, the number of triggers for each function is divided by the total number of operations (or the total number of users) within the time window to obtain a standardized target frequency, and the functions are sorted in descending order according to this frequency.

[0099] As an alternative implementation, the system can also use the percentage of unique users who have used the function out of the total number of target users, instead of the absolute number of operations. For example, if 900 out of 1000 target users have used navigation, then the target frequency of navigation is 0.9. The system then sorts the functions from highest to lowest based on this coverage ratio.

[0100] It's worth noting that transforming a large volume of unstructured historical operation logs into a sequence of target functions with a clear chronological order transforms user habits from vague, experiential understanding into precise, calculable, structured profile data. Furthermore, by strictly arranging these logs in descending order of size, interference from low-frequency, long-tail functions can be automatically eliminated, accurately selecting and prioritizing the core functions that best meet the actual needs of the target audience. This provides objective factual evidence for the subsequent scientific allocation of testing resources.

[0101] Step S401: Determine multiple first weight coefficients for multiple requirement testing functions based on the profile data;

[0102] Step S402: Determine multiple second weighting coefficients for multiple required test functions based on the vehicle model;

[0103] Step S403: Determine multiple functional weight coefficients based on multiple first weight coefficients and multiple second weight coefficients.

[0104] In this embodiment, such as Figure 3 As shown, the system extracts previously generated user profile data (such as target function sequences, usage frequency, etc.), calculates the importance of each function in actual user use through statistical algorithms, and converts it into a quantified first weight coefficient. For example, if the profile data reveals that users frequently use the "voice interaction" function, the system assigns a high first weight coefficient to this function, reflecting its core position among the real user group.

[0105] Furthermore, based on the vehicle model being tested and its preset quality assessment dimensions (such as functionality, performance / stability, user experience, compatibility, and safety), the system assigns a second weighting coefficient to each function according to preset rules. Specifically, the positioning of different vehicle models determines the different testing focuses. For example, for luxury models that emphasize safety, the system will assign a higher second weighting coefficient to safety-related functions such as "active braking"; while for models that emphasize entertainment, it will assign a higher second weighting coefficient to "audio-visual playback".

[0106] Finally, the system combines the first weight coefficient representing the user's perspective with the second weight coefficient representing the product's perspective (e.g., weighted summation) to obtain the comprehensive functional weight coefficient for each requirement testing function.

[0107] The aforementioned first weight coefficient refers to the function weight calculated based on real user profile data (such as usage frequency and user preferences), which reflects the actual popularity and usage dependence of the function among the target user group.

[0108] The aforementioned second weighting coefficient refers to the functional weight set based on vehicle model positioning and a multi-dimensional quality assessment system (such as safety, performance, compatibility, etc.), reflecting the importance of the function in engineering implementation and product definition.

[0109] The aforementioned functional weight coefficient refers to the final comprehensive weight value obtained by combining the first weight coefficient and the second weight coefficient. This coefficient is the core quantitative indicator that determines test priority and resource allocation.

[0110] As an optional implementation, the system pre-sets the allocation ratio of the first weighting coefficient and the second weighting coefficient (e.g., 6:4 or 5:5). During calculation, the "first weighting coefficient × 60%" of a certain function is added to the "second weighting coefficient × 40%" to obtain the final function weighting coefficient.

[0111] As an alternative implementation, the system dynamically adjusts the fusion ratio based on the specific tags of the vehicle model. For example, for high-end business vehicles, the system automatically increases the proportion of the second weighting coefficient (engineering and safety dimension) to 70%, while decreasing the proportion of the first weighting coefficient to 30%; the opposite is true for young and sporty vehicles.

[0112] It's worth noting that by combining objective user behavior data (first weight) with subjective product engineering positioning (second weight), the limitations of a single evaluation dimension are overcome. This ensures that the final functional weight coefficients align with user habits while guaranteeing core product quality. Furthermore, cross-validation from these dual perspectives effectively prevents the blind allocation of testing resources, ensuring that frequently used core functions, as well as underlying functions related to driving safety and system stability, receive appropriate testing weights. This maximizes the overall delivery quality of the smart cockpit within a limited testing period.

[0113] Step S501: Determine the testing frequency of the requirement testing function based on the test priority corresponding to the requirement testing function;

[0114] Step S502: Determine the test allocation resources and test execution plan for the required test functions based on the test frequency;

[0115] Step S503: Test the required test functions based on test resource allocation and test execution plan.

[0116] In this embodiment, the system assigns a corresponding test execution frequency to a function based on its priority level (e.g., P0, P1, P2, etc.) according to a preset mapping rule. Specifically, for P0-level core mandatory test functions, the system sets an extremely high test frequency (e.g., triggering tests with every code commit or daily build); while for P3-level low-frequency peripheral functions, the system sets a lower test frequency (e.g., executing only before version release or once a week).

[0117] Furthermore, based on the calculated testing frequency, the system dynamically plans the required testing resources (such as testing equipment, automated scripts, and test personnel man-hours) and generates specific test execution plans (such as serial execution, parallel execution, automated regression, or manual exploratory testing). For example, for core functions tested frequently, the system will prioritize allocating the best-performing and most stable automated test benches and adopt parallel execution schemes to shorten the time consumption; for non-core functions tested infrequently, ordinary testing equipment will be allocated or manual testing will be scheduled during resource-idle periods.

[0118] Finally, the testing platform or testers, following the generated execution plan, schedule and allocate resources to conduct actual testing and verification work on each required test function in sequence. Specifically, the system automatically triggers automated test scripts to run test cases for core functions on designated high-performance test benches, or testers, based on task dashboards, use assigned testing equipment to verify non-core functions, ensuring that the testing process is executed sequentially.

[0119] The test frequency mentioned above refers to the number of times or the time interval between repeated tests of a certain requirement test function within a specific test cycle.

[0120] The aforementioned test allocation resources refer to the specific physical elements allocated by the system for a particular test task during the test execution process, including but not limited to test benches, test equipment, automated test scripts, test personnel, and test time.

[0121] The aforementioned test execution plan refers to the strategic planning that guides how test tasks are specifically implemented, including the timing of test triggering, execution method (such as automation / manual), execution order (such as serial / parallel), and exception handling mechanism.

[0122] As an optional implementation, a multi-level pipeline can be configured in the continuous integration platform. For functions with high testing frequency (P0 level), they are attached to the daily built automated pipeline, and the system automatically allocates high-performance concurrent test nodes (resources) to them and executes automated regression schemes; for functions with low testing frequency, they are attached to the weekly release pipeline and executed using regular nodes.

[0123] As another alternative implementation, features can be tagged based on testing frequency in the project management tool. For core features that are tested frequently, dedicated test engineers and testing vehicles should be prioritized during scheduling, and detailed test execution plans should be developed. For features that are tested infrequently, they should be assigned to junior testers or executed when resources are more abundant later in the project.

[0124] It is worth noting that by developing high-frequency testing and dedicated execution plans for high-priority features, core functions can be quickly verified during version iterations, thereby exposing and fixing high-risk defects in the early stages of the testing cycle and maximizing the return on investment of testing.

[0125] Step S601: Obtain the vehicle's historical test logs;

[0126] Step S602: Update the weight coefficients of multiple functions based on historical test logs.

[0127] In this embodiment, the system selectively extracts structured log data generated by test tasks executed in previous versions or within the current test cycle from the test management platform, automated test server, or test equipment. Specifically, the log data includes not only the execution results of test cases (such as pass, fail, or block), but also process data during execution (such as actual time consumed, number of defects found, defect severity level, and resource consumption).

[0128] Furthermore, the system performs statistical analysis on the extracted historical test logs, extracts key indicators that reflect the actual quality risks of the functions, and dynamically corrects the original function weight coefficients (such as increasing or decreasing them) through a preset feedback adjustment algorithm.

[0129] For example, if historical logs show that a certain function (such as "intelligent voice recognition") has frequently had serious defects in recent versions, it means that the actual quality risk of the function is far higher than expected, and the system will automatically increase the weight coefficient of the function; conversely, if a function passes the tests stably for multiple consecutive versions and there are no user complaints, the system will appropriately decrease its weight coefficient, thereby freeing up testing resources.

[0130] The aforementioned historical test logs refer to a collection of structured data automatically or manually recorded during past test executions. They not only record the static results of the tests but also include dynamic process information such as defect tracking, execution time, and exception stack traces, serving as a data source for evaluating the true quality status of the functionality.

[0131] The aforementioned weight coefficient update refers to the process by which the system dynamically adjusts the initially set functional weight coefficients based on actual test feedback data using an algorithm.

[0132] As an optional implementation, the system statistically analyzes the defect detection rate of each function in the historical test logs. For functions with a defect density significantly higher than the average, the system triggers a penalty mechanism, multiplying its function weight coefficient by an adjustment factor greater than 1 (e.g., 1.2). For functions with zero defects for a long period, a reward mechanism is triggered, multiplying by a factor less than 1 (e.g., 0.8).

[0133] As an alternative implementation, the system analyzes the test execution time and the number of blocking events caused by environmental / preconditions in the historical logs. If a function has a low initial weight, but the historical logs show that it is prone to blocking and takes a very long time to troubleshoot, the system will automatically increase its weight coefficient to reserve more buffer time and dedicated resources for it in subsequent tests.

[0134] It is worth noting that, through feedback from historical data, the system can automatically identify and continuously increase the testing investment in high-risk and error-prone functions, while gradually reducing the over-testing of long-term stable functions, thereby maximizing the return on investment of testing resources in long-term version iterations.

[0135] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or grid device, etc.) to execute the methods of the various embodiments of the present invention.

[0136] This embodiment also provides a vehicle testing apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0137] Figure 4 This is a structural block diagram of a vehicle testing apparatus 400 according to one embodiment of the present invention, as shown below. Figure 4 As shown, the device includes: a first acquisition module 41, a first determination module 42, a second determination module 43, and a test module 44.

[0138] The first acquisition module 41 is used to acquire the vehicle model and the profile data of the target object;

[0139] The first determining module 42 is used to determine multiple function weight coefficients for multiple requirement testing functions of a vehicle based on the profile data and the vehicle model, wherein each requirement testing function corresponds to a function weight coefficient.

[0140] The second determining module 43 is used to determine multiple test priorities for multiple requirement test functions based on multiple functional weight coefficients, wherein each requirement test function corresponds to one test priority.

[0141] Test module 44 is used to test multiple requirement test functions based on multiple test priorities.

[0142] Optionally, the first acquisition module 41 includes: a first determining unit, used to determine the target object based on the vehicle model; an acquisition unit, used to acquire the historical operation logs and platform object data of the target object; and a second determining unit, used to determine the profile data based on the historical operation logs and platform object data.

[0143] Optionally, the second determining unit includes: a first determining subunit, used to determine multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement testing functions of the target object; a sorting subunit, used to sort the multiple requirement testing functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement testing functions in the target function sequence are arranged in descending order according to the numerical value of their corresponding target frequencies; and a second determining subunit, used to determine profile data based on the target function sequence.

[0144] Optionally, the first determining module 42 includes: a third determining unit, used to determine multiple first weight coefficients for multiple requirement testing functions based on profile data; a fourth determining unit, used to determine multiple second weight coefficients for multiple requirement testing functions based on vehicle model; and a fifth determining unit, used to determine multiple function weight coefficients based on multiple first weight coefficients and multiple second weight coefficients.

[0145] Optionally, the test module 44 includes: a sixth determining unit, used to determine the test frequency of the requirement test function based on the test priority corresponding to the requirement test function; a seventh determining unit, used to determine the test allocation resources and test execution plan of the requirement test function based on the test frequency; and a test unit, used to test the requirement test function based on the test allocation resources and test execution plan.

[0146] Optionally, the vehicle testing device 400 further includes: a second acquisition module for acquiring historical test logs of the vehicle; and an update module for updating multiple functional weight coefficients based on the historical test logs.

[0147] Embodiments of the present invention also provide a vehicle, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the above-described vehicle testing method.

[0148] Optionally, in this embodiment, the vehicle may be configured to store a computer program for performing the following steps:

[0149] Step S101: Obtain the vehicle model and the profile data of the target object;

[0150] Step S102: Based on the profile data and vehicle model, determine multiple function weight coefficients for multiple demand test functions of the vehicle, wherein each demand test function corresponds to a function weight coefficient.

[0151] Step S103: Determine multiple test priorities for multiple requirement test functions based on multiple function weight coefficients, wherein each requirement test function corresponds to one test priority;

[0152] Step S104: Test multiple requirement test functions based on multiple test priorities.

[0153] Optionally, the processor may also perform the following steps when executing the program: determining the target object based on the vehicle model; obtaining the target object's historical operation logs and platform object data; and determining profile data based on the historical operation logs and platform object data.

[0154] Optionally, when the processor executes the program, it also performs the following steps: determining multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement test functions of the target object; sorting the multiple requirement test functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged from largest to smallest according to the value of the corresponding target frequency; and determining profile data based on the target function sequence.

[0155] Optionally, when the processor executes the program, it also performs the following steps: determining multiple first weight coefficients for multiple requirement testing functions based on the profile data; determining multiple second weight coefficients for multiple requirement testing functions based on the vehicle model; and determining multiple function weight coefficients based on the multiple first weight coefficients and the multiple second weight coefficients.

[0156] Optionally, when the processor executes the program, it also performs the following steps: determining the test frequency of the requirement test function based on the test priority corresponding to the requirement test function; determining the test allocation resources and test execution plan for the requirement test function based on the test frequency; and testing the requirement test function based on the test allocation resources and test execution plan.

[0157] Optionally, the processor may also perform the following steps when executing the program: obtaining the vehicle's historical test logs; and updating the weight coefficients of multiple functions based on the historical test logs.

[0158] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0159] Embodiments of the present invention also provide an electronic device, such as... Figure 5 As shown, it includes a memory 51 and a processor 52, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the above-described vehicle testing method.

[0160] Optionally, in this embodiment, the electronic device may be configured to store a computer program for performing the following steps:

[0161] Step S101: Obtain the vehicle model and the profile data of the target object;

[0162] Step S102: Based on the profile data and vehicle model, determine multiple function weight coefficients for multiple demand test functions of the vehicle, wherein each demand test function corresponds to a function weight coefficient.

[0163] Step S103: Determine multiple test priorities for multiple requirement test functions based on multiple function weight coefficients, wherein each requirement test function corresponds to one test priority;

[0164] Step S104: Test multiple requirement test functions based on multiple test priorities.

[0165] Optionally, the processor may also perform the following steps when executing the program: determining the target object based on the vehicle model; obtaining the target object's historical operation logs and platform object data; and determining profile data based on the historical operation logs and platform object data.

[0166] Optionally, when the processor executes the program, it also performs the following steps: determining multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement test functions of the target object; sorting the multiple requirement test functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged from largest to smallest according to the value of the corresponding target frequency; and determining profile data based on the target function sequence.

[0167] Optionally, when the processor executes the program, it also performs the following steps: determining multiple first weight coefficients for multiple requirement testing functions based on the profile data; determining multiple second weight coefficients for multiple requirement testing functions based on the vehicle model; and determining multiple function weight coefficients based on the multiple first weight coefficients and the multiple second weight coefficients.

[0168] Optionally, when the processor executes the program, it also performs the following steps: determining the test frequency of the requirement test function based on the test priority corresponding to the requirement test function; determining the test allocation resources and test execution plan for the requirement test function based on the test frequency; and testing the requirement test function based on the test allocation resources and test execution plan.

[0169] Optionally, the processor may also perform the following steps when executing the program: obtaining the vehicle's historical test logs; and updating the weight coefficients of multiple functions based on the historical test logs.

[0170] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0171] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program configured to perform the above-described vehicle testing method when run on a computer or processor.

[0172] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0173] Step S101: Obtain the vehicle model and the profile data of the target object;

[0174] Step S102: Based on the profile data and vehicle model, determine multiple function weight coefficients for multiple demand test functions of the vehicle, wherein each demand test function corresponds to a function weight coefficient.

[0175] Step S103: Determine multiple test priorities for multiple requirement test functions based on multiple function weight coefficients, wherein each requirement test function corresponds to one test priority;

[0176] Step S104: Test multiple requirement test functions based on multiple test priorities.

[0177] Optionally, the storage medium is configured to store program code for performing the following steps: determining the target object based on the vehicle model; obtaining the target object's historical operation logs and platform object data; and determining profile data based on the historical operation logs and platform object data.

[0178] Optionally, the storage medium is configured to store program code for performing the following steps: determining multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement test functions of the target object; sorting the multiple requirement test functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged in descending order according to the numerical value of their corresponding target frequencies; and determining profile data based on the target function sequence.

[0179] Optionally, the storage medium is configured to store program code for performing the following steps: determining multiple first weight coefficients for multiple requirement testing functions based on profile data; determining multiple second weight coefficients for multiple requirement testing functions based on vehicle model; and determining multiple function weight coefficients based on the multiple first weight coefficients and the multiple second weight coefficients.

[0180] Optionally, the storage medium is configured to store program code for performing the following steps: determining the test frequency of the requirement test function based on the test priority corresponding to the requirement test function; determining the test allocation resources and test execution plan for the requirement test function based on the test frequency; and testing the requirement test function based on the test allocation resources and test execution plan.

[0181] Optionally, the storage medium is configured to store program code for performing the following steps: obtaining historical test logs of the vehicle; updating multiple function weight coefficients based on the historical test logs.

[0182] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0183] Embodiments of the present invention also provide a computer program product, including a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described vehicle testing method.

[0184] Optionally, in this embodiment, the computer program product described above may be configured to store a computer program for performing the following steps:

[0185] Step S101: Obtain the vehicle model and the profile data of the target object;

[0186] Step S102: Based on the profile data and vehicle model, determine multiple function weight coefficients for multiple demand test functions of the vehicle, wherein each demand test function corresponds to a function weight coefficient.

[0187] Step S103: Determine multiple test priorities for multiple requirement test functions based on multiple function weight coefficients, wherein each requirement test function corresponds to one test priority;

[0188] Step S104: Test multiple requirement test functions based on multiple test priorities.

[0189] Optionally, when the computer program executes the program, it also performs the following steps: determining the target object based on the vehicle model; obtaining the target object's historical operation logs and platform object data; and determining profile data based on the historical operation logs and platform object data.

[0190] Optionally, when the computer program executes the program, it also performs the following steps: determining multiple target frequencies based on historical operation logs and platform object data, wherein the multiple target frequencies are the usage frequencies of multiple requirement test functions of the target object; sorting the multiple requirement test functions corresponding to the multiple target frequencies based on the multiple target frequencies to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged from largest to smallest according to the value of the corresponding target frequency; and determining profile data based on the target function sequence.

[0191] Optionally, when the computer program executes the program, it also performs the following steps: determining multiple first weight coefficients for multiple requirement testing functions based on the profile data; determining multiple second weight coefficients for multiple requirement testing functions based on the vehicle model; and determining multiple function weight coefficients based on the multiple first weight coefficients and the multiple second weight coefficients.

[0192] Optionally, when the computer program executes the program, it also performs the following steps: determining the test frequency of the requirement test function based on the test priority corresponding to the requirement test function; determining the test allocation resources and test execution plan for the requirement test function based on the test frequency; and testing the requirement test function based on the test allocation resources and test execution plan.

[0193] Optionally, the computer program may also perform the following steps when executing the program: obtaining the vehicle's historical test logs; and updating multiple function weight coefficients based on the historical test logs.

[0194] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0195] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0196] In the embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0197] The units described as separate components may or may not be physically separate. Similarly, the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

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

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

[0200] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for testing a vehicle, characterized in that, include: Obtain vehicle model and target object profile data; Based on the profile data and the vehicle model, multiple function weight coefficients are determined for multiple requirement testing functions of the vehicle, wherein each requirement testing function corresponds to a function weight coefficient. Multiple test priorities are determined based on the multiple functional weight coefficients, wherein each requirement test function corresponds to one test priority; The multiple requirement test functions are tested based on the multiple test priorities.

2. The vehicle testing method according to claim 1, characterized in that, Obtaining the portrait data includes: The target object is determined based on the vehicle model; Obtain the historical operation logs and platform object data of the target object; The profile data is determined based on the historical operation logs and the platform object data.

3. The vehicle testing method according to claim 2, characterized in that, The profile data determined based on the historical operation logs and the platform object data includes: Based on the historical operation logs and the platform object data, multiple target frequencies are determined, wherein the multiple target frequencies are the usage frequencies of multiple requirement testing functions of the target object; Based on the multiple target frequencies, the multiple requirement test functions corresponding to the multiple target frequencies are sorted to obtain a target function sequence, wherein the multiple requirement test functions in the target function sequence are arranged from largest to smallest according to the value of the corresponding target frequency; The profile data is determined based on the target function sequence.

4. The vehicle testing method according to claim 1, characterized in that, Determining the weighting coefficients of the multiple functions based on the profile data and the vehicle model includes: Based on the profile data, determine multiple first weight coefficients for the multiple requirement testing functions; Based on the vehicle model, determine multiple second weighting coefficients for the multiple requirement testing functions; The plurality of functional weight coefficients are determined based on the plurality of first weight coefficients and the plurality of second weight coefficients.

5. The vehicle testing method according to claim 1, characterized in that, Testing the multiple requirement test functions based on the multiple test priorities includes: The testing frequency of the requirement testing function is determined based on the test priority corresponding to the requirement testing function. Based on the test frequency, determine the test resource allocation and test execution plan for the required test functions; The required test functions are tested based on the test resource allocation and the test execution plan.

6. The vehicle testing method according to claim 1, characterized in that, The method further includes: Obtain the historical test logs of the vehicle; The weight coefficients of the multiple functions are updated based on the historical test logs.

7. A vehicle testing device, characterized in that, include: The first acquisition module is used to acquire the vehicle model and the profile data of the target object; The first determining module is used to determine multiple function weight coefficients for multiple demand testing functions of the vehicle based on the profile data and the vehicle model, wherein each demand testing function corresponds to a function weight coefficient. The second determining module is used to determine multiple test priorities of the multiple requirement test functions based on the multiple function weight coefficients, wherein each requirement test function corresponds to a test priority; The testing module is used to test the multiple requirement test functions based on the multiple test priorities.

8. A vehicle comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the vehicle testing method as described in any one of claims 1 to 6.

9. A vehicle comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the vehicle testing method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the vehicle testing method according to any one of claims 1 to 6 when run on a computer or processor.

Images