Înainte de a învăța conceptele de testare mainframe, să învățăm
Ce este un mainframe?
Mainframe-ul este un sistem computerizat de înaltă performanță și de mare viteză. Este utilizat în scopuri de calcul la scară mai mare, care necesită o disponibilitate și o securitate foarte mari. Este utilizat mai ales în sectoare precum finanțele, asigurările, comerțul cu amănuntul și alte domenii critice în care datele imense sunt procesate de mai multe ori.
Testarea mainframe-ului
Mainframe Testing este un proces de testare a aplicațiilor și serviciilor software bazate pe sistemele Mainframe. Scopul testării mainframe-ului este de a asigura performanța, fiabilitatea și calitatea aplicației sau serviciilor software prin metode de verificare și validare și de a verifica dacă este gata de implementare.
În timpul efectuării testării Mainframe, testerul trebuie doar să știe despre navigarea pe ecranele CICS. Acestea sunt construite personalizat pentru aplicații specifice. Orice modificare adusă codului în testerul COBOL, JCL etc. nu trebuie să vă faceți griji cu privire la emulatorul configurat pe aparat. Modificările care funcționează pe un emulator de terminal vor funcționa pe altele.
- Aplicația Mainframe (altfel numită job batch) este testată în funcție de cazurile de test dezvoltate folosind cerințe
- Testarea mainframe-ului se efectuează de obicei pe codul implementat folosind diverse combinații de date stabilite în fișierul de intrare.
- Aplicațiile care rulează pe mainframe pot fi accesate prin intermediul emulatorului terminal. Emulatorul este singurul software care trebuie instalat pe computerul client.
În acest tutorial pentru începători, veți învăța-
- Atribute Mainframe
- Clasificarea testării manuale în mainframe
- Cum se face testarea mainframe
- Instrumente de testare a automatizării mainframe
- Metodologie în testarea mainframe
- Pașii implicați în testarea lotului
- Pașii implicați în testarea online
- Pași implicați în testarea online - integrarea loturilor
- Comenzi utilizate în testarea mainframe
- Condiții prealabile pentru a începe testarea mainframe-ului
- Cele mai bune practici
- Testarea mainframe-ului Provocări și depanare
- Abenduri comune întâlnite
- Problemă comună cu care se confruntă în timpul testării mainframe
Atribute Mainframe
- 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 executa sarcini de diferite dimensiuni.
- Utilizează stocarea pe disc ca o extensie a stocării reale.
- Multiprogramare
- Computerul execută mai multe programe în același timp. Dar, la un moment dat, un singur program poate controla CPU.
- Este o facilitate oferită pentru a face o utilizare eficientă a procesorului.
- Prelucrarea în serie
- Este o tehnică prin care orice sarcină este realizată în unități cunoscute sub numele de joburi.
- O lucrare poate determina executarea unuia sau mai multor programe într-o secvență.
- Planificatorul de lucrări ia o decizie cu privire la ordinea în care trebuie executate lucrările. Pentru a maximiza debitul mediu, joburile sunt programate în funcție de prioritate și clasă.
- Informațiile necesare pentru procesarea loturilor sunt furnizate prin JCL (JOB CONTROL LANGUAGE). JCL descrie jobul lot - programe, date și resurse necesare.
- Partajarea timpului
- Într-un sistem de partajare a timpului, fiecare utilizator are acces la sistem prin intermediul dispozitivului terminal. În loc să trimită lucrări programate pentru o execuție ulterioară, utilizatorul introduce comenzi care sunt procesate imediat.
- Prin urmare, aceasta se numește „Procesare interactivă”. Permite utilizatorului să interacționeze direct cu computerul.
- Procesarea de partajare a timpului este cunoscută sub denumirea de „Prelucrare de prim plan”, iar prelucrarea loturilor este cunoscută sub numele de „Procesare în fundal”.
- Spooling
- SPOOLing înseamnă Operări periferice simultane online .
- Dispozitivul SPOOL este utilizat pentru a stoca ieșirea programului / aplicației. Ieșirea spool este direcționată către dispozitivele 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
Testarea manuală mainframe poate fi clasificată în două tipuri:
- Testare pe loturi -
- 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 baza de date sunt verificate și înregistrate.
- 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 ecrane noi.
- 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
- Echipa de afaceri pregătește documentele privind cerințele. Care determină modul în care un anumit element sau proces va fi modificat în ciclul de lansare.
- 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 versiune vor fi pentru funcționalitățile out-box, cum ar fi testarea aplicațiilor și proceselor.
- 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ță.
- Testarea integrării - Testarea întregului proces sau a altei aplicații care primesc sau trimit date către aplicația afectată. Testarea prin regresie este centrul principal al acestei activități de testare.
Instrumente de testare a automatizării mainframe
Mai jos este lista instrumentelor care pot fi utilizate pentru testarea automatizării mainframe-ului.
- REXX
- excela
- QTP
Metodologie în testarea mainframe
Să luăm în considerare un exemplu: o companie de asigurări XYZ are un modul de înscriere a membrilor. Este nevoie de 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 loturi.
- Testarea online se face pe ecranul de înscriere a membrilor. La fel ca o pagină web, baza de date este validată cu date introduse prin ecrane.
- Înscrierea offline poate fi înscriere pe hârtie sau înscriere pe un site web al unei terțe părți. Datele offline (denumite și lot) vor fi introduse în baza de date a companiei prin lucrări de lot. Un fișier plat de intrare este pregătit conform formatului de date prescris și este introdus în secvența de lucrări batch. Deci, pentru testarea aplicațiilor mainframe putem folosi următoarea abordare.
- Primul job din linia joburilor batch validează datele introduse. Să spunem, de exemplu, caractere speciale, alfabete în câmpuri numai numerice etc.
- Al doilea job validează consistența datelor pe baza condițiilor de afaceri. De exemplu, o înscriere pentru copii nu ar trebui să conțină date dependente, cod poștal al membrilor (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 lucrărilor în lot se face în 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 validarea bazei de date. (Rezultatele intermediare trebuie să fie validate pentru prudență suplimentară)
Următoarea este metoda urmată pentru testarea Mainframe:
Pasul 1) : Testarea Shakedown / fum
Accentul principal în această etapă este de a valida dacă codul implementat se află în mediul de testare potrivit. De asemenea, se asigură că nu există probleme critice cu codul.
Pasul 2) : Testarea sistemului
Mai jos sunt tipurile de testare efectuate ca parte a testării sistemului.
- Testarea pe lot - Această testare se va face prin validarea rezultatelor testului pe fișierele de ieșire și modificările de date efectuate de joburile de loturi din domeniul de testare și înregistrarea acestora.
- Testare online - Această testare se va face pe partea frontală a aplicației mainframe. Aici aplicația este testată pentru câmpul corect de intrare, cum ar fi un plan de asigurare, dobânda pentru plan etc.
- Testarea integrării online a loturilor - Această testare se va face pe sistemele care au procese discontinue și aplicații 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 dobânzii se face pe un ecran de actualizare, iar detaliile soldului din conturile afectate vor fi modificate numai printr-o lucrare pe seară. în acest caz se va face prin validarea ecranului cu detalii despre plan și executarea lucrării în lot pentru actualizarea tuturor conturilor).
- Testarea bazei de date - Bazele de date în care datele din aplicația mainframe (IMS, IDMS, DB2, VSAM / ISAM, seturi de date secvențiale, GDG) sunt validate pentru aspectul lor și stocarea datelor.
Pasul 3) : Testarea integrării sistemului
Scopul principal al acestei testări 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, ei folosesc date din sistemul testat. Este important să testați interfața și diferitele tipuri de mesaje (cum ar fi Job Success, Job Failed, Database actualizat etc.) care pot circula între sisteme și acțiunile rezultate întreprinse de sistemele individuale.
Tipurile de testare efectuate în această etapă sunt
- Testarea lotului
- Testare online
- Online - Testare integrare lot
Pasul 4) : Testarea regresiei
Testarea prin regresie este o fază comună în orice tip de proiect de testare. Această testare în Mainframes asigură faptul că lucrările lot și ecranele online care nu interacționează direct cu sistemul testat (sau nu intră în sfera cerințelor) nu sunt afectate de versiunea curentă a proiectului.
Pentru a avea teste de regresie eficiente, un anumit set de cazuri de testare ar trebui să fie selectat în funcție de complexitatea acestora și ar trebui creat un pat de regresie (depozit de cazuri de testare). Acest set trebuie actualizat ori de câte ori există o nouă funcționalitate lansată în versiune.
Pasul 5) : Testarea performanței
Această testare se face pentru a identifica blocajele în zonele cu impact ridicat, cum ar fi datele front-end, actualizarea bazelor de date online și pentru a proiecta scalabilitatea aplicației.
Pasul 6) : Testarea securității
Această testare se face pentru a evalua cât de bine este proiectată și dezvoltată aplicația pentru a contracara atacurile anti-securitate.
Ar trebui să se facă două teste de securitate pe sistem - Securitatea mainframe și Securitatea rețelei.
Caracteristicile care trebuie testate sunt
- Integritate
- Confidențialitate
- Autorizare
- Autentificare
- Disponibilitate
Pașii implicați în testarea lotului
- După ce echipa QA primește pachetul aprobat (pachetul conține proceduri, JCL, carduri de control, module etc.), testerul ar trebui să previzualizeze și să recupereze conținutul în PDS, după cum este necesar.
- Convertiți producția JCL sau Development JCL în QA JCL numit altfel JOB SETUP.
- Copierea fișierului de producție și pregătirea fișierelor de testare.
- Pentru fiecare funcționalitate, va fi definită o secvență de lucrări. (Așa cum se explică în exemplul din secțiunea Metodologie în mainframe). Lucrările trebuie trimise utilizând comanda SUB împreună cu fișierele de date de testare.
- Verificați fișierul intermediar pentru a identifica motivele pentru datele lipsă sau erori.
- Verificați fișierul final de ieșire, baza de date și Spool-ul pentru a valida rezultatele testului.
- Dacă jobul eșuează, bobina va avea motivul eșecului jobului. Remediați eroarea și retrimiteți lucrarea.
Raportarea testului - Defectul trebuie înregistrat dacă rezultatul real deviază de la cel așteptat.
Pașii implicați în testarea online
- Selectați ecranul Online într-un mediu de testare.
- Testați fiecare câmp pentru datele acceptabile.
- Testați scenariul de testare pe ecran.
- Verificați baza de date pentru actualizările de date din ecranul online.
Raportarea testului - Defectul trebuie înregistrat dacă rezultatul real deviază de la cel așteptat.
Pași implicați în testarea online - integrarea loturilor
- Rulați lucrarea într-un mediu de testare și validați datele de pe ecranele online.
- Actualizați datele de pe ecranele online și validați dacă lucrarea batch este executată corect cu datele actualizate.
Comenzi utilizate în testarea mainframe
- TRIMITEȚI - Trimiteți o lucrare de fundal.
- ANULARE - Anulați lucrarea de fundal.
- ALOCARE - Alocați un set de date
- COPIERE - Copiați un set de date
- RENAME - Redenumiți setul de date
- ȘTERGERE - Ștergeți setul de date
- JOB SCAN -Pentru a lega JCL cu programul, bibliotecile, fișierul etc. fără a-l executa.
Există multe alte comenzi utilizate atunci când este necesar, dar nu sunt atât de frecvente.
Condiții prealabile pentru a începe testarea mainframe-ului
Detaliile de bază necesare pentru testarea mainframe sunt:
- ID-ul de autentificare și parola pentru conectarea la 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.
- Loc de munca
- Efectuați o scanare a lucrărilor (Comandă - JOBSCAN) pentru a verifica erorile înainte de a o executa.
- Parametrul CLASS trebuie indicat către clasa de testare.
- Direcționați ieșirea lucrării în spool sau un JHS sau după cum este necesar utilizând parametrul MSGCLASS.
- Redirecționați e-mailul în job către spool sau un ID de e-mail de testare.
- Comentează pașii FTP pentru testarea inițială și apoi îndreaptă lucrarea către un server de testare.
- În cazul în care este generată o înregistrare IMR (Incident Management) în lucrare, trebuie doar să adăugați comentariul „SCOPUL DE TESTARE” în job sau pe cardul param.
- Toate bibliotecile de producție din job ar trebui schimbate și arătate către biblioteci de testare.
- Locul de muncă nu trebuie lăsat nesupravegheat.
- Pentru a preveni executarea lucrării într-o buclă infinită în caz de eroare, parametrul TIME trebuie adăugat cu timpul specificat.
- Salvați rezultatul lucrării, inclusiv bobina. Bobina poate fi salvată folosind XDC.
- Fişier
- Creați numai fișier de testare cu dimensiunea necesară. Utilizați GDG-uri (Generare grupuri de date - 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.
- Parametrul DISP (Dispoziție - descrie sistemul pentru a efectua păstrarea sau ștergerea setului de date după terminarea normală sau anormală a pasului sau lucrării) parametrul fișierelor ar trebui codat corect.
- Asigurați-vă că toate fișierele utilizate pentru execuția lucrării sunt salvate și închise corect pentru a împiedica intrarea lucrării în HOLD.
- În timpul testării folosind GDG-uri, asigurați-vă că versiunea corectă este indicată.
- Bază de date
- În timpul executării jobului sau a programului online, asigurați-vă că datele neintenționate nu sunt inserate, actualizate sau șterse.
- De asemenea, asigurați-vă că regiunea DB2 corectă este utilizată pentru testare.
- Cazuri de testare
- Testați întotdeauna pentru condiții limită cum ar fi - Fișier gol, Prelucrarea primei înregistrări, Prelucrarea ultimei înregistrări etc.
- Includeți întotdeauna condiții de testare atât pozitive, cât și negative.
- În cazul în care procedurile standard sunt utilizate în program, 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.
- Date de testare
- Configurarea datelor de testare trebuie făcută înainte de începerea testării.
- Nu modificați niciodată datele din regiunea de test fără a notifica. Pot exista și alte echipe care lucrează cu aceleași date, iar testul lor ar eșua.
- În cazul în care fișierele de producție sunt necesare în timpul execuției, ar trebui obținută o autorizație adecvată înainte de a le copia sau utiliza.
Cele mai bune practici
- În cazul executării unui job în lot, MAX CC 0 este un indicator al faptului că jobul a rulat cu succes. Nu înseamnă că funcționalitatea funcționează bine. Lucrarea va rula cu succes chiar și atunci când ieșirea este goală sau nu conform așteptărilor. Deci, este întotdeauna de așteptat să verificați toate rezultatele înainte de a declara lucrarea cu succes.
- Este întotdeauna o bună practică să efectuați o sarcină uscată a sarcinii testate. Rularea uscată se face cu fișiere de intrare goale. Acest proces ar trebui urmat pentru joburile care sunt afectate de modificările efectuate pentru ciclul de testare.
- Înainte de începerea ciclului de testare, lucrarea de testare aranjată trebuie făcută cu mult timp în avans. Acest lucru vă va ajuta să aflați în prealabil orice eroare JCL, economisind astfel timp în timpul execuției.
- În timp ce accesați tabelele DB2 prin SPUFI (opțiune de pe emulator pentru a accesa tabelele DB2), setați întotdeauna auto commit ca „NU” pentru a evita actualizările accidentale.
- Disponibilitatea datelor de testare este provocarea principală în testarea pe loturi. Datele necesare trebuie create cu mult înainte de ciclul de testare și trebuie verificate pentru a fi complete.
- Unele tranzacții online și lucrări de lot pot scrie date în MQ-uri (Message Queue) pentru a transmite date către alte aplicații. Dacă datele nu sunt valide, acestea 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.
Testarea mainframe-ului Provocări și depanare
| Provocări | Abordare |
| Cerințe incomplete / neclare Este posibil să existe acces la manualul de utilizare / ghidul de instruire, dar acestea nu sunt aceleași cu cerințele documentate. | Testerii ar trebui să fie implicați în SDLC încă din faza de cerințe. Acest lucru vă va ajuta să verificați dacă cerințele sunt testabile. |
| Configurarea / identificarea datelor Pot exista situații în care datele existente ar trebui reutilizate conform cerințelor. Uneori este dificil de identificat datele necesare din datele existente. | Pentru configurarea datelor, instrumentele de casă pot fi utilizate conform nevoilor. Pentru preluarea datelor existente, interogările trebuie create în prealabil. În cazul oricărei dificultăți, o cerere poate fi adresată echipei de gestionare a datelor pentru crearea sau clonarea datelor necesare. |
| Configurare job După ce joburile sunt recuperate în PDS, jobul trebuie configurat în regiunea QA. Pentru ca locurile de muncă să nu fie trimise cu calificativul de producție sau detaliile căii. | Instrumentele de configurare a lucrărilor ar trebui utilizate pentru a depăși erorile umane produse în timpul configurării. |
| Solicitare ad-hoc Pot exista situații în care testarea de la capăt la cap trebuie să fie acceptată din cauza unei probleme în problemele aplicațiilor din amonte sau din aval. Aceste cereri cresc timpul și efortul în ciclul de execuție. | Utilizarea de scripturi de automatizare, scripturi de regresie și scripturi schelet ar putea ajuta la reducerea timpului și a efortului. |
| Lansări la timp pentru modificarea domeniului de aplicare Poate exista o situație în care impactul codului poate schimba complet aspectul sistemului. Acest lucru poate necesita o modificare pentru a testa cazurile, scripturile și datele. | Ar trebui să existe un proces de gestionare a schimbării domeniului și analiza impactului. |
Abenduri comune întâlnite
- S001 - A apărut o eroare I / O.
Motiv - Citire la sfârșitul fișierului, eroare de lungime a fișierului, încercare de scriere în fișier numai în citire.
- S002 - Înregistrare I / O nevalidă.
Motiv - Încercați să scrieți o înregistrare mai lungă decât lungimea înregistrării.
- S004 - A apărut o eroare în timpul DESCHIS.
Motiv - DCB nevalid
- 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.
- S0C1 - Excepție de funcționare
Motiv - Imposibil de deschis fișierul, lipsă card DD
- S0C4 - excepție de protecție / încălcare a stocării
- Motiv - Încercarea stocării accesului nu este disponibilă pentru program.
- SC07 - Excepție verificare program - Date
- Motiv - Modificarea aspectului înregistrării sau a aspectului fișierului.
- Sx22 - Jobul a fost anulat
- S222 - Lucrare anulată de utilizator fără un dump.
- S322 - Timpul Job sau Step a depășit limita specificată sau programul este într-o buclă sau parametru de timp insuficient.
- S522 - Expirarea sesiunii TSO.
- S806 -Nu se poate lega sau încărca.
Motiv - ID-ul jobului nu a putut găsi modulul de încărcare specificat.
- S80A - Stocare virtuală insuficientă pentru a satisface solicitările GETMAIN sau FREEMAIN.
- S913 - Încercarea de a accesa setul de date pe care utilizatorul nu este autorizat.
- 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 diferite tipuri de abenduri.
Problemă comună cu care se confruntă în timpul testării mainframe
- Job Abends - Pentru finalizarea cu succes a jobului, trebuie să verificați datele, fișierul de intrare și modulele prezente la locația specifică sau nu. Abendele pot fi confruntate din mai multe motive, cel mai frecvent fiind - date nevalide, câmp de introducere incorect, nepotrivire a datei, probleme de mediu etc.
- Fișier de ieșire gol - Deși lucrarea ar putea rula cu succes (MaxCC 0), ieșirea ar putea să nu fie așa cum era de așteptat. Deci, înainte de a trece orice caz de testare, testerul trebuie să se asigure că ieșirea este verificată încrucișat. Abia apoi continuați mai departe.
- Fișier de intrare 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 reexecutarea și relucrarea.
Rezumat:
- Testarea mainframe-ului este ca orice altă procedură de testare care începe de la colectarea cerințelor, proiectarea testelor, executarea testelor și raportarea rezultatelor.
- Pentru a testa în mod eficient aplicația, testerul 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. La fel ca navigarea pe ecran, crearea de fișiere și PDS, salvarea rezultatelor testelor etc. înainte de începerea ciclului de testare.
- Testarea aplicației mainframe este un proces care necesită timp. Ar trebui urmat un program clar de testare pentru proiectarea testului, configurarea și executarea datelor.
- Testarea pe loturi și testarea online ar trebui să fie efectuate eficient fără a lipsi nici o funcționalitate menționată în documentul de cerință și niciun caz de test nu ar trebui scutit.