REPUBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA DEFENZA

UNIVERSIDAD NACIONAL EXPERIMENTAL DE LAS FUERZAS
ARMADAS BOLIVARIANAS
NUCLEO FALCON-EXTENCION PUNTO FIJO

INTEGRANTES:
ANDRADE OSLO
ARENA DARLIN
CEDEÑO JOSE
MENDEZ JOSE
RODRIGUES CARLOS

COMUNIDAD CARDON 14 DE OCTUBRE DE 2010

INTRODUCCION
 PRUEBA DE SISTEMAS

Cualquier pieza de software completo, desarrollado o adquirido, puede

verse como un sistema que debe probarse, ya sea para decidir acerca de
su aceptación, para analizar defectos globales o para estudiar aspectos
específicos de su comportamiento, tales como seguridad o rendimiento. A
éste tipo de pruebas donde se estudia el producto completo se les llama
Pruebas de Sistemas.
La prueba de sistemas usualmente es de caja negra, especialmente si
quien prueba no tiene acceso al código fuente del producto a probar, que
es lo más frecuente.

Los objetivos de las pruebas de sistemas son:

 Evaluar:
 Integralmente los elementos del modelo.
 Cada una de las partes que interactúan en el modelo.
 El resultado de la capacitación del recurso humano.
 Reforzar el entrenamiento mediante la simulación.
 Detectar posibles fallas para su inmediata corrección.
 Realizar pruebas de volumen y de funcionalidad de todos los
componentes.
 Simular fallas para observar el comportamiento del modelo.
 Identificar posibles mejoras para el modelo.
 Evaluar la prueba
 CASOS DE PRUEBA
En la Ingeniería del software, los casos de prueba o Test Case son un
conjunto de condiciones o variables bajo las cuáles el analista determinará
si el requisito de una aplicación es parcial o completamente satisfactorio.

Se pueden realizar muchos casos de prueba para determinar que un

requisito es completamente satisfactorio. Con el propósito de comprobar
que todos los requisitos de una aplicación son revisados, debe haber al
menos un caso de prueba para cada requisito a menos que un requisito
tenga requisitos secundarios. En ese caso, cada requisito secundario
deberá tener por lo menos un caso de prueba. Algunas metodologías como
RUP recomiendan el crear por lo menos dos casos de prueba para cada
requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el
otro debe realizar la prueba negativa.

Si la aplicación es creada sin requisitos formales, entonces los casos de

prueba se escriben basados en la operación normal de programas de una
clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una
entrada conocida y una salida esperada, los cuales son formulados antes
de que se ejecute la prueba. La entrada conocida debe probar una
precondición y la salida esperada debe probar una postcondición.

Formalmente, los casos de prueba escritos consisten principalmente

en tres partes con subdivisiones:

 Introducción/visión general contiene información general acerca de los

Casos de Prueba.
 Identificador es un identificador único para futuras referencias, por
ejemplo, mientras se describe un defecto encontrado.
  Caso de prueba dueño/creador es el nombre del analista o diseñador
de pruebas, quien ha desarrollado pruebas o es responsable de su
desarrollo.
 Versión la actual definición del caso de prueba.
 Nombre el caso de prueba debe ser un título entendible por personas,
para la fácil comprensión del propósito del caso de prueba y su campo
de aplicación.
 Identificador de requerimientos el cual está incluido por el caso de
prueba. También aquí puede ser identificador de casos de uso o
especificación funcional.
 Propósito contiene una breve descripción del propósito de la prueba, y
la funcionalidad que chequea.
 Dependencias
 Actividades de los casos de prueba
 Ambiente de prueba/configuración contiene información acerca de la
configuración del hardware o software en el cuál se ejecutará el caso de
prueba.
 Inicialización describe acciones, que deben ser ejecutadas antes de
que los casos de prueba se hayan inicializado. Por ejemplo, debemos
abrir algún archivo.
 Finalización describe acciones, que deben ser ejecutadas después de
realizado el caso de prueba. Por ejemplo si el caso de prueba estropea
la base de datos, el analista debe restaurarla antes de que otro caso de
prueba sea ejecutado.
 Acciones pasos a realizar para completar la prueba.
 Descripción de los datos de entrada
 Resultados
 Resultados esperados contiene una descripción de lo que el analista
debería ver tras haber completado todos los pasos de la prueba
 Resultados reales contienen una breve descripción de lo que el
analista encuentra después de que los pasos de prueba se hayan
 completado. Esto se sustituye a menudo con un Correcto/Fallido. Si un
caso de prueba falla, frecuentemente la referencia al defecto implicado
se debe enumerar en esta columna.

Metodología R.U.P
La metodología RUP, llamada así por sus siglas en inglés Rational Unified
Process, divide en 4 fases el desarrollo del software:
 Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
 Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
 Construcción, En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
 Transmisión, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual

consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos
de una iteración se establecen en función de la evaluación de las iteraciones
precedentes.
PRUEBAS DE SOFTWARE
Las pruebas de software, en inglés testing son los procesos que permiten verificar
y revelar la calidad de un producto software. Son utilizadas para identificar
posibles fallos de implementación, calidad, o usabilidad de un programa de
ordenador o videojuego. Básicamente es una fase en el desarrollo de software
consistente en probar las aplicaciones construidas.
Las pruebas de software se integran dentro de las diferentes fases del ciclo del
software dentro de la Ingeniería de software. Así se ejecuta un programa y
mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas

que permitan comprobar el grado de cumplimiento respecto de las
especificaciones iníciales del sistema.
 “El testing puede probar la presencia de errores pero no la ausencia de ellos”
Pruebas de carga
Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se
realiza generalmente para observar el comportamiento de una aplicación bajo una
cantidad de peticiones esperada. Esta carga puede ser el número esperado de
usuarios concurrentes utilizando la aplicación y que realizan un número específico
de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar
los tiempos de respuesta de todas las transacciones importantes de la aplicación.
Si la base de datos, el servidor de aplicaciones, etc también se monitorizan,
entonces esta prueba puede mostrar el cuello de botella en la aplicación.

Prueba de estrés
Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el
número de usuarios que se agregan a la aplicación y se ejecuta una prueba de
carga hasta que se rompe. Este tipo de prueba se realiza para determinar la
solidez de la aplicación en los momentos de carga extrema y ayuda a los
administradores para determinar si la aplicación rendirá lo suficiente en caso de
que la carga real supere a la carga esperada.

Prueba de estabilidad (soak testing)

Esta prueba normalmente se hace para determinar si la aplicación puede aguantar
una carga esperada continuada. Generalmente esta prueba se realiza para
determinar si hay alguna fuga de memoria en la aplicación.

Pruebas de picos (spike testing)

La prueba de picos, como el nombre sugiere, trata de observar el comportamiento
del sistema variando el número de usuarios, tanto cuando bajan, como cuando
tiene cambios drásticos en su carga. Esta prueba se recomienda que sea
realizada con un software automatizado que permita realizar cambios en el
número de usuarios mientras que los administradores llevan un registro de los
valores a ser monitoreados
 CAJA BLANCA
Se denomina cajas blancas a un tipo de pruebas de software, éstas se basan en
el conocimiento de la lógica interna del código. Las pruebas contemplan los
distintos caminos que se pueden generar gracias a las estructuras condicionales,
a los distintos estados del mismo, etc.
En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse
a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería
dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser
que los métodos de una clase suelen ser menos complejos que los de una función
de programación estructurada).

CAMINO BASICO
Este método permite generar casos de prueba a través de una medida de la
complejidad lógica del programa a probar. De algún modo, determina cuáles son
todos los caminos posibles a la hora de ejecutar el programa.
Se tratará de crear casos de prueba que permitan ejecutar como mínimo una vez
cada uno de esos caminos.
Este método utiliza un simbolismo especial que permite transformar las
instrucciones de pseudocódigo de un programa, en una especie de grafo.
Con el método del camino básico, nos aseguramos que todos los caminos lógicos
del programa se recorren, pero no podemos decir nada a nivel de datos.

PRUEBA DE ESTRUCTURAS DE CONTROL

Este método de prueba pretende controlar qué ocurre con las diferentes
estructuras de datos declaradas (variables simples, matrices, etc).
Para ello, utiliza una serie de mecanismos que van trazando el recorrido de cada
una de las estructuras declaradas. Se obtienen unos caminos que se debe
garantizar que se recorran para demostrar que esas variables se usan. Esta
prueba determinará errores del tipo: variables no usadas, incluso variables no
declaradas o usos erróneos de variables.
Muchos de los errores de software provienen de las estructuras condicionales y de
las estructuras iterativas. Por ese motivo, adicionalmente al método del camino
básico se pueden utilizar pruebas específicas para condiciones y pruebas
específicas para bucles.

PRUEBAS DE CONDICIONES:
Este método de prueba revisa las condiciones que existen en sentencias del tipo
if (estructura condicional o alternativa).
Esas condiciones pueden ser simples:
exp1 operador-relacional exp2.
O bien pueden ser compuestas uniendo en este caso varias condiciones simples
mediante operadores lógicos: and, or y not:
cond1 and cond2 or not(cond3)
La prueba de ramificaciones.
Es muy simple y únicamente, trata los dos casos posibles en una expresión lógica:
que toda la condición (completa) sea true o que sea false.
La prueba de dominio.
Es más complejo y dice, que para una condición formada por n variables
(condiciones simples), serán necesarios 2 casos de prueba.

PRUEBA DE BUCLES:
Este método trata de comprobar el buen funcionamiento de los bucles. Cuando
tratamos con estructuras iterativas o bucles, habrá que diferenciar según el tipo de
bucle que estamos probando.
 Pruebas para bucles simples
 Pruebas para bucles anidados
 Pruebas para bucles concatenados
 Pruebas para bucles NO estructurados PRUEBAS DE FLUJO DE DATOS
 CAJA NEGRA
Este tipo de pruebas no considera la codificación dentro de sus parámetros a
evaluar, es decir, que no están basadas en el conocimiento del diseño interno del
programa. Estas pruebas se enfocan en los requerimientos establecidos y en la
funcionalidad del software

Estudia el punto de vista de las entradas y salidas o respuestas que produce, sin
tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra
nos interesará su forma de interactuar con el medio que le rodea (en ocasiones,
otros elementos que también podrían ser cajas negras) entendiendo qué es lo que
hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben
estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio,
no se precisa definir ni conocer los detalles internos de su funcionamiento.
 MODELOS DE PRUEBA

Modelo en Cascada (Bennington 1956): El más conocido, está basado en el

ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las
siguientes actividades

Ingeniería y Análisis
del Sistema

Análisis de los
Requisitos

Diseño

Codificación

Prueba

Mantenimiento
Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un
sistema mayor el trabajo comienza estableciendo los requisitos de todos los
elementos del sistema y luego asignando algún subconjunto de estos requisitos al
software.

Análisis de los requisitos del software: el proceso de recopilación de los requisitos

se centra e intensifica especialmente en el software. El ingeniero de software
(Analistas) debe comprender el ámbito de la información del software, así como la
función, el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del

programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño traduce los
requisitos en una representación del software con la calidad requerida antes de
que comience la codificación.

Codificación: el diseño debe traducirse en una forma legible para la maquina. El

paso de codificación realiza esta tarea. Si el diseño se realiza de una manera
detallada la codificación puede realizarse mecánicamente.

Prueba: una vez que se ha generado el código comienza la prueba del programa.
La prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente.

Los cambios ocurrirán debido a que hayan encontrado errores, a que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
Modelo V (Ministerio de Defensa de Alemania, 1992): El Modelo V tiende a
ser muy relacionado con el Modelo de Cascada puesto que es una evolución del
mismo.

Los planes de prueba son OPERACION

el nexo entre el desarrollo
Y MANTENIMIENTO
y la verificación

ANALISIS DE Plan de
PRUEBA DE
Pruebas
REQUERIMIENTOS de Aceptación ACEPTACION
Validar requerimientos

Plan de
DISEÑO DEL
Pruebas PRUEBA DEL

SISTEMA
del Sistema
SISTEMA
Verificar diseño

DISEÑO Plan de PRUEBA DE

Pruebas
DETALLADO de Integración INTEGRACION

IMPLEMENTACION

DE PROGRAMAS Y

PRUEBA UNITARIA

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra

mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las
etapas de la mitad anterior.
Se puede identificar una ventaja principal con respecto al Modelo Cascada
más simple, y se refiere a que este modelo involucra chequeos de cada una de las
etapas del modelo de cascada
Modelo Iterativo

Modelo Prototipo

Este modelo consiste en un procedimiento que permite al equipo de desarrollo

diseñar y analizar una aplicación que representa el sistema que sería
implementado (McCracken y Jackson, 1982). Dicha aplicación, llamada prototipo,
está compuesta por los componentes que se desean evaluar (i.e. las funciones
principales). Las etapas del modelo son:
 Investigación preliminar.
 Colecta y refinamiento de los requerimientos y proyecto rápido:
 Análisis y especificación del prototipo.
 Diseño y construcción del prototipo.
 Evaluación del prototipo por el cliente.
 Renacimiento del prototipo.
 Diseño técnico.
 Programación y test.
 Operación y mantenimiento.

Para construir un prototipo del software se aplican los siguientes pasos:

PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar

es un buen candidato para construir un prototipo.
Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es
esencial que:
1) El cliente participe en la evaluación y refinamiento del prototipo, y 2) el cliente
sea capaz de tomar decisiones de requerimientos de una forma oportuna.
Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia
en la eficacia del prototipo.

PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una

representación abreviada de los requerimientos.
Antes de que pueda comenzar la construcción de un prototipo, el analista debe
representar los dominios funcionales y de información del programa y desarrollar
un método razonable de partición. La aplicación de estos principios de análisis
fundamentales, pueden realizarse mediante los métodos de análisis de
requerimientos.

PASO 3. Después de que se haya revisado la representación de los

requerimientos, se crea un conjunto de especificaciones de diseño abreviadas
para el prototipo.
El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin
embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a
nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño
procedimental detallado.
PASO 4. El software del prototipo se crea, prueba y refina.
Idealmente, los bloques de construcción de software preexisten se utilizan para
crear el prototipo de una forma rápida. Desafortunadamente, tales bloques
construidos raramente existen.
Incluso si la implementación de un prototipo que funcione es impracticable, es
escenario de construcción de prototipos puede aun aplicarse. Para las
aplicaciones interactivas con el hombre, es posible frecuentemente crear un
prototipo en papel que describa la interacción hombre-maquina usando una serie
de hojas de historia.

PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual
"conduce la prueba" de la aplicación y sugiere modificaciones.
Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el
cliente puede examinar una representación implementada de los requerimientos
del programa, sugerir modificaciones que harán al programa cumplir mejor las
necesidades reales.

PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los

requerimientos estén formalizados o hasta que el prototipo haya evolucionado
hacia un sistema de producción.
El paradigma de construcción del prototipo puede ser conducido con uno o dos
objetivos en mente: 1) el propósito del prototipado es establecer un conjunto de
requerimientos formales que pueden luego ser traducidos en la producción de
programas mediante el uso de métodos y técnicas de ingeniería de programación,
o 2) el propósito de la construcción del prototipo es suministrar un continuo que
pueda conducir al desarrollo evolutivo de la producción del software. Ambos
métodos tienen sus meritos y ambos crean problemas.
 MODELO PROTOTIPO

MODELOS DE PRUEBAS ORIENTADAS A OBJETOS

El grado al que se han completado y la consistencia de las representaciones

orientadas a objetos deben evaluarse a medida que se construyen.

ASPECTOS ESTRATÉGICOS:
 Especificar los requisitos del producto de manera cuantificable antes de que
empiecen las pruebas.
 Establecer explícitamente los objetivos de la prueba.
 Comprender cuáles son los usuarios del software y desarrollar un perfil
para cada categoría de usuario.
 Desarrollar un plan de prueba que destaque la "prueba de ciclo rápido".
 Construir un software "robusto" diseñado para probarse a sí mismo.
 Usar revisiones técnicas formales y efectivas como filtro previo a la prueba.
CONCLUSION
 BIBLIOGRAFIA

http://es.wikipedia.org/wiki/Pruebas_de_software

http://my.opera.com/pelican0/blog/show.dml/564829
http://www.xuletas.es/ficha/camino-basico/