Pruebas Del Software

Prueba del software
Las pruebas deben llevarse a cabo durante todo el proceso de desarrollo de sistemas y no sólo  durante la implementación. Varía su clasificación y características dependiendo del momento en que se lleven a cabo. En este documento el enfoque es en las pruebas posteriores al diseño, es  decir de la implementación.


PRUEBAS BASADAS EN LA EJECUCIÓN
Estas se deben llevar a cabo a partir de que se genera código. Para su realización se requiere preparar previamente datos de prueba. La correcta elección de los datos de prueba será la clave del éxito de las mismas.
Las cualidades que deben verificarse en las pruebas son: utilidad, fiabilidad, solidez o robustez, desempeño y corrección.
La utilidad verifica a qué grado el sistema satisface las necesidades del cliente en cuanto a 
rentabilidad o utilidades.
La fiabilidad que es la medida de la frecuencia de fallas, es decir el tiempo entre fallas y el 
tiempo promedio de reparación. Esta medida permitirá tomar consideraciones de recuperación.
La solidez o robustez implica varios factores como la respuesta a entradas inválidas.
El desempeño mide qué tanto el sistema cumple con los tiempos de respuesta o requisitos de espacio establecidos en las especificaciones.
Finalmente, la corrección se refiere a qué tanto cumple con todas las especificaciones del 
usuario.
un proceso de Evaluación en el que los resultados obtenidos se comparan con los resultados 
esperados para localizar fallos en el software. Estos fallos conducen a un proceso de 
Depuración en el que es necesario identificar la falta asociada con cada fallo y corregirla, 
pudiendo dar lugar a una nueva prueba. Como resultado final se puede obtener una 
determinada Predicción de Fiabilidad, o un cierto nivel de confianza en el software 
probado.Modelo deEl objetivo de las pruebas no es asegurar la ausencia de defectos en un software, únicamente  puede demostrar que existen defectos en el software. Nuestro objetivo es pues, diseñar  pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para ser más eficaces (es decir, con más alta probabilidad de encontrar errores), las pruebas
deberían ser realizadas por un equipo independiente al que realizó el software. El ingeniero de software que creó el sistema no es el más adecuado para llevar a cabo las pruebas de dicho software, ya que inconscientemente tratará de demostrar que el software funciona, y no que  no lo hace, por lo que la prueba puede tener menos éxito.


PASOS PARA PROBAR EL SOFTWARE
Veamos ahora cuáles son las tareas a realizar para probar un software:
1.  Diseño de las pruebas. Esto es, identificación de la técnica o técnicas de pruebas que se
utilizarán para probar el software. Distintas técnicas de prueba ejercitan diferentes criterios
como guía para realizar las pruebas. Seguidamente veremos algunas de estas técnicas.
2.  Generación de los casos de prueba. Los casos de prueba representan  los datos que se
utilizarán como entrada para ejecutar el software a probar. Más concretamente los casos de
prueba determinan un conjunto de entradas, condiciones de ejecución y resultados esperados 
para un objetivo particular. Como veremos posteriormente, cada técnica de pruebas 
proporciona unos criterios distintos para generar estos casos o datos de prueba. Por lo tanto, 
durante la tarea de generación de casos de prueba, se han de confeccionar los distintos casos de prueba según la técnica o técnicas identificadas previamente. La generación de cada caso de prueba debe ir acompañada del resultado que ha de producir el software al ejecutar dicho caso (como se verá más adelante, esto es necesario para detectar un posible fallo en el programa).
3. Definición de los procedimientos de la prueba. Esto es, especificación de cómo se va a llevar a cabo el proceso, quién lo va a realizar, cuándo …
4.  Ejecución de la prueba,  aplicando los casos de prueba generados previamente e identificando los posibles fallos producidos al comparar los resultados esperados con los
resultados obtenidos.
5. Realización de un informe de la prueba, con el resultado de la ejecución de las pruebas, qué casos de prueba pasaron satisfactoriamente, cuáles no, y qué fallos se detectaron.
Tras estas tareas es necesario realizar un proceso de depuración de las faltas asociadas a los  fallos identificados. Nosotros nos centraremos en el segundo paso, explicando cómo distintas técnicas de pruebas pueden proporcionar criterios para generar distintos datos de prueba. 



