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

Introducción......................................................................................................................2

Automatización de Pruebas de Software.........................................................................3

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

Objetivo, problemas que resuelve..............................................................................5

En que fases del proceso de desarrollo de software es útil........................................6

Tipos de prueba..........................................................................................................8

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

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

Mejores prácticas y recomendaciones......................................................................16

Conclusión......................................................................................................................18

Referencias Bibliográficas..............................................................................................19

1

Introducción

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.

2

Automatización de Pruebas de Software

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.

3

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

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.

4

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

5

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

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

6

Modelo en V del ciclo de vida

 

Método de pruebas de sistemas

7

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.

8

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

9

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.

10

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.

11

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.

12

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

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.

13

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

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

14

lenguaje de programación de la herramienta de automatización. El no tomar al proyecto

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.

15

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.

16

Asegurar recursos: reservar el tiempo de la prueba.

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.

17

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.

18

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_Informatica/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/

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

19