El plan de pruebas puede sufrir cambios que le permitan
adaptarse mejor a la evolución del proyecto. Estos cambios, en caso de que sean
aprobados, deben estar claramente especificados en un documento anexo al plan
original, así como la causa de los mismos y deberán estar firmados por todos
los miembros del equipo, incluidos los líderes de otras áreas ajenas a Pruebas.
Todos los miembros del equipo deben conocer su contenido
y mantenerlo presente a lo largo del ciclo de vida del proyecto.
Es necesario determinar qué software se debe utilizar
para realizar cada prueba e indicar las herramientas a utilizar para cada una
de ellas.
Plan de Pruebas de Sistema
El propósito del plan de pruebas es reunir la información
necesaria para planear y controlar el esfuerzo de pruebas al sistema.
El documento debe contener:
·
Objetivos:
• Identificar los elementos que serán
considerados en las pruebas.
• Identificar el razonamiento para
realizar pruebas en ciertas áreas.
• Describir el enfoque de pruebas a
utilizar.
• Identificar los recursos requeridos y
proveer una estimación de esfuerzo para las pruebas.
• Enlistar los entregables del plan de
pruebas.
·
Propósito:
Aquí se debe de poner con que finalidad
se están haciendo las pruebas.
·
Alcance:
Una breve descripción del alcance de
este plan. Se describen los tipos de pruebas que se llevarán a cabo, así como
las exclusiones que sean necesarias aclarar.
·
Abreviaciones, definiciones y acrónimos:
En caso de ser necesario, incluir
términos, acrónimos y abreviaciones requeridas para interpretar correctamente
el plan.
·
Referencias
En esta sección se provee una lista de
todos los documentos referenciados en este Plan.
·
Generalidades
Esta subsección describe lo que contiene
el resto del documento y cómo está organizada la información.
Descripción de pruebas
·
TIPO
DE PRUEBA
Considerar la lista de que se anexa para
decidir las pruebas de sistema que se considerarán.
o
Prueba Funcional
Esta
prueba se enfoca e identifica que el sistema cumpla con los requerimientos
definidos, esta es una prueba de caja negra que se basa en los resultados
obtenidos a través de la interfaz gráfica.
o
Prueba de Interfaz de Usuario
Verifica
la interacción con el software, asegurando que el usuario cuenta con el acceso
y navegación adecuada para las funciones de la aplicación. Además revisa que
los objetos de interfaz gráfica, se comportan de manera adecuada y cumplen con
los estándares de la organización o de la industria.
o
Pruebas de rendimiento
Se
verifica el desempeño de la aplicación para cumplir con los requerimientos
establecidos, por ejemplo, tiempo de respuesta, número de transacciones
procesadas por unidad de tiempo.
o
Pruebas de carga
Se
verifica la funcionalidad del sistema, en diferentes situaciones de carga de
trabajo esperada o más allá del límite. Se verifica tiempo de respuesta, número
de transacciones procesadas, etc.
o
Pruebas de estrés
Se
verifica la funcionalidad del sistema bajo condiciones de recursos que no se
presentan de manera normal.
o
Pruebas de control de acceso y seguridad
Pruebas
de niveles de acceso a la aplicación, a fin de verificar que el nivel de acceso
es adecuado para los datos o funciones de negocio, según se requiera. Pruebas
de seguridad a nivel sistema que aseguren que sólo los usuarios autorizados
tienen acceso al sistema y son capaces de accesar la aplicación a través de los
canales apropiados.
o
Pruebas de falla y recuperación
Permiten
asegurar que el sistema es capaz de recuperarse ante una falla de software o
hardware con la consecuente pérdida de integridad en los datos.
o
Pruebas de configuración
Verifican
que la aplicación se comporta adecuadamente en diferentes plataformas de
hardware o software para las cuales fue realizada.
o
Pruebas de Instalación
Verifica
que la aplicación y sus actualizaciones sean instaladas adecuadamente.
·
CRITERIOS A SATISFACER
Indicar la tolerancia a fallas o
criterios para decidir si los productos son satisfactorios en esta prueba.
·
ID DEL COMPONENTE A PROBAR
En esta parte se debe de poner el nombre
del componente o componentes que se van a revesar en esta etapa de prueba.
·
CALENDARIZACIÓN
En este se indican las fechas de inicio
y fin de los eventos de prueba que contempla este plan.
·
RECURSOS DEL SISTEMA
Elementos para establecer el ambiente de
pruebas necesario.
·
HERRAMIENTAS
Agregar o eliminar herramientas de
pruebas conforme sea necesario.
·
RECURSOS A PROVEER POR EL CLIENTE
Se debe indicar recursos necesarios para
realizar las pruebas y que deben ser provistos por el cliente.
Procedimientos de las pruebas de software
Una vez que tengamos nuestro
plan de pruebas de sistema y que fijemos las pruebas que deban realizarse,
debemos plasmar el procedimiento que debe seguir cada una de éstas. Para
realizarlas se deben seguir ciertos pasos generales.
Tipos
de Pruebas
·
PRUEBAS UNITARIAS
Se comprueba la estructura interna de
cada una de las clases y se verifica la funcionalidad de cada método.
Procedimiento:
Diseñar guión de prueba con los casos de
prueba.
Cargar datos especificados en los casos
de prueba.
Ejecución dependiendo método.
Verificar condiciones asociadas al caso
de prueba mediante métodos assert.
Se evalúan fallos y errores.
·
PRUEBAS DE INTEGRACIÓN
Las Pruebas de Integración se basan en
los casos de prueba que verifican ante todo que cada elemento este
correctamente conectado al siguiente elemento.
Ascendente
Se debe organizar las clases o módulos
en forma de árbol con el fin de identificar los niveles, se comienza de los
módulos de abajo hasta la raíz.
Procedimiento:
Diseñar guión de prueba con los casos de
prueba.
Se combinan los módulos por niveles.
Se construye un conductor para coordinar
entrada y salida de los Test Cases.
Se sustituyen los conductores por los
módulos reales.
Pruebas de regresión.
Descendente
Se comienza por el módulo raíz y
continuamos hacia abajo por la jerarquía de control en profundidad y anchura.
Procedimiento:
Diseñar guión de prueba con los casos de
prueba.
El módulo de control principal es
conductor de pruebas, se construyen resguardos para los módulos subordinados.
Se sustituyen los resguardos por las
clases reales.
Se prueba cada vez que se integra un
nuevo módulo hasta llegar a los nodos terminales.
·
PRUEBAS DE VALIDACIÓN
Se comparan los requerimientos del
sistema solicitados por el cliente con los resultados obtenidos con el software
terminado.
Procedimiento:
Generar un guion de casos de prueba.
Método de la caja negra.
Comprobar la facilidad y ergonomía en la
interfaz grafica del usuario.
·
PRUEBAS DEL SISTEMA
Se crea una simulación del sistema
operando en donde va a ser implementado, se realiza la última reflexión de los
beneficios al implementarlo tanto en software como en hardware.
Interfaces externas.
Volumen.
Funcionamiento.
Recuperación.
Seguridad.
Resistencia.
Rendimiento-Comportamiento.
Fiabilidad.
Documentación.
·
PRUEBAS DE ACEPTACIÓN
El usuario verifica que sea lo que
pidió.
El usuario aporta y especifica los casos
de prueba.
Valida los resultados obtenidos con los
esperados.
Se genera un reporte.
Guión de pruebas
En un guión de pruebas (también llamado script)
enlistamos todos los pasos que se deben seguir para realizar una serie de
pruebas (casos de prueba).
Se clasifican en:
·
Identificación de casos de prueba
En este guión se describen brevemente y
de manera muy general los casos de prueba identificados.
·
Casos de prueba de alto nivel
Con este guión se especifica cada uno de
los casos de prueba identificados previamente; se describen los actores
involucrados dentro de la prueba y las precondiciones que se deben cumplir para
que el caso pueda ser ejecutado.
·
Casos de prueba a detalle
Con este guión especificamos paso por
paso lo que se debe hacer para realizar la prueba descrita en la imagen
anterior; donde se indican las precondiciones que se deben cumplir y los
resultados esperados después de ejecutar la prueba, se especifica también a la
persona que desarrolló el caso de prueba, la fecha y el artefacto o también
podemos encontrar guiones de prueba en los cuales lo único que existe es
código. Ese script nos servirá para realizar una prueba de caja blanca (probar
código).
Play Blackjack at a Casino! - Microgaming - Microgaming
ResponderEliminarA classic card deccasino game is a wooricasinos.info thrilling and engaging blackjack game at goyangfc Microgaming. This fun game is now https://vannienailor4166blog.blogspot.com/ available for your device! poormansguidetocasinogambling