jueves, 5 de febrero de 2015

Pruebas de Sistema e Integración

Contenido

Introducción

Es interesante como puedes ver a través de varios tipos de pruebas diferentes, que en alguno de esos algo falle y no se note con algún otro tipo de prueba. Con esto se pueden tener perspectivas de algún programa de varias formas.

Desarrollo

Pruebas de Sistema

Las pruebas de Sistema o también conocidas como Pruebas de Software se van enfocadas a las investigaciones empíricas y técnicas, cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto hacia los que va enfocado el software. Puede ser visto como un proceso de control de calidad.
Estas pruebas te sirven para saber si cumple con sus objetivos o no. Esta prueba no se fija si funciona bien o no, sino que es lo que espera el cliente. Y por definición, estas pruebas son imposibles si no se cuenta con los requerimientos por escrito.
Algunos Ejemplos:
  • ·         Pruebas de rendimiento: Tienen como objetivo monitorear el rendimiento del proyecto o programa en cuanto a contexto de ejecución, es decir, se dedica a revisar que tan bien y que tan fluido corre el programa en una computadora. Para poder realizarse se necesita tener el proyecto completamente integrado.
  • ·         Pruebas de Stress: Se dedican a darle al programa una carga anormal, metiendolo en una situación poco normal para poder verificar su comportamiento en esta clase de situaciones. Básicamente es aventarle cuanto se le pueda y ver como lo maneja.
  • ·         Pruebas de Seguridad: Aquí es donde se verifica que los mecanismos de seguridad destinados a proteger el sistema (tales como el cifrado, la firma digital, etc.) se ejecuten debidamente y cumplan con su función.
  • ·         Pruebas de recuperación: En estas pruebas se intenta hacer fallar al programa para poder analizar su capacidad de recuperación. Se pueden ejecutar de muchas maneras

A pesar de ser éstas algunos ejemplos, esta prueba “engloba” todas las pruebas, ya que en pruebas funcionales se usan: pruebas integrales, pruebas de entrega, entre otros.
Ésta prueba por estos detalles puede llegar a ser confuso aunque sea objetiva y busque el “control de calidad”.

Pruebas de Integración

Las pruebas de integración o también llamadas pruebas integrales solo son realizadas en el ámbito del desarrollo del software y sólo se ejecutan una vez que se hayan realizado las pruebas unitarias.
Consiste en realizar pruebas para verificar un gran conjunto de partes de software. Hace énfasis en su operación conjunta.
Éstos pueden identificar el fallo del funcionamiento entre unidades. Puede ver que haya falta de coherencia entre una clase y otra. También puede que no sean compatibles.
Hay algunos tipos de errores con los que te puedes encontrar que son:
·         De Interfaz: puedes aceptar bien los datos pero a la hora de verlos, o ver alguna parte del programa no cuadre, etc.
·         No Funcionales: puedes ver el tiempo que se tarda en cargar los recursos, o que simplemente no cargue bien, etc.
·         De Configuración: puede estar utilizando alguna versión obsoleta, o que esté usando alguna que esté en prueba, pero que no ha sido publicada, etc.
·         De Integridad: que en algún momento algún proceso cambie el formato de un valor sin ser necesario, eliminar algún campo que necesite otra parte.
Existen varias formas de hacer esta prueba entre las cuales son: Big Bang, Descendente, Ascendente, Por parejas, Vecindades, Caminos de mensajes.

Conclusión

Es importante tener varias pruebas distintas porque puede que con algunas pruebas te haya funcionado el código, pero con una ya no. Esto te ayuda a que revises bien un programa antes de lanzarlo.

Referencias

Fernández, J. M. (Abrill 2011). Ingeniería de Software, Pruebas de integración. Febrero 5, 2015, de Universidad Veracruzana Sitio web: http://www.uv.mx/personal/jfernandez/files/2012/11/PruebaIntegracionEstructurada.pdf
varios. (2014). ISIS4713 - CBSE Pruebas de Integración. Febrero 5, 2015, de Universidad de los Andes Sitio web: https://sistemas.uniandes.edu.co/~isis4713/dokuwiki/lib/exe/fetch.php?media=isis4713-pruebasintegracion.pdf

Moreno, J. L.. (Mayo 17, 2004). Aplicación de un Sistema Experto para el desarrollo de Sistema Evaluador del modelo Capability Maturity Model (CMM) niveles dos y tres. Capítulo 5. Pruebas del Sistema y Conclusiones. Febrero 5, 2015, de Universidad de las Américas Puebla (UDLAP) Sitio web: http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/moreno_a_jl/capitulo_5.html

Fernández, J. M. (2010). Cápitulo 6 Pruebas de Sistema. Febrero 5, 2015, de Universidad Veracruzana Sitio web: http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-Sistema.pdf

viernes, 16 de enero de 2015

Pruebas de caja blanca y negra

Contenido


Introducción

En este tema veremos 2 tipos de prueba, el de caja negra y caja blanca. Cada uno de estos te permite ver cierta parte del proceso que quieres evaluar.  Estas pruebas se complementan totalmente, te permite ver toda la parte del sistema.

Desarrollo

Caja Negra

Las pruebas de Caja Negra puede ser un concepto muy abstracto ya que solo se dedica a mirar y también se le llega a llamar de diversas formas como de entrada/salida, caja opaca, pruebas inducidas, entre otras.
En estas pruebas sólo se centra en una sección específica de código, es decir es una manera de encontrar casos o errores específicos del programa. Estas pruebas se dedican solo a estudiar los datos, lo que ingresas y que sale sin preocuparse por lo que ocurre dentro.
Como cualquier otra prueba, las de caja negra se apoyan y basan en la especificación de requisitos y documentación funcional, estos requisitos suelen ser más complejos que los internos.
Esta prueba obviamente tiene la limitación de que solo ve los datos que entran y salen en el proceso, por lo tanto siempre es necesario realizar más de un tipo de prueba.

Caja Blanca

A las pruebas de Caja Blanca se les denomina así porque realiza las pruebas sobre las funciones internas de un modulo del programa. Entre las técnicas usadas son: 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 e interacciones, y luego para las interacciones máximas, máximas menos uno y más uno).
Las pruebas se realizan en un módulo específico, para luego realizar los de caja negra sobre varios subsistemas, que es la integración de varios.
Dentro de la caja blanca podemos encontrar las llamadas coberturas que revisa las sentencias, decisiones y condiciones del sistema.

Conclusión

Con esta investigación puedo concluir que las pruebas de caja negra y blanca se complementan totalmente, ya que con ambos puedes ver el proceso y los resultados. A la vez puedes probar una buena parte importante del código.

Referencias

Gómez, V. (2012). Pruebas de Caja Negra. Enero 16, 2015, de globe Testing Sitio web: http://www.globetesting.com/2012/08/pruebas-de-caja-negra/

Williams, L. (2006). White Box Testing. Enero 16, 2015, de North Carolina State University Sitio web: http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf

Grafos y Diagramas

Diagrama inicial

Diagrama (solo procesos)