A vehicle end service function test method, device, equipment and medium

Abstract

The application relates to the technical field of software testing, and discloses a vehicle-side service function testing method, device, equipment and medium. The method comprises the following steps: obtaining a plurality of services in a vehicle-side application and a plurality of service corresponding to-be-tested function parameters; according to the function characteristics of the plurality of services, determining a to-be-tested scene category, and according to the to-be-tested scene category and a preset to-be-tested scene generation strategy, combining the plurality of services and the to-be-tested function parameters to generate a to-be-tested scene; according to the to-be-tested scene, generating a test case, and controlling a pre-configured execution simulator to receive the test case and execute testing on the vehicle-side service function. In the application, the plurality of services and the to-be-tested function parameters are combined to obtain the to-be-tested scene according to the function characteristics of the vehicle-side service, the same test scene is not generated for different demand information, the repetition of the service function testing is avoided, the coverage of the test scene is improved, and the test efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to a method, apparatus, equipment, and medium for testing vehicle-side service-oriented functions. Background Technology

[0002] Service-Oriented Architecture (SOA) defines a method for reusing software components through service interfaces. These interfaces use common communication standards that can be quickly integrated into new applications without requiring deep integration each time. Each service in SOA contains the code and data integration needed to perform a complete, independent business function. These service interfaces provide loose coupling, allowing users to call them even without knowing how the underlying integration is implemented.

[0003] With the development of vehicle-to-everything (V2X) technology, Service-Oriented Architecture (SOA) has been widely applied to vehicles. Service-oriented functionalities are increasingly used in vehicle applications. As the number of applications and their functions diversify, the scenarios involving vehicle-side service-oriented functionalities are expanding, providing users with an exceptional experience. However, vehicle-side service-oriented architecture is a relatively new technology, and currently, there are no systematic testing tools or methods. Furthermore, there are thousands upon thousands of vehicle-side service-oriented functionalities, with different applications repeatedly calling these functionalities, and various services existing across different application scenarios. Therefore, using current software testing methods to test SOA service-oriented functionalities leads to problems such as repetitive testing, incomplete coverage of numerous test scenarios, and low testing efficiency due to the sheer number of services. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a method, apparatus, equipment and medium for testing vehicle-side service functions, so as to solve the problems of repetitive testing, incomplete coverage of multiple testing scenarios and low testing efficiency in the prior art.

[0005] To achieve the above and other related objectives, this application provides a method for testing vehicle-side service-oriented functions, the method comprising:

[0006] Obtain multiple services in the vehicle application and the corresponding function parameters to be tested for the multiple services;

[0007] Based on the functional characteristics of the multiple services, the category of the scenario to be tested is determined, and based on the category of the scenario to be tested and the preset scenario generation strategy, the multiple services and the parameters of the function to be tested are combined to generate the scenario to be tested.

[0008] Based on the scenario to be tested, test cases are generated, and a pre-configured execution simulator is controlled to receive the test cases and execute tests on the vehicle-side service functions.

[0009] In one embodiment of this application, obtaining multiple services in the vehicle-side application and the corresponding functional parameters to be tested for the multiple services includes:

[0010] Obtain information on vehicle-side application requirements;

[0011] The vehicle application requirement information is parsed to identify multiple services in the vehicle application and to call the service-oriented functional parameter requirement information corresponding to the multiple services.

[0012] Based on the service-oriented functional parameter requirement information, the functional parameters to be tested corresponding to the multiple services are obtained.

[0013] In one embodiment of this application, obtaining the test function parameters corresponding to the plurality of services based on the service-oriented function parameter requirement information includes:

[0014] Based on the service-oriented functional parameter requirement information, determine the parameter type of the functional parameter to be tested for each service;

[0015] If the parameter type is string, then obtain the length range of the string parameter to get the first parameter range;

[0016] If the parameter type is numeric, then obtain the value range of the numeric parameter to obtain the second parameter range;

[0017] The first parameter range and / or the second parameter range corresponding to the multiple services are divided into equivalence classes to obtain the valid parameter range, and the test function parameters corresponding to the multiple services are obtained according to the boundary values ​​of the valid parameter range.

[0018] In one embodiment of this application, after obtaining multiple services in the vehicle-side application and the corresponding function parameters to be tested for the multiple services, the method further includes:

[0019] If the parameter of the function to be tested is the minimum value of the boundary within the preset priority parameter range, then the priority of the parameter of the function to be tested is set to the first priority level.

[0020] If the parameter to be tested is a boundary value other than the minimum boundary value within the range of the priority parameter, then the priority of the parameter to be tested is set to the second priority level.

[0021] If the parameter of the function to be tested is within the equivalent range corresponding to the priority parameter range, then the priority of the parameter of the function to be tested is set to the third priority level.

[0022] Based on the first-level priority and / or second-level priority and / or third-level priority of the parameters of the functions to be tested corresponding to the multiple services, first priority information is obtained, and the first priority information is used to combine with the scenario to be tested to obtain the test case.

[0023] In one embodiment of this application, the step of combining the multiple service and function parameters to generate a test scenario according to the test scenario category and a preset test scenario generation strategy includes:

[0024] If the scene to be tested is a fixed scene, then a preset fixed combination method corresponding to the fixed scene is invoked;

[0025] According to the fixed combination method, the multiple services and the corresponding functional parameters to be tested are combined to obtain the scenario to be tested.

[0026] In one embodiment of this application, the step of combining the multiple service and function parameters to generate a test scenario according to the test scenario category and a preset test scenario generation strategy includes:

[0027] If the scenario to be tested is a free combination scenario, then a key-value pair list is generated based on the multiple services and the corresponding functional parameters to be tested. The key of the key-value pair list is the functional parameters to be tested corresponding to the multiple services, and the value of the key-value pair list is the multiple services. The number of rows in the key-value pair list is the same as the number of functional parameters to be tested corresponding to the multiple services.

[0028] According to the preset key-value combination method, the keys and values ​​in the key-value pair list are combined to obtain the scene to be tested.

