Test del mainframe: tutorial completo

Prima di apprendere i concetti di test del mainframe, impariamo

Cos'è un mainframe?

Il mainframe è un sistema informatico ad alte prestazioni e ad alta velocità. Viene utilizzato per scopi informatici su larga scala che richiedono grande disponibilità e sicurezza. Viene utilizzato principalmente in settori come la finanza, le assicurazioni, la vendita al dettaglio e altre aree critiche in cui enormi dati vengono elaborati più volte.

Test del mainframe

Test del mainframe è un processo di test di applicazioni e servizi software basati su sistemi mainframe. Lo scopo del test del mainframe è garantire le prestazioni, l'affidabilità e la qualità dell'applicazione o del servizio software mediante metodi di verifica e convalida e verificare se è pronto per l'implementazione.

Durante l'esecuzione del test del mainframe, il tester deve solo conoscere la navigazione delle schermate CICS. Sono costruiti su misura per applicazioni specifiche. Qualsiasi modifica apportata al codice nel tester COBOL, JCL, ecc. non deve preoccuparsi dell'emulatore configurato sulla macchina. Le modifiche che funzionano su un emulatore di terminale funzioneranno su altri.

L'applicazione Mainframe (altrimenti chiamata batch di lavori) viene testata rispetto ai casi di test sviluppati utilizzando i requisiti
Il test del mainframe viene solitamente eseguito sul codice distribuito utilizzando varie combinazioni di dati impostate nel file di input.
È possibile accedere alle applicazioni eseguite sul mainframe tramite l'emulatore di terminale. L'emulatore è l'unico software che deve essere installato sul computer client.

Attributi del mainframe

Archiviazione virtuale
1. Si tratta di una tecnica che consente a un processore di simulare una memoria principale più grande della quantità effettiva di memoria reale.
2. È una tecnica per utilizzare la memoria in modo efficace per archiviare ed eseguire attività di varie dimensioni.
3. Utilizza l'archiviazione su disco come estensione dell'archiviazione reale.
Multiprogrammazione
1. Il computer esegue più di un programma contemporaneamente. Ma in ogni momento solo un programma può avere il controllo della CPU.
2. È una funzionalità fornita per utilizzare in modo efficiente la CPU.
Elaborazione batch
1. È una tecnica mediante la quale qualsiasi compito viene svolto in unità note come lavori.
2. Un lavoro può causare l'esecuzione di uno o più programmi in sequenza.
3. Lo scheduler dei lavori prende una decisione sull'ordine in cui i lavori devono essere eseguiti. Per massimizzare il throughput medio, i lavori vengono pianificati in base alla loro priorità e classe.
4. Le informazioni necessarie per l'elaborazione batch vengono fornite tramite JCL (JOB CONTROL LANGUAGE). JCL descrive il lavoro batch: programmi, dati e risorse necessari.
Condivisione del tempo
1. In un sistema time-sharing, ogni utente ha accesso al sistema tramite il dispositivo terminale. Invece di inviare lavori programmati per un'esecuzione successiva, l'utente immette comandi che vengono elaborati immediatamente.
2. Quindi questo è chiamato “elaborazione interattiva”. Consente all'utente di interagire direttamente con il computer.
3. L'elaborazione in time-sharing è nota come "Elaborazione in primo piano" mentre l'elaborazione dei processi batch è nota come "Elaborazione in background".
Spooling
1. SPOOLing sta per Periferico simultaneo Operazioni in linea.
2. Il dispositivo SPOOL viene utilizzato per memorizzare l'output del programma/applicazione. L'output in spool viene indirizzato ai dispositivi di output come una stampante (se necessario).
3. Si tratta di una funzionalità che sfrutta il vantaggio del buffering per utilizzare in modo efficiente i dispositivi di output.

Classificazione dei test manuali nel mainframe

Mainframe Test manuale possono essere classificati in due tipologie:

1. Test dei lavori in batch -

