Pruebas de Sistema I

aaaaa
Universidad Nacional San Luis Gonzaga de Ica

PRUEBAS DE SISTEMAS I
2

Aaaaa

FACULTAD DE INGENIERA DE SISTEMAS

PRUEBAS DE SISTEMAS I FACULTAD DE INGENIERA DE SISTEMAS 3

3

Curso : Pruebas de Software
Ciclo : IX S-2
Catedrtico : Ing. Alonso Morales Loayza
Integrantes : Cusi Alvarado Julio Cesar

Paucca Inca Erick Jim
Quispe Cuaresma Paul

Ica Per
2014

PRUEBAS DE SISTEMAS I

Universidad Nacional San Luis Gonzaga de Ica
Ao de la promocin de la industria Responsable y del Compromiso Climtico

4

Dedicatoria
Con todo respeto y gratitud a la Facultad de Ingeniera
de Sistemas - UNSLG, que ante dificultades supo
Brindarnos lo Mejor de S para nuestro Crecimiento y
Desarrollo Profesional, a nuestros profesores por la
grandiosa Labor que desempean y por todas las
facilidades prestadas para la realizacin del presente
trabajo.

5
INDICE
INDICE ............................................................................................................................... 5
ndice De Figuras ................................................................................................................. 7
NDICE DE TABLAS ............................................................................................................... 7
Introduccin ........................................................................................................................ 8
Captulo 1 ............................................................................................................................ 9
Pruebas Funcionales ............................................................................................................ 9
1.1. Definicin .................................................................................................................... 9
1.2. Objetivos................................................................................................................... 10
Captulo 2 .......................................................................................................................... 10
Diseos de Casos de Uso e Historias De Usuario ............................................................. 10
2.1. Diagrama de Caso de Usos ............................................................................................ 10
2.2. Elementos Principales de Diagrama de Casos de Uso ................................................. 11
2.2.1 ACTORES ............................................................................................................... 11
2.2.2. Caso de Uso ............................................................................................................ 12
2.2.3 Relaciones ................................................................................................................ 12
2.3. Casos de uso .................................................................................................................. 14
2.3.1. CARACTERSTICAS DE CASO DE USOS......................................................... 15
2.3.2. Descripcin de casos de uso ................................................................................... 15
2.3.3. Alternativas de casos de uso ................................................................................... 16
2.3.4. Beneficios de casos de usos .................................................................................... 17
2.4. Historia de usuario ......................................................................................................... 17
2.4.1. Estructura de la historia de usuario ........................................................................ 18
2.4.2. Caractersticas de historia de usuario ..................................................................... 19
2.4.3. Beneficios de historia de usuario ........................................................................... 20
2.5. Diferencia entre Casos de uso vs historia de uso........................................................... 21
Captulo 3 .......................................................................................................................... 22
Pruebas de Regresin ........................................................................................................ 22

6
3.1. Definicin ...................................................................................................................... 23
3.2. Objetivo ......................................................................................................................... 24
3.3. Tipos de Regresin ........................................................................................................ 24
Captulo 4 .......................................................................................................................... 26
Herramientas para Implementar y Ejecutar Pruebas Funcionales y de Regresin ............ 26
4.1. Automatizacin de Pruebas Funcionales ....................................................................... 26
4.2. Herramientas de Pruebas de Regresin y Funcionales .................................................. 27
4.2.1. vTest ........................................................................................................................ 27
4.2.2. IBM Rational Functional Tester ............................................................................. 29
4.2.3. IBM Rational Robot ................................................................................................ 30
4.2.4. GXTest .................................................................................................................... 32
4.2.5. JUnit ........................................................................................................................ 33
4.2.6. Selenium ................................................................................................................. 34
Captulo 5 .......................................................................................................................... 36
Monitoreo de Resultados ................................................................................................... 36
5.1. Evaluacin ..................................................................................................................... 36
5.2. Monitoreo ...................................................................................................................... 37
5.3. Relacin entre Monitoreo y Evaluacin ........................................................................ 37
5.4. Mecanismos de Monitoreo ............................................................................................ 37
5.5. Elementos del Plan de Monitoreo .................................................................................. 38
5.5.1. Plan o Enunciado .................................................................................................... 38
5.5.2. Esquema o Indicadores ........................................................................................... 38
5.5.3. Esquema de Metas durante el Periodo .................................................................... 39
Conclusiones ..................................................................................................................... 40
Bibliografa ........................................................................................................................... 41


7
ndice De Figuras
Figura 1. Representacion de Diagrama de Uso ............................................................ 11
Figura 2. Actor de Diagrama de Casos de Uso.11
Figura 3. Representacin de un caso de uso ................................................................ 12
Figura 4. Ejemplo de La relacin Include ....................................................................... 13
Figura 5. Ejemplo de La Relacion Extend ...................................................................... 14
Figura 6. Ejemplo De Generalizacion ............................................................................ 14
Figura 7. Ejemplo de Historia de Usuario ...................................................................... 18
Figura 8. Composicion de ua Historia de Usuario .......................................................... 18
Figura 9. Diferencias entre Csos de Uso e Historias de Usuario ................................... 21
Figura 10. Regresion Testing ........................................................................................ 22
Figura 11. Herramienta vTest ........................................................................................ 28
Figura 12. Herramienta IBM Rational Robot .................................................................. 31
Figura 13. Herramienta Selenium .................................................................................. 35
Figura 14. Dinamica de Funcionamiento de La Herramienta Selenium ......................... 35
Figura 15. Monitoreo De Resultados ............................................................................. 36
Figura 16. Metas Durante el Periodo ............................................................................. 39
NDICE DE TABLAS

Table 1. Descripcion del Caso de Uso Ingresando pedido..15
Tabla 2. Alternativa de un caso de uso.. ..16


8
Introduccin
La fase de pruebas del sistema tiene como objetivo verificar el sistema software para
comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse varios
tipos distintos de pruebas en funcin de los objetivos de las mismas. Algunos tipos son
pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad,
etc. Este trabajo habla de las pruebas funcionales. Estas pruebas verifican que el sistema
software ofrece a los actores humanos la funcionalidad recogida en su especificacin.
Una de las tcnicas ms empleadas para la especificacin funcional de sistemas software son
los casos de uso. Las principales ventajas de los casos de uso son que ocultan los detalles
internos del sistema, son rpidos de construir, fciles de modificar y entender por los clientes
y futuros usuarios del sistema y pueden aplicarse a distintos tipos de sistemas.


9
Captulo 1
Pruebas Funcionales
1.1. Definicin
Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen
por objetivo probar que los sistemas desarrollados, cumplan con las funciones especficas
para los cuales han sido creados, es comn que este tipo de pruebas sean desarrolladas por
analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la ltima
etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a produccin.
A este tipo de pruebas se les denomina tambin pruebas de comportamiento o pruebas de
caja negra, ya que los Tester o analistas de pruebas, no enfocan su atencin a como se
generan las respuestas del sistema, bsicamente el enfoque de este tipo de prueba se basa
en el anlisis de los datos de entrada y en los de salida, esto generalmente se define en los
casos de prueba preparados antes del inicio de las pruebas. Mediante las pruebas funcionales
validamos el cumplimiento de las aplicaciones desarrolladas contra las funciones detalladas
en el documento de requisitos del cliente, buscando reducir los defectos en la etapa de
operacin y permitiendo la correccin de los mismos a costos reducidos al ser encontrados
en etapas tempranas.
Los sistemas que han pasado por pruebas unitarias tienen un menor tiempo de pruebas
funcionales, este comportamiento es obvio, ya que las pruebas unitarias nos permiten
encontrar los errores ms evidentes y fciles de corregir, en la etapa de pruebas funcionales
el sistema debera estar bastante estable y con muy pocos errores crticos. Si un sistema llega
a la etapa de pruebas funcionales con demasiados errores crticos y/o bloqueantes, se debera
devolver el sistema a la etapa de pruebas unitarias ya que resulta muy poco productivo realizar
pruebas funcionales con sistemas inestables, el avance es demasiado lento y el analista de
pruebas no podr apoyar mucho en la resolucin de los errores ya que en esta etapa solo se
centra la atencin en las entradas y salidas, y no en la lgica intermedia, (Black Box Caja
Negra)


10
1.2. Objetivos
- Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo la
navegacin, entrada de datos, procesamiento y obtencin de resultados.
- Reduccin de costos en etapas temprana
- Aumentar la satisfaccin del cliente
Captulo 2
Diseos de Casos de Uso e
Historias De Usuario
2.1. Diagrama de Caso de Usos
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de
diagrama de comportamiento. Los diagramas de casos de uso documentan el comportamiento
de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan
los requisitos funcionales del sistema, es decir, representan las funciones que un sistema
puede ejecutar.
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el
sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactan
(operaciones o casos de uso).
Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras
los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los
diagramas de casos de uso.


11

Figura 1. Representacin de un diagrama de caso de uso.
2.2. Elementos Principales de Diagrama de Casos de Uso
Los elementos principales de diagrama de casos de uso son:
2.2.1 ACTORES
Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier
cosa externa que interacta con el sistema. No tiene por qu ser un ser humano, puede ser
otro sistema informtico o unidades organizativas o empresas.
Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol,
mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta
forma, un usuario puede acceder al sistema como distintos actores.
Figura 2. Actor de Diagrama de Casos de Uso.

12
2.2.2. Caso de Uso
Es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo
algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan
actores. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto
con otros actores, intercambia datos o control con el sistema, participando de ese caso de
uso.
El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente
por el principal objeto o entidad del sistema que es afectado por el caso. Grficamente, los
casos de uso se representan con un valo, con el nombre del caso en su interior. Veamos su
representacin grfica de un caso de uso en la figura.

Figura 3. Representacin de un caso de uso
2.2.3 Relaciones
Las cuatro relaciones principales entre los casos de uso son soportadas por el estndar UML,
el cual describe notacin grfica para esas relaciones.
a) Asociacin:
Una asociacin es la relacin de comunicacin ms simple entre un actor y el sistema.
Las asociaciones implican que un actor interacta con el comportamiento modelado en el
caso de uso. La notacin para las asociaciones es una lnea simple entre el actor y el caso
de uso en el que participa.

13
b) Inclusin (include)
Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro caso de uso.
El primer caso de uso a menudo depende del resultado del caso de uso incluido. En trminos
muy simples, cuando relacionamos dos casos de uso con un include, estamos diciendo que
el primero (el caso de uso base) incluye al segundo (el caso de uso incluido). Es decir, el
segundo es parte esencial del primero. Sin el segundo, el primero no podra funcionar bien;
pues no podra cumplir su objetivo. Para una venta en caja, la venta no puede considerarse
completa si no se realiza el proceso para cobrarla en ese momento. El caso de uso Cobrar
Renta est incluido en el caso de uso Rentar Video, o lo que es lo mismo Rentar Video
incluye (<<include>>) Cobrar Renta.

Figura 4. Ejemplo de La elacin Include
c) Extensin (extend)
Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a
otro. Pero, una de las diferencias bsicas es que en el caso del extend hay
situaciones en que el caso de uso de extensin no es indispensable que ocurra, y
cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de uso
base. En cambio en el include es necesario que ocurra el caso incluido, tan slo para
satisfacer el objetivo del caso de uso base. Ejemplo: Puedes Realizar Venta sin
Acumular Puntos de Cliente VIP, cuando no eres un cliente VIP. Pero, si eres un
cliente VIP s acumulars puntos. Por lo tanto, Acumular Puntos es una extensin de
Realizar Venta y slo se ejecuta para cierto tipo de ventas, no para todas.


14

Figura 5. Ejemplo de La Relacin Extend

d) Generalizacin
La Generalizacin es la actividad de identificar elementos en comn entre conceptos
y definir las relaciones de una superclase (concepto general) y subclase (concepto
especializado). Relacin entre un caso de uso general y otro ms especfico que
hereda caractersticas y aade otras.

