Post on 10-Dec-2015
description
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011
Pruebas a
través del
Ciclo de Vida
del Software
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 2
• Modelos de Desarrollo de Software
• Niveles de Pruebas
• Tipos de Pruebas
• Pruebas de Mantenimiento
Agenda
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 3
• Este tipo de modelo es frecuentemente referido como
un modelo lineal o secuencial.
• Cada producto de trabajo o actividad es completada antes de
moverse a la siguiente.
Modelo en Cascada (Waterfall)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 4
• En un entorno de fabrica que produce remaches para
el fuselaje de un avión, las verificaciones son
realizadas por operadores para evaluar el remache en
una faja transportadora. Este evaluación puede revelar
un porcentaje de los remaches que sean defectuosos.
Usualmente este porcentaje es pequeño y no resulta en
que el lote total de remaches sea rechazado. Por ello el
volumen del producto puede ser emitido. Considere
ahora el mismo avión pero el producto es el software
que controla la visualización proporcionada para el
avión. Si en algún punto de las pruebas, se encuentran
muchos defectos, que sucederá a continuación?
Podemos entregar solo partes del sistema?
Modelo en Cascada - Caso de Estudio
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 5
• Verificación
• Verifica que el producto de trabajo cumple con los requerimientos
para el que fue creado. Ej. Asegurarse que un sitio web que esta
siendo construido siga los lineamientos de usabilidad para sitios
web. La verificación ayuda a asegurar que estamos construyendo el
producto en la forma correcta
• Validación
• Cambia el enfoque de la evaluación del producto de trabajo contra
las necesidades del usuario. Esto significa asegurarse que el
comportamiento del producto de trabajo concuerde con las
necesidades del cliente definidas por el proyecto. Por ejemplo, los
lineamientos de usabilidad pueden haber sido escritos para
personas familiarizadas con sitios web. Quizás este sitio web este
orientado a usuarios novatos. La validación ayuda a asegurar que
estamos construyendo el producto correcto en tanto le interese al
usuario.
Controles a través del Ciclo de Vida
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 6
V-Model (Modelo de Desarrollo Secuencial)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 7
• El lado izquierdo del modelo se enfoca en:
• Especificación de Requerimientos-capturar las necesidades del
usuario
• Especificación Funcional – definición de las funciones requeridas
para alcanzar las necesidades de los usuarios
• Especificación técnica – diseño técnico de funciones identificadas en
la especificación funcional
• Especificación de Programa – diseño detallado de cada modulo o
unidad a ser construido para cumplir con la funcionalidad requerida
• Las especificaciones se revisan para verificar:
• Conformidad con el producto de trabajo previo
• Existe suficiente detalle para que el producto de trabajo subsecuente
se construido correctamente
• Que pueda ser probado – Existen detalles suficientes para probarlo?
V-Model (Modelo de Desarrollo Secuencial)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 8
• Al medio del modelo-V se muestra que el planeamiento
para las pruebas puede comenzar con cada producto
de trabajo
• Por ejemplo, con la especificación de requerimientos, las pruebas
de aceptación serian planificadas justo al inicio del desarrollo.
V-Model (Modelo de Desarrollo Secuencial)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 9
• El lado izquierdo se enfoca en las actividades de
pruebas. Para cada producto de trabajo, se identifica
una actividad de pruebas:
• Pruebas contra la especificación de requerimientos toman lugar en
la etapa de pruebas de aceptación
• Pruebas sobre la especificación funcional toma lugar en la etapa de
pruebas de sistema
• Pruebas sobre la especificación técnica toma lugar en la etapa de
pruebas de integración
• Pruebas sobre la especificación de programa toma lugar en la
etapa de pruebas unitarias
V-Model (Modelo de Desarrollo Secuencial)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 10
• En este modelo los requerimientos no necesitan estar
totalmente definidos antes de que comience la
codificación. En lugar de ello una versión funcional del
producto es construida, en una serie de etapas o
iteraciones – de ahí el nombre de desarrollo iterativo o
incremental
• Cada etapa incluye definición de requerimientos,
diseño, codificación y pruebas
Modelo de Desarrollo Iterativo Incremental
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 11
Modelo de Desarrollo Iterativo Incremental
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 12
• Este tipo de desarrollo se conoce como cíclico –
vamos repitiendo el ciclo de desarrollo una cantidad de
veces dentro del proyecto
• El proyecto tendrá un tiempo y costo definido, dentro
de el, los ciclos serán definidos
• Cada ciclo también tiene un tiempo y costo definido
• Para cada ciclo de tiempo un requerimiento es definido
y una versión del código es producido
• Al final del ciclo se decide si se necesita crear
funcionalidad adicional para la siguiente iteración
Modelo de Desarrollo Iterativo Incremental
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 13
• Una característica clave de este tipo de desarrollo es el
involucramiento de representantes de usuario durante
las pruebas lo que minimiza el riesgo de desarrollar
productos insatisfactorios
• La falta de documentación formal hace que sea difícil
probar por lo que los desarrolladores deben usar “test-
driven development”
Modelo de Desarrollo Iterativo Incremental
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 14
• Formas de desarrollo iterativo:
• Prototipeo
• Desarrollo rápido de aplicaciones (RAD)
• Desarrollo de Software Ágil
• Una metodología propietaria es “Rational Unified
Process (RUP)”
Modelo de Desarrollo Iterativo Incremental
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 15
• A que llamamos “verificación”?
• A que llamamos “validación”?
• Mencione 3 productos de trabajo típicamente usados
en el modelo-V
• Identifique un beneficio del modelo-V
• Identifique una debilidad del modelo-V
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 16
• Mencione 3 actividades típicamente asociados con un
modelo iterativo
• Identifique un beneficio significativo de un modelo
iterativo
• Enumere 3 retos de un desarrollo iterativo
• Enumere 3 formas de desarrollo iterativo
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 17
• Diseño temprano de las pruebas
• Cada producto de trabajo es probado
• Los probadores se involucran en la revisión de
requerimientos antes que sean liberados
Características de las Pruebas Efectivas
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 18
• Pruebas Unitarias (de Componente)
• Pruebas de Integración
• Pruebas de Sistema
• Pruebas de Aceptación
Niveles de las Pruebas
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 19
• Las pruebas unitarias intentan asegurar que el codigo
escrito para una unidad o componente concuerde con
su especificacion, previamente a su integracion con
otras unidades.
Pruebas Unitarias (de Componente)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 20
• Arrange – Act - Assert Pattern
Pruebas Unitarias (de Componente)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 21
• Se suele usar «Unit Test
Framework»
• Una metodología es «Test-
Driven Development»
• Las pruebas unitarias son
usualmente realizadas por
del desarrollador que
escribió el código
Pruebas Unitarias (de Componente)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 22
• Test Doubles
• Objetos ficticios (falsos) usados en lugar de los reales
• Usado cuando [1] el objeto real no esta disponible, [2] el
objeto real es difícil de acceder, [3] se sigue una estrategia de
re-crear un estado de la aplicación, [4] limitar el alcance de la
prueba al objeto/método actualmente bajo pruebas.
Pruebas Unitarias (de Componente)
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 23
• Test Doubles
Pruebas Unitarias (de Componente)
Si el SUT require objetos como
parametros, se usan Pseudo-
Objects o nulls como parametros
Reemplazan a los componentes reales de
los cuales depende el SUT. Las respuestas
son “Hard-coded” o controladas
Registra las llamadas a metodos
y valores de sus parametros
realizados por el SUT
Implementacion mas compleja, maneja
interacciones entre miembros del SUT.
Se comporta como component real
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 24
Obstáculos comunes para las Pruebas
Unitarias
It's not my job to do unit testing
I haven't been trained to do unit testing
I don't have the tools to do unit testing
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 25
• Entrenamiento en Metodologías de Pruebas así como
técnicas y herramientas especificas para pruebas
unitarias
• Los desarrolladores deberían ser los responsables de
crear y documentar los procesos y estándares para las
pruebas unitarias
• Establecer políticas de ejecución de pruebas unitarias
antes de colocar el código en el repositorio de control
de versiones
• Recolectar métricas a nivel de unidad. Por ejemplo: #
de defectos por miles de líneas de código (KLOC)
Como adoptar la implementación de las
pruebas unitarias
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 26
• El proposito de una prueba de integracion es exponer
defectos en las interfaces y en las interacciones
componentes integrados o sistemas.
• Identifica problemas que ocurren cuando las unidades
son combinadas
Pruebas de Integración
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 27
• Antes de comenzar, se requiere una estrategia de
integración
• Esto involucra decidir como se juntara el sistema para las pruebas
• Las estrategias mas comunes son:
• Integración Big Bang
• Integración Top-Down
• Integración Bottom-Up
• Se pueden usar Stubs (Componente pasivo llamado
por otro componente) y Drivers (componentes que
llaman a otros componentes)
Estrategias de Integración
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 28
• Todas las unidades son unidas a la vez resultando en
un sistema completo
• Es dificil aislar cualquier error encontrado
Integración Big-Bang
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 29
• El sistema es construido en etapas comenzando con
componentes que llaman a otros componentes
Integración Top-Down
Minimiza la necesidad de “drivers”, se necesitan “stubs”
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 30
• Es lo opuesto de la integracion top-down y los
componentes son integrados en un orden bottom-up
Integración Bottom-Up
Las unidades de mas bajo nivel se suelen llamar “utility modules”
Minimiza la necesidad de “stubs”. La necesidad de “drivers” complica las pruebas
y la logica de alto nivel y el flujo de datos son probados tardiamente,
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 31
• Considera la funcionalidad desde una perspectiva
completa
• Las pruebas de sistema se enfocan en el
comportamiento de todo el sistema/producto definido
por el alcance del project de desarrollo en un entorno
en vivo representativo
Pruebas de Sistema
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 32
• Especifica una funcion que un sistema o componente
de sistema debe realizar
• Puede ser especifico a un sistema.
• Ejemplo: El Sistema en el modulo de ventas debe ofrecer una
opcion mediante la cual el usuario pueda ver una comparacion de
lo presupuestado vs la venta real en un rango de fechas
Requerimientos Funcionales
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 33
• Las pruebas de sistema no-funcionales se enfoca en
aquellos aspectos que son importantes pero no
directamente relacionados con el comportamiento del
sistema.
• Son requerimientos genericos que pueden ser
aplicados a otros tipos de sistemas.
• Ejemplo: “Cuando haya hasta 100 usuarios accediendo
simultáneamente al sistema, su tiempo de respuesta no será en
ningún momento superior a 2 segundos”
Requerimientos no-Funcionales
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 34
• Installability—installation procedures.
• Maintainability—ability to introduce changes to the
system.
• Performance—expected normal behaviour.
• Load handling—behaviour of the system under
increasing load.
• Stress handling—behaviour at the upper limits of
system capability.
Requerimientos no-Funcionales - Ejemplos
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 35
• Portability—use on different operating platforms.
• Recovery—recovery procedures on failure.
• Reliability—ability of the software to perform its
required functions over time.
• Usability—ease with which users can engage with the
system.
Requerimientos no-Funcionales - Ejemplos
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 36
• Proporciona a los usuarios finales la conformidad de
que el sistema funcionara de acuerdo a sus
expectativas
• Los objetos de pruebas pueden incluir: el sistema
totalmente integrado; formularios y reportes
producidos por el sistema
• A diferencia de las pruebas de sistema, las pruebas
llevadas aquí deben ser independientes de otras
pruebas llevadas a cabo.
• Su propósito es demostrar la conformidad del sistema
con los requerimientos del cliente
Pruebas de Aceptación
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 37
Un Nivel de Prueba esta definido por un
entorno en particular
Sample Environmental Variables
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 38
• En el modelo-V cual documento seria usado como la
base de pruebas para pruebas unitarias?
• Describa 3 estrategias típicas de integración
• Identifique cuales “stubs” y “drivers” son normalmente
utilizados?
• En el modelo-V, cual documento es usado como la
base de pruebas para las pruebas de sistema?
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 39
• Compare un requerimiento funcional con un
requerimiento no-funcional
• Enumere 3 requerimientos no-funcionales
• Cual es el propósito de las pruebas de aceptación?
• En el modelo-V, cual es la base de pruebas para las
pruebas de aceptación?
• Identifique 3 tipos de pruebas de aceptación
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 40
Tipos de Pruebas
Tipos de Pruebas Modelos usados
Pruebas Funcionales Flujos de proceso, modelos de transición de estado, modelos de amenaza de seguridad,
Pruebas No-funcionales Modelos de rendimientos, Modelos de Usabilidad
Pruebas Estructurales Modelo de Flujo de Control, Modelo de estructura de menús
Pruebas relacionadas con cambios
Pruebas de Confirmación o Re-PruebaPruebas de Regresión
• Distintos tipos de pruebas son requeridos para
alcanzar los objetivos de cada Nivel de Pruebas
Guino Henostroza | Curso de Pruebas de Software | 3Dev Business & Consulting –Mayo 2011 41
• Cual de los siguientes alternativas es correcta?
(a)Las pruebas de regresión verifican que un problema ha sido
resuelto satisfactoriamente, mientras que las pruebas de
confirmación se realizan al final de cada release
(b)Las pruebas de regresión verifican que todos los problemas ha
sido resueltos satisfactoriamente, mientras que las pruebas de
confirmación se refiere a pruebas de arreglos individuales
(c)Las pruebas de regresión verifican que los arreglos a errores no
introduzcan funcionalidad inesperada dentro de sistema,
mientras que las pruebas de confirmación verifican que los
arreglos hayan sido satisfactorios.
(d)Las pruebas de regresión verifican que todas las pruebas
requeridas han sido llevadas a cabo, mientras que las pruebas de
confirmacion verifican que cada prueba este completa.