Test del mainframe: tutorial completo

Prima di approfondire i concetti relativi al testing su mainframe, esaminiamo innanzitutto la piattaforma su cui vengono eseguiti i test.

Cos'è un mainframe?

Il mainframe è un sistema informatico ad alte prestazioni e ad alta velocità. Viene utilizzato per l'elaborazione di grandi quantità di dati che richiede elevata disponibilità e robustezza. È impiegato principalmente in settori come la finanza, le assicurazioni, la vendita al dettaglio e altre aree critiche in cui vengono elaborati enormi volumi di dati più volte al giorno.

Test del mainframe

Test del mainframe Il test su mainframe è un processo di verifica di applicazioni e servizi software basati su sistemi mainframe. Lo scopo del test su mainframe è garantire le prestazioni, l'affidabilità e la qualità di un'applicazione o di un servizio software attraverso metodi di verifica e validazione, e controllare se è pronto per la distribuzione.

Durante l'esecuzione di test su mainframe, il tester deve principalmente conoscere la navigazione delle schermate CICS. Queste schermate sono create su misura per applicazioni specifiche. Quando vengono apportate modifiche al codice in COBOL, JCL e linguaggi simili, il tester non deve preoccuparsi dell'emulatore configurato sulla macchina, perché le modifiche che funzionano su un emulatore di terminale funzioneranno anche sugli altri.

• L'applicazione mainframe (detta anche batch di lavoro) 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 in esecuzione sul mainframe tramite un emulatore di terminale. L'emulatore è l'unico software che deve essere installato sul computer client.

Poiché la piattaforma si comporta in modo diverso da uno stack web, è utile sapere quali caratteristiche del mainframe influenzano la progettazione dei test. Il test del mainframe si colloca quindi accanto agli altri tipi di test del software piuttosto che sostituirne qualcuno.

Attributi del mainframe

1. Archiviazione virtuale
   • Si tratta di una tecnica che consente a un processore di simulare una memoria principale più grande 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.
2. Multiprogrammazione
   • Il computer esegue più programmi contemporaneamente. Tuttavia, in un dato momento, solo un programma può avere il controllo della CPU.
   • È una funzionalità fornita per utilizzare in modo efficiente la CPU.
3. Elaborazione batch
   • È una tecnica mediante la quale qualsiasi compito viene svolto in unità note come lavori.
   • Un lavoro può causare l'esecuzione di uno o più programmi in sequenza.
   • 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.
   • Le informazioni necessarie per l'elaborazione batch vengono fornite tramite JCL (JOB CONTROL LANGUAGE). Il JCL descrive il job batch, ovvero i programmi, i dati e le risorse necessarie.
4. Condivisione del tempo
   • 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.
   • Quindi questo è chiamato “elaborazione interattiva”. Consente all'utente di interagire direttamente con il computer.
   • L'elaborazione in time-sharing è nota come "Elaborazione in primo piano" mentre l'elaborazione dei processi batch è nota come "Elaborazione in background".
5. Spooling
   • SPOOLing sta per Simultaneous Peripheral Operazioni online.
   • Il dispositivo SPOOL viene utilizzato per memorizzare l'output di un programma o di un'applicazione. L'output memorizzato nella coda di stampa viene indirizzato a dispositivi di output come una stampante (se necessario).
   • 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

Queste caratteristiche suddividono il lavoro di test manuale sul mainframe in due flussi ben distinti.

Mainframe Test manuale possono essere classificati in due tipologie:

1. Test dei processi batch —

• Il processo di test prevede l'esecuzione di processi batch per le funzionalità implementate nella versione corrente.
• I risultati del test estracI dati ricavati dai file di output e dal database vengono verificati e registrati.

2. Test online —

• Il test online si riferisce al collaudo delle schermate CICS, che è simile al collaudo di una 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 su mainframe

1. Il team commerciale prepara i documenti dei requisiti, che definiscono come un particolare elemento o processo verrà modificato nel ciclo di rilascio.
2. Il team di test e il team di sviluppo ricevono il documento dei requisiti. Calcolano quanti processi saranno interessati dalla modifica. Solitamente, in una release, solo il 20-25% dell'applicazione è direttamente interessato dal requisito personalizzato. Il restante 75-80% del lavoro di rilascio è dedicato alle funzionalità standard, come il test delle applicazioni e dei processi correlati.
3. Quindi, un'applicazione Mainframe deve essere testata in due parti:
   • Requisiti di prova — Testare l'applicazione per verificare la funzionalità o la modifica menzionata nel documento dei requisiti.
   • Testare l'integrazione — Testare l'intero processo o altre applicazioni che ricevono o inviano 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 — il linguaggio di scripting fornito con z/OS, ampiamente utilizzato per gestire l'invio ripetitivo di job e i controlli di output.
• Excel — Utilizzato con le macro per creare, confrontare e generare report sui dati di test e sui file di output.
• OpenText UFT Un — il nome attuale dello strumento che l'industria chiama ancora QTP oppure QuickTest Professional; automatizza 3270 schermate del terminale.
• Galasa — un software open-source, Framework di test di integrazione profonda per il progetto Open Mainframe che gestisce 3270 schermate, processi batch JCL e Db2 da una pipeline CI/CD.
• Suite di test z/OS del fornitore - IBM Test Accelerator per Z e BMC AMI DevX Total Test copre i test unitari COBOL e gli ambienti di test virtualizzati.

Qualunque strumento venga scelto, ripaga solo quando si trova all'interno di un sistema mantenuto framework di automazione dei test piuttosto che una pila disordinata di sceneggiature.

Metodologia nel test del mainframe

Consideriamo un esempio: una compagnia assicurativa XYZ ha un modulo di iscrizione clienti. Questo modulo raccoglie dati sia dalla schermata di iscrizione online che dalle iscrizioni offline. Come già accennato, per il test su mainframe esistono due approcci: il test online e il test batch.

• I test online vengono eseguiti nella schermata di iscrizione dei membri. Proprio come una pagina web, il database viene convalidato con i dati inseriti tramite le schermate.
• L'iscrizione offline può avvenire tramite moduli cartacei o su un sito web di terze parti. I dati offline (anche denominati batch) verranno inseriti nel database aziendale tramite processi batch. Un file di input di tipo flat viene preparato secondo il formato dati prescritto e fornito alla sequenza di processi batch. Pertanto, per il test delle applicazioni mainframe, possiamo utilizzare il seguente approccio.
  • Il primo processo della sequenza di processi batch convalida i dati inseriti, ad esempio caratteri speciali o lettere dell'alfabeto nei campi numerici.
  • Il secondo compito consiste nel verificare la coerenza dei dati in base alle condizioni aziendali. Ad esempio, l'iscrizione di un bambino non deve contenere dati relativi a persone a carico, né un codice postale di un membro non coperto dal piano tariffario sottoscritto.
  • Il terzo compito consiste nel modificare i dati in un formato che possa 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 inserimento e apportando modifiche simili.
  • Il quarto lavoro carica i dati nel database.
• Il test dei processi batch viene eseguito in due fasi:
  • Ogni lavoro viene convalidato separatamente e
  • L'integrazione tra i job viene convalidata fornendo il file di input al primo job e convalidando il database. (Per maggiore precauzione, è necessario convalidare anche i risultati intermedi.)

Di seguito viene descritto il metodo seguito per il collaudo dei mainframe:

Fase 1) Test di collaudo/test del fumo

L'obiettivo principale in questa fase è verificare che il codice distribuito si trovi nell'ambiente di test corretto. Garantisce inoltre che non vi siano problemi critici con il codice. Questo è l'equivalente mainframe di Test del fumo su qualsiasi altra piattaforma.

Passo 2) Test di sistema

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

1. Test in batch — Questa fase di test viene eseguita convalidando i risultati dei test sui file di output e sulle modifiche ai dati apportate dai processi batch oggetto del test, e registrandoli.
2. Test online — Questo test viene eseguito sul front-end dell'applicazione mainframe. Qui l'applicazione viene testata per verificare la correttezza dei campi di inserimento, come ad esempio il piano assicurativo, gli interessi maturati sul piano e valori simili.
3. Test di integrazione batch online — Questi test vengono eseguiti su sistemi dotati sia di processi batch che di un'applicazione online. Vengono validati il ​​flusso di dati e l'interazione tra le schermate online e i processi batch.

   (Esempio per questo tipo di test: si consideri un aggiornamento dei dettagli del piano, come ad esempio un aumento del tasso di interesse. La modifica del tasso di interesse viene effettuata in una schermata di aggiornamento e i dettagli del saldo dei conti interessati verranno modificati solo da un processo batch notturno. In questo caso, il test viene eseguito convalidando la schermata dei dettagli del piano e l'esecuzione del processo batch per l'aggiornamento di tutti i conti.)

4. Test del database — I database in cui sono memorizzati i dati dell'applicazione mainframe (IMS, IDMS, Db2, VSAM/ISAM, dataset sequenziali, GDG) vengono validati per quanto riguarda la struttura e l'archiviazione dei dati.

Fase 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 influenzati dai requisiti. Tuttavia, utilizzano i dati del sistema in fase di test. È importante testare il interfaccia e i diversi tipi di messaggi (come Lavoro completato con successo, Lavoro non riuscito, Database aggiornato) che possono circolare tra i sistemi, e le conseguenti azioni intraprese dai singoli sistemi.

I tipi di test eseguiti in questa fase sono

1. Test in batch
2. Test online
3. Test di integrazione batch online

Fase 4) Test di regressione

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

Per eseguire test di regressione efficaci, è necessario selezionare un insieme specifico di casi di test in base alla loro complessità e creare un ambiente di regressione (repository di casi di test). Questo insieme deve essere aggiornato ogni volta che viene implementata una nuova funzionalità nella release. Qualora l'ambiente di regressione sia troppo grande per essere eseguito completamente, Test basati sul rischio viene utilizzato per decidere quali processi e schermate vengono eseguiti nuovamente per primi.

Passo 5) Test di Performance

Questo test viene eseguito per identificare i colli di bottiglia nelle aree ad alto traffico come l'inserimento dati front-end e gli aggiornamenti del database online e per prevedere la scalabilità dell'applicazione. Le finestre batch di lunga durata vengono solitamente esaminate con Test di stress contro i volumi di picco.

Passo 6) Test di sicurezza

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

Il sistema dovrebbe essere sottoposto a un duplice test di sicurezza: sicurezza del mainframe e sicurezza della rete.

Le caratteristiche che devono essere testate sono

1. Integrity
2. riservatezza
3. Autorizzazione
4. Autenticazione
5. Disponibilità

Fasi coinvolte nel test di batch

1. Dopo che il team QA ha ricevuto il pacchetto approvato (il pacchetto contiene procedure, JCL, schede di controllo, moduli e elementi simili), il tester deve visualizzarne l'anteprima e recuperarne il contenuto in PDS secondo necessità.
2. Convertire il JCL di produzione o di sviluppo in un JCL di QA, altrimenti detto JOB SETUP.
3. Copia il file di produzione e prepara i file di test.
4. Per ogni funzionalità, verrà definita una sequenza di job (come spiegato nell'esempio nella sezione Metodologia di test su mainframe). I job devono essere inviati utilizzando il comando SUB insieme ai file di dati di test.
5. Controlla il file intermedio per identificare le cause dei dati mancanti o errati.
6. Verificare il file di output finale, il database e lo spool per convalidare i risultati del test.
7. Se il lavoro fallisce, lo spool avrà il motivo del fallimento del lavoro. Risolvere l'errore e inviare nuovamente il lavoro.

Report di prova - A difetto Se il risultato effettivo si discosta dal risultato atteso, è necessario registrarlo.

Fasi del test online

1. Seleziona la schermata Online in un Ambiente di test.
2. Testare ogni campo per i dati accettabili.
3. Prova il Scenario di prova sullo schermo.
4. Verificare il database per gli aggiornamenti dei dati dalla schermata online.

Report di prova — Un difetto deve essere segnalato se il risultato effettivo si discosta dal risultato atteso.

Fasi coinvolte nel test di integrazione batch online

1. Esegui il processo in un ambiente di test e convalida i dati visualizzati nelle schermate online.
2. Aggiorna i dati nelle schermate online e verifica che il processo batch venga eseguito correttamente con i dati aggiornati.

Comandi utilizzati nei test sui mainframe

Questi passaggi vengono eseguiti dal terminale, quindi un vocabolario di comandi ridotto copre la maggior parte della giornata di un tester.

1. INVIA — Invia una richiesta di lavoro in background.
2. ANNULLA — Annulla un'attività in background.
3. ASSEGNARE — Assegna un dataset.
4. COPIA — Copia un set di dati.
5. RINOMINARE — Rinominare un set di dati.
6. DELETE — Elimina un set di dati.
7. SCANSIONE DEL LAVORO — Collega il JCL al programma, alle librerie, ai file e ad altre risorse senza eseguirlo.

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

Prerequisiti per iniziare i test sul mainframe

Le informazioni di base necessarie per il test del mainframe sono:

• ID di accesso e password per accedere all'applicazione.
• Conoscenza di base dei comandi ISPF.
• Nomi dei file, qualificatore del file e loro tipi.

Prima di iniziare i test sul mainframe, è necessario verificare i seguenti aspetti.

1. Lavoro
   • Esegui una scansione del lavoro (comando — JOBSCAN) per verificare la presenza di errori prima di eseguirlo.
   • Il parametro CLASS deve puntare alla classe di test.
   • Indirizzare l'output del job nello spool o in un JHS, o secondo necessità, utilizzando il parametro MSGCLASS.
   • Reindirizza l'e-mail del processo alla coda di posta o a un indirizzo e-mail di prova.
   • Per i test iniziali, commentate i passaggi relativi all'FTP e poi indirizzate il processo a un server di test.
   • Nel caso in cui venga generato un IMR (Incident Management Record) nel job, aggiungere il commento "SCOPO DI TEST" nel job o nella scheda dei parametri.
   • Tutte le librerie di produzione nel lavoro dovrebbero essere modificate e indirizzate alle librerie di test.
   • Il lavoro non dovrebbe essere lasciato incustodito.
   • Per evitare che il processo entri in un ciclo infinito in caso di errore, è necessario aggiungere il parametro TIME specificando un intervallo di tempo.
   • Salvare l'output del lavoro incluso lo spool. La bobina può essere salvata utilizzando XDC.
2. Compila il
   • Crea un file di prova delle dimensioni necessarie. Utilizza i GDG (Generation Data Groups, ovvero gruppi di dati generazionali: file con lo stesso nome ma con numeri di versione sequenziali, come MYLIB.LIB.TEST.G0001V00 e MYLIB.LIB.TEST.G0002V00) quando necessario per memorizzare i dati in file consecutivi con lo stesso nome.
   • Il parametro DISP (Disposition - indica al sistema se conservare o eliminare il dataset dopo la terminazione normale o anomala della fase o del job) 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 venga messo in stato di HOLD.
   • Durante i test con GDG, assicurarsi che sia selezionata la versione corretta.
3. Banca Dati
   • Durante l'esecuzione del lavoro o del programma online, assicurarsi che non vengano inseriti, aggiornati o eliminati dati indesiderati.
   • Assicurati inoltre di utilizzare la regione Db2 corretta per i test.
4. Casi test
   • È sempre necessario verificare le condizioni limite, come ad esempio un file vuoto, l'elaborazione del primo record e l'elaborazione dell'ultimo record.
   • Includere sempre condizioni di test sia positive che negative.
   • Nel caso in cui nel programma vengano utilizzate procedure standard, come il riavvio del checkpoint, i moduli di aberrazione o i file di controllo, includere Test Caseper verificare se i moduli sono stati utilizzati correttamente.
5. Dati di test
   • L'impostazione dei dati del test deve essere eseguita prima dell'inizio del test.
   • Non modificare mai i dati nell'area di test senza avvisare gli altri. Potrebbero esserci altri team che lavorano con gli stessi dati e i loro test fallirebbero.
   • 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

1. Nel caso di un'esecuzione batch, MAX CC 0 indica che l'esecuzione è andata a buon fine. Ciò non significa che la funzionalità funzioni correttamente. L'esecuzione del job avrà esito positivo anche se l'output è vuoto o non conforme alle aspettative. Pertanto, è sempre consigliabile verificare tutti gli output prima di dichiarare l'esecuzione del job conclusa con successo.
2. È sempre buona norma eseguire una simulazione del processo da testare. La simulazione viene effettuata con file di input vuoti. Questa procedura dovrebbe essere seguita per i processi che saranno interessati dalle modifiche apportate per il ciclo di test.
3. Prima dell'inizio del ciclo di test, è necessario impostare il job di test con largo anticipo. Questo permette di individuare in anticipo eventuali errori JCL, risparmiando tempo durante l'esecuzione.
4. Quando si accede alle tabelle Db2 tramite SPUFI (un'opzione dell'emulatore per accedere alle tabelle Db2), impostare sempre l'auto commit su "NO" per evitare aggiornamenti accidentali.
5. La disponibilità dei dati di test rappresenta la principale sfida nei test batch. I dati necessari devono essere creati con largo anticipo rispetto al ciclo di test e la loro completezza deve essere verificata. Tracking quella preparazione in un gestione dei test Il repository mantiene allineati il ​​banco di prova per la regressione e la configurazione dei dati.
6. Alcune transazioni online e processi batch possono scrivere dati in code di messaggi (MQ) per transmittrasferimento di dati ad altre applicazioni. Se i dati non sono validi, le MQ potrebbero essere disabilitate o interrotte, compromettendo l'intero processo di test. È buona norma verificare il corretto funzionamento delle MQ dopo il test.

Sfide e risoluzione dei problemi relativi ai test sui mainframe

Anche con queste procedure in atto, alcuni problemi si ripresentano in quasi ogni rilascio di mainframe. La tabella seguente associa ciascuno di essi alla soluzione proposta.

Le sfide	Approccio
Requisiti incompleti/non chiari	Potrebbe esserci accesso a un manuale utente o a una guida di formazione, ma questi non sono la stessa cosa dei requisiti documentati. I tester dovrebbero essere coinvolti nel Ciclo di vita del test del software a partire dalla fase di definizione dei requisiti. Questo aiuta a verificare se i requisiti sono testabili.
Impostazione/identificazione dei dati	Potrebbero verificarsi situazioni in cui è necessario riutilizzare dati esistenti in base alle esigenze. A volte è difficile identificare i dati richiesti tra quelli esistenti. Per la configurazione dei dati, è possibile utilizzare strumenti sviluppati internamente, a seconda delle necessità. Per recuperare i dati esistenti, è necessario creare le query in anticipo. In caso di difficoltà, è possibile inoltrare una richiesta al team di gestione dei dati per la creazione o la clonazione dei dati necessari.
Impostazione del lavoro	Una volta che i job sono stati recuperati in PDS, è necessario configurarli nell'area di QA, in modo che non vengano inviati con un qualificatore di produzione o un dettaglio di percorso. È opportuno utilizzare strumenti di configurazione dei job per evitare errori umani durante la fase di configurazione.
Richiesta ad hoc	Potrebbero verificarsi situazioni in cui test end-to-end È necessario fornire supporto a causa di un problema nelle applicazioni a monte o a valle. Queste richieste aumentano i tempi e gli sforzi nel ciclo di esecuzione. L'utilizzo di script di automazione, script di regressione e script di base può contribuire a ridurre i tempi e gli sforzi aggiuntivi.
Rilasci puntuali per la modifica dell'ambito	Potrebbe verificarsi una situazione in cui l'impatto sul codice modifichi completamente l'aspetto e il funzionamento del sistema. Ciò potrebbe richiedere una modifica ai casi di test, agli script e ai dati. È necessario predisporre un processo di gestione delle modifiche all'ambito del progetto e un'analisi d'impatto.

Abusi comuni riscontrati

Quando un job fallisce, lo spool segnala un codice di errore (abend code). L'elenco seguente riporta i codici che un tester di mainframe incontra più frequentemente, insieme alla causa usuale.

1. S001 — Si è verificato un errore di I/O.

   Motivo: lettura alla fine del file, errore di lunghezza del file o tentativo di scrittura in un file di sola lettura.

2. S002 — Record di I/O non valido.

   Motivo: tentativo di scrivere un disco più lungo della lunghezza consentita.

3. S004 — Si è verificato un errore durante l'apertura.

   Motivo: DCB non valido.

4. S013 — Errore durante l'apertura di un dataset.

   Motivo: il membro PDS non esiste oppure la lunghezza del record nel programma non corrisponde alla lunghezza effettiva del record.

5. S0C1 - OperaEccezione zione.

   Motivo: impossibile aprire il file o carta DD mancante.

6. S0C4 — Eccezione di protezione / violazione di archiviazione.

   Motivo: tentativo di accedere a una memoria non disponibile per il programma.

7. S0C7 — Eccezione durante il controllo del programma, dati.

   Motivo: modifica del layout del record o del file.

8. Sx22 — L'offerta di lavoro è stata annullata.

   Motivo: il lavoro è stato interrotto prima del completamento; la cifra centrale identifica chi o cosa lo ha annullato.

9. S222 — Lavoro annullato dall'utente senza dump.
10. S322 — Il tempo di esecuzione del lavoro o della fase ha superato il limite specificato, oppure il programma è in un ciclo infinito, oppure il parametro TIME è insufficiente.
11. S522 — Timeout della sessione TSO.
12. S806 — Impossibile creare il collegamento o caricare il file.

    Motivo: il processo non riesce a trovare il modulo di carico specificato.

13. S80A — Spazio di archiviazione virtuale insufficiente per soddisfare le richieste GETMAIN o FREEMAIN.
14. S913 — Tentativo di accedere a un set di dati per il quale l'utente non è autorizzato.
15. Sx37 — Impossibile allocare spazio di archiviazione sufficiente al dataset.

Assistenza errori — Uno strumento molto diffuso per ottenere informazioni dettagliate su vari tipi di incidenti.

Problemi comuni riscontrati durante i test sui mainframe

• Il lavoro si interrompe — Per completare correttamente l'operazione, è necessario verificare i dati, il file di input e la presenza dei moduli nella posizione specificata. Gli errori possono verificarsi per diversi motivi, i più comuni dei quali sono dati non validi, un campo di input errato, una data non corrispondente o problemi ambientali.
• File di output vuoto — Anche se il job potrebbe essere eseguito correttamente (MaxCC 0), l'output potrebbe non essere quello previsto. Pertanto, prima di approvare qualsiasi caso di test, il tester deve assicurarsi che l'output sia stato verificato. Solo allora si può procedere con il test.
• File di input vuoto — In alcune applicazioni, i file vengono ricevuti da processi a monte. Prima di utilizzare il file ricevuto per testare l'applicazione corrente, i dati devono essere verificati incrociatamente per evitare di dover rieseguire il processo e rilavorare.

DOMANDE FREQUENTI