Test method for vehicle software and related device

Abstract

This application discloses a testing method and related equipment for vehicle software. The method includes: assigning a unique global identifier and configuring a category label for each pre-created text test case in a test case management platform, and generating an automated script corresponding to each text test case, wherein the automated script contains the global identifier of the corresponding text test case; in response to a test execution command of the vehicle software, obtaining the target global identifier and target category label corresponding to the text test case to be executed from the test case management platform; matching the corresponding target automated script based on the target global identifier, and dynamically adding an execution marker corresponding to the target category label to the target automated script; and filtering the automated script according to the execution marker and executing the test. The technical solution provided by this application can improve the testing efficiency of vehicle software.

Description

Technical Field

[0001] This application belongs to the field of vehicle and software testing technology, and particularly relates to a testing method and related equipment for vehicle software. Background Technology

[0002] With the rapid development of automotive intelligence and electrification, the functional complexity of vehicle software has increased exponentially, expanding from traditional power control and body control to multiple core areas such as intelligent driving, intelligent cockpit, and vehicle networking. To ensure the reliability and safety of vehicle software, automated testing has become an indispensable key link in the vehicle software development process, with the number of automated test cases for a single project in the industry generally reaching tens of thousands. At the same time, the testing scenarios for vehicle software are becoming increasingly diverse, requiring verification in various testing environments such as real vehicles, various test benches, hardware-in-the-loop testing platforms, and software-in-the-loop testing platforms. The test cases applicable to different testing environments differ significantly; therefore, precise classification and selection of automated test cases are necessary.

[0003] Currently, the industry primarily uses methods such as directly writing execution markers into automated scripts or categorizing automated scripts according to the test environment to filter test cases. However, with the continuous increase in the number of automated test cases, the limitations of existing solutions are becoming increasingly apparent. When it is necessary to add or adjust test category tags, a large number of completed automated scripts must be modified one by one and resubmitted to the code repository for hosting. This is not only time-consuming and labor-intensive but also prone to introducing human error. Furthermore, the workload of tag adjustment increases exponentially as the project progresses, severely restricting the testing iteration speed of vehicle software.

[0004] Therefore, improving the testing efficiency of vehicle software has become an urgent technical problem to be solved. Summary of the Invention

[0005] The embodiments of this application provide a method, apparatus, computer program product, computer-readable storage medium, and electronic device for testing vehicle software, which can at least improve the testing efficiency of vehicle software to a certain extent.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to a first aspect of the embodiments of this application, a method for testing vehicle software is provided. The method includes: assigning a unique global identifier and configuring a category label for each pre-created text test case in a test case management platform, and generating an automated script corresponding to each text test case, wherein the automated script contains the global identifier of the corresponding text test case; in response to a test execution instruction for the vehicle software, obtaining a target global identifier and a target category label corresponding to the text test case to be executed from the test case management platform; matching a corresponding target automated script based on the target global identifier, and dynamically adding an execution marker corresponding to the target category label to the target automated script; and filtering the automated script according to the execution marker and executing the test.

[0008] In some embodiments of this application, based on the foregoing scheme, a classification label is configured for each text use case, including: configuring at least one of a vehicle model label, a test environment label, and an environment type label for each text use case; wherein, the vehicle model label is used to identify the vehicle model to which the text use case is adapted, the test environment label is used to identify the test carrier to which the text use case is applicable, and the environment type label is used to identify the test mode to which the text use case is applicable.

[0009] In some embodiments of this application, based on the foregoing scheme, configuring a classification label for each text use case further includes: establishing multiple mutually isolated project spaces in the use case management platform; and independently configuring the classification label for the corresponding text use case in each project space.

[0010] In some embodiments of this application, based on the foregoing scheme, generating an automation script corresponding to each text use case, wherein the automation script contains a global identifier for the corresponding text use case, includes: writing the global identifier corresponding to each text use case into the text use case name of the corresponding automation script to establish a one-to-one correspondence between text use cases and automation scripts.