Figura 6. Ejemplo de Generalizacin

2.3. Casos de uso
Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para
llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso
se denominan actores. Los casos de usos no va permitir que se cumpla los requerimientos
funcionales del sistema.
En el contexto de ingeniera del software, un caso de uso es una secuencia de interacciones
que se desarrollarn entre un sistema y sus actores en respuesta a un evento que inicia un
actor principal sobre el propio sistema.


15
2.3.1. CARACTERSTICAS DE CASO DE USOS
Los casos de uso tienen las siguientes caractersticas:
1) Estn expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta
con l, aunque el nfasis est puesto en la interaccin.
4) Son iniciados por un nico actor.
5) Estn acotados al uso de una determinada funcionalidad claramente diferenciada
del sistema.

2.3.2. Descripcin de casos de uso

Los casos de uso se documentan con texto informal. En general, se usa una lista numerada
de los pasos que sigue el actor para interactuar con el sistema. A continuacin se muestra
una parte simplificada de la descripcin del caso de uso Ingresando Pedido.

Tabla 1. Descripcin del caso de Uso Ingresando Pedido
Caso de Uso: Ingresando Pedido.
Actor: Empleado de Ventas.
1) El cliente se comunica con la oficina de ventas, e informa su nmero de
cliente
2) El oficial de ventas ingresa el nmero de cliente en el sistema
3) El sistema obtiene la informacin bsica sobre el cliente
4) El cliente informa el producto que quiere comprar, indicando la cantidad
5) El sistema obtiene la informacin sobre el producto solicitado, y confirma
su disponibilidad
6) Se repite el paso 4) hasta que el cliente no informa ms productos
7).

16
2.3.3. Alternativas de casos de uso
Durante la ejecucin de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo,
mientras se ingresa un pedido, el cliente puede solicitar un producto que est discontinuado.
El sistema deber en este caso informar esta situacin al empleado que ingresa el pedido.
Esas desviaciones del curso normal del caso de uso se llaman alternativas. Las alternativas
tienen las siguientes caractersticas:
1) Representan un error o excepcin en el curso normal del caso de uso.
2) No tienen sentido por s mismas, fuera del contexto del caso de uso en el que
ocurren.
Si bien en la bibliografa las alternativas se documentan al final del caso de uso, la experiencia
demuestra que resulta til documentar los casos en tablas, mostrando el curso principal en la
primera columna, y las alternativas en una segunda columna, como lo muestra el siguiente
ejemplo:
Caso de Uso: Ingresando Pedido
Actor: Empleado de ventas
Curso Normal Alternativas Curso Normal Alternativas
1) El cliente se comunica con la oficina de
ventas, e informa su nmero de cliente

2) El oficial de ventas ingresa el nmero de
cliente en el sistema

3) El sistema obtiene la informacin bsica
sobre el cliente
3.1 Si no est registrado, se le informa que
debe registrarse en la oficina de clientes
4) El cliente informa el producto que quiere
comprar, indicando la cantidad

5) El sistema obtiene la informacin sobre
el producto solicitado, y confirma su
disponibilidad.
5.1 Si no hay disponibilidad del producto, el
sistema informa la fecha de reposicin
6) Se repite el paso 4) hasta que el cliente no
informa ms productos

Tabla 2. Alternativas de un caso de uso
De esta forma, es mucho ms simple ver en qu parte del caso de uso puede ocurrir la
excepcin, y se mantiene la ventaja de poder leer de corrido el curso normal.

17
2.3.4. Beneficios de casos de usos
La tcnica de caso de uso tiene xito en sistemas interactivos, ya que expresa la
intencin que tiene el actor (su usuario) al hacer uso del sistema.

Como tcnica de extraccin de requerimiento permite que el analista se centre en las
necesidades del usuario, qu espera ste lograr al utilizar el sistema, evitando que la
gente especializada en informtica dirija la funcionalidad del nuevo sistema
basndose solamente en criterios tecnolgicos.

A su vez, durante la extraccin (elicitation en ingls), el analista se concentra en las
tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor
valor aportan al negocio. Esto facilita luego la priorizacin del requerimiento.

2.4. Historia de usuario
Una historia de usuario es una representacin de un requisito de software escrito en una o
dos frases utilizando el lenguaje comn del usuario. Las historias de usuario son utilizadas en
las metodologas de desarrollo giles para la especificacin de requisitos (acompaadas de
las discusiones con los usuarios y las pruebas de validacin). Cada historia de usuario debe
ser limitada, esta debera poderse escribir sobre una nota adhesiva pequea. Dentro de la
metodologa XP las historias de usuario deben ser escritas por los clientes.
Las historias de usuario son una forma rpida de administrar los requisitos de los usuarios sin
tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para
administrarlos. Las historias de usuario permiten responder rpidamente a los requisitos
cambiantes. Una buena historia de usuario describe esta funcionalidad, quin la necesita, y
cmo y porqu se va a utilizar.

18

Figura 7. Ejemplo de Historia de Usuario

2.4.1. Estructura de la historia de usuario
La historia de usuario est compuesta por:

Figura 8. Composicin de una Historia de Usuario
a. ID: Identificador de la historia de usuario.
b. TTULO: Ttulo descriptivo de la historia de usuario.
c. DESCRIPCIN: Descripcin sintetizada de la historia de usuario. Si bien el estilo
puede ser libre, la historia de usuario debe responder a tres preguntas: Quin se

