Testare mainframe – Tutorial complet

Înainte de a învăța conceptele de testare mainframe, să ne uităm mai întâi la platforma pe care rulează testele.

Ce este un mainframe?

Unitatea centrală (mainframe) este un sistem informatic de înaltă performanță și viteză mare. Este utilizat pentru calcul la scară largă, care necesită disponibilitate ridicată și securitate puternică. Este utilizat în principal în sectoare precum finanțele, asigurările, comerțul cu amănuntul și alte domenii critice unde volume uriașe de date sunt procesate de mai multe ori pe zi.

Testare mainframe

Testare mainframe este un proces de testare a aplicațiilor și serviciilor software bazate pe sisteme mainframe. Scopul testării mainframe este de a asigura performanța, fiabilitatea și calitatea unei aplicații software sau a unui serviciu prin metode de verificare și validare și de a verifica dacă este gata de implementare.

În timpul efectuării testelor Mainframe, testerul trebuie în principal să cunoască navigarea pe ecranele CICS. Aceste ecrane sunt construite special pentru aplicații specifice. Atunci când se fac modificări la cod în COBOL, JCL și limbaje similare, testerul nu trebuie să-și facă griji cu privire la configurarea emulatorului pe mașină, deoarece modificările care funcționează pe un emulator de terminal vor funcționa și pe celelalte.

• Aplicația Mainframe (numită și lot de joburi) este testată în funcție de cazurile de testare dezvoltate folosind cerințe.
• Testarea mainframe este de obicei efectuată pe codul implementat folosind diferite combinații de date stabilite în fișierul de intrare.
• Aplicațiile care rulează pe mainframe pot fi accesate prin intermediul unui emulator de terminal. Emulatorul este singurul software care trebuie instalat pe mașina client.

Deoarece platforma se comportă diferit față de un web stack, este util să știm ce caracteristici ale mainframe-ului determină designul testului. Prin urmare, testarea mainframe-ului se află alături de celelalte tipuri de testare software în loc să înlocuiască vreunul dintre ele.

Atribute mainframe

1. Stocare virtuală
   • Este o tehnică care permite unui procesor să simuleze stocarea principală care este mai mare decât cantitatea reală de stocare reală.
   • Este o tehnică de utilizare eficientă a memoriei pentru a stoca și a executa sarcini de diferite dimensiuni.
   • Utilizează stocarea pe disc ca o extensie a stocării reale.
2. Multiprogramare
   • Calculatorul execută mai multe programe în același timp. Dar, la un moment dat, doar un singur program poate avea controlul asupra procesorului.
   • Este o facilitate oferită pentru a utiliza eficient procesorul.
3. Procesarea loturilor
   • Este o tehnică prin care orice sarcină este îndeplinită în unități cunoscute sub numele de joburi.
   • Un job poate determina executarea unuia sau mai multor programe într-o secvență.
   • Planificatorul de job ia o decizie cu privire la ordinea în care ar trebui să fie executate joburile. Pentru a maximiza debitul mediu, lucrările sunt programate în funcție de prioritatea și clasa lor.
   • Informațiile necesare pentru procesarea în loturi sunt furnizate prin JCL (LIMBAJ DE CONTROL AL JOBURILOR). JCL descrie jobul în loturi — programele, datele și resursele necesare.
4. Împărțirea timpului
   • Într-un sistem de partajare a timpului, fiecare utilizator are acces la sistem prin intermediul dispozitivului terminal. În loc să trimită joburi care sunt programate pentru execuție ulterioară, utilizatorul introduce comenzi care sunt procesate imediat.
   • Prin urmare, aceasta se numește „Procesare interactivă”. Acesta permite utilizatorului să interacționeze direct cu computerul.
   • Procesarea în timp partajat este cunoscută sub denumirea de „Prelucrare în prim-plan”, iar procesarea lotului este cunoscută ca „Procesare în fundal”.
5. Spooling
   • SPOOLing înseamnă Periferic Simultan Operațiuni online.
   • Dispozitivul SPOOL este utilizat pentru a stoca ieșirea unui program sau a unei aplicații. Ieșirea spool este direcționată către dispozitive de ieșire, cum ar fi o imprimantă (dacă este necesar).
   • Este o facilitate care exploatează avantajul tamponării pentru a utiliza eficient dispozitivele de ieșire.

Clasificarea testării manuale în mainframe

Aceste atribute împart munca manuală de testare pe mainframe în două fluxuri clar separate.

mainframe Testarea manuală pot fi clasificate in doua tipuri:

