Date post: | 05-Mar-2015 |
Category: |
Documents |
Upload: | agota-ledo |
View: | 30 times |
Download: | 5 times |
INTRODUCCIÓN A LAVERIFICACION
YVALIDACION
Verificación y Validación
Objetivos Introducir los conceptos de :
– verificación del proceso de software.– validación del producto de software.
Describir las fases del proceso de pruebas.
Explicar la importancia de la planificación de las pruebas.
Describir estrategias complementarias de prueba.
Verificación y Validación
Tópicos El proceso de prueba. Planificación de las pruebas. Estrategias de prueba.
Verificación: ”El producto se esta construyendo en
forma correcta ?" El proceso de desarrollo debe estar
conforme con sus sus estándares o prácticas de desarrollo.
Cómo Verificar ? Qué caraterísticas del proceso de
desarrollo se deben verificar ?
Verificación v/s Validación
Verificación v/s Validación
Validación "Se esta construyendo el producto correcto?" El software debe hacer lo que el usuario
requiere, debe haber concordancia con :– la especificación de requisitos.– La satisfacción de necesidades del cliente.
¿Cómo ? ¿Qué características del software debemos
validar? ¿Podemos ?
Introducción Conceptos relacionados
Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto.
Casos de Pruebas: un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular.
Defecto (bug): un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.
Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.
Cubre todo el ciclo de vida V & V debe aplicarse en cada fase del
proceso de software
Tiene dos objetivos principales El descubrimiento de defectos en el sistema. El aseguramiento de que el sistema será útil
o no, en una determinada situación operacional
El proceso V & V
Objetivos y/o recomendaciones Las pruebas deben centrarse en dos objetivos (es
habitual olvidar el segundo): Probar si el software no hace lo que debe hacer. Probar si el software hace lo que no debe hacer, es
decir, si provoca efectos secundarios.
No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas.
Objetivos y/o recomendaciones El programador debe evitar probar sus propios programas,
ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas.
Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos.
Cada caso de prueba debe definir el resultado de salida esperado.
Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados
Objetivos y/o recomendaciones La experiencia parece indicar que donde hay
un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto.
Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.
Permite revelar la presencia de errores, no su ausencia.
Una prueba exitosa consiste en detectar síntomas de la presencia de uno o mas errores.
Prueba de programas
Técnicas de diseño de pruebas Imposibilidad de Prueba Exhaustiva del
Software: Se deben seguir determinados criterios para
seleccionar los casos de prueba Objetivo Técnicas Diseño de Pruebas:
Garantizar con el mayor grado de confianza posible en que se detectarán los defectos del software.
Equilibro entre Recursos y Garantía para descubrir los defectos existentes
Técnicas de diseño de pruebas
Existen dos enfoques clásicos:
1. El enfoque estructurado o de caja blanca.
2. El enfoque funcional o de caja negra.
Prueba de defectos Pruebas diseñadas para descubrir defectos
en el sistema. Un prueba de defectos exitosa es aquella
que revela la presencia de defectos en el sistema.
Algunos tipos de pruebas
La prueba de defectos y la depuración son distintos procesos.
La prueba de defectos se refiere a la confirmación de la presencia de errores.
La depuración se refiere a la localización y reparación de estos errores.
Prueba y depuración
El proceso de depuración
Locateerror
Designerror repair
Repairerror
Re-testprogram
Pruebas de Unidad prueba de componentes individuales
Prueba de Módulo prueba de conjuntos de componentes dependientes
Prueba de sub-sistemas ( Integración ) prueba de colecciones de módulos integrados en sub-
sistemas Prueba del sistema
prueba del sistema completo. Prueba de aceptación
pruebas de los usuarios para verificar que el sistema cumple con los requerimientos.
Llamado en ocasiones prueba alfa.
Fases de prueba
El proceso de pruebas
Sub-systemtesting
Moduletesting
Unittesting
Systemtesting
Acceptancetesting
Componenttesting
Integration testing Usertesting
Describe las fases principales del proceso de pruebas.
Describe el seguimiento de las pruebas a los requerimientos.
Estimar la planificación general y la necesidad de recursos.
Describir el método usado para archivar los resultados de las pruebas
Planificación de las pruebas
El plan de pruebas
El proceso de pruebas. El seguimiento (traceability) de los
requerimientos. Componentes probados. El calendario de las pruebas. Los procedimientos para archivar pruebas. Los requerimientos del hardware y software. Las restricciones.
El modelo Clásico
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand tess
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
ServiceAcceptance
testSystem
integration testSub-system
integration test
Algunas Estrategias de prueba
Las estrategias de pruebas son formas de enfocar el proceso de pruebas
Distintas estrategias pueden aplicarse para las distintas fases del proceso de pruebas
Estrategias consideradas Pruebas top-down Pruebas bottom-up Prueba de estres
Prueba incremental
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence1
Test sequence2
Test sequence3
Prueba top-down
Level 2Level 2Level 2Level 2
Level 1 Level 1Testing
sequence
Level 2stubs
Level 3stubs
. . .
Prueba top-down
Comienza con los altos niveles del sistema y sigue hacia los niveles inferiores.
Es una estrategia de pruebas que es usada junto con el desarrollo denominados “top-down”
Pruebas “bottom-up”
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
Pruebas bottom-up
Son necesarias para componentes críticos. Comienza con los niveles inferiores y se
mueven hacia los niveles superiores del sistema.
Solo encuentra problemas de diseño hasta muy avanzado el proceso.
Ejercita el sistema mas allá de los limites de carga del sistema.
Esta prueba causa que los defectos surjan. Al estresar el sistema se prueba el
comportamiento frente a fallas (tolerancia). La prueba de estrés verifica pérdidas
inaceptables de servicio o datos. Particularmente relevante en sistemas
distribuidos que presentan una degradación severa cuando la red se sobre carga.
Prueba de estres
Resumen
Verificación y validación no son lo mismo.
Las pruebas son usadas para establecer la presencia de defectos.
Las actividades necesarias en las pruebas son prueba de unidades, prueba de módulos, prueba de sub-sistemas, prueba de integración y prueba de aceptación.
Resumen
Las pruebas deben ser planificadas como parte del proceso de planeación. Deben estar disponibles los recursos necesarios
Deben diseñarse planes de pruebas para guiar el proceso de pruebas
Las estrategias de pruebas son : pruebas top-down, pruebas bottom-up, pruebas de estrés, entre otras.