Mainframe-test – Komplet selvstudium

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

Lad os lære, før du lærer mainframe-testkoncepter

Hvad er en mainframe?

Mainframen er et computersystem med høj ydeevne og høj hastighed. Det bruges til større computerformål, der kræver stor tilgængelighed og sikkerhed. Det bruges mest i sektorer som finans, forsikring, detailhandel og andre kritiske områder, hvor enorme data behandles flere gange.

Mainframe test

Mainframe test er en proces med test af softwareapplikationer og tjenester baseret på mainframe-systemer. Formålet med mainframe-testning er at sikre ydeevne, pålidelighed og kvalitet af softwareapplikation eller service ved hjælp af verifikations- og valideringsmetoder og kontrollere, om den er klar til at blive implementeret.

Mens testeren udfører Mainframe-test, behøver testeren kun at vide om navigationerne på CICS-skærmene. De er specialbygget til specifikke applikationer. Eventuelle ændringer i koden i COBOL, JCL, etc. tester behøver ikke at bekymre sig om emulatoren opsat på maskinen. De ændringer, der virker på en terminalemulator, vil virke på andre.

  • Mainframe-applikationen (ellers kaldet jobbatch) testes i forhold til testcases udviklet ved brug af krav
  • Mainframe-testning udføres normalt på den implementerede kode ved hjælp af forskellige datakombinationer, der er sat i inputfilen.
  • Programmer, der kører på mainframen, kan tilgås via terminalemulator. Emulatoren er den eneste software, der skal installeres på klientmaskinen.

Mainframe-attributter

  1. Virtuel opbevaring
    1. Det er en teknik, der lader en processor simulere hovedlager, der er større end den faktiske mængde af reelt lager.
    2. Det er en teknik til at bruge hukommelsen effektivt til at gemme og udføre opgaver i forskellige størrelser.
    3. Det bruger disklager som en udvidelse af ægte lager.
  2. Multiprogrammering
    1. Computeren udfører mere end et program på samme tid. Men på ethvert givet tidspunkt kan kun ét program have kontrol over CPU.
    2. Det er en facilitet til rådighed for at gøre effektiv brug af CPU'en.
  3. Batchbehandling
    1. Det er en teknik, hvorved enhver opgave udføres i enheder kendt som job.
    2. Et job kan få et eller flere programmer til at køre i en sekvens.
    3. Jobplanlæggeren træffer en beslutning om, i hvilken rækkefølge opgaverne skal udføres. For at maksimere den gennemsnitlige gennemstrømning planlægges jobs efter deres prioritet og klasse.
    4. De nødvendige oplysninger til batchbehandling leveres gennem JCL (JOB CONTROL LANGUAGE). JCL beskriver batchjobbet – programmer, data og nødvendige ressourcer.
  4. Tidsdeling
    1. I et tidsdelingssystem har hver bruger adgang til systemet gennem terminalenheden. I stedet for at indsende job, der er planlagt til senere udførelse, indtaster brugeren kommandoer, der behandles med det samme.
    2. Derfor kaldes dette "interaktiv behandling". Det gør det muligt for brugeren at interagere direkte med computeren.
    3. Timeshare-behandling er kendt som "Forgrundsbehandling", og batch-jobbehandlingen er kendt som "Baggrundsbehandling."
  5. spooling
    1. SPOOLing står for Samtidig Perifer Operationer online.
    2. SPOOL-enhed bruges til at gemme output fra program/applikation. Det spoolede output dirigeres til outputenheder som en printer (hvis nødvendigt).
    3. Det er en facilitet, der udnytter fordelen ved buffering for at gøre effektiv brug af outputenhederne.

Klassificering af manuel test i mainframe

Mainframe Manuel testning kan opdeles i to typer:

1. Batch-jobtest -

  • Testprocessen involverer udførelse af batchjobs for den funktionalitet, der er implementeret i den aktuelle udgivelse.
  • Testresultatet udtrukket fra outputfilerne og databasen verificeres og registreres.

2. Online test -

  • Online test refererer til test af CICS skærme, som svarer til test af websiden.
  • Funktionaliteten af ​​de eksisterende skærme kunne ændres, eller nye skærme kunne tilføjes.
  • Forskellige applikationer kan have forespørgselsskærme og opdateringsskærme. Funktionaliteten af ​​disse skærme skal kontrolleres som en del af onlinetestningen.

Sådan laver du Mainframe-testning

  1. Forretningsteamet udarbejder kravdokumenter. Hvilket bestemmer, hvordan en bestemt vare eller proces vil blive ændret i frigivelsescyklussen.
  2. Testteamet og udviklingen modtager kravdokumentet. De vil finde ud af, hvor mange processer der vil blive påvirket af ændringen. Normalt, i en udgivelse, er kun 20-25 % af applikationen direkte påvirket af det tilpassede krav. De øvrige 75% af udgivelsen vil være til out-box-funktionaliteter som at teste applikationer og processer.
  3. Så en Mainframe-applikation skal testes i to dele:
    1. Testkrav – Test af applikationen for funktionaliteten eller ændringen nævnt i kravdokumentet.
    2. Test af integration – Test af hele processen eller anden applikation, der modtager eller sender data til den berørte applikation. Regressionstest er det primære fokus for denne testaktivitet.

RELATEREDE ARTIKLER

Mainframe automationstestværktøjer

Nedenfor er listen over værktøjer, der kan bruges til mainframe Test af automatisering.

  • REXX
  • Excel
  • QTP

Metode i mainframe test

Lad os overveje et eksempel: Et XYZ-forsikringsselskab har medlemstilmeldingsmodul. Det tager data både fra medlemstilmeldingsskærmen og offline tilmelding. Som vi diskuterede tidligere, kræver det to tilgange til Mainframe-test, online-test og batch-test.

  • Online test sker på medlemstilmeldingsskærmen. Ligesom en webside valideres databasen med data indtastet via skærmbillederne.
  • Offline tilmelding kan være papirtilmelding eller tilmelding på en tredjeparts hjemmeside. Offline-dataene (også kaldet batch) vil blive indtastet i virksomhedens database via batchjobs. En flad inputfil forberedes i henhold til det foreskrevne dataformat og føres til sekvensen af ​​batchjob. Så til mainframe-applikationstestning kan vi bruge følgende tilgang.
  • Det første job i rækken af ​​batchjobs validerer de indtastede data. Lad os f.eks. sige specialtegn, alfabeter i felter med kun tal osv.
  • Det andet job validerer konsistensen af ​​data baseret på forretningsbetingelser. For eksempel bør en børnetilmelding ikke indeholde afhængige data, medlemspostnummer (som ikke er tilgængeligt for service af den tilmeldte plan) osv.
  • Det tredje job ændrer dataene i det format, der kan indtastes i databasen. For eksempel sletning af planens navn (databasen gemmer kun plan-id og forsikringsplannavn), tilføjelse af dato for indrejse osv.
  • Det fjerde job indlæser dataene i databasen.
  • Batch job test udføres på denne proces i to faser -
  • Hvert job valideres separat, og den
  • Integration mellem jobs valideres ved at give input flad fil til det første job og validere databasen. (Mellemresultater skal valideres for ekstra forsigtighed)

Følgende er metoden, der følges til Mainframe-test:

Trin 1) Shakedown/Røgtest

Hovedfokus i denne fase er at validere, om den implementerede kode er i det rigtige testmiljø. Det sikrer også, at der ikke er kritiske problemer med koden.

Trin 2) Systemtest

Nedenfor er de typer af test, der udføres som en del af systemtest.

  1. Batch test – Denne test vil blive udført ved at validere testresultaterne på outputfiler og dataændringer udført af batchjobs under testomfang og registrering af dem.
  2. Online test – Denne test vil blive udført på forsiden af ​​mainframe-applikationen. Her testes ansøgningen for korrekt indtastningsfelt som en forsikringsplan, renter på planen osv.
  3. Online-batch-integrationstest – Denne test vil blive udført på systemerne med batch-processer og online-applikation. Dataflowet og interaktionen mellem onlineskærmene og batch-jobbene valideres.

    (Eksempel på denne type test – Overvej en opdatering af plandetaljer som f.eks. rentestigning. Ændringen af ​​rente sker på en opdateringsskærm, og saldodetaljerne på de berørte konti vil kun blive ændret ved et batchjob hver nat. Test i dette tilfælde vil blive udført ved at validere skærmbilledet Plandetaljer og batchjobbet for at opdatere alle konti).

  4. Database test – De databaser, hvor dataene fra mainframe-applikationen (IMS, IDMS, DB2, VSAM/ISAM, sekventielle datasæt, GDG'er) er valideret for deres layout og datalagring.

Trin 3) Systemkrav Integrationstest

Det primære formål med denne test er at validere funktionaliteten af ​​de systemer, der interagerer med det system, der testes.

Disse systemer er ikke direkte påvirket af kravene. De bruger dog data fra det system, der testes. Det er vigtigt at teste grænsefladen og forskellige typer meddelelser (såsom Job vellykket, Job Mislykket, Database opdateret osv.), der kan flyde mellem systemerne og de deraf følgende handlinger foretaget af de enkelte systemer.

Typer af test udført i denne fase er

  1. Batch test
  2. Online test
  3. Online – Batch-integrationstest

Trin 4) Regressionstest

Regressionstest er en almindelig fase i enhver form for testprojekt. Denne test i Mainframes sikrer, at batchjobs og onlineskærme, som ikke interagerer direkte med systemet under test (eller ikke er omfattet af kravene), ikke påvirkes af den aktuelle projektudgivelse.

For at have effektiv regressionstestning bør et bestemt sæt af testcases optages på listen afhængigt af deres kompleksitet, og der bør oprettes et regressionsbed (Testcase-lager). Dette sæt bør opdateres, hver gang der er en ny funktionalitet udrullet i udgivelsen.

Trin 5) Test af ydeevne

Denne test udføres for at identificere flaskehalsene i områder med høje hits som frontend-data, opgradering af onlinedatabaser og for at projektere applikationens skalerbarhed.

Trin 6) Sikkerhedstest

Denne test udføres for at evaluere, hvor godt applikationen er designet og udviklet til at imødegå anti-sikkerhedsangreb.

Der bør udføres dobbelt sikkerhedstest på systemet - Mainframe-sikkerhed og netværkssikkerhed.

De funktioner, der skal testes, er

  1. Integrity
  2. Fortrolighed
  3. Tilladelse
  4. Godkendelse
  5. Tilgængelighed

Trin involveret i batchtest

  1. Efter at QA-teamet har modtaget den godkendte pakke (pakken indeholder procedurer, JCL, kontrolkort, moduler osv.), bør testeren forhåndsvise og hente indholdet i PDS efter behov.
  2. Konverter produktions-JCL eller Development JCL til QA JCL ellers kaldet JOB SETUP.
  3. Kopiering af produktionsfil og udarbejdelse af testfiler.
  4. For hver funktionalitet vil der være defineret en jobsekvens. (Som forklaret i eksemplet i afsnittet Metodologi i Mainframe). Jobbene skal indsendes ved hjælp af SUB-kommandoen med testdatafilerne.
  5. Tjek den mellemliggende fil for at identificere årsagerne til manglende eller fejludgående data.
  6. Kontroller den endelige outputfil, databasen og spoolen for at validere testresultaterne.
  7. Hvis jobbet mislykkes, vil spolen have årsagen til jobfejlen. Ret fejlen og send jobbet igen.

Testrapportering – Defekt skal logges, hvis det faktiske resultat afviger fra forventet.

Trin involveret i online test

  1. Vælg skærmbilledet Online i et testmiljø.
  2. Test hvert felt for de acceptable data.
  3. Test Testscenarie på skærmen.
  4. Bekræft databasen for dataopdateringer fra onlineskærmen.

Testrapportering – Defekt skal logges, hvis det faktiske resultat afviger fra forventet.

Trin involveret i online - batchintegrationstest

  1. Kør jobbet i en Testmiljø og valider dataene på onlineskærmene.
  2. Opdater dataene på onlineskærmene og valider, om batchjobbet køres korrekt med de opdaterede data.

Kommandoer brugt i mainframe-test

  1. SUBMIT – Indsend et baggrundsjob.
  2. CANCEL – Annuller baggrundsjob.
  3. ALLOCATE – Tildel et datasæt
  4. COPY – Kopier et datasæt
  5. RENAME – Omdøb datasæt
  6. SLET – Slet datasæt
  7. JOB SCAN – At binde JCL med programmet, bibliotekerne, filen osv. uden at udføre det.

Der er mange andre kommandoer, der bruges efter behov, men de er ikke så hyppige.

Forudsætninger for at starte mainframe-testning

Grundlæggende detaljer, der er nødvendige for mainframe-testning, er:

  • Login-id og adgangskode til at logge ind på applikationen.
  • Kort viden om ISPF-kommandoer.
  • Navne på filerne, filkvalifikation og deres typer.

Før du starter mainframe-testning, skal nedenstående aspekter verificeres.

  1. Job
    1. Lav en jobscanning (Kommando – JOBSCAN) for at kontrollere for fejl, før den udføres.
    2. KLASSE-parameteren skal peges på testklassen.
    3. Ret joboutputtet ind i spool eller en JHS eller efter behov ved at bruge MSGCLASS-parameteren.
    4. Omdiriger e-mailen i jobbet til spool eller et test-mail-id.
    5. Kommenter FTP-trinnene for indledende test, og peg derefter jobbet til en testserver.
    6. Hvis der genereres en IMR (Incident Management record) i jobbet, skal du blot tilføje kommentaren "TESTING PURPOSE" i jobbet eller paramkortet.
    7. Alle produktionsbiblioteker i jobbet skal ændres og peges på testbiblioteker.
    8. Jobbet bør ikke efterlades uden opsyn.
    9. For at forhindre jobbet i at køre i en uendelig løkke i tilfælde af fejl, skal TIME parameter tilføjes med specificeret tid.
    10. Gem outputtet fra jobbet inklusive spolen. Spolen kan gemmes ved hjælp af XDC.
  1. File (Felt)
    1. Opret kun testfil af nødvendig størrelse. Brug GDG'er (Generationsdatagrupper – Filer med samme navn, men med sekventielle versionsnumre – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 så videre ), når det er nødvendigt for at gemme data i fortløbende filer med samme navn.
    2. DISP-parameteren (Disposition – beskriver systemet til at udføre bevaring eller sletning af datasættet efter normal eller unormal afslutning af trinnet eller jobbet) for filerne skal kodes korrekt.
    3. Sørg for, at alle filer, der bruges til jobudførelse, er gemt og lukket korrekt for at forhindre, at jobbet går i HOLD.
    4. Mens du tester med GDG'er, skal du sørge for, at der peges på den rigtige version.
  2. Database
    1. Mens du udfører jobbet eller onlineprogrammet, skal du sikre dig, at utilsigtede data ikke indsættes eller opdateres eller slettes.
    2. Sørg også for, at den korrekte DB2-region bruges til test.
  3. Test tilfælde
    1. Test altid for grænsebetingelser som – Tom fil, Første registreringsbehandling, Sidste registreringsbehandling osv.
    2. Inkluder altid både positive og negative testbetingelser.
    3. I tilfælde af, at der bruges standardprocedurer i programmet, såsom genstart af kontrolpunkt, Abend-moduler, kontrolfiler osv., inkluderer testcases for at validere, om modulerne er blevet brugt korrekt.
  4. Testdata
    1. Opsætning af testdata skal udføres før starten af ​​testen.
    2. Ændre aldrig dataene på testområdet uden at give besked. Der kan være andre hold, der arbejder med samme data, og deres test ville mislykkes.
    3. Hvis produktionsfilerne er nødvendige under udførelsen, skal der indhentes korrekt autorisation, før de kopieres eller bruges.

Bedste Praksis

  1. I tilfælde af en batchjob-kørsel, er MAX CC 0 en indikator for, at jobbet er kørt med succes. Det betyder ikke, at funktionaliteten fungerer fint. Jobbet vil køre med succes, selv når outputtet er tomt eller ikke som forventet. Så det forventes altid at kontrollere alle output, før jobbet erklæres for vellykket.
  2. Det er altid en god praksis at udføre en tør omgang med det undersøgte job. Tørkørsel udføres med tomme inputfiler. Denne proces bør følges for de job, der påvirkes af ændringerne i testcyklussen.
  3. Inden testcyklussen begynder, skal opsætningen af ​​testjobbet udføres i god tid. Dette vil hjælpe med at finde ud af enhver JCL-fejl på forhånd og dermed spare tid under udførelsen.
  4. Mens du får adgang til DB2-tabeller via SPUFI (mulighed på emulatoren for at få adgang til DB2-tabeller), skal du altid indstille auto commit som "NEJ" for at undgå utilsigtede opdateringer.
  5. Testdatatilgængelighed er den primære udfordring i batchtest. Nødvendige data bør oprettes i god tid før testcyklussen og bør kontrolleres for fuldstændighed.
  6. Nogle onlinetransaktioner og batchjobs kan skrive data ind i MQ'er (Message Queue) for at overføre data til andre applikationer. Hvis dataene ikke er gyldige, kan de deaktivere/stoppe MQ'er, dette vil påvirke hele testprocessen. Det er en god praksis at kontrollere, at MQ'er fungerer fint efter test.

Mainframe test Udfordringer og fejlfinding

Udfordringer Tilgang
Ufuldstændige/uklare krav

Der kan være adgang til brugermanual/træningsvejledning, men det er ikke det samme som dokumenterede krav. 		Testere bør involveres i SDLC fra kravfasen og fremefter. Dette vil hjælpe med at verificere, om kravene er testbare.
Dataopsætning/identifikation

Der kan være situationer, hvor eksisterende data skal genbruges i henhold til kravet. Det er nogle gange vanskeligt at identificere de nødvendige data fra de eksisterende data. 		Til dataopsætning kan hjemmelavede værktøjer bruges efter behov. For at hente eksisterende data skal forespørgsler bygges på forhånd. I tilfælde af problemer, kan en anmodning sendes til datastyringsteamet for at oprette eller klone nødvendige data.
Jobopsætning

