Generación de Casos de PruebaSurgen varias preguntas:g p g

¿qué valores son adecuados? ¿cuántos casos serán suficientes?

Conviene precisar lo que se entenderá por caso de prueba:Un caso de prueba es una especificación precisa de una ejecución de una pieza de software, constituida por: unconjunto de valores de entrada, un conjunto de resultados esperados y opcionalmente, un conjunto de condicionesen que se ejecuta la prueba y un conjunto de condiciones esperadas al terminar dicha prueba.

Los valores de entrada deben ser valores específicos para variables específicas o acciones concretas que originaneventos reconocibles por el software. Ejemplo del primero puede ser nombre: “González”. Un ejemplo de acciónsería “oprimir el botón Cancelar”.

Los resultados esperados pueden ser valores específicos de variables, mensajes o cambios en la apariencia delsoftware. Ejemplos del primero sería pago = 1200.00. Ejemplo del segundo: “Operación no permitida”. Del tercero:aparece una ventana para capturar datos de un alumno nuevo.

Los casos de prueba conviene representarlos en un formato como el de la siguiente, que contiene los elementosantes descritos.

Las condiciones deben expresarse como proposiciones lógicas que pueden ser falsas o verdaderas. Una condiciónde entrada puede ser: La base de datos está vacía. Una condición de salida puede ser: Se suspendió la ejecucióndel programa. Las condiciones de entrada deben ser verdaderas para que se realice el caso de prueba. Lasp g p q pcondiciones de salida falsas indican que el caso de prueba falló.

La efectividad de una prueba depende de la selección de los datos de prueba

¿Qué datos de pruebas debemos usarpara probar efectivamente una unidad?

– Existe una variedad amplia de técnicas para diseñar los casos de prueba de unidades 

Para preparar los casos de pruebas hacen falta un número de datos que ayuden a laejecución de estos casos y que permitan que el sistema se ejecute en todas susvariantes, pueden ser datos válidos o inválidos para el programa según si lo que sedesea es hallar un error o probar una funcionalidad. Los datos se escogen atendiendoa las especificaciones del problema, sin importar los detalles internos del programa, afin de verificar que el programa corra bien.

Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es una delas más efectivas pues permite examinar los valores válidos e inválidos de lasentradas existentes en el software

Regularmente, una condición de entrada es: un valor numérico específico, un rango de valores, un conjunto devalores relacionados o una condición lógica.‐gParticiones equivalentes

Una clase de equivalencia representa un conjunto de estados válidos y no válidos para una condición de entrada dada 

Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices:q p gSi un parámetro de entrada debe estar comprendido en un cierto rango de valores, aparecen 3 clases de

equivalencia: por debajo, en y por encima del rango.Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del

rango.gSi una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto

o fuera de él.Si una entrada es booleana (lógica), hay 2 clases: si o no.

– Una condición de entrada es una restricción de un parámetro o variable de entrada establecida como un requisito o regla de negocio.

• Para cada condición de entrada (asociada a un argumento o variable) se definen dos tipos de clases de equivalencia: 

Clases VálidasClases Válidas: conjuntos de valores de entrada válidas • Ej. 0 ≤ costo ≤ 9999999

Clases Inválidas ó No ValidasClases Inválidas ó No Validas: conjuntos de valores de entrada inválidos • Ej. costo < 0 y costo > 9999999Ej. costo < 0 y costo   9999999

– Ejemplo de una condición (regla de negocio):

• El costo de un producto está en el rango [ 9999999]

variable de entrada restricción

CRITERIOS DE ESPECIFICACIÓN DE CLASES DE EQUIVALENCIAS

Sitio Web

Login

5

Ejemplos prueba validación con MEDESIPU

Ejemplo Prueba ValidaciónProyecto Fecha No Control WEB de la Especialidad de Informática del IUTM-UPM. 18/05/10 01 Caso de Uso a Probar Registrarse como Alumno en el SITIO (RFA001)  Actores A través de este caso de uso, el sistema le permite al alumno registrarse como usuario con rol de Alumno en el Sitio Web

ALUMNOS

Tipo de Prueba CAJA NEGRA Objetivo de la Prueba

Comprobar las excepciones para NO REGISTRAR UN ALUMNO Condiciones de la Prueba

El estudiante debe haber solicitado vía presencial o por correo electrónico al WEB MASTER su clave de registro. Debe estar registrado p p g gla clave de registro del alumno Refe Actividad /Operación Resultado Esperado Resultado Obtenido Evaluación

(A)probado/(R)eprobado) 01P01 Colocar en BLANCO los campos obligatorio

una a la vez Mensaje de excepcion de campo obigatorio en

Para el campo de correo electronico en blanco, coloca

(R)eprobado

blanco el mensaje de excepción para el apellido en blanco

01P02 Colocar un correo electrónico inexistente Mensaje de excepcion de correo electrónico inexistente

El esperado (A)probado

01P03 Colocar un usuario existente en la BD Mensaje de excepcion de usuario existente

Registra a un usuario existente en la BD

R)eprobado

01P04 Colocar clave sumnistrada errada Mensaje de clave suministrada errada

El esperado (A)probado

01P05 Campos Nombres y Apellidos con números Mensaje de excepción de Registra el alumno con R)eprobado Nombres y Apellidos con números

números en los nombres y apellidos

Representa del Equipo de desarrollo Representante de los Usuarios (Stakeholder) Apellidos y Nombres:

Firma: Apellidos y Nombres:

Firma:

 

Considerando la pregunta ¿cuántos casos serán suficientes?, puede analizarse un caso extremo: generar todas lascombinaciones posibles de valores que pueda procesar el programa. Si esto fuera posible, se tendría la seguridadde que no hay una combinación que lo haga fallar Desgraciadamente no es factible ya que el número de casosde que no hay una combinación que lo haga fallar. Desgraciadamente no es factible, ya que el número de casoscrece de manera exponencial respecto al número de variables, debido a que deben considerarse las combinacionesde valores de cada una con las demás. Así pues, habrá que conformarse con un conjunto finito de casos que dencierta tranquilidad.

Para ilustrar el crecimiento del número de casos, suponga que sólo usamos variables booleanas:• Para una sola, hay dos combinaciones: cierto y falso;• Para dos variables, se tienen cuatro casos o 22: cierto con cierto, cierto con falso, falso con cierto y falso confalso;falso;• Para n variables tendremos 2n

Dado que no es factible la prueba exhaustiva, debe buscarse la manera de generar un número suficiente de casosde prueba que ofrezcan cierta seguridad en sus resultados Para ello deben aplicarse ordenadamente y serde prueba que ofrezcan cierta seguridad en sus resultados. Para ello deben aplicarse ordenadamente y serrepetibles en diversas circunstancias. En consecuencia, se requiere de un modelo de prueba.

El papel de cualquier modelo es ofrecer una visión simplificada de una fracción de la realidad, de tal manera quepueda razonarse acerca de ella buscar solución a problemas y ensayar soluciones En el caso de la prueba depueda razonarse acerca de ella, buscar solución a problemas y ensayar soluciones. En el caso de la prueba desoftware, el modelo destaca algunos aspectos del software que guían la selección de los casos de prueba,indicando la manera de construirlos y a veces ofreciendo un número mínimo de casos suficientes.