Grupo 5

PRUEBAS DE SISTEMA Y ACEPTACIN
INTRODUCCION
Las aplicaciones, sistemas o cualquier mecanismo diseado e implementado por un

humano, son propensas a tener fallos. A veces, pueden contribuir al fracaso de
cualquier proyecto de software, e impactar de forma negativa en toda una empresa.
Surge por tanto la necesidad de asegurar en lo posible, la calidad del producto.
Principalmente se debe verificar que se cumplan con las especificaciones planteadas
desde un inicio por el analista o el propio cliente, y/o eliminar los posibles errores que
se hayan cometido en cualquier etapa del desarrollo.
Siguiendo el proceso de desarrollo software, tras la realizacin del anlisis, diseo y

en algn punto del desarrollo de la aplicacin debe iniciarse la etapa de pruebas de
software, que permitir verificar y revelar la calidad del producto software construido,
antes de su puesta en marcha. Para esto es necesario un ambiente aislado del
desarrollo y el de produccin, es decir, debera simularse la ejecucin de la aplicacin
en un entorno idntico a donde se va a ejecutar.
Al igual que con casi cualquier proceso tcnico, las pruebas de software tienen un
orden prescrito en la que deben hacerse las cosas. Los diferentes niveles de pruebas
se utilizan en el proceso de prueba; cada nivel de prueba tiene como objetivo probar
diferentes aspectos del sistema. Los 4 niveles de pruebas de software se clasifican en:
Pruebas Unitarias, Pruebas de Integracin, Pruebas de Sistema, y por ltimo las
Pruebas de Aceptacin, las cuales integran y ejecutan otros tipos de pruebas.
Principalmente en el desarrollo de sistemas software, la fase de Prueba de Sistemas
cobra gran importancia. El proceso de prueba a nivel de sistema engloba tantos tipos
de prueba como tipos de requisitos se pueden definir y probar con la ejecucin del
sistema o mediante la verificacin de sus distintos elementos. Habitualmente se
engloba requisitos funcionales, de seguridad, de rendimiento, de fiabilidad, de
accesibilidad, etc.
As tambin la importancia que tiene la fase final, de las Pruebas de Aceptacin (o

pruebas de aceptacin del usuario), que se llevar a cabo para determinar si el sistema
se ajusta a las necesidades del negocio del usuario, para posteriormente sea lanzado
a produccin.
En el presente trabajo se har nfasis principalmente a las Pruebas de Sistemas y

Pruebas de Aceptacin, as como el de su implementacin respectivamente de cada
una de ellas en el desarrollo de software.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 1
I. PRUEBAS DE SISTEMA
1. CONCEPTO
Las pruebas del sistema es una forma de tratar de demostrar que el sistema no
cumple sus especificaciones de requisitos y no se puede utilizar. Se puede
consumir tanto como la mitad de los recursos de las pruebas.
Responde a dos grandes preguntas:

1. Tenemos una cobertura suficiente del sistema?
2. El sistema est en condicin de ser liberado?
Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos

o requerimientos, enfocndose en los errores hechos durante la transicin del
proceso al disear la especificacin funcional. Esto hace a las pruebas de
sistema un proceso vital de pruebas, ya que en trminos del producto, nmero
de errores hechos, y severidad de esos errores, es un paso en el ciclo de
desarrollo generalmente propenso a la mayora de los errores.
Cualquier pieza de software completo, desarrollado o adquirido, puede verse como

un sistema que debe de probarse, ya sea decidir acerca de su aceptacin, para
analizar defectos globales o para estudiar aspectos especficos de su
comportamiento, tales como seguridad, rendimiento. A este tipo de pruebas donde
se estudia el producto completo se les llama pruebas de sistemas.
Las pruebas de sistema no son procesos para probar las funciones del sistema o
del programa completo, porque sta sera redundante con el proceso de las
pruebas funcionales. Las pruebas del sistema tienen un propsito particular:
comparar el sistema o el programa con sus objetivos originales (Requerimientos
funcionales y no funcionales). Dado este propsito, se presentan dos
implicaciones:

Las pruebas de sistema no se limitan a los sistemas. Si el producto es un
programa, la prueba del sistema es el proceso de procurar demostrar cmo
el programa, en su totalidad, no resuelve sus objetivos o requerimientos.

Las pruebas de sistema, por definicin, son imposibles si noestn los
requerimientos por escrito, mensurables para el producto.
Las pruebas del sistema son una fase de pruebas de investigacin, en la que se
asegura que cada componente unitario o mdulo (identificado en las pruebas
unitarias), interacte con otros componentes o mdulos, tal como fue diseado.
2. OBJETIVOS
Las pruebas de sistema tienen como objetivo ejercitar profundamente el

sistema comprobando la integracin del sistema de informacin globalmente,
verificando el funcionamiento correcto de las interfaces entre los distintos
subsistemas que lo componen y con el resto de sistemas de informacin con los
que se comunica.
Un problema clsico de la prueba de sistema es sealar con el dedo. Esto

ocurre cuando se descubre un error y el desarrollador de cada elemento del
sistema culpa a los dems. En lugar de caer en este absurdo, el ingeniero del
software debe de anticiparse a posibles problemas de la interfaz y:
Disear ruta de manejo de errores que prueben toda la informacin

proveniente de otros elementos del sistema.

Aplicar una serie de pruebas que simulen datos incorrectos u otros
posibles errores en la interfaz de software.

Registrar los resultados de la prueba como evidencia en el caso de que
se culpe.
Participar en la planeacin y el diseo de las pruebas del sistemas para
asegurar que le software se ha probado adecuadamente.
En realidad, la prueba de sistema abarca una serie de pruebas diferentes cuyo

propsito principal es ejecutar profundamente el sistema en cmputo. Aunque
cada prueba tiene un propsito diferente, todas trabajan para verificar que se
hayan integrado adecuadamente todos los elementos del sistema y que realicen
las funciones apropiadas.
Ilustracin I-1. Pruebas de Software (Testing)
3. IMPORTANCIA DE LAS PRUEBAS DE SISTEMA

Por qu son importantes las pruebas de sistemas?

Las pruebas de sistemas son importantes por lo siguiente:

Es donde se prueba el sistema como un todo dentro del ciclo de vida del
desarrollo del sistema.

verificar si cumple con sus requisitos
El sistema es probado para
funcionales y tcnicos.

El sistema esprobado en un entorno lo ms parecido al entorno de
produccin.

los
Las pruebas de Sistema permiten probar, verificar y validar, tanto
requisitos de negocios como la arquitectura de la aplicacin.
4. VISIN SISTMICA DE LA PRUEBA
Cuando se deben realizar pruebas, debe mantenerse un enfoque sistmico, es

decir integral, que est detrs de todo desarrollo de software. Al hablar de
enfoque sistmico se indica que:

Todo sistema tiene una serie de objetivos que le dan sentido. Esos
objetivos estn asociados con indicadores de xito que permiten
determinar si los objetivos se cumplen y en qu medida.

Todo sistema tiene una serie de elementos que lo forman y la interaccin
de tales elementos se orienta a satisfacer los objetivos.

Todo sistema tiene una frontera que lo separa de un medio ambiente.
Los elementos de ese medio ambiente influyen sobre el sistema
proporcionndoles una serie de entradas y obteniendo del mismo un
conjunto de salida.

interaccionan con otros
Ningn Sistema existe en aislamiento; siempre
sistemas constituyendo un sistema mayor.
4.1. Principios base para la prueba

Al aplicar esos conceptos a la prueba de software, se obtienen una serie de
principios que servirn de base para la prueba:

Debe asegurarse de conocer con precisin los objetivos del software a
probar, as como sus indicadores de xito. Estos elementos se localizan
en los documentos obtenidos en la etapa de recoleccin de
requerimientos, as como en las especificaciones del software. Esta
informacin ser indispensable para preparar el plan de pruebas y ser
la base para iniciar el desarrollo de los casos de prueba.

Deben determinarse las entradas y salidas del sistema aprobar. ste
aspecto es necesario en la preparacin de los casos de prueba y tambin
en el establecimiento de procedimientos de prueba, orientados
especialmentea los casos de prueba que muestran el cumplimiento de
los objetivos.

Considerar el sistema mayor donde opera el software a probar.
Generalmente es un ambiente organizacional, formado por elementos de
hardware, de software y personas (usuarios). Todos estos elementos
influyen mucho sobre el sistema y ayudan especialmente en la
preparacin de casos de prueba de situaciones no deseadas, relacionadas
con datos inadecuados,
ausencia de elementos necesarios y ocurrencia
de excepciones.
5. VISIN GENERAL DE LA PRUEBA DE SISTEMA
El proceso de prueba de un sistema tiene dos etapas que pueden estar muy
separadas en el tiempo: la preparacin de las pruebas y la aplicacin de las
mismas. La primera est muy ligada a la obtencin de requerimientos, por lo
que ocurre en las primeras etapas del proyecto, mientras que la segunda
requiere del sistema completo o al menos una integracin, como se denomina
a un producto parcial, an no liberado, para poder aplicar las pruebas, por lo
que ocurre en etapas avanzadas del proyecto. La situacin exacta de estas
partes depende del modelo de ciclo de vida que se haya elegido.
La etapa de preparacin de pruebas incluye al menos tres actividades:
a. Preparar un plan de pruebas.
b. Preparar una lista de verificaciones de los requerimientos.
c. Preparar casos de prueba.
Para ejecutar la segunda y la tercera actividad se requiere contar con el

documento de requerimientos.
Ilustracin 0-2: Suposiciones de Pruebas de Sistemas
La primera etapa de pruebas provee retroalimentacin para el anlisis de

requerimientos, identificando huecos, ambigedades y otros problemas.
Tambin provee valiosas sugerencias para el diseo y la implementacin del
sistema, si apenas est desarrollando.
La etapa de aplicacin de pruebas requiere del plan de pruebas y de una versin

del sistema que sea ejecutable (una integracin). Sobre sta se aplicarn los
casos de prueba que se prepararon, se analizaran los resultados y se
identificaran posibles defectos.
Esta segunda etapa provee retroalimentacin a la implementacin y al diseo,

mostrado posibles defectos que deben ser corregidos. Tambin provee que ser
de utilidad en la liberacin del sistema, su aceptacin, la estimacin de si
confiabilidad y para su mantenimiento.
La prueba de sistemas tiene varias suposiciones importantes:
Cada unidad que forma el sistema ha sido probada y se han eliminado

sus defectos.

Las interfaces humano-computadoras (de texto o grficas), han sido
probadas tambin por separado.

Se han realizado pruebas de integracin para analizar la interaccin
entre partes del sistema y se han eliminado los defectos identificados.
El segundo punto es importante, ya que algunas veces se confunde la prueba

de sistema con la prueba de la interfaz. La primera verifica la interaccin de
todas las partes, mientras que la segunda nicamente analiza los elementos de
la interfaz y posiblemente el manejo de eventos asociados. Sim embargo, las
herramientas que ayudan a la prueba de interfaz pueden utilizarse para iniciar
las pruebas de sistema.
6. PLAN DE PRUEBAS
El plan de pruebas es un documento muy importante dentro del proceso de

prueba del software. En l se explican los propsitos y enfoques de las pruebas,
el plan de trabajo, los procedimientos operacionales, las herramientas
necesarias y las responsabilidades. La extensin y detalle del plan debe
adecuarse al proyecto y a las necesidades de la empresa, pudiendo usarse como
gua el estndar IEEE 829.
A continuacin, se muestra una propuesta mnima de contenido, para

proyectos pequeos y medianos.

Identificacin del plan de pruebas y el sistema al que aplica.

Elementos a probar: qu mdulos, clases, casos de uso se van a
probar; cuando se emplea desarrollo iterativo, deben
especificarse las prestaciones (funcionales), a probar y cuales no
se probarn
(ya sea que se probaron antes o que se implementarn
despus).

Enfoque: vista general de la estrategia de prueba.

Criterio de aceptacin o rechazo de un caso de prueba: criterio
para dar por bueno o malo un caso de prueba al ser ejecutado.

Criterio de suspensin: ya sea por tiempo o por cobertura.
Productos a entregar: desde el propio plan, los casos y
procedimientos de prueba, los resultados.

Tareas a realzar para satisfacer el proceso.

Necesidadesambientales: hardware, software y espacio de trabajo
necesarios.

Responsabilidades: quien es responsable de cada cosa.

Personal necesario y si requieren entrenamiento.

Calendario: tiempos e hitos en el proceso.

Riesgos
y contingencias que pueden ocurrir en el proceso de
prueba.
7. LISTA DE VERIFICACIONES
Para comenzar el proceso de pruebas del sistema se parte del documento de

requerimientos. En caso que no exista y se deba evaluar un sistema para
aceptarlo o seleccionarlo de entre un conjunto, habr que preparar dicho
documento, aun cuando sea extemporneo.
Un documento de requerimientos debe contener la lista de las funciones que se

desea realice el software, describindolas y priorizndolas; tambin debe
incluir los requerimientos no funcionales, que pueden incluir aspectos
organizacionales, de rendimiento y otros.
Un documento de requerimientos bien preparado debe proveer, para cada

requerimiento, una forma de verificar que se satisface. En el caso de las
funciones, ser una descripcin y en caso de requerimientos no funcionales
pueden ser especificaciones muy precisas, como puede ser el tiempo de
respuesta.
Por el momento concentraremos la atencin en los requerimientos funcionales,

dejando los otros para una seccin posterior.
La actividad de preparar lista de verificacin incluye los pasos siguientes:

Asegurar que para cada requerimiento exista una descripcin de la
manera en que se verificar; si no existe, debe desarrollarse. Una buena
descripcin debe contener al menos el funcionamiento tpico de la
funcin a que corresponde y los principales comportamientos alternos:
variaciones menos
frecuentes, respuesta ante datos incompletos y fallas
del ambiente.

Revisin de las descripciones: cada descripcin debe revisarse para
asegurarseque se entiende claramente, que efectivamente es
realizable.
8. E/S, TAREAS Y ROLES DE PRUEBAS DE SISTEMA
ENTRADAS
Plan de pruebas de Sistema.

Producto Integrado y probado.
TAREAS
Preparacin del entorno de pruebas. Se recomienda la existencia

de un entono de pruebas especfico para la realizacin de este
tipo de pruebas.
Instalacin en el entorno de pruebas.
Construccin de elementos auxiliarea de prueba.
Ejecucin de las pruebas.
Obtencin y registro de resultados. Elaboracin del Informe de
Pruebas, en el que se registrarn los resultados de las pruebas.
Correcin de fallos y errores detectados.
Reiteracin de la actividad hasta superar todas las pruebas.
Elaboracin del Manual de Usuario y de Administracin.
Actualizacin y revisin del Plan e Informe de Pruebas.
SALIDAS
Informe de Pruebas de Sistema.

Manual de Usuario.
Manual de Administracin.
Plan e Informe de Pruebas.
Sistema probado.
ROLES
Ing. de Pruebas
Analista Funcional
Jefe de Pruebas
Ilustracin 0-3: E/S, Tareas y Roles de Pruebas de Sistema
Las pruebas de sistema normalmente son llevadas a cabo por un equipo

