Metodología de testing de software para mitigar riesgos en la

Transcripción

Metodología de testing de software para mitigar
riesgos en la adopción de IPv6
LACNIC - ASSE
18 de mayo de 2015
Laura
Elimin
Laura
Elimin
Laura
Elimin
Índice
Laura
ÍNDICE ....................................................................................................................................................................... 2 Laura
1. INTRODUCCIÓN ................................................................................................................................................. 4 Elimin
Elimin
Laura
OBJETIVO .......................................................................................................................................................................... 4 ACTORES ........................................................................................................................................................................... 4 ORGANIZACIÓN DEL DOCUMENTO ........................................................................................................................................... 5 Elimin
2. ETAPAS .............................................................................................................................................................. 6 Laura
PLANIFICACIÓN DE LAS PRUEBAS ............................................................................................................................................. 6 DISEÑO DE PRUEBAS ............................................................................................................................................................ 6 CONFIGURACIÓN DE LAS APLICACIONES Y DEL AMBIENTE ............................................................................................................. 7 EJECUCIÓN DE PRUEBAS ........................................................................................................................................................ 7 EVALUACIÓN DE LAS PRUEBAS ................................................................................................................................................ 7 3. ACTIVIDADES ..................................................................................................................................................... 8 E1 -‐ PLANIFICACIÓN DE LAS PRUEBAS ...................................................................................................................................... 8 E1A1 – Estudio de la arquitectura del sistema ........................................................................................................... 8 E1A2 – Determinación del alcance de las pruebas ..................................................................................................... 9 E1A3 – Priorización de funcionalidades ...................................................................................................................... 9 E2 -‐ DISEÑO DE LAS PRUEBAS .............................................................................................................................................. 10 E2A1 – Definición de la estrategia de testing ........................................................................................................... 10 E2A2 – Diseño de casos de prueba y misiones de testing exploratorio .................................................................... 11 E2A3 – Validación de casos de prueba y misiones de testing exploratorio .............................................................. 13 E3 – CONFIGURACIÓN DE LAS PRUEBAS ................................................................................................................................. 13 E3A1 – Armado de ambiente IPv4 ............................................................................................................................ 13 E3A2 – Armado de ambiente IPv6 ............................................................................................................................ 13 E3A3 – Documentación de la configuración de ambientes ...................................................................................... 14 E4 – EJECUCIÓN DE LAS PRUEBAS ......................................................................................................................................... 14 E4A1 – Ejecución en sistema bajo prueba IPv4 ........................................................................................................ 14 E4A2 – Ejecución en sistema bajo prueba IPv6 ........................................................................................................ 14 E4A3 – Pruebas de regresión .................................................................................................................................... 14 E5 – EVALUACIÓN DE LAS PRUEBAS ....................................................................................................................................... 14 E5A1 – Revisión de las pruebas ................................................................................................................................ 14 E5A2 – Determinación del nivel de certificación ...................................................................................................... 15 E5A3 – Mejora de la base de conocimiento ............................................................................................................. 15 4. ROLES .............................................................................................................................................................. 16 Laura
Elimin
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
LÍDER DE TESTING .............................................................................................................................................................. 16 TESTER ............................................................................................................................................................................ 16 EXPERTO EN IPV6 ............................................................................................................................................................. 16 EVALUADOR ..................................................................................................................................................................... 16 Laura
5. CERTIFICACIÓN ................................................................................................................................................ 17 Laura
IPV6USERAPP .................................................................................................................................................................. 17 IPV6FULLAPP ................................................................................................................................................................... 18 IPV6USERSERVICE ............................................................................................................................................................ 18 IPV6FULLSERVICE ............................................................................................................................................................. 19 IPV6SYSTEM .................................................................................................................................................................... 19 RESUMEN COMPARATIVO .................................................................................................................................................... 19 6. DOCUMENTACIÓN REQUERIDA PARA LA VALIDACIÓN ..................................................................................... 20 PLANIFICACIÓN DE LAS PRUEBAS ........................................................................................................................................... 20 Documento de arquitectura del sistema .................................................................................................................. 20 Inventario de pruebas .............................................................................................................................................. 21 Elimin
Laura
Elimin
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
DISEÑO DE PRUEBAS .......................................................................................................................................................... 22 Inventario de pruebas con la estrategia de pruebas ................................................................................................ 22 Documento con casos de prueba diseñados ............................................................................................................. 23 Documento con misiones de testing exploratorio .................................................................................................... 23 CONFIGURACIÓN DE LAS PRUEBAS ......................................................................................................................................... 24 Documento de armado de ambientes ...................................................................................................................... 24 EJECUCIÓN DE PRUEBAS ...................................................................................................................................................... 24 Registro de ejecución de casos de prueba y sesiones de testing exploratorio .......................................................... 24 Capturas de tráfico ................................................................................................................................................... 24 Incidentes detectados y corregidos .......................................................................................................................... 24 7. GLOSARIO ........................................................................................................................................................ 26 Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Laura
Elimin
Centro de Ensayos de Software
1.
Introducción
Objetivo
Existe una gran madurez a nivel de los productos y servicios de comunicaciones respecto a su
cumplimiento de los estándares que definen IPv6. IPv6 es un protocolo maduro, de amplio
desarrollo y soporte, pero de todas formas, su adopción no alcanza de forma significativa a los
usuarios finales.
El presente documento propone una metodología genérica para la prueba de sistemas de
software con foco en IPv6.
Gran parte de los componentes de infraestructura (switches, routers, tarjetas de red, sistemas
operativos, drivers, etc.) soportan IPv6, y se pretende que las aplicaciones maduren en el uso
del protocolo. La presente metodología se define para ayudar a las empresas en el proceso de
adecuación de sus sistemas informáticos para soportar el estándar. Se trata de una orientación
para los expertos en testing y comunicaciones que buscan certificar que cierto sistema opera
adecuadamente sobre IPv6.
El objetivo de la metodología es guiar al equipo certificador en las pruebas de sistemas,
verificando que brindan su funcionalidad en entornos comunicados con IPv6.
Permite al equipo de pruebas y consultores externos, conocer los aspectos más relevantes a
ser evaluados durante las pruebas y llegar al adecuado desarrollo y ajuste de los sistemas.
Actores
La metodología está diseñada considerando cuatro tipos de actores:
1.Organización promotora - LACNIC
§
Centraliza la metodología
§
Determina quiénes son capacitadores autorizados
2.Capacitadores - LACNIC y CES
§
Diseñan y ofrecen capacitaciones sobre la metodología
§
Organización interesada probar sistemas
§
Entienden y promueven la importancia de probar sistemas
§
Capacitar su personal y prueban sus sistemas
3.Testers / Consultores
Página 4
§
Se forman para poder brindan el servicio
§
Son contratados por las organizaciones interesadas
§
Diseñan, ejecutan y documentan las pruebas
§
Identificar los problemas y los corrigen
La metodología se construyó en base a la experiencia del CES (Centro de Ensayos de
Software) en testing y al conocimiento de IPv6 de sus consultores asociados. Para su definición
y validación se probaron los sistemas de LACNIC (organización internacional que forma parte
de la administración de Internet) y que junto a ASSE (prestador de servicios de salud del
estado uruguayo) patrocinaron este trabajo.
La metodología está organizada en etapas que agrupan actividades. Las etapas
generalmente están asociadas con la participación de diferentes roles. Como resultado de la
aplicación de la metodología se obtiene un nivel de certificación de los sistemas informáticos
de la organización.
Organización del documento
El documento está organizado por secciones que abordan las etapas, actividades, roles, niveles
de certificación, documentación requerida y un glosario.
En la segunda sección se presentan las etapas de la metodología y su interacción. Se describe
brevemente el objetivo de cada etapa, sus condiciones de entrada y salida, así como los roles
que participan.
En la tercera sección se profundiza en las actividades que componen cada etapa, explicando en
qué consisten y los actores y roles involucrados.
En la cuarta sección se describen los roles asociados a cada etapa y actividad.
En la quinta sección se describen los niveles de certificación establecidos.
La sexta sección presenta la documentación requerida por el Certificador para evaluar el nivel
de certificación.
La séptima sección presenta un glosario, acordando definiciones para los términos usados en el
documento.
Si bien cada lector podrá detenerse más o menos en cada sección, se recomienda leer todo el
documento a los efectos de conocer los actores involucrados y lograr una visión global de las
etapas y actividades de la metodología.
Página 5
2.
Etapas
La metodología define cinco etapas: Planificación de pruebas, Diseño de pruebas,
Configuración de ambiente de pruebas, Ejecución de pruebas y Evaluación de las pruebas. Las
etapas agrupan actividades vinculadas.
Figura 1 - Etapas
La primera etapa es la Planificación de pruebas, siguen el Diseño de pruebas y la Configuración
de los ambientes de pruebas, que pueden ir en paralelo. Con los ambientes listos se puede
comenzar con la etapa de Ejecución de las pruebas para culminar con la etapa de Evaluación
de las pruebas. Pueden darse iteraciones sucesivas de estas etapas hasta lograr el nivel de
certificación requerido.
A continuación se describe cada una de las etapas.
Planificación de las pruebas
El primer paso en el proyecto es definir qué se va a probar y qué no se va a probar. Las
pruebas puede tener diferentes alcances: se pueden probar todas las funcionalidades de una
de las interfaces (GUI, Web, Servicios Web, Bibliotecas, etc.), y se puede probar todas las
funcionalidades de partes de la aplicación claramente definidas (módulos, subsistemas).
A partir de las interfaces a probar se registran todas las funcionalidades que se proveen.
Luego se evalúa su prioridad para las pruebas según el riesgo que implican cambiar del
protocolo IPv4 al IPv6. En la sección Actividades se profundiza en este aspecto.
Las interfaces y funcionalidades a probar determinan el cubrimiento en extensión de las
pruebas, mientras que su prioridad, determina su cubrimiento en profundidad, o sea la
intensidad de las pruebas.
En el proceso de planificación obtenemos un inventario
funcionalidades a probar priorizadas según el riesgo IPv6.
con
las
interfaces
y
Diseño de pruebas
En esta etapa se define la estrategia de prueba para cada ítem del inventario de pruebas y se
diseñan los casos de prueba y las misiones de testing exploratorio.
Dado que las pruebas tienen el objetivo de detectar problemas con el manejo de las
direcciones IP, se presentan una serie de ideas de prueba relacionadas a los datos que darán
Página 6
al tester herramientas para diseñar casos adaptados al contexto. Es importante identificar
también las funcionalidades asociadas a la comunicación del sistema, porque pueden ser otra
fuente de problemas. Por último, es importante diseñar pruebas asociadas al ambiente en el
cual se ejecuta la aplicación.
Configuración de las aplicaciones y del ambiente
Para la ejecución de todas las pruebas es necesario armar ambientes de pruebas. En primer
lugar, si la aplicación se encontrase trabajando actualmente en IPv6, se creará un ambiente
para ser probada. Si, en cambio, la aplicación se encuentra ejecutando en IPv4 se armará un
ambiente IPv4 para su prueba, considerando el funcionamiento como un oráculo.
Una vez probada, se deberá configurar la aplicación y el ambiente para su funcionamiento bajo
IPv6. La idea fundamental de la configuración es filtrar las interfaces de interés, rechazando
todos los paquetes IPv4. Toda configuración debe ser documentada ya que es un insumo
fundamental para conformar los ambientes de producción.
Eventualmente, en la prueba sobre IPv6 se podrán encontrar errores en el código fuente, en la
configuración de la aplicación, en los componentes del ambiente o en su configuración. Para
ejecutar las pruebas de regresión, se deberá corregir esos errores y documentarlos.
Ejecución de pruebas
En primera instancia, si existe la posibilidad, se prueba la aplicación corriendo en su ambiente
IPv4 (si se tratara de una migración a IPv6). De esta manera, se tendrá información sobre el
estado de la aplicación antes de los cambios (migración o ajustes en el código fuente). Los
errores encontrados no serán atribuidos luego al cambio a IPv6. Estas pruebas son además
una oportunidad para capturar tráfico en las interfaces de interés, a los efectos de validar
experimentalmente cuáles son los servicios que hacen uso de las redes.
Luego, se comienza con la prueba exhaustiva de los ítems del inventario en un ambiente IPv6.
Si el ambiente no logra ser IPv6 puro se monitorizan las interfaces donde pueden viajar
paquetes IPv4.
De existir problemas que no estaban en la versión IPv4 o que pueden ser atribuibles a este
protocolo, se detienen las pruebas hasta su corrección. Con la nueva versión se ejecutan
pruebas de regresión sobre las funcionalidades donde se encontraron problemas y donde
pueden impactar los cambios.
Evaluación de las pruebas
En esta etapa se revisa el material recogido en todo el proceso de trabajo y se lo analiza para
determinar el nivel alcanzado.
El material debe servir de evidencia de que se hicieron las pruebas y se cubrieron los ítems del
inventario, así como que las interfaces que no son IPv6 puras no contienen paquetes IPv4 que
correspondan a la aplicación.
Por último, la organización de pruebas consolida la información y experiencia recogida en el
proyecto, integrándola a su base de conocimiento para este tipo de pruebas.
Página 7
3.
Actividades
A continuación se presenta un diagrama con las actividades y luego una descripción detallada
de cada una.
Figura 2 - Etapas con sus Actividades
E1 - Planificación de las pruebas
E1A1 – Estudio de la arquitectura del sistema
Tanto para la definición de la frontera del sistema a probar como para conocer los puntos de
comunicación con el exterior, es importante analizar la arquitectura del sistema. Si existe
documentación el estudio puede comenzar validando la información, en caso de que no
existiese se deberá consultar a los técnicos correspondientes.
Las interacciones IPv6 buscadas, contextualizadas en la arquitectura, permiten identificar las
fronteras del sistema a analizar durante las pruebas. El siguiente esquema muestra cómo
cambian las fronteras dependiendo de quiénes interactúen en el sistema a nivel de IPv6.
Página 8
3%(*)&1(%0
456
/0/+()1
!-+2
3%(*)&1(%0
&%7+82)9+9)1-%0
:)(%;+22
,-.%(-%.
6+0%07&%
!+.10
$1/.%(
$%&
'()*+&+
!"#
!"#$%'
!"#$%&
Figura 3 - Fronteras del sistema
Si se busca que un sistema con interface Web pueda ser accedido IPv6 por los usuarios finales
desde Internet, la frontera está antes del firewall de la figura. Es posible incluso que en ciertos
casos una traducción de direcciones IPv6 a IPv4 sea suficiente para el propósito.
Si por el contrario se busca explorar la compatibilidad IPv6 en los servidores de aplicaciones de
la figura, las interacciones ya no serían con el usuario final sino con los servidores Web y las
bases de datos, mientras que las interfaces en la frontera son todas aquellas que comunican
estos servidores con el resto del mundo.
E1A2 – Determinación del alcance de las pruebas
En esta actividad se delimita el sistema bajo prueba. En primera instancia se selecciona las
aplicaciones a probar. Luego se seleccionan los módulos o subsistemas y luego las interfaces
que ofrecen.
Se enumeran las funcionalidades a probar, asociando a cada una un identificador numérico, un
detalle y eventuales observaciones.
E1A3 – Priorización de funcionalidades
Para cada funcionalidad se prioriza según el riesgo relativo al uso de IPv6. Esto puede ser
determinado por un experto en el protocolo o por un tester teniendo en cuenta ciertos
aspectos. En base a la experiencia, se sugiere categorizar en tres niveles: ALTA, MEDIA y
BAJA.
Datos IPv6 - Si dentro del inventario aparece una funcionalidad que utiliza como dato una
dirección IP, rango o prefijo, se vuelve necesario verificar su funcionamiento en las distintas
formas en las cuales el estándar permite escribir las direcciones. Este tipo de funcionalidad
seguramente será de ALTA prioridad.
Ejemplo: Funcionalidad de Creación de usuario donde se asocie una dirección o rango a
un usuario particular desde donde podrá acceder al sistema.
Página 9
Comunicaciones - Cualquier funcionalidad que desencadene una comunicación a través de la
frontera establecida para el sistema se priorizará con un nivel MEDIO-ALTO de prioridad.
Ejemplo: Funcionalidad que emite una alerta vía correo electrónico.
Configuraciones - Las funcionalidades que consuman datos de configuración con direcciones
IP estáticas se sugiere sean priorizadas en nivel MEDIO. Aún con los métodos dinámicos (DNS
por ejemplo), hay que tener precaución de que el servicio tenga soporte IPv6 en su
comunicación con el sistema.
Ejemplo: Configuración en WSDLs, archivos XML o de texto plano o en las entradas de
la tabla de hosts.
La prioridad BAJA se asocia a las funcionalidades que no presentan las características
anteriores. De todas maneras, se probarán ya que pueden aparecer problemas no
contemplados en la priorización. Por lo anterior y por otras razones la prioridad puede ser
ajustada durante el ciclo de pruebas.
E2 - Diseño de las pruebas
E2A1 – Definición de la estrategia de testing
Habitualmente se distinguen dos estrategias de testing: planificado y exploratorio.
Se aplica testing planificado cuando se diseñan los casos de prueba previamente y luego se
ejecutan las pruebas, para lo cual se requiere conocer en profundidad el sistema bajo prueba.
Se aplica testing exploratorio cuando se aprende del sistema bajo prueba a través de un
proceso simultáneo de exploración, diseño y ejecución de pruebas. Este aprendizaje suscita el
diseño y ejecución dinámica de nuevas y mejores pruebas, de cuyos resultados se obtiene más
información sobre el producto. El tester tiene en todo momento el control y responsabilidad
por las pruebas que lleva a cabo. En el contexto de esta metodología, el testing exploratorio
combinado con capturas de tráfico en las interfaces de la frontera, puede ser de gran ayuda
para identificar las interacciones IP del sistema con otros componentes.
Los incidentes detectados aplicando ambas estrategias suelen variar y frecuentemente el
testing exploratorio revela riesgos no considerados en el testing planificado que lleva al diseño
de nuevos casos de prueba.
Por lo mencionado, se recomienda fuertemente la aplicación combinada de ambas estrategias
para optimizar la eficacia y eficiencia de las pruebas. La forma en que se combinan depende
del contexto.
Se sugiere definir misiones específicas y ejecutar sesiones de testing exploratorio con pruebas
básicas, para las funcionalidades de prioridad BAJA.
Se sugiere definir misiones generales y ejecutar sesiones de testing exploratorio con pruebas
más incisivas de aspectos o características comunes a todas o varias funcionalidades del
software bajo prueba.
Para las funcionalidades de prioridad MEDIA y ALTA se recomienda diseñar casos de prueba
para atacar con más detalle y rigurosidad la casuística correspondiente. Además se puede
combinar estos casos de prueba con sesiones de testing exploratorio que desafíen aún más el
producto bajo prueba de acuerdo a sus respuestas y a los incidentes encontrados.
Página 10
E2A2 – Diseño de casos de prueba y misiones de testing exploratorio
Tanto las misiones y sesiones de testing exploratorio como las pruebas planificadas
contemplarán los aspectos asociados al uso de IPv6. A modo de ejemplo, se presentan a
continuación ideas, casos y datos de prueba.
Pruebas sobre los datos
Las direcciones y rangos de direcciones pueden introducirse al sistema a través de formularios,
en archivos o directamente en la base de datos. Lo importante es probar distintas variantes
para estudiar, por ejemplo, que el parser de las direcciones las maneja correctamente o que el
sistema reconoce la misma dirección IP a pesar de estar escrita de formas diferentes.
Las direcciones presentadas a continuación están dentro del rango que determina el
RFC 3849, “IPv6 Address Prefix Reserved for Documentation”: 2001:0DB8::/32. Este rango de
direcciones están reservadas para ser usadas en manuales y tutoriales.
•
Ingresar una dirección IPv6 válida.
o
•
Ingresar una dirección comprimida.
o
•
•
o
2001:0db8:0000:0000:0000:0000:1428:57ab
o
2001:0db8:0000:0000:0000::1428:57ab
o
2001:0db8:0:0:0:0:1428:57ab
o
2001:0db8:0::0:1428:57ab
o
2001:0db8::1428:57ab
Ingresar una dirección inválida, el sistema debería rechazarla.
•
::ffff:c0a8:5909
Dirección compatible con IPv4 (ya no se usa pero debería probarse igual).
o
::192.168.89.9
o
::c0a8:5909
Dirección con puerto correcta (con los corchetes).
o
•
::ffff:192.168.89.9
Misma dirección que la anterior.
o
•
2001:db8:2de::e13
Dirección con IPv4 empotrada.
o
•
2001:0db8::25de::cade
Dirección con ceros omitidos.
o
•
2001:0db8:85a3:0000:1319:8a2e:0370:7344
Varios tipos de compresión de la misma dirección IPv6.
o
•
2001:0db8:85a3::1319:8a2e:0370:7344
Ingresar una dirección que se puede comprimir.
o
•
2001:0db8:85a3:08d3:1319:8a2e:0370:7334
[2001:0db8::1428:57ab]:8080
Dirección con puerto incorrecta (sin los corchetes).
Página 11
o
•
2001:0db8:0000:0000:0000:0000:1428:57ab:8080
Verificar validación de que no sea la misma IP.
o
2001:0db8:0000:0000:0000:0000:1428:57ab
o
2001:0db8::1428:57ab
•
Direcciones ULA y/o Global Aggr. según corresponda.
•
Máscaras de -3/0/37/64/75/128/140.
Pruebas de comunicaciones
Es importante ejercitar las funcionalidades que se sabe o se presume que pueden provocar
comunicación entre los componentes y comunicación a través de las fronteras del sistema.
Se sugiere por ejemplo:
•
Provocar la interacción con la base de datos.
o
Alta, modificación, consulta y eliminación de un objeto.
•
Provocar el envío de correos electrónicos.
•
Provocar alarmas.
•
Reestablecer contraseñas.
•
Provocar la conexión a otros sistemas.
o
•
Utilizando funcionalidades que consuman datos de otros sistemas.
Identificar funcionalidades que detecten el país a través de la IP cliente.
o
Esto se da generalmente en el inicio en la aplicación.
•
Separar los componentes (servidor de aplicaciones, DBMS).
•
Ejecutar funcionalidades que utilicen el broadcast (no se maneja igual en las
tecnologías).
•
Revisar registros de sistema IPv6 para auditoría.
o
Usar funcionalidades que generen registros con la IP.
Estas ideas son buenas candidatas para misiones generales de testing exploratorio.
Pruebas de arquitectura y ambiente
A partir de la arquitectura estudiada, identificar los puntos donde el uso de IPv6 pueda generar
problemas.
•
Revisar dónde se encuentran las validaciones.
o
Si las validaciones de IPv6 son a partir de Javascript, estudiando el código HTML.
o
En ese caso se pueden saltar analizando y editando el pedido http con
herramientas como Fiddler (http://www.fiddler2.com/fiddler2/) o Webscarab
(https://www.owasp.org/index.php/Proyecto_WebScarab_OWASP).
•
Si la aplicación está desplegada sobre un cluster, probar la sincronización sobre IPv6.
•
Si el sistema incluye entre sus componentes un firewall, este debe permitir reglas que
manejen direcciones IPV6.
•
Utilizar un DNS vinculando nombres con direcciones IPv6.
Página 12
E2A3 – Validación de casos de prueba y misiones de testing exploratorio
Los casos de prueba y las misiones de testing exploratorio pueden ser validados con un
experto en el protocolo IPv6, así como con expertos en la aplicación de la organización sean
funcionales o testers. En la validación se revisan los casos para ver si son valiosos para
encontrar problemas relativos al protocolo IP, y también si dadas las funcionalidades puntuales
del sistema, se deben agregar casos de prueba no contemplados.
Además, el Certificador debe validar los casos antes de su ejecución para revisar si están
contempladas las variantes importantes y para conocer las pruebas que llevarán a la posterior
certificación. Eventualmente, los Certificadores pueden pedir que se mejoren los casos y se
agreguen los que consideren faltantes.
E3 – Configuración de las pruebas
E3A1 – Armado de ambiente IPv4
En los casos que la aplicación tuviera una versión funcionando aún en IPv4 sería deseable
crear un ambiente de testing para usar la instalación como oráculo de las pruebas.
Esta actividad, por su parte, puede aportar información relevante al tráfico de paquetes IP
entre los componentes. Investigando cómo se comunica el sistema en su interior y hacia el
exterior se entiende mejor dónde pueden encontrarse los problemas de compatibilidad con el
protocolo IPv6.
Pueden utilizarse herramientas para análisis de tráfico como:
•
UNIX and Linux, tcpdump
•
Sun Microsystems, Snoop
•
Microsoft, Network Monitor (1.2 y 2.0)
•
HP/Agilent Technologies, Internet Advisor LAN™
•
IBM, DatagLANce™
E3A2 – Armado de ambiente IPv6
Esta actividad consiste en armar el ambiente para las pruebas en IPv6.
Se busca que en el ambiente viajen solamente paquetes IPv6. Para esto hay varias
alternativas:
1. Utilizar componentes donde se pueda deshabilitar IPv4 o directamente trabajen con
IPv6. En algunos sistemas operativos es posible deshabilitar completamente IPv4 y sólo
utilizar una comunicación IPv6.
2. En los casos que el IPv4 no se puede deshabilitar se buscará filtrar los paquetes IPv4 en
todos los puntos de comunicación donde sea posible. En donde no sea posible se
instalarán monitores para registrar los paquetes de comunicación, de manera de poder
corroborar que la aplicación no está haciendo uso de IPv4. Para evitar el pasaje de
paquetes IPv4 se puede utilizar, por ejemplo, “iptables” o “Netfilter” en Linux y
“Netfilter for windows”. Por ejemplo, para bloquear el tráfico IPv4 mediante iptables se
utilizan los comandos:
iptables -P INPUT DROP
Página 13
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
E3A3 – Documentación de la configuración de ambientes
Es muy importante la documentación de la configuración, por esa razón se destaca como una
actividad en sí misma. La información registrada irá constituyendo la base de conocimiento
que servirá para planificar mejor los nuevos proyectos de prueba (calibrando la priorización),
diseñar mejores casos de prueba, identificar y solucionar problemas antes incluso del armado
del ambiente. Cada nueva configuración del sistema constituye una nueva versión de la
aplicación a probar por lo tanto el registro de esa información es esencial.
E4 – Ejecución de las pruebas
E4A1 – Ejecución en sistema bajo prueba IPv4
Si el sistema bajo prueba tuviera una versión IPv4, se aplicará testing exploratorio para
conocer su funcionamiento y a la vez, detectar incidentes rápidamente, para evitar que sean
atribuibles al cambio de protocolo de red. A su vez, en las funcionalidades donde se observen
tiempos superiores a los dos segundos, registrar los tiempos para su comparación posterior.
E4A2 – Ejecución en sistema bajo prueba IPv6
Se ejecuta el plan de pruebas según la estrategia delineada. Durante la ejecución de las
sesiones de testing exploratorio y los casos de prueba diseñados y planificados se
monitorizarán todas las interfaces que no sean puramente IPv6. Los resultados de las pruebas
se detallarán exhaustivamente, sobre todo en el caso que la empresa responsable de las
pruebas no sean los Certificadores. De esta manera, la última tendrá elementos para evaluar
las pruebas. A su vez, en las funcionalidades donde se observen tiempos superiores a los dos
segundos, registrar los tiempos para su comparación posterior.
E4A3 – Pruebas de regresión
Este paso se lleva a cabo eventualmente si se encuentran problemas que deben solucionarse,
ya sea por configuración del sistema bajo prueba o la infraestructura, así como también
cambios en el código fuente, instalación de actualizaciones o parches. En ese caso, se ejecutan
pruebas de regresión sobre las funcionalidades donde se encontraron problemas y donde
pueden impactar los cambios.
E5 – Evaluación de las pruebas
E5A1 – Revisión de las pruebas
Las pruebas finales, luego de los ciclos de prueba y corrección necesarios, deben arrojar
resultados positivos. Además, los tiempos de respuesta que fueron registrados en las pruebas
con IPv4 y con IPv6 deben haber mejorado o al menos no degradado.
Por su parte, los Testers/Consultores deberán organizar la información y prepararla para su
entrega a los Certificadores.
Página 14
Los Certificadores analizarán la información recibida y podrán pedir más en la medida que se
requiera.
Los documentos a entregar se encuentran detallados en la sección Documentación requerida.
E5A2 – Determinación del nivel de certificación
A partir del nivel que se ha decidido alcanzar y al que realmente se ha llegado con las pruebas
los Certificadores determinan el tipo de certificación que se otorga.
A modo de resumen, si la aplicación permite al usuario final utilizar la aplicación con IPv6 de la
misma forma en la que lo hace con IPv4 se obtiene la certificación IPv6UserApp.
Si además, permite al usuario administrador y al resto de los sistemas con los que interactúa
(todas las interfaces) trabajar en forma similar con IPv6 que con IPv4 se obtiene la
certificación IPv6FullApp.
Cuando se prueba la aplicación en el ambiente que será o es de producción y el sistema
permite al usuario final utilizar la aplicación con IPv6 de la misma forma en la que lo hace con
IPv4 se obtiene la certificación IPv6UserService.
Si se prueba la aplicación en el ambiente que será o es de producción y además permite al
usuario administrador y al resto de los sistemas con los que interactúa (todas las interfaces)
trabajar en forma similar con IPv6 que con IPv4 se obtiene la certificación IPv6FullService.
Cuando se prueba la aplicación en el ambiente que será o es de producción y el sistema
trabaja completamente bajo IPv6, o sea, en forma interna (entre sus componentes) y externa
(todas sus interfaces: usuario final, administrador y otros sistemas informáticos) se obtiene la
certificación IPv6System.
E5A3 – Mejora de la base de conocimiento
Lo aprendido en el proyecto, en todas sus etapas y actividades, se incorpora a la base de
conocimiento de la organización Tester. La base de conocimiento le permitirá llevar a cabo
estos proyectos en forma más eficiente. Cada vez conocerá más sobre los posibles problemas
relativos a la adecuación al protocolo IPv6 que tienen las tecnologías involucradas como las
funcionalidades habituales de los sistemas informáticos.
Es deseable que la organización Certificadora también tenga y actualice su base de
conocimiento con cada proyecto en el que participa.
Página 15
4.
Roles
A continuación se detallan los roles involucrados en la metodología de pruebas para uso de
sistemas en IPv6. Estos roles pueden ser desempeñados por una misma persona, por ejemplo
el líder puede ser un experto en IPv6.
No se incluyen en esta descripción los roles técnicos y gerenciales de la Organización
interesada en la certificación, con los cuales se interactúa durante el proceso.
Líder de testing
El líder de testing participará en la planificación de las pruebas, definiendo objetivo y alcance
junto con la contraparte de la Organización interesada en la certificación.
Elaborará el inventario de funcionalidades demarcando claramente las fronteras del sistema
bajo prueba, enumerando las funcionalidades que se probarán, priorizándolas, así como las
que no serán probadas.
El líder será el responsable de definir la estrategia de pruebas para las funcionalidades
inventariadas.
Además, planificará la configuración de los ambientes de prueba junto con los responsables de
infraestructura de la Organización interesada en la certificación y el experto en IPv6.
Participará activamente en el seguimiento y control del proyecto, el seguimiento de la
metodología de pruebas y la evaluación de pruebas.
Tester
El tester participará en la elaboración del inventario de pruebas junto al líder de testing.
Como tarea principal diseñará los casos de prueba, las misiones de testing exploratorio y
ejecutará las pruebas.
Además es muy importante que registre detalladamente las sesiones de prueba así como los
resultados obtenidos en los casos de prueba diseñados y planificados.
Experto en IPv6
El experto en IPv6 participará en la priorización del inventario junto con el líder de testing.
También colaborará en la configuración de los ambientes de prueba, diseño y validación de
casos, misiones de prueba, así como en la etapa de evaluación de pruebas.
Evaluador
El evaluador de la organización deberá poseer amplios conocimientos y una vasta experiencia
en testing. A su vez, deberá especializarse en este tipo de pruebas y podrá asesorarse con un
experto en IPv6.
Página 16
5.
Comprobación
Para la certificación IPv6 se definen 5 niveles: IPv6UserApp, IPv6FullApp, IPv6UserService,
IPv6FullService y IPv6System.
Figura 4 - Niveles de certificación
A continuación se explica cada uno de los niveles.
IPv6UserApp
Se otorga la certificación IPv6UserApp si la aplicación permite, al usuario final, utilizar la
aplicación con IPv6 de la misma forma en la que lo hace con IPv4.
Se pretende verificar que la experiencia de usuario final del sistema bajo prueba (humano o
sistema informático) por IPv6 es funcionalmente equivalente de la de IPv4, por ejemplo en
interfaces:
•
Aplicaciones Web, front-end.
•
Servicios (WS, RMI, EJB, CORBA, etc.)
Página 17
•
Aplicaciones con interfaz nativa del sistema operativo
Se verificarán todas las funcionalidades de las interfaces definidas en el alcance, pero no,
todas las posibles combinaciones.
IPv6FullApp
Se otorga la certificación IPv6FullApp si la aplicación permite al usuario final, administrador y
al resto de los sistemas con los que interactúa (todas las interfaces) trabajar en forma similar
con IPv6 que con IPv4.
Los sistemas, subsistemas, módulos, interfaces y funcionalidades inventariadas y verificadas
incluirán la visión del usuario final, usuario administrador y personal de soporte. Para estos
usuarios el sistema bajo prueba es funcionalmente equivalente sobre IPv6 que sobre IPv4. A
modo de ejemplo, esto incluye:
•
Todas las funcionalidades para cualquier usuario del sistema desde cualquier origen
•
En aplicaciones Web, por ejemplo, front-end y back-end.
Esto incluirá no sólo funcionalidades de interfaz gráfica, por ejemplo, los registros de actividad
en el sistema (logs) que presenten direcciones IP deberán ser compatibles con IPv6.
IPv6UserService
Se otorga la certificación IPv6UserService cuando se prueba la aplicación en el ambiente
que será o es de producción y la aplicación permite al usuario final utilizar la aplicación
con IPv6 de la misma forma en la que lo hace con IPv4.
La infraestructura será la misma en la que trabajará o trabaja el sistema en producción.
A modo de ejemplo, la aplicación ejecutará en un ambiente que puede involucrar componentes
de infraestructura como:
•
Alta disponibilidad/failovers.
•
Unidades iSCSI.
•
Bases de datos.
•
Balanceadores de carga/failover.
•
Métodos y dispositivos de respaldo.
•
Aceleradores.
•
Firewalls.
•
Virtualización.
Por ejemplo, para la resolución de nombres se utilizará DNS con direcciones IPv6 y registros
AAAA.
No es necesario que los componentes de infraestructura estén certificados con IPv6 Ready.
Página 18
IPv6FullService
Se otorga la certificación IPv6FullService cuando se prueba la aplicación en el ambiente
que será o es de producción y la aplicación permite al usuario final, administrador y al resto
de los sistemas con los que interactúa (todas las interfaces) trabajar en forma similar con IPv6
que con IPv4.
Al igual que en IPv6UserService, no es necesario que los componentes de infraestructura estén
certificados con IPv6 Ready.
IPv6System
Se otorga la certificación IPv6System cuando se prueba la aplicación en el ambiente que
será o es de producción y la aplicación permite al usuario final, administrador y al resto de
los sistemas con los que interactúa (todas las interfaces) trabajar en forma similar con IPv6
que con IPv4. Además, internamente el sistema funciona completamente bajo IPv6.
Esto no quiere decir que se certifica cada uno de los componentes por separado, ni tampoco el
ambiente por sí solo en el cual se ejecuta el sistema. Quiere decir que la aplicación ejecuta en
un ambiente, con comunicaciones IPv6 internas y externas, de forma similar que con IPv4.
La infraestructura será la misma en la que trabajará o trabaja el sistema en producción.
Como en las anteriores certificaciones, no es necesario que los componentes de infraestructura
estén certificados con IPv6 Ready.
Resumen comparativo
A continuación se presenta una tabla comparativa entre las certificaciones:
IPv6UserApp
IPv6FullApp
IPv6UserService
IPv6 para
usuario final
IPv6 para
todas las
interfaces
Prueba en el
ambiente de
producción o
similar
IPv6 entre
componentes
internos
Página 19
IPv6FullService
IPv6System
6.
Documentación requerida para la validación
La validación es incremental y a partir de la entrega de documentos. Los documentos
que se detallan a continuación son los básicos tanto que la organización Certificadora puede
pedir más información o la organización Tester aportar información adicional.
Planificación de las pruebas
Documento de arquitectura del sistema
En este documento se presentará los componentes del sistema, delimitando claramente las
fronteras y las interfaces con el exterior. Además se presentará el ambiente en el cual ejecuta
el sistema. La información tiene que presentarse como diagramas y en forma detallada
describiendo las especificaciones de los componentes.
Este documento tiene que contener diagramas como por ejemplo:
3%(*)&1(%0
456
/0/+()1
!-+2
:)(%;+22
,-.%(-%.
6+0%07&%
!+.10
3%(*)&1(%0
&%7+82)9+9)1-%0
$1/.%(
$%&
'()*+&+
!"#
!"#$%'
!"#$%&
Figura 5 - Ejemplo diagrama de red
Puede contener información de las aplicaciones y tecnologías involucradas. Por ejemplo:
Aplicación1 Aspectos
Observaciones Función Informatización de las intervenciones quirúrgicas. Desarrollo Desarrollado y mantenido por EMPRESA, a partir de un proyecto
de código abierto (sourceforge).
Fuentes Se cuenta con acceso al código fuente de las aplicaciones.
Hosteado Se encuentra alojado en EMPRESA-HOSTING.
Ambiente Se cuenta con acceso a un ambiente de desarrollo y testing.
Notas La identificación de los terminales se realiza mediante la
numeración IP de éstos, sobre una IP-VPN MPLS.
Figura 6 - Información sobre las aplicaciones
Página 20
Estas tablas se vinculan con estas dos tablas:
Componente
Descripción Apache 2.2 Servidor WEB.
Tomcat 6 Servidor de aplicaciones.
mod_jk (apache) Módulo de Apache para implementar esquemas de balanceo de carga
y alta disponibilidad entre servidores.
MySQL 5.x Motor de Base de Datos.
Linux HA (Ker 2.6.19) Sistema Operativo (soporte de alta disponibilidad y balance de carga).
VMWare Sistema para virtualización de sistemas operativos.
JRE 1.6.0 Máquina virtual Java.
JBoss 4 Framework para desarrollo de aplicaciones en entorno Java.
Open LDAP 2 Servidor de Información de Directorios sobre IP.
Figura 7 - Información sobre tecnologías
Aplicación1 Aplicación2 Apache 2.2 X
X
Tomcat 6 X
mod_jk (apache) X
X
MySQL 5.x X
X
Linux HA (Ker 2.6.19) X
X
VMWare X
JRE 1.6.0 X
X
Jboss 4 X
Open LDAP 2 X
Figura 8 - Uso de tecnología por aplicaciones
El documento no tiene que limitarse a esta información sino que debe brinda un panorama
claro del sistema a probar y el entorno en el cual ejecuta.
Inventario de pruebas
En este documento deben explicar los subsistemas, módulos e interfaces a probar junto con
las funcionalidades asociadas a cada uno. Debe estar priorizado según la criticidad con
Página 21
respecto al cambio IPv4 a IPv6 y debe tener un detalle que explique en qué consiste cada
funcionalidad.
Por ejemplo, el inventario puede contener esta información:
Usuario Módulo Usuario final Gestión de objetos Id Nombre Prioridad IPV6 1 2 Nuevo Objeto Actualizar Objeto ALTA MEDIA 3 Consultar objeto Configurar Objetos Configurar Sistema Respaldar Restaurar ALTA Observaciones Alguna observación Alguna observación MEDIA MEDIA BAJA BAJA 4 Configuración Gestión de repositorio Administrador 5 6 7 Figura 9 - Inventario de funcionalidades
Diseño de pruebas
Inventario de pruebas con la estrategia de pruebas
El inventario, una vez validado, deberá incorporar la estrategia de pruebas para cada una de
las funcionalidades.
Al inventario se agrega una columna en la cual se plantea la estrategia para cada funcionalidad
a probar.
Usuario Usuario final Módulo Gestión de objetos Id Nombre Prioridad IPV6 1 2 Nuevo Objeto Actualizar Objeto ALTA MEDIA 3 Consultar objeto Configurar Objetos Configurar Sistema Respaldar Restaurar 4 Configuración Administrador Gestión de repositorio 5 6 7 Estrategia ALTA Observaciones Alguna observación Alguna observación MEDIA PLAN MEDIA BAJA BAJA EXPL EXPL EXPL Figura 10 - Inventario con estrategia de pruebas
Página 22
PLAN EXPL PLAN Centro de Ensayos de Software
Documento con casos de prueba diseñados
En este documento se detallan todos los casos de prueba diseñados para la ejecución del
testing planificado.
Por ejemplo se puede utilizar un formato de tabla para diseñar los casos de prueba:
Funcionalidad 1 Id f1_cp1 f1_cp2 Fecha creación 07/08/12 07/08/12 Precondición Resumen Mauricio Debe estar creado el objeto Se actualizan los valores variable1 dato1 variable2 dato1 Gustavo Debe estar creado el objeto Se elimina el objeto variable1 dato2 variable2 dato2 Diseñador Variables Variable1 Variable2 Variable3 Resultado esperado Variable4 General variable3 dato1 variable4 dato1 Se almacenaron los campos en la BD variable3 dato2 variable4 dato2 Se elimina el elemento de la BD Mensaje El objeto se actualizó con éxito El objeto se eliminó con éxito Figura 11 - Plantilla para casos de prueba
El documento de casos de prueba diseñados contendrá varias de este tipo de tablas, pudiendo
contener otros elementos como tablas de decisión, máquinas de estado, etc. dependiendo de
la técnica usada para el diseño.
Documento con misiones de testing exploratorio
En este documento se detallan todas las misiones que se tendrán en mente cuando se
ejecuten las sesiones de testing exploratorio.
Misiones Id Fecha creación Diseñador Detalle m1 07/08/12 Mauricio Verificar el ciclo de vida del objetoX m2 07/08/12 Gustavo Verificar la configuración Área1 Áreas Área2 Área3 Área4 f1 f2 f3 f5 f6 Figura 12 - Misiones de testing exploratorio
Las misiones de testing exploratorio deben cubrir todas las áreas (funcionalidades) que se
decidieron probar con testing exploratorio en el inventario de pruebas.
Página 23
Configuración de las pruebas
Documento de armado de ambientes
Este documento presentará la configuración necesaria, actualización de componentes y
cualquier cambio necesario para configurar el ambiente para el funcionamiento del sistema en
IPv6. Se pueden utilizar diagramas de la misma forma que en el Documento de arquitectura de
sistema.
Ejecución de pruebas
Registro de ejecución de casos de prueba y sesiones de testing exploratorio
En este documento se presenta el registro de la ejecución de los casos de prueba, con los
datos utilizados, el orden en el que se ejecutaron los casos y los resultados obtenidos con
evidencias como por ejemplo, capturas de pantalla o mensajes de respuesta (archivo XML).
A continuación se presenta un ejemplo de reporte de ejecución de casos de prueba:
Funcionalidad 1 Id Resultado obtenido Ambiente Versión Incidentes 3.1b3 3.1b3 f1_cp1 Error f1_cp2 OK windows, mozila firefox windows, mozila firefox Ejecución Fecha Tester 223-‐266 20/08/2012 María 20/08/2012 María Figura 13 - Reporte de ejecución de casos de prueba
Las sesiones de testing exploratorio tienen que registrarse en documentos separados, donde
se presentan datos como la misión, las áreas probadas, la fecha y hora de inicio y cierre de
sesión, las notas de lo que sucede en la interacción con la aplicación (texto e imágenes) e
incidentes encontrados.
Capturas de tráfico
En los casos que existan interfaces que no son IPv6 puras, se deberá entregar capturas de
tráfico para poder analizar los paquetes que viajan entre el emisor y el receptor.
Se espera un archivo de captura que pueda ser manejable y estudiado por alguna herramienta
libre.
Incidentes detectados y corregidos
En este documento se presentarán los problemas encontrados y las soluciones a los mismos.
Esto pueden ser instalaciones de parches, cambios en el código fuente, cambios en la
configuración, etc.
Página 24
En el proceso de prueba y corrección de problemas por la empresa el tester puede utilizar
herramientas de gestión de incidentes como por ejemplo Mantis (http://www.mantisbt.org/).
Los reportes de este tipo de herramientas suministran los datos necesarios para presentar los
incidentes detectados y corregidos.
Página 25
7.
Glosario
A continuación se presenta un glosario con una definición de algunos términos, buscando
manejar los conceptos de una forma común.
Actores
Instituciones vinculadas e interesadas en el proyecto de certificación
de alguna forma.
Ambiente
Entorno donde ejecuta el sistema bajo prueba.
Broadcast
Envío de información a todos los receptores disponibles, no a un
receptor particular.
Capturas de tráfico
Archivos con secuencias de paquetes de información que viajaron por
la red.
Cluster
Conjunto de equipos en los cuales se puede distribuir el cómputo de
una aplicación.
DNS
Aplicación que asocia a las direcciones IP un nombre para ser
manejado por los equipos y los usuarios.
Firewall
Aplicación que filtra el pasaje de información en la red según
determinadas reglas configurables.
Frontera
Interfaces que delimitan definiendo los componentes que están en el
sistema y los que son parte de otros sistemas o del ambiente de
ejecución.
Funcionalidad
Operación que brinda el sistema y es de valor para algún usuario.
Host
Equipo, virtual o físico, que se identifica en la red a través de una
dirección IP.
Interface
Conjunto de operaciones que brinda el sistema en un formato
particular.
Inventario
pruebas
IPv4
de
Conjunto de funcionalidades y aspectos a probar de un sistema.
Ver http://tools.ietf.org/html/rfc791
IPv6
Ver http://tools.ietf.org/html/rfc2460
Misión específica de
testing exploratorio
Objetivo que puede utilizarse en una sesión de testing, involucra
funcionalidades o aspectos puntuales. Por ejemplo, “Verificar los
estados de un expediente”.
Misión general de
testing exploratorio
Objetivo que puede utilizarse en una sesión de testing, involucra
funcionalidades o aspectos generales a la aplicación. Por ejemplo,
“Estudiar la usabilidad del sistema”.
Oráculo
Entidad que determina los resultados esperados del sistema.
Parser
Analizador que extrae información de valor dentro de un conjunto
mayor.
Sesiones de testing
exploratorio
Lapso de tiempo entre 45 y 120 minutos en el cual el tester se enfoca
en una misión particular.
Sistema
Se trata de la aplicación delimitada por sus componentes esenciales.
Por ejemplo, los componentes de software en los servidores de
aplicaciones, en los PC clientes, la base de datos. Los componentes de
red quedan afuera del concepto de sistema.
Página 26
Testing planificado
Estrategia de testing en la cual la instancia de diseño de casos de
prueba precede a la instancia de ejecución.
Testing exploratorio
Estrategia de testing en la cual el aprendizaje sobre el sistema, el
diseño de casos de prueba y la ejecución de estos se realizan en forma
simultánea.
WSDL
Formato XML en el cual se describen servicios Web.
XML
Lenguaje de texto con marcas fácilmente legible tanto por personas
como computadoras.
Página 27

Metodología de testing de software para mitigar riesgos en la

Transcripción

Documentos relacionados

Sistemas Distribuidos

Alternativas de videoconferencia sobre IPv6 - IPv6 México

La nueva generación del Protocolo de Internet

Introducción a IPv6