Intelligent test case generation method for crack detection method

Abstract

The application discloses a kind of intelligent test case generation methods for crack detection method, specifically relates to a kind of intelligent test case generation methods for crack detection method.Method includes: using SysML to establish the layered demand model of test case set, and automatically extract leaf demand to carry out multi-dimensional condition combination, generate covering unit and convert into text prompt word by large language model;Retrieve control template, through self-adapting condition fusion module, weight fusion is carried out to multi-source control chart, then input MControlNet and joint prompt word, generate crack image meeting specified test demand through diffusion model;According to the test label generated by control condition, encapsulate as standard test case;Requirement coverage verification is carried out based on the «verify» relationship of SysML, and according to the coverage gap in coverage report, the missing case is generated by closed-loop supplement.This application realizes the traceable management of requirement, case to verification, improves the authenticity, controllability and scene coverage of generated test sample.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary fields of artificial intelligence, computer vision, model-based systems engineering (MBSE), and generative AI, and specifically relates to an intelligent test case generation method for crack detection methods. Background Technology

[0002] Crack detection methods are widely used in the inspection and structural health monitoring of infrastructure such as roads, bridges, tunnels, utility tunnels, and airport runways. With the engineering deployment of deep learning methods, crack detection systems typically include image acquisition, preprocessing, model inference, post-processing, and result storage and interface output. In engineering applications, the correctness of a crack detection system depends not only on the accuracy of the algorithm but also on the adequacy of test cases in covering complex environmental scenarios such as low light at night, fog, water accumulation, oil stains, and obstructions; the traceability between test data and requirements; and the automation and reproducibility of the testing process.

[0003] Current testing practices face the problem of insufficient scenario coverage. Acquiring realistic crack images in rare scenarios such as smoke, shadows, nighttime, and strong glare is costly and results in scarce samples, making it difficult to construct test sets that meet the requirements for extreme environment coverage. Furthermore, there is a disconnect between requirements and verification. Test requirements often rely on unstructured documents or experience lists, lacking hierarchical modeling and quantitative decomposition based on systems engineering methods such as SysML, thus failing to form a closed-loop traceability of "requirements → test cases → verification → report." Simultaneously, test case generation is inefficient and inconsistent, with test images and annotations largely relying on manual collection or annotation, making it difficult to generate test data at scale that covers multiple combinations of conditions. Finally, existing generative enhancement methods are insufficient. Crack images generated by general text-based image models often suffer from geometric distortion, texture chaos, or label mismatch, and the generation process is unrelated to the failure mode of the detection model. Most methods rely on a single control signal, making it difficult to balance structural rationality, semantic consistency, and fine-grained realism. At the same time, there is a lack of quantitative standards for the "extreme degree" of generated samples, making it impossible to assess the performance boundaries of the model under harsh conditions. In addition, there is a lack of traceable link between the AI ​​data optimization process and the requirements of high-level systems, making it difficult to meet the certification and audit requirements of safety-critical areas.

[0004] Therefore, there is an urgent need for a method that can automatically generate crack image test data, automatically encapsulate test cases, and output traceable verification results based on explicit coverage constraints. Summary of the Invention

[0005] This invention addresses the problems of scarce complex scenario samples, broken traceability links between requirements and verification in crack detection test case generation, and insufficient controllability and unreliable generation quality of existing image generation methods. It proposes an intelligent test case generation method for crack detection methods, specifically including the following steps:

[0006] S1. Based on SysML requirement modeling, for the test objectives of the crack detection system, a hierarchical structure is adopted, and a hierarchical requirement model of the test case set is established using SysML; one or more top-level major requirements and their derived minor requirements are defined, and each minor requirement must be inherited from a major requirement through the SysML «deriveReqt» relationship.

[0007] S2. Generate multi-source text image input conditions based on the demand model, automatically extract leaf demand nodes in the demand model, combine multi-dimensional conditions according to the coverage criterion and combination constraint rules, generate a structured set of coverage units, and automatically convert the coverage units into text prompt words with scene semantics.

[0008] S3. Multi-source input controllable image generation: Retrieve control templates that meet the conditions from the control template library and use them as spatial control conditions in subsequent image generation stages; Perform feature layer weighted fusion on the multi-source control map, including crack mask, edge information, depth information, and semantic prior, to form a unified feature representation; Introduce the MControlNet architecture as a conditional control module, using the unified feature representation as the input of the MControlNet, and inject the MControlNet control conditions into the crack image generation process; Generate crack images that meet the specified test requirements based on the spatial control conditions and the MControlNet control conditions.

[0009] S4. Test Label Generation and Packaging: Construct test labels based on the control conditions used in the image generation stage. Test labels must include at least the following:

[0010] Crack location information, crack shape label, illumination and weather label, ground humidity label, occlusion ratio label, background complexity label, corresponding Coverage Unit number, and Prompt number;

[0011] S5. Test Case Encapsulation and Storage: Generate images and their corresponding labels are uniformly encapsulated into standard test cases. Each test case includes at least: a UUID to uniquely identify the test sample; an ImagePath to store the path of the generated image; a MaskPath to record the corresponding control template; a CoverageUnitID to record the coverage unit to which the test sample belongs; a PromptID to establish the mapping relationship between text prompts and test samples; a SceneLabel to record scene attributes; a BoundingBox to record crack target bounding box information; and a HashValue to ensure the uniqueness and integrity of the test sample. After encapsulation, all test cases are uniformly stored in the test case library, and a UUID index and a Coverage Unit index are established.

[0012] S6. Coverage verification and test report generation: Based on the test case library encapsulated in step S5, coverage statistics, requirement verification, and coverage report generation are performed on the test samples. A requirement-test case traceability matrix is ​​generated to evaluate the degree to which the current test case set meets the SysML requirement model, providing a basis for subsequent test case optimization.

