Trabajo Grupal Comprobacion de Software

UNIVERSIDAD PRIVADA TELESUP
FACULTAD DE INGENIERIA DE
SISTEMAS
Tema: CASOS DE PRUEBAS.
Elaborado por: Rivas Perez Pedro Steen
2015
Lima Per
DEDICATORIA
Dedico este trabajo a Dios

Por estar presente en cada
Momento de mi vida y
A mi esposa porque son el
Motivo de m existir.
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

ocasionar desde la molestia por un mensaje inapropiado, hasta la prdida de
cuantiosas sumas de dinero o, peor an, de vidas humanas. Por ello, el
software, a semejanza de cualquier artefacto tangible, debe ser sometido a
pruebas para evaluar si cumple adecuadamente con lo que se espera de l y
hacer minimizar los posibles fallos. Aunque el desarrollador de software realiza
pruebas del mismo, estas deben de realizarse por personal dedicado a esta
actividad especfica se efectan de manera intuitiva e informal. Dada la
creciente demanda de software de calidad, la prueba o testeo del software en
una actividad que ha evolucionado con elu so de diversas tcnicas y
herramientas que la alejan del arte y la acercan a la ingeniera.
Segn la IEEE, probar el software es analizarlo para detectar diferencias entre
las condiciones existentes y las requeridas, y para evaluar las caractersticas
del mismo.
AUDITORIA.
PGINA 2

Conceptos Preliminares
Proyecto de prueba.
Es el conjunto de actividades que involucra la fase de prueba de un
proyecto de desarrollo. Este se realiza por un equipo, con un objetivo
concreto, con una programacin establecida, en un entorno y que aplica
unos procesos para obtener una salida.
Plan de prueba.
Es un documento que describe el alcance, el enfoque, los recursos y la
programacin de las actividades de pruebas previstas. En l se identifican
las caractersticas que deben probarse, los elementos a probar, las tareas
de prueba, los responsables de cada tarea, los riesgos y los planes de
contingencia requeridos. Respecto del alcance deber indicar los niveles
de prueba que deben aplicarse y las mtricas para determinar en qu
momento se debe finalizar el proyecto.
Escenario de prueba.
Este es un elemento clave para la organizacin de las pruebas; cuyo
objetivo es identificar los principales componentes que intervienen durante
su ejecucin. De la misma manera tambin permite crear diferentes
escenarios a partir de la variacin y combinacin de sus componentes. En
concreto permite la identificacin de: el sistema bajo prueba, los requisitos
que se probarn, los datos de prueba que se usarn, el caso o los casos de
prueba y los elementos de la plataforma de ejecucin de prueba que son
necesarios para ejecutar la prueba. A partir de estos elementos se puede
configurar un entorno de prueba y obtener informacin bsica para
establecer la trazabilidad entre requisitos, datos de prueba, caso de
prueba, sistema bajo prueba y resultados.
Entorno de prueba.
Describe el entorno de hardware y software en el que las pruebas se
llevarn a cabo, y cualquier otro software con el que interacta el software
bajo prueba durante su ejecucin bajo la prueba. Especifica la arquitectura
de ejecucin para un escenario de prueba. Por lo tanto representa la
AUDITORIA.
PGINA 3

infraestructura tcnica (libreras, repositorios, sistemas de integracin
continua, herramientas de gestin y control de las pruebas, sistemas de
gestin de incidencias, etc.) que soportan el despliegue de las pruebas.
Hito.
Es un evento que marca la finalizacin de una actividad, la cual debe
entregar como resultado un producto concreto. No tiene esfuerzo ni
recursos asignados. Su definicin dentro del plan es clave para la
aplicacin de los procesos de gestin, especficamente para los de
ejecucin y control & seguimiento.
Producto.
Es el resultado de la ejecucin de una actividad, de una fase o de un
proyecto.
Existen tres clases, salidas, productos de entrega y artefactos. Las salidas
son resultados intangibles que no constituyen un activo en s mismas,
pueden formar parte de la descripcin de un producto. Los productos de
entrega son aquellos que forman parte del resultado para el cliente o para
un participante del proceso. Los artefactos son productos consumidos,
producidos o modificados por una tarea.
Recurso.
Es un elemento que representa un insumo necesario para la ejecucin de
un proyecto, de una actividad o de una tarea. Tiene como caracterstica
que puede ser estimado, asignado, valorado y cuantificado. Entre los
recursos ms comunes podemos mencionar personas, herramientas,
espacio fsico, informacin, etc.
Tcnica de prueba.
Especifica la estrategia a utilizar en las pruebas para seleccionar las
entradas de los casos de prueba y analizar los resultados. Diferentes
tcnicas revelan diferentes aspectos de la calidad de un sistema de
software. Existen dos categoras principales de tcnicas de prueba, las
funcionales y las estructurales. En las funcionales el sistema bajo prueba
se analiza como una caja negra, los casos de prueba se basan en
comprobar los requisitos y/o las especificaciones de diseo. En las
estructurales, el sistema bajo prueba se analiza como una caja blanca, los
AUDITORIA.
PGINA 4

