DE10311864A1 - Generation of test case data for software module testing, e.g. for software modules in a motor vehicle control program, whereby data are generated using a database of standard components that are then combined appropriately - Google Patents

Abstract

Method for generating test case data (M5) for functional testing of a software module has the following steps: formal description of a function of the module using standard components (M2) from a database (10); for each standard component, determination of a number of different input signal combinations or generic test targets (M3); renaming of the local names of standard component inputs as global names for the module, or concrete test targets (M4) and; consideration of the global names to generate the test data quantity. An independent claim is made for a device for generating test case data for software module testing.

Description

The present invention relates to a method for generating a test case set for a functional test of a software module.

The invention also relates to a computer program running on a computing device, in particular on a microprocessor, executable is.

Finally, the present concerns Invention a device for generating a test case set for a Function test of a software module.

State of technology

Computer programs are usually not as a big one Software unit trained, but usually include several different ones Functional units, so-called software modules. That applies to computer programs that only on a computing device be processed, and for So-called distributed computer programs equally, the one on several computing devices Expire computer network.

An example of such a computer program, which comprises several modules is a motor vehicle control program, that on a single ECU or on an ECU network one Motor vehicle is processed (so-called control unit software). The control unit software can perform a wide variety of functions, that of pure comfort functions up to the highest safety-critical functions are sufficient. Exemplary for the different Functions of control unit software are listed here: Control or regulation of temperature, humidity, supply, etc. indoor air; to open or close of windows, sunroof, tailgate; the control or regulation of a Internal combustion engine, an automatic or automated transmission, a steering support, the Motor vehicle traction; so-called X-by-wire systems (steer-by-wire, brake-by-wire, shift-by-wire, etc.).

In the design and implementation of new or revised ECU software must maximum careful be worked because errors in the software can lead to extremely critical driving situations. Of The test of the new or revised control unit software is therefore of crucial importance. The software test is usually carried out in modules. The inputs of a Software module from a programmer or a special test engineer with different input signals and it is checked whether dependent on the right ones from the input signals present at the module outputs Set output signals.

According to the state of the art there is no systematic generation of test case quantities, i.e. of input signals which a software module while of the test. Rather, a test case set is for a new one or revised module generated by the programmer or the test engineer by feeling. The programmer or test engineer accesses his personal general Computer knowledge, his personal knowledge of that software module to be tested and his personal knowledge of the Function that the module fulfills should. Basically, the module to be tested is considered one Black box considered, the content of which does not influence the function test of the module. A certain test coverage can be done this way cannot be ensured. Rather, the quality of the functional test fluctuates or the number of test cases from the experience of the programmer or of the test engineer.

General guidelines about the Leave test coverage of newly created or revised software hardly stand up because the module to be tested is usually still there did not exist because it was either completely re-created and implemented or revised has been. Each module to be tested is different. That even applies if two software modules have the same function, but different ones People created or revised were. In addition, those with the known from the prior art manual, intuitive procedures often fail to achieve test results reproducible.

The present invention lies based on the task of creating a test case set for a functional test of a Generate software module in such a way that by means of the test case set achieved a definable test depth of the functional test with certainty can be.

• – formale Beschreibung einer Funktion des Moduls durch mindestens eine Standardkomponente aus einer Datenbank;
• – für jede Standardkomponente Ermitteln einer Anzahl von verschiedenen Kombinationen von Eingangssignalen (sog. generischen Testzielen), die erforderlich sind, um verschiedene Ausgangssignale der Standardkomponente zu erzielen, wobei die Anzahl der verschiedenen generischen Testziele abhängig ist von einer vorgebbaren Testtiefe des Funktionstests;
• – Umbenennen der lokalen Bezeichnungen der Eingänge der Standardkomponenten in globale Bezeichnungen des Moduls (sog. konkrete Testziele); und
• – unter Berücksichtigung der globalen Bezeichnungen des Moduls Generieren der Testfallmenge aus der zuvor ermittelten Anzahl von konkreten Testzielen, indem für das gesamte Modul eine Anzahl von verschiedenen Kombinationen von Eingangssignalen ermittelt wird, die erforderlich sind, damit alle zuvor ermittelten generischen Testziele der Standardkomponenten mindestens einmal auftreten, wobei ein Testfall mindestens ein Testziel umfasst.

To solve this problem, a method of the type mentioned at the beginning is proposed with the following method steps:

• - formal description of a function of the module by at least one standard component from a database;
• - For each standard component, determining a number of different combinations of input signals (so-called generic test targets) that are required to achieve different output signals of the standard component, the number of different generic test targets being dependent on a predefinable test depth of the functional test;
• - Renaming the local names of the inputs of the standard components to global names of the module (so-called concrete test targets); and
• - taking into account the global designations of the module, generating the test case set from the previously determined number of concrete test targets, by determining a number of different combinations of input signals for the entire module, which are necessary so that all previously determined generic test targets of the standard components occur at least once , where a test case includes at least one test target.

Advantages of invention

According to the present invention the function test of a software module is systematized. It a defined test coverage can be achieved. It is also Test procedure reproducible.

The generation of the test case set is divided into steps analysis of requirements, identification of Test targets, assignment of test targets to test cases and design of test cases divided to test software based on non-formal requirements to carry out systematically.

The inventive method reduces the complexity of the test case design by dividing it into several in succession to be executed, clearly separate sub-steps. This reduces the susceptibility to errors and leads to test results that are highly reproducible, complete, consistent and are understandable. Furthermore, the process is good in the development process of software can be integrated, because when executing the Documentation is created step by step becomes. Based on this documentation, it is easily possible to make statements about the Test case coverage to meet the specification. Let also the design results are very simple based on the documentation a review undergo.

The standard components are in one Database or library filed. The standard components include e.g. elementary functions (e.g. arithmetic operations, curves and maps, logical operations, comparators, switches, controls), Storage functions (e.g. read access, write access, Read and write access), communication functions (e.g. sending, Receiving), dynamic functions (e.g. linear transmission elements, ramps) and state machines (e.g. timers, delays, hysteresis, triggers, Debouncer, flip-flops, status tables).

According to an advantageous development The invention proposes that the function of the module by described at least one non-formal requirement specification which then leads to the formal description of the function of the module which processes at least one standard component from a database becomes. This corresponds to a general textual description the function of the module to be tested. This non-formal requirement specification is processed by using relations the concrete non-formal requirements generic requirements be assigned to. Each requirement component represents various non-formal requirements for the same functionality and this in a uniform form. With the help of relations let yourself the set of all non-formal requirement specifications in one Quantity of all prepared specifications with the identified ones Transfer requirement components as elements.

According to a preferred embodiment of the Invention is proposed to determine the generic Test objectives of a standard component the generic test objectives in dependence on the considered standard component and depending on it are taken from the test depth of the functional test of the database. In the database there are each generic requirement component about others Relationships assigned generic test goals. The test goals are included systematically derived before the function test and in the Database has been filed. For subsequent changes and / or additions the database is extensible. You get a new amount, which the generic test goals for the underlying quantity of all prepared specifications or Set of all non-formal requirement specifications as elements contains.

The amount with the generic test targets will then transferred to another set, which the concrete test goals for contains the set of all non-formal requirement specifications as elements. The to do so Relations result from the comparison of the requirement components with the underlying non-formal requirements.

From the set of concrete test goals can finally Test cases for the functional test of the software module are created on the basis of the test objectives determined in this way , with a test case also taking into account more than one test objective can. The different test cases are summarized in the test case set.

drawings

Further features, possible applications and advantages of the invention will become apparent from the following description of embodiments of the invention, which are shown in the drawing. Make it up all described or illustrated features on their own or in any combination the subject of the invention, regardless of its summary in the claims or their relationship back as well as regardless of their formulation or presentation in the description or in the drawing. Show it:

1 a flowchart of a method according to the invention for generating a test case set for a functional test of a software module;

2 an inventive device for generating a test case set for a functional test of a software module;

3 to 11 various examples of a standard component for the formal description of a function of the software module; and

12 a block diagram of a software module to be tested.

description of the embodiments

In 1 A flow diagram of a method according to the invention for generating a test case set for a functional test of a software module is shown. The software module can be part of a computer program that is only processed on one computing device, or else part of a computer program that runs on several computing devices of a computer network.

An example of such a computer program, which comprises several modules is a motor vehicle control program, that on a single ECU or on an ECU network one Motor vehicle is processed (so-called control unit software). The control unit software can perform a wide variety of functions, that of pure comfort functions up to the highest safety-critical functions are sufficient. Exemplary for the different Functions of control unit software are listed here: Control or regulation of temperature, humidity, supply, etc. indoor air; to open or close of windows, sunroof, tailgate; the control or regulation of a Internal combustion engine, an automatic or automated transmission, a steering support, the Motor vehicle traction; so-called X-by-wire systems (steer-by-wire, brake-by-wire, shift-by-wire, etc.).

In the design and implementation of new or revised ECU software must maximum careful be worked because errors in the software can lead to extremely critical driving situations. Of The test of the new or revised control unit software is therefore of crucial importance. The software test is usually carried out in modules. The inputs of a Software module from a programmer or a special test engineer with different input signals and it is checked whether dependent on the right ones from the input signals present at the module outputs Set output signals.

The method according to the invention begins in a function block 1 , The starting point for the test design is a non-formal requirement specification for the software module or the control unit software. In a functional block 2 the function of the module to be tested is described by at least one non-formal requirement specification. This corresponds to a general textual description of the function of the module to be tested. The at least one non-formal requirement specification can be represented as a set M1, which contains the individual non-formal requirements as elements. For example,

For example, the non-formal requirement a ₄₁ is: The wiper wipes when the ignition is on and the wiper is pressed.

In a functional block 3 there is a formal description of the function of the module by at least one standard component from a database 10 , For this purpose, the non-formal requirement specification M1 is prepared for the formal description of the function of the module by the at least one standard component. The non-formal requirement specification M1 is prepared by assigning generic requirements to the concrete non-formal requirements. Each requirement component represents various non-formal requirements of the same functionality and represents them in a uniform form. With the help of the relations, the set M1 of all non-formal requirement specifications can be converted into a set M2 of all prepared specifications with the identified requirement components as elements:

The generic requirement component ak ₄ belonging to the non-formal requirement a ₄₁ is, for example:
Output signal A1 is set as long as input signals E1 and E2 are set (logical AND).

The standard components are in a database 10 or library. The standard components include, for example, elementary functions (e.g. arithmetic operations, curves and maps, logical operations, comparators, switches, controls), memory functions (e.g. read access, write access, read and write access), communication functions (e.g. sending , Receive), dynamic functions (eg linear transmission elements, ramps) and state machines (eg timers, delays, hysteresis, triggers, debouncers, flip-flops, state tables). Arithmetic operations include, for example, addition, subtraction, multiplication, division, and absolute value formation. Logical operations include, for example, AND, OR, NOT operations. Comparators include, for example, greater than, greater than or equal to, equal to, unequal, less than, less than or equal to comparators. Linear transmission elements are, for example, P, I, PI, PT1, DT1, PDT1 elements. The state machines include state tables with 2, 3, 4 or more states.

In the 3 to 11 different symbols of different standard components are shown. 3 shows an example of a switch, namely a multi-selection switch, in which one of the inputs In1, ..., InN-1, InN can be connected to the output Out1 depending on a state Cond1 and parameters Para1, ... ParaN-1. If Cond1 = ParaN, Out1 = In1; if Cond1 = ParaN, Out1 = InN-1. The value InN is applied to the output Out1 if the Cond1 state does not correspond to any of the parameters Para1, ..., ParaN-1.

In 4 an example of a timer is shown. There is a time at output Out1 that has passed since the start of the measurement. The measurement is only active as long as Cond1 = true; the measurement is reset by setting Cond2 = true.

In 5 an example of a characteristic curve is shown. This standard component uses output curve Para1 to determine output Out1 as a function of input In1.

6 shows a first example of a linear transmission element, namely an integrating I-element. The value In1 is the input of an I controller with an integration constant Para1.

In 7 Another example of a linear transmission element, namely a PT1 element, is shown. The value In1 is the input of a PT1 controller with a time constant Parat.

In 8th an example of a memory management, namely a read access, is shown. The output Out1 is set depending on the bit Para2 of the value Para1.

9 shows an example of a communication, namely a send message command. The value In1 is sent as message Para1.

In 10 shows an example of a state machine, namely a state machine with four states S1, S2, S3 and S4. The state of the machine is at output Out1. The state of the machine changes depending on various conditions Cond1, ..., Cond12 that are present on the state machine and on the old state of the machine that is present on the inputs Para1, ..., Para4.

11 shows an example of a switching element, namely for a switching element for an alternative selection. The value In1 is present at output Out1 if the condition Cond1 is set. Otherwise the value In2 is applied to the output Out1.

In a functional block 4 For each standard component, a certain number of different combinations of input signals (so-called generic test targets) are determined, which are required to achieve different output signals of the standard component. The number of different generic test targets depends on a predefinable test depth of the function test. The generic test goals are based on a database 10 or library determined. In the database 10 the generic test objectives are stored depending on the standard component under consideration and depending on the depth of the functional test. The test objectives are systematically derived prior to the functional test and in the database 10 been filed. The database is for subsequent changes and / or additions 10 kept expandable. The generic test targets form a new set M3, which contains the generic test targets for the underlying set of all prepared specifications or the set of all non-formal requirement specifications as elements.

The generic test objectives for the logical AND operation belonging to the generic requirement component ak ₄ from the example above are:
Z ₄₁ : E1 = 0, E2 = 0
Z ₄₂ : E1 = 1, E2 = 0
Z ₄₃ : E1 = 0, E2 = 1
Z ₄₄ : E1 = 1, E2 = 1,
where E1 and E2 are the inputs of the standard component. The specified test objectives represent complete test coverage. It is conceivable for software modules for which a smaller test depth is sufficient not to use all of the specified generic test targets, but only selected test targets.

Referring to the examples of a standard component according to the 3 to 11 , are according to the multi-selection switch 3 The following test objectives are defined for two different test depths and in the database 10 filed:

Test depth 1:

• In1 ≠ In2, ..., InN; Cond1 = Para1; Out1 = In1
• In2 ≠ In1, In3, ..., InN; Cond1 = Para2; Out1 = In2
• ...
• InN-1 ≠ In1, ..., InN; Cond1 = ParaN-1; Out1 = InN-1
• InN ≠ In1, ..., InN-1; Cond1 ≠ Para1, Para2, ..., ParaN; Out1 = InN

test depth 2 :

• In1 = Min (PhysVal); In2, ..., InN = Max (PhysVal); cond1 = Para1; Out1 = In1 = Min (PhysVal)
• In2 = Min (PhysVal); In1, In3, ..., InN = Max (PhysVal); cond1 = Parat; Out1 = In2 = Min (PhysVal)
• ...
• InN-1 = Min (PhysVal); In1, ..., InN = Max (PhysVal); Cond1 = ParaN-1; Out1 = InN-1 = Min (PhysVal)
• InN = Min (PhysVal); In1, ..., InN-1 = Max (PhysVal); Cond1 ≠ Para1, Para2, ..., Paran; Out1 = InN = Min (PhysVal)
• In1 = Max (PhysVal); In2, ..., InN = Min (PhysVal); Cond1 = Para1; Out1 = In1 = Max (PhysVal)
• In2 = Max (PhysVal); In1, In3, ..., InN = Min (PhysVal); cond1 = Para2; Out1 = In2 = Max (PhysVal)
• ...
• InN-1 = Max (PhysVal); In1, ..., InN = Min (PhysVal); Cond1 = Paran-1; Out1 = InN-1 = Max (PhysVal)
• InN = Max (PhysVal); In1, ..., InN-1 = Min (PhysVal); Cond1 $ Para1, Para2, ..., ParaN; Out1 = InN = Max (PhysVal), where Min (PhysVal) and Max (PhysVal) the interval of all possible values between one represent the lower and upper limits of the specification.

According to the timer 4 the following test objectives are defined for three different test depths and in the database 10 filed:

Test depth 1:

• 0 <age Value of Out1 <Max (PhysVal); Cond1 = wrong; Cond2 = wrong; Out1 = const.
• 0 <old value from Out1 <Max (PhysVal); Cond1 = wrong; Cond2 = true; Out1 is reset to 0
• old value of Out1 = 0; Cond1 = true; Cond2 = wrong; out1 = Time since the start of the measurement
• 0 <old value from Out1 <Max (PhysVal); Cond1 = true; Cond2 = wrong; Out1 = time since the start of the measurement
• 0 <old value from Out1 <Max (PhysVal); Cond1 = true;
• Cond2 = true; Out1 is reset to 0

Test depth 2:

• old value of Out1 = 0; Cond1 = wrong; Cond2 = true; out1 = 0 = const.
• old value of Out1 = Max (PhysVal); Cond1 = true; Cond2 = wrong; Out1 = time since the start of the measurement
• old value of Out1 = 0; Cond1 = true; Cond2 = true; Out1 = 0 = const.

Test depth 3:

• old value of Out1 = 0; Cond1 = wrong; Cond2 = wrong; Out1 = 0 = const.
• old value of Out1 = Max (PhysVal); Cond1 = wrong; Cond2 = not correct; Out1 = Max (PhysVal) = const.
• old value of Out1 = Max (PhysVal); Cond1 = wrong; Cond2 = true; Out1 is reset to 0
• old value of Out1 = Max (PhysVal) -1; Cond1 = true; Cond2 = not correct; Out1 = time since the start of the measurement
• old value of Out1 = Max (PhysVal); Cond1 = true; Cond2 = true; Out1 is reset to 0

For the characteristic according to 5 the following test objectives are defined for three different test depths and in the database 10 filed:

Test depth 1:

• In1 = scanning point k; Curve Para1; Value of the sampled Point ≠ 0; Out1 = function (Para1, In1) ≠ 0
• In1 = scanning point k; Curve Para1; Value of the sampled point = 0; Out1 = 0

Test depth 2:

• In1 = scanning point k; Curve Para1; Value of the sampled Points = Min (PhysVal); Out1 = Min (PhysVal)
• In1 = scanning point k; Curve Para1; Value of the sampled point = Max (PhysVal); Out1 = Max (PhysVal)

Test depth 3:

• In1 = Min (PhysVal); Out1 = function (Para1, In1)
• In1 = Max (PhysVal); Out1 = function (Para1, In1)

For the integrating I-link according to 6 the following test objectives are defined for three different test depths and in the database 10 filed:

Test depth 1:

• Min (PhysVal) <In1, Parat <Max (PhysVal); Out1 = ramp with slope Para1 · In1

Test depth 2 (limits of Input signal In1):

• In1 = Min (PhysVal); Min (PhysVal) <Para1 <Max (PhysVal); Out1 = ramp with slope · In para1 1
• In1 = Max (PhysVal); Min (PhysVal) <Para1 <Max (PhysVal); Out1 = ramp with slope Para1 · In 1

Test depth 3 (limits of Constant AI):

• Para1 = Min (PhysVal); Min (PhysVal) <In1 <Max (PhysVal); Out1 ramp with slope Para1 · In1
• Para1 = Max (PhysVal); Min (PhysVal) <In1 <Max (PhysVal); Out1 ramp with slope Para1 · In1

For the PT1 link according to 7 the following test objectives are defined for three different test depths and in the database 10 filed:

Test depth 1:

• In1 = step from 0 to X; 0 <Para1 <Max (PhysVal); out1 = X · (1-exp (-1 / Para1])

Test depth 2 (limits of Input signal In1):

In1 = step from 0 to X = Min (PhysVal); 0 < Para1 <Max (PhysVal); Out1 = X · (1-exp (-1 / Para1])

In1 = step from 0 to X = Max (PhysVal); 0 <Para1 <Max (PhysVal); Out1 = X · (1-exp (-1 / Para1])

Test depth 3 (limits of Constant T1):

• Para1 = 0; In1 = step from 0 to X; Out1 = X · (1-exp (-1 / Para1])
• Para1 = Max (PhysVal); In1 = step from 0 to X; Out1 = X · (1-exp [-1 / Para1])

For read access according to 8th the following test objectives are defined for two different test depths and in the database 10 filed:

Test depth 1:

• Bit Para2 of the variable Para1 set, all other bits not set; Out1 set

Test depth 2:

• Bit Para2 of the variable Para1 not set, all others Bits set; Out1 not set

According to the send message command 9 the following test target is defined and in the database 10 filed:

test depth 1 :

• In1 ≠ content the message Para1; then the content of the message is Para1 = In1

For the state machine with four states according to 10 the following test objectives are defined for two test depths and in the database 10 filed:

Test depth 1 (becomes state changed correctly?):

• Old value of Out1 = Para1; Cond1 = true; Cond2 = Cond3 = Cond8 = Cond10 = Cond11 = wrong; Out1 = Para2
• Old value of Out1 = Parat; Cond8 = true; Cond1 = Cond6 = Cond7 = Cond10 = Cond12 = wrong; Out1 = Para4
• Old value of Out1 = Para1; Cond10 = true; Cond1 = Cond4 = Cond5 = Cond8 = Cond9 = wrong; Out1 = Para3
• Old value of Out1 = Para2; Cond2 = true; Cond1 = Cond3 = Cond8 = Cond10 = Cond11 = wrong; Out1 = Para1
• Old value of Out1 = Para2; Cond3 = true; Cond2 = Cond4 = Cond5 = Cond9 = Cond11 = wrong; Out1 = Para3
• Old value of Out1 = Para2; Cond11 = true; Cond2 = Cond3 = Cond6 = Cond7 = Cond12 = wrong; Out1 = Para4
• Old value of Out1 = Para3; Cond4 = true; Cond2 = Cond3 = Cond5 = Cond9 = Cond11 = wrong; Out1 = Para2
• Old value of Out1 = Para3; Cond5 = true; Cond4 = Cond6 = Cond7 = Cond9 = Cond12 = wrong; Out1 = Para4
• Old value of Out1 = Para3; Cond9 = true; Cond1 = Cond4 = Cond5 = Cond8 = Cond10 = wrong; Out1 = Para1
• Old value of Out1 = Para4; Cond6 = true; Cond4 = Cond5 = Cond7 = Cond9 = Cond12 = wrong; Out1 = Para3
• Old value of Out1 = Para4; Cond7 = true; Cond1 = Cond6 = Cond8 = Cond10 = Cond12 = wrong; Out1 = Para1
• Old value of Out1 = Para4; Cond12 = true; Cond2 = Cond3 = Cond6 = Cond7 = Cond11 = wrong; Out1 = Para2

Test depth 2 (becomes state correct?):

• Old value of Out1 = Para1; Cond1 = Cond8 = Cond10 = wrong
• Old value of Out1 = Parat; Cond2 = Cond3 = Cond11 = wrong
• Old value of Out1 = Para3; Cond4 = Cond5 = Cond9 = wrong
• Old value of Out1 = Para4; Cond6 = Cond7 = Cond12 = wrong

For the switching element for an alternative selection according to 11 the following test objectives are defined for two test depths and in the database 10 filed:

Test depth 1:

• In1 ≠ In2; Cond1 = true; Out1 = In1
• In1 ≠ In2; Cond1 = wrong; Out1 = In2

Test depth 2:

• In1 = Min (PhysVal); In2 = Max (PhysVal); Cond1 = true; Out1 = In1 = Min (PhysVal)
• In1 = Min (PhysVal); In2 = Max (PhysVal); Cond1 = wrong; out1 = In2 = Max (PhysVal)
• In1 = Max (PhysVal); In2 = Min (PhysVal); Cond1 = true; out1 = In1 = Max (PhysVal)
• In1 = Max (PhysVal); In2 = Min (PhysVal); Cond1 = wrong; out1 = In2 = Min (PhysVal)

In a next step, the set of M3 with the generic test targets in a function block 5 transferred into a further set M4, which contains the specific test targets z ₄₁ ', ..., Z ₄₄ ' for the set of all non-formal requirements specifications as elements. The relationships required for this result from the comparison of the requirement components with the underlying non-formal requirements. In other words, in the function block 5 the local names E1, E2 of the inputs of the standard components have been renamed the module's global designations "Wiper", "Ignition".

The specific test targets belonging to the generic test targets z ₄₁ , ..., z ₄₄ from the example above are, for example:
Z ₄₁ ': wiper OFF, ignition OFF
Z ₄₂ ': wiper ON, ignition OFF
Z ₄₃ ': wiper OFF, ignition ON
Z ₄₄ ': wiper ON, ignition ON

The set M4 of the concrete test targets will eventually become a function block 6 Test cases for the functional test of the software module created on the basis of the determined test goals. A test case can also consider more than one test goal. The various test cases are summarized in a test case set M5. In the function block 6 the test case set M5 is generated from the previously determined number M4 of specific test targets, taking into account the global designations of the module, by determining a number of different combinations of input signals (so-called concrete test targets) for the entire module, which are necessary to ensure that all of them previously Generic test objectives of the standard components determined occur at least once.

According to the present invention the function test of a software module is systematized. It a defined test coverage can be achieved. It is also Test procedure reproducible. By means of the method according to the invention generated test case quantity can certainly be a predeterminable test depth of the function test can be achieved.

The generation of the test case set is divided into steps analysis of requirements, identification of Test targets, assignment of test targets to test cases and design of test cases divided to test software based on non-formal requirements to carry out systematically.

The inventive method reduces the complexity of the test case design by dividing it into several in succession to be executed, clearly separate sub-steps. This reduces the susceptibility to errors and leads to test results that are highly reproducible, complete, consistent and are understandable.

Furthermore, the process can be easily integrated into the software development process, since documentation is automatically created step by step when the sub-steps are carried out (see function block 7 ). Based on this documentation, it is easy to make statements about the test case coverage of the specification. In addition, the design results can be easily checked using the documentation.

In a functional block 8th the function test of the software module to be tested is then carried out in a manner known per se on the basis of the generated test case set M5. In a functional block 9 the method according to the invention is then ended.

In another example, a software module is to be tested, of which a graphical block diagram in 12 is shown. This includes two standard components, a bigger comparator 11 and a logical AND operation 12 , The bigger comparator 11 has two inputs E1, E2 and one output. The logical AND link 12 has two inputs E3, E4 and one output A1. The output of the bigger comparator 11 is as input E4 to the AND link 12 guided. This in 12 The block diagram shown is one possibility of a formal description of the software module as described in the function block 3 of the flow chart 1 is created.

For the two standard components 11 . 12 can according to function block 4 the associated generic test targets can be found in the flowchart from a library. For the bigger comparator 11 if the functional test is deep:
Int1>Int2; Out1 = 1
Int1 = Int2; Out1 = 0
Int1 <Int2; Out1 = 0

For the AND link 12 are the generic test objectives for a high test depth of the functional test:
Int1 = 0; Int2 = 0; Out1 = 0
Int1 = 1; Int2 = 0; Out1 = 0
Int1 = 0; Int2 = 1; Out1 = 0
Int1 = 1; Int2 = 1; Out1 = 1

According to function block 5 of the flow chart 1 the generic test targets are converted into concrete test targets. In the present example, the result is for the larger comparator 11 :
Test goal 11.1: E1>E2; E4 = 1
Test goal 11.2: E1 = E2; E4 = 0
Test goal 11.3: E1 <E2; E4 = 0

And for the logical AND link 12 surrendered:
Test goal 12.1: E4 = 0; E3 = 0; A1 = 0
Test goal 12.2: E4 = 1; E3 = 0; A1 = 0
Test goal 12.3: E4 = 0; E3 = 1; A1 = 0
Test goal 12.4: E4 = 1; E3 = 1; A1 = 1

According to function block 6 of the flow chart, the test case set M5 is then generated based on the test targets. The following test cases result in the present example:
Test case 1: E1 = 0; E2 = 0; E3 = 0; A1 = 0
Test case 2: E1 = 1; E2 = 0; E3 = 0; A1 = 0
Test case 3: E1 = 0; E2 = 1; E3 = 1; A1 = 0
Test case 4: E1 = 1; E2 = 0; E3 = 1; AI = 1

Test case 1 covers the test objectives 11.2 and 12.1, test case 2, test objectives 11.1 and 12.2, the test case 3 test targets 11.3 and 12.3 and test case 4 covers the test targets 11.1 and 12.4. With the input signals of these test cases the inputs E1, E2, E3 of the software module to be tested is applied, and it is checked whether sets the specified output signal at output A1.

In 2 is a device according to the invention for generating a test case set for a functional test of a software module in its entirety with the reference symbol 20 designated. The device 20 comprises a storage element 21 , which is designed as a flash memory. Alternatively, the storage element 21 also be designed as a random access memory or as a read-only memory. On the storage element 21 A computer program is stored which is suitable for executing the method according to the invention when it is on a computing device 22 the device 20 expires. The computing device 22 is designed in particular as a microprocessor. Between the storage element 21 and the computing device 22 is a data transmission connection 23 provided, which is designed, for example, as a data line or as a bus system. Via the data connection 23 becomes the computer program for processing on the computing device 22 either in sections or as a whole of the storage element 21 transfer. Conversely, you can use the data connection 23 also results of calculations or other values that arise during the processing of the computer program from the computing device 22 to the storage element 21 transferred and stored there. For example, the number of test cases determined in the course of processing the computer program is also stored in the memory element 21 stored.

The device further comprises 20 a read-only memory 24 , which is designed, for example, as a random access memory. On the read-only memory 24 the library or database is stored, which contains the standard components for the formal description of the function of the module to be tested as well as the generic test objectives of the standard components. The computer program can run on the computing device during processing 22 via another data connection 25 to the read-only memory 24 access and download standard components and corresponding generic test targets for further processing.

The device receives the input variable 20 the set M1, which contains the individual non-formal requirements as elements. Output size of the device 20 is the determined test case quantity M5. Alternatively, the quantity M4 can also be output as an output variable, which contains the specific test targets z ₄₁ ', ..., z ₄₄ ' for the set of all non-formal requirement specifications as elements. In this case, the test case set M5 can then be outside the device 20 to be generated.

Claims (9)

Method for generating a test case set (M5) for a functional test of a software module, characterized by the following method steps: - formal description of a function of the module by at least one standard component (M2) from a database ( 10 ); - For each standard component, determining a number of different combinations of input signals (so-called generic test targets M3) which are required to achieve different output signals of the standard component, the number of different generic test targets being dependent on a predefinable test depth of the functional test; - Renaming the local names of the inputs of the standard components to global names of the module (so-called concrete test targets M4); and - taking into account the global designations of the module, generating the test case quantity (M5) from the previously determined number (M4) of specific test targets, by determining a number of different combinations of input signals for the entire module, which are necessary so that all previously determined generic test objectives (M3) of the standard components occur at least once, whereby a test case comprises at least one test objective. Method according to Claim 1, characterized in that the function of the module is described by at least one non-formal requirement specification (M1) which then leads to the formal description (M2) of the function of the module by the at least one standard component from a database ( 10 ) is processed. Method according to Claim 1 or 2, characterized in that, in order to determine the generic test targets (M3) of a standard component, the generic test targets in dependence on the standard component under consideration and in dependence on the test depth of the functional test of the database ( 10 ) can be removed. Method according to one of claims 1 to 3, characterized in that fewer different genes for a small test depth of the functional test test targets (M3) and, for a high test depth, more different generic test targets (M3) can be determined. Method according to one of claims 1 to 4, characterized in that that the generation of the test case quantity (M5) is documented automatically becomes. Computer program running on a computing device ( 22 ), in particular executable on a microprocessor, characterized in that the computer program for executing a method according to one of claims 1 to 5 is executable if it is on the computing device ( 22 ) expires. Computer program according to claim 6, characterized in that the computer program on a memory element ( 21 ), in particular on a random access memory, on a read-only memory or on a flash memory. Contraption ( 20 ) for generating a test case set (M5) for a functional test of a software module, characterized in that the device ( 20 ) comprises: means for the formal description of a function of the module by at least one standard component from a database ( 10 ); Means for determining a number of different combinations of input signals (so-called generic test targets M3) for each standard component, the generic test targets being required to achieve different output signals of the standard component, and the number of different generic test targets depending on a predeterminable test depth the function test; - Means for renaming the local names of the inputs of the standard components into global names of the module (so-called concrete test targets M4); and - means for generating the test case quantity (M5) from the previously determined number of concrete test targets, taking into account the global designations of the module, by determining a number of different combinations of input signals for the entire module, which are required so that all previously determined generic ones Test objectives of the standard components occur at least once, whereby a test case comprises at least one test objective. Contraption ( 20 ) according to claim 8, characterized in that the device comprises a computing device ( 22 ), in particular a microprocessor, on which a computer program is executable, which is suitable for executing a method according to one of claims 1 to 5, if it is on the computing device ( 22 ) expires.