[0011] In some embodiments of this application, based on the foregoing scheme, after obtaining the target global identifier and target category label corresponding to the text use case to be executed from the use case management platform, the method further includes: storing the obtained target global identifier and target category label to a local database, wherein the local database also stores the text use case name, the project to which it belongs, and the use case number information.

[0012] In some embodiments of this application, based on the foregoing scheme, the step of matching the target automation script with the target global identifier and dynamically adding an execution tag corresponding to the target category tag to the target automation script includes: reading the target global identifier and target category tag stored in the local database; identifying the global identifier contained in the automation script in the use case management platform, matching the identified global identifier with the target global identifier in the local database; and dynamically adding an execution tag consistent with the target category tag to the successfully matched automation script.

[0013] In some embodiments of this application, based on the foregoing scheme, the method further includes: in response to a batch modification instruction for category tags, exporting a list of use cases containing global identifiers and corresponding category tags from the use case management platform; batch editing the category tags in the use case list using a table editing tool; and re-importing the edited use case list into the use case management platform to update the category tags corresponding to the text use cases.

[0014] In some embodiments of this application, based on the foregoing scheme, after filtering automated scripts and executing tests according to the execution marker, the method further includes: binding the test results with the global identifier and category tag of the corresponding automated script; storing the bound test results in the test case management platform; and granting access permissions to the test results based on user permissions.

[0015] According to a second aspect of the embodiments of this application, a testing apparatus for vehicle software is provided. The apparatus includes: an allocation unit, configured to allocate a unique global identifier to each pre-created text test case in a test case management platform, configure a category label, and generate an automation script corresponding to each text test case, wherein the automation script contains the global identifier of the corresponding text test case; an acquisition unit, configured to acquire a target global identifier and a target category label corresponding to the text test case to be executed from the test case management platform in response to a test execution instruction for the vehicle software; a matching unit, configured to match a corresponding target automation script based on the target global identifier, and dynamically add an execution marker corresponding to the target category label to the target automation script; and an execution unit, configured to filter automation scripts according to the execution marker and execute tests.

[0016] According to a third aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform an operation as described in any of the first aspects above.

[0017] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to perform the operation as described in any of the first aspects above.

[0018] According to a fifth aspect of the present application, an electronic device is provided, the electronic device including one or more processors and one or more memories, the one or more memories storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the one or more processors to perform the operation as described in any of the first aspects above.

[0019] Based on the technical solution proposed in this application, the testing efficiency of vehicle software can be effectively improved. This application decouples the configuration of category tags from the writing of automated scripts. By assigning a unique global identifier to each text test case and writing it into the automated script, a stable correspondence between text test cases and automated scripts is established. Category tags are uniformly configured on the test case management platform and do not need to be written into the automated script code. When it is necessary to adjust the scope of application of test cases, only the category tags need to be modified on the platform, eliminating the need to modify and resubmit a large number of automated scripts one by one, significantly reducing the workload and time consumption of tag adjustments, while avoiding the risk of human error caused by code modification. During test execution, by obtaining the latest target global identifier and category tags from the test case management platform, execution markers are dynamically added to the matched automated scripts and execution is filtered. This allows for the rapid and accurate filtering of test cases that meet the testing requirements, avoiding the execution of inapplicable test cases, shortening the testing cycle, and improving the test response speed and overall efficiency, which is particularly suitable for vehicle software testing scenarios with a large number of automated test cases. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a vehicle software testing method according to an embodiment of this application is shown; Figure 2 A block diagram of a vehicle software testing apparatus according to an embodiment of this application is shown; Figure 3 A schematic diagram of the structure of an electronic device in an embodiment of this application is shown. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0023] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. It should also be noted that, for the sake of simplicity, certain components in the drawings that do not affect the interpretation of the technical solution of this application have been appropriately omitted.

[0024] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined. Therefore, the actual execution order may change depending on the actual situation.

