UNIVERSIDAD YACAMBÚ

ESPECIALIZACIÓN EN GERENCIA MENCIÓN REDES Y

TELECOMUNICACIONES

FASE II
ANALISIS Y DISEÑO DE SISTEMAS

TRABAJO 3

PLAN DE PRUEBAS

Participantes
Lavieri Maria Verónica
Castellanos A. Carmen

Noviembre, 2009
 INTRODUCCIÓN

El desarrollo de cualquier software, no es un tarea tan sencilla como muchas

personas piensan, va muchos mas allá que programar; involucra seguir una serie de pasos
utilizando una metodología, En la actualidad la evolución del software, al igual que la
Ingeniería del Software, ha realizado avances en las metodologías a seguir, tal como la
orientada a objeto; con el propósito de abarcar todas las etapas de producción y generar un
producto de alta calidad.

En este mismo orden de ideas, cabe destacar que unas de las actividades
fundamentales del desarrollo de un software e las Pruebas, dado que en esta etapa se
evalúa que se cumplan los requerimientos del software, para así entregar la aplicación al
cliente. Durante las pruebas se pretende encontrar posibles errores, así de esta forma tomar
las correcciones pertinentes. Por tanto para llevar acabo la revisión de un software para
entregar, es fundamental contar con un Plan de Pruebas. A continuación se describen
aspectos relevantes a considerar para llevar realizar todas las actividades que involucran las
pruebas de un sistema u aplicación.
 PLAN DE PRUEBAS

PRUEBAS DEL SISTEMA:

Las pruebas del sistema implican integrar dos o más componentes que implementan
funciones del sistema o características y a continuación se prueba este sistema integrado. En
un proceso de desarrollo iterativo, las pruebas del sistema se ocupan de probar un incremento
que va a ser entregado al cliente; en un proceso en cascada, las pruebas del sistema se
ocupan de probar el sistema completo.

Las pruebas del software son un elemento crítico para la garantía de calidad del
software y representa una revisión final de las especificaciones, del diseño y de la
codificación

OBJETIVOS DE LAS PRUEBAS

• La prueba es el proceso de ejecución de un programa con la intención de descubrir un

error.

• Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error
no descubierto hasta entonces.

• Una prueba tiene éxito si descubre un error no detectado hasta entonces.

PRINCIPIOS DE LAS PRUEBAS

• Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un

ingeniero del software deberá entender los principios básicos que guían las pruebas del
software.
• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del
cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se
entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos
que impiden al programa cumplir sus requisitos.

• Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de

las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La
definición detallada de los casos de prueba puede empezar tan pronto como el modelo de
diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas
antes de generar ningún código.

• El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla,

el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante
las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos
del programa. El problema, por supuesto, es aislar estos módulos sospechosos y
probarlos concienzudamente.

• Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las
primeras pruebas planeadas y ejecutadas se centran generalmente en módulos
individuales del programa. A medida que avanzan las pruebas, desplazan su punto de
mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en
el sistema entero.

• No son posibles las pruebas exhaustivas. El número de permutaciones de caminos

para incluso un programa de tamaño moderado es excepcionalmente grande. Por este
motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es
posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que
se han aplicado todas las condiciones en el diseño a nivel de componente.
 • Para ser más eficaces, las pruebas deberían ser realizadas por un equipo
independiente. Por «mas eficaces » queremos referirnos a pruebas con la más alta
probabilidad de encontrar errores (el objetivo principal de las pruebas).

PLAN DE PRUEBAS:

Es en una serie de pasos bien planificados que dan como resultado una correcta
construcción del software. El Plan proporciona un mapa que describe los pasos que hay que
llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y
cuánto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier plan de prueba
debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de
las pruebas y la agrupación y evaluación de los datos resultantes.
Un Plan de prueba del software debe ser suficientemente flexible para promover la
creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes
sistemas basados en software. Al mismo tiempo, la estrategia debe ser suficientemente
rígida para promover un seguimiento razonable de la planificación y la gestión a medida que
progresa el proyecto.

Para la mayoría de los sistemas complejos, existen dos fases distintas de pruebas del
sistema:

1. Pruebas de integración, en las que el equipo de pruebas tiene acceso al código fuente
del sistema. Cuando se descubre un problema, el equipo de integración intenta encontrar la
fuente del problema e identificar los componentes que tienen que ser depurados. Las pruebas
de integración se ocupan principalmente de encontrar defectos en el sistema.
2. Pruebas de entregas, en las que se prueba una versión del sistema que podría ser en-
tregada a los usuarios. Aquí, el equipo de pruebas se ocupa de validar que el sistema
satisface sus requerimientos y con asegurar que el sistema es confiable. Las pruebas de
entregas son normalmente pruebas de «caja negra» en las que el equipo de pruebas se ocupa
simplemente de demostrar si el sistema funciona o no correctamente. Los problemas son
comunicados al equipo de desarrollo cuyo trabajo es depurar el programa. Cuando los
clientes se implican en las pruebas de entregas, éstas a menudo se denominan pruebas de
aceptación. Si la entrega es lo suficientemente buena, el cliente puede entonces aceptarla
para su uso.

Fundamentalmente, se puede pensar en las pruebas de integración como las pruebas de

sistemas incompletos compuestos por grupos de componentes del sistema. Las pruebas de
entregas consisten en probar la entrega del sistema que se pretende proporcionar a los
clientes. Naturalmente, éstas se solapan, en especial cuando se utiliza desarrollo incremental
y el sistema para entregar está incompleto. Generalmente, la prioridad en las pruebas de
integración es descubrir defectos en el sistema, y la prioridad en las pruebas del sistema es
validar que el sistema satisface sus requerimientos. Sin embargo, en la práctica, hay una parte
de prueba de validación y una parte de prueba de defectos durante ambos procesos.

PRUEBAS DE INTEGRACIÓN

El proceso de la integración del sistema implica construir éste a partir de sus componentes y
probar el sistema resultante para encontrar problemas que pueden surgir debido a la
integración de los componentes. Los componentes que se integran pueden ser componentes
comerciales, componentes reutilizables que han sido adaptados a un sistema particular, o
componentes nuevos desarrollados. Para muchos sistemas grandes, es probable que se usen
los tres tipos de componentes. Las pruebas de integración comprueban que estos
componentes realmente funcionan juntos, son llamados correctamente y transfieren los datos
correctos en el tiempo preciso a través de sus interfaces.

La integración del sistema implica identificar grupos de componentes que proporcionan alguna
funcionalidad del sistema e integrar éstos añadiendo código para hacer que funcionen
conjuntamente. Algunas veces, primero se desarrolla el esqueleto del sistema en su totalidad,
y se le añaden los componentes. Esto se denomina integración descendente. De forma
alternativa, pueden integrarse primero los componentes de infraestructura que proporcionan
servicios comunes, tales como el acceso a bases de datos y redes, y a continuación pueden
añadirse los componentes funcionales. Esta es la integración ascendente. En la práctica, para
muchos sistemas, la estrategia de integración es una mezcla de ambas, añadiendo en
incrementos componentes de infraestructura y componentes funcionales. En ambas
aproximaciones de integración, normalmente tiene que desarrollarse código adicional para
simular otros componentes y permitir que el sistema se ejecute.

La principal dificultad que surge durante las pruebas de integración es la localización de los
errores. Existen interacciones complejas entre los componentes del sistema, y cuando se
descubre una salida anómala, puede resultar difícil identificar dónde ha ocurrido el error.
Para hacer más fácil la localización de errores, siempre debería utilizarse una aproximación
incremental para la integración y pruebas del sistema. Inicialmente, debería integrarse una
configuración del sistema mínima y probar este sistema.

Cuando se planifica la integración, tiene que decidirse el orden de integración de los com-
ponentes.

PRUEBAS DE ENTREGAS

Las pruebas de entregas son el proceso de probar una entrega del sistema que será distribui-
da a los clientes. El principal objetivo de este proceso es incrementar la confianza del
suministrador en que el sistema satisface sus requerimientos. Si es así, éste puede entregarse
como un producto o ser entregado al cliente. Para demostrar que el sistema satisface sus
requerimientos, tiene que mostrarse que éste entrega la funcionalidad especificada,
rendimiento y confiabilidad, y que no falla durante su uso normal.

Las pruebas de entregas son normalmente un proceso de pruebas de caja negra en las que
las pruebas se derivan a partir de la especificación del sistema. El sistema se trata como una
caja negra cuyo comportamiento sólo puede ser determinado estudiando sus entradas y sus sa-
lidas relacionadas. Otro nombre para esto es pruebas funcionales, debido a que al probador
sólo le interesa la funcionalidad y no la implementación del software.
La siguiente figura ilustra el modelo de un sistema que se admite en las pruebas de caja
negra. El probador presenta las entradas al componente o al sistema y examina las
correspondientes salidas. Si las salidas no son las esperadas (es decir, si las salidas
pertenecen al conjunto Se), entonces la prueba ha detectado un problema con el software.

Entradas que
provocan
comportamiento
anómalo

Salidas que
revelan las
presencias de
defectos

Cuando se prueban las entregas del sistema, debería intentarse «romper» el software eli-
giendo casos de prueba que pertenecen al conjunto Ee, Es decir, el objetivo debería ser
seleccionar entradas que tienen una alta probabilidad de generar fallos de ejecución del
sistema (salidas del conjunto Se). Se utiliza la experiencia previa de cuáles son las pruebas de
defectos que probablemente tendrán éxito y las guías de pruebas ayudarán a elegir la
adecuada.

PRUEBAS DE RENDIMIENTO

Una vez que un sistema se ha integrado completamente, es posible probar las propiedades
emergentes del sistema) tales como rendimiento y fiabilidad. Las pruebas de rendimiento
tienen que diseñarse para asegurar que el sistema pueda procesar su carga esperada. Esto
normalmente implica planificar una serie de pruebas en las que la carga se va incrementando
regularmente hasta que el rendimiento del sistema se hace inaceptable.
Como sucede con otros tipos de pruebas, las pruebas de rendimiento se ocupan tanto de
demostrar que el sistema satisface sus requerimientos como de descubrir problemas y defec-
tos en el sistema. Para probar si los requerimientos de rendimiento son alcanzados, usted tie-
ne que construir un perfil operacional. Un perfil operacional es un conjunto de pruebas que
reflejan la combinación real de trabajo que debería ser manejada por el sistema. Por lo tanto,
si el 90% de las transacciones en un sistema son de tipo A, un 5% de tipo B y el resto de tipos
C, D y E, entonces usted tiene que diseñar el perfil operacional para que la amplia mayoría de
las pruebas sean de tipo A. En caso contrario, no se tendrá un test preciso del rendimiento
operacional del sistema. Por supuesto, esta aproximación no es necesariamente la mejor
aproximación para las pruebas de defectos. Tal y como se explica más adelante, la
experiencia ha demostrado que una forma efectiva de descubrir defectos es diseñar pruebas
alrededor de los límites del sistema. Las pruebas de rendimiento implican estresar el sistema
(de ahí el nombre de pruebas de estrés) realizando demandas que están fuera de los límites
del diseño del software.

Por ejemplo, un sistema de procesamiento de transacciones puede diseñarse para procesar

hasta 300 transacciones por segundo; un sistema operativo puede diseñarse para gestionar
hasta 1.000 terminales distintas. Las pruebas de estrés van realizando pruebas acercándose
a la máxima carga del diseño del sistema hasta que el sistema falla. Este tipo de pruebas
tienen dos funciones:

1. Prueba el comportamiento de fallo de ejecución del sistema. Pueden aparecer circuns-

tancias a través de una combinación no esperada de eventos en donde la carga sobre el
sistema supere la máxima carga anticipada. En estas circunstancias, es importante que un fallo
de ejecución del sistema no provoque la corrupción de los datos o pérdidas inesperadas de
servicios de los usuarios. Las pruebas de estrés verifican que las sobrecargas en el sistema
provocan «fallos ligeros» en lugar de colapsarlo bajo su carga.
2. Sobrecargan el sistema y pueden provocar que se manifiesten defectos que normalmente
no serían descubiertos. Aunque se puede argumentar que estos defectos es improbable que
causen fallos de funcionamiento en un uso normal, puede haber combinaciones inusuales de
circunstancias normales que las pruebas de estrés pueden reproducir.
Las pruebas de estrés son particularmente relevantes para los sistemas distribuidos basados
en una red de procesadores. Estos sistemas exhiben a menudo una degradación grave
cuando son sobrecargados. La red se satura con datos de coordinación que los diferentes pro-
cesos deben intercambiar, de forma que los procesos son cada vez más lentos a medida que
esperan los datos requeridos de otros procesos

PRUEBAS DE COMPONENTES

Las pruebas de componentes (a menudo denominadas pruebas de unidad) son el proceso de

probar los componentes individuales en el sistema. Éste es un proceso de pruebas de defec-
tos, por lo que su objetivo es encontrar defectos en estos componentes. Tal y como se indicó
en la introducción, para la mayoría de los sistemas, los de sarroll adores de componentes son
los responsables de las pruebas de componentes.
Existen diferentes tipos de componentes que pueden probarse en esta etapa:

1. Funciones individuales o métodos dentro de un objeto.

2. Clases de objetos que tienen varios atributos y métodos.
3. Componentes compuestos formados por diferentes objetos o funciones. Estos com-
ponentes compuestos tienen una interfaz definida que se utiliza para acceder a su fun-
cionalidad.

Las funciones o métodos individuales son el tipo más simple de componente y sus pruebas
son un conjunto de llamadas a estas rutinas con diferentes parámetros de entrada. Pueden
utilizarse las aproximaciones para diseñar los casos de prueba, descritos en la sección si-
guiente, y para diseñar las pruebas de las funciones o métodos.
Cuando se están probando clases de objetos, deberían diseñar las pruebas para proporcio-
nar cobertura para todas las características del objeto. Por lo tanto, las pruebas de clases de
objetos deberían incluir:

1. Las pruebas aisladas de todas las operaciones asociadas con el objeto.

2. La asignación y consulta de todos los atributos asociados con el objeto.
3. Ejecutar el objeto en todos sus posibles estados. Esto significa que deben simularse todos
los eventos que provocan un cambio de estado en el objeto.

PRUEBAS DE INTERFACES

Muchos componentes en un sistema no son simples funciones u objetos, sino que son
componentes compuestos formados por varios objetos que interactúan. Las pruebas de estos
componentes se ocupan principalmente de probar que la interfaz del componente se comporta
de acuerdo con su especificación.

Las pruebas de interfaces son particularmente importantes para el desarrollo orientado a

objetos y basado en componentes. Los objetos y componentes se definen por sus interfaces y
pueden ser reutilizados en combinación con otros componentes en sistemas diferentes. Los
errores de interfaz en el componente compuesto no pueden detectarse probando los objetos
individuales o componentes. Los errores en el componente compuesto pueden surgir debido
a interacciones entre sus partes.
Existen diferentes tipos de interfaces entre los componentes del programa y, consecuente-
mente, distintos tipos de errores de interfaces que pueden producirse:

1. Interfaces de parámetros. Son interfaces en las que los datos, o algunas veces refe-
rencias a funciones, se pasan de un componente a otro en forma de parámetros.
2. Interfaces de memoria compartida. Son interfaces en las que un bloque de memoria se
comparte entre los componentes. Los datos se colocan en la memoria por un sub-
sistema y son recuperados desde aquí por otros subsistemas.
3. Interfaces procedurales. Son interfaces en las que un componente encapsula un conjunto
de procedimientos que pueden ser llamados por otros componentes. Los objetos y los
componentes reutilizables tienen esta forma de interfaz.
4. Interfaces de paso de mensajes. Son interfaces en las que un componente solicita un
servicio de otro componente mediante el paso de un mensaje. Un mensaje de retorno
incluye los resultados de la ejecución del servicio. Algunos sistemas orientados a objetos
tienen esta forma de interfaz, así como los sistemas cliente-servidor.
 Existen diferentes tipos de interfaces entre los componentes del programa y, consecuente-
mente, distintos tipos de errores de interfaces que pueden producirse:

5. Interfaces de parámetros. Son interfaces en las que los datos, o algunas veces refe-
rencias a funciones, se pasan de un componente a otro en forma de parámetros.
6. Interfaces de memoria compartida. Son interfaces en las que un bloque de memoria se
comparte entre los componentes. Los datos se colocan en la memoria por un sub-
sistema y son recuperados desde aquí por otros subsistemas.
7. Interfaces procedurales. Son interfaces en las que un componente encapsula un conjunto
de procedimientos que pueden ser llamados por otros componentes. Los objetos y los
componentes reutilizables tienen esta forma de interfaz.
8. Interfaces de paso de mensajes. Son interfaces en las que un componente solicita un
servicio de otro componente mediante el paso de un mensaje. Un mensaje de retorno
incluye los resultados de la ejecución del servicio. Algunos sistemas orientados a objetos
tienen esta forma de interfaz, así como los sistemas cliente-servidor.

Los errores de interfaces son una de las formas más comunes de error en sistemas com-
plejos (Lutz, 1993). Estos errores se clasifican en tres clases:

1. Mal uso de la interfaz. Un componente llama a otro componente y comete un error en la

utilización de su interfaz. Este tipo de errores es particularmente común con interfaces
de parámetros en donde los parámetros pueden ser de tipo erróneo, pueden pasarse
en el orden equivocado o puede pasarse un número erróneo de parámetros.
2. No comprensión de la interfaz. El componente que realiza la llamada no comprende la
especificación de la interfaz del componente al que llama, y hace suposiciones sobre el
comportamiento del componente invocado. El componente invocado no se comporta
como era de esperar y esto provoca un comportamiento inesperado en el componente
que hace la llamada. Por ejemplo, puede llamarse a una rutina de búsqueda binaria con
un vector no ordenado para realizar la búsqueda. En este caso, la búsqueda podría
fallar.
3. Errores temporales. Se producen en sistemas de tiempo real que utilizan una memoria
compartida o una interfaz de paso de mensajes. El productor de los datos y el con-
sumidor de dichos datos pueden operar a diferentes velocidades. A menos que se tenga
 un cuidado particular en el diseño de la interfaz, el consumidor puede acceder a
información no actualizada debido a que el productor de la información no ha actua-
lizado la información de la interfaz compartida.

Las pruebas para encontrar defectos en las interfaces son difíciles debido a que algunos de-
fectos de las interfaces sólo se pueden manifestar en condiciones inusuales. Por ejemplo, con-
sideremos un objeto que implementa una cola con una estructura de datos de longitud fija. Un
objeto que llama puede suponer que la cola está implementada como una estructura de datos
infinita y puede no comprobar el desbordamiento de la cola cuando se introduce un elemento.
Esta condición sólo se puede detectar durante las pruebas diseñando casos de prueba que
fuerzan un desbordamiento de la cola y hacen que dicho desbordamiento no dañe el compor-
tamiento del objeto de alguna forma detectable.

Guías generales para las pruebas de interfaz:

1. Examinar el código a probar y listar explícitamente cada llamada a un componente externo.

