5.Realización de pruebas en entornos Java PDF

Preview

Summary

apuntes de clase que sirven para el examen...

Description

ZĞĂůŝnjĂĐŝſŶ ĚĞ ƉƌƵĞďĂƐ ĞŶ ĞŶƚŽƌŶŽƐ :ĂǀĂ

Construcción de Software

Realización de pruebas en entornos Java Entre las alternativas con las que se encuentra el desarrollador Java para probar su código están: • La escritura de valores por pantalla: ésta es una estrategia que suele incluirse en el inicio de muchos proyectos, antes de ser sustituida por otras estrategias más sofisticadas, generalmente cuando aparece el fenómeno conocido como scroll blindness (ceguera por desplazamiento, que hace alusión a las dificultades para comprobar que todo funciona bien cuando el número de líneas impresas por pantalla son muchas). • El uso de herramientas de log: existen diversas herramientas de log disponibles, entre ellas el paquete java.util.logging incluido en el entorno de ejecución de Java. La utilización de depuradores: en la actualidad los IDE ( Integrated Development Environments , entornos de desarrollo integrado) cuentan con herramientas que facilitan la depuración del código. La formalización de una batería de pruebas y su automatización le provee las ventajas de formalizar la batería de pruebas y automatizarlas, entre ellas citamos las siguientes: 1. Permiten definir con claridad el comportamiento del código antes de implementarlo (siempre y cuando escriba las pruebas antes que el código). 2. Mantienen su valor en el tiempo. Las formas manuales de probar el código no son persistentes, volver a ejecutarlas implica el mismo esfuerzo que realizarlas por primera vez. 3. Permite la realización de pruebas de regresión cada vez que modificamos el código garantizando la integridad del mismo. Lógicamente, estas formas de realizar pruebas no son excluyentes.

El entorno de ejecución de pruebas Junit: Cuando se considera que cierto módulo está acabado, se realiza una serie de pruebas en busca de fallos a través de los criterios de pruebas de caja negra y/o de caja blanca, tenga en cuenta que no son excluyentes, sino complementarias, hay que procurar usar las dos. Cuando nos fijamos en las devoluciones de cada una de las funciones de la CUT (Class Under Test), estamos ante las pruebas funcionales o de caja negra.

--

El proceso de una prueba de caja negra es simple, se ejecuta la unidad de prueba con datos y se observa la salida, se compara con el resultado esperado. En caso de que la prueba se supere, es decir, el resultado obtenido y el esperado son iguales, se denomina ―oráculo‖. Conforme se va pasando las pruebas de caja negra se puede determinar qué ―cantidad‖ de código se ha cubierto, es decir, cuanto porcentaje de código se ha ejecutado. Estas son las pruebas de caja blanca. Con las pruebas de caja blanca lo que se busca es encontrar fragmentos del programa que no son ejecutados por los casos de pruebas. Si el resultado de estas pruebas es menor al 100%, se deben ejecutar otros casos para intentar llegar al 100%. Si aun así no se consigue ese 100%, debemos preguntar si sirve de algo ese código. El proceso de realizar estas pruebas es simple, como podemos observar en el siguiente diagrama:

--

••••••••••••••••••••••

•••••••••••••••••••••••••• ••••••••••••••••••••••••••

••••••••••••••••••••••

ad Domain Model

••••••••••••••••••••••

•••••••••••••••••••••••••• ••••••••••••••••••••

•••••••••••••••••••••

Seleccionamos CUT

••••••••••••••••••••••

•••••••••••••••••••••••••• •••••••••••••••••••• •••••••••••••••••••••

Generamos casos para probar CUT

••••••••••••••••••••

•••••••••••••••••••••

Pruebas de Caja Negra

••••••••••••••••••••••

•••••••••••••••••••••••••• ¿Hay errores?

errores •• ••••••••Corregir ••••••

•••••••••••••••••••••••• ••••••••••••••••••••••••••

SI

NO

••••••••••••••••••••••

Pruebas de Caja Blanca

••••••••••••••••••••••

•••••••••••••••••••••••••• ¿Alcanza el umbral?

•••• •••••••••••

••••••••••••••••••••••••• ••••••••••••••••••••••••••

NO

SI

Añadir casos

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

••••••••••••••••••••••••••

••••••••••••••••••••••

--

Mutante: un mutante es una copia de la CUT con un pequeño fallo, un cambio sintáctico, por lo tanto, un mutante no es más que una versión defectuosa de la CUT. Para generar mutantes puede usar la aplicación MuJava, genera mutantes, ejecuta los casos de pruebas contra ellos y muestra los resultados obtenidos. JUnit es un conjunto de clases ( framework ) de código abierto 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, simplificando la ejecución de pruebas unitarias y de regresión en Java. También permite la automatización de baterías de pruebas para sistemas Java. Con estos dos programas se pueden crear los casos de pruebas de forma simple, aunque en la actualidad, entornos de desarrollo cono NetBeans y Eclipse cuentan con plug-in los cuales se encargan de generar los casos de prueba, permitiendo centrarnos en el resultado obtenido y no en la creación del caso.

Antes de comenzar, consideramos conveniente introducir la nomenclatura de Junit: • Caso de prueba: un caso de prueba es una clase que contiene un conjunto de pruebas relacionadas entre sí. El ejemplo típico es el caso de prueba ―ClaseXXTestCase‖ que prueba a la clase ―ClaseXX‖. Cada caso de prueba contiene a su vez un conjunto de pruebas. • Prueba: Cada prueba es un método dentro un caso (clase) de prueba que se denominan ―testXX()‖. Es importante que el nombre comience con "test" ya que sirve para que Junit pueda, por introspección, determinar qué métodos corresponden a pruebas debiendo ser ejecutados y cuáles son de soporte. Creación de un caso de prueba: Para realizar un caso de prueba, basta con: 1. Crear una clase que extienda a junit.framework.TestCase. 2. Añadirle un constructor que acepte un String como parámetro y lo pase a su superclase. 3. Generar el entorno de pruebas. Para ello, utilizamos los métodos setUp() para la puesta a punto del entorno y tearDown() para liberar cualquier recurso que lo necesite. Estos métodos son invocados antes y después de cada prueba. 4. Codificar las pruebas. Cada prueba es un método que comienza con "test", es decir, si tenemos N pruebas, tendremos N métodos que se llamarán testXX(). Cada prueba se ejecuta por separado, y el orden en que se ejecutan las pruebas no está determinado. Por ello, es fundamental que, con la ayuda de los métodos setup y teardown, cada prueba sea completamente independiente de las demás y no deje efectos colaterales ni para otras pruebas, ni para sí misma cuando se vuelva a ejecutar. Cuando Junit ejecuta una prueba, ejecuta primero el setup, luego la prueba, y luego el teardown, y así para cada una de ellas. 5. Cuando se quiere comprobar un valor, se utiliza la familia assert (afirmar): assertTrue, assertFalse, assertEquals, assertNotNull, entre otras. Además, tenemos el método fail(String

-4-

message), que se utiliza para forzar a que la prueba falle (por ejemplo, cuando una parte del código de prueba no se debería ejecutar y se ejecuta). Creación de baterías de pruebas En Junit, agregar casos de prueba en baterías de pruebas se conoce como creación de suites de pruebas. Para crear una suite hay que instanciar la clase TestSuite e invocar los métodos de adición de pruebas. Recuerde que Junit incorpora la adición de pruebas por introspección, mediante la cual, con solo pasar el nombre de la clase al constructor de la suite, se genera automáticamente una prueba para cada método de la clase que comience por ―test‖. Para ejecutar las pruebas, existen diversas alternativas, aunque todas son similares: 1- Utilizar el TestRunner (ejecutor de pruebas) proporcionado por Junit, tanto en su versión textual como en la que posee interfaz gráfica de usuario. 2- Usar el plugin incluido en Eclipse [ECLIPSE] o cualquier otro IDE ( Integrated Development Environment, Entorno de Desarrollo Integrado) que contenga un plugin para Junit, 3- Utilizar las tareas de Ant que existen al efecto, junit y junit-report. Esto permite automatizar la ejecución de las pruebas, integrándolo con la construcción de la aplicación.

Mejorar la calidad del Software de aplicaciones web Cuando su aplicación es Web como las de nuestro caso, ya que con JavaEE usted diseñará y construirá aplicaciones que corran en Internet o en una Intranet, es necesario pensar que necesitamos automatizar las pruebas teniendo en cuenta que la arquitectura base es de tipo cliente-servidor. Es importante identificar algunas características necesarias para agilizar el trabajo del desarrollador en el autotesting y la del equipo de testing, para ello es importante que la herramienta permita ―grabar‖ todo lo que se haga. Cada click del Mouse y cada input del teclado queden grabados y registrados en código script, pudiendo modificarlo cuando lo necesitemos hacer. Con esta grabación usted podrá comprobar que el caso de prueba descripto inicialmente en la planilla Excel se cumplió. ¿Qué gana con esto? Testing de Regresión: permite grabar y ejecutar las pruebas tantas veces como lo necesite, lo cual produce una ganancia de tiempo considerable cuando se trata de proyectos de software medianos o grandes, o bien de productos. Es decir, aquel software donde las pruebas serán ejecutadas reiteradamente. Testing Distribuido: puede correr el test en distintas PCs para que ejecuten las pruebas de manera simultánea o bien sincronizada. Testing de Caja Blanca: se puede acceder a su modelo de objetos y ejecutar cualquier método, evento o lo que sea que haya sido programado y compilado. Web Page Testing: permite ejecutar muchos tipos de tests sobre páginas web entre las cuales están los test de carga, de stress, de performance. También permite acceder al modelo de objetos (DOM) del browser por lo que hacer un test en una página web será igual a hacerlo en una aplicación win32/64.

-

Logs/Resultados: un completísimo listado de resultados por cada prueba, incluso screenshots, comparaciones de imágenes obtenidas de las pruebas contra imágenes de nuestro repositorio, entre otros. Recuerde entonces que la calidad del software que usted está desarrollando no depende solamente de su codificación sino de las pruebas unitarias que le realice a sus componentes y las pruebas de integración que le realice al sistema antes de entregarlo al equipo de testing. Busque una herramienta que le permita automatizar las pruebas y si no tiene los casos de prueba diseñados, interprete los casos de uso que le han llegado para programar y diseñe sus propios casos de prueba.

--...