Metodología de testing de software para mitigar riesgos en la
Transcripción
Metodología de testing de software para mitigar riesgos en la
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 Centro de Ensayos de Software § 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software • 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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 Centro de Ensayos de Software 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