[0013] S7: Traceable verification and closed-loop feedback. Based on the coverage report and requirement-test case traceability matrix generated in step S6, perform coverage analysis on the current test case set and locate test requirements that do not meet coverage requirements. For test requirements that do not meet coverage requirements, identify the corresponding missing coverage units and test conditions, regenerate the corresponding text prompts and control conditions, and call step S3 to continue generating new test samples. The newly generated test samples execute steps S3 to S7 again until all test requirements meet the preset coverage requirements.

[0014] Specifically, the method for defining the top-level major requirements and their derived minor requirements in step S1 is as follows:

[0015] S11. Use SysML «requirement» to define two independent top-level requirements: coverage metric R-COV-000 and format / traceability metric R-IF-000.

[0016] S12. Decompose R-COV-000 into secondary requirements. Through the SysML «deriveReqt» inheritance relationship, decompose R-COV-000 into the following secondary requirements, each of which inherits from R-COV-000. If the secondary requirements still need to be refined, deeper requirements can be derived until the hierarchy meets the requirements.

[0017] S13. Decompose R-IF-000 into smaller requirements. Through the SysML «deriveReqt» inheritance relationship, decompose R-IF-000 into smaller requirements. Each smaller requirement inherits from R-IF-000.

[0018] Specifically, step S2 is implemented as follows:

[0019] S21. Based on the SysML hierarchical requirement model described in step S1, automatically extract leaf requirement nodes, and generate a set of coverage units according to the requirement semantic type, composability constraints and coverage criteria. Each coverage unit represents a composite test scenario that can be used for subsequent image generation and test case construction.

[0020] S22. Generate basic text input conditions for each coverage unit. Adopt an automatic conversion method from coverage unit to text input conditions based on a large language model to automatically convert structured coverage units into text input conditions with scene semantics. Combine this with a rule constraint mechanism to ensure that the generated results are consistent with the original test requirements.

[0021] Specifically, step S21 is implemented as follows:

[0022] Step S211: Extract all leaf nodes of the smallest granularity requirements without child requirements from the SysML requirement model, i.e., leaf requirements, as the objects to be covered.

[0023] Step S212: Divide the leaf requirements into multiple coverage dimensions according to semantic type, with each coverage dimension representing a variable factor in the test scenario;

[0024] Step S213: Establish combination constraint rules based on the coverage dimension and generate candidate coverage units. Combine the leaf requirements in different coverage dimensions to form a set of candidate coverage units.

[0025] Step S214: Filter the final coverage units based on the coverage target to ensure that they meet the following conditions: each leaf requirement is covered by at least one coverage unit; the combination relationship between different types of leaf requirements is covered as much as possible; coverage units that cover more uncovered requirements are selected first; if there are sample quantity or ratio requirements for certain parent requirements, the corresponding coverage units are generated repeatedly according to the requirements.

[0026] Step S215, Coverage Integrity Verification: After the coverage unit is generated, a leaf requirement-coverage unit traceability matrix is ​​established to verify whether all leaf requirements have been covered.

[0027] Specifically, step S3 is implemented as follows:

[0028] S31. Control template acquisition and spatial control condition generation:

[0029] A control template library is pre-established, and control templates are selected from the control template library. Each control template in the template library corresponds to a real crack area. When a new test sample is generated, the system retrieves a control template that meets the conditions from the template library based on the crack type, crack scale and scene requirements in the current coverage unit, and uses it as a spatial control condition in the subsequent image generation process.

[0030] S32, MControlNet control condition generation

[0031] The crack mask matching the current coverage unit is retrieved from the control template library. The adaptive conditional fusion module ACFB is introduced to perform feature layer weighted fusion of the multi-source control map, including crack mask, edge information, depth information and semantic prior, to form a unified conditional code. The conditional code is then injected into the latent space diffusion model as the input condition of MControlNet. The crack image that meets the specified test requirements is generated in conjunction with the text prompt words.

[0032] ACFB, based on a variational autoencoder (VAE) architecture, is used for unified modeling and feature compression of various control graphs. Its inputs include multi-source conditional signals such as crack masks, edge information, depth information, and semantic priors, and it also supports externally input spatial weight maps. Specifically, ACFB maps each control graph to a shared feature space and performs pixel-by-pixel weighted fusion based on the user-provided spatial weight map to form a unified conditional code. Through a learnable weight allocation mechanism, ACFB adaptively models the importance of different conditional information in the generation process, achieving weighted fusion of multi-source control features. Simultaneously, through feature compression and dimension alignment operations, the fused control information is mapped into a compact and highly discriminative unified feature representation.

[0033] During training, ACFB learns the structural information of each control chart by reconstructing them and employs a weighted reconstruction loss function. This function sums the reconstruction errors of each control chart according to their corresponding weights, guiding the network to focus more on the fidelity of high-weight regions. The spatial weights can be manually set or learned by the model itself, allowing for dynamic adjustment of the importance of each control condition during the inference phase.

[0034] Specifically, the sources of the control template library include: real annotation information in existing publicly available crack datasets, including crack area control templates, crack outlines, crack target boxes, etc.; and crack images collected at the engineering site, which are manually annotated or generated from existing annotation results to form control templates, and are uniformly stored in the template library.

[0035] Specifically, the Adaptive Conditional Fusion (ACFB) module consists of a fusion module, an Encoder-Decoder structure, and a splitting module. The fusion module uses independent encoders to map k control images to a shared feature space, and performs pixel-wise weighted fusion with an externally input spatial weight matrix to obtain fused features. The Encoder-Decoder structure compresses and reconstructs the latent space from the fused features. The splitting module splits the reconstructed features into reconstructed versions of the original control images for supervised learning.

[0036] Assume there is a total A control image, denoted as:

[0037] ;

[0038] in , For image resolution, For each control image, there can be an external spatial weight matrix, corresponding to the number of channels.

[0039] ,

