Pruebas del softwareGladys Rodriguez
domingo, 12 de agosto de 2012
sábado, 28 de julio de 2012
viernes, 27 de julio de 2012
Pruebas:
concepto y objetivos
Objetivos
de las pruebas
Encontrar defectos en el software
Una prueba tiene éxito si descubre un defecto
Una prueba fracasa si hay defectos pero no los descubre
Pruebas
de Verificación
Ver si cumple las especificaciones de diseño
Pruebas
de Validación
Ver si cumple los requisitos del análisis
Pruebas del Software
El proceso de pruebas del
software tiene dos objetivos:
1. Demostrar al
desarrollador y al
cliente que el software satisface sus requerimientos.
Para el software a medida, significa que debe haber al menos una prueba
para cada requerimiento del sistema y del usuario.
Para software genérico, significa que debe haber pruebas para todas las
características del sistema que se incorporarán en la entrega del producto.
Este objetivo conduce a las pruebas de validación => se espera
que el sistema funcione correctamente usando un conjunto determinado de casos
de prueba que reflejan el uso esperado de aquél.
2. Descubrir
defectos en el software: que su comportamiento es incorrecto, no deseable o no
cumple su especificación.
La prueba de defectos está relacionada con la eliminación de todos los
comportamientos no deseables.
Ej: caídas del sistema, interacciones no permitidas con otros sistemas,
cálculos incorrectos y corrupción de datos.
Este objetivo conduce a la prueba de defectos, cuando los
casos de prueba se diseñan para exponer los defectos.
Modelo del Proceso de Pruebas del
Software
img
Pruebas
de “caja blanca”
Concepto
y terminología
Pruebas en que se conoce el código a probar
Caja blanca (clear box: caja clara o transparente)
Se procura ejercitar cada elemento del código
Algunas
clases de pruebas
Pruebas de cubrimiento
Pruebas de condiciones
Pruebas de bucles
Pruebas de cubrimiento
Ejecutar
al menos una vez cada sentencia
Se
necesitan varios casos de prueba
Determinar posibles “caminos” independientes
Cada condición debe cumplirse en un caso y en otro no. En general, se
necesitan tantos casos como condiciones, más uno (número ciclomático)
Puede
ser imposible cubrir el 100%
Código que nunca se ejecuta: condiciones imposibles
Ejemplo: detección y notificación de errores internos en un código sin
errores
Pruebas de condiciones
Cumplir
o no cada parte de cada condición
Se
necesitan varios casos de prueba
Determinar expresiones simples en las condiciones
Una por cada operando lógico o comparación
Cada expresión simple debe cumplirse en un caso y en otro no, siendo
decisiva en el resultado
Puede
ser imposible cubrir el 100%
Expresiones simples no independientes
Pruebas de bucles
Conseguir
números de repeticiones especiales
Bucles
simples
Repetir cero, una y dos veces
Repetir un número medio (típico) de veces
Repetir el máximo-1, máximo y ¡máximo +1!
Bucles
anidados
Repetir un número medio (típico) los bucles internos, el mínimo los
externos, y variar las repeticiones del bucle intermedio ensayado.
Ensayarlo con cada nivel de anidamiento
Pruebas de “caja negra”
Concepto
y terminología
Pruebas en que se conoce sólo la interfaz
Caja negra (black box: caja opaca)
Se procura ejercitar cada elemento de la interfaz
Algunas
clases de pruebas
Cubrimiento ® invocar todas las funciones (100%)
Clases de equivalencia de datos
Pruebas de valores límite
Pruebas de valores límite
Complemento
a las particiones de equivalencia
Varios
casos de prueba por cada partición
Valores típicos, intermedios
Valores primero y segundo del rango
Valores penúltimo y último
Valores vecinos fuera del rango (en otra partición)
Motivación
l
Los programadores se equivocan con más frecuencia al tratar los
valores en la frontera (Ej: > en vez de ³)
Estrategias
de prueba del software
Contenido
Pruebas de unidades
Pruebas de integración
Pruebas de regresión
Pruebas de validación
Pruebas sin estrategia
Motivación
Las pruebas son incómodas
La pruebas son aburridas
“Estoy seguro de que lo he codificado bien”
Probar
todo junto, al final - Big-Bang
Falla por todas partes
Muy difícil diagnosticar las causas de los fallos
Muy costoso de arreglar
Resultado ® productos finales defectuosos
Actividades
de prueba de software
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.
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.
La principal dificultad que surge en las pruebas de integración es
localizar los errores.
Hay interacciones complejas entre los componentes del sistema, y cuando se
descubre una salida anómala, es difícil identificar dónde ha ocurrido el error.
Para facilitar la localización de errores, debería utilizarse una
aproximación incremental para la integración y pruebas del sistema.
Inicialmente, debería integrarse una configuración del sistema mínima y
probar este sistema.
A continuación, deberían añadirse componentes a esta configuración mínima y
probar después de añadir cada incremento.
Pruebas de regresión
Repetir
las pruebas tras cada modificación
Repetir sólo pruebas de verificación
Pruebas de unidades
Pruebas de integración
Conservar y actualizar los programas de prueba
Usar herramientas de ejecución automática de las pruebas
Cuando se integra un
nuevo incremento, hay que volver a
ejecutar las pruebas para incrementos previos, así como las nuevas pruebas
requeridas para verificar la nueva funcionalidad del sistema.
Volver a ejecutar un
conjunto existente de pruebas se denomina pruebas de regresión.
Si las pruebas de
regresión nos muestran problemas, entonces hay que verificar si éstos son
problemas en el incremento previo o si son debidos al incremento añadido de
funcionalidad.
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.
Comprobar
que se satisfacen los requisitos
Se usan la mismas técnicas, pero con otro objetivo
No hay programas de prueba, sino sólo el código final de la aplicación
Se prueba el programa completo
Uno o varios casos de prueba por cada requisito o caso de uso
especificado
Se prueba también rendimiento, capacidad, etc. (y no sólo resultados
correctos)
Pruebas alfa (desarrolladores) y beta (usuarios).
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.
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.
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.
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.
Diseño de casos de prueba
El diseño de casos de prueba es parte de las pruebas de componentes y
sistemas.
Consiste en diseñar los casos de prueba (entradas y salidas esperadas) para
probar el sistema.
El objetivo es crear un conjunto de casos de prueba que sean efectivos
descubriendo defectos en los programas y muestren que el sistema satisface sus
requerimientos.
Para diseñar un caso de
prueba, se selecciona una característica del sistema o componente que se está
probando.
Pruebas basadas en requerimientos
Un principio general es que los requerimientos deben poder probarse.
Los requerimientos deberían ser escritos para que se pueda diseñar una
prueba y un observador pueda comprobar que los mismos se satisfacen.
En las pruebas basadas en requerimientos el usuario considera cada
requerimiento y deriva un conjunto de pruebas para cada uno de ellos.
Automatización de las Pruebas
Las pruebas son una fase cara y laboriosa del proceso del software.
Estas herramientas ofrecen una serie de facilidades y pueden reducir mucho
los costos de las pruebas.
Ya vimos las pruebas de regresión.
Cada prueba individual se puede implementar como un objeto y un ejecutador
de pruebas ejecuta todas las pruebas.
Las pruebas deben escribirse para que indiquen si el sistema probado
funciona como se esperaba.
1. Gestor de
pruebas. Gestiona la ejecución de las pruebas del programa.
Mantiene un registro de los datos de las pruebas, resultados esperados y
facilidades probadas del programa.
2. Generador de
datos de prueba. Genera datos de prueba para el programa a probar.
Se logra seleccionando datos de una base de datos o utilizando patrones
para generar datos aleatorios.
3. Oráculo. Predice resultados esperados de las
pruebas.
Pueden ser versiones previas del programa o sistemas de prototipos.
Las pruebas back-to-back implican ejecutar el oráculo y el
programa a probar, en paralelo.
Las diferencias entre sus salidas son resaltadas.
4. Comparador de
ficheros. Compara los resultados de las pruebas del programa
con los resultados de pruebas previas e informa de las diferencias entre ellos.
Se utilizan en pruebas de regresión, donde se comparan los resultados de
ejecutar diferentes versiones.
5. Generador de
informes. Proporciona informes y facilidades de generación
para los resultados de las pruebas.
6. Analizador
dinámico. Añade código a un programa para contar el número
de veces que se ha ejecutado cada sentencia.
Después de las pruebas, se genera un perfil de ejecución que muestra
cuántas veces se ha ejecutado cada sentencia del programa.
7. Simulador. Hay varios tipos de simuladores.
Los simuladores de la
máquina objetivo simulan la máquina sobre la que se ejecuta el programa
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.
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
Suscribirse a:
Comentarios (Atom)