PRUEBAS DE SISTEMAS Y
PRUEBAS DE ACEPTACIN
CURSO:
Pruebas de Software
DOCENTE:
Mag. Morales Loaiza Alonso
INTEGRANTES:
Castaeda Gutierrez Jesus
De la Cruz Apari Joan Kimbely
Ramos Gutierrez Juan Angel
Salcedo Vilchez Almamia
ICA PERU
2017
PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN
DEDICATORIA
Este presente trabajo est dedicado a
Dios, por brindarnos la dicha de la salud
y bienestar fsico y espiritual. A
nuestros padres, por los innumerables
motivos hayan logrado encaminarnos
por el buen camino y as lograr nuestros
objetivos.
INDICE
INTRODUCCION Pgina 6
PRUEBAS DE SISTEMAS....... Pgina 7
1. CONCEPTO............. Pgina 7
1.1. TIPOS DE PRUEBAS DE SISTEMAS... Pgina 8
1.1.1. PRUEBA DE RECUPERACION. Pgina 8
1.1.2. PRUEBA DE SEGURIDAD.. Pgina 9
1.1.3. PRUEBA DE RESISTENCIA... Pgina 10
1.1.4. PRUEBA DE DESEMPEO Pgina 10
1.1.5. PRUEBA DE COMUNICACIN.. Pgina 11
1.1.6. PRUEBA DE VOLUMEN.. Pgina 11
1.1.7. PRUEBA DE TENSION Pgina 11
1.1.8. PRUEBA DE DISPONIBILIDAD DE DATOS. Pgina 11
1.1.9. PRUEBA DE FACILIDAD DE USO. Pgina 11
1.1.10. PRUEBA DE OPERACIN..... Pgina 12
1.1.11. PRUEBA DE ENTORNO.. Pgina 12
1.1.12. PRUEBA DE ALMACENAMIENTO.... Pgina 12
1.1.13. PRUEBA DE CONFIGURACION Pgina 12
1.1.14. PRUEBA DE INSTALACION... Pgina 12
1.1.15. PRUEBA DE DOCUMENTACION.. Pgina 13
1.2. VISION SISTEMATICA DE LA PRUEBA.. Pgina 13
1.3. VISTA GENARAL DE LA PRUEBA DE SISTEMAS Pgina 13
1.4. PLAN DE PRUEBAS.... Pgina 14
INDICE DE FIGURAS
FIGURA 1: PRUEBAS DE SISTEMA.. Pgina 7
FIGURA 2: PRUEBA DE RECUPERACION.. Pgina 8
FIGURA 3: PRUEBA DE SEGURIDAD... Pgina 9
FIGURA 4: PRUEBA DE RESISTENCIA Pgina 10
FIGURA 5: FLUJO DE CONTROL DE PRUEBA DE ACEPTACION. Pgina 16
FIGURA 6: ARQUITECTURA DE PRUEBA DE SISTEMA.. Pgina 22
FIGURA 7: EJECUCION DEL CASO DE PRUEBA DEL ESCENARIO PRINCIPAL
CON LA HERRAMIENTA SELENIUN. Pgina 28
FIGURA 8: IMPLEMENTACION DEL CASO DE PRUEBA.. Pgina 29
FIGURA 9: ALTERNATIVAS DE ESPECIFICACION... Pgina 33
FIGURA 10: DESCRIPCION NARRATIVA...................... Pgina 34
INDICE DE TABLAS
TABLA 1: ENTRADAS, SALIDAS, TAREAS Y ROLES DE PRUEBAS DE
ACEPTACION................................................ Pgina 19
TABLA 2: HERRAMIENTAS PARA PRUEBAS DE ACEPTACION. Pgina 20
TABLA 3: COMPORTAMIENTO GENERICO DE UN CASO DE PRUEBA Pgina 23
TABLA 4: CASO DE USO BAJO PRUEBA.. Pgina 25
TABLA 5: REQUISITO DE INFORMACION DE LOS ENLACES.. Pgina 26
TABLA 6: ESCENARIOS DEL CASO DE USO... Pgina 26
TABLA 7: ESCENARIO PRINCIPAL. Pgina 27
TABLA 8: VARIABLES IDENTIFICADAS PARA EL CASO DE USO... Pgina 27
TABLA 9: CATEGORIAS PARA LAS VARIABLES IDENTIFACADAS Pgina 27
TABLA 10: TRADUCCION A CPDIGO EJECUTABLE DE LOS PASOS
REALIZADOS POR EL USUARIO EN EL ESCENARIO PRINCIPAL.. Pgina 29
TABLA 11: TRADUCCION A CODIGO EJECUTABLE DEL TEST ORACLE
PARA EL ESCENARIO PRINCIPAL. Pgina 30
INTRODUCCION
La aplicacin de pruebas de software es actualmente una herramienta importante para
llevar el control de la realizacin de un proyecto de software de calidad y cada vez es
ms rigurosa estas pruebas por el hecho de la gran competitividad creciente existente
en el mercado.
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.
PRUEBAS DE SISTEMAS
1. CONCEPTO
El software se incorpora a otros elementos del sistema (como hardware, personas,
informacin), y se realiza una serie de pruebas de integracin de sistemas y de validacin.
Estas pruebas estn ms all del alcance del proceso de software y no las realizan
nicamente los ingenieros del software. Sin embargo, los pasos durante el diseo y las
pruebas del software mejoran en gran medida la probabilidad de tener xito en la integracin
del software en el sistema mayor. Cualquier pieza de software completo, desarrollado o
adquirido, puede verse como un sistema que debe de probarse, ya sea decidir acerca de su
aceptacin, para analizar defectos globales o para estudiar aspectos especficos de su
comportamiento, tales como seguridad, rendimiento. A este tipo de pruebas donde se
estudia el producto completo se les llama pruebas de sistemas.
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.
Si se dan el tiempo y los recursos suficientes, una buena prueba de seguridad terminara
por irrumpir en el sistema. El papel del diseador del sistema es que el costo de la
irrupcin sea mayor que el valor de la informacin que habr de obtenerse.
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.
La situacin exacta de estas partes depende del modelo de ciclo de vida que haya
elegido. La etapa de preparacin de la prueba incluye al menos tres actividades:
Preparacin un plan de pruebas
Preparar una lista de verificaciones de los requerimientos
Preparar casos de prueba.
6) productos a entregar: desde el propio plan, los casos y procedimientos de prueba, los
resultados.
7) tareas a realizar para satisfacer el proceso.
8) necesidades ambientales: hardware, software y espacios de trabajo necesarios.
9) responsabilidades: quin es responsable de cada cosa.
10) personal necesario y si requieren entrenamiento.
11) calendario: tiempo e hitos en el proceso.
12) riesgos y contingencias que pueden ocurrir en el proceso de prueba.
PRUEBAS DE ACEPTACION
2. CONCEPTO
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.
Las pruebas de aceptacin, son bsicamente pruebas funcionales sobre el sistema completo,
y buscan comprobar que se satisfacen los requisitos establecidos. Su ejecucin es facultativa
del cliente, y en el caso de que no se realicen explcitamente, se dan por incluidas dentro de
las pruebas de sistema. Es decir, las pruebas de aceptacin son, a menudo, responsabilidad
del usuario o del cliente, aunque cualquier persona involucrada en el negocio puede
realizarlas. La ejecucin de las pruebas de aceptacin requiere un entorno de pruebas que
represente el entorno de produccin.
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.
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.
Especificacin de Requisitos.
Manuales de Usuario.
Entradas Sistema probado.
Plan de Pruebas.
Resultados de pruebas.
Salidas Producto aceptado
Informe de Pruebas de aceptacin.
Ingeniero de Pruebas.
Roles Jefe de Pruebas.
Jefe de Proyecto (Cierre formal de la actividad).
Herramienta Descripcin
Canoo es una herramienta de Software Libre para
automatizar las pruebas de aplicaciones web de una forma
CANOO muy efectiva.
http://webtest.canoo.com/webtest/manual/WebTestHome.htm
l
Concordion es un framework Java de Software Libre que
permite convertir especificaciones en texto comn sobre
CONCORDION
requerimientos en pruebas automatizadas
http://www.dosideas.com/wiki/Concordion
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.
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 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.
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.
B) TEST HARNESS.
Tal y cmo se describi en la figura 6, 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 7, 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.
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 10.
A continuacin, en la tabla 11, se escribir los asertos a partir de los pasos que realiza el
sistema.
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.
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.
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.
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.
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
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 10: 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.
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).
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.
EJEMPLO:
LA HISTORIA
En el desarrollo de un sistema de clculo de precios con el objetivo de utilizar las
pruebas de aceptacin, la primera etapa es tener a todos en una sala para definir la
historia. Los clientes definen lo que quieren con el estmulo de los miembros tcnicos
del equipo. Con BDD, que desea utilizar un formato establecido para la definicin de las
historias con el fin de apoyar un lenguaje coherente entre los miembros del equipo, y en
concreto lo que se requiere por parte del cliente. Teniendo en cuenta el siguiente
formato, se rellena los datos con la ayuda del cliente:
Lamentablemente, mientras se sigue el formato, que ofrece una informacin muy floja,
y no un punto de partida para la puesta en prctica. Un ejemplo an mejor sera:
Como administrador de ventas, quiero ser capaz de ver los precios del producto X, para
que pueda ofrecer a los clientes con un costo exacto basado en sus necesidades.
Esta historia nos ofrece ms detalles y ms de contexto sobre lo que el cliente est
esperando a suceder y lo que quieren en realidad. Como resultado, es mucho ms til
para nosotros en la aplicacin del sistema. Un hecho importante a recordar cuando se
escriben las historias y caractersticas es de mantenerlos lo ms centrado posible. Que
har que sea mucho ms fcil crear los escenarios, escribir las pruebas, y aplicar el
cdigo final.
Escenarios
Incluso con una historia, usted todava necesita ms informacin sobre lo que estn
esperando a suceder. Los escenarios son muy tiles para esto. Un escenario se limita
a establecer que, dado un determinado contexto, si algo sucede, entonces la salida debe
ser esto. El objetivo es ofrecer un ejemplo ms concreto de cmo la implementacin de
la historia debe comportarse en diferentes situaciones. Este se comunica con las
expectativas del equipo y proporciona los pasos para su verificacin.
La sintaxis recomienda el uso que se conoce como dado, Cundo, entonces (GWT)
sintaxis, promovido por Dan North:
Dado/ Teniendo en cuenta [el contexto], cuando [algo que ocurre], entonces [el
resultado].
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. 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.
4. 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 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.
5. BIBLIOGRAFIA
1. Isabel Ramos Romn, Jos Javier Dolado Cosn. Tcnicas Cuantitativas para la
Gestin en la Ingeniera del Software. Primera Edicion ed. Tuya , Ramos Romn I,
Dolado Cosn JJ, editors. Espaa: Netbiblo, 2007; 2007.
4. IEEE Computer Society. Computer. [Online].; 2004 [cited 2012. Available from:
http://www.computer.org/portal/web/swebok/html/contentsch5#ch5.