Anexo Test de Pruebas

ANEXO: TEST DE PRUEBAS La escritura de tests es tan importante que es algo que deberamos hacer todo el tiempo a lo largo del ciclo de desarrollo del software. Los tests, si estn bien escritos, nos permiten evaluar exhaustivamente la implementacin de una aplicacin en todos sus niveles.

Test unitarios: un test unitario ejercita el funcionamiento de una unidad de cdigo, normalmente una clase, aislada del resto de la aplicacin. Tests de integracin: un test de integracin ejercita el funcionamiento de una o varias clases en el contexto de la aplicacin. Tpicamente, estos tests verifican la interaccin con una base de datos, conexiones a sistemas externos, containers, etc.

Lo importante es automatizar el testeo de la aplicacin en todos los niveles. Los tests que escribamos deben tener dos propiedades: deben ser automticos e independientes. Los tests son sumamente valiosos cuando el nivel de stress es alto, as, si podemos ejecutarlos automticamente contamos con una valiosa herramienta para indicar que el sistema funciona correctamente. La autonoma e independencia entre los tests garantiza que la falla de un test no impacta al resto. Esto nos permite diagnosticar los problemas con ms precisin. Una forma efectiva de probar clases Java es utilizar JUnit que es posiblemente el ms antiguo y popular framework de test disponible para java. Por tal motivo es adoptado y bien conocido por la mayora de los desarrolladores y muy familiarizados con el. Hay numerosas extensiones disponibles para JUnit que permiten las pruebas de cualquier componente de nuestro sistema. Un caso simple de pruebas extiende de [Link] y este provee de algunos mtodos bsicos para construir pruebas incluyendo mtodos assert que son los mecanismos para comprobar la correccin de nuestro cdigo y realizar las validaciones adecuadas para garantizar el buen funcionamiento. Una forma efectiva de probar clases Java es por tanto utilizar JUnit. Esta es una excelente herramienta para probar nuestros JavaBeans normales, pero la necesidad de probar nuestro cdigo llega mucho ms all. Para la creacin de casos de prueba se deber utilizar StrutsTestCase. Adems se pueden utilizar otras herramientas para las pruebas de stress y carga, tales como Apache JMeter ([Link] en la que podemos definir y simular escenarios concurrentes. Para completar el conjunto de pruebas y garantizar la correccin del software construido deberamos recurrir a realizar una evaluacin del comportamiento funcional de la aplicacin. Para ello utilizaremos herramientas que nos permiten introducir un patrn de navegacin automatizado y ejecutar las pruebas de aceptacin Un ejemplo de estos productos es Solex.

1.1

JUnit

En [Link] podemos encontrar la ltima versin de junit, actualmente la 3.7. Para poder usar JUnit lo nico que debemos hacer es incluir el fichero [Link] en nuestro classpath. La forma de funcionar tpica de un test con JUnit es: definir unos datos, darles algn tipo de tratamiento, obtener unos resultados y comprobarlos con los resultados que nosotros estbamos esperando. La idea final es que sea el propio JUnit el que no diga si el test ha ido bien o por el contrario el resultado no coincide con el esperado.
Pgina: 1

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Anexo Test de Pruebas

1.1.1

Assert

Empezaremos viendo como se pueden hacer las comprobaciones de los resultados. La clase [Link], nos proporciona una serie de mtodos que son los encargados de hacer dichas comprobaciones. Esta clase contiene una serie de mtodos que empiezan por assert. Tenemos mtodos assert para comprobar si dos objetos son iguales (assertEquals...), para comprobar si un objeto es nulo (assertNull...), para comprobar si un objeto no es nulo (assertNotNull...) o para comprobar si dos variables apuntan a un mismo objeto (assertSame...). Cada llamada a un mtodo assert podemos considerarla como un test. La lgica de estos mtodos es simple, si la condicin del mtodo assert se cumple el test es valido, en caso contrario el test no es valido y lanza un FailedAssertionError, o sea, un error en el testeo. Debemos tener cuidado con los bloques try-catch, ya que estos bloques normalmente capturan excepciones que lanza nuestro cdigo indicando alguna anomala. Si en los test usamos algn bloque de este tipo no deberamos dejar que el test acabe bien. Para este propsito disponemos del mtodo fail() o fail(String mensaje), que lanza un FailedAssetionError, y nos informe de la anomala. 1.1.2 TestCase

La clase abstracta [Link] es la base sobre la cual definiremos nuestros tests. Esta clase extiende de [Link]. Para crear un test con JUnit debemos seguir estos tres pasos: Crear una clase que herede de la clase TestCase public class SimpleTest extends TestCase Crear un constructor con un parmetro de tipo String y llamar al constructor de la clase padre pasndole dicho String. public SimpleTest( String nombre ) { super( nombre ) } Crear uno o varios mtodos que empiecen por "test", sin parmetros y que no devuelvan nada. public void testSimple() { ... } De esta forma tan simple hemos creado una clase de test. Ahora solo nos queda implementar el mtodo testSimple(). import [Link]; public class SimpleTest extends TestCase { public SimpleTest( String nombre ) { super( nombre ); } public static void main( String args[] ) { [Link]( [Link] ); } public void testSimple() {
Subdireccin General de Desarrollo, Tecnologa e Infraestructuras. Pgina: 2

Anexo Test de Pruebas

String s1 = "DySs"; String s2 = "DySs"; assertEquals( s1, s2 ); } } Como hemos visto un TestCase no es mas que una clase que contiene uno o varios mtodos test...() donde aparecen una o varias llamadas a mtodos assert...() o fail(). La ejecucin de un test puede acabar de cuatro formas: o o Con la validacin correcta de todos los asserts. Esto es lo que esperamos. Lanzando uno a varios FailedAssertionError con su informacin asociada. Esto ocurre si algn assert no ha sido valido, o sea, la ejecucin de nuestro cdigo no ha devuelto el resultado esperado. Lanzando cualquier Exception de Java. Esto no es provocado por la validacin de los mtodos assert, sino que nos indica algn error de implementacin, ya puede ser del propio TestCase o de nuestro cdigo. Puede que el resultado sea una mezcla de excepciones de Java y FailedAssertionErrors.

Ejemplo: import [Link]; public class ErrorEnTryCatch extends TestCase { public static void main( String args[] ) { [Link]( [Link] ); } public ErrorEnTryCatch( String nombre ) { super( nombre ); } public void testTryCatch() { String error = null; try { [Link]( [Link]() ); } catch( NullPointerException npex ) { fail( "\nExcepcion capturada por el test\n" + npex ); } } } 1.1.3 setUp() y tearDown()

La secuencia de ejecucin de una clase que herede de TestCase es la siguiente: setUp() testAlgo() tearDown() Esta secuencia se repite para todos los mtodos test que contenga nuestra clase. Si tuvisemos varios mtodos test que realizan algn tratamiento sobre unos mismos datos, deberamos usar setUp() para la inicializacin de dichos datos. En setUp() inicializaremos
Subdireccin General de Desarrollo, Tecnologa e Infraestructuras. Pgina: 3

Anexo Test de Pruebas

variables, estableceremos conexiones con bases de datos, etc. En tearDown() liberaremos recursos tales como las conexiones a bases de datos. import [Link]; public class SimpleTest2 extends TestCase { private String s1; private String s2; private String s3; public SimpleTest2( String nombre ) { super( nombre ); } public static void main( String args[] ) { [Link]( [Link] ); } public void setUp() { s1 = "DySs"; s2 = "DySs"; s3 = "Ashther"; } public void testComparaStrings() { assertEquals( s1, s2 ); } public void testConcatenaStrings() { String test1 = s1 + s3; String test2 = s2 + s3; assertEquals( test1, test2 ); } }

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 4

Anexo Test de Pruebas

1.1.4

TestSuite

Es posible que tengamos nuestros tests estructurados en varias clases TestCase y nos interese ejecutarlos todos de una sola vez. Con este propsito JUnit nos proporciona la clase TestSuite que sirve para agrupar tanto TestCases como otras TestSuite. Para crear una coleccin de tests debemos seguir los siguientes pasos: Crear una clase que herede de TestCase public class VariosTest extend TestCase Crear un constructor con un parmetro de tipo String y llamar al constructor de la clase padre pasndole dicho String. public VariosTest( String nombre ) { super( nombre ) } Crear un mtodo esttico de nombre suite, sin parmetros de entrada y que devuelva un Test. public static Test suite() Crear un TestSuite dentro del mtodo suite TestSuite suite = new TestSuite(); Aadir tests al TestSuite // Solo un mtodo test [Link]( new SimpleTest2( "testConcatenaString" ); // Todos los metodos test de un TestCase [Link]( [Link] ); // Otro TestSuite [Link]( [Link]() ); devolver el TestSuite return suite;

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 5

Anexo Test de Pruebas

Ejemplo: import [Link]; import [Link]; import [Link]; public class VariosTest extend TestCase{ public VariosTest( String nombre ) { super( nombre ); } public static void main( String args[] ) { [Link]( suite() ); } public static Test suite() { TestSuite suite = new TestSuite(); [Link]( [Link] ); [Link]( new SimpleTest2( "testConcatenaStrings" ) ); return suite; } } 1.1.5 TestRunner

Hasta ahora hemos visto como crear nuestros test, ahora veremos la forma de ejecutarlos. Todos los ejemplos tienen un mtodo main donde se llama a [Link]. TestRunner es la clase encargada de ejecutar nuestros tests. Disponemos de tres clases TestRunner, una en modo testo y dos mas en modo grafico, Swing y AWT. public class VisualizaResultados { public static void main( String args[] ) { // Modo texto [Link]( [Link] ); // Modo grafico con AWT [Link]( [Link] ); // Modo grafico con Swing [Link]( [Link] ); } } 1.1.6 Conclusin

La forma ideal de usar JUnit es desarrollando en paralelo el cdigo de la clase y el test JUnit para ese trozo de cdigo, en vez de escribir toda la clase y luego escribir el test. Si desarrollamos en paralelo siempre nos ser mas fcil depurar el cdigo y testearlo mucho mejor, pero como he dicho es una forma de trabajar, no una obligacin. Como hemos podido comprobar el uso de JUnit es muy sencillo y a la vez potente. Y esto es solo la punta de iceberg, podis encontrar mucha mas informacin en su pagina oficial, [Link]

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 6

Anexo Test de Pruebas

1.2

StrutsTestCase

Es una extensin de la clase estndar TestCase de JUnit de Apache, permite el desarrollo de casos de pruebas de software basado en el framework Struts. Fue creado para mejorar el paradigma de diseo Modelo-Vista-Controlador (MVC) dentro de la capa de presentacin de una aplicacin Web. StrutsTestCase permite no solo probar la lgica de las clases Action como lo permite la clase TestCase si no que es capaz de invocar al controlador ActionServlet por lo que permite probar tambin los forward, ActionForms y mappings del software. StrutsTestCase permite el desarrollo de estos casos de prueba en base a dos posibles implementaciones, una basada en Mock Object que no requiere la ejecucin dentro de un contenedor de aplicaciones y otra basada en Cactus para la ejecucin dentro de un contenedor. JMock es una librera que permite realizar tests utilizando objetos simulados (mock objects) dinmicos. El objetivo es aislar los objetos que se testean sustituyendo los objetos con los que se relacionan por objetos simulados en los que podemos definir su estado y los resultados de los mtodos. En esencia, un desarrollador es responsable de maquetar las clases que definen el interface para ser consumidas por las clases que se estn probando. Cactus es una extensin de JUnit, prueba cdigo del lado del servido al nivel de unidad. Cactus soporta la aproximacin in-container para pruebas del lado del servidor. Ambas herramientas son imprescindibles y no deberan faltar en cualquier equipo de desarrollo de aplicaciones empresariales que busque la calidad. La estrategia generalmente aceptada para pruebas en Struts ser la de probar las clases de la capa de presentacin a travs de la capa de aplicacin. Seguidamente se muestra un ejemplo de uso de StrutsTestCase con Mock que valida una accin: // Extendemos de MockStrutsTestCase: public class TestLoginAction extends MockStrutsTestCase { public TestLoginAction(String testName) { super(testName); } // Vamos a probar un caso de xito public void testLogin() { // Indicamos donde est nuestro fichero de configuracin setConfigFile("/WEB-INF/config/[Link]"); // Indicamos la accin que vamos a probar setRequestPathInfo("/login"); // Seteamos las form bean properties addRequestParameter("username","deryl"); addRequestParameter("password","radar"); // Realizamos la llamada actionPerform(); //Verificamos el forward
Subdireccin General de Desarrollo, Tecnologa e Infraestructuras. Pgina: 7

Anexo Test de Pruebas

verifyForward("success"); // Comprobamos que no existan errores verifyNoActionErrors();

} }

Adems StrutsTestCase provee mtodos para desarrollar casos de pruebas sobre software basado en Struts y Tiles como muestra el siguiente ejemplo: // Extendemos de MockStrutsTestCase: public class TestLoginAction extends MockStrutsTestCase { public TestLoginAction(String testName) { super(testName); } // Vamos a probar el caso anterior pero verificando Tiles public void testLogin() { // Indicamos donde est nuestro fichero de configuracin setConfigFile("/WEB-INF/config/[Link]"); // Indicamos la accin que vamos a probar setRequestPathInfo("/login"); // Seteamos las form bean properties addRequestParameter("username","deryl"); addRequestParameter("password","radar"); // Realizamos la llamada actionPerform(); // Podemos verificar el forward verifyForward("success"); // La plantilla tiles que usar la salida verifyInputTilesForward("[Link]"); // o ambos a la vez verifyTilesForward("success","[Link]");

} }

StrutsTestCase puede descargarse desde la siguiente direccin: [Link] La versin actual es la 2.1.3 publicada en Noviembre de 2004 que da soporte a la versin de struts 1.2.X Cabe destacar que el ndice de actividad actual en el proyecto es muy alto. La falta de nuevas releases es debida principalmente a la escasa evolucin que ha tenido el framework Struts Action o clsico en los ltimos aos. Por lo tanto hablamos de un producto muy maduro del que no se prev nuevas versiones (aunque s parches y correcciones), salvo que se produzcan grandes cambios en el framework de Struts. Para poder utilizar StrutsTestCase es necesario disponer de las libreras:

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 8

Anexo Test de Pruebas

La librera jakarta-commons-colections: [Link] El conjunto de libreras que componen el sistema de casos de prueba Cactus: [Link] Uso y configuracin. Existe un FAQ: [Link] Foro de discusin: [Link] API: [Link]

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 9

Anexo Test de Pruebas

1.3

Pruebas de carga: JMeter

Por medio de la herramienta que presentamos a continuacin, es posible medir el comportamiento de una aplicacin ante diversos escenarios de concurrencia. La informacin de esta herramienta se encuentra disponible en: [Link] JMeter es una herramienta de carga para llevar acabo simulaciones sobre cualquier recurso de Software. Inicialmente diseada para pruebas de estrs en aplicaciones web, hoy en da, su arquitectura ha evolucionado no slo para llevar acabo pruebas en componentes habilitados en Internet (HTTP), sino adems en Bases de Datos , programas en Perl , requisiciones FTP y prcticamente cualquier otro medio. Adems, posee la capacidad de realizar desde una solicitud sencilla hasta secuencias de requisiciones que permiten diagnosticar el comportamiento de una aplicacin en condiciones de produccin. En este sentido, simula todas las funcionalidades de un Navegador ("Browser"), o de cualquier otro cliente, siendo capaz de manipular resultados en determinada requisicin y reutilizarlos para ser empleados en una nueva secuencia.

1.3.1

Prueba de carga bsica

El componente principal de JMeter es denominado Plan de Prueba o Test Plan, en l se definen todos los aspectos relacionados con una prueba de carga, como : parmetros empleados por requisicin, tipo de reportes a generarse con los resultados obtenidos, la posible reutilizacin de requisiciones compuestas por usuarios, entre otros aspectos. A continuacin se ilustra paso a paso un Plan de Prueba utilizado para simular una carga de 50 usuarios solicitando la pgina principal en determinado sitio.

Estando en la interfase principal de JMeter (ilustrada anteriormente), en la columna izquierda debe observar un icono llamado Test Plan -- seleccinelo -- al llevar acabo este paso, en la ventana derecha aparecern varias opciones, aquella encontrada en la parte superior le permite asignar un nombre a su plan de prueba, defnalo a su criterio. El resto de las opciones representan funcionalidades avanzadas que no sern descritas para esta simulacin. Definido el nombre, colquese nuevamente en el icono Test Plan y oprima el botn derecho de su "mouse", del men generado seleccione la opcin Add -- Thread Group; para efectos prcticos un "Thread Group" es considerado el grupo de usuarios que desea simular para su aplicacin.

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 10

Anexo Test de Pruebas

Ahora seleccione el icono Thread Group recientemente creado. Al llevar acabo este paso la ventana derecha mostrar la siguiente serie de opciones : o name : Utilizado para definir un nombre ms descriptivo sobre el grupo de usuarios, como : "Usuarios Esperados" o number of threads : Equivale al numero de usuarios que se desean simular, en este caso utilizaremos 50. o o Ramp-up period : Es el lapso de tiempo en segundos que se desea tener entre cada grupo de usuarios ("Thread Group") , utilizaremos 15 . Forever : Utilizado para indicar si la simulacin para grupos de usuarios ("Thread Group") ser llevada acabo infinitamente, esto es, si selecciona esta opcin indica que desea simular 50 usuarios, esperar 15 segundos ("Ramp-up period"), simular otros 50 usuarios y as sucesivamente. Para esta prueba es recomendable defina 10 ciclos para simular un total de 500 usuarios en cuestin de 150 segundos. Scheduler : Finalmente, esta opcin permite definir tiempos de arranque para determinados grupos de usuarios ("Thread Group") , para efectos prcticos de esta simulacin no ser seleccionada esta opcin y se iniciar la prueba a nuestra discrecin.

Una vez definidas las caractersticas del grupo de usuarios ("Thread Group"), colquese nuevamente en este icono de la columna izquierda y ahora seleccione la opcin Add -Sampler -- HTTP Request . Lo anterior genera un icono denominado HTTP Request utilizado para definir las requisiciones de simulacin. Si selecciona este ltimo icono aparecern las siguientes opciones en la ventana derecha : o Server Name o IP : Empleado para definir la direccin I.P o nombre del servidor donde ser llevada acabo la prueba de carga, se utilizar [Link] para indicar un servidor local. port number: Define el puerto TCP de operacin del servidor, ser empleado 80, que es el "default" para Servidores de Pginas .

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 11

Anexo Test de Pruebas

path : Utilizado para definir la ruta de acceso para llevar acabo la prueba, ser definido /[Link], tpicamente la pgina principal de todo sitio para Internet.

Ahora debe colocarse en el icono de HTTP Request y oprimir el botn derecho de su "mouse", del men generado seleccione la opcin Add -- Listener -- Graph Results, as como Add -- Listener -- View Results in Table. Lo anterior le indica a JMeter que debe generar una grfica y tabla (respectivamente) con los resultados obtenidos en la simulacin. Finalmente guarde su plan de prueba ("Test Plan") y ejectelo seleccionando la opcin Run -- Start del men superior. Si se coloca en el icono Graph Results mientras se esta llevando acabo la simulacin, puede observar como es construida interactivamente la grfica de resultados.

Como ultima nota, es recomendable que cuando ejecute la presente prueba de carga tambin realice un anlisis sobre el comportamiento del Hardware, para tener una perspectiva global acerca del sistema.

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 12

Anexo Test de Pruebas

1.3.2

Prueba de carga avanzada

La prueba ilustrada en la seccin anterior lleva acabo solicitudes idnticas en todos sus ciclos, sin embargo, aunque este tipo de requisiciones simulan el comportamiento que puede tener determinado cliente (Navegador/"Browser"), carece de elementos especficos que puedan simular con mayor exactitud una carga de produccin real. A travs de JMeter tambin es posible realizar requisiciones para que cada solicitud contenga parmetros nicos por usuario, de esta manera permitiendo simular clientes especficos. Una caso tpico como este se puede presentar al intentar simular el registro simultneo de varios usuarios en una aplicacin, ya que cada cliente (Navegador/"Browser") emplea un usuario y contrasea distinta. A continuacin se ilustra paso a paso como llevar a cabo una prueba de esta naturaleza en JMeter. La definicin de usuarios con sus respectivos parmetros de requisicin es llevado acabo en un archivo XML llamado [Link]; en el directorio bin de JMeter puede encontrar una muestra de este archivo, as como su respectivo DTD . Para nuestra prueba utilizaremos un archivo [Link] con los siguientes datos : <?xml version="1.0"?> <!DOCTYPE allthreads SYSTEM "[Link]"> <allthreads> <thread> <parameter> <paramname>usuario</paramname> <paramvalue>asanchez</paramvalue> </parameter> <parameter> <paramname>contrasea</paramname> <paramvalue>java</paramvalue> </parameter> </thread> <thread> <parameter> <paramname>usuario</paramname> <paramvalue>jperez</paramvalue> </parameter> <parameter> <paramname>contrasea</paramname> <paramvalue>xml</paramvalue> </parameter> </thread> <thread> <parameter> <paramname>usuario</paramname> <paramvalue>tpadilla</paramvalue> </parameter> <parameter> <paramname>contrasea</paramname>
Subdireccin General de Desarrollo, Tecnologa e Infraestructuras. Pgina: 13

Anexo Test de Pruebas

<paramvalue>puntonet</paramvalue> </parameter> </thread> <!-- Ms usuarios ("Threads") en base a prueba --> </allthreads> Como puede notar, el archivo inicia con el elemento <allthread> que anida estructuras <thread>, como fue mencionado anteriormente y para efectos prcticos, cada "Thread" representa una requisicin de usuario. A su vez, dentro de cada elemento <thread> se definen los Tags <parameter> -- empleado para definir parmetros por solicitud -- y estos a su vez incluyen, <paramname> -- utilizado para definir el nombre del parmetro -- , as como <paramvalues> para especificar su respectivo valor. En resumen, el archivo anterior representa tres solicitudes de usuarios con dos parmetros por requisicin : nombre y contrasea; el tipo de solicitudes generadas por JMeter seran idnticas a las creadas por una forma HTML / XHTML . Un vez generado [Link] colquelo en el directorio bin de JMeter, sobre-escribiendo el archivo muestra. Realice los mismos pasos indicados en la prueba bsica de JMeter en la definicin del "Thread Group", modificando el numero de usuarios para reflejar aquellos definidos en [Link], en este caso tres :

Una vez definidas las caractersticas del grupo de usuarios ("Thread Group"), colquese nuevamente en este icono de la columna izquierda y ahora seleccione la opcin Add -Sampler -- HTTP Request . Lo anterior genera un icono denominado HTTP Request utilizado para definir las requisiciones de simulacin. Ahora es necesario asociar el grupo de usuarios definidos en nuestro archivo con las requisiciones, esto se logra colocndose en el icono HTTP Request oprimiendo el botn derecho del "mouse" y seleccionando la opcin : Add -- Pre Processors -- HTTP User Parameter Modifier; en esta ventana puede observar que las instrucciones "default" son leer el archivo [Link] del directorio bin de JMeter :
Pgina: 14

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Anexo Test de Pruebas

Posteriormente, seleccione nuevamente el icono HTTP Request para definir sus otros parmetros en la ventana derecha : o Server Name or IP : Empleado para definir la direccin I.P o nombre del servidor donde ser llevada acabo la prueba de carga, se utilizar [Link] para indicar un servidor local. port number: Define el puerto TCP de operacin del servidor, ser empleado 80, que es el "default" para Servidores de Pginas . HTTP Request - Method : Modifique el mtodo de requisicin a tipo POST, ya que el proceso a simular es de registro. path : Utilizada para definir la aplicacin de servidor empleada para procesar la requisicin, en esta caso definiremos un JSP en el directorio principal del servidor : /[Link] . Send parameters with the request : A travs del icono Add debe agregar los parmetros que sern enviados por solicitud como fueron definidos en [Link] , lo nico que debe definir son sus nombres, los valores son tomados automticamente del archivo XML .

o o o

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 15

Anexo Test de Pruebas

Colquese nuevamente en el icono de HTTP Request y oprima el botn derecho de su "mouse", del men generado seleccione la opcin Add -- Listener -- Graph Results, as como Add -- Listener -- View Results in Table. Lo anterior le indica a JMeter que debe generar una grfica y tabla (respectivamente) con los resultados obtenidos en la simulacin. Finalmente guarde su plan de prueba ("Test Plan") y ejectelo seleccionando la opcin Run -- Start del men superior. Si se coloca en el icono Graph Results mientras se esta llevando acabo la simulacin, puede observar como es construida interactivamente la grfica de resultados.

Como ultima nota, es recomendable que cuando ejecute la presente prueba de carga tambin realice un anlisis sobre el comportamiento del Hardware, para tener una perspectiva global acerca del sistema.

1.4

Pruebas de aceptacin: Solex

Mediante esta herramienta es posible grabar la navegacin realizada, introducir variables y puntos de comprobacin y repetir la misma de forma automtica para verificar que el sistema se comporta de la forma esperada. La informacin de este plugin se encuentra disponible en: [Link]

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 16

Anexo Test de Pruebas

1.5

Conclusiones y recomendaciones

Una buena razn para escribir tests es que ganamos en eficiencia a corto, mediano y largo plazo: un control exhaustivo y automtico de la aplicacin nos permite garantizar su buen funcionamiento en forma rpida. Con JUnit los tests pueden ser ejecutados desde varios ambientes diferentes: la IDE (Eclipse, JDev, etc), Ant, Maven, lnea de comandos. En segundo lugar, escribiendo tests ganamos en calidad: contar con una batera completa de tests nos permite refactorizar el cdigo cmodamente para introducir mejoras. La correcta ejecucin de los tests nos da ciertas garantas sobre la calidad de la aplicacin. En tercer lugar, la escritura de tests aumenta nuestro nivel de confianza con la implementacin porque sabemos que el estado actual de la aplicacin est bajo control. Esto es particularmente importante cuando hay diferentes personas en el grupo de desarrollo: la correcta ejecucin de los tests nos garantiza que la integracin de nuevos desarrollos no corrompe la base de cdigo existente. La escritura de tests cases tambin aumenta el grado de confianza a nivel individual, lo que se traduce en mayor satisfaccin por el trabajo realizado. Finalmente, la escritura de tests tambin contribuye a una mejor documentacin de la aplicacin; de hecho los tests constituyen el tipo de documentacin que evoluciona junto con la aplicacin. Qu mejor forma de documentar una clase que con una batera de test cases que muestran explcitamente cmo debe ser utilizada, con sus datos de entrada y salida? Una cuestin fundamental es que los tests sean escritos por la misma persona que escribe el cdigo de la implementacin. La escritura de tests no puede delegarse en alguien que desconoce los detalles finos de la aplicacin ya que los tests deben evolucionar junto con la implementacin. Por otro lado, el testeo no es algo que corresponda a una fase especfica del proceso de desarrollo. Es algo que debemos hacer todo el tiempo. Sobre todo, no es algo que debamos postergar para el final. Idealmente, los tests unitarios deben escribirse antes que el cdigo de la clase que se testea. En ese mismo sentido debemos mencionar una metodologa de desarrollo llamada Test Driven Development (TDD) que justamente nos alienta a escribir los tests antes que el cdigo de la implementacin. La aplicacin de ese principio nos obliga a reflexionar sobre las responsabilidades y servicios expuestos por las clases de tal manera que puedan ser testeadas fcilmente. El resultado es un diseo mucho ms limpio, comprensible e intuitivo. Aunque muchos consideran que TDD es demasiado extrema en sus ambiciones, debemos admitir que es realmente efectiva como forma de trabajo porque nos ayuda a concentrarnos en las necesidades y requerimientos concretos del sistema, dejando de lado la implementacin de funcionalidad innecesaria. Sin duda alguna StrutsTestCase + JUnit es la mejor eleccin a la hora de desarrollar casos de prueba del mercado para aplicaciones basadas en Struts Action, tanto por la simplicidad del cdigo, como por las funcionalidades nicas que ofrece a la hora de probar Actions, ActionForms, forwards, mapping y Tiles. Estas libreras usadas conjuntamente con la clase TestCase de JUnit nos proveen de un potente sistema de desarrollo de casos de prueba, las siguientes recomendaciones aseguran en gran medida la robustez y calidad de la aplicacin desarrollada:

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 17

Anexo Test de Pruebas

Separacin del desarrollo de los distintos componentes de la aplicacin por capas:

1. Desarrollo de clases de la capa de modelo.

En esta fase se construyen normalmente las clases de negocio, persistencia a base de datos del componente que vamos a desarrollar, etc... Paralelamente y mediante el uso de la clase TestCase de JUnit vamos desarrollando casos de prueba unitarios para cada funcionalidad que vamos completando. Antes de continuar con el desarrollo debemos ser capaces de lanzar toda la batera de pruebas desarrollada sin errores.

2. Desarrollo de clases de la capa de control.

Una vez disponemos de las clases de la capa de modelo y estamos seguros de su buen funcionamiento gracias a los casos de prueba, empezamos a generar las clases de control, las clases Action y ActionForm. Paralelamente desarrollaremos casos de prueba con las clases de StrutsTestCase. Generaremos una clase de prueba para cada uno de los ActionForm y cada una de las clases de accin con un caso de prueba para cada posible comportamiento de la accin, esto asegurar un comportamiento correcto de las acciones. 3. Desarrollo de capa de vista. Una vez que hemos probado satisfactoriamente todos los casos de prueba de ambas capas podemos desarrollar la capa de vista, una vez terminado el desarrollo lanzaremos todas las bateras de pruebas y comprobaremos que el conjunto de la aplicacin responde como era de esperar. Es muy posible tener que modificar o ampliar la funcionalidad de las clases de negocio o de control debido a cambios producidos durante el desarrollo de otras capas, nunca hemos de olvidar crear o modificar casos de prueba que cubran los cambios realizados y asegurarnos de que todos ellos responden como es de esperar.

Subdireccin General de Desarrollo, Tecnologa e Infraestructuras.

Pgina: 18