[0029] In one embodiment of this application, after generating test cases based on the scenario to be tested, the method further includes:

[0030] Generate test scripts corresponding to the test cases, and combine multiple test cases and their corresponding test scripts to obtain a test project. When the test project is invoked, the test scripts are run to control the execution simulator to receive and run the test cases.

[0031] Based on the first priority information, the priorities of the parameters of the function to be tested in each test case are superimposed to obtain the superimposed priority;

[0032] The priority of each test case is determined based on the number of services in each test case and the combined priority.

[0033] If the number of services is equal to the combined priority, then the priority of the test case is set to the first priority level.

[0034] If the combined priority is greater than one times the number of services and less than or equal to two times the number of services, then the priority of the test case is set to the second priority level.

[0035] If the combined priority is greater than twice the number of services and less than or equal to three times the number of services, then the priority of the test case is set to the third priority level.

[0036] If the combined priority is greater than three times the number of services and less than or equal to four times the number of services, then the priority of the test case is set to the fourth priority level.

[0037] Based on the first priority level and / or the second priority level and / or the third priority level and / or the fourth priority level, a second priority information is obtained, which is used to determine whether to call the test project.

[0038] In one embodiment of this application, after obtaining the second priority information, the method further includes:

[0039] If the second priority information matches the preset test project call priority, then the test project is called and the test script is run;

[0040] If the execution simulator cannot receive the test case, or the execution simulator cannot run the test case, then the test case is determined to have a defect.

[0041] The test scenario and the first priority information are recombined to obtain new test cases and generate new test scripts.

[0042] In one embodiment of this application, after obtaining new test cases and generating new test scripts, the method further includes:

[0043] Run the new test script to regain control of the execution simulator, receive the new test cases, and execute tests on the vehicle-side service-oriented functions.

[0044] Based on the results of running the new test script and the results of running the new test cases in the simulator, a test log is generated.

[0045] In one embodiment of this application, after controlling the pre-configured execution simulator to receive the test cases and execute tests on the vehicle-side service-oriented functions, the method further includes:

[0046] Obtain the vehicle-side service-oriented function test results returned by the execution simulator. The vehicle-side service-oriented function test results include test case defects and defect levels, and the defect levels correspond to the second priority information.

[0047] Based on the preset correspondence between defect levels and defect rates, the defect rate of each test case in the test project is calculated, and the defect rates of each test case in the test project are added together to obtain the test project defect rate.

[0048] If the defect rate of the test item is less than the preset defect rate threshold, then the vehicle-side service function test is deemed to have passed.

[0049] If the defect rate of the test item is greater than the preset defect rate threshold, the vehicle-side service function test is determined to have failed, and test cases are regenerated based on the test case defects.

[0050] In one embodiment of this application, a vehicle-side service functionality testing device is also provided, the device comprising:

[0051] The data acquisition module is used to acquire multiple services in the vehicle application and the corresponding functional parameters to be tested for the multiple services;

[0052] The test scenario generation module is used to determine the test scenario category based on the functional characteristics of the multiple services, and to combine the multiple services and test function parameters to generate the test scenario based on the test scenario category and the preset test scenario generation strategy.

[0053] The testing module is used to generate test cases based on the scenario to be tested, and to control the pre-configured execution simulator to receive the test cases and execute tests on the vehicle-side service functions.

[0054] In one embodiment of this application, an electronic device is also provided, the electronic device comprising:

[0055] One or more processors;

[0056] A storage device for storing one or more programs, which, when executed by one or more processors, enable the electronic device to implement the vehicle-side service function testing method as described above.

[0057] In one embodiment of this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a computer's processor, causes the computer to perform the vehicle-side service function testing method as described above.

[0058] The beneficial effects of this invention are:

[0059] First, multiple services in the vehicle-side application and their corresponding functional parameters to be tested are obtained. Then, based on the functional characteristics of the multiple services, the categories of test scenarios are determined. According to the test scenario categories and a preset test scenario generation strategy, the multiple services and the functional parameters to be tested are combined to generate test scenarios. Finally, test cases are generated based on the test scenarios, and a pre-configured execution simulator is controlled to receive and execute the test cases to test the vehicle-side service-oriented functions. In this invention, by combining multiple services and functional parameters to be tested based on the functional characteristics of the vehicle-side services to obtain test scenarios, the same test scenarios are not generated for different requirements, thus avoiding duplication of service-oriented function testing, improving test scenario coverage, and consequently improving testing efficiency.

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

[0061] 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:

[0062] Figure 1 This is a schematic diagram illustrating the implementation environment of a vehicle-side service-oriented function testing method, as shown in an exemplary embodiment of this application.

[0063] Figure 2 This is a flowchart illustrating a vehicle-side service-oriented function testing method as shown in an exemplary embodiment of this application;

[0064] Figure 3 This is a schematic diagram illustrating a scene generation strategy corresponding to a freely combinable scene, as shown in an exemplary embodiment of this application;

[0065] Figure 4 This is a schematic diagram of a test bench for supporting a vehicle-side service-oriented function testing method, as shown in an exemplary embodiment of this application.

[0066] Figure 5 This is a flowchart illustrating a vehicle-side service-oriented function testing method, as shown in another exemplary embodiment of this application.

[0067] Figure 6 This is a block diagram illustrating a vehicle-side service-oriented function testing apparatus according to an exemplary embodiment of this application;

[0068] Figure 7This is a block diagram illustrating a vehicle-side service-oriented function testing apparatus, as shown in another exemplary embodiment of this application.

