6.4 ESTRATEGIAS DE PRUEBA



Documentos relacionados
PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

1. Descripción y objetivos

Plan de estudios ISTQB: Nivel Fundamentos

Ingeniería de Software. Pruebas

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

Contenido. Profesor: Ing. MSc. Eliomar Nieves

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Empresa Financiera Herramientas de SW Servicios

2 EL DOCUMENTO DE ESPECIFICACIONES

AI 2 ADQUISICIÓN Y MANTENIMIENTO DE SOFTWARE DE APLICACIÓN AFINES OBJETIVOS OBJETIVOS DE CONTROL

GESTION OPERATIVA. Niveles de gestión

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Ciclo de vida y Requerimientos de software. Laboratorio de Programación

Diseño orientado al flujo de datos

Introducción a las Pruebas de Software

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

5. Gestión de la Configuración del Software (GCS)

LEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA

Gestión y Desarrollo de Requisitos en Proyectos Software

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

LISTA DE MEJORAS PARA MEJORAR LOS RESULTADOS DE LA EVALUACIÓN

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

IAP TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

6 Anexos: 6.1 Definición de Rup:

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Gestión de Configuración del Software

Análisis y Diseño de Aplicaciones

6.3 CASOS DE PRUEBA CAJA BLANCA

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

Criterios de clasificación

Los profesores Flipantes

Planificación, Gestión y Desarrollo de Proyectos

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA

Plan de Gestión de Configuración. Universidad Nacional de la Patagonia Austral

CICLO DE VIDA DEL SOFTWARE

Arquitectura de Aplicaciones

Aplicaciones de Ingeniería de Software

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS

SISTEMAS Y MANUALES DE LA CALIDAD

Implantación y Aceptación del Sistema

Plan de Gestión de la Calidad

E Documento de entrega de Aplicación

Conceptos Generales. Introducción a la ingeniería de Software. Tomado de: Escuela de Sistemas Universidad Nacional de Colombia Sede Medellín

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Metodología básica de gestión de proyectos. Octubre de 2003

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Workflows? Sí, cuántos quiere?

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

PRU. Fundamento Institucional. Objetivos. Alcance

SISTEMAS DE INFORMACIÓN I TEORÍA

Aseguramiento de la Calidad

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Introducción a la Firma Electrónica en MIDAS

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Calidad de Sistemas de Información

Desarrollar el concepto del producto. Asignar requisitos de hardware y software N

Procedimiento de gestión de auditorias internas de calidad

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN

Planeación del Proyecto de Software:

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

Ciclo De Vida Software

Resumen de los cambios de la versión 2.0 a la 3.0 de las PA-DSS (normas de seguridad de datos para las aplicaciones de pago)

Elementos requeridos para crearlos (ejemplo: el compilador)

INSTITUCIÓN EDUCATIVA LA ESPERANZA AUDITORIAS INTERNAS. CÓDIGO: A1-IN01 VERSIÓN: 1 PÁGINA 1 de 6

Universidad Politécnica de Tulancingo Código del documento PR-SGI-003

SIIGO PYME PLUS. Proceso de Recuperación. Cartilla I

Implementando un ERP La Gestión del Cambio

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

Política de Gestión Integral de Riesgos Compañía Sud Americana de Vapores S.A.


AUDITORIAS INTERNAS DE CALIDAD. Definir las actividades pertinentes para realizar las auditorías internas del Sistema de Gestión de calidad.

Procedimiento para Auditorías Internas

SISTEMAS DE INFORMACIÓN III TEORÍA

Testing. Tipos, Planificación y Ejecución de Pruebas

Directrices para la auto- evaluación A.l Introducción

DE VIDA PARA EL DESARROLLO DE SISTEMAS

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN

Capítulo VII PLAN DE IMPLEMENTACIÓN DE ALTO NIVEL

GATEWAYS COMO FIREWALLS

SISTEMA DE GESTIÓN DE LA CALIDAD

ADMINISTRACIÓN DE PROYECTOS

UNIVERSIDAD DE ORIENTE FACULTAD DE CIENCIAS ECONOMICAS

PROCEDIMIENTO DE AUDITORÍAS INTERNAS DEL SISTEMA DE GESTIÓN DE CALIDAD

PROCEDIMIENTO ESPECÍFICO. Código G Edición 0

Figure 16-1: Phase H: Architecture Change Management

Ciclo de vida del software

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)

DESCRIPCIÓN ESPECÍFICA NÚCLEO: COMERCIO Y SERVICIOS SUBSECTOR: INFORMÁTICA

Orientaciones de la Convención n de Ramsar para el Monitoreo Integrado de Humedales. Hernán n Torres

CRM Gestión de Oportunidades Documento de Construcción Bizagi Process Modeler

Transcripción:

Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema

Las pruebas del software aplican similar estrategia moviéndonos de adentro hacia afuera de la espiral. la prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. La prueba avanza para llegar a la prueba de integración, donde el foco de atención es el diseño y construcción de la arquitectura del software. Otra vuelta hacia afuera encontramos la prueba de validación, donde se validan los requisitos establecidos como parte del análisis de requisitos del software, comparándolos con el sistema que ha sido construido. Finalmente, llegamos a la prueba del sistema en la que se prueban como un todo el software y otros elementos del sistema.

PRUEBA DE UNIDAD La prueba de unidad centra el proceso de verificación en la menor unidad del diseño: el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes, con el fin de descubrir errores dentro del módulo. Se prueba la interfase para asegurar que la información fluye de forma adecuada hacia y desde la unidad del programa que está siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante la ejecución del algoritmo.

PRUEBA DE UNIDAD Se prueban las condiciones límite para asegurar que el módulo funciona correctamente con los límites establecidos. Se ejercitan todos los caminos independientes de la estructura de control para asegurar que todas las sentencias del módulo se ejecuten por lo menos una vez. Y finalmente se prueban todos los caminos de manejo de errores.

PRUEBA DE INTEGRACION Si todos los módulos funcionan bien por qué dudar de que funcionen bien juntos?. El problema es "ponerlos juntos". La prueba de integración detecta errores de interacción. El procedimiento adecuado se llama integración incremental con el cual se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y corregir.

PRUEBA DE INTEGRACION Un plan general de integración y una descripción de las pruebas específicas deben quedar documentados en una especificación de prueba, es parte esencial del proceso de ingeniería de software y forma parte de la configuración del software.

Un perfil de la especificación de prueba puede ser el siguiente: I. Alcance de la prueba. II. Plan de prueba. A. Fases de prueba. B. Agenda. C. Software adicional. D. Entorno y recursos. III. Procedimiento de prueba N. A. Orden de integración. 1. Propósito. 2. Módulos a ser probados. B. Pruebas de unidad para los módulos de la subfase. 1. Descripción de pruebas para el módulo M. 2. Descripción del software adicional. 3. Resultados esperados. C. Entorno de prueba. 1. Herramientas o técnicas especiales. 2. Descripción del software adicional. D. Datos de los casos de prueba. E. Resultados esperados para la subfase N. IV. Resultados de prueba obtenidos. V. Referencias. VI. Apéndices.

El alcance de prueba resume las características funcionales, de rendimiento y diseño interno específicas a probar. Se limita el esfuerzo de prueba, se describen criterios de terminación de cada fase de prueba y se documentan las limitaciones del plan. El plan de prueba describe la estrategia general para la integración. Se divide en fases y subfases. En todas las fases se siguen los siguientes criterios: Integridad de interfase, validez funcional, contenido de la información y rendimiento.

La sección de procedimiento de prueba describe detalladamente el procedimiento de prueba requerido para llevar a cabo el plan de prueba, describiendo el orden de integración y las pruebas de cada fase. Asimismo se incluye un listado de todos los casos de prueba y resultados esperados. Se registran los resultados reales de prueba obtenidos, problemas y peculiaridades. Esta información es vital para el mantenimiento del software.

PRUEBA DE VALIDACION Una vez ensamblado como paquete probamos la validación, la cual se logra cuando el software funciona de acuerdo con las expectativas razonables del cliente. Estas expectativas están definidas en la especificación de requisitos que describe los atributos del software visibles al usuario, basado en los criterios de validación de dicho documento. La prueba de validación se lleva a cabo con pruebas de la caja negra que demuestran la conformidad con los requisitos.

PRUEBA DE VALIDACION Una vez probado cada caso pueden darse dos condiciones: las características de funcionamiento ó de rendimiento están de acuerdo con las especificaciones y son aceptables, ó se descubre una desviación de las especificaciones y se crea una lista de deficiencias.

PRUEBA DE VALIDACION Se pueden realizar pruebas alfa ó beta, la prueba alfa es conducida por un cliente en el lugar de desarrollo; la prueba beta en uno ó más lugares de clientes y usuarios finales. En la alfa el desarrollador observa, en la beta es una aplicación en vivo en un entorno que no controla el desarrollador. Como resultado el equipo de desarrollo de software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la base de clientes.

PRUEBA DE SISTEMA Constituida por una serie de pruebas diferentes cuyo propósito es ejercitar profundamente el sistema basado en computadora. Entre pruebas de sistema tenemos: Prueba de recuperación: forza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Se evalúa la corrección de reinicialización, mecanismos de recuperación del estado del sistema, recuperación de datos y rearranque. Prueba de seguridad: intenta verificar que los mecanismos de protección del sistema lo protegerán adecuadamente.

PRUEBA DE SISTEMA Prueba de resistencia: está diseñada para enfrentar a los programas con situaciones anormales, es decir, ejecuta un sistema de forma que demande recursos en cantidad, frecuencia ó volúmenes anormales. Una variación de esta prueba es la prueba de sensibilidad, utilizando datos que produzcan inestabilidad ó procesamiento incorrecto. Prueba de rendimiento: prueba el rendimiento del software en tiempo de ejecución. Se da en todos los pasos del proceso de prueba.

EJERCICIO: Prueba de unidad en el contexto orientado a objetos Prueba de clase Prueba de integracion en el contexto orientado a objetos Prueba basada en subprocesos Prueba basada en el uso Prueba de grupo