Pruebas de software

Pruebas De Software - Presentation Transcript
1. PRUEBAS DE SOFTWARE Control de Calidad del Software
2. Pruebas de Unidad
o Í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”.
o 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!
o A todas las pruebas se les debería poder hacer un seguimiento hasta los
requisitos de los clientes (trazabilidad ) .
o Las pruebas deberían planificarse antes de que empiecen.
o El principio de Pareto es aplicable a la prueba del software (“donde hay
un defecto, hay otros”) .
o Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo
grande”.
o No son posibles las pruebas exhaustivas.
o Para ser más efectivas, las pruebas deberían ser conducidas por un
equipo independiente.
o Se deben evitar los casos de prueba no documentados ni diseñados con
cuidado.
o 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.
o 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.
o Las pruebas de unidad se concentran en la lógica del procesamiento
interno.
o Este tipo de prueba se puede aplicar en paralelo a varios componentes.
5. Pruebas de Integración
o “ Si todo funciona bien individualmente, ¿por qué dudan que funcione
cuando se une?
o 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.
o 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.

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
o 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.
o La prueba se concentra en las acciones visibles para el usuario y en la
salida del sistema que éste puede reconocer.
o 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.
o Criterios de la prueba de validación
o La validación del software se logra mediante una serie de pruebas que
demuestren que se cumple los requisitos.
o 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.
o Después de que se ha dirigido cada caso de prueba de validación, existirá
dos condiciones posibles:
o 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.
o Revisión de la configuración
o Es un elemento importante del proceso de validación.
o 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
o 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.
o Estas pruebas están más allá del alcance del proceso del software y no las
realizan únicamente los ingenieros de software.
o 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.
o Prueba de seguridad
o La interrupción abarca un amplio rango de actividades: hackers
o La prueba de seguridad comprueba que los mecanismos de protección
integrados en el sistema realmente lo protejan de irrupciones
inapropiadas.
o 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)
o Uso de una lista de chequeo preestablecida (ver (Pressman 98), p.319):

o 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?
 ...
o 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?
 ...
o 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?
o Prueba de resistencia
o Las pruebas de resistencia están diseñadas para confrontar los programas
con situaciones anormales.
o La prueba de resistencia ejecuta un sistema de tal manera que requiera
una frecuencia o un volumen anormal de recursos
o La persona que aplica la prueba tratará de sobrecargar el programa.
o Una variante de la prueba de resistencia es una técnica denominada
prueba de sensibilidad.
o Las pruebas de sensibilidad tratan de descubrir combinaciones de datos
dentro de las clases de entrada válidas que causen inestabilidad o
procesamiento inapropiado.
o Prueba de desempeño
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.
o 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.
o 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
o 1. Prueba de unidad: es la prueba de cada módulo, que normalmente
realiza el propio personal de desarrollo en su entorno
o 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

o 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.
o 4. Prueba del sistema: el sw. ya validado se integra con el resto del
sistema (rendimiento, seguridad, recuperación y resistencia)
o 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)
16. TÉCNICAS DE PRUEBA DEL SOFTWARE
17. Pruebas de Caja Negra y Caja Blanca
o Hay dos maneras de probar cualquier producto construido:
o 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)
o 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)
o Las pruebas de caja negra son las que se aplican a la interfaz del
software.
o 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.
o La prueba de caja blanca del software se basa en un examen cercano al
detalle procedimental.
o 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.

Pruebas de software

Más contenido relacionado

La actualidad más candente (20)

Destacado (6)

Similar a Pruebas de software (20)

Pruebas de software