1 / 12

Ingeniería de Software Laboratorio XI

Ingeniería de Software Laboratorio XI. Testin – Planificación Pruebas unitarias Eduardo Saavedra A. 11/11/2009. Tópicos. Introducción Ejemplo Aplicación de prueba. Introducción. Introducción. La fase de testing es una de las últimas fases de todo desarrollo de sistemas.

mya
Download Presentation

Ingeniería de Software Laboratorio XI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ingeniería de SoftwareLaboratorio XI Testin – Planificación Pruebas unitarias Eduardo Saavedra A. 11/11/2009

  2. Tópicos • Introducción • Ejemplo • Aplicación de prueba

  3. Introducción

  4. Introducción • La fase de testing es una de las últimas fases de todo desarrollo de sistemas.

  5. ¿Donde estamos? Código Construcción Unitarias Integración Sistemas Aceptación Pruebas

  6. Propó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

  7. Metodologías para pruebas • Caja blanca • Consiste en testear “insitu” las funciones y métodos. • Caja negra • Consiste en testear entradas y salidas esperadas.

  8. ¿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.

  9. Ficha de planificación de prueba

  10. Ejemplo – ficha de planificación

  11. Ejemplo – Resultado ejecución

  12. Actividades • 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

More Related