ESTRATEGIA PARA LA APLICACIÓN DE PRUEBAS DE CAJA BLANCA Y CAJA NEGRA EMPLEANDO LA METODOLOGÍA RUP.

Transcripción

1 ESTRATEGIA PARA LA APLICACIÓN DE PRUEBAS DE CAJA BLANCA Y CAJA NEGRA EMPLEANDO LA METODOLOGÍA RUP. Ing. Susana González Espinosa 1, Ing. Rafael Bello Lara 2, Dania Durán Cutiño 3 1, 2,3 Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños Km 2 ½, La Lisa, La Habana. sespinosa@uci.cu RESUMEN Este trabajo se centra en la selección de los procesos que formarán parte de la estrategia para la aplicación de pruebas. Para ello se definen primeramente los niveles de prueba a realizar, resaltando la significación que tienen en estos las pruebas de Caja Blanca y Caja Negra. Se hace un breve análisis de las ventajas que proporciona la metodología RUP y de su correcto empleo. Se realizó una selección de los roles que deben intervenir en cada uno de los procesos, así como de los artefactos necesarios para que estos se encuentren debidamente documentados, dando paso a cada una de las actividades a desarrollar. Mediante una representación gráfica se explican los diferentes aspectos de cada proceso y se hace una proposición de las herramientas a utilizar para la automatización de las pruebas. La estrategia desarrollada fue aplicada en uno de los subsistemas que componen el producto SAREN (Servicio Autónomo de Registros y Notarías). Se realizó un análisis de los resultados reales y esperados con el propósito de corregir los defectos encontrados. Mediante la correcta aplicación de esta estrategia se garantiza que se realice la detección de errores en la fase correspondiente, garantizando que en la liberación del producto este se encuentre libre de defectos. Palabras claves: Pruebas de software, procesos de pruebas, herramientas de pruebas automatizadas. STRATEGY FOR THE IMPLEMENTATION OF WHITE BOX TESTING AND BLACK BOX USING RUP METHODOLOGY. ABSTRACT This paper focuses on the selection of the processes that form part of the strategy for the implementation of tests. This first defined test levels to be performed, highlighting the significance of these tests have White Box and Black Box. A brief analysis of the advantages provided by the RUP methodology and its proper use. A selection was made of the roles that should be involved in each of the processes and artifacts required for them are properly documented, leading to each of the activities to be developed. Through a graphical representation explains the different aspects of each process and a proposal are made to use tools for test automation. The strategy developed was applied in one of the subsystems in the product SAREN (Autonomous Service Registries and Notaries). An analysis of actual and expected results for the purpose of correcting defects found. Through the proper application of this strategy is

2 guaranteed to perform error detection in the corresponding phase, ensuring that the release of this product is free from defects. Keywords: Software testing, testing processes, automated testing tools. INTRODUCCIÓN Lograr un alto nivel de calidad es el objetivo de la mayoría de las organizaciones que desarrollan software. Según la IEEE La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. Para determinar la calidad de un producto de software se deben desarrollar actividades que permitan comprobar el grado de cumplimiento de las especificaciones iniciales del sistema, y es aquí donde las pruebas de software desempeñan un papel fundamental. Estas verifican el desarrollo que va alcanzando el producto durante todas sus etapas, identificando posibles fallos de implementación, calidad, o usabilidad de un programa. Hoy en día han surgido tendencias en virtud de demostrar la importancia de las pruebas de software, así como proponer mejoras a las mismas y de esta forma, incrementar la calidad del proceso de desarrollo. Entre estas tendencias se encuentran vincular el proceso de pruebas a lo largo del ciclo de vida de desarrollo de software y la automatización de las mismas. Algunos autores como Krutchen, Pressman, Pfleger, Cardoso y Sommerville afirman que el proceso de Ejecución de Pruebas debe ser considerado durante todo el ciclo de vida de desarrollo del software, para así obtener un producto de alta calidad. Su éxito dependerá del seguimiento de una estrategia de prueba adecuada. La estrategia de prueba de software integra un conjunto de actividades que describen los pasos que hay que llevar a cabo en un proceso de prueba, tomando en consideración cuánto esfuerzo y recursos se van a requerir, con el fin de obtener como resultado una correcta construcción del software. DESARROLLO En la estrategia no se define el momento en que deben culminar las pruebas, simplemente se realiza una propuesta para cada iteración, se propone al responsable de calidad del equipo de desarrollo que se le realice al producto la cantidad de iteraciones necesarias mientras se encuentren defectos críticos en la aplicación. Para llevar a cabo la estrategia con éxito, se debe comenzar a trabajar desde el interior del programa, es decir, desde la partícula más pequeña hasta la máxima expresión que el mismo pueda alcanzar; por lo que se decide comenzar este proceso realizando la prueba de unidad. El énfasis de esta prueba es verificar que esta pequeña unidad funcione

3 correctamente en forma aislada antes de proceder a integrarla al sistema. La prueba de unidad está basada fundamentalmente en la realización de técnicas de pruebas de Caja Blanca y en menor medida en técnicas de pruebas de Caja Negra. Para optimizar tiempo y esfuerzo se automatizan las técnicas de pruebas de Caja Blanca empleando para ello la herramienta NUnit. Luego se pasaría a verificar que todas estas unidades que ya han sido probadas y funcionan correctamente, lo hacen de igual forma cuando interactúan y se integran con otras unidades del sistema. Después de haber verificado cada una de ellas individualmente, se espera que al interactuar estas, se mantengan funcionando sin problemas. Luego que el software ha sido integrado se realizan pruebas de alto nivel, entre estas se encuentra la prueba de validación, que es de suma importancia ya que es la que proporciona la información de si se satisfacen o no todos los requisitos funcionales. Para la realización de esta prueba se usa exclusivamente la técnica de prueba de Caja Negra. La realización de las pruebas de sistema está comprendida entre las pruebas de alto nivel. Este tipo de pruebas permiten probar el sistema como un todo así como también aspectos relacionados con la integración del producto a otros sistemas. En esta etapa se le pueden realizar también pruebas de Caja Negra al producto, aunque se le da mayor atención a las pruebas de estrés, rendimiento, configuración, seguridad, usabilidad, entre otras. La utilización de RUP es factible en proyectos de gran tamaño ya que tiene un proceso de pruebas bien definido. La ventaja de ser dirigido por casos de uso posibilita el diseño de casos de prueba y la posible automatización de las mismas. Debido a que es iterativo e incremental, las pruebas no se realizan cuando el producto está terminado, sino que este posibilita que en cada iteración pueda ser aplicado al menos un ciclo de pruebas. Para la elaboración de la estrategia se analizaron los procesos asociados a las pruebas de software. De esta forma se propone la realización de 5 procesos, como muestra la Figura 1, que se consideran necesarios e indispensables para el desarrollo y progreso efectivo de cada una de las acciones a llevar a cabo en la etapa de pruebas. Figura 1 : Procesos de la estrategia.

4 Como primer proceso se tiene la planificación de las pruebas la cual consiste en definir los roles y recursos del sistema para un apropiado entorno de pruebas, así como la definición de una estrategia adecuada y la planificación del esfuerzo. Figura 2: Planificación de las pruebas. Luego se tiene el diseño de pruebas el cual consiste en identificar los casos de prueba y estructura los procedimientos de pruebas. Figura 3: Diseño de las pruebas.

5 Posteriormente se pasa a la implementación de las pruebas la cual consiste en automatizar los procedimientos de prueba obteniendo los componentes de prueba correspondientes. Figura 4: Implementación de las pruebas. Luego se pasa a la ejecución de las pruebas la cual consiste en comparar el comportamiento esperado del software con su comportamiento real, analizar las diferencias y reportar los resultados. Figura 5: Ejecución de las pruebas. Y por último y no menos importante por esto se tiene la evaluación de las pruebas la cual consiste en evaluar los resultados obtenidos y elaborar un documento con los errores detectados, así como recomendaciones y observaciones para futuras pruebas a realizar, con vista a las próximas iteraciones a efectuar.

6 Figura 6: Evaluación de las pruebas. Para obtener un buen resultado a partir de cada uno de los procesos de prueba descritos anteriormente, es necesario tener en cuenta un aspecto fundamental: las herramientas para la automatización de las pruebas unitarias ya que optimizan el tiempo y el esfuerzo notablemente. Para la automatización de las pruebas se han creado una serie de herramientas que ayudan en gran medida a su realización, ya que en nuestros días los sistemas que se necesitan son cada vez más grandes y complejos y con estas herramientas se puede reforzar el desarrollo de todo el proceso de pruebas, disminuyendo tiempo, esfuerzo y costo. Herramientas para la automatización de las pruebas unitarias. Las pruebas escritas a mano generalmente son automatizadas usando el mismo lenguaje que se utiliza en construir el SBP puesto que es más viable el acceso a las mismas APIs (Application Programming Interface) que el sistema. Esto no es obligatorio, usar un lenguaje familiar para los desarrolladores disminuye el esfuerzo requerido para aprender cómo automatizar completamente las pruebas. Para esto se han creado una serie de herramientas que ayudan en gran medida a su realización. Para este proceso muchos frameworks son implementados basados en el patrón xunit usando lenguajes de programación orientado a objetos. El término xunit se refiere a cualquier miembro de la familia de frameworks de pruebas automatizadas. La mayoría de los lenguajes de programación, hoy cuentan con al menos una implementación de xunit, donde se comparten características básicas que permiten lograr las siguientes funcionalidades: Especificar las pruebas como métodos de prueba ; especificar los resultados esperados dentro del método de prueba en forma de llamadas a métodos de aserción ; agregar las pruebas en suites de pruebas que puedan ser ejecutadas como una sola operación y ejecutar una o más pruebas para obtener un reporte de los resultados de la ejecución de las pruebas.

7 Algunos de los frameworks xunit tienen soporte para descubrir los métodos de prueba o alguna forma de selección para ejecutar subconjuntos de métodos de prueba basados en algún criterio. (MESZAROS, 2007) Entre las herramientas creadas para analizar el código se encuentra JUnit (para aplicaciones en Java). Esta ha tenido tanto éxito que se ha extendido a otros muchos lenguajes de programación. Todos los frameworks heredados de JUnit han recibido la denominación xunit, de ahí el patrón xunit. Entre los framworks xunit, existen versiones para C/C++ (CUnit y CPPUnit), Delphi (DUnit), PHP (PHPUnit), HTML (HTMLUnit), NUnit (plataforma.net), VBUnit (Visual Basic) entre otros. Todas estas herramientas ayudan al diseño y ejecución de las pruebas de Caja Blanca. Estas constituyen un conjunto de frameworks que permiten realizar la ejecución de clases de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Las pruebas unitarias se pueden efectuar de forma manual, pero cuando se van a aplicar a proyectos de gran magnitud esto se vuelve muy engorroso. En ocasiones, se hace muy difícil ejecutar un gran número de pruebas dado el factor tiempo, que es muy importante para el desarrollo total del proyecto. Por esto se considera que es una buena práctica la automatización de las pruebas para cualquier proyecto de software. En el proyecto Registros y Notarías, se decidió emplear la herramienta NUnit que se ajusta a la plataforma.net para llevar a cabo dicho proceso. NUnit es un framework open source de pruebas unitarias para todos los lenguajes de la plataforma.net. Tiene la misma funcionalidad que JUnit. NUnit, como caso particular, es un framework desarrollado en C# que ofrece las funcionalidades necesarias para implementar pruebas en un proyecto. Provee una interfaz gráfica para ejecutar y administrar las mismas, informando si una prueba (o un conjunto de pruebas) falló, pasó o fue ignorada. Para ello compara los valores esperados y los valores generados, y si estos son diferentes la prueba no pasa, en caso contrario la prueba es exitosa. Con NUnit se logra ejecutar pruebas automatizadas fácilmente. Contiene mecanismos para recolectar resultados de manera estructurada, produce varios tipos de reportes a partir de los resultados obtenidos en la ejecución de las pruebas, permite que existan relaciones entre las pruebas y que unas reutilicen código de otras. Además, soporta la jerarquía entre las pruebas pudiendo establecerse la prioridad y el orden de unas con otras. NUnit.Forms y NUnit.ASP constituyen una expansión al framework núcleo NUnit. Estos tienen como objetivo ampliar NUnit de manera que este sea capaz de manejar pruebas de elementos de interfaz de usuario tanto en Windows Forms como en ASP.NET. NUnit posee un conjunto de meta atributos y aserciones que permiten probar los métodos de una clase especificada. Se puede ejecutar desde la consola o a través de una interfaz gráfica y se puede integrar con el Visual Studio en cualquiera de sus versiones.

8 Caso de estudio Con el objetivo de automatizar el Sistema Registral y Notarial venezolano surge el proyecto Registros y Notarías. Para dicha automatización se crean varios sistemas entre los que se encuentra el Sistema de Administración Financiera el cual tiene como propósito principal agilizar el proceso financiero y administrativo para los registros y notarías de Venezuela, eliminando los trámites innecesarios y facilitando mecanismos modernos de comunicación interdepartamental, poniendo a disposición de cada puesto de trabajo una función automatizada, que contempla desde la formulación de presupuestos, hasta la obtención de estados financieros finales. El Sistema de Administración Financiera en SAREN (Servicio Autónomo de Registros y Notarías) está conformado por los siguientes módulos relacionados entre sí: Administración, Presupuesto, Contabilidad, Requisiciones, Compras y Servicios, Retenciones, Recaudación, Tesorerías, Fondos en Anticipo y Caja Chica. El SAREN puede estar estructurado por la Unidad Administradora Central (UAC), Unidades Administradoras Desconcentradas (UAD) y Unidades Ejecutoras Locales (UEL), a partir de esta estructura es que se desarrolló el Sistema de Administración Financiera del SAREN. El trabajo desarrollado fue aplicado en el módulo Requisiciones del sistema Administración Financiera. Se realizó un análisis de los resultados reales y esperados con el propósito de corregir los defectos encontrados. Mediante la correcta aplicación de esta estrategia se garantiza que se realice la detección de errores en la fase correspondiente, garantizando que en la liberación del producto este se encuentre libre de defectos. A continuación se muestra una comparación de los resultados obtenidos luego de haber ejecutado las pruebas siguiendo procedimientos diferentes en el módulo Requisiciones. El módulo Requisiciones fue desarrollado en paralelo por 2 equipos con las mismas características en cuanto a experiencia y actitudes para el desarrollo de software. El equipo A, siguió el estándar de desarrollo propuesto en el proyecto con la aplicación de las pruebas de forma tradicional utilizando al equipo de calidad interna del proyecto. El equipo B aplicó el procedimiento de prueba descrito en este trabajo. Los resultados en cuanto a la cantidad de defectos detectados se encuentran en la Tabla 1. Equipo Defectos Tiempo(dias) Tamaño(CU) Pruebas realizadas A Caja Negra B Caja Blanca y Caja Negra Tabla 1. Resultados.

9 CONCLUSIONES En este trabajo se presentó una estrategia que muestra los pasos a seguir en la etapa de pruebas. Además se seleccionan un conjunto de procesos para la realización de las pruebas unitarias los cuales describen nuevos roles, actividades y artefactos que interactúan en cada uno de ellos. Y en su momento, posibilitó la realización de las pruebas unitarias aplicando la técnica de prueba de Caja Blanca mediante el uso de la herramienta de automatización NUnit, mostrando sus resultados como aval del buen desempeño del equipo de trabajo e identificando dificultades que evitarían. La aplicación de la estrategia al caso de estudio demostró la factibilidad de la misma y permitió además resolver algunas dificultades técnicas dentro de los procedimientos definidos a partir de este trabajo, los desarrolladores que emplean tecnología.net podrán aplicar la estrategia propuesta, con ello aumentará la calidad de los sistemas entregados a los clientes. BIBLIOGRAFIA BOSOM, A Pruebas Unitarias (Unit Testing). [Disponible en: pruebas-unitarias-unit-testing] DUSTIN, E., RASHKA, J. y al, et Automated Software Testing: Introduction, management and performance. s.l. : Addison-Wesley, SALANOVA, P. E. (2006). Modelos de Calidad Web. Clasificación de Métricas., UNIVERSIDAD NACIONAL DE EDUCACION A DISTANCIA: 308 PRESSMAN, R, S Ingenieria del Software. Un enfoque práctico. Quinta edición. ed. McGraw Hill. GUTIÉRREZ, J. J.; ESCALONA, M. J., et al. Estudio comparativo de propuestas para la generación de casos de prueba a partir de requisitos funcionales. Disponible en: ANDREW HUNT, DAVID THOMAS: Pragmatic Unit Testing in C# with NUnit The Pragmatic Bookshelf, Raleigh 2004, ISBN JIM NEWKIRK, ALEXEI VORONTSOV: Test-Driven Development in Microsoft.NET. Microsoft Press, Redmond 2004, ISBN BILL HAMILTON: NUnit Pocket Reference. O'Reilly, Cambridge 2004, ISBN KRUCHTEN, P. The Rational Unified Process as Introduction. 2 nd Edition PFLEEGER, S. Software Engineering CARDOSO, R. Pruebas del Software SOMMERVILLE, I. Software Engineering