I NGENIERÍA DE S OFTWARE L ABORATORIO XI Testin – Planificación Pruebas unitarias Eduardo Saavedra A. 11/11/2009

T ÓPICOS 1. Introducción 2. Ejemplo 3. Aplicación de prueba

I NTRODUCCIÓN

La fase de testing es una de las últimas fases de todo desarrollo de sistemas.

¿D ONDE ESTAMOS ? Código Unitarias Integración Sistemas Aceptación Construcción Pruebas

P ROPÓSITO DE LAS PRUEBAS UNITARIAS Concordancia entre los datos de entrada y las variables locales que las soportan. Concordancia entre las salidas esperadas y las salidas presentadas por el módulo en prueba. Sintaxis y semántica del código Estructuras bucles o iterativas; asignaciones, incrementadores, flags, condicionantes. Carga y recuperación de datos desde tablas. Formatos de campos en tablas relacionadas Lógica del algoritmo

M ETODOLOGÍAS PARA PRUEBAS Caja blanca Consiste en testear “insitu” las funciones y métodos. Caja negra Consiste en testear entradas y salidas esperadas.

¿C ÓMO DEBERÍAN SER ? Para que una prueba unitaria sea “buena” se deben cumplir los siguientes requisitos: Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua. Completas: deben cubrir la mayor cantidad de código. Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua. Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

F ICHA DE PLANIFICACIÓN DE PRUEBA Id Caso de prueba Identificador del caso de prueba. Dependerá del código previsto para el grupo de pruebas. Descripción de la prueba Se especifica el análisis de la acción o función que deberá verificar la prueba. Procedimiento Se especifica paso a paso el procedimiento que seguirá el testeador para ejecutar la prueba. Requisitos asociados Se indica el o los requisitos asociados al módulo o clase que se revisará. Entradas al sistema Aquí se especifica la entrada del caso de prueba al que se verá afecto el módulo o la clase. Salidas esperadas Aquí se especifica claramente cual es la salida esperada dependiendo del caso de prueba ingresado

E JEMPLO – FICHA DE PLANIFICACIÓN Id Caso de pruebaPu -3 Descripción de la pruebaSe analizara el perfecto agregado de datos de un producto, con los valores válidos esperados como entrada. ProcedimientoSe ingresan los valores a los campos en orden descendente. Requisitos asociadosr.1008 Entradas al sistemaPara campos numéricos : - valores con rango mínimo de valores con rango máximo de valores con rango intermedio entre y Para campos alfanuméricos : - valores vacíos - valores alfanuméricos ( caracteres, símbolos, números en cualquier combinación) Salidas esperadas - Registro creado exitosamente - No permitir registrar valores vacíos - No permitir registrar valores

E JEMPLO – R ESULTADO EJECUCIÓN Caso de prueba entradasalidaPrimera ronda Segunda ronda Rangos mínimos Aceptaok Rangos máximos Aceptaok Rangos intermedios Aceptaok (vacío)Vacíos No aceptaok abcdefghiAlfanuméricos No aceptaok

A CTIVIDADES Escoger 2 “layout” de mantenedores de sus requerimientos y obtener 7 pruebas. En su defecto escoger 7 funcionalidades que posean entradas o salidas en base a entradas. Escoger una funcionalidad de transacción Generar las fichas para planificación de pruebas unitarias de lo dicho anteriormente: 7| funcionalidades generales. 1 transacción. Entrega 18/11/2009