2. Pruebas de Unidad
Índice de la fiabilidad del software:
se comporta de acuerdo a las especificaciones y requisitos de
rendimiento.
“La prueba no puede asegurar la ausencia de defectos: sólo puede
demostrar que existen defectos en el software”.
No es una actividad secundaria:
30-40% del esfuerzo de desarrollo
En aplicaciones críticas (p.ej. control de vuelo, reactores nucleares),
¡de 3 a 5 veces más que el resto de pasos juntos de la ingeniería del
software!
El costo aproximado de los errores del software (bugs) para la
economía americana es el equivalente al 0,6% de su PIB, unos 60.000
millones de dólares
¡Evitar bichos puede ser un gran negocio!
3. Pruebas de Unidad
A todas las pruebas se les debería poder hacer un seguimiento
hasta los requisitos de los clientes (trazabilidad).
Las pruebas deberían planificarse antes de que empiecen.
El principio de Pareto es aplicable a la prueba del software (“donde
hay un defecto, hay otros”).
Las pruebas deberían empezar por “lo pequeño” y progresar hacia
“lo grande”.
No son posibles las pruebas exhaustivas.
Para ser más efectivas, las pruebas deberían ser conducidas por
un equipo independiente.
Se deben evitar los casos de prueba no documentados ni
diseñados con cuidado.
No deben realizarse planes de prueba suponiendo que
prácticamente no hay defectos en los programas y, por tanto,
dedicando pocos recursos a las pruebas.
4. Pruebas de Unidad
Se concentra en el esfuerzo de verificación de la
unidad más pequeña del diseño del software: el
componente o módulo del software.
Las pruebas de unidad se concentran en la
lógica del procesamiento interno.
Este tipo de prueba se puede aplicar en paralelo
a varios componentes.
5. Pruebas de Integración
“Si todo funciona bien individualmente, ¿por qué dudan
que funcione cuando se une?
La prueba de integración es una técnica sistemática
para construir la arquitectura del software, mientras, al
mismo tiempo, se aplican las pruebas para descubrir
errores asociados con la interfaz.
El objetivo es tomar componentes a los que se aplicó
una prueba de unidad y construir una estructura de
programa que determine el diseño.
A menudo se tiende a intentar una integración que no
sea incremental (enfoque “big bang”), se combinan
todos los componentes por anticipado, se prueba todo el
programa como un todo.
6. Pruebas de Validación
Las pruebas de validación empiezan tras la culminación
de la prueba de integración, cuando se han ejercitado
los componentes individuales. Se ha terminado de
ensamblar el software como paquete y se han
descubierto y corregido los errores de interfaz.
La prueba se concentra en las acciones visibles para el
usuario y en la salida del sistema que éste puede
reconocer.
La validación se define de una forma simple en que se
alcanza cuando el software funciona de tal manera que
satisface las expectativas razonables del cliente
(especificación de requisitos-criterios de validación.
7. Pruebas de Validación
Criterios de la prueba de validación
La validación del software se logra mediante una serie de
pruebas que demuestren que se cumple los requisitos.
Un plan de prueba delinea la clase de pruebas que se
aplicarán y un procedimiento de prueba define los casos de
prueba específicos.
Después de que se ha dirigido cada caso de prueba de
validación, existirá dos condiciones posibles:
1) La característica de funcionamiento o desempeño cumple
con la especificación y se la acepta. 2) se descubre una
desviación de la especificación y se crea una lista de
deficiencias.
8. Pruebas de Validación
Revisión de la configuración
Es un elemento importante del proceso de validación.
So objetivo es asegurar que todos los elementos de la
configuración del software se hayan desarrollado
apropiadamente, estén catalogados y tengan el
detalle suficiente para reforzar la fase de soporte del
ciclo de vida del software.
9. Pruebas del Sistema
Al final del desarrollo el software se incorpora a otros
elementos del sistema (hardware, personas,
información) y se realiza una serie de pruebas de
integración del sistema y de validación.
Estas pruebas están más allá del alcance del proceso
del software y no las realizan únicamente los ingenieros
de software.
Sin embargo, los pasos dados durante el diseño y la
prueba del software mejorarán en gran medida la
probabilidad de tener éxito en la integración del software
del sistema mayor.
10. Pruebas del Sistema
Prueba de seguridad
La interrupción abarca un amplio rango de
actividades: hackers
La prueba de seguridad comprueba que los
mecanismos de protección integrados en el
sistema realmente lo protejan de irrupciones
inapropiadas.
Durante la prueba de seguridad quién la aplica
desempeña el papel del individuo que desea
entrar en el sistema.
11. Prueba de Interfaces Gráficas de Usuario (GUI, Graphical
User Interface)
Uso de una lista de chequeo preestablecida (ver (Pressman 98), p.319):
Para ventanas:
¿Se abrirán las ventanas mediante órdenes basadas en el teclado o en un
menú?
¿Se puede ajustar el tamaño, mover y desplegar la ventana?
¿Se regenera adecuadamente cuando se escribe y se vuelve a abrir?
...
Para menús emergentes y operaciones con el ratón:
¿Se muestra la barra de menú apropiada en el contexto apropiado?
¿Es correcto el tipo, tamaño y formato del texto?
¿Si el ratón tiene varios botones, están apropiadamente reconocidos en el
contexto?
...
Entrada de datos:
¿Se repiten y son introducidos adecuadamente los datos alfanuméricos?
¿Funcionan adecuadamente los modos gráficos de entrada de datos? (p.e. barra
deslizante)
¿Se reconocen adecuadamente los datos no válidos?
¿Son inteligibles los mensajes de entrada de datos?
12. Pruebas del Sistema
Prueba de resistencia
Las pruebas de resistencia están diseñadas para confrontar
los programas con situaciones anormales.
La prueba de resistencia ejecuta un sistema de tal manera
que requiera una frecuencia o un volumen anormal de
recursos
La persona que aplica la prueba tratará de sobrecargar el
programa.
Una variante de la prueba de resistencia es una técnica
denominada prueba de sensibilidad.
Las pruebas de sensibilidad tratan de descubrir
combinaciones de datos dentro de las clases de entrada
válidas que causen inestabilidad o procesamiento
inapropiado.
13. Pruebas del Sistema
Prueba de desempeño
La prueba de desempeño está diseñada para probar el
desempeño del software en tiempo de ejecución dentro
del contexto de un sistema integrado.
La prueba de desempeño se aplica en todos los pasos
del proceso de la prueba, incluso al nivel de la unidad, el
desempeño de un módulo individual debe evaluarse
mientras se realizan las pruebas.
Sin embargo no es sino hasta que se encuentren
totalmente integrados todos los elementos del sistema
que es posible asegurar el verdadero desempeño del
sistema.
14. Resumen
1. Prueba de unidad: es la prueba de cada módulo, que
normalmente realiza el propio personal de desarrollo en su entorno
2. Prueba de integración: con el esquema del diseño del software,
los módulos probados se integran para comprobar sus interfaces en
el trabajo conjunto
3. Prueba de validación: el software totalmente ensamblado se
prueba como un todo para comprobar si cumple los requisitos
funcionales y de rendimiento, facilidad de mantenimiento,
recuperación de errores, etc.
4. Prueba del sistema: el sw. ya validado se integra con el resto del
sistema (rendimiento, seguridad, recuperación y resistencia)
5. Prueba de aceptación: el usuario comprueba en su propio
entorno de explotación si lo acepta como está o no
15. Relación entre productos de desarrollo y niveles de prueba
Requisitos de
usuario
Especificación de
requisitos
Diseño modular
Especificación
lógica del módulo
Pruebas de sistema
Pruebas de integración
Pruebas de unidad
Pruebas de
aceptación
Código(Piattini et al. 96)
18. Pruebas de Caja Negra y Caja
Blanca
Hay dos maneras de probar cualquier producto
construido:
1. Si se conoce la función específica para la que se diseño el producto, se
aplican pruebas, que demuestren que cada función es plenamente
operacional, mientras se buscan los errores de cada función. (Prueba de
Caja Negra)
2. Si se conoce el funcionamiento interno del producto, se aplican pruebas
para asegurarse de que todas las “piezas encajan”, es decir, que las
operaciones internas se realizan de acuerdo a las especificaciones, y que
se han probado todos los componentes internos de manera adecuada.
(Prueba de Caja Blanca)
19. Pruebas de Caja Negra y Caja Blanca
Las pruebas de caja negra son las que se aplican a la
interfaz del software.
Una prueba de caja negra examina algún aspecto
funcional de un sistema que tiene poca relación con la
estructura lógica interna del software.
La prueba de caja blanca del software se basa en un
examen cercano al detalle procedimental.
En la prueba de caja blanca se prueban las rutas
lógicas del software y la colaboración entre
componentes, al proporcionar casos de prueba que
ejerciten conjuntos específicos de condiciones, bucles
o ambos.
