Testare mainframe – Tutorial complet

Înainte de a învăța conceptele de testare mainframe, să învățăm

Ce este un mainframe?

Mainframe-ul este un sistem informatic de înaltă performanță și de mare viteză. Este folosit pentru scopuri de calcul la scară mai mare, care necesită o mare disponibilitate și securitate. Este folosit mai ales în sectoare precum finanțele, asigurările, comerțul cu amănuntul și alte domenii critice în care date uriașe sunt procesate de mai multe ori.

Testare mainframe

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

În timpul testării mainframe-ului, testerul trebuie să știe doar despre navigarea ecranelor CICS. Sunt construite la comandă pentru aplicații specifice. Orice modificare adusă codului în testerul COBOL, JCL etc. nu trebuie să-și facă griji cu privire la emulatorul configurat pe mașină. Modificările care funcționează pe un emulator de terminal vor funcționa și pe altele.

• Aplicația Mainframe (denumită în alt mod lot de joburi) este testată în raport cu 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 emulator de terminal. Emulatorul este singurul software care trebuie instalat pe computerul client.

Atribute mainframe

1. Stocare virtuală
   1. Este o tehnică care permite unui procesor să simuleze stocarea principală care este mai mare decât cantitatea reală de stocare reală.
   2. Este o tehnică de utilizare eficientă a memoriei pentru a stoca și a executa sarcini de diferite dimensiuni.
   3. Utilizează stocarea pe disc ca o extensie a stocării reale.
2. Multiprogramare
   1. Computerul execută mai multe programe în același timp. Dar, în orice moment, un singur program poate avea controlul asupra CPU.
   2. Este o facilitate oferită pentru a utiliza eficient procesorul.
3. Procesarea loturilor
   1. Este o tehnică prin care orice sarcină este îndeplinită în unități cunoscute sub numele de joburi.
   2. Un job poate determina executarea unuia sau mai multor programe într-o secvență.
   3. 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.
   4. Informațiile necesare procesării loturilor sunt furnizate prin JCL (LIMBAJUL DE CONTROL AL LUCRURILOR). JCL descrie sarcina batch – programe, date și resurse necesare.
4. Împărțirea timpului
   1. Î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.
   2. Prin urmare, aceasta se numește „Procesare interactivă”. Acesta permite utilizatorului să interacționeze direct cu computerul.
   3. Procesarea în timp partajat este cunoscută sub denumirea de „Prelucrare în prim-plan”, iar procesarea lotului este cunoscută ca „Procesare în fundal”.
5. Spooling
   1. SPOOLing înseamnă Periferic simultan Operations Online.
   2. Dispozitivul SPOOL este utilizat pentru a stoca rezultatul programului/aplicației. Ieșirea în spool este direcționată către dispozitive de ieșire, cum ar fi o imprimantă (dacă este necesar).
   3. Este o facilitate care exploatează avantajul tamponării pentru a utiliza eficient dispozitivele de ieșire.

Clasificarea testării manuale în mainframe

mainframe Testarea manuală pot fi clasificate in doua tipuri:

1. Testarea lucrărilor pe lot -

• Procesul de testare implică execuții de joburi batch pentru funcționalitatea implementată în versiunea curentă.
• Rezultatul testului extras 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, care este similară cu testarea paginii 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 afaceri pregătește documentele cerințelor. Care determină modul în care un anumit articol sau proces va fi modificat în ciclul de lansare.
2. Echipa de testare și dezvoltarea primesc documentul de cerință. Ei își vor da seama câte procese vor fi afectate de schimbare. De obicei, într-o versiune, doar 20-25% din aplicație este afectată direct de cerința personalizată. Celelalte 75% din lansare vor fi pentru funcționalitățile out-box, cum ar fi testarea aplicațiilor și proceselor.
3. Deci, o aplicație Mainframe trebuie testată în două părți:
   1. Cerințe de testare – Testarea aplicației pentru funcționalitatea sau modificarea menționată în documentul de cerință.
   2. Testarea integrării – Testarea întregului proces sau a altei 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
• Excel
• QTP

Metodologia în testarea mainframe-ului

Să luăm în considerare un exemplu: o companie de asigurări XYZ are modul de înscriere a membrilor. Preia date atât din ecranul de înscriere a membrilor, cât și din înregistrarea offline. După cum am discutat mai devreme, este nevoie de două abordări pentru testarea mainframe, testarea online și testarea pe lot.

• Testare online se face pe ecranul de înscriere a membrilor. La fel ca o pagină web, baza de date este validată cu datele introduse prin ecrane.
• Înscriere offline poate fi o înscriere pe hârtie sau o înscriere pe un site web terță parte. Datele offline (numite și lot) vor fi introduse în baza de date a companiei prin joburi în lot. Un fișier plat de intrare este pregătit conform formatului de date prescris și alimentat în secvența de joburi lot. Deci, pentru testarea aplicațiilor mainframe, putem folosi următoarea abordare.
• Primul job din linia de joburi lot validează datele introduse. Să spunem, de exemplu, caractere speciale, alfabete în câmpuri numai cu numere etc.
• Al doilea job validează consistența datelor pe baza condițiilor de afaceri. De exemplu, o înscriere a unui copil nu trebuie să conțină date dependente, cod poștal membru (care nu este disponibil pentru service de către planul înscris), etc.
• Al treilea job 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 intrare etc.
• Al patrulea job încarcă datele în baza de date.
• Testarea sarcinilor pe lot se realizează pe acest proces în două faze -
• Fiecare job este validat separat, iar
• Integrarea între joburi este validată prin furnizarea unui fișier plat de intrare la primul job și prin validarea bazei de date. (Rezultatele intermediare trebuie validate pentru precauție suplimentară)

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

Pas 1) Pat pliant/Testarea fumului

Accentul principal în această etapă este de a valida dacă codul implementat se află în mediul de testare potrivit. De asemenea, asigură că nu există probleme critice cu codul.

Pas 2) Testarea sistemului

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

1. Testarea loturilor – Această testare va fi efectuată prin validarea rezultatelor testelor pe fișierele de ieșire și modificările datelor efectuate de joburile batch aflate în domeniul de testare și înregistrarea acestora.
2. Testare online – Această testare se va face pe partea frontală a aplicației mainframe. Aici aplicația este testată pentru câmpul de intrare corect, cum ar fi un plan de asigurare, dobândă pentru plan etc.
3. Testare de integrare în loturi online – Această testare se va face pe sistemele care au procese batch și aplicație online. Fluxul de date și interacțiunea dintre ecranele online și joburile lot sunt validate.

   (Exemplu pentru acest tip de testare – Luați în considerare o actualizare a detaliilor planului, cum ar fi creșterea ratei dobânzii. Schimbarea interesului se face pe un ecran de actualizare, iar detaliile soldului de pe conturile afectate vor fi modificate doar printr-un job batch nocturn. Testarea în acest caz se va face prin validarea ecranului Detalii plan și rularea jobului batch pentru actualizarea tuturor conturilor).

4. Testarea bazei de date – Bazele de date în care datele din aplicația mainframe (IMS, IDMS, DB2, VSAM/ISAM, Sequential datasets, GDG) sunt validate pentru layout-ul și stocarea datelor.

Pas 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 direct afectate de cerințe. Cu toate acestea, folosesc date din sistemul testat. Este important să testați interfața și diferitele tipuri de mesaje (cum ar fi Lucrul cu succes, Lucrarea eșuată, Baza de date actualizată etc.) 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

Pas 4) Testarea regresiei

Testarea de regresie este o fază comună în orice tip de proiect de testare. Această testare în mainframes asigură că lucrările în lot ș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ă, un anumit set de cazuri de testare ar trebui să fie selectat pe lista scurtă în funcție de complexitatea lor și ar trebui creat un pat de regresie (depozitul de cazuri de testare). Acest set ar trebui să fie actualizat ori de câte ori este lansată o nouă funcționalitate în versiune.

Pas 5) Test de performanta

Această testare este efectuată pentru a identifica blocajele din zonele cu impact ridicat, cum ar fi datele front-end, actualizarea bazelor de date online și pentru a proiecta scalabilitatea aplicației.

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.

Trebuie efectuate două teste de securitate pe sistem – 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 lotului

1. După ce echipa QA primește pachetul aprobat (Pachetul conține proceduri, JCL, carduri de control, module etc.), testerul trebuie să previzualizeze și să preia conținutul în PDS după cum este necesar.
2. Convertiți JCL de producție sau JCL de dezvoltare în JCL QA, altfel numit JOB SETUP.
3. Copierea fișierului de producție și pregătirea fișierelor de testare.
4. Pentru fiecare funcționalitate, va fi definită o secvență de job. (Așa cum este explicat în exemplul din Metodologie din secțiunea Mainframe). Joburile trebuie trimise folosind comanda SUB cu fișierele de date de testare.
5. Verificați fișierul intermediar pentru a identifica motivele lipsei sau ale erorilor de date.
6. Verificați fișierul final de ieșire, 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 - Defect ar trebui să fie înregistrat dacă rezultatul real se abate de la 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.

Raportare test – Defectul trebuie înregistrat dacă rezultatul real se abate de la așteptat.

Pași implicați în testarea online – integrare în loturi

1. Rulați lucrarea într-un Mediu de testare și validați datele de pe ecranele online.
2. Actualizați datele de pe ecranele online și validați dacă jobul lot este rulat corect cu datele actualizate.

Comenzi utilizate în testarea mainframe-ului

1. TRIMITE – Trimiteți un job de fundal.
2. CANCEL – Anulați lucrarea de fundal.
3. ALLOCATE – Alocați un set de date
4. COPIE – Copiați un set de date
5. RENAME – Redenumiți setul de date
6. DELETE – Șterge setul de date
7. JOB SCAN – Pentru a lega JCL-ul cu programul, bibliotecile, fișierul etc. fără a-l executa.

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

Condiții preliminare pentru a începe testarea mainframe-ului

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

• ID de autentificare și parola pentru autentificarea în aplicație.
• Scurte cunoștințe despre comenzile ISPF.
• Numele fișierelor, calificativul fișierelor și tipurile acestora.

Înainte de a începe testarea mainframe-ului, trebuie verificate aspectele de mai jos.

1. Loc de munca
   1. Efectuați o scanare a lucrării (Comandă – JOBSCAN) pentru a verifica dacă există erori înainte de a o executa.
   2. Parametrul CLASS ar trebui să fie îndreptat către clasa de testare.
   3. Direcționați ieșirea lucrării în spool sau într-un JHS sau după cum este necesar utilizând parametrul MSGCLASS.
   4. Redirecționați e-mailul în job la spool sau un ID de e-mail de testare.
   5. Comentați pașii FTP pentru testarea inițială și apoi direcționați jobul către un server de testare.
   6. În cazul în care un IMR (înregistrare de gestionare a incidentelor) este generat în job, trebuie doar să adăugați comentariul „SCOPIUL DE TESTARE” în ​​job sau card de parametri.
   7. Toate bibliotecile de producție din job ar trebui să fie modificate și direcționate către biblioteci de testare.
   8. Lucrarea nu trebuie lăsată nesupravegheată.
   9. Pentru a preveni rularea jobului într-o buclă infinită în cazul oricărei erori, parametrul TIME trebuie adăugat cu timpul specificat.
   10. Salvați rezultatul lucrării, inclusiv bobina. Bobina poate fi salvată folosind XDC.

2. Fișier
   1. Creați fișierul de test numai cu dimensiunea necesară. Utilizați GDG-uri (Grupuri de date de generație – Fișiere cu același nume, dar cu numere de versiune secvențiale – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 și așa mai departe) atunci când este necesar pentru a stoca date în fișiere consecutive cu același nume.
   2. Parametrul DISP (Disposition – descrie sistemul care trebuie să efectueze păstrarea sau ștergerea setului de date după terminarea normală sau anormală a pasului sau a sarcinii) pentru fișiere ar trebui să fie codificate corect.
   3. Asigurați-vă că toate fișierele utilizate pentru executarea jobului sunt salvate și închise corect pentru a preveni ca jobul să intre în HOLD.
   4. În timp ce testați folosind GDG-uri, asigurați-vă că este indicată versiunea corectă.
3. Baza de date
   1. În timp ce executați lucrarea sau programul online, asigurați-vă că datele neintenționate nu sunt inserate, actualizate sau șterse.
   2. De asemenea, asigurați-vă că regiunea DB2 corectă este utilizată pentru testare.
4. Cazuri de testare
   1. Testați întotdeauna condițiile limită precum – Fișier gol, Procesarea primei înregistrări, Procesarea ultimei înregistrări etc.
   2. Includeți întotdeauna condițiile de testare atât pozitive, cât și negative.
   3. În cazul în care în program sunt utilizate proceduri standard, cum ar fi repornirea punctului de verificare, modulele Abend, fișierele de control etc. includ cazuri de testare pentru a valida dacă modulele au fost utilizate corect.
5. Date de testare
   1. Configurarea datelor de testare trebuie făcută înainte de începerea testării.
   2. Nu modificați niciodată datele din regiunea de testare fără a anunța. Pot exista alte echipe care lucrează cu aceleași date, iar testul lor ar eșua.
   3. Î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 rulării unui job în lot, MAX CC 0 este un indicator că jobul a rulat cu succes. Nu înseamnă că funcționalitatea funcționează bine. Lucrarea va rula cu succes chiar și atunci când rezultatul este gol sau nu conform așteptărilor. Prin urmare, se așteaptă întotdeauna să se verifice toate ieșirile înainte de a declara jobul reușit.
2. Este întotdeauna o practică bună să faceți o rulare uscată a lucrării testate. Funcția uscată se face cu fișiere de intrare goale. Acest proces ar trebui urmat pentru lucrările care sunt afectate de modificările efectuate pentru ciclul de testare.
3. Înainte de începerea ciclului de testare, configurarea lucrării de testare trebuie făcută cu mult înainte. Acest lucru va ajuta la identificarea oricărei erori JCL în avans, economisind astfel timp în timpul execuției.
4. În timp ce accesați tabelele DB2 prin SPUFI (Opțiune de pe emulator pentru a accesa tabelele DB2), setați întotdeauna autocommit ca „NU” pentru a evita actualizările accidentale.
5. Disponibilitatea datelor de testare este principala provocare în testarea loturilor. Datele necesare trebuie create cu mult înainte de ciclul de testare și trebuie verificate pentru a fi complete.
6. Unele tranzacții online și joburi batch pot scrie date în MQ-uri (Message Queue) pentru transmiterea datelor către alte aplicații. Dacă datele nu sunt valide, pot dezactiva/opri MQ-urile, acest lucru va afecta întregul proces de testare. Este o practică bună să verificați dacă MQ-urile funcționează bine după testare.

Provocări și depanare de testare mainframe

Provocări	Abordarea
Cerințe incomplete/neclare Poate exista acces la manualul utilizatorului/ghidul de instruire, dar acestea nu sunt aceleași cu cerințele documentate.	Testerii ar trebui să fie implicați în SDLC începând cu faza de cerințe. Acest lucru va ajuta la verificarea dacă cerințele sunt testabile.
Configurare/Identificare datelor Pot exista situații în care datele existente ar trebui reutilizate conform cerințelor. Uneori este dificil să identifici datele necesare din datele existente.	Pentru configurarea datelor, instrumentele de origine pot fi utilizate în funcție de nevoi. Pentru preluarea datelor existente, interogările ar trebui să fie construite în avans. În cazul oricărei dificultăți, o solicitare poate fi adresată echipei de gestionare a datelor pentru crearea sau clonarea datelor necesare.
Configurare job Odată ce joburile sunt preluate în PDS, jobul trebuie configurat în regiunea QA. Pentru ca locurile de muncă să nu fie depuse cu calificativ de producție sau detaliu de cale.	Instrumentele de configurare a lucrărilor ar trebui utilizate pentru a depăși erorile umane făcute în timpul configurării.
Cerere ad-hoc Pot exista situații în care testarea de la capăt la capăt trebuie să fie suportată din cauza unei probleme legate de problemele aplicației din amonte sau din aval. Aceste solicitări măresc timpul și efortul în ciclul de execuție.	Utilizarea scripturilor de automatizare, a scripturilor de regresie și a scripturilor schelet ar putea ajuta la reducerea timpului și efortului general.
Lansări la timp pentru modificarea domeniului de aplicare Poate exista o situație în care impactul codului poate schimba complet aspectul și senzația sistemului. Acest lucru poate necesita o modificare a cazurilor de testare, a scripturilor și a datelor.	Procesul de management al schimbării domeniului și analiza impactului ar trebui să fie în vigoare.

Abends comune întâlnite

1. S001 – A apărut o eroare I/O.

   Motiv – Citirea la sfârșitul fișierului, eroare de lungime a fișierului, încercarea de a scrie într-un fișier de numai citire.

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

   Motiv – Încercați să scrieți o înregistrare mai lungă decât lungimea înregistrării.

3. S004 – A apărut o eroare în timpul DESCHIS.

   Motiv – DCB invalid

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

   Motiv – membru PDS nu există, lungimea înregistrării în program nu se potrivește cu lungimea reală a înregistrării.

5. S0C1 – OperaExcepție

   Motiv – Nu se poate deschide fișierul, lipsește cardul DD

6. S0C4 – Excepție de protecție/ Încălcare stocare
7. Motiv – Încercarea de acces la stocarea nu este disponibilă pentru program.
8. S0C7 – Excepție de verificare a programului – Date
9. Motiv – Modificarea aspectului înregistrării sau a aspectului fișierului.
10. Sx22 – Lucrarea a fost anulată
11. S222 – Lucrări anulate de utilizator fără un dump.
12. S322 – Timpul de lucru sau de pas a depășit limita specificată sau programul este într-o buclă sau un parametru de timp insuficient.
13. S522 – Timeout sesiunea TSO.
14. S806 – Imposibil de conectat sau încărcat.

    Motiv – ID-ul jobului nu poate găsi modulul de încărcare specificat.

15. S80A – Nu este suficient spațiu de stocare virtual pentru a satisface solicitările GETMAIN sau FREEMAIN.
16. S913 – Încercarea de a accesa setul de date pe care utilizatorul nu este autorizat.
17. Sx37 – Nu se poate aloca spațiu de stocare suficient pentru setul de date.

Asistență pentru erori – Un instrument foarte popular pentru a obține informații detaliate despre diferite tipuri de abend.

Problemă frecventă cu care se confruntă în timpul testării mainframe-ului

• Job Abends – Pentru finalizarea cu succes a lucrării, ar trebui să verificați datele, fișierul de intrare și modulele prezente în locația specifică sau nu. Abends-urile pot fi confruntate din mai multe motive, cele mai frecvente fiind: date invalide, câmp de intrare incorect, nepotrivire a datei, probleme de mediu etc.
• Fișierul de ieșire este gol–Deși job-ul poate rula cu succes (MaxCC 0), rezultatul ar putea să nu fie așa de așteptat. Deci, înainte de a trece orice caz de testare, testerul trebuie să se asigure că rezultatul este verificat încrucișat. Abia apoi continuați.
• Fișierul de intrare este gol – În unele aplicații, fișierele vor fi primite din procesele din amonte. Înainte de a utiliza fișierul primit pentru testarea aplicației curente, datele trebuie verificate încrucișat pentru a evita reexecuția și reluarea.

Rezumat

• Testarea mainframe este ca orice altă procedură de testare pornind de la colectarea cerințelor, proiectarea testelor, execuția testului și raportarea rezultatelor.
• Pentru a testa aplicația în mod eficient, testatorul ar trebui să participe la întâlnirile de proiectare programate de echipele de dezvoltare și de afaceri.
• Este obligatoriu ca testerul să se obișnuiască cu diferite funcții de testare mainframe. Cum ar fi navigarea pe ecran, crearea fișierelor și PDS, salvarea rezultatelor testelor etc. înainte de începerea ciclului de testare.
• Testarea aplicațiilor mainframe este un proces care necesită timp. Trebuie urmat un program clar de testare pentru proiectarea testului, configurarea datelor și execuția.
• Testarea în lot și testarea online ar trebui să fie efectuate eficient, fără a pierde nicio funcționalitate menționată în documentul de cerințe și nu Caz de testare ar trebui cruțat.