Pruebas

INTRODUCCIÓN
Una prueba es el chequeo o revisión de algo para comprobar que se encuentre en buen estado o cumpla con lo que se le especificó además de que se hacen para encontrar posibles fallas, errores o desperfectos que puedan afectar el rendimiento o funcionalidad del objeto en cuestión..
En el caso del software es la ejecución de un programa con la intención de descubrir un error, se suele utilizar una técnica experimental para la búsqueda de errores en los programas.
Las pruebas de software son una parte importante pero muy costosa del proceso de desarrollo de software
Pueden llegar a representar entre el 30 y 50 % del costo total del desarrollo del software [Myers, 2004]
Sin embargo, los costos de las fallas en un software en operación pueden llegar a ser mucho mayores (catastróficos)

DESARROLLO

Pruebas de Integración

La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté deacuerdo con el que dicta el diseño. La integración puede ser descendente si se integran los módulos desde el control o programa principal, o bien, ascendente, si la verificación del diseño empieza desde los módulos más bajos y de allí al principal. La selección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

Pruebas de Sistema

Las pruebas de sistema tienen por objetivo comprobar que el sistema, que

ha superado las pruebas de integración, se comporta correctamente con su entorno

(otras máquinas, otro hardware, redes, fuentes reales de información,

etc.).

Bajo este nivel de pruebas encontramos varios subniveles :

1) Pruebas de recuperación. Consisten en forzar el fallo del software y comprobar que la recuperación se lleva a cabo de manera correcta, devolviendo al sistema a un estado coherente.

2) Pruebas de seguridad. Intentan verificar que los mecanismos de protección incorporados al sistema lo protegerán, de hecho, de penetraciones inadecuadas.

3) Pruebas de resistencia. Estas pruebas están diseñadas para que el sistema requiera recursos en cantidad, frecuencia o volumen anormales. La idea es intentar que el sistema se venga abajo por la excesiva tensión a la que se lo somete.

4) Pruebas de rendimiento. En sistemas de tiempo real o sistemas empotrados, es inaceptable que el software proporcione las funciones requeridas fuera de las condiciones de rendimiento exigidas. 

CONCLUSIONES

Todas las pruebas que realicemos nos sirven para comprobar el buen funcionamiento de nuestro software así como reparar o mejorar cualquier defecto que se tenga en él.

FUENTES

http://www.academica.mx/blogs/las-pruebas-integraci%C3%B3n-software

https://sistemas.uniandes.edu.co/~isis4713/dokuwiki/lib/exe/fetch.php?media=isis4713-pruebasintegracion.pdf

http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-Integracion.pdf

https://www.lsi.us.es/docencia/get.php?id=6731

Diagrama y Grafo.

POSIBLES CAMINOS:

1. P1 P2 
2. P1 P3
3. P2
4. P3
5. P1 P2 P3 
6. P1 P3 P2
7. P4 P5
8. P4 P6
9. P4 P5 P4 P5
10. P4 P6 P4 P6 
11. P4 P5 P4 P6
12. P4 P6 P4 P5

INTRODUCCIÓN.

Una prueba es el chequeo o revisión de algo para comprobar que se encuentre en buen estado o cumpla con lo que se le especificó además de que se hacen para encontrar posibles fallas, errores o desperfectos que puedan afectar el rendimiento o funcionalidad del objeto en cuestión..


DESARROLLO


PRUEBAS DE CAJA BLANCA

Permiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa, se basan en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran por ciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.


PRUEBAS DE CAJA NEGRA

Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa.

Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba.

Estas pruebas se denominan de varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas por datos…los sinónimos son muchos y muy variados.

Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo, charter o sección específica de un software, es decir, es una manera de encontrar casos específicos en ese modulo que atiendan a su especificación.

Las pruebas de caja negra se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior.

Éstas, principalmente, se centran en módulos o charters de interfaz de usuario (pantalla, ficheros, canales de comunicación…) pero suelen ser útiles en cualquier módulo ya que todos o la mayoría tienen datos de entrada y salida que se pueden comprobar y verificar.

CONCLUSIONES

Las pruebas son una parte fundamental del software porque nos permiten evitar cualquier error y/o corregirlo para hacer más confiable nuestro software.

BIBLIOGRAFÍA

http://www.ecured.cu/index.php/Pruebas_de_caja_blanca
http://indalog.ual.es/mtorres/LP/Prueba.pdf
http://www.globetesting.com/2012/08/pruebas-de-caja-negra/