Universidad del Quindío. López Cardona, González Idárraga. Marco de comparación para métodos de pruebas.
1
Marco de Comparación para Métodos de pruebas en el Campo de la Ingeniería de Software. López, Roy., González, Juan Camilo. {rllopezc, jcgonzalezi}@uqvirtual.edu.co Universidad del Quindío
Abstract— Software testing are processes that allow to verify and disclose the quality of a software product before its launch. A good method for testing software must be displayed testing activities at different levels; (I) unit testing; (Ii) integration testing; and (iii) environment or system testing. During the time has been defined a large number of methods for testing software, but these are not assessed or compared to existing testing methods which have been validated under a standard, therefore show only some of the aforementioned activities or practices based on defined immature fashion. In this paper we propose a framework for comparison testing methods in the field of software engineering in order to determine which method should be used, depending on what is to be achieved with the software product. This work shows the benefits of using the comparative framework for the choice of the testing method.
Índice de Términos— marco de comparación, método, prueba, software, niveles, producto, calidad, ingeniería. I. INTRODUCCIÓN La construcción de un marco de comparación tiene como finalidad establecer diferencias entre un conjunto de elementos de estudio, en este caso métodos de pruebas de software, los cuales definen su utilidad en una fase en el desarrollo de software que consiste en probar las aplicaciones construidas. Existen diferentes definiciones correspondientes a lo que es una prueba de software, entre ellas cabe resaltar: Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo condiciones especificadas, los resultados son observados o registrados, y una evaluación es realizada de un aspecto del sistema o componente [1]. Un enfoque análogo es definido por Swebok [2], en donde se plantea una prueba de software como una actividad ejecutada para evaluar y mejorar la calidad del producto a través de la identificación de defectos y problemas.
Otros especialistas de pruebas manifiestan que las pruebas de software son actividades claves para que los procesos de validación y verificación tengan éxito, ya que ayudan a entregar el producto con la calidad suficiente para satisfacer las necesidades del cliente y con la certeza de que el producto cumple las especificaciones definidas. En este sentido, las pruebas pueden considerarse como un proceso que intenta proporcionar confianza en el software y cuyo objetivo fundamental es demostrar al desarrollador y al cliente que el software satisface sus requisitos [3]. Un método de pruebas se compone de un conjunto de elementos con la pretensión de definir una guía, mediante la cual se realice la comprobación de un software. Cada método está conformado por diferentes técnicas para realizar las pruebas a diferentes niveles. Dichos métodos son clasificados de forma genérica en métodos de caja negra y métodos de caja blanca. Además establecen diferentes enfoques con el fin de especificar los requisitos de software, según Seo et al. [4]. Desafortunadamente los métodos de pruebas son difíciles de comparar porque muchos de ellos carecen de fundamentación teórica. Hay una serie de comparaciones sensibles que se pueden hacer entre los métodos de pruebas, las cuales en el análisis son menos útiles de lo que parecen. Las comparaciones son precisas pero utilizan parámetros no relacionados con la verdadera eficacia de los métodos, lo cual puede ser fundamentalmente engañoso [5]. Según Hamlet [5] la comparación empírica de los métodos de prueba deben lidiar con dos factores invalidantes potenciales: (i) Una colección de
Universidad del Quindío. López Cardona, González Idárraga. Marco de comparación para métodos de pruebas.
programas debe ser utilizado, esta puede ser muy pequeña o particular para que los resultados sean confiables. (ii) Una prueba de datos debe ser creada para cada método, los datos pueden tener propiedades buenas o malas no relacionadas con el método. En este documento nos enfocamos en identificar las características principales, diferencias, ventajas y desventajas de algunos métodos de pruebas de software, como el TDD, con el fin de establecer comparaciones e identificar el enfoque de cada uno de ellos mediante el cual buscan especificar los requisitos de software. Para completar esta tarea proponemos un marco de comparación de estos métodos, así como también se analiza la posibilidad de utilizar SEMAT como base para establecer las comparaciones. Este documento está organizado así: en la sección II presentamos el marco teórico sobre los métodos de pruebas que ya se han mencionado. En la sección III presentamos el trabajo relacionado. En la sección IV nosotros proponemos un marco de comparación para los métodos de pruebas. En la sección V se muestra el caso de estudio. Finalmente, en la sección VI presentamos algunas conclusiones. II. MARCO TEÓRICO Muchos métodos para realizar pruebas de software han sido desarrollados, todos con el objetivo de soportar los requisitos de software que han sido modelados a partir ya sea de casos de uso, diagramas de colaboración, especificaciones formales u otros métodos. Ciertamente una gran cantidad de trabajo que es desarrollado de manera temprana se interesa en métodos y aparatos que ayuden a crear “prueba de diseño de pensamiento” de manera más organizada para asistir el desarrollo de métodos. De acuerdo con Khan et al. [6] un número de modelos de métodos de pruebas ha sido considerado para la ejecución en ámbitos industriales, de igual forma otros han sido considerados ineficaces, pero dicha selección se da como juicio después de que las empresas hacen uso de un método determinado y al transcurrir el tiempo se dan cuenta que no alcanza a satisfacer las necesidades, por lo cual desechan el método con el
2
fin de adoptar uno nuevo que se adapte a sus necesidades. En casos extremos, dicha situación puede afectar por completo el proceso de desarrollo de software. En el contexto de las pruebas de software, TDD es una técnica avanzada para la implementación de las pruebas unitarias automatizadas para impulsar el diseño de software y la fuerza de desacoplamiento de las dependencias. TDD no pretende sustituir las pruebas tradicionales, sino que define una forma comprobada para asegurar la unidad de pruebas eficaz. La iniciativa global se traduce en mejoras continuas y proporciona un mecanismo para la propagación de las lecciones aprendidas entre los proyectos para mejorar aún más la organización. [1] III. TRABAJO RELACIONADO Un primer enfoque es planteado por Selby et al. [8] donde se aplica la metodología de experimentación para comparar tres estados de la práctica de técnicas para probar software: a) lectura de código por abstracción paso a paso, b) pruebas funcionales usando partición de equivalencia y análisis de valores en frontera, y c) prueba estructural usando 100% de criterios de cobertura. El estudio compara las estrategias en tres aspectos de las pruebas de software: eficacia en detección de fallas, costo de detección de fallas, y clases de fallas detectadas. 32 programadores profesionales y 42 estudiantes avanzados aplicaron las tres técnicas a cuatro programas en un diseño experimental. Algunos de los resultados obtenidos fueron: los profesionales detectaron más errores, con los estudiantes avanzados las tres técnicas no fueron diferentes en cuanto a cantidad de fallas detectadas, las pruebas funcionales detectaron más fallas que los otros métodos, entre otros resultados relacionados a los dos grupos abordados. Khan et al. [6] plantea que en las pruebas de software es adecuado si los métodos de pruebas solo son evaluados por la habilidad de identificar errores, sino que además ellos también pueden ser comparados sobre las pruebas entre las cuales ellos aumentan confiablidad. Se establecen variantes de confiabilidad en los métodos de pruebas de software, con el fin de definir su eficacia respecto a
Universidad del Quindío. López Cardona, González Idárraga. Marco de comparación para métodos de pruebas.
las características de los demás. Hamlet [5] plantea que la comparación de métodos de prueba de software solo tiene sentido si se hace referencia a las propiedades de comparación con la calidad de software actual. Las comparaciones existentes suelen utilizar fundamentos de anécdotas que no se relacionan necesariamente con la calidad, al comparar métodos en las bases de términos técnicos ellos mismos se definen. El más grave error es usar un método cuya eficacia es desconocida y se utiliza como estándar para juzgar a otros métodos. El ensayo aleatorio, como un método que puede ser relacionado a la calidad ofrece la oportunidad para comparaciones válidas. Mét odo Mé todo 1
Funcion amiento Caja blanca
Orien tación A obje tos
Tipo de Prueba Uni taria
Descripción
Mé todo 2
Caja negra
A compo nentes
Fun cional
Consta de 5 pasos repetitivos que …
Mé todo 3
Caja blanca
A mode los
De segur idad
Simula el método utilizado en …
Se deben diseñar casos de pruebas para …
Caracte rísticas Puede utilizar diferentes enfoques de …
Aplica bilidad Es preferible aplicarlo cuando …
Es necesario repetir las pruebas cada cierto tiempo … Los errores detectados son …
Es útil cuando se necesita …
Es un método general para …
3
IV. PROPUESTA Nosotros proponemos el uso de una tabla de comparación con el objetivo de lograr una identificación apropiada de las características, ventajas, eficiencia y demás características relevantes de un método de pruebas, a la vez que se puede establecer una clasificación de dichos métodos y evidenciar las diferencias entre ellos. De esta manera no solo se está analizando la habilidad de detección de errores de cada método, sino que se puede dar conciencia de a qué tipo de pruebas está dirigido y es posible identificar una aproximación de la calidad que tendrán las pruebas al momento de aplicarse.
Eficiencia
Ventajas
Des ventajas Requiere de más tiempo para …
Es capaz de detectar el 99% de los errores en … La eficiencia es variable en casos como …
Garantiza la calidad de …
Puede facilitar el desarrollo de …
No es confi able cuando …
Existe un margen de error de …
No es necesario tener …
El costo de imple menta ción se eleva …
Figura 1. Tabla de comparación entre métodos de pruebas con ejemplos de posibles datos.
En este orden de ideas y según Mustafa et al. [12], es posible clasificar las pruebas en los siguientes tipos: Prueba de estrés, de carga, de regresiones, funcional, de código abierto, de seguridad, de aceptación, de desempeño, unitaria. Estos tipos, o cualquier otro no citado pueden ser colocados en la columna “Tipo de Prueba”. Otros tipos de pruebas son mencionados en [10] y [11].
Asimismo en [11] se menciona que las pruebas se pueden agrupar según su funcionamiento, es decir, pueden considerar solo las entradas y salidas (caja negra) o también el proceso interno (caja blanca). Y los métodos de pruebas pueden estar orientados a objetos, componentes, modelos, etc. Conocer las características de cada método es necesario para poder luego identificar las
Universidad del Quindío. López Cardona, González Idárraga. Marco de comparación para métodos de pruebas.
diferencias. En vista de eso se decide emplear una columna de la tabla para estas características y otra para descripción, siendo esta última importante para conocer a grandes rasgos en qué consiste cada método. Las columnas de aplicabilidad y eficiencia dan a conocer cuándo es aplicable un método, y la habilidad para detectar errores respectivamente. Estos datos son de interés para usos empresariales y de producción. Por último se propone tener dos columnas separadas para las ventajas y desventajas de cada método de pruebas, ésta información será importante a la hora de decidirse por un método u otro. La tabla que se ilustra en la figura 1 contiene las columnas anteriormente descritas y es un ejemplo de cómo podrían ir los datos escritos en ella. Por otra parte, también se puede utilizar SEMAT para establecer comparaciones de métodos de pruebas. SEMAT tiene 3 áreas de interés, y dentro del área de “Solución” se encuentra el espacio de actividad “Probar el Sistema”, dentro del cual está la competencia de “Testing” que encapsula la habilidad de probar un sistema verificando que es usable y cumple con los requisitos [21]. Teniendo esto en cuenta se pueden usar los fundamentos propuestos por SEMAT en este espacio de actividad para analizar los métodos y compararlos. V. CASO DE ESTUDIO El caso de estudio presentado es un ejemplo de la aplicación de la tabla de comparación propuesta anteriormente y sólo contiene 2 métodos a comparar, los cuales son Desarrollo Guiado por Pruebas (TDD) y Desarrollo Dirigido por el Comportamiento (BDD), sin embargo la tabla puede utilizarse para comparar cualquier cantidad de métodos de pruebas. En esta ocasión la estructura de la tabla será segmentada.
Método
4
Funcionamiento
Test Driven Development Behavior Driven Development
Caja Negra Caja Negra
Figura 2. Tabla de funcionamiento. Método
Orientación
Test Driven Development Behavior Driven Development
A Pruebas A Comportamiento
Figura 3. Tabla de orientación. Método Test Driven Development Behavior Driven Development
Tipo de Prueba Unitaria De aceptación, funcional
Figura 4. Tabla de tipo. Método
Descripción Técnica de desarrollo de software que consiste en iniciar el proceso escribiendo las pruebas que el software debe pasar, antes de empezar a Test Driven Development escribir el código que las satisface. Es una práctica donde los criterios de aceptación del software se socializan y discuten con todo el equipo de desarrollo, luego estos criterios se aterrizan en ejemplos concretos antes de abordar las tareas de diseño y codificación y por último se Behavior Driven Development pasa a la fase de desarrollo
Figura 5. Tabla de descripción. Método
Test Driven Development
Behavior Driven Development
Características Las pruebas se escriben antes que el código. La definición de las pruebas se hace con base en Los requerimientos de la clase que se está implementando. El código debe pasar por diferentes casos de prueba. Exige la definición de las pruebas antes de empezar a codificar. Las pruebas se expresan en términos del comportamiento esperado del software. Consta de 4 fases que son la discusión, la destilación, el desarrollo de código y la producción de un demo
Figura 6. Tabla de características. Método
Aplicabilidad Se puede aplicar en los casos en donde no se ha Empezado a escribir código, y requiere de Test Driven Development herramientas de pruebas unitarias. Este método muestra su utilidad al inicio de ciclos de desarrollo, pues lo que se pretende es que todos los miembros del equipo tengan la misma percepción del problema y de la solución propuesta, esta técnica es fundamental cuando Behavior Driven Development se aplican metodologías ágiles de desarrollo.
Figura 7. Tabla de Aplicabilidad.
Universidad del Quindío. López Cardona, González Idárraga. Marco de comparación para métodos de pruebas.
Método
Eficiencia Este método garantiza que el código pase todas las pruebas establecidas puesto que solo se prueban pequeños fragmentos de código y éstos se refactorizan cada vez que no se pasa Test Driven Development la prueba. BDD apunta al cumplimiento de requisitos funcionales o de comportamiento de manera general, de manera que la confiabilidad Behavior Driven Development depende del diseño de las pruebas
Figura 8. Tabla de eficiencia. Método
Ventajas Se escribe la menor cantidad de código posible puesto que solo se debe escribir el código necesario para satisfacer las pruebas diseñadas. Propende por la obtención de Test Driven Development código de alta calidad. Se tiene un ciclo claramente definido que comineza con una discusión del problema, de las estrategias propuestas para abordarlo y de lo que se espera Behavior Driven Development obtener al finalizar del ciclo de desarrollo
Figura 9. Tabla de ventajas. Método
Desventajas Existe la posibilidad de que haya errores en el diseño de las pruebas, sobre todo si las hace la misma persona que codifica, lo que implica que no se obtengan los resultados esperados. Es una técnica que requiere disciplina puesto que es muy fácil no aplicarla con la debida rigurosidad. Para ciertas funcionalidades es muy difícil hacer un conjunto de pruebas que garantice que Test Driven Development todos los casos posibles estén cubiertos. Es necesario emplear el tiempo suficiente para que los miembros del equipo conozca en detalle el producto que se espera obtener en términos funcionales. Es necesario capturar las pruebas en un formato que debe ser aprobado por todo Behavior Driven Development el equipo.
Figura 10. Tabla de desventajas. Los dos métodos comparados son de tipo caja negra, debido a que las pruebas se construyen antes de la escritura de código, con lo que solo se saben las entradas y las salidas que deberían salir en un funcionamiento correcto. Asimismo las demás columnas se pueden llenar leyendo las especificaciones de los métodos.
comportamiento del software, y por lo tanto su aplicabilidad corresponde a casos diferentes. Sin embargo estas diferencias no impiden que ambos métodos se puedan aplicar de forma simultánea, y al tener distinta orientación éstos métodos se complementan el uno al otro. Por otra parte, también se pudieron identificar características en común entre ambos métodos, particularmente se tiene que ambos métodos requieren de la construcción de las pruebas antes de la escritura de código, de manera que también comparten la desventaja de que si hay errores en el diseño de las pruebas consecuentemente habrá errores que no se puedan detectar y por lo tanto no se obtendrán los resultados esperados. VI. CONCLUSIONES Un marco de comparación de métodos de pruebas es útil no solo para hallar ventajas, desventajas y diferencias entre métodos de pruebas, sino que permite conocer y contrastar datos necesarios para poder tomar decisiones validables, como lo son la eficiencia y la aplicabilidad. En este artículo nosotros propusimos un marco de comparación de métodos de pruebas de software como una manera práctica y sistemática de analizar, comparar y elegir métodos de pruebas sin tener que leer especificaciones detalladas. Luego demostramos con un caso de estudio la posibilidad de comparar gran cantidad de métodos con una tabla de comparación. Con esto se pretende que el interesado tenga una mayor claridad en las características de los métodos y pueda tener una guía para escoger un método a la hora de probar software. También proponemos SEMAT como una base para establecer estas comparaciones. REFERENCIAS
[1] I. Std.610, «IEEE pruebas de software,» 1990. [2] Swebok, «Swebok,» 2014.
Una vez se ha llenado la tabla se pueden identificar las diferencias entre ambos métodos, la más evidente es que TDD es orientado a pruebas unitarias, mientras que BDD apunta al
5
[3] Cibertec, «Pruebas de software,» 2007. [4] K. Seo y E. M. Choi, «Comparison of Five Black-box
Universidad del Quindío. López Cardona, González Idárraga. Marco de comparación para métodos de pruebas.
Testing Methods for Object-Oriented Software,» Seoul, 2006. [5] R. Hamlet, «Theoretical Comparison of Testing Methods,» 2008. [6] J. Khan, R. U. Khan, F. khan y S. Raza, «A Survey on Software Testing: Technique, Comparison and Analysis,» Malakand, 2013. [7] D. Duka y L. Hribar, «Test Driven Development Method in Software Development Process,» 2008. [8] V. Basili y R. Selby, «Comparing the Effectiveness of Software Testing Strategies,» 1987. [9] Chow, T. S., «Testing Software Design Modeled by Finite-State Machines,» 1978. [10] Jovanović, I., «Software Testing Methods and Techniques,» 2008. [11] Luo, L., & Li, P. (s.f.), «Software Testing Techniques,». [12] Mustafa, K., Al-Qutaish, R., & Muhairat, M., «Classification of Software Testing Tools Based on the Software Testing Methods,» 2009. [13] Williams, L., Maximilien, E., & Vouk, M., «TestDriven Development as a Defect-Reduction Practice,» 2003. [14] Elisabeth , H., «Driving Development with Tests: ATDD and TDD,» 2008. [15] Seo, K., & Choi, E. M., «Comparison of Five Blackbox Testing Methods for Object-Oriented Software,» 2006. [16] Juristo, N., Moreno, A., & Vegas, S., «TÉCNICAS DE EVALUACIÓN DE SOFTWARE,» 2006. [17] Gutiérrez, J., Escalona, M., Mejias, M., & Reina, A., Modelos de pruebas para pruebas del sistema.,» Sevilla 2006. [18] Franco Ochoa, J. C., «Metodologia para testing de software basado en componentes,». Medellin 2010. [19] Pérez Lamancha, B., «Proceso de testing funcional independiente,». Montevideo 2006. [20] Gonzales Varela, L., «Introducción al software testing,» 2012. [21] Zapata, C., & Castro, L., «Software Engineering: Methods, Modeling and Teaching,» (Primera ed., Vol. 3). Medellín, Colombia: Centro Editorial de la Facultad de Minas. 2014.
6