Verificacin y Validacin del Software Objetivos Comprender diferencia entre verificacin y validacin del software.

Conocer las tcnicas de pruebas para descubrir fallos en el cdigo. DEFINICION: Conjunto de procesos de comprobacin y anlisis que aseguran que el software est acorde a su especificacin y las necesidades de los clientes. VERIFICACIN Se comprueba que el software cumple los requisitos funcionales y no funcionales VALIDACIN Comprueba q el software cumple las expectativas q el cliente espera. Hacerlo de forma inicial TCNICAS DE VERIFICACIN Y VALIDACIN Inspecciones del Software: Se analizan las diferentes representaciones del sistema (diagramas de requerimientos, de diseo y cdigo) bsqueda de defectos. Son tcnicas de validacin estticas se realizan en todo el ciclo d desarrollo Pruebas del Software Tcnicas de validacin dinmicas Requiere disponer de prototipo ejecutables tcnica + predominante.

Inspecciones del Software: revisiones sistemticas d documentos y cdigos con el objetivo de detectar fallos. Permiten detectar entre 60 y 90% de los fallos a unos costes mucho ms bajos que las pruebas Permiten detectar mltiples defectos en una simple inspeccin, las pruebas solo detectan un fallo x prueba. Inspecciones detectan fallos de mdulos, pruebas fallos a nivel de sistema

compilador, incluyen analizadores lxicos y sintcticos y conjunto de reglas Aspectos habitualmente analizados son: -Anlisis de flujo de control -Anlisis de utilizacin de datos -Anlisis de interfaces -Anlisis de la trayectoria Ejemplos: PMD, CPD: buscar duplicidades en el cdigo, Checkstyle, Findbugs, RIPS: Es un escner de seguridad para encontrar vulnerabilidades en aplicaciones PHP DISEO POR CONTRATOS: Es un mecanismo para especificar requerimientos y garantas que no se pueden representar solamente con metadatos Contratos se expresan en forma de pre-condiciones, poscondiciones e invariantes asociados a los objetos Anlisis esttico del cdigo Chequeo de inconsistencias en tiempo de ejecucin. Documentacin del cdigo. pre-condicin clusula lgica q debe estar libre de efectos colaterales, y q debe cumplirse como requisito pos-condicin es una clusula lgica que debe cumplirse luego de la ejecucin del mtodo Un invariante clusula que establece las condiciones bajo las cuales el estado de un objeto es "correcto" Code Contracts ofrece cuatro recursos fundamentales: -- La clase esttica Contract --Nuevos atributos que permiten colocar meta-informacin en el cdigo --Herramientas que trabajan sobre el cdigo -----Ensamblados de referencia con informacin de contratos Los mtodos formales surgieron como puntos de vista analticos con los que es posible verificar el desarrollo de sistemas mediante la lgica y las matemticas, lo que aporta grandes ventajas para mejorar la calidad de los programas.propsitos son: sistematizar e introducir rigor en todas las fases de desarrollo de software

LISTA DE FALLOS
Fallos de datos: Las variables se inicializan antes q d q utilicen los valores? las constantes tienen nombre? Fallos de control: Para cada instruccin condicional Es correcta la condicin? Todos los ciclos terminan? Existe cdigo no alcanzable? Fallos de entrada/salida: Se utilizan todas las variables de entrada? Provocan corrupcin de los datos las entradas no esperadas? Fallos de la interfaz: Las llamadas a funciones y mtodos tienen el nmero correcto de parmetros? Existen funciones o procedimientos no invocados? Fallos de gestin de almacenamiento: Si una estructura con punteros se modifica, Se reasignan correctamente todos los punteros? Si se utiliza almacenamiento dinmico, se asigna correctamente el espacio? Fallos de gestin de las excepciones: Se toman en cuenta todas las condiciones de errores posibles ?. Anlisis Esttico Automtico: de programas son herramientas de software que rastrean el texto fuente de un programa, en busca de errores no detectados por el

Proceso de Depuracin localiza y corrige los errores descubiertos durante la verificacin y validacin. Proceso complicado no siempre los errores se detectan en el punto en que se generan Despus de reparar el error, hay que volver a probar el sistema (pruebas de regresin).

Mtodos formales se refiere entonces al uso de tcnicas de la lgica y de la matemtica discreta para especificar, disear, verificar, desarrollar y validar programas. Pruebas de Software Metas del proceso de Prueba: Demostrar al desarrollador y al cliente que el Sw cumple con los requisitos esta meta conduce a la validacin, mediante casos de prueba Encontrar situaciones en donde el comportamiento del Sw sea incorrecta esta meta se orienta a pruebas de defectos para presentar los defectos Las pruebas pueden mostrar solo la presencia de errores, mas no su ausencia El objetivo de las pruebas es la deteccin de defectos en el software (descubrir un error es el xito de una prueba) Software Comercial Debe pasar por tres etapas de pruebas Pruebas de desarrollo Versiones de prueba Pruebas de usuario PRUEBAS DE DESARROLLO Las pruebas realizan en tres niveles. Pruebas de unidad. Se pone a prueba unidades de programa o clases de objetos individuales. o Probar todas las operaciones asociadas al objeto. o Establecer y verificar el valor de todos los atributos relacionados con el objeto. o Poner el objeto en todos los estados posibles o se debe automatizar las pruebas de unidad ejemp JUNIT partes d una prueba Automatiza: Parte de configuracin -- entradas y salidas esperadas Parte Call Se llama al objeto o al mtodo. Parte de Declaracin -- Se compara Se escriben dos tipos de casos de prueba El primero debe reflejar una operacin normal la otra prueba tiene que basarse en probar la experiencia

Pruebas del componente, muchas unidades individuales

se integran, prueba las interfaces del componente tipos: Interfaz de Parmetro Interfaces de memoria compartida Interfaces de procedimiento Interfaces que pasan mensajes Errores de interfaz: Son una de las formas mas comunes de falla en los sistemas complejos: Uso incorrecto de la interfaz Mala interpretacin de la Interfaz Errores de temporizacin PRUEBAS DEL SISTEMA, todos los componentes se integran y se prueba como un todo, prueba las interacciones entre los componentes. Diferencias con las pruebas de componentes. Durante las pruebas de sistema, los component reutilizables desarrollados por separado y los sistemas comerciales pueden integrarse, se prueba el sistema completo. Las pruebas de sistema es un proceso colectivo mas que individual. Desarrollo dirigido por pruebas: TDD es el enfoque al diseo de programas donde se entrelazan el desarrollo de pruebas y el de cdigo. Se introdujo como parte de los mtodos agiles como XP Proceso del TDD Se comienza por identificar el incremento de funcionalidad requerido. Se escribe una prueba para esta funcionalidad y se implementa como una prueba automatizada. Se corre la prueba, junto con todas las otras pruebas que se implementaron inicialmente -- Falla

Se implementa la funcionalidad y se opera nuevamente la prueba. Una vez puestas en funcionamiento con xito todas las pruebas, se avanza a la implementacin de la siguiente funcionalidad. Beneficios Cobertura de Cdigo. Prueba de regresin. Al volver a correr todo el programa. Depuracin simplificada. Documentacin del Sistema PRUEBAS DE VERSIN. Proceso de poner a prueba una versin particular de un sistema que se pretende usar fuera del equipo de desarrollo.

Pruebas de escenario Enfoque donde se crean escenarios tpicos de uso Un escenario es una historia Los escenarios deben ser realistas Se ponen a prueba varios requerimientos tambin demuestra que las combinaciones no causan problemas

4. 5. 6.

Correr pruebas de aceptacin. Negociar los resultados de las pruebas. Rechazo o aceptacin del sistema.

Caja Negra: Se realiza con el fin de asegurar que el producto es operativo. Mtodos de prueba basados en grafos Particin equivalente Anlisis de valores lmites Prueba de comparacin Caja Blanca: Se desarrolla con el fin de asegurar que todas las piezas del sistema tienen una operacin interna que se ajusta a las especificaciones y que todos sus componentes internos se han aprobado en forma adecuada. Prueba de camino bsico Notacin de grafo de flujo Complejidad ciclomtica Obtencin de casos de prueba Matrices de grafos Prueba de la estructura de control Prueba de condicin Prueba de flujo de datos Prueba de bucles Resumen La pruebas solo pueden mostrar la presencia de errores en un programa. Sin embargo no pueden garantizar que no surjan fallas posteriores. Las pruebas de desarrollo son responsabilidad del equipo de desarrollo. Pruebas de desarrollo incluyen Pruebas de Unidad, de Componentes y de Sistema. Siempre que sea posible se debe escribir pruebas automatizadas. Las pruebas de escenario son tiles porque imitan el uso practico del sistema.

Diferencias entre pruebas de versin y de sistemas. Un equipo independiente que no intervino en el desarrollo, debe realizar las pruebas de versin. Las pruebas del sistema por parte del equipo de desarrollo, deben enfocarse en el descubrimiento de bugs

Principal Meta de pruebas de versin: Convencer al proveedor del sistema de que este es suficientemente apto para su uso, si es as puede liberarse como un producto o entregarse al cliente. ETAPAS Pruebas basadas en requerimientos Principio general de buena practica Deben escribirse de forma que pueda disearse Se consideran pruebas de validacin mas que de defecto.

C. PRUEBAS DE RENDIMIENTO Una vez integrado completamente el sistema, es posible probar propiedades emergentes como el rendimiento y la confiabilidad. Se disean para garantizar que el sistema procese su carga pretendida. Implica efectuar una serie de pruebas donde se aumente la carga hasta que el rendimiento se vuelva inaceptable. Funciones Prueba el comportamiento de falla del sistema . Fuerza al sistema y puede hacer que salga a la luz defectos que no se descubran normalmente PRUEBAS DE USUARIO Son una etapa en el proceso de pruebas Las pruebas de usuario son necesarias esenciales aun cuando se hayan realizado otros tipos de pruebas Tipos Pruebas Alfa. Los usuarios del Sw trabajan con el equipo Pruebas Beta. Donde una versin del Sw se pone a disposicin de los usuarios Pruebas de aceptacin. Clientes prueban un sistema para decidir si esta o no listo para ser aceptado son bastante usados en XP Etapas en pruebas de aceptacin 1. Definir los criterios de aceptacin. 2. Plan de pruebas de aceptacin (Recursos). 3. Derivar pruebas de aceptacin.

Las pruebas de aceptacin son un proceso de prueba de usuario, donde la meta es decidir si el Sw es suficientemente adecuado para desplegarse y utilizarse