[0040] and Represents the rows and columns of the common latent space matrix. Indicates the first The spatial distribution of the importance of each condition.

[0041] In the fusion module, each control image is first mapped to a shared feature space using an independent encoder:

[0042] ,

[0043] in For the first An encoder for a control chart;

[0044] Then, weighted fusion is performed at the feature layer:

[0045] ,

[0046] in, This indicates pixel-wise weighted fusion;

[0047] The encoder further maps the fused features onto the latent space.

[0048] ,

[0049] Obtain latent variables The Decoder reconstructs high-dimensional features from the latent variables and then reconstructs the original control images separately using the SplitModule:

[0050] ,

[0051] Loss function design encourages the model to focus on information with high weights:

[0052] ,

[0053] This invention uses Stable Diffusion Inpainting as the base generator, which accepts a mask. and the image to be repaired As an additional condition, to further improve the control over the consistency of crack geometry and semantics, this invention introduces the MControlNet architecture and extends the single condition to a set of multi-source conditions. This includes crack masks, edge maps, depth maps, semantic maps, etc. Multi-source conditions are first fused into a unified condition representation using ACFB. Then, it is injected into the intermediate layer of the diffusion model by MControlNet. The overall denoising process can be represented as:

[0054] ,

[0055] in This is an adjustable control intensity coefficient. Through this design, the present invention achieves precise control over the location, shape, and background environment of cracks in the generated image.

[0056] Specifically, in step S3, the latent space diffusion model consists of a forward diffusion process and a reverse generation process.

[0057] During the forward diffusion process, the model gradually adds Gaussian noise to the real samples, causing the data distribution to gradually evolve into a standard Gaussian distribution, and finally obtain approximate Gaussian noise.

[0058] Given data distribution ,in, It is the original sample. It is the data distribution of the original sample. . It is a preset noise scheduling table. The variables should be gradually increased from small to large, with corresponding noise added to gradually increase the magnitude, thus obtaining a series of intermediate variables. When T is large enough, the final result is The process for noise that approximately follows a Gaussian distribution is as follows:

[0059] ,

[0060] in: Represents a normal distribution; It is the identity matrix. Let be the conditional probability distribution. The formula indicates that Gaussian noise is added at each step, resulting in:

[0061] ,

[0062] ,

[0063] in , That is, only one random Gaussian distribution is needed. This allows you to directly obtain intermediate variables at any step.

[0064] During the reverse generation process, the latent space diffusion model learns to gradually denoise random Gaussian noise and generate samples with a data distribution similar to the real samples.

[0065] The reverse generation process starts with standard Gaussian noise and gradually removes noise from intermediate variables. This reverse generation process is a Markov process, which can be derived using Bayes' theorem:

[0066] ,

[0067] in It is the mean of a Gaussian distribution. , Let V be the variance of the Gaussian distribution. ;

[0068] Original samples in actual reverse generation process Unknown, training deep neural networks to predict , This is random Gaussian noise added during the forward diffusion process to generate the current noisy sample;

[0069] Then proceed with reverse generation:

[0070] ,

[0071] ,

[0072] ,

[0073] Initial noise samples are obtained by sampling from a standard Gaussian distribution. According to time steps The order is repeated, using the above formula to calculate the samples from the previous time step step by step, i.e., from get until the final generated sample is obtained. .

[0074] Specifically, step S6 is implemented as follows:

[0075] S61, Test Case Coverage Statistics: First, traverse the test case library, read the coverage unit number and test label information corresponding to each test case, including attributes such as lighting conditions, ground humidity, crack shape, occlusion ratio, and background complexity, and classify and count them according to each coverage dimension.

[0076] S62. Requirement Coverage Verification: After completing the statistics, perform coverage verification for each requirement based on the SysML requirement model established in step S1.

[0077] For each requirement, the system extracts relevant data from the coverage statistics based on its corresponding preset quantitative indicators and determines whether the current test case set meets the corresponding requirement; for quantitative requirements, it determines whether the number of samples for the corresponding test conditions has reached the set threshold; for proportional requirements, it calculates the proportion of the corresponding sample number to the total number of test cases and compares it with the proportion specified in the requirement model; for combined coverage requirements, it determines whether the corresponding test samples have been generated for each combination of coverage units.

[0078] S64. Based on the «verify» relationship in SysML, test cases that meet the verification conditions are associated with corresponding requirements to form a requirement-test case mapping relationship. For requirements that do not meet the requirements, the system records the corresponding coverage gap, including missing test conditions, missing coverage unit combinations and current coverage level. The coverage gap serves as the basis for generating subsequent test data.

[0079] S63. Coverage Report Generation: Automatically generate a coverage report based on coverage statistics and requirements verification results.

[0080] Specifically, the coverage report includes at least: statistical results of samples for each coverage dimension; coverage status of each coverage unit; verification results of compliance or non-compliance for each SysML requirement; requirement-test case traceability matrix; coverage gap analysis, including missing test conditions and combinations of coverage units; total number of test cases, coverage statistics, and report generation time and version number information.

[0081] Compared with the prior art, the present invention has the following beneficial effects:

[0082] (1) The test requirements structure modeling based on SysML requirement model was realized, which improved the traceability of the test process.

[0083] This invention introduces the SysML requirement modeling method into the crack detection test case generation process. By establishing top-level requirements, derived requirements, and verification relationships, test requirements are decomposed into executable coverage units step by step. The mapping between requirements and test cases is established using the «deriveReqt» and «verify» relationships, realizing full-process traceable management from test requirements to test samples and coverage verification. This overcomes the problems of traditional test requirements relying on manual compilation and lacking structured management.

[0084] (2) Automatic generation of test conditions oriented to coverage requirements has been realized, which solves the problem of scarce samples in complex scenarios and improves the coverage of test scenarios.

[0085] This invention automatically extracts leaf requirements based on the SysML requirement model, constructs coverage units, and automatically generates test conditions and text prompts by combining coverage constraint rules. This effectively avoids the problems of low efficiency and insufficient coverage in traditional manual test scenario design. Furthermore, it can automatically generate test samples for complex environments, extreme scenarios, and multi-dimensional combinations of conditions, improving the coverage of test data for complex engineering scenarios.

[0086] (3) It realizes crack image generation with multi-condition collaborative control, which improves the authenticity and controllability of the generated samples.

[0087] This invention combines Stable Diffusion Inpainting, MControlNet, and the Adaptive Conditional Fusion Module (ACFB), while also introducing text prompts, mask templates, and various control conditions to jointly control crack location, crack morphology, scene environment, and background information. This enables the generated image to maintain realistic texture while meeting specified test requirements, improving the structural rationality, semantic consistency, and controllability of the generated samples. Attached Figure Description

[0088] Figure 1 This is a diagram illustrating the SysML requirements decomposition.

[0089] Figure 2 This is a schematic diagram of the ACFB module;

[0090] Figure 3 A schematic diagram of MControlnet;

[0091] Figure 4 This is the overall flowchart;

[0092] Figure 5 A diagram illustrating the generation of overlay units and prompt words for Sysml requirements;

[0093] Figure 6 This is a diagram illustrating the closed loop of requirements-use cases-validation-traceability-coverage.

[0094] Figure 7 The process of converting coverage units to prompts;

[0095] Figure 8 This represents the forward and reverse diffusion processes in the diffusion model. Detailed Implementation Specific implementation method one:

[0097] This embodiment is described in conjunction with the accompanying drawings. This embodiment provides an intelligent test case generation method for crack detection methods, combined with... Figure 4 The specific implementation steps are as follows:

[0098] S1, Combination Figure 1 Based on SysML requirement modeling, a hierarchical structure is adopted for the test objectives of the crack detection system. A hierarchical requirement model of test case set is established using SysML. The top-level major requirement and its derived minor requirements are defined. Each minor requirement must inherit from a major requirement through the SysML «deriveReqt» relationship.

[0099] Specifically, the way to define the top-level major requirements and their derived minor requirements is as follows:

[0100] S11. Use SysML «requirement» to define two independent top-level requirements: coverage metric R-COV-000 and format / traceability metric R-IF-000.

[0101]

[0102] S12. Decompose R-COV-000 into secondary sub-requirements. Through the SysML «deriveReqt» inheritance relationship, decompose R-COV-000 into the following secondary sub-requirements, each of which inherits from R-COV-000. If the secondary requirements still need to be refined, deeper requirements can be derived until the hierarchy satisfies the requirements. In this embodiment, R-COV-000 is first decomposed into secondary sub-requirements:

[0103]

[0104] The secondary sub-demands are further broken down into tertiary sub-demands:

[0105]

[0106] S13. Decompose R-IF-000 into smaller requirements using the SysML «deriveReqt» inheritance relationship, with each smaller requirement inheriting from R-IF-000:

[0107]

[0108] S2. Generate multi-source text image input conditions based on the demand model, automatically extract leaf demand nodes in the demand model, combine multi-dimensional conditions according to the coverage criterion and combination constraint rules, generate a structured set of coverage units, and automatically convert the coverage units into text prompt words with scene semantics.

[0109] Specifically, step S2 includes:

[0110] S21. Based on the SysML hierarchical requirement model described in step S1, automatically extract leaf requirement nodes, and generate a set of coverage units according to the requirement semantic type, composability constraints and coverage criteria. Each coverage unit represents a composite test scenario that can be used for subsequent image generation and test case construction.

[0111] In this step, the system does not generate test scenarios through manual enumeration. Instead, based on the SysML hierarchical requirement model established in step S1, it automatically extracts leaf requirement nodes and generates a set of coverage units according to requirement semantic types, composability constraints, and coverage criteria. Each coverage unit represents a composite test scenario that can be used for subsequent image generation and test case construction.

[0112] Further, step S21 includes:

[0113] Step S211: Extract all leaf nodes of the smallest granularity requirement without child requirements from the SysML requirement model, i.e., leaf requirements, as the objects to be covered; for the crack detection test requirement, the following leaf requirements can be obtained:

[0114]

[0115] Step S212: Divide the leaf requirements into multiple coverage dimensions according to semantic type, with each coverage dimension representing a variable factor in the test scenario;

[0116]

[0117] Therefore, a coverage unit It can be represented as:

[0118] ;

[0119] Step S213: Establish combination constraint rules based on the coverage dimension and generate candidate coverage units. Combine the leaf requirements in different coverage dimensions to form a set of candidate coverage units.

[0120] To avoid generating unreasonable or unexecutable coverage units, the system establishes composite constraint rules:

[0121]

[0122] Step S214: Filter the final coverage units based on the coverage target to ensure that they meet the following conditions: each leaf requirement is covered by at least one coverage unit; the combination relationship between different types of leaf requirements is covered as much as possible; coverage units that cover more uncovered requirements are selected first; if there are sample quantity or ratio requirements for certain parent requirements, the corresponding coverage units are generated repeatedly according to the requirements.

[0123] Using the full composition approach, the candidate set CandidateUnits is:

[0124] ,

[0125]

[0126] To avoid an excessive number of covering units due to full combination, the system employs a covering array or greedy set covering algorithm to select a smaller number of covering units from the candidate covering units, such that they satisfy the following conditions:

[0127] 1. Each leaf must be covered by at least one cover unit;

[0128] 2. The combination relationships between different types of leaf requirements should be covered as much as possible;

[0129] 3. Prioritize selecting coverage units that cover more of the uncovered needs;

[0130] 4. If certain parent requirements have requirements on the number or proportion of samples, then the corresponding coverage units will be generated repeatedly according to those requirements.