[0025] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0026] Next, this application will elaborate on the proposed testing scheme for vehicle software. (Refer to...) Figure 1 The flowchart illustrates a vehicle software testing method according to an embodiment of this application. This method can be executed by a device with computational processing capabilities, such as... Figure 1 As shown, the method includes at least steps 110 to 140, which are described in detail below: In step 110, a unique global identifier is assigned to each pre-created text use case in the use case management platform, and a category label is configured. An automation script corresponding to each text use case is generated, and the automation script contains the global identifier of the corresponding text use case.

[0027] In this application, the text test case refers to a plain text test description written by testers based on the functional requirements of the vehicle software. It clarifies the purpose, steps, and expected results of the test, serving as the foundation for automated testing. The globally unique identifier is a unique identifier assigned to each text test case, ensuring it is unique across the entire platform and project. Its function is to establish a stable one-to-one correspondence between text test cases and automated scripts.

[0028] In this application, the automated script refers to a code program that converts text test cases into automatically executable code, which can simulate manual operation to complete the testing of vehicle software.

[0029] In practical applications, testers can first create text test cases in the test case management platform. The platform can automatically generate a globally unique identifier for each text test case. Testers can configure corresponding category tags for each text test case according to testing requirements. Then, developers write automation scripts based on the content of the text test cases and add the corresponding globally unique identifiers to the automation scripts.

[0030] In this application, by assigning a unique global identifier to each text use case and configuring a category label, and writing the globally unique identifier into the automation script, a clear correspondence between text use cases and automation scripts can be established, avoiding confusion in the process of managing a large number of use cases, and laying the foundation for subsequent dynamic tagging and use case filtering.

[0031] In step 110 above, configuring a classification label for each text use case can be performed as follows: Step 111: Step 111: Configure at least one of the following for each text test case: vehicle model tag, test environment tag, and environment type tag. The vehicle model tag identifies the vehicle model to which the text test case is adapted, the test environment tag identifies the test platform to which the text test case is applicable, and the environment type tag identifies the test mode to which the text test case is applicable.

[0032] In this application, the vehicle model label can be set according to the specific vehicle model, such as model A, model B, model C, etc. Different vehicle models may have different software functions, therefore, corresponding test cases need to be configured for different models. The test environment label is used to identify the test platform to which the test cases are applicable. Common test environments include real vehicles, various test benches, hardware-in-the-loop (HIL) test platforms, and software-in-the-loop (SIL) test platforms. Hardware-in-the-loop testing connects the physical controller to a virtual simulation environment for testing, used to verify hardware interfaces and real-time performance; software-in-the-loop testing runs the control algorithm model entirely in a computer simulation environment, used for early verification of software logic. The environment type label is used to identify the test mode to which the test cases are applicable, such as hardware-in-the-loop mode, software-in-the-loop mode, etc.

[0033] For example, a text test case used to test the Bluetooth connectivity function of a vehicle's infotainment system, adapted to vehicle model A, and suitable for bench environment and hardware-in-the-loop testing mode, can be configured with three category labels: vehicle model A, bench, and hardware-in-the-loop.

[0034] In this application, by configuring vehicle model tags, test environment tags, and environment type tags, test cases can be classified in multiple dimensions. This allows for the precise selection of applicable test cases based on different testing requirements, avoiding the execution of inapplicable test cases, reducing the time spent on ineffective testing, and improving the relevance and efficiency of testing.

[0035] In step 110 above, configuring a classification label for each text use case can also be performed according to steps 112 to 113 below: Step 112: Establish multiple isolated project spaces in the use case management platform.

[0036] Step 113: Configure the category labels for the corresponding text use cases independently in each project space, and the category labels of different project spaces do not interfere with each other.

[0037] In this application, during actual vehicle software development, testing of multiple projects is typically conducted simultaneously, such as software testing for different vehicle models or different software versions. To avoid confusion between test cases and tags across different projects, multiple isolated project spaces can be established within the test case management platform. Each project space corresponds to an independent test project. Within each project space, text test cases for that project can be created and managed, and category tags can be configured independently. The category tags of different project spaces are independent of each other and will not affect each other.

[0038] For example, if software testing projects for vehicle model A and vehicle model B are carried out simultaneously, separate project spaces for vehicle model A and vehicle model B can be created in the test case management platform. The tags configured in the vehicle model A project space are only valid for test cases within that project, and the tags configured in the vehicle model B project space are only valid for test cases within that project.

[0039] In this application, by establishing multiple isolated project spaces and configuring category tags independently in each project space, parallel testing of multiple projects can be supported, improving the reusability and management efficiency of the test case management platform, avoiding mutual interference between tag configurations of different projects, and ensuring the orderly conduct of testing.

[0040] In step 110 above, configuring a classification label for each text use case may further include the following steps 114 to 115: Step 114: Assign different tag configuration permissions to different users.

[0041] Step 115 allows users with the corresponding permissions to add, modify, and delete category tags for the corresponding text use cases.

[0042] In this application, to ensure the accuracy and security of tag configuration and to prevent unauthorized personnel from arbitrarily modifying tags and causing test errors, an access control mechanism can be set up in the test case management platform to assign different tag configuration permissions to different users.

[0043] For example, users can be categorized into different roles such as test manager, senior test engineer, and regular test engineer. Test managers have permission to configure tags for all test cases across all projects, and can add, modify, and delete tags for any test case. Senior test engineers have permission to configure tags for all test cases within their assigned projects. Regular test engineers only have permission to configure tags for the test cases they are responsible for. When a user needs to manipulate the category tags of a specific text test case, the platform can first verify whether the user has the corresponding permissions. Only users with the appropriate permissions can perform the corresponding operation.

[0044] In this application, by assigning different tag configuration permissions to different users, the tag configuration process can be standardized, the possibility of human error can be reduced, the accuracy and security of tag configuration can be guaranteed, and problems such as test failure or inaccurate test results due to tag errors can be avoided.

[0045] In step 110 above, generating an automation script corresponding to each text use case, wherein the automation script contains a global identifier for the corresponding text use case, can be executed according to step 116 below: Step 116: Write the global identifier corresponding to each text use case into the text use case name of the corresponding automation script to establish a one-to-one correspondence between text use cases and automation scripts.

[0046] In this application, when writing automation scripts, a globally unique identifier can be included as part of the automation script name. This allows the globally unique identifier to be directly extracted from the script name during subsequent use case collection and matching, making it convenient to quickly and accurately find the corresponding text use case information.

[0047] For example, if a text test case has a globally unique identifier of AUTOECU202500123, and the corresponding test function is a normal Bluetooth connection to the vehicle's infotainment system, then the automation script can be named as follows: "testAUTOECU202500123bluetoothconnectnormal".

[0048] This approach eliminates the need to add extra identification information elsewhere in the script code, simplifying the script writing process and facilitating script management and maintenance.

[0049] In this application, by writing a globally unique identifier into the text test case name of the automated script, a stable and easily identifiable one-to-one correspondence between the text test case and the automated script can be established, avoiding matching errors in a large number of scripts. It also simplifies the subsequent test case collection and matching process and improves the efficiency of testing.

[0050] Continue to refer to Figure 1 In step 120, in response to the test execution command of the vehicle software, the target global identifier and target category label corresponding to the text test case to be executed are obtained from the test case management platform.

[0051] In this application, the test execution instruction refers to an instruction initiated by the user based on test requirements, used to instruct the system to execute corresponding test tasks. The test execution instruction may include information such as the test scope, applicable vehicle models, test environment, and environment type. Upon receiving the test execution instruction, the system will, based on the conditions in the instruction, call the relevant interfaces of the test case management platform through the Application Programming Interface (API), query the database of the test case management platform for text test cases that meet the conditions, and obtain the globally unique identifiers and category tags corresponding to these text test cases.

[0052] For example, if a user initiates a test execution command to execute all test cases for vehicle model A in a hardware-in-the-loop environment, the system can call the interface of the test case management platform to query all text test cases with vehicle model A and hardware-in-the-loop tags, and obtain the globally unique identifiers and category tags of these test cases.

[0053] In this application, by responding to test execution instructions and obtaining information about the test cases to be executed from the test case management platform, it is ensured that the obtained test case configuration information is the latest, avoiding test errors caused by using outdated tag information. At the same time, it also realizes centralized management and unified scheduling of test cases.

[0054] In this application, after obtaining the target global identifier and target category label corresponding to the text use case to be executed from the use case management platform, the following step 121 can also be performed: Step 121: Store the obtained target global identifier and target category label in a local database. The local database also stores text use case name, project to which it belongs, and use case number information.

[0055] In this application, the local database can be used to temporarily store test case information obtained from the test case management platform. This allows the system to directly read test case information from the local database during subsequent test execution, eliminating the need for frequent calls to the test case management platform's interface and improving test execution speed. Furthermore, when network failures occur or the test case management platform becomes inaccessible, the system can still use the test case information stored in the local database to continue testing, ensuring test continuity.

[0056] In this application, the local database can be an embedded relational database (SQLite). This type of database can store the entire database, including definitions, tables, indexes, and data, in a single cross-platform file, without requiring a separate server process. It has advantages such as zero configuration, lightweight nature, and ease of deployment, making it very suitable for local data storage. In addition to globally unique identifiers and category tags, the local database can also store information such as text test case names, project names, and test case numbers, facilitating subsequent test result statistics and analysis.

[0057] In this application, by storing the acquired test case information in a local database, the execution speed of the test can be improved, the dependence on the network and test case management platform can be reduced, the robustness of the test system can be enhanced, and data support can be provided for subsequent test result management.

[0058] Continue to refer to Figure 1 In step 130, the target automation script is matched based on the target global identifier, and an execution tag corresponding to the target category tag is dynamically added to the target automation script.

[0059] In this application, during the test case collection phase, the system can scan all automated scripts in a specified directory, extract the globally unique identifier (GUID) from each script name, and then match the extracted GUID with the target GUID stored in the local database. For successfully matched automated scripts, the system can dynamically add the corresponding target category tag as an execution marker to the script. It should be noted that this execution marker is temporary, only effective during the current test run, and is not written into the automated script's code. The process of dynamically adding execution markers can be implemented using hook functions of the test framework. For example, in the pytest test framework, the `pytest_collection_modifyitems` hook function can be used to add markers to test cases during the test case collection process.

[0060] In this application, by matching automated scripts based on globally unique identifiers and dynamically adding execution tags, test case management and script management are decoupled. When it is necessary to modify or add category tags, only modifications need to be made in the test case management platform, without modifying any automated script code, which greatly improves the efficiency of tag modification and reduces maintenance costs.

[0061] In step 130 above, the step of matching the corresponding target automation script based on the target global identifier and dynamically adding an execution tag corresponding to the target classification label to the target automation script can be performed according to the following steps 131 to 133: Step 131: Read the target global identifier and target classification label stored in the local database.

[0062] Step 132: Identify the global identifiers contained in the automation scripts in the use case management platform, and match the identified global identifiers with the target global identifiers in the local database.

[0063] Step 133: Dynamically add an execution tag that matches the target classification tag to the successfully matched automated script.

[0064] During step 131, the system can retrieve the target global identifiers and corresponding target category labels for all test cases to be executed from the local database using a database query. During step 132, the system can iterate through all automated scripts, extracting globally unique identifiers from the script names using string matching or regular expressions. Then, it compares the extracted globally unique identifiers with the target global identifiers in the local database one by one to find matching automated scripts. During step 133, the system can add an execution marker that is completely identical to the target category label to each successfully matched automated script.