independiente de tcnicos especializados en pruebas. En algunas
organizaciones estas pruebas son llevadas a cabo por un equipo externo o por
analistas de negocio.
Las pruebas de sistema requieren un entorno de pruebas controlado en lo que

se refiere a un control de versiones del software o datos de prueba, entre otras
cosas. Una prueba del sistema es ejecutada por la organizacin en un entorno
controlado. El entorno de pruebas debera corresponder al objetivo final o
entorno de produccin tanto como sea posible, con el objetivo de minimizar el
riesgo de encontrar fallos especficos del entorno.
Ilustracin 0-4: Flujo de Control de Pruebas de Sistema
9. TIPOS DE PRUEBAS DE SISTEMA

N PRUEBAS DE SISTEMA
1 Pruebas de Almacenamiento
2 Pruebas de Comunicacin
3 Pruebas de Configuracin
4 Pruebas de Desempeo
5 Pruebas de Disponibilidad de datos
6 Pruebas de Entorno
7 Pruebas de Facilidad de Uso
8 Pruebas de Implantacin
9 Pruebas de Instalacin
10 Pruebas de la Documentacin
11 Pruebas de Operacin
12 Pruebas de Recuperacin
13 Pruebas de Rendimiento
14 Pruebas de Resistencia
15 Pruebas de Seguridad
16 Pruebas de Sobrecarga
17 Pruebas de Tensin
18 Pruebas de Usabilidad
19 Pruebas de Volumen
Ilustracin 0-5: Tipos de Pruebas de Sistemas
9.1. Prueba de Almacenamiento

Los programas tienen de vez en cuando objetivos de almacenamiento que
indiquen, por ejemplo, la cantidad de memoria principal y secundaria que el
programa usa y el tamao de los archivos temporales. Se disean casos de
prueba para demostrar que estos objetivos de almacenaje no han sido
encontrados.
9.2. Prueba de Comunicaciones

Determinan que las interfaces entre los componentes del sistema funcionan
adecuadamente, tanto a travs de dispositivos remotos, como locales. As
mismo, se han de probar las interfaces hombre/mquina.
9.3. Prueba de Configuracin

Programas tales como sistemas operativos, sistemas de gerencia de base de
datos, y programas de conmutacin de mensajes soportan una variedad de
configuraciones de hardware, incluyendo varios tipos y nmeros de dispositivos
de entrada-salida y lneas de comunicaciones, o diversos tamaos de memoria.
A menudo el nmero de configuraciones posibles es demasiado grande para
probar cada uno, pero en lo posible, se debe probar el programa con cada tipo
de dispositivo de hardware y con la configuracin mnima y mxima. Si el
programa por s mismo se puede configurar para omitir componentes, o si puede
funcionar en diversas computadoras, cada configuracin posible de este debe
ser probada.
9.4. Prueba de Desempeo

La prueba de desempeo est diseada para probar el desempeo del software
en tiempos de ejecucin dentro del contexto de un sistema integrado. La
prueba de desempeo se aplica en todos los pasos del proceso de la prueba.
Incluso al nivel de la unidad. El desempeo de un mdulo individual debe de
evaluarse mientras se realizan las pruebas. Sin embargo, no es sino hasta que
se encuentre totalmente integrado todos los elementos del sistema que es
posible asegurar el verdadero desempeo del sistema.
Con frecuencia las pruebas de desempeo se vinculan con pruebas de

resistencia y suelen requerir instruccin de software y hardware. Es decir, a
menudo resulta necesario medir con exactitud la utilizacin de recursos (por
ejemplo: los ciclos de procesador). Mediante instrumentacin externa pueden
vigilarse de manera regular los intervalos de ejecucin, los eventos que se
registran (como las interrupciones) y los estados de muestra del equipo. Si se
instrumenta un sistema, la persona que aplica la prueba descubrir situaciones
que lleven a la degradacin y posibles fallas del sistema.
9.5. Prueba de Disponibilidad de datos

Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de
equipo fsico como lgico, sin comprometer la integridad de los datos.
9.6. Prueba de Entorno

Consisten en verificar las interacciones del sistema con otros sistemas dentro
del mismo entorno.
9.7. Prueba de Facilidad de uso

Consisten en comprobar la adaptabilidad del sistema a las necesidades de los
usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo,
como para determinar las facilidades que aporta al introducir datos en el
sistema y obtener los resultados.
9.8. Prueba de Implantacin

El objetivo de las pruebas de implantacin es comprobar el funcionamiento
correcto del sistema integrando el hardware y software en el entorno de
operacin, y permitir al usuario que, desde el punto de vista de operacin,
realice la aceptacin del sistema una vez instalado en su entorno real y en base
al cumplimiento de los requisitos no funcionales especificados.
9.9. Prueba de Instalacin

Algunos tipos de sistemas de software tienen complicados procedimientos de
instalacin. Las pruebas de los procedimientos de instalacin es una parte
importante del proceso de prueba del sistema. Esto es particular de un sistema
automatizado de instalacin que sea parte del paquete del programa. Al
funcionar incorrectamente el programa de instalacin podra evitar que el
usuario tenga una experiencia acertada con el sistema. La primera experiencia
de un usuario es cuando l o ella instalan la aplicacin. Si esta fase se realiza
mal, entonces el usuario/el cliente puede buscar otro producto o tener poca
confianza en la validez de la aplicacin.
9.10. Prueba de Documentacin

Las pruebas de sistema tambin se refieren a la exactitud de la documentacin
del usuario. Una manera de lograr esto es utilizar la documentacin para
determinar la representacin de los casos anteriores de prueba del sistema.
Esto es, una vez se desea idear el caso de sobrecarga, se utilizara la
documentacin como gua para escribir el caso de prueba real. Tambin, la
documentacin del usuario debe ser el tema de una inspeccin, comprobndola
para saber si hay exactitud y claridad. Cuales quiera de los ejemplos ilustrados
en la documentacin se deben probar y hacer parte de los casos y alimentarlos
al programa.
9.11. Prueba de Operacin

Consisten en comprobar la correcta implementacin de los procedimientos de
operacin, incluyendo la planificacin y control de trabajos, arranque y re
arranque del sistema.
9.12. Prueba de Recuperacin

Muchos sistemas de cmputo deben de recuperarse de fallas y reanudar el
procesamiento en el tiempo determinado. En algunos casos, un sistema debe
ser tolerante con las fallas; es decir, las fallas de procesamiento no deben llevar
a la cada del sistema, en general. En otros casos una falta del sistema debe de
corregir dentro de un periodo especfico o se sufrir un fuerte dao econmico.
La prueba de recuperacin es una prueba de sistema que obliga al software a

fallar de varias maneras y a verificar que la recuperacin se realice
apropiadamente. Si la recuperacin es automtica (la realiza el propio sistema)
debe de evaluarse que sean correctos la re-inicializacin, los mecanismos de
respaldo del sistema, la recuperacin de datos y el nuevo arranque. Si la
recuperacin requiere de intervencin humana, se debe evaluar el tiempo
medio de recuperacin (TMR) para determinar si se encuentra dentro de los
lmites aceptables.
Si se dan el tiempo y los recursos suficientes, una buena prueba de seguridad

terminara por irrumpir en el sistema. El papel del diseador del sistema es que
el costo de la irrupcin sea mayor que el valor de la informacin que habr de
obtenerse.
9.13. Prueba 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, tales como la escalabilidad,
fiabilidad y uso de los recursos.
Las pruebas de rendimiento son un subconjunto de la ingeniera de pruebas,

una prctica informtica que se esfuerza por mejorar el rendimiento,
englobndose en el diseo y la arquitectura de un sistema, antes incluso del
esfuerzo inicial de la codificacin.
9.14. Prueba de Resistencia

