DE102004039832A1 - Structural coverage criteria for continuous function charts - Google Patents

Abstract

The present invention relates to a method for the structure-oriented testing of the test completeness by means of a graphical model, in particular in the form of continuous function charts (CFC), projected software. DOLLAR A The invention is characterized by deriving a pseudo-code from the graphical model of the software and from the pseudo-code to determine test completeness criteria during a dynamic test.

Description

The Configuration of Continuous Function Charts (CFC) provides a graphical Programming language that is already used in a conventional way. From CFCs, a C or assembler code is generated, which in different ECUs is used. CFCs are as a form of model-based development in which the interconnection of functional blocks by Specification of the data flow is described.

always Extensive software systems are used in safety-critical areas used. The error rate of these systems is growing with increasing complexity. The high complexity causes extensive and expensive Testing activities, which a considerable one Share of total development costs. Therefore, computer-aided methods needed the one meaningful and efficient testing enable. The software must be tested early and intensively in the development process be to later quality problems and avoid the associated costs. This is especially true to carry out a comprehensive module test. For this module test are completeness criteria to be defined, which must be fulfilled for the acceptance of the software.

With Exception of intermodular data flows is usually found in coverage measurements at the module level. Interesting but especially the Interconnection of modules, as application-specific Knowledge of an analysis is explicitly provided.

Currently, the module test is typically performed using functional test cases derived from the requirement specification. Since this is usually held in unbound form, ie in natural language or prose or is written and can not be checked for completeness, a structure-oriented test of the full test is desirable. This is required by relevant standards (eg EN 50128 ). Writing in natural language has the advantage of easy comprehension. At the same time, however, there are disadvantages associated with natural language. Criteria such as completeness, consistency and unambiguity are generally not achieved. In addition, the systematic derivation of function-oriented test cases from prose specifications is difficult. While there are procedures aimed at systematically examining the specified subject matter, they are rarely used systematically and often refer only to partial aspects of the specified functionality. Therefore, in a pure function-oriented test, it can be assumed that untested functionality still exists in the software.

Around nevertheless a certain completeness In the dynamic test to guarantee, in practice, the overlap the software is evaluated by the functional test cases according to criteria, which are based on the structure of the software.

Become the dynamic test cases derived solely with regard to structure-oriented criteria, so is not guaranteed that required in the specification functionality Completely checked has been. So the structure test alone is not able to miss missing functionalities to recognize. The comparison of the implementation with the specification through the function test recognizes such errors. It is therefore desirable functional and Structure test procedures combine with each other by completeness of test cases derived according to function-oriented criteria structure-oriented criteria is assessed.

aim the determination is more structurally dependent Criteria for the measurement of the test completeness in the module test and in particular as a criterion for the module acceptance in the graphic design to serve with CFC. The criteria are to be described in such a way that this later can be implemented in a tool.

A exam the test integrity at the code level is known in non-model based software development, but so far not possible with graphically configured software.

The completeness The module test becomes more conventional On the basis of the requirement specification and on the basis of the Experience of the developer evaluated. For critical applications Appraisers will be consulted.

It is therefore an object of the present invention - a - in particular structure-oriented - testing the Provide test completeness in graphically configured software or in graphically configured software modules.

The The object is achieved by a method according to claim 1, by a device and a storage medium according to the independent claims. advantageous Embodiments can be found in the subclaims.

base The examination is a projecting of the software in a graphical programming language to provide a graphical model of the software. A Such programming language is for example by means of Continuous Function Charts (CFC) provided.

The Evaluation of the test completeness can be structured based on the model. To becomes a pseudo code derived from the model being instrumented and that of the measurement the test data adequacy is based on. On this pseudo code are known and Standards of Completeness Recommended by Standards During the determined by dynamic tests.

pseudocode or pseudo-code is an expression from computer science. He describes a representation of a computer program in a language that a programming language, but even easier to read as formulated program code.

pseudocode is a semi-formal, non-standard language with which you can the process structures of an algorithm roughly by texts and fixed describes predefined keywords. The keywords of the pseudocode usually follow the expressions of a higher-level programming language.

Example of pseudocode:

Next graphic design becomes a test of graphic models carried out. Often used test strategies of this type of configuration are functional Testing. additionally to functional tests are in the graphically oriented engineering process also structure-oriented tests of interest. The structure-oriented Testing the code generated from graphical models requires numerous dynamic test cases, who not only look at the interconnections of the graphical components, but also check the inside of the components. The graphic models have a coarser one granularity as the generated code, i. only essential for coverage measurements Structures are taken into account. This is how the structure-oriented test of graphic models becomes specifically relate to the aspects of graphic design. Therefore should in addition to the known structural coverage criteria on the Code level, such criteria are collected on graphic models and used to evaluate the test data adequacy.

Of the Contains pseudo-code the main structural features of the model, hides implementation details however, out. A production code is inappropriate as it is the one for coverage measurements relevant structures are not explicitly included.

Consequently will not be the overlap of the generated code (this would be too extensive, moreover the building blocks already tested and certified, so that in the sense of a modular development an overlapping of the production code not meaningful), but an overlap of the relevant structures of the model.

