Stordatortestning – komplett handledning

Låt oss lära dig innan du lär dig koncept för stordatortestning

Vad är en stordator?

Stordatorn är ett datorsystem med hög prestanda och hög hastighet. Den används för större beräkningsändamål 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 behandlas flera gånger.

Stordatortestning

Stordatortestning är en process för att testa mjukvaruapplikationer och tjänster baserade på stordatorsystem. Syftet med stordatortestning är att säkerställa prestanda, tillförlitlighet och kvalitet hos programvara eller tjänst genom verifiering och valideringsmetoder och kontrollera om den är redo att distribueras.

När testaren utför stordatortestning behöver testaren bara veta om navigeringen på CICS-skärmarna. De är specialbyggda för specifika applikationer. Eventuella ändringar som görs i koden i COBOL, JCL, etc. testare 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.

• Stordatorapplikationen (även kallad jobbbatch) testas mot de testfall som utvecklats med krav
• Stordatortestning utförs vanligtvis på den distribuerade koden med hjälp av olika datakombinationer som ställs in i indatafilen.
• Applikationer som körs på stordatorn kan nås via terminalemulatorn. Emulatorn är den enda programvaran som behöver installeras på klientdatorn.

Stordatorattribut

1. Virtuell lagring
   1. Det är en teknik som låter en processor simulera huvudlagring som är större än den faktiska mängden verklig lagring.
   2. Det är en teknik för att effektivt använda minne för att lagra och utföra uppgifter i olika storlekar.
   3. Den använder disklagring som en förlängning av verklig lagring.
2. Multiprogrammering
   1. Datorn kör mer än ett program samtidigt. Men vid varje givet tillfälle kan bara ett program ha kontroll över CPU.
   2. Det är en möjlighet att effektivt använda CPU:n.
3. Satsvis bearbetning
   1. Det är en teknik genom vilken alla uppgifter utförs i enheter som kallas jobb.
   2. Ett jobb kan orsaka att ett eller flera program körs i en sekvens.
   3. Jobbplaneraren 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.
   4. Den nödvändiga informationen för batchbearbetning tillhandahålls genom JCL (JOBB CONTROL LANGUAGE). JCL beskriver batchjobbet – program, data och resurser som behövs.
4. Tidsdelning
   1. I ett tidsdelningssystem har varje användare tillgång till systemet via terminalanordningen. Istället för att skicka jobb som är schemalagda för senare exekvering, anger användaren kommandon som bearbetas omedelbart.
   2. Därför kallas detta för "interaktiv bearbetning". Det gör det möjligt för användaren att interagera direkt med datorn.
   3. Tidsdelningsbearbetning är känd som "Förgrundsbearbetning" och batchjobbbearbetning är känd som "Bakgrundsbearbetning".
5. Spooling
   1. SPOOLing står för Samtidig Perifer Operationer online.
   2. SPOOL-enhet används för att lagra utdata från program/applikation. Den spoolade utmatningen riktas till utdataenheter som en skrivare (om det behövs).
   3. Det är en anläggning som utnyttjar fördelen med buffring för att effektivt använda utgångsenheterna.

Klassificering av manuell testning i stordatorer

stordator Manuell testning kan delas in i två typer:

1. Batch Job Testing -

• Testprocessen involverar körningar av batchjobb för den funktionalitet som implementeras i den aktuella versionen.
• Testresultatet som extraheras från utdatafilerna och databasen verifieras och registreras.

2. Onlinetestning -

• Onlinetestning avser testning av CICS-skärmar som liknar testning av webbsidan.
• Funktionaliteten på de befintliga skärmarna kan ändras eller nya skärmar kan läggas till.
• Olika applikationer kan ha förfrågningsskärmar och uppdateringsskärmar. Funktionaliteten hos dessa skärmar måste kontrolleras som en del av onlinetestningen.

Hur man gör stordatortestning

1. Affärsteamet förbereder kravdokument. Vilket bestämmer hur ett visst objekt eller en viss process kommer att ändras i releasecykeln.
2. 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. Vanligtvis, i en release, påverkas endast 20-25 % av applikationen direkt av det anpassade kravet. De övriga 75 % av utgåvan kommer att vara för out-box-funktioner som att testa applikationer och processer.
3. Så en stordatorapplikation måste testas i två delar:
   1. Testkrav – Testa applikationen för funktionaliteten eller ändringen som nämns i kravdokumentet.
   2. Testa integration – Testa 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.

Testverktyg för stordatorautomation

Nedan är listan över verktyg som kan användas för stordatorer Automationstestning.

• REXX
• excel
• QTP

Metodik i stordatortestning

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 tar det två tillvägagångssätt för stordatortestning, onlinetestning och batchtestning.

• Testning online görs på medlemsregistreringsskärmen. Precis som en webbsida valideras databasen med data som matas in via skärmarna.
• Offlineregistrering kan vara pappersregistrering eller registrering på en tredje parts webbplats. Offlinedata (även kallad batch) kommer att matas in i företagets databas genom batchjobb. En platt inmatningsfil förbereds enligt det föreskrivna dataformatet och matas till sekvensen av batchjobb. Så för testning av stordatorapplikationer kan vi använda följande tillvägagångssätt.
• Det första jobbet i raden av batchjobb validerar de angivna uppgifterna. Låt oss t.ex. säga specialtecken, alfabet i fält med endast nummer, etc.
• Det andra jobbet validerar konsistensen av data baserat på affärsförhållanden. 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 modifierar data i det format som kan matas in i databasen. Till exempel, radering av planens namn (databasen lagrar endast plan-ID och försäkringsplanens namn), tilläggsdatum för inträde, etc.
• Det fjärde jobbet laddar data till databasen.
• Batchjobbtestning görs på denna process i två faser -
• Varje jobb valideras separat, och
• Integration mellan jobben valideras genom att tillhandahålla platt indatafil till det första jobbet och validera databasen. (Intermediära resultat måste valideras för extra försiktighet)

Följande är metoden som följs för stordatortestning:

Steg 1) Shakedown/Rökprovning

Huvudfokus i detta skede är att validera om koden som distribueras är i rätt testmiljö. Det säkerställer också att det inte finns några kritiska problem med koden.

Steg 2) Kravhantering

Nedan finns de typer av tester som görs som en del av Systemtestning.

1. Batchtestning – Denna testning kommer att göras genom att validera testresultaten på utdatafiler och dataändringar som gjorts av batchjobben under testomfång och registrering av dem.
2. Onlinetestning – Denna testning kommer att göras på framsidan av stordatorapplikationen. Här testas applikationen för korrekt inmatningsfält som en försäkringsplan, ränta på planen etc.
3. Online-batch-integrationstestning – Denna testning kommer att göras på de system som har batchprocesser och onlineapplikation. Dataflödet och interaktionen mellan onlineskärmarna och batchjobben valideras.

   (Exempel för denna typ av testning – Överväg en uppdatering av plandetaljer som höjning av räntan. Ändringen av räntan görs på en uppdateringsskärm, och saldodetaljerna på de berörda kontona kommer endast att ändras av ett nattligt batchjobb. Testning i detta fall kommer att göras genom att validera skärmen Plandetaljer och batchjobbet körs för uppdatering av alla konton).

4. Databastestning – Databaserna där data från stordatorapplikationen (IMS, IDMS, DB2, VSAM/ISAM, Sequential datasets, GDGs) valideras för sin layout och datalagring.

Steg 3) Systemkrav Integrationstestning

Det primära syftet med denna testning är att validera funktionaliteten hos systemen som interagerar med systemet som testas.

Dessa system påverkas inte direkt av kraven. Däremot använder de data från systemet som testas. Det är viktigt att testa gränssnittet och olika typer av meddelanden (som Job Successful, Job Failed, Database updated, etc.) som eventuellt kan flyta mellan systemen och de resulterande åtgärder som vidtas av de individuella systemen.

Typer av tester som görs i detta skede är

