trabajo final comprobacion de software
TRANSCRIPT
“Año de la Integración Nacional y el
Reconocimiento de Nuestra Diversidad”
COMPROBACION DE SOFTWARE
TRABAJO MONOGRAFICO GRUPAL
Casos de Pruebas
SEPTIMO CICLO
Semestre: 2012 - II
UNIVERSIDAD PRIVADA TELESUPFACULTAD DE INGENIERIA DE SISTEMAS e INFORMATICA ddd
ASIGNATURA:
COMPROBACION DE SOFTWARE
TRABAJO MONOGRAFICO:
" CASOS DE PRUEBAS”
EQUIPO DE TRABAJO:
BUSTAMANTE ALVAREZ, DONY JUNIOR
GOMEZ SANTOS, FERNANDO MARTIN
GOMEZ SANTOS, VICTOR BENJAMIN
LAYNES MORENO, PEDRO ROBERTO
VILLACORTA SANTAMATO, JUAN FRANCISCO
TUTOR: CARMONA ESPINOZA, JORGE LUIS
Lima, Diciembre del 2012
Contenido
1. Introducción:.................................................................................................4
2. Conceptos Preliminares...............................................................................6
3. Ámbito de Pruebas.....................................................................................13
4. Tipos de Pruebas.......................................................................................15
5. Ciclo de Aplicación de Pruebas..................................................................17
6. Metodología de Testing..............................................................................19
7. Principios de la Prueba del Software.........................................................20
8. Algunas definiciones de Casos de Pruebas...............................................22
9. Plan de Pruebas y Casos de Pruebas (Ejemplo).......................................23
Objetivos........................................................................................................23
Alcance..........................................................................................................23
Requisitos Funcionales..................................................................................23
Personal a Participar en las Pruebas.............................................................26
Modalidad De Ejecución De Casos De Prueba.............................................27
Calendario de Pruebas..................................................................................35
10. Conclusiones...........................................................................................36
11. Referencias.............................................................................................38
1. 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 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.
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 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
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 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.
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.
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.
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.
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.
3. Á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.
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.
4. 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:
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.
5. 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 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.
6. 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).
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.
7. Principios de la Prueba del Software
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
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.
8. 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 ".
9. 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:
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 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-27Es 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 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-40
Se 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”
Personal a Participar en las Pruebas
Participantes y responsabilidad de los participantes
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
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
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 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. 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-37
Verificar 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-44
Verificar 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.
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-41Verificar 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:
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)
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:
RF-22
Verificar 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
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-50Realizado 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”
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
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
10. 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 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.
11. 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