casos de prueba estn orientados a comprobar la implementacin del
software (cdigo), su objetivo bsico es la estructura interna del software.
Cada una de estas dos categoras tiene sub-categoras que describen con
un mayor nivel de detalle las tcnicas a aplicar.
Especificacin.
Este elemento se refiere a la especificacin de requisitos del sistema que
ser sujeto de prueba. Es un documento que especifica los requisitos para
un sistema o componente. Tpicamente se incluyen los requisitos
funcionales, requisitos no funcionales (rendimiento, seguridad, usabilidad
etc.), los requisitos de las interfaces, los requisitos de diseo y estndares
de desarrollo. Dado que en algunos casos no se cuenta con una
especificacin formal de requisitos y que solo se tiene acceso al cdigo a
partir del cual se extrae la arquitectura, o simplemente se tiene la
documentacin del diseo, a partir de la cual se generan los casos de
prueba, se considera como parte de la especificacin de requisitos el
diseo procedimental, de datos, arquitectnico y de interface. De la misma
manera se incluye dentro de dicha especificacin aspectos contractuales
acordados con el cliente como los acuerdos de nivel de servicio (SLA).
Datos de prueba.
Se refiere a los valores, los tipos, las estructuras y los repositorios donde
se alojan los datos que se usarn durante la prueba para ejercitar el
sistema bajo prueba. Los datos pueden ser introducidos directamente en el
momento de la ejecucin, con lo cual solo se tendra un registro de ellos;
pueden estar incluidos en una estructura esttica de datos dentro del
cdigo del caso de prueba; pueden seleccionarse desde una base de
datos, o desde un pool de datos preparado para la prueba.
Batera de prueba.
Este elemento agrupa un conjunto de casos de prueba con una
caracterstica comn, por ejemplo los casos de prueba asociados a un
mismo elemento del sistema bajo prueba o los casos de prueba
relacionados con un nivel de prueba. Puede contener uno o ms casos de
prueba. Es til para organizar los casos de prueba dentro de un proyecto.
AUDITORIA.
PGINA 5
AUDITORIA.
PGINA 6

Registro de prueba.
Son las trazas que deja la ejecucin de un caso de prueba o el contexto de
la prueba (conjunto de casos de prueba); su informacin puede usarse
para validar las acciones del caso de prueba y pude incluirse como parte
del resultado. Contiene la informacin relativa al despliegue y ejecucin de
la prueba. Por lo tanto registra las interacciones del sistema bajo prueba y
de los componentes de la plataforma de ejecucin. En otras palabras
contiene la informacin sobre la ejecucin del escenario de pruebas, que
puede usarse para la reconstruccin de la ejecucin, o para analizar
alguna relacin concreta del sistema bajo prueba con algn elemento del
entorno. Por ejemplo en las tcnicas de generacin de casos de prueba
mediante grabacin, del registro aporta la informacin para posteriores
ejecuciones del caso de prueba, o para introducir posibles variaciones a
este.
Secuencias de comandos de prueba.(Scripts)
Es un documento que contiene las instrucciones para la ejecucin y
evaluacin de los resultados de un caso de prueba, lo define como un
elemento que se usa para automatizar la ejecucin automtica de los
procedimientos de prueba. Es el elemento que contiene las instrucciones
para automatizar el plan de ejecucin, es decir indica que elementos de la
plataforma de despliegue de pruebas y en qu orden deben ejecutarse,
verifica que estos estn desplegados para continuar con el lanzamiento
del sistema bajo prueba y la ejecucin de los casos de prueba.
Adicionalmente contiene las instrucciones necesarias para integrar todos
los elementos del entorno de la prueba que intervienen en la ejecucin de
un caso de prueba.
Elemento de plataforma de despliegue.
Representa aquellos elementos necesarios para desplegar la prueba.
Incluye a las libreras de herramientas de pruebas y los elementos de la
plataforma despliegue del sistema bajo prueba, los cuales por ejemplo
para una prueba de aceptacin equivaldran al entorno real donde se
desplegara el sistema.
AUDITORIA.
PGINA 7
AUDITORIA.
PGINA 8

Plan de ejecucin.
Indica los pasos de ejecucin de la prueba, configura el entorno de
pruebas, describe el orden en que deben desplegarse los elementos de la
plataforma de despliegue, el sistema bajo prueba y los casos de prueba.
Caso de prueba.
Es 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.
Sistema bajo prueba.
Se refiere al sistema que est siendo probado. Se define como una parte,
un elemento, un componente, un subsistema o el sistema completo que es
ejercitado por un caso de prueba.
Nivel de prueba.
Define el alcance de la prueba en cuanto a que elementos del sistema se
probarn. Se definen los siguientes niveles: unitario, componente,
integracin, interface y de sistema. Su aplicacin depende del grado de
avance del ciclo de desarrollo. De acuerdo con la metodologa de
desarrollo que se emplee y con la complejidad del sistema, se pueden
definir otros niveles tales como: alfa, beta o de aceptacin entre otros.
Objetivo.
Consiste en un conjunto concreto de caractersticas del software que se
evaluarn bajo condiciones especficas, comparando el comportamiento
real del sistema con el comportamiento especificado por la documentacin
del sistema. En otras palabras, el objetivo de la prueba describe las
cualidades del sistema que el caso de prueba debe probar. Por lo tanto un
objetivo est siempre asociado a un caso de prueba.
AUDITORIA.
PGINA 9

Resultado de la prueba.
Corresponde a la salida generada por el sistema bajo prueba como
consecuencia de la ejecucin de un caso de prueba. Cada caso de prueba
tiene asociado un resultado.
Informe de prueba.
Es un documento que describe la conducta y los resultados de las pruebas
realizadas en un sistema o un componente.
Veredicto.
Define en concreto el resultado de la prueba, el cual puede ser: inconcluso,
fallo, paso, error. Inconcluso cuando la ejecucin de la prueba no se pudo
finalizar y por lo tanto no es posible determinar su resultado. Fallo se
refiere a que el resultado de la prueba no concuerda con el resultado
esperado. Error cuando durante la ejecucin de la prueba se presenta una
excepcin ocasionada por algn componente del sistema de prueba (por
ejemplo, una divisin por cero, un error de sintaxis, ausencia de un
elemento para continuar con la ejecucin).
Incidencia.
Se genera como resultado de la deteccin de un fallo en el sistema bajo
prueba por la ejecucin de un caso de prueba. Est relacionada con un
componente del sistema bajo prueba.
Polticas de pruebas.
Expresan la filosofa de la organizacin, sus objetivos, las mtricas claves
de pruebas e incluso polticas de aseguramiento de la calidad. A partir de
ellas se controla la ejecucin. Estas pueden variar dependiendo del tipo de
proyecto y del dominio de aplicacin. Deben definirse claramente sin
ambigedad y de ser posible deben expresarse de manera cuantitativa.
AUDITORIA.
PGINA 10

Manual de pruebas.
Define las actividades, procedimientos y tareas de pruebas independiente
de cualquier proyecto especfico. Describe las actividades mnimas que
deben cubrirse durante las pruebas. Este debe incluir una definicin de
alto nivel de las fases del ciclo de prueba.
AUDITORIA.
PGINA 11

mbito de Pruebas
El mbito se puede conocer como etapas de las pruebas, y podemos definirlas
como:
Pruebas unitarias.
Su objetivo es probar las unidades ms pequeas del software, el
componente o mdulo de software. Centran su actividad en verificar la
funcionalidad
la
estructura
(lgica
interna)
de
cada
elemento
individualmente, una vez que ha sido codificado. Se realizan en el entorno

del desarrollador.
Pruebas de componentes.
Son un tipo de pruebas unitarias, realizadas por los desarrolladores para
probar que la funcionalidad bsica de los componentes y las funciones
dentro de un servicio son conformes con las especificaciones. El objetivo de
la prueba del componente es coger la pieza ms pequea del software a
probar, aislarlo del resto del cdigo, y determinar si se comporta
exactamente como se espera. Cada componente se prueba por separado
antes de integrarlo en servicio(s). Se revisa formalmente del cdigo para
asegurar la conformidad con estndares de la organizacin e identificar
debilidades.
Pruebas de integracin.
Comprenden
verificaciones
asociadas
grupos
de
componentes,
generalmente reflejados en la especificacin de diseo del sistema y/o

subsistemas, y culminan probando el sistema como conjunto. Se centran en
verificar el ensamblaje correcto entre los distintos componentes, una vez
que han sido probados unitariamente. Se efectan en el entorno del
desarrollador.
Pruebas de sistema.
AUDITORIA.
PGINA 12

Son pruebas de integracin del sistema completo. Permiten probar el
sistema en su conjunto y con otros sistemas con los que se relaciona para
verificar que las especificaciones funcionales y tcnicas se cumplen. Se
realizan en un entorno fuera del alcance del desarrollador.
Pruebas de aceptacin.
Los usuarios prueban el sistema o aplicacin para establecer si est listo
para desplegarlo.
Las etapas de las pruebas mencionadas anteriormente, no son fases que se
ejecutan rigurosamente en ese orden en un desarrollo iterativo. En una
iteracin pueden usarse cualquiera de las etapas. Por ejemplo en una primera
iteracin puede aplicarse una prueba de aceptacin, para establecer si el
cliente est de acuerdo con el prototipo, sin aplicar pruebas unitarias.
AUDITORIA.
PGINA 13

Tipos de Pruebas
De acuerdo con las dimensiones de calidad que se desean evaluar, en las
pruebas se clasifican como:
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

Comparar
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
para las aplicaciones de negocios que cuenta con un elevado nmero de

usuarios concurrentes. Con este tipo de pruebas se puede medir
rendimiento real y lmites potenciales del sistema,
podremos obtener el
punto de quiebre en que la aplicacin puede tener problemas debido a la

cantidad de usuarios, de manera que se puedan tomar las acciones
correctivas antes de que el problema llegue a los entornos productivos.
Pruebas de seguridad:
Este tipo de pruebas estn orientadas a identificar las vulnerabilidades de
seguridad que pueden tener las aplicaciones.
AUDITORIA.
PGINA 15

Ciclo de Aplicacin de Pruebas
Para resolver la complejidad de la ejecucin de las pruebas de software, estas
se tratan como un proyecto relacionado con el proceso de desarrollo. En este
sentido se divide su aplicacin en fases, conformando un ciclo de pruebas, se
definen brevemente como:
Requisitos de las pruebas.
Se definen todos los recursos necesarios para la ejecucin de las pruebas
como: herramientas, roles, tiempo, elementos del entorno (requisitos,
especificaciones funcionales, modelos y cdigos del sistema a probar). Se
expresa un Plan de Pruebas.
Diseo de las pruebas.
En esta fase se identifican los siguientes aspectos: tem de prueba, el
enfoque de prueba detallado y los casos de pruebas de alto nivel asociados.
Se seleccionan y derivan los casos de pruebas. El resultado es un
documento que contiene el diseo de las pruebas, especficamente
definiendo la estructura de la suite de pruebas.
Especificacin de las pruebas.
Adiciona datos concretos al diseo de pruebas, sobre los casos de pruebas y
las especificaciones del procedimiento de pruebas. La finalidad es detallar
las condiciones de pruebas a la especificacin del diseo y como ejecutar
cada prueba incluyendo por ejemplo los procedimientos de inicio y
finalizacin, as como los pasos de prueba que deben seguirse.
Implementacin de las pruebas.
Comprende la generacin de las pruebas a partir de las especificaciones del
modelo o del sistema (cdigo). Como resultado se obtendrn los artefactos
del sistema bajo prueba tales como la configuracin de las pruebas y el
contexto de las pruebas.
AUDITORIA.
PGINA 16

Validacin de las pruebas.
Esta actividad verifica la conformidad de las pruebas. Esto implica verificar
la conformidad interna tanto con las especificaciones del sistema como con
el modelo del sistema. La conformidad interna, consiste en verificar que
estn definidos todos los casos de pruebas (suficientes), as como los datos
de pruebas necesarios, que los procedimientos de prueba no presenten
bloqueos, que la sintaxis y la semntica de las pruebas indicadas estn
conformes.
Ejecucin de las pruebas.
Comprende todos los pasos necesarios para ejecutar de forma manual o
automtica las pruebas. La ejecucin manual debe estar apoyada por
herramientas guiadas por procedimientos de pruebas.
La ejecucin
automtica necesita la generacin de scripts de pruebas junto con los

ejecutores de pruebas. Adicionalmente se usa una plataforma de pruebas
para ejecutar y registrar el seguimiento automticamente. Tanto las
pruebas manuales como las automticas se analizan subsecuentemente.
Evaluacin de las pruebas.
Esta actividad implica la comparacin de los resultados esperados versus
los obtenidos, durante la ejecucin de las pruebas. Estas respuestas
incluyen salidas grficas, cambios de datos y de estados internos, informes
generados y comunicacin con el entorno.
La propuesta anterior de definicin de las actividades de ciclo de pruebas,
describe muy brevemente stas en funcin de las herramientas que pueden
soportarla, orientadas hacia la generacin automtica de pruebas a partir de
modelos. Sin embargo no detalla las actividades que forman parte de cada
fase, ni como fluye la informacin entre ella, por lo tanto es difcil de aplicar a
cualquier dominio. Al respecto se proponen varios enfoques de ciclo de vida de
prueba; que describen el proceso de prueba como un grupo de cuatro etapas:
planificacin, diseo, ejecucin y revisin de los resultados.
AUDITORIA.
PGINA 17

Metodologa de Testing
La metodologa de Testing est soportada por herramientas, estndares
internacionales de modelos de procesos (CMMI), estndares de calidad (IEES,
ISO), estndares de procesos de gestin (PMBOK).
La metodologa de Testing est dirigida al equipo de Testing de Software
Factory de GMD, cuya responsabilidad es velar por el control de calidad de las
aplicaciones que atienden a los diferentes proyectos de la lnea de negocio.
Est compuesta de :
Cinco fases: Inicio, Planificacin,
del proyecto.
Cinco procesos: Anlisis y Diseo de Testing, Preparacin de Testing,
Ejecucin, Seguimiento Control y Cierre
Ejecucin de Testing, Evaluacin de Resultados y Cierre 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
Principios de la Prueba del Software
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

determinado tipo de defecto, se escogen las condiciones de entrada, se
determinan losr esultados esperados y se realiza la prueba para determinar si
el defecto est o no presente.
Principio 3
Los resultados de cada prueba deben ser revisados meticulosamente. Si un
defecto es pasado por alto o si se declara equivocadamente- la existencia de
un defecto que no es tal, las consecuencias pueden ser muy costosas.
Principio 4
Cada caso de prueba debe incluir el resultado esperado. El resultado esperado
es lo que permitir determinar si existen o no defectos.
Principio 5
Los casos de prueba deben incluir condiciones de entrada vlidas einvlidas.
La robustez del software se puede evaluar probando su funcionamiento con
entradas invlidas.
Principio 6
La probabilidad de que existan defectos adicionales en un componente de
software es directamente proporcional al nmero de defectos y adetectados en
ese componente. Este principio se basa en la evidencia emprica. Las razones
pueden ser el nivel de complejidad o algunos defectos de diseo.
Principio 7
Las pruebas deben ser conducidas por personas independientes a las que
hicieron el desarrollo El desarrollador est squicamente preparado para que su
obra funcione bien, de modo que le ser muy difcil asumir el principio 1:
detectar defectos.
Principio 8
Las pruebas deben ser repetibles y reutilizables. Las pruebas deben ser
repetidas luego de haberse reparado el defecto. Adems tambin sern muy
AUDITORIA.
PGINA 20

tiles para las pruebas de regresin, es decir, las que se realizarn cuando, por
razones de evolucin o mejora, el software tenga que ser modificado.
AUDITORIA.
PGINA 21

Algunas definiciones de Casos de Pruebas
Qu es un caso de prueba?
Norma IEEE 610 (1990) define caso de prueba como sigue:
(1) Es un conjunto de entradas de prueba, las condiciones de ejecucin y
resultados esperados desarrollado para un objetivo particular, como para
ejercer una ruta de programa en particular o para verificar el cumplimiento con
un requisito especfico.
(2) (IEEE Std 829-1983) Documentacin que especifique los insumos, predijo
resultados, y establecer un de las condiciones de ejecucin de un elemento de
prueba.
Segn Ron Patton (2001, p. 65),
"Los casos de prueba son las aportaciones especficas que usted va a tratar y
los procedimientos que se le siguen al probar el software. "
Boris Beizer (1995, p. 3) define una prueba como
"Una secuencia de uno o ms subtests ejecutan como una secuencia porque el
resultado y / o estado final de una subprueba es la entrada y / o estado inicial
de la siguiente. 'Test' La palabra es utiliza para incluir subtests, pruebas
adecuadas, y suites de prueba.
Bob Binder (. 1999, p 47) define caso de prueba:
"Un caso de prueba especifica el pretest estado del IUT y su entorno, las
entradas de prueba o condiciones y el resultado esperado. El resultado
esperado especifica lo que el IUT debera producir a partir de las entradas de
prueba. Esta especificacin incluye los mensajes generados por la IUT,
excepciones, los valores de retorno, y el estado resultante de la IUT y su
entorno. Los casos de prueba Tambin puede especificar las condiciones
iniciales y resultantes para otros objetos que constituyen el IUT y su medio
ambiente ".
AUDITORIA.
PGINA 22

Plan de Pruebas y Casos de Pruebas (Ejemplo)
Objetivos
El presente documento tiene como objetivo principal, describir las
actividades a realizar durante las pruebas con los usuarios. Para cada
requerimiento descrito en el documento Propuesta de Solucin se ha
planteado los puntos a probar.
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.
Identificar la planta total LPIS de telfonos instalados.

Cargar y adaptar al sistema con los nuevos catlogos proporcionados
por ATIS AC.
Creacin de rangos Rurales en la serie 83.
Ejecutar un cambio de nmero masivo de nmeros a toda la planta
LPIS, conservando el perfil inicial del producto.
Cobrar tarifa rural a todas las llamadas entrantes a los telfonos LPIS,
salvo aquellas llamadas que se originen en otro LPIS u otro rural.
Verificar la aplicacin de las condiciones normativas dispuestas por
OSIPTEL.
AUDITORIA.
PGINA 23

Requisitos Funcionales
AUDITORIA.
PGINA 24

Cd./Re
q
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
CD: Cdigo Departamental
1-830-YXZZ
Donde :
Y=0
para TUP Rural VSAT Gilat (X = 0 al 9)
Y=1
Y=2
para TUP Rural MAR (X = 0 al 9)
Y=3
Y=4
para TUP Rural VSAT Dama
X = 0,2
X = 3,4,5 para TUP LPIS

RF-13
X=9
para TUP Rural Inalmbrico
Y=5
para TUP Rural Celular (X = 0 al 9)
Y=6
para Rurales con T. Bsica MAR (X = 0 al 9)
X = 0 al 8 para Bsico Rural MAR (*)

X=9
para Fono rural
Y=7
para Rurales con T. Bsica VSAT Gilat/Dama (X = 0 al 9)
Y=8
para LPIS con T. Bsica URA (X = 0 al 9)
X=5
para T. Bsica LPIS Inalmbrica
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
En el caso de telfonos TUP LPIS, no se realizan cambios en las comisiones.