19
beneficia? Qu se quiere? y Cul es el beneficio? Por ello, algunos autores
recomiendan redactar las historias de usuario segn el formato:
Como (rol) quiero (algo) para poder (beneficio)
d. ESTIMACIN: Estimacin del coste de implementacin en unidades de desarrollo
(estas unidades representarn el tiempo terico de desarrollo/hombre que se estipule
al comienzo del proyecto).
e. VALOR: Es dado por el cliente. El Manifiesto gil deja claro que una de nuestras
prioridades debe ser entregar software que funciona. ste, adems, maximizar el
valor y la satisfaccin percibida por el cliente. El valor determinar, junto con el tiempo,
el orden con el que las historias de usuario van a ser implementadas.
f. DEPENDENCIAS: Una historia de usuario no debera ser dependiente de otra historia,
pero en ocasiones es necesario mantener la relacin. En este apartado se indicaran
los IDs de las tareas de las que depende una tarea.
g. PRUEBAS DE ACEPTACIN: Pruebas consensuadas entre el cliente y el
desarrollador y que el cdigo debe superar para dar como finalizada la implementacin
del requerimiento. Tambin se las suele denominar criterios de aceptacin.
Las historias de usuario son comnmente usadas en las metodologas giles como Scrum o
XP
2.4.2. Caractersticas de historia de usuario
Las Historias de Usuario deben cumplir las siguientes caractersticas para que puedan realizar
su funcin de manera correcta:
Independientes. Deben ser atmicas en su definicin. Es decir, se debe intentar que
no dependa de otras historias para poder completarla.
Negociables. La historia en s misma no es lo suficientemente explcita como para
considerarse un contrato, la discusin con los usuarios debe permitir esclarecer su
alcance y ste debe dejarse explcito bajo la forma de pruebas de validacin. Se puede
reemplazar por otra de diferente prioridad.
Valoradas. Deben ser valoradas por el cliente. Para poder saber cunto aporta al Valor
de la aplicacin y junto con la estimacin convertirse en un criterio de prioridad.
Estimables. los desarrolladores necesitan poder estimar una historia de usuario para
permitir que se pueda priorizar y planificar la historia.
Pequea. una buena historia debe ser pequea en esfuerzo, generalmente
representando no ms de 2-3 personas/semana de trabajo. Una historia que es ms

20
grande va a tener ms errores asociados a la estimacin y alcance. que no sean
grande, funcionalidades pequea
Verificables. Este es el gran avance de las Historias de Usuario. Que, junto con el
cliente, se acuerdan unos Criterios de Aceptacin que verifican si se ha cumplido con
las funcionalidades descritas y esperadas.
2.4.3. Beneficios de historia de usuario
Al ser muy corta, sta representa requisitos del modelo de negocio que pueden
implementarse rpidamente (das o semanas)
Necesitan poco mantenimiento
Mantienen una relacin cercana con el cliente
Permite estimar fcilmente el esfuerzo de desarrollo


21
2.5. Diferencia entre Casos de uso vs historia de uso

Figura 9. Diferencias entre Casos de Uso e Historia de Usuario


22
Captulo 3
Pruebas de Regresin
Cuando se dan situaciones de prisas por cumplir plazos, en otros por la necesidad de
solucionar una urgencia y en otros tantos porque no se piensa que determinados cambios en
el cdigo puedan provocar efectos colaterales en la aplicacin. Las posibilidades de que se
produzcan este tipo de problemas dependern mucho de la calidad de la codificacin y de la
seccin del cdigo que se est tocando, ya que no es lo mismo tocar una clase con un
alto acoplamiento que otra.
Para reducir el riesgo de que aparezcan efectos colaterales, es conveniente la realizacin de
pruebas de regresin que se basan principalmente en realizar testing sobre funcionalidades
de la aplicacin que presentan riesgo de haber sido afectadas por los cambios.
Figura 10. Regresin Testing


23
3.1. Definicin
Se denominan Pruebas de regresin a cualquier tipo de pruebas de software que intentan
descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias
funcionales con respecto al comportamiento esperado del software, inducidos por cambios
recientemente realizados en partes de la aplicacin que anteriormente al citado cambio no
eran propensas a este tipo de error.
Esto implica que el error tratado se reproduce como consecuencia inesperada del citado
cambio en el programa.
Este tipo de cambio puede ser debido:
Prcticas no adecuadas de control de versiones
Falta de consideracin acerca del mbito o contexto de produccin final
Extensibilidad del error que fue corregido (fragilidad de la correccin)
O simplemente una consecuencia del rediseo de la aplicacin.
Otras definiciones
Llamamos prueba de regresin, porque tenemos que hacer nuevas pruebas donde se han
probado antes. Por lo general, este tipo de pruebas se realiza a travs de herramientas de
automatizacin de pruebas, pues muchas veces hay falta de tiempo para ejecutar casos de
prueba ya ejecutadas, as las pruebas de regresin se deja a un segundo plano. Sin embargo,
este es un grave defecto que los equipos estn poniendo. Las pruebas de regresin, a veces
se puede encontrar ms defectos que en la primera prueba, esto es debido a que el
tester puede tener ms familiaridad con el sistema y al volver a ejecutar los casos de prueba
es posible detectar otros tipos de defectos donde en la primera ejecucin fue inadvertido.
Para que las pruebas de regresin sean ejecutadas de manera rpida, es necesario que
el lder de calidad tenga ciencia de la necesidad de este tipo de prueba, para que
pueda planear la ejecucin de pruebas de regresin y haciendo un aumento del tiempo de la
actividad de la prueba.


24
El plan de casos de prueba de regresin puede ser de tres tipos:
Los casos de prueba que cubren toda la funcionalidad del sistema.
Los casos de prueba slo para las caractersticas que han sido modificados.
Nuevos casos de prueba para las caractersticas que se vieron
afectadas probablemente por el cambio.
Las pruebas de regresin es una forma efectiva de reducir la cantidad de defectos que se
pueden encontrar en un sistema.
3.2. Objetivo
El objetivo de las pruebas de regresin es eliminar el efecto onda, es decir, comprobar que
los cambios sobre un componente de un sistema de informacin, no introducen un
comportamiento no deseado o errores adicionales en otros componentes no modificados.
Cundo deben realizarse las Pruebas de Regresin?
No es suficiente probar slo los componentes modificados o aadidos, o las funciones que en
ellos se realizan, sino que tambin es necesario controlar que las modificaciones no
produzcan efectos negativos sobre el mismo u otros componentes.
Las Pruebas de Regresin pueden usarse no solo para probar la correccin de un programa,
sino a menudo usarse para rastrear la calidad de su salida. Por ejemplo en el diseo de
un compilador, las pruebas de regresin deben rastrear el tamao del cdigo, tiempo de
simulacin, y el tiempo de compilacin de las suites de prueba. Cuando quiera que aparezca
un nuevo build (constructor), el proceso de regresin aparece.
3.3. Tipos de Regresin
A. Clasificacin de mbito:
Local: Los cambios introducen nuevos errores.
Desenmascarada: Los cambios revelan errores previos.
Remota: Los cambios vinculan alguna otra parte del programa (mdulo) e int
roducen errores en ella.


25
B. Clasificacin temporal
Nueva caracterstica: Los cambios realizados con respecto a nuevas funcion
al idadesen la versin introducen errores en otras novedades en la misma
versin del software.
Caracterstica preexistente: Los cambios realizados con respecto a nuevas f
uncionalidades introducen errores en previas versiones
Cmo mitigar los riesgos?
Repeticin completa y habitual de la batera de pruebas.
Repeticin parcial basada en trazabilidad y anlisis de riesgos.
Pruebas de cliente o usuario:
a. Beta: Distribucin a clientes potenciales y actuales de versiones beta.
b. Pilot: Distribucin a un subconjunto bien definido y localizado.
c. Paralela: Simultaneando uso de ambos sistemas.
Parches de emergencia - estos parches se publican inmediatamente, y sern incluidos
en releases de mantenimiento futuras.


26
Captulo 4
Herramientas para
Implementar y Ejecutar
Pruebas Funcionales y de
Regresin

4.1. Automatizacin de Pruebas Funcionales
En la actualidad, verificar que el software funcione correctamente cumpliendo con las
necesidades del negocio ha dejado de ser suficiente. El testing debe ser efectivo encontrando
la mayor cantidad de errores pero tambin eficiente, ejecutando mayor cantidad de test en
menos tiempo, y con menores costos.
Es por ello que las actividades de automatizacin de pruebas estn cobrando relevancia
dentro de las reas de sistemas. La tarea que comnmente llamamos de automatizacin
consiste en aplicar tcnicas y herramientas diversas para ejecutar pruebas sin intervencin
humana (o con una mnima).
Es una actividad en principio costosa, pero que si se la ejecuta siguiendo un proceso definido
y controlado (con indicadores rigurosos), permite obtener grandes beneficios. Por el contrario,
si se inicia un proceso de automatizacin pensando en que va a hacer todo la herramienta,
no se obtendrn resultados favorables.
La automatizacin es una actividad humana y de desarrollo, por ms que el objetivo final sea
minimizar la intervencin humana en la ejecucin de parte de la prueba.

27
Pensando en esto, resulta claro que la automatizacin de pruebas funcionales no puede ser
implementada en todos los casos. Por el contrario es necesario tener un contexto claro que
nos permita aumentar la probabilidad de xito:
Aplicaciones en mantenimiento correctivo y/o evolutivo estables.
Un equipo de testing maduro.
Un alto grado de repetitividad en las pruebas a realizar.
La ecuacin costo/beneficio analizada.
Pero para qu automatizar las pruebas? En principio hay varias razones:
Para aumentar la periodicidad de las pruebas
Para aumentar la repetitividad y exhaustividad de las pruebas. Esto se logra
ampliando el alcance de las pruebas (ms combinaciones de datos, ms
variaciones de casos).
Para disminuir la cantidad de errores producto de realizar tareas repetitivas de
testing manual.
Para disminuir los tiempos de deteccin de errores y los tiempos de regresin
de cada paquete de software liberado.
Para reemplazar tareas repetitivas y montonas de ejecucin por tareas de
diseo de casos de prueba complejos (mejor aprovechamiento de los
recursos).
Para validar la testeabilidad de las aplicaciones antes de ingresarlas a testing (smoke testing).

4.2. Herramientas de Pruebas de Regresin y Funcionales
4.2.1. vTest
Es una herramienta de pruebas de regresin y funcionales automatizadas para las
aplicaciones web. vTest incorpora capacidades de presentacin de informes, reproduccin,
verificacin y registro. vTest es compatible con Microsoft Internet Explorer y Mozilla Firefox.

28
La aplicacin es compatible con todas las tecnologas de Internet populares como HTTP,
HTTPS/SSL, DHTML, JavaScript, ActiveX.
vTest tambin es compatible con todos los marcos importantes de aplicacin web como ASP,
ASP.NET, Java Servlets y JSP, PHP y CGI. vTest te permite grabar y probar toda tu aplicacin
en minutos simplemente apuntando y haciendo clic en la Aplicacin web.
Sin ninguna programacin, todos los objetos son capturados automticamente y grabados
como una secuencia grfica que muestra los pasos en tu secuencia de comandos en la forma
de un rbol basada en iconos. Para aquellos usuarios que deseen utilizar un lenguaje de
programacin, vTest utiliza JavaScript y proporciona una completa API de JavaScript que t
puedes utilizar para crear secuencias de comandos de pruebas personalizadas.
vTest crea secuencias de comandos que se adaptan muy bien cuando cambia la interfaz de
la aplicacin del usuario. La mayora de la competencia crea secuencias de comandos que
utilizan simplemente el nombre/ID del objeto para identificar un objeto en la aplicacin. vTest
utiliza un algoritmo sofisticado de identificacin de objetos para identificar objetos en tu
aplicacin. Esto permite que las secuencias de comandos puedan adaptarse muy bien a los
cambios de la interfaz de la aplicacin de un usuario.

Figura 11. Herramienta VTest


