Contenido

INTRODUCCION................................................................................................... 3
PRUEBAS DE SOFTWARE..................................................................................... 4
METODOLOGA DE PRUEBAS............................................................................... 4
ESTRATEGIAS DE PRUEBA DEL SOFTWARE..........................................................8
ASPECTOS ESTRATGICOS EN LAS PRUEBAS DE SOFTWARE............................10
TIPOS DE PRUEBAS........................................................................................... 12
Prueba Unitaria.............................................................................................. 12
Prueba de Integracin.................................................................................... 13
Pruebas del Sistema...................................................................................... 15
Prueba de Aceptacin.................................................................................... 17
Pruebas de Humo (Smoke Testing o Ad Hoc).................................................18
HERRAMIENTAS PARA PRUEBAS DE SOFTWARE.................................................20
Selenium........................................................................................................ 20
Firebug........................................................................................................... 21
JMeter............................................................................................................ 22
Testlink........................................................................................................... 23
CONCLUSIONES.............................................................................................. 25
RECOMENDACIONES......................................................................................... 26
BIBLIOGRAFIA.................................................................................................... 27

INTRODUCCION

En un proyecto de desarrollo de software los errores (bugs),

puede presentarse en cualquiera de las etapas del ciclo de
vida del software.
Aun cuando se intente detectarlos despus de cada fase
utilizando tcnicas como la inspeccin, algunos errores
permanecen sin ser descubiertos.
Por lo tanto es muy probable que el cdigo final contenga
errores de requerimientos y diseo, adicionales a los
introducidos en la codificacin.
Las pruebas de software son una parte importante pero muy
costosa del proceso de desarrollo de software.
Pueden llegar a representar entre el 30 y 50 % del costo total
del desarrollo del software.
Sin embargo, los costos de las fallas en un software en
operacin pueden llegar a ser mucho mayores (catastrficos).

PRUEBAS DE SOFTWARE

METODOLOGA DE PRUEBAS
Los procesos de aseguramiento de calidad de un producto de
software suelen dividirse en lo que respecta a su componente
analtico en pruebas estticas y dinmicas. La diferencia
fundamental entre estos tipos de pruebas, radica en que las
pruebas estticas se centran en evaluar la calidad con la que
se est generando la documentacin del proyecto, por medio
de revisiones peridicas, mientras que las pruebas dinmicas,
requieren de la ejecucin del software con el fin de medir el
nivel de calidad con la que este fue codificado y el nivel de
cumplimiento en relacin con la especificacin del sistema.
Realizar pruebas dinmicas a un producto de software, suele
en la mayora de los casos confundirse con una simple
actividad de ejecucin de pruebas y reporte de incidencias,
sin embargo, para productos de complejidad media en
adelante, lo recomendable es implementar de manera formal
una metodologa de pruebas que se ajuste y acople
uniformemente con la metodologa de desarrollo seleccionada
por la firma desarrolladora.
Para procesos de desarrollo basados en la metodologa RUP o
mtodos tradicionales,
implementar una metodologa de
pruebas es totalmente viable, teniendo en cuenta que estas
metodologas estn orientadas a la documentacin y a la
formalizacin de todas las actividades ejecutadas. Si por el
contrario,
la firma desarrolladora gua su proceso bajo
lineamientos basados en metodologas giles, ser necesario

reevaluar la conveniencia de ejecutar todas las actividades

que implica un proceso de pruebas formal, lo que en la
mayora de los casos, conlleva a reducir al mnimo las
actividades relacionadas con un proceso de pruebas,
circunstancia que naturalmente puede desencadenar en la
liberacin de productos con bajos niveles de calidad.
Un proceso de pruebas formal, est compuesto, cuando
menos por las siguientes 5 tpicas etapas:

Planeacin de pruebas.
Diseo de pruebas.
implementacin de pruebas.
Evaluacin de criterios de salida.
Cierre del proceso.

