Wie testen Sie Programme, die komplexe Eingabedaten erfordern?

Question

Wir haben eine Reihe von Konvertern, die komplexe Daten verarbeiten und transformieren. Meistens ist die Eingabe EDI und die Ausgabe XML oder umgekehrt, obwohl es andere Formate gibt.

Es gibt viele Abhängigkeiten in den Daten. Was Methoden oder Software sind verfügbar, die komplexe Eingabedaten wie diese generieren können?

Im Moment verwenden wir zwei Methoden: (1) eine Reihe von Beispieldateien, die wir im Laufe der Jahre hauptsächlich aus Dateien Bugs und Samples in der Dokumentation erstellt haben, und (2) Pseudozufalls-Testdaten generieren. Aber ersteres deckt nur einen Bruchteil der Fälle ab, und letzteres hat viele Kompromisse und testet nur eine Teilmenge der Felder.

Bevor Sie den Pfad der Implementierung (neu erfinden?) Eines komplexen tabellengesteuerten Datengenerators weitergehen, welche Optionen haben Sie erfolgreich gefunden?

Answer 1

Nun, die Antwort ist in Ihrer Frage. Sofern Sie nicht einen komplexen tabellengesteuerten Datengenerator implementieren, machen Sie die Dinge richtig mit (1) und (2).

(1) umfasst die Regel "1 Bug verifiziert, 1 neuer Testfall". Und wenn die Struktur der pseudozufälligen Testdaten von (2) in realen Situationen überhaupt entspricht, ist es in Ordnung.

(2) kann immer verbessert werden, und es wird sich hauptsächlich im Laufe der Zeit verbessern, wenn man über neue Randfälle nachdenkt. Das Problem mit zufälligen Daten für Tests ist, dass es nur zufällig bis zu einem Punkt sein kann, wo es so schwierig wird, die erwartete Ausgabe aus den Zufallsdaten im Testfall zu berechnen, dass Sie den getesteten Algorithmus im Testfall grundlegend neu schreiben müssen.

So (2) wird immer einen Bruchteil der Fälle übereinstimmen. Wenn eines Tages alle Fälle übereinstimmen, ist es in der Tat eine neue Version Ihres Algorithmus.

Answer 2

1. ich gegen die Verwendung von Zufallsdaten raten würde, da es es schwierig, wenn nicht unmöglich machen, den Fehler zu reproduzieren, die berichtet wird (ich weiß, du sagst ‚Pseudo-Random‘, nur nicht sicher, was Sie von dieser genau bedeuten).

2. Das Arbeiten über ganze Dateien von Daten würde wahrscheinlich funktionelle oder Integrationstests in Betracht ziehen. Ich würde vorschlagen, dass Sie Ihre Datei mit bekannten Fehlern übernehmen und diese in Unit-Tests übersetzen, oder zumindest für zukünftige Fehler, auf die Sie stoßen. Dann können Sie diese Komponententests auch so erweitern, dass sie auch die anderen fehlerhaften Bedingungen abdecken, für die Sie keine "Beispieldaten" haben. Dies wird wahrscheinlich einfacher sein, wenn Sie jedes Mal eine neue Datendatei erstellen, wenn Sie an eine Bedingung/Regelverletzung denken, nach der Sie suchen möchten.

3. Stellen Sie sicher, dass Ihre Analyse des Datenformats von der Interpretation der Daten im Format gekapselt ist. Dadurch wird das Testen der Einheiten, wie oben beschrieben, viel einfacher.

4. Wenn Sie Ihre Tests unbedingt durchführen müssen, sollten Sie eine maschinenlesbare Beschreibung des Dateiformats in Erwägung ziehen und einen Testdatengenerator schreiben, der das Format analysiert und daraus gültige/ungültige Dateien generiert. Dies ermöglicht auch, dass sich Ihre Testdaten entsprechend den Dateiformaten weiterentwickeln.