Testowanie komputerów mainframe — kompletny samouczek

Zanim zapoznamy się z koncepcją testowania komputerów mainframe, przyjrzyjmy się najpierw platformie, na której przeprowadzane są testy.

Co to jest komputer główny?

Komputer mainframe to wydajny i szybki system komputerowy. Jest wykorzystywany do obliczeń na dużą skalę, wymagających wysokiej dostępności i solidnego bezpieczeństwa. Znajduje zastosowanie głównie w sektorach takich jak finanse, ubezpieczenia, handel detaliczny i innych kluczowych obszarach, gdzie ogromne ilości danych są przetwarzane wielokrotnie dziennie.

Testowanie komputera głównego

Testowanie komputera głównego to proces testowania aplikacji i usług oprogramowania opartych na systemach mainframe. Celem testowania mainframe jest zapewnienie wydajności, niezawodności i jakości aplikacji lub usługi oprogramowania poprzez metody weryfikacji i walidacji oraz sprawdzenie, czy jest ona gotowa do wdrożenia.

Podczas testowania komputerów mainframe, tester musi przede wszystkim znać nawigację po ekranach CICS. Ekrany te są tworzone specjalnie dla konkretnych aplikacji. Wprowadzając zmiany w kodzie w językach COBOL, JCL i podobnych, tester nie musi martwić się o konfigurację emulatora na komputerze, ponieważ zmiany działające na jednym emulatorze terminala będą działać na pozostałych.

• Aplikacja mainframe (inaczej zwana pakietem zadań) jest testowana na podstawie przypadków testowych opracowanych na podstawie wymagań.
• Testowanie komputera mainframe zwykle przeprowadza się na wdrożonym kodzie, wykorzystując różne kombinacje danych zapisane w pliku wejściowym.
• Dostęp do aplikacji działających na komputerze mainframe można uzyskać za pośrednictwem emulatora terminala. Emulator to jedyne oprogramowanie, które należy zainstalować na komputerze klienckim.

Ponieważ platforma zachowuje się inaczej niż stos sieciowy, warto wiedzieć, które cechy komputera mainframe determinują projekt testów. Testowanie komputera mainframe jest zatem realizowane równolegle z innymi rodzaje testowania oprogramowania zamiast zastępować którykolwiek z nich.

Atrybuty komputera mainframe

1. Pamięć wirtualna
   • Jest to technika, która pozwala procesorowi symulować wielkość pamięci głównej, która jest większa niż rzeczywista ilość rzeczywistej pamięci.
   • Jest to technika efektywnego wykorzystania pamięci do przechowywania i wykonywania zadań o różnej wielkości.
   • Wykorzystuje pamięć dyskową jako rozszerzenie prawdziwej pamięci.
2. Wieloprogramowanie
   • Komputer wykonuje więcej niż jeden program jednocześnie. Jednak w danym momencie tylko jeden program może mieć kontrolę nad procesorem.
   • Jest to funkcja zapewniająca efektywne wykorzystanie procesora.
3. Przetwarzanie wsadowe
   • Jest to technika, dzięki której dowolne zadanie jest realizowane w jednostkach zwanych zadaniami.
   • Zadanie może powodować wykonanie jednego lub większej liczby programów w sekwencji.
   • Harmonogram zadań podejmuje decyzję o kolejności wykonywania zadań. Aby zmaksymalizować średnią przepustowość, zadania są planowane według ich priorytetu i klasy.
   • Niezbędne informacje do przetwarzania wsadowego są dostarczane za pośrednictwem JCL (JOB CONTROL LANGUAGE). JCL opisuje zadanie wsadowe — programy, dane i potrzebne zasoby.
4. Dzielenie czasu
   • W systemie podziału czasu każdy użytkownik ma dostęp do systemu za pośrednictwem urządzenia końcowego. Zamiast wysyłać zadania zaplanowane do późniejszego wykonania, użytkownik wprowadza polecenia, które są przetwarzane natychmiast.
   • Dlatego nazywa się to „przetwarzaniem interaktywnym”. Umożliwia użytkownikowi bezpośrednią interakcję z komputerem.
   • Przetwarzanie współdzielone w czasie jest znane jako „przetwarzanie na pierwszym planie”, a przetwarzanie zadań wsadowych jest znane jako „przetwarzanie w tle”.
5. Buforowanie
   • SPOOLing to skrót od Simultaneous Peripheral Operacje Online.
   • Urządzenie SPOOL służy do przechowywania danych wyjściowych programu lub aplikacji. Spoolowane dane wyjściowe są kierowane do urządzeń wyjściowych, takich jak drukarka (w razie potrzeby).
   • Jest to rozwiązanie wykorzystujące zalety buforowania w celu efektywnego wykorzystania urządzeń wyjściowych.

Klasyfikacja testów ręcznych w komputerach mainframe

Atrybuty te dzielą ręczną pracę testową na komputerze typu mainframe na dwa wyraźnie oddzielne strumienie.

Główna rama Testowanie ręczne można podzielić na dwa rodzaje:

1. Testowanie zadań wsadowych —

• Proces testowania obejmuje wykonywanie zadań wsadowych dla funkcjonalności zaimplementowanych w bieżącej wersji.
• Wyniki testów np.tracDane pochodzące z plików wyjściowych i bazy danych są weryfikowane i rejestrowane.

2. Testowanie online —

• Testowanie online odnosi się do testowania ekranów CICS, co jest podobne do testowania strony internetowej.
• Można zmienić funkcjonalność istniejących ekranów lub dodać nowe.
• Różne aplikacje mogą mieć ekrany zapytań i ekrany aktualizacji. Funkcjonalność tych ekranów należy sprawdzić w ramach testów online.

Jak przeprowadzać testy na komputerach mainframe

1. Zespół biznesowy przygotowuje dokumenty wymagań, które określają sposób modyfikacji konkretnego elementu lub procesu w cyklu wydania.
2. Zespół testowy i zespół programistów otrzymują dokument wymagań. Określają liczbę procesów, na które wpłynie zmiana. Zazwyczaj w wydaniu tylko 20–25% aplikacji jest bezpośrednio dotknięte przez dostosowane wymagania. Pozostałe 75–80% nakładu pracy przeznaczane jest na funkcjonalność gotową do użycia, taką jak testowanie aplikacji i procesów.
3. Zatem aplikację Mainframe należy przetestować w dwóch częściach:
   • Wymagania testowe — Testowanie aplikacji pod kątem funkcjonalności lub zmian wymienionych w dokumencie wymagań.
   • Integracja testowa — Testowanie całego procesu lub innych aplikacji odbierających lub wysyłających dane do danej aplikacji. Testy regresji jest głównym celem tej działalności testowej.

Narzędzia do automatycznego testowania komputerów mainframe

Poniżej znajduje się lista narzędzi, których można użyć na komputerze mainframe Testowanie automatyzacji.

• REXX — język skryptowy dostarczany z systemem z/OS, powszechnie używany do wykonywania powtarzalnych zadań przesyłania i sprawdzania wyników.
• przewyższać — używane z makrami do tworzenia, porównywania i raportowania danych testowych i plików wyjściowych.
• OpenText UFT jeden — tak obecnie nazywa się narzędzie, które branża nadal nazywa QTP lub QuickTest Professional; automatyzuje 3270 ekranów terminali.
• Galasa — oprogramowanie typu open source, Otwarty projekt Mainframe, głębokie ramy testowe integracji który obsługuje 3270 ekranów, zadania wsadowe JCL i Db2 z poziomu potoku CI/CD.
• Zestawy testowe dostawcy z/OS Do IBM Test Accelerator for Z i BMC AMI DevX Total Test obejmują testowanie jednostkowe języka COBOL i wirtualizowane środowiska testowe.

Niezależnie od tego, które narzędzie zostanie wybrane, będzie ono opłacalne tylko wtedy, gdy będzie przechowywane w dobrze utrzymanym stanie. framework automatyzacji testów a nie luźny stos skryptów.

Metodologia testowania komputerów mainframe

Rozważmy przykład: firma ubezpieczeniowa XYZ posiada moduł rejestracji członków. Pobiera on dane zarówno z ekranu rejestracji członków, jak i z rejestracji offline. Jak wspomniano wcześniej, stosuje dwa podejścia do testowania na komputerach mainframe: testowanie online i testowanie wsadowe.

• Testowanie online odbywa się na ekranie rejestracji członków. Podobnie jak strona internetowa, baza danych jest weryfikowana za pomocą danych wprowadzanych na ekranach.
• Rejestracja offline może odbywać się w formie papierowej lub za pośrednictwem zewnętrznej strony internetowej. Dane offline (nazywane również wsadowymi) będą wprowadzane do bazy danych firmy za pomocą zadań wsadowych. Płaski plik wejściowy jest przygotowywany zgodnie z określonym formatem danych i przekazywany do kolejnych zadań wsadowych. Dlatego do testowania aplikacji mainframe możemy zastosować następujące podejście.
  • Pierwsze zadanie w serii zadań wsadowych weryfikuje wprowadzone dane — na przykład znaki specjalne lub litery w polach zawierających wyłącznie cyfry.
  • Drugie zadanie weryfikuje spójność danych w oparciu o warunki biznesowe. Na przykład, rejestracja dziecka nie powinna zawierać danych osoby na utrzymaniu ani kodu pocztowego członka, który nie jest dostępny w ramach zarejestrowanego planu.
  • Trzecie zadanie modyfikuje dane do formatu, który można wprowadzić do bazy danych. Na przykład, usuwa nazwę planu (baza danych będzie przechowywać tylko identyfikator planu i nazwę planu ubezpieczeniowego), dodaje datę wprowadzenia i wprowadza podobne zmiany.
  • Czwarte zadanie ładuje dane do bazy danych.
• Testowanie zadań wsadowych w tym procesie odbywa się w dwóch fazach —
  • Każde zadanie jest sprawdzane osobno, a
  • Integrację między zadaniami weryfikuje się poprzez dostarczenie płaskiego pliku wejściowego do pierwszego zadania i walidację bazy danych. (Wyniki pośrednie należy zweryfikować ze względów bezpieczeństwa).

Poniżej przedstawiono metodę testowania komputerów mainframe:

Krok 1) Testowanie/test dymny

Głównym celem tego etapu jest sprawdzenie, czy wdrożony kod znajduje się w odpowiednim środowisku testowym. Gwarantuje to również brak krytycznych problemów z kodem. Jest to odpowiednik mainframe'a. Testowanie dymu na dowolnej innej platformie.

Krok 2) Testowanie systemu

Poniżej znajdują się rodzaje testów przeprowadzanych w ramach testowania systemu.

1. Testowanie partii — Testowanie to wykonuje się poprzez weryfikację wyników testów w plikach wyjściowych oraz zmian danych wprowadzonych przez zadania wsadowe objęte zakresem testowania, a następnie ich rejestrowanie.
2. Testowanie online — Testowanie odbywa się na front-endzie aplikacji mainframe. W tym przypadku aplikacja jest sprawdzana pod kątem poprawności pól wprowadzania, takich jak plan ubezpieczeniowy, odsetki od planu i podobne wartości.
3. Wsadowe testowanie integracji online — Testy te przeprowadzane są w systemach obsługujących zarówno procesy wsadowe, jak i aplikację online. Sprawdzany jest przepływ danych i interakcja między ekranami online a zadaniami wsadowymi.

   (Przykład tego typu testowania — rozważmy aktualizację szczegółów planu, taką jak wzrost stopy procentowej. Zmiana stóp procentowych jest dokonywana na ekranie aktualizacji, a szczegóły salda na odpowiednich kontach zostaną zmodyfikowane wyłącznie przez zadanie wsadowe wykonywane co noc. Testowanie w tym przypadku odbywa się poprzez walidację ekranu szczegółów planu i uruchomienie zadania wsadowego w celu aktualizacji wszystkich kont.)

4. Testowanie baz danych — Bazy danych, w których przechowywane są dane z aplikacji mainframe (IMS, IDMS, Db2, VSAM/ISAM, sekwencyjne zestawy danych, GDG), są sprawdzane pod kątem układu i sposobu przechowywania danych.

Krok 3) System Testy integracyjne

Podstawowym celem tego testowania jest sprawdzenie funkcjonalności systemów wchodzących w interakcję z testowanym systemem.

Systemy te nie są bezpośrednio objęte wymaganiami. Wykorzystują jednak dane z testowanego systemu. Ważne jest, aby przetestować Interfejs oraz różne typy komunikatów (np. Zadanie wykonane pomyślnie, Zadanie nieudane, Baza danych zaktualizowana), które mogą przepływać między systemami, a także wynikające z nich działania podejmowane przez poszczególne systemy.

Rodzaje testów przeprowadzanych na tym etapie to

1. Testowanie partii
2. Testowanie online
3. Online — testowanie integracji wsadowej

Krok 4) Testowanie regresyjne

Testowanie regresyjne to powszechny etap każdego projektu testowego. Testowanie w komputerach mainframe gwarantuje, że zadania wsadowe i ekrany online, które nie oddziałują bezpośrednio na testowany system (lub nie mieszczą się w zakresie wymagań), nie zostaną zakłócone przez bieżącą wersję projektu.

Aby testy regresyjne były efektywne, należy wybrać konkretny zestaw przypadków testowych, w zależności od ich złożoności, i utworzyć repozytorium przypadków testowych (tzw. repozytorium regresji). Zestaw ten należy aktualizować za każdym razem, gdy w wersji testowej wprowadzana jest nowa funkcjonalność. W przypadku, gdy repozytorium regresji jest zbyt duże, aby można było je w pełni uruchomić, Testowanie oparte na ryzyku służy do decydowania, które zadania i ekrany zostaną ponownie uruchomione jako pierwsze.

Krok 5) Test wydajności

Testy te przeprowadza się w celu zidentyfikowania wąskich gardeł w obszarach o dużym natężeniu ruchu, takich jak wprowadzanie danych front-end i aktualizacje bazy danych online, a także w celu oszacowania skalowalności aplikacji. Długotrwałe okna wsadowe są zazwyczaj badane za pomocą Testy warunków skrajnych w stosunku do wolumenów szczytowych.

Krok 6) Testowanie bezpieczeństwa

Testy te przeprowadza się w celu oceny, jak dobrze aplikacja została zaprojektowana i opracowana pod kątem przeciwdziałania atakom zabezpieczającym.

Należy przeprowadzić podwójne testy bezpieczeństwa systemu — testy bezpieczeństwa komputera mainframe i testy bezpieczeństwa sieci.

Cechy, które należy przetestować to:

1. Integrity
2. Poufność
3. Autoryzacja
4. Uwierzytelnianie
5. Dostępność:

Etapy testowania wsadowego

1. Po otrzymaniu przez zespół ds. zapewnienia jakości zatwierdzonego pakietu (pakiet zawiera procedury, JCL, karty kontrolne, moduły i podobne elementy), tester powinien przejrzeć jego zawartość i pobrać ją do PDS, zależnie od potrzeb.
2. Przekształć produkcyjny JCL lub deweloperski JCL w QA JCL, inaczej nazywany JOB SETUP.
3. Skopiuj plik produkcyjny i przygotuj pliki testowe.
4. Dla każdej funkcjonalności zdefiniowana będzie sekwencja zadań (jak wyjaśniono w przykładzie w sekcji „Metodologia testowania komputerów mainframe”). Zadania należy przesyłać za pomocą polecenia SUB wraz z plikami danych testowych.
5. Sprawdź plik pośredni, aby zidentyfikować przyczyny brakujących lub błędnych danych.
6. Sprawdź końcowy plik wyjściowy, bazę danych i bufor, aby zweryfikować wyniki testu.
7. Jeśli zadanie się nie powiedzie, w buforze będzie podana przyczyna niepowodzenia zadania. Napraw błąd i prześlij zadanie ponownie.

Raportowanie testowe - A ulegnie awarii? należy zalogować, jeśli rzeczywisty wynik odbiega od oczekiwanego.

Etapy testowania online

1. Wybierz ekran Online w Środowisko testowe.
2. Przetestuj każde pole pod kątem akceptowalnych danych.
3. Przetestuj Scenariusz testowy na ekranie.
4. Sprawdź bazę danych pod kątem aktualizacji danych na ekranie online.

Raportowanie testowe — Wadę należy zgłosić, jeżeli rzeczywisty wynik odbiega od oczekiwanego.

Etapy testów integracji wsadowej online

1. Uruchom zadanie w środowisku testowym i sprawdź poprawność danych na ekranach online.
2. Zaktualizuj dane na ekranach online i sprawdź, czy zadanie wsadowe działa prawidłowo przy użyciu zaktualizowanych danych.

Polecenia używane w testowaniu komputerów mainframe

Kroki te wykonuje się w terminalu, więc większość dnia testera zajmuje użycie niewielkiego zasobu poleceń.

1. PRZEŚLIJ — Prześlij pracę w tle.
2. ANULUJ — Anuluj zadanie w tle.
3. PRZEZNACZYĆ — Przydziel zbiór danych.
4. KOPIA — Skopiuj zbiór danych.
5. PRZEMIANOWAĆ — Zmień nazwę zestawu danych.
6. DELETE — Usuń zbiór danych.
7. SKANOWANIE ZADANIA — Powiąż JCL z programem, bibliotekami, plikami i innymi zasobami bez konieczności jego uruchamiania.

Istnieje wiele innych poleceń używanych w razie potrzeby, ale nie są one zbyt częste.

Wymagania wstępne do rozpoczęcia testowania komputera mainframe

Podstawowe informacje potrzebne do testowania komputerów mainframe to:

• Login i hasło umożliwiające zalogowanie się do aplikacji.
• Krótka znajomość komend ISPF.
• Nazwy plików, kwalifikator pliku i ich typy.

Przed rozpoczęciem testowania komputera mainframe należy zweryfikować poniższe aspekty.

1. Praca
   • Przed wykonaniem zadania należy sprawdzić, czy nie ma błędów, wykonując skanowanie (polecenie — JOBSCAN).
   • Parametr CLASS powinien wskazywać na klasę testową.
   • Przekieruj dane wyjściowe zadania do spoola lub JHS, lub w razie potrzeby, używając parametru MSGCLASS.
   • Przekieruj wiadomość e-mail w zadaniu do bufora lub do testowego identyfikatora poczty e-mail.
   • Zakomentuj kroki protokołu FTP w celu przeprowadzenia początkowego testu, a następnie skieruj zadanie na serwer testowy.
   • W przypadku wygenerowania w zadaniu rekordu IMR (Incident Management Record), należy dodać komentarz „CEL TESTOWANIA” w zadaniu lub karcie parametrów.
   • Wszystkie biblioteki produkcyjne w zadaniu powinny zostać zmienione i wskazane jako biblioteki testowe.
   • Pracy nie należy pozostawiać bez nadzoru.
   • Aby zapobiec wykonywaniu zadania w nieskończonej pętli w przypadku wystąpienia błędu, należy dodać parametr TIME z określonym czasem.
   • Zapisz wynik zadania, łącznie ze szpulą. Szpulę można zapisać za pomocą XDC.
2. filet
   • Utwórz plik testowy tylko o wymaganym rozmiarze. W razie potrzeby użyj grup GDG (Generation Data Groups — plików o tej samej nazwie, ale z kolejnymi numerami wersji, takich jak MYLIB.LIB.TEST.G0001V00 i MYLIB.LIB.TEST.G0002V00), aby przechowywać dane w kolejnych plikach o tej samej nazwie.
   • Parametr DISP (Dyspozycja — informuje system, czy zachować czy usunąć zbiór danych po normalnym lub nieprawidłowym zakończeniu kroku lub zadania) dla plików powinien być poprawnie zakodowany.
   • Upewnij się, że wszystkie pliki użyte do wykonania zadania zostały poprawnie zapisane i zamknięte, aby zapobiec przejściu zadania w tryb HOLD.
   • Podczas testowania przy użyciu GDG upewnij się, że wybrano właściwą wersję.
3. Baza danych
   • Podczas wykonywania zadania lub programu online należy upewnić się, że nie zostaną wprowadzone, zaktualizowane lub usunięte niepożądane dane.
   • Należy również upewnić się, że do testowania użyto właściwego regionu Db2.
4. Przypadki testowe
   • Zawsze testuj warunki brzegowe, takie jak pusty plik, przetwarzanie pierwszego rekordu i przetwarzanie ostatniego rekordu.
   • Zawsze uwzględniaj zarówno pozytywne, jak i negatywne warunki testowe.
   • W przypadku stosowania w programie standardowych procedur, takich jak restart punktu kontrolnego, moduły awaryjnego zakończenia lub pliki sterujące, należy uwzględnić Przypadek testowys w celu sprawdzenia, czy moduły zostały użyte prawidłowo.
5. Dane testowe
   • Konfigurację danych testowych należy przeprowadzić przed rozpoczęciem testów.
   • Nigdy nie modyfikuj danych w obszarze testowym bez powiadomienia innych. Inne zespoły mogą pracować z tymi samymi danymi i ich testy mogą zakończyć się niepowodzeniem.
   • Jeżeli w trakcie realizacji potrzebne są pliki produkcyjne, należy przed ich kopiowaniem lub wykorzystaniem uzyskać odpowiednie uprawnienia.

Najlepsze praktyki

1. W przypadku uruchomienia zadania wsadowego, MAX CC 0 oznacza, że ​​zadanie zostało wykonane pomyślnie. Nie oznacza to jednak, że funkcjonalność działa prawidłowo. Zadanie zostanie wykonane pomyślnie nawet wtedy, gdy dane wyjściowe są puste lub niezgodne z oczekiwaniami. Dlatego zawsze należy sprawdzić wszystkie dane wyjściowe przed uznaniem zadania za pomyślne.
2. Zawsze warto przeprowadzić próbę działania testowanego zadania. Próba działania jest przeprowadzana z pustymi plikami wejściowymi. Ten proces należy zastosować w przypadku zadań, na które wpływają zmiany wprowadzone w cyklu testowym.
3. Przed rozpoczęciem cyklu testowego, konfiguracja zadania testowego powinna zostać przeprowadzona z dużym wyprzedzeniem. Pomaga to w wykryciu ewentualnych błędów JCL z wyprzedzeniem, oszczędzając czas podczas wykonywania testu.
4. Uzyskując dostęp do tabel Db2 za pomocą SPUFI (opcja w emulatorze umożliwiająca dostęp do tabel Db2), zawsze ustawiaj opcję automatycznego zatwierdzania na „NIE”, aby uniknąć przypadkowych aktualizacji.
5. Dostępność danych testowych stanowi główne wyzwanie w testowaniu wsadowym. Wymagane dane powinny zostać wygenerowane z dużym wyprzedzeniem przed cyklem testowym i sprawdzone pod kątem kompletności. Tracking że przygotowanie w ramach wspólnego zarządzanie testami repozytorium utrzymuje zgodność podłoża regresji i konfiguracji danych.
6. Niektóre transakcje online i zadania wsadowe mogą zapisywać dane w kolejkach komunikatów (MQ) transmitPrzesyłanie danych do innych aplikacji. Jeśli dane są nieprawidłowe, może to spowodować wyłączenie lub zatrzymanie MQ, co wpłynie na cały proces testowania. Dobrą praktyką jest sprawdzenie, czy MQ działają poprawnie po zakończeniu testów.

Wyzwania związane z testowaniem komputerów mainframe i rozwiązywanie problemów

Mimo tych praktyk, kilka problemów pojawia się ponownie w niemal każdej wersji komputera mainframe. Poniższa tabela zestawia każdy z nich z podejściem, które go rozwiązuje.

Wyzwania	Podejście
Niekompletne/niejasne wymagania	Dostęp do podręcznika użytkownika lub przewodnika szkoleniowego może być możliwy, ale nie jest to to samo, co udokumentowane wymagania. Testerzy powinni być zaangażowani w cykl życia testowania oprogramowania już od fazy wymagań. Pomaga to zweryfikować, czy wymagania są testowalne.
Konfiguracja danych / Identyfikacja	Mogą wystąpić sytuacje, w których istniejące dane powinny zostać ponownie wykorzystane zgodnie z wymaganiami. Czasami trudno jest zidentyfikować potrzebne dane spośród istniejących. Do konfiguracji danych można użyć narzędzi własnych, w zależności od potrzeb. Aby pobrać istniejące dane, zapytania powinny zostać utworzone z wyprzedzeniem. W przypadku jakichkolwiek trudności można zwrócić się do zespołu zarządzającego danymi z prośbą o utworzenie lub klonowanie wymaganych danych.
Konfiguracja pracy	Po pobraniu zadań do systemu PDS, zadanie należy skonfigurować w obszarze QA, aby nie było ono przesyłane z kwalifikatorem produkcyjnym ani szczegółami ścieżki. Narzędzia do konfiguracji zadań powinny być używane w celu wyeliminowania błędów ludzkich popełnionych podczas konfiguracji.
Żądanie ad hoc	Mogą wystąpić sytuacje, gdy testowanie od końca do końca Wymaga obsługi z powodu problemu w aplikacjach nadrzędnych lub podrzędnych. Żądania te wydłużają czas i zwiększają nakład pracy w cyklu wykonania. Użycie skryptów automatyzacji, skryptów regresji i skryptów szkieletowych może pomóc w skróceniu nakładu czasu i wysiłku.
Terminowe wydania w celu zmiany zakresu	Może zaistnieć sytuacja, w której wpływ kodu całkowicie zmieni wygląd i działanie systemu. Może to wymagać zmiany przypadków testowych, skryptów i danych. Powinien istnieć proces zarządzania zakresem zmian i analiza wpływu.

Często spotykane Abends

Gdy zadanie się nie powiedzie, spool zgłasza kod awaryjnego zakończenia. Poniższa lista zawiera kody, z którymi testerzy komputerów mainframe spotykają się najczęściej, wraz z ich typową przyczyną.

1. S001 — Wystąpił błąd wejścia/wyjścia.

   Przyczyna — odczytanie końca pliku, błąd długości pliku lub próba zapisu do pliku tylko do odczytu.

2. S002 — Nieprawidłowy rekord wejścia/wyjścia.

   Powód — próba zapisania rekordu dłuższego niż długość rekordu.

3. S004 — Wystąpił błąd podczas OTWIERANIA.

   Powód — nieprawidłowy DCB.

4. S013 — Błąd podczas otwierania zbioru danych.

   Powód — Członek PDS nie istnieje lub długość rekordu w programie nie odpowiada rzeczywistej długości rekordu.

5. S0C1 Do OperaWyjątek tion.

   Powód — nie można otworzyć pliku lub brakuje karty DD.

6. S0C4 — Wyjątek ochrony/naruszenie zasad przechowywania.

   Powód — próba uzyskania dostępu do pamięci masowej, która jest niedostępna dla programu.

7. S0C7 — Wyjątek sprawdzania programu, dane.

   Powód — zmiana układu rekordu lub pliku.

8. Sx22 — Zadanie zostało anulowane.

   Powód — zadanie zostało zakończone przed ukończeniem; środkowa cyfra określa, kto lub co je anulowało.

9. S222 — Zadanie zostało anulowane przez użytkownika bez zrzutu.
10. S322 — Czas trwania zadania lub kroku przekroczył określony limit, program znajduje się w pętli lub parametr TIME jest niewystarczający.
11. S522 — Przekroczono limit czasu sesji TSO.
12. S806 — Nie można połączyć ani załadować.

    Powód — zadanie nie może znaleźć określonego modułu ładowania.

13. S80A — Za mało pamięci wirtualnej do spełnienia żądań GETMAIN lub FREEMAIN.
14. S913 — Próba uzyskania dostępu do zbioru danych, do którego użytkownik nie jest uprawniony.
15. Sx37 — Nie udało się przydzielić wystarczającej ilości miejsca do przechowywania zestawu danych.

Pomoc w przypadku błędów — Bardzo popularne narzędzie umożliwiające uzyskanie szczegółowych informacji na temat różnych typów awarii.

Typowe problemy napotykane podczas testowania komputerów mainframe

• Praca się kończy — Aby pomyślnie ukończyć zadanie, należy sprawdzić dane, plik wejściowy oraz obecność modułów w określonej lokalizacji. Przyczyny problemów mogą być różne, a najczęstszymi są nieprawidłowe dane, nieprawidłowe pole wejściowe, niezgodność dat lub problemy środowiskowe.
• Plik wyjściowy jest pusty — Chociaż zadanie może zostać pomyślnie wykonane (MaxCC 0), wynik może nie być zgodny z oczekiwaniami. Dlatego przed zaliczeniem każdego przypadku testowego tester musi upewnić się, że wynik został zweryfikowany krzyżowo. Dopiero wtedy można kontynuować testowanie.
• Plik wejściowy jest pusty — W niektórych aplikacjach pliki są odbierane z procesów nadrzędnych. Przed użyciem otrzymanego pliku do testowania bieżącej aplikacji, dane powinny zostać zweryfikowane krzyżowo, aby uniknąć ponownego uruchomienia i przeróbek.

FAQ