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.]
<Nombre del Proyecto> Documento: Plan de Pruebas Clave: NombredelProyecto_PlanPruebas_ddmmaa_v1.doc Versin: 1.0 Fecha: 30/11/2012
Historial de Revisin
Fecha <dd/mmm/yy> Versin <x.x> <detalles> Descripcin Autor <nombre>
Confidencial
Tera.LOC, 2012
Pgina 2
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 base de datos 3.1.2 Prueba de Funcionalidad 3.1.3 Prueba de Ciclo de Negocio 3.1.4 Prueba de Interfaz del Usuario 3.1.5 El Perfil de Funcionamiento 3.1.6 Prueba de Carga 3.1.7 Prueba de Estrs 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 Configuracin 3.1.12 Prueba de Instalacin 3.2 Herramientas 4. Recursos 4.1 Roles 4.2 Sistema 5. Projecto de Milestones 6. Deliverables 6.1 Modelo de Prueba 6.2 Pruebas de Logs 6.3 Reportes de Defecto Apndice A Tareas de Proyecto 4 4 4 4 5 5 5 6 6 7 8 10 11 13 15 17 18 19 22 23 24 25 25 26 28 28 28 28 28 29
Confidencial
Tera.LOC, 2012
Pgina 3
Plan de Pruebas
1.
1.1
Introduccin
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 ejemplo, Unidad, Integracin, o Sistema y los tipos de pruebas por 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.]
Confidencial
Tera.LOC, 2012
Pgina 4
1.4
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.] Creado o Disponible x
Si Si Si Si Si Si Si Si Si Si Si No No No No No No No No No No No
Documento (y version / fecha) Especificacin de Requerimientos Especificaciones Funcionales Reportes de Caso de Uso Plan del Proyecto Especificaciones de Diseo Prototipo Manuales de Usuario Modelo o Flujo del Negocio Modelo o Flujo de Datos Funciones y Reglas del Negocio Evaluacin del Riesgo del Proyecto o Negocio
Recibido o Revisado
Si Si Si Si Si Si Si Si Si Si Si No No No No No No No No No No No
Autor o Recurso
Notas
2.
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." 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.
Confidencial
Tera.LOC, 2012
Pgina 5
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 3.1.1 Tipos de Prueba 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: Tcnica: [Asegure la funcin de los mtodos y de los procesos de acceso de base de datos correctamente y sin la corrupcin de datos.] [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: Consideraciones Especiales: [Todos los mtodos y procesos de acceso de base de datos funcionan segn lo diseado y sin ninguna corrupcin de los datos.] [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.]
Confidencial
Tera.LOC, 2012
Pgina 6
3.1.2
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:] [Asegure la funcionalidad apropiada del objetivo-de-prueba, incluyendo la navegacin, la entrada de datos, el proceso, y la recuperacin.] [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.]
Objetivo de Prueba:
Tcnica:
La tcnica require las herramientas siguientes: 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: Consideraciones Especiales:
[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 impacto la implementacin y la ejecucin de la prueba de funcin]
Confidencial
Tera.LOC, 2012
Pgina 7
3.1.3
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.] [Asegure la funcin apropiada de los procesos del objetivo-de-prueba y de fondo segn modelos y horario requeridos del negocio.] [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
Objetivo de Prueba: Tcnica:
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: 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.]
[Se han ejecutado todas las pruebas previstas. Se han tratado todos los defectos identificados.]
[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.]
Confidencial
Tera.LOC, 2012
Pgina 8
Confidencial
Tera.LOC, 2012
Pgina 9
3.1.4
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.] [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.] [La tcnica requiere las Herramientas de Automatizacin del script de prueba.] [La tcnica apoya la prueba de cada pantalla o ventana principal que ser usada extensamente por el usuario final.] [No todas las caractersticas para los objetos de costumbre y de terceros pueden ser alcanzadas.]
Objetivo de Prueba:
Herramientas requeridas Criterios de Terminacin: Consideraciones Especiales:
Confidencial
Tera.LOC, 2012
Pgina 10
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.] [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: La tcnica requiere las herramientas siguientes: Herramienta de automatizacin del script de prueba Una herramienta de perfil de funcionamiento de aplicacin, como Rational Quantify. Herramientas de monitoreo-instalacin (registro, disco duro, CPU, memoria y as sucesivamente) 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.]
Objetivo de Prueba:
Confidencial
Tera.LOC, 2012
Pgina 11
Consideraciones Especiales:
[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.]
Confidencial
Tera.LOC, 2012
Pgina 12
3.1.6
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.] [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.
Tcnica:
Herramientas Requeridas:
La tcnica requiere las herramientas siguientes: Herramienta de automatizacin del script de prueba Herramienta de control y calendarizacin de cargas de transaccin Herramientas de monitoreo-instalacin (registro, disco duro, CPU, memoria y as sucesivamente) 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.]
Confidencial
Tera.LOC, 2012
Pgina 13
[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.]
Confidencial
Tera.LOC, 2012
Pgina 14
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: La tcnica requiere las herramientas siguientes: Herramienta de automatizacin del script de prueba Herramienta de control y calendarizacin de cargas de transaccin Herramientas de monitoreo-instalacin (registro, disco duro, CPU, memoria y as sucesivamente) Herramientas de generacin de datos
Confidencial
Tera.LOC, 2012
Pgina 15
[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.] [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.]
Confidencial
Tera.LOC, 2012
Pgina 16
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:
La tcnica requiere las herramientas siguientes: Herramienta de automatizacin del script de prueba Herramienta de control y calendarizacin de cargas de transaccin Herramientas de monitoreo-instalacin (registro, disco duro, CPU, memoria y as sucesivamente) Herramientas de generacin de datos [Se han ejecutado todas las pruebas previstas y los lmites especificados del sistema son alcanzados o excedidso sin el software o fallas de software.] [Qu perodo de tiempo sera considerado un tiempo aceptable para las condiciones del alto volumen, segn lo observado arriba?]
Confidencial
Tera.LOC, 2012
Pgina 17
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:
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.
Tcnica:
Seguridad a nivel sistema: [Vea las consideraciones especiales abajo] [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.] [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.]
Confidencial
Tera.LOC, 2012
Pgina 18
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]
Confidencial
Tera.LOC, 2012
Pgina 19
Tcnica:
[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.]
Confidencial
Tera.LOC, 2012
Pgina 20
[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.]
Confidencial
Tera.LOC, 2012
Pgina 21
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.] [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.]
Tcnica:
[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.]
Confidencial
Tera.LOC, 2012
Pgina 22
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 [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.]
Tcnica:
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?]
Confidencial
Tera.LOC, 2012
Pgina 23
3.2 Herramientas Las herramientas siguientes sern empleadas para este proyecto: [Nota: Suprima o agregue los artculos como apropiados.] Herramienta 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 Vendor/In-house Versin
Confidencial
Tera.LOC, 2012
Pgina 24
4.
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
(nmero de los papeles a tiempo completo asignados)
Responsabilidades especficas or Comentarios
Manejador de Prueba, Manejador del Proyecto de Prueba
Proporciona cuidado de la gerencia. Responsabilidades: proporciona la direccin tcnica adquiere recursos apropiados proporcione la divulgacin de la gerencia
Diseador de Prueba
Identifica, da la prioridad, y pone a casos de la prueba en ejecucin. Responsabilidades: genere el plan de prueba genere el modelo de la prueba evale la eficacia del esfuerzo de la prueba
Probador
Ejecuta las pruebas. Responsabilidades: ejecute las pruebas resultados del registro recuprese de errores peticiones del cambio del documento
Confidencial
Tera.LOC, 2012
Pgina 25
Manejadorr del Sistema de Prueba
Asegura el ambiente de la prueba y se manejan y se mantienen los activos. Responsabilidades: administre el sistema de gerencia de la prueba instale y maneje el acceso a los sistemas de la prueba
Administrador de la Base de Datos, Manejador de la base de Datos
Asegura el ambiente de los datos de prueba (base de datos) y se manejan y se mantienen los activos. Responsabilidades: administre los datos de prueba (base de datos)
Diseador
Identifica y define las operaciones, las cualidades, y las asociaciones de las clases de la prueba. Responsabilidades: identifica y define las clases de la prueba identifica y define los paquetes de la prueba
Implementador
Instrumentos y pruebas de unidad que la prueba clasifica y los paquetes de la prueba. Responsabilidades: crea las clases y los paquetes de la prueba puestos en ejecucin en el modelo de la prueba
4.2
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

Confidencial
TBD TBD
Tera.LOC, 2012 Pgina 26
Nombre de la Base de Datos Prueba PC's cel Cliente Incluya los requisitos especiales de la configuracin Prueba de Repository Red or Subred Nombre del Servidor Prueba de Desarrollo de PC's
TBD
TBD
TBD TBD TBD
Confidencial
Tera.LOC, 2012
Pgina 27
5.
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 Prueba del Plan Diseo de Prueba Implementacin de Prueba Execucun de Prueba Evaluacin de Prueba
Esfuerzo
Fecha de Inicio
Fecha de Terminacin
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.]
Confidencial
Tera.LOC, 2012
Pgina 28
Apndice A
Prueba del Plan
Tareas de Proyecto
Debajo estn las tareas prueba-relacionadas:
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, 2012 Pgina 29
Confidencial
analice los defectos determnese si se han alcanzado los Triterios de la Terminacin de la Prueba y los Criterios de xito
Confidencial
Tera.LOC, 2012
Pgina 30

FORMATO APTI PlanPruebas

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

FORMATO APTI PlanPruebas

Загружено:

Авторское право:

Доступные форматы

Plan de Pruebas

<Nombre del Proyecto> Empresa

Criterios de Terminacin: Consideraciones Especiales:

Prueba de Ciclo de Negocio

Objetivo de Prueba: Tcnica:

Criterios de Terminacin: Consideraciones Especiales:

Prueba de Interfaz del Usuario

Herramientas requeridas Criterios de Terminacin: Consideraciones Especiales:

Criterios de Terminacin: Consideraciones Especiales:

Criterios de Terminacin: Consideraciones Especiales:

Responsabilidades especficas or Comentarios

Manejador de Prueba, Manejador del Proyecto de Prueba

Manejadorr del Sistema de Prueba

Administrador de la Base de Datos, Manejador de la base de Datos

Servidor de la Base de datos Red or Subred Nombre del Servidor

TBD TBD TBD

Debajo estn las tareas prueba-relacionadas:

Вам также может понравиться