Académique Documents
Professionnel Documents
Culture Documents
INTRODUCCION
Al igual que con casi cualquier proceso tcnico, las pruebas de software tienen un
orden prescrito en la que deben hacerse las cosas. Los diferentes niveles de pruebas
se utilizan en el proceso de prueba; cada nivel de prueba tiene como objetivo probar
diferentes aspectos del sistema. Los 4 niveles de pruebas de software se clasifican en:
Pruebas Unitarias, Pruebas de Integracin, Pruebas de Sistema, y por ltimo las
Pruebas de Aceptacin, las cuales integran y ejecutan otros tipos de pruebas.
Principalmente en el desarrollo de sistemas software, la fase de Prueba de Sistemas
cobra gran importancia. El proceso de prueba a nivel de sistema engloba tantos tipos
de prueba como tipos de requisitos se pueden definir y probar con la ejecucin del
sistema o mediante la verificacin de sus distintos elementos. Habitualmente se
engloba requisitos funcionales, de seguridad, de rendimiento, de fiabilidad, de
accesibilidad, etc.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 1
PRUEBAS DE SISTEMA Y ACEPTACIN
I. PRUEBAS DE SISTEMA
1. CONCEPTO
Las pruebas del sistema es una forma de tratar de demostrar que el sistema no
cumple sus especificaciones de requisitos y no se puede utilizar. Se puede
consumir tanto como la mitad de los recursos de las pruebas.
Las pruebas de sistema no son procesos para probar las funciones del sistema o
del programa completo, porque sta sera redundante con el proceso de las
pruebas funcionales. Las pruebas del sistema tienen un propsito particular:
comparar el sistema o el programa con sus objetivos originales (Requerimientos
funcionales y no funcionales). Dado este propsito, se presentan dos
implicaciones:
Las pruebas de sistema no se limitan a los sistemas. Si el producto es un
programa, la prueba del sistema es el proceso de procurar demostrar cmo
el programa, en su totalidad, no resuelve sus objetivos o requerimientos.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 2
PRUEBAS DE SISTEMA Y ACEPTACIN
Las pruebas de sistema, por definicin, son imposibles si noestn los
requerimientos por escrito, mensurables para el producto.
Las pruebas del sistema son una fase de pruebas de investigacin, en la que se
asegura que cada componente unitario o mdulo (identificado en las pruebas
unitarias), interacte con otros componentes o mdulos, tal como fue diseado.
2. OBJETIVOS
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 3
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 4
PRUEBAS DE SISTEMA Y ACEPTACIN
Todo sistema tiene una serie de objetivos que le dan sentido. Esos
objetivos estn asociados con indicadores de xito que permiten
determinar si los objetivos se cumplen y en qu medida.
Todo sistema tiene una serie de elementos que lo forman y la interaccin
de tales elementos se orienta a satisfacer los objetivos.
Todo sistema tiene una frontera que lo separa de un medio ambiente.
Los elementos de ese medio ambiente influyen sobre el sistema
proporcionndoles una serie de entradas y obteniendo del mismo un
conjunto de salida.
interaccionan con otros
Ningn Sistema existe en aislamiento; siempre
sistemas constituyendo un sistema mayor.
Debe asegurarse de conocer con precisin los objetivos del software a
probar, as como sus indicadores de xito. Estos elementos se localizan
en los documentos obtenidos en la etapa de recoleccin de
requerimientos, as como en las especificaciones del software. Esta
informacin ser indispensable para preparar el plan de pruebas y ser
la base para iniciar el desarrollo de los casos de prueba.
Deben determinarse las entradas y salidas del sistema aprobar. ste
aspecto es necesario en la preparacin de los casos de prueba y tambin
en el establecimiento de procedimientos de prueba, orientados
especialmentea los casos de prueba que muestran el cumplimiento de
los objetivos.
Considerar el sistema mayor donde opera el software a probar.
Generalmente es un ambiente organizacional, formado por elementos de
hardware, de software y personas (usuarios). Todos estos elementos
influyen mucho sobre el sistema y ayudan especialmente en la
preparacin de casos de prueba de situaciones no deseadas, relacionadas
con datos inadecuados,
ausencia de elementos necesarios y ocurrencia
de excepciones.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 5
PRUEBAS DE SISTEMA Y ACEPTACIN
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.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 6
PRUEBAS DE SISTEMA Y ACEPTACIN
6. PLAN DE PRUEBAS
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 7
PRUEBAS DE SISTEMA Y ACEPTACIN
Identificacin del plan de pruebas y el sistema al que aplica.
Elementos a probar: qu mdulos, clases, casos de uso se van a
probar; cuando se emplea desarrollo iterativo, deben
especificarse las prestaciones (funcionales), a probar y cuales no
se probarn
(ya sea que se probaron antes o que se implementarn
despus).
Enfoque: vista general de la estrategia de prueba.
Criterio de aceptacin o rechazo de un caso de prueba: criterio
para dar por bueno o malo un caso de prueba al ser ejecutado.
Criterio de suspensin: ya sea por tiempo o por cobertura.
Tareas a realzar para satisfacer el proceso.
Necesidadesambientales: hardware, software y espacio de trabajo
necesarios.
Responsabilidades: quien es responsable de cada cosa.
Personal necesario y si requieren entrenamiento.
Calendario: tiempos e hitos en el proceso.
Riesgos
y contingencias que pueden ocurrir en el proceso de
prueba.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 8
PRUEBAS DE SISTEMA Y ACEPTACIN
7. LISTA DE VERIFICACIONES
Asegurar que para cada requerimiento exista una descripcin de la
manera en que se verificar; si no existe, debe desarrollarse. Una buena
descripcin debe contener al menos el funcionamiento tpico de la
funcin a que corresponde y los principales comportamientos alternos:
variaciones menos
frecuentes, respuesta ante datos incompletos y fallas
del ambiente.
Revisin de las descripciones: cada descripcin debe revisarse para
asegurarseque se entiende claramente, que efectivamente es
realizable.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 9
PRUEBAS DE SISTEMA Y ACEPTACIN
ENTRADAS
TAREAS
SALIDAS
ROLES
Ing. de Pruebas
Analista Funcional
Jefe de Pruebas
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 10
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 11
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 12
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 13
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 14
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 15
PRUEBAS DE SISTEMA Y ACEPTACIN
Se disea pruebas especiales que generen10 interrupciones por segundo
cuando la tasa promedio es de una o dos.
una magnitud que permita
Se aumenta la frecuencia de entrada de datos
como responder las funciones de entrada.
casos de pruebas que requieran el mximo de memoria u otros
Se ejecutan
recursos.
Se disea
casos de pruebas que causen problemas de administracin de
memoria.
Se crean casos de pruebas que produzcan bsquedas excesivas de datos en
el disco.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 16
PRUEBAS DE SISTEMA Y ACEPTACIN
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.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 17
PRUEBAS DE SISTEMA Y ACEPTACIN
10. CONCEPTO
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 18
PRUEBAS DE SISTEMA Y ACEPTACIN
Esta fase o nivel toma como punto de partida la lnea base de aceptacin del
producto ya instalado en el entorno de certificacin. A partir de dicha lnea
base se acepta el producto, tomando como referencia la especificacin de
requisitos y comprobando que el sistema cubre satisfactoriamente los requisitos
del cliente.
El sistema ha de ser aceptado por el usuario. Por tal motivo, a partir de las
especificaciones estructuradas del sistema, el analista produce un conjunto de
casos de prueba que tendr que pasar satisfactoriamente. Como las pruebas de
aceptacin se pueden desarrollar en paralelo con las actividades de diseo e
implementacin, es normal que esta actividad la inicie el analista nada ms
finalizar la actividad de Anlisis Estructurado.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 19
PRUEBAS DE SISTEMA Y ACEPTACIN
11. OBJETIVOS
Las pruebas de aceptacin tienen como objetivo obtener la aceptacin final del
cliente antes de la entrega del producto para su paso a produccin. Cuando la
organizacin ha realizado las pruebas de sistema y ha corregido la mayora de
sus defectos, el sistema ser entregado al usuario o al cliente para que d su
aprobacin.
Describe un escenario (secuencia de pasos) de ejecucin o uso del sistema
desde la perspectiva del cliente.
Puede estar asociada a requisitos funcionales o no funcionales.
Un requisito tiene una o ms pruebas de aceptaciones asociadas.
desde escenarios tpicos/frecuentes
Las pruebas de aceptacin cubren
hasta los ms excepcionales.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 20
PRUEBAS DE SISTEMA Y ACEPTACIN
Comparar los resultados de las pruebas con los casos de prueba iniciales.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 21
PRUEBAS DE SISTEMA Y ACEPTACIN
Especificacin de Requisitos.
Manuales de Usuario.
Sistema probado.
Entradas Plan de Pruebas.
Resultados de pruebas.
Producto aceptado
Informe de Pruebas de aceptacin.
Salidas
Roles
Ingeniero de Pruebas
Jefe de pruebas
Jefe de proyecto
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 22
PRUEBAS DE SISTEMA Y ACEPTACIN
13. ESTRATEGIAS
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 23
PRUEBAS DE SISTEMA Y ACEPTACIN
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.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 24
PRUEBAS DE SISTEMA Y ACEPTACIN
13.5. Herramientas
Si bien este tipo de pruebas pueden realizarse con prototipos de la aplicacin,
diagramas de secuencia o casos de uso que se muestran al usuario para que
valide los requerimientos definidos, existen algunas herramientas que pueden
ser tiles:
FitNesse
Permite a los usuarios, equipos de testing y programadores aprender lo que
debe hacer el software y comparar automticamente lo que realmente hace.
Se pueden realizar pruebas de aceptacin y pruebas de reglas de negocio. Es
una wiki que no requiere demasiadas configuraciones.
Avignon
Es un framework para pruebas de aceptacin que permite a los usuarios
expresar pruebas de aceptacin de una forma no ambigua antes que comience
el desarrollo. Trabaja en conjunto con JUnit, HTTPUnit, JAXP y Xalan. Utiliza
XML para definir la sintaxis del lenguaje.
Concordion
Es un framework Java de Software Libre que permite convertir
especificaciones en texto comn sobre requerimientos en pruebas
automatizadas.
Las especificaciones (o pruebas de aceptacin) se escriben normalmente en
archivos HTML, usando tablas y todos los elementos comunes para darle formato.
De esta manera se logran especificaciones muy fciles de leer y que todos pueden
comprender (desde analistas de negocio hasta desarrolladores).
Cucumber Es una herramienta para hacer pruebas de aceptacin de usuario
(mediante enfoque BDD -Behaviour Driven Development-) escrita en Ruby y
que ayuda a que el usuario final, es decir, la persona que se encuentra
trabajando en el ambiente del negocio propiamente dicho, y el equipo de
proyecto (analista, desarrollador y probador) se puedan entender
fcilmente.
Ilustracin II-5: Tabla de herramientas de la prueba de aceptacin
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 25
PRUEBAS DE SISTEMA Y ACEPTACIN
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 26
PRUEBAS DE SISTEMA Y ACEPTACIN
14. CONCEPTO
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 27
PRUEBAS DE SISTEMA Y ACEPTACIN
16.1.1. UserInterface:
La clase UserInterface representa la interfaz externa del sistema bajo
prueba y ha sido estereotipada de acuerdo con la definicin del perfil de
prueba de UML
16.1.2. UserEmulator:
La clase UserEmulator, define el elemento que podr interactuar con el
sistema utilizando las mismas interfaces que una persona real. Si, por
ejemplo, el sistema a prueba es una aplicacin web (como en el caso
prctico) la clase UserEmulator ser capaz de interactuar con el navegador
web para indicarle la URL qu tiene que visitar, rellenar formularios, pulsar
enlaces, etc. A partir de la interaccin de dicha clase con el sistema, se
obtendrn uno o varios resultados (clase TestResult), por ejemplo, en el
caso del sistema web, se obtendr cdigo HTML
16.1.3. AssertCatalog:
La clase AssertCatalog define la coleccin de asertos a disposicin de los
casos de prueba para determinar si el resultado obtenido del sistema a
prueba (clase TestResult) es correcto o no.
Tanto el UserEmulator como el AssertCatalog se han agrupado en un clasificador
que representa el test harness, dado que estos dos elementos, suelen ser
comunes para todas las pruebas de diversos sistemas y existe gran variedad de
ofertas en el mercado tanto de pago como libres y gratuitas.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 28
PRUEBAS DE SISTEMA Y ACEPTACIN
16.1.4. TestSuite:
La clase TestSuite, estereotipada como un Test Context del perfil de
pruebas de UML, representa un conjunto de casos de prueba (Test Case en
el perfil de UML).
16.1.5. TestOracle:
Esta clase sirve de contenedor de todas las acciones de validacin
(expresadas mediante la ejecucin de asertos sobre el resultado obtenido)
que determinarn el veredicto de los casos de prueba del contexto de
prueba.
16.1.6. TestDataPool
La clase TestDataPool (estereotipada como Data Pool segn el perfil de UML)
contendr un conjunto de mtodos Data Selector para seleccionar los
distintos valores de prueba segn las distintas particiones identificadas en
las variables de los casos de uso.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 29
PRUEBAS DE SISTEMA Y ACEPTACIN
El segundo patrn indica que cada caso de prueba debe ser implementado como
un mtodo. Esto concuerda con la definicin del UMLTP dnde un caso de
prueba no es un elemento arquitectnico, por tanto no se ha definido en la
seccin anterior, sino la definicin de un comportamiento como un mtodo
(estereotipado como Test Case) dentro de un elemento Test Suite
(estereotipado como Test Context). El comportamiento genrico de un caso de
prueba que se adopta con mayor frecuencia se lista en la tabla 2.
Como se puede ver en la tabla 1, cada mtodo de prueba tiene asociados otros
dos mtodos. El primero, mtodo set-up, establece el estado adecuado del
sistema para la ejecucin de la prueba. El segundo, tear down, restaura el
estado original del sistema. Estos mtodos tambin estarn definidos en el Test
Suite. Cada caso de uso tendr asociado un elemento TestSuite (figura 1). Dicha
suite contendr los mtodos de pruebas y mtodos asociados de todos los
escenarios de dicho caso de uso.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 30
PRUEBAS DE SISTEMA Y ACEPTACIN
17. CONCEPTO
Por qu hacer las pruebas de aceptacin?
Riesgo para la reputacin
Riesgo legal
Riesgo de tiempo
Riesgo de recursos
Las pruebas de aceptacin slo funcionan con el apoyo de los clientes, para
ayudar a definir los criterios. Sin el conductor de los criterios de aceptacin, se
hace difcil verificar si se est construyendo el software correcto.
18. DESCRIPCIN
Las pruebas de aceptacin se ejecutan luego de culminar la fase de pruebas de
sistema, esta ejecucin se realiza en la ltima etapa de pruebas, la cual evaluar
el sistema final con miras a su presentacin frente al cliente. En este plan se
especificarn las pruebas que sean necesarias para verificar si el programa cumple
con las especificaciones formales establecidas por el cliente.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 31
PRUEBAS DE SISTEMA Y ACEPTACIN
19. META
20. OBJETIVOS
Evidenciar la implementacin satisfactoria para el entorno de usuario.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 32
PRUEBAS DE SISTEMA Y ACEPTACIN
PRUEBAS ALFA
Encargado : Fecha :
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 33
PRUEBAS DE SISTEMA Y ACEPTACIN
PRUEBAS BETA
Usuario :
Fecha:
Prueba Observaciones
realizada
Cuestionario
3= Promedio
4= Bueno
5= Excelente
3= Promedio
4= Bueno
5= Excelente
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 34
PRUEBAS DE SISTEMA Y ACEPTACIN
El cliente elaborar un ranking para cada Caso de Uso (CU) con las siguientes
prioridades: ALTA, MEDIA o BAJA y en base a ellas se le asignar un mayor
nmero de pruebas para los CU con un mayor nivel de prioridad.
Evaluacin de pruebas
Participantes: Fecha:
Anlisis de resultados:
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 35
PRUEBAS DE SISTEMA Y ACEPTACIN
Las respuestas a las preguntas de las listas de chequeo se pueden dar de forma
directa o mediante la realizacin de casos de prueba. De realizarse a travs de los
casos de prueba, las respuestas dependern de los resultados en los mismos.
Escala de Evaluacin
Aprobado 5
No Falla menor 3
Aprobado
Falla Grave 1
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 36
PRUEBAS DE SISTEMA Y ACEPTACIN
Resultados de la presencia de las caractersticas de calidad (PCC) en cada
una de las etapas, considerando la importancia dada por los
involucrados.
Una vez obtenidos los resultados de todas las sub-caractersticas, se
proceder a realizar los clculos para obtener la evaluacin de la
caracterstica de calidad. Este clculo se realizar de la siguiente
manera:
Se calcula el promedio ponderado de las sub-caractersticas tomando en
cuenta los pesos que le han sido asignados a cada una de ellas.
Para calcular este promedio ponderado se multiplican los valores
obtenidos de cada sub-caracterstica (SC) por su peso correspondiente
(P).
Se suman los valores obtenidos de la multiplicacin y se divide este valor
entre la suma de todos los pesos. Este clculo se representa a travs de
la siguiente frmula:
Resultados de la
presencia de las caractersticas de calidad en todo el
sistema (PCCS).
Despus de realizar las evaluaciones de las caractersticas de calidad en
cada una de las etapas del proceso de prueba, se obtiene el porcentaje
de presencia de cada una de las caractersticas de calidad en todo el
sistema (PPCS) el cual es el promedio de los porcentajes de presencia de
cada una de las caractersticas en cada etapa del proceso de prueba
(PPCE).
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 37
PRUEBAS DE SISTEMA Y ACEPTACIN
Anlisis de resultados
Tipo de Alfa
prueba:
Resumen
Nmero Aceptadas
de Pruebas Rechazadas
Modificadas
Comentarios:
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 38
PRUEBAS DE SISTEMA Y ACEPTACIN
V. CONCLUSIONES Y
RECOMENDACIONES
Las pruebas de sistema permiten probar, validar, verificar tantos los requisitos
del negocio como la arquitectura del sistema.
Las pruebas de sistema nos permiten obtener una visin muy similar a su
comportamiento en produccin por ello estas pruebas se deben ejecutar en un
entorno muy similar al de produccin para minimizar el riesgo de encontrar
fallos especficos en l.
Las pruebas de aceptacin nos permiten obligar a definir que los requisitos sean
verificables, adems de valorar adecuadamente el esfuerzo asociado a la
incorporacin de un requisito.
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 39
PRUEBAS DE SISTEMA Y ACEPTACIN
BIBLIOGRAFIA
The Art of Software Testing (Second Edition) - Glenford J. Myers
Ingeniera del Software (Sptima edicin) - Ian Sommerville
http://woombat140512.blogspot.pe/2013_06_01_archive.html
http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-
Sistema.pdf
INTECO. Instituto Nacional de Tecnologias de Comunicacion. [Online].;
2009 [cited 2012 [Plan Avanza 2 - Ministerio
de Industria, Turismo y
Comercio de Espaa]. Available from.
Qualilfication Board. [Online] 2010;
ISTQB. International Software Testing
Programa de estudio nivel bsico.
F. Alonso Amo, Loic Martnez Normand. Introduccin a la Ingeniera del
software. Primera edicion
ed. Barbero Ruiz J, editor. Espaa: Delta
Publicaciones, 2005.
Natalia Juristo, Ana M. Moreno, Sira Vegas. Tcnicas de evaluacin de
software.
[http://www.grise.upm.es/htdocs/sites/extras/12/pdf/Documentacion
_Evaluacion_7.pdf]
BENDEZU MAYHUA HENDERSON, ECHACCAYA MARTINEZ HILARION,MOSCOSO TUPAC AMET MANUEL , PACHAS TASAYCO PERCY RAUL, SOTELO MEZA ALBERTO 40