PRUEBAS DEL SOFTWARE "CAJA BLANCA Y CAJA NEGRA"

PRUEBAS DEL SOFTWARE “CAJA BLANCA Y CAJA NEGRA”

ANGELA MOLANO CASTELLANOS (1.053.604.120)

ING. JHON FREDDY MONTES MORA

EVALUACIÓN DEL SOFTWARE

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

ESCUELA DE CIENCIAS BÁSICAS E INGENIERÍA

ING. DE SISTEMAS

COLOMBIA

2008

CONTENIDO

INTRODUCCIÓN

1. MARCO TEÓRICO

1.1 PRUEBA DE CAJA BLANCA

1.2 PRUEBA DE CAJA NEGRA

2. APICACIÓN PRUEBA DE CAJA NEGRA

3. APLICACIÓN PRUEBA DE CAJA BLANCA

CONCLUSIONES

RECOMENDACIONES

BIBLIOGRAFÍA

INTRODUCCIÓN

La fase de pruebas es una de las más costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de productos que forman parte de la aplicación. Obviamente, se aplican diferentes técnicas de prueba a cada tipo de producto software.

Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente. Es probado para descubrir errores cometidos sin darse cuenta al realizar su diseño y construcción La prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniería del software.

El ingeniero crea una serie de casos de prueba que intentan "demoler" el software que ha sido construido. Tiene como objetivos:

1. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.

2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Por lo tanto hay que diseñar pruebas que saque a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. Inclusive tiene como ventaja ver hasta qué punto las funciones parecen funcionar de acuerdo con las especificaciones y cumplir así los requisitos de rendimiento.

Para realizar pruebas efectivas un equipo de software debe efectuar revisiones técnicas formales y efectivas. Esto elimina muchos errores antes de empezar las pruebas. La prueba comienza al nivel de componentes y trabaja “hacia fuera”, hacia la integración de todo el sistema de cómputo. Las pruebas deberían empezar por lo "pequeño" y progresar hacia "lo grande" (módulos). Diferentes técnicas de prueba son apropiadas en diferentes momentos. La prueba la dirige el desarrollador del software y en proyectos grandes un grupo independiente de pruebas. Las pruebas deberían planificarse mucho antes de que empiecen. La prueba y la depuración son actividades diferentes, pero ambas se incluyen en la estrategia de pruebas. A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. No son posibles las pruebas exhaustivas (imposible ejecutar todas las combinaciones de caminos). Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Un error es diseñar y ejecutar pruebas que solamente demuestren el buen funcionamiento del programa en lugar de descubrir errores.

Hay dos maneras de probar cualquier producto:

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.

2. Si se conoce el funcionamiento interno el producto, se aplican pruebas para asegurar que todas las piezas encajen, es decir, que las operaciones internas se realicen de acuerdo con las especificaciones.

El software debe probarse desde dos perspectivas diferentes:

1. La lógica interna del programa utilizando técnicas de diseño de casos de prueba de "caja blanca"

2. Los requisitos del software utilizando técnicas de diseño de casos de prueba de "caja negra"

1. MARCO TEÓRICO

1.1 PRUEBA DE CAJA BLANCA

En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del modulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables), comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno.

Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración).

En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada).

Las pruebas de caja blanca realizan un seguimiento del código fuente según va ejecutando los casos de prueba, de manera que se determinan de manera concreta las instrucciones, bloques, etc. en los que existen errores. Cuando se pasan casos de prueba al programa que se está probando, es conveniente conocer qué porcentaje del programa se ha ejecutado, de manera que estemos próximos a asegurar que todo él es correcto (evidentemente, es imposible alcanzar una certeza del 100%). Existen varias formas de medir la cobertura lograda en el programa por los casos de prueba, algunas de las cuales se presentan en el siguiente epígrafe:

Criterios de cobertura

De acuerdo con (Cornett 2002), el análisis de cobertura del código es el proceso de:

- Encontrar fragmentos del programa que no son ejecutados por los casos de prueba.

- Crear casos de prueba adicionales que incrementen la cobertura.

- Determinar un valor cuantitativo de la cobertura (que es, de manera indirecta, una medida de la calidad del programa).

Adicionalmente, el análisis de cobertura también permite la identificación de casos de prueba redundantes, que no incrementan la cobertura.

1. Cobertura de sentencias: Comprueba el número de sentencias ejecutables que se han ejecutado. Mantenimiento Avanzado de Sistemas de Información – Pruebas del software. Por segmento se entiende una secuencia de sentencias sin puntos de decisión. Como el ordenador está obligado a ejecutarlas una tras otra, es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos.

El número de sentencias de un programa es finito. Basta coger el código fuente e ir contando. Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias, hasta que hayamos pasado por todas, o por una inmensa mayoría.

En la práctica, el proceso de pruebas termina antes de llegar al 100%, pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias.

A la hora de decidir el punto de corte antes de llegar al 100% de cobertura hay que ser precavido y tomar en consideración algo más que el índice conseguido. En efecto, ocurre con harta frecuencia que los programas contienen código muerto o inalcanzable. Puede ser que este trozo del programa, simplemente "sobre" y se pueda prescindir de él; pero a veces significa que una cierta funcionalidad, necesaria, es inalcanzable: esto es un error y hay que corregirlo.

2. Cobertura de decisiones: Comprueba el número de decisiones ejecutadas, considerando que se ha ejecutado una decisión cuando se han recorrido todas sus posible ramas (la que la hace true y la que la hace false, pero también todas las posibles ramas de un switch). Desde el punto de vista de cobertura de segmentos, basta ejecutar una vez, con éxito en la condición, para cubrir todas las sentencias posibles. Sin embargo, desde el punto de vista de la lógica del programa, también debe ser importante el caso de que la condición falle (si no lo fuera, sobra el IF). Sin embargo, como en la rama ELSE no hay sentencias, con 0 ejecuciones tenemos el 100%. Para afrontar estos casos, se plantea un refinamiento de la cobertura de segmentos consistente en recorrer todas las posibles salidas de los puntos de decisión. Para el ejemplo de arriba, para conseguir una cobertura de ramas del 100% hay que ejecutar (al menos) 2 veces, una satisfaciendo la condición, y otra no. Estos criterios se extienden a las construcciones que suponen elegir 1 de entre varias ramas. Por ejemplo, el CASE. Nótese que si lográramos una cobertura de ramas del 100%, esto llevaría implícita una cobertura del 100% de los segmentos, pues todo segmento está en alguna rama. Esto es cierto salvo en programas triviales que carecen de condiciones (a cambio, basta 1 sola prueba para cubrirlo desde todos los puntos de vista). El criterio también debe refinarse en lenguajes que admiten excepciones (por ejemplo, Ada). En estos casos, hay que añadir pruebas para provocar la ejecución de todas y cada una de las excepciones que pueden dispararse.

3. Cobertura de condiciones: Comprueba el número de condiciones ejecutadas, entendiendo que se ha ejecutado una condición cuando se han ejecutado todas sus posibles ramas.

4. Cobertura de condiciones múltiples: Comprueba el número de condiciones múltiples ejecutadas, considerando que se ha ejecutado una condición múltiple cuando se han ejecutado todas sus correspondientes ramas con todas las posibles variantes de la instrucción condicional.

5. Cobertura de condiciones/decisiones: Comprueba el número de condiciones y decisiones que se han ejecutado.

6. Cobertura de caminos: Comprueba el número de caminos linealmente independientes que se han ejecutado en el grafo de flujo de la unidad que se está probando. El número de caminos linealmente independientes coincide con la complejidad ciclomática de McCabe.

7. Cobertura de funciones: Comprueba el número de funciones y procedimientos que han sido llamados.

8. Cobertura de llamadas: Comprueba el número de llamadas a funciones y procedimientos que se han ejecutado. No debe confundirse con la cobertura de funciones: en la cobertura de funciones contamos cuántas funciones de las que hay en nuestro proMantenimiento Avanzado de Sistemas de Información – Pruebas del software grama han sido llamadas, mientras que la cobertura de llamadas cuenta cuántas de las llamadas a funciones que hay en el programa se han ejecutado.

9. Cubrimiento de bucles: Comprueba el número de bucles que han sido ejecutados cero veces (excepto para bucles do -While), una vez y más de una vez. Los bucles no son más que segmentos controlados por decisiones. Así, la cobertura de ramas cubre plenamente la esencia de los bucles. Pero eso es simplemente la teoría, pues la práctica descubre que los bucles son una fuente inagotable de errores, todos triviales, algunos mortales. Un bucle se ejecuta un cierto número de veces; pero ese número de veces debe ser muy preciso, y lo más normal es que ejecutarlo una vez de menos o una vez de más tenga consecuencias indeseables. Y, sin embargo, es extremadamente fácil equivocarse y redactar un bucle que se ejecuta 1 vez de más o de menos. Para un bucle de tipo WHILE hay que pasar 3 pruebas

1. 0 ejecuciones

2. 1 ejecución

3. más de 1 ejecución

Para un bucle de tipo REPEAT hay que pasar 2 pruebas

1. 1 ejecución

2. más de 1 ejecución

Los bucles FOR, en cambio, son muy seguros, pues en su cabecera está definido el número de veces que se va a ejecutar. Ni una más, ni una menos, y el compilador se encarga de garantizarlo. Basta pues con ejecutarlos 1 vez. No obstante, conviene no engañarse con los bucles FOR y examinar su contenido. Si dentro del bucle se altera la variable de control, o el valor de alguna variable que se utilice en el cálculo del incremento o del límite de iteración, entonces eso es un bucle FOR con trampa. También tiene "trampa" si contiene sentencias del tipo EXIT (que algunos lenguajes denominan BREAK) o del tipo RETURN. Todas ellas provocan terminaciones anticipadas del bucle. Estos últimos párrafos hay que precisarlos para cada lenguaje de programación. Lo peor son aquellos lenguajes que permiten el uso de sentencias GOTO. Tampoco conviene confiarse de lo que prometen lenguajes como MODULA-2, que se supone que prohíben ciertas construcciones arriesgadas. Los compiladores reales suelen ser más tolerantes que lo que anuncian los libros. Si el programa contiene bucles LOOP, o simplemente bucles con trampa, la única cobertura aplicable es la de ramas. El riesgo de error es muy alto; pero no se conocen técnicas sistemáticas de abordarlo, salvo reescribir el código.

10. Cubrimiento de carrera: Comprueba el número de tareas o hilos que han ejecutado simultáneamente el mismo bloque de código.

11. Cobertura de operadores relacionales: Comprueba si se han ejecutado los valores límite en los operadores relacionales (>, <, >=, <=), ya que se asume la hipótesis de que estas situaciones son propensas a errores. 12. Cobertura de tablas: Comprueba si se ha hecho referencia a todos los elementos de los arrays.

1.2 PRUEBA DE CAJA NEGRA

También conocidas como Pruebas de Comportamiento, estas pruebas se basan en la especificación del programa o componente a ser probado para elaborar los casos de prueba. El componente se ve como una “Caja Negra” cuyo comportamiento sólo puede ser determinado estudiando sus entradas y las salidas obtenidas a partir de ellas. No obstante, como el estudio de todas las posibles entradas y salidas de un programa sería impracticable se selecciona un conjunto de ellas sobre las que se realizan las pruebas. Para seleccionar el conjunto de entradas y salidas sobre las que trabajar, hay que tener en cuenta que en todo programa existe un conjunto de entradas que causan un comportamiento erróneo en nuestro sistema, y como consecuencia producen una serie de salidas que revelan la presencia de defectos. Entonces, dado que la prueba exhaustiva es imposible, el objetivo final es pues, encontrar una serie de datos de entrada cuya probabilidad de pertenecer al conjunto de entradas que causan dicho comportamiento erróneo sea lo más alto posible. Al igual que ocurría con las técnicas de Caja Blanca, para confeccionar los casos de prueba de Caja Negra existen distintos criterios. Algunos de ellos son:

1. Particiones de Equivalencia: La partición de equivalencia es un método de prueba de Caja Negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. La partición equivalente se dirige a una definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. En otras palabras, este método intenta dividir el dominio de entrada de un programa en un número finito de clases de equivalencia. De tal modo que se pueda asumir razonablemente que una prueba realizada con un valor representativo de cada clase es equivalente a una prueba realzada con cualquier otro valor de dicha clase. Esto quiere decir que si el caso de prueba correspondiente a una clase de equivalencia detecta un error, el resto de los casos de prueba de dicha clase de equivalencia deben detectar el mismo error. Y viceversa, si un caso de prueba no ha detectado ningún error, es de esperar que ninguno de los casos de prueba correspondientes a la misma clase de equivalencia encuentre ningún error. El diseño de casos de prueba según esta técnica consta de dos pasos:

1. Identificar las clases de equivalencia.

2. Identificar los casos de prueba.

2.Análisis de Valores Límite: La experiencia muestra que los casos de prueba que exploran las condiciones límite producen mejor resultado que aquellos que no lo hacen. Las condicione límite son aquellas que se hayan en los márgenes de la clase de equivalencia, tanto de entrada como de salida. Por ello, se ha desarrollado el análisis de valores límite como técnica de prueba. Esta técnica nos lleva a elegir los casos de prueba que ejerciten los valores límite.

Por lo tanto, el análisis de valores límite complementa la técnica de partición de equivalencia de manera que:

- En lugar de seleccionar cualquier caso de prueba de las clases válidas e inválidas, se eligen los casos de prueba en los extremos.

- En lugar de centrase sólo en el dominio de entrada, los casos de prueba se diseñan también considerando el dominio de salida.

Las pautas para desarrollar casos de prueba con esta técnica son:

- Si una condición de entrada especifica un rango de valores, se diseñarán casos de prueba para los dos límites del rango, y otros dos casos para situaciones justo por debajo y por encima de los extremos.

- Si una condición de entrada especifica un número de valores, se diseñan dos casos de prueba para los valores mínimo y máximo, además de otros dos casos de prueba para valores justo por encima del máximo y justo por debajo del mínimo. - Aplicar las reglas anteriores a los datos de salida.

- Si la entrada o salida de un programa es un conjunto ordenado, habrá que prestar atención a los elementos primero y último del conjunto.

3. Métodos Basados en Grafos.

4. Pruebas de Comparación.

5.Análisis Causa-Efecto.

Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.

Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc.) Este comentario no obsta para que sean útiles en cualquier módulo del sistema. Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado.

Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea. El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero).

A la vista de los requisitos de un módulo, se sigue una técnica algebraica conocida como "clases de equivalencia". Esta técnica trata cada parámetro como un modelo algebraico donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, entonces es suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes.

El problema está pues en identificar clases de equivalencia, tarea para la que no existe una regla de aplicación universal; pero hay recetas para la mayor parte de los casos prácticos:

- si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

- si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

- si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.

- si una entrada es booleana, hay 2 clases: si o no. Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.

2. APICACIÓN PRUEBA DE CAJA NEGRA

FUNCIONALIDAD INCORRECTA O FALTÁNTE

El aplicativo presenta dos funcionalidades faltantes:

1. No existe un método que permita refrescar los formularios donde se cargan las tablas de valores de las funciones calculadas, es decir, los resultados generados luego de calcular la función, se cargan en labels creados en tiempo de ejecución, los cuales no se pueden refrescar o remover, para que cada vez que se cargue el formulario este se encuentre listo para un nuevo calculo; el sistema vuelve a realizar su recorrido con los nuevos valores, pero la tabla de resultados se sobrescribe. Para poder realizar un nuevo calculo y que la tabla de valores se visualice de manera correcta se debe cerrar la aplicación y correrla de nuevo.

2. El aplicativo no permite introducir valores decimales en el dominio, es decir, los valores que puede registrar el usuario deben ser enteros.

ANÁLISIS DE VALORES LÍMITE

Referente al punto anterior, donde se mencionó la funcionalidad faltante que restringe la entrada de valores decimales por parte del usuario, se ajusto la aplicación para que el aplicativo aceptara valores decimales, pero como existe un requerimiento en el aplicativo que cita “Los valores que deberá graficar la función en el aplicativo deberán estar entre los rangos (-5 a 5) con un intervalo de cambio de valor de 0.5.”, la aplicación no calcula el ultimo valor en x y su correspondiente y. En este aspecto, los valores decimales, afectan el sistema, en sentido que este genera información incompleta. En base a la premisa que el aplicativo debe graficar valores entre (-5,5), el sistema se valido, pero los valores límite que podemos sugerir son:

- (-∞,-5), este tipo de valores genera error

(-5,5), valores aceptables

- (5, +∞), este tipo de valores genera error

PRUEBA DE SEGURIDAD

Las restricciones aplicadas al software para evitar su depuración, corresponden a la información (valores en el dominio) que registra el usuario. Estas son:

- El usuario no puede digitar más de dos caracteres en los campos donde se le solicita que ingrese el dominio sobre el cual el sistema calcula la tabla de valores y genera la gráfica.

- Los campos en que se solicita el dominio no aceptan caracteres alfanuméricos, solo numéricos. Si el usuario digita caracteres con las condiciones anteriores, automáticamente el sistema le informa del error y le solicita nuevos valores.

- El sistema no acepta valores decimales. -Suponemos que el usuario ingresa valores de tipo numérico y enteros, el sistema también valida esta información, en base a las siguientes condiciones:

− xmin debe ser estrictamente menor que xmax (por ejemplo [5, -4], es un error)

− xmin no debe ser menor que -5 (por ejemplo [-6,3], es un error)

− xmax no debe ser mayor que 5 (por ejemplo [-5,6], es un error)

- La tabla de valores se genera automáticamente en componentes labels, el usuario no puede modificar los resultados generados por el sistema.

PRUEBA DE RENDIMIENTO

Se puede decir que el aplicativo funciona a una tasa de rendimiento del 95%, pues es un aplicativo que no consume muchos recursos, dado a su poca complejidad y la funcionalidad implementada en él es bastante sencilla, no requiere gran cantidad de memoria para su ejecución. El aplicativo funciona de manera operativa, las entradas se aceptan de forma adecuada y las salidas son correctas.

3. APLICACIÓN PRUEBA DE CAJA BLANCA

DECISIONES LÓGICAS

-Validación del dominio

1. xMin = Val(txtxMin): xMax = Val(txtxMax)

2. If xMin < -5 Then

3. MsgBox "El limite inferior no debe ser menor a -5", vbCritical, "Error"

4. txtxMax.Text = ""

Label10(0).Caption = ""

txtxMin.SetFocus

Parabola.Cls

Exit Sub

7. End If

5. If xMax > 5 Then

3. MsgBox "El limite superior no debe ser mayor a 5", vbCritical, "Error"

4. txtxMin.Text = ""

txtxMax.Text = ""

Label10(0).Caption = ""

txtxMin.SetFocus

Parabola.Cls

Exit Sub

7. End If

6. If xMin >= xMax Then

3. MsgBox "El dominio no es válido", vbCritical, "Error"

4. txtxMin.Text = ""

txtxMax.Text = ""

txtxMin.SetFocus

Exit Sub

7. End If

- Calculo de tabla de valores para puntos intermedios (razón de cambio 0.5)

