Mandantenkontext prüfen, wenn ein Worker abwechselnde Aufträge verarbeitet

Ziel

Testen, ob mandantenspezifischer Zustand in einen späteren, vom selben Worker bearbeiteten Auftrag übergeht. Dieser originäre Testfall konzentriert sich auf Worker-Wiederverwendung und Auftragsreihenfolge statt auf umfassende Behauptungen zur Mandantenisolation.

Voraussetzungen

Einen isolierten Worker-Prozess mit synthetischen Mandanten und unterscheidbaren neutralen Datensätzen verwenden. Eine kontrollierte Möglichkeit bereitstellen, aufeinanderfolgende Aufträge durch denselben Worker zu schicken und deren Ergebnisse zu prüfen, ohne echte Daten offenzulegen.

Schritte

1. Die explizite Mandanteneingabe und die zulässige Ausgabe jedes Auftrags festlegen. Jeden Anwendungskontext einbeziehen, der rund um die Verarbeitung initialisiert und gelöscht werden soll, ohne sich auf einen impliziten Standardmandanten zu verlassen.

2. Einen Auftrag für den ersten Mandanten und dann einen Auftrag für den zweiten Mandanten durch denselben Worker ausführen. Zurückgegebene Datensätze und Nebeneffekte gegen den jeweils erwarteten Mandanten jedes Auftrags prüfen.

3. Die Auftragsreihenfolge umkehren und wiederholen. Reihenfolgeabhängige Unterschiede rechtfertigen eine Untersuchung von bewahrtem Kontext, Testfallverunreinigung oder einer anderen verborgenen Abhängigkeit; sie sind nicht automatisch ein Beweis für einen Sicherheitsdefekt.

4. Einen kontrollierten Fehler im ersten Auftrag einführen, bevor der zweite beginnt. Prüfen, dass Aufräumen und Kontextinitialisierung weiterhin das deklarierte Verhalten des zweiten Auftrags ergeben.

5. Nach der Reparatur die Fälle mit umgekehrter Reihenfolge und vorangehendem Fehler als Regressionen bewahren. Kontrollen mit frischem Worker beibehalten, damit der Test Initialisierungsdefekte von Zustand unterscheiden kann, der von einem früheren Auftrag zurückgelassen wurde.

Erwartetes Ergebnis

Der brauchbare Nachweis bildet Vorgängerauftrag, aktuellen Mandanten, Ausgabe und Nebeneffekte ab und macht jede Abhängigkeit von vorheriger Mandantenverarbeitung sichtbar und reproduzierbar.

Grenzen und Prüfbasis

Dieser sequenzielle Vorschlag testet weder gleichzeitige Aufgaben noch jede Form von gemeinsam genutztem Zustand. Thread-basierte, asynchrone und Multi-Prozess-Ausführung erfordern separat kontrollierte Nebenläufigkeits-Testfälle mit demselben expliziten Mandantenorakel. Dies ist eine originäre vorgeschlagene Methode; es wird keine Ausführung und kein empirisches Ergebnis behauptet.