“ Año de la lucha contra la corrupción y la impunidad"

FACULTAD: INGENIERIA DE SISTEMAS

TEMA:

CURSO: PRUEBAS DE SOFTWARE

DOCENTE: DR. ALONSO MORALES

ALUMNOS:

De la Cruz Salcedo Diego

Díaz Sarria Ricardo
Landa Rojas Juan
Pachacute Bautista Joel

CICLO : IX “A”
ICA – PERU
2019
 ÍNDICE
INTRODUCCIÓN....................................................................................................
1.0 PRUEBAS UNITARIAS....................................................................................
1.1 Concepto ............................................................................................. 6
1.2 Beneficios. ........................................................................................... 6
1.3 Encuentra los problemas a tiempo....................................................... 7
1.4 Facilita el cambio ................................................................................. 8
1.5 Simplifica la integración ....................................................................... 8
1.6 Documentación .................................................................................... 8
1.7 Diseño.................................................................................................. 9
1.8 Limitaciones ......................................................................................... 9
1.9 Aplicaciones ....................................................................................... 10
1.9.1 Programación extrema ......................................................... 10
1.9.2 Técnicas ............................................................................... 11
1.9.3 Frameworks para pruebas de unidad ................................... 11
2.0 MANEJO DE EXCEPCIONES ...................................................................... 12
2.1 Concepto ........................................................................................... 12
2.2 Manejo de excepciones ..................................................................... 12
2.3 Intento (try) ........................................................................................ 13
2.4 Se lanza una excepción (throw) ......................................................... 14
2.5 La excepción es capturada en un punto específico del programa
(catch): ............................................................................................... 15
2.6 Ejemplos de código............................................................................ 17
2.6.1 Ejemplo de manejo de excepciones en Java ....................... 17
2.6.2 Ejemplo de manejo de excepciones en C# .......................... 17
3.0 TÉCNICAS DE DEPURACIÓN DE PROGRAMAS....................................... 19
3.1 Concepto ........................................................................................... 19
3.2 ¿Qué es un depurador? ..................................................................... 20
3.3 Tipos de Depuración .......................................................................... 21
3.4 Proceso de Depuración ..................................................................... 22
3.5 Técnicas ............................................................................................ 23
3.5.1 Depuración de impresión (o rastreo): ................................... 23
3.5.2 La Depuración remota .......................................................... 24
3.5.3 Depuración post-mortem ...................................................... 24
3.5.4 Depuración Delta.................................................................. 24
3.5.5 Squeeze saff ........................................................................ 24
3.5.6 Depuración para sistemas embebidos. ................................ 25
3.5.7 Anti depuración..................................................................... 25
4.0 PRUEBAS DE INTEGRACIÓN .................................................................... 27
4.1 Tipos de integración ........................................................................... 27
4.1.1 Integración descendente ...................................................... 27
4.1.2 Integración ascendente ........................................................ 28
El propósito de la integración ........................................................ 29
4.2 Métodos ............................................................................................. 29
4.2.1 Pruebas de Caja Negra ........................................................ 29
4.2.2 Pruebas de Caja Blanca ....................................................... 31
4.2.3 Prueba de Caja Gris ............................................................. 32
4.3 Enfoques............................................................................................ 32
4.3.1 Big Bang ............................................................................... 32
4.3.2 Top Down ............................................................................. 33
4.3.3 Stubs de prueba ................................................................... 33
4.4 Consejos ............................................................................................ 33
5.0 IMPLEMENTACIÓN DE PRUEBAS UNITARIAS Y DE INTEGRACIÓN ....... 35
6.0 CONCLUSIONES ......................................................................................... 35
7.0 BIBLIOGRAFÍA ............................................................................................ 36
 INTRODUCCIÓN

El Software testing o como se conoce en español las pruebas de software se

aplican como una etapa más del proceso de desarrollo de software, su objetivo
es asegurar que el software cumpla con las especificaciones requeridas y
eliminar los posibles defectos que este pudiera tener. En un principio la mayoría
de empresas de desarrollo contaban con una etapa de pruebas demasiado
informal, en la actualidad el software testing se ha convertido en una de las
etapas más críticas del ciclo de vida del desarrollo de software y esto ha
causado el origen de diversas metodologías.

En la actualidad el software testing se hace más complicado ya que debe hacer

frente a una gran cantidad de metodologías de desarrollo, lenguajes de
programación, sistemas operativos, hardware etc.

Es por esto que el testing debe apoyarse en metodologías generales que

revisan los aspectos más fundamentales que debe considerar todo proceso de
pruebas. Debido a esta complejidad actualmente se cuentan con una gran
cantidad de software diseñado exclusivamente para la etapa de pruebas,
incluyendo la gestión del proceso de software testing, la administración y
seguimiento de errores, la administración de los casos de prueba,
automatización de pruebas etc.
1.0 PRUEBAS UNITARIAS

