Etapas de las pruebas

Etapas
de las
pruebas
Etapas
de las
pruebas

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

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

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

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

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
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
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, 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
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
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
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
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
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
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
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
<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
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
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
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
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
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
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
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
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
 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/

Etapas de las pruebas

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to Etapas de las pruebas

Similar to Etapas de las pruebas (20)

Etapas de las pruebas