Planeacin de Pruebas
Es la etapa en donde se ejecutan las primeras actividades
correspondientes al proceso de pruebas y
tiene como
resultado un entregable denominado plan de pruebas el cual
debe estar conformado en cuando menos por aspectos tales
como:
Alcance de la prueba: Determina que funcionalidades del
producto y/o software sern probadas durante el transcurso
de la prueba. Este listado de funcionalidades a probar se
extrae con base a un anlisis de riesgos realizado de manera
previa, que tienen en cuenta variables tales como el impacto
que podra ocasionar la falla de una funcionalidad y la
probabilidad de falla de una funcionalidad. Producto de este
anlisis, se cuenta con informacin adicional que permite
determinar adems del alcance detallado del proceso de
pruebas, la prioridad con la que las funcionalidades deben
probarse y la profundidad de las pruebas.

Tipos de Prueba: En este punto se debe determinar qu

tipos de pruebas requerira el producto. No todos los
productos de software requieren la aplicacin de todos los
tipos de pruebas que existen, por esta razn, es estrictamente
necesario que el lder de pruebas se plantee preguntas que le
permitan determinar qu tipos de prueba son aplicables al
proyecto en evaluacin. Los posibles tipos de prueba a aplicar
son: pruebas de stress, pruebas de rendimiento, pruebas de
carga, pruebas funcionales, pruebas de usabilidad, pruebas de
regresin, entre otros.
Estrategia de Pruebas: Teniendo en cuenta que no es viable
probar con base a todas las posibles combinaciones de datos,
es necesario determinar a travs de un anlisis de riesgos
sobre que funcionalidades debemos centrar nuestra atencin.
Adicionalmente, una buena estrategia de pruebas debe
indicar los niveles de pruebas (ciclos) que aplicaremos y la
intensidad o profundidad a aplicar para cada nivel de pruebas
definido. En este punto tambin es importante definir los
criterios de entrada y salida para cada ciclo de pruebas a
ejecutar.
Criterios de Salida: Entre las partes involucradas en el
proceso, se define de manera formal, bajo qu condiciones se
puede considerar
que una actividad de pruebas fue
finalizada. Los criterios de salida se deben definir para cada
nivel de pruebas a ejecutar. Algunos ejemplos de criterios de
salida que pueden ser utilizados son: porcentaje de
funcionalidades de alto riesgo probadas con xito, nmero
defectos crticos y/o mayores aceptados, etc.
Otros aspectos: Tal y como se realiza en cualquier plan de
proyecto, se debe incluir una estimacin de tiempos, los roles
y/o recursos que harn parte del proceso, la preparacin del
entorno de pruebas, cronograma base.

Diseo de Pruebas
Una vez elaborado y aprobado el plan de pruebas, el equipo
de trabajo debe iniciar el anlisis de toda la documentacin
existente con respecto al sistema, con el objeto de iniciar el
diseo de los casos de prueba. Los entregables claves para
iniciar este diseo pueden ser: casos de uso, historias de
usuario, arquitectura del sistema, diseos, manuales de
usuario (si existen), manuales tcnicos (si existen). El diseo
de los casos, debe considerar la elaboracin de casos
positivos y negativos. Los casos de prueba negativos permiten
validar cmo se comporta el sistema ante situaciones atpicas
y permite verificar la robustez del sistema, atributo que
constituye unos de los requerimientos no funcionales
indispensable para
cualquier software.
Por ltimo, es
necesario definir cules son los datos de prueba necesarios
para la ejecucin de los casos de prueba diseados.

Implementacin y Ejecucin de Pruebas

La ejecucin de pruebas debe iniciar con la creacin de los
datos de prueba necesarios para ejecutar los casos de prueba
diseados. La ejecucin de estos casos, puede realizarse de
manera manual o automatizada; en cualquiera de los casos,
cuando se detecte un fallo en el sistema, este debe ser
documentado y registrado en una herramienta que permita
gestionar los defectos (Bug Tracker). Una vez el defecto ha
sido corregido por la firma desarrolladora en su respectivo
proceso de depuracin, es necesario realizar un re-test que
permita confirmar que el defecto fue solucionado de manera
exitosa. Por ltimo, es indispensable ejecutar un ciclo de
regresin que nos permita garantizar, que los defectos
corregidos en el proceso de depuracin de la firma, no hayan
desencadenado otros tipos de defectos en el sistema.

Evaluacin de Criterios de Salida

Los criterios de salida son necesarios para determinar si es
posible dar por finalizado un ciclo de pruebas. Para esto, es
conveniente definir una serie de mtricas que permitirn al
finalizar un proceso de pruebas, comparar los resultados
obtenidos contra las mtricas definidas, s los resultados
obtenidos no superan la mtricas definidas, no es posible
continuar con el siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales
se pueden mencionar: cubrimiento de funcionalidades en
general, cubrimiento de funcionalidades crticas para el
sistema, Nmero de defectos crticos y mayores detectados,
etc. Tambin es importante aclarar que el proceso de pruebas
puede ser suspendido y/o paralizado, debido entre otros, a
aspectos relacionados con el presupuesto y la calidad mnima
del sistema requerida para el inicio formal de pruebas.

Cierre del proceso

Durante este periodo de cierre el cual histricamente se ha
comprobado que se le destina muy poco tiempo en la
planeacin, se deben cerrar las incidencias reportadas, se
debe verificar si los entregables planeados han sido
entregados y aprobados, se deben finalizar y aprobar los
documentos de soporte de prueba, analizar las lecciones
aprendidas para aplicar en futuros proyectos, etc.

ESTRATEGIAS DE PRUEBA DEL

SOFTWARE
Una estrategia de prueba del software integra las tcnicas de
diseo de casos de prueba en una serie de pasos bien
planificados que dan como resultado una correcta
construccin del software. Y lo que es ms importante, una
estrategia de prueba del software proporciona un mapa a
seguir para el responsable del desarrollo del software, a la
organizacin de control de calidad y al cliente: un mapa que
describe los pasos que hay que llevar a cabo como parte de la
prueba, cundo se deben planificar y realizar esos pasos, y
cunto esfuerzo, tiempo y recursos se van a requerir. Por
tanto, cualquier estrategia de prueba debe incorporar la
planificacin de la prueba, el diseo de casos de prueba, la
ejecucin de las pruebas y la agrupacin y evaluacin de los
datos resultantes.
La prueba es un conjunto de actividades que se pueden
planificar por adelantado y llevar a cabo sistemticamente.
Por esta razn se debe definir en el proceso de la ingeniera
del software una plantilla para la prueba del software: un
conjunto de pasos en los que podamos situar los mtodos
especficos de diseo de casos de prueba.
Se han propuesto varias estrategias de prueba del software en
distintos libros. Todas proporcionan al desarrollador de
software una plantilla para la prueba y todas tienen las
siguientes caractersticas generales:

La prueba comienza en el nivel de mdulo y trabaja

hacia fuera, hacia la integracin de todo el sistema
basado en computadora.

Segn el momento son apropiadas diferentes tcnicas de

prueba.
La prueba la lleva a cabo el responsable del desarrollo
del software y (para grandes proyectos) un grupo
independiente de pruebas.
La prueba y la depuracin son actividades diferentes,
pero la depuracin se debe incluir en cualquier estrategia
de prueba.
Una estrategia de prueba del software debe incluir pruebas de
bajo nivel que verifiquen que todos los pequeos segmentos
de cdigo fuente se han implementado correctamente, as
como pruebas de alto nivel que validen las principales
funciones del sistema frente a los requisitos del cliente. Una
estrategia debe proporcionar una gua al profesional y
proporcionar un conjunto de hitos para el jefe de proyecto.
Debido a que los pasos de la estrategia de prueba se dan a la
vez cuando aumenta la presin de los plazos fijados, se debe
poder medir el progreso y los problemas deben aparecer lo
antes posible.

ASPECTOS ESTRATGICOS EN LAS

PRUEBAS DE SOFTWARE
Tom Gilb plantea que se deben abordar los siguientes puntos
si se desea implementar con xito una estrategia de prueba
del software:

10

Especificar los requisitos del producto de manera

