Testfall-Versionen¶

Die Versionshistorie hält fest, wie ein normaler Testfall der Testbibliothek zu einem früheren Zeitpunkt aussah. Eine Version umfasst den Testfall und seine Varianten gemeinsam. Quick-Testfälle sind ausgenommen. Die Versionierung ersetzt weder Testergebnisse noch das ergänzende Änderungsprotokoll.

Versionen ansehen und vergleichen¶

Öffnen Sie in der Testbibliothek einen normalen Testfall und wählen Sie Versionen. Sie benötigen Leserechte auf den Testfall. Die Liste zeigt die gespeicherten Stände; wählen Sie einen Eintrag, um dessen Inhalt und Dateien anzusehen. Zum Vergleich wählen Sie zwei Versionen. Die geänderten Bereiche werden aufgelistet, die Inhalte nebeneinander dargestellt.

Beim Speichern geänderter Inhalte entsteht automatisch eine neue Version. Unverändertes Speichern erzeugt keine zusätzliche Version. Alles speichern fasst die bearbeiteten Angaben eines Testfalls zu einem gemeinsamen Stand zusammen. Sofort gespeicherte Aktionen, beispielsweise das Hinzufügen eines Anhangs, sind eigene Änderungen.

Der beim Umstellen eines bestehenden Projekts erfasste Ausgangsstand ist keine nachträglich rekonstruierte Vorgeschichte. Frühere Änderungen können gegebenenfalls im alten Änderungsprotokoll stehen; sie werden nicht als vollständige Testfallversionen ausgegeben.

Was zu einer Version gehört¶

Beschreibung, Vorbedingungen, Testschritte, erwartete Ergebnisse und Varianten, einschließlich der damals wirksamen geerbten Inhalte.
Benutzerdefinierte Felder mit ihren historischen Werten und Definitionen, einschließlich der damals wirksamen geerbten Werte.
Feste Versionen verwendeter Testschrittbausteine und deren vollständige Texte.
Gespeicherte Dateianhänge und eingebettete Bilder als unabhängige Kopien.
Die erfassten fachlichen Beziehungen als Herkunftsinformation.

Die historischen Dateien bleiben lesbar, wenn ein ursprünglicher Anhang oder ein Inline-Bild später aus dem aktuellen Testfall entfernt wird. Für ihren Abruf gelten weiterhin die aktuellen Zugriffsrechte auf den Testfall. Extern verknüpfte Anhänge werden nur als Verweise gekennzeichnet; ihre Ziele werden nicht automatisch heruntergeladen oder dauerhaft gesichert. Interne Serverpfade werden in der Historie nicht offengelegt. Beim Wiederherstellen bleiben die aktuell vorhandenen externen Verknüpfungen erhalten. Bereits vor der Erfassung fehlende Dateien lassen sich durch Versionierung nicht wiederherstellen und werden entsprechend gekennzeichnet.

Kennwortfelder werden nicht in lesbare historische Inhalte aufgenommen. Zugangsdaten und ausführbare Konfigurationen externer Werkzeuge werden nicht durch eine Wiederherstellung zurückgesetzt. Pro Datei sind bis zu 100 MB, für alle Dateien einer Version zusammen bis zu 256 MB vorgesehen; größere Inhalte müssen vor dem Speichern gesondert behandelt werden.

Einen früheren Inhalt wiederherstellen¶

Mit Bearbeitungsrechten können Sie einen früheren Stand auswählen und Wiederherstellen aufrufen. Prüfen Sie die Vorschau und bestätigen Sie erst danach. Die Wiederherstellung erzeugt eine neue aktuelle Version mit einem Verweis auf den übernommenen Stand. Sie überschreibt keine alte Version.

Fehlen inzwischen benötigte Felddefinitionen oder passen deren Typen beziehungsweise Auswahlwerte nicht mehr, blockiert die Vorschau die Übernahme. Stellen Sie die Definitionen wieder bereit oder schließen Sie die betroffenen Felder ausdrücklich aus. Nicht mehr nutzbare Bausteinverwendungen können nur nach ausdrücklicher Auswahl in eigene historische Texte umgewandelt werden.

Wiederhergestellt werden die eigenen Feldwerte des Testfalls und seiner Varianten. Geerbte benutzerdefinierte Werte bleiben in der historischen Ansicht nachvollziehbar; ihre übergeordneten Definitionen werden nicht verändert. Für den aktuellen Testfall gelten nach der Wiederherstellung weiterhin die aktuellen Vererbungsregeln.

Berechtigungen, persönliche Einstellungen, Ergebnisse und frühere Reviewfreigaben werden nicht zurückgesetzt. Historische Beziehungen werden nicht stillschweigend neu angelegt. Bereits erzeugte Testläufe behalten ihren übernommenen Inhalt; eine Wiederherstellung schreibt keine alten Ergebnisse um.

Hat jemand den Testfall seit Ihrer Vorschau geändert, wird die Übernahme abgewiesen. Laden Sie den aktuellen Stand neu und prüfen Sie den Vergleich erneut.

Vorlagen, Läufe und Reviews¶

Eine Planvorlage kann einen ausdrücklich übernommenen Bibliotheksstand verwenden. Neue Testläufe behalten die dabei gespeicherten Inhalte und ihre Versionsherkunft. Eine spätere Synchronisierung mit der Bibliothek verändert vorhandene normale Laufdefinitionen nicht. Für ältere Läufe ohne aufgezeichnete Herkunft wird keine Version nachträglich behauptet. Einzelne projektübergreifende Kopien übernehmen keine fremde Revisionskennung, wenn das zugehörige Archiv im Zielprojekt fehlt.

Änderungen an geerbten Feldwerten oder zentralen Felddefinitionen erzeugen nicht unmittelbar für jeden Testfall eine Version. Speichern Sie den betroffenen Testfall, bevor Sie ihn erneut freigeben. Solange sein aktueller Inhalt vom gespeicherten Versionsstand abweicht, wird eine neue Reviewentscheidung abgewiesen; eine Planübernahme erhält dann keinen unzutreffenden Versionsbezug.

Neue Reviewentscheidungen beziehen sich auf den geprüften Inhaltsstand. Ändert sich dieser vor dem Bestätigen, muss der aktuelle Inhalt erneut geprüft werden. Ein wiederhergestellter Inhalt übernimmt keine frühere Reviewfreigabe automatisch.

Windows und Schnittstellen¶

Windows bleibt zum Bearbeiten und Ausführen der Testfälle verwendbar. Versionen im Web im Testfallfenster öffnet die passende Browseransicht mit derselben Anmeldeübergabe wie Im Web öffnen. Vergleich und Wiederherstellung erfolgen im Browser. Nur wenn die Übergabe fehlschlägt, ist eine Web-Anmeldung erforderlich.

MCP und REST verwenden dieselben Projekt- und Objektrechte. ztm_project_test_case_versions bietet Liste, Inhalt, Vergleich, Dateiinhalte und Wiederherstellungsvorschau. Die Schreibfähigkeit project.test-case-version.restore wird über ztm_project_action_prepare und ztm_project_action_commit vorbereitet und bestätigt. Eine allgemeine API-Schreibfreigabe ersetzt keine Objektberechtigung.

Projekte aktualisieren und sichern¶

Vor der Schemaumstellung das vollständige Projekt sichern und alle alten Windows-, Web- und Hintergrundprozesse für dieses Projekt beenden. Die Migration installiert zusätzlich einen Datenbankschutz gegen Schreibzugriffe älterer Clients. Während einer laufenden Migration werden auch gewöhnliche Schreibzugriffe aktueller Clients abgewiesen. Nach einer unterbrochenen Migration muss die Aktualisierung mit einem aktuellen Client vollständig abgeschlossen werden.

Dieser Schutz ersetzt das Wartungsfenster nicht: Ältere Programme können unmittelbar auf Projektdateien zugreifen, ohne vorher in die Datenbank zu schreiben. Gemischter Schreibbetrieb mit alten Clients ist deshalb weiterhin nicht unterstützt.

Historische Dateiinhalte werden mit der Projektdatenbank gesichert. Bei vollständiger Projektübertragung und Datenbankkonvertierung müssen Historie, Dateiinhalte und Versionsherkunft gemeinsam übertragen werden. Ein einzelner Text- oder Tabellenexport ist kein Archiv der vollständigen Versionsgeschichte.