Está en la página 1de 38

Etapas de las pruebas de

software
FIS - 2016

Autor: Oyolo Isasi, Cristian Alexis

Pachas Benavides, Leiner

Ing. Alonso Morales Loayza.

DEDICATORIA:
Dedicamos el presente trabajo a
nuestro docente que, a pesar de todas las
adversidades, y dems incovenientes, nos
demuestra su apoyo y comprensin con la
finalidad de lograr profesionales de calidad y
de aporte a la sociedad.
1

NDICE
INTRODUCCIN....................................................................................................
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 integracin.........................................................................8
1.6 Documentacin......................................................................................8
1.7 Diseo....................................................................................................9
1.8 Limitaciones...........................................................................................9
1.9 Aplicaciones.........................................................................................10
1.9.1 Programacin extrema...........................................................10
1.9.2 Tcnicas.................................................................................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 excepcin (throw):.........................................................14
2.5 La excepcin es capturada en un punto especfico del programa
(catch):.................................................................................................15
2.6 Ejemplos de cdigo:............................................................................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 TCNICAS DE DEPURACIN DE PROGRAMAS........................................19
3.1 Concepto:.............................................................................................19
3.2 Qu es un depurador?.......................................................................20
3.3 Tipos de Depuracin:...........................................................................21
3.4 Proceso de Depuracin:......................................................................22
3.5 Tcnicas...............................................................................................23
3.5.1 Depuracin de impresin (o rastreo):....................................23
3.5.2 La Depuracin remota...........................................................24
3.5.3 Depuracin post-mortem.......................................................24
3.5.4 Depuracin Delta...................................................................24
3.5.5 Squeeze saff..........................................................................24
3.5.6 Depuracin para sistemas embebidos..................................25
3.5.7 Anti depuracin......................................................................25

4.0 PRUEBAS DE INTEGRACIN......................................................................27


4.1 Tipos de integracin:............................................................................27
4.1.1 Integracin descendente:.......................................................27
4.1.2 Integracin ascendente:.........................................................28
El propsito de la integracin..........................................................29
4.2 Mtodos...............................................................................................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 IMPLEMENTACIN DE PRUEBAS UNITARIAS Y DE INTEGRACIN.......35
6.0 CONCLUSIONES...........................................................................................35
7.0 BIBLIOGRAFA:..............................................................................................36

INTRODUCCIN

El Software testing o como se conoce en espaol las pruebas de software se


aplican como una etapa ms 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 mayora
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 ms crticas del ciclo de vida del desarrollo de software y esto ha
causado el origen de diversas metodologas.

En la actualidad el software testing se hace ms complicado ya que debe hacer


frente a una gran cantidad de metodologas de desarrollo, lenguajes de
programacin, sistemas operativos, hardware etc.

Es por esto que el testing debe apoyarse en metodologas generales que


revisan los aspectos ms fundamentales que debe considerar todo proceso de
pruebas. Debido a esta complejidad actualmente se cuentan con una gran
cantidad de software diseado exclusivamente para la etapa de pruebas,
incluyendo la gestin del proceso de software testing, la administracin y
seguimiento de errores, la administracin de los casos de prueba,
automatizacin de pruebas etc.

1.0 PRUEBAS UNITARIAS


1.1 Concepto

En programacin, una prueba unitaria es una forma de comprobar el


correcto funcionamiento de un mdulo de cdigo. Esto sirve para
asegurar que cada uno de los mdulos funcione correctamente por
separado. Luego, con las Pruebas de Integracin, se podr asegurar el
correcto funcionamiento del sistema o subsistema en cuestin.
La idea es escribir casos de prueba para cada funcin no trivial
o mtodoen el mdulo, 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 cdigo 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 Programacin
extrema y Scrum, se crean las pruebas de unidad antes de
escribir el cdigo en s. Cuando las pruebas pasan, el cdigo se
considera completa.
Si las pruebas fallan, se consideran que es un error, ya sea por
el cdigo modificado o por la propia prueba.
Las pruebas de unidad permiten localizar defectos o errores
fcilmente localizables, ya que estas alertan al equipo de desarrollo

