Pruebas Del Software

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 PRUEBA DE CAJA BLANCA 1. Inclusive tiene como ventaja ver hasta qué punto las funciones parecen funcionar de acuerdo con las especificaciones y cumplir así los requisitos de rendimiento. Por lo tanto hay que diseñar pruebas que saque a la luz diferentes clases de errores. lo que incluye especificaciones de requisitos. 3.1. se aplican diferentes técnicas de prueba a cada tipo de producto software. Esto elimina muchos errores antes de empezar las pruebas. por supuesto. 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. 2. Diferentes técnicas de prueba son apropiadas en diferentes momentos. La prueba la dirige el desarrollador del software y en . 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. casos de uso. El ingeniero crea una serie de casos de prueba que intentan "demoler" el software que ha sido construido. haciéndolo con la menor cantidad de tiempo y esfuerzo.2 PRUEBA DE CAJA NEGRA 2. hacia la integración de todo el sistema de cómputo. diagramas de diversos tipos y. Tiene como objetivos: 1. 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. el código fuente y el resto de productos que forman parte de la aplicación. Para realizar pruebas efectivas un equipo de software debe efectuar revisiones técnicas formales y efectivas. La prueba comienza al nivel de componentes y trabaja “hacia fuera”. Las pruebas deberían empezar por lo "pequeño" y progresar hacia "lo grande" (módulos). deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto. Obviamente. Una prueba tiene éxito si descubre un error no detectado hasta entonces. 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. APICACIÓN PRUEBA DE CAJA NEGRA 3. En sentido estricto. MARCO TEÓRICO 1. No son posibles las pruebas exhaustivas (imposible ejecutar todas las combinaciones de caminos). Los requisitos del software utilizando técnicas de diseño de casos de prueba de "caja negra" 1. comprobación de bucles (se verifican los bucles para 0. A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. sobre un módulo concreto. 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). Si se conoce el funcionamiento interno el producto. es decir. pruebas de camino de datos (definición-uso de variables). las pruebas deberían ser realizadas por un equipo independiente. las de caja blanca están dirigidas a las funciones internas. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del modulo.1 PRUEBA DE CAJA BLANCA En programación. pero según varias opiniones. pruebas sobre las expresiones lógico-aritméticas. que las operaciones internas se realicen de acuerdo con las especificaciones. . Para ser más eficaces. La lógica interna del programa utilizando técnicas de diseño de casos de prueba de "caja blanca" 2. Un error es diseñar y ejecutar pruebas que solamente demuestren el buen funcionamiento del programa en lugar de descubrir errores. pero ambas se incluyen en la estrategia de pruebas. En los sistemas orientados a objetos. mientras se buscan los errores de cada función. Entre las técnicas usadas se encuentran. se aplican pruebas para asegurar que todas las piezas encajen. Las pruebas deberían planificarse mucho antes de que empiecen. 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.proyectos grandes un grupo independiente de pruebas. Las pruebas de caja blanca se llevan a cabo en primer lugar. y luego para las iteraciones máximas. 2. para luego realizar las de caja negra sobre varios subsistemas (integración). El software debe probarse desde dos perspectivas diferentes: 1. Hay dos maneras de probar cualquier producto: 1. la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución). La prueba y la depuración son actividades diferentes. máximas menos uno y más uno.1 y n iteraciones. se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. las pruebas de caja blanca pueden aplicarse a los métodos de la clase. Adicionalmente. es imposible alcanzar una certeza del 100%). o por una inmensa mayoría.Encontrar fragmentos del programa que no son ejecutados por los casos de prueba. es conveniente conocer qué porcentaje del programa se ha ejecutado.Crear casos de prueba adicionales que incrementen la cobertura. Cuando se pasan casos de prueba al programa que se está probando. Existen varias formas de medir la cobertura lograda en el programa por los casos de prueba. una medida de la calidad del programa). simplemente "sobre" y se pueda prescindir de él. necesaria. Basta coger el código fuente e ir contando. bloques. . Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias. El número de sentencias de un programa es finito.Determinar un valor cuantitativo de la cobertura (que es. . Cobertura de sentencias: Comprueba el número de sentencias ejecutables que se han ejecutado. hasta que hayamos pasado por todas. en los que existen errores. 1. de manera que estemos próximos a asegurar que todo él es correcto (evidentemente. Puede ser que este trozo del programa.Las pruebas de caja blanca realizan un seguimiento del código fuente según va ejecutando los casos de prueba. Mantenimiento Avanzado de Sistemas de Información – Pruebas del software. de manera que se determinan de manera concreta las instrucciones. Como el ordenador está obligado a ejecutarlas una tras otra. que no incrementan la cobertura. En la práctica. . es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos. pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias. pero a veces significa que una cierta funcionalidad. es inalcanzable: esto es un error y hay que corregirlo. de manera indirecta. el proceso de pruebas termina antes de llegar al 100%. el análisis de cobertura también permite la identificación de casos de prueba redundantes. ocurre con harta frecuencia que los programas contienen código muerto o inalcanzable. Por segmento se entiende una secuencia de sentencias sin puntos de decisión. algunas de las cuales se presentan en el siguiente epígrafe: Criterios de cobertura De acuerdo con (Cornett 2002). 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. etc. el análisis de cobertura del código es el proceso de: . En efecto. 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. para cubrir todas las sentencias posibles. Sin embargo. Estos criterios se extienden a las construcciones que suponen elegir 1 de entre varias ramas. Cobertura de condiciones: Comprueba el número de condiciones ejecutadas. también debe ser importante el caso de que la condición falle (si no lo fuera. una satisfaciendo la condición. 4. Cobertura de llamadas: Comprueba el número de llamadas a funciones y procedimientos que se han ejecutado. y otra no. Sin embargo. En estos casos. 5. El número de caminos linealmente independientes coincide con la complejidad ciclomática de McCabe. se plantea un refinamiento de la cobertura de segmentos consistente en recorrer todas las posibles salidas de los puntos de decisión. pero también todas las posibles ramas de un switch). Cobertura de condiciones/decisiones: Comprueba el número de condiciones y decisiones que se han ejecutado. 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. Cobertura de funciones: Comprueba el número de funciones y procedimientos que han sido llamados. esto llevaría implícita una cobertura del 100% de los segmentos. 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. Por ejemplo. Nótese que si lográramos una cobertura de ramas del 100%. El criterio también debe refinarse en lenguajes que admiten excepciones (por ejemplo.2. el CASE. una vez y más de una vez. pues todo segmento está en alguna rama. hay que añadir pruebas para provocar la ejecución de todas y cada una de las excepciones que pueden dispararse. la cobertura de ramas cubre plenamente la esencia de los bucles. Desde el punto de vista de cobertura de segmentos. Cobertura de condiciones múltiples: Comprueba el número de condiciones múltiples ejecutadas. desde el punto de vista de la lógica del programa. Cubrimiento de bucles: Comprueba el número de bucles que han sido ejecutados cero veces (excepto para bucles do -While). 6. mientras que la cobertura de llamadas cuenta cuántas de las llamadas a funciones que hay en el programa se han ejecutado. con 0 ejecuciones tenemos el 100%. Para afrontar estos casos. Los bucles no son más que segmentos controlados por decisiones. Esto es cierto salvo en programas triviales que carecen de condiciones (a cambio. Para el ejemplo de arriba. entendiendo que se ha ejecutado una condición cuando se han ejecutado todas sus posibles ramas. con éxito en la condición. 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. para conseguir una cobertura de ramas del 100% hay que ejecutar (al menos) 2 veces. 8. Así. 9. 7. basta 1 sola prueba para cubrirlo desde todos los puntos de vista). basta ejecutar una vez. Ada). sobra el IF). como en la rama ELSE no hay sentencias. 3. Cobertura de decisiones: Comprueba el número de decisiones ejecutadas. Pero . entonces eso es un bucle FOR con trampa. Cobertura de operadores relacionales: Comprueba si se han ejecutado los valores límite en los operadores relacionales (>. estas pruebas se basan en la especificación del . Todas ellas provocan terminaciones anticipadas del bucle. o el valor de alguna variable que se utilice en el cálculo del incremento o del límite de iteración. 12. en cambio. Estos últimos párrafos hay que precisarlos para cada lenguaje de programación. o simplemente bucles con trampa. y el compilador se encarga de garantizarlo. pues en su cabecera está definido el número de veces que se va a ejecutar. 1 ejecución 3. 1. ya que se asume la hipótesis de que estas situaciones son propensas a errores. y lo más normal es que ejecutarlo una vez de menos o una vez de más tenga consecuencias indeseables. <. es extremadamente fácil equivocarse y redactar un bucle que se ejecuta 1 vez de más o de menos. sin embargo. que se supone que prohíben ciertas construcciones arriesgadas. >=. Para un bucle de tipo WHILE hay que pasar 3 pruebas 1. Lo peor son aquellos lenguajes que permiten el uso de sentencias GOTO.eso es simplemente la teoría. Si el programa contiene bucles LOOP. Ni una más. Cubrimiento de carrera: Comprueba el número de tareas o hilos que han ejecutado simultáneamente el mismo bloque de código. son muy seguros. 0 ejecuciones 2. pero ese número de veces debe ser muy preciso. Tampoco conviene confiarse de lo que prometen lenguajes como MODULA-2. Los compiladores reales suelen ser más tolerantes que lo que anuncian los libros. No obstante.2 PRUEBA DE CAJA NEGRA También conocidas como Pruebas de Comportamiento. <=). 1 ejecución 2. pues la práctica descubre que los bucles son una fuente inagotable de errores. 11. 10. Un bucle se ejecuta un cierto número de veces. salvo reescribir el código. todos triviales. la única cobertura aplicable es la de ramas. ni una menos. Si dentro del bucle se altera la variable de control. conviene no engañarse con los bucles FOR y examinar su contenido. Y. Cobertura de tablas: Comprueba si se ha hecho referencia a todos los elementos de los arrays. algunos mortales. El riesgo de error es muy alto. más de 1 ejecución Para un bucle de tipo REPEAT hay que pasar 2 pruebas 1. pero no se conocen técnicas sistemáticas de abordarlo. También tiene "trampa" si contiene sentencias del tipo EXIT (que algunos lenguajes denominan BREAK) o del tipo RETURN. Basta pues con ejecutarlos 1 vez. más de 1 ejecución Los bucles FOR. Identificar las clases de equivalencia. 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. los casos de prueba se diseñan también considerando el dominio de salida. es de esperar que ninguno de los casos de prueba correspondientes a la misma clase de equivalencia encuentre ningún error. dado que la prueba exhaustiva es imposible. En otras palabras. Algunos de ellos son: 1. 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. Entonces. el análisis de valores límite complementa la técnica de partición de equivalencia de manera que: . Por ello. 2. se eligen los casos de prueba en los extremos. El diseño de casos de prueba según esta técnica consta de dos pasos: 1. . Para seleccionar el conjunto de entradas y salidas sobre las que trabajar. el objetivo final es pues.En lugar de centrase sólo en el dominio de entrada. Esto quiere decir que si el caso de prueba correspondiente a una clase de equivalencia detecta un error. 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. y como consecuencia producen una serie de salidas que revelan la presencia de defectos. .En lugar de seleccionar cualquier caso de prueba de las clases válidas e inválidas. este método intenta dividir el dominio de entrada de un programa en un número finito de clases de equivalencia. No obstante. 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. Las condicione límite son aquellas que se hayan en los márgenes de la clase de equivalencia. el resto de los casos de prueba de dicha clase de equivalencia deben detectar el mismo error.programa o componente a ser probado para elaborar los casos de prueba. Por lo tanto.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. tanto de entrada como de salida. hay que tener en cuenta que en todo programa existe un conjunto de entradas que causan un comportamiento erróneo en nuestro sistema. Al igual que ocurría con las técnicas de Caja Blanca. La partición equivalente se dirige a una definición de casos de prueba que descubran clases de errores. para confeccionar los casos de prueba de Caja Negra existen distintos criterios. reduciendo así el número total de casos de prueba que hay que desarrollar. 2. Y viceversa. si un caso de prueba no ha detectado ningún error. se ha desarrollado el análisis de valores límite como técnica de prueba. Identificar los casos de prueba. Esta técnica nos lleva a elegir los casos de prueba que ejerciten los valores límite. 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. Si una condición de entrada especifica un rango de valores. un entero).Las pautas para desarrollar casos de prueba con esta técnica son: .Aplicar las reglas anteriores a los datos de salida. Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. Métodos Basados en Grafos. y el probador se limita a suministrarle datos como entrada y estudiar la salida. Las pruebas de caja negra se centran en lo que se espera de un módulo. es decir. etc.) Este comentario no obsta para que sean útiles en cualquier módulo del sistema. . sin preocuparse de lo que pueda estar haciendo el módulo por dentro. y otros dos casos para situaciones justo por debajo y por encima de los extremos. 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). se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. ficheros. se diseñarán casos de prueba para los dos límites del rango. intentan encontrar casos en que el módulo no se atiene a su especificación. canales de comunicaciones. sino en los datos que se le pasan a estas funciones.Si la entrada o salida de un programa es un conjunto ordenado.Si una condición de entrada especifica un número de valores. se sigue una técnica algebraica conocida como "clases de equivalencia". pantalla. 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. aunque puede ser más laborioso en módulos con interfaz al exterior. pues los demás datos de la misma clase son equivalentes. habrá que prestar atención a los elementos primero y último del conjunto. se diseñan dos casos de prueba para los valores mínimo y máximo. 5. . 4. A la vista de los requisitos de un módulo. 3. En cualquier caso. entonces es suficiente probar un caso de cada clase. Es fácil obtener coberturas del 100% en módulos internos. El conjunto de datos posibles suele ser muy amplio (por ejemplo. Esta técnica trata cada parámetro como un modelo algebraico donde unos datos son equivalentes a otros. es muy recomendable conseguir una alta cobertura en esta línea.Análisis Causa-Efecto. Pruebas de Comparación. . De hecho. además de otros dos casos de prueba para valores justo por encima del máximo y justo por debajo del mínimo. . Por ello se denominan pruebas funcionales. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia. 2. en y por encima del rango. en y por encima del rango.5. El aplicativo no permite introducir valores decimales en el dominio. para que cada vez que se cargue el formulario este se encuentre listo para un nuevo calculo. pero los valores límite que podemos sugerir son: . en sentido que este genera información incompleta. el sistema se valido. la aplicación no calcula el ultimo valor en x y su correspondiente y. es decir. .El problema está pues en identificar clases de equivalencia. aparecen 2 clases de equivalencia: en el conjunto o fuera de él.si una entrada requiere un valor concreto. tarea para la que no existe una regla de aplicación universal. APICACIÓN PRUEBA DE CAJA NEGRA FUNCIONALIDAD INCORRECTA O FALTÁNTE El aplicativo presenta dos funcionalidades faltantes: 1. afectan el sistema.”. donde se mencionó la funcionalidad faltante que restringe la entrada de valores decimales por parte del usuario. En este aspecto. el sistema vuelve a realizar su recorrido con los nuevos valores. 2. Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases. los cuales no se pueden refrescar o remover. los resultados generados luego de calcular la función. No existe un método que permita refrescar los formularios donde se cargan las tablas de valores de las funciones calculadas. 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. En base a la premisa que el aplicativo debe graficar valores entre (-5.si una entrada es booleana.si una entrada requiere un valor de entre los de un conjunto. los valores que puede registrar el usuario deben ser enteros. es decir.5). ANÁLISIS DE VALORES LÍMITE Referente al punto anterior.si un parámetro de entrada debe estar comprendido en un cierto rango. aparecen 3 clases de equivalencia: por debajo. pero hay recetas para la mayor parte de los casos prácticos: . se cargan en labels creados en tiempo de ejecución. . se ajusto la aplicación para que el aplicativo aceptara valores decimales. hay 2 clases: si o no. pero la tabla de resultados se sobrescribe. aparecen 3 clases de equivalencia: por debajo. . 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. los valores decimales. el sistema también valida esta información. en base a las siguientes condiciones: − xmin debe ser estrictamente menor que xmax (por ejemplo [5.La tabla de valores se genera automáticamente en componentes labels. Estas son: . PRUEBA DE RENDIMIENTO Se puede decir que el aplicativo funciona a una tasa de rendimiento del 95%.Los campos en que se solicita el dominio no aceptan caracteres alfanuméricos. las entradas se aceptan de forma adecuada y las salidas son correctas. 3. APLICACIÓN PRUEBA DE CAJA BLANCA . dado a su poca complejidad y la funcionalidad implementada en él es bastante sencilla. no requiere gran cantidad de memoria para su ejecución. corresponden a la información (valores en el dominio) que registra el usuario. este tipo de valores genera error (-5.6]. solo numéricos. . es un error) . este tipo de valores genera error PRUEBA DE SEGURIDAD Las restricciones aplicadas al software para evitar su depuración. es un error) − xmax no debe ser mayor que 5 (por ejemplo [-5. es un error) − xmin no debe ser menor que -5 (por ejemplo [-6.El sistema no acepta valores decimales.5). . +∞).-5). pues es un aplicativo que no consume muchos recursos..3]. automáticamente el sistema le informa del error y le solicita nuevos valores. valores aceptables . Si el usuario digita caracteres con las condiciones anteriores.(5. el usuario no puede modificar los resultados generados por el sistema. -Suponemos que el usuario ingresa valores de tipo numérico y enteros. -4]. El aplicativo funciona de manera operativa.(-∞.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. If xMin < -5 Then 3. MsgBox "El limite inferior no debe ser menor a -5".DECISIONES LÓGICAS -Validación del dominio 1.Cls Exit Sub 7. MsgBox "El dominio no es válido". If xMax > 5 Then 3. vbCritical. vbCritical.Text = "" Label10(0). txtxMin.SetFocus Parabola.SetFocus . xMin = Val(txtxMin): xMax = Val(txtxMax) 2. End If 5.Text = "" txtxMin. If xMin >= xMax Then 3. "Error" 4.Text = "" Label10(0). MsgBox "El limite superior no debe ser mayor a 5".Caption = "" txtxMin. txtxMin.Cls Exit Sub 7. "Error" 4. vbCritical.Text = "" txtxMax. txtxMax. "Error" 4. End If 6.Caption = "" txtxMin.SetFocus Parabola.Text = "" txtxMax. End If .Visible = True End With 8.1). k = Label12.5 3.Calculo de tabla de valores para puntos intermedios (razón de cambio 0. n = (m ^ 2) + (4 * m) + 5 4.5) 1.Count 7.Top + 665 .Caption = Str(n) . If x <> 2. Load Label13(l) With Label13(l) .Top = Label13(l . l = Label13. Load Label12(k) With Label12(k) .Top + 665 .Caption = Str(m) .Top = Label12(k .Exit Sub 7.Visible = True End With 6. m = x + 0.Count 5.1). End If . Calculo para el Ymin y el Ymax 1. Ymax = f(Xv) .. Ymax = f(xMax) 4. Ymin = f(xMin) 2. If xMin < ymin =" f(Xv)"> 1. If f(xMax) > Ymax Then 3. If f(xMax) < ymin =" f(xMax)"> 4. If xMin <> Ymax Then 7. Ymax = f(xMin) 2. BUCLES DIAGRAMA DE FLUJO DE DATOS (DFD) . simplemente. Un programa puede pasar con holgura millones de pruebas y sin embargo tener defectos internos que surgen en el momento más inoportuno. . así encontraríamos hasta el último fallo.  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. Además. Indirectamente. Las pruebas de caja blanca nos convencen de que un programa hace bien lo que hace.  La fase de pruebas absorbe una buena porción de los costes de desarrollo de software. automatizado. se muestra renuente a un tratamiento matemático o. económico e incluso matemático. pero no de que haga lo que necesitamos  Lograr una buena cobertura con pruebas de caja negra es un objetivo deseable. Las pruebas de caja negra nos convencen de que un programa hace lo que queremos. 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. y sin embargo no servir a la función que se pretende. 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. pero no de que haga (además) otras cosas menos aceptables. pero no suficiente a todos los efectos.CONCLUSIONES  La prueba ideal de un sistema sería exponerlo en todas las situaciones posibles. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente. Una prueba tiene éxito si descubre un error no detectado hasta entonces. RECOMENDACIONES La prueba del software es un elemento crítico para la garantía de la calidad del 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.Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores.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. Verificar la integración adecuada de los componentes. Verificar que todos los requisitos se han implementado correctamente. etc. no es una etapa del proyecto en la cual se asegura la calidad.La prueba no es una actividad sencilla. probar la estabilidad. Además. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. Lo que conduce al principal beneficio de la prueba: proporcionar feedback mientras hay todavía tiempo y recursos para hacer algo. probar el producto final. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Deben decir algo sobre la presencia o ausencia de clases de errores. sólo puede demostrar que existen defectos en el software. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. esta etapa implica: Verificar la interacción de componentes. haciéndolo con la menor cantidad de tiempo y esfuerzo. Todo caso de prueba debe satisfacer los siguientes criterios: Reducir el número de casos de prueba adicionales. sino que la prueba debe ocurrir durante todo el ciclo de vida: podemos probar la funcionalidad de los primeros prototipos.La primera aproximación se denomina prueba de la caja negra y la segunda prueba de la caja blanca. cobertura y rendimiento de la arquitectura. La prueba no puede asegurar la ausencia de defectos. BIBLIOGRAFÍA . www.-http://ingpau.ehu.html -http://fcqi.http://ji.1%20prb-cal-mant.com/2007/09/etapa-de-pruebas.pdf PANTALLAZOS DEL APLICATIVO .http://lsi.html .es/mtorres/LP/Prueba.ppt .pdf .blogspot.uabc.ugr.com/2007/09/etapa-de-pruebas.pdf .http://ingpau.ual.tij.pdf .es/mikelv/index_archivos/ApuntesIS/8-PruebasdelSoftware.com/tcs/TCS%20Notes%20JAVega/Parte_16_TestWhite.blogspot.es/~ig1/docis/pruso.mx/docentes/luisgmo/data/8.rogeliodavila.http://indalog.