[0069] Figure 8 A schematic diagram of the structure of a computer system suitable for an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0070] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0071] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0072] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0073] First, it's important to note that with the trend of the "new four modernizations" of automobiles (electrification, connectivity, intelligence, and sharing), the demands of the new car-buying demographic have undergone significant changes. While cars are fully realizing connectivity, autonomous driving, and data-driven capabilities, they are also increasingly focused on directly reaching users, improving experience and services, and meeting personalized user needs. SOA (Service-Oriented Architecture) is both a software architecture and a software design philosophy. In SOA, services are the core abstraction and the most fundamental unit of the system. Each service has independent functionality, and the interfaces between services follow a unified standard, allowing for mutual access, composition, and expansion. In the vehicle-side, based on SOA, the number of services increases with the number of applications. Therefore, the coverage and efficiency of test scenarios are crucial for service testing. Some existing technologies involve defining test items to obtain test requirements, scanning the paths of these requirements to obtain several test scenarios, generating corresponding test data based on these scenarios, and finally adding the test data to the expected scenarios to form test cases. The aforementioned technical solutions primarily describe the entire process of requirement input, test requirement generation, test scenario generation, and test case output. However, they do not explain in detail how test scenarios are obtained through path scanning of test requirements, how test data is generated, or how test data and test scenarios are combined to generate test cases. Furthermore, while the aforementioned technical solutions primarily obtain test cases through a combination of test scenarios and data, which improves test case coverage, it also results in duplicate test cases, increasing the workload of test execution and reducing test efficiency. Finally, the aforementioned technical solutions do not disclose how to perform test execution, how to generate test results, how to generate test cases through regression testing, or how to perform regression testing. Therefore, the solution in this application primarily addresses the problems of duplicate service function testing, incomplete coverage of numerous test scenarios, and low testing efficiency caused by the increasing and diversification of service functions in vehicle-side SOA architectures.

[0074] The following explains the technical terms used in this application:

[0075] `string` is a type of string used in various programming languages. A string is a special object and belongs to the reference type. In this embodiment, vehicle-side application requirement information is obtained through user input or system input. This requirement information limits the service-oriented function parameter requirements and restricts the data type of the parameters. When the parameter data type is `string`, the length range of the `string` parameter needs to be determined for subsequent determination of the parameters of the function to be tested.

[0076] Priority: In this application embodiment, priority includes the priority of the function parameter to be tested, the priority of test cases, and the priority of defects. Specifically, when the same batch of test cases are to be tested under the same testing computing power conditions, the priority of the function parameter to be tested can determine which test cases need to be run and which do not. The priority of test cases can guide the execution module to select and execute test items containing test cases and test scripts. The priority of defects, because different test cases correspond to different priorities, means that defects occurring during the test execution will correspond to the test cases, and the values ​​of defects corresponding to different priority levels are also different, which can be used to generate subsequent test results.

[0077] Key-value pairs: In computer science, key-value pairs, also known as name-value pairs or attribute-value pairs, are a basic data representation. When it is necessary to extend the data model without modifying existing code or data using open data structures, all or part of the data model can be represented as a collection of tuples, where each element is a name-value pair.

[0078] A test case is a set of test inputs, execution steps, and expected results designed for a specific test objective, in order to test the path of a program or verify whether the software meets a specific requirement. In this embodiment, the test case includes a test scenario (which contains multiple corresponding services and parameters of the function to be tested) and priority information of the parameters of the function to be tested.

[0079] Test script: A test script is a series of instructions for a specific test. It is a computer-readable instruction that automates the test process and can be executed by automated testing tools. To improve the maintainability and reusability of test scripts, they must be built before execution. In this embodiment, after obtaining the test cases, the corresponding test scripts are generated. After the test scripts run successfully, the test cases are transferred to the test execution simulator for execution.

[0080] DI value (Defect Index): The DI value is one of the standards for measuring the quality of software. It can be calculated based on the severity and number of bugs (defects). In this embodiment, a test project is invoked and its test cases are run. The defect rate of the current test project is determined by the number of defects and the defect level in the test case execution results.

[0081] Figure 1 This is a schematic diagram illustrating the implementation environment of a vehicle-side service-oriented function testing method, as shown in an exemplary embodiment of this application.

[0082] Reference Figure 1As shown, the implementation environment may include a vehicle-side service-oriented function testing terminal 101, a cloud platform 102, and an information storage terminal 103. The vehicle-side service-oriented function testing terminal 101 may include electronic devices such as tablets, laptops, and desktop computers, used to receive information, generate test projects, execute tests, and generate test results. The cloud platform 102 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services, used to store vehicle-side application requirement information, test logs, and test results. The information storage terminal 103 is used to store vehicle-side application requirement information and may also be used to acquire and store test results and / or test logs transmitted by the vehicle-side service-oriented function testing terminal 101.

[0083] In addition, the technical solution provided in this application embodiment can be applied to the vehicle-side service function test terminal 101. The vehicle-side service function test terminal 101 is used to connect to the cloud 102 and the information storage terminal 103 through the network and obtain vehicle-side application requirement information. At the same time, the cloud 102 and the information storage terminal 103 also receive and store the test results and test logs generated by the vehicle-side service function test terminal 101.

[0084] In one embodiment of this application, a vehicle-side service-oriented function testing terminal 101 acquires multiple services in a vehicle-side application and corresponding test function parameters for those services. Based on the functional characteristics of the multiple services, it determines the test scenario category and, according to the test scenario category and a preset test scenario generation strategy, combines the multiple services and test function parameters to generate a test scenario. Based on the test scenario, it generates test cases and controls a pre-configured execution simulator to receive and execute the test cases to test the vehicle-side service-oriented functions. By combining multiple services and test function parameters based on the functional characteristics of the vehicle-side services to obtain the test scenario, the same test scenario is not generated for different requirements, thus avoiding duplication of service-oriented function testing, improving test scenario coverage, and consequently improving testing efficiency.

[0085] The above section introduced the exemplary implementation environment of the technical solution of this application. Next, we will continue to introduce the vehicle-side service function testing method of this application.

[0086] To address the problems of repetitive testing, incomplete coverage of numerous testing scenarios, and low testing efficiency in existing service-oriented function testing technologies, embodiments of this application propose a vehicle-side service-oriented function testing method, a vehicle-side service-oriented function testing device, an electronic device, a computer-readable storage medium, and a computer program product, which will be described in detail below.

