Berlin:Firmware/Testing
Vorgeplänkel
Vor einem Release soll die Freifunk Berlin Firmware immer einmal unter Realbedingungen getestet werden. Dazu haben wir einige Testszenarien erarbeitet, die - wenn möglich - mit den relevantesten Geräten einmal durchgespielt werden sollen. Die Geräteliste kann gerne ergänzt werden. Die Szenarien können gerne ergänzt werden.
Szenario A - Regelfall DSL-Insel Tunnel:
- Installieren des Images (clean)
- Wizzard: "Internet teilen"
- prüfen, ob Client getunnelte Verbindung ins Internet bekommt
- Option BBB: prüfen, ob sich das Paket bbb-digger installieren lässt. Prüfen, ob BBB erreichbar ist.
Szenario B - Regelfall Mesh:
- Installieren des Images (clean)
- Wizzard: "Am Freifunk-Netz teilnehmen"
- Prüfen, ob Gerät mesht (Achtung 802.11s und adhoc)
- Prüfen, ob Client Internet über das Mesh bekommt
Szenario C - Regelfall DSL-Insel ohne Tunnel:
- Installieren des Images (clean)
- Wizzard: "Internet teilen"
- prüfen, ob Client direkte Verbindung ins Internet bekommt
- Option BBB: prüfen, ob sich das Paket bbb-digger installieren lässt. Prüfen, ob BBB erreichbar ist.
Szenario D - Regelfall funktionierenden Router updaten:
- Installieren des Images (Einstellungen behalten)
- prüfen, ob alles noch so funktioniert wie vorher
Erfassung der Testergebnisse
Jeder Test wird einfach in die untenstehende Tabelle geschrieben. Wobei ein "+" für "Testszenario bestanden", o für "nicht getestet" und "-" für "es gab ein Problem" steht. Falls ein Problem auftritt bitte einfach eine Erläuterung unter die Tabelle schreiben.
Testing Tabelle RC 1.0.6
| Gerät | Szenario A | Szenario B | Szenario C | Szenario D | xx | xx |
|---|---|---|---|---|---|---|
| TP-Link TL-WDR3600 v1 | + o - | + o - | + o - | + o - | + o - | + o - |
| TP-Link TL-WDR4300 v1 | + o - | + o - | + o - | + o - | + o - | + o - |
| TP-Link CPE210 v1.1 | + o - | + o - | + o - | + o - | + o - | + o - |
| TP-Link Archer C7 v2 | + o - | + o - | + o - | + o - | + o - | + o - |
| GL AR150 | + o - | + o - | + o - | + o - | + o - | + o - |
| TP-Link TL-WDR4900 v1 | + o - | + o - | + o - | + o - | + o - | + o - |
| Ubiquiti Nanostation M5/M2 | + o - | + o - | + o - | + o - | + o - | + o - |
| TP-Link TL-WR1043N/ND v2 | + o - | + o - | + o - | + o - | + o - | + o - |
Teilautomatisierung von manuellen Tests
Das händische Testen von Firmware-Releases kann sehr Zeitaufwändig werden. Insbesondere wenn mehrere Modelle getestet werden sollen, nimmt die immmer wieder gleiche Einrichtung der Router über den Wizard einen großen Teil der Zeit in Anspruch. Dieser Schritt kann mit diesem Skript automatisiert werden. Dabei wird mit dem Router über einen ferngesteuerten Webbrowser interagiert. Alle Schritte erfolgen somit exakt so, als würden sie von einem menschlichen Nutzer ausgeführt.
Konzept automatisierte Tests der Kernfunktionen
Um hardwareunabhängige Funktionen der Firmware zu testen, kam die Idee auf Test zu automatisieren. Insbesondere soll es dazu führen, auf Veränderungen im OpenWrt, z.B. Konfigurationen, in der Freifunk-Firmware schneller zu reagieren und die Freifunk-Firmware im Kern stabil zu halten.
Allgemein
Die verschiedenen Architekturen und Systeme, auf denen die Freifunk-Firmware lauffähig ist, können z.B. mittels Qemu virtualisiert werden. Dadurch können verschiedene Testszenarion mit virtuellen Maschinen nachgebaut werden. Container sind ggf. noch ressourcenschonender (brauchen keinen eigenen Kernel, kein dediziertes RAM, kein eigenes Block Device), siehe auch dieses Skript, dass die Firmware in einem Docker-Container laufen lässt.
Um den Ansatz der Automatisierung der Tests zu verfolgen, wird wird eine Orchestrierungsschicht benötigt. Die Orchestrierung kann ggf. durch Tools wie Jenkins, ansible, puppet oder einer Kombination dieser erfolgen. Damit die Tests nachvollziehbar sind, sollten die Testcases verwaltet und die Ergebnisse gespeichert werden. Hierzu bietet sich das Tool TestLink an, dass sowohl eine Datenbank für die Testcases und Ergebnisse bietet, als auch eine Workflow Engine zur Unterstützung der Automatisierung.
Im Rahmen der Gluon-firmware gibt es auch ein Testframework für Mesh-Topologien was adaptiert werden kann.
Ressourcen
Die benötigten Ressourcen setzen sich aus den Anforderungen der eingesetzten Tools, wie Testlink und Jenkins, als auch den Ressourcen für die Testscenarion benötigten virtuellen Maschinen zusammen. Da die Virtuellen Maschinen einen Freifunk Router simulieren soll, sind die benötigten Ressourcen hierfür eher gering und liegen bei < 128 MB RAM und 8-128 MB Disk. Die Parallelisierung der Test ist dann ein Multiplikator der benötigten Ressourcen der virtuellen Maschinen.
Zielarchitektur
TBD
Testszenarien
TBD
