A closed-loop measurement and transmission coordination method, device, equipment and medium

Abstract

Embodiments of the present application provide a closed-loop test and development coordination method and device, equipment and medium, relating to the technical field of automobile electronic and electrical architecture. The present application realizes the integration and coordination of testing and development: through a model reference mode, a bidirectional synchronous association is established between the model reference test sequence and the source model. The modifications of the model logic made by the developer during the debugging process can be automatically synchronized to all model reference test sequences to which the model belongs, and the tester can quickly perform regression verification without reimporting test cases or reconstructing the test architecture, thereby greatly shortening the iteration cycle of development and testing and improving the efficiency of testing and development.

Description

Technical Field

[0001] This application relates to the field of automotive electronic and electrical architecture technology, and in particular to a closed-loop measurement and control coordination method, apparatus, device, and medium. Background Technology

[0002] With the dramatic increase in the complexity of automotive electronic and electrical architectures, Model-Based Design (MBD) has become the mainstream method for developing application-layer software for embedded software controllers. In traditional development processes, software model development and testing are typically handled by two separate departments: the development department is responsible for the design, implementation, and manual debugging of the software model, while the testing department is responsible for the design of test cases and the execution of automated scripts. In other words, manual debugging during the development phase and automated testing during the verification phase are usually two isolated activities.

[0003] However, due to the independence of testing and development, there is a serious information gap and execution disconnect between the two, resulting in low efficiency for both testing and development. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a closed-loop test and development collaborative method, apparatus, equipment, and medium that can improve the efficiency of testing and development.

[0005] The embodiments of this application disclose the following technical solutions: Firstly, this application discloses a closed-loop test-and-launch coordination method, the method comprising: Obtain the model test case set corresponding to the source model; The source model is set to model reference mode, and multiple model reference test sequences are created based on the source model; wherein each model reference test sequence corresponds to a test case in the model test case set; The source model is automatedly tested by executing the model reference test sequence to obtain test results; When it is determined from the test results that the source model has a logical defect, the source model is modified according to the logical defect to obtain an updated source model; wherein, the modification is synchronized to the multiple model reference test sequences based on the model reference pattern; Obtain supplementary test steps corresponding to the logical defect, and update the model test case set according to the supplementary test steps, so that the updated model test case set can be used for subsequent automated testing of the updated source model.

[0006] Optionally, before setting the source model to model reference mode and creating multiple model reference test sequences based on the source model, the method further includes: Perform the following connection operations on the source model: connect the input interface of the source model to the input control module, connect the output interface of the source model used to output continuous commands to the waveform observation module, and connect the output interface of the source model used to output discrete commands to the digital display module.

[0007] Optionally, the step of automatically testing the source model by executing the model reference test sequence to obtain test results includes: When a test error occurs or a specific test scenario is discovered during the execution of the model reference test sequence according to the timing of the automated test script, the execution of the automated test script is interrupted. The source model is then subjected to random divergence testing by modifying the variable values ​​of the input control module, and the test results are obtained through the waveform observation module or the digital display module.

[0008] Optionally, the method further includes: When performing automated testing on the source model, the state values ​​of at least one output variable and at least one intermediate variable in the source model are continuously acquired according to a preset sampling frequency, and a debug log is generated. When it is determined from the test results that the source model has a logical defect, the value sequence of the input variables that caused the logical defect is determined based on the state values ​​of the output variables and the intermediate variables recorded in the debugging log, so as to reproduce the fault scene.

[0009] Optionally, obtaining supplementary test steps corresponding to the logical defect and updating the model test case set according to the supplementary test steps includes: Obtain voice or text information of supplementary test steps entered by testers; The text information or the text description converted from the voice information is input into a pre-built use case parsing model to obtain the model variable names and value ranges output by the use case parsing model; wherein, the use case parsing model includes a pre-trained neural network model or a lookup and replace script based on the interface design table; Supplementary model test cases are generated based on the model variable names and the value ranges, and the supplementary model test cases are updated to the model test case set.

