Lär oss lära oss innan vi lär oss huvudtestningskoncept
Vad är en Mainframe?
Mainframe är en högpresterande och ett höghastighetsdatasystem. Den används i större skala för datoranvändning som kräver stor tillgänglighet och säkerhet. Det används mest i sektorer som finans, försäkring, detaljhandel och andra kritiska områden där enorma data bearbetas flera gånger.
Mainframe Testing
Mainframe Testing är en process för att testa programapplikationer och tjänster baserade på Mainframe Systems. Syftet med mainframe-testning är att säkerställa prestanda, tillförlitlighet och kvalitet på programvara eller tjänster genom verifierings- och valideringsmetoder och kontrollera om den är redo att distribueras.
Under testning av Mainframe behöver testaren bara veta om navigering på CICS-skärmarna. De är specialbyggda för specifika applikationer. Alla ändringar som görs i koden i COBOL, JCL, etc. tester behöver inte oroa sig för emulatorn som är inställd på maskinen. Ändringarna som fungerar på en terminalemulator kommer att fungera på andra.
- Mainframe-applikationen (annars kallad job-batch) testas mot de testfall som utvecklats med hjälp av krav
- Mainframe Testing utförs vanligtvis på den distribuerade koden med hjälp av olika datakombinationer som anges i inmatningsfilen.
- Tillämpningar som körs på stordatorn kan nås via terminalemulator. Emulatorn är den enda programvaran som behöver installeras på klientmaskinen.
I den här nybörjarhandledningen lär du dig-
- Mainframe-attribut
- Klassificering av manuell testning i Mainframe
- Hur man gör Mainframe Testing
- Mainframe Automation Testing Tools
- Metod i Mainframe Testing
- Steg involverade i partitestning
- Steg involverade i onlinetestning
- Steg involverade i Online - Batch Integration-testning
- Kommandon som används vid Mainframe Testing
- Förutsättningar för att starta mainframe-test
- Bästa praxis
- Mainframe test Utmaningar och felsökning
- Common Abends påträffades
- Vanligt problem vid testning av stordator
Mainframe-attribut
- Virtuell lagring
- Det är en teknik som låter en processor simulera huvudlagring som är större än den faktiska mängden verklig lagring.
- Det är en teknik för att effektivt använda minnet för att lagra och utföra uppgifter av olika storlek.
- Det använder disklagring som en förlängning av verklig lagring.
- Multiprogrammering
- Datorn kör mer än ett program samtidigt. Men vid ett givet tillfälle kan bara ett program ha kontroll över CPU.
- Det är en anläggning som tillhandahålls för att effektivt använda CPU: n.
- Satsvis bearbetning
- Det är en teknik genom vilken varje uppgift utförs i enheter som kallas jobb.
- Ett jobb kan få ett eller flera program att köras i en sekvens.
- Jobbschemaläggaren fattar ett beslut om i vilken ordning jobben ska utföras. För att maximera den genomsnittliga genomströmningen schemaläggs jobb enligt deras prioritet och klass.
- Den nödvändiga informationen för batchbearbetning tillhandahålls via JCL (JOBBKONTROLLSPRÅK). JCL beskriver batchjobbet - program, data och resurser som behövs.
- Tidsdelning
- I ett system för tidsdelning har varje användare tillgång till systemet via terminalenheten. Istället för att skicka jobb som är planerade för senare körning anger användaren kommandon som behandlas omedelbart.
- Därför kallas detta "Interaktiv bearbetning". Det gör det möjligt för användaren att interagera direkt med datorn.
- Tidsdelningsbehandling är känd som "Förgrundsbehandling" och bearbetning av batchjobb kallas "Bakgrundsbehandling".
- Spolning
- SPOOLing står för Simultaneous Peripheral Operations Online .
- SPOOL-enheten används för att lagra utdata från program / applikation. Den spolade utgången riktas till utdataenheter som en skrivare (om det behövs).
- Det är en anläggning som utnyttjar fördelen med buffring för att effektivt utnyttja utdataenheterna.
Klassificering av manuell testning i Mainframe
Manuell testning av Mainframe kan delas in i två typer:
- Batch Job Testing -
- Testprocessen innefattar körningar av batchjobb för den funktionalitet som implementeras i den aktuella versionen.
- Testresultatet extraherat från utdatafilerna och databasen verifieras och registreras.
- Online-testning -
- Onlinetestning avser testning av CICS-skärmar som liknar testning av webbsidan.
- Funktionen på de befintliga skärmarna kan ändras eller nya skärmar kan läggas till.
- Olika applikationer kan ha förfrågningsskärmar och uppdatera skärmar. Funktionerna på dessa skärmar måste kontrolleras som en del av online-testningen.
Hur man gör Mainframe Testing
- Verksamhetsteamet förbereder kravdokument. Vilket avgör hur ett visst objekt eller en process kommer att ändras under frigöringscykeln.
- Testteamet och utvecklingen får kravdokumentet. De kommer att ta reda på hur många processer som kommer att påverkas av förändringen. I en version påverkas vanligtvis endast 20-25% av applikationen direkt av det anpassade kravet. De andra 75% av utgåvan kommer att användas för out-box-funktioner som att testa applikationer och processer.
- Så en Mainframe-applikation måste testas i två delar:
- Testkrav - Testa applikationen för funktionalitet eller ändring som nämns i kravdokumentet.
- Testing Integration - Testar hela processen eller annan applikation som tar emot eller skickar data till den berörda applikationen. Regressionstestning är det primära fokus för denna testaktivitet.
Mainframe Automation Testing Tools
Nedan finns en lista över verktyg som kan användas för testning av mainframe-automatisering.
- REXX
- Excel
- QTP
Metod i Mainframe Testing
Låt oss överväga ett exempel: Ett XYZ-försäkringsbolag har medlemsregistreringsmodul. Det tar data både från medlemsregistreringsskärmen och offlineregistrering. Som vi diskuterade tidigare krävs två metoder för Mainframe-test, online-test och batch-test.
- Onlinetestning görs på medlemsregistreringsskärmen. Precis som en webbsida valideras databasen med data som matas in genom skärmarna.
- Offline-registrering kan vara pappersregistrering eller registrering på en tredje parts webbplats. Offline-data (även kallad batch) kommer att läggas in i företagets databas via batchjobb. En inmatad plattfil förbereds enligt det föreskrivna dataformatet och matas till sekvensen för batchjobb. Så för mainframe-applikationstestning kan vi använda följande tillvägagångssätt.
- Det första jobbet i raden av batchjobb validerar de angivna uppgifterna. Låt säga till exempel specialtecken, alfabet i antal endast fält etc.
- Det andra jobbet validerar konsistensen av data baserat på affärsvillkor. Till exempel bör en barnregistrering inte innehålla beroende data, medlemspostnummer (som inte är tillgängligt för service av den registrerade planen) etc.
- Det tredje jobbet ändrar data i det format som kan matas in i databasen. Om du till exempel tar bort plannamnet (databasen lagras endast plan-ID och försäkringsplanens namn), tilläggsdatum för posten etc.
- Det fjärde jobbet läser in data i databasen.
- Batchjobbtestning görs på denna process i två faser -
- Varje jobb valideras separat och
- Integrationen mellan jobben valideras genom att tillhandahålla platt plattfil för det första jobbet och validera databasen. (Mellanresultat måste valideras för extra försiktighet)
Följande är metoden som följts för Mainframe-testning:
Steg 1) : Shakedown / rökprovning
Huvudfokus i detta steg är att validera om koden som används är i rätt testmiljö. Det säkerställer också att det inte finns några kritiska problem med koden.
Steg 2) : Systemtestning
Nedan följer de typer av tester som görs som en del av systemtestning.
- Partitestning - Denna testning kommer att göras genom att validera testresultaten på utdatafiler och dataändringar som görs av batchjobben under testomfång och registrering av dem.
- Onlinetestning - Den här testningen kommer att göras på framsidan av mainframe-applikationen. Här testas applikationen för korrekt inmatningsfält som en försäkringsplan, ränta på planen etc.
- Online-batch-integrationstestning - Denna testning kommer att göras på system som har batchprocesser och onlineapplikation. Dataflödet och interaktionen mellan online-skärmarna och batchjobben valideras.
( Exempel på denna typ av testning - Tänk på en uppdatering av planuppgifter som höjning av räntan. Intresseändringen görs på en uppdateringsskärm och balansuppgifterna på de berörda kontona kommer endast att ändras med ett nattligt batchjobb. Testning i det här fallet kommer du att göra genom att validera skärmen Plandetaljer och batchjobbet för uppdatering av alla konton).
- Databastestning - De databaser där data från mainframe-applikationen (IMS, IDMS, DB2, VSAM / ISAM, sekventiella datamängder, GDG: er) valideras för deras layout och datalagring.
Steg 3) : Test av systemintegration
Det primära syftet med denna testning är att validera funktionaliteten hos de system som interagerar med systemet som testas.
Dessa system påverkas inte direkt av kraven. De använder dock data från det testade systemet. Det är viktigt att testa gränssnittet och olika typer av meddelanden (som jobb lyckades, jobb misslyckades, databas uppdaterad, etc.) som kan flöda mellan systemen och de resulterande åtgärder som de enskilda systemen vidtar.
Typer av test som görs i detta skede är
- Partitestning
- Onlinetestning
- Online - Testning av batchintegration
Steg 4) : Regressionstestning
Regressionstestning är en vanlig fas i alla typer av testprojekt. Denna testning i Mainframes säkerställer att batchjobb och online-skärmar som inte direkt interagerar med systemet som testas (eller inte omfattas av kraven) inte påverkas av den aktuella projektreleasen.
För att få en effektiv regressionstestning bör en särskild uppsättning testfall vara listade beroende på deras komplexitet och en regressionsbädd (Testfall-arkiv) bör skapas. Denna uppsättning bör uppdateras när det finns en ny funktionalitet som lanseras i utgåvan.
Steg 5) : Prestandatestning
Denna testning görs för att identifiera flaskhalsar i områden med höga hit som frontendata, uppgradering av onlinedatabaser och för att projicera applikationens skalbarhet.
Steg 6) : Säkerhetstestning
Denna testning görs för att utvärdera hur väl applikationen är utformad och utvecklad för att motverka anti-säkerhetsattacker.
Tvåfaldig säkerhetstestning bör göras på systemet - Mainframe-säkerhet och nätverkssäkerhet.
De funktioner som behöver testas är
- Integritet
- Sekretess
- Tillstånd
- Autentisering
- Tillgänglighet
Steg involverade i partitestning
- Efter att QA-teamet fått det godkända paketet (paketet innehåller procedurer, JCL, kontrollkort, moduler etc.) ska testaren förhandsgranska och hämta innehållet i PDS efter behov.
- Konvertera produktions JCL eller Development JCL till QA JCL annars kallad JOB SETUP.
- Kopiera produktionsfilen och förbereda testfiler.
- För varje funktionalitet definieras en jobbsekvens. (Som förklaras i exemplet i avsnittet Metodik i Mainframe). Jobben ska skickas med SUB-kommandot med testdatafilerna.
- Kontrollera mellanfilen för att identifiera orsakerna till att data saknas eller felaktigt.
- Kontrollera den slutliga utdatafilen, databasen och spolen för att validera testresultaten.
- Om jobbet misslyckas kommer spolen att ha orsaken till att jobbet misslyckades. Åtgärda felet och skicka in jobbet igen.
Testrapportering - Fel ska loggas om det faktiska resultatet avviker från förväntat.
Steg involverade i onlinetestning
- Välj Online-skärmen i en testmiljö.
- Testa varje fält för godtagbara data.
- Testa testscenariot på skärmen.
- Verifiera databasen för datauppdateringar från online-skärmen.
Testrapportering - Fel ska loggas om det faktiska resultatet avviker från förväntat.
Steg involverade i Online - Batch Integration-testning
- Kör jobbet i en testmiljö och validera data på online-skärmarna.
- Uppdatera data på online-skärmarna och validera om batchjobbet körs korrekt med de uppdaterade uppgifterna.
Kommandon som används vid Mainframe Testing
- SUBMIT - Skicka ett bakgrundsjobb.
- AVBRYT - Avbryt bakgrundsjobb.
- ALLOCATE - Tilldela en dataset
- COPY - Kopiera en dataset
- RENAME - Byt namn på datauppsättningen
- RADERA - Ta bort datauppsättning
- JOBBSKANNING - Att binda JCL till programmet, biblioteken, filen etc. utan att köra det.
Det finns många andra kommandon som används vid behov, men de är inte så frekventa.
Förutsättningar för att starta mainframe-test
Grundläggande detaljer som behövs för mainframe-testning är:
- Inloggnings-ID och lösenord för att logga in i applikationen.
- Kort kunskap om ISPF-kommandon.
- Namnen på filerna, filkvalificering och deras typer.
Innan du börjar testa mainframe bör följande aspekter verifieras.
- Jobb
- Gör en jobbsökning (Command - JOBSCAN) för att söka efter fel innan du kör den.
- CLASS-parametern ska pekas på testklassen.
- Rikta jobbutmatningen till en spole eller en JHS eller efter behov med hjälp av parametern MSGCLASS.
- Omdirigera e-postmeddelandet i jobbet för att spole eller ett test-post-ID.
- Kommentera FTP-stegen för inledande testning och rikta sedan jobbet till en testserver.
- Om en IMR (Incident Management-post) genereras i jobbet, lägg bara till en kommentar "TESTMÅL" i jobbet eller param-kortet.
- Alla produktionsbibliotek i jobbet bör ändras och pekas på testbibliotek.
- Jobbet ska inte lämnas utan uppsikt.
- För att förhindra att jobbet körs i ett oändligt slinga i fall av något fel bör TIME-parametern läggas till med angiven tid.
- Spara utmatningen från jobbet inklusive spolen. Spolen kan sparas med XDC.
- Fil
- Skapa endast testfil av önskad storlek. Använd GDGs (Generation Data Groups - Files with the same name but with sequential version numbers- MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 so on) vid behov för att lagra data i på varandra följande filer med samma namn.
- DISP (Disposition - beskriver systemet för att utföra förvaring eller radering av dataset efter normal eller onormal avslutning av steget eller jobbet). Parametern för filerna ska kodas korrekt.
- Se till att alla filer som används för utförande av jobb sparas och stängs ordentligt för att förhindra att jobb går in i HOLD.
- När du testar med GDG, se till att rätt version pekas på.
- Databas
- När du utför jobbet eller onlineprogrammet, se till att oavsiktliga data inte infogas eller uppdateras eller raderas.
- Se också till att rätt DB2-region används för testning.
- Testfall
- Testa alltid för gränsvillkor som - Tom fil, Första postbearbetning, Senaste postbearbetning etc.
- Inkludera alltid både positiva och negativa testförhållanden.
- Om standardprocedurer används i programmet som omstart av kontrollpunkten, innehåller Abend-moduler, kontrollfiler etc. testfall för att validera om modulerna har använts korrekt.
- Testdata
- Installationen av testdata bör göras före testets början.
- Ändra aldrig data i testområdet utan att meddela. Det kan finnas andra team som arbetar med samma data, och deras test skulle misslyckas.
- Om produktionsfilerna behövs under körningen bör korrekt auktorisering erhållas innan du kopierar eller använder dem.
Bästa praxis
- I fall av en batchjobb är MAX CC 0 en indikator på att jobbet har körts framgångsrikt. Det betyder inte att funktionaliteten fungerar bra. Jobbet körs framgångsrikt även när utmatningen är tom eller inte enligt förväntningarna. Så det förväntas alltid att kontrollera alla utdata innan jobbet lyckas.
- Det är alltid bra att göra en torr körning av det jobb som testas. Torrkörning görs med tomma inmatningsfiler. Denna process bör följas för de jobb som påverkas av de ändringar som gjorts för testcykeln.
- Innan testcykeln börjar ska testjobbet göras i god tid. Detta kommer att hjälpa till att ta reda på eventuella JCL-fel i förväg, vilket sparar tid under körningen.
- När du öppnar DB2-tabeller via SPUFI (Alternativ på emulatorn för att komma åt DB2-tabeller), ställer du alltid in auto commit som "NO" för att undvika oavsiktliga uppdateringar.
- Testdatatillgänglighet är den primära utmaningen vid batch-testning. Nödvändiga data bör skapas i god tid före testcykeln och bör kontrolleras för fullständighet.
- Vissa onlinetransaktioner och batchjobb kan skriva data i MQ: er (Message Queue) för överföring av data till andra applikationer. Om data inte är giltiga kan det avaktivera / stoppa MQ: er, detta kommer att påverka hela testprocessen. Det är bra att kontrollera att MQ: er fungerar bra efter testning.
Mainframe test Utmaningar och felsökning
| Utmaningar | Närma sig |
| Ofullständiga / oklara krav Det kan finnas tillgång till användarmanual / träningsguide, men de är inte samma som dokumenterade krav. | Testare bör involveras i SDLC från kravfasen och framåt. Detta hjälper till att verifiera om kraven kan testas. |
| Datainställning / identifiering Det kan finnas situationer där befintliga data bör återanvändas enligt kravet. Ibland är det svårt att identifiera nödvändiga data från befintliga data. | För datainställning kan hemodlade verktyg användas efter behov. För att hämta befintlig data bör frågor byggas i förväg. Vid problem kan en begäran ställas till datahanteringsgruppen för att skapa eller klona nödvändiga data. |
| Jobbinställning När jobben har hämtats till PDS måste jobbet ställas in i QA-regionen. Så att jobben inte skickas in med produktionskvalificering eller sökväg. | Verktyg för jobbinställningar bör användas för att övervinna mänskliga fel som görs under installationen. |
| Ad hoc-förfrågan Det kan finnas situationer när testning från slut till slut måste stödjas på grund av ett problem i applikationer uppströms eller nedströms. Dessa förfrågningar ökar tiden och ansträngningen i exekveringscykeln. | Användning av automatiseringsskript, regressionsskript och skelettskript kan hjälpa till att minska tiden och ansträngningen. |
| On-Time Releases för områdesändring Det kan finnas en situation där kodpåverkan kan förändra systemets utseende och känsla. Detta kan kräva en ändring av testfall, skript och data. | Omfattningsförändringsprocess och konsekvensanalys bör finnas på plats. |
Common Abends påträffades
- S001 - Ett I / O-fel uppstod.
Orsak - Läsning i slutet av filen, fillängdsfel, försök att skriva till skrivskyddad fil.
- S002 - Ogiltig I / O-post.
Orsak - Försök att skriva en post längre än postlängden.
- S004 - Fel inträffade under OPEN.
Orsak - Ogiltig DCB
- S013 - Fel vid öppning av en dataset.
Orsak - PDS-medlem finns inte, inspelningslängden i programmet matchar inte den faktiska postlängden.
- S0C1 - Undantag för drift
Anledning - Det går inte att öppna filen, DD-kort saknas
- S0C4 - Skyddsundantag / lagringsöverträdelse
- Orsak - Att prova åtkomstlagring inte tillgängligt för programmet.
- SC07 - Undantag för programkontroll - Data
- Orsak - Ändring av postlayout eller fillayout.
- Sx22 - Jobbet har avbrutits
- S222 - Jobb avbrutet av användaren utan dumpning.
- S322 - Jobb- eller stegtid överskred den angivna gränsen, eller programmet är i en loop eller otillräcklig tidsparameter.
- S522 - Timeout för TSO-session.
- S806 - Kan inte länka eller ladda.
Orsak - jobb-ID kan inte hitta den angivna belastningsmodulen.
- S80A - Inte tillräckligt med virtuell lagring för att tillgodose GETMAIN- eller FREEMAIN-förfrågningar.
- S913 - Försöker komma åt den dataset som användaren inte är auktoriserad.
- Sx37 - Det går inte att allokera tillräckligt med lagring till datasetet.
Error Assist - Ett mycket populärt verktyg för att få detaljerad information om olika typer av abends.
Vanligt problem vid testning av stordator
- Job Abends - För att lyckas med jobbet bör du kontrollera data, inmatningsfil och modulerna som finns på den specifika platsen eller inte. Abends kan mötas av flera skäl, det vanligaste är - Ogiltiga data, felaktigt inmatningsfält, datummatchning, miljöfrågor etc.
- Utdatafilen tom - Även om jobbet kan köras framgångsrikt (MaxCC 0) kanske inte utdata är som förväntat. Så innan testet passerar måste testaren se till att utdata är korsverifierad. Först sedan fortsätt vidare.
- Inmatningsfilen tom - I vissa applikationer kommer filer att tas emot från uppströmsprocesserna. Innan du använder den mottagna filen för att testa aktuell applikation, bör uppgifterna korsverifieras för att undvika återkörning och omarbetning.
Sammanfattning:
- Mainframe-testning är som alla andra testprocedurer med början från kravinsamling, testdesign, testkörning och resultatrapportering.
- För att testa applikationen effektivt bör testaren delta i designmöten som planeras av utvecklings- och affärsteam.
- Det är obligatoriskt för testaren att vänja sig vid olika mainframe-testfunktioner. Som skärmnavigering, fil- och PDS-skapande, spara testresultat etc. innan testcykeln börjar.
- Mainframe-applikationstestning är en tidtagande process. Ett tydligt testschema bör följas för testdesign, datainställning och utförande.
- Partitestning och online-testning bör göras effektivt utan att någon funktionalitet som nämns i kravdokumentet saknas, och inget testfall bör sparas.