2009-04-24 11 views
3

Ich habe Hunderte von Skripten zum Testen einer Komponente. Jedes dieser Skripte enthält eine Reihe von Indizes und einzelnen Datensätzen.Was ist der "beste" Weg, Skripte zu speichern?

Indizes können in mehreren TC_Level-Skripts und sogar in anderen Indizes verwendet werden.
Jedes Skript hat einen eindeutigen Namen.

Beispiel:

TC_1 
    | 
(1) Subscript_a 
    | | 
    | (1) Record i 
    | | 
    | (2) Record ii 
    | 
(2) Subscript_b 
    | | 
    | (1) Subscript_c 
    | | | 
    | | (1) Record_i 
    | | | 
    | | (2) Record_iii 
    | | 
    | (2) Record_ii 
    | 
(3) Record_iv 
    | 
(4) Record_v 
    | 
    ... 

Ich möchte

  • speichern meine Skripte in einem Container.
  • lesen Sie sie in eine Strukturansicht innerhalb meiner Skript-Engine.

Welche Art von Container sollte ich verwenden?

Möglicher Behälter (aber nicht beschränkt auf): Verzeichnis, Datenbank, XML-Datei, eine Tabelle, Flatfile, ...

Bitte, für Vorschläge, auch eine kurze Probe (nicht unbedingt Code) von Speicher Struktur.

Ich habe C# Beispiele zum Auffüllen von Baumansichten von Datenbanken gesehen, aber ich glaube nicht, dass ich einen Verweis auf eine parentID (für die Indizes) verwenden kann, da ein Index mehr als eine parentID haben kann.

+0

Alle: Ich stimme zu, dass die Verwendung eines Dateisystems eine praktikable Lösung ist (siehe Kommentar zu Chris), aber wir wollten den Fehler vermeiden, versehentlich ein Skript zu löschen, wenn Skripte entfernt wurden, die nicht mit "MainScriptForTesting" verknüpft sind. Wir denken darüber nach, einen strengeren Prozess zu verwenden, bei dem wir Änderungen an Skripten "rechtfertigen" (mit Hilfe von Bugfixes) und Änderungshistorie zur Bearbeitung von Skripten hinzufügen müssen. –

Antwort

4

Ich würde empfehlen, auf eine Verzeichnisstruktur + Versionskontrollsystem zu verlassen.

Es hat viele Vorteile:

  • Versionskontrolle hilft Ihnen, Ihre Revisionen zu halten und verbessert die Sicherheit
  • es ist immer noch zugänglich für Sie ohne Phantasie Werkzeuge
  • es einfach ist
  • es ist ziemlich schnell
+0

Das Programm, das wir ursprünglich verwendet haben, hat ein Verzeichnis für die Skripte verwendet und wir haben sie gerade eingelesen. Die Endbenutzer würden sehr oft vergessen, ein Skript hinzuzufügen, wenn sie in das Konfigurationsmanagement einsteigen. Sie würden das erst eine Woche vor dem eigentlichen Test bemerken und die fehlenden Skripte aufspüren. Dann legen wir alles in eine (schlecht entworfene) Datenbank und jetzt habe ich die Möglichkeit, die Oberfläche (und den Datenspeicher) neu zu schreiben. –

0

Ich würde auch empfehlen, nur eine Verzeichnisstruktur mit einer einheitlichen Namensgebung zu verwenden mich. Wenn Sie alle Dateien packen müssen, können Sie möglicherweise einfach "tar" (oder ein anderes Archivierungs-/Zip-Tool) verwenden.

+0

Konfigurationsverwaltung "würde" durch und lassen uns jedes einzelne Skript entpacken und verifizieren. ;) –

1

Ich stimme einem Versionskontrollsystem und einem Dateisystem ist ideal.

Allerdings würde ich auch empfehlen, dass Sie jeden Testfall aufteilen, um ein Verzeichnis für jedes Stück zusätzlicher Daten zu enthalten, die es benötigt. Die meisten modernen Data Versionskontrollsysteme unterstützen die Begriffe von Links und dies wäre eine ideale Verwendung von ihnen, um alles auf lange Sicht wartbar zu machen. Diese spielen auch gut mit Teer, wie in einer anderen Antwort erwähnt wird.

Shared 
| | 
| Subscript_a 
| | 
| Subscript_b 
| | 
| Subscript_c 
Test_Case_1 
|   | 
|   SUBSCRIPT_B_DIRECTORY 
|        | 
|        link to ../../Shared/Subscript_b 
|        | 
|        SUBSCRIPT_C_DIRECTORY 
|             | 
|             link to ../../../../Shared/scri_c 
Test_Case_2 
|   | 
|   SUBSCRIPT_C_DIRECTORY 
|        | 
|        link to ../../Shared/Subscript_c 
Test_Case_3 
      | 
      SUBSCRIPT_A_DIRECTORY 
      |     | 
      |     link to ../../Shared/Subscript_a 
      SUBSCRIPT_B_DIRECTORY 
           | 
           link to ../../Shared/Subscript_b 

Das gleiche würde für Datensätze gelten. Es ist schmerzhaft zu Setup, aber ich glaube, dass es kaufen Sie die Flexibilität und Wartbarkeit auf lange Sicht von in der Lage, Ihre Skripte und Test_Cases mischen und übereinstimmen. Sie müssen mit der zusätzlichen Umleitungsebene umgehen, und einige Umgebungsvariablen wie $ SHAREDTOP könnten Ihre Skripts davon abhalten, verschoben zu werden.Wenn Sie Windows sind, erhalten Sie nur die verknüpfbare Funktion von einem guten Versionskontrollsystem. Wiederum würde tar auf einer UNIX-Box sogar ausreichen.

+0

Siehe den obigen Kommentar. –

Verwandte Themen