Method and device for testing vehicle abnormity, electronic equipment and storage medium

Abstract

The invention provides a method and device for testing vehicle abnormity, electronic equipment and a storage medium, the method is applied to the field of vehicle communication testing, and the method comprises the following steps: determining a target test data packet according to a function test demand of a target vehicle; based on the SOME / IP protocol, sending the target test data packet to the tested end, so that the tested end processes the target test data packet based on the SOME / IP protocol; according to the actual operation parameters of the tested end, determining whether the tested end has a test abnormality, the actual operation parameters being used for representing the operation state of the tested end when the tested end is tested; and terminating the test process of the tested end under the condition that the tested end is abnormal in test. According to the method, the test data packet related to the test function can be designed in a targeted manner, so that the test process is closer to the actual communication scene and the actual test requirement of the vehicle, whether the tested end is abnormal or not can be accurately detected in the test process, and the reliability and the accuracy of the test result are improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle communication testing, and more specifically, to a method, device, electronic device, and storage medium for testing vehicle abnormalities in the field of vehicle communication testing. Background Art

[0002] At present, during the driving process of a vehicle, data transmission is usually achieved between various Electronic Control Units (ECUs) in the vehicle using the Scalable Service-Oriented Middleware over Internet Protocol (SOME / IP) protocol.

[0003] To ensure the correctness of information transmission and the stable and normal operation of each ECU during communication between ECUs based on the SOME / IP protocol, technicians generally conduct pre-tests to detect and verify the SOME / IP protocol communication as much as possible. This allows them to detect anomalies in the SOME / IP communication process in advance, such as crashes, memory leaks, or deadlocks.

[0004] The testing method used in related technologies is fuzz testing. The disadvantage of this testing method is that it cannot well meet the actual testing needs of the vehicle, and it is difficult to discover abnormal problems in SOMP / IP protocol communication during the testing process. Summary of the Invention

[0005] The present application provides a method, device, electronic device and storage medium for testing vehicle abnormalities. The method can specifically design test data packets related to the test function, so that the test process is closer to the actual communication scenario and actual test requirements of the vehicle, thereby accurately detecting whether the tested end is abnormal during the test process, and improving the reliability and accuracy of the test results.

[0006] In a first aspect, a method for testing vehicle abnormalities is provided, the method comprising: determining a target test data packet based on functional test requirements of a target vehicle; sending the target test data packet to a tested terminal based on the SOME / IP protocol, so that the tested terminal processes the target test data packet based on the SOME / IP protocol; determining whether a test abnormality occurs at the tested terminal based on actual operating parameters of the tested terminal, the actual operating parameters being used to represent the operating status of the tested terminal when being tested; and terminating the test process of the tested terminal if the test abnormality occurs at the tested terminal.

[0007] In the above technical solution, a method for testing vehicle abnormalities is provided, and the specific implementation process of the method is: when testing the vehicle ECU, first determine the target test data packet according to the functional test requirements, and then send the target test data packet to the tested end based on the SOME / IP protocol. When the tested end processes the target test data packet, it can be determined whether the tested end has an abnormality based on the actual operating parameters of the tested end and terminate the test when an abnormality occurs. The above-mentioned targeted determination of relevant target test data packets based on the test function requirements can make the test process closer to the actual communication scenario of the vehicle and more in line with current test requirements, so that during the test process, it can accurately detect whether the tested end has an abnormality, thereby improving the reliability and accuracy of the test results. When an abnormality is found, terminating the test can obtain the abnormal situation in the first time, which is convenient for accurate handling of the abnormal situation.

[0008] In combination with the first aspect, in some possible implementations, the method also includes: obtaining the initial operating parameters of the tested end before sending the target test data packet; and determining whether a test abnormality occurs at the tested end based on the actual operating parameters of the tested end, including: determining whether a test abnormality occurs at the tested end based on the initial operating parameters and the actual operating parameters.

[0009] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the test exception includes a crash exception, the initial operating parameters include an initial process identifier, and the actual operating parameters include an actual process identifier. Determining whether a test exception occurs on the tested end based on the initial operating parameters and the actual operating parameters includes: determining whether the initial process identifier is consistent with the actual process identifier; when the initial process identifier is consistent with the actual process identifier, determining that the crash exception does not occur on the tested end; when the initial process identifier is inconsistent with the actual process identifier, determining that the crash exception occurs on the tested end.

[0010] In the above technical solution, when determining whether the tested end has experienced a crash anomaly during the test, the initial process ID is compared with the actual process ID. This method does not require complex and in-depth parameter analysis, thereby improving the efficiency of crash detection through this simple and efficient method. In addition, due to the uniqueness of process IDs, by comparing process IDs before and after the test, process anomalies can be promptly and accurately detected, accurately locating whether the tested end has experienced a crash anomaly, and improving the reliability and stability of anomaly detection.

[0011] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the test abnormality includes a memory leak abnormality, the initial operating parameters include an initial memory occupancy, and the actual operating parameters include an actual memory occupancy. The determination of whether the test abnormality occurs on the tested end based on the initial operating parameters and the actual operating parameters includes: based on the target test data packet, repeatedly testing the test end, and obtaining N first test times of the target test data packet, where N is a positive integer greater than 1; when N is greater than or equal to the first preset number, for any first test number among the N first test times, determining the memory occupancy change corresponding to the first test number based on the target actual memory occupancy and the target initial memory occupancy corresponding to the first test number; performing linear fitting on the N memory occupancy changes corresponding to the N first test times to determine the memory occupancy change trend of the tested end; when the memory occupancy change trend is an upward trend, determining that the memory leak abnormality occurs on the tested end; when the memory occupancy change trend is not the upward trend, determining that the memory leak abnormality does not occur on the tested end.

[0012] In the above technical solution, repeated testing of the test end based on the target test data packet can avoid the errors and occasional interference caused by single test results, thereby improving the accuracy of the test results. During the repeated testing process, by obtaining N memory usage changes corresponding to N first test times and performing a linear fit on them, it is possible to comprehensively analyze the changing trend of memory usage as the number of tests increases. The linear fit can also eliminate short-term fluctuations in the data, more accurately identify the changing trend of memory usage, and improve the accuracy of memory leak judgment.

[0013] In combination with the first aspect and the above-mentioned implementation method, in some possible implementation methods, the test abnormality includes a processing performance degradation abnormality, the initial operating parameter includes an initial CPU occupancy, and the actual operating parameter includes an actual CPU occupancy. The determination of whether a test abnormality occurs on the tested end based on the initial operating parameter and the actual operating parameter includes: based on the target test data packet, repeatedly testing the test end, and obtaining M second test times and cumulative test duration of the target test data packet, where M is a positive integer greater than 1; when M is greater than or equal to the second preset number of times, and the cumulative test duration is greater than or equal to the preset duration Next, for any second test number of the M second test times, determine the CPU occupancy change corresponding to the second test number based on the target initial CPU occupancy and the target actual CPU occupancy corresponding to the second test number; perform linear fitting on the M CPU occupancy change corresponding to the M second test times to determine the CPU occupancy change trend of the tested end; when the CPU occupancy change trend is an upward trend, determine that the tested end has the processing performance degradation abnormality; when the CPU occupancy change trend is not the upward trend, determine that the tested end has not the processing performance degradation abnormality.

[0014] In the above technical solution, repeated testing of the test end based on the target test data packet can avoid the errors and occasional interference caused by single test results, thereby improving the accuracy of the test results. During the repeated testing process, by obtaining M CPU usage changes corresponding to M second test times and performing a linear fit on them, it is possible to comprehensively analyze the changing trend of CPU usage as the number of tests increases. The linear fit can also eliminate short-term fluctuations in the data, more accurately identify the changing trend of CPU usage, and improve the accuracy of determining whether the CPU processing performance has declined.

[0015] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the test exception includes a no-response exception, the initial operating parameters include the initial activity time, and the actual operating parameters include the actual activity time and the response status of the tested end. The determination of whether the test exception occurs on the tested end based on the initial operating parameters and the actual operating parameters includes: determining whether the actual activity time is consistent with the initial activity time, and determining whether the response status of the tested end is an application no-response state; when the actual activity time is consistent with the initial activity time, or the response status of the tested end is an application no-response state, determining that the tested end has the no-response exception; when the actual activity time is inconsistent with the initial activity time, and the response status of the tested end is not an application no-response state, determining that the tested end has not the no-response exception.

[0016] In the above technical solution, when determining whether an unresponsiveness exception occurs on the tested end, the actual activity time and the initial activity time are comprehensively considered, as well as whether the tested end is in an unresponsive state of the application. Through this multi-dimensional judgment method, it is possible to more accurately detect whether an unresponsiveness exception occurs on the tested end, avoid the judgment loopholes caused by a single judgment method, and enhance the card type and accuracy of the judgment result.

[0017] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the target test data packet is determined according to the functional test requirements of the target vehicle, including: determining the type of the target test data packet according to the functional test requirements of the target vehicle, the type of the target test data packet is used to indicate how the tested end processes the target test data packet; determining the target preset data packet construction rule corresponding to the functional test requirement from multiple preset data packet construction rules corresponding to the type of the target test data packet according to the functional test requirement; determining the target test data packet according to the functional test requirement and the target preset data packet construction rule.

[0018] In the above technical solution, when determining the target test data packet, the type of the target test data packet is determined according to the functional test requirements of the target vehicle, so that the specific test business for the tested end can be clarified. Further, according to the functional test requirements, the target preset data packet construction rules corresponding to the functional test requirements are determined from the multiple preset data packet construction rules corresponding to the type of the target test data packet. In this process, the test end flexibly selects the corresponding data packet construction rules according to the test scenario, which can improve the flexibility of the test and enable the test of this application to better adapt to various test scenarios and demand changes. Finally, according to the functional test requirements and the construction rules of the target preset data packet, the target test data packet is determined, which can ensure that the target test data packet not only meets the functional test requirements, but also complies with the corresponding construction rules, thereby ensuring the accuracy and reliability of the test.

[0019] In a second aspect, a device for testing vehicle abnormalities is provided, which includes: a data packet determination module, which is used to determine a target test data packet according to the functional test requirements of the target vehicle; a data packet sending module, which is used to send the target test data packet to the tested end based on the SOME / IP protocol, so that the tested end processes the target test data packet based on the SOME / IP protocol; an abnormality detection module, which is used to determine whether a test abnormality occurs at the tested end based on actual operating parameters of the tested end, and the actual operating parameters are used to indicate the operating status of the tested end when being tested; and a test termination module, which is used to terminate the test process of the tested end if the test abnormality occurs at the tested end.