del problema antes de entregar cdigo 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 cdigo despus 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 mtodos para que cada vez que
un cambio causa un fallo, se puede identificar rpidamente.
A travs de la prctica de mantenimiento, las pruebas seguirn
reflejando precisin en el uso del ejecutable y del cdigo de cara
a cualquier cambio.
1.5 Simplifica la integracin

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 ms fciles las pruebas de integracin.
1.6 Documentacin

Proporcionan una especie de documentacin viva del sistema. Los


desarrolladores aprenden que funcionalidad es proporcionada por una
unidad y pueden ver cmo usarlo en las pruebas unitarias para tener
comprensin bsica de la interfaz de unidad (API).
Las pruebas de unidad muestran caractersticas que indican el uso
adecuado o inadecuado de la unidad.

Por otro lado, la documentacin narrativa ordinaria es ms sensible a


irse a la deriva de la implementacin del programa, por lo tanto se
convertir en obsoleta.

1.7 Diseo
Cuando se desarrolla con un enfoque basado en pruebas, la
combinacin de escribir la prueba unitaria para especificar la interfaz,
ms la actividad de refactorizar despus de pasar la prueba, puede
tomar lugar un diseo formal de este. Cada prueba de unidad puede
ser vista como un elemento de diseo que especifica clases y
mtodos.
1.8 Limitaciones

Las pruebas no pueden mostrar todos los errores en el programa, ya


que no se pueden evaluar todas las rutas de ejecucin. Lo mismo la
pasa con las pruebas unitarias ya que solo prueban funcionalidad de
las unidades ellos mismos.

No se detectan errores de integracin o errores a nivel de sistema


ms amplio tales como rendimiento.
No demuestran una ausencia total de errores.

Es necesario el uso de otras tcnicas como la aplicacin de mtodos


formales para probar que un componente de software no tenga
comportamientos inesperados.
Demanda de esfuerzo, se estima que por cada lnea de cdigo
escrita, se escriben de 3 a 5 lneas de cdigo para probar.
Existen secciones de cdigo que no pueden ser fcilmente probados
en absoluto, por ejemplo que son no deterministas o implican multiples
hilos. Adems es probable que el cdigo de prueba tenga errores al igual que
el cdigo 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
cdigo 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 podra regresar el cdigo
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 Programacin extrema.


Las pruebas unitarias son la piedra angular de la programacin
extrema, que esta automatizado en base a un framework de
pruebas unitarias.
Esta utiliza la creacin 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 todava
o porque se expone intencionalmente a un defecto.

La programacin extrema obliga a una prueba de todo lo que se


puede romper estratgicamente por sobre la prueba en cada ruta de
ejecucin del mtodo tradicional, todo esto lleva a crear menos
pruebas que el mtodo tradicional. La programacin extrema se
limita a reconocer las pruebas raramente exhaustivas y proporciona
orientacin para identificar en forma eficaz con recursos limitados
(tiempo).
Las pruebas de unidad son fundamentales para el
concepto de diseo emergente. Como el diseo emergente
es muy dependiente de la refactorizacin, estas pruebas
son un componente integral.
1.9.2 Tcnicas
Las pruebas unitarias estn comnmente 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
instruccin paso a paso. Sin embargo, la automatizacin es eficaz
para lograr muchos beneficios.
Para realizar plenamente el efecto de aislamiento durante el uso de
un enfoque automtico, la unidad o cdigo 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 cdigo probado.
Durante la ejecucin de pruebas se registran las pruebas que no
cumplan algn 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 diseo, pruebas unitarias y refactorizacin a


menudo trabajan juntos para que surja mejor solucin.

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

programacin. Es posible probar sin el uso de Frameworks al escribir


cdigo que se ejecutan las unidades bajo pruebas de afirmacin,
manejo de excepciones y mecanismos para sealar 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 situacin, se hara
relativamente fcil.

