Fundamentos de Ingeniería del Software
PRUEBAS Vicente García Díaz
[email protected]
Vicente García Díaz César Fernández Acebal Juan Manuel Cueva Lovelle Escuela de Ingeniería Informática Universidad de Oviedo
Algunos problemas famosos 2
F-16 (1986) Therac-25 (1985-1987) Misil Misil Patr Patriot iot (1991) (1991) Ariadne Ariadne 5 (1996) (1996) Mars Mars Clim Climat atee Orbi Orbite terr (199 (1999) 9) Multidata Multidata Software Software (2001) (2001)
Ubicación general 3
Son necesarias ¿Por qué hacer pruebas?
Desarrollos en cascada o iterativos…
Revisión
Análisis
Diseño
Codificación
Pruebas
Pruebas vs otras etapas de desarrollo Software más complejo y crítico Costes ocasionados por los fallos muy altos
Inicio operación
1/3
Conceptos básicos
defecto error fallo
4
Un del programador ocasiona un , el cual produce un Error es una acción humana equivocada Defecto es una definición incorrecta en un software u n sistema para realizar las Fallo es la incapacidad de un funciones especificadas en los requisitos No es lo mismo verificar verificar que que validar Verificar es determinar si se está construyendo un producto correctamente Validar es determinar si se está construyendo el producto correcto
2/3
Conceptos básicos 5
Prueba Es un proceso crítico en el que un software o uno de sus componentes se ejecuta en circunstancias previamente planificadas con el objetivo básico de encontrar errores Los resultados se observan, se guardan y se evalúan Ciclo de prueba Es una actividad compuesta: Formar una idea de los resultados aceptables para determinados valores de entrada Se ejecuta el software dándole los valores determinados en unas condiciones específicas Se observan los resultados Se comparan los resultados con la idea inicial
3/3
Conceptos básicos 6
Caso de prueba Es un escenario concreto de una prueba: Identificador Componente a probar Condiciones de entrada Datos de entrada Salida esperada
Id 1 2 3
Condiciones de entrada La base de datos está cargada La base de datos está cargada La base de datos está cargada
Entrada 1 1,5 0,3
Salida esperada 1,323 1,984 0,396
¿Cuántos casos de prueba son suficientes? Modelos
Objetivos de las pruebas 7
Verificar y validar el software Descubrir defectos no detectados con anterioridad
Encontrar defectos con poco esfuerzo y tiempo
Encontrar defectos con una alta probabilidad
Característicass de las pruebas Característica 8
Son siempre necesarias y críticas Pueden llegar a ocupar incluso el 30-40 % del tiempo Suelen suponer un coste del 30-50 % de un software confiable El princip principio io de Pareto Pareto es aplicable aplicable Son críticas para garantizar la calidad del software Sólo pueden demostrar la existencia de defectos No pueden ser completas Pueden planificarse con mucha antelación Son más efectivas si las dirige un equipo independiente
Lo que deberían y no deberían hacer 9
Deberían: Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer Realizarse de forma independiente respecto a otras Realizarse Estar muy bien documentadas
No deberían: Ser redundantes Ser demasiado complejas Dar por supuesto que un software no tendrá defectos
Falsos mitos sobre pruebas 10
Los desarrolladores de un módulo no deberían probar dicho módulo El software no debería estar expuesto a personas que puedan utilizarlo de forma mal intencionada Las personas que realizan las pruebas únicamente trabajan en la etapa de pruebas
Esquema básico del proceso 11
Planificar
Plan de pruebas
Diseñar
Casos de prueba
Información Información del proyecto
Desarrollo
Ejecutar Resultados
Depurar
Informes
Fallos encontrados
Evaluar
Resultados esperados Analizar
Planificación de la prueba 12
Identificación Enfoque Informe de incidencias Criterio de suspensión Productos a entregar Tareas a realizar Necesidades ambientales Responsabilidades Personal necesario Calendario Riesgos
Diseño de la prueba 13
Criterios utilizados para obtener los casos de prueba Casos de prueba organizados
Unidad, Integración, Sistema, Sistema, …
Resultado esperado Requisitos que se están probando
Datos de prueba Criterios de terminación
Un nº de defectos por unidad de tiempo de la prueba inferior a un valor determinado Un nº de defectos esperado Un % de cobertura determinado Fin de tiempo o recursos Se ejecutaron todas las pruebas
Depuración del software 14
Lo que se hace cuando un caso de prueba tiene éxito Fases de la depuración Localizar el defecto Corregir el defecto
Técnicas más utilizadas para localizar el defecto Fuerza bruta Rastreo hacia atrás Eliminación de causas
Espacio conceptual 15
Prueba
Caso de prueba
*
1..n
Componente
Corrección
*
*
Controlador
Resguardo *
Fallo
* *
*
Estado erróneo
*
*
Defecto
Taxonomía de gestión de de defectos defectos 16
Manejo de defectos Evitación de defectos
Detección de defectos
Gestión de la configuración
Metodología
Tolerancia a defectos Transacciones atómicas
Revisión
Pruebas
Pruebas unitarias
Pruebas de integración
Depuración
...
Manejo de excepciones
Estándares relacionados con pruebas 17
IEEE 730 asegurar la calidad del software documentación de las pruebas IEEE 829 documentación IEEE 830 especificaciones especificaciones de los requisitos de sistemas IEEE 1008 pruebas unitarias IEEE 1012 verificación y validación del software IEEE 1028 inspecciones inspecciones en software clasificación de las anomalías software IEEE 1044 clasificación IEEE 1061 métricas sobre calidad del software IEEE 12207 proceso del ciclo de vida del software y de los datos BS 7925-1 vocabulario de términos utilizados en las pruebas BS 7925-2 pruebas de componentes software ISO/IEC 29119 todo el ciclo de pruebas. Pretende sustituir a
otros como IEEE 829, IEEE 1008, BS 7925-1, BS 7925-2
Tipos principales de pruebas 18
desarrollador
cliente
usuario
Pruebas de usabilidad
Pruebas unitarias Pruebas de integración Pruebas de sistema
Pruebas de implantación Pruebas alfa y beta Pruebas de aceptación