[0087] Please see Figure 2 , Figure 2This is a flowchart illustrating an exemplary embodiment of the vehicle-side service-oriented function testing method, which can be applied to... Figure 1 The implementation environment is shown. It should be understood that this method can also be applied to other exemplary implementation environments and specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0088] like Figure 2 As shown, in an exemplary embodiment, the vehicle-side service-oriented function testing method includes at least steps S210 to S230, which are described in detail below:

[0089] In step S210, multiple services in the vehicle application and the corresponding functional parameters to be tested are obtained.

[0090] It should be noted that the vehicle-side application has multiple functions. Based on SOA, the vehicle-side application is divided into multiple functional services. When the vehicle needs to output an execution signal for a certain action in a certain scenario, it calls the target service through a pre-configured service interface. In this embodiment, the service list of the vehicle-side application is obtained. The service list includes the names, types, and parameters of the functions to be tested for multiple services. The parameters to be tested can be parameter ranges or specific parameter values. In this embodiment, specific parameter values ​​are selected as the parameters to be tested.

[0091] In step S220, the test scenario category is determined based on the functional characteristics of multiple services, and the test scenario is generated by combining multiple services and test function parameters according to the test scenario category and the preset test scenario generation strategy.

[0092] It should be noted that the test scenario categories include fixed scenario categories and freely combinable scenario categories. Fixed scenario categories may include, for example, highway driving scenarios and automatic parking driving scenarios. Freely combinable scenarios are scenarios generated by freely combining services during vehicle-side service-oriented function testing. Because users can combine services according to their personal preferences and current needs to realize scenario creation during actual vehicle use, the free combination of services and test parameters in this application embodiment during the service-oriented function testing phase can both simulate the scenario generation process in the real environment and improve the scenario coverage.

[0093] In step S230, test cases are generated according to the scenario to be tested, and the pre-configured execution simulator is controlled to receive the test cases and execute tests on the vehicle-side service functions.

[0094] It should be noted that in this embodiment, test cases can be generated directly based on the scenario to be tested; alternatively, multiple scenarios to be tested obtained in step S220 can be combined with the first priority information of the corresponding functional parameters to be tested to generate test cases. The simulator receives and runs the test cases to test the vehicle-side service functions and outputs the test results. Furthermore, when the same test project contains multiple test cases, the first priority information can be used to determine which test cases to run and which not to run, thereby improving testing efficiency.

[0095] As can be seen from steps S210 to S230 above, the solution proposed in this embodiment combines multiple services and parameters of the function to be tested through the functional characteristics of the vehicle-side service to obtain the test scenario. This avoids the situation of generating the same test scenario for different requirement information, avoids duplication of service-oriented function testing, improves the coverage of test scenarios, and thus improves testing efficiency.

[0096] In one embodiment of this application, Figure 2 Step S210, which involves obtaining multiple services in the vehicle application and the corresponding parameters of the functions to be tested, includes the following steps:

[0097] Obtain information on vehicle-side application requirements;

[0098] The vehicle application requirement information is parsed to identify multiple services in the vehicle application and to call the service-oriented functional parameter requirement information corresponding to the multiple services.

[0099] Based on the service-oriented functional parameter requirement information, the functional parameters to be tested corresponding to the multiple services are obtained.

[0100] For example, the vehicle-side service-oriented function test terminal 101 obtains vehicle-side application requirement information pre-stored in the cloud 102 and / or information storage terminal 103 via the network. The vehicle-side application requirement information may be, for example, a service list, which includes multiple services, the functional characteristics of multiple services (i.e., applicable scenarios), and service-oriented function parameter requirement information of multiple services. The service-oriented function parameter requirement information includes information such as parameter type and parameter range.

[0101] In one embodiment of this application, obtaining the test function parameters corresponding to the plurality of services based on the service-oriented function parameter requirement information includes the following steps:

[0102] Based on the service-oriented functional parameter requirement information, determine the parameter type of the functional parameter to be tested for each service;

[0103] If the parameter type is string, then obtain the length range of the string parameter to get the first parameter range;

[0104] If the parameter type is numeric, then obtain the value range of the numeric parameter to obtain the second parameter range;

[0105] The first parameter range and / or the second parameter range corresponding to the multiple services are divided into equivalence classes to obtain the valid parameter range, and the test function parameters corresponding to the multiple services are obtained according to the boundary values ​​of the valid parameter range.

[0106] For example, the parameter type and range are obtained through service-oriented functional parameter requirement information. If the parameter is a string parameter, its length range is obtained; if the parameter is a numeric parameter, its value range is obtained. Then, each parameter to be tested is obtained according to the equivalence class boundary value algorithm. It should be noted that during the testing process, sometimes multiple parameters within the same parameter range are selected to obtain the parameters to be tested. In the process of generating the test scenario, some different parameters will correspond to the same test scenario. Although this improves the scenario coverage, it also increases the number of tests and reduces testing efficiency. In this embodiment, equivalence class partitioning is used to reasonably classify the test processes that cannot be exhaustively enumerated, thereby ensuring the completeness and representativeness of the test cases.

[0107] In one embodiment of this application, Figure 2 After obtaining multiple services in the vehicle-side application and the corresponding function parameters to be tested in step S210, the following steps are also included:

[0108] If the parameter of the function to be tested is the minimum value of the boundary within the preset priority parameter range, then the priority of the parameter of the function to be tested is set to the first priority level.

[0109] If the parameter to be tested is a boundary value other than the minimum boundary value within the range of the priority parameter, then the priority of the parameter to be tested is set to the second priority level.

[0110] If the parameter of the function to be tested is within the equivalent range corresponding to the priority parameter range, then the priority of the parameter of the function to be tested is set to the third priority level.

[0111] Based on the first-level priority and / or second-level priority and / or third-level priority of the parameters of the functions to be tested corresponding to the multiple services, first priority information is obtained, and the first priority information is used to combine with the scenario to be tested to obtain the test case.

