Testování sálových počítačů – kompletní návod

Od: Thomas Hamilton Thomas Hamilton
Hours aktualizováno

Než se naučíte koncepty testování sálových počítačů, pojďme se učit

Co je to sálový počítač?

Sálový počítač je vysoce výkonný a vysokorychlostní počítačový systém. Používá se pro výpočetní účely ve větším měřítku, které vyžadují vysokou dostupnost a zabezpečení. Většinou se používá v odvětvích, jako je finance, pojišťovnictví, maloobchod a další kritické oblasti, kde se obrovská data zpracovávají vícekrát.

Testování sálových počítačů

Testování sálových počítačů je proces testování softwarových aplikací a služeb založených na sálových systémech. Účelem testování sálových počítačů je zajistit výkon, spolehlivost a kvalitu softwarové aplikace nebo služby metodami ověřování a validace a zkontrolovat, zda je připravena k nasazení.

Při provádění testování sálového počítače potřebuje tester vědět pouze o navigacích obrazovek CICS. Jsou vyrobeny na zakázku pro konkrétní aplikace. Jakékoli změny kódu provedené v testeru COBOL, JCL atd. se nemusí starat o nastavení emulátoru na stroji. Změny, které fungují na jednom emulátoru terminálu, budou fungovat i na ostatních.

  • Aplikace Mainframe (jinak nazývaná dávka úloh) je testována proti testovacím případům vyvinutým pomocí požadavků
  • Testování sálových počítačů se obvykle provádí na nasazeném kódu pomocí různých kombinací dat nastavených ve vstupním souboru.
  • K aplikacím, které běží na sálovém počítači, lze přistupovat prostřednictvím emulátoru terminálu. Emulátor je jediný software, který je třeba nainstalovat na klientský počítač.

Atributy sálového počítače

  1. Virtuální úložiště
    1. Je to technika, která umožňuje procesoru simulovat hlavní úložiště, které je větší než skutečné množství skutečného úložiště.
    2. Je to technika, jak efektivně využívat paměť k ukládání a provádění úloh různé velikosti.
    3. Využívá diskové úložiště jako rozšíření skutečného úložiště.
  2. Multiprogramování
    1. Počítač spouští více než jeden program současně. Ale v každém okamžiku může mít kontrolu nad CPU pouze jeden program.
    2. Je to zařízení, které umožňuje efektivní využití CPU.
  3. Dávkové zpracování
    1. Je to technika, pomocí které se provádí jakýkoli úkol v jednotkách známých jako úlohy.
    2. Úloha může způsobit spuštění jednoho nebo více programů v sekvenci.
    3. Plánovač úloh rozhoduje o pořadí, ve kterém by se měly úlohy provádět. Pro maximalizaci průměrné propustnosti jsou úlohy plánovány podle jejich priority a třídy.
    4. Potřebné informace pro dávkové zpracování poskytuje JCL (JOB CONTROL LANGUAGE). JCL popisuje dávkovou úlohu – potřebné programy, data a zdroje.
  4. Sdílení času
    1. V systému sdílení času má každý uživatel přístup do systému prostřednictvím koncového zařízení. Místo odesílání úloh, které jsou naplánovány k pozdějšímu provedení, uživatel zadává příkazy, které jsou zpracovány okamžitě.
    2. Proto se tomu říká „interaktivní zpracování“. Umožňuje uživateli přímou interakci s počítačem.
    3. Časově sdílené zpracování je známé jako „zpracování popředí“ a dávkové zpracování úlohy je známé jako „zpracování na pozadí“.
  5. Navíjení
    1. Spooling znamená Simultánní periferie Operaonline.
    2. Zařízení SPOOL se používá k uložení výstupu programu/aplikace. Výstup pro souběžný tisk je směrován na výstupní zařízení, jako je tiskárna (je-li potřeba).
    3. Je to zařízení využívající výhody ukládání do vyrovnávací paměti k efektivnímu využití výstupních zařízení.

Klasifikace ručního testování v sálových počítačích

mainframe Ruční testování lze rozdělit do dvou typů:

1. Dávkové testování úlohy -

  • Proces testování zahrnuje provádění dávkových úloh pro funkcionalitu implementovanou v aktuální verzi.
  • Výsledek testu extrahovaný z výstupních souborů a databáze je ověřen a zaznamenán.

2. Online testování -

  • Online testování označuje testování obrazovek CICS, které je podobné testování webové stránky.
  • Funkčnost stávajících obrazovek by mohla být změněna nebo mohou být přidány nové obrazovky.
  • Různé aplikace mohou mít obrazovky dotazů a obrazovky aktualizací. Funkčnost těchto obrazovek je potřeba zkontrolovat v rámci online testování.

Jak provést testování sálového počítače

  1. Obchodní tým připravuje dokumenty požadavků. Což určuje, jak bude konkrétní položka nebo proces upraven v cyklu vydání.
  2. Testovací tým a vývojáři obdrží dokument požadavků. Zjistí, kolik procesů bude změna ovlivněna. Ve verzi je obvykle přizpůsobeným požadavkem přímo ovlivněno pouze 20–25 % aplikace. Zbývajících 75 % vydání bude určeno pro funkce out-box, jako je testování aplikací a procesů.
  3. Takže mainframe aplikace musí být testována ve dvou částech:
    1. Požadavky na testování – Testování funkčnosti aplikace nebo změny uvedené v dokumentu požadavků.
    2. Testování integrace – Testování celého procesu nebo jiné aplikace, která přijímá nebo odesílá data do postižené aplikace. Regresní testování je primárním cílem této testovací činnosti.

SOUVISEJÍCÍ ČLÁNKY

Nástroje pro testování automatizace sálových počítačů

Níže je uveden seznam nástrojů, které lze použít pro sálové počítače Testování automatizace.

  • REXX
  • vynikat
  • QTP

Metodologie testování sálových počítačů

Uvažujme příklad: Pojišťovna XYZ má modul pro zápis členů. Přebírá data z obrazovky registrace členů i offline registrace. Jak jsme uvedli dříve, pro testování sálových počítačů, online testování a dávkové testování jsou zapotřebí dva přístupy.

  • Online testování se provádí na obrazovce registrace členů. Stejně jako webová stránka je databáze ověřována údaji zadanými přes obrazovky.
  • Offline registrace může být papírová registrace nebo registrace na webových stránkách třetí strany. Offline data (také označovaná jako dávka) budou vložena do firemní databáze prostřednictvím dávkových úloh. Vstupní plochý soubor je připraven podle předepsaného formátu dat a přiváděn do sekvence dávkových úloh. Takže pro testování aplikací na sálových počítačích můžeme použít následující přístup.
  • První úloha v řadě dávkových úloh ověřuje zadaná data. Řekněme například speciální znak, abecedy v číselných polích atd.
  • Druhá úloha ověřuje konzistenci dat na základě obchodních podmínek. Dětská registrace by například neměla obsahovat závislá data, PSČ člena (které není k dispozici pro službu v rámci registrovaného plánu) atd.
  • Třetí úloha upravuje data ve formátu, který lze zadat do databáze. Například odstranění názvu plánu (databáze bude ukládat pouze ID plánu a název pojistného plánu), připojení data vstupu atd.
  • Čtvrtá úloha načte data do databáze.
  • Dávkové testování úloh Tento proces probíhá ve dvou fázích –
  • Každá úloha je ověřována samostatně a
  • Integrace mezi úlohami je ověřena poskytnutím vstupního plochého souboru první úloze a ověřením databáze. (Průběžné výsledky musí být kvůli zvýšené opatrnosti ověřeny)

Při testování sálového počítače se používá následující metoda:

Krok 1) Shakedown/Testování kouře

Hlavním cílem v této fázi je ověřit, zda je nasazený kód ve správném testovacím prostředí. Také zajišťuje, že neexistují žádné kritické problémy s kódem.

Krok 2) Testování systému

Níže jsou uvedeny typy testování prováděné v rámci testování systému.

  1. Dávkové testování – Toto testování bude provedeno ověřením výsledků testů na výstupních souborech a změn dat provedených dávkovými úlohami v rozsahu testování a jejich zaznamenáním.
  2. Online testování – Toto testování bude provedeno na předním konci aplikace pro sálový počítač. Zde je aplikace testována na správné vstupní pole, jako je pojistný plán, úrok z plánu atd.
  3. Testování online dávkové integrace – Toto testování bude provedeno na systémech s dávkovými procesy a online aplikací. Ověřuje se datový tok a interakce mezi online obrazovkami a dávkovými úlohami.

    (Příklad pro tento typ testování – Zvažte aktualizaci podrobností plánu, jako je zvýšení úrokové sazby. Změna úroku se provádí na obrazovce aktualizace a podrobnosti zůstatku na dotčených účtech budou upraveny pouze noční dávkovou úlohou. Testování v tomto případě bude provedeno ověřením obrazovky Podrobnosti plánu a spuštěním dávkové úlohy pro aktualizaci všech účtů).

  4. Testování databáze – Databáze, kde jsou data z mainframové aplikace (IMS, IDMS, DB2, VSAM/ISAM, sekvenční datové sady, GDG) ověřována z hlediska jejich rozložení a uložení dat.

Krok 3) Systém Testování integrace

Primárním účelem tohoto testování je ověřit funkčnost systémů, které jsou v interakci s testovaným systémem.

Tyto systémy nejsou požadavky přímo ovlivněny. Používají však data z testovaného systému. Důležité je otestovat rozhraní a různé typy zpráv (jako Úloha úspěšná, Úloha se nezdařila, Databáze aktualizována atd.), které mohou případně proudit mezi systémy a z toho vyplývající akce jednotlivých systémů.

Typy testování prováděné v této fázi jsou

  1. Dávkové testování
  2. Online testování
  3. Online – dávkové testování integrace

Krok 4) Regresní testování

Regresní testování je běžnou fází v jakémkoli typu testovacího projektu. Toto testování na sálových počítačích zajišťuje, že dávkové úlohy a online obrazovky, které přímo neinteragují s testovaným systémem (nebo nespadají do rozsahu požadavků), nejsou aktuální verzí projektu ovlivněny.

Aby bylo regresní testování účinné, měla by být konkrétní sada testovacích případů zařazena do užšího výběru v závislosti na jejich složitosti a mělo by být vytvořeno regresní lůžko (úložiště testovacích případů). Tato sada by měla být aktualizována vždy, když je do vydání zavedena nová funkce.

Krok 5) Testování výkonu

Toto testování se provádí s cílem identifikovat úzká místa v oblastech s vysokým výskytem, ​​jako jsou data frontend, upgradovat online databáze a promítnout škálovatelnost aplikace.

Krok 6) Testování bezpečnosti

Toto testování se provádí za účelem vyhodnocení toho, jak dobře je aplikace navržena a vyvinuta tak, aby čelila útokům proti zabezpečení.

Na systému by měly být provedeny dva testy zabezpečení – zabezpečení sálového počítače a zabezpečení sítě.

Vlastnosti, které je třeba testovat, jsou

  1. Integrity
  2. Důvěrnost
  3. Povolení
  4. Ověřování
  5. dostupnost

Kroky zahrnuté v dávkovém testování

  1. Poté, co tým QA obdrží schválený balíček (balíček obsahuje procedury, JCL, kontrolní karty, moduly atd.), by si měl tester prohlédnout a načíst obsah do PDS podle potřeby.
  2. Převeďte produkční JCL nebo Development JCL na QA JCL jinak nazývané JOB SETUP.
  3. Kopírování produkčního souboru a příprava testovacích souborů.
  4. Pro každou funkci bude definována pracovní sekvence. (Jak je vysvětleno v příkladu v části Metodika v části Mainframe). Úlohy by měly být odeslány pomocí příkazu SUB se soubory testovacích dat.
  5. Zkontrolujte přechodný soubor, abyste zjistili důvody chybějících nebo chybných dat.
  6. Zkontrolujte konečný výstupní soubor, databázi a cívku, abyste ověřili výsledky testu.
  7. Pokud úloha selže, zařazování bude mít důvod selhání úlohy. Opravte chybu a odešlete úlohu znovu.

Testovací reporty – Přeběhnout měl by být zaznamenán, pokud se skutečný výsledek liší od očekávaného.

Kroky zahrnuté v online testování

  1. Vyberte obrazovku Online v testovacím prostředí.
  2. Otestujte každé pole na přijatelná data.
  3. Otestujte Scénář testu na obrazovce.
  4. Ověřte databázi pro aktualizace dat z online obrazovky.

Hlášení o testu – Defekt by měl být zaznamenán, pokud se skutečný výsledek liší od očekávaného.

Kroky zapojené do testování online – dávkové integrace

  1. Spusťte úlohu v a Testovací prostředí a ověřte data na online obrazovkách.
  2. Aktualizujte data na online obrazovkách a ověřte, zda je dávková úloha správně spuštěna s aktualizovanými daty.

Příkazy používané při testování sálových počítačů

  1. ODESLAT – Odešlete úlohu na pozadí.
  2. CANCEL – Zrušení úlohy na pozadí.
  3. ALLOCATE – Přidělení datové sady
  4. COPY – Kopírování datové sady
  5. RENAME – Přejmenování datové sady
  6. DELETE – Odstranit datovou sadu
  7. JOB SCAN – Spojení JCL s programem, knihovnami, souborem atd. bez jeho provedení.

V případě potřeby se používá mnoho dalších příkazů, ale nejsou tak časté.

Předpoklady pro zahájení testování sálových počítačů

Základní podrobnosti potřebné pro testování sálového počítače jsou:

  • Přihlašovací ID a heslo pro přihlášení do aplikace.
  • Stručná znalost příkazů ISPF.
  • Názvy souborů, kvalifikátor souborů a jejich typy.

Před zahájením testování sálového počítače by měly být ověřeny níže uvedené aspekty.

  1. Práce
    1. Proveďte skenování úlohy (Command – JOBSCAN), abyste před jejím provedením zkontrolovali chyby.
    2. Parametr CLASS by měl směřovat na třídu testu.
    3. Nasměrujte výstup úlohy do cívky nebo JHS nebo podle potřeby pomocí parametru MSGCLASS.
    4. Přesměrujte e-mail v úloze do zařazování nebo na ID testovací pošty.
    5. Zakomentujte kroky FTP pro počáteční testování a poté nasměrujte úlohu na testovací server.
    6. V případě, že je v zakázce vygenerován záznam IMR (Incident Management), stačí na kartu zakázky nebo param přidat komentář „ÚČEL TESTOVÁNÍ“.
    7. Všechny produkční knihovny v úloze by měly být změněny a nasměrovány na testovací knihovny.
    8. Práce by neměla zůstat bez dozoru.
    9. Aby se zabránilo spuštění úlohy v nekonečné smyčce v případě jakékoli chyby, měl by být přidán parametr TIME se zadaným časem.
    10. Uložte výstup úlohy včetně cívky. Cívku lze uložit pomocí XDC.
  1. Soubor
    1. Vytvořte pouze testovací soubor potřebné velikosti. Použijte GDGs (Generation Data Groups – Soubory se stejným názvem, ale se sekvenčními čísly verzí – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 atd.), pokud je to nutné k ukládání dat do po sobě jdoucích souborů se stejným názvem.
    2. Parametr DISP (Disposition – popisuje systém, který má provést zachování nebo odstranění datové sady po normálním nebo abnormálním ukončení kroku nebo úlohy) pro soubory by měl být správně kódován.
    3. Zajistěte, aby byly všechny soubory použité pro provedení úlohy správně uloženy a uzavřeny, aby se úloha nedostala do stavu HOLD.
    4. Při testování pomocí GDG se ujistěte, že ukazujete na správnou verzi.
  2. Databáze
    1. Při provádění úlohy nebo online programu zajistěte, aby nebyla vložena, aktualizována nebo odstraněna nechtěná data.
    2. Také se ujistěte, že je pro testování použita správná oblast DB2.
  3. Testovací případy
    1. Vždy testujte okrajové podmínky, jako je – prázdný soubor, zpracování prvního záznamu, zpracování posledního záznamu atd.
    2. Vždy zahrňte pozitivní i negativní podmínky testu.
    3. V případě, že jsou v programu použity standardní postupy, jako je restart kontrolního bodu, moduly Abend, řídicí soubory atd., zahrňte testovací případy pro ověření, zda byly moduly použity správně.
  4. Testovací data
    1. Nastavení testovacích dat by mělo být provedeno před začátkem testování.
    2. Nikdy neupravujte data v testovací oblasti bez upozornění. Se stejnými daty mohou pracovat i jiné týmy a jejich test by selhal.
    3. V případě, že jsou produkční soubory potřebné během provádění, je třeba před jejich kopírováním nebo použitím získat řádné oprávnění.

Doporučené postupy

  1. V případě spuštění dávkové úlohy je MAX CC 0 indikátorem, že úloha proběhla úspěšně. Neznamená to, že funkce funguje dobře. Úloha poběží úspěšně, i když je výstup prázdný nebo není podle očekávání. Vždy se tedy očekává, že před prohlášením úlohy za úspěšnou zkontrolujete všechny výstupy.
  2. Vždy je dobrou praxí provést test nasucho. Suchý běh se provádí s prázdnými vstupními soubory. Tento proces by měl být dodržován u úloh, které jsou ovlivněny změnami provedenými pro testovací cyklus.
  3. Před zahájením testovacího cyklu by mělo být nastavení testovací úlohy provedeno s dostatečným předstihem. Pomůže vám to zjistit jakoukoli chybu JCL předem, čímž ušetříte čas při provádění.
  4. Při přístupu k tabulkám DB2 prostřednictvím SPUFI (volba na emulátoru pro přístup k tabulkám DB2) vždy nastavte automatické potvrzení na hodnotu „NE“, abyste předešli náhodným aktualizacím.
  5. Test Dostupnost dat je primární výzvou při dávkovém testování. Požadovaná data by měla být vytvořena v dostatečném předstihu před zkušebním cyklem a měla by být zkontrolována úplnost.
  6. Některé online transakce a dávkové úlohy mohou zapisovat data do MQ (fronta zpráv) pro přenos dat do jiných aplikací. Pokud data nejsou platná, může to deaktivovat/zastavit MQ, což ovlivní celý proces testování. Je dobrou praxí zkontrolovat, zda MQ po testování fungují správně.

Výzvy a odstraňování problémů při testování sálových počítačů

Výzvy Přístup
Neúplné / nejasné požadavky

Může existovat přístup k uživatelské příručce / školicí příručce, ale ty nejsou stejné jako dokumentované požadavky. 		Testeři by měli být zapojeni do SDLC od fáze požadavků dále. To pomůže ověřit, zda jsou požadavky testovatelné.
Nastavení dat/Identifikace

Mohou nastat situace, kdy by stávající data měla být znovu použita podle požadavku. Někdy je obtížné identifikovat požadovaná data z existujících dat. 		Pro nastavení dat lze podle potřeby použít domácí nástroje. Pro načítání existujících dat by měly být dotazy vytvořeny předem. V případě jakýchkoli potíží lze požádat tým správy dat o vytvoření nebo klonování požadovaných dat.
Nastavení úlohy

Jakmile jsou úlohy načteny do PDS, musí být úloha nastavena v oblasti QA. Aby se úlohy neodesílaly s produkčním kvalifikátorem nebo podrobnostmi o cestě. 		Nástroje pro nastavení úlohy by se měly používat tak, aby se předešlo lidským chybám, ke kterým dojde během nastavování.
Ad-hoc žádost

Mohou nastat situace, kdy je potřeba podpořit end-to-end testování kvůli problémům s upstream nebo downstream aplikací. Tyto požadavky zvyšují čas a úsilí v cyklu provádění. 		Použití automatizačních skriptů, regresních skriptů a základních skriptů může pomoci snížit režijní náklady a úsilí.
Včasná vydání pro změnu rozsahu

Může nastat situace, kdy dopad kódu může zcela změnit vzhled a dojem ze systému. To může vyžadovat změnu testovacích případů, skriptů a dat. 		Měl by být zaveden proces řízení změny rozsahu a analýza dopadů.

Běžný Abends

  1. S001 – Došlo k chybě I/O.

    Důvod – Čtení na konci souboru, chyba délky souboru, pokus o zápis do souboru pouze pro čtení.

  2. S002 – Neplatný I/O záznam.

    Důvod – Pokus zapsat záznam delší, než je délka záznamu.

  3. S004 – Během OPEN došlo k chybě.

    Důvod – Neplatné DCB

  4. S013 – Chyba při otevírání datové sady.

    Důvod – člen PDS neexistuje, délka záznamu v programu neodpovídá skutečné délce záznamu.

  5. S0C1 – OperaVýjimka

    Důvod – Nelze otevřít soubor, chybí DD karta

  6. S0C4 – Výjimka ochrany/Narušení úložiště
  7. Důvod – Pokus o přístup k úložišti, které program nemá k dispozici.
  8. S0C7 – Výjimka kontroly programu – Data
  9. Důvod – Změna rozložení záznamu nebo rozložení souboru.
  10. Sx22 – Úloha byla zrušena
  11. S222 – Úloha zrušena uživatelem bez výpisu.
  12. S322 – Čas úlohy nebo kroku překročil zadaný limit, nebo je program ve smyčce nebo nedostatečný časový parametr.
  13. S522 – časový limit relace TSO.
  14. S806 – Nelze propojit nebo načíst.

    Důvod – ID úlohy nemůže najít zadaný zaváděcí modul.

  15. S80A – Nedostatek virtuálního úložiště pro uspokojení požadavků GETMAIN nebo FREEMAIN.
  16. S913 – Pokus o přístup k datové sadě, ke které uživatel nemá oprávnění.
  17. Sx37 – Nelze přidělit dostatek úložiště datové sadě.

Error Assist – Velmi oblíbený nástroj pro získání podrobných informací o různých typech abendů.

Běžný problém při testování sálových počítačů

  • Job Abends – Pro úspěšné dokončení úlohy byste měli zkontrolovat data, vstupní soubor a moduly přítomné nebo nepřítomné na konkrétním místě. Abends může čelit z několika důvodů, z nichž nejčastější jsou – Neplatná data, Nesprávné vstupní pole, nesoulad data, problémy životního prostředí atd.
  • Výstupní soubor je prázdný– Přestože úloha může běžet úspěšně (MaxCC 0), výstup nemusí odpovídat očekávání. Před absolvováním jakéhokoli testovacího případu se tedy tester musí ujistit, že výstup je křížově ověřen. Teprve potom pokračujte dále.
  • Vstupní soubor je prázdný – V některých aplikacích budou soubory přijímány z nadřazených procesů. Před použitím přijatého souboru pro testování aktuální aplikace by měla být data křížově ověřena, aby se zabránilo opětovnému spuštění a přepracování.

Shrnutí

  • Testování sálových počítačů je jako každý jiný testovací postup počínaje shromážděním požadavků, návrhem testu, provedením testu a hlášením o výsledcích.
  • Aby bylo možné aplikaci efektivně otestovat, měl by se tester účastnit návrhových schůzek naplánovaných vývojovými a obchodními týmy.
  • Pro testera je povinné zvyknout si na různé testovací funkce sálového počítače. Jako navigace na obrazovce, vytváření souborů a PDS, ukládání výsledků testů atd. před začátkem testovacího cyklu.
  • Testování mainframových aplikací je časově náročný proces. Při návrhu testu, nastavení dat a provádění by měl být dodržován jasný plán testování.
  • Dávkové testování a online testování by mělo být prováděno efektivně, aniž by chyběla jakákoli funkce uvedená v dokumentu s požadavky a ne Testovací případ by měl být ušetřen.

Shrňte tento příspěvek takto: