Pruebas De Sistema
Enviado por NightLord • 5 de Julio de 2013 • 9.037 Palabras (37 Páginas) • 454 Visitas
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
...