[0010] Secondly, this application discloses a closed-loop test and launch coordination device, the device comprising: an acquisition module, a creation module, a testing module, a modification module, and an update module; The acquisition module is used to acquire the model test case set corresponding to the source model; The creation module is used to set the source model to model reference mode and create multiple model reference test sequences based on the source model; wherein each model reference test sequence corresponds to a test case in the model test case set; The testing module is used to perform automated testing on the source model by executing the model reference test sequence and obtain test results. The modification module is used to modify the source model according to the logical defects when it is determined from the test results, thereby obtaining an updated source model; wherein the modification is synchronized to the multiple model reference test sequences based on the model reference pattern. The update module is used to obtain supplementary test steps corresponding to the logical defect, and update the model test case set according to the supplementary test steps, so that the updated model test case set can be used for subsequent automated testing of the updated source model.

[0011] Optionally, the device further includes: a connection module; The connection module is used to perform the following connection operations on the source model: connecting the input interface of the source model to the input control module, connecting the output interface of the source model used to output continuous commands to the waveform observation module, and connecting the output interface of the source model used to output discrete commands to the digital display module.

[0012] Optionally, the testing module is specifically used to: interrupt the execution of the automated testing script when a test error occurs or a specific test scenario is discovered during the execution of the model reference test sequence according to the timing of the automated testing script; perform random divergence testing on the source model by modifying the variable values ​​of the input control module; and obtain the test results through the waveform observation module or the digital display module.

[0013] Optionally, the device further includes: a log module and a reproduction module; The logging module is used to continuously acquire the status values ​​of at least one output variable and at least one intermediate variable in the source model according to a preset sampling frequency when performing automated testing on the source model, and generate debugging logs. The reproduction module is used to determine the value sequence of the input variables that cause the logical defect based on the state values ​​of the output variables and the intermediate variables recorded in the debugging log when it is determined that there is a logical defect in the source model according to the test results, so as to reproduce the fault scene.

[0014] Optionally, the update module is specifically used for: obtaining voice or text information of supplementary test steps entered by testers; inputting the text information or text description converted from the voice information into a pre-built test case parsing model to obtain the model variable names and value ranges output by the test case parsing model; wherein, the test case parsing model includes a pre-trained neural network model or a lookup and replace script based on an interface design table; generating supplementary model test cases according to the model variable names and value ranges, and updating the supplementary model test cases to the model test case set.

[0015] Thirdly, this application discloses a closed-loop test and launch coordination device, the device comprising: a memory and a processor; The memory is used to store programs; The processor is configured to execute the program to implement the various steps of the closed-loop test-and-launch coordination method as described in the first aspect.

[0016] Fourthly, this application discloses a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the various steps of the closed-loop test-and-send coordination method as described in the first aspect.

[0017] Compared with the prior art, this application has the following beneficial effects: This application provides a closed-loop test-development collaboration method, apparatus, device, and medium. The method includes: obtaining a model test case set corresponding to a source model; setting the source model to a model reference mode and creating multiple model reference test sequences based on the source model; wherein each model reference test sequence corresponds to a test case in the model test case set; performing automated testing on the source model by executing the model reference test sequences to obtain test results; when it is determined from the test results that the source model has a logical defect, modifying the source model according to the logical defect to obtain an updated source model; wherein the modification is synchronized to multiple model reference test sequences based on the model reference mode; obtaining supplementary test steps corresponding to the logical defect, and updating the model test case set according to the supplementary test steps so that the updated model test case set can be used for subsequent automated testing of the updated source model. Thus, this application achieves integrated collaboration between testing and development: through the model reference mode, a bidirectional synchronous association is established between the model reference test sequences and the source model. Modifications made by developers to the model logic during debugging can be automatically synchronized to all model reference test sequences to which the model belongs. Testers can quickly perform regression verification without re-importing test cases or refactoring the test architecture, thereby greatly shortening the iteration cycle of development and testing and improving the efficiency of testing and development. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating a closed-loop test-and-send coordination method provided in this application embodiment; Figure 2 A schematic diagram of a closed-loop test-and-launch collaborative interface provided in an embodiment of this application; Figure 3 A flowchart of a closed-loop test-launch collaboration based on model referencing is provided for embodiments of this application; Figure 4 A schematic diagram illustrating the entire closed-loop test-launch coordination process provided in this application embodiment; Figure 5 A schematic diagram of a closed-loop test-and-release collaborative update process provided in an embodiment of this application; Figure 6 A schematic diagram of a closed-loop measurement and transmission coordination device provided in an embodiment of this application; Figure 7 This is a schematic diagram of a computer-readable medium provided in an embodiment of this application. Detailed Implementation

