CN116204420A - Stable generation method for module-level Simulink test case - Google Patents

Stable generation method for module-level Simulink test case Download PDF

Info

Publication number
CN116204420A
CN116204420A CN202310045492.5A CN202310045492A CN116204420A CN 116204420 A CN116204420 A CN 116204420A CN 202310045492 A CN202310045492 A CN 202310045492A CN 116204420 A CN116204420 A CN 116204420A
Authority
CN
China
Prior art keywords
module
tested
modules
tested software
test case
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310045492.5A
Other languages
Chinese (zh)
Inventor
郭世凯
王子轩
刘昭维
任虹燕
李晓晨
江贺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dalian Maritime University
Original Assignee
Dalian Maritime University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dalian Maritime University filed Critical Dalian Maritime University
Priority to CN202310045492.5A priority Critical patent/CN116204420A/en
Publication of CN116204420A publication Critical patent/CN116204420A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

The invention discloses a stable generation method of a module-level Simulink test case, which comprises the following steps: constructing a software module to be tested; sequencing all minimum unit standard modules in an official module library in the tested software; generating all modules from the official module library of the tested software; operating the tested use case, if the compiling fails, deleting a module link group causing the compiling failure; recording the information of the module link group in the tested case which is successfully operated into a tested software module analysis database; repeating the operation until all minimum unit standard modules in the official module library in the tested software are traversed; and in the stage of randomly generating the test cases, randomly generating an initial module capable of generating signals from a official module library of the tested software, inputting information of the module into a tested software module analysis database to inquire the link condition of the module, storing the generated test cases after the operation is successful, discarding the test cases after the operation is successful, and counting the generation rate of the test cases.

Description

