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
Descargar

Differential Calculus