Installation und Konfiguration von Zeta Test Management Web¶

Zeta Test Management Web stellt zentrale Testprojekte im Browser bereit. Die Anwendung basiert auf ASP.NET Core und .NET 10. Windows-Anwendung und Weboberfläche greifen auf dieselben Projekte zu und decken die fachlichen Testmanagement-Aufgaben ab. Lokale Betriebssystemfunktionen werden browsergerecht umgesetzt oder über eine freigegebene Local Bridge angebunden.

Für einen produktiven zentralen Betrieb verwenden Sie das IIS-Paket zetatest-web.zip. Das separate Web-EXE-Setup richtet eine lokale Demo-/Einzelplatzvariante mit Kestrel ein; es ersetzt keine abgesicherte IIS-Installation.

Diese Anleitung beschreibt die produktive Bereitstellung, HTTPS, Berechtigungen, Konfigurationsdateien, Updates und optionale Client-/Server-Pfadzuordnungen.

Bereitstellungsvarianten¶

Wählen Sie die Bereitstellungsform vor der Installation bewusst aus:

Lokale Demo-/Einzelplatzvariante: Das Web-EXE-Setup startet die mitgelieferte Webanwendung lokal über Kestrel. Diese Variante eignet sich für Evaluierung und einen einzelnen Windows-Benutzer, nicht als zentraler Produktionsserver.
Zentrale IIS-Variante: Entpacken Sie zetatest-web.zip auf einem Windows Server und betreiben Sie den enthaltenen Ordner Website als IIS-Anwendung. Dies ist der empfohlene Produktionsweg.
Reverse Proxy: Ein vorgeschalteter Proxy kann TLS terminieren und die Anwendung veröffentlichen. Proxy, Weiterleitungen und vertrauenswürdige Header müssen dabei bewusst administriert und getestet werden.

Halten Sie Programmdateien, Konfiguration, Protokolle und Projektdaten in klar getrennten, gesicherten Pfaden. Das erleichtert Updates und Rollbacks.

Funktionsumfang und Bereichsfreigaben¶

Die Weboberfläche deckt Anforderungen, Testbibliothek, Planung, Ausführung, Reviews, Auswertung, Berichtsdesign und Administration ab. Die regulären Webbereiche sind in Version 6 standardmäßig aktiviert. Der historisch benannte Konfigurationsbereich AppSettings.ExperimentalWebAreas kann einzelne Bereiche administrativ abschalten; sein Name kennzeichnet keinen allgemeinen Vorabstatus.

Prüfen Sie beim Rollout die vorgesehenen Aufgaben mit repräsentativen Rollen und Daten. KI wird unabhängig von den normalen Webbereichen eingerichtet und freigegeben. Für konkrete lokale Windows-Funktionen siehe Funktionsumfang.

Voraussetzungen und Vorbereitungen¶

Prüfen Sie vor der Installation die jeweils aktuellen Systemvoraussetzungen. Für die aktuelle Auslieferung benötigen Sie insbesondere:

einen unterstützten Windows Server, derzeit Windows Server 2019 oder 2022, mit aktuellen Sicherheitsupdates;
Microsoft IIS und administrative Rechte für die Einrichtung von Site, Anwendungspool, Bindings und Zertifikat;
das zum Zeta-Test-Management-Release passende Microsoft-.NET-10-Hosting-Bundle; es installiert auch das ASP.NET Core Module V2 für IIS;
einen stabilen DNS-Namen und ein vertrauenswürdiges TLS-Zertifikat für HTTPS;
eine gesicherte Projekt- und Datenbankbasis; für den Webbetrieb wird Microsoft SQL Server 2017 oder neuer empfohlen;
eine eigene technische Identität mit nur den erforderlichen Datei- und Datenbankrechten.

Legen Sie vor der ersten Bereitstellung Backup, Wiederherstellung, Updatefenster und einen technischen Verantwortlichen fest.

Erstinstallation mit dem IIS-Paket¶

Installieren Sie IIS und anschließend das zum Release passende .NET-10-Hosting-Bundle. Starten Sie den Server neu, wenn das Hosting-Bundle dies verlangt.
Entpacken Sie zetatest-web.zip zunächst in einen Staging-Ordner. Der IIS-Pfad zeigt später auf den enthaltenen Ordner Website.
Konfigurieren Sie Config.json, appsettings.json und bei Bedarf foldermappings.json. Verwenden Sie für produktive Projekte einen stabilen Datenpfad außerhalb des austauschbaren Release-Ordners.
Erstellen Sie einen eigenen IIS-Anwendungspool mit „Kein verwalteter Code“. Setzen Sie „32-Bit-Anwendungen aktivieren“ auf False und weisen Sie eine dedizierte Identität zu.
Erstellen Sie die IIS-Site beziehungsweise -Anwendung mit dem physischen Pfad zum Ordner Website. Die ausgelieferte web.config mit AspNetCoreModuleV2 bleibt maßgeblich.
Vergeben Sie die benötigten Datei- und Datenbankrechte und richten Sie das HTTPS-Binding mit dem vorgesehenen Zertifikat ein.
Starten Sie Anwendungspool und Site. Öffnen Sie die HTTPS-Adresse zuerst als Administrator und prüfen Sie Startseite, Anmeldung, Projektliste und ein freigegebenes Testprojekt.

Gehen Sie erst nach erfolgreichem Pilotbetrieb in den breiten Rollout.

Update und Rollback¶

Behandeln Sie ein Webupdate wie eine kontrollierte Serveränderung:

Sichern Sie Projekte, Datenbank, Websitekonfiguration und gegebenenfalls Protokolle. Notieren Sie die bisherige Produktversion und den aktiven Websitepfad.
Entpacken Sie das neue zetatest-web.zip in einen parallelen Release-Ordner.
Übernehmen Sie Config.json, appsettings.json und foldermappings*.json nicht blind. Vergleichen Sie die neuen Standarddateien und führen Sie Ihre umgebungsspezifischen Werte kontrolliert zusammen. Verwenden Sie die neue ausgelieferte web.config.
Stoppen Sie den Anwendungspool, schalten Sie den IIS-Pfad auf den neuen Ordner Website um und starten Sie den Pool wieder.
Prüfen Sie HTTPS, Anmeldung, Projektliste, Rechte und einen typischen Testablauf. Beobachten Sie Ereignisanzeige und aktivierte Anwendungsprotokolle.

Für den Rollback stoppen Sie den Pool, stellen den vorherigen Websitepfad und bei notwendigen Datenmigrationen auch die dazugehörige Datensicherung wieder her. Löschen Sie den vorherigen Release-Ordner erst nach dem vereinbarten Rückfallzeitraum.

IIS und HTTPS konfigurieren¶

Anwendungspool: „Kein verwalteter Code“, 32-Bit-Anwendungen deaktiviert, eigene Identität und ein zur Betriebsplanung passender Startmodus.
ASP.NET Core: Das .NET-Hosting-Bundle stellt AspNetCoreModuleV2 bereit. Wenn das Modul fehlt, reparieren oder installieren Sie das Hosting-Bundle und starten IIS beziehungsweise den Server neu.
Physischer Pfad: Verweisen Sie auf den Ordner Website des aktiven Releases. Die Projekte selbst liegen nicht im öffentlich auslieferbaren Websitepfad.
HTTPS: Binden Sie den produktiven DNS-Namen an Port 443 und ein vertrauenswürdiges Zertifikat. HTTP bleibt höchstens als ausdrücklich konfigurierter Redirect-Endpunkt bestehen.
Anwendungseinstellungen: Bei direkter HTTPS-Terminierung in IIS können Sie UseHttpsRedirection aktivieren und AllowInsecureCookies deaktivieren. Bei einem Reverse Proxy muss die Weiterleitung am Proxy und in der gesamten Kette getestet werden.

Das IIS-Modul „URL Rewrite“ ist keine Voraussetzung von Zeta Test Management Web. Setzen Sie es nur ein, wenn Ihre eigene Redirect- oder Proxykonfiguration es benötigt.

Berechtigungen nach dem Least-Privilege-Prinzip¶

Vergeben Sie der Anwendungspool-Identität nur die tatsächlich benötigten Rechte:

Programmordner: Lesen und Ausführen auf dem aktiven Ordner Website.
Projektwurzeln: Ändern auf den in projectSearchFolderPaths freigegebenen Projekten, soweit die vorgesehenen Webfunktionen schreiben müssen.
Benutzerablagen, Anhänge und Protokolle: Ändern nur auf den hierfür konfigurierten Ordnern.
SQL Server: Ein eigenes Login beziehungsweise Dienstkonto mit den für die verwendeten Datenbanken erforderlichen, minimalen Rechten.

Für UNC-Pfade verwenden Sie eine Domänen- oder Dienstidentität, die den Share und die NTFS-Rechte tatsächlich besitzt. Vermeiden Sie persönliche Administratorenkonten und globale Vollzugriffe.

Sicherheitsgrenze: Projektdateien, Konfigurationsdateien, Backups und Protokolle dürfen nicht als statische Dateien über die Website erreichbar sein.

Config.json und appsettings.json konfigurieren¶

Config.json enthält die klassischen Zeta-Test-Management-Anwendungseinstellungen. Mehrere Projektwurzeln in projectSearchFolderPaths werden durch Semikolon getrennt:

{
  "settings": [
    {
      "name": "projectSearchFolderPaths",
      "value": "D:\\ZetaTest\\Projects;\\\\fileserver\\ZetaTest\\Projects"
    },
    {
      "name": "alternativeCurrentUserStorageBaseFolderPath",
      "value": "D:\\ZetaTest\\UserStorage"
    },
    {
      "name": "forbiddenProjectNames",
      "value": "Archive;Templates"
    }
  ]
}

appsettings.json steuert ASP.NET-Core-Funktionen, unter anderem HTTPS, Cookies, Logging, Sprache und Bereichsfreigaben:

{
  "AppSettings": {
    "UseHttpsRedirection": true,
    "AllowInsecureCookies": false,
    "ExperimentalWebAreas": {
      "Enabled": true,
      "DisabledAreas": []
    }
  }
}

Die Werte sind Beispiele und müssen zu Ihrer Topologie passen. Lassen Sie nicht benötigte Auto-Login-Optionen deaktiviert. Behandeln Sie serviceApiKey und andere Schlüssel als Geheimnisse; legen Sie sie weder in öffentlich erreichbaren Ordnern noch in einer ungeschützten Versionsverwaltung ab.

Nach Änderungen recyceln Sie gezielt den Anwendungspool und prüfen die Startseite sowie die betroffenen Funktionen.

Schutz vor wiederholten Anmeldeversuchen¶

Dieser Schutz benötigt einen entsprechend aktualisierten Web-Server-Build. Eine Konfigurationsänderung allein ergänzt ihn nicht in älteren Installationen.

Die Kennwortanmeldungen für Serveradministration und Projekte begrenzen wiederholte Fehlversuche pro Konto und unabhängig davon pro IP-Adresse. Fünf Fehlversuche lösen noch keine Wartezeit aus; mit dem sechsten Fehlversuch beginnt eine Wartezeit von zwei Sekunden. Weitere Fehlversuche verlängern sie auf vier, acht Sekunden und so weiter, höchstens fünf Minuten. Eine erfolgreiche Anmeldung setzt nur den Kontozähler zurück. Die IP-Begrenzung bleibt bestehen, damit ein gültiges Konto sie nicht umgehen kann.

Während einer Wartezeit zeigt das Formular einen Hinweis; die Antwort enthält HTTP 429 und Retry-After. Auch ein inzwischen korrektes Kennwort kann erst nach Ablauf erneut geprüft werden. Es gibt keine dauerhafte Kontosperre. Nach 30 Minuten ohne zugelassenen Versuch verfallen die Zähler. Abgewiesene Versuche verlängern die Wartezeit nicht. Pro IP sind außerdem höchstens 30 zugelassene Versuche innerhalb von 60 Sekunden möglich; ab dem 21. Fehlversuch greift auch die steigende IP-Wartezeit. Bei vielen Nutzern hinter einer gemeinsamen Adresse berücksichtigen Sie diese gemeinsamen Grenzen.

Die Konfiguration steht unter AppSettings.LoginProtection in appsettings.json:

{
  "AppSettings": {
    "LoginProtection": {
      "Enabled": true,
      "FreeAttempts": 5,
      "IpFreeAttempts": 20,
      "BaseDelaySeconds": 2,
      "MaxDelaySeconds": 300,
      "EntryExpirationMinutes": 30,
      "IpPermitLimit": 30,
      "IpWindowSeconds": 60,
      "MaxEntries": 10000,
      "InFlightSeconds": 120
    }
  }
}

InFlightSeconds begrenzt eine reservierte, noch nicht abgeschlossene Kennwortprüfung. Gleichzeitige Prüfungen desselben Kontos sind gesperrt; nach einem Prozessabbruch wird der reservierte Versuch als fehlgeschlagen gewertet. MaxEntries begrenzt die gespeicherten Konto- und IP-Einträge zusammen. Die Aufbewahrungszeit muss mindestens so lang wie die maximale Wartezeit, das IP-Zeitfenster und die Reservierung sein. Ungültige Werte werden abgewiesen. Änderungen benötigen einen Neustart der Webanwendung.

Die Zähler liegen dauerhaft im Unterordner LoginProtection des privaten Administrationsdatenordners. Bei Bedarf setzt AppSettings.LoginProtectionStateDirectory einen absoluten anderen Pfad außerhalb des Webroots. Alle Worker derselben Installation müssen denselben dauerhaften Ordner verwenden und dort Änderungsrechte besitzen. Die Datei enthält abgeleitete Kennungen, keine Klartextbenutzernamen oder IP-Adressen. Löschen Sie sie nicht beim Update. Liegt der Administrationsdatenordner innerhalb des Programmverzeichnisses, konfigurieren Sie vor einem Austausch dieses Verzeichnisses einen getrennten dauerhaften Speicherpfad. Ein nicht verfügbarer, voller oder beschädigter Speicher führt sicherheitshalber zu HTTP 503 statt einer ungeschützten Kennwortprüfung; prüfen Sie dann Speicherplatz, Rechte und Serverprotokoll.

Die Dateispeicherung ist für Worker auf demselben Server vorgesehen. Für mehrere Webserver ergänzen Sie eine gemeinsame Begrenzung am vertrauenswürdigen vorgeschalteten Dienst. Hinter einem Reverse Proxy muss die tatsächliche Client-IP durch die Hosting-Konfiguration vertrauenswürdig übermittelt werden. Beliebige X-Forwarded-For-Header werden nicht als Identitätsnachweis verwendet.

Der Schutz betrifft eigene Browser-Kennwortformulare. Die automatische Windows-zu-Web-Anmeldung mit Einmaltoken, eine ausdrücklich konfigurierte kennwortfreie Demo und Projekte ohne Benutzerverwaltung erhalten dadurch keine zusätzliche Kennwortabfrage. API-Schlüssel und externe Identitätsanbieter besitzen eigene Sicherheitsgrenzen. Der Schutz ersetzt weder HTTPS noch starke Kennwörter oder einen abgesicherten Serverzugang.

Client-/Server-Pfade mit foldermappings.json zuordnen¶

foldermappings.json ist nur erforderlich, wenn ein vom Windows-Client übertragener Projektpfad auf dem Webserver anders lautet. Die Anwendung ersetzt den passenden Anfang des Clientpfads durch den Serverpfad:

{
  "startsWithMappings": [
    {
      "client": "\\\\fileserver\\ZetaTest",
      "server": "D:\\ZetaTest"
    }
  ]
}

Im Beispiel wird \\fileserver\ZetaTest\ProjektA auf D:\ZetaTest\ProjektA abgebildet. Beide Pfade müssen dasselbe Projekt bezeichnen; Groß-/Kleinschreibung ist unter Windows nicht ausschlaggebend.

Legen Sie die Datei im Ordner Website ab.
Verwenden Sie möglichst wenige, eindeutige Präfixe und vermeiden Sie überlappende Zuordnungen.
Prüfen Sie die Zielpfade aus Sicht der Anwendungspool-Identität.
Recyceln Sie nach einer Änderung den Anwendungspool; ein pauschales IISRESET ist nicht erforderlich.