Documente Academic
Documente Profesional
Documente Cultură
FACULTAD DE INGENIERIA DE
SISTEMAS
Tema: CASOS DE PRUEBAS.
Elaborado por: Rivas Perez Pedro Steen
2015
Lima Per
DEDICATORIA
Tabla de contenido
1. Introduccin:
2. Conceptos Preliminares
3. mbito de Pruebas
4. Tipos de Pruebas
5. Ciclo de Aplicacin de Pruebas
6. Metodologa de Testing
7. Principios de la Prueba del Software
8. Algunas definiciones de Casos de Pruebas
9. Plan de Pruebas y Casos de Pruebas (Ejemplo)
Objetivos
Alcance
Requisitos Funcionales
Personal a Participar en las Pruebas
Modalidad De Ejecucin De Casos De Prueba
Calendario de Pruebas
10.
Conclusiones
11.
Referencias
Introduccin:
En el mbito de la ingeniera de Sistemas las actividades de pruebas son
actividades que han tomado relevante importancias en la actualidad, estas
actividades se realizan con el objetivo de detectar fallos y evaluar las
caractersticas del software. Las pruebas regulan la ejecucin de los proyectos
y garantizan la calidad del software desarrollado. Desde el modelo de
desarrollo en cascada hasta la aparicin de las metodologas giles, las
pruebas han pasado de ser una simple etapa en el proceso de desarrollo a
constituirse en un conjunto de etapas que controlan la duracin del ciclo de
vida, la calidad y la confiabilidad del software desarrollado. En este contexto los
Casos de Pruebas o Test Case son un conjunto de condiciones o variables bajo
las cules el analista determinar si el requisito de una aplicacin es parcial o
completamente satisfactorio.
Otra definicin puede ser, los Casos de Pruebas, son un conjunto de entradas
junto con las condiciones de ejecucin y los resultados esperados, que se
desarrollan con el objetivo de ejercitar un sistema. Especifica como los
elementos participantes en la prueba interactan con el sistema para realizar
el objetivo de la prueba; es decir define las acciones que sern ejecutadas por
un componente de prueba.
De lo que podemos desprender que los casos de pruebas son artefactos que se
desarrollan con miras a describir el camino para llegar a minimizar los errores o
bug en un sistema.
En la actualidad el desarrollo de sistemas tiene una gran demanda y la actual
ubicuidad del software en nuestra vidas, nos lleva a poner especial nfasis en
las pruebas de software, por lo un mal funcionamiento del mismo puede
AUDITORIA.
PGINA 1
AUDITORIA.
PGINA 2
PGINA 3
PGINA 4
PGINA 5
AUDITORIA.
PGINA 6
AUDITORIA.
PGINA 7
AUDITORIA.
PGINA 8
AUDITORIA.
PGINA 9
AUDITORIA.
PGINA 10
AUDITORIA.
PGINA 11
la
estructura
(lgica
interna)
de
cada
elemento
verificaciones
asociadas
grupos
de
componentes,
PGINA 12
AUDITORIA.
PGINA 13
Pruebas funcionales:
Se realizan con la finalidad de verificar que los cambios de componentes,
nuevos desarrollos o configuraciones cumplan con las especificaciones
del requerimiento.
Pruebas integrales:
Identifica los errores como resultado de combinar procesos que han sido
probados individualmente. Este evento de prueba es crucial porque
descubre los errores que no pueden ser localizados durante las pruebas
funcionales, ocurren en las interacciones e interfaces entre unidades y
con otros sistemas. Este tipo de pruebas incluye comprobar funciones o
procesos de negocio claves.
Pruebas de regresin:
En cada nueva versin se supone que se corrigen defectos y/o se
aaden nuevas funciones. En cualquier caso, una nueva versin exige
una nueva ejecucin de las pruebas. Si stas se han sistematizado en
una fase anterior, ahora pueden volver a pasarse automticamente,
simplemente para comprobar que las modificaciones no provocan
errores donde antes no los haba. En la realizacin de las pruebas de
regresin de componentes crticos se aplicar las denominadas Bitcoras
de casusticas, con los cuales podremos asegurar que los flujos
existentes no se vean afectados por el cambio.
Pruebas de performance:
Para las aplicaciones de negocios es importante el tiempo de respuesta
u otros parmetros de gasto. Es til saber cunto tiempo le lleva al
sistema procesar cunta memoria consume, o cunto espacio en disco
utiliza, o cuntos datos transfiere por un canal de comunicaciones, etc.
Las principales actividades de las pruebas de desempeo son:
AUDITORIA.
PGINA 14
el
desempeo
real
del
sistema
respecto
de
los
requerimientos de desempeo.
Afinar el sistema para mejorar las mediciones de desempeo y
proyectar la capacidad futura de manejo de carga del sistema.
Pruebas de stress:
Las pruebas de stress al igual que las de performance son muy importantes
podremos obtener el
AUDITORIA.
PGINA 15
AUDITORIA.
PGINA 16
La ejecucin
PGINA 17
del proyecto.
Cinco procesos: Anlisis y Diseo de Testing, Preparacin de Testing,
Para cada una de ellas se describe claramente los objetivos, el perfil de las
personas a participar, los requerimientos de entrada, las tareas a realizar y los
resultados esperados.
AUDITORIA.
PGINA 18
Estos principios son importantes porque guiarn el accionar del profesional que
prueba del software. Ilene Burstein seala los siguientes, reformulando los
establecidos originalmente por Glenford J. Myers:
Principio 1
Probar es el proceso que consiste en ejecutar un componente de software
utilizando un conjunto de casos de prueba previamente seleccionados con la
intencin de detectar defectos y de evaluar su calidad. Esto supone separar las
pruebas de la depuracin o debugging, actividad esta que se refiere a
reparar el software eliminando los defectos.
Principio 2
Un buen caso de prueba es aquel que tiene una alta probabilidad dehallar
defectos an no detectados. Partiendo de la hiptesis de la presencia de un
AUDITORIA.
PGINA 19
AUDITORIA.
PGINA 21
AUDITORIA.
PGINA 22
Alcance
El alcance de las pruebas est enmarcado dentro del alcance funcional
considerado en la propuesta de solucin que plantea las modificaciones
de los sistemas para a cumplir segn dicta la Resolucin Ministerial N
305-2005-MTC/05 del MTC (ANEXO 2),
767 localidades han sido
designadas como Localidades de Preferente Inters Social (LPIS) y pasan a
tener el mismo tratamiento en cuanto a Numeracin y Rgimen Tarifario
(solo para llamadas entrantes) que las localidades rurales. Con lo que se
identifica la planta total de telfonos instalados en estas localidades,
aquellas que actualmente no estn catalogadas como rurales
(secuencialmente o por etapas) aplicndoles las condiciones normativas
dispuestas por OSIPTEL.
AUDITORIA.
PGINA 23
AUDITORIA.
PGINA 24
DESCRIPCIN
Identificacin del Planta LPIS
RF-12
Se crearn rangos rurales diferenciados para los distintos tipos de lneas, estas son:
Telefona Bsica LPIS, Telefona Bsica LPIS inalmbrica, Lnea Social LPIS, Fonofcil
LPIS, TPE LPIS, TPI LPIS, TPI Prepago LPIS.
Se debe considerar el siguiente esquema de numeracin rural, definido por el
MTC:
Provincias:
Lima:
CD-83-YXZZ
1-830-YXZZ
Donde :
Y=0
Y=1
Y=2
Y=3
Y=4
X = 0,2
Y=5
Y=6
Y=7
Y=8
X=5
Z = del 0 al 9
Nota (*)
Dentro de este millar se encuentran incluidas centrales con tecnologas
AXE, PRX y 5ESS.
Facturacin
RF-21
La llamada saliente de un telfono LPIS a urbanos (mviles, SLM, LDN, LDI), LPIS o
Rurales, mantendr la tarifas vigentes de la promocin o clasificacin vigente
contratada, es decir no se realizar ningn cambio en la tarificacin de sus
llamadas salientes.
AUDITORIA.
PGINA 25
RESPONSABILIDADES
Tester1
Tester2
Donny Bustamante
Tester3
Pedro Laynes
Tester4
Juan Villacorta
Trfico:
Conformado por los siguientes requerimientos.
Orde
n
1
AUDITORIA.
Grupo
Todos los nuevos trficos debern pasar por las anomalas definidas en
PGINA 26
Los reportes mnimos y crticos necesarios ATIS para las pruebas de Trfico
son los siguientes:
AUDITORIA.
PGINA 27
RF1221
RF1326
AUDITORIA.
PGINA 28
RF-36
RF-38
RF-39
RF-40
RF-41
RF-42
AUDITORIA.
PGINA 29
RF-30
RF-45
AUDITORIA.
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
Llamadas
PGINA 30
Distribucin y Emisin:
Orden
Grupo
Cod./
Req.
Distribucin y Emisin:
AUDITORIA.
PGINA 31
RF-22
RF-47
Grupo : Fenix
Orden
Grupo
AUDITORIA.
PGINA 32
Cod./Re
q.
10
11
RF-50
AUDITORIA.
PGINA 33
Grupo
Cod./Req.
Orden
1
Grupo
Cod./Req.
Calendario de Pruebas
Fecha
Sistema
Funciones a Probar
14/09/2012
Recepcin de Entregable
14/09/2012 al
17/09/2012
AUDITORIA.
ATIS
PGINA 34
Validaciones
Configuraciones
de
las
Pruebas de Testing:
ATIS
Conclusiones
La prueba de software tiene el objetivo de encontrar defectos, por lo que
deben ser realizadas por una persona, o un equipo de personas,
independiente del desarrollador del software. Realizar todas las pruebas
posibles generalmente es imposible, por limitaciones de tiempo y de
recursos materiales. La prueba de software consistir en disear y ejecutar
un nmero limitado de casos de prueba que permita encontrar el mximo
nmero de defectos. La prueba de software usualmente requiere utilizar
una combinacin de tcnicas de caja negra y de caja transparente para
lograr un conjunto de casos de prueba consistente, combinacin que
depender de las caractersticas del software y de las limitaciones del
entorno.
Los casos de pruebas reflejan los requerimientos que sern verificados, esta
verificacin deber ser realizada de diferentes maneras y por diferentes
analistas de pruebas. Los casos de pruebas son la parte importante de un
buen Plan de pruebas puesto que son la base para poder determinar si un
software tiene o no errores. En la actualidad basados en las tendencias y la
mejora continua en el desarrollo de software es necesario mejorar el diseo
de los casos de prueba, Actualmente, la gestin de pruebas de software es
una de las tareas ms importantes en la industria del desarrollo de software
y las tecnologas de la informacin, y ms an si el objetivo es desarrollar
productos de calidad. En esa gestin, la prueba es una de las fases ms
importantes, y en sta, lo que requiere ms cuidado y dedicacin es el
diseo de los casos de prueba, por lo que es necesario estudiar cmo
disearlos y escribirlos mejor.
AUDITORIA.
PGINA 35
Referencias
AUDITORIA.
PGINA 36
http://es.wikipedia.org/wiki/Caso_de_prueba
http://www.funlam.edu.co/lampsakos/n3/n3a3.pdf
http://www.kaner.com/pdfs/GoodTest.pdf
AUDITORIA.
PGINA 37