Pruebas de Software, Diapositivas de Desarrollo de Software

¡Descarga Pruebas de Software y más Diapositivas en PDF de Desarrollo de Software solo en Docsity!

PRUEBAS DE

SOFTWARE

POR: DAVID RIQUELME REYNA

ÍNDICE

• (^) Introducción
• (^) Niveles de pruebas
• (^) Tipos de pruebas
• (^) Automatización de pruebas
• (^) Métodos de prueba
• (^) Conclusiones

VALIDACIÓN VS VERIFICACIÓN

VALIDACIÓN

• (^) Proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. VERIFICACIÓN - (^) Proceso de evaluar un sistema o componente para determinar si los productos de una determinada fase satisfacen las condiciones impuestas al comienzo de la fase.

¿POR QUÉ NECESITAMOS HACER PRUEBAS?

• (^) La capacidad humana de aprendizaje y memorización es limitada con

respecto a todo lo que queramos abarcar, lo que implica fallos y errores

inevitables si lo intentamos evitar con nuestras capacidades humanas.

• (^) Nos permite garantizar que las aplicaciones cumplen con la funcionalidad

esperada y la expectativa de calidad (no solo de código);.

• (^) Reduce el costo, uso de recursos y tiempo del desarrollo
• (^) Evita errores de reprogramación del software
  • JUSTIFICACIÓN
    • La realización de tareas de pruebas conlleva un costo asociado que puede inducir a tomar decisiones de no realizarlas. Así como no realizarlas también conlleva un costo asociado.
    • (^) Presumiendo el siguiente objetivo: Menores costos, menores tiempos de desarrollo y mayor satisfacción del cliente.

NIVELES DE PRUEBAS

TEST OBJETIVO PARTICIPANTE

S

AMBIENTE MÉTODO

UNITARIO Detectar errores en los datos, lógica, algoritmos Programadores Desarrollo Caja Blanca INTEGRACIÓN O COMPONENTES Detectar errores de interfaces y relaciones entre componentes Programadores Desarrollo Caja, Blanca, Top Down, Bottom Up SISTEMA Detectar fallas en el cubrimiento de los requerimientos Testers, Analistas Desarrollo Funcional FUNCIONAL O IMPLEMENTACIÓ N Detectar errores en la implementación de requerimientos Testers, Analistas Desarrollo Funcional ACEPTACIÓN Detectar fallas en la implementación del sistema Testers, Analistas, Cliente Productivo Funcional

NIVELES DE PRUEBAS

Pruebas unitárias Pruebas de integración Pruebas de sistema Pruebas de aceptación Componentes aislados Verifican Interacción entre componentes Verifican Requisitos del sistema Necesidades de los usuarios Verifican Verifican Pruebas de implantación Paso a producción Verifican

PRUEBAS DE INTEGRACIÓN O COMPONENTES

• (^) Cuando: Durante la construcción del sistema
• (^) Objetivo: Identifican problemas que ocurren cuando las unidades se combinan. Los nuevos errores que surgen probablemente estén relacionados con la interfaz entre las unidades en lugar de dentro de las propias unidades; simplificando la tarea de encontrar y corregir los defectos. - (^) HERRAMIENTAS - (^) Las mismas, sustituyendo los mocks por las clases reales y, si es necesario, escribiendo más casos de prueba.

PRUEBAS DE SISTEMA

• (^) Cuando: Durante la construcción del sistema (partes completas).
• (^) Objetivo: Prueban a fondo el sistema, comprobando su funcionalidad e integridad globalmente, en un entorno lo más parecido posible al entorno final de producción. - (^) HERRAMIENTAS - (^) Jmeter - (^) Avignon - (^) The grinch - (^) Marathon - (^) JWebTest - (^) Abbot - (^) Selenium - GUItar - (^) HttpUnit

PRUEBAS DE ACEPTACIÓN

• (^) Cuando: Después de la implantación en el entorno de producción.
• (^) Objetivo: Verifican que el sistema cumple con todos los requisitos indicados y permite que los usuarios del sistema den el visto bueno definitivo. - (^) HERRAMIENTAS - (^) Las mismas. Las pruebas se vuelven a ejecutar en el entorno real de producción y se añaden nuevas pruebas.

PRUEBAS DE REGRESIÓN

• (^) Cuando: Durante el mantenimiento del sistema.
• (^) Objetivo: C ada vez que se realizan cambios en un proyecto, es posible que el código existente ya no funcione correctamente o que se presenten errores no descubiertos previamente. Este tipo de error se llama regresión. Para detectar estos defectos, todo el proyecto debe someterse a una regresión: una nueva prueba completa de un programa modificado, en lugar de una prueba de solo las unidades modificadas, para garantizar que no se hayan introducido errores con las modificaciones. - (^) HERRAMIENTAS - (^) Las mismas. Las pruebas se vuelven a ejecutar en el entorno real de producción y se añaden nuevas pruebas.

AUTOMATIZAR PRUEBAS

• (^) Mayor rapidez de ejecución.
• (^) Menos recursos.
• (^) Evitamos pruebas obsoletas
• (^) Ciclo de prueba manual es muy largo
• (^) Proceso de prueba manual es propenso a errores
• (^) Liberar a la gente para realizar tareas creativas
• (^) Generar un ambiente de confianza soportado por los test
• (^) Obtener realimentación de forma temprana y con alta frecuencia
• Generar conocimiento del sistema en desarrollo a partir de los test
• Generar documentación del código consistente
• Generar una mejor utilización de los recursos a partir de menores costos

OBSTÁCULOS PARA AUTOMATIZAR LAS

PRUEBAS

• (^) Actitud de los programadores
• (^) La joroba de dolor
• (^) Inversión inicial
• (^) Código que siempre cambia
• (^) Sistemas legacy
• (^) Temor
• (^) Viejos hábitos
• (^) ¡Muy pocas herramientas!
• (^) Necesitan una “base” a menudo inexistente.
• (^) Un conjunto pobre de pruebas.

¿CUÁNDO AUTOMATIZAR Y CUÁNDO NO

AUTOMATIZAR?

¡CUÁNDO OPTIMIZAR!

• (^) No buscamos automatizarlo absolutamente todo.
• (^) Tenemos modelos y documentación del sistema.
• (^) Nosotros controlamos las herramientas de prueba. ¡CUÁNDO NO OPTIMIZAR! - (^) Gastamos más en la automatización que en la pruebas en sí. - (^) Construimos el sistema sobre la marcha. - (^) Las herramientas de prueba nos controlan a nosotros.

ESTRATEGIAS PARA COMENZAR LA

AUTOMATIZACIÓN

• (^) Capacitación a analistas, testers y programadores
• (^) Seleccionar una forma de trabajo
• (^) Seleccionar herramientas
• (^) Desarrollar proyectos pilotos
• (^) Institucionalizar