A vehicle-mounted software testing method, system, device and storage medium

Abstract

This application discloses a method, system, device, and storage medium for testing in-vehicle software. In this solution, three independent types of resources are defined through a project configuration file, corresponding to the environment under test, testing tools, and test cases, respectively. A variable replacement context is generated based on the configuration file. Testing tools and test case sets are obtained according to the configuration. After compliance verification with standardized integration specifications, the test cases are traversed. Before execution, variable reference replacement is performed, and executable instructions are generated. This technical solution decouples test logic from resources and test cases from the environment, improving the scalability, stability, and adaptability of the testing solution. This enables test cases to be reused across projects and vehicle models, adapting to the needs of agile development and continuous integration of in-vehicle software.

Description

Technical Field

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

[0002] As automotive electronic and electrical architecture continues to evolve towards domain controllers and central computing platforms, the functional complexity, code size, and iteration speed of in-vehicle software have increased significantly. Automated testing has become a core element in ensuring the functional safety and delivery quality of in-vehicle software.

[0003] Current mainstream automotive software testing solutions generally suffer from the defect of deep coupling between the core logic of the framework and the environment under test, testing tools, and test cases. When it is necessary to adapt to a new environment under test, add new testing tools, or integrate new test cases, the core code of the framework must be modified. This not only leads to poor system scalability and high maintenance difficulty, but also easily causes framework stability issues, making it difficult to adapt to the parallel testing needs of multiple scenarios and multiple versions in the automotive field.

[0004] Meanwhile, in existing testing solutions, the information of the environment under test and the parameters for calling tools are generally hard-coded directly into the test case scripts. When the test environment or tool configuration changes, the associated test cases need to be modified line by line. This not only results in extremely low environment adaptation efficiency and is prone to human error, but also makes it impossible to reuse test cases across projects and vehicle models. The test asset reuse rate is low, making it difficult to support the agile development and continuous integration testing requirements of rapid iteration of in-vehicle software. Summary of the Invention

[0005] To address the aforementioned issues, this application provides an in-vehicle software testing method, system, device, and storage medium. The aim is to decouple test logic from test resources, test cases from environment configuration, and improve the scalability, reusability, and adaptation efficiency of in-vehicle software automated testing.

[0006] The embodiments of this application disclose the following technical solutions: The first aspect of this application provides a method for testing in-vehicle software, the method comprising: Obtain the project configuration file, which defines three types of resources: the first type, the second type, and the third type. The first type of resources describes the connection and access information of the environment under test. The second type of resources describes the acquisition method and usage commands of the testing tools. The third type of resources describes the acquisition method and integration specifications of the test cases. Based on the project configuration file, a variable replacement context is generated; The testing tools are obtained according to the method of obtaining the testing tools, and multiple test case sets are obtained according to the method of obtaining the test cases; Based on the aforementioned interface specifications, compliance checks are performed on multiple test case sets, and the test case sets that pass the checks are iterated through. The test cases in the set of test cases that have passed the compliance verification are traversed. Based on the variable substitution context, the variable references in the currently traversed test cases are replaced, an executable instruction is generated, and the executable instruction is executed.

[0007] In an optional implementation, the second type of resource is further used to describe the preprocessing method of the testing tool; after obtaining the testing tool according to the acquisition method of the testing tool, the method further includes: The testing tool is preprocessed according to the preprocessing method described above.

[0008] In an optional implementation, the third type of resource is further used to describe the preprocessing method of test cases; after obtaining multiple test case sets according to the test case acquisition method, the method further includes: The test case set is preprocessed according to the preprocessing method described above.

[0009] In an optional implementation, the first type of resource is further used to describe the recovery instructions for the test environment; before traversing the test cases in the set of test cases that have passed the compliance verification, replacing the variable references in the currently traversed test cases based on the variable replacement context, generating executable instructions, and executing the executable instructions, the method further includes: Restore the test environment according to the recovery instructions.

[0010] In an optional implementation, the project configuration file also defines global configuration information, which includes the working directory for test execution.

