Directriz: Datos de prueba
En esta directriz se muestra una introducción al diseño de conjuntos de datos de prueba.
Relaciones
Elementos relacionados
Descripción principal

Explicación

En la tarea de diseño de prueba, se han identificado y descrito dos artefactos importantes: Scripts de prueba y Casos de prueba. Si datos de prueba, estos dos artefactos no se pueden implementar ni ejecutar. Son, tan solo, descripciones de condiciones, casos de ejemplo y vías de acceso sin valores concretos que los identifiquen sucintamente. Los datos de prueba, aunque no son un artefacto en sí mismos, afectan de modo importante en el éxito (o anomalía) de la prueba. La prueba no se puede implementar ni ejecutar si datos de prueba, puesto que se necesitan datos de prueba para lo siguiente:

  • entrada para crear una condición
  • salida para evaluar un requisito
  • soporte (una condición previa a la prueba)

Por este motivo, la identificación de valores es un esfuerzo importante que se lleva a cabo cuando se identifican los casos de prueba (consulte los apartados Producto de trabajo: Caso de prueba y Directriz: Caso de prueba).

Al identificar los datos de prueba reales, hay cuatro atributos de los datos de prueba que se deben tratar:

  • profundidad - volumen o cantidad de datos en los datos de prueba
  • extensión - grado de variación de los datos de prueba
  • ámbito - aplicabilidad de los datos de prueba al objetivo de la prueba
  • arquitectura - estructura física de los datos de prueba

En los apartados siguientes se trata con más detalle cada una de estas características:

Profundidad

Profundidad es el volumen o la cantidad de datos que se utiliza para la prueba. La profundidad es una consideración importante, puesto que la escasez de datos puede no reflejar condiciones de la vida real, mientras que el exceso de datos es difícil de gestionar y mantener. Lo ideal es que la prueba se inicie con un pequeño conjunto de datos que ofrezca soporte para los casos de prueba críticos (por lo general, los casos de prueba positivos). A medida que se vaya ganando seguridad durante la prueba, se deben aumentar los datos de prueba hasta que la profundidad de datos sea representativa del entorno desplegado (o que sea adecuada y viable).

Extensión

La extensión hace referencia al grado de variación de los valores de los datos de prueba. Se puede aumentar la profundidad de los datos de prueba, simplemente creando más registros. Mientras que, por lo general, es una solución adecuada, no trata las variaciones verdaderas de los datos que se espera encontrar en los datos reales. Si estas variaciones en los datos de prueba, es posible que no se puedan identificar defectos (después de todo, no todas las retiradas de los cajeros automáticos son de un importe de 50,00 dólares). Por ello, los valores de datos deben reflejar los valores de datos que se encuentran en el entorno desplegado como, por ejemplo, 10,00 ó 120,00 dólares. Además, los datos de prueba deben reflejar información del mundo real, por ejemplo:

  • Nombres que incluyan títulos, valores numéricos, puntuación y sufijos:
    • Dr. James Bandlin, Ms. Susan Smith y Rev. Joseph P. Mayers
    • James Johnson III, Steven Wilshire 3rd y Charles James Ellsworth, Esq.
    • Ellen Jones-Smythe, Brian P. Tellstor
  • Direcciones con varias líneas de dirección, por ejemplo:
    • 6500 Broadway Street
      Suite 175
    • 1550 Broadway
      Piso 17
      Mailstop 75A
  • Códigos de ciudad (y país) y números de teléfono que sean reales y mantengan correspondencia:
    • Lexington, MA, EE.UU. + 01 781 676 2400
    • Kista, Suecia +46 8 56 62 82 00
    • París, Francia +33 1 30 12 09 50

Los valores de datos de prueba pueden ser una representación física o una representación estadística de los datos reales para obtener la extensión suficiente. Se sugieren y valoran ambos métodos.

Para crear datos de prueba basados en una representación física de los datos desplegados, identifique los valores (o rangos) permitidos para cada elemento de datos de la base de datos desplegada y asegúrese de que, para cada elemento de datos haya, como mínimo, un registro en los datos de prueba que contenga cada valor permitido.

Por ejemplo:

  Número de cuenta (rango) Número secreto
(entero)
Saldo de cuenta
(decimal)
Tipo de cuenta
(cadena de caracteres)
(S) 0812 0000 0000 a
0812 9999 9999

© 0829 0000 0000 a
0829 9999 9999

(X) 0799 0000 0000 a
0799 9999 9999

0000 - 9999 -999.999,99 a 999.999,99 S, C, X
registro 1 0812 0837 0293 8493 -3.123,84 S
registro 2 0812 6493 8355 3558 8.438,53 S
registro 3 0829 7483 0462 0352 673,00 C
registro 4 0799 4896 1893 4896 493.498,49 X

La matriz anterior contiene el número mínimo de registros que representan físicamente los valores de datos aceptables. Para el número de cuenta, hay un registro para cada uno de los tres rangos, todos los números de PIN se encuentran dentro del rango especificado, hay varios saldos de cuenta diferentes, incluido uno que es negativo, y hay registros para cada uno de los diferentes tipos de cuenta. La matriz anterior son los datos mínimos, y la recomendación sería disponer de valores de datos tanto en los límites de cada rango como dentro del rango (consulte el apartado Directriz: Caso de prueba).

La ventaja de la representación física es que los datos de prueba tienen un tamaño limitado y gestionable, centrado y dirigido a los valores aceptables. Sin embargo, la desventaja es que los datos del mundo real no son totalmente aleatorios. Los datos reales tienden a tener perfiles estadísticos que puede afectar al rendimiento, lo que no se tiene en cuenta al utilizar la representación física.

La representación de los datos de prueba estadísticos son los datos de prueba que reflejan una creación de ejemplos estadísticos (de los mismos porcentajes) de los datos de producción. Por ejemplo, utilizando los mismos elementos de datos que más arriba, si se analiza la base de datos de producción y se descubre lo siguiente:

  • Número total de registros: 294.031
  • Número total de tipo de cuenta S: 141.135 (48 % del total)
  • Número total de tipo de cuenta C: 144.075 (49 %)
  • Número total de tipo de cuenta X: 8.821 (3 %)
  • Los números de cuenta y los números de PIN están distribuidos equitativamente

los datos de prueba, basados en la creación de ejemplos estadísticos incluiría 294 registros (si se compara con los cuatro que se han indicado más arriba):

  Datos de prueba (al .1 por ciento de producción)
Número de registros Porcentaje
Número total de registros 294 100
Números de cuenta
(S) 0812 0000 0000 a
0812 9999 9999
141 48
Números de cuenta
© 0829 0000 0000 a
0829 9999 9999
144 49
Números de cuenta
(X) 0799 0000 0000 a
0799 9999 9999
9 3

La matriz anterior sólo trata los tipos de cuenta. Al desarrollar los datos de prueba más correctos basados en la representación estadística, se deberían incluir los elementos de datos significativos. En el ejemplo anterior, incluiría reflejar los saldos de cuenta reales.

Una desventaja de la representación estadística es que no refleja el rango completo de valores aceptables.

Por lo general, se utilizan ambos métodos de identificación de datos de prueba para garantizar que los datos de prueba tratan todos los valores y problemas de población / rendimiento.

La extensión de los datos de prueba es adecuada para los datos de prueba que se utilizan como entrada, así como para los datos de prueba que se utilizan para dar soporte a la prueba (en datos preexistentes).

Ámbito

El ámbito es la aplicabilidad de los datos de prueba al objetivo de la prueba, y está relacionado con la profundidad y la extensión. Tener una gran cantidad de datos no significa que sean los datos correctos. Como en el caso de la extensión de los datos de prueba, se debe garantizar que los datos de prueba sean adecuados, es decir, que haya datos de prueba para dar soporte al objetivo de prueba específico.

Por ejemplo, en la matriz anterior, los cuatro primeros registros de datos de prueba tratan los valores aceptables para cada elemento de datos. Sin embargo, no hay registros para evaluar los saldos negativos para los tipos de cuenta C y X, por ello, aunque los datos de prueba incluyan de modo correcto saldos negativos (extensión válida), los datos que se sitúan por debajo resultan insuficientes en este ámbito para dar soporte a cualquier prueba que utilice saldos de cuenta negativos para cada tipo de cuenta. Para tratar esta omisión, se necesita ampliar los datos a fin de incluir otros registros, incluidos saldos negativos, para cada uno de los distintos tipos de cuenta.

Número de cuenta (rango) Número secreto
(entero)
Saldo de cuenta
(decimal)
Tipo de cuenta
(cadena de caracteres)
(S) 0812 0000 0000 a
0812 9999 9999

© 0829 0000 0000 a
0829 9999 9999

(X) 0799 0000 0000 a
0799 9999 9999

0000 - 9999 -999.999,99 a 999.999,99 S, C, X
registro 1 0812 0837 0293 8493 -3.123,84 S
registro 2 0812 6493 8355 3558 8.438,53 S
registro 3 0829 7483 0462 0352 673,00 C
registro 4 0799 4896 1893 4896 493.498,49 X
Nuevo registro 1 0829 3491 4927 0352 -995.498,34 C
Nuevo registro 2 0799 6578 9436 4896 -64.913,87 X

El ámbito de los datos de prueba es adecuado para los datos de prueba que se utilizan como entrada, así como para los datos de prueba que se utilizan para dar soporte a la prueba (en datos preexistentes).

Arquitectura

La estructura física de los datos de prueba sólo es adecuada para cualquier dato preexistente que utilice el destino de la prueba para dar soporte a la prueba, por ejemplo, una tabla de reglas o una base de datos de la aplicación.

La prueba no se ejecuta una vez y se finaliza. La prueba se repite en y entre iteraciones. Con el objeto de ejecutar la prueba de modo coherente, seguro y eficaz, los datos de prueba se deben devolver a su estado inicial anterior a la ejecución de la prueba. Esto se aplica, en especial, cuando se va a automatizar la prueba.

Por este motivo, y para garantizar la integridad, la seguridad y la eficacia de la prueba, resulta de extrema importancia que los datos de prueba estén libres de todas las influencias externas y que se conozca su estado al principio, durante y al final de la ejecución de la prueba. Para lograr este objetivo de la prueba, se deben tratar dos problemas:

Cada uno de estos problemas afecta al modo en que se gestiona la base de datos de prueba, se diseña el modelo de prueba y se interactúa con otros roles.

Inestabilidad / Segregación

Los datos de prueba pueden convertirse en inestables por los motivos siguientes:

  • influencias externas no relacionadas con la prueba modifican los datos
  • los verificadores desconocen los datos que utilizan los demás verificadores

Para mantener la seguridad y la integridad de la prueba, los datos de prueba se deben controlar y aislar correctamente de dichas influencias. Las estrategias para asegurar que se han aislado los datos de prueba incluyen:

  • entornos de prueba separados - los verificadores tienen su propio entorno de prueba, separado físicamente de los demás. Los verificadores no comparten nada, es decir, tienen sus propios datos y destino de la prueba. Se puede conseguir, por ejemplo, si cada verificador tiene su propio PC.
  • instancias de base de datos de prueba separados - los verificadores tienen su propia instancia de datos, aislados de todas las demás influencias. Se comparte el entorno físico, quizá incluso el destino de la prueba, pero si cada verificador tiene su propia instancia de datos, se reduce mucho el riesgo de contaminación de los datos de prueba.
  • partición de base de datos / datos de prueba - todos los verificadores comparten la base de datos y están bien informados sobre los datos que utilizan los demás (y evitan utilizar los datos de otros verificadores). Por ejemplo, un verificador utiliza los registros 0 a 99 y otro verificador utiliza los registros 100 a 199, o bien, alguno utiliza clientes cuyos apellidos empiecen por las letras de la Aa a la Kz, mientras que otro verificador utiliza pacientes cuyos nombres empiecen por las letras de la La a la Zz.

Estado inicial

El otro problema de la arquitectura de datos de prueba que se debe tratar es el del estado inicial de los datos de prueba al iniciar la ejecución de la prueba. En especial, esto se aplica cuando se utiliza la automatización de pruebas. Del mismo modo que el destino de la prueba debe iniciar la ejecución de la prueba en un estado conocido y deseado, lo mismo se aplica a los datos de prueba. Esto contribuye a la condición de repetición y seguridad de que cada ejecución de la prueba sea igual que la anterior.

Para tratar este problema se suelen utilizar cuatro estrategias:

  • renovación de los datos
  • reinicialización de los datos
  • restablecimiento de los datos
  • rehacer datos

Más abajo se describe con detalle cada una de ellas.

El método que se utiliza depende de varios factores, incluidas las características físicas de la base de datos, la competencia técnica de los verificadores, la disponibilidad de roles externos (no de prueba) y el destino de la prueba.

Renovación de los datos

El método más recomendable para volver los datos de prueba a su estado inicial es la Renovación de datos. Este método implica la creación y el almacenamiento de una copia de la base de datos en su estado inicial. Al terminar la ejecución de la prueba (o antes de la ejecución de la prueba), la copia archivada de la base de datos de prueba se copia en el entorno de prueba para su utilización. De este modo se asegura que el estado inicial de los datos de prueba es el mismo al principio de cada ejecución de la prueba.

Una ventaja de este método es que los datos se pueden archivar en varios estados iniciales diferentes. Por ejemplo, los datos de prueba se pueden archivar en el estado del final del día, el estado del final de la semana o el estado del final del mes, entre otros. De este modo, el verificador dispone de un método que le permite renovar rápidamente a un estado determinado con el objeto de dar soporte a una prueba, por ejemplo, al probar los casos de uso de final de mes.

Reinicialización de los datos

Si los datos no se pueden renovar, el método siguiente más adecuado consiste en restaurar los datos a su estado inicial a través de algún medio programático. La reinicialización de los datos se basa en herramientas y casos de uso especiales para devolver los datos de prueba a sus valores iniciales.

Debe tener cuidado y asegurarse de que todos los datos, las relaciones y los valores clave se devuelven a su valor inicial adecuado a fin de garantizar que no haya errores en los datos.

Una de las ventajas de este método es que puede ofrecer soporte para la prueba de valores no válidos en la base de datos. En condiciones normales, se debe bloquear la entrada de los valores de datos no válidos en los datos (por ejemplo, por medio de una regla de validación en el cliente). Sin embargo, otro actor puede afectar a los datos (por ejemplo, una actualización electrónica de otro sistema). La prueba debe verificar que se identifiquen y manejen correctamente los datos no válidos, con independencia de cómo se lleve a cabo.

Restablecimiento de los datos

Un método sencillo para volver los datos a su estado inicial es "revertir los cambios" realizados en los datos durante la prueba. Este método se basa en la utilización del destino de la prueba para entrar entradas de reversión, es decir, añadir registros / valores que se han suprimido, deshacer las modificaciones de los registros /valores modificados y suprimir los datos que se han añadido.

No obstante, este método tiene riesgos asociados, entre los que se incluyen:

  • se deben revertir todas las acciones, no sólo algunas
  • se basa en casos de uso en el destino de la prueba (que se deben probar para verificar si funciona correctamente antes de utilizarlos para el restablecimiento de los datos).
  • las claves de base de datos, los índices y los puntos no se deben o no se pueden restablecer

Si éste es el único método disponible en el entorno de verificación, evite utilizar claves de base de datos, índices y punteros como destinos principales de la verificación. Es decir, por ejemplo, utilice el campo Nombre del paciente para determinar si el paciente se ha añadido a la base de datos, en lugar de utilizar un número de ID de paciente generado por el sistema.

Rehacer datos

Rehacer datos es el método menos adecuado para tratar el estado inicial de los datos de prueba. De hecho, no se aplica realmente al problema. En vez de ello, al terminar la ejecución de la prueba el estado de los datos se convierte en el nuevo estado inicial de los datos de prueba. Por lo general, requiere modificar los datos de prueba utilizados para la entrada, y los casos de prueba y los datos de prueba utilizados para la evaluación de los resultados.

Hay algunas instancias en las que es necesario, por ejemplo, al final del mes. Si no existe archivador de los datos antes del final del mes, se deben ejecutar los datos de prueba y los scripts de prueba de cada día y semana con el objeto de "rehacer" los datos para el estado que se necesita para la prueba del proceso de fin de mes.

Entre los riesgos asociados a este método se incluyen:

  • las claves de base de datos, los índices y los puntos no se pueden restablecer (y no se pueden utilizar para la verificación)
  • los datos cambian constantemente
  • requiere esfuerzo adicional para certificar la verificación de los resultados