Pruebas de mainframe: tutorial completo

Antes de aprender los conceptos de pruebas de mainframe, aprendamos

¿Qué es una computadora central?

El mainframe es un sistema informático de alto rendimiento y alta velocidad. Se utiliza para fines informáticos a mayor escala que requieren gran disponibilidad y seguridad. Se utiliza principalmente en sectores como finanzas, seguros, comercio minorista y otras áreas críticas donde se procesan grandes cantidades de datos varias veces.

Pruebas de mainframe

Pruebas de mainframe Es un proceso de prueba de aplicaciones y servicios de software basados en sistemas Mainframe. El propósito de las pruebas de mainframe es garantizar el rendimiento, la confiabilidad y la calidad de la aplicación o servicio de software mediante métodos de verificación y validación y verificar si está listo para implementarse.

Mientras realiza pruebas de Mainframe, el evaluador solo necesita conocer las navegaciones de las pantallas de CICS. Están diseñados a medida para aplicaciones específicas. Cualquier cambio realizado en el código en COBOL, JCL, etc., el evaluador no tiene que preocuparse por el emulador configurado en la máquina. Los cambios que funcionan en un emulador de terminal funcionarán en otros.

La aplicación Mainframe (también llamada lote de trabajo) se prueba con los casos de prueba desarrollados utilizando requisitos
Las pruebas de mainframe generalmente se realizan en el código implementado utilizando varias combinaciones de datos establecidas en el archivo de entrada.
Se puede acceder a las aplicaciones que se ejecutan en la computadora central a través del emulador de terminal. El emulador es el único software que debe instalarse en la máquina cliente.

Atributos del sistema central

Almacenamiento virtual
1. Es una técnica que permite a un procesador simular un almacenamiento principal que es mayor que la cantidad real de almacenamiento real.
2. Es una técnica para utilizar la memoria de forma eficaz para almacenar y ejecutar tareas de varios tamaños.
3. Utiliza el almacenamiento en disco como una extensión del almacenamiento real.
Multiprogramación
1. La computadora ejecuta más de un programa al mismo tiempo. Pero en un momento dado sólo un programa puede tener el control de la CPU.
2. Es una función proporcionada para hacer un uso eficiente de la CPU.
Procesamiento por lotes
1. Es una técnica mediante la cual cualquier tarea se realiza en unidades conocidas como trabajos.
2. Un trabajo puede hacer que uno o más programas se ejecuten en una secuencia.
3. El programador de trabajos toma una decisión sobre el orden en que se deben ejecutar los trabajos. Para maximizar el rendimiento promedio, los trabajos se programan según su prioridad y clase.
4. La información necesaria para el procesamiento por lotes se proporciona a través de JCL (LENGUAJE DE CONTROL DE TRABAJO). JCL describe el trabajo por lotes: programas, datos y recursos necesarios.
Tiempo compartido
1. En un sistema de tiempo compartido, cada usuario tiene acceso al sistema a través del dispositivo terminal. En lugar de enviar tareas programadas para su ejecución posterior, el usuario ingresa comandos que se procesan de inmediato.
2. De ahí que esto se denomine “Procesamiento Interactivo”. Permite al usuario interactuar directamente con la computadora.
3. El procesamiento de tiempo compartido se conoce como “Procesamiento en primer plano” y el procesamiento de trabajos por lotes se conoce como “Procesamiento en segundo plano”.
Spooling
1. SPOOLing significa Periférico simultáneo Operaciones en línea.
2. El dispositivo SPOOL se utiliza para almacenar la salida del programa/aplicación. La salida en cola se dirige a dispositivos de salida como una impresora (si es necesario).
3. Es una función que aprovecha las ventajas del almacenamiento en búfer para hacer un uso eficiente de los dispositivos de salida.

Clasificación de pruebas manuales en mainframe

Ordenador central Prueba Manualmente se puede clasificar en dos tipos:

1. Pruebas de trabajos por lotes –

El proceso de prueba implica ejecuciones de trabajos por lotes para la funcionalidad implementada en la versión actual.
El resultado de la prueba extraído de los archivos de salida y la base de datos se verifica y registra.

2. Pruebas en línea –

Las pruebas en línea se refieren a las pruebas de pantallas CICS que son similares a las pruebas de la página web.
Se podría cambiar la funcionalidad de las pantallas existentes o agregar nuevas pantallas.
Varias aplicaciones pueden tener pantallas de consulta y pantallas de actualización. Es necesario comprobar la funcionalidad de estas pantallas como parte de las pruebas en línea.

Cómo realizar pruebas de mainframe

El equipo de Negocios prepara los documentos de requisitos, que determinan cómo se modificará un elemento o proceso en particular en el ciclo de lanzamiento.
El equipo de pruebas y desarrollo recibe el documento de requisitos y determina cuántos procesos se verán afectados por el cambio. Por lo general, en una versión, solo el 20-25 % de la aplicación se ve afectada directamente por el requisito personalizado. El 75 % restante de la versión se destinará a las funciones estándar, como las pruebas de aplicaciones y procesos.
Por lo tanto, una aplicación Mainframe debe probarse en dos partes:
1. Requisitos de prueba – Probar la aplicación para la funcionalidad o el cambio mencionado en el documento de requisitos.
2. Integración de pruebas – Probar todo el proceso u otra aplicación que reciba o envíe datos a la aplicación afectada. Pruebas de regresión es el enfoque principal de esta actividad de prueba.

Herramientas de prueba de automatización de mainframe

A continuación se muestra la lista de herramientas que se pueden utilizar para mainframe. Pruebas de automatización.

REXX
Excel
QTP

Metodología en pruebas de mainframe

Consideremos un ejemplo: una compañía de seguros XYZ tiene un módulo de inscripción de miembros. Toma datos tanto de la pantalla de inscripción de miembros como de la inscripción fuera de línea. Como comentamos anteriormente, se necesitan dos enfoques para las pruebas de mainframe, las pruebas en línea y las pruebas por lotes.

Prueba en línea se realiza en la pantalla de inscripción de miembros. Al igual que una página web, la base de datos se valida con los datos ingresados a través de las pantallas.
Inscripción sin conexión Puede ser una inscripción en papel o en un sitio web de terceros. Los datos sin conexión (también denominados lotes) se ingresarán en la base de datos de la empresa a través de trabajos por lotes. Se prepara un archivo plano de entrada según el formato de datos prescrito y se envía a la secuencia de trabajos por lotes. Por lo tanto, para las pruebas de aplicaciones de mainframe podemos utilizar el siguiente enfoque.
El primer trabajo en la línea de trabajos por lotes valida los datos ingresados. Digamos, por ejemplo, caracteres especiales, alfabetos en campos solo numéricos, etc.
El segundo trabajo valida la coherencia de los datos en función de las condiciones comerciales. Por ejemplo, la inscripción de un niño no debe contener datos de dependientes, código postal del miembro (que no está disponible para el servicio del plan inscrito), etc.
El tercer trabajo modifica los datos en el formato que se puede ingresar en la base de datos. Por ejemplo, eliminar el nombre del plan (la base de datos almacenará solo la identificación del plan y el nombre del plan de seguro), agregar la fecha de ingreso, etc.
El cuarto trabajo carga los datos en la base de datos.
Pruebas de trabajos por lotes se realiza en este proceso en dos fases –
Cada trabajo se valida por separado y el
La integración entre los trabajos se valida proporcionando un archivo plano de entrada al primer trabajo y validando la base de datos. (Los resultados intermedios deben validarse para mayor precaución)

El siguiente es el método seguido para las pruebas de Mainframe:

Paso 1) Chantaje/Prueba de humo

El objetivo principal de esta etapa es validar si el código implementado se encuentra en el entorno de prueba adecuado. También se asegura de que no haya problemas críticos con el código.

Paso 2) Pruebas del sistema

A continuación se detallan los tipos de pruebas realizadas como parte de las pruebas del sistema.

Pruebas por lotes – Esta prueba se realizará validando los resultados de la prueba en los archivos de salida y los cambios de datos realizados por los trabajos por lotes bajo el alcance de la prueba y registrándolos.
Pruebas en línea – Esta prueba se realizará en la interfaz de la aplicación mainframe. Aquí se prueba la aplicación para verificar el campo de entrada correcto, como un plan de seguro, intereses sobre el plan, etc.
Pruebas de integración por lotes en línea – Esta prueba se realizará en los sistemas que tengan procesos por lotes y aplicación en línea. Se valida el flujo de datos y la interacción entre las pantallas en línea y los trabajos por lotes.
(Ejemplo para este tipo de prueba. – Considere una actualización de los detalles del plan, como el aumento de la tasa de interés. El cambio de interés se realiza en una pantalla de actualización y los detalles del saldo de las cuentas afectadas se modificarán solo mediante un trabajo por lotes nocturno. En este caso, las pruebas se realizarán validando la pantalla de detalles del plan y la ejecución del trabajo por lotes para actualizar todas las cuentas.
Prueba de base de datos – Las bases de datos donde se validan los datos de la aplicación mainframe (IMS, IDMS, DB2, VSAM/ISAM, conjuntos de datos secuenciales, GDG) para su diseño y almacenamiento de datos.

Paso 3) System Pruebas de integración

El objetivo principal de esta prueba es validar la funcionalidad de los sistemas que interactúan con el sistema bajo prueba.

Estos sistemas no se ven directamente afectados por los requisitos. Sin embargo, utilizan datos del sistema bajo prueba. Es importante probar la interfaz y los diferentes tipos de mensajes (como trabajo exitoso, trabajo fallido, base de datos actualizada, etc.) que pueden fluir entre los sistemas y las acciones resultantes tomadas por los sistemas individuales.

Los tipos de pruebas realizadas en esta etapa son

Pruebas por lotes
Pruebas en línea
En línea: pruebas de integración por lotes

Paso 4) Pruebas de regresión

Las pruebas de regresión son una fase común en cualquier tipo de proyecto de prueba. Esta prueba en Mainframes garantiza que los trabajos por lotes y las pantallas en línea que no interactúan directamente con el sistema bajo prueba (o que no entran en el alcance de los requisitos) no se vean afectados por la versión actual del proyecto.

Para que las pruebas de regresión sean efectivas, se debe seleccionar un conjunto particular de casos de prueba según su complejidad y se debe crear un banco de regresión (repositorio de casos de prueba). Este conjunto se debe actualizar siempre que se implemente una nueva funcionalidad en la versión.

Paso 5) Test de rendimiento

Esta prueba se realiza para identificar los cuellos de botella en áreas de alto impacto, como los datos frontales, la actualización de bases de datos en línea y para proyectar la escalabilidad de la aplicación.

Paso 6) Pruebas de seguridad

Esta prueba se realiza para evaluar qué tan bien está diseñada y desarrollada la aplicación para contrarrestar los ataques antiseguridad.

Se deben realizar dos pruebas de seguridad en el sistema: seguridad del mainframe y seguridad de la red.

Las características que deben probarse son

Integrity
Confidencialidad
Autorización
Autenticación
Disponibilidad

Pasos involucrados en las pruebas por lotes

Después de que el equipo de control de calidad reciba el paquete aprobado (el paquete contiene procedimientos, JCL, tarjetas de control, módulos, etc.), el evaluador debe obtener una vista previa y recuperar el contenido en PDS según sea necesario.
Convierte el JCL de producción o el JCL de desarrollo en JCL de control de calidad, también llamado CONFIGURACIÓN DE TRABAJO.
Copiar archivo de producción y preparar archivos de prueba.
Para cada funcionalidad, habrá una secuencia de trabajo definida. (Como se explica en el ejemplo en la sección Metodología en Mainframe). Los trabajos deben enviarse usando el comando SUB con los archivos de datos de prueba.
Verifique el archivo intermedio para identificar los motivos de los datos faltantes o erróneos.
Verifique el archivo de salida final, la base de datos y el Spool para validar los resultados de la prueba.
Si el trabajo falla, el spool tendrá el motivo del fracaso del trabajo. Solucione el error y vuelva a enviar el trabajo.

Informes de prueba – Defecto debe registrarse si el resultado real se desvía del esperado.

Pasos involucrados en las pruebas en línea

Seleccione la pantalla En línea en un entorno de prueba.
Pruebe cada campo para obtener datos aceptables.
Prueba el Escenario de prueba en la pantalla.
Verifique la base de datos para las actualizaciones de datos desde la pantalla en línea.

Informes de prueba: el defecto debe registrarse si el resultado real se desvía del esperado.

Pasos involucrados en línea: prueba de integración por lotes

Ejecute el trabajo en un Entorno de prueba y validar los datos en las pantallas online.
Actualice los datos en las pantallas en línea y valide si el trabajo por lotes se ejecuta correctamente con los datos actualizados.

Comandos utilizados en pruebas de mainframe

ENVIAR: envíe un trabajo en segundo plano.
CANCELAR: cancela el trabajo en segundo plano.
ASIGNAR: asignar un conjunto de datos
COPIAR: copiar un conjunto de datos
RENAME – Cambiar el nombre del conjunto de datos
ELIMINAR – Eliminar conjunto de datos
ESCANEO DE TRABAJO –Para vincular el JCL con el programa, bibliotecas, archivo, etc. sin ejecutarlo.

Hay muchos otros comandos que se utilizan cuando es necesario, pero no son tan frecuentes.

Requisitos previos para iniciar las pruebas de mainframe

Los detalles básicos necesarios para las pruebas de mainframe son:

ID de inicio de sesión y contraseña para iniciar sesión en la aplicación.
Breves conocimientos sobre comandos ISPF.
Nombres de los archivos, calificador de archivos y sus tipos.

Antes de comenzar las pruebas de mainframe, se deben verificar los siguientes aspectos.

Trabajos
1. Realice un escaneo del trabajo (Comando – JOBSCAN) para verificar si hay errores antes de ejecutarlo.
2. El parámetro CLASS debe apuntar a la clase de prueba.
3. Dirija la salida del trabajo al spool o a JHS o según sea necesario mediante el parámetro MSGCLASS.
4. Redirigir el correo electrónico en el trabajo a la cola de impresión o a un ID de correo de prueba.
5. Comente los pasos de FTP para la prueba inicial y luego apunte el trabajo a un servidor de prueba.
6. En caso de que se genere un IMR (registro de gestión de incidentes) en el trabajo, simplemente agregue el comentario "PROPÓSITO DE LA PRUEBA" en el trabajo o en la tarjeta de parámetros.
7. Todas las bibliotecas de producción en el trabajo deben cambiarse y apuntar a bibliotecas de prueba.
8. El trabajo no debe dejarse desatendido.
9. Para evitar que el trabajo se ejecute en un bucle infinito en caso de cualquier error, se debe agregar el parámetro TIME con el tiempo especificado.
10. Guarde el resultado del trabajo, incluido el spool. El spool se puede guardar usando XDC.

Archive
1. Cree un archivo de prueba del tamaño necesario únicamente. Utilice GDG (grupos de datos de generación: archivos con el mismo nombre pero con números de versión secuenciales: MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00, etc.) cuando sea necesario almacenar datos en archivos consecutivos con el mismo nombre.
2. El parámetro DISP (Disposición: describe el sistema para mantener o eliminar el conjunto de datos después de la terminación normal o anormal del paso o trabajo) para los archivos debe codificarse correctamente.
3. Asegúrese de que todos los archivos utilizados para la ejecución del trabajo estén guardados y cerrados correctamente para evitar que el trabajo entre en ESPERA.
4. Mientras realiza pruebas con GDG, asegúrese de apuntar a la versión correcta.
Database
1. Mientras ejecuta el trabajo o programa en línea, asegúrese de que no se inserten, actualicen o eliminen datos no deseados.
2. Además, asegúrese de que se utilice la región DB2 correcta para las pruebas.
Casos de prueba
1. Siempre pruebe las condiciones límite como: archivo vacío, procesamiento del primer registro, procesamiento del último registro, etc.
2. Incluya siempre condiciones de prueba tanto positivas como negativas.
3. En caso de que se utilicen procedimientos estándar en el programa, como reinicio del punto de control, módulos Abend, archivos de control, etc., incluya casos de prueba para validar si los módulos se han utilizado correctamente.
Datos de prueba
1. La configuración de los datos de prueba debe realizarse antes del comienzo de la prueba.
2. Nunca modifique los datos de la región de prueba sin notificarlo. Es posible que haya otros equipos trabajando con los mismos datos y su prueba fallaría.
3. En caso de que los archivos de producción sean necesarios durante la ejecución, se debe obtener la autorización adecuada antes de copiarlos o utilizarlos.

Mejores Prácticas

En caso de ejecutar un trabajo por lotes, MAX CC 0 es un indicador de que el trabajo se ejecutó correctamente. No significa que la funcionalidad esté funcionando bien. El trabajo se ejecutará correctamente incluso cuando la salida esté vacía o no según lo esperado. Por lo tanto, siempre se espera verificar todos los resultados antes de declarar que el trabajo fue exitoso.
Siempre es una buena práctica realizar un ensayo del trabajo bajo prueba. El ensayo se realiza con archivos de entrada vacíos. Este proceso debe seguirse para los trabajos que se ven afectados por los cambios realizados para el ciclo de prueba.
Antes de que comience el ciclo de prueba, la configuración del trabajo de prueba debe realizarse con mucha antelación. Esto ayudará a descubrir cualquier error de JCL con anticipación y, por lo tanto, ahorrará tiempo durante la ejecución.
Al acceder a las tablas de DB2 a través de SPUFI (opción en el emulador para acceder a las tablas de DB2), configure siempre la confirmación automática como "NO" para evitar actualizaciones accidentales.
La disponibilidad de datos de prueba es el principal desafío en las pruebas por lotes. Los datos requeridos deben crearse mucho antes del ciclo de prueba y se debe verificar que estén completos.
Algunas transacciones en línea y trabajos por lotes pueden escribir datos en MQ (Message Queue) para transmitir datos a otras aplicaciones. Si los datos no son válidos, puede desactivar/detener las MQ, lo que afectará todo el proceso de prueba. Es una buena práctica comprobar que los MQ funcionan bien después de las pruebas.

Desafíos y solución de problemas de pruebas de mainframe

Desafíos	Nuevo enfoque
Requisitos incompletos/poco claros Es posible que haya acceso al manual del usuario/guía de capacitación, pero esos no son los mismos que los requisitos documentados.	Los evaluadores deben participar en el SDLC desde la fase de requisitos en adelante. Esto ayudará a verificar si los requisitos son comprobables.
Configuración/identificación de datos Puede haber situaciones en las que los datos existentes deban reutilizarse según el requisito. A veces resulta difícil identificar los datos necesarios a partir de los datos existentes.	Para la configuración de datos, se pueden utilizar herramientas locales según la necesidad. Para recuperar datos existentes, las consultas deben crearse con anticipación. En caso de cualquier dificultad, se puede enviar una solicitud al equipo de gestión de datos para crear o clonar los datos necesarios.
Configuración del trabajo Una vez que los trabajos se recuperan en PDS, es necesario configurar el trabajo en la región de control de calidad. Para que los trabajos no se envíen con un calificador de producción o un detalle de ruta.	Se deben utilizar herramientas de configuración del trabajo para superar los errores humanos cometidos durante la configuración.
Solicitud ad hoc Puede haber situaciones en las que sea necesario admitir pruebas de un extremo a otro debido a un problema en las aplicaciones ascendentes o descendentes. Estas solicitudes aumentan el tiempo y el esfuerzo en el ciclo de ejecución.	El uso de scripts de automatización, scripts de regresión y scripts de esqueleto podría ayudar a reducir el tiempo y el esfuerzo.
Lanzamientos puntuales para cambios de alcance Puede haber una situación en la que el impacto del código cambie completamente la apariencia del sistema. Esto puede requerir un cambio en los casos de prueba, scripts y datos.	Se debe implementar un proceso de gestión de cambios de alcance y un análisis de impacto.

Abends comunes encontrados

S001 – Se produjo un error de E/S.
Motivo: lectura al final del archivo, error de longitud del archivo, intento de escribir en un archivo de solo lectura.
S002 – Registro de E/S no válido.
Motivo: intento de escribir un registro de mayor longitud que el registro.
S004 – Se produjo un error durante la APERTURA.
Motivo: DCB no válido
S013: Error al abrir un conjunto de datos.
Motivo: el miembro de PDS no existe, la longitud del registro en el programa no coincide con la longitud del registro real.
S0C1 – Operaexcepción de ción
Motivo: no se puede abrir el archivo, falta la tarjeta DD
S0C4 – Excepción de protección/violación de almacenamiento
Motivo: intentar acceder al almacenamiento que no está disponible para el programa.
S0C7 – Excepción de verificación de programa – Datos
Motivo: cambio en el diseño del registro o del archivo.
Sx22 – El trabajo ha sido cancelado
S222 – Trabajo cancelado por el usuario sin volcado.
S322: El tiempo del trabajo o del paso excedió el límite especificado, o el programa está en un bucle o el parámetro de tiempo es insuficiente.
S522 – Tiempo de espera de sesión TSO.
S806 – No se puede vincular o cargar.
Motivo: la identificación del trabajo no puede encontrar el módulo de carga especificado.
S80A: no hay suficiente almacenamiento virtual para satisfacer las solicitudes GETMAIN o FREEMAIN.
S913 – Intentando acceder al conjunto de datos para el cual el usuario no está autorizado.
Sx37: no se puede asignar suficiente almacenamiento al conjunto de datos.

Asistente de errores: una herramienta muy popular para obtener información detallada sobre varios tipos de terminaciones anómalas.

Problema común que se enfrenta durante las pruebas de mainframe

El trabajo termina – Para completar exitosamente el trabajo, debe verificar los datos, el archivo de entrada y los módulos presentes en la ubicación específica o no. Las interrupciones pueden ocurrir debido a múltiples razones, siendo la más común: datos no válidos, campo de entrada incorrecto, falta de coincidencia de fechas, problemas ambientales, etc.
Archivo de salida vacío–Aunque el trabajo puede ejecutarse correctamente (MaxCC 0), es posible que el resultado no sea el esperado. Entonces, antes de pasar cualquier caso de prueba, el evaluador debe asegurarse de que la salida tenga una verificación cruzada. Sólo entonces continúa.
Archivo de entrada vacío – En algunas aplicaciones, los archivos se recibirán de los procesos anteriores. Antes de utilizar el archivo recibido para probar la aplicación actual, los datos deben verificarse de forma cruzada para evitar una nueva ejecución y reelaboración.

Resumen

Las pruebas de mainframe son como cualquier otro procedimiento de prueba que comienza con la recopilación de requisitos, el diseño de la prueba, la ejecución de la prueba y el informe de resultados.
Para probar la aplicación de forma eficaz, el evaluador debe participar en reuniones de diseño programadas por los equipos comerciales y de desarrollo.
Es obligatorio que el evaluador se acostumbre a las distintas funciones de prueba del mainframe. Como navegación en pantalla, creación de archivos y PDS, guardar resultados de pruebas, etc. antes de que comience el ciclo de prueba.
Las pruebas de aplicaciones de mainframe son un proceso que requiere tiempo. Se debe seguir un programa de pruebas claro para el diseño de las pruebas, la configuración de los datos y la ejecución.
Las pruebas por lotes y en línea deben realizarse de manera efectiva sin perder ninguna funcionalidad mencionada en el documento de requisitos, y no Caso de prueba debería salvarse.