[0020] As described earlier, software model development and testing are typically handled collaboratively by two separate departments: the development department is responsible for the design, implementation, and manual debugging of the software model, while the testing department is responsible for the design of test cases and the execution of automated scripts. In other words, manual debugging during the development phase and automated testing during the verification phase are usually two isolated activities. However, this independence between testing and development leads to significant information gaps and execution disconnects, resulting in low efficiency for both.

[0021] Through research, the inventors have provided a closed-loop collaborative testing and development method, apparatus, device, and medium. This application achieves integrated collaboration between testing and development: through a model referencing pattern, a bidirectional synchronous association is established between the model referencing test sequence and the source model. Modifications to the model logic made by developers during debugging are automatically synchronized to all model referencing test sequences belonging to that model. Testers can quickly perform regression verification without re-importing test cases or refactoring the test architecture, thereby greatly shortening the iteration cycle of development and testing and improving the efficiency of both.

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

[0023] See Figure 1 The figure is a flowchart of a closed-loop test-launch coordination method provided in an embodiment of this application. This method can be applied to model-based development environments (such as the MATLAB / Simulink platform), and specifically includes: S101: Obtain the model test case set corresponding to the source model.

[0024] The source model refers to the embedded software model to be tested and verified. It is usually built by developers using Model-Based Design (MBD) tools, such as the application layer logic model of the vehicle domain controller built in Simulink.

[0025] A model test case set refers to a pre-built dataset for automated testing and verification of a source model. It includes at least one model test case, which verifies whether the source model's logical behavior under specific input stimuli meets expectations. Specifically, a model test case includes input stimulus definitions, expected output definitions, and test step descriptions.

[0026] Input stimulus definition describes the value or change sequence of variables applied to each input interface of the source model on the timeline of test execution, accurately reproducing specific test scenarios. Expected output definition describes the desired value that each output interface of the source model should produce at the corresponding time under given input stimulus, serving as a direct criterion for determining whether a test case passes. Test procedure description refers to the explanation of the test operation process recorded in natural or structured language, facilitating developers and testers to understand the test intent and operational logic of the current test case from a functional application perspective. For example, for a turn signal control model, a typical model test case is: at t=0s, set the left turn signal switch corresponding to the TurnLeverLeftSts to 1, and at t=3s, set it to 0, verifying that the output signal LeftTurnLampCmd remains 1 during the period from 0 to 3s.

[0027] It should be noted that the model test case set can be stored in formats such as Excel spreadsheets or MAT data files for automated script loading and execution. This application does not impose any restrictions on this.

[0028] S102: Set the source model to model reference mode and create multiple model reference test sequences based on the source model; wherein each model reference test sequence corresponds to a test case in the model test case set.

[0029] To achieve deep collaboration between testing and development, the simulation properties of the source model are set to ModelReference mode, and then multiple model reference test sequences (Harness) are created based on the source model.

[0030] Model referencing is a low-level architecture-level linking mechanism that allows an independent model file to be referenced by other top-level models or testing frameworks, rather than simply being copied and pasted. Model referencing offers the following benefits: First, when a developer manually debugs any model referencing test sequence and discovers a logical defect, directly modifying the model logic referenced within that test sequence, the modification will instantly penetrate the referencing hierarchy and automatically update the original file of the source model. Second, conversely, if a developer directly modifies the source model after receiving test feedback, the model logic referenced in all created model referencing test sequences will be synchronously refreshed.

