Mainframe-test – Komplet selvstudium

Før vi lærer koncepterne bag mainframe-testning, lad os først se på den platform, testene kører på.

Hvad er en mainframe?

Mainframen er et højtydende og hurtigt computersystem. Det bruges til storskala databehandling, der kræver høj tilgængelighed og stærk sikkerhed. Det bruges mest i sektorer som finans, forsikring, detailhandel og andre kritiske områder, hvor enorme mængder data behandles mange gange om dagen.

Mainframe test

Mainframe test er en proces til test af softwareapplikationer og -tjenester baseret på mainframe-systemer. Formålet med mainframe-testning er at sikre ydeevnen, pålideligheden og kvaliteten af ​​en softwareapplikation eller tjeneste gennem verifikations- og valideringsmetoder og at kontrollere, om den er klar til implementering.

Under mainframe-testning skal testeren primært kende navigationen på CICS-skærmene. Disse skærme er specialbygget til specifikke applikationer. Når der foretages ændringer i koden i COBOL, JCL og lignende sprog, behøver testeren ikke bekymre sig om den emulator, der er konfigureret på maskinen, fordi ændringer, der virker på én terminalemulator, også virker på de andre.

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

Fordi platformen opfører sig anderledes end en webstak, er det nyttigt at vide, hvilke mainframe-karakteristika der driver testdesignet. Mainframe-testning fungerer derfor sideløbende med de andre. typer af softwaretestning i stedet for at erstatte nogen af ​​dem.

Mainframe-attributter

1. Virtuel opbevaring
   • Det er en teknik, der lader en processor simulere hovedlager, der er større end den faktiske mængde af reelt lager.
   • Det er en teknik til at bruge hukommelsen effektivt til at gemme og udføre opgaver i forskellige størrelser.
   • Det bruger disklager som en udvidelse af ægte lager.
2. Multiprogrammering
   • Computeren udfører mere end ét program på samme tid. Men på et givet tidspunkt kan kun ét program have kontrol over CPU'en.
   • Det er en facilitet til rådighed for at gøre effektiv brug af CPU'en.
3. Batchbehandling
   • Det er en teknik, hvorved enhver opgave udføres i enheder kendt som job.
   • Et job kan få et eller flere programmer til at køre i en sekvens.
   • 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.
   • De nødvendige oplysninger til batchbehandling leveres via JCL (JOB CONTROL LANGUAGE). JCL beskriver batchjobbet — nødvendige programmer, data og ressourcer.
4. Tidsdeling
   • 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.
   • Derfor kaldes dette "interaktiv behandling". Det gør det muligt for brugeren at interagere direkte med computeren.
   • Timeshare-behandling er kendt som "Forgrundsbehandling", og batch-jobbehandlingen er kendt som "Baggrundsbehandling."
5. spooling
   • SPOOLING står for Simultaneous Peripheral Operationer online.
   • En SPOOL-enhed bruges til at gemme outputtet fra et program eller en applikation. Det spoolede output sendes til outputenheder som f.eks. en printer (hvis nødvendigt).
   • Det er en facilitet, der udnytter fordelen ved buffering for at gøre effektiv brug af outputenhederne.

Klassificering af manuel test i mainframe

Disse attributter opdeler manuelt testarbejde på mainframen i to klart adskilte strømme.

Mainframe Manuel testning kan opdeles i to typer:

1. Test af batchjob —

• Testprocessen involverer udførelse af batchjob for den funktionalitet, der er implementeret i den aktuelle version.
• Testresultaterne f.eks.tracfra outputfilerne og databasen verificeres og registreres.

2. Onlinetestning —

• Online testning refererer til testning af CICS-skærme, hvilket svarer til testning af en webside.
• 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 udfører du mainframe-testning

1. Forretningsteamet udarbejder kravdokumenter, som bestemmer, hvordan et bestemt element eller en bestemt proces skal ændres i udgivelsescyklussen.
2. Testteamet og udviklingsteamet modtager kravdokumentet. De finder ud af, hvor mange processer der vil blive påvirket af ændringen. Normalt er det i en release, at kun 20-25% af applikationen er direkte påvirket af det tilpassede krav. De resterende 75-80% af udgivelsens indsats går til den færdige funktionalitet, såsom test af de omkringliggende applikationer og processer.
3. Så en Mainframe-applikation skal testes i to dele:
   • Testkrav — Test af applikationen for den funktionalitet eller ændring, der er nævnt i kravdokumentet.
   • Test af integration — Test af hele processen eller andre applikationer, der modtager eller sender data til den berørte applikation. Regressionstest er det primære fokus for denne testaktivitet.

Mainframe automationstestværktøjer

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

• REXX — scriptsproget, der følger med z/OS, og som i vid udstrækning bruges til at styre gentagne jobafsendelser og outputkontroller.
• Excel — bruges sammen med makroer til at opbygge, sammenligne og rapportere testdata og outputfiler.
• OpenText UFT Én — det nuværende navn på det værktøj, som branchen stadig kalder det QTP eller QuickTest Professional; den automatiserer 3270 terminalskærme.
• Galasa — en open source-løsning, Open Mainframe Project dyb integrationstestramme der driver 3270 skærme, JCL-batchjob og Db2 fra en CI/CD-pipeline.
• Leverandør z/OS testpakker — IBM Test Accelerator til Z og BMC AMI DevX Total Test dækker COBOL-enhedstestning og virtualiserede testmiljøer.

Uanset hvilket værktøj der vælges, betaler det sig kun, når det står i et vedligeholdt område testautomatiseringsramme snarere end en løs bunke af manuskripter.

Metode i mainframe test

Lad os se på et eksempel: Et XYZ forsikringsselskab har et medlemstilmeldingsmodul. Det tager data både fra medlemstilmeldingsskærmen og fra offlinetilmelding. Som tidligere nævnt, tager det to tilgange til mainframe-testning: online testning og batchtestning.

• Online testning udføres 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) indtastes i virksomhedens database via batchjob. En flad inputfil udarbejdes i henhold til det foreskrevne dataformat og føres til batchjobsekvensen. Så til test af mainframe-applikationer kan vi bruge følgende tilgang.
  • Det første job i rækken af ​​batchjob validerer de indtastede data – for eksempel specialtegn eller alfabeter i felter med kun tal.
  • Det andet job validerer dataenes konsistens baseret på forretningsforhold. For eksempel bør en underordnet tilmelding ikke indeholde data om pårørende eller et medlems postnummer, der ikke er tilgængeligt for tjenesten af ​​den tilmeldte plan.
  • Det tredje job ændrer dataene til det format, der kan indtastes i databasen. For eksempel sletter plannavnet (databasen gemmer kun plan-ID'et og forsikringsplannavnet), tilføjer indtastningsdatoen og lignende ændringer.
  • Det fjerde job indlæser dataene i databasen.
• Batchjobtestning udføres på denne proces i to faser —
  • Hvert job valideres separat, og
  • Integrationen mellem jobbene valideres ved at levere den fladt inputfil til det første job og validere databasen. (Mellemresultater skal valideres af ekstra forsigtighed.)

Følgende er den anvendte metode til mainframe-testning:

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. Dette er mainframe-ækvivalenten til Røgtest på enhver anden platform.

Trin 2) Systemtest

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

1. Batch test — Denne testning udføres ved at validere testresultaterne på outputfiler og de dataændringer, der er foretaget af batchjobbene under testomfanget, og registrere dem.
2. Online test — Denne testning udføres på front-end af mainframe-applikationen. Her testes applikationen for korrekte indtastningsfelter som en forsikringsplan, renter på planen og lignende værdier.
3. Online-batch-integrationstest — Denne testning udføres på systemer, der både har batchprocesser og en onlineapplikation. Dataflowet og interaktionen mellem onlineskærmene og batchjobbene valideres.

   (Eksempel på denne type testning — Overvej en opdatering af plandetaljer, f.eks. en stigning i renten. Ændringen af ​​renten foretages på en opdateringsskærm, og saldooplysningerne på de berørte konti ændres kun af et natligt batchjob. Testning udføres i dette tilfælde ved at validere plandetaljerskærmen og batchjobbet køres for at opdatere alle konti.)