Personal a Participar en las Pruebas
Participantes y responsabilidad de los participantes
PARTICIPANTE
RESPONSABILIDADES
Enrique Ros Sarazu
Tester1
Ricardo Torres Ros
Tester2
Donny Bustamante
Tester3
Pedro Laynes
Tester4
Juan Villacorta
Desarrollador de Configuraciones ATIS IN
Pilar Garca Prieto
Desarrollador de Configuraciones ATIS FA
Fernando Gmez Santos
Desarrollador de Configuraciones Fnix
Vctor Gmez Santos
Jefe de Proyecto por COMSA
Carlos Castro Narvez
Jefe de Proyecto por Telefonica
Modalidad De Ejecucin De Casos De Prueba

OBJETIVO
Registrar las incidencias, es decir los errores durante las pruebas, y las
observaciones, es decir los ajustes o complementos al requerimiento o
adicionales que el usuario solicite.
El detalle de la ejecucin de pruebas por requerimiento es el siguiente:
Grupo: Trafico (Simulacin de una Cclica completa para Ciclo 28).
Conformado por los siguientes requerimientos:
Trfico:
Conformado por los siguientes requerimientos.
Orde
n
1
AUDITORIA.
Grupo
Todos los nuevos trficos debern pasar por las anomalas definidas en
PGINA 26

ATIS.
Asegurar la inclusin de los nuevos trficos en todos los reportes ATIS de

trficos (incluye descuentos).
Pruebas de visualizacin en el on-line del mdulo de trficos de ATIS-FA.
Los reportes mnimos y crticos necesarios ATIS para las pruebas de Trfico
son los siguientes:
Reportes ATIS TRAFICO: Adicional a los reportes mencionados, se deben de

generar las muestras de Facturasfacturas y Reportesreportes 14R1, 14R2 y
SUNAT.Sunat.

Trfico:
AUDITORIA.
PGINA 27

Se debe de verificar los 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 espera identificar los rangos rurales de la planta LPIS en las
distintas lneas de telfonos instalados.Probar que la llamadas
salientes 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.
RF1221
En el caso de telfonos TUP LPIS, no se realizan cambios en las

comisiones.
A los telfonos LPIS se les considerar que la llamada entrante
ser considerada como Rural, si es que la llamada tiene origen
en una zona urbana.
Verificar el siguiente esquema de numeracin rural, definido por
el MTC:
Provincias: CD-83-YXZZ (CD: Cdigo Departamental) Lima:
1-830-YXZZ
Donde :
Y=0
Y=1
Y=2
Y=3
Y=4
X = 0,2
X = 3,4,5 para TUP LPIS
X=9
para TUP Rural Inalmbrico
Y=5
para TUP Rural Celular (X = 0 al 9)
Y=6
para Rurales con T. Bsica MAR (X = 0 al 9)
X = 0 al 8 para Bsico Rural MAR (*)
X=9
para Fono rural
Y=7
para Rurales con T. Bsica VSAT Gilat/Dama (X = 0 al 9)
Y=8
para LPIS con T. Bsica URA (X = 0 al 9)
X=5
para T. Bsica LPIS Inalmbrica
Z = del 0 al 9
RF1326
AUDITORIA.
Nota (*) Se encuentran incluidas centrales con tecnologas

AXE, PRX y 5ESS.
Se espera verificar la numeracin rural que tomaran los
nmeros identificados por la planta LPIS.Verificar la
configuracin y restricciones de acuerdo al tipo de plan de las
lneas y bloqueos a excepcin del bloqueo de la serie 81, 82 y
83 en las lneas cerradas LPIS (Limite de Consumo y prepagos)
se cumplan.
Probar que la llamadas salientes 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.
Se espera que el trfico de llamadas salientes de un telfono
LPIS hacia urbanos o rurales no presenten cambios en su
tarificacin es decir mantengan la promocin vigente
contratada.
PGINA 28

Facturacin:
RF-25
RF-36
Verificar creacin y configuracin de nuevos cdigos de Cargos

Cofas, para su diferenciacin.
Verificar el recibo telefnico y las hojas de liquidacin
mantengan su estructura actual utilizando las glosas
existentes para el caso de llamadas salientes.
Verificar que en las Lneas Abiertas, LDC y Prepago LPIS las
llamadas hacia la serie rural y LPIS se considerar como
llamadas locales LDN segn corresponda por lo que no se
realizar ninguna modificacin en el recibo.
Para el trfico entrante a la planta LPIS: Verificar el
mantenimiento de glosas actuales de Telefona Rural.
Nota: No aplican los modelos de recibos para LDC y Prepago,
puesto que el trfico a la serie rural est restringido.
RF-38
RF-39
RF-40
RF-41
RF-42
AUDITORIA.
Se debe de Verificar los reportes 14R1, 14R2 y SUNAT, tienen

su equivalente en el ATIS con las configuraciones realizadas
en el Daco Visual.
Validar las siguientes configuraciones:
Configuraciones en DAME (ahora EMM4)

Configuraciones en ATIS FA (Asociacin de TTD).
Configuraciones en ATIS IN
Configuraciones en ATIS CO
Configuraciones en ATIS AC
Configuraciones en Cocofade
Este trfico debe de ser considerado en todos los
Reportes ATIS (Anmalos, Trficos, Cierre)
Verificar recibos conteniendo los diferentes tipos de llamadas,

incluyendo las llamadas salientes a urbanos (mviles, SLM,
LDN, LDI); del LPIS a rural y de LPIS a LPIS.
En la Facturacin Detallada Local verificar el prefijo del Tipo de
Llamadas hacia un LPIS, que deber ser el mismo que hacia un
rural (TPR)
Verificar que los actuales COFAS salientes para las lneas LPIS,
de acuerdo al tipo de producto. Para el caso de las llamadas
entrantes a LPIS se utilizarn las COFAS existentes para las
llamadas entrantes rurales
Verificar que el negocio TUP Rural canalize los ingresos
generados por las llamadas entrantes hacia un LPIS.
PGINA 29

EMM4:
RF-24
Se tendr que analizar el impacto en los sistemas (BMP, DAME,

EMM4 y ATIS) y se tendr que realizar las adecuaciones
necesarias.
Adecuaciones en el EMM4
Debe de considerarse la validacin contra la serie de centrales
(telf_a, telf_b)
RF-30
Deber de definir los formatos de salida a ATIS-FA.

Se debern de definir los TTs, cual es su valor.
Las pruebas debern de abarcar todas las entradas y salidas
de la plataforma, EMM4 hasta el ingreso haca ATIS-FA y deben
de ser generadas para Lima y Provincias.
Probar en el Mediador:
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
Locales salientes de LPIS a LIPS

Locales salientes de LPIS a LIPS (duracin cero)
PQL salientes de LPIS a (duracin cero)
PQL salientes de LPIS a LIPS.
PQL salientes de LPIS a LIPS duracin cero)
LDN salientes de LPIS a LIPS.
LDN salientes de LPIS a LIPS (duracin cero)
LDI salientes de LPIS a LIPS.
LDI salientes de LPIS a LIPS (duracin cero)
Locales entrantes a LIPS.
PQL entrantes a LIPS.
LDN entrantes a LIPS.
LDI entrantes a LIPS.
Locales salientes de LPIS a TUP Urbanos.
PQL salientes de LPIS a TUP Urbanos
LDN salientes de LPIS a TUP Urbanos
LDI salientes de LPIS a TUP Urbanos
Locales salientes de LPIS a Bsica (<> LIPS)
PQL salientes de LPIS a Bsica (<> LIPS)
LDN salientes de LPIS a Bsica (<> LIPS)
LDI salientes de LPIS a Bsica (<> LIPS)
Distribucin y Emisin:
Orden
Grupo
Asegurar la inclusin de los nuevos trficos en todos

los reportes ATIS de Emisin, Distribucin, Cierre.
Muestras de facturas y Hoja de Liquidaciones en la que

se observe los siguientes puntos:
Cod./
Req.
Pruebas para la generacin de facturas en

lneas Abiertas, lneas Limite de Consumo que
contengan todas las cofas a facturarse y en
todas las casusticas anteriores (Servicio Local,
LdN y Tup, etc)
Claridad en las glosas (definidas por el usuario
de facturacin)
Correcto ordenamiento en la factura y la Hoja
de Liquidacin (definidas por el usuario de
facturacin MAS NO la posicin en ATIS)
Las muestras debern de tener todos los
conceptos antiguos y nuevos a probar definidas
en el IVDR.
Pruebas con los nuevos formatos en caso se
modifiquen.
Distribucin y Emisin:
AUDITORIA.
PGINA 31

Verificar que para los telfonos LPIS se conservar el mismo
formato de Recibo y Hoja de Liquidacin segn se trate de un
TUP o un Bsico (Verificar que se mantienen todas las
configuraciones de emisin y recibo)
RF-22
Verificar la inclusin de los nuevos trficos en todos los reportes

ATIS de emisin, distribucin, cierre se muestre en las facturas
y Hoja de Liquidaciones en la que se observe los siguientes
puntos:
RF-47
Generacin de facturas en lneas Abiertas, lneas Limite de

Consumo que contengan todas las cofas a facturarse y en todas
las casusticas anteriores (Servicio Local, LdN y Tup, etc)
Claridad en las glosas.
Correcto ordenamiento en la factura y la Hoja de Liquidacin
(definidas por el usuario de facturacin MAS NO la posicin en
ATIS)
Las muestras debern de tener todos los conceptos antiguos y
nuevos a probar definidas en el IVDR.
Pruebas con los nuevos formatos en caso se modifiquen.
Grupo : Fenix
Pruebas Usuario/Testing - Online:
Orden
Grupo
1 telfono LPIS que quiere hacer un reclamo de

facturacin
1 telfono NO LPIS que quiere hacer un reclamo de

facturacin
1 telfono LPIS que quiere hacer un reclamo de calidad
1 telfono NO LPIS que quiere hacer un reclamo de

calidad
1 telfono LPIS que quiere hacer una inspeccin
AUDITORIA.
PGINA 32
Cod./Re
q.

