Técnicas para diseñar casos de prueba del software Carlos Núñez Lay RESUMEN Dada la actual ubicuidad del software, un mal funcionamiento del mismo puede ocasionar desde la molestia por un mensaje inapropiado, hasta la pérdida de cuantiosas sumas de dinero o, peor aún, de vidas humanas. Por ello, el software, a semejanza de cualquier artefacto tangible, debe ser sometido a pruebas para evaluar si cumple adecuadamente con lo que se espera de él. Aunque el desarrollador de software realiza pruebas del mismo, estas –aún en empresas con personal dedicado a esta actividad específica- se efectúan de manera intuitiva e informal. Dada la creciente demanda de software de calidad, la prueba o “testeo” del software en una actividad que ha evolucionado con el uso de diversas técnicas y herramientas que la alejan del arte y la acercan a la ingeniería. En las siguientes secciones se presentan los conceptos fundamentales de la prueba del software y se revisan algunas técnicas para diseñar casos de pruebas. Dentro del conjunto de estas técnicas se han escogido las referidas a las pruebas unitarias del código ejecutable, tanto desde un enfoque funcional (“caja negra”), como desde un enfoque estructural (“caja transparente” transparente” o “caja blanca”). Aunque también son importantes para la calidad del software, no son motivo de este artículo las pruebas estáticas, tales como las inspecciones grupales del código, o la revisión de programas por los colegas. 1. INTRODUCCIÓN Según la IEEE, probar el software es analizarlo para detectar diferencias entre las condiciones existentes y las requeridas, y para evaluar las características del mismo. Obsérvese que -según esta definición- probar el software no consiste en mostrar que el software realiza las funciones requeridas (“que funcione”). Por el contrario, se debe partir de la suposición de que el software contiene defectos y de que la prueba se realiza para detectar la mayor cantidad posible de estos y – en consecuencia – aumentar su confiabilidad y su calidad. El trabajo de probar software consiste –entonces- en diseñar casos de prueba, llevarlos a cabo en un entorno controlado, detectar defectos, documentarlos y reportarlos. Dado que usualmente se tienen limitaciones de tiempo y recursos, el número de casos de prueba debe ser finito y, por tanto, lo más eficientes posibles, es decir, que tenga una alta probabilidad de encontrar defectos. Probar todos los casos posibles puede resultar imposible, mientras que hacerlo con casos elegidos aleatoriamente encierra una alta probabilidad de no detectar defectos. En este artículo se describen algunas técnicas para diseñar casos de prueba del código ejecutable a nivel unitario. En la secciones siguientes se enumeran los principios que deben guiar este tipo de pruebas y las dos clases de técnicas que nos permiten diseñar casos de prueba eficientes: de caja negra o funcionales y de caja transparente (o blanca) o estructurales.
2. PRINCIPIOS DE LA PRUEBA DEL SOFTWARE Estos principios son importantes porque guiarán el accionar del profesional que prueba del software. Ilene Burstein señala los siguientes, reformulando los establecidos originalmente por Glenford J. Myers: Principio 1
Probar es el proceso que consiste en ejecutar un componente de software utilizando un conjunto de casos de prueba previamente seleccionados con la intención de detectar defectos y de evaluar su calidad. Esto supone separar las pruebas de la depuración o “debugging”, actividad esta que se refiere a reparar el software eliminando los defectos. Principio 2
Un buen caso de prueba es aquel que tiene una alta probabilidad de hallar defectos aún no detectados. Partiendo de la hipótesis de la presencia de un determinado tipo de defecto, se escogen las condiciones de entrada, se determinan los resultados esperados y se realiza la prueba para determinar si el defecto está o no presente. Principio 3
Los resultados de cada prueba deben ser revisados meticulosamente. Si un defecto es pasado por alto o si se declara –equivocadamente- la existencia de un defecto que no es tal, las consecuencias pueden ser muy costosas. Principio 4
Cada caso de prueba debe incluir el resultado esperado. El resultado esperado es lo que permitirá determinar si existen o no defectos. Principio 5
Los casos de prueba deben incluir condiciones de entrada válidas e inválidas. La robustez del software se puede evaluar probando su funcionamiento con entradas inválidas. Principio 6
La probabilidad de que existan defectos adicionales en un componente de software es directamente proporcional al número de defectos ya detectados en ese componente. Este principio se basa en la evidencia empírica. Las razones pueden ser el nivel de complejidad o algunos defectos de diseño. Principio 7
Las pruebas deben ser conducidas por personas independientes a las que hicieron el desarrollo. El desarrollador está síquicamente preparado para que su obra funcione “bien”, de modo que le será muy difícil asumir el principio 1: detectar defectos. Principio 8
Las pruebas deben ser repetibles y reutilizables. Las pruebas deben ser repetidas luego de haberse reparado el defecto. Además también serán muy útiles para las pruebas de regresión, es decir, las que se realizarán cuando, por razones de evolución o mejora, el software tenga que ser modificado. 3. TÉCNICAS DE CAJA NEGRA El término “Caja Negra” se refiere a que con este enfoque se deja de lado la estructura interna del software, es decir, solo se toma en cuenta qué hace (o debe hacer) el software, mas no el cómo lo hace. La materia prima para estas técnicas puede ser la descripción funcional del software, las condiciones de entrada y de salida, o un diagrama Entrada-Proceso-Salida bien especificado. Las técnicas de Caja Negra permiten revelar defectos y/o ambigüedades en los requerimientos y en las especificaciones del software. 3.1. Particiones de Equivalencia En esta técnica, el dominio de datos de entrada es particionado en una cantidad finita de clases de equivalencia (válidas e inválidas). Cualquier dato miembro de una clase de equivalencia será un elemento representativo de dicha clase y permitirá obtener información (revelar defectos) acerca del comportamiento del software con los datos de esa clase de equivalencia. Realizar pruebas para todas y cada una de estas clases de equivalencia permite superar la necesidad de probar exhaustivamente todos los posibles datos de entrada, lo cual generalmente es imposible. ¿Cómo se identifican las clases de equivalencia? El proceso de identificación de las clases de equivalencia es un proceso heurístico que se basa –usualmente- en la descripción de los datos de entrada que encontramos en las especificaciones del software. Glenford J. Myers menciona algunas pautas para identificar clases de equivalencia: 1. ‘‘Si una condición especifica un rango de valores, se identifican una clase de equivalencia válida y dos clases de equivalencia inválidas” Por ejemplo: CANTIDAD puede ser un valor entre 1 y 999. La clase de equivalencia válida será 1 ≤ CANTIDAD ≤ 999. Una clase inválida será CANTIDAD < 1, y otra clase inválida: CANTIDAD > 999. 2. ‘‘Si una condición especifica una cantidad de valores, se identifican una clase de equivalencia válida y dos inválidas”
Por ejemplo: se pueden listar de 1 a 6 propietarios de un bien. La clase de equivalencia válida será de 1 a 6 propietarios, mientras que las dos inválidas serán: sin propietario y más de 6 propietarios. 3. ‘‘Si una condición especifica un conjunto de valores válidos, se identifican una clase de equivalencia válida y una clase inválida” Por ejemplo: el tipo de vehículo puede ser BUS, MICROBUS, CAMIÓN, o AUTO. Se tendrán cuatro clases de equivalencia válidas (los cuatro valores válidos) y una inválida (cualquier valor no especificado, digamos “VOLQUETE”) 4. ‘‘Si una condición se especifica como debe ser, se identifican una clase de equivalencia válida y una inválida”. Por ejemplo: el primer carácter de un código debe ser una letra. La clase de equivalencia válida será: es una letra; y la clase inválida: no es una letra. 5. ‘‘Si tiene motivos para pensar que el software no manipula de manera similar a todos los elementos de una clase de equivalencia, entonces particiónela en clases de equivalencia más pequeñas’’ Luego de identificar las clases de equivalencia, se deberá proceder a escribir cada caso de prueba tratando que este cubra la mayor cantidad de clases de equivalencia válidas, hasta que todas hayan sido consideradas. Por el contrario, cada clase de equivalencia inválida deberá ser cubierta por un caso de prueba de manera individual, hasta que todas sean cubiertas. Consideremos el ejemplo del ingreso a una base de datos de un código de artículo con las características siguientes: Está compuesto por caracteres alfanuméricos El número de caracteres varía entre 4 y 8 El primer carácter debe ser una letra Las clases de equivalencia (CE) podrían ser: CE1 - El código ingresado es alfanumérico CE2 - El código ingresado NO es alfanumérico CE3 - El código ingresado tiene entre 4 y 8 caracteres CE4 - El código ingresado tienen menos de 4 caracteres CE5 - El código ingresado tiene más de 8 caracteres CE6 - El primer carácter es una letra CE7 - El primer carácter NO es una letra Los casos de prueba para cubrir las clases de equivalencia identificadas podrían ser: o
o
o
o
o
o
o
o
o
o
Dato de prueba
Clases de equivalencia válidas
Clases de equivalencia inválidas
ABC123
CE1, CE3, CE6
AB*123
CE2
A
CE4
ABCDEF123456
CE5
123ABC
CE7
3.2. Análisis de Valores Límites Esta técnica es un complemento de la anterior. Los valores límite son aquellos que se encuentran en los “bordes” de las clases de equivalencia. La experiencia muestra que muchos errores ocurren en el tratamiento a estos valores límite. Nuevamente Glenford J. Myers aporta algunos lineamientos para hacer este análisis: 1. ‘‘Si una condición especifica un rango de valores, desarrolle casos de prueba para los extremos del rango y para valores que estén inmediatamente debajo y encima de los extremos inferior y superior del rango” Para el antes mencionado ejemplo de la CANTIDAD -que puede ser un valor entre 1 y 999- deberían considerarse casos de prueba para los valores 1 y 999, así como para 0 y 1000. Si se tratara de una LONGITUD con un rango entre 5.0000 y 10.0000, tendríamos que considerar casos de prueba para los valores 5.0000, 10.0000, 4.9999 y 10.0001. 2. ‘‘Si se especifica un conjunto ordenado, tal como una lista o una tabla, se debe tener especial cuidado en el primer elemento del conjunto, y en el último” Si consideramos el ejemplo del ingreso de un código de artículo, encontramos valores límites en la longitud del código (de 4 a 8 caracteres). En base a ello podríamos añadir los casos de prueba siguientes: Dato de prueba
Valores límite
AB1
3
AB12
4
ABCD1234
8
ABCD12345
9
3.3. Gráficos causa-efecto Una debilidad de la técnica de las técnicas de particiones de equivalencia y análisis de valores límite es que no facilita la combinación de condiciones. Los
gráficos causa-efecto permiten combinar condiciones, lo cual también ayuda en el hallazgo de ambigüedades y/o inconsistencias en las especificaciones. Esta técnica es una adaptación de aquella utilizada para probar circuitos lógicos digitales. En esta técnica las especificaciones del software -dadas en un lenguaje natural- se modelan en un lenguaje formal: los gráficos causa-efecto. Para ello, a partir de cada especificación del software deben identificarse: las causas – condiciones de entrada o clases de equivalencia de entrada los efectos – condiciones de salida o transformaciones observables las restricciones – limitaciones externas del software Con estos elementos se construye un gráfico booleano: las causas y los efectos son los nodos del gráfico las causas se ubican a la izquierda del gráfico, y los efectos a la derecha las relaciones lógicas entre causas y efectos se grafican con vectores y utilizando los operadores lógicos AND, OR y NOT Los símbolos básicos para los gráficos causa efecto son los siguientes: o
o
o
o
o
o
Luego, el gráfico es vaciado a una tabla de decisión que servirá para desarrollar los casos de prueba necesarios. Cada causa y cada efecto tendrán una fila en la tabla. Cada columna de la tabla representará una combinación de causas y corresponderá a un caso de prueba. Tomemos como ejemplo la especificación de un módulo para buscar un carácter en una cadena: se debe ingresar la longitud de la cadena y el carácter a buscar. Si la longitud de la cadena es mayor a 80 debe mostrarse un mensaje de error. Si el carácter se encuentra en la cadena, debe mostrarse su posición, de lo contrario debe mostrarse el mensaje “No encontrado” .
Las causas o condiciones de entrada serían: C1: entero positivo entre 1 y 80 C2: carácter a buscar Los efectos o condiciones de salida serían: E1: Longitud fuera de rango E2: Posición del carácter E3: Carácter no encontrado El gráfico causa-efecto para esta especificación, y las proposiciones que representa sería las siguientes:
•
Si C1 y C2, entonces E2
•
Si C1 y no C2, entonces E3
•
Si no C1, entonces E1
El paso siguiente es vaciar el gráfico en la tabla de decisión siguiendo el procedimiento siguiente para cada efecto (“1” representa la presencia de la causa o efecto, “0” representa su ausencia, y “-“ indica que no se considera): Seleccione un efecto Retroceda a través del gráfico y encuentre todas las combinaciones de causas que hagan que el efecto ocurra Cree una columna en la tabla de decisión para cada combinación de causas Determine, para cada combinación, los estados de los demás efectos y colóquelos en la columna Para este sencillo ejemplo, la tabla de decisión sería la siguiente: o
o
o
o
Prueba 1
Prueba 2
Prueba 3
C1
1
1
0
C2
1
0
-
E1
0
0
1
E2
1
0
0
E3
0
1
0
3.4. Conjetura de errores Esta técnica consiste en que la(s) persona(s) que diseñan los casos de prueba enumere posibles errores, en base a su experiencia e –incluso- su intuición. Es un proceso ad-hoc, por lo que no hay un procedimiento establecido para hacer conjeturas. Sin embargo, si se tienen documentados los defectos de las versiones anteriores, o de programas similares, esta documentación será una fuente muy valiosa para enriquecer la conjetura de errores. Ejemplos típicos son los casos en que puede ocurrir una división entre cero, la manipulación de arreglos y de punteros más allá de sus límites, o las condiciones del entorno del software. 4. TECNICAS DE CAJA TRANSPARENTE Al contrario del enfoque de Caja Negra, en este caso las técnicas se basan en el conocimiento de la estructura interna del software. El objetivo es asegurar que los componentes del programa están trabajando adecuadamente, por lo que se debe conocer el código o el seudo código del software para forzar la ejecución de alternativas específicas del software (bifurcaciones, por ejemplo), Éstas técnicas son útiles para revelar defectos de lógica, control de condiciones, secuenciación e inicializaciones. 4.1. Cobertura lógica Al analizar la estructura lógica interna –aún de programas relativamente sencillos- nos damos cuenta que el número de las posibles secuencias lógicas de ejecución es muy grande, lo cual hace –nuevamente- materialmente imposible realizar pruebas exhaustivas que cubran todas las posibilidades. Por ello, se requiere un criterio para determinar cuántos casos de prueba serán necesarios para considerar que el software ha sido suficientemente probado. Este criterio se le conoce como criterio de cobertura. El criterio de cobertura más simple e intuitivo podría ser: diseñar los casos de prueba necesarios para que se ejecute por lo menos una vez cada sentencia del programa . Pero para un programa como el del código mostrado, este criterio es muy débil. Basaría con hacer a = 2, b = 0 y x = 3 para cumplir con este criterio. Sin embargo, podrían pasarse por alto defectos en el sentido de los operadores lógicos al codificar x < 1 en vez de x > 1, por ejemplo. public void foo (int a, int b, int x) { if (a > 1 && b == 0) { x = x / a; } if (a == 2 || x > 1) { x = x + 1; } }
Un criterio de cobertura bastante completo es el denominado Cobertura de Condición Múltiple que señala que deben diseñarse los casos de prueba necesarios para que se invoquen por lo menos una vez cada una de las
combinaciones posibles de los resultados de condición en cada decisión .
Y si se trata de programas con múltiples puntos de entrada, habría que agregar y que se invoquen por lo menos una vez cada uno de los puntos de entrada . Por ejemplo, para probar el programa anterior de manera adecuada se deberían considerar ocho combinaciones: 1. a > 1, b = 0
5. a = 2, x > 1
2. a > 1, b ≠ 0
6. a = 2, x ≤ 1
3. a ≤ 1, b = 0
7. a ≠ 2, x > 1
4. a ≤ 1, b ≠ 0
8. a ≠ 2, x ≤ 1
En este ejemplo, las ocho combinaciones podrían ser cubiertas con cuatro casos de prueba: 1. a = 2, b = 0, x = 4 2. a = 2, b = 1, x= 1 3. a = 1, b = 0, x = 2 4. a = 1, b = 1, x = 1 4.2. Flujo de datos Esta técnica se basa en el rol de las variables dentro del programa y es útil para detectar defectos debido a la definición, inicialización y/o uso de las mismas. Por su naturaleza, la eficacia de esta técnica decae conforme el tamaño del programa aumenta, por lo que se recomienda para programas pequeños y complejos. Las variables de un programa pueden jugar diferentes roles en determinadas sentencias: se les puede asignar un valor como en read x, o en x = y + 10; pueden usarse como un predicado como en if x > 100; o para hacer un cálculo como en y = 25 * x . A las sentencias de asignación se les denominará de definición ( def ), mientras que a las otras se les denominará de uso (uso ) Esta técnica trata de analizar el flujo de datos desde las sentencias de asignación hasta aquellas donde se usan las variables. Para ello se debe identificar y clasificar las ocurrencias de cada variable, ya que durante las pruebas se deben ejecutar todas las asignaciones y todos los usos. En el ejemplo siguiente se tienen cuatro variables cuenta, i, n y numero. cuenta = 0 1 read (n) 2 i=1 3 while (i <= n) 4 read (numero) 5 cuenta = cuenta + 1 6
i=i+1 7 end while 8 print (cuenta) 9 El siguiente paso es tabular las ocurrencias de definición y uso de cada variable. En las tablas siguientes se especifica la línea de código en la que aparece la variable y un número secuencial para cada flujo. Las variables podrían ser definidas y usadas en la misma sentencia.
cuenta i n numero def uso def uso def uso def uso 1 1 6 5 3 4 9 2 4 10 5 6 2 1 9 6 3 7 3 6 5 7 7 7 4 6 9 8 7 4 Luego deben generarse los datos de prueba para ejecutar todos los flujos tabulados. Para este ejemplo bastarían dos casos de prueba: Datos de prueba Flujos n=0 2, 5, 9 n = 3; numero =1,2,3 1, 3, 4, 5, 6, 7, 8, 9, 10 4.3. Prueba de lazos (loops) Los lazos o “loops” son estructuras de programación a las que frecuentemente están asociados diversos defectos del software, por lo que merecen una especial atención. Para un lazo simple que puede variar de cero a n iteraciones, se deben considerar casos de prueba para: Cero iteraciones (el lazo no se ejecuta) Una iteración Dos iteraciones k iteraciones (k < n) n – 1 iteraciones n + 1 iteraciones (si es posible) Valor negativo para la variable de control del lazo Si el mínimo de iteraciones fuera mayor a cero, pruebe con un número de iteraciones menor al mínimo. Para los lazos anidados los casos de prueba pueden crecer exponencialmente. Para limitar este número de casos considere lo siguiente: Empiece con el nivel más interno, poniendo los niveles externos en sus valores mínimos. Pruebe el mínimo, el mínimo + 1, un número típico, el máximo – 1 y el máximo número de iteraciones para el nivel más interno. o
o
o
o
o
o
o
o
o
o
o
5. o
o
o
6. •
• •
•
•
•
Suba un nivel, establezca un número típico de iteraciones para el nivel interno, repita el paso anterior para el presente nivel, manteniendo los niveles externos en sus valores mínimos. Continúe con este proceso hasta probar todos los niveles del lazo anidado. CONCLUSIONES La prueba de software tiene el objetivo de encontrar defectos, por lo que deben ser realizadas por una persona, o un equipo de personas, independiente del desarrollador del software. Realizar todas las pruebas posibles generalmente es imposible, por limitaciones de tiempo y de recursos materiales. La prueba de software consistirá en diseñar y ejecutar un número limitado de casos de prueba que permita encontrar el máximo número de defectos. La prueba de software usualmente requiere utilizar una combinación de técnicas de caja negra y de caja transparente para lograr un conjunto de casos de prueba consistente, combinación que dependerá de las características del software y de las limitaciones del entorno REFERENCIAS BIBLIOGRÁFICAS Beizer, Boris; Software Testing Techniques - Second Edition; The Coriolis Group; 1990 Black, Rex; Pragmatic Software Testing; John Wiley & Sons; 2007 Burnstein, Ilene; Practical software testing; Springer-Verlag New York Inc.; 2003 Harinath P. V. y otros; Software Testing Guide Book; Software Testing Research Lab; 2004 Myers, Glenford J.; The Art of Software Testing-Second Edition; John Wiley & Sons, Inc.; 2004 Rojas, Johanna y Barrios, Emilio; Investigación sorbe el estado del arte en diseño y aplicación de pruebas de software; Universidad Francisco José de Caldas - Bogotá; 2007
