• La fase de pruebas es una de las más costosas del ciclo de vida software.

• Deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto software, lo que incluye las especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de elementos que forman parte de la aplicación

• Se aplican diferentes técnicas de prueba a cada tipo de producto software.

Introducción

Las pruebas de software (testing) son los procesos que permiten verificar y revelar la calidad de un producto software.

Son utilizadas para identificar posibles fallos de:• implementación• Calidad• Usabilidad

Pruebas de sistema

La forma de verificar de las diversas funcionalidades de un producto de software, descritas en el formato de Áncora o en Casos de Uso, son el punto de partida parala preparación de casos de prueba y, en ocasiones, de procedimientos de prueba.

Las funcionalidades o prestaciones de un sistema pueden separarse en dos grupos:

Casos de pruebas

CASOS DE PRUEBA: Condiciones dadas para un objetivo particular.

• Ocurre cuando las entradas deben completarse antes de que el sistema se lance a realizar una función, básicamente sin retroalimentación que pueda influir en el usuario.

• Es el caso de una sola variable, una sola acción a través de un botón o de un Enter, pero también incluye la lectura de listas de datos cuyo proceso se realiza cuando la lista ha terminado.

Casos de pruebas

a) aquellas que reciben un conjunto de entradas más o menos simultáneas y a partir de ellas generan un resultado

Casos de pruebas II

Un ejemplo:

En interfaces gráficas, donde resulta muy común que deban llenarse varios campos (por ejemplo nombre, dirección, teléfono y rfc) y al final se oprime un botón el cual indica al sistema que la entrada está completa y puede aplicar la función seleccionada.

Casos de pruebas III

b) las que requieren una serie de interacciones con el actor(usuario), en cada una de las cuales éste introduce una serie de datos.

• Ocurre cuando la entrada ocurre en varias etapas donde una de ellas genera una respuesta parcial del sistema, la cual influye en la siguiente, ya que el usuario no puede indicar las entradas sin tomar en cuanta la salida intermedia. Sin embargo la función completa requiere de terminar todas las etapas.

Casos de pruebas IV

Un ejemplo:• “El empleado selecciona la opción “Consultar” y el

sistema le muestra una lista de productos;

• El empleado marca los productos que le interesan y al terminar oprime el botón “Cotizar”;

• El sistema le muestra la lista de productos seleccionados y los precios de cada uno, así como la disponibilidad; también deja un espacio a la derecha de cada producto para anotar la cantidad deseada;

• El empleado marca la cantidad deseada de cada uno; los no deseados los marca con un cero. Al concluir oprime el botón “Listo”;

•

Un ejemplo (continuación):

• el sistema genera una orden y le solicita que indique la forma de pago;

• El empleado marca “Tarjeta” y escribe el número y la compañía y oprime “Termina”;

• el sistema verifica los datos con el banco y, si está de acuerdo, envía mensaje y un muestra un botón “Imprimir factura”;

• El empleado oprime el botón “Imprimir factura” y el sistema lo hace.”

Casos de pruebas V

Un ejemplo (continuación): En el ejemplo es claro que existen cinco etapas de entrada de datos para completar una sola función. Lo que el empleado puede ingresar en cada una depende de la anterior.

En las tres subsecciones siguientes se describen los aspectos generales de la preparación de casos de prueba y los detalles cuando ocurre cada uno de loscasos mencionados.

Casos de pruebas VI

Diseño de casos de pruebas

El diseño de casos de prueba se puede realizar basándose en los enfoques y en sus técnicas y las estrategias de prueba.

Objetivo: Conseguir confianza aceptable en que se encontraran todos defectos existentes, sin consumir una cantidad excesiva de recursos.

Diseño de casos de pruebas II

TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

• PROPÓSITOProducir el número de casos de prueba manteniendo la efectividad de la prueba.

• ENFOQUES PRINCIPALESCaja blanca (como lo hace)Caja negra (que es lo que hace)

Diseño de casos de pruebas III

PRUEBAS DE CAJA BLANCA

Consiste en realizar pruebas para verificar que líneas específicas del código funcionan tal como esta definido.También usa la estructura de control del diseño procedimental para obtener los casos de prueba .

Diseño de casos de pruebas III

PRUEBAS DE CAJA NEGRA

La prueba verifica que el ítem que se esta probando, cuando se dan las entradas apropiadas produce los resultados esperados.Los datos de prueba se escogerán atendiendo a las especificaciones al problema, sin importar los detalles internos del programa, al fin de verificar que el programa corra bien.

• Una buena prueba tiene un alta probabilidad de encontrar un error. El ingeniero de software debe tener un alto nivel de entendimiento del software a construir.

• Una buena prueba no debe ser redundante. Uno de los objetivos de las pruebas es «encontrar el mayor número de errores con la menor cantidad de tiempo y esfuerzo posibles».

• Una buena prueba debería ser la mejor de la cosecha. La limitación en tiempo y recursos puede impedir que se ejecuten todos los casos de prueba.

• Una buena prueba no debería ser ni demasiado sencilla ni demasiado compleja.

Kaner, Falk y Nguyen

Características que debe tener una “buena prueba”

• Identificador es único para futuras referencias.

• Caso de prueba dueño/creador es el nombre del analista o diseñador de pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.

• Versión la actual definición del caso de prueba.

• Nombre el caso de prueba debe ser un título entendible por personas, para la fácil comprensión del propósito del caso de prueba y su campo de aplicación.

• Identificador de requerimientos el cuál está incluido por el caso de prueba. También aquí puede ser identificador de casos de uso o especificación funcional.

• Propósito contiene una breve descripción del propósito de la prueba, y la funcionalidad que chequea.

• Dependencias

Estructura de los casos de pruebas I

Introducción/visión general contiene información general acerca de los Casos de Prueba.

Estructura de los casos de pruebas II

• Ambiente de prueba/configuración contiene información acerca de la configuración del hardware o software en el cuál se ejecutará el caso de prueba.

• Inicialización describe acciones, que deben ser ejecutadas antes de que los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún archivo.

• Finalización describe acciones, que deben ser ejecutadas después de realizado el caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el analista debe restaurarla antes de que otro caso de prueba sea ejecutado.

• Acciones pasos a realizar para completar la prueba.

• Descripción de los datos de entrada

Actividades: de casos de pruebas

• Resultados esperados contiene una descripción de lo que el analista debería ver tras haber completado todos los pasos de la prueba

• Resultados reales contienen una breve descripción de lo que el analista encuentra después de que los pasos de prueba se hayan completado. Esto se sustituye a menudo con un Correcto/Fallido. Si un caso de prueba falla, frecuentemente la referencia al defecto implicado se debe enumerar en esta columna.

Estructura de los casos de pruebas III

Resultados