1. Testarea lucrărilor în lot —

• Procesul de testare implică executarea de joburi în lot pentru funcționalitatea implementată în versiunea curentă.
• Rezultatele testelor ex.tracDatele extrase din fișierele de ieșire și din baza de date sunt verificate și înregistrate.

2. Testare online —

• Testarea online se referă la testarea ecranelor CICS, similară cu testarea unei pagini web.
• Funcționalitatea ecranelor existente ar putea fi modificată sau ar putea fi adăugate noi ecrane.
• Diverse aplicații pot avea ecrane de interogare și ecrane de actualizare. Funcționalitatea acestor ecrane trebuie verificată ca parte a testării online.

Cum se face testarea mainframe-ului

1. Echipa de business pregătește documentele de cerințe, care determină modul în care un anumit element sau proces va fi modificat în ciclul de lansare.
2. Echipa de testare și echipa de dezvoltare primesc documentul cu cerințe. Aceștia stabilesc câte procese vor fi afectate de modificare. De obicei, într-o lansare, doar 20-25% din aplicație este afectată direct de cerința personalizată. Restul de 75-80% din efortul de lansare se îndreaptă către funcționalitățile predefinite, cum ar fi testarea aplicațiilor și proceselor din jur.
3. Deci, o aplicație Mainframe trebuie testată în două părți:
   • Cerințe de testare — Testarea aplicației pentru funcționalitatea sau modificarea menționată în documentul de cerințe.
   • Testarea integrării — Testarea întregului proces sau a altor aplicații care primesc sau trimit date către aplicația afectată. Testarea regresiei este obiectivul principal al acestei activități de testare.

Instrumente de testare a automatizării mainframe

Mai jos este lista de instrumente care pot fi utilizate pentru mainframe Testarea automatizării.

• REXX — limbajul de scripting livrat cu z/OS, utilizat pe scară largă pentru a gestiona trimiterea repetitivă de joburi și verificările de ieșire.
• Excel — utilizat cu macrocomenzi pentru a construi, compara și genera rapoarte pe baza datelor de testare și a fișierelor de ieșire.
• OpenText UFT O — denumirea actuală a instrumentului pe care industria îl mai numește QTP sau QuickTest Professional; automatizează ecranele terminalului 3270.
• Galașă — open-source, Cadrul de testare a integrării profunde a proiectului Open Mainframe care gestionează ecrane 3270, joburi batch JCL și Db2 dintr-o pipeline CI/CD.
• Suite de teste z/OS pentru furnizori - IBM Acceleratorul de testare pentru Z și BMC AMI. DevX Total Test acoperă testarea unitară COBOL și mediile de testare virtualizate.

Indiferent de instrumentul ales, acesta se amortizează doar atunci când se află într-un spațiu întreținut cadru de automatizare a testelor mai degrabă decât o grămadă vrac de scripturi.

Metodologia în testarea mainframe-ului

Să luăm în considerare un exemplu: o companie de asigurări XYZ are un modul de înscriere a membrilor. Acesta preia date atât din ecranul de înscriere a membrilor, cât și din înscrierea offline. După cum s-a discutat anterior, există două abordări pentru testarea mainframe-ului: testarea online și testarea în lot.

• Testarea online se face pe ecranul de înscriere a membrilor. La fel ca o pagină web, baza de date este validată cu datele introduse prin intermediul ecranelor.
• Înscrierea offline poate fi înscriere pe hârtie sau înscriere pe un site web terț. Datele offline (denumite și batch) vor fi introduse în baza de date a companiei prin joburi batch. Un fișier plat de intrare este pregătit conform formatului de date prescris și introdus în secvența de joburi batch. Așadar, pentru testarea aplicațiilor mainframe putem utiliza următoarea abordare.
  • Prima lucrare din linia de lucrări în lot validează datele introduse — de exemplu, caractere speciale sau litere în câmpurile care conțin doar numere.
  • A doua sarcină validează consistența datelor pe baza condițiilor de afaceri. De exemplu, o înscriere a unui copil nu ar trebui să conțină date dependente sau un cod poștal al unui membru care nu este disponibil pentru servicii de către planul înscris.
  • A treia sarcină modifică datele în formatul care poate fi introdus în baza de date. De exemplu, ștergerea numelui planului (baza de date va stoca doar ID-ul planului și numele planului de asigurare), adăugarea datei de introducere și modificări similare.
  • Al patrulea job încarcă datele în baza de date.
