Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Prueba de Sistema y Aceptacion
Prueba de Sistema y Aceptacion
ICA-PERU
2015
2
FIS-UNICA
DEDICATORIA
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
7
FIS-UNICA
8
FIS-UNICA
9
FIS-UNICA
10
FIS-UNICA
11
FIS-UNICA
h)
i)
j)
k)
l)
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
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
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.
16
FIS-UNICA
FIS-UNICA
17
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
19
FIS-UNICA
Ejemplo:
1.
2.
3.
4.
5.
6.
20
FIS-UNICA
FIS-UNICA
21
22
FIS-UNICA
FIS-UNICA
23
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
28
FIS-UNICA
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.
Entradas
Tareas
Salidas
Roles
Especificacin de Requisitos.
Manuales de Usuario.
Sistema probado.
Plan de Pruebas.
30
FIS-UNICA
2.7
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
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).
33
FIS-UNICA
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
FIS-UNICA
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.
37
FIS-UNICA
38
FIS-UNICA
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
40
FIS-UNICA
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
3.2
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.
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
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.
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
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.
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.
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:
en:
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/
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