El particionamiento de equivalencia o el particionamiento de clase de equivalencia ( ECP ) [1] es una técnica de prueba de software que divide los datos de entrada de una unidad de software en particiones de datos equivalentes de los que se pueden derivar casos de prueba. En principio, los casos de prueba están diseñados para cubrir cada partición al menos una vez. Esta técnica intenta definir casos de prueba que descubren clases de errores, reduciendo así el número total de casos de prueba que deben desarrollarse. Una ventaja de este enfoque es la reducción del tiempo necesario para probar el software debido al menor número de casos de prueba.
La partición de equivalencia se aplica normalmente a las entradas de un componente probado, pero se puede aplicar a las salidas en casos excepcionales. Las particiones de equivalencia se derivan generalmente de la especificación de requisitos para los atributos de entrada que influyen en el procesamiento del objeto de prueba.
El concepto fundamental de ECP proviene de la clase de equivalencia que a su vez proviene de la relación de equivalencia . Un sistema de software es en efecto una función computable implementada como un algoritmo en algún lenguaje de programación de implementación . Dado un vector de prueba de entrada , algunas instrucciones de ese algoritmo se cubren (consulte la cobertura del código para obtener más detalles), otras no. Esto da la interesante relación entre los vectores de prueba de entrada: -es una relación de equivalencia entre los vectores de prueba a, b si y solo si la huella de cobertura de los vectores a, b es exactamente la misma, es decir, cubren las mismas instrucciones, en el mismo paso. Evidentemente, esto significaría que la cobertura de relación C dividiría el espacio del vector de entrada del vector de prueba en una clase de equivalencia múltiple . Esta partición se denomina partición de clase de equivalencia de la entrada de prueba. Si hay N clases equivalentes, solo N vectores son suficientes para cubrir completamente el sistema.
La demostración se puede hacer usando una función escrita en C :
int safe_add ( int a , int b ) { int c = a + b ; if ( a > 0 && b > 0 && c <= 0 ) { fprintf ( stderr , "Overflow (positivo)! \ n " ); } if ( a < 0 && b < 0 && c > = 0 ) { fprintf ( stderr , "Overflow (negativo)! \ n " ); } return c ; }
Sobre la base del código, los vectores de entrada de [ a , b ] se dividen. Los bloques que debemos cubrir son el desbordamiento en la dirección positiva, la dirección negativa y ninguno de estos 2. Eso da lugar a 3 clases equivalentes, a partir de la propia revisión del código.
Para resolver el problema de entrada, nos refugiamos en la inecuación
observamos que hay un tamaño fijo de Integer (informática) , por lo tanto, la z se puede reemplazar con: -
- INT_MIN ≤ x + y ≤ INT_MAX
y
con x ∈ {INT_MIN, ..., INT_MAX} e y ∈ {INT_MIN, ..., INT_MAX}
Los valores del vector de prueba en la condición estricta de la igualdad que es INT_MIN = x + y e INT_MAX = x + y se denominan valores de frontera. El análisis de valores de frontera tiene información detallada al respecto. Tenga en cuenta que el gráfico solo cubre el caso de desbordamiento, primer cuadrante para los valores positivos de X e Y.
En general, una entrada tiene ciertos rangos que son válidos y otros rangos que no lo son. Los datos no válidos aquí no significan que los datos sean incorrectos, significa que estos datos se encuentran fuera de una partición específica. Esto puede explicarse mejor con el ejemplo de una función que toma un parámetro "mes". El rango válido para el mes es de 1 a 12, lo que representa de enero a diciembre. Este rango válido se llama partición. En este ejemplo, hay dos particiones más de rangos no válidos. La primera partición inválida sería ≤ 0 y la segunda partición inválida sería ≥ 13.
... -2-1 0 1 .............. 12 13 14 15 ..... -------------- | ------------------- | --------------- ------ partición no válida 1 partición válida partición no válida 2
La teoría de prueba relacionada con la partición de equivalencia dice que solo se necesita un caso de prueba de cada partición para evaluar el comportamiento del programa para la partición relacionada. En otras palabras, es suficiente seleccionar un caso de prueba de cada partición para verificar el comportamiento del programa. Usar más o incluso todos los casos de prueba de una partición no encontrará nuevas fallas en el programa. Los valores dentro de una partición se consideran "equivalentes". Por tanto, el número de casos de prueba se puede reducir considerablemente.
Un efecto adicional de aplicar esta técnica es que también encontrará los casos de prueba denominados "sucios". Un evaluador sin experiencia puede tener la tentación de usar como casos de prueba los datos de entrada del 1 al 12 para el mes y olvidarse de seleccionar algunas de las particiones no válidas. Esto conduciría a una gran cantidad de casos de prueba innecesarios, por un lado, y a la falta de casos de prueba para los rangos sucios, por otro lado.
La tendencia es relacionar la partición de equivalencia con las llamadas pruebas de caja negra, que consiste en verificar estrictamente un componente de software en su interfaz, sin tener en cuenta las estructuras internas del software. Pero al observar más de cerca el tema, hay casos en los que también se aplica a las pruebas de caja gris . Imagine una interfaz para un componente que tiene un rango válido entre 1 y 12 como en el ejemplo anterior. Sin embargo, internamente, la función puede tener una diferenciación de valores entre 1 y 6 y valores entre 7 y 12. Dependiendo del valor de entrada, el software internamente se ejecutará a través de diferentes rutas para realizar acciones ligeramente diferentes. Con respecto a las interfaces de entrada y salida del componente, esta diferencia no se notará, sin embargo, en sus pruebas de caja gris, le gustaría asegurarse de que se examinen ambas rutas. Para lograr esto, es necesario introducir particiones de equivalencia adicionales que no serían necesarias para las pruebas de caja negra. Para este ejemplo, esto sería:
... -2-1 0 1 ..... 6 7 ..... 12 13 14 15 ..... -------------- | --------- | ---------- | -------------- ------- partición 1 inválida P1 P2 partición 2 inválida particiones válidas
Para verificar los resultados esperados, necesitaría evaluar algunos valores intermedios internos en lugar de la interfaz de salida. No es necesario que debamos utilizar varios valores de cada partición. En el escenario anterior, podemos tomar -2 de la partición no válida 1, 6 de la partición válida P1, 7 de la partición válida P2 y 15 de la partición no válida 2.
La partición de equivalencia no es un método independiente para determinar casos de prueba. Debe complementarse con un análisis de valor límite . Una vez determinadas las particiones de posibles entradas, se debe aplicar el método de análisis de valor límite para seleccionar los casos de prueba más efectivos de estas particiones.
Limitaciones
En los casos en que los rangos o conjuntos de datos involucrados se acerquen a la simplicidad (Ejemplo: 0-10, 11-20, 21-30), y probar todos los valores sería práctico, se debe considerar la cobertura de prueba general utilizando todos los valores dentro y bordeando los rangos. La cobertura de prueba general puede revelar errores que no se detectarían con el método de partición de equivalencia, si el software incluye subparticiones que el evaluador desconoce. [2] Además, en casos simplistas, el beneficio de reducir el número de valores de prueba mediante el uso de partición de equivalencia disminuye, en comparación con los casos que involucran rangos más grandes (Ejemplo: 0-1000, 1001-2000, 2001-3000).
Otras lecturas
- Sitio web del Grupo de trabajo sobre normas de prueba
- Parteg , una herramienta de generación de pruebas gratuita que combina la generación de rutas de prueba a partir de máquinas de estado UML con la generación de clases de equivalencia de valores de entrada.
- https://books.google.com/books/about/Software_Testing_Techniques.html