Program detection method and device, storage medium and electronic equipment

Abstract

The invention discloses a program detection method and device, a storage medium and electronic equipment. The method comprises the steps that a target source code corresponding to a to-be-tested program is determined, a program exception logic tree is generated according to the target source code, the program exception logic tree comprises at least one branch node and at least one preset exception node, and the preset exception node is used for indicating a preset exception condition in the running process of the target source code; determining at least one target node in branch nodes of the program exception logic tree and preset exception nodes; running the to-be-tested program, collecting current log data of the target node under the condition that the target source code runs to the target node, and sending the collected log data to the data analysis terminal; and under the condition that the target source code runs each target node or the running of the target source code is finished, receiving a program detection result returned by the data analysis terminal. The technical problem that a vehicle program detection method provided by a related technology is relatively high in data resource consumption is solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle-mounted detection technology, and in particular to a program detection method and device, a storage medium, and an electronic device. Background Art

[0002] In the development of automotive embedded systems, traditional program execution log analysis methods rely on log level control and file system storage. However, after installation, the electronic control unit (ECU) disables debug ports such as serial ports and JTAG for network security reasons, making log data difficult to directly obtain. In addition, most ECUs have limited interface resources. While transferring log data to the system on chip (SoC) via a single bus such as the controller area network (CAN) is feasible, it is limited by challenges such as the supporting microcontroller (MCU), the risk of losing the startup process log, and communication load and storage pressure. Especially in scenarios with complex software operating conditions and large amounts of log data, it is not only inefficient but may also damage system performance. In other words, the vehicle program detection methods provided by related technologies suffer from the problem of high data resource consumption. Summary of the Invention

[0003] The embodiments of the present application provide a program detection method and device, a storage medium, and an electronic device to at least solve the technical problem that the vehicle program detection method provided by the related art consumes a large amount of data resources.

[0004] According to one aspect of an embodiment of the present application, a program detection method is provided, comprising: determining a target source code corresponding to a program to be tested, and generating a program exception logic tree based on the target source code, wherein the program exception logic tree comprises at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset exception situation during the operation of the target source code; determining at least one target node among the branch nodes and the preset exception nodes of the program exception logic tree; running the program to be tested, and when the target source code runs to the target node, collecting current log data of the target node, and sending the collected log data to a data analysis terminal; and receiving a program detection result returned by the data analysis terminal when the target source code has run through each target node or the target source code has finished running.

[0005] According to another aspect of an embodiment of the present application, a program detection device is also provided, including: an exception logic tree generation unit, used to determine the target source code corresponding to the program to be tested, and generate a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset exception situation during the operation of the target source code; a target node determination unit, used to determine at least one target node among the branch nodes and the preset exception nodes of the program exception logic tree; a data collection unit, used to run the program to be tested, and when the target source code runs to the target node, collect the current log data of the target node, and send the collected log data to the data analysis terminal; a data analysis unit, used to receive the program detection result returned by the data analysis terminal when the target source code has run through each target node or the target source code has ended.

[0006] Optionally, the above-mentioned abnormal logic tree generation unit includes: a condition determination module, which is used to determine at least one logical branch condition corresponding to the target source code, wherein the logical branch condition is used to indicate the conditions for executing different code blocks based on current log data; a node determination module, which is used to determine the branch nodes corresponding to at least one logical branch condition, and determine the exit nodes corresponding to the branch nodes, wherein the exit nodes include abnormal nodes and normal nodes, and the exit nodes are used to indicate the termination point of the current branch node; a program logic diagram generation module, which is used to connect the condition nodes, branch nodes and exit nodes corresponding to the logical branch conditions according to the execution logic of the target source code to obtain a program logic diagram; an abnormal logic tree generation module, which is used to retain the abnormal nodes and the branch nodes corresponding to the abnormal nodes in the program logic diagram to obtain a program abnormal logic tree.

[0007] Optionally, the above-mentioned program logic diagram generation module is also used to: determine the entry node according to the target source code, wherein the entry node is used to indicate the input of the target source code; determine the first logical branch condition after the input based on the execution logic of the target source code, and connect the entry node and the conditional node corresponding to the first logical branch condition; traverse M logical branch conditions and perform the following operations: connect the conditional node corresponding to the i-th logical branch condition with the branch node corresponding to the i-th logical branch condition, and determine the category of the branch node, wherein the branch node corresponding to the abnormal node is a normal branch node, and the branch node corresponding to the normal node is an abnormal branch node, i is an integer greater than 0 and less than or equal to M, and M is an integer greater than 0; connect at least one abnormal branch node with its corresponding abnormal node; when i is less than M, connect the normal branch node with the conditional node corresponding to the i+1-th logical branch condition; when i is equal to M, connect the normal branch node with the normal node.

[0008] Optionally, the above-mentioned program logic diagram generation module is also used to: determine the execution order of M logical branch conditions according to the execution logic of the target source code, and sequentially number the conditional nodes corresponding to each of the M logical branch conditions according to the execution order; traverse the M logical branch conditions, and perform the following operations: sequentially number the branch nodes corresponding to the conditional node corresponding to the nth logical branch condition according to the target source code, where n is an integer greater than 0 and less than or equal to M; when n is equal to M, sequentially number the exit nodes according to the serial numbers of the corresponding branch nodes.

[0009] Optionally, the abnormal logic tree generation module is further configured to: retain abnormal nodes and branch nodes corresponding to the abnormal nodes in the program logic diagram; and uniformly number the abnormal nodes and branch nodes according to their numbers.

[0010] Optionally, the above-mentioned data analysis unit includes: an image information acquisition module, which is used to obtain current image information of the target terminal running the target source code when the target source code runs to the target node; and a data analysis module, which is used to send the current image information to the data analysis terminal.

[0011] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the above-mentioned program detection method when running.

[0012] According to another aspect of the embodiments of the present application, a computer program product is provided, comprising a computer program / instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program / instructions from the computer-readable storage medium and executes the computer program / instructions, causing the computer device to perform the program detection method described above.

[0013] According to another aspect of the embodiments of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the program detection method through the computer program.

[0014] In an embodiment of the present application, the target source code corresponding to the program to be tested is determined, and a program exception logic tree is generated based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset abnormal situation during the operation of the target source code; at least one target node is determined among the branch nodes and the preset exception nodes of the program exception logic tree; the program to be tested is run, and when the target source code runs to the target node, the current log data of the target node is collected, and the collected log data is sent to the data analysis terminal; when the target source code runs through each target node or the target source code runs to the end, the program detection result returned by the data analysis terminal is received. In the case of a target source code that needs to be detected, a program exception logic tree can be generated based on the target source code, which only involves the node and code relationship corresponding to the abnormal state. Any node therein can be determined as a target node. When the program runs to the target node, it indicates that the program is in an abnormal state. The log data of the current program can be recorded, and the program can be detected based on the log data to obtain the detection result. This approach avoids acquiring large amounts of program data and instead captures only the data needed to detect the problem. This reduces the amount of data the terminal needs to send and improves detection efficiency. Furthermore, this method addresses the significant data resource consumption associated with vehicle program detection methods provided by related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0016] Figure 1 is a schematic diagram of a hardware environment of an optional program detection method according to an embodiment of the present application;

[0017] Figure 2 is a flowchart of an optional program detection method according to an embodiment of the present application;

[0018] Figure 3 is a schematic diagram of an optional program logic diagram according to an embodiment of the present application;

[0019] Figure 4 is a schematic diagram of an optional program exception logic tree according to an embodiment of the present application;

[0020] Figure 5 is a schematic diagram of another optional program exception logic tree according to an embodiment of the present application;

