1. Borre el titulo con el cuadrado y cuando salga “Haga click para agregar el titulo”Escribe el que estaba y ya

2. Cambie los verdes porfavor q se ve re feo JAJAJAJA

3. Y Borre de su parte lo q no crea q sea necesario, igual ya borre algunas

BORRAR

Prueba de equivalencia• Técnica de caja negra, que.

Prueba de equivalencia• Técnica de caja negra, que.

The Big Five- Henry Cafiero, Guillermo Malagón

PRUEBAS DE SOFTWARE

El hombre que ha cometido un error y no lo corrige comete otro error mayor. Confucio (551 AC-478 AC) Filósofo chino.

AGENDA

Introducción. Objetivo. Características. Ejemplos Defecto, Falla Error Tipos de defecto Tipos de prueba Casos de prueba Tipos de casos de prueba Stub y manejadores de prueba

Correcciones. Técnicas de control de calidad

Técnicas para evitar defectos Técnicas para detectar defectos

prueba unitaria pruebas de integración pruebas del sistema.

Técnicas de tolerancia de defectos.

Actividades de Prueba. Conclusiones

Bibliografía

Proceso de analizar un producto de software para: Detectar diferencias entre el

comportamiento real con el pedido. Para evaluar las funcionalidades y

características no funcionales del software.

Las pruebas en la Ingeniería de Software son muy importantes y deben realizarse en cada una de las fases de la construcción del producto, las cuales incluyen especificaciones en: Requisitos. Casos de Uso. Diagramas. Código Fuente

IEEEStandard1999

INTRODUCCION

Pruebas en la planeación

Objetivo PrincipalDiseñar pruebas

sistematicamente

Objetivos• Detectar un error. • Lograr confianza acerca

del nivel de calidad.• Tener un buen caso de

prueba: que tenga más probabilidad de mostrar un error no descubierto antes.

• Descubrir un error no descubierto antes (éxito de la prueba).

¿Estamosconstruyendocorrectament

eel producto?

¿Estamosconstruyend

o elProducto correcto?

Objetivo

¿POR QUÉ ES IMPOSIBLE PROBAR POR COMPLETO UN SISTEMA?

Las pruebas no son determinantes.

Es necesario realizar las pruebas bajo restricciones de tiempo y presupuesto.

Los sistemas se entregan sin estar probados por completo, esto conduce a defectos que son descubiertos por los usuarios finales.

Porque es imposible probar por completo un sistema

Características de una buena prueba

Alta probabilidad de encontrar un error.No ser redundante.Ser la mejor de su clase.No muy simple, no muy compleja.Trazable.Planeada.Ir de lo pequeño a lo grande.Diseñar y documentar es muy importante.

Ejemplos I

Shega-Cindy Sánchez, Guillermo Malagon

Error

Defecto

Ejemplos II

Algorítmico

Mecánico

Tipos de Defectos (1/3)

Algorítmico

Sintaxis

Uso incorrecto de las estructuras del lenguaje de programación.

Computacióny precisión

Formula mal implementada o resultado con precisión no deseada.

Documentación

Los documentos no corresponden con el funcionamiento real.

Tipos de defectos (1/3)

Tipos de defectos (2/3)

Por estrés ysobrecarga

Capacidad olimites

Sincronización ocoordinación

Rendimiento oDesempeño

Cuando el sistema opera fuera de la velocidad especificada en los requerimientos no funcionales.

Tipos de Defectos (2/3)

Tipos de defectos (3/3)

Recuperación

Cuando se encuentra una falla y el sistema no responde como se esperaba.

H/W y S/W de sistemas

Cuando el H/W y el S/W operan fuera de las condiciones operativas establecidas en la documentación.

Estándares yprocedimientos

Cuando no se siguen los procedimientos previamente establecidos para el desarrollo de una actividad.

Omisión

Cometido

• Cuando se crea algo incorrecto.

Tipos de Defectos (3/3)

Basados en Ejecución: Se crean los casos de pruebateniendo en cuenta el código ejecutable.

Basados en la No Ejecución : Se revisa metodicamente el código para encontrar fallas, no se usan los casos de prueba

Tipos de Pruebas

Casos de prueba

Atributos Descripción

Nombre Permite que el que realiza la prueba distinga los casos de prueba.

Propósito Por que se realiza el caso de prueba.

Prerrequisitos Que se debe tener correcto antes de ejecutar el caso de prueba.

Ubicación Describe donde puede encontrarse el caso de prueba.

Entrada Describe el conjunto de datos de entrada a dar por el actor.

Oráculo Resultados esperados de la prueba contra los que se compara la salida de la prueba.

Pasos Como se debe realizar la prueba.

Casos de Prueba

Atributos Descripción

Nombre Normal User Login

Propósito Test that users can log in with the proper username or email address and their password.

Prerrequisitos User is not already logged in.User testuser exists, and account is in good standing.

Ubicación http://readyset.tigris.org/nonav/templates/frameset.html

Entrada usernameOrEmail = {testuser, bogususer, testuser@nospam.com, test@user@nospam.com, empty}password = {valid, invalid, empty}

Oráculo El usuario se encuentra en el sistema.

Casos de Prueba (2)

Casos de prueba (3)

Atributos Descripción

Pasos visit LoginPageenter usernameOrEmailenter passwordclick Loginsee the terms-of-use pageclick Agree at page bottomclick Submitsee PersonalPageverify welcome message is correct username

Casos de Prueba (3)

Enfoque Aleatorio:consiste en utilizar modelos (en muchas ocasiones

estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba

creando datos de entrada en la secuenciay con la frecuencia con las que podrían aparecer en la

Práctica (de manera repetitiva)

Para ello habitualmente se utilizan generadores automáticos de casos de prueba

Tipos de Casos de Prueba (Enfoques Principales)

Enfoque estructural o de caja blanca (transparente): – Estructura interna del programa– La prueba exhaustiva: probar todos

los posibles caminos de ejecución– nº caminos lógicos ( buscar los más importantes)

Enfoque funcional o de caja negra: – Para derivar los casos: se estudia

la especificación de las funciones, la entrada y la salida.

STUBS Y MANEJADORES DE PRUEBAS

Se usan para sustituir las partes faltantes de un sistema mientras estas se encuentran aisladas en una ejecución de casos de pruebas.

Stubs y manejadores de Pruebas

Manejadores de Pruebas

Stub de Prueba

Simula la parte del sistema que llama al componente a

probar

Simula a los componentes que

son llamados por el componente a

probar

CORRECCIONES

Es un cambio a un componente con el propósito de reparar un defecto.

Las correcciones pueden ir desde una simple modificación de un solo componente, hasta el rediseño completo de una estructura de datos o un subsistema.

Existe una probabilidad alta de que el desarrollador introduzca nuevos defectos en el componente revisado.Seguimiento del

problema

Contiene documentación de cada falla error y defecto

detectado y su corrección.

Correcciones

Tecnicas de Control de Calidad

Técnicas de control de calidad

Control de calidadEvitar defectos

Detección de defectos

Tolerancia de defectos

Trata de impedir la ocurrencia de errores y fallos encontrando

defectos en el sistema antes de

lanzarlo

Ayuda a encontrar defectos en los

sistemas pero no tratan de

recuperar las fallas que causa

Recuperación de una falla mientras

el sistema se encuentra en

ejecución

Tecnicas de Control de Calidad

Técnicas para evitar defectos

Evitar defectos

Desarrollo de metodologías

Administración de la configuración

Técnicas de verificación

Revisiones

Técnicas que minimizan la

introducción de defectos en los

modelos del sistema y el

código.

Evita cambios causados por cambios no

controlados en los modelos del

sistema

Encontrar defectos antes de la ejecución del

programa

Inspección manual de

algunos o todos los aspectos del

sistema sin ejecutar.

Tecnicas para evitar defectos

Técnicas para detectar defectos

Detectar defectos

Depuración

Depuración para corrección

Depuración del desempeño

Pruebas

Prueba unitaria

Prueba de integración

Prueba del sistema

Asume que los defectos pueden

encontrarse a partir de una falla

no planeada

Técnica de detección de defectos que trata de crear

fallas o errores en forma planeada

Encontrar cualquier

desviación entre los

requerimientos funcionales

observados y los especificados.

Desviación entre los

requerimientos no funcionales

observados y los especificados.

Trata de encontrar

defectos en los subsistemas, con

respecto a los casos de uso

Probar los componentes

cuando están en conjunto en un sistema activo.

Prueba los componentes juntos vistos

como el sistema final, para

identificar errores

Tecnicas para detectar defectos

Motivaciones

Reduce complejidad de

las pruebas generales.

Permite paralelismo de

actividades.

Facilita resaltar y corregir defectos.

Prueba Unitaria

Prueba de equivalencia

• Técnica de caja negra, que minimiza la cantidad de casos de prueba.

Tecnicas para pruebas unitarias

I

d

e

n

tifi

c

a

c

i

ó

n

d

e

l

a

s

c

l

a

s

e

s

d

e

e

q

u

i

v

a

l

e

n

c

i

a

.

Selección de las entradas de prueba.

Criterio Descripción

Cobertura Cada entrada posible pertenece a una de las clases de equivalencia.

Inconexión Ninguna entrada pertenece a mas de una entrada de equivalencia.

Representación Si la ejecución muestra un error cuando se usa como entrada un miembro particular de una clase de equivalencia, el mismo error puede detectarse usando como entrada a cualquier otro miembro de la clase.

Prueba de Equivalencia

Método que retorna la cantidad de días de un mes recibiendo el mes y el día como parámetro.

Ejemplo

Clase de equivalencia Valor para la entrada de mes

Valor para la entrada de año

Meses con 31 días, años no bisiestos.

7 (Julio) 1901

Meses con 31 días, años bisiestos.

7 (Julio) 1904

Meses con 30 días, años no bisiestos.

6 (Junio) 1901

Meses con 30 días, años bisiestos.

6 (Junio) 1904

Meses con 28 o 29 días, años no bisiestos.

2 (Febrero) 1901

Meses con 28 o 29 días, años bisiestos.

2 (Febrero) 1904

Ejemplo

Prueba de frontera

• Caso especial de la prueba de equivalencia, se enfoca en las condiciones de frontera de las clases de equivalencia.

Tecnicas para pruebas unitarias

Se deben seleccionar los casos de los extremos de las clases de equivalencia.

desventaja: no exploran combinaciones de datos de entrada de prueba

EJ: Clase de equivalencia

Valor para la entrada de

mes

Valor para la entrada de

año

Años bisiestos divisibles entre 400

2 (Febrero) 2000

Años no bisiestos divisibles entre 100

2 (Febrero) 1900

Meses no positivos inválidos

0 1291

Meses positivos inválidos.

13 1315

Prueba de Frontera

Prueba de ruta

• Técnica de caja blanca, que identifica fallas en la implementación del componente.

Tecnicas para pruebas unitarias

Se deben recorrer todas las rutas posibles del código para encontrar las fallas producidas por los defectos.

El punto inicial son los diagramas de flujo.

Prueba de ruta

DIAGRAMA DE FLUJO GRAFO DE FLUJO

• Este método permite obtener una medida de la complejidad lógica de un diseño procedimental.

•Esta medida puede ser usada como guía a la hora de definir un conjunto básico de caminos de ejecución (diseño de casos de prueba).

Ejemplo prueba de ruta

Caso de prueba Ruta

[year = 0, month = 1] [throws1]

[year = 1901, month = 1] [n = 32 return]

[year = 1901, month = 2] [n = 28 return]

[year = 1904, month = 2] [n = 29 return]

[year = 1901, month = 4] [n = 30 return]

[year = 1901, month = 0] [throws2]

Complejidad ciclomática CC = #aristas – #nodos +2

Ejemplo prueba de ruta (2/2)

1. V (G) = a - n + 2siendo a el número de arcos o

aristas del grafo y n el número de nodos.

2. V (G) = rsiendo r el número de regiones cerradas delgrafo.

3. V(G) = c + 1 siendo c el número de nodos de condición.

Complejidad Ciclomatica

Pruebas basadas en estado• Se enfoca en los sistemas

orientados a objetos.

Tecnicas para pruebas unitarias

Se seleccionan entradas para cada estado del sistema.

Se compara estado resultante con el esperado.

Pruebas basadas en estado

Ejemplo de pruebas basadas en estado

Estimulo Transición probada Estado resultante predicho

Conjunto vacio 1. Transición inicial MeasureTime

Oprimir ButtonL 2. MeasureTime

Oprimir ambos botones 3. SetTime

Esperar 2 min 4. Exceso tiempo MeasureTime

Oprimir ambos botones

3. Pone al sistema en el estado SetTime para probar la siguiente transición

SetTime

Oprimir ambos botones 5. SetTime -> MeasureTime

Oprimir ambos botones 3. SetTime

Oprimir ButtonL 6. Ciclo de regreso MeasureTime MeasureTime

Pruebas resultantes para ajustar la hora (los 8 primeros estimulos)

• Prueba de condición: Encontrar errores en condiciones lógicas en un módulo

• Prueba de flujo de datos: De acuerdo con la ubicación de las definiciones y los usos de las variables del programa.

• Prueba de bucles: exclusivamente en la validez de las construcciones de Bucles Tipos de bucles:

• Simples • Anidados • Concatenados• No estructurados

Pruebas de la estructura de control

Prueba de gran explosión

• Asume que los componentes se prueban primero en forma individual y luego como un sistema.

Estrategia para pruebas de integracion

Cuando todos los componentes se prueban por separado existe la tentación de mezclarlos juntos desde la primera vez.

Utilizado para sistemas pequeños.

Prueba de gran explosion

Exige prueba individual de

cada componente.

Difícil encontrar

fallas al estar todos los

componentes fusionados.

No se pueden

distinguir los defectos de la interfaz de otros.

Desventaja

Ejemplo gran explosion

Ejemplo gran explosion

Prueba de abajo hacia arriba

• Prueba primero de manera individual el componente de la capa inferior para luego integrarlos a los de la capa superior.

Estrategias para prueba de integracion

Prueba individualmente los componentes de la capa inferior

Integra los componentes con los de la siguiente capa

Se repite hasta que se combinan todos los componentes de todas las capas

Prueba de abajo hacia arriba

Ejemplo de prueba de abajo hacia arriba

Ejemplo de prueba de abajo hacia arriba

Prueba de arriba hacia abajo

• Prueba primero de manera individual el componente de la capa superior para luego integrarlos a los de la capa inferior.

Estrategias para prueba de integracion

Prueba individualmente los componentes de la capa superior

Integra los componentes de la siguiente capa hacia abajo

Cuando estan integrados los componentes de la capa se realiza la integración con la siguiente capa

Prueba de arriba hacia abajo

Ejemplo de prueba de arriba hacia abajo

Ejemplo de prueba de arriba hacia abajo

Prueba de emparedado

• Combina las estrategias de abajo hacia arriba y de arriba hacia abajo, usando lo mejor de cada una.

Estrategia para prueba de integracion

Se elige una capa destino

Se prueba la capa superior y se integra a la capa destino

Se prueba la capa inferior y se integra a la capa destino

Prueba de emparedado

Ejemplo de prueba de emparedado

Ejemplo de prueba de emparedado

Prueba de emparedado modificado• Prueba las tres capas en forma

individual antes de combinarlas en pruebas incrementales entre ellas

Estrategias para pruebas de integracion

Se elige una capa destino

S

e

p

r

u

e

b

a

n

i

n

d

i

v

i

d

u

a

l

m

e

n

t

e

t

o

d

a

s

l

a

s

c

a

p

a

s

Se realizan pruebas incrementales combinadas entre las capas

Prueba de emparedado modificado

Prueba de emparedado modificado

Prueba de emparedado modificado

Prueba funcional

• Encuentra diferencias entre los requerimientos funcionales y el sistema, técnica de caja negra.

Actividades para pruebas del sistema

Inspección del modelo de casos de uso.

Identificamos instancias de casos de uso que es probable que causen fallas.

Prueba Funcional

Prueba de desempeño

• Encuentra diferencias entre los objetivos de diseño seleccionados durante el diseño del sistema y el sistema.

Actividades para prueba del sistema

Prueba de Esfuerzo

• Revisa si el sistema puede responder a muchas peticiones.

Prueba de Volumen

• Trata de encontrar defectos asociados a grandes cantidades de datos.

Pruebas de Seguridad

• Trata de encontrar fallas de seguridad en el sistema.

Prueba de desempeno (1/2)

Pruebas de Temporización

• Tratan de encontrar comportamientos que violan las restricciones de temporización descritas por los requerimientos funcionales.

Pruebas de Recuperación

• Evalúan la habilidad del sistema para recuperarse de errores.

Prueba de desempeno (2/2)

Prueba piloto

• Se instala el sistema y lo utiliza un conjunto de usuarios seleccionados.

Actividades para prueba del sistema

Pruebas Alfa

• Los usuarios usan al sistema en el ambiente de desarrollo.

Pruebas Beta

• Una cantidad limitada de usuarios finales realizan la prueba de aceptación.

Prueba Piloto

Prueba de aceptación

• Pruebas de usabilidad funcional y de desempeño realizadas por el cliente en el ambiente de desarrollo contra criterios de aceptación.

Actividades para prueba del sistema

Prueba Patrón

• El cliente prepara un conjunto de casos de prueba que representa condiciones típicas bajo las cuales debe operar el sistema.

Pruebas Competidoras

• Se prueba el nuevo sistema contra el sistema existente.

Pruebas de Sombra

• Se ejecutan en paralelo los sistemas nuevo y heredado, se comparan sus salidas.

Prueba de aceptacion

Prueba de instalación

• Pruebas para revisar que los manuales de instalación correspondan con el proceso real llevado a cabo al momento de instalar el software en el ambiente de destino.

Pruebas de Instalación

Tolerancia de defectos

Transacciones atómicas

Redundancia modularLos sistemas de bases de datos

las proporcionan para recuperarse

de una falla.

Se sustenta en la suposición de que

las fallas del sistema se basan en las fallas de

los componentes

Tecnicas de tolerancia de defectos

1. Especificaciones del Cliente insuficientes.

2. Dificultad con el control de versiones.

3. Falta de Claridad en procesos de desarrollo de software.

4. Cambios en las funcionales de Alto Impacto en producto.

5. Aumento del alcance del producto.

6. Cambios en miembros del proyecto.

7. Curva de aprendizaje de nuevos miembros vinculados a los proyectos.

8. Suspensiones en los proyectos y tiempos invertidos para retomar

proyectos.

9. Inestabilidad del ambiente de pruebas, lo que ocasionó la repetición de

pruebas.

10. Dificultad para establecer la configuración y los datos de pruebas.

Conclusiones

BRUEGGE, B y DUTOIT, A. Ingeniería de Software Orientado a Objetos. Prentice Hall, 2002.

Pfleeger, S. Ingeniería de Software Teoría y Práctica. Prentince Hall, 2002.

Schach, S. Ingeniería de Software Clásica y Orientada a Objetos. McGrawHill, 2002.

SWEBOK: Guide to the Software Engineering Body of Knowledge, 2004 Version, Disponible: http://www.swebok.org [Ene, 2005] .

http://www.greensqa.com/archivos/Art02-PlaneacionPruebasFuncionales.pdf

Bibliografía

Taller

Solución Taller

Camino 1

Camino 2

Camino 3