PVVS-Clase 01-Introduccion

PRUEBAS
VERIFICACIÓN Y
VALIDACIÓN DE
SOFTWARE
2020-I
Verificación y Validación de
Software
Software
Verificación y Validación de Software
Software
Proceso de evaluación de un sistema (o de uno de sus
componentes) para determinar si los productos de una fase
dada satisfacen las condiciones impuestas al comienzo de
dicha fase.
"¿Estamos construyendo correctamente el producto?

Software
Proceso de evaluación de un sistema (o de uno de sus
componentes) durante o al final del proceso de desarrollo
para determinar si satisface los requisitos marcados por el
usuario.
"¿Estamos construyendo el producto correcto?

Verificación: ¿Construimos
el mouse correctamente?
Validación: ¿Hicimos el
mouse que el cliente quería?
• Debido a la urgencia de entregas de un producto de software, es una

práctica común realizar una pobre verificación y validación.
• En general, sólo se prueban algunos casos ejemplo para observar si los

resultados de ejecución cumplen nuestras expectativas.
• Esto implica una pobre confianza en el producto de

• software.
La verificación y validación no puede hacerse en base a

intuición, experiencia o suerte. Se requiere seguir
principios y técnicas rigurosas y adecuadas.

Tanto el proceso de desarrollo de software, como los

productos generados, deben ser verificados.

Tanto el proceso de desarrollo de software, como los

productos generados, deben ser verificados.
El proceso de verificación debe ser verificado.

La actividad debe realizarse en momentos diferentes con

objetivos, técnicas y personal diferente.
Quien desarrolla su producto, no debería verificar su

producto. El ego humano no permite ser objetivo. no
queremos aceptar nuestras equivocaciones, y queremos
terminar pronto.
La presencia de defectos en el software complejo no puede

evitarse completamente. A veces, algunos defectos
pueden ser tolerados.
En la práctica, la correctitud es relativa.

El mito dice que si somos buenos programadores, no

habrá errores que encontrar. Si nos concentramos bien, si
usamos programación estructurada, OO, etc. no vamos a
tener errores.
Hay bugs, dice el mito, porque somos malos

programadores, y si somos malos debemos sentirnos
culpables.
La producción de software, como cualquier actividad

humana, es un proceso sujeto a errores. Cualquiera sean
los métodos usados, no es posible garantizar que el
producto final se comporte siempre como es requerido.
Fundamentos del Testing de Software
Fundamentos del Testing de

Software
Durante la construcción de cualquier producto, sus partes y

el producto final son chequeados con respecto a una
especificación o requerimientos.

Se debe determinar si el producto resuelve las tareas

especificadas.

Se debe determinar si el producto resuelve las tareas

especificadas.
Si el producto exhibe problema, se deben realizar las

correcciones necesarias.
Esta idea general que describe la construcción de

productos, también es apropiada para la construcción de
software.
Sin embargo, la evaluación de productos parciales o

totales en el software resulta ser más difícil.
La evaluación de un software es más difícil porque un

producto de software no es un objeto físico. No podemos
mirar el software.
La única forma de examinar directamente el software es

mirando su código y la documentación.
El comportamiento dinámico del software, es otro

problema. Observando el código o la documentación no
podemos evaluar este comportamiento.
El comportamiento dinámico es evaluado mediante

testing*, mediante la ejecución del software.
* Vamos a tener un overload del término “testing"

Durante el testing, el comportamiento del software se

compara con el comportamiento esperado.
El testing contribuye a reducir los riesgos en el uso del

software.
Durante el testing, el comportamiento del software se

compara con el comportamiento esperado.
El testing contribuye a reducir los riesgos en el uso del

software.
El testing y su documentación pueden ser requeridos por

contrato o como parte de standards legales o industriales.
Fundamentos
Fundamentos deldel
Testing de Software
Testing de Software
Terminología del Testing

Una situación se puede clasificar como incorrecta, sólo

cuando sabemos qué es lo correcto.
Un fracaso, es el no cumplimiento de un requerimiento. Es

decir, una discrepancia entre un valor o comportamiento
actual y uno esperado.
Los requerimientos son fundamentales en el proceso de

testing. Sin requerimientos, es muy limitado el tipo de
testing que podemos hacer.
Ciertos tipos de métodos de testeo dependen de cómo

fueron realizados los requerimientos (testing formal).
El fracaso cubre aspectos no funcionales. Un software que

es muy difícil de usar o muy lento (pero funcionalmente
están bien), se consideran un fracaso.
En software, una falla lleva al fracaso. Sinónimos de falla

son, defecto o bug.
Mark II, 1947

Mark II, 1947

Una falla existe porque fue programada originalmente, o a

