Plagio

Mostrar el documento en pdf

Fases de prueba de Software

Para ver el documento en pdf

Pruebas de software son las investigaciones empiricas y tecnicas cuyo objetivo es proporcionar informacion objetiva e independiente sobre la calidad del producto, es una actividad mas en el proceso de control de calidad
Las pruebas son basicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del ripo de pruebas estas actividades podran ser implementadas en cualquier momento de dicho proceso de desarrollo.

Caracteristicas y fases de prueba de sofware
La prueba de software se puede definir como una actividad en la cual un sistema o uno de sus componentes se ejecuta en curcunstancias previamente espeficicadas( que cumpla con todos los requisitos del cliente). Seguidamente se realiza un proceso de evaluacion en el que los resultados obtenidos se comparan con los resultados esperados para localizar fallos en el software. Estos fallos conducen a un proceso de depuracion en el que es necesario identificar la falta asociada con cada fallo y corregir, pudiendo dar lugar a una nueva prueba. Como resultado final se puede obtener una determinada prediccion de fiabilidad o un cierto nivel de confianza en el software probado

El objetivo de las pruebas no es asegurar la ausencia de defectos de un software, unicamente puede demostrar que existen defectos.
El objetivo es diseñar y hacer exhaustivamente pruebas que nos permitan encontrar el mayor numero de errores haciendolo con la menor cantidad de tiempo y esfuerzo.

Para encontrar el mayor numero de fallos en el sistema sera necesario que sean realizadas por un equipo ajeno al que desarrollo el software ya que si el ingeniero que creo el sistema tratara siempre de demostrar que su software funciona y las pruebas correctivas no tendran mucho exito

Tareas a realizar para probar tu software

•  Diseño de las pruebas
  identificar las distintas tecnicas de pruebas que se utilizaran para probar el software
•  
• Generacion de los casos de prueba
  los casos de prueba son los datos de entrada que se introduciran en el software  para probarlo y retornaran resultados con un objetivo en particular
•  
• Definicion de los procedimientos de prueba
  Especifica como se va a llevar el proceso de prueba, quien lo va a realizar y cuando
•  
• Ejecucion de prueba
  despues de haber aplicado los casos de prueba se van a comparar los datos retornados por el programa y se comparan con los resultados esperados
•  
• informe de prueba
• con el resultado de los casos de prueba se identificaran cuales resultaron satisfactorios en caso de ser diferente a lo esperado, se identificaran los fallos

Tecnicas y Herramientas de prueba
Las tecnicas de evaluacion dinamica o prueba proporcionan distintos criterios para generar casos de prueba que provoquen fallos en los programas
Las Tecnicas se agrupan en :

• Tecnicas de caja blanca o estructurales que se bansan en un minucioso examen de los detalles procedimentales del codigo a evaluar, por lo que es necesario conocer la logica del programa
•  
• Técnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz del
  programa a probar, entendiendo por interfaz las entradas y salidas de dicho programa.
   
• No es necesario conocer la lógica del programa, únicamente la funcionalidad que debe
   realizar. 

Pruebas de Caja Blanca o Estructurales
A este tipo de técnicas se le conoce también como Técnicas de Caja Transparente o de Cristal.
Este método se centra en cómo diseñar los casos de prueba atendiendo al comportamiento
interno y la estructura del programa. Se examina así la lógica interna del programa sin
considerar los aspectos de rendimiento.
El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez,
todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como
falsa.

Pruebas de Caja Negra o Funcionales
También conocidas como Pruebas de Comportamiento, estas pruebas se basan en la
especificación del programa o componente a ser probado para elaborar los casos de prueba. El
componente se ve como una “Caja Negra” cuyo comportamiento sólo puede ser determinado
estudiando sus entradas y las salidas obtenidas a partir de ellas. No obstante, como el estudio de
todas las posibles entradas y salidas de un programa sería impracticable se selecciona un
conjunto de ellas sobre las que se realizan las pruebas. Para seleccionar el conjunto de entradas
y salidas sobre las que trabajar, hay que tener en cuenta que en todo programa existe un
conjunto de entradas que causan un comportamiento erróneo en nuestro sistema, y como
consecuencia producen una serie de salidas que revelan la presencia de defectos. Entonces, dado
que la prueba exhaustiva es imposible, el objetivo final es pues, encontrar una serie de datos de
entrada cuya probabilidad de pertenecer al conjunto de entradas que causan dicho
comportamiento erróneo sea lo más alto posible.
Al igual que ocurría con las técnicas de Caja Blanca, para confeccionar los casos de prueba de
Caja Negra existen distintos criterios. Algunos de ellos son:

•  Particiones de Equivalencia.
•  Análisis de Valores Límite.
• Métodos Basados en Grafos.
• Pruebas de Comparación.
• Análisis Causa-Efecto.

Proceso de la Prueba de Software
La estrategia que se ha de seguir a la hora de evaluar dinámicamente un sistema software debe
permitir comenzar por los componentes más simples y más pequeños e ir avanzando
progresivamente hasta probar todo el software en su conjunto. Más concretamente, los pasos a
seguir son:
1. Pruebas Unitarias. Comienzan con la prueba de cada módulo.

2. Pruebas de Integración. A partir del esquema del diseño, los módulos probados se vuelven a probar combinados para probar sus interfaces.

3. Prueba del Sistema. El software ensamblado totalmente con cualquier componente
hardware que requiere se prueba para comprobar que se cumplen los requisitos
funcionales

4. Pruebas de Aceptación. El cliente comprueba que el software funciona según sus expectativas.

Casos de uso en diagramado UML

Para verlo en Pdf http://www.slideshare.net/MarcoSk81/casos-de-uso-21797025

Casos de Uso
Un caso de uso describe una interaccion con los actores como secuencia de mensajes entre el sistema y uno o mas actores.

Es una unidad coherente de funcionalidad, proporcionanda por una unidad del sistema y expresada por secuencias de mensajes intercambiados por la unidad del sistema y uno o mas actores.


El proposito de un caso de uso es definir una pieza de comportamiento coherente, sin revelar la estructura interna del sistema en pocas palabras estamos describiendo el comportamiento o como funciona la unidad de software que ocupara nuestro usuario

Los casos de uso sirven mas que nada para capturar el comportamiendo deseado del sistema sin tener que especificar como se implementa ese comportamiento, se usa como medio de comprension del sistema para desarrolladores, usuarios finales y expertos del dominio y ayudan a validar la arquitectura y verificar el sistema en en el transcurso del desarrollo.

Un aso de uso es iniciado por un actor. A partir de ese momento, ese Actor, junto con otros actores intercambian datos o control con el sistema participando de ese caso de uso

Los casos de Uso tienen las siguientes caracteristicas :

• Estan expresados desde el punto de vista del actor
• Se documentan con texto informal 
• Describen tanto lo que hace el actor como lo que hace el sistema cuando interactua con el, aunque el enfasis esta pueso en la interaccion son iniciados por un unico actor 
• Estan acotados al uso de una determinda funcionalidad claramente diferenciada del sistema

Actores
 Un actor es una agrupacion de personas, sistemas o maquinas que interactuan con el sistema que estamos constuyendo. Por ejemplo, para una empresa que recibe pedidos en forma telefonica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, se pueden hacer las mismas cosas con el sistemas son considerados un unico actor como : Empleado de ventas .

Los actores son externos al sistema que vamos a desarrollar. Por lo tantom al identificar actores estamos empezando a delimitar el sistema, y a definir su alcanze. Definir el alcanze del sistema es el primer objetivo del analista, ya que un proyecto sin alcanze no podra nunca alcnzar sus objetivos.

La diferencia entre un usuario y actor.
un actores una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta dorma, un usuario puede acceder al sistema como distintos actores.

En pocas palabras un actor representa

•  Representa un conjunto de roles que los usuarios de los casos juegan al interactuar con estos
• Representan un rol que es jugado por una persona, un dispositivo de hardware u otro sistema que interactue con nuestro sistema
• se puede definir en categorias generales de actores y especializarlos atraves de relaciones e generalizaio
• Un actor y un caso de uso se pueden comunicar a traves de una asociasion en donde cada uno de ellos pueden enviar y recibir mensajes

Extension
La extension se utiliza para estructurar y relacionar casos de uso, la cual especifica como un caso de uso puedo insertarse en otro para extender la funcionalidad del anterior. El caso de uso donde se insertara la nueva funcionalidad debe ser un flujo completo, por lo cual este es independiente del caso de uso a insertarse. El caso de uso inicial no requiere consideraciones adicionales al caso de uso a ser insertado, unicamente se espeficifica su punto de insercion.

La extension se utiliza para modelar las secuencias de eventos opcionales de casos de uso, que al manejarse de manera independiente pueden ganarse o eliminarse del sistema de manera modular

Inclusión
La inclusion se define como una seccion de un caso de uso que es parte obligatoria del caso de uso basico.
El caso de uso donde se insertara la funcionalidad depende del caso de uso a ser insertado. Esta relacion se etiqueta con incluye(include)

Generalizacion
 Apoya la reutilizacion de los casos de uso. Mediante la relacion de generalizacion es necesario describir las partes similares una sola vez, en lugar de repetirlas para todos los casos de uso con un comportamiento comun.
Los casos de uso extraidos se conocen como casos de uso abstractos, ya que no seran instanciados independientemente, y servirian solo para describir partes que son comunes a otros casos de uso. Los casos de uso que realmente seran instanciados se llaman casos de uso concretos.