[0112] For example, after obtaining the first priority information, the first priority information and the test scenario are combined to obtain test cases. Different test cases contain different test scenarios, and different test scenarios contain different parameters of the function to be tested. The first priority information corresponding to different parameters of the function to be tested can indicate whether to run the test case. The priority is 1 when the parameter of the function to be tested is the minimum value within the priority parameter range; the priority is 2 when the parameter of the function to be tested is another boundary value within the priority parameter range; the priority is 3 when the parameter of the function to be tested is within the equivalence class range; and the priority is 4 when the parameter of the function to be tested does not meet any of the above three conditions.

[0113] In one embodiment of this application, the test scene category includes fixed scenes. Figure 2 Step S220, as shown, involves combining the parameters of the multiple services and functions to be tested to generate a test scenario based on the test scenario category and a preset test scenario generation strategy. This includes the following steps:

[0114] If the scene to be tested is a fixed scene, then a preset fixed combination method corresponding to the fixed scene is invoked;

[0115] According to the fixed combination method, the multiple services and the corresponding functional parameters to be tested are combined to obtain the scenario to be tested.

[0116] For example, based on the functional characteristics of the service, it is determined whether the current service corresponds to a fixed scenario type or a freely combinable scenario type. For instance: Service A can be applied to the first fixed scenario and the second freely combinable scenario; Service B can be applied to the second fixed scenario and the first freely combinable scenario; Service C can be applied to the third fixed scenario; Service D can be applied to the third freely combinable scenario; Service E can be applied to the first fixed scenario; and Service F can be applied to the second fixed scenario. Then, Service A and its corresponding functional parameters to be tested are combined with Service E and its corresponding functional parameters to be tested to generate the first fixed scenario; and Service B and its corresponding functional parameters to be tested are combined with Service F and its corresponding functional parameters to be tested to generate the first fixed scenario.

[0117] In one embodiment of this application, the test scenario category includes freely combinable scenarios. Figure 2 Step S220, as shown, involves combining the parameters of the multiple services and functions to be tested to generate a test scenario based on the test scenario category and a preset test scenario generation strategy. This includes the following steps:

[0118] If the scenario to be tested is a free combination scenario, then a key-value pair list is generated based on the multiple services and the corresponding functional parameters to be tested. The key of the key-value pair list is the functional parameters to be tested corresponding to the multiple services, and the value of the key-value pair list is the multiple services. The number of rows in the key-value pair list is the same as the number of functional parameters to be tested corresponding to the multiple services.

[0119] According to the preset key-value combination method, the keys and values ​​in the key-value pair list are combined to obtain the scene to be tested.

[0120] For example, see Figure 3 , Figure 3 This is a schematic diagram illustrating a scenario generation strategy corresponding to a freely combinable scenario, as shown in an exemplary embodiment of this application. First, the number of services A and the number of parameters of the function to be tested B are obtained; then, based on A and B, a scenario generation strategy is generated. Figure 3 The key-value pair list shown has B rows, the value of each key-value pair is "all services", and the number of values ​​in each key-value pair is A. Finally, according to the preset key-value combination method, the keys and values ​​in the key-value pair list are combined to obtain the scenario to be tested. In this embodiment, the preset key-value combination method is to combine all keys and values ​​using a heuristic algorithm and generate the test scenario according to the principle of pairwise testing. Figure 3 The schematic diagram of the scenario generation strategy corresponding to the freely combinable scenarios shown includes services A and B. Service A corresponds to parameter values ​​1, 2, and 3, and service B corresponds to parameter values ​​1 and 2. Based on the principle of pairwise testing, the keys and values ​​in the key-value pair list are combined to obtain four scenarios to be tested. In this embodiment, the freely combinable scenarios can simulate the service and parameter combinations when a user defines a scenario on the vehicle side. The freely combinable scenario generation strategy can utilize heuristic algorithms to design test scenarios according to the principle of pairwise testing. Verification has shown that for any freely combinable scenario, the heuristic algorithm can achieve over 90% scenario coverage.

[0121] In one embodiment of this application, Figure 2 After generating test cases based on the scenario to be tested in step S230, the following steps are also included:

[0122] Generate test scripts corresponding to the test cases, and combine multiple test cases and their corresponding test scripts to obtain a test project. When the test project is invoked, the test scripts are run to control the execution simulator to receive and run the test cases.

[0123] Based on the first priority information, the priorities of the parameters of the function to be tested in each test case are superimposed to obtain the superimposed priority;

[0124] The priority of each test case is determined based on the number of services in each test case and the combined priority.

[0125] If the number of services is equal to the combined priority, then the priority of the test case is set to the first priority level.

[0126] If the combined priority is greater than one times the number of services and less than or equal to two times the number of services, then the priority of the test case is set to the second priority level.

[0127] If the combined priority is greater than twice the number of services and less than or equal to three times the number of services, then the priority of the test case is set to the third priority level.

[0128] If the combined priority is greater than three times the number of services and less than or equal to four times the number of services, then the priority of the test case is set to the fourth priority level.

[0129] Based on the first priority level and / or the second priority level and / or the third priority level and / or the fourth priority level, a second priority information is obtained, which is used to determine whether to call the test project.

[0130] For example, after combining the scenario to be tested and the first priority information to obtain test cases, test scripts corresponding to the test cases are generated. Then, multiple test cases and their corresponding test scripts are combined to generate a test project. A test project can contain multiple test cases and their corresponding test scripts. It should be noted that test projects can be created, modified, and deleted as needed. Test projects support adding, deleting, modifying, and exporting test cases. Furthermore, regression test cases related to service-oriented functions can be generated based on the bugs (defects) in the previous round of testing results, and regression test projects can be generated based on the regression test cases.

[0131] For example, if the number of services is M and the combined priority is N, then when M = N, the priority of the test case is 1; when M < N ≤ 2M, the priority of the test case is 2; when 2M < N ≤ 3M, the priority of the test case is 3; and when 3M < N ≤ 4M, the priority of the test case is 4. When multiple test projects are invoked under the same computing power conditions, the priority of the test cases can be used to determine which test projects are invoked and which are not, thereby improving testing efficiency.

[0132] In one embodiment of this application, after obtaining the second priority information, the following steps are further included:

[0133] If the second priority information matches the preset test project call priority, then the test project is called and the test script is run;

[0134] If the execution simulator cannot receive the test case, or the execution simulator cannot run the test case, then the test case is determined to have a defect.

[0135] The test scenario and the first priority information are recombined to obtain new test cases and generate new test scripts.

[0136] For example, when the second priority information corresponding to a test case matches the preset test project call priority, such as when multiple test cases in a test project have priorities of 1 and / or 2, and the preset test project call priority is 1 and 2, then the test project is called. After the test project is called, the test scripts within it are run to transfer multiple test cases to the pre-configured execution simulator for execution. It should be noted that if the execution simulator cannot receive test cases or cannot run test cases, it indicates that the test script is faulty and / or the test cases have defects. The test script can be debugged to ensure that the script is correct and usable, and then the test project can be regenerated; or the scenario to be tested and the first priority information can be recombined to generate regression test cases to ensure that the test cases can run. In the above steps, by debugging the test script and generating regression test cases, it can be ensured that the predetermined test cases that need to be run can run accurately during the testing process, thereby improving the accuracy of the test.

[0137] In one embodiment of this application, after obtaining new test cases and generating new test scripts, the following steps are further included:

[0138] Run the new test script to regain control of the execution simulator, receive the new test cases, and execute tests on the vehicle-side service-oriented functions.

[0139] Based on the results of running the new test script and the results of running the new test cases in the simulator, a test log is generated.

[0140] In this embodiment, when the test project is invoked and run, the console will print the execution log of each test case in the test project in real time. When a test script or test case fails to run, the results of the failure and the bug will be logged so that testers can adjust the problem in a timely manner to ensure the normal operation of the test project. After regenerating the test script and test cases and running them, a test log is generated, and the situation of the problem can be stored in the test log for testers to review.

[0141] In one embodiment of this application, Figure 2After the pre-configured execution simulator receives the test cases and executes tests on the vehicle-side service-oriented functions in step S240, the following steps are also included:

[0142] Obtain the vehicle-side service-oriented function test results returned by the execution simulator. The vehicle-side service-oriented function test results include test case defects and defect levels, and the defect levels correspond to the second priority information.

[0143] Based on the preset correspondence between defect levels and defect rates, the defect rate of each test case in the test project is calculated, and the defect rates of each test case in the test project are added together to obtain the test project defect rate.

[0144] If the defect rate of the test item is less than the preset defect rate threshold, then the vehicle-side service function test is deemed to have passed.

[0145] If the defect rate of the test item is greater than the preset defect rate threshold, the vehicle-side service function test is determined to have failed, and test cases are regenerated based on the test case defects.

[0146] For example, after a test project is completed, the Dependency Indicator (DI) value for this test is calculated based on the bug severity. This DI value is then compared to a preset DI threshold. If the DI value is greater than the threshold, the test fails, and regression test cases are generated based on the bug list. The test is then re-executed using regression testing. If the DI value is less than the threshold, the test passes, and a test report is generated, completing the test loop. The severity of bugs in each test case is described using priorities. The bug severity corresponds to the priority of the test case; for example, a bug in a priority 1 test case has a severity of 1, and a bug in a priority 2 test case also has a severity of 2. When a bug appears in a higher-priority test case, it indicates a higher bug severity. Therefore, correlating bug severity with priority information helps determine the severity of all bugs in the current test project. A bug level of 1 is considered critical; a bug level of 2 is considered severe; a bug level of 3 is considered normal; and a bug level of 4 is considered warning.

[0147] For example, the DI value of a bug of level 1 is set to 10, the DI value of a bug of level 2 is set to 3, the DI value of a bug of level 3 is set to 1, and the DI value of a bug of level 4 is set to 0.1. Then the DI values ​​of the bugs in each test case are summed to obtain the DI value of the test item.

[0148] In one embodiment of this application, see Figure 4 , Figure 4 This is a schematic diagram of a test bench illustrating an exemplary embodiment of this application, used to support a method for testing vehicle-side service-oriented functions. In this embodiment, a test bench is constructed to test vehicle-side service-oriented functions. Figure 4 In this test bench, the main components include a PC (Personal Computer), an in-vehicle infotainment system, an MCU (Microcontroller Unit) for deploying control modules, and an execution simulator. The execution simulator can be, for example, CANoe (CAN open environment, a device for bus development), and the in-vehicle infotainment system can be, for example, an Android in-vehicle infotainment system.

[0149] The specific setup process for the test bench includes the following steps:

[0150] (1) The host computer of the automatic test system is deployed on the PC and connected to the vehicle terminal via ADB (Android Debug Bridge) cable / serial cable, connected to the MCU via serial cable, and connected to the execution simulator via serial cable.

[0151] (2) Deploy the application under test on the Android vehicle terminal and ensure that the application is enabled and connect to the MCU via Ethernet.

[0152] (3) The MCU deploys the service signal processing module and transmits the service to the execution simulator via signals.

[0153] (4) The simulator mainly simulates the transmission and reception of signals and is connected to the MCU via a local area network.

[0154] This test bench primarily ensures that the test scripts running on the PC-side automated test system trigger the execution of service-oriented functions on the Android vehicle-mounted application. The executed signals are converted into network signals such as CAN / CANFD / Link that can be received by the vehicle and transmitted to the MCU via service-oriented calls. The MCU then transmits the signals to the execution simulator, and the test script controls the execution simulator to return the execution status to the vehicle-mounted application, forming a closed loop of test bench signals.

[0155] In one embodiment of this application, see Figure 5 , Figure 5 This is a flowchart illustrating a vehicle-side service-oriented function testing method, as shown in another exemplary embodiment of this application. Figure 5 In China, through Figure 4 The test bench shown enables testing of vehicle-side service functions, specifically including the following steps:

[0156] Import vehicle application requirements information Figure 4When importing vehicle-side application requirements information into the test bench shown, it must be imported in a predetermined unified format so that the PC-side automatic testing system can recognize it.

[0157] Based on the imported vehicle application requirements information, a detailed service list and related information are identified. Then, test data and first priority information are generated based on the parameter information in the service list. Based on the functional characteristics of the service, the test scenario is distinguished as a fixed scenario or a freely combined scenario. Then, the corresponding test scenario is generated based on the nature of these two scenarios.

[0158] Combine the first priority information with the test scenario to generate test cases, and calculate the second priority information of the test cases based on the first priority information of the scenario parameters;

[0159] By debugging on the bench, it is determined whether the simulator can receive or execute test cases normally. If it fails, the test cases are regenerated.

[0160] Add successfully debugged test cases to the test project; supports adding, deleting, and modifying test projects and test cases within them.

[0161] Run the test project and generate test logs for the results of each test case in the test project. When bench failures or functional failures occur, record the bugs generated by the functional failures in the test logs. When bench failures occur, notify the testers and adjust the bench problems in a timely manner to ensure the normal execution of the test project.

[0162] After the test project is completed, the DI value of this test is calculated according to the bug level, and then compared with the set DI threshold. If it is greater than the preset DI threshold, the test is deemed to have failed, and regression test cases are generated according to the bug list. Then, the test is re-executed through the regression test project. If the DI value of the execution result is less than the preset DI threshold, the test is deemed to have passed, and a test report is generated, thus achieving the closure of the entire test.

[0163] Figure 6 This is a block diagram illustrating a vehicle-side service-oriented function testing apparatus according to an exemplary embodiment of this application. The apparatus can be applied to… Figure 1 The implementation environment shown is not limited to this embodiment. This device can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0164] like Figure 6 As shown, this exemplary vehicle-side service-oriented function testing device includes:

[0165] Data acquisition module 601 is used to acquire multiple services in the vehicle application and the corresponding function parameters to be tested for the multiple services;

[0166] The test scenario generation module 602 is used to determine the test scenario category based on the functional characteristics of the multiple services, and to combine the multiple services and test function parameters to generate the test scenario based on the test scenario category and the preset test scenario generation strategy.

[0167] The testing module 603 is used to generate test cases based on the scenario to be tested, and to control the pre-configured execution simulator to receive the test cases and execute tests on the vehicle-side service functions.

[0168] In this exemplary vehicle-side service-oriented function testing device, multiple services and parameters of the function to be tested are combined based on the functional characteristics of the vehicle-side services to obtain the test scenario. This avoids generating the same test scenario for different requirements, prevents duplication of service-oriented function testing, improves the coverage of test scenarios, and thus improves testing efficiency.

[0169] It should be noted that the vehicle-side service-oriented function testing device and the vehicle-side service-oriented function testing method provided in the above embodiments belong to the same concept. The specific operation methods of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the vehicle-side service-oriented function testing device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0170] In one embodiment of this application, see Figure 7 , Figure 7 This is a block diagram illustrating a vehicle-side service-oriented function testing apparatus, as shown in another exemplary embodiment of this application.

[0171] Figure 7 The vehicle-side service functionality testing device shown includes:

[0172] Data processing module: Obtains imported vehicle application requirements information, and obtains the parameters of the function to be tested and the first priority information based on the vehicle application requirements information.

[0173] Test scenario generation module: Generates fixed scenarios and / or freely combined scenarios based on parameters of multiple services and functions to be tested.

[0174] Test case management module: Generates test cases and test scripts based on test scenarios and first priority information, combines test cases and test scripts to generate test projects, and stores test case documents. The test case management module supports adding, modifying, and deleting test cases in test projects.

[0175] Execution module: Supports debugging of single test scripts and batch test scripts, and runs test scripts in test projects to transfer test cases to the execution simulator.

[0176] The simulator module works in conjunction with test scripts to simulate the send and receive commands of the executor and run the received test cases to perform vehicle-side service functionality testing.

[0177] Log module: Records the output results of the script debugging and runtime execution module and the execution simulator module, and supports online real-time viewing and log playback after execution.

[0178] Test report generation module: This module mainly analyzes the results after the project is executed. It determines whether the test passes or fails based on the DI threshold set by the user. If the DI value of the test project is greater than the DI threshold, the test fails and regression test cases are generated based on the bug list. If the DI value of the test project is less than the DI threshold, the test passes and a test report is automatically generated.

[0179] Understandable, Figure 7 The vehicle-side service function testing device shown is based on the same concept as the vehicle-side service function testing method provided in the above embodiments. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here.

[0180] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the electronic device to implement the vehicle-side service function testing method provided in the above embodiments.

[0181] Figure 8 A schematic diagram of a computer system suitable for an electronic device according to an embodiment of this application is shown. It should be noted that... Figure 8 The computer system 800 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0182] like Figure 8As shown, the computer system 800 includes a Central Processing Unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 802 or programs loaded from storage portion 808 into Random Access Memory (RAM) 803, such as performing the methods described in the above embodiments. The RAM 803 also stores various programs and data required for system operation. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An Input / Output (I / O) interface 805 is also connected to the bus 804.

[0183] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0184] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs various functions defined in the system of this application.

[0185] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

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

[0187] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0188] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the vehicle-side service function testing method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0189] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle-side service function testing method provided in the various embodiments described above.

[0190] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for testing vehicle-side service-oriented functions, characterized in that, The method includes: Obtain multiple services in the vehicle application and the corresponding function parameters to be tested for the multiple services; Based on the functional characteristics of the multiple services, the category of the scenario to be tested is determined, and based on the category of the scenario to be tested and the preset scenario generation strategy, the multiple services and the parameters of the function to be tested are combined to generate the scenario to be tested. Based on the scenario to be tested, test cases are generated, and a pre-configured execution simulator is controlled to receive the test cases and execute tests on the vehicle-side service functions. After obtaining multiple services in the vehicle application and the corresponding functional parameters to be tested for the multiple services, the method further includes: if the functional parameter to be tested is the minimum boundary value within a preset priority parameter range, then the priority of the functional parameter to be tested is set to a first-level priority; if the functional parameter to be tested is a boundary value other than the minimum boundary value within the priority parameter range, then the priority of the functional parameter to be tested is set to a second-level priority; if the functional parameter to be tested is within the equivalent range corresponding to the priority parameter range, then the priority of the functional parameter to be tested is set to a third-level priority; based on the first-level priority and / or the second-level priority and / or the third-level priority of the functional parameters to be tested corresponding to the multiple services, first priority information is obtained, and the first priority information is used to combine with the test scenario to obtain the test case; After generating test cases based on the scenario to be tested, the method further includes: generating test scripts corresponding to the test cases, and combining multiple test cases and their corresponding test scripts to obtain a test project. When the test project is invoked, the test scripts are run to control the execution simulator to receive and run the test cases. Based on the first priority information, the priorities of the parameters of the function to be tested in each test case are superimposed to obtain a superimposed priority. The priority of each test case is determined based on the number of services in each test case and the superimposed priority. If the number of services is equal to the superimposed priority, the priority of the test case is set to the first priority level. If the superimposed priority is not equal to the first priority level, the priority of the test case is set to the first priority level. If the priority of a test case is greater than one times the number of services but less than or equal to two times the number of services, then the priority of the test case is set to the second priority level. If the combined priority is greater than twice the number of services but less than or equal to three times the number of services, then the priority of the test case is set to the third priority level. If the combined priority is greater than three times the number of services but less than or equal to four times the number of services, then the priority of the test case is set to the fourth priority level. Based on the first priority level and / or the second priority level and / or the third priority level and / or the fourth priority level, second priority information is obtained, and the second priority information is used to determine whether to call the test project.

2. The vehicle-side service-oriented function testing method according to claim 1, characterized in that, The acquisition of multiple services in the vehicle application and the corresponding parameters of the functions to be tested includes: Obtain information on vehicle-side application requirements; The vehicle application requirement information is parsed to identify multiple services in the vehicle application and to call the service-oriented functional parameter requirement information corresponding to the multiple services. Based on the service-oriented functional parameter requirement information, the functional parameters to be tested corresponding to the multiple services are obtained.

3. The vehicle-side service-oriented function testing method according to claim 2, characterized in that, The step of obtaining the test function parameters corresponding to the multiple services based on the service-oriented function parameter requirement information includes: Based on the service-oriented functional parameter requirement information, determine the parameter type of the functional parameter to be tested for each service; If the parameter type is string, then obtain the length range of the string parameter to get the first parameter range; If the parameter type is numeric, then obtain the value range of the numeric parameter to obtain the second parameter range; The first parameter range and / or the second parameter range corresponding to the multiple services are divided into equivalence classes to obtain the valid parameter range, and the test function parameters corresponding to the multiple services are obtained according to the boundary values ​​of the valid parameter range.

4. The vehicle-side service-oriented function testing method according to claim 1, characterized in that, The step of combining the parameters of the multiple services and functions to be tested to generate a test scenario based on the test scenario category and a preset test scenario generation strategy includes: If the scene to be tested is a fixed scene, then a preset fixed combination method corresponding to the fixed scene is invoked; According to the fixed combination method, the multiple services and the corresponding functional parameters to be tested are combined to obtain the scenario to be tested.

5. The vehicle-side service-oriented function testing method according to claim 1, characterized in that, The step of combining the parameters of the multiple services and functions to be tested to generate a test scenario based on the test scenario category and a preset test scenario generation strategy includes: If the scenario to be tested is a free combination scenario, then a key-value pair list is generated based on the multiple services and the corresponding functional parameters to be tested. The key of the key-value pair list is the functional parameters to be tested corresponding to the multiple services, and the value of the key-value pair list is the multiple services. The number of rows in the key-value pair list is the same as the number of functional parameters to be tested corresponding to the multiple services. According to the preset key-value combination method, the keys and values ​​in the key-value pair list are combined to obtain the scene to be tested.

6. The vehicle-side service-oriented function testing method according to claim 1, characterized in that, After obtaining the second priority information, it also includes: If the second priority information matches the preset test project call priority, then the test project is called and the test script is run; If the execution simulator cannot receive the test case, or the execution simulator cannot run the test case, then the test case is determined to have a defect. The test scenario and the first priority information are recombined to obtain new test cases and generate new test scripts.

7. The vehicle-side service-oriented function testing method according to claim 6, characterized in that, After obtaining new test cases and generating new test scripts, the process also includes: Run the new test script to regain control of the execution simulator, receive the new test cases, and execute tests on the vehicle-side service-oriented functions. Based on the results of running the new test script and the results of running the new test cases in the simulator, a test log is generated.

8. The vehicle-side service-oriented function testing method according to claim 1, characterized in that, After the pre-configured execution simulator receives the test cases and executes tests on the vehicle-side service-oriented functions, the process also includes: Obtain the vehicle-side service-oriented function test results returned by the execution simulator. The vehicle-side service-oriented function test results include test case defects and defect levels, and the defect levels correspond to the second priority information. Based on the preset correspondence between defect levels and defect rates, the defect rate of each test case in the test project is calculated, and the defect rates of each test case in the test project are added together to obtain the test project defect rate. If the defect rate of the test item is less than the preset defect rate threshold, then the vehicle-side service function test is deemed to have passed. If the defect rate of the test item is greater than the preset defect rate threshold, the vehicle-side service function test is determined to have failed, and test cases are regenerated based on the test case defects.

9. A vehicle-side service function testing device, characterized in that, The apparatus, used in the method of any one of claims 1-8, comprises: The data acquisition module is used to acquire multiple services in the vehicle application and the corresponding functional parameters to be tested for the multiple services; The test scenario generation module is used to determine the test scenario category based on the functional characteristics of the multiple services, and to combine the multiple services and test function parameters to generate the test scenario based on the test scenario category and the preset test scenario generation strategy. The testing module is used to generate test cases based on the scenario to be tested, and to control the pre-configured execution simulator to receive the test cases and execute tests on the vehicle-side service functions.

10. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the vehicle-side service function testing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the computer's processor, causes the computer to perform the vehicle-side service function testing method as described in any one of claims 1 to 8.

Images