Directriz: Análisis de clase de equivalencia
Análisis de clase de equivalencia es una técnica para minimizar el número de casos de prueba. En esta directriz se explica lo que es esta técnica y cómo utilizarla.
Relaciones
Descripción principal

Introducción

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:

  1. Combinaciones de variables independientes
  2. Variables dependientes basadas en relaciones jerárquicas
  3. Variables dependientes basadas en relaciones temporales
  4. Relaciones en clúster basadas en ejemplares del mercado
  5. Relaciones complejas que se pueden modelar

Estrategias

Existen técnicas y estrategias diferentes que se pueden utilizar en la prueba de partición de equivalencia. Estos son algunos ejemplos:

Partición de clase de equivalencia

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:

  1. 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).
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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.

Análisis de valor de límite

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:

  1. 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.
  2. Para un entero, si el rango de entrada válido es de 10 a 100, probar 9, 10, 100, 101.
  3. 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.
  4. 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.
  5. 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.
  6. Si el programa acepta una lista, probar los valores de la lista. Todos los demás valores no son válidos.
  7. Al leer o escribir un archivo, comprobar los caracteres primero y último del archivo.
  8. 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.
  9. 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.

Valores especiales

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:

  1. Para un tipo de entero, se debe probar siempre cero si se encuentra en la clase de equivalencia válida.
  2. 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.
  3. 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.

Método "Categoría-Partición"

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:

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

    1. 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.
    2. Identificar las características de los parámetros y las condiciones de entorno.
    3. 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.

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

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

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

Más información y consultas

  1. Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
  2. 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.
  3. Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on Software Engineering, 8-4, 1992.
  4. 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.
  5. BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering and Methodology, 3-3, 1994.
  6. Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
  7. 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.
  8. Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software Engineering, 71-16, 2000.
  9. Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New York, 2002.
  10. Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special Interest Group on Software Engineering, 18-5, 1993.
  11. Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM Special Interest Group on Software Engineering, 1981.
  12. 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.
  13. Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons, Inc., 1995.
  14. 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.
  15. William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
  16. Thomas J. Ostrand and Marc J. Balcer, The Category-Partition method for specifying and generating functional tests, Communications of ACM 31, 1988.
  17. Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.