• Testarea lucrărilor în lot se face în cadrul acestui proces în două faze —
  • Fiecare job este validat separat și
  • Integrarea dintre joburi este validată prin furnizarea fișierului plat de intrare primului job și validarea bazei de date. (Rezultatele intermediare trebuie validate pentru o precauție suplimentară.)

Următoarea este metoda urmată pentru testarea mainframe-ului:

Pasul 1) Testarea de shakedown/cu fum

Principalul obiectiv în această etapă este de a valida dacă codul implementat se află în mediul de testare corect. De asemenea, se asigură că nu există probleme critice cu codul. Acesta este echivalentul mainframe al Testarea fumului pe orice altă platformă.

Pas 2) Testarea sistemului

Mai jos sunt tipurile de testare efectuate ca parte a Testării sistemului.

1. Testarea loturilor — Această testare se realizează prin validarea rezultatelor testelor pe fișierele de ieșire și a modificărilor de date efectuate de joburile batch din cadrul testării și înregistrarea acestora.
2. Testare online — Această testare se face pe front-end-ul aplicației mainframe. Aici, aplicația este testată pentru câmpuri de introducere corecte, cum ar fi un plan de asigurare, dobânda la plan și valori similare.
3. Testare de integrare în loturi online — Această testare se efectuează pe sisteme care au atât procese batch, cât și o aplicație online. Fluxul de date și interacțiunea dintre ecranele online și joburile batch sunt validate.

   (Exemplu pentru acest tip de testare — Luați în considerare o actualizare a detaliilor planului, cum ar fi o creștere a ratei dobânzii. Modificarea dobânzii se face pe un ecran de actualizare, iar detaliile soldului conturilor afectate vor fi modificate doar printr-o lucrare în lot nocturnă. Testarea, în acest caz, se face prin validarea ecranului cu detaliile planului și a lucrării în lot executate pentru actualizarea tuturor conturilor.)

4. Testarea bazei de date — Bazele de date în care sunt stocate datele din aplicația mainframe (IMS, IDMS, Db2, VSAM/ISAM, seturi de date secvențiale, GDG-uri) sunt validate din punct de vedere al aspectului și stocării datelor.

Pasul 3) Sistem Testare de integrare

Scopul principal al acestei teste este de a valida funcționalitatea sistemelor care interacționează cu sistemul testat.

Aceste sisteme nu sunt afectate direct de cerințe. Cu toate acestea, ele utilizează date din sistemul testat. Este important să se testeze interfață și diferitele tipuri de mesaje (cum ar fi Lucrare reușită, Lucrare eșuată, Bază de date actualizată) care pot circula între sisteme și acțiunile rezultate întreprinse de sistemele individuale.

Tipurile de testare efectuate în această etapă sunt

1. Testarea loturilor
2. Testare online
3. Online — Testare de integrare în loturi

Pasul 4) Testarea regresiei

Testarea de regresie este o fază comună în orice tip de proiect de testare. Această testare în mainframe-uri asigură că joburile batch și ecranele online care nu interacționează direct cu sistemul testat (sau nu intră în domeniul de aplicare al cerințelor) nu sunt afectate de versiunea curentă a proiectului.

Pentru a avea o testare de regresie eficientă, ar trebui selectat un set specific de cazuri de testare în funcție de complexitatea lor și ar trebui creat un platformă de regresie (depozit de cazuri de testare). Acest set ar trebui actualizat ori de câte ori sunt implementate noi funcționalități în versiune. În cazul în care platforma de regresie este prea mare pentru a rula complet, Testare bazată pe risc este utilizat pentru a decide care joburi și ecrane sunt rulate din nou primele.

Pas 5) Test de performanta

Această testare este efectuată pentru a identifica blocajele în domeniile cu impact ridicat, cum ar fi introducerea datelor în front-end și actualizările online ale bazei de date, și pentru a estima scalabilitatea aplicației. Ferestrele de lot cu execuție lungă sunt de obicei examinate cu Testare stresanta împotriva volumelor de vârf.

Pas 6) Testarea securității

Această testare este efectuată pentru a evalua cât de bine este proiectată și dezvoltată aplicația pentru a contracara atacurile anti-securitate.

Ar trebui efectuate două teste de securitate asupra sistemului - securitatea mainframe-ului și securitatea rețelei.

Caracteristicile care trebuie testate sunt

1. Integrity
2. Confidențialitatea
3. Autorizare
4. Autentificare
5. Disponibilitate

Pași implicați în testarea în lot

