Trabajo Grupal comprobacion de software

UNIVERSIDAD PRIVADA TELESUP

FACULTAD DE INGENIERIA DE SISTEMASTema: “CASOS DE PRUEBAS”.

Elaborado por: Rivas Perez Pedro Steen

2015

Lima – Perú


DEDICATORIA

Dedico este trabajo a Dios

Por estar presente en cada

Momento de mi vida y

A mi esposa porque son el

Motivo de mí existir.


Tabla de contenido

1. Introducción:

2. Conceptos Preliminares

3. Ámbito de Pruebas

4. Tipos de Pruebas

5. Ciclo de Aplicación de Pruebas

6. Metodología de Testing

7. Principios de la Prueba del Software

8. Algunas definiciones de Casos de Pruebas

9. Plan de Pruebas y Casos de Pruebas (Ejemplo)

Objetivos

Alcance

Requisitos Funcionales

Personal a Participar en las Pruebas

Modalidad De Ejecución De Casos De Prueba

Calendario de Pruebas

10.Conclusiones

11.Referencias


Introducción:

En el ámbito de la ingeniería de Sistemas las actividades de pruebas son actividades que han

tomado relevante importancias en la actualidad, estas actividades se realizan con el objetivo de

detectar fallos y evaluar las características del software. Las pruebas regulan la ejecución de los

proyectos y garantizan la calidad del software desarrollado. Desde el modelo de desarrollo en

cascada hasta la aparición de las metodologías ágiles, las pruebas han pasado de ser una simple

etapa en el proceso de desarrollo a constituirse en un conjunto de etapas que controlan la

duración del ciclo de vida, la calidad y la confiabilidad del software desarrollado. En este contexto

los Casos de Pruebas o Test Case son un conjunto de condiciones o variables bajo las cuáles el

analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.

Otra definición puede ser, los Casos de Pruebas, son un conjunto de entradas junto con las

condiciones de ejecución y los resultados esperados, que se desarrollan con el objetivo de ejercitar

un sistema. Especifica como los elementos participantes en la prueba interactúan con el sistema

para realizar el objetivo de la prueba; es decir define las acciones que serán ejecutadas por un

componente de prueba.

De lo que podemos desprender que los casos de pruebas son artefactos que se desarrollan con

miras a describir el camino para llegar a minimizar los errores o bug en un sistema.

En la actualidad el desarrollo de sistemas tiene una gran demanda y la actual ubicuidad del

software en nuestra vidas, nos lleva a poner especial énfasis en las pruebas de software, por lo un

mal funcionamiento del mismo puede ocasionar desde la molestia por un mensaje inapropiado,

hasta la pérdida de cuantiosas sumas de dinero o, peor aún, de vidas humanas. Por ello, el

software, a semejanza de cualquier artefacto tangible, debe ser sometido a pruebas para evaluar

si cumple adecuadamente con lo que se espera de él y hacer minimizar los posibles fallos. Aunque

el desarrollador de software realiza pruebas del mismo, estas deben de realizarse por personal

“AUDITORIA”. PÁGINA 1


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.



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.



Á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.



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.



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.

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.

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.



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 ".



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-27 Es necesario que se registren los rangos diferenciados con su respectiva Tipología en la Tabla de SUPI.

RF-28

Las llamadas LPIS tendrán el mismo enrutamiento que las llamadas rurales (se registrarán en cada central cabecera al igual que las llamadas rurales)

Se deberán definir nuevos TTD para la diferenciación de tráficos; estos TTD se asociaran a las Cofas existentes de rurales.

La identificación de los LPIS se realizará a través de los rangos (tabla de rango del mediador EMM4), el requerimiento no involucra cambio en la parte comercial

RF- 29

Se deberá realizar una marca en las tablas RNGN, SUPI (Opción 7002), y/o TB_Cent donde se identifique una marca que permita diferenciar los Rurales LPIS.

Evaluar las tablas impactadas propias (EMM4 y sincronizadas ) ante la marca que permita identificar a las líneas rurales de LPIS en las validaciones de mediación.

RF-30

Adecuaciones en el EMM4

o Debe de considerarse la validación contra la serie de centrales (telf_a, telf_b)o Deberá de definir los formatos de salida a ATIS-FA. o Se deberán de definir los TT´s, cual es su valor. o Las pruebas deberán de abarcar todas las entradas y salidas de la plataforma, EMM4 hasta el

ingreso hacía ATIS-FA y deben de ser generadas para Lima y Provincias.

RF-31

Reporte de llamadas detallado y consolidado (10R y 13R) en las cuales se observe la aplicación correcta de la valorización. El detalle de llamadas deberá de contener la siguiente información básica

Teléfono origen. Teléfono destino. Cofa. TTD. Código de Patrón. Inicio de la llamada. Duración real. Duración facturada. Monto a facturar Horario (normal, reducido)

