ECYS USAC.

Vacaciones Junio 2015

Anlisis y Diseo de Sistemas II.
Ing. Luis Alberto Arias Solrzano

Mydelin Stephanie Valladares Lima 201113845

Irwin Guillermo Hernndez Guerra 201047998
lvaro Obrayan Hernndez Garca 200714982
Erwin Alejandro Gonzlez Bonilla 200212458

TAREA No. 2
Pruebas de Caja Blanca
Consiste en realizar pruebas para verificar que lneas especficas de cdigo
funcionan tal como est definido.
La prueba de la caja blanca es un mtodo de diseo de casos de prueba que
usa la estructura de control del diseo procedimental para derivar los casos de
prueba.
Prueba de ruta bsica: Permite conocer una medida de la complejidad
lgica de un diseo procedural y usar esta medida como gua para
definir un conjunto bsico de rutas de ejecucin.
Prueba de condicin: Mtodo que ejercita las condiciones lgicas
contenidas en un mdulo del programa.
Prueba del flujo de datos: Mtodo que selecciona rutas de prueba de
acuerdo con las ubicaciones de las definiciones y usos de las variables
del programa.
Prueba de bucles: Se concentra exclusivamente en la validez de la
construccin de bucles
Pruebas de Caja Negra
En este tipo de prueba, tan slo, podemos probar dando distintos valores a las
entradas. Este tipo de prueba se centra en los requisitos funcionales del
software y permite obtener entradas que prueben todos los flujos de una
funcionalidad (casos de uso).
Prueba basada en fallas
Prueba basada en escenarios
Prueba de arquitectura cliente/servidor
Pruebas de servidor
Pruebas de base de datos
Pruebas de transaccin
Pruebas de comunicacin de red
Prueba de documentacin

Pruebas de Humo
Es un testing rpido su objetivo es verificar, con pruebas sencillas y que
demanden poco tiempo, que ciertos caminos de la aplicacin funcionen
correctamente.
Las pruebas de humo ponen de manifiesto si el software est o no lo
suficientemente estable para afrontar un ciclo de pruebas y son un paso previo
a la ejecucin del plan de pruebas diseado previamente.
Conexin a la BD.
Las pruebas de humo son tiles a la hora de determinar si un sistema va
cumpliendo lo requerido, as como para verificar una vez ya en
produccin, que luego de una instalacin nueva o de la recuperacin de
una falla catastrfica el sistema se ha devuelto a su pleno
funcionamiento.
Pruebas Unitarias
Se aplican a un componente del software. Podemos considerar como
componente (elemento indivisible) a una funcin, una clase, una librera, etc.
Probar un mtodo en el cdigo.
Probar una funcionalidad.
Pruebas de Rendimiento
Las pruebas de rendimiento son las pruebas que se realizan, desde una
perspectiva, para determinar lo rpido que realiza una tarea un sistema en
condiciones particulares de trabajo. Tambin puede servir para validar y
verificar otros atributos de la calidad del sistema.
Los tipos de software que existen para realizar las diversas pruebas son:

Apache JMeter
NeoLoad
LoadRunner
LoadUI
WebLOAD

 WAPT
Loadster
LoadImpact
Rational Performance Tester
Testing Anywhere
OpenSTA
QEngine (ManageEngine)
Loadstorm
CloudTest
Httperf
Existen diversas aplicaciones en el medio para verificar el rea de rendimiento
que son las siguientes
Pruebas de carga
Este es el tipo ms sencillo de pruebas de rendimiento. Una prueba de
carga se realiza generalmente para observar el comportamiento de
una aplicacin bajo una cantidad de peticiones esperada. Esta carga
puede ser el nmero esperado de usuarios concurrentes utilizando la
aplicacin y que realizan un nmero especfico de transacciones durante
el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de
respuesta de todas las transacciones importantes de la aplicacin. Si
la base de datos, el servidor de aplicaciones, etc... Tambin se
monitorizan, entonces esta prueba puede mostrar el cuello de botella
en la aplicacin.
Prueba de estrs
Esta prueba se utiliza normalmente para romper la aplicacin. Se va
doblando el nmero de usuarios que se agregan a la aplicacin y se
ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se
realiza para determinar la solidez de la aplicacin en los momentos de
carga extrema y ayuda a los administradores para determinar si la
aplicacin 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 aplicacin
puede aguantar una carga esperada continuada. Generalmente esta

prueba se realiza para determinar si hay alguna fuga de memoria en la

aplicacin.
Pruebas de picos (spike testing)
La prueba de picos, como el nombre sugiere, trata de observar el
comportamiento del sistema variando el nmero de usuarios, tanto
cuando bajan, como cuando tiene cambios drsticos en su carga. Esta
prueba se recomienda que sea realizada con un software automatizado
que permita realizar cambios en el nmero de usuarios mientras que los
administradores llevan un registro de los valores a ser monitorizados.
Pre-requisitos para las pruebas de carga
Un desarrollo estable de la aplicacin instalado en un entorno lo ms
parecido al de produccin.
El entorno de pruebas de rendimiento no debe cruzarse con pruebas de
aceptacin de usuarios ni con el entorno de desarrollo. Esto es tan
peligroso que si las pruebas de aceptacin de usuarios, o las pruebas de
integracin o cualquier otra prueba se ejecutan en el mismo entorno,
entonces los resultados no son fiables. Como buena prctica, siempre es
aconsejable disponer de un entorno de pruebas de rendimiento lo ms
parecido como se pueda al entorno de produccin.
Pruebas de Integracin
Las pruebas de integracin es la fase en pruebas de software en el que los
mdulos de software individuales se combinan y se ensayaron como un grupo.
Se produce despus de que las pruebas unitarias y antes de las pruebas de
validacin. Las pruebas de integracin tiene como sus mdulos de entrada que
han sido probados unidad, en agregados ms grandes grupos, aplica pruebas
definidas en un plan de pruebas de integracin de los agregados, y ofrece
como salida el sistema integrado listo para la prueba del sistema.
Algunos diferentes tipos de pruebas de integracin son Big Bang, de arriba
hacia abajo y de abajo hacia arriba. Otros patrones de integracin son:
Integracin colaboracin, la integracin del esqueleto, Capa de integracin,
integracin Client/Server Integration Services Distributed e Integracin de alta
frecuencia.

Pruebas de Diseo (Accesibilidad)

Las pruebas de diseo son aquellas que se ejecutan para verificar el correcto
funcionamiento de la lgica de nuestro software como tambin de los diversos
modelos que tengamos que analizar y testear por ende las pruebas de diseo
son de las ultimas en ejecutarse para poder verificar el correcto
funcionamiento de cada uno de nuestros mdulos
Pruebas Funcionales
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 especficas para los cuales han sido creados, es
comn 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
produccin.
El objetivo de la prueba funcional es validar cuando el comportamiento
observado del software probado cumple o no con sus especificaciones. La
prueba funcional toma el punto de vista del usuario. Las funciones son
probadas ingresando las entradas y examinando las salidas. La estructura
interna del programa raramente es considerada. Para realizar pruebas
funcionales, la especificacin se analiza para derivar los casos de prueba.
Tcnicas como particin de equivalencia, anlisis del valor lmite, grafo causaefecto y conjetura de errores son especialmente pertinentes para las pruebas
funcionales. Se deben considerar condiciones invlidas e inesperadas de la
entrada y tener en cuenta que la definicin del resultado esperado es una
parte vital de un caso de la prueba. El propsito de la prueba funcional es
mostrar discrepancias con la especificacin y no demostrar que el programa
cumple su especificacin.
El alcance de las pruebas nos dice qu funcionalidades se van a probar y cules
no. Para poder definir el alcance, se divide el sistema en mdulos,
componentes o subsistemas, no todos los componentes sern probados con
la misma importancia y pueden existir componentes que queden fuera del
alcance de las pruebas. Cada componente agrupa varias funcionalidades, se
dividen las funcionalidades hasta un nivel en el que sea posible definir el
alcance. Luego de esto, se analizan las funcionalidades, dando como resultado

un Inventario de Pruebas. En la Tabla 1 se muestra un ejemplo de la

priorizacin de las funcionalidades. El inventario es una lista de las
funcionalidades del producto de software. Para cada funcionalidad se asigna:
Identificador: Referencia nica a la especificacin de requerimientos,
donde se encuentra la descripcin detallada del mismo.
Nombre: Nombre de la funcionalidad a probar.
Prioridad: Indica la prioridad que tiene esa funcionalidad para las
pruebas. Los valores posibles son: Alta, Media y Baja.
Una vez que se tiene el inventario de pruebas, se
define el alcance. Para esto se estima el tiempo
en probar cada funcionalidad, utilizando la
informacin de proyectos anteriores similares y
la experiencia del equipo de pruebas.
Conociendo esta informacin, el plan de
desarrollo del producto y la fecha prevista para
instalar el producto en el ambiente de
produccin, se define el alcance para las
pruebas.

Pruebas de Regresin
Las Pruebas de Regresin es cualquier tipo de pruebas de software que trata
de descubrir nuevos errores de software, o regresiones, en reas funcionales
y no funcionales de un sistema existente despus de los cambios, tales como
mejoras, parches o cambios de configuracin, se han hecho para ellos. Tienen
como objetivo verificar que no ocurri una regresin en la calidad del producto
luego de un cambio, asegurando que los cambios no introducen un
comportamiento no deseado u errores adicionales. Implican la re ejecucin de
alguna o todas las pruebas realizadas anteriormente.
La intencin de las pruebas de regresin es para asegurarse de que un cambio
tal como los mencionados anteriormente no ha introducido nuevos fallos. Una
de las principales razones para las pruebas de regresin es para determinar si
un cambio en una parte del software afecta a otras partes del software.

Los mtodos comunes de pruebas de regresin incluyen volver a ejecutar las

pruebas previamente realizadas y comprobar si el comportamiento del
programa ha cambiado y si fallas previamente fijos ha vuelto a surgir. Las
pruebas de regresin se pueden utilizar para probar un sistema de manera
eficiente mediante la seleccin sistemtica el conjunto mnimo apropiado de
las pruebas necesarias para cubrir adecuadamente un cambio en particular.
Las pruebas de regresin pueden ser utilizadas no slo para probar la
correccin de un programa, pero a menudo tambin para el seguimiento de la
calidad de su produccin. Por ejemplo, en el diseo de un compilador, pruebas
de regresin podra realizar el seguimiento del tamao del cdigo, el tiempo
de simulacin y el tiempo de compilacin de los casos serie de pruebas.
Para que las pruebas de regresin sean ejecutadas de manera rpida, es
necesario que el lder de calidad tenga ciencia de la necesidad de este tipo de
prueba, para que pueda planear la ejecucin de pruebas de regresin y
haciendo un aumento del tiempo de la actividad de la prueba.
El plan de casos de prueba de regresin puede ser de tres tipos:
Los casos de prueba que cubren toda la funcionalidad del sistema.
Los casos de prueba slo para las caractersticas que han sido
modificados.
Nuevos casos de prueba para las caractersticas que se vieron afectadas
probablemente por el cambio.

La figura 1 ilustra un enfoque para

pruebas de regresin a nivel de
unidad, de modo que un
subconjunto de casos de prueba
puede detectar un error de
regresin de unidad.

Las Pruebas de Regresin pueden usarse no solo para probar la correccin de

un programa, sino a menudo usarse para rastrear la calidad de su salida. Por
ejemplo en el diseo de un compilador, las pruebas de regresin deben
rastrear el tamao del cdigo, tiempo de simulacin, y el tiempo de
compilacin de las suites de prueba. Cuando quiera que aparece un nuevo
build, el proceso de regresin aparece.
Pruebas de Aceptacin (UAT)
La prueba de aceptacin es realizada por un grupo de usuarios finales o los
clientes del sistema, para asegurarse que el sistema desarrollado cumple sus
requisitos. La prueba de aceptacin de usuario se distingue generalmente por
la incorporacin de un trayecto feliz o casos de prueba positivos.
Son bsicamente pruebas funcionales, sobre el sistema completo, y buscan
una cobertura de la especificacin de requisitos y del manual del usuario. Estas
pruebas no se realizan durante el desarrollo, pues sera impresentable al
cliente; sino que se realizan sobre el producto terminado e integrado o pudiera
ser una versin del producto o una iteracin funcionad pactada previamente
con el cliente.
La experiencia muestra que an despus del ms cuidadoso proceso de
pruebas por parte del desarrollador, quedan una serie de errores que slo
aparecen cuando el cliente comienza a usarlo. Los desarrolladores suelen
llevar las manos a la cabeza y expresan:
"Pero, a quin se le ocurre usar as mi programa?"
Sea como sea, el cliente siempre tiene razn. Decir que los requisitos no
estaban claros, o que el manual es ambiguo puede salvar la cara; pero
ciertamente no deja satisfecho al cliente. Alegar que el cliente es un intil es
otra tentacin muy fuerte, que conviene reprimir.
Una prueba de aceptacin puede ir desde un informal caso de prueba hasta la
ejecucin sistemtica de una serie de pruebas bien planificadas. De hecho, las
pruebas de aceptacin pueden tener lugar a lo largo de semanas o meses,
descubriendo as errores latentes o escondidos que pueden ir degradando el

funcionamiento del sistema. Estas pruebas son muy importantes, ya que

definen el paso nuevas fases del proyecto como el despliegue y
mantenimiento.

Se emplean dos tcnicas para las pruebas de aceptacin:

La prueba alfa.
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el
software de forma natural con el desarrollador como observador del
usuario. Las pruebas alfa se llevan a cabo en un entorno controlado. Para
que tengan validez, se debe primero crear un ambiente con las mismas
condiciones que se encontrarn en las instalaciones del cliente. Una vez
logrado esto, se procede a realizar las pruebas y a documentar los
resultados.
La prueba beta.
Se lleva a cabo por los usuarios finales del software en los lugares de
trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no

est presente normalmente. As, la prueba beta es una aplicacin "en

vivo" del software en un entorno que no puede ser controlado por el
desarrollador. El cliente registra todos los problemas (reales o
imaginarios) que encuentra durante la prueba beta e informa a
intervalos regulares al desarrollador.
Como resultado de los problemas informados durante la prueba beta, el
desarrollador del software lleva a cabo modificaciones y as prepara una
versin del producto de software para toda la clase de clientes.