1. După ce echipa de asigurare a calității primește pachetul aprobat (pachetul conține proceduri, JCL, carduri de control, module și elemente similare), testerul ar trebui să previzualizeze și să preia conținutul în PDS, după cum este necesar.
2. Conversia JCL-ului de producție sau a JCL-ului de dezvoltare în JCL QA, denumit și JOB SETUP.
3. Copiați fișierul de producție și pregătiți fișierele de test.
4. Pentru fiecare funcționalitate, va exista o secvență de joburi definită (așa cum este explicat în exemplul din secțiunea Metodologie în testarea mainframe-ului). Joburile ar trebui trimise folosind comanda SUB împreună cu fișierele de date de testare.
5. Verificați fișierul intermediar pentru a identifica motivele pentru datele lipsă sau eronate.
6. Verificați fișierul de ieșire final, baza de date și Spool-ul pentru a valida rezultatele testului.
7. Dacă jobul eșuează, spool-ul va avea motivul eșecului jobului. Remediați eroarea și retrimiteți lucrarea.

Raportarea testelor - A defect ar trebui înregistrată dacă rezultatul real deviază de rezultatul așteptat.

Pași implicați în testarea online

1. Selectați ecranul Online într-un Mediu de testare.
2. Testați fiecare câmp pentru datele acceptabile.
3. Testați Scenariu de testare pe ecran.
4. Verificați baza de date pentru actualizările de date de pe ecranul online.

Raportarea testelor — Un defect trebuie înregistrat dacă rezultatul real deviază de rezultatul așteptat.

Pași implicați în testarea online — integrare în lot

1. Executați jobul într-un mediu de testare și validați datele pe ecranele online.
2. Actualizați datele pe ecranele online și validați dacă jobul batch rulează corect cu datele actualizate.

Comenzi utilizate în testarea mainframe-ului

Acești pași sunt executați din terminal, așa că un vocabular scurt de comenzi acoperă cea mai mare parte a zilei unui tester.

1. TRIMITE — Trimiteți o lucrare de fundal.
2. ANULARE — Anulați o lucrare în fundal.
3. ALOCA — Alocați un set de date.
4. COPIE — Copiați un set de date.
5. REDENUMIȚI — Redenumiți un set de date.
6. DELETE — Ștergeți un set de date.
7. SCANAREA JOBULUI — Leagă JCL-ul cu programul, bibliotecile, fișierele și alte resurse fără a-l executa.

Există multe alte comenzi folosite atunci când este necesar, dar nu sunt atât de frecvente.

Cerințe preliminare pentru începerea testării mainframe-ului

Detaliile de bază necesare pentru testarea mainframe-ului sunt:

• ID de autentificare și parola pentru autentificarea în aplicație.
• Scurtă cunoaștere a comenzilor ISPF.
• Numele fișierelor, calificatorul de fișier și tipurile acestora.

Înainte de a începe testarea mainframe-ului, trebuie verificate următoarele aspecte.

1. Loc de munca
   • Efectuați o scanare a jobului (comanda — JOBSCAN) pentru a verifica dacă există erori înainte de a o executa.
   • Parametrul CLASS ar trebui să fie orientat către clasa de testare.
   • Direcționați ieșirea jobului în spool sau într-un JHS sau, după cum este necesar, utilizând parametrul MSGCLASS.
   • Redirecționează e-mailul din job către spool sau către un ID de e-mail de test.
   • Comentați pașii FTP pentru testarea inițială și apoi direcționați jobul către un server de testare.
   • În cazul în care în cadrul jobului se generează o înregistrare IMR (Incident Management Record - Înregistrare de gestionare a incidentelor), adăugați comentariul „TESTING PURPOSE” în ​​job sau în fișa de parametri.
   • Toate bibliotecile de producție din job ar trebui să fie modificate și direcționate către biblioteci de testare.
   • Lucrarea nu trebuie lăsată nesupravegheată.
   • Pentru a preveni rularea jobului într-o buclă infinită în cazul oricărei erori, parametrul TIME trebuie adăugat cu un timp specificat.
   • Salvați rezultatul lucrării, inclusiv bobina. Bobina poate fi salvată folosind XDC.
2. Fișier
   • Creați un fișier de test doar de dimensiunea necesară. Folosiți GDG-uri (Generation Data Groups - fișiere cu același nume, dar cu numere de versiune secvențiale, cum ar fi MYLIB.LIB.TEST.G0001V00 și MYLIB.LIB.TEST.G0002V00) atunci când este necesar pentru a stoca date în fișiere consecutive cu același nume.
   • Parametrul DISP (Disposition — indică sistemului dacă să păstreze sau să șteargă setul de date după terminarea normală sau anormală a etapei sau a jobului) pentru fișiere trebuie să fie codificat corect.
   • Asigurați-vă că toate fișierele utilizate pentru execuția jobului sunt salvate și închise corect pentru a preveni intrarea jobului în HOLD.
   • În timp ce testați folosind GDG-uri, asigurați-vă că este indicată versiunea corectă.
3. Baza de date
   • În timpul executării jobului sau a programului online, asigurați-vă că nu sunt introduse, actualizate sau șterse date neintenționate.
   • De asemenea, asigurați-vă că regiunea Db2 corectă este utilizată pentru testare.
4. Cazuri de testare
   • Testați întotdeauna condițiile limită, cum ar fi un fișier gol, prima înregistrare procesată și ultima înregistrare procesată.
   • Includeți întotdeauna condițiile de testare atât pozitive, cât și negative.
   • În cazul în care în program se utilizează proceduri standard, cum ar fi repornirea la puncte de control, modulele de tip abence sau fișierele de control, includeți Caz de testarepentru a valida dacă modulele au fost utilizate corect.
5. Date de testare
   • Configurarea datelor de testare trebuie făcută înainte de începerea testării.
   • Nu modificați niciodată datele din regiunea de testare fără a anunța alte persoane. Este posibil ca alte echipe să lucreze cu aceleași date, iar testele lor ar eșua.
   • În cazul în care fișierele de producție sunt necesare în timpul execuției, trebuie obținută autorizarea corespunzătoare înainte de copiere sau utilizare.

Cele mai bune practici

1. În cazul executării unei sarcini în lot, MAX CC 0 este un indicator că sarcina a fost executată cu succes. Nu înseamnă că funcționalitatea funcționează corect. Sarcina va rula cu succes chiar și atunci când ieșirea este goală sau nu conform așteptărilor. Prin urmare, este întotdeauna de așteptat să se verifice toate ieșirile înainte de a declara sarcina ca fiind reușită.
2. Este întotdeauna o practică bună să se facă o simulare a jobului testat. O simulare se face cu fișiere de intrare goale. Acest proces trebuie urmat pentru joburile care sunt afectate de modificările aduse pentru ciclul de testare.
3. Înainte de începerea ciclului de testare, configurarea jobului de testare ar trebui făcută cu mult timp înainte. Acest lucru ajută la descoperirea oricărei erori JCL în avans, economisind astfel timp în timpul execuției.
4. Când accesați tabele Db2 prin SPUFI (o opțiune din emulator pentru accesarea tabelelor Db2), setați întotdeauna auto commit la „NO” pentru a evita actualizările accidentale.
5. Disponibilitatea datelor de testare este principala provocare în testarea în loturi. Datele necesare ar trebui create cu mult timp înainte de ciclul de testare și ar trebui verificate pentru a fi complete. Tracking acea pregătire într-un mod comun managementul testelor repozitoriul menține patul de regresie și configurația datelor aliniate.
6. Unele tranzacții online și joburi batch pot scrie date în MQ-uri (cozi de mesaje) pentru transmittransferul de date către alte aplicații. Dacă datele nu sunt valide, MQ-urile pot fi dezactivate sau oprite, iar acest lucru va afecta întregul proces de testare. Este o practică bună să verificați dacă MQ-urile funcționează corect după testare.

Provocări și depanare a testelor mainframe

Chiar și cu aceste practici implementate, câteva probleme reapar la aproape fiecare versiune de mainframe. Tabelul de mai jos prezintă fiecare problemă asociată cu abordarea care o rezolvă.

Activități	Abordarea
Cerințe incomplete/neclare	Poate exista acces la un manual de utilizare sau un ghid de instruire, dar acestea nu sunt același lucru cu cerințele documentate. Testerii ar trebui să fie implicați în ciclul de viață al testării software de la faza cerințelor încolo. Acest lucru ajută la verificarea dacă cerințele sunt testabile.
Configurarea / Identificarea datelor	Pot exista situații în care datele existente trebuie reutilizate conform cerințelor. Uneori este dificil să se identifice datele necesare dintre datele existente. Pentru configurarea datelor, se pot utiliza instrumente proprii, în funcție de necesități. Pentru preluarea datelor existente, interogările trebuie construite în prealabil. În caz de dificultate, se poate depune o cerere la echipa de management al datelor pentru crearea sau clonarea datelor necesare.
Configurare job	Odată ce joburile sunt preluate în PDS, acesta trebuie configurat în regiunea QA, astfel încât joburile să nu fie trimise cu un calificator de producție sau un detaliu al căii. Instrumentele de configurare a joburilor ar trebui utilizate pentru a depăși erorile umane produse în timpul configurării.
Cerere ad-hoc	Pot exista situații când testare de la capăt la capăt trebuie să fie suportat din cauza unei probleme în aplicațiile din amonte sau din aval. Aceste solicitări cresc timpul și efortul din ciclul de execuție. Utilizarea scripturilor de automatizare, a scripturilor de regresie și a scripturilor schelet poate ajuta la reducerea timpului și a efortului suplimentar.
Lansări la timp pentru modificarea domeniului de aplicare	Poate exista o situație în care impactul codului schimbă complet aspectul și funcționalitatea sistemului. Acest lucru poate necesita o modificare a cazurilor de testare, a scripturilor și a datelor. Ar trebui implementate un proces de gestionare a modificărilor domeniului de aplicare și o analiză a impactului.

Abrupturi frecvente întâlnite

Când o lucrare eșuează, spool-ul raportează un cod de terminare abruptă. Lista de mai jos prezintă codurile pe care un tester mainframe le întâlnește cel mai des, împreună cu cauza obișnuită.

1. S001 — A apărut o eroare de intrare/ieșire.

   Motiv — Citire la sfârșitul fișierului, eroare de lungime a fișierului sau o încercare de scriere într-un fișier doar pentru citire.

2. S002 — Înregistrare I/O nevalidă.

   Motiv — Încercare de a scrie o înregistrare mai lungă decât lungimea înregistrării.

3. S004 — A apărut o eroare în timpul DESCHIDERII.

   Motiv — DCB nevalid.

4. S013 — Eroare la deschiderea unui set de date.

   Motiv — Membrul PDS nu există sau lungimea înregistrării din program nu corespunde cu lungimea reală a înregistrării.

5. S0C1 - OperaExcepție de la țiune.

   Motiv — Imposibil de deschis fișierul sau lipsește cardul DD.

6. S0C4 — Excepție de protecție / încălcare a stocării.

   Motiv — Încercarea de a accesa spațiu de stocare care nu este disponibil programului.

7. S0C7 — Excepție de verificare a programului, date.

   Motiv — Modificare a aspectului înregistrării sau a aspectului fișierului.

8. Sx22 — Lucrarea a fost anulată.

   Motiv — Lucrul a fost încheiat înainte de finalizare; cifra din mijloc identifică cine sau ce l-a anulat.

9. S222 — Lucrare anulată de utilizator fără dump.
10. S322 — Timpul jobului sau al pasului a depășit limita specificată sau programul se află într-o buclă sau parametrul TIME este insuficient.
11. S522 — Expirare sesiune TSO.
12. S806 — Nu se poate crea legătura sau încărca.

    Motiv — Lucrul nu poate găsi modulul de încărcare specificat.

13. S80A — Nu există suficient spațiu de stocare virtual pentru a satisface cererile GETMAIN sau FREEMAIN.
14. S913 — Încercarea de a accesa un set de date pe care utilizatorul nu este autorizat să îl utilizeze.
15. Sx37 — Nu se poate aloca suficient spațiu de stocare setului de date.

Asistență la erori — Un instrument foarte popular pentru a obține informații detaliate despre diverse tipuri de abateri.

Probleme frecvente întâlnite în timpul testării mainframe-ului

• Job Abends — Pentru finalizarea cu succes a lucrării, trebuie să verificați datele, fișierul de intrare și dacă modulele sunt prezente în locația specifică. Terminările anormale pot apărea din mai multe motive, cele mai frecvente fiind date nevalide, un câmp de intrare incorect, o nepotrivire de dată sau probleme de mediu.
• Fișierul de ieșire este gol — Deși jobul s-ar putea executa cu succes (MaxCC 0), rezultatul s-ar putea să nu fie cel așteptat. Așadar, înainte de a trece orice caz de testare, testerul trebuie să se asigure că rezultatul este verificat încrucișat. Numai atunci testarea ar trebui continuată.
• Fișierul de intrare este gol — În unele aplicații, fișierele sunt primite de la procesele din amonte. Înainte de a utiliza fișierul primit pentru testarea aplicației curente, datele ar trebui verificate încrucișat pentru a evita reexecuția și relucrarea.

Întrebări frecvente