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	T	Aufruf von wi-Info auf wi-client
1.4	rt	m	T	[Inter Community Routing](#rt_wi_mz"Mainzer Clients pingen Wiesbadener Clients über IPv4 und IPv6 und vice versa.")
2.1	fo	m	T	Ausfall eines Gates

Testfälle

1. Routing-Testfälle

2. Aufruf von tmp.to auf wi-client * Kategorie: routing * Durchführung: manuell * ab Milestone: ? * 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.

3. Aufruf von tmp.to auf mz-client * Kategorie: routing * Durchführung: manuell * ab Milestone: ? * 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.

4. Aufruf von wi-Info auf wi-client * Kategorie: routing * Durchführung: manuell * ab Milestone: ? * 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://10.207.0.56/infopage aufgerufen. * Nachbedingung: Alle Aufrufe von http://10.207.0.56/infopage 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.

5. Inter Community Routing * Kategorie: routing * Durchführung: manuell * ab Milestone: ? * benötigt: alle Gates, mindestens ebensoviele Nodes (Mainz und Wiesbaden) und Clients im Wiesbadener und Mainz Netz * Vorbedingungen: mindestens an jedem zu testenden Gate ist ein 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. failover-Testfälle

7. Ausfall eines Gates * Kategorie: failover * Durchführung: manuell * ab Milestone: ? * 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?).

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