Especificacions de proves de validació » Historial » Revisió 9
Revisió 8 (Victor Oncins, 24-02-2012 11:01) → Revisió 9/41 (Victor Oncins, 24-02-2012 11:11)
h1. Proves per alliberar release de producció (Esborrany) L'objecte de les proves prèvies d'alliberament de release és avaluar la release considerada de preproducció i obtenir mesures de rendiment. Aquests aspectes són important per tal de d'obtenir informació de les limitacions del firmware desenvolupat i permetre que les futures iteracions del desenvolupament incorporin modificacions i millores concretes. Tot seguit definirem un grup de proves i un d'escenaris. Una prova és un procediment pel qual es mesura un conjunt d'un o més paràmetres relatius al funcionament de la release. El resultat d'aquesta mesura serà tant quantitatiu com sigui possible. En general hi hauran proves de rendiment i proves de qualitat. Una prova de rendiment és aquella que el/els paràmetres avaluats tans sols seran emprats per conèixer els límits operatius del firmware. Per exemple, una prova pot ser la mesura de la capacitat dels enllaços ràdio de la malla de nodes QM. Una prova de qualitat és aquella en que el/els paràmetres avaluats seran comparats amb valors de referència sota cert criteri. Les proves de qualitat permetran saber si la release supera o no el llindar de qualitat fixat. Per exemple, una prova de qualitat és avaluar si una xarxa QM permet l'establiment de N-protocols de capa d'aplicació o de transport (P2P,...) des de la LAN de hosts (clients). En funció del resultat la prova es supera o no. D'altra banda un escenari és un certa disposició de nodes sobre els quals s'hi aplica un conjunt de proves. Podem considerar que un escenari és un conjunt de proves contextualitzades i per tant, aportaria més informació que l'avaluació de proves aïllades. h2. Proves proposades Tot seguit descrivim algunes de les proves bàsiques referenciades amb la notació Pn, on n és un enter 0,1,2,3... *Ref:* P0 *Títol:* Sense especificar *Descripció:* Sense determinar *Ref:* P1 *Títol:* Capacitat mesh entre dos nodes QM *Descripció:* Avaluació de l'ample de banda disponible entre dos nodes QM. El resultat de la prova haurà de donar com a mínim el valor de la màxima transferència TCP amb diferents mides de paquets (a determinar). Si és possible hauria d'incloure també la màxima transferència UDP amb diferents mides de paquets. *Ref:* P2 *Títol:* Temps de reencaminament intern *Descripció:* Considerem dos nodes QM client (CN) entre els quals és possible l'encaminament per camí redundant, entre els quals hi ha una connexió TCP o UDP. Caldrà avaluar el temps que es triga en restablir la connexió TCO o UDP en cas que un dels nodes perdi l'enllaç amb el qual transmet o rep els paquets. Es considera que es pot emprar qualsevol protocol de capa d'aplicació. *Ref:* P3 *Títol:* Temps de reencaminament extern *Descripció:* Considerem una xarxa QM amb dos nodes gateway (GN) i com a mínim un CN amb el qual hi haurà encaminament redundant. El node CN ha triat el gateway GN1 per encaminar els paquets a Internet. Un host intern situat a CN estableix una connexió amb un host d'Internet. Mesurar el temps mínim que trigaria el host intern a restablir la connexió amb el host d'Internet en cas d'absència d'anunci de disponibilitat d'Internet de GN1 (per exemple, desconnexió de l'enllaç amb Inet o desconnexió total de GN1 de la xarxa). *Ref:* P4 *Títol:* Establiment de sessions típiques *Descripció:* Donat un CN integrat a una xarxa QM i amb un host connectat, provar el correcte establiment de sessions amb servidors/hosts d'Internet amb el protocols de capa d'aplicació i de transport següents: P2P, POP, SMTP,(altres de correu), FTP, ToIP (SIP, multimèdia), HTTP, HTTPS, SSL, (més...) *Ref:* P5 *Títol:* Ubiqüitat del mode "roaming" *Descripció:* En una configuració típica de xarxa QM tots els nodes tenen una accés sense-fils pels hosts clients en mode gestionat (AP). Aquest accés està configurat amb un mateix SSID. L'objectiu és permetre la ubiqüitat de la connexió (no de la mobilitat). És a dir, un host client pot vincular-se a qualsevol AP sense necessitat que l'usuari es registri sota un nou SSID. Comprovar doncs que un host client es connecti correctament sota un SSID[falta estudiar millor el mecanisme de d'associació per SSID en presència de 2 AP amb el mateix SSID i mateix/diferent canal] *Ref:* P6 *Títol:* Gestió d'interfícies a través de LuCi *Descripció:* Aquesta prova té com objectiu avaluar si Comprovació de les modificacions dels rols vinculats a les interfícies de xarxa des de la URL /cgi-bin/luci/qmp/network/ tenen l'efecte desitjat. | head1 | head 2 | head foo | bar | | foo | | bar | baz | següents funcionalitat Canvis LAN devices Pàgina: /cgi-bin/luci/qmp/network/ -> Mirar si el canvi es posa al bridge -> Dona DHCP -> BMX/OLSR funcionen? Canvis WAN devices Pàgina: /cgi-bin/luci/qmp/network/ -> Conectar Servidor DHCP, amb internet -> Funciona Splash -> BMX/OLSR funcionen? Canvis MESH devices Pàgina: /cgi-bin/luci/qmp/network/ -> BMX/OLSR funcionen? *Ref:* P7 *Títol:* Interfície de gestió *Descripció:*