29
Caractersticas clave de "vTest":
Automatiza la tarea de pruebas de regresin y funcionales y por tanto reduce el tiempo
de entrega al mercado.
Mejora la eficiencia de los ingenieros de aseguramiento de la calidad permitindoles
dedicar menos tiempo a pruebas manuales y ms tiempo a pruebas de diseo.
Maximiza la fiabilidad y solidez mediante la capacidad de ejecutar pruebas bajo
demanda o de acuerdo con una programacin preestablecida sin necesidad de
intervencin del usuario.
No requiere un fondo de programacin. Para aquellos usuarios que deseen utilizar sus
habilidades de programacin, vTest utiliza el lenguaje estndar de programacin
JavaScript.
Gestiona de manera eficaz la evolucin del producto mediante la generacin de
pruebas que pueden ser modificadas fcilmente.
4.2.2. IBM Rational Functional Tester
Es una herramienta para la realizacin de pruebas funcionales y de regresin automatizadas.
Este software proporciona funciones de pruebas automatizadas para pruebas funcionales, de
regresin, de GUI y basadas en los datos. Rational Function Tester da soporte a diversas
aplicaciones, como aplicaciones basadas en web, .Net, Java, Siebel, SAP, basadas en
emulador de terminal, PowerBuilder, Ajax, Adobe Flex, Dojo Toolkit, GEF, documentos Adobe
PDF, zSeries, iSeries y pSeries
Entre las caractersticas ms resaltantes estn:
Esta herramienta de pruebas automatizada es la mejor de su clase para las pruebas
funcionales y la regresin de aplicaciones Java, Microsoft Visual Studio .NET y
basadas en Web.
Ofrece a los ejecutores de pruebas una seleccin de idiomas de script y un editor de
solidez Java en Eclipse o Microsoft Visual Basic .NET en Visual Studio .NET, para la
verificacin del montaje y la personalizacin.
Proporciona a los ejecutores de pruebas con poca experiencia funciones
automatizadas para actividades como, por ejemplo, la generacin de pruebas.

30
Incluye la tecnologa ScriptAssure y funciones de coincidencia de patrones para
mejorar la capacidad de recuperacin del script de verificacin dado los frecuentes
cambios que se producen en la interfaz del usuario de aplicaciones.
Incorpora soporte para el control de versiones para permitir un desarrollo paralelo de
los scripts de verificacin y el uso simultneo por parte de equipos distribuidos por el
mundo.
Permite la realizacin de pruebas de aplicaciones creadas con VS.NET Winforms,
J2SE/JEE, HTML/DHTML, XML, JavaScript y applets de Java e incluye soporte
exclusivo para la biblioteca SWT de Java asociada con Eclipse.
Soporta las pruebas de aplicaciones 3270 (zSeries) y 5250 (iSeries) que utilizan las
aplicaciones basadas en IBM Rational Functional Tester Extension for Terminal.

4.2.3. IBM Rational Robot
Robot es una herramienta orientada a objetos que permite la automatizacin de pruebas
funcionales del GUI de las aplicaciones, la creacin, modificacin y ejecucin de scripts de
pruebas funcionales y de regresin. Se utiliza adems para generar los scripts necesarios
para las pruebas de desempeo, simulando usuarios virtuales que interactan con los
servidores. Permite registrar y reportar el detalle de toda la informacin relacionada con el
proceso de prueba. Soporta mltiples tecnologas JavaT, Web y todo VS.NET controles de
formasOracle, aplicaciones Borland, Delphi y Sybase PowerBuilder
IBM Rational Robot automatiza las pruebas funcionales y de regresin para aplicaciones e-
commerce, cliente/servidor y ERP. Es usado para probar aplicaciones de una gran variedad
de interfaces de tecnologa.
Caractersticas principales:
Simplifica la configuracin de pruebas. IBM Rational Robot puede ser utilizado para
realizar pruebas distribuidas entre muchas mquinas, cada una configurada diferente.
Las mismas pruebas funcionales pueden ser ejecutadas simultneamente, acortando
el tiempo para identificar problemas con configuraciones especficas.
Prueba diferentes tipos de aplicaciones. IBM Rational Robot soporta un amplio
rango de ambientes y lenguajes, incluyendo HTML y DHTML, Java, VS.NET,

31
Microsoft Visual Basic y Visual C++, Oracle Developer/2000, PeopleSoft, Sybase
PowerBuilder y Borland Delphi.
Asegura la profundidad de las pruebas. Realiza desde pruebas de interfaces de
usuario en aplicaciones hasta pruebas de propiedades de los objetos de la aplicacin
como por ejemplo ActiveX Controls, OCXs, Java applets y muchos ms.
Pruebas de controles y objetos. IBM Rational Robot permite probar cada
componente de la aplicacin bajo una variedad de condiciones y provee casos de
prueba de mens, listas, caracteres, bitmaps y muchos ms.
Ayuda a analizar los problemas rpidamente. IBM Rational Robot automticamente
escribe los resultados en el Repositorio de Rational, y los pinta de colores para un
anlisis ms visual.
Permite el reuso. IBM Rational Robot asegura que un script, sin modificacin pueda
ser reusado para probar una aplicacin en ejecucin en Microsoft Windows XP,
Windows ME, Windows 2003, Windows 2000, Windows 98 o Windows NT.

Figura 12. Herramienta IBM Rational Robot

32
4.2.4. GXTest
GXtest es la solucin ideal para la automatizacin de pruebas funcionales de sistemas Web
desarrollados con GeneXus. Permite de manera sencilla automatizar casos de prueba que
luego evolucionan con la aplicacin en desarrollo, sin convertir el testing en un cuello de
botella a la hora de liberar el sistema al cliente.
GXtest disminuye la carga de tiempos, costos y esfuerzo, logrando que los casos de prueba
sean simples de ampliar, mantener y perpetuar, y al mismo tiempo, confirmar que el sistema
hace lo que los usuarios esperan que haga.
Realice automticamente pruebas de regresin planificadas en su sistema y asegrese de
liberar un producto con mejor calidad.

Key Features:
Record and playback
Data-driven testing
Construccin grfica de casos de prueba (sin necesidad de programar scripts)
Ejecucin del mismo caso de prueba sobre la aplicacin generada en
o Java, .NET o Ruby
o GeneXus 8, 9, X o Ev1
Ejecucin en Internet Explorer, Firefox
Reportes de resultados por e-mail
Planificacin (schedulling) de suites de pruebas
Ejecucin distribuida y paralela