Il processo di test prevede l'esecuzione di lavori batch per la funzionalità implementata nella versione corrente.
Il risultato del test estratto dai file di output e dal database viene verificato e registrato.

2. Test in linea -

Il test in linea si riferisce al test delle schermate CICS che è simile al test della pagina Web.
È possibile modificare la funzionalità delle schermate esistenti oppure aggiungerne di nuove.
Diverse applicazioni possono avere schermate di richiesta e schermate di aggiornamento. La funzionalità di queste schermate deve essere verificata nell'ambito del test online.

Come eseguire test sul mainframe

Il team Business prepara i documenti dei requisiti, che determinano come un particolare articolo o processo verrà modificato nel ciclo di rilascio.
Il team di testing e lo sviluppo ricevono il documento dei requisiti. Calcoleranno quanti processi saranno interessati dal cambiamento. Di solito, in una release, solo il 20-25% dell'applicazione è interessato direttamente dal requisito personalizzato. L'altro 75% della release sarà per le funzionalità out-box come il testing delle applicazioni e dei processi.
Quindi, un'applicazione Mainframe deve essere testata in due parti:
1. Requisiti di prova – Testare l'applicazione per la funzionalità o la modifica menzionata nel documento dei requisiti.
2. Testare l'integrazione – Testare l'intero processo o altra applicazione che riceve o invia dati all'applicazione interessata. Test di regressione è l'obiettivo principale di questa attività di test.

Strumenti di test per l'automazione del mainframe

Di seguito è riportato l'elenco degli strumenti che possono essere utilizzati per il mainframe Test di automazione.

REXX
Excel
QTP

Metodologia nel test del mainframe

Consideriamo un esempio: una compagnia assicurativa XYZ dispone di un modulo di iscrizione dei membri. Prende i dati sia dalla schermata di registrazione dei membri che dalla registrazione offline. Come discusso in precedenza, sono necessari due approcci per il test del mainframe, il test online e il test in batch.

Test in linea viene effettuato nella schermata di registrazione del membro. Proprio come una pagina web il database viene validato con i dati inseriti attraverso le schermate.
Iscrizione offline può essere un'iscrizione cartacea o un'iscrizione su un sito Web di terze parti. I dati offline (chiamati anche batch) saranno inseriti nel database aziendale tramite batch job. Un file flat di input viene preparato secondo il formato dati prescritto e immesso nella sequenza di batch job. Quindi per il test dell'applicazione mainframe possiamo usare il seguente approccio.
Il primo lavoro nella riga dei lavori batch convalida i dati immessi. Diciamo ad esempio caratteri speciali, alfabeti in campi solo numerici, ecc.
Il secondo lavoro convalida la coerenza dei dati in base alle condizioni aziendali. Ad esempio, l'iscrizione di un bambino non deve contenere dati dipendenti, codice postale del membro (che non è disponibile per il servizio da parte del piano iscritto), ecc.
Il terzo lavoro modifica i dati nel formato che può essere immesso nel database. Ad esempio, eliminando il nome del piano (il database memorizzerà solo l'ID del piano e il nome del piano assicurativo), aggiungendo la data di immissione, ecc.
Il quarto lavoro carica i dati nel database.
Test di lavoro in batch viene svolto questo processo in due fasi:
Ogni lavoro viene convalidato separatamente e il file
L'integrazione tra i lavori viene convalidata fornendo un file flat di input al primo lavoro e convalidando il database. (I risultati intermedi devono essere convalidati per maggiore cautela)

Di seguito è riportato il metodo seguito per i test Mainframe:

Passo 1) Shakedown/Test del fumo

L'obiettivo principale in questa fase è verificare se il codice distribuito si trova nell'ambiente di test corretto. Garantisce inoltre che non vi siano problemi critici con il codice.

Passo 2) Test di sistema

Di seguito sono riportati i tipi di test eseguiti come parte del test di sistema.

