Proyecto de Solución de Problemas con Programación Pruebas Proyecto de Solución de Problemas con Programación

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 para cada funcionalidad del software. 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 las salidas o resultados esperados. Un programador debe de evitar probar sus propios programas. Una organización no debe de probar sus propios programas.

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.

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.

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.

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

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.

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

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

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

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

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

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.

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)

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

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

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) Jfcunit Httpunit Jwebunit Dbunit Opensta

Plan de pruebas

Ejemplo

Referencias Myers, et al. (2004), “The Art of Software Testing”, Wiley, Estados Unidos, 2004, ISBN: 0-471-46912-2

¿Preguntas, dudas y comentarios?