Los pasos de prueba analizados antes en este trabajo, llevan a una evaluacin
completa de las funciones y el desempeo normalmente del programa. Las
pruebas de resistencia estn diseadas para confrontar los programas en
situaciones anormales. En esencia, la persona que realiza la prueba de
resistencia se preguntara.
Hasta dnde llevar esto antes de que falle?
La prueba de resistencia ejecuta un sistema de tal manera que requiera una

cantidad, una frecuencia o volumen anormal de recursos. Por ejemplo:

Se disea pruebas especiales que generen10 interrupciones por segundo
cuando la tasa promedio es de una o dos.

una magnitud que permita
Se aumenta la frecuencia de entrada de datos
como responder las funciones de entrada.

casos de pruebas que requieran el mximo de memoria u otros
Se ejecutan
recursos.

Se disea
casos de pruebas que causen problemas de administracin de
memoria.

Se crean casos de pruebas que produzcan bsquedas excesivas de datos en
el disco.
9.15. Prueba de Seguridad

Cualquier sistema de cmputo que maneje informacin confidencial o que
desencadenen acciones que daen o beneficien inapropiadamente a los
individuos es un blanco para irrupciones impropias o ilegales. La irrupcin
abarca un amplio rango de actividades:

Hacker que tratan de entrar en los sistemas por juego.

Empleados disgustados que tratan de irrumpir como forma de venganza.

Individuos deshonestos que buscan ganancias personales ilcitas.
La prueba de seguridad comprueba que los mecanismos de proteccin

integrados en el sistema realmente lo protejan de irrupciones inapropiadas.
Los sistemas se deben de probarse para la seguridad del sistema para asegurar
que es invulnerable a los ataques frontales, pero tambin a los perpetrados por
los flancos o las retaguardia.
Durante la prueba de seguridad, quien la aplica desempea el papel del

individuo que desea entrar en el sistema. Todo vale! Debe de tratar de obtener
contraseas por cualquier medio externo; podra atacar el sistema con software
personalizados, diseados para burlar cualquier defensa que se haya
construido; podra saturar el sistema, negando as el servicio a otros; podra
producir errores intencionales en el sistema para tratar de tener acceso durante
la recuperacin: podra revisar datos sin proteccin, con la idea de encontrar
la clave de acceso al sistema.
9.16. Prueba de Sobrecarga

Consisten en comprobar el funcionamiento del sistema en el umbral lmite de
los recursos, sometindole a cargas masivas. El objetivo es establecer los
puntos extremos en los cuales el sistema empieza a operar por debajo de los
requisitos establecidos.
9.17. Prueba de Tensin

La prueba de tensin es poner al programa a grandes cargas o tensiones. Esto
no se debe confundir con la prueba de volumen; una gran tensin es volumen
mximo de datos, o de actividad, en un tiempo corto. Una analoga sera
evaluar a un mecangrafo. Una prueba de volumen se determinara si el
mecangrafo hiciera frente a un bosquejo de un informe grande; una prueba
de tensin se determinara si el mecangrafo puede mecanografiar a un ndice
de 50 palabras por minuto.
9.18. Prueba de Usabilidad

Otra categora importante de casos de prueba de sistema es la tentativa de
encontrar problemas de factores humanos, o usabilidad. Sin embargo, un
anlisis de factores humanos sigue siendo una cuestin altamente subjetiva.
9.19. Prueba de Volumen

Consisten en examinar el funcionamiento del sistema cuando est trabajando
con grandes volmenes de datos, simulando las cargas de trabajo esperadas.
II. PRUEBAS DE ACEPTACIN

Una caracterstica esencial de un requisito del software es que debe ser posible
validar que el producto final lo satisface. Los requisitos que no pueden ser
validados son deseos realmente justos. Una tarea importante es por lo tanto
planear cmo verificar cada requisito. En la mayora de los casos, el diseo de
pruebas de aceptacin hace esto. Identificar y disear pruebas de aceptacin
puede ser difcil para los requerimientos no funcionales. Para ser validados,
deben primero ser analizados al punto donde pueden ser expresados
cuantitativamente.
Ilustracin II-1: Flujo de control pruebas de aceptacin
10. CONCEPTO
Las pruebas de aceptacin, son bsicamente pruebas funcionales sobre el

sistema completo, y buscan comprobar que se satisfacen los requisitos
establecidos. Su ejecucin es facultativa del cliente, y en el caso de que no se
realicen explcitamente, se dan por incluidas dentro de las pruebas de sistema.
Es decir, las pruebas de aceptacin son, a menudo, responsabilidad del usuario
o del cliente, aunque cualquier persona involucrada en el negocio puede
realizarlas. La ejecucin de las pruebas de aceptacin requiere un entorno de
pruebas que represente el entorno de produccin.
Estas pruebas se llevan a cabo antes de que el software se ponga en

funcionamiento real, es decir el producto est listo para implantarse en el
entorno del cliente. El usuario debe ser el que realice las pruebas, ayudado por
las personas del equipo de pruebas, siendo deseable que el mismo usuario sea
quien aporte los casos de prueba.
Esta fase o nivel toma como punto de partida la lnea base de aceptacin del
producto ya instalado en el entorno de certificacin. A partir de dicha lnea
base se acepta el producto, tomando como referencia la especificacin de
requisitos y comprobando que el sistema cubre satisfactoriamente los requisitos
del cliente.
El sistema ha de ser aceptado por el usuario. Por tal motivo, a partir de las
especificaciones estructuradas del sistema, el analista produce un conjunto de
casos de prueba que tendr que pasar satisfactoriamente. Como las pruebas de
aceptacin se pueden desarrollar en paralelo con las actividades de diseo e
implementacin, es normal que esta actividad la inicie el analista nada ms
finalizar la actividad de Anlisis Estructurado.
Ilustracin II-2: Modelo V para pruebas
La prueba de aceptacin puede darse en distintos momentos del ciclo de vida,

tales como:

Se pueden realizar pruebas de aceptacin sobre un producto de software
cuando se instala o se integra.

Las pruebas de aceptacin de la usabilidad deun componente pueden
hacerse durante las pruebas de componente.

nueva mejora funcional pueden realizarse
Las pruebas de aceptacin de una
antes de la prueba del sistema.
11. OBJETIVOS
Las pruebas de aceptacin tienen como objetivo obtener la aceptacin final del
cliente antes de la entrega del producto para su paso a produccin. Cuando la
organizacin ha realizado las pruebas de sistema y ha corregido la mayora de
sus defectos, el sistema ser entregado al usuario o al cliente para que d su
aprobacin.
El objetivo de las pruebas de aceptacin es crear confianza en el sistema,

partes del sistema o caractersticas especficas no funcionales del sistema. El
objetivo principal estas pruebas no es localizar defectos. Las pruebas de
aceptacin evalan la buena disposicin de un sistema para su despliegue y uso,
a pesar de no constituir necesariamente el ltimo nivel de prueba. As por
ejemplo, las pruebas de aceptacin de un sistema pueden estar seguidas de una
prueba de integracin del sistema a gran escala.
Una prueba de aceptacin tiene como propsito demostrar al cliente el

cumplimiento de un requisito del software. Precisando un poco ms, una prueba
de aceptacin:

Describe un escenario (secuencia de pasos) de ejecucin o uso del sistema
desde la perspectiva del cliente.

Puede estar asociada a requisitos funcionales o no funcionales.

Un requisito tiene una o ms pruebas de aceptaciones asociadas.

desde escenarios tpicos/frecuentes
Las pruebas de aceptacin cubren
hasta los ms excepcionales.
Adicional a su propsito fundamental, las pruebas de aceptacin pueden

rentabilizarse usndose para:

Obligar a definir requisitos que sean verificables.
Valorar adecuadamente el esfuerzo asociado a la incorporacin de un
requisito.
Negociar con el cliente el alcance del sistema.
Planificar el desarrollo iterativo e incremental del sistema.
Guiar a los desarrolladores.
Identificar oportunidades de reutilizacin.
12. CICLO DE VIDA
El ciclo de la prueba de aceptacin debe considerar al menos los siguientes

puntos:
Disear casos de prueba de aceptacin basados en los requerimientos que

presenta el cliente.
Preparar datos de las pruebas de aceptacin.
Validar datos de los casos de prueba de aceptacin.
Definir el procedimiento de la prueba.
Ejecutar las pruebas de aceptacin.
Comparar los resultados de las pruebas con los casos de prueba iniciales.
Documentar las pruebas de aceptacin.
Especificacin de Requisitos.
Manuales de Usuario.
Sistema probado.
Entradas Plan de Pruebas.
Preparacin del entorno de pruebas. Se recomienda la existencia de un

entorno de pruebas especfico para la realizacin de este tipo de pruebas.
Instalacin en el entorno de pruebas.
Identificacin de las pruebas a realizar.
Planificacin de las pruebas. Se establecern las posibles dependencias que
hubiera entre pruebas y se establecer el orden o secuencia de ejecucin de
las pruebas en base a dichas dependencias.
Ejecucin de las pruebas.
Obtencin y registro de resultados.
Correccin de fallos y errores detectados.
Tareas
Reiteracin de la tarea hasta superar todas las pruebas.
Elaboracin de un Informe de Pruebas de aceptacin.
Revisin de la correcta ejecucin y resultados de todas las pruebas planteadas.
Creacin de la lnea base de produccin.
Cierre formal de la actividad.
Resultados de pruebas.
Producto aceptado
Informe de Pruebas de aceptacin.
Salidas
Ilustracin II-3: Entradas tareas salidas de las pruebas de aceptacin
Roles
Ingeniero de Pruebas
Jefe de pruebas
Jefe de proyecto
Ilustracin II-4: Roles de la prueba de aceptacin
13. ESTRATEGIAS
En general, las pruebas de aceptacin pueden adoptar, entre otras, las

siguientes formas:
13.1. Pruebas de aceptacin del usuario

Hay casos en los que el cliente y el usuario final son diferentes y lo que le parece
vlido a un usuario final, puede ocurrir que no le parezca vlido a otro. Por este
motivo, es fundamental realizar pruebas con los usuarios finales.
13.2. Pruebas operativas

Estas pruebas son llevadas a cabo por los administradores del sistema que se va
a poner en produccin. En estas pruebas se incluyen las tareas:
Copia de seguridad/ restauracin.

Recuperacin de desastres.
Gestin de usuarios.
Comprobaciones peridicas de vulnerabilidades de seguridad
Carga de datos y tareas de migracin.
Tareas de mantenimiento.
13.3. Pruebas de aceptacin contractual y normativa

Las pruebas de aceptacin contractual Toman como base los criterios de
aceptacin previstos en un contrato para fabricar un software desarrollado a
medida. Los criterios de aceptacin debern establecerse en el momento en
que las partes aceptan contraer dicho contrato.
Las pruebas de aceptacin normativa toman como base cualquier normativa de

obligado cumplimiento, tales como normativas gubernamentales, legales o de
seguridad.
13.4. Pruebas alfa y beta (o de campo)

Si el sistema ha sido desarrollado para el mercado masivo entonces no ser
prctico probarlo para usuarios o clientes individuales, en algunos casos sera
imposible. En estos casos, antes de que el producto se ponga a la venta, es
necesaria una retroalimentacin.
13.4.1. Pruebas 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 y
registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en
un entorno controlado.
Las pruebas -alfa consisten en invitar al cliente a que pruebe el sistema

en el entorno de desarrollo. Se trabaja en un entorno controlado y el cliente
siempre tiene un experto a mano para ayudarle a usar el sistema. El
desarrollador va registrando los errores detectados y los problemas de uso.
13.4.2. Pruebas beta ().

Las pruebas -beta se realizan con posterioridad a las prueba -alfa, y se
desarrollan en el entorno del cliente. En este caso, el cliente se queda a solas
con el producto y trata de encontrarle fallos de los que informa al
desarrollador.
Se llevan 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 que encuentra durante la prueba beta e
informa a intervalos regulares al desarrollador.
13.5. Herramientas
Si bien este tipo de pruebas pueden realizarse con prototipos de la aplicacin,
diagramas de secuencia o casos de uso que se muestran al usuario para que
valide los requerimientos definidos, existen algunas herramientas que pueden
ser tiles:
FitNesse
Permite a los usuarios, equipos de testing y programadores aprender lo que
debe hacer el software y comparar automticamente lo que realmente hace.
Se pueden realizar pruebas de aceptacin y pruebas de reglas de negocio. Es
una wiki que no requiere demasiadas configuraciones.
Avignon
Es un framework para pruebas de aceptacin que permite a los usuarios
expresar pruebas de aceptacin de una forma no ambigua antes que comience
el desarrollo. Trabaja en conjunto con JUnit, HTTPUnit, JAXP y Xalan. Utiliza
XML para definir la sintaxis del lenguaje.
Concordion
Es un framework Java de Software Libre que permite convertir
especificaciones en texto comn sobre requerimientos en pruebas
automatizadas.
Las especificaciones (o pruebas de aceptacin) se escriben normalmente en
archivos HTML, usando tablas y todos los elementos comunes para darle formato.
De esta manera se logran especificaciones muy fciles de leer y que todos pueden
comprender (desde analistas de negocio hasta desarrolladores).
Cucumber Es una herramienta para hacer pruebas de aceptacin de usuario
(mediante enfoque BDD -Behaviour Driven Development-) escrita en Ruby y
que ayuda a que el usuario final, es decir, la persona que se encuentra
trabajando en el ambiente del negocio propiamente dicho, y el equipo de
proyecto (analista, desarrollador y probador) se puedan entender
fcilmente.
Ilustracin II-5: Tabla de herramientas de la prueba de aceptacin
13.6. Garanta de calidad o control de calidad con respecto a

pruebas de aceptacin
Se conoce esta actividad como prueba final o prueba de aceptacin. Requiere
como entrada los datos de las pruebas de aceptacin y el sistema integrado
producido en la actividad. La prueba la realizara algn miembro o
departamento del usuario, o incluso un departamento independiente de control
de calidad. Interesa sealar que es importante realizar actividades de control
de calidad en cada una de las actividades anteriores de anlisis, diseo e
implementacin para asegurar que se han realizado con un nivel apropiado de
calidad.
As se asegura que el analista est desarrollando especificaciones de calidad,

que el diseador est produciendo diseos de calidad y que el programador est
codificando programas de calidad. La actividad de control de calidad es
simplemente la prueba final de la calidad del sistema. (F. Alonso Amo, Loic
artnez Normand)
La prueba de aceptacin comprueba el comportamiento del sistema frente a

las necesidades del cliente, sin embargo, estos pueden haber sido expresado,
los clientes se comprometen, o especificar, las tareas tpicas para comprobar
que sus exigencias se han cumplido o que la organizacin ha identificado estos
para el mercado objetivo para el software.
III. IMPLEMENTACION DE PRUEBAS

DE SISTEMA
14. CONCEPTO
Una implementacin o implantacin es la realizacin de una aplicacin, o la

ejecucin de un plan, idea, modelo cientfico, diseo, especificacin, estndar,
algoritmo o poltica.
En ciencias de la computacin, una implementacin es la realizacin de una

especificacin tcnica o algoritmos como un programa, componente software,
u otro sistema de cmputo. Muchas implementaciones son dadas segn a una
especificacin o un estndar. Por ejemplo, un navegador web respeta (o debe
respetar) en su implementacin, las especificaciones recomendadas segn el
World Wide Web Consortium, y las herramientas de desarrollo del software
contienen implementaciones de lenguajes de programacin.
15. GENERACIN DE OBJETIVOS DE PRUEBA A PARTIR DE

CASOS DE USO
El perfil de pruebas de UML define un objetivo de pruebas como un elemento

con un nombre concreto que define qu debe ser probado.
En el contexto de pruebas del sistema a partir de los casos de uso, un objetivo

de prueba puede expresarse como un escenario del caso de uso. Dicho escenario
estar compuesto de una secuencia de pasos, sin alternativa posible, y de un
conjunto de valores de prueba, as como las pre-condiciones y post-condiciones
relevantes para dicho escenario.
Para la generacin de los escenarios de prueba, en primer lugar, se construye

un diagrama de actividades a partir de la secuencia principal y secuencias
errneas y alternativas del caso de uso. En el diagrama de actividades, se
estereotipa las acciones realizadas por el sistema y las acciones realizadas por
los actores. Despus, se realiza un anlisis de caminos y, cada camino del
diagrama de actividades, ser un escenario del caso de uso y, por tanto, un
potencial objetivo de pruebas.
16. IMPLEMENTACIN DE PRUEBAS DE SISTEMA
Una vez obtenidos los objetivos de prueba es posible implementar casos de

prueba que cubran dichos objetivos. A continuacin, se describe una
arquitectura genrica para pruebas del sistema a partir de los elementos
definidos en el perfil de pruebas de UML.
16.1. Una Arquitectura de prueba de sistema

La arquitectura para la ejecucin y comprobacin automtica de pruebas del
sistema se muestran en la figura 1. A continuacin, se describen brevemente
los elementos de la arquitectura de prueba.
16.1.1. UserInterface:
La clase UserInterface representa la interfaz externa del sistema bajo
prueba y ha sido estereotipada de acuerdo con la definicin del perfil de
prueba de UML
16.1.2. UserEmulator:
La clase UserEmulator, define el elemento que podr interactuar con el
sistema utilizando las mismas interfaces que una persona real. Si, por
ejemplo, el sistema a prueba es una aplicacin web (como en el caso
prctico) la clase UserEmulator ser capaz de interactuar con el navegador
web para indicarle la URL qu tiene que visitar, rellenar formularios, pulsar
enlaces, etc. A partir de la interaccin de dicha clase con el sistema, se
obtendrn uno o varios resultados (clase TestResult), por ejemplo, en el
caso del sistema web, se obtendr cdigo HTML
16.1.3. AssertCatalog:
La clase AssertCatalog define la coleccin de asertos a disposicin de los
casos de prueba para determinar si el resultado obtenido del sistema a
prueba (clase TestResult) es correcto o no.
Tanto el UserEmulator como el AssertCatalog se han agrupado en un clasificador
que representa el test harness, dado que estos dos elementos, suelen ser
comunes para todas las pruebas de diversos sistemas y existe gran variedad de
ofertas en el mercado tanto de pago como libres y gratuitas.
16.1.4. TestSuite:
La clase TestSuite, estereotipada como un Test Context del perfil de
pruebas de UML, representa un conjunto de casos de prueba (Test Case en
el perfil de UML).
16.1.5. TestOracle:
Esta clase sirve de contenedor de todas las acciones de validacin
(expresadas mediante la ejecucin de asertos sobre el resultado obtenido)
que determinarn el veredicto de los casos de prueba del contexto de
prueba.
16.1.6. TestDataPool
La clase TestDataPool (estereotipada como Data Pool segn el perfil de UML)
contendr un conjunto de mtodos Data Selector para seleccionar los
distintos valores de prueba segn las distintas particiones identificadas en
las variables de los casos de uso.
Ilustracin III-1: TestDataPool
16.2. Implementacin de casos de prueba

Para la implementacin de los casos de prueba se van a aplicar los patrones isolated
test y test method. El primer patrn indica que cada caso de prueba debe ser
independiente de los dems. Por ello, como se ha visto anteriormente, cada
objetivo de prueba se codificar como un caso de prueba, ya que los objetivos de
prueba no tiene dependencias entre ellos y cualquier objetivo de prueba puede
verificarse independientemente de los dems.
El segundo patrn indica que cada caso de prueba debe ser implementado como
un mtodo. Esto concuerda con la definicin del UMLTP dnde un caso de
prueba no es un elemento arquitectnico, por tanto no se ha definido en la
seccin anterior, sino la definicin de un comportamiento como un mtodo
(estereotipado como Test Case) dentro de un elemento Test Suite
(estereotipado como Test Context). El comportamiento genrico de un caso de
prueba que se adopta con mayor frecuencia se lista en la tabla 2.
1. Invocacin del set up del caso de pruebas.

2. Invocacin del mtodo de prueba
2.1. Ejecucin de una accin sobre el sistema.
2.2. Comprobacin del resultado de la accin (opcional).
3. Invocacin del tear down del caso de pruebas.
Ilustracin III-2: Comportamiento generico de un caso de prueba
Como se puede ver en la tabla 1, cada mtodo de prueba tiene asociados otros
dos mtodos. El primero, mtodo set-up, establece el estado adecuado del
sistema para la ejecucin de la prueba. El segundo, tear down, restaura el
estado original del sistema. Estos mtodos tambin estarn definidos en el Test
Suite. Cada caso de uso tendr asociado un elemento TestSuite (figura 1). Dicha
suite contendr los mtodos de pruebas y mtodos asociados de todos los
escenarios de dicho caso de uso.
IV. IMPLEMENTACION DE PRUEBAS

DE ACEPTACIN
17. CONCEPTO
Por qu hacer las pruebas de aceptacin?
Cualquier cambio en una empresa, y en especial la instalacin de nuevos sistemas

informticos, se exponen a muchos riesgos, incluyendo:

Riesgo para la reputacin

Riesgo legal

Riesgo de tiempo

Riesgo de recursos
Por lo tanto, la razn principal es averiguar que va hacer el sistema de la

empresa antes de implementarlo. Luego de tomar la decisin sobre la base de
las pruebas presentadas por el desarrollador.
Las pruebas de aceptacin slo funcionan con el apoyo de los clientes, para
ayudar a definir los criterios. Sin el conductor de los criterios de aceptacin, se
hace difcil verificar si se est construyendo el software correcto.
Mediante la creacin de pruebas con requisitos claros y criterios de aprobacin,

el software se encuentra una mejor oportunidad de cumplir con las expectativas
del cliente.
18. DESCRIPCIN
Las pruebas de aceptacin se ejecutan luego de culminar la fase de pruebas de
sistema, esta ejecucin se realiza en la ltima etapa de pruebas, la cual evaluar
el sistema final con miras a su presentacin frente al cliente. En este plan se
especificarn las pruebas que sean necesarias para verificar si el programa cumple
con las especificaciones formales establecidas por el cliente.
19. META
La meta es la determinacin por parte del cliente de la aceptacin o rechazo

del sistema desarrollado.
20. OBJETIVOS
Evidenciar la implementacin satisfactoria para el entorno de usuario.
Comprobar la funcionalidad del sistema en su totalidad.
21. TCNICAS Y PRCTICAS
El tipo de prueba a ejecutar en esta etapa son las pruebas funcionales, ms

conocidas como pruebas de caja negra. Las pruebas de caja negra permiten
detectar funcionamiento incorrecto o incompleto, errores de interfaz, errores
accesos estructuras de datos externas, problemas de rendimiento, errores de
inicio y terminacin. Su criterio se basa en las interfaces y las especificaciones
de los mdulos.
21.1. Pruebas Alfa (entorno de desarrollo)

Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se va a usar 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.
21.2. Pruebas Beta (entorno de cliente)

Pruebas realizadas por los usuarios finales. Las pruebas beta vienen despus de
las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que est
fuera de control de los desarrolladores. Aqu el cliente se queda a solas con el
sistema y trata de encontrarle fallos al producto de los que informa por escrito
al desarrollador.
En resumen, las pruebas alfa y beta, es habitual su realizacin (preparacin,

ejecucin y documentacin) para productos que sern vendidos.
21.3. Actividades del plan
21.3.1. Ciclo de vida de las pruebas de aceptacin
Disear casos de prueba de aceptacin basados en los requerimientos

que presenta el cliente.
Preparar datos de las pruebas de aceptacin.
Validar datos de los casos de prueba de aceptacin.
Procedimiento de la prueba.

Ejecutar las pruebas de aceptacin para validar el anlisis de
requerimientos del cliente.
Comparar los resultados de las pruebas con los casos de prueba iniciales.
Documentar las pruebas de aceptacin.
21.3.2. Diseo de casos de prueba de aceptacin

Para las pruebas Alfa descritas en el punto 4.2.1 se considera que los encargados
de apoyar la labor del usuario mantengan un registro de los eventos que realiza el
usuario durante la ejecucin del sistema, mediante la siguiente tabla que detalla
la informacin necesaria para la realizacin de la prueba.
Como la prueba se realiza primordialmente basndose en la interfaz del

sistema, se pide que la captura de los datos se realice considerando el nombre
de la funcionalidad que se est manipulando, en cuanto a los entornos de
prueba, se sugiere dar a conocer con ms detalle que elementos se estn
manipulando. El resultado indicar el estado en que se encuentra el mdulo
con defectos, siendo del tipo Urgente, Controlada, Puede esperar, Vital.
Finalmente, las observaciones especifican de mejor forma cmo se produjo el
defecto o falla.
PRUEBAS ALFA
Encargado : Fecha :
Funcionalidad Entorno de prueba Resultado Observaciones

Prueba
Ilustracin IV-1: Prueba Alfa
Adems, se solicitar al usuario que finalizado el testeo de prueba complete un

formulario o cuestionario con preguntas relacionadas con su desempeo.
Para las pruebas Beta descritas en el punto 4.2.2 se considera la participacin

del usuario frente al sistema, en este caso, el ambiente de prueba no contar
con una persona encargada de guiar al usuario, sino que su entorno de prueba
ser privado y la ejecucin la estimar el usuario en un ambiente propicio. Se
podr incluir adems sugerencias en cuanto a la interaccin y manipulacin del
sistema.
PRUEBAS BETA
Usuario :
Fecha:
Prueba Observaciones
realizada
Ilustracin IV-2: Prueba Beta
21.3.3. Verificacin de calidad del producto

Se realizar a travs de una lista de Chequeo y donde se considerar un
cuestionario para las siguientes caractersticas: Correccin, Fiabilidad,
Eficiencia, Integridad, Facilidad de Uso y Facilidad de Mantenimiento.
Cuestionario
Caracterstica Pregunta Evaluacin
Fiabilidad 1. La informacin que actualmente 1= Inaceptable

entrega el sistema le parece fidedigna? 2= Bajo el promedio
3= Promedio
4= Bueno
5= Excelente
Correccin 1. El sistema hace lo que uno le pide? 1= Inaceptable

Y cmo lo calificara?
2= Bajo el promedio
3= Promedio
4= Bueno
5= Excelente
A modo de resumen, en esta tabla 3 se presenta la Lista de chequeo para las

caractersticas de fiabilidad y correccin.
21.3.4. Procedimiento y evaluacin de la prueba
21.3.4.1. Criterio de aceptacin
El cliente elaborar un ranking para cada Caso de Uso (CU) con las siguientes
prioridades: ALTA, MEDIA o BAJA y en base a ellas se le asignar un mayor
nmero de pruebas para los CU con un mayor nivel de prioridad.
Las pruebas sern validadas por el usuario, y posteriormente los resultados

obtenidos sern entregados en una tabla de evaluacin de las pruebas, la cual
debe poseer al menos un 85% de satisfaccin para el Software sea aprobado.
21.3.4.2. Criterio de evaluacin
Se realizar una asignacin de pesos para cada una de las sub-caractersticas de

calidad.
Evaluacin de pruebas
Participantes: Fecha:
Tipo prueba: rea /Equipo(a realizar la prueba):
Porcentaje de satisfaccin obtenido:
Anlisis de resultados:
Ilustracin IV-3: Evaluacion de pruebas
21.3.5. Anlisis de resultados
Los resultados pueden obtenerse en base a dos criterios: respuestas a las

preguntas de las listas de chequeo y la ponderacin.
Dar respuesta a las distintas preguntas de las listas de chequeo.
Las respuestas a las preguntas de las listas de chequeo se pueden dar de forma
directa o mediante la realizacin de casos de prueba. De realizarse a travs de los
casos de prueba, las respuestas dependern de los resultados en los mismos.
Los casos de prueba sern evaluados por medio de la siguiente escala:
Escala de Evaluacin
Aprobado 5
No Falla menor 3
Aprobado
Falla Grave 1
Ilustracin IV-4: Escala de Evaluacion
21.3.5.1. Ponderacin de Resultados
A partir del procesamiento de las respuestas dadas en las listas de chequeo,

se generan tres tipos de resultados, no excluyentes:
Resultados de la presencia de las sub-caractersticas en cada etapa del

proceso de prueba, segn la caracterstica de calidad a la que corresponde.
Se calcula el promedio aritmtico de las respuestas de cada pregunta de la

sub-caracterstica que se est evaluando.
Sobre la base de los promedios anteriores, la presencia de las sub

caractersticas tendrn los siguientes valores:
1= La sub-caracterstica no est presente en esta etapa.

2= La sub-caracterstica se presenta de manera muy deficiente.
3= La sub-caracterstica se presenta medianamente.
4= La sub-caracterstica se encuentra presente.
5= La sub-caracterstica se encuentra altamente presente.

Resultados de la presencia de las caractersticas de calidad (PCC) en cada
una de las etapas, considerando la importancia dada por los
involucrados.
Una vez obtenidos los resultados de todas las sub-caractersticas, se
proceder a realizar los clculos para obtener la evaluacin de la
caracterstica de calidad. Este clculo se realizar de la siguiente
manera:

Se calcula el promedio ponderado de las sub-caractersticas tomando en
cuenta los pesos que le han sido asignados a cada una de ellas.

Para calcular este promedio ponderado se multiplican los valores
obtenidos de cada sub-caracterstica (SC) por su peso correspondiente
(P).

Se suman los valores obtenidos de la multiplicacin y se divide este valor
entre la suma de todos los pesos. Este clculo se representa a travs de
la siguiente frmula:
Este resultado representa la evaluacin de la presencia de la

caracterstica de calidad dentro de una etapa. Esta evaluacin ser
representada en un rango del 1 al 5, al igual que los resultados dados
para las sub-caractersticas.
El valor obtenido es llevado a porcentaje con el fin de identificar si el mismo

tiene el nivel de satisfaccin. Como se ha determinado que el porcentaje
de aceptacin o satisfaccin sea de un 85%. Para los casos de que no alcance
este valor mnimo de presencia se recomienda que sea revisada la
caracterstica en todo el proceso de desarrollo del software.

Resultados de la
presencia de las caractersticas de calidad en todo el
sistema (PCCS).

Despus de realizar las evaluaciones de las caractersticas de calidad en
cada una de las etapas del proceso de prueba, se obtiene el porcentaje
de presencia de cada una de las caractersticas de calidad en todo el
sistema (PPCS) el cual es el promedio de los porcentajes de presencia de
cada una de las caractersticas en cada etapa del proceso de prueba
(PPCE).
Es importante sealar que se tom, nuevamente, como nivel de

satisfaccin de la caracterstica de calidad un valor del 85%. Una
presencia con un valor por debajo del 85% se considera deficiente en el
Software que se est evaluando.
Luego de la ejecucin de las pruebas, los resultados deben superar el

85% de satisfaccin, de lo contrario el sistema no estara cumpliendo con
los atributos de calidad mnimos requeridos, ni tampoco con el avance
requerido por el proyecto. Segn lo solicitado por calidad, si el nivel de
satisfaccin obtenido fuese menor al esperado (85%) se deber realizar
nuevamente las pruebas hasta alcanzar el nivel establecido.
Se realizar un informe resumen con los datos seleccionados de los casos

de prueba para realizar el anlisis y determinar el porcentaje de pruebas
satisfactorias. Los datos del anlisis general se resumen en la siguiente
tabla:
Anlisis de resultados
Tipo de Alfa
prueba:
Resumen
Cantidad de pruebas % pruebas satisfactorias

realizadas
Nmero Aceptadas
de Pruebas Rechazadas
Modificadas
Comentarios:
Ilustracin IV-5: Anlisis de Resultado General
V. CONCLUSIONES Y
RECOMENDACIONES
Las pruebas de sistema permiten probar, validar, verificar tantos los requisitos
del negocio como la arquitectura del sistema.
Las pruebas de sistema deben ser realizadas por un equipo de tcnicos

especializado en prueba y los requerimientos del sistema deben ser completos
y estar correctamente documentados.
Las pruebas de sistema nos permiten obtener una visin muy similar a su
comportamiento en produccin por ello estas pruebas se deben ejecutar en un
entorno muy similar al de produccin para minimizar el riesgo de encontrar
fallos especficos en l.
Las pruebas de aceptacin nos permiten obligar a definir que los requisitos sean
verificables, adems de valorar adecuadamente el esfuerzo asociado a la
incorporacin de un requisito.
Los requerimientos y las pruebas de aceptacin conducen el proceso de

desarrollo, y sobretodo marcan el cierre de las pruebas, por ende el producto
aceptado.
Para las pruebas de aceptacin es recomendable que se cuente con criterios de

aceptacin previamente aprobados por el usuario.
Estas pruebas se deben realizar en el entorno en que se pondr en produccin

el sistema, es decir en el ambiente en donde se incluye al personal donde har
uso del producto.
Es indispensable tener presente que se deben validar la documentacin y los

procedimientos de uso, por ejemplo mediante una auditora.
BIBLIOGRAFIA

The Art of Software Testing (Second Edition) - Glenford J. Myers

Ingeniera del Software (Sptima edicin) - Ian Sommerville

http://woombat140512.blogspot.pe/2013_06_01_archive.html

http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-
Sistema.pdf

INTECO. Instituto Nacional de Tecnologias de Comunicacion. [Online].;
2009 [cited 2012 [Plan Avanza 2 - Ministerio
de Industria, Turismo y
Comercio de Espaa]. Available from.

Qualilfication Board. [Online] 2010;
ISTQB. International Software Testing
Programa de estudio nivel bsico.

F. Alonso Amo, Loic Martnez Normand. Introduccin a la Ingeniera del
software. Primera edicion
ed. Barbero Ruiz J, editor. Espaa: Delta
Publicaciones, 2005.

Natalia Juristo, Ana M. Moreno, Sira Vegas. Tcnicas de evaluacin de
software.
[http://www.grise.upm.es/htdocs/sites/extras/12/pdf/Documentacion
_Evaluacion_7.pdf]
SWEBOK. Gua al cuerpo de conocimiento de la ingeniera del software.

2004. Proyecto del comit de la prctica profesional del IEEE Computer
Society. [http://www.cc.uah.es/drg/b/HispaSWEBOK.Borrador.pdf]

Grupo 5

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Grupo 5

Hochgeladen von

Copyright:

Verfügbare Formate

PRUEBAS DE SISTEMA Y ACEPTACIN

Las aplicaciones, sistemas o cualquier mecanismo diseado e implementado por un

Siguiendo el proceso de desarrollo software, tras la realizacin del anlisis, diseo y

As tambin la importancia que tiene la fase final, de las Pruebas de Aceptacin (o

En el presente trabajo se har nfasis principalmente a las Pruebas de Sistemas y

Responde a dos grandes preguntas:

2. El sistema est en condicin de ser liberado?

Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos

Cualquier pieza de software completo, desarrollado o adquirido, puede verse como

Las pruebas de sistema tienen como objetivo ejercitar profundamente el

Un problema clsico de la prueba de sistema es sealar con el dedo. Esto

Disear ruta de manejo de errores que prueben toda la informacin

En realidad, la prueba de sistema abarca una serie de pruebas diferentes cuyo

Ilustracin I-1. Pruebas de Software (Testing)

3. IMPORTANCIA DE LAS PRUEBAS DE SISTEMA

4. VISIN SISTMICA DE LA PRUEBA

Cuando se deben realizar pruebas, debe mantenerse un enfoque sistmico, es

4.1. Principios base para la prueba

5. VISIN GENERAL DE LA PRUEBA DE SISTEMA

La etapa de preparacin de pruebas incluye al menos tres actividades:

a. Preparar un plan de pruebas.

b. Preparar una lista de verificaciones de los requerimientos.

c. Preparar casos de prueba.

Para ejecutar la segunda y la tercera actividad se requiere contar con el

Ilustracin 0-2: Suposiciones de Pruebas de Sistemas

La primera etapa de pruebas provee retroalimentacin para el anlisis de

La etapa de aplicacin de pruebas requiere del plan de pruebas y de una versin

Esta segunda etapa provee retroalimentacin a la implementacin y al diseo,

La prueba de sistemas tiene varias suposiciones importantes:

Cada unidad que forma el sistema ha sido probada y se han eliminado

El segundo punto es importante, ya que algunas veces se confunde la prueba

El plan de pruebas es un documento muy importante dentro del proceso de

A continuacin, se muestra una propuesta mnima de contenido, para

Productos a entregar: desde el propio plan, los casos y

procedimientos de prueba, los resultados.

Para comenzar el proceso de pruebas del sistema se parte del documento de

Un documento de requerimientos debe contener la lista de las funciones que se

Un documento de requerimientos bien preparado debe proveer, para cada

Por el momento concentraremos la atencin en los requerimientos funcionales,

La actividad de preparar lista de verificacin incluye los pasos siguientes:

8. E/S, TAREAS Y ROLES DE PRUEBAS DE SISTEMA

Plan de pruebas de Sistema.

Preparacin del entorno de pruebas. Se recomienda la existencia

Informe de Pruebas de Sistema.

Ilustracin 0-3: E/S, Tareas y Roles de Pruebas de Sistema

Las pruebas de sistema normalmente son llevadas a cabo por un equipo

Las pruebas de sistema requieren un entorno de pruebas controlado en lo que

Ilustracin 0-4: Flujo de Control de Pruebas de Sistema

9. TIPOS DE PRUEBAS DE SISTEMA

Ilustracin 0-5: Tipos de Pruebas de Sistemas

9.1. Prueba de Almacenamiento

9.2. Prueba de Comunicaciones

9.3. Prueba de Configuracin

9.4. Prueba de Desempeo

Con frecuencia las pruebas de desempeo se vinculan con pruebas de

9.5. Prueba de Disponibilidad de datos

9.6. Prueba de Entorno

9.7. Prueba de Facilidad de uso

9.8. Prueba de Implantacin

9.9. Prueba de Instalacin

9.10. Prueba de Documentacin

9.11. Prueba de Operacin

9.12. Prueba de Recuperacin