Test in batch – Questo test verrà eseguito convalidando i risultati del test sui file di output e le modifiche ai dati eseguite dai lavori batch nell'ambito del test e registrandoli.
Test online – Questo test verrà eseguito sul front-end dell'applicazione mainframe. Qui l'applicazione viene testata per il campo di immissione corretto come un piano assicurativo, interessi sul piano, ecc.
Test di integrazione batch online – Questo test verrà eseguito sui sistemi con processi batch e applicazione online. Il flusso di dati e l'interazione tra le schermate online e i lavori batch vengono convalidati.
(Esempio per questo tipo di test – Considerare un aggiornamento sui dettagli del Piano come l'aumento del tasso di interesse. La modifica dell'interesse viene eseguita su una schermata di aggiornamento e i dettagli del saldo sui conti interessati verranno modificati solo da un batch job notturno. In questo caso, il test verrà eseguito convalidando la schermata dei dettagli del Piano e il batch job eseguito per aggiornare tutti i conti).
Test del database – I database in cui i dati provenienti dall'applicazione mainframe (IMS, IDMS, DB2, VSAM/ISAM, Sequential dataset, GDG) sono validati per il loro layout e l'archiviazione dei dati.

Passo 3) Sistema Test d'integrazione

Lo scopo principale di questo test è convalidare la funzionalità dei sistemi che interagiscono con il sistema sottoposto a test.

Questi sistemi non sono direttamente interessati dai requisiti. Tuttavia, utilizzano i dati del sistema sotto test. È importante testare l'interfaccia e i diversi tipi di messaggi (come Lavoro riuscito, Lavoro non riuscito, Database aggiornato, ecc.) che possono fluire tra i sistemi e le conseguenti azioni intraprese dai singoli sistemi.

I tipi di test eseguiti in questa fase sono

Test in batch
Test online
Online – Test di integrazione batch

Passo 4) Test di regressione

Il test di regressione è una fase comune in qualsiasi tipo di progetto di test. Questo test nei mainframe garantisce che i lavori batch e le schermate online che non interagiscono direttamente con il sistema in prova (o non rientrano nell'ambito dei requisiti) non siano influenzati dall'attuale versione del progetto.

Per avere test di regressione efficaci, un set specifico di casi di test dovrebbe essere selezionato in base alla loro complessità e dovrebbe essere creato un regression bed (repository dei casi di test). Questo set dovrebbe essere aggiornato ogni volta che viene implementata una nuova funzionalità nella release.

Passo 5) Test di Performance

Questo test viene eseguito per identificare i colli di bottiglia nelle aree ad alto impatto come i dati front-end, l'aggiornamento dei database online e per prevedere la scalabilità dell'applicazione.

Passo 6) Test di sicurezza

Questo test viene eseguito per valutare quanto bene l'applicazione è progettata e sviluppata per contrastare gli attacchi anti-sicurezza.

Sul sistema dovrebbero essere eseguiti due test di sicurezza: sicurezza del mainframe e sicurezza della rete.

Le caratteristiche che devono essere testate sono

Integrity
riservatezza
Autorizzazione
Autenticazione
Disponibilità

Passaggi coinvolti nel test batch