TÉCNICAS DE PRUEBA
Las técnicas de prueba proporcionan distintos criterios para generar casos de prueba que 
provoquen fallos en los programas. Estas técnicas se agrupan en:
− Técnicas de caja  de vidrio o estructurales (antes conocidas como de caja blanca), que se basan en un minucioso examen de los detalles procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa. Se examina el código a fin de generar datos de prueba que garanticen se ejecute cada una de las líneas de código para poder observar su resultado.
− Técnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz del programa aprobar, entendiendo por interfaz las entradas y salidas de dicho programa.  Se preparan considerando únicamente las especificaciones del sistema, es decir, los requerimientos. Sin asomarse al código.  No es necesario conocer la lógica del programa, únicamente la funcionalidad que debe realizar.
A primera vista parecería que una prueba de caja blanca completa nos llevaría a disponer de un código perfectamente correcto. De hecho esto ocurriría si se han probado todos los posibles caminos por los que puede pasar el flujo de control de un programa. Sin embargo, para programas de cierta envergadura, el número de casos de prueba que habría que generar sería excesivo, nótese que el número de caminos incrementa exponencialmente a medida que el número de sentencias condicionales y bucles aumenta. Sin embargo, este tipo de prueba no se desecha como impracticable. Se pueden elegir y ejercitar ciertos caminos representativos de un programa.
Por su parte, tampoco sería factible en una prueba de caja negra probar todas y cada una de 
las posibles entradas a un programa, por lo que análogamente a como ocurría con las técnicas de caja blanca, se seleccionan un conjunto representativo de entradas y se generan los correspondientes casos de prueba, con el fin de provocar fallos en los programas.
En realidad estos dos tipos de técnicas son técnicas complementarias que han de aplicarse al realizar una prueba dinámica, ya que pueden ayudar a identificar distintos tipos de faltas en un programa.
A continuación, se describen en detalle los procedimientos propuestos por ambos tipos de 
técnicas para generar casos de prueba.


Pruebas de Caja de Vidrio o Estructurales
Este método se centra en cómo diseñar los casos de prueba  atendiendo al  comportamiento 
interno y la estructura del programa. Se examina así la lógica interna del programa sin 
considerar los aspectos de rendimiento.
El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez, 
todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera 
como falsa.
Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los
caminos de un programa. Por ello se han definido distintos criterios de cobertura lógica, que
permiten decidir qué sentencias o caminos se deben examinar con los casos de prueba. Estos
criterios son:
- Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el programa se ejecute, al menos, una vez.
- Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en el programa se ejecute una vez con resultado verdadero y otra con el falso.- Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condición en una decisión tenga una vez resultado verdadero y otra falso.
- Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada
condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión 
tome todas las posibles salidas, al menos una vez.
- Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas las combinaciones posibles de resultados de cada condición se invoquen al menos una vez.
- Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos
los caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta su salida.


Pruebas de Caja Negra o Funcionales
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:
− Particiones de Equivalencia.
− Análisis de Valores Límite.
− Métodos Basados en Grafos.
− Pruebas de Comparación.
− Análisis Causa-Efecto.





ESTRATEGIA DE PRUEBAS
La estrategia que se ha de seguir a la hora de evaluar dinámicamente un sistema software 
debe permitir comenzar por los componentes más simples y más pequeños e ir avanzando
progresivamente hasta probar todo el software en su conjunto. Más concretamente, los pasos a
seguir son:
1. Pruebas Unitarias. Comienzan con la prueba de cada módulo.
2. Pruebas de Integración. A partir del esquema del diseño, los módulos probados se vuelven a probar combinados para probar sus interfaces.
3. Prueba del Sistema. El software ensamblado totalmente con cualquier componente hardware  que requiere se prueba para comprobar que se cumplen los requisitos funcionales.
4. Pruebas de Aceptación. El cliente comprueba que el software funciona según sus
expectativas.


Pruebas Unitarias
La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre cada 
módulo del software de manera independiente. El objetivo es comprobar que el módulo, 
entendido como una unidad funcional de un programa independiente, está correctamente 
codificado. En estas pruebas cada módulo será probado por separado y lo hará, generalmente, la persona que lo creó. En general, un módulo se entiende como un componente software que 
cumple las siguientes características:
− Debe ser un bloque básico de construcción de programas.
− Debe implementar una función independiente simple.
− Podrá ser probado al cien por cien por separado.
− No deberá tener más de 500 líneas de código.
Tanto pruebas de caja de vidrio como de caja negra han de aplicar para probar de la manera 
más completa posible un módulo. Nótese que las pruebas de caja negra (los casos de prueba) se pueden especificar antes de que módulo sea programado, no así las pruebas de caja de  vidrio.