[0131] Step S215, Coverage Integrity Verification: After the coverage units are generated, a leaf requirement-coverage unit traceability matrix is ​​established to verify whether all leaf requirements have been covered. Its input is:

[0132] ReqModel: SysML requirement model;

[0133] CombineRules: Rules for combining coverage dimensions;

[0134] ConstraintRules: Combined constraint rules;

[0135] Combined coverage strength, default .

[0136] Its output is: CoverageUnitSet.

[0137] The steps include:

[0138] 1. Extract leaf requirements;

[0139] 2. Divide the coverage dimensions according to semantic type;

[0140] 3. Initialize the candidate covering unit set;

[0141] 4. Perform combinations for different coverage dimensions;

[0142] 5. Filter candidate coverage cells according to constraint rules;

[0143] 6. Construct the set of targets to be covered;

[0144] 7. Initialize the final set of covering units;

[0145] 8. Greedy selection of covering cells;

[0146] 9. Coverage integrity verification;

[0147] S22. Generate basic text input conditions for each coverage unit. Adopt an automatic conversion method from coverage unit to text input conditions based on a large language model to automatically convert structured coverage units into text input conditions with scene semantics. Combine this with a rule constraint mechanism to ensure that the generated results are consistent with the original test requirements.

[0148] Combination Figure 5 and Figure 7 Note that after generating the overlay units, they need to be converted into text input conditions (Prompts) that can be used by the image generation model. Traditional methods typically construct text descriptions using fixed template concatenation, such as directly combining scene attributes and crack attributes from the overlay units according to a predefined format. However, the text expressions generated by this method are limited in variety and semantic richness, making it difficult to fully leverage the generative model's ability to express complex scenes.

[0149] To address this, the present invention employs an automatic conversion method from cover units to text input conditions based on a Large Language Model (LLM). This method leverages the semantic understanding and natural language generation capabilities of the LLM to automatically convert structured cover units into text input conditions with rich scene semantics. Simultaneously, it incorporates a rule-based constraint mechanism to ensure that the generated results remain consistent with the original test requirements, thereby achieving automatic mapping from test requirements to image generation conditions.

[0150] For each coverage unit (CU) generated in step S2, a structured semantic description is first constructed:

[0151] CU =<Scene, Surface, CrackType, Occlusion, Background> ,

[0152] The system automatically constructs standardized prompts based on the coverage units and passes the structured attributes as input parameters to the large language model. An example of the input template is as follows:

[0153] Generate crack detection test image prompts based on the following test scenario.

[0154] Require:

[0155] 1. Retain all coverage conditions;

[0156] 2. Conflicting scenarios must not be introduced;

[0157] 3. Output a natural language description suitable for image generation models;

[0158] 4. Highlight the crack structure and environmental characteristics;

[0159] 5. Maintain an authentic shooting style.

[0160] Test scenario:

[0161] Scene = Low light intensity at night;

[0162] Surface = standing water;

[0163] CrackType = Straight crack;

[0164] Occlusion = High occlusion;

[0165] Background = Highly complex background.

[0166] S3. Multi-source input controllable image generation: Control templates meeting certain conditions are retrieved from the control template library and used as spatial control conditions for subsequent image generation stages; multi-source control maps, including crack masks, edge information, depth information, and semantic priors, are weighted and fused at the feature layer to form a unified feature representation; combined with… Figure 3 The MControlNet architecture is introduced as a condition control module, which injects MControlNet control conditions into the crack image generation process; based on the spatial control conditions and the MControlNet control conditions, crack images that meet the specified test requirements are generated.

[0167] Specifically, step S3 is implemented in the following ways:

[0168] S31. Control template acquisition and spatial control condition generation:

[0169] A control template library is pre-established, and a control template Mask is selected from the control template library. Each control template in the template library corresponds to a real crack area. When a new test sample is generated, the system retrieves a control template that meets the conditions from the template library based on the crack type, crack scale and scene requirements in the current coverage unit, and uses it as a spatial control condition in the subsequent image generation process.

[0170] Specifically, the sources of the control template library include: real annotation information in existing publicly available crack datasets, including crack area control templates, crack outlines, crack target boxes, etc.; and crack images collected on-site, which are manually annotated or generated from existing annotation results to form control templates, and are uniformly stored in the template library.

[0171] Each Mask in the template library corresponds to a real crack area and can be directly used as a constraint for the repair area of ​​Stable DiffusionInpainting, thereby ensuring that the location, size and overall spatial structure of the generated cracks conform to the actual engineering scenario.

[0172] When generating new test samples, the system retrieves a Mask template that meets the conditions from the template library based on the crack type, crack scale, and scene requirements in the current Coverage Unit (CU), and uses it as a spatial control condition in the subsequent image generation process.

[0173] S32, MControlNet control condition generation:

[0174] The crack mask matching the current coverage unit is retrieved from the control template library. The adaptive conditional fusion module ACFB is introduced to perform feature layer weighted fusion of the multi-source control map, including crack mask, edge information, depth information and semantic prior, to form a unified conditional code. The conditional code is then injected into the latent space diffusion model as input condition of MControlNet. The crack image that meets the specified test requirements is generated in conjunction with the text prompt words.

[0175] Specifically, in combination Figure 2 The adaptive conditional fusion module (ACFB) consists of a fusion module, an encoder-decoder structure, and a splitting module. The fusion module uses independent encoders to map k control images to a shared feature space, and performs pixel-wise weighted fusion with an externally input spatial weight matrix to obtain fused features. The encoder-decoder structure compresses and reconstructs the latent space from the fused features. The splitting module splits the reconstructed features into reconstructed versions of the original control images for supervised learning.

[0176] Specifically, in combination Figure 8 Note that in step S3, the latent space diffusion model consists of a forward diffusion process and a reverse generation process.

[0177] During the forward diffusion process, the model gradually adds Gaussian noise to the real samples, causing the data distribution to gradually evolve into a standard Gaussian distribution, and finally obtain approximate Gaussian noise.

