INTRODUCCION
El presente trabajo está basado en los principales métodos de prueba de software. Describe los objetivos que se persiguen al realizar la prueba y los principios de la prueba. Un producto puede probarse de acuerdo al conocimiento de la función específica para la que fue diseñado el producto (caja negra). Con la aplicación de esta técnica se adquieren pruebas que disminuyen el numero de casos de prueba. La prueba del método de la caja de cristal frecuentemente es más eficaz para descubrir errores debido a que los programas sutiles ocurren en la interfaz de sub- programas. Estrategias de prueba del software Una estrategia de prueba del software integra los métodos de diseño de caso de pruebas del software en una serie bien planeada de pasos que desembocara en la eficaz construcción de software. La estrategia proporciona un mapa que describe los pasos que se darán como parte de la prueba indica cuando se planean y cuando se dan estos pasos, además de cuanto esfuerzo, tiempo y recursos consumiran. Por tanto, cualquier estrategia de prueba debe incorporar la planeación de pruebas, el diseño de caso de pruebas, la ejecución de pruebas y la recolección y evolución de los datos resultantes. Una estrategia de prueba del software debe ser lo suficionetemente flexible como para promover un enfoque perzonalizado al mismo tiempo debe ser lo adecuadamente rigido como para promover una planeación razonable y un seguimiento administrativo del avanze del proyecto. ¿Qué es? El software se prueba para descrubrir errores cometidos sin darse cuenta al realizar su diseño y construcción. ¿pero como se realizan las pruebas? ¿Debe desarrollarse un plan formal para las pruebas? ¿debe probase el programa como un lodo o solo deben aplicarse pruebas a una parte pequena? ¿deben volver a realizarse las pruebas ejecutadas a medida que se agregan nuevos componentes a un sitemas de gran tamano?
1
¿Cuándo debe pedirse la participación del cliente? Estas y muchas otras preguntas se responderán cuando desarrolle una estrategia de prueba del software. ¿Quién lo hace? El jefe de proyecto, los ingenieros del software o los especialistas en pruebas son quienes desarrollan la estrategia para la prueba del software ¿Por qué es importante? Con frecuencia, la prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniería del software. Si se realiza sin un plan, se desperdicia tiempo se dedica un esfuerzo innecesario y, aun peor, es posible que aun no se detecten errores. Por tanto la razonable seria establecer una estrategia sistemática para probar el software ¿Cuáles son los pasos? La prueba empieza por lo pequeño y avanza hacia lo grande esto significa que en las primeras etapas la prueba se concentra en un solo componente o un grupo pequeño de componentes relacionados y se aplica para descubrir errores en la la lógica de datos y de procesamiento que se a encapsulado en el componente una ves probados los componentes deben integrarse hasta que todo el sistema se haya construido. En este punto se ejecuta una serie de pruebas de alto nivel para descubrir errores en la satisfacción de los requisitos dl cliente a medida que se descubren, lo errores deben diagnosticarse y corregirse empleando un proceso llamado depuración. ¿Cuál es producto obtenido? Una especificación de la prueba documenta el enfoque que aplico el equipo de software a la prueba al definir un plan que detalla una estrategia general y un procedimiento que describe los pasos específicos y se darán en las pruebas que abran de realizarse. ¿Cómo puedo estar seguro de que lo he hecho correctamente? Al revisar la especificación de la prueba antes de realizarla se evalua si están completos los casos y las tareas de prueba. Un plan y un procedimiento de 2
prueba efectivos llevaran a la construcción ordenada del software y al descubrimiento de errores en cada etapa de proceso de costruccion. Una estrategia global
3
Prueba de Unidad El proceso de verificación se centra en la menor unidad de diseño del software.
Se aplica sobre la descripción del diseño procedimental.
Usa técnica de prueba de caja blanca.
Se puede realizar en paralelo para diferentes módulos.
Ámbito de Prueba La interfaz del módulo.
El impacto de los datos globales sobre el módulo.
Las estructuras de datos locales.
Las condiciones límite.
Los caminos de ejecución de la estructura de control.
Los caminos de manejo de errores.
Procedimiento de Prueba
Para cada prueba, se debe desarrollar un software que controle y/o resguarde.
Un controlador es un programa principal que acepta los datos del caso de prueba, pasa los datos al módulo e imprime los resultados.
Un resguardo es un subprograma que reemplaza a los módulos subordinados, realiza alguna manipulación de datos, imprime una verificación de entrada y devuelve el control.
4
La prueba de Integración Es una técnica sistemática para construir la estructura del programa y detectar errores asociados con la interacción.
La integración no incremental no es recomendable.
La integración incremental puede ser descendente o ascendente.
Se necesitan pruebas de regresión.
Integración descendente
5
Los módulos subordinados al módulo de control principal se van incorporando a la estructura primero-en-profundidad, o primero en anchura.
Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los módulos directamente subordinados.
Se sustituyen los resguardos subordinados uno a uno por los módulos.
Se llevan a cabo pruebas cada vez que se integra un módulo.
Tras terminar las pruebas se reemplaza otro resguardo con el módulo real
6
Integración Ascendente Empieza la construcción y la prueba con los módulos atómicos eliminando la necesidad de resguardos.
Se combinan los módulos de bajo nivel en grupos que realicen una sub función específica.
Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba.
Se prueba el grupo. Se eliminan los controladores y combinan los grupos moviéndose hacia arriba por la estructura del programa.
Enfoque combinado
La Prueba de validación 7
Comprueba que el software, una vez ensamblado, funciona de acuerdo con las expectativas razonables del cliente.
Se satisfacen los requerimientos funcionales.
Se alcanzan los requisitos de rendimiento.
La documentación es correcta e inteligible.
Se alcanzan otros requerimientos (compatibilidad, recuperación de errores...)
Usa técnicas de caja negra
Revisión de la configuración Comprobar, para todos los elementos de la configuración del software que:
se han desarrollado apropiadamente,
se han catalogado, y
están suficientemente detallados para soportar la fase de mantenimiento.
Pruebas alfa y Beta Son pruebas de aceptación que permiten que el cliente valide los requisitos.
Las pruebas alfa se llevan a cabo en un entorno controlado.
Las pruebas beta se llevan a cabo en el lugar de trabajo del cliente.
Pueden durar semanas o meses
La Prueba del Sistema El objetivo es verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. La responsabilidad es de todos los creadores de cada uno de los elementos del sistema.
Medidas Preventivas
Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.
Realizar pruebas que simulen datos en mal estado u otros problemas de la interfaz del software. 8
Registrar los resultados de las pruebas.
Participar en la planificación y el diseño de casos de prueba
Tipos de Prueba
Prueba de Recuperación Fuerza el fallo del software de varias formas y verifica que la recuperación se produce adecuadamente.
Si la recuperación es automática hay que evaluar la corrección de la inicialización, de los mecanismos de recuperación del estado del sistema, de la recuperación de los datos y del proceso de rearranque. 9
Si la recuperación no es automática, hay que evaluar los tiempos medios de reparación para determinar si están dentro de unos límites aceptables
Un sistema tolerante a fallos evita que cese el funcionamiento de todo el sistema cuando se produce un fallo del proceso.
Prueba de Seguridad Verifica que los mecanismos de protección incorporados protegerán al sistema.
Intenta conseguir las claves de acceso de cualquier forma.
Ataca con software a medida.
Bloquea el sistema.
Provoca errores del sistema entrando durante su recuperación.
Un sistema que maneje información que pueda afectar de forma inapropiada a las personas es un posible objetivo para entradas ilegales.
Prueba de resistencia Enfrenta al programa con situaciones atípicas, esto es, ejecuta el sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales.
Incrementa las frecuencias de datos de entrada.
Ejecuta casos que requieran el máximo de memoria.
Buscar demasiados datos que residan en disco.
Realiza pruebas de sensibilidad intentando descubrir combinaciones de datos dentro de una clase de entrada válida que pueda producir inestabilidad o un proceso incorrecto
Prueba de Rendimiento Prueban el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado.
Requiere de instrumentación tanto software como hardware para los procesos de monitorización y medición.
Se lleva a cabo durante todos los pasos de prueba.
Los sistemas de tiempo real y los sistemas empotrados se tienen que ajustar a los requisitos de rendimiento.
10
Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de desarrollo, ...).
Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software.
En este capítulo estudiaremos: •
Fundamentos de la prueba del software, que definen los objetivos fundamentales de la fase de prueba.
•
Diseño de casos de prueba, que se centra en un conjunto de técnicas para que satisfagan los objetivos globales de la prueba.
1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE En la etapa de prueba del software se crean una serie de casos de prueba que intentan "destruir" el software desarrollado.
La prueba requiere que se descarten ideas preconcebidas sobre la "calidad o corrección" del software desarrollado.
1.1. Objetivos de la prueba •
La prueba es un proceso de ejecución de un programa con la intención de descubrir un error
•
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces
•
Una prueba tiene éxito si descubre un error no detectado hasta entonces
El objetivo es diseñar casos de prueba que, sistemáticamente, saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de 11
esfuerzo.
La prueba no puede asegurar la ausencia de errores; sólo puede demostrar que existen defectos en el software.
1.2. Proceso de prueba
12
El proceso de prueba tiene dos entradas: •
Configuración del software: Incluye la especificación de requisitos del software, la especificación del diseño y el código fuente
•
Configuración de prueba: Incluye un plan y un procedimiento de prueba
Si el funcionamiento del software parece ser correcto y los errores encontrados son fáciles de corregir, podemos concluir con que: •
La calidad y la fiabilidad del software son aceptables, o que
•
Las pruebas son inadecuadas para descubrir errores serios
1.3. Diseño de casos de prueba Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de tiempo.
Cualquier producto de ingeniería se puede probar de dos formas:
•
Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada función es operativa.
•
Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operación interna se ajusta a las especificaciones, y que todos los componentes internos se han probado de forma adecuada.
En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta.
En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando
los
caminos
lógicos
del
programa,
comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos. 13
A primera vista, la prueba de caja blanca profunda nos llevaría a tener "programas 100 por cien correctos", es decir: •
Definir todos los caminos lógicos
•
Desarrollar casos de prueba para todos los caminos lógicos
•
Evaluar los resultados
Pero esto supone un estudio demasiado exhaustivo, que prolongaría excesivamente los planes de desarrollo del software, por lo que se hará un estudio de los caminos lógicos importantes.
2. PRUEBA DE LA CAJA BLANCA La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.
14
Las pruebas de caja blanca intentan garantizar que: •
Se ejecutan al menos una vez todos los caminos independientes de cada módulo
•
Se utilizan las decisiones en su parte verdadera y en su parte falsa
•
Se ejecuten todos los bucles en sus límites
•
Se utilizan todas las estructuras de datos internas
2.1. Prueba del camino básico El método del camino básico (propuesto por McCabe) permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba que garanticen que cada camino se ejecuta al menos una vez.
2.1.1. Notación del grafo de flujo o grafo del programa Representa el flujo de control lógico con la siguiente notación:
15
A continuación se muestra un ejemplo basado en un diagrama de flujo que representa la estructura de control del programa.
16
En el grafo de flujo •
Cada nodo representa una o más sentencias procedimentales
•
Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una decisión
•
Las flechas (aristas) representan el flujo de control
Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.
Si en el diseño procedimental se utilizan condiciones compuestas, la generación del grafo de flujo tiene que descomponer las condiciones compuestas en condiciones sencillas, tal y como muestra la figura siguiente.
17
2.1.2. Complejidad ciclomática Es una medida que proporciona una idea de la complejidad lógica de un programa. •
La complejidad ciclomática coincide con el número de regiones del grafo de flujo
•
La complejidad ciclomática, V(G), de un grafo de flujo G , se define como V(G) = Aristas - Nodos + 2
•
La complejidad ciclomática, V(G), de un grafo de flujo G , también se define como V(G) = Nodos de predicado + 1
A partir del grafo de flujo de la figura 4, la complejidad ciclomática sería: •
Como el grafo tiene cuatro regiones, V(G) = 4
•
Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 = 4
•
Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4
A partir del valor de la complejidad ciclomática obtenemos el número de caminos independientes, que nos dan un valor límite para el número de pruebas que tenemos que diseñar.
En el ejemplo, el número de caminos independientes es 4, y los caminos independientes son: •
1-11
•
1-2-3-4-5-10-1-11
•
1-2-3-6-7-9-10-1-11
•
1-2-3-6-8-9-10-1-11
2.1.3. Pasos del diseño de pruebas mediante el camino básico •
Obtener el grafo de flujo, a partir del diseño o del código del módulo
•
Obtener la complejidad ciclomática del grafo de flujo
•
Definir el conjunto básico de caminos independientes
•
Determinar los casos de prueba que permitan la ejecución de cada uno de los caminos anteriores
•
Ejecutar cada caso de prueba y comprobar que los resultados son los 18
esperados
2.2. Prueba de bucles Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del software.
La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.
Se pueden definir cuatro tipos de bucles diferentes: •
Bucles simples
•
Bucles concatenados
•
Bucles anidados
•
Bucles no estructurados
19
2.2.1. Bucles simples A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de pruebas siguientes:
•
Saltar el bucle
•
Pasar sólo una vez por el bucle
•
Pasar dos veces por el bucle
•
Hacer m pasos del bucle con m < n
•
Hacer n-1, n y n+1 pasos por el bucle
2.2.2. Bucles anidados Si extendiésemos el conjunto de pruebas de los bucles simples a los bucles anidados, el número de pruebas crecería geométricamente, por lo que Beizer sugiere el siguiente conjunto de pruebas para bucles anidados:
•
Comenzar con el bucle más interno, estableciendo los demás bucles a los valores mínimos
•
Llevar a cabo las pruebas de bucles simples para el bucle más interno, conservando los valores de iteración de los bucles más externos a los valores mínimos
•
Progresar hacia fuera en el siguiente bucle más externo, y manteniendo los bucles más externos a sus valores mínimos 20
•
Continuar hasta que se hayan probado todos los bucles
2.2.3. Bucles concatenados Probar los bucles concatenados mediante las técnicas de prueba para bucles simples, considerándolos como bucles independientes.
2.2.4. Bucles no estructurados Rediseñar estos bucles para que se ajusten a las construcciones de la programación estructurada.
Ejemplo Construir el Grafo de Flujo correspondiente a la siguiente especificación del software en LDP.
21
Solución
22
Ejemplo Construir el Grafo de Flujo correspondiente al siguiente código de un programa
Solución
23
3. PRUEBA DE LA CAJA NEGRA Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que: •
Las funciones del software son operativas
•
La entrada se acepta de forma correcta
•
Se produce una salida correcta
•
La integridad de la información externa se mantiene
A continuación se derivan conjuntos de condiciones de entrada que utilicen todos los requisitos funcionales de un programa.
Las pruebas de caja negra pretenden encontrar estos tipos de errores: •
Funciones incorrectas o ausentes
•
Errores en la interfaz
•
Errores en estructuras de datos o en accesos a bases de datos externas
•
Errores de rendimento
•
Errores de inicialización y de terminación
Los tipos de prueba de cana negra que vamos a estudiar son:
3.1.
•
Prueba de partición equivalente
•
Prueba de análisis de valores límites
Prueba de partición equivalente
Este método de prueba de caja negra divide el dominio de entrada de un programa en clases de datos, a partir de las cuales deriva los casos de prueba.
Cada una de estas clases de equivalencia representa a un conjunto de estados válidos o inválidos para las condiciones de entrada.
24
3.1.1. Identificación de las clases de equivalencia Se identifican clases de equivalencia válidas e inválidas con la siguiente tabla
Condiciones externas
Clases de equivalencia Clases de equivalencia inválidas válidas
25
A continuación se siguen estas directrices:
•
Si una condición de entrada especifica un rango de valores (p.e, entre 1 y 999), se define una CEV (1 <= valor
<= 999) y
dos CEI (valor < 1 y valor > 999) •
Si una CE requiere un valor específico (p.e., el primer carácter tiene que ser una letra), se define una CEV (una letra) y una CEI (no es una letra)
•
Si una CE especifica un conjunto de valores de entrada, se define una CEV para cada uno de los valores válidos, y una CEI (p.e., CEV para "Moto", "Coche" y "Camión", y CEI para "Bicicleta")
•
Si una condición de entrada especifica el número de valores (p.e., una casa puede tener uno o dos propietarios), identificar una CEV y dos CEI (0 propietarios y 3 propietarios)
3.1.2. Identificación de casos de prueba Seguir estos pasos •
•
Asignar un número único a cada clase de equivalencia Escribir casos de prueba hasta que sean cubiertas todas las CEV, intentando cubrir en cada casos tantas CEV como sea posible
•
Para cada CEI, escribir un caso de prueba, cubriendo en cada caso una CEI
Ejemplo Diseñar casos de prueba de partición equivalente para un software que capte estos datos de entrada:
•
Código de área: En blanco o un número de tres dígitos
•
Prefijo: Número de tres dígitos que no comiencen por 0 ó 1
•
Sufijo: Número de cuatro dígitos
•
Ordenes: "Cheque", "Depósito", "Pago factura"
•
Palabra clave: Valor alfanumérico de 6 dígitos 26
