Ao de la Integracin Nacional y el Reconocimiento de Nuestra Diversidad

COMPROBACION DE SOFTWARE

TRABAJO MONOGRAFICO GRUPAL

Casos de Pruebas

SEPTIMO CICLO

Semestre: 2012 - II

UNIVERSIDAD PRIVADA TELESUP

FACULTAD 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. 2. 3. 4. 5. 6. 7. 8. 9.

Introduccin:................................................................................................ 4 Conceptos Preliminares .............................................................................. 6 mbito de Pruebas .................................................................................... 13 Tipos de Pruebas ...................................................................................... 15 Ciclo de Aplicacin de Pruebas ................................................................. 17 Metodologa de Testing ............................................................................. 19 Principios de la Prueba del Software ........................................................ 20 Algunas definiciones de Casos de Pruebas .............................................. 22 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 Ejecucin De Casos De Prueba ............................................ 27 Calendario de Pruebas ................................................................................. 35

10. 11.

Conclusiones .......................................................................................... 36 Referencias ............................................................................................ 38

1. Introduccin:

En el mbito de la ingeniera de Sistemas las actividades de pruebas son actividades que han tomado relevante importancias en la actualidad, estas actividades se realizan con el objetivo de detectar fallos y evaluar las caractersticas del software. Las pruebas regulan la ejecucin de los proyectos y garantizan la calidad del software desarrollado. Desde el modelo de desarrollo en cascada hasta la aparicin de las metodologas giles, las pruebas han pasado de ser una simple etapa en el proceso de desarrollo a constituirse en un conjunto de etapas que controlan la duracin del ciclo de vida, la calidad y la confiabilidad del software desarrollado. En este contexto los Casos de Pruebas o Test Case son un conjunto de condiciones o variables bajo las cules el analista determinar si el requisito de una aplicacin es parcial o completamente satisfactorio. Otra definicin puede ser, los Casos de Pruebas, son un conjunto de entradas junto con las condiciones de ejecucin y los resultados esperados, que se desarrollan con el objetivo de ejercitar un sistema. Especifica como los elementos participantes en la prueba interactan con el sistema para realizar el objetivo de la prueba; es decir define las acciones que sern ejecutadas por un componente de prueba. De lo que podemos desprender que los casos de pruebas son artefactos que se desarrollan con miras a describir el camino para llegar a minimizar los errores o bug en un sistema. En la actualidad el desarrollo de sistemas tiene una gran demanda y la actual ubicuidad del software en nuestra vidas, nos lleva a poner especial nfasis en las pruebas de software, por lo un mal funcionamiento del mismo puede ocasionar desde la molestia por un mensaje inapropiado, hasta la prdida de cuantiosas sumas de dinero o, peor an, de vidas humanas. Por ello, el software, a semejanza de cualquier artefacto tangible, debe ser sometido a

pruebas para evaluar si cumple adecuadamente con lo que se espera de l y hacer minimizar los posibles fallos. Aunque el desarrollador de software realiza pruebas del mismo, estas deben de realizarse por personal dedicado a esta actividad especfica se efectan de manera intuitiva e informal. Dada la creciente demanda de software de calidad, la prueba o testeo del software en una actividad que ha evolucionado con elu so de diversas tcnicas y herramientas que la alejan del arte y la acercan a la ingeniera. Segn la IEEE, probar el software es analizarlo para detectar diferencias entre las condiciones existentes y las requeridas, y para evaluar las caractersticas del mismo.

2. Conceptos Preliminares

Proyecto de prueba. Es el conjunto de actividades que involucra la fase de prueba de un proyecto de desarrollo. Este se realiza por un equipo, con un objetivo concreto, con una programacin establecida, en un entorno y que aplica unos procesos para obtener una salida.

Plan de prueba. Es un documento que describe el alcance, el enfoque, los recursos y la programacin de las actividades de pruebas previstas. En l se identifican las caractersticas que deben probarse, los elementos a probar, las tareas de prueba, los responsables de cada tarea, los riesgos y los planes de contingencia requeridos. Respecto del alcance deber indicar los niveles de prueba que deben aplicarse y las mtricas para determinar en qu momento se debe finalizar el proyecto.

Escenario de prueba. Este es un elemento clave para la organizacin de las pruebas; cuyo objetivo es identificar los principales componentes que intervienen durante su ejecucin. De la misma manera tambin permite crear diferentes escenarios a partir de la variacin y combinacin de sus componentes. En concreto permite la identificacin de: el sistema bajo prueba, los requisitos que se probarn, los datos de prueba que se usarn, el caso o los casos de prueba y los elementos de la plataforma de ejecucin de prueba que son necesarios para ejecutar la prueba. A partir de estos elementos se puede configurar un entorno de prueba y obtener informacin bsica para establecer la trazabilidad entre requisitos, datos de prueba, caso de prueba, sistema bajo prueba y resultados.

Entorno de prueba. Describe el entorno de hardware y software en el que las pruebas se llevarn a cabo, y cualquier otro software con el que interacta el software

bajo prueba durante su ejecucin bajo la prueba. Especifica la arquitectura de ejecucin para un escenario de prueba. Por lo tanto representa la infraestructura tcnica (libreras, repositorios, sistemas de integracin continua, herramientas de gestin y control de las pruebas, sistemas de gestin de incidencias, etc.) que soportan el despliegue de las pruebas.

Hito. Es un evento que marca la finalizacin de una actividad, la cual debe entregar como resultado un producto concreto. No tiene esfuerzo ni recursos asignados. Su definicin dentro del plan es clave para la aplicacin de los procesos de gestin, especficamente para los de ejecucin y control & seguimiento.

Producto. Es el resultado de la ejecucin de una actividad, de una fase o de un proyecto. Existen tres clases, salidas, productos de entrega y artefactos. Las salidas son resultados intangibles que no constituyen un activo en s mismas, pueden formar parte de la descripcin de un producto. Los productos de entrega son aquellos que forman parte del resultado para el cliente o para un participante del proceso. Los artefactos son productos consumidos, producidos o modificados por una tarea.

Recurso. Es un elemento que representa un insumo necesario para la ejecucin de un proyecto, de una actividad o de una tarea. Tiene como caracterstica que puede ser estimado, asignado, valorado y cuantificado. Entre los recursos ms comunes podemos mencionar personas, herramientas, espacio fsico, informacin, etc.

Tcnica de prueba. Especifica la estrategia a utilizar en las pruebas para seleccionar las entradas de los casos de prueba y analizar los resultados. Diferentes tcnicas revelan diferentes aspectos de la calidad de un sistema de

software. Existen dos categoras principales de tcnicas de prueba, las funcionales y las estructurales. En las funcionales el sistema bajo prueba se analiza como una caja negra, los casos de prueba se basan en comprobar los requisitos y/o las especificaciones de diseo. En las estructurales, el sistema bajo prueba se analiza como una caja blanca, los casos de prueba estn orientados a comprobar la implementacin del software (cdigo), su objetivo bsico es la estructura interna del software. Cada una de estas dos categoras tiene sub-categoras que describen con un mayor nivel de detalle las tcnicas a aplicar.

Especificacin. Este elemento se refiere a la especificacin de requisitos del sistema que ser sujeto de prueba. Es un documento que especifica los requisitos para un sistema o componente. Tpicamente se incluyen los requisitos funcionales, requisitos no funcionales (rendimiento, seguridad, usabilidad etc.), los requisitos de las interfaces, los requisitos de diseo y estndares de desarrollo. Dado que en algunos casos no se cuenta con una especificacin formal de requisitos y que solo se tiene acceso al cdigo a partir del cual se extrae la arquitectura, o simplemente se tiene la documentacin del diseo, a partir de la cual se generan los casos de prueba, se considera como parte de la especificacin de requisitos el diseo procedimental, de datos, arquitectnico y de interface. De la misma manera se incluye dentro de dicha especificacin aspectos contractuales acordados con el cliente como los acuerdos de nivel de servicio (SLA).

Datos de prueba. Se refiere a los valores, los tipos, las estructuras y los repositorios donde se alojan los datos que se usarn durante la prueba para ejercitar el sistema bajo prueba. Los datos pueden ser introducidos directamente en el momento de la ejecucin, con lo cual solo se tendra un registro de ellos; pueden estar incluidos en una estructura esttica de datos dentro del cdigo del caso de prueba; pueden seleccionarse desde una base de datos, o desde un pool de datos preparado para la prueba.

Batera de prueba. Este elemento agrupa un conjunto de casos de prueba con una caracterstica comn, por ejemplo los casos de prueba asociados a un mismo elemento del sistema bajo prueba o los casos de prueba relacionados con un nivel de prueba. Puede contener uno o ms casos de prueba. Es til para organizar los casos de prueba dentro de un proyecto.

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

Elemento de plataforma de despliegue. Representa aquellos elementos necesarios para desplegar la prueba. Incluye a las libreras de herramientas de pruebas y los elementos de la plataforma despliegue del sistema bajo prueba, los cuales por ejemplo para una prueba de aceptacin equivaldran al entorno real donde se desplegara el sistema.

Plan de ejecucin. Indica los pasos de ejecucin de la prueba, configura el entorno de pruebas, describe el orden en que deben desplegarse los elementos de la plataforma de despliegue, el sistema bajo prueba y los casos de prueba.

Caso de prueba. Es un conjunto de entradas junto con las condiciones de ejecucin y los resultados esperados, que se desarrollan con el objetivo de ejercitar un sistema. Especifica como los elementos participantes en la prueba interactan con el sistema para realizar el objetivo de la prueba; es decir define las acciones que sern ejecutadas por un componente de prueba.

Sistema bajo prueba. Se refiere al sistema que est siendo probado. Se define como una parte, un elemento, un componente, un subsistema o el sistema completo que es ejercitado por un caso de prueba.

Nivel de prueba. Define el alcance de la prueba en cuanto a que elementos del sistema se probarn. Se definen los siguientes niveles: unitario, componente, integracin, interface y de sistema. Su aplicacin depende del grado de avance del ciclo de desarrollo. De acuerdo con la metodologa de desarrollo que se emplee y con la complejidad del sistema, se pueden definir otros niveles tales como: alfa, beta o de aceptacin entre otros.

Objetivo. Consiste en un conjunto concreto de caractersticas del software que se evaluarn bajo condiciones especficas, comparando el comportamiento real del sistema con el comportamiento especificado por la documentacin del sistema. En otras palabras, el objetivo de la prueba describe las cualidades del sistema que el caso de prueba debe probar. Por lo tanto un objetivo est siempre asociado a un caso de prueba.

Resultado de la prueba. Corresponde a la salida generada por el sistema bajo prueba como consecuencia de la ejecucin de un caso de prueba. Cada caso de prueba tiene asociado un resultado.

Informe de prueba. Es un documento que describe la conducta y los resultados de las pruebas realizadas en un sistema o un componente.

Veredicto. Define en concreto el resultado de la prueba, el cual puede ser: inconcluso, fallo, paso, error. Inconcluso cuando la ejecucin de la prueba no se pudo finalizar y por lo tanto no es posible determinar su resultado. Fallo se refiere a que el resultado de la prueba no concuerda con el resultado esperado. Error cuando durante la ejecucin de la prueba se presenta una excepcin ocasionada por algn componente del sistema de prueba (por ejemplo, una divisin por cero, un error de sintaxis, ausencia de un elemento para continuar con la ejecucin).

Incidencia. Se genera como resultado de la deteccin de un fallo en el sistema bajo prueba por la ejecucin de un caso de prueba. Est relacionada con un componente del sistema bajo prueba.

Polticas de pruebas.

Expresan la filosofa de la organizacin, sus objetivos, las mtricas claves de pruebas e incluso polticas de aseguramiento de la calidad. A partir de ellas se controla la ejecucin. Estas pueden variar dependiendo del tipo de proyecto y del dominio de aplicacin. Deben definirse claramente sin ambigedad y de ser posible deben expresarse de manera cuantitativa.

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

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 ms pequeas del software, el componente o mdulo de software. Centran su actividad en verificar la funcionalidad y la estructura (lgica interna) de cada elemento

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

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

