Prueba de Sistema y Aceptacion

Prueba de Sistema y Aceptacin
Ao de la Diversificacin Productiva y del Fortalecimiento de Educacin
Universidad Nacional San Luis Gonzaga de Ica

Facultad de Ingenieria de Sistemas
Tema: Prueba de Sistema y Aceptacin

Curso: Pruebas de Software
Docente: Mg. Alonso Morales
Integrantes:
Arenas Yataco, Esther
Aybar Carmona, Jerson
Pacheco Vargas, Ricardo
Pario Prada, Angelica
Quispe Conde, Frans
ICA-PERU
2015
2
FIS-UNICA
DEDICATORIA
Este presente trabajo de Prueba de Sistema y

Aceptacin dedicamos a nuestros progenitores por
innumerables
motivos
que
hayan
logrado
encaminarnos por el buen camino y as lograr el
objetivo deseado.
Dedicamos tambin a Mg. Alonso Morales de
Pruebas de Software por la gua y orientacin prestada
as lograr el presente proyecto
3
FIS-UNICA
Introduccin
Las pruebas de software son los procesos que permiten verificar y revelar la
calidad de un producto software antes de su puesta en marcha. Bsicamente, es
una fase en el desarrollo de software que consiste en probar las aplicaciones
construidas.
Las pruebas de sistemas conforman uno de los niveles de pruebas de software
conjuntamente con diversas pruebas como pruebas recuperacin, seguridad,
resistencia, desempeo, comunicacin, volumen, tensin, disponibilidad de
datos, facilidad de uso, operacin, entorno, almacenamiento, configuracin,
instalacin y documentacin. Cada cual tiene diversa finalidad y con un objetivo
en comn que demuestre una visin sistemtica para proyecto.
Las pruebas de aceptacin es otro tipo de nivel que se complementa en los
niveles de pruebas de software, estas pruebas son muy fundamentales ya que
son las que nos van a permitir que el producto cumpla con los estndares
necesarios y que a la vez satisfaga a los usuarios de acuerdo a los
requerimientos que plantearon desde un inicio.
4
FIS-UNICA
ndice
Contenido
Dedicatoria ................................................................................................................................... 2
Introduccin ................................................................................................................................. 3
ndice de Figuras .......................................................................................................................... 5
ndice de Tablas ............................................................................................................................. 5
1. Prueba de Sistema..................................................................................................................... 6
1.1 Visin Sistemica de la Prueba ............................................................................................. 8
1.2 Visin General de la Prueba de Sistema................................................................................ 9
1.3 Plan de Pruebas ................................................................................................................. 10
1.3.1 Preparar plan de pruebas ............................................................................................ 10
1.3.2 Preparar lista de verificacin .......................................................................................... 11
1.3.2.1 Detalle a partir de Ancora........................................................................................ 13
1.3.2.2 Detalle a partir de Casos de uso ................................................................................. 14
1.3.3 Preparar casos de prueba ............................................................................................... 15
1.3.3.1 Forma general de los casos de prueba ................................................................... 16
1.3.3.2 Entrada Simultanea .................................................................................................... 17
1.3.3.3 Entrada en varias etapas ............................................................................................ 19
1.3.3.4 Beneficios a partir de la preparacin de casos de prueba ......................................... 20
1.3.4 Ejecucin caso de prueba..21
1.3.4.1 Prueba Funcional ........................................................................................................ 21
1.3.4.2 Prueba No Funcional ................................................................................................... 22
2. Prueba de Aceptacin ........................................................................................................... 26
2.1 Estudio de la situacin actual en Pruebas de Aceptacin .............................................. 26
2.2. Objetivo de la pruebas de aceptacin ............................................................................... 27
2.3 Generacin de las pruebas de aceptacin ......................................................................... 28
2.4 Estrategias de pruebas de aceptacin ............................................................................. 28
2.4.1 Prueba Alfa ..................................................................................................................... 28
2.4.2 Prueba Beta .................................................................................................................... 28
2.5 Entradas, salidas, tareas y roles de pruebas de aceptacin. .............................................. 29
2.6 Criterios de pruebas de aceptacin ................................................................................. 30
2.7 Herramientas para pruebas de aceptacin ........................................................................ 31
FIS-UNICA
2.8 Garanta de calidad o control de calidad con respecto a pruebas de aceptacin ............. 31
3. Implementacin de Prueba de Sistema y Aceptacin ........................................................ 32
3.1 Implemetacin de Prueba de Sistema .............................................................................. 32
3.1.1 Generacin de objetivos de prueba a partir de casos de uso ......................................... 32
3.1.2 Implementacin de pruebas del sistema ........................................................................ 33
3.2 Implementacin de pruebas de aceptacin ..................................................................... 41
3.2.1 Pruebas de aceptacin automtica............................................................................... 42
3.2.2 Implementacin ............................................................................................................... 49
Conclusiones y recomendaciones ............................................................................................. 50
Bibliografa.................................................................................................................51
ndice de Figuras
Figura 1.- Prueba de sistema ............................................................................................................... 6
Figura 2.- Proceso de prueba de sistema ............................................................................................ 9
..26
Figura 3.- Flujo de control de pruebas de aceptacin.......................... Error!
Marcador no definido.
Figura 4. Arquitectura de Prueba de Sistema. .................................................................................. 33
Figura 5. Ejecucin del caso de prueba del escenario principal con la herramienta Selenium. ....... 39
Figura 6. Implementacin del caso de prueba. ................................................................................. 40
Figura 7.- Alternativas de Especificacin........................................................................................... 44
Figura 8.- Descripcin narrativa ........................................................................................................ 45
ndice de Tablas
Tabla 1. Bitcora de Ancora. ............................................................................................................... 13
Tabla 2. Caso de prueba con condiciones. ........................................................................................ 18
Tabla 3. Comportamiento generico de un caso de prueba . ............................................................. 34
.......................................36
Tabla 4. Caso de uso bajo prueba. ....................................................... Error!
Marcador no definido.
Tabla 5. Requisito de informacin de los enlaces. ............................................................................ 37
Tabla 6. Escenarios del caso de uso. ................................................................................................. 37
Tabla 7. Escenario principal............................................................................................................... 38
Tabla 8. Variables identificadas para el caso de uso. ........................................................................ 38
Tabla 9. Categoras para las variables identificadas.......................................................................... 38
Tabla 10. Traduccin a cdigo ejecutable de los pasos realizados por el usuario en el escenario
principal. ............................................................................................................................................ 40
Tabla 11. Traduccin a cdigo ejecutable del test Oracle para el escenario principal. .................... 41
6
FIS-UNICA
Prueba de Sistema
1. Prueba de Sistema
Cualquier pieza de software completo,

desarrollado o adquirido, puede verse como un
sistema que debe probarse, ya sea para decidir
acerca de su aceptacin, para analizar defectos
globales o para estudiar aspectos especficos de su
comportamiento, tales como seguridad o
rendimiento. A ste tipo de pruebas donde se
estudia el producto completo se les llama Pruebas
de Sistema.
Figura 1: Prueba de Sistema
La prueba de sistemas usualmente es de caja negra, especialmente si quien prueba no

tiene acceso al cdigo fuente del producto a probar, que es lo ms frecuente.
Las Pruebas de sistemas no son procesos para probar las funciones del sistema o del
programa completo, porque esta seria redundante con el proceso de las pruebas
funcionales. Las pruebas del sistema tienen un propsito particular: para comparar el
sistema o el programa con sus objetivos originales (Requerimientos funcionales y no
funcionales). Dado este propsito, se presentan dos implicaciones.
1. 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.
2. Las pruebas de sistema, por definicin, son imposibles si no estn 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.
7
FIS-UNICA
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:
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.
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.
El sistema es probado para verificar si cumple con sus requisitos funcionales y
tcnicos.
El sistema es probado en un entorno lo ms parecido al entorno de produccin.
Las pruebas de sistema permiten probar, verificar y validar, tanto los requisitos
de negocios como la arquitectura de la aplicacin.
8
FIS-UNICA
1.1 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:
a) 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.
b) Todo sistema tiene una serie de elementos que lo forman y la interaccin de
tales elementos se orienta a satisfacer los objetivos.
c) 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 salidas.
d) Ningn sistema existe en aislamiento; siempre interaccionan con otros sistemas
constituyendo un sistema mayor.
Al aplicar esos conceptos a la prueba de software, se obtienen una serie de principios

que servirn de base para la prueba:
1. 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.
2. 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 especialmente a los
casos de prueba que muestran el cumplimiento de los objetivos.
3. 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.
9
FIS-UNICA
1.2 Vista general de la prueba de sistemas

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 actividades se requiere contar con el documento
de requerimientos.
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 analizarn los resultados y se identificarn posibles
defectos.
Esta segunda etapa provee retroalimentacin a la implementacin y al diseo,
mostrando posibles defectos que deben ser corregidos. Tambin provee informacin
que ser de utilidad en la liberacin del sistema, su aceptacin, la estimacin de su
confiabilidad y para su mantenimiento.
10
Figura 2: Proceso de prueba de sistema
FIS-UNICA
La prueba de sistemas tiene varias suposiciones importantes:

a) Cada unidad que forma el sistema ha sido probada por separado y se han
eliminado sus defectos.
b) Las interfaces humano-computadoras (de texto o grficas) han sido probadas
tambin por separado.
c) 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. Sin embargo, las herramientas que
ayudan a la prueba de interfaz pueden utilizarse para iniciar las pruebas de sistema.
1.3 Plan de pruebas

