21
Tipos de Pruebas ISF5501 Ingeniería de Software Semana 14/2

Ra semana 14 2

Embed Size (px)

Citation preview

Page 1: Ra semana 14 2

Tipos de PruebasISF5501 Ingeniería de Software

Semana 14/2

Page 2: Ra semana 14 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.

Page 3: Ra semana 14 2

1. Pruebas de Caja Blanca

2. Pruebas de Caja Negra

3. Pruebas de Sistema en Tiempo Real

4. Síntesis

Temario Semana 14-2

Page 4: Ra semana 14 2

Garanticen que se ejercitan por lo menos una vez todoslos caminos independientes de cada módulo.

• Mediante esta técnica, se pueden obtener casos deprueba que:

Se ejerciten todas sus decisiones lógicas.

Se ejecuten todas sus condiciones y con sus límitesoperacionales.

Se ejerciten las estructuras internas de datos paraasegurar su validez.

Pruebas de Caja Blanca

Page 5: Ra semana 14 2

Los errores lógicos y las suposiciones incorrectas.

• Las Pruebas de Caja Blanca se orientan principalmente alos siguientes tipos de errores:

A menudo creemos que los caminos lógicos tiene pocasposibilidades de ejecutarse cuando, de hecho, se puedeejecutar en forma regular.

Los errores tipográficos son aleatorios (traducción allenguaje de programación)

Pruebas de Caja Blanca

Page 6: Ra semana 14 2

1. Pruebas de Caja Blanca

2. Pruebas de Caja Negra

3. Pruebas de Sistema en Tiempo Real

4. Síntesis

Temario Semana 14-2

Page 7: Ra semana 14 2

Los métodos de prueba de caja negra se centran en losrequisitos funcionales del software, orientadas al conjuntode 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 BBDDexternas

• Errores de rendimiento

• Errores de inicialización o de terminación

La prueba de caja negra ignora intencionalmente laestructura de control (caja blanca) y centra su atención en elcampo de la información.

Pruebas de Caja Negra

Page 8: Ra semana 14 2

Partición Equivalente:

• Es un método de prueba de caja negra que divide elcampo de entrada de un sistema en clases de datos delos que se pueden derivar casos de prueba.

• El diseño de casos de prueba para este método se basaen una evaluación de las clases de equivalencia para unacondición de entrada.

• Típicamente, una condición deentrada es un valor numéricoespecífico, un rango de valores, unconjunto de valores relacionadoso una condición lógica.

Pruebas de Caja Negra

Page 9: Ra semana 14 2

Análisis de Valores Límites (AVL):

• Ya que los errores tienden a darse en loslímites del campo y no en el centro, sedesarrolla esta técnica que nos lleva a laelección de casos de prueba queejerciten aquellos valores límites.

• Esta técnica complementa la técnica de particiónequivalente.

• Las prueba de AVL regularmente son llevadas a cabo enforma intuitiva por los desarrolladores y aplicandociertas directrices es más completa y, por lotanto, tendrá una mayor probabilidad de detectarerrores.

Pruebas de Caja Negra

Page 10: Ra semana 14 2

Técnica de Grafos causa-efecto:

• Es una técnica que proporciona unarepresentación de las condiciones lógicasy sus correspondientes acciones.

• Dicha técnica sigue 4 pasos:

Se listan para un módulo las causas (condiciones deentrada) y los efectos (acciones), asignando unidentificador 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 casosde prueba.

Pruebas de Caja Negra

Page 11: Ra semana 14 2

Prueba de Comparación:

• A menudo, donde la fiabilidad del software esabsolutamente crítico (sistema de control de vuelo,centrales nucleares, etc.), desde el punto de vista delsoftware se desarrollan versiones independientes de unaaplicación usando las mismas especificaciones.

• En la situación anterior, se debe probar cada versión conlos mismos datos de prueba, para asegurar que todasproporcionan una salida idéntica.

Pruebas de Caja Negra

Page 12: Ra semana 14 2

Prueba de Comparación:

