Pruebas del software

Pruebas del Software

Maestrantes:

Gladys María Rodríguez

Domingo Florentino Muñoz

Margarita Cepeda Gómez

Bonao, julio 2012

Introducción a las pruebas del software

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


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


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-8

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-9

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

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

Actividades de desarrollo

Análisis

Diseño

Codificación

Integración

Mantenimiento

P. unidadesDoc. Diseño

Cod. Módulos

P. integración

Cód. Completo

P. validación

Doc. Requisitos


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 unidades

Se prueba cada módulo

Módulo en

pruebas

Programa

de prueba

Otros

módulos

Otros

módulos

Reales o

simulados

(stubs)


Pruebas de Integración

“Si todo funciona bien individualmente, ¿por qué dudan quefuncione cuando se une?

La prueba de integración es una técnica sistemática paraconstruir la arquitectura del software, mientras, al mismotiempo, se aplican las pruebas para descubrir errores asociadoscon la interfaz.

El objetivo es tomar componentes a los que se aplicó unaprueba de unidad y construir una estructura de programa quedetermine el diseño.

A menudo se tiende a intentar una integración que no seaincremental (enfoque “big bang”), se combinan todos loscomponentes por anticipado, se prueba todo el programa comoun 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


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 Regresión


Pruebas de Validación

Las pruebas de validación empiezan tras la culminación de laprueba de integración, cuando se han ejercitado loscomponentes individuales. Se ha terminado de ensamblar elsoftware como paquete y se han descubierto y corregido loserrores de interfaz.

La prueba se concentra en las acciones visibles para el usuarioy en la salida del sistema que éste puede reconocer.

La validación se define de una forma simple en que se alcanzacuando el software funciona de tal manera que satisface lasexpectativas razonables del cliente (especificación derequisitos-criterios de validación.


Pruebas 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.


Pruebas del Sistema

Prueba de seguridad

La interrupción abarca un amplio rango deactividades: hackers

La prueba de seguridad comprueba que losmecanismos de protección integrados en el sistemarealmente lo protejan de irrupciones inapropiadas.

Durante la prueba de seguridad quién la aplicadesempeña el papel del individuo que desea entrar enel sistema.


Pruebas del SistemaPrueba de resistencia

Las pruebas de resistencia están diseñadas para confrontar losprogramas con situaciones anormales.

La prueba de resistencia ejecuta un sistema de tal manera querequiera 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 denominadaprueba de sensibilidad.

Las pruebas de sensibilidad tratan de descubrir combinaciones dedatos dentro de las clases de entrada válidas que causeninestabilidad o procesamiento inapropiado.


Pruebas del Sistema

Prueba de desempeño

La prueba de desempeño está diseñada para probar eldesempeño del software en tiempo de ejecución dentro delcontexto de un sistema integrado.

La prueba de desempeño se aplica en todos los pasos delproceso de la prueba, incluso al nivel de la unidad, eldesempeño de un módulo individual debe evaluarse mientrasse realizan las pruebas.

Sin embargo no es sino hasta que se encuentren totalmenteintegrados todos los elementos del sistema que es posibleasegurar el verdadero desempeño del sistema.


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.

Diseño de casos de prueba


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.

Pruebas basadas en

requerimientos


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.

Automatización de las Pruebas


Banco de Trabajo de Pruebas


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


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 unidad

Pruebas de

aceptación

Código


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 aplicanpruebas, que demuestren que cada función es plenamente operacional, mientras sebuscan los errores de cada función. (Prueba de Caja Negra)

2. Si se conoce el funcionamiento interno del producto, se aplican pruebas paraasegurarse de que todas las “piezas encajan”, es decir, que las operaciones internasse realizan de acuerdo a las especificaciones, y que se han probado todos loscomponentes internos de manera adecuada. (Prueba de Caja Blanca)

Pruebas del software

Documents

Transcript of Pruebas del software