Los casos de prueba y cmo se utilizan en la prctica informalmente. Surgen varias
preguntas: cuntos casos sern suficientes? Cmo generar los menos posibles? Qu
valores son adecuados?
1.3.1 Preparar un 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 8294. A continuacin se muestra
una propuesta mnima de contenido, para proyectos pequeos y medianos.
a) Identificacin del plan de pruebas y el sistema al que se aplica.
b) Elementos a probar: qu mdulos, clases, casos de uso se van a probar; Cuando
se emplea desarrollo iterativo, deben especificarse las prestaciones
(funcionalidades) a probar y cules no se probarn (ya sea que se probaron
antes o que se implementarn despus).
c) Enfoque: vista general de la estrategia de prueba.
d) Criterio de aceptacin o rechazo de un caso de prueba: criterio para dar por
bueno o malo un caso de prueba al ser ejecutado.
e) Criterio de suspensin: ya sea por tiempo o por cobertura.
f) Productos a entregar: desde el propio plan, los casos y procedimientos de
prueba, los resultados.
g) Tareas a realizar para satisfacer el proceso.
11
FIS-UNICA
h)
i)
j)
k)
l)
Necesidades ambientales: hardware, software y espacio de trabajo necesarios.

Responsabilidades: quin 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.
1.3.2 Preparar 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:

a) Asegurarse 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.
b) Revisin de las descripciones: cada descripcin debe revisarse para asegurarse
que se entiende claramente, que efectivamente es realizable.
12
FIS-UNICA
Ejemplos:
Una funcin muy comn en los sistemas de informacin es la de identificar al usuario
pidiendo un nombre y una contrasea. Una manera de describir la forma de verificar
seria la siguiente:
Se introduce el nombre y la contrasea de un usuario registrado y entonces se activa
el sistema habilitando las opciones a que tenga derecho
Una forma ms completa podra agregar como casos alternos:
Se introduce un nombre y contrasea que no coinciden con un usuario registrado y
entonces se activa una ventana donde se muestra un mensaje especificando el error
cometido.
Suponga una funcin donde un cliente de una papelera desea saber qu tipos de
cuadernos existen y su precio de mayoreo, eligiendo el concepto cuaderno en un
catlogo. La forma de verificar podra ser como sta:
El cliente selecciona Cuaderno en el catlogo de productos y oprime el botn
Buscar; el sistema mostrar una pgina con los diferentes tipos y marcas, con su
precio al menudeo y su precio de mayoreo. Si no se oprime ningn botn en 30
segundos, aparecer un mensaje que solicite elegir un producto y que indique que se
oprima un botn.
Debe observarse que estas frases, que indican cmo verificar, no constituyen casos de
prueba, aunque s ofrecen una gua para prepararlos. Algunas recomendaciones para
estas listas son las siguientes:
a) Comenzar siempre por el funcionamiento tpico deseado, el que se considerar
un xito del sistema.
b) Si existen casos alternos aceptables, describirlos despus.
c) Finalmente, describir casos que se consideran fracasos, pero que estn (o
deben estar) considerados en la programacin, generalmente en forma de
validaciones.
d) Escrbalos de manera clara y concreta, en tiempo presente y evite frases
condicionales como: podra oprimir o debera escribir un identificador; en
su lugar, escriba: oprima... o escriba identif.
e) Si existe algn requerimiento no funcional asociado con la verificacin,
asegrese de anotarlo en el documento de requerimientos. Por ejemplo, en el
caso de la identificacin es comn considerar que tiene un mximo de tres
intentos.
13
FIS-UNICA
Si utiliza una metodologa que ayude a la recoleccin y manejo de requerimientos, es

posible que esta forma de verificar ya est escrita. Por ejemplo, la metodologa ncora
(Sumano, 2006) utiliza una bitcora donde se exige anotar la manera de verificar cada
quinteta que representa una accin iniciada por un papel (usuario). Algunos enfoques
de Casos de Uso sugieren describir los pasos ms importantes que se siguen en cada
caso de uso, incluyendo caminos alternos. Esta informacin es bastante similar a la que
se indica como verificacin.
Estos dos casos se tratarn en las secciones siguientes. Si la metodologa que utiliza no
incluye ste elemento o si el software ya existe y no se cuenta con un documento de
requerimientos adecuado, usted puede preparar esa lista de verificaciones.
1.3.2.1 Detalle a partir de ncora

La metodologa ncora permite identificar de manera precisa la funcionalidad
requerida por el usuario y ofrece una serie de artefactos tiles en la preparacin de
pruebas. El principal de stos es la Bitcora de Desarrollo.
La Bitcora de Desarrollo contiene la lista de quintetas diferentes que se identificaron
en los Guiones de la propuesta computacional del sistema; para cada quinteta incluye
un campo que indica cmo verificar y otro con el tiempo estimado de desarrollo. Para
fines de las pruebas interesan los dos primeros.
Tabla 1: Bitcora de Ancora
Referencia: Una quinteta incluye un papel, una accin (verbo), un utensilio principal, un utensilio auxiliar
opcional y una periodicidad opcional.
Como se indic antes, esta forma de verificar debe revisarse y completarse, de modo
que se asegure contar con:
a) Descripcin de la accin iniciada por el papel (primer elemento de la quinteta) y
la respuesta del sistema (lo que ser visible y quiz parte no visible, como
actualizacin de una base de datos).
b) Descripcin de variantes del caso tpico, si los hubiera.
c) Descripcin de al menos un caso fracasado.
14
FIS-UNICA
Los casos fracasados pueden incluir algunos de los siguientes:

1. Equivocacin en los datos proporcionados por el papel.
2. Falta de disponibilidad de algn componente del sistema (pieza de software,
base de datos, etc.)
3. Falla del hardware.
4. Otro problema del ambiente del sistema.
1.3.2.2 Detalle a partir de Casos de Uso

Una alternativa muy popular para definir la funcionalidad de un sistema es el empleo
de casos de uso. Para stos existe una notacin semiformal dentro del estndar UML,
orientada a su representacin grfica, pero existen muchas variantes acerca de los
detalles que acompaan a dicha notacin. En esta seccin usaremos algunas ideas
tomadas del mtodo ICONIX [Rosemberg, 1999], del Proceso Unificado [Jacobson et al,
2000] y del enfoque de Select Perspective [Select, 2005], que se describen
brevemente.
En todos los mtodos que utilizan el Lenguaje Unificado de Modelado (UML), la
descripcin general de lo que hace el sistema se representa en un Modelo de Casos de
Uso, el cual contiene actores, casos de uso y relaciones entre ellos.
Un Caso de Uso corresponde a una forma en que un actor utilizar el sistema, es decir,
a una funcionalidad o prestacin. Cada caso de uso se representa grficamente como
un valo con un texto que indica su funcin, usualmente un verbo o una frase verbal.
Usualmente la forma grfica no es suficiente para documentar las prestaciones de un
sistema y se acostumbra agregar una descripcin textual, que no es parte del estndar
de UML. Algunas formas de realizacin son las siguientes:
a) Proceso Unificado: la forma grfica del caso de uso se complementa con el Flujo
de Sucesos, que es una descripcin textual de la secuencia de acciones que
forman el caso de uso. Puede haber varios niveles de detalle.
b) ICONIX: se recomienda describir en forma de texto la serie de acciones que
indican la funcin que realiza el caso de uso. El autor recomienda iniciar con
una sola frase general y luego detallarla.
c) Select Perspective: en este mtodo (y su herramienta correspondiente) se
describe cada caso de uso por medio de un dilogo donde se indican las
acciones del actor y las respuestas del sistema, de manera alternada.
Como puede verse, en realidad los tres constituyen una misma forma de texto, con
diferentes detalles pero con el mismo concepto.
15
FIS-UNICA
Ejemplos.
El siguiente es un ejemplo tomado de [Jacobson et al, 2000]
Caso de uso Pagar Factura:
El comprador estudia la factura a pagar y verifica que se corresponde con el
pedido original.
El comprador planifica el pago de la factura por banco.
Cuando vence el da de pago, el sistema revisa si hay suficiente dinero en la
cuenta del comprador. Si tiene suficiente dinero disponible, se realiza la
transaccin.
La descripcin textual de los casos de uso contiene, en cierta medida, la informacin
necesaria para verificar su cumplimiento. Si no fuera suficiente, debern detallarse
ms.
1.3.3 Preparar casos de prueba

La forma de verificar de las diversas funcionalidades de un producto de software,
descritas en el formato de ncora o en Casos de Uso, son el punto de partida para la
preparacin de casos de prueba y, en ocasiones, de procedimientos de prueba.
Las funcionalidades o prestaciones de un sistema pueden separarse en dos grupos:
a) Aquellas que reciben un conjunto de entradas ms o menos simultneas y a
partir de ellas generan un resultado y
b) las que requieren una serie de interacciones con el actor (usuario), en cada una
de las cuales ste introduce una serie de datos.
El primer caso ocurre cuando las entradas deben completarse antes de que el sistema
se lance a realizar una funcin, bsicamente sin retroalimentacin que pueda influir en
el usuario. Es el caso de una sola variable, una sola accin a travs de un botn o de un
Enter, pero tambin incluye la lectura de listas de datos cuyo proceso se realiza cuando
la lista ha terminado. Un ejemplo tpico, en interfaces grficas, donde resulta muy
comn que deban llenarse varios campos (por ejemplo nombre, direccin, telfono y
rfc) y al final se oprime un botn el cual indica al sistema que la entrada est completa
y puede aplicar la funcin seleccionada.
El segundo caso ocurre cuando la entrada ocurre en varias etapas donde una de ellas
genera una respuesta parcial del sistema, la cual influye en la siguiente, ya que el
usuario no puede indicar las entradas sin tomar en cuenta la salida intermedia. Sin
embargo la funcin completa requiere de terminar todas las etapas.
16
FIS-UNICA
Un ejemplo de ste tipo es la siguiente entrada de una funcin de venta:

El empleado selecciona la opcin Consultar y el sistema le muestra una lista de
productos;
El empleado marca los productos que le interesan y al terminar oprime el botn
Cotizar; El sistema le muestra la lista de productos seleccionados y los precios de
cada uno, as como la disponibilidad; tambin deja un espacio a la derecha de cada
producto para anotar la cantidad deseada;
El empleado marca la cantidad deseada de cada uno; los no deseados los marca con un
cero. Al concluir oprime el botn Listo; el sistema genera una orden y le solicita que
indique la forma de pago;
El empleado marca Tarjeta y escribe el nmero y la compaa y oprime Termina; el
sistema verifica los datos con el banco y, si est de acuerdo, enva mensaje y un
muestra un botn Imprimir factura;
El empleado oprime el botn Imprimir factura y el sistema lo hace.
En el ejemplo es claro que existen cinco etapas de entrada de datos para completar
una sola funcin. Lo que el empleado puede ingresar en cada una depende de la
anterior.
En las tres subsecciones siguientes se describen los aspectos generales de la
preparacin de casos de prueba y los detalles cuando ocurre cada uno de los casos
mencionados.
1.3.3.1 Forma general de los casos de prueba

La idea bsica para la preparacin de casos de prueba a partir de la forma de verificar
que se trat en la seccin anterior, es como sigue:
1) Se toma la parte tpica de la forma de verificar, es decir la parte exitosa de la
funcin. Para esa parte se genera un grupo de casos de prueba, empleando
algunos de los mtodos (dominios y valores a la frontera) o bien por otros
como el de grafo causa-efecto o el de mquinas de estados.
2) Si existen caminos alternos exitosos, se hace lo mismo que en el apartado
anterior.
3) Si existen caminos alternos que terminen en fracaso, se aplica el mismo
procedimiento del primer apartado.
4) Considerando el enfoque de sistemas para prueba, se agregan casos de prueba
para situaciones no previstas en los apartados anteriores, que incluirn:
o Ausencia de algn elemento del sistema (biblioteca, clase, archivo)
o Falta de disponibilidad de recursos necesarios (acceso a sitio remoto, acceso
a base de datos, etc.) o errores en su direccionamiento (path).
o Equivocaciones del usuario (datos crticos vacos, llaves duplicadas, tipos de
datos errneos, etc.)
FIS-UNICA
17
o Situaciones del medio ambiente que afecten negativamente la operacin del

sistema (sobrecarga del equipo o la red, dispositivos en problemas (no listos,
sin papel, etc.)
Muchas de las situaciones incluidas en los apartados 3 y 4 corresponden a problemas
de validacin y manejo de excepciones que deben tomarse en cuenta y deben producir
salidas en forma de mensajes de aviso o toma de valores por omisin.
1.3.3.2 Entrada simultnea

Cuando las entradas son simultneas, usualmente la generacin de casos de prueba no
tiene mayores problemas y no es necesario hacer ms. Recuerde que los casos de
prueba utilizan valores especficos de las variables de entrada o salida, lo que los
distingue totalmente de las formas de verificar, que pueden ser ms genricas.
Como se trata de prueba de todo un sistema que rara vez trabajar en aislamiento, los
casos de prueba que toman en cuenta el medio ambiente son muy importantes y a
veces no basta representar los casos de prueba como se hizo en ejemplos de los
captulos anteriores. En muchos casos se requiere considerar las condiciones en que se
da la prueba y en ocasiones debe considerarse la manera de lograr dichas condiciones,
a travs de un procedimiento de prueba.
Las condiciones describen el contexto deseado al realizar una prueba, como puede ser
la presencia de ciertos datos en la base de datos, la ausencia de otras aplicaciones que
compitan por los recursos o el estado especfico de un objeto o una estructura de
datos (por ejemplo una pila vaca o llena al tope). Las condiciones deben expresarse en
forma de predicados especficos, sin indefiniciones.
Ejemplos de condiciones:
El usuario Gonzalo est registrado en la base de datos.
La base de datos est en el path c:\unaaplicacion\bd
La red est desconectada.
El producto Jabn no est registrado en la base de datos.
Las condiciones pueden ser de entrada y de salida, siendo ms comunes las primeras.
Puede haber varias condiciones para un solo caso de prueba.
18
FIS-UNICA
Condiciones entrada
El usuario Gonzalo
est registrado en la BD
con
contrasea
W3fY74
El usuario Gonzalo
est
registrado en la BD con
contrasea W3fY47
La red est desconectada
Entradas
Salidas
esperadas
Condiciones
salidas
usuario=Gonzalo
contra=W3fY74
Bienvenido,
Gonzalo
El men principal
se activa
usuario=Gonzalo
contra=W3fY74
Error en
contrasea
El sistema termina
ejecucin.
url=http:www/Elsiti
o.org
La red est desconectada url=http:www/Elsiti
o.org
Sitio
inaccesible
(se muestra la
pgina
www.Elsitio.org)
Tabla 2: Casos de prueba con condiciones
En algunos casos las condiciones resultan complejas de expresar o no resulta fcil

verificar su cumplimiento. Tambin puede suceder que las pruebas propuestas no sean
inmediatamente identificables para el probador o para una persona que revise los
casos de prueba. Esto puede suceder cuando no hay una manera directa de probar un
resultado y deben aplicarse varios pasos. En estas dos situaciones se hace necesario un
procedimiento de prueba. ste consiste en una serie de pasos que deben realizarse
para aplicar un grupo de casos de Prueba.
Un procedimiento de prueba puede tener tres secciones:
a) Preparativos para la prueba
b) Instrucciones especiales para aplicar los casos de prueba
c) Instrucciones para verificar los resultados y restaurar el estado original.
Los preparativos para la prueba incluyen la creacin de elementos auxiliares (como
archivos de datos y objetos), carga de registros de prueba a una base de datos y
aplicacin de otras funciones del sistema como antecedente para la funcin que se
desea probar.
Las instrucciones para la prueba pueden incluir aviso de reiniciar el estado antes de
cada caso de prueba o dejar que trabajen de manera sucesiva, sin reiniciar el estado.
La parte final puede incluir la verificacin de resultados insertados en la base de datos
o revisin de documentos impresos, as como retirar de la base de datos los registros
usados para las pruebas.
19
FIS-UNICA
Ejemplo:
1.
2.
3.
4.
5.
6.
Salve la base de datos.

Utilice una copia vaca de la base de datos.
Inserte los registros que se indican en el archivo datosPrueba.txt
Asegrese de tener deshabilitadas las conexiones de red.
Aplique todos los casos de prueba, uno a uno, sin reiniciar la base de datos.
Verifique que en la base de datos haya sido eliminado el registro del producto
Caf en polvo 250 gr.
7. Verifique que en la base de datos la cantidad del producto Azcar cubos
indique 47.
8. Elimine la base de datos de prueba y restaure la original.
Estos procedimientos de prueba pueden realizarse manualmente, programarse en
forma de script o dentro de un programa auxiliar para pruebas. El uso de scripts es
muy comn cuando se realizan pruebas automticas.
1.3.3.3 Entradas en varias etapas

La seccin anterior trat el caso en que se tiene un conjunto de entradas ms o menos
simultneas. En sta se tratar el segundo caso, cuando la entrada a un sistema se da
en etapas que no resultan independientes.
Este caso puede probarse con el mismo procedimiento del caso sencillo, siempre y
cuando se separe cada etapa en un caso de prueba y todos los pasos anteriores se
incluyan en un procedimiento de prueba. Sin embargo ste enfoque resulta poco
prctico, ya que se repetirn muchos pasos innecesariamente.
Ahora bien, la prueba de varias etapas de manera encadenada obliga a realizar un
procedimiento de prueba donde se van detallando los datos de entrada en cada etapa
y las salidas intermedias esperadas. Si cualquier paso de una salida intermedia difiere
de lo esperado, se suspende la ejecucin y se marca una falla.
Esta manera de probar usando un procedimiento que cubra las etapas requiere
cuidados especiales en la seleccin de valores. A diferencia de un caso sencillo, donde
se conocen los diversos dominios (o su equivalente, segn el mtodo), en este caso
deben considerarse valores que obliguen a seguir un camino de ejecucin
determinado, que permita cubrir las diferentes etapas. Existirn valores que pasan la
primera etapa, pero que no sigan adelante con la segunda y otros que pasen tres
etapas y fracasen en la cuarta.
20
FIS-UNICA
Por ejemplo, considere un sistema de inscripciones a diversos cursos, con diferentes

precios, de acuerdo al siguiente procedimiento de prueba:
Se registra el nombre del alumno y otros datos del mismo, terminando al oprimir
Registra; el sistema lo registra y muestra un nmero de control en un campo de la
ventana, habilitando el botn Arancel. Si ya existe un alumno con el mismo nombre,
rechaza el registro enviando un mensaje.
Cuando aparece el nmero de control se anota el tipo de curso y se oprime Arancel;
el sistema muestra la cantidad a pagar y habilita el botn Pago.
El alumno indica si el pago es en efectivo o con tarjeta (y da el nmero) y oprime
Pago; el sistema verifica y genera un recibo.
Si se desea probar la primera etapa por separado, se pueden dar nombres de alumnos
no registrados y otros ya registrados. Sin embargo, si se desea probar todo el
procedimiento hasta generar el recibo, slo se pueden elegir nombres no repetidos;
los otros producen salidas antes de generar el recibo. Igualmente, si no se elige un
curso vlido o ninguno le interesa al alumno, el procedimiento se quedar en la
segunda etapa, sin concluir.
As pues, cuando se prueba en este tipo de secuencias, debe tenerse cuidado con la
seleccin de valores que lleguen hasta el final.
Recuerde que cada unidad ya fue probada por separado, as que aqu no se trata de
volver a probar cada parte, sino el sistema como un todo.
1.3.3.4 Beneficios a partir de la preparacin de casos de prueba