[0065] For example, the globally unique identifier of a certain test case stored in the local database is AUTOECU202500123, and the corresponding category tags are vehicle type A, bench, and hardware in the loop. When the system scans the automated script named testAUTOECU202500123bluetoothconnectnormal, it extracts the globally unique identifier AUTOECU202500123. After successfully matching it with the target global identifier in the local database, it dynamically adds the three execution tags of vehicle type A, bench, and hardware in the loop to the script.

[0066] In this application, by executing the process of reading the local database, matching global identifiers, and dynamically adding execution markers step by step, it can be ensured that each automated script can accurately obtain the corresponding execution markers, thereby improving the accuracy and reliability of test case selection and ensuring the smooth progress of testing.

[0067] Continue to refer to Figure 1 In step 140, the automated script is filtered according to the execution marker and the test is executed.

[0068] In this application, after all the execution tags of the automated scripts have been added, the system can filter out the automated scripts that meet the conditions and execute the test according to the execution tag conditions specified in the test execution instruction.

[0069] For example, if the test execution command specifies that test cases with the vehicle model A and hardware-in-the-loop (HIL) tags should be executed, the system can filter out automated scripts that have both of these tags, execute these scripts in a preset order, and record the test results. In the pytest testing framework, the tags to be executed can be specified using the -m parameter. For example, the command pytest -m "vehicle model A and hardware-in-the-loop" can be used to execute test cases with both vehicle model A and HIL tags.

[0070] In this application, by executing automated scripts for tagging and filtering and then performing tests, test cases that meet the test requirements can be executed precisely, avoiding the execution of unnecessary test cases, shortening the test cycle, improving test efficiency, and ensuring the comprehensiveness and relevance of the tests.

[0071] In this application, after filtering the automated script according to the execution flag and executing the test, the following steps 151 to 152 can be performed: Step 151: Bind the test results to the global identifier and category label of the corresponding automation script.

[0072] Step 152: Store the bound test results in the test case management platform and grant access permissions to the test results based on user permissions.

[0073] In this application, the test results may include the execution status, execution time, error information, logs, etc., of the test cases. After the test execution is complete, the system can bind the test results of each test case with the corresponding global identifier and category tag, allowing for quick retrieval of the corresponding test results via the global identifier or category tag. After binding, the system can upload the test results to the test case management platform for storage, achieving centralized management of test data. Simultaneously, the platform can grant access permissions to test results based on user privileges; users with different permissions can only view the test results they are authorized to access. For example, a regular test engineer can only view the test results of the test cases they are responsible for, while a test manager can view the test results of all projects.

[0074] In this application, by binding test results with global identifiers and category tags and storing them in the test case management platform, and by granting access permissions based on user permissions, the traceability and security of test data can be achieved, making it convenient for testers to query and analyze test results, locate software defects, and improve the quality and efficiency of testing.

[0075] In this application, steps 161 to 163 may also be performed: Step 161: In response to the batch modification instruction for category labels, export a list of use cases containing global identifiers and corresponding category labels from the use case management platform.

[0076] Step 162: Use a table editing tool to batch edit the category labels in the use case list.

[0077] Step 163: Re-import the edited use case list into the use case management platform to update the category tags corresponding to the text use cases.

[0078] In this application, when it is necessary to modify or add category tags for a large number of text use cases, the batch modification function can be used.

[0079] Specifically, users can first initiate a batch modification command for category tags within the use case management platform. The platform can then export a list of eligible use cases as a spreadsheet file, such as an Excel file. The exported use case list includes a global identifier, text use case name, category tag, and other information for each use case. Users can then use a spreadsheet editing tool to batch edit the exported use case list, such as adding new tags, modifying existing tags, or deleting unnecessary tags in the category tag column. After editing, users can re-import the edited use case list into the use case management platform, which will then update the category tags for the corresponding text use cases based on the global identifier.

[0080] For example, when it is necessary to add the vehicle model B label to all use cases that are compatible with vehicle model A, the user can export a list of all use cases with the vehicle model A label, add vehicle model B in batches in the category label column in Excel, and then re-import it to the platform. The platform can automatically add the vehicle model B label to these use cases.

