SOFTWARE DE CALIDAD

PRUEBAS DE SOFTWARE
DEFINICIONES
Verificacin:
Es el proceso de evaluacin 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
DEFINICIONES
Validacin:
El proceso de evaluacin 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
DEFINICIONES
Pruebas (test):
Es 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
evaluacin de algn aspecto
DEFINICIONES
Caso de prueba (test case):
Un conjunto de entradas, condiciones de
ejecucin y resultados esperados
desarrollados para un objetivo particular

Defecto (defect, fault, bug):
un defecto en el software como, por
ejemplo, un proceso, una definicin de
datos o un paso de procesamiento
incorrectos en un programa
DEFINICIONES
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.

DEFINICIONES
Error (error): accin humana qe
provoca que un software contenga
una falta



RELACION ENTRE ERROR, DEFECTO Y FALLO
Defecto en el
Software
Error del
programador
Efectos
Negativos en el
Sistema
Fallo en el
Sistema
Se Plasma
Da lugar a
Provoca
IDEAS PARADGICAS DE LAS PRUEBAS


OBJETIVO de las pruebas es la deteccin de
defectos en el software (descubrir un error es el
xito de una prueba)


El descubrimiento de un defecto significa un xito
para la mejora de la calidad.
RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS
Cada caso de prueba debe definir el resultado de salida
esperado que se comparar con el realmente obtenido.

El programador debe evitar probar sus propios programas, ya
que desea (consciente o inconscientemente) demostrar que
funcionan sin problemas.

Adems, es normal que las situaciones que olvid considerar al
crear el programa queden de nuevo olvidados al crear los casos
de prueba

Se debe inspeccionar a conciencia el resultado de cada prueba,
as poder descubrir posibles sntomas de defectos.

Al generar casos de prueba, se deben incluir tanto datos de
entrada vlidos y esperados como no vlidos e inesperados.


RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS

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 debe hacer, es decir,
si provoca efectos secundarios adversos

Se deben evitar los casos desechables, es decir, los no
documentados ni diseados con cuidado.
Ya que suele ser necesario probar muchas veces el
software y por tanto hay que tener claro qu funciona y
qu no

No deben hacerse planes de prueba suponiendo que,
prcticamente, no hay defectos en los programas y, por
lo tanto, dedicando pocos recursos a las pruebas
siempre hay defectos

RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS
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 nmero de defectos ya
descubierto.
Las pruebas son una tarea tanto o ms creativa que el
desarrollo de software.
Siempre se han considerado las pruebas como una tarea
destructiva y rutinaria.
Es interesante planificar y disear las pruebas para
poder detectar el mximo nmero y variedad de
defectos con el mnimo consumo de tiempo y
esfuerzo
ACTIVIDADES DEL PROCESO DE PRUEBA
La depuracin
Localizacin y correccin de defectos

El anlisis de la estadstica de
errores
Sirve para realizar predicciones de la
fiabilidad del software y para detectar las
causas ms habituales de error y por
tanto mejorar los procesos de desarrollo
MTRICAS SOBRE EL PRODUCTO
1. TAMAO ESTIMADO DEL CDIGO
La forma que se ha utilizado
histricamente para estimar el tamao es
contar el nmero de lneas de cdigo.
Con ciertas normas para determinar qu es lo que se
cuenta (lneas de comentario, cdigo incluido, etc.) y
siempre referido a un lenguaje concreto, lo que los
valores nos dan es un valor para, comparando con otros
casos, poder estimar el esfuerzo necesario en futuros
desarrollos.
MTRICAS SOBRE EL PRODUCTO
2. COMPLEJIDAD ESTIMADA .
La idea bsica del mtodo consiste en definir
estimaciones de complejidad para cada una de las
funciones y estimar, dadas las especificaciones del
sistema, cuntos elementos de cada tipo van a ser
necesarios.
Funciones bsicas que suelen aparecer en muchos
sistemas:
Entradas: Pantallas o formatos empleados para introducir
datos a un programa.
Salidas: Pantallas o informes empleados para utilizarlos con
otros programas o para lectura directa .
Consultas: Mecanismos para pedir ayuda o dar rdenes de
ejecucin.
Ficheros de datos: Conjuntos lgicos de informacin
empleados por una aplicacin (ya sean tablas en memoria
como ficheros de disco) junto con los procedimientos de
acceso a los mismos.
Interfaces: Ficheros compartidos con otras aplicaciones

3. Robustez .
Por robustez de un programa se entiende por la
ausencia de fallos en su ejecucin con diferentes
datos de entrada durante intervalos de tiempo
predeterminados.
La robustez de un programa est ligada a la aparicin de
problemas durante su ejecucin.
La importancia de conocer el nmero de fallos encontrados en un
intervalo de tiempo no reside nicamente en obtener un valor
global de la calidad del producto sino en los beneficios derivados
de su anlisis.
Las medidas estadsticas de fiabilidad (tiempo medio entre fallos
encontrados durante la ejecucin, reduccin del nmero de
recopilaciones necesarias, etc.) sirven para alimentar el proceso
de desarrollo.
MTRICAS SOBRE EL PROCESO
Las mtricas mencionadas anteriormente estaban
orientadas a conocer la complejidad del producto (con
algn valor indirecto como el tamao) para poder
estimar los recursos necesarios para su realizacin.

Segn se vayan acumulando datos y se analicen
estadsticamente, las estimaciones sern cada vez
mejores.

Esto nos servir para planificar mejor futuros desarrollos.

Existen otros tipos de datos que se pueden tomar
durante el desarrollo de un producto de software y que
no estn ligados al producto sino a los procesos
implicados. El anlisis de cmo estos procesos se
realizan a partir de medidas tomadas en el desarrollo
es la base para su posterior mejora.

MTRICAS SOBRE EL PROCESO
Algunos de los elementos a medir son:
Distribucin del esfuerzo en cada una de
las fases con objeto de poder estimar los
recursos necesarios.
Obsrvese que esta medida es complementaria a las
de tamao mencionadas anteriormente, aquella nos
permita conocer los recursos globales necesarios,
de lo que se trata aqu es de obtener medidas reales
y utilizarlas en futuros proyectos.

Productividad medida en nmero de lneas
de cdigo documentadas que es capaz de
producir una persona en una unidad de
tiempo.

TIPOS DE PRUEBAS
1. VERIFICACION
Se revisa si el resultado corresponde a
la especificacin del sistema (El sistema
se est construyendo de manera
correcta)
2. VALIDACION
El resultado es realmente lo que el
cliente quiere.




TECNICAS DE PRUEBAS
PRUEBA DE REGRESION
Verificar el sistema despus de haber efectuado cambios

PRUEBA DE OPERACIN
Verificar el sistema en operacin despus por un largo periodo bajo condiciones normales

PRUEBA DE ESCALA COMPLETA
Verificar el sistema en su carga mxima mediante la asignacin de los parmetros en su
valor limite y la interconexin del sistema con un mximo de equipos y usuarios

PRUEBA DE RENDIMIENTO O DE CAPACIDAD
Mide la capacidad de procesamiento del sistema bajo diferentes cargas incluyendo
espacio de almacenamiento y utilizacin de la unidad de procesamiento.
Los valores medidos se componen por los valores requeridos

PRUEBA DE SOBRECARGA
Observa como se comporta el sistema cuando se le aplica una sobrecarga mas all de las
pruebas de escala completa y rendimiento.
TECNICAS DE PRUEBAS
PRUEBA NEGATIVA
Mide el estrs del sistema en situaciones inesperadas, como casos de usos
que normalmente no seran utilizados de forma simultanea.
El sistema se usa intencional y sistemticamente en forma incorrecta.
PRUEBA BASADA EN REQUISITOS O PRUEBA DE CASOS DE USO
Se llevan acabo pruebas basadas directamente en la especificacin de
requisitos.
Pueden utilizarse los mismos casos de usos originales como casos de prueba.
Se trata de verificar las especificaciones funcionales descritas para los casos
de usos originales

PRUEBAS ERGONMICAS
Prueba los aspectos ergonmicos del sistema, es decir las relaciones hombre-
maquina en caso que existan
Ejemplo: Si los men son lgico y legibles, si los mensajes son visibles, si se
puede entender los mensajes de falla, etc.

TECNICAS DE PRUEBAS
PRUEBA DE DOCUMENTACIN DE USUARIO
Prueba la documentacin de usuario, incluyendo el manual de ste y la
documentacin de mantenimiento y servicio.
Se prueba que los manuales y el comportamiento del sistema sean
congruentes entre si, que sean legibles, con buena redaccin y en general que
sean comprensibles.

PRUEBA DE ACEPTACIN O DE VALIDACIN
Pretende lograr una revisin final por parte de la organizacin que solicit el
sistema, lo cual significa validacin del sistema.


NIVELES DE PRUEBA
PRUEBA DE UNIDAD
Solamente se prueba una unidad como tal, como una clase, un paquete de servicio o un
subsistema.
Prueba de especificacin o caja negra
Verifica las relaciones de entradas y salida de una unidad.
Su objetivo es verificar que hace la unidad sin averiguar como lo
hace.

Prueba basada en estado
Verifica las interacciones entre operaciones de una clase segn cambios
en los atributos de un objeto.
No se pueden ver las operaciones de un objeto como aisladas e
independientes de los valores de los atributos.




NIVELES DE PRUEBA
Prueba estructural
Verifica que la estructura de la unidad sea correcta, se conoce como
prueba basada en programa o caja blanca, dado que debe conocerse
como est implementada internamente la unidad
PRUEBA DE INTEGRACIN
Se verifica que las unidades trabajen juntas
correctamente. Se basa principalmente en la prueba
de casos de uso

PRUEBA DE SISTEMA
Verifica el sistema completa o su aplicacin como tal
Pruebas de operacin
Prueba de escala completa
Prueba negativa
Prueba basada en requisitos o prueba de casos de uso
Prueba de documentacin de usuario




PROCESO DE PRUEBAS
1. ESTRATEGIA DE PRUEBAS
Orden de pruebas:
En que momento y en que orden se aplican las pruebas (arriba hacia abajo y de abajo hacia arriba)
Alcance de las pruebas
Se identifica el tipo, numero y casos de prueba que se aplicarn para revisar los diferentes aspectos del sistema
Automatizacin de las pruebas
Tiene como propsito reducir el esfuerzo y costo de las pruebas mediante la automatizacin del proceso o
aspectos de l

2. PLANEACIN DE LAS PRUEBAS
Comienza con el establecimiento de las estrategias de pruebas, lo que incluye la
cuestin si stas se harn automtica o manualmente y si existen programas o datos
de prueba que puedan ser usados, posiblemente modificados o desarrollados de
nueva cuenta

3. CONSTRUCCIN DE LAS PREBAS
Las pruebas deben ser diseadas a nivel funcional donde se describan cada prueba y
su propsito de forma general y detallada.
Se debe describir como se debe ejecutar el caso de prueba

4. EJECUCIN DE LAS PRUEBAS
Ejecutan las pruebas, se reportan y analizan los resultados