So prüfen wir

Technische Aussage Beleg: Test Stand: 28.10.2026

Worum geht es?

Wir prüfen Illumentis auf mehreren Ebenen: mit automatisierten Tests, mit Tests, die den ganzen Code nach Mustern durchsuchen, mit gezielten Angriffsversuchen und mit Scans. Eine Änderung muss diese Prüfungen bestehen, bevor sie ausgeliefert wird. Zahlen und Ergebnisse stehen im Monatsbericht.

Schutzziel

Eine Schutzmaßnahme soll nicht nur einmal funktionieren, sondern bei jeder Änderung am Code weiter wirken. Neue Fehler sollen auffallen, bevor Nutzerinnen und Nutzer sie erleben.

Funktionsprinzip

Die Prüfung besteht aus Schichten, die sich ergänzen:

Funktionstests: Einheits- und Funktionstests im Backend (PHPUnit), Tests der Oberfläche (Vitest) und Ende-zu-Ende-Tests im Browser (Playwright).
Sicherheitstests: Zu jeder sicherheitsrelevanten Schutzmaßnahme gehört eine eigene Testklasse.
Tests über den ganzen Code: Sie suchen nach Mustern statt nach bekannten Einzelfällen, zum Beispiel ob jede Route eine Zugriffsprüfung hat. Mehr dazu in einem eigenen Artikel.
Statische Analyse: PHPStan findet Typ- und Logikfehler, Deptrac prüft die Architekturregeln.
Mutation-Testing: Infection baut absichtlich Fehler in Berechtigungsprüfungen ein und prüft, ob die Tests sie bemerken.
Abhängigkeiten und Geheimnisse: Prüfung der Bibliotheken auf bekannte Schwachstellen und Lizenzen, Suche nach versehentlich eingecheckten Zugangsdaten.
Angriffsversuche und Scans: Gezielte Versuche, als angemeldeter Nutzer an fremde Daten zu kommen, und ein Scan der Beta-Instanz von außen.

Maßnahmen

Wir setzen diese Prüfungen so ein, dass sie nicht von guter Laune abhängen:

Die Prüfstrecke läuft bei jeder Änderung. Eine Änderung wird erst ausgeliefert, wenn die Pflicht-Checks bestehen.
Für sicherheitskritischen Code gilt eine höhere Abdeckungsschwelle als für den Rest, und sie ist als Prüfung in der Pipeline verankert.
Der Abhängigkeits-Check läuft bei jeder Änderung, bei einem Release entsteht außerdem eine Stückliste der verwendeten Bibliotheken.
Das Mutation-Testing läuft monatlich als Bericht. Es blockiert keine Auslieferung, soll aber zeigen, wo Tests nachgezogen werden müssen.
Die Testlisten selbst werden geprüft: Es gibt Tests, die sicherstellen, dass genannte Tests existieren und nicht stillschweigend übersprungen werden.

Was wir nicht versprechen

Tests finden nicht jeden Fehler. Sie prüfen, was wir uns vorher überlegt haben.
Ein hoher Wert im Mutation-Testing zeigt, dass Tests Änderungen bemerken würden, aber nicht, dass sie fachlich das Richtige prüfen.
Das Mutation-Testing ist ein Bericht und keine Sperre in der Pipeline.
Die Prüfungen sind unsere eigene. Ein unabhängiger externer Penetrationstest hat bisher nicht stattgefunden.

Wie wir das prüfen

Ergebnisse und Kennzahlen stehen im Monatsbericht; auf dieser Seite nennen wir bewusst keine Zahlen, die veralten. Die Tabelle zeigt Tests, die die Prüfungen selbst absichern.

Nachweis-Tests

Test	Das belegt der Test
`FunctionalCoverageManifestTest`	Jede Anforderung aus dem Pflichtenheft hat mindestens einen Test, der sie ausdrücklich abdeckt.
`SecurityTestManifestCoverageTest`	Jede als Pflicht benannte Sicherheitstestklasse existiert wirklich als Datei.
`NoSkippedFunctionalTestsTest`	Funktionstests werden nicht stillschweigend übersprungen.
`RedTeamValidationCatalogCoverageTest`	Der Bericht nennt nur Testklassen, die es gibt.

Zum Bericht

Änderungsverlauf

28.10.2026: Erste Fassung.