Hasta aqu se ha descrito como preparar listas de verificacin de los requerimientos y
la preparacin de casos de prueba a partir de ellos, lo que llevar a asegurar el
cumplimiento de todos los requerimientos.
Como se dijo al principio, la preparacin de casos de prueba ocurre en las etapas
tempranas del desarrollo del software, cuando todava no se ha diseado ni escrito el
mismo, mientras que su ejecucin ocurrir en etapas ms avanzadas.
Sin embargo, desde la preparacin de los casos de prueba y los procedimientos
asociados ya se obtienen ganancias para la calidad del software.
Entre otras se tienen:
Las listas de verificacin del cumplimiento de los requerimientos ayudan a realizar
revisiones tcnicas al software antes de iniciar su diseo, identificando los aspectos
ms dbiles y los que pueden generar problemas; como deben estar completos, ayuda
a asegurarse que no existan requerimientos que no se pueden comprobar.
FIS-UNICA
21
Por ejemplo, si hubiese un requerimiento El sistema debe ser totalmente amigable,

sin una forma de verificar tal cosa, debe revisarse qu se entiende por amigable y,
ms an, qu debe entenderse por totalmente amigable.
La preparacin de los casos de prueba obliga a reflexionar acerca de los valores
aceptables y los no aceptables, as como las situaciones no deseadas que podran
ocurrir, como los errores del usuario o la falla de la base de datos. El tener presentes
estas situaciones permite disear una buena validacin de las entradas y
aseguramiento del ambiente, en vez de darlo por hecho. Por ejemplo, en Delphi es
comn hacer programas que abren automticamente la base de datos, desde el inicio;
si por alguna razn la base de datos tiene problemas, tales programas se cierran sin
ms trmite, dejando al usuario frustrado. De haberlo tenido en cuenta, se habra
dejado la base cerrada para abrirla ms adelante, asegurndose de su buen
funcionamiento.
Al preparar los casos de prueba se pueden identificar las funciones ms complejas, con
ms casos posibles, lo que har que se ponga cuidado especial en su desarrollo, ya que
muy probablemente sern las funciones que ms defectos tendrn.
1.3.4 Ejecucin de casos de prueba

Finalmente se puede pasar a ejecutar los casos de prueba que se prepararon con
anterioridad. Esta prueba puede realizarse en varias maneras:
1.3.4.1 Pruebas Funcionales

Prueba de Integracin
En las que el equipo de prueba tiene acceso al cdigo fuente del sistema. Cuando
se descubre un problema, el equipo de integracin intenta encontrar la fuente del
problema e identificar los componentes que tienen ser depurados. Las pruebas de
integracin se ocupan principalmente de encontrar defectos en el sistema.
Prueba de entrega
Aqu se prueba una versin del sistema que podra ser entregada al usuario. Aqu el
equipo de pruebas se ocupa de validar que el sistema satisface sus requerimientos
y con asegurar que el sistema es confiable. Las pruebas de entrega son
normalmente prueba de caja negra en las que el equipo de prueba se ocupa
simplemente de demostrar si el sistema funciona o no correctamente.
22
FIS-UNICA
1.3.4.2 Pruebas No Funcionales

Pruebas 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.
Pruebas de recuperacin
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.
Pruebas de volumen
Consisten en examinar el funcionamiento del sistema cuando est trabajando con
grandes volmenes de datos, simulando las cargas de trabajo esperadas.
Pruebas 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.
Pruebas 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.
Pruebas 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.
FIS-UNICA
23
Pruebas 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.
Pruebas 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.
Pruebas de entorno
Consisten en verificar las interacciones del sistema con otros sistemas dentro del
mismo entorno.
Pruebas de seguridad
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.
Pruebas 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.
Pruebas 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.
24
FIS-UNICA
Prueba de Rendimiento
Las pruebas de rendimiento tienen que disearse para asegurar que el sistema
pueda procesar su carga esperada. Esto normalmente implica planificar una seria
de pruebas en las que la carga se va incrementando regularmente hasta que el
rendimiento de sistema se hace inaceptable. Las pruebas de rendimiento se
ocupan tanto de demostrar que el sistema satisface sus requerimientos como de
descubrir problemas y defectos en el sistema.
Pruebas 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.
Pruebas 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.
Pruebas 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
25
FIS-UNICA
Pruebas 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.
Pruebas 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.
Pruebas de la 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.
26
FIS-UNICA
Prueba de Aceptacin
2. Pruebas de Aceptacin
La prueba de aceptacin es ejecutada antes de que la aplicacin sea instalada dentro
de un ambiente de produccin. La prueba de aceptacin es generalmente desarrollada
y ejecutada por el cliente o un especialista de la aplicacin y es conducida a determinar
como el sistema satisface sus criterios de aceptacin validando los requisitos que han
sido levantados para el desarrollo, incluyendo a documentacin y procesos de negocio
Estas pruebas se realizan para que el cliente certifique que el sistema es vlido para l.
La planificacin detallada de estas pruebas debe haberse realizado en etapas
tempranas del desarrollo, con el objetivo de utilizar los resultados como indicador de
su validez: si se ejecutan las pruebas documentadas a satisfaccin del cliente, el
producto se considera correcto y, por tanto, adecuado para su puesta en produccin.
(Isabel Ramos Romn, Jos Javier Dolado Cosn, 2007)
Las pruebas de aceptacin (Instituto Nacional de Tecnologas de Comunicacin, 2009),
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.
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. (Instituto Nacional
de Tecnologas de Comunicacin, 2009).
27
Figura 3: Flujo de control de pruebas de aceptacin
FIS-UNICA
2.1 Estudio de la situacin actual en Pruebas de Aceptacin

Dentro del tipo de pruebas que tenemos para validar el software, una de las ms
importantes son las de aceptacin (users tests). Son aquellas pruebas que son
diseadas por el propio equipo de desarrollo en base a los requisitos funcionales
especificados en la fase de anlisis para cubrir todo ese espectro, y ejecutadas por el
propio usuario final, no por todos evidentemente, pero s por una cantidad de usuarios
finales significativo que den validez y conformidad al producto que se les est
entregado en base a lo que se acord inicialmente.
Dependiendo de la complejidad del sistema a probar, si est o no dividido por
mdulos, etc. la realizacin de dichas pruebas se ejecuta de forma diferente. Si
estuviera una aplicacin dividida en mdulos, se trataran esto como subsistemas y
estudiando si tienen o no la suficiente complejidad como para tratarlos de forma
diferente, habra que realizar sesiones de prueba de aceptacin diferentes.
2.2 Objetivo de la pruebas de aceptacin

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. (INTECO, 2009)
El objetivo de las pruebas de aceptacin es validar que un sistema cumple con el
funcionamiento esperado y permitir al usuario de dicho sistema que determine su
aceptacin, desde el punto de vista de su funcionalidad y rendimiento.
Las pruebas de aceptacin son definidas por el usuario del sistema y preparadas por el
equipo de desarrollo, aunque la ejecucin y aprobacin final corresponden al usuario.
La validacin del sistema se consigue mediante la realizacin de pruebas de caja negra
que demuestran la conformidad con los requisitos y que se recogen en el plan de
pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados.
Dicho plan est diseado para asegurar que se satisfacen todos los requisitos
funcionales especificados por el usuario teniendo en cuenta tambin los requisitos no
funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los
datos y procesos, as como a los distintos recursos del sistema.
28
FIS-UNICA
2.3 Generacin de las pruebas de aceptacin

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.
2.4 Estrategias de pruebas de aceptacin

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. A menudo este tipo de sistemas tiene dos etapas de pruebas de
aceptacin.
Pruebas alfa y beta
Cuando se construye software a medida para un cliente, se lleva a cabo una serie de
pruebas de aceptacin para permitir que el cliente valide todos los requisitos. La
mayora de los desarrolladores de productos de software llevan a cabo un proceso
denominado pruebas alfa y beta para descubrir errores que parezca que slo el
usuario final puede descubrir.
A. 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.
B. 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.
29
FIS-UNICA
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.
2.5 Entradas, salidas, tareas y roles de pruebas de aceptacin
Entradas
Tareas
Salidas
Roles
Especificacin de Requisitos.
Manuales de Usuario.
Sistema probado.
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.
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.
Ingeniero de Pruebas.
Jefe de Pruebas.
Jefe de Proyecto (Cierre formal de la actividad).
30
FIS-UNICA
El hecho de centrarnos en las pruebas de aceptacin, surge de intentar reforzar la

visin de que el usuario integrado en dicha fase, de forma temprana, ayudara a
mejorar dicho proceso desde la fase de planificacin y diseo de las pruebas, con las
consiguientes mejoras de muchos aspectos cuantificables y deseables como pueden
ser:
Aumento en la calidad del software integrado

Minimizacin de costes
Aumento de la fiabilidad en los resultados del proyecto
Se produce un incremento de la satisfaccin del cliente al utilizar un software
con una cantidad de errores inferior.
Se incrementa la eficiencia del proceso de desarrollo.
2.6 Criterios de pruebas de aceptacin.

La aceptacin del software se logra mediante una serie de pruebas que demuestren
que cumple con los requerimientos. Un plan de prueba delinea la clase de prueba que
se aplicara y un procedimiento de prueba define los casos de prueba especificas tanto
el plan como el procedimiento se disean para asegurar que satisfacen todos los
requerimientos funcionales, que se alcanzan todos las caractersticas de
comportamiento, que se cumplen con todos los requisitos de desempeo, que la
documentacin es correcta y se cumple tambin con todos los requisitos de facilidades
uso y otros requisitos especificados (portabilidad, compatibilidad, recuperacin de
errores, facilidad de mantenimiento).
2.7
Herramientas para pruebas de aceptacin.
Herramienta
CANOO
CONCORDION
FITNESSE
JBEHAVE
JMETER
Descripcin
Canoo es una herramienta de Software Libre para automatizar las pruebas de
aplicaciones web de una forma muy efectiva.
http://webtest.canoo.com/webtest/manual/WebTestHome.html
Concordion es un framework Java de Software Libre que permite convertir
especificaciones en texto comn sobre requerimientos en pruebas automatizadas
http://www.dosideas.com/wiki/Concordion
FitNesse es una herramienta colaborativa para el desarrollo de software. Permite a los
clientes, testers, y programadores aprender lo que su software debera hacer, y
automticamente compara lo que realmente hace. Compara las expectativas de los
clientes a los resultados reales
http://www.dosideas.com/wiki/FitNesse
JBehave es un framework Java para mejorar la colaboracin entre desarrolladores, QA,
analistas de negocio, Dueo Del Producto y todos los miembros del equipo a travs de
escenarios automatizados y legibles.
http://www.dosideas.com/wiki/JBehave
JMeter es un proyecto de Apache Jakarta que puede ser usado para realizar una Prueba
De Carga, para as analizar y mediar la Performance De Aplicaciones de distinto tipo,
aunque con especial foco en Aplicaciones Web
http://jakarta.apache.org/jmeter/
http://www.dosideas.com/wiki/JMeter
FIS-UNICA
31
SAHI
SELENIUM
SOAPUI
9. WATIR
Sahi es una herramienta de automatizacin de pruebas para aplicaciones Web, con la

facilidad de grabar y reproducir scripts. Est desarrollada en Java y JavaScript, la
herramienta usa simplemente JavaScript para ejecutar los eventos en el browser.
http://www.dosideas.com/wiki/Sahi
Selenium es una herramienta de Software Libre para pruebas de aplicaciones Web. Las
pruebas de Selenium se ejecutan directamente en un navegador y facilitan las pruebas
de compatibilidad en navegadores, tambin como pruebas
funcionales de aceptacin de aplicaciones Web.
http://www.dosideas.com/wiki/Selenium
SoapUI es una herramienta de Software Libre grfica, est basada en Java y sirve para el
testeo de Web Service y generacin de Cliente De Web Service
http://www.dosideas.com/wiki/SoapUI
Watir es una librera simple de cdigo abierto para la automatizacin web en los
navegadores. Permite escribir pruebas que sean fciles de leer y fciles de mantener. Se
ha optimizado para la simplicidad y flexibilidad.
http://watir.com/
2.8 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
Martnez Normand)
Las pruebas 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.
32
FIS-UNICA
Implementacin de Pruebas
de Sistemas y Aceptacin
3.- Implementacin de Prueba de Sistema y Aceptacin
3.1 Implementacin de Pruebas de Sistemas
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. (ALEGSA, 2012).
En este caso se presenta un ejemplo, basado en el perfil de pruebas de

UML, para la implementacin en cdigo ejecutable de objetivos de prueba
definidos mediante escenarios y variables operacionales.
3.1.1 Generacin de objetivos de prueba a partir de casos de uso

Se resumen trabajos anteriores de los autores para obtener objetivos de prueba, los
cules son el punto de partida para desarrollar pruebas automticas.
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.
33
FIS-UNICA
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 prueba.
3.1.2 Implementacin
A. Una arquitectura de prueba del sistema
La arquitectura para la ejecucin y comprobacin automtica de pruebas del sistema
se muestran en la figura 4.
Esta arquitectura es similar a la arquitectura necesaria para la automatizacin de otros
tipos de pruebas, como las pruebas unitarias. La principal diferencia estriba en que, en
una prueba unitaria, la propia prueba invoca al cdigo en ejecucin, mientras que una
prueba funcional del sistema necesita un mediador (el elemento UserEmulator) que
sepa cmo manipular su interfaz externa. (ingsoft , 2007)
UserInterface.- La clase UserInterface representa la interfaz externa del sistema bajo
prueba.
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. El perfil de
pruebas de UML no define ningn elemento para representar los resultados obtenidos
del sistema a prueba, por lo que se ha modelado con una clase sin estereotipar.
34
Figura 4: Arquitectura de prueba de sistema
FIS-UNICA
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 prueba de diversos sistemas y existe gran variedad de ofertas en el mercado
tanto de pago como libres y gratuitas.
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). En el perfil de pruebas, todo Test Context tiene un elemento Arbiter y un
elemento Scheduler, sin embargo, ambos elementos no se van a utilizar en esta
propuesta, por lo que han sido omitidos de la figura 4.
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.
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.
B. Implementacin de los casos de prueba

Un caso de prueba es una implementacin de un objetivo de prueba. Segn el perfil de
pruebas de UML, un caso de prueba no es un elemento arquitectnico sino la
definicin de un comportamiento dentro de un elemento estereotipado como Test
Context.
El comportamiento genrico para un caso de prueba se lista en la tabla 3.
Tabla 3: Comportamiento genrico de un caso de prueba
35
FIS-UNICA
Cada caso de uso tendr asociado un test suite. Dicha suite contendr las pruebas de
todos los escenarios de dicho caso de uso.
Como se ha visto en los objetivos de prueba, en cada uno de los pasos del escenario
debe indicarse si es realizado por un actor o por el sistema a prueba. Esta informacin
es muy relevante a la hora de la codificacin de los mtodos de prueba de la suite.
Todos los pasos realizados por un actor se traducirn en el cdigo del caso de prueba a
una interaccin entre el caso de prueba y el sistema. El test oracle de un caso de
prueba ser el conjunto de ValidationActions, o acciones de validacin, obtenidas
principalmente, a partir de los pasos realizados por el sistema.
Se va a aplicar la tcnica de variables operacionales y de categora-particin para la
definicin de los valores de prueba necesarios. Se han identificado tres tipos distintos
de variables operacionales. Cada uno de los tipos se implementar de manera distinta
en los casos de prueba.
El primer tipo lo componen aquellas variables operacionales que indican un
suministro de informacin al sistema por parte de un actor externo.
Para cada variable de este tipo se definir una nueva clase cuyos objetos contendrn
los distintos valores de prueba para dicha variable. Para cada particin del dominio
identificada, el elemento TestDataPool tendr, al menos, una operacin que devuelva
un valor de prueba perteneciente a dicha particin. Un ejemplo de una variable
operacional de este tipo se muestra en el caso prctico.
El segundo tipo lo componen aquellas variables operacionales que indican una
seleccin entre varias opciones que un actor externo tiene disponible. En este caso, no
tiene sentido implementar estas variables como mtodos del TestDataPool. En su
lugar, dicha seleccin se implementar directamente como parte del cdigo que
implementa la interaccin entre el actor y el sistema. Un ejemplo de una variable
operacional de este tipo se muestra en el caso prctico.
El tercer tipo lo componen aquellas variables operacionales que indican un estado del
sistema. Para implementar el mtodo de set up del caso de prueba, se debe escribir el
cdigo necesario para establecer adecuadamente el valor de las variables
operacionales que describen los estados del sistema, o bien comprobar que dichos
valores son los adecuados. De manera anloga, el mtodo tear up debe restaurar
dichos valores a sus estados originales. Adems, el mtodo tear down debe eliminar, si
es procedente, la informacin introducida por el caso de prueba en el sistema durante
la ejecucin del caso de prueba. Varios ejemplos de variables operacionales de este
tipo se muestran en el caso prctico.
36
FIS-UNICA
Un caso prctico.
En este caso prctico (Departamento de Lenguajes y Sistemas Informticos), en
primer lugar se aplicar lo visto, para obtener un conjunto de objetivos de prueba a
partir de un caso de uso. Despus, se definen las caractersticas del Test harness
utilizado (seccin B). Finalmente, se aplica lo visto en las secciones anteriores para
implementar un caso de prueba a partir de un objetivo de prueba (seccin C). Los
artefactos del sistema bajo prueba se han definido en ingls, ya que el espaol no est
soportado por las herramientas utilizadas.
A) Objetivos de prueba
El caso de uso de la tabla 4, describe la introduccin de un nuevo enlace en el sistema.
Como complemento, se muestra tambin el requisito de almacenamiento de
informacin que describe la informacin manejada por cada enlace (tabla 5). Los
patrones usados se describen en la metodologa de elicitacin NDT. A partir del caso
de uso, y de manera automtica, se han generado un conjunto de escenarios los cules
sern los objetivos de prueba de dicho caso de uso. Dado que el caso de uso presenta
bucles no acotados, con un nmero infinito de potenciales repeticiones, criterio de
cobertura elegido para obtener los caminos es el criterio 01, el cual consiste en
obtener todos los caminos posibles para una repeticin de ninguna o una vez de cada
uno de los bucles.
Todos los escenarios obtenidos con este criterio y traducidos al espaol se listan
en la tabla 6. Para este caso prctico, seleccionamos el escenario 09, el cual se describe
en detalle en la tabla 7 (dado que el caso de uso se ha redactado en ingls, su
escenario principal tambin se muestra en ingls), para su implementacin.
Tabla 4: Caso de uso bajo prueba
37
FIS-UNICA
Tabla 5: Requisito de informacin de los enlaces
Tambin ha sido posible aplicar el mtodo de categora-particin. Todas las variables

operacionales encontradas automticamente por la herramienta ValueGen se
enumeran en la tabla 8. Las particiones para cada una de dichas variables (tambin
encontradas por la herramienta ValueGen) se enumeran en la tabla 9.
En este caso, no se ha continuado refinando el conjunto de particiones aunque para
algunas variables, como V04, s podran identificarse particiones adicionales.
Para la implementacin del escenario de xito, todas las variables operacionales deben
tener un valor perteneciente a las particiones C02.
Tabla 6: Escenarios del caso de uso
38
FIS-UNICA
Tabla 7: Escenario principal
Tabla 8: Variables identificadas para el caso de uso
Tabla 9: Categoras para las variables identificadas
39
FIS-UNICA
B) Test harness
Tal y cmo se describi en la figura 5, el test harness tiene la misin de simular el
comportamiento del usuario y ofrecer un conjunto de asertos para evaluar el resultado
obtenido.
En este caso prctico, al ser el sistema bajo prueba una aplicacin web, es necesario
que el test harness sea capaz de comunicarse con el navegador web y sea capaz
tambin de realizar comprobaciones en el cdigo HTML recibido como respuesta. Por
ellos, hemos elegido la herramienta de cdigo abierto Selenium
(www.openqa.org/selenium) la cul cumple estas caractersticas.
Como se puede ver en la figura 8, Selenium ofrece un interfaz que permite abrir un
navegador web e interactuar con l de la misma manera que un actor humano.
Respecto al catlogo de asertos, al estar basado en la popular herramienta JUnit,
Selenium incorpora el mismo conjunto de asertos que JUnit y, adems, funciones para
acceder a los resultados visualizados en el navegador web.
Figura 5: Ejecucin del caso de prueba del escenario principal con la herramienta Selenium
C) Implementacin de un caso de prueba

En primer lugar se ha implementado el data pool y los valores de prueba tal y como se
muestra en la figura 6.
40
FIS-UNICA
A continuacin, se toman todos los pasos ejecutados por el actor humano y se

traducen a cdigo Java para la herramienta Selenium. Dicha traduccin se realiza
actualmente a mano y se muestra en la tabla 5.
Figura 6: Implementacin del caso de prueba
Tabla 10: Traduccin a cdigo ejecutable de los pasos realizados por el usuario
en el escenario principal
41
FIS-UNICA
A continuacin, en la tabla 9, se escribir los asertos a partir de los pasos que realiza el sistema.
Tabla 11: Traduccin o cdigo ejecutable del test Oracle para el escenario
principal
La implementacin del mtodo de set-up consisti en comprobar que todas las

variables operacionales de la tabla 4 tuvieran un valor de la particin C02. Es decir,
comprobar que hay categoras y que no hay ninguna circunstancia que ocasione un
error al recuperar las categoras o insertar el nuevo enlace. La implementacin del
mtodo de tear down, consisti en la restauracin del conjunto original de enlaces
almacenado en el sistema.
3.2
Implementacin de pruebas de aceptacin
Las pruebas de aceptacin slo funcionan con el apoyo de los clientes, o por lo menos
un proxy para el cliente, para ayudar a definir los criterios. Sin el conductor de los
criterios de aceptacin, se hace difcil verificar si usted est construyendo el software
correcto. El cliente, junto con todos los miembros del equipo de desarrollo debe
reunirse para definir el sistema en trminos de una serie de "escenarios" que
describen lo que el sistema debe hacer y cmo debe hacerlo.
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. Sin embargo, esto implica que alguien manualmente verifique que se cumplan
los requisitos y la aplicacin funcione como se esperaba.
42
FIS-UNICA
Aqu es donde las pruebas de aceptacin automticas entran en lugar de los requisitos
en un documento obsoleto, los requisitos se definen como ejemplos y escenarios, se
protegen en control de origen con los artefactos de implementacin y se pueden
ejecutar en cualquier momento para comprobar si se implementa cualquier requisito y
funciona correctamente. Puede tomar el mismo enfoque para escribir las pruebas,
pero en lugar de escribirlos en software de administracin de casos de pruebas o en
una hoja de clculo, escribirlos directamente en el cdigo.
3.2.1 Pruebas de aceptacin automtica

Una de las prcticas ms valiosas para salir del movimiento de Software gil es un
sistema automatizado, previamente probado estilo de desarrollo, a menudo
denominado Test-Driven Development, o TDD. Un principio fundamental de TDD es
que la creacin de pruebas se trata tanto de diseo y el desarrollo de la orientacin, ya
que se trata de la verificacin y la regresin. Es tambin acerca del uso de la prueba
para especificar una unidad de la funcionalidad requerida, y el uso de esa prueba a
escribir a continuacin, slo el cdigo necesario para ofrecer esta funcionalidad. Por lo
tanto, el primer paso en la implementacin de cualquier nueva funcionalidad es para
describir sus expectativas con una prueba.
Muchos desarrolladores y los equipos han tenido gran xito con TDD. Los dems no
tienen, y encontrar que luchan con la gestin del proceso a travs del tiempo, sobre
todo porque el volumen de pruebas empieza a crecer y la flexibilidad de las pruebas se
empieza a degradar. Algunos no son seguro de cmo empezar con TDD, mientras que
otros encuentran TDD fciles de iniciar, slo para ver lo abandonaron como los plazos
cercanos a los retrasos y el telar grande.
Por ltimo, muchos desarrolladores interesados cumplir con la resistencia a la prctica
dentro de sus organizaciones, ya sea porque la palabra "prueba" implica una funcin
que pertenece a otro equipo o por la falsa percepcin de que los resultados de TDD en
cdigo extra demasiado y ralentiza los proyectos. (Satrom, 2010)
a) Enfoque Test-Driven Development (TDD)

El enfoque Test-Driven Development (TDD) se basa en que las pruebas deben dirigir el
desarrollo del producto software. El TDD se ha aplicado esencialmente en el mbito de
la implementacin, particularmente siguiendo e planteamiento no escribir cdigo
hasta disponer de las pruebas que debe satisfacer dicho cdigo. El TDD ha tenido un
fuerte impulso con las metodologas giles, las cuales lo incorporan entre sus prcticas
esenciales.
En productos software industriales, cuando se utilizan prcticas de ingeniera de
requisitos, stas mayoritariamente estn soportadas por lenguaje natural, lo cual
conlleva los ya conocidos inconvenientes relativos a ambigedad.
FIS-UNICA
43
Sin embargo, la necesidad de validacin puede ms que las ventajas que puede ofrecer
una especificacin ms formal y rigurosa de los requisitos. El cliente debe poder leer y
comprender los requisitos para as poder dar su conformidad respecto de ellos. Las
tcnicas ms populares para especificacin de requisitos se resumen en Casos de Uso
(utilizados en metodologas tradicionales, como RUP) e Historias de Usuario (fichas de
XP o representaciones similares en otras metodologas giles como Scrum). Si bien los
elementos Actor (o tipo de usuario) y Requisitos (Caso de Uso o Historia de Usuario)
pueden visualizarse y manipularse grficamente o en fichas, la descripcin de cada
requisito se elabora esencialmente de forma textual en lenguaje natural. Para definir
los requisitos es clave involucrar al cliente. El acuerdo/contrato con el cliente y la
planificacin del desarrollo del producto deberan estar basados en los requisitos que
se pretenden incorporar en el producto. Los requisitos son el objetivo a conseguir, es
decir, es lo que espera el cliente que el producto software satisfaga.
Nuestra propuesta se denomina Test-Driven Requirements Engineering (TDRE) por
referirnos a TDD pero en el mbito de los requisitos y la planificacin. TDRE integra los
artefactos, actividades y roles, asociados a la especificacin y validacin de los
Requisitos y de las Pruebas de Aceptacin. El concepto de Requisitos se convierte en
un contenedor de Pruebas de Aceptacin, y son stas las que adquieren protagonismo
como especificacin de cada requisito. Una de las ocho buenas caractersticas que
recomienda la IEEE 830 para una especificacin de requisitos se refiere a que cada
requisito debe ser Verificable. En nuestra propuesta los requisitos son verificables
pues estn especificados como Pruebas de Aceptacin.
b) TDRE
Para comprender cmo los requisitos pueden ser especificados mediante Pruebas de
Aceptacin comenzaremos con un ejemplo. Consideremos el requisito Retirar dinero
en el contexto de un cajero automtico. Una tpica especificacin narrativa podra ser
la siguiente:
El cliente debe poder retirar dinero del cajero en cantidades seleccionables. Siempre
recibe un comprobante, a menos que el cajero se quede sin papel. Cuando se trata de
un cliente preferencial puede retirar ms dinero del que tiene en su cuenta, pero se le
debe advertir que se le cobrarn intereses. El cliente debera poder cancelar en
cualquier momento antes de confirmar el retiro de dinero. Las cantidades deberan
poder servirse con los billetes que en ese momento tenga el cajero y no se deberan
aceptar otros montos. Sera conveniente avisar cuando el cajero est realizando
operaciones internas mostrando un mensaje: El dinero retirado de la cuenta debe
poder comprobarse en los registros de movimientos de la cuenta.
44
FIS-UNICA
Figura 7: Alternativas de Especificacin
La Figura 7 ilustra algunas alternativas de especificacin para este requisito

(incluyendo la anterior descripcin narrativa como opcin por defecto). Los iconos
reflejan la conveniencia de cada alternativa de especificacin. Elaborar un Diagrama
de Secuencia para definir cada escenario de ejecucin del requisito puede parecer
interesante, sin embargo, en general no resulta apropiado por la gran cantidad de
diagramas generados. Resulta ms interesante la identificacin de los escenarios que
la ilustracin de cada uno de ellos en un diagrama.
La descripcin narrativa no es descartable, al menos para dar una breve definicin del
requisito centrndose en definir los conceptos involucrados (con la idea de un glosario
o de un sencillo Modelo de Dominio).
Un Modelo de Casos de Uso no es mala idea, especialmente para organizar y visualizar
los requisitos de un sistema nuevo. Sin embargo, un Modelo de Casos de Uso no es
apropiado para ilustrar la estructura de requisitos detallada de un producto software
en situaciones de mantenimiento a ms largo plazo, ya que un producto software de
tamao medio puede tener miles de requisitos. La visualizacin y gestin de gran
cantidad de requisitos necesita de mecanismos ms apropiados.
Los bocetos (visualizaciones muy preliminares) de la Interfaz de Usuario (IU) son
siempre bienvenidos pues son una herramienta efectiva de comunicacin y validacin
con el cliente, el cual puede hacerse una idea del producto. En este contexto de
requisitos no debe pretenderse realizar el diseo final de las IUs sino ms bien paneles
con cierto mbito de datos, sin profundizar en tipos de controles de interfaz o
cuestiones de esttica de formularios/pginas. Las plantillas son una de las
alternativas de especificacin ms usadas para Casos de Uso. Las plantillas son
elegantes y proporcionan una sensacin de orden en la especificacin. Sin embargo, en
general resultan contraproducentes ya que tienden a dar un tratamiento uniforme en
cuanto al nivel de detalle para todos los requisitos.
FIS-UNICA
45
En aquellos muy simples se tiende a incluir cosas obvias o irrelevantes slo para poder
cubrir todos los apartados de la plantilla. Cuando un requisito incluye varios (o
muchos) escenarios, el intento por sintetizar todos los escenarios en una plantilla (que
slo ofrece pasos y excepciones) lleva normalmente a especificaciones enrevesadas.
Figura 8: Descripcin narrativa
Nuestro enfoque TDRE apuesta por especificar los requisitos usando los elementos que
se muestran en la Figura 8: una breve descripcin narrativa que establece los
conceptos y motivacin del requisito, bocetos de la IU (si procede) y una lista de
Pruebas de Aceptacin (PAs). Estas PAs se refinarn desde simples frases que dan
nombre a los escenarios, hasta pruebas diseadas, listas para ser aplicadas o para
automatizarse y aplicarse en regresin. As, los requisitos actan como contenedores
para la Pas. Dependiendo del requisito, podra ser til utilizar otras formas de
especificacin con carcter complementario. Por ejemplo un Diagrama de Actividad si
el comportamiento asociado al requisito es de carcter algortmico o un Diagrama de
Estados si el comportamiento incluye habilitacin o deshabilitacin de acciones de
acuerdo con el estado del sistema. La premisa esencial es pragmatismo respecto de la
especificacin, con lo cual no se descarta el uso combinado de alternativas de
especificacin, pero el criterio primordial debe ser el rentabilizar el esfuerzo en
especificacin y facilitar el mantenimiento de dicha especificacin. Por otra parte,
desde el punto de vista de esfuerzo de mantenimiento, especialmente en cuanto a
consistencia, es importante no abusar de solapes o duplicaciones de especificaciones
en diferentes medios de representacin.
46
FIS-UNICA
Las miles de PAs que fcilmente puede llegar a tener un producto software deben
organizarse adecuadamente para poder ser gestionadas de forma eficiente. Un grafo
dirigido es una representacin adecuada para realizar un refinamiento por niveles.
Dicho grafo permite tanto la visualizacin de relaciones de descomposicin como de
dependencia entre requisitos. As, cada nodo es un requisito funcional o no funcional.
Los arcos entre nodos establecen relaciones padres-hijos (mediante las cuales se hace
una descomposicin de los requisitos) o relaciones de dependencia del tipo nodos
que afectan nodos (estas relaciones son clave para realizar anlisis de impacto).
Las PAs tendrn diferentes estados segn el refinamiento de su especificacin, de
menor a mayor detalle dichos estados son: identificacin (un nombre para la PA),
definicin (establecimiento de condiciones, pasos de ejecucin y resultado esperado),
diseo (instanciacin con datos especficos) y ejecucin en el producto (incluyendo el
caso de ejecucin en regresin, sea sta automatizada o manual). En el resto del
artculo nos centraremos en la identificacin y definicin de la PAs, lo cual est ms
asociado al marco de trabajo del analista. El diseo y ejecucin de la PAs es
responsabilidad del tester.
As, en el ejemplo anterior, el requisito Retirar dinero podra ser un nodo de la
estructura de requisitos. Los nombres que identifican sus PAs podran ser:
Reintegro usando cantidades predefinidas habilitadas.
Reintegro con cantidad introducida por cliente.
Reintegro saldo < cantidad.
Cancelacin de operacin.
No disponibilidad de billetes.
No disponibilidad de papel para recibo.
Reintegro saldo < cantidad con cliente preferencial.
Excedido tiempo de comunicacin con sistema central.
Aviso de operaciones internas del cajero.
Excedido tiempo de espera para introduccin de accin.
47
FIS-UNICA
Una PA tiene como propsito demostrar al cliente el cumplimiento parcial o total de

un requisito del software. Las caractersticas de una PA son:
Una PA describe un escenario (secuencia de pasos) de ejecucin o
un uso del sistema desde la perspectiva del cliente. Las PAs cubren
desde escenarios tpicos/frecuentes hasta los ms excepcionales.
Puede estar asociada a un requisito funcional o requisito no
funcional. Un requisito tiene una o ms PAs asociadas.
Una PA puede tener infinitas instanciaciones (ejecuciones con
valores concretos).
La definicin de una PA se separa en cuatro apartados: Condicin, Pasos, Resultado
Esperado y Observaciones.
Condicin. Es opcional, y se utiliza para establecer condiciones
previas antes de aplicar los pasos de la prueba. Normalmente se
refieren al estado de la BD antes de ejecutar la prueba y/o la
navegacin necesaria en la IU para localizarse en el punto adecuado
para realizar la prueba (cuando no sea obvio)
Pasos. Son las acciones de interaccin del actor con el sistema.
Cuando son varias acciones, stas pueden ponerse en una lista
numerada. Deben ser simples, del estilo seleccionar,
introducir..., evitando hacer referencia explcita a controles de
interfaz o cualquier tecnicismo que dificulte su validacin con el
usuario.
Resultado esperado. Es el efecto de las acciones de interaccin del
actor. Cada accin puede provocar uno o ms resultados. Es
importante que cuando se trate de mensajes al usuario se incluya el
texto como parte del resultado esperado, as el programador
dispone de dicha informacin ya validada con el cliente.
Observaciones. Es un apartado opcional, son recomendaciones
que el analista estima conveniente hacerle al tester y/o
programador.
Las condiciones y/o resultados esperados pueden establecerse en el mbito del
requisito contenedor de la PA o de otros requisitos. Esto, como indicaremos ms
adelante, permitir establecer relaciones de dependencia entre requisitos.
A continuacin se presenta como ejemplo la definicin de la PA Reintegro saldo <
cantidad.
48
FIS-UNICA
1. Condicin
Debe existir un cliente normal (esta caracterstica se establece en el
apartado datos bsicos del cliente).
2. Pasos
Intentar reintegro con cliente normal y con cantidad solicitada
mayor al saldo.
Resultado esperado.
Se muestra el mensaje La cantidad solicitada supera su saldo
actual, vuelva a introducir la cantidad y se retorna a la ventana
para introducir la cantidad.
Pruebas de aceptacin ayudar a validar que se est construyendo la aplicacin que
desea el cliente, mientras que la automatizacin de estos escenarios le permite
verificar constantemente la aplicacin en todo el proceso de desarrollo y los utilizan
como parte de su suite de pruebas de regresin para asegurar que los futuros cambios
no violan los requerimientos actuales.
Sin embargo, tener un cliente implicado con escritura de pruebas, especialmente
pruebas automticas, presenta un nmero de posibles problemas. Los clientes, en
general, no son tcnicos y tienden a alejarse del propio desarrollo de software. El
cliente puede proporcionar los datos y ejemplos, mientras que los probadores o los
desarrolladores rpidamente pueden codificar los escenarios y especificacin
ejecutable.
Las pruebas de aceptacin de la interfaz de usuario

En los ejemplos, las pruebas de aceptacin se centr en la lgica de negocio y los
objetos de dominio con el fin de comprobar si la lgica trabajado con xito. Pero, qu
acerca de cmo el usuario interacta con la aplicacin? Estas pruebas de aceptacin
deben estar all para verificar la lgica es correcta el punto de vista del usuario-y el
punto de vista del usuario es la interfaz de usuario.
Personalmente, creo que las pruebas de aceptacin deben centrarse en la lgica de la
aplicacin y las secciones importantes del cdigo que decidir qu hacer. Si la aplicacin
tiene un buen desacoplamiento, y una buena separacin de la lgica del cdigo de la
interfaz de usuario, esto debera hacer las pruebas ms fciles de implementar. Si est
probando en este nivel, las pruebas no sufrirn cambios en la interfaz de usuario.
Mientras que las pruebas deben centrarse exclusivamente en la lgica, esto no
significa que usted no debera tener ninguna prueba de aceptacin en todo el interfaz
de usuario. Me gusta tener un conjunto de pruebas de humo que se dirigen a la base
"camino feliz" de la interfaz de usuario.
49
FIS-UNICA
Se centran en las partes de la aplicacin que los usuarios son ms propensos a utilizar
con el fin de obtener el mximo valor de la menor cantidad de pruebas. Si se intenta
cubrir todos los posibles caminos y usos de la interfaz de usuario, y si los cambios de
interfaz de usuario (por ejemplo, como opciones de pasar a un dilogo a otro),
entonces usted tendra que cambiar todas las pruebas.
Por ejemplo, si se prueba la interfaz de usuario para un sitio de comercio electrnico,

el camino sera feliz para seleccionar un artculo, incorporarlo a su carrito de compras,
echa un vistazo, y ver la confirmacin de compra. Si este escenario falla, usted
realmente quieren saber lo ms pronto posible.
Para ciertas aplicaciones, dependiendo de la complejidad y el tiempo de vida, es
posible que desee tener ms pruebas de aceptacin que se ejecutan en la interfaz de
usuario para asegurarse de que tienen ms confianza en la capa de interfaz de usuario.
Con xito pruebas de la interfaz de usuario es un tema complejo, sin embargo, y no lo
hago tiene el espacio para cubrirla aqu. (Francisco Surez;Patricio Letelier)
3.2.2 Implementacin de pruebas de aceptacin

Una vez que tenga la historia y los escenarios en un formato claro y comprensible, el
siguiente paso es automatizar la historia y los escenarios. Esto les permite ser
ejecutado durante el desarrollo para seguir los progresos y detectar los errores de
regresin.
50
FIS-UNICA
Conclusiones y recomendaciones
Las pruebas de aceptacin son iterativas donde se pueden aplicar un conjunto de
metodologa como el programacin extrema (XP), el scrum y RUP (casos de usos) estn
definidas como pruebas de Caja negra por la que el ms importante de los actores que
estas pruebas sean exitosas es el cliente es importante determinar las historias y
escenarios en donde se van a especificar determinar los requisitos para que el cliente
pueda validar si est conforme a lo especificado.
Por otra parte tenemos las pruebas de sistemas estas son las encargadas de evaluar el
funcionamiento a lo largo del proceso para detectar los errores que se puedan
producir para ello es necesario hacer una estrategia con los testing y separar el
desarrollo del cdigo con el desarrollo de la interfaz as se hace mejor una
implementacin de prueba de sistemas.
La implementacin de estas dos pruebas de software se debe hacer con exmenes
riguroso y que cumplan con determinados estndares y con la coordinacin de los
stakeholder que estn implicados en la elaboracin del sistema.
51
FIS-UNICA
BIBLIOGRAFIA
1.-Isabel Ramos Romn, Jos Javier Dolado Cosn. Tcnicas Cuantitativas para la Gestin en la
Ingeniera del Software. Primera Edicin ed. Tuya , Ramos Romn I, Dolado Cosn JJ, editors.
Espaa: Netbiblo, 2007; 2007.
2.-INTECO. Instituto Nacional de Tecnologas de Comunicacin. [Online].; 2009 [cited 2012
[Plan Avanza 2 - Ministerio de Industria, Turismo y Comercio de Espaa]. Available from:
www.inteco.es/file/XaXZyrAaEYfaXKiMJlkT_g.
3.-F. Alonso Amo, Loic Martnez Normand. Introduccin a la Ingeniera del software. Primera
edicion ed. Barbero Ruiz J, editor. Espaa: Delta Publicaciones, 2005.
4.-IEEE Computer Society. Computer. [Online].; 2004 [cited 2012. Disponible en:
http://www.computer.org/portal/web/swebok/html/contentsch5#ch5.
5.-Asociacion de tecnicos de informtica. Pruebas de Aceptacin en Sistemas Navegables.
REICIS Revista Espaola de Innovacin, Calidad. 2010 Noviembre; vol. 6(nm. 3): p. pp. 47-55.
6.-ALEGSA. ALEGSA - DICCIONARIO DE INFORMTICA. [Online]. 2012. Disponible en:
http://www.alegsa.com.ar/Dic/implementacion.php.
7.ingsoft.
ingsoft-ETAPA
DE
PRUEBAS.
[Online].2007.
http://ingpau.blogspot.com/2007/09/etapa-de-pruebas.html.
Disponible
en:
8.-Departamento de Lenguajes y Sistemas Informticos. ITESCAM. [Online]. Disponible en:

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r43876.PDF.
9.-Satrom B. MSDN Magazine. [Online].; 2010. Disponible en: http://msdn.microsoft.com/eses/magazine/gg490346.aspx
10.-Francisco
Surez;
Patricio
Letelier.
TUNE-UP.
[Online].
Disponible
http://tuneup.dsic.upv.es/LinkClick.aspx?fileticket=Dshzxx-2qDY%3D&tabid=40.
en:
11.- Universidad Distrital Francisco Jos de Caldas. ARQUISOFT.[Online]. Disponible en:

http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/
12.- Instituto Tecnolgico de Mrida. Desarrollo de proyecto de Software. [Online]. Disponible
en:
http://es.slideshare.net/juandiaz89/estrategias-de-aplicacin-de-pruebas-del-sistema14842463
52
FIS-UNICA
13.Ana Sosa. Magazine. Prueba general de Software. ITPUEBLA. [Online]. Disponible en:
http://www.itpuebla.edu.mx/Alumnos/Cursos_Tutoriales/Ana_Sosa_Pintle/ANALISIS_DISENO/
ANALISIS%202%20PRUEBA%20GENERAL%20DEL%20SISTEMA.htm
14.-TestHouse.Pruebas de Sistemas. [Online]. Disponible en:
http://www.es.testhouse.net/pruebas-de-sistema/
15.- Departamento de Tecnologas y Sistemas de Informacin. Universidad Castilla-Mxico.

[Online]. Disponible en:
http://www.inf-cr.uclm.es/www/mpolo/asig/0708/phd/apuntesDoctorado.pdf
16.-Jesus Barranco de Areba. Metodologa de anlisis estructurado de sistemas. Universidad
Pontifica-Espaa.
[Online].
Disponible
en:
http://books.google.com.pe/books?id=PUqxsNVaQC8C&pg=PA467&lpg=PA467&dq=pruebas+
de+comunicacion+de+sistemas&source=bl&ots=bJjHFtBrBL&sig=EhPEBom8YGdbpcUvAGzYuJ
MF0lw&hl=es&sa=X&ei=LhmSUf3fLvfK4APlroDABw&ved=0CFwQ6AEwCTgK#v=onepage&q=pr
uebas%20de%20comunicacion%20de%20sistemas&f=false
Referencias
Jacobson, Ivar, Booch, Grady, Rumbaugh, James, El Proceso Unificado de Desarrollo de
Software, Addison Wesley, 2000
Lambuth, Mark, Bug fishing Embedded System Programming, 28/02/2002, localizable en
Internet en http://embedded.com
Rosenberg, Doug: Use Case Driven Object Modeling with UML: a practical approach,
Addison-Wesley, EUA, 1999.
Select Vista general de Select Perspective y Select Component Architect, SELECT Business
Solutions, 2003
Sumano, ngeles ncora: Anlisis de requerimientos de software conducente al reuso de
artefactos, Universidad Veracruzana, 2006.
Yamaura, Tsuneo How to design practical test cases, IEEE Software v 15, n 6,
november/december 1998, pp 30-36.
53
FIS-UNICA
Documentacin
54

Prueba de Sistema y Aceptacion

Hochgeladen von

Dokumentinformationen

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

Prueba de Sistema y Aceptacion

Hochgeladen von

Copyright:

Verfügbare Formate

Prueba de Sistema y Aceptacin

Ao de la Diversificacin Productiva y del Fortalecimiento de Educacin

Universidad Nacional San Luis Gonzaga de Ica

Tema: Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Este presente trabajo de Prueba de Sistema y

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Cualquier pieza de software completo,

La prueba de sistemas usualmente es de caja negra, especialmente si quien prueba no

Prueba de Sistema y Aceptacin

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema

Prueba de Sistema y Aceptacin

1.1 Visin sistmica de la prueba

Al aplicar esos conceptos a la prueba de software, se obtienen una serie de principios

Prueba de Sistema y Aceptacin

1.2 Vista general de la prueba de sistemas

Figura 2: Proceso de prueba de sistema

Prueba de Sistema y Aceptacin

La prueba de sistemas tiene varias suposiciones importantes:

1.3 Plan de pruebas

1.3.1 Preparar un plan de Pruebas

Prueba de Sistema y Aceptacin

Necesidades ambientales: hardware, software y espacio de trabajo necesarios.

1.3.2 Preparar lista de verificaciones

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

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Si utiliza una metodologa que ayude a la recoleccin y manejo de requerimientos, es

1.3.2.1 Detalle a partir de ncora

Tabla 1: Bitcora de Ancora

Prueba de Sistema y Aceptacin

Los casos fracasados pueden incluir algunos de los siguientes:

1.3.2.2 Detalle a partir de Casos de Uso

Prueba de Sistema y Aceptacin

1.3.3 Preparar casos de prueba

Prueba de Sistema y Aceptacin

Un ejemplo de ste tipo es la siguiente entrada de una funcin de venta:

1.3.3.1 Forma general de los casos de prueba

Prueba de Sistema y Aceptacin

o Situaciones del medio ambiente que afecten negativamente la operacin del

1.3.3.2 Entrada simultnea

Prueba de Sistema y Aceptacin

En algunos casos las condiciones resultan complejas de expresar o no resulta fcil

Prueba de Sistema y Aceptacin

Salve la base de datos.

1.3.3.3 Entradas en varias etapas

Prueba de Sistema y Aceptacin

Por ejemplo, considere un sistema de inscripciones a diversos cursos, con diferentes

1.3.3.4 Beneficios a partir de la preparacin de casos de prueba

Prueba de Sistema y Aceptacin

Por ejemplo, si hubiese un requerimiento El sistema debe ser totalmente amigable,

1.3.4 Ejecucin de casos de prueba

1.3.4.1 Pruebas Funcionales

Prueba de Sistema y Aceptacin

1.3.4.2 Pruebas No Funcionales

Prueba de Sistema y Aceptacin

Pruebas de facilidad de uso

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin

Prueba de Sistema y Aceptacin