--- title: "Product Testing" description: "Mit Product Testing halten Sie erwartete Berechnungsergebnisse als Testfälle fest und spielen sie automatisch erneut ab, sobald sich ein Produkt, ein ProductBrick oder ein DataPool ändert. So fallen Regressionen sofort auf..." url: "https://support.pr-4.orbit.do/de/advanced-features/product-testing" locale: "de" lastReviewed: "2026-05-04" --- # Product Testing Mit Product Testing halten Sie erwartete Berechnungsergebnisse als Testfälle fest und spielen sie automatisch erneut ab, sobald sich ein Produkt, ein ProductBrick oder ein DataPool ändert. So fallen Regressionen sofort auf... > **Note:** Mit Product Testing halten Sie erwartete Berechnungsergebnisse als Testfälle (`Test Cases`) fest und spielen sie automatisch erneut ab, sobald sich ein Produkt (`Product`), ein `ProductBrick` oder ein `DataPool` ändert. So fallen Regressionen in dem Moment auf, in dem sie entstehen, und nicht erst beim Kunden. ## Überblick Orbit-Produkte bestehen aus `ProductBricks` und `DataPools`. Schon eine kleine Änderung, etwa eine Preiserhöhung, ein neuer Dieselzuschlag oder eine angepasste Machbarkeitslogik, kann sich auf jede Buchung auswirken, die das Produkt nutzt. Product Testing macht aus jeder gespeicherten Buchung einen deterministischen Regressionstest. Änderungen werden so geprüft, bevor Orbit sie speichert. Ein Testfall hält die Eingaben einer Berechnung fest (den vollständigen Transportentwurf), dazu die erwarteten Ausgaben (Positionen und Machbarkeit) und den Zeitpunkt der Berechnung. Wenn Sie später das zugrunde liegende Produkt, den `ProductBrick` oder den `DataPool` bearbeiten, spielt Orbit jeden betroffenen Testfall gegen die ausstehende Änderung ab. Bevor die Änderung gespeichert wird, prüfen Sie die Ergebnisse. > **Das Wichtigste auf einen Blick:** **Speichern nur nach Prüfung**: Jede Änderung an einem Produkt, `ProductBrick` oder `DataPool` führt die gesamte Regressions-Suite aus. Ohne Prüfung der Ergebnisse lässt sich nichts speichern. > > **Deterministisch durch simulierte Zeit**: Jeder Testfall läuft mit der Systemzeit, zu der er aufgezeichnet wurde. Er nutzt also die Versionen der Bricks und Pools, die zu diesem Zeitpunkt galten. > > **Kaskadierende Prüfung**: Wenn sich ein `DataPool` ändert, testet Orbit automatisch jedes Produkt. > > **Speichern in zwei Phasen**: Ein Soft-Save führt die Tests aus und erstellt eine Übersicht zur Prüfung. Ein Hard-Save übernimmt die Änderung und aktualisiert die erwarteten Ergebnisse (die *Sollwerte*) für die Testfälle, die Sie behalten. > > **API zuerst**: Jeder Ablauf in Orbit MissionControl steht auch über die Orbit API bereit. Agenten und Integrationen können Tests also per Programm anlegen und ausführen. ## Begriffe ### Testfälle Ein Testfall ist eine eingefrorene Momentaufnahme einer Berechnung: **Entwurfs-Snapshot**: Die vollständige Transporteingabe (Properties, Zeitstempel, Daten des Shipments, TransportShape), die als deterministische Eingabe dient. **Sollwerte**: Die erwarteten Ausgaben der Berechnung. Heute sind das Positionen und Machbarkeit. **Simulierte Zeit**: Der Zeitpunkt, zu dem die Berechnung ursprünglich lief. Wenn der Testfall läuft, behandelt Orbit diesen Zeitpunkt als aktuelle Systemzeit. Die Berechnung nutzt so die Versionen der Bricks und Pools, die damals galten. Ein Testfall gehört zu einem Produkt. Das Produkt ist der natürliche Sammelpunkt, weil es jeden `ProductBrick` und jeden `DataPool` kennt, von dem es abhängt. ### Kohorten Testfälle sind in Kohorten (`Cohorts`) gruppiert. Eine Kohorte fasst die Testfälle mit derselben simulierten Laufzeit zusammen, meist die Testfälle, die gegen die aktuell gültige Version des Produkts aufgezeichnet wurden. > **Note:** Die aktive Gruppe ist die **aktuelle Kohorte**. Wenn Sie eine neue Version eines Produkts, `ProductBrick` oder `DataPool` mit einem Gültigkeitsdatum in der Zukunft veröffentlichen, archiviert Orbit die aktuelle Kohorte. Dann legt Orbit eine neue aktuelle Kohorte an, deren Zeitstempel nach vorn verschoben sind, passend zum neuen Gültigkeitszeitraum. Archivierte Kohorten können Sie weiter einsehen. ### Soft-Save und Hard-Save Das Speichern eines Produkts, `ProductBrick` oder `DataPool` besteht aus zwei Schritten: 1. **Soft-Save**: Orbit führt jeden betroffenen Testfall gegen die ausstehende Änderung aus und gibt eine Übersicht der Ergebnisse zurück. Noch wird nichts gespeichert. 2. **Hard-Save**: Sobald Sie die Ergebnisse des Soft-Save bestätigen, übernimmt Orbit die Änderung, aktualisiert die Sollwerte der behaltenen Testfälle und archiviert jede überholte Kohorte. Diese Aufteilung macht die Funktion für die Oberfläche und für Agenten gleich gut nutzbar: Dieselben zwei Schritte steuern den Dialog **Testergebnisse überprüfen** in Orbit MissionControl und den gleichen Ablauf über die Orbit API. ## Einen Testfall anlegen Es gibt zwei Wege, einen Testfall festzuhalten. ### Aus dem Transport Composer (empfohlen) So bauen Sie eine Regressions-Suite am natürlichsten auf: Sie halten echte, aktuelle Buchungen fest, wenn sie Ihnen begegnen. \1. Öffnen Sie in Orbit MissionControl den **Transport Composer**. \2. Geben Sie eine Transportanfrage ein und lassen Sie die Produkte rechnen. \3. Öffnen Sie auf der berechneten Produktkarte das Aktionsmenü und wählen Sie **Als Test speichern**. \4. Geben Sie dem Testfall einen aussagekräftigen Namen (zum Beispiel *Same-Day-Kurier Berlin, 2 Stopps, 30 kg*) und senden Sie ab. Orbit hält den vollständigen Entwurf, den Zeitpunkt der Berechnung sowie die berechneten Positionen und die Machbarkeit als erwartete Ausgabe fest. Die Schaltfläche liegt mit Absicht im Aktionsmenü. So stört sie Nutzer bei der täglichen Buchung nicht. ### Aus dem Tab „Testen“ Jedes Produkt hat unter **Einstellungen → Products** einen Tab **Testen**. Dort können Sie: \- die vorhandenen Kohorten eines Produkts ansehen. \- den Entwurfs-Snapshot eines Testfalls öffnen und seine Eingaben prüfen. \- die aktuelle Kohorte mit **Aktuelle Testfälle ausführen** von Hand ausführen. \- die aktuelle Kohorte löschen, wenn sie nicht mehr relevant ist. Hat ein Produkt noch keine Testfälle, verweist der Tab Sie zurück zum Transport Composer, wo die meisten Testfälle entstehen. ## Der Ablauf beim Speichern Beim Speichern eines Produkts, `ProductBrick` oder `DataPool` öffnet sich immer der Dialog **Testergebnisse überprüfen**. Der Dialog führt durch drei Phasen. ### 1. Tests laufen Orbit ermittelt jedes Produkt, das von der Änderung betroffen ist, auch nachgelagerte Produkte, wenn Sie einen gemeinsam genutzten `DataPool` bearbeiten. Dann führt Orbit die passenden Testfälle parallel aus. Solange der Lauf dauert, zeigt der Dialog den laufenden Zustand. ### 2. Ergebnisse Für jedes betroffene Produkt zeigt der Dialog die Zahl **\{passed} / \{total} bestanden** und eine Liste der Testfälle. Jeder Testfall trägt `Bestanden`, `Fehlgeschlagen` oder `Fehler`: \- `Bestanden` Die ausstehende Änderung liefert eine Ausgabe, die der aufgezeichneten erwarteten Ausgabe entspricht. \- `Fehlgeschlagen` Die ausstehende Änderung liefert ein anderes Ergebnis als ursprünglich erwartet. \- `Fehler` Die Berechnung konnte nicht abgeschlossen werden (zum Beispiel wegen fehlender Daten oder eines Laufzeitfehlers in einem Brick). Sie können jeden Testfall aufklappen, um seine Sollwerte und Eingaben zu prüfen. Ist ein Testfall nicht mehr relevant, zum Beispiel weil die Änderung sein Szenario absichtlich überflüssig macht, halten Sie ihn zum Löschen gedrückt, bevor Sie fortfahren. ### 3. Speichern bestätigen Bestehen alle Testfälle, wird direkt gespeichert. Schlägt ein Testfall fehl, müssen Sie bewusst entscheiden: **Sollwerte aktualisieren** bestätigt, dass die neuen Ausgaben stimmen, und zeichnet sie als neue erwartete Ergebnisse auf. **Weiter bearbeiten** bricht das Speichern ab und bringt Sie zurück in den Editor. > **Note:** Anders gesagt: Sie dürfen mit fehlgeschlagenen Tests speichern, aber erst, wenn Sie bestätigt haben, dass jede Abweichung gewollt ist. Die Testfälle, die Sie mitnehmen, werden die neue Basis. Ein stilles Überschreiben gibt es nicht. ### Verschobene Kohorten bei neuen Versionen Führt die Änderung einen neuen Gültigkeitszeitraum ein, zum Beispiel einen `DataPool`, der ab dem Ersten des nächsten Monats gilt, macht Orbit beim Speichern zwei Dinge: \1. Die simulierte Zeit jedes behaltenen Testfalls (und alle Zeitstempel in seinem Entwurfs-Snapshot, etwa Zeitfenster für Beladung und Zustellung) rückt um die Differenz zwischen altem und neuem Gültigkeitsdatum nach vorn. Die neue Kohorte testet dieselben Szenarien weiter, nur mit der neuen Version. \2. Orbit archiviert die vorherige Kohorte. Sie bleibt im Tab **Testen** sichtbar und kommt wieder zum Einsatz, falls Sie je auf diese frühere Version zurückgehen. Ist die Verschiebung keine ganze Zahl von Wochen, fällt wochentagsabhängige Logik (zum Beispiel ein Sonntagszuschlag) unter Umständen auf einen anderen Wochentag. Neben jedem Testfall steht das simulierte Datum. So erkennen Sie das und können den Gültigkeitszeitraum bei Bedarf anpassen. ## Kaskadierende Änderungen Viele Produkte können auf einen `DataPool` verweisen. Wenn Sie einen bearbeiten, ermittelt der Soft-Save jedes Produkt, das ihn nutzt, und führt alle Testfälle aus deren aktueller Kohorte aus. Der Dialog **Testergebnisse überprüfen** gruppiert die Ergebnisse nach Produkt. So sehen Sie die Folgen einer einzelnen Änderung auf einen Blick. Änderungen an einem `ProductBrick` oder Produkt verhalten sich genauso, begrenzt auf die Produkte, die darauf verweisen. > **Note:** Beispiel aus der Praxis: > > Eine Planerin bei Spaceport Shipping Co. in Paris aktualisiert den `DataPool` für den Dieselzuschlag des kommenden Monats. Der aktuelle Wert ist 7 %, der neue Wert 9 %, gültig ab dem Ersten des nächsten Monats. > > Die Planerin öffnet **Einstellungen → Products → Pools**, bearbeitet den `DataPool` und klickt auf Speichern. Der Dialog **Testergebnisse überprüfen** öffnet sich und führt die aktuelle Kohorte gegen die ausstehende Änderung aus. Das Produkt für den Same-Day-Kurier zeigt `9 / 12 bestanden`. Drei Testfälle, alle davon priorisierte Geschäftszustellungen an ACME Ltd in Tokio, tragen `Fehlgeschlagen`, weil ihr Gesamtpreis um 2 % gestiegen ist. > > Die Planerin klappt die fehlgeschlagenen Testfälle auf, bestätigt, dass die neuen Summen genau dem höheren Zuschlag entsprechen, und klickt auf **Sollwerte aktualisieren**. Orbit übernimmt die neue Pool-Version, archiviert die vorherige Kohorte, verschiebt die simulierten Zeitstempel der behaltenen Testfälle nach vorn und zeichnet die neuen Summen als erwartete Ergebnisse auf. Wer dieses Produkt das nächste Mal ändert, testet gegen diese aktualisierten Summen. ## API-Zugriff Den gesamten Ablauf von Product Testing bietet die Orbit API unter `/v5/products/{productId}/test-cases`, darunter: \- Testfälle auflisten, abrufen, anlegen und löschen. \- Die Test-Suite für ein Produkt ausführen. \- Die Sollwerte nach einem Soft-Save aktualisieren. \- Einzelne Sollwerte aus einem Testfall entfernen. Ein Agent oder eine Integration kann also dieselbe Schleife aus Soft-Save, Prüfung und Hard-Save per Programm steuern: einen Soft-Save auslösen, jedes Testergebnis prüfen, entscheiden, welche Testfälle bleiben, und die Änderung übernehmen. Der Dialog in Orbit MissionControl ist eine mögliche Oberfläche für diesen Ablauf, Ihre eigene Automatisierung eine andere. Die Schemas für Anfragen und Antworten finden Sie in der Orbit API Reference. ## FAQ **Q: Wo liegen Testfälle?** Testfälle hängen am Produkt. Das Produkt kennt jeden `ProductBrick` und jeden `DataPool`, von dem es abhängt. Darum ist es der natürliche Ort für die Regressions-Suite. **Q: Kann ich eine Änderung speichern, ohne die Tests auszuführen?** Nein. Jede Änderung an einem Produkt, `ProductBrick` oder `DataPool` durchläuft den Ablauf aus Soft-Save und Hard-Save. Die Tests laufen immer, und Sie bestätigen das Ergebnis immer, bevor die Änderung gespeichert wird. **Q: Was passiert mit meinen alten Testfällen, wenn ich eine neue Version veröffentliche?** Orbit archiviert die vorherige Kohorte; sie bleibt am Produkt. Die Testfälle, die Sie behalten, kopiert Orbit in eine neue aktuelle Kohorte, deren Zeitstempel um die Differenz der Gültigkeitszeiträume nach vorn verschoben sind. Stellen Sie später eine frühere Version wieder her, ist deren archivierte Kohorte noch da. **Q: Mein Test ist fehlgeschlagen, weil das simulierte Datum auf einen anderen Wochentag gerückt ist. Was tun?** Neben jedem Testfall steht das simulierte Datum. Liegt die Ursache in einer wochentagsabhängigen Regel (zum Beispiel einem Wochenendzuschlag), passen Sie den Gültigkeitszeitraum Ihrer neuen Version so an, dass die Verschiebung auf denselben Wochentag fällt. Meist verlängern Sie die Differenz dazu auf ein Vielfaches von sieben Tagen. **Q: Welche Arten von Sollwerten werden heute unterstützt?** Positionen und Machbarkeit hält Orbit automatisch fest, wenn Sie einen Testfall aus dem Transport Composer speichern. **Q: Kann ein Testfall externe APIs aufrufen?** Tests sind nur deterministisch, solange der Code des `ProductBrick` keine externen Live-Dienste aufruft. Aufrufe an externe REST-APIs lassen sich nicht gegen einen eingefrorenen Zeitpunkt wiederholen. Wir empfehlen daher, diese Logik auf der Plattform zu halten. Natürlich können Sie trotzdem externe API-Endpunkte aufrufen. Beachten Sie nur, dass das zu unzuverlässigen Regressionstests führen kann. **Q: Ist Product Testing über die Orbit API verfügbar?** Ja. Der gesamte Ablauf aus Anlegen, Auflisten, Ausführen und Aktualisieren der Sollwerte steht unter `/v5/products/{productId}/test-cases` bereit. Details finden Sie in der Orbit API Reference.