Diseñar un conjunto de pruebas en donde los valores de los parámetros para los componentes
externos están en los extremos de sus rangos. Es bastante probable que estos valores
extremos revelen inconsistencias en la interfaz.
2. En los lugares en los que se pasan punteros a través de una interfaz, siempre probar la
interfaz con parámetros de punteros nulos.
3. Cuando se llama a un componente a través de una interfaz procedural, diseñar pruebas
que hagan que el componente falle. Realizar suposiciones de fallos de ejecución erróneas es
una de las malas interpretaciones de especificación más comunes.
4. Utilizar las pruebas de estrés, tal y como se indicó en la sección previa, en los sistemas de
paso de mensajes. Diseñar pruebas que generen muchos más mensajes de los que
probablemente ocurran en la práctica. Los problemas temporales se detectan de esta
manera.
5. Cuando varios componentes interactúan a través de memoria compartida, diseñar
pruebas que varían el orden en el que se activan estos componentes. Estas pruebas pueden
revelar suposiciones implícitas hechas por el programador sobre el orden en el que los datos
compartidos son producidos y consumidos.
 ESTANDAR DE DOCUMENTACIÓN PARA EL PLAN DE PRUEBAS

IEEE 829-1983

El estándar IEEE 829-1983 describe los tipos de documentos que pueden producirse
durante el proceso de prueba.

El Plan de Pruebas

El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos,

calendario, responsables y manejo de riesgos de un proceso de pruebas. Puede haber un
plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación,
integración e integración). Un plan de pruebas incluye:

1. Identificador del plan.

Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance,

por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de
verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del contrato
asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para
el método iniciar de la clase Despachador). Como todo artefacto del desarrollo, está sujeto a
control de configuración, por lo que debe distinguirse adicionalmente la versión y fecha del
plan.

2. Alcance:

Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Items a probar:

Indica la configuración a probar y las condiciones mínimas que debe cumplir para
comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una configuración que
aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos,
puede que detectemos fallas graves demasiado tarde.

4. Estrategia

Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de

prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección
podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o
"Ejercicio de los caminos ciclomáticos válidos". En lo posible la estrategia debe precisar el
número mínimo de casos de prueba a diseñar, por ej. 100% de las fronteras, 60% de los
caminos ciclomáticos... La estrategia también explicita el grado de automatización que se
exigirá, tanto para la generación de casos de prueba como para su ejecución.

5. Categorización de la configuración

Explicita las condiciones bajo las cuales, el plan debe ser: Suspendido, Repetido, o
Culminado. En algunas circunstancias (las cuales deben ser explicadas) el proceso de
prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al
corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe
explicitarse a partir de qué punto, ya que puede ser necesario repetir algunas pruebas. Los
criterios de culminación pueden ser tan simples como aprobar el número mínimo de casos
de prueba diseñados o tan complejos como tomar en cuenta no sólo el número mínimo, sino
también el tiempo previsto para las pruebas y la tasa de detección de fallas.

Tangibles

Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej.
subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y
bitácora de pruebas.
Procedimientos especiales

Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como
cualquier habilidad especial que se requiere.

Recursos

Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las
características del hardware, el software de sistemas (p. ej. el sistema de operación),
cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación
específica del software a probar (p. ej. qué módulos se colocan en qué máquinas de una red
local) y la configuración del software de apoyo.

La sección incluye un estimado de los recursos humanos necesarios para el proceso.

También se indican cualquier requerimiento especial del proceso: actualización de licencias,
espacio de oficina, tiempo en la máquina de producción, seguridad.

Calendario

Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el
tiempo de las tareas a realizar.

Manejo de riesgos

Explicita los riesgos del plan, las acciones mitigantes y de contigencia.

Responsables

Especifica quién es el responsable de cada una de las tareas previstas en el plan.

La dirección del proceso de pruebas es parte de las responsabilidades del Coordinador de
Calidad, figura nueva a introducirse este trimestre en el proyecto Delta Pensum. En el
proceso adoptado para Delta Pensum, algunos de los renglones del Plan de Pruebas,
pueden detallarse en la descripción de las Suites de Prueba. Recuerde que es importante
evitar información redundante.

EJEMPLO DE UN PLAN DE PRUEBAS

GESTIÓN DE UN VIDEOCLUB

PLAN DE PRUEBAS

Versión 1.0

Revisión histórica

Fecha Versión Descripción Autor

27/02/2004 1.0 Versión inicial del Plan de pruebas LSI

Índice

1. Introducción

1.1. Propósito
1.2. Ámbito
1.3. Definiciones, acrónimos y abreviaturas

2. Requerimientos de las pruebas

3. Estrategia de prueba

3.1. Tipos de pruebas y técnicas

3.2. Herramientas

4. Recursos

4.1. Recursos hardware

4.2. Recursos software
4.3. Herramientas de soporte
4.4. Configuración de entornos de prueba
4.5. Recursos humanos

5. Actividades de prueba
6. Resultados de las pruebas

7. Tareas de la etapa de prueba

1. Introducción

1.1. Propósito

Este documento describe el Plan de pruebas para el sistema de Gestión de un videoclub. En

concreto define los siguientes objetivos específicos:
• Identifica los elementos que se van a probar.
• Describe la estrategia de pruebas que se va a seguir en el proceso de prueba.
• Identifica los recursos necesarios para llevar a cabo el proceso de prueba y estima los
esfuerzos que conlleva.
• Lista los resultados que se obtienen de las actividades de prueba.

1.2. Ámbito

Este Plan de Pruebas describe las pruebas de unidad, integración y del sistema que se
aplicarán al sistema software desarrollado.
El objetivo es probar todos los requisitos definidos en la Especificación de requisitos y en el
Modelo de casos de uso.

1.3. Definiciones, acrónimos, y abreviaturas

Ver glosario de términos.

2. Requerimientos de la pruebas

La lista que proporcionamos en esta sección identifica los elementos (casos de uso,
requisitos funcionales y requisitos no funcionales) que son objetivos de las pruebas. Es decir,
los elementos qué vamos a probar.

• Pruebas de integridad de la base de datos y de los datos:

o Verificar el acceso al sistema de Gestión de un videoclub.

o Verificar la recuperación correcta de las modificaciones realizadas en la base de
datos.
o Verificar accesos simultáneos de lectura de datos.

• Pruebas de funcionalidad:

o Verificar el caso de uso Alta de socio (CU1).

 o Verificar el caso de uso Modificación de socio (CU2).
o Verificar el caso de uso Baja de socio (CU3).
o Verificar el caso de uso Pago en metálico (CU4).
o Verificar el caso de uso Pago con tarjeta (CU5).
o Verificar el caso de uso Pago a cuenta (CU6).
o Verificar el caso de uso Consultar datos de socio (CU7).
o Verificar el caso de uso Listar películas alquiladas (CU8).
o Verificar el caso de uso Consultar cuenta de socio (CU9).
o Verificar el caso de uso Listar deudas (CU10).
o Verificar el caso de uso Deudas socio (CU11).
o Verificar el caso de uso Identificación socio (CU12).
o Verificar el caso de uso Alquiler vídeo (CU13).
o Verificar el caso de uso Devolver vídeo (CU14).
o Verificar el caso de uso Reservar vídeo (CU15).
o Verificar el caso de uso Comprar vídeo (CU16).
o Verificar el caso de uso Disponibilidad de películas (CU17).
o Verificar el caso de uso Alta de proveedores (CU18).
o Verificar el caso de uso Baja de proveedores (CU19).
o Verificar el caso de uso Modificación de proveedores (CU20).
o Verificar el caso de uso Consulta de proveedores (CU21).
o Verificar el caso de uso Realizar pedido (CU22).
o Verificar el caso de uso Alta de película (CU23).
o Verificar el caso de uso Baja de película (CU24).
o Verificar el caso de uso Modificación de película (CU25).
o Verificar el caso de uso Consulta de película (CU26).
o Verificar el caso de uso Estado película (CU27).

Documento de Visión, sección 6.1: “Se deben comunicar avisos y señales con sonidos, por
ejemplo, para avisar de que no se puede alquilar una película reservada, ya que el
responsable del videoclub no mira continuamente la pantalla.”

Documento de Visión, sección 6.1: “Se usarán asistentes que guíen en los procesos de
petición de películas al proveedor y alquiler.”

Documento de Visión, sección 6.2: “Para prever caídas del sistema se harán copias de
seguridad.”

Documento de Visión, sección 6.2: “Se utilizará durante algún tiempo el sistema manual
actual con la aplicación propuesta, hasta que el sistema esté totalmente probado.”

• Pruebas de interfaz de usuario:

o Verificar que la navegación a través de un conjunto de pantallas es fácil.

o Navegar a través de todos los casos de uso, verificando que cada interfaz de
usuario se comprende fácilmente.
o Verificar todas las funciones de ayuda online.
 o Verificar que todas las interfaces de usuario siguen los estándares de GUI.

Documento de Visión, sección 6.1: “Debe proporcionarse ayuda en línea con instrucciones
paso a paso para guiar al empleado en las tareas que debe realizar.”

Documento de Visión, sección 6.7: “El sistema debe interactuar y recoger datos de los
proveedores vía Internet, conectándose a las páginas que éstos ofrecen.”

• Pruebas de desarrollo:

Documento de Visión, sección 6.3: “Se usarán dos terminales para poder alquilar y devolver,
mejorando así la eficiencia del videoclub y el uso de los recursos. “

Documento de Visión, sección 6.3: “Las peticiones a los proveedores se irán generando
automáticamente para acelerar el proceso de petición.”

Documento de Visión, sección 6.3: “El sistema proporcionará acceso rápido al catálogo de
películas de la base de datos, no tardando más de 10 segundos. Se calcula que el sistema
debe manejar un volumen de datos de 10.000 películas y 5.000 socios.”

3. Estrategia de prueba

En esta sección presentamos el enfoque que vamos a utilizar para probar el sistema
software. En la sección anterior hemos descrito qué elementos del sistema software vamos a
probar, y en esta sección se define cómo se realizaran las pruebas.

3.1. Tipos de pruebas y técnicas

3.1.1 Pruebas de integridad de la base de datos y de los datos.

Objetivos de la prueba Comprobar que los procedimientos y métodos de

acceso a la base de datos funcionan
correctamente.
Técnicas Invocar cada procedimiento o método de acceso
a la base de datos con datos válidos e inválidos.
Inspeccionar la base de datos para asegurar que
los datos son los previstos, todos los eventos de
la base de datos ocurren adecuadamente, o
revisar los valores devueltos para asegurar que
la recuperación de datos es correcta.
Criterios de finalización Todos los procedimientos y métodos de acceso
funcionan como se diseñaron y sin ningún error
en los datos.
Consideraciones Los procesos se deberían invocar manualmente.
Se debería usar bases de datos de tamaño
 pequeño o mínimo (limitado según el número de
registros) para incrementar la visibilidad de
cualquier evento no aceptable.
Las pruebas pueden necesitar un entorno de
desarrollo DBMS para recuperar o modificar
datos directamente de la base de datos.

3.1.2 Pruebas de funcionalidad.

Las pruebas de funcionalidad se deberían centrar en cualquier requisito que pueda ser
trazado directamente de los casos de uso y reglas de negocio. El objetivo de estas pruebas
es verificar la aceptación, procesamiento y recuperación de datos y la adecuada
implementación de las reglas de negocio. Este tipo de pruebas están basadas en técnicas de
caja negra, es decir, verificar la aplicación interaccionando a través de las interfaces de
usuario y analizando los resultados.

Objetivos de la prueba Asegurar la navegación correcta de la aplicación,

Técnicas
Criterios de finalización
Consideraciones
la entrada de datos, su procesamiento y
recuperación.
Ejecutar cada caso de uso y flujo del caso de
uso con datos válidos e inválidos para verificar lo
siguiente:
• Cuando se utilizan datos correctos se
obtienen los resultados esperados.
• Cuando se utilizan datos incorrectos se
obtienen los mensajes de error o
advertencias adecuadas.
• Cada regla de negocio se ha aplicado
correctamente.
Todas las pruebas planificadas se han
ejecutado.
Todos los defectos identificados se han
considerado.
Ninguna.

3.1.3 Pruebas de interfaz de usuario.

Las pruebas de interfaz de usuario verifican la interacción del usuario con el sistema
software. El objetivo de esta prueba es asegurar que la interfaz de usuario permite al usuario
acceder y navegar a través de toda la funcionalidad de la aplicación. Además, la prueba de
interfaz de usuario garantiza que las interfaces de usuario cumplen los estándares.
 Objetivos de la prueba
Técnicas
Criterios de finalización
Consideraciones
Verificar los siguientes objetivos:
• La navegación a través de la aplicación
refleja adecuadamente las reglas de negocio
y los requisitos incluyendo ventana a
ventana, campo a campo y métodos de
acceso (tabulador, movimientos del ratón y
teclas de función).
• Las ventanas y sus características, como
menús, tamaño, posición y estado cumplen
los estándares.
Crear o modificar pruebas para cada ventana
con el objetivo de verificar la correcta navegación
y su estado.
Cada ventana se ha verificado con éxito y es
consistente con la versión de referencia o con
los estándares utilizados.
Ninguna.

3.1.4 Pruebas de desarrollo.

Las pruebas de desarrollo miden tiempos de respuesta, índices de transacción y otros

requisitos susceptibles al tiempo. El objetivo de estas pruebas es verificar y validar que los
requisitos de rendimiento se han alcanzado.
Las pruebas de desarrollo normalmente se ejecutan varias veces usando cada vez un cargo
de trabajo diferente. La prueba inicial se debería realizar con una carga normal y la segunda
prueba con una carga extrema.

Objetivos de la prueba Validar el tiempo de respuesta del sistema

Técnicas
Criterios de finalización
Consideraciones
software para las transacciones diseñadas o
funciones de negocio bajo las condiciones
siguientes:
• Volumen de trabajo normal.
• El peor volumen de trabajo.
Usar los procedimientos de prueba definidas
para las pruebas de funcionalidad.
Modificar los ficheros de datos (para incrementar
el número de transacciones) o modificar los
sripts para incrementar el número de iteraciones
que se ejecutan en cada transición.
Se han completado las pruebas sin ningún error
y dentro de los tiempos de respuesta esperados.
Ninguna.
3.2. Herramientas

Las siguientes herramientas se usarán para llevar a cabo el proceso de prueba:

Tipo de Prueba Herramienta

Gestión del proyecto Microsoft Project
Herramienta DBMS Oracle
Interfaz de usuario Test Complete
Funcionales JUnit
Optimize it
Rendimiento Test Load

4. Recursos

En esta sección describimos los recursos necesarios para realizar el proceso de prueba, sus
principales responsabilidades y características.

4.1. Recursos hardware

Recurso Cantidad Nombre y Tipo

PC 2 Diseño de las pruebas
PC 3 Ejecución de las
pruebas

4.2. Recursos software

Nombre del elemento software Tipo y otras notas

Magic Draw Desarrollo del proyecto
Microsoft Project Gestión del proyecto
Oracle Herramienta DBMS
Test Complete Interfaz de usuario
JUnit Funcionales
Optimize it
Test Load Rendimiento

4.3. Herramientas de soporte

Ninguna.

4.4. Configuración del entorno de prueba

Ninguna.
 4.5. Recursos humanos

RECURSOS HUMANOS
Rol Mínimos recursos Responsabilidades específicas o
recomendados comentarios
Gestor de prueba 1 Proporcionar una gestión adecuada.
Responsabilidades:
• Proporcionar una dirección técnica.
• Adquirir los recursos apropiados.
• Informar de la gestión.
Diseñador de prueba 3 Identificar, priorizare implementar los casos de
prueba.
Responsabilidades:
• Generar el Plan de pruebas.
• Diseñar los Casos de prueba.
• Evaluar el esfuerzo de prueba.
Probador (Tester) 3 Ejecutar las pruebas.
Responsabilidades:
• Ejecutar pruebas.
• Recuperar los errores.
• Documentar los defectos.

5. Actividades de prueba

Las actividades del proceso de prueba para este sistema software son:

Actividad Esfuerzo (p/d) Fecha de Fecha de finalización

comienzo
Planificación de la prueba 2 12 de Marzo 15 de Marzo
Diseño de la prueba 3 12 de Abril 20 de Abril
Implementación de la prueba 4 2 de Mayo 20 de Mayo
Ejecución de la prueba 3 1 de Junio 15 de Junio
Evaluación de la prueba 1 3 de Junio 17 de Junio

6. Resultados de las pruebas

Del proceso de prueba se obtienen los siguientes documentos de desarrollo de software:

Documento de desarrollo de Desarrollador Revisión Fecha

software
Plan de prueba LSI LSI 20 de Marzo
Casos de prueba LSI LSI 25 de Mayo
Informe de evaluación de pruebas LSI LSI 20 de Junio
Modelo de prueba LSI LSI 16 de Junio
7. Tareas de la etapa de pruebas

Las tareas que se realizan en cada una de las actividades son:

• Planificación de las pruebas:

o Identificar los requisitos para las pruebas.

o Valorar los riesgos.
o Desarrollar la estrategia de pruebas.
o Identificar los recursos necesarios para realizar las pruebas.
o Planificar la temporalización.
o Generar el Plan de pruebas.
• Diseño de las pruebas:

o Análisis de la carga de trabajo.

o Desarrollo de las pruebas.
o Identificar y describir los casos de prueba.

• Implementación de las pruebas:

o Establecer el entorno de prueba.

o Desarrollar las clases de prueba, los componentes de prueba y los datos de
prueba.

• Ejecución de las pruebas:

o Ejecutar los casos de prueba.

o Evaluar la ejecución del proceso de prueba.
o Verificar los resultados.
o Investigar los resultados no esperados.
o Registrar los defectos.

• Evaluación de las pruebas:

o Evaluar la cobertura de los casos de prueba.

o Evaluar la cobertura del código.
o Analizar los defectos.
o Determinar si se han alcanzado los criterios de las pruebas.
o Crear los informes de evaluación de las Pruebas.
 CONCLUSIONES

Las pruebas del sistema, es la etapa dentro del ciclo de vida o de desarrollo de
software que involucra la revisión final para garantizar la calidad del software. El plan de
pruebas a seguir debe abarcar aspectos los aspectos que permitan detectar y corregir los
errores u omisiones, antes de entregar el producto final, tomando en cuenta tanto los
principios y estándares como el de documentación para las pruebas del IEEE, que permiten
elaborar un plan de acuerdo al software que se desarrolla.
 REFERENCIAS BIBLIOGRAFICAS

Pressman R. (2005). Ingeniería de Software Un Enfoque Práctico. Editorial McGrawHill.

Sexta edición

Sommerville I. (2005). Ingeniería de Software Un Enfoque. Séptima edición

Editorial Pearson Addison Wesley. España

Universidad Simón Bolívar (2001). Plan de Pruebas. Consultado en Noviembre, 13, 2009 en
http://www.ldc.usb.ve/~teruel/ci4713/clases2001/planPruebas.html.