[0020] In combination with the second aspect, in some possible implementations, the anomaly detection module is specifically used to: obtain the initial operating parameters of the tested end before sending the target test data packet; and determine whether a test anomaly occurs at the tested end based on the initial operating parameters and the actual operating parameters.

[0021] In combination with the second aspect and the above-mentioned implementation methods, in some possible implementation methods, the test exception includes a crash exception, the initial operating parameters include an initial process identifier, and the actual operating parameters include an actual process identifier. The exception detection module is also used to: determine whether the initial process identifier is consistent with the actual process identifier; when the initial process identifier is consistent with the actual process identifier, determine that the crash exception does not occur on the tested end; when the initial process identifier is inconsistent with the actual process identifier, determine that the crash exception occurs on the tested end.

[0022] In combination with the second aspect and the above-mentioned implementation methods, in some possible implementation methods, the test abnormality includes a memory leak abnormality, the initial operating parameters include an initial memory occupancy, and the actual operating parameters include an actual memory occupancy. The abnormality detection module is also used to: based on the target test data packet, repeatedly test the test end and obtain N first test times of the target test data packet, where N is a positive integer greater than 1; when N is greater than or equal to the first preset number, for any first test number of the N first test times, determine the memory occupancy change corresponding to the first test number based on the target actual memory occupancy and the target initial memory occupancy corresponding to the first test number; perform linear fitting on the N memory occupancy changes corresponding to the N first test times to determine the memory occupancy change trend of the tested end; when the memory occupancy change trend is an upward trend, determine that the tested end has the memory leak abnormality; when the memory occupancy change trend is not the upward trend, determine that the tested end has not the memory leak abnormality.

[0023] In combination with the second aspect and the above-mentioned implementation method, in some possible implementation methods, the test abnormality includes a processing performance degradation abnormality, the initial operating parameters include an initial CPU occupancy, and the actual operating parameters include an actual CPU occupancy. The abnormality detection module is also used to: based on the target test data packet, repeatedly test the test end, and obtain M second test times and cumulative test duration of the target test data packet, where M is a positive integer greater than 1; when M is greater than or equal to the second preset number, and the cumulative test duration is greater than or equal to the preset duration, for any second test number of the M second test times, determine the CPU occupancy change corresponding to the second test number based on the target initial CPU occupancy and the target actual CPU occupancy corresponding to the second test number; perform linear fitting on the M CPU occupancy changes corresponding to the M second test times to determine the CPU occupancy change trend of the tested end; when the CPU occupancy change trend is an upward trend, determine that the tested end has the processing performance degradation abnormality; when the CPU occupancy change trend is not the upward trend, determine that the tested end has not the processing performance degradation abnormality.

[0024] In combination with the second aspect and the above-mentioned implementation methods, in some possible implementation methods, the test exception includes a no-response exception, the initial operating parameters include the initial activity time, the actual operating parameters include the actual activity time and the response status of the tested end, and the exception detection module is also used to: determine whether the actual activity time is consistent with the initial activity time, and determine whether the response status of the tested end is an application no-response state; when the actual activity time is consistent with the initial activity time, or the response status of the tested end is an application no-response state, determine that the tested end has the no-response exception; when the actual activity time is inconsistent with the initial activity time, and the response status of the tested end is not an application no-response state, determine that the tested end does not have the no-response exception.

[0025] In combination with the second aspect and the above-mentioned implementation methods, in some possible implementation methods, the data packet determination module is specifically used to: determine the type of the target test data packet according to the functional test requirements of the target vehicle, and the type of the target test data packet is used to indicate how the tested end processes the target test data packet; according to the functional test requirements, determine the target preset data packet construction rule corresponding to the functional test requirements from multiple preset data packet construction rules corresponding to the type of the target test data packet; determine the target test data packet according to the functional test requirements and the target preset data packet construction rule.

[0026] In a third aspect, an electronic device is provided, comprising a memory and a processor. The memory is configured to store executable program code, and the processor is configured to retrieve and execute the executable program code from the memory, so that the electronic device executes the method of the first aspect or any possible implementation of the first aspect.

[0027] In a fourth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method in the first aspect or any possible implementation of the first aspect.

[0028] In a fifth aspect, a computer-readable storage medium is provided, which stores a computer program code. When the computer program code runs on a computer, the computer executes the method in the above-mentioned first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is an interactive flow chart of SOME / IP protocol communication provided by an embodiment of the present application;

[0030] Figure 2 This is a schematic diagram of a communication scenario between vehicle ECUs provided in an embodiment of the present application;

[0031] Figure 3 This is a schematic diagram of the structure of a test terminal provided in an embodiment of the present application;

[0032] Figure 4 is a schematic flow chart of a method for testing vehicle abnormalities provided in an embodiment of the present application;

[0033] Figure 5 This is a schematic flow chart of a method for determining whether an abnormality occurs at a tested terminal, provided in an embodiment of the present application;

[0034] Figure 6 is a schematic flow chart of another method for testing vehicle abnormalities provided by an embodiment of the present application;

[0035] Figure 7 1 is a schematic structural diagram of a device for testing vehicle abnormalities provided in an embodiment of the present application;

[0036] Figure 8 This is a schematic diagram of the structure of an electronic device at a test end provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] The following will clearly and thoroughly describe the technical solutions in this application in conjunction with the accompanying drawings. In the description of the embodiments of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more than two.

[0038] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0039] Before introducing the method of the embodiment of the present application, the following is a glossary of professional terms that may be involved in the embodiment of the present application.

[0040] SOME / IP: A service-oriented middleware protocol for communication between different ECUs in a vehicle. Part of the AUTOSAR Adaptive Platform, SOME / IP provides a standardized, service-oriented communication mechanism for vehicle ECUs based on IP. This allows different ECUs to interact as services to implement various vehicle functions.

[0041] Test target: refers to the object that needs to be tested and verified during the SOME / IP communication protocol testing process, usually referring to the ECU or related equipment and systems that communicate based on the SOME / IP protocol.

[0042] Test software: refers to the tools or programs used to test the SOME / IP communication protocol. It is mainly used to simulate the behavior of SOME / IP as a client or server in the protocol, send various test messages, monitor and analyze the data interaction during the communication process, and verify whether the test target meets the specifications and functional requirements of the SOME / IP protocol.

[0043] During testing, the test target can be either a client or a server. When the test target is a client, the test software corresponds to the server; when the test target is a server, the test software corresponds to the client. The client is used to request services, and the server is used to provide services.

[0044] In one scenario, when the test target is a client, the test software, acting as a server, proactively initiates the service. This process is called "Offer Service" on the server side. The test target is responsible for finding the services provided by each ECU server in the vehicle. This process is called "Find Service" on the client side, where the client discovers the available services provided by the server. After receiving the Find Service request from the client, the server responds with an "Offer Service" response, and the test target then subscribes to the service.

[0045] In another scenario, when the test target is a server, the test software acts as a client and first discovers the service (FindService). The test software is then responsible for providing the service (OfferService). Since service subscription is typically initiated by the client, it primarily allows the client to obtain specific data updates or notifications from the server. The server's primary responsibility is to provide services, process client requests, and manage resources. The server itself is the source and sender of data. Therefore, when the test target is a server, the server does not need to actively subscribe to the services of other components.

[0046] Fuzz Testing: An automated software testing method that uses random data generation or mutation techniques to inject a large number of seemingly meaningless or abnormal inputs into the system under test to discover vulnerabilities, defects, or abnormal behaviors in the system under test.

[0047] A memory leak occurs when a program, after requesting dynamic memory, fails to release the allocated memory space, preventing it from being reclaimed by the system. Common manifestations of a memory leak include: programs running on the system increasingly occupying more memory, while available memory decreases. As memory leaks worsen, programs run more slowly and response times increase.

[0048] A crash occurs when a program suddenly stops running due to a serious error or resource exhaustion. Common symptoms of a crash include the application interface disappearing or an error dialog box popping up.

[0049] Decreased central processing unit (CPU) performance refers to a decrease in the CPU's ability to process tasks per unit time, making it unable to efficiently execute instructions, calculations, and other operations as normally. Common manifestations of this decline include noticeably slower user experiences such as opening applications, switching windows, and executing commands, requiring extended wait times.

[0050] Unresponsiveness: This refers to a period of time when a program fails to respond to user actions or external events as expected, resulting in a stagnant state. Common manifestations of unresponsiveness include: no feedback from the program interface, regardless of user actions, and prolonged periods of inactivity.

[0051] Deadlock occurs when two or more threads (or processes) compete for resources (e.g., hardware devices, memory areas, etc.) during execution, causing them to wait for each other. Without external intervention, these processes cannot continue. Common symptoms of deadlock include: the related processes being blocked and unable to move forward, and CPU usage may be low or unchanged.

[0052] It should be understood that the embodiment of the present application is applied to the scenario where two ECUs in a vehicle communicate via the SOME / IP protocol. Figure 1 This paper introduces the communication principle of SOME / IP protocol.

[0053] Figure 1 This is an interactive flow chart of SOME / IP protocol communication provided in an embodiment of the present application.

[0054] For example, Figure 1 As shown in the figure, when two ECUs in a vehicle communicate, the roles they play vary depending on the business needs. The client can be understood as the ECU that needs to obtain data, and the server can be understood as the ECU that needs to send or provide data. The communication process between the two ECUs using the SOME / IP protocol is as follows:

[0055] After the server prepares the relevant service functions, it will actively send an Offer Service message to inform other ECUs in the vehicle that the service has been started and a connection can be established. That is, the server notifies the outside world that the service it provides is ready and can be used.

[0056] When a client needs a service, it can send a Find Service message to proactively search for the service. If the service is ready, the server receives the Find Service message from the client and sends an Offer Service message via the User Datagram Protocol (UDP) to inform the client of the service's availability and related information.

[0057] After receiving the Offer Service, the client can subscribe to the relevant event by sending a Subscribe Event Group. The server verifies whether the client meets the event subscription conditions and responds with an Acknowledge character (ACK) if the conditions are met. The server then publishes the event to the subscribed client according to the event attributes.

[0058] After introducing how ECUs communicate based on the SOME / IP protocol, Figure 2 The application scenarios of the embodiments of the present application are introduced.

