Etapas de las pruebas

1,982 views

Published on

pruebas de integracion, pruebas unitarias, depuracion, pruebas de excepcion. implementacion

  • Be the first to comment

Etapas de las pruebas

  1. 1. Etapas de las pruebas Etapas de las pruebas
  2. 2. 2 ”Año de la Promoción de la Industria Responsable y del Compromiso Climático” UNIVERSIDAD NACIONAL “SAN LUIS GONZAGA” DE ICA FACULTAD DE INGENIERÍA DE SISTEMAS Angulo Gasco, Jesús Camana Infanzón, Giovanni Neira Lovera, Kathia Toralva Baldeón, Deiby Villafuerte Sotelo, Jean Ing. Antonio Alonso Morales Loaiza Ica – 2014 ETAPAS DE LAS PRUEBAS
  3. 3. 3 DEDICATORIA El presente trabajo lo dedicamos a nuestros padres; a quienes les debemos todo lo que tenemos en esta vida. A Dios, ya que gracias a él tenemos esos padres maravillosos, los cuales nos apoyan en nuestras derrotas y celebran nuestros triunfos. A nuestros profesores quienes son nuestros guías en el aprendizaje, dándonos los últimos conocimientos para nuestro buen desenvolvimiento en la sociedad.
  4. 4. AGRADECIMIENTOS A nuestros padres, que gracias a su esfuerzo y trabajo, hemos podido aprender cosas nuevas, que nos ayudaron a ser mejor cada día. A la universidad San Luis Gonzaga de Ica, que nos brinda la oportunidad de estudiar en sus aulas adquiriendo nuevos conocimientos.
  5. 5. 5 Índice Tabla de Figuras....................................................................................................................................7 Pruebas unitarias .................................................................................................................................8 1. Conceptos básicos...................................................................................................................8 2. Beneficios...................................................................................................................................9 2.1 Encuentra los problemas a tiempo...............................................................................9 2.2 Facilita el cambio.................................................................................................................9 2.3 Simplifica la integración ...................................................................................................9 2.4 Documentación .................................................................................................................10 2.5 Diseño ...................................................................................................................................10 3. Limitaciones...........................................................................................................................10 4. Aplicaciones ...........................................................................................................................11 4.1 Programación extrema...................................................................................................11 5. Técnicas ...................................................................................................................................12 6. Frameworks para pruebas de unidad..........................................................................12 Manejo de excepciones ...................................................................................................................13 1. Manejo de excepciones:.....................................................................................................13 1. Intento (try): .................................................................................................................14 2. Se lanza una excepción (throw): ...........................................................................15 3. La excepción es capturada (catch): ......................................................................15 4. Ejemplos de código:....................................................................................................17 Técnicas de depuración de programas.....................................................................................19 1. ¿Qué es el depurador?........................................................................................................20 2. Tipos de depuración ...........................................................................................................20 3. Proceso de depuración......................................................................................................20 4. Proceso de depuración típico..........................................................................................21
  6. 6. 6 4.1 Técnicas................................................................................................................................22 4.2 Anti depuración.................................................................................................................24 Pruebas de integración ...................................................................................................................25 1. El propósito............................................................................................................................26 2. Método......................................................................................................................................27 3. Enfoques..................................................................................................................................30 4. Limitaciones...........................................................................................................................31 5. Consejos...................................................................................................................................31 Implementación de pruebas .........................................................................................................32 1. Frameworks y Herramientas para Unit Testing e Integration Testing...........32 1.1. Frameworks y Herramientas en .Net...................................................................32 1.2. Frameworks y Herramientas en Java ..................................................................34 1.3. Frameworks y Herramientas en JavaScript ......................................................35 1.4. Frameworks y Herramientas en Python ............................................................36 2. Implementación de Pruebas Unitarias ........................................................................36 3. Implementación de Pruebas de Integración..............................................................46 6. Conclusiones y Recomendaciones .........................................................................................51 Bibliografía............................................................................................................................................52
  7. 7. 7 Tabla de Figuras Figura 1 El simbolo de Depuracion............................................................................................20 Figura 2Proceso de Depuracion ..................................................................................................21 Figura 3 Jerarquia de Pruebas......................................................................................................26 Figura 4 Pruebas de Caja Negra...................................................................................................27 Figura 5 Pruebas de Caja Blanca .................................................................................................28 Figura 6 Pruebas de Caja Gris.......................................................................................................29 Figura 7 Dialogo de Nuevo Proyecto .........................................................................................37 Figura 8 Código a Probar................................................................................................................37 Figura 9 Resultado de Pruebas ....................................................................................................39 Figura 10 Estructura del Proyecto de Java..............................................................................39 Figura 11 Menu para Agregar un Test ......................................................................................40 Figura 12 Cuadro de Dialogo de Nueva Clase.........................................................................40 Figura 13 Resultados de las Pruebas en Eclipse ..................................................................41 Figura 14 Código Js a probar.........................................................................................................42 Figura 15 Estructura del Proyecto en js...................................................................................42 Figura 16 Resultado de las Pruebas en Buster.js..................................................................44 Figura 17 Estructura del Proyecto en Python........................................................................45 Figura 18 Nuevo Test en Python.................................................................................................45 Figura 19 Resultados de Pruebas en Visual Studio..............................................................46 Figura 20 Nueva Prueba de UI .....................................................................................................47 Figura 21 Cuadro de Generación de UI Test...........................................................................47 Figura 22 Grabación de pasos en el Navegador ....................................................................47 Figura 23 Menú de Grabación de UI Test.................................................................................48 Figura 24 Prueba de UI con Assert.............................................................................................48 Figura 25 Estructura de Proyecto de Selenium.....................................................................48 Figura 26 Cuadro de Dialogo de Nueva Clase.........................................................................49
  8. 8. 8 1.Conceptos básicos. Es un método de prueba de software por el cual unidades de código fuente, conjunto de pocos o muchos módulos de programas, asociaciones a control de datos, uso de procedimientos y procedimientos operativos se deben probar y ver si son actos para su uso. Intuitivamente, uno puede ver una unidad como la parte más pequeña testeable de una aplicación. En programación orientada a objetos, una unidad es a menudo una interfaz, como una clase, pero podría ser un método individual. Las pruebas unitarias son fragmentos códigos creados por los desarrolladores o por tester de caja blanca durante el proceso de desarrollo. La anatomía de una prueba de unidad está compuesto por tres partes: preparar, actuar y afirmar. En preparar se hace todo lo necesario entre precondiciones y entradas, luego para actuar se pone el objeto o método bajo la prueba y por último se afirman los resultados esperados. Pruebas unitarias
  9. 9. 9 2.Beneficios. La meta de las pruebas de unidad es aislar cada parte del programa y mostrar que partes individuales son correctas. Proporciona un estricto contrato escrito que un trozo del código debe satisfacer. 2.1 Encuentra los problemas a tiempo. Las pruebas de unidad encuentran problema en el ciclo de desarrollo. En TDD, que se usa frecuentemente en Programación extrema y Scrum, se crean las pruebas de unidad antes de escribir el código en sí. Cuando las pruebas pasan, el código se considera completa. Si las pruebas fallan, se consideran que es un error, ya sea por el código modificado o por la propia prueba. Las pruebas de unidad permiten localizar defectos o errores fácilmente localizables, ya que estas alertan al equipo de desarrollo del problema antes de entregar código a testers o clientes, ya que esto se realiza en etapas tempranas del ciclo de desarrollo. 2.2 Facilita el cambio Permite al desarrollador refactorizar código después de que haya pasado la prueba y asegurarse de que el modulo continua funcionando correctamente. El procedimiento es escribir casos de prueba para todas las funciones y los métodos para que cada vez que un cambio causa un fallo, se puede identificar rápidamente. A través de la práctica de mantenimiento, las pruebas seguirán reflejando precisión en el uso del ejecutable y del código de cara a cualquier cambio. 2.3 Simplifica la integración Las pruebas de unidad reducen la incertidumbre en las propias unidades, y se puede usar el enfoque Bottom-up en estilo de pruebas. Al probar las partes de un programa para luego probar la suma de sus partes, se hacen más fáciles las pruebas de integración
  10. 10. 10 2.4 Documentación Proporcionan una especie de documentación viva del sistema. Los desarrolladores aprenden que funcionalidad es proporcionada por una unidad y pueden ver cómo usarlo en las pruebas unitarias para tener comprensión básica de la interfaz de unidad (API). Las pruebas de unidad muestran características que indican el uso adecuado o inadecuado de la unidad. Por otro lado, la documentación narrativa ordinaria es más sensible a irse a la deriva de la implementación del programa, por lo tanto se convertirá en obsoleta. 2.5 Diseño Cuando se desarrolla con un enfoque basado en pruebas, la combinación de escribir la prueba unitaria para especificar la interfaz, más la actividad de refactorizar después de pasar la prueba, puede tomar lugar un diseño formal de este. Cada prueba de unidad puede ser vista como un elemento de diseño que especifica clases y métodos. 3.Limitaciones Las pruebas no pueden mostrar todos los errores en el programa, ya que no se pueden evaluar todas las rutas de ejecución. Lo mismo la pasa con las pruebas unitarias ya que solo prueban funcionalidad de las unidades ellos mismos.  No se detectan errores de integración o errores a nivel de sistema más amplio tales como rendimiento.  No demuestran una ausencia total de errores.  Es necesario el uso de otras técnicas como la aplicación de métodos formales para probar que un componente de software no tenga comportamientos inesperados.  Demanda de esfuerzo, se estima que por cada línea de código escrita, se escriben de 3 a 5 líneas de código para probar.
  11. 11. 11  Existe secciones de código que no pueden ser fácilmente probados en absoluto, por ejemplo que son no deterministas o implican múltiples hilos. Además es probable que el código de prueba tenga errores al igual que el código que se prueba.  Dificultad de establecer pruebas realistas y útiles, es necesario crear condiciones iniciales relevantes como parte del comportamiento del sistema completo, si las condiciones iniciales no son correctas, el código de prueba no se ejecuta en un contexto realista.  La carencia de un sistema de control de versiones, ya que si existen pruebas que anteriormente pasan las pruebas y posteriormente no lo hace, desde la lista de cambios hechos, se podría regresar el código a un estado anterior.  El problema del software embebido, puesto que el software se desarrolla en sistema diferente al que finalmente se ejecutara. No se podrán ejecutar las pruebas unitarias en el entorno de implementación real. 4.Aplicaciones 4.1 Programación extrema. Las pruebas unitarias son la piedra angular de la programación extrema, que esta automatizado en base a un framework de pruebas unitarias. Esta utiliza la creación de pruebas unitarias para el desarrollo basado en pruebas (TDD), el desarrollador escribe un caso de prueba ya sea por un requisito de software o un defecto. Producirá un error, ya sea porque el requisito no se ha implementado todavía o porque se expone intencionalmente a un defecto. La programación extrema obliga a una prueba de todo lo que se puede romper estratégicamente por sobre la prueba en cada ruta de ejecución del método tradicional, todo esto lleva a crear menos pruebas que el método tradicional. La programación extrema se limita a reconocer las pruebas raramente exhaustivas y
  12. 12. 12 proporciona orientación para identificar en forma eficaz con recursos limitados (tiempo). Las pruebas de unidad son fundamentales para el concepto de diseño emergente. Como el diseño emergente es muy dependiente de la refactorización, estas pruebas son un componente integral. 5.Técnicas Las pruebas unitarias están comúnmente automatizadas, pero aun así se pueden realizar en forma manual. La IEEE no está a favor de ninguno. El objetivo de estas pruebas es aislar una unidad y validarla. El enfoque manual puede emplear documento de instrucción paso a paso. Sin embargo, la automatización es eficaz para lograr muchos beneficios. Para realizar plenamente el efecto de aislamiento durante el uso de un enfoque automático, la unidad o código bajo prueba deberá probarse fuera de su ambiente natural, en otras palabras se ejecuta en el exterior de donde fue creada. Pruebas de esta manera revela innecesarias dependencias del código probado. Durante la ejecución de pruebas se registran las pruebas que no cumplan algún criterio. Muchos Frameworks marcan las fallas y reportan estos incluso su resumen y dependiendo de la gravedad de la falla, se pueden detener ejecuciones posteriores. Los patrones de diseño, pruebas unitarias y refactorización a menudo trabajan juntos para que surja mejor solución. 6.Frameworks para pruebas de unidad Son a menudo productos de terceros que no se distribuyen como parte de la suite del compilador. Ayudan al proceso de pruebas de unidad, estando en una variedad amplia de lenguajes de programación. Es posible probar sin el uso de Frameworks al escribir código que se ejecutan las unidades bajo pruebas de afirmación, manejo de excepciones y mecanismos para señalar errores. Es bueno dejas la puerta abierta para el uso de pruebas unitarias, ya que tener pocas pruebas de unidad es apenas algo bueno a no tener ninguna, mientras que tener un framework en esta situación, se haría relativamente fácil.
  13. 13. Antes de entrar en el tema de las excepciones en programación, se ha de matizar en el concepto de qué son las excepciones, vistas desde un punto de vista fuera y dentro del mundo de la programación. En el lenguaje humano, una excepción es un elemento excluyente de una regla, y de forma convencional se ha extendido esta definición. En el lenguaje máquina, una excepción se trata, de forma general, de algo que no se espera que ocurra, pero que puede ocurrir, similar al tratamiento de errores, pero de los errores en tiempo de ejecución. A veces estas excepciones, para una máquina, no son casos que no deberían estar contemplados, tal y como un programador se lo asigna, sino que pueden ser indicadores para comprobar que realmente todo está marchando bien o no. 1.Manejo de excepciones: Una excepción es un error que puede ocurrir debido a una mala entrada por parte del usuario, un mal funcionamiento en el hardware, un argumento inválido para un Manejo de excepciones
  14. 14. 14 cálculo matemático, etc. Para remediar esto, el programador debe estar atento y escribir los algoritmos necesarios para evitar a toda costa que un error de excepción pueda hacer que el programa se interrumpa de manera inesperada. El manejo de excepciones se basa en un mecanismo cuyo funcionamiento tiene tres etapas básicas: 1. Se intenta ejecutar un bloque de código y se decide qué hacer si se produce una circunstancia excepcional durante su ejecución. 2. Se produce la circunstancia: se “lanza” una excepción (en caso contrario el programa sigue su curso normal). 3. La ejecución del programa es desviada a un sitio específico donde la excepción es “capturada” y se decide que hacer al respecto. Para las tres etapas anteriores existen tres palabras claves específicas: try, throw y catch. El detalle del proceso es como sigue. 1. Intento (try): En síntesis podemos decir que el programa se prepara para cierta acción, decimos que "lo intenta". Para ello se especifica un bloque de código cuya ejecución se va a intentar ("try-block") utilizando la palabra clave try. try { // Bloque de código-intento ... } El juego consiste en indicar al programa que si existe un error durante el "intento", entonces debe lanzar una excepción y transferir el control de ejecución al punto donde exista un manejador de excepciones ("handler") que coincida con el tipo lanzado. Si no se produce ninguna excepción, el programa sigue su curso normal. De lo dicho se deduce inmediatamente que se pueden lanzar excepciones de varios tipos y que pueden existir también receptores (manejadores) de varios tipos; incluso manejadores "universales", capaces de hacerse cargo de cualquier
  15. 15. 15 tipo de excepción. A la inversa, puede ocurrir que se lance una excepción para la que no existe manejador adecuado, en cuyo caso... (La solución más adelante). Así pues, try es una sentencia que en cierta forma es capaz de especificar el flujo de ejecución del programa. Un bloque-intento debe ser seguido inmediatamente por el bloque manejador de la excepción. 2. Se lanza una excepción (throw): Si se detecta una circunstancia excepcional dentro del bloque-intento, se lanza una excepción mediante la ejecución de una sentencia “throw”. Por ejemplo: if (condición) throw "overflow"; Es importante advertir que, salvo los casos en que la excepción es lanzada por las propias librerías, estas no se lanzan espontáneamente. Es el programador el que debe utilizar una sentencia (generalmente condicional) para, en su caso, lanzar la excepción. Todas las excepciones deben ser lanzadas desde el interior de un “bloque- intento” y permite que sean de cualquier tipo. Como se ha apuntado antes, generalmente son un objeto (instancia de una clase) que contiene información. Este objeto es creado y lanzado en el punto de la sentencia “throw” y capturado donde está la sentencia catch. El tipo de información contenido en el objeto es justamente el que nos gustaría tener para saber qué tipo de error se ha producido. En este sentido puede pensarse en las excepciones como en una especie de correos que transportan información desde el punto del error hasta el sitio donde esta información puede ser analizada. 3. La excepción es capturada en un punto específico del programa (catch): Esta parte del programa se denomina manejador ("handler"); se dice que el "handler" captura la excepción. El “handler” es un bloque de código diseñado
  16. 16. 16 para manejar la excepción precedida por la palabra “catch”. Se requiere que exista al menos un manejador inmediatamente después de un bloque “try”. Es decir, se requiere el siguiente esquema: try { //bloque de código que se intenta ... } catch (...) { //bloque de manejador de posibles excepciones ... } ... //continua la ejecución normal El "handler" es el sitio donde continua el programa en caso de que ocurra la circunstancia excepcional (generalmente un error) y donde se decide que hacer. A este respecto, las estrategias pueden ser muy variadas (no es lo mismo el programa de control de un reactor nuclear que un humilde programa de contabilidad). En último extremo, en caso de errores absolutamente irrecuperables, la opción adoptada suele consistir en mostrar un mensaje explicando el error. Puede incluir el consabido "Avise al proveedor del programa" o bien generar un fichero texto (por ejemplo: error.txt) con la información pertinente, que se guarda en disco con objeto de que pueda ser posteriormente analizado y corregido en sucesivas versiones de la aplicación. En resumen se ha dicho que “try” es una sentencia que en cierta forma es capaz de especificar el flujo de ejecución del programa; en el fondo el mecanismo de excepciones funciona como una especie de sentencia “if … then … else”.
  17. 17. 17 4. Ejemplos de código:  Ejemplo de manejo de excepciones en Java: import java.io.IOException; // ... public static void main(String[] args) { try { // Se ejecuta algo que puede producir una excepción } catch (IOException e) { // manejo de una excepción de entrada/salida } catch (Exception e) { // manejo de una excepción cualquiera } finally { // código a ejecutar haya o no excepción } }  Ejemplo de manejo de excepción en Delphi: procedure TForm1.Button1Click(Sender : TObject); begin try try a := b / c; finally // Este código siempre se ejecuta, //Independientemente de si ocurre o no una excepción. end; except on e:EZeroDivide do // Manejo de la excepción División por cero. on e:Exception do // Manejo de una excepción "genérica". end; end;
  18. 18. 18  Ejemplo de manejo de excepciones en Python: try: result = x / y except ZeroDivisionError: print "division by zero!" else: print "result is", result finally: print "executing finally clause"  Ejemplo de manejo de excepciones en C#: Using System; Class test{ Public static void Main(string[] args){ double a = 10, b = 20, c = 0; try{ c = a + b; Console.WriteLine(“{0:f} + {1:f} = {2:d}”, a, b, c); } catch(FormatException) { Console.WriteLine(“Ha ocurrido un error de formato”); } catch(Exception e) { Console.WriteLine(“Error: ” + e.Message); } } }
  19. 19. La depuración de programas es el proceso de identificar y corregir errores de programación. En ingles se le conoce como debugging, ya que se asemeja a la eliminación de bichos (bugs), manera informal como se le conoce a los errores de programación. Cuando se escriben programas, es normal cometer errores (bugs). De hecho, en promedio, un programador comete un error cada 10 líneas de programa. Esto significa que la probabilidad de que el programa funcione a la primera vez es prácticamente nula. Por lo tanto, el desarrollo de un programa siempre incorpora una etapa de depuración (debugging), que consiste en buscar y resolver los errores cometidos durante la programación. Para facilitar la etapa de depuración es conveniente usar herramientas especializadas para estos efectos. La más común es el depurador o también llamado debugger. Técnicas de depuración de programas
  20. 20. 20 1.¿Qué es el depurador? Un depurador es una herramienta que permite intervenir durante la ejecución de un programa, para saber cómo se está ejecutando. El depurador permite:  Ejecutar pasó a paso un programa (stepping).  Establecer puntos de detención (breakpoints).  Examinar el contenido de las variables y objetos.  Conocer el encadenamiento de llamadas de procedimientos.  Retomar la ejecución hasta un nuevo punto de detención. 2.Tipos de depuración Existen 2 tipos de depuración: difícil y profunda.  Una depuración difícil significa que hay problemas con la lógica del programa.  Una depuración profunda solo mejora el programa, lo libera de errores sencillos o busca código optimizable. 3.Proceso de depuración El proceso de depuración comienza con la ejecución de un casi de prueba, luego se evalúan los resultados y se encuentra una falta de correspondencia entre el desempeño esperado y el real. Figura 1 El símbolo de Depuración
  21. 21. 21 La depuración siempre arroja dos resultados:  Se encuentra y se corrige la causa.  No se localiza la causa. En este último caso, la persona encargada debe sospechar la causa y diseñar uno o más casos de pruebas que ayuden a convalidar esa sospecha y avanzar hacia la corrección del error de manera iterativa. 4.Proceso de depuración típico Normalmente, el primer paso en la depuración es intentar reproducir el problema, Esta puede ser una tarea no trivial, por ejemplo, como con procesos paralelos o algunos errores de software inusuales, Además, el entorno del usuario especifico y el historial de uso puede hacer que sea fácil de reproducir el problema. Después de que se reproduce el error, es posible que se simplifiquen para que sea más fácil de depurar la entrada del programa. Por ejemplo, un error en el compilador puede hacer que falle al analizar algún archivo fuente grande. Sin embargo, después de la simplificación del caso de pruebas solo algunas líneas del archivo fuente original puede ser suficiente para reproducir el mismo accidente. Esta simplificación Figura 2 Proceso de Depuración
  22. 22. 22 se puede hacer de forma manual, utilizando un divide y vencerás. El programador tratara de eliminar algunas partes del caso de prueba original y comprobar si el problema persiste. Al depurar el problema de una interfaz gráfica de usuario, el programador puede tratar de pasar por alto alguna interacción con el usuario de la descripción original de problema y verificar las acciones restantes es suficiente para los bugs que aparecen. Después de que el caso de prueba está suficientemente simplificada, un programador puede utilizar una herramienta de depurador para examinar los estados del programa y rastrear el origen del problema. Alternativamente, puede utilizar el rastreo. En casos sencillos, la localización se encuentra a pocos sentencias “print” que imprimir los valores de las variables en ciertos puntos de la ejecución del programa. 4.1 Técnicas  Depuración de impresión (o rastreo) El tipo más común es la depuración de impresión. Imprimir la depuración está habilitada cuando se ejecuta un programa. A medida que el programa se está ejecutando, aparece una lista de errores, ya que vienen a lo largo de la ejecución del programa. Esto puede ayudar a los desarrolladores a identificar problemas con la forma en que el programa se ejecuta.  La Depuración remota Depuración remota es similar a la impresión de depuración, pero el programa se ejecuta en un equipo diferente desde el depurador. Para ello, el equipo que ejecuta el programa y el ordenador que se está depurando el equipo debe estar unido a una red. Después de esto, el programa se ejecuta y el depurador contiene información acerca de lo que los errores que pueda contener. Esto es útil para identificar cómo una aplicación puede ejecutarse en diferentes plataformas o equipos  Depuración post-mortem Errores de depuración post- mortem identificados después de un programa que ya se ha estrellado. Esto se realiza mediante la instalación de un archivo que registra el
  23. 23. 23 estado de la aplicación, ya que se ha estrellado. Esta información se puede utilizar para identificar por qué la ejecución puede haber fallado.  Depuración Delta Delta depuración automatiza el proceso de depuración, y analiza sistemáticamente a través de una aplicación para los errores. Estos errores están aislados del resto del programa. Esto permite a los desarrolladores ver cómo su programa cuando estos eliminan los bugs molestos del contexto de su aplicación.  Squeeze saff La solución en este problema se aísla mediante la ejecución de dos procesos. El primero es un proceso de alto nivel que se utiliza para identificar los principales problemas en la aplicación. A continuación, la unidad de pruebas específicas se ejecuta para aislar el problema exacto o error. Esto acelera el proceso de depuración al mismo tiempo, identificar los problemas exactos.  Depuración para sistemas embebidos. En contraste con el software de ordenador entorno de diseño de uso general, una característica fundamental de entornos integrados es el gran número de diferentes plataformas disponibles para los desarrolladores (arquitecturas de CPU, proveedores, sistemas operativos y sus variantes). Los sistemas integrados son, por definición, no diseños de propósito general: se desarrollan típicamente para una sola tarea (o pequeña gama de tareas), y la plataforma se elige específicamente para optimizar esa aplicación. No sólo este hecho de hacer la vida difícil para los desarrolladores de sistemas embebidos, también hace que la depuración y control de los sistemas más duro también, ya que se necesitan diferentes herramientas de depuración en diferentes plataformas. Para identificar y corregir errores en el sistema (por ejemplo, problemas lógicos o de sincronización en el código, o un error de diseño en el hardware); Para recopilar información sobre los estados de funcionamiento del sistema que puede ser utilizada para analizar el sistema: para encontrar maneras de aumentar
  24. 24. 24 su rendimiento o para optimizar otras características importantes (por ejemplo, consumo de energía, fiabilidad, respuesta en tiempo real, etc.) 4.2 Anti depuración Es la aplicación de una o más técnicas de código informático que impide los intentos de ingeniería inversa o depuración de un proceso de destino, Se utiliza activamente en los esquemas legítimos de protección de copia, pero también es utilizado por el malware, para disfrutar su detección y eliminación. Las técnicas utilizadas en la lucha contra la depuración son:  Api basada en: Comprueba la existencia de un depurador utilizando la información del sistema. Excepción basada en: compruebe si las excepciones son interferidos.  Bloques de proceso e hilo: compruebe si los bloques de proceso e hilo han sido manipuladas.  Código modificación: comprobar modificaciones de código hechas por un depurador manipular los puntos de interrupción de software.  Hardware y registrarse base: comprobar si los puntos de interrupción de hardware y los registros de la CPU.  El tiempo y latencia: comprobar el tiempo necesario para la ejecución de instrucciones.
  25. 25. 25  La detección y sanción del depurador Prueba la interacción entre dos o más elementos, que pueden ser clases, módulos, paquetes, subsistemas, etc. incluso la interacción del sistema con el entorno de producció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 (unit test) y estructurar un programa que esté de acuerdo 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 del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias. Pruebas de integración
  26. 26. 26 Figura 3 Jerarquía de Pruebas Las pruebas de integración se llevan a cabo después de pruebas unitarias y antes System Testing. El prerrequisito de Pruebas de integración es tener dos módulos diferentes, de haber probado para las pruebas unitarias. Ejemplo: Durante el proceso de fabricación de un bolígrafo, la tapa, el cuerpo, la cola y el clip, el cartucho de tinta y el bolígrafo se producen por separado y se prueban unitariamente por separado. Cuando dos o más unidades están listas, se ensamblan, se lleva el acabo las pruebas de integración. Por ejemplo, si la tapa encaja en el cuerpo o no. 1.El propósito El propósito de las pruebas de integración es exponer los fallos en la interacción entre unidades integradas, como también es verificar, el rendimiento y la fiabilidad funcional, y exigencias impuestas a los principales elementos de diseño. Estos "objetos de diseño", es decir, los conjuntos (o grupos de unidades), se ejercen a través de sus interfaces usando pruebas de caja negra.
  27. 27. 27 2.Método Se puede usar cualquiera de los métodos.  Pruebas de Caja Negra  Pruebas de Caja Blanca  Pruebas de Caja Gris Normalmente, el método depende de tu definición en "Unit testing".  Pruebas de Caja Negra También conocido como las pruebas de comportamiento, es un método de pruebas de software en el que la estructura / diseño / implementación interna del elemento que se está probado no es conocido por el tester. Estas pruebas pueden ser funcional o no funcional, aunque por lo general funcional. Figura 4 Pruebas de Caja Negra Este método se llama así debido a que el programa de software, a los ojos del tester, es como una caja de color negro; dentro de la cual uno no puede ver. Este método intenta encontrar errores en las siguientes categorías:  Funciones incorrectas o faltantes  Error Interfaz  Errores en estructuras de datos o el acceso de base de datos externa  Errores de comportamiento o rendimiento  Los errores de inicialización y terminación
  28. 28. 28 Ejemplo Un Tester, sin el conocimiento de las estructuras internas de un sitio web, pone a prueba las páginas web mediante el uso de un navegador; usando solo (clics, las pulsaciones de teclado en el sitio web) esperando la verificación de las salidas contra el resultado esperado del flujo de navegación.  Pruebas de caja Blanca Es un método de pruebas de software en el que la estructura / diseño / implementación interna del elemento que se probó se sabe por el Tester. El Tester elige entradas para ejercer caminos a través del código y determina las salidas apropiadas. Las pruebas de caja blanca está son probados más allá de la interfaz de usuario. Este método se llama así debido a que el programa de software, a los ojos del tester, es como una caja blanca / transparente; dentro de la cual se ve claramente la estructura. Figura 5 Pruebas de Caja Blanca Ejemplo Un Tester, por lo general un desarrollador, estudia el código de la aplicación de un campo determinado, en una página web, determina todas entradas (válidos y no válidos) y verifica los resultados en contra de los resultados esperados, los cuales también se determina mediante el estudio del código de implementación.
  29. 29. 29  En Pruebas de caja Gris Un tester de caja negra no tiene conocimiento de la estructura interna de la aplicación para ser probado, mientras que un Tester de caja blanca conoce la estructura interna de la aplicación. Un Tester de caja gris sabe parcialmente la estructura interna, que incluye el acceso a la documentación de las estructuras de datos internas, así como los algoritmos utilizados. Las pruebas de caja gris son beneficiosos, ya que toma la técnica sencilla de pruebas de caja negra y lo combina con los sistemas específicos de código (pruebas de caja blanca). Efectos negativos  Cobertura de código parcial: En las pruebas de caja gris, el código fuente o binarios están desaparecidos debido al acceso limitado a la estructura interna de las aplicaciones que se traduce en un acceso limitado para el recorrer el camino del código.  Identificación de defectos: En aplicaciones distribuidas, es difícil de identificar los defectos y asociarlos. Figura 6 Pruebas de Caja Gris
  30. 30. 30 Ejemplo Un ejemplo de pruebas de caja gris sería cuando se estudian los códigos de dos unidades / módulos (Método de ensayo Caja Blanca) para el diseño de casos de prueba y las pruebas reales se realizan utilizando las interfaces expuestas (método de Pruebas de Caja Negra) y es útil en la integración de pruebas. 3.Enfoques o Big Bang es un enfoque de Pruebas de Integración, donde todos o la mayoría de las unidades se combinan juntos y probados en una sola vez. Se adopta este enfoque cuando el equipo de pruebas recibe todo el software en un paquete. Entonces, ¿cuál es la diferencia entre el Big Bang entre Pruebas de Integración y Pruebas del Sistema? Bueno, las pruebas anteriores sólo ven las interacciones entre las unidades mientras que el segundo pone a prueba todo el sistema.  El método de Big Bang es muy eficaz para ahorrar tiempo en el proceso de pruebas de integración.  Sin embargo, si los casos de prueba y sus resultados no se registran correctamente, todo el proceso de integración será más complicado y puede impedir que el equipo de pruebas de lograr el objetivo de las pruebas de integración. o Top Down es un enfoque para pruebas de integración, donde las unidades de primer nivel son probados primero y unidades de nivel inferior se ponen a prueba paso a paso después de eso. Se necesitan Stubs de prueba para simular unidades de nivel inferior que pueden no estar disponibles durante las fases iniciales. Stubs de prueba un trozo de código usado como sustituto de alguna otra funcionalidad. Un Stubs puede simular el comportamiento de código existente. o ser el sustituto temporal para un código aún no desarrollado. o Bottom Up es un enfoque para pruebas de integración, donde las unidades de nivel inferior se prueban primero, las unidades nivel superior paso a paso
  31. 31. 31 después de este. Se adopta este enfoque cuando se sigue un enfoque de desarrollo ascendente. Se necesitan Drivers para simular unidades de nivel superior que pueden no estar disponibles durante las fases iniciales. Drivers de pruebas está apoyando código y los datos que se utilizan para proporcionar un entorno para las pruebas de parte de un sistema de aislamiento. Se le puede llamar como un módulo de software que se utiliza para invocar un módulo bajo prueba y proporcionar entradas de prueba, control y ejecución. o Sandwich / Hybrid es un enfoque de Pruebas de Integración, que es una combinación de los enfoques Top Down y Bottom Up. 4.Limitaciones Cualquier condición que no se mencionan en las pruebas de integración especificadas, en las afueras de la confirmación de la ejecución de los elementos de diseño, por lo general no pueden probar. 5.Consejos  Asegúrese de que tiene un documento de diseño de detalle adecuado donde las interacciones entre cada unidad están claramente definidos. De hecho, usted no será capaz de realizar pruebas de integración sin esta información.  Asegúrese de que tiene un sistema de gestión de configuración de software robusta en su lugar. O de lo contrario, tendrá un momento difícil el seguimiento de la versión correcta de cada unidad, sobre todo si la cantidad de unidades que integrarse es enorme.  Asegúrese de que cada unidad es de primera unidad de prueba antes de iniciar pruebas de integración.  En la medida de lo posible, automatizar sus pruebas, especialmente cuando se utiliza el enfoque de arriba hacia abajo o de abajo hacia arriba, ya que las pruebas de regresión es importante cada vez que integra una unidad, y las pruebas de regresión manual puede ser ineficiente.
  32. 32. unitarias y de integración Es importante mencionar que cuando nos referimos a la Implementación de las pruebas unitarias, es común referirnos también al proceso de desarrollo de las mismas, ya que ambas etapas son muy dependientes una de la otra y en muchos casos llegan a superponerse. 1.Frameworks y Herramientas para Unit Testing e Integration Testing 1.1. Frameworks y Herramientas en .Net a. MSTest, El Marco de pruebas unitarias de Visual Studio (MSTest) describe la suite de herramientas de pruebas unitarias de Microsoft integrado en algunas de las versiones de Visual Studio 2005 y versiones posteriores. El marco de pruebas unitarias se define en Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Las Implementación de pruebas
  33. 33. 33 pruebas unitarias creadas con el marco de pruebas unitarias se pueden ejecutar en Visual Studio o utilizando MSTest.exe, desde una línea de comandos. b. NUnit, NUnit es un framework open source de Pruebas de unidad para Microsoft .NET y Mono. Sirve al mismo propósito que JUnit realiza en el mundo Java, y es uno de muchos en la familia xUnit. NUnit.Forms es una expansión al framework núcleo NUnit y es también open source. Esto busca concretamente ampliar NUnit para que sea capaz de manejar pruebas de elementos de interfaz de usuario en Windows Forms. NUnit. ASP es una expansión al framework núcleo NUnit y es también open source. Esto busca concretamente ampliar NUnit para que sea capaz de manejar pruebas de elementos de interfaz de usuario en ASP.NET. c. xUnit, xUnit.net es un framework de código abierto, una herramienta de testing gratuito, centrado en la comunidad de unit testing en .NET. Escrito por el inventor original de NUnit v2, xUnit.net es la última tecnología para las pruebas unitarias en C#, VB.NET y otros lenguajes .NET. Funciona con ReSharper, CodeRush, TestDriven.NET y Xamarin. xUnit.net forma parte de la Galería Abierta ASP.NET cuyas fuentes están bajo la Fundación Outercurve. Está autorizado bajo la licencia Apache 2, que es aprobado por la OSI.
  34. 34. 34 1.2. Frameworks y Herramientas en Java a. JUnit, es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente. JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva modificación. b. TestNG, es un marco de pruebas inspirado en JUnit y NUnit pero introduciendo algunas nuevas funcionalidades que lo hacen más potente y fácil de usar. TestNG está diseñado para cubrir todas las categorías de pruebas: unitarias, funcionales, de extremo a extremo, la integración, etc. y requiere JDK 5 o superior. c. Selenium, es un entorno de pruebas de software para aplicaciones basadas en la web. Selenium provee una herramienta de grabar/reproducir para crear pruebas sin usar un lenguaje de scripting para pruebas (Selenium IDE). Incluye también un lenguaje específico de dominio para pruebas (Selanese) para escribir pruebas en un amplio número de lenguajes de programación populares incluyendo Java, C#, Ruby, Groovy, Perl, Php y Python. Las pruebas pueden ejecutarse entonces usando la mayoría de los navegadores web modernos en diferentes sistemas operativos como Windows, Linux y OSX. Está pensado principalmente para realizar pruebas de integración sobre sistemas web.
  35. 35. 35 1.3. Frameworks y Herramientas en JavaScript a. Karma, Una sencilla herramienta que permite ejecutar código JavaScript en múltiples verdaderos exploradores. El objetivo principal de Karma es hacer que su desarrollo TDD fácil, rápido y divertido. Karma no es un marco de pruebas, ni una biblioteca de aserciones. Karma simplemente lanza un servidor HTTP, y genera el archivo HTML corredor de prueba usted probablemente ya sabe de su marco de pruebas favorito. Así que para los propósitos de prueba se puede utilizar casi cualquier cosa. Ya existen plugins para la mayoría de los marcos de las pruebas comunes b. Buster.js, Buster.js es un toolkit para testing en JavaScript, al estar escrito en JavaScript es también una herramienta para testing en Node.js que incluye assertion library, etc. Hay una API pública para la mayoría de cosas. Puedes configurarlo para generar reportes de las pruebas automatizadas. Está integrado en proyectos conjuntos como ramp, una librería genérica de automatización para navegadores para temas de pruebas de integración. c. QUnit, QUnit es un framework JavaScript pruebas unitarias potente y fácil de usar. Es utilizado por los proyectos de jQuery, jQuery UI y jQuery Mobile y es capaz de probar cualquier código genérico JavaScript. QUnit fue desarrollado originalmente por John Resig como parte de jQuery. En 2008 consiguió su propia documentación en casa, el nombre y la API, permitiendo que otros lo utilizan para sus pruebas también. En el momento en que todavía dependía de jQuery. Una reescritura en 2009 fijó que QUnit funciona totalmente independiente.
  36. 36. 36 1.4. Frameworks y Herramientas en Python a. PyUnit, Este marco de pruebas unitarias, apodado 'PyUnit' por convención, es una versión en Python de JUnit. JUnit fue escrito por Kent Beck galletas inteligentes y Erich Gamma, y es, a su vez, una versión Java de marco de pruebas de Smalltalk de Kent. Cada uno es el framework de pruebas estándar de facto para su respectiva unidad de la lengua, y por lo tanto ambos son una base sólida para un marco Python eficaz y elegante. b. unittest.mock, unittest.mock es una biblioteca para realizar pruebas en Python. Esta le permite reemplazar partes de su sistema bajo prueba con objetos simulados y hacer afirmaciones sobre la forma en que se han utilizado. Después de realizar una acción, puede hacer afirmaciones sobre los que utilizaron métodos / atributos y argumentos con los que se les llama. Mock es muy fácil de usar y está diseñado para su uso con unittest. Mock se basa en el patrón "acción -> afirmación” en vez de 'record -> replay' utilizado por muchos mocking Frameworks. c. Splinter, es una herramienta open source para hacer testing de aplicaciones web usando Python. Este framework te permite automatizar acciones del navegador, como visitar páginas web e interactuar con sus elementos. Dado que Splinter nos permite automatizar acciones en el navegador puede emplearse para realizar pruebas en aplicaciones escritas no solo en Python. Splinter no está integrado a ningún framework de pruebas de aceptación pero posee una capa de abstracción para escribir su propia implementación. 2.Implementación de Pruebas Unitarias 2.1. Implementación en .Net usando MSTest La implementación de pruebas unitarias es una característica integrada en el IDE de Microsoft Visual Studio. A continuación describiremos el proceso básico para la creación de pruebas unitarias.
  37. 37. 37 Dentro de Visual Studio y como parte de la solución de nuestro proyecto procedemos a crear un proyecto de pruebas. Figura 7 Dialogo de Nuevo Proyecto Con el proyecto de pruebas creado, procedemos a agregar las referencias a los proyectos o piezas de software que se desean probar. Figura 8 Código a Probar
  38. 38. 38 Por defecto el proyecto de pruebas nos crea un caso de prueba de unitarias. Ahí agregaremos una prueba unitaria básica para ilustrar el ejemplo. [TestMethod] public void Test_calculadora_suma_funciona() { //Arrange var calculadora = new Calculadora(); var a = 5; var b = 1.99; var expeccted = 6.99; //Act var result = calculadora.Sumar(a,b); //Assert Assert.AreEqual(result, expeccted); } Siguiendo estas convenciones sencillas como marcar los métodos de prueba como TestMethod es suficiente para que el gestor de pruebas puede descubrir las pruebas unitarias, ejecutarlas y podamos ver los resultados.
  39. 39. 39 Figura 9 Resultado de Pruebas 2.2. Frameworks y Herramientas en Java usando JUnit Para ilustrar las pruebas unitarias en Java utilizaremos JUnit y el IDE Eclipse. Una vez que tengamos nuestro proyecto (pieza de software a probar) procedemos a asegurarnos que el proyecto cuente con las librerías externas (.jar) para realizar las pruebas. Figura 10 Estructura del Proyecto de Java Ahora agregamos un caso de pruebas utilizando el menú contextual en el proyecto: New > JUnit Test Case
  40. 40. 40 Figura 11 Menú para Agregar un Test Agregamos el nombre y configuramos el framework que usaremos (Junit3 en este cas). Figura 12 Cuadro de Dialogo de Nueva Clase Luego escribimos el test unitario utilizando las mismas convenciones que empleamos anteriormente.
  41. 41. 41 public class TestCalculadora extends TestCase { public void test_calculadora_funciona() { //Arrange Calculadora calc = new Calculadora(); float a = 9.99f; float b= 0.01f; float expected = 10f; //Act float result = calc.Sumar(a, b); //Assert assertEquals(expected, result, 0); } public static Test suite() { TestSuite suite = new TestSuite(TestCalculadora.class); return suite; } public static void main(String args[]) { junit.textui.TestRunner.run(suite()); } } Al emplear TestSuite permitimos que el entorno de JUnit descubra nuestros test y nos muestre los resultados al ejecutarlo. 2.3. Frameworks y Herramientas en JavaScript usando Buster.js Figura 13 Resultados de las Pruebas en Eclipse
  42. 42. 42 Para probar código escrito en JavaScript ya sea en aplicaciones escritas en node.js o en código estático (como mostraremos a continuación) podemos usar la suite de pruebas Buster.js que al ser solo un archivo .js puede integrarse en cualquier editor (brackets en este caso). El código anterior vamos a probarlo usando buster.js y el editor brackets, para ello agregamos una carpeta llamada test y dentro colocamos el script de buster que obtenemos de su web y creamos un archivo donde redactaremos nuestra prueba. Figura 15 Estructura del Proyecto en js Siguiendo la documentación de Buster, redactamos el test unitario siguiendo las mismas convecciones que usamos anteriormente. En nuestro archivo calculadora-test.js agregamos lo siguiente. var calculadora = new ViewModel(); var assert = buster.assert; buster.testCase("Calculadora tests", { Figura 14 Código Js a probar
  43. 43. 43 setUp: function () { }, "Suma funciona correctamente": { "should return 5": function () { //Arrange var a = 5.55; var b = 1.11; var re = 6.66; //Act var result = calculadora.suma(a,b); //Assert assert.equals(re,result); } } }); Una vez que tenemos escritos nuestro test, creamos una página HTML para ver los resultados de las pruebas, Buster.js te provee una plantilla con estilos básicos para que utilices como administrador de pruebas. <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>Test Calculadora</title> </head> <body> <script type="text/javascript" src="http://cdn.busterjs.org/releases/latest/buster- test.js"></script> <script type="text/javascript" src="../knockout- 3.1.0.js"></script> <script type="text/javascript" src="../calculadora.js"></script>
  44. 44. 44 <script type="text/javascript" src="calculadora- test.js"></script> </body> </html> En esa página referenciamos el script de las pruebas y los scripts a probar. Luego si vemos la página en el navegador podemos ver a Buster.js ejecutando nuestras pruebas. Figura 16 Resultado de las Pruebas en Buster.js 2.4. Frameworks y Herramientas en Python usando Py.test Para implementar las pruebas unitarias en Python usaremos el framework de pruebas integrada en la herramienta.
  45. 45. 45 Figura 17 Estructura del Proyecto en Python Una vez que tenemos nuestra aplicación, agregamos una prueba unitaria, para ello usamos el menú contextual y seleccionamos la opción de agregar un nuevo elemento. Figura 18 Nuevo Test en Python En el cuadro de dialogo seleccionamos la opción de Python Unit Test. En el archivo que se agrega a nuestra solución redactamos nuestras pruebas unitarias. import unittest from DemoPython import sumar class Test_testdemo(unittest.TestCase): def test_sumar_funciona(self): assert sumar(3,6) == 9
  46. 46. 46 if __name__ == '__main__': unittest.main() Una vez que hemos escrito nuestra prueba que podemos ver que es muy sencilla. Utilizamos el explorador de pruebas integrado en Visual Studio para ejecutar las pruebas y ver los resultados. 3.Implementación de Pruebas de Integración 3.1. Implementación en .Net usando MSTest MSTest incluye una característica que nos permite generar pruebas de integración o pruebas funcionales sobre la aplicación como tal. Figura 19 Resultados de Pruebas en Visual Studio
  47. 47. 47 Figura 20 Nueva Prueba de UI Al agregar este elemento se presenta un cuadro de dialogo donde debemos elegir entre agregar o grabar las acciones de pruebas y editar una prueba existente. Figura 21 Cuadro de Generación de UI Test En nuestro caso generaremos una nueva prueba. Al aceptar el cuadro de dialogo empezaremos a grabar las acciones que se realizan en el navegador, una vez que terminamos, usamos el botón generar para que se transforme en código de UI Test. Figura 22 Grabación de pasos en el Navegador
  48. 48. 48 Figura 23 Menú de Grabación de UI Test Los pasos generados se transforman en código que podemos corregir o agregar condiciones a verificar en forma de aserciones. Figura 24 Prueba de UI con Assert Y ahora podemos ejecutar y repetir los pasos y las aserciones. 3.2. Frameworks y Herramientas en Java y otros lenguajes usando Selenium Selenium es un framework que nos permite automatizar las operaciones en el navegador, así que para ejecutar las pruebas de integración agregamos las aserciones dentro de un Testcase. Para usar Selenium debemos descargar el driver para el lenguaje que utilicemos, en este caso. Nos aseguramos que los drivers estén cargados en el proyecto. Figura 25 Estructura de Proyecto de Selenium
  49. 49. 49 Una vez que nuestro proyecto tiene las librerías adecuadas para poder escribir las pruebas agregamos una clase a nuestro proyecto. Figura 26 Cuadro de Dialogo de Nueva Clase Luego en esta clase escribimos nuestra prueba usando las API’s de automatización de Selenium. import junit.framework.TestCase; import com.thoughtworks.selenium.DefaultSelenium; public class HomeUrlIT extends TestCase { protected DefaultSelenium createSeleniumClient(String url) throws Exception { return new DefaultSelenium("localhost", 4444, "*firefox", url); } public void testBaseForm() throws Exception { DefaultSelenium selenium = createSeleniumClient("http://localhost:8080/"); selenium.start();
  50. 50. 50 selenium.open("/"); assertTrue(selenium.isTextPresent("Hello")); assertTrue(selenium.isTextPresent("World")); selenium.stop(); } } Y ahora si podemos ejecutar nuestra prueba como parte de JUnit y ejecutar las operaciones sobre un navegador real y probar la aplicación como tal.
  51. 51. 51 6. Conclusiones y Recomendaciones En conclusión como hemos podido observar la automatización de pruebas representa una herramienta útil para aliviar la carga de trabajo de los testers. Hemos querido representar una visión general y global del proceso de prueba, tanto para las pruebas unitarias como para las de integración. Analizamos el proceso típico de depuración, al cual dividimos en las siguientes etapas:  Reproducir el error  Simplificar el escenario de prueba.  Depuración utilizando alguna de las técnicas descritas. Entre las técnicas que podemos emplear son la Depuración de impresión, Depuración Remota, Depuración Post-mortem, Depuración Delta, Depuración Squeeze saff, etc. En general el proceso de depuración nos permite encontrar y corregir errores que surgen en la ejecución de una aplicación, para evitar un número elevado de errores utilizamos métodos de pruebas que nos permitan asegurarnos de que los programas se ejecutan de la manera esperada. Hemos visto pruebas unitarias que ejecutan métodos en particular aisladas del resto de dependencias y se ejecutan en aislado y por otro lado las pruebas de integración ejecutan la aplicación en su conjunto tal cual será utilizado por el usuario final para asegurarnos de que la aplicación es funcional. Hemos revisado muchos Frameworks y combinación de lenguajes dependiendo el escenario y su espacio de trabajo, una u otra herramienta puede ser mucho más útil. Nuestra exploración ha sido ligera y ha tratado de explorar la mayor cantidad de Frameworks y opciones posibles pero recomendamos explore todas las opciones disponibles en su marco de trabajo, considere que cada día se hacen mejores esfuerzos para automatizar el proceso de pruebas y debemos de aceptar el reto de mantenernos en la constante actualización.
  52. 52. 52 Bibliografía  Testing unit: http://en.wikipedia.org/wiki/Unit_testing  (s.f.). Obtenido de White Box Testing: http://softwaretestingfundamentals.com/white- box-testing/  Academia mexico. (s.f.). Obtenido de Pruebas de integracion: http://www.academica.mx/blogs/las-pruebas-integraci%C3%B3n-software  Black box Testing. (s.f.). Obtenido de http://softwaretestingfundamentals.com/black- box-testing/  Centro de Artigos. (s.f.). Obtenido de Articulos eduactivos pruebas de integracion: http://centrodeartigos.com/articulos-educativos/article_11464.html  CentroArtigos. (s.f.). Obtenido de Gray Box Testing: http://centrodeartigos.com/articulos-educativos/article_11464.html  Depuración de programas. (2014). Obtenido de Wikipedia: http://es.wikipedia.org/wiki/Depuraci%C3%B3n_de_programas  Depuración de Programas. (2014). Obtenido de http://lsi.ugr.es/: http://lsi.ugr.es/~ig1/docis/depurac.htm  Depuración, Origen, Alcance, Instrumentos, Técnicas, Depuración para sistemas embebidos, Anti-debugging. (2014). Obtenido de centrodeartigos.com: http://centrodeartigos.com/articulos-noticias-consejos/article_128179.html  Depurador. (2014). Obtenido de Wikipedia: http://es.wikipedia.org/wiki/Depurador  Exception handling. (2014). Obtenido de Wikipedia: http://en.wikipedia.org/wiki/Exception_handling#Static_checking_of_exceptions  Integration Testing. (s.f.). Obtenido de Wikipedia: http://en.wikipedia.org/wiki/Integration_testing  Karma, official web site. (s.f.). Obtenido de http://karma- runner.github.io/0.12/index.html  Ozuna, M. d. (2014). ¿Es inevitable depurar? Obtenido de arqhys: http://www.arqhys.com/general/depuracion-de-programas.html
  53. 53. 53  PRUEBA Y DEPURACION DE UN PRODUCTO DE SOFTWARE. (2014). Obtenido de http://isc.itcj.s5.com/: http://isc.itcj.s5.com/ids1/unidad7.htm  Roldán, C. S. (2012). Codejobs. Obtenido de Excepciones en C# (CSharp): http://www.codejobs.biz/es/blog/2012/09/24/excepciones-en-c- csharp#sthash.4cnvUBu7.dpbs  SoftwareTesting. (s.f.). Obtenido de SoftwareTesting: http://www.softwaretestinginfo.com/integration-testing/  StackOverFlow. (s.f.). Obtenido de UnitTest: http://stackoverflow.com/questions/5357601/whats-the-difference-between-unit- tests-and-integration-tests  Técnicas de depuración de programas. (2014). Obtenido de /users.dcc.uchile.cl/: http://users.dcc.uchile.cl/~lmateu/CC10A/Apuntes/debug/

×