an excellent way data testing using xml technologies
En el SDLC , si la aplicación usa un modelo en cascada, las actividades de prueba se planean al final. Esto plantea un riesgo de reelaboración con respecto a los requisitos, el diseño, el código y los casos de prueba si el equipo de control de calidad identifica defectos. Es mejor evitar esperar hasta el final para identificar los defectos en una aplicación.
Las pruebas que no se basan en la ejecución funcional de la aplicación pueden encontrar defectos sin exigir la liberación de todos los componentes en el entorno de prueba. Esto se puede lograr mediante pruebas de datos.
El XML y las tecnologías relacionadas que se utilizan para la comunicación entre los diferentes niveles de una aplicación brindan la oportunidad de realizar las pruebas que no necesitan esperar a que toda la aplicación esté disponible para la prueba.
Este documento describe una forma posible de considerar la opción de prueba de datos al principio del ciclo de vida de un lanzamiento de producto.
Lo que vas a aprender:
- Suposición:
- Grupo de enfoque:
- Propósito:
- Prueba del ciclo de vida de la gestión de datos
- Conclusión
- Lectura recomendada
Suposición:
Este documento asume que el lector está familiarizado con conceptos de prueba de software y uso fundamental de una base de datos y tecnologías XML.
Grupo de enfoque:
Equipo de control de calidad (QA), equipo de datos (DT), desarrollador (DEV)
Propósito:
los Data de muestra identificado para probar un producto define el alcance de las pruebas realizadas, agrega confianza en los resultados de la prueba y la calidad del producto. La identificación de los datos para una prueba depende de los requisitos de la prueba a realizar.
Este documento se centra en validar los datos de prueba antes de verlos en la interfaz de usuario.
Este proceso necesita la gestión de datos de prueba para tener resultados de prueba efectivos. Los datos, como todos sabemos, se pueden guardar en una base de datos o en un archivo plano. Pero la transferencia de datos desde / hacia una base de datos se puede manejar usando XML. Existe una relación muy estrecha entre XML (1), XSD (2), XPATH (3) & XSLT (4). (Consulte todas las definiciones a continuación).
(1) XML - es X tensible METRO Arkup L anguage. Es una recomendación del World Wide Web Consortium (W3C) para describir datos. Si se aplica un conjunto de reglas de sintaxis correctas, se puede garantizar que un documento XML esté 'bien formado'.
(2) XSD - Usado para denotar la estructura de un documento XML. Un documento XML 'bien formado' se puede validar con un XSD (esquema XML) para validarlo.
(3) XPATH - Se debe navegar por un XML 'válido' y 'bien formado' para obtener los datos adecuados del XML. Las expresiones XPATH se ven como una ruta de archivo tradicional en un directorio.
(4) XSLT - es X tensible S tyleheet L idioma T transformaciones: mientras se representan los datos de un XML en una interfaz de usuario (UI), se puede aplicar cualquier estilo (fuente, color, tamaño, etc.) utilizando XSLT. XSLT usa XPath para localizar información del XML.
Los datos presentados en el XML se valida con un esquema (archivo XSD). El XML se puede generar en diferentes formatos con XSLT y XPATH.
c ++ cómo usar stringstream
Para el propósito de esta discusión usaremos el siguiente ejemplo.
Ejemplo - Una editorial tiene un sitio web que muestra información sobre los libros que ha publicado. Una de las páginas web muestra un resumen de cada capítulo de un libro. Las pruebas deben garantizar que el contenido sea apropiado en esta página web. La editorial ya ha publicado millones de libros.
Toda la información relacionada con los libros publicados se guarda en una base de datos. Sin embargo, la página web en cuestión necesita que se extraiga un subconjunto de los datos (sobre un libro nuevo y sus capítulos) de la base de datos a un XML.
El XML que se proporciona a continuación representa los metadatos del libro.
Archivo XML Book.xml
|_+_|Libro de esquemas XML.xsd
Prueba del ciclo de vida de la gestión de datos
Similar a otro proceso, gestión de datos de prueba tiene sus propias etapas de ciclo de vida (LC).
- Identificar los requisitos de datos
- Planificar la recopilación de datos
- Construye los datos
- Prueba los datos
- Mantenimiento de datos (no detallado en este documento porque no es relevante)
# 1. Identificar los requisitos de datos
En el ejemplo anterior, la base de datos almacena millones de registros. Si el contenido de todos los libros se extrae en un archivo XML, se requiere una validación detallada. A medida que se tiene que enviar nueva información a la página web, el XML y el esquema pueden sufrir cambios.
Los cambios en XML, XSD, XPATH y XSLT requieren una validación adecuada. Pero esta prueba no necesita esperar a la presentación, el middleware y el lanzamiento del nivel de datos. El equipo de control de calidad puede analizar XSD para preparar un plan de requisitos de datos.
preguntas y respuestas de la entrevista de cisco networking pdf
| Etapa del ciclo de la vida | Criterio para entrar | Actividades / Responsabilidad | Criterio de salida |
|---|---|---|---|
| Identificar los requisitos de datos de prueba | Los siguientes documentos están disponibles Diseño de base de datos, diseño de UI, especificación de requisitos, arquitectura técnica, diagrama de flujo de datos, diagramas de casos de uso | Comprender los requisitos de datos que hacen referencia a los documentos a partir de los criterios de entrada (QA, DT, DEV) Requisitos de datos de prueba (QA, DT, DEV): documenta todas las necesidades de datos para cada pantalla y muestra un mapeo entre los nombres de visualización de pantalla y el elemento XML correspondiente. | Revise el documento de requisitos de datos de prueba (QA, DEV, DT) |
El proceso de identificación de todos los requisitos de datos para un producto debe abordar lo siguiente:
a) Cobertura e integridad - ¿Los requisitos identificados cubren todos los casos de uso?
Ejemplo - Es muy importante probar las combinaciones de datos para título, autor, categoría, idioma en la muestra XML anterior; ya que el esquema exige estos campos.
Esto se puede manejar fácilmente mirando el esquema XML que describe la presencia de un elemento / atributo y su orden en el XML.
b) Calidad - ¿Los datos recopilados son de la mejor calidad posible? Los datos de prueba utilizados determinan la calidad de las pruebas realizadas en la aplicación.
- Positivo y escenarios negativos - Las pruebas deben verificar cómo se comporta la aplicación con los datos de entrada válidos / no válidos
los documento de requisitos de datos de prueba enumera las necesidades de datos en todos los niveles de la aplicación. Los datos de la base de datos se pueden utilizar directamente en la interfaz de usuario y / o manipular (cálculos, concatenación, etc.). Por lo tanto, es necesario capturar todas las necesidades de datos.
La siguiente tabla representa una tabla de datos de muestra:
| Nombre del campo | Tipo de datos | Datos de prueba | Observaciones | Resultado de la prueba |
|---|---|---|---|---|
| Autor | Cuerda | Campo en blanco | Ya que es un campo obligatorio. La prueba debería fallar. | |
| Autor | Cuerda | Autor + @ | Tiene caracteres especiales | Esta prueba debería fallar |
| Autor | Cuerda | Nombre del autor | Incluye un espacio | Esta prueba debe pasar |
| Autor | Cuerda | 123 Autor | Comienza con un número | Esta prueba debería fallar |
| Autor | Cuerda | @!Autor | Comienza con caracteres especiales | Esta prueba debería fallar |
| Autor | Cuerda | Autor | Prefijado con espacios | Esta prueba debería fallar |
En el ejemplo anterior, se puede evitar el uso del tipo de datos de cadena para el campo Autor. En cambio, se puede imponer un patrón.
P.ej. solo alfabetos, comience con una letra mayúscula, sin caracteres especiales, etc. A patrón (que restringe un valor de elemento definido en XSD) se puede definir como .
Si esto está configurado para el autor elemento en el ejemplo anterior, significa, el autor El elemento debe tener el valor con una combinación de letras mayúsculas, minúsculas y números enteros positivos únicamente.
# 2. Planificar la recopilación de datos
| Etapa LC | Criterio para entrar | Actividades / Responsabilidad | Criterio de salida |
|---|---|---|---|
| Planificar la recopilación de datos | Documento de requisitos de datos de prueba aprobados | Identificar la frecuencia de las necesidades de datos (DEV, QA) Lista de datos de prueba (QA) Definir esquema XML (DEV) | Revise la frecuencia de las necesidades de datos y los datos de prueba (DT) |
# 3. Construye los datos
| Etapa LC | Criterio para entrar | Actividades / Responsabilidad | Criterio de salida |
|---|---|---|---|
| Construir datos | Archivo de solicitud de datos | Construya los datos en la base de datos (DT) Extraiga los datos de la base de datos en XML (DT) Validar el XML contra el esquema (DT) Comparta el archivo XML con QA (DT) | El equipo de control de calidad recibe el archivo XML |
# 4. Prueba los datos
| Etapa LC | Criterio para entrar | Actividades / Responsabilidad | Criterio de salida |
|---|---|---|---|
| Prueba los datos | Archivo XML de solicitud de datos | Validar el XML contra el esquema para verificar que esté completo y correcto (QA) Actualizar el documento de mapeo con los resultados de las pruebas (QA) | Resultados de la prueba compartidos con DEV, equipo DT |
Como se indica en las tablas anteriores, QA valida el XML con el esquema para verificar si los datos están disponibles como se esperaba. Una vez que el esquema coincide, se puede confirmar que el contenido y su estructura están bien. Sin embargo, esto no confirma que el sistema recopile los datos con precisión.
Como sabemos, XML muestra una estructura de árbol con p no-hijo-hermano-ancestro-descendiente relación entre los nodos.
Mire la tabla a continuación para comprender las convenciones XPATH más simples:
Para representar los campos del XML en una pantalla (como HTML por ejemplo) se utiliza la combinación XSLT - XPATH.
|_+_|En un navegador, finalmente, el XML resultante se representa como se muestra a continuación. Dado que los datos ya han sido verificados, el enfoque de las pruebas puede estar más en la apariencia de la pantalla.
Conclusión
- Las pruebas de datos realizadas al principio del ciclo de vida de las pruebas de desarrollo ahorran dinero, ya que el costo de corregir un error durante la ejecución de la prueba funcional es mucho más que solucionarlo al principio del ciclo de vida.
- El esfuerzo invertido inicialmente en la validación del archivo XML, XPath y XSLT con documentos XSD ayuda a evitar múltiples iteraciones de la versión.
- El equipo de control de calidad puede trabajar en estrecha colaboración con el equipo de desarrollo y brindar un servicio de valor agregado
- El equipo de control de calidad puede ayudar a simular varias combinaciones de datos para garantizar la cobertura y la corrección
Estoy seguro de que esta técnica le resultará útil. No dudes en comentar si tienes alguna duda.
Lectura recomendada
- Un enfoque simple para pruebas de XML para bases de datos
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Diferencias clave entre las pruebas de caja negra y las pruebas de caja blanca
- Las 10 herramientas más populares de almacenamiento de datos y tecnologías de prueba
- Tutorial de pruebas de almacenamiento de datos de pruebas ETL (una guía completa)
- Descarga del libro electrónico Testing Primer
- ¿Qué es la prueba de mutación? Tutorial con ejemplos
- Cómo realizar pruebas basadas en datos con la herramienta TestComplete