La generación de dichos reportes deberá ser de manera DIARIA.

RF-32 Se generaran pruebas de aplicación de valorización para Facturación.

Para la generación de las pruebas, éstas deberán de contener todos los tipos de tráficos y poder observar la correcta valorización de las llamadas, teniendo en cuenta las reglas establecidas por el Negocio, en ese sentido deberán de generarse reportes de pruebas, las pruebas que se ejecuten deben



generar resultados en forma de reportes(archivos de resultados) siendo estos:

Reportes de llamadas salientes de LPIS (SLM, LDN, LDI) y TUP urbanos. Reportes con llamadas entrantes hacía LPIS.

RF-33 Las modificaciones sólo se dará en la valorización de tráficos y no se dará cambio alguno en las rentas a cobrar (las condiciones comerciales del producto se mantienen)

RF-34Las tarifas de un LPÏS hacia otras operadoras se mantienen igual.

RF-35 Para el caso de Facturación detallada Local, en caso se presentaran llamadas locales a teléfonos LPIS esta se mostrarán de manera similar como si llamara a un teléfono rural. A excepción si el llamante es un LPIS, en ese caso se mostrará como una llamada local.

RF-36

El recibo telefónico y las hojas de liquidación mantendrán su estructura actual utilizando las glosas existentes para el caso de llamadas salientes.En las Líneas Abiertas, LDC y Prepago LPIS las llamadas hacia la serie rural y LPIS se considerará como llamadas locales ó LDN según corresponda por lo que no se realizará ninguna modificación en el recibo.

Se incluye modelos de Recibos y Hoja de liquidación (Anexo 9)

Para el tráfico entrante a la planta LPIS:

Se van a mantener las glosas actuales de Telefonía Rural (Ver Anexo 11 Glosas Agrupadoras de los Servicios Rurales que aparecen en el recibo telefónico y en la hoja de liquidación).

No aplican los modelos de recibos para LDC y Prepago, puesto que el tráfico a la serie rural está restringido.

Se incluye modelos de Recibo Telefónico para Línea Abierta y el modelo de la Hoja de Liquidación (Anexo 10)

RF-37 Las llamadas a LPIS deberá de considerarse que se registren en los reportes de medios magnéticos como rurales, es decir no habrá cambio en dicho reporte.

RF-38 Se deben de realizar las respectivas configuraciones en el Daco Visual y generar pruebas con los reportes 14R1, 14R2 y SUNAT. Los siguientes reportes tienen su equivalente en el ATIS y deberán considerar estos.

RF-39

Se deberán considerar las siguientes configuraciones:

Configuraciones en DAME (ahora EMM4) Configuraciones en ATIS FA (Asociación de TTD). Configuraciones en ATIS IN Configuraciones en ATIS CO Configuraciones en ATIS AC Configuraciones en Cocofade Este tráfico debe de ser considerado en todos los reportes ATIS (Anómalos, Tráficos, Cierre)

Dichas pruebas deben de ser generadas antes de su implementación.

RF-40Se deben de generar muestras de modelos de recibos conteniendo los diferentes tipos de llamadas, incluyendo las llamadas salientes a urbanos (móviles, SLM, LDN, LDI); del LPIS a rural y de LPIS a LPIS.En la Facturación Detallada Local verificar el prefijo del Tipo de Llamadas hacia un LPIS, que deberá ser el mismo que hacia un rural (TPR)

RF-41 Para las líneas LPIS, se mantendrán sus actuales COFAS salientes de acuerdo al tipo de producto. Para el caso de las llamadas entrantes a LPIS se utilizarán las COFAS existentes para las llamadas entrantes rurales

RF-42 El negocio TUP Rural canalizará los ingresos generados por las llamadas entrantes hacia un LPIS.

Reclamos

RF-49 Carga de Archivo de CNM LiquidadosEn el sistema Fénix se deberá cargar el archivo con la información del CNM liquidado (numero antiguo / numero nuevo, numero de inscripción y fecha de cambio)

RF-50 Realizado el cruce de información debe verificarse que el número ingresado corresponde al CNM se deberá emitir el mensaje correspondiente: “el numero ha sido cambiado por disposición del MTC RM Nro 305-2005-MTC/05”



Personal a Participar en las Pruebas

Participantes y responsabilidad de los participantes

Modalidad De Ejecución De Casos De Prueba

OBJETIVO

Registrar las incidencias, es decir los errores durante las pruebas, y las observaciones, es decir los ajustes o complementos al requerimiento o adicionales que el usuario solicite.

El detalle de la ejecución de pruebas por requerimiento es el siguiente:

Grupo: Trafico (Simulación de una Cíclica completa para Ciclo 28).Conformado por los siguientes requerimientos:

Tráfico:

Conformado por los siguientes requerimientos.

Orden Grupo


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


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.


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-37Verificar que las llamadas a LPIS deberá de considerarse que se registren en los reportes de medios magnéticos como rurales, es decir no habrá cambio en dicho reporte.Se espera que no existan cambios en los reportes de medios magnéticos.

RF-43

Verificar que todos los nuevos tráficos deberán pasar por las anomalías definidas en ATIS. Asegurar la inclusión de los nuevos tráficos en todos los reportes ATIS de tráficos (incluye descuentos)Pruebas de visualización en el on-line del módulo de tráficos de ATIS-FA.Se espera que los nuevos tráficos deban de pasar por los procesos de anomalías de Atis.

RF-44Verificar los reportes ATIS para las pruebas de Tráfico: Reportes ATIS TRAFICO Adicional a los reportes mencionados, se deben de generar las muestras de facturas y reportes 14R1, 14R2 y Sunat.Se espera en las pruebas de tráfico las facturas y reportes 14R1 14R2 y Sunat.



Facturación:

RF-25Verificar creación y configuración de nuevos códigos de Cargos – Cofas, para su diferenciación.

RF-36

Verificar el recibo telefónico y las hojas de liquidación mantengan su estructura actual utilizando las glosas existentes para el caso de llamadas salientes.Verificar que en las Líneas Abiertas, LDC y Prepago LPIS las llamadas hacia la serie rural y LPIS se considerará como llamadas locales ó LDN según corresponda por lo que no se realizará ninguna modificación en el recibo.

Para el tráfico entrante a la planta LPIS: Verificar el mantenimiento de glosas actuales de Telefonía Rural.

Nota: No aplican los modelos de recibos para LDC y Prepago, puesto que el tráfico a la serie rural está restringido.

RF-38 Se debe de Verificar los reportes 14R1, 14R2 y SUNAT, tienen su equivalente en el ATIS con las configuraciones realizadas en el Daco Visual.

RF-39

Validar las siguientes configuraciones:

Configuraciones en DAME (ahora EMM4) Configuraciones en ATIS FA (Asociación de TTD). Configuraciones en ATIS IN Configuraciones en ATIS CO Configuraciones en ATIS AC Configuraciones en Cocofade Este tráfico debe de ser considerado en todos los Reportes ATIS

(Anómalos, Tráficos, Cierre)

RF-40

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

RF-41 Verificar que los actuales COFAS salientes para las líneas LPIS, de acuerdo al tipo de producto. Para el caso de las llamadas entrantes a LPIS se utilizarán las COFAS existentes para las llamadas entrantes rurales

RF-42 Verificar que el negocio TUP Rural canalize los ingresos generados por las llamadas entrantes hacia un LPIS.

EMM4:



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:


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.


Distribución y Emisión:



RF-22Verificar que para los teléfonos LPIS se conservará el mismo formato de Recibo y Hoja de Liquidación según se trate de un TUP o un Básico (Verificar que se mantienen todas las configuraciones de emisión y recibo)

RF-47

Verificar la inclusión de los nuevos tráficos en todos los reportes ATIS de emisión, distribución, cierre se muestre en las facturas y Hoja de Liquidaciones en la que se observe los siguientes puntos:

Generación de facturas en líneas Abiertas, líneas Limite de Consumo que contengan todas las cofas a facturarse y en todas las casuísticas anteriores (Servicio Local, LdN y Tup, etc)

Claridad en las glosas. Correcto ordenamiento en la factura y la Hoja de Liquidación (definidas por el

usuario de facturación MAS NO la posición en ATIS) Las muestras deberán de tener todos los conceptos antiguos y nuevos a probar

definidas en el IVDR. Pruebas con los nuevos formatos en caso se modifiquen.

Grupo : Fenix

Pruebas Usuario/Testing - Online:



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.


Fenix:

RF-49 Verificar en el sistema Fénix se deberá cargar el archivo con la información del CNM liquidado (numero antiguo / numero nuevo, numero de inscripción y fecha de cambio)

RF-50 Realizado el cruce de información debe verificarse que el número ingresado corresponde al CNM se deberá emitir el mensaje correspondiente: “el numero ha sido cambiado por disposición del MTC RM Nro 305-2005-MTC/05”



Pruebas Testing – Online:

Conformado por los siguientes requerimientos:


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:


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

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.



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


http://www.kaner.com/pdfs/GoodTest.pdf

http://www.funlam.edu.co/lampsakos/n3/n3a3.pdf

http://es.wikipedia.org/wiki/Caso_de_prueba

Date post:	06-Feb-2016
Category:	Documents
Upload:	pedrosteenrivasperez
View:	21 times
Download:	0 times

Trabajo Grupal comprobacion de software

Documents