1. Batchtestning
2. Onlinetestning
3. Online – Batchintegrationstestning

Steg 4) Regressionstestning

Regressionstestning är en vanlig fas i alla typer av testprojekt. Denna testning i stordatorer säkerställer att batchjobb och onlineskä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å effektiv regressionstestning bör en särskild uppsättning testfall väljas ut beroende på deras komplexitet och en regressionsbädd (Testfallsförråd) bör skapas. Denna uppsättning bör uppdateras när det finns en ny funktionalitet som rullas ut i versionen.

Steg 5) Prestandatester

Denna testning görs för att identifiera flaskhalsar i områden med hög träff som frontenddata, uppgradering av onlinedatabaser och för att projicera skalbarheten av applikationen.

Steg 6) Säkerhetstestning

Denna testning görs för att utvärdera hur väl applikationen är designad och utvecklad för att motverka anti-säkerhetsattacker.

Tvåfaldiga säkerhetstester bör göras på systemet – stordatorsäkerhet och nätverkssäkerhet.

Funktionerna som behöver testas är

1. Integrity
2. Sekretess
3. Tillstånd
4. Autentisering
5. Tillgänglighet

Steg involverade i batchtestning

1. Efter att QA-teamet har tagit emot det godkända paketet (paketet innehåller procedurer, JCL, kontrollkort, moduler, etc.), bör testaren förhandsgranska och hämta innehållet till PDS efter behov.
2. Konvertera produktions-JCL eller Development JCL till QA JCL, annars kallad JOB SETUP.
3. Kopiera produktionsfil och förbereda testfiler.
4. För varje funktion kommer det att finnas en jobbsekvens definierad. (Som förklarat i exemplet i avsnittet Metodik i stordatorer). Jobben ska skickas med kommandot SUB med testdatafilerna.
5. Kontrollera den mellanliggande filen för att identifiera orsakerna till att data saknas eller misslyckas.
6. Kontrollera den slutliga utdatafilen, databasen och spoolen för att validera testresultaten.
7. Om jobbet misslyckas kommer spolen att ha orsaken till jobbet misslyckande. Åtgärda felet och skicka in jobbet igen.

Testrapportering – defekt ska loggas om det faktiska resultatet avviker från förväntat.

Steg involverade i onlinetestning

1. Välj onlineskärmen i en testmiljö.
2. Testa varje fält för acceptabel data.
3. Testa Testscenario på skärmen.
4. Verifiera databasen för datauppdateringar från onlineskärmen.

Testrapportering – Fel ska loggas om det faktiska resultatet avviker från förväntat.

Steg involverade i online – batchintegrationstestning

1. Kör jobbet i en Testmiljö och validera data på onlineskärmarna.
2. Uppdatera data på onlineskärmarna och verifiera om batchjobbet körs korrekt med uppdaterade data.

Kommandon som används i stordatortestning

1. SUBMIT – Skicka in ett bakgrundsjobb.
2. CANCEL – Avbryt bakgrundsjobb.
3. ALLOCATE – Tilldela en datauppsättning
4. COPY – Kopiera en datauppsättning
5. RENAME – Byt namn på datauppsättning
6. DELETE – Ta bort datamängd
7. JOBBSCANNING – För att binda JCL med 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 stordatortestning

Grundläggande detaljer som behövs för stordatortestning är:

• Inloggnings-ID och lösenord för att logga in i applikationen.
• Kort kunskap om ISPF-kommandon.
• Namn på filerna, filnamn och deras typer.

Innan du börjar testa stordatorer bör nedanstående aspekter verifieras.

1. Jobb
   1. Gör en jobbskanning (Kommando – JOBSCAN) för att leta efter fel innan du kör den.
   2. CLASS-parametern ska pekas på testklassen.
   3. Rikta jobbutmatningen till spool eller en JHS eller efter behov genom att använda parametern MSGCLASS.
   4. Omdirigera e-postmeddelandet i jobbet för att spoola eller ett testpost-ID.
   5. Kommentera FTP-stegen för inledande testning och peka sedan jobbet till en testserver.
   6. Om en IMR (Incident Management-post) genereras i jobbet, lägg bara till kommentaren "TESTNINGSSYFTE" i jobbet eller paramkortet.
   7. Alla produktionsbibliotek i jobbet bör ändras och peka på testbibliotek.
   8. Jobbet ska inte lämnas obevakat.
   9. För att förhindra att jobbet körs i en oändlig slinga i fall av fel, bör TIME-parametern läggas till med angiven tid.
   10. Spara resultatet av jobbet inklusive spolen. Spolen kan sparas med XDC.

2. Fil
   1. Skapa endast en testfil av önskad storlek. Använd GDGs (Generation Data Groups – Filer med samma namn men med sekventiella versionsnummer – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 så vidare ) när det behövs för att lagra data i på varandra följande filer med samma namn.
   2. Parametern DISP (Disposition – beskriver systemet för att bevara eller ta bort datamängden efter normal eller onormal avslutning av steget eller jobbet) för filerna bör kodas korrekt.
   3. Se till att alla filer som används för jobbkörning sparas och stängs ordentligt för att förhindra att jobbet hamnar i HOLD.
   4. När du testar med GDG:er se till att rätt version pekas på.
3. Databas
   1. När du kör jobbet eller onlineprogrammet, se till att oavsiktlig data inte infogas, uppdateras eller raderas.
   2. Se också till att rätt DB2-region används för testning.
4. Testfall
   1. Testa alltid för gränsvillkor som – Tom fil, Första postbearbetning, Sista postbearbetning, etc.
   2. Inkludera alltid både positiva och negativa testförhållanden.
   3. Om standardprocedurer används i programmet som Checkpoint-omstart, Abend Modules, Control-filer, etc. inkluderar testfall för att validera om modulerna har använts korrekt.
5. Testdata
   1. Inställning av testdata bör göras före början av testningen.
   2. Ändra aldrig data på testområdet utan att meddela detta. Det kan finnas andra team som arbetar med samma data, och deras test skulle misslyckas.
   3. Om produktionsfilerna behövs under exekveringen bör lämplig auktorisering erhållas innan du kopierar eller använder dem.

Best Practices

1. Om ett batchjobb körs är MAX CC 0 en indikator på att jobbet har körts framgångsrikt. Det betyder inte att funktionen fungerar bra. Jobbet kommer att köras framgångsrikt även när utgången är tom eller inte enligt förväntningarna. Så det förväntas alltid att kontrollera alla utdata innan du förklarar jobbet framgångsrikt.
2. Det är alltid bra att göra en torrkörning av jobbet som testas. Torrkörning görs med tomma inmatningsfiler. Denna process bör följas för de jobb som påverkas av ändringarna som gjorts för testcykeln.
3. Innan testcykeln börjar bör testjobbet göras i god tid i förväg. Detta kommer att hjälpa till att ta reda på eventuella JCL-fel i förväg, vilket sparar tid under körningen.
4. När du använder DB2-tabeller via SPUFI (alternativ på emulatorn för åtkomst till DB2-tabeller), ställ alltid in auto commit som "NEJ" för att undvika oavsiktliga uppdateringar.
5. Testdatatillgänglighet är den primära utmaningen vid batchtestning. Nödvändiga data bör skapas i god tid före testcykeln och bör kontrolleras för fullständighet.
6. Vissa onlinetransaktioner och batchjobb kan skriva data till MQ:er (meddelandekö) för att överföra data till andra applikationer. Om data inte är giltiga kan det inaktivera/stoppa MQs, detta kommer att påverka hela testprocessen. Det är en god praxis att kontrollera att MQ:er fungerar bra efter testning.

Stordatortestning Utmaningar och felsökning

Utmaningar	Tillvägagångssätt
Ofullständiga/otydliga krav Det kan finnas tillgång till användarmanual/utbildningsguide, men de är inte samma som dokumenterade krav.	Testare bör vara involverade i SDLC från kravfasen och framåt. Detta hjälper till att verifiera om kraven är testbara.
Datainställning/identifikation Det kan finnas situationer där befintlig data ska återanvändas enligt kravet. Det är ibland svårt att identifiera de data som krävs utifrån befintliga data.	För datainställning kan hemmagjorda verktyg användas efter behov. För att hämta befintlig data bör frågor skapas i förväg. I händelse av problem kan en begäran ställas till datahanteringsteamet för att skapa eller klona nödvändig data.
Jobbinställningar 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ägsdetalj.	Jobbinställningsverktyg 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 slut-till-änd-testning behöver stödjas på grund av problem i uppströms- eller nedströmsapplikationsproblem. 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 omfattningsändring Det kan finnas en situation där kodpåverkan helt kan förändra systemets utseende och känsla. Detta kan kräva en ändring av testfall, skript och data.	Omfattning förändringshanteringsprocess och konsekvensanalys bör finnas på plats.

Vanliga Abends påträffade

1. S001 – Ett I/O-fel inträffade.

   Orsak – Läsning i slutet av filen, fillängdsfel, försök att skriva till en skrivskyddad fil.

2. S002 – Ogiltig I/O-post.

   Orsak – Försök att skriva en post som är längre än postens längd.

3. S004 – Fel uppstod under OPEN.

   Orsak – Ogiltig DCB

4. S013 – Fel vid öppning av en datauppsättning.

   Orsak – PDS-medlem finns inte, skivlängden i programmet matchar inte den faktiska skivlängden.

5. S0C1 – Operation Undantag

   Orsak – Det går inte att öppna filen, DD-kort saknas

6. S0C4 – Skyddsundantag/ Lagringsbrott
7. Orsak – Försöker få tillgång till lagringsutrymme som inte är tillgängligt för programmet.
8. S0C7 – Programkontrollundantag – Data
9. Orsak – Ändring av postlayout eller fillayout.
10. Sx22 – Jobbet har avbrutits
11. S222 – Jobb avbröts av användaren utan dumpning.
12. S322 – Jobb- eller Stegtiden överskred den specificerade gränsen, eller så är programmet i en loop eller otillräcklig tidsparameter.
13. S522 – TSO-session timeout.
14. S806 – Det går inte att länka eller ladda.

    Orsak – Jobb-ID kan inte hitta den angivna lastmodulen.

15. S80A – Inte tillräckligt med virtuellt lagringsutrymme för att tillfredsställa GETMAIN- eller FREEMAIN-förfrågningar.
16. S913 – Försöker komma åt datamängden som användaren inte är auktoriserad.
17. Sx37 – Det går inte att allokera tillräckligt med lagringsutrymme till datamängden.

Error Assist – Ett mycket populärt verktyg för att få detaljerad information om olika typer av abends.

Vanligt problem under stordatortestning

• Job Abends – För framgångsrikt slutförande av jobbet bör du kontrollera data, indatafil och moduler som finns på den specifika platsen eller inte. Avvikelser kan uppstå på grund av flera orsaker, den vanligaste är - Ogiltig data, felaktigt inmatningsfält, datumfel, miljöproblem, etc.
• Utdatafil tom– Även om jobbet kan köras framgångsrikt (MaxCC 0), kanske resultatet inte blir som förväntat. Så innan testaren klarar något testfall måste testaren se till att utgången är korsverifierad. Först sedan gå 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 data korsverifieras för att undvika omkörning och omarbetning.

Sammanfattning

• Stordatortestning är som vilken annan testprocedur som helst med början från kravinsamling, testdesign, testutförande 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 stordatortestfunktioner. Som skärmnavigering, skapande av filer och PDS, spara testresultat, etc. innan testcykeln börjar.
• Testning av stordatorapplikationer är en tidskrävande process. Ett tydligt testschema bör följas för testdesign, datainställning och utförande.
• Batchtestning och onlinetestning bör göras effektivt utan att missa någon funktionalitet som nämns i kravdokumentet, och Testfall bör skonas.