Neue Lufox-Funktionen auf einer Testwelt prüfen

Eine neue Funktion kann in einer leeren Entwicklungswelt fehlerfrei wirken und im tatsächlichen Projekt sofort Probleme verursachen. Dort treffen ältere Spielstände, andere Berechtigungen und mehrere gleichzeitig aktive Systeme aufeinander. Eine Testwelt soll diesen Abstand gezielt verkleinern. Sie muss nicht jede Einzelheit des öffentlichen Betriebs kopieren. Sie braucht die Bestandteile, die für die konkrete Änderung relevant sind, und einen Ausgangszustand, der sich zuverlässig wiederherstellen lässt.

Lufox enthält bereits automatisierte Prüfungen für verschiedene Fachbereiche. Im inspizierten Quelltext werden beispielsweise Questziele und Menübelegungen untersucht sowie gespeicherte Arbeitszustände eines Helfers wieder eingelesen. Diese Tests belegen vorhandene Prüfideen, nicht einen hier ausgeführten vollständigen Testlauf. Für eine neue Veröffentlichung werden solche automatischen Prüfungen mit tatsächlicher Bedienung in einer getrennten Spielumgebung verbunden. Beide Ebenen beantworten unterschiedliche Fragen.

Die Prüffrage vor der Umgebung festlegen

Am Anfang steht eine konkrete Änderung. Ein neuer Abholknopf soll beispielsweise eine bereits verdiente Belohnung ausgeben. Die Prüffragen lauten dann: Erscheint der Knopf im richtigen Zustand, wird die Belohnung genau einmal ausgegeben und bleibt der Abschluss nach einer Unterbrechung erhalten? Diese Fragen bestimmen, welche Daten und welche anderen Systeme im Test benötigt werden.

Eine allgemeine Aussage wie „Wir testen den Server“ ist zu weit. Sie erzeugt viele zufällige Spielhandlungen, aber wenig belastbare Erkenntnis. Besser ist ein begrenzter Prüfauftrag mit klaren Erwartungen. Zusätzlich werden einige benachbarte Abläufe ausgewählt, die durch die Änderung betroffen sein könnten. Beim Abholknopf gehören dazu etwa bereits abgeschlossene Aufgaben und ein volles Inventar.

Die Testumgebung wird anschließend passend aufgebaut. Für eine reine Textänderung ist keine Kopie aller Welten notwendig. Für einen Inventarwechsel zwischen Servern reicht dagegen eine einzelne lokale Menüansicht nicht aus. Der Aufwand folgt dem Risiko und dem Zusammenhang. So bleibt die Prüfung gründlich, ohne jede kleine Änderung mit derselben großen Umgebung zu belasten.

Testdaten bewusst vorbereiten

Ein gutes Testkonto besitzt einen bekannten Zustand. Es kann eine offene Aufgabe, eine abholbare Belohnung und ein klar beschriebenes Inventar haben. Dieser Zustand wird vor dem Versuch festgehalten. Danach lässt sich beurteilen, ob genau die erwartete Änderung entstanden ist. Ein zufällig über Wochen bespieltes Administrationskonto ist dafür ungeeignet, weil seine Vorgeschichte kaum noch nachvollziehbar ist.

Mehrere Ausgangslagen ergänzen sich. Ein frisches Konto prüft den Einstieg. Ein fortgeschrittenes Konto prüft vorhandene Daten. Ein Konto ohne passende Berechtigung prüft die Grenze. Diese Unterschiede sind wichtiger als viele nahezu identische Durchläufe mit derselben Person. Für jede Ausgangslage wird beschrieben, warum sie zur Änderung gehört.

Produktive Daten werden nicht unbesehen kopiert. Häufig genügen künstliche, aber fachlich passende Datensätze. Wenn eine konkrete ältere Struktur benötigt wird, kann eine bereinigte Kopie sinnvoll sein. Dabei bleiben private Informationen und echte externe Zugänge außerhalb des Tests. Das Ziel ist eine repräsentative Form des Zustands, nicht eine möglichst umfangreiche Sammlung tatsächlicher Spielerinformationen.

Die Testwelt von echten Wirkungen trennen

Eine Kopie kann weiterhin auf produktive Dienste zeigen, wenn ihre Verbindungen nicht bewusst angepasst wurden. Dann könnten Testbelohnungen echte Konten verändern oder Testmeldungen öffentliche Kanäle erreichen. Deshalb wird vor der ersten Handlung geprüft, welche Datenbank, welche externen Dienste und welche Auslieferungswege die Umgebung verwendet. Ein anderer Weltname allein schafft keine ausreichende Trennung.

Die Umgebung erhält eine deutlich erkennbare Kennzeichnung. Diese ist im Spiel und in den zugehörigen Verwaltungsansichten sichtbar, damit eine Person nicht versehentlich den falschen Bereich bedient. Gleichzeitig wird der Zugang auf die vorgesehenen Tester begrenzt. Die Kennzeichnung erklärt den Zweck; die Zugangskontrolle verhindert unbeabsichtigte gewöhnliche Nutzung.

Für die Freigabe wird später das geprüfte Programm übernommen, nicht der gesamte zufällig veränderte Testspielstand. Die Welt kann während der Versuche absichtlich beschädigt oder mit Sonderfällen gefüllt worden sein. Deshalb sind Freigabeartefakt und Testdaten getrennte Ergebnisse. Diese Unterscheidung verhindert, dass ein erfolgreicher Test ausgerechnet seine künstlichen Ausgangsbedingungen in den normalen Betrieb mitnimmt.

Einen normalen Ablauf vollständig spielen

Der erste Durchlauf folgt einer gewöhnlichen Absicht. Die Testperson öffnet die Aufgabenübersicht, findet die abholbare Belohnung und bestätigt die Ausgabe. Danach schließt sie die Ansicht, öffnet sie erneut und prüft den Abschluss. Anschließend meldet sie sich ab und wieder an. Erst dadurch wird sichtbar, ob das Ergebnis über die ursprüngliche Menüinstanz hinaus Bestand hat.

Die Person erhält das Ziel, aber keine Schrittfolge mit jeder genauen Position. So zeigt der Versuch auch, ob die Oberfläche verständlich ist. Wenn der Entwickler ständig erklären muss, welcher Knopf gemeint ist, fehlt möglicherweise Information im Spiel. Solche Beobachtungen werden genauso ernst genommen wie eine technische Ausnahme. Eine funktionierende, aber unauffindbare Aktion erfüllt ihren Zweck nur eingeschränkt.

Nach dem Ablauf werden die maßgeblichen Daten geprüft. Eine grüne Meldung allein reicht nicht. Die Belohnung soll tatsächlich vorhanden und der Abholstatus abgeschlossen sein. Wenn beide Informationen aus verschiedenen Speichern stammen, werden sie gemeinsam betrachtet. Die Testnotiz hält das Ergebnis so fest, dass eine zweite Person denselben Zusammenhang nachvollziehen kann.

Fehler an gezielten Stellen auslösen

Nun wird der Ablauf an einer bekannten Stelle unterbrochen. Beispielsweise wird die Datenantwort verzögert, während die Person das Menü schließt. Danach wird geprüft, ob eine alte Antwort die neue Ansicht überschreibt. Ein anderer Test unterbricht die Verbindung nach der verbindlichen Buchung, aber vor der sichtbaren Bestätigung. Nach der Rückkehr muss der vorhandene Abschluss erkennbar bleiben.

Solche Fehler werden kontrolliert erzeugt. Ein zufälliger Neustart irgendwann während einer langen Sitzung liefert weniger genaue Erkenntnisse. Der Test benennt die Grenze, an der die Unterbrechung stattfindet, und den erwarteten Zustand danach. Dadurch kann eine gefundene Abweichung reproduziert werden. Eine spätere Korrektur wird mit derselben Folge erneut geprüft.

Für die technische Untersuchung können gezielte Protokolle oder ein Debugger helfen. Paper beschreibt beide Möglichkeiten und den Einsatz von Haltepunkten zur Betrachtung des aktuellen Zustands. In einer getrennten Testumgebung lässt sich damit eine schwierige Reihenfolge bewusst anhalten. Solche Werkzeuge werden kontrolliert verwendet und nicht als öffentlich erreichbare Dauerfunktion betrieben. Paper: Debugging your plugin

Automatische Tests auf fachliche Regeln ausrichten

Nicht jede Prüfung benötigt eine laufende Welt. Eine Regel über erlaubte Zustandsübergänge lässt sich oft mit einfachen Daten untersuchen. Der vorhandene Lufox-Test für einen Arbeitsplan prüft beispielsweise, dass ein voller Transport erst abgeliefert wird und dass gespeicherte Fracht nach erneutem Laden erhalten bleibt. Solche Tests beschreiben eine fachliche Erwartung und können schnell wiederholt werden.

Die JUnit-Dokumentation erläutert das Framework für strukturierte Tests und überprüfbare Erwartungen. Entscheidend für das Projekt ist jedoch die Auswahl sinnvoller Aussagen. Ein Test, der nur dieselbe Berechnung noch einmal abschreibt, liefert wenig zusätzliche Sicherheit. Besser ist eine Eigenschaft wie „derselbe Auftrag verändert den Zustand höchstens einmal“ oder „ein ungültiger gespeicherter Zustand wird nicht still als leeres Ergebnis übernommen“. JUnit: User Guide

Konfigurationsprüfungen ergänzen diese Regeln. Der inspizierte Questkatalogtest untersucht unter anderem Zielbezeichnungen, Voraussetzungen und Feldbelegungen. Ein Menütest prüft vorhandene Routen und Überschneidungen. Diese Prüfungen sind besonders hilfreich, weil Inhalte auch ohne Änderung am Java-Code fehlerhaft werden können. Ein korrekt kompilierter Programmstand beweist keine gültige neue Aufgabenliste.

Unterschiede zur echten Umgebung sichtbar halten

Eine Testwelt besitzt oft weniger Spieler, weniger Daten und kürzere Wege. Diese Unterschiede begrenzen die Aussage des Tests. Eine erfolgreiche Funktionsprüfung ist deshalb nicht automatisch ein Leistungsnachweis für hohe gleichzeitige Nutzung. Umgekehrt muss ein kleiner Funktionstest nicht künstlich mit großer Last überfrachtet werden. Beide Fragestellungen können getrennt geprüft und dokumentiert werden.

Wichtig ist eine kurze Liste der relevanten Unterschiede. Vielleicht wurde nur ein Clienttyp getestet, eine externe Verbindung durch einen Ersatz simuliert oder eine ältere Datenmenge verwendet. Diese Angaben machen den Erfolg nicht wertlos. Sie verhindern lediglich eine zu weitgehende Schlussfolgerung. Das Team kann anschließend gezielt entscheiden, welche zusätzliche Prüfung vor der Veröffentlichung noch nötig ist.

Auch Zeitverhalten unterscheidet sich. Eine sehr schnelle lokale Antwort kann Fehler verdecken, die erst bei Verzögerung auftreten. Deshalb werden für betroffene Abläufe bewusst langsame Antworten und umgekehrte Abschlussreihenfolgen getestet. Der Zweck ist nicht, das System maximal zu quälen, sondern realistische Unsicherheiten sichtbar zu machen, die im normalen kurzen Durchlauf selten auftreten.

Einen Fehlerbericht reproduzierbar schreiben

Ein guter Bericht nennt Ausgangszustand, Handlung, erwartetes Ergebnis und tatsächlich beobachtetes Ergebnis. Hinzu kommen die geprüfte Fassung und gegebenenfalls eine kurze Folge von Zeitpunkten. Diese Struktur ist hilfreicher als „geht manchmal nicht“. Ein Bild oder Protokollausschnitt ergänzt den Bericht, ersetzt aber nicht die Beschreibung des Ablaufs.

Für das Belohnungsbeispiel könnte die Beobachtung lauten, dass nach dem Schließen während einer verzögerten Antwort das alte Menü erneut erschien. Der Bericht nennt genau, wann geschlossen wurde und welche Ansicht danach offen war. Dadurch lässt sich die vermutete Ursache eingrenzen. Ein allgemeiner Hinweis auf ein kaputtes Menü würde dagegen mehrere völlig unterschiedliche Fehler zusammenfassen.

Nach einer Korrektur wird zuerst der ursprüngliche Fall wiederholt. Anschließend folgen die unmittelbar benachbarten Fälle, etwa normales Öffnen und ein zweiter schneller Wechsel. Es ist nicht nötig, ohne Anlass sämtliche alten Tests mehrfach neu auszuführen. Die Breite der Prüfung richtet sich danach, welche Zusammenhänge die Änderung tatsächlich berührt.

Die Freigabe als begrenzte Aussage formulieren

Am Ende steht eine konkrete Aussage über den geprüften Stand. Der neue Abholablauf wurde mit den benannten Ausgangsdaten getestet, Unterbrechungen wurden behandelt und die relevanten gespeicherten Zustände stimmen. Offene Einschränkungen bleiben sichtbar. Eine pauschale Formulierung wie „alles fehlerfrei“ wäre durch keinen endlichen Test glaubwürdig belegt.

Zusätzlich wird der Rückweg vorbereitet. Das vorherige Programm und ein passender Datenstand müssen zusammen verfügbar sein, falls die neue Fassung unerwartete Probleme zeigt. Die Testumgebung kann diesen Rückweg bereits üben. Besonders bei Datenformatänderungen ist das wichtig, weil ein älteres Programm einen neu geschriebenen Zustand möglicherweise nicht mehr versteht.

Eine gute Lufox-Testwelt ist damit ein Werkzeug für klare Fragen. Sie verbindet kontrollierte Ausgangslagen mit tatsächlicher Bedienung und gezielt erzeugten Fehlern. Ihr Wert liegt nicht in der bloßen Existenz einer zweiten Welt, sondern in wiederholbaren Aussagen über eine konkrete Änderung. So gelangen neue Funktionen mit einem nachvollziehbaren Prüfergebnis in das Projekt, statt lediglich nach einer gelungenen Vorführung als fertig zu gelten.