Upload
stuart-greene
View
37
Download
1
Embed Size (px)
DESCRIPTION
BORRAR. 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. - PowerPoint PPT Presentation
Citation preview
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, [email protected], test@[email protected], 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