[0059] Figure 2 This is a schematic diagram of a scenario of communication between vehicle ECUs provided in an embodiment of the present application.

[0060] For example, Figure 2 As shown, ECU 202 and ECU 203 are any two ECUs in vehicle 201. During the operation of vehicle 201, ECU 202 and ECU 203 can communicate with each other via the SOME / IP protocol to achieve data transmission between the ECUs.

[0061] In some scenarios, ECU 202 may be the engine management system (EMS) in vehicle 201, and ECU 203 may be the in-vehicle infotainment system control unit in vehicle 201. ECU 202 is responsible for managing various engine operating parameters, such as fuel injection rate, ignition timing, and engine speed; ECU 203 is responsible for functions such as playing music, providing navigation, and displaying vehicle 201 operating data. While vehicle 201 is operating, ECU 202 needs to transmit the engine speed to ECU 203, which then displays it on the instrument panel or for use by other vehicle functions.

[0062] In the above scenario, ECU 202 plays the role of a server, responsible for providing the engine speed, while ECU 203 plays the role of a client, responsible for obtaining the engine speed.

[0063] The following specifically describes the detailed process of how to implement engine speed transmission between ECU 202 and ECU 203 based on the SOME / IP protocol.

[0064] The first stage is to provide services.

[0065] ECU202, as the server providing the engine speed service, first offers the service in the form of broadcast through the service discovery (SD) mechanism in the SOME / IP protocol, indicating to other ECUs in the vehicle 201 that it can provide various services such as engine speed, and attaches relevant information of each service, such as the service identity document (Service ID or service ID) and instance ID.

[0066] The Service ID is used to identify a specific type of service in the vehicle 201. In the vehicle 201, different ECUs correspond to different types of services, and each service has a unique service ID.

[0067] The instance ID is used to distinguish different instances of the same type of service. When there are multiple entities providing the same type of service in the vehicle 201, each entity's corresponding service instance will have a unique instance ID.

[0068] The second stage is service discovery.

[0069] ECU 203, as the client that needs to obtain engine speed, broadcasts a Find Service request via the SOME / IP protocol to search for available engine speed services in vehicle 201. When ECU 203 receives the OfferService response from ECU 202, it can determine that it can obtain engine speed from ECU 202.

[0070] The third stage is service subscription.

[0071] ECU 203, based on its needs, sends a subscription request to ECU 202 to subscribe to engine speed data update events. When ECU 202 detects a change in engine speed, it encapsulates the changed engine speed in a message format specified by the SOME / IP protocol and sends it to ECU 203, which has subscribed to the service, via the in-vehicle communication network bus (e.g., the Controller Area Network (CAN) bus).

[0072] After receiving the message, ECU203 can parse the message content, obtain the engine speed, and process the engine speed according to its own functional requirements, such as displaying the engine speed on the instrument panel.

[0073] From the above examples, it can be seen that the SOME / IP protocol plays a vital role in the communication between ECUs of the vehicle 201 .

[0074] During the actual operation of the vehicle 201, due to various factors, the ECUs communicating based on the SOME / IP protocol may experience unexpected anomalies, such as crashes, memory leaks, CPU processing performance degradation, or ECU unresponsiveness.

[0075] To avoid the above problems, technicians generally conduct preliminary tests to simulate the above-mentioned anomalies in the communication process as much as possible to discover various potential problems when ECUs communicate based on the SOME / IP protocol, so as to ensure the stability and safety of the actual vehicle operation.

[0076] The commonly used testing method in related technologies is the general fuzz testing method. However, this method does not meet actual testing requirements during the testing process, making it difficult to detect abnormal problems in the SOME / IP protocol communication process. The reasons are as follows:

[0077] First, general fuzz testing involves inputting large amounts of invalid, unexpected, or random data into the tested end (i.e., the test target) to detect abnormal issues such as crashes or memory leaks. However, problems such as crashes, memory leaks, or deadlocks in SOME / IP protocol communications may stem from complex internal logical interactions and flaws in resource management mechanisms. For example, memory leaks are caused by the long-term accumulation of allocated memory that is not properly released by the program. General fuzz testing uses random input data, making it difficult to accurately detect vulnerabilities in memory allocation and release logic. Deadlocks are mostly caused by resource competition among multiple threads or processes and unreasonable locking and unlocking sequences. General fuzz testing finds it difficult to simulate the specific resource competition timing and conditions that can trigger deadlocks.

[0078] Secondly, the SOME / IP protocol has defined rules for communication specifications and data communication formats. General fuzz testing lacks a deep understanding of the protocol specifications and only performs broad data perturbations. As a result, it is difficult to discover logical issues hidden in the correct protocol flow.

[0079] Furthermore, general fuzz testing focuses on inputting anomalous results to observe output, but lacks continuous monitoring of the internal state and resource usage of the tested endpoint during runtime. For example, memory leaks require monitoring memory allocation and release processes, as well as resource usage trends, to be detected. Another example is deadlocks, which are difficult to detect based solely on external input and output when they haven't actually been triggered.

[0080] Finally, SOME / IP protocol communication in vehicle networks corresponds to specific business logic and operational scenarios. General-purpose fuzz testing fails to closely integrate these real-world scenarios and build test cases that closely resemble real-world operational scenarios, making it difficult to detect anomalies caused by specific scenarios.

[0081] Based on the above problems, an embodiment of the present application provides a method for testing vehicle abnormalities. This method can specifically design test data packets related to the test functions, so that the test process is closer to the vehicle's actual communication scenarios and actual test requirements, thereby accurately detecting whether the tested end is abnormal during the test process, and improving the reliability and accuracy of the test results.

[0082] It should be understood that this method is specifically applied to the test end, that is, the test software. The test end can be some ECU in the vehicle with test functions, or it can be an external test device installed with professional test software. The external test device has the function of simulating various SOME / IP protocol messages, so that it can send test data to the tested end. Optionally, the professional test software is such as the controller area network (CAN) open environment (oe) or VT System. The external test device is such as a computer, desktop computer or other electronic device.

[0083] Before introducing the method of the embodiment of the present application, the architecture and working principle of the test end when implementing the method are first introduced.

[0084] Figure 3 This is a structural diagram of a test terminal provided in an embodiment of the present application.

[0085] For example, Figure 3 As shown, when implementing the method of the embodiment of the present application, the test terminal 300 can be divided into a protocol acquisition module 301, a protocol parsing module 302, a test preprocessing module 303, a message processing module 304, and a message construction module 305 according to different functional modules. The functions of each module are as follows:

[0086] The protocol acquisition module 301 is used to obtain the SOME / IP protocol data in the vehicle. Specifically, the protocol acquisition module 301 can read the communication protocol information of each vehicle ECU according to the SOME / IP protocol specification. Alternatively, during the vehicle development and testing process, the protocol acquisition module 301 can reference test data and documentation on protocol interactions between various ECUs to obtain the vehicle's SOME / IP protocol data.

[0087] Optionally, depending on the test requirements, the protocol acquisition module 301 may only acquire the SOME / IP protocol data corresponding to the data interaction between the two ECUs corresponding to the current test requirements. Alternatively, the protocol acquisition module 301 may directly acquire the protocol data for the interaction between all ECUs in the vehicle.

[0088] After the protocol acquisition module 301 acquires the SOME / IP protocol data, it may send the SOME / IP protocol data to the protocol analysis module 302 .

[0089] After receiving the SOME / IP protocol data, the protocol parsing module 302 performs two steps. The first step is that the protocol parsing module 302 parses the SOME / IP protocol data to obtain the service ID, method ID, message type, and message data contained in the protocol data.

[0090] In the SOME / IP protocol, different service functions are distinguished by unique service IDs. For example, a service that controls window lifts and a service that controls seat heating each have a corresponding service ID. When parsing protocol data, protocol parsing module 302 can extract the service ID from the protocol data and identify the specific service ID to clearly identify the service to which the current service ID corresponds.

[0091] A method ID may correspond to multiple operating modes or sub-functions within a service. These different operating modes or sub-functions are specifically distinguished by the method ID. For example, in a window lift service, multiple operating modes correspond to operations such as raise, lower, and stop. These different operations correspond to different method IDs. By parsing the protocol data, the protocol parsing module 302 can determine the specific sub-function corresponding to the current protocol data.

[0092] The message type is used to indicate how the message is processed. Optionally, the message type includes the following: REQUEST, NOTIFICATION, RESPONSE, and REQUEST_NO_RETURN.

[0093] Message data refers to the actual valid content carried in the message. For example, in a window lift service, the message data may include the specific position value of the window to be raised or lowered.

[0094] Secondly, different protocol contents correspond to their own data units, which are used to represent the specific form of the protocol contents. Figure 3 As shown in Figure 1, the service ID unit corresponds to the service ID in the protocol content and is used to clarify the specific form of the service ID during actual data transmission. It specifies the position of the service ID in the data frame, the number of bytes occupied, and the encoding method.

[0095] The method ID unit corresponds to the method ID and is used to clarify the specific form of the method ID during actual data transmission, including the value range of the method ID, the position in the data frame, the number of bytes occupied, etc.

[0096] The message type corresponds to the message type unit and is used to specify how the message type is represented at the data level. In some possible scenarios, for example, 0x00 can be used to represent the message type - REQUSET, and 0x02 can be used to represent the message type - NOTIFICATION.

[0097] The message data corresponds to the data type unit and the data length unit. The data type unit specifies the data type of the message data, such as integer or character, etc. The data length unit specifies the length or number of bytes of the message data.

[0098] The test preprocessing module 303 is used to determine the roles played by the test target and the test software in the SOME / IP protocol communication process based on the test requirements. Specifically, if the test target is the client, the test software is the server. Conversely, if the test target is the server, the test software is the client.

[0099] Depending on the devices corresponding to the test objectives and test software, the device acting as the server is responsible for providing services for the client to find and subscribe to. The device acting as the client is responsible for actively finding services and waiting for the server to provide services, so as to complete the communication preparation work before the test and build the basic interactive environment for the test.

[0100] It should be understood that, as previously described, when ECUs interact based on the SOME / IP protocol, the corresponding message types include, but are not limited to, notification, request, response, or request without response. Different message types correspond to different processing terminals.

[0101] Specifically, clients are responsible for handling Request and Request without Response messages. To obtain services, perform operations, and so on, clients send Request or Request without Response messages to servers. For example, if a client wants to query a vehicle's fuel consumption data, it would send a REQUEST message to the server (ECU) providing the fuel consumption data service.

[0102] Notifications and responses are handled by the server. When data is updated or a new event occurs, the server proactively sends a notification message to clients that have subscribed to the relevant notifications. For example, if a vehicle's engine malfunctions, the engine server will send a notification message to clients that have subscribed to the notification.

[0103] In addition, after receiving the client request, the server processes the request and returns a response message. For example, if the client requests to obtain the vehicle speed, the server will process it and return a RESPONSE containing the vehicle speed.

[0104] During the test process, since the test data packet or test message is sent from the test end 300 to the tested end, when the test end 300 is a server, the message type to be constructed by the test end 300 can be a notification type or a response type. When the test end 300 is a client, the message type to be constructed by the test end 300 can be a request type or a request without response type.

[0105] In actual testing, the test message type may be any of NOTIFICATION, REQUEST, RESPONSE, and REQUEST_NO_RETURN, depending on the test requirements. Depending on whether the test end 300 is a client or a server, the message processing module 304 defines the message types that the test end 304 can handle as different roles.

[0106] The message construction module 305 defines the test data construction rules during the test process. These rules are formulated based on the parsed protocol content. These rules specify the various components of the test data, such as the service ID, method ID, data length, and data type. Data types include enumeration types and byte types.

[0107] During the test process, after the test end 300 determines the message type and role, it can call the message construction rules in the message construction module 305 through the message processing module 304, construct a test data packet and send it to the tested end based on the SOME / IP protocol to check whether any abnormalities occur in the tested end during the processing of the test data packet.

[0108] After introducing the structure and working principle of the test terminal, Figure 4 A method for testing vehicle abnormalities provided in an embodiment of the present application is introduced in detail.

[0109] Figure 4 It is a schematic flowchart of a method for testing vehicle abnormalities provided in an embodiment of the present application.

[0110] For example, Figure 4 As shown, the method 400 includes the following steps 401 to 404.

[0111] 401, determine a target test data package according to a functional test requirement of a target vehicle.

[0112] As mentioned earlier, the tester can be either a client or a server. Correspondingly, the tested end can be either a client or a server. During the testing process, technicians can determine the role of the tester based on the current functional testing requirements of the target vehicle. Functional testing requirements refer to the conditions that must be met when testing a specific functional feature in the target vehicle. These conditions specifically include the ECU that corresponds to the function and the data that the ECU receives when implementing the function.

[0113] Among them, the tested end is the ECU in the vehicle, and the testing end can be the ECU or an external testing device installed with professional testing software. The external testing device can simulate the working behavior of the ECU and thus send test data packets to the ECU of the tested end.

[0114] After clarifying the functional test requirements, the test end can determine or construct the target test data packet to be sent to the tested end based on the functional test requirements. Figure 3 It can be seen that when determining the target test data packet, the construction rules of the target test data packet need to be met.

[0115] For example, a functional test requirement might be to test whether the tested device can accurately respond within a specified timeframe when requesting the vehicle's current navigation route information. In this case, the target test packet type should be REQUEST, and the method ID should be the Get Navigation Route Information method.

[0116] Therefore, when constructing the target test data packet of the current test, it is necessary to combine the message type of the current test and the construction rules of the data packet under this type.

[0117] In one possible implementation, determining a target test data package based on functional test requirements of a target vehicle includes:

[0118] Determine the type of the target test data packet based on the functional test requirements of the target vehicle. The type of the target test data packet indicates how the tested end processes the target test data packet.

[0119] According to the functional test requirements, determining a target preset data packet construction rule corresponding to the functional test requirements from a plurality of preset data packet construction rules corresponding to the type of the target test data packet;

[0120] Determine the target test data package based on the functional test requirements and target preset data package construction rules.

[0121] Specifically, when determining the type of the target test data packet, the test end may automatically determine the type of the target test data packet, or manually determine the type of the target test data packet.

[0122] In one case, after the technician determines the current functional test requirements, he can input the functional test requirements into the relevant interface of the test end. The test end obtains the current functional test requirements and the different test scenarios and data packet types corresponding to different test scenarios pre-stored on the test end to determine the type of target test data packet corresponding to the current functional test requirements.

[0123] In another case, after the technician determines the current functional test requirement, he or she can manually determine the type of target test data packet corresponding to the functional test requirement and select the type of target test data packet on the test interface of the test terminal.

[0124] Optionally, the types of data packets provided in the embodiments of the present application include but are not limited to the aforementioned request type, response type, notification type, and request but no response type.

[0125] In the embodiment of the present application, according to different functional testing requirements, the construction rules of different types of test data packets during the testing process are also different.

[0126] Exemplarily, when the type of the target test data packet is a notification type, the embodiment of the present application provides the following test data packet construction rules.

[0127] (1) Undefined notification service ID + defined notification method ID + defined length + general data;

[0128] (2) Defined notification service ID + undefined notification method ID + defined length + general data;

[0129] (3) Defined notification service ID + defined notification method ID + 0 length + general data;

[0130] (4) Defined notification service ID + defined notification method ID + length exceeding definition + general data;

[0131] (5) Defined notification service ID + defined notification method ID + defined length + fuzzy test data.

[0132] When the type of the target test data packet is a request type or a response type, the embodiment of the present application provides the following test data packet construction rules.

[0133] (1) Undefined request service ID + defined request method ID + defined length + general data;

[0134] (2) Defined request service ID + undefined request method ID + defined length + general data;

[0135] (3) Defined request service ID + defined request method ID + 0 length + general data;

[0136] (4) Defined request service ID + defined request method ID + exceeding defined length + regular data;

[0137] (5) Defined request service ID + defined request method ID + defined length + fuzzy test data.

[0138] Since messages of the request but no response type are usually not processed, no message construction rules are set in the embodiment of the present application.

[0139] It should be understood that the service ID corresponding to the response type message is the same as the service ID corresponding to the request type message, and the method ID corresponding to the response type message is the same as the method ID corresponding to the request type message. This is done to ensure a close correlation between the response and the request.

[0140] For example, consider the notification type as a message type. A defined notification service ID refers to a service ID for a notification type that is explicitly specified in the SOME / IP protocol specification. An undefined notification service ID refers to a service ID for a notification type that is not explicitly specified in the SOME / IP protocol specification. Similarly, a defined notification method ID refers to a method ID for a sub-function or operation of a notification type that is explicitly specified in the SOME / IP protocol specification. An undefined notification method ID refers to a method ID for a sub-function or operation of a notification type that is not explicitly specified in the SOME / IP protocol specification.

[0141] It should be understood that in the embodiment of the present application, what is sent to the tested end during the test process is mainly abnormal data, the purpose of which is to detect whether the tested end will experience problems such as crash, no response or memory leak when processing abnormal messages. During the test process, according to different functional test requirements, the above-mentioned different message construction rules also have different test purposes, which are mainly used to test the protocol stack layer and business layer of the tested end. The protocol stack layer is mainly responsible for processing functions related to the network communication protocol, such as the reception, parsing and routing of messages. The business layer is mainly responsible for implementing specific business logic and functions, and performing corresponding operations based on the received messages.

[0142] For any of the notification, response, or request types, the following build rules: Undefined service ID + defined method ID + defined length + regular data; Defined service ID + defined method ID + 0 length + regular data; and Defined service ID + defined method ID + more than defined length + regular data are intended for testing the protocol stack layer of the tested end. The following build rules: Defined service ID + undefined method ID + defined length + regular data; and Defined service ID + defined method ID + defined length + fuzzy test data are intended for testing the business layer of the tested end.

[0143] Specifically, the combination of an undefined service ID, a defined method ID, a defined length, and regular data tests the protocol stack's ability to handle unknown service IDs. The protocol stack must identify and handle service IDs according to the SOME / IP protocol specification. When encountering an undefined service ID, the stack's error message handling is tested.

[0144] The defined service ID + defined method ID + 0 length + regular data primarily tests the protocol stack's ability to handle unusual message lengths. The protocol stack is responsible for receiving, parsing, and distributing messages, and message length is a crucial factor in its message parsing. A data length of 0 violates the protocol specification, so messages constructed according to this construction rule can test the protocol stack's ability to correctly respond to such unusual messages.

[0145] Defined service ID + defined method ID + exceeding defined length + regular data, mainly tests the performance of the protocol stack when processing messages exceeding expected length.

[0146] For a message with a defined service ID, an undefined method ID, a defined length, and regular data, when the service ID is defined but the method ID is undefined, the protocol stack can identify the service, but the business layer cannot determine the specific operation to perform. Therefore, using this type of message, the tester can verify whether the business layer of the tested end will handle this situation abnormally.

[0147] For a defined service ID, method ID, length, and fuzzy test data, the fuzzy test data may indicate various problems encountered by the business layer when processing data. Therefore, through this type of message, the tester can test the fault tolerance of the tested side's business layer when handling such exceptions.

[0148] Therefore, after determining the current functional test requirements for the tested end and determining the type of the target test data packet, the testing end can analyze, based on the functional test requirements, whether the current test focus is the protocol stack layer or the business layer of the tested end, and further determine the corresponding test content, and finally search for the target preset message construction rule corresponding to the current functional test requirement among the multiple preset message construction rules (i.e., preset data packet construction rules) corresponding to the type of the current target test data packet.

[0149] After determining the target preset message construction rule, the test end can construct a target test data packet according to the target preset message construction rule based on the current functional test requirements.

[0150] In the above technical solution, when determining the target test data packet, the type of the target test data packet is determined according to the functional test requirements of the target vehicle, so that the specific test business for the tested end can be clarified. Further, according to the functional test requirements, the target preset data packet construction rules corresponding to the functional test requirements are determined from the multiple preset data packet construction rules corresponding to the type of the target test data packet. In this process, the test end flexibly selects the corresponding data packet construction rules according to the test scenario, which can improve the flexibility of the test and enable the test of this application to better adapt to various test scenarios and demand changes. Finally, according to the functional test requirements and the construction rules of the target preset data packet, the target test data packet is determined, which can ensure that the target test data packet not only meets the functional test requirements, but also complies with the corresponding construction rules, thereby ensuring the accuracy and reliability of the test.

[0151] 402 : Send the target test data packet to the tested terminal based on the SOME / IP protocol, so that the tested terminal processes the target test data packet based on the SOME / IP protocol.