partir de un cambio realizado.
Una falla aparece cuando se ejecuta el software,

produciendo un fracaso.
En IEEE Standard Glossary of Software Engineering se

describe el fracaso como el evento que ocurre cuando el
usuario experimenta problemas con el software.
En general, también se usan los términos problema o

incidente.
Es posible que una falla se encuentre oculta por una o más

fallas. Esto se conoce como enmascaramiento de defectos.
Es posible que una falla se encuentre oculta por una o más

fallas. Esto se conoce como enmascaramiento de defectos.
Un problema interesante es que una falla puede causar

uno, muchos o ningún fracaso.
La falla y el fracaso pueden estar a una distancia arbitraria

entre sí.
Testing no es debugging. Para corregir una falla, debemos

localizarla en el código. El Testing sólo nos permite saber
qué efecto tiene la falla.
La localización y corrección de una falla, es el debugging.

Cada ejecución que se hace, con el objetivo de analizar el

resultado, es un testing. Las condiciones en las que se da
el test deben ser definidas. El comportamiento esperado
debe ser conocido, y comparado con el actual. Todo el
proceso debería ser documentado.
El testing de software puede tener varios propósitos:

Encontrar fallas
Medir calidad
Aumentar la confianza
Analizar el programa o su documentación
Se define como objeto de test, al elemento que estamos

testeando.
La ejecución de un objeto de test se realiza con datos de
test.
La administración de los test incluye el planeamiento,

implementación, documentación y análisis del testing.
El proceso de testing incluye a la administración de los

test.
Se define como suite de test a la ejecución de uno o más

casos de test.
Un caso de test contiene el objeto de test, condiciones de

ejecución, parámetros de entrada y salida esperada.
La concatenación de casos de test, de modo que la

entrada de un test sea la salida del anterior forman un
escenario de test.
Un ejemplo
Un ejemplo
Un ejemplo
Probar este
programa en forma
exhaustiva significa
probar cada
posibilidad de
camino.
Un ejemplo
Si consideramos 1
iteración del bucle,
tenemos 5 posibles
caminos.
Un ejemplo
Si consideramos 2
iteración del bucle,
tenemos 25 posibles
caminos.
51*51 = 52 = 25
Un ejemplo
Si consideramos 20
iteraciones del
bucle, tenemos
estos posibles
caminos.
520*519*...*52*51
Un ejemplo
Si consideramos 20
iteraciones del
bucle, tenemos
estos posibles
caminos.
520 = 9.5367432e+13
Un ejemplo
Si los test se
hicieran en forma
manual, a 5 minutos
por test. Se tardaría
mil millones de
años.
Un ejemplo
Si los test se
hicieran en 5
microsegundos por
test. Se tardarían 19
años.
El tiempo/esfuerzo/presupuesto dedicado al testing varía

enormemente de proyecto a proyecto.
El tiempo/esfuerzo/presupuesto dedicado al testing varía

enormemente de proyecto a proyecto.
La decisión de ¿hasta dónde llegar con el testing?

depende del análisis de riesgos del proyecto de software.
Probabilidad de que ocurra un error + Impacto del error

Todo proyecto tiene recursos limitados. Y cada recurso

debe ser obtenido mediante negociaciones o peleas.
En muchos casos, la ventana de tiempo dedicada al testing

es pequeña, al final del desarrollo (a días de la entrega) y
con poco personal.
Testing en el Proceso de Desarrollo de Software
Testing en el Proceso de
Desarrollo de Software
El primer modelo de desarrollo de software fue el modelo

de Cascada.
Royce, W. W.: "Managing the development of large software systems", IEEE WESCOM, Aug. 1970, pp. 1-9.
Testing en el Proceso de Desarrollo de

Software
Requerimientos
de Sistema
Requerimientos
de Software
Análisis
Diseño
Desarrollo
Uso
Testing en el Proceso de Desarrollo de
Software
Requerimientos
de Sistema
Requerimientos
de Software
Análisis
Diseño
Desarrollo
Testing
Uso
Una variante del modelo de cascada es conocida como

Modelo V, y da una mejor integración al proceso de testing.
Boehm, B. W.: "Guidelines for Verifying and Validation Software Requirements and Design Specifications",
Proceedings of Euro IFIP 1979, pp. 711-719

Requerimientos
de Software
Diseño
Preliminar
Diseño
Detallado
Codificación

Requerimientos Test de
de Software Sistema
Diseño Test de
Preliminar Integración
Diseño
Test de Unidad
Detallado
Codificación
Planificación
Planificación
de Software Sistema Deployment
Planificación
Diseño Test de
Mantenimiento
Diseño
Test de Unidad
Detallado
Codificación
El testing del software contribuye a mejorar la calidad del

software. También permite medir esta misma calidad.
Los aspectos de calidad que pueden ser evaluados

mediante testing son:
Funcionalidad - Seguridad - Confiabilidad - Usabilidad -

Eficiencia - Portabilidad - Mantenibilidad
La correctitud absoluta no puede alcanzarse por medio de

testing.
Principios del Testing


Testing shows the presence of defects, not their absence

Exhaustive testing is not possible


Testing activities should start as early as possible


Defects tend to cluster together


The pesticide paradox


Test is context dependent


Test is context dependent
The fallacy of assuming that no failures means a useful system

Contenido de la Materia
¿qué vamos a ver?
Bases de la VyV
Testing Orientado a Objetos
Testing de Componentes y Servicios Web
Testing Formal
Gestión del Testing
Testing de Performance, Sistemas Embebidos y Usabilidad

RESUMEN
RESUMEN
Verificación: ¿Construimos
el mouse correctamente?
Validación: ¿Hicimos el
mouse que el cliente quería?
RESUMEN
Un ejemplo
Si los test se
hicieran en 5
microsegundos por
test. Se tardarían 19
años.
RESUMEN
Planificación
Planificación
de Software Sistema Deployment
Planificación
Diseño Test de
Mantenimiento
Diseño
Test de Unidad
Detallado
Codificación
RESUMEN
Contenido de la Materia
¿qué vamos a ver?
Bases de la VyV
Testing Orientado a Objetos
Testing de Componentes y Servicios Web
Testing Formal
Gestión del Testing
Testing de Performance, Sistemas Embebidos y Usabilidad

PRUEBAS
VERIFICACIÓN Y
VALIDACIÓN DE
SOFTWARE
2019-II

PVVS-Clase 01-Introduccion

Cargado por

Copyright:

Formatos disponibles

PVVS-Clase 01-Introduccion

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PVVS-Clase 01-Introduccion

Cargado por

Copyright:

Formatos disponibles

PRUEBAS

"¿Estamos construyendo correctamente el producto?

"¿Estamos construyendo el producto correcto?

• Debido a la urgencia de entregas de un producto de software, es una

• En general, sólo se prueban algunos casos ejemplo para observar si los

• Esto implica una pobre confianza en el producto de

La verificación y validación no puede hacerse en base a

La verificación y validación no puede hacerse en base a

Tanto el proceso de desarrollo de software, como los

La verificación y validación no puede hacerse en base a

Tanto el proceso de desarrollo de software, como los

El proceso de verificación debe ser verificado.

La actividad debe realizarse en momentos diferentes con

Quien desarrolla su producto, no debería verificar su

La presencia de defectos en el software complejo no puede

En la práctica, la correctitud es relativa.

El mito dice que si somos buenos programadores, no

Hay bugs, dice el mito, porque somos malos

La producción de software, como cualquier actividad

Fundamentos del Testing de

Durante la construcción de cualquier producto, sus partes y

Durante la construcción de cualquier producto, sus partes y

Se debe determinar si el producto resuelve las tareas

Durante la construcción de cualquier producto, sus partes y

Se debe determinar si el producto resuelve las tareas

Si el producto exhibe problema, se deben realizar las

Esta idea general que describe la construcción de

Sin embargo, la evaluación de productos parciales o

La evaluación de un software es más difícil porque un

La única forma de examinar directamente el software es

El comportamiento dinámico del software, es otro

El comportamiento dinámico es evaluado mediante

* Vamos a tener un overload del término “testing"

Durante el testing, el comportamiento del software se

El testing contribuye a reducir los riesgos en el uso del

Durante el testing, el comportamiento del software se

El testing contribuye a reducir los riesgos en el uso del

El testing y su documentación pueden ser requeridos por

Terminología del Testing

Una situación se puede clasificar como incorrecta, sólo

Un fracaso, es el no cumplimiento de un requerimiento. Es

Los requerimientos son fundamentales en el proceso de

Ciertos tipos de métodos de testeo dependen de cómo

El fracaso cubre aspectos no funcionales. Un software que

En software, una falla lleva al fracaso. Sinónimos de falla

Mark II, 1947

Mark II, 1947

Una falla existe porque fue programada originalmente, o a

Una falla aparece cuando se ejecuta el software,

En IEEE Standard Glossary of Software Engineering se

En general, también se usan los términos problema o

Es posible que una falla se encuentre oculta por una o más

Es posible que una falla se encuentre oculta por una o más

Un problema interesante es que una falla puede causar

La falla y el fracaso pueden estar a una distancia arbitraria

Testing no es debugging. Para corregir una falla, debemos

La localización y corrección de una falla, es el debugging.

Cada ejecución que se hace, con el objetivo de analizar el

El testing de software puede tener varios propósitos: