Abnahmetest

_Hinweis:_{Dieses Dokument versteht sich als Guideline und dient der Strukturierung des Abnahmeberichts. Bitte halten Sie die in diesem Bericht zusammengefassten Beobachtungen, Kritiken, und Verbesserungsvorschläge in einer verständlichen und konstruktiven Art und Weise fest. Das Entwicklungsteam muss zu Ihrem Bericht schriftlich Stellung nehmen und gegebenenfalls Änderungen am System vornehmen. Wenn notwendig, untermauern Sie Ihren Bericht durch Screenshots.}

1. Ergebnis

Beschreiben Sie Ihr Vorgehen beim Abnahmetest (z.B. in Bezug auf die Übernahme des Systems und des Testdrehbuchs vom Entwicklerteams, Anzahl der Testfälle, Testdaten). Fassen Sie das Ergebnis Ihres Systemtests zusammen und gehen Sie dabei auf Stärken und Schwächen des Systems ein.

Uns als Abnahmeteam wurden insgesamt 27 Testfälle vom Entwicklerteam zur Verfügung gestellt. Diese deckten verschiedene Bereiche des Systems ab, darunter Login, Employee, Department, Facility Administration, System Administration sowie die Hardware Komponenten (Sensorstationen und Raspberry Pi). Die Testfälle wurden in einer Excel-Tabelle exportiert, welche wir für die Durchführung der Tests sowie zur Dokumentation von Feedback und Auffälligkeiten verwendet haben. Alle Teammitglieder beteiligten sich an der Durchführung der Tests, wobei die Testfälle möglichst gleichmäßig aufgeteilt wurden. Für die Tests standen unterschiedliche Testdaten zur Verfügung, darunter mehrere Users mit verschiedenen Rollen sowie bereits angelegte Systemdaten.

ERGEBNISSE HIER EINFÜGEN .....

2. Funktionalität

Prüfen Sie zumindest folgende Aspekte:

Sind alle versprochenen Funktionalität (vlg. Software Konzept) implementiert?

Funktioniert der Datenaustausch mit anderen Systemen?

3. Performanz, Fehlertoleranz und Stabilität

Prüfen Sie zumindest folgende Aspekte:

Ist das Antwortverhalten des Systems im vereinbarten Rahmen?