2.0 MANEJO DE EXCEPCIONES

2.1 Concepto
Antes de entrar en el tema de las excepciones en programacin,
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
programacin.
En el lenguaje humano, una excepcin es un elemento
excluyente de una regla, y de forma convencional se ha
extendido esta definicin. En el lenguaje mquina, una
excepcin 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 ejecucin.
A veces estas excepciones, para una mquina, no son casos que
no deberan 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 excepcin es un error que puede ocurrir debido a una mala


entrada por parte del usuario, un mal funcionamiento en el
hardware, un argumento invlido para un clculo matemtico,
etc. Para remediar esto, el programador debe estar atento y
escribir los algoritmos necesarios para evitar a toda costa que un
error de excepcin pueda hacer que el programa se interrumpa
de manera inesperada.
El manejo de excepciones se basa en un mecanismo cuyo
funcionamiento tiene tres etapas bsicas:
1. Se intenta ejecutar un bloque de cdigo y se decide
qu hacer si se produce una circunstancia excepcional
durante su ejecucin.
2. Se produce la circunstancia: se lanza una excepcin
(en caso contrario el programa sigue su curso
normal).
3. La ejecucin del programa es desviada a un
sitio

especfico

donde

la

excepcin

es

capturada y se decide que hacer al respecto.


Para las tres etapas anteriores existen tres palabras
claves especficas: try, throw y catch. El detalle del
proceso es como sigue.
2.3 Intento (try):
En sntesis podemos decir que el programa se prepara
para cierta accin, decimos que "lo intenta". Para ello se
especifica un bloque de cdigo cuya ejecucin se va a
intentar ("try-block") utilizando la palabra clave try.
try { // Bloque de cdigo-intento
...
}

El juego consiste en indicar al programa que si existe un error


durante el "intento", entonces debe lanzar una excepcin y
transferir el control de ejecucin al punto donde exista un
manejador de excepciones ("handler") que coincida con el tipo
lanzado. Si no se produce ninguna excepcin, el programa
sigue su curso normal.
De lo dicho se deduce inmediatamente que se pueden lanzar
excepciones de varios tipos y que pueden existir tambin
receptores

(manejadores)

de

varios

tipos;

incluso

manejadores "universales", capaces de hacerse cargo de


cualquier tipo de excepcin. A la inversa, puede ocurrir que se
lance una excepcin para la que no existe manejador
adecuado, en cuyo caso... (La solucin ms adelante).
As pues, try es una sentencia que en cierta forma es capaz
de especificar el flujo de ejecucin del programa. Un bloqueintento debe ser seguido inmediatamente por el bloque
manejador de la excepcin.

2.4 Se lanza una excepcin (throw):


Si se detecta una circunstancia excepcional dentro del
bloque-intento, se lanza una excepcin mediante la ejecucin
de una sentencia throw. Por ejemplo:
if (condicin) throw "overflow";

Es importante advertir que, salvo los casos en que la


excepcin es lanzada por las propias libreras, estas no se
lanzan espontneamente. Es el programador el que debe
utilizar una sentencia (generalmente condicional) para, en su
caso, lanzar la excepcin.
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 informacin. Este objeto
es creado y lanzado en el punto de la sentencia throw y
capturado donde est la sentencia catch. El tipo de
informacin contenido en el objeto es justamente el que nos
gustara 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 informacin desde el
punto del error hasta el sitio donde esta informacin puede ser
analizada.

2.5 La excepcin es capturada en un punto especfico del programa


(catch):
Esta parte del programa se denomina manejador ("handler");
se dice que el "handler" captura la excepcin. El handler es
un bloque de cdigo diseado para manejar la excepcin
precedida por la palabra catch. Se requiere que exista al
menos un manejador inmediatamente despus de un bloque
try. Es decir, se requiere el siguiente esquema:
try { //bloque de cdigo que se intenta
...
}
catch (...) { //bloque de manejador de posibles
excepciones
...
}
... //continua la ejecucin 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 opcin 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
informacin pertinente, que se guarda en disco con objeto de
que pueda ser

posteriormente analizado y corregido en sucesivas versiones


de la aplicacin.
En resumen se ha dicho que try es una sentencia que en
cierta forma es capaz de especificar el flujo de ejecucin del
programa; en el fondo el mecanismo de excepciones funciona
como una especie de sentencia if then
else.

2.6 Ejemplos de cdigo:


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 excepcin
} catch (IOException e) {
// manejo de una excepcin de entrada/salida
} catch (Exception e) {
// manejo de una excepcin cualquiera
} finally {
// cdigo a ejecutar haya o no excepcin
}
}

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 TCNICAS DE DEPURACIN DE PROGRAMAS


3.1 Concepto:
Uno de los principales problemas al desarrollar aplicaciones son los
errores de ejecucin. Compilar un programa no es garanta suficiente
de que funciona de la manera prevista. Es ms, el ciclo de desarrollo
de un programa est ocupado, en su mayora por las tareas de
diagnosticar y corregir los errores de ejecucin. A los errores de
ejecucin

en

programas

se

les

suele

denominar

en

ingls bugs (bichos).


El origen de la utilizacin del trmino 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 mrito.

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, pgina 75.

La invencin del trmino se atribuye generalmente a la ingeniera


Grace Hopper que en 1946 estaba en el laboratorio de
computacin 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 haba quedado atrapada entre los contactos de

un rel (por aquel entonces el elemento bsico de un ordenador)


que a su vez era parte de la lgica interna del ordenador. Estos
operadores estaban familiarizados con el trmino bug e incluso
pegaron el insecto en su libro de notas con la anotacin 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 da, los mtodos que se utilizan para depurar los errores de
un programa son mltiples y con diferentes niveles de eficacia. El
mtodo consistente en insertar llamadas a

printf que escriben en

pantalla mensajes es quizs el ms 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
ejecucin 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
trmino ingls, debugger. El depurador es un ejecutable cuya misin

es permitir la ejecucin controlada de un segundo ejecutable. Se


comporta como un envoltorio dentro del cual se desarrolla una
ejecucin normal de un programa, pero a la vez permite realizar una
serie de operaciones especficas para visualizar el entorno de
ejecucin en cualquier instante.
Ms concretamente, el depurador permite:

Ejecutar un programa lnea a lnea.

Detener la ejecucin temporalmente en una lnea de cdigo concreta.

Detener temporalmente la ejecucin bajo determinadas condiciones.

Visualizar el contenido de las variables en un determinado momento


de la ejecucin.

Cambiar el valor del entorno de ejecucin para poder ver el efecto de


una correccin en el programa.

3.3 Tipos de Depuracin:


Hay dos tipos de depuracin: difcil y profunda.
Una depuracin difcil significa que hay problemas con la lgica del
programa, mientras que una depuracin profunda slo mejora el
programa, lo libera de errores sencillos o busca cdigo optimizable.
Adems de buscar errores, la depuracin permite detectar algunos
detalles importantes para el mejoramiento del programa; por ejemplo:
1. Expresiones booleanas que requieren simplificacin.
2. Segmentos de cdigo 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 ningn mtodo 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), ms difcil resulta detectar los siguientes.
Ante la imposibilidad de hacer pruebas exhaustivas se recurre a una
seleccin 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 an no detectados. Para reducir las posibilidades de error
se debe tener en cuenta que la mayora de los errores ocurre en las
etapas de especificacin y diseo (por prestar poca atencin a la
naturaleza del problema), y se reducen siguiendo algn mtodo
estructurado. Tambin se generan errores en la traduccin del diseo
al cdigo; y finalmente suele haber errores en la comprobacin y
depuracin, la misma correccin de errores puede dar pauta a otros.
3.4 Proceso de Depuracin:
En general la depuracin de un programa se completa en tres fases;
es un proceso en el que el producto se va acercando a la perfeccin
(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 prcticamente
terminado, se somete a pruebas que podramos llamar "de
laboratorio" para comprobar que todo marcha segn 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 todava est en fase
de gestacin. En una versin 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 ms

errores aparentes (o los ya conocidos estn en proceso de


depuracin), se procede a la distribucin del producto a una serie de
probadores seleccionados ("beta testers"). Son las denominadas
versiones beta, que, aunque con errores espordicos, pueden tener
un comportamiento ms o menos aceptable.
Finalmente, en una tercera fase, con la informacin, opiniones y
sugerencias de los "beta testers", se procede a lanzar la primera
versin pblica v 1.0 del producto ("Release"), tambin 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 versin 2.0 el producto se
considera estable.

Fases de las Pruebas


3.5 Tcnicas

3.5.1 Depuracin de impresin (o rastreo):


El tipo ms comn es la depuracin de impresin. Imprimir la
depuracin 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 ejecucin del programa.
Esto puede ayudar a los desarrolladores a identificar problemas
con la forma en que el programa se ejecuta.
3.5.2 La Depuracin remota
Depuracin remota es similar a la impresin de depuracin, 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. Despus de
esto, el programa se ejecuta y el depurador contiene informacin
acerca de lo que los errores que pueda contener. Esto es til para
identificar cmo una aplicacin puede ejecutarse en diferentes
plataformas o equipos
3.5.3 Depuracin post-mortem
Errores de depuracin post- mortem identificados despus de un
programa que ya se ha estrellado. Esto se realiza mediante la
instalacin de un archivo que registra el estado de la aplicacin, ya
que se ha estrellado. Esta informacin se puede utilizar para
identificar por qu la ejecucin puede haber fallado.
3.5.4 Depuracin Delta
Delta depuracin automatiza el proceso de depuracin, y analiza
sistemticamente a travs de una aplicacin para los errores.
Estos errores estn aislados del resto del programa. Esto permite
a los desarrolladores ver cmo su programa cuando estos eliminan
los bugs molestos del contexto de su aplicacin.
3.5.5 Squeeze saff
La solucin en este problema se asla mediante la ejecucin de
dos procesos. El primero es un proceso de alto nivel que se utiliza

para identificar los principales problemas en la aplicacin. A


continuacin, la unidad de pruebas especficas se ejecuta para
aislar el problema exacto o error. Esto acelera el proceso de
depuracin al mismo tiempo, identificar los problemas exactos.
3.5.6 Depuracin para sistemas embebidos.
En contraste con el software de ordenador entorno de diseo de
uso

general,

integrados

una

es

el

caracterstica
gran

nmero

fundamental
de

diferentes

de

entornos

plataformas

disponibles para los desarrolladores (arquitecturas de CPU,


proveedores, sistemas operativos y sus variantes). Los sistemas
integrados son, por definicin, no diseos de propsito general: se
desarrollan tpicamente para una sola tarea (o pequea gama de
tareas), y la plataforma se elige especficamente para optimizar
esa aplicacin. No slo este hecho de hacer la vida difcil para los
desarrolladores de sistemas embebidos, tambin hace que la
depuracin y control de los sistemas ms duro tambin, ya que se
necesitan diferentes herramientas de depuracin en diferentes
plataformas.
Para identificar y corregir errores en el sistema (por ejemplo,
problemas lgicos o de sincronizacin en el cdigo, o un error de
diseo en el hardware);
Para recopilar informacin 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 caractersticas importantes (por ejemplo, consumo de
energa, fiabilidad, respuesta en tiempo real, etc.).
3.5.7 Anti depuracin
Es la aplicacin de una o ms tcnicas de cdigo informtico que
impide los intentos de ingeniera inversa o depuracin de un
proceso de destino, Se utiliza activamente en los esquemas
legtimos de proteccin de copia, pero tambin es utilizado por el

malware, para disfrutar su deteccin y eliminacin. Las tcnicas


utilizadas en la lucha contra la depuracin son:

Api basado en: Comprueba la existencia de un depurador

utilizando la informacin del sistema.


Excepcin basada en: compruebe si las excepciones son

interferidas.
Bloques de proceso e hilo: compruebe si los bloques de proceso

e hilo han sido manipulados.


Cdigo modificacin: comprobar modificaciones de cdigo
hechas por un depurador manipular los puntos de interrupcin
de software.

4.0 PRUEBAS DE INTEGRACIN


La necesidad de realizar las pruebas de integracin viene dada por el hecho
de que los mdulos 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 integracin es una prueba sistemtica para construir la
arquitectura del software, mientras al mismo tiempo, se aplican las pruebas
para descubrir errores asociados a la interfaz, asegurndonos que los
mdulos que estn relacionados ejecuten correctamente.
A menudo se tiende a intentar una integracin, se combinan todos los
componentes por anticipado, se prueba todo el programa como un todo. El
objetivo es tomar los mdulos probados en unidad y estructurar un
programa que est de acuerdo con el que dicta el diseo.
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 integracin:
4.1.1 Integracin descendente:
Es una estrategia de integracin incremental a la construccin de la
estructura de programas, en el cual se integran los mdulos
movindose en direccin hacia abajo por la jerarqua comenzando por
el control principal (Programa principal). Los mdulos 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 Integracin ascendente:


Es donde la construccin del diseo empieza desde los mdulos
ms bajos hacia arriba (mdulo principal), el procesamiento
requerido de los mdulos subordinados siempre est disponible y
elimina la necesidad de resguardo.
La seccin de una estrategia de integracin depende de las
caractersticas depende de las caractersticas del software y, a
veces, del plan del proyecto, en algunos de los casos se puede
combinar ambas estrategias.

Jerarqua de Pruebas
Ejemplo:
Durante el proceso de fabricacin de un bolgrafo, la tapa, el cuerpo, la
cola y el clip, el cartucho de tinta y el bolgrafo se producen por
separado y se prueban unitariamente por separado. Cuando dos o ms
unidades estn listas, se ensamblan, se lleva el acabo las pruebas de
integracin. Por ejemplo, si la tapa encaja en el cuerpo o no.

El propsito de la integracin
El propsito de las pruebas de integracin es exponer los fallos en
la interaccin entre unidades integradas, como tambin es verificar,
el rendimiento y la fiabilidad funcional, y exigencias impuestas a los
principales elementos de diseo. Estos "objetos de diseo", es
decir, los conjuntos (o grupos de unidades), se ejercen a travs de
sus interfaces usando pruebas de caja negra.
4.2 Mtodos
Se puede usar cualquiera de los mtodos.
1. Pruebas de Caja Negra
2. Pruebas de Caja Blanca
3. Pruebas de Caja Gris
Normalmente, el mtodo depende de tu definicin 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 mdulo, charter o seccin especfica de un
software, es decir, es una manera de encontrar casos especficos
en ese mdulo que atiendan a su especificacin.
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 mdulos o charters de
interfaz

de

usuario

(pantalla,

ficheros,

canales

de

comunicacin) pero suelen ser tiles en cualquier mdulo ya


que todos o la mayora 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 especificacin de requisitos y
documentacin funcional, estos requisitos suelen ser ms
complejos que los internos, para ello se realiza una cobertura de

especificacin que ser muy recomendable para conseguir


probar el mayor campo posible.
Este mtodo intenta encontrar errores en las siguientes
categoras:

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 inicializacin y terminacin.

Limitaciones de las pruebas de caja negra


Lo ms deseable a la hora de realizar pruebas de caja negra es
realizar una cobertura completa, pero, en la mayora de los casos
no es suficiente, siempre hay que combinarlas con pruebas de
integracin, ya que por mucho que funcionen los datos de
entrada/salida, por dentro o en terceros sistemas, pueden existir
defectos que no se estn teniendo en cuenta. Estos defectos
pueden no acarrear problemas a corto plazo, pero a lo largo del
tiempo aparecern y como dicenes 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 pginas web mediante el uso de un navegador; usando
solo (clics, las pulsaciones de teclado en el sitio web) esperando la
verificacin de las salidas contra el resultado esperado del flujo de
navegacin.
4.2.2 Pruebas de Caja Blanca
Es un mtodo de pruebas de software en el que la estructura /
diseo / implementacin interna del elemento que se prob se
sabe por el Tester. El Tester elige entradas para ejercer caminos
a travs del cdigo y determina las salidas apropiadas. Las
pruebas de caja blanca son probadas ms all de la interfaz de
usuario.
Este mtodo 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 cdigo de la aplicacin
de un campo determinado, en una pgina web, determina todas entradas
(vlidos y no vlidos) y verifica los resultados en contra de los resultados
esperados, los cuales tambin se determina mediante el estudio del cdigo
de implementacin.

4.2.3 Prueba de Caja Gris


Un tester de caja negra no tiene conocimiento de la estructura
interna de la aplicacin para ser probado, mientras que un Tester
de caja blanca conoce la estructura interna de la aplicacin. Un
Tester de caja gris sabe parcialmente la estructura interna, que
incluye el acceso a la documentacin de las estructuras de datos
internas, as como los algoritmos utilizados.
Las pruebas de caja gris son beneficiosas, ya que toma la tcnica
sencilla de pruebas de caja negra y lo combina con los sistemas
especficos de cdigo (pruebas de caja blanca).
Efecto negativos
Cobertura de cdigo parcial: En las pruebas de caja gris, el
cdigo fuente o binarios estn 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 cdigo.
Identificacin de defectos: En aplicaciones distribuidas, es difcil
de identificar los defectos y asociarlos.

4.3 Enfoques
4.3.1 Big Bang
Es un enfoque de Pruebas de Integracin, donde todos o la
mayora 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, cul es la diferencia entre el Big Bang entre Pruebas
de Integracin y Pruebas del Sistema? Bueno, las pruebas
anteriores slo ven las interacciones entre las unidades mientras
que el segundo pone a prueba todo el sistema correctamente,
todo el proceso de integracin ser ms complicado y puede

impedir que el equipo de pruebas de lograr el objetivo de las


pruebas de integracin.

4.3.2 Top Down


Es un enfoque para pruebas de integracin, donde las unidades
de primer nivel son probadas primero y unidades de nivel inferior
se ponen a prueba paso a paso despus 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 cdigo usado como sustituto de alguna otra
funcionalidad. Un Stubs puede simular el comportamiento de
cdigo existente. o ser el sustituto temporal para un cdigo an
no desarrollado.
4.4 Consejos
Asegrese de que tiene un documento de diseo de detalle
adecuado donde las interacciones entre cada unidad estn claramente
definidas. De hecho, usted no ser capaz de realizar pruebas de
integracin sin esta informacin.
Asegrese de que tiene un sistema de gestin de configuracin de
software robusta en su lugar. O de lo contrario, tendr un momento
difcil el seguimiento de la versin correcta de cada unidad, sobre todo
si la cantidad de unidades que integrarse es enorme.
Asegrese de que cada unidad es de primera unidad de prueba
antes de iniciar pruebas de integracin.
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 regresin son importantes cada vez que

integra una unidad, y las pruebas de regresin manual puede ser


ineficiente.

5.0 IMPLEMENTACIN DE PRUEBAS UNITARIAS Y DE INTEGRACIN


Es importante mencionar que cuando nos referimos a la Implementacin
de las pruebas unitarias, es comn referirnos tambin 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 ejecucin de un programa cuya
intencin 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 cdigo fuente de los mdulos, mientras que las pruebas de
caja

negra

poseen

criterios

especificaciones de los mdulos.

basados

en

las

interfaces

las

7.0 BIBLIOGRAFA:
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
Depuracin de Programas:
http://www.arqhys.com/general/depuracion-de-programas.html
Proceso de Depuracin:
http://www.zator.com/Cpp/E1_4_5.htm

También podría gustarte