Etapas de las

Pruebas
 ” Año del Dialogo y la Reconciliación Nacional”

UNIVERSIDAD NACIONAL
“SAN LUIS GONZAGA” DE
ICA
FACULTAD DE INGENIERÍA DE SISTEMAS

ETAPASTRABAJO:
DE LAS PRUEBAS
ETAPAS DE LAS PRUEBAS

Apolaya Sanchez, Carlos

Figueroa Funes, Gabriel
García Ibarra, Albert
Narro Andrade, Marco
Quispe Ccoyllo, Edgar

Ing. Antonio Alonso Morales Loaiza

Ica – 2018
2
 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.

3
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.
Índice
Tabla de Figuras............................................................................................................................. ...... 7

I. Pruebas unitarias ............................................................................................................................. 8

1. Conceptos básicos. ................................................................................................................ . 8

2. Beneficios................................................................................................................................... 8

2.1 Encuentra los problemas a tiempo .............................................................................. 8

2.2 Facilita el cambio ................................................................................................................ 9

2.3 Simplifica la integración .................................................................................................. 9

2.4 Documentación..................................................................................................................…9

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

II. Manejo de excepciones................................................................................................................ 13

1. Manejo de excepciones:..................................................................................................... . 13

1.1. Intento (try): .............................................................................................................. 14

1.2. Se lanza una excepción (throw): ........................................................................ 14

1.3. La excepción es capturada (catch): ................................................................... 15

1.4. Ejemplos de código: ................................................................................................ 17

III. Técnicas de depuración de programas ............................................................................... 19

1. ¿Qué es el depurador?......................................................................................................... 19

2. Tipos de depuración ............................................................................................................ 20

3. Proceso de depuración ....................................................................................................... 20

4. Proceso de depuración típico........................................................................................... 21

5
 4.1 Técnicas ................................................................................................................................ 22

4.2 Anti depuración ................................................................................................................. 24

IV. Pruebas de integración ............................................................................................................. 25

1. El propósito ............................................................................................................................ 26

2. Método........................................................................................................ .............................. 26

3. Enfoques .................................................................................................................... .............. 30

4. Limitaciones ................................................................................................................ ........... 31

5. Consejos .................................................................................................................... ............... 32

V. Implementación de pruebas .............................................................................................. ...... 33

1. Frameworks y Herramientas para Unit Testing e Integration Testing ........... 33

1.1. Frameworks y Herramientas en .Net ................................................................... 33

1.2. Frameworks y Herramientas en Java .................................................................. 35

1.3. Frameworks y Herramientas en JavaScript ...................................................... 36

1.4. Frameworks y Herramientas en Python ............................................................ 37

2. Implementación de Pruebas Unitarias ........................................................................ 38

3. Implementación de Pruebas de Integración .............................................................. 48

VI. Conclusiones y Recomendaciones ........................................................................................ 53

Bibliografía ................................................................................................................................... ......... 55

6
Tabla de Figuras
Figura 1 El simbolo de Depuracion ............................................................................................ 19
Figura 2Proceso de Depuracion .................................................................................................. 21
Figura 3 Jerarquia de Pruebas...................................................................................................... 25
Figura 4 Pruebas de Caja Negra ................................................................................................... 27
Figura 5 Pruebas de Caja Blanca ................................................................................................. 28
Figura 6 Pruebas de Caja Gris ....................................................................................................... 30
Figura 7 Dialogo de Nuevo Proyecto ......................................................................................... 38
Figura 8 Código a Probar ................................................................................................................ 39
Figura 9 Resultado de Pruebas .................................................................................................... 40
Figura 10 Estructura del Proyecto de Java .............................................................................. 40
Figura 11 Menu para Agregar un Test ...................................................................................... 41
Figura 12 Cuadro de Dialogo de Nueva Clase......................................................................... 41
Figura 13 Resultados de las Pruebas en Eclipse ................................................................... 42
Figura 14 Código Js a probar......................................................................................................... 43
Figura 15 Estructura del Proyecto en js ................................................................................... 43
Figura 16 Resultado de las Pruebas en Buster.js .................................................................. 46
Figura 17 Estructura del Proyecto en Python ........................................................................ 46
Figura 18 Nuevo Test en Python ................................................................................................. 47
Figura 19 Resultados de Pruebas en Visual Studio .............................................................. 48
Figura 20 Nueva Prueba de UI...................................................................................................... 48
Figura 21 Cuadro de Generación de UI Test ........................................................................... 49
Figura 22 Grabación de pasos en el Navegador .................................................................... 49
Figura 23 Menú de Grabación de UI Test ................................................................................. 50
Figura 24 Prueba de UI con Assert ............................................................................................. 50
Figura 25 Estructura de Proyecto de Selenium ..................................................................... 50
Figura 26 Cuadro de Dialogo de Nueva Clase......................................................................... 51

7
 I. Pruebas Unitarias
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.

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.
8
 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

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).
9
 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.

- 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
10
 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
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.

11
 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.

12
II. Manejo de excepciones
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

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.

13
Para las tres etapas anteriores existen tres palabras claves específicas: try, throw y

catch. El detalle del proceso es como sigue.

1.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 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.

1.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:

14
 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.

1.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
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:

15
 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”.

16
1.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;

17
 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);
}
}
}

18
 III.Técnicas de depuración de
programas
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.

Figura 1 El símbolo d e Depuración

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:

19
 o Ejecutar pasó a paso un programa
(stepping).
o Establecer puntos de detención
(breakpoints).
o Examinar el contenido de las variables y
objetos.
o Conocer el encadenamiento de llamadas de
procedimientos.
o 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.

o Una depuración difícil significa que hay problemas con la lógica del programa.
o 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.

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.

20
 Figura 2 Proceso de Depuración

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 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

21
 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 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.

22
 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 su rendimiento
o para optimizar otras características importantes (por ejemplo, consumo de energía,
fiabilidad, respuesta en tiempo real, etc.)

23
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.

24
 IV. Pruebas de integración
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.

Figura 3 Jerarquía de Pruebas

Las pruebas de integración se llevan a cabo después de pruebas unitarias y antes

System Testing.

25
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.

2. Método
Se puede usar cualquiera de los métodos.

a. Pruebas de Caja Negra

b. Pruebas de Caja Blanca
c. Pruebas de Caja Gris

Normalmente, el método depende de tu definición en "Unit testing".

a. 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.

26
 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

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.

b. 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

27
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

28
 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.

c. 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.

29
 Figura 6 Pruebas de Caja Gris

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

30
 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 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.

31
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 d i f í c i l
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
 V. Implementación de
Pruebas 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 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.
33
 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
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
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
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, 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, e s 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.

37
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.
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.

38
 Figura 8 Código a Probar

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);
}

39
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.

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

40
Ahora agregamos un caso de pruebas utilizando el menú contextual
en el proyecto: New > JUnit Test Case

Figura 11 Menú para Agregar un Test

Agregamos el nombre y configuramos el framework que usaremos

(Junit3 en este cas).

41
 Figura 12 Cuadro de Dialogo de Nueva Clase

Luego escribimos el test unitario utilizando las mismas convenciones

que empleamos anteriormente.

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.

Figura 13 Resultados de las Pruebas en Eclipse

42
2.3. Frameworks y Herramientas en JavaScript usando
Buster.js

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).

Figura 14 Código Js a probar

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

43
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", {

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.

44
 <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>

<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.

45
 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.

Figura 17 Estructura del Proyecto en Python

46
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

i == ' main ':

f name
unittest.main()

47
 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.

Figura 19 Resultados de Pruebas en Visual Studio

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 20 Nueva Prueba de UI

48
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

49
 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

50
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();

51
 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.

52
 VI. 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

53
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.

54
 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



 55
  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 Software Testing;

http://www.softwaretestinginfo.com/integration-testing/
 Técnicas de depuración de programas. (2014). Obtenido de /users.dcc.uchile.cl/:
http://users.dcc.uchile.cl/~lmateu/CC10A/Apuntes/debug/

56
57