1. Einleitung

In Userstory U0820 wurde der Registrierungsdienst mit eingeschränkter Funktionalität implementiert und auf Openshift deployt. Auf dem Stand von U0820 stellt der Registrierungsdienst zwei Endpunkte für die Stufen 1 und 3 der Berechtigungsprüfung bereit. Diese Endpunkte sollen hier auf ihre Korrektheit geprüft werden. Da es sich um Endpunkte der Schnittstelle zwischen Registrierungsdienst und Messenger-Proxy handelt, existiert keine UI. Die Endpunkte müssen also manuell (z.B. via RESTer, curl, Entwicklertools eines Browsers) aufgerufen werden.

In der Folgestory U0830 wurde der Endpunkt für Stufe 2 der Berechtigungsprüfung sowie die Schnittstelle "I_TiMessengerContactManagement" implementiert.

Mit der Userstory U0846 wurden das Personen- und Organsisationsverzeichnis entfernt, sodass der Registrierungsdienst nur noch die Föderationsliste beim VZD-FHIR-Directory abfragt und die neuste Liste unter einem REST-Endpunkt anbietet. Eine Datenbankanbindung muss nicht mehr vorliegen, da die zuvor persistierte Freigabeliste nicht mehr gepflegt wird, sondern nur noch die Föderationsliste, dessen Datenhaltung transient ist.

In Userstory EGK-8520 wurde mit den Endpunkten zur Messenger-Service-Verwaltung der erste Teil der Org-Admin-API ("I_Admin") implementiert. Diese Endpunkte erlauben die Modifizierung von Messenger-Service-Einträgen in der DB des Registrierungsdienstes.

Mit Userstory EGK-8560 wurde der Prozess zum Anlegen neuer Org-Admin-Accounts im Registrierungsdienst-IDP umgesetzt. Dafür wurde ein Endpunkt implementiert sowie das Frontend des Registrierungsdienstes erstellt, welches den Nutzer beim Aufruf dieses Endpunkts führt.

2. Vorbereitende Maßnahmen

Der zu testende Registrierungsdienst muss in einer Openshift-Umgebung deployt sein. Zusätzlich muss ein FHIR-Proxy, der die Daten für die Berechtigungsprüfung bereitstellt, verfügbar sein. Außerdem ist ein IDP nötig, mit dem sich der Registrierungsdienst beim FHIR-Proxy authentifizieren kann und somit Zugriff auf die relevanten Daten erhält.

In der Openshift-Umgebung tim-global-development sind schon alle nötigen Komponenten vorhanden und konfiguriert. Die Verfügbarkeit kann mit folgenden Links geprüft werden:

Komponente Basis-URL Health-Check

Registrierungsdienst

https://fachdienst-tim-registrierungsdienst-tim-global-development.apps.ocp01.dev.21c.ads

Link

FHIR-Proxy-Mock

https://testumgebung-tim-vzd-fhir-proxy-mock-tim-global-development.apps.ocp01.dev.21c.ads

Link

TIM-Keycloak (IDP)

https://testumgebung-tim-keycloak-tim-global-development.apps.ocp01.dev.21c.ads

-

Zusätzlich muss eine Postgres-Datenbank zur Verfügung stehen und passend im Registrierungsdienst konfiguriert sein.

3. Testfälle

Um die Tests möglichst klar zu gestalten, folgen die Beschreibungen der auszuführenden Schritte einer festgelegten Struktur und nutzen Schlüsselwörter. Jeder Schritt besteht aus ein oder zwei Teilen: Jeder Schritt beginnt mit der Beschreibung einer oder mehrerer Aktionen, die der Tester ausführen soll. Diese Aktionsbeschreibung ist mit dem Schlüsselwort "soll" markiert. Meist folgt darauf die Beschreibung einer erwarteten Reaktion des zu testenden Systems. Diese Reaktionsbeschreibung ist mit dem Schlüsselwort "muss" oder "darf nicht" markiert. Stimmt die beobachtbare Reaktion nicht mit der erwarteten Reaktion überein, gilt der Testschritt als "nicht bestanden".

3.1. Testfall 1: Föderationsliste (Berechtigungsprüfung Stufe 1)

Der Endpunkt zum Abruf der Föderationsliste findet sich unter dem Pfad

/federationList

3.1.1. Vorbereitung

Die Föderationsliste des FHIR-Proxys darf keinen Eintrag enthalten. Einträge können über die UI des FHIR-Proxy-Mocks erzeugt und gelöscht werden.

Der zu testende Endpunkt gibt Föderationslisten zurück. Die JSON-Repräsentation einer solchen Liste hat folgenden Aufbau:

Listing 1. Beispiel der JSON-Repräsentation einer Föderationsliste
{
  "version": 1,
  "domainList": [
    {
      "domain": "example.com",
      "telematikID": "id",
      "isInsurance": false,
      "timProvider": "provider"
    }
  ]
}

3.1.2. Durchführung

  1. Der Endpunkt zum Abruf der Föderationsliste soll aufgerufen werden. (Link für tim-global-development). Das zurückgegebene JSON-Objekt muss die Felder vorgangsId, returnCode und result enthalten. Die Werte aller dieser Felder dürfen nicht NULL sein. Das Feld result muss die Föderationsliste enthalten. Das Feld version dieser Föderationsliste muss als Wert eine Zahl größer 0 haben. Diese Föderationsliste darf keine Domains enthalten (da auch die Liste des FHIR-Proxys keine Einträge enthält).

  2. Eine Domain soll der Föderationsliste des FHIR-Proxy-Mocks hinzugefügt werden.

  3. Der Endpunkt zum Abruf der Föderationsliste soll erneut aufgerufen werden. Die zurückgegebene Liste muss nun den gerade hinzugefügten Eintrag enthalten und muss als Version einen Wert haben, der exakt um eins größer ist als die Version der Liste der vorhergegangenen Anfrage.

3.1.3. Nachbereitung

3.2. Testfall 2: Org-Admin-API: DB-Anlage und -Synchronisierung

Die DB des Registrierungsdienstes wird durch Liquibase-Jobs angelegt und migriert, die als ArgoCD-PreSync-Hooks ausgeführt werden. Die Synchronisierung der DB erfolgt im Rahmen einer Startup-Probe, die in Kubernetes-Umgebungen automatisch beim Start des Containers vom Kubernetes-Controller aufgerufen wird. In diesem Testfall wird diese Initialisierung der DB geprüft.

3.2.1. Vorbereitung

Um den gesamten Prozess (erneut) durchführen zu können, muss die Registrierungsdienst-DB in den passenden Ausgangszustand versetzt werden. Dafür kann einer der folgenden Wege gewählt werden:

  • Liquibase-Rollback: Sofern Zugriff auf Liquibase und die korrekten Changelog-Dateien besteht, kann der Ausgangszustand mit einem einzelnen Rollback-Befehl erzeugt werden. Da die Changesets keine Tags setzen, muss hier gegebenenfalls der Befehl liquibase rollback-to-date genutzt werden.

  • Manuelle Löschung: Falls Liquibase nicht zur Verfügung steht, kann der Ausgangszustand auch mit zwei SQL-Befehlen erreicht werden. Dafür muss einerseits in der Tabelle liquibase.databasechangelog die Zeile mit der ID create-messenger-service-table gelöscht werden und andererseits die Tabelle regdienstdb.messenger_service vollständig gedroppt werden.

3.2.2. Durchführung

  1. Ein ArgoCD-Sync SOLL ausgelöst werden. Die Liquibase-Jobs des Registrierungsdienstes MÜSSEN ausgeführt werden. Nach Beendigung des Syncs MUSS die Tabelle regdienstdb.messenger_service existieren und leer sein.

  2. Ein Registrierungsdienst-Pod SOLL gelöscht werden. Nachdem der deshalb von Kubernetes gestartete Pod erfolgreich gestartet wurde, MUSS die Tabelle regdienstdb.messenger_service Einträge für jeden im gitops-Repo (values-mandanten.yaml) konfigurierten Messenger-Service enthalten.

  3. Ein beliebiger Eintrag SOLL direkt in der DB gelöscht werden und für einen anderen Eintrag SOLL der Wert der Spalte mandant_ik auf einen nicht im gitops-Repo vorhandenen Wert verändert werden. Danach SOLL erneut ein Registrierungsdienst-Pod gelöscht werden. Nach dem erfolgreichen Neustart MUSS der Inhalt der Messenger-Service-Tabelle wieder korrekt sein.

In diesem Produkttest wird nur die Synchronisierung der DB und nicht die Funktionalität der implementierten Endpunkte getestet. Die Endpunkte sind Teil eines größeren Features "Org-Admin-API", das nach der Umsetzung des Org-Admin-Clients integrativ getestet werden wird. Die isolierte Funktionalität der Endpunkte wird bereits in Unit-Tests geprüft.

3.2.3. Nachbereitung

3.3. Testfall 4: Testen der Org-Admin-Endpunkte

In diesem Testfall wird die User-Story EGK-8532 geprüft, die die Implementierung der Org-Admin-Endpunkte im Registrierungsdienst umfasst. Ziel dieses Tests ist es, sicherzustellen, dass Org-Admins die Matrix-User-Accounts auf ihren Matrix-Homeservern über die Org-Admin-API verwalten können. Zu den zu prüfenden Funktionen gehört unter anderem die Möglichkeit, die Sessions eines Nutzers einzusehen und diese zu beenden (auszuloggen).

3.3.1. Vorbereitung

Vor der Durchführung dieses Tests müssen folgende Voraussetzungen erfüllt sein:

  1. Ein Org-Admin-Account für den jeweiligen Messenger-Service muss vorhanden sein.

  2. Ein Synapse-Admin ist erforderlich. Diese Rolle ist derzeit nur für Sachbearbeiter-Instanzen verfügbar. Daher sollte die Testausführung auf einer SB-Instanz erfolgen, z.B.: tim-242424244-sb-tim-global-development.apps.ocp01.dev.21c.ads.

  3. Für die Testdurchführung wird die Firefox-Erweiterung Rester verwendet.

3.3.2. Durchführung

Generierung OAuth 2 Token

Die Rester Erweiterung SOLL geöffnet werden.

Unter Authorization → Create New Configuration → OAuth 2 MUSS eine neue OAuth 2 Konfiguration erstellt werden.

Die Konfiguration SOLL wie folgt ausgefüllt werden:

Einstellung Wert

OAuth-Flow

Authorization Code

Authorization Request Endpoint

https://tim-dev-regd-idp-tim-global-development.apps.ocp01.dev.21c.ads/realms/org-admin/protocol/openid-connect/auth

Access Token Request Method

POST

Access Token Request Endpoint

https://tim-dev-regd-idp-tim-global-development.apps.ocp01.dev.21c.ads/realms/org-admin/protocol/openid-connect/token

Access Token Request: Client Authentication

NONE

Client ID

org-admin-client

Redirect URL

https://tim-dev-regdienst-tim-global-development.apps.ocp01.dev.21c.ads/

Nachdem die Konfiguration gespeichert wurde, MUSS diese ausgewählt werden und die Daten des ORG-Admin Accounts einmalig eingegeben werden. Das OAuth 2 Token MUSS erfolgreich generiert werden.

Nach der erfolgreichen Token-Generierung SOLLEN die folgenden Endpunkte in der angegebenen Reihenfolge aufgerufen werden. Dabei ergibt sich der Aufruf stets aus der Route des Frontend des Registrierungsdienstes + Endpunkt.

Die URL des Frontends für den Regdienst lautet beispielsweise: https://tim-dev-regdienst-tim-global-development.apps.ocp01.dev.21c.ads/

3.3.3. 1. Benutzer einer Domain abrufen

Um alle Benutzer einer Domain abzurufen, SOLL der folgende Endpunkt aufgerufen werden:

Url des Frontends + /org-admin/v1/domains/{domain}/users`

Einstellung Wert

Methode

GET

Parameter

Domain (z.B. tim-242424244-sb-tim-global-development.apps.ocp01.dev.21c.ads)

Response

Gibt alle Benutzer zurück, die der Domain zugeordnet sind.

3.3.4. 2. Einzelnen Benutzer abrufen

Um einen einzelnen Benutzer abzurufen, SOLL der folgende Endpunkt aufgerufen werden:

Url des Frontends + /org-admin/v1/domains/{domain}/users/{user_id}`

Einstellung Wert

Methode

GET

Parameter

Domain, UserId (z.B. @user:tim-242424244-sb-tim-global-development.apps.ocp01.dev.21c.ads)

Response

Gibt einen einzelnen Benutzer zurück.

3.3.5. 3. Benutzer-Sessions abrufen

Um alle Sessions eines Benutzers abzurufen, SOLL der folgende Endpunkt aufgerufen werden:

Url des Frontends + /org-admin/v1/domains/{domain}/users/{user_id}/sessions`

Einstellung Wert

Methode

GET

Parameter

Domain, UserId

Response

Gibt die Sessions zurück, an denen der Benutzer angemeldet ist.

3.3.6. 4. Geräte eines Benutzers abrufen

Um alle Geräte eines Benutzers abzurufen, SOLL der folgende Endpunkt aufgerufen werden:

Url des Frontends + /org-admin/v1/domains/{domain}/users/{user_id}/devices`

Einstellung Wert

Methode

GET

Parameter

Domain, UserId

Response

Gibt alle Geräte zurück, mit denen sich der Benutzer angemeldet hat.

3.3.7. 5. Gerät eines Benutzers löschen

Um ein Gerät eines Benutzers zu löschen, SOLL der folgende Endpunkt aufgerufen werden:

Url des Frontends + /org-admin/v1/domains/{domain}/users/{user_id}/devices/{device_id}`

Einstellung Wert

Methode

DELETE

Parameter

Domain, UserId, DeviceId

Response

Löscht das Gerät eines Benutzers.

3.3.8. 6. Systemmeldung versenden

Um eine Systemmeldung zu versenden, SOLL der folgende Endpunkt aufgerufen werden:

Url des Frontends + /org-admin/v1/domains/{domain}/notification`

Einstellung Wert

Methode

POST

Parameter

Domain

Header

Content-Type: application/json

JSON-Body

{ "user_id": "@user:tim-242424244-sb-tim-global-development.apps.ocp01.dev.21c.ads", "content": { "msgtype": "m.text", "body": "Das ist meine Nachricht" } }

Response

Versendet eine Benachrichtigung an den User und gibt eine Event-Id zurück.