Når jobbet er hentet ind i PDS, skal jobbet konfigureres i QA-regionen. Sådan at jobs ikke indsendes med produktionskvalifikation eller stidetaljer. 		Jobopsætningsværktøjer bør bruges for at overvinde menneskelige fejl begået under opsætningen.
Ad hoc anmodning

Der kan være situationer, hvor ende til ende-test skal understøttes på grund af et problem i upstream- eller downstream-applikationsproblemer. Disse anmodninger øger tiden og indsatsen i udførelsescyklussen. 		Brug af automatiseringsscripts, regressionsscripts og skeletscripts kan hjælpe med at reducere tid og kræfter.
Frigivelser til tiden for ændring af omfang

Der kan være en situation, hvor kodepåvirkningen fuldstændig kan ændre systemets udseende og følelse. Dette kan kræve en ændring af testcases, scripts og data. 		Omfangsændringsstyringsproces og effektanalyse bør være på plads.

Almindelige Abends stødt på

  1. S001 – Der opstod en I/O-fejl.

    Årsag – Læsning i slutningen af ​​filen, fillængdefejl, forsøg på at skrive til skrivebeskyttet fil.

  2. S002 – Ugyldig I/O-record.

    Årsag – Forsøg at skrive en post, der er længere end rekordlængden.

  3. S004 – Der opstod en fejl under OPEN.

    Årsag – Ugyldig DCB

  4. S013 – Fejl ved åbning af et datasæt.

    Årsag – PDS-medlem eksisterer ikke, rekordlængde i programmet stemmer ikke overens med den faktiske rekordlængde.

  5. S0C1 – Operation Undtagelse

    Årsag – Filen kunne ikke åbnes, DD-kort mangler

  6. S0C4 – Beskyttelsesundtagelse/ Opbevaringsbrud
  7. Årsag – Forsøger at få adgang til lager er ikke tilgængeligt for programmet.
  8. S0C7 – Programkontrolundtagelse – Data
  9. Årsag – Ændring i postlayout eller fillayout.
  10. Sx22 – Job er blevet annulleret
  11. S222 – Job annulleret af brugeren uden dump.
  12. S322 – Job- eller Trintid overskred den specificerede grænse, eller programmet er i en sløjfe eller utilstrækkelig tidsparameter.
  13. S522 – TSO session timeout.
  14. S806 – Kan ikke linkes eller indlæses.

    Årsag – Job-id kan ikke finde det angivne belastningsmodul.

  15. S80A – Ikke nok virtuel lagerplads til at opfylde GETMAIN- eller FREEMAIN-anmodninger.
  16. S913 – Forsøger at få adgang til datasættet, som brugeren ikke er autoriseret.
  17. Sx37 – Kan ikke tildele nok lagerplads til datasættet.

Error Assist – Et meget populært værktøj til at få detaljerede oplysninger om forskellige typer af abends.

Almindelig problem under test af mainframe

  • Job Abends – For en vellykket gennemførelse af jobbet bør du kontrollere data, inputfil og moduler, der er til stede på det specifikke sted eller ej. Afbrydelser kan opstå på grund af flere årsager, den mest almindelige er - Ugyldige data, Forkert inputfelt, datomismatch, miljøproblemer osv.
  • Outputfilen er tom– Selvom jobbet muligvis kører med succes (MaxCC 0), er output muligvis ikke som forventet. Så før de bestå en testcase, skal testeren sikre sig, at outputtet er krydsverificeret. Først derefter gå videre.
  • Inputfilen er tom – I nogle applikationer vil der blive modtaget filer fra upstream-processerne. Før du bruger den modtagne fil til at teste den aktuelle applikation, skal dataene krydsverificeres for at undgå genudførelse og omarbejdning.

Resumé

  • Mainframe-test er som enhver anden testprocedure, der starter fra kravindsamling, testdesign, testudførelse og resultatrapportering.
  • For at teste applikationen effektivt bør testeren deltage i designmøder planlagt af udviklings- og forretningsteams.
  • Det er obligatorisk for testeren at vænne sig til forskellige mainframe-testfunktioner. Som skærmnavigation, oprettelse af filer og PDS, lagring af testresultater osv. før testcyklussen begynder.
  • Test af mainframe-applikationer er en tidskrævende proces. En klar testplan bør følges for testdesign, dataopsætning og udførelse.
  • Batchtest og onlinetest bør udføres effektivt uden at gå glip af nogen funktionalitet nævnt på kravdokumentet, og nej Test sag skal skånes.

Du kan lide: