Lad os lære, før vi lærer mainframe-testkoncepter
Hvad er en Mainframe?
Mainframe er et højtydende computersystem med høj hastighed. Det bruges til større computingsformå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.
Test af mainframe
Mainframe Testing er en proces til test af softwareapplikationer og tjenester baseret på Mainframe Systems. Formålet med mainframe-test er at sikre ydelsen, pålideligheden og kvaliteten af softwareapplikation eller -tjeneste ved verifikations- og valideringsmetoder og kontrollere, om den er klar til implementering.
Under udførelse af Mainframe-test behøver testeren kun at vide om navigationen på CICS-skærmene. De er specialbygget til specifikke applikationer. Eventuelle ændringer foretaget i koden i COBOL, JCL osv. Tester behøver ikke at bekymre sig om emulatoren, der er opsat på maskinen. De ændringer, der fungerer på en terminalemulator, fungerer på andre.
- Mainframe-applikationen (ellers kaldes jobbatch) testes i forhold til testcases udviklet ved hjælp af krav
- Mainframe Testing udføres normalt på den implementerede kode ved hjælp af forskellige datakombinationer indstillet i inputfilen.
- Programmer, der kører på mainframe, kan tilgås via terminalemulator. Emulatoren er den eneste software, der skal installeres på klientmaskinen.
I denne begyndervejledning lærer du-
- Mainframe-attributter
- Klassificering af manuel test i mainframe
- Sådan udføres Mainframe Testing
- Mainframe Automation Testværktøjer
- Metode i Mainframe Testing
- Trin involveret i batch-test
- Trin involveret i online test
- Trin involveret i online - test af batchintegration
- Kommandoer, der bruges i Mainframe Testing
- Forudsætninger for at starte mainframe-test
- Bedste praksis
- Mainframe test Udfordringer og fejlfinding
- Common Abends stødt på
- Almindeligt problem under mainframe-test
Mainframe-attributter
- Virtuel opbevaring
- Det er en teknik, der lader en processor simulere hovedlager, der er større end den faktiske mængde reel lager.
- Det er en teknik til effektivt at bruge hukommelse til at gemme og udføre forskellige opgaver.
- Det bruger disklagring som en udvidelse af reel lagring.
- Multiprogrammering
- Computeren udfører mere end et program på samme tid. Men på et givet tidspunkt kan kun et program have kontrol over CPU'en.
- Det er en facilitet, der leveres til effektiv brug af CPU'en.
- Batchbehandling
- Det er en teknik, hvorved enhver opgave udføres i enheder, der kaldes job.
- Et job kan få et eller flere programmer til at udføres i en rækkefølge.
- Jobplanlæggeren træffer en beslutning om rækkefølgen, i hvilken jobene skal udføres. For at maksimere den gennemsnitlige kapacitet er job planlagt efter deres prioritet og klasse.
- De nødvendige oplysninger til batchbehandling leveres via JCL (JOB CONTROL LANGUAGE). JCL beskriver batchjob - programmer, data og nødvendige ressourcer.
- Tidsdeling
- I et tidsdelingssystem har hver bruger adgang til systemet via 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.
- Time-share-behandling er kendt som "Forgrundsbehandling", og batch-jobbehandlingen kaldes "Baggrundsbehandling".
- Spoling
- SPOOLing står for Simultaneous Peripheral Operations Online .
- SPOOL-enhed bruges til at gemme output fra program / applikation. Det spolede output dirigeres til outputenheder som 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
Mainframe Manual Testing kan klassificeres i to typer:
- Test af batchjob -
- Testprocessen involverer udførelser af batchjobs for den funktionalitet, der er implementeret i den nuværende udgivelse.
- Testresultatet ekstraheret fra outputfilerne og databasen verificeres og registreres.
- Online test -
- Online test refererer til test af CICS-skærme, der svarer til test af websiden.
- Funktionaliteten på 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 onlinetesten.
Sådan udføres Mainframe Testing
- Forretningsteamet udarbejder kravsdokumenter. Hvilket bestemmer, hvordan et bestemt emne eller en proces skal ændres i frigivelsescyklussen.
- Testteamet og udviklingen modtager kravdokumentet. De vil finde ud af, hvor mange processer der vil blive påvirket af ændringen. Normalt berøres kun 20-25% af applikationen direkte af det tilpassede krav i en frigivelse. De øvrige 75% af udgivelsen vil være til out-box-funktionaliteter som at teste applikationer og processer.
- Så en Mainframe-applikation skal testes i to dele:
- Testkrav - Test af applikationen for funktionalitet eller ændring nævnt i kravdokumentet.
- Testing 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.
Mainframe Automation Testværktøjer
Nedenfor er listen over værktøjer, der kan bruges til mainframe-automatiseringstest.
- REXX
- Excel
- QTP
Metode i Mainframe Testing
Lad os overveje et eksempel: Et XYZ-forsikringsselskab har medlemsregistreringsmodul. Det tager data både fra medlemstilmeldingsskærmen og offline tilmelding. Som vi diskuterede tidligere, tager det to tilgange til Mainframe-test, online-test og batch-test.
- Online test udføres på skærmbilledet til medlemsregistrering. Ligesom en webside er databasen valideret med data indtastet gennem skærmene.
- Offline tilmelding kan være papir tilmelding eller tilmelding på et tredjeparts websted. Offline-dataene (også kaldet batch) vil blive indtastet i virksomhedsdatabasen via batchjob. En flad inputfil udarbejdes i henhold til det foreskrevne dataformat og føres til rækkefølgen af batchjob. 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. Lad os f.eks. Sige specialtegn, alfabeter kun i antal felter osv.
- Det andet job validerer konsistensen af data baseret på forretningsforhold. For eksempel bør en børnetilmelding ikke indeholde afhængige data, medlems postnummer (som ikke er tilgængelig for service af den tilmeldte plan) osv.
- Det tredje job ændrer dataene i det format, der kan indtastes i databasen. Sletning af plannavn (database gemmer kun plan-ID og forsikringsplannavn), tilføjelsesdato for indtastning osv.
- Det fjerde job indlæser dataene i databasen.
- Test af batchjob udføres på denne proces i to faser -
- Hvert job valideres separat, og
- Integration mellem jobene valideres ved at levere input-flat fil til det første job og validere databasen. (Mellemliggende resultater skal valideres for ekstra forsigtighed)
Følgende er metoden, der følges til Mainframe-test:
Trin 1) : Shakedown / røgtest
Hovedfokus i dette trin er at validere, om den implementerede kode er i det rigtige testmiljø. Det sikrer også, at der ikke er nogen kritiske problemer med koden.
Trin 2) : Systemtest
Nedenfor er de typer af test udført som en del af systemtest.
- Batchtest - Denne test udføres ved at validere testresultaterne på outputfiler og dataændringer udført af batchjobs under testomfang og registrering af dem.
- Online test - Denne test udføres i frontenden af mainframe-applikationen. Her testes applikationen for korrekt indtastningsfelt som en forsikringsplan, renter på planen osv.
- Online-batch-integrationstest - Denne test udføres på de systemer, der har batchprocesser og online applikation. Datastrømmen og interaktionen mellem online-skærmbillederne og batchjobs valideres.
( Eksempel på denne type test - Overvej en opdatering af planoplysninger som stigning i renten. Ændringen af interesse foretages på en opdateringsskærm, og balancedetaljerne på de berørte konti ændres kun ved et natligt batchjob. Testning i dette tilfælde gøres ved at validere skærmbilledet Planoplysninger og batch-jobkørslen til opdatering af alle konti).
- Databasetest - De databaser, hvor dataene fra mainframe-applikationen (IMS, IDMS, DB2, VSAM / ISAM, sekventielle datasæt, GDG'er) valideres for deres layout og datalagring.
Trin 3) : Systemintegrationstest
Det primære formål med denne test er at validere funktionaliteten af de systemer, der interagerer med det testede system.
Disse systemer påvirkes ikke direkte af kravene. De bruger dog data fra det testede system. Det er vigtigt at teste grænsefladen og forskellige typer meddelelser (som Job vellykket, Job mislykkedes, Database opdateret osv.), Der kan flyde mellem systemerne og de resulterende handlinger, der udføres af de enkelte systemer.
Typer af test udført i dette trin er
- Batchtest
- Online test
- Online - Test af batchintegration
Trin 4) : Regressionstest
Regressionstest er en almindelig fase i enhver form for testprojekt. Denne test i Mainframes sikrer, at batchjobs og online-skærme, der ikke direkte interagerer med systemet under test (eller ikke kommer inden for kravene), ikke påvirkes af den aktuelle projektudgivelse.
For at få effektiv regressionstest bør et bestemt sæt testtilfælde være på listen, afhængigt af deres kompleksitet, og der skal oprettes et regressionsseng (Test cases repository). Dette sæt skal opdateres, når der er en ny funktionalitet rullet ud i udgivelsen.
Trin 5) : Test af ydeevne
Denne test udføres for at identificere flaskehalse i områder med høj hit som frontendata, opgradering af online databaser og for at projicere 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 skal udføres to gange sikkerhedstest på systemet - Mainframe-sikkerhed og netværkssikkerhed.
De funktioner, der skal testes, er
- Integritet
- Fortrolighed
- Bemyndigelse
- Godkendelse
- Tilgængelighed
Trin involveret i batch-test
- Når QA-teamet har modtaget den godkendte pakke (pakken indeholder procedurer, JCL, kontrolkort, moduler osv.), Skal testeren forhåndsvise og hente indholdet i PDS efter behov.
- Konverter produktions-JCL eller Development JCL til QA JCL, der ellers kaldes JOB SETUP.
- Kopiering af produktionsfil og klargøring af testfiler.
- For hver funktionalitet vil der være en jobsekvens defineret. (Som forklaret i eksemplet i afsnittet Methodology i Mainframe). Jobbet skal sendes ved hjælp af SUB-kommandoen sammen med testdatafiler.
- Kontroller den mellemliggende fil for at identificere årsagerne til manglende eller fejlagtige data.
- Kontroller den endelige outputfil, database og spool for at validere testresultaterne.
- Hvis jobbet mislykkes, vil spolen have årsagen til jobfejlen. Løs fejlen, og indsend jobbet igen.
Testrapportering - Fejl skal logges, hvis det faktiske resultat afviger fra forventet.
Trin involveret i online test
- Vælg Online-skærmen i et testmiljø.
- Test hvert felt for de acceptable data.
- Test testscenariet på skærmen.
- Bekræft databasen for dataopdateringer fra online skærmen.
Testrapportering - Fejl skal logges, hvis det faktiske resultat afviger fra forventet.
Trin involveret i online - test af batchintegration
- Kør jobbet i et testmiljø, og valider dataene på onlineskærmene.
- Opdater dataene på onlineskærmene, og valider, hvis batchjobbet køres korrekt med de opdaterede data.
Kommandoer, der bruges i Mainframe Testing
- SUBMIT - Indsend et baggrundsjob.
- ANNULLER - Annuller baggrundsjobbet.
- TILDELE - Tildel et datasæt
- COPY - Kopier et datasæt
- RENAME - Omdøb datasæt
- SLET - Slet datasæt
- JOB SCAN - For at binde JCL med programmet, biblioteker, fil osv. Uden at udføre det.
Der er mange andre kommandoer, der bruges, når det kræves, men de er ikke så hyppige.
Forudsætninger for at starte mainframe-test
Grundlæggende detaljer, der er nødvendige til mainframe-test, er:
- Login-id og adgangskode til at logge ind på applikationen.
- Kort viden om ISPF-kommandoer.
- Navne på filerne, filkvalificering og deres typer.
Inden du starter mainframe-test, skal nedenstående aspekter verificeres.
- Job
- Udfør en jobscanning (Command - JOBSCAN) for at kontrollere, om der er fejl, før du udfører den.
- CLASS-parameteren skal peges på testklassen.
- Ret joboutputtet til en spole eller en JHS eller efter behov ved hjælp af MSGCLASS-parameteren.
- Omdiriger e-mailen i jobbet for at spole eller et test-mail-id.
- Kommenter FTP-trinene til indledende test, og ret jobbet til en testserver.
- Hvis der genereres en IMR (Incident Management-post) i jobbet, skal du blot tilføje kommentar "TESTING FORMÅ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, at jobbet kører i en uendelig loop i tilfælde af en fejl, skal TIME-parameteren tilføjes med den angivne tid.
- Gem output fra jobbet inklusive spolen. Spolen kan gemmes ved hjælp af XDC.
- Fil
- Opret kun testfil af den nødvendige størrelse. Brug GDG'er (Generations Data Groups - Files with the same name but with sequential version numbers- MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 osv.), Når det er nødvendigt for at gemme data i fortløbende filer med samme navn.
- DISP (Disposition - beskriver systemet til at udføre opbevaring eller sletning af datasættet efter normal eller unormal afslutning af trin eller job) Parameteren for filerne skal kodes korrekt.
- Sørg for, at alle de filer, der bruges til jobudførelse, gemmes og lukkes korrekt for at forhindre, at job går i HOLD.
- Når du tester med GDG'er, skal du sørge for, at den rigtige version peges på.
- Database
- Mens du udfører jobbet eller online-programmet, skal du sikre dig, at utilsigtede data ikke indsættes eller opdateres eller slettes.
- Sørg også for, at den korrekte DB2-region bruges til testning.
- Test tilfælde
- Test altid for randbetingelser som - Tom fil, Første postbehandling, Sidste recordbehandling osv.
- Inkluder altid både positive og negative testbetingelser.
- I tilfælde af at der anvendes standardprocedurer i programmet som genstart af kontrolpunktet, inkluderer Abend-moduler, kontrolfiler osv. Testcases for at validere, hvis modulerne er brugt korrekt.
- Testdata
- Opsætning af testdata skal udføres inden starten af testen.
- Du må aldrig ændre dataene i testområdet uden at underrette det. Der kan være andre teams, der arbejder med samme data, og deres test mislykkes.
- Hvis produktionsfilerne er nødvendige under udførelsen, skal der opnås korrekt autorisation, før de kopieres eller bruges.
Bedste praksis
- I tilfælde af et batchjob-kørsel er MAX CC 0 en indikator for, at jobbet har kørt med succes. Det betyder ikke, at funktionaliteten fungerer fint. Jobbet kører med succes, selv når output er tomt eller ikke som forventet. Så det forventes altid at kontrollere alle output, inden job erklæres vellykket.
- Det er altid en god praksis at udføre et tørt løb af det job, der testes. Tørkørsel udføres med tomme inputfiler. Denne proces skal følges for de job, der er påvirket af de ændringer, der er foretaget i testcyklussen.
- Før testcyklussen begynder, skal opsætningen af testjob gøres i god tid. Dette vil hjælpe med at finde ud af JCL-fejl på forhånd og dermed spare tid under udførelse.
- Når 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 "NO" for at undgå utilsigtede opdateringer.
- Testdatatilgængelighed er den primære udfordring i batch-test. Nødvendige data skal oprettes i god tid før testcyklussen og skal kontrolleres for fuldstændighed.
- Nogle onlinetransaktioner og batchjob skriver muligvis data i MQ'er (Message Queue) til transmission af data til andre applikationer. Hvis dataene ikke er gyldige, kan det 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 | Nærme sig |
| Ufuldstændige / uklare krav Der kan være adgang til brugervejledning / træningsvejledning, men disse er ikke det samme som dokumenterede krav. | Testere bør være involveret i SDLC fra kravsfasen og fremefter. Dette hjælper med at kontrollere, om kravene kan testes. |
| Dataopsætning / identifikation Der kan være situationer, hvor eksisterende data skal genbruges i henhold til kravet. Det er undertiden vanskeligt at identificere de krævede 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 der sendes en anmodning til datahåndteringsteamet om oprettelse eller kloning af nødvendige data. |
| Jobopsætning Når jobbet er hentet til PDS, skal jobbet konfigureres i QA-regionen. Så job ikke indsendes med produktionskvalificering eller stigdetalje. | Værktøjer til jobopsætning skal bruges til at overvinde menneskelige fejl, der er foretaget under opsætningen. |
| Ad-hoc-anmodning Der kan være situationer, hvor test til slut til slut skal understøttes på grund af et problem i upstream- eller downstream-applikationsproblemer. Disse anmodninger øger tid og kræfter i eksekveringscyklussen. | Brug af automatiseringsskripts, regressionsskripts og skeletskripts kan hjælpe med at reducere tiden og kræfterne. |
| On-Time frigivelser til omfangsændring Der kan være en situation, hvor kodens indvirkning kan ændre systemets udseende og fornemmelse fuldstændigt. Dette kan kræve en ændring af testsager, scripts og data. | Omfangsstyringsproces og konsekvensanalyse bør være på plads. |
Common Abends stødt på
- S001 - Der opstod en I / O-fejl.
Årsag - Læsning i slutningen af filen, fillængdefejl, forsøg på at skrive til skrivebeskyttet fil.
- S002 - Ugyldig I / O-post.
Årsag - Forsøg at skrive en post, der er længere end rekordlængden.
- S004 - Der opstod en fejl under OPEN.
Årsag - Ugyldig DCB
- S013 - Fejl ved åbning af et datasæt.
Årsag - PDS-medlem findes ikke, rekordlængde i programmet svarer ikke til den faktiske rekordlængde.
- S0C1 - Undtagelse af drift
Årsag - Kan ikke åbne filen, mangler DD-kort
- S0C4 - Undtagelse af beskyttelse / overtrædelse af lagring
- Årsag - At prøve adgangslager ikke tilgængelig for programmet.
- SC07 - Undtagelse af programkontrol - data
- Årsag - Ændring i postlayout eller fillayout.
- Sx22 - Job er annulleret
- S222 - Job annulleret af brugeren uden dump.
- S322 - Job- eller trintid overskred den angivne grænse, eller programmet er i en loop eller utilstrækkelig tidsparameter.
- S522 - Timeout for TSO-session.
- S806 - Kan ikke linke eller indlæse.
Årsag - Job-id kan ikke finde det specificerede belastningsmodul.
- S80A - Ikke nok virtuel lagerplads til at tilfredsstille GETMAIN- eller FREEMAIN-anmodninger.
- S913 - Forsøger at få adgang til datasættet, som brugeren ikke er autoriseret.
- Sx37 - Kan ikke allokere nok lager til datasættet.
Error Assist - Et meget populært værktøj til at få detaljeret information om forskellige typer af abends.
Almindeligt problem under mainframe-test
- Job afvikles - For en vellykket afslutning af jobbet skal du kontrollere data, inputfil og de moduler, der findes på det specifikke sted eller ej. Abends kan blive konfronteret på grund af flere grunde, hvor den mest almindelige er - Ugyldige data, forkert indtastningsfelt, datooverensstemmelse, miljøproblemer osv.
- Outputfil tom - Selvom jobbet muligvis kører korrekt (MaxCC 0), er output muligvis ikke som forventet. Så før testeren gennemføres, skal testeren sørge for, at output er krydsverificeret. Først derefter videre.
- Inputfil tom - I nogle applikationer modtages 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 startende fra kravindsamling, testdesign, testudførelse og resultatrapportering.
- For at teste applikationen effektivt skal testeren deltage i designmøder planlagt af udviklings- og forretningsteams.
- Det er obligatorisk for testeren at vænne sig til forskellige mainframe testfunktioner. Ligesom skærmnavigation, oprettelse af filer og PDS, gemning af testresultater osv. Inden testcyklussen begynder.
- Test af mainframe-applikationer er en tidskrævende proces. En klar testplan skal følges for testdesign, dataopsætning og udførelse.
- Batchtest og onlinetestning skal udføres effektivt uden at gå glip af nogen funktionalitet, der er nævnt i kravdokumentet, og ingen testsager skal spares.