An offline response structure-driven on-board diagnostic test case seed generation method

Abstract

The application discloses an off-line response structure driven vehicle-mounted diagnosis test case seed generation method, and belongs to the field of vehicle-mounted diagnosis communication data processing and automatic testing. The method performs protocol analysis, segmented recombination and payload normalization on off-line vehicle-mounted diagnosis communication records, infers a request field template and establishes a request-response association; generates an off-line response structure benchmark and a continuous field echo mapping containing cross-sample change bytes according to multiple associations; performs variation on a variable position of the request, generates positive and negative expected response structures for each candidate test case; repeatedly executes the candidate test case, classifies the actual response into positive response, standard negative response, structural abnormal response or timeout, and respectively adopts positive response indicators and negative response indicators for screening to obtain a verified test case seed set. The application improves the pertinence of the expected response and the reusability and traceability of the test case seed.

Description

Technical Field

[0001] This invention relates to the fields of vehicle diagnostic communication data processing and automated testing technology, and in particular to a method and computer-readable storage medium for inferring request field templates, request-response relationships and response structure benchmarks from offline vehicle diagnostic communication records, and for generating, executing and filtering vehicle diagnostic test case seeds based on the response structure benchmarks. Background Technology

[0002] On-board diagnostic testing typically involves sending diagnostic requests to the electronic control unit (ECU) or a diagnostic protocol simulation environment, and determining the test results based on the returned positive response, standard negative response, structural anomaly response, or timeout. Initial test case requests can be derived from manually written requests, protocol specifications, historical communication records, or randomly generated requests.

[0003] Existing solutions for generating test cases based on historical communication records typically focus on selecting representative messages from request messages or performing random mutations, boundary value replacements, and bit-flipping on bytes in the request payload. These solutions do not fully utilize the response messages corresponding to historical requests, making it difficult to determine which request fields are fixed and which can be mutated, and also making it difficult to automatically generate matching expected responses for specific mutated requests.

[0004] Some solutions can find responses following a request based on temporal proximity, but inferring echo relationships solely based on a single sample or identical fixed byte values ​​can easily lead to misidentifying identical fixed fields in the request and response as parameter echo fields. Incorrect echo relationships can cause errors in updating the expected response after mutation, resulting in incorrect judgments.

[0005] Furthermore, positive responses and standard negative responses differ in structure and evaluation purpose. Positive responses typically require checking the response service identifier, parameter echo, and response payload structure; standard negative responses typically require checking the negative response service identifier, original request service identifier, and negative response code. If the same parameter echo filtering criteria are used for both types of responses, standard negative responses may be incorrectly rejected because the corresponding parameter echo field does not exist.

[0006] Therefore, a technical solution is needed that can generate request field templates and offline response structure benchmarks from offline diagnostic communication records, verify the continuous field echo relationship using cross-sample changes, generate test case-specific expected response structures for mutated candidate test cases, and obtain reusable test case seeds through differential screening of positive responses and standard negative responses. Summary of the Invention

[0007] The purpose of this invention is to provide an offline response structure-driven method for generating vehicle diagnostic test case seeds, in order to solve the problems in the prior art that only mutate the request message, cannot reliably infer the echo relationship between request parameters and response parameters, cannot automatically generate test case-specific expected responses, and cannot perform differential verification of positive responses and standard negative responses.

[0008] To achieve the above objectives, the present invention provides a method for generating vehicle diagnostic test case seeds driven by an offline response structure, comprising the following steps.

[0009] Step 1: Obtain offline vehicle diagnostic communication records. These records include request and response messages acquired before the test execution, along with timestamps, communication directions, addressing information, and raw data payloads corresponding to the request and response messages. These records can originate from log files, message files, data tables, or authorized collection records.

[0010] Step two involves standardizing the offline communication records. A standardized message record is obtained by parsing, segmenting, reassembling, and extracting the payload using a protocol adapter corresponding to the communication protocol of the offline vehicle diagnostic communication record. The standardized message record includes at least a timestamp, communication direction, addressing information, and a standardized diagnostic payload. For communication protocols that use a length field to limit the payload, the payload boundary is determined based on the length field and protocol encapsulation rules; a byte with a value of 0x00 cannot be automatically identified as a padding byte.

[0011] Step 3: Generate request field templates. Group the request messages in the normalized message record according to at least two of the following: protocol type, communication direction, addressing information, diagnostic service identifier, and payload length. Analyze the value distribution of each byte position within each group, and divide each byte position into fixed and variable positions based on this value distribution to generate request field templates.

[0012] For a group containing n request messages, count the number of occurrences C of the byte value v at the j-th byte position. j (v), calculate the fixed-position confidence level F according to the following formula. j :

[0013]

[0014] When F jIf the position of the j-th byte is not lower than a preset fixed position threshold, the j-th byte position is determined to be a fixed position; otherwise, the j-th byte position is determined to be a variable position. When two or more byte values ​​have the same highest occurrence frequency, the corresponding byte position is determined to be a variable position, or the confidence of the fixed position of that byte position is reduced. A minimum group sample size can also be set. When the sample size of the request message group is lower than the minimum group sample size, the request message group is not used for high-confidence request field template inference.

[0015] Step 4: Establish request-response relationships. For each request message, within a preset interaction time window, based on the communication direction, address correspondence, and diagnostic service response rules, search for candidate response messages from the response messages following the request message.

[0016] The system determines whether the communication direction of the candidate response message and the request message is opposite, whether the addressing information conforms to a preset correspondence, and whether the response service identifier meets the positive or negative response rules. If multiple candidate response messages meet the conditions, the candidate response message with the smallest time interval from the request message and which can be uniquely identified is selected. If the associated response message cannot be uniquely identified, the corresponding request message is marked as a low-confidence request message, and the low-confidence request message is prohibited from participating in the generation of the high-confidence offline response structure benchmark.

[0017] Step 5: Generate an offline response structure baseline. Statistical analysis is performed on multiple high-confidence request-response pairs within the same request message group to generate an offline response structure baseline. This offline response structure baseline includes at least the response service identifier rule, response payload length, fixed response location, variable response location, and echo mapping between request fields and response fields.

[0018] For the request candidate field U and the response candidate field V, calculate the field mapping matching rate Q(U,V) based on m request-response associations:

[0019]

[0020] Where, q k [U] represents the candidate field U, r of the k-th request message. k[V] represents the candidate field V of the k-th associated response message, and I(·) is an indicator function. It takes the value 1 when both fields have the same value, and 0 otherwise. An echo mapping between the request candidate field U and the response candidate field V is established only when Q(U,V) is not lower than a preset echo threshold, and the request candidate field U contains at least one changed byte position across different request messages, and this change in byte position occurs synchronously in the response candidate field V. The echo mapping can be a single-byte position mapping or a continuous byte field mapping. By requiring that the candidate field contains at least one byte position that changes across samples and occurs synchronously, false echo relationships formed when the fixed byte values ​​in the request and response fields are exactly the same are excluded.

[0021] Step Six: Generate Candidate Test Cases. Select historical request messages that match the request field template from the request message group as initial test case seeds. Perform mutations on the variable positions of the initial test case seeds to generate candidate test cases. The mutations include at least one of the following: byte boundary value replacement; historical value replacement; enumerated value replacement; bitwise reversal; random value replacement.

[0022] Step 7: Generate a test case-specific expected response structure. Based on the offline response structure baseline of the request message group to which the candidate test case belongs, generate a test case-specific expected response structure for each candidate test case. The test case-specific expected response structure includes a positive expected response structure and a negative expected response structure. For the positive expected response structure, copy the offline response structure baseline of the request message group to which the candidate test case belongs, and according to the echo mapping, synchronously write the changed request field values ​​in the candidate test case into the corresponding response fields in the positive expected response structure. For the negative expected response structure, at least the positions of the negative response service identifier, the original request service identifier, and the negative response code are set. The test case-specific expected response structure of the same candidate test case can contain both a positive expected response structure and a negative expected response structure.

[0023] Step 8: Repeat execution and calculate verification metrics. Repeatedly execute candidate test cases in the test environment. For each execution, record the request sending information, actual response, response type, structure matching result, parameter echo matching result, and whether a timeout occurred. Classify each actual execution result as a positive response, a standard negative response, a structure anomaly response, or a timeout.

[0024] Let K be the number of times the candidate test cases are executed, and N be the number of times a positive response is received. pos The standard negative response count is N. neg The number of structural anomaly responses is N abn The number of timeouts is N timeout ,but:

[0025]

[0026] Protocol response rate R resp Structural anomaly rate R abn and timeout rate R timeout Calculate according to the following formulas respectively:

[0027]

[0028] The protocol response rate in this specification refers to the effective protocol response rate. Although a structural anomaly response indicates that the test environment returned a response message, if this response message does not meet the positive response rule or the standard negative response rule, it is not counted in the number of effective protocol responses and is recorded using the structural anomaly rate R. abn Individual evaluation.

[0029] When N pos When the value is greater than 0, the parameter echo matching rate and the positive response structure consistency rate are further calculated.

[0030] Let N be the number of positive responses that satisfy the use case-specific continuous field echo mapping. echo The number of affirmative responses that satisfy the affirmative expected response structure is N. pos-match Then the parameter echo matching rate R echo Consistency rate R of positive response structure pos They are respectively:

[0031] When N neg If the value is greater than 0, the consistency rate of the negative response structure is further calculated.

[0032] Let N be the number of standard negative responses that satisfy the negative expected response structure. neg-match Then the negative response structure consistency rate R neg for:

[0033]

[0034] When N pos When N equals 0, the parameter echo matching rate and the positive response structure consistency rate are not calculated; when N... neg When the value is 0, the negative response structure consistency rate is not calculated.

[0035] Step 9: Implement differentiated screening. Different metrics are used to screen candidate test cases that receive positive responses and those that receive standard negative responses. For candidate test cases that receive positive responses, the following criteria are used as screening conditions for positive response seeds: protocol response rate, parameter echo matching rate, and positive response structure consistency rate must not be lower than their respective thresholds, and the structure anomaly rate and timeout rate must not be higher than their respective thresholds.

[0036] For candidate test cases that receive standard negative responses, the following criteria are used as negative response seeds: protocol response rate and negative response structure consistency rate are not lower than their respective thresholds, and structure anomaly rate and timeout rate are not higher than their respective thresholds. Parameter echo matching rate is not included in the negative response seed selection. Candidate test cases that meet the corresponding selection criteria are determined as verified test case seeds, resulting in a set of verified test case seeds.

[0037] Furthermore, the method of the present invention can also generate a verification evidence file corresponding to the set of verified test case seeds. The verification evidence file records the association between the original offline message, request message group, offline response structure baseline, initial test case seed, candidate test cases, execution record, response record, verification conclusion, and verified test case seed. The execution record includes at least request sending information, execution time, execution count, and test environment information. The generation of the verification evidence file is an optional output step and does not constitute a necessary condition for generating verified test case seeds.

[0038] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0039] The above method can be implemented by a computer program. When the processor executes the computer program, it sequentially completes the following steps: offline communication record normalization, request field template inference, request-response association, offline response structure benchmark generation, continuous field echo mapping generation, initial test case seed selection, candidate test case generation, test case-specific expected response structure generation, repeated execution of candidate test cases, actual response classification, indicator calculation, and differential filtering processing.

[0040] Compared with the prior art, the present invention has at least the following beneficial effects:

[0041] First, historical requests and responses are used to form the basis for test case generation, avoiding unconstrained mutation of only request messages.

[0042] Second, by verifying the echo relationship through continuous field matching that includes bytes that change across samples, the risk of false echoes caused by identical fixed fields is reduced.

[0043] Third, it can automatically update the expected response structure based on the specific mutation values ​​of candidate requests, forming use case-specific response judgment rules.

[0044] Fourth, handle positive responses and standard negative responses separately, so that standard negative responses that conform to the protocol rules can also be used to form reusable test case seeds.

[0045] Fifth, by limiting the impact of structural anomaly response and timeout results on seed screening through structural anomaly rate and timeout rate, the reliability of screening results can be improved.

[0046] Sixth, improve the reproducibility and auditability of test case seeds through repeated execution and source tracing. Attached Figure Description

[0047] Figure 1 This is a flowchart illustrating the overall process of the method of the present invention.

[0048] Figure 2 Flowchart for inferring request field templates.

[0049] Figure 3 Generate a flowchart for request-response association and continuous field echo mapping.

[0050] Figure 4 Generate flowcharts for candidate test cases and their specific expected response structures.

[0051] Figure 5 A flowchart for differentiated screening of repeated execution, positive responses, and standard negative responses. Detailed Implementation

[0052] The present invention will be further described below with reference to the accompanying drawings and structural embodiments.

[0053] This embodiment uses de-identified example data constructed based on actual communication characteristics, conforming to the classic CAN and ISO-TP single-frame formats. The example data is used to illustrate the processes of offline communication record normalization, request field template inference, request-response association, offline response structure benchmark generation, continuous field echo mapping, candidate test case generation, and differential screening.

[0054] For other vehicle diagnostic transmission methods, the addressing information parsing, segmentation and reassembly, and diagnostic payload extraction can be completed first through the corresponding protocol adapter before proceeding with subsequent steps.

[0055] Step 1: Obtain the following offline diagnostic communication records. This embodiment obtains the following offline diagnostic communication records:

[0056] serial number Timestamp direction CAN ID Raw data payload M1 10:00:00.100 send 0x7E0 02 10 03 00 00 00 00 00 M2 10:00:00.120 take over 0x7E8 02 50 03 00 00 00 00 00 M3 10:00:00.200 send 0x7E0 03 22 F1 90 00 00 00 00 M4 10:00:00.230 take over 0x7E8 07 62 F1 90 41 42 43 44 M5 10:00:00.300 send 0x7E0 03 22 F1 8C 00 00 00 00 M6 10:00:00.330 take over 0x7E8 07 62 F1 8C 31 32 33 34 M7 10:00:00.400 send 0x7E0 03 22 F1 91 00 00 00 00 M8 10:00:00.430 take over 0x7E8 07 62 F1 91 00 00 00 00

[0057] The above messages are arranged in strict alternation of requests and responses to illustrate the request-response relationship.

[0058] Step two: Normalize the raw data payload. Taking M3 as an example, the first byte 0x03 is the ISO-TP single-frame protocol control information. Its lower half-byte indicates that the subsequent diagnostic payload length is 3 bytes. Therefore, 3 bytes are truncated starting from the second byte to obtain the normalized diagnostic payload 22 F1 90. The trailing 0x00 outside the payload length is padding bytes.

[0059] For M8, the first byte 0x07 indicates that the following 7 bytes are all payload; therefore, the last four 0x00 bytes are all valid response data and cannot be deleted. A byte cannot be identified as a padding byte simply because it has a value of 0x00; the payload boundary must be determined according to the payload length in the ISO-TP protocol control information. The normalization result is as follows.

[0060] Original message Standardized diagnostic payload M1 10 03 M2 50 03 M3 22 F1 90 M4 62 F1 90 41 42 43 44 M5 22 F1 8C M6 62 F1 8C 31 32 33 34 M7 22 F1 91 M8 62 F1 91 00 00 00 00

[0061] Step 3: Establish request message groups and generate request field templates. Assign M3, M5, and M7, whose service identifier is 0x22, sending address is 0x7E0, and normalized diagnostic payload length is 3 bytes, to request message group G1.

[0062] Let the minimum group sample size be n. min =3, fixed position threshold τ fix =0.8, and the sample size in this embodiment is n=3.

[0063] The values ​​at the first byte position are 0x22, 0x22, and 0x22, therefore:

[0064]

[0065] F1 is not lower than the fixed position threshold τ fix Therefore, the position of the first byte is determined to be a fixed position.

[0066] The value at the second byte position is always 0xF1, therefore:

[0067]

[0068] F2 is not lower than the fixed position threshold τ fix Therefore, the position of the second byte is determined to be a fixed position.

[0069] The values ​​at the 3rd byte position are 0x90, 0x8C, and 0x91, each appearing once. Therefore:

[0070]

[0071] F3 is below the fixed-location threshold τ fixTherefore, the position of the 3rd byte is determined to be a variable position.

[0072] This generates the request field template:

[0073]

[0074] The first and second bytes are in fixed positions, while the third byte is in a variable position.

[0075] Step 4: Establish request-response associations. In this embodiment, the interaction time window is set to 100 milliseconds. M4, following M3, communicates in the opposite direction to M3. 0x7E0 and 0x7E8 satisfy the preset addressing correspondence, with a time interval of 30 milliseconds. Furthermore, 0x62 satisfies the positive response service identifier rule for service 0x22. Therefore, the M3→M4 association is established. Similarly, the M5→M6 and M7→M8 associations are established. M1 and M2 form an independent request-response association for service 0x10 and do not participate in the response structure statistics of G1.

[0076] Step 5: Generate the offline response structure baseline. Based on the three high-confidence request-response pairs M3→M4, M5→M6, and M7→M8, generate the offline response structure baseline B1. The normalized diagnostic payload length of the three 0x22 service affirmative responses is 7 bytes each. The first byte is fixed at 0x62, the second and third bytes are the same as the second and third bytes of the corresponding request, and the fourth to seventh bytes are the response data fields.

[0077] The standard negative response baseline is set to a 3-byte structure:

[0078] 7F 22 NRC

[0079] Among them, 0x7F is the negative response service identifier, 0x22 is the original request service identifier, and NRC is the negative response code.

[0080] To verify whether the second and third bytes of the request and the second and third bytes of the response form a continuous field echo mapping, we set the request candidate field U = [2, 3] and the response candidate field V = [2, 3]. The fields of the three association pairs are compared as follows.

[0081] Related pairs Request field U Response field V Are they consistent? M3→M4 F1 90 F1 90 yes M5→M6 F1 8C F1 8C yes M7→M8 F1 91 F1 91 yes

[0082] thus:

[0083]

[0084] The third byte of the request candidate field changes from 0x90 to 0x8C and 0x91 in different samples, and the corresponding position in the response candidate field changes synchronously, satisfying the condition that at least one byte changes and that change occurs synchronously in the response candidate field. Therefore, a continuous field echo mapping is established from the second and third bytes of the request to the second and third bytes of the response. The fixed value 0xF1 existing alone in the request and response fields is not sufficient evidence to establish an echo mapping.

[0085] The obtained offline response structure baseline B1 includes:

[0086] (1) The response length is definitely 7 bytes;

[0087] (2) The first byte of the affirmative response is always 0x62;

[0088] (3) The response will definitely have bytes 2 to 3 as consecutive echo fields;

[0089] (4) The 4th to 7th bytes of the affirmative response are variable response data fields;

[0090] (5) The standard negative response length is 3 bytes;

[0091] (6) The first byte of the standard negative response is always 0x7F;

[0092] (7) The second byte of the standard negative response is always the original requested service identifier 0x22;

[0093] (8) The third byte of the standard negative response is the negative response code.

[0094] Step Six: Extract initial test case seeds I001, I002, and I003 from M3, M5, and M7 respectively. Retain these three historical requests to form T001, T002, and T003; perform byte boundary mutation on the third byte of I001, replacing 0x90 with 0x00 and 0xFF respectively, generating T004 and T005. This mutation is a byte boundary mutation with variable byte positions and does not represent the minimum or maximum value of the complete two-byte parameter space.

[0095] Initial seed / candidate use cases Requested payload Generation method I001 / T001 22 F1 90 Preserve historical values I002 / T002 22 F1 8C Preserve historical values I003 / T003 22 F1 91 Preserve historical values I001 / T004 22 F1 00 The 3rd byte is replaced with 0x00 I001 / T005 22 F1 FF Replace the 3rd byte with 0xFF

[0096] Step 7: Generate a unique expected response structure for each candidate test case.

[0097] Taking T004 as an example, according to the continuous field echo mapping, the request field F1 00 is written into the 2nd and 3rd bytes of the positive expected response, resulting in the positive expected response structure:

[0098] 62 F1 00 ?? ?? ?? ??

[0099] Simultaneously generate a negative expected response structure:

[0100] 7F 22 NRC

[0101] The positive expected response structure corresponding to T005 is:

[0102] 62 F1 FF ?? ?? ?? ??

[0103] The negative expected response structure is also as follows:

[0104] 7F 22 NRC

[0105] For T001, T002, and T003, generate corresponding positive expected response structures based on the second to third bytes of their request payloads, respectively.

[0106] Step 8: Repeat and calculate the verification metrics. In the local protocol simulator configured according to the response rules of this embodiment, each candidate test case is executed K=3 times.

[0107] In this embodiment, the simulator returns positive responses to requested payloads 22 F1 90, 22 F1 8C, and 22 F1 91, and standard negative responses 7F 22 31 to requested payloads 22 F1 00 and 22 F1 FF.

[0108] In this embodiment, the minimum thresholds for protocol response rate, parameter echo matching rate, positive response structure consistency rate, and negative response structure consistency rate are each set to 80%, and the maximum thresholds for structure anomaly rate and timeout rate are each set to 10%. These thresholds are only used to illustrate the screening process in this embodiment and can be adjusted according to protocol type, sample size, and testing environment.

[0109] The results of repeated execution are as follows:

[0110] use cases Requested payload <![CDATA[N pos ]]> <![CDATA[N neg ]]> <![CDATA[N abn ]]> <![CDATA[N timeout ]]> Response Classification T001 22 F1 90 3 0 0 0 A positive response T002 22 F1 8C 3 0 0 0 A positive response T003 22 F1 91 3 0 0 0 A positive response T004 22 F1 00 0 3 0 0 Standard negative response T005 22 F1 FF 0 3 0 0 Standard negative response

[0111] The corresponding verification metrics are as follows:

[0112] use cases Protocol response rate Parameter echo matching rate Certainty Response Structure Consistency Negative response structure consistency rate Structural anomaly rate Timeout rate T001 100% 100% 100% Do not participate 0% 0% T002 100% 100% 100% Do not participate 0% 0% T003 100% 100% 100% Do not participate 0% 0% T004 100% Do not participate Do not participate 100% 0% 0% T005 100% Do not participate Do not participate 100% 0% 0%

[0113] For executions T001 to T003, all three executions yielded positive responses that met the expected response structure. Therefore, the protocol response rate, parameter echo matching rate, and positive response structure consistency rate were all 100%, while the structure anomaly rate and timeout rate were all 0%, satisfying the positive response seed screening conditions set in this embodiment.

[0114] For T004 and T005, all three executions yielded a standard negative response 7F 22 31. The first byte of the response is the negative response service identifier 0x7F, the second byte is the original request service identifier 0x22, and the third byte is the negative response code 0x31, satisfying the expected negative response structure.

[0115] Therefore, the protocol response rate and negative response structure consistency rate of T004 and T005 are both 100%, and the structure anomaly rate and timeout rate are both 0%, which meets the negative response seed screening conditions set in this embodiment. The parameter echo matching rate is not involved in the screening of T004 and T005.

[0116] Step 9: Generate verified test case seeds and verification evidence. Based on the above execution results and differential screening criteria, T001 to T005 are determined as verified test case seeds S001 to S005, respectively. Among them: T001, T002, and T003 are retained as positive response seeds; T004 and T005 are retained as standard negative response seeds.

[0117] Candidate test cases whose protocol response rate, parameter echo matching rate, or corresponding response structure consistency rate does not reach the corresponding threshold, or whose structure anomaly rate or timeout rate is higher than the corresponding threshold, will not be included in the verified test case seed set.

[0118] When generating verification evidence files, the following tracing relationship is used:

[0119] Original offline message M → Request message group G → Offline response structure baseline B → Initial test case seed I → Candidate test case T → Execution record E → Response record R → Verification conclusion V → Verified test case seed S.

[0120] For example, the traceability chain corresponding to T004 can be recorded as follows:

[0121] M3→G1→B1→I001→T004→E004-1, E004-2, E004-3→R004-1, R004-2, R004-3→V004→S004.

[0122] Among them, execution records E004-1, E004-2 and E004-3 record the request sending information, execution time, number of executions and test environment information during the three execution processes of T004, respectively; response records R004-1, R004-2 and R004-3 record the actual response obtained in the corresponding execution process, respectively.

[0123] In another implementation, the offline vehicle diagnostic communication log may contain multiple frames of diagnostic messages or employ other vehicle diagnostic transmission protocols. The protocol adapter first reassembles the multiple frames into a complete diagnostic payload and outputs a unified timestamp, communication direction, addressing information, and diagnostic payload fields. Subsequent processes such as request field template inference, request-response association, offline response structure baseline generation, continuous field echo mapping, use case-specific expected response structure generation, and differential filtering remain consistent.

[0124] In another embodiment, the fixed position threshold, echo threshold, interaction time window, minimum group sample size, number of repetitions, and various filtering thresholds can be set according to the protocol type, sample size, and test environment. Changing the thresholds does not alter the technical processing relationship of this invention, which utilizes an offline request-response structure to generate and verify test case seeds.

[0125] In the software implementation, the computer program calls the protocol adapter corresponding to the communication protocol of the original communication record to obtain a unified and standardized message record, and then sequentially executes the following steps: request field template generation, high-confidence request-response association, offline response structure benchmark generation, continuous field echo mapping generation, candidate test case generation, test case-specific expected response structure generation, candidate test case execution, actual response classification, indicator calculation, and differential filtering.

[0126] The request field template inference, request-response association, offline response structure benchmark generation, continuous field echo mapping generation, test case-specific expected response structure generation, and differential filtering logic of this method do not depend on specific vehicle models, electronic control unit models, or specific test hardware.

[0127] The data and execution results listed in this embodiment are constructive examples. For the original messages generated by different communication protocols, the corresponding protocol adapter first completes message parsing, segmentation and reassembly, and diagnostic payload extraction, and then performs the above processing.

[0128] The local protocol simulator in this specification is used to provide a repeatable execution verification environment for this embodiment. The implementation environment of the invention method is not limited to the local protocol simulator, but can also be deployed in a real vehicle, electronic control unit test bench or authorized test environment of a specific physical bus.

[0129] The above embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. Equivalent substitutions or transformations made by those skilled in the art to the field statistical methods, mutation operators, protocol adaptation methods, response classification rules, or screening thresholds without departing from the core processing relationships of the present invention should all be included within the scope of protection of the present invention.

Claims

1. A method for generating vehicle diagnostic test case seeds driven by an offline response structure, characterized in that, include: Obtain offline vehicle diagnostic communication records, and perform message parsing, segmentation and reassembly, and payload extraction through a protocol adapter corresponding to the communication protocol of the offline vehicle diagnostic communication records to obtain a normalized message record that includes at least a timestamp, communication direction, addressing information, and normalized diagnostic payload. The request messages in the standardized message record are grouped according to at least two of the following: protocol type, communication direction, addressing information, diagnostic service identifier, and payload length. The value distribution of each byte position in each group is statistically analyzed. Based on the value distribution, each byte position is divided into fixed positions and variable positions to generate a request field template. For each request message, within a preset interaction time window, based on the communication direction, address correspondence, and diagnostic service response rules, the associated response message is determined from the response messages following the request message, and a request-response association is established. Statistical analysis is performed on multiple request-response pairs within the same group to generate an offline response structure baseline that includes at least the response service identification rules, response payload length, fixed response location, variable response location, and echo mapping between request fields and response fields. Historical request messages that match the request field template are selected from the group as initial test case seeds. Mutation is performed on the variable positions of the initial test case seeds to generate candidate test cases. Based on the offline response structure benchmark and the echo mapping, a test case-specific expected response structure is generated for each candidate test case. The test case-specific expected response structure includes a positive expected response structure and a negative expected response structure. In the testing environment, each candidate test case is executed repeatedly a preset number of times, and the actual responses obtained are classified as positive responses, standard negative responses, structurally abnormal responses, or timeouts. For candidate test cases that receive a positive response, they are filtered based on protocol response rate, parameter echo matching rate, positive response structure consistency rate, and timeout rate. For candidate test cases that receive standard negative responses, they are filtered based on protocol response rate, negative response structure consistency rate, and timeout rate; the candidate test cases that meet the corresponding filtering conditions are determined as verified test case seeds, thus obtaining a set of verified test case seeds.

2. The method according to claim 1, characterized in that, The echo mapping includes single-byte position mapping or consecutive-byte field mapping; For request candidate field U and response candidate field V, the field mapping matching rate Q(U,V) is calculated based on m request-response association pairs, where Q(U,V) is the ratio of the number of association pairs in the m request-response association pairs where the request candidate field U and the response candidate field V have the same value to m. An echo mapping between the request candidate field U and the response candidate field V is established only when Q(U,V) is not lower than the preset echo threshold, and the request candidate field U contains at least one changed byte position between different request messages, and the change of that byte position appears synchronously in the response candidate field V.

3. The method according to claim 1, characterized in that, The associated response message includes: Filter candidate response messages from messages that follow the request message and whose time interval with the request message is no greater than a preset interaction time window; Determine whether the communication direction of the candidate response message and the request message is opposite, whether the addressing information conforms to the preset correspondence, and whether the diagnostic service identifier meets the positive response rule or the negative response rule; when there are multiple candidate response messages that meet the conditions, select the candidate response message with the smallest time interval with the request message and which can be uniquely determined. When the associated response message cannot be uniquely identified, the corresponding request message is marked as a low-confidence request message, and the low-confidence request message is prohibited from participating in the generation of the high-confidence offline response structure benchmark.

4. The method according to claim 1, characterized in that, For the j-th byte position of the request message packet, count the number of times the byte value v appears at that j-th byte position, C. j (v), and calculate the fixed position confidence F of the j-th byte position according to the following formula. j : Where n is the number of request messages in the request message group; When Fj is not lower than the preset fixed position threshold, the position of the j-th byte is determined as a fixed position; otherwise, the position of the j-th byte is determined as a variable position. When two or more byte values ​​have the same highest occurrence count, the position of the j-th byte is determined as a variable position.

5. The method according to claim 1, characterized in that, The mutation performed on the variable position of the initial test case seed includes at least one of the following: byte boundary value replacement, historical value replacement, enumeration value replacement, bitwise flipping, and random value replacement; The generated test case-specific expected response structure includes: copying the offline response structure baseline of the group to which the candidate test case belongs; synchronously writing the changed request field values ​​in the candidate test case into the corresponding response fields in the positive expected response structure according to the echo mapping; and generating a negative expected response structure that includes at least the negative response service identifier, the original request service identifier, and the position of the negative response code.

6. The method according to claim 1, characterized in that, Let K be the number of times the candidate test cases are executed, Npos be the number of positive responses, Nneg be the number of standard negative responses, Nabn be the number of structural anomaly responses, and Ntimeout be the number of timeouts, and: Protocol response rate R resp Structural anomaly rate R abn and timeout rate R timeout They are respectively: The protocol response rate refers to the effective protocol response rate; structural anomaly responses are not counted in the number of effective protocol responses. When a candidate test case receives a positive response, the parameter echo matching rate and the positive response structure consistency rate are further calculated. The protocol response rate, parameter echo matching rate, and positive response structure consistency rate are not lower than the corresponding thresholds, and the structure anomaly rate and timeout rate are not higher than the corresponding thresholds, which are used as the selection conditions for positive response seeds. When a candidate test case receives a standard negative response, the negative response structure consistency rate is further calculated. The protocol response rate and the negative response structure consistency rate are not lower than the corresponding thresholds, and the structure anomaly rate and the timeout rate are not higher than the corresponding thresholds. These are used as the screening conditions for negative response seeds. The parameter echo matching rate is not included in the screening of negative response seeds.

7. The method according to claim 1, characterized in that, Also includes: Generate a verification evidence file corresponding to the set of verified test case seeds. The verification evidence file records at least the association between the original offline message identifier, the request message group identifier, the offline response structure baseline identifier, the initial test case seed identifier, the candidate test case identifier, the execution record identifier, the response record identifier, the verification conclusion identifier, and the verified test case seed identifier. The execution record includes at least the request sending information, execution time, execution count, and test environment information.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the method according to any one of claims 1 to 7.

Images