Practico
Descargar como PPTX, PDF0 recomendaciones250 vistas
El documento explica por qué las pruebas de software son necesarias. Menciona que los errores son comunes y pueden ser costosos, por lo que es importante revisar el trabajo de otros. También describe cómo los defectos pueden introducirse en cualquier etapa del ciclo de vida del software y cómo las pruebas ayudan a medir y mejorar la calidad al identificar fallas.
![El grado en el que el sistema o componente cumple
con los requerimientos o las expectativas del cliente o
usuario final.
[IEEE 610]
Calidad](https://image.slidesharecdn.com/practico-130725074756-phpapp02/85/Practico-39-320.jpg)
Practico
- 1. Introducción ¿Por qué son necesarias las pruebas de software? 25/07/2013 Marcelo Flores Sonia Medina Yajaira Vargas
- 2. ¿Por qué las pruebas de software son necesarias? Defectos Pruebas en el ciclo de vida del Software Calidad Causa del problema Agenda
- 4. Software Sistemas Computacionales, procedimientos y posibles documentos y datos asociados al funcionamiento de un sistema de computadora.
- 5. Un error en un componente o en el sistema, que causa que falle una función requerida. Bug, bicho, error, problema, falla… Defecto
- 7. Cometemos Errores • Algunos no son importantes • Algunos son costosos y peligrosos Asumir cosas erróneas • Puntos ciegos • Errores repetitivos Por qué las pruebas de software son tan necesarias? Idealmente, un tercero debe revisar nuestro trabajo ¿Un error puede causar problemas? ¡Considerar el contexto!
- 8. ¿Qué es lo que hace un Software tester?
- 9. ¿Qué hace un software tester?
- 11. Control de calidad y pruebas
- 13. Costo: 18.5 millones de dólares ¿Errores en Software?
- 15. ¿Errores en Software? ¿ ?
- 18. Diferentes tipos de Testing
- 19. Desarrollo de aplicaciones para probar aplicaciones Automatización y Pruebas de Verificación de Prototipos
- 22. Las Pruebas dependen del contexto Principio
- 23. No todos los Sistemas Informáticos tienen el mismo nivel de riesgo. No todos los problemas tienen en mismo impacto. La pruebas depende del contexto
- 24. Liste las 5 pruebas mas importantes que debería ejecutar, para cada uno de los siguientes sistemas: • Facebook • El sistema de transacciones de un Banco • El sistema de facturación de SAGUAPAC Ordene según la importancia de cada prueba, la mas importante debe ser la prueba 1, la menos importante, la prueba 5. Practica 1
- 26. Error de Usuario Error de Diseño Error de Implementación Error por ambientes Uso Malicioso Causas de efecto
- 27. El sistema no hace algo que debe hacer El sistema hace algo que no debe hacer Algunos defectos latentes pueden no causar fallas. Causas de defectos
- 28. Definición de Requerimientos Diseño Implementación ¿cuando se introduce el defectos?
- 29. Costo de los defectos
- 30. Clasifique los Errores presentados en el documentos de la Práctica 2… Practica 2
- 31. Identifique posibles defectos de diseño, de implementación, y de definición de requerimientos, para alguno de los siguientes sistemas: Sistema de un Cajero Automático Pagina de compras online TUMOMO.com Ventas online de tickets para Cine Center El sistema de notificación de vuelos de SABSA Practica 3
- 32. Pruebas
- 33. Se puede introducir defectos en todo el Ciclo. Pruebas Intensas durante el desarrollo y mantenimiento buscando defectos Pruebas en el ciclo de vida del software
- 34. La ejecución de pruebas, mejora la calidad del sistema, al identificar/reducir fallas. Se utilizan distintos métodos y pruebas: Pruebas por el autor Auditorias/pruebas por terceros Requerimientos Contractuales/legales Estándares de la industria Pruebas en el ciclo de vida del software
- 36. Las pruebas ayudan a medir la calidad del software, en términos de: Defectos encontrados Pruebas ejecutadas Cobertura Pruebas
- 37. Las pruebas se deben enfocar en: Requerimientos funcionales Requerimientos no funcionales Pruebas
- 38. Pruebas pobres, descubrirán pocos o ningún defecto. Pruebas bien diseñadas nos ayudarán a encontrar defectos certeza de la calidad y buen funcionamiento del sistema. Pruebas
- 39. El grado en el que el sistema o componente cumple con los requerimientos o las expectativas del cliente o usuario final. [IEEE 610] Calidad
- 40. Considera la siguiente aplicación: Practica 4
- 41. Identificar las características mas importantes de la aplicación Definir pruebas de aspectos funcionales y no funcionales, que aseguren la calidad del software Practica 4
- 42. Validación: • Las especificaciones son correctas? Verificación: • ¿Se cumplen las especificaciones? calidad
- 43. Se puede medir examinando los atributos del sistema: Tiempo de respuesta Tiempo entre fallas calidad
- 44. Se puede medir examinando los atributos del sistema: • Tiempo de respuesta • Tiempo entre fallas Calidad
- 45. Puede tener aspectos subjetivos: Facilidad de uso Calidad
- 46. Se basa en buenos procesos de desarrollo y cumplimiento de requerimientos: ◦Utilizamos procesos formales ◦Utilizamos los resultados de las pruebas Calidad
- 47. Considera el retorno de Inversión: El proyecto puede tener un presupuesto limitado Definir tiempos para no sobrepasar el presupuesto Calidad
- 48. Sentimiento de confianza ◦Soporte ◦Sistema Novedoso ◦Sistema Oportuno Calidad
- 49. Ejemplo
- 50. Encontrar la causa del problema
- 51. Problema Encontrar Causa Darle una solución Procedimientos para aislar el problema Encontrar la causa de un problema
- 52. El reparar un defecto puede revelar nuevos defectos La reparación de un defecto no siempre es correcta Algunos Defectos no se reparan hasta la siguiente versión Reparando defectos
- 53. Aislar la causa de un problema es importante en el proceso de aseguramiento de calidad. Podemos usar ese conocimiento para evitar defectos similares. Mejoramos nuestros procesos. Encontrar la causa de un problema
- 54. Analice el Archivo Calcular.xlsx, tiene un macro que suma valores, verifique la aplicación y si encuentra un defecto, encuentre la causa, y descríbala. Practica 5
- 55. Ejecute el Macro del archivo LimiteDatos.xlsx. Intente añadir una columna para el número 0. Excel el da un mensaje ¿Cuál es el problema? ¿Es un defecto? Practica 6
- 57. “Es imposible realizar pruebas exhaustivas a un sistema” . Principio
- 58. Inicialmente tendemos a querer probar todo ¿Es esto posible? Consideremos: Opciones validas Opciones invalidas Variedad de ambientes Tiempos/recursos ¿ Cuantas pruebas son suficientes?
- 59. Necesitamos elegir las pruebas que sean suficientes para: Proyecto Cliente Sistema Informático Considerando riesgos ¿ Cuantas pruebas son suficientes?
- 60. Las pruebas elegidas deben darnos información suficiente para tomas decisiones. ¿ Cuantas pruebas son suficientes?
- 61. Tenemos un Web site de publicidad, debemos ejecutar las pruebas al sitio antes de ponerlo a producción, y tenemos 2 semanas para terminar las pruebas. Cuentan con 2 Ingenieros de Control de Calidad. Existen 6 navegadores que pueden ser utilizados por los potenciales clientes. • Chrome, IE, Firefox, Opera, Safari, QTWeb Practica 7
- 62. ¿Como podemos ejecutar las pruebas para terminar a tiempo?, ¿existen riesgos que podemos asumir?, Describa el plan y los riesgos que podemos asumir para cumplir con la fecha límite. Practica 7
- 63. ¿Preguntas?