6
1 telfono NO LPIS que quiere hacer una inspeccin
1 telfono LPIS que quiere hacer una queja
1 telfono NO LPIS que quiere hacer una queja
1 telfono LPIS que quiere hacer un ajuste
10
1 telfono NO LPIS que quiere hacer un ajuste
11
1 telfono LPIS para generar reclamo, este telfono

debe una factura que posea COFAS NUEVAS
CONFIGURADOS por LPIS.

Fenix:
RF-49
RF-50
AUDITORIA.
Verificar en el sistema Fnix se deber cargar el archivo con la

informacin del CNM liquidado (numero antiguo / numero
nuevo, numero de inscripcin y fecha de cambio)
Realizado el cruce de informacin debe verificarse que el
nmero ingresado corresponde al CNM se deber emitir el
mensaje correspondiente: el numero ha sido cambiado por
disposicin del MTC RM Nro 305-2005-MTC/05
PGINA 33

Pruebas Testing Online:
Orden
1
Grupo
Cod./Req.
Usar el aplicativo FENIX sin cargar ningn

telfono en la tabla de CNM por LPIS
Pruebas Testing Batch:

Orden
1
Grupo
Cod./Req.
Carga batch de archivo con CNM por LPIS y

visualizacin en FENIX
Consideraciones para la ejecucin de pruebas por requerimiento es el

siguiente:
1. Que exista el archivo de entrada con los telfonos migrados por LPIS,
en base a la estructura indicada.
2. Que exista los archivos con las COFFAS nuevas que sern cargados en
FENIX.
3. Que existan facturas en ATIS con las nuevas COFFAS para las pruebas
en FENIX.
4. Contar telfonos migrados por LPIS
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

17/09/2012 al
03/10/2012
Pruebas de Testing:
ATIS
EMM4 - Trafico Facturacin

Distribucin y Emisin - Fenix
Las pruebas se realizarn en: Area de Testing
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

Para desarrollar software de calidad y libre de errores, el plan de pruebas y
los casos de prueba son muy importantes. Un caso de prueba bien diseado
tiene gran posibilidad de llegar a resultados ms fiables y eficientes,
mejorar el rendimiento del sistema, y reducir los costos en tres categoras:
1) En la productividad, menos tiempo para escribir y mantener los casos.
2) Capacidad de prueba, menos tiempo para ejecutarlos.
3) Programar la fiabilidad, estimaciones ms fiables y efectivas.
No hay una frmula sencilla o exacta para la generacin de "buenos" casos
de prueba. El mbito de las pruebas es demasiado complejo para esto. Hay
pruebas de que son buenos para sus propsitos, para que produzca el tipo
de informacin que se est buscando.
Muchos analista de pruebas, disean sus casos de pruebas en base o lo
requerimientos, ellos son principalmente probadores de escenario o
prp0badores de dominio. Para lograr la amplia gama de valor de nuestras
pruebas, tenemos que utilizar una amplia gama de tcnicas, que van
evolucionando da a da.
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

Trabajo Grupal Comprobacion de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo Grupal Comprobacion de Software

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

Dedico este trabajo a Dios

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

individualmente, una vez que ha sido codificado. Se realizan en el entorno

generalmente reflejados en la especificacin de diseo del sistema y/o

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

para las aplicaciones de negocios que cuenta con un elevado nmero de

punto de quiebre en que la aplicacin puede tener problemas debido a la

seguridad que pueden tener las aplicaciones.

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

automtica necesita la generacin de scripts de pruebas junto con los

UNIVERSIDAD PRIVADA TELESUP

Cinco fases: Inicio, Planificacin,

Ejecucin, Seguimiento Control y Cierre

Ejecucin de Testing, Evaluacin de Resultados y Cierre de Testing

UNIVERSIDAD PRIVADA TELESUP

Principios de la Prueba del Software

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

Identificar la planta total LPIS de telfonos instalados.

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

CD: Cdigo Departamental

para TUP Rural VSAT Gilat (X = 0 al 9)

para TUP Rural VSAT Gilat (X = 0 al 9)

para TUP Rural MAR (X = 0 al 9)

para TUP Rural MAR (X = 0 al 9)

para TUP Rural VSAT Dama

para TUP Rural VSAT Dama

X = 3,4,5 para TUP LPIS

para TUP Rural Inalmbrico

para TUP Rural Celular (X = 0 al 9)

para Rurales con T. Bsica MAR (X = 0 al 9)

X = 0 al 8 para Bsico Rural MAR (*)

para Fono rural

para Rurales con T. Bsica VSAT Gilat/Dama (X = 0 al 9)

para LPIS con T. Bsica URA (X = 0 al 9)

para T. Bsica LPIS Inalmbrica

En el caso de telfonos TUP LPIS, no se realizan cambios en las comisiones.

UNIVERSIDAD PRIVADA TELESUP

Enrique Ros Sarazu

Ricardo Torres Ros

Desarrollador de Configuraciones ATIS IN

Pilar Garca Prieto

Desarrollador de Configuraciones ATIS FA