Stable generation method for module-level Simulink test case
Technical Field
The invention relates to the field of software testing, in particular to a module-level Simulink test case stable generation method.
Background
As a commercial CPS development tool chain, simulink has been widely used to design, simulate and generate embedded code for CPS models in many security critical applications. In the Simulink development tool chain, a user designs a Simulink model as a block diagram. It analyzes, compiles and executes the CPS model to simulate the behavior of CPS before transferring to hardware. And when the simulation meets the user expectation, automatically generating embedded codes by the Simulink, and deploying the embedded codes into the target application program. The development process described above allows users to quickly build CPS prototypes and deploy applications without writing code. While the Simulink compiler is the most important part of the Simulink development tool chain, the consequences of errors are not envisaged. In order to reduce the probability of errors of the Simulink compiler, tests for the Simulink compiler are gradually raised at present.
The existing methods for generating a Simulink test case model in a Simulink development tool chain are represented by SLforge, and the random model generation and the random generation based on machine learning are guided based on a semi-formal Simulink model specification, so that the method has the defects that a complete generation specification is required to be provided for improving the success rate of model generation, meanwhile, the methods refer to the existing real model, so that the generated model mainly depends on the existing model, and the model generated model has limitation.
Disclosure of Invention
According to the problems existing in the prior art, the invention discloses a stable generation method of a module-level Simulink test case, which specifically comprises the following steps:
constructing a tested software module, and analyzing the link condition of each minimum unit standard module in the database for storing the tested software;
sequencing all minimum unit standard modules in an official module library in the tested software, extracting a module A without heavy sample from the module A, and copying to generate a plurality of modules A, so that the number of the modules A is equal to the number of all minimum unit standard modules in the tested software;
generating all modules from the official module library of the tested software, correspondingly linking each module to the module A in the test case, and enabling each module A to be linked with a non-repeated module to form a module link group;
operating the tested use case, if the compiling fails, deleting a module link group causing the compiling failure;
recording the information of the module link group in the tested case which is successfully operated into a tested software module analysis database;
repeating the operation until all minimum unit standard modules in the official module library in the tested software are traversed;
a test case randomly generating stage, namely randomly generating an initial module capable of generating signals from a official module library of tested software, inputting information of the module into a tested software module analysis database to inquire the link condition of the module, randomly picking out the linkable module from the module to generate, and the like to generate a tested case;
and (5) running the generated test cases, storing if the running is successful, discarding if the compiling is failed, and counting the generation rate of the tested cases.
The tested software module analyzes the link condition of each minimum unit standard module in the database and stores the link condition in the form of a database table, wherein the information of the main record comprises the name information of the departure module and the name information of the arrival module.
The minimum unit standard module is a module which cannot be continuously split and is given in an official module library, the initial module is a signal generation module, and some modules which can generate signals in tested software.
The module a is linked with other modules in such a way that the module a is the side closer to the signal input, and the input ports of the other modules are linked to the output port of the module a through signal lines.
The departure module is a module which is positioned on the signal inflow side or is closer to the signal inflow side when linked, and the arrival module is a module which is positioned on the information outflow side or is closer to the signal outflow side.
By adopting the technical scheme, the stable generation method of the module-level Simulink test case provided by the invention has the advantages that a large number of combined compilations are carried out on each module in the early stage, and the successfully compilations of module combinations are screened and recorded, so that the defect that the tested software Simulink cannot stably guide the generation of a model because no effective language specification is overcome. The method guides the generation of the test cases of the tested software in the follow-up process, greatly improves the success rate of the overall compiling after the test cases are generated, has great significance for the generation of the tested software model, and provides a large number of available test case sets for the follow-up work of the tested software test.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of the method of the present invention;
FIG. 2 is a schematic diagram of module batch generation and linking in accordance with the present invention;
FIG. 3 is a schematic diagram of model generation in accordance with the present invention.
Detailed Description
In order to make the technical scheme and advantages of the present invention more clear, the technical scheme in the embodiment of the present invention is clearly and completely described below with reference to the accompanying drawings in the embodiment of the present invention:
as shown in fig. 1, a flow chart of a module level Simulink test case stability generation method is shown, and the specific scheme is as follows:
in step S101: constructing a software module analysis database to be tested;
the software module analysis database to be tested can be constructed by, but not limited to, constructing by Mysql, constructing an empty database, and then creating a database table, wherein three fields in the database table are a primary key and departure module information respectively, and arrival module information. Taking Simulink as an example, the generation module may use a special official API, and there are usually various ways, such as knowing the module name to be generated, and then the departure module information and the arrival module information in the tested software may be specific names of the modules. The definition of a departure module and an arrival module is that the departure module generally obtains a signal faster than the arrival module and flows the signal into an input port of the arrival module through an output port of the departure module, and the departure module is connected with the arrival module through one or more signal lines.
In the subsequent step, if the analysis data of the tested software module in the analysis database of the tested software module is required to be added, the above specification is required to be met, that is, the information of the departure module and the arrival module is collected, and the analysis database of the tested software module is not allowed to be added for repeated information, so that each module can be generated with equal probability in the subsequent step.
In step S102: the module generates and links the verification in batches;
specifically, in the step, all the minimum unit standard modules in the official module library in the tested software are ordered, the modules without repeated samples are extracted from the modules, and a plurality of the modules are generated by copying, so that the number of the modules is equal to the number of all the minimum unit standard modules in the tested software. Generating all modules from the official module library of the tested software, correspondingly linking each module to the module in the test case, and enabling each module to be linked with a non-repeated module to form a module linking group; as shown in fig. 2, the module a 21 is a basic module which can only be selected randomly from the official module library in the software under test by the method, and is not composed of other basic modules, and performs specific tasks in the model. By copying the information of the module for multiple times, a plurality of identical modules such as a module A23, a module A25 and the like are generated, and the number of the modules is equal to the total number of the modules of an official module library in the tested software and is used for carrying out one-to-one matching on the modules in the subsequent link verification stage. And generating all modules from the official module library of the tested software, wherein the modules are only generated once. And the generated modules are connected with the module A, and the method is illustrated as a module B22, a module C24 and a module D26 which are a miniature image of all the modules and represent the modules which execute various functions in the tested software (the module A is possibly generated, and the module A is allowed). And carrying out one-to-one matching and linking on the modules generated after the generation and the modules A generated in batches, wherein each group only comprises two modules, namely the modules A and other modules. It is emphasized that some modules do not have input ports and cannot support chaining with module a, and the method automatically eliminates these modules and marks them as signaling modules. For a module without an output port, the method is called a signal termination module, and when the subsequent module A meets the requirement of the signal termination module, we will skip and not discuss.
In step S103: collecting analysis data of a tested software module;
when the steps are finished, the test case is operated, and if the test case is operated normally, the existing link information in the test case is recorded into the analysis database of the tested software module. If the operation fails and generates error information, deleting the module link group which causes the error information to be generated until the operation is normal and no error information is generated. The concept of normal operation and error information will be standardized and described in step S105, and the information required to be recorded into the analysis database of the software module under test is also described in step S101, and will not be described in detail here.
Step S102 and step S103 need to be carried out once on all modules in the official module library of the tested software, and record;
in step S104: randomly generating a model;
at present, the tested software module analyzes the module link information of all modules in the database recorded tested software official module library, and after operation verification, the links among the modules can be confirmed to meet the requirements of the tested software, and a feasible and effective specification is theoretically provided for the accuracy of the random generation of the model. In the random generation stage of the model, a signal emitting module (particularly a module capable of autonomously generating other signals such as linearity, nonlinearity and the like) is randomly found in an official module library of the tested software, and the module has the characteristics that an input port is not provided, and the module is a direct and indirect source of the signals of the other modules), and the information of the signal emitting module is input into a starting module field in an analysis database table of the tested software module for searching, wherein the searching content is an arrival module field. The method comprises the steps that the found random module field is randomly sampled according to the maximum output port number supported by a current signal sending module, the number of the generated new modules is smaller than or equal to the maximum output port number of the signal sending module, and in addition, the random sampling method is consistent with the random sampling mentioned in other methods, and no special operation exists. As shown in fig. 3, the module a31 is a signal emitting module, and according to the maximum number of output ports, we randomly generate other modules such as a module B32, a module C33, a module D34, and the like, and link them to the module a31 by a direct link mode. After that, the information of the modules such as the module B32, the module C33 and the module D34 is also input into the starting module field in the analysis database of the tested software module for searching, the modules are generated according to the method, the generated modules are linked to the module B32 and the module C33, and after the module D34, the modules are repeatedly circulated and reciprocated, and the tree fork type generation mode is presented. Until the number generated reaches the number required by the method in the test case (this number is usually set by the engineer itself).
In step S105: model operation and recording;
specifically, the test case models which are randomly generated are operated in each simulation mode of tested software (especially Simulink), the models which can be normally operated and do not generate error information are collected, information such as names, operation time and the like is recorded, and finally the random generation probability of the test case models is calculated in a mode that the number of the test case models which can be normally operated is divided by the total number of the test case models which are randomly generated. It should be emphasized that the error information covers the prompt information that the tested software crashes and pops up due to the test case, the generated test case model does not conform to the test software specification, and pops up the compiling information that pops up when the compiling fails, and also covers various situations that the test case operation can not be terminated due to exceeding time, and the tested software is forced to be closed.
The foregoing is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art, who is within the scope of the present invention, should make equivalent substitutions or modifications according to the technical scheme of the present invention and the inventive concept thereof, and should be covered by the scope of the present invention.

Claims (5)

1. A module-level Simulink test case stable generation method is characterized by comprising the following steps:
constructing a tested software module, and analyzing the link condition of each minimum unit standard module in the database for storing the tested software;
sequencing all minimum unit standard modules in an official module library in the tested software, extracting a module A without heavy sample from the module A, and copying to generate a plurality of modules A, so that the number of the modules A is equal to the number of all minimum unit standard modules in the tested software;
generating all modules from the official module library of the tested software, correspondingly linking each module to the module A in the test case, and enabling each module A to be linked with a non-repeated module to form a module link group;
operating the tested use case, if the compiling fails, deleting a module link group causing the compiling failure;
recording the information of the module link group in the tested case which is successfully operated into a tested software module analysis database;
repeating the operation until all minimum unit standard modules in the official module library in the tested software are traversed;
a test case randomly generating stage, namely randomly generating an initial module capable of generating signals from a official module library of tested software, inputting information of the module into a tested software module analysis database to inquire the link condition of the module, randomly picking out the linkable module from the module to generate, and the like to generate a tested case;
and (5) running the generated test cases, storing if the running is successful, discarding if the compiling is failed, and counting the generation rate of the tested cases.
2. The method for stably generating the module-level Simulink test case according to claim 1, wherein the method comprises the following steps: the tested software module analyzes the link condition of each minimum unit standard module in the database and stores the link condition in the form of a database table, wherein the information of the main record comprises the name information of the departure module and the name information of the arrival module.
3. The method for stably generating the module-level Simulink test case according to claim 1, wherein the method comprises the following steps: the minimum unit standard module is a module which cannot be continuously split and is given in an official module library, the initial module is a signal generation module, and some modules which can generate signals in tested software.
4. The method for stably generating the module-level Simulink test case according to claim 1, wherein the method comprises the following steps: the module a is linked with other modules in such a way that the module a is the side closer to the signal input, and the input ports of the other modules are linked to the output port of the module a through signal lines.
5. The method for stably generating the module-level Simulink test case according to claim 1, wherein the method comprises the following steps: the departure module is a module which is positioned on the signal inflow side or is closer to the signal inflow side when linked, and the arrival module is a module which is positioned on the information outflow side or is closer to the signal outflow side.
CN202310045492.5A 2023-01-30 2023-01-30 Stable generation method for module-level Simulink test case Pending CN116204420A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310045492.5A CN116204420A (en) 2023-01-30 2023-01-30 Stable generation method for module-level Simulink test case

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310045492.5A CN116204420A (en) 2023-01-30 2023-01-30 Stable generation method for module-level Simulink test case

Publications (1)

Publication Number Publication Date
CN116204420A true CN116204420A (en) 2023-06-02

Family

ID=86510599

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310045492.5A Pending CN116204420A (en) 2023-01-30 2023-01-30 Stable generation method for module-level Simulink test case

Country Status (1)

Country Link
CN (1) CN116204420A (en)

Similar Documents

Publication Publication Date Title
CN113032195B (en) Chip simulation verification method, system, equipment and storage medium
US20020091968A1 (en) Object-oriented data driven software GUI automated test harness
US7895575B2 (en) Apparatus and method for generating test driver
US9594543B2 (en) Activity diagram model-based system behavior simulation method
CA2548334A1 (en) An apparatus for migration and conversion of software code from any source platform to any target platform
CN103399814B (en) The method and device of automatic test
CN109857641A (en) The method and device of defects detection is carried out to program source file
CN107608873B (en) Software testing method and system and testing platform
CN115952758A (en) Chip verification method and device, electronic equipment and storage medium
CN107622017B (en) Analysis method for universal automation software test
CN115543781A (en) Method and interactive system for automatically verifying automobile software model
CN112860587B (en) UI automatic test method and device
Lefticaru et al. Towards an integrated approach for model simulation, property extraction and verification of P systems
CN110069414A (en) Regression testing method and system
CN110286882B (en) Foreground system design and verification method based on model detection
CN116204420A (en) Stable generation method for module-level Simulink test case
CN116090380A (en) Automatic method and device for verifying digital integrated circuit, storage medium and terminal
CN115687356A (en) Method and system for realizing data verification in automatic test clinical trial
CN114091687A (en) Method and device for automatic delivery and deployment of machine learning model
CN114968817A (en) Method, device, equipment and storage medium for evaluating code change influence range
CN113505283A (en) Test data screening method and system
CN111949525A (en) AI-based robustness intelligent test system and test method thereof
CN111427731B (en) Automatic split code stream and verification code stream testing method and system
US20230168656A1 (en) Automatically assigning natural language labels to non-conforming behavior of processes
Långström An Investigative Study of Testing Strategy and Test Case Creation in a Hardware-Software Co-design Environment Using Software Product Line Theory

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination