Antes de aprender los conceptos de prueba de mainframe, aprendamos
¿Qué es un Mainframe?
El mainframe es un sistema informático de alto rendimiento y alta velocidad. Se utiliza para fines informáticos a mayor escala que requieren una gran disponibilidad y seguridad. Se utiliza principalmente en sectores como finanzas, seguros, comercio minorista y otras áreas críticas donde se procesan grandes datos varias veces.
Pruebas de mainframe
Mainframe Testing es un proceso de prueba de aplicaciones y servicios de software basados en Mainframe Systems. 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 las pruebas de Mainframe, el evaluador solo necesita conocer la navegación de las pantallas de CICS. Están hechos a medida para aplicaciones específicas. Cualquier cambio realizado en el código en COBOL, JCL, etc., el probador no tiene que preocuparse por la configuración del emulador en la máquina. Los cambios que funcionan en un emulador de terminal funcionarán en otros.
- La aplicación Mainframe (también denominada por lotes 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 el mainframe a través del emulador de terminal. El emulador es el único software que debe instalarse en la máquina cliente.
En este tutorial para principiantes, aprenderá:
- Atributos de mainframe
- Clasificación de pruebas manuales en mainframe
- Cómo hacer pruebas de mainframe
- Herramientas de prueba de automatización de mainframe
- Metodología en pruebas de mainframe
- Pasos involucrados en la prueba por lotes
- Pasos involucrados en las pruebas en línea
- Pasos involucrados en Online - Prueba de integración por lotes
- Comandos usados en pruebas de mainframe
- Requisitos previos para iniciar las pruebas de mainframe
- Mejores prácticas
- Desafíos y resolución de problemas de las pruebas de mainframe
- Abends comunes encontrados
- Problema común que se enfrenta durante las pruebas de mainframe
Atributos de mainframe
- Almacenamiento virtual
- Es una técnica que permite a un procesador simular un almacenamiento principal que es mayor que la cantidad real de almacenamiento real.
- Es una técnica para utilizar la memoria de forma eficaz para almacenar y ejecutar tareas de varios tamaños.
- Utiliza el almacenamiento en disco como una extensión del almacenamiento real.
- Multiprogramación
- La computadora ejecuta más de un programa al mismo tiempo. Pero en un momento dado, solo un programa puede controlar la CPU.
- Es una función que se proporciona para hacer un uso eficiente de la CPU.
- Procesamiento por lotes
- Es una técnica mediante la cual se logra cualquier tarea en unidades conocidas como trabajos.
- Un trabajo puede hacer que uno o más programas se ejecuten en una secuencia.
- El programador de trabajos toma una decisión sobre el orden en el que deben ejecutarse los trabajos. Para maximizar el rendimiento promedio, los trabajos se programan según su prioridad y clase.
- 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
- En un sistema de tiempo compartido, cada usuario tiene acceso al sistema a través del dispositivo terminal. En lugar de enviar trabajos que están programados para su ejecución posterior, el usuario ingresa comandos que se procesan inmediatamente.
- Por lo tanto, esto se denomina "procesamiento interactivo". Permite al usuario interactuar directamente con la computadora.
- 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
- SPOOLing significa Operaciones periféricas simultáneas en línea .
- El dispositivo SPOOL se utiliza para almacenar la salida de un programa / aplicación. La salida en cola se dirige a dispositivos de salida como una impresora (si es necesario).
- Es una instalación que aprovecha la ventaja del almacenamiento en búfer para hacer un uso eficiente de los dispositivos de salida.
Clasificación de pruebas manuales en mainframe
Las pruebas manuales de mainframe se pueden clasificar en dos tipos:
- Prueba de trabajo por lotes -
- El proceso de prueba implica la ejecución 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 verifican y registran.
- Pruebas en línea -
- La prueba en línea se refiere a la prueba de las pantallas CICS que es similar a la prueba de la página web.
- Se podría cambiar la funcionalidad de las pantallas existentes o se podrían agregar nuevas pantallas.
- Varias aplicaciones pueden tener pantallas de consulta y pantallas de actualización. La funcionalidad de estas pantallas debe verificarse como parte de las pruebas en línea.
Cómo hacer pruebas de mainframe
- El equipo comercial prepara los documentos de requisitos. Lo que determina cómo se modificará un artículo o proceso en particular en el ciclo de lanzamiento.
- El equipo de pruebas y el desarrollo reciben el documento de requisitos. Averiguarán 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 otro 75% del lanzamiento será para las funcionalidades listas para usar, como probar las aplicaciones y los procesos.
- Por lo tanto, una aplicación Mainframe debe probarse en dos partes:
- Prueba de requisitos : prueba de la aplicación para la funcionalidad o el cambio mencionado en el documento de requisitos.
- Prueba de integración : prueba de todo el proceso u otra aplicación que recibe o envía datos a la aplicación afectada. La prueba 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 las pruebas de automatización de mainframe.
- REXX
- Sobresalir
- 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.
- Las pruebas en línea se realizan 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.
- La inscripción fuera de línea puede ser en papel o en el sitio web de un tercero. Los datos sin conexión (también denominados por 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 alimenta a la secuencia de trabajos por lotes. Entonces, para las pruebas de aplicaciones de mainframe, podemos usar 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 de solo números, etc.
- El segundo trabajo valida la consistencia 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 a la base de datos. Por ejemplo, eliminar el nombre del plan (la base de datos almacenará solo el ID del plan y el nombre del plan de seguro), agregar la fecha de entrada, etc.
- El cuarto trabajo carga los datos en la base de datos.
- Las pruebas de trabajo por lotes se realizan 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) : Prueba de Shakedown / Smoke
El enfoque principal en esta etapa es validar si el código implementado se encuentra en el entorno de prueba correcto. También asegura que no haya problemas críticos con el código.
Paso 2) : Prueba del sistema
A continuación, se muestran los tipos de pruebas que se realizan como parte de las pruebas del sistema.
- Prueba 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 registrando los mismos.
- Pruebas en línea : estas pruebas se realizarán en la parte frontal de la aplicación del mainframe. Aquí se prueba la aplicación para el campo de entrada correcto como un plan de seguro, interés en el plan, etc.
- Prueba de integración por lotes en línea : esta prueba se realizará en los sistemas que tienen procesos por lotes y una 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 se realizará mediante la validación de la pantalla 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 los datos de la aplicación de mainframe (IMS, IDMS, DB2, VSAM / ISAM, conjuntos de datos secuenciales, GDG) se validan para su diseño y almacenamiento de datos.
Paso 3) : Prueba de integración del sistema
El propósito principal de esta prueba es validar la funcionalidad de los sistemas que interactúan con el sistema bajo prueba.
Estos sistemas no se ven afectados directamente 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 que se realizan en esta etapa son
- Prueba por lotes
- Pruebas en línea
- En línea: pruebas de integración por lotes
Paso 4) : prueba de regresión
La prueba de regresión es una fase común en cualquier tipo de proyecto de prueba. Esta prueba en Mainframes asegura que los trabajos por lotes y las pantallas en línea que no interactúan directamente con el sistema bajo prueba (o no entran en el alcance de los requisitos) no se ven afectados por la versión actual del proyecto.
Para tener pruebas de regresión efectivas, se debe seleccionar un conjunto particular de casos de prueba en función de su complejidad y se debe crear un banco de regresión (repositorio de casos de prueba). Este conjunto debe actualizarse cada vez que se implemente una nueva funcionalidad en la versión.
Paso 5) : prueba de rendimiento
Esta prueba se realiza para identificar los cuellos de botella en áreas de alto impacto, como los datos del front-end, la actualización de las bases de datos en línea y para proyectar la escalabilidad de la aplicación.
Paso 6) : Prueba de seguridad
Esta prueba se realiza para evaluar qué tan bien está diseñada y desarrollada la aplicación para contrarrestar los ataques contra la seguridad.
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
- Integridad
- Confidencialidad
- Autorización
- Autenticación
- Disponibilidad
Pasos involucrados en la prueba por lotes
- Una vez que el equipo de control de calidad recibe 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.
- Convierta el JCL de producción o el JCL de desarrollo en QA JCL, también denominado JOB SETUP.
- Copiando archivo de producción y preparando 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 la computadora central). Los trabajos deben enviarse usando el comando SUB con los archivos de datos de prueba.
- Verifique el archivo intermedio para identificar las razones de los datos faltantes o con errores.
- 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. Aborde el error y vuelva a enviar el trabajo.
Informe de prueba: el 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 los datos aceptables.
- Pruebe el escenario de prueba en la pantalla.
- Verifique la base de datos para las actualizaciones de datos desde la pantalla en línea.
Informe de prueba: el defecto debe registrarse si el resultado real se desvía del esperado.
Pasos involucrados en Online - Prueba de integración por lotes
- Ejecute el trabajo en un entorno de prueba y valide los datos en las pantallas en línea.
- Actualice los datos en las pantallas en línea y valide si el trabajo por lotes se ejecuta correctamente con los datos actualizados.
Comandos usados 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
- COPY: copia un conjunto de datos
- RENAME: cambiar el nombre del conjunto de datos
- BORRAR - Eliminar conjunto de datos
- EXPLORACIÓN 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.
- Breve conocimiento de los comandos ISPF.
- Nombres de los archivos, calificador de archivos y sus tipos.
Antes de comenzar las pruebas de mainframe, se deben verificar los aspectos siguientes.
- Trabajo
- Realice una exploración del trabajo (Comando - JOBSCAN) para comprobar si hay errores antes de ejecutarlo.
- El parámetro CLASS debe apuntar a la clase de prueba.
- Dirija la salida del trabajo a spool o JHS o según sea necesario utilizando el parámetro MSGCLASS.
- Vuelva a enrutar el correo electrónico en el trabajo para ponerlo en cola o un ID de correo de prueba.
- Comente los pasos de FTP para la prueba inicial y luego apunte el trabajo a un servidor de prueba.
- 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.
- Todas las bibliotecas de producción del trabajo deben cambiarse y apuntar a las bibliotecas de prueba.
- El trabajo no debe dejarse desatendido.
- 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.
- Guarde la salida del trabajo, incluido el carrete. El carrete se puede guardar usando XDC.
- Archivo
- Cree un archivo de prueba del tamaño necesario únicamente. Utilice GDG (Generation Data Groups - 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 para almacenar datos en archivos consecutivos con el mismo nombre.
- 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.
- Asegúrese de que todos los archivos utilizados para la ejecución del trabajo se guarden y se cierren correctamente para evitar que el trabajo entre en RETENCIÓN.
- Al realizar pruebas con GDG, asegúrese de que se apunta a la versión correcta.
- Base de datos
- Mientras ejecuta el trabajo o el programa en línea, asegúrese de que no se inserten, actualicen o eliminen datos no deseados.
- Además, asegúrese de que se utilice la región DB2 correcta para las pruebas.
- Casos de prueba
- Siempre pruebe las condiciones de límite como: archivo vacío, procesamiento del primer registro, procesamiento del último registro, etc.
- Incluya siempre las condiciones de prueba positivas y negativas.
- 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
- La configuración de los datos de prueba debe realizarse antes del comienzo de la prueba.
- Nunca modifique los datos en la región de prueba sin notificar. Puede haber otros equipos trabajando con los mismos datos y su prueba fallaría.
- 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 usarlos.
Mejores prácticas
- En caso de que se ejecute un trabajo por lotes, MAX CC 0 es un indicador de que el trabajo se ha ejecutado 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 las expectativas. Por lo tanto, siempre se espera verificar todas las salidas antes de declarar que el trabajo fue exitoso.
- Siempre es una buena práctica hacer un ensayo del trabajo bajo prueba. La ejecución en seco 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 por adelantado 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 los 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 deben verificarse para 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 deshabilitar / detener MQ, esto afectará a todo el proceso de prueba. Es una buena práctica comprobar que los MQ funcionan bien después de la prueba.
Desafíos y resolución de problemas de las pruebas de mainframe
| Desafíos | Acercarse |
| Requisitos incompletos / poco claros Es posible que haya acceso al manual del usuario / guía de capacitación, pero no son los mismos que los requisitos documentados. | Los probadores deben participar en el SDLC desde la fase de requisitos en adelante. Esto ayudará a verificar si los requisitos se pueden probar. |
| Configuración / identificación de datos Puede haber situaciones en las que los datos existentes deban reutilizarse según el requisito. A veces es difícil identificar los datos necesarios a partir de los datos existentes. | Para la configuración de datos, se pueden utilizar herramientas de cosecha propia según las necesidades. Para obtener datos existentes, las consultas deben crearse con anticipación. En caso de cualquier dificultad, se puede realizar una solicitud al equipo de administración de datos para crear o clonar los datos requeridos. |
| Configuración del trabajo Una vez que los trabajos se recuperan en PDS, el trabajo debe configurarse en la región de control de calidad. Para que los trabajos no se envíen con calificador de producción o detalle de ruta. | Se deben utilizar herramientas de configuración de trabajos 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 secuencias de comandos de automatización, secuencias de comandos de regresión y secuencias de comandos esqueleto podría ayudar a reducir la sobrecarga de tiempo y esfuerzo. |
| Publicaciones a tiempo para cambios de alcance Puede haber una situación en la que el impacto del código pueda cambiar completamente la apariencia del sistema. Esto puede requerir un cambio en los casos de prueba, los scripts y los 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 con una longitud superior a la del registro.
- S004 - Ocurrió un error durante ABRIR.
Motivo: DCB no válido
- S013 - Error al abrir un conjunto de datos.
Motivo: el miembro PDS no existe, la longitud del registro en el programa no coincide con la longitud real del registro.
- S0C1 - Excepción de operación
Razón: 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 no está disponible para el programa.
- SC07 - 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 un volcado.
- S322 - El tiempo de trabajo o paso excedió el límite especificado, o el programa está en un bucle o parámetro de tiempo insuficiente.
- S522: tiempo de espera de la sesión de 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 que 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 anormales.
Problema común que se enfrenta durante las pruebas de mainframe
- Fin de trabajo : para completar con éxito 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 anormales se pueden enfrentar debido a múltiples razones, siendo las más comunes: 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 la salida no sea la esperada. Entonces, antes de aprobar cualquier caso de prueba, el probador debe asegurarse de que la salida se verifique de forma cruzada. Solo entonces continúe.
- 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 la repetición y el trabajo.
Resumen:
- Las pruebas de mainframe son como cualquier otro procedimiento de prueba que comienza con la recopilación de requisitos, el diseño de pruebas, la ejecución de pruebas y los informes de resultados.
- Para probar la aplicación de manera eficaz, el evaluador debe participar en las reuniones de diseño programadas por los equipos de desarrollo y comerciales.
- Es obligatorio que el probador se acostumbre a varias funciones de prueba del mainframe. Como la navegación por la pantalla, la creación de archivos y PDS, el almacenamiento de los resultados de las pruebas, etc. antes de que comience el ciclo de pruebas.
- La prueba de aplicaciones de mainframe es un proceso que requiere tiempo. Se debe seguir un programa de prueba claro para el diseño de la prueba, la configuración de datos y la ejecución.
- Las pruebas por lotes y las pruebas en línea deben realizarse de manera efectiva sin perder ninguna de las funciones mencionadas en el documento de Requisitos, y no debe escatimarse ningún caso de prueba.
