Instituto Tecnológico Superior De Acatlán de Osorio Carrera: Ingeniería Informática Materia: Verificación y Validación de Software Portafolio de evidencias Elaborado por: Solano Agustín Carlos Profesor: L.C.C. Miguel Fuentes Cortez. Acatlán de Osorio Puebla, Junio de 2014
Temario general dela materia Num. Nombre de la unidad Subtemas 1 2 3 Introducción al proceso de verificación y validación. Pruebas. Verificación 1.1 Contextualización de la verificación y validación. 1.2 Terminología del proceso. 1.3 El proceso de la verificación y validación. 1.4 Tipos generales de los errores. 1.5 Responsabilidad de pruebas. 1.6 Organigrama de proceso de testing (un modelo propuesto). 1.7 Costos del error. 2.1 Tipos de pruebas. 2.2 Cobertura de las pruebas. 2.3 Preparación de la prueba. 2.4 Productos de la prueba. 2.5 Criterios para la realización de pruebas. 2.6 Plan Pruebas (validación y verificación). 2.7 Estructura de los casos de Prueba. 2.8 Conceptos Generales los diseño de las pruebas (validación y verificación). 2.9 Reporte y Seguimiento de errores. 2.10 Informe de la Prueba. 2.11 Fuentes de información de QA para el control estadística o métricas. 2.12 Control estadístico vs métricas. 2.13 Importancia de la calidad, las métricas y el control estadístico. 3.1 Marco de Referencia para el desarrollo de software. 3.2 Herramientas para apoyar al proceso y la ejecución de las revisiones de software. 3.3 Manejo de Requerimientos (Verificación). 3.4 Verificación en este proceso. 3.5 Entradas propuestas para el proceso de verificación de requerimientos. 3.6 Método de verificación. 3.7 Aspectos a verificar en esta etapa. 3.8 Entendimiento de problema
4 5 6 Modelado Implementación Validación y logística de pruebas (Verificación). 3.9 Revisión general de requerimientos. 3.10 Fase de manejo de requerimientos. 4.1 Modelado de pruebas con UML. 4.2 Cumplimiento de la especificación en los requerimientos. 4.3 Importancia en la efectividad en el diseño. 4.4 Patrones (tipos de patrones, como utilizar los 5.1 Implementación. 5.2 Entradas para pruebas. 5.3 Plan de pruebas (estrategia de prueba, ambientes, test team, atacar y asegurar regresión). 5.4 Ejecución de tipos generales de pruebas. 5.5 Caja negra y caja blanca. 5.6 Otros tipos de test. 5.7 GUI, Funcionalidad, Performance, entre otros. 5.7.1 Documentación (técnica y de usuario). 5.7.2 Seguridad. 5.7.3 Diseño de las pruebas. 6.1 Pruebas y aceptación del cliente 6.2 Entrega de proceso de pruebas. 6.3 Formalización y cierre del proyecto. 6.4 Monitoreo y seguimiento del proyecto. 6.5 Formalización de cambios. 6.6 Administración de defectos.
Unidad I Introducción al proceso de validación y verificación 1.1 Contextualización de la verificación y validación Verificación y validación del software, es el proceso de control que asegura que un determinado software cumple con su especificación y satisface las necesidades del usuario. Verificación: Se ocupa de controlar si el producto satisface los requerimientos del usuario; Se está construyendo el producto correctamente? Su propósito es asegurar que el producto seleccionado cumple con los requerimientos especificados. Construir el sistema correctamente Descubrir y corregir errores en el sistema Criterios a verificar Verifica que la información sea coherente Identifica desviaciones con estándares y requerimientos Recolecta datos para mejorar el proceso Verifica que el producto cumpla o Con los requerimientos o Con los atributos de calidad o Que se ajuste a las regulaciones, estándares y procedimientos definidos. Validación: Su propósito es demostrar que el producto satisfacerá su uso esperado cuando sea puesto en funcionamiento. Controla que el producto cumpla su especificación inicial. Se está construyendo el producto correcto? Construir el sistema correcto Evaluar la conformidad con la especificación de requisistos Casos de test
Pruebas unitarias Estos procesos se realizan a través de revisiones hechas ya sea por los mismos desarrolladores o verificadores (especialistas en verificación) dependiendo de los tipos de prueba a realizar. Estas revisiones se clasifican en tres: 1. Informales: No hay procedimientos definidos, por lo que la revisión se realiza de la forma más flexible, las Ventajas que presenta son menor coste y esfuerzo, preparación corta, entre otras, y sus desventaja es que detectan menos defectos. 2. Semi-formales: Se definen unos procedimientos mínimos a seguir. 3. Formales: Se define completamente el proceso, la revisión se hace en detalle en detalle, por una persona o grupo distintos del autor, para verificar si el producto se ajusta a sus especificaciones o atributos de calidad y a los estándares utilizados en la empresa.
1.2 Terminología del proceso 1.3 El proceso de la verificación y validación La verificación y validación deberían conceder la confianza en que el software alcanza su objetivo, esto no significa que esté libre de defectos, más bien debería ser lo suficientemente bueno para su uso, y el tipo de uso determinará el grado de confianza que es necesaria, en otras palabras una adecuada verificación y validación, determinara la calidad del software. La aplicación de la verificación y validación depende de la organización de las actividades relacionadas al proceso de pruebas de software, para esto Burnstein propone la siguiente organización: Planeación: Fija las metas y una estrategia general de pruebas. Preparación: Se describe el procedimiento general de prebasy se generan los casos de prueba específicos. Ejecución: Incluye la observación y la medición del comportamiento del producto Análisis: Incluye verificación y análisis de resultado para determinar si se observaron fallas Seguimiento: Si se detectaron fallas, se inicia un monitoreo para asegurar que se remueva el origen de estas.
1.4 Tipos generales de errores Sintácticos: Los errores de sintaxis, o sintácticos, ocurren cuando el programador escribe código que no va de acuerdo a las reglas de escritura del lenguaje de programación. Lógicos: Los errores lógicos ocurren a causa de un mal diseño del programa. Puede ocurrir que una línea de código observe todas las reglas sintácticas del lenguaje, pero el código tenga una lógica equivocada. C= a+b y c= a*b De ejecución: Se produce cuando el ordenador no puede ejecutar alguna instrucción de forma correcta. C=5/0; sintácticamente es correcto pero al momento de realizar la operación el ordenador internamente no podrá hacer la operación. 1.5 Responsabilidad de pruebas La responsabilidad de pruebas busca la reducción de defectos, fallas, errores y anomalías que puedan existir en el desarrollo de un sistema informático. Fagan (1976) menciona que las inspecciones (Revisión por pares de cualquier producto de trabajo por personas capacitadas que buscan defectos mediante un proceso bien definido.) son un método formal, eficiente y económico para encontrar errores en el diseño y el código. Fagan propone un conjunto de roles y un proceso a seguir durante las inspecciones. 1. Moderador: Persona clave en un inspección exitosa, debe ser un programador competente, pero no necesita ser un técnico experto en el programa inspeccionado. Calendariza reuniones, reporta resultados y da seguimiento al retrabajo. 2. Diseñador: Responsable de producir el diseño del programa 3. Implementador/Codificador: Responsable de transformar el diseño en código. 4. Encargado de las pruebas: Responsable de escribir y/o ejecutar los casos de prueba o alguna otra forma de probar los productos del diseñador y el codificador. Para esto es importante contar con un plan de pruebas que es un documento que describe el enfoque que será utilizado para las actividades de prueba, e
incluye: los elementos a ser probados, los tipos de pruebas que se realizaran, el calendario de las pruebas, los recursos humanos, procedimientos de reportes y criterios de evaluación. 1.6 Organigrama de proceso de testing (un modelo propuesto)
1.7 Costos del error Origen Costos de Errores Pre sen tes en: Porque surgen El 72 % de estos se originan en el traslado de los requerimientos Fases del ciclo de desarrollo Perdidas de capital Perdidas de vidas Incumplimiento de requerimientos Desconocimiento de los requerimientos Bajo flujo de información Escasa documentación