[0021] Figure 6 is a schematic diagram of another optional program detection method according to an embodiment of the present application;

[0022] Figure 7 is a schematic diagram of an optional program detection device according to an embodiment of the present application;

[0023] Figure 8 is a schematic diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0026] According to one aspect of the embodiments of the present application, a program detection method is provided. As an optional implementation, the program detection method can be applied to, but is not limited to, Figure 1 Optionally, the above program detection method can be applied to a vehicle terminal. Figure 1A side view of a vehicle terminal 101 is shown, which is positioned on and capable of traversing a travel surface 113. The vehicle terminal 101 includes an onboard navigation system 103, a computer-readable storage device or medium (memory) 102 including a digitized road map 104, a spatial monitoring system 117, a vehicle controller 109, a GPS (Global Positioning System) sensor 110, an HMI (Human / Machine Interface) device 111, and also includes an autonomous controller 112 and a telematics controller 114. The vehicle terminal 101 may include, but is not limited to, commercial vehicles, industrial vehicles, agricultural vehicles, passenger vehicles, all-terrain vehicles, personal mobile devices, robots, and similar forms of mobile platforms for the purposes of this application.

[0027] In one embodiment, the spatial monitoring system 117 includes: one or more spatial sensors and systems arranged to monitor the visible area 105 in front of the vehicle terminal 101; and a spatial monitoring controller 118. The spatial sensors used to monitor the visible area 105 include, for example, a lidar sensor 106, a radar sensor 107, a camera 108, and the like. The placement of the spatial sensors allows the spatial monitoring controller 118 to monitor traffic flow, including approaching vehicles, intersections, lane markings, and other objects surrounding the vehicle terminal 101. The spatial sensors of the spatial monitoring system 117 may include object positioning sensing devices. The lidar sensor 106 uses pulsed and reflected laser beams to measure the range or distance to an object. The radar sensor 107 uses radio waves to determine the range, angle, and / or speed of an object. The camera 108 includes an image sensor, a lens, and a camera controller.

[0028] The camera 108 is advantageously mounted and positioned on the vehicle terminal 101 in a position that allows it to capture images of the visible area 105, wherein at least a portion of the visible area 105 includes a portion of the travel surface 113 in front of the vehicle terminal 101 and including the trajectory of the vehicle terminal 101. The visible area 105 may also include the surrounding environment. Other cameras (not shown) may also be used, for example, including a second camera disposed on the rear or side portion of the vehicle terminal 101 to monitor the rear of the vehicle terminal 101 and one of the right or left sides of the vehicle terminal 101.

[0029] The autonomous controller 112 is configured to implement autonomous driving or advanced driver assistance system (ADAS) vehicle functionality. Such functionality may include a vehicle onboard control system capable of providing a certain level of driving automation. Driving automation may include a range of dynamic driving and vehicle operations. Driving automation may include simultaneous automatic control of vehicle driving functions (including steering, acceleration, and braking), wherein the driver relinquishes control of the vehicle for a period of time during the journey. Driving automation may include simultaneous automatic control of vehicle driving functions (including steering, acceleration, and braking), wherein the driver relinquishes control of the vehicle terminal 101 for the entire journey. Driving automation includes hardware and a controller configured to monitor the spatial environment under various driving modes to perform various driving tasks during dynamic vehicle operations. By way of non-limiting example, autonomous vehicle functions include adaptive cruise control (ACC) operations, lane guidance and lane keeping operations, lane change operations, steering assist operations, object avoidance operations, parking assist operations, vehicle braking operations, vehicle speed and acceleration operations, and vehicle lateral motion operations, for example, as part of lane guidance, lane keeping, and lane change operations.

[0030] The autonomous controller can be equipped with an operating system and an autonomous driving system. The operating system can be responsible for managing the hardware resources (including sensors, system buses, networks, etc.) of the vehicle terminal 101 and scheduling computing resources. The autonomous driving system can implement various algorithms required for autonomous driving, including positioning, environmental perception, path planning and control, and can make decisions in situations such as driving on curves, driving in straight lines, driving in complex road conditions, and changing lanes.

[0031] When the vehicle terminal 101 is used to detect the program to be tested, steps S1-S4 can be executed in the vehicle terminal 101 to determine the target source code corresponding to the program to be tested, and generate a program exception logic tree based on the target source code; determine at least one target node among the branch nodes and exception nodes of the program exception logic tree; run the program to be tested, and collect current log data when the target source code runs to the target node; when the log data of at least one target node is collected, send at least one log data to the data analysis terminal, and receive the program detection result returned by the data analysis terminal.

[0032] The vehicle terminal 101 may include a telematics controller 114 that includes a wireless telematics communication system capable of off-vehicle communications, including communications with a communication network 115 having both wireless and wired communication capabilities. Alternatively or additionally, the telematics controller 114 may directly perform off-vehicle communications by communicating with an off-board server 116 via the communication network 115.

[0033] In an embodiment of the present application, a target source code corresponding to a program to be tested is determined, and a program exception logic tree is generated based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one exception node, and the exception node is used to indicate an abnormal situation during the operation of the target source code; at least one target node is determined among the branch nodes and the exception node of the program exception logic tree; the program to be tested is run, and when the target source code runs to the target node, current log data is collected, wherein the current log data is used to indicate the current data of the target node; when the log data of at least one target node is collected, at least one log data is sent to a data analysis terminal, and the program detection result returned by the data analysis terminal is received. In the case of a target source code that needs to be detected, a program exception logic tree can be generated based on the target source code, which only involves the node and code relationship corresponding to the abnormal state, and any node therein can be determined as a target node. When the program runs to the target node, it indicates that the program is in an abnormal state, and the log data of the current program can be recorded, and the program is detected based on the log data to obtain a detection result. In this way, it is possible to avoid obtaining a large amount of program data and only obtain data that is effective for detecting the problem, thereby reducing the amount of data that the terminal needs to send and improving detection efficiency. Furthermore, the above method solves the technical problem that the vehicle program detection method provided by the related art consumes a lot of data resources.

[0034] In an optional embodiment, if Figure 2 As shown, the above program detection method includes the following steps:

[0035] S202, determining a target source code corresponding to the program to be tested, and generating a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset exception condition during the execution of the target source code;

[0036] It should be noted that the target source code may refer to the source code of the program to be tested, which is the basis for analyzing and generating the exception logic tree.

[0037] The program exception logic tree is an abstract tree-like data structure used to summarize and represent possible exception paths within program code. It consists of multiple branch nodes and exception nodes, each representing an execution path or an exception exit point during code execution. Branch nodes represent different exception paths within the exception logic tree. Exception nodes, also known as exception exit points or exception termination points, identify the point in code execution where an exception is detected and output results.

[0038] In an alternative implementation, the source code of a software program is first identified, which will be the target of testing and analysis. Then, by analyzing the structure and logic of the target source code, an exception logic tree model is constructed. This model depicts the various exception paths that the program may encounter during execution. By constructing the exception logic tree, it is possible to systematically analyze and understand the points in the code where exceptions may occur, as well as the program's handling flow after an exception occurs. This tree structure not only helps identify potential error sources but also guides test case design, ensuring that all possible exception paths are covered, thereby improving software quality.

[0039] It should be noted that pre-defined exception nodes are a series of code locations that programmers pre-define during the development phase based on a deep understanding of program logic and potential risk points. These locations are typically parts of the program that are prone to errors or require special handling, such as array out-of-bounds errors, pointer null references, memory allocation failures, and file open errors.

