Resumen modelo de desarrollo del software

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


• 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)


• 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


• 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


V-Model (Modelo de Desarrollo Secuencial)


• 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?



• 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.



• 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



• 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


• 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



• 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”



• Formas de desarrollo iterativo:

• Prototipeo

• Desarrollo rápido de aplicaciones (RAD)

• Desarrollo de Software Ágil

• Una metodología propietaria es “Rational Unified

Process (RUP)”



• 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


• 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


• 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


• Pruebas Unitarias (de Componente)

• Pruebas de Integración

• Pruebas de Sistema

• Pruebas de Aceptación

Niveles de las Pruebas


• 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)


• Arrange – Act - Assert Pattern



• 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



• 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.



• Test Doubles


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


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


• 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


• 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


• 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


• Todas las unidades son unidas a la vez resultando en

un sistema completo

• Es dificil aislar cualquier error encontrado

Integración Big-Bang


• 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”


• 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,


• 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


• 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


• 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


• 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


• 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


• 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


Un Nivel de Prueba esta definido por un

entorno en particular

Sample Environmental Variables


• 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?


• 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


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


• 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.

Resumen modelo de desarrollo del software

Documents

Transcript of Resumen modelo de desarrollo del software