REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR

UNIVERSIDAD ALEJANDRO DE HUMBOLDT
CARACAS – DISTRITO CAPITAL
CÀTEDRA: Ingeniería Del Software.

Caracas, Julio 2010

 Índice
Índice................................................................................................................................................................................2
Introducción.....................................................................................................................................................................2
Automatización de Pruebas de Software........................................................................................................................3
Definición de Software Testing (Pruebas de Software):..........................................................................................4
Parasoft SOAtest: Web Orientación Legal herramienta de prueba de servicios de Parasoft. Creación automática de
pruebas de WSDL, WSIL, UDDI y tráfico HTTP. Las capacidades incluyen la validación WSDL, carga y pruebas
de rendimiento; modelo de gráfica y prueba de escenarios complejos. Crea automáticamente pruebas de seguridad
de penetración de las inyecciones SQL, inyecciones de XPath, fuzzing parámetro, bombas de XML, y entidades
externas. prueba por datos a través de fuentes de datos tales como Excel, CSV, consultas DB, etc Apoyo a JMS,
soporte MIME archivo adjunto..................................................................................................................................13
Otros frameworks de persistencia:.............................................................................................................................13
Maven y Embedded JBoss sobre Java 6....................................................................................................................13
HttpUnit: Pruebas de conectividad y cliente.Emula un web browser . Necesita un web server para
funcionar.Sitio: http://httpunit.sourceforge.net/ ....................................................................................................14
Conclusión.....................................................................................................................................................................19
Referencias Bibliográficas.............................................................................................................................................20

Introducción

2
 La Industria de Pruebas de Software ha venido evolucionando rápidamente en
estos últimos años tanto en madurez de negocio, como en profesionalismo y
metodología

Esta madurez ha llevado a la industria de pruebas a ser eficaz pero ahora el reto
se presenta en el tema de la eficiencia, dado el aumento de la complejidad y de las
necesidades de rapidez en la producción de aplicativos de software. Es por eso que el
tema de automatización de pruebas viene tomando fuerza en las empresas que tienen
un proceso de pruebas formalmente implementado.

La problemática actual con respecto a la Automatización de Pruebas radica en la

complejidad, tiempo y costos tanto de la implementación como del mantenimiento, que
la han convertido en un tema difícil de afrontar.

Las pruebas automatizadas son efectivas en entornos donde los cambios son
frecuentes o en aplicaciones en las que se esperan builds y releases críticos.

Existe una gran variedad de herramientas automatizadas de pruebas y

frameworks disponibles. Esto junto con las nuevas metodologías en desarrollo de
aplicaciones, han creado un reto a la hora de diseñar frameworks de pruebas que sean
mantenibles y suites de pruebas destinadas a regresión.

Es por ello que es necesario destinar la automatización de pruebas a un equipo

con experiencia en el sector.

Automatización de Pruebas de Software

3
 En la cadena de valor del desarrollo de un software específico, el proceso de
prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad,
escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien
desarrollado. Las aplicaciones de software han crecido en complejidad y tamaño, y por
consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo
construido de modo de minimizar el costo de su reparación. Mientras antes se detecte
una falla, más barata es su corrección.

El proceso de prueba es un proceso técnico especializado de investigación que

requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y
técnicas de pruebas y herramientas especializadas.

Definición de Software Testing (Pruebas de Software):

Proceso realizado concurrentemente a través de las diferentes etapas de
desarrollo de software que utiliza y mantiene el testware y cuyo objetivo es apoyar la
disminución del riesgo de aparición de fallas y faltas en operación.

• Automatización de pruebas es una de las inversiones que ha producido los

mejores y más satisfactorios resultados.
• Inversión a medio-largo plazo
• Única actividad que nos proporciona una estimación real de la calidad de nuestra
aplicación.
• Sí, el producto está preparado para salir.
• Desarrollo iterativo: probar en cada iteración, cada vez que se realiza un cambio.
• Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un
error no encontrado hasta entonces.
• Una prueba tiene éxito si descubre un error no detectado hasta entonces.
• No sólo se prueba el código: documentación y ayuda.

Las pruebas de software de automatización es una herramienta que garantiza

4
el desarrollo de productos de calidad. Las empresas son capaces de ejecutar varias de
estas pruebas con menos recursos en menor tiempo. En efecto, la reducción de los
recursos utilizados daría lugar a un costo reducido, que es muy beneficioso para
cualquier negocio. Así, utilizando este tipo de pruebas se ha convertido en una medida
prudente por empresas dedicadas al desarrollo de software.

Hay muchas ventajas de la utilización de pruebas automatizadas. Entre ellas se

encuentra que es un sistema confiable. La prueba automatizada ha sido considerada
una de las maneras más confiable para asegurar la calidad del software. Este tipo de
pruebas se utilizan para minimizar la intervención manual en el proceso, reduciendo así
los posibles errores cometidos por los humanos. En este enfoque, las pruebas de
ejecutar el mismo procedimiento en la forma exactamente las mismas cada vez que se
llevan a cabo. Debido a esta forma exacta, eliminando los errores humanos se convierte
en lo siguiente.

Pruebas automatizadas son repetibles - otro citado por los ingenieros de

software. Estos les permiten saber cómo un programa de software específico responde
cuando los mismos procedimientos que se realizan repetidamente. Del mismo modo,
las pruebas automatizadas son programables. Esto significa que los desarrolladores
pueden configurar complejos exámenes, que pueden revelar datos ocultos desde el
propio programa.

5
Objetivo, problemas que resuelve:

El proceso de Pruebas de Software (Software Testing) tiene como objetivo

apoyar la disminución de los efectos de faltas y fallas en operación al detectarlas y
gestionarlas formalmente concurrentemente a todas las etapas de desarrollo del
software.
Mejorar la calidad de software como un todo y hacer su validación, desde el
punto de vista de los clientes y usuarios, siendo un aspecto fundamental en el proceso
de desarrollo de software. Cuando se utiliza el desarrollo iterativo e incremental o
cuando lidiamos con software con un largo tiempo de vida, es todavía más importante
validar el producto de forma ágil y con un mínimo de etapas repetitivas manuales.

Podríamos enumerar sus objetivos de la siguiente manera:

1. Mejora la calidad del producto.

2. Disminuir el tiempo de salida al mercado.
3. Detección de errores con anticipación.
4. Fomentar al equipo de desarrollo a realizar y ejecutar pruebas de manera
continua.
5. Reducción de Costos

En que fases del proceso de desarrollo de software es útil:

Se prueba a través de todo el proceso de desarrollo, pero en el caso de pruebas
automatizadas el software de prueba se utiliza la fase de pruebas del desarrollo de
software específicamente.

Se observa la importancia de verificar cada uno de los productos que se van

construyendo, bajo la asunción de que si lo que se va construyendo es todo ello
correcto, también lo será el producto final. Igualmente, se observa que el proceso de
Validación resalta la importancia de comprobar el cumplimiento de los objetivos de los
requisitos y del sistema final, de suerte que podría construirse un Plan de pruebas de

6
aceptación desde el momento mismo de tener los requisitos, que sería comprobado al
finalizar el proyecto.

Si tras la fase de requisitos viniese una segunda de diseño a alto nivel del
sistema, también podría prepararse un Plan de pruebas de integración, que sería
comprobado tras tener codificados los diferentes módulos del sistema.
Esta correspondencia entre fases del desarrollo y tipos de pruebas produce el
llamado “modelo en V”.

Modelo en V del ciclo de vida

7
Método de pruebas de sistemas

8
Tipos de prueba:
• En función de qué conocemos:
o Pruebas de caja negra: no conocemos la implementación del código, sólo la
interfaz. Tan sólo podemos probar dando distintos valores a las entradas y
salidas.

9
 o Pruebas de caja blanca: conocemos el código (la implementación de éste)
que se va a ejecutar y podemos definir las pruebas que cubran todos los
posibles caminos del código.
• Según el grado de automatización:
o Pruebas manuales: son las que se hacen normalmente al programar o las
que ejecuta una persona con la documentación generada durante la
codificación (P. ej.- comprobar cómo se visualiza el contenido de una página
web en dos navegadores diferentes).
o Pruebas automáticas: se usa un determinado software para sistematizar las
pruebas y obtener los resultados de las mismas (P. ej.- verificar un método de
ordenación).
• En función de qué se prueba:
o Pruebas unitarias: se aplican a un componente del software. Podemos
considerar como componente (elemento indivisible) a una función, una clase,
una librería, etc. En nuestro caso, generalmente hablaremos de una clase
como componente de software.
o Pruebas de integración: consiste en construir el sistema a partir de los
distintos componentes y probarlo con todos integrados. Estas pruebas deven
realizarse progresivamente.
o Pruebas de regresión: son aquellas pruebas cuyo objetivo es comprobar por
qué ha dejado de funcionar algo que ya funcionaba. El objetivo de las
pruebas de regresión es no tener que “volver atrás”.
o Pruebas funcionales: sobre el sistema funcionando se comprueba que
cumple con la especificación (normalmente a través de los casos de uso).
o Pruebas de rendimiento o stress: los tres primeros tipos de pruebas de los
que ya se ha hablado comprueban la eficacia del sistema. Las pruebas de
rendimiento se basan en comprobar que el sistema puede soportar el
volumen de carga definido en la especificación, es decir, hay que comprobar
la eficiencia (P. ej.- Se ha montado una página web sobre un servidor y hay
que probar qué capacidad tiene estado de aceptar peticiones).

10
o Pruebas de Seguridad: se determinan los niveles de permiso de usuarios,
las operaciones de acceso al sistema y acceso a datos.
o Pruebas de Usabilidad: se determina la calidad de la experiencia de un
usuario en la forma en la que éste interactúa con el sistema, se considera la
facilidad de uso y el grado de satisfacción del usuario.
o Pruebas de Validación: Son las pruebas realizadas sobre un software
completamente integrado para evaluar el cumplimiento con los requisitos
especificados.
o Pruebas de aceptación: son las únicas pruebas que son realizadas por los
usuarios, todas las anteriores las lleva a cabo el equipo de desarrollo.
Podemos distinguir entre dos pruebas:
 Pruebas alfa: las realiza el usuario en presencia de personal de
desarrollo del proyecto haciendo uso de una máquina preparada para
tal fin.
 Pruebas beta: las realiza el usuario después de que el equipo de
desarrollo les entregue una versión casi definitiva del producto.

11
 Herramientas y/o framework para automatizar pruebas por capas:

A. componentes de persistencia (con ejemplos):

DBUnit: El código abierto de extensión de JUnit (también se puede usar con

Ant) específicamente dirigido a proyectos de bases de datos que, entre otras cosas,
pone una base de datos en un estado conocido entre las corridas de prueba. Permite
evitar los problemas que pueden ocurrir cuando un caso de prueba corrompe la base
de datos y hace que las pruebas posteriores para fallar o agravar el daño. Tiene la
capacidad de exportar e importar datos de base de datos desde y hacia bases de
datos XML. Puede trabajar con conjuntos de datos muy grandes cuando se utiliza en
modo de transmisión, y puede ayudar a verificar que los datos de base de datos
coincide espera conjuntos de valores.

12
 Parasoft SOAtest: Web Orientación Legal herramienta de prueba de
servicios de Parasoft. Creación automática de pruebas de WSDL, WSIL, UDDI y
tráfico HTTP. Las capacidades incluyen la validación WSDL, carga y pruebas de
rendimiento; modelo de gráfica y prueba de escenarios complejos. Crea
automáticamente pruebas de seguridad de penetración de las inyecciones SQL,
inyecciones de XPath, fuzzing parámetro, bombas de XML, y entidades externas.
prueba por datos a través de fuentes de datos tales como Excel, CSV, consultas
DB, etc Apoyo a JMS, soporte MIME archivo adjunto

Otros frameworks de persistencia:

Maven y Embedded JBoss sobre Java 6.

B. componentes de interfaz de usuario (con ejemplos):

JUnitPerf: Permite las pruebas de rendimiento de forma dinámica añadido a las

actuales pruebas JUnit. Permite la rápida composición de una serie de pruebas de
rendimiento, que se puede ejecutar de forma automática e independiente de pruebas
JUnit otros. Diseñado para usarse donde hay rendimiento / requisitos de escalabilidad
que necesitan verificar de nuevo código mientras refactorización. Por Mike Clark
Consultoría / Clarkware, licenciado bajo la licencia BSD.

Abad Java GUI Test Marco: Marco de realizar el ensayo por Timothy pared
proporciona una generación automática de eventos y la validación de componentes GUI
de Java, mejorando las funciones más básicas que proporciona la clase java.awt.Robot.
(Abad = "A Better 'Bot'). El marco puede ser invocada directamente desde el código
Java o accede sin necesidad de programación mediante el uso de secuencias de
comandos a través de" Costello ", un editor de scripts / grabador. Adecuado tanto para
uso por desarrolladores para pruebas unitarias y garantía de calidad para pruebas
funcionales. gratuito - bajo la GNU Licencia Pública General.

JUnit: Marco para escribir pruebas unitarias java repetible - un framework de

13
pruebas de regresión escrito por Erich Gamma y Kent Beck. Para su uso por los
desarrolladores de la aplicación de las pruebas unitarias en Java. Libre Open Source
Software liberado bajo la Licencia Pública de IBM y alojado en SourceForge. El sitio
incluye una gran colección de extensiones y la documentación.

Nunit:
Framework de pruebas unitarias para la plataforma .NET. Es una herramienta de
código abierto.También está basado en xUnit. Dispone de diversas expansiones como
Nunit.Forms o Nunit.ASP.

Httpunit:
Pruebas de capa de presentación. Escrito en Java. Emula en forma simplificada
un Java web sever. Sitio: http://httpunit.sourceforge.net/doc/servletunit-intro.html

C. componentes de servicios (con ejemplos):

HttpUnit: Pruebas de conectividad y cliente.Emula un web browser . Necesita un
web server para funcionar.Sitio: http://httpunit.sourceforge.net/

WebInject: es una herramienta gratuita para pruebas automatizadas de

aplicaciones web y servicios web. It can be used to test individual system components
that have HTTP interfaces (JSP, ASP, CGI, PHP, AJAX, Servlets, HTML Forms,
XML/SOAP Web Services, REST, etc), and can be used as a test harness to create a
suite of [HTTP level] automated functional, acceptance, and regression tests. Puede ser
utilizado para probar los componentes del sistema individual que tienen interfaces
HTTP (JSP, ASP, CGI, PHP, AJAX, Servlets, HTML Forms, XML / SOAP Web Services,
REST, etc), y puede ser utilizado como un arnés de prueba para crear un conjunto de
nivel [HTTP] automatizado funcionales, la aceptación y pruebas de regresión.

SoapUI: Una aplicación gratuita de escritorio abierta fuente de Eviware Software

14
AB para inspeccionar, invocando, desarrollo, simulación / burla y funcional / carga /
pruebas de conformidad de los servicios web a través de HTTP. Está dirigido,
principalmente a los desarrolladores / probadores de mediación y / o consumo de
servicios Web (Java, Net, etc). Simulacro de servicios Web se pueden crear para
cualquier WSDL y alojado dentro de soapUI o utilizando el corredor MockService de
línea de comandos. IDE-plugins disponibles para Eclipse, IntelliJ IDEA, NetBeans y una
especializada eclipse-plugin para JBossWS. versión profesional "pagado" disponibles
con apoyo profesional y la funcionalidad extendida.

SOAPscope Server: Web herramienta de prueba de los servicios Mindreef Inc.

Software / Progreso, para crear escenarios de prueba de forma automática mediante el
registro de acciones; compartirlos con otros probadores de colaboración en el servidor
baaed interfaz de usuario. Ver los mensajes SOAP y WSDL en Pseudocódigo ViewTM.
Crear pruebas complejas incluyendo la aprobación de los valores de una respuesta a
las solicitudes posteriores, realizar pruebas por lotes y validar los resultados de todos
sin necesidad de programación. Simular servicios web que aún no existen, o nuevos
escenarios para los que lo hacen.

LISA para Servicios Web / SOAP: Servicios Web / SOAP herramienta de

prueba de iTKO, Inc. Ninguna de código SOAP / XML y las pruebas de exploración
WSDL y prueba de mantenimiento, y apoya las sesiones activas, SSL, autenticación y
cadenas de magia. Funciona con cualquier cliente y soporte Java y NET. Y cualquier
otro servicio web SOAP compatibles.

Factores críticos de éxito para una implantación:

Contar con personal con experiencia en desarrollo. Un factor crítico en la

implementación de un marco de pruebas es, tener la participación en el equipo de
trabajo de recursos humanos con habilidades de desarrollo, preferentemente en el
lenguaje de programación de la herramienta de automatización. El no tomar al proyecto

15
de automatización como un proyecto de desarrollo, es uno de los errores más graves
que se comete al encarar una implementación de este estilo; debido a que una mala
arquitectura en el desarrollo del marco de pruebas, no permitirá el éxito del proyecto.

Pensar que con la automatización se descartarán las pruebas manuales. Muchas

organizaciones piensan que luego de la finalización de este proyecto, prescindirán de
los probadores manuales, y entonces no prevén contrataciones para el área de
pruebas.
Existen tipos de pruebas en las cuales la automatización no es una técnica
factible. (Ejemplo: ver si la barrera de una caseta se levanta al emitir el ticket). Incluso
en aquellas pruebas que pueden automatizarse, es conveniente que en una etapa
inicial del desarrollo, se efectúen manualmente.

Hay muchos factores responsables de la implantación exitosa de un marco para

la automatización de pruebas. Los elementos clave son:

• Compromiso: La gestión debe participar activamente en la prueba de

elaboración del marco de la automatización.
• Costos y presupuesto: la construcción de un marco para la presupuestación de
las necesidades de pruebas automatizadas. Convencimiento de la gerencia, es
un proceso de cultura y tiene costos inherentes de implantación.
• Proceso: El proceso debe estar bien definido, sin ad-hoc de pruebas y
orientación definida para la prueba, la cobertura de prueba y criterios de prueba
para cada paso.
• Recursos relacionados: Para garantizar que la automatización del desarrollo
Marco va bien, debería haber un equipo dedicado.
• Realistas: La gestión debe ser realista y pruebas automáticas 100% no es
posible y que todas las pruebas no pueden ser automatizados. Proporcionará
resultados después de varios ciclos se llevó a cabo y no hay retorno inmediato
de la inversión para la construcción de las pruebas de automatización Marco.

16
 • El Recurso Humano: se ha de contar con un excelente equipo de Ingenieros de
prueba, a fin que garanticen la exactitud de los resultados arrojados por el
software de automatización de pruebas. Habilidades del equipo de pruebas.

• Buena metodología de pruebas y disciplina de implantación.

Mejores prácticas y recomendaciones:

Las recomendaciones para unas pruebas exitosas son las siguientes:

• 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.
Además, es normal que las situaciones que olvidó considerar al crear el
programa queden de nuevo olvidados al crear los casos de prueba.
• Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder
descubrir posibles síntomas de defectos.
• Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y
esperados como no válidos e inesperados.
• Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo):
o Probar si el software no hace lo que debe hacer
o Probar si el software hace lo que debe hacer, es decir, si provoca efectos
secundarios adversos
• Se deben evitar los casos desechables, es decir, los no documentados, ni
diseñados con cuidado. Ya que suele ser necesario probar muchas veces el
software y por tanto hay que tener claro qué funciona y qué no.
• No deben hacerse planes de prueba suponiendo que, prácticamente, no hay
defectos en los programas y, por lo tanto, dedicando pocos recursos a las
pruebas, siempre hay defectos.
• Asegurar recursos: reservar el tiempo de la prueba.

17
 • Sobrepasar la confianza inicial y los supuestos que tenemos sobre el producto:
profundizar el análisis para obtener información que no teníamos.
• Si el ciclo es iterativo realizar la prueba en todas las iteraciones (si no la
ejecución, el diseño de la prueba)
• Tratar el diseño de la prueba como una actividad preventiva.
• Pensar en el volumen de los artefactos de prueba (cientos o miles de casos y
defectos) para elegir herramientas adecuadas.
• No intentar automatizar toda la prueba.

En resumen, las siguientes son las recomendaciones de buenas prácticas para la

prueba manual de software para tener éxito: ser sistemático en el diseño y
documentación de pruebas, pruebas de llave en mano, automatizar, administrar bien las
pruebas, los casos de prueba de rango, e invertir en las pruebas.

18
 Conclusión

Cualquier desarrollador con experiencia en el desarrollo de aplicaciones conoce

de sobra el esfuerzo que supone probar correctamente la aplicación. Crear casos de
prueba, ejecutarlos y analizar sus resultados es una tarea tediosa. Además, es habitual
que los requisitos de la aplicación varíen constantemente, con el consiguiente aumento
del número de versiones de la aplicación y la refactorización continua del código. En
este contexto, es muy probable que aparezcan nuevos errores.

Este es el motivo por el que la automatización de pruebas es una

recomendación, aunque no una obligación, útil para crear un entorno de desarrollo
satisfactorio. Los conjuntos de casos de prueba garantizan que la aplicación hace lo
que se supone que debe hacer. Incluso cuando el código interno de la aplicación
cambia constantemente, las pruebas automatizadas permiten garantizar que los
cambios no introducen incompatibilidades en el funcionamiento de la aplicación.
Además, este tipo de pruebas obligan a los programadores a crear pruebas en un
formato estandarizado y muy rígido que pueda ser procesado por un framework de
pruebas.

Fiabilidad, repetibilidad, programabilidad, velocidad y eficacia de costes son los

beneficios pocos se podría obtener en la prueba de la automatización del software.
Aunque existen algunas desventajas de utilizar este proceso como la dificultad de
mantener los archivos de datos de prueba y requiere competencia extrema en la
secuencia de comandos de prueba, se adapta ampliamente en la industria de software
en todo el mundo.

19
 Referencias Bibliográficas

Fuentes online Consultadas:

• http://iseriesvenezuela.blogspot.com/2010/02/tips-para-la-prueba-de-
software.html
• http://www.acis.org.co/fileadmin/Base_de_Conocimiento/XXVII_Salon_Info
rmatica/MariaClaraChoucair-PruebasDeSoftware.pdf
• http://www.e-quallity.net/definiciones.php
• http://alarcos.inf-cr.uclm.es/doc/masi/doc/lec/parte5/polo-apuntesp5.pdf
• http://www.sistedes.es/TJISBD/Vol-1/No-4/articles/pris-07-raja-ctps.pdf
• http://www.programania.net/diseno-de-software/tipos-de-pruebas-
automatizadas-de-software/
• http://www.lsi.us.es/~javierj/cursos_ficheros/02.SR.pdf
• http://athenea.ort.edu.uy/publicaciones/ingsoft/ortsf/areas/IntroduccionPru
eba.pdf
• http://www.worldlingo.com/ma/enwiki/es/Test_automation
• http://www.dosideas.com/wiki/JMeter
• http://isg2.pbworks.com/Pruebas+del+Software
• http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?
pagina=pruebasjwebunit
• http://materias.fi.uba.ar/7548/PruebasSoftware.pdf
• http://materias.fi.uba.ar/7572/zips/Pruebas%20de%20Software.pdf
• http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?
pagina=embeddedJBossPersistenceTests
• http://www.softwareqatest.com/qatweb1.html

20