[0178] Given data distribution ,in, It is the original sample. It is the data distribution of the original sample. . It is a preset noise scheduling table. The variables should be gradually increased from small to large, with corresponding noise added to gradually increase the magnitude, thus obtaining a series of intermediate variables. When T is large enough, the final result is The process for noise that approximately follows a Gaussian distribution is as follows:

[0179] ,

[0180] in: Represents a normal distribution; It is the identity matrix. Let be the conditional probability distribution. The formula indicates that Gaussian noise is added at each step, resulting in:

[0181] ,

[0182] ,

[0183] in , That is, only one random Gaussian distribution is needed. This allows you to directly obtain intermediate variables at any step.

[0184] During the reverse generation process, the latent space diffusion model learns to gradually denoise random Gaussian noise and generate samples with a data distribution similar to the real samples.

[0185] The reverse generation process starts with standard Gaussian noise and gradually removes noise from intermediate variables. This reverse generation process is a Markov process, which can be derived using Bayes' theorem:

[0186] ,

[0187] in It is the mean of a Gaussian distribution. , Let V be the variance of the Gaussian distribution. ;

[0188] Original samples in actual reverse generation process Unknown, training deep neural networks to predict , This is random Gaussian noise added during the forward diffusion process to generate the current noisy sample;

[0189] Then proceed with reverse generation:

[0190] ,

[0191] ,

[0192] ,

[0193] Initial noise samples are obtained by sampling from a standard Gaussian distribution. According to time steps The order is repeated, using the above formula to calculate the samples from the previous time step step by step, i.e., from get until the final generated sample is obtained. .

[0194] S4. Test Label Generation and Packaging: Based on the control conditions used in the image generation stage, test labels are constructed. The test labels mainly include:

[0195] Crack location information, crack shape label, illumination and weather label, ground humidity label, occlusion ratio label, background complexity label, corresponding Coverage Unit number, and Prompt number.

[0196] Since the above labels are all generated from the process, the consistency between the image content and the label information is guaranteed, avoiding the detection errors and label deviations that may occur in the traditional automatic labeling process, and improving the consistency and reliability of the test data.

[0197] S5. Test Case Encapsulation and Storage: Generate images and their corresponding labels are uniformly encapsulated into standard test cases. Each test case includes at least: a UUID for uniquely identifying the test sample; an ImagePath for storing the path of the generated image; a MaskPath for recording the corresponding control template; a CoverageUnitID for recording the coverage unit to which the test sample belongs; a PromptID for establishing the mapping relationship between text prompts and test samples; a SceneLabel for recording scene attributes; a BoundingBox for recording crack target box information; and a HashValue for ensuring the uniqueness and integrity of the test sample. After encapsulation, all test cases are uniformly stored in the test case library, and a UUID index and a Coverage Unit index are established to support fast retrieval, coverage statistics, and subsequent requirement verification.

[0198] S6. Coverage verification and test report generation: Based on the test case library encapsulated in step S5, coverage statistics, requirement verification, and coverage report generation are performed on the test samples. A requirement-test case traceability matrix is ​​generated to evaluate the degree to which the current test case set meets the SysML requirement model, providing a basis for subsequent test case optimization.

[0199] Specifically, step S6 is implemented as follows:

[0200] S61, Test Case Coverage Statistics: First, traverse the test case library, read the coverage unit number and test label information corresponding to each test case, including attributes such as lighting conditions, ground humidity, crack shape, occlusion ratio, and background complexity, and classify and count them according to each coverage dimension.

[0201] For each coverage dimension, the number of samples corresponding to each test condition and its proportion of the total test samples are counted. For example: the illumination dimension counts the number of samples in scenarios such as low light at night, fog, and shadow / backlight; the ground humidity dimension counts the number of samples in scenarios such as water accumulation, wet asphalt, and oil stains; the crack morphology dimension counts the number of samples for straight cracks, branch cracks, and network cracks; the occlusion ratio dimension counts the number of samples corresponding to different occlusion intervals; and the background complexity dimension counts the number of samples corresponding to different background levels.

[0202] The statistical results are compiled into a comprehensive statistical table, providing basic data for subsequent requirements verification.

[0203] S62. Requirement Coverage Verification: After completing the statistics, perform coverage verification for each requirement based on the SysML requirement model established in step S1.

[0204] For each requirement, the system extracts relevant data from the coverage statistics based on its corresponding preset quantitative indicators and determines whether the current test case set meets the corresponding requirement; for quantitative requirements, it determines whether the number of samples for the corresponding test conditions has reached the set threshold; for proportional requirements, it calculates the proportion of the corresponding sample number to the total number of test cases and compares it with the proportion specified in the requirement model; for combined coverage requirements, it determines whether the corresponding test samples have been generated for each combination of coverage units.

[0205] S63. Subsequently, based on the «verify» relationship in SysML, the system establishes an association between test cases that meet the verification conditions and corresponding requirements, forming a requirement-test case mapping relationship, and realizing traceable verification between test samples and requirements.

[0206] For requirements that are not met, the system records the corresponding coverage gaps, including missing test conditions, missing coverage unit combinations, and the current coverage level, providing a basis for generating subsequent test data.

[0207] S64. Coverage Report Generation: Automatically generate a coverage report based on coverage statistics and requirements verification results.

[0208] Specifically, the coverage report includes at least:

[0209] (1) Statistical results of samples in each coverage dimension;

[0210] (2) Coverage status of each Coverage Unit;

[0211] (3) Validation results (meeting / not meeting) for each SysML requirement;

[0212] (4) Requirements-Test Case Traceability Matrix;

[0213] (5) Coverage gap analysis, including missing test conditions and coverage unit combinations;

[0214] (6) The total number of test cases, coverage statistics, and information such as report generation time and version number.