1.1 Concepto

En programación, una prueba unitaria es una forma de comprobar el

correcto funcionamiento de un módulo de código. Esto sirve para
asegurar que cada uno de los módulos funcione correctamente por
separado. Luego, con las Pruebas de Integración, se podrá asegurar el
correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial

o métodoen el módulo, de forma que cada caso sea independiente del
resto.

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

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

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

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

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

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

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

Existen secciones de código que no pueden ser fácilmente probados

en absoluto, por ejemplo que son no deterministas o implican multiples
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.

1.9 Aplicaciones

1.9.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.
1.9.2 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.
 1.9.3 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.

2.0 MANEJO DE EXCEPCIONES

2.1 Concepto

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.

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

Para las tres etapas anteriores existen tres palabras

claves específicas: try, throw y catch. El detalle del
proceso es como sigue.

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

2.4 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.
2.5 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:

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

2.6 Ejemplos de código:

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

2.6.2 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);
}
}
}
3.0 TÉCNICAS DE DEPURACIÓN DE PROGRAMAS

3.1 Concepto:

Uno de los principales problemas al desarrollar aplicaciones son los

errores de ejecución. Compilar un programa no es garantía suficiente
de que funciona de la manera prevista. Es más, el ciclo de desarrollo
de un programa está ocupado, en su mayoría por las tareas de
diagnosticar y corregir los errores de ejecución. A los errores de
ejecución en programas se les suele denominar en
inglés bugs (bichos).

El origen de la utilización del término bug para describir los errores en

un programa es un poco confuso, pero hay dos referencias
documentadas a las cuales se les suele atribuir este mérito.

 La primera de ellas se puede encontrar en una carta que Edison

escribió en 1878 en la que se puede leer:

It has been just so in all of my inventions. The first step is an

intuition, and comes with a burst, then difficulties arise -- this thing
gives out and [it is] then that “Bugs” -- as such little faults and
difficulties are called -- show themselves and months of intense
watching, study and labor are requisite before commercial
success or failure is certainly reached.

Fuente: Edison to Puskas, 13 de noviembre de 1878, Edison papers, Edison

National Laboratory, U.S. National Park Service, West Orange, N.J., citado
en “Thomas P. Hughes, American Genesis: A History of the American Genius
for Invention”, Penguin Books, 1989, página 75.

 La invención del término se atribuye generalmente a la ingeniera

Grace Hopper que en 1946 estaba en el laboratorio de
computación de la universidad de Harvard trabajando en los
ordenadores con nombre Mark II y Mark III. Los operadores
descubrieron que la causa de un error detectado en el Mark II era
una polilla que se había quedado atrapada entre los contactos de
 un relé (por aquel entonces el elemento básico de un ordenador)
que a su vez era parte de la lógica interna del ordenador. Estos
operadores estaban familiarizados con el término bug e incluso
pegaron el insecto en su libro de notas con la anotación “First
actual case of bug being found” (primer caso en el que realmente
se encuentra un bug) tal y como ilustra la figura 1.

3.2 ¿Qué es un depurador?

Hoy en día, los métodos que se utilizan para “depurar” los errores de
un programa son múltiples y con diferentes niveles de eficacia. El
método consistente en insertar llamadas a printf que escriben en
pantalla mensajes es quizás el más ineficiente de todos ellos. En
realidad, lo que se precisa es una herramienta que permita ejecutar
de forma controlada un programa, que permita suspender la
ejecución en cualquier punto para poder realizar comprobaciones, ver
el contenido de las variables, etc.

Esta herramienta se conoce con el nombre de depurador o, su

término inglés, debugger. El depurador es un ejecutable cuya misión
 es permitir la ejecución controlada de un segundo ejecutable. Se
comporta como un envoltorio dentro del cual se desarrolla una
ejecución normal de un programa, pero a la vez permite realizar una
serie de operaciones específicas para visualizar el entorno de
ejecución en cualquier instante.

Más concretamente, el depurador permite:

 Ejecutar un programa línea a línea.

 Detener la ejecución temporalmente en una línea de código concreta.

 Detener temporalmente la ejecución bajo determinadas condiciones.

 Visualizar el contenido de las variables en un determinado momento

de la ejecución.

 Cambiar el valor del entorno de ejecución para poder ver el efecto de

una corrección en el programa.

3.3 Tipos de Depuración:

Hay dos tipos de depuración: difícil y profunda.

Una depuración difícil significa que hay problemas con la lógica del
programa, mientras que una depuración profunda sólo mejora el
programa, lo libera de errores sencillos o busca código optimizable.

Además de buscar errores, la depuración permite detectar algunos

detalles importantes para el mejoramiento del programa; por ejemplo:

1. Expresiones booleanas que requieren simplificación.

2. Segmentos de código que nunca se ejecutan

3. Instrucciones en las que se ocupa el 90% del tiempo, que pueden

ser optimizables.

4. Necesidad de volver a empezar desde el principio.

 Desafortunadamente, no existe ningún método que permita probar
por completo, en un tiempo razonable, un programa de gran
complejidad. Esto se debe a que mientras mayor cantidad de errores
se detectan (y corrigen), más difícil resulta detectar los siguientes.
Ante la imposibilidad de hacer pruebas exhaustivas se recurre a una
selección cuidadosa de datos de prueba. Si el programa funciona
correctamente con esos datos, se puede tener mucha confianza
sobre su futuro comportamiento. El momento de dejar de buscar
errores es cuando el esfuerzo de hacerlo es mayor que el costo de
los fallos aún no detectados. Para reducir las posibilidades de error
se debe tener en cuenta que la mayoría de los errores ocurre en las
etapas de especificación y diseño (por prestar poca atención a la
naturaleza del problema), y se reducen siguiendo algún método
estructurado. También se generan errores en la traducción del diseño
al código; y finalmente suele haber errores en la comprobación y
depuración, la misma corrección de errores puede dar pauta a otros.

3.4 Proceso de Depuración:

En general la depuración de un programa se completa en tres fases;

es un proceso en el que el producto se va acercando a la perfección
(estar libre de errores e inconvenientes graves) mediante una serie
de transformaciones sucesivas que responden al esquema de la
figura.

En una primera fase, cuando ya el programa está prácticamente

terminado, se somete a pruebas que podríamos llamar "de
laboratorio" para comprobar que todo marcha según lo esperado y
sin errores. Son pruebas que realiza el propio programador antes de
dar a conocer el producto. Estas versiones se suelen denominar alfa
y corresponden a un punto en que el programa todavía está en fase
de gestación. En una versión alfa son de esperar todo tipo de errores
y "cuelgues".

En una segunda fase, cuando el programador cree que su producto

ya está suficientemente presentable y él no consigue encontrar más
 errores aparentes (o los ya conocidos están en proceso de
depuración), se procede a la distribución del producto a una serie de
probadores seleccionados ("beta testers"). Son las denominadas
versiones beta, que, aunque con errores esporádicos, pueden tener
un comportamiento más o menos aceptable.

Finalmente, en una tercera fase, con la información, opiniones y

sugerencias de los "beta testers", se procede a lanzar la primera
versión pública v 1.0 del producto ("Release"), también denominadas
versiones gamma. A partir de aquí, lo normal es que se vayan
recogiendo las sugerencias, cuestiones y posibles errores que hayan
pasado inadvertidos en las pruebas beta y sean reportados por los
usuarios. Las soluciones a estos problemas, junto con las mejoras
que se vayan incorporando, son implementados en versiones
sucesivas. Generalmente a partir de la versión 2.0 el producto se
considera estable.

Fases de las Pruebas

3.5 Técnicas
 3.5.1 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.

3.5.2 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

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

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

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

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

3.5.7 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 basado en: Comprueba la existencia de un depurador

utilizando la información del sistema.
 Excepción basada en: compruebe si las excepciones son
interferidas.
 Bloques de proceso e hilo: compruebe si los bloques de proceso
e hilo han sido manipulados.
 Código modificación: comprobar modificaciones de código
hechas por un depurador manipular los puntos de interrupción
de software.
4.0 PRUEBAS DE INTEGRACIÓN

La necesidad de realizar las pruebas de integración viene dada por el hecho

de que los módulos que forman un programa suelen fallar cuando trabajan
de forma conjunta, aunque previamente se haya demostrado que funcionan
correctamente de manera individual.

La prueba de integración es una prueba sistemática para construir la

arquitectura del software, mientras al mismo tiempo, se aplican las pruebas
para descubrir errores asociados a la interfaz, asegurándonos que los
módulos que están relacionados ejecuten correctamente.

A menudo se tiende a intentar una integración, se combinan todos los

componentes por anticipado, se prueba todo el programa como un todo. El
objetivo es tomar los módulos probados en unidad y estructurar un
programa que esté de acuerdo con el que dicta el diseño.

Con el uso de estas pruebas conseguimos ir formando el programa global a

medida que se comprueba como los distintos componentes interaccionan y
se comunican libres de errores.

Frases para entenderlo:

"Si todo funciona bien individualmente, ¿por qué va a fallar cuando se

une?"

4.1 Tipos de integración:

4.1.1 Integración descendente:

Es una estrategia de integración incremental a la construcción de la

estructura de programas, en el cual se integran los módulos
moviéndose en dirección hacia abajo por la jerarquía comenzando por
el control principal (Programa principal). Los módulos subordinados de
control principal se incorporan en la estructura en la estructura, bien,
de forma primero-en-profundidad, bien primero-en-anchura.
4.1.2 Integración ascendente:

Es donde la construcción del diseño empieza desde los módulos

más bajos hacia arriba (módulo principal), el procesamiento
requerido de los módulos subordinados siempre está disponible y
elimina la necesidad de resguardo.

La sección de una estrategia de integración depende de las

características depende de las características del software y, a
veces, del plan del proyecto, en algunos de los casos se puede
combinar ambas estrategias.

Jerarquía de Pruebas

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.
 El propósito de la integración

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.

4.2 Métodos

Se puede usar cualquiera de los métodos.

1. Pruebas de Caja Negra

2. Pruebas de Caja Blanca
3. Pruebas de Caja Gris

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

4.2.1 Pruebas de Caja Negra

Las pruebas de caja negra se centran principalmente en lo que

“se quiere” de un módulo, charter o sección específica de un
software, es decir, es una manera de encontrar casos específicos
en ese módulo que atiendan a su especificación.

Las pruebas de caja negra se limitan a que el tester pruebe con

“datos” de entrada y estudie como salen, sin preocuparse de lo
que ocurre en el interior.

Éstas, principalmente, se centran en módulos o charters de

interfaz de usuario (pantalla, ficheros, canales de
comunicación…) pero suelen ser útiles en cualquier módulo ya
que todos o la mayoría tienen datos de entrada y salida que se
pueden comprobar y verificar. Como cualquier otra prueba, las de
caja negra se apoyan y basan en la especificación de requisitos y
documentación funcional, estos requisitos suelen ser más
complejos que los internos, para ello se realiza una “cobertura de
especificación” que será muy recomendable para conseguir
probar el mayor campo posible.

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.

Limitaciones de las pruebas de caja negra

Lo más deseable a la hora de realizar pruebas de caja negra es

realizar una cobertura completa, pero, en la mayoría de los casos
no es suficiente, siempre hay que combinarlas con pruebas de
integración, ya que por mucho que funcionen los datos de
entrada/salida, por dentro o en terceros sistemas, pueden existir
defectos que no se están teniendo en cuenta. Estos defectos
pueden no acarrear problemas a corto plazo, pero a lo largo del
tiempo aparecerán y como dicen…”es mejor el remedio que la
enfermedad”.

Prueba de Caja Negra

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.

4.2.2 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 son probadas 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.

Prueba 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.
 4.2.3 Prueba 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 beneficiosas, 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).

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

4.3 Enfoques

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

4.3.2 Top Down

Es un enfoque para pruebas de integración, donde las unidades

de primer nivel son probadas 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.

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

4.4 Consejos

Asegúrese de que tiene un documento de diseño de detalle

adecuado donde las interacciones entre cada unidad están claramente
definidas. 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 son importantes cada vez que
integra una unidad, y las pruebas de regresión manual puede ser
ineficiente.
5.0 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.

Link del Video:

https://www.youtube.com/watch?v=szHnZVtUYvI

6.0 CONCLUSIONES

Las pruebas de software permiten la ejecución de un programa cuya

intención u objetivo principal es el de detectar errores presentes en el
software con el fin de disminuirlos y corregirlos para que a su vez se
mejore la calidad con la que se producen los diferentes aplicativos.

Las pruebas de caja blanca poseen criterios basados en el contenido y la

estructura del código fuente de los módulos, mientras que las pruebas de
caja negra poseen criterios basados en las interfaces y las
especificaciones de los módulos.
7.0 BIBLIOGRAFÍA:
Pruebas Unitarias:
https://es.wikipedia.org/wiki/Prueba_unitaria
https://www.google.com.pe/search?
q=pruebas+unitarias+de+software&safe=active&espv=2&biw=679&bih=617&sourc
e=lnms&tbm=isch&sa=X&ved=0ahUKEwjToYa4wanPAhWBHB4KHVDPC00Q_AUI
BigB&dpr=1#safe=active&tbm=isch&q=pruebas+de+software&imgrc=hVBM_IPpqX
XiMM%3A
https://www.google.com.pe/search?
q=pruebas+unitarias+de+software&safe=active&espv=2&biw=679&bih=617&sourc
e=lnms&tbm=isch&sa=X&ved=0ahUKEwjToYa4wanPAhWBHB4KHVDPC00Q_AUI
BigB&dpr=1#safe=active&tbm=isch&q=documentacion+de+software

El programa depurador o debugger:

http://www.it.uc3m.es/abel/as/MMC/L3/Debugger_es.html

Depuración de Programas:

http://www.arqhys.com/general/depuracion-de-programas.html

Proceso de Depuración:

http://www.zator.com/Cpp/E1_4_5.htm