[0081] In this application, by providing a batch modification function for category labels, the label modification work of a large number of test cases can be completed quickly without modifying any automated script code, which greatly reduces the workload and error probability of label modification and improves the iteration speed of testing. It is especially suitable for vehicle software testing scenarios with a large number of automated test cases.

[0082] The following describes an embodiment of the apparatus described in this application, which can be used to execute the vehicle software testing method described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the vehicle software testing method described above.

[0083] See Figure 2 The diagram shows a block diagram of a vehicle software testing apparatus according to an embodiment of this application.

[0084] like Figure 2 As shown, the vehicle software testing apparatus 200 according to an embodiment of this application includes: an allocation unit 201, an acquisition unit 202, a matching unit 203, and an execution unit 204.

[0085] The system includes: an allocation unit 201, configured to assign a unique global identifier and configure a category label for each pre-created text test case in the test case management platform, and generate an automation script corresponding to each text test case, wherein the automation script contains the global identifier of the corresponding text test case; an acquisition unit 202, configured to acquire the target global identifier and target category label corresponding to the text test case to be executed from the test case management platform in response to the test execution command of the vehicle software; a matching unit 203, configured to match the corresponding target automation script based on the target global identifier, and dynamically add an execution mark corresponding to the target category label to the target automation script; and an execution unit 204, configured to filter the automation script according to the execution mark and execute the test.

[0086] In some embodiments of this application, based on the foregoing scheme, the allocation unit 201: configures at least one of a vehicle model label, a test environment label, and an environment type label for each text use case; wherein, the vehicle model label is used to identify the vehicle model to which the text use case is adapted, the test environment label is used to identify the test carrier to which the text use case is applicable, and the environment type label is used to identify the test mode to which the text use case is applicable.

[0087] In some embodiments of this application, based on the aforementioned scheme, the allocation unit 201: establishes multiple mutually isolated project spaces in the use case management platform; and independently configures the classification tags of corresponding text use cases in each project space.

[0088] In some embodiments of this application, based on the aforementioned scheme, the allocation unit 201: writes the global identifier corresponding to each text use case into the text use case name of the corresponding automation script, so as to establish a one-to-one correspondence between text use cases and automation scripts.

[0089] In some embodiments of this application, based on the foregoing scheme, the device further includes: a storage unit, used to store the obtained target global identifier and target category label corresponding to the text use case to be executed in a local database after obtaining the target global identifier and target category label corresponding to the text use case to be executed from the use case management platform, wherein the local database also stores the text use case name, the project to which it belongs and the use case number information.

[0090] In some embodiments of this application, based on the foregoing scheme, the matching unit 203: reads the target global identifier and target category label stored in the local database; identifies the global identifier contained in the automation script in the use case management platform, and matches the identified global identifier with the target global identifier in the local database; dynamically adds an execution tag consistent with the target category label to the successfully matched automation script.

[0091] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes: an update unit, configured to, in response to a batch modification instruction for category tags, export a list of use cases containing global identifiers and corresponding category tags from the use case management platform; batch edit the category tags in the use case list using a table editing tool; and re-import the edited use case list into the use case management platform to update the category tags corresponding to the text use cases.

[0092] In some embodiments of this application, based on the foregoing scheme, the device further includes: a binding unit, configured to bind the test results with the global identifier and category tag of the corresponding automated script after the automated script is filtered and the test is executed according to the execution marker; store the bound test results in the test case management platform; and grant access permissions to the test results based on user permissions.

[0093] Based on the same inventive concept, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor so as to cause a computer device having the processor to perform operations performed by the vehicle software testing method described above.

[0094] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to perform the operations performed by the vehicle software testing method described above.

[0095] Based on the same inventive concept, this application also provides an electronic device, see reference. Figure 3 The diagram shows a schematic of the structure of an electronic device in an embodiment of this application. The electronic device includes one or more memories 304, one or more processors 302, and at least one computer program (computer program instruction) stored in the memory 304 and executable on the processor 302. When the processor 302 executes the computer program, it implements the vehicle software testing method as described above.

[0096] Among them, Figure 3 In this document, a bus architecture (represented by bus 300) is used. Bus 300 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 302 and memory represented by memory 304. Bus 300 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 305 provides an interface between bus 300 and receiver 301 and transmitter 303. Receiver 301 and transmitter 303 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 302 is responsible for managing bus 300 and general processing, while memory 304 can be used to store data used by processor 302 during operation.

[0097] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

[0098] In the several 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 instance, 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 coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0099] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; 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.

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

[0101] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method of testing vehicle software, characterized by, The method includes: In the use case management platform, a unique global identifier is assigned to each pre-created text use case, and a category label is configured. An automated script corresponding to each text use case is generated, and the automated script contains the global identifier of the corresponding text use case. In response to the test execution command of the vehicle software, the target global identifier and target category label corresponding to the text test case to be executed are obtained from the test case management platform; Based on the target global identifier, match the corresponding target automation script, and dynamically add the execution tag corresponding to the target category tag to the target automation script; The automated script for tagging and filtering is executed, and tests are performed accordingly.

2. The method of claim 1, wherein, Configure category labels for each of the text use cases, including: Configure at least one of the following for each text test case: vehicle model tag, test environment tag, and environment type tag; wherein the vehicle model tag is used to identify the vehicle model to which the text test case is adapted, the test environment tag is used to identify the test carrier to which the text test case is applicable, and the environment type tag is used to identify the test mode to which the text test case is applicable.

3. The method of claim 1, wherein, Configuring category labels for each of the text use cases also includes: Multiple isolated project spaces are established within the use case management platform; Configure category tags for corresponding text use cases independently within each project space.

4. The method of claim 1, wherein, The generation of an automated script corresponding to each text use case, wherein the automated script contains a global identifier for the corresponding text use case, including: Write the global identifier corresponding to each text test case into the text test case name of the corresponding automation script to establish a one-to-one correspondence between text test cases and automation scripts.

5. The method of claim 1, wherein, After obtaining the target global identifier and target category label corresponding to the text use case to be executed from the use case management platform, the method further includes: The obtained target global identifier and target category label are stored in a local database. The local database also stores text use case names, project names, and use case numbers.

6. The method of claim 5, wherein, The step of matching the target automation script based on the target global identifier and dynamically adding an execution tag corresponding to the target category label to the target automation script includes: Read the target global identifier and target category label stored in the local database; Identify the global identifiers contained in the automation scripts in the use case management platform, and match the identified global identifiers with the target global identifiers in the local database; Dynamically add execution tags that match the target category label to the successfully matched automated scripts.

7. The method of claim 1, wherein, The method further includes: In response to the batch modification instruction for category labels, a list of use cases containing global identifiers and corresponding category labels is exported from the use case management platform; Batch edit the category labels in the use case list using a table editing tool; Re-import the edited use case list into the use case management platform to update the category tags corresponding to the text use cases.

8. The method according to claim 1, characterized in that, After filtering the automated scripts according to the execution flags and executing the tests, the method further includes: Bind the test results to the global identifier and category label of the corresponding automation script; The bound test results are stored in the test case management platform, and access permissions for the test results are granted based on user permissions.

9. A testing apparatus for vehicle software, characterized in that, The device includes: The allocation unit is used to assign a unique global identifier to each pre-created text use case in the use case management platform, configure classification tags, and generate an automation script corresponding to each text use case, wherein the automation script contains the global identifier of the corresponding text use case. The acquisition unit is used to obtain the target global identifier and target category label corresponding to the text test case to be executed from the test case management platform in response to the test execution command of the vehicle software. A matching unit is used to match the corresponding target automation script based on the target global identifier, and dynamically add an execution tag corresponding to the target category tag to the target automation script; An execution unit is used to filter automated scripts and execute tests based on the execution flags.

10. An electronic device, characterized in that, The electronic device includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as described in any one of claims 1 to 8.

Images