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