Home

Wetter

Kalender

Software

Impressum

Automatischer SW-Test: Typische Probleme und einfache L�sungsans�tze

Inhalt

1 Organisation des Testaufbaus
- 1.1 Simulation der Umgebung
  - 1.1.1 Typische Struktur
  - 1.1.2 Begriffsdefinition: Mocks, Stubs, Dummies
- 1.2 Zugriff auf das Testobjekt
- 1.3 Dummy-Implementierungen
2 Verifikation und Teststeuerung
- 2.1 Zentralisierte Erfassung der "Testereignisse" (TestEvents)
  - 2.1.1 Prinzipieller Mechanismus
  - 2.1.2 Simulation der Fake-Objects
  - 2.1.3 Formulierung der Testf�lle (Test cases)
- 2.2 Multithreading, Synchronisation paralleler Abl�ufe
  - 2.2.1 Naiver Ansatz: Warten mit Sleep
  - 2.2.2 Gezielte Synchronisation
  - 2.2.3 Simulation der Fake-Objects
  - 2.2.4 Formulierung der Testf�lle (Test cases)
3 Kontrollierte Testausf�hrung

Einleitung und Motivation

Die im nachfolgenden Text beschriebenen Vorgehensweisen und Realisierungsans�tze stammen aus Projekten im Umfeld der Automatisierungstechnik, die unter aktuellen Microsoft-Windows-Betriebssystemen realisiert wurden. Stichpunkte: Parallelisierung von Abl�ufen, Multithreading, C++, Microsoft Visual Studio.

Die Erstellung und laufende Wartung automatisierter SW-Tests wurde dabei als notwendiges Hilfsmittel zur Gew�hrleistung einer �berzeugenden SW-Qualit�t betrachtet. Um den Wartungsaufwand in Grenzen zu halten, war dabei auch der Aspekt der Wiederverwendung von Bedeutung.

Querverweise:

Top1 Organisation des Testaufbaus

Top1.1 Simulation der Umgebung

Das Testobjekt wird typischerweise in eine spezifische Testumgebung eingebettet, in der alle ben�tigten Kommunikationspartner instanziiert werden, so dass aus Sicht des Testobjektes kein Unterschied zum Betrieb in der Produktivumgebung zu erkennen ist.

Die Kommunikationspartner werden dabei h�ufig in vereinfachter Form simuliert. Teilweise ist jedoch auch das direkte Einbinden von Original-Klassen/Komponenten aus dem Produktivcode m�glich und sinnvoll.

Top1.1.1 Typische Struktur

Schematische Darstellung:
Simulation der Umgebung

Bei der Erstellung einer spezifischen Testumgebung sollten folgende Aspekte bedacht werden:

Vermeidung zus�tzlicher Abh�ngigkeiten
Bei der Einbindung vorhandener Originalkomponenten erspart man sich zwar den Realisierungsaufwand f�r eine entsprechende Simulationskomponente, dieser Vorteil kann jedoch schnell durch folgende Aspekte zunichte gemacht werden:
- Die einzubindende Komponente befindet sich selbst noch in Entwicklung und steht erst zu einem sp�terem Zeitpunkt mit den erforderlichen Funktionalit�ten zur Verf�gung.
- Die einzubindende Komponente hat noch kein stabiles Verhalten. Anstatt das eigentliche Testobjekt zu �berpr�fen muss man ggf. erst entsprechende Fehleranalysen f�r die eingebundene Komponente durchf�hren.
- Die einzubindende Komponente ben�tigt ihrerseits eine Reihe von Kommunikationspartnern
M�glichkeit der Ansteuerung und Verifikation
H�ufig ist es erforderlich und sinnvoll zumindest einige Aspekte der Kommunikation zwischen Testobjekt und Kommunikationspartnern zu �berpr�fen. Das bedeutet:
- testrelevante Fehlerf�lle k�nnen nachgestellt werden, so kann es z.B. erforderlich sein, dass ein Kommunikationspartner des Testobjektes so parametriert wird, dass er ein bestimmtes (Fehl-) Verhalten zeigt, wenn er vom Testobjekt angesprochen wird
- alle test relevanten Aspekte der Kommunikation zwischen Kommunikationspartnern und Testobjekt sind im Test �berpr�fbar (z.B. �bergebene Parameter beim Schnittstellenaufruf)

Grundelemente eines typischen Testablaufes (siehe Abbildung)

Innerhalb eines Testfalles (test case) wird eine Schnittstellenfunktion des Testobjektes aufgerufen
Das Testobjekt delegiert zur Erf�llung der Anfrage bestimmte Teilaufgaben an seine Kommunikationspartner
Zur Verifikation eines korrekten Ablaufes sind dann innerhalb des Testfalles folgende Schritte m�glich:
- Unmittelbar pr�fbare Aspekte des Aufrufes (Returnwert, R�ckgabeparameter, nachfolgende Statusabfragen am Testobjekt selbst) k�nnen direkt verifiziert werden.
- Die erfolgten Aufrufe in die Laufzeitumgebung m�ssen erfasst und ausgewertet werden

Top1.1.2 Begriffsdefinition: Mocks, Stubs, Dummies

Je nach Verwendung der simulierten Komponenten unterscheidet man in der Test-Literatur folgende Begriffe:

Dummy-Object

ein Dummy-Objekt wird innerhalb des Tests lediglich als Parameter weitergereicht
Methodenaufrufe erfolgen nicht, es sind deshalb keine Methodenrealisierungen erforderlich

Fake- oder Stub-Object

realisiert eine (stark vereinfachte) funktionsf�hige Implementierung, die f�r Produktiv-Zwecke nicht geeignet ist
die Realisierung beschr�nkt sich auf die f�r den Testfall erforderlichen Funktionen
Informationen �ber die durchgef�hrten Aufrufe k�nnen aufgezeichnet und zur Abfrage durch �bergeordnete Instanzen bereitgestellt werden

Mock-Object

wird "vorprogrammiert" mit den zu erwartenden Aufrufen durch das Testobjekt
f�hrt die Verifikation des Kommunikationsablaufes in der "Verifikationsphase" eigenst�ndig durch

Weiterf�hrende Referenzen

Martin Fowler: Mocks aren't Stubs
Begriffsdefinitionen zu Stubs und Mockobjects, Gegen�berstellung der Verifikation des Zustandes gegen�ber der Verifikation des Verhaltens.

Gerard Meszaros: xUnit Patterns: Mocks, Fakes, Stubs and Dummies
Begriffsdefinitionen, umfangreiche Darstellung der m�glichen Strategien beim Testen

Top1.2 Zugriff auf das Testobjekt

Top1.2.1 Beschr�nkung auf �ffentliche Interfaces (Blackbox-Test)

F�r manche Tests ist es ausreichend, die regul�ren Schnittstellen des zu testenden Systems anzusteuern. Dies bedeutet, da� sowohl das "Triggern" des zu testenden Systems wie auch das "Beobachten" der erwarteten Ergebnisse bzw. Reaktionen �ber die �ffentlichen Schnittstellen des zu testenden Systems erfolgen kann.

F�r diese F�lle sind keine besonderen Vorkehrungen f�r den Zugriff auf das Testobjekt erforderlich.

Top1.2.2 Zugriff auf private Daten (Whitebox-Test)

Der Zugriff auf private Daten kann aus folgenden Gr�nden sinnvoll sein:

Setzen von Anfangsbedingungen f�r einen Testfall
Durch den unmittelbaren Zugriff auf private Memberdaten k�nnen beliebige Zust�nde im zu testenden System leicht eingestellt werden. Auf "regul�re" Weise �ber die �ffentlichen Schnittstellen sind diese Zust�nde oft nur m�hsam herzustellen, denn dies ist oft verbunden mit:
- Hochfahren des Gesamtsystems mit ver�nderten Konfigurationsdaten, dadurch entsprechend hoher Zeitbedarf f�r das Herunterfahren und anschliessende Hochfahren des Systems. Verwaltungsaufwand f�r die entsprechenden Konfigurationsfiles.
- Aufwendiges Durchspielen ganzer Szenarien um eine gew�nschte Vorbedingung herzustellen
�berpr�fung interner Abl�ufe/Algorithmen im zu testenden System
- Um die Korrektheit eines SW-Systems zu pr�fen, ist es h�ufig sinnvoll auch interne Abl�ufe und Zust�nde zu �berwachen. Meist ist die Kontrolle �ber die regul�ren �ffentlichen Schnittstellen nur indirekt und unvollst�ndig m�glich.
- Anwendungsbeispiel: Abfrage der Zust�nde einer Statemachine, die das Verhalten einer SW-Komponente bestimmt.

Randbedingungen:

F�r das zu testende System sind folgende Eigenschaften w�nschenswert:

der Zugriff auf Interna soll nur f�r den Test m�glich sein
der regul�re Produktivcode soll zwar das Testen unterst�tzen aber dennoch m�glichst keine spezifischen Anweisungen f�r den Test enthalten

L�sungsansatz: friend-Deklaration

// MyClassToTest.h (part of the system under test)

class MyClassToTest : public IMyClassToTest
{
    public:

      // Methods of public interface IMyClassToTest
      virtual void DoSomethingPublic (void);

    private:
        int m_internalState;

        // Allow full access for the purpose of testing
        friend class AccessForWhiteboxTest;
};

// MyTest.cpp (part of the test environment)

// Use the internal structure of the object under test
#include <TestObject/Internals/MyClassToTest.h>

class AccessForWhiteboxTest
{
    public:

    static void SetInternalState (
        IMyClassToTest* in_pIMyClass
        int             in_newState)
    {GetInternals (in_pIMyClass)-> m_internalState = in_newState;}

    static int GetInternalState (
        IMyClassToTest* in_pIMyClass)
    {return GetInternals (in_pIMyClass)-> m_internalState;}

    static MyClassToTest* GetInternals (IMyClassToTest* in_pIMyClass)
    {
        // Knowing the internal structure allows casting of the
        // public interface pointer to the specific class type
        return static_cast<MyClassToTest*>(in_pIMyClass);
    }
};

// MyTestCases.cpp (part of the test environment)

void MyTestFunction ()
{
    IMyClassToTest* pIMyClass = ... // get interface via the
                                    // "official" public access method

    // set some initial state
    AccessForWhiteboxTest::SetInternalState (pIMyClass , INITIAL_STATE);

    ...

    // after some interactions the state should have changed
    Verify (AccessForWhiteboxTest::GetInternalState (pIMyClass) == RUNNING);
}

Hinweis:
Der Beispielcode wurde absichtlich einfach gew�hlt. In der modernen Programmierpraxis sollten anstelle von Raw-Pointern besser Smart-Pointerklassen oder auch Referenzen eingesetzt werden.

Top1.2.3 Zugriff auf private Methoden (Whitebox-Test)

Neben dem Zugriff auf alle Attribute (siehe vorhergehender Abschnitt), kann es auch sinnvoll sein, private Methoden (oder allgemein Methoden ausserhalb des �ffentlichen Interfaces einer Klasse) anzusteuern. Nimmt man eine �bliche Organisation in getrennte �bersetzungseinheiten an (z.B. unter MS-Windows eine eigene DLL f�r jedes Teilsystem), so tritt dabei das Problem auf, dass nicht virtuelle Funktionen des zu testenden Systems in der �bersetzungseinheit der Testumgebung nicht zur Verf�gung stehen.

L�sungsansatz: exportierte Zugriffsklasse

Die Klasse AccessForWhiteboxTest wird in die �bersetzungseinheit der zu testenden Komponente verlagert und dort als Klasse zur allgemeinen Verwendung exportiert. Da sie sich in der gleichen �bersetzungseinheit wie die zu testende Klasse befindet, sind alle Methoden und Daten prinzipiell zugreifbar.

// MyClassToTest.h (part of the system under test)

class MyClassToTest : public IMyClassToTest
{
    public:
      ...

    private:
        int m_internalState;

        // Allow full access for the purpose of testing
        friend class AccessForWhiteboxTest;

    private:
        void DoSomethingInternal (void);
};

// AccessForWhiteboxTest.h (part of the system under test)

#ifdef SYSTEM_UNDER_TEST_EXPORTS
#define SYSTEM_UNDER_TEST_API __declspec(dllexport)
#else
#define SYSTEM_UNDER_TEST_API __declspec(dllimport)
#endif

// Use the internal structure of the object under test
#include <TestObject/Internals/MyClassToTest.h>

SYSTEM_UNDER_TEST_API class AccessForWhiteboxTest
{
    public:

    static void DoSomethingInternal  (
        IMyClassToTest* in_pIMyClass
        int             in_newState)
    {GetInternals()-> DoSomethingInternal();}

    static void SetInternalState (
        IMyClassToTest* in_pIMyClass
        int             in_newState);
    static int GetInternalState (
        IMyClassToTest* in_pIMyClass)
    static MyClassToTest* GetInternals (IMyClassToTest* in_pIMyClass)
    {
        // Knowing the internal structure allows casting of the
        // public interface pointer to the specific class type
        return static_cast<MyClassToTest*>(in_pIMyClass);
    }
};

// MyTestCases.cpp (part of the test environment)

// Use the access object exported by the system under test
#include <TestObject/Internals/AccessForWhiteboxTest.h>

void MyTestFunction ()
{
    IMyClassToTest pIMyClass = ... // get interface via the
                                   // "official" public access method

    // call some private function which would not be available
    // by regular means
    AccessForWhiteboxTest::DoSomethingInternal(pIMyClass);

    ...
}

Top1.3 Dummy-Implementierungen

In vielen Projekten werden auch an Interfaces �ber einen l�ngeren Zeitraum �nderungen durchgef�hrt. Um den st�ndigen Aktualisierungsaufwand f�r Testumgebungen in Grenzen zu halten kann nach folgendem Modell vorgegangen werden:

Annahmen und Randbedingungen:

Es werden h�ufig nur einige Methoden eines Interfaces w�hrend der Testausf�hrung tats�chlich aufgerufen.
F�r die Instanziierbarkeit eines Objektes m�ssen aber alle Methoden vorhanden sein.

Ansatz:

Die Originalkomponenten stellen Dummy-Implementierungen ihrer Interfaces zur Verf�gung, die stets aktuell gehalten werden.
In den Testumgebungen werden statt der Original-Interfaces die Dummy-Implementierungen verwendet.
Vorteil:
- es m�ssen nur die tats�chlich aufgerufenen Methoden realisiert werden
- alle anderen Methoden passen sich stets an ge�nderte Signaturen und sonstige �nderungen "automatisch" an

Dummy-Implementierung eines Interfaces:

// ISomeInterfaceDummyImpl.h (part of the system under test)

// DummyImplementation of interface ISomeInterface 
struct ISomeInterfaceDummyImpl : public ISomeInterface
{
    virtual int GetSomeInt()              {TEST_DUMMY_IMPL;}
    virtual void DoSomething (int in_val) {TEST_DUMMY_IMPL;}
    virtual void DoSomethingElse()        {TEST_DUMMY_IMPL;}
    ...
};

// CheckDummyImpl.cpp (part of the system under test)

class TestISomeInterfaceDummyImpl : public ISomeInterfaceDummyImpl
{};

... (classes for other dummy interfaces)

// Verify that all dummy implementations can be instantiated
//
// Remark: This function is never called. Its only purpose is
// that the compiler checks that the classes deriving from the
// dummy implementations can be instantiated. A compile error
// in this function usually is caused by changes to some interface.
// With the compile error the developer is reminded to adjust also
// the dummy implementation of the interface.
void TestDummyImplementationsOfInterfaces
{
    new TestISomeInterfaceDummyImpl;

    ... (other test instantiations)
}

Makro TEST_DUMMY_IMPL:

// Makro TEST_DUMMY_IMPL
// Produce hint that the dummy implementation is used.
// Debug version   : assert
// Release version : throw std::exception
// Remark:
// If this macro is called within a unit test, then the corresponding
// method needs to be implemented within the specific test environment.
#define TEST_DUMMY_IMPL                                              \
    assert(!\"Do not use dummy implementation!\");                   \
    throw std::exception(\"Do not use dummy implementation for \")   \
    +   std::string(__FUNCTION__)), __FILE__, __LINE__, __FUNCTION__)

Anwendung bei der Realisierung eines FakeObjects:

class MyFakeObject : public ISomeInterfaceDummyImpl
{
public:

  // Only realize the methods which are really used within the test
  virtual int GetSomeInt()
  {return 17;}
};

Durch die Ableitung von der Dummy-Implementierung des Interfaces ist gew�hrleistet, dass das FakeObject stets instanziiert werden kann, selbst wenn f�r das zugrunde liegende Interface �nderungen vorgenommen werden.

Top2 Verifikation und Teststeuerung

Top2.1 Zentralisierte Erfassung der "Testereignisse" (TestEvents)

Im Unterschied zur Verwendung mehrerer spezifischer Mock-Objekte, die das beobachtete Verhalten jeweils aus ihrer Sicht eigenst�ndig �berpr�fen, wird im Folgenden versucht, die Verifikationslogik zu verallgemeinern und in eine �bergreifende, zentrale Komponente auszulagern, die unabh�ngig von der spezifischen Testumgebung eingesetzt und wiederverwendet werden kann.

Top2.1.1 Prinzipieller Mechanismus

Es werden dabei folgende Prinzipien verfolgt:

Text-Ereignisse
einfaches Realisierungsprinzip: ein Ereignis entspricht einem einzeiligen Text, der alle relevanten Informationen (Methodenaufruf, Parameter, meldende Klasse/Komponente, Auflistung relevanter Werte etc.) enth�lt. Der Umfang der Informationen wird vollst�ndig vom Autor der spezifischen Testumgebung bestimmt.
Singleton, von �berall erreichbar
In der gesamten Testumgebung gibt es genau eine Instanz der Klasse TestEvents. Entsprechend dem Singleton-Prinzip ist diese Instanz erreichbar f�r:
- Fake-Objekte, die Aufrufe durch das Testobjekt weitermelden
- Test cases, die die Verifikation durch �berpr�fung der eingetragenen "Testereignisse" durchf�hren

Schematische Darstellung:

TestEvents

Hinweis:
Das vorgeschlagene Konzept der TestEvents hat �hnlichkeiten mit dem Konzept des "TestSpy" aus xUnit Patterns: Test Spy

Weitergehende M�glichkeiten

Da alle relevanten Testereignisse an die zentrale Framework-Komponente "TestEvents" geleitet werden, ergeben sich auf einfache Weise die folgenden zus�tzlichen Erweiterungsm�glichkeiten:

Testprotokoll, Logfile
Die Eintr�ge in TestEvents k�nnen in ein Logfile geleitet werden, das einerseits als formaler Beleg f�r die Durchf�hrung des Tests oder auch als Grundlage f�r die Analyse aufgetretener Fehler dienen kann.
Traces
In �hnlicher Weise k�nnen Traceausgaben generiert werden, die in Verbindung mit den regul�ren Traceausgaben des Testobjektes den Kommunikationsablauf des Gesamtsystems widerspiegeln.
Fehleranalysen
Tritt ein erwartetes Testereignis nicht ein, so ist es i.d.R. f�r die Analyse hilfreich, die bis dahin aufgezeichneten Testereignisse zusammen mit der Information, ob sie erwartet wurden oder nicht, abrufen zu k�nnen.

Top2.1.2 Simulation der Fake-Objects

H�ufig ist es ausreichend, im Test lediglich den Aufruf eines bestimmten Objektes aus der Laufzeitumgebung des Testobjektes nachzuweisen. F�r diese F�lle beschr�nkt sich die Simulation des FakeObjects auf einfache Methodenimplementierungen nach folgendem Muster:

void FakeObject1::DoSomeService (void)
{
    // simply log info about call as a line of text
    TheTestEvents()->AddEvent("DoSomeService (called at FakeObject1)");
}

In manchen Situationen ist es erforderlich, das Kommunikationsverhalten des FakeObjects abh�ngig vom Testfall zu beeinflussen, um entsprechende R�ckwirkungen auf das TestObjekt ausl�sen zu k�nnen.
Ausserdem kann es zur Vereinfachung der Verifikation sinnvoll sein, dass je nach Testfall andere Aspekte / andere FakeObjects �berwacht werden. Das erreicht man am einfachsten dadurch, dass man einem FakeObject mitteilen kann, ob es seine Aktivit�ten als Testereignisse weitermelden soll:

class FakeObject2
{
public:

    //-----  interface method called by the TestObject -----

    int DoSomeOtherService (int in_param)
    {
        // (1) log info about call as a line of text
        if (m_logActivitiesToTestEvents)
        {
            TheTestEvents()->AddEvent("DoSomeOtherService in=",
                in_param, " (called at FakeObject2)");
        }

        // (2) configurable communication behaviour of FakeObject
        return m_retVal;
    }

    //-----  control methods called by the test case -----

    void SetRetVal (int in_retVal)
    {m_retVal = in_retVal;}

    void SetLogActivities (bool in_logActivities)
    {m_logActivitiesToTestEvents = in_logActivities;}

private:
    // configurable return value, visible to TestObject
    int m_retVal;

    // flag to activate/deactivate generation of TestEvents 
    bool m_logActivitiesToTestEvents;
};

Top2.1.3 Formulierung der Testf�lle (Test cases)

Ein Testfall besteht typischerweise aus einer oder mehrerer Teilsequenzen nach folgendem Muster:

Vorbereitung (Schritt 1 im Diagramm)
Vorbereitung der Testumgebung, Instrumentierung der Fake-Objects, damit das TestObject bei nachfolgender Anregung die ben�tigten Reaktionen erf�hrt
Anregung des Testobjektes (Schritt 2 im Diagramm)
Aufruf des Testobjects �ber regul�re Schnittstellen (Blackbox-Test) oder spezifische Testschnittstellen (Whitebox-Test).
- Das Testobjekt ruft seinerseits Kommunikationspartner innerhalb seiner Laufzeitumgebung (Schritt 3 im Diagramm)
- Handelt es sich dabei um Fakeobjects, so kann der Aufruf in der zentralen Komponente TestEvents aufgezeichnet werden (Schritt 4 im Diagramm)
Verifikation (Schritt 5 im Diagramm)
Pr�fung des aufgetretenen Kommunikationsverhaltens des Testobjects mit seiner Umgebung

Auszug aus einem Testcase:

// prepare environment
fakeObject2->SetRetVal(5);
fakeObject2->SetLogActivities(true)

// call test object
myTestObject->SomeInterfaceMethod();

// check whether the call has triggered the following reactions in the given order
TheTestEvents()->Expect("DoSomeService (called at FakeObject1)");
TheTestEvents()->Expect("DoSomeOtherService in=3 (called at FakeObject2)");

Top2.2 Multithreading, Synchronisation paralleler Abl�ufe

Existieren in der Laufzeitumgebung des Testobjektes parallele Abl�ufe (Multithreading), so kann die Reaktion des Testobjektes verz�gert werden. F�r den Test bedeutet das, dass bei R�ckkehr des Aufrufs einer Schnittstelle des Testobjekts, die Bearbeitung der Anfrage noch gar nicht abgeschlossen sein muss. Die asynchrone Reaktion verhindert somit eine unmittelbare �berpr�fung der erwarteten Reaktionen.

Top2.2.1 Naiver Ansatz: Warten mit Sleep

Ein erster Ansatz k�nnte darin bestehen, nach derartigen Aufrufen einfach eine vorgegebene Zeit abzuwarten und dann erst im Testscript mit den n�chsten Aktionen (z.B. Pr�fung der dann hoffentlich schon eingetretenen Reaktionen) fortzufahren. Abgesehen von sehr einfachen Anwendungsf�llen ergeben sich mit dieser Vorgehensweise h�ufig folgende Probleme:

unsichere Synchronisation
je nach Leistungsf�higkeit und sonstiger Auslastung des Rechners, auf dem der Test gerade ausgef�hrt wird, kann die erforderliche Wartezeit stark variieren. Bei starker Nebenlast (z.B. durch andere parallele Test/Compilier- Aktivit�ten) kann die Wartezeit zu niedrig sein. Das Testscript wird fortgesetzt bevor die gerade angestossene Aktivit�t vollst�ndig bearbeitet wurde. Der Test wird dadurch i.d.R. scheitern.
vervielfachte Ausf�hrungsdauer
Tests enthalten meist eine ganze Reihe von Testf�llen, sodass sich die Wartezeiten addieren. Verz�gerungen um den Faktor 10 bis 50 durch die eingef�hrten Wartezeiten sind dabei durchaus zu erwarten. H�ufig ist das f�r regelm��ig auszuf�hrende Tests (z.B. direkt im Anschlu� an die Compilierung) nicht mehr akzeptabel.

Top2.2.2 Gezielte Synchronisation

Die Reaktionen des Testobjektes bestehen sehr h�ufig darin, dass Kommunikationspartner aus der Laufzeitumgebung des Testobjektes angesprochen werden. Handelt es sich dabei um simulierte Fake-Objects, so k�nnen innerhalb dieser Objekte Synchronisationsmechanismen eingesetzt werden.

Grundlegendes Ziel dabei ist es, die ggf. verz�gerten Reaktionen des Testobjektes mit dem sequentiellen Ablauf der einzelnen Testinteraktionen im Testscript (test case) zu synchronisieren.

Schematische Darstellung:

Synchronisation paralleler Abl�ufe

Ein Beispiel f�r eine technische Umsetzung eines Synchronisationsmechanismus findet sich unter TestToolBox-Synchronizer.

Top2.2.3 Simulation der Fake-Objects

In Erweiterung der weiter oben aufgef�hrten Realisierungsbeispiele ist es meist ausreichend, lediglich einen Synchronisationsaufruf zu erg�nzen:

void FakeObject1::DoSomeService (void)
{
    // simply log info about call as a line of text
    TheTestEvents()->AddEvent("DoSomeService (called at FakeObject1)");

    // generate synchronisation event
    TheSynchronizer()->GenerateSync()");
}

Top2.2.4 Formulierung der Testf�lle (Test cases)

Ein Testfall besteht typischerweise aus einer oder mehrerer Teilsequenzen nach folgendem Muster:

Vorbereitung (Schritt 1 im Diagramm)
Im Testfall muss bekannt sein, wieviele Synchronisationsereignisse abgewartet werden m�ssen, bevor die Testsequenz fortgesetzt werden kann
Anregung des Testobjektes (Schritt 2 im Diagramm)
Aufruf des Testobjects �ber regul�re Schnittstellen (Blackbox-Test) oder spezifische Testschnittstellen (Whitebox-Test).
Synchronisiertes Warten (Schritt 3 im Diagramm)
Die Ausf�hrung des sequentiellen Testskriptes wird angehalten bis alle erwarteten asynchronen Ereignisse eingetreten sind.
Asynchrone Aktivit�ten des Testobjektes
- Das Testobjekt ruft seinerseits Kommunikationspartner innerhalb seiner Laufzeitumgebung (Schritt 4 im Diagramm)
- Handelt es sich dabei um Fakeobjects, so kann der Aufruf in der zentralen Komponente TestEvents aufgezeichnet werden. Zus�tzlich werden entsprechende Synchronisationsereignisse �ber die zentrale Komponente Synchronizer ausgel�st. (Schritt 5 im Diagramm)
Abschluss der Synchronisation und Verifikation (Fortsetzung Schritt 3 im Diagramm)
Nach Eintreffen aller erwarteten Synchronisationsereignisse erfolgt die Pr�fung des aufgetretenen Kommunikationsverhaltens des Testobjects mit seiner Umgebung.

Auszug aus einem Testcase:

// prepare synchronization
// here we have to wait for 2 asynchronous reactions
TheSynchronizer->Init(2);

// now call test object
myTestObject->SomeInterfaceMethod();

// wait until sync events have been received
TheSynchronizer()->WaitForSync();

// synchronization point is passed, now we can proceed
// with the test sequence

// check whether the call has triggered the following reactions in the given order
TheTestEvents()->Expect("DoSomeService (called at FakeObject1)");
TheTestEvents()->Expect("DoSomeOtherService in=3 (called at FakeObject2)");

Top3 Kontrollierte Testausf�hrung

Top3.1 Zeitbeschr�nkte Ausf�hrung (TimedExec)

Automatisierte SW-Tests werden typischerweise auch automatisiert gestartet und in �bergeordnete Abl�ufe eingebettet.

Beispiele:

Ausf�hrung und Auswertung einer Reihe von UnitTests zu allen Teilsystemen/Units eines SW-Systems
Einbettung in den Buildproze�
In gr��eren SW-Projekten wird f�r die Erzeugung des Gesamtproduktes aus den einzelnen Teilprodukten ein oft l�nger dauernder SW-Generierungsproze� ben�tigt. Um eine laufende Konsistenzpr�fung des aktuellen SW-Standes durchf�hren zu k�nnen und Entwickler und Tester mit "frischen" Ergebnissen versorgen zu k�nnen, werden regelm��ig automatische Gesamtbuilds durchgef�hrt (z.B. n�chtliche Generierung). Neben dem Produktivcode werden selbstverst�ndlich auch die zugeh�rigen Testumgebungen mit generiert. Nach dem reinen Compilieren/Linken macht es dabei durchaus Sinn auch gleich die Testausf�hrung in den Generierablauf mit einzubinden (Beispiel MS Visual Studio: Start der Testausf�hrung als Postbuild-Step, Verwendung des Testergebnisses als Returncode f�r den Buildproze�)

Top3.1.1 Womit zu rechnen ist: Tests schlagen fehl!

In einem lebendigen Projekt werden Tests h�ufig Laufzeitfehler zeigen:

Ge�nderte Interfaces
�nderungen an Interface-Methoden k�nnen dazu f�hren, dass nicht mehr die vorgesehenen Methoden der Fake-Objekte aufgerufen werden, sondern statt dessen die Dummy-Implementierungen, die nicht f�r einen tats�chlichen Aufruf gedacht sind (siehe Dummy-Implementierung von Interfaces).
Weiterentwicklung verwendeter Originalkomponenten
In den Test als Teil der Laufzeitumgebung eingebundene Originalkomponenten k�nnen im Zuge der Weiterentwicklung ihr Verhalten �ndern.
Weiterentwicklung Testobjekt
Die Implementierung des Testobjektes selbst kann sich �ndern und deshalb an zun�chst nicht vorhersehbarer Stelle zu ver�ndertem Verhalten im Testablauf f�hren

Diese "Fehlschl�ge" sind durchaus erw�nscht. Denn ein wesentliches Testziel ist das Erkennen von Ver�nderungen in der SW. Ein Test der vermeintlich robust gegen�ber SW-�nderungen ist, d.h. der nicht angepasst werden muss, wenn sich wesentliche Aspekte der Realisierung �ndern, hat mit gro�er Wahrscheinlichkeit auch den Nachteil, da� mit ihm auch unerw�nschte �nderungen nicht erkannt werden k�nnen.

Top3.1.2 M�glichst vermeiden: Blockade des Gesamtablaufes

Das Fehlverhalten eines Testes kann zu einer dauerhaften Blockade im Ablauf f�hren, in den der Test eingebettet ist:

Zu best�tigende Assert-Box
Absturz mit H�ngenbleiben des Testprozesses in einer System-Dialogbox
H�ngenbleiben in Endlosschleife
Deadlock aufgrund falscher Synchronisation

Es ist zwar w�nschenswert, dass das Fehlverhalten aufgedeckt wird. Wichtig ist es aber andererseits auch, dass die dem Test nachfolgenden Aktionen (z.B. Tests weiterer Systemkomponenten, Compilierung nachfolgender (Test-)Projekte) dadurch nicht behindert werden

Hinweis: Es gibt Testumgebungen, die beispielsweise Exceptions abfangen k�nnen und den Testablauf dann von der Ausnahme "unbeeindruckt" korrekt fortsetzen oder beenden k�nnen. In der Regel versagt diese Methode jedoch in komplexeren Systemen, in denen die Ausnahmen in unterschiedlichen Workerthreads auftreten k�nnen.

Top3.1.3 Ansteuerung des Assert- und Fehlerbox-Verhaltens

Default-Verhalten f�r Assert

Im Quellcode k�nnen beliebige logische Bedingungen als assert-Anweisung formuliert werden:

#include <assert.h>
...
assert(numEntries >= 5);
...
assert(!"Some condition is not fulfilled");

Ist die logische Bedingung nicht erf�llt, so wird im Falle einer Konsolenaplikation die Information �ber die fehlgeschlagene Bedingung mit Angabe zur betroffenen Code-Stelle nach stdout/stderr geschrieben. Zus�tzlich wird ein modaler Dialog angezeigt und der Programmablauf h�lt bis zur Best�tigung an:

assert message box

F�r Windowsapplikationen wird die gescheiterte Bedingung direkt in der Dialogbox angezeigt.

Default-Verhalten f�r typische fatale Fehler

Klassische Fehler wie z.B. Nullzeigerzugrifff oder Teilen durch 0 f�hren zum Programmabbruch und zur Anzeige entsprechender modaler Dialogboxen, die den weiteren Ablauf anhalten.

Zugriff auf Nullzeiger:

access violation message box

Teilen durch 0:

division by zero message box

Ver�ndern des Defaultverhaltens

Das Defaultverhalten zur Meldung und Anzeige der beschriebenen Fehler kann gezielt eingestellt werden. Zur Durchf�hrung von UnitTests erscheinen folgende Massnahmen sinnvoll:

Umleitung der Meldungen zu Warnungen, Fehlern und Asserts �ber _CrtSetReportMode sowohl in die Standardausgabe (_CRT_MODE_FILE mit _CRTDBG_FILE_STDOUT als gesetztem Reportfile) als auch in das Ausgabefenster eines laufenden Debuggers (_CRT_MODE_DEBUG). Weitere Details
Wird die Applikation zur Fehleranalyse im Debugger betrieben, so ist es sinnvoll, dass zum schnelleren Erkennen der gescheiterten Codestelle die Fehlerboxen aktiviert werden, d.h. der Reportmode _CRTDBG_MODE_WNDW sollte dann eingesclaltet werden. Zur automatischen Erkennnung, ob die Anwendung im Debugger betrieben wird, kann die Windows-Funktion IsDebuggerPresent() verwendet werden.
Es kann auch sinnvoll sein, das gew�nschte Verhalten �ber die Kommandozeile gezielt ein- und ausschalten zu k�nnen. Sind die Aufrufparameter nicht direkt �ber die Main-Funktion verf�gbar, so kann an beliebiger Stelle im Quellcode �ber die Windows-Funktion GetCommandLine() auf die Kommmandozeilen-Parameter zugegriffen werden. Weitere Details

Code-Beispiel

Die Syntax der Kommandozeilenparameter ist spezifisch f�r jede Applikation. Im nachfolgenden Beispiel wird angenommmen, dass IsCmdLineArgExisting() und GetCmdLineArg() als spezifische Funktionen vorhanden sind.

// Initially deactivate display of
// fatal error or assert message boxes
int displayErrorMsgBox = 0;

// First check command lline
if (IsCmdLineArgExisting("ShowFatalErrorMsgBox"))
{
    if (GetCmdLineArg("ShowFatalErrorMsgBox")=="YES")
    {
        displayErrorMsgBox = _CRTDBG_MODE_WNDW;
    }
}
else // not set via command liine
{
    if (IsDebuggerPresent())
    {
        displayErrorMsgBox = _CRTDBG_MODE_WNDW;
    }
}

// Send all reports to STDOUT and debugger output
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE|_CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE|_CRTDBG_MODE_DEBUG
				             | displayErrorMsgBox );
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE|_CRTDBG_MODE_DEBUG
				             | displayErrorMsgBox);
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT );

Fatale nicht abschaltbare Endemeldungen

Durch die oben aufgef�hrten Parametrierungen wird die Windows-Meldung zum fatalen Abbruch eines Programms nicht beeinflusst.

fatal termination message box

Der weitere Ablauf wird durch diese Meldung weiterhin blockiert. Um einen ungehinderten Ablauf f�r diesen Fall und auch f�r die weiter oben beschriebenen logischen "H�nger" zu gew�hrleisten, wird im nachfolgenden Abschnitt eine �bergeordneter L�sungsansatz vorgesteellt.

Top3.1.4 Einf�hrung einer zus�tzlichen Kontrollinstanz

Eine Testapplikation wird nicht direkt zur Ausf�hrung gebracht, sondern �ber einen zus�tzlichen Indirektionschritt einer einfachen �berwachungsinstanz zur Ausf�hrung �bergeben, der die maximal zul�ssige Ausf�hrungszeit mitgeteilt wird. Wird die konfigurierte Ausf�hrungszeit �berschritten, so wird der Testprozess von der �berwachungsinstanz abgebrochen und ein Fehlercode wird an den umgebenden Prozess zur�ckgegegen, der dann z.B. mit dem n�chsten Testprojekt fortsetzen kann.

Technische Realisierungsm�glichkeit: Einfache Konsolenapplikation, die �ber die Kommandozeile mit dem zu startenden Test-Executable und der erlaubten Ausf�hrungszeit versorgt wird. Details siehe TestToolBox-TimedExec.

Bei Bedarf lassen sich folgende zus�tzlichen Funktionalit�ten �ber die eingef�hrte �berwachungsinstanz l�sen:

Synchronisation konkurrierender Zugriffe durch Testapplikationen
Moderne Rechner und Buildsysteme �bersetzen stets mehrere Teilprojekte parallel. Damit k�nnen auch die in den Buildproze� eingebundenen Testapplikationen parallel gestartet werden. Greifen diese konkurrierend auf begrenzte exklusive Ressourcen zu (z.B. Portadressen), so kann �ber die �berwachungsinstanz auf einfache Weise eine Serialisierung der Testausf�hrung durchgef�hrt werden. Innerhalb der spezifischen Testumgebungen kann dann der exklusive Zugriff auf die Systemressourcen einfach vorausgesetzt werden.
Zentrale Erfassung der Testergebnisse
Die �berwachungsinstanz kennt alle gestarteten Testapplikationen und ihr Laufzeitverhalten (Returncode bzw. Notwendigkeit des gezielten Beendens nach H�ngenbleiben). Es ist somit ein leichtes daraus ein einfaches �bersichtsprotokoll zu den durchgef�hrten Testl�ufen zu erstellen.
Zentrales Ein/Ausschalten der Testausf�hrung
Je nach pers�nlichen Pr�ferenzen oder nach den Erfordernissen f�r die spezifische Generierumgebung kann �ber das Setzen einer Umgebungsvariablen das Starten der Tests abgeschaltet werden, ohne dass in irgendeinem Teilprojekt eine Ver�nderung vorgenommen werden mu�.

Schematische Darstellung (Einbettung in Buildprozess):

Sichere Ausf�hrung von Tests im Buildproze�

Top3.2 Wiederholte Ausf�hrung von Tests

Top3.2.1 Robustheit: Wiederholung beliebiger Testapplikationen

In der Praxis gibt es gelegentlich Situationen, in denen es zum sporadischen Fehlschlag eines ansonsten "meist" korrekt arbeitenden Testes kommt. H�ufig treten diese Probleme im Multithreaded-Umfeld auf und sind z.B. durch Prozessor-Nebenlasten oder durch unsichere Synchronisationsmechanismen im Testablauf bedingt.

Um die allgemeine Stabilit�t und Reproduzierbarkeit des Testablaufes zu untersuchen, ist es daher sinnvoll, eine Testanwendung einem Stresstest zu unterziehen und sie in einer Endlosschleife immer wieder auszuf�hren. Signalisiert die Testapplikation den Fehlschlag �ber einen entsprechenden Exitcode, so kann die Testausf�hrung im Fehlerfall gezielt angehalten werden. Auf diese Weise bleiben f�r die Fehleranalyse die letzten Logdateien und die Traceinformationen, die dem Fehler unmittelbar vorausgehen, erhalten.

Beispiel f�r ein einfaches CMD-Script zur Ansteuerung der Testausf�hrung:

@echo OFF
:: File: Repeat.cmd
:: Syntax: Repeat [targetDir] [exeFile] [cmdLineOptions]
::
:: Call unit test in an endless loop and stop execution when
:: the first error is detected

setlocal
set targetDir=C:\\MyTargetDir\\bin
set exeFile=MyTestApp.exe
set options=-formal
set counter=0
if \"%1\" NEQ \"\" set targetDir=%1
if \"%2\" NEQ \"\" set exeFile=%2
if \"%3\" NEQ \"\" set options=%3

echo.
echo Repeated execution of unit test (stop when first error is found)...
echo.
echo ------------------------------------------------------
echo Target directory : %targetDir%
echo Test executable  : %exeFile%
echo Cmdline options  : %options%
echo ------------------------------------------------------
echo.
goto EXEC_TEST

:: loop for repeated execution
:EXEC_TEST
set /a counter+=1
echo Executing iteration %counter%

%targetDir%\\TimedExec.exe 120  %targetDir%\\%exeFile% %options% >nul
@if errorlevel 1 GOTO STOP_TEST
GOTO EXEC_TEST

:: reaction in case of error
:STOP_TEST
echo.
echo Error detected! Test has stopped!
echo Check logfiles and / or trace output to analyze error situation!

endlocal

Es k�nnen auch mehrere Testapplikationen auf einmal gestartet werden:

@echo OFF
:: File: RepeatAll.cmd

set targetDir=D:\\MyTargetDir\\bin
if \"%1\" NEQ \"\" set targetDir=%1

::start several test applications
for %%X in (MyTestAppA.exe MyTestAppB.exe MyTestAppC.exe)
    do start cmd.exe /k Repeat.cmd %targetDir% %%X

Top3.2.2 Ressourcenverbrauch: Wiederholung �ber das Testrahmensystem

Testumgebungen besitzen in der Regel ein steuerndes Rahmensystem, �ber das die einzelnen Testf�lle ausgef�hrt werden. �ber den blo�en Aufruf der Testf�lle hinaus erscheinen folgende Ansteuerungsm�glichkeiten als sinnvoll:

Selektion der Testf�lle
Bei Bedarf Auswahl einer Teilmenge der Testf�lle, z.B. nach �nderungen um bestimmte Problemsituationen/Fehler gezielt nachzustellen, ohne durch die Ausf�hrungszeit nicht relevanter Testf�lle aufgehalten zu werden.
Auswahl der Reihenfolge
Je nach Organisation der Testf�lle kann die Einhaltung einer bestimmten Reihenfolge zwingend sein. Verfolgt man das Paradigma, dass die einzelnen Testf�lle unabh�ngig voneinander sind, so kann es sinnvoll sein zur Absicherung der Annahmen eine Zufallsreihenfolge zu erzeugen.
Dauertests
F�r Langzeituntersuchungen k�nnen die definierten Testf�lle �ber einen l�ngeren Zeitraum wiederholt ausgef�hrt werden.
- Test der allgemeinen Systemstabilit�t
  Insbesondere bei teilweise nicht deterministischem Verhalten (z.B. im Multithreading-Umfeld) kann es sinmvoll sein, die Testf�lle mehrfach auszuf�hren um die Entdeckungswahrscheinlichkeit f�r sporadisch auftretende Probleme zu erh�hen.
- Untersuchung des Ressourcenverbrauchs
  Eine Einbettung der Abfrage relevanter Performance-Daten in den Testablauf hat den Vorteil, dass zu stets gleichen Randbedingungen (z.B. nach Ausf�hrung des jeweils letzten Testfalls einer Iteration) der Ressourcenverbrauch bestimmt wird und eine Beeinflussung durch sporadische Schwankungen w�hrend der Testfallausf�hrung vermieden wird.

Schematische Darstellung:

ausf�hrendes System

Anmerkung zu Ressourcen-Leaks und Ressourcen-Verbrauch

Ein beliebtes Vorgehensmodell bei der Ausf�hrung von Testf�llen ist:

Um f�r verschiedene Testf�lle gleiche Anfangsbedingungen zu schaffen, wird einfach das zu testende System jeweils neu instanziiert.
Pr�fung auf Memory-Leaks bei Beendigung der Testapplikation
Ein einfacher Check wird bereits durch die C-Runtime-Bibliothek angeboten (_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF)). Im Fehlerfall werden Speicherleaks ohne weiteren Programmieraufwand z.B. in das Debugfenster geschrieben.

F�r den realen Betrieb gilt dagegen folgendes:

Von der Applikation nicht freigegebene Ressourcen werden i.d.R. automatisch vom Betriebssystem bei Prozessende wieder zur Verf�gung gestellt.
Applikationen sind typischerweise �ber einen l�ngeren Zeitraum in Betrieb. Das bedeutet, dass Funktionalit�ten auch wiederholt aufgerufen werden k�nnen, ohne dass die Applikation "frisch" gestartet wurde.
F�r einen geregelten Ressourcenverbrauch ist es daher auch wichtig, dass w�hrend des laufenden Betriebs nicht zuviele Ressourcen beansprucht werden.

Schlussfolgerungen f�r einen realistischen Dauertest

Es ist sinnvoll das Hochfahren und Herunterfahren des zu testenden Objektes von der Wiederholungsschleife �ber die Testf�lle zu trennen
Man muss unterscheiden zwischen einmaligen Initialisierungen und ggf. wiederholten Initialisierungen/Vorbereitungen f�r die einzelnen Testf�lle.

Ein Beispiel f�r eine technische Umsetzung eines Test-Ausf�hrungssystems, das die genannten Eigenschaften aufweist, findet sich unter TestToolBox-Runner.

Top3.3 Pr�fung auf Memory Leaks

Top3.3.1 Runtime Library zeigt Speicher-Lecks beim Programmende

Instrumentierungen im Quellcode

Durch einfache Instrumentierung der Runtime-Library werden Memory Leaks beim Beenden des Programms automatisch ausgegeben. Hierzu sind folgende Anweisungen notwendig.

Notwendiges Include:

#include <crtdbg.h>

Beim Hochfahren der Applikation (z.B. in main()) wird die Leakerkennung eingeschaltet und die Anzeige erkannter Leaks wird sowohl in den Standard-Output als auch in die verwendete Debug-Console umgelenkt:

// Send all reports to STDOUT and debugger output
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE |_CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT );

// Switch on detection of memory leaks
_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG));

Hinweis: Um das Aufblenden blockierender modaler Dialogboxen zur Anzeige fataler Fehler zu unterdr�cken siehe Codebeispiel.

Im Fehlerfall werden Leaks in folgendem Format angezeigt:

Detected memory leaks!
Dumping objects ->
{92} normal block at 0x00033478, 4 bytes long.
 Data: <    > CD CD CD CD 
Object dump complete.

Auffinden der zugeh�rigen Codestelle

Zu jedem Leak wird eine sogenannte Allokationsnummer angezeigt (im Beispiel "92"). Ist der Fehler reproduzierbar, d.h. wird bei mehreren Testl�ufen stets die gleiche Allokationsnummer ausgegeben, so bestehen gute Chancen, die Stelle im Quellcode aufzusp�ren, an der der Speicher angefordert wurde. Hierzu muss beim Hochfahren der Applikation f�r die entsprechende Allokation ein "Haltepunkt" gesetzt werden. Um dies m�glichst einfach f�r verschiedene Allokationsnummern ohne Neucompilierung durchf�hren zu k�nnen empfiehlt sich Code nach folgendem Muster:

int allocNum = 0; //< set specific value within debugger!
if (allocNum!=0)
{
    _CrtSetBreakAlloc(allocNum);
}

Einige Test-Frameworks unterst�tzen die beschriebenen Leistungsmerkmale und erlauben dar�berhinaus das Setzen eines Haltepunktes f�r eine bestimmte Allokationsnummer �ber die Kommandozeile (siehe Boost TestLib und TestToolBox-Runner).

Achtung: Debug-Version einsetzen!

Die beschriebenen Mechanismen der Runtime Library wirken nur in der Debug-Version. Bei Tests mit der Release-Version werden keine Memoryleaks angezeigt. Aus diesem Grunde sollte in jedem Falle auch die Debug-Version der Testapplikation generiert und getestet werden.

Top3.3.2 Automatische Erkennung der Leak-Situation

Die im vorhergehenden Abschnitt beschriebene Ausgabe von Memoryleaks nach Programmende hat einen Nachteil: Leaks werden erst nach Beendigung des Programms festgestellt und k�nnen somit nicht mehr zur Festlegung des Exitcodes des Programmes verwendet werden. Testapplikationen, die funktional alle Testf�lle erf�llen, aber Teile des Speichers nicht mehr freigeben, werden deshalb typischerweise einen Exit-Code von 0 zur�ckgeben. Leaks werden also nur erkannt, wenn ein Tester "anwesend" ist, der den Testoutput begutachtet und gezielt nach entsprechenden Hinweisen auf Memoryleaks sucht.

Um automatisierte Testl�ufe in die Lage zu versetzen, auch derartige Leaks sicher erkennen zu k�nnen, wird ein zus�tzlicher Indirektionsschritt eingef�hrt, der die "Inspektion" des Programm-Outputs automatisiert ausf�hrt. Im einzelnen werden dazu folgende Schritte durchgef�hrt:

die Testapplikation wird nicht direkt, sondern �ber eine steuernde Applikation gestartet
die steuernde Applikation lenkt alle Ausgaben der Testapplikation, die normalerweise nach stdout und stderr gehen in eine Datei um
nach Beendigung der Testapplikation pr�ft die steuernde Applikation den "aufgefangenen" Output und pr�ft ihn auf das Vorhandensein des Textes "Detected memory leaks!"
wird dieser Text gefunden, so kann der ExitCode gezielt gesetzt werden, um einen Fehler zu signalisieren

Code-Snippets

Anlegen des Textfiles, das den Output der Testapplikation aufnehmen soll:

std::string nameApplicationOutputFile = GetFullPathOfTestApplication()
    + ".AppOut.txt";

SECURITY_ATTRIBUTES security;
security.bInheritHandle=true;
security.lpSecurityDescriptor=NULL;
security.nLength = sizeof(SECURITY_ATTRIBUTES);

HANDLE hApplicationOutputFile = CreateFile(
    nameApplicationOutputFile.c_str(),
    GENERIC_WRITE, 
    FILE_SHARE_WRITE, 
    &security, 
    CREATE_ALWAYS, 
    FILE_ATTRIBUTE_NORMAL, 
    0);

Starten der Testapplikation mit Umlenken von StdOut und StdErr:

// Definition of startinfo struct
STARTUPINFO startInfo;
startInfo. cb              = sizeof (STARTUPINFO);
startInfo. lpReserved      = 0;
startInfo. lpDesktop       = 0;
startInfo. lpTitle         = 0;
startInfo. dwX             = 0;
startInfo. dwY             = 0;
startInfo. dwXSize         = 0;
startInfo. dwYSize         = 0;
startInfo. dwXCountChars   = 0;
startInfo. dwYCountChars   = 0;
startInfo. dwFillAttribute = 0;
startInfo. dwFlags         = STARTF_USESTDHANDLES | otherFlags;
startInfo. wShowWindow     = SW_SHOW;
startInfo. cbReserved2     = 0;
startInfo. lpReserved2     = 0;
startInfo. lpReserved      = 0;
startInfo. hStdInput       = 0;
startInfo. hStdOutput      = hApplicationOutputFile;
startInfo. hStdError       = hApplicationOutputFile;

std::string appPathWithArgs = m_GetFullPathOfTestApplication() + GetStartArgs();

CreateProcess (
    NULL,
    LPTSTR (appPathWithArgs. c_str()),
    NULL,
    NULL,
    TRUE, // handles are inherited
    0,
    NULL,
    NULL,
    &startInfo,
    &m_procInfo);

Nach Beendigung der Testapplikation werden die aufgezeichneten Ausgaben �berpr�ft:

std::fstream outFile; // file with captured stdout and stderr of test app
outFile.open(nameApplicationOutputFile.c_str());
std::string line;
while( std::getline( outFile, line ) )
{
    // write captured output of test application to std out
    std::cout << line << std::endl;

    if (line.find("Detected memory leaks") !=string::npos)
    {
        exitCode = 1; // generate error
        std::cout << "****** MEM LEAK FOUND!!! ****" << std::endl;
    }
}
outFile.close();

Ein Beispiel f�r eine technische Realisierung einer steuernden Applikation findet sich in TestToolBox-TimedExec. Weitere Aufgaben einer derartigen steuernden Applikation sind in Abschnitt "Zeitbeschr�nkte Ausf�hrung (TimedExec)" beschrieben.