[0152] After constructing the target test data packet, since the test end and the tested end communicate via the SOME / IP protocol, the test end can send the target test data packet to the tested end based on the SOME / IP protocol to test the tested end's response when processing the target test data packet based on the SOME / IP protocol.

[0153] 403. Determine whether a test abnormality occurs on the tested terminal based on actual operating parameters of the tested terminal. The actual operating parameters are used to indicate the operating status of the tested terminal during the test.

[0154] After the tested end receives the target test data packet, its internal program begins running when processing the target test data packet, corresponding to actual operating parameters. In embodiments of the present application, the testing end can determine whether the tested end encountered a test anomaly by obtaining the actual operating parameters of the tested end when processing the target test data packet. The actual operating parameters represent the operating status of the tested end during the test.

[0155] When determining whether a test abnormality occurs at the tested end, it is specifically achieved by comparing the actual operating parameters with the initial operating parameters of the tested end before the test.

[0156] In one possible implementation, the method further includes:

[0157] Before sending the target test data packet, obtain the initial operating parameters of the tested end;

[0158] And, based on the actual operating parameters of the tested terminal, determine whether the tested terminal has a test abnormality, including:

[0159] Determine whether a test abnormality occurs on the tested end based on the initial operating parameters and the actual operating parameters.

[0160] Optionally, regardless of whether they are initial operating parameters or actual operating parameters, the operating parameters include the process ID, memory usage, CPU usage, and activity time. That is, the initial operating parameters include the initial process ID, initial memory usage, initial CPU usage, and initial activity time. The actual operating parameters include the actual process ID, actual memory usage, actual CPU usage, and actual activity time.

[0161] Specifically, when the ECU processes the target test data packets, there's some data interaction between the vehicle's ECU and the Android system. The Android system provides a series of Android debug bridge (adb) command-line tools. Therefore, the aforementioned operating parameters can be obtained using the relevant parameter acquisition commands in the Android system.

[0162] For example, for the initial process ID and the actual process ID, the test end can use adb shell ps|grep <svcname>The ps command can be used to view the status of all processes in the current tested terminal. svcName refers to the service name. When obtaining the process ID, first use adb shell ps|grep <svcname>The command obtains the process ID (PID, also known as the process number) associated with the current service name. Before sending the target test data packet, the test end can use adb shell ps|grep <svcname>After sending the target test data packet, the test end can use adb shell ps|grep <svcname>Instruction to obtain the actual process ID.

[0163] For the initial memory usage and actual memory usage, the test end can use adb shell dumpsysmeminfo <svcname>Instruction acquisition. dumpsys is a command used by the Android system to obtain specific system service information. The meminfo sub-command is specifically used to obtain memory information. <svcname>Before sending the target test data packet, the test end can use adb shell dumpsys meminfo <svcname>After sending the target test data packet, the test end can use adbshell dumpsys meminfo <svcname>Instruction to obtain the actual memory usage.

[0164] Optionally, the memory usage can be expressed as a memory usage rate or as memory occupied space, which is not limited in the embodiments of the present application.

[0165] For the initial CPU usage and actual CPU usage, the test end can first use adb shell ps|grep <svcname>Instructions to obtain the current process ID, and then use adb shell top-p <pid>Get the CPU usage. <pid>It is the process ID obtained. The top command can display the resource usage of each process in the system in real time. Add -p <pid>Before sending the target test data packet, the test end can use adbshell ps|grep <svcname>Instructions to obtain the initial process ID, and then use adb shell top-p <pid>Get the initial CPU usage corresponding to the initial process ID. After sending the target test data packet, the test end can use adb shellps|grep <svcname>Instructions to obtain the actual process ID, and then use adb shell top-p <pid>Get the actual CPU usage corresponding to the actual process ID.

[0166] For the initial activity time and actual activity time, for the tested end, each time a new activity occurs (such as receiving user input, processing data, etc.), the activity time of the tested end will be continuously updated, and the current time will be recorded as the latest activity time. Based on this, the test end can use adb shell dumpsys activity services <svcname>Get the activity time. Before sending the target test data packet, the test end can use adb shell dumpsysactivity services <svcname>After sending the target test data packet, the test end can use adb shell dumpsys activity services <svcname>Instruction to obtain actual activity time.

[0167] Typically, when the tested end is unresponsive, it may also be accompanied by an Application No Responding (ANR) state. Therefore, after sending the target test data packet, in addition to obtaining the actual activity time, the actual operating parameters also include the response status of the tested end. Specifically, the test end can also use the adb logcat | grep "ANR" | grep "<package name>" command to obtain whether the tested end ECU is in the Application No Responding state. The package name here refers to the corresponding software package during the ECU operation process.

[0168] After obtaining all the above parameters, the test end can determine whether a test anomaly occurs when the tested end processes the target test data packet based on these parameters.

[0169] Optionally, the test exceptions in the embodiment of the present application include crash exceptions, memory leak exceptions, processing performance degradation exceptions, and no response exceptions. The following describes in detail the judgment process of different test exceptions.

[0170] The first test exception - crash exception

[0171] When judging whether a crash exception occurs on the tested end, it is determined by the initial process ID and the actual process ID.

[0172] In one possible implementation, determining whether a test abnormality occurs on the tested end based on the initial operating parameters and the actual operating parameters includes:

[0173] Determine whether the initial process ID is consistent with the actual process ID;

[0174] When the initial process ID is consistent with the actual process ID, it is determined that no crash exception occurs on the tested end;

[0175] When the initial process ID is inconsistent with the actual process ID, it is determined that a crash exception occurs on the tested end.

[0176] It should be understood that the reason for comparing the process IDs before and after the test to determine whether the tested device has experienced a crash is that each process in the vehicle has a unique process ID. When the tested device's process starts normally (i.e., the tested ECU is running), the operating system assigns it a specific process ID. As long as the ECU continues to operate normally, its process ID remains unchanged.

[0177] When a process crashes, the operating system terminates it, and the corresponding process ID no longer belongs to it. If the tested device crashes and then restarts to recover, the operating system assigns a new process ID to the newly started process. Therefore, if the tested device crashes and then restarts, the corresponding process IDs before and after the crash will inevitably be different.

[0178] Based on this, the test end first obtains the initial process identifier before sending the target test data packet. After sending the target test data packet, the actual process identifier at the current moment is obtained. When the initial process identifier and the actual process identifier are the same, it means that since the process of the tested end was started, the process has not crashed and restarted during the test. On the contrary, when the initial process identifier and the actual process identifier are different, it means that the currently running process is no longer the process corresponding to the initial process identifier, but a new process that has been restarted. This situation is usually caused by the crash of the previous process. Therefore, the test end determines that a crash exception has occurred on the tested end.

[0179] In the above technical solution, when determining whether the tested end has experienced a crash anomaly during the test, the initial process ID is compared with the actual process ID. This method does not require complex and in-depth parameter analysis, thereby improving the efficiency of crash detection through this simple and efficient method. In addition, due to the uniqueness of process IDs, by comparing process IDs before and after the test, process anomalies can be promptly and accurately detected, accurately locating whether the tested end has experienced a crash anomaly, and improving the reliability and stability of anomaly detection.

[0180] The second test exception - memory leak exception

[0181] In one possible implementation, determining whether a test abnormality occurs on the tested end based on the initial operating parameters and the actual operating parameters includes:

[0182] Repeat the test on the test end based on the target test data packet, and obtain N first test times of the target test data packet, where N is a positive integer greater than 1;

[0183] When N is greater than or equal to the first preset number of times, for any first test number among the N first test numbers, determining a memory usage change corresponding to the first test number according to the target actual memory usage corresponding to the first test number and the target initial memory usage;

[0184] Performing linear fitting on the N memory usage changes corresponding to the N first test times to determine the memory usage change trend of the tested terminal;

[0185] If the memory usage trend is increasing, it is determined that a memory leak occurs on the tested end.

[0186] If the memory usage change trend is not an upward trend, it is determined that no memory leak exception occurs on the tested end.

[0187] It should be understood that a memory leak is a phenomenon in which memory usage continuously increases while a program is running. Therefore, monitoring changes in memory usage before and after testing is key to determining whether a memory leak has occurred. Furthermore, because it is necessary to observe the changing trends in memory usage, multiple tests of the tested device based on the target test data packets are necessary to accurately capture the cumulative changes in memory usage.

[0188] Specifically, based on the target test data packet, the test end can repeatedly send the target test data packet to the tested end and obtain N first test times of the target test data packet in real time. In addition, before each target test data packet is sent, the test end needs to first obtain the initial memory usage of the tested end before the target test data packet is sent. After each target test data packet is sent, the test end can obtain the actual memory usage of the test end. This allows the test end to subsequently analyze the memory usage change trend of the tested end based on the memory usage change of the tested end before and after each test.

[0189] Optionally, when the memory usage is expressed as memory space (bytes), the corresponding memory usage change refers to the change in memory space. When the memory usage is expressed as memory usage percentage, the corresponding memory usage change refers to the change in memory usage percentage.

[0190] The embodiment of the present application pre-sets a critical number of repeated tests, that is, a first preset number. Optionally, the first preset number is 50 times. When the test end detects that N is greater than or equal to the first preset number, it can be determined that the judgment requirements for memory leaks are currently met. Furthermore, after obtaining the initial memory occupancy and actual memory occupancy corresponding to each of the N first test times, for any one of the first test times, the test end can determine the target actual memory occupancy and target initial memory occupancy corresponding to the current first test number, and calculate the target actual memory occupancy and target initial memory occupancy, and calculate the memory occupancy change corresponding to the first test number.

[0191] By performing the above calculation for each of the N first test times, we can obtain the N memory usage changes corresponding to the N first test times. The memory usage change is closely related to the total memory usage. If the memory usage change continues to increase, since the memory usage change is based on the difference between the actual memory usage and the initial memory usage, it indicates that the actual memory usage is showing an overall upward trend.

[0192] Therefore, the test end can perform a linear fit on the N memory usage changes to determine the changing trend of the memory usage changes. When the changing trend of the memory usage changes is an upward trend, it means that the changing trend of the memory usage of the tested end is also an upward trend. When the changing trend of the memory usage of the tested end is an upward trend, the test end can determine that the tested end has a memory leak anomaly during the test. On the contrary, when the changing trend of the memory usage does not show an upward trend, the test end determines that the tested end has no memory leak anomaly.

