Notas de la Unidad 10

Transcripción

Unidad 10
Pruebas
M.C. Martín Olguín
Pruebas de Software


Los sistemas OO son colecciones de objetos
organizados por subsistemas. Estos objetos
colaboran entre sí para ofrecer la
funcionalidad esperada del software.
Es necesario probar que la interacción entre
los objetos, en diferentes niveles, se lleva a
cabo de la manera correcta.
M.C. Martín Olguín (C) 2004
Pruebas
Objetivo de las Pruebas de
Software

El objetivo de las pruebas es encontrar el
mayor número posible de errores con una
cantidad razonable de esfuerzo, aplicado
sobre un lapso de tiempo realista.
(Pressman, 2001).
Pruebas
¿Cuándo empiezan las
pruebas?



Desde la especificación de requerimientos.
Cada vez que se especifica un Caso de Uso,
se tienen que crear “Casos de Prueba” para
los diferentes escenarios.
Además se deben probar los modelos de
Análisis y Diseño para evitar la propagación
de defectos a la programación.
Pruebas
Pruebas de los modelos de
Análisis y Diseño


Estos modelos no se pueden probar en el
sentido convencional, ya que no pueden
ejecutarse.
Sin embargo se utilizan Revisiones Técnicas
Formales para examinar la exactitud y
consistencia de ambos modelos.
Pruebas
Exactitud de los modelos de
Análisis y Diseño

Exactitud Sintáctica


Se revisa el uso apropiado de la simbología que
define la metodología utilizada.
Exactitud Semántica


El modelo se debe apegar al dominio del
problema en el mundo real.
Si el modelo refleja con exactitud el mundo real,
entonces es semánticamente correcto.
Pruebas
...Exactitud Semántica


Se requiere la ayuda de expertos en el dominio
del problema, quienes revisan las definiciones de
las clases y sus jerarquías para detectar
omisiones o ambigüedades.
Se evalúan las relaciones entre clases para
determinar si reflejan las conexiones en el mundo
real.
Pruebas
Consistencia de los modelos
de Análisis y Diseño


Se centra en revisión de las relaciones entre
entidades dentro del modelo.
Se debe examinar cada clase y sus
conexiones con otras clases
(colaboraciones).
Pruebas
...Consistencia de los modelos
de Análisis y Diseño

Para el modelo del Diseño se deben llevar a
cabo revisiones de:






Arquitectura
Subsistemas
Asignación de procesadores
Asignación de clases a subsistemas
Diseño de la interfaz de usuario
Modelo de Clases del Análisis contra el del
Diseño
Pruebas
Revisiones Técnicas Formales


Es una actividad de garantía de calidad del
software.
Es una clase de revisión que incluye
recorridos, inspecciones, revisiones cíclicas y
demás evaluaciones técnicas del software
Pruebas
...Objetivos de las RTF

Objetivos:





Descubrir errores en la función, lógica o implementación
de cualquier representación del software.
Verificar que el software cumple con los requerimientos.
Garantizar que el software ha sido representado de
acuerdo a los estándares predefinidos.
Conseguir un software desarrollado de manera uniforme.
Hacer que los proyectos sean más manejables.
Pruebas
RTF


Se puede usar como entrenamiento para los
ingenieros novatos.
Promueve la seguridad y continuidad, ya que
varias personas se familiarizan con partes
del software que, de otro modo, no hubieran
visto nunca.
Pruebas
RTF

La RTF se lleva a cabo mediante una reunión
y sólo tendrá éxito si es bien planificada,
controlada y atendida.
Pruebas
Reunión de Revisión



Deben convocarse para la revisión entre tres
y cinco personas.
Se debe preparar por adelantado, pero cada
persona no le debe invertir más de dos horas
de trabajo previo.
La duración de la reunión debe ser menor a
dos horas.
Pruebas
Participantes en la preparación

El Productor


Jefe del Proyecto


Es el responsable del proyecto.
Jefe de Revisión



Es el ingeniero que ha desarrollado el artefacto.
Evalúa la disponibilidad del artefacto, genera copias del
material necesario y las distribuye entre los revisores para
que se preparen.
Prepara la agenda.
Revisores

Se familiarizan con el artefacto y preparan sus notas.
Pruebas
Desarrollo de la Reunión






Se designa un Registrador (secretario) entre
los Revisores.
El Jefe de Revisión explica la agenda.
El Productor expone una breve introducción.
El Productor inicia el “recorrido de
inspección”, explicando el material.
Los Revisores exponen sus puntos de vista.
El Registrador va anotando los problemas o
errores encontrados.
Pruebas
...Desarrollo de la Reunión

Al final de la reunión los participantes deben
decidir si:




Aceptan el artefacto sin modificaciones.
Rechazan el artefacto debido a los serios errores
encontrados.
Aceptan el artefacto provisionalmente.
Todos los asistentes firman la conclusión.
Pruebas
Registro e Informe de la
Revisión


El Registrador debe generar una lista de
sucesos de revisión y un resumen.
El resumen debe responder lo siguiente:



¿Qué fue revisado?
¿Quién lo revisó?
¿Qué se descubrió y cuáles fueron las
conclusiones?
Pruebas
La lista de sucesos de revisión

Sirve para:


Identificar áreas problemáticas dentro del
artefacto.
Como lista de comprobación para que el
Productor verifique que cumplió con lo acordado.
Pruebas
Directrices para la revisión





Revisar al artefacto no al Productor.
Fijar una agenda y mantenerla.
Limitar el debate y las impugnaciones.
Enunciar áreas de problemas, pero no
intentar resolver cada problema.
Tomar notas escritas.
Pruebas
...Directrices para la revisión





Limitar el número de participantes e insistir
en la preparación anticipada.
Desarrollar un checklist para cada artefacto a
revisar.
Disponer de recursos y tiempo.
Llevar a cabo un buen entrenamiento de
todos los revisores.
Repasar las revisiones anteriores.
Pruebas
Pruebas de Implementación

Para probar código, existen dos grandes
tipos de pruebas:

Pruebas de Caja Negra


Sólo interesa la funcionalidad y no la implementación,
es decir, se enfoca en las entradas y las salidas.
Pruebas de Caja Blanca


Se generan a partir del conocimiento de la estructura
e implementación del software.
Se realiza análisis de código para diseñar pruebas
que garanticen que todas las instrucciones de un
componente se ejecutarán al menos una vez.
Pruebas
...Pruebas de Implementación


Para la POO se sigue la estrategia clásica:
de dentro hacia fuera, es decir, de lo más
pequeño a lo más grande.
Esto implica:



Pruebas de Unidad
Pruebas de Integración
Pruebas de Sistema (validación)
Pruebas
Pruebas de Unidad



En la POO la unidad más pequeña
comprobable es la clase.
Cada clase posee uno o varios métodos
(operaciones).
Técnicas de prueba de unidad:


Verificación al azar. En esta se definen
trayectorias de operaciones aleatorias.
Pruebas de partición basada en estados. Se
definen trayectorias de operaciones que obliguen
al objeto a transitar por varios estados.
Pruebas
…Pruebas de Unidad



Pruebas de partición basada en atributos. Se
prueban las operaciones que usen determinados
atributos.
Pruebas de partición basada en categorías. Se
agrupan y prueban las operaciones de acuerdo a
una función genérica, por ejemplo: operaciones
de inicialización, operaciones de consulta y
operaciones de terminación.
¿Qué pasa con la jerarquía de clases?
Pruebas
Pruebas de Integración


Consiste en probar la colaboración entre las
clases.
Estrategias:


Pruebas de escenarios. Se utilizan los diagramas
de interacción para generar los casos de prueba
de acuerdo a cómo tienen que colaborar los
objetos participantes en un escenario incluyendo
excepciones.
Pruebas de cadenas de eventos. Prueban la
respuesta del sistema a una entrada particular o
a un conjunto de eventos de entrada.
Pruebas
Pruebas de Validación



A nivel de sistema o de validación, los
detalles de conexiones de clases
desaparecen.
La validación se centra en las acciones
visibles al usuario y salidas reconocibles
desde el sistema. Se aplican técnicas de caja
negra.
Para diseña las pruebas se utilizan la
especificación de casos de uso, diagramas
de estados y de actividades.
Pruebas
Pruebas de Regresión


En la etapa de implementación, cada vez que
se corrige un error en una clase, en un
módulo o en un subsistema, es necesario
aplicar pruebas de regresión, es decir, repetir
las pruebas que ya se habían aplicado.
Las pruebas de regresión se utilizan para
comprobar que los cambios hechos a un
programa no introducen nuevas fallas.
Pruebas
...Pruebas de Regresión


En la realidad es muy caro aplicar todas las
pruebas cada vez que se hace una
modificación.
Por eso es importante identificar bien las
dependencias entre módulos y subsistemas,
procurar en el diseño el bajo acoplamiento y
asociar cada prueba con su correspondiente
componente o subsistema.
Pruebas
Drivers
images%255Cco_stubs-img2
images%255Cco_stubs-img1
Pruebas
Stubs
Pruebas
Artefactos




Lista de ideas para Pruebas
Plan de Pruebas
Caso de Prueba
Script de Prueba
Pruebas

Notas de la Unidad 10

Transcripción

Documentos relacionados

Comunicado de prensa SCEM/CS/178 RINDEN HOMENAJE AL

himno cebe don josé de san martín