-
Notifications
You must be signed in to change notification settings - Fork 0
Testdrehbuch
Prahbdip Singh edited this page May 23, 2026
·
45 revisions
Hinweis: Diese Vorlage versteht sich als Basis und dient der Strukturierung des Testdrehbuchs und des zugehörigen Testprotokolls. Diese Seite definiert die Testdurchführung für die Integrationstests (und ist ein Vorschlag für die Abnahmetests). Zielgruppe sind die Verantwortlichen für die Durchführung der Integrationstests. Dieses Dokument kann durch Ergänzung der Abschnitte 2 und 4 auch als Testprotokoll verwendet werden.
Noch ein Hinweis:Eine Wiki-Seite eignet sich nicht gut für ein Testprotokoll. Sie können den Inhalt der Seite in einen Issue kopieren. Dann funktionieren auch die Check-Boxes zu den beobachteten Abweichungen.
[[TOC]]
Beschreiben Sie die erforderlichen Vorbereitungsschritte zur Ausführung der hier angeführten Tests. Eine beispielhafte Aufstellung ist nachfolgende angeführt.
Zu Testbeginn sind folgende Nutzer eingerichtet:
| Benutzer/Passwort | Rollen | Abteilung | Anmerkung |
|---|---|---|---|
| admin / passwd | SYSTEM_ADMIN, EMPLOYEE | Research (2) | Haupt-Adminkonto |
| user1 / passwd | MANAGEMENT, EMPLOYEE | Research (2) | Management-Sicht |
| user2 / passwd | EMPLOYEE | Research (2) | Einfacher Mitarbeiter |
| elvis / passwd | SYSTEM_ADMIN, EMPLOYEE | Management | Zweiter Admin |
| anna / passwd | EMPLOYEE, DEPARTMENT_LEAD | Engineering | Lead Engineering |
| ben / passwd | EMPLOYEE | Engineering | Büro: Eng Office A |
| clara / passwd | EMPLOYEE | Engineering | Büro: Eng Office B |
| david / passwd | EMPLOYEE | Engineering | Büro: Eng Office B |
| eva / passwd | EMPLOYEE, BUILDING_ADMIN | HR | Gebäude-Admin |
| felix / passwd | EMPLOYEE | HR | Büro: HR Office A |
| greta / passwd | EMPLOYEE, DEPARTMENT_LEAD | HR | Lead HR |
| hans / passwd | EMPLOYEE | Management | Büro: Mgmt Office A |
| iris / passwd | EMPLOYEE, MANAGEMENT | Management | Management-Sicht |
| jonas / passwd | EMPLOYEE | Management | Büro: Mgmt Office B |
Initialer Testdatenbestand: (Beispiele)
- Adressen: Primary Address (Italy), Campus West Austria, Main Campus Austria, HQ South Germany
- Gebäude: Still OLD IT, Tech Tower, Main Office, South HQ
- Abteilungen: Research (2), Sales, Engineering, HR, Management
- Räume: Room 1 (OFFICE), Common Area 1/2 (COMMON_AREAS), Eng Office A/B/C, Eng Common Area, HR Office A/B, HR Common Area, Mgmt Office A/B, Mgmt Common Area, Sales Office A, Sales Common Area
- Sensorstationen: Station A (Room 1), Station B (Common Area 1), Eng-A-S1, Eng-B-S1, HR-A-S1, HR-B-S1, Mgmt-A-S1, Sales-A-S1 etc.
- Messwerte: Temperatur, Luftfeuchtigkeit, IAQ und Druck für alle büroähnlichen Räume vom 23.01.2026 bis 23.04.2026
- Schwellenwerte: TEMPERATURE (UPPER/LOWER), HUMIDITY, IAQ je Raum; teils deaktiviert
- Aktive Verletzungen: Room 1 HUMIDITY, Eng Office A IAQ, Eng Office B HUMIDITY, HR Office A HUMIDITY, Sales Office A TEMPERATURE etc.
- Klimahinweise: 2 bestehende + 7 erweiterte Hinweise für verschiedene Metriken
-
Hinweis: Alle Testdaten werden sollten automatisch nach
docker compose up --buildvon derdata-prod.sqlin die Datenbank gespeichert werden.
Hinweis: Sie sollten diese Daten zusätzlich in Form eines einfach zu importierenden Datenbank-Dumps bereitstellen.
Die Integrationstests können gestartet werden, wenn
- Alle Unit-Tests erfolgreich und vollständig ausgeführt wurden.
- Die Datenbank mit dem beschriebenen initialen Testdatenbestand befüllt ist. Dies sollte automatisch erfolgen.
- Die Anwendung lokal oder auf dem Testserver erreichbar ist (
http://localhost:8080).
Dieser Abschnitt soll bei Testdurchführung ausgefüllt werden
- Testdatum: (wann wurde getestet? ggf. Zeitraum)
- Tester: (wer hat getestet)
- Getestete Version: (z.B. GIT Tag)
- Testeingangskriterien erfüllt: ja/nein laut (Verweis auf E-Mail der Entwickler, Maventestprotokoll, ...)
- Testumgebung: (z.B. Anwendung lokal auf eigenem Rechner, Datenbank auf Server)
Hinweis: Die nachfolgenden Testfälle sind nur Beispiele. Erweitern Sie die Testfälle entsprechend Ihrer Konzeptbeschreibung und insbesondere der darin angeführten Use Cases. Vergessen Sie nicht darauf auch allgemeine (Filterung, Sortierung, etc.) funktionale und nicht-funktionale (Antwortzeiten, Stabilität, etc.) Anforderungen mit Ihren Testfällen abzudecken.
Die hier beschriebenen Testfälle decken die in der Konzeptbeschreibung angeführten Use Cases vollumfänglich ab. Weitere Testfälle wurden zur Überprüfung allgemeiner funktionaler Anforderungen ergänzt. Abweichungen von den erwarteten Ergebniszuständen wurden im Rahmen des durchgeführten Tests (vgl. ABschnitt 2, Testprotokoll) dokumentiert und entsprechend der nachfolgenden Einstufungen klassifiziert.
- OK: Keine Abweichungen gefunden.
- Kosmetische Abweichungen: Kleinere Layout Probleme: z.B. Zeilenumbrüche im TExt ungeschickt, Texte für Buttons zu lange, etc.
- Mittlere Abweichungen: Die Funktionalität ist grundsätzlich vorhanden, kann aber nur eingeschränkt benutzt werden, z.B. einige erwartete Einträge in einer Dropdownliste fehlen, Datenänderungen sind erst nach Schließen und wieder Öffnen eines Dialoges sichtbar, usw.
- Große Abweichungen: Die Funktionalität ist nicht benutzbar, z.B. Aktionsbuttons zeigen keine Reaktion, Daten werden nicht korrekt in die Datenbank geschrieben, etc.
- System unbenutzbar: Die Durchführung dieses Tests hinterlässt das System in einem unbenutzbaren Zustand, z.B. System stürtzt ab. Datenbank wird inkonsistent, Daten werden (ungeplant) gelöscht, etc.
| Feld | Inhalt |
|---|---|
| Use Case | UC Auth1 - Benutzeranmeldung |
| Ausgangszustand | Benutzer 'admin' (Passwort: passwd) ist ausgeloggt. Testdaten sind geladen. |
| Aktion | 1. POST /authentication/login mit Body { "username": "admin", "password": "passwd" } 2. Antwort entgegennehmen. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort-Body enthält ein gültiges JWT-Token im Feld 'token'. Das Token kann für nachfolgende Requests verwendet werden. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Auth1 - Benutzeranmeldung |
| Ausgangszustand | Benutzer 'admin' ist ausgeloggt. |
| Aktion | 1. POST /authentication/login mit Body { "username": "admin", "password": "wrongpassword" }
|
| Erwarteter Ergebniszustand | HTTP 401 Unauthorized. Kein JWT-Token wird zurückgegeben. Fehlermeldung weist auf ungültige Zugangsdaten hin. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Auth1 - Benutzeranmeldung |
| Ausgangszustand | Kein Benutzer mit Username 'ghost' existiert. |
| Aktion | 1. POST /authentication/login mit Body { "username": "ghost", "password": "password" }
|
| Erwarteter Ergebniszustand | HTTP 401 Unauthorized. Kein JWT-Token wird zurückgegeben. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Auth1 - Benutzeranmeldung |
| Ausgangszustand | Benutzer 'user2' (Rolle: EMPLOYEE) ist im System vorhanden. Ein SYSTEM_ADMIN deaktiviert den Benutzer via PATCH /api/admin/{id} mit { "enabled": false }. |
| Aktion | 1. POST /authentication/login mit den Zugangsdaten des deaktivierten Benutzers. |
| Erwarteter Ergebniszustand | HTTP 401 Unauthorized. Kein JWT-Token wird zurückgegeben. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Auth2 - Zugriffskontrolle |
| Ausgangszustand | Kein JWT-Token vorhanden. |
| Aktion | 1. GET /api/userx/me ohne Authorization-Header senden. |
| Erwarteter Ergebniszustand | HTTP 401 Unauthorized. Kein Benutzerprofil wird zurückgegeben. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Auth2 - Benutzerprofil |
| Ausgangszustand | Benutzer 'admin' ist eingeloggt und besitzt ein gültiges JWT-Token. |
| Aktion | 1. GET /api/userx/me mit gültigem Bearer-Token. Für die Testdurchführung steht zusätzlich eine SWE.postman_collection.json zur Verfügung, welche direkt in Postman importiert werden kann. Alternativ können die aktuellen Benutzerdaten nach erfolgreichem Login im Frontend über das Benutzerprofil oben rechts geladen werden. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Die Antwort enthält den Benutzer admin mit den Rollen SYSTEM_ADMIN und EMPLOYEE. Sensible Daten wie Passwort-Hashes sind NICHT Bestandteil der Antwort. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User2 - Benutzerverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. |
| Aktion | 1. GET /api/admin mit Bearer-Token von 'admin'. Im Frontend können alle Users über "User Management" in der Navbar aufgerufen werden. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort-Array enthält alle Benutzer (admin, user1, user2, elvis, anna, ben, clara, david, eva, felix, greta, hans, iris, jonas). Passwort-Hashes sind nicht enthalten. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User2 - Benutzerverwaltung |
| Ausgangszustand | Benutzer 'user2' (Rolle: EMPLOYEE) ist eingeloggt. Im Frontend soll kein "User Management" Feld in der Navbar vorhanden sein. |
| Aktion | 1. GET /api/admin mit Bearer-Token von 'user2' durch Endpoint API aufruf. Im Frontend ist keine |
| Erwarteter Ergebniszustand | HTTP 403 Forbidden. Kein Benutzer-Array wird zurückgegeben. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User2 - Benutzerverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzername 'newuser' existiert nicht. |
| Aktion | 1. POST /api/admin mit Body: { "username": "newuser", "password": "pw123", "firstName": "New", "lastName": "User", "email": "new@example.com", "enabled": true, "roles": ["EMPLOYEE"] }. Im Frontend kann ein neuer User unter "User Management -> "Add User" erstellt werden. |
| Erwarteter Ergebniszustand | HTTP 201 Created. Antwort-Body enthält den neuen Benutzer mit generierter ID. Benutzername ist 'newuser', Rolle ist 'EMPLOYEE'. Benutzer ist nachfolgend über GET /api/admin/{id} abrufbar. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User2 - Benutzerverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzername 'admin' existiert bereits. |
| Aktion | 1. POST /api/admin mit Body: { "username": "admin", "password": "pw123", "roles": ["EMPLOYEE"], "enabled": true }. |
| Erwarteter Ergebniszustand | HTTP 409 Conflict. Fehlermeldung weist auf bereits vorhandenen Benutzernamen hin. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User2 - Benutzerverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzer 'user2' existiert. |
| Aktion | 1. PATCH /api/admin/{id_von_user2} mit Body: { "firstName": "MaxUpdated", "email": "updated@example.com" }. Im Frontend können die Daten eines Users unter "User Management" -> "Details" aktualisiert werden. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort enthält firstName: 'MaxUpdated' und email: 'updated@example.com'. Andere Felder (username, roles) bleiben unverändert. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User2 - Benutzerverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Testbenutzer 'newuser' wurde in TC User2.3 erstellt. |
| Aktion | 1. DELETE /api/admin/{id_von_newuser} mit Bearer-Token von 'admin'. Im Frontend kann unter "User Management" der Button "Delete" benutzt werden. |
| Erwarteter Ergebniszustand | HTTP 204 No Content. Der gelöschte User ist in der separaten Liste "Deleted Users" ersichtlich. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC User3 - Self-Service |
| Ausgangszustand | Benutzer 'user2' (Rolle: EMPLOYEE) ist eingeloggt. |
| Aktion | 1. PATCH /api/userx/me mit Body: { "firstName": "MaxSelf", "phone": "+43 555 1234" }. Im Frontend können die Daten direkt wenn man seinen eigenen Namen rechts oben in Eck wählt geändert werden. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort enthält firstName: 'MaxSelf' und phone: '+43 555 1234'. Username und Rollen bleiben unverändert. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Abs1 - Abwesenheitsverwaltung |
| Ausgangszustand | Benutzer 'admin' ist eingeloggt. Abwesenheiten für 'admin' sind in der Datenbank vorhanden. |
| Aktion | 1. GET /api/userx/me/absences mit Bearer-Token von 'admin'. Im Frontend unter "Absences" in der Navbar. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Keine Abwesenheiten anderer Benutzer sind im Frontent ersichtlich. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Abs1 - Abwesenheitsverwaltung |
| Ausgangszustand | Benutzer 'admin' ist eingeloggt. |
| Aktion | 1. POST /api/absence mit Body: { "userxId": {id_von_admin}, "startDate": {freie_Wahl}, "endDate": {freie_Wahl}, "absenceType": "HOLIDAY" }. Im Frontend kann eine Abwesenheit unter "Absences" -> "Manage Absences" eingereicht werden. |
| Erwarteter Ergebniszustand | HTTP 201 Created. Antwort enthält die neue Abwesenheit mit Status 'PLANNED' und Typ 'HOLIDAY'. Start- und Enddatum sind korrekt gespeichert. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Abs1 - Abwesenheitsverwaltung |
| Ausgangszustand | Benutzer 'admin' ist eingeloggt. |
| Aktion | 1. POST /api/absence mit Body: { "userxId": {id_von_admin}, "startDate": "{freie_Wahl}", "endDate": "{freie_Wahl}", "absenceType": "HOLIDAY" }. Hinweis: startDate sollte größer als endDate sein. Siehe 3.2 für Frontend aktion. |
| Erwarteter Ergebniszustand | HTTP 400 Bad Request. Fehlermeldung weist auf ungültige Datumskombination hin. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Building1 - Gebäude |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Buildings sind in der Datenbank vorhanden. |
| Aktion | Im Frontend kann der eingeloggte Benutzer unter „Organization“ in der Navbar alle Gebäude, Adressen und Departments verwalten. Beim Anklicken der Schaltfläche „Organization“ soll automatisch die Ansicht „Buildings“ geöffnet werden. Zusätzlich sollen alle vorhandenen Gebäude in Tabellenform angezeigt werden. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort enthält mindestens die Buildings: 'Still OLD IT', 'Tech Tower', 'Main Office', 'South HQ' |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Building2 - Gebäude |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. |
| Aktion | Im Frontend kann der eingeloggte Benutzer unter „Organization“ in der Navbar alle Gebäude, Adressen und Departments verwalten. Beim Anklicken der Schaltfläche „Addresses“ muss der Benutzer zunächst eine neue Adresse anlegen. Anschließend kann unter „Buildings“ ein neues Gebäude erstellt werden, wobei die zuvor angelegte Adresse ausgewählt werden muss. |
| Erwarteter Ergebniszustand | HTTP 201 CREATED. Die neu erstellte Entität sollte in der Liste erscheinen. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Building2 - Gebäude |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. |
| Aktion | Im Frontend kann der eingeloggte Benutzer unter „Organization“ in der Navbar alle Gebäude, Adressen und Departments verwalten. Beim Anklicken der Schaltfläche „Addresses“ muss der Benutzer zunächst eine neue Adresse anlegen. Anschließend kann unter „Buildings“ ein neues Gebäude erstellt werden, wobei die zuvor angelegte Adresse ausgewählt werden muss. |
| Erwarteter Ergebniszustand | HTTP 201 CREATED. Die neu erstellte Entität sollte in der Liste erscheinen. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Building3 - Gebäude |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Ein Building aus dem vorherigen Test Case existiert bereits in der Buildings-Liste. |
| Aktion | Im Frontend navigiert der eingeloggte Benutzer unter „Organization“ zur View „Buildings“. Dort bearbeitet der Benutzer das zuvor erstellte Building über die Schaltfläche „Edit“, ändert den Namen des Buildings und speichert die Änderungen. Danach überprüft der Benutzer, ob der neue Name direkt aktualisiert in der Liste angezeigt wird. Anschließend löscht der Benutzer das gleiche Building über die Schaltfläche „Delete“ und bestätigt den Löschvorgang. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Das Building wird erfolgreich bearbeitet und direkt aktualisiert in der Liste angezeigt. Anschließend wird das Building erfolgreich gelöscht und verschwindet aus der Buildings-Liste. Beide Aktionen liefern eine SUCCESS-Meldung. Die verbundene Addresse mit dem Building wird auch komplett aus der Datenbank entfernt bzw. in der Liste "Addresses". |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Department1 - Department |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Der Benutzer „Ben Schmidt“ existiert bereits im System. |
| Aktion | Im Frontend kann der eingeloggte Benutzer unter „Organization“ in der Navbar alle Gebäude, Adressen und Departments verwalten. Beim Anklicken der Schaltfläche „Departments“ erstellt der Benutzer ein neues Department und weist diesem den Benutzer „Ben Schmidt“ zu. Anschließend wird das Department gespeichert. |
| Erwarteter Ergebniszustand | HTTP 201 CREATED. Das neu erstellte Department sollte in der Liste erscheinen und den Benutzer „Ben Schmidt“ enthalten. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Department2 - Department |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Ein Department mit dem Benutzer „Ben Schmidt“ existiert bereits in der Departments-Liste. |
| Aktion | Im Frontend navigiert der eingeloggte Benutzer unter „Organization“ zur View „Departments“. Dort bearbeitet der Benutzer das zuvor erstellte Department über die Schaltfläche „Edit“, ändert den Namen des Departments und speichert die Änderungen. Danach überprüft der Benutzer, ob der neue Name direkt aktualisiert in der Liste angezeigt wird. Anschließend löscht der Benutzer das gleiche Department über die Schaltfläche „Delete“ und bestätigt den Löschvorgang. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Das Department wird erfolgreich bearbeitet und direkt aktualisiert in der Liste angezeigt. Anschließend wird das Department erfolgreich gelöscht und verschwindet aus der Departments-Liste. Beide Aktionen liefern eine SUCCESS-Meldung. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Room1 - Raumverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Räume sind bereits in der Datenbank vorhanden. |
| Aktion | Im Frontend kann der eingeloggte Benutzer über die Navbar zur separaten View „Rooms“ navigieren. Nach dem Öffnen der Ansicht sollen alle bereits vorhandenen Räume in Tabellenform angezeigt werden. Dazu gehören unter anderem „Common Area 1“, „Common Area 2“, verschiedene „Eng Rooms“, „HR Rooms“ sowie „Mgmt Rooms“. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Die vorhandenen Räume werden erfolgreich geladen und in Tabellenform angezeigt. Die Liste enthält mehrere bereits angelegte Räume wie „Common Area 1“, „Common Area 2“, Engineering-, HR- und Management-Räume. Nur aktive Räume (active: true) werden angezeigt. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Room2 - Raumverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Ein Department „Engineering“ sowie das Building „TechTower“ existieren bereits im System. |
| Aktion | Im Frontend navigiert der eingeloggte Benutzer über die Navbar zur View „Rooms“. Dort erstellt der Benutzer über die Schaltfläche "Add Room“ einen neuen Raum mit dem Namen „Eng Office D“. Als Raumtyp wird „OFFICE“ ausgewählt, zusätzlich wird das Department „Engineering“ sowie das Building „TechTower“ ausgewählt. Anschließend speichert der Benutzer den neuen Raum. |
| Erwarteter Ergebniszustand | HTTP 201 CREATED. Der neue Raum „Eng Office D“ wird erfolgreich erstellt und direkt in der Raumliste angezeigt. Der Raum besitzt den Status active: true und eine SUCCESS-Meldung wird angezeigt. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Room3 - Raumverwaltung |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Der Raum „Eng Office D“ wurde im vorherigen Test Case erstellt und existiert in der Datenbank mit active: true. |
| Aktion | Im Frontend navigiert der eingeloggte Benutzer über die Navbar zur View „Rooms“. Dort sucht er den Raum „Eng Office D“ in der Liste und löscht ihn über die Schaltfläche „Delete“. Der Benutzer bestätigt den Löschvorgang. Im Hintergrund wird ein Soft-Delete ausgeführt, sodass der Raum in der Datenbank erhalten bleibt, aber als inaktiv markiert wird. |
| Erwarteter Ergebniszustand | HTTP 204 No Content. Der Raum wird erfolgreich soft-deleted und erhält den Status active: false. Ein anschließender GET /api/room/{id} liefert HTTP 404 zurück bzw. der Raum wird nicht mehr in der aktiven Raumliste angezeigt. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Raspberry1 - Raspberry Management |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Mehrere Raspberry Pis sind bereits in der Datenbank vorhanden. |
| Aktion | Im Frontend navigiert der eingeloggte Benutzer über die Navbar zu „Devices“. Dort wird automatisch eine Liste aller vorhandenen Raspberry Pis geladen und als Cards angezeigt werden. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Die Antwort enthält mindestens die Raspberry Pis rpi-room1, rpi-common1, rpi-eng-a. Jeder Raspberry Pi enthält die Felder id, hostName, ipAddress, deviceStatus, roomId, sensorStationIds. Die Geräte werden im Frontend in der Device-Liste angezeigt. Beim Anklicken der Liste werden die dazugehörigen Sensor Stationen angezeigt. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Raspberry1 - Raspberry Management |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Der Raspberry Pi „rpi-room1“ (id: 1) ist im System vorhanden und einem Raum zugewiesen. |
| Aktion | Im Frontend navigiert der eingeloggte Benutzer über die Navbar zu „Devices“. Dort wird die Liste der vorhandenen Raspberry Pis angezeigt. Der Benutzer wählt den Raspberry Pi „rpi-room1“ aus und klickt auf den Button „Download config.yaml“. Dadurch wird eine YAML-Konfigurationsdatei für das ausgewählte Gerät generiert und automatisch heruntergeladen. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Eine config.yaml Datei wird erfolgreich heruntergeladen. Der Inhalt der Datei entspricht exakt der Konfiguration des ausgewählten Raspberry Pis und hat folgendes Format (siehe code block unter Tabelle). |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
pi:
id: 1
room_id: 1
room_name: "Room 1"
host_name: "rpi-room1"
backend_url: "http://192.168.0.110:8080"
privacy_mode: true| Feld | Inhalt |
|---|---|
| Use Case | UC Raspberry2 - Raspberry Management |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN) ist eingeloggt. Der Raspberry Pi „rpi-room1“ ist vorhanden und bereits einer Raumstruktur zugeordnet. |
| Aktion | Im Frontend navigiert der Benutzer über die Navbar zu „Devices“ und wählt dort den Raspberry Pi „rpi-room1“ aus. Dadurch klappt die Detailansicht bzw. die zugehörige Liste der Stationen unter diesem Raspberry Pi auf. In dieser Ansicht kann der Benutzer über den Button „Add Station“ eine neue Sensorstation erstellen. Dabei werden frei wählbare Feldnamen und Werte angegeben. Die neu erstellte Sensorstation wird anschließend dem Raspberry Pi zugeordnet und erscheint in der Liste mit dem Status-Label „Needs setup“. Wichtig: In diesem Use Case ist SmartScan nicht aktiviert und wird nicht verwendet. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Die neue Sensorstation wird erfolgreich erstellt und dem Raspberry Pi „rpi-room1“ zugeordnet. Sie erscheint direkt in der aufklappbaren Liste unter dem Raspberry Pi mit dem Status „Needs setup“. Alle manuell eingegebenen Felder werden korrekt übernommen und gespeichert. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Threshold1 - Schwellenwertverwaltung |
| Ausgangszustand | Benutzer 'eva' (Passwort: 'passwd', Rolle: BUILDING_ADMIN) ist eingeloggt. Für den Raum „Room 1“ existiert noch kein Schwellenwert für die Metrik „PRESSURE“. Bereits vorhandene Schwellenwerte werden in der Liste unter „Thresholds“ angezeigt. |
| Aktion | Im Frontend navigiert der Benutzer über die Navbar zum Menüpunkt „Thresholds“. Dort öffnet sich eine Liste aller bereits existierenden Schwellenwerte. Der Benutzer erstellt einen neuen Schwellenwert für den Raum „Room 1“ mit der Metrik „PRESSURE“ und wählt dabei beliebige gültige Werte für den Schwellenwert. ThresholdType sollte UPPER sein. Zusätzlich wird ein passender Climate Hint für „Pressure“ aus der vorhandenen Liste ausgewählt. Nach dem Ausfüllen der Felder speichert der Benutzer den neuen Schwellenwert. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Der neue Schwellenwert wird erfolgreich erstellt und ist dem Raum „Room 1“ zugeordnet. Die Antwort enthält metric: 'PRESSURE', thresholdType entsprechend der Auswahl, sowie die gesetzten Werte. Der ausgewählte Climate Hint ist korrekt verknüpft. Der neue Schwellenwert erscheint direkt in der Threshold-Liste im Frontend. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Threshold1 - Schwellenwertverwaltung |
| Ausgangszustand | Benutzer 'eva' (Passwort: 'passwd', Rolle: SYSTEM_USER oder SYSTEM_ADMIN je nach Systemdefinition) ist eingeloggt. Für den Raum „Room 1“ existiert bereits ein Schwellenwert für die Metrik „PRESSURE“, welcher im vorherigen Test Case erstellt wurde. |
| Aktion | Im Frontend navigiert der Benutzer über die Navbar zu „Thresholds“. Dort wird die Liste der vorhandenen Schwellenwerte angezeigt. Der Benutzer sucht den zuvor erstellten Schwellenwert für „Room 1“ und öffnet diesen über die „Edit“-Funktion. Anschließend ändert der Benutzer den ThresholdType auf „LOWER“ und passt den Schwellenwert auf einen neuen beliebigen Wert an. Danach speichert der Benutzer die Änderungen. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Die Aktualisierung des Schwellenwerts kann aufgrund von HTTP-Anfragen einige Sekunden dauern. Nach erfolgreicher Verarbeitung ist der Schwellenwert mit metric: 'PRESSURE' weiterhin dem Raum „Room 1“ zugeordnet, jedoch mit thresholdType: 'LOWER' und dem aktualisierten Wert. Die Änderung wird korrekt in der Liste im Frontend angezeigt. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics1 - Raumanalyse |
| Ausgangszustand | Benutzer 'ben' (Rolle: EMPLOYEE, Raum: 'Eng Office A', privacyMode: false) ist eingeloggt. |
| Aktion | Im Frontend navigiert der Benutzer über die Navbar zum „Dashboard“. Dort wird automatisch die View „My Office“ aktiviert, die dem zugewiesenen Raum „Eng Office A“ entspricht. Der Benutzer sieht eine Übersicht mit den neuesten Messdaten seines Büros sowie die Anzahl aktiver Grenzwertverletzungen. Anschließend klickt der Benutzer auf „View History“. Dadurch werden historische Analysedaten geladen und in Diagrammform dargestellt. Es erscheinen mehrere Diagramm Blocks sowie zusätzliche Buttons zur Anpassung der Granularität. In diesem Use Case ist mindestens ein Diagramm für „Temperature“ über einen Zeitraum von 30 Tagen sichtbar, basierend auf den vorhandenen Mockdaten. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Die Dashboard-Ansicht zeigt korrekt „My Office“ für den Raum „Eng Office A“, inklusive aktueller Messdaten und Grenzwertverletzungen. Beim Öffnen von „View History“ werden mindestens 4 Diagramme sowie Steuerungselemente für die Granularität angezeigt, wobei mindestens das 30-Tage-Temperature-Diagramm korrekt gerendert wird (nur für TEMPERATURE aufgrund der Mock Daten). |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics1 - Raumanalyse |
| Ausgangszustand | Benutzer 'ben' (Rolle: EMPLOYEE, Department: Engineering) ist eingeloggt. Der Raum „Eng Common Area“ gehört zum Department Engineering und ist dem Benutzer über die Organisationsstruktur zugänglich. |
| Aktion | Im Frontend navigiert der Benutzer über die Navbar zum „Dashboard“. Dort wählt er den gemeinsamen Bereich „Eng Common Area“ aus. Anschließend wird automatisch die Raumzusammenfassung geladen. Zusätzlich öffnet der Benutzer die Ansicht „View History“, um historische Daten zu prüfen. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Im Frontend wird die Raumübersicht für „Eng Common Area“ korrekt angezeigt, jedoch werden keine Diagramme gerendert, da keine Daten existieren. Zusätzlich existieren keine Threshold Violations, da keine Messwerte vorliegen. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
CONTINUE HERE
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics3 - Trendanalyse |
| Ausgangszustand | Benutzer 'anna' (Rolle: DEPARTMENT_LEAD, Department: Engineering) ist eingeloggt. Raum 'Eng Office A' hat privacyMode: false. |
| Aktion | 1. GET /api/analytics/rooms/{3}/trends?metric=TEMPERATURE&from=2026-01-23T00:00:00&to=2026-02-22T00:00:00 mit Bearer-Token von 'anna'. |
| Erwarteter Ergebniszustand | HTTP 200 OK. bucketSize ist '1d' (erzwungene Tagesgranularität, nicht 'raw'). granularityReduced ist true. Datenpunkte repräsentieren Tagesdurchschnitte. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics4 - Abteilungsanalyse |
| Ausgangszustand | Benutzer 'anna' (Rolle: DEPARTMENT_LEAD, Department: Engineering) ist eingeloggt. |
| Aktion | 1. GET /api/analytics/departments/{id_Engineering}/summary mit Bearer-Token von 'anna'. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort enthält roomCount >= 5 (Eng Office A/B/C + Common Area). activeViolations zählt korrekt die aktiven Verletzungen der Abteilung. avgMetrics und currentMetrics sind befüllt. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics4 - Abteilungsanalyse |
| Ausgangszustand | Benutzer 'anna' (Rolle: DEPARTMENT_LEAD, Department: Engineering) ist eingeloggt. |
| Aktion | 1. GET /api/analytics/departments/{id_HR}/summary mit Bearer-Token von 'anna'. |
| Erwarteter Ergebniszustand | HTTP 403 Forbidden. Kein Abteilungsobjekt wird zurückgegeben. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics5 - Anonymisierung |
| Ausgangszustand | Benutzer 'iris' (Rolle: MANAGEMENT) ist eingeloggt. |
| Aktion | 1. GET /api/analytics/departments/{id_Engineering}/violations mit Bearer-Token von 'iris'. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort enthält total, active, resolved und byMetric-Aufschlüsselung. byRoom-Liste ist LEER (Anonymisierung gemäß Spezifikation). |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics6 - Firmendashboard |
| Ausgangszustand | Benutzer 'eva' (Rolle: BUILDING_ADMIN) ist eingeloggt. |
| Aktion | 1. GET /api/analytics/company/dashboard mit Bearer-Token von 'eva'. |
| Erwarteter Ergebniszustand | HTTP 200 OK. Antwort enthält totalRooms, totalEmployees, activeViolations. departmentBreakdowns enthält Einträge für alle Abteilungen. Werte sind plausibel (totalEmployees >= 10). |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics6 - Firmendashboard |
| Ausgangszustand | Benutzer 'eva' (Rolle: BUILDING_ADMIN) ist eingeloggt. |
| Aktion | 1. GET /api/analytics/company/trends?metric=TEMPERATURE&from=2026-01-23T00:00:00&to=2026-04-22T23:59:59 mit Bearer-Token von 'eva'. |
| Erwarteter Ergebniszustand | HTTP 200 OK. bucketSize ist nicht 'raw' (Fenster > 7 Tage => automatisch '1h', '6h' oder '1d'). Datenpunkte (points) sind nicht leer und enthalten plausible Temperaturwerte. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Analytics1 - Validierung |
| Ausgangszustand | Benutzer 'eva' (Rolle: BUILDING_ADMIN) ist eingeloggt. |
| Aktion | 1. GET /api/analytics/rooms/{id_Eng_Office_A}/summary?from=2026-04-22T00:00:00&to=2026-01-01T00:00:00 mit Bearer-Token von 'eva'. |
| Erwarteter Ergebniszustand | HTTP 400 Bad Request. Fehlermeldung weist darauf hin, dass 'from' nicht nach 'to' liegen darf. |
| Beobachtete Abweichungen | |
| Einstufung | Siehe 3. Testfälle - Einstufungsskala |
| Feld | Inhalt |
|---|---|
| Use Case | UC Hint1 - Klimahinweise |
| Ausgangszustand | Benutzer 'admin' (Rolle: SYSTEM_ADMIN oder BUILDING_ADMIN) ist eingeloggt. |
| Aktion | 1. POST /api/climatehint mit Body: { "metric": "TEMPERATURE", "hintText": "Testhinweis Temperatur" }
|
| Erwarteter Ergebniszustand | HTTP 201 Created. Antwort enthält den neuen Hinweis mit id, metric: 'TEMPERATURE' und hintText: 'Testhinweis Temperatur'. |
| Beobachtete Abweichungen | |
| Einstufung | [ ] OK [ ] Kosmetische Abweichungen [ ] Mittlere Abweichungen [ ] Große Abweichungen [ ] System unbenutzbar |
| Feld | Inhalt |
|---|---|
| Use Case | UC Hint1 - Klimahinweise |
| Ausgangszustand | Benutzer 'admin' ist eingeloggt. Klimahinweis 'Use a reverse-water-sprayer' ist mit dem HUMIDITY-Schwellenwert von 'Room 1' verknüpft. |
| Aktion | 1. DELETE /api/climatehint/{id_reverseWaterSprayer} mit Bearer-Token von 'admin'. |
| Erwarteter Ergebniszustand | HTTP 204 No Content. Die Verknüpfung zum Schwellenwert wurde automatisch aufgelöst. Der Schwellenwert selbst bleibt erhalten. |
| Beobachtete Abweichungen | |
| Einstufung | [ ] OK [ ] Kosmetische Abweichungen [ ] Mittlere Abweichungen [ ] Große Abweichungen [ ] System unbenutzbar |
Führen Sie in diesem Abschnitt weitere Testfälle zur nachvollziehbaren und reproduzierbaren Überprüfung relevanter nichtfunktionaler Anforderungen an. Diese sind z.B.:
- Tests zu Antwortzeiten
- Konsistenz der Nutzeroberfläche
- Stabilitätstests
| Begriff | Erklärung |
|---|---|
| ACTIVE | Status einer Schwellenwert-Verletzung – Verletzung ist noch aktiv. |
| BUILDING_ADMIN | Rolle mit Zugriff auf Gebäudeverwaltung und Analytics (kein User-Management). |
| DEPARTMENT_LEAD | Rolle mit Zugriff auf eigene Abteilung; reduzierte Granularität bei Büroanalysen. |
| EMPLOYEE | Basisrolle; Zugriff auf eigenes Büro und gemeinsame Bereiche der Abteilung. |
| IAQ | Index of Air Quality – Luftqualitätsindex. |
| JWT | JSON Web Token – statelesser Authentifizierungstoken. |
| MANAGEMENT | Rolle mit anonymisiertem Zugriff auf Abteilungs- und Firmendaten. |
| privacyMode | Bool-Flag pro Raum: true = Mindestbelegung nicht erreicht, keine Messdaten für EMPLOYEE sichtbar. |
| RESOLVED | Status einer Schwellenwert-Verletzung - Verletzung wurde aufgelöst. |
| Soft-Delete | Logisches Löschen: Raum bleibt in DB, wird aber als active: false markiert. |
| SYSTEM_ADMIN | Administratorrolle für Benutzerverwaltung; KEIN Zugriff auf Analytics-Endpunkte. |
- Software Konzept (Version, Datum)