Pruebas de integracin. Comprenden verificaciones asociadas a grupos de componentes,

generalmente reflejados en la especificacin de diseo del sistema y/o subsistemas, y culminan probando el sistema como conjunto. Se centran en verificar el ensamblaje correcto entre los distintos componentes, una vez que han sido probados unitariamente. Se efectan en el entorno del desarrollador.

Pruebas de sistema. Son pruebas de integracin del sistema completo. Permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y tcnicas se cumplen. Se realizan en un entorno fuera del alcance del desarrollador.

Pruebas de aceptacin. Los usuarios prueban el sistema o aplicacin para establecer si est listo para desplegarlo.

Las etapas de las pruebas mencionadas anteriormente, no son fases que se ejecutan rigurosamente en ese orden en un desarrollo iterativo. En una iteracin pueden usarse cualquiera de las etapas. Por ejemplo en una primera iteracin puede aplicarse una prueba de aceptacin, para establecer si el cliente est de acuerdo con el prototipo, sin aplicar pruebas unitarias.

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 regresin: En cada nueva versin se supone que se corrigen defectos y/o se aaden nuevas funciones. En cualquier caso, una nueva versin exige una nueva ejecucin de las pruebas. Si stas se han sistematizado en una fase anterior, ahora pueden volver a pasarse automticamente, simplemente para comprobar que las modificaciones no provocan errores donde antes no los haba. En la realizacin de las pruebas de regresin de componentes crticos se aplicar las denominadas Bitcoras de casusticas, con los cuales podremos asegurar que los flujos existentes no se vean afectados por el cambio.

Pruebas de performance: Para las aplicaciones de negocios es importante el tiempo de respuesta u otros parmetros de gasto. Es til saber cunto tiempo le lleva al

sistema procesar cunta memoria consume, o cunto espacio en disco utiliza, o cuntos datos transfiere por un canal de comunicaciones, etc. Las principales actividades de las pruebas de desempeo son: Comparar el desempeo real del sistema respecto de los requerimientos de desempeo. Afinar el sistema para mejorar las mediciones de desempeo y proyectar la capacidad futura de manejo de carga del sistema.

Pruebas de stress: Las pruebas de stress al igual que las de performance son muy importantes para las aplicaciones de negocios que cuenta con un elevado nmero de usuarios concurrentes. Con este tipo de pruebas se puede medir rendimiento real y lmites potenciales del sistema, podremos obtener el punto de quiebre en que la aplicacin puede tener problemas debido a la cantidad de usuarios, de manera que se puedan tomar las acciones correctivas antes de que el problema llegue a los entornos productivos.

Pruebas de seguridad: Este tipo de pruebas estn orientadas a identificar las vulnerabilidades de seguridad que pueden tener las aplicaciones.

5. Ciclo de Aplicacin de Pruebas

Para resolver la complejidad de la ejecucin de las pruebas de software, estas se tratan como un proyecto relacionado con el proceso de desarrollo. En este sentido se divide su aplicacin en fases, conformando un ciclo de pruebas, se definen brevemente como: Requisitos de las pruebas. Se definen todos los recursos necesarios para la ejecucin de las pruebas como: herramientas, roles, tiempo, elementos del entorno (requisitos, especificaciones funcionales, modelos y cdigos del sistema a probar). Se expresa un Plan de Pruebas.

Diseo de las pruebas. En esta fase se identifican los siguientes aspectos: tem de prueba, el enfoque de prueba detallado y los casos de pruebas de alto nivel asociados. Se seleccionan y derivan los casos de pruebas. El resultado es un documento que contiene el diseo de las pruebas, especficamente definiendo la estructura de la suite de pruebas.

Especificacin de las pruebas. Adiciona datos concretos al diseo de pruebas, sobre los casos de pruebas y las especificaciones del procedimiento de pruebas. La finalidad es detallar las condiciones de pruebas a la especificacin del diseo y como ejecutar cada prueba incluyendo por ejemplo los procedimientos de inicio y finalizacin, as como los pasos de prueba que deben seguirse.

Implementacin de las pruebas. Comprende la generacin de las pruebas a partir de las especificaciones del modelo o del sistema (cdigo). Como resultado se obtendrn los artefactos del sistema bajo prueba tales como la configuracin de las pruebas y el contexto de las pruebas.

Validacin de las pruebas. Esta actividad verifica la conformidad de las pruebas. Esto implica verificar la conformidad interna tanto con las especificaciones del sistema como con el modelo del sistema. La conformidad interna, consiste en verificar que estn definidos todos los casos de pruebas (suficientes), as como los datos de pruebas necesarios, que los procedimientos de prueba no presenten bloqueos, que la sintaxis y la semntica de las pruebas indicadas estn conformes.

Ejecucin de las pruebas. Comprende todos los pasos necesarios para ejecutar de forma manual o automtica las pruebas. La ejecucin manual debe estar apoyada por herramientas guiadas por procedimientos de pruebas. La ejecucin automtica necesita la generacin de scripts de pruebas junto con los ejecutores de pruebas. Adicionalmente se usa una plataforma de pruebas para ejecutar y registrar el seguimiento automticamente. Tanto las pruebas manuales como las automticas se analizan subsecuentemente.

Evaluacin de las pruebas. Esta actividad implica la comparacin de los resultados esperados versus los obtenidos, durante la ejecucin de las pruebas. Estas respuestas incluyen salidas grficas, cambios de datos y de estados internos, informes generados y comunicacin con el entorno.

La propuesta anterior de definicin de las actividades de ciclo de pruebas, describe muy brevemente stas en funcin de las herramientas que pueden soportarla, orientadas hacia la generacin automtica de pruebas a partir de modelos. Sin embargo no detalla las actividades que forman parte de cada fase, ni como fluye la informacin entre ella, por lo tanto es difcil de aplicar a cualquier dominio. Al respecto se proponen varios enfoques de ciclo de vida de prueba; que describen el proceso de prueba como un grupo de cuatro etapas: planificacin, diseo, ejecucin y revisin de los resultados.

6. Metodologa de Testing

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

Para cada una de ellas se describe claramente los objetivos, el perfil de las personas a participar, los requerimientos de entrada, las tareas a realizar y los resultados esperados.

7. Principios de la Prueba del Software

Estos principios son importantes porque guiarn el accionar del profesional que prueba del software. Ilene Burstein seala los siguientes, reformulando los establecidos originalmente por Glenford J. Myers: Principio 1 Probar es el proceso que consiste en ejecutar un componente de software utilizando un conjunto de casos de prueba previamente seleccionados con la intencin de detectar defectos y de evaluar su calidad. Esto supone separar las pruebas de la depuracin o debugging, actividad esta que se refiere a reparar el software eliminando los defectos. Principio 2 Un buen caso de prueba es aquel que tiene una alta probabilidad dehallar defectos an no detectados. Partiendo de la hiptesis de la presencia de un determinado tipo de defecto, se escogen las condiciones de entrada, se determinan losr esultados esperados y se realiza la prueba para determinar si el defecto est o no presente. Principio 3 Los resultados de cada prueba deben ser revisados meticulosamente. Si un defecto es pasado por alto o si se declara equivocadamente- la existencia de un defecto que no es tal, las consecuencias pueden ser muy costosas. Principio 4 Cada caso de prueba debe incluir el resultado esperado. El resultado esperado es lo que permitir determinar si existen o no defectos. Principio 5 Los casos de prueba deben incluir condiciones de entrada vlidas einvlidas. La robustez del software se puede evaluar probando su funcionamiento con entradas invlidas.

Principio 6 La probabilidad de que existan defectos adicionales en un componente de software es directamente proporcional al nmero de defectos y adetectados en ese componente. Este principio se basa en la evidencia emprica. Las razones pueden ser el nivel de complejidad o algunos defectos de diseo. Principio 7 Las pruebas deben ser conducidas por personas independientes a las que hicieron el desarrollo El desarrollador est squicamente preparado para que su obra funcione bien, de modo que le ser muy difcil asumir el principio 1: detectar defectos. Principio 8 Las pruebas deben ser repetibles y reutilizables. Las pruebas deben ser repetidas luego de haberse reparado el defecto. Adems tambin sern muy tiles para las pruebas de regresin, es decir, las que se realizarn cuando, por razones de evolucin o mejora, el software tenga que ser modificado.

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

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 Solucin se ha planteado los puntos a probar.

Alcance
El alcance de las pruebas est enmarcado dentro del alcance funcional considerado en la propuesta de solucin que plantea las modificaciones de los sistemas para a cumplir segn dicta la Resolucin Ministerial N 305-2005MTC/05 del MTC (ANEXO 2), 767 localidades han sido designadas como Localidades de Preferente Inters Social (LPIS) y pasan a tener el mismo tratamiento en cuanto a Numeracin y Rgimen Tarifario (solo para llamadas entrantes) que las localidades rurales. Con lo que se identifica la planta total de telfonos instalados en estas localidades, aquellas que actualmente no estn catalogadas como rurales (secuencialmente o por etapas) aplicndoles las condiciones normativas dispuestas por OSIPTEL.

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

Requisitos Funcionales
Cd./Req Identificacin del Planta LPIS Se crearn rangos rurales diferenciados para los distintos tipos de lneas, estas son: Telefona Bsica LPIS, Telefona Bsica LPIS inalmbrica, Lnea Social LPIS, Fonofcil LPIS, TPE LPIS, TPI LPIS, TPI Prepago LPIS. DESCRIPCIN

RF-12

Se debe considerar el siguiente esquema de numeracin rural, definido por el MTC: Provincias: Lima: Donde : Y=0 Y=1 Y=2 Y=3 Y=4 X = 0,2 para TUP Rural VSAT Gilat (X = 0 al 9) para TUP Rural VSAT Gilat (X = 0 al 9) para TUP Rural MAR (X = 0 al 9) para TUP Rural MAR (X = 0 al 9) para TUP Rural VSAT Dama para TUP Rural VSAT Dama CD-83-YXZZ CD: Cdigo Departamental

1-830-YXZZ

X = 3,4,5 para TUP LPIS RF-13 X=9 Y=5 Y=6 para TUP Rural Inalmbrico para TUP Rural Celular (X = 0 al 9) para Rurales con T. Bsica MAR (X = 0 al 9)

X = 0 al 8 para Bsico Rural MAR (*) X=9 Y=7 Y=8 X=5 para Fono rural para Rurales con T. Bsica VSAT Gilat/Dama (X = 0 al 9) para LPIS con T. Bsica URA (X = 0 al 9) para T. Bsica LPIS Inalmbrica

Z = del 0 al 9 Nota (*) Dentro de este millar se encuentran incluidas centrales con tecnologas AXE, PRX y 5ESS. Facturacin La llamada saliente de un telfono LPIS a urbanos (mviles, SLM, LDN, LDI), LPIS o Rurales, mantendr la tarifas vigentes de la promocin o clasificacin vigente contratada, es decir no se realizar ningn cambio en la tarificacin de sus llamadas salientes. RF-21 En el caso de telfonos TUP LPIS, no se realizan cambios en las comisiones. A los telfonos LPIS se les considerar que la llamada entrante ser considerada como Rural, si es que la llamada tiene origen en una zona urbana. Para los telfonos LPIS se conservar el mismo formato de recibo y hoja de liquidacin segn se trate de un TUP o un bsico (se mantienen todas las configuraciones de emisin y recibo) 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 telfonos Urbanos (considerar las tarifas rurales incluidas en el Anexo7).

RF-22

RF-23

RF-24 RF-25

Se tendr que analizar el impacto en los sistemas (BMP, DAME, EMM4 y ATIS) y se tendr que realizar las adecuaciones necesarias. Se crearn y configurarn nuevos cdigos de cargos Cofas, para su diferenciacin. Mantener Configuracin de restricciones de acuerdo al tipo de plan de las lneas y bloqueos a excepcin del bloqueo de la serie 81, 82 y 83 en las lneas cerradas LPIS (Limite de Consumo y prepagos) Es necesario que se registren los rangos diferenciados con su respectiva Tipologa en la Tabla de SUPI. Las llamadas LPIS tendrn el mismo enrutamiento que las llamadas rurales (se registrarn en cada central cabecera al igual que las llamadas rurales)

RF-26

RF-27

RF-28

Se debern definir nuevos TTD para la diferenciacin de trficos; estos TTD se asociaran a las Cofas existentes de rurales. La identificacin de los LPIS se realizar a travs de los rangos (tabla de rango del mediador EMM4), el requerimiento no involucra cambio en la parte comercial Se deber realizar una marca en las tablas RNGN, SUPI (Opcin 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 lneas rurales de LPIS en las validaciones de mediacin. Adecuaciones en el EMM4

RF- 29

RF-30

o o o o

Debe de considerarse la validacin contra la serie de centrales (telf_a, telf_b) Deber de definir los formatos de salida a ATIS-FA. Se debern de definir los TTs, cual es su valor. Las pruebas debern de abarcar todas las entradas y salidas de la plataforma, EMM4 hasta el ingreso haca ATIS-FA y deben de ser generadas para Lima y Provincias. Reporte de llamadas detallado y consolidado (10R y 13R) en las cuales se observe la aplicacin correcta de la valorizacin. El detalle de llamadas deber de contener la siguiente informacin bsica Telfono origen. Telfono destino. Cofa. TTD. Cdigo de Patrn. Inicio de la llamada. Duracin real. Duracin facturada. Monto a facturar Horario (normal, reducido) La generacin de dichos reportes deber ser de manera DIARIA. Se generaran pruebas de aplicacin de valorizacin para Facturacin. Para la generacin de las pruebas, stas debern de contener todos los tipos de trficos y poder observar la correcta valorizacin de las llamadas, teniendo en cuenta las reglas establecidas por el Negocio, en ese sentido debern 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 haca LPIS. Las modificaciones slo se dar en la valorizacin de trficos y no se dar cambio alguno en las rentas a cobrar (las condiciones comerciales del producto se mantienen) Las tarifas de un LPS hacia otras operadoras se mantienen igual. Para el caso de Facturacin detallada Local, en caso se presentaran llamadas locales a telfonos LPIS esta se mostrarn de manera similar como si llamara a un telfono rural. A excepcin si el llamante es un LPIS, en ese caso se mostrar como una llamada local.

RF-31

RF-32

RF-33 RF-34 RF-35

El recibo telefnico y las hojas de liquidacin mantendrn su estructura actual utilizando las glosas existentes para el caso de llamadas salientes. En las Lneas Abiertas, LDC y Prepago LPIS las llamadas hacia la serie rural y LPIS se considerar como llamadas locales LDN segn corresponda por lo que no se realizar ninguna modificacin en el recibo. Se incluye modelos de Recibos y Hoja de liquidacin (Anexo 9) RF-36 Para el trfico entrante a la planta LPIS: Se van a mantener las glosas actuales de Telefona Rural (Ver Anexo 11 Glosas Agrupadoras de los Servicios Rurales que aparecen en el recibo telefnico y en la hoja de liquidacin). No aplican los modelos de recibos para LDC y Prepago, puesto que el trfico a la serie rural est restringido. Se incluye modelos de Recibo Telefnico para Lnea Abierta y el modelo de la Hoja de Liquidacin (Anexo 10) Las llamadas a LPIS deber de considerarse que se registren en los reportes de medios magnticos como rurales, es decir no habr cambio en dicho reporte. 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 debern considerar estos. Se debern considerar las siguientes configuraciones: Configuraciones en DAME (ahora EMM4) Configuraciones en ATIS FA (Asociacin de TTD). Configuraciones en ATIS IN Configuraciones en ATIS CO Configuraciones en ATIS AC Configuraciones en Cocofade Este trfico debe de ser considerado en todos los reportes ATIS (Anmalos, Trficos, Cierre) Dichas pruebas deben de ser generadas antes de su implementacin. Se deben de generar muestras de modelos de recibos conteniendo los diferentes tipos de llamadas, incluyendo las llamadas salientes a urbanos (mviles, SLM, LDN, LDI); del LPIS a rural y de LPIS a LPIS. En la Facturacin Detallada Local verificar el prefijo del Tipo de Llamadas hacia un LPIS, que deber ser el mismo que hacia un rural (TPR) Para las lneas LPIS, se mantendrn sus actuales COFAS salientes de acuerdo al tipo de producto. Para el caso de las llamadas entrantes a LPIS se utilizarn las COFAS existentes para las llamadas entrantes rurales El negocio TUP Rural canalizar los ingresos generados por las llamadas entrantes hacia un LPIS. Reclamos RF-49 Carga de Archivo de CNM Liquidados En el sistema Fnix se deber cargar el archivo con la informacin del CNM liquidado (numero antiguo / numero nuevo, numero de inscripcin y fecha de cambio) Realizado el cruce de informacin debe verificarse que el nmero ingresado corresponde al CNM se deber emitir el mensaje correspondiente: el numero ha sido cambiado por disposicin del MTC RM Nro 305-2005-MTC/05

RF-37 RF-38

RF-39

RF-40

RF-41 RF-42

RF-50

Personal a Participar en las Pruebas

Participantes y responsabilidad de los participantes
PARTICIPANTE Enrique Ros Sarazu Ricardo Torres Ros Tester1 Tester2 RESPONSABILIDADES

Donny Bustamante Pedro Laynes Juan Villacorta Pilar Garca Prieto Fernando Gmez Santos Vctor Gmez Santos Carlos Castro Narvez

Tester3 Tester4 Desarrollador de Configuraciones ATIS IN Desarrollador de Configuraciones ATIS FA Desarrollador de Configuraciones Fnix Jefe de Proyecto por COMSA Jefe de Proyecto por Telefonica

Modalidad De Ejecucin De Casos De Prueba OBJETIVO Registrar las incidencias, es decir los errores durante las pruebas, y las observaciones, es decir los ajustes o complementos al requerimiento o adicionales que el usuario solicite. El detalle de la ejecucin de pruebas por requerimiento es el siguiente: Grupo: Trafico (Simulacin de una Cclica completa para Ciclo 28). Conformado por los siguientes requerimientos:

Trfico: Conformado por los siguientes requerimientos.

Orden 1 2 3 4 5

Grupo
Todos los nuevos trficos debern pasar por las anomalas definidas en ATIS. Asegurar la inclusin de los nuevos trficos en todos los reportes ATIS de trficos (incluye descuentos). Pruebas de visualizacin en el on-line del mdulo de trficos de ATIS-FA. Los reportes mnimos y crticos necesarios ATIS para las pruebas de Trfico son los siguientes: Reportes ATIS TRAFICO: Adicional a los reportes mencionados, se deben de generar las muestras de Facturasfacturas y Reportesreportes 14R1, 14R2 y SUNAT.Sunat.

El detalle de la ejecucin de pruebas por requerimiento es el siguiente:

Trfico:
Se debe de verificar los rangos rurales diferenciados para los distintos tipos de lneas, estas son: Telefona Bsica LPIS, Telefona Bsica LPIS inalmbrica, Lnea Social LPIS, Fonofcil LPIS, TPE LPIS, TPI LPIS, TPI Prepago LPIS. Se espera identificar los rangos rurales de la planta LPIS en las distintas lneas de telfonos instalados.Probar que la llamadas salientes de un telfono LPIS a urbanos (mviles, SLM, LDN, LDI), LPIS o Rurales, mantendr la tarifas vigentes de la promocin o clasificacin vigente contratada, es decir no se realizar ningn cambio en la tarificacin de sus llamadas salientes. En el caso de telfonos TUP LPIS, no se realizan cambios en las comisiones. A los telfonos LPIS se les considerar que la llamada entrante ser considerada como Rural, si es que la llamada tiene origen en una zona urbana. Verificar el siguiente esquema de numeracin rural, definido por el MTC: Provincias: CD-83-YXZZ (CD: Cdigo Departamental) Lima: 1-830YXZZ 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 Inalmbrico Y=5 para TUP Rural Celular (X = 0 al 9) Y=6 para Rurales con T. Bsica MAR (X = 0 al 9) X = 0 al 8 para Bsico Rural MAR (*) X=9 para Fono rural Y=7 para Rurales con T. Bsica VSAT Gilat/Dama (X = 0 al 9) Y=8 para LPIS con T. Bsica URA (X = 0 al 9) X=5 para T. Bsica LPIS Inalmbrica Z = del 0 al 9

RF1221

RF1326

Nota (*) Se encuentran incluidas centrales con tecnologas AXE, PRX y 5ESS. Se espera verificar la numeracin rural que tomaran los nmeros identificados por la planta LPIS.Verificar la configuracin y restricciones de acuerdo al tipo de plan de las lneas y bloqueos a excepcin del bloqueo de la serie 81, 82 y 83 en las lneas cerradas LPIS (Limite de Consumo y prepagos) se cumplan.

 Probar que la llamadas salientes de un telfono LPIS a urbanos (mviles, SLM, LDN, LDI), LPIS o Rurales, mantendr la tarifas vigentes de la promocin o clasificacin vigente contratada, es decir no se realizar ningn cambio en la tarificacin de sus llamadas salientes. Se espera que el trfico de llamadas salientes de un telfono LPIS hacia urbanos o rurales no presenten cambios en su tarificacin es decir mantengan la promocin vigente contratada. RF-21 En el caso de telfonos TUP LPIS, no se realizan cambios en las comisiones. Se espera que no existan cambios en las comisiones para los telfonos TUP LPIS. A los telfonos LPIS se les considerar que la llamada entrante ser considerada como Rural, si es que la llamada tiene origen en una zona urbana. Se espera que en zonas urbanas las llamadas entrantes para telfonos LPIS sean consideradas como rurales. Verificar la configuracin y restricciones de acuerdo al tipo de plan de las lneas y bloqueos a excepcin del bloqueo de la serie 81, 82 y 83 en las lneas cerradas LPIS (Limite de Consumo y prepagos) se cumplan. Se espera que las lneas mantengan sus restricciones de acuerdo al plan que corresponda. configuraciones y

RF-26

RF-28

Verificar que las llamadas LPIS tendrn el mismo enrutamiento que las llamadas rurales (se registrarn en cada central cabecera al igual que las llamadas rurales). Verificar los nuevos TTD para la diferenciacin de trficos; estos TTD debern estar asociados a las Cofas existentes de rurales. Verificar marca en las tablas RNGN, SUPI, y/o TB_Cent donde se identifique una marca que permita diferenciar los Rurales LPIS.

RF- 29

Se espera que las lneas rurales LPIS se diferencien de los otros a travs de una marca en algn campo o indicador en las tablas: RNGN, SUPI, y/o TB_Cent.

Validar Reportes de llamadas detallado y consolidado (10R y 13R) en las cuales se observe la aplicacin correcta de la valorizacin. El detalle de llamadas deber de contener la siguiente informacin bsica Telfono origen. Telfono destino. Cofa. TTD. Cdigo de Patrn. Inicio de la llamada. Duracin real. Duracin facturada. Monto a facturar Horario (normal, reducido) La generacin de dichos reportes deber ser de manera DIARIA. Se espera en los reportes 10R y 13R la valorizacin correcta de acuerdo al detalle de la informacin indicada. Probar valorizacin para Facturacin. Para la generacin de las pruebas, stas debern de contener todos los tipos de trficos y poder observar la correcta valorizacin de las llamadas, teniendo en cuenta las reglas establecidas por el Negocio. RF-32 Reportes de llamadas salientes de LPIS (SLM, LDN, LDI) y TUP urbanos. Reportes con llamadas entrantes haca LPIS. Se espera que en las pruebas contengan todos los tipos de trficos y se visualice la valorizacin correcta del trfico consumido. Validar que las modificaciones slo se dar en la valorizacin de trficos 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 slo en la valorizacin de los trficos ms no en otros conceptos como la renta a cobrar. Verificar que las tarifas de un LPS hacia otras operadoras se mantienen igual. Se espera que no existan cambios en las tarifas del trfico desde un LPIS hacia otras operadoras. Probar en la Facturacin detallada Local, en caso se presentaran llamadas locales a telfonos LPIS esta se deben de mostrar de manera similar como si llamara a un telfono rural. A excepcin si el llamante es un LPIS, en ese caso se mostrar como una llamada local. Se espera que las llamadas locales hacia un telfono LPIS, estas deben de tener el mismo comportamiento de llamada rural. Verificar que las llamadas a LPIS deber de considerarse que se registren en los reportes de medios magnticos como rurales, es decir no habr cambio en dicho reporte. Se espera que no existan cambios en los reportes de medios magnticos. Verificar que todos los nuevos trficos debern pasar por las anomalas definidas en ATIS. Asegurar la inclusin de los nuevos trficos en todos los reportes ATIS de trficos (incluye descuentos) Pruebas de visualizacin en el on-line del mdulo de trficos de ATIS-FA. Se espera que los nuevos trficos deban de pasar por los procesos de anomalas de Atis.

RF-31

RF-33

RF-34

RF-35

RF-37

RF-43

RF-44

Verificar los reportes ATIS para las pruebas de Trfico: 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 trfico las facturas y reportes 14R1 14R2 y Sunat.

Facturacin:
RF-25 Verificar creacin y configuracin de nuevos cdigos de Cargos Cofas, para su diferenciacin.

RF-36

Verificar el recibo telefnico y las hojas de liquidacin mantengan su estructura actual utilizando las glosas existentes para el caso de llamadas salientes. Verificar que en las Lneas Abiertas, LDC y Prepago LPIS las llamadas hacia la serie rural y LPIS se considerar como llamadas locales LDN segn corresponda por lo que no se realizar ninguna modificacin en el recibo. Para el trfico entrante a la planta LPIS: Verificar el mantenimiento de glosas actuales de Telefona Rural. Nota: No aplican los modelos de recibos para LDC y Prepago, puesto que el trfico a la serie rural est restringido.

RF-38

Se debe de Verificar los reportes 14R1, 14R2 y SUNAT, tienen su equivalente en el ATIS con las configuraciones realizadas en el Daco Visual. Validar las siguientes configuraciones: Configuraciones en DAME (ahora EMM4) Configuraciones en ATIS FA (Asociacin de TTD). Configuraciones en ATIS IN Configuraciones en ATIS CO Configuraciones en ATIS AC Configuraciones en Cocofade Este trfico debe de ser considerado en todos los Reportes ATIS (Anmalos, Trficos, Cierre)

RF-39

RF-40

Verificar recibos conteniendo los diferentes tipos de llamadas, incluyendo las llamadas salientes a urbanos (mviles, SLM, LDN, LDI); del LPIS a rural y de LPIS a LPIS. En la Facturacin Detallada Local verificar el prefijo del Tipo de Llamadas hacia un LPIS, que deber ser el mismo que hacia un rural (TPR)

RF-41

RF-42

Verificar que los actuales COFAS salientes para las lneas LPIS, de acuerdo al tipo de producto. Para el caso de las llamadas entrantes a LPIS se utilizarn las COFAS existentes para las llamadas entrantes rurales Verificar que el negocio TUP Rural canalize los ingresos generados por las llamadas entrantes hacia un LPIS.

EMM4:
RF-24 Se tendr que analizar el impacto en los sistemas (BMP, DAME, EMM4 y ATIS) y se tendr que realizar las adecuaciones necesarias. Adecuaciones en el EMM4 Debe de considerarse la validacin contra la serie de centrales (telf_a, telf_b) RF-30 Deber de definir los formatos de salida a ATIS-FA. Se debern de definir los TTs, cual es su valor. Las pruebas debern de abarcar todas las entradas y salidas de la plataforma, EMM4 hasta el ingreso haca ATIS-FA y deben de ser generadas para Lima y Provincias. Probar en el Mediador:
Llamadas Locales salientes de LPIS a LIPS Llamadas Locales salientes de LPIS a LIPS (duracin cero) Llamadas PQL salientes de LPIS a (duracin cero) Llamadas PQL salientes de LPIS a LIPS. Llamadas PQL salientes de LPIS a LIPS duracin cero) Llamadas LDN salientes de LPIS a LIPS. Llamadas LDN salientes de LPIS a LIPS (duracin cero) Llamadas LDI salientes de LPIS a LIPS. Llamadas LDI salientes de LPIS a LIPS (duracin 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 Bsica (<> LIPS) Llamadas PQL salientes de LPIS a Bsica (<> LIPS) Llamadas LDN salientes de LPIS a Bsica (<> LIPS) Llamadas LDI salientes de LPIS a Bsica (<> LIPS)

RF-45

Distribucin y Emisin:

Conformado por los siguientes requerimientos.

Orden

Grupo

Cod./R eq.

Asegurar la inclusin de los nuevos trficos en todos los reportes ATIS de Emisin, Distribucin, Cierre. Muestras de facturas y Hoja de Liquidaciones en la que se observe los siguientes puntos: Pruebas para la generacin de facturas en lneas Abiertas, lneas Limite de Consumo que contengan todas las cofas a facturarse y en todas las casusticas anteriores (Servicio Local, LdN y Tup, etc) Claridad en las glosas (definidas por el usuario de facturacin) Correcto ordenamiento en la factura y la Hoja de Liquidacin (definidas por el usuario de facturacin MAS NO la posicin en ATIS) Las muestras debern de tener todos los conceptos antiguos y nuevos a probar definidas en el IVDR. Pruebas con los nuevos formatos en caso se modifiquen.

El detalle de la ejecucin de pruebas por requerimiento es el siguiente:

Distribucin y Emisin:
Verificar que para los telfonos LPIS se conservar el mismo formato de Recibo y Hoja de Liquidacin segn se trate de un TUP o un Bsico (Verificar que se mantienen todas las configuraciones de emisin y recibo) Verificar la inclusin de los nuevos trficos en todos los reportes ATIS de emisin, distribucin, cierre se muestre en las facturas y Hoja de Liquidaciones en la que se observe los siguientes puntos:
Generacin de facturas en lneas Abiertas, lneas Limite de Consumo que contengan todas las cofas a facturarse y en todas las casusticas anteriores (Servicio Local, LdN y Tup, etc) Claridad en las glosas. Correcto ordenamiento en la factura y la Hoja de Liquidacin (definidas por el usuario de facturacin MAS NO la posicin en ATIS) Las muestras debern de tener todos los conceptos antiguos y nuevos a probar definidas en el IVDR. Pruebas con los nuevos formatos en caso se modifiquen.

RF-22

RF-47

Grupo : Fenix

Pruebas Usuario/Testing - Online:

Conformado por los siguientes requerimientos.

Orden 1 2 3 4 5 6 7 8 9 10 11

Grupo
1 telfono LPIS que quiere hacer un reclamo de facturacin 1 telfono NO LPIS que quiere hacer un reclamo de facturacin 1 telfono LPIS que quiere hacer un reclamo de calidad 1 telfono NO LPIS que quiere hacer un reclamo de calidad 1 telfono LPIS que quiere hacer una inspeccin 1 telfono NO LPIS que quiere hacer una inspeccin 1 telfono LPIS que quiere hacer una queja 1 telfono NO LPIS que quiere hacer una queja 1 telfono LPIS que quiere hacer un ajuste 1 telfono NO LPIS que quiere hacer un ajuste 1 telfono LPIS para generar reclamo, este telfono debe una factura que posea COFAS NUEVAS CONFIGURADOS por LPIS.

Cod./Req.

El detalle de la ejecucin de pruebas por requerimiento es el siguiente: Fenix:

RF-49 Verificar en el sistema Fnix se deber cargar el archivo con la informacin del CNM liquidado (numero antiguo / numero nuevo, numero de inscripcin y fecha de cambio) Realizado el cruce de informacin debe verificarse que el nmero ingresado corresponde al CNM se deber emitir el mensaje correspondiente: el numero ha sido cambiado por disposicin del MTC RM Nro 305-2005-MTC/05

RF-50

Pruebas Testing Online: Conformado por los siguientes requerimientos: Orden 1 Grupo Usar el aplicativo FENIX sin cargar ningn telfono en la tabla de CNM por LPIS Cod./Req.

Pruebas Testing Batch: Conformado por los siguientes requerimientos:

Orden 1

Grupo Carga batch de archivo con CNM por LPIS y visualizacin en FENIX

Cod./Req.

Consideraciones para la ejecucin de pruebas por requerimiento es el siguiente: 1. Que exista el archivo de entrada con los telfonos migrados por LPIS, en base a la estructura indicada. 2. Que exista los archivos con las COFFAS nuevas que sern cargados en FENIX. 3. Que existan facturas en ATIS con las nuevas COFFAS para las pruebas en FENIX. 4. Contar telfonos migrados por LPIS

Calendario de Pruebas
Fecha 14/09/2012 Sistema Funciones a Probar
Recepcin de Entregable

14/09/2012 al 17/09/2012

ATIS

Validaciones Configuraciones Pruebas de Testing:

de

las

17/09/2012 al 03/10/2012

ATIS

EMM4 - Trafico Facturacin Distribucin y Emisin - Fenix

Las pruebas se realizarn 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 disear y ejecutar un nmero limitado de casos de prueba que permita encontrar el mximo nmero de defectos. La prueba de software usualmente requiere utilizar una combinacin de tcnicas de caja negra y de caja transparente para lograr un conjunto de casos de prueba consistente, combinacin que depender de las caractersticas del software y de las limitaciones del entorno. Los casos de pruebas reflejan los requerimientos que sern verificados, esta verificacin deber ser realizada de diferentes maneras y por diferentes analistas de pruebas. Los casos de pruebas son la parte importante de un buen Plan de pruebas puesto que son la base para poder determinar si un software tiene o no errores. En la actualidad basados en las tendencias y la mejora continua en el desarrollo de software es necesario mejorar el diseo de los casos de prueba, Actualmente, la gestin de pruebas de software es una de las tareas ms importantes en la industria del desarrollo de software y las tecnologas de la informacin, y ms an si el objetivo es desarrollar productos de calidad. En esa gestin, la prueba es una de las fases ms importantes, y en sta, lo que requiere ms cuidado y dedicacin es el diseo de los casos de prueba, por lo que es necesario estudiar cmo disearlos y escribirlos mejor. Para desarrollar software de calidad y libre de errores, el plan de pruebas y los casos de prueba son muy importantes. Un caso de prueba bien diseado tiene gran posibilidad de llegar a resultados ms fiables y eficientes, mejorar el rendimiento del sistema, y reducir los costos en tres categoras: 1) En la productividad, menos tiempo para escribir y mantener los casos. 2) Capacidad de prueba, menos tiempo para ejecutarlos. 3) Programar la fiabilidad, estimaciones ms fiables y efectivas.

No hay una frmula sencilla o exacta para la generacin de "buenos" casos de prueba. El mbito de las pruebas es demasiado complejo para esto. Hay pruebas de que son buenos para sus propsitos, para que produzca el tipo de informacin que se est buscando. Muchos analista de pruebas, disean sus casos de pruebas en base o lo requerimientos, ellos son principalmente probadores de escenario o prp0badores de dominio. Para lograr la amplia gama de valor de nuestras pruebas, tenemos que utilizar una amplia gama de tcnicas, que van evolucionando da a da.

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