Pruebas De Sistema

INTRODUCCION

La fase de pruebas del sistema tiene como objetivo verificar el sistema software para comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse varios tipos distintos de pruebas en función de los objetivos de las mismas. Algunos tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc. Este trabajo habla de las pruebas funcionales. Estas pruebas verifican que el sistema software ofrece a los actores humanos la funcionalidad recogida en su especificación.

Una de las técnicas más empleadas para la especificación funcional de sistemas software son los casos de uso. Las principales ventajas de los casos de uso son que ocultan los detalles internos del sistema, son rápidos de construir, fáciles de modificar y entender por los clientes y futuros usuarios del sistema y pueden aplicarse a distintos tipos de sistemas.

1. PRUEBAS FUNCIONALES

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.

Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones específicas para los cuales han sido creados, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la última etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción.

A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas.

Las pruebas funcionales en la mayoría de los casos son realizadas manualmente por el analista de pruebas, también es posible automatizar este tipo de pruebas utilizando herramientas como WinRunner o SilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con el aplicativo a probar. La automatización de pruebas puede resultar compleja y solo se recomienda en algunas funcionalidades específicas, por ejemplo en las pantallas que tendrán mayor uso, generalmente pantallas de ingreso de datos. Se debe tener en cuenta que el costo de estas licencias suele ser bastante elevado.

En la actualidad se utilizan pruebas unitarias en la mayoría de los aplicativos desarrollados, siendo las pruebas unitarias una primera etapa y las pruebas funcionales la segunda y definitiva en la que se da la conformidad del sistema.

Objetivo:

Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo la navegación, entrada de datos, procesamiento y obtención de resultados.

Metas de estas pruebas son:

Verificar el procesamiento, recuperación e implementación adecuada de las reglas del Negocio

Verificar la apropiada aceptación de datos.

Enfoque:

Los requisitos funcionales (Casos de Uso) y las reglas del negocio.

Caja Negra.

Se ejecuta cada caso de uso, flujo de caso de uso, o función, usando datos válidos e inválidos, para verificar lo siguiente:

• Que se aplique apropiadamente cada regla de negocio.

• Que los resultados esperados ocurran cuando se usen datos válidos.

• Que sean desplegados los mensajes apropiados de error y precaución cuando se usan datos inválidos.

2. DISEÑO DE CASOS DE USO E HISTORIA DE USUARIO

2.1. Conceptos Básicos del Diseño de Caso de Uso

Caso de Uso:

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Diagrama de Casos de Uso:

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

En la práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

Fig.1.1 Representa a un Diagrama de Caso de Uso

En la Fig.1.1 se describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles.

2.2. Elementos Principales de un Diseño de Caso de Uso

2.2.1. Actores

Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma

Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos.

Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores.

Los actores se representan con dibujos simplificados de personas, llamados en inglés “stick man” (hombres de palo).

Identificar a los actores es el primer paso para usar la técnica de casos de uso. Por ejemplo, en el sistema de pedidos nombrado anteriormente, sin conocer prácticamente ningún detalle sobre cómo funcionará, podemos decir que:

-El grupo de usuarios que ingrese pedidos al sistema será un actor.

-El grupo de usuarios que haga otras operaciones con los pedidos, como por ejemplo autorizarlos, cancelarlos y modificar sus plazos de entrega, será un actor.

-Todo grupo de usuarios que reciba ciertos informes del sistema, como por ejemplo estadísticas de ventas, será un actor.

Es común que los distintos actores coincidan con distintas áreas de la empresa en la que se implementará el sistema, o con jerarquías dentro de la organización (empleado, supervisor y gerente son distintos actores, si realizan tareas distintas).

2.2.2. Casos de Uso

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambia datos o control con el sistema, participando de ese caso de uso.

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo información de pedidos y no Generando información de pedidos.

Características de los Casos de Uso:

1) Están expresados desde el punto de vista del actor.

...