Plan de Pruebas de Software PDF

Preview

Summary

Plantilla de análisis para prueba de software en general ...

Description

Pruebas de Verificación y Validación de Software

NRC:

Docente: ____________ Presentado por: Michael Daniel Murillo ID:

Colombia - Bogotá D.C 10/08/2019

Segunda Parte taller 1

Plan de Pruebas de Software [Segunda parte taller I] Fecha: 10/08/2019

Página 1

Segunda Parte taller 1

Tabla de contenido Historial de Versiones................................................................................................4 Información del Proyecto...........................................................................................4 Aprobaciones.............................................................................................................5 1. Introducción.........................................................................................................5 A.

Propósito.......................................................................................................5

B.

Resumen Ejecutivo.......................................................................................6

C.

Alcance de Proyecto.....................................................................................6

D.

Identificación Del Proyecto...........................................................................6

E.

Estrategia De Evolución Del Plan de Pruebas y Validación........................6

2. Revisiones de Estándares del prototipo.............................................................6 A.

Diseño de Software......................................................................................7

B.

Diseño de Componentes UML.....................................................................7

C.

Verificación de Calidad de Escritura de código Fuentes..............................7

D.

Verificación de Pruebas de Componentes...................................................7

3. Alcance de Elementos de las Pruebas...............................................................7 A.

Elementos de Pruebas.................................................................................7

B.

Nuevas Funcionalidades a Probar...............................................................8

C.

Pruebas de Regresión..................................................................................8

D.

Funcionalidades a No Probar.......................................................................8

E.

Enfoque de Pruebas (Estrategia).................................................................8

4. TIPOS DE PRUEBAS.........................................................................................8 A.

Prueba de Funcionalidad.............................................................................8

Página 2

Segunda Parte taller 1

B.

Prueba de Ciclo del Negocio........................................................................9

C.

Prueba de Interfaz de Usuario...................................................................10

D.

Prueba de Performance..............................................................................11

E.

Prueba de Carga........................................................................................12

F.

Prueba de Esfuerzo (stress, competencia por recursos, bajos recursos)....12

G.

Prueba de Volumen....................................................................................13

H.

Prueba de Seguridad y Control de Acceso................................................13

I.

Prueba de Fallas y Recuperación.................................................................14

J.

Prueba de Configuración...............................................................................14

K.

Prueba de Instalación.................................................................................14

L. Prueba de Documentos.................................................................................15 5. Criterios de Aceptación o Rechazo...................................................................16 A.

Criterios de Aceptación o Rechazo............................................................16

B.

Criterios de Suspensión.............................................................................16

C.

Criterios de Reanudación...........................................................................16

6. Entregables.......................................................................................................16 7. Recursos...........................................................................................................17 A.

Requerimientos de Entornos – Hardware..................................................17

B.

Requerimientos de Entornos – Software...................................................17

C.

Herramientas de Pruebas Requeridas.......................................................17

D.

Personal y Roles del equipo de Desarrollo................................................17

E.

Herramientas de Pruebas Requeridas.......................................................17

F.

Entrenamiento o Capacitaciones de Testing.................................................17

8. Planificación y Organización.............................................................................18 Página 3

Segunda Parte taller 1

A.

Procedimientos para las Pruebas..............................................................18

B.

Matriz de Responsabilidades.....................................................................18

C.

Cronograma................................................................................................18

D.

Premisas.....................................................................................................19

E.

Dependencias y Riesgos............................................................................19

9. Referencias.......................................................................................................20 10.

Glosario..........................................................................................................21

Historial de Versiones Fecha 11/08/2019

Versión 1.0

Autor Michael Murillo

Organización UNIMINUTO

Descripción Prueba de Verificación y Validación de Aplicación

Información del Proyecto Empresa / Organización Proyecto Fecha de preparación Cliente Patrocinador principal Gerente / Líder de Proyecto Gerente / Líder de Pruebas de Software

Página 4

Segunda Parte taller 1

Aprobaciones Nombre y Apellido

Cargo

Departamento u Organización

Fecha

Firma

1. Introducción A. Propósito Este Plan de Verificación para el proyecto “Formulario de Registro MVC” soporta los siguientes objetivos:  Identificar los componentes de software y documentación que deben ser sometidos al proceso de verificación y validación.  Enumerar los requerimientos que son recomendados para verificar, teniendo en cuenta las prioridades del cliente en cada fase.  Describir las estrategias de verificación que serán utilizadas para cada tipo de verificación, esto es, verificación unitaria, de integración, funcional y de sistema.  Identificar los recursos humanos y roles que serán necesarios en el proceso de verificación y validación. Página 5

Segunda Parte taller 1

B. Resumen Ejecutivo Resumen de todo el contenido del plan de Pruebas de Software, describe cuál es su propósito, establece si es un plan maestro o un plan detallado, identifica el alcance del plan de pruebas en relación con el plan de Proyecto de Software, restricciones (por ejemplo de recursos o presupuesto), alcance del esfuerzo de pruebas entre otros aspectos. C. Alcance de Proyecto Resumen de todo el contenido del plan de Pruebas de Software, describe cuál es su propósito, establece si es un plan maestro o un plan detallado, identifica el alcance que se obtendrá en todas las pruebas. D. Identificación Del Proyecto Resumen de todo el contenido del plan de Pruebas de Software, describe cuál es su propósito, establece si es un plan maestro o un plan detallado, identifica el alcance que se obtendrá en todas las pruebas. E. Estrategia De Evolución Del Plan de Pruebas y Validación Integran las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la evaluación correcta del proyecto donde se identifican las características y las evoluciones de los componentes que lo integra considerando las especificaciones que integran los requerimientos de recursos y requerimientos o que tengan implicaciones en la planificación.

2. Revisiones de Estándares del prototipo Clasifica los requerimientos con los procesos que se llevaran a cabo en la planificación del sistema teniendo acabo cada función del sistema para verificar los procesos que tendrá para hacer pruebas a cada uno de los componentes que integran el aplicativo A. Diseño de Software

Página 6

Segunda Parte taller 1

Análisis de requerimientos que resultan, desde el punto de vista del cliente, para el software a diseñar. En este contexto, el cliente prepara el así llamado pliego de condiciones. Donde cuenta que funciones se debe tener en cuenta para llevar a cabo una verificación y validación de lo que se espera en el desarrollo. B. Diseño de Componentes UML Elaboran un concepto, en el que se define con qué estructuras de programa, técnicas de programación y algoritmos los requerimientos analizados anteriormente se deben cumplir y programar con la metodología definida. C. Verificación de Calidad de Escritura de código Fuentes Es un proceso similar a la revisión de código de forma automática mediante herramientas. Estas herramientas comprueban el código fuente para garantizar que cumpla un conjunto de reglas predefinidas que garantizan buenas prácticas de programación. El uso de métodos analíticos para inspeccionar y revisar el código fuente para detectar errores es una práctica estándar de desarrollo de software. Las verificaciones de calidad de código surgen a partir de buenas prácticas recogidas en Marco de Desarrollo de Ingeniera de Software para cada lenguaje de programación, así como de los propios estándares de nomenclatura establecidos. D. Verificación de Pruebas de Componentes Listado de todos los módulos, componentes o elementos que se van a verificar y que cumplan lo establecido. Aquí van la lista de elementos que se esperan probar

3. Alcance de Elementos de las Pruebas A. Elementos de Pruebas Listado de todos los módulos, componentes o elementos que se van a probar. Si es de alto nivel, se listan las áreas funcionales (módulos o procesos que cubre el Testing), por otro lado, si es de un nivel detallado se listan los programas, unidades o módulos. B. Nuevas Funcionalidades a Probar Página 7

Segunda Parte taller 1

Es un listado de lo que se va a probar “Desde el Punto de vista del Usuario”. No es una descripción técnica del software sino sus características y funcionalidades. Se incluyen tanto las que son nuevas como las que se están modificando.

C. Pruebas de Regresión Listado de las funcionalidades no directamente involucradas en el desarrollo, pero cuyos componentes están siendo afectados y por ende deben probarse para asegurar que continúan funcionando adecuadamente. Al igual que en el punto anterior, se describen desde el punto de vista del usuario. D. Funcionalidades a No Probar Listado de las funcionalidades que NO se van a probar. Debe incluir información de las razones por las cuales no se van a probar y los riesgos que se están asumiendo. E. Enfoque de Pruebas (Estrategia) La Estrategia de Pruebas puede definirse como un documento aparte, o puede ser incluido dentro del Plan de Pruebas según su extensión. Aquí pueden definirse los tipos de pruebas a realizar (funcionales, de desempeño, de interfaces, no funcionales, etc.), requerimientos especiales de las pruebas, configuraciones a probar, subconjuntos de datos a considerar, nivel de pruebas de regresión, entre otros aspectos.

4. TIPOS DE PRUEBAS Esta sección presenta el enfoque recomendado para la verificación. Describe como se verificarán los elementos. Se indicarán las técnicas usadas y el criterio para saber cuándo una prueba se completó (criterio de aceptación). A. Prueba de Funcionalidad La prueba de funcionalidad se enfoca en requerimientos para verificar que se corresponden directamente a casos de usos o funciones y reglas del negocio. Los objetivos de estas pruebas son verificar la aceptación de los datos, el

Página 8

Segunda Parte taller 1

proceso, la recuperación y la implementación correcta de las reglas del negocio.

Objetivo de la prueba Asegurar la funcionalidad apropiada del objeto de prueba, incluyendo la navegación, entrada de datos, proceso y recuperación.

Técnica Ejecutar los casos de uso usando datos válidos y no válidos, para verificar lo siguiente: •

Se obtienen los resultados esperados cuando se usan datos válidos.

• Cuando se usan datos no válidos se despliegan los mensajes de error o advertencia apropiados. •

Se aplica apropiadamente cada regla del negocio.

Criterio de aceptación Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han sido debidamente identificados.

Consideraciones especiales Las pruebas de funcionalidad se verán afectadas si se retrasa el desarrollo de la implementación, o si el software entregado al área de verificación contiene muchos defectos que impidan las pruebas de las restantes funcionalidades. Dentro de lo posible se intentará realizar tests cases que sean automáticos, de manera de poder reproducirlos para realizar los tests de regresión. Esto no es fácil dado que se cuenta con una interfaz web que correrá sobre varios browsers de internet y el armado de tests cases automatizados es mas complejo que el manual. B. Prueba de Ciclo del Negocio Esta prueba debe simular las actividades realizadas en el proyecto en el tiempo. Se debe identificar un período, que puede ser un año, y se deben ejecutar las transacciones y actividades que ocurrirían en el período de un año. Esto incluye todos los ciclos diarios, semanales y mensuales y eventos que son sensibles a la fecha.

Página 9

Segunda Parte taller 1

En este caso, el único requerimiento que determina un ciclo diario es el resumen por día de las noticias comentadas. Si en el futuro surge algún otro requerimiento, se agregará debidamente.

Objetivo de la prueba Asegurar que la aplicación funciona de acuerdo a los requerimientos del negocio.

Técnica La prueba debe simular ciclos de negocios realizando lo siguiente: Las pruebas de funcionalidad se deben modificar para aumentar la cantidad de veces que se ejecuta cada función, simulando varios usuarios diferentes en un período determinado. Todas las funciones sensibles a la fecha se deben ejecutar con fechas válidas y no válidas o períodos de tiempo válidos y no válidos. Para cada prueba realizada verificar lo siguiente: •

Se obtienen los resultados esperados cuando se usan datos válidos.

• Cuando se usan datos no válidos se despliegan los mensajes de error o advertencia apropiados. •

Se aplica apropiadamente cada regla del negocio.

Criterio de aceptación Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han sido debidamente identificados.

Consideraciones especiales Las fechas del sistema y eventos requieren actividades de soporte especiales. Esto es, poder cambiar la fecha y hora del reloj de servidor donde correrá el sistema. C. Prueba de Interfaz de Usuario Esta prueba verifica que la interfaz de usuario proporcione al usuario el acceso y navegación a través de las funciones apropiadas. Además, asegura que los

Página 10

Segunda Parte taller 1

objetos presentes en la interfaz de usuario se muestren como se espera y conforme a los estándares establecidos por la empresa o de la industria.

Objetivo de la prueba Verificar que: la navegación a través de los elementos que se están probando reflejen las funciones del negocio y los requerimientos, incluyendo manejo de ventanas, campos y métodos de acceso; los objetos de las ventanas y características, como menúes, tamaño, posición, estado funcionen de acuerdo a los estándares.

Técnica Crear o modificar pruebas para cada ventana verificando la navegación y los estados de los objetos para cada ventana de la aplicación y cada objeto dentro de la ventana.

Criterio de aceptación Cada ventana ha sido verificada exitosamente siendo consistente con una versión de referencia o estándar establecido. D. Prueba de Performance En esta prueba se miden y evalúan los tiempos de respuesta, los tiempos de transacción y otros requerimientos sensitivos al tiempo. El objetivo de la prueba es verificar que se logren los requerimientos de performance. La prueba de performance es implementada y ejecutada para poner a punto los destinos de pruebas de performance como función de condiciones de trabajo o configuraciones de hardware. Para este sistema, las pruebas de performance son respecto a los tiempos de carga para las páginas.

Objetivo de la prueba Verificar la performance de determinadas transacciones o funciones de negocio bajo ciertas condiciones: •

condiciones de trabajo normales conocidas.

•

peores casos de condiciones de trabajo conocidas.

Página 11

Segunda Parte taller 1

Técnica • Levantar el servidor ASP en la plataforma Azure utilizando la cuenta de developer. Luego utilizar el software OpenSTA para realizar las pruebas de tiempos de respuesta en las paginas del portal Web.

Criterio de aceptación Las paginas mas importantes (las de los Casos de Uso mas prioritarios) tienen un tiempo de respuesta aceptable según los requerimientos no funcionales. E.

Prueba de Carga

Objetivo de la prueba Verificar que el sistema responderá adecuadamente bajo condiciones de carga importantes que simulen lo más realista posible un escenario real al que se podría enfrentar el sistema en producción. El objetivo es determinar la cantidad más razonable de usuarios que puede soportar un nodo, para luego extrapolar a varios nodos simultáneamente.

Técnica • Levantar el servidor ASP en la plataforma Azure utilizando la cuenta de developer. • Luego utilizar el software OpenSTA para realizar las pruebas de carga simulando un uso racional en las acciones de los usuarios, por ejemplo, un 60% de los usuarios solo ingresara a la portada sin registrarse. Un 20% se registrara y mirará su portada personalizada. Un 10% se registrara, realizará búsquedas y verá algunas noticias y un 10% se registrará y subirá alguna noticia. • Luego incrementar el numero de usuarios manteniendo la proporción de las clases de equivalencia

Criterio de aceptación El objetivo de la prueba es determinar la carga de usuarios mas común que puede soportar un único nodo, por l...