Reagiert das System in angemessener Weise auf Fehlerzustände (z.B. Neustart des Accesspoints, kurzfristiger Ausfall der Kommunikation zwischen Minirechner und zentralem Backend (etc.)?

Reagiert Ihr System stabil auf fehlerhafte und attackierende Eingaben?

Ist sichergestellt, dass gelöschte/inaktive Benutzeraccounts, Access Points und Sensorstationen keine Auswirkungen auf vergangene Berichtszeiträume haben?

4. Usability

Prüfen Sie, inwiefern das Gesamtkonzept des Systems den Bedürfnissen der adressierten Zielgruppe gerecht wird.

5. Testdrehbuch

Bewerten Sie das vom Entwicklungsteam zur Verfügung gestellte Testdrehbuch (=Liste der Testfälle) in Hinblick auf Testüberdeckung und Wiederverwendbarkeit.

3.1 Authentifizierung

TC-ID	Status	Bemerkung
TC Auth1.1	OK	Login funktioniert korrekt für alle getesteten Benutzer. Bei Anmeldung mit einem nicht existierenden Benutzer wird aktuell jedoch die Meldung „Server Error, Bad Credentials“ angezeigt. Die Exception BadCredentialsException sollte im GlobalExceptionHandler behandelt werden.
TC Auth1.2	Mittlere Abweichungen	Anmeldung mit falschem Passwort führt derzeit zu einer generischen „Server Error“-Meldung. Erwartet wird eine benutzerfreundliche Fehlermeldung.
TC Auth1.3	Mittlere Abweichungen	Die angezeigte Fehlermeldung entspricht jedoch derselben Problematik wie bei den vorherigen Login-Testfällen. Grundsätzlich kann sich der User nicht mehr anmelden, was OK ist.
TC Auth1.4	Große Abweichungen	Der erwartete Dialog zur Eingabe der E-Mail-Adresse beim erstmaligen Login wird nicht angezeigt.

3.2 Mitarbeitende

TC-ID	Status	Bemerkung
TC Emp1.1	OK	Keine aktiven Verstöße sichtbar. Es wurden wahrscheinlich keine Testdaten hinterlegt, die Anzeige verhält sich dennoch korrekt.
TC Emp1.2	OK	Keine Auffälligkeiten festgestellt.
TC Emp1.3	OK	Funktioniert wie beschrieben.
TC Emp1.4		Noch nicht durchgeführt.
TC Emp1.5		Noch nicht durchgeführt.

3.3 Department

TC-ID	Status	Bemerkung
TC Dep1.1	Mittlere Abweichungen	Historische Klimadaten werden grundsätzlich korrekt dargestellt. Bei Räumen mit nicht erfüllter Mindestbelegung werden jedoch weiterhin einzelne Messwerte angezeigt, obwohl kein Graph dargestellt wird.
TC Dep1.2	OK	Funktioniert wie im Testfall beschrieben.
TC Room3.1	OK	Funktioniert wie beschrieben.
TC Room3.2	OK	Funktionalität entspricht den Anforderungen. Finde etwas unübersichtich wenn alle Adressen im Drop-Down erscheinen obwohl ich die, die schon taken sind, ja nicht nehmen kann. Würd evtl. ne Sortierung einbauen, dass die neuen Adressen, die noch nie verwendet wurden, ganz oben erscheinen.
TC Building3.3	OK	Funktionalität entspricht den Anforderungen.
TC Department3.4	OK	Funktioniert wie beschrieben.
TC Department3.5	OK	Funktioniert wie beschrieben.
TC Room3.6	OK	Funktioniert wie beschrieben.
TC Room3.7	OK	Funktioniert wie beschrieben.
TC Room3.8	OK	Funktioniert wie beschrieben. Allerdings führt die gegebene url nicht zur gewünschten seite

3.4 Facility Administration

TC-ID	Status	Bemerkung
TC Fac1.1	OK	Threshold-Konfiguration funktioniert zuverlässig, einschließlich der implementierten Boundary-Logik.
TC Fac1.2	OK	Funktionalität entspricht den Anforderungen.
TC Fac1.3	OK	Funktionalität entspricht den Anforderungen.

3.5 System Administration

TC-ID	Status	Bemerkung
TC SA1.1		Noch nicht durchgeführt.
TC SA1.2		Noch nicht durchgeführt.
TC SA1.3		Noch nicht durchgeführt.
TC SA1.4		Noch nicht durchgeführt.
TC SA1.5	OK	Funktioniert wie vorgesehen.

3.6 Sensorstation

TC-ID	Status	Bemerkung
TC Sen1.1	OK	Funktioniert wie vorgesehen.
TC Sen1.2	Kosmetische Abweichungen	Angezeigter Zeitstempel weicht um etwa 2 Stunden von der tatsächlichen Zeit ab.
TC Sen1.3	OK	Funktioniert wie vorgesehen.
TC Sen1.4	OK	Funktioniert wie vorgesehen.

3.6 Schwellenwerte

TC-ID	Status	Bemerkung
TC Thresh5.1	OK	Funktioniert wie vorgesehen.
TC Thresh5.2	Kosmetische Abweichungen	asd

3.7 Analytics

TC-ID	Status	Bemerkung
TC Ana6.1	OK	Keine Abweichungen, funktioniert wie vorgesehen.
TC Ana6.2	OK	Keine Abweichungen, funktioniert wie vorgesehen.
TC Ana6.3	OK	Keine Abweichungen, funktioniert wie vorgesehen.
TC Ana6.4	OK	Keine Abweichungen, funktioniert wie vorgesehen.
TC Ana6.5	Kosmetische Abweichungen	Eventuell den Inhalt scrollbar machen und der Sidebar eine feste Höhe geben (Pagination oder Scrollable), um ein konsistentes und sauberes Layout zu gewährleisten. Ist der Inhalt zu groß, wird momentan ein weißer hintergrund angezeigt, wenn man zu weit hinunter scrolled.

3.7 Raspberry Pi

TC-ID	Status	Bemerkung
TC Hub1.1	OK	Das lokale Puffern der Messdaten in der SQLite-Datenbank funktioniert wie vorgesehen. Zur direkten Überprüfung der gespeicherten Einträge musste die Datei central.db jedoch zunächst von g5t5/central/config nach g5t5/central verschoben werden, da Docker die Datenbank von dort aus einbindet.
TC Hub1.2	Mittlere Abweichungen	Die Events werden korrekt in den Docker Logs protokolliert. Die im Testfall spezifizierte Logdatei /var/log/iot/central_1.log konnte auf dem Raspberry Pi jedoch nicht gefunden werden.
TC Hub1.3	Mittlere Abweichungen	Die Übertragung von Messdaten an die Webanwendung funktioniert grundsätzlich. Ist das Backend erreichbar, werden die Daten erfolgreich übertragen und in der Raspberry PI Datenbank mit dem Status SYNCHED markiert. Ist das Backend nicht erreichbar, werden die Messdaten korrekt mit dem Status PENDING gespeichert. Das spätere erneute Senden dieser zwischengespeicherten Datensätze funktioniert jedoch nicht. Die Webanwendung lehnt diese Datensätze ab. Als mögliche Ursache wurde festgestellt, dass die aus der SQLite Datenbank geladenen Messdaten Feldnamen im snake_case-Format (z. B. is_active) enthalten, während erfolgreich übertragene Datensätze das vom Backend erwartete camelCase Format (z. B. isActive) verwenden.
TC Hub1.4	OK	Die Berechnung von Grenzwertüberschreitungen funktioniert wie im Testfall beschrieben.

6. Weiter Auffälligkeiten

Führen Sie hier weiter Auffälligkeiten an bzw. geben Sie konkrete Verbesserungsvorschläge.

Das System sollte vollständig über Docker containerisiert werden, sodass sowohl Backend als auch Frontend gemeinsam gestartet werden können und kein manueller Start über mvn bzw. npm start erforderlich ist.
Die angegebenen Startbefehle (docker up -d und mvn springboot:run) funktionieren in der aktuellen Form nicht. Korrekt wären hier docker compose up -d sowie mvn spring-boot:run.
In den Logs treten mehrfach AccessDeniedException Fehler auf, die aktuell durch eine generische Methode im GlobalExceptionHandler abgefangen werden. Beispiel:

Unhandled exception at path: /api/department/rooms/violations, caught by global handler: org.springframework.security.authorization.AuthorizationDeniedException: Access Denied

Es wird empfohlen, die AccessDeniedException explizit in der Methode handleNotAllowedException zu berücksichtigen. Dies kann z. B. durch Gruppierung der Exceptions erfolgen:

@ExceptionHandler({NotAllowedException.class, AccessDeniedException.class})
Für Tester war es nicht sofort ersichtlich, wo sich der „Enabled“-Button befindet, um Benutzer im User Management zu aktivieren bzw. zu deaktivieren. Eine klarere Benennung (z. B. statt „Authorize“) sowie eine intuitivere Platzierung im UI wäre hier sinnvoll.
In den Logfiles treten NullPointerException-Fehler auf, z. B.:

NullPointerException occurred at path: /api/employee/common-areas

Ursache ist, dass Userx.getDepartment() teilweise null zurückgibt, wodurch anschließend Department.getId() nicht aufgerufen werden kann. Es wird empfohlen, entsprechende Null-Checks oder Validierungen im Code zu ergänzen.