[0040] In an optional implementation, when developers are writing code, they have already set up logging or exception handling code at some obvious abnormal points, such as network connection checks, resource adequacy checks, etc. These preset nodes can be checked and recorded at specific locations in the program (such as function entries and exits, before and after important operations). At the same time, the system will continue to monitor the usage status and performance indicators of key resources, such as CPU load, memory usage, network latency, etc., during operation. If any indicator is detected to be out of the normal range, such as a sudden surge in CPU load or memory usage reaching the upper limit, the system will automatically identify these locations as abnormal nodes and record relevant information. The preset and dynamically identified abnormal nodes can be combined to construct an abnormal logic tree. The preset abnormal nodes serve as fixed branch points of the tree, while the dynamically identified abnormal nodes serve as branches that may be added or changed in the tree, enriching the coverage of abnormal monitoring.

[0041] Example 1:

[0042] Assume there is a simple temperature control system program, the generated program exception logic tree can be:

[0043] Entry Node (SN): Start of the temperatureControl function.

[0044] Branch condition 1: the return value of the readTemperatureSensor() function.

[0045] Branch node PN11: Sensor reading failed.

[0046] Branch node PN12: Sensor reading successful.

[0047] Branch condition 2 (in PN12): the judgment result of isTemperatureHigh().

[0048] Normal branch PN21: The temperature is high, turn on the cooling system.

[0049] Abnormal branch AN1: Temperature sensor failure, record error, and handle the failure.

[0050] Abnormal branch AN2: sensor reading fails, record the error, and handle the fault.

[0051] Exception exit EN: Based on whether an exception occurs, the program completes normally or the termination point after exception handling.

[0052] S204, determining at least one target node from among the branch nodes of the program exception logic tree and the preset exception nodes;

[0053] It should be noted that the program exception logic tree can be constructed based on the program source code, focusing on the tree structure of the program exception path. It consists of a series of nodes, including StartNode (entry node), ProcessNode (process node) and EndNode (exit node), with special attention paid to the exception branch.

[0054] A branch node (ProcessNode) can be a node in the program exception logic tree that represents a conditional judgment or logical selection. They represent different possible exception paths in the program execution flow. An exception node (EndNode) can be a terminal node in the exception logic tree, representing the end point of program exception execution, i.e., the exception exit. A target node can be a branch node or exception node selected in the program exception logic tree with special monitoring or logging requirements. These nodes are selected based on the problem analysis requirements and testing strategy.

[0055] In an optional embodiment, the target node can be determined based on specific technical requirements, system scale, performance indicators, and test objectives. For example, it can be determined based on the following target parameters:

[0056] Code coverage: Ensure that target nodes cover a certain percentage of code logic. For example, target nodes should cover at least 80% of critical code paths and major functional modules. This is because critical code paths and major functional modules are often crucial for system stability and correctness, and monitoring them effectively identifies most potential issues. The specific coverage can be adjusted based on the complexity and criticality of the project. For systems with high reliability requirements, such as aerospace and medical equipment, higher coverage, even approaching 100%, may be required.

[0057] Abnormal frequency and criticality: For abnormal branches that occur frequently or may lead to serious consequences, target nodes should be set as a priority. For example, through historical data analysis, it is determined that abnormal branches that have occurred more than a certain threshold (such as 100 times) in the past month, or abnormal branches that may cause serious consequences such as system crashes, data loss, and security vulnerabilities, must be set as target nodes. This quantitative standard helps to concentrate monitoring resources and focus on those parts that have the greatest impact on system operations. For example, in an e-commerce system, abnormal branches with payment failures may occur a certain number of times every day. If this number exceeds the set threshold, it is necessary to pay special attention and set a target node to record the relevant information in detail to quickly locate and resolve the problem.

[0058] System performance indicators: From the perspective of system performance, the setting of target nodes should not exceed the performance capacity of the system. For example, it is stipulated that the total data collection volume of the target nodes cannot exceed 20% of the system memory capacity, or the impact of data collection and processing of the target nodes on the system CPU utilization cannot exceed 10%. This is because too many target nodes may increase the burden on the system and affect its normal operation. At the same time, it is necessary to ensure that the target nodes can effectively help analyze performance bottlenecks. For example, in a telecommunications system with high real-time requirements, when the system experiences increased response delays, it is necessary to set up pre-buried points in key signal processing and transmission links. By analyzing the data collected by these target nodes, it is necessary to determine which link has performance problems, such as the signal processing algorithm taking too long or insufficient data transmission bandwidth.

[0059] System complexity and module division: Determine the number and distribution of target nodes based on the system's complexity and module division. For example, for a large distributed software system, each module should have a certain number of target nodes, and the number can be determined based on the module's complexity and functional importance. Generally speaking, the complexity of a module can be measured by indicators such as the number of lines of code, the number of functions, and the number of classes. For example, if a module has more than 100,000 lines of code or contains more than 100 classes, then a relatively large number of target nodes may be required to fully monitor its operation. At the same time, the distribution of target nodes for different modules should also be reasonably balanced to avoid concentrating on a certain module while ignoring other modules.

[0060] In an optional implementation, constructing a program exception logic tree is a key technical preparation when performing software testing and exception analysis. This tree structure covers all possible exception paths of the program, from program startup or the beginning of a functional module (StartNode) to the end of exception handling (EndNode exception). In the exception logic tree, branch nodes (ProcessNode) represent conditional judgment points during program execution, which may cause the program to enter a normal or abnormal subsequent path. In order to efficiently monitor and analyze exceptions, some of these branch nodes and exception nodes can be selected as target nodes.

[0061] S206, running the program to be tested, and when the target source code runs to the target node, collecting the current log data of the target node, and sending the collected log data to the data analysis terminal;

[0062] It should be noted that the program under test is typically a software module in an onboard ECU. Log data can be data collected by the system when the program runs to the target node, reflecting the current program status and operating environment, including but not limited to system time, variable values, resource usage, etc.