[0193] In the above technical solution, repeated testing of the test end based on the target test data packet can avoid the errors and occasional interference caused by single test results, thereby improving the accuracy of the test results. During the repeated testing process, by obtaining N memory usage changes corresponding to N first test times and performing a linear fit on them, it is possible to comprehensively analyze the changing trend of memory usage as the number of tests increases. The linear fit can also eliminate short-term fluctuations in the data, more accurately identify the changing trend of memory usage, and improve the accuracy of memory leak judgment.

[0194] The third test exception - handling performance degradation exception

[0195] In one possible implementation, determining whether a test abnormality occurs on the tested end based on the initial operating parameters and the actual operating parameters includes:

[0196] Based on the target test data packet, repeatedly test the test end and obtain M second test times and cumulative test duration of the target test data packet, where M is a positive integer greater than 1;

[0197] When M is greater than or equal to the second preset number of times and the cumulative test duration is greater than or equal to the preset duration, for any second test number of the M second test times, determining the CPU occupancy change corresponding to the second test number according to the target initial CPU occupancy corresponding to the second test number and the target actual CPU occupancy;

[0198] Performing linear fitting on the M CPU usage changes corresponding to the M second test times to determine the CPU usage change trend of the tested terminal;

[0199] If the CPU usage trend is increasing, it is determined that the tested end has experienced abnormal processing performance degradation.

[0200] If the CPU usage change trend is not an upward trend, it is determined that the tested end does not experience abnormal processing performance degradation.

[0201] The aforementioned processing performance degradation mainly refers to a degradation in CPU processing performance.

[0202] It should be understood that when the CPU processing performance decreases, the CPU will usually continue to run at a high load, which means that the CPU needs to spend more resources to complete the same task, resulting in a continuous increase in CPU usage. Therefore, when judging whether the tested end has an abnormal decline in processing performance, this can be achieved by monitoring the changing trend of the CPU usage. Since it is necessary to observe the changing trend of the CPU memory usage, it is necessary to perform multiple tests on the tested end based on the target test data packet in order to accurately capture the cumulative changes in the CPU usage. In addition, in order to accurately evaluate the CPU performance of the tested end after a period of normal operation and avoid misjudgment caused by too short a test time, it is also necessary to limit the test time.

[0203] Specifically, based on the target test data packet, the test end can repeatedly send the target test data packet to the tested end, and obtain M second test times of the target test data packet in real time, and use the timer to time the current test duration to obtain the cumulative test duration. In addition, before each target test data packet is sent, the test end needs to first obtain the initial CPU occupancy of the tested end before the target test data packet is sent, and after each target test data packet is sent, the test end can obtain the actual CPU occupancy of the test end, so that the subsequent test end can analyze the CPU occupancy change trend of the tested end based on the CPU occupancy change of the tested end before and after each test. Generally, when describing the CPU occupancy rate, it mainly refers to the CPU occupancy rate.

[0204] The embodiment of the present application pre-sets a critical number of repeated tests, i.e., a second preset number, and a critical cumulative duration of repeated tests, i.e., a preset duration. Optionally, the second preset number can be the same as the first preset number, i.e., 50 times, or the second preset number can be different from the second preset number, and the preset duration can be 10s. When the test end detects that M is greater than or equal to the second preset number and the cumulative test duration is greater than or equal to the preset duration, it can be determined whether the judgment requirement of whether the processing performance has decreased is currently met. Further, after obtaining the initial CPU occupancy and actual CPU occupancy corresponding to each of the M second test times, for any one of the second test times, the test end can determine the target actual CPU occupancy and target initial CPU occupancy corresponding to the current second test time, and calculate the target actual CPU occupancy and target initial CPU occupancy, and calculate the CPU occupancy change corresponding to the second test time.

[0205] By performing the above calculation for each of the M second test times, the M CPU usage changes corresponding to the M second test times can be obtained. Similar to the correlation between the memory usage change and the memory usage, there is also a close relationship between the CPU usage change and the CPU usage. This is because if the CPU usage change continues to increase, since the CPU usage change is based on the difference between the actual CPU usage and the initial CPU usage, it indicates that the actual CPU usage is showing an overall upward trend.

[0206] Therefore, the test end can perform a linear fit on the M CPU usage changes to determine the changing trend of the CPU usage changes. When the changing trend of the CPU usage changes is an upward trend, it indicates that the changing trend of the CPU usage of the tested end is also an upward trend. When the changing trend of the CPU usage of the tested end is an upward trend, the test end can determine that the tested end has experienced an abnormal decline in processing performance during the test. Conversely, when the changing trend of the CPU usage does not show an upward trend, the test end determines that the tested end has not experienced an abnormal decline in processing performance.

[0207] In the above technical solution, repeated testing of the test end based on the target test data packet can avoid the errors and occasional interference caused by single test results, thereby improving the accuracy of the test results. During the repeated testing process, by obtaining M CPU usage changes corresponding to M second test times and performing a linear fit on them, it is possible to comprehensively analyze the changing trend of CPU usage as the number of tests increases. The linear fit can also eliminate short-term fluctuations in the data, more accurately identify the changing trend of CPU usage, and improve the accuracy of determining whether the CPU processing performance has declined.

[0208] The fourth test exception - no response exception

[0209] In one possible implementation, determining whether a test abnormality occurs on the tested end based on the initial operating parameters and the actual operating parameters includes:

[0210] Determine whether the actual activity time is consistent with the initial activity time, and determine whether the response status of the tested end is the application unresponsive state;

[0211] When the actual activity time is consistent with the initial activity time, or the response status of the tested end is the application unresponsive state, it is determined that the tested end has an unresponsive exception;

[0212] When the actual activity time is inconsistent with the initial activity time and the response state of the tested end is not an application unresponsive state, it is determined that the tested end does not have an unresponsiveness exception.

[0213] It should be understood that there are two corresponding judgment methods when judging whether the tested end has an unresponsive exception. The first is by comparing the initial activity time and the actual activity time; the second is by obtaining whether the current tested end is in the ANR state, which is the most obvious manifestation of the application being unresponsive.

[0214] By comparing the initial activity time with the actual activity time, we can determine whether the tested end-point has experienced an unresponsiveness anomaly. This is primarily because when the tested end-point is operating normally, its internal processes or services continuously perform various operations and interactions, which results in constant updates to the activity time. In other words, each time a new activity occurs, such as receiving user input, processing data, or communicating with other components, the current time is recorded as the latest activity time. Therefore, under normal circumstances, the latest activity time will gradually increase over time, constantly updating to a later point in time. If the tested end-point becomes unresponsive, it means that its process or service has ceased normal activity for a period of time. Since no new activity occurs, the latest activity time will not be updated and will remain at a previous point in time, unchanged by the passage of actual time. Therefore, by comparing the current actual activity time with the initial activity time, we can determine whether the tested end-point has experienced any new activity and, therefore, whether the tested end has experienced an unresponsiveness anomaly during the test.

[0215] Specifically, if the actual activity time and initial activity time are consistent after the test end obtains them, it indicates that no new activity has occurred on the tested end during this period, and the tested end may be unresponsive (for example, deadlocked). Alternatively, if the test end obtains that the tested end is in the ANR state, it also indicates that the tested end is unresponsive.

[0216] On the contrary, when the actual activity time is inconsistent with the initial activity time, and the current tested end is not in the ANR state, it means that the tested end has generated new activities during this period, indicating that the tested end is operating normally and no unresponsiveness exception occurs.

[0217] In the above technical solution, when determining whether an unresponsiveness exception occurs on the tested end, the actual activity time and the initial activity time are comprehensively considered, as well as whether the tested end is in an unresponsive state of the application. Through this multi-dimensional judgment method, it is possible to more accurately detect whether an unresponsiveness exception occurs on the tested end, avoid the judgment loopholes caused by a single judgment method, and enhance the card type and accuracy of the judgment result.

[0218] Therefore, through the above different judgment processes, the testing end can timely discover different abnormalities in the tested end during the testing process of the tested end.

[0219] It should be understood that during the testing of the tested end using the target test data packet, the aforementioned anomaly detection processes can be performed in parallel by running different processes on the tested end. This approach enables the simultaneous completion of multiple anomaly detection processes in a relatively short period of time, thereby improving testing efficiency. Alternatively, the aforementioned anomaly detection processes can be performed sequentially. For example, detection priorities can be set for the various anomaly detection processes based on their resource requirements or importance. This approach can avoid interference between different testing processes and reduce testing complexity.

[0220] In addition, during the test process, in order to facilitate subsequent technical personnel to conduct detailed analysis and processing of abnormal situations, the test end can also use a test data packet list to store each test data packet in the test process.

[0221] Specifically, in an embodiment of the present application, a maximum number of data packets that can be stored in the test data packet list can be set. After detecting that the number of data packets in the test data packet list has reached the maximum number of data packets, the test end can delete the test data packets with an earlier storage time.

[0222] In order to facilitate the understanding of the above process of determining whether the tested end has a test exception, the following Figure 5 The above process is introduced.

[0223] Figure 5 This is a schematic flowchart of a method for determining whether an abnormality occurs at a tested end, provided in an embodiment of the present application.

[0224] For example, Figure 5 As shown, the method 500 includes the following steps 501 to 522.

[0225] 501, adb establishes a connection with the Android system.

[0226] This step refers to establishing a communication channel between the test end and the in-vehicle Android system through the adb tool.

[0227] After establishing the communication signal and before sending the target test data packet, the test end may respectively execute steps 502 to 505 to obtain initial operating parameters for different anomaly detections.

[0228] 502, obtain the initial process ID.

[0229] 503. Get the initial memory usage.

[0230] 504. Obtain the initial CPU usage.

[0231] 505, obtain the initial activity time.

[0232] 506 , determining a target test data package based on the functional test requirements for the target vehicle.

[0233] 507, sending a target test data packet to the tested end.

[0234] According to different anomaly detection requirements, after sending the target test data packet, the test end can obtain the actual operating parameters corresponding to each initial operating parameter and detect anomalies on the tested end.

[0235] 508, obtain the actual process ID.

[0236] 509, determine whether the initial process ID is consistent with the actual process ID.

[0237] When the initial process ID is consistent with the actual process ID, it is determined that the tested end does not have a crash exception.

[0238] When the initial process identifier is inconsistent with the actual process identifier, step 510 is executed.

[0239] 510: It is determined that a crash exception occurred on the tested end.

[0240] 511, get the actual memory usage.

[0241] 512. Determine whether the current first test number N of repetitions is greater than or equal to a first preset number.

[0242] When N is greater than or equal to the first preset number, execute step 513;

[0243] When N is less than the first preset number, the target test data packet is repeatedly sent to perform the test.

[0244] 513. For any first test number among the N first test numbers, determine the memory occupancy change corresponding to the first test number based on the target actual memory occupancy and the target initial memory occupancy corresponding to the first test number; perform linear fitting on the N memory occupancy changes corresponding to the N first test numbers to determine the memory occupancy change trend of the tested end.

[0245] 514. Determine whether the change trend of the memory usage of the tested terminal is an upward trend.

[0246] When the memory usage change trend is not an upward trend, it is determined that no memory leak exception occurs on the tested end.

[0247] When the memory usage change trend is an upward trend, step 515 is executed.

[0248] 515: It is determined that a memory leak exception occurs on the tested end.

[0249] 516, obtain the actual CPU usage.

[0250] 517 , determining whether the current number M of repeated second tests is greater than or equal to a second preset number, and whether the accumulated test duration is greater than or equal to a preset duration.

[0251] When M is less than a second preset number of times, or the cumulative test duration is less than a preset duration, continue to repeatedly send the target test data packet for testing;

[0252] When M is greater than or equal to the second preset number and the accumulated test duration is greater than or equal to the preset duration, step 518 is executed.

[0253] 518. For any second test number of the M second test numbers, determine the CPU occupancy change corresponding to the second test number based on the target initial CPU occupancy and the target actual CPU occupancy corresponding to the second test number; perform linear fitting on the M CPU occupancy changes corresponding to the M second test numbers to determine the CPU occupancy change trend of the tested end.

[0254] 519, determine whether the CPU usage change trend is an upward trend.

[0255] If the CPU usage trend is not increasing, confirm that the tested end has no abnormal processing performance degradation.

[0256] When the CPU usage change trend is an upward trend, step 520 is executed.

[0257] 520: It is determined that the processing performance of the tested end has degraded abnormally.

[0258] 521, obtain the actual activity time and response status of the tested end.

[0259] 522, determining whether the actual activity time is consistent with the initial activity time, and determining whether the response status of the tested terminal is an application unresponsive state.

[0260] When the actual activity time is inconsistent with the initial activity time, and the response status of the tested end is not the application unresponsive state, it is determined that the tested end does not have an unresponsive exception;

[0261] When the actual activity time is consistent with the initial activity time, or the response status of the tested terminal is the application unresponsive state, step 523 is executed.

[0262] 523: The tested end is determined to be unresponsive.

[0263] Steps 501 to 523 in the above method 500 have the same inventive concept as the above four situations of determining test abnormality of the tested end. Please refer to the above introduction for details and will not be repeated here.

[0264] 404. When a test exception occurs on the tested end, the test process of the tested end is terminated.

[0265] Therefore, through step 403, the testing end can determine whether the tested end has the above-mentioned abnormalities during the testing process.

[0266] When the tested end does not have the above-mentioned abnormalities, the testing end can conduct a new round of testing on the tested end according to the next two functional test requirements.

[0267] When any of the above-mentioned exceptions occur on the tested end, the testing end needs to terminate the testing process on the tested end, analyze the current exception cause in a timely manner, and formulate corresponding treatment measures.

[0268] In summary, a method for testing vehicle abnormalities is provided, and the specific implementation process of the method is: when testing the vehicle ECU, first determine the target test data packet according to the functional test requirements, and then send the target test data packet to the tested end based on the SOME / IP protocol. When the tested end processes the target test data packet, it can be determined whether the tested end has an abnormality based on the actual operating parameters of the tested end and terminate the test when an abnormality occurs. The above-mentioned targeted determination of relevant target test data packets based on the test function requirements can make the test process closer to the actual communication scenario of the vehicle and more in line with current test requirements, so that during the test process, it can accurately detect whether the tested end has an abnormality, thereby improving the reliability and accuracy of the test results. When an abnormality is found, terminating the test can obtain the abnormal situation in the first time, which is convenient for accurate handling of the abnormal situation.

[0269] Below through Figure 6 The overall implementation process of the embodiment of the present application is introduced in detail.

[0270] Figure 6 It is a schematic flowchart of another method for testing vehicle abnormalities provided in an embodiment of the present application.

[0271] For example, Figure 6 As shown, the method 600 includes the following steps 601 to 619.

[0272] 601. Determine the type of a target test data packet according to a functional test requirement of a target vehicle. The type of the target test data packet is used to indicate how the tested end processes the target test data packet.

[0273] 602 : According to the functional test requirement, determine a target preset data packet construction rule corresponding to the functional test requirement from a plurality of preset data packet construction rules corresponding to the type of the target test data packet.

[0274] 603 , determining a target test data packet according to the functional test requirements and target preset data packet construction rules.

[0275] 604. Obtain the initial operating parameters of the tested terminal.

[0276] The initial running parameters include the initial process ID, initial memory usage, initial CPU usage, and initial activity time.

[0277] 605, sending the target test data packet to the tested end.

[0278] 606. Obtain the actual operating parameters of the tested terminal.

[0279] The actual running parameters include the actual process ID, actual memory usage, actual CPU usage, actual activity time, and the response status of the tested end.

[0280] 607, determine whether the initial process ID is consistent with the actual process ID.

[0281] When the initial process ID is consistent with the actual process ID, it is determined that no crash exception occurs on the tested end;

[0282] When the initial process identifier is inconsistent with the actual process identifier, step 608 is executed.

[0283] 608: It is determined that a crash exception occurs on the tested terminal.

[0284] When it is determined that the tested terminal has a crash exception, step 619 is executed.

[0285] 609 , determining whether the current first test number N of repetitions is greater than or equal to a first preset number.

[0286] When N is greater than or equal to the first preset number, execute step 610;

[0287] When N is less than the first preset number, the target test data packet is repeatedly sent to perform the test.

[0288] 610. For any first test number among the N first test times, determine the memory occupancy change corresponding to the first test number based on the target actual memory occupancy and the target initial memory occupancy corresponding to the first test number; perform linear fitting on the N memory occupancy changes corresponding to the N first test times to determine the memory occupancy change trend of the tested end.

[0289] 611. Determine whether the change trend of the memory usage of the tested terminal is an upward trend.

[0290] When the memory usage change trend is not an upward trend, it is determined that no memory leak exception occurs on the tested end.

[0291] When the memory usage change trend is an upward trend, step 612 is executed.

[0292] 612: It is determined that a memory leak exception occurs on the tested end.

[0293] When it is determined that a memory leak exception occurs on the tested end, step 619 is executed.

[0294] 613 , determining whether the current number M of repeated second tests is greater than or equal to a second preset number, and whether the accumulated test duration is greater than or equal to a preset duration.

[0295] When M is less than a second preset number of times, or the cumulative test duration is less than a preset duration, continue to repeatedly send the target test data packet for testing;

[0296] When M is greater than or equal to the second preset number and the accumulated test duration is greater than or equal to the preset duration, step 614 is executed.

[0297] 614. For any second test number of the M second test numbers, determine the CPU occupancy change corresponding to the second test number based on the target initial CPU occupancy and the target actual CPU occupancy corresponding to the second test number; perform linear fitting on the M CPU occupancy changes corresponding to the M second test numbers to determine the CPU occupancy change trend of the tested end.

[0298] 615 , determining whether the CPU usage change trend is an upward trend.

[0299] If the CPU usage trend is not increasing, confirm that the tested end has no abnormal processing performance degradation.

[0300] When the CPU usage change trend is an upward trend, step 616 is executed.

[0301] 616: It is determined that the processing performance of the tested end has degraded abnormally.

[0302] When it is determined that the processing performance of the tested terminal is abnormally degraded, step 619 is executed.

[0303] 617, determining whether the actual activity time is consistent with the initial activity time, and determining whether the response status of the tested terminal is an application unresponsive state.

[0304] When the actual activity time is inconsistent with the initial activity time, and the response status of the tested end is not the application unresponsive state, it is determined that the tested end does not have an unresponsive exception;

[0305] When the actual activity time is consistent with the initial activity time, or the response status of the tested terminal is the application unresponsive state, step 618 is executed.

[0306] 618: It is determined that the tested end has a non-responsive exception.

[0307] When it is determined that the tested end has a non-response exception, step 619 is executed.

[0308] 619. When a test exception occurs on the tested end, the test process of the tested end is terminated.

[0309] Steps 601 to 619 in the above method 600 have the same inventive concept as steps 401 to 404 in the method 400. Please refer to the above introduction for details and will not be repeated here.

[0310] Figure 7 It is a structural schematic diagram of a device for testing vehicle abnormalities provided in an embodiment of the present application.

[0311] For example, Figure 7 As shown, the apparatus 700 includes:

[0312] The data packet determination module 701 is used to determine the target test data packet according to the functional test requirements of the target vehicle;

[0313] The data packet sending module 702 is configured to send the target test data packet to the tested terminal based on the SOME / IP protocol, so that the tested terminal processes the target test data packet based on the SOME / IP protocol;

[0314] Anomaly detection module 703, configured to determine whether a test anomaly occurs on the tested terminal based on actual operating parameters of the tested terminal, where the actual operating parameters are used to indicate the operating status of the tested terminal during the test;

[0315] The test termination module 704 is configured to terminate the test process of the tested end when the test exception occurs at the tested end.

[0316] In one possible implementation, the anomaly detection module 703 is specifically used to: obtain the initial operating parameters of the tested end before sending the target test data packet; and determine whether a test anomaly occurs at the tested end based on the initial operating parameters and the actual operating parameters.

[0317] In one possible implementation, the test exception includes a crash exception, the initial operating parameters include an initial process identifier, and the actual operating parameters include an actual process identifier. The exception detection module 703 is also used to: determine whether the initial process identifier is consistent with the actual process identifier; when the initial process identifier is consistent with the actual process identifier, determine that the crash exception does not occur on the tested end; when the initial process identifier is inconsistent with the actual process identifier, determine that the crash exception occurs on the tested end.

[0318] In one possible implementation, the test exception includes a memory leak exception, the initial operating parameters include an initial memory occupancy, and the actual operating parameters include an actual memory occupancy. The exception detection module 703 is also used to: based on the target test data packet, repeatedly test the test end and obtain N first test times of the target test data packet, where N is a positive integer greater than 1; when N is greater than or equal to the first preset number, for any first test number among the N first test times, determine the memory occupancy change corresponding to the first test number based on the target actual memory occupancy and the target initial memory occupancy corresponding to the first test number; perform linear fitting on the N memory occupancy changes corresponding to the N first test times to determine the memory occupancy change trend of the tested end; when the memory occupancy change trend is an upward trend, determine that the tested end has the memory leak exception; when the memory occupancy change trend is not the upward trend, determine that the tested end has not the memory leak exception.

[0319] In one possible implementation, the test abnormality includes a processing performance degradation abnormality, the initial operating parameters include an initial CPU occupancy, and the actual operating parameters include an actual CPU occupancy. The abnormality detection module 703 is also used to: based on the target test data packet, repeatedly test the test end, and obtain M second test times and cumulative test duration of the target test data packet, where M is a positive integer greater than 1; when M is greater than or equal to the second preset number, and the cumulative test duration is greater than or equal to the preset duration, for any second test number of the M second test times, determine the CPU occupancy change corresponding to the second test number based on the target initial CPU occupancy and the target actual CPU occupancy corresponding to the second test number; perform linear fitting on the M CPU occupancy changes corresponding to the M second test times to determine the CPU occupancy change trend of the tested end; when the CPU occupancy change trend is an upward trend, determine that the tested end has the processing performance degradation abnormality; when the CPU occupancy change trend is not the upward trend, determine that the tested end has not the processing performance degradation abnormality.

[0320] In one possible implementation, the test exception includes a no-response exception, the initial operating parameters include the initial activity time, the actual operating parameters include the actual activity time and the response status of the tested end, and the exception detection module 703 is also used to: determine whether the actual activity time is consistent with the initial activity time, and determine whether the response status of the tested end is an application no-response state; when the actual activity time is consistent with the initial activity time, or the response status of the tested end is an application no-response state, determine that the tested end has the no-response exception; when the actual activity time is inconsistent with the initial activity time, and the response status of the tested end is not an application no-response state, determine that the tested end does not have the no-response exception.

[0321] In one possible implementation, the data packet determination module 701 is specifically used to: determine the type of the target test data packet according to the functional test requirements of the target vehicle, and the type of the target test data packet is used to indicate how the tested end processes the target test data packet; determine the target preset data packet construction rule corresponding to the functional test requirement from multiple preset data packet construction rules corresponding to the type of the target test data packet according to the functional test requirements; and determine the target test data packet according to the functional test requirements and the target preset data packet construction rule.

[0322] Figure 8 1 is a schematic diagram of the structure of an electronic device at a test end provided in an embodiment of the present application. Optionally, the electronic device at the test end can be a vehicle or an external detection device.

[0323] For example, Figure 8 As shown, the electronic device 800 includes: a memory 801 and a processor 802, wherein the memory 801 stores an executable program code 8011, and the processor 802 is used to call and execute the executable program code 8011 to perform a method for testing vehicle abnormalities.

[0324] In this embodiment, the electronic device can be divided into functional modules according to the above-described method example. For example, each functional module can be mapped to a specific function, or two or more functions can be integrated into a single processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and represents only a logical functional division. In actual implementation, other division methods may be used.

[0325] When the functional modules are divided according to their functions, the electronic device may include: a data packet determination module, a data packet transmission module, an anomaly detection module, and a test termination module. It should be noted that all relevant content of each step involved in the above method embodiment can be referred to in the functional description of the corresponding functional module and will not be repeated here.

[0326] The electronic device provided in this embodiment is used to execute the above-mentioned method for testing vehicle abnormalities, and thus can achieve the same effect as the above-mentioned implementation method.

[0327] In the case of an integrated unit, the electronic device may include a processing module and a storage module. The processing module may be used to control and manage the operation of the electronic device, and the storage module may be used to support the electronic device in executing relevant program codes and data.

[0328] The processing module may be a processor or controller that implements or executes the various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processing (DSP) and a microprocessor, and the storage module may be a memory.

[0329] This embodiment also provides a computer-readable storage medium, which stores computer program code. When the computer program code runs on a computer, the computer executes the above-mentioned related method steps to implement a method for testing vehicle abnormalities in the above-mentioned embodiment.

[0330] This embodiment also provides a computer program product. When the computer program product is run on a computer, it enables the computer to execute the above-mentioned related steps to implement a method for testing vehicle abnormalities in the above-mentioned embodiment.

[0331] In addition, the electronic device provided in the embodiments of the present application can specifically be a chip, component or module, and the electronic device may include a connected processor and memory; wherein the memory is used to store instructions, and when the electronic device is running, the processor can call and execute instructions to enable the chip to execute a method for testing vehicle abnormalities in the above embodiment.

[0332] Among them, the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0333] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by 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.

[0334] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0335] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.< / svcname> < / svcname> < / svcname> < / pid> < / svcname> < / pid> < / svcname> < / pid> < / pid> < / pid> < / svcname> < / svcname> < / svcname> < / svcname> < / svcname> < / svcname> < / svcname> < / svcname> < / svcname>

Claims

1. A method for testing vehicle abnormality, characterized in that: The method comprises: Determine the target test data package based on the functional test requirements of the target vehicle; Based on the SOME / IP protocol, the target test data packet is sent to the tested terminal, so that the tested terminal processes the target test data packet based on the SOME / IP protocol; determining whether a test abnormality occurs on the tested end according to actual operating parameters of the tested end, wherein the actual operating parameters are used to represent the operating state of the tested end during the test; When the test abnormality occurs at the tested end, the test process of the tested end is terminated.

2. The method according to claim 1, characterized in that The method further comprises: Before sending the target test data packet, obtaining the initial operating parameters of the tested terminal; And, determining whether a test abnormality occurs on the tested end according to actual operating parameters of the tested end, including: Determine whether a test abnormality occurs at the tested end according to the initial operating parameters and the actual operating parameters.

3. The method according to claim 2, characterized in that The test exception includes a crash exception, the initial operation parameters include an initial process identifier, and the actual operation parameters include an actual process identifier. Determining whether the tested end has a test exception based on the initial operation parameters and the actual operation parameters includes: Determining whether the initial process identifier is consistent with the actual process identifier; When the initial process identifier is consistent with the actual process identifier, determining that the tested terminal does not have the crash exception; When the initial process identifier is inconsistent with the actual process identifier, it is determined that the crash exception occurs on the tested end.

4. The method according to claim 2, characterized in that The test exception includes a memory leak exception, the initial operating parameters include an initial memory usage, and the actual operating parameters include an actual memory usage. Determining whether the tested end has a test exception based on the initial operating parameters and the actual operating parameters includes: Repeat the test on the test end based on the target test data packet, and obtain N first test times of the target test data packet, where N is a positive integer greater than 1; When N is greater than or equal to the first preset number of times, for any first test number among the N first test numbers, determining a memory usage change corresponding to the first test number according to a target actual memory usage and a target initial memory usage corresponding to the first test number; Performing linear fitting on the N memory usage changes corresponding to the N first test times to determine a memory usage change trend of the tested terminal; When the memory usage change trend is an upward trend, determining that the tested terminal has the memory leak anomaly; When the memory usage variation trend is not the upward trend, it is determined that the tested terminal does not have the memory leak anomaly.

5. The method according to claim 2, characterized in that The test abnormality includes a processing performance degradation abnormality, the initial operating parameters include an initial CPU usage, and the actual operating parameters include an actual CPU usage. Determining whether the tested end has a test abnormality based on the initial operating parameters and the actual operating parameters includes: Repeat the test on the test end based on the target test data packet, and obtain M second test times and cumulative test duration of the target test data packet, where M is a positive integer greater than 1; When M is greater than or equal to a second preset number of times and the cumulative test duration is greater than or equal to the preset duration, for any second test number of the M second test times, determining a CPU occupancy change corresponding to the second test number according to the target initial CPU occupancy corresponding to the second test number and the target actual CPU occupancy; Performing linear fitting on the M CPU usage changes corresponding to the M second test times to determine a CPU usage change trend of the tested terminal; When the CPU usage change trend is an upward trend, determining that the processing performance degradation abnormality occurs on the tested terminal; When the CPU usage change trend is not the upward trend, it is determined that the tested terminal does not have the processing performance degradation anomaly.

6. The method according to claim 2, characterized in that The test abnormality includes a no-response abnormality, the initial operating parameters include an initial activity time, the actual operating parameters include an actual activity time and a response status of the tested terminal, and determining whether the tested terminal has a test abnormality based on the initial operating parameters and the actual operating parameters includes: Determining whether the actual activity time is consistent with the initial activity time, and determining whether the response state of the tested terminal is an application unresponsive state; When the actual activity time is consistent with the initial activity time, or the response state of the tested terminal is the application unresponsive state, determining that the unresponsiveness exception occurs on the tested terminal; When the actual activity time is inconsistent with the initial activity time, and the response state of the tested terminal is not the application unresponsive state, it is determined that the unresponsiveness exception does not occur in the tested terminal.

7. The method according to claim 1, characterized in that Determining a target test data packet according to the functional test requirements of the target vehicle includes: Determining the type of the target test data packet according to the functional test requirements of the target vehicle, where the type of the target test data packet is used to indicate how the tested end processes the target test data packet; According to the functional test requirement, determining a target preset data packet construction rule corresponding to the functional test requirement from a plurality of preset data packet construction rules corresponding to the type of the target test data packet; The target test data packet is determined according to the functional test requirement and the target preset data packet construction rule.

8. A device for testing vehicle abnormalities, characterized in that: The device comprises: A data packet determination module is used to determine a target test data packet according to the functional test requirements of the target vehicle; A data packet sending module, configured to send the target test data packet to the tested terminal based on the SOME / IP protocol, so that the tested terminal processes the target test data packet based on the SOME / IP protocol; an anomaly detection module, configured to determine whether a test anomaly occurs on the tested terminal based on actual operating parameters of the tested terminal, wherein the actual operating parameters are used to represent the operating status of the tested terminal during the test; The test termination module is used to terminate the test process of the tested end when the test abnormality occurs at the tested end.

9. An electronic device, characterized in that: The electronic device comprises: a memory for storing executable program code; A processor is configured to call and run the executable program code from the memory, so that the electronic device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 7 is implemented.

Images