Está en la página 1de 27

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
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 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
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 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
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 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
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 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
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 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
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.
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
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:

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