Metodologia de Certificacion en Ipv6 Preliminar PDF

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
Laura
Índice Elimin
ÍNDICE ....................................................................................................................................................................... 2 Laura

Elimin
1. INTRODUCCIÓN ................................................................................................................................................. 4
Laura
OBJETIVO .......................................................................................................................................................................... 4 Elimin
ACTORES ........................................................................................................................................................................... 4 Laura
ORGANIZACIÓN DEL DOCUMENTO ........................................................................................................................................... 5 Elimin
2. ETAPAS .............................................................................................................................................................. 6 Laura
Elimin
PLANIFICACIÓN DE LAS PRUEBAS ............................................................................................................................................. 6
Laura
DISEÑO DE PRUEBAS ............................................................................................................................................................ 6
Elimin
CONFIGURACIÓN DE LAS APLICACIONES Y DEL AMBIENTE ............................................................................................................. 7
EJECUCIÓN DE PRUEBAS ........................................................................................................................................................ 7 Laura
EVALUACIÓN DE LAS PRUEBAS ................................................................................................................................................ 7 Elimin
Laura
3. ACTIVIDADES ..................................................................................................................................................... 8
Elimin
E1 -‐ PLANIFICACIÓN DE LAS PRUEBAS ...................................................................................................................................... 8 Laura
E1A1 – Estudio de la arquitectura del sistema ........................................................................................................... 8 Elimin
E1A2 – Determinación del alcance de las pruebas ..................................................................................................... 9 Laura
E1A3 – Priorización de funcionalidades ...................................................................................................................... 9 Elimin
E2 -‐ DISEÑO DE LAS PRUEBAS .............................................................................................................................................. 10
Laura
E2A1 – Definición de la estrategia de testing ........................................................................................................... 10
Elimin
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 Laura
E3 – CONFIGURACIÓN DE LAS PRUEBAS ................................................................................................................................. 13 Elimin
E3A1 – Armado de ambiente IPv4 ............................................................................................................................ 13 Laura

E3A2 – Armado de ambiente IPv6 ............................................................................................................................ 13 Elimin
E3A3 – Documentación de la configuración de ambientes ...................................................................................... 14 Laura
E4 – EJECUCIÓN DE LAS PRUEBAS ......................................................................................................................................... 14 Elimin
E4A1 – Ejecución en sistema bajo prueba IPv4 ........................................................................................................ 14 Laura
E4A2 – Ejecución en sistema bajo prueba IPv6 ........................................................................................................ 14 Elimin
E4A3 – Pruebas de regresión .................................................................................................................................... 14 Laura
E5 – EVALUACIÓN DE LAS PRUEBAS ....................................................................................................................................... 14
Elimin
E5A1 – Revisión de las pruebas ................................................................................................................................ 14
Laura
E5A2 – Determinación del nivel de certificación ...................................................................................................... 15
Elimin
E5A3 – Mejora de la base de conocimiento ............................................................................................................. 15
Laura
4. ROLES .............................................................................................................................................................. 16 Elimin
LÍDER DE TESTING .............................................................................................................................................................. 16 Laura
TESTER ............................................................................................................................................................................ 16 Elimin
EXPERTO EN IPV6 ............................................................................................................................................................. 16 Laura
EVALUADOR ..................................................................................................................................................................... 16 Elimin
5. CERTIFICACIÓN ................................................................................................................................................ 17 Laura

Elimin
IPV6USERAPP .................................................................................................................................................................. 17
Laura
IPV6FULLAPP ................................................................................................................................................................... 18
Elimin
IPV6USERSERVICE ............................................................................................................................................................ 18
IPV6FULLSERVICE ............................................................................................................................................................. 19 Laura
IPV6SYSTEM .................................................................................................................................................................... 19 Elimin
RESUMEN COMPARATIVO .................................................................................................................................................... 19 Laura
Elimin
6. DOCUMENTACIÓN REQUERIDA PARA LA VALIDACIÓN ..................................................................................... 20
Laura
PLANIFICACIÓN DE LAS PRUEBAS ........................................................................................................................................... 20 Elimin
Documento de arquitectura del sistema .................................................................................................................. 20 Laura
Inventario de pruebas .............................................................................................................................................. 21 Elimin
Laura
Elimin
Laura
Elimin
Laura
DISEÑO DE PRUEBAS .......................................................................................................................................................... 22
Inventario de pruebas con la estrategia de pruebas ................................................................................................ 22 Laura
Documento con casos de prueba diseñados ............................................................................................................. 23 Elimin
Documento con misiones de testing exploratorio .................................................................................................... 23 Laura
CONFIGURACIÓN DE LAS PRUEBAS ......................................................................................................................................... 24 Elimin
Documento de armado de ambientes ...................................................................................................................... 24 Laura
EJECUCIÓN DE PRUEBAS ...................................................................................................................................................... 24 Elimin
Registro de ejecución de casos de prueba y sesiones de testing exploratorio .......................................................... 24
Laura
Capturas de tráfico ................................................................................................................................................... 24
Elimin
Incidentes detectados y corregidos .......................................................................................................................... 24
Laura
7. GLOSARIO ........................................................................................................................................................ 26 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 con las interfaces y
funcionalidades a probar priorizadas según el riesgo IPv6.
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 6+0%07&%
456 3%(*)&1(%0 !+.10
/0/+()1 &%7+82)9+9)1-%0
!-+2
:)(%;+22 $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 2001:0db8:85a3:08d3:1319:8a2e:0370:7334
• Ingresar una dirección comprimida.
o 2001:0db8:85a3::1319:8a2e:0370:7344
• Ingresar una dirección que se puede comprimir.
o 2001:0db8:85a3:0000:1319:8a2e:0370:7344
• Varios tipos de compresión de la misma dirección IPv6.
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.
o 2001:0db8::25de::cade
• Dirección con ceros omitidos.
o 2001:db8:2de::e13
• Dirección con IPv4 empotrada.
o ::ffff:192.168.89.9
• Misma dirección que la anterior.
o ::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 [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 IPv6FullService IPv6System
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
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 6+0%07&%
456 3%(*)&1(%0 !+.10
/0/+()1 &%7+82)9+9)1-%0
!-+2
:)(%;+22 $1/.%(
,-.%(-%. $%&
!"# '()*+&+
!"#$%& !"#$%'
Figura 5 - Ejemplo diagrama de red
Puede contener información de las aplicaciones y tecnologías involucradas. Por ejemplo:
Aspectos Observaciones
Función Informatización de las intervenciones quirúrgicas.
Desarrollado y mantenido por EMPRESA, a partir de un proyecto
Aplicación1
Desarrollo
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.
La identificación de los terminales se realiza mediante la
Notas
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.
Módulo de Apache para implementar esquemas de balanceo de carga
mod_jk (apache)
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:
Prioridad
Usuario Módulo Id Nombre IPV6 Observaciones
Alguna
1 Nuevo Objeto ALTA observación
2 Actualizar Objeto MEDIA
Alguna
Usuario final Gestión de objetos 3 Consultar objeto ALTA observación
Configurar
4 Objetos MEDIA
Configurar
Configuración 5 Sistema MEDIA
Gestión de 6 Respaldar BAJA
Administrador repositorio 7 Restaurar BAJA
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.
Prioridad
Usuario Módulo Id Nombre IPV6 Observaciones Estrategia
Alguna
1 Nuevo Objeto ALTA observación PLAN
2 Actualizar Objeto MEDIA EXPL
Alguna
Usuario final Gestión de objetos 3 Consultar objeto ALTA observación PLAN
Configurar
4 Objetos MEDIA PLAN
Configurar
Configuración 5 Sistema MEDIA EXPL
Gestión de 6 Respaldar BAJA EXPL
Administrador repositorio 7 Restaurar BAJA EXPL
Figura 10 - Inventario con estrategia de pruebas
Página 22
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

Variables Resultado esperado

Fecha
Id Diseñador Precondición Resumen Variable1 Variable2 Variable3 Variable4 General Mensaje
creación
El objeto
Se Se se
Debe estar actualizan almacenaron actualizó
creado el los variable1 variable2 variable3 variable4 los campos con
f1_cp1 07/08/12 Mauricio objeto valores dato1 dato1 dato1 dato1 en la BD éxito
El objeto
se
Debe estar Se Se elimina el eliminó
creado el elimina el variable1 variable2 variable3 variable4 elemento de con
f1_cp2 07/08/12 Gustavo objeto objeto dato2 dato2 dato2 dato2 la BD é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

Áreas
Fecha
Id Diseñador Detalle Área1 Área2 Área3 Área4
creación
Verificar el ciclo

de vida del
m1 07/08/12 Mauricio objetoX f1 f2 f3
Verificar la
m2 07/08/12 Gustavo configuración 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

Ejecución
Resultado
Id Ambiente Versión Incidentes Fecha Tester
obtenido
windows,
mozila
f1_cp1 Error firefox 3.1b3 223-‐266 20/08/2012 María
windows,
mozila
f1_cp2 OK firefox 3.1b3 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 de Conjunto de funcionalidades y aspectos a probar de un sistema.
pruebas
IPv4 Ver http://tools.ietf.org/html/rfc791
IPv6 Ver http://tools.ietf.org/html/rfc2460
Misión específica de Objetivo que puede utilizarse en una sesión de testing, involucra
testing exploratorio funcionalidades o aspectos puntuales. Por ejemplo, “Verificar los
estados de un expediente”.
Misión general de Objetivo que puede utilizarse en una sesión de testing, involucra
testing exploratorio 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 Lapso de tiempo entre 45 y 120 minutos en el cual el tester se enfoca
exploratorio 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

Metodologia de Certificacion en Ipv6 Preliminar PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Metodologia de Certificacion en Ipv6 Preliminar PDF

Caricato da

Copyright:

Formati disponibili

Metodología de testing de software para mitigar

riesgos en la adopción de IPv6

ÍNDICE ....................................................................................................................................................................... 2 Laura

E3A1 – Armado de ambiente IPv4 ............................................................................................................................ 13 Laura

5. CERTIFICACIÓN ................................................................................................................................................ 17 Laura

§ 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

§ 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

Organización del documento

La primera etapa es la Planificación de pruebas, siguen el Diseño de pruebas y la Configuración

Planificación de las pruebas

al tester herramientas para diseñar casos adaptados al contexto. Es importante identificar

Configuración de las aplicaciones y del ambiente

Evaluación de las pruebas

Figura 2 - Etapas con sus Actividades

E1 - Planificación de las pruebas

E1A1 – Estudio de la arquitectura del sistema

Figura 3 - Fronteras del sistema

E1A2 – Determinación del alcance de las pruebas

E1A3 – Priorización de funcionalidades

Comunicaciones - Cualquier funcionalidad que desencadene una comunicación a través de la

Configuraciones - Las funcionalidades que consuman datos de configuración con direcciones

La prioridad BAJA se asocia a las funcionalidades que no presentan las características

E2 - Diseño de las pruebas

E2A1 – Definición de la estrategia de testing

E2A2 – Diseño de casos de prueba y misiones de testing exploratorio

Pruebas sobre los datos

Pruebas de arquitectura y ambiente

E2A3 – Validación de casos de prueba y misiones de testing exploratorio

E3 – Configuración de las pruebas

E3A1 – Armado de ambiente IPv4

E3A2 – Armado de ambiente IPv6

iptables -P FORWARD DROP

E3A3 – Documentación de la configuración de ambientes

E4 – Ejecución de las pruebas

E4A1 – Ejecución en sistema bajo prueba IPv4

E4A2 – Ejecución en sistema bajo prueba IPv6

E4A3 – Pruebas de regresión

E5 – Evaluación de las pruebas

E5A1 – Revisión de las pruebas

E5A2 – Determinación del nivel de certificación

E5A3 – Mejora de la base de conocimiento

Figura 4 - Niveles de certificación

A continuación se explica cada uno de los niveles.

• Aplicaciones con interfaz nativa del sistema operativo

IPv6UserApp IPv6FullApp IPv6UserService IPv6FullService IPv6System

6. Documentación requerida para la validación

Planificación de las pruebas

Documento de arquitectura del sistema

Figura 5 - Ejemplo diagrama de red

Puede contener información de las aplicaciones y tecnologías involucradas. Por ejemplo:

Figura 6 - Información sobre las aplicaciones

Estas tablas se vinculan con estas dos tablas:

Figura 7 - Información sobre tecnologías

Figura 8 - Uso de tecnología por aplicaciones