[0011] In an optional implementation, the interface specification includes: a structured configuration file with a preset name exists in the root directory of the test case set; the compliance verification of multiple test case sets based on the interface specification includes: Determine whether a structured configuration file for transportation and names exists in the root directory of each test case set; If it exists, the verification passes, and the corresponding test case set is added to the test case set to be traversed; If it does not exist, the validation fails, the corresponding test case set is marked as an exception and execution is skipped.

[0012] In an optional implementation, after generating and executing the executable instructions, the method further includes: The execution results of the executable instructions are associated with the corresponding test cases, and a test report is generated based on the association results.

[0013] A second aspect of this application provides an in-vehicle software testing system, the system comprising: The configuration acquisition module is used to acquire the project configuration file, which defines three types of resources: a first type, a second type, and a third type. The first type of resources describes the connection and access information of the environment under test; the second type of resources describes the acquisition method and usage commands of the testing tools; and the third type of resources describes the acquisition method and integration specifications of the test cases. A configuration parsing module is used to generate a variable replacement context based on the project configuration file; The resource acquisition module is used to acquire the test tool according to the acquisition method of the test tool, and to acquire multiple test case sets according to the acquisition method of the test cases; The compliance verification module is used to perform compliance verification on multiple test case sets based on the interface specifications, and to traverse the test case sets that have passed the verification. The test execution module is used to traverse the test cases in the set of test cases that have passed the compliance verification, replace the variable references in the currently traversed test cases based on the variable replacement context, generate executable instructions, and execute the executable instructions.

[0014] A third aspect of this application provides an in-vehicle software testing device, which includes: a processor and a memory. The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the steps of the vehicle software testing method described in any implementation of the first aspect according to the instructions in the program code.

[0015] A fourth aspect of this application provides a computer-readable storage medium for storing program code for performing the steps of the vehicle software testing method described in any implementation of the first aspect.

[0016] Compared with the prior art, this application has the following beneficial effects: In this technical solution, the project configuration file is first obtained, which defines three types of resources: a first type, a second type, and a third type. The first type of resource describes the connection and access information of the environment under test. The second type of resource describes the acquisition method and usage commands of the testing tools. The third type of resource describes the acquisition method and interface specifications of the test cases. Next, a variable substitution context is generated based on the project configuration file. Then, the testing tools are acquired according to the acquisition method, and multiple test case sets are acquired according to the acquisition method. Following this, compliance checks are performed on the multiple test case sets based on the interface specifications, and the test case sets that pass the checks are traversed. Finally, the test cases in the compliance-checked test case sets are traversed, and based on the variable substitution context, variable references in the currently traversed test cases are replaced to generate executable instructions and execute the executable instructions. As can be seen, the technical solution of this application abstracts the test environment, testing tools, and test cases into three independent resource categories, uniformly defined in the project configuration file. Combined with the standardized interface specifications and compliance verification mechanism of the third resource category, this breaks the tight coupling problem between the core testing logic and various testing resources in existing solutions. When adding or adapting test environments, testing tools, or test cases, only the project configuration file needs to be adjusted, without modifying the core testing logic. This avoids the disruption of the entire testing process caused by a single abnormal test case, improving the scalability, maintainability, and operational stability of the testing solution, and enabling it to adapt to the parallel testing needs of multiple scenarios and versions in the automotive field. Furthermore, by generating variable replacement contexts based on the project configuration file, and completing the unified replacement of variable references before test case execution, complete decoupling of test case business logic from environment configuration and tool parameters is achieved. When the environment changes, there is no need to modify test cases line by line; only the configuration file needs to be adjusted to complete full adaptation, improving adaptation efficiency and avoiding human error. This enables test cases to be reused across projects and vehicle models without modification, significantly improving the reusability of test assets and effectively supporting the agile development and continuous integration testing needs of automotive software. Attached Figure Description

[0017] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart of an in-vehicle software testing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an in-vehicle software testing system provided in an embodiment of this application. Detailed Implementation

[0019] As described earlier, with the continuous evolution of automotive electronic and electrical architecture towards domain controllers and central computing platforms, the functional complexity, code size, and iteration speed of in-vehicle software have increased significantly. Automated testing has become a core element in ensuring the functional safety and delivery quality of in-vehicle software.

