Pruebas Proyecto de Soluci贸n de Problemas con Programaci贸n 1
Pruebas y depuración • La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. • La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.
Depuración • Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. • En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.
Depuración • Es la detección, corrección y eliminación de errores de software. • El tener un plan de pruebas ayuda a clarificar el proceso de depuración. • El plan de pruebas debe de estar mucho antes de la construcción del software.
Depuración • Existen muchos tipos de pruebas dependiendo de la labor y características de cada una de ellas. • Pruebas Alfa: se realizan por el usuario final en un ambiente controlado. • Pruebas Beta: se realizan por el usuario sin controlar el ambiente.
Depuración • A continuación se mencionan algunas características deseables que deben contener los planes de prueba: • Diseñar un caso de prueba funcionalidad del software.
para
cada
• Establecer como mínimo un caso de prueba de datos correcto.
Depuración • Establecer como mínimo un caso de prueba de datos incorrecto. • Ejemplo: Caso de Prueba de un módulo de raíz cuadrada. • Qué el usuario ingrese un número mayor que 0.
Depuración • Qué el usuario ingrese un número 0 • Qué el usuario ingrese un número menor que 0. • Toda actividad de construcción (codificación) es susceptible de cometer errores dado que se trata de una actividad humana.
Depuración • Al realizar la depuración de un programa existe la posibilidad de un 50% de cometer otro error. • Es recomendable realizar pruebas de trazado (assert) para visualizar en donde ocurren los errores.
Depuración • Se recomienda probar lo antes posible cualquier fragmento de código. • Las pruebas ayudan al aseguramiento de calidad pero no garantizan que un software esté 100% libre de errores.
Depuración • Las pruebas de caja blanca también llamadas transparentes se concentran en lo que es el código fuente. • No se pueden tener pruebas que abarquen el 100% de los casos de uso. Se deben realizar pruebas de segmentos
Depuración • Las pruebas de segmentos son bloques de instrucciones. • Las pruebas de caja negra están orientadas a lo que se espera realicen los componentes modulares del sistema.
Depuración • Son pruebas funcionales y no interesa como se realizan las cosas sólo que el resultado obtenido sea el correcto. • Se recomienda que sean los usuarios quienes las realicen. • Existen diversas filosofías de pruebas como la programación defensiva.
Depuración • La programación defensiva es una técnica de probar primero. Es considerada una técnica de codificación. Se basa en el principio de divide y vencerás. • Se codifica el esqueleto de la aplicación. • Se realizan pruebas.
Depuración • Se corrigen los errores y se vuelven a hacer pruebas. • Las pruebas de estrés se encargan de observar el rendimiento de la aplicación sobre cargas demandantes de trabajo: grandes volúmenes de datos con poco espacio en disco, 90% de uso de CPU, múltiples conexiones, etc.
Depuración • Existen otros tipos de prueba como: • Pruebas de unidad: se encargan de un módulo de software en particular. • Pruebas de Integración: son pruebas que se realizan con dos o más módulos trabajando en conjunto.
Depuración • Existen otro tipos de prueba como las de aceptación que están más involucradas en el concepto en sí que en el desarrollo. • También se pueden aplicar pruebas aleatorias. Lo ideal es poder utilizar un framework de pruebas.
Depuración • La mayoría de los IDEs modernos presentan frameworks para la depuración desde el clásico step by step o step over sobre cada uno de los módulos hasta la realización de pruebas de unidad. • Entre las más famosas destacan JUnit para realizar pruebas de unidad en Java.
Guía para la Prueba de Programas • Se necesita especificar resultados esperados.
las
salidas
o
• Un programador debe de evitar probar sus propios programas. • Una organización no debe de probar sus propios programas.
19
Guía para la Prueba de Programas • Inspeccionar los resultados obtenidos de cada prueba. • Los casos de prueba deben escribirse con condiciones de entrada que son inválidas e inesperadas, así como también aquellas que son válidas y esperadas. 20
Guía para la Prueba de Programas • Examinar un programa para verificar que hace lo que deba de hacer es sólo parte de la prueba, la otra mitad es asegurarse que el programa no haga lo que no deba de hacer. • No realizar planeaciones asumiendo que no se encontrarán errores. 21
Guía para la Prueba de Programas • La probabilidad de la existencia de mas errores en una sección de un programa es proporcional al número de errores encontrados en esa sección. • La realización de pruebas es una actividad extremadamente creativa e intelectualmente retadora. 22
Guía para la Prueba de Programas • Se debe de realizar una lista de verificación para inspecciones de prueba que contenga los siguientes puntos: • • • •
Datos Declaración de datos Errores computacionales Errores de comparación
23
Guía para la Prueba de Programas • Errores de control de flujo • Errores de Interface • Errores de Entrada/Salida • Se pueden utilizar métodos deductivos e inductivos para la prueba de software. 24
Depuración por Inducción • Se siguen los siguientes pasos: • • • • • •
Localizar los datos pertinentes Organizar los datos Estudiar las relaciones Divisar las hipótesis Probar las hipótesis Corregir el error
25
Depuración por Deducción • • • • •
Enumerar las posibles causas Usar procedimientos de eliminación Refinar las hipótesis restantes Probar las hipótesis restantes Si no se pueden probar las hipótesis entonces coleccionar más datos y repetir el proceso • En caso contrario corregir el error
26
XP eXtreme Programming • Se tienen doce principios básicos: • • • • • •
Planeación y requerimientos Entregas pequeñas e incrementales Metáforas de Sistemas Diseños simples Pruebas continuas Refactorización
27
XP eXtreme Programming • • • • • •
Programación en pares Propiedad colectiva del código Integración Continua Semanas de 40 horas Clientes como miembros del equipo Codificar con estándares 28
Extreme Testing • Las programación extrema tienen las siguientes ventajas en lo que respecta al proceso de pruebas: • Se gana confianza ya que el código debe cumplir las especificaciones. • Se tiene el resultado final del código antes de codificar
29
Extreme Testing • Se entiende mucho mejor las especificaciones y requerimientos de la aplicación. • Se inicia con diseños simples y se refactoriza el código después para mejorar el desempeño sin preocuparse de que se estén rompiendo las especificaciones. 30
Plan de Pruebas • Se recomienda utilizar la metodología y formatos del estándar IEEE 829 para documentación de pruebas de software: • Pasos que incluye: • Identificador de plan de pruebas (se muestra el estándar a seguir para el nombre de las pruebas)
31
Plan de Pruebas • Introducción (en que consiste las pruebas del sistema) • Elementos a probar • Características a ser probadas • Características que no se probarán • Enfoque • Criterio de fallo o aceptación de los elementos
32
Plan de Pruebas • Criterio de Suspensión y Reanudación de requerimientos • Entregables de las pruebas • Tareas de las pruebas • Necesidades del entorno • Responsabilidades • Equipo y necesidades de capacitación • Agenda
33
Plan de Pruebas • Riesgos y contingencias • Acuerdos • A las pruebas se les ha empezado a llamar de manera formal verificación y validación. • Existen metodologías más robustas como el TMMI (Test Maturity Model)
34
35
Plan de pruebas
36
Ejemplo
Referencias • Myers, et al. (2004), “The Art of Software Testing”, Wiley, Estados Unidos, 2004, ISBN: 0-471-46912-2
37
多Preguntas, dudas y comentarios?
38