Ein Bundle testen #

Diese Seite richtet sich an Bündler, die ein Release vor der Auslieferung testen. Ein Bundle kombiniert viele Teile; der einzige Beweis, dass sie zusammen funktionieren, ist, das Bundle so zu installieren und zu verwenden, wie es ein Empfänger tun würde.

Inhalt #

1. Die Testmatrix
2. Prüfungen am Build
3. Installationstests
4. Prüfungen an der laufenden Website
5. Upgrade-Test
6. Das Testprotokoll

Die Testmatrix #

Führen Sie auf, was Sie zusagen, und testen Sie jede zugesagte Kombination, nicht mehr:

PHP:        8.x, 8.y
Database:   SQLite 3, PostgreSQL <version>
Server:     Velocity (qbix) / Apache + PHP-FPM / nginx + PHP-FPM
Install:    exp:install / kickstarter / setup wizard
Network:    online / offline
Upgrade:    from bundle <previous version>

Die CI des Projekts testet PostgreSQL 15 und MySQL 8.0 und führt für die anderen die Unit-Tests der Treiber aus (Datenbankunterstützung); eine Kombination, die Ihr Bundle darüber hinaus zusagt, müssen Sie selbst nachweisen.

Prüfungen am Build #

Installationstests #

1. Probelauf: php bin/php/console exp:install --dry-run ... oder exp:kickstarter run --dry-run; Exit 0.
2. Installation: Exit 0; var/log/setup.log endet mit einer RESULT-Zeile ohne Fehler. Das Protokoll enthält "Zustandsprüfungen nach der Installation (Datenbank, deklarierte Tabellen, Inhaltsklassen, Objekte, Inhaltswurzel, Namenslisten, Einstellungen, Siteaccesses, Besitzrechte der Dateien)" (Installation mit einem Befehl).
3. Zweiter Start: Der Test auf eine bestehende Installation überspringt die Installation; die Daten sind noch da.
4. Offline: dieselbe Installation ohne ausgehendes Netzwerk (Offline-Bundles).
5. Fehlerfall: Ein falsches Datenbankpasswort ergibt Exit 1, aktiven Wartungsmodus und einen lesbaren Grund in var/log/setup.log.

Prüfungen an der laufenden Website #

• To do: Die Website und die Administration antworten unter den dokumentierten Adressen.
• To do: Mit dem übergebenen Passwort anmelden; es ändern; die Datei var/log/initial-admin-password ist verschwunden.
• To do: Einen Artikel mit einem Bild veröffentlichen; er erscheint auf der Website; Bildvarianten werden erzeugt.
• To do: Die Suche findet ihn.
• To do: Cron läuft (runcronjobs.php) als Benutzer der Website ohne Rechtefehler.
• To do: /.git/config, /settings/site.ini, /composer.json werden nicht ausgeliefert (13.16).
• To do: Kein Hinweisbalken Demo-Modus (außer in Demo-Bundles).
• To do: Info > Über und Info > Copyright zeigen die Versionen und Lizenzen.
• To do: Keine Dateien unter var/ gehören root.
• To do: Nach einem Neustart des gesamten Bundles gilt alles oben Genannte weiterhin.

Upgrade-Test #

1. Installieren Sie das vorige Bundle-Release; fügen Sie einige Inhalte hinzu.
2. Wenden Sie Ihr Update so an, wie es die Empfänger tun werden (Updates und Upgrade-Pfade).
3. Prüfen Sie die Versionszeile (erwarteter Wert für die Linie 6.0.15: 6.0.15stable, Abfrage in 11.2), die Inhalte, die Anmeldung und die Prüfungen oben.
4. Folgen Sie 11.7 Das Upgrade überprüfen.

Das Testprotokoll #

Bewahren Sie je Release auf: die Matrix mit Ergebnissen, var/log/setup.log und var/log/kickstart.log jeder Installation, das Build-Protokoll (Lock-Dateien und reproduzierbare Builds) und die Namen der Tester. Partner, die Exponential-Releases selbst testen, können Ergebnisse zurückmelden (Releases testen).

Verwandte Seiten #

• Checkliste für die Bundle-Veröffentlichung
• Testen in einer Sandbox (Seitenpakete)
• Benchmarking einer gehosteten Website
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.