Windows-Client, Web-Anwendung, KI und MCP im Zusammenspiel¶

Windows-Client, Web-Anwendung, KI-Dienste, MCP und Local Bridge greifen über unterschiedliche technische Wege auf Zeta Test Management zu. Windows- und Weboberfläche decken die fachlichen Testmanagement-Aufgaben auf derselben Projekt- und Berechtigungsbasis ab. KI, MCP und lokale Integrationen besitzen jeweils eigene Freigaben und technische Grenzen. Planen Sie jeden Zugangsweg als eigene Vertrauens-, Netzwerk- und Betriebsgrenze.

Aufgaben und Funktionsgrenzen¶

Der Windows-Client stellt den umfassenden Desktop-Umfang und lokale Integrationen bereit. Die Web-Anwendung bietet browserbasierte Fach-, Administrations- und KI-Arbeitsflächen. MCP automatisiert freigegebene Lese- und Schreib-Capabilities über dieselben Fachservices wie der Web-Chat. Local Bridge ergänzt ausschließlich durch die Kunden-IT erlaubte lokale Aktionen.

Eine kompakte Gegenüberstellung finden Sie unter Funktionen in Windows, Web, KI und MCP. Einrichtung und Bedienung der neuen Funktionen sind unter KI und Automatisierung beschrieben.

Architektur und Netzwerkgrenzen¶

Der Browser verbindet sich per HTTPS mit dem Host der Web-Anwendung. Er benötigt keinen direkten Zugriff auf Datenbank- oder Projektdateifreigaben.
Der Windows-Client wird je nach Betriebsmodell mit einem zentralen Backend verbunden oder verwendet eine unterstützte lokale Backend-Variante.
KI-Arbeitsflächen verwenden das serverseitige providerneutrale Gateway. Providerendpunkte und Geheimnisse bleiben in der Serveradministration; Datenzonen und Egress werden ausdrücklich freigegeben.
MCP verwendet den Web-Host über POST /mcp und eine eigene API-Schlüsselprüfung. Der MCP-Schlüssel ist nicht mit dem Backend-Schlüssel des Windows-Clients gleichzusetzen.
Local Bridge verbindet Chrome oder Edge über eine Browsererweiterung mit einem lokalen Native-Messaging-Host. Der Webserver startet keine freien lokalen Befehle; die IT-Richtlinie erlaubt nur benannte Aktionen.

Veröffentlichen Sie weder Datenbank noch Projektdateifreigaben direkt im Internet. Verwenden Sie kontrolliertes HTTPS, Firewall-Regeln und gegebenenfalls VPN oder Reverse Proxy. Dokumentieren Sie Datenflüsse, Datenzonen, Dienstkonten und Vertrauensgrenzen vor der Inbetriebnahme.

Gemeinsame Datenbasis und Berechtigungen¶

Windows- und Web-Anwendung arbeiten innerhalb der konfigurierten Projektgrenzen mit derselben fachlichen Datenbasis. Browser, KI-Provider und MCP greifen jedoch nicht direkt auf Datenbank oder Projektdateien zu, sondern über die vorgesehenen Serverkomponenten und berechtigungsgefilterten Fachservices.

Eine funktionierende Anmeldung oder API-Schlüsselprüfung ersetzt keine Projekt-, Rollen- oder Objektberechtigung. Für KI müssen außerdem globale Aktivierung, Szenariozuordnung, Datenfreigabe und Projekt-KI-Berechtigung passen. Schreibaktionen prüfen Berechtigung und Objektversion erneut beim Commit.

Trennen Sie Programmdateien, Projektdaten, Datenbank und Sicherungen. Vergeben Sie technischen Konten nur die notwendigen Rechte und speichern Sie Geheimnisse weder in Dokumentation noch in Diagnoseprotokollen.

Active-Directory- und LDAP-Anmeldung¶

Je nach Projekt- und Serverkonfiguration können Benutzer über integrierte Projektkonten oder ein angebundenes LDAP-Verzeichnis authentifiziert werden. Der Web-Host beziehungsweise die zuständige Anwendungskomponente muss den Verzeichnisdienst aus seiner Netzwerkzone erreichen können; Rollen und Projektrechte werden weiterhin in Zeta Test Management ausgewertet.

Ein eigener IIS-Mechanismus für NTLM oder Kerberos ist dafür nicht grundsätzlich erforderlich, sofern die Anwendung die LDAP-Anmeldung übernimmt. Wenn Ihre Zielarchitektur Windows-Authentifizierung, Single Sign-on oder einen vorgeschalteten Identity-Proxy vorsieht, muss diese Variante separat geplant und abgenommen werden. Bevorzugen Sie verschlüsselte LDAP-Verbindungen und prüfen Sie Zertifikatsvertrauen, Gruppenauflösung und Ausfallverhalten.

Backend-Konnektivität des Windows-Clients¶

Der Windows-Client kann gegen eine zentrale Backend-URL mit zugehörigem Backend-API-Schlüssel konfiguriert werden. Hinterlegen Sie die Werte in den dafür vorgesehenen Programmoptionen oder einer verwalteten Konfiguration, verwenden Sie ausschließlich HTTPS und setzen Sie in Dokumentation nur Platzhalter wie https://backend.example.org/ und <backend-api-key> ein.

Bei unterstützten lokalen Betriebsarten kann der aktuelle Client ohne konfigurierte zentrale Backend-URL einen mitgelieferten lokalen Kestrel-Host für lokale Vorgänge starten. Diese lokale Variante ist keine Empfehlung, einen Dienst ungeprüft nach außen zu öffnen. Netzwerkzugriff, Bindung, Zertifikate und Lebenszyklus müssen zum gewählten Betriebsmodell passen.

Der Backend-API-Schlüssel des Windows-Clients und ein MCP-API-Schlüssel erfüllen unterschiedliche Aufgaben und dürfen nicht verwechselt oder wiederverwendet werden. Schützen und rotieren Sie beide Geheimnisse, protokollieren Sie keine vollständigen Werte und sperren Sie nicht mehr benötigte Schlüssel.