Test Cases

Test Cases

Übersicht

Nr.	K	D	M	Test
1.1	rt	m	T	Aufruf von tmp.to auf wi-client
1.2	rt	m	T	Aufruf von tmp.to auf mz-client
1.3	rt	m	C	Aufruf von wi-Info auf wi-client
1.4	rt	m	C	Aufruf von mz-Info auf mz-client
1.5	rt	m	C	Inter-Community Routing
1.6	rt	m	C	Inter-City Routing 1
1.7	rt	m	C	Inter-City Routing 2
2.1	dn	m	C	interne Namensauflösung
2.2	dn	m	C	Inter-City Namensauflösung
3.1	fo	m	C	Ausfall eines Gates

Testfälle

1. Routing-Testfälle

   1. Anonymisierungsdienst: Aufruf von tmp.to auf wi-client

      • FIX-ME: Problem: es wird bereits hier auch die Namensauflösung extern getestet
      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Test Gluon
      • benötigt: alle Gates, mindestens ebensoviele Nodes (Wiesbaden) und Clients
      • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein Client angemeldet; Zugriff auf diese Clients
      • Ablauf: Auf den Browsern aller Test-Clients wird der URL http://tmp.to aufgerufen.
      • Nachbedingung: Alle Aufrufe von http://tmp.to zeigen, dass der Ano-Dienst als Absender auftaucht.
        • Methode: Beobachtung auf Clients.

   2. Anonymisierungsdienst: Aufruf von tmp.to auf mz-client

      • FIX-ME: Problem: es wird bereits hier auch die Namensauflösung extern getestet
      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Test Gluon
      • benötigt: alle Gates, mindestens ebensoviele Nodes (Mainz) und Clients
      • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein Client angemeldet; Zugriff auf diese Clients
      • Ablauf: Auf den Browsern aller Test-Clients wird der URL http://tmp.to aufgerufen.
      • Nachbedingung: Alle Aufrufe von http://tmp.to zeigen, dass der Ano-Dienst als Absender auftaucht.
        • Methode: Beobachtung auf Clients.

   3. Intra-Community Routing: Aufruf von wi-Info auf wi-client

      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Closed Beta
      • benötigt: alle Gates, mindestens ebensoviele Nodes (Wiesbaden) und Clients
      • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein Client angemeldet; Zugriff auf diese Clients
      • Ablauf: Auf den Browsern aller Test-Clients werden die URLs http://10.207.0.56/infopage und http://fec0::a:cf:0:38/infopage aufgerufen.
      • Nachbedingung: Alle Aufrufe der URLs zeigen, dass die Clients auf die IC-VPN-Infopage auf der Lotuswurzel zugreifen können, egal an welchem Gate sie angemeldet sind.
        • Methode: Beobachtung auf Clients.
      • Erweiterung: sollten weitere Gates im IC-VPN als zu Wiesbaden gehörig auftauchen (wiesbadenx>), können zusätzlich http://10.207.`x'`.56/infopage und http://fec0::a:cf:`x''`:38/infopage geprüft werden.

   4. Intra-Community Routing: Aufruf von mz-Info auf mz-client

      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Closed Beta
      • benötigt: alle Gates, mindestens ebensoviele Nodes (Mainz) und Clients
      • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein Client angemeldet; Zugriff auf diese Clients
      • Ablauf: Auf den Browsern aller Test-Clients werden die URLs http://10.207.1.37/infopage und http://fec0::a:cf:1:25/infopage aufgerufen.
      • Nachbedingung: Alle Aufrufe der URLs zeigen, dass die Clients auf die IC-VPN-Infopage auf der Spinat zugreifen können, egal an welchem Gate sie angemeldet sind.
        • Methode: Beobachtung auf Clients.
      • Erweiterung: sollten weitere Gates im IC-VPN als zu Mainz gehörig auftauchen (mainzx), können zusätzlich http://10.207.`x'`.37/infopage> und http://fec0::a:cf:`x''`:25/infopage geprüft werden

   5. Inter-Community Routing

      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Closed Beta
      • benötigt: alle Gates, je mindestens ebensoviele Nodes (Mainz und Wiesbaden) und Clients im Wiesbadener und Mainz Netz
      • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein wi-Client und ein mz-Client angemeldet; Zugriff auf diese Clients
      • Ablauf: Mainzer Clients pingen Wiesbadener Clients über IPv4 und IPv6 und vice versa.
      • Nachbedingung: Alle Ping Befehle sind erfolgreich.
        • Methode: Beobachtung auf Clients.

   6. Inter-City Routing 1

      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Closed Beta
      • benötigt: alle Gates, je mindestens ebensoviele Nodes (Mainz und Wiesbaden) und Clients im Wiesbadener und Mainz Netz
      • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein wi-Client und ein mz-Client angemeldet; Zugriff auf diese Clients; Hamburger infopage prinzipiell erreichbar
      • Ablauf: Auf den Browsern aller Test-Clients werden die URLs http://10.207.0.62/infopage und http://fec0::a:cf:0:3e/infopage aufgerufen.
      • Nachbedingung: Alle Aufrufe der URLs zeigen, dass die Clients auf die Hamburger IC-VPN-Infopage zugreifen können.
        • Methode: Beobachtung auf Clients.
      • Alternative: Infopage einer anderen Community nutzen.

   7. Inter-City Routing 2

      • FIXME: Dienst in einer anderen Community für diesen Test ausfindig machen
      • Kategorie: routing
      • Durchführung: manuell
      • ab Milestone: Closed Beta
      • benötigt: alle Gates, je mindestens ebensoviele Nodes (Mainz und Wiesbaden) und Clients im Wiesbadener und Mainz Netz
      • Vorbedingungen: DNS-Testfälle bestenden; mindestens an jedem zu testenden Gate ist ein wi-Client und ein mz-Client angemeldet; Zugriff auf diese Clients; Dienst prinzipiell erreichbar
      • Ablauf: Dienst aufgerufen, vie DNS-Namen.
      • Nachbedingung: Alle Aufrufe der URLs zeigen, dass die Clients auf Dienst zugreifen können.
        • Methode: Beobachtung auf Clients.
      • Alternative: anderen Dienst nutzen

