Time sequence verification method and device for automobile software test log

Abstract

The invention discloses a time sequence verification method and device for an automobile software test log. The method comprises the steps that an expected log file and an actual log file are obtained, the expected log file comprises a plurality of expected log entries arranged in sequence, each entry has a plurality of structured fields, the actual log file comprises a plurality of actual log entries recorded in sequence, and each entry has structured fields corresponding to the expected log entries one to one; sequentially aiming at each expected log entry, starting from the current to-be-matched position of the actual log file, searching an actual log entry meeting a preset matching rule; if the search is successful, updating the to-be-matched position of the actual log file to the next position and continuing to match the next expected log entry, and if the search is failed, continuing to search in the subsequent entries of the actual log file until the traversal of the actual log file is completed; and finally, judging whether the actual log file passes verification or fails verification according to whether all entries of the expected log file are matched according to a preset time sequence or not.

Description

Technical Field

[0001] This application relates to the field of automotive software testing technology, and in particular to a method and apparatus for timing verification of automotive software testing logs. Background Technology

[0002] In the field of automotive electronics technology, automotive software development and testing based on the AUTOSAR architecture has become the industry mainstream. Diagnostic Log and Trace (DLT) is the core mechanism for recording the operating status, module interaction and error information of automotive software. Verifying whether the actual running DLT log stream conforms to the preset business process or state machine sequence is an important part of automotive software testing scenarios.

[0003] Currently, the industry's time-series verification of DLT logs mainly relies on manual review and analysis using general text tools. Existing technologies only have patents or tools with general text sequence matching concepts, and there are no dedicated verification tools designed specifically for the characteristics of automotive DLT logs. Manual review requires testers to manually sift through massive amounts of log files, relying on experience to filter key event sequences; general text tools use scripts such as grep, diff, and awk to assist in parsing log content in an attempt to complete time-series verification.

[0004] Manual verification is extremely inefficient and prone to missing key information due to subjective judgment bias or visual oversight, failing to meet the needs of automated testing and continuous integration in automotive software. General-purpose text tools such as grep and diff are not designed for DLT log verification and have inherent functional defects. They cannot handle the multi-dimensional structured information of DLT logs and have difficulty accurately matching key log events that appear in sequence, thus failing to meet the professional needs of automotive software testing. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method and apparatus for timing verification of automotive software test logs.

[0006] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a timing verification method for automotive software test logs, the method comprising: Obtain the expected log file and the actual log file; wherein, the expected log file includes multiple expected log entries arranged in sequence, and each expected log entry includes multiple structured fields; the actual log file includes multiple actual log entries recorded in sequence, and each actual log entry includes structured fields that correspond one-to-one with each of the expected log entries; For each expected log entry in the expected log file, starting from the current position to be matched in the actual log file, search for an actual log entry that satisfies the preset matching rules with the current expected log entry. If the search is successful, the position to be matched in the actual log file is updated to the next actual log entry in the actual log file, and the search continues to match the next expected log entry in the expected log file; if the search fails, the search continues in the subsequent actual log entries in the actual log file until the actual log file has been traversed. If all expected log entries in the expected log file are matched according to the preset time sequence, the actual log file is deemed to have passed verification; if one or more expected log entries fail to find an actual log entry that meets the preset matching rule, the actual log file is deemed to have failed verification.

[0007] In one possible implementation, finding the actual log entry that matches the current expected log entry according to a preset matching rule includes: The expected log entry and the actual log entry are matched for the first part of the structured fields, and included to match the second part of the structured fields.

[0008] In one possible implementation, the multiple structured fields include an application identifier field, a context identifier field, a log level field, and a log content field; the application identifier field is used to identify the log source, the context identifier field is used to identify the log context, the log level field is used to indicate the log severity, and the log content field is used to record the log content.

[0009] In one possible implementation, finding the actual log entry that matches the current expected log entry according to a preset matching rule includes: Starting from the current position to be matched, each actual log entry in the actual log file is matched and judged with the current expected log entry in turn; If the match is successful, the search is successful. If the matching judgment fails, the matching judgment continues for the next actual log entry until the actual log file has been traversed.

[0010] In one possible implementation, the method further includes: During the matching process, the actual log entries in the actual log file are checked in parallel to see if they meet the preset error judgment conditions. If an actual log entry that meets the error determination conditions exists, the matching process is terminated early and the verification of the actual log file is determined to have failed.

[0011] In one possible implementation, checking whether the actual log entry meets the preset error determination conditions includes: Obtain the application identifier field, context identifier field, and log level field of the actual log entry; Determine whether the log level field of the actual log entry belongs to the set of error log levels specified in the error determination conditions; If the log level field belongs to the error log level set, determine whether the application identifier field of the actual log entry belongs to the application identifier set when the application identifier set of the error judgment condition is not empty, and whether the context identifier field of the actual log entry belongs to the context identifier set when the context identifier set of the error judgment condition is not empty. If the log level field belongs to the error log level set, the application identifier field belongs to the application identifier set, and the context identifier field belongs to the context identifier set, then the actual log entry is determined to meet the error determination condition.