• A pesar de que se aplica esta técnica a sistemascríticos, no es infalible.

• Si el error se encuentra en las especificaciones de la cualse han basados todas las versiones, el error seráencontrado en cualquiera de estas versiones; por elcontrario, si todas las versiones producen resultadosidénticos, pero erróneos, esta prueba no detectará elerror.

Pruebas de Caja Negra

Page 13: Ra semana 14 2

1. Pruebas de Caja Blanca

2. Pruebas de Caja Negra

3. Pruebas de Sistema en Tiempo Real

4. Síntesis

Temario Semana 14-2

Page 14: Ra semana 14 2

Por la naturaleza de los sistemas en tiempo real, a laspruebas se le agregará un nuevo y difícil elemento en sutratamiento: el tiempo.

El diseñador de pruebas no solodeberá considerar los casos depruebas de caja blanca y de cajanegra, sino que también latemporización de los datos y elparalelismo de los procesos quemanipulan estos datos.

Pruebas de Sistema en Tiempo Real

Page 15: Ra semana 14 2

Bajo esta técnica, las pruebas del software debenconsiderar el impacto de las fallas del hardware sobre elprocesamiento del sistema.

Esta estrategia incluye cuatro pasos:

• Prueba de tareas

• Prueba de Comportamiento

• Prueba intertareas

• Prueba del Sistema

Pruebas de Sistema en Tiempo Real

Page 16: Ra semana 14 2

i. Pruebas de Tareas:

• Este es el primer paso en las pruebas de tiempo real yconsiste en probar todas las tareas en formaindependiente.

• Se diseñan pruebas de caja negra y caja blanca y seaplican a cada una de las tareas del sistema.

• Estas pruebas sólo descubren errores en la lógica y en elfuncionamiento, pero NO errores a base de tiempo.

Pruebas de Sistema en Tiempo Real

Page 17: Ra semana 14 2

ii. Pruebas de Comportamiento:

• Se puede comparar el comportamiento del modelo delsistema (desarrollado durante el análisis) con el softwareejecutable, para ver si existe concordancia.

• Una vez probada cada clase de sucesos, al sistema se lepresentan estos sucesos en orden aleatorio y con unafrecuencia también aleatoria.

• Se examina el comportamiento del sistema para detectarerrores de comportamiento.

Pruebas de Sistema en Tiempo Real

• Se basa en la simulación del comportamiento del sistemay examinar dicho comportamiento en base a sucesosexternos.

Page 18: Ra semana 14 2

iii. Prueba intertareas:

• Se prueban las tareas que se comunican con otras, condiferentes tasas de datos y cargas de procesamiento,para determinar si se producen errores desincronización entre ellas.

• Adicional a lo anterior, se prueban las tareas quecomunican colas de mensaje o almacenes de datos, paradetectar errores en el tamaño de esas zonas dealmacenamiento de datos.

Pruebas de Sistema en Tiempo Real

• Una vez que se han aislado los errores de tareasindividuales y del comportamiento del sistema, laprueba se dirige a los errores relativos al tiempo.

Page 19: Ra semana 14 2

iv. Prueba del Sistema:

• El software y el hardware están integrados, por lo que selleva a cabo una serie de pruebas complejas del sistemapara intentar descubrir errores en la interfazsoftware/hardware.

Pruebas de Sistema en Tiempo Real

Page 20: Ra semana 14 2

1. Pruebas de Caja Blanca

2. Pruebas de Caja Negra

3. Pruebas de Sistema en Tiempo Real

4. Síntesis

Temario Semana 14-2

Page 21: Ra semana 14 2

Síntesis

• Las Pruebas son diseñadas principalmente para ladetección de errores en el software.

• Las pruebas, al igual que el diseño, debe cumplir conuna serie de fundamentos para que se acerquen alconcepto de calidad esperado para esta etapa.

• Las pruebas están orientadas a descubrir errores delsistema. No hay que olvidar que las pruebasmodulares se realizan en su proceso de desarrollo.