Especificacions de proves de validació » Historial » Revisió 39
Revisió 38 (Victor Oncins, 14-03-2012 16:29) → Revisió 39/41 (Victor Oncins, 25-03-2012 23:18)
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. Com a eina de mesura pot ser emprat netperf. *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. Caldrà avaluar el temps que es triga en restablir la connectivitat de capa de xarxa en cas que un dels nodes perdi l'enllaç amb el qual transmet o rep els paquets. Una possible metodologia pot ser la de considerar que una connexió és restablerta sii el ping cap a la IPv4 del node és restablert i per tant, aquest temps es pot mesurar com el temps de restabliment de ping. *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 des del qual hi haurà encaminament redundat cap a Internet. El node CN ha triat el gateway GN1 per encaminar els paquets a Internet. Un host intern connectat 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). Una possible metodologia pot ser la de considerar que una connexió és restablerta sii el ping cap a la IPv4 del node és restablert i per tant, aquest temps es pot mesurar com el temps de restabliment de ping. *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 un 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. *Ref:* P6 *Títol:* Gestió d'interfícies a través de LuCi *Descripció:* Aquesta prova té com objectiu avaluar si les modificacions dels rols vinculats a les interfícies de xarxa des de la URL @/cgi-bin/luci/qmp/network/@ tenen l'efecte desitjat. Considerem tres tipus d'interfícies, les quals només poden tenir determinats rols: # 802.3@10/100Mbps (C) :: LAN, WAN i VOID # 802.11@5GHz (W5) :: MESH i VOID # 802.11@2,4GHz (W24) :: LAN i VOID La prova cal fer-la sobre un node amb disposició de connectar directament a Internet. La taula següent conté els resultats esperats en funció de la combinació de rols |\3=.Rols possibles |\7=.Resultats esperats | |_.C |_.W5 |_.W24 |_.br-lan |_.DHCP server |_.DHCP client |_.BMX6 |_.OLSR |_.Internet |_.Splash | | VOID | VOID | LAN | W24 | SI | NO | NO | NO | NO | NO | | VOID | MESH | VOID | W24 | SI | NO | SI | SI | NO | NO | | VOID | MESH | LAN | W24 | NO | NO | SI | SI | NO | NO | | LAN | VOID | VOID | C | SI | NO | NO | NO | NO | NO | | LAN | VOID | LAN | C,W24 | SI | NO | NO | NO | NO | NO | | LAN | MESH | VOID | C | SI | NO | SI | SI | NO | NO | | LAN | MESH | LAN | C,W24 | SI | NO | SI | SI | NO | NO | | WAN | VOID | VOID | VOID | NO | SI | NO | NO | NO | NO | | WAN | VOID | LAN | W24 | SI | SI | NO | NO | SI | SI | | WAN | MESH | VOID | VOID | NO | SI | SI | SI | NO | NO | | WAN | MESH | LAN | W24 | SI | SI | SI | SI | SI | SI | *SI* : és requerit que el servei funcioni. *NO* : no és requerit que el servei funcioni. *Ref:* P7 *Títol:* Accés segur a la WLAN d'usuaris *Descripció:* *(Funcionalitat no implementada)* Comprovar si un usuari pot ser autenticat i es permet el xifrat de l'accés ràdio pels següents protocols de seguretat: * WPA/WPA2 * Xifrat AES i TKIP * Autenticat PSK i EAP *Ref:* P8 *Títol:* Representació gràfica de nodes i enllaços *Descripció:* Es pretén avaluar la resposta de la funció de Mapa de manera que, des de cert CN/GN, els enllaços representats corresponguin als enllaços establerts per BMX6 amb la resta de nodes. Tot seguit determinarem un conjunt d'escenaris que permetran posar a prova la resposta del firmware, basats en les proves anteriors. Un factor important és la determinació del número de nodes GN en una xarxa de nodes QM. Denotarem per @QM m/n@ una xarxa de n-nodes amb m-nodes en mode gateway. A menys que s'especifiqui el contrari tots els nodes seran idèntics tant en maquinari com el release de firmware. *Ref:* P9 *Títol:* Descàrregues de d'arxius de mida gran *Descripció:* Comprovar si la descàrrega d'un arxiu de mida gran (>50MB) es du a terme correctament *Ref:* P10 *Títol:* Mode roaming *Descripció:* Comprovar la integritat d'una sessió TCP quan un client passa d'un AP a un altre, quan hi ha activat l'esquema d'adreçament non-overlapping. *Ref:* E0 *Títol:* Sense especificar *Descripció:* Sense determinar *Ref:* E1 *Títol:* Xarxa @QM m/n@ de curt abast amb baixa càrrega de trànsit *Descripció:* Considerem una xarxa @QM m/n@ on m i n estaran determinats per la disponibilitat del material i recursos del laboratori. La distància entre nodes serà la de la sala de proves. Relació de proves: *Revisió emprada:* http://qmp.cat/projects/qmp/repository/show?branch=testing&rev=468783c |_.@m(GN)@ |_.@n(Total)@ |_.Proves | | 0 | >=3 | P1, P2, P8, P9, P10 | | 1 | >=3 | P4, P5, P8, P9, P10 | | 2 | >=3 | P3, P8, P9, P10 | *Resultats:* Hem fet proves P3 i P8 amb n=4 i m=2 amb el mateix hardware (Monster). m=2. La prova P3 ha donat com a resultat un correcte reencaminament extern. El temps de balanceig va ser d'uns 20s amb el client connectat a un CN. La prova P8 va donar com resultat que els enllaços entre nodes es representen correctament però no s'actualitzen al cap cert temps. La prova P9 s'ha fet amb dos GN però sense interrompre connexió a Internet de cap dels dos. Ha donat com a resultat que la connexió s'ha interromput sempre al poc temps d'iniciada la descàrrega. La prova P10 ha mostrat, amb un sol GN, que la connexió TCP s'interromp quan hi ha canvi d'AP com a conseqüència de la moviment del client. Apèndix: Per la mateixa prova amb un node gateway amb hardware alternatiu (NS5,...)