Skip to content

Testdrehbuch

Jump to bottom
Emma Danko edited this page Jun 30, 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]]

1. Testvorbereitung

Um das System vollständig zu starten, befolgen Sie die folgenden Schritte. Reihenfolge bitte einhalten. Relevante Abkürzungen:

  • BE ... Backend
  • FE ... Frontend
  • RPI ... Raspberry Pi
  1. Der Computer, auf dem Sie die Webapplikation starten wollen, muss mit demselben WLAN-Netz verbunden sein, in dem sich später auch der RPI befinden soll.
  2. Docker Engine auf Ihrem Computer starten.
  3. Projekt in der IDE Ihrer Wahl öffnen und die IP-Adresse des Computers in die .env-Datei unter APP_BACKEND_URL=http://your-backend-url einfügen. Die IP des WLAN-Adapters kann z.B. mit ifconfig auf Linux oder ipconfig auf Windows ermittelt werden.
# so sollte die .env Datei aussehen, sie muss sich im root folder des Projekts (/g5t4) befinden

# --- Team / deployment ---
TEAM_NAME=G5T4
HOST_PORT=8080

# --- JWT ---
APP_JWT_SECRET=1a7783f6abab21b127e728d54043df9e6dbd9b1ae21ea1a743b6f04db60f3a02f16cae655b0de03bfc7b415572af35c865a083f061b4e37d333b9316516c4f557274c5988483056494ca9940de53b24b8547b1b9d06f9f4bc4515fcc9b9cdd241e027dd575744b4e9b028f4fb3b2a90956afc0685d6c5a12d47aceb9b39f451714e08dc6e0722dffc3481ac5a1a765ad12a37eecbcc218d03a6f742ac6de3c879bea46b8233fc5cee438371664cb1b323c2d52dae01b0673878507cf8b9d54f7f53519ca05e5a9e17cc831118348eca0d26de394a648d7f4ce78f2e3788b22add2bc37c401061cdacc18d5aa5a7d379b57085856d85a01127061ba9205504f5265ce6d806354daac802d0252d021e45676318ca8b89039bef8a75f68765958159d9a3c4ecaca061d7950081e9ad171fac2bcaed214f7ab19e323e4b7d47d41bd7bff38cd80949ab6b078cef870372252851e14d7f31fe137abd946ff7676fdc6ff9003054f65b4fdc8ea1e126294197461ace716da9fc1a8bd7a6edcb8d1d585280a59799798e13276d5797ce133ed3b8503d2cefca9b4022b95360b3cc2865fc02b8968741dcae7cd48ee6d16fe376d841215458fb736783182a06a3730c2f57f0f2e5e3b39bdfb86cbc2536e6e73522408ccf422686653f0efeee0662721de13069bcb37090d788c6393d7ce9dc8d9b463764232f7f1dc7f074f6ccb1a3232

# --- PostgreSQL ---
POSTGRES_DB=skel
POSTGRES_USER=sa
POSTGRES_PASSWORD=2026swe

APP_BACKEND_URL=http://192.168.0.110:8080

  1. Nun ist alles bereit, um den Docker-Container der Webapp mit docker compose up --build zu starten. Sollten Sie im Laufe des Testens die Datenbank des Backends zurücksetzen wollen, benutzen Sie dazu docker compose down -v und anschließend wieder docker compose up --build.

  2. Nachdem die Applikation vollständig gestartet ist, können Sie über localhost:8080 in Ihrem Browser auf die Applikation zugreifen.

  3. Loggen Sie sich mit einem passenden User ein, je nach gewünschter Funktionalität. Für das Setup des RPI und der Sensorstation brauchen Sie User admin.

    User: admin, Passwort: passwd

    Für eine vollständige Liste aller User siehe Kapitel 1: Testdaten.

  4. Nachdem Sie erfolgreich eingeloggt sind, klicken Sie in der oberen Menüleiste auf den Button Devices. Dort können Sie nun entweder mit dem Button + Add Raspberry Pi einen neuen RPI erstellen oder, direkt über den kleinen Pfeil rechts, einen bestehenden RPI für das Setup verwenden.

setup1.png

  1. Beim Erstellen eines neuen RPI werden Sie aufgefordert, einen Hostnamen und einen Raum auszuwählen. Wichtig: Jeder Raum kann nur einen RPI haben. Wenn Sie versuchen, einen RPI einem Raum zuzuteilen, der bereits einen hat, bekommen Sie eine Fehlermeldung.

setup2.png

  1. Nach erfolgreicher RPI-Erstellung taucht der RPI unten in der Liste der vorhandenen RPIs auf.

setup3.png

  1. Für die Erstkonfiguration eines neuen RPI muss nun die vom BE generierte conf.yaml heruntergeladen und manuell auf die SD-Karte des RPI an den Speicherort /home/pi/conf.yml kopiert werden.

Wie Sie das machen, hängt davon ab, ob das Climate Canary Git-Repo bereits auf den RPI geklont wurde und ob pi-gateway bereits als systemd-Service auf dem RPI registriert wurde.

Der Hostname unseres RPI ist swess26-raspberry13. Einloggen können Sie sich mit User: pi und Passwort: 123.

Falls das Git-Repo noch nicht geklont wurde, machen Sie das jetzt und führen Sie anschließend das install.sh-Skript aus, um den systemd-Service pi-gateway zu registrieren.

# Nachdem Sie den RPI mit dem WLAN verbunden haben, führen Sie folgende Befehle aus 
# führen Sie diese entweder lokal auf dem RPI aus oder mit ssh "ssh pi@swess26-raspberry13.local"
git clone <repo-url>
cd g5t4

# systemd-Service-Registrierung, das muss nur einmal ausgeführt werden
sudo ./raspberry_setup/install.sh

