Especificacions de proves de validació » Historial » Versió 39
Victor Oncins, 25-03-2012 23:18
1 | 4 | Victor Oncins | h1. Proves per alliberar release de producció (Esborrany) |
---|---|---|---|
2 | 2 | Victor Oncins | |
3 | 1 | Victor Oncins | 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. |
4 | |||
5 | 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. |
||
6 | |||
7 | 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. |
||
8 | |||
9 | 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. |
||
10 | |||
11 | 5 | Victor Oncins | h2. Proves proposades |
12 | 1 | Victor Oncins | |
13 | Tot seguit descrivim algunes de les proves bàsiques referenciades amb la notació Pn, on n és un enter 0,1,2,3... |
||
14 | |||
15 | 4 | Victor Oncins | *Ref:* P0 |
16 | *Títol:* Sense especificar |
||
17 | *Descripció:* Sense determinar |
||
18 | 1 | Victor Oncins | |
19 | 4 | Victor Oncins | *Ref:* P1 |
20 | *Títol:* Capacitat mesh entre dos nodes QM |
||
21 | 22 | Victor Oncins | *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. |
22 | 1 | Victor Oncins | |
23 | 4 | Victor Oncins | *Ref:* P2 |
24 | *Títol:* Temps de reencaminament intern |
||
25 | 22 | Victor Oncins | *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. |
26 | 1 | Victor Oncins | |
27 | 4 | Victor Oncins | *Ref:* P3 |
28 | *Títol:* Temps de reencaminament extern |
||
29 | 23 | Victor Oncins | *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. |
30 | 1 | Victor Oncins | |
31 | 4 | Victor Oncins | *Ref:* P4 |
32 | *Títol:* Establiment de sessions típiques |
||
33 | *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...) |
||
34 | 1 | Victor Oncins | |
35 | 4 | Victor Oncins | *Ref:* P5 |
36 | *Títol:* Ubiqüitat del mode "roaming" |
||
37 | 27 | Victor Oncins | *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. |
38 | 1 | Victor Oncins | |
39 | 4 | Victor Oncins | *Ref:* P6 |
40 | 8 | Victor Oncins | *Títol:* Gestió d'interfícies a través de LuCi |
41 | 23 | Victor Oncins | *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: |
42 | 1 | Victor Oncins | |
43 | 23 | Victor Oncins | # 802.3@10/100Mbps (C) :: LAN, WAN i VOID |
44 | 18 | Victor Oncins | # 802.11@5GHz (W5) :: MESH i VOID |
45 | 19 | Victor Oncins | # 802.11@2,4GHz (W24) :: LAN i VOID |
46 | 1 | Victor Oncins | |
47 | 17 | Victor Oncins | 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 |
48 | 20 | Victor Oncins | |
49 | 21 | Victor Oncins | |\3=.Rols possibles |\7=.Resultats esperats | |
50 | 14 | Victor Oncins | |_.C |_.W5 |_.W24 |_.br-lan |_.DHCP server |_.DHCP client |_.BMX6 |_.OLSR |_.Internet |_.Splash | |
51 | 13 | Victor Oncins | | VOID | VOID | LAN | W24 | SI | NO | NO | NO | NO | NO | |
52 | | VOID | MESH | VOID | W24 | SI | NO | SI | SI | NO | NO | |
||
53 | 14 | Victor Oncins | | VOID | MESH | LAN | W24 | NO | NO | SI | SI | NO | NO | |
54 | 13 | Victor Oncins | | LAN | VOID | VOID | C | SI | NO | NO | NO | NO | NO | |
55 | | LAN | VOID | LAN | C,W24 | SI | NO | NO | NO | NO | NO | |
||
56 | | LAN | MESH | VOID | C | SI | NO | SI | SI | NO | NO | |
||
57 | | LAN | MESH | LAN | C,W24 | SI | NO | SI | SI | NO | NO | |
||
58 | | WAN | VOID | VOID | VOID | NO | SI | NO | NO | NO | NO | |
||
59 | | WAN | VOID | LAN | W24 | SI | SI | NO | NO | SI | SI | |
||
60 | | WAN | MESH | VOID | VOID | NO | SI | SI | SI | NO | NO | |
||
61 | 1 | Victor Oncins | | WAN | MESH | LAN | W24 | SI | SI | SI | SI | SI | SI | |
62 | |||
63 | *SI* : és requerit que el servei funcioni. *NO* : no és requerit que el servei funcioni. |
||
64 | 23 | Victor Oncins | |
65 | *Ref:* P7 |
||
66 | *Títol:* Accés segur a la WLAN d'usuaris |
||
67 | 24 | Victor Oncins | *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: |
68 | 23 | Victor Oncins | * WPA/WPA2 |
69 | 1 | Victor Oncins | * Xifrat AES i TKIP |
70 | 24 | Victor Oncins | * Autenticat PSK i EAP |
71 | |||
72 | *Ref:* P8 |
||
73 | *Títol:* Representació gràfica de nodes i enllaços |
||
74 | *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. |
||
75 | 25 | Victor Oncins | |
76 | 29 | Victor Oncins | 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. |
77 | 26 | Victor Oncins | |
78 | 30 | Victor Oncins | *Ref:* P9 |
79 | *Títol:* Descàrregues de d'arxius de mida gran |
||
80 | *Descripció:* Comprovar si la descàrrega d'un arxiu de mida gran (>50MB) es du a terme correctament |
||
81 | |||
82 | 31 | Victor Oncins | *Ref:* P10 |
83 | *Títol:* Mode roaming |
||
84 | 34 | Victor Oncins | *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. |
85 | 30 | Victor Oncins | |
86 | 31 | Victor Oncins | |
87 | |||
88 | 26 | Victor Oncins | *Ref:* E0 |
89 | *Títol:* Sense especificar |
||
90 | *Descripció:* Sense determinar |
||
91 | |||
92 | *Ref:* E1 |
||
93 | 29 | Victor Oncins | *Títol:* Xarxa @QM m/n@ de curt abast amb baixa càrrega de trànsit |
94 | 1 | Victor Oncins | *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: |
95 | 38 | Victor Oncins | *Revisió emprada:* http://qmp.cat/projects/qmp/repository/show?branch=testing&rev=468783c |
96 | 1 | Victor Oncins | |
97 | |_.@m(GN)@ |_.@n(Total)@ |_.Proves | |
||
98 | 33 | Victor Oncins | | 0 | >=3 | P1, P2, P8, P9, P10 | |
99 | | 1 | >=3 | P4, P5, P8, P9, P10 | |
||
100 | 32 | Victor Oncins | | 2 | >=3 | P3, P8, P9, P10 | |
101 | 30 | Victor Oncins | |
102 | 39 | Victor Oncins | *Resultats:* Hem fet proves P3 i P8 amb n=4 i m=2 amb el mateix hardware (Monster). |
103 | 32 | Victor Oncins | 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. |
104 | 38 | Victor Oncins | La prova P8 va donar com resultat que els enllaços entre nodes es representen correctament però no s'actualitzen al cap cert temps. |
105 | 1 | Victor Oncins | 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. |
106 | 39 | Victor Oncins | 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. |
107 | |||
108 | Apèndix: Per la mateixa prova amb un node gateway amb hardware alternatiu (NS5,...) |