Tips para la creación de casos de pruebas

Un poco de teoría

Contenido de un caso de prueba  (¿Qué deberíamos colocar en ellos mínimamente?)

• Precondiciones: situación previa a la ejecución de una prueba o características de un objeto de prueba antes de llevar a la práctica (ejecución) un caso de prueba   
• Valores de entrada: descripción de los datos de entrada de un objeto de prueba 
• Resultados esperados: datos de salida que se espera que produzca un objeto de prueba para los datos de entrada y condiciones establecidas 
• Postcondiciones: características de un objeto de prueba tras la ejecución de una prueba, descripción de su situación tras la ejecución de las pruebas 
• Dependencias: relación entre los casos de prueba 
• Prioridad u orden de ejecución: orden en el que se ejecutarán los casos de prueba, normalmente dependiente de la criticidad del requisito o riesgo al que brinden cobertura 
• Identificador distinguible: Identificador o código con el objeto de vincular, por ejemplo, un informe de errores al caso de prueba en el cual ha sido detectado 
• Condiciones: características a evaluar del objeto de prueba 

Tipos de pruebas 

Caja negra

Se denomina así a las pruebas en donde el foco no se encuentra en la estructura del objeto de prueba, es decir no importa para este tipo de pruebas cómo fue construido, sólo se evalúa su funcionamiento conociendo cómo debe reaccionar (que salidas generar) en base a las entradas que se le provea.  También se denomina a este tipo de pruebas funcionales u orientadas a la especificación. Las pruebas funcionales están dirigidas a verificar la corrección y la completitud de una función  ¿Están disponibles en el módulo todas las funciones especificadas?  ¿Las funciones ejecutadas presentan resultados correctos? Las ejecuciones de casos de prueba deberían ser efectuadas con una baja redundancia, pero sin embargo con carácter integral/completo, la idea es probar lo menos posible, pero tanto como sea necesario con el fin de lograr una prueba eficiente desde el punto de vista de la economía de la prueba, es decir intentar hallar el punto más eficiente entre la calidad obtenida y el costo

Técnicas de casos de prueba de caja negra 

• Partición de equivalencia (segmentación de equivalencia) o clase de equivalencia. 
• Análisis de valores límite.
• Tablas de decisión. 
• Pruebas de transición de estado. 
• Pruebas de caso de uso 

Partición de equivalencia o clase de equivalencia (CE) 

• La partición en clases de equivalencia es lo que la mayoría de los probadores hacen de forma intuitiva: dividen los posibles valores en clases, mediante lo cual observan los rangos de valores de entrada de un programa (uso habitual del método CE) y su relación con las salidas generadas Los rangos de valores definidos se agrupan en clases de equivalencia para las cuales se aplican las siguientes reglas:  
• Todos los valores para los cuales se espera que el programa tenga un comportamiento común se agrupan en una clase de equivalencia (CE)  
• Las clases de equivalencia no pueden superponerse y no pueden presentar ningún salto (discontinuidad) 
• Las clases de equivalencia pueden consistir en un rango de valores (por ejemplo, 0<x<10) o en un valor aislado (por ejemplo, x = Verdadero) 
• Las clases de equivalencia deben contemplar valores válidos (clases de equivalencia válidas) e inválidos (clases de equivalencia no válidas) 
• Las clases de equivalencia válidas pueden mezclarse entre sí y/o con una y sólo una clase de equivalencia no válida. 
•  Las clases de equivalencia inválidas no pueden mezclarse entre sí, pero si pueden hacerlo con las clases de equivalencias válidas 

Clase de equivalencia válida: engloba todos los valores dentro del rango válido de definición.  

Clase de equivalencia no válida: aquí podemos hacer una distinción en cuanto a tipos de valores que se encuentren fuera del rango válido.  Por un lado, tendremos los valores con un formato correcto pero cuyo valor se encuentre por fuera del rango válido, ya sea por sobre o por debajo de este.  Por otro lado, encontramos los valores con formato incorrecto.  Generalmente estas clases de equivalencia suelen separarse. 

Ejemplo 

Las clases de equivalencia se escogen para entradas válidas y no válidas. Si el valor x se define como válido para valores 0 ≤ x ≤ 100, entonces, inicialmente, se pueden identificar tres clases de equivalencia:  

1. x < 0 (valores de entrada no válidos) 
2. 0 ≤ x ≤ 100 (valores de entrada válidos)  
3. x > 100 (valores de entrada no válidos) 

Se pueden definir clases de equivalencia adicionales, conteniendo, pero no limitándolas a entradas no numéricas, números muy grandes o muy pequeños formatos numéricos no admitidos, etc. 

Pasos para trabajar con clases de equivalencia 

• Identificar las variables de entrada del objeto de prueba, por ejemplo, campos a completar en una interfaz de usuario o parámetros que pueda recibir un proceso o servicio.
• Identificar cuales pueden utilizar rangos de valores 
• Identificar los límites superior e inferior de los rangos válidos 
• Identificar valores no válidos (no pertenecientes al rango)
• Agregar, si corresponde una clase de equivalencia con aquellos valores que deben ser tratados de forma particular ya que se conoce han provocado fallos en el pasado o resultan sospechosos. 

Ejemplo 2 

Un programa espera un valor porcentual de acuerdo a los siguientes requisitos:  

• Sólo se admiten valores enteros 
• 0 pertenece al rango y es su límite inferior
• 100 pertenece al rango y es su límite superior 
• Son válidos todos los números del 0 al 100
• No válidos todos los números negativos 
• No son válidos los números mayores que 100 
• No son válidos los números decimales 
• No son válidos valores no numéricos 

Clases de equivalencia generadas:  (CE = Clase de equivalencia válida; CENV = Clase de equivalencia NO válida)

• CEV 01 valores entre 0 y 100 
• CENV 01 valores negativos 
• CENV 02 valores mayores a 100
• CENV 03 valores decimales
• CENV 04 Valores no numéricos 

El porcentaje será presentado en un diagrama de barra y se aplicarán los siguientes requisitos adicionales dado que para cada intervalo el sistema reaccionará de forma diferente (ambos valores se encuentran incluidos dentro de la clase de equivalencia

0 a 15

16 a 50

51 a 85

86 a 100

Ahora nos encontramos con que la clase de equivalencia CEV 01 puede ser dividida en cuatro:

CEV 01 valores entre 0 y 15 

CEV 02 valores entre 16 y 50  

CEV 03 valores entre 51 y 85 

CEV 04 valores entre 86 y 100 

Por lo tanto, nuestro esquema completo de clases de equivalencias pasará a ser el siguiente: 

• CEV 01 valores entre 0 y 15
• CEV 02 valores entre 16 y 50
• CEV 03 valores entre 51 y 85
• CEV 04 valores entre 86 y 100
• CENV 01 valores negativos
• CENV 02 valores mayores a 100
• CENV 03 valores decimales
• CENV 04 Valores no numéricos

El siguiente paso consta de elegir a la hora de ejecutar los casos un representante para cada una de estas clases de equivalencia, por ejemplo:

CEV 01	CEV 02	CEV 03	CEV 04	Negativos	Mayores a 100	Decimales	No numéricos
10	20	80	90	-5	120	2,5	árbol

*nota: estas clases de equivalencia podrían ampliarse si conocemos valores problemáticos para el sistema o si sospechamos de alguna combinación de valores o valores que podrían generar inconvenientes.

Particularidades de esta técnica 

• La calidad de la prueba depende de precisión de la segmentación de variables/elementos en clases de equivalencia  
• Las clases de equivalencia que no hubieran sido identificadas presentan el riesgo de posibles omisiones dado que los representantes utilizados no cubren todas las posibilidades 
• El método de la clase de equivalencia aporta casos de prueba para los cuales aún debe ser seleccionado  un representante por clase de equivalencia. 
• Las combinaciones de datos de prueba son seleccionados definiendo el o los representantes de cada clase de equivalencia 
• Todo valor perteneciente a una clase de equivalencia puede ser un representante de la misma. Los óptimos son:  valores característicos (utilizados con frecuencia dentro de la lógica real del negocio).  Valores problemáticos (sospechosos de producir fallos, por ejemplos valores muy grandes que puedan sobrecargar la variable que lo reciba).  Valores límite (en la frontera de la clase de equivalencia)  
• Los representantes de clases de equivalencias válidas se pueden combinar  
• Los representantes de clases de equivalencias  no válidas no se pueden combinar 
• Representantes de una clase de equivalencia  no válida sólo se puede combinar con otros representantes de clases de equivalencias  válidas 
• Para casos de prueba los representantes de clases de equivalencias  inválidos deben combinarse siempre con los mismos valores de otras clases de equivalencias  válidos (combinaciones estándar)
• La cobertura de clases de equivalencia puede ser utilizada como criterio de salida para finalizar las actividades del proceso de prueba 
• La transición de una especificación o definición funcional en clases de equivalencia con frecuencia, es una tarea difícil debido a la carencia de documentación precisa y completa  
• Los límites no definidos o las descripciones faltantes hacen difícil la definición de las clases de equivalencia  
•  Con frecuencia, es necesario mantener contacto con el cliente con el objeto de completar la información 
• Método sistemático para el diseño de casos de prueba que apunta a conseguir un alto valor de cobertura con una mínima cantidad de casos de prueba. 
• La partición del rango de valores en clases de equivalencia a partir de las especificaciones cubre los requisitos funcionales  
• La asignación de prioridades a las clases de equivalencia puede ser utilizada para la asignación de prioridades a los casos de prueba (los valores de entrada utilizados con poca frecuencia deben ser los últimos en ser probados) 
• Las pruebas de las excepciones conocidas están cubiertas por los casos de prueba que utilizan representantes de las clases de equivalencia no válidas 
• La partición de equivalencia es aplicable a todos los niveles de prueba • Puede ser utilizada para lograr objetivos de cobertura de entrada y salida  
• Puede ser utilizada para entradas manuales (humanas) o vía interfaces de un sistema o parámetros de interfaces en pruebas de integración

Técnica de valores límites 

• El análisis de valores limite amplía la técnica de partición en clases de equivalencia introduciendo una regla para seleccionar representantes  
• Los valores frontera (valores límite) de la clase de equivalencia deben ser probados de forma intensiva  ¿Por qué prestar más atención a los límites? Porque frecuentemente los límites del rango de valores no están bien definidos o conducen a distintas interpretaciones.  Por ejemplo, cuando se define que un valor es válido entre 0 y 100 no se está especificando de forma clara si 0 y 100 forman parte del rango válido como límites inferior y superior o si los valores válidos serían en realidad los mayores o iguales a 1 y los menores o iguales a 99.  Por lo tanto, al comprobar si los límites se verifican si estos han sido implementados (programados) correctamente  
• La experiencia demuestra que, con mucha frecuencia, los errores tienen lugar en los límites del rango de valores 
• El análisis de los valores límite puede ser aplicado en todos los niveles de prueba 
• Es una técnica fácil de aplicar y su capacidad de detección de defectos es alta en el caso de especificaciones detalladas  
• El análisis de valores límite asume que: 
• La clase de equivalencia está compuesta de un rango continuo de valores (no por un valor individual o un conjunto de valores discretos) 
• Se pueden definir los límites para el rango de valores  
• Como extensión a la partición en clases de equivalencia el análisis de valores límite es un método que sugiere la selección de representantes 
• La partición en clases de equivalencia: evalúa un valor (típico) de la clase de equivalencia mientras que el análisis de valores límite: evalúa los valores límite (frontera) y su entorno 
• Se utiliza el siguiente esquema:  valor mínimo  ≤ x ≤ valor máximo 

• Límite Inferior - δ  
• Límite Inferior + δ  
• Límite Superior - δ  
• Límite Superior + δ 
• Donde δ es el menor incremento definido para el valor. 

• Por ejemplo: 1 para valores enteros o 0,0001 si estuviésemos trabajando con 4 decimales 
• El esquema básico sólo puede ser aplicado cuando el rango de valores ha sido definido de conformidad con el mismo esquema  
• En este caso no son necesarias pruebas adicionales para un valor en el interior del rango de valores  
• Si una clase de equivalencia está definida como un único valor numérico, por ejemplo, x = 5, los valores correspondientes al entorno también serán utilizados, siendo los representantes (de la clase y su entorno) 4,5 y 6 
• Los valores límite para clases de equivalencia no validas tienen poco sentido ya que ya se encuentran cubiertos a través del esquema básico 
•  Para rangos de valores definidos como un conjunto de valores, en general, no es posible definir los valores límite, por ejemplo: Soltero, casado, divorciado, viudo 
• Esquema básico: seleccionar tres valores con el objeto de ser probados: el valor límite exacto y dos valores pertenecientes al entorno (dentro y fuera de la clase de equivalencia  
• Punto de vista alternativo: dado que el valor límite pertenece a la clase de equivalencia, sólo son necesarios dos valores para las pruebas, uno perteneciente a la clase de equivalencia y otro no perteneciente a la clase de equivalencia 
• Un error de programación causado por un operador de comparación erróneo será detectado con los dos valores límite (frontera) 

Pruebas de tabla de decisión  

La partición en clases de equivalencia y el análisis de valores límite tratan entradas en condiciones aisladas, sin embargo, una condición de entrada puede tener efectos sólo en combinación con otras condiciones de entrada - Todos los métodos descritos previamente no tienen en cuenta el efecto de dependencias y combinaciones.  El uso del conjunto completo de las combinaciones de todas las clases de equivalencia de entrada conduce, normalmente, a un número muy alto de casos de prueba (explosión de casos de prueba), con la ayuda de las tablas de decisión obtenidas a partir del análisis de las combinaciones de valores de entrada (causa efecto), la cantidad de combinaciones posibles se puede reducir de forma sistemática a un subconjunto de las mismas.  

Uso práctico 

• La especificación está dividida en partes fáciles de gestionar, por lo tanto, conduce a una tabla de decisión con un tamaño práctico 
• Es difícil deducir valores límite a partir de la tabla de decisión 
• Es recomendable combinar casos de prueba obtenidos a partir de tablas de decisión con valores obtenidos a partir de un análisis de valores límite 
• El número de causas y efectos analizados determinarán la complejidad del de la tabla de decisión.  Para n precondiciones cuyos posibles valores puedan ser verdadero o falso, se pueden generar 2n casos de prueba,  Para sistemas de gran tamaño este método sólo es controlable con el apoyo de herramientas. 

Pruebas de tabla de decisión  

• Identificación sistemática de combinaciones de entradas (combinaciones de causas) que no podrían ser identificadas utilizando otros métodos  
• Los casos de prueba son fáciles de obtener a partir de la tabla de decisión  
• Facilidad para determinar una cobertura suficiente de casos de prueba, por ejemplo, por lo menos un caso de prueba por cada columna de la tabla de decisión.
• El número de casos de prueba se puede reducir por la fusión sistemática de columnas de la tabla de decisión  
• El establecimiento de un gran número de causas conduce a resultados complejos y extensos por lo tanto, se puede incurrir en muchos errores en la aplicación de este método.  Esto hace necesario el uso de una

Pruebas de transición de estado  

Muchos métodos sólo tienen en cuenta el comportamiento del sistema en términos de datos de entrada y datos de salida pero no se tiene en cuenta los diferentes estados que pueda tomar el objeto de prueba.  Por ejemplo, el resultado de acciones que hubieran ocurrido en el pasado podrían haber causado que el objeto de prueba adquiera un determinado estado interno.  Los distintos estados que puede tomar un objeto de prueba se modelan a través de diagramas de transición de estado y el análisis de estas transiciones de estado se utiliza para definir casos de prueba basados en ellas.  Con frecuencia, las pruebas de transición de estado se utilizan en la industria del software embebido y automatización técnica en general 

Para determinar los casos de prueba utilizando un diagrama de transición de estado se construye un árbol de transición.  El estado inicial es la raíz del árbol y para cada estado que pueda ser alcanzado desde el estado inicial se crea un nodo que está conectado a la raíz por una rama, esta operación se repite y finaliza cuando: el estado del nodo es un estado final (una hoja del árbol) o el mismo nodo con el mismo estado ya es parte del árbol.  Cada camino, desde la raíz hasta una hoja, representa un caso de prueba de prueba de transición de estado El árbol de transición de estado debe ser extendido utilizando transiciones inválidas (casos de prueba negativos, pruebas de robustez) -Ejemplo: dos transiciones inválidas posibles.  Las transiciones imposibles entre estados no se pueden probar

Pruebas de transición de estado criterios de salida de prueba  

• Todo estado ha sido alcanzado, por lo menos, una vez  
• Toda transición ha sido ejecutada, por lo menos, una vez  
• Beneficios y desventajas de este método  
• Buen método de prueba para objetos de prueba que pueden ser descritos como máquinas de estado 
• Buen método de prueba para probar clases, sólo si el ciclo de vida del objeto está disponible  
• Con mucha frecuencia, los estados son más bien complejos, es decir, hacen falta una gran cantidad de parámetros para describir el estado, en esos casos el diseño de casos de prueba y el análisis de los resultados puede ser difícil y requerir mucho tiempo  
• Sólo cubriendo todos los estados no se garantiza una cobertura completa de prueba 

Pruebas basadas en casos de uso  

Los casos de prueba se obtienen directamente a partir de los casos de uso del objeto de prueba, el objeto de prueba es visto como un sistema reaccionando con actores.  Por lo tanto un caso de uso describe la interacción de todos los actores involucrados conduciendo a un resultado final por parte del sistema.  Todo caso de uso tiene precondiciones que deben ser cumplidas con el objeto de ejecutar el caso de uso (caso de prueba) de forma satisfactoria, además todo caso de uso tiene postcondiciones que describen el sistema tras la ejecución del caso de uso (caso de prueba)  Los casos de uso son elementos del Lenguaje Unificado de Modelado (UML), sin embargo el diagrama de casos de uso es uno de los 13 diferentes tipos de diagramas utilizado por UML.  Un diagrama de casos de uso describe un comportamiento, nos describe una secuencia de eventos y demuestra  la reacción del sistema desde el punto de vista del usuario 

• Cada caso de uso describe una cierta tarea (interacción usuario-sistema) 
• La descripción de un caso de uso incluye, pero no está limitado a: Precondiciones  
• Resultados esperados/comportamiento del sistema  
• Postcondiciones  
• Estos elementos descriptivos también son utilizados para definir los casos de prueba correspondientes  
• Cada caso de uso puede es utilizado como la fuente para un caso de prueba   
• Cada alternativa en el diagrama corresponde a un caso de prueba separado  
• Normalmente la información aportada por un caso de uso no tiene suficiente detalle para definir casos de prueba de forma directa.  Son necesarios datos adicionales (datos de entrada, resultados esperados) para construir/desarrollar un caso de prueba.

Beneficios  

Pruebas apropiadas para pruebas de aceptación y pruebas de sistema, dado que cada caso de uso describe un escenario de usuario a probar  Útil para diseñar pruebas de aceptación con la participación del cliente/usuario  Pruebas apropiadas si las especificaciones del sistema se encuentran disponibles en UML  Puede ser combinada con otras técnicas de prueba basadas en la especificación

Desventajas  

Nula obtención de casos de prueba adicionales más allá de la información aportada por el caso de uso  Por lo tanto, este método debería ser utilizado sólo en combinación con otros métodos de diseño sistemático de casos de prueba.  

Conclusiones generales de las técnicas  

El objetivo principal de las pruebas de caja negra es probar la funcionalidad del sistema  El resultado de las pruebas dependen de la calidad de la especificación del sistema (por ejemplo, la completitud, especificaciones faltantes o erróneas conducen a malos casos de prueba) Si las especificaciones son erróneas, también serán erróneos los casos de prueba. Las pruebas se ejecutan/desarrollan solamente para las funciones descritas. Una especificación faltante de una funcionalidad requerida no será detectada durante las pruebas  Si el objeto de prueba posee funciones que no han sido especificadas, éstas no serán evaluadas  Tales funciones superfluas pueden causar problemas en las áreas de la estabilidad y seguridad  Las pruebas funcionales constituyen la actividad de pruebas más importante Los métodos de caja negra son utilizados siempre en el proceso de prueba  Las desventajas pueden ser compensadas con el uso de métodos adicionales de diseño de casos de prueba, por ejemplo, pruebas de caja blanca o pruebas basadas en la experiencia. 

Pasos para la definición de casos de prueba 

1. Identificar indefiniciones, definiciones vagas, incompletas o inexistentes. 
2. Identificar valores de entrada a utilizar. 
3. Generar repositorios de valores de entrada para ser referenciados luego en los pasos de los casos de prueba.
4. Identificar datos de prueba (datos que necesito existan en el sistema para la ejecución de mis casos). 
5. Verificar la existencia de dichos datos o solicitar su creación de no existir. 
6. Generar repositorio de datos de prueba para ser referenciados luego en los casos de prueba. 
7. Identificar las condiciones que deseo probar. 
8. Establecer prioridades de ejecución para dichas condiciones. 
9. Identificar las necesidades o precondiciones para poder probar la condición deseada. 
10. Establecer el paso a paso para poder cumplir la prueba de dicha condición. 
11. Identificar y definir el conjunto de resultados esperados. 
12. Realizar la revisión entre pares para verificar posibles defectos.