[0063] In an alternative implementation, the program under test (i.e., the software module in the vehicle's ECU) is first launched and executed. The system then continuously monitors the program's execution until it reaches a predefined target node. Once the program reaches the target node, current log data is collected and recorded. This data contains information about the program's immediate state and environment at the target node.

[0064] In an optional embodiment, after determining the target node in step S204, detection code can be inserted into the target node to determine the information carried by the data node, such as basic information such as the node identifier and timestamp, as well as other data content added based on the source code of the program to be tested. The detection code is inserted at the target node location. When the program runs to this point, the detection code will record the data snapshot at this time and place, i.e., log data, in a predefined data node format.

[0065] In an optional embodiment, the data recorded in the log data can be designed as needed, such as:

[0066] Node ID: Uniquely identifies a data node, facilitating quick indexing and location. Node IDs are described in detail below and are not detailed here.

[0067] Timestamp: Records the exact time when data was captured, helping to build a timeline of the problem.

[0068] System status information: Record key variables, parameters and status data based on program characteristics and monitoring objectives.

[0069] Resource utilization data: Integrate resource data such as CPU and memory usage to help evaluate program resource consumption.

[0070] Communication data: For communication-intensive programs, record communication protocols, message content, and network status to facilitate optimization of communication logic.

[0071] User operation data: records user operation events and parameters, analyzes user behavior and its impact on the program.

[0072] In-vehicle data: Add sensor data (such as temperature and voltage) and bus communication data to comprehensively evaluate vehicle startup performance, assisting with fault location and performance optimization.

[0073] By selecting target nodes in the target source code and implementing tracking, the system can dynamically monitor the program's runtime status, particularly at branch points that may trigger exceptions. When the execution flow of the program under test reaches these target nodes, the system automatically collects log data, including but not limited to the current time, variable states during program runtime, and resource usage information. The collected log data is then formatted and stored for subsequent analysis and testing. This approach not only monitors abnormal program behavior but also captures the specific time and context of the exception, greatly simplifying problem location and repair.

[0074] S208 , when the target source code has run through each target node or the target source code has finished running, receiving the program detection result returned by the data analysis terminal.

[0075] It should be noted that a data analysis terminal can refer to a client application, web service, or specific server that receives log data and performs in-depth analysis to detect possible anomalies or errors in program execution. Program detection results can be the results returned by the data analysis terminal after analyzing log data, and contain diagnostic information about the program's operation status, such as the cause of the anomaly, the time of occurrence, and the scope of impact.

[0076] In an optional embodiment, when the program runs to the target node, the program log server running in the tested software operating environment collects log data through pre-inserted detection code, and outputs the collected data to the client or browser. When the program is executed to the pre-set target node, the program log server collects the relevant log data through the previously inserted detection code. After collecting this data, it will be sent to the client or browser for subsequent analysis and viewing.

[0077] After receiving log data, the log data analysis program client or browser first parses the data to obtain the node data. It then searches for the node's location within the program's exception logic tree. This search eliminates the need to traverse the tree; the node ID directly indexes the location. Combined with the data snapshot of the exception site carried in the node, the analysis determines the time and cause of the problem.

[0078] After log data analysis is complete, statistics can be generated by project name, software module, frequency of occurrence, cause, time, severity, and other factors, and output in the form of charts. Once log data analysis is complete, the results can be summarized by various dimensions, such as project name, software module involved, frequency of occurrence, cause, time of occurrence, and severity. These statistical results can then be displayed in the form of charts for a more intuitive presentation of the analysis results, making it easier for developers, testers, and other relevant personnel to understand and evaluate program performance.

[0079] In an embodiment of the present application, a target source code corresponding to a program to be tested is determined, and a program exception logic tree is generated based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one exception node, and the exception node is used to indicate an abnormal situation during the operation of the target source code; at least one target node is determined among the branch nodes and the exception node of the program exception logic tree; the program to be tested is run, and when the target source code runs to the target node, current log data is collected, wherein the current log data is used to indicate the current data of the target node; when the log data of at least one target node is collected, at least one log data is sent to a data analysis terminal, and the program detection result returned by the data analysis terminal is received. In the case of a target source code that needs to be detected, a program exception logic tree can be generated based on the target source code, which only involves the node and code relationship corresponding to the abnormal state, and any node therein can be determined as a target node. When the program runs to the target node, it indicates that the program is in an abnormal state, and the log data of the current program can be recorded, and the program is detected based on the log data to obtain a detection result. In this way, it is possible to avoid obtaining a large amount of program data and only obtain data that is effective for detecting the problem, thereby reducing the amount of data that the terminal needs to send and improving detection efficiency. Furthermore, the above method solves the technical problem that the vehicle program detection method provided by the related art consumes a lot of data resources.

[0080] In an optional embodiment, a program exception logic tree is generated based on the target source code, including: determining at least one logic branch condition corresponding to the target source code, wherein the logic branch condition is used to indicate the conditions for executing different code blocks based on current log data; determining branch nodes corresponding to each of the at least one logic branch condition, and determining exit nodes corresponding to each of the branch nodes, wherein the exit nodes include abnormal nodes and normal nodes, and the exit nodes are used to indicate the termination point of the current branch node; connecting the condition nodes, branch nodes, and exit nodes corresponding to the logic branch condition according to the execution logic of the target source code to obtain a program logic diagram; retaining the abnormal nodes and the branch nodes corresponding to the abnormal nodes in the program logic diagram to obtain a program exception logic tree.

[0081] It should be noted that logical branch conditions are conditional judgments used in programs to determine the execution path, such as if, else, and switch-case. A branch node can be the location where a logical branch begins in the code, corresponding to the logical branch condition. An exit node can be the end point of the branch logic and is divided into exception nodes and normal nodes. Exception nodes represent abnormal situations that occur during code execution, while normal nodes indicate that the code executes normally to the end. An exception node can be the exit point of a program when it encounters an abnormal situation, such as a function error return, resource exhaustion, or illegal operation. A normal node can be the point where a program executes to the end without encountering any exceptions. A conditional node can be a node containing logical branch conditions, used to determine different paths for program execution. A program logic diagram can be a diagram that graphically represents the program execution process, including the connection relationship between conditional nodes, branch nodes, and exit nodes.

[0082] In an optional implementation, an in-depth analysis of the target source code can be performed to identify all possible logical branch points. These branch conditions are used to determine whether to execute a certain code block or jump to another code block, and are the core of the program's dynamic behavior. After identifying the logical branch conditions, it is necessary to determine the branch node when each condition is triggered, that is, the starting point of a new logical path that may be entered in the code. At the same time, for each branch node, its corresponding exit node must also be determined. The exit node indicates the end point of the current logical path and may be a normal node or an abnormal node.

[0083] The above analysis results are displayed in the form of a graph, clearly showing the connections between conditional nodes, branch nodes, and exit nodes, forming a complete program logic flow chart. From the complete program logic chart, all nodes related to exception handling are filtered out, namely the exception node and its direct or indirect branch nodes, to form a dedicated exception logic tree. This tree will be used for exception monitoring, helping to quickly locate and analyze the specific location and cause of the exception.

[0084] Example 2:

[0085] Suppose you are analyzing the source code of the volume control module in a car entertainment system. The goal is to monitor and analyze abnormal situations that may be encountered during the volume adjustment process.

[0086] In an optional embodiment, the source code of the volume control module is first reviewed to identify key logic branch conditions, such as checking whether the volume adjustment button is pressed (if (volumeButtonPressed)) and whether the volume exceeds the limit (if (volume>maxVolume)).

[0087] For the condition of whether the volume button is pressed, the branch node BN1 (volume button pressed) is determined, and its exit nodes are further determined to include normal node EN1 (volume adjustment successful) and abnormal node AN1 (volume adjustment button failure). For the condition of whether the volume exceeds the limit, the branch node BN2 (volume exceeds the limit) and exit node AN2 (volume exceeds the limit, the module needs to handle the exception) are determined.

[0088] Next, the analysis results were graphically represented, including nodes such as BN1, BN2, EN1, AN1, and AN2, and their connections, to form a complete logic diagram for the volume control module program. Finally, the nodes associated with the abnormality, AN1 and AN2, and their upstream branch nodes BN1 and BN2, were filtered from the program logic diagram to construct a specialized abnormality logic tree for the volume control module.

[0089] Through the above-mentioned implementation of this application, a program exception logic tree is generated from the target source code. This tree will serve as the basis for exception monitoring and analysis, helping developers to more effectively solve problems and optimize the system. This will facilitate subsequent exception monitoring and analysis, and improve the stability of the vehicle system.

[0090] In an optional embodiment, conditional nodes, branch nodes, and exit nodes corresponding to logical branch conditions are connected according to the execution logic of the target source code to obtain a program logic diagram, including: determining an entry node according to the target source code, wherein the entry node is used to indicate an input of the target source code; determining a first logical branch condition after the input based on the execution logic of the target source code, and connecting the entry node and the conditional node corresponding to the first logical branch condition;

[0091] Traverse the M logical branch conditions and perform the following operations: connect the conditional node corresponding to the i-th logical branch condition with the branch node corresponding to the i-th logical branch condition, and determine the category of the branch node, where the branch node corresponding to the abnormal node is a normal branch node, and the branch node corresponding to the normal node is an abnormal branch node, i is an integer greater than 0 and less than or equal to M, and M is an integer greater than 0; connect at least one abnormal branch node with its corresponding abnormal node; when i is less than M, connect the normal branch node with the conditional node corresponding to the i+1-th logical branch condition; when i is equal to M, connect the normal branch node with the normal node.

[0092] It should be noted that the entry node (SN) can be the first point where the program starts to execute and is also the starting point for constructing the program logic graph.

[0093] In an alternative implementation, the starting point of the program can be determined from the target source code. This starting point will become the first node in constructing the program logic graph. The source code is analyzed to find the first decision point in the program execution, which will determine the subsequent execution path of the program.

[0094] A program may have multiple logical branch conditions. During the traversal process, for each logical branch condition, the corresponding condition node is connected to the branch node to form a logical link. The program then determines whether the branch node connected to the condition node is a normal branch node or an abnormal branch node. The abnormal branch node is ensured to ultimately lead to the abnormal node, completing the abnormal path. A normal branch node guides the program to the next logical branch condition, i.e., the subsequent program flow. When all logical branch conditions have been processed, the normal branch node leads to the normal end of the program.

[0095] Through the above-described implementation of this application, the program's execution logic is extracted from the target source code, and a program logic diagram is constructed. The logical branch conditions, conditional nodes, branch nodes, and exit nodes are clearly defined and connected to show the program's normal and abnormal execution paths. Traversing the logical branch conditions and classifying the nodes are key steps in constructing the program logic diagram, ensuring its accuracy and completeness.

[0096] In an optional embodiment, after connecting the normal branch node with the normal node, the method further includes: determining an execution order of the M logical branch conditions according to the execution logic of the target source code, and sequentially numbering the conditional nodes corresponding to each of the M logical branch conditions according to the execution order;

[0097] Traverse the M logical branch conditions and perform the following operations: sequentially number the branch nodes corresponding to the conditional node corresponding to the nth logical branch condition according to the target source code, where n is an integer greater than 0 and less than or equal to M; when n is equal to M, sequentially number the exit nodes according to the sequence numbers of their corresponding branch nodes.

[0098] It should be noted that normal branch nodes are nodes in the program logic diagram that represent the normal logic flow. They typically do not directly point to exception handling logic, but rather to the regular execution of the program. Normal nodes are nodes that handle the normal program execution flow and can be considered normal branches in the program logic, reflecting the normal operation path of the software when no exceptions are encountered.

[0099] In an optional embodiment, M logical branch conditions are identified and determined based on the actual execution flow of the target source code, where M represents the total number of identified branch conditions. A unique sequence number is assigned to each conditional node (i.e., decision point) corresponding to each logical branch condition, in accordance with the order in which these conditions are executed in the source code, to ensure that the order of the conditional nodes is consistent with their execution order in the source code.

[0100] Traverse each of the M logical branch conditions one by one. When the nth logical branch condition is reached, sequentially number the corresponding branch nodes, ensuring that each branch node's number is logically related to the number of its parent condition node. In particular, when n equals M, that is, after traversing all logical branch conditions, sequentially number the program's exit nodes (including normal and abnormal exits). These numbers should reflect their relationship to the branch nodes to facilitate subsequent analysis and problem location.

[0101] Figure 3 is a schematic diagram of an optional program logic diagram according to an embodiment of the present application; after determining the target source code corresponding to the program to be detected, the branch conditions in the target source code can be identified, and the conditional node corresponding to the first branch condition (such as Figure 3 The branch condition 1 shown is connected to the entry node. Then the condition node can be connected to the corresponding branch node (such as Figure 3 As shown in the abnormal branch 1, normal branch 1, abnormal branch 2). Connect the branch node corresponding to the normal branch to the condition node corresponding to the next branch condition (such as Figure 3 The branch condition 2 shown in FIG2 is connected, and the branch condition 2 is connected to the corresponding branch node (as shown in FIG2 ). Figure 3As shown in the abnormal branch 3, abnormal branch 4, normal branch 2). In the absence of conditional nodes, connect all the branch nodes corresponding to the abnormal branches with the corresponding abnormal exits. This will give a preliminary program logic diagram after the nodes are connected. Then, you can number each node in the logic diagram. You can first number the conditional nodes in the order in which the branch conditions appear, such as Figure 3 Then determine the branch conditions connected to each branch node and number them according to the order in which they appear in the target source code. Figure 3 The three branch nodes corresponding to the branch condition 1 shown may appear in the order of abnormal branch 1, normal branch 1, and abnormal branch 2. Then, they may be numbered as PN11, PN12, and PN13, corresponding to the branch condition and the order thereof.

[0102] Through the above-mentioned implementation mode of the present application, in the process of constructing the program logic diagram, by analyzing the execution logic of the target source code, all possible logical branch conditions are found, and are numbered according to the execution order of these conditions in the source code. Secondly, all logical branch conditions are traversed, and the branch nodes after each conditional node are numbered to reflect their position and order in the program logic diagram. Finally, after processing all conditional nodes, the exit nodes of the program are numbered to ensure that the number of each exit node is consistent with the number of its upstream branch node. Doing so not only clearly displays the execution flow of the program, but also facilitates tracing the specific path when an exception occurs, thereby improving the efficiency and accuracy of exception analysis.

[0103] In an optional embodiment, the abnormal nodes and the branch nodes corresponding to the abnormal nodes in the program logic diagram are retained to obtain a program abnormality logic tree, including: retaining the abnormal nodes and the branch nodes corresponding to the abnormal nodes in the program logic diagram; and uniformly numbering the abnormal nodes and the branch nodes according to the numbers of the abnormal nodes and the branch nodes.

[0104] It should be noted that after obtaining the program logic diagram, the abnormal nodes and the branch nodes corresponding to the abnormal nodes in the program logic diagram can be retained, that is, the conditional nodes, normal nodes and their corresponding branch nodes can be deleted.

[0105] Figure 4 is a schematic diagram of an optional program exception logic tree according to an embodiment of the present application; Figure 4 As stated, Figure 4 Can be based on Figure 3 The program logic diagram is obtained by deleting nodes, which will Figure 3 Delete Conditional Branch 1, Conditional Branch 2, Normal Branch 2, and Normal Exit 1. Retain the remaining nodes. The node numbers remain unchanged.

[0106] It should be noted that the nodes in the program exception logic tree can be uniformly numbered. In the huge program logic, each node has a unique number. Developers or testers can quickly find the corresponding node based on the number, without having to search line by line in the complex code, which greatly saves time and improves efficiency. And after the numbering is unified, data storage and retrieval are more convenient. When the server collects log data, the data can be classified and stored according to the number, and the corresponding node data can be quickly extracted by number for subsequent analysis. Moreover, the numbering makes the data association clearer, and can easily integrate node data with related system status, user operations and other information to analyze the problem in all aspects. The number provides an accurate reference for problem tracking, records the node number where the problem occurs, and developers can quickly focus on the abnormal location and obtain detailed information based on the number, such as system status, variable values, etc., to deeply analyze the root cause, fix the problem in a targeted manner, and verify the repair effect.

[0107] Figure 5 is a schematic diagram of another optional program exception logic tree according to an embodiment of the present application; Figure 5 As shown, it can be Figure 4 The program exception logic tree in the program is numbered. Figure 4 The nodes of each layer are numbered according to the tree-like levels that have been formed. Figure 4 In the example, if abnormal branch 1, normal branch 1, and abnormal branch 2 are located at the same level, they can be numbered in sequence (ND11, ND12, ND13). This sequence can also be the order in which they appear in the target source code.

[0108] In an optional implementation, after obtaining the program exception logic tree, the target node can be determined in the program exception logic tree. The following provides different methods for selecting the target node based on actual application scenarios:

[0109] 1. Testing scenarios for specific functions or abnormal branches (select only ND11 nodes as target nodes):

[0110] In an automotive software system, suppose a new processing branch (PN11) has been developed to handle startup failures of the vehicle's stop-start system in specific low-temperature environments. Developers initially suspect that a misjudgment in the battery voltage detection process in low-temperature environments is causing the stop-start system to fail to start properly. The target node is then set to the PN11 node of this low-temperature startup failure processing branch. When the vehicle is in a low-temperature environment and the stop-start system fails to start, the system triggers this pre-buried point and records information such as the battery voltage value at that time, ambient temperature sensor data, the current status of the stop-start system (such as motor speed, relay status, etc.), and the system timestamp. Using this data, developers can accurately analyze whether there is a problem with the battery voltage detection algorithm in low-temperature environments, thereby determining whether the sensor data is inaccurate, the voltage judgment threshold is improperly set, or there is an error in other related control logic.

[0111] A software upgrade for the in-vehicle infotainment (IVI) system primarily improved the voice recognition module's dialect recognition capabilities. To ensure the correctness of this new functionality, developers focused on the dialect processing branch (PN11) of voice recognition. A target node was set at the PN11 node of this dialect processing branch. When a user inputs a voice command in a specific dialect, the system records information such as the audio feature parameters of the voice input, the recognition result, the degree of match with the standard dialect voice library, and the recognition time at the PN11 node. By analyzing this data, developers can quickly determine whether the newly upgraded dialect recognition function has achieved the expected recognition accuracy and whether there are any issues such as dialect confusion or recognition timeouts.

[0112] 2. Scenario for comprehensive detection of the entire logical link (selecting ND01, ND12, ND22, and ND31 as target nodes):

[0113] In electric vehicle automated parking systems, automated parking is a complex process. This process begins with the vehicle searching for a parking space (SN), progresses through parking space detection and identification (ND12), calculation of the relative position between the vehicle and the space (ND22), vehicle trajectory planning and control (ND31), and ultimately completes parking (EN3). Target nodes are set at the four nodes ND01, ND12, ND22, and ND31 within the automated parking function's logical chain. During the automated parking process, the system records key data at each target node. For example, the ND01 node records the vehicle's speed and the status of surrounding environmental sensing devices (such as ultrasonic sensors and cameras) when the automated parking function is activated. The ND12 node records the identified parking space type (perpendicular, parallel, etc.), space dimensions, and the initial relative position between the space and the vehicle. The ND22 node records control parameters such as the real-time relative distance and angle between the vehicle and the space, the vehicle's steering angle, and speed. The ND31 node records the final parking position accuracy and the time taken to complete the parking operation. By analyzing the data from each node in the entire link, developers can fully understand the execution process of the automatic parking function. For problems such as parking space recognition errors and excessive vehicle control deviations, they can quickly locate which link has the problem and perform targeted optimization.

[0114] Within the intelligent connected vehicle ecosystem, remote vehicle control involves the coordinated operation of multiple software modules. Starting with a user sending a remote air conditioning start command (SN) via a mobile app, the command is received by the vehicle's communication module (ND12), forwarded by the gateway module (ND22), and executed by the air conditioning control module (ND31), ultimately completing the air conditioning start (EN3). Target nodes are set at these four nodes in the entire logical link for remote air conditioning start. As the vehicle receives and executes remote commands, the system records relevant data at each node. For example, node ND12 records the command content, signal strength, and response time received by the communication module; node ND22 records the gateway module's command parsing results, forwarding port, and protocol information; and node ND31 records the command parameters received by the air conditioning control module, the air conditioning target temperature, fan speed setting, and compressor operating status. By analyzing this data, developers can gain a comprehensive understanding of the flow of remote control commands between modules and quickly identify specific issues such as command loss, forwarding delays, and module execution errors.

[0115] 3. Comprehensively test all abnormal branch scenarios (select Figure 5 All nodes in as target nodes):

[0116] Before launching a new electric vehicle battery management system (BMS) software, comprehensive testing of all exception branches is required to ensure its stability and reliability. BMS software contains numerous exception branches, such as battery overcharge protection exception (ND01), battery overdischarge protection exception (ND11), battery temperature anomaly (ND12), and battery cell voltage difference exception (ND21). Nodes associated with each of these exception branches are set as target nodes. During software execution, the system records detailed information for each exception branch triggered. For example, the ND01 node for battery overcharge protection anomaly records the charging current, battery voltage, overcharge protection trigger threshold, and protection action execution (such as disconnecting the charging circuit or issuing an alarm). The ND12 node for battery temperature anomaly records battery surface temperature, temperature sensor data, and cooling system status. By collecting and analyzing data from all exception branches, developers can gain a comprehensive understanding of software performance under various abnormal conditions, proactively identify potential vulnerabilities and risks, ensure stable software operation after launch, and avoid battery safety incidents caused by software anomalies.

[0117] During reliability testing of automotive software in complex environments such as high temperature, extreme cold, and high humidity, the software may encounter various unexpected anomalies. For example, in high-temperature environments, the vehicle's electronic control unit (ECU) software may experience memory overflow exceptions (ND01), communication bus anomalies (ND11), and sensor data anomalies (ND12). In cold environments, software startup anomalies (ND21), execution delay anomalies (ND22), and software freeze anomalies (ND31) may occur. All abnormal branch nodes are set as target nodes. During complex environment testing, the system records detailed environmental parameters (such as temperature and humidity) and software status information (such as memory usage, communication bus load, and task execution queue status) at each abnormal branch node. Developers can analyze this data to understand the software's abnormal performance in different extreme environments and identify areas where the software lacks adaptability to the environment. This allows them to perform targeted optimization and reinforcement, improving the software's reliability and stability in actual use.

[0118] Through the above-mentioned implementation mode of the present application, the program exception logic tree can be uniformly numbered, so that the staff can quickly focus on the exception location, combine the number to obtain detailed information, such as system status, variable values, etc., deeply analyze the root cause, repair the problem in a targeted manner, and verify the repair effect.

[0119] In an optional embodiment, before sending the collected log data to the data analysis terminal, it includes: when the target source code runs to the target node, obtaining the current image information of the target terminal running the target source code; and sending the current image information to the data analysis terminal.

[0120] It should be noted that image information can be obtained from a monitoring module outside the vehicle terminal. The monitoring module can be a key component in the system responsible for capturing live video and images through devices such as cameras when an abnormal program operation is detected.

[0121] When the program under test reaches the target node, the monitoring module captures video and images using a camera or other device. For example, during in-vehicle software testing, if a powertrain anomaly is detected, the vehicle's camera will immediately activate to record key information, including the surrounding traffic environment. The captured video and images are stored in chronological order to a designated location and made available to the test program client or browser for analysis. Proper file naming and path management are implemented during storage to ensure data traceability.

[0122] The monitoring module can be triggered by commands from the vehicle terminal. When the vehicle terminal detects that the program under test has reached the target node, it can send a command to the monitoring module to initiate data collection. This mechanism ensures timely and targeted data collection.

[0123] Through the above-described embodiments of this application, by acquiring image information from a monitoring module external to the vehicle terminal, the video and images provided by the monitoring module can intuitively reflect the on-site conditions at the time of the problem, such as the surrounding traffic environment or the operating status of industrial equipment during on-board software testing, assisting developers in analyzing the cause of the anomaly. This also enriches system diagnostic information and improves diagnostic accuracy. Combining log data with on-site information provides a comprehensive understanding of the problem and enhances system robustness.

[0124] Figure 6 is a schematic diagram of another optional program detection method according to an embodiment of the present application; Figure 6 As shown, the vehicle terminal runs a program under test 602. The vehicle terminal processor executes steps S602-S604. When the program runs to the target node, it records log data and sends the log data to the vehicle server 604. The vehicle server 604 synchronously or asynchronously executes steps S606-1 and S606-2, sends a monitoring instruction to the monitoring module 608, or sends the log data to the off-vehicle test terminal 606. The monitoring module 608 can execute step S610 to generate image information. The test terminal 606 then executes steps S608, S612, and S614 to analyze the log data, obtain image information from the monitoring module 608, and generate a detection result.

[0125] In an alternative embodiment, the tested program 602 can be the foundation of the entire monitoring and analysis process, carrying the program code to be tested and monitored. In an automotive software testing scenario, M1 might be the software in the vehicle's electronic control unit (ECU), which controls vehicle driving functions such as power output regulation and braking control. The tester's goal is to comprehensively monitor the operating status of this ECU software to promptly identify potential anomalies and ensure vehicle safety and reliability.

[0126] The onboard server 604 plays a key role as a data collector. Based on the program logic tree extracted from the program under test 602, it further accurately locates the branch logic tree where the program may be abnormal. For example, in automobile software, the program logic tree covers the logical paths for the implementation of various vehicle functions, including normal driving operation logic and some exception handling logic (such as emergency response logic in the event of system failure). It can identify these abnormal branch logic trees and set target nodes at the key nodes therein, just like setting up observation posts on the road to collect log data. When the program under test 602 runs to these target nodes, it will trigger the data collection mechanism to record the relevant information of the current program operation, providing a detailed data basis for subsequent analysis.

[0127] The core responsibility of the monitoring module 608 is to capture the on-site situation at the moment the problem occurs through devices such as cameras. When the onboard server 604 detects that the program to be tested runs to a pre-buried point, it will promptly send instructions to the monitoring module 608, prompting the monitoring module 608 to control the camera to record video and take pictures. For example, in the test of the car's automatic driving assistance system, if the onboard server 604 collects log data from a certain pre-buried point indicating that the vehicle's automatic emergency braking system has an abnormality, the monitoring module 608 will immediately activate the cameras around the vehicle and record key information such as the traffic environment around the vehicle at this time, the relative position with other vehicles or obstacles, etc. These visual data can provide an intuitive reference for the subsequent analysis of the specific cause of the abnormality, helping developers to more accurately restore the problem scenario.

[0128] The test terminal 606 can be a local platform for data analysis and presentation. It receives log data and performs comprehensive analysis based on the video / photos provided by the monitoring module. During automotive software development, developers typically run the test terminal 606 on their work computers to quickly obtain test results. After receiving log data and relevant field data, the test terminal 606 applies specific analysis algorithms to analyze the data. For example, it checks whether system parameters in the logs exceed normal ranges or analyzes whether the vehicle's driving trajectory in the video meets expectations. The test terminal 606 then presents the analysis results to developers in the form of intuitive charts and reports, helping them quickly locate problems and assess their severity.

[0129] The test terminal 606 can also focus more on remote and cloud environments in terms of usage scenarios. For automobile manufacturers, when the vehicle has been delivered to the user, but the vehicle software needs to be remotely monitored and analyzed, the test terminal 606 plays an important role. Through the browser, technical support personnel can access the log data and related on-site information sent by the vehicle on the cloud server. For example, when a vehicle has a software failure in a remote area, the user can transmit the vehicle's operating data to the automobile manufacturer's cloud server via the 4G / 5G network. The technical support personnel analyze this data on the browser side and provide the user with a preliminary diagnostic result and solution in a timely manner. This method greatly improves the efficiency of after-sales technical support and reduces user waiting time.

[0130] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0131] According to another aspect of the embodiment of the present application, a program detection device for implementing the above program detection method is also provided. Figure 7 As shown, the device includes:

[0132] An exception logic tree generating unit 702 is configured to determine the target source code corresponding to the program to be tested and generate a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset exception condition during the execution of the target source code;

[0133] A target node determining unit 704 is configured to determine at least one target node from among the branch nodes of the program exception logic tree and the preset exception nodes;

[0134] The data collection unit 706 is used to run the program to be tested, collect the current log data of the target node when the target source code runs to the target node, and send the collected log data to the data analysis terminal;

[0135] The data analysis unit 708 is configured to receive a program detection result returned by the data analysis terminal when the target source code has run through each target node or the target source code has finished running.

[0136] Optionally, the above-mentioned abnormal logic tree generation unit 702 includes: a condition determination module, which is used to determine at least one logical branch condition corresponding to the target source code, wherein the logical branch condition is used to indicate the conditions for executing different code blocks based on current log data; a node determination module, which is used to determine the branch nodes corresponding to each of the at least one logical branch conditions, and determine the exit nodes corresponding to each of the branch nodes, wherein the exit nodes include abnormal nodes and normal nodes, and the exit nodes are used to indicate the termination point of the current branch node; a program logic diagram generation module, which is used to connect the condition nodes, branch nodes and exit nodes corresponding to the logical branch conditions according to the execution logic of the target source code to obtain a program logic diagram; an abnormal logic tree generation module, which is used to retain the abnormal nodes and the branch nodes corresponding to the abnormal nodes in the program logic diagram to obtain a program abnormal logic tree.

[0137] Optionally, the above-mentioned program logic diagram generation module is also used to: determine the entry node according to the target source code, wherein the entry node is used to indicate the input of the target source code; determine the first logical branch condition after the input based on the execution logic of the target source code, and connect the entry node and the conditional node corresponding to the first logical branch condition; traverse M logical branch conditions and perform the following operations: connect the conditional node corresponding to the i-th logical branch condition with the branch node corresponding to the i-th logical branch condition, and determine the category of the branch node, wherein the branch node corresponding to the abnormal node is a normal branch node, and the branch node corresponding to the normal node is an abnormal branch node, i is an integer greater than 0 and less than or equal to M, and M is an integer greater than 0; connect at least one abnormal branch node with its corresponding abnormal node; when i is less than M, connect the normal branch node with the conditional node corresponding to the i+1-th logical branch condition; when i is equal to M, connect the normal branch node with the normal node.

[0138] Optionally, the above-mentioned program logic diagram generation module is also used to: determine the execution order of M logical branch conditions according to the execution logic of the target source code, and sequentially number the conditional nodes corresponding to each of the M logical branch conditions according to the execution order; traverse the M logical branch conditions, and perform the following operations: sequentially number the branch nodes corresponding to the conditional node corresponding to the nth logical branch condition according to the target source code, where n is an integer greater than 0 and less than or equal to M; when n is equal to M, sequentially number the exit nodes according to the serial numbers of the corresponding branch nodes.

[0139] Optionally, the abnormal logic tree generation module is further configured to: retain abnormal nodes and branch nodes corresponding to the abnormal nodes in the program logic diagram; and uniformly number the abnormal nodes and branch nodes according to their numbers.

[0140] Optionally, the data analysis unit 706 includes: an image information acquisition module for acquiring current image information of a target terminal running the target source code when the target source code runs to a target node; and a data analysis module for sending the current image information to the data analysis terminal.

[0141] Optionally, in this embodiment, the embodiments to be implemented by the above-mentioned various unit modules can refer to the above-mentioned various method embodiments, which will not be repeated here.

[0142] According to another aspect of the embodiment of the present application, an electronic device for implementing the above program detection method is also provided. The electronic device may be Figure 8 The terminal device or server shown in FIG. This embodiment is described by taking the electronic device as a terminal device as an example. Figure 8 As shown, the electronic device includes a memory 802 and a processor 804. The memory 802 stores a computer program, and the processor 804 is configured to execute the steps in any of the above method embodiments through the computer program.

[0143] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0144] Optionally, in this embodiment, the processor may be configured to execute the following steps through a computer program:

[0145] S1, determining the target source code corresponding to the program to be tested, and generating a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset abnormal situation during the operation of the target source code;

[0146] S2, determining at least one target node among the branch nodes and the preset exception nodes of the program exception logic tree;

[0147] S3: Run the program to be tested. When the target source code runs to the target node, collect the current log data of the target node and send the collected log data to the data analysis terminal.

[0148] S4, when the target source code has run through each target node or the target source code has finished running, receiving the program detection result returned by the data analysis terminal.

[0149] Alternatively, those skilled in the art will appreciate that Figure 8 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (MID), a PAD, or other terminal devices. Figure 8 It does not limit the structure of the electronic device. For example, the electronic device may also include Figure 8 More or fewer components (such as network interfaces, etc.) as shown in, or with Figure 8 Different configurations shown.

[0150] Among them, the memory 802 can be used to store software programs and modules, such as the program instructions / modules corresponding to the program detection method and device in the embodiment of the present application. The processor 804 executes various functional applications and data processing by running the software programs and modules stored in the memory 802, that is, realizing the above-mentioned program detection method. The memory 802 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 802 may further include a memory remotely located relative to the processor 804, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include but are not limited to the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 802 can be used specifically but not limited to store information such as log data. As an example, Figure 8 As shown, the memory 802 may include, but is not limited to, the abnormal logic tree generation unit 702, the target node determination unit 704, the data acquisition unit 706, and the data analysis unit 708 in the program detection device. In addition, it may also include, but is not limited to, other module units in the program detection device, which will not be repeated in this example.

[0151] Optionally, the transmission device 806 is configured to receive or send data via a network. Specific examples of the network may include a wired network and a wireless network. In one embodiment, the transmission device 806 includes a network interface controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In one embodiment, the transmission device 806 is a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.

[0152] In addition, the electronic device further includes: a display 808 for displaying whether a problem is detected; and a connection bus 810 for connecting various module components in the electronic device.

[0153] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting multiple nodes through network communication. The nodes may form a peer-to-peer (P2P) network, and any computing device, such as a server, terminal, or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0154] According to one aspect of the present application, a computer program product is provided, comprising a computer program / instructions containing program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication component and / or installed from a removable medium. When the computer program is executed by a central processing unit, the various functions provided in the embodiments of the present application are performed.

[0155] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0156] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned program detection method.

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

[0158] S1, determining the target source code corresponding to the program to be tested, and generating a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset abnormal situation during the operation of the target source code;

[0159] S2, determining at least one target node among the branch nodes and the preset exception nodes of the program exception logic tree;

[0160] S3: Run the program to be tested. When the target source code runs to the target node, collect the current log data of the target node and send the collected log data to the data analysis terminal.

[0161] S4, when the target source code has run through each target node or the target source code has finished running, receiving the program detection result returned by the data analysis terminal.

[0162] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing the hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0163] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above-mentioned computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which can be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the above-mentioned methods in each embodiment of the present application.

[0164] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0165] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the above-mentioned 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 system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0166] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0167] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0168] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A program detection method, characterized in that: include: Determining a target source code corresponding to the program to be tested, and generating a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, and the preset exception node is used to indicate a preset abnormal situation during the operation of the target source code; Determine at least one target node among the branch nodes and the preset exception nodes of the program exception logic tree; Running the program to be tested, when the target source code runs to the target node, collecting current log data of the target node, and sending the collected log data to a data analysis terminal; When the target source code has run through each target node or the target source code has finished running, a program detection result returned by the data analysis terminal is received.

2. The method according to claim 1, characterized in that The generating of a program exception logic tree according to the target source code includes: Determining at least one logical branch condition corresponding to the target source code, wherein the logical branch condition is used to indicate a condition for determining execution of different code blocks based on the current log data; Determine the branch nodes corresponding to each of the at least one logical branch conditions, and determine the exit nodes corresponding to each of the branch nodes, wherein the exit nodes include the abnormal nodes and normal nodes, and the exit nodes are used to indicate the termination point of the current branch node; Connecting the conditional nodes corresponding to the logical branch conditions, the branch nodes, and the exit nodes according to the execution logic of the target source code to obtain a program logic graph; The abnormal node and the branch node corresponding to the abnormal node in the program logic graph are retained to obtain the program abnormality logic tree.

3. The method according to claim 2, characterized in that The step of connecting the conditional nodes corresponding to the logical branch conditions, the branch nodes, and the exit nodes according to the execution logic of the target source code to obtain a program logic diagram includes: Determining an entry node according to the target source code, wherein the entry node is used to indicate an input of the target source code; Determine a first logic branch condition after input based on the execution logic of the target source code, and connect the entry node and the conditional node corresponding to the first logic branch condition; Traverse the M logical branch conditions and perform the following operations: Connecting the conditional node corresponding to the i-th logical branch condition with the branch node corresponding to the i-th logical branch condition, and determining the category of the branch node, wherein the branch node corresponding to the abnormal node is a normal branch node, and the branch node corresponding to the normal node is an abnormal branch node, i is an integer greater than 0 and less than or equal to M, and M is an integer greater than 0; connecting at least one of the abnormal branch nodes to the corresponding abnormal nodes; When i is less than M, connect the normal branch node to the conditional node corresponding to the (i+1)th logical branch condition; When i is equal to M, the normal branch node is connected to the normal node.

4. The method according to claim 3, characterized in that After the normal branch node is connected to the normal node, the method includes: Determining an execution order of the M logic branch conditions according to the execution logic of the target source code, and sequentially numbering the condition nodes corresponding to each of the M logic branch conditions according to the execution order; Traverse the M logical branch conditions and perform the following operations: Sequentially number the branch nodes corresponding to the conditional node corresponding to the nth logical branch condition according to the target source code, where n is an integer greater than 0 and less than or equal to M; When n is equal to M, the exit nodes are numbered sequentially according to the sequence numbers of their corresponding branch nodes.

5. The method according to claim 2, characterized in that The step of retaining the abnormal node and the branch node corresponding to the abnormal node in the program logic graph to obtain the program abnormality logic tree includes: retaining the abnormal node and the branch node corresponding to the abnormal node in the program logic graph; The abnormal nodes and the branch nodes are uniformly numbered according to their numbers.

6. The method according to any one of claims 1 to 5, characterized in that Before sending the collected log data to the data analysis terminal, the method includes: When the target source code runs to the target node, obtaining current image information of the target terminal running the target source code; The current image information is sent to the data analysis terminal.

7. A program detection device, characterized in that: include: an exception logic tree generating unit, configured to determine a target source code corresponding to a program to be tested, and to generate a program exception logic tree based on the target source code, wherein the program exception logic tree includes at least one branch node and at least one preset exception node, wherein the preset exception node is used to indicate a preset exception condition during the execution of the target source code; a target node determining unit, configured to determine at least one target node from among the branch nodes and the preset abnormal nodes of the program abnormality logic tree; A data collection unit is configured to run the program to be tested, collect current log data of the target node when the target source code runs to the target node, and send the collected log data to a data analysis terminal; The data analysis unit is configured to receive a program detection result returned by the data analysis terminal when the target source code has run through each target node or the target source code has finished running.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the method according to any one of claims 1 to 6 is executed when the program is executed.

9. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 6 through the computer program.

Images