Excepto para las aplicaciones de software más triviales, por lo general, se considera imposible probar todas las
combinaciones de entradas factibles lógicamente para un sistema de software. Por consiguiente, seleccionar un
subconjunto óptimo que ofrezca la máxima probabilidad de encontrar el mayor número de errores es una tarea importante y
que vale la pena que lleven a cabo los verificadores.
Realizar pruebas basadas en el análisis de clase de equivalencia (sinónimos: partición de equivalencia,
análisis de dominio) es una forma de análisis de prueba de caja negra que intenta reducir el número total de
pruebas potenciales a un conjunto mínimo de pruebas que revelan tantos errores como sea posible [MYE79]. Este método particiona el conjunto de entradas y salidas en un número finito
de clases
de equivalencia que permite seleccionar un valor de prueba representativo para cada clase. La prueba resultado
del valor representativo para una clase es el "equivalente" a los otros valores de la misma clase. Si no se encuentra
ningún error en la prueba del valor representativo, se estima que todos los demás valores "equivalentes" tampoco
hubieran identificado ningún error.
El poder de las clases de equivalencia yace en su capacidad de orientar al verificador mediante la estrategia de
pruebas para reducir la explosión combinatoria de las pruebas potencialmente necesarias. La técnica proporciona unas
bases lógicas por la cuales un subconjunto del número total concebible de pruebas se puede seleccionar. Aquí se
muestran algunas categorías de áreas de problemas para grandes números de pruebas que se pueden beneficiar de la
consideración de clases de equivalencia:
-
Combinaciones de variables independientes
-
Variables dependientes basadas en relaciones jerárquicas
-
Variables dependientes basadas en relaciones temporales
-
Relaciones en clúster basadas en ejemplares del mercado
-
Relaciones complejas que se pueden modelar
Existen técnicas y estrategias diferentes que se pueden utilizar en la prueba de partición de equivalencia. Estos son
algunos ejemplos:
Teoría de partición de equivalencia tal como la propone Glenford Myers [MYE79]. Intenta
reducir el número total de casos de prueba necesarios al particionar las condiciones de entrada en un número finito de
clases de equivalencia. Se han clasificado ambos tipos de clases de equivalencia: el conjunto de entradas válidas en el
programa se considera como la clase de equivalencia válida, y todas las demás entradas se incluyen en la
clase de equivalencia no válida.
A continuación se incluye un conjunto de directrices para identificar clases de equivalencia:
-
Si una condición de entrada especifica un rango valores (por ejemplo, el programa "acepta valores de 10 a 100"), se
identifican una clase de equivalencia válida (de 10 a 100) y dos clases de equivalencia no válidas (menor que 10 y
mayor que 100).
-
Si una condición de entrada especifica un conjunto de valores (por ejemplo, "la tela ser de varios colores: ROJO,
BLANCO, NEGRO, VERDE, MARRÓN"), se identifica una clase de equivalencia válida (los valores válidos) y una clase de
equivalencia no válida (todos los demás valores no válidos). Cada valor de la clase de equivalencia válida se debe
manejar de modo diferente.
-
Si la condición de entrada se especifica como una situación de obligación (por ejemplo, "la cadena de caracteres de
entrada debe ser en mayúsculas"), se identifica una clase de equivalencia válida (caracteres en mayúsculas) y una
clase de equivalencia no válida (todas las demás entradas excepto los caracteres en mayúsculas).
-
Todo lo que finaliza "mucho" antes de que se lleve a cabo la tarea es una clase de equivalencia. Todo lo que se
realiza durante un intervalo de tiempo corto antes de que finalice el programa es otra clase. Todo lo que se
realiza antes de que el programa inicie otra operación es otra clase.
-
Si se especifica que un programa funcione con un tamaño de memoria de 64 M a 256 M. Este rango de tamaño es una
clase de equivalencia. Se puede aceptar cualquier otro tamaño de memoria que sea mayor que 256 M o menor que 64 M.
-
La partición del suceso de salida se basa en las entradas del programa. Aunque clases de equivalencia de entrada
diferentes pueden tener el mismo tipo de suceso de salida, las clases de equivalencia de entrada se deben seguir
tratando de forma distinta.
En cada una de las clases de equivalencia, se considera que las condiciones de límite tienen un mayor índice de éxito
en la identificación de las anomalías resultantes que las condiciones que no son de límite. Las condiciones de límite
son los valores que se encuentran en, inmediatamente por encima o por debajo del límite o los "bordes" de cada clase de
equivalencia.
Las pruebas que son resultado de las condiciones de límite utilizan valores que se encuentran en el mínimo (min), justo
encima del mínimo (min+), justo debajo del máximo (max-) y el máximo (max) del rango que se debe probar. Al probar los
valores de límite, los verificadores eligen algunos casos de prueba para cada clase de equivalencia. Para la muestra de
pruebas relativamente pequeña, la probabilidad de descubrimiento de anomalías es alta. Se ha reducido al verificador
parte de la carga que supone probar una amplia población de casos en una clase de valores equivalente que es improbable
que produzca diferencias importantes en los resultados de la prueba.
Algunas recomendaciones al elegir valores de límite:
-
Para una variable flotante, si la condición válida para ésta es de
-1.0 a 1.0 , probar
-1.0 , 1.0 , -1.001 y 1.001 .
-
Para un entero, si el rango de entrada válido es de
10 a 100 , probar 9 ,
10 , 100 , 101 .
-
Si un programa espera una letra en mayúsculas, probar de la A a la Z de límite. Probar también
@ y
[ puesto que, en el código ASCII, @ está junto debajo de la A y [ está justo
después de la Z.
-
Si la entrada o la salida de un programa es un conjunto ordenado, conviene prestar atención al primer y al último
elemento del conjunto.
-
Si la suma de las entradas debe ser un número específico (
n ), probar el programa donde la suma sea
n-1 , n , o bien, n+1 .
-
Si el programa acepta una lista, probar los valores de la lista. Todos los demás valores no son válidos.
-
Al leer o escribir un archivo, comprobar los caracteres primero y último del archivo.
-
La denominación de moneda más pequeña es un céntimo o equivalente. Si el programa acepta un rango específico, de la
a a la b, probar a
-0.01 y b +0.01 .
-
Para una variable con varios rangos, cada rango es una clase de equivalencia. Si los subrangos no están solapados,
probar los valores de los límites, después del límite superior y debajo del límite inferior.
Después de intentar las dos estrategias de análisis de límite anteriores, un verificador con experiencia puede observar
las entradas de programa para descubrir todos los casos de "valores especiales" que, una vez más son, potencialmente,
fuentes valiosas para revelar anomalías de software. Estos son algunos ejemplos:
-
Para un tipo de entero, se debe probar siempre cero si se encuentra en la clase de equivalencia válida.
-
Al probar la hora (hora, minuto y segundo), se debe probar siempre 59 y 0 como el límite superior e inferior para
cada campo, sin tener en cuenta la restricción que tenga la variable de entrada. Así, excepto los valores de límite
de la entrada, -1, 0, 59 y 60 siempre deben ser casos de prueba.
-
Al probar la fecha (año, mes y día), se deben incluir numerosos casos de prueba como, por ejemplo, un número de
días en un mes específico, el número de días de febrero en año bisiesto o el número de días en años no bisiestos.
Ostrand and Balcer [16] han desarrollado un método de partición que ayuda a los
desarrolladores a analizar la especificación del sistema, escribir scripts de prueba y gestionarlos. Diferente a la
mayoría de estrategias que, básicamente, se centran en el código, su método se basa también en la información del
diseño y la especificación.
La principal ventaja de este método es la posibilidad de revelar errores antes de escribir el código, puesto que el
origen de entrada es la especificación y las pruebas son resultado del análisis de dicha especificación. Las faltas en
las especificaciones se descubren pronto, con frecuencia bastante antes de que se implementen en código.
La estrategia del método "categoría-partición" es la siguiente:
-
Analizar la especificación: descomponer la funcionalidad del sistema en unidades funcionales, de modo que tanto se
puedan probar independientemente tanto por la especificación como por la implementación.
A partir de ahí:
-
Identificar los parámetros y las condiciones de entorno que van a influir en la ejecución de la función.
Los parámetros son las entradas de la unidad de función. Las condiciones de entorno son los estados del
sistema, que producen la ejecución de la unidad de función.
-
Identificar las características de los parámetros y las condiciones de entorno.
-
Clasificar las características en categorías, que producen el comportamiento del sistema.
En este estadio se descubren las descripciones del comportamiento ambiguas, contradictorias y que
faltan.
-
Particionar las categorías en opciones: Las opciones son las distintas situaciones posibles que pueden ocurrir y no
se esperan. Representan el mismo tipo de información en una categoría.
-
Determinar las relaciones y las restricciones entre las opciones. Las opciones de categorías diferentes influyen
entre sí, lo que también influye en la construcción del conjunto de aplicaciones de prueba. Las restricciones se
añaden para eliminar la contradicción entre opciones de entornos y parámetros diferentes.
-
Diseñar casos de prueba según las categorías, las opciones y la información de las restricciones. Si una opción
causa un error, no se debe combinar con otras opciones para crear el caso de prueba. Si una única prueba puede
probar "suficientemente" una opción, puede ser el representante de la opción o un valor especial.
-
Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
-
White L. J. and Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software
Engineering, Vol. SE-6, No. 3, 1980.
-
Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on
Software Engineering, 8-4, 1992.
-
Steven J. Zeil, Faten H. Afifi and Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction
on Software Engineering and Methodology, 1-4, 1992.
-
BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering
and Methodology, 3-3, 1994.
-
Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
-
Martin R. Woodward and Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal
triangle, ACM Press New York, NY, 2000.
-
Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software
Engineering, 71-16, 2000.
-
Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New
York, 2002.
-
Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special
Interest Group on Software Engineering, 18-5, 1993.
-
Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM
Special Interest Group on Software Engineering, 1981.
-
Lori A. Clarke, Johnette Hassell, and Debra J Richardson, A system to generate test data and symbolically execute
programs, IEEE Transaction on Software Engineering, SE-2, 1976.
-
Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons,
Inc., 1995.
-
Steven J. Zeil, Faten H. Afifi and Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM
Transaction on Software Engineering and Methodology, 1-4, 1992.
-
William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
-
Thomas J. Ostrand and Marc J. Balcer, The Category-Partition method
for specifying and generating functional tests, Communications of ACM 31, 1988.
-
Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.
|