cuantificable mucho antes de que comiencen las
pruebas. Aunque el objetivo principal de la prueba es
encontrar errores, una buena estrategia de prueba
tambin evala otras caractersticas de la calidad tales
como la transportabilidad, facilidad de mantenimiento y
facilidad de uso. Todo esto debera especificarse de
manera que sea medible para que los resultados de la
prueba no sean ambiguos.
Establecer los objetivos de la prueba de manera
explcita. Se deberan establecer en trminos medibles
los objetivos especficos de la prueba. Por ejemplo la
efectividad de la prueba, la cobertura de la prueba,
tiempo medio de fallo, el coste para encontrar y arreglar
errores, densidad de fallos remanente o frecuencia de
ocurrencia, y horas de trabajo por prueba de regresin
deberan establecerse dentro de la planificacin de la
prueba.
Comprender qu usuarios va a tener el software y
desarrollar un perfil para cada categora de usuario. Usar
casos, que describan el escenario de interaccin para
cada clase de usuario pudiendo reducir el esfuerzo
general de prueba concentrando la prueba en el empleo
real del producto.
Desarrollar un plan de prueba que haga hincapi en la
prueba de ciclo rpido. Gilb recomienda que un equipo
de ingeniera del software aprenda a probar en ciclos
rpidos (2 por ciento del esfuerzo del proyecto) de
incrementos de funcionalidad y/o mejora de la calidad
tiles para el cliente y que se puedan probar sobre el
terreno. La realimentacin generada por estas pruebas

11

de ciclo rpido puede usarse para controlar los niveles de

calidad y las correspondientes estrategias de prueba.
Construir un software robusto diseado para probarse
a s mismo. El software debera disearse de manera que
use tcnicas de depuracin anti-errores. Es decir, el
software debera ser capaz de diagnosticar ciertas clases
de errores. Adems, el diseo debera incluir pruebas
automatizadas y pruebas de regresin.
Usar revisiones tcnicas formales efectivas como filtro
antes de la prueba. Las revisiones tcnicas formales
pueden ser tan efectivas como las pruebas en el
descubrimiento de errores. Por este motivo, las
revisiones pueden reducir la cantidad de esfuerzo de
prueba necesaria para producir software de alta calidad.
Llevar a cabo revisiones tcnicas formales para evaluar
la estrategia de prueba y los propios casos de prueba.
Las revisiones tcnicas formales upueden descubrir
inconsistencias, omisiones y errores claros en el enfoque
de la prueba. Esto ahorra tiempo y tambin mejora la
calidad del producto.
Desarrollar un enfoque de mejora continua al proceso de
prueba. Debera medirse la estrategia de prueba. Las
mtricas agrupadas durante la prueba deberan usarse
como parte de un enfoque estadstico de control del
proceso para la prueba del software.

TIPOS DE PRUEBAS

12

Analizaremos 5 tipos de pruebas:

Pruebas
Pruebas
Pruebas
Pruebas
Pruebas

Unitarias
de Integracin
de Sistema
de Aceptacin
de Humo

Prueba Unitaria
Objetivo de la Prueba:
Se focaliza en ejecutar cada mdulo (o unidad minima a ser
probada, ej = una clase) lo que provee un mejor modo de
manejar la integracin de las unidades en componentes
mayores.
Busca asegurar que el cdigo funciona de acuerdo con las
especificaciones y que el mdulo lgico es vlido.
Descripcin de la Prueba:
Particionar los mdulos en pruebas en unidades lgicas fciles
de probar.
Por cada unidad hay que definir los casos de prueba (pruebas
de caja blanca).
Para esto los casos de prueba deben disearse de forma tal
que se recorran todos los caminos de ejecucin posibles
dentro del cdigo bajo prueba; por lo tanto el diseador debe
construirlos con acceso al cdigo fuente de la unidad a probar.
Los aspectos a considerar son los siguientes: Rutinas de
excepcin, Rutinas de error, Manejo de parmetros,
Validaciones, Valores vlidos, Valores lmites, Rangos,
Mensajes posibles.

13

Tcnica:
Comparar el resultado esperado con el resultado obtenido.
Si existen errores, reportarlos.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en
cuenta.
Consideraciones Especiales:
Para la elaboracin de pruebas unitarias en java se puede
utillizar el JUNIT y CACTUS.

Prueba de Integracin
Objetivo de la Prueba:
Identificar errores introducidos por la combinacin de
programas probados unitariamente. Determina cmo la base
de datos de prueba ser cargada.
Verificar que las interfaces entre las entidades externas
(usuarios) y las aplicaciones funcionan correctamente.
Verificar que las especificaciones de diseo sean alcanzadas.
Determina el enfoque para avanzar desde un nivel de
integracin de las componentes al siguiente.

Descripcin de la Prueba:

14

Describe cmo verificar que las interfaces entre

componentes de software funcionan correctamente.

las

Determina cmo la base de datos de prueba ser cargada.

Determina el enfoque para avanzar desde un nivel de
integracin de las componentes al siguiente.
Decide qu acciones tomar cuando se descubren problemas.
Por cada Caso de Prueba ejecutado:
Comparar el resultado esperado con el resultado obtenido.
Tcnica:
Utilizar la tcnica top-down. Se empieza con los mdulos de
nivel superior, y se verifica que los mdulos de nivel superior
llaman a los de nivel inferior de manera correcta, con los
parmetros correctos.
Utilizar la tcnica down-top. Se empieza con los mdulos de
nivel inferior, y se verifica que los mdulos de nivel inferior
llaman a los de nivel superior de manera correcta, con los
parmetros correctos.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en
cuenta.

15

Pruebas del Sistema

Objetivo de la Prueba:
Asegurar la apropiada navegacin dentro del sistema, ingreso
de datos, procesamiento y recuperacin.
Descripcin de la Prueba:
Las pruebas del sistema deben enfocarse en requisitos que
puedan ser tomados directamente de casos de uso y reglas y
funciones de negocios. El objetivo de estas pruebas es
verificar el ingreso, procesamiento y recuperacin apropiado
de datos, y la implementacin apropiada de las reglas de
negocios. Este tipo de pruebas se basan en tcnicas de caja
negra, sto es, verificar el sistema (y sus procesos internos),
la interaccin con las aplicaciones que lo usan via GUI y
analizar las salidas o resultados.
En esta prueba se determina qu pruebas de Sistema
(usabilidad, volumen, desempeo, etc.) asegurarn que la
aplicacin alcanzar sus objetivos de negocio.
La prueba de Sistema incluye:

Prueba
Prueba
Prueba
Prueba
Prueba
Prueba
Prueba
Prueba

funcionalidad
de Usabilidad
de Performance
de Documentacin y Procedimientos
de Seguridad y Controles
de Volumen
de Esfuerzo (Stress)
de recuperacin

16

Prueba de mltiples sitios

Para sistemas web se recomienda especialmente realizar

mnimo el siguiente grupo de pruebas de sistema:

Humo
Usabilidad
Performance
Funcionalidad

Para capitalizar el trabajo hasta ahora completado, los casos

de prueba de las pruebas previas realizadas pueden
frecuentemente ser reorganizados y rehusados durante la
prueba de sistema. No obstante, deben ser desarrollados
casos de prueba adicionales para aquellos aspectos del
sistema, tales como documentacin, procedimientos y
desempeo que no han sido probados durante la prueba
unitaria y de integracin.
La prueba de sistema es compleja porque intenta validar un
nmero de caractersticas al mismo tiempo, a diferencia de
otras pruebas que slo se centran en uno o dos aspectos del
sistema al mismo tiempo.
Tcnica:
Ejecute cada caso de uso, flujo bsico o funcin utilizando
datos vlidos e invlidos, para verificar que:
Los resultados esperados ocurren cuando se utiliza un dato
vlido.
Los mensajes de error o de advertencia aparecen en el
momento adecuado, cuando se utiliza un dato invlido.
Cada regla de negocios es aplicada adecuadamente.

17

Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en
cuenta.

Consideraciones Especiales:
Identifique o describa aquellos aspectos (internos o externos)
que impactan la implementacin y ejecucin de las pruebas
del Sistema

Prueba de Aceptacin
Objetivo de la Prueba:
Determinacin por parte del cliente de la aceptacin o
rechazo del sistema desarrollado.
Descripcin de la Prueba:
La prueba de aceptacin es ejecutada antes de que la
aplicacin sea instalada dentro de un ambiente de produccin.
La prueba de aceptacin es generalmente desarrollada y
ejecutada por el cliente o un especialista de la aplicacin y es
conducida a determinar como el sistema satisface sus
criterios de aceptacin validando los requisitos que han sido
levantados para el desarrollo, incluyendo a documentacin y
procesos de negocio.
Basado en esta prueba el cliente determina si acepta o
rechaza el sistema

18

Estas pruebas estn destinadas a probar que el producto est

listo para el uso operativo. Suelen ser un subconjunto de las
Pruebas de Sistema.
Sirve para que el usuario pueda validar si el producto final se
ajusta a los requisitos fijados, es decir, si el producto est listo
para ser implantado para el uso operativo en el entorno del
usuario.
Esta prueba es complementada por la prueba de estilo.

Tcnica:
Realizacin de los documentos de planes de prueba de
aceptacin y especificacin de los mismos, basados en los
criterios de aceptacin del cliente.
Los casos prueba de aceptacin han de ser planificados,
organizados y formalizados de manera que se determine el
cumplimiento de los requisitos del sistema. Para la realizacin
de estas pruebas se necesita disponer de los siguientes
documentos:

Especificacin de requisitos del sistema.

Manual de usuario.
Manual de administrador.
Realizar Pruebas de estilo

Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en
cuenta.
Consideraciones Especiales:

19

Las Pruebas de Aceptacin se suelen realizar en un entorno de

pre-produccin.

Pruebas de Humo (Smoke Testing o Ad Hoc)

Objetivo de la Prueba:
Los objetivos son los siguientes:
Detectar los errores en realeases tempranos y de manera
fcil
Probar el sistema constantemente
Garantizar poco esfuerzo en la integracin final del
sistema
Asegurar los resultados de las pruebas unitarias
Se reducen los riesgos y a baja calidad.
Descripcin de la Prueba:
Toma ste nombre debido a que su objetivo es probar el
sistema constantemente buscando que saque humo o falle.
En algunos proyectos este tipo de prueba va junto con las
pruebas funcionales. Permite detectar problemas que por lo
regular no son detectados en las pruebas normales. Algunas
veces, si las Pruebas ocurren tarde en el ciclo de desarrollo
est ser una forma de garantizar el buen desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van de
extremo a extremo de la aplicacin.
Tcnica:
1. Realizar una integracin de todo el sistema cada cierto
periodo (se recomienda un da, mximo una semana)

20

2. Realizar los casos de prueba asignados a los casos de uso

finalizados ese da ms los realizados en das anteriores
3. Buscar eficientemente errores
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identifcaron han sido tenidos en
cuenta.
Consideraciones Especiales:
Cuando se encuentre un error en el release correspondiente al
periodo elegido para hacer las integraciones del sistema, se
detiente el desarrollo hasta que el error es corregido.
Este tipo de pruebas es til en la programacin extrema
(extremme programming) y de sistemas complejos.
Es til el uso de programas de prueba automticas que se
encarguen de probar os casos de prueba ya ejecutados en
realeases anteriores.

HERRAMIENTAS PARA PRUEBAS DE

SOFTWARE
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 tambin un
lenguaje especfico (Selenese) para escribir pruebas en un

21

amplio nmero de lenguajes de

programacin
populares
incluyendo Java, C#, Ruby,
Groovy, Perl, Php y Python.
Las pruebas pueden ejecutarse
entonces usando la mayora de
los navegadores web modernos
diferentes sistemas operativos
como Windows, Linux y OSX.

en

Los componentes de la suite

Selenium son:
Selenium IDE: Es un plugin de
Firefox que permite grabar y
reproducir tests en Firefox.
Permite generar el cdigo para
ejecutar posteriormente las
pruebas con Selenium Remote Control.
Selenium Remote Control: Es un servidor escrito en Java
que acepta comandos al navegador va HTTP. RC hace posible
escribir pruebas automatizadas para aplicaciones web, en
cualquier lenguaje de programacin lo que permite una mejor
integracin de Selenium a entornos de prueba existentes.
Selenium WebDriver: Es el sucesor de Selenium RC.
Selenium WebDriver acepta comandos (enviados en Selenese
o va el API de cliente) y los enva a un navegador.
Selenium Grid: Es un servidor que permite usar instancias
de navegador ejecutndose en mquinas remotas

Firebug

22

Es una extensin de Firefox creada

y diseada especialmente para
desarrolladores y programadores
web. Es un paquete de utilidades
con el que se puede analizar
(revisar velocidad de carga,
estructura DOM), editar,
monitorizar y depurar el cdigo
fuente, CSS, HTML y JavaScript de
una pgina web de manera
instantnea e inline.
Firebug es un complemento
indispensable para trabajar con
Selenium, ya que nos permitir
una identificacin ms rpida de los elementos de lapgina
web que estemos probando. Adems, Firebug no es un simple
inspector como DOM Inspector, adems edita y permite
guardar los cambios, un paso por delante del conocido Web
Developer.
Firebug no es un simple inspector como DOM Inspector,
adems edita y permite guardar los cambios, un paso por
delante del conocido Web Developer.

JMeter
JMeter es un proyecto de Apache que puede ser utilizado
como una herramienta de prueba de carga para analizar y
medir el desempeo de una variedad de servicios, con nfasis
en aplicaciones web. En nuestras propias palabras diremos
que JMeter es probablemente la herramienta ms utilizada
para realizar pruebas de rendimiento y stress sobre

23

aplicaciones web, aunque tambin soporta otros protocolos

como:

Web HTTP, HTTPS

SOAP
FTP
Database via JDBC
LDAP
Message-oriented middleware (MOM)
via JMS
Mail SMTP(S), POP3(S) and IMAP(S)
MongoDB (NoSQL)
Native commands or shell scripts
TCP

JMeter est desarrollado con Java, por lo que puede utilizarse

en todos los sistemas operativos con los que normalmente
trbajamos (windows, mac o linux).
Adems de todo esto, comenzar a trabajar con JMeter es
bastante sencillo. Lo que no es tan sencillo es saber leer los
resultados que nos da la herramienta, por lo que en muchos
casos, combinar una herramienta como JMeter con otra
herramienta puramente funcional, nos puede dar ms
informacin que usar JMeter de forma aislada.

Testlink
Testlink es un sistema de gestin de pruebas de software
basado en la web, es de cdigo abierto (Open Source) y
dispone de una amplia comunidad de foristas y voluntarios
que publican guas e informacin sobre cmo utilizarlo.

24

Para organizar las pruebas de software, Testlink define tres

unidades de informacin bsicas que son el Proyecto de
pruebas (Test Project), Plan de pruebas (Test Plan) y el usuario
(User), el resto de la informacin son relaciones entre estas
bases.
Para gestionar el software Testing, utilizas el Testlink para:

Definir proyectos de pruebas (Test Project).

Definir los usuarios que accedern al proyecto.
Crear casos de prueba y su informacin (Test Case).
Organizar los casos de pruebas en conjuntos de
pruebas (Test Suite).
Asignar palabras claves (keywords) a los casos de
pruebas.
Crear planes de pruebas (Test Plan) y enlazarles casos de
pruebas (Test Case).
Ejecutar los casos de prueba y registrar resultados.
Visualizar los resultados de las pruebas (Test Results).

25

CONCLUSIONES
En el desarrollo de software se deben tener en cuenta las
etapas que conforman el ciclo de vida para garantizar el xito
de una aplicacin informtica. Los productos multimedia, por
tratarse de software tambin requieren de pruebas
funcionales y estructurales. Es mejor detectar a tiempo
cualquier error, por mnimo que sea, antes de empezar a
distribuir el producto al cliente o pblico destino, para evitar
posteriores dolores de cabeza.

26

RECOMENDACIONES
Cada caso de prueba debe definir el resultado de salida
esperado que se comparar con el realmente obtenido.
El programador debe evitar probar sus propios programas, ya
que desea (consciente o inconscientemente) demostrar que
funcionan sin problemas.
Se debe inspeccionar a conciencia el resultado de cada
prueba, para as poder descubrir posibles sntomas de
defectos.
Al generar casos de prueba, se deben incluir tanto datos de
entrada vlidos como no vlidos.
Las pruebas deben centrarse en dos objetivos: probar si el
software no hace lo que debe hacer o viceversa, es decir, si
provoca efectos secundarios adversos

27

No deben hacerse planes de prueba suponiendo que,

prcticamente, no hay defectos en los programas y, por lo
tanto, dedicando pocos recursos a las pruebas siempre hay
defectos.
La experiencia parece indicar que donde hay un defecto hay
otros, es decir, la probabilidad de descubrir nuevos defectos
en una parte del software es proporcional al nmero de
defectos ya descubierto.
Las pruebas son una tarea tanto o ms creativa que el
desarrollo de software. Siempre se han considerado las
pruebas como una tarea destructiva y rutinaria.

BIBLIOGRAFIA
1.- [Link]
2.- [Link]
3.- [Link]
4.- [Link]
5.- [Link]
6.-[Link]