[0020] Current mainstream automotive software testing solutions generally suffer from the defect of deep coupling between the core logic of the framework and the environment under test, testing tools, and test cases. When it is necessary to adapt to a new environment under test, add new testing tools, or integrate new test cases, the core code of the framework must be modified. This not only leads to poor system scalability and high maintenance difficulty, but also easily causes framework stability issues, making it difficult to adapt to the parallel testing needs of multiple scenarios and multiple versions in the automotive field.

[0021] Meanwhile, in existing testing solutions, the information of the environment under test and the parameters for calling tools are generally hard-coded directly into the test case scripts. When the test environment or tool configuration changes, the associated test cases need to be modified line by line. This not only results in extremely low environment adaptation efficiency and is prone to human error, but also makes it impossible to reuse test cases across projects and vehicle models. The test asset reuse rate is low, making it difficult to support the agile development and continuous integration testing requirements of rapid iteration of in-vehicle software.

[0022] To address the aforementioned problems, the inventors have proposed a method, system, device, and storage medium for testing in-vehicle software.

[0023] First, the project configuration file is obtained, which defines three types of resources: a first type, a second type, and a third type. The first type of resource describes the connection and access information of the environment under test. The second type of resource describes the acquisition method and usage commands of the testing tools. The third type of resource describes the acquisition method and integration specifications of the test cases. Next, a variable replacement context is generated based on the project configuration file. Then, the testing tools are acquired according to the acquisition method, and multiple test case sets are acquired according to the acquisition method. Following this, compliance checks are performed on the multiple test case sets based on the integration specifications, and the sets that pass the checks are iterated through. Finally, the test cases in the compliance-checked test case sets are iterated through, and variable references in the currently iterated test cases are replaced based on the variable replacement context, generating executable instructions and executing them. It is evident that this technical solution, by abstracting the environment under test, testing tools, and test cases into three independent types of resources, uniformly defined in the project configuration file, and combined with the standardized integration specifications and compliance checks of the third type of resource, breaks the tight coupling problem between the core testing logic and various testing resources in existing solutions. When adding or adapting test environments, testing tools, and test cases, only the project configuration file needs to be adjusted, without modifying the core test logic. This avoids the disruption of the entire test process caused by a single abnormal test case, improving the scalability, maintainability, and operational stability of the test solution. It can adapt to the parallel testing needs of multiple scenarios and versions in the automotive field. Furthermore, by generating variable replacement contexts based on the project configuration file, variable references are uniformly replaced before test case execution, achieving complete decoupling of test case business logic from environment configuration and tool parameters. When the environment changes, there is no need to modify test cases line by line; only the configuration file needs to be adjusted to complete full adaptation, improving adaptation efficiency and avoiding human error. This enables test cases to be reused across projects and vehicle models without modification, significantly improving the reusability of test assets and effectively supporting the agile development and continuous integration testing needs of automotive software.

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

[0025] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0026] See Figure 1 This figure is a flowchart of an in-vehicle software testing method provided in an embodiment of this application. Figure 1 As shown, the method includes the following steps: S101. Obtain the project configuration file.

[0027] In this embodiment, the project configuration file is the sole configuration entry point and information source for the vehicle software testing method. It is written in a standardized JSON or YAML structured format, centrally managing all variable configurations throughout the testing process, thus achieving complete decoupling between the core testing logic and the variable configurations. The project configuration file is then obtained.

[0028] The first type of resource is used to describe the connection and access information of the environment under test, serving as a static environmental information carrier for devices and services.

[0029] The second type of resource describes the acquisition methods and usage commands of testing tools, serving as a standardized configuration carrier for the toolchain required for testing.

[0030] The third type of resource describes the acquisition methods and integration specifications for test cases, serving as a standardized configuration carrier for test case sets.

[0031] In the embodiments of this application, the connection and access information of the tested environment includes, but is not limited to, the network address, authentication credentials, communication protocols, and environmental variables of the tested vehicle electronic control unit (ECU), domain controller, and central computing platform.

[0032] Testing tools, including but not limited to in-vehicle software compilation toolchains, cross-compilation tools, simulation testing tools, log collection tools, diagnostic tools, and other tools required for the entire in-vehicle testing process.

[0033] The command provides standardized instructions for calling testing tools and supports referencing them as variables within test cases.

[0034] A test case set is a collection of test cases for a single functional module of an in-vehicle system, such as a cockpit startup test case set, a network connectivity test case set, and a body control test case set.

[0035] The interface specification is a standardized interface agreement between the test architecture and the test case set. It is a unified standard that allows the test case set to be identified, parsed, and executed.

[0036] In this embodiment, the resource classes are independent of each other and have clear boundaries. They are centrally defined only through the project configuration file, with no logical coupling. When adding, replacing, or adapting any resource class, only the corresponding content in the configuration file needs to be modified, without changing the core testing logic.

[0037] In one example implementation, the project configuration file can employ encrypted storage and permission verification mechanisms, allowing only authorized accounts to modify and read the configuration content, thus meeting the compliance and data security requirements of in-vehicle software functional safety testing.

[0038] In another example implementation, the project configuration file supports a parent configuration inheritance mechanism. Common basic configurations can be fixed as parent configuration files, and new projects only need to write differentiated configurations to complete the configuration file setup, further improving configuration reusability and new project adaptation efficiency.

[0039] In one alternative implementation, in order to unify the management of common public information throughout the entire testing process and enable a change in global configuration to take effect throughout the entire process, global configuration information is also defined in the project configuration file. The global configuration information includes the working directory for test execution, the root directory of test cases, global parameters passed in from the command line, the vehicle model code under test, the vehicle software version number, the test execution mode, etc.

[0040] In this embodiment, the global configuration information consists of common configuration items applicable throughout the entire testing process, and does not change with variations in individual resources or test cases. The working directory for test execution serves as the root directory for this test task, and is used to structurally store all data retrieved for this test, including tools, test cases, generated logs, reports, etc., ensuring that test data is traceable and archiveable.

[0041] In one example implementation, the working directory for test runs can be automatically generated by “vehicle model + version number + test time”, avoiding data confusion between different test tasks and facilitating the archiving and backtracking of test data.

[0042] This application embodiment consolidates all variable content that varies with the test environment, project, and vehicle model into a project configuration file and defines it as three independent standardized resources. This provides a unique and consistent configuration information source for the entire testing process, fundamentally solving the problems of scattered configuration and tight coupling between logic and resources in the prior art. At the same time, it provides a standardized foundation for subsequent automated resource management and unified variable replacement.

[0043] S102. Generate a variable replacement context based on the project configuration file.

[0044] In this embodiment, the variable substitution context is a structured key-value dictionary built in memory. It is the sole source of values ​​for variable reference substitution throughout the entire test process. It is generated only once after the configuration file is parsed and reused throughout the entire process to ensure the consistency of configuration information throughout the entire test process.

[0045] In this embodiment, the variable substitution context is divided into two main structures: a global area and a resource area. The global area stores global configuration information from the project configuration file, while the resource area stores full configuration information for first, second, and third type resources, categorized by resource type, corresponding one-to-one with the definitions in the project configuration file. In test cases, configuration items in the context can be referenced as variables using the unified format {{resource type.resource name.attribute / action}}.

[0046] In one example implementation, while generating the variable replacement context, a context snapshot file can be generated simultaneously and archived with the configuration file and final test report for this test, enabling full-chain traceability of the testing process and facilitating subsequent troubleshooting and auditing.

[0047] In another example implementation, it supports updating the specified configuration items in the context via global directives during the test process, adapting to special scenarios where the environment configuration needs to be dynamically adjusted during the test, while retaining modification records to ensure that configuration changes are traceable.

[0048] This application embodiment parses static configuration files into memory-level variables that can be quickly queried to replace the context, providing core data support for unified variable replacement before subsequent test case execution. It realizes dynamic mapping between abstract variable references and real configuration values ​​in test cases, which is the core foundation for decoupling test cases from environment configuration.

[0049] S103. Obtain the testing tools according to the method of obtaining the testing tools, and obtain multiple test case sets according to the method of obtaining the test cases.

[0050] In this embodiment, the acquisition method corresponding to each testing tool in the second type of resources is read, and the testing tools are sequentially pulled to the specified tool path under the test execution working directory. Simultaneously, the acquisition method corresponding to each test case set in the third type of resources is read, and the test case sets are sequentially pulled to the specified test case path under the test execution working directory.

[0051] Acquisition methods include, but are not limited to, File Transfer Protocol (FTP), centralized version control system (Apache Subversion, SVN), Git, local disk path, shared storage path, etc., and support automatic retrieval of local and remote resources.

[0052] In this embodiment, only the second and third types of resources are acquired; the first type of resources are only loaded into the variable replacement context and no acquisition or download operations are performed.

[0053] In one example implementation, multiple testing tools and test case sets can be fetched in parallel using multiple threads, significantly reducing test preparation time and improving testing efficiency. A retry mechanism can also be configured to handle failures; the number of retries and the retry interval can be customized in the global configuration information. If a retry still fails, the corresponding resource is marked as abnormal, detailed error logs are output, and the test process is terminated to avoid invalid execution.

[0054] In one optional implementation, to automate the environment initialization of the testing tool and ensure its proper invocation, the second type of resource also describes the preprocessing method for the testing tool. After obtaining the testing tool according to its acquisition method, the in-vehicle software testing method further includes: Preprocess the testing tool according to its preprocessing method.

[0055] In the embodiments of this application, the preprocessing methods include, but are not limited to, operations such as tool file decompression, execution permission configuration, authorization activation, environment variable registration, dependency package installation, and tool version verification. The preprocessing instructions can be configured as a single command or a combination of multiple commands to adapt to the initialization requirements of different tools.

[0056] In one optional implementation, to achieve automated environment adaptation of the test case set and ensure that the test case set can be executed normally, the third type of resource is also used to describe the preprocessing method of the test cases; after obtaining multiple test case sets according to the test case acquisition method, the vehicle software testing method also includes: The test case set is preprocessed according to the preprocessing method of the test cases.

[0057] In the embodiments of this application, the preprocessing methods include, but are not limited to, operations such as uncompressing test case files, installing test script dependencies, converting test case formats, initializing test basic data, and cleaning up historical test data.

[0058] This application embodiment achieves automated deployment and initialization of testing tools and test case sets through standardized resource acquisition and optional preprocessing mechanisms, eliminating the need for manual deployment of test resources, greatly improving the automation level of the testing process, while ensuring the consistency of resource deployment in different testing environments and avoiding oversights caused by manual operation.

[0059] S104. Based on the interface specifications, perform compliance verification on multiple test case sets and iterate through the test case sets that have passed the verification.

[0060] In this application embodiment, compliance verification refers to verifying the format and content of the test case set that has been pulled to the local machine in accordance with the interface specifications defined in the third type of resources. Only test case sets that pass the verification can be included in the execution queue. This is the core link to realize plug-and-play test cases and ensure the stable operation of the test process.

[0061] In one optional implementation, the interface specification includes: a structured configuration file with a preset name exists in the root directory of the test case set. Step S104 specifically includes: S1041. Determine whether a structured configuration file for transportation and names exists in the root directory of each test case set.

[0062] In this embodiment, the default name is a globally unified and fixed filename, such as testcase.json, which is the sole entry point for the testing framework and test case sets. All acquired test case sets are sequentially traversed, and each set is checked to see if a configuration file with this fixed name exists in the root directory. Extended checks are also performed: whether the configuration file format is standard JSON or YAML, and whether the configuration file contains required fields such as the test module name, test case list, test steps, and acceptance rules. If all checks meet the requirements, proceed to step S1042; if any check fails, proceed to step S1043.

[0063] S1042, Verification passed, the corresponding test case set is added to the test case set to be traversed.

[0064] In this embodiment of the application, for the test case set that has passed the verification, the test case list in its structured configuration file is automatically parsed, and a queue of test cases to be executed is generated according to the preset execution priority, such as test case level, module dependency relationship, etc., and incorporated into the overall test execution plan.

[0065] In one example implementation, the execution order of test case sets can be customized in the project configuration file, and it can also be configured to execute only test cases of a specified level, adapting to the needs of different testing scenarios such as smoke testing and regression testing.

[0066] S1043, if the verification fails, mark the corresponding test case set as an exception and skip execution.

[0067] In this embodiment, test case sets that fail validation are immediately marked as abnormal, and detailed reasons for the abnormality are output, such as missing configuration files, invalid formats, or missing required fields. The abnormal information is also written to the test log. Simultaneously, the abnormal test case set is skipped, and subsequent test case sets are processed, ensuring that the entire testing process is not interrupted due to the abnormality of a single test case set.

[0068] In one example implementation, the verification rules for the interface specification can be customized, and verification items can be extended in the project configuration file to adapt to the personalized interface requirements of different types of vehicle test case sets.

[0069] In another example implementation, the handling strategy for abnormal test case sets can be configured. For test case sets of core functional modules, the entire test process can be terminated when the verification fails. For non-core modules, execution can be skipped only, adapting to the stability requirements of different test scenarios.

[0070] This application's embodiments, through interface specifications and compliance verification mechanisms, completely decouple test case sets from core test logic. Any test case set conforming to the interface specifications can be directly integrated and used plug-and-play without modifying the core code. Simultaneously, an exception tolerance mechanism ensures the continuity and stability of the testing process, significantly improving maintainability and scalability.

[0071] S105. Traverse the test cases in the test case set that have passed the compliance verification, and replace the variable references in the currently traversed test cases based on the variable substitution context, generate executable instructions, and execute the executable instructions.

[0072] In this embodiment, test cases in the queue to be executed are traversed in a preset order. For the single test case currently being traversed, all variable references that conform to the format {{resource type.resource name.attribute / action}} are first fully scanned. Based on the pre-generated variable replacement context, all variable references are replaced with the corresponding real configuration values ​​to generate a variable-free instruction that can be directly executed in the current test environment. Then, the executable instruction is executed, and data such as instruction execution results, execution logs, and return parameters are collected simultaneously.

[0073] In this embodiment, the scope of variable reference scanning and replacement covers the entire process of test case execution conditions, test steps, post-processing actions, and acceptance judgment rules, ensuring that all variable content in test cases is uniformly managed through configuration files.

[0074] In one example implementation, variable replacement can be performed in real-time parsing mode, completing the replacement just before a single test action is executed. This ensures that the latest variable replacement context is used, avoiding execution errors caused by configuration changes during testing.

[0075] In another example implementation, the comparison data before and after the replacement of each variable reference is automatically recorded and written to the test traceability log, which facilitates backtracking of the test process and problem localization.

[0076] In an optional implementation, to ensure that each test case set is executed in a consistent initial environment, avoid interference from preceding tests, and improve the accuracy of test results, the first type of resource is also used to describe the recovery instructions for the test environment. Before step S105, the vehicle software testing method further includes: Restore the test environment according to the recovery instructions.

[0077] In this embodiment, the recovery command is automatically invoked before each test case set is executed. Specifically, it includes operations such as restarting the on-board device under test, resetting the configuration to factory settings, clearing the runtime cache, and restarting the test service, ensuring that the execution environment of each test case set is completely consistent.

[0078] In an optional implementation, to achieve automated summarization and visualization of test results, after step S105, the vehicle software testing method further includes: The execution results of executable instructions are associated with the corresponding test cases, and a test report is generated based on the association results.

[0079] In this embodiment of the application, the execution result (pass / fail / skip), execution time, step log, error details, and variable substitution traceability record of each instruction are uniquely associated and stored with the corresponding test case identifier (Identifier, ID), test case name, and module to which it belongs.

[0080] After all test cases are executed, the entire process execution data is automatically summarized to generate a structured in-vehicle software test report. The report supports multiple formats such as HTML, PDF, and JSON. It can be used directly for project delivery and compliance review, or seamlessly integrated with Continuous Integration and Continuous Delivery / Deployment Platform (CI / CD) platforms, test management platforms, and defect management systems to achieve an automated closed loop in the testing process.

[0081] This application's embodiments completely decouple test case business logic from environment configuration and tool parameters through unified variable replacement before test case execution. Test cases only need to focus on test business logic and acceptance rules, without needing to be bound to any specific environment parameters. When the test environment, tool configuration, or vehicle model project changes, only the corresponding content in the project configuration file needs to be modified, without modifying test cases line by line. This significantly improves environment adaptation efficiency, avoids oversights caused by manual modifications, and enables the unmodified reuse of test cases across projects and vehicle models, significantly improving the reusability of onboard test assets.

[0082] This application's embodiments fundamentally solve the core defects of existing automotive software testing solutions, such as tight coupling between core logic and test resources, poor scalability, low test case reuse rate, and low environment adaptation efficiency, through standardized definitions of three types of independent resources, configuration-driven full-process design, unified variable replacement mechanism, and standardized test case docking specifications. It significantly improves the scalability, stability, reusability, and adaptation efficiency of automated testing for automotive software, and can fully adapt to the testing needs of multiple scenarios, multiple versions, and rapid iterations in the automotive field, effectively supporting the agile development and continuous integration testing process of automotive software.

[0083] Based on the vehicle software testing method provided in the foregoing embodiments, this application also provides a vehicle software testing system. Figure 2 This is a schematic diagram of the structure of an in-vehicle software testing system provided in an embodiment of this application. Figure 2 As shown, the in-vehicle software testing system includes: a configuration acquisition module 201, a configuration parsing module 202, a resource acquisition module 203, a compliance verification module 204, and a test execution module 205.

[0084] The configuration acquisition module 201 is used to acquire the project configuration file. The project configuration file defines three types of resources: the first type, the second type, and the third type. The first type of resources describes the connection and access information of the environment under test. The second type of resources describes the acquisition method and usage commands of the testing tools. The third type of resources describes the acquisition method and integration specifications of the test cases.

[0085] Configure parsing module 202 to generate variable replacement context based on project configuration file.

[0086] The resource acquisition module 203 is used to acquire test tools according to the acquisition method of test tools, and to acquire multiple test case sets according to the acquisition method of test cases.

[0087] The compliance verification module 204 is used to perform compliance verification on multiple test case sets based on the interface specifications, and to traverse the test case sets that have passed the verification.

[0088] Test execution module 205 is used to traverse the test cases in the test case set that have passed compliance verification, replace variable references in the currently traversed test cases based on the variable substitution context, generate executable instructions, and execute the executable instructions.

[0089] This application embodiment achieves dual decoupling of test logic and test resources, and test cases and environment configuration through the coordinated cooperation of configuration acquisition module 201, configuration parsing module 202, resource acquisition module 203, compliance verification module 204 and test execution module 205, which significantly improves the scalability, stability, asset reuse rate and environment adaptation efficiency of vehicle software automated testing.

[0090] Optionally, the second type of resource is also used to describe the preprocessing method of the test tool. The vehicle software testing system also includes a first preprocessing module, which is used to preprocess the test tool according to the preprocessing method of the test tool after the resource acquisition module 203 acquires the test tool according to the acquisition method of the test tool.

[0091] Optionally, the third type of resource is also used to describe the preprocessing method of test cases. The vehicle software testing system also includes a second preprocessing module, which is used by the resource acquisition module 203 to preprocess the test case sets according to the test case preprocessing method after the resource acquisition module 203 acquires multiple test case sets according to the test case acquisition method.

[0092] Optionally, the first type of resource is also used to describe the recovery instructions for the test environment. The vehicle software testing system also includes an environment recovery module, which is used to restore the test environment according to the recovery instructions before the test execution module 205 traverses the test cases in the test case set that have passed compliance verification, replaces the variable references in the currently traversed test cases based on the variable substitution context, generates executable instructions, and executes the executable instructions.

[0093] Optionally, the project configuration file also defines global configuration information, which includes the working directory for test runs.

[0094] Optionally, the integration specifications include: a structured configuration file with a preset name exists in the root directory of the test case set; the compliance verification module 204 is specifically used for: Determine if a structured configuration file for transport and name exists in the root directory of each test case set.

[0095] If it exists, the verification passes, and the corresponding test case set is added to the test case set to be traversed.

[0096] If it does not exist, the validation fails, the corresponding test case set is marked as an exception and execution is skipped.

[0097] Optionally, the in-vehicle software testing system also includes a report generation module, which is used to associate the execution results of executable instructions with the corresponding test cases and generate a test report based on the association results.

[0098] In addition, this application embodiment also provides an in-vehicle software testing device, which includes a processor and a memory.

[0099] The memory is used to store program code and transfer the program code to the processor; The processor is used to execute the steps of the vehicle software testing method described in any of the above method embodiments according to the instructions in the program code.

[0100] Furthermore, embodiments of this application also provide a computer-readable storage medium storing program code, which is used to execute the steps of the vehicle software testing method described in any of the above method embodiments.

[0101] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the system and device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0102] The above description is merely one 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 technical scope 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.

Claims

1. A method for testing in-vehicle software, characterized in that, include: Obtain the project configuration file; the project configuration file defines a first type of resource, a second type of resource, and a third type of resource; the first type of resource is used to describe the connection and access information of the environment under test; the second type of resource is used to describe the acquisition method and usage commands of the testing tools; the third type of resource is used to describe the acquisition method and interface specifications of the test cases; Based on the project configuration file, a variable replacement context is generated; The testing tools are obtained according to the method of obtaining the testing tools, and multiple test case sets are obtained according to the method of obtaining the test cases; Based on the aforementioned interface specifications, compliance checks are performed on multiple test case sets, and the test case sets that pass the checks are iterated through. The test cases in the set of test cases that have passed the compliance verification are traversed. Based on the variable substitution context, the variable references in the currently traversed test cases are replaced, an executable instruction is generated, and the executable instruction is executed.

2. The method according to claim 1, characterized in that, The second type of resource is also used to describe the preprocessing method of the testing tool; after obtaining the testing tool according to the acquisition method of the testing tool, the method further includes: The testing tool is preprocessed according to the preprocessing method described above.

3. The method according to claim 1, characterized in that, The third type of resource is also used to describe the preprocessing methods for test cases; After obtaining multiple test case sets according to the test case acquisition method, the method further includes: The test case set is preprocessed according to the preprocessing method described above.

4. The method according to claim 1, characterized in that, The first type of resource is also used to describe the recovery instructions for the test environment; before traversing the test cases in the set of test cases that have passed the compliance verification, replacing the variable references in the currently traversed test cases based on the variable replacement context, generating executable instructions, and executing the executable instructions, the method further includes: Restore the test environment according to the recovery instructions.

5. The method according to claim 1, characterized in that, The project configuration file also defines global configuration information, which includes the working directory for test runs.

6. The method according to claim 1, characterized in that, The interface specification includes: a structured configuration file with a preset name exists in the root directory of the test case set; the compliance verification of multiple test case sets based on the interface specification includes: Determine whether a structured configuration file for transportation and names exists in the root directory of each test case set; If it exists, the verification passes, and the corresponding test case set is added to the test case set to be traversed; If it does not exist, the validation fails, the corresponding test case set is marked as an exception and execution is skipped.

7. The method according to claim 1, characterized in that, After generating and executing the executable instructions, the method further includes: The execution results of the executable instructions are associated with the corresponding test cases, and a test report is generated based on the association results.

8. An in-vehicle software testing system, characterized in that, include: The configuration acquisition module is used to acquire the project configuration file; the project configuration file defines a first type of resource, a second type of resource, and a third type of resource; the first type of resource is used to describe the connection and access information of the environment under test; the second type of resource is used to describe the acquisition method and usage commands of the testing tools; the third type of resource is used to describe the acquisition method and interface specifications of the test cases. A configuration parsing module is used to generate a variable replacement context based on the project configuration file; The resource acquisition module is used to acquire the test tool according to the acquisition method of the test tool, and to acquire multiple test case sets according to the acquisition method of the test cases; The compliance verification module is used to perform compliance verification on multiple test case sets based on the interface specifications, and to traverse the test case sets that have passed the verification. The test execution module is used to traverse the test cases in the set of test cases that have passed the compliance verification, replace the variable references in the currently traversed test cases based on the variable replacement context, generate executable instructions, and execute the executable instructions.

9. An in-vehicle software testing device, characterized in that, include: Processor and memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the steps of the vehicle software testing method according to any one of claims 1 to 7, based on the instructions in the program code.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for performing the steps of the vehicle software testing method according to any one of claims 1 to 7.

Images