Falls der systemd-Service bereits registriert war oder nachdem Sie ihn mit den oben genannten Befehlen registriert haben, ist es nun an der Zeit, die conf.yml-Datei auf den RPI zu kopieren. Dies ist mit den unten genannten Befehlen möglich.

# RPI muss mit dem richtigen WLAN verbunden sein 

# Mit diesem Befehl wird die conf.yml, die Sie im FE heruntergeladen haben, vom BE-Rechner auf den RPI übertragen.
scp conf_<name>.yaml pi@swess26-raspberry13.local:/home/pi/conf.yml

# führen Sie die weiteren Befehle lokal auf dem RPI aus oder mit ssh "ssh pi@swess26-raspberry13.local"

# stellen Sie sicher, dass sie sich im richtigen Ordner befinden 
cd ./Dokumente/g5t4/raspberry_setup

# Dieser Befehl baut den Docker-Container
./build.sh

# Service neu starten, damit die neue Config geladen wird 
sudo systemctl restart pi-gateway


# Alternativ können Sie diesen Befehl auch lokal auf dem RPI aufrufen 
sudo systemctl restart pi-gateway

# Application-Logs einsehen 
tail -f /home/pi/pi-gateway/app.log

# systemd-Logs einsehen 
journalctl -u pi-gateway -f 

# If you ever need to manually wipe the database on the RPI, follow these steps
sudo systemctl stop pi-gateway
rm -f /home/pi/pi-gateway/sensor.db
sudo systemctl start pi-gateway

  1. Nur das Erstsetup ist so aufwändig. Danach wird der RPI jedes Mal beim Booten prüfen, ob eine conf.yml-Datei vorhanden ist und eine WLAN-Verbindung besteht. Falls ja, startet der Normalbetrieb automatisch. Falls das fehlschlägt, gibt es alle 30 Sekunden einen Retry.

  2. Sollten Sie zu irgendeinem Zeitpunkt die Logs auf dem RPI sehen wollen, empfehlen wir die VS-Code Remote SSH Extension für den Zugriff auf den RPI. Dies wird zwar im Normalbetrieb nicht benötigt, könnte aber zum Testen interessant sein, weil die Aktivitäten auf dem RPI ausführlich geloggt werden und Ihnen während der Ausführung detaillierte Informationen geben. Der Hostname unseres RPI ist swess26-raspberry13. Einloggen können Sie sich mit User: pi und Passwort: 123.

  3. Wenn der RPI erfolgreich gestartet wurde und die Kommunikation mit dem BE aufgenommen hat, sollte die Frontend-Ansicht so aussehen:

setup7.png

Setup der Sensorstation

  1. Nachdem die Applikation auf dem RPI hochgefahren ist, wird die Sensorstation mit Strom verbunden. Das Programm auf der Sensorstation startet automatisch.

Falls Ihnen eine Sensorstation vom zu bewertenden Team zur Verfügung gestellt wurde, ist in der Regel kein weiteres Setup erforderlich. Das Programm ist bereits auf dem Arduino vorinstalliert.

Wenn auf dem Display Waiting for known connection... steht, befindet sich die Sensorstation in der Verbindungsstatus-Ansicht. Falls stattdessen die Datenmessungs-Anzeige zu sehen ist, drücken Sie einmal den ersten Knopf (Button 1), um zur Verbindungsstatus-Ansicht zu wechseln.

Wenn dort Waiting for known connection... angezeigt wird, setzen Sie den Arduino zurück, indem Sie alle drei Knöpfe gleichzeitig drücken. Dies kann unter Umständen mehrere Versuche erfordern.

Nach dem Zurücksetzen sollte auf dem Display ADVERTISING AS: auf der ersten Zeile und auf der zweiten Zeile die MAC-Adresse erscheinen. Die Sensorstation ist nun bereit und kann über das Frontend einem RPI zugewiesen werden.

  1. Wenn Sie keine Sensorstation erhalten haben, müssen Sie Ihre eigene Station gegebenenfalls entsprechend umbauen.

Das verwendete Pinout lautet:

Funktion Pin
Button 1 D2
Button 2 D3
Button 3 D10
RGB Rot A0
RGB Grün A6
RGB Blau A7
BME680 + LCD SDA / SCL
  1. Zum Flashen des Arduinos mit unserem Code muss PlatformIO verwendet werden. Welche IDE Sie dafür nutzen, ist Ihnen überlassen.

Das Arduino-Projekt befindet sich im Ordner:

arduino

Die relevante platformio.ini-Datei finden Sie unter:

arduino/src/ClimateCanary/platformio.ini

Nachdem alle benötigten Libraries installiert wurden, kann der Code direkt aus der IDE auf den Arduino geflasht werden.

  1. Prüfen Sie nun noch einmal, ob die Sensorstation weiterhin ADVERTISING AS: und die MAC-Adresse anzeigt.

  2. Nun gehen wir zurück ins Frontend. Durch das Klicken auf den kleinen Pfeil rechts erscheint das folgende Submenü.

setup4.png

  1. Über den Button Scan for Arduinos taucht ein weiteres Fenster auf, über das ein BLE-Scan ausgelöst wird. Dies ist der erste Schritt, um Sensorstationen mit dem RPI zu verbinden.

setup5.png

  1. Der Scan dauert 10 Sekunden. Anschließend übermittelt der RPI die gefundenen Sensorstationen an das BE. Während Sie warten, sehen Sie diesen Screen. Der Arduino muss sich im Setup-Modus befinden. Das Display zeigt in diesem Fall ADVERTISING AS: und die MAC-Adresse. Sollten Sie irgendetwas anderes auf dem Display sehen, bitte alle drei Buttons auf dem Arduino gleichzeitig drücken, um das Gerät zurückzusetzen.

setup6.png

  1. Sollten keine Sensorstationen gefunden werden, vergewissern Sie sich, dass alle Geräte eingeschaltet sind, BE und RPI im selben WLAN sind und die Applikation auf dem RPI läuft (VS-Code SSH Remote ist hier der beste Weg). Überprüfen Sie außerdem, ob der Arduino wirklich im Setup-Modus ist.

  2. Die gefundenen Sensorstationen werden folgendermaßen angezeigt. Es können mehrere Sensorstationen mit einem RPI verbunden werden, allerdings muss das Setup für jede einzeln ausgeführt werden. Also wählen Sie hier jeweils eine Sensorstation aus, indem Sie auf den grünen Select Button klicken.

setup8.png

  1. Nun können Sie der Sensorstation einen beliebigen Namen geben und das gewünschte Messintervall angeben. Das Messintervall wird in Sekunden angegeben und kann zwischen 0 und 255 Sekunden betragen.

setup9.png

  1. Die Sensorstation befindet sich nun im Status available, solange, bis die Authentifizierungslogik zwischen Sensorstation und RPI abgeschlossen ist. Wenn alles geklappt hat, ist die Sensorstation nun im Status connected, ansonsten connection failed. In diesem Fall am besten noch einmal scannen und versuchen zu verbinden.

setup10.png

setup11.png

  1. Sobald die Sensorstation im Status connected ist, beginnt sie, Messdaten an das BE zu senden.

Das Setup ist nun erfolgreich abgeschlossen. Happy Testing.

1.1 Testdaten

Zu Testbeginn sind folgende Nutzer eingerichtet:

Benutzer/Passwort Rollen Abteilung Anmerkung
admin / passwd SYSTEM_ADMIN Haupt-Adminkonto
user1 / passwd MANAGEMENT Management-Sicht
user2 / passwd EMPLOYEE Management Büro: Mgmt Common Area
elvis / passwd SYSTEM_ADMIN Zweiter Admin
anna / passwd EMPLOYEE, DEPARTMENT_LEAD Engineering Lead Engineering
ben / passwd EMPLOYEE Engineering Leads all other Departments
clara / passwd EMPLOYEE Engineering Büro: Eng Office B
david / passwd EMPLOYEE Engineering Büro: Eng Office B
eva / passwd BUILDING_ADMIN Gebäude-Admin
greta / passwd EMPLOYEE HR Büro: HR Office B
felix / passwd EMPLOYEE HR Büro: HR Office A
hans / passwd EMPLOYEE Management Büro: Mgmt Office A
iris / passwd MANAGEMENT Management-Sicht
jonas / passwd EMPLOYEE Management Büro: Mgmt Office B
eng1-4 /passwd EMPLOYEE Engineering Büro: Eng Office A

Initialer Testdatenbestand:

  • Abwesenheiten: Mehrere geplante und genehmigte Abwesenheiten (HOLIDAY, SICKNESS, PARENTAL_LEAVE, OTHER)
  • Adressen: Primary Address (Italy), Campus West Austria, Main Campus Austria, HQ South Germany
  • Gebäude: Old IT Building, Tech Tower, Main Office, South HQ
  • Abteilungen: Research (2), Sales, Management, Engineering, HR
  • Räume: Room 1, Common Area 1, Sales Common Area, Sales Office A, Mgmt Office A/B, Mgmt Common Area 1/2, Eng Office A/B/C, Eng Common Area, HR Office A/B, HR Common Area
  • Sensorstationen: Station A/B, Sales-A-S1, Sales-Common-S1, Mgmt-A/B-S1, Mgmt-Common-S1, Eng-A/B/C-S1, Eng-A-S2/S3, Eng-Common-S1, HR-A/B-S1, HR-Common-S1
  • Raspberry Pis: Für alle relevanten Räume vorhanden
  • Messwerte: Ca. 562.000 Messdatensätze für Temperatur, Luftfeuchtigkeit, IAQ und Druck
  • Schwellenwerte: Temperatur-, Luftfeuchtigkeits- und IAQ-Grenzwerte für verschiedene Räume; teils deaktivierbar
  • Aktive Verletzungen: U.a. Room 1 HUMIDITY, Eng Office A IAQ, Eng Office B HUMIDITY, HR Office A HUMIDITY, Sales Office A TEMPERATURE
  • Historische Verletzungen: Mehrere RESOLVED-Verletzungen für Temperatur, IAQ und Luftfeuchtigkeit
  • Klimahinweise: Mehrere Hinweise für HUMIDITY, TEMPERATURE, PRESSURE und IAQ
  • Hinweis: Alle Testdaten werden automatisch nach docker compose up --build über die Datei docker-DB.sql in die Datenbank importiert. Kein manuelles importieren wird benötigt aufgrund der Automatisierung. Die docker-DB.sql befindet sich in der root directory.

Hinweis: Sie sollten diese Daten zusätzlich in Form eines einfach zu importierenden Datenbank-Dumps bereitstellen.

1.2 Testeingangskriterien

Die Integrationstests können gestartet werden, wenn

  1. Alle Unit-Tests erfolgreich und vollständig ausgeführt wurden. Alle Unittests können mit einem Rechtsklick unter src/test/java/ -> 'Run 'Tests' in tests' ausgeführt werden.
  2. Die Datenbank mit dem beschriebenen initialen Testdatenbestand befüllt ist. Dies sollte automatisch erfolgen.
  3. Die Anwendung lokal oder auf dem Testserver erreichbar ist (http://localhost:8080).

2. Testprotokoll

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)

3. Testfälle

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.

3.0 Einstufungslegende

  • 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.

3.1 Authentifizierung

TC Auth1.1: Anmeldung — gültige Zugangsdaten

Feld Inhalt
Use Case UC Auth1 — Benutzeranmeldung
Ausgangszustand Benutzer admin (Passwort: passwd) ist ausgeloggt. Testdaten sind geladen.
Aktion 1. Die Login-Seite aufrufen.
2. Benutzername admin und Passwort passwd eingeben.
3. Sign in klicken.
Erwarteter Ergebniszustand Der Benutzer wird auf die Profil- bzw. Dashboard-Seite weitergeleitet. Es wird keine Fehlermeldung angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Auth1.2: Anmeldung — falsches Passwort

Feld Inhalt
Use Case UC Auth1 — Benutzeranmeldung
Ausgangszustand Benutzer admin ist ausgeloggt.
Aktion 1. Die Login-Seite aufrufen.
2. Benutzername admin und Passwort wrongpassword eingeben.
3. Sign in klicken.
Erwarteter Ergebniszustand Eine Fehlermeldung erscheint, die auf falsche Zugangsdaten hinweist. Der Benutzer verbleibt auf der Login-Seite.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Auth1.3: Anmeldung — unbekannter Benutzer

Feld Inhalt
Use Case UC Auth1 — Benutzeranmeldung
Ausgangszustand Kein Benutzer mit dem Benutzernamen ghost existiert im System.
Aktion 1. Die Login-Seite aufrufen.
2. Benutzername ghost und ein beliebiges Passwort eingeben.
3. Sign in klicken.
Erwarteter Ergebniszustand Eine Fehlermeldung erscheint. Der Benutzer verbleibt auf der Login-Seite. Es wird kein Dashboard angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Auth1.4: Anmeldung — deaktivierter Benutzer

Feld Inhalt
Use Case UC Auth1 — Benutzeranmeldung
Ausgangszustand Benutzer user2 (Rolle: EMPLOYEE) ist vorhanden. Ein Administrator hat diesen Account zuvor über User Management -> User2 -> Deleted deaktiviert.
Aktion 1. Die Login-Seite aufrufen.
2. Die Zugangsdaten des deaktivierten Benutzers eingeben (user2, passwd).
3. Sign in klicken.
Erwarteter Ergebniszustand Eine Fehlermeldung erscheint. Der Benutzer kann sich nicht anmelden und verbleibt auf der Login-Seite.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.2 Benutzerverwaltung

TC User2.1: Alle Benutzer abrufen (SYSTEM_ADMIN)

Feld Inhalt
Use Case UC User2 — Benutzerverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt.
Aktion 1. User Management in der Navbar anklicken unter "Admin".
Erwarteter Ergebniszustand Eine Tabelle wird angezeigt, die alle Benutzer enthält: admin, user1, user2, elvis, anna, ben, clara, david, eva, felix, greta, hans, iris, jonas. Keine Passwort-Hashes sind sichtbar.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.2: Alle Benutzer abrufen — fehlende Berechtigung

Feld Inhalt
Use Case UC User2 — Benutzerverwaltung
Ausgangszustand Benutzer user2 (Rolle: EMPLOYEE) ist eingeloggt.
Aktion 1. Prüfen, ob ein User Management-Eintrag in der Navbar sichtbar ist unter "Admin".
Erwarteter Ergebniszustand Der Eintrag User Management ist in der Navbar nicht sichtbar.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.3: Neuen Benutzer anlegen

Feld Inhalt
Use Case UC User2 — Benutzerverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzername newuser existiert nicht.
Aktion 1. User Management aufrufen.
2. Add User klicken.
3. Folgende Felder ausfüllen: Benutzername newuser, Passwort pw123, Vorname New, Nachname User, E-Mail new@example.com, Rolle EMPLOYEE, Department: Research (2), Room: Common Area 1 , Phone '+43 1234 56'.
4. Speichern.
Erwarteter Ergebniszustand Der neue Benutzer newuser mit der Rolle EMPLOYEE erscheint in der Benutzertabelle.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.4: Benutzer anlegen — Benutzername bereits vergeben

Feld Inhalt
Use Case UC User2 — Benutzerverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzername admin existiert bereits.
Aktion 1. User Management aufrufen.
2. Add User klicken.
3. Benutzername admin eingeben und die restlichen Pflichtfelder ausfüllen.
4. Speichern.
Erwarteter Ergebniszustand Eine Fehlermeldung erscheint. Es wird kein neuer Benutzer angelegt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.5: Benutzer aktualisieren

Feld Inhalt
Use Case UC User2 — Benutzerverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzer user2 existiert.
Aktion 1. User Management aufrufen.
2. Details für user2 anklicken.
3. Vorname auf MaxUpdated und E-Mail auf updated@example.com ändern.
4. Speichern.
Erwarteter Ergebniszustand Die Benutzerliste bzw. Detailansicht zeigt MaxUpdated und updated@example.com für user2. Andere Felder (Benutzername, Rollen) bleiben unverändert.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.6: Benutzer löschen

Feld Inhalt
Use Case UC User2 — Benutzerverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzer newuser wurde in TC User2.3 erstellt.
Aktion 1. User Management aufrufen.
2. newuser in der Liste suchen.
3. Delete klicken und den Vorgang bestätigen.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. newuser ist nicht mehr in der aktiven Benutzerliste sichtbar. Der Benutzer erscheint in der Liste Deleted Users.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.7: Eigenes Profil aktualisieren (Self-Update)

Feld Inhalt
Use Case UC User3 — Self-Service
Ausgangszustand Ein Admin muss den Benutzer newuser (Rolle: EMPLOYEE) von der Deleted List restoren. Später, im System mit "newuser", password: pw123 einloggen.
Aktion 1. Auf den Benutzernamen oben rechts in der Navbar klicken, um die Profilseite zu öffnen.
2. Edit klicken.
3. Vorname auf MaxSelf und Telefon auf +43 555 1234 ändern.
4. Speichern.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Die Profilseite zeigt den Vornamen MaxSelf und die Telefonnummer +43 555 1234. Benutzername und Rollen bleiben unverändert.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC User2.8: Eigenes Konto löschen (Self Delete)

Feld Inhalt
Use Case UC User3 — Self-Service
Ausgangszustand Der Benutzer newuser (EMPLOYEE) ist im System eingeloggt und befindet sich auf seiner Profilseite.
Aktion 1. Profilseite über Klick auf den Benutzernamen in der Navbar öffnen.
2. Zum Bereich Danger Zone scrollen.
3. Auf Delete my account klicken.
4. Löschvorgang bestätigen (Confirm Dialog).
Erwarteter Ergebniszustand Der Benutzer wird deaktiviert (soft deleted). Ein erneutes Login mit newuser ist nicht mehr möglich und der Benutzer erscheint ggf. in der Deleted List.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.3 Abwesenheitsverwaltung

TC Abs3.1: Eigene Abwesenheiten abrufen

Feld Inhalt
Use Case UC Abs1 — Abwesenheitsverwaltung
Ausgangszustand Benutzer greta ist eingeloggt. Zwei Abwesenheiten für greta sind in der Datenbank vorhanden.
Aktion 1. Absences in der Navbar anklicken.
2. Der Tab Manage Absences wird standardmäßig angezeigt.
Erwarteter Ergebniszustand Nur die Abwesenheiten von greta werden angezeigt. Abwesenheiten anderer Benutzer sind nicht sichtbar.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Abs3.2: Abwesenheit anlegen

Feld Inhalt
Use Case UC Abs1 — Abwesenheitsverwaltung
Ausgangszustand Benutzer greta ist eingeloggt.
Aktion 1. Absences -> Manage Absences aufrufen.
2. Ein Startdatum und ein Enddatum auswählen (Enddatum muss nach dem Startdatum liegen).
3. Abwesenheitstyp Holiday auswählen.
4. Submit klicken.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Die neue Abwesenheit erscheint in der Liste mit Status PLANNED und Typ HOLIDAY. Start- und Enddatum werden korrekt angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Abs3.3: Abwesenheit anlegen — Enddatum vor Startdatum

Feld Inhalt
Use Case UC Abs1 — Abwesenheitsverwaltung
Ausgangszustand Benutzer greta ist eingeloggt.
Aktion 1. Absences -> Manage Absences aufrufen.
2. Ein Startdatum wählen, das nach dem Enddatum liegt.
3. Einen beliebigen Abwesenheitstyp auswählen.
4. Submit klicken.
Erwarteter Ergebniszustand Eine Fehlermeldung erscheint, die darauf hinweist, dass das Startdatum vor dem Enddatum liegen muss. Es wird keine Abwesenheit angelegt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.4 Gebäude & Räume

TC Room3.1: Alle Gebäude abrufen

Feld Inhalt
Use Case UC Building1 — Gebäudeverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Gebäude sind in der Datenbank vorhanden.
Aktion 1. Admin -> Organization in der Navbar anklicken.
2. Der Tab Buildings öffnet sich standardmäßig.
Erwarteter Ergebniszustand Eine Tabelle wird angezeigt, die mindestens folgende Gebäude enthält: Old IT Building, Tech Tower, Main Office, South HQ.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Room3.2: Neues Gebäude anlegen

Feld Inhalt
Use Case UC Building2 — Gebäudeverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt.
Aktion 1. Organization -> Addresses aufrufen.
2. Add Address klicken, alle Pflichtfelder ausfüllen und speichern.
3. Zum Tab Buildings wechseln.
4. Add Building klicken, einen Namen eingeben und die in Schritt 2 erstellte Adresse auswählen.
5. Speichern.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Das neue Gebäude wird in der Gebäudetabelle angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Building3.3: Bestehendes Gebäude bearbeiten und löschen

Feld Inhalt
Use Case UC Building3 — Gebäudeverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Das in TC Room3.2 erstellte Gebäude ist in der Liste vorhanden.
Aktion 1. Organization -> Buildings aufrufen.
2. Edit für das in TC Room3.2 erstellte Gebäude klicken, den Namen ändern und speichern.
3. Prüfen, ob der neue Name sofort in der Liste aktualisiert wird.
4. Delete für dasselbe Gebäude klicken und den Vorgang bestätigen.
Erwarteter Ergebniszustand Die Bearbeitung liefert eine Erfolgsmeldung und der aktualisierte Name erscheint sofort in der Liste. Nach dem Löschen verschwindet das Gebäude aus der Liste und eine Erfolgsmeldung wird angezeigt. Die in TC Room3.2 ausschließlich für dieses Gebäude erstellte Adresse ist ebenfalls nicht mehr nach einem Page refresh in der Addresses-Liste sichtbar.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Department3.4: Neues Department anlegen

Feld Inhalt
Use Case UC Department1 — Abteilungsverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Benutzer Ben Schmidt existiert im System.
Aktion 1. Organization -> Departments aufrufen.
2. Add Department klicken.
3. Einen Namen eingeben und Ben Schmidt als Abteilungsleiter zuweisen.
4. Speichern.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Das neue Department ist in der Abteilungstabelle sichtbar und zeigt Ben Schmidt als Abteilungsleiter.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Department3.5: Bestehendes Department bearbeiten und löschen

Feld Inhalt
Use Case UC Department2 — Abteilungsverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Das in TC Department3.3 mit Ben Schmidt erstellte Department ist in der Liste vorhanden.
Aktion 1. Organization -> Departments aufrufen.
2. Edit für das Department klicken, den Namen ändern und speichern.
3. Prüfen, ob der aktualisierte Name sofort in der Liste angezeigt wird.
4. Delete für dasselbe Department klicken und den Vorgang bestätigen.
Erwarteter Ergebniszustand Die Bearbeitung liefert eine Erfolgsmeldung und der aktualisierte Name erscheint sofort in der Liste. Nach dem Löschen verschwindet das Department aus der Liste und eine Erfolgsmeldung wird angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Room3.6: Alle Räume abrufen

Feld Inhalt
Use Case UC Room1 — Raumverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Räume sind in der Datenbank vorhanden.
Aktion 1. Organization -> Rooms aufrufen.
Erwarteter Ergebniszustand Eine Tabelle wird angezeigt, die vorhandene Räume enthält, darunter Common Area 1, Common Area 2, verschiedene Eng Rooms, HR Rooms und Mgmt Rooms. Es werden ausschließlich Räume mit Status active: true angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Room3.7: Neuen Raum anlegen und Pagination

Feld Inhalt
Use Case UC Room2 — Raumverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Department Engineering und Gebäude Tech Tower sind vorhanden.
Aktion 1. Organization -> Rooms aufrufen.
2. Add Room klicken.
3. Name Eng Office D eingeben, Raumtyp OFFICE wählen, Department Engineering und Gebäude Tech Tower auswählen.
4. Speichern.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Raum Eng Office D erscheint in der Raumliste mit Status active: true. Außerdem sollte die Tabelle nach Name, Type, Department und Building sortierbar sein.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Room3.8: Raum Soft-Delete

Feld Inhalt
Use Case UC Room3 — Raumverwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Raum Eng Office D wurde in TC Room3.6 erstellt und ist aktiv.
Aktion 1. Organization -> Rooms aufrufen.
2. Eng Office D in der Liste suchen.
3. Delete klicken und den Vorgang bestätigen.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Eng Office D ist nicht mehr in der aktiven Raumliste sichtbar. Der Raum wird intern als active: false markiert (Soft-Delete) und verbleibt in der Datenbank. Dies kann hier überprüft werden: http://localhost:8081/buildings?pgsql=postgres&username=sa&db=skel mit password: 2026swe wo ACTIVE=0 gesetzt wird für den gelöschten Raum.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.5 Sensorstationen & Raspberry Pis

TC Sensor4.1: Alle Raspberry Pis abrufen

Feld Inhalt
Use Case UC Raspberry1 — Raspberry-Pi-Verwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Mehrere Raspberry Pis sind in der Datenbank vorhanden.
Aktion 1. Admin -> Devices in der Navbar anklicken.
Erwarteter Ergebniszustand Eine Liste von Raspberry-Pi-Karten wird angezeigt, die mindestens rpi-room1, rpi-common1 und rpi-eng-a enthält. Jede Karte zeigt ID, Host-Name, IP-Adresse, Status und zugewiesenen Raum. Durch Aufklappen einer Karte werden die zugehörigen Sensorstationen angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Sensor4.2: Raspberry-Pi-Konfigurationsdatei herunterladen

Feld Inhalt
Use Case UC Raspberry1 — Raspberry-Pi-Verwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Raspberry Pi rpi-room1 (id: 1) ist vorhanden und einem Raum zugewiesen.
Aktion 1. Devices aufrufen.
2. rpi-room1 in der Liste suchen.
3. Download conf.yaml klicken.
Erwarteter Ergebniszustand Eine Datei mit dem Namen conf_rpi-room1.yaml (oder ähnlich) wird heruntergeladen. Der Inhalt entspricht folgendem Forma (siehe unten)
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: false

TC Sensor4.3: Sensorstation scannen

Feld Inhalt
Use Case UC Raspberry2 — Raspberry-Pi-Verwaltung
Ausgangszustand Benutzer admin (Rolle: SYSTEM_ADMIN) ist eingeloggt. Raspberry & Arduino Setup wird für dieses Testcase vorausgesetzt.
Aktion 1. Admin -> Devices aufrufen.
2. Neues Raspberry Pi anlegen und setup vornehmen.
3. Ein Klick auf "Scan for Arduinos"
Erwarteter Ergebniszustand Die gefundenen Sensorstationen erscheint in der Liste für Scan Arduinos.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.6 Schwellenwerte

TC Thresh5.1: Schwellenwert anlegen

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.
Aktion 1. Building -> Thresholds in der Navbar anklicken.
2. Add Threshold klicken.
3. Raum Room 1, Metrik PRESSURE, Schwellenwerttyp UPPER auswählen und einen gültigen Grenzwert eingeben.
4. Einen Klimahinweis für PRESSURE aus der verfügbaren Liste auswählen.
5. Speichern
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Der neue Schwellenwert für Room 1 / PRESSURE / UPPER erscheint in der Schwellenwerteliste mit dem verknüpften Klimahinweis.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Thresh5.2: Schwellenwert bearbeiten

Feld Inhalt
Use Case UC Threshold1 — Schwellenwertverwaltung
Ausgangszustand Benutzer eva (Passwort: passwd, Rolle: BUILDING_ADMIN) ist eingeloggt. Der in TC Thresh5.1 erstellte PRESSURE / UPPER-Schwellenwert für Room 1 ist vorhanden.
Aktion 1. Thresholds aufrufen.
2. Den PRESSURE-Schwellenwert für Room 1 suchen und Edit klicken.
3. Den Schwellenwerttyp auf LOWER ändern und den Grenzwert auf einen neuen gültigen Wert aktualisieren.
4. Speichern.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Der Schwellenwert für Room 1 / PRESSURE wird nun mit Typ LOWER und dem aktualisierten Grenzwert angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.7 Analytics

TC Ana6.1: Raumzusammenfassung — eigenes Büro (EMPLOYEE)

Feld Inhalt
Use Case UC Analytics1 — Raumanalyse
Ausgangszustand Benutzer ben (Rolle: EMPLOYEE, zugewiesener Raum: Eng Office A, privacyMode: false) ist eingeloggt.
Aktion 1. Dashboard in der Navbar anklicken.
2. Der Tab Dashboard ist standardmäßig aktiv und zeigt Eng Office A.
3. Prüfen, ob aktuelle Messwerte und die Anzahl aktiver Grenzwertverletzungen angezeigt werden.
4. View History auf der Raumkarte klicken.
5. Auf der Verlaufsseite prüfen, ob alle Diagramme gerendert werden.
Erwarteter Ergebniszustand Das Dashboard zeigt Eng Office A mit aktuellen Messwerten und aktiven Grenzwertverletzungen. Die Verlaufsseite zeigt 4 Metrikdiagramme (Temperatur, Luftfeuchtigkeit, Luftdruck, IAQ).
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Ana6.2: Raumzusammenfassung — gemeinsamer Bereich (EMPLOYEE)

Feld Inhalt
Use Case UC Analytics1 — Raumanalyse
Ausgangszustand Benutzer ben (Rolle: EMPLOYEE, Department: Engineering) ist eingeloggt. Raum Eng Common Area gehört zum Department Engineering.
Aktion 1. Dashboard in der Navbar anklicken.
2. Zum Tab Common Areas wechseln.
3. View History auf der Karte von Eng Common Area klicken.
Erwarteter Ergebniszustand Das Dashboard zeigt Eng Common Area. Die Verlaufsseite rendert die 4 Metrikdiagramm-Blöcke. Für diesen Raum werden keine Grenzwertverletzungen angezeigt.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Ana6.3: Raumtrend — reduzierte Granularität (DEPARTMENT_LEAD)

Feld Inhalt
Use Case UC Analytics2 — Trendanalyse
Ausgangszustand Benutzer anna (Rolle: DEPARTMENT_LEAD, Department: Engineering) ist eingeloggt.
Aktion Department -> Overview:
1. Zur Verlaufsansicht für Raum Eng Office B navigieren.
Erwarteter Ergebniszustand Das Diagramm wird mit Tagesdurchschnittswerten gerendert (bucketSize: 1d).
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Ana6.4: Verletzungsanalyse — Anonymisierung für MANAGEMENT

Feld Inhalt
Use Case UC Analytics3 — Anonymisierung
Ausgangszustand Benutzer iris (Rolle: MANAGEMENT) ist eingeloggt.
Aktion 1. Overview in der Navbar anklicken.
Erwarteter Ergebniszustand Aktive Verletzungsanzahlen sowie eine Aufschlüsselung nach Metrik werden angezeigt. Die Aufschlüsselung nach Räumen ist nicht sichtbar, entsprechend der Anonymisierungsanforderung für die Rolle MANAGEMENT.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Ana6.5: Firmen-Dashboard (BUILDING_ADMIN)

Feld Inhalt
Use Case UC Analytics6 — Firmen-Dashboard
Ausgangszustand Benutzer eva (Rolle: BUILDING_ADMIN) ist eingeloggt.
Aktion 1. Building -> Rooms in der Navbar anklicken.
Erwarteter Ergebniszustand Das Firmen-Dashboard zeigt alle Räume und deren Messwerte sowie Grenzwertverletzungen in verschiedene Granularitätsoptionen. Diagramme werden nicht für alle Rooms gerendert aufgrund der Mock Daten. Für die vordefinierten Räume mit Department Engineering sind genügend Daten enthalten, um die Diagrame zu rendern.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.8 Klimahinweise

TC Hint7.1: Klimahinweis anlegen

Feld Inhalt
Use Case UC Hint1 — Klimahinweise
Ausgangszustand Benutzer eva (Rolle: BUILDING_ADMIN) ist eingeloggt.
Aktion 1. Thresholds in der Navbar aufrufen.
2. Zum Tab Climate Hints wechseln.
3. Add Climate Hint klicken.
4. Metrik TEMPERATURE auswählen und den Hinweistext Testhinweis Temperatur eingeben.
5. Speichern.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Der neue Klimahinweis mit Metrik TEMPERATURE und Text Testhinweis Temperatur erscheint in der Climate-Hints-Liste unter der Temperatur-Gruppe.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

TC Hint7.2: Klimahinweis löschen

Feld Inhalt
Use Case UC Hint1 — Klimahinweise
Ausgangszustand Benutzer eva (Rolle: BUILDING_ADMIN) ist eingeloggt und befindet sich im Bereich Thresholds → Climate Hints. Ein bestehender Klimahinweis mit Metrik TEMPERATURE und Text Testhinweis Temperatur ist vorhanden.
Aktion 1. Thresholds in der Navbar aufrufen.
2. Zum Tab Climate Hints wechseln.
3. Den Eintrag mit Metrik TEMPERATURE und Text Testhinweis Temperatur in der Liste auswählen.
4. Auf Delete (Löschen-Icon) klicken.
5. Löschvorgang bestätigen.
Erwarteter Ergebniszustand Eine Erfolgsmeldung erscheint. Der Klimahinweis Testhinweis Temperatur ist nicht mehr in der Climate-Hints-Liste sichtbar.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.2 Testfälle vom Softwarekonzept

Viele Testcases, die sich aus den Usecases ergeben, wurden im oberen Kapitel schon abgedeckt. Zusätzliche befinden sich hier.

Feld Inhalt
Use Case UC-06 TC1 — Grenzwertwarnung auslösen (Normalbetrieb)
Ausgangszustand Grenzwerte sind für den betroffenen Raum konfiguriert. Die Sensorstation ist aktiv. Ein Messwert überschreitet dauerhaft über 5 Minuten einen konfigurierten Grenzwert.
Aktion 1. Raspberry Pi empfängt Messdaten via BLE.
2. Raspberry Pi erkennt nach 5-minütigem Überschreiten des Grenzwerts eine bestätigte Verletzung.
Erwarteter Ergebniszustand Der Warnstatus wird gesetzt. Die LED der Sensorstation wechselt auf Rot. Das Display der Sensorstation zeigt den Warnmodus mit Hinweis und Tipp. Die dem Raum zugewiesenen EMPLOYEEs sehen, dass es eine aktive Warnung gibt, in ihrem Dashboard. Die Abteilungsleitung sieht die Warnung in der Abteilungsübersicht.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala
Feld Inhalt
Use Case UC-06 TC2 — Noise-Filter verhindert Fehlauslösung
Ausgangszustand Grenzwerte sind für den betroffenen Raum konfiguriert. Die Sensorstation ist aktiv. Ein Messwert überschreitet den Grenzwert kurzfristig (< 5 Minuten), z. B. durch kurzes Öffnen eines Fensters.
Aktion 1. Raspberry Pi empfängt kurzzeitig erhöhte Messdaten via BLE.
Erwarteter Ergebniszustand Es wird keine Warnung ausgelöst. LED und Display der Sensorstation bleiben unverändert.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala
Feld Inhalt
Use Case UC-06 TC3 — Warnung manuell aufheben
Ausgangszustand Eine aktive Grenzwertwarnung (violationStatus = ACTIVE) liegt für einen Raum vor. Nutzer:in ist in der Webapp eingeloggt.
Aktion 1. Warnung im Frontend manuell aufheben. (BUILDING_ADMIN muss den threshold manuell deaktivieren, um Warnungen aufzuheben)
Erwarteter Ergebniszustand Das Backend sendet eine PATCH-Anfrage mit ViolationResolvedDTO an /api/spi/{piId}/violation/resolve. Der Raspberry Pi deaktiviert die Verletzung, informiert die Sensorstation und aktualisiert seine lokale Datenbank. Die Meldung verschwindet von der Overview Ansicht der EMPLOYEEs. Die Verletzung bleibt historisch gespeichert (violationStatus = RESOLVED).
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala
Feld Inhalt
Use Case UC-06 TC4 — Warnung automatisch aufheben
Ausgangszustand Eine aktive Grenzwertwarnung liegt für einen Raum vor. Die Messwerte kehren dauerhaft in den Normalbereich zurück.
Aktion 1. Raspberry Pi erkennt, dass die Messwerte dauerhaft unterhalb des Grenzwerts liegen.
Erwarteter Ergebniszustand Der Raspberry Pi hebt den Warnstatus auf und informiert Sensorstation und Webapp. Die LED der Sensorstation wechselt auf Türkis. Die Meldung verschwindet von der Overview Ansicht der EMPLOYEEs. Die Verletzung bleibt historisch gespeichert (violationStatus = RESOLVED).
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

3.3 Weiter nichtfunktionale Testfälle

Feld Inhalt
Use Case NFR-01 TC1 — Ladezeit Admin-Dashboard
Ausgangszustand Nutzer:in ist als Systemadministrator eingeloggt.
Aktion 1. Admin-Dashboard aufrufen via Dashboard Button in der Topbar.
Erwarteter Ergebniszustand Das Admin-Dashboard ist vollständig geladen und nutzbar in unter 2 Sekunden.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala
Feld Inhalt
Use Case NFR-02 TC1 — Stabilitätstest Datenkontinuität über 30 Minuten
Ausgangszustand Raspberry Pi und Arduino sind korrekt verbunden und lauffähig. Nutzer:in ist als Employee jonas mit entsprechendem Passwort eingeloggt.
Aktion 1. System 30 Minuten ohne Unterbrechung laufen lassen.
2. Anschließend die Verlaufsansicht des zugeordneten Büroraums öffnen.
Erwarteter Ergebniszustand Der Graph zeigt einen lückenlosen Datenverlauf über die gesamten 30 Minuten. Keine grauen Lücken oder Unterbrechungen sind sichtbar.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala
Feld Inhalt
Use Case NFR-03 TC1 — Datenkonsistenz zwischen Employee- und Admin-Ansicht
Ausgangszustand Employee jonas ist eingeloggt. Der zugeordnete Büroraum enthält historische Messdaten.
Aktion 1. Als Employee jonas einloggen und die Verlaufsansicht des eigenen Büroraums öffnen.
2. Angezeigte Daten (Werte, Zeitstempel, Verlauf) notieren.
3. Als Employee ausloggen und als Systemadministrator einloggen.
4. Unter Building → Rooms denselben Raum aufrufen und die Verlaufsansicht öffnen.
Erwarteter Ergebniszustand Die in der Admin-Ansicht angezeigten Messdaten (Menüpunkt Buildings -> Rooms) stimmen vollständig mit den in der Employee-Ansicht notierten Daten überein. Keine Abweichungen in Werten oder Zeitstempeln.
Beobachtete Abweichungen
Einstufung Siehe 3. Testfälle - Einstufungsskala

4. Anhang

4.1 Glossar

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.

4.2 Referenzierte Dokumente

Home

Software Konzept

REST-Spezifikation

Testdrehbuch

Abnahmetest

KI-Erfahrungsbericht

Masterlist Meeting Protokolle

Masterlist Zeitaufzeichnungen

Sidebar

Clone this wiki locally