Testowanie komputerów mainframe — kompletny samouczek

Zanim poznamy koncepcje testowania komputerów mainframe, zapoznajmy się

Co to jest komputer główny?

Komputer mainframe to system komputerowy o dużej wydajności i szybkości. Jest używany do celów obliczeniowych na większą skalę, które wymagają dużej dostępności i bezpieczeństwa. Jest stosowany głównie w sektorach takich jak finanse, ubezpieczenia, handel detaliczny i inne krytyczne obszary, w których ogromne dane są przetwarzane wielokrotnie.

Testowanie komputera głównego

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

Podczas testowania komputera mainframe tester musi jedynie wiedzieć o nawigacji na ekranach CICS. Są one budowane na zamówienie do konkretnych zastosowań. Wszelkie zmiany dokonane w kodzie w COBOL, JCL itp. tester nie musi martwić się o emulator ustawiony na maszynie. Zmiany, które działają na jednym emulatorze terminala, będą działać na innych.

Aplikacja mainframe (inaczej zwana zbiorem zadań) jest testowana na podstawie przypadków testowych opracowanych przy użyciu 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.

Atrybuty komputera mainframe

Pamięć wirtualna
1. Jest to technika, która pozwala procesorowi symulować wielkość pamięci głównej, która jest większa niż rzeczywista ilość rzeczywistej pamięci.
2. Jest to technika efektywnego wykorzystania pamięci do przechowywania i wykonywania zadań o różnej wielkości.
3. Wykorzystuje pamięć dyskową jako rozszerzenie prawdziwej pamięci.
Wieloprogramowanie
1. Komputer wykonuje więcej niż jeden program w tym samym czasie. Ale w danym momencie tylko jeden program może kontrolować procesor.
2. Jest to funkcja zapewniająca efektywne wykorzystanie procesora.
Przetwarzanie wsadowe
1. Jest to technika, dzięki której dowolne zadanie jest realizowane w jednostkach zwanych zadaniami.
2. Zadanie może powodować wykonanie jednego lub większej liczby programów w sekwencji.
3. Harmonogram zadań podejmuje decyzję o kolejności wykonywania zadań. Aby zmaksymalizować średnią przepustowość, zadania są planowane według ich priorytetu i klasy.
4. Informacje niezbędne do przetwarzania wsadowego są dostarczane przez JCL (JĘZYK KONTROLI JOB). JCL opisuje zadanie wsadowe – potrzebne programy, dane i zasoby.
Dzielenie czasu
1. 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.
2. Dlatego nazywa się to „przetwarzaniem interaktywnym”. Umożliwia użytkownikowi bezpośrednią interakcję z komputerem.
3. Przetwarzanie współdzielone w czasie jest znane jako „przetwarzanie na pierwszym planie”, a przetwarzanie zadań wsadowych jest znane jako „przetwarzanie w tle”.
Buforowanie
1. SPOOLing oznacza Jednoczesne peryferia Operaonline.
2. Urządzenie SPOOL służy do przechowywania danych wyjściowych programu/aplikacji. Buforowany wydruk jest kierowany do urządzeń wyjściowych, takich jak drukarka (w razie potrzeby).
3. Jest to rozwiązanie wykorzystujące zalety buforowania w celu efektywnego wykorzystania urządzeń wyjściowych.

Klasyfikacja testów ręcznych w komputerach mainframe

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

1. Testowanie zadań wsadowych -

Proces testowania obejmuje wykonanie zadań wsadowych dla funkcjonalności zaimplementowanej w bieżącej wersji.
Wynik testu wyodrębniony z plików wyjściowych i bazy danych jest weryfikowany i rejestrowany.

2. Testowanie online -

Testowanie online odnosi się do testowania ekranów CICS, które 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 przeprowadzić testowanie komputera mainframe

Zespół biznesowy przygotowuje dokumenty wymagań. Które określają, w jaki sposób konkretny element lub proces będzie modyfikowany w cyklu wydania.
Zespół testujący i programista otrzymują dokument wymagań. Określą, ile procesów będzie podlegać zmianie. Zazwyczaj w wydaniu tylko 20-25% aplikacji jest bezpośrednio objętych dostosowanym wymaganiem. Pozostałe 75% wydania będzie przeznaczone na funkcje out-box, takie jak testowanie aplikacji i procesów.
Zatem aplikację Mainframe należy przetestować w dwóch częściach:
1. Wymagania testowe – Testowanie aplikacji pod kątem funkcjonalności lub zmiany wymienionej w dokumencie wymagań.
2. Integracja testowa – Testowanie całego procesu lub innej aplikacji, która odbiera lub wysyła dane do aplikacji, której dotyczy problem. 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
przewyższać
QTP

Metodologia testowania komputerów mainframe

Rozważmy przykład: Firma ubezpieczeniowa XYZ posiada moduł rejestracji członków. Pobiera dane zarówno z ekranu rejestracji członka, jak i rejestracji offline. Jak wspomnieliśmy wcześniej, do testowania komputerów mainframe, testów online i testów wsadowych potrzebne są dwa podejścia.

Testowanie online odbywa się na ekranie rejestracji członka. Podobnie jak strona internetowa, baza danych jest weryfikowana na podstawie danych wprowadzanych na ekranach.
Rejestracja offline może być zapisem papierowym lub zapisem na stronie internetowej osoby trzeciej. Dane offline (nazywane również zbiorem) zostaną wprowadzone do bazy danych firmy za pomocą zadań wsadowych. Płaski plik wejściowy jest przygotowywany zgodnie z określonym formatem danych i przekazywany do sekwencji zadań wsadowych. Tak więc do testowania aplikacji mainframe możemy użyć następującego podejścia.
Pierwsze zadanie w linii zadań wsadowych sprawdza wprowadzone dane. Powiedzmy na przykład znak specjalny, alfabety w polach zawierających tylko liczby itp.
Drugie zadanie sprawdza spójność danych w oparciu o warunki biznesowe. Na przykład rejestracja dziecka nie powinna zawierać danych zależnych, kodu pocztowego członka (który nie jest dostępny w ramach usługi w ramach zarejestrowanego planu) itp.
Trzecie zadanie modyfikuje dane w formacie, który można wprowadzić do bazy danych. Na przykład usunięcie nazwy planu (baza danych będzie przechowywać tylko identyfikator planu i nazwę planu ubezpieczenia), dodanie daty wpisu itp.
Czwarte zadanie ładuje dane do bazy danych.
Testowanie zadań wsadowych odbywa się w tym procesie w dwóch fazach –
Każde zadanie jest sprawdzane oddzielnie, a plik
Integracja między zadaniami jest sprawdzana poprzez dostarczenie płaskiego pliku wejściowego do pierwszego zadania i sprawdzenie bazy danych. (Wyniki pośrednie należy zweryfikować w celu zachowania szczególnej ostrożności)

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

Krok 1) Leże/Testowanie dymu

Głównym celem na tym etapie jest sprawdzenie, czy wdrożony kod znajduje się w odpowiednim środowisku testowym. Zapewnia również, że nie ma żadnych krytycznych problemów z kodem.

Krok 2) Testowanie systemu

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

Testowanie partii – Testowanie to zostanie przeprowadzone poprzez sprawdzenie wyników testów w plikach wyjściowych i zmianach danych dokonanych przez zadania wsadowe objęte zakresem testowania oraz ich zapisanie.
Testowanie online – To testowanie zostanie przeprowadzone na froncie aplikacji mainframe. Tutaj aplikacja jest testowana pod kątem prawidłowego pola wejściowego, takiego jak plan ubezpieczeniowy, odsetki od planu itp.
Wsadowe testowanie integracji online – Testy te zostaną przeprowadzone na systemach obsługujących procesy wsadowe i aplikację online. Sprawdzany jest przepływ danych i interakcja między ekranami online a zadaniami wsadowymi.
(Przykład tego typu testów – Rozważ aktualizację szczegółów Planu, takich jak wzrost stopy procentowej. Zmiana odsetek jest dokonywana na ekranie aktualizacji, a szczegóły salda na kontach, których to dotyczy, zostaną zmodyfikowane tylko przez nocne zadanie wsadowe. Testowanie w tym przypadku zostanie przeprowadzone poprzez zatwierdzenie ekranu szczegółów Planu i uruchomienie zadania wsadowego w celu aktualizacji wszystkich kont).
Testowanie baz danych – Bazy danych, w których sprawdzane są dane z aplikacji mainframe (IMS, IDMS, DB2, VSAM/ISAM, sekwencyjne zbiory danych, GDG) pod kątem ich układu i przechowywania danych.