1. If x <>

2. m = x + 0.5

3. n = (m ^ 2) + (4 * m) + 5

4. k = Label12.Count

5. Load Label12(k)

With Label12(k)

.Top = Label12(k - 1).Top + 665

.Caption = Str(m)

.Visible = True End With

6. l = Label13.Count

7. Load Label13(l)

With Label13(l)

.Top = Label13(l - 1).Top + 665

.Caption = Str(n)

.Visible = True

End With

8. End If

- Calculo para el Ymin y el Ymax

1. Ymin = f(xMin)

2. If f(xMax) < ymin =" f(xMax)">

4. If xMin < ymin =" f(Xv)">

1. Ymax = f(xMin)

2. If f(xMax) > Ymax Then 3. Ymax = f(xMax)

4. If xMin <> Ymax Then 7. Ymax = f(Xv)

BUCLES

DIAGRAMA DE FLUJO DE DATOS (DFD)

CONCLUSIONES

• La prueba ideal de un sistema sería exponerlo en todas las situaciones posibles, así encontraríamos hasta el último fallo. Indirectamente, garantizamos su respuesta ante cualquier caso que se le presente en la ejecución real. Esto es imposible desde todos los puntos de vista: humano, económico e incluso matemático.



• La fase de pruebas absorbe una buena porción de los costes de desarrollo de software. Además, se muestra renuente a un tratamiento matemático o, simplemente, automatizado. Su ejecución se basa en metodología (reglas que se les dan a los encargados de probar) que se va desarrollando con la experiencia.



• Lograr una buena cobertura con pruebas de caja blanca es un objetivo deseable; pero no suficiente a todos los efectos. Un programa puede estar perfecto en todos sus términos, y sin embargo no servir a la función que se pretende. Las pruebas de caja blanca nos convencen de que un programa hace bien lo que hace; pero no de que haga lo que necesitamos


• Lograr una buena cobertura con pruebas de caja negra es un objetivo deseable; pero no suficiente a todos los efectos. Un programa puede pasar con holgura millones de pruebas y sin embargo tener defectos internos que surgen en el momento más inoportuno. Las pruebas de caja negra nos convencen de que un programa hace lo que queremos; pero no de que haga (además) otras cosas menos aceptables.


• Todo caso de prueba debe satisfacer los siguientes criterios: Reducir el número de casos de prueba adicionales. Deben decir algo sobre la presencia o ausencia de clases de errores.

RECOMENDACIONES

La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica: Verificar la interacción de componentes. Verificar la integración adecuada de los componentes. Verificar que todos los requisitos se han implementado correctamente. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida: podemos probar la funcionalidad de los primeros prototipos; probar la estabilidad, cobertura y rendimiento de la arquitectura; probar el producto final, etc. Lo que conduce al principal beneficio de la prueba: proporcionar feedback mientras hay todavía tiempo y recursos para hacer algo.

La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. 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 alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

La prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

Cualquier proceso de ingeniería puede ser probado de una de dos formas:Se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa.Se pueden desarrollar pruebas que aseguren que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada.La primera aproximación se denomina prueba de la caja negra y la segunda prueba de la caja blanca.

BIBLIOGRAFÍA

-http://ingpau.blogspot.com/2007/09/etapa-de-pruebas.html

-http://fcqi.tij.uabc.mx/docentes/luisgmo/data/8.1%20prb-cal-mant.pdf

- http://lsi.ugr.es/~ig1/docis/pruso.pdf

- www.rogeliodavila.com/tcs/TCS%20Notes%20JAVega/Parte_16_TestWhite.ppt

- http://ingpau.blogspot.com/2007/09/etapa-de-pruebas.html

- http://ji.ehu.es/mikelv/index_archivos/ApuntesIS/8-PruebasdelSoftware.pdf

- http://indalog.ual.es/mtorres/LP/Prueba.pdf

PANTALLAZOS DEL APLICATIVO