2. DNS-Testfälle

   1. interne Namensauflösung
   • Kategorie: DNS
   • Durchführung: manuell
   • ab Milestone: Closed Beta
   • benötigt: alle Gates, je mindestens ebensoviele Nodes (Mainz und Wiesbaden) und Clients im Wiesbadener und Mainzer Netz
   • Vorbedingungen: mindestens an jedem zu testenden Gate ist ein wi-Client und ein mz-Client angemeldet; Zugriff auf diese Clients; dort nslookup oder dig vorhanden
   • Ablauf: gate23.ffmz.org und gate23.ffwi.org und resultierende v4- und v6-Adressen wieder rückwärts auflösen
   • Nachbedingung: alle Auflösungen liefern aus beiden Netzen korrekte Ergebnisse
     • Methode: Beobachtung auf Clients.

3. Inter-City Namensauflösung * Kategorie: DNS * Durchführung: manuell * ab Milestone: Closed Beta * benötigt: alle Gates, je mindestens ebensoviele Nodes (Mainz und Wiesbaden) und Clients im Wiesbadener und Mainz Netz * Vorbedingungen: mindestens an jedem zu testenden Gate ist ein wi-Client und ein mz-Client angemeldet; Zugriff auf diese Clients; dort nslookup oder dig vorhanden * Ablauf: DNS Namen und resultierende v4- und v6-Adressen wieder rückwärts auflösen (anderer übers ICVPN verbundene Communities) * DNS-Namen: (http://hamburg.freifunk.net/wo-wird-gefunkt#Dienste Hamburg), (https://github.com/MetaMeute/ffhl-dns Lübeck) * Nachbedingung: alle Auflösungen liefern aus beiden Netzen korrekte Ergebnisse

   • Methode: Beobachtung auf Clients.

4. failover-Testfälle

5. Ausfall eines Gates * Kategorie: failover * Durchführung: manuell * ab Milestone: Closed Beta * s. a.: Details * benötigt: mindestens zwei Gates, mindestens doppelt so viele Nodes und wiederum doppelt so viele Clients * Vorbedingungen: jedes Gate wurde von mindestens einem wi-Node und einem mz-Node gewählt; mindestens ein Client ist an jedem Node angemeldet; an jedem Node steht ein zusätzlicher Reserve-Client bereit (noch nicht eingewählt); Zugriff auf alle Clients * Ablauf: Es wird der Ausfall eines Gates simuliert, indem dieses von beiden fastd-Wolken getrennt wird. Danach (!) werden die Reserve-Clients ebenfalls am Netz angemeldet. * Nachbedingung: Alle Reserve-Clients konnten sich problemfrei am Netz anmelden - über ein noch funktionierendes Gate. Die vorher schon angemeldeten Clients erhalten nach spätestens 5 Minuten einen neuen Satz IP-Konfig per DHCP und können danach weiterarbeiten.

   • Methode: Beobachtung auf Clients (und Karte?).

6. ...

Ausfallszenarien

Prosa Testformulierungen, um auftretbare Störungen und deren Folgen sowie Fehlerbehandlung zu beleuchten.

• Ein Freifunk-Gateway fällt komplett aus

  • Erwartete Folgen:
    • keine essentiellen solange noch mindestens ein Gateway funktioniert
    • B.A.T.M.A.N Adv auf den Freifunk Knoten wählt ein anderes Gateway
    • A.L.F.R.E.D Daten bleiben erhalten, solange eine weitere Master Instanz auf einem verbleibenden Gateway läuft
    • A.L.F.R.E.D Daten, die das Gateway selbst announced hat agen aus
    • Clients erhalten nach Ablauf der Leasetime (5 Minuten) eine neue IP-Adresse + Gateway (IPv4)
    • Auf den Freifunk Knoten fällt eine der zwei fastd Verbindungen weg. Wenn noch weitere Gateways verfügbar sind, wird eine neue zweite Verbindung aufgebaut
  • technische Tasks:
    • Gateway wiederbeleben
  • Erwartetes Verhalten nach Wiederbelebung:
    • Freifunk Knoten bauen fastd Verbindung auf
    • B.A.T.M.A.N Adv auf Freifunk Knoten wählen evtl. dieses Gateway als Gateway
    • Clients erhalten IP + DNS + Gateway (IPv4 + IPv6)
  • Bemerkungen:
    • Case ist anwendbar bis das letzte Gateway ausfällt

• DHCP-Server auf einem Gateway fällt aus

  • Erwartete Folgen:
    • schon bediente Clients können ihr DHCP-Lease nicht erneuern (IPv4)
    • neue Clients erhalten keine IP + DNS + Gateway (IPv4)
    • Clients können weiterhin über IPv6 kommunizieren (sowohl im Freifunk Netz als auch ins Internet)
  • technische Tasks zur Problembehandlung:
    • zyklisches Prüfen ob der DHCP-Server läuft
    • B.A.T.M.A.N Adv Gateway-Flag entziehen
    • DHCP-Server stoppen (B.A.T.M.A.N Adv Multicast Optimierungen müssen geprüft werden -> DHCP Renew (siehe: https://github.com/freifunk-mwu/ffctl/issues/5))
    • radvd kann weiter laufen (B.A.T.M.A.N Adv Multicast Optimierungen müssen geprüft werden)
  • technische Tasks nach Wiederbelebung:
    • B.A.T.M.A.N Adv Gateway-Flag wieder setzen
    • DHCP Server starten
  • Erwartetes Verhalten nach Wiederbelebung:
    • Im B.A.T.M.A.N Adv wird dieses Gate wieder als Gateway geführt
    • Clients erhalten IP + DNS + Gateway (IPv4)
  • Bemerkungen:
    • Case ist anwendbar bis der letzte DHCP-Server bzw. das letzte Gateway ausfällt

• DNS-Server (Slave) auf einem Gateway fällt aus

  • Erwartete Folgen:
    • keine essentiellen solange noch mindestens ein DNS-Server bzw. ein Gateway funktioniert
      • per DHCP sowie Router Advertisments werden alle zur Verfügung stehenden DNS Server verteilt
  • technische Tasks
    • zyklisches Prüfen ob der DNS-Server läuft
    • DNS-Server wiederbeleben
  • Erwartetes Verhalten nach Wiederbelebung:
    • DNS-Server gleicht Zonen mit dem DNS Master ab
    • DNS-Server beantwortet DNS-Anfragen von Clients

• DNS-Server (Master Freifunk intern) fällt aus

  • Erwartete Folgen:
    • keine DNS Änderungen mehr möglich
    • für Clients zunächst keine essentiellen solange noch mindestens ein Slave auf einem Gateway funktioniert
      • per DHCP sowie Router Advertisments werden alle zur Verfügung stehenden DNS Server verteilt
    • Wird das Problem nicht innerhalb des "expire" Timers gelöst, beantworten auch die Slaves keine Anfragen mehr (momentan 28 Tage)
  • technische Tasks
    • zyklisches Prüfen ob der DNS-Server läuft
    • DNS-Server wiederbeleben
  • Erwartetes Verhalten nach Wiederbelebung:
    • DNS-Server kann Slaves wieder mit Zonen beliefern
    • DNS-Server beantwortet DNS-Anfragen von Clients
    • DNS Änderungen wieder möglich

• fastd auf einem Gateway fällt aus

  • Erwartete Folgen:
    • Verbleibende Gateways sowie Freifunk Knoten, die zu diesem Gateway eine fastd Verbindung aufgebaut hatten, verlieren fastd Verbindung zu diesem Gateway
      • nicht essentiell solange noch mindestens eine fastd Instanz auf einem verbleibenden Gateway aktiv ist
    • B.A.T.M.A.N Adv auf Freifunk Knoten wählen neues Gateway (wenn das jetzige das betroffene Gateway war)
      • schon bediente Clients erhalten nach Ablauf der DHCP-Leasetime eine neue IP + DNS + Gateway (IPv4)
      • neue Clients erhalten IP + DNS + Gateway (IPv4) von einem anderen Gateway
    • Router Advertisments bleiben aus
      • IPv6 Adressen der Freifunk Knoten und Clients bleiben erhalten aufgrund RAs anderer Gateways
  • technische Tasks:
    • zyklisches Prüfen ob fastd läuft
    • fastd wiederbeleben
  • Erwartetes Verhalten nach Wiederbelebung:
    • fastd Verbindungen zu anderen Gates werden aufgebaut
    • Freifunk Knoten können fastd Verbindung wieder aufbauen

• radvd auf einem Gateway fällt aus

  • Erwartete Folgen:
    • keine essentiellen, solange noch mindestens ein radvd auf einem verbleibenden Gateway läuft (B.A.T.M.A.N Adv Multicast Optimierungen müssen geprüft werden)
  • technische Tasks:
    • zyklisches Prüfen ob radvd läuft
    • radvd wiederbeleben
  • Erwartetes Verhalten nach Wiederbelebung:
    • radvd sendet RAs

• radvd auf allen Gateways fällt aus

  • Erwartete Folgen:
    • Freifunk Knoten und Clients erhalten keine IPv6 Default Route und keine DNS Server mehr (nur über RAs der Gateways)
    • Freifunk Knoten und Clients behalten ihre IPv6 Adressen, da jeder Knoten weiterhin RAs verschickt
    • Freifunk Knoten und Clients bleiben weiterhin über IPv6 im Freifunk Netz erreichbar
    • Je nach Implementierung (DNS und/oder IP) funktioniert die Autoupdater Funktion der Freifunk Knoten nicht mehr
    • Community übergreifende Kommunikation per IPv6 nicht mehr möglich
  • technische Tasks:
    • zyklisches Prüfen ob radvd läuft
    • radvd wiederbeleben
  • Erwartetes Verhalten nach Wiederbelebung:
    • radvd sendet RAs
    • Freifunk Knoten und Clients erhalten Default Route und DNS Server per RAs
    • Community übergreifende Kommunikation per IPv6 wieder möglich