[0215] Coverage reports not only reflect the coverage of the current test case set, but also clearly identify coverage items that have not yet met testing requirements, providing a basis for subsequent test sample generation and coverage optimization.

[0216] The above results will serve as input for the closed-loop feedback optimization in step S7, continuing to generate new test conditions and test cases based on the coverage gaps until the coverage requirements specified in the SysML requirement model are met.

[0217] S7: Combination Figure 6 The system enables traceable verification and closed-loop feedback. Based on the coverage report and requirement-test case traceability matrix generated in step S6, it performs coverage analysis on the current test case set and locates test requirements that do not meet coverage requirements. For test requirements that do not meet coverage requirements, it identifies the corresponding missing coverage units and test conditions, regenerates the corresponding text prompts and control conditions, and calls step S3 to continue generating new test samples. The newly generated test samples then execute steps S3 to S7 again until all test requirements meet the preset coverage requirements.

[0218] The scope of this invention is not limited to the above-described embodiments; a combination of one or more specific embodiments can also achieve the purpose of the invention.

Claims

1. A method for generating intelligent test cases for crack detection methods, characterized in that, Includes the following steps: S1. Based on SysML requirement modeling, for the test objectives of the crack detection system, a hierarchical structure is adopted, and a hierarchical requirement model of the test case set is established using SysML; one or more top-level major requirements and their derived minor requirements are defined, and each minor requirement must be inherited from a major requirement through the SysML «deriveReqt» relationship. S2. Generate multi-source text image input conditions based on the demand model, automatically extract leaf demand nodes in the demand model, combine multi-dimensional conditions according to the coverage criterion and combination constraint rules, generate a structured set of coverage units, and automatically convert the coverage units into text prompt words with scene semantics. S3. Multi-source input controllable image generation: Retrieve control templates that meet the conditions from the control template library and use them as spatial control conditions for subsequent image generation stages; Perform feature layer weighted fusion on the multi-source control map, including crack mask, edge information, depth information, and semantic prior, to form a unified feature representation; Introduce the MControlNet architecture as a condition control module, using the unified feature representation as the input of the MControlNet, and inject the MControlNet control conditions into the crack image generation process; Crack images that meet specified test requirements are generated based on spatial control conditions and MControlNet control conditions. S4. Test Label Generation and Packaging: Construct test labels based on the control conditions used in the image generation stage. Test labels must include at least the following: Crack location information, crack shape label, illumination and weather label, ground humidity label, occlusion ratio label, background complexity label, corresponding Coverage Unit number, and Prompt number; S5. Test Case Encapsulation and Storage: Generate images and their corresponding labels are uniformly encapsulated into standard test cases. Each test case includes at least: a UUID to uniquely identify the test sample; an ImagePath to store the path of the generated image; a MaskPath to record the corresponding control template; a CoverageUnitID to record the coverage unit to which the test sample belongs; a PromptID to establish the mapping relationship between text prompts and test samples; a SceneLabel to record scene attributes; a BoundingBox to record crack target bounding box information; and a HashValue to ensure the uniqueness and integrity of the test sample. After encapsulation, all test cases are uniformly stored in the test case library, and a UUID index and a Coverage Unit index are established. S6. Coverage verification and test report generation: Based on the test case library encapsulated in step S5, coverage statistics, requirement verification, and coverage report generation are performed on the test samples. A requirement-test case traceability matrix is ​​generated to evaluate the degree to which the current test case set meets the SysML requirement model, providing a basis for subsequent test case optimization. S7: Traceable verification and closed-loop feedback. Based on the coverage report and requirement-test case traceability matrix generated in step S6, perform coverage analysis on the current test case set and locate test requirements that do not meet coverage requirements. For test requirements that do not meet coverage requirements, identify the corresponding missing coverage units and test conditions, regenerate the corresponding text prompts and control conditions, and call step S3 to continue generating new test samples. The newly generated test samples execute steps S3 to S7 again until all test requirements meet the preset coverage requirements.

2. The intelligent test case generation method for crack detection according to claim 1, characterized in that, The specific method for defining the top-level major requirements and their derived minor requirements as described in step S1 is as follows: S11. Use SysML «requirement» to define two independent top-level requirements: coverage metric R-COV-000 and format / traceability metric R-IF-000. S12. Decompose R-COV-000 into secondary requirements. Through the SysML «deriveReqt» inheritance relationship, decompose R-COV-000 into the following secondary requirements, each of which inherits from R-COV-000. If the secondary requirements still need to be refined, deeper requirements can be derived until the hierarchy meets the requirements. S13. Decompose R-IF-000 into smaller requirements. Through the SysML «deriveReqt» inheritance relationship, decompose R-IF-000 into smaller requirements. Each smaller requirement inherits from R-IF-000.

3. The intelligent test case generation method for crack detection according to claim 1, characterized in that, The specific implementation method of step S2 is as follows: S21. Based on the SysML hierarchical requirement model described in step S1, automatically extract leaf requirement nodes, and generate a set of coverage units according to the requirement semantic type, composability constraints and coverage criteria. Each coverage unit represents a composite test scenario that can be used for subsequent image generation and test case construction. S22. Generate basic text input conditions for each coverage unit. Adopt an automatic conversion method from coverage unit to text input conditions based on a large language model to automatically convert structured coverage units into text input conditions with scene semantics. Combine this with a rule constraint mechanism to ensure that the generated results are consistent with the original test requirements.

