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 di elaborazione su scala più ampia che richiedono grande disponibilità e sicurezza. Viene utilizzato principalmente in settori come finanza, assicurazioni, vendita al dettaglio e altre aree critiche in cui vengono elaborati dati di grandi dimensioni più volte.
Test del mainframe
Mainframe Testing è un processo di test di applicazioni e servizi software basati su sistemi Mainframe. Lo scopo del test 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 la distribuzione.
Durante l'esecuzione del test Mainframe, il tester deve solo conoscere le navigazioni 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 impostato sulla macchina. Le modifiche che funzionano su un emulatore di terminale funzioneranno sugli 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 sulla macchina client.
In questo tutorial per principianti imparerai-
- Attributi del mainframe
- Classificazione dei test manuali in mainframe
- Come eseguire il test del mainframe
- Strumenti di test per l'automazione del mainframe
- Metodologia nei test mainframe
- Passaggi coinvolti nel test in batch
- Passaggi coinvolti nei test in linea
- Passaggi coinvolti in Online - Test di integrazione batch
- Comandi utilizzati nel test del mainframe
- Prerequisiti per avviare il test del mainframe
- Migliori pratiche
- Mainframe testing Sfide e risoluzione dei problemi
- Si sono verificate anomalie comuni
- Problema comune riscontrato durante i test del mainframe
Attributi del mainframe
- Archiviazione virtuale
- È una tecnica che consente a un processore di simulare la memoria principale che è maggiore della quantità effettiva di memoria reale.
- È una tecnica per utilizzare la memoria in modo efficace per archiviare ed eseguire attività di varie dimensioni.
- Utilizza l'archiviazione su disco come estensione dell'archiviazione reale.
- Multiprogrammazione
- Il computer esegue più di un programma contemporaneamente. Ma in un dato momento solo un programma può avere il controllo della CPU.
- È una funzione fornita per fare un uso efficiente della CPU.
- Elaborazione in lotti
- È una tecnica mediante la quale qualsiasi attività viene eseguita in unità note come lavori.
- Un lavoro può causare l'esecuzione di uno o più programmi in una sequenza.
- Lo scheduler dei lavori prende una decisione sull'ordine in cui i lavori devono essere eseguiti. Per massimizzare la produttività media, i lavori vengono pianificati in base alla loro priorità e classe.
- 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
- In un sistema di condivisione del tempo, ogni utente ha accesso al sistema tramite il dispositivo terminale. Invece di inviare i lavori pianificati per l'esecuzione successiva, l'utente immette comandi che vengono elaborati immediatamente.
- Quindi questo è chiamato "Elaborazione interattiva". Consente all'utente di interagire direttamente con il computer.
- L'elaborazione in multiproprietà è nota come "Elaborazione in primo piano" e l'elaborazione in batch del processo è nota come "Elaborazione in background".
- Spooling
- SPOOLing è l'acronimo di Simultaneous Peripheral Operations Online .
- Il dispositivo SPOOL viene utilizzato per memorizzare l'output del programma / applicazione. L'output di spool viene indirizzato a dispositivi di output come una stampante (se necessario).
- È una funzionalità che sfrutta il vantaggio del buffering per fare un uso efficiente dei dispositivi di output.
Classificazione dei test manuali in mainframe
Il test manuale del mainframe può essere classificato in due tipi:
- Test di lavoro 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.
- Test online -
- Il test in linea si riferisce al test delle schermate CICS che è simile al test della pagina Web.
- La funzionalità delle schermate esistenti potrebbe essere modificata o potrebbero essere aggiunte nuove schermate.
- Diverse applicazioni possono avere schermate di richiesta e schermate di aggiornamento. La funzionalità di queste schermate deve essere verificata durante il test in linea.
Come eseguire il test del mainframe
- Il team aziendale prepara i documenti dei requisiti. Che determina come un particolare elemento o processo verrà modificato nel ciclo di rilascio.
- Il team di test e lo sviluppo ricevono il documento dei requisiti. Capiranno quanti processi saranno interessati dal cambiamento. Di solito, in una versione, solo il 20-25% dell'applicazione è interessato direttamente dal requisito personalizzato. L'altro 75% del rilascio riguarderà le funzionalità out-box come il test delle applicazioni e dei processi.
- Quindi, un'applicazione Mainframe deve essere testata in due parti:
- Requisiti di test : test dell'applicazione per la funzionalità o la modifica menzionata nel documento dei requisiti.
- Test dell'integrazione : test dell'intero processo o di altre applicazioni che ricevono o inviano dati all'applicazione interessata. Il 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 test di automazione mainframe.
- REXX
- Eccellere
- QTP
Metodologia nei test mainframe
Consideriamo un esempio: una compagnia di assicurazioni XYZ ha un modulo di iscrizione dei membri. Prende i dati sia dalla schermata di registrazione dei membri che dalla registrazione offline. Come abbiamo discusso in precedenza, sono necessari due approcci per il test mainframe, il test online e il test batch.
- Il test in linea viene eseguito nella schermata di registrazione dei membri. Proprio come una pagina web, il database viene convalidato con i dati inseriti attraverso le schermate.
- L'iscrizione offline può essere l'iscrizione cartacea o l'iscrizione su un sito Web di terze parti. I dati offline (indicati anche come batch) verranno inseriti nel database aziendale tramite lavori batch. Un file flat di input viene preparato secondo il formato dati prescritto e inviato alla sequenza di lavori batch. Quindi per il test delle applicazioni mainframe possiamo utilizzare il seguente approccio.
- Il primo lavoro nella riga dei lavori batch convalida i dati immessi. Supponiamo ad esempio caratteri speciali, alfabeti nei 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 dal piano registrato), ecc.
- Il terzo lavoro modifica i dati nel formato che può essere inserito 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.
- Il test del lavoro in batch viene eseguito su 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)
Quello che segue è il metodo seguito per il test Mainframe:
Passaggio 1) : Shakedown / Smoke Test
L'obiettivo principale in questa fase è verificare se il codice distribuito si trova nell'ambiente di test corretto. Assicura inoltre che non ci siano problemi critici con il codice.
Passaggio 2) : test del 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 effettuate dai lavori batch nell'ambito del test e registrandoli.
- Test in linea : 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, l'interesse sul piano, ecc.
- Test di integrazione batch in linea : questo test verrà eseguito sui sistemi con processi batch e applicazione online. Il flusso di dati e l'interazione tra le schermate in linea e i lavori batch vengono convalidati.
( Esempio per questo tipo di test : prendere in considerazione un aggiornamento sui dettagli del piano come l'aumento del tasso di interesse. La modifica dell'interesse viene eseguita in una schermata di aggiornamento e i dettagli del saldo sugli account interessati verranno modificati solo da un lavoro batch notturno. in questo caso verrà eseguito convalidando la schermata dei dettagli del piano e l'esecuzione del batch job per l'aggiornamento di tutti gli account).
- Test del database : i database in cui i dati dall'applicazione mainframe (IMS, IDMS, DB2, VSAM / ISAM, set di dati sequenziali, GDG) vengono convalidati per il layout e l'archiviazione dei dati.
Passaggio 3) : test di integrazione del sistema
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 sottoposto a test. È importante testare l'interfaccia e diversi tipi di messaggi (come Lavoro riuscito, Lavoro non riuscito, Database aggiornato, ecc.) Che possono fluire tra i sistemi e le azioni conseguenti intraprese dai singoli sistemi.
I tipi di test eseguiti in questa fase sono
- Test in batch
- Test in linea
- Online - Test di integrazione batch
Passaggio 4) : test di regressione
Il test di regressione è una fase comune in qualsiasi tipo di progetto di test. Questo test in Mainframe garantisce che i lavori batch e le schermate online che non interagiscono direttamente con il sistema sottoposto a test (o che non rientrano nell'ambito dei requisiti) non siano influenzati dalla versione corrente del progetto.
Per avere test di regressione efficaci, è necessario selezionare un particolare insieme di casi di test in base alla loro complessità e creare un letto di regressione (archivio dei casi di test). Questo set deve essere aggiornato ogni volta che viene implementata una nuova funzionalità nella versione.
Passaggio 5) : test delle prestazioni
Questo test viene eseguito per identificare i colli di bottiglia in aree ad alto impatto come i dati front-end, l'aggiornamento dei database in linea e per proiettare la scalabilità dell'applicazione.
Passaggio 6) : test di sicurezza
Questo test viene eseguito per valutare quanto bene l'applicazione è progettata e sviluppata per contrastare gli attacchi anti-sicurezza.
Dovrebbero essere eseguiti due test di sicurezza sul sistema: sicurezza del mainframe e sicurezza della rete.
Le caratteristiche che devono essere testate sono
- Integrità
- Riservatezza
- Autorizzazione
- Autenticazione
- Disponibilità
Passaggi coinvolti nel test in batch
- Dopo che il team QA ha ricevuto il pacchetto approvato (il pacchetto contiene procedure, JCL, schede di controllo, moduli, ecc.), Il tester dovrebbe visualizzare in anteprima e recuperare i contenuti in PDS come richiesto.
- Convertire il JCL di produzione o il JCL di sviluppo in JCL QA altrimenti chiamato JOB SETUP.
- Copia del file di produzione e preparazione dei file di prova.
- Per ogni funzionalità, sarà definita una sequenza di lavoro. (Come spiegato nell'esempio nella sezione Metodologia nella sezione Mainframe). I lavori devono essere inviati utilizzando il comando SUB con i file di dati di prova.
- 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 non riesce, lo spool avrà il motivo dell'errore del lavoro. Risolvi l'errore e invia nuovamente il lavoro.
Report dei test: il difetto deve essere registrato se il risultato effettivo devia dal previsto.
Passaggi coinvolti nei test in linea
- Seleziona la schermata Online in un ambiente di test.
- Testare ogni campo per i dati accettabili.
- Testare lo scenario di prova sullo schermo.
- Verificare il database per gli aggiornamenti dei dati dalla schermata in linea.
Report dei test: il difetto deve essere registrato se il risultato effettivo devia dal previsto.
Passaggi coinvolti in Online - Test di integrazione batch
- Eseguire il lavoro in un ambiente di prova e convalidare i dati nelle schermate in linea.
- Aggiorna i dati nelle schermate in linea 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.
- ALLOCATE - Alloca un dataset
- COPIA: copia un set di dati
- RENAME - Rinomina il set di dati
- DELETE - Elimina dataset
- JOB SCAN -Per associare JCL al programma, alle librerie, al file, ecc. Senza eseguirlo.
Ci sono molti altri comandi usati 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 i seguenti aspetti.
- Lavoro
- Eseguire una scansione del lavoro (comando - JOBSCAN) per verificare la presenza di errori prima di eseguirlo.
- Il parametro CLASS dovrebbe essere puntato alla classe di test.
- Dirigere l'output del lavoro nello spool o in un JHS o come richiesto utilizzando il parametro MSGCLASS.
- Reindirizza l'e-mail nel lavoro allo spool o a un ID e-mail di prova.
- Commentare i passaggi FTP per il test iniziale, quindi indirizzare il lavoro a un server di test.
- Nel caso in cui venga generato un IMR (record di gestione degli incidenti) nel lavoro, è sufficiente aggiungere il commento "SCOPO DEL TEST" nel lavoro o nella scheda dei parametri.
- Tutte le librerie di produzione nel lavoro dovrebbero essere modificate e puntate alle librerie di test.
- Il lavoro non deve essere lasciato incustodito.
- Per evitare che il lavoro venga eseguito in un ciclo infinito in caso di errori, il parametro TIME deve essere aggiunto con il tempo specificato.
- Salvare l'output del lavoro compreso lo spool. Lo spool può essere salvato utilizzando XDC.
- File
- Crea solo il file di prova delle dimensioni necessarie. Utilizzare GDG (Generation Data Groups - 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 memorizzare i dati in file consecutivi con lo stesso nome.
- Il parametro DISP (Disposizione - descrive il sistema per eseguire la conservazione o l'eliminazione del set di dati dopo la terminazione normale o anormale del passaggio o del lavoro) per i file deve essere codificato correttamente.
- Assicurarsi che tutti i file utilizzati per l'esecuzione del lavoro siano salvati e chiusi correttamente per evitare che il lavoro vada in ATTESA.
- Durante il test utilizzando i GDG assicurati che sia puntata la versione giusta.
- Banca dati
- Durante l'esecuzione del lavoro o del programma in linea, assicurarsi che i dati involontari non vengano inseriti, aggiornati o eliminati.
- Inoltre, assicurarsi che per il test venga utilizzata la regione DB2 corretta.
- Casi test
- Verifica sempre le condizioni al contorno come: file vuoto, elaborazione del primo record, elaborazione dell'ultimo record, ecc.
- Includere sempre condizioni di test positive e negative.
- Nel caso in cui nel programma vengano utilizzate procedure standard come il riavvio del punto di controllo, i moduli di interruzione, i file di controllo, ecc. Includere casi di test per convalidare se i moduli sono stati utilizzati correttamente.
- Dati di test
- L'impostazione dei dati del test deve essere eseguita prima dell'inizio del test.
- Non modificare mai i dati nella regione di test senza avvisare. Potrebbero esserci altri team che lavorano con gli stessi dati e il loro test fallirebbe.
- Nel caso in cui i file di produzione siano necessari durante l'esecuzione, è necessario ottenere l'autorizzazione appropriata prima di copiarli o utilizzarli.
Migliori pratiche
- In caso di esecuzione di un lavoro batch, MAX CC 0 è un indicatore 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 meno come previsto. Quindi ci si aspetta sempre di controllare tutti gli output prima di dichiarare il lavoro andato a buon fine.
- È sempre una buona pratica eseguire un funzionamento a secco del lavoro in esame. Il funzionamento a secco viene eseguito con file di input vuoti. Questo processo dovrebbe essere seguito per i lavori che sono influenzati dalle modifiche apportate per il ciclo di prova.
- Prima che il ciclo di prova inizi, l'impostazione del lavoro di prova deve essere eseguita con largo anticipo. Ciò aiuterà a scoprire in anticipo qualsiasi errore JCL, risparmiando 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 in batch. I dati richiesti dovrebbero essere creati con largo anticipo rispetto al ciclo di prova e dovrebbe essere verificata la completezza.
- Alcune transazioni in linea e lavori batch possono scrivere dati in MQ (Message Queue) per la trasmissione dei dati ad altre applicazioni. Se i dati non sono validi, potrebbe disabilitare / arrestare gli MQ, ciò influenzerà l'intero processo di test. È buona norma verificare che gli MQ funzionino correttamente dopo il test.
Mainframe testing Sfide e risoluzione dei problemi
| Sfide | Approccio |
| Requisiti incompleti / non chiari Potrebbe essere possibile accedere al manuale utente / alla guida di formazione, ma questi non sono gli stessi dei requisiti documentati. | I tester dovrebbero essere coinvolti nell'SDLC dalla fase dei requisiti in poi. Questo aiuterà a verificare se i requisiti sono testabili. |
| Impostazione / identificazione dei dati Potrebbero verificarsi situazioni in cui i dati esistenti dovrebbero essere riutilizzati secondo il requisito. A volte è difficile identificare i dati richiesti dai dati esistenti. | Per l'impostazione dei dati, è possibile utilizzare strumenti personalizzati in base alle necessità. Per recuperare i dati esistenti, le query devono essere create in anticipo. In caso di difficoltà, è possibile inoltrare una richiesta al team di gestione dei dati per la creazione o la clonazione dei dati richiesti. |
| Impostazione lavoro Una volta che i lavori vengono recuperati in PDS, il lavoro deve essere impostato nella regione QA. In modo che i lavori non vengano inviati con il qualificatore di produzione o il dettaglio del percorso. | Gli strumenti di configurazione del lavoro dovrebbero essere utilizzati in modo da superare gli errori umani commessi durante la configurazione. |
| Richiesta ad-hoc Potrebbero verificarsi situazioni in cui è necessario supportare i test end-to-end a causa di un problema nelle applicazioni upstream o downstream. Queste richieste aumentano il tempo e lo sforzo nel ciclo di esecuzione. | L'utilizzo di script di automazione, script di regressione e script scheletro potrebbe aiutare a ridurre il tempo e il sovraccarico di lavoro. |
| Rilasci puntuali per la modifica dell'ambito Potrebbe verificarsi una situazione in cui l'impatto del codice potrebbe modificare completamente l'aspetto e il funzionamento del sistema. Ciò potrebbe richiedere una modifica a casi di test, script e dati. | Dovrebbero essere in atto il processo di gestione del cambiamento dell'ambito e l'analisi dell'impatto. |
Si sono verificate anomalie comuni
- S001 - Si è verificato un errore di I / O.
Motivo: lettura alla fine del file, errore di lunghezza del file, tentativo di scrittura 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'OPEN.
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 del record effettiva.
- S0C1 - Eccezione operazione
Motivo: impossibile aprire il file, scheda DD mancante
- S0C4 - Eccezione di protezione / violazione dello spazio di archiviazione
- Motivo: tentativo di accesso allo spazio di archiviazione non disponibile per il programma.
- SC07 - 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 un dump.
- S322 - Il tempo del lavoro o del passo ha superato il limite specificato o il programma è in un ciclo o il parametro del tempo è insufficiente.
- S522 - Timeout della sessione TSO.
- S806 -Impossibile collegare o caricare.
Motivo: l'ID lavoro non è in grado di trovare il modulo di caricamento specificato.
- S80A - Memoria virtuale insufficiente per soddisfare le richieste GETMAIN o FREEMAIN.
- S913 - Tentativo di accesso al set di dati che l'utente non è autorizzato.
- Sx37: impossibile allocare spazio di archiviazione sufficiente per il set di dati.
Error Assist - Uno strumento molto popolare per ottenere informazioni dettagliate su vari tipi di abends.
Problema comune riscontrato durante i test del mainframe
- Fine del lavoro - Per completare con successo il lavoro, è necessario controllare i dati, il file di input ei moduli presenti nella posizione specifica o meno. Le anomalie possono essere affrontate a causa di molteplici ragioni, la più comune è: 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. Quindi, prima di superare qualsiasi test case, 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 a monte. Prima di utilizzare il file ricevuto per testare l'applicazione corrente, i dati devono essere verificati in modo incrociato per evitare la riesecuzione e la rilavorazione.
Sommario:
- Il test mainframe è come qualsiasi altra procedura di test a partire dalla raccolta dei requisiti, progettazione dei test, esecuzione dei test e reporting dei risultati.
- Per testare l'applicazione in modo efficace, il tester dovrebbe partecipare a riunioni di progettazione programmate dai team di sviluppo e aziendali.
- È obbligatorio per il tester abituarsi alle varie funzioni di test del mainframe. Come la navigazione nella schermata, 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 richiede tempo. È necessario seguire un programma di test chiaro per la progettazione, la configurazione e l'esecuzione dei dati.
- Il test in batch e il test in linea dovrebbero essere eseguiti in modo efficace senza perdere alcuna funzionalità menzionata nel documento dei requisiti e nessun caso di test dovrebbe essere risparmiato.