4. Database test — De databaser, hvor dataene fra mainframe-applikationen opbevares (IMS, IDMS, Db2, VSAM/ISAM, sekventielle datasæt, GDG'er), valideres med hensyn til deres layout og datalagring.

Trin 3) System 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ænseflade og de forskellige typer meddelelser (som f.eks. Job vellykket, Job mislykkedes, Database opdateret), der kan flyde mellem systemerne, og de deraf følgende handlinger, der udføres af de enkelte systemer.

Typer af test udført i denne fase er

1. Batch test
2. Online test
3. Online — Batchintegrationstestning

Trin 4) Regressionstest

Regressionstest er en almindelig fase i enhver type testprojekt. Denne testning i mainframes sikrer, at batchjob og online skærmbilleder, der ikke interagerer direkte med det system, der testes (eller ikke er omfattet af kravene), ikke påvirkes af den aktuelle projektudgivelse.

For at opnå effektiv regressionstestning bør et bestemt sæt testcases udvælges afhængigt af deres kompleksitet, og der bør oprettes et regressionssæt (testcase-repository). Dette sæt bør opdateres, når ny funktionalitet rulles ud i udgivelsen. Hvis regressionssættet er for stort til at køre fuldt ud, Risikobaseret test bruges til at bestemme, hvilke job og skærmbilleder der køres igen først.

Trin 5) Test af ydeevne

Denne testning udføres for at identificere flaskehalse i områder med høje belastninger, såsom dataindtastning i frontend og online databaseopdateringer, og for at forudsige applikationens skalerbarhed. Langvarige batchvinduer undersøges normalt med Stresstest mod spidsbelastninger.

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 to sikkerhedstests 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 batchtestning

1. Når QA-teamet modtager den godkendte pakke (pakken indeholder procedurer, JCL, kontrolkort, moduler og lignende), skal testeren forhåndsvise og hente indholdet i PDS efter behov.
2. Konverter produktions-JCL'en eller udviklings-JCL'en til QA-JCL, også kaldet JOB-OPSÆTNING.
3. Kopier produktionsfilen og forbered testfilerne.
4. For hver funktionalitet vil der være defineret en jobsekvens (som forklaret i eksemplet i afsnittet Metodologi i mainframe-testning). Jobbene skal indsendes ved hjælp af SUB-kommandoen sammen med testdatafilerne.
5. Kontrollér den mellemliggende fil for at identificere årsagerne til manglende eller fejlagtige data.
6. Kontrollér 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.

Test rapportering - a defekt skal registreres, hvis det faktiske resultat afviger fra det forventede resultat.

Trin involveret i online testning

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

Test rapportering — En fejl skal registreres, hvis det faktiske resultat afviger fra det forventede resultat.

Trin involveret i online — batchintegrationstestning

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

Kommandoer brugt i mainframe-testning

Disse trin styres fra terminalen, så et lille kommandovokabular dækker det meste af en testers dag.

1. INDSEND — Indsend et baggrundsjob.
2. CANCEL — Annuller et baggrundsjob.
3. ALLOKÉR — Alloker et datasæt.
4. COPY — Kopiér et datasæt.
5. OMDØB — Omdøb et datasæt.
6. SLET — Slet et datasæt.
7. JOB SCANNING — Bind JCL'en med programmet, biblioteker, filer og andre ressourcer uden at udføre den.

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 kendskab til ISPF-kommandoer.
• Navne på filerne, filkvalifikatoren og deres typer.

Før mainframe-testning påbegyndes, bør nedenstående aspekter verificeres.

1. Job
   • Udfør en jobscanning (kommando — JOBSCAN) for at kontrollere for fejl, før den udføres.
   • CLASS-parameteren skal pege på testklassen.
   • Diriger jobbets output til en spool eller en JHS, eller efter behov, ved hjælp af MSGCLASS-parameteren.
   • Omdiriger e-mailen i jobbet til spool eller til et test-mail-id.
   • Kommentér FTP-trinnene til den indledende test, og peg derefter jobbet til en testserver.
   • Hvis der genereres en IMR (Incident Management Record) i jobbet, skal du tilføje kommentaren "TESTFORMÅL" i jobbet eller parameterkortet.
   • Alle produktionsbiblioteker i jobbet skal ændres og peges på testbiblioteker.
   • Jobbet bør ikke efterlades uden opsyn.
   • For at forhindre jobbet i at køre i et uendeligt loop i tilfælde af en fejl, skal TIME-parameteren tilføjes med et bestemt tidspunkt.
   • Gem outputtet fra jobbet inklusive spolen. Spolen kan gemmes ved hjælp af XDC.
2. File (Felt)
   • Opret kun en testfil af den nødvendige størrelse. Brug GDG'er (Generation Data Groups - filer med samme navn, men med sekventielle versionsnumre, f.eks. MYLIB.LIB.TEST.G0001V00 og MYLIB.LIB.TEST.G0002V00) når det er nødvendigt for at gemme data i fortløbende filer med samme navn.
   • DISP-parameteren (Disposition — fortæller systemet, om datasættet skal beholdes eller slettes efter normal eller unormal afslutning af trinnet eller jobbet) for filerne skal kodes korrekt.
   • Sørg for, at alle filer, der bruges til jobudførelse, gemmes og lukkes korrekt for at forhindre, at jobbet går i HOLD.
   • Når du tester med GDG'er, skal du sørge for at pege på den rigtige version.
3. Database
   • Sørg for, at utilsigtede data ikke indsættes, opdateres eller slettes, mens du udfører jobbet eller onlineprogrammet.
   • Sørg også for, at den korrekte Db2-region bruges til testning.
4. Test tilfælde
   • Test altid for randbetingelser såsom en tom fil, første postbehandling og sidste postbehandling.
   • Inkluder altid både positive og negative testbetingelser.
   • Hvis standardprocedurer anvendes i programmet, såsom genstart af checkpoint, abend-moduler eller kontrolfiler, skal de inkluderes Test sagfor at kontrollere, om modulerne er blevet brugt korrekt.
5. Testdata
   • Opsætning af testdata skal udføres før starten af ​​testen.
   • Rediger aldrig dataene i testområdet uden at underrette andre. Der kan være andre teams, der arbejder med de samme data, og deres tests ville mislykkes.
   • 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 et batchjob er MAX CC 0 en indikator for, at jobbet er kørt korrekt. Det betyder ikke, at funktionaliteten fungerer fint. Jobbet vil køre korrekt, selv når outputtet er tomt eller ikke som forventet. Så det forventes altid at kontrollere alle output, før jobbet erklæres som vellykket.
2. Det er altid god praksis at lave en prøvekørsel af det job, der testes. En prøvekørsel udføres med tomme inputfiler. Denne proces bør følges for de job, der påvirkes af de ændringer, der er foretaget i testcyklussen.
3. Før testcyklussen begynder, bør testjobbet sættes op i god tid. Dette hjælper med at finde eventuelle JCL-fejl på forhånd og dermed spare tid under udførelsen.
4. Når du tilgår Db2-tabeller via SPUFI (en mulighed på emulatoren for at tilgå Db2-tabeller), skal du altid indstille auto commit til "NEJ" for at undgå utilsigtede opdateringer.
5. Tilgængelighed af testdata er den primære udfordring i batchtestning. Nødvendige data bør oprettes i god tid før testcyklussen og kontrolleres for fuldstændighed. Tracking den forberedelse i en fælles testadministration Repository holder regressionslejet og dataopsætningen justeret.
6. Nogle onlinetransaktioner og batchjob kan skrive data til MQ'er (meddelelseskøer) for transmitoverføre data til andre applikationer. Hvis dataene ikke er gyldige, kan det deaktivere eller stoppe MQ'erne, og dette vil påvirke hele testprocessen. Det er god praksis at kontrollere, at MQ'erne fungerer fint efter test.

Udfordringer og fejlfinding ved mainframe-testning

Selv med disse fremgangsmåder på plads, opstår der et par problemer igen i næsten alle mainframe-udgivelser. Tabellen nedenfor viser hvert problem sammen med den tilgang, der løser det.

Udfordringer	Tilgang
Ufuldstændige/uklare krav	Der kan være adgang til en brugermanual eller træningsvejledning, men det er ikke det samme som dokumenterede krav. Testere bør være involveret i livscyklus for softwaretest fra kravfasen og fremefter. Dette hjælper med at verificere, om kravene er testbare.
Dataopsætning / Identifikation	Der kan være situationer, hvor eksisterende data skal genbruges efter behov. Det kan nogle gange være vanskeligt at identificere de nødvendige data ud fra de eksisterende data. Til dataopsætning kan der anvendes hjemmelavede værktøjer efter behov. For at hente eksisterende data bør der udarbejdes forespørgsler på forhånd. I tilfælde af problemer kan der rettes en anmodning til datastyringsteamet om oprettelse eller kloning af de nødvendige data.
Jobopsætning	Når jobbene er hentet i PDS, skal jobbet konfigureres i QA-regionen, så jobbene ikke indsendes med en produktionskvalifikator eller stidetalje. Jobopsætningsværktøjer bør bruges til at overvinde menneskelige fejl, der opstår 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-applikationer. Disse anmodninger øger tiden og indsatsen i udførelsescyklussen. Brug af automatiseringsscripts, regressionsscripts og skeletonscripts kan hjælpe med at reducere tids- og indsatsomkostningerne.
Frigivelser til tiden for ændring af omfang	Der kan opstå en situation, hvor kodepåvirkningen fuldstændigt ændrer systemets udseende og funktionalitet. Dette kan kræve en ændring af testcases, scripts og data. Der bør være en proces til styring af omfangsændringer og en konsekvensanalyse på plads.

Almindelige abends, der opstår

Når et job mislykkes, rapporterer spoolen en abend-kode. Listen nedenfor dækker de koder, en mainframe-tester oftest støder på, sammen med den sædvanlige årsag.

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

   Årsag — Læsning i slutningen af ​​filen, fejl i fillængden eller et forsøg på at skrive ind i en skrivebeskyttet fil.

2. S002 — Ugyldig I/O-post.

   Årsag — Forsøg på at skrive en post, der er længere end postens længde.

3. S004 — Der opstod en fejl under ÅBNING.

   Årsag — Ugyldig DCB.

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

   Årsag — PDS-medlemmet findes ikke, eller postlængden i programmet stemmer ikke overens med den faktiske postlængde.

5. S0C1 — Operation Undtagelse.

   Årsag — Filen kan ikke åbnes, eller DD-kort mangler.

6. S0C4 — Beskyttelsesundtagelse / lagringsovertrædelse.

   Årsag — Forsøg på at få adgang til lagerplads, der ikke er tilgængelig for programmet.

7. S0C7 — Programkontrolundtagelse, data.

   Årsag — Ændring i postlayout eller fillayout.

8. Sx22 — Jobbet er blevet annulleret.

   Årsag — Jobbet blev afsluttet før færdiggørelse; det midterste ciffer angiver, hvem eller hvad der annullerede det.

9. S222 — Jobbet blev annulleret af brugeren uden en dump.
10. S322 — Job- eller trintiden har overskredet den angivne grænse, eller programmet er i en løkke, eller TIME-parameteren er utilstrækkelig.
11. S522 — Timeout for TSO-session.
12. S806 — Kunne ikke linke eller indlæse.

    Årsag — Jobbet kan ikke finde det angivne indlæsningsmodul.

13. S80A — Ikke nok virtuel lagerplads til at opfylde GETMAIN- eller FREEMAIN-anmodninger.
14. S913 — Forsøger at få adgang til et datasæt, som brugeren ikke har tilladelse til at bruge.
15. Sx37 — Der kan ikke allokeres tilstrækkelig lagerplads til datasættet.

Fejlhjælp — Et meget populært værktøj til at få detaljerede oplysninger om forskellige typer af uheld.

Almindelige problemer under mainframe-testning

• Job Abends — For at udføre jobbet korrekt, bør du kontrollere dataene, inputfilen og om modulerne er til stede på den specifikke placering. Fejl kan opstå af flere årsager, hvoraf de mest almindelige er ugyldige data, et forkert inputfelt, en datoafvigelse eller miljøproblemer.
• Outputfilen er tom — Selvom jobbet muligvis kører korrekt (MaxCC 0), er outputtet muligvis ikke som forventet. Så før testeren består en testcase, skal vedkommende sørge for, at outputtet er krydsverificeret. Først derefter bør testningen fortsætte.
• Inputfilen er tom — I nogle applikationer modtages filer fra upstream-processer. Før den modtagne fil bruges til at teste den aktuelle applikation, bør dataene krydsverificeres for at undgå genudførelse og omarbejdning.

Ofte Stillede Spørgsmål