P. 1
PLAN DE PRUEBAS

PLAN DE PRUEBAS

|Views: 5.954|Likes:
Publicado porAdrianAnex

More info:

Published by: AdrianAnex on Apr 05, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

11/10/2015

pdf

text

original

ESTRUCTURA Y ELEMENTOS DE UN PLAN DE PRUEBAS (Borrador) Preparado por Adrián Anex M – Dirección de Calidad

INTRODUCCIÓN Las pruebas de software se aplican como una etapa más del proceso de desarrollo de software, su objetivo es asegurar que este cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. Generalmente las pruebas se apoyan en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de prueba. “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. Incluye identificación del plan de acción y fecha del plan, el alcance que es el Tipo de prueba y las propiedades/elementos del software a ser probado, los ítems a probar que son los elementos a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan.”
Un plan de pruebas está constituido por un conjunto de pruebas. Cada prueba debe:
• • • •

Dejar claro qué tipo de propiedades se quieren probar (corrección, robustez, fiabilidad, usabilidad,...). Dejar claro cómo se mide el resultado. Especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta). Definir cuál es el resultado que se espera (identificación, tolerancia,...) ¿Cómo se decide que el resultado es acorde con lo esperado?

Luego de culminadas las etapas de análisis, diseño y desarrollo se inicia la etapa de pruebas, en esta etapa lo recomendable es que el aplicativo se mantenga en un ambiente aislado o separado del ambiente de desarrollo o de producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los ambientes que existen en producción para asegurar su correcto funcionamiento en esa futura etapa Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica razonable antes de iniciar el proceso de prueba.

. Las pruebas sólo pueden encontrar los errores que buscan.Al probar hay que tener presente las siguientes máximas: • • Que usted no encuentre debilidades no quiere decir que no existan. Probar todo es lisa y llanamente imposible. Así. Observabilidad: Deben existir formas de conocer las operaciones que esta realizando el software Controlabilidad: Las salidas del software deben depender únicamente de los datos de entrada. como estructural y en el código. Las pruebas pueden encontrar fallos. Una prueba tiene éxito si encuentra un error o defecto. • • • • Tenga en consideración Para que un software sea adecuado a las pruebas debe cumplir los siguientes requisitos: • • • • • • • Operatividad: El fallo debido a un error no debe interferir con las pruebas posteriores. no dando lugar a aleatoriedades. Por esto es tan importante un buen diseño de pruebas. Descomposición: Deben estar estructurado de tal forma que puedan aislarse los problemas en componentes simples (modularidad) Simplicidad: Tanto funcional. debe resolverse antes. tenga por seguro que la encontrará el usuario. Estabilidad: Es recomendable que los cambios no interfieran en la evolución del plan de pruebas. y cada versión debería contener una agenda para actualizaciones subsiguientes del plan. Si usted no encuentra una debilidad. pero jamás demostrar que no los hay. Facilidad de comprensión: Cuanta mas información contenga el código o la documentación técnica adjunta mas fácilmente se desarrollaran las prueba Evolución del Plan A medida que el proyecto evolucione este documento debe ser actualizado periódicamente para reflejar las situaciones desarrolladas. cada versión del plan debería ser remplazada por el cambio de control.

No debe ser redundante. 1.4.3..Configuración del ambiente de pruebas.Estado del plan de pruebas Explicita las condiciones bajo las cuales. Al corregirse los defectos.Alcance Indica el tipo de prueba y las propiedades / elementos de la aplicación a ser probada. el proceso de prueba previsto por el plan puede continuar. En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado.. si es muy compleja a lo mejor no sabemos lo que ha fallado 1. Si ya funciona. Finalizado.. Este debe ser igual o muy similar al ambiente de producción donde se pueda evaluar al sistema implementado. Si es muy sencilla no aporta nada. no lo probamos más.2. el plan de ser: Suspendido. Si tenemos donde elegir. 1.1. 1. No debería ser ni demasiado sencilla ni demasiado compleja. patrón y/o herramientas a utilizarse en el diseño de los casos de prueba 1. mejor.1 ESTRUCTURA DEL PLAN DE PRUEBAS Este capítulo presenta los componentes que estructuran este marco y sirve como una guía para la preparación de cualquier Plan de Pruebas Características de una buena prueba • • • • Ha de tener una alta probabilidad de encontrar un fallo. de manera equivalente. bitácora de pruebas.5. El primer factor que hay que tener en consideración es el ambiente de pruebas. por ejemplo especificación de pruebas. ya que puede ser necesario repetir algunas pruebas.Estrategia de prueba La estrategia de prueba que el producto que se implementando cumpla con los requerimientos de la lógica del negocio que el GEC ha explicitado en su contrato de servicio. casos de prueba. 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. elegimos la mejor. Repetido. Debe ser la “mejor de la cosecha”. Describe la técnica. Cuanto más. 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. registro de errores . pero debe explicitarse a partir de qué punto.

seguridad.. el software de sistemas (por ej.1. 1.Manejo de riesgos Explicita los riesgos del plan.8. .10.Descripción de Requerimientos. También se indican cualquier requerimiento especial del proceso: actualización de licencias. 1. incluyendo las características del hardware.Calendario Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. La sección incluye un estimado de los recursos humanos necesarios para el proceso. así como la colocación específica del software a probar (por ej. tiempo en la máquina del ambiente.6. Cualquier requerimiento no incluido en esta lista estará fuera del alcance de las pruebas.11. el líder proyecto y el Director de Desarrollo e Internet. el sistema de operación).. cualquier otro software necesario para llevar a cabo las pruebas.Aprobación del Plan. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo..12. El Plan de Pruebas debe ser revisado por todos las partes responsables de su ejecución y aprobado por el equipo de prueba. 1. 1.7. Esta sección del Plan de Pruebas contiene una lista de todos los requerimientos que serán probados.Procedimientos especiales Identifica las tareas necesarias para preparar y ejecutar las pruebas.9. así como cualquier habilidad especial que se requiera... 1. las acciones mitigantes y de contingencia.Responsables y la matriz de responsabilidad Especifica quién es el responsable de cada una de las tareas previstas en el plan. 1...Recursos Especifica las propiedades necesarias y deseables del ambiente de prueba. espacio de oficina.

2 CASOS DE PRUEBA Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba. Los casos de prueba nos permitirán probar todas las funcionalidades del sistema. Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una primera barrida de pruebas y con esto también podremos realizar nuestro cronograma y plan de pruebas. En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores. Módulo a probar Descripción del caso Pre-requisitos Data necesaria (valores a ingresar) Pasos o secuencia lógica Resultado esperado (correcto o incorrecto) Resultado obtenido Observaciones o comentarios Analista de Pruebas (responsable de las pruebas) Fecha de Ejecución Estado (concluido. Las combinaciones de casos de prueba podrían ser prácticamente infinitas. los casos de prueba deben definir los datos de entrada a utilizar. pendiente. en proceso) Ejemplo: Id Caso Modulo a probar Descripción del de caso prueba CP001 Inscripción de Validar que un cursos alumno moroso (biblioteca o financiero no pueda inscribir ramos) Validar que el alumno pueda inscribir asignaturas inherentes a su Pre requisitos Fecha de la Comentarios Estado prueba a la prueba dd/mm/aa Pendiente Debe existir el alumno Debe existir la carrera Debe existir la malla y los prerrequisitos . el proceso que debemos seguir en el sistema y el resultado esperado. Estructura para casos de prueba • • • • • • • • • • • • Identificador de caso de prueba. sin embargo es importante tener buen criterio a la hora de desarrollarlos.

Carga masiva de datos (ficha prospectos) 8. Usabilidad Unitarias Funcionalidad. • Determinar si la aplicación requiere modificaciones para que cumpla con los objetivos anteriores.. De huella de auditoría 3. Validar que un alumno no pueda inscribir ramos que no tenga los prerrequisitos aprobados Validar que el alumno inscriba un número mínimo de asignaturas (Créditos) 3 ESQUEMA GENERAL DE LAS PRUEBAS Las pruebas se harán en las siguientes categorías: 1.1.2 Pruebas unitarias .Pruebas de usabilidad Estas pruebas están orientadas a probar la usabilidad del sistema. 4. Recuperación frente a una caída 9. con los sistemas en producción 7. 2. Rendimiento (simulación de matrícula) 6. de acuerdo a los procesos de negocios vigentes Prueba de demanda “on line” (por ejemplo inscripción de asignaturas (cursos) 5. En nuestro caso. ubican rápidamente la función que desean ejecutar. Integración. 3. los objetivos principales serán: • Determinar si los usuarios pueden utilizar las distintas funcionalidades del sistema sin mayores complicaciones.carrera. Robutez 11. • Determinar si la interfaz es lo suficientemente intuitiva tanto para usuarios que tienen experiencia como para aquellos que no la tienen. Esto se refiere a probar la facilidad con lo cual los usuarios de una aplicación la pueden operar. 3. es decir. Aceptación 12. Seguridad 10.

su objetivo será encontrar posibles debilidades en e sistema bajo prueba 3.3 Pruebas funcionales Se denominan pruebas funcionales a las pruebas de software que tienen por objetivo probar que el sistema implementado cumpla con las funciones específicas para los cuales han sido creado. A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra.Pretenden probar que los fragmentos individuales (unidades) que forman el sistema cumplen las especificaciones y tienen el comportamiento esperado. Generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar. o cuánta memoria consume. Típicamente nos puede preocupar cuánto tiempo le lleva al sistema procesar tantos datos.4 Prueba de demanda “on line” (por ejemplo inscripción de asignaturas (cursos) 3. ya que el analistas de pruebas.. básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida. es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales. o cuántos datos transfiere por un canal de comunicaciones.5 Rendimiento ( por ejemplo: simulación de matrícula) A veces es importante el tiempo de respuesta. Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del usuario. 3.Prueba de integración . posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional. al duplicarse el volumen de datos de entrada). Generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos. a diferencia del analista de pruebas que tiene más bien una misión crítica. El analista de pruebas debe dar fuerza a las pruebas funcionales y más aún a las de robustez. enfocados básicamente al negocio. Para todos estos parámetros suele ser importante conocer cómo evolucionan al variar la dimensión del problema (por ejemplo. 3. esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción. esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas. u otros parámetros de rendimiento. o cuánto espacio en disco utiliza.6. no enfocan su atención a como se generan las respuestas del sistema.

Se prueba la capacidad del sistema para salir de situaciones embarazosas provocadas por errores en el suministro de datos. sobre el sistema completo. y buscan una cobertura de la especificación de requisitos y del manual del usuario. etc. aplicaciones web. aplicaciones cliente/servidor.9 Seguridad Se valida la funcionalidad del aplicativo para proveer una estructura de permisos y acceso según sea el perfil del usuario 3.8 Recuperación frente a caídas 3. Determina que el sistema cumple con lo deseado y se obtiene la conformidad del cliente. Estas pruebas las realiza el cliente. y si cumplen con la funcionalidad establecida 3. Comprueban la correcta unión de los componentes entre sí a través de sus interfaces. estas ‘partes’ pueden ser módulos.10 Prueba de robustez Determinan la capacidad del aplicativo para no soportar entradas incorrectas. en particular cuando la interfaz es humana 3.7 Carga masiva de datos (por ejemplo prospectos) 3. Son básicamente pruebas funcionales.Las pruebas de integraciónse refieren a la prueba o pruebas de todos los elementos unitarios. aplicaciones individuales. Se realizan en el ámbito una vez que se han aprobado las pruebas unitarias. . Estas pruebas son importantes en sistemas con una interfaz al exterior. que comprueban la compatibilidad y funcionalidad de los interfaces entre las distintas ‘partes’ que componen un sistema.11 Pruebas de Aceptación Son las que harán de acuerdo a los criterios de aceptación.

4. se tendrán los siguientes atributos por cada prueba realizada: • Estado de la prueba • Número de la versión probada • Persona que realizó la prueba • Fecha y hora de la prueba • Notas y observaciones de la prueba Será responsabilidad del QA actualizar el estado de la prueba en los registros.1 Suite de pruebas La suite definirá los casos de prueba asociados a cada prueba. probados.4 ENTREGABLES 4. 4. En suma. probados condicionalmente o fallidos. Los resultados de las pruebas serán resumidos posteriormente antes de probar.3 Reportes de defectos y errores En la Intranet se almacenarán todos los resultados y defectos individuales y en conjunto de las pruebas realizadas . Los resultados de las pruebas serán guardados bajo un control de versiones.2 Registros de pruebas realizadas Servirá para identificar los casos de prueba y hacer seguimiento del estado de cada caso de prueba.

y con las características implícitas que se espera de todo software desarrollado profesionalmente. Error Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de escritura. Defecto Un defecto de software. Verificación La verificación del software es el proceso a través del cual se analiza y revisa que el software satisfaga los objetivos propuestos al inicio del desarrollo. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Referente a la programación una prueba de software. un proceso. es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora u otro dispositivo. condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. Por ejemplo. una acción humana que conduce a un resultado incorrecto. Calidad del software Concordancia con lo requisitos funcionales y de rendimiento explícitamente establecidos y con los estándares de desarrollo explícitamente documentados. un caso de prueba es utilizado por el analista para determinar si el requisito de una aplicación es parcial o completamente satisfactorio. Por ejemplo: Divisiones entre cero. Son utilizadas para identificar posibles fallos de implementación. en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. una definición de datos o un paso de procesamiento incorrectos en un programa. una mala interpretación de un requerimiento o de la funcionalidad de un método. los resultados se observan y registran para realizar una evolución de dicho proceso. Validación . Falla Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Es una tipo de manifestación del defecto en el sistema que se ejecuta.ANEXO-1 GLOSARIO Pruebas Es una actividad en la cual un sistema o uno de sus componentes se ejecutan para verificar el funcionamiento de un proceso. Caso de prueba Un conjunto de entradas.

• Test de Rendimiento Prueba orientada a determinar la capacidad de la solución de HW/SW en el escenario de producción esperado. coordinado de dos o más módulos • Test Funcional Prueba de usuario/cliente sobre funcionalidades desarrolladas. Test de Integración prueba que valida el funcionamiento desarrollados por separado. Test Unitario Prueba sobre componentes desarrollados individualmente. .El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->