FORMATO APTI PlanPruebas

Plan de Pruebas
<Nombre del Proyecto>

Empresa
Versin 1.0
[El texto entre corchetes y desplegado en itlicas de color fucsia se incluye para proveer una gua para el
llenado del documento y debe ser borrado antes de publicar el documento: Sobre este texto oprimir el botn
derecho del ratn Seleccionar texto con formato similar - Borrar con la tecla suprimir]
[Para actualizar los campos en Microsoft Word (los cuales se muestran sobre un fondo gris cuando se
selecciona], ir a Archivo > Propiedades > Resumen y reemplazar los campos Asunto con el Nombre del
Proyecto y Autor con el nombre del autor de este documento despus ir a Personalizar y actualizar el valor
Numero de Documento en la lista de propiedades del mismo dialogo, por el nuevo nmero de versin.
Posteriormente cerrar el dialogo actualizar el documento seleccionando en el men Editar > Seleccionar todo
o CtrlE y presionar F9, o simplemente dar un clic sobre el campo y presionar F9. Esto debe repetirse tambin
en el ndice, encabezado y pie de pgina, en todas sus secciones.]
[Reemplazar los <textos> por sus valores correspondientes en cada seccin.]

Documento: Plan de Pruebas
Clave: NombredelProyecto_PlanPruebas_ddmmaa_v1.doc
Versin:
1.0
Fecha: 18/11/2016
Historial de Revisin
Fecha
<dd/mmm/yy>
C o n fi d e n c i a l
Versin
<x.x>
Descripcin
<detalles>
Tera.LOC, 2016
Autor
<nombre>
Pgina 2

Versin:
1.0
Fecha: 18/11/2016
Tabla de contenido
1.
Introduccin
1.1
Propsito
1.2
Contexto
1.3
Alcance
1.4
Identificacin del Proyecto
2.
Requerimientos de Pruebas
3.
Estrategia de Pruebas
3.1
Tipos de Prueba
3.1.1 Prueba de la Integridad de los Datos y de la bBase de Datos
3.1.2 Prueba de la Funcin
3.1.3 Prueba del Ciclo de Negocio
3.1.4 Prueba de la Interfaz de ususrio
3.1.5 El Perfil de Funcionamiento
3.1.6 Prueba de Carga
3.1.7 Prueba de Tensin
3.1.8 Prueba de Volumen
3.1.9 Prueba de la seguridad y del control de acceso
3.1.10 Failover y prueba de recuperacin
3.1.11 Prueba de la Configuracin
3.1.12 Prueba de la Instalacin
3.2
Herramientas
4.
Recursos
4.1
Roles
4.2
Sistema
5.
Projecto Milestones
6.
Deliverables
6.1
Modelo de Prueba
6.2
Prueba de Registro
6.3
Informes de Defecto
Apendice A
Error! Marcador no definido.

2
2
2
2
Tareas del Proyecto
Tera.LOC, 2016
Pgina 3

Versin:
1.0
Fecha: 18/11/2016
Plan de Pruebas
1.
Introduccin
1.1
Propsito
Este documento de Plan de Pruebas para el <Nombre del Proyecto> soporta los siguientes objetivos:
[Identifica informacin del proyecto y componentes de software que pueden ser probados.
Lista de requerimientos recomendados para las pruebas (alto nivel).
Recomendaciones y descripciones de estrategias de prueba a ser empleadas.
Identifica las fuentes requeridas y provee un estimado de pruebas de esfuerzo.
Lista los elementos entregables de pruebas del proyecto.]
1.2
Contexto
[Introduzca una breve descripcin del objetivo de la prueba (componentes, aplicaciones, sistemas, etctera)
y sus objetivos. Incluyendo informacin, como principales funcionalidades, su arquitectura y una breve
historia del proyecto. Esta seccin debe abarcar entre tres y seis prrafos.]
1.3
Alcance
[Describa las niveles de prueba por ejemplo, Unidad, Integracin, o Sistema y los tipos de pruebas
tratados en este plan, tal como funcionalidad, usabilidad, desempeo y confiablidad.
Provee una breve lista de las caractersticas de pruebas objetivo y funciones que sern o no probadas.
Liste cualquier supuesto hecho durante el desarrollo de este documento que pueda impactar el diseo,
desarrollo o implementacin de pruebas.
Liste cualquier riesgo o contingencia que pueda afectar el diseo, desarrollo o implementacin de pruebas.
Liste cualquier restriccin que pueda afectar le diseo, desarrollo o implementacin de pruebas.]
Tera.LOC, 2016
Pgina 4

1.4
Versin:
1.0
Fecha: 18/11/2016
Identificacin del Proyecto

La tabla siguiente identifica la documentacin y disponibilidad para desarrollar el Plan de pruebas:
[Nota: Borre o agregue los elementos segn sea apropiado.]
Documento
(y version / fecha)
Especificacin de
Requerimientos
Creado o
Disponible
x
Recibido o
Revisado
Autor o Recurso
Si
No
Si
No
Especificaciones
Funcionales
Si
No
Si
No
Reportes de Caso de Uso
Si
No
Si
No
Plan del Proyecto
Si
No
Si
No
Especificaciones de Diseo
Si
No
Si
No
Prototipo
Si
No
Si
No
Manuales de Usuario
Si
No
Si
No
Modelo o Flujo del

Negocio
Si
No
Si
No
Modelo o Flujo de Datos
Si
No
Si
No
Funciones y Reglas del

Negocio
Si
No
Si
No
Evaluacin del Riesgo del

Proyecto o Negocio
Si
No
Si
No
2.
Notas
Requerimientos de Pruebas
El listado siguiente identifica los elementos casos de uso, requerimientos funcionales, y requerimientos
no funcionales que hayan sido identificados como objetivos de las pruebas. Esta lista representa lo que
ser probado.
[Introduzca una lista de alto nivel de los principales requerimientos de pruebas.]
3.
Estrategia de Pruebas
[La estrategia de la prueba presenta el acercamiento recomendado a la prueba del objetivo de prueba. La
seccin anterior, Requisitos de Prueba, describe cul ser probadoesto describe como el objetivo- de-prueba
ser probado.
Para cada tipo de prueba, proporcione una descripcin de la prueba y porqu se est siendo implementado y
ejecutado.
Si un tipo de prueba no es implementado y s ejecutado, indicar esto en una oracin que indique que la prueba
no ser implementada o ejecutada y la indicacin de la justificacin, quedar como " esta prueba no ser
puesta en ejecucin ni ser ejecutada. Esta prueba no es apropiada."
Tera.LOC, 2016
Pgina 5

Versin:
1.0
Fecha: 18/11/2016
Las consideraciones principales para la estrategia de la prueba son las tcnicas que se utilizarn y el criterio
para saber cundo se termina la prueba.
Adems de las consideraciones proporcionadas para cada prueba abajo, la prueba debe solamente debera
ser ejecutada usando lo conocido, bases de datos controladas en ambientes seguros. ]
3.1
Tipos de Prueba
3.1.1
Prueba de la integridad de los datos y de la base de datos
[Las bases de datos y los procesos de la base de datos se deberan probar como subsistema independiente.
Esta examinacin deber probar los subsistemas dentro de la interfaz del usuario del objetivo-de-prueba
como la interfaz a los datos. La investigacin adicional en el Sistema de Administracin de Bases de Datos
(DBMS) necesita ser realizada para identificar las herramientas y las tcnicas que pueden existir para
apoyar la prueba identificada abajo.]
Objetivo de Prueba:
[Asegure la funcin de los mtodos y de los procesos de acceso de base

de datos correctamente y sin la corrupcin de datos.]
Tcnica:
[Invoque cada mtodo y proceso de acceso de base de datos,

sembrando cada uno con los datos vlidos e invlidos o las peticiones
de los datos.

Examine la base de datos para asegurar que los datos han
sido poblados segn lo previsto, todos los acontecimientos de la base de
datos ocurridos correctamente, o repase los datos devueltos para
asegurarse de que los datos correctos fueron recuperados por las
razones correctas]
Herramientas requeridas
[La tcnica requiere las siguientes herramientas:

Herramienta de automatizacin del script de prueba
Herramientas de recuperacin y respaldo
Herramientas de monitoreo-instalacin (registro, disco duro, CPU,
memoria y as sucesivamente)
Herramientas y utilidades SQL de base de datos
Herramientas de generacin de datos.]
Criterios de
Terminacin:
[Todos los mtodos y procesos de acceso de base de datos funcionan

segn lo diseado y sin ninguna corrupcin de los datos.]
Consideraciones
Especiales:

[La prueba puede requerir un ambiente de desarrollo del
DBMS o controladores para introducir o modificar los datos
directamente en la base de datos.

Los procesos se deben llamar manualmente.

Las bases de datos pequeas o como mnimo clasificadas
(nmero limitado de expedientes) deben de ser utilizadas para aumentar
la visibilidad de cualquier acontecimiento no-aceptable.]
Tera.LOC, 2016
Pgina 6

3.1.2
Versin:
1.0
Fecha: 18/11/2016
Prueba de Funcionalidad
[La prueba de funcionalidad del objetivo-de-prueba debe centrarse en cualquier requisito para la prueba
que se puede rastreada directamente para utilizar casos o funciones de negocio y reglas de negocio. Las
metas de estas pruebas son verificar la aceptacin de datos apropiada, proceso, y recuperacin, e
implementacin apropiada de las reglas de negocio. Este tipo de prueba se basa sobre tcnicas de la caja
negra; eso est verificando la aplicacin y sus procesos internos interactuando con la aplicacin va la
Interfaz Grfica del Usuario (GUI) y analizando la salida o los resultados. Se identifica abajo un contorno
de la prueba recomendada para aplicacin:]
Objetivo de Prueba:
[Asegure la funcionalidad apropiada del objetivo-de-prueba,

incluyendo la navegacin, la entrada de datos, el proceso, y la
recuperacin.]
Tcnica:
[Ejecute cada caso de uso, flujo de uso-caso, o funcin, usando los datos
vlidos e invlidos, verificar el siguiente:
Los resultados previstos ocurren cuando se utilizan los datos vlidos.
Se exhibe el error apropiado o los mensajes de alerta cuando se
utilizan los datos invlidos.

Herramientas
Requeridas:
Cada regla de negocio se aplica correctamente.]
La tcnica require las herramientas siguientes:

Criterios de
Terminacin:
[Se han ejecutado todas las pruebas previstas.
Se han direccionado todos los defectos identificados.]
Consideraciones
Especiales:
[Identifique o describa esos artculos o puntos (internos o externos) ese

impacto la implementacin y la ejecucin de la prueba de funcin]
Tera.LOC, 2016
Pgina 7

3.1.3
Versin:
1.0
Fecha: 18/11/2016
Prueba de Ciclo de Negocio
[La prueba del ciclo de negocio debe emular las actividades realizadas en <nombre del proyecto > un
cierto plazo. Un perodo se debe identificar, por ejemplo un ao, y las transacciones y las actividades que
ocurrirn durante el perodo de un ao deben ser ejecutadas. Esto incluye todos los ciclos diarios,
semanales, y mensuales, los acontecimientos que son fechas-sensibles, por ejemplo ticklers.]
Objetivo de Prueba:
[Asegure la funcin apropiada de los procesos del objetivo-de-prueba y

de fondo segn modelos y horario requeridos del negocio.]
Tcnica:
[La prueba simular varios ciclos de negocio realizando lo siguiente:

Las pruebas usadas para la prueba de funcin del objetivode-prueba
sern modificadas o realzadas para aumentar el nmero
de veces que se ejecuta cada funcin para simular varios usuarios
sobre un periodo especificado.

Toda funcin de tiempo o fecha-sensible ser ejecutada
usando fechas o perodos de tiempo vlidos o invlidos.

Todas las funciones que ocurren en un horario peridico
sern ejecutadas o lanzadas en el tiempo apropiado.

La prueba incluir usando datos vlidos e invlidos para
verificar lo siguiente:

vlidos.
Los resultados previstos ocurren cuando se utilizan los datos

Se exhibe el error apropiado o los mensajes de alerta cuando
se utilizan los datos invlidos.

Herramientas
Requeridas:
Cada regla de negocio se aplica correctamente.
La tcnica requiere las herramientas siguientes:

Criterios de
Terminacin:
[Se han ejecutado todas las pruebas previstas.
Se han tratado todos los defectos identificados.]
Tera.LOC, 2016
Pgina 8

Consideraciones
Especiales:
Versin:
1.0
Fecha: 18/11/2016

[Las fechas y los acontecimientos del sistema pueden requerir
actividades especiales de soporte

El modelo de negocio se requiere para identificar requisitos
apropiados de la prueba y los procedimientos.]
Tera.LOC, 2016
Pgina 9

3.1.4
Versin:
1.0
Fecha: 18/11/2016
Prueba de Interfaz del Usuario
[La Prueba de interfaz del Usuario (UI) verifica la interaccin de un usuario con el software. El objetivo de
la prueba de UI es asegurarse de que la interfaz del usuario provee al usuario el acceso y la navegacin
apropiados con las funciones del objetivo-de-prueba. Adems, la prueba de UI se asegura de que los
objetos dentro del UI funcionan segn lo esperado y se conforma con los estndares corporativos o de la
industria.]
Objetivo de Prueba:
[Verificar lo siguiente:

La navegacin a travs del objetivo-de-prueba refleja
correctamente en las funciones y los requerimientos, incluyendo
ventana-a-ventana, campo-a campo, y el uso de los mtodos de acceso
(tabuladores, movimientos del ratn, claves de aceleracin)

Objetos y caractersticas de la ventana, tales como mens,
tamao, posicin, estado, y foco se conforman con los estndares.]
Tcnica:
[Cree o modifique las pruebas para que cada ventana verifique los
estados apropiados de navegacin y del objeto para cada ventana y los
objetos de uso.]
Herramientas requeridas
[La tcnica requiere las Herramientas de Automatizacin del script de

prueba.]
Criterios de
Terminacin:
[La tcnica apoya la prueba de cada pantalla o ventana principal que

ser usada extensamente por el usuario final.]
Consideraciones
Especiales:
[No todas las caractersticas para los objetos de costumbre y de

terceros pueden ser alcanzadas.]
Tera.LOC, 2016
Pgina 10

Versin:
1.0
Fecha: 18/11/2016
3.1.5 El Perfil de Funcionamiento

[El perfil de funcionamiento es una prueba de funcionamiento en la cual los tiempos de respuesta, ndices de
transaccin y otros requerimientos de tiempos sensibles se miden y se evalan. El objetivo del perfil del
funcionamiento es verificar que los requerimientos del funcionamiento se han alcanzado. El perfil del
funcionamiento es implementado y se ejecuta para perfilar y afinar los comportamientos de funcionamiento de
un objetivo-de-prueba como funcin de condiciones tales como configuraciones de la carga de trabajo o de
hardware.
Nota: Las transacciones abajo refieren a " transacciones de negocio lgicas. Estas transacciones se
definen como casos especficos de uso que se espere que un agente del sistema realice con el objetivo-deprueba, por ejemplo agregan o modifican un contrato dado.]
Objetivo de Prueba:
[Verifique los comportamientos de funcionamiento para las

transacciones sealadas o las funciones del negocio bajo las
condiciones siguientes:
carga de trabajo anticipada normal
Tcnica:
carga de trabajo del peor del caso anticipada]
[Utilice los mtodos de prueba desarrollados para la prueba de la

funcin o de ciclo de negocio.
Modifique los archivos de datos para aumentar el nmero de
transacciones o los scripts para aumentar el nmero de iteraciones
para cada transaccin que ocurre.
Los scripts se deben funcionar en una mquina (el mejor caso es a la
usuario nico, transaccin simple) y deber ser repetido con los
clientes mltiples (virtuales o reales, vea las consideraciones
especiales abajo).]
Herramientas
Requeridas:

Una herramienta de perfil de funcionamiento de aplicacin, como
Rational Quantify.
Criterios de
Terminacin:
[La tcnica apoya probando:

[La transaccin simple o un solo usuario: Emulacin exitosa de los
scripts de transaccin sin ninguna falla debido a los problemas de
implementacin de pruebas.]
[Las transacciones mltiples o usuarios mltiples: Emulacin exitosa
de la carga de trabajo sin fallas debido a los problemas de
implementacin de pruebas.]
Tera.LOC, 2016
Pgina 11

Consideraciones
Especiales:
Versin:
1.0
Fecha: 18/11/2016
[La prueba de funcionamiento comprensiva incluye tener una carga de

trabajo de fondo en el servidor.
Hay varios mtodos que se pueden utilizar para realizar esto,
incluyendo:
Maneje las transacciones" directamente en el servidor, generalmente
en la forma de las sentencias SQL.
Cree la carga " virtual " del usuario para simular a muchos clientes,
generalmente varios cientos. Las Herramientas de Emulacin de
Terminales Remotas se utilizan para lograr esta carga. Esta tcnica se
puede tambin utilizar para cargar la red con trfico.
Utilice a clientes fsicos mltiples, cada script prueba de
funcionamiento para poner una carga en el sistema.
La prueba de funcionamiento se debe realizar en una mquina dedicada o
en un tiempo dedicado. Esto permite control completo y la medida exacta.
Las bases de datos usadas para la prueba de funcionamiento deben ser
de cualquier tamao real o escalado igualmente.]
Tera.LOC, 2016
Pgina 12

3.1.6
Versin:
1.0
Fecha: 18/11/2016
Prueba de Carga
[La prueba de la carga es una prueba del funcionamiento que sujeta al objetivo-de-prueba variando las
cargas de trabajo para medir y evaluar los comportamientos de funcionamiento y la capacidad del objetivode-prueba de continuar funcionando correctamente bajo estas diversas cargas de trabajo. El objetivo de la
prueba de la carga es determinar y asegurarse de que el sistema funciona correctamente ms all de la
carga de trabajo mxima prevista. Adems, la prueba de la carga evala las caractersticas de
funcionamiento, tales como tiempos de respuesta, ndices de transaccin, y otros puntos sensibles al
tiempo).]
[Nota: Las transacciones abajo refieren a " transacciones de negocio lgicas ". Estas transacciones se
definen como funciones especficas que se esperan que un usuario final del sistema realice con el uso de la
aplicacin, por ejemplo agregan o modifican un contrato dado.]
Objetivo de Prueba:
[Verifique las transacciones designadas o los casos del negocio bajo

condiciones de la carga de trabajo para observar y registrar el
comportamiento del objetivo y la informacin de desarrollo del
sistema.]
Tcnica:
[Utilice los scripts de prueba de transaccin para la funcin o del ciclo

de negocio como base, pero recuerde remover las interacciones y los
retrasos innecesarios.
Modifique los archivos de datos para aumentar el nmero de
transacciones o las pruebas para incrementar el nmero de veces que
cada transaccin ocurre.]
Las cargas de trabajo deben incluir- por ejemplo, diariamente,
semanalmente y mensualmente- cargas pico.
Las cargas de trabajo deben representar las cargas promedio as como
las pico.
Las cargas de trabajo deben representar picos continuas e instantneos.
Las cargas de trabajo deben ser ejecutadas sobre diferente
Configuracin de ambiente de pruebas.
Herramientas
Requeridas:

Herramienta de control y calendarizacin de cargas de transaccin
Herramientas de generacin de datos
Criterios de
Terminacin:
[La tcnica apoya a la prueba de Emulacin bajo, la cual es una

emulacin exitosa de la carga de trabajo sin ninguna falla y debido a los
problemas de implementacin de las pruebas.]
Tera.LOC, 2016
Pgina 13

Consideraciones
Especiales:
Versin:
1.0
Fecha: 18/11/2016
[La prueba de la carga se debe realizar en una mquina dedicada o en

tiempo dedicado. Esto permite control completo y la medida exacta.
Las bases de datos usadas para la prueba de la carga deben ser o de
tamao real o escaladas igualmente.]
Tera.LOC, 2016
Pgina 14

Versin:
1.0
Fecha: 18/11/2016
3.1.7 Prueba de Estrs

[La prueba de estrs es un tipo de prueba del funcionamiento implementada y ejecutada para entender como
un sistema falla debido a las condiciones en el lmite o fuera de l, las tolerancias esperadas. Esto involucra
tpicamente bajos recursos o una competencia por los recursos. Una memoria baja o poco espacio de disco
puede revelar los defectos en el objetivo-de-prueba que no son condiciones normales inferiores evidentes.
Otros defectos pudieron resultar de la competicin por los recursos compartidos como el ancho de banda de la
red o los seguros de la base de datos. La prueba de tensin se puede tambin utilizar para identificar la carga
de trabajo mxima que el objetivo-de-prueba puede manejar.]
[Note: Las referencias a las transacciones abajo refieren a transacciones de negocio lgicas.]
Objetivo de Prueba:
[Verifique que las funciones del objetivo-de-prueba correctamente y sin

error bajo las siguientes condiciones de estrs:
poco o nada de memoria disponible en el servidor (RAM y espacio de
almacenamiento persistente)
nmero clientes fsicamente o reales mximos conectados o simulados.
usuarios mltiples haciendo las mismas transacciones contra los
mismos datos o cuentas
el peor caso de volumen de transicin o mezcla (vase la prueba de
funcionamiento arriba).
Notas: El objetivo de la Prueba de Estrs se pudo tambin indicar como
identificar y documentar las condiciones bajo las cuales el sistema FALLA
para continuar funcionando correctamente.
La prueba de estrs del cliente se describe bajo la seccin 3.1.11
prueba de la configuracin.]
Tcnica:
[Utilice las pruebas desarrolladas para el perfil de funcionamiento o la

prueba de carga.
Para probar recursos limitados, las pruebas se deben correr en una
sola mquina, y la RAM y el DASD en el servidor deben ser reducidos o
limitados.
Para las pruebas de estrs restantes, los clientes mltiples deben ser
utilizados, tanto para el funcionamiento de las mismas pruebas o para
las pruebas complementarias para producir el peor caso de mezcla o
volumen de transaccin.
Herramientas
Requeridas:

Tera.LOC, 2016
Pgina 15

Versin:
1.0
Fecha: 18/11/2016
Criterios de
Terminacin:
[La tcnica apoya las prueba de Emulacin de Estrs. El sistema puede

ser emulado exitosamente en uno o mas condiciones definidas como
condiciones de estrs y una observacin del estado del sistema
resultante, durante y despus de las que la condicin ha sido emuladam
puede ser capturada.]
Consideraciones
Especiales:
[Estresar la red puede requerir las herramientas de la red para cargar

la red con los mensajes o paquetes.
El DASD usado para el sistema se debe reducir temporalmente para
restringir el espacio disponible para que la base de datos crezca.
Sincronizacin del acceso de los clientes simultneos a los mismos
registros o datos de cuenta.]
Tera.LOC, 2016
Pgina 16

Versin:
1.0
Fecha: 18/11/2016
3.1.8 Prueba de Volumen

[Las Pruebas de Volumen sujetas al objetivo-de-prueba asignan a las grandes cantidades de datos para
determinar si se alcanzan los lmites que hacen que el software falle. El Volumen que Prueba tambin
identifica la carga mxima continua o volumen que el objetivo-de-prueba puede manejar por un perodo dado.
Por ejemplo, si el objetivo-de-prueba est procesando un conjunto de registros de la base de datos para
generar un informe, una prueba de volumen utilizara una base de datos grande de la prueba y comprobara
que el software se comport normalmente y produjo el informe correcto.]
Objetivo de Prueba:
[Verifique que el objetivo-de-prueba funcione con xito bajo los

panoramas siguientes del alto volumen:
(real o fsicamente -capaz) el nmero mximo de clientes conectados, o
simulados, todos realizando lo mismo, peor caso (desarrollo) funcin
del negocio por un perodo extendido.
El tamao mximo de la base de datos ha sido alcanzado (real o
escalado) y mltiples queries o reportes de transacciones se ejecutan
simultneamente.]
Tcnica:
[Utilice las pruebas desarrolladas para el perfil del funcionamiento o la

prueba de carga.
Los clientes mltiples deben ser utilizados, o ejecutando las mismas
pruebas o las pruebas complementarias para producir el peor caso de
mezcla o volumen de transaccin (vase la prueba de estrs arriba) por
un perodo extendido.
Se crea el mximo tamao de la base de datos (real, escalada, o se
llena con datos representativos) y los clientes mltiples usados para
correr queries y reportar las transacciones simultneamente por
perodos extendidos.]
Herramientas
Requeridas:

Criterios de
Terminacin:
[Se han ejecutado todas las pruebas previstas y los lmites

especificados del sistema son alcanzados o excedidso sin el software o
fallas de software.]
Consideraciones
Especiales:
[Qu perodo de tiempo sera considerado un tiempo aceptable para las

condiciones del alto volumen, segn lo observado arriba?]
Tera.LOC, 2016
Pgina 17

Versin:
1.0
Fecha: 18/11/2016
3.1.9 Prueba de la seguridad y del control de acceso

[La prueba de seguridad y de control de acceso se enfoca en dos reas clave de seguridad:
Seguridad a nivel aplicacin, incluyendo el acceso a los datos o a las funcionalidades del negocio
Seguridad a nivel sistema, incluyendo el registro en el acceso remoto al sistema.
La seguridad a nivel aplicacin se asegura de que, basada en la seguridad deseada, restringe a los actores de
las funciones especficas o casos de uso, o los limita en los datos que estn disponibles para ellos. Por ejemplo,
para cada uno se puede permitir incorporar datos y para crear nuevas cuentas, pero solamente los
administradores pueden borrarlos. Si hay seguridad en el nivel de datos, la prueba se asegura que el "usuario
tipo uno" pueda ver toda la informacin del cliente, incluyendo datos financieros, sin embargo, "usuario dos"
ve solamente los datos demogrficos para el mismo cliente.
La seguridad a nivel sistema se asegura de que solamente esos usuarios que se les concede acceso al sistema
sean capaces de tener acceso a las aplicaciones y solamente a travs de las gateways apropiadas.]
Objetivo de Prueba:
Tcnica:
Seguridad a nivel aplicacin: [Verifique que un actor pueda tener

acceso solamente a esas funciones o datos para los cuales su tipo
del usuario tenga permisos proporcionados.]
Seguridad a nivel sistema: Verifique que solamente permitan a

esos actores el acceso al sistema y a las aplicaciones que estn
permitidos para accesarlos.]
Seguridad a nivel aplicacin: [Identifique y enumere cada tipo de

usuario y las funciones o los datos para los que tiene permiso.]
[Cree las pruebas para cada tipo del usuario y verifique cada
permiso creando las transacciones especficas a cada tipo del
usuario.]
Modifique las pruebas de re-ejecucin y del tipo de usuario
para los mismos usuarios. En cada caso, verifique que esas
funciones adicionales o los datos estn correctamente
disponibles o negadas.
Seguridad a nivel sistema: [Vea las consideraciones especiales

abajo]
Criterios de Terminacin:
[Para cada tipo de actor conocido la funcin o los datos

apropiados estn disponibles, y todas las transacciones funcionan
segn lo esperado y funcionan en pruebas de funcin anteriores
del uso.]
Consideraciones Especiales:
[El acceso al sistema se debe repasar o discutir con el

administrador apropiado de la red o de sistemas. Esta prueba
puede ser no requerida mientras que sea una funcin de la
administracin de la red o de los sistemas.]
Tera.LOC, 2016
Pgina 18

Versin:
1.0
Fecha: 18/11/2016
3.1.10 Failover y prueba de recuperacin

[Failover y la Prueba de la Recuperacin se aseguran de que el objetivo-de-prueba pueda hacer failover
con xito y se recupeea de una variedad de malfuncionamientos del hardware, software o de la red con la
prdida indebida de datos o de integridad de los datos.
La prueba de Failover se asegura de que, para esos sistemas que deban mantenerse funcionando, cuando
ocurre una condicin de failover, los sistemas alternos o de reserva " asumen el control correctamente "
para el sistema cado sin la prdida de datos o de transacciones.
La prueba de recuperacin es un proceso antagnico de la prueba en el cual la aplicacin o el sistema se
expone a las condiciones extremas, o condiciones simuladas, para causar una falta, tal como fallas de un
dispositivo de entrada-salida(I/O) o los indicadores y claves invlidas de la base de datos. Se invocan los
procesos de recuperacin y la aplicacin o el sistema se supervisa y se examina para verificar la aplicacin
apropiada, o el sistema, y se ha alcanzado la recuperacin de los datos.]
Objetivo de Prueba:
[Verifique que los procesos de recuperacin (manuales o

automatizados) restauran correctamente la base de datos, los
usos, y el sistema a un deseado y conocido, estado. Los tipos
siguientes de condiciones deben ser incluidos en la prueba:
interrupcin de la energa al cliente
interrupcin de la energa al servidor
interrupcin de la comunicacin va los servidores de la red
interrupcin, comunicacin, o apagn al DASD y o controles
del DASD
ciclos incompletos (los procedimientos de filtrado de los
datos interrumpidos, procesos de sincronizacin de los datos
interrumpidos).
indicador invlido o claves de la base de datos
elemento de datos invlido o corrompido en base de datos]
Tera.LOC, 2016
Pgina 19

Tcnica:
Versin:
1.0
Fecha: 18/11/2016
[Las Pruebas creadas para la Prueba de la Funcin y de Ciclo

de Negocio se deben utilizar para crear una serie de
transacciones. Una vez que se alcance el punto de prueba de
inicio deseado, las acciones siguientes se deben realizar, o
simular, individualmente:
Interrupcin de la energa al cliente: apagar la PC .
Interrupcin de la energa al servidor: simule o inicie el
corte de energa para el servidor.
Interrupcin va los servidores de la red: simule o inicie la
prdida de la comunicacin con la red (fsicamente desconecte
los cables de comunicacin de la energa de los servidores o
ruteadores.
Interrupcin, comunicacin, o apagn al DASD y
reguladores del DASD: simule o elimine fsicamente
comunicacin con unos o ms dispositivos de control del
DASD.
Una vez se alcanzan las condiciones antes mencionadas o las
condiciones simuladas, las transacciones adicionales deben
ser ejecutadas y rebasar este segundo estado del punto de
prueba, los procedimientos de recuperacin deben ser
invocados.
La prueba para los ciclos incompletos utiliza la misma tcnica
que se describe arriba excepto que los procesos de la base de
datos en s mismos deberan ser abortados o ser terminados
prematuramente.
La prueba para las condiciones siguientes requiere que un
estado conocido de la base de datos est alcanzado. Varios
campos, indicadores, y claves de la base de datos se deben
corromper manualmente y directamente dentro de la base de
datos (va las herramientas de la base de datos). Las
transacciones adicionales se deben ejecutar usando las
Pruebas de la Aplicacin de la Funcin del Uso y de Ciclo de
Negocio y de ciclos completos ejecutados.]
[En todos los casos arriba, el uso, la base de datos, y el

sistema deberan, sobre completar los procedimientos de
recuperacin, regreso a un estado conocido, deseable. Este
estado incluye la corrupcin de los datos limitada a los
campos corrompidos conocidos, los indicadores o las claves, y
los informes indicando los procesos o las transacciones que
no fueron terminadas debido a las interrupciones.]
Tera.LOC, 2016
Pgina 20

Versin:
1.0
Fecha: 18/11/2016
[La prueba de la recuperacin es altamente intrusa. Los

procedimientos para desconectar cableador (simulando
prdida de la energa o de la comunicacin) pueden no ser
deseables o factibles. Los mtodos alternativos, tales como
herramientas del software de diagnstico pueden ser
requeridos.
Grupos Recursos de los Sistemas (o de las operaciones de
computadora), Bases de Datos, y Red son requeridos.
Estas pruebas se deben funcionar despus de horas o en
mquinas aisladas.]
Tera.LOC, 2016
Pgina 21

Versin:
1.0
Fecha: 18/11/2016
3.1.11 Prueba de Configuracin

[La prueba de la configuracin verifica la operacin del objetovo-de-prueba en diversas configuraciones de
software y de hardware. En la mayora de los ambientes de la produccin, las especificaciones particulares
del hardware para los sitios de trabajo del cliente, las conexiones de red y los servidores de la base de datos
varan. Las estaciones de trabajo del cliente pueden tener diferente software cargado-- por ejemplo,
aplicaciones, controladores, etc. y en cualquier momento, muchas diversas combinaciones pueden ser
activadas usando diferentes recursos.]
Objetivo de Prueba:
[Verifique que el objetivo-de-prueba funcione correctamente en

las configuraciones requeridas del hardware y del software.]
Tcnica:
[Use Funciones de Sscripts de Prueba.

Abra y cierre el software relacionado varia no-objetivo-deprueba, tal como las aplicaciones de Microsoft, Excel y Word,
como parte de la prueba o antes del comienzo de la prueba.
Ejecute las transacciones seleccionadas para simular al
agente que interacta recprocamente con el objetivo-deprueba y el software del no-objetivo-de-prueba.
Repita el proceso antes mencionado, reduciendo al mnimo la
disponibilidad de memoria convencional en la estacin de
trabajo del cliente.]
[Para cada combinacin del software del objetivo-de-prueba y

del no-objetivo-de-prueba, todas las transacciones se
terminan con xito sin falla.]
[Qu software del no-objetivo-de-prueba es necesario, est

disponible, y es accesible desde el escritorio?
Qu aplicaciones se utilizan tpicamente?
Qu datos son las aplicaciones en ejecucuns; por ejemplo,
un gran la hoja de balance abierta dentro de Excel o un
documento de100 pginas en Word?
Los sistemas enteros, netware, servidores de red, bases de
datos, y etc., tambin necesitan ser documentados como parte
de esta prueba.]
Tera.LOC, 2016
Pgina 22

Versin:
1.0
Fecha: 18/11/2016
3.1.12 Prueba de Instalacin

[La prueba de la instalacin tiene dos propsitos. El primero debe asegurar que el software se puede
instalar bajo diversas condiciones --tal como una nueva instalacin, una actualizacin, y una completa o
instalacin personalizada-- bajo condiciones normales y anormales. Las condiciones anormales incluyen la
espacio de disco escaso, carencia del privilegio de crear directorios, etctera. El segundo propsito es
verificar que, una vez que est instalado, el software funciona correctamente. Esto generalmente significa
ejecutar un nmero de las pruebas que fueron desarrolladas para la Prueba de Funcin.]
Objetivo de Prueba:
Verifique que el objetivo-de-prueba se instale correctamente

sobre cada configuracin de hardware requerida bajo
condiciones siguientes:
nueva instalacin, una mquina nueva, nunca instalada
previamente con < nombre del proyecto >
la actualizacin, mquina instalada previamente < nombre
del proyecto >, misma versin
la actualizacin, mquina instalada previamente el < nombre
del proyecto >, antigua versin
Tcnica:
[Manualmente o desarrolle las escrituras automatizadas,

para validar condicin del objetivo de la mquina-- nuevo - <
nombre del proyecto > nunca instalado; < proyecte el nombre
> la misma versin o antigua versin instalada ya).
Lance o realice la instalacin.
Con un subconjunto predeterminado de scriptss de prueba de
funcin,corra las transacciones.]
las transacciones conocidas del < proyecto > se ejecutan con

xito sin falta.
[Qu < nombre del proyecto > transacciones se deben

seleccionar para abarcar una prueba de < Nombre del
Proyecto > ha estado instalado con xito y no hay
componentes de software importantes?]
Tera.LOC, 2016
Pgina 23

Versin:
1.0
Fecha: 18/11/2016
3.2
Herramientas
Las herramientas siguientes sern empleadas para este proyecto:
[Nota: Suprima o agregue los artculos como apropiados.]
Herramienta
Vendor/In-house
Versin
Administrador de Pruebas
Tracking de Defecto
Herramienta ASQ para pruebas
multifuncionales
Herramienta de ASQ para la
prueba de funcionamiento
Test Coverage Monitor or Profiler
Administrador de Proyecto
Herramientas DBMS
Tera.LOC, 2016
Pgina 24

4.
Versin:
1.0
Fecha: 18/11/2016
Recursos
[Esta seccin presenta los recursos recomendados para el proyecto <Nombre del Proyecto >, sus
responsabilidades principales, y su sistema de conocimiento o de la habilidad.]
4.1
Roles
Esta tabla demuestra las asunciones que proveen de personal para el proyecto. .
[NOTA: Suprima o agregue los artculos como apropiados.]
Recursos Humanos
Trabajador
Recursos Mnimos
Recomendados
Responsabilidades especficas or Comentarios
(nmero de los papeles a tiempo

completo asignados)
Manejador de Prueba,
Proporciona cuidado de la gerencia.

Responsabilidades:
Manejador del Proyecto de

Prueba
Diseador de Prueba
proporciona la direccin tcnica
adquiere recursos apropiados
proporcione la divulgacin de la gerencia
Identifica, da la prioridad, y pone a casos de la

prueba en ejecucin.
Responsabilidades:
Probador
genere el plan de prueba
genere el modelo de la prueba
evale la eficacia del esfuerzo de la prueba
Ejecuta las pruebas.

Responsabilidades:
ejecute las pruebas
resultados del registro
recuprese de errores
peticiones del cambio del documento
Tera.LOC, 2016
Pgina 25

Manejadorr del Sistema de

Prueba
Versin:
1.0
Fecha: 18/11/2016
Asegura el ambiente de la prueba y se manejan y

se mantienen los activos.
Responsabilidades:
Administrador de la Base
de Datos, Manejador de la
base de Datos
administre el sistema de gerencia de la

prueba
instale y maneje el acceso a los sistemas de

la prueba
Asegura el ambiente de los datos de prueba

(base de datos) y se manejan y se mantienen los
activos.
Responsabilidades:
Diseador
administre los datos de prueba (base de

datos)
Identifica y define las operaciones, las

cualidades, y las asociaciones de las clases de la
prueba.
Responsabilidades:
Implementador
identifica y define las clases de la prueba
identifica y define los paquetes de la prueba
Instrumentos y pruebas de unidad que la prueba

clasifica y los paquetes de la prueba.
Responsabilidades:
4.2
crea las clases y los paquetes de la prueba

puestos en ejecucin en el modelo de la
prueba
Sistema
La tabla siguiente dispuso los recursos de sistema para el proyecto de prueba.
[Los elementos especficos del sistema de la prueba no se conocen completamente en este tiempo. Se
recomienda que el sistema simule el ambiente de la produccin, reduciendo los accesos y los tamaos de la
base de datos si y cuando sea apropiado.]
[Nota: Suprima o agregue los artculos como apropiados.]
Recursos del Sistema

Recurso
Nombre / Tipo
Servidor de la Base de datos

Red or Subred
Nombre del Servidor
TBD
TBD
Tera.LOC, 2016
Pgina 26

Nombre de la Base de Datos
Versin:
1.0
Fecha: 18/11/2016
TBD
Prueba PC's cel Cliente

Incluya los requisitos especiales de la
configuracin
TBD
Prueba de Repository
Red or Subred
Nombre del Servidor
Prueba de Desarrollo de PC's
TBD
TBD
TBD
Tera.LOC, 2016
Pgina 27

5.
Versin:
1.0
Fecha: 18/11/2016
Projecto de Milestones
[La prueba del < Nombre del Proyecto > debe incorporar las actividades de la prueba para cada uno de los
esfuerzos de la prueba identificados en las secciones anteriores. Los Limlestones separados del proyecto se
deben identificar para comunicar realizaciones del estado del proyecto.]
Tarea Milestone
Esfuerzo
Fecha de Inicio
Fecha de
Terminacin
Prueba del Plan

Diseo de Prueba
Implementacin de Prueba
Execucun de Prueba
Evaluacin de Prueba
6.
Deliverables
[En esta seccin, enumere los varios documentos, las herramientas, y los informes que sern creados, por
quien, entregado a quin, y cuando est entregado.]
6.1
Modelo de Prueba
[Esta seccin identifica los informes que sern creados y distribuidos del modelo de la prueba. Estos
productos de trabajo en el modelo de la prueba necesitan ser creados o ser referidos a las herramientas de
ASQ.]
6.2
Pruebas de Logs
[Describa el mtodo y las herramientas usadas para registrar y para divulgar sobre el estado de los
resultados y de la prueba de la prueba.]
6.3
Reportes de Defecto
[En esta seccin, identifique el mtodo y las herramientas usadas para registrar, para seguir, y para
divulgar sobre incidentes de la prueba y su estado.]
Tera.LOC, 2016
Pgina 28

Apndice A
Versin:
1.0
Fecha: 18/11/2016
Tareas de Proyecto
Debajo estn las tareas prueba-relacionadas:
Prueba del Plan

-
Identificar requerimientos para la prueba
determine el riesgo
desarrolle la estrategia de la prueba
identifique los recursos de la prueba
cree el horario
genere el plan de prueba
Prueba del Diseo

-
prepare el anlisis de la carga de trabajo
identifique y describa los casos de la prueba
identifique y estructure los mtodos de prueba
repase y determine la cobertura de la prueba
Implemente la prueba
-
scripts del expediente o de la prueba del programa
identifique la funcionalidad prueba-especfica en el Diseo y el Modelo de Implementacin
establezca los sets de datos externos

Ejecute la prueba
-
ejecute los mtodos de Prueba
evale la ejecucin de la Prueba
recuprese de la Prueba detenida
verifique los resultados
investigue los resultados inesperados
registre los defectos
Evale la prueba
-
evale la cobertura del Test-case
evale la cobertura del cdigo
Tera.LOC, 2016
Pgina 29

Versin:
1.0
Fecha: 18/11/2016
analice los defectos

determnese si se han alcanzado los Triterios de la Terminacin de la Prueba y los Criterios de xito
Tera.LOC, 2016
Pgina 30

FORMATO APTI PlanPruebas

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FORMATO APTI PlanPruebas

Uploaded by

Copyright:

Available Formats

Plan de Pruebas

<Nombre del Proyecto>

[Reemplazar los <textos> por sus valores correspondientes en cada seccin.]

<Nombre del Proyecto>

<Nombre del Proyecto>

Error! Marcador no definido.

Tareas del Proyecto

<Nombre del Proyecto>

<Nombre del Proyecto>

Identificacin del Proyecto

Reportes de Caso de Uso

Plan del Proyecto

Modelo o Flujo del

Modelo o Flujo de Datos

Funciones y Reglas del

Evaluacin del Riesgo del

<Nombre del Proyecto>

Prueba de la integridad de los datos y de la base de datos

[Asegure la funcin de los mtodos y de los procesos de acceso de base

[Invoque cada mtodo y proceso de acceso de base de datos,

[La tcnica requiere las siguientes herramientas:

[Todos los mtodos y procesos de acceso de base de datos funcionan

Los procesos se deben llamar manualmente.

<Nombre del Proyecto>

[Asegure la funcionalidad apropiada del objetivo-de-prueba,

Cada regla de negocio se aplica correctamente.]

La tcnica require las herramientas siguientes:

[Se han ejecutado todas las pruebas previstas.

Se han direccionado todos los defectos identificados.]

[Identifique o describa esos artculos o puntos (internos o externos) ese

<Nombre del Proyecto>

Prueba de Ciclo de Negocio

[Asegure la funcin apropiada de los procesos del objetivo-de-prueba y

[La prueba simular varios ciclos de negocio realizando lo siguiente:

Los resultados previstos ocurren cuando se utilizan los datos

Cada regla de negocio se aplica correctamente.

La tcnica requiere las herramientas siguientes:

[Se han ejecutado todas las pruebas previstas.

Se han tratado todos los defectos identificados.]

<Nombre del Proyecto>

<Nombre del Proyecto>

Prueba de Interfaz del Usuario

[La tcnica requiere las Herramientas de Automatizacin del script de

[La tcnica apoya la prueba de cada pantalla o ventana principal que

[No todas las caractersticas para los objetos de costumbre y de

<Nombre del Proyecto>

3.1.5 El Perfil de Funcionamiento

[Verifique los comportamientos de funcionamiento para las

carga de trabajo del peor del caso anticipada]

[Utilice los mtodos de prueba desarrollados para la prueba de la

La tcnica requiere las herramientas siguientes:

[La tcnica apoya probando:

<Nombre del Proyecto>

[La prueba de funcionamiento comprensiva incluye tener una carga de

<Nombre del Proyecto>

[Verifique las transacciones designadas o los casos del negocio bajo

[Utilice los scripts de prueba de transaccin para la funcin o del ciclo

La tcnica requiere las herramientas siguientes:

[La tcnica apoya a la prueba de Emulacin bajo, la cual es una

<Nombre del Proyecto>

[La prueba de la carga se debe realizar en una mquina dedicada o en

<Nombre del Proyecto>

3.1.7 Prueba de Estrs