[0031] A model reference test sequence refers to a test framework model that maintains a reference link relationship with the source model under test, and is used to carry specific test cases and observation modules.

[0032] See Figure 2 This figure is a schematic diagram of a closed-loop test-and-launch collaborative interface provided in an embodiment of this application. Figure 2 As shown, the closed-loop test and development collaboration interface includes a manual debugging area and a model testing area. The manual debugging area supports developers in modifying the source model, recording debugging logs, and performing manual divergence testing, obtaining test results through waveform observation or digital display. The model testing area is used for test preparation, importing model test cases, executing automated tests, and updating test cases driven by supplementary test steps.

[0033] It should be noted that this application also includes preprocessing of the external visualization interface of the source model before creating the model reference test sequence: Connect the input interface of the source model to the input control module. For example, in the MATLAB / Simulink library browser, this input control module can be implemented using the Const module in Simulink.

[0034] Furthermore, the output interface in the source model used to output continuous commands is connected to the waveform observation module. For example, this waveform observation module can be implemented using the Scope module in Simulink. The continuous command typically refers to a physical quantity signal that changes continuously over time (e.g., vehicle speed signal, analog voltage sample value, etc.). If the waveform observation module displays multiple overlapping output lines when corresponding to multiple interface inputs, multiple windows can be set to independently display each curve.

[0035] Furthermore, the output interface in the source model used to output discrete commands is connected to the digital display module. For example, this digital display module can be implemented using the Disp module or Display module in Simulink. Discrete commands typically refer to status variables such as switch status, mode identifier bits, and fault codes (e.g., left turn signal switch status LeftLampSts=1).

[0036] Therefore, through the above connection, when a model reference test sequence is created based on the source model, the input control module, waveform observation module, and digital display module are automatically reused in each test sequence, enabling the automated testing process to have visual observation capabilities and providing an interactive interface for subsequent manual divergence testing.

[0037] See Figure 3 This figure is a flowchart of a closed-loop test-and-launch collaborative process based on model referencing, provided in an embodiment of this application. Figure 3As shown, the source model (e.g., turn signal control model.slx) is at the core of the entire collaborative architecture. First, the source model is set to model reference mode, and multiple model reference test sequences (Harness 1, Harness 2…Harness N) are created based on this source model, each corresponding to a model test case. The model test case set stores all automated test cases to be executed and is loaded into each test sequence through the test case import module. During automated test execution, if an error occurs in a test sequence or a developer discovers a suspicious scenario, the automated process can be immediately interrupted, switching to the manual debugging module. In the manual debugging module, developers perform divergent testing by modifying the values ​​of the input control module and observe the output response in real time through the waveform observation module. They can also use the operation step recording function to record the operation sequence for reproduction. When a logical defect is determined in the source model, developers can directly modify the model logic in any test sequence. Due to the bidirectional synchronization mechanism of the model reference mode (marked with double arrows in the diagram), this modification will be automatically synchronized to the source model ontology file and simultaneously updated to all other test sequences, without needing to re-import test cases one by one. In addition, supplementary test steps discovered during manual debugging or functional testing are transformed into supplementary model test cases through the test case parsing module and updated to the model test case set (indicated by the dashed feedback arrow in the figure), thus forming a closed-loop update of test cases and ensuring that subsequent regression testing can cover newly discovered scenarios.

[0038] S103: Automated testing of the source model is performed by executing the model reference test sequence to obtain test results.

[0039] First, to ensure the purity and simplicity of the test environment, after all other parallel processes are shut down, click the automated script to execute the test, and execute the model reference test sequence sequentially.

[0040] During the execution of the automated test script, if any of the following triggering conditions occur, the execution of the automated test script will be interrupted and switched to manual debugging mode: Condition 1: The Verify function in the automated test script detects that the actual value of the output variable does not match the expected output definition, i.e., a test error occurs. Condition 2: When observing the waveform in the waveform observation module, the developer subjectively discovers that the waveform shape is suspicious even though a Verify error has not been triggered, or the developer wants to conduct additional boundary exploration for a specific combination of variables based on experience, i.e., a specific test scenario is discovered.

[0041] When the execution of the automated test script is interrupted, developers can perform random divergent testing on the source model by modifying the variable values ​​of the input control module, and obtain the test results through the waveform observation module or digital display module. This achieves an organic combination of the accuracy of automated testing and the flexibility of manual debugging.

[0042] For example, in turn signal testing, if the automated script only tests the standard scenario of "left turn signal on for 3 seconds and then off," but the developer, while viewing the waveform in the waveform observation module, considers the scenario that "rapidly switching the right turn lever during the left turn signal flashing might cause a state machine conflict," then the developer can manually change the value of the input control module corresponding to the "right turn lever switch" from 0 to 1 in a paused or stepped simulation state and observe the response changes in the waveform observation module or digital display module.

[0043] S104: When it is determined from the test results that there is a logical defect in the source model, the source model is modified according to the logical defect to obtain an updated source model; wherein, the modification is synchronized to multiple model reference test sequences based on the model reference pattern.

[0044] When test results indicate a logical flaw in the source model, developers can directly modify the internal logic of the referenced model within the currently erroneous model reference test sequence without shutting down the test environment. Due to the bidirectional synchronization mechanism of the model reference pattern, this modification will be automatically synchronized to the source model ontology file and simultaneously updated in all other model reference test sequences. This "one-stop change" mechanism significantly shortens the iteration time of regression testing.

[0045] It should be noted that after obtaining the updated source model, the logical changes in the source model can be compared and confirmed with the updated content of the model test case set to ensure the consistency and traceability of the updated content when collaborating with multiple people.

[0046] S105: Obtain the supplementary test steps corresponding to the logical defects, and update the model test case set according to the supplementary test steps so that the updated model test case set can be used for subsequent automated testing of the updated source model.

[0047] During actual testing, testers may discover new test scenarios not covered by pre-defined test cases during manual debugging, functional testing, or real-vehicle testing. These supplementary test steps can be entered via voice or text. Specifically, first, the voice or text information of the supplementary test steps entered by the tester is obtained. Then, the text information, or a text description converted from the voice information, is input into a pre-built test case parsing model to obtain the model variable names and value ranges output by the test case parsing model. The test case parsing model includes a pre-trained neural network model or a lookup and replace script based on an interface design table. This test case parsing model is essentially an adaptive translation system, capable of converting text into variable descriptions and valid value ranges (generating model test cases), or conversely, converting operational variable descriptions into text descriptions (generating functional test cases). For example, the pseudocode for this step can be as follows: for i=1:size(input,1) if input(i) == design interface table(i, 1) % Match the Chinese characters in the function description then output(i) = Design Interface Table(i, 2); % Outputs the English variable names and values ​​of the model end End Finally, supplementary model test cases are generated based on the model variable names and value ranges, and these supplementary model test cases are updated to the model test case set. For example, through the test case parsing model, functional test step descriptions (e.g., "door / window open / close manually") can be converted into model test case format (e.g., "WindowSW=1"). This generates supplementary model test cases, which are then updated to the model test case set. The newly added model test cases are then persistently stored in the test case set file (e.g., an Excel spreadsheet or MAT file) in step S101 and are automatically loaded and executed the next time automated testing is performed.

[0048] It should also be noted that this application provides a technical means for automatically capturing and reproducing intermittent faults: First, when manually debugging or automatically testing the source model, the intermediate variables that need to be monitored are connected to the terminal interface, and then connected to the data export module (e.g., the To Workspace module in the MATLAB / Simulink environment) together with the output interface. The state values ​​of at least one output variable and at least one intermediate variable in the source model are continuously acquired according to a preset sampling frequency, and a debugging log is generated. It should be noted that a higher sampling frequency results in denser data recording (too much data maintaining the same state may reduce troubleshooting efficiency), while a lower sampling frequency results in sparser data (which may miss data at critical turning points). Typically, the sampling frequency can be set to the scheduling cycle of the embedded software (e.g., 10ms). Subsequently, when the test results determine that the source model has a logical defect, the value sequence of the input variable causing the logical defect is determined based on the state values ​​of the output and intermediate variables recorded in the debugging log, in order to reproduce the fault scene. For example, in testing a turn signal model, if the debug log records that at a certain moment the output variable LeftTurnLampCmd experienced an unexpected brief flip, while the value of the intermediate variable DebounceCounter returned to zero from a certain threshold, developers can analyze the correlation between the variable states before and after that moment in the log to accurately deduce that it was caused by a very short-lived jitter in the input variable TurnLeverLeftSts. Thus, even a once-in-a-lifetime, sporadic defect can be permanently fixed as a regression test case, ensuring that the fixed model will not experience the same type of failure again in any subsequent changes.

[0049] During manual debugging, this invention also provides an operation step recording function. See [link / reference] Figure 2 The manual debugging area includes recording controls such as start recording, pause recording, end recording, fault scene playback, analysis, and deletion of recording logs. When a problem is discovered by chance, the current operation sequence can be interrupted with one click and saved. The playback function can then accurately reproduce the problem, completely solving the pain point of the difficulty in reproducing occasional problems.

[0050] See Figure 4 This figure is a schematic diagram of a closed-loop test-launch coordination process provided in an embodiment of this application. Figure 4As shown, the entire test-development collaboration process begins with the initial development and debugging phase of the source model. In this phase, developers manually debug and perform divergent testing on the source model based on input control modules and output observation modules (such as the Const and Scope modules) to initially verify the model's basic logic. This is followed by the first round of automated testing. The pre-built model test case set 1 is loaded into each model reference test sequence via an automatic import program, executing the first round of automated testing. During the model update and debugging phase, automated testing is performed based on the model reference test sequences. If logical defects or suspicious scenarios are found during testing, the automated process is interrupted, and manual debugging and divergent testing based on input control and output observation are initiated. After locating the problem, the model logic is directly modified. Due to the bidirectional synchronization mechanism of the model reference mode, model modifications are automatically synchronized to all test sequences. Simultaneously, based on supplementary test steps discovered during testing, model test case set 2 is updated on the original model test case set 1. Finally, the updated model test case set 2 is re-imported into the model reference test sequence, and regression testing is performed to verify the effectiveness of defect fixes and the coverage of newly added test cases. This forms a complete closed loop of "development → testing → debugging → update → regression".

[0051] See Figure 5 This figure is a schematic diagram of a closed-loop test-and-release collaborative update process provided in an embodiment of this application. Figure 5 As shown, after completing test preparation, test case import, and automated testing, when supplementary test steps are generated during manual debugging or functional testing, these supplementary test steps can be input into the manual debugging and model update module to generate updated functional test cases or updated model test cases. The updated model test cases can be re-imported into the automated testing process for subsequent regression testing of the updated source model; the updated functional test cases can be synchronously output to the testing side for subsequent functional verification. This achieves a closed-loop update of test cases between automated testing, manual debugging, and functional testing.

[0052] It should also be noted that the method of this application can also be applied to model version management. In project development, there are typically two versions of the model: a production version used for code generation and a temporary version used for debugging. These often become inconsistent due to asynchronous modifications. By applying the method of this application, the debug version model can be used as a model reference for the production version model. In this way, any modifications made to the model logic in the debug version will be automatically updated to the production version model based on the synchronization mechanism of the model reference pattern, thus ensuring logical consistency between the debug and production versions and avoiding potential problems caused by version inconsistencies.

[0053] In summary, this application discloses a closed-loop test-development collaboration method, which achieves integrated collaboration between testing and development: through a model referencing pattern, a bidirectional synchronous association is established between the model referencing test sequence and the source model. Modifications to the model logic made by developers during debugging are automatically synchronized to all model referencing test sequences to which that model belongs. Testers can quickly perform regression verification without re-importing test cases or refactoring the test architecture, thereby greatly shortening the iteration cycle of development and testing and improving the efficiency of both.

[0054] See Figure 6 The figure is a schematic diagram of a closed-loop test-launch coordination device provided in an embodiment of this application. The closed-loop test-launch coordination device 200 includes: an acquisition module 201, a creation module 202, a testing module 203, a modification module 204, and an update module 205.

[0055] Module 201 is used to obtain the model test case set corresponding to the source model; Create module 202 to set the source model to model reference mode and create multiple model reference test sequences based on the source model; each model reference test sequence corresponds to a test case in the model test case set; Test module 203 is used to perform automated testing on the source model by executing the model reference test sequence and obtain test results; Modification module 204 is used to modify the source model according to the logical defects when it is determined from the test results, so as to obtain an updated source model; wherein, the modification is synchronized to multiple model reference test sequences based on the model reference mode. The update module 205 is used to obtain supplementary test steps corresponding to the logical defects and update the model test case set according to the supplementary test steps so that the updated model test case set can be used for subsequent automated testing of the updated source model.

[0056] In one specific implementation, the closed-loop measurement and transmission coordination device 200 further includes: a connection module; The connection module is used to perform the following connection operations on the source model: connect the input interface of the source model to the input control module, connect the output interface of the source model used to output continuous commands to the waveform observation module, and connect the output interface of the source model used to output discrete commands to the digital display module.

[0057] In one specific implementation, the test module 203 is specifically used to: interrupt the execution of the automated test script when a test error occurs or a specific test scenario is discovered during the execution of the model reference test sequence according to the timing of the automated test script; perform random divergence testing on the source model by modifying the variable values ​​of the input control module; and obtain the test results through the waveform observation module or the digital display module.

[0058] In one specific implementation, the closed-loop test and release coordination device 200 further includes: a log module and a reproduction module; The logging module is used to continuously acquire the status values ​​of at least one output variable and at least one intermediate variable in the source model at a preset sampling frequency during automated testing of the source model, and generate debug logs. The reproduction module is used to determine the sequence of values ​​of the input variables that caused the logical defect when the source model is determined to have a logical defect based on the status values ​​of the output variables and intermediate variables recorded in the debugging log, so as to reproduce the fault scene.

[0059] In one specific implementation, the update module 205 is specifically used to: obtain voice or text information of supplementary test steps entered by testers; input the text information or text description converted from voice information into a pre-built test case parsing model to obtain the model variable names and value ranges output by the test case parsing model; wherein, the test case parsing model includes a pre-trained neural network model or a lookup and replace script based on the interface design table; generate supplementary model test cases according to the model variable names and value ranges, and update the supplementary model test cases to the model test case set.

[0060] In summary, this application discloses a closed-loop test-development collaboration device, which achieves integrated collaboration between testing and development: through a model referencing pattern, a bidirectional synchronous association is established between the model referencing test sequence and the source model. Modifications to the model logic made by developers during debugging are automatically synchronized to all model referencing test sequences to which that model belongs. Testers can quickly perform regression verification without re-importing test cases or refactoring the test architecture, thereby greatly shortening the iteration cycle of development and testing and improving the efficiency of both.

[0061] This application also provides a corresponding closed-loop test-launch coordination device and a computer-readable medium for implementing the closed-loop test-launch coordination method provided in this application.

[0062] The closed-loop test-and-deployment coordination device includes a memory and a processor. The memory is used to store instructions or code, and the processor is used to execute the instructions or code so that the device performs a closed-loop test-and-deployment coordination method according to any embodiment of this application.

[0063] See Figure 7 This figure is a schematic diagram of a computer-readable medium provided in an embodiment of this application. The computer-readable medium 300 stores a computer program 311, which, when executed by a processor, implements the above-described... Figure 1 The steps of the closed-loop measurement and development collaborative method.

[0064] It should be noted that, in the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0065] It should be noted that the machine-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0066] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0067] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

[0068] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0069] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A closed-loop measurement and transmission coordination method, characterized in that, The method includes: Obtain the model test case set corresponding to the source model; The source model is set to model reference mode, and multiple model reference test sequences are created based on the source model; wherein each model reference test sequence corresponds to a test case in the model test case set; The source model is automatedly tested by executing the model reference test sequence to obtain test results; When it is determined from the test results that the source model has a logical defect, the source model is modified according to the logical defect to obtain an updated source model; wherein, the modification is synchronized to the multiple model reference test sequences based on the model reference pattern; Obtain supplementary test steps corresponding to the logical defect, and update the model test case set according to the supplementary test steps, so that the updated model test case set can be used for subsequent automated testing of the updated source model.

2. The method according to claim 1, characterized in that, Before setting the source model to model reference mode and creating multiple model reference test sequences based on the source model, the method further includes: Perform the following connection operations on the source model: connect the input interface of the source model to the input control module, connect the output interface of the source model used to output continuous commands to the waveform observation module, and connect the output interface of the source model used to output discrete commands to the digital display module.

3. The method according to claim 2, characterized in that, The step of automatically testing the source model by executing the model reference test sequence and obtaining test results includes: When a test error occurs or a specific test scenario is discovered during the execution of the model reference test sequence according to the timing of the automated test script, the execution of the automated test script is interrupted. The source model is then subjected to random divergence testing by modifying the variable values ​​of the input control module, and the test results are obtained through the waveform observation module or the digital display module.

4. The method according to claim 1, characterized in that, The method further includes: When performing automated testing on the source model, the state values ​​of at least one output variable and at least one intermediate variable in the source model are continuously acquired according to a preset sampling frequency, and a debug log is generated. When it is determined from the test results that the source model has a logical defect, the value sequence of the input variables that caused the logical defect is determined based on the state values ​​of the output variables and the intermediate variables recorded in the debugging log, so as to reproduce the fault scene.

5. The method according to claim 1, characterized in that, The step of obtaining supplementary test steps corresponding to the logical defect and updating the model test case set according to the supplementary test steps includes: Obtain voice or text information of supplementary test steps entered by testers; The text information or the text description converted from the voice information is input into a pre-built use case parsing model to obtain the model variable names and value ranges output by the use case parsing model; wherein, the use case parsing model includes a pre-trained neural network model or a lookup and replace script based on the interface design table; Supplementary model test cases are generated based on the model variable names and the value ranges, and the supplementary model test cases are updated to the model test case set.

6. A closed-loop measurement and transmission coordination device, characterized in that, The device includes: an acquisition module, a creation module, a testing module, a modification module, and an update module; The acquisition module is used to acquire the model test case set corresponding to the source model; The creation module is used to set the source model to model reference mode and create multiple model reference test sequences based on the source model; wherein each model reference test sequence corresponds to a test case in the model test case set; The testing module is used to perform automated testing on the source model by executing the model reference test sequence and obtain test results. The modification module is used to modify the source model according to the logical defects when it is determined from the test results, thereby obtaining an updated source model; wherein the modification is synchronized to the multiple model reference test sequences based on the model reference pattern. The update module is used to obtain supplementary test steps corresponding to the logical defect, and update the model test case set according to the supplementary test steps, so that the updated model test case set can be used for subsequent automated testing of the updated source model.

7. The apparatus according to claim 6, characterized in that, The device further includes: a connection module; The connection module is used to perform the following connection operations on the source model: connecting the input interface of the source model to the input control module, connecting the output interface of the source model used to output continuous commands to the waveform observation module, and connecting the output interface of the source model used to output discrete commands to the digital display module.

8. The apparatus according to claim 7, characterized in that, The testing module is specifically used to: interrupt the execution of the automated testing script when a test error occurs or a specific test scenario is discovered during the execution of the model reference test sequence according to the timing of the automated testing script; perform random divergence testing on the source model by modifying the variable values ​​of the input control module; and obtain the test results through the waveform observation module or the digital display module.

9. A closed-loop measurement and transmission coordination device, characterized in that, The device includes: a memory and a processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the closed-loop test-and-launch coordination method as described in any one of claims 1 to 5.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements each step of the closed-loop measurement and transmission coordination method as described in any one of claims 1 to 5.

Images