Stordatortestning – komplett handledning

Innan vi lär oss koncepten för stordatortestning, låt oss först titta på plattformen som testerna körs på.

Vad är en stordator?

Stordatorn är ett högpresterande och snabbt datorsystem. Det används för storskalig databehandling som kräver hög tillgänglighet och stark säkerhet. Det används främst inom sektorer som finans, försäkring, detaljhandel och andra kritiska områden där stora datamängder behandlas många gånger om dagen.

Stordatortestning

Stordatortestning är en process för att testa programvaruapplikationer och tjänster baserade på stordatorsystem. Syftet med stordatortestning är att säkerställa prestanda, tillförlitlighet och kvalitet hos en programvaruapplikation eller tjänst genom verifierings- och valideringsmetoder, och att kontrollera om den är redo att driftsättas.

När testare utför stordatorer behöver de främst känna till navigeringen på CICS-skärmarna. Dessa skärmar är specialbyggda för specifika applikationer. När ändringar görs i koden i COBOL, JCL och liknande språk behöver de inte oroa sig för emulatorn som är konfigurerad på maskinen, eftersom ändringar som fungerar på en terminalemulator också fungerar på de andra.

• Stordatorapplikationen (även kallad jobbbatch) testas mot de testfall som utvecklats med hjälp av 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 en terminalemulator. Emulatorn är den enda programvaran som behöver installeras på klientmaskinen.

Eftersom plattformen beter sig annorlunda än en webbstack är det bra att veta vilka stordatoregenskaper som driver testdesignen. Stordatortestning ligger därför bredvid de andra. typer av mjukvarutestning snarare än att ersätta någon av dem.

Stordatorattribut

1. 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 minne för att lagra och utföra uppgifter i olika storlekar.
   • Den använder disklagring som en förlängning av verklig lagring.
2. Multiprogrammering
   • Datorn kör mer än ett program samtidigt. Men vid varje givet ögonblick kan bara ett program kontrollera processorn.
   • Det är en möjlighet att effektivt använda CPU:n.
3. Satsvis bearbetning
   • Det är en teknik genom vilken alla uppgifter utförs i enheter som kallas jobb.
   • Ett jobb kan orsaka att ett eller flera program körs i en sekvens.
   • 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.
   • Nödvändig information för batchbearbetning tillhandahålls via JCL (JOB CONTROL LANGUAGE). JCL beskriver batchjobbet – program, data och resurser som behövs.
4. Tidsdelning
   • 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.
   • Därför kallas detta för "interaktiv bearbetning". Det gör det möjligt för användaren att interagera direkt med datorn.
   • Tidsdelningsbearbetning är känd som "Förgrundsbearbetning" och batchjobbbearbetning är känd som "Bakgrundsbearbetning".
5. Spooling
   • SPOOLING står för Simultaneous Peripheral Operationer online.
   • En SPOOL-enhet används för att lagra utdata från ett program eller en applikation. Den buffade utdatan dirigeras till utdataenheter som en skrivare (om det behövs).
   • 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

Dessa attribut delar upp manuellt testarbete på stordatorn i två tydligt separerade strömmar.

stordator Manuell testning kan delas in i två typer:

1. Batchjobbtestning —

• Testprocessen innefattar körning av batchjobb för den funktionalitet som implementerats i den aktuella versionen.
• Testresultaten extracfrån utdatafilerna och databasen verifieras och registreras.

2. Onlinetestning —

• Onlinetestning avser testning av CICS-skärmar, vilket liknar testning av en webbsida.
• 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 som avgör hur en viss artikel eller process ska modifieras under lanseringscykeln.
2. Testteamet och utvecklingsteamet får kravdokumentet. De räknar ut hur många processer som kommer att påverkas av ändringen. Vanligtvis påverkas endast 20–25 % av applikationen direkt av det anpassade kravet i en release. De återstående 75–80 % av releasearbetet går till färdiga funktioner, såsom att testa omgivande applikationer och processer.
3. Så en stordatorapplikation måste testas i två delar:
   • Testkrav — Testa applikationen med avseende på funktionaliteten eller ändringen som nämns i kravdokumentet.
   • Testa integration — Testa hela processen eller andra applikationer 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 — skriptspråket som levereras med z/OS, som ofta används för att driva repetitiva jobbinlämningar och utdatakontroller.
