trabajo grupal comprobacion de software
DESCRIPTION
comprobacion de software, trabajo grupal, VII cicloTRANSCRIPT
UNIVERSIDAD PRIVADA TELESUP
FACULTAD DE INGENIERIA DE SISTEMASTema: “CASOS DE PRUEBAS”.
Elaborado por: Rivas Perez Pedro Steen
2015
Lima – Perú
UNIVERSIDAD PRIVADA TELESUP
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.
UNIVERSIDAD PRIVADA TELESUP
Tabla de contenido
1. Introducción:
2. Conceptos Preliminares
3. Ámbito de Pruebas
4. Tipos de Pruebas
5. Ciclo de Aplicación de Pruebas
6. Metodología 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 Ejecución De Casos De Prueba
Calendario de Pruebas
10.Conclusiones
11.Referencias
UNIVERSIDAD PRIVADA TELESUP
Introducción:
En el ámbito de la ingeniería 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 características del software. Las pruebas regulan la ejecución de los
proyectos y garantizan la calidad del software desarrollado. Desde el modelo de desarrollo en
cascada hasta la aparición de las metodologías á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
duración 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 cuáles el
analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.
Otra definición puede ser, los Casos de Pruebas, son un conjunto de entradas junto con las
condiciones de ejecución y los resultados esperados, que se desarrollan con el objetivo de ejercitar
un sistema. Especifica como los elementos participantes en la prueba interactúan con el sistema
para realizar el objetivo de la prueba; es decir define las acciones que serán 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 ocasionar desde la molestia por un mensaje inapropiado,
hasta la pérdida de cuantiosas sumas de dinero o, peor aún, 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
“AUDITORIA”. PÁGINA 1
UNIVERSIDAD PRIVADA TELESUP
dedicado a esta actividad específica se efectúan 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 técnicas y herramientas que la alejan del arte y la acercan a la
ingeniería.
Según la IEEE, probar el software es analizarlo para detectar diferencias entre las condiciones
existentes y las requeridas, y para evaluar las características del mismo.
“AUDITORIA”. PÁGINA 2
UNIVERSIDAD PRIVADA TELESUP
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 programación 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 programación de las
actividades de pruebas previstas. En él se identifican las características 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 métricas para determinar en qué momento se debe finalizar el
proyecto.
Escenario de prueba.
Este es un elemento clave para la organización de las pruebas; cuyo objetivo es identificar los
principales componentes que intervienen durante su ejecución. De la misma manera
también permite crear diferentes escenarios a partir de la variación y combinación de sus
componentes. En concreto permite la identificación de: el sistema bajo prueba, los requisitos
que se probarán, los datos de prueba que se usarán, el caso o los casos de prueba y los
elementos de la plataforma de ejecución de prueba que son necesarios para ejecutar la
prueba. A partir de estos elementos se puede configurar un entorno de prueba y obtener
información básica 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 llevarán a cabo, y
cualquier otro software con el que interactúa el software bajo prueba durante su ejecución
bajo la prueba. Especifica la arquitectura de ejecución para un escenario de prueba. Por lo
tanto representa la infraestructura técnica (librerías, repositorios, sistemas de integración
“AUDITORIA”. PÁGINA 3
UNIVERSIDAD PRIVADA TELESUP
continua, herramientas de gestión y control de las pruebas, sistemas de gestión de
incidencias, etc.) que soportan el despliegue de las pruebas.
Hito.
Es un evento que marca la finalización de una actividad, la cual debe entregar como
resultado un producto concreto. No tiene esfuerzo ni recursos asignados. Su definición
dentro del plan es clave para la aplicación de los procesos de gestión, específicamente para
los de ejecución y control & seguimiento.
Producto.
Es el resultado de la ejecución 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 descripción
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 ejecución de un proyecto, de
una actividad o de una tarea. Tiene como característica que puede ser estimado, asignado,
valorado y cuantificado. Entre los recursos más comunes podemos mencionar personas,
herramientas, espacio físico, información, etc.
Técnica de prueba.
Especifica la estrategia a utilizar en las pruebas para seleccionar las entradas de los casos de
prueba y analizar los resultados. Diferentes técnicas revelan diferentes aspectos de la calidad
de un sistema de software. Existen dos categorías principales de técnicas 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 diseño. En las estructurales, el sistema bajo prueba se analiza como una caja blanca, los
casos de prueba están orientados a comprobar la implementación del software (código), su
“AUDITORIA”. PÁGINA 4
UNIVERSIDAD PRIVADA TELESUP
objetivo básico es la estructura interna del software. Cada una de estas dos categorías tiene
sub-categorías que describen con un mayor nivel de detalle las técnicas a aplicar.
Especificación.
Este elemento se refiere a la especificación de requisitos del sistema que será sujeto de
prueba. Es un documento que especifica los requisitos para un sistema o componente.
Típicamente se incluyen los requisitos funcionales, requisitos no funcionales (rendimiento,
seguridad, usabilidad etc.), los requisitos de las interfaces, los requisitos de diseño y
estándares de desarrollo. Dado que en algunos casos no se cuenta con una especificación
formal de requisitos y que solo se tiene acceso al código a partir del cual se extrae la
arquitectura, o simplemente se tiene la documentación del diseño, a partir de la cual se
generan los casos de prueba, se considera como parte de la especificación de requisitos el
diseño procedimental, de datos, arquitectónico y de interface. De la misma manera se
incluye dentro de dicha especificación 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 usarán durante la prueba para ejercitar el sistema bajo prueba. Los datos pueden ser
introducidos directamente en el momento de la ejecución, con lo cual solo se tendría un
registro de ellos; pueden estar incluidos en una estructura estática de datos dentro del
código del caso de prueba; pueden seleccionarse desde una base de datos, o desde un pool
de datos preparado para la prueba.
Batería de prueba.
Este elemento agrupa un conjunto de casos de prueba con una característica común, 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 más casos de
prueba. Es útil para organizar los casos de prueba dentro de un proyecto.
“AUDITORIA”. PÁGINA 5
UNIVERSIDAD PRIVADA TELESUP
Registro de prueba.
Son las trazas que deja la ejecución de un caso de prueba o el contexto de la prueba
(conjunto de casos de prueba); su información puede usarse para validar las acciones del
caso de prueba y pude incluirse como parte del resultado. Contiene la información relativa al
despliegue y ejecución de la prueba. Por lo tanto registra las interacciones del sistema bajo
prueba y de los componentes de la plataforma de ejecución. En otras palabras contiene la
información sobre la ejecución del escenario de pruebas, que puede usarse para la
“reconstrucción” de la ejecución, o para analizar alguna relación concreta del sistema bajo
prueba con algún elemento del entorno. Por ejemplo en las técnicas de generación de casos
de prueba mediante grabación, del registro aporta la información 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 ejecución y evaluación de los
resultados de un caso de prueba, lo define como un elemento que se usa para automatizar la
ejecución automática de los procedimientos de prueba. Es el elemento que contiene las
instrucciones para automatizar el plan de ejecución, es decir indica que elementos de la
plataforma de despliegue de pruebas y en qué orden deben ejecutarse, verifica que estos
estén desplegados para continuar con el lanzamiento del sistema bajo prueba y la ejecución
de los casos de prueba. Adicionalmente contiene las instrucciones necesarias para integrar
todos los elementos del entorno de la prueba que intervienen en la ejecución de un caso de
prueba.
Elemento de plataforma de despliegue.
Representa aquellos elementos necesarios para desplegar la prueba. Incluye a las librerías de
herramientas de pruebas y los elementos de la plataforma despliegue del sistema bajo
prueba, los cuales por ejemplo para una prueba de aceptación equivaldrían al entorno real
donde se desplegaría el sistema.
“AUDITORIA”. PÁGINA 6
UNIVERSIDAD PRIVADA TELESUP
Plan de ejecución.
Indica los pasos de ejecución 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 ejecución y los resultados
esperados, que se desarrollan con el objetivo de ejercitar un sistema. Especifica como los
elementos participantes en la prueba interactúan con el sistema para realizar el objetivo de
la prueba; es decir define las acciones que serán 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 probarán. Se
definen los siguientes niveles: unitario, componente, integración, interface y de sistema. Su
aplicación depende del grado de avance del ciclo de desarrollo. De acuerdo con la
metodología de desarrollo que se emplee y con la complejidad del sistema, se pueden definir
otros niveles tales como: alfa, beta o de aceptación entre otros.
Objetivo.
Consiste en un conjunto concreto de características del software que se evaluarán bajo
condiciones específicas, comparando el comportamiento real del sistema con el
comportamiento especificado por la documentación 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”. PÁGINA 7
UNIVERSIDAD PRIVADA TELESUP
Resultado de la prueba.
Corresponde a la salida generada por el sistema bajo prueba como consecuencia de la
ejecución 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 ejecución 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 ejecución de la prueba se presenta una
excepción ocasionada por algún componente del sistema de prueba (por ejemplo, una
división por cero, un error de sintaxis, ausencia de un elemento para continuar con la
ejecución).
Incidencia.
Se genera como resultado de la detección de un fallo en el sistema bajo prueba por la
ejecución de un caso de prueba. Está relacionada con un componente del sistema bajo
prueba.
Políticas de pruebas.
Expresan la filosofía de la organización, sus objetivos, las métricas claves de pruebas e
incluso políticas de aseguramiento de la calidad. A partir de ellas se controla la ejecución.
Estas pueden variar dependiendo del tipo de proyecto y del dominio de aplicación. Deben
definirse claramente sin ambigüedad y de ser posible deben expresarse de manera
cuantitativa.
“AUDITORIA”. PÁGINA 8
UNIVERSIDAD PRIVADA TELESUP
Manual de pruebas.
Define las actividades, procedimientos y tareas de pruebas independiente de cualquier
proyecto específico. Describe las actividades mínimas que deben cubrirse durante las
pruebas. Este debe incluir una definición de alto nivel de las fases del ciclo de prueba.
“AUDITORIA”. PÁGINA 9
UNIVERSIDAD PRIVADA TELESUP
Á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 más pequeñas del software, el componente o módulo de
software. Centran su actividad en verificar la funcionalidad y la estructura (lógica 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 básica 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 más
pequeña del software a probar, aislarlo del resto del código, 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 código para asegurar la conformidad con estándares
de la organización e identificar debilidades.
Pruebas de integración.
Comprenden verificaciones asociadas a grupos de componentes, generalmente reflejados en
la especificación de diseño 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 efectúan en el entorno del desarrollador.
Pruebas de sistema.
Son pruebas de integración 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 técnicas se cumplen. Se realizan en un entorno fuera del alcance del desarrollador.
Pruebas de aceptación.
“AUDITORIA”. PÁGINA 10
UNIVERSIDAD PRIVADA TELESUP
Los usuarios prueban el sistema o aplicación 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 iteración pueden usarse cualquiera
de las etapas. Por ejemplo en una primera iteración puede aplicarse una prueba de aceptación,
para establecer si el cliente está de acuerdo con el prototipo, sin aplicar pruebas unitarias.
“AUDITORIA”. PÁGINA 11
UNIVERSIDAD PRIVADA TELESUP
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 regresión:
En cada nueva versión se supone que se corrigen defectos y/o se añaden nuevas
funciones. En cualquier caso, una nueva versión exige una nueva ejecución de las pruebas.
Si éstas se han sistematizado en una fase anterior, ahora pueden volver a pasarse
automáticamente, simplemente para comprobar que las modificaciones no provocan
errores donde antes no los había. En la realización de las pruebas de regresión de
componentes críticos se aplicará las denominadas Bitácoras de casuísticas, 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
parámetros de gasto. Es útil saber cuánto tiempo le lleva al sistema procesar cuánta
memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un
canal de comunicaciones, etc.
Las principales actividades de las pruebas de desempeño son:
“AUDITORIA”. PÁGINA 12
UNIVERSIDAD PRIVADA TELESUP
Comparar el desempeño real del sistema respecto de los requerimientos de
desempeño.
Afinar el sistema para mejorar las mediciones de desempeño 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 número de usuarios concurrentes. Con
este tipo de pruebas se puede medir rendimiento real y límites potenciales del sistema,
podremos obtener el punto de quiebre en que la aplicación 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 están orientadas a identificar las vulnerabilidades de seguridad que
pueden tener las aplicaciones.
“AUDITORIA”. PÁGINA 13
UNIVERSIDAD PRIVADA TELESUP
Ciclo de Aplicación de Pruebas
Para resolver la complejidad de la ejecución de las pruebas de software, estas se tratan como un
proyecto relacionado con el proceso de desarrollo. En este sentido se divide su aplicación en fases,
conformando un ciclo de pruebas, se definen brevemente como:
Requisitos de las pruebas.
Se definen todos los recursos necesarios para la ejecución de las pruebas como: herramientas,
roles, tiempo, elementos del entorno (requisitos, especificaciones funcionales, modelos y
códigos del sistema a probar). Se expresa un Plan de Pruebas.
Diseño 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 diseño de las pruebas, específicamente
definiendo la estructura de la suite de pruebas.
Especificación de las pruebas.
Adiciona datos concretos al diseño de pruebas, sobre los casos de pruebas y las
especificaciones del procedimiento de pruebas. La finalidad es detallar las condiciones de
pruebas a la especificación del diseño y como ejecutar cada prueba incluyendo por ejemplo los
procedimientos de inicio y finalización, así como los pasos de prueba que deben seguirse.
Implementación de las pruebas.
Comprende la generación de las pruebas a partir de las especificaciones del modelo o del
sistema (código). Como resultado se obtendrán los artefactos del sistema bajo prueba tales
como la configuración de las pruebas y el contexto de las pruebas.
Validación 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
“AUDITORIA”. PÁGINA 14
UNIVERSIDAD PRIVADA TELESUP
conformidad interna, consiste en verificar que estén 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 semántica de las pruebas indicadas estén conformes.
Ejecución de las pruebas.
Comprende todos los pasos necesarios para ejecutar de forma manual o automática las
pruebas. La ejecución manual debe estar apoyada por herramientas guiadas por
procedimientos de pruebas. La ejecución automática necesita la generación de scripts de
pruebas junto con los ejecutores de pruebas. Adicionalmente se usa una plataforma de
pruebas para ejecutar y registrar el seguimiento automáticamente. Tanto las pruebas
manuales como las automáticas se analizan subsecuentemente.
Evaluación de las pruebas.
Esta actividad implica la comparación de los resultados esperados versus los obtenidos,
durante la ejecución de las pruebas. Estas respuestas incluyen salidas gráficas, cambios de
datos y de estados internos, informes generados y comunicación con el entorno.
La propuesta anterior de definición de las actividades de ciclo de pruebas, describe muy
brevemente éstas en función de las herramientas que pueden soportarla, orientadas hacia la
generación automática de pruebas a partir de modelos. Sin embargo no detalla las actividades que
forman parte de cada fase, ni como fluye la información entre ella, por lo tanto es difícil 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: planificación, diseño, ejecución y
revisión de los resultados.
Metodología de Testing
La metodología de Testing está soportada por herramientas, estándares internacionales de
modelos de procesos (CMMI), estándares de calidad (IEES, ISO), estándares de procesos de gestión
(PMBOK).
“AUDITORIA”. PÁGINA 15
UNIVERSIDAD PRIVADA TELESUP
La metodología 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 línea de negocio.
Está compuesta de :
Cinco fases: Inicio, Planificación, Ejecución, Seguimiento Control y Cierre del proyecto.
Cinco procesos: Análisis y Diseño de Testing, Preparación de Testing, Ejecución de Testing,
Evaluación 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.
Principios de la Prueba del Software
“AUDITORIA”. PÁGINA 16
UNIVERSIDAD PRIVADA TELESUP
Estos principios son importantes porque guiarán el accionar del profesional que prueba del
software. Ilene Burstein señala 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 intención de detectar defectos y de evaluar
su calidad. Esto supone separar las pruebas de la depuración 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 aún no
detectados. Partiendo de la hipótesis de la presencia de un 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 válidas einválidas. La robustez del
software se puede evaluar probando su funcionamiento con entradas inválidas.
Principio 6
“AUDITORIA”. PÁGINA 17
UNIVERSIDAD PRIVADA TELESUP
La probabilidad de que existan defectos adicionales en un componente de software es
directamente proporcional al número de defectos y adetectados en ese componente. Este
principio se basa en la evidencia empírica. Las razones pueden ser el nivel de complejidad o
algunos defectos de diseño.
Principio 7
Las pruebas deben ser conducidas por personas independientes a las que hicieron el desarrollo El
desarrollador está síquicamente preparado para que su obra funcione “bien”, de modo que le será
muy difícil 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. Además también serán muy útiles para las pruebas de regresión, es
decir, las que se realizarán cuando, por razones de evolución o mejora, el software tenga que ser
modificado.
“AUDITORIA”. PÁGINA 18
UNIVERSIDAD PRIVADA TELESUP
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 ejecución 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 específico”.
“(2) (IEEE Std 829-1983) Documentación que especifique los insumos, predijo resultados, y establecer un de las condiciones de ejecución de un elemento de prueba”.
Según Ron Patton (2001, p. 65),
"Los casos de prueba son las aportaciones específicas 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 más 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 debería producir a partir de las entradas de prueba. Esta especificación 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 También puede especificar las condiciones iniciales y resultantes para otros objetos que constituyen el IUT y su medio ambiente ".
“AUDITORIA”. PÁGINA 19
UNIVERSIDAD PRIVADA TELESUP
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 Solución se ha planteado los puntos a probar.
Alcance
El alcance de las pruebas está enmarcado dentro del alcance funcional considerado en la propuesta de solución que plantea las modificaciones de los sistemas para a cumplir según dicta la Resolución Ministerial N° 305-2005-MTC/05 del MTC (ANEXO 2), 767 localidades han sido designadas como Localidades de Preferente Interés Social (LPIS) y pasan a tener el mismo tratamiento en cuanto a Numeración y Régimen Tarifario (solo para llamadas entrantes) que las localidades rurales. Con lo que se identifica la planta total de teléfonos instalados en estas localidades, aquellas que actualmente no están catalogadas como rurales (secuencialmente o por etapas) aplicándoles las condiciones normativas dispuestas por OSIPTEL.
Identificar la planta total LPIS de teléfonos instalados. Cargar y adaptar al sistema con los nuevos catálogos proporcionados por ATIS AC. Creación de rangos Rurales en la serie 83. Ejecutar un cambio de número masivo de números a toda la planta LPIS, conservando el
perfil inicial del producto. Cobrar tarifa rural a todas las llamadas entrantes a los teléfonos LPIS, salvo aquellas
llamadas que se originen en otro LPIS u otro rural. Verificar la aplicación de las condiciones normativas dispuestas por OSIPTEL.
Requisitos Funcionales
Cód./Req DESCRIPCIÓN
Identificación del Planta LPIS
RF-12Se crearán rangos rurales diferenciados para los distintos tipos de líneas, estas son: Telefonía Básica LPIS, Telefonía Básica LPIS inalámbrica, Línea Social LPIS, Fonofácil LPIS, TPE LPIS, TPI LPIS, TPI Prepago LPIS.
RF-13 Se debe considerar el siguiente esquema de numeración rural, definido por el MTC:
“AUDITORIA”. PÁGINA 20
UNIVERSIDAD PRIVADA TELESUP
Provincias: CD-83-YXZZ CD: Código Departamental
Lima: 1-830-YXZZ
Donde :
Y = 0 para TUP Rural VSAT Gilat (X = 0 al 9)
Y = 1 para TUP Rural VSAT Gilat (X = 0 al 9)
Y = 2 para TUP Rural MAR (X = 0 al 9)
Y = 3 para TUP Rural MAR (X = 0 al 9)
Y = 4 para TUP Rural VSAT Dama
X = 0,2 para TUP Rural VSAT Dama
X = 3,4,5 para TUP LPIS
X = 9 para TUP Rural Inalámbrico
Y = 5 para TUP Rural Celular (X = 0 al 9)
Y = 6 para Rurales con T. Básica MAR (X = 0 al 9)
X = 0 al 8 para Básico Rural MAR (*)
X = 9 para Fono rural
Y = 7 para Rurales con T. Básica VSAT Gilat/Dama (X = 0 al 9)
Y = 8 para LPIS con T. Básica URA (X = 0 al 9)
X = 5 para T. Básica LPIS Inalámbrica
Z = del 0 al 9
Nota (*)
Dentro de este millar se encuentran incluidas centrales con tecnologías AXE, PRX y 5ESS.
Facturación
RF-21
La llamada saliente de un teléfono LPIS a urbanos (móviles, SLM, LDN, LDI), LPIS o Rurales, mantendrá la tarifas vigentes de la promoción o clasificación vigente contratada, es decir no se realizará ningún cambio en la tarificación de sus llamadas salientes.
En el caso de teléfonos TUP LPIS, no se realizan cambios en las comisiones.
A los teléfonos LPIS se les considerará que la llamada entrante será considerada como Rural, si es que la llamada tiene origen en una zona urbana.
RF-22Para los teléfonos LPIS se conservará el mismo formato de recibo y hoja de liquidación según se trate de un TUP o un básico (se mantienen todas las configuraciones de emisión y recibo)
RF-23 Configurar en sistemas las tarifas a utilizar para los rangos definidos.
Desde un LPIS: Llamadas a LPIS o rurales considerar las mismas tarifas entre abonados urbanos y TUP
“AUDITORIA”. PÁGINA 21
UNIVERSIDAD PRIVADA TELESUP
urbanos. (de acuerdo al plan tarifario)
Hacia un LPIS: Llamadas entrantes desde teléfonos Urbanos (considerar las tarifas rurales incluidas en el Anexo7).
RF-24Se tendrá que analizar el impacto en los sistemas (BMP, DAME, EMM4 y ATIS) y se tendrá que realizar las adecuaciones necesarias.
RF-25 Se crearán y configurarán nuevos códigos de cargos – Cofas, para su diferenciación.
RF-26Mantener Configuración de restricciones de acuerdo al tipo de plan de las líneas y bloqueos a excepción del bloqueo de la serie 81, 82 y 83 en las líneas cerradas LPIS (Limite de Consumo y prepagos)
RF-27 Es necesario que se registren los rangos diferenciados con su respectiva Tipología en la Tabla de SUPI.
RF-28
Las llamadas LPIS tendrán el mismo enrutamiento que las llamadas rurales (se registrarán en cada central cabecera al igual que las llamadas rurales)
Se deberán definir nuevos TTD para la diferenciación de tráficos; estos TTD se asociaran a las Cofas existentes de rurales.
La identificación de los LPIS se realizará a través de los rangos (tabla de rango del mediador EMM4), el requerimiento no involucra cambio en la parte comercial
RF- 29
Se deberá realizar una marca en las tablas RNGN, SUPI (Opción 7002), y/o TB_Cent donde se identifique una marca que permita diferenciar los Rurales LPIS.
Evaluar las tablas impactadas propias (EMM4 y sincronizadas ) ante la marca que permita identificar a las líneas rurales de LPIS en las validaciones de mediación.
RF-30
Adecuaciones en el EMM4
o Debe de considerarse la validación contra la serie de centrales (telf_a, telf_b)o Deberá de definir los formatos de salida a ATIS-FA. o Se deberán de definir los TT´s, cual es su valor. o Las pruebas deberán de abarcar todas las entradas y salidas de la plataforma, EMM4 hasta el
ingreso hacía ATIS-FA y deben de ser generadas para Lima y Provincias.
RF-31
Reporte de llamadas detallado y consolidado (10R y 13R) en las cuales se observe la aplicación correcta de la valorización. El detalle de llamadas deberá de contener la siguiente información básica
Teléfono origen. Teléfono destino. Cofa. TTD. Código de Patrón. Inicio de la llamada. Duración real. Duración facturada. Monto a facturar Horario (normal, reducido)
La generación de dichos reportes deberá ser de manera DIARIA.
RF-32 Se generaran pruebas de aplicación de valorización para Facturación.
Para la generación de las pruebas, éstas deberán de contener todos los tipos de tráficos y poder observar la correcta valorización de las llamadas, teniendo en cuenta las reglas establecidas por el Negocio, en ese sentido deberán de generarse reportes de pruebas, las pruebas que se ejecuten deben
“AUDITORIA”. PÁGINA 22
UNIVERSIDAD PRIVADA TELESUP
generar resultados en forma de reportes(archivos de resultados) siendo estos:
Reportes de llamadas salientes de LPIS (SLM, LDN, LDI) y TUP urbanos. Reportes con llamadas entrantes hacía LPIS.
RF-33 Las modificaciones sólo se dará en la valorización de tráficos y no se dará cambio alguno en las rentas a cobrar (las condiciones comerciales del producto se mantienen)
RF-34Las tarifas de un LPÏS hacia otras operadoras se mantienen igual.
RF-35 Para el caso de Facturación detallada Local, en caso se presentaran llamadas locales a teléfonos LPIS esta se mostrarán de manera similar como si llamara a un teléfono rural. A excepción si el llamante es un LPIS, en ese caso se mostrará como una llamada local.
RF-36
El recibo telefónico y las hojas de liquidación mantendrán su estructura actual utilizando las glosas existentes para el caso de llamadas salientes.En las Líneas Abiertas, LDC y Prepago LPIS las llamadas hacia la serie rural y LPIS se considerará como llamadas locales ó LDN según corresponda por lo que no se realizará ninguna modificación en el recibo.
Se incluye modelos de Recibos y Hoja de liquidación (Anexo 9)
Para el tráfico entrante a la planta LPIS:
Se van a mantener las glosas actuales de Telefonía Rural (Ver Anexo 11 Glosas Agrupadoras de los Servicios Rurales que aparecen en el recibo telefónico y en la hoja de liquidación).
No aplican los modelos de recibos para LDC y Prepago, puesto que el tráfico a la serie rural está restringido.
Se incluye modelos de Recibo Telefónico para Línea Abierta y el modelo de la Hoja de Liquidación (Anexo 10)
RF-37 Las llamadas a LPIS deberá de considerarse que se registren en los reportes de medios magnéticos como rurales, es decir no habrá cambio en dicho reporte.
RF-38 Se deben de realizar las respectivas configuraciones en el Daco Visual y generar pruebas con los reportes 14R1, 14R2 y SUNAT. Los siguientes reportes tienen su equivalente en el ATIS y deberán considerar estos.
RF-39
Se deberán considerar las siguientes configuraciones:
Configuraciones en DAME (ahora EMM4) Configuraciones en ATIS FA (Asociación de TTD). Configuraciones en ATIS IN Configuraciones en ATIS CO Configuraciones en ATIS AC Configuraciones en Cocofade Este tráfico debe de ser considerado en todos los reportes ATIS (Anómalos, Tráficos, Cierre)
Dichas pruebas deben de ser generadas antes de su implementación.
RF-40Se deben de generar muestras de modelos de recibos conteniendo los diferentes tipos de llamadas, incluyendo las llamadas salientes a urbanos (móviles, SLM, LDN, LDI); del LPIS a rural y de LPIS a LPIS.En la Facturación Detallada Local verificar el prefijo del Tipo de Llamadas hacia un LPIS, que deberá ser el mismo que hacia un rural (TPR)
RF-41 Para las líneas LPIS, se mantendrán sus actuales COFAS salientes de acuerdo al tipo de producto. Para el caso de las llamadas entrantes a LPIS se utilizarán las COFAS existentes para las llamadas entrantes rurales
RF-42 El negocio TUP Rural canalizará los ingresos generados por las llamadas entrantes hacia un LPIS.
Reclamos
RF-49 Carga de Archivo de CNM LiquidadosEn el sistema Fénix se deberá cargar el archivo con la información del CNM liquidado (numero antiguo / numero nuevo, numero de inscripción y fecha de cambio)
RF-50 Realizado el cruce de información debe verificarse que el número ingresado corresponde al CNM se deberá emitir el mensaje correspondiente: “el numero ha sido cambiado por disposición del MTC RM Nro 305-2005-MTC/05”
“AUDITORIA”. PÁGINA 23
UNIVERSIDAD PRIVADA TELESUP
Personal a Participar en las Pruebas
Participantes y responsabilidad de los participantes
Modalidad De Ejecución 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 ejecución de pruebas por requerimiento es el siguiente:
Grupo: Trafico (Simulación de una Cíclica completa para Ciclo 28).Conformado por los siguientes requerimientos:
Tráfico:
Conformado por los siguientes requerimientos.
Orden Grupo
“AUDITORIA”. PÁGINA 24
PARTICIPANTE RESPONSABILIDADES
Enrique Ríos Sarazu Tester1
Ricardo Torres Ríos Tester2
Donny Bustamante Tester3
Pedro Laynes Tester4
Juan Villacorta Desarrollador de Configuraciones – ATIS IN
Pilar García Prieto Desarrollador de Configuraciones – ATIS FA
Fernando Gómez Santos Desarrollador de Configuraciones – Fénix
Víctor Gómez Santos Jefe de Proyecto por COMSA
Carlos Castro Narváez Jefe de Proyecto por Telefonica
UNIVERSIDAD PRIVADA TELESUP
1 Todos los nuevos tráficos deberán pasar por las anomalías definidas en ATIS.
2 Asegurar la inclusión de los nuevos tráficos en todos los reportes ATIS de tráficos (incluye descuentos).
3 Pruebas de visualización en el on-line del módulo de tráficos de ATIS-FA.
4 Los reportes mínimos y críticos necesarios ATIS para las pruebas de Tráfico son los siguientes:
5 Reportes ATIS TRAFICO: Adicional a los reportes mencionados, se deben de generar las muestras de Facturasfacturas y Reportesreportes 14R1, 14R2 y SUNAT.Sunat.
El detalle de la ejecución de pruebas por requerimiento es el siguiente:
Tráfico:
RF-1221
Se debe de verificar los rangos rurales diferenciados para los distintos tipos de líneas, estas son: Telefonía Básica LPIS, Telefonía Básica LPIS inalámbrica, Línea Social LPIS, Fonofácil LPIS, TPE LPIS, TPI LPIS, TPI Prepago LPIS.Se espera identificar los rangos rurales de la planta LPIS en las distintas líneas de teléfonos instalados.Probar que la llamadas salientes de un teléfono LPIS a urbanos (móviles, SLM, LDN, LDI), LPIS o Rurales, mantendrá la tarifas vigentes de la promoción o clasificación vigente contratada, es decir no se realizará ningún cambio en la tarificación de sus llamadas salientes.
En el caso de teléfonos TUP LPIS, no se realizan cambios en las comisiones.
A los teléfonos LPIS se les considerará que la llamada entrante será considerada como Rural, si es que la llamada tiene origen en una zona urbana.
RF-1326 Verificar el siguiente esquema de numeración rural, definido por el MTC:Provincias: CD-83-YXZZ (CD: Código Departamental) Lima: 1-830-YXZZDonde :Y = 0 para TUP Rural VSAT Gilat (X = 0 al 9)Y = 1 para TUP Rural VSAT Gilat (X = 0 al 9)Y = 2 para TUP Rural MAR (X = 0 al 9)Y = 3 para TUP Rural MAR (X = 0 al 9)Y = 4 para TUP Rural VSAT DamaX = 0,2 para TUP Rural VSAT DamaX = 3,4,5 para TUP LPISX = 9 para TUP Rural InalámbricoY = 5 para TUP Rural Celular (X = 0 al 9)Y = 6 para Rurales con T. Básica MAR (X = 0 al 9)X = 0 al 8 para Básico Rural MAR (*)X = 9 para Fono ruralY = 7 para Rurales con T. Básica VSAT Gilat/Dama (X = 0 al 9)Y = 8 para LPIS con T. Básica URA (X = 0 al 9)X = 5 para T. Básica LPIS InalámbricaZ = del 0 al 9Nota (*) Se encuentran incluidas centrales con tecnologías AXE, PRX y 5ESS.Se espera verificar la numeración rural que tomaran los números identificados por la planta LPIS.Verificar la configuración y restricciones de acuerdo al tipo de
“AUDITORIA”. PÁGINA 25
UNIVERSIDAD PRIVADA TELESUP
plan de las líneas y bloqueos a excepción del bloqueo de la serie 81, 82 y 83 en las líneas cerradas LPIS (Limite de Consumo y prepagos) se cumplan.
RF-21
Probar que la llamadas salientes de un teléfono LPIS a urbanos (móviles, SLM, LDN, LDI), LPIS o Rurales, mantendrá la tarifas vigentes de la promoción o clasificación vigente contratada, es decir no se realizará ningún cambio en la tarificación de sus llamadas salientes.Se espera que el tráfico de llamadas salientes de un teléfono LPIS hacia urbanos o rurales no presenten cambios en su tarificación es decir mantengan la promoción vigente contratada.
En el caso de teléfonos TUP LPIS, no se realizan cambios en las comisiones.Se espera que no existan cambios en las comisiones para los teléfonos TUP LPIS.
A los teléfonos LPIS se les considerará que la llamada entrante será considerada como Rural, si es que la llamada tiene origen en una zona urbana.Se espera que en zonas urbanas las llamadas entrantes para teléfonos LPIS sean consideradas como rurales.
RF-26
Verificar la configuración y restricciones de acuerdo al tipo de plan de las líneas y bloqueos a excepción del bloqueo de la serie 81, 82 y 83 en las líneas cerradas LPIS (Limite de Consumo y prepagos) se cumplan.
Se espera que las líneas mantengan sus configuraciones y restricciones de acuerdo al plan que corresponda.
RF-28
Verificar que las llamadas LPIS tendrán el mismo enrutamiento que las llamadas rurales (se registrarán en cada central cabecera al igual que las llamadas rurales).
Verificar los nuevos TTD para la diferenciación de tráficos; estos TTD deberán estar asociados a las Cofas existentes de rurales.
RF- 29
Verificar marca en las tablas RNGN, SUPI, y/o TB_Cent donde se identifique una marca que permita diferenciar los Rurales LPIS.
Se espera que las líneas rurales LPIS se diferencien de los otros a través de una marca en algún campo o indicador en las tablas: RNGN, SUPI, y/o TB_Cent.
RF-31
Validar Reportes de llamadas detallado y consolidado (10R y 13R) en las cuales se observe la aplicación correcta de la valorización. El detalle de llamadas deberá de contener la siguiente información básica
Teléfono origen. Teléfono destino. Cofa. TTD. Código de Patrón. Inicio de la llamada.
“AUDITORIA”. PÁGINA 26
UNIVERSIDAD PRIVADA TELESUP
Duración real. Duración facturada. Monto a facturar Horario (normal, reducido)
La generación de dichos reportes deberá ser de manera DIARIA.
Se espera en los reportes 10R y 13R la valorización correcta de acuerdo al detalle de la información indicada.
RF-32
Probar valorización para Facturación. Para la generación de las pruebas, éstas deberán de contener todos los tipos de tráficos y poder observar la correcta valorización de las llamadas, teniendo en cuenta las reglas establecidas por el Negocio.
Reportes de llamadas salientes de LPIS (SLM, LDN, LDI) y TUP urbanos.
Reportes con llamadas entrantes hacía LPIS.Se espera que en las pruebas contengan todos los tipos de tráficos y se visualice la valorización correcta del tráfico consumido.
RF-33
Validar que las modificaciones sólo se dará en la valorización de tráficos y no se dará cambio alguno en las rentas a cobrar (Verificar que las condiciones comerciales del producto se mantienen)Se espera que existan cambios sólo en la valorización de los tráficos más no en otros conceptos como la renta a cobrar.
RF-34 Verificar que las tarifas de un LPÏS hacia otras operadoras se mantienen igual.Se espera que no existan cambios en las tarifas del tráfico desde un LPIS hacia otras operadoras.
RF-35
Probar en la Facturación detallada Local, en caso se presentaran llamadas locales a teléfonos LPIS esta se deben de mostrar de manera similar como si llamara a un teléfono rural. A excepción si el llamante es un LPIS, en ese caso se mostrará como una llamada local.Se espera que las llamadas locales hacia un teléfono LPIS, estas deben de tener el mismo comportamiento de llamada rural.
RF-37Verificar que las llamadas a LPIS deberá de considerarse que se registren en los reportes de medios magnéticos como rurales, es decir no habrá cambio en dicho reporte.Se espera que no existan cambios en los reportes de medios magnéticos.
RF-43
Verificar que todos los nuevos tráficos deberán pasar por las anomalías definidas en ATIS. Asegurar la inclusión de los nuevos tráficos en todos los reportes ATIS de tráficos (incluye descuentos)Pruebas de visualización en el on-line del módulo de tráficos de ATIS-FA.Se espera que los nuevos tráficos deban de pasar por los procesos de anomalías de Atis.
RF-44Verificar los reportes ATIS para las pruebas de Tráfico: Reportes ATIS TRAFICO Adicional a los reportes mencionados, se deben de generar las muestras de facturas y reportes 14R1, 14R2 y Sunat.Se espera en las pruebas de tráfico las facturas y reportes 14R1 14R2 y Sunat.
“AUDITORIA”. PÁGINA 27
UNIVERSIDAD PRIVADA TELESUP
Facturación:
RF-25Verificar creación y configuración de nuevos códigos de Cargos – Cofas, para su diferenciación.
RF-36
Verificar el recibo telefónico y las hojas de liquidación mantengan su estructura actual utilizando las glosas existentes para el caso de llamadas salientes.Verificar que en las Líneas Abiertas, LDC y Prepago LPIS las llamadas hacia la serie rural y LPIS se considerará como llamadas locales ó LDN según corresponda por lo que no se realizará ninguna modificación en el recibo.
Para el tráfico entrante a la planta LPIS: Verificar el mantenimiento de glosas actuales de Telefonía Rural.
Nota: No aplican los modelos de recibos para LDC y Prepago, puesto que el tráfico a la serie rural está restringido.
RF-38 Se debe de Verificar los reportes 14R1, 14R2 y SUNAT, tienen su equivalente en el ATIS con las configuraciones realizadas en el Daco Visual.
RF-39
Validar las siguientes configuraciones:
Configuraciones en DAME (ahora EMM4) Configuraciones en ATIS FA (Asociación de TTD). Configuraciones en ATIS IN Configuraciones en ATIS CO Configuraciones en ATIS AC Configuraciones en Cocofade Este tráfico debe de ser considerado en todos los Reportes ATIS
(Anómalos, Tráficos, Cierre)
RF-40
Verificar recibos conteniendo los diferentes tipos de llamadas, incluyendo las llamadas salientes a urbanos (móviles, SLM, LDN, LDI); del LPIS a rural y de LPIS a LPIS.En la Facturación Detallada Local verificar el prefijo del Tipo de Llamadas hacia un LPIS, que deberá ser el mismo que hacia un rural (TPR)
RF-41 Verificar que los actuales COFAS salientes para las líneas LPIS, de acuerdo al tipo de producto. Para el caso de las llamadas entrantes a LPIS se utilizarán las COFAS existentes para las llamadas entrantes rurales
RF-42 Verificar que el negocio TUP Rural canalize los ingresos generados por las llamadas entrantes hacia un LPIS.
EMM4:
“AUDITORIA”. PÁGINA 28
UNIVERSIDAD PRIVADA TELESUP
RF-24Se tendrá que analizar el impacto en los sistemas (BMP, DAME, EMM4 y ATIS) y se tendrá que realizar las adecuaciones necesarias.
RF-30
Adecuaciones en el EMM4
Debe de considerarse la validación contra la serie de centrales (telf_a, telf_b)
Deberá de definir los formatos de salida a ATIS-FA.
Se deberán de definir los TT´s, cual es su valor.
Las pruebas deberán de abarcar todas las entradas y salidas de la plataforma, EMM4 hasta el ingreso hacía ATIS-FA y deben de ser generadas para Lima y Provincias.
RF-45
Probar en el Mediador:
Llamadas Locales salientes de LPIS a LIPS Llamadas Locales salientes de LPIS a LIPS (duración cero) Llamadas PQL salientes de LPIS a (duración cero) Llamadas PQL salientes de LPIS a LIPS. Llamadas PQL salientes de LPIS a LIPS duración cero) Llamadas LDN salientes de LPIS a LIPS. Llamadas LDN salientes de LPIS a LIPS (duración cero) Llamadas LDI salientes de LPIS a LIPS. Llamadas LDI salientes de LPIS a LIPS (duración cero) Llamadas Locales entrantes a LIPS. Llamadas PQL entrantes a LIPS. Llamadas LDN entrantes a LIPS. Llamadas LDI entrantes a LIPS. Llamadas Locales salientes de LPIS a TUP Urbanos. Llamadas PQL salientes de LPIS a TUP Urbanos Llamadas LDN salientes de LPIS a TUP Urbanos Llamadas LDI salientes de LPIS a TUP Urbanos Llamadas Locales salientes de LPIS a Básica (<> LIPS) Llamadas PQL salientes de LPIS a Básica (<> LIPS) Llamadas LDN salientes de LPIS a Básica (<> LIPS) Llamadas LDI salientes de LPIS a Básica (<> LIPS)
“AUDITORIA”. PÁGINA 29
UNIVERSIDAD PRIVADA TELESUP
Distribución y Emisión:
Conformado por los siguientes requerimientos.
Orden Grupo Cod./Req.
1 Asegurar la inclusión de los nuevos tráficos en todos los reportes ATIS de Emisión, Distribución, Cierre.
2 Muestras de facturas y Hoja de Liquidaciones en la que se observe los siguientes puntos:
Pruebas para la generación de facturas en líneas Abiertas, líneas Limite de Consumo que contengan todas las cofas a facturarse y en todas las casuísticas anteriores (Servicio Local, LdN y Tup, etc)
Claridad en las glosas (definidas por el usuario de facturación)
Correcto ordenamiento en la factura y la Hoja de Liquidación (definidas por el usuario de facturación MAS NO la posición en ATIS)
Las muestras deberán de tener todos los conceptos antiguos y nuevos a probar definidas en el IVDR.
Pruebas con los nuevos formatos en caso se modifiquen.
El detalle de la ejecución de pruebas por requerimiento es el siguiente:
Distribución y Emisión:
“AUDITORIA”. PÁGINA 30
UNIVERSIDAD PRIVADA TELESUP
RF-22Verificar que para los teléfonos LPIS se conservará el mismo formato de Recibo y Hoja de Liquidación según se trate de un TUP o un Básico (Verificar que se mantienen todas las configuraciones de emisión y recibo)
RF-47
Verificar la inclusión de los nuevos tráficos en todos los reportes ATIS de emisión, distribución, cierre se muestre en las facturas y Hoja de Liquidaciones en la que se observe los siguientes puntos:
Generación de facturas en líneas Abiertas, líneas Limite de Consumo que contengan todas las cofas a facturarse y en todas las casuísticas anteriores (Servicio Local, LdN y Tup, etc)
Claridad en las glosas. Correcto ordenamiento en la factura y la Hoja de Liquidación (definidas por el
usuario de facturación MAS NO la posición en ATIS) Las muestras deberán 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:
Conformado por los siguientes requerimientos.
Orden Grupo Cod./Req.
1 1 teléfono LPIS que quiere hacer un reclamo de facturación
2 1 teléfono NO LPIS que quiere hacer un reclamo de facturación
3 1 teléfono LPIS que quiere hacer un reclamo de calidad
4 1 teléfono NO LPIS que quiere hacer un reclamo de calidad
5 1 teléfono LPIS que quiere hacer una inspección
6 1 teléfono NO LPIS que quiere hacer una inspección
7 1 teléfono LPIS que quiere hacer una queja
“AUDITORIA”. PÁGINA 31
UNIVERSIDAD PRIVADA TELESUP
8 1 teléfono NO LPIS que quiere hacer una queja
9 1 teléfono LPIS que quiere hacer un ajuste
10 1 teléfono NO LPIS que quiere hacer un ajuste
11 1 teléfono LPIS para generar reclamo, este teléfono debe una factura que posea COFAS NUEVAS CONFIGURADOS por LPIS.
El detalle de la ejecución de pruebas por requerimiento es el siguiente:
Fenix:
RF-49 Verificar en el sistema Fénix se deberá cargar el archivo con la información del CNM liquidado (numero antiguo / numero nuevo, numero de inscripción y fecha de cambio)
RF-50 Realizado el cruce de información debe verificarse que el número ingresado corresponde al CNM se deberá emitir el mensaje correspondiente: “el numero ha sido cambiado por disposición del MTC RM Nro 305-2005-MTC/05”
“AUDITORIA”. PÁGINA 32
UNIVERSIDAD PRIVADA TELESUP
Pruebas Testing – Online:
Conformado por los siguientes requerimientos:
Orden Grupo Cod./Req.
1 Usar el aplicativo FENIX sin cargar ningún teléfono en la tabla de CNM por LPIS
Pruebas Testing – Batch:
Conformado por los siguientes requerimientos:
Orden Grupo Cod./Req.
1 Carga batch de archivo con CNM por LPIS y visualización en FENIX
Consideraciones para la ejecución de pruebas por requerimiento es el siguiente:
1. Que exista el archivo de entrada con los teléfonos migrados por LPIS, en base a la estructura indicada.
2. Que exista los archivos con las COFFAS nuevas que serán cargados en FENIX.3. Que existan facturas en ATIS con las nuevas COFFAS para las pruebas en FENIX.4. Contar teléfonos migrados por LPIS
Calendario de Pruebas
Fecha Sistema Funciones a Probar
14/09/2012
Recepción de Entregable
14/09/2012 al
17/09/2012
ATIS Validaciones de las Configuraciones
“AUDITORIA”. PÁGINA 33
UNIVERSIDAD PRIVADA TELESUP
17/09/2012 al
03/10/2012 ATIS
Pruebas de Testing:
EMM4 - Trafico – Facturación – Distribución y Emisión - Fenix
Las pruebas se realizarán 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 diseñar y ejecutar un número
limitado de casos de prueba que permita encontrar el máximo número de defectos. La prueba
de software usualmente requiere utilizar una combinación de técnicas de caja negra y de caja
transparente para lograr un conjunto de casos de prueba consistente, combinación que
dependerá de las características del software y de las limitaciones del entorno.
Los casos de pruebas reflejan los requerimientos que serán verificados, esta verificación
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 diseño de los casos
de prueba, Actualmente, la gestión de pruebas de software es una de las tareas más
importantes en la industria del desarrollo de software y las tecnologías de la información, y
más aún si el objetivo es desarrollar productos de calidad. En esa gestión, la prueba es una de
las fases más importantes, y en ésta, lo que requiere más cuidado y dedicación es el diseño de
los casos de prueba, por lo que es necesario estudiar cómo diseñarlos y escribirlos mejor.
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 diseñado tiene gran posibilidad de llegar
“AUDITORIA”. PÁGINA 34
UNIVERSIDAD PRIVADA TELESUP
a resultados más fiables y eficientes, mejorar el rendimiento del sistema, y reducir los costos
en tres categorías:
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 más fiables y efectivas.
No hay una fórmula sencilla o exacta para la generación de "buenos" casos de prueba. El
ámbito de las pruebas es demasiado complejo para esto. Hay pruebas de que son buenos para
sus propósitos, para que produzca el tipo de información que se está buscando.
Muchos analista de pruebas, diseñan 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 técnicas, que
van evolucionando día a día.
“AUDITORIA”. PÁGINA 35
UNIVERSIDAD PRIVADA TELESUP
Referencias
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”. PÁGINA 36