Pruebas de Integración
Aún cuando los módulos de un programa funcionen bien por separado es necesario probarlos
conjuntamente: un módulo puede tener un efecto adverso o inadvertido sobre otro módulo; lassubfunciones, cuando se combinan, pueden no producir la función principal deseada; la 
imprecisión aceptada individuamente puede crecer hasta niveles inaceptables al combinar los módulos; los datos pueden perderse o malinterpretarse entre interfaces, etc.
Por lo tanto, es necesario probar el software ensamblando todos los módulos probados 
previamente. Ésta es el objetivo de la pruebas de integración.
A menudo hay una tendencia a intentar una integración no incremental; es decir, a combinar 
todos los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco 
caótico con un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o 
módulos) que los provocó.
En contra, se puede aplicar la integración  incremental  en la que el programa se prueba en 
pequeñas porciones en las que los fallos son más fáciles de detectar. Existen dos tipos de 
integración incremental, la denominada ascendente y descendente. Veamos los pasos a seguir para cada caso.
Integración incremental ascendente
1. Se combinan los módulos de bajo nivel en grupos que realicen una subfunción específica.
2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y
salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la
estructura del programa.

Integración incremental descendente:
1. Se usa el módulo de control principal como controlador de la prueba, creando  resguardos
(módulos que simulan el funcionamiento de los módulos que utiliza el que está probando) para 
todos los módulos directamente subordinados al módulo de control principal.
2. Dependiendo del enfoque e integración elegido se van sustituyendo uno a uno los 
resguardos subordinados por los módulos reales.
3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.



Pruebas del Sistema
Este tipo de pruebas tiene como propósito ejercitar profundamente el sistema para verificar 
que se han integrado adecuadamente todos los elementos del sistema (hardware, otro 
software, etc.) y que realizan las funciones adecuadas. Concretamente se debe comprobar que:
- Se cumplen los requisitos funcionales establecidos.
- El funcionamiento y rendimiento de las interfaces hardware, software y de usuario.
- La adecuación de la documentación de usuario.
- Rendimiento y respuesta en condiciones límite y de sobrecarga.
Para la generación de casos de prueba de sistema se utilizan técnicas de caja negra. Este tipo de pruebas se suelen hacer inicialmente en el entrono del desarrollador, denominadas Pruebas Alfa, y seguidamente en el entrono del cliente denominadas Pruebas Beta.


Pruebas de Aceptación
A la hora de realizar estas pruebas, el producto está listo para implantarse en el entorno del 
cliente.
El usuario debe ser el que realice las pruebas, ayudado por personas del equipo de pruebas, 
siendo deseable, que sea el mismo usuario quien aporte los casos de prueba.
Estas pruebas se caracterizan por:
- Participación activa del usuario, que debe ejecutar los casos de prueba ayudado por
miembros del equipo de pruebas.
- Están enfocadas a  probar los requisitos de usuario, o mejor dicho a demostrar que no se
cumplen los requisitos, los criterios de aceptación o el contrato. Si no se consigue demostrar
esto el cliente deberá aceptar el producto.
- Corresponden a la fase final del proceso de desarrollo de software.


Es muy recomendable que las pruebas de aceptación se realicen en el entorno en que se va a
explotar el sistema (incluido el personal que lo maneje). En caso de un producto de interés 
general, se realizan pruebas con varios usuarios que reportarán sus valoraciones sobre el 
producto.
Para la generación de casos de prueba de aceptación se utilizan técnicas de caja negra.


Pruebas de Regresión
La regresión consiste en la repetición selectiva de pruebas para detectar fallos introducidos 
durante la modificación de un sistema o componente de un sistema. Se efectuarán para 
comprobar que los cambios no han originado efectos adversos no intencionados o que se 
siguen cumpliendo los requisitos especificados.
En las pruebas de regresión hay que:
- Probar íntegramente los módulos que se han cambiado.
- Decidir las pruebas a efectuar para los módulos que no han cambiado y que han sido
afectados por los cambios producidos.
Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el mantenimiento.


PRUEBAS ORIENTADAS A OBJETOS
En las secciones anteriores se ha presentado el proceso de pruebas orientado al concepto 
general de módulo. Sin embargo, en el caso de la orientación a objetos (OO) es el concepto de clase y objeto el que se utiliza. Veamos a continuación, algunas particularidades de las pruebas para el caso de la Orientación a Objetos
Prueba de Unidad
Al tratar software OO cambia el concepto de unidad. El encapsulamiento dirige la definición de clases y objetos. Esto significa que cada clase e instancia de clase (objeto) empaqueta los 
atributos (datos) y las operaciones (también conocidas como métodos o servicios) que 
manipulan estos datos.
Por lo tanto, en vez de módulos individuales, la menor unidad a probar es la clase u objeto
encapsulado. Una clase puede contener un cierto número de operaciones, y una operación 
particular puede existir como parte de un número de clases diferentes. Por tanto, el significado de prueba de unidad cambia ampliamente frente al concepto general visto antes.
De esta manera, la  prueba de clases  para el software OO es el equivalente a la prueba de 
unidad para software convencional. A diferencia de la prueba de unidad del software 
convencional, la cual tiende a centrarse en el detalle algorítmico de un módulo y los datos que 
fluyen a lo largo de la interfaz de éste, la prueba de clases para software OO está dirigida por 
las operaciones encapsuladas en la clase y el estado del comportamiento de la clase. Así, la
prueba de una clase debe haber probado mediante las correspondientes técnicas de caja  de 
vidrio y caja negra el funcionamiento de cada uno de los métodos de dicha clase. Además, se 
deben haber generado casos de prueba para probar valores representativos de los atributos de dicha clase (esto puede realizarse aplicando la técnica de clases de equivalencia y análisis de valores límite).


Prueba de Integración
Debido a que el software OO no tiene una estructura de control jerárquica, las estrategias
convencionales de integración ascendente y descendente poseen un significado poco relevante en este contexto.
Generalmente se pueden encontrar dos estrategias diferentes de pruebas de integración en 
sistemas OO. La primera,  prueba basada en hilos (o threads),  integra el conjunto de clases 
necesario para responder a una entrada o evento del sistema. Cada hilo se integra y prueba 
individualmente. El segundo enfoque para la integración, prueba basada en el uso. Esta prueba comienza la construcción del sistema integrando y probando aquellas clases (llamadas clases independientes) que usan muy pocas de las clases. Después de probar las clases independientes, se comprueba la próxima capa de clases, llamadas clases dependientes, que usan las clases independientes. Esta secuencia de capas de pruebas de clases dependientes continúa hasta construir el sistema por completo.
Nótese cómo la prueba basada en hilos proporciona una estrategia más ordenada para realizar la prueba que la prueba basada en el uso. Esta prueba basada en hilos, suele aplicarse utilizando los diagramas de secuencia de objetos que diseñan cada evento de entrada al sistema.
Concretamente, se pueden realizar los siguientes pasos para generar casos de prueba a partir de un diagrama de secuencias.
1. Definir el conjunto de secuencias de mensajes a partir del diagrama de secuencia. Cada 
secuencia ha de comenzar con un mensaje  m  sin predecesor (habitualmente, un mensaje 
enviado al sistema por un actor), y estará formada por el conjunto de mensajes cuya ejecución 
dispara m.
2. Analizar sub-secuencias de mensajes a partir de posibles caminos condicionales en los 
diagramas de secuencia.
3. Identificar los casos de prueba que se han de introducir al sistema para que se ejecuten las 
secuencias de mensajes anteriores, en función de los métodos y las clases afectadas por la 
secuencia. Tanto valores válidos como inválidos deberían considerarse.
Nótese cómo el conjunto de casos de prueba puede aumentar exponencialmente si se trabaja 
sobre un sistema OO con un número elevado de interacciones. Por lo tanto, es necesario tener en cuenta este factor a la hora de realizar el diseño.


Prueba de Sistema
En el nivel de prueba del sistema, los detalles de las conexiones entre clases no afectan. El 
software debe integrarse con los componentes hardware correspondientes y se ha de 
comprobar el funcionamiento del sistema completo acorde a los requisitos. Como en el caso del software convencional, la validación del software OO se centra en las acciones visibles del 
usuario y las salidas del sistema reconocibles por éste. Para asistir en la determinación de 
casos de prueba de sistema, el ejecutor de la prueba debe basarse en los casos de uso que 
forman parte del modelo de análisis. El caso de uso brinda un escenario que posee una alta 
probabilidad con errores encubiertos en los requisitos de interacción del cliente. Los métodos 
convencionales de prueba de caja negra, pueden usarse para dirigir estas pruebas.
Prueba de Aceptación


La prueba de aceptación en un sistema OO es semejante  a la prueba de aceptación en un 
software tradicional. El motivo es que el objetivo de este tipo de prueba es comprobar si el 
cliente está satisfecho con el producto desarrollado y si este producto cumple con sus 
expectativas, en términos de los errores que genera y de la funcionalidad que suministra. Al 
igual que las pruebas convencionales serán los clientes quienes realicen estas pruebas y 
suministren los casos de prueba correspondientes.

Para Saber Mas Visite http://is.ls.fi.upm.es/udis/docencia/erdsi/Documentacion-Evaluacion-
6.pdf#search=%22Juristo%2C%20Natalia%20T%C3%A9cnicas%20de%20Evaluaci%C3%B3n
%20de%20Software%22