• excel — används med makron för att bygga, jämföra och rapportera testdata och utdatafiler.
• OpenText UFT One — det nuvarande namnet på verktyget som branschen fortfarande kallar QTP eller QuickTest Professional; den automatiserar 3270 terminalskärmar.
• Galasa — en öppen källkod, Ramverk för djupintegrationstestning av Open Mainframe Project som driver 3270 skärmar, JCL-batchjobb och Db2 från en CI/CD-pipeline.
• Leverantörens z/OS-testsviter - IBM Testacceleratorn för Z och BMC AMI DevX Total Test täcker COBOL-enhetstestning och virtualiserade testmiljöer.

Oavsett vilket verktyg som väljs lönar det sig bara när det står i ett underhållet ramverk för testautomatisering snarare än en lös hög med manus.

Metodik i stordatortestning

Låt oss ta ett exempel: Ett försäkringsbolag i XYZ har en modul för medlemsregistrering. Den tar data både från medlemsregistreringsskärmen och från offline-registrering. Som diskuterats tidigare används två metoder för stordatortestning: onlinetestning och batchtestning.

• Onlinetestning görs på medlemsregistreringsskärmen. Precis som en webbsida valideras databasen med data som matas in via skärmarna.
• Offline-registrering kan vara pappersregistrering eller registrering på en tredjepartswebbplats. Offlinedata (även kallad batch) matas in i företagets databas via batchjobb. En platt indatafil förbereds enligt det föreskrivna dataformatet och matas in i sekvensen av batchjobb. Så för testning av stordatorapplikationer kan vi använda följande metod.
  • Det första jobbet i raden med batchjobb validerar de angivna uppgifterna – till exempel specialtecken eller alfabet i fält med endast siffror.
  • Det andra jobbet validerar datakonsistensen baserat på affärsförhållanden. Till exempel bör en underordnad registrering inte innehålla beroende data eller ett medlems postnummer som inte är tillgängligt för tjänsten av den registrerade planen.
  • Det tredje jobbet ändrar informationen till det format som kan matas in i databasen. Till exempel tar man bort plannamnet (databasen lagrar endast plan-ID och försäkringsplannamn), lägger till inmatningsdatum och liknande ändringar.
  • Det fjärde jobbet laddar data till databasen.
• Batchjobbtestning utförs på denna process i två faser —
  • Varje jobb valideras separat, och
  • Integrationen mellan jobben valideras genom att den inmatade flatfilen tillhandahålls till det första jobbet och valideringen av databasen sker. (Mellanresultat måste valideras av extra försiktighet.)

Följande är metoden som används för stordatortestning:

Steg 1) Skakning/Röktestning

Huvudfokus i detta steg är att validera om den distribuerade koden är i rätt testmiljö. Det säkerställer också att det inte finns några kritiska problem med koden. Detta är stordatorns motsvarighet till Rökprovning på någon annan plattform.

Steg 2) Kravhantering

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

1. Batchtestning — Denna testning görs genom att validera testresultaten på utdatafiler och de dataändringar som gjorts av batchjobben under testomfattningen, och registrera dem.
2. Onlinetestning — Denna testning utförs på stordatorapplikationens frontend. Här testas applikationen för korrekta inmatningsfält som en försäkringsplan, ränta på planen och liknande värden.
3. Online-batch-integrationstestning — Denna testning utförs på system som har både batchprocesser och en onlineapplikation. Dataflödet och interaktionen mellan onlineskärmarna och batchjobben valideras.

   (Exempel på den här typen av testning — Överväg en uppdatering av plandetaljer, till exempel en höjning av räntan. Ränteändringen görs på en uppdateringsskärm, och saldouppgifterna för de berörda kontona ändras endast av ett nattligt batchjobb. Testning görs i det här fallet genom att validera plandetaljernas skärm och batchjobbet körs för att uppdatera alla konton.)

4. Databastestning — De databaser där data från stordatorapplikationen lagras (IMS, IDMS, Db2, VSAM/ISAM, sekventiella datamängder, GDG:er) valideras för layout och datalagring.

Steg 3) System 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. De använder dock data från det testade systemet. Det är viktigt att testa gränssnitt och de olika typerna av meddelanden (som Jobbet lyckades, Jobbet misslyckades, Databasen uppdaterad) som kan flöda mellan systemen, och de resulterande åtgärder som vidtas av de enskilda 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 online-skärmar som inte direkt interagerar med systemet som testas (eller inte omfattas av kraven) inte påverkas av den aktuella projektversionen.

För att få effektiv regressionstestning bör en specifik uppsättning testfall utarbetas baserat på deras komplexitet och en regressionsbädd (testfallsförråd) bör skapas. Denna uppsättning bör uppdateras när ny funktionalitet rullas ut i versionen. Om regressionsbädden är för stor för att köras fullt ut, Riskbaserad testning används för att bestämma vilka jobb och skärmar som körs om först.

Steg 5) Prestandatester

Denna testning görs för att identifiera flaskhalsar inom områden med höga belastningar, som datainmatning i frontend och uppdateringar av databaser online, och för att bedöma applikationens skalbarhet. Långvariga batchfönster undersöks vanligtvis med Stresstestning mot toppvolymer.

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 utföras på systemet – stordatorsäkerhet och nätverkssäkerhet.

De funktioner 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 mottagit det godkända paketet (paketet innehåller procedurer, JCL, kontrollkort, moduler och liknande artiklar) ska testaren förhandsgranska och hämta innehållet i PDS efter behov.
2. Konvertera produktions-JCL:n eller utvecklings-JCL:n till QA-JCL, även kallad JOBBINSTÄLLNING.
3. Kopiera produktionsfilen och förbered testfilerna.
4. För varje funktionalitet kommer det att finnas en definierad jobbsekvens (som förklaras i exemplet i avsnittet Metodik i stordatortestning). Jobben ska skickas med SUB-kommandot tillsammans med testdatafilerna.
5. Kontrollera den mellanliggande filen för att identifiera orsakerna till saknade eller felaktiga data.
6. Kontrollera den slutliga utdatafilen, databasen och spolen 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 - A defekt bör loggas om det faktiska resultatet avviker från det förväntade resultatet.

Steg involverade i online-testning

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 — Ett fel bör registreras om det faktiska resultatet avviker från det förväntade resultatet.

Steg involverade i online — batchintegrationstestning

1. Kör jobbet i en testmiljö och validera data på onlineskärmarna.
2. Uppdatera informationen på onlineskärmarna och kontrollera om batchjobbet körs korrekt med uppdaterad information.

Kommandon som används i stordatortestning

Dessa steg styrs från terminalen, så ett litet kommandovokabulär täcker större delen av en testares dag.

1. SKICKA — Skicka in ett bakgrundsjobb.
2. ANNULLERA — Avbryt ett bakgrundsjobb.
3. FÖRDELA — Allokera en datauppsättning.
4. KOPIA — Kopiera en datauppsättning.
5. DÖPA OM — Byt namn på en datauppsättning.
6. RADERA — Ta bort en datauppsättning.
7. JOBBSKANNING — Binda JCL:n med programmet, biblioteken, filerna och andra resurser utan att köra den.

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.
• Kortfattad kunskap om ISPF-kommandon.
• Filnamn, filkvalificerare och deras typer.

Innan man påbörjar stordatortestning bör nedanstående aspekter verifieras.

1. Jobb
   • Gör en jobbsökning (kommando — JOBSCAN) för att kontrollera om det finns fel innan du kör den.
   • CLASS-parametern ska peka på testklassen.
   • Dirigera jobbutdata till spoolen eller en JHS, eller vid behov, med hjälp av parametern MSGCLASS.
   • Omdirigera e-postmeddelandet i jobbet till buffring eller till ett test-e-post-ID.
   • Kommentera FTP-stegen för initial testning och peka sedan jobbet till en testserver.
   • Om en IMR (Incident Management Record) genereras i jobbet, lägg till kommentaren "TESTSYFTE" i jobb- eller parameterkortet.
   • Alla produktionsbibliotek i jobbet bör ändras och peka på testbibliotek.
   • Jobbet ska inte lämnas obevakat.
   • För att förhindra att jobbet körs i en oändlig loop vid eventuella fel, bör parametern TIME läggas till med en angiven tid.
   • Spara resultatet av jobbet inklusive spolen. Spolen kan sparas med XDC.
2. Fil
   • Skapa endast en testfil med önskad storlek. Använd GDG:er (Generation Data Groups – filer med samma namn men med sekventiella versionsnummer, till exempel MYLIB.LIB.TEST.G0001V00 och MYLIB.LIB.TEST.G0002V00) vid behov för att lagra data i efterföljande filer med samma namn.
   • Parametern DISP (Disposition — anger för systemet om datasetet ska behållas eller tas bort efter normalt eller onormalt avslut av steget eller jobbet) för filerna ska vara korrekt kodad.
   • Se till att alla filer som används för jobbkörning sparas och stängs korrekt för att förhindra att jobbet hamnar i HOLD-läge.
   • När du testar med GDG:er, se till att rätt version pekas ut.
3. Databas
   • Se till att oavsiktlig data inte infogas, uppdateras eller raderas när du kör jobbet eller onlineprogrammet.
   • Se också till att rätt Db2-region används för testning.
4. Testfall
   • Testa alltid för randvillkor som en tom fil, första postbearbetning och sista postbearbetning.
   • Inkludera alltid både positiva och negativa testförhållanden.
   • Om standardprocedurer används i programmet, såsom omstart av kontrollpunkt, abend-moduler eller kontrollfiler, inkludera Testfallför att kontrollera om modulerna har använts korrekt.
5. Testdata
   • Inställning av testdata bör göras före början av testningen.
   • Ändra aldrig data i testområdet utan att meddela andra. Det kan finnas andra team som arbetar med samma data, och deras tester skulle misslyckas.
   • Om produktionsfilerna behövs under exekveringen bör lämplig auktorisering erhållas innan du kopierar eller använder dem.

Best Practices

1. Vid körning av ett batchjobb är MAX CC 0 en indikator på att jobbet har körts utan problem. Det betyder inte att funktionen fungerar som den ska. Jobbet kommer att köras utan problem även om utdata är tomt eller inte enligt förväntan. Därför förväntas det alltid att kontrollera alla utdata innan jobbet förklaras som lyckat.
2. Det är alltid en bra vana att testa jobbet som testas. En testkörning görs med tomma indatafiler. Denna process bör följas för de jobb som påverkas av de ändringar som gjorts under testcykeln.
3. Innan testcykeln börjar bör testjobbet konfigureras i god tid. Detta hjälper till att upptäcka eventuella JCL-fel i förväg, vilket sparar tid under körningen.
4. När du öppnar Db2-tabeller via SPUFI (ett alternativ i emulatorn för att komma åt Db2-tabeller), ställ alltid in auto commit till "NEJ" för att undvika oavsiktliga uppdateringar.
5. Tillgängligheten av testdata är den största utmaningen vid batchtestning. Nödvändiga data bör skapas i god tid före testcykeln och kontrolleras för fullständighet. Tracking den förberedelsen i en gemensam testhantering regressionsbädden och datauppsättningen är i linje.
6. Vissa onlinetransaktioner och batchjobb kan skriva data till MQ:er (meddelandeköer) för transmitöverföra data till andra applikationer. Om informationen inte är giltig kan det inaktivera eller stoppa MQ:erna, och detta kommer att påverka hela testprocessen. Det är god praxis att kontrollera att MQ:erna fungerar felfritt efter testning.

Utmaningar och felsökning av stordatortestning

Även med dessa metoder på plats återkommer några problem i nästan varje stordatorversion. Tabellen nedan parar ihop vart och ett av dem med den metod som löser det.

Utmaningar	Tillvägagångssätt
Ofullständiga/otydliga krav	Det kan finnas tillgång till en användarmanual eller utbildningsguide, men det är inte samma sak som dokumenterade krav. Testare bör vara involverade i livscykel för mjukvarutestning från kravfasen och framåt. Detta hjälper till att verifiera om kraven är testbara.
Datauppsättning / Identifiering	Det kan finnas situationer där befintlig data bör återanvändas enligt behov. Det är ibland svårt att identifiera nödvändig data från befintlig data. För datauppsättning kan egna verktyg användas efter behov. För att hämta befintlig data bör frågor skapas i förväg. Vid problem kan en begäran göras till datahanteringsteamet om att skapa eller klona nödvändig data.
Jobbinställningar	När jobben har hämtats till PDS måste jobbet konfigureras i QA-regionen, så att jobben inte skickas med en produktionskvalificerare eller sökvägsdetalj. Verktyg för jobbkonfiguration bör användas för att övervinna mänskliga fel som görs under konfigurationen.
Ad hoc-förfrågan	Det kan finnas situationer då testning från början till slut behöver stödjas på grund av ett problem i uppströms- eller nedströmsapplikationer. Dessa förfrågningar ökar tiden och ansträngningen i exekveringscykeln. Användning av automatiseringsskript, regressionsskript och skelettskript kan bidra till att minska tids- och ansträngningskostnaderna.
On-Time Releases för omfattningsändring	Det kan uppstå en situation där kodpåverkan helt förändrar systemets utseende och känsla. Detta kan kräva en ändring av testfall, skript och data. En process för hantering av omfattningsändringar och konsekvensanalys bör finnas på plats.

Vanliga uppkomna abends

När ett jobb misslyckas rapporterar spolen en abend-kod. Listan nedan täcker de koder som en stordatortestare stöter på oftast, tillsammans med den vanliga orsaken.

1. S001 — Ett I/O-fel uppstod.

   Orsak — Läser i slutet av filen, fillängdsfel eller ett försök att skriva till en skrivskyddad fil.

2. S002 — Ogiltig I/O-post.

   Orsak — Försökte skriva en post som är längre än postens längd.

3. S004 — Fel uppstod under ÖPPNING.

   Orsak — Ogiltig DCB.

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

   Orsak — PDS-medlemmen finns inte, eller så matchar postlängden i programmet inte den faktiska postlängden.

5. S0C1 - OperaUndantag.

   Orsak — Det går inte att öppna filen, eller så saknas DD-kort.

6. S0C4 — Skyddsundantag / lagringsöverträdelse.

   Orsak — Försöker komma åt lagringsutrymme som inte är tillgängligt för programmet.

7. S0C7 — Programkontrollundantag, data.

   Orsak — Ändring i postlayout eller fillayout.

8. Sx22 — Jobbet har avbrutits.

   Orsak — Jobbet avslutades innan det var klart; siffran i mitten identifierar vem eller vad som avbröt det.

9. S222 — Jobb avbrutet av användaren utan en dump.
10. S322 — Jobb- eller stegtiden har överskridit den angivna gränsen, eller programmet är i en loop, eller så är TIME-parametern otillräcklig.
11. S522 — Timeout för TSO-session.
12. S806 — Det gick inte att länka eller ladda.

    Orsak — Jobbet kan inte hitta den angivna laddningsmodulen.

13. S80A — Inte tillräckligt med virtuellt lagringsutrymme för att tillgodose GETMAIN- eller FREEMAIN-förfrågningar.
14. S913 — Försöker komma åt en datauppsättning som användaren inte har behörighet att använda.
15. Sx37 — Det gick inte att allokera tillräckligt med lagringsutrymme till datamängden.

Felhjälp — Ett mycket populärt verktyg för att få detaljerad information om olika typer av abends.

Vanliga problem som uppstår vid stordatortestning

• Job Abends — För att jobbet ska slutföras korrekt bör du kontrollera data, indatafilen och om modulerna finns på den specifika platsen. Avvikelser kan uppstå av flera anledningar, den vanligaste är ogiltiga data, ett felaktigt inmatningsfält, en datumavvikelse eller miljöproblem.
• Utdatafil tom — Även om jobbet kan köras utan problem (MaxCC 0), kanske utdata inte är som förväntat. Så innan testaren klarar ett testfall måste hen se till att utdata är korsverifierad. Först då bör testningen fortsätta.
• Inmatningsfilen tom — I vissa applikationer tas filer emot från uppströmsprocesser. Innan den mottagna filen används för att testa den aktuella applikationen bör data korsverifieras för att undvika omkörning och omarbetning.

Vanliga frågor