Mainframe Testing - Fullstendig opplæring

Innholdsfortegnelse:

Anonim

Før vi lærer konsept for mainframe-testing, kan vi lære

Hva er en Mainframe?

Mainframe er en høy ytelse og et høyhastighets datasystem. Den brukes til større databehandlingsformål som krever stor tilgjengelighet og sikkerhet. Det brukes mest i sektorer som økonomi, forsikring, detaljhandel og andre kritiske områder der enorme data blir behandlet flere ganger.

Mainframe Testing

Mainframe Testing er en prosess for testing av programvareapplikasjoner og tjenester basert på Mainframe Systems. Hensikten med mainframe-testing er å sikre ytelse, pålitelighet og kvalitet på programvareapplikasjon eller -tjeneste ved verifikasjons- og valideringsmetoder og sjekke om den er klar til distribusjon.

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

  • Mainframe-applikasjonen (ellers kalt jobbatch) testes mot testtilfellene som er utviklet ved hjelp av krav
  • Mainframe Testing utføres vanligvis på den distribuerte koden ved hjelp av forskjellige datakombinasjoner satt i inndatafilen.
  • Programmer som kjører på hovedrammen kan nås via terminalemulator. Emulatoren er den eneste programvaren som trenger å installeres på klientmaskinen.

I denne nybegynnerveiledningen vil du lære-

  • Mainframe-attributter
  • Klassifisering av manuell testing i hovedramme
  • Hvordan gjøre Mainframe Testing
  • Mainframe Automation Testing Tools
  • Metodikk i Mainframe Testing
  • Trinn involvert i batch testing
  • Fremgangsmåten involvert i online testing
  • Fremgangsmåten involvert i Online - Batch Integration testing
  • Kommandoer som brukes i Mainframe Testing
  • Forutsetninger for å starte mainframe testing
  • Beste praksis
  • Mainframe testing Utfordringer og feilsøking
  • Common Abends oppstått
  • Vanlig problem som står overfor under mainframe-testing

Mainframe-attributter

  1. Virtuell lagring
    1. Det er en teknikk som lar en prosessor simulere hovedlagring som er større enn den faktiske mengden ekte lagring.
    2. Det er en teknikk for å bruke minne effektivt til å lagre og utføre forskjellige oppgaver.
    3. Den bruker disklagring som en utvidelse av ekte lagring.
  2. Multiprogrammering
    1. Datamaskinen utfører mer enn ett program samtidig. Men til enhver tid kan bare ett program ha kontroll over CPU.
    2. Det er et anlegg som tilbys for å gjøre effektiv bruk av CPUen.
  3. Batchbehandling
    1. Det er en teknikk der enhver oppgave blir utført i enheter som kalles jobber.
    2. En jobb kan føre til at ett eller flere programmer kjøres i rekkefølge.
    3. Jobbplanleggeren tar en beslutning om rekkefølgen jobbene skal utføres i. For å maksimere gjennomsnittlig gjennomstrømning, er jobber planlagt i henhold til deres prioritet og klasse.
    4. Den nødvendige informasjonen for batchbehandling blir gitt gjennom JCL (JOBBKONTROLLSPRÅK). JCL beskriver batchjobben - programmer, data og ressurser som trengs.
  4. Tidsdeling
    1. I et tidsdelingssystem har hver bruker tilgang til systemet gjennom terminalenheten. I stedet for å sende jobber som er planlagt for senere kjøring, skriver brukeren inn kommandoer som behandles umiddelbart.
    2. Derfor kalles dette "Interactive Processing". Det gjør det mulig for brukeren å samhandle direkte med datamaskinen.
    3. Tidsdelingsbehandling er kjent som "Forgrunnsbehandling" og batchjobbbehandlingen er kjent som "Bakgrunnsbehandling."
  5. Spoling
    1. SPOOLing står for Simultaneous Peripheral Operations Online .
    2. SPOOL-enheten brukes til å lagre utdataene fra programmet / applikasjonen. Den spolede utgangen er rettet mot utdataenheter som en skriver (om nødvendig).
    3. Det er et anlegg som utnytter fordelen ved buffering for å gjøre effektiv bruk av utgangsenhetene.

Klassifisering av manuell testing i hovedramme

Mainframe Manual Testing kan deles inn i to typer:

  1. Batch Job Testing -
    • Testprosessen involverer kjøringer av batchjobber for funksjonaliteten som er implementert i den nåværende versjonen.
    • Testresultatet hentet fra utdatafilene og databasen blir verifisert og registrert.
  2. Online testing -
    • Online Testing refererer til testing av CICS-skjermer, som ligner på testing av websiden.
    • Funksjonaliteten til eksisterende skjermer kan endres, eller nye skjermer kan legges til.
    • Ulike applikasjoner kan ha forespørselsskjermer og oppdateringsskjermbilder. Funksjonaliteten til disse skjermene må kontrolleres som en del av online testing.

Hvordan gjøre Mainframe Testing

  1. Forretningsteamet utarbeider kravdokumenter. Som bestemmer hvordan et bestemt element eller en bestemt 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, berøres bare 20-25% av applikasjonen direkte av det tilpassede kravet. De andre 75% av utgivelsen vil være for out-box-funksjonalitet som å teste applikasjoner og prosesser.
  3. Så et Mainframe-program må testes i to deler:
    1. Testkrav - Testing av applikasjonen for funksjonalitet eller endring nevnt i kravdokumentet.
    2. Testing Integration - Testing av hele prosessen eller et annet program som mottar eller sender data til det berørte programmet. Regresjonstesting er det primære fokuset for denne testaktiviteten.

Mainframe Automation Testing Tools

Nedenfor er listen over verktøy som kan brukes til mainframe Automation Testing.

  • REXX
  • utmerke
  • QTP

Metodikk i Mainframe Testing

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

  • Online testing gjøres på medlemsregistreringsskjermen. Akkurat som en webside blir databasen validert med data som er lagt inn gjennom skjermbildene.
  • Frakoblet registrering kan være papirregistrering eller registrering på et tredjeparts nettsted. Offline-dataene (også referert til som batch) vil bli lagt inn i firmadatabasen gjennom batchjobber. En flat flatfil blir klargjort i henhold til det foreskrevne dataformatet og matet til sekvensen av batchjobber. Så for testing av mainframe-applikasjoner kan vi bruke følgende tilnærming.
    • Den første jobben i linjen med batchjobber validerer de oppgitte dataene. La for eksempel si spesialtegn, alfabet i antall bare felt osv.
    • Den andre jobben validerer konsistensen av data basert på forretningsforhold. For eksempel bør en barnepåmelding ikke inneholde avhengige data, medlems postnummer (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 lagrer bare plan-ID og forsikringsplannavn), vedleggsdato for oppføring osv.
    • Den fjerde jobben laster inn dataene i databasen.
  • Batchjobbtesting utføres på denne prosessen i to faser -
    • Hver jobb valideres separat, og
    • Integrering mellom jobbene valideres ved å levere flat flatefil til den første jobben og validere databasen. (Mellomliggende resultater må valideres for ekstra forsiktighet)

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

Trinn 1) : Shakedown / Smoke Testing

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

Trinn 2) : Systemtesting

Nedenfor er testtypene som er gjort som en del av systemtesting.

  1. Batch Testing - Denne testingen vil bli gjort ved å validere testresultatene på utdatafiler og dataendringer utført av batchjobber under testomfang og registrering av dem.
  2. Online testing - Denne testingen vil bli gjort på frontenden av hovedrammeapplikasjonen. Her testes applikasjonen for riktig inngangsfelt som en forsikringsplan, renter på planen, etc.
  3. Online-Batch Integration testing - Denne testingen vil bli gjort på systemene som har batchprosesser og online applikasjon. Dataflyten og samspillet mellom de elektroniske skjermene og batchjobber er validert.

    ( Eksempel på denne typen testing - Vurder en oppdatering av plandetaljer som økning i renten. Endringen av interesse gjøres på en oppdateringsskjerm, og saldoopplysningene på de berørte kontoene endres bare ved en nattlig batchjobb. Testing i dette tilfellet vil du gjøre ved å validere skjermbildet Plandetaljer og batchjobben for oppdatering av alle kontoene).

  4. Databasetesting - Databasene der dataene fra hovedrammeapplikasjonen (IMS, IDMS, DB2, VSAM / ISAM, sekvensielle datasett, GDGer) er validert for layout og datalagring.

Trinn 3) : Testing av systemintegrasjon

Det primære formålet med denne testingen er å validere funksjonaliteten til systemene som samhandler med systemet som testes.

Disse systemene påvirkes ikke direkte av kravene. Imidlertid bruker de data fra systemet som testes. Det er viktig å teste grensesnittet og forskjellige typer meldinger (som jobb vellykket, jobb mislyktes, database oppdatert, etc.) som kan mulig flyte mellom systemene og de resulterende handlingene som tas av de enkelte systemene.

Typer testing utført i dette stadiet er

  1. Batch Testing
  2. Online testing
  3. Online - Testing av batchintegrasjon

Trinn 4) : Regresjonstesting

Regresjonstesting er en vanlig fase i alle typer testprosjekter. Denne testingen i Mainframes sørger for at batchjobber og online-skjermene som ikke direkte samhandler med systemet som testes (eller som ikke kommer inn i kravene) ikke påvirkes av den nåværende prosjektutgivelsen.

For å få effektiv regresjonstesting, bør et bestemt sett med testtilfeller være på listen, avhengig av deres kompleksitet, og det bør opprettes et regresjonslag (Test cases repository). Dette settet bør oppdateres hver gang det er en ny funksjonalitet rullet ut i utgivelsen.

Trinn 5) : Prestasjonstesting

Denne testingen er gjort for å identifisere flaskehalser i områder med høyt hit som frontendata, oppgradering av elektroniske databaser og for å projisere skalerbarheten i applikasjonen.

Trinn 6) : Sikkerhetstesting

Denne testingen er gjort for å evaluere hvor godt applikasjonen er designet og utviklet for å motvirke antisikkerhetsangrep.

To ganger sikkerhetstesting bør gjøres på systemet - Mainframe-sikkerhet og nettverkssikkerhet.

Funksjonene som må testes er

  1. Integritet
  2. konfidensialitet
  3. Autorisasjon
  4. Godkjenning
  5. Tilgjengelighet

Trinn involvert i batch testing

  1. Etter at QA-teamet mottar den godkjente pakken (pakken inneholder prosedyrer, JCL, kontrollkort, moduler osv.), Bør testeren forhåndsvise og hente innholdet i PDS etter behov.
  2. Konverter produksjon JCL eller Development JCL til QA JCL ellers kalt JOBB SETUP.
  3. Kopiering av produksjonsfil og klargjøring av testfiler.
  4. For hver funksjonalitet vil det være definert en jobbsekvens. (Som forklart i eksemplet i Methodology in Mainframe-seksjonen). Jobbene skal sendes inn ved hjelp av SUB-kommandoen sammen med testdatafilene.
  5. Kontroller mellomfilen for å identifisere årsakene til manglende eller feilaktige data.
  6. Kontroller den endelige utdatafilen, databasen og spolen for å validere testresultatene.
  7. Hvis jobben mislykkes, vil spolen ha årsaken til jobbsvikt. Løs feilen og send jobben på nytt.

Testrapportering - Feil skal logges hvis det faktiske resultatet avviker fra forventet.

Fremgangsmåten involvert i online testing

  1. Velg skjermbildet Online i et testmiljø.
  2. Test hvert felt for akseptable data.
  3. Test testscenariet på skjermen.
  4. Bekreft databasen for dataoppdateringene fra online-skjermen.

Testrapportering - Feil skal logges hvis det faktiske resultatet avviker fra forventet.

Fremgangsmåten involvert i Online - Batch Integration testing

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

Kommandoer som brukes i Mainframe Testing

  1. SEND INN - Send inn en bakgrunnsjobb.
  2. AVBRYT - Avbryt bakgrunnsjobben.
  3. TILDELE - Tildel et datasett
  4. KOPIER - Kopier et datasett
  5. RENAME - Gi nytt navn til datasettet
  6. SLETT - Slett datasett
  7. JOBBSKANNING - For å binde JCL med programmet, biblioteker, filer osv. Uten å utføre det.

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 mainframe testing er:

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

Før du begynner å teste mainframe, bør følgende aspekter verifiseres.

  1. Jobb
    1. Gjør en jobbskanning (Command - JOBSCAN) for å se etter feil før du utfører den.
    2. CLASS-parameteren bør pekes på testklassen.
    3. Rett jobbutdata til spole eller en JHS eller etter behov ved hjelp av MSGCLASS-parameteren.
    4. Omadresser e-posten i jobben for å spole eller en test-post-ID.
    5. Kommenter FTP-trinnene for første testing, og pek deretter jobben til en testserver.
    6. Hvis det genereres en IMR (Incident Management record) i jobben, er det bare å legge til kommentaren "TESTING PURPOSE" i jobben eller param-kortet.
    7. Alle produksjonsbibliotekene i jobben bør endres og pekes på testbiblioteker.
    8. Jobben skal ikke overlates uten tilsyn.
    9. For å forhindre at jobben kjøres i en uendelig løkke i tilfelle feil, bør TIME-parameteren legges til med spesifisert tid.
    10. Lagre utdataene fra jobben inkludert spolen. Spolen kan lagres ved hjelp av XDC.
  1. Fil
    1. Opprett testfil bare av nødvendig størrelse. Bruk GDGs (Generation Data Groups - Files with the same name but with sequential version numbers- MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 so on) når det er nødvendig for å lagre data i påfølgende filer med samme navn.
    2. DISP (Disposition - beskriver systemet som skal utføre oppbevaring eller sletting av datasettet etter normal eller unormal avslutning av trinn eller jobb). Parameteren for filene skal være kodet riktig.
    3. Sørg for at alle filene som brukes til jobbutførelse, lagres og lukkes ordentlig for å hindre at jobben går i HOLD.
    4. Når du tester med GDG, må du sørge for at riktig versjon pekes på.
  2. Database
    1. Mens du utfører jobben eller det elektroniske programmet, må du sørge for at utilsiktede data ikke blir satt inn eller oppdatert eller slettet.
    2. Forsikre deg også om at riktig DB2-region brukes til testing.
  3. Test tilfeller
    1. Test alltid for grensebetingelser som - Tom fil, Første postbehandling, Siste postbehandling, etc.
    2. Ta alltid med både positive og negative testforhold.
    3. I tilfelle hvis standardprosedyrer brukes i programmet som Check point restart, Abend Modules, Control files, etc. inkluderer testcases for å validere om modulene har blitt brukt riktig.
  4. Testdata
    1. Oppsett av testdata bør gjøres før begynnelsen av testingen.
    2. Endre aldri dataene i testområdet uten å varsle. Det kan være andre team som jobber med samme data, og testen deres mislykkes.
    3. Hvis produksjonsfilene er nødvendige under utførelsen, bør du få riktig autorisasjon før du kopierer eller bruker dem.

Beste praksis

  1. I tilfelle en batchjobb 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 utdataene er tomme eller ikke som forventet. Så det forventes alltid å sjekke alle utgangene før du erklærer jobben vellykket.
  2. Det er alltid en god praksis å gjøre et tørt løp 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 testjobben settes opp i god tid. Dette vil hjelpe deg med å finne ut JCL-feil på forhånd, og dermed spare tid under kjøring.
  4. Når du får tilgang til DB2-tabeller via SPUFI (Alternativ på emulatoren for å få tilgang til DB2-tabeller), må du alltid sette automatisk forpliktelse som "NEI" for å unngå utilsiktede oppdateringer.
  5. Testdatatilgjengelighet er den viktigste utfordringen i batch-testing. Nødvendige data bør opprettes i god tid før testsyklusen og bør kontrolleres for fullstendighet.
  6. Noen online transaksjoner og batchjobber kan skrive data i MQ (Message Queue) for overføring av data til andre applikasjoner. Hvis dataene ikke er gyldige, kan det deaktivere / stoppe MQ, dette vil påvirke hele testprosessen. Det er en god praksis å sjekke at MQ fungerer bra etter testing.

Mainframe testing Utfordringer og feilsøking

Utfordringer Nærme seg
Ufullstendige / uklare krav Det kan være tilgang til brukerhåndbok / opplæringsguide, men de er ikke det 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 brukes på nytt i henhold til kravet. Noen ganger er det vanskelig å identifisere nødvendige data fra eksisterende data. For dataoppsett kan hjemmelagde verktøy brukes etter behov. For å hente eksisterende data, må spørsmål bygges på forhånd. Ved problemer kan det sendes en forespørsel til datahåndteringsteamet om å 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 banedetaljer. 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 når test til slutt til slutt må støttes på grunn av et problem i oppstrøms- eller nedstrøms applikasjonsproblemer. Disse forespørslene øker tid og krefter i kjøresyklusen. Bruk av automatiseringsskript, regresjonsskript og skjelettskript kan bidra til å redusere tiden og krefter overhead.
Tidlige utgivelser for endring av omfanget Det kan være en situasjon der kodekonsekvensen kan endre utseendet og følelsen av systemet. Dette kan kreve en endring av testtilfeller, skript og data. Prosess for håndtering av endringsomfang og konsekvensanalyse bør være på plass.

Common Abends oppstått

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

    Årsak - Lesing på slutten av filen, fillengdefeil, prøv å skrive inn skrivebeskyttet fil.

  2. S002 - Ugyldig I / O-post.

    Årsak - Forsøk å skrive en plate som er lengre enn rekordlengden.

  3. S004 - Det oppstod en feil under OPEN.

    Årsak - Ugyldig DCB

  4. S013 - Feil ved åpning av datasett.

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

  5. S0C1 - Unntak for drift

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

  6. S0C4 - Beskyttelsesunntak / Lagringsbrudd
  7. Årsak - Prøver tilgang til lagring som ikke er tilgjengelig for programmet.
  8. SC07 - Unntak for programkontroll - 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 loop eller utilstrekkelig tidsparameter.
  13. S522 - Timeout for TSO-økt.
  14. S806 -Kan ikke kobles eller lastes inn.

    Årsak - Job-ID kan ikke finne den spesifiserte lastemodulen.

  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 allokere nok lagring til datasettet.

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

Vanlig problem som står overfor under mainframe-testing

  • Job Abends - For vellykket fullføring av jobben, bør du sjekke data, inndatafil og modulene som er tilstede på det bestemte stedet eller ikke. Abends kan bli møtt på grunn av flere grunner, den vanligste vesenet - Ugyldige data, feil inntastingsfelt, datooverensstemmelse, miljøproblemer, etc.
  • Utdatafilen tom - Selv om jobben kan kjøres vellykket (MaxCC 0), kan det hende at utdataene ikke er som forventet. Så før testeren passerer, må testeren sørge for at utdataene er kryssverifisert. Bare fortsett deretter videre.
  • Inndatafilen er tom - I noen applikasjoner vil filer mottas fra oppstrømsprosesser. Før du bruker den mottatte filen for å teste nåværende applikasjon, bør dataene kryssverifiseres for å unngå re-kjøring og omarbeiding.

Sammendrag:

  • Mainframe testing er som alle andre testprosedyrer 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 forskjellige mainframe testfunksjoner. Som skjermenavigering, oppretting av filer og PDS, lagring av testresultater osv. Før testsyklusen begynner.
  • Hovedrammeapplikasjonstesting er en tidskrevende prosess. En klar testplan skal følges for testdesign, dataoppsett og utføring.
  • Batch-testing og online testing bør gjøres effektivt uten å savne noen funksjonalitet som er nevnt i kravdokumentet, og ingen testsaker skal spares.