Krok 3) Konfiguracja Testy integracyjne

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

Wymagania te nie mają bezpośredniego wpływu na te systemy. Wykorzystują jednak dane z testowanego systemu. Ważne jest, aby przetestować interfejs i różne typy komunikatów (np. zadanie zakończone sukcesem, zadanie zakończone niepowodzeniem, aktualizacja bazy danych itp.), które mogą przepływać pomiędzy systemami i wynikać z działań podejmowanych przez poszczególne systemy.

Rodzaje testów przeprowadzanych na tym etapie to

Testowanie partii
Testowanie online
Online – wsadowe testowanie integracji

Krok 4) Testy regresji

Testowanie regresyjne jest częstym etapem każdego rodzaju projektu testowego. To testowanie na komputerach mainframe zapewnia, że bieżąca wersja projektu nie ma wpływu na zadania wsadowe i ekrany online, które nie wchodzą w bezpośrednią interakcję z testowanym systemem (lub nie wchodzą w zakres wymagań).

Aby testy regresji były skuteczne, należy wybrać konkretny zestaw przypadków testowych w zależności od ich złożoności i utworzyć podłoże regresji (repozytorium przypadków testowych). Zestaw ten należy aktualizować za każdym razem, gdy w wersji zostanie wprowadzona nowa funkcjonalność.

Krok 5) Test wydajności

Testowanie to ma na celu identyfikację wąskich gardeł w obszarach o dużym natężeniu ruchu, takich jak dane front-end, aktualizacja internetowych baz danych i prognozowanie skalowalności aplikacji.

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.

W systemie należy przeprowadzić podwójne testy bezpieczeństwa – bezpieczeństwo komputera mainframe i bezpieczeństwo sieci.

Funkcje, które należy przetestować, to

Integrity
Poufność
Autoryzacja
Uwierzytelnianie
Dostępność

Kroki związane z testowaniem wsadowym

Po tym jak zespół ds. kontroli jakości otrzyma zatwierdzony pakiet (pakiet zawiera procedury, JCL, karty kontrolne, moduły itp.), tester powinien wyświetlić podgląd i pobrać zawartość do PDS zgodnie z wymaganiami.
Przekonwertuj produkcyjny JCL lub deweloperski JCL na QA JCL, inaczej nazywany JOB SETUP.
Kopiowanie pliku produkcyjnego i przygotowanie plików testowych.
Dla każdej funkcjonalności zostanie zdefiniowana sekwencja zadań. (Jak wyjaśniono w przykładzie w sekcji Metodologia w dziale Mainframe). Zadania należy przesłać za pomocą polecenia SUB wraz z plikami danych testowych.
Sprawdź plik pośredni, aby zidentyfikować przyczyny braków lub błędów w danych.
Sprawdź końcowy plik wyjściowy, bazę danych i bufor, aby zweryfikować wyniki testu.
Jeśli zadanie się nie powiedzie, w buforze będzie podana przyczyna niepowodzenia zadania. Napraw błąd i prześlij zadanie ponownie.

Raportowanie testów – Wada powinien zostać zarejestrowany, jeśli rzeczywisty wynik odbiega od oczekiwanego.

Kroki związane z testowaniem online

Wybierz ekran Online w środowisku testowym.
Przetestuj każde pole pod kątem akceptowalnych danych.
Przetestuj Scenariusz testowy na ekranie.
Sprawdź bazę danych pod kątem aktualizacji danych na ekranie online.

Raportowanie testów – w przypadku, gdy rzeczywisty wynik odbiega od oczekiwanego, należy zarejestrować defekt.

Kroki związane z testowaniem online – integracja wsadowa

Uruchom zadanie w formacie a Środowisko testowe i sprawdź dane na ekranach online.
Zaktualizuj dane na ekranach online i sprawdź, czy zadanie wsadowe zostało poprawnie uruchomione ze zaktualizowanymi danymi.

Polecenia używane w testowaniu komputerów mainframe

WYŚLIJ – Prześlij zadanie w tle.
ANULUJ – Anuluj zadanie w tle.
ALLOCATE – przydziela zbiór danych
KOPIUJ — kopiuje zbiór danych
ZMIEŃ NAZWĘ – Zmień nazwę zestawu danych
USUŃ – Usuń zbiór danych
SKANOWANIE ZADAŃ – Aby powiązać JCL z programem, bibliotekami, plikiem itp. bez ich wykonywania.

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

Wymagania wstępne umożliwiające rozpoczęcie testowania komputera mainframe

Podstawowe dane potrzebne do przetestowania komputera mainframe to:

Login i hasło umożliwiające zalogowanie się do aplikacji.
Krótka wiedza na temat poleceń ISPF.
Nazwy plików, kwalifikator plików i ich typy.

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

Praca
1. Wykonaj skanowanie zadania (Polecenie – JOBSCAN), aby sprawdzić błędy przed jego wykonaniem.
2. Parametr CLASS należy wskazać na klasę testową.
3. Skieruj dane wyjściowe zadania do bufora lub JHS lub zgodnie z wymaganiami, używając parametru MSGCLASS.
4. Przekieruj wiadomość e-mail w zadaniu do bufora lub testowego identyfikatora poczty e-mail.
5. Skomentuj kroki FTP w celu wstępnego przetestowania, a następnie skieruj zadanie na serwer testowy.
6. W przypadku wygenerowania IMR (rekordu zarządzania incydentami) w zadaniu wystarczy dodać komentarz „CEL TESTOWANIA” na karcie zadania lub parametru.
7. Wszystkie biblioteki produkcyjne w zadaniu powinny zostać zmienione i wskazane jako biblioteki testowe.
8. Pracy nie należy pozostawiać bez nadzoru.
9. Aby zadanie nie uruchamiało się w nieskończonej pętli w przypadku wystąpienia błędu, należy dodać parametr CZAS z określonym czasem.
10. Zapisz wynik zadania, łącznie ze szpulą. Szpulę można zapisać za pomocą XDC.

filet
1. Utwórz plik testowy tylko o wymaganym rozmiarze. Użyj GDG (Generation Data Groups – Pliki o tej samej nazwie, ale z kolejnymi numerami wersji – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 itd.), gdy jest to konieczne do przechowywania danych w kolejnych plikach o tej samej nazwie.
2. Parametr DISP (Disposition – opisuje system wykonywania zachowywania lub usuwania zbioru danych po normalnym lub nienormalnym zakończeniu kroku lub zadania) dla plików powinien być poprawnie zakodowany.
3. Upewnij się, że wszystkie pliki użyte do wykonania zadania zostały zapisane i prawidłowo zamknięte, aby zapobiec przejściu zadania w tryb WSTRZYMAJ.
4. Podczas testowania przy użyciu GDG upewnij się, że wskazana jest właściwa wersja.
Baza danych
1. Podczas wykonywania zadania lub programu online należy upewnić się, że niezamierzone dane nie zostały wstawione, zaktualizowane lub usunięte.
2. Upewnij się także, że do testowania używany jest właściwy region DB2.
Przypadki testowe
1. Zawsze testuj warunki brzegowe, takie jak – pusty plik, przetwarzanie pierwszego rekordu, przetwarzanie ostatniego rekordu itp.
2. Zawsze uwzględniaj zarówno pozytywne, jak i negatywne warunki testowe.
3. W przypadku, gdy w programie stosowane są standardowe procedury, takie jak ponowne uruchomienie punktu kontrolnego, moduły Abend, pliki kontrolne itp., należy uwzględnić przypadki testowe w celu sprawdzenia, czy moduły zostały prawidłowo użyte.
Dane testowe
1. Konfigurację danych testowych należy przeprowadzić przed rozpoczęciem testów.
2. Nigdy nie modyfikuj danych w obszarze testowym bez powiadomienia. Mogą istnieć inne zespoły pracujące z tymi samymi danymi i ich test zakończy się niepowodzeniem.
3. Jeżeli w trakcie realizacji potrzebne są pliki produkcyjne, należy przed ich kopiowaniem lub wykorzystaniem uzyskać odpowiednie uprawnienia.

Najlepsze praktyki

W przypadku uruchomienia zadania wsadowego wartość MAX CC 0 wskazuje, że zadanie zostało pomyślnie wykonane. Nie oznacza to, że funkcjonalność działa prawidłowo. Zadanie zostanie wykonane pomyślnie, nawet jeśli dane wyjściowe będą puste lub niezgodne z oczekiwaniami. Dlatego zawsze oczekuje się sprawdzenia wszystkich wyników przed zadeklarowaniem pomyślnego wykonania zadania.
Zawsze dobrą praktyką jest wykonanie próbnego przebiegu testowanego zadania. Praca próbna jest wykonywana z pustymi plikami wejściowymi. Proces ten należy zastosować w przypadku zadań, na które mają wpływ zmiany wprowadzone w cyklu testowym.
Przed rozpoczęciem cyklu testowego konfigurację zadania testowego należy wykonać z dużym wyprzedzeniem. Pomoże to w wykryciu z wyprzedzeniem wszelkich błędów JCL, oszczędzając w ten sposób czas podczas wykonywania.
Podczas uzyskiwania dostępu do tabel DB2 poprzez SPUFI (opcja w emulatorze umożliwiająca dostęp do tabel DB2) zawsze ustawiaj automatyczne zatwierdzanie na „NIE”, aby uniknąć przypadkowych aktualizacji.
Dostępność danych testowych jest głównym wyzwaniem w testowaniu wsadowym. Wymagane dane należy utworzyć z dużym wyprzedzeniem przed cyklem testowym i sprawdzić pod kątem kompletności.
Niektóre transakcje online i zadania wsadowe mogą zapisywać dane w MQ (kolejce komunikatów) w celu przesyłania danych do innych aplikacji. Jeśli dane są nieprawidłowe, może to spowodować wyłączenie/zatrzymanie MQ, co będzie miało wpływ na cały proces testowania. Dobrą praktyką jest sprawdzenie po przetestowaniu, czy MQ działają prawidłowo.

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

Wyzwania	Podejście
Niekompletne/niejasne wymagania Może istnieć dostęp do instrukcji obsługi/przewodnika szkoleniowego, ale nie są one tożsame z udokumentowanymi wymaganiami.	Testerzy powinni być zaangażowani w SDLC już od fazy wymagań. Pomoże to sprawdzić, czy wymagania są testowalne.
Konfiguracja danych/identyfikacja Mogą zaistnieć sytuacje, w których istniejące dane powinny zostać ponownie wykorzystane zgodnie z wymaganiami. Czasami trudno jest zidentyfikować wymagane dane na podstawie istniejących danych.	Do konfiguracji danych można zastosować własne narzędzia, w zależności od potrzeb. Aby pobrać istniejące dane, należy wcześniej utworzyć zapytania. W przypadku jakichkolwiek trudności można złożyć wniosek do zespołu zarządzającego danymi o utworzenie lub sklonowanie wymaganych danych.
Konfiguracja pracy Po pobraniu zadań do PDS należy je skonfigurować w regionie kontroli jakości. Aby zadania nie były przesyłane z kwalifikatorem produkcji lub szczegółami ścieżki.	Należy używać narzędzi do konfiguracji zadania, aby uniknąć błędów ludzkich popełnionych podczas konfiguracji.
Żądanie ad hoc Mogą zaistnieć sytuacje, w których konieczne będzie wsparcie kompleksowych testów ze względu na problemy z aplikacjami na wcześniejszym lub dalszym etapie. Żądania te zwiększają czas i wysiłek w cyklu wykonawczym.	Korzystanie ze skryptów automatyzacji, skryptów regresji i skryptów szkieletowych może pomóc w zmniejszeniu nakładu czasu i wysiłku.
Terminowe wydania w celu zmiany zakresu Może zaistnieć sytuacja, w której wpływ kodu może całkowicie zmienić wygląd i działanie systemu. Może to wymagać zmiany przypadków testowych, skryptów i danych.	Należy wdrożyć proces zarządzania zmianą zakresu i analizę wpływu.

Napotkano typowe Abendy

S001 – Wystąpił błąd we/wy.
Powód – Odczyt na końcu pliku, błąd długości pliku, próba zapisu do pliku tylko do odczytu.
S002 – Nieprawidłowy rekord we/wy.
Powód – próba zapisania rekordu dłuższego niż długość rekordu.
S004 – Wystąpił błąd podczas OTWIERANIA.
Powód – nieprawidłowy DCB
S013 – Błąd podczas otwierania zbioru danych.
Powód – członek PDS nie istnieje, długość rekordu w programie nie odpowiada rzeczywistej długości rekordu.
S0C1 – OperaWyjątek
Powód – Nie można otworzyć pliku, brak karty DD
S0C4 – Wyjątek ochrony/naruszenie pamięci
Powód — próba dostępu do pamięci niedostępnej dla programu.
S0C7 – Wyjątek sprawdzania programu – Dane
Powód – Zmiana układu rekordu lub układu pliku.
Sx22 – Zadanie zostało anulowane
S222 – Zadanie anulowane przez użytkownika bez zrzutu.
S322 – Czas zadania lub kroku przekroczył określony limit, program znajduje się w pętli lub parametr czasu jest niewystarczający.
S522 – Przekroczono limit czasu sesji OSP.
S806 – Nie można połączyć lub załadować.
Powód — identyfikator zadania nie może znaleźć określonego modułu ładowania.
S80A – Za mało pamięci wirtualnej, aby spełnić żądania GETMAIN lub FREEMAIN.
S913 – Próba dostępu do zbioru danych, do którego użytkownik nie jest autoryzowany.
Sx37 – Nie można przydzielić wystarczającej ilości miejsca do zbioru danych.

Error Assist – Bardzo popularne narzędzie pozwalające uzyskać szczegółowe informacje na temat różnego rodzaju zakrętów.

Typowy problem występujący podczas testowania komputerów mainframe

Praca się kończy – Aby pomyślnie zakończyć zadanie, należy sprawdzić dane, plik wejściowy i moduły obecne w określonej lokalizacji, czy nie. Nieprawidłowości mogą wystąpić z wielu powodów, z których najczęstszym jest nieprawidłowe dane, nieprawidłowe pole wejściowe, niedopasowanie daty, problemy środowiskowe itp.
Plik wyjściowy jest pusty–Chociaż zadanie może zostać pomyślnie wykonane (MaxCC 0), dane wyjściowe mogą nie być zgodne z oczekiwaniami. Dlatego przed zaliczeniem dowolnego przypadku testowego tester musi upewnić się, że dane wyjściowe zostały zweryfikowane krzyżowo. Dopiero wtedy przejdź dalej.
Plik wejściowy jest pusty – W niektórych aplikacjach pliki będą odbierane z procesów nadrzędnych. Przed użyciem otrzymanego pliku do testowania bieżącej aplikacji dane należy zweryfikować krzyżowo, aby uniknąć ponownego wykonania i przeróbki.

Podsumowanie

Testowanie na komputerze mainframe przypomina każdą inną procedurę testowania, począwszy od zbierania wymagań, projektowania testów, wykonywania testów i raportowania wyników.
Aby skutecznie przetestować aplikację, tester powinien uczestniczyć w spotkaniach projektowych zaplanowanych przez zespoły deweloperskie i biznesowe.
Tester musi koniecznie zapoznać się z różnymi funkcjami testowymi komputera mainframe. Podobnie jak nawigacja na ekranie, tworzenie plików i PDS, zapisywanie wyników testów itp. przed rozpoczęciem cyklu testowego.
Testowanie aplikacji na komputerze mainframe to proces czasochłonny. Należy przestrzegać jasnego harmonogramu testów w zakresie projektowania testów, konfiguracji danych i wykonywania.
Testy wsadowe i testy online powinny być przeprowadzane skutecznie, nie pomijając żadnej funkcjonalności wymienionej w dokumencie wymagań i nr Przypadek testowy należy oszczędzić.

Możesz lubić: