Your SlideShare is downloading. ×
Ra semana 14 2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Ra semana 14 2

98
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
98
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Tipos de PruebasISF5501 Ingeniería de Software Semana 14/2
  • 2. Aprendizajes Esperados:Determina Planes de prueba basado en requerimientos de negocio. Contenidos: Describe las técnicas de detección y corrección de fallas en la etapa de transición.
  • 3. Temario Semana 14-21. Pruebas de Caja Blanca2. Pruebas de Caja Negra3. Pruebas de Sistema en Tiempo Real4. Síntesis
  • 4. Pruebas de Caja Blanca• Mediante esta técnica, se pueden obtener casos de prueba que:  Garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada módulo.  Se ejerciten todas sus decisiones lógicas.  Se ejecuten todas sus condiciones y con sus límites operacionales.  Se ejerciten las estructuras internas de datos para asegurar su validez.
  • 5. Pruebas de Caja Blanca• Las Pruebas de Caja Blanca se orientan principalmente a los siguientes tipos de errores:  Los errores lógicos y las suposiciones incorrectas.  A menudo creemos que los caminos lógicos tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar en forma regular.  Los errores tipográficos son aleatorios (traducción al lenguaje de programación)
  • 6. Temario Semana 14-21. Pruebas de Caja Blanca2. Pruebas de Caja Negra3. Pruebas de Sistema en Tiempo Real4. Síntesis
  • 7. Pruebas de Caja Negra Los métodos de prueba de caja negra se centran en los requisitos funcionales del software, orientadas al conjunto de condiciones de entrada del sistema. Esta prueba reconoce errores en las siguientes categorías: • Funciones incorrectas o ausentes • Errores de interfaz • Errores de estructuras de datos o en accesos a BBDD externas • Errores de rendimiento • Errores de inicialización o de terminación La prueba de caja negra ignora intencionalmente la estructura de control (caja blanca) y centra su atención en el campo de la información.
  • 8. Pruebas de Caja Negra Partición Equivalente: • Es un método de prueba de caja negra que divide el campo de entrada de un sistema en clases de datos de los que se pueden derivar casos de prueba. • El diseño de casos de prueba para este método se basa en una evaluación de las clases de equivalencia para una condición de entrada. • Típicamente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica.
  • 9. Pruebas de Caja Negra Análisis de Valores Límites (AVL): • Ya que los errores tienden a darse en los límites del campo y no en el centro, se desarrolla esta técnica que nos lleva a la elección de casos de prueba que ejerciten aquellos valores límites. • Esta técnica complementa la técnica de partición equivalente. • Las prueba de AVL regularmente son llevadas a cabo en forma intuitiva por los desarrolladores y aplicando ciertas directrices es más completa y, por lo tanto, tendrá una mayor probabilidad de detectar
  • 10. Pruebas de Caja Negra Técnica de Grafos causa-efecto: • Es una técnica que proporciona una representación de las condiciones lógicas y sus correspondientes acciones. • Dicha técnica sigue 4 pasos:  Se listan para un módulo las causas (condiciones de entrada) y los efectos (acciones), asignando un identificador a cada uno de ellos.  Se desarrolla un grafo de causa-efecto.  Se convierte el grafo en una tabla de decisiones.  Se convierte las reglas de la tabla de decisión a casos de prueba.
  • 11. Pruebas de Caja Negra Prueba de Comparación: • A menudo, donde la fiabilidad del software es absolutamente crítico (sistema de control de vuelo, centrales nucleares, etc.), desde el punto de vista del software se desarrollan versiones independientes de una aplicación usando las mismas especificaciones. • En la situación anterior, se debe probar cada versión con los mismos datos de prueba, para asegurar que todas proporcionan una salida idéntica.
  • 12. Pruebas de Caja Negra Prueba de Comparación: • A pesar de que se aplica esta técnica a sistemas críticos, no es infalible. • Si el error se encuentra en las especificaciones de la cual se han basados todas las versiones, el error será encontrado en cualquiera de estas versiones; por el contrario, si todas las versiones producen resultados idénticos, pero erróneos, esta prueba no detectará el error.
  • 13. Temario Semana 14-21. Pruebas de Caja Blanca2. Pruebas de Caja Negra3. Pruebas de Sistema en Tiempo Real4. Síntesis
  • 14. Pruebas de Sistema en Tiempo Real  Por la naturaleza de los sistemas en tiempo real, a las pruebas se le agregará un nuevo y difícil elemento en su tratamiento: el tiempo.  El diseñador de pruebas no solo deberá considerar los casos de pruebas de caja blanca y de caja negra, sino que también la temporización de los datos y el paralelismo de los procesos que manipulan estos datos.
  • 15. Pruebas de Sistema en Tiempo Real  Bajo esta técnica, las pruebas del software deben considerar el impacto de las fallas del hardware sobre el procesamiento del sistema.  Esta estrategia incluye cuatro pasos: • Prueba de tareas • Prueba de Comportamiento • Prueba intertareas • Prueba del Sistema
  • 16. Pruebas de Sistema en Tiempo Real i. Pruebas de Tareas: • Este es el primer paso en las pruebas de tiempo real y consiste en probar todas las tareas en forma independiente. • Se diseñan pruebas de caja negra y caja blanca y se aplican a cada una de las tareas del sistema. • Estas pruebas sólo descubren errores en la lógica y en el funcionamiento, pero NO errores a base de tiempo.
  • 17. Pruebas de Sistema en Tiempo Real ii. Pruebas de Comportamiento: • Se basa en la simulación del comportamiento del sistema y examinar dicho comportamiento en base a sucesos externos. • Se puede comparar el comportamiento del modelo del sistema (desarrollado durante el análisis) con el software ejecutable, para ver si existe concordancia. • Una vez probada cada clase de sucesos, al sistema se le presentan estos sucesos en orden aleatorio y con una frecuencia también aleatoria. • Se examina el comportamiento del sistema para detectar errores de comportamiento.
  • 18. Pruebas de Sistema en Tiempo Real iii. Prueba intertareas: • Una vez que se han aislado los errores de tareas individuales y del comportamiento del sistema, la prueba se dirige a los errores relativos al tiempo. • Se prueban las tareas que se comunican con otras, con diferentes tasas de datos y cargas de procesamiento, para determinar si se producen errores de sincronización entre ellas. • Adicional a lo anterior, se prueban las tareas que comunican colas de mensaje o almacenes de datos, para detectar errores en el tamaño de esas zonas de almacenamiento de datos.
  • 19. Pruebas de Sistema en Tiempo Real iv. Prueba del Sistema: • El software y el hardware están integrados, por lo que se lleva a cabo una serie de pruebas complejas del sistema para intentar descubrir errores en la interfaz software/hardware.
  • 20. Temario Semana 14-21. Pruebas de Caja Blanca2. Pruebas de Caja Negra3. Pruebas de Sistema en Tiempo Real4. Síntesis
  • 21. Síntesis• Las Pruebas son diseñadas principalmente para la detección de errores en el software.• Las pruebas, al igual que el diseño, debe cumplir con una serie de fundamentos para que se acerquen al concepto de calidad esperado para esta etapa.• Las pruebas están orientadas a descubrir errores del sistema. No hay que olvidar que las pruebas modulares se realizan en su proceso de desarrollo.