4. The intelligent test case generation method for crack detection according to claim 3, characterized in that, The specific implementation method of step S21 is as follows: Step S211: Extract all leaf nodes of the smallest granularity requirements without child requirements from the SysML requirement model, i.e., leaf requirements, as the objects to be covered. Step S212: Divide the leaf requirements into multiple coverage dimensions according to semantic type, with each coverage dimension representing a variable factor in the test scenario; Step S213: Establish combination constraint rules based on the coverage dimension and generate candidate coverage units. Combine the leaf requirements in different coverage dimensions to form a set of candidate coverage units. Step S214: Filter the final coverage units based on the coverage target to ensure that they meet the following conditions: each leaf requirement is covered by at least one coverage unit; the combination relationship between different types of leaf requirements is covered as much as possible; coverage units that cover more uncovered requirements are selected first; if there are sample quantity or ratio requirements for certain parent requirements, the corresponding coverage units are generated repeatedly according to the requirements. Step S215, Coverage Integrity Verification: After the coverage unit is generated, a leaf requirement-coverage unit traceability matrix is ​​established to verify whether all leaf requirements have been covered.

5. The intelligent test case generation method for crack detection according to claim 1, characterized in that, The specific implementation method of step S3 is as follows: S31. Control template acquisition and spatial control condition generation: A control template library is pre-established, and control templates are selected from the control template library. Each control template in the template library corresponds to a real crack area. When a new test sample is generated, the system retrieves a control template that meets the conditions from the template library based on the crack type, crack scale and scene requirements in the current coverage unit, and uses it as a spatial control condition in the subsequent image generation process. S32, MControlNet control condition generation: The crack mask matching the current coverage unit is retrieved from the control template library. The adaptive conditional fusion module ACFB is introduced to perform feature layer weighted fusion of the multi-source control map, including crack mask, edge information, depth information and semantic prior, to form a unified conditional code. The conditional code is then injected into the latent space diffusion model as input condition of MControlNet. The crack image that meets the specified test requirements is generated in conjunction with the text prompt words.

6. The intelligent test case generation method for crack detection according to claim 5, characterized in that, The sources of the control template library include: real annotation information in existing publicly available crack datasets, including crack area control templates, crack outlines, crack target boxes, etc.; and crack images collected on engineering sites, which are manually annotated or generated from existing annotation results to form control templates, and are uniformly stored in the template library.

7. The intelligent test case generation method for crack detection according to claim 5, characterized in that, The adaptive conditional fusion module ACFB consists of a fusion module, an Encoder-Decoder structure, and a splitting module. The fusion module uses independent encoders to map k control images to a shared feature space, and combines them with an externally input spatial weight matrix to perform pixel-by-pixel weighted fusion to obtain fused features. The Encoder-Decoder structure enables compression and reconstruction from the fused features to the latent space; the splitting module splits the reconstructed features into reconstructed versions of the original control image for supervised learning.

8. The intelligent test case generation method for crack detection according to claim 5, characterized in that, In step S3, the latent space diffusion model consists of a forward diffusion process and a reverse generation process; During the forward diffusion process, the latent space diffusion model gradually adds Gaussian noise to the real samples, causing the data distribution to gradually evolve into a standard Gaussian distribution, and finally obtain approximate Gaussian noise. The forward diffusion process is a Markov process, given the data distribution. ,in, For the original sample, The data distribution of the original sample, ; It is a preset noise scheduling table that gradually changes from small to large, and corresponding noise is added and gradually increased, which can yield a series of intermediate variables. When T is large enough, the final result is The process for noise that approximately follows a Gaussian distribution is as follows: ， in: Represents a normal distribution; It is the identity matrix. The conditional probability distribution; Each step incorporates a certain amount of Gaussian noise, resulting in: ， ， in , , It follows a random Gaussian distribution; During the reverse generation process, the latent space diffusion model learns to gradually denoise random Gaussian noise and generate samples with a data distribution similar to the real samples. The reverse generation process starts with standard Gaussian noise and gradually removes noise from intermediate variables. This reverse generation process is a Markov process, which can be derived using Bayes' theorem: ， in It is the mean of a Gaussian distribution. , Let V be the variance of the Gaussian distribution. ; Original samples in actual reverse generation process Unknown, training deep neural networks to predict , This is random Gaussian noise added during the forward diffusion process to generate the current noisy sample; Then proceed with reverse generation: ， ， ， Initial noise samples are obtained by sampling from a standard Gaussian distribution. According to time steps The order is repeated, using the above formula to calculate the samples from the previous time step step by step, i.e., from get until the final generated sample is obtained. .

9. The intelligent test case generation method for crack detection according to claim 1, characterized in that, The specific implementation method of step S6 is as follows: S61, Test Case Coverage Statistics: First, traverse the test case library, read the coverage unit number and test label information corresponding to each test case, including attributes such as lighting conditions, ground humidity, crack shape, occlusion ratio, and background complexity, and classify and count them according to each coverage dimension. S62. Requirement Coverage Verification: After completing the statistics, perform coverage verification for each requirement based on the SysML requirement model established in step S1. For each requirement, the system extracts relevant data from the coverage statistics based on its corresponding preset quantitative indicators, and determines whether the current set of test cases meets the corresponding requirement. For quantity-based requirements, determine whether the sample size for the corresponding test conditions has reached the set threshold; For proportional requirements, calculate the proportion of the corresponding sample number to the total number of test cases and compare it with the proportion specified in the requirement model; for combined coverage requirements, determine whether corresponding test samples have been generated for each combination of coverage units. S63. Based on the «verify» relationship in SysML, test cases that meet the verification conditions are associated with corresponding requirements to form a requirement-test case mapping relationship. For requirements that do not meet the requirements, the system records the corresponding coverage gap, including missing test conditions, missing coverage unit combinations and current coverage level. The coverage gap serves as the basis for generating subsequent test data. S64. Coverage Report Generation: Automatically generate a coverage report based on coverage statistics and requirements verification results.

10. The intelligent test case generation method for crack detection according to claim 9, characterized in that, The coverage report shall include at least: statistical results of samples for each coverage dimension; coverage status of each coverage unit; verification results of compliance or non-compliance for each SysML requirement; requirement-test case traceability matrix; coverage gap analysis, including missing test conditions and combinations of coverage units; total number of test cases, coverage statistics, and report generation time and version number information.

Images