Cap3 - Pruebas de Regresión: Tales criterios dan un filtro que se puede distribuir a todos los testers para que
s dan un filtro que se puede distribuir a todos los testers para que puedan
Las pruebas de regresión no es un nivel de pruebas, es la repetición de pruebas de software
que se produce cuando se realizan cambios para asegurar que la nueva versión del software
ha conservado la capacidad de la versión anterior y que no se han introducido nuevos
defectos debido a los cambios, estos pueden ocurrir en cualquier nivel de la prueba, por
ejemplo, cuando las pruebas de unidad son ejecutadas la unidad puede pasar un número
de estas pruebas hasta que una de las pruebas revele un defecto. La unidad es reparada y
luego vuelto a analizar con todos los casos de prueba antiguos para asegurar que los
cambios no han afectado a su funcionalidad.
Hay 2 partes de un sistema de prueba de regresión:
 Establecen que las características probadas en la última versión aún están
presentes. Así se ejecutan las pruebas menos la primera versión.
 Establecen que no se producen pérdidas de memoria. Las pérdidas de memoria
son una causa importante de retraso, ya que son difíciles de encontrar. Es útil, por
tanto, ejecutar las pruebas del sistema de regresión en paralelo con las pruebas
del sistema normales.
Las pruebas del sistema deben producir un producto clave llamado el conjunto de pruebas
de regresión del sistema, que es el conjunto de datos de casos de prueba diseñados para
ejercer un sistema sobre la mayor parte o la totalidad de sus características, Su objetivo es
apoyar la repetición de pruebas cuando se realizan cambios en el sistema.
Comenzar a identificar los criterios para las pruebas de regresión durante el tiempo de
especificación de requerimientos. Estos incluirán:
 ¿Qué características estarán disponibles a partir de la versión 1?
 ¿Cuáles serán los principales requerimientos incorporados en cada versión?
 ¿Cuál será la forma más común en el que se utilizará el sistema?
 ¿Cuáles son los requerimientos más importantes? (¿Por qué? ¿Es evidente por sí
mismo su importancia o tiene más que ver con la política del cliente?).
 ¿Qué requerimientos son críticos en el tiempo?
 ¿Qué requerimientos son críticos de usabilidad?
 ¿Qué pruebas son los más fáciles de ejecutar, y la más indicada?
 ¿Qué características son las más críticas en los ingresos del cliente?
marcar los posibles requerimientos y por lo tanto las pruebas de interés. A medida que
progresa la prueba puede añadir los siguientes criterios:
 ¿Qué características han contenido el mayor número de bugs?
 ¿En qué pruebas se han encontrado el mayor número de bugs?
 ¿Qué acciones del operador han encontrado el mayor número de bugs?
1. Identificación y Priorización de Pruebas de Regresión:
Las pruebas de regresión tienen que responder a la pregunta "tiene algo roto desde la última
versión". Esto requiere que las pruebas de regresión se prioricen de manera que los bugs
que se han encontrado históricamente respecto a la mayoría de bugs se ejecutan primero.
Hay dos soluciones a esto:
 Asegurar que cada bug que expone una prueba se encuentre en la lista de esa
prueba de tal manera que se ejecuten sólo aquellas pruebas que han encontrado
bugs.
 Asegurarse de que los títulos de todos los bugs estén construidos de tal manera
que se puedan utilizar para determinar qué operador u otras acciones son más
propensas a presentar errores.
Otros enfoques para el establecimiento de prioridades incluyen:
 Características Principales: Primero las pruebas de las características clave (es el
método más común para la regresión de pruebas ya que si falta un elemento clave
de la versión será rechazado).
 Cambios: Pruebas de cambios de las primeras funciones.
 Tiempo Transcurrido desde la última ejecución: Suponiendo que las ejecuciones
de la prueba del sistema no ejecutan todas las pruebas preparadas.
 Riesgo: Asignado a la función en una sesión de evaluación de riesgos.
2. Importancia de las Pruebas de Regresión:
Se realizan generalmente después de la corrección de un defecto o después de la adición de
nuevas funcionalidades.
Su objetivo es asegurar que ningún defecto se añadió al sistema después de la modificación.
No sirve para nada hacer pruebas en un sistema, pero después de modificaciones no hacer
de nuevo las mismas pruebas, eso no va asegurar que el sistema no tiene defectos.
Las pruebas de regresión, a veces se puede encontrar más defectos que en la primera
prueba, esto es debido al tester al tener más familiaridad con el sistema y al volver a ejecutar
los casos de prueba es posible detectar otros tipos de defectos donde en la primera
ejecución fue inadvertida.
El plan de casos de prueba de regresión puede ser de tres tipos:
 Los casos de prueba que cubren toda la funcionalidad del sistema.
 Los casos de prueba sólo para las características que han sido modificados.
 Nuevos casos de prueba para las características que se vieron afectadas
probablemente por el cambio.
Las pruebas de regresión son una forma efectiva de reducir la cantidad de defectos que se
pueden encontrar en un sistema.
Cap4 – Herramientas para Implementar y Ejecutar Pruebas Funcionales y de Regresión:
Actualmente el número de herramientas para pruebas de software disponibles, tanto en el
mercado como de manera gratuita (herramientas de código abierto), es muy amplio.
1. Herramientas Open Source para Pruebas Funcionales:
Selenium: Es un conjunto de utilidades que facilita la labor de obtener juegos de pruebas
para aplicaciones web. Para ello nos permite grabar, editar y depurar casos de prueba, que
podrán ser ejecutados de forma automática e iterativa posteriormente.
Además de ser una herramienta para registrar acciones, permite editarlas manualmente o
crearlas desde cero.
Características:
 Facilidad de registro y ejecución de los test.
 Referencia a objetos DOM en base al ID, nombre o a través de XPath.
 Auto-completado para todos los comandos.
 Las acciones pueden ser ejecutadas paso a paso.
 Herramientas de depuración y puntos de ruptura (breakpoints).
 Los test pueden ser almacenados en diferentes formatos.
Recursos Necesarios: Los navegadores más compatibles con Selenium son:
 Explorer.
 Mozilla Firefox.
 Google Chrome.
 Safari.
Componentes: Los componentes de Selenium que son necesarias para la grabación y
ejecución de las pruebas son:
 SELENIUM client: cliente de SELENIUM, necesario para crear pruebas JUnit con
SELENIUM.
 SELENIUM IDE: plugin de Firefox para la grabación de las pruebas, paso a paso.
 SELENIUM Server: servidor de SELENIUM, que es el que realiza las pruebas.
Watir: es una familia de bibliotecas bajo la Licencia BSD para el lenguaje de programación
Ruby que automatiza la operación de los navegadores web, permite automatizar Internet
Explorer, Mozilla Firefox, Google Chrome y Safari y se encuentra disponible como una Gema
de Ruby.
Funcionalidad SOAPUI: Es una herramienta, desarrollada en java, para la realización de
pruebas a aplicaciones con arquitectura orientada a servicio (SOA) y transferencia de estado
representacional (REST). Soporta múltiples protocolos como SOAP, REST, HTTP, JMS, AMF y
JDBC.
Solex: Herramienta Open Source para testeo creado para ser implantado como un plugin
en Eclipse. Solex permite grabar la sesión de un usuario, permitiéndolo configurar en
función a diferentes parámetros, para poder ser utilizado posteriormente y ser repetida, de
manera que aseguremos la no regresión de la aplicación. Asimismo, también nos permite
realizar pruebas de estrés y rendimiento contra la aplicación web.
2. Herramientas de Pruebas Web Funcional/ Regresión (Basadas en Java):
Otro apartado a tener en cuenta es la comprobación de que la funcionalidad de la aplicación
es la esperada, en función a los requisitos que se han definido.
Para ello, existen multitud de herramientas y a continuación vamos a analizar algunas de
ellas:
Junit: JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases
Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los
métodos de la clase se comporta como se espera. Es decir, en función de algún valor de
entrada se evalúa el valor de retorno esperado, permite controlar pruebas de regresión, es
decir, detectar nuevos bugs que puedan surgir a consecuencia de haber cambiado el código
fuente inicial (por ejemplo, añadiendo nuevas funcionalidades). De esta manera, JUnit nos
permitirá comprobar que la aplicación cumple con los requisitos y que no se ha alterado su
funcionalidad inicial.
HTTP Unit: es una librería java Open Source para realizar testeos de caja negra en
aplicaciones web HTTP y servlets. La librería de testeo tiene las siguientes características:
 Autenticación
 JavaScript
 Redirección automática
HttpUnit se integra de forma sencilla con JUnit para realizar testeos de aplicaciones web.
JWeb Unit: es una herramienta muy interesante para realizar rápidamente una buena
batería de pruebas unitarias para nuestra aplicación web, con este framework, nuestras
pruebas podrán interactuar con la aplicación web, simulando las diferentes acciones del
usuario y revisando la interfaz que genera la aplicación en cada momento.
Jameleon: es una herramienta para probar aplicaciones de forma automática. Divide la
aplicación en características y crea casos de prueba para cada una de ellas, ha sido diseñado
para testear todo tipo de aplicaciones. Para hacer esto posible, Jameleon está diseñado en
forma de plugin. Actualmente hay diferentes plugins disponibles:
 JUnit plugin.
 Jiffie plugin.
 HtmlUnit plugin.
 Selenium plugin.
 Watir plugin.
 HttpUnit plugin.
 JwebUnit plugin.
3. Herramientas Comerciales para Pruebas Funcionales:
SoapTest: Permite a los usuarios verificar todos los aspectos de un servicio Web, WSDL de
validación, a la unidad y las pruebas funcionales del cliente y el servidor, para pruebas de
rendimiento, SOAPtest aborda cuestiones clave de servicios Web como la interoperabilidad,
la seguridad, la gestión del cambio y la escalabilidad.
Rational Functional Tester: Herramienta de automatización de pruebas funcionales y de
regresión. Proporciona capacidades de pruebas de interfaz gráfica, pruebas manejadas por
datos (Data Driven), pruebas funcionales y pruebas de regresión.
Algunas de sus características son:
 Simplificación de creación y visualización de pruebas.
 Pruebas de tipo storyboards.
 Trazabilidad en todo el ciclo de vida.
 Validación de data dinámica (por medio de un wizard).
 Capacidad de definir scripts (por medio de lenguajes de Scripting).
Entre las pruebas que realiza tenemos:
 Prueba de guión gráfico: simplifica la visualización y la edición de pruebas
mediante el lenguaje natural y las capturas de pantalla representadas.
 Pruebas automatizadas: permite a los probadores automatizar pruebas de forma
flexible cuando se realizan cambios frecuentes en la interfaz de usuario de las
aplicaciones con la tecnología ScriptAssure.
 Pruebas basadas en datos: le permite realizar las mismas series de acciones de
pruebas con un conjunto variado de datos de pruebas.
 Script de pruebas: combina un grabador de acciones de usuario con varias
opciones de personalización y funciones de mantenimiento de scripts
inteligentes.
 Integraciones: se integra con IBM Rational Team Concert e IBM Rational Quality
Manager para proporcionar acceso a elementos de trabajo y a soporte de activos
de pruebas de la SCM lógicas o compuestas.