33
4.2.5. JUnit
JUnit es un marco de trabajo de pruebas de regresin escrito por Erich Gamma y Kent Beck.
Es utilizado por los desarrolladores para implementar pruebas de unidad en java.
JUnit es un conjunto de clases (framework) que permite realizar la ejecucin de clases Java
de manera controlada, para poder evaluar si el funcionamiento de cada uno de los mtodos
de la clase se comporta como se espera. Es decir, en funcin de algn valor de entrada se
evala el valor de retorno esperado; si la clase cumple con la especificacin, entonces JUnit
devolver que el mtodo de la clase pas exitosamente la prueba; en caso de que el valor
esperado sea diferente al que regres el mtodo durante la ejecucin, JUnit devolver un fallo
en el mtodo correspondiente.
JUnit es tambin un medio de controlar las pruebas de regresin, necesarias cuando una
parte del cdigo ha sido modificado y se desea ver que el nuevo cdigo cumple con los
requerimientos anteriores y que no se ha alterado su funcionalidad despus de la nueva
modificacin.
El propio framework incluye formas de ver los resultados (runners) que pueden ser en modo
texto, grfico (AWT o Swing) o como tarea en Ant.
Existen varias razones para utilizar JUnit a la hora de hacer pruebas de cdigo:
La herramienta no tiene coste alguno, podremos descargarla directamente desde la Web
oficial.
Es una herramienta muy utilizada, por lo que no ser complicado buscar documentacin.
Existen varios plugins para poder utilizar con diferentes Entornos de Desarrollo Integrado
(IDE).
Existen tambin muchas herramientas de pruebas de cobertura que utilizaran como base
JUnit.
Con JUnit, ejecutar tests es tan fcil como compilar tu cdigo. El compilador "testea" la
sintaxis del cdigo y los tests "validan" la integridad del cdigo.
Los resultados son chequeados por la propia aplicacin y dar los resultados
inmediatamente.

34
Los tests JUnit se pueden organizar en suites, las que contendrn ejemplares de tests,
incluso podrn contener otras suites.
Utilizando los tests programados en JUnit, la estabilidad de nuestras aplicaciones mejorar
sustancialmente.
Los tests realizados se podrn presentar junto con el cdigo, para validar el trabajo realizado.

4.2.6. Selenium
Selenium es un set de herramientas que permiten desarrollar scripts para pruebas de
aplicaciones Web en diversos lenguages como Java, Ruby, Python, Perl, .Net o PHP. Es un
producto ofrecido como Open Source que est permanentemente siendo optimizado.
Componentes:
Selenium Core: Framework de ejecucin DHTML, desarrollado en JavaScript por la
ThoughtWorks. Los test, corren directamente en el servidor web de la aplicacin.
Contiene un lenguaje llamado Selenese.
Selenium IDE: esta implementado como un complemento de Firefox, permite grabar,
editar y depurar pruebas. El IDE genera el cdigo automticamente a gran variedad
de lenguajes y Frameworks de prueba.HTML Selenese, C#, Java, Perl, PHP, Python,
Ruby, JUnit, NUnit, RSpec.
Selenium Remote Control: Servidor, escrito en Java , que soporta comandos a travs
del browser via HTTP. Hace posible la ejecucin de test automticos para los lenguajes
soportados. Selenium provee drivers cliente para los lenguajes, funcionan de interface
para el servidor a travs del browser.

35

Figura 13. Herramienta Selenium
Selenium Grid: logramos ejecutar varias instancias del Remote Control de forma
paralela, en distintas maquinas.

Figura 14. Dinmica de Funcionamiento de La Herramienta Selenium
Ventajas:
Manejo centralizado.
Aceleracin de los tiempos de prueba.
Facilidad en pruebas simultaneas.

36
Captulo 5
Monitoreo de Resultados
El monitoreo de resultado tiene como un principal objetivo cambiar el comportamiento antes,
durante, y despus de la intervencin. Identifica que componentes funcionan como fue
previsto y cules no para mejorar la efectividad del programa o proyecto.

Figura 15.monitoreo de resultados
5.1. Evaluacin
La evaluacin es una actividad temporal que trata de determinar en forma sistemtica y
objetiva la pertinencia, rendimiento y xito de los programas y proyectos en curso y
terminados. A diferencia del monitoreo, que se debe llevar a cabo en todos los programas y
proyectos, las evaluaciones se realizan en forma ms selectiva, por razones prcticas. Los
administradores de programas o proyectos tienen flexibilidad para decidir por qu y cundo
es necesaria una evaluacin, teniendo en cuenta una serie de criterios.


37
5.2. Monitoreo
El monitoreo o seguimiento es un proceso de gestin moderna que consiste en el registro
ordenado de los avances de un programa o proyecto, de manera sistemtica, a fin de verificar
el avance en el cumplimiento de actividades, la obtencin de productos y el logro de objetivos
planificados, detectando las dificultades que pudieran presentarse para adoptar las medidas
necesarias para asegurar el xito del proyecto o programa.
El monitoreo es una forma de evaluacin o apreciacin, aunque a diferencia de la evaluacin
El monitoreo permite a los programas hacer lo siguiente:
Implementar medidas correctivas para poner a los programas nuevamente en curso
y que sean responsables de los resultados que se espera que el programa logre.
Determinar cmo deberan ser distribuidos los fondos en todas las actividades
programticas.
Recolectar informacin que puede usarse en el proceso de evaluacin.

5.3. Relacin entre Monitoreo y Evaluacin
El monitoreo y la evaluacin son realidades distintas pero estrechamente relacionadas. Se
prestan mutuo apoyo y son igualmente importantes. El monitoreo puede facilitar datos
cuantitativos y cualitativos, basados en la utilizacin de determinados indicadores, y tales
datos pueden utilizarse en las actividades de evaluacin.

5.4. Mecanismos de Monitoreo
El punto de partida del monitoreo es la planificacin, en la cual se precisan los indicadores y
las metas que permitirn medir el logro de cada objetivo propuesto, de acuerdo a los plazos
y recursos pre-definidos.
La teora de la planificacin del desarrollo define el seguimiento o monitoreo como un ejercicio
destinado a identificar de manera sistemtica la calidad del desempeo de un sistema,
subsistema o proceso a efecto de introducir los ajustes o cambios pertinentes y oportunos
para el logro de sus resultados y efectos en el entorno. As, el monitoreo permite analizar el
avance y proponer acciones a tomar para lograr los objetivos; Identificar los xitos o fracasos
reales o potenciales lo antes posible y hacer ajustes oportunos a la ejecucin. Con un

38
extendido consenso sobre la finalidad del monitoreo, como se define en el prrafo anterior, en
la actualidad existen dos tendencias sobre el significado y el alcance de los sistemas de
seguimiento o monitoreo. Una tendencia enfatiza la coincidencia entre lo planificado y lo
ocurrido. La otra en el conocimiento que se deriva de las acciones de seguimiento. La primera
tendencia descansa en una visin racional del proceso de planificacin. De este modo se
asume que dados ciertos insumos se obtendrn determinados resultados y efectos. En
correspondencia con esta tendencia, el acento del monitoreo es el anlisis sistemtico del
proceso de implementacin y el criterio de valoracin es la mayor o menor coincidencia entre
lo planificado y lo ocurrido. As, el foco de atencin es la verificacin si se ha cumplido lo
planificado y sugerir cambios para reducir la discrepancia entre uno y otro momento.
En la otra tendencia con el monitoreo se busca verificar la validez de una hiptesis,
retroalimentarla y consecuentemente tomar decisiones estratgicas y operativas
fundamentadas sobre una base emprica, y por tanto el monitoreo se traduce, en un proceso
de produccin y gestin de conocimientos empricos y en una fuente de aprendizaje que
contribuye a una mayor pertinencia y efectividad.
5.5. Elementos del Plan de Monitoreo
5.5.1. Plan o Enunciado
En esta parte se describe la racionalidad o el sentido que sustenta la iniciativa con
respecto a la realidad que se pretende modificar. Dicho sentido se expresa de manera
en que se articulan las actividades, los resultados, los objetivos y efectos buscados.
5.5.2. Esquema o Indicadores
Cada objetivo, resultado o producto son medidos por una serie de indicadores con sus
valores respectivos (unidades de medida), los responsables y las fuentes para la
recopilacin de los datos sobre el desempeo. Algunas veces los valores de los
indicadores estn desagregados en aspectos ms especficos. Por ejemplo: en el
indicador Nmero de alumnos promovidos, puede interesar desagregarlos en: i)
regin del pas; ii) nio o nia; iii) poblacin indgena o no indgena.


39
5.5.3. Esquema de Metas durante el Periodo
Este componente permite identificar el comportamiento de los indicadores durante un
determinado perodo de tiempo a definir (trimestral, semestral, anual etc.). Los
indicadores pueden medirse o cotejarse con referencia al pasado respecto a los
valores de la Lnea de Base, o bien a futuro, con respecto a las metas definidas para
el ciclo de tiempo definido.

Figura 16. Metas Durante el Periodo


40
Conclusiones
Probar es buscarle los fallos a un programa.
La fase de pruebas requiere un gran porcentaje de los recursos humanos y econmicos del
desarrollo de software. Adems, se muestra renuente a un tratamiento matemtico
o, simplemente, automatizado.
Su ejecucin se basa en metodologa (reglas que se les dan a los encargados de probar)
que se va desarrollando con la experiencia. Es tediosa, es un arte, es un trabajo que
requiere una buena dosis de mala intencin, y provoca difciles reacciones humanas.
Aunque se han desarrollado miles de herramientas de soporte de esta fase, todas
han limitado su xito a entornos muy concretos, frecuentemente slo sirviendo para el
producto para el que se desarrollaron. Slo herramientas muy generales como
analizadores de complejidad, sistemas de ejecucin simblica y medidores de
cobertura han mostrado su utilidad en un marco ms amplio. Pero al final sigue
siendo imprescindible un artista humano que sepa manejarlas.
El objetivo de las pruebas funcionales es demostrar que el sistema cumple con las funciones
especficas para las que fue creada
El monitoreo es el seguimiento rutinario de la informacin prioritaria de un programa, su
progreso, sus actividades y sus resultados. El monitoreo procura responder la pregunta
qu estamos haciendo?.
El Tiempo que ahorramos en la ejecucin de pruebas nos sirva para un mejor Diseo de los
Casos de Pruebas.
Este Tema ha sido tratado con el fin de orientarnos como realizar el manejo de la Fase de
pruebas y conocer que funcin cumple en el desarrollo de software.


41
Bibliografa

http://www.calidadysoftware.com/testing/pruebas_funcionales.php
http://es.wikipedia.org/wiki/Pruebas_funcionales
http://es.wikipedia.org/wiki/Caso_de_uso
http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf
http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf
http://es.wikipedia.org/wiki/Historias_de_usuario
http://blog.netcom.mx/?p=25
http://aegxxi-desarrollo.blogspot.com/2012/06/historias-de-usuario-vs-casos-
de-uso.html
http://ldc.usb.ve/~martinez/cursos/ci3715/clase11_AJ2010.pdf
http://www.greensqa.com/portal/index.php/soluciones/calidad-de-
productos/50-pruebas-funcionales-de-software
http://www.inf.ucv.cl/~bcrawford/AULA_ICI444/Pruebas.pdf
http://www.softqanetwork.com/pruebas-de-regresion
http://es.scribd.com/doc/50756477/Pruebas-de-regresion
http://gtsw-es.blogspot.com/2012/01/la-importancia-de-las-pruebas-de.html
http://prezi.com/zijdoejlghjb/copy-of-pruebas-del-sistema-i/
http://www.oei.es/idie/mONITOREOEINDICADORES.pdf
http://www.endvawnow.org/es/articles/340-tipos-de-evaluacion-monitoreo-
resultado-e-impacto.html

Pruebas de Sistema I

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pruebas de Sistema I

Cargado por

Copyright:

Formatos disponibles

aaaaa

Universidad Nacional San Luis Gonzaga de Ica

También podría gustarte