Mainframe-testing – komplett opplæring

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

La oss lære før du lærer konsepter for mainframe-testing

Hva er en stormaskin?

Hovedrammen er et datasystem med høy ytelse og høy hastighet. Den brukes til større databehandlingsformål som krever stor tilgjengelighet og sikkerhet. Det brukes mest i sektorer som finans, forsikring, detaljhandel og andre kritiske områder der enorme data behandles flere ganger.

Mainframe-testing

Mainframe-testing er en prosess for å teste programvareapplikasjoner og tjenester basert på Mainframe-systemer. Hensikten med stormaskintesting er å sikre ytelsen, påliteligheten og kvaliteten til programvareapplikasjonen eller tjenesten ved hjelp av verifiserings- og valideringsmetoder og sjekke om den er klar til å distribueres.

Mens testeren utfører Mainframe-testing, trenger testeren bare å vite om navigasjonen til CICS-skjermene. De er spesialbygd for spesifikke bruksområder. Eventuelle endringer i koden i COBOL, JCL, etc. tester trenger ikke å bekymre deg for emulatoren som er satt opp på maskinen. Endringene som fungerer på en terminalemulator vil fungere på andre.

  • Mainframe-applikasjonen (ellers kalt jobbbatch) testes mot testcasene utviklet ved bruk 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 terminalemulator. Emulatoren er den eneste programvaren som må installeres på klientmaskinen.

Mainframe-attributter

  1. Virtuell lagring
    1. Det er en teknikk som lar en prosessor simulere hovedlagring som er større enn den faktiske mengden reell lagring.
    2. Det er en teknikk for å bruke minne effektivt til å lagre og utføre oppgaver i forskjellige størrelser.
    3. Den bruker disklagring som en utvidelse av ekte lagring.
  2. Multiprogrammering
    1. Datamaskinen kjører mer enn ett program samtidig. Men til enhver tid kan bare ett program ha kontroll over CPU.
    2. Det er et anlegg for å gjøre effektiv bruk av CPU.
  3. Batch Processing
    1. Det er en teknikk der enhver oppgave utføres i enheter kjent som jobber.
    2. En jobb kan føre til at ett eller flere programmer kjøres i en sekvens.
    3. 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.
    4. Nødvendig informasjon for batchbehandling gis gjennom JCL (JOBB CONTROL LANGUAGE). JCL beskriver batchjobben – programmer, data og nødvendige ressurser.
  4. Tidsdeling
    1. 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.
    2. Derfor kalles dette "interaktiv behandling". Det gjør det mulig for brukeren å samhandle direkte med datamaskinen.
    3. Tidsdelingsbehandling er kjent som "Forgrunnsbehandling" og batchjobbbehandling er kjent som "bakgrunnsbehandling."
  5. spoling
    1. SPOOLing står for Samtidig Perifer Operasjoner på nett.
    2. SPOOL-enheten brukes til å lagre utdata fra program/applikasjon. Utdata i kø sendes til utenheter som en skriver (hvis nødvendig).
    3. Det er et anlegg som utnytter fordelen med buffering for å gjøre effektiv bruk av utdataenhetene.

Klassifisering av manuell testing i stormaskin

Hovedramme Manuell testing kan deles inn i to typer:

1. Batch jobbtesting -

  • Testprosessen involverer utførelse av batchjobber for funksjonaliteten implementert i gjeldende utgivelse.
  • Testresultatet trukket ut fra utdatafilene og databasen blir verifisert og registrert.

2. Online testing -

  • Online testing refererer til testing av CICS-skjermer som ligner testing av nettsiden.
  • 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.

Hvordan gjøre Mainframe-testing

  1. Bedriftsteamet utarbeider kravdokumenter. Som bestemmer hvordan et bestemt element eller prosess skal endres i utgivelsessyklusen.
  2. Testteamet og utviklingen mottar kravdokumentet. De vil finne 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 andre 75% av utgivelsen vil være for ut-boksen-funksjonaliteter som testing av applikasjoner og prosesser.
  3. Så en Mainframe-applikasjon må testes i to deler:
    1. Testkrav – Teste applikasjonen for funksjonaliteten eller endringen nevnt i kravdokumentet.
    2. Testing av integrasjon – Testing av hele prosessen eller annen applikasjon som mottar eller sender data til den berørte applikasjonen. Regresjonstesting er hovedfokus for denne testaktiviteten.

RELATERTE ARTIKLER

Testverktøy for automatisering av stormaskin

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

  • REXX
  • Excel
  • QTP

Metodikk i stormaskintesting

La oss vurdere et eksempel: Et XYZ-forsikringsselskap har medlemsregistreringsmodul. Det tar data både fra medlemsregistreringsskjermen og offline-registrering. Som vi diskuterte tidligere, krever det to tilnærminger for Mainframe-testing, online testing og batch-testing.

  • Online testing gjøres på medlemsregistreringsskjermen. Akkurat som en nettside blir databasen validert med data som legges inn gjennom skjermene.
  • Frakoblet påmelding kan være papirpåmelding eller påmelding på en tredjeparts nettside. Offline-dataene (også referert til som batch) vil bli lagt inn i firmadatabasen gjennom batchjobber. En flat input-fil utarbeides i henhold til det foreskrevne dataformatet og mates til sekvensen av batchjobber. Så for testing av mainframe-applikasjoner kan vi bruke følgende tilnærming.
  • Den første jobben i rekken av batchjobber validerer dataene som er lagt inn. La oss si for eksempel spesialtegn, alfabeter i felt med bare tall osv.
  • Den andre jobben validerer konsistensen av data basert på forretningsforhold. For eksempel skal en barneregistrering ikke inneholde avhengige data, medlemspostnummer (som ikke er tilgjengelig for service av den registrerte planen), etc.
  • Den tredje jobben endrer dataene i formatet som kan legges inn i databasen. For eksempel sletting av plannavnet (databasen vil bare lagre plan-ID og forsikringsplannavn), legge til dato for innreise osv.
  • Den fjerde jobben laster dataene inn i databasen.
  • Batch jobb testing gjøres på denne prosessen i to faser -
  • Hver jobb valideres separat, og
  • Integrasjon mellom jobbene valideres ved å gi inndata flat fil til den første jobben og validere databasen. (Mellomresultater må valideres for ekstra forsiktighet)

Følgende er metoden som følges for Mainframe-testing:

Trinn 1) Shakedown/Røykprøving

Hovedfokuset i dette stadiet er å validere om koden som er distribuert er i riktig testmiljø. Det sikrer også at det ikke er noen kritiske problemer med koden.

Trinn 2) Systemtesting

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

  1. Batch testing – Denne testingen vil bli utført ved å validere testresultatene på utdatafiler og dataendringer utført av batchjobbene under testomfang og registrering av dem.
  2. Online testing – Denne testingen vil bli utført på forsiden av stormaskinapplikasjonen. Her testes applikasjonen for riktig inngangsfelt som en forsikringsplan, renter på planen, etc.
  3. Online-batch-integrasjonstesting – Denne testingen vil bli gjort på systemene som har batch-prosesser og nettbasert applikasjon. Dataflyten og interaksjonen mellom nettskjermene og batchjobbene er validert.

    (Eksempel på denne typen testing – Vurder en oppdatering av plandetaljer som økning av renten. Endringen av rente gjøres på en oppdateringsskjerm, og saldodetaljene på de berørte kontoene vil kun bli endret av en nattlig batchjobb. Testing i dette tilfellet vil bli utført ved å validere Plandetaljer-skjermen og batchjobben for oppdatering av alle kontoene).

  4. Databasetesting – Databasene der dataene fra stormaskinapplikasjonen (IMS, IDMS, DB2, VSAM/ISAM, Sekvensielle datasett, GDG-er) er validert 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 er ikke direkte berørt av kravene. De bruker imidlertid data fra systemet som testes. Det er viktig å teste grensesnittet og ulike typer meldinger (som Job Vellykket, Job Failed, Database oppdatert, etc. ) 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. Online – Batch-integrasjonstesting

Trinn 4) Regresjonstesting

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

For å ha effektiv regresjonstesting, bør et bestemt sett med testtilfeller bli shortlisted avhengig av deres kompleksitet, og en regresjonsseng (Testcase-repository) bør opprettes. Dette settet bør oppdateres hver gang det er en ny funksjonalitet rullet ut i utgivelsen.

Trinn 5) Ytelsestesting

Denne testingen er gjort for å identifisere flaskehalsene i områder med høye treff som grensesnittdata, oppgradering av online databaser og for å projisere skalerbarheten til applikasjonen.

Trinn 6) Sikkerhetstesting

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

To ganger sikkerhetstesting bør utføres på systemet – Mainframe-sikkerhet 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 har mottatt den godkjente pakken (pakken inneholder prosedyrer, JCL, kontrollkort, moduler osv.), bør testeren forhåndsvise og hente innholdet til PDS etter behov.
  2. Konverter produksjons-JCL eller Development JCL til QA JCL ellers kalt JOBSETUP.
  3. Kopiering av produksjonsfil og klargjøring av testfiler.
  4. For hver funksjonalitet vil det være en jobbsekvens definert. (Som forklart i eksempelet i Metodikk i Mainframe-delen). Jobbene skal sendes inn ved å bruke SUB-kommandoen med testdatafilene.
  5. Sjekk mellomfilen for å identifisere årsakene til manglende eller feildata.
  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 – Defekt skal logges dersom det faktiske resultatet avviker fra forventet.

Trinn involvert i online testing

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

Testrapportering – Defekt skal logges dersom det faktiske resultatet avviker fra forventet.

Trinn involvert i online – batchintegrasjonstesting

  1. Kjør jobben i en Test miljø og valider dataene på nettskjermene.
  2. Oppdater dataene på nettskjermene og valider om batchjobben kjøres riktig med de oppdaterte dataene.

Kommandoer brukt i Mainframe-testing

  1. SEND inn – Send inn en bakgrunnsjobb.
  2. CANCEL – Avbryt bakgrunnsjobb.
  3. ALLOCATE – Tildel et datasett
  4. COPY – Kopier et datasett
  5. RENAME – Gi nytt navn til datasett
  6. SLETT – Slett datasett
  7. JOBBSCANNING – For å binde JCL med programmet, bibliotekene, filene osv. 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 mainframe-testing

Grunnleggende detaljer som trengs for stormaskintesting er:

  • Påloggings-ID og passord for pålogging i applikasjonen.
  • Kort kunnskap om ISPF-kommandoer.
  • Navn på filene, filkvalifikator og deres typer.

Før du starter mainframe-testing, bør aspektene nedenfor verifiseres.

  1. Jobb
    1. Utfør en jobbskanning (Kommando – JOBSCAN) for å se etter feil før du utfører den.
    2. KLASSE-parameteren skal pekes til testklassen.
    3. Rett jobbutgangen inn i spole eller en JHS eller etter behov ved å bruke MSGCLASS-parameteren.
    4. Omdiriger e-posten i jobben til spool eller en testpost-ID.
    5. Kommenter FTP-trinnene for innledende testing og pek jobben til en testserver.
    6. I tilfelle en IMR (Incident Management record) genereres i jobben, legg bare til kommentaren "TESTING PURPOSE" i jobben eller paramkortet.
    7. Alle produksjonsbibliotekene i jobben bør endres og pekes på testbiblioteker.
    8. Jobben skal ikke stå uten tilsyn.
    9. For å forhindre at jobben kjører i en uendelig sløyfe i tilfelle feil, bør TIME-parameteren legges til med spesifisert tid.
    10. Lagre utskriften av jobben inkludert spolen. Spolen kan lagres ved hjelp av XDC.
  1. filet
    1. Opprett kun testfil av nødvendig størrelse. Bruk GDGs (Generasjonsdatagrupper – Filer med samme navn, men med sekvensielle versjonsnumre – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 så videre ) når det er nødvendig for å lagre data i påfølgende filer med samme navn.
    2. DISP-parameteren (Disposisjon – beskriver systemet som skal utføre beholde eller slette datasettet etter normal eller unormal avslutning av trinnet eller jobben) for filene skal kodes riktig.
    3. Sørg for at alle filene som brukes til jobbutførelse er lagret og lukket riktig for å forhindre at jobben går i HOLD.
    4. Mens du tester med GDG-er, sørg for at riktig versjon er pekt på.
  2. Database
    1. Mens du utfører jobben eller nettprogrammet, sørg for at utilsiktede data ikke settes inn eller oppdateres eller slettes.
    2. Sørg også for at riktig DB2-region brukes til testing.
  3. Testtilfeller
    1. Test alltid for grenseforhold som – tom fil, første postbehandling, siste postbehandling, etc.
    2. Inkluder alltid både positive og negative testforhold.
    3. Hvis standardprosedyrer brukes i programmet som Checkpoint restart, Abend Modules, Control files, etc. inkluderer testcases for å validere om modulene har blitt brukt riktig.
  4. Testdata
    1. Testdataoppsett bør gjøres før begynnelsen av testingen.
    2. Modifiser aldri dataene på testområdet uten å varsle. Det kan være andre team som jobber med samme data, og testen deres vil mislykkes.
    3. I tilfelle produksjonsfilene er nødvendige under utførelsen, bør riktig autorisasjon innhentes før du kopierer eller bruker dem.

Beste praksis

  1. I tilfelle en batchjobb kjøres, er MAX CC 0 en indikator på at jobben har kjørt vellykket. Det betyr ikke at funksjonaliteten fungerer bra. Jobben vil kjøre vellykket selv når utgangen er tom eller ikke som forventet. Så det forventes alltid å sjekke alle utdataene før jobben erklæres vellykket.
  2. Det er alltid en god praksis å gjøre en tørr kjøring av jobben som testes. Tørrkjøring gjøres med tomme inndatafiler. Denne prosessen bør følges for jobbene som påvirkes av endringene som er gjort for testsyklusen.
  3. Før testsyklusen begynner bør oppsettet av testjobben gjøres i god tid. Dette vil hjelpe til med å finne ut eventuelle JCL-feil på forhånd og dermed spare tid under utførelse.
  4. Når du får tilgang til DB2-tabeller via SPUFI (alternativ på emulatoren for å få tilgang til DB2-tabeller), må du alltid angi automatisk commit som "NO" for å unngå utilsiktede oppdateringer.
  5. Testdatatilgjengelighet er hovedutfordringen i batchtesting. Nødvendige data bør opprettes i god tid før testsyklusen og bør kontrolleres for fullstendighet.
  6. Enkelte nettbaserte transaksjoner og batchjobber kan skrive data inn i MQ-er (Message Queue) for overføring av data til andre applikasjoner. Hvis dataene ikke er gyldige, kan det deaktivere/stoppe MQs, dette vil påvirke hele testprosessen. Det er en god praksis å sjekke at MQ-er fungerer bra etter testing.

Mainframe-testing Utfordringer og feilsøking

Utfordringer Tilnærming
Ufullstendige / uklare krav

Det kan være tilgang til brukermanual/ opplæringsveiledning, men de er ikke de samme som dokumenterte krav. 		Testere bør være involvert i SDLC fra kravfasen og utover. Dette vil bidra til å verifisere om kravene er testbare.
Dataoppsett/identifikasjon

Det kan være situasjoner der eksisterende data bør gjenbrukes i henhold til kravet. Noen ganger er det vanskelig å identifisere de nødvendige dataene fra eksisterende data. 		For dataoppsett kan hjemmelagde verktøy brukes etter behov. For å hente eksisterende data bør spørringer bygges på forhånd. I tilfelle problemer kan en forespørsel sendes til databehandlingsteamet for å opprette eller klone nødvendige data.
Jobboppsett

Når jobbene er hentet inn i PDS, må jobben settes opp i QA-regionen. Slik at jobbene ikke sendes inn med produksjonskvalifisering eller banedetalj. 		Verktøy for jobboppsett bør brukes for å overvinne menneskelige feil som er gjort under oppsettet.
Ad hoc-forespørsel

Det kan være situasjoner der ende-til-ende-testing må støttes på grunn av et problem i oppstrøms- eller nedstrømsapplikasjonsproblemer. Disse forespørslene øker tiden og innsatsen i utførelsessyklusen. 		Bruk av automatiseringsskript, regresjonsskript og skjelettskript kan bidra til å redusere tid og innsats.
Utgivelser i tide for endring av omfang

Det kan være en situasjon der kodepåvirkningen kan endre utseendet og følelsen til systemet fullstendig. Dette kan kreve endringer i testtilfeller, skript og data. 		Omfang endringsstyringsprosess og konsekvensanalyse bør være på plass.

Vanlige Abends påtruffet

  1. S001 – Det oppstod en I/O-feil.

    Årsak – Lesing på slutten av filen, fillengdefeil, forsøk på å skrive inn i skrivebeskyttet fil.

  2. S002 – Ugyldig I/O-post.

    Årsak – Forsøk å skrive en post som er lengre enn rekordlengden.

  3. S004 – Feil oppstod under OPEN.

    Årsak – Ugyldig DCB

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

    Årsak – PDS-medlem eksisterer ikke, rekordlengden i programmet samsvarer ikke med den faktiske postlengden.

  5. S0C1 – Operasjon Unntak

    Årsak – Kan ikke åpne filen, mangler DD-kort

  6. S0C4 – Beskyttelsesunntak/ Lagringsbrudd
  7. Årsak – Prøver å få tilgang til lagring som ikke er tilgjengelig for programmet.
  8. S0C7 – Programkontrollunntak – Data
  9. Årsak – Endring i postoppsett eller filoppsett.
  10. Sx22 – Jobben er kansellert
  11. S222 – Jobb kansellert av brukeren uten dump.
  12. S322 – Jobb- eller trinntid overskred den angitte grensen, eller programmet er i en sløyfe eller utilstrekkelig tidsparameter.
  13. S522 – Tidsavbrudd for TSO-økt.
  14. S806 – Kan ikke koble eller laste.

    Årsak – Jobb-ID finner ikke den spesifiserte lastmodulen.

  15. S80A – Ikke nok virtuell lagring til å tilfredsstille GETMAIN- eller FREEMAIN-forespørsler.
  16. S913 – Prøver å få tilgang til datasettet som brukeren ikke er autorisert.
  17. Sx37 – Kan ikke tildele nok lagringsplass til datasettet.

Error Assist – Et veldig populært verktøy for å få detaljert informasjon om ulike typer abends.

Vanlig problem under testing av stormaskin

  • Job Abends – For vellykket gjennomføring av jobben bør du sjekke dataene, inndatafilen og modulene som er tilstede på det spesifikke stedet eller ikke. Abends kan bli møtt på grunn av flere årsaker, den vanligste er - Ugyldige data, Feil inndatafelt, datofeil, miljøproblemer, etc.
  • Utdatafilen er tom– Selv om jobben kan kjøre vellykket (MaxCC 0), kan det hende at utgangen ikke blir som forventet. Så før han består en testsak, må testeren sørge for at utgangen er kryssverifisert. Bare deretter gå videre.
  • Inndatafilen er tom – I noen applikasjoner vil filer bli mottatt fra oppstrømsprosessene. Før du bruker den mottatte filen for å teste gjeldende applikasjon, bør dataene kryssverifiseres for å unngå omkjøring og omarbeiding.

Sammendrag

  • Mainframe-testing er som enhver annen testprosedyre som starter fra kravinnsamling, testdesign, testutførelse og resultatrapportering.
  • For å teste applikasjonen effektivt, bør testeren delta i designmøter planlagt av utviklings- og forretningsteam.
  • Det er obligatorisk for testeren å bli vant til ulike stormaskintestfunksjoner. Som skjermnavigering, opprettelse av filer og PDS, lagring av testresultater osv. før testsyklusen starter.
  • Mainframe-applikasjonstesting er en tidkrevende prosess. En klar testplan bør følges for testdesign, dataoppsett og utførelse.
  • Batch-testing og online-testing bør utføres effektivt uten å gå glipp av noen funksjonalitet nevnt på kravdokumentet, og ingen Testsak bør spares.