1. PRUEBAS DE SOFTWARE Control de Calidad del Software.
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
coste 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 incrementa (enfoque “bigbang”),
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 , GraphicalUser Interface) Uso de una
lista de chequeo preestablecida (ver (Presuman 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).
MUCHAS GRACIAS!!!
ResponderEliminar