[0012] In one possible implementation, obtaining the expected log file and the actual log file includes: It receives the expected log file path and the actual log file path passed in via command-line arguments; Obtain the expected log file according to the expected log file path, and obtain the actual log file according to the actual log file path.

[0013] Secondly, embodiments of this application disclose a timing verification device for automotive software test logs, the device comprising: The acquisition module is used to acquire the expected log file and the actual log file; wherein, the expected log file includes multiple expected log entries arranged in sequence, and each expected log entry includes multiple structured fields; the actual log file includes multiple actual log entries recorded in sequence, and each actual log entry includes structured fields that correspond one-to-one with the expected log entries; The matching module is used to sequentially search for each expected log entry in the expected log file, starting from the current position to be matched in the actual log file, and to find an actual log entry that satisfies a preset matching rule. If the search is successful, the position to be matched in the actual log file is updated to the next actual log entry in the actual log file, and the matching continues for the next expected log entry in the expected log file. If the search fails, the search continues in subsequent actual log entries in the actual log file until the actual log file has been traversed. If all expected log entries in the expected log file are matched in a preset time sequence, the actual log file is deemed to have passed verification. If one or more expected log entries fail to find an actual log entry that satisfies the preset matching rule, the actual log file is deemed to have failed verification.

[0014] In one possible implementation, the matching module is specifically configured to perform an identical match on the first part of the structured fields of the expected log entry and the actual log entry, and to perform an inclusion match on the second part of the structured fields of the expected log entry and the actual log entry.

[0015] In one possible implementation, the multiple structured fields include an application identifier field, a context identifier field, a log level field, and a log content field; the application identifier field is used to identify the log source, the context identifier field is used to identify the log context, the log level field is used to indicate the log severity, and the log content field is used to record the log content.

[0016] In one possible implementation, the matching module is specifically used to start from the current position to be matched and sequentially match each actual log entry in the actual log file with the current expected log entry; if the matching is successful, the search is successful; if the matching fails, the matching is continued for the next actual log entry until the actual log file has been traversed.

[0017] In one possible implementation, the matching module is further configured to check in parallel during the matching process whether the actual log entries in the actual log file meet the preset error judgment conditions; if there are actual log entries that meet the error judgment conditions, the matching process is terminated in advance and the verification of the actual log file is determined to be unsuccessful.

[0018] In one possible implementation, the matching module is further specifically used to obtain the application identifier field, context identifier field, and log level field of the actual log entry; Determine whether the log level field of the actual log entry belongs to the set of error log levels specified in the error determination conditions; If the log level field belongs to the error log level set, determine whether the application identifier field of the actual log entry belongs to the application identifier set when the application identifier set of the error judgment condition is not empty, and whether the context identifier field of the actual log entry belongs to the context identifier set when the context identifier set of the error judgment condition is not empty. If the log level field belongs to the error log level set, the application identifier field belongs to the application identifier set, and the context identifier field belongs to the context identifier set, then the actual log entry is determined to meet the error determination condition.

[0019] In one possible implementation, the acquisition module is specifically configured to receive the expected log file path and the actual log file path passed in via command line parameters; acquire the expected log file based on the expected log file path; and acquire the actual log file based on the actual log file path.

[0020] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the timing verification method for automotive software test logs as described in any of the first aspects.

[0021] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that it stores a computer program, which is loaded by a processor to execute the timing verification method for automotive software test logs as described in any of the first aspects.

[0022] This application provides a method and apparatus for timing verification of automotive software test logs. The method first obtains an expected log file and an actual log file. The expected log file includes multiple expected log entries arranged in sequence, each entry having multiple structured fields. The actual log file includes multiple actual log entries recorded in sequence, each entry having a structured field corresponding one-to-one with the expected log entries. Then, for each expected log entry, starting from the current matching position in the actual log file, it searches for actual log entries that satisfy preset matching rules. If the search is successful, the matching position in the actual log file is updated to the next entry, and the matching continues for the next expected log entry. If the search fails, it continues searching in subsequent entries of the actual log file until the actual log file has been traversed. Finally, based on whether all entries in the expected log file have been matched according to the preset timing, it is determined whether the actual log file verification has passed or failed.

[0023] The method provided in this application automates the verification of log timing in automotive software testing, eliminating the need for manual intervention in filtering and matching log entries. This significantly improves the efficiency of log timing verification and meets the needs of automated automotive software testing. By sequentially searching for each expected log entry and updating the actual log entry to be matched upon successful search, the method strictly adheres to preset timing requirements, ensuring the accuracy of log timing verification and effectively solving the problem of traditional methods failing to accurately verify log timing. The design of continuing to traverse subsequent entries in the actual log until all entries are found allows for flexible searching of matching entries in the actual log, without requiring a one-to-one correspondence between the actual and expected logs. This adapts to testing scenarios where logs in actual automotive software operation include irrelevant content. Furthermore, matching based on one-to-one structured fields lays the foundation for accurate matching between log entries, improving the targeting of the search and matching. Clear verification result judgment rules make the results of log timing verification clear and definite, directly meeting the requirements for judging log timing verification results in automotive software testing. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a timing verification method for automotive software test logs provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a timing verification device for automotive software test logs provided in an embodiment of this application. Detailed Implementation

[0026] As described earlier, in the field of automotive electronics, especially in the R&D and testing of automotive software based on the AUTOSAR architecture, actual log files are the core mechanism for recording the operating status of automotive software systems, inter-module interactions, and fault information. To verify whether the business processes and state machine timings of the actual operation of automotive software meet design expectations, testers need to perform timing verification on the actual log files generated during operation. Currently, the industry's methods for verifying the timing of actual log files mainly fall into two categories: manual review and analysis assisted by general text tools. These methods cannot meet the automated and precise testing needs of automotive software.

[0027] To address this technical problem, this application provides a method and apparatus for timing verification of automotive software test logs. The method first obtains an expected log file and an actual log file. The expected log file includes multiple expected log entries arranged in sequence, each entry having multiple structured fields. The actual log file includes multiple actual log entries recorded in sequence, each entry having a structured field corresponding one-to-one with the expected log entries. Then, for each expected log entry, starting from the current matching position in the actual log file, it searches for actual log entries that satisfy preset matching rules. If the search is successful, the matching position in the actual log file is updated to the next entry, and the matching continues for the next expected log entry. If the search fails, the search continues in subsequent entries of the actual log file until the actual log file has been traversed. Finally, based on whether all entries in the expected log file have been matched according to the preset timing, it is determined whether the actual log file verification has passed or failed.

[0028] The method provided in this application automates the verification of log timing in automotive software testing, eliminating the need for manual intervention in filtering and matching log entries. This significantly improves the efficiency of log timing verification and meets the needs of automated automotive software testing. By sequentially searching for each expected log entry and updating the actual log entry to be matched upon successful search, the method strictly adheres to preset timing requirements, ensuring the accuracy of log timing verification and effectively solving the problem of traditional methods failing to accurately verify log timing. The design of continuing to traverse subsequent entries in the actual log until all entries are found allows for flexible searching of matching entries in the actual log, without requiring a one-to-one correspondence between the actual and expected logs. This adapts to testing scenarios where logs in actual automotive software operation include irrelevant content. Furthermore, matching based on one-to-one structured fields lays the foundation for accurate matching between log entries, improving the targeting of the search and matching. Clear verification result judgment rules make the results of log timing verification clear and definite, directly meeting the requirements for judging log timing verification results in automotive software testing.

[0029] This solution can be implemented across various hardware devices throughout the automotive software testing process, covering log timing verification scenarios across all stages of automotive R&D, production, and testing. Hardware with data reading and processing capabilities, such as production line industrial control computers, portable automotive diagnostic tools, R&D test workstations, personal computers, and enterprise CI / CD automated test servers, can all be equipped with this log timing verification method to perform log timing verification in automotive software testing. In automotive parts and vehicle production lines, production line industrial control computers or portable diagnostic tools can invoke this method to perform timing matching verification between actual operating logs generated by processes such as ECU flashing and OTA upgrades and preset expected logs. During the automotive software R&D and debugging phase, R&D personnel can execute this method through test workstations and personal computers to complete the timing correctness verification of log streams during software functional testing.

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

[0031] See Figure 1 , Figure 1 This is a flowchart illustrating a timing verification method for automotive software test logs provided in an embodiment of this application. The execution subject of this method can be a server, desktop computer, or other electronic device capable of computation. The following description uses an electronic device as the execution subject, and the method includes: S101: Electronic device obtains the expected log file and the actual log file.

[0032] The expected log file is a pre-set reference file used to verify log timing before automotive software testing. The expected log file includes multiple expected log entries arranged in a pre-set order according to the test process. Expected log entries are the basic units constituting the expected log file. Each expected log entry includes multiple structured fields set to achieve log matching and serves as a reference for verifying the timing of a single log entry.

[0033] The actual log file is a log record file generated during the actual operation of automotive software. Actual log entries within the actual log file are recorded according to the actual running time or execution order of the software. Actual log entries are the basic units that constitute the actual log file. The structured fields in an actual log entry correspond one-to-one with the expected log entries. The structured fields of actual log entries and expected log entries match perfectly in terms of dimensions and types, providing a foundation for subsequent field-level matching.

[0034] Structured fields are information units in log entries divided according to fixed dimensions, and are the core basis for achieving accurate matching between expected and actual log entries. In one possible implementation, structured fields include an application identifier field, a context identifier field, a log level field, and a log content field. Specifically, the application identifier field identifies the log source, the context identifier field identifies the log context, the log level field indicates the log severity, and the log content field records the log content.

[0035] In this embodiment, the electronic device can acquire expected log files and actual log files in various ways to adapt to different application scenarios of automotive software testing. The electronic device can directly read files from local storage media, such as retrieving pre-written expected log files from its own hard drive, USB flash drive, or other external storage, as well as actual log files stored locally after the automotive software runs. Alternatively, it can acquire log files through peripheral transmission or network communication, such as receiving actual log files generated during actual operation from automotive diagnostic tools, ECUs, or downloading standardized expected log files from a remote test server.

[0036] When acquiring files, the electronic device identifies the basic format and content structure of the files, confirming that the expected log entries in the expected log file are arranged sequentially according to the preset test time sequence, and that the actual log entries in the actual log file are recorded continuously according to the actual running order of the automotive software. Simultaneously, it verifies that the structured fields of both files meet the one-to-one matching requirement, ensuring no missing field dimensions or type mismatches. After file acquisition, the electronic device loads both files into its own memory for data preprocessing, providing a directly accessible data source for subsequent log entry searching and matching operations. This avoids repeated readings of external storage during subsequent matching processes, improving overall processing efficiency.

[0037] In one possible implementation, obtaining the expected log file and the actual log file includes: The electronic device receives the expected log file path and the actual log file path passed in as command-line arguments. The electronic device retrieves the expected log file based on the expected log file path and the actual log file based on the actual log file path.

[0038] The electronic device acts as a command-line tool, receiving file path information through a standardized command-line parameter interface to accurately retrieve the expected and actual log files. The device provides dedicated command-line parameters for inputting the expected and actual log file paths. Users can initiate a verification request by entering command-line instructions with corresponding parameters. Upon receiving the instruction, the device parses and processes it, precisely extracting the path parameters indicating the expected and actual log file storage locations. This ensures no confusion or omission of the two types of path parameters, providing accurate location information for subsequent file location and retrieval.

[0039] After parsing the command-line parameters, the electronic device searches for the expected log file path in the corresponding local storage medium or external storage device. Once the specific storage location of the expected log file is located, a file read operation is performed, loading the entire contents of the expected log file into the electronic device's local memory, forming file data that can be directly used for subsequent log matching processing. For the actual log file, the electronic device follows the exact same search and read logic, locating the file in the storage medium based on the parsed actual log file path, and completing the file read and memory loading. This actual log file is the DLT log file generated during the actual operation of the automotive software, which records multiple actual log entries according to the actual software runtime sequence.

[0040] During the process of retrieving files based on the path, the electronic device also performs basic file validity checks. If no corresponding file is found based on the parsed path, or if the retrieved file format does not match the preset log file format, the electronic device will promptly provide a file retrieval failure message and terminate the subsequent process. If the file retrieval is successful and the format verification passes, the process of retrieving the expected log file and the actual log file is successfully completed. This command-line parameter-based file retrieval method eliminates the need for manual selection of file storage paths, fully adapting to the needs of automated testing scenarios in automotive software. It can be directly invoked by automated programs such as Shell scripts and CI / CD pipelines, significantly improving the efficiency and convenience of file retrieval.

[0041] S102: The electronic device sequentially searches for each expected log entry in the expected log file, starting from the current position to be matched in the actual log file, for an actual log entry that satisfies a preset matching rule with the current expected log entry.

[0042] The current position to be matched refers to the starting position in the actual log file where no matching verification has been performed. It is the baseline starting point for searching actual log entries. The position to be matched will be dynamically updated as the matching operation progresses. Initially, it is the first actual log entry in the actual log file.

[0043] Preset matching rules refer to pre-defined, unified criteria used to determine whether expected log entries match actual log entries. Preset matching rules apply to the matching and validation of structured fields that correspond one-to-one with the actual log entries, and are the core basis for log entry matching.

[0044] After acquiring the expected log file and the actual log file, the electronic device first initializes the current matching position in the actual log file, setting it to the location of the first actual log entry. Simultaneously, it establishes a queue of expected log entries to be matched, following the original order of the expected log entries in the expected log file, and determines the first expected log entry to be matched. After initialization, the electronic device follows a sequential processing principle, retrieving the currently matched expected log entries from the queue one by one as the matching benchmark for this search. This process does not disrupt the preset timing of the expected log entries, ensuring the core requirement of log timing verification is met.

[0045] For each retrieved expected log entry, the electronic device reads subsequent actual log entries line by line, starting from the current matching position in the actual log file, as the actual log entries to be verified. For each actual log entry to be verified, the electronic device comprehensively compares all its structured fields with the corresponding structured fields in the expected log entry, strictly determining whether they match according to preset matching rules. During this search process, the electronic device only searches within the range after the current matching position in the actual log file, without backtracking to already verified actual log entries, avoiding resource waste caused by duplicate matching, and ensuring that the search process is consistent with the recording sequence of the actual logs.

[0046] After completing the search for the current expected log entry, the electronic device will perform different operations based on the search results. If the search is successful, meaning an actual log entry that meets the preset matching rules is found, the current position to be matched in the actual log file is updated to the next entry of the successfully matched actual log entry. At the same time, the matching target is advanced to the next expected log entry in the expected log file, and the search and matching process for that next expected log entry is initiated, maintaining the temporal order of the matching between expected and actual log entries throughout the process. If the search fails, meaning no corresponding matching actual log entry is found, the matching search continues in the subsequent actual log entries that have not yet been traversed in the actual log file. This process will continue until the actual log file has been completely traversed. At this point, the search for the current expected log entry will stop, and the overall verification result determination stage will begin.

[0047] To further clarify the specific execution method of the preset matching rules, make the log entry matching more in line with the structured characteristics of automotive software DLT logs, and improve the accuracy and domain adaptability of the matching, this application embodiment also divides the structured fields into two parts and adopts different matching methods for each part. At the same time, it clarifies the specific field types corresponding to each part, thereby completing the search for actual log entries that meet the preset matching rules.

[0048] In one possible implementation, finding the actual log entry that matches the currently expected log entry according to a preset matching rule includes: The electronic device performs a match on the first part of the structured fields of the expected log entries and the actual log entries, and performs an inclusion match on the second part of the structured fields of the expected log entries and the actual log entries.

[0049] In this embodiment, when the electronic device searches for an actual log entry starting from the current matching position in the actual log file, it first divides the structured fields in the expected log entry and the actual log entry into a first part of structured fields and a second part of structured fields according to preset rules. The first part of structured fields is fixed as an application identifier field, a context identifier field, and a log level field, while the second part of structured fields is the log content field. This division method is based on the inherent structural design of DLT logs in automotive software testing and precisely matches the characteristic attributes of automotive software logs.

[0050] The electronic device first performs the same matching operation on the first part of the structured fields, comparing the application identifier, context identifier, and log level fields in the expected log entry with the corresponding fields in the actual log entry to be verified, field by field. Only when the contents of all three fields are completely consistent with the corresponding fields in the actual log entry, without any differences, is the first part of the structured fields considered to have passed the match. This matching method can accurately pinpoint the application that generated the log, its context, and the log's importance level, ensuring the relevance of the match from the source and avoiding invalid matches caused by incorrect log sources.

[0051] After the first part of the structured field matching passes, the electronic device then performs an inclusion matching operation on the second part of the log content fields. It is not required that the log content fields of the expected log entry be completely identical to the corresponding fields of the actual log entry; it is only necessary to verify whether the log content fields of the actual log entry include the log content fields of the expected log entry. If the inclusion relationship is satisfied, the second part of the structured field matching is considered successful. This design adapts to the characteristics of automotive software during actual operation, where log content fields often include dynamically changing data such as timestamps, process IDs, and sensor values. This effectively avoids matching failures caused by such non-core dynamic content, improving the flexibility of the matching process.

[0052] The electronic device comprehensively judges the matching results of the two structured fields of the two log entries. Only when the matching of the same field in the first part of the structured fields and the inclusion matching of the second part of the structured fields are both completed and passed, is it finally determined that the current actual log entry to be verified and the current expected log entry meet the preset matching rules, and the search is completed. If the matching result of any structured field part fails, the electronic device directly skips the actual log entry and continues to traverse the next actual log entry and perform the above differential matching operation.

[0053] To further clarify the specific execution process of finding matching log entries from the current position to be matched in the actual log file, and to make the log entry search process more standardized and operable, this application embodiment also adopts a line-by-line matching judgment method to complete the search for actual log entries that meet the preset matching rules.

[0054] In one possible implementation, the actual log entries that match the currently expected log entries according to a preset matching rule are searched, including: Starting from the current position to be matched, the electronic device sequentially matches each actual log entry in the actual log file with the currently expected log entry. If a match is successful, the search is successful; if a match fails, the process continues to match the next actual log entry until the entire actual log file has been traversed.

[0055] In this embodiment, when performing a search operation, the electronic device strictly follows the recording sequence of the actual log file. Starting from the pre-defined current position to be matched, it extracts subsequent actual log entries line by line according to their original arrangement in the file, using each extracted entry as the object to be verified in a single matching judgment. Throughout the search process, the electronic device only traverses the actual log file sequentially, without backtracking to previously extracted entries or disrupting their original order, ensuring that the search process is consistent with the generation sequence of the actual logs.

[0056] For each actual log entry to be verified extracted line by line, the electronic device performs a complete matching judgment against the currently expected log entry according to pre-set matching rules, and performs corresponding verification on the structured fields of both. If the result of this matching judgment is successful, it means that an actual log entry that meets the preset matching rules has been found. The electronic device will immediately terminate the current traversal search operation and directly determine that the search operation is successful, without continuing to extract and verify subsequent actual log entries, effectively improving the efficiency of log entry search.

[0057] If the matching result for the current actual log entry to be verified fails, the electronic device will not terminate the overall search process. Instead, it will continue to extract the next actual log entry from the actual log file and repeat the matching operation described above. This process will continue until the electronic device finds an actual log entry that meets the preset matching rules and completes the search, or until the actual log file has been completely traversed. This ensures a comprehensive search of all actual log entries after the current matching position, avoiding omissions of matching log entries and guaranteeing the comprehensiveness and accuracy of the search operation.

[0058] To further improve the efficiency of timing verification of automotive software logs, promptly identify abnormal situations in actual logs, and avoid invalid matching operations, this application embodiment also adds a parallel error judgment and checking step during the log matching process. If an abnormal log that meets the conditions is detected, the matching is terminated in advance and the verification is directly judged as failed.

[0059] In one possible implementation, the method further includes: During the matching process, the electronic device checks in parallel whether the actual log entries in the actual log file meet the preset error judgment conditions. If there are actual log entries that meet the error judgment conditions, the electronic device terminates the matching process early and determines that the verification of the actual log file has failed.

[0060] In this embodiment, when the electronic device executes the core process of log entry matching, it simultaneously initiates a parallel error detection and checking process for the actual log entries. These two processes proceed simultaneously without interference, eliminating the need to wait for a particular log entry to complete its matching before performing error checking. This ensures both the integrity of the matching logic and real-time error checking. During the parallel checking process, the electronic device's checking targets remain consistent with the actual log entries traversed in the current matching process. For each actual log entry traversed, before or during the matching process with the current expected log entry, an error detection and checking process is performed simultaneously on that actual log entry, achieving a full traversal and check of the actual log file without any omissions.

[0061] The electronic device performs a comprehensive comparison of each currently traversed log entry with pre-defined error judgment criteria. These criteria are established based on the actual needs of automotive software testing and are specifically designed to identify critical abnormal log entries in the actual logs that could cause software malfunctions. Throughout the parallel inspection process, the electronic device continuously performs this comparison operation on each traversed log entry until it finds a log entry that meets the error judgment criteria, or completes the traversal of the entire log file and ends the matching process.

[0062] If, during parallel checks, the electronic device detects any actual log entry that meets preset error criteria, it immediately triggers a fast-fail mechanism. This terminates the entire log matching process prematurely, eliminating the need to continue matching and error checking subsequent log entries, and directly determining that the actual log file verification has failed. This eliminates the need to wait for all expected log entries to be matched before determining the anomaly. The process terminates immediately upon detecting an anomaly, effectively avoiding the consumption of computational resources by subsequent meaningless matching operations. This significantly improves log verification efficiency in abnormal scenarios and provides timely feedback on critical anomalies during automotive software operation, ensuring that the log sequence verification results better align with the actual business needs of automotive software testing.

[0063] To further clarify the specific verification logic and execution steps of error judgment conditions, improve the accuracy and rigor of actual log entry error judgment, and make the error judgment rules flexible and adaptable, this application embodiment also completes the check of whether the actual log entries meet the error judgment conditions through a step-by-step and field-by-field layered verification method.

[0064] In one possible implementation, checking whether the actual log entry meets preset error judgment conditions includes: The electronic device retrieves the application identifier field, context identifier field, and log level field of the actual log entry. The electronic device then determines whether the log level field of the actual log entry belongs to the set of error log levels specified in the error determination criteria.

[0065] If the log level field belongs to the error log level set, the electronic device determines whether the application identifier field of the actual log entry belongs to the application identifier set when the application identifier set of the error judgment condition is not empty, and whether the context identifier field of the actual log entry belongs to the context identifier set when the context identifier set of the error judgment condition is not empty.

[0066] If the log level field belongs to the error log level set, the application identifier field belongs to the application identifier set, and the context identifier field belongs to the context identifier set, the electronic device determines that the actual log entry meets the error determination conditions.

[0067] In this embodiment of the application, when the electronic device performs error judgment condition checks on actual log entries, it first accurately extracts three core structured fields from the currently traversed actual log entry: the application identifier field, the context identifier field, and the log level field. These three fields are the key verification dimensions for error judgment, directly related to the source of the log and the level of abnormality. After extraction, they are used as the core data for subsequent layered verification, laying the foundation for accurate judgment.

[0068] The electronic device first performs a pre-emptive core check for error detection, prioritizing whether the extracted log level field belongs to the pre-specified set of error log levels in the error detection conditions. This is the primary condition for error detection; only when the log level meets the preset exception level requirements is subsequent identification field verification performed. If the log level field is not in the set of error log levels, the electronic device will directly determine that the actual log entry does not meet the error detection conditions, without needing to perform subsequent field verification, thereby improving the overall efficiency of error detection.

[0069] If, after verification, the log level field of the actual log entry belongs to the preset error log level set, the electronic device will continue to perform targeted condition checks based on the configuration status of the application identifier set and context identifier set in the error judgment conditions. For the application identifier set, the electronic device will only determine whether the application identifier field of the actual log entry belongs to the set if the set is not empty; if the set is empty, the field check will be skipped. For the context identifier set, the same verification logic is followed, and the context identifier field of the actual log entry is checked only if the set is not empty. This design allows the error judgment rules to flexibly adapt to the verification needs of different test scenarios, supporting both full log exception level checks and precise exception checks for specific applications and specific contexts.

[0070] The electronic device then comprehensively evaluates all the conditions to be verified. Only when two core conditions are met simultaneously can the current actual log entry be determined to meet the preset error judgment conditions. First, the log level field must belong to the error log level set. Second, provided the corresponding sets are not empty, the application identifier field must belong to the application identifier set, and the context identifier field must belong to the context identifier set. If any of the fields to be verified fails to meet the corresponding requirements, the electronic device determines that the current actual log entry does not meet the error judgment conditions and continues to perform matching and error checking operations on the next actual log entry. This hierarchical and comprehensive judgment method effectively avoids misjudgments caused by matching a single field, significantly improving the accuracy and reliability of error judgment.

[0071] S103: If all expected log entries in the expected log file are matched according to the preset timing, the electronic device determines that the actual log file verification is successful.

[0072] Matching according to the preset timing means that for each expected log entry in the expected log file, the actual log entries that meet the preset matching rules are found in the actual log file in the original order in the file, and the matching process strictly follows the recording time of the actual logs, without any out-of-order or skipped-order matching.

[0073] The electronic device continuously monitors the matching status of expected log entries in real time, determining whether sequential matching of all expected log entries has been completed by checking the matching count or the position change of the matching pointer. When the electronic device completes the search for the last expected log entry in the expected log file according to the operation process of step S102, and that expected log entry successfully finds an actual log entry in the actual log file that meets the preset matching rules, the electronic device will determine that all expected log entries have been matched in the preset time sequence.

[0074] During this determination process, the electronic device performs a secondary verification of the overall matching process, confirming that the matching of each expected log entry follows the sequential logic of proceeding to the next entry only after the previous one has been successfully matched. The position of the actual log file to be matched is always updated forward with the matching progress, without any backtracking or cross-sequence matching anomalies, ensuring that the matching results meet the core requirements of sequential verification. After completing the overall matching status verification, the electronic device will officially output the determination result, clearly marking that the actual log file has passed verification, and can associate and store the determination result with the matching process information, providing traceable log verification records for automotive software testing.

[0075] S104: If one or more expected log entries fail to find actual log entries that meet the preset matching rules, the electronic device determines that the verification of the actual log file has failed.

[0076] After the electronic device has traversed all entries of the actual log file according to the operation procedure of S102, if the matching count does not cover all entries of the expected log file, and if one or more expected log entries do not find actual log entries that meet the preset matching rules, the electronic device will directly determine that the verification of the actual log file has failed.

[0077] In another possible implementation, if the parallel error detection process detects an actual log entry that meets the preset error detection conditions during the entire matching process, causing the matching process to terminate prematurely, the electronic device will also determine that the actual log file verification has failed.

[0078] When a verification fails, the electronic device records the reason for the failure and related information, including the location and number of expected log entries that were not successfully matched, or the specific field information and error type of the actual log entry that triggered the error judgment condition. At the same time, the judgment result and failure information are output synchronously, providing a clear traceability basis for subsequent troubleshooting and process optimization in automotive software testing, and avoiding the situation of only outputting the failure result without specific reference information.

[0079] This application also provides a timing verification device for automotive software test logs, such as... Figure 2 As shown, the device includes: The acquisition module 201 is used to acquire the expected log file and the actual log file; wherein, the expected log file includes multiple expected log entries arranged in sequence, and the expected log entries include multiple structured fields; the actual log file includes multiple actual log entries recorded in sequence, and the actual log entries include structured fields that correspond one-to-one with the expected log entries; The matching module 202 is used to sequentially search for each expected log entry in the expected log file, starting from the current position to be matched in the actual log file, for an actual log entry that satisfies a preset matching rule. If the search is successful, the position to be matched in the actual log file is updated to the next actual log entry in the actual log file, and the matching continues for the next expected log entry in the expected log file. If the search fails, the search continues in subsequent actual log entries in the actual log file until the actual log file has been traversed. If all expected log entries in the expected log file are matched in a preset time sequence, the actual log file is deemed to have passed verification. If one or more expected log entries fail to find an actual log entry that satisfies the preset matching rule, the actual log file is deemed to have failed verification.

[0080] In one possible implementation, the matching module 202 is specifically used to perform same matching on the first part of the structured fields of the expected log entry and the actual log entry, and to perform inclusion matching on the second part of the structured fields of the expected log entry and the actual log entry.

[0081] In one possible implementation, the multiple structured fields include an application identifier field, a context identifier field, a log level field, and a log content field; the application identifier field is used to identify the log source, the context identifier field is used to identify the log context, the log level field is used to indicate the log severity, and the log content field is used to record the log content.

[0082] In one possible implementation, the matching module 202 is specifically used to start from the current position to be matched, and sequentially match each actual log entry in the actual log file with the current expected log entry; if the matching is successful, the search is successful; if the matching fails, the matching is continued for the next actual log entry until the actual log file has been traversed.

[0083] In one possible implementation, the matching module 202 is further configured to check in parallel during the matching process whether the actual log entries in the actual log file meet the preset error judgment conditions; if there are actual log entries that meet the error judgment conditions, the matching process is terminated in advance and the verification of the actual log file is determined to be unsuccessful.

[0084] In one possible implementation, the matching module 202 is further configured to obtain the application identifier field, context identifier field, and log level field of the actual log entry; Determine whether the log level field of the actual log entry belongs to the set of error log levels specified in the error determination conditions; If the log level field belongs to the error log level set, determine whether the application identifier field of the actual log entry belongs to the application identifier set when the application identifier set of the error judgment condition is not empty, and whether the context identifier field of the actual log entry belongs to the context identifier set when the context identifier set of the error judgment condition is not empty. If the log level field belongs to the error log level set, the application identifier field belongs to the application identifier set, and the context identifier field belongs to the context identifier set, then the actual log entry is determined to meet the error determination condition.

[0085] In one possible implementation, the acquisition module 201 is specifically used to receive the expected log file path and the actual log file path passed in through command line parameters; acquire the expected log file according to the expected log file path, and acquire the actual log file according to the actual log file path.

[0086] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the timing verification method for automotive software test logs described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0087] Memory can store computer instructions. When these instructions are executed by a processor, the processor can use them to perform timing verification methods for automotive software test logs. Memory can also store data.

[0088] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0089] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0090] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0091] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0092] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for timing verification of automotive software test logs, characterized in that, The method includes: Obtain the expected log file and the actual log file; wherein, the expected log file includes multiple expected log entries arranged in sequence, and each expected log entry includes multiple structured fields; the actual log file includes multiple actual log entries recorded in sequence, and each actual log entry includes structured fields that correspond one-to-one with each of the expected log entries; For each expected log entry in the expected log file, starting from the current position to be matched in the actual log file, search for an actual log entry that satisfies the preset matching rules with the current expected log entry. If the search is successful, the position to be matched in the actual log file is updated to the next actual log entry in the actual log file, and the search continues to match the next expected log entry in the expected log file; if the search fails, the search continues in the subsequent actual log entries in the actual log file until the actual log file has been traversed. If all expected log entries in the expected log file are matched according to the preset time sequence, the actual log file is deemed to have passed verification; if one or more expected log entries fail to find an actual log entry that meets the preset matching rule, the actual log file is deemed to have failed verification.

2. The method according to claim 1, characterized in that, The process of finding actual log entries that match the current expected log entries according to preset matching rules includes: The expected log entry and the actual log entry are matched for the first part of the structured fields, and included to match the second part of the structured fields.

3. The method according to claim 1, characterized in that, The structured fields include an application identifier field, a context identifier field, a log level field, and a log content field; the application identifier field is used to identify the log source, the context identifier field is used to identify the log context, the log level field is used to indicate the log severity, and the log content field is used to record the log content.

4. The method according to claim 1, characterized in that, The process of finding actual log entries that match the current expected log entries according to preset matching rules includes: Starting from the current position to be matched, each actual log entry in the actual log file is matched and judged with the current expected log entry in turn; If the match is successful, the search is successful. If the matching judgment fails, the matching judgment continues for the next actual log entry until the actual log file has been traversed.

5. The method according to claim 1, characterized in that, The method further includes: During the matching process, the actual log entries in the actual log file are checked in parallel to see if they meet the preset error judgment conditions. If an actual log entry that meets the error determination conditions exists, the matching process is terminated early and the verification of the actual log file is determined to have failed.

6. The method according to claim 5, characterized in that, The step of checking whether the actual log entry meets the preset error judgment conditions includes: Obtain the application identifier field, context identifier field, and log level field of the actual log entry; Determine whether the log level field of the actual log entry belongs to the set of error log levels specified in the error determination conditions; If the log level field belongs to the error log level set, determine whether the application identifier field of the actual log entry belongs to the application identifier set when the application identifier set of the error judgment condition is not empty, and whether the context identifier field of the actual log entry belongs to the context identifier set when the context identifier set of the error judgment condition is not empty. If the log level field belongs to the error log level set, the application identifier field belongs to the application identifier set, and the context identifier field belongs to the context identifier set, then the actual log entry is determined to meet the error determination condition.

7. The method according to claim 1, characterized in that, The process of obtaining the expected log file and the actual log file includes: It receives the expected log file path and the actual log file path passed in via command-line arguments; Obtain the expected log file according to the expected log file path, and obtain the actual log file according to the actual log file path.

8. A timing verification device for automotive software test logs, characterized in that, The device includes: The acquisition module is used to acquire the expected log file and the actual log file; wherein, the expected log file includes multiple expected log entries arranged in sequence, and each expected log entry includes multiple structured fields; the actual log file includes multiple actual log entries recorded in sequence, and each actual log entry includes structured fields that correspond one-to-one with the expected log entries; The matching module is used to sequentially search for each expected log entry in the expected log file, starting from the current position to be matched in the actual log file, and to find an actual log entry that satisfies a preset matching rule. If the search is successful, the position to be matched in the actual log file is updated to the next actual log entry in the actual log file, and the matching continues for the next expected log entry in the expected log file. If the search fails, the search continues in subsequent actual log entries in the actual log file until the actual log file has been traversed. If all expected log entries in the expected log file are matched in a preset time sequence, the actual log file is deemed to have passed verification. If one or more expected log entries fail to find an actual log entry that satisfies the preset matching rule, the actual log file is deemed to have failed verification.

9. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to complete the timing verification method for automotive software test logs as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the timing verification method for automotive software test logs as described in any one of claims 1-7.

Images