Dopo che il team QA ha ricevuto il pacchetto approvato (il pacchetto contiene procedure, JCL, schede di controllo, moduli, ecc.), il tester deve visualizzare in anteprima e recuperare i contenuti nel PDS come richiesto.
Convertire il JCL di produzione o il JCL di sviluppo in JCL QA, altrimenti denominato JOB SETUP.
Copia del file di produzione e preparazione dei file di test.
Per ogni funzionalità verrà definita una sequenza di lavoro. (Come spiegato nell'esempio in Metodologia nella sezione Mainframe). I lavori devono essere inviati utilizzando il comando SUB con i file di dati di test.
Controllare il file intermedio per identificare i motivi dei dati mancanti o errati.
Controllare il file di output finale, il database e lo spool per convalidare i risultati del test.
Se il lavoro fallisce, lo spool avrà il motivo del fallimento del lavoro. Risolvere l'errore e inviare nuovamente il lavoro.

Rapporto di prova – Difetto dovrebbe essere registrato se il risultato effettivo si discosta da quello previsto.

Passaggi coinvolti nei test online

Selezionare la schermata Online in un ambiente di test.
Testare ogni campo per i dati accettabili.
Prova il Scenario di prova sullo schermo.
Verificare il database per gli aggiornamenti dei dati dalla schermata online.

Reporting del test: il difetto deve essere registrato se il risultato effettivo si discosta da quello previsto.

Passaggi coinvolti nel test di integrazione online – batch

Esegui il lavoro in a Ambiente di test e convalidare i dati sulle schermate online.
Aggiorna i dati sulle schermate online e verifica se il lavoro batch viene eseguito correttamente con i dati aggiornati.

Comandi utilizzati nel test del mainframe

INVIA: invia un lavoro in background.
ANNULLA – Annulla il lavoro in background.
ASSEGNARE – Assegnare un set di dati
COPIA: copia un set di dati
RENAME – Rinomina il set di dati
ELIMINA: elimina il set di dati
JOB SCAN – Per associare il JCL al programma, alle librerie, al file, ecc. senza eseguirlo.

Esistono molti altri comandi utilizzati quando richiesto, ma non sono così frequenti.

Prerequisiti per avviare il test del mainframe

I dettagli di base necessari per il test del mainframe sono:

ID di accesso e password per accedere all'applicazione.
Breve conoscenza dei comandi ISPF.
Nomi dei file, qualificatore di file e relativi tipi.

Prima di iniziare il test del mainframe, è necessario verificare gli aspetti seguenti.

Lavoro
1. Eseguire una scansione del lavoro (Comando – JOBSCAN) per verificare la presenza di errori prima di eseguirlo.
2. Il parametro CLASS deve puntare alla classe di test.
3. Dirigere l'output del lavoro nello spool o in un JHS o come richiesto utilizzando il parametro MSGCLASS.
4. Reindirizza l'email nel processo allo spooler o a un ID di posta di prova.
5. Commentare i passaggi FTP per il test iniziale e quindi indirizzare il lavoro a un server di test.
6. Nel caso in cui nel lavoro venga generato un IMR (record di gestione degli incidenti), è sufficiente aggiungere il commento "SCOPO TEST" nel lavoro o nella scheda parametri.
7. Tutte le librerie di produzione nel lavoro dovrebbero essere modificate e indirizzate alle librerie di test.
8. Il lavoro non dovrebbe essere lasciato incustodito.
9. Per evitare che il lavoro venga eseguito in un ciclo infinito in caso di errori, il parametro TIME deve essere aggiunto con l'ora specificata.
10. Salvare l'output del lavoro incluso lo spool. La bobina può essere salvata utilizzando XDC.

Compila il
1. Crea solo il file di prova delle dimensioni necessarie. Utilizzare i GDG (Gruppi di dati di generazione – File con lo stesso nome ma con numeri di versione sequenziali – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 e così via) quando necessario per archiviare i dati in file consecutivi con lo stesso nome.
2. Il parametro DISP (Disposizione – descrive il sistema per eseguire la conservazione o l'eliminazione del set di dati dopo la conclusione normale o anomala della fase o del lavoro) per i file deve essere codificato correttamente.
3. Assicurarsi che tutti i file utilizzati per l'esecuzione del lavoro siano salvati e chiusi correttamente per evitare che il lavoro vada in ATTESA.
4. Durante il test utilizzando i GDG, assicurati che venga indicata la versione corretta.
Banca Dati
1. Durante l'esecuzione del lavoro o del programma online, assicurarsi che dati indesiderati non vengano inseriti, aggiornati o eliminati.
2. Inoltre, assicurarsi che per il test venga utilizzata la regione DB2 corretta.
Casi test
1. Verificare sempre le condizioni limite come: file vuoto, elaborazione del primo record, elaborazione dell'ultimo record, ecc.
2. Includere sempre condizioni di test sia positive che negative.
3. Nel caso in cui nel programma vengano utilizzate procedure standard come il riavvio del punto di controllo, i moduli di abend, i file di controllo, ecc., includere casi di test per verificare se i moduli sono stati utilizzati correttamente.
Dati di test
1. L'impostazione dei dati del test deve essere eseguita prima dell'inizio del test.
2. Non modificare mai i dati sulla regione di test senza avvisare. Potrebbero esserci altri team che lavorano con gli stessi dati e il loro test fallirebbe.
3. Nel caso in cui i file di produzione siano necessari durante l'esecuzione, è necessario ottenere l'adeguata autorizzazione prima di copiarli o utilizzarli.

migliori pratiche

In caso di esecuzione di un lavoro batch, MAX CC 0 indica che il lavoro è stato eseguito correttamente. Ciò non significa che la funzionalità funzioni correttamente. Il lavoro verrà eseguito correttamente anche quando l'output è vuoto o non conforme alle aspettative. Quindi è sempre previsto che controlli tutti gli output prima di dichiarare il lavoro riuscito.
È sempre una buona pratica eseguire un test di prova del lavoro in prova. L'esecuzione di prova viene eseguita con file di input vuoti. Questo processo dovrebbe essere seguito per i lavori che sono influenzati dalle modifiche apportate per il ciclo di test.
Prima dell'inizio del ciclo di prova, l'impostazione del lavoro di prova deve essere eseguita con largo anticipo. Ciò aiuterà a scoprire in anticipo eventuali errori JCL, risparmiando così tempo durante l'esecuzione.
Durante l'accesso alle tabelle DB2 tramite SPUFI (opzione sull'emulatore per accedere alle tabelle DB2), impostare sempre il commit automatico su "NO" per evitare aggiornamenti accidentali.
La disponibilità dei dati di test è la sfida principale nei test batch. I dati richiesti dovrebbero essere creati con largo anticipo rispetto al ciclo di prova e dovrebbero essere verificati per verificarne la completezza.
Alcune transazioni online e lavori batch possono scrivere dati in MQ (Message Queue) per trasmettere dati ad altre applicazioni. Se i dati non sono validi, potrebbero disabilitare/arrestare MQ, ciò influenzerà l'intero processo di test. È buona norma verificare che i MQ funzionino correttamente dopo il test.

Sfide e risoluzione dei problemi dei test del mainframe

Le sfide	Approccio
Requisiti incompleti/non chiari Potrebbe essere possibile accedere al manuale utente/guida alla formazione, ma questi non corrispondono ai requisiti documentati.	I tester dovrebbero essere coinvolti nell'SDLC dalla fase dei requisiti in poi. Ciò aiuterà a verificare se i requisiti sono verificabili.
Configurazione/Identificazione dei dati Potrebbero verificarsi situazioni in cui i dati esistenti devono essere riutilizzati secondo i requisiti. A volte è difficile identificare i dati richiesti dai dati esistenti.	Per l'impostazione dei dati, è possibile utilizzare strumenti interni in base alle necessità. Per recuperare i dati esistenti, le query dovrebbero essere create in anticipo. In caso di difficoltà, è possibile inviare una richiesta al team di gestione dei dati per la creazione o la clonazione dei dati richiesti.
Impostazione del lavoro Una volta recuperati i lavori in PDS, è necessario impostarli nell'area QA. In modo che i lavori non vengano inviati con il qualificatore di produzione o i dettagli del percorso.	Gli strumenti di impostazione del lavoro dovrebbero essere utilizzati in modo da superare gli errori umani commessi durante l'impostazione.
Richiesta ad hoc Potrebbero verificarsi situazioni in cui è necessario supportare i test end-to-end a causa di un problema nell'applicazione upstream o downstream. Queste richieste aumentano il tempo e lo sforzo nel ciclo di esecuzione.	L'uso di script di automazione, script di regressione e script di scheletro potrebbe aiutare a ridurre il tempo e gli sforzi generali.
Rilasci puntuali per la modifica dell'ambito Potrebbe verificarsi una situazione in cui l'impatto del codice potrebbe modificare completamente l'aspetto del sistema. Ciò potrebbe richiedere una modifica ai casi di test, agli script e ai dati.	Dovrebbero essere in atto un processo di gestione delle modifiche dell’ambito e un’analisi dell’impatto.

Si sono verificate anomalie comuni

S001 – Si è verificato un errore I/O.
Motivo: lettura alla fine del file, errore di lunghezza del file, tentativo di scrivere in un file di sola lettura.
S002 – Record I/O non valido.
Motivo: tentativo di scrivere un record più lungo della lunghezza del record.
S004 – Si è verificato un errore durante l'APERTURA.
Motivo: DCB non valido
S013 – Errore durante l'apertura di un set di dati.
Motivo: il membro PDS non esiste, la lunghezza del record nel programma non corrisponde alla lunghezza effettiva del record.
S0C1 – Operazione Eccezione
Motivo: impossibile aprire il file, scheda DD mancante
S0C4 – Eccezione di protezione/Violazione di archiviazione
Motivo: tentativo di accesso allo spazio di archiviazione non disponibile per il programma.
S0C7 – Eccezione controllo programma – Dati
Motivo: modifica del layout del record o del layout del file.
Sx22 – Il lavoro è stato annullato
S222 – Lavoro annullato dall'utente senza dump.
S322 – Il tempo del lavoro o del passo ha superato il limite specificato oppure il programma è in un ciclo o il parametro temporale è insufficiente.
S522 – Timeout della sessione TSO.
S806 – Impossibile collegare o caricare.
Motivo: l'ID lavoro non è riuscito a trovare il modulo di caricamento specificato.
S80A – Spazio di archiviazione virtuale insufficiente per soddisfare le richieste GETMAIN o FREEMAIN.
S913 – Tentativo di accesso al set di dati per il quale l'utente non è autorizzato.
Sx37 – Impossibile allocare spazio di archiviazione sufficiente al set di dati.

Error Assist: uno strumento molto popolare per ottenere informazioni dettagliate su vari tipi di anomalie.

Problema comune affrontato durante i test del mainframe

Il lavoro si interrompe – Per completare con successo il lavoro, è necessario controllare o meno i dati, il file di input e i moduli presenti nella posizione specifica. Le anomalie possono verificarsi a causa di molteplici ragioni, le più comuni delle quali sono: dati non validi, campo di input errato, mancata corrispondenza della data, problemi ambientali, ecc.
File di output vuoto–Sebbene il lavoro possa essere eseguito correttamente (MaxCC 0), l'output potrebbe non essere quello previsto. Pertanto, prima di superare qualsiasi caso di test, il tester deve assicurarsi che l'output sia sottoposto a verifica incrociata. Solo allora procedi oltre.
File di input vuoto – In alcune applicazioni, i file verranno ricevuti dai processi upstream. Prima di utilizzare il file ricevuto per testare l'applicazione corrente, i dati devono essere sottoposti a verifica incrociata per evitare rieseguizioni e rielaborazioni.

Sommario

Il test del mainframe è come qualsiasi altra procedura di test che inizia con la raccolta dei requisiti, la progettazione del test, l'esecuzione del test e il reporting dei risultati.
Per testare l'applicazione in modo efficace, il tester dovrebbe partecipare alle riunioni di progettazione programmate dai team di sviluppo e aziendali.
È obbligatorio che il tester si abitui alle varie funzioni di test del mainframe. Come la navigazione sullo schermo, la creazione di file e PDS, il salvataggio dei risultati dei test, ecc. prima dell'inizio del ciclo di test.
Il test delle applicazioni mainframe è un processo che richiede tempo. È necessario seguire un programma di test chiaro per la progettazione, l'impostazione dei dati e l'esecuzione del test.
I test in batch e i test online dovrebbero essere eseguiti in modo efficace senza perdere alcuna funzionalità menzionata nel documento dei Requisiti e n Test Case dovrebbe essere risparmiato.

Potrebbe piacerti: