jueves, 5 de febrero de 2015

Pruebas de integración y pruebas de sistema

Introducción

El siguiente paso después de hacer pruebas unitarias (pruebas de caja negra y caja blanca) es hacer pruebas de integración, que es correr y testear todos los módulos en grupo y no individualmente como se hacía anteriormente. Luego se procede a realizar las pruebas de sistema, que consisten en verificar que todo el programa se ejecute correctamente y además que se cumpla lo establecido en la documentación.

Desarrollo


Pruebas de integración

Las pruebas de integración es la fase en pruebas de software en el que los módulos de software individuales se combinan y se ensayaron como un grupo. Se produce después de que las pruebas unitarias y antes de las pruebas de validación. Las pruebas de integración buscan probar la combinación de las distintas partes de la aplicación para determinar si funcionan correctamente en conjunto.

Este tipo de pruebas es útil para ver como se comunican los servlets con las páginas de HTML, por ejemplo.

Hay diferentes tipos de pruebas de integración, pero sólo haremos énfasis en 2 de ellos:

  • Big Bang: En este enfoque, todos o la mayoría de los módulos desarrollados están acoplados juntos para formar un sistema de software completa o la mayor parte del sistema y luego se usa para las pruebas de integración.
  • De abajo hacia arriba y de arriba hacia abajo: En este enfoque, los componentes de más bajo nivel se prueban primero, después se utiliza para facilitar la prueba de los componentes de más alto nivel. El proceso se repite hasta que se prueba el componente en la parte superior de la jerarquía.

Pruebas de sistema

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la intefración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de los sistemas de información con los que se comunica.

Siempre tienen como guía los requerimientos establecidos por el cliente y se busca analizar si los satisfacen, tanto en los requerimientos positivos (qué se deseaba que haga) como en las limitaciones (qué se deseaba que no hiciera).

Las pruebas realizadas por el desarrollador a veces se dividen en alfa y beta. Las primeras se realizan en las instalaciones del desarrollador, mientras que las segundas se efectúan en las instalaciones del cliente, pero bajo control del desarrollador. Las pruebas que realiza el cliente por su cuenta se conocen a veces como pruebas de aceptación.

Para realizar las pruebas de sistema pueden prepararse los casos de prueba de forma similar a las pruebas de integración, guiándose por los casos de uso, pero es más común que las pruebas las inicie un operador humano.

Conclusiones

Como hemos visto, la fase de pruebas de integración y pruebas de sistema son las más importantes ya que en ellas se prueban todos los módulos juntos y se da la primera impresión de cómo se ejecutará el proyecto en su versión final. Es de suma importancia hacer estas pruebas antes de presentar la primera versión al cliente porque, en la posterior fase de pruebas que es la de aceptación, el usuario sólo verifica si el programa se ejecuta correctamente. Ahí ya no interviene en gran medida el tester.

Bibliografía


Gutiérrez, J. (2013). Introducción al proceso de pruebas. febrero 5, 2015, Sitio web: http://www.lsi.us.es/~javierj/cursos_ficheros/02.SR.pdf

González, J. M. (2012). Guía mínima de prueba de software orientado a objetos. febrero 5, 2015, Sitio web:http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-Integracion.pdf

Hernández, J. (2011). Ingeniería del software, febrero 5, 2015, Sitio web: http://ocw.uc3m.es/ingenieria-informatica/ingeniera-del-software-iii/materialclase/ISIII_09_PRUE.pdf

Torres, C (2011). Pruebas. febrero 5, 2015, Sitio web: http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/torres_c_fr/capitulo7.pdf

viernes, 16 de enero de 2015

Diagrama de flujo y grafo

Diagrama de flujo




Grafo



Posibles caminos:
  • Inicio-P1-P2-Fin
  • Inicio-P1-P3-Fin
  • Inicio-P4-Fin
  • Inicio-P4-P5-Fin
  • Inicio-P4-P6-Fin

Pruebas de caja blanca y de caja negra

Introducción

En esta entrada se definirán dos tipos de pruebas: las pruebas de caja blanca y de caja negra. Se enlistarán sus principales características, funciones, así como para qué nos sirven cada una de ellas.

Desarrollo


Pruebas de caja blanca

Son pruebas estructurales. Conociendo el código y siguiendo su estructura lógica, se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente lo que el diseño indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones.

Lo que se hace es escoger distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados. Su objetivo es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo) aunque también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

Las principales técnicas de diseño de pruebas de caja blanca son:
  • Pruebas de flujo de control
  • Pruebas de flujo de datos
  • Pruebas de bifurcación
  • Pruebas de caminos básicos
Pruebas de caja negra

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas ignoramos la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos.

La prueba de caja negra no sustituye a la prueba de caja blanca, sino es un enfoque complementario que intenta descubrir diferentes tipos de errores a los encontrados en los métodos de la caja blanca.

Con este tipo de pruebas podemos detectar:
  • Funciones incorrectas o ausentes.
  • Errores de interfaz
  • Errores en estructuras de datos o en accesos a las bases de datos externas.
  • Errores de rendimiento.
  • Errores de inicialización y terminación. 
Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y observando las salidas que se producen para determinar si la función se está desempeñando correctamente por el sistema bajo prueba. Las herramientas básicas son observar la funcionalidad y contrastar con la especificación.

Conclusiones

Cuando estamos creando un proyecto, una fase muy importante es la fase de pruebas. Su objetivo es encontrar los posibles errores que podamos encontrar en nuestro software. Por eso es indispensable saber qué tipos de pruebas hay. Los dos más importantes son los de caja blanca y los de caja negra. En el primero, podemos ver cómo se procesan los datos y en el segundo sólo los enfocamos en las entradas y las salidas de los datos.

Bibliografía


Carabati, M. (2013). Pruebas de caja negra y caja blanca. enero 16, 2015, Sitio web: https://prezi.com/sjwfwmix7slk/pruebas-de-caja-negra-y-caja-blanca/

Torres, M. (2011). Técnicas de prueba. enero 16, 2015, Sitio web: http://indalog.ual.es/mtorres/LP/Prueba.pdf

Montes, L. (2010). Casos de prueba. Caja blanca, Sitio web: http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.2%20prb-cal-mant.pdf