Pruebas de mainframe: tutorial completo

Antes de aprender los conceptos de pruebas en sistemas centrales, veamos primero la plataforma en la que se ejecutan las pruebas.

¿Qué es una computadora central?

El mainframe es un sistema informático de alto rendimiento y alta velocidad. Se utiliza para computación a gran escala que requiere alta disponibilidad y seguridad robusta. Se emplea principalmente en sectores como finanzas, seguros, comercio minorista y otras áreas críticas donde se procesan enormes volúmenes de datos varias veces al día.

Pruebas de mainframe

Pruebas de mainframe Es un proceso de prueba de aplicaciones y servicios de software basados ​​en sistemas mainframe. El objetivo de las pruebas mainframe es garantizar el rendimiento, la fiabilidad y la calidad de una aplicación o servicio de software mediante métodos de verificación y validación, y comprobar si está listo para su implementación.

Durante las pruebas de mainframe, el evaluador necesita principalmente conocer la navegación de las pantallas CICS. Estas pantallas están diseñadas a medida para aplicaciones específicas. Cuando se realizan cambios en el código en COBOL, JCL y lenguajes similares, el evaluador no tiene que preocuparse por el emulador configurado en la máquina, ya que los cambios que funcionan en un emulador de terminal funcionarán en los demás.

• La aplicación Mainframe (también llamada procesamiento por lotes) se prueba comparándola con los casos de prueba desarrollados a partir de los 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 ordenador central mediante un emulador de terminal. El emulador es el único software que necesita instalarse en el equipo cliente.

Debido a que la plataforma se comporta de manera diferente a una pila web, es útil saber qué características del mainframe impulsan el diseño de las pruebas. Por lo tanto, las pruebas de mainframe se ubican junto con las demás. tipos de pruebas de software en lugar de reemplazar alguno de ellos.

Atributos del sistema central

1. 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.
2. Multiprogramación
   • El ordenador ejecuta más de un programa al mismo tiempo. Pero en un momento dado, solo un programa puede tener el control de la CPU.
   • Es una función proporcionada para hacer un uso eficiente de la CPU.
3. Procesamiento por lotes
   • Es una técnica mediante la cual cualquier tarea se realiza 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 que se deben ejecutar 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 (Job Control Language). JCL describe el trabajo por lotes: los programas, los datos y los recursos necesarios.
4. Tiempo compartido
   • 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.
   • De ahí que esto se denomine “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”.
5. Spooling
   • SPOOLing significa Periférica Simultánea Operaciones en línea.
   • El dispositivo SPOOL se utiliza para almacenar la salida de un programa o aplicación. La salida almacenada en el SPOOL se envía a dispositivos de salida como una impresora (si es necesario).
   • 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

Estas características dividen el trabajo de prueba manual en el ordenador central en dos flujos claramente separados.

Ordenador central Prueba manual se puede clasificar en dos tipos:

1. Pruebas de trabajos por lotes —

• El proceso de prueba implica la ejecución de trabajos por lotes para la funcionalidad implementada en la versión actual.
• Los resultados de la prueba extracLos datos extraídos de los archivos de salida y de la base de datos se verifican y registran.

2. Pruebas en línea —

• Las pruebas en línea se refieren a las pruebas de las pantallas de CICS, lo cual es similar a probar una 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 en sistemas centrales

1. El equipo de negocio prepara los documentos de requisitos, que determinan cómo se va a modificar un elemento o proceso en particular durante el ciclo de lanzamiento.
2. Los equipos de pruebas y desarrollo reciben el documento de requisitos. Determinan cuántos procesos se verán afectados por el cambio. Por lo general, en una versión, solo entre el 20 % y el 25 % de la aplicación se ve afectada directamente por el requisito personalizado. El 75 % al 80 % restante del esfuerzo de la versión se dedica a la funcionalidad estándar, como las pruebas de las aplicaciones y los procesos relacionados.
3. Por lo tanto, una aplicación Mainframe debe probarse en dos partes:
   • Requisitos de prueba — Probar la aplicación para verificar la funcionalidad o el cambio mencionado en el documento de requisitos.
   • Integración de pruebas — Probar todo el proceso u otras aplicaciones que reciben o envían 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 — el lenguaje de scripting incluido en z/OS, ampliamente utilizado para gestionar el envío repetitivo de trabajos y las comprobaciones de salida.
• Excel — Se utiliza con macros para crear, comparar e informar sobre datos de prueba y archivos de salida.
• OpenText UFT Un — el nombre actual de la herramienta que la industria todavía llama QTP o QuickTest Professional; automatiza 3270 pantallas de terminal.
• Galasa — un código abierto, Marco de pruebas de integración profunda del Open Mainframe Project que gestiona 3270 pantallas, trabajos por lotes JCL y Db2 desde una canalización CI/CD.
• Conjuntos de pruebas z/OS del proveedor - IBM Test Accelerator para Z y BMC AMI DevX Total Test abarca las pruebas unitarias de COBOL y los entornos de prueba virtualizados.

Cualquiera que sea la herramienta elegida, solo resulta rentable cuando se encuentra dentro de un sistema bien mantenido. marco de automatización de pruebas en lugar de un montón suelto de guiones.

Metodología en pruebas de mainframe

Consideremos un ejemplo: la compañía de seguros XYZ cuenta con un módulo de registro de miembros. Este módulo recibe datos tanto de la pantalla de registro como del registro fuera de línea. Como se mencionó anteriormente, utiliza dos enfoques para las pruebas en el sistema central: pruebas en línea y pruebas por lotes.

• Las pruebas en línea se realizan en la pantalla de inscripción de miembros. Al igual que en una página web, la base de datos se valida con los datos introducidos a través de las pantallas.
• La inscripción fuera de línea puede realizarse en papel o a través de un sitio web de terceros. Los datos fuera de línea (también conocidos como lotes) se ingresarán en la base de datos de la empresa mediante 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. Por lo tanto, para las pruebas de aplicaciones de mainframe podemos utilizar el siguiente enfoque.
  • La primera tarea de la secuencia de tareas por lotes valida los datos introducidos; por ejemplo, caracteres especiales o letras en campos que solo admiten números.
  • La segunda tarea consiste en validar la coherencia de los datos según las condiciones del negocio. Por ejemplo, la inscripción de un menor no debe contener datos de dependientes ni un código postal del miembro que no esté disponible para el plan inscrito.
  • El tercer paso modifica los datos para adaptarlos al formato que se puede introducir en la base de datos. Por ejemplo, elimina el nombre del plan (la base de datos solo almacenará el ID del plan y el nombre del plan de seguro), añade la fecha de entrada y realiza cambios similares.
  • El cuarto trabajo carga los datos en la base de datos.
• Las pruebas de trabajos por lotes se realizan en este proceso en dos fases:
  • Cada trabajo se valida por separado y
  • La integración entre las tareas se valida proporcionando el archivo plano de entrada a la primera tarea y validando la base de datos. (Por precaución, es necesario validar los resultados intermedios).

A continuación se describe el método seguido para las pruebas de sistemas centrales:

Paso 1) Prueba de funcionamiento/prueba de humo

El objetivo principal en esta etapa es validar si el código implementado está en el entorno de prueba correcto. También garantiza que no haya problemas críticos con el código. Este es el equivalente en mainframe de Prueba de humo en cualquier otra plataforma.

Paso 2) Pruebas del sistema

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

1. Pruebas por lotes — Estas pruebas se realizan validando los resultados de las pruebas en los archivos de salida y los cambios de datos realizados por los trabajos por lotes que se encuentran dentro del ámbito de prueba, y registrándolos.
2. Pruebas en línea — Estas pruebas se realizan en la interfaz de usuario de la aplicación principal. Aquí se comprueba que la aplicación introduzca correctamente campos como el plan de seguro, los intereses del plan y valores similares.
3. Pruebas de integración por lotes en línea — Estas pruebas se realizan en sistemas que cuentan con 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: Consideremos una actualización de los detalles del plan, como un aumento en 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 solo se modificarán mediante un proceso por lotes nocturno. En este caso, la prueba se realiza validando la pantalla de detalles del plan y la ejecución del proceso por lotes para actualizar todas las cuentas).

4. Prueba de base de datos — Las bases de datos donde se almacenan los datos de la aplicación del sistema central (IMS, IDMS, Db2, VSAM/ISAM, conjuntos de datos secuenciales, GDG) se validan en cuanto a su diseño y almacenamiento de datos.

Paso 3) Sistema 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 afectados directamente por los requisitos. Sin embargo, utilizan datos del sistema que se está probando. Es importante probar el interfaz. y los diferentes tipos de mensajes (como Trabajo exitoso, Trabajo fallido, Base de datos actualizada) que pueden fluir entre los sistemas, y las acciones resultantes tomadas por cada sistema.

Los tipos de pruebas realizadas en esta etapa son

1. Pruebas por lotes
2. Pruebas en línea
3. 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 proyecto de pruebas. Estas pruebas en mainframes garantizan 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 dentro del alcance de los requisitos) no se vean afectados por la versión actual del proyecto.

Para tener pruebas de regresión efectivas, se debe preseleccionar un conjunto particular de casos de prueba según su complejidad y se debe crear un entorno de regresión (repositorio de casos de prueba). Este conjunto debe actualizarse cada vez que se implemente una nueva funcionalidad en la versión. Cuando el entorno de regresión es demasiado grande para ejecutarse por completo, Pruebas basadas en riesgos Se utiliza para decidir qué trabajos y pantallas se vuelven a ejecutar primero.

Paso 5) Test de rendimiento

Estas pruebas se realizan para identificar los cuellos de botella en áreas de alto tráfico, como la entrada de datos en el front-end y las actualizaciones de bases de datos en línea, y para proyectar la escalabilidad de la aplicación. Por lo general, se examinan las ventanas de procesamiento por lotes de larga duración con Pruebas de estrés frente a los volúmenes máximos.

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 pruebas de seguridad dobles en el sistema: seguridad del sistema central y seguridad de la red.

Las características que deben probarse son:

1. Integrity
2. Confidencialidad
3. Autorización
4. Autenticación
5. Disponibilidad

Pasos involucrados en las pruebas por lotes

1. Una vez que el equipo de control de calidad reciba el paquete aprobado (que contiene procedimientos, JCL, tarjetas de control, módulos y elementos similares), el evaluador deberá previsualizar y recuperar el contenido en PDS según sea necesario.
2. Convierta el JCL de producción o el JCL de desarrollo en un JCL de control de calidad, también conocido como JOB SETUP.
3. Copia el archivo de producción y prepara los archivos de prueba.
4. Para cada funcionalidad, se definirá una secuencia de trabajos (como se explica en el ejemplo de la sección Metodología de pruebas en mainframe). Los trabajos deben enviarse mediante el comando SUB con los archivos de datos de prueba.
5. Revise el archivo intermedio para identificar las razones por las que faltan datos o hay errores.
6. Compruebe el archivo de salida final, la base de datos y el Spool para validar los resultados de la prueba.
7. Si el trabajo falla, el spool tendrá el motivo del fracaso del trabajo. Solucione el error y vuelva a enviar el trabajo.

Informe de prueba - Un precisa Se debe registrar si el resultado real difiere del resultado esperado.

Pasos involucrados en las pruebas en línea

1. Seleccione la pantalla en línea en un Entorno de prueba.
2. Pruebe cada campo para obtener datos aceptables.
3. Prueba el Escenario de prueba en la pantalla.
4. Verifique la base de datos para las actualizaciones de datos desde la pantalla en línea.

Informe de prueba — Se debe registrar un defecto si el resultado real difiere del resultado esperado.

Pasos involucrados en las pruebas de integración por lotes en línea

1. Ejecute la tarea en un entorno de prueba y valide los datos en las pantallas en línea.
2. Actualice los datos en las pantallas en línea y compruebe si el trabajo por lotes se ejecuta correctamente con los datos actualizados.

Comandos utilizados en las pruebas de sistemas centrales

Estos pasos se ejecutan desde la terminal, por lo que un vocabulario de comandos reducido cubre la mayor parte del día a día de un probador.

1. HAZ CLICK — Envíe una solicitud de verificación de antecedentes.
2. CANCELAR — Cancelar un trabajo en segundo plano.
3. ASIGNAR — Asignar un conjunto de datos.
4. COPIA — Copiar un conjunto de datos.
5. REBAUTIZAR — Cambiar el nombre de un conjunto de datos.
6. BORRAR — Eliminar un conjunto de datos.
7. ESCANEO DE TRABAJOS — Vincula el JCL con el programa, las bibliotecas, los archivos y otros recursos sin ejecutarlo.

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

Requisitos previos para comenzar 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.
• Conocimientos básicos de comandos ISPF.
• Nombres de los archivos, el calificador del archivo y sus tipos.

Antes de comenzar las pruebas del sistema central, se deben verificar los siguientes aspectos.

1. Trabajos
   • Realice un análisis 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 la cola de impresión o a un JHS, o según sea necesario, utilizando el parámetro MSGCLASS.
   • Redirigir el correo electrónico del trabajo a la cola de impresión o a una dirección de correo electrónico de prueba.
   • Comente los pasos de FTP para la prueba inicial y luego dirija la tarea a un servidor de prueba.
   • En caso de que se genere un IMR (Registro de Gestión de Incidentes) en el trabajo, agregue el comentario "PROPÓSITO DE PRUEBA" en el trabajo o en la tarjeta de parámetros.
   • Todas las bibliotecas de producción en el trabajo deben cambiarse y apuntar a bibliotecas de prueba.
   • El trabajo no debe dejarse desatendido.
   • Para evitar que el proceso entre en un bucle infinito en caso de error, se debe añadir el parámetro TIME con un tiempo especificado.
   • Guarde el resultado del trabajo, incluido el spool. El spool se puede guardar usando XDC.
2. Archivo
   • Cree un archivo de prueba del tamaño necesario. Utilice GDG (Grupos de Datos de Generación: archivos con el mismo nombre pero con números de versión secuenciales, como MYLIB.LIB.TEST.G0001V00 y MYLIB.LIB.TEST.G0002V00) cuando sea necesario para almacenar datos en archivos consecutivos con el mismo nombre.
   • El parámetro DISP (Disposición: indica al sistema si debe conservar o eliminar el conjunto de datos tras la finalización normal o anormal del paso o trabajo) para los archivos debe estar codificado correctamente.
   • Asegúrese de que todos los archivos utilizados para la ejecución del trabajo se guarden y cierren correctamente para evitar que el trabajo entre en estado de espera (HOLD).
   • Al realizar pruebas con GDG, asegúrese de que se esté utilizando la versión correcta.
3. Database
   • Al ejecutar el trabajo o el programa en línea, asegúrese de que no se inserten, actualicen ni eliminen datos no deseados.
   • Además, asegúrese de que se utilice la región Db2 correcta para las pruebas.
4. Casos de prueba
   • Siempre compruebe las condiciones límite, como un archivo vacío, el procesamiento del primer registro y el procesamiento del último registro.
   • Incluya siempre condiciones de prueba tanto positivas como negativas.
   • En caso de que se utilicen procedimientos estándar en el programa, como reinicio de punto de control, módulos de terminación anormal o archivos de control, incluya Caso de pruebapara validar si los módulos se han utilizado correctamente.
5. 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 a los demás. Es posible que otros equipos estén trabajando con los mismos datos y sus pruebas fallarían.
   • 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

1. En el caso de la ejecución de un trabajo por lotes, MAX CC 0 indica que el trabajo se ha ejecutado correctamente. Esto no significa que la funcionalidad esté funcionando correctamente. El trabajo se ejecutará correctamente incluso si la salida está vacía o no cumple con las expectativas. Por lo tanto, siempre se recomienda verificar todas las salidas antes de declarar que el trabajo se ha ejecutado correctamente.
2. Siempre es recomendable realizar una prueba en seco del trabajo que se está evaluando. Esta prueba se realiza con archivos de entrada vacíos. Este proceso debe seguirse para los trabajos que se vean afectados por los cambios realizados durante el ciclo de pruebas.
3. Antes de que comience el ciclo de pruebas, la configuración del trabajo de prueba debe realizarse con suficiente antelación. Esto ayuda a detectar cualquier error de JCL con anticipación, lo que ahorra tiempo durante la ejecución.
4. Al acceder a las tablas Db2 a través de SPUFI (una opción del emulador para acceder a las tablas Db2), configure siempre la confirmación automática en "NO" para evitar actualizaciones accidentales.
5. La disponibilidad de datos de prueba es el principal desafío en las pruebas por lotes. Los datos necesarios deben crearse con suficiente antelación al ciclo de pruebas y deben verificarse para asegurar que estén completos. Tracking esa preparación en un entorno compartido gestión de pruebas El repositorio mantiene alineados el entorno de regresión y la configuración de datos.
6. Algunas transacciones en línea y trabajos por lotes pueden escribir datos en MQ (colas de mensajes) para transmitenviar datos a otras aplicaciones. Si los datos no son válidos, pueden deshabilitar o detener las colas de mensajes (MQ), lo que afectará todo el proceso de prueba. Es recomendable verificar que las colas de mensajes funcionen correctamente después de las pruebas.

Desafíos y solución de problemas en las pruebas de sistemas mainframe

Aun con estas prácticas implementadas, algunos problemas se repiten en casi todas las versiones de mainframe. La siguiente tabla relaciona cada problema con el método que lo resuelve.

Desafíos	Nuevo enfoque
Requisitos incompletos/poco claros	Puede que haya acceso a un manual de usuario o guía de capacitación, pero estos no son lo mismo que los requisitos documentados. Los evaluadores deben participar en el proceso. ciclo de vida de las pruebas de software Desde la fase de requisitos en adelante. Esto ayuda a verificar si los requisitos son comprobables.
Configuración de datos / Identificación	Puede haber situaciones en las que sea necesario reutilizar los datos existentes según las necesidades. A veces resulta difícil identificar los datos requeridos entre los ya existentes. Para la configuración de datos, se pueden utilizar herramientas propias según sea necesario. Para recuperar datos existentes, se deben crear consultas con antelación. En caso de cualquier dificultad, se puede solicitar al equipo de gestión de datos la creación o clonación de los datos necesarios.
Configuración del trabajo	Una vez que los trabajos se recuperan en PDS, deben configurarse en la región de control de calidad (QA) para que no se envíen con un calificador de producción ni con detalles de ruta. Se deben utilizar herramientas de configuración de trabajos para evitar errores humanos durante la configuración.
Solicitud ad hoc	Puede haber situaciones en las que pruebas de extremo a extremo Se requiere asistencia debido a un problema en las aplicaciones anteriores o posteriores. 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 básicos puede ayudar a reducir el tiempo y el esfuerzo necesarios.
Lanzamientos puntuales para cambios de alcance	Puede darse el caso de que el impacto en el código cambie por completo la apariencia del sistema. Esto podría requerir modificaciones en los casos de prueba, los scripts y los datos. Es necesario contar con un proceso de gestión de cambios de alcance y un análisis de impacto.

Desvaríos comunes encontrados

Cuando falla un trabajo, el sistema de impresión informa un código de error. La siguiente lista incluye los códigos que un probador de mainframe encuentra con mayor frecuencia, junto con su causa habitual.

1. S001 — Se ha producido un error de entrada/salida.

   Motivo: Lectura al final del archivo, error de longitud del archivo o intento de escritura en un archivo de solo lectura.

2. S002 — Registro de E/S no válido.

   Motivo: Intentar escribir un registro más largo que la longitud permitida.

3. S004 — Se produjo un error durante la apertura.

   Motivo: DCB no válido.

4. S013 — Error al abrir el conjunto de datos.

   Motivo: El miembro de PDS no existe o la longitud del registro en el programa no coincide con la longitud real del registro.

5. S0C1 - OperaExcepción de ción.

   Motivo: No se puede abrir el archivo o falta la tarjeta DD.

6. S0C4 — Excepción de protección / violación de almacenamiento.

   Motivo: Se está intentando acceder a un área de almacenamiento no disponible para el programa.

7. S0C7 — Excepción de comprobación del programa, datos.

   Motivo: Cambio en el formato del registro o del archivo.

8. Sx22 — El trabajo ha sido cancelado.

   Motivo: El trabajo se interrumpió antes de su finalización; el dígito central identifica quién o qué lo canceló.

9. S222 — Trabajo cancelado por el usuario sin volcado de memoria.
10. S322 — El tiempo de ejecución del trabajo o del paso superó el límite especificado, o el programa está en un bucle, o el parámetro TIEMPO es insuficiente.
11. S522 — Tiempo de espera de la sesión TSO agotado.
12. S806 — No se pudo enlazar ni cargar.

    Motivo: El proceso no puede encontrar el módulo de carga especificado.

13. S80A — No hay suficiente almacenamiento virtual para satisfacer las solicitudes GETMAIN o FREEMAIN.
14. S913 — Intentando acceder a un conjunto de datos que el usuario no está autorizado a utilizar.
15. Sx37 — No se pudo asignar suficiente espacio de almacenamiento al conjunto de datos.

Asistencia para errores — Una herramienta muy popular para obtener información detallada sobre varios tipos de anomalías.

Problemas comunes que se presentan durante las pruebas de sistemas centrales

• El trabajo termina Para que la tarea se complete correctamente, debe verificar los datos, el archivo de entrada y la presencia de los módulos en la ubicación especificada. Los errores pueden ocurrir por diversas razones, siendo las más comunes los datos no válidos, un campo de entrada incorrecto, una discrepancia en la fecha o problemas ambientales.
• Archivo de salida vacío Aunque el trabajo se ejecute correctamente (MaxCC 0), el resultado podría no ser el esperado. Por lo tanto, antes de superar cualquier caso de prueba, el evaluador debe asegurarse de que el resultado se haya verificado. Solo entonces se debe continuar con las pruebas.
• Archivo de entrada vacío — En algunas aplicaciones, se reciben archivos de procesos anteriores. Antes de utilizar el archivo recibido para probar la aplicación actual, se deben verificar los datos para evitar la repetición de tareas y el retrabajo.

Preguntas Frecuentes