Mainframe-testing – komplett opplæring

Før vi lærer oss konsepter for stormaskintesting, la oss først se på plattformen testene kjøres på.

Hva er en stormaskin?

Stormaskinen er et datasystem med høy ytelse og høy hastighet. Det brukes til storskala databehandling som krever høy tilgjengelighet og sterk sikkerhet. Det brukes hovedsakelig i sektorer som finans, forsikring, detaljhandel og andre kritiske områder der store datamengder behandles mange ganger om dagen.

Mainframe-testing

Mainframe-testing er en prosess for testing av programvare og tjenester basert på stormaskiner. Formålet med stormaskinertesting er å sikre ytelsen, påliteligheten og kvaliteten til en programvare eller tjeneste gjennom verifiserings- og valideringsmetoder, og å sjekke om den er klar til utrulling.

Når testeren utfører stormaskintesting, trenger testeren hovedsakelig å kjenne til navigeringen i CICS-skjermbildene. Disse skjermbildene er spesialbygd for spesifikke applikasjoner. Når endringer gjøres i koden i COBOL, JCL og lignende språk, trenger ikke testeren å bekymre seg for emulatoren som er satt opp på maskinen, fordi endringer som fungerer på én terminalemulator, vil fungere på de andre.

• Stormaskinapplikasjonen (også kalt jobbbatch) testes mot testtilfellene som er utviklet ved hjelp av krav.
• Mainframe-testing utføres vanligvis på den distribuerte koden ved å bruke ulike datakombinasjoner satt inn i inngangsfilen.
• Applikasjoner som kjører på stormaskinen kan nås via en terminalemulator. Emulatoren er den eneste programvaren som må installeres på klientmaskinen.

Fordi plattformen oppfører seg annerledes enn en webstack, er det nyttig å vite hvilke stormaskinegenskaper som driver testdesignet. Stormaskintesting står derfor side om side med de andre typer programvaretesting heller enn å erstatte noen av dem.

Mainframe-attributter

1. Virtuell lagring
   • Det er en teknikk som lar en prosessor simulere hovedlagring som er større enn den faktiske mengden reell lagring.
   • Det er en teknikk for å bruke minne effektivt til å lagre og utføre oppgaver i forskjellige størrelser.
   • Den bruker disklagring som en utvidelse av ekte lagring.
2. Multiprogrammering
   • Datamaskinen kjører mer enn ett program samtidig. Men til enhver tid kan bare ett program ha kontroll over CPU-en.
   • Det er et anlegg for å gjøre effektiv bruk av CPU.
3. Batch Processing
   • Det er en teknikk der enhver oppgave utføres i enheter kjent som jobber.
   • En jobb kan føre til at ett eller flere programmer kjøres i en sekvens.
   • Jobbplanleggeren tar en beslutning om rekkefølgen jobbene skal utføres i. For å maksimere den gjennomsnittlige gjennomstrømningen, planlegges jobber i henhold til deres prioritet og klasse.
   • Den nødvendige informasjonen for batchbehandling gis gjennom JCL (JOB CONTROL LANGUAGE). JCL beskriver batchjobben – programmer, data og ressurser som trengs.
4. Tidsdeling
   • I et tidsdelingssystem har hver bruker tilgang til systemet gjennom terminalenheten. I stedet for å sende inn jobber som er planlagt for senere utførelse, legger brukeren inn kommandoer som behandles umiddelbart.
   • Derfor kalles dette "interaktiv behandling". Det gjør det mulig for brukeren å samhandle direkte med datamaskinen.
   • Tidsdelingsbehandling er kjent som "Forgrunnsbehandling" og batchjobbbehandling er kjent som "bakgrunnsbehandling."
5. spoling
   • SPOOLING står for Samtidig periferi Operasjoner på nett.
   • En SPOOL-enhet brukes til å lagre utdataene fra et program eller en applikasjon. Den spolede utdataene sendes til utdataenheter som en skriver (om nødvendig).
   • Det er et anlegg som utnytter fordelen med buffering for å gjøre effektiv bruk av utdataenhetene.

Klassifisering av manuell testing i stormaskin

Disse attributtene deler manuelt testarbeid på stormaskinen i to tydelig atskilte strømmer.

Hovedramme Manuell testing kan deles inn i to typer:

1. Testing av batchjobber —

• Testprosessen innebærer utføring av batchjobber for funksjonaliteten som er implementert i gjeldende versjon.
• Testresultatene f.eks.trachentet fra utdatafilene og databasen verifiseres og registreres.

2. Testing på nett —

• Nettbasert testing refererer til testing av CICS-skjermer, som ligner på testing av en nettside.
• Funksjonaliteten til de eksisterende skjermene kan endres, eller nye skjermer kan legges til.
• Ulike applikasjoner kan ha forespørselsskjermer og oppdateringsskjermer. Funksjonaliteten til disse skjermene må kontrolleres som en del av netttestingen.

Slik utfører du stormaskintesting

1. Forretningsteamet utarbeider kravdokumenter som bestemmer hvordan et bestemt element eller en bestemt prosess skal endres i utgivelsessyklusen.
2. Testteamet og utviklingsteamet mottar kravdokumentet. De finner ut hvor mange prosesser som vil bli påvirket av endringen. Vanligvis, i en utgivelse, påvirkes bare 20–25 % av applikasjonen direkte av det tilpassede kravet. De resterende 75–80 % av utgivelsesarbeidet går til den ferdige funksjonaliteten, som å teste omkringliggende applikasjoner og prosesser.
3. Så en Mainframe-applikasjon må testes i to deler:
   • Testkrav — Testing av applikasjonen for funksjonaliteten eller endringen som er nevnt i kravdokumentet.
   • Testing av integrasjon — Testing av hele prosessen eller andre applikasjoner som mottar eller sender data til den berørte applikasjonen. Regresjonstesting er hovedfokus for denne testaktiviteten.

Testverktøy for automatisering av stormaskin

Nedenfor er listen over verktøy som kan brukes for stormaskin Automatiseringstesting.

• REXX — skriptspråket som følger med z/OS, mye brukt til å drive repeterende jobbinnsending og utdatakontroller.
• Excel — brukes med makroer for å bygge, sammenligne og rapportere testdata og utdatafiler.
• OpenText UFT En — det nåværende navnet på verktøyet som industrien fortsatt kaller QTP eller QuickTest Professional; den automatiserer 3270 terminalskjermbilder.
• Galasa — en åpen kildekode, Rammeverk for testing av dyp integrasjon i Open Mainframe Project som driver 3270 skjermer, JCL-batchjobber og Db2 fra en CI/CD-pipeline.
• Leverandør z/OS testpakker - IBM Testakselerator for Z og BMC AMI DevX Total Test dekker COBOL-enhetstesting og virtualiserte testmiljøer.

Uansett hvilket verktøy som velges, lønner det seg bare når det står inne i et vedlikeholdt rammeverk for testautomatisering snarere enn en løs bunke med manus.

Metodikk i stormaskintesting

La oss se på et eksempel: Et forsikringsselskap i XYZ har en modul for medlemsregistrering. Den henter data både fra medlemsregistreringsskjermen og fra registrering uten nett. Som diskutert tidligere, tar den to tilnærminger for stormaskintesting: online testing og batchtesting.

• Nettbasert testing gjøres på medlemsregistreringsskjermen. Akkurat som en nettside valideres databasen med data som legges inn via skjermbildene.
• Offline-registrering kan være papirregistrering eller registrering på et tredjepartsnettsted. Offline-dataene (også referert til som batch) vil bli lagt inn i bedriftsdatabasen via batchjobber. En flat input-fil utarbeides i henhold til det foreskrevne dataformatet og mates inn i sekvensen av batchjobber. Så for testing av stormaskinapplikasjoner kan vi bruke følgende tilnærming.
  • Den første jobben i raden med batchjobber validerer dataene som er angitt – for eksempel spesialtegn eller alfabeter i felt med bare tall.
  • Den andre jobben validerer datakonsistensen basert på forretningsforhold. For eksempel bør ikke en underordnet registrering inneholde data om pårørende eller et medlems postnummer som ikke er tilgjengelig for tjenesten av den registrerte planen.
  • Den tredje jobben endrer dataene til et format som kan legges inn i databasen. For eksempel slette plannavnet (databasen lagrer bare plan-ID og forsikringsplannavn), legge til registreringsdato og lignende endringer.
  • Den fjerde jobben laster dataene inn i databasen.
• Batchjobbtesting utføres på denne prosessen i to faser –
  • Hver jobb valideres separat, og
  • Integrasjonen mellom jobbene valideres ved å legge inn den flate inputfilen i den første jobben og validere databasen. (Mellomresultater må valideres av ekstra forsiktighetshensyn.)

Følgende er metoden som følges for stormaskintesting:

Trinn 1) Shakedown/røyktesting

Hovedfokuset i denne fasen er å validere om koden som er distribuert er i riktig testmiljø. Det sikrer også at det ikke er noen kritiske problemer med koden. Dette er stormaskinens ekvivalent til Røykprøving på noen annen plattform.

Trinn 2) Systemtesting

Nedenfor er typene tester som er utført som en del av systemtesting.

1. Batch testing — Denne testingen gjøres ved å validere testresultatene på utdatafiler og dataendringene som er gjort av batchjobbene under testomfanget, og registrere dem.
2. Online testing — Denne testingen gjøres på frontenden av stormaskinapplikasjonen. Her testes applikasjonen for korrekte inntastingsfelt som en forsikringsplan, renter på planen og lignende verdier.
3. Online-batch-integrasjonstesting — Denne testingen utføres på systemer som har både batchprosesser og en nettbasert applikasjon. Dataflyten og samspillet mellom nettskjermbildene og batchjobbene valideres.

   (Eksempel på denne typen testing – Vurder en oppdatering av plandetaljer, for eksempel en økning i renten. Endringen i renten gjøres på en oppdateringsskjerm, og saldodetaljene på de berørte kontoene endres bare av en nattlig batchjobb. Testing i dette tilfellet gjøres ved å validere plandetaljskjermen og batchjobben kjøres for å oppdatere alle kontoene.)

4. Databasetesting – Databasene der dataene fra stormaskinapplikasjonen lagres (IMS, IDMS, Db2, VSAM/ISAM, sekvensielle datasett, GDG-er) valideres for layout og datalagring.

Trinn 3) System Integrasjonstesting

Hovedformålet med denne testingen er å validere funksjonaliteten til systemene som samhandler med systemet som testes.

Disse systemene påvirkes ikke direkte av kravene. De bruker imidlertid data fra systemet som testes. Det er viktig å teste grensesnitt og de ulike meldingstypene (som Jobb vellykket, Jobb mislyktes, Database oppdatert) som kan flyte mellom systemene, og de resulterende handlingene som utføres av de enkelte systemene.

Typer testing gjort i dette stadiet er

1. Batch testing
2. Online testing
3. På nett — Batchintegrasjonstesting

Trinn 4) Regresjonstesting

Regresjonstesting er en vanlig fase i alle typer testprosjekter. Denne testingen i stormaskiner sikrer at batchjobber og online-skjermbilder som ikke samhandler direkte med systemet som testes (eller ikke omfattes av kravene), ikke påvirkes av den nåværende prosjektutgivelsen.

For å få effektiv regresjonstesting bør et bestemt sett med testtilfeller utvelges avhengig av kompleksiteten deres, og et regresjonssett (testtilfellelager) bør opprettes. Dette settet bør oppdateres hver gang ny funksjonalitet rulles ut i utgivelsen. Der regresjonssettet er for stort til å kjøre fullt ut, Risikobasert testing brukes til å bestemme hvilke jobber og skjermbilder som kjøres på nytt først.

Trinn 5) Ytelsestesting

Denne testingen gjøres for å identifisere flaskehalser i områder med høye belastninger, som dataregistrering i frontend og oppdateringer av nettbaserte databaser, og for å anslå applikasjonens skalerbarhet. Langvarige batchvinduer undersøkes vanligvis med Stresstesting mot toppvolumer.

Trinn 6) Sikkerhetstesting

Denne testen er gjort for å evaluere hvor godt applikasjonen er designet og utviklet for å motvirke anti-sikkerhetsangrep.

Todelt sikkerhetstesting bør utføres på systemet – stormaskinsikkerhet og nettverkssikkerhet.

Funksjonene som må testes er

1. Integrity
2. Konfidensialitet
3. autorisasjon
4. Autentisering
5. Tilgjengelighet

Trinn involvert i batchtesting

1. Etter at QA-teamet mottar den godkjente pakken (pakken inneholder prosedyrer, JCL, kontrollkort, moduler og lignende elementer), bør testeren forhåndsvise og hente innholdet i PDS etter behov.
2. Konverter produksjons-JCL-en eller utviklings-JCL-en til QA-JCL, også kalt JOBBOPPSETT.
3. Kopier produksjonsfilen og klargjør testfilene.
4. For hver funksjonalitet vil det være definert en jobbsekvens (som forklart i eksemplet i delen Metodikk i stormaskintesting). Jobbene skal sendes inn ved hjelp av SUB-kommandoen sammen med testdatafilene.
5. Sjekk den mellomliggende filen for å identifisere årsakene til manglende eller feilaktige data.
6. Sjekk den endelige utdatafilen, databasen og spolen for å validere testresultatene.
7. Hvis jobben mislykkes, vil spolen ha årsaken til jobbfeilen. Rett opp feilen og send inn jobben på nytt.

Testrapportering - A defekt bør loggføres dersom det faktiske resultatet avviker fra det forventede resultatet.

Trinn involvert i online testing

1. Velg Online-skjermen i en Test miljø.
2. Test hvert felt for akseptable data.
3. Test Testscenario på skjermen.
4. Bekreft databasen for dataoppdateringer fra nettskjermen.

Testrapportering — En feil skal loggføres dersom det faktiske resultatet avviker fra det forventede resultatet.

Trinn involvert i online – batchintegrasjonstesting

1. Kjør jobben i et testmiljø og valider dataene på de elektroniske skjermbildene.
2. Oppdater dataene på online-skjermbildene og valider om batchjobben kjører riktig med de oppdaterte dataene.

Kommandoer brukt i stormaskintesting

Disse trinnene styres fra terminalen, så et lite kommandovokabular dekker mesteparten av en testers dag.

1. SEND — Send inn en bakgrunnsjobb.
2. AVBRYT — Avbryt en bakgrunnsjobb.
3. TILDELE — Tildel et datasett.
4. KOPI — Kopier et datasett.
5. RENAME — Gi nytt navn til et datasett.
6. SLETT — Slett et datasett.
7. JOBBSKANNING — Bind JCL-en med programmet, bibliotekene, filene og andre ressurser uten å kjøre den.

Det er mange andre kommandoer som brukes når det er nødvendig, men de er ikke så hyppige.

Forutsetninger for å starte stormaskintesting

Grunnleggende detaljer som trengs for stormaskintesting er:

• Påloggings-ID og passord for pålogging i applikasjonen.
• Kort kjennskap til ISPF-kommandoer.
• Navn på filene, filkvalifikatoren og deres typer.

Før du starter stormaskintesting, bør aspektene nedenfor verifiseres.

1. Jobb
   • Utfør en jobbskanning (kommando — JOBSCAN) for å se etter feil før du kjører den.
   • CLASS-parameteren skal peke mot testklassen.
   • Diriger jobbutdataene til spolen eller en JHS, eller etter behov, ved å bruke MSGCLASS-parameteren.
   • Omdiriger e-posten i jobben til utskriftskø eller til en test-e-post-ID.
   • Kommenter ut FTP-trinnene for innledende testing, og pek deretter jobben til en testserver.
   • Hvis en IMR (hendelseshåndteringsrapport) genereres i jobben, legg til kommentaren «TESTFORMÅL» i jobb- eller parameterkortet.
   • Alle produksjonsbibliotekene i jobben bør endres og pekes på testbiblioteker.
   • Jobben skal ikke stå uten tilsyn.
   • For å forhindre at jobben kjører i en uendelig løkke i tilfelle feil, bør TIME-parameteren legges til med en spesifisert tid.
   • Lagre utskriften av jobben inkludert spolen. Spolen kan lagres ved hjelp av XDC.
2. filet
   • Opprett en testfil med kun nødvendig størrelse. Bruk GDG-er (Generation Data Groups – filer med samme navn, men med sekvensielle versjonsnumre, for eksempel MYLIB.LIB.TEST.G0001V00 og MYLIB.LIB.TEST.G0002V00) når det er nødvendig for å lagre data i sammenhengende filer med samme navn.
   • DISP-parameteren (Disposition – forteller systemet om datasettet skal beholdes eller slettes etter normal eller unormal avslutning av trinnet eller jobben) for filene bør være riktig kodet.
   • Sørg for at alle filene som brukes til jobbutførelse lagres og lukkes på riktig måte for å forhindre at jobben settes i HOLD.
   • Når du tester med GDG-er, må du sørge for at du peker på riktig versjon.
3. Database
   • Når du utfører jobben eller det nettbaserte programmet, må du sørge for at utilsiktede data ikke settes inn, oppdateres eller slettes.
   • Sørg også for at riktig Db2-region brukes til testing.
4. Testtilfeller
   • Test alltid for grensebetingelser som en tom fil, første postbehandling og siste postbehandling.
   • Inkluder alltid både positive og negative testforhold.
   • Dersom standardprosedyrer brukes i programmet, for eksempel omstart av kontrollpunkt, abend-moduler eller kontrollfiler, inkluder Testsakfor å bekrefte om modulene har blitt brukt riktig.
5. Testdata
   • Testdataoppsett bør gjøres før begynnelsen av testingen.
   • Aldri endre dataene i testområdet uten å varsle andre. Det kan være andre team som jobber med de samme dataene, og testene deres vil mislykkes.
   • I tilfelle produksjonsfilene er nødvendige under utførelsen, bør riktig autorisasjon innhentes før du kopierer eller bruker dem.

Beste praksis

1. Ved kjøring av en batchjobb er MAX CC 0 en indikator på at jobben har kjørt. Det betyr ikke at funksjonaliteten fungerer som den skal. Jobben vil kjøre selv om utdataene er tomme eller ikke som forventet. Det forventes derfor alltid å sjekke alle utdataene før jobben erklæres som vellykket.
2. Det er alltid lurt å prøvekjøre jobben som testes. En prøvekjøring gjøres med tomme inputfiler. Denne prosessen bør følges for jobbene som påvirkes av endringene som er gjort for testsyklusen.
3. Før testsyklusen starter, bør testjobben settes opp i god tid. Dette bidrar til å finne eventuelle JCL-feil på forhånd, og dermed spare tid under utførelsen.
4. Når du åpner Db2-tabeller via SPUFI (et alternativ i emulatoren for å få tilgang til Db2-tabeller), må du alltid sette automatisk commit til «NO» for å unngå utilsiktede oppdateringer.
5. Tilgjengeligheten av testdata er den primære utfordringen ved batchtesting. Nødvendige data bør opprettes i god tid før testsyklusen og bør kontrolleres for fullstendighet. Tracking den forberedelsen i en delt testledelse depotet holder regresjonssenget og dataoppsettet på linje.
6. Noen nettbaserte transaksjoner og batchjobber kan skrive data til MQ-er (meldingskøer) for transmitoverføre data til andre applikasjoner. Hvis dataene ikke er gyldige, kan det deaktivere eller stoppe MQ-ene, og dette vil påvirke hele testprosessen. Det er god praksis å sjekke at MQ-ene fungerer som de skal etter testing.

Utfordringer og feilsøking med stormaskintesting

Selv med disse fremgangsmåtene på plass, dukker det opp noen problemer igjen i nesten alle stormaskinutgivelser. Tabellen nedenfor viser hvert problem med løsningen.

Utfordringer	Tilnærming
Ufullstendige / uklare krav	Det kan være tilgang til en brukermanual eller opplæringsguide, men dette er ikke det samme som dokumenterte krav. Testere bør være involvert i livssyklus for programvaretesting fra kravfasen og utover. Dette bidrar til å bekrefte om kravene er testbare.
Dataoppsett / Identifikasjon	Det kan være situasjoner der eksisterende data bør gjenbrukes i henhold til behovet. Det er noen ganger vanskelig å identifisere de nødvendige dataene fra de eksisterende dataene. For dataoppsett kan hjemmelagde verktøy brukes etter behov. For å hente eksisterende data bør spørringer lages på forhånd. Ved problemer kan en forespørsel sendes til databehandlingsteamet om å opprette eller klone de nødvendige dataene.
Jobboppsett	Når jobbene er hentet inn i PDS, må jobben settes opp i QA-regionen, slik at jobbene ikke sendes inn med en produksjonskvalifikator eller stidetaljer. Verktøy for jobboppsett bør brukes for å overvinne menneskelige feil som gjøres under oppsettet.
Ad hoc-forespørsel	Det kan være situasjoner der ende-til-ende-testing trenger støtte på grunn av et problem i oppstrøms- eller nedstrømsapplikasjoner. Disse forespørslene øker tiden og innsatsen i utførelsessyklusen. Bruk av automatiseringsskript, regresjonsskript og skjelettskript kan bidra til å redusere tids- og innsatskostnadene.
Utgivelser i tide for endring av omfang	Det kan oppstå en situasjon der kodepåvirkningen fullstendig endrer systemets utseende og preg. Dette kan kreve en endring i testtilfeller, skript og data. En prosess for håndtering av omfangsendring og konsekvensanalyse bør være på plass.

Vanlige abends som oppstår

Når en jobb mislykkes, rapporterer spolen en abend-kode. Listen nedenfor dekker kodene en stormaskintester møter oftest, sammen med den vanlige årsaken.

1. S001 — Det oppsto en I/O-feil.

   Årsak — Leser på slutten av filen, feil med fillengden eller et forsøk på å skrive inn i en skrivebeskyttet fil.

2. S002 — Ugyldig I/O-oppføring.

   Årsak — Forsøk på å skrive en post som er lengre enn postens lengde.

3. S004 — Det oppsto en feil under ÅPNING.

   Årsak — Ugyldig DCB.

4. S013 – Feil ved åpning av et datasett.

   Årsak — PDS-medlemmet finnes ikke, eller postlengden i programmet samsvarer ikke med den faktiske postlengden.

5. S0C1 - Operasjon Unntak.

   Årsak — Kan ikke åpne filen, eller DD-kort mangler.

6. S0C4 — Beskyttelsesunntak / brudd på lagring.

   Årsak — Forsøker å få tilgang til lagringsplass som ikke er tilgjengelig for programmet.

7. S0C7 — Programkontrollunntak, data.

   Årsak — Endring i postoppsett eller filoppsett.

8. Sx22 – Jobben er kansellert.

   Årsak – Jobben ble avsluttet før fullføring; det midterste sifferet identifiserer hvem eller hva som avbrøt den.

9. S222 — Jobben ble avbrutt av brukeren uten en dump.
10. S322 — Jobb- eller trinntiden overskred den angitte grensen, eller programmet er i en løkke, eller TIME-parameteren er utilstrekkelig.
11. S522 — Tidsavbrudd for TSO-økt.
12. S806 – Kan ikke koble eller laste.

    Årsak – Jobben finner ikke den angitte lastemodulen.

13. S80A – Ikke nok virtuell lagringsplass til å tilfredsstille GETMAIN- eller FREEMAIN-forespørsler.
14. S913 — Forsøker å få tilgang til et datasett som brukeren ikke har autorisasjon til å bruke.
15. Sx37 – Kan ikke tildele nok lagringsplass til datasettet.

Feilhjelp — Et veldig populært verktøy for å få detaljert informasjon om ulike typer uhell.

Vanlige problemer man møter under testing av stormaskiner

• Job Abends — For å fullføre jobben, bør du sjekke dataene, inndatafilen og om modulene er tilstede på den spesifikke plasseringen. Avvik kan oppstå av flere årsaker, den vanligste er ugyldige data, feil inndatafelt, datoavvik eller miljøproblemer.
• Utdatafilen er tom — Selv om jobben kan kjøre uten problemer (MaxCC 0), er det ikke sikkert at resultatet er som forventet. Så før testeren består en test, må vedkommende sørge for at resultatet er kryssverifisert. Først da bør testingen fortsette.
• Inndatafilen er tom — I noen applikasjoner mottas filer fra oppstrømsprosesser. Før den mottatte filen brukes til å teste den gjeldende applikasjonen, bør dataene kryssverifiseres for å unngå ny kjøring og omarbeiding.

Spørsmål og svar