Qt Test Übersicht

Qt Test ist ein Framework für Unit-Tests von Qt-basierten Anwendungen und Bibliotheken. Qt Test bietet alle Funktionen, die in Unit-Test-Frameworks üblich sind, sowie Erweiterungen für das Testen von grafischen Benutzeroberflächen.

Qt Test wurde entwickelt, um das Schreiben von Unit-Tests für Qt-basierte Anwendungen und Bibliotheken zu erleichtern:

Sie können einen Qt Creator Assistenten verwenden, um ein Projekt zu erstellen, das Qt Tests enthält, und diese direkt von Qt Creator aus erstellen und ausführen. Weitere Informationen finden Sie unter Qt Creator: Tests erstellen und ausführen.

Einen Test erstellen

Um einen Test zu erstellen, untergliedern Sie die Klasse QObject und fügen Sie ihr einen oder mehrere private Slots hinzu. Jeder private Slot ist eine Testfunktion in Ihrem Test. QTest::qExec() kann verwendet werden, um alle Testfunktionen im Testobjekt auszuführen.

Darüber hinaus können Sie die folgenden privaten Slots definieren, die nicht als Testfunktionen behandelt werden. Wenn sie vorhanden sind, werden sie vom Testframework ausgeführt und können zur Initialisierung und Bereinigung entweder des gesamten Tests oder der aktuellen Testfunktion verwendet werden.

• initTestCase() wird aufgerufen, bevor die erste Testfunktion ausgeführt wird.
• initTestCase_data() wird aufgerufen, um eine globale Testdatentabelle zu erstellen.
• cleanupTestCase() wird aufgerufen, nachdem die letzte Testfunktion ausgeführt wurde.
• init() wird vor der Ausführung jeder Testfunktion aufgerufen.
• cleanup() wird nach jeder Testfunktion aufgerufen.

Verwenden Sie initTestCase(), um den Test vorzubereiten. Jeder Test sollte das System in einem brauchbaren Zustand zurücklassen, so dass er wiederholt ausgeführt werden kann. Aufräumarbeiten sollten in cleanupTestCase() behandelt werden, damit sie auch dann ausgeführt werden, wenn der Test fehlschlägt.

Verwenden Sie init() für die Vorbereitung einer Testfunktion. Jede Testfunktion sollte das System in einem brauchbaren Zustand hinterlassen, so dass sie wiederholt ausgeführt werden kann. Aufräumarbeiten sollten in cleanup() behandelt werden, damit sie auch dann ausgeführt werden, wenn die Testfunktion fehlschlägt und vorzeitig beendet wird.

Alternativ können Sie RAII (Resource Acquisition is Initialization) verwenden, wobei die Aufräumarbeiten in Destruktoren aufgerufen werden, um sicherzustellen, dass sie ausgeführt werden, wenn die Testfunktion zurückkehrt und das Objekt den Gültigkeitsbereich verlässt.

Wenn initTestCase() fehlschlägt, wird keine Testfunktion ausgeführt. Wenn init() fehlschlägt, wird die folgende Testfunktion nicht ausgeführt, sondern der Test wird mit der nächsten Testfunktion fortgesetzt.

Beispiel:

class MyFirstTest: public QObject
{ Q_OBJECTprivate: bool myCondition() { return true; }private slots: void initTestCase()    {
        qDebug("Called before everything else.");
    } void myFirstTest() { QVERIFY(true); // prüfen, ob eine Bedingung erfüllt istQCOMPARE(1, 1); // zwei Werte vergleichen} void mySecondTest() { QVERIFY(myCondition()); QVERIFY(1 != 2); } void cleanupTestCase()    {
        qDebug("Called after myFirstTest and mySecondTest.");
    } };

Wenn die Testklasse eine statische öffentliche Methode void initMain() hat, wird diese von den Makros QTEST_MAIN aufgerufen, bevor das Objekt QApplication instanziiert wird. Dies wurde in 5.14 hinzugefügt.

Weitere Beispiele finden Sie im Qt Test Tutorial.

Erhöhen der Zeitüberschreitung für Testfunktionen

QtTest begrenzt die Laufzeit der einzelnen Tests, um Endlosschleifen und ähnliche Fehler zu erkennen. Standardmäßig wird jeder Aufruf einer Testfunktion nach fünf Minuten unterbrochen. Bei datengesteuerten Tests gilt dies für jeden Aufruf mit einem bestimmten Daten-Tag. Diese Zeitüberschreitung kann konfiguriert werden, indem die Umgebungsvariable QTEST_FUNCTION_TIMEOUT auf die maximale Anzahl von Millisekunden gesetzt wird, die für einen einzelnen Aufruf akzeptabel ist. Wenn ein Test länger als die konfigurierte Zeitspanne dauert, wird er unterbrochen und qFatal() aufgerufen. Infolgedessen bricht der Test standardmäßig ab, als ob er abgestürzt wäre.

Um QTEST_FUNCTION_TIMEOUT über die Befehlszeile unter Linux oder macOS einzustellen, geben Sie ein:

QTEST_FUNCTION_TIMEOUT=900000
export QTEST_FUNCTION_TIMEOUT

Unter Windows:

SET QTEST_FUNCTION_TIMEOUT=900000

Führen Sie dann den Test in dieser Umgebung aus.

Alternativ können Sie die Umgebungsvariable auch programmatisch im Testcode selbst setzen, zum Beispiel durch den Aufruf der speziellen Methode initMain() Ihrer Testklasse:

qputenv("QTEST_FUNCTION_TIMEOUT", "900000");

Um einen geeigneten Wert für die Zeitüberschreitung zu berechnen, sehen Sie sich an, wie lange der Test normalerweise dauert, und entscheiden Sie, wie viel länger er dauern kann, ohne dass dies ein Symptom für ein Problem ist. Rechnen Sie diese längere Zeit in Millisekunden um, um den Timeout-Wert zu erhalten. Wenn Sie z. B. feststellen, dass ein Test, der mehrere Minuten dauert, auf einem langsamen Rechner bis zu zwanzig Minuten dauern kann, multiplizieren Sie 20 * 60 * 1000 = 1200000 und setzen Sie die Umgebungsvariable auf 1200000 statt auf den obigen Wert 900000.

Einen Test erstellen

Sie können eine ausführbare Datei erstellen, die eine Testklasse enthält, die typischerweise eine Klasse des Produktionscodes testet. Normalerweise möchten Sie jedoch mehrere Klassen in einem Projekt mit einem einzigen Befehl testen.

Eine schrittweise Erklärung finden Sie unter Schreiben eines Unit-Tests.

Bauen mit CMake und CTest

Zum Erstellen eines Tests können Sie CMake und CTest verwenden. Mit CTest können Sie Tests auf der Grundlage eines regulären Ausdrucks, der mit dem Testnamen abgeglichen wird, ein- oder ausschließen. Außerdem können Sie die Eigenschaft LABELS auf einen Test anwenden, und CTest kann dann Tests auf der Grundlage dieser Labels ein- oder ausschließen. Alle gekennzeichneten Ziele werden ausgeführt, wenn test target in der Befehlszeile aufgerufen wird.

CMake bietet noch einige andere Vorteile. Zum Beispiel kann das Ergebnis eines Testlaufs mit CDash praktisch ohne Aufwand auf einem Webserver veröffentlicht werden.

CTest skaliert auf sehr unterschiedliche Unit-Test-Frameworks und funktioniert mit QTest.

Nachfolgend ein Beispiel für eine CMakeLists.txt-Datei, die den Projektnamen und die verwendete Sprache (hier mytest und C++), die für die Erstellung des Tests erforderlichen Qt-Module (Qt5Test) und die im Test enthaltenen Dateien(tst_mytest.cpp) angibt.

project(mytest LANGUAGES CXX)

find_package(Qt6 REQUIRED COMPONENTS Test)

set(CMAKE_INCLUDE_CURRENT_DIR ON)

set(CMAKE_AUTOMOC ON)

enable_testing(true)

qt_add_executable(mytest tst_mytest.cpp)
add_test(NAME mytest COMMAND mytest)

target_link_libraries(mytest PRIVATE Qt::Test)

Weitere Informationen zu den Optionen, die Sie haben, finden Sie unter Erstellen mit CMake.

Bauen mit qmake

Wenn Sie qmake als Build-Tool verwenden, fügen Sie einfach das Folgende zu Ihrer Projektdatei hinzu:

QT += testlib

Wenn Sie den Test über make check ausführen möchten, fügen Sie die zusätzliche Zeile hinzu:

CONFIG += testcase

Um zu verhindern, dass der Test auf Ihrem Ziel installiert wird, fügen Sie die zusätzliche Zeile ein:

CONFIG += no_testcase_installs

Siehe das qmake-Handbuch für weitere Informationen über make check.

Bauen mit anderen Werkzeugen

Wenn Sie andere Build-Tools verwenden, stellen Sie sicher, dass Sie den Ort der Qt Test Header-Dateien zu Ihrem Include-Pfad hinzufügen (normalerweise include/QtTest unter Ihrem Qt-Installationsverzeichnis). Wenn Sie ein Release-Build von Qt verwenden, verlinken Sie Ihren Test mit der QtTest Bibliothek. Für Debug-Builds verwenden Sie QtTest_debug.

Qt Test Kommandozeilen-Argumente

Syntax

Die Syntax zur Ausführung eines Autotests hat die folgende einfache Form:

testname [options] [testfunctions[:testdata]]...

Ersetzen Sie testname durch den Namen Ihrer ausführbaren Datei. testfunctions kann Namen von Testfunktionen enthalten, die ausgeführt werden sollen. Wenn keine testfunctions übergeben wird, werden alle Tests ausgeführt. Wenn Sie den Namen eines Eintrags in testdata anhängen, wird die Testfunktion nur mit diesen Testdaten ausgeführt.

Zum Beispiel:

/myTestDirectory$ testQString toUpper

Führt die Testfunktion mit dem Namen toUpper mit allen verfügbaren Testdaten aus.

/myTestDirectory$ testQString toUpper toInt:zero

Führt die Testfunktion toUpper mit allen verfügbaren Testdaten und die Testfunktion toInt mit der Testdatenzeile zero aus (wenn die angegebenen Testdaten nicht vorhanden sind, schlägt der zugehörige Test fehl und die verfügbaren Daten-Tags werden gemeldet).

/myTestDirectory$ testMyWidget -vs -eventdelay 500

Führt den Funktionstest testMyWidget aus, gibt jede Signalausgabe aus und wartet 500 Millisekunden nach jedem simulierten Maus-/Tastaturereignis.

Optionen

Optionen für die Protokollierung

Die folgenden Befehlszeilenoptionen bestimmen, wie die Testergebnisse protokolliert werden:

• -o Dateiname,Format
  Writes output to the specified file, in the specified format (one of txt, csv, junitxml, xml, lightxml, teamcity or tap). Use the special filename - (hyphen) to log to standard output.
• -o Dateiname
  Schreibt die Ausgabe in die angegebene Datei.
• -txt
  Gibt die Ergebnisse als reinen Text aus.
• -csv
  Gibt die Ergebnisse als kommagetrennte Werte (CSV) aus, die sich für den Import in Tabellenkalkulationen eignen. Dieser Modus ist nur für Benchmarks geeignet, da er normale Pass/Fail-Meldungen unterdrückt.
• -junitxml
  Gibt die Ergebnisse als JUnit-XML-Dokument aus.
• -xml
  Gibt die Ergebnisse als XML-Dokument aus.
• -lightxml
  Gibt die Ergebnisse als Strom von XML-Tags aus.
• -teamcity
  Gibt die Ergebnisse im TeamCity-Format aus.
• -tap
  Gibt die Ergebnisse im Test Anything Protocol (TAP)-Format aus.

Die erste Version der Option -o kann wiederholt werden, um Testergebnisse in mehreren Formaten zu protokollieren, aber es kann nicht mehr als eine Instanz dieser Option Testergebnisse auf der Standardausgabe protokollieren.

Wenn die erste Version der Option -o verwendet wird, sollten weder die zweite Version der Option -o noch die Optionen -txt, -xml, -lightxml, -teamcity, -junitxml oder -tap verwendet werden.

Wenn keine der beiden Versionen der Option -o verwendet wird, werden die Testergebnisse auf der Standardausgabe protokolliert. Wenn keine Formatoption verwendet wird, werden die Testergebnisse im Klartext protokolliert.

Optionen für Testprotokolldetails

Die folgenden Befehlszeilenoptionen steuern, wie viele Details in den Testprotokollen angezeigt werden:

• -silent
  
• Stille Ausgabe; zeigt nur schwerwiegende Fehler, Testabbrüche und minimale Statusmeldungen an.
• -v1
  Ausführliche Ausgabe; zeigt an, wann jede Testfunktion eingegeben wird. (Diese Option wirkt sich nur auf die reine Textausgabe aus.)
• -v2
  Extended verbose output; shows each QCOMPARE() and QVERIFY(). (This option affects all output formats and implies -v1 for plain text output.)
• -vs
  Zeigt alle Signale, die ausgegeben werden, und die aus diesen Signalen resultierenden Slot-Aufrufe. (Diese Option betrifft alle Ausgabeformate.)

Test-Optionen

Die folgenden Befehlszeilenoptionen beeinflussen die Ausführung von Tests:

• -functions
  
• Gibt alle im Test verfügbaren Testfunktionen aus und bricht dann ab.
• -datatags
  Gibt alle im Test verfügbaren Daten-Tags aus. Einem globalen Daten-Tag wird ' __global__ ' vorangestellt.
• -eventdelay ms
  If no delay is specified for keyboard or mouse simulation (QTest::keyClick(), QTest::mouseClick() etc.), the value from this parameter (in milliseconds) is substituted.
• -keydelay ms
  Wie -eventdelay, beeinflusst aber nur die Tastatursimulation und nicht die Maussimulation.
• -mousedelay ms
  Wie -eventdelay, beeinflusst aber nur die Maussimulation und nicht die Tastatursimulation.
• -maxwarnings number
  Legt die maximale Anzahl der auszugebenden Warnungen fest. 0 für unbegrenzt, Standardwert ist 2000.
• -nocrashhandler
  Deaktiviert den Crash-Handler auf Unix-Plattformen. Unter Windows wird der Windows-Fehlerberichtsdialog wieder aktiviert, der standardmäßig ausgeschaltet ist. Dies ist nützlich für die Fehlersuche bei Abstürzen.
• -repeat n
  Führen Sie die Testsuite n-mal aus oder bis der Test fehlschlägt. Nützlich, um fehlerhafte Tests zu finden. Bei einem negativen Ergebnis werden die Tests für immer wiederholt. Dies ist als Entwicklerwerkzeug gedacht und wird nur mit dem Klartext-Logger unterstützt.
• -skipblacklisted
  Überspringen Sie die Tests auf der schwarzen Liste. Diese Option soll eine genauere Messung der Testabdeckung ermöglichen, indem verhindert wird, dass Tests auf der schwarzen Liste die Abdeckungsstatistik aufblähen. Wenn die Testabdeckung nicht gemessen wird, ist es empfehlenswert, Tests auf der schwarzen Liste auszuführen, um Änderungen in den Ergebnissen zu erkennen, z. B. einen neuen Absturz oder die Behebung des Problems, das die schwarze Liste verursacht hat.
• -platform name
  This command line argument applies to all Qt applications, but might be especially useful in the context of auto-testing. By using the "offscreen" platform plugin (-platform offscreen) it's possible to have tests that use QWidget or QWindow run without showing anything on the screen. Currently the offscreen platform plugin is only fully supported on X11.

Benchmarking-Optionen

Die folgenden Befehlszeilenoptionen steuern die Benchmark-Tests:

• -callgrind
  Verwendet Callgrind zur Zeitmessung von Benchmarks (nur Linux).
• -tickcounter
  Verwendet CPU-Tick-Counter zur Zeitmessung von Benchmarks.
• -eventcounter
  Zählt Ereignisse, die während Benchmarks empfangen werden.
• -minimumvalue n
  Legt den minimalen akzeptablen Messwert fest.
• -minimumtotal n
  Legt die minimale akzeptable Gesamtzahl für wiederholte Ausführungen einer Testfunktion fest.
• -iterations n
  Legt die Anzahl der Akkumulationsiterationen fest.
• -median n
  Legt die Anzahl der Median-Iterationen fest.
• -vb
  Gibt ausführliche Benchmarking-Informationen aus.

Verschiedene Optionen

• -help
  Gibt die möglichen Kommandozeilenargumente aus und gibt einige nützliche Hilfestellungen.

Qt Test Umgebungsvariablen

Sie können bestimmte Umgebungsvariablen setzen, um die Ausführung eines Autotests zu beeinflussen:

• QTEST_DISABLE_CORE_DUMP
  
• Wenn Sie diese Variable auf einen Wert ungleich Null setzen, wird die Erzeugung einer Core-Dump-Datei deaktiviert.
• QTEST_DISABLE_STACK_DUMP
  Wenn Sie diese Variable auf einen Wert ungleich Null setzen, verhindert Qt Test die Ausgabe eines Stacktraces, falls ein Autotest eine Zeitüberschreitung aufweist oder abstürzt.
• QTEST_FATAL_FAIL
  Wenn Sie diese Variable auf einen Wert ungleich Null setzen, führt ein Fehler in einem Autotest zum sofortigen Abbruch des gesamten Autotests. Dies ist nützlich, um z.B. einen instabilen oder intermittierenden Fehler in einem Test zu debuggen, indem der Test in einem Debugger gestartet wird. Unterstützung für diese Variable wurde in Qt 6.1 hinzugefügt.
• QTEST_THROW_ON_FAIL (seit 6.8)
  Setting this variable to a non-zero value will cause QCOMPARE()/QVERIFY() etc to throw on failure (as opposed to just returning from the immediately-surrounding function scope).
• QTEST_THROW_ON_SKIP (seit 6.8)
  Same as QTEST_THROW_ON_FAIL, except affecting QSKIP().

Erstellen einer Benchmark

Um einen Benchmark zu erstellen, befolgen Sie die Anweisungen zum Erstellen eines Tests und fügen dann ein QBENCHMARK Makro oder QTest::setBenchmarkResult() zu der Testfunktion hinzu, die Sie mit einem Benchmark vergleichen möchten. Im folgenden Codeschnipsel wird das Makro verwendet:

class MyFirstBenchmark: public QObject
{
    Q_OBJECT
private slots:
    void myFirstBenchmark()
    {
        QString string1;
        QString string2;
        QBENCHMARK {
            string1.localeAwareCompare(string2);
        }
    }
};

Eine Testfunktion, die die Leistung misst, sollte entweder ein einziges QBENCHMARK Makro oder einen einzigen Aufruf von setBenchmarkResult() enthalten. Ein mehrfaches Auftreten ist nicht sinnvoll, da nur ein Leistungsergebnis pro Testfunktion oder pro Daten-Tag in einem datengesteuerten Setup gemeldet werden kann.

Vermeiden Sie es, den Testcode zu ändern, der den Körper eines QBENCHMARK Makros bildet (oder beeinflusst), oder den Testcode, der den an setBenchmarkResult() übergebenen Wert berechnet. Unterschiede in den aufeinanderfolgenden Leistungsergebnissen sollten idealerweise nur durch Änderungen an dem Produkt, das Sie testen, verursacht werden. Änderungen am Testcode können möglicherweise zu irreführenden Berichten über eine Leistungsänderung führen. Wenn Sie den Testcode ändern müssen, machen Sie dies in der Commit-Nachricht deutlich.

In einer Leistungstestfunktion sollte auf QBENCHMARK oder setBenchmarkResult() ein Verifizierungsschritt mit QCOMPARE(), QVERIFY() usw. folgen. Sie können dann ein Leistungsergebnis als ungültig kennzeichnen, wenn ein anderer Codepfad als der beabsichtigte gemessen wurde. Ein Leistungsanalysewerkzeug kann diese Informationen verwenden, um ungültige Ergebnisse herauszufiltern. Beispielsweise führt eine unerwartete Fehlerbedingung in der Regel dazu, dass das Programm vorzeitig aus der normalen Programmausführung aussteigt und somit fälschlicherweise eine dramatische Leistungssteigerung anzeigt.

Auswählen des Mess-Backends

Der Code innerhalb des QBENCHMARK-Makros wird gemessen und möglicherweise auch mehrmals wiederholt, um eine genaue Messung zu erhalten. Dies hängt von dem gewählten Mess-Backend ab. Es sind mehrere Back-Ends verfügbar. Sie können in der Befehlszeile ausgewählt werden:

Kurz gesagt, Walltime ist immer verfügbar, erfordert aber viele Wiederholungen, um ein brauchbares Ergebnis zu erhalten. Tick-Counter sind in der Regel verfügbar und können Ergebnisse mit weniger Wiederholungen liefern, sind aber anfällig für Skalierungsprobleme der CPU-Frequenz. Valgrind liefert genaue Ergebnisse, berücksichtigt aber keine E/A-Wartezeiten und ist nur auf einer begrenzten Anzahl von Plattformen verfügbar. Die Ereigniszählung ist auf allen Plattformen verfügbar und liefert die Anzahl der Ereignisse, die von der Ereignisschleife empfangen wurden, bevor sie an die entsprechenden Ziele gesendet werden (dies kann auch Nicht-Qt-Ereignisse umfassen).

Die Linux-Performance-Monitoring-Lösung ist nur unter Linux verfügbar und bietet viele verschiedene Zähler, die durch Übergabe einer zusätzlichen Option -perfcounter countername ausgewählt werden können, z. B. -perfcounter cache-misses, -perfcounter branch-misses oder -perfcounter l1d-load-misses. Der Standardzähler ist cpu-cycles. Die vollständige Liste der Zähler erhalten Sie, wenn Sie ein beliebiges Benchmark-Programm mit der Option -perfcounterlist ausführen.

• Die Verwendung des Leistungszählers erfordert möglicherweise die Freigabe des Zugriffs für nicht privilegierte Anwendungen.
• Bei Geräten, die keine hochauflösenden Zeitgeber unterstützen, wird standardmäßig eine Granularität von einer Millisekunde verwendet.

Siehe Schreiben eines Benchmarks im Qt Test Tutorial für weitere Benchmarking-Beispiele.

Globale Testdaten verwenden

Sie können initTestCase_data() definieren, um eine globale Testdatentabelle einzurichten. Jeder Test wird einmal für jede Zeile in der globalen Testdatentabelle ausgeführt. Wenn die Testfunktion selbst datengesteuert ist, wird sie für jede lokale Datenzeile und für jede globale Datenzeile ausgeführt. Wenn es also g Zeilen in der globalen Datentabelle und d Zeilen in der eigenen Datentabelle des Tests gibt, ist die Anzahl der Durchläufe dieses Tests g mal d.

Die globalen Daten werden mit dem Makro QFETCH_GLOBAL() aus der Tabelle geholt.

Im Folgenden werden typische Anwendungsfälle für globale Testdaten beschrieben:

• Auswahl unter den verfügbaren Datenbank-Backends in QSql-Tests, um jeden Test gegen jede Datenbank durchzuführen.
• Durchführen aller Netzwerktests mit und ohne SSL (HTTP versus HTTPS) und Proxying.
• Testen eines Timers mit einer hochgenauen Uhr und mit einer groben Uhr.
• Auswahl, ob ein Parser von einer QByteArray oder von einer QIODevice lesen soll.

Zum Beispiel, um jede von roundTripInt_data() bereitgestellte Zahl mit jeder von initTestCase_data() bereitgestellten Locale zu testen:

void TestQLocale::roundTripInt()
{
    QFETCH_GLOBAL(QLocale, locale);
    QFETCH(int, number);
    bool ok;
    QCOMPARE(locale.toInt(locale.toString(number), &ok), number);
    QVERIFY(ok);
}

In der Befehlszeile eines Tests können Sie den Namen einer Funktion (ohne den Präfix test-class-name) angeben, um nur die Tests dieser Funktion auszuführen. Wenn die Testklasse über globale Daten verfügt oder die Funktion datengesteuert ist, können Sie ein Daten-Tag nach einem Doppelpunkt anhängen, um nur den Datensatz dieses Tags für die Funktion auszuführen. Um sowohl ein globales Tag als auch ein für die Testfunktion spezifisches Tag anzugeben, kombinieren Sie beide mit einem Doppelpunkt dazwischen, wobei das globale Daten-Tag an erster Stelle steht. Zum Beispiel

./testqlocale roundTripInt:zero

führt den zero Testfall des obigen roundTripInt() Tests (unter der Annahme, dass seine TestQLocale Klasse zu einer ausführbaren testqlocale kompiliert wurde) in jeder der durch initTestCase_data() angegebenen Sprachumgebungen aus, während

./testqlocale roundTripInt:C

alle drei Testfälle von roundTripInt() nur in der C-Sprachumgebung ausführt und

./testqlocale roundTripInt:C:zero

führt nur den Testfall zero in der Sprachumgebung C aus.

Eine solch fein abgestufte Kontrolle darüber, welche Tests ausgeführt werden sollen, kann die Fehlersuche erheblich erleichtern, da Sie nur den einen Testfall durchgehen müssen, bei dem ein Fehler aufgetreten ist.