Known and test completeness criteria recommended by standards are e.g. B. Branch Coverage, Condition / Decision Overlap and / or all-uses coverage.

Further Criteria for the exam can be connector-based criteria.

The Method can be applied in particular to software modules.

When Device for controlling a method can in particular a Personal computers are used. This is an automatic Testüberdeckungsmaßermittlung possible.

The Data for execution an advantageous method can advantageously provided on a CD-ROM or a floppy disk become.

Especially Advantageously, a quantification and an automatic survey the test integrity be provided in the module test of CFC-based software. These Approach will be necessary in the implementation of relevant standards.

DEFINITIONS:

Continuous Function Charts (CFCs) provide a form of graphical programming, also referred to below as configuration. An example of CFCs shows 1 ,

prefabricated and self-defined function blocks are used during configuration in a graphic artboard placed and interconnected according to technological aspects. The function blocks contain the actual functionality, for example in the form of calculations and logical links. By connecting the inputs and outputs the placed blocks, the signal flow is determined. By The assignment of the blocks to specific event classes and through Defining the sequence of execution of the blocks within an event class the project engineer defines the process structure.

In a standard library are already essential function blocks contain. Usually During configuration, function blocks are taken from the standard library used is the use of self-defined function blocks but also possible.

Varied support for the development of high-quality systems is provided by CAE tools. Some examples of such tools are SIBAS ^® G, SIMATIC S7 and Matlab / Simulink / Stateflow. SIBAS ^® G is the configuration tool used to create vehicle control software for trains. With SIMATIC S7, solutions for control and control tasks can be created. Matlab / Simulink / Stateflow are tools for creating executable models of the control system. In numerous systems, the editor is established with various function block libraries. It is part of SIBAS G, SIMATIC S7, SIMOTION, Drive ES Graphic, DIGSI, DESIGO building management system and others. The SIBAS ^® G configuration tool is used as an example system. For example, SIBAS ^® G is used to create vehicle control software for trains. A SIBAS ^® program is a continuous function chart that is used with the CAE tool SIBAS ^® -G for configuring the software for SIBAS ^® 32 ECUs.

In order to support project engineers in programming, the configuration in CAE tools is usually carried out on a graphic level. Then an executable program is created. An example of graphical models are Continuous Function Charts (CFCs), which can be created with SIBAS ^® G, SIMATIC S7 or other tools.

Criteria for a method of completeness testing of test data in the module test for CFC are proposed. This is based on SIBAS ^® G function diagrams, which represent a special form of CFC.

First, a formal description of the module test will be presented, as it can be applied to SIBAS ^® G projects. A module represents a function φ: S _E → S _A , which maps the signals S _E applied to the input connectors to the signals of the output connectors S _A. A complete test of all combinations of values for input signals for a module is generally not possible: For this purpose, all combinations of possible values of the input signals S ε S _{E would have to be} generated for this purpose. On the other hand, after the test cases have been carried out, it must be determined whether the output signals S ε S _A calculated by the module are correct. Since there are generally infinitely many combinations of possible values of the input signals and thus the provision and evaluation of the test cases is not possible, from the set of possible combinations of input signals S ε S _E suitable representatives must be selected, which check the functionality as completely as possible.

• 1. Test auf Basis von Grenzwertanalysen
• 2. Test auf Basis von Fehlererwartung
• 3. Test auf Basis von Fehlereinstreuung
• 4. Leistungs-Modellierung
• 5. Test auf Basis von Äquivalenzklassen und Eingangsdaten-Unterteilung
• 6. Strukturabhängige Test

For example, in the field of railway technology is the norm EN 50128 applied to software components. As testing strategies for software of the security levels defined from one to four, dynamic tests and dynamic analysis are recommended ("Highly Recommended" -HR). The following techniques or dynamic testing, including for a method according to the present invention, are proposed:

• 1. Test based on limit value analyzes
• 2. Test based on error expectation
• 3. Test based on error diffusion
• 4. Performance modeling
• 5. Test based on equivalence classes and input data subdivision
• 6. Structure dependent test

The commonly used methods for module testing SIBAS ^® G plans are functional tests. The test cases are derived from the specification or the module specification. In the test procedure, one considers the input and output quantities of the test runs for the entire module or for a part thereof and decides according to the specification whether a decrease can take place on the basis of satisfactory results.

For example, a SIBAS ^® is -32-system (Siemens rail automation system with 32 bit microprocessor) for control and regulating tasks for central control device (ZSG), drive control devices (ASG) and combined control devices used in the field for example, of mass transit vehicles.

For example In rail vehicles there are many components that are electric such as doors, drive, brakes and cab display. Most of these components require information from others Components and in turn generate information for others Components are important.

The System controls, controls, protects In the power converter close range the vehicle drive and takes over in a vague cross-over Control level as a control unit Tax and information tasks.

The ZSG assumes higher-level control and monitoring tasks in the vehicle. The ASGs are used to control and regulate driving and braking via the traction motors. Using a PC monitor program, the operating system of the central computer can be used with the SIBAS ^® 32 Monitor.

The SIBAS ^® program is a continuous function chart that is used with the CAE tool SIBAS ^® -G for configuring the software for the SIBAS ^® 32 control units. The functions of the vehicle control and drive technology, the SIBAS ^® 32 central computer and signal processors are configured on the basis of function blocks, and programs are generated from these that can be downloaded to the control units.

In the following, components of the CFCs in SIBAS ^® G are presented, which can be used as a basis for structure-oriented test criteria.

function blocks

Function blocks are a graphic element of SIBAS ^® G plans. Function blocks contain the basic functionality of the overall program, from the simplest logical links to complex control algorithms. The functionality of the functional design is - depending on the target platform - programmed in C and / or in assembler.

connectors

to Configuring a signal flow diagram, the blocks have a and output connectors as embedded objects. With their help can the building blocks are connected to a functional network. The Enable connectors the data exchange between the function blocks.

signals

The Output connectors of function blocks set via static RAM cells provide the signals. These signals each have one implicit and one optional explicit signal names.

event classes

function blocks are associated with event classes. With an event class is set For example, if it is a function block that is cyclic be edited or due to a specific event in the Vehicle to be processed. about The event classes combine all function modules into groups. Within the event class, the individual function blocks become lined up in a row and according to the cell number in this Order processed.

Hierarchical structure of SIBAS ^® G programs

The software of, for example, a SIBAS ^® G program is built from the smallest graphic modules, the function blocks. By linking the inputs and outputs of the individual function blocks, a logical network is created. The SIBAS ^® G configuration tool is available for this programming. The SIBAS ^® G program is hierarchically structured. The hierarchical program structure of SIBAS ^® G consists of the following elements: Function modules, plan sheets, function groups, function packages and control program.

Workflow for the development of SIBAS ^® G programs

As a starting point for the creation of a functional package with SIBAS ^® G, the requirements for the functional package, which are described in a specification with design specification. After configuring the individual function packages with SIBAS ^® G, these are combined into a program. Subsequently, the automatic code generation with standard compilers, which are integrated in SIBAS ^® G, becomes an executable program. The test cases for a module test are also derived from the specifications. Subsequently, the module tests are carried out. For the module test of function packages created with SIBAS ^® G, there are several possibilities. All possibilities are important and complementary.

Pseudo-code generation

• – Um Kontrollfluss-basierte Kriterien anwenden zu können, müssen Verzweigungen in einer Code-Ausführung sichtbar gemacht werden;
• – Für Datenfluss basierte Kriterien müssen Definitionen und Benutzungen von Variablen im generierten Pseudo-Code spezifiziert werden;
• – Um Bedingungsüberdeckungskriterien anwenden zu können, müssen Teilentscheidungen sowie Gesamtentscheidungen von prädikativen Ausdrücken im Pseudo-Code identifiziert werden können;
• – Der den Funktionsbausteinen unterliegende Quellcode muss im Pseudo-Code verborgen bleiben. Dies ist notwendig, um die Bewertung der Testvollständigkeit auf die vom Projektor gegebene Beschreibung des Moduls zu fokussieren und die Testvollständigkeit im Hinblick auf die grafische Implementierung des Prüflings zu bewerten.

In order to transfer the control flow and data flow-oriented criteria to a SIBAS ^® G plan, the generation of a code from the plan is described below. With regard to the application of the known structure-oriented criteria to the code to be generated, it must fulfill the following characteristics:

• - In order to apply control flow-based criteria, branches must be made visible in a code execution;
• - Data flow based criteria must specify definitions and uses of variables in the generated pseudo-code;
• - In order to apply conditional coverage criteria, partial decisions as well as overall decisions of predicative expressions must be identifiable in pseudo-code;
• - The source code subject to the function blocks must remain hidden in the pseudo-code. This is necessary in order to focus the evaluation of the test completeness on the description of the module given by the projector and to evaluate the test completeness with regard to the graphical implementation of the test object.

Each application of a criterion to the pseudo-code allows conclusions about the graphical model. This determines the importance of pseudo-code overlap on SIBAS ^® G plans.

Formal description the source language

The components of the graphical source language SIBAS ^® G are defined. Due to the restriction to the graphical level, the only components to consider are the function blocks and the signals.

flow graph

In the first step of the pseudo-code generation, the components of the source language (SIBAS ^® G-Plan) are used to build a flow structure. An attempt is made to generate the sequence graph of the pseudo-code as oriented as possible on the real sequence structure.

In one next The code generation step becomes the function blocks of the run graph represented as functions.

control flow

These Functions are for the calculation of the values at output connectors. They still bring no control flow into the pseudo-code.

First, the control flow of SIBAS ^® G plans is realized with the help of so-called logic and control function blocks. Following this, some arithmetic function blocks contribute to the control flow.

Around to represent the control flow in pseudo-code will be those Functions that include the logic, control and some arithmetic function blocks correspond, replaced by instructions.

data flow

in the last step of the code generation, the data flow becomes visible made. For this purpose, the relationships between output and input connectors used. The relationships in the source code are through the connections specified between the function blocks. All connectors are replaced in the flow structure by their signal names. All Constants are replaced by their values.

at The definition of pseudo-code should be noted that a signal can be used before it is calculated. In the executable Code, however, bypasses the problem by starting at program startup all signals are set to a specific default value. That is why for the generated Pseudo code in addition introduced the assumption that all signals are initialized with default values at program start become.

The proposed structure of the pseudo-code meets the established requirements, to apply control flow and data flow oriented criteria can.

application of known criteria

The CFC's graphical plans do not allow the direct application of the known control flow and data flow based criteria. However, to show the importance of the criteria for a graphical plan, the criteria must first be applied to a pseudo-code presented above. The following describes the application of the known control flow and data flow oriented criteria to the pseudo-code. From this application, the consequences for SIBAS ^® G plans are derived.

In this section uses control flow-based testing techniques for the sake of completeness of the test based on the coverage of the pseudo-code.

Statement testing;

The Target of instruction coverage is the least one-time execution of all instructions of the program to be tested, ie the coverage of all nodes of the control flow graph.

Branch coverage test

The Target of the branch coverage test is the execution all branches of the program to be tested. He requires the coverage all edges and control flow graphs.

Of the Difference between the instruction coverage test and the branch coverage test of the pseudo-code consists in the test of certain function blocks. In the function modules, it is possible to use the input connectors to prove that the output connectors are not affected. This branch overlap tests in contrast to the instruction coverage of the pseudo-code additionally the assignment of the input connectors.

The criteria can be classified in the module test according to the requirements of the software according to different SIL (Safety Integrity Level). The decision on the application of the instruction Overlap or branch overlap of the pseudo-code can be made according to the applied SIL.

Path coverage test

One Path coverage test is a comprehensive control flow-oriented technique. It will execution all different paths of the module to be tested required. A path is a sequence of nodes of the control flow graph. Two Paths are identical only if the sequences of their nodes are identical.

This test technique for SIBAS ^® G charts can only be used if all unreachable paths are determined and the module functions to be tested are limited to a worksheet page, for example.

Condition coverage test

Of the Condition coverage test pays attention to the logical structure of decisions of the test to be tested Software. There are different forms, of which the weakest - the simple one Condition coverage test - not the instruction and Branch coverage test subsumed. The so-called multiple condition coverage test subsumes the branch cover, but has other weaknesses. In This section will discuss the minimum multiple service coverage test and the so-called modified operator / decision coverage test is considered, which represents a good compromise between test effort and quality of results.

The Target of a condition coverage test is the thorough review of composite decisions. For a complete branch coverage test It is sufficient that the evaluation of all decisions once returns the value true and false, but does not take into account the complicated structure the decisions.

For procedures the condition coverage test becomes between composite decision and atomic decision distinguished.

When Decision is hereinafter referred to as an expression used during the Runtime is evaluated to true or false. Is a decision from further partial decisions with two-digit Boolean operators composed, it is called a composite decision. Otherwise, it is called an atomic decision. Examples for atomic Decisions in a pseudo-code are signals that are Boolean Values are assigned. Examples of composite decisions are results of function modules, such as AND and OR.

The paradigm of the SIBAS ^® G program contains logical function blocks that correspond to n-honor operators AND and OR. More complex logical links are not implemented in individual blocks. As a result, according to the above-described generation, the pseudo code has only a small number of composite part decisions from AND and OR blocks. The predicates of the IF instructions are atomic part decisions determined by the input signals.

On the other hand, the function blocks, which represent the elementary logical links, offer the project engineer the possibility of designing any complicated interconnections. Functional packages with predominantly logical interconnections are very important for SIBAS ^® G projects.

Around an overlap for complex logical interconnections by links of multiple logical Function blocks must be determined, the interconnections in Pseudo-code can be identified.

there is too complex logical interconnections to notice that one Signal can be defined in several places. That's exactly what then before, if function blocks of different event classes can produce the same signal. If a signal within the event class is defined twice, so this has no meaning. Because of the sequential execution of the Function blocks within an event class always become the last executed Definition used.

Multiple definitions of a signal are always combined in the composite logical interconnection with logical OR. Thus, all definitions of a signal carry the entire logical Ver circuit.

Of the minimal multiple condition coverage test demands that in addition to the partial atomic decisions and the overall decision also all composite partial decisions against true and false checked become.

Of the modified condition / decision coverage test requires test cases that demonstrate that every atomic partial decision is the truth value the overall decision independently of the other partial decisions.

Data flow-based criteria

To assess the completeness of the test based on pseudo-code coverage, data-flow-based test techniques are used. This is particularly useful in the context of the SIBAS ^® G-Plan because it is essentially data flow diagrams.

all defs criterion

The all defs criterion requires a lot of test paths, so for everyone Node and each variable at least one definition-free path with respect to Variables from the node to an item is included. The criterion requires that for each definition of all variables at least one Calculation or use of this variable tested in a predicate becomes.

all p-uses criterion

The all-p-uses criterion is met if for each node and each variable is a definition-free path with respect to Variable of the node to all elements in the tested paths is included. It has to be every combination of every variable definition be tested with every p-use that uses this definition.

all c-uses criterion

The all-c-uses criterion requires execution of at least one definition-free one Path regarding the Variables of the node to each element for each node and variable.

Of the greatest proportion of calculating uses in pseudo-code are the functions, who do not bring in a control flow and not in instructions be split.

all uses

The Criterion all uses requires all predicative and calculating variable accesses that are calculated by a definition too testing. Formally formulated must be a definition-free path with respect to a Variable from node to all elements for each node in each variable be included.

As described earlier, data flow oriented techniques in SIBAS ^® G charts can detect the errors that hide in the data exchange between different event classes.

Connectors-based test criteria

Some additional criteria are described which are defined independently of function modules. Connectors of the SIBAS ^® G plans are used as the basis for the criteria. The connector types are defined for SIBAS ^® G language. So the criteria can be used for all projects without change. This has the advantage that the criteria for all projects are comparable.

The next Criteria share the signals connected to the connectors of the function blocks exist in such equivalence classes that they have special values and limits for All applications are acceptable to test.

instrumentation of the code

To support the dynamic test and automated recording of test results enable the programs under test to be instrumented. An instrumented program contains additional inserted instructions at certain points which are required for recording information during the test procedure.

in the Generally, the instrumentation of the code is for the control flow and data flow oriented testing techniques a solved one Problem. The application of instrumentation is exemplified by various tools for example LDRA shown. It will only pointed to a conceptual approach to instrumentation. About that In addition, the code to be instrumented is not the one generated C code, but the pseudo code taken.

For the record of information in an instruction coverage test must be every statement with a counter which is initialized to zero. A counter will set to 1 if the corresponding statement is executed during the test. After the test becomes the sum of all counter values and the number of instructions calculates the coverage measure.

at Instrumentation of the branch coverage test have to with the counters predicates be offset. The counters have to can be incremented up to the value 2 at most. Once the counter counted up, though the predicate TRUE is evaluated and again if the predicate is up FALSE is evaluated. After the test procedure is the sum of all counter values and the number of branches calculates the coverage measure.

The all uses criterion requires the execution of all uses, which are reachable from a definition. For this, each definition must have an additional one information about have the number of achievable uses. If at one Test procedure is set that counter a definition as many times as the number of times achievable uses, then all uses of the definition accomplished Service.

Of the Algorithm for identifying the compound logical Interconnections in the pseudo-code gives a starting point for the instrumentation the modified condition / decision coverage test. With the algorithm it is possible to find the composite logical interconnection in pseudo-code.

The identified logical expressions can in pseudo code after each execution a SWITCH function are evaluated. So can the results of the atomic and the overall decision for saved every test case. After performing the test cases become the stored values and the logical expressions of a Subjected to analysis. It should be decided whether each atomic Condition independent other changes the value of the overall decision. Based on the results In the analysis and the number of required criteria, the degree of overlap is determined.

In order to is shown that the criteria for automatic detection the test coverage are suitable. In detail, the algorithms of instrumentation dependent on the generated C code, however, this will not be considered further.

The scope of the present invention is not limited to the use of SIBAS ^®, but includes any similar configuration tools to create graphical models.

The Invention will be described below with reference to an embodiment. Show it:

1 a section from a plan sheet page "Air conditioner setpoint conversion" as an example of a CFC;

2 a sheet from the SIBAS ^® G program "Temperature averaging" with signal assignments through the functional test cases;

3 a representation for the branch coverage of a pseudo-code in an example "averaging temperature;

4 a representation for coverage according to the all uses criterion on pseudo-code in the plan page "Temperature averaging;

5 the steps of the method according to the invention.

An empirical investigation is described based on existing SIBAS ^® G plans and test cases from a real project. With test cases from test specifications, the overlay mass is delivered and the sensitivity of the unaudited functionality is discussed. The application of the defined criteria in SIBAS ^® G plans is carried out from a real project. The plans are configured with predominantly arithmetic function blocks. Basically, a configuration with predominantly logical links is possible.

It For example, the exemplary measurement of test integrity has been exemplified of some SIBAS G plans executed. The example plans as well as the completeness tested test cases come from a real project planning with the SIBAS G development environment. The criteria were based on a SIBAS G plan with predominantly arithmetic Function blocks applied. Detailed process descriptions are to be taken from the following.

The applicability of the defined criteria is shown on the basis of SIBAS ^® G plans from real projects. The degree of test coverage of the pseudo-code is determined during the execution of the functional test cases. The functional test cases are taken from an existing test specification.

When Criteria are in the empirical investigation branch overlaps, modified condition / decision coverage, uses all uses criterion and connector-based criteria themselves as criteria in the structure-oriented test at the code level proven to have. The branch overlap subsumes the instruction coverage, is however in contrast to the path coverage feasible with reasonable effort. The modified condition / decision coverage calls for a thorough Test the logic of the pseudo-code and set an optimum between Effort and test quality The all uses criterion has a dataflow-oriented view on the control flow and asks the test of some event classes more comprehensive Partial paths.

For empirical investigation of the coverage criteria, a SIBAS ^® G plan sheet page is selected, which contains mainly arithmetic calculations.

embodiment with numerical calculations

The example is a sheet of sheet from the function package "air conditioning". The function presented in the example provides averaging of four outside temperature values. If the maximum value of the four temperature values is greater than the average of the other three multiplied by the factor 1.1, it is excluded from the calculation. The same happens if the minimum value is less than the average of the other three temperature values multiplied by the factor 0.9. If the minimum value and the maximum value are excluded from the calculation, the average temperature value from the remaining two temperature values is calculated (see 2 ).

• • $62E5W31 – "Fallen_KLM1_Aussen_Temp" – Vom ersten Sensor gelieferter Temperaturwert
• • $62E5W32 – "Fallen_KLM2_Aussen_Temp" – Vom zweiten Sensor gelieferter Temperaturwert
• • $62E5W33 – "Fallen_KLM3_Aussen_Temp" – Vom dritten Sensor gelieferter Temperaturwert
• • $62E5W34 – "Fallen_KLM4_Aussen_Temp" – Vom vierten Sensor gelieferter Temperaturwert
• • $61M5001 – "Außentemperatur Ungültig – Das Signal hat den Wert 1, wenn die Frostwarnung und der Frostschutz eingeschaltet werden soll

The following input signals are available:

• • $ 62E5W31 - "Fall_KLM1_Out_Temp" - Temperature value supplied by the first sensor
• • $ 62E5W32 - "Fall_KLM2_Out_Temp" - Temperature value supplied by the second sensor
• • $ 62E5W33 - "Fall_KLM3_Aussen_Temp" - Temperature value supplied by the third sensor
• • $ 62E5W34 - "Fall_KLM4_Aussen_Temp" - Temperature value supplied by the fourth sensor
• • $ 61M5001 - "Outside temperature invalid - The signal is set to 1 if the frost warning and frost protection are to be switched on

• • $62M7W00 – Mittelwert der Außentemperatur
• • $62M5000 – "Frostwarnung" – das Signal hat den Wert 1, wenn die Frostwarnung aktiviert werden soll
• • $61M5003 – "Frostschutz" – das Signal hat den Wert 1, wenn der Frostschutz aktiviert werden soll

The function has the following output signals:

• • $ 62M7W00 - Average outdoor temperature
• • $ 62M5000 - "Frost warning" - the signal is set to 1 if the frost warning is to be activated
• • $ 61M5003 - "Frost protection" - the signal is set to 1 if frost protection is to be activated

• 1. Eingangssignale: $62E5W31 = 20° C – Außentemperaturwert vom ersten Sensor $62E5W32 = 21° C – Außentemperaturwert vom zweiten Sensor $62E5W33 = 22° C – Außentemperaturwert vom dritten Sensor $62E5W31 = 23° C – Außentemperaturwert vom vierten Sensor
• Ausgangssignal: $62M7W00 = 21,5° C – Der aktuelle Mittelwert der Außentemperatur
• 2. Eingangssignale: $62E5W31 = 20° C – Außentemperaturwert vom ersten Sensor $62E5W32 = 21° C – Außentemperaturwert vom zweiten Sensor $62E5W33 = 22° C – Außentemperaturwert vom dritten Sensor $62E5W31 = 25° C – Außentemperaturwert vom vierten Sensor
• Ausgangssignal: $62M7W00 = 22° C – Der aktuelle Mittelwert der Außentemperatur
• 3. Eingangssignale: $62E5W31 = 16° C – Außentemperaturwert vom ersten Sensor $62E5W32 = 21° C – Außentemperaturwert vom zweiten Sensor $62E5W33 = 22° C – Außentemperaturwert vom dritten Sensor $62E5W31 = 25° C – Außentemperaturwert vom vierten Sensor
• Ausgangssignal: $62M7W00 = 21,5° C – Der aktuelle Mittelwert der Außentemperatur
• 4. Eingangssignale: $61M5001 = 1 – Außentemperatur ist ungültig
• Ausgangssignale: $61M5000 = 1 – Frostwarnung ist aktiv $61M5003 = 1 – Frostschutz ist aktiv
• 5. Eingangssignale: $61M5001 = 0 – Außentemperatur ist gültig $62M7W00 = 5°C – Mittelwert der Außentemperatur
• Ausgangssignale: $61M5000 = 0 – Frostwarnung deaktiviert $61M5003 = 1 – Frostschutz ist aktiv
• 6. Eingangssignale: $61M5001 = 0 – Außentemperatur ist gültig $62M7W00 = 1° C – Mittelwert der Außentemperatur
• Ausgangssignale: $61M5000 = 1 – Frostwarnung ist aktiv $61M5003 = 1 – Frostschutz ist aktiv
• 7. Eingangssignale: $61M5001 = 0 – Außentemperatur ist gültig $62M7W00 = 7° C – Mittelwert der Außentemperatur
• Ausgangssignale: $61M5000 = 0 – Frostwarnung ist deaktiviert §61M5003 = 0 – Frostschutz ist deaktiviert

According to the test specification, seven test cases are designed for the plan sheet. The first three test cases test the averaging and the remaining the activation of the frost warning and the frost protection. The following are the test cases listed.

• 1. Input signals: $ 62E5W31 = 20 ° C - Outside temperature value from first sensor $ 62E5W32 = 21 ° C - Outside temperature value from second sensor $ 62E5W33 = 22 ° C - Outside temperature value from third sensor $ 62E5W31 = 23 ° C - Outside temperature value from fourth sensor
• Output signal: $ 62M7W00 = 21.5 ° C - The current average of the outdoor temperature
• 2. Input signals: $ 62E5W31 = 20 ° C - Outside temperature value from first sensor $ 62E5W32 = 21 ° C - Outside temperature value from second sensor $ 62E5W33 = 22 ° C - Outside temperature value from third sensor $ 62E5W31 = 25 ° C - Outside temperature value from fourth sensor
• Output signal: $ 62M7W00 = 22 ° C - The current average of the outside temperature
• 3. Input signals: $ 62E5W31 = 16 ° C - Outside temperature value from first sensor $ 62E5W32 = 21 ° C - Outside temperature value from second sensor $ 62E5W33 = 22 ° C - Outside temperature value from third sensor $ 62E5W31 = 25 ° C - Outside temperature value from fourth sensor
• Output signal: $ 62M7W00 = 21.5 ° C - The current average of the outdoor temperature
• 4. Input signals: $ 61M5001 = 1 - outdoor temperature is invalid
• Output signals: $ 61M5000 = 1 - Frost warning is active $ 61M5003 = 1 - Frost protection is active
• 5. Input signals: $ 61M5001 = 0 - Outdoor temperature is valid $ 62M7W00 = 5 ° C - Average outdoor temperature
• Output signals: $ 61M5000 = 0 - Frost warning deactivated $ 61M5003 = 1 - Frost protection is active
• 6. Input signals: $ 61M5001 = 0 - Outdoor temperature is valid $ 62M7W00 = 1 ° C - Average outdoor temperature
• Output signals: $ 61M5000 = 1 - Frost warning is active $ 61M5003 = 1 - Frost protection is active
• 7. Input signals: $ 61M5001 = 0 - Outdoor temperature is valid $ 62M7W00 = 7 ° C - Average outdoor temperature
• Output signals: $ 61M5000 = 0 - Frost warning is deactivated §61M5003 = 0 - Frost protection is deactivated

The values of the input signals to the above test cases are in 2 shown. The values in particular for the first test case are at the top, the second at the middle, the third at the bottom, the fourth at the top. The associated values of the output signals of the function blocks are recorded in the same positions in the interconnection diagram.

The two functions "Education the mean value "and" activation of frost protection and the frost warning " individually tested in the sheet. In the following investigation the test coverage it is assumed that between the tests "formation of the mean" and "activation of the antifreeze and the frost alarm "no dependencies exist. The cover is determined separately, only the affected structure elements are affected of the plan sheet.

Branch Coverage of the pseudo-code

In order to achieve a branch coverage of the pseudo-code, the predicative conditions for all functional components have to be evaluated once to true and once to false. In 3 the conditions are shown next to the applicable function blocks. A plus of a test case shows that this Be be evaluated with the test case.

In the function "formation of the average value" a total of 10 conditions (see 3 ). The coverage according to individual test cases is listed in Table 1.

table Fig. 1 shows the overlap amount that the Two overlap measure of the pseudo-code equivalent. It is assigned to the sheet "Average outdoor temperature" and the "Average value" function.

Tabelle 1

Table 1

The Function "Activation frost protection and frost warning "has a total of 8 conditions. The overlap measure after individual test cases is listed in Table 2.

2 shows a plan sheet page from SIBAS ^® G program "Temperature averaging" with signal assignments through the functional test cases.

3 refers to the branch coverage of the pseudo-code in the example "temperature averaging".

table 2 represents the overlap measure that the Branch coverage of pseudo-code This corresponds to the sheet "Averaging the outdoor temperature" and the function "Activation of frost protection and the frost warning ".

Tabelle 2

Table 2

With the test cases from test specifications all conditions in the interconnection plan are evaluated. In order to will be complete Branch Coverage reached the pseudo-code.

all uses criterion

The coverage of the all uses criterion in pseudo-codes is in 4 shown graphically. The signal flows are tested. The conditions that the control flow introduces into the pseudo-code and that are responsible for the definition of the signals are shown at the bottom and the far right.

In the function "Education of the mean " a total of 49 subpaths between the definitions and uses to cover completely to fulfill the all uses criterion of the pseudo-code. The coverage according to the individual test cases is shown in Table 1.

Tabelle 3 Table 3 shows all uses coverage of the pseudo-code in the sheet "Averaging the outside temperature" in the "Averaging" function

Table 3

A path between the definition of the signal TEMP SW3.OUT and its use in the function block TEMP SW2 is not covered. The path is in 4 shown on the top right and marked with the sign "-". In the following section of the pseudo-code definition and use are underlined.

• 8. Eingangssignale: $62E5W31 = 16°C – Außentemperaturwert vom ersten Sensor $62E5W32 = 21°C – Außentemperaturwert vom zweiten Sensor $62E5W33 = 22°C – Außentemperaturwert vom dritten Sensor $62E5W31 = 23°C – Außentemperaturwert vom vierten Sensor
• Ausgangssignal: $62M7W00 = 22°C – Mittelwert des zweiten, dritten und vierten Sensors der Außentemperatur

The test cases do not test the case that only the minimum temperature value is interpreted as invalid and is not included in the calculation of the mean value. An additional test case would be:

• 8. Input signals: $ 62E5W31 = 16 ° C - Outside temperature value from first sensor $ 62E5W32 = 21 ° C - Outside temperature value from second sensor $ 62E5W33 = 22 ° C - Outside temperature value from third sensor $ 62E5W31 = 23 ° C - Outside temperature value from fourth sensor
• Output signal: $ 62M7W00 = 22 ° C - Average of the second, third and fourth outdoor temperature sensor

In 4 the additional test case is represented by the lowest numerical value.

• 9. Eingangssignale: $62E5W31 = 16°C – Außentemperaturwert vom ersten Sensor $62E5W32 = 21°C – Außentemperaturwert vom zweiten Sensor $62E5W33 = 22°C – Außentemperaturwert vom dritten Sensor $62E5W31 = 23°C – Außentemperaturwert vom vierten Sensor
• Ausgangssignal: $62M7W00 = 22,64°C – Berechneter Mittelwert der Außentemperatur

The execution of the test case leads to a different result for the output signal:

• 9. Input signals: $ 62E5W31 = 16 ° C - Outside temperature value from first sensor $ 62E5W32 = 21 ° C - Outside temperature value from second sensor $ 62E5W33 = 22 ° C - Outside temperature value from third sensor $ 62E5W31 = 23 ° C - Outside temperature value from fourth sensor
• Output signal: $ 62M7W00 = 22.64 ° C - Calculated average of the outside temperature

Of the Test case thus provides a value of the output signal greater than the specified mean.

Of the Difference is justified by that the minus function block TEMP SB3 earlier is called as the sum function block TEMP AD2. It means that in the current calculation step, not the current sum of the temperature values, but the sum is taken from one step before.

4 shows a coverage according to the all-uses criterion on pseudo code on the sheet page "temperature averaging".

So assigns the all uses criterion of the pseudo-code to a not fully tested Functionality. The deviation from the specification, however, is not serious: The event class T7 is calculated in ms cycle. That's how it works the software is not crucial, whether for the calculation of the mean value the current sum of the temperature values or the formed one before Couple ms earlier Sum is taken.

In the function "Activation frost protection and frost warning ", a total of 12 sub-paths must be covered. The coverage according to the individual test cases is shown in Table 2.

table 4 shows an overlap of the pseudo-code according to the all uses criterion in the sheet "Averaging the outdoor temperature "at the function" Activation of frost protection and the frost warning ".

Tabelle 4

Table 4

With the test cases from the test specification All conditions in the function "Activation of antifreeze and the Frost warning "evaluated. Thus, the subfunction completely covers the all uses criterion reached the pseudo-code.

Connector-based criteria

The Connector-based criteria divide the signals sent to the connectors of the function modules are in equivalence classes and require the test of special values and limits. The connector-based Criteria demand test cases to overflows, rounding of numerical connectors and possible states of binary Connectors.

In this sheet (see 2 ) are 54 normalized connectors and 11 binary connectors used. None of the eleven required values are tested on the standardized connectors with the test cases from the test specification. All binary connectors are assigned the required values 1 and 0. Thus, the coverage of the connector-based criteria after execution of the test cases reaches the value 3.6%.

Of the Testing the connector-based criteria can be very costly. He is therefore only for plan leaves with critical functionality to demand that cause a major failure in misconduct can.

5 shows the steps of the method according to the invention in a block diagram. The pseudo-code is used to determine test completeness criteria during dynamic testing. The method includes projecting software using a graphical model at step S100, deriving a pseudo-code at step S110, and determining test completion criteria in one step 5120 ,

Claims (9)

Method for structure-oriented testing of test completeness by means of a graphic model, in particular in the form of continuous Function Charts (CFC), configured software (S100), marked by Deriving a pseudo-code (S110) from the graphical Model of software, determining from the pseudo-code of test completeness criteria (S120) during a testing. Method according to claim 1, characterized in that that the pseudo-code is the essential structural features of the model contains. A method according to claim 1 or 2, characterized that an overlap the relevant structures of the model is required. Method according to one or more of claims 1 to 3, characterized in that test completeness criteria, for example the instruction coverage, the branch cover, the condition / decision coverage or the all-uses coverage are. Method according to one or more of claims 1 to 4, characterized in that test completeness criteria, for example are connector-based criteria. Method according to one or more of claims 1 to 5, characterized in that a software module test takes place. Method according to one or more of claims 1 to 6, characterized in that an automatic Testüberdeckungsmaßermittlung he follows. Apparatus for carrying out a method according to one or more of the claims 1 to 7, characterized in that the device is a personal computer having. Computer program product with stored data for execution A method according to one or more of claims 1 to 7, characterized in that the computer program product on a personal computer is usable.