Estudio comparativo de propuestas para la generación de casos de prueba a partir de requisitos funcionales (LSI-2005-01)

Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática Universidad de Sevilla Avda Reina Mercedes, s/n. 41012 SEVILLA Fax : 95 455 71 39. Tlf: 95 455 71 39. E-mail: [email protected] Estudio comparativo de propuestas para la generación de casos de prueba a partir de requisitos funcionales. Javier Jesús Gutiérrez, María José Escalona, Manuel Mejías, Jesús Torres {javierj, escalona, risoto, torres}@lsi.us.es Universidad de Sevilla Lenguajes y Sistemas Informáticos España Sevilla, Febrero de 2005 2 HOJA DE CONTROL DE MODIFICACIONES Número Fecha Descripción Autores 0 11 – 2004 Desarrollo Inicial Javier Jesús Gutiérrez y María José Escalona. 1 02 – 2005 Versión final Los autores del trabajo. 3 Índice. 1. Introducción. .................................................................................................5 1.2. Las pruebas del sistema desde el punto de vista de la calidad. ..................................6 2. Descripción de propuestas.............................................................................8 2.1. Method Employing Scenarios to Systematically Derive Test Cases for System Test (SCENT)............................................................................................................................8 2.1.1. Bloque 1. Obtención de escenarios de uso...................................................................... 8 2.1.2. Bloque 2: Generación automática de casos de prueba a partir de escenarios............. 11 2.2. Generación de casos de prueba a partir de casos de uso. .........................................12 2.3. UML-Based Statistical Test Case Generation..........................................................13 2.4. AGEDIS....................................................................................................................15 2.4.1 Descripción del proceso................................................................................................. 15 2.4.2. Descripción de las herramientas................................................................................... 16 2.5. Use Case Path Análisis.............................................................................................18 2.6. Resumen de las propuestas estudiadas.....................................................................20 3. Descripción de casos de uso reales. ............................................................21 3.1. GLASS, aplicación práctica de SCENT...................................................................21 3.1.1. Sistema de monitorización remota de subestaciones en sistemas de distribución de energía eléctrica...................................................................................................................... 22 3.1.2. Sistema de monitorización de transformadores de alto voltaje..................................... 23 3.1.3. Conclusiones.................................................................................................................. 23 3.2. AGEDIS....................................................................................................................23 3.2.1. Descripción de 5 casos de estudio................................................................................. 23 3.2.2. Conclusiones.................................................................................................................. 24 4. Ejemplos de uso. .........................................................................................26 4.1. Descripción del caso de uso......................................................................................26 4.2. Generación del conjunto de pruebas aplicando SCENT. .........................................27 4.3. Generación del conjunto de pruebas aplicando Generating Test Cases from Use Cases................................................................................................................................30 4.4. Generación del conjunto de pruebas aplicando UML-Based Statistical Test Case Generation. ......................................................................................................................32 4.5. Generación del conjunto de pruebas aplicando AGEDIS. .......................................35 4 4.6. Generación del conjunto de pruebas aplicando Use Case Path Analisys.................35 5. Análisis y comparación de las propuestas descritas. ..................................39 5.1. Puntos en comunes y comparación global................................................................39 5.2. Principales puntos fuertes y puntos débiles de las propuestas estudiadas................41 5.2.1. SCENT........................................................................................................................... 41 5.2.2. Generación de casos de prueba a partir de casos de uso. ............................................ 42 5.2.3. UML-Based Statistical Test Case Generation............................................................... 42 5.2.4. AGEDIS......................................................................................................................... 42 5.2.5. Use Case Path Analisys................................................................................................. 43 7. Conclusiones y futuros trabajos..................................................................44 7.1. Conclusiones.............................................................................................................44 7.2. Futuras líneas de investigación.................................................................................44 8. Referencias..................................................................................................45 5 1. Introducción. Hoy en día, debido al aumento del tamaño y la complejidad del software, el proceso de prueba se ha convertido en una tarea vital en el de desarrollo de cualquier sistema informático. Son muchas las clasificaciones de los tipos de prueba que se pueden realizar. Una clasificación posible es la propuesta por Métrica 3 [15] y que se muestra en la tabla 1. Tipo de pruebas Fase de realización Descripción Pruebas Unitarias. Durante la construcción del sistema Prueban el diseño y el comportamiento de cada uno de los componentes del sistema una vez construidos. Pruebas de Integración. Durante la construcción del sistema Comprueban la correcta unión de los componentes del sistema entre sí a través de sus interfaces, y si cumplen con la funcionalidad establecida Pruebas de Sistema. Después de la construcción del sistema Prueban a fondo el sistema, comprobando su funcionalidad e integridad globalmente, en un entorno lo más parecido posible al entorno final de producción. Pruebas de Implantación. Durante la implantación en el entrono de producción. Comprueba el correcto funcionamiento del sistema dentro del entorno real de producción. Pruebas de Aceptación. Después de la implantación en el entorno de producción. Verifican que el sistema cumple con todos los requisitos indicados y permite que los usuarios del sistema den el visto bueno definitivo. Pruebas de Regresión. Después de realizar modificaciones al sistema. El objetivo es comprobar que los cambios sobre un componente del sistema, no generan errores adicionales en otros componentes no modificados. Tabla 1 . Descripción de las pruebas del software. En la ilustración 1 se muestra sobre que elementos se realiza el conjunto de pruebas de la tabla 1 y quienes son los participantes. Las pruebas unitarias y de integración no pueden comenzar hasta que no se dispone de componentes del sistema ya construidos, al igual que las pruebas de implantación y aceptación que tampoco pueden comenzar hasta que se disponga del sistema completo y se instale en su entorno de producción. Sin embargo, la planificación de las pruebas de sistema puede comenzar antes de que el sistema esté terminado. Como el objetivo de las pruebas de sistema es comprobar que todo lo que se está desarrollando cumple con los requisitos del sistema, la planificación de estas pruebas y el diseño de los casos de prueba pueden comenzar tan pronto como empiecen a estar disponibles las especificaciones funcionales del sistema. La planificación y diseño de las pruebas de sistema en las primeras fases de desarrollo, cuando aún se realiza la elicitación de requisitos, permite encontrar errores, omisiones, inconsistencias y sobreespecificaciones en los requisitos funcionales cuando 6 aún es fácil y económico corregirlas, ya que el coste de eliminar defectos aumenta a medida que aumenta el tiempo qué transcurre entre la aparición del defecto y su detección [13]. Verificación Implementación Pruebas de sistema Pruebas de aceptación Validación Verificación Requisitos de los clientes Verificación Pruebas de integración Requisitos del sistema Diseño del sistema Cliente Ingeniero de pruebas Desarrolladores Pruebas de implantación Pruebas unitarias Diseño de componentes Aceptación Ilustración 1. Descripción de las pruebas del software. Para que el proceso de prueba del sistema sea eficaz debe estar integrado dentro del propio proceso de desarrollo y, como cualquier otra fase de dicho proceso, debe realizarse de manera sistemática, minimizando el factor experiencia o intuición. Esto se puede conseguir a través de metodologías que guíen el proceso de desarrollo de pruebas de sistema a partir de requisitos funcionales. 1.1. Objetivos de este trabajo. El control de calidad de cualquier producto debe comprobar que la calidad del producto final se ajusta a una especificación dada. En el caso concreto del software, el control de calidad debe comprobar que el producto final funcione correctamente de acuerdo con sus especificaciones y en colaboración con otros sistemas software y bases de datos [13]. Un aspecto crucial del control de la calidad son las pruebas del software y, dentro de estas, las pruebas del sistema. Cuando hablamos de pruebas de software nos referimos a la verificación dinámica del comportamiento de un sistema. Esta verificación está basada en la observación de un conjunto seleccionado de ejecuciones controladas o casos de prueba. 7 Las primeras propuestas aparecidas para la sistematización y automatización del proceso de pruebas de sistema estaban basadas en la utilización de máquinas de estados finitos como herramienta de representación del comportamiento del sistema. Posteriormente, con el auge del conjunto de diagramas propuestos en la notación UML para el modelado de los diferentes aspectos de un sistema, surgieron nuevas propuestas metodológicas y herramientas para el desarrollo del proceso de prueba a partir de escenarios de uso del sistema descritos mediante diagramas, principalmente con la notación UML. Actualmente, está surgiendo un nuevo grupo de propuestas que intenta integrar estas dos aproximaciones, tanto la aproximación basada en máquinas de estados como la aproximación basada en escenarios de uso, adoptando lo mejor de ambas [14]. Dentro de este grupo de propuestas, tanto SCENT [2] como AGEDIS [5] son dos de sus representantes más destacados. Las pruebas del sistema son aquellas que se aplican al producto final, las cuales permiten detectar en que puntos el producto no cumple sus especificaciones. El objetivo de estas pruebas es probar a fondo el sistema, comprobando su funcionalidad e integridad globalmente, en un entorno lo más parecido posible al entorno final de producción. El objetivo de las pruebas del sistema es comprobar que el sistema software que se está desarrollando cumple con la funcionalidad recogida en casos de uso o escenarios. En este trabajo se describen y analizan cinco propuestas para la obtención de casos de prueba para la realización de pruebas del sistema a partir de los requisitos del sistema. También se analizan los casos prácticos documentados donde se han aplicado estas propuestas y los resultados obtenidos y, por último, se desarrolla un ejemplo práctico con cada una de estas propuestas. 8 2. Descripción de propuestas. En este apartado vamos a describir brevemente cinco propuestas que permiten obtener un conjunto de casos de prueba para la realización de pruebas del sistema a partir de los requisitos funcionales del sistema software. En los dos siguientes apartados se estudiaran los casos prácticos a los que se han aplicado y se desarrollará un ejemplo con cada propuestas y en el apartado cinco expondremos las similitudes y diferencias entre ellas y sus principales puntos fuertes y débiles. Los criterios para la selección de las propuestas analizadas han sido, en primer lugar, seleccionar las propuestas más actuales. En este aspecto ninguna de las propuestas analizadas en este artículo es anterior al año 2.002, e incluso una de ellas, AGEDIS [5], ha finalizado a principios del año 2.004 por lo que es la propuesta más actual existente en el momento de preparar este artículo. En segundo lugar hemos buscado propuestas basadas en la corriente actual de aunar las aproximaciones de máquinas de estados y escenarios de uso, por lo que hemos seleccionado dos de las propuestas más representativas en este campo como son SCENT [2] y AGEDIS. En tercer lugar hemos seleccionado, como alternativa a las dos propuestas anteriores, dos propuestas sencilla y rápidas de poner en marcha, una llamada Generación de casos de prueba a partir de casos de uso [1] y otra llamada UML-Based Statistical Test Case Generation [8]. Las cuatro propuestas seleccionadas en los párrafos anteriores obtienen un conjunto de pruebas funcionales. Sin embargo, existen más tipos de pruebas posibles, como pruebas de seguridad, pruebas de carga y rendimiento, etc. Por este motivo hemos seleccionado una propuesta que nos permite derivar casos de prueba para realizar pruebas de fiabilidad llamada UML-Based Statistical Test Case Generation [4]. 2.1. Method Employing Scenarios to Systematically Derive Test Cases for System Test (SCENT). SCENT [2], [3] es una metodología que se puede dividir en dos grandes bloques. En el primero, SCENT describe un proceso para definir escenarios de uso, refinarlos y organizarlos, a partir de los requisitos funcionales del sistema software. En el segundo, a partir de estos escenarios, describe como obtener sistemáticamente casos de prueba de sistema. 2.1.1. Bloque 1. Obtención de escenarios de uso. SCENT define escenario de uso como un conjunto ordenado de interacciones entre un sistema y uno o varios actores. Un escenario puede abarcar una secuencia concreta de interacciones o un conjunto de posibles interacciones o caminos de ejecución. Los pasos 9 para obtener un conjunto de escenarios adecuados para la posterior derivación de casos de prueba se muestran en la tabla 2. Paso Descripción Resultado 1 Encontrar todos los actores que interactúan con el sistema. Lista de actores 2 Encontrar todos los eventos externos relevantes para el sistema (disparadores / triggers). Lista de eventos. 3 Determinar las entradas y salidas del sistema y sus resultados. Entradas y salidas del sistema. 4 Determinar los límites del sistema Diagrama de contexto. 5 Crear descripciones de escenarios sin detallar, solo con el nombre y una breve descripción. Lista de escenarios. 6 Asignar prioridades a los escenarios de acuerdo a su importancia y verificar que los escenarios cubren toda la funcionalidad del sistema. Lista de escenarios ordenador por prioridad y enlaces escenarios – actores. 7 Para cada escenario detallar paso a paso su secuencia de eventos, organizándolos según la plantilla que SCENT proporciona. Flujo de acciones en los escenarios. 8 Crear un diagrama de dependencias. Diagrama de dependencias. 9 Revisión y corrección de los escenarios y diagramas por loa usuarios. Anotaciones de los escenarios. 10 Extender los escenarios refinando la descripción del flujo de acción principal y descomponer las tareas en pasos simples. Descripción del flujo principal de acción. 11 Modelar flujos alternativos de ejecución, indicando las excepciones que provocan y como reaccionar a estas excepciones. Flujos de ejecución alternativos, excepciones y su manejo. 16 Especificaciones Modelo de comportamiento Generar Objetivos de las pruebas Directivas de generación Generar Directivas de ejecución Generar Conjunto de pruebas Generar Generar Ejecución de las pruebas y obtención de resultados Ejecutar Ejecutar Análisis y retroalimentación Ilustración 5. Descripción del proceso de obtención y ejecución de casos de prueba. Por último se analizan los resultados y se repiten los pasos hasta que se alcanzan los objetivos deseados. 2.4.2. Descripción de las herramientas. El proceso de AGEDIS está soportado por un conjunto de herramientas con una interfaz gráfica común. En la ilustración 6 se muestra de manera gráfica las herramientas que intervienen en cada una de las partes del proceso. A continuación se describen las herramientas existentes.  Una interfaz gráfica de usuario común para todas las herramientas de AGEDIS.  Una herramienta de simulación de modelos que permite depurar el modelo de comportamiento.  Un generador de pruebas capaz de crear un conjunto de casos de prueba que satisfagan el criterio de cobertura, indicado en los objetivos de la prueba,  Un marco de ejecución de pruebas independiente de la plataforma y lenguaje del sistema (actualmente soporta C, C++ y Java)  Dos herramientas para el análisis de los resultados de las pruebas, un analizador de cobertura que informa de valores posibles no probados y caminos de ejecución no recorridos, y un analizador de defectos que agrupa los defectos encontrados en un camino de ejecución. 17 Modelo < Objecteering > Directivas de generación < XML > Compilador Codificación intermedia < Lenguaje IF > Generador < TGV o Gotcha > Conjunto abstracto de pruebas < XML > Ejecución < Spider > Traza de ejecución Analizador < FoCus > Visualizador < FoCus > Directivas de ejecución < Objecteering > Ilustración 6. Descripción de la arquitectura de herramientas de AGEDIS. En la tabla 7 se describen brevemente las herramientas de soporte del proceso AGEDIS. Herramienta. Descripción. Objecteering Herramienta para construir modelos de comportamiento del sistema en lenguaje AML (AGEDIS Modelling Language). Se encarga de traducir los modelos en AML a lenguaje IF. Spider Motor de ejecución de las pruebas encargado de ejecutar el conjunto de pruebas generado teniendo en cuenta las directivas de ejecución. FoCus Herramienta para la visualización y análisis de los resultados de los catálogos de pruebas. Gotcha y TGV Motores de generación de pruebas a partir de la descripción del comportamiento del sistema y de las directivas de generación. Tabla 7. Descripción de las herramientas. 18 2.5. Use Case Path Análisis. Esta propuesta [8] describe un proceso de 5 pasos que permite obtener, a partir de un caso de uso, un conjunto de caminos de ejecución adecuado para ser traducidos a pruebas del sistema. Estos pasos se resumen en la tabla 8. Paso Descripción Resultado 1 Elaboración de diagramas de flujo a partir de los casos de uso. Un diagrama de flujo por cada caso de uso. 2 Identificación de todos los posibles caminos de ejecución. Listado de caminos de ejecución de cada diagrama de flujo. 3 Análisis y baremación de los caminos. Listado de caminos baremados. 4 Selección de caminos a probar. Listado de caminos que se convertirán en casos de prueba. 5 Elaboración de los casos de prueba a partir de los caminos seleccionados. Un caso de prueba por cada camino. Tabla 8. Descripción de los pasos para la obtención de casos de prueba. El primer paso consiste en dibujar un diagrama de flujo para cada caso de uso (Ilustración 7). Cada caso de uso tiene varios caminos de ejecución y cada camino es un caso de prueba potencial.. Este diagrama de flujo, que sigue una notación propia descrita en la propuesta, muestra todos los posibles caminos de ejecución del caso de uso. El segundo paso consiste en identificar todos los caminos posibles de ejecución. De cada camino se indica su identificador, el nombre del camino formado por los números o nombres de las ramas que cruza y descripción del camino donde se resume, en lenguaje natural, la secuencia completa de iteración del usuario con el sistema. Después se analizan y puntúan los caminos evaluando sus atributos. Esta propuesta deja abierta la posibilidad de analizar tantos atributos como se considere conveniente y propone dos atributos como ejemplo: la frecuencia con que se ejecuta el camino y el factor crítico del camino. El atributo frecuencia toma un valor entre 1, un camino muy poco frecuente y, 10, un camino muy frecuente y puntúa la repetición de un camino por parte de un usuario. Los caminos de ejecución más utilizados por los usuarios son los que obtendrán más puntuación en frecuencia. El atributo Factor crítico también toma un valor comprendido entre 1 y 10, y describe como de crítico puede ser el fallo de este camino. Un fallo en un camino que impida seguir trabajando con el sistema tendrá un valor muy alto en este atributo, mientras que un fallo en un camino que sea recuperable por el sistema con un gasto en recursos mínimo y sin ocasionar ninguna pérdida en la información del sistema tendrá un valor muy bajo. 19 2: Fallo de página 1: Acceso correcto 3: Nombre o contraseña en blanco 4: Nombre o contraseña introducidos 5: Nombre inexistente 6: Contraseña no válida 7: Acceso a página de inicio Ilustración 7. Ejemplo de diagrama de flujo de una página Web de login. La propuesta permite que se introduzcan nuevos atributos si se considera necesario y que se modifique la escala en que a cada uno se le asigna un valor. Una vez puntuados todos los atributos se obtiene, a partir de ellos, la valoración del camino, o factor del camino. La fórmula incluida en esta propuesta se detalla a continuación, en la tabla 9, aunque también se permite modificarla, por ejemplo asignándole un peso a cada atributo en función de su importancia. Factor del camino = Frecuencia + Factor crítico Tabla 9. Fórmula para la obtención del factor o valoración del camino de ejecución. Con esta valoración se seleccionan los caminos más significativos obteniendo un conjunto con el mínimo número caminos que garantice que se prueba completamente la funcionalidad crítica y que asegure que todas las ramas de ejecución han sido incluidas en, al menos, un camino. Cada camino seleccionado se convertirá en un caso de prueba. Por último para camino se obtiene su conjunto de escenarios de prueba. Esta propuesta define escenario de prueba como un camino de ejecución y un conjunto de 20 valores concretos para ese camino. Generalmente el caso de prueba de un camino de ejecución, tendrá más de un escenario de prueba. 2.6. Resumen de las propuestas estudiadas. Hemos descrito varias propuestas para obtener pruebas del sistema a partir de los requisitos en las fases tempranas del desarrollo de software, A continuación, en la tabla 10, se ofrece un breve resumen de cada una. Propuesta. Descripción. SCENT [2], [3] Ofrece un método muy completo para manipular y organizar los requisitos funcionales en escenarios de uso y derivar casos de prueba del sistema a partir de ellos. AGEDIS [5], [6]. Abarca tanto la elaboración de un prototipo del sistema como la generación y ejecución de las pruebas. Cuenta, además, con un conjunto de herramientas para automatizar el proceso. Generating Test Cases From use Cases [1]. Desarrolla un método basado en tres pasos para obtener un conjunto de casos de prueba del sistema a partir de casos de uso descritos en lenguaje natural. UML-Based Statistical Test Case Generation [4] Está orientada a obtener un conjunto de casos de prueba para realizar pruebas de carga en función de las probabilidades de cada caminos de ejecución para cada requisito funcional. Use Case Path Anmalisys [8]. Analiza todos los caminos de ejecución para un caso de prueba, los puntúa y selecciona el conjunto mínimo que deben traducirse a pruebas del sistema. Tabla 10. Descripción propuestas para la obtención de casos de prueba a partir de requisitos funcionales. En el apartado 5 se ofrece una comparativa entre estas propuestas sí como sus puntos fuertes y sus puntos débiles. 21 3. Descripción de casos de uso reales. Las únicas propuestas que incluyen referencias a casos de uso reales son: SCENT [9] y AGEDIS [11], por tanto estos van a ser los únicos casos de uso reales estudiados en este apartado. La propuesta Use Case Path análisis menciona dos proyectos basados en tecnología EJB donde ha sido utilizado, sin embargo no se indica ninguna referencia a documentación donde detalle el uso o donde ofrezca conclusiones. Hemos intentado ponernos en contacto con su autor mediante correo electrónico pero, aunque los correos no han sido devueltos, no hemos obtenido contestación. Tanto la propuesta Generación de casos de prueba a partir de casos de uso [1] como la propuesta UML-Based Statistical Test Case Generation [4] no mencionan ningún caso de uso real donde haya sido aplicado. 3.1. GLASS, aplicación práctica de SCENT. GLASS [9] es el nombre de un sistema de monitorización remota de sistemas embebidos de ingeniería eléctrica desarrollado por ABB Corporate Research Center en Baden-Daettwil, Suiza. Este sistema está basado en una arquitectura cliente-servidor de tres capas sobre TCP/IP y, más, basado en clientes y servidor web y el protocolo http. En la ilustración 8 se muestra una visión general de la arquitectura del sistema GLASS. La propuesta SCENT ha sido aplicada a dos subproyectos del sistema GLASS: uno de ellos es un sistema encargado de la monitorización remota de subestaciones en sistemas de distribución de energía eléctrica, el otro subproyecto es un sistema encargado de la monitorización de transformadores de alto voltaje [9]. En la ilustración 9 se muestra una captura del sistema en funcionamiento. Ilustración 8. Arquitectura del sistema GLASS 22 Ilustración 9. Ejemplo de la interfaz Web de GLASS. Cada subproyecto contaba con su propio grupo de desarrollo. Los desarrolladores de cada uno de los proyectos contaban con experiencia en lenguajes orientados a objetos y con una vaga idea sobre los escenarios y su uso en ingeniería del software. La formación ofrecida a cada uno de los grupos de desarrollo consistió en un taller de medio día de duración donde se presentó el procedimiento para creación de escenarios descrito en SCENT y se ilustró la formalización de escenarios escritos en lenguaje natural en diagramas de estados mediante un breve ejemplo Aunque en la documentación, [1] y [9] no se indica ni el número de desarrolladores ni el tiempo invertido en el desarrollo, a juzgar por el número de escenarios, 33 el primer sistema y 14 el segundo, estimamos que los proyectos fueron de tamaño pequeño con un número no superior a 6 u 8 desarrolladores. 3.1.1. Sistema de monitorización remota de subestaciones en sistemas de distribución de energía eléctrica. En este sistema ya se contaba con una especificación inicial, por lo que solo se desarrollaron partes del método para adaptarse a la implementación existente. En cambio en el segundo, se usó SCENT y su aproximación de escenarios desde el principio. 23 En este sistema, las pruebas del sistema se restringieron a mostrar las principales características para ser funcional (que hacían al sistema funcional) y garantizaba la obtención de un prototipo operacional para ser usado para demostraciones y formación. Para este primer sistema fueron necesarios 33 escenarios. No ha sido necesario un gran periodo de formación. El tiempo empleado en la formación del equipo de desarrollo en el proceso de SCENT fue de un día, con una primera sesión teórica y una segunda sesión práctica. Durante todo el proceso el equipo de desarrollo contó con supervisión de técnicos con un gran conocimiento de SCENT. 3.1.2. Sistema de monitorización de transformadores de alto voltaje. En este sistema, a diferencia del anterior, se aplicó la propuesta SCENT desde el principio. Sin embargo el tiempo dedicado a la formación de los desarrolladores fue similar al del sistema anterior. Los requerimientos para el nuevo sistema se recogieron en 14 escenarios. 3.1.3. Conclusiones. Ambos proyectos concluyeron de forma satisfactoria, siendo SCENT una herramienta fundamental de este éxito. De los casos prácticos se han extraído las siguientes conclusiones:  Los clientes apreciaron el uso de escenarios y permitió integrarlos en el proceso creando, refinando y validando escenarios.  El trabajo de creación y refinado de los escenarios es un proceso iterativo que discurre en paralelo al proceso de formalización. Algunos de los problemas aparecidos fueron:  La gestión de escenarios, que al estar escritos en lenguaje natural dificultaba mantenerlos consistentes.  La granularidad de los escenarios. Distinguir los que es parte de la especificación y la implementación, cuando no es necesario seguir refinando un escenario, etc.  Dificultad para modelar interacciones internas con los escenarios. Los escenarios están pensados principalmente para modelar interacciones con usuarios. 3.2. AGEDIS. 3.2.1. Descripción de 5 casos de estudio. Durante los 3 años de desarrollo de AGEDIS se han llevado a cabo 5 casos de estudio reales de la industria. Es cada uno de aplico métodos de prueba basados en modelos y herramientas a problemas reales en la industria. El requisito imprescindible para 24 la automatización del proceso de obtención y ejecución de los casos de prueba es elaborar un modelo del comportamiento del sistema. Los dos primeros casos de estudio se realizaron antes de que las herramientas estuvieron disponibles y su principal utilidad fue determinar los requisitos que dichas herramientas debían satisfacer. En concreto, el primer caso de estudio fue llevado a cabo por France Telecom usando la herramienta GOTCHA de IBM para generar conjuntos de pruebas para una implementación del protocolo de comunicaciones Pragmatic General Multicast (PGM). Este caso de estudio se centró en la interacción entre los distintos procesos durante la transmisión de datos. El segundo caso de estudio se aplicó sobre el proyecto TCP (Transit Computerization Project) para la automatización del intercambio de información realizado por la empresa Intrasoft. Se construyeron dos modelos, uno para su uso con la herramienta TGV y otro con la herramienta GOTCHA para poder comprobar las ventajas y diferencias de cada una y aplicarlas a las herramientas a desarrollar. El tercer caso de estudio se aplicó sobre el proyecto "WebSphere MQ Telemetry Java Classes", consistente en una interfaz de programación escrita en Java de un protocolo de mensajería. Este fue el primer caso de estudio donde se pudo comprara un modelo desarrollado con las herramientas AGEDIS con modelos desarrollados con la herramienta GOTCHA y RBP, resultando el modelo AGEDIS más apropiado para la comunicación entre desarrolladores y la identificación de las entradas y salidas. El cuarto caso de estudio se llevó a cabo después de que las herramientas fueran integradas bajo una interfaz gráfica de usuario común a todas ellas. El sistema a probar fue el sistema llamado E-Tendering desarrollado por Intrasoft, el cual proporciona la infraestructura necesaria para servicios de gestión basados en web. Fueron necesarias usar una serie de librerías adicionales para permitir la conexión entre Spider y el sistema que se estaba probando, lo cual demostró que era sencillo realizar esta integración El quinto y último caso de estudio se aplicó sobre NEMO, un middleware diseñado para distribuir mensajes a una lista de usuarios registrados utilizado como componente en varias aplicaciones de France Telecom. Se desarrolló un modelo muy sencillo, con un único servicio de distribución y dos receptores, sin embargo este modelo demostró que se puede obtener un gran número de casos de prueba válidos y aplicables a modelos de más complejidad a partir de modelos simples y que la vuelta a generar casos de prueba es automática cuando se modifica el modelo. 3.2.2. Conclusiones. En el desarrollo de pruebas basadas en modelos se comienza a obtener beneficios simplemente por el hecho de moldear. La creación de un modelo sirvió en los casos de estudio para resaltar inconsistencias en las especificaciones y, en varios casos, exponer fallos en fases muy tempranas del proceso de desarrollo. La naturaleza integrada de las herramientas y sus interfaces fue muy apreciada por los ingenieros, permitiéndoles desarrollar su trabajo de forma rápida y cómoda y aumentando su productividad. 25 El modelado de un sistema no es una tarea sencilla. Fuerza a los ingenieros a comprender el sistema que están modelando mucho mejor. Gracias a esto las pruebas basadas en modelos pueden detectar inconsistencias en requerimientos y diseño sin necesidad de ejecutar una sola prueba. Son necesarios más estudios para determinar cuando la construcción de modelos mediante herramientas gráficas, como AML, es mejor que mediante herramientas basadas en texto. 32 I – Valor inválido. V – Valor válido. Vacío – No se indica ningún valor. N/A – El valor que tenga es irrelevante. En el tercer punto, ya con todos los casos de prueba identificados, se revisan para asegurar su exactitud y localizar casos redundantes o la ausencia de algún caso. Por último, para cada escenario de caso de uso, se identifican sus valores de prueba. Los casos de prueba con sus valores de pruebas definitivos se recogen en la tabla 15. ID Escenarios Fallo de página Nombre Contraseña Resultado esperado 1 Acceso correcto HTTP Ok John Dough Carga de la página de inicio 2 Fallo de página Error 505 N/A N/A Mensaje de error. 3 Nombre o contraseña en blanco HTTP Ok John “” “” Dough Mensaje de error. El sistema solicita autentificación de nuevo. 4 Nombre no existente. HTTP Ok Jane N/A Mensaje de error. El sistema solicita autentificación de nuevo. 5 Contraseña no válida. HTTP Ok John Anyone Mensaje de error. El sistema solicita autentificación de nuevo. Tabla 15 Matriz de casos de prueba con sus valores de prueba. Con el conjunto escenarios de casos de uso y valores de prueba obtenidos se podrán realizar fácilmente las pruebas del sistema que garanticen que toda la funcionalidad recogida en este caso de uso ha sido correctamente implementada. Repitiendo este proceso por cada caso de uso obtendremos un catálogo con las pruebas del sistema necesarias para garantizar la calidad del sistema desarrollado. 4.4. Generación del conjunto de pruebas aplicando UML-Based Statistical Test Case Generation. El primer paso para aplicar esta propuesta es refinar el caso de uso detallando el camino principal de ejecución, caminos alternativos, combinaciones con otros casos de uso, precondiciones y postcondicones. Todos estos elementos ya los tenemos recogidos en el caso de uso del apartado 4.1, excepto relaciones con otros casos de uso que no estamos teniendo en cuenta para este ejemplo, por lo que podemos pasar al siguiente paso. 33 El segundo paso es transformar el caso de uso en un diagrama de estados. El diagrama obtenido es idéntico al diagrama de estados obtenido en el ejemplo de aplicación de la propuesta SCENT. Por motivos de comodidad se reproduce a continuación: Fallo del servidor Fallo de Página Nombre o contraseña en blanco Contraseña no válida Acceso a página de inicio Pantalla de acceso Comprobación de nombre y contraseña Nombre inexistente Nombre y contraseña introducidos Ilustración 12. Diagrama de estados del caso de uso. A continuación se transforma el diagrama de estados anterior en un gráfico de uso. En este ejemplo, el diagrama de estados ya incluye todo lo que exige un gráfico de uso, por lo que no es necesario realizar ninguna modificación sobre el diagrama de estados para transformarlo en gráfico de uso. El método principal para determinar la probabilidad de cada transición es estudiando los usos en el sistema. En este ejemplo se da la peculiaridad de que solo existe un único uso del sistema posible y todos los flujos alternativos de ejecución existen a consecuencia de errores que puedan surgir. Por lo tanto hemos determinado las probabilidades basándonos en nuestra propia experiencia. Las probabilidades asignadas a cada transición se muestran en la siguiente tabla. Estas probabilidades se recogen en la tabla 16. 34 Símbolo Descripción Probabilidad FP Fallo de página 0.05 I Nombre y contraseña introducidos 0.85 B Nombre o contraseña en blanco. 0.1 NI Nombre incorrecto. 0.1 NC Contraseña incorrecta 0.1 A Acceso a página de inicio 0.8 Tabla 16. Probabilidades de cada transición. A continuación, con la información de la tabla anterior, elaboramos el modelo de uso añadiendo las probabilidades a cada una de las transiciones del diagrama de estados. Este diagrama se muestra en la ilustración 13. Fallo del servidor FP : 0.05 B : 0.1 NC : 0.1 A : 0.8 Pantalla de acceso Comprobación de nombre y contraseña NI : 0.1 I : 0.85 Ilustración 13. modelo de uso. 35 Este modelo de uso es la base para pruebas aleatorias, las cuales deciden que camino de ejecución seguirán en función de las probabilidades de cada transición. El único requisito básico para un conjunto de pruebas aleatorias es que contemple el arco mínimo de ejecución, es decir, una secuencia de transiciones que recorran completamente el modelo en el menor número de pasos. En nuestro ejemplo esta secuencia es el camino en el que un actor introduce un nombre de usuario y clave corrector y accede a su página de inicio. Después de que el camino mínimo sea verificado, las pruebas aleatorias se generan. Cada caso de prueba es un camino aleatorio que recorre el modelo de uso, y que elige la transición que toma en cada estado que atraviesa, dependiendo de las probabilidades de cada transición. Por ejemplo, si ejecutáramos 1.000 pruebas aleatorias sobre el modelo de uso, aproximadamente 50 (el 0,05 o el 5 % ) deberían terminar en fallo de página. 4.5. Generación del conjunto de pruebas aplicando Use Case Path Analisys. El primer paso es dibujar el diagrama de flujo a partir de la secuencia normal de ejecución y las excepciones posibles del caso de uso. Este diagrama de flujo se muestra en la ilustración 5 en el punto 2.5. Por comodidad lo volvemos a reproducir a continuación, en la ilustración 14, incluyendo además un número único para cada rama, lo que nos facilitará la tarea a la hora de identificar los caminos.. La numeración de las ramas no corresponde con la numeración de las secuencia de ejecución o excepciones del caso de uso, ya que en una misma situación, por ejemplo la 4, pueden surgir varias excepciones cada una con su rama de ejecución propia. 2: Fallo de página 1: Acceso correcto 3: Nombre o contraseña en blanco 4: Nombre o contraseña introducidos 5: Nombre inexistente 6: Contraseña no válida 7: Acceso a página de inicio Ilustración 14 Diagrama de flujo del caso de uso. 36 A continuación se identifican todos los posibles caminos del diagrama de flujo, anotando por cada camino su descripción. En la tabla 17 se muestran todos los caminos identificados a partir del diagrama de flujo anterior. Id Nombre Descripción 1 2 Fallo de página por problemas del servidor. 2 1, 4, 7 Acceso correcto al sistema. 3 1, 3, 4, 7 Acceso correcto al sistema después de introducir un nombre o contraseña en blanco. 4 1, 4, 5, 7 Acceso correcto al sistema después de introducir un nombre inexistente. 5 1, 4, 6, 7 Acceso correcto al sistema después de introducir una contraseña no válida. 6 1, 4, 5, 6, 7 Acceso correcto al sistema después de introducir un nombre inexistente y una contraseña no válida. 7 1, 3, 4, 5, 6, 7 Acceso correcto al sistema después de introducir un nombre o contraseña en blanco, un nombre inexistente y una contraseña no válida. Tabla 17. Caminos posibles de ejecución. Existen más caminos posibles, como por ejemplo el camino 1, 3, 4, 5, 7, pero son repeticiones de los caminos ya mostrados en la tabla 13. A continuación se procede a analizar y baremar todos los caminos identificados. Para la baremación utilizaremos los dos factores indicados por la propuestas: la frecuencia y el factor crítico, sin embargo cambiaremos la escala de puntuación. Los valores posibles para ambos factores, en vez de estar comprendidos entre 1 y 10, estarán comprendidos dentro del rango de 1 a 5, ambos incluidos. Para el factor de frecuencia un valor de 1 significa un camino que se ejecuta con una frecuencia muy alta, en torno al 90% - 95%, un valor de 3 significa un camino que se ejecuta aproximadamente en la mitad de los recorridos del caso de uso, en torno al 50%, y un valor de 5 significa un camino que se ejecuta con una frecuencia muy baja, en torno al 5% - 10%. Para el factor crítico un valor de 1 significa que un fallo en este camino de ejecución puede ser recuperado por el sistema con un gasto mínimo de recursos y sin comprometer su información, un valor de 3 significa que un fallo en este camino es importante para el sistema, pero puede seguir trabajando, y un valor de 5 significa que un fallo en este camino es crítico para el sistema, o que puede provocar la caída total del mismo. 37 Una vez puntuados estos factores para cada camino, se obtiene el factor de cama camino según la fórmula de la tabla 7 (Valoración = Frecuencia + Factor crítico). A continuación, en la tabla 18, se muestra las puntuaciones de cada atributo y el valor del factor, o valoración, de cada camino identificado. Id Nombre Frecuencia Factor crítico Valoración 1 2 1 1 2 2 1, 4, 7 5 5 10 3 1, 3, 4, 7 2 5 7 4 1, 4, 5, 7 3 5 8 5 1, 4, 6, 7 4 5 9 6 1, 4, 5, 6, 7 2 5 7 7 1, 3, 4, 5, 6, 7 1 5 6 Tabla 18. Atributos y factor para cada camino. A continuación se ordenan los caminos en función de su valoración. Los caminos ordenador de mayor a menos valoración se muestran en la tabla 19. Id Nombre Frecuencia Factor crítico Valoración 2 1, 4, 7 5 5 10 5 1, 4, 6, 7 4 5 9 4 1, 4, 5, 7 3 5 8 3 1, 3, 4, 7 2 5 7 6 1, 4, 5, 6, 7 2 5 7 7 1, 3, 4, 5, 6, 7 1 5 6 1 2 1 1 2 Tabla 19. Caminos ordenador según su valoración. El camino principal, que en este ejemplo es el camino que recorre las ramas 1, 4 y 7, generalmente es el camino más importante, por lo tanto, como regla general, es el camino cuyo factor de 5 es el mayor de todos los caminos identificados para un caso de uso. En el ejemplo concreto que hemos seleccionado, todas las ramas alternativas, salvo la rama 2, vuelven al camino principal, por lo tanto cualquier fallo en estas ramas alternativas impide la consecución del camino principal. Por este motivo el factor crítico de estas ramas alternativas coincide con el factor crítico de la rama o camino principal. El siguiente paso es la selección de los caminos de los que deben derivarse casos de prueba, o que deben convertirse en casos de prueba. Para ello se seleccionan los caminos con una valoración más alta teniendo en cuenta que siempre ha de seleccionarse el camino principal de ejecución y que es necesario que todas las ramas sean comprobadas por un caso de prueba como mínimo. La lista de caminos seleccionados se muestra en la tabla 20. 38 Id Nombre Frecuencia Factor crítico Valoración Descripción 2 1, 4, 7 5 5 10 Acceso correcto al sistema. 5 1, 4, 6, 7 4 5 9 Acceso correcto al sistema después de introducir una contraseña no válida. 4 1, 4, 5, 7 3 5 8 Acceso correcto al sistema después de introducir un nombre inexistente. 3 1, 3, 4, 7 2 5 7 Acceso correcto al sistema después de introducir una contraseña no válida. 1 2 1 1 2 Fallo de página por problemas del servidor. Tabla 20. Caminos seleccionados para derivarlos en casos de prueba. Hemos elegido todos los casos de prueba menos el caso con id 6 y el caso con id 7, ya que todas las ramas de estos dos caminos ya se comprueban mediante los casos de prueba de los caminos con id 2, id 3, id 4 e id 5. El camino con id 1 también es elegido para derivar casos de prueba a pesar de tener la valoración más baja de entre todos los caminos, ya que, como hemos mencionado en el párrafo anterior, es necesario que todos los caminos se comprueben por, al menos, un caso de prueba. A continuación elaboramos un conjunto de pruebas que verifiquen los caminos seleccionamos podemos garantizar que se comprueba adecuadamente el caso de prueba. Para generar estos casos de prueba se elabora, por cada caso, un conjunto de escenarios de prueba, los cuales consisten en una tabla con datos válidos, que hagan pasar con éxito el caso de prueba, y datos inválidos, que hagan fallar el caso de prueba. A continuación, en la tabla 21 mostramos un conjunto de datos de prueba para el camino Id 6. En cursiva se muestran los valores válidos. Atributos 1 2 3 Nombre: Joh John Yane Jane Peterr Peter Contraseña: MyK Dough dough Dough Otoole Parker Notas: 1 nombre y contraseñas incorrectos y 1 correctos. Sustituir nombre y clave incorrecta por las correctas. 1 nombre y contraseñas incorrectos y 1 correctos. Sustituir nombre y clave incorrecta por las correctas. 1 nombre y contraseñas incorrectos y 1 correctos. Sustituir nombre y clave incorrecta por las correctas. Resultado esperado: Acceso a la página de inicio del usuario John. Acceso a la página de inicio de la usuario Jane. Acceso a la página de inicio del usuario Peter. Tabla 21. Datos de prueba. 39 5. Análisis y comparación de las propuestas descritas. 5.1. Puntos en comunes y comparación global. En las propuestas estudiadas se han extraído una serie de puntos comunes que se detallan a continuación: 1. El objetivo de todas las propuestas es obtener un conjunto completo de pruebas del sistema que permitan garantizar que el sistema software cumple con la especificación funcional dada, lo cual permite asegurar su calidad. 2. Todas parten de los requisitos funcionales del sistema y todas permiten comenzar a desarrollar los casos de prueba del sistema en cuanto se comience a disponer los requisitos funcionales. 3. Todas usan el análisis de los caminos posibles, bien mediante la descripción textual de los pasos del escenario o caso de uso, o mediante diagramas de estado. 4. Los requisitos funcionales no tienen que cumplir de principio ningún requisito formal. A partir de una breve descripción en lenguaje natural ya se puede comenzar a trabajar. 5. La derivación de pruebas del sistema a partir de los requisitos funcionales se realiza de manera automática y sistemática. Todas las propuestas son susceptibles de automatización, algunas más que otras, mediante herramientas software. 6. La aplicación de estas propuestas a los requisitos funcionales ayuda a validarlos, comprobando si son correctos y completos en las primeras fases de desarrollo. En la tabla 22 se muestra una comparativa entre las distintas propuestas basada en sus aspectos más relevantes. En la tabla 23 se describen las características que se han tenido en consideración para comparar las propuestas. SCENT Generación de casos de prueba a partir de CU. UML-Based Statistical Test Case Generation AGEDIS Use Case Path Analysis Nueva notación Sí (1) No No Sí (2) Sí Automatización completa No No No Sí No Casos prácticos. Sí No No Sí Sí Tipo de pruebas Fallos Fallos Fiabilidad (5) Fallos Nivel de automatización. Generación Generación Generación Ejecución Generación Uso de estándares Sí Sí Sí Sí Sí Automatización por herramientas Sí No Sí Sí Sí Herramientas de soporte No No No Sí No Dificultad de implantación Media Baja Media Alta Baja Ejemplos Sí Sí Sí Sí Sí Número de pasos 16+3 (3) 3 5 6 4+1 (4) Análisis y selección de casos de prueba Sí No No Sí Sí Tabla 22. Tabla comparativa de las propuestas. 40 (1) – Diagramas de dependencias de los escenarios. (2) – Lenguaje IF para modelar el sistema. (3) – 16 pasos para obtener los escenarios y 3 pasos para derivar casos de prueba a partir de ellos. (4) – 4 pasos para obtener el conjunto de caminos y un paso adicional para convertirlos en casos de prueba (5) – Los objetivos de las pruebas pueden ser encontrar fallos, realizar pruebas de carga, de fiabilidad, etc.. Nueva notación: Indica si la propuesta propone una notación o un conjunto de diagramas propio. Automatización completa Indica si las propuestas ofrecen un sistema de automatización total o dejan partes que deben realizarse a mano. Casos prácticos Indica si existen referencias de proyectos reales en los que la propuesta se haya llevado a la práctica. Tipo de pruebas Indica si los casos de uso generados están orientados a la búsqueda de fallos del sistema o a pruebas de fiabilidad. Nivel de automatización. Indica si la propuesta contempla también la automatización de la ejecución de pruebas o solo la automatización de la generación de casos de prueba. Uso de estándares Indica si la propuesta se basa en herramientas y diagramas ampliamente usados, como UML. Automatización por herramientas Indica si todo el proceso es susceptible de ser automatizado mediante herramientas software. La propuesta generación de casos de prueba a partir de los casos de uso trabaja siempre lenguaje natural, por lo que no es susceptible de automatización, aunque sí se pueden desarrollar herramientas que gestionen el proceso. Herramientas de soporte Indica si actualmente existen herramientas que den soporte a la metodología o automaticen sus pasos. Dificultad de implantación Una dificultad baja indica una propuesta muy sencilla de aplicar y para la que apenas se requiere preparación previa. Una dificultad media indica que existen elementos en la propuesta, nueva notación o algún proceso con alto grado de dificultad, que requiere preparación previa. Una dificultad alta indica que no se puede aplicar una propuesta sin un estudio detallado de todos sus elementos. En el siguiente apartado se detalla, para cada propuesta, el motivo de la dificultad de implantación asignada. Ejemplos Indica si la propuesta incluye ejemplos de los distintos pasos. Número de pasos Índica el número de pasos a dar para obtener un conjunto de pruebas del sistema. Análisis y selección de casos de prueba Indica si la propuesta describe como analizar y seleccionar solo aquellos casos de uso o caminos de ejecución relevantes para convertirlos en casos de prueba. Tabla 23. Descripción de las características evaluadas. 41 5.2. Principales puntos fuertes y puntos débiles de las propuestas estudiadas. A continuación se resumen los principales puntos fuertes y débiles de cada una de las propuestas analizadas. También, tomando como base los factores analizados en las tablas anteriores, se indica cual es el nivel de dificultad de implantación de cada una de las propuestas. En la ilustración 15 se resume el nivel de dificultad de todas las propuestas analizadas. Baja Media Alta AGEDIS SCENT G.C.P.D.C.U.** UML-Based STCG * Use Case Path Analisys. Ilustración 15 Dificultad de implantación de las propuestas analizadas. * UML-Based Statistical Test Case Generation. ** Generación De Casos De Prueba A Partir De Casos De Uso. 5.2.1. SCENT. Su principal punto fuerte es que ofrece un método muy completo para crear y organizar escenarios de uso. Además incluye dos referencias a proyectos reales donde se ha aplicado con éxito. Su principal punto débil es que es necesario realizar un trabajo muy extenso, 16 pasos, con los escenarios antes de poder generar casos de prueba. La dificultad de implantación es media porque incluye un nuevo modelo de diagrama, orientado a representar las dependencias que los requisitos funcionales tienen entre sí, que es necesario aprender.