Тестване на мейнфрейм

Преди да научим концепции за тестване на мейнфрейм, нека научим

Какво е Mainframe?

Основният компютър е високопроизводителна и високоскоростна компютърна система. Използва се за по-мащабни изчислителни цели, които изискват голяма наличност и сигурност. Използва се най-вече в сектори като финанси, застраховане, търговия на дребно и други критични области, където огромни данни се обработват многократно.

Mainframe Testing е процес на тестване на софтуерни приложения и услуги, базирани на Mainframe Systems. Целта на мейнфрейм тестването е да осигури производителността, надеждността и качеството на софтуерното приложение или услуга чрез методи за проверка и валидиране и да провери дали е готова за внедряване.

Докато извършва тестване на Mainframe, тестерът трябва да знае само за навигацията на екраните CICS. Те са създадени по поръчка за конкретни приложения. Всички промени, направени в кода в тестера COBOL, JCL и др., Не трябва да се притесняват от емулатора, настроен на машината. Промените, които работят на един терминален емулатор, ще работят и на други.

Приложението Mainframe (иначе наречено пакетно задание) се тества спрямо тестовите случаи, разработени с използване на изисквания
Тестването на мейнфрейм обикновено се извършва върху внедрения код, като се използват различни комбинации от данни, зададени във входния файл.
Приложенията, които се изпълняват на мейнфрейма, могат да бъдат достъпни чрез емулатор на терминал. Емулаторът е единственият софтуер, който трябва да бъде инсталиран на клиентската машина.

В този урок за начинаещи ще научите -

Основни атрибути
Класификация на ръчното тестване в мейнфрейм
Как се прави тестване на мейнфрейм
Инструменти за тестване на автоматизация на мейнфрейм
Методология в мейнфрейм тестване
Стъпки, включени в тестването на партиди
Стъпки, включени в онлайн тестване
Стъпки, включени в тестване за онлайн - пакетна интеграция
Команди, използвани при тестване на мейнфрейм
Предварителни условия за започване на тестване на мейнфрейм
Най-добри практики
Предизвикателства и отстраняване на неизправности при тестване на мейнфрейм
Често срещани Abends
Често срещан проблем по време на тестване на мейнфрейм

Основни атрибути

Виртуално съхранение
1. Това е техника, която позволява на процесора да симулира основно съхранение, което е по-голямо от действителното количество реално съхранение.
2. Това е техника за ефективно използване на паметта за съхраняване и изпълнение на различни по размер задачи.
3. Той използва дисково хранилище като разширение на реалното хранилище.
Мултипрограмиране
1. Компютърът изпълнява повече от една програма едновременно. Но във всеки един момент само една програма може да има контрол върху процесора.
2. Това е средство за ефективно използване на процесора.
Партидна обработка
1. Това е техника, чрез която всяка задача се изпълнява в единици, известни като работни места.
2. Заданието може да доведе до изпълнение на една или повече програми в последователност.
3. Планировчикът на задачи взема решение относно реда, в който заданията трябва да бъдат изпълнени. За да се увеличи средната производителност, заданията се планират според техния приоритет и клас.
4. Необходимата информация за партидна обработка се предоставя чрез JCL (ЕЗИК ЗА КОНТРОЛ НА РАБОТА). JCL описва пакетното задание - необходими програми, данни и ресурси.
Споделяне на времето
1. В система за споделяне на времето всеки потребител има достъп до системата чрез терминалното устройство. Вместо да изпраща задания, които са планирани за по-късно изпълнение, потребителят въвежда команди, които се обработват незабавно.
2. Следователно това се нарича "Интерактивна обработка". Позволява на потребителя да взаимодейства директно с компютъра.
3. Обработката с дял от времето е известна като „Обработка на преден план“, а обработката на партидно задание е известна като „Обработка на фона“.
Намотаване
1. SPOOLing означава едновременни периферни операции онлайн .
2. Устройството SPOOL се използва за съхраняване на изхода на програма / приложение. Намалената продукция е насочена към изходни устройства като принтер (ако е необходимо).
3. Това е съоръжение, използващо предимството на буферирането, за да се използват ефективно изходните устройства.

Класификация на ръчното тестване в мейнфрейм

Основното ръчно тестване може да бъде класифицирано в два вида:

Партидно тестване на работа -
- Процесът на тестване включва изпълнение на групови задачи за функционалността, внедрена в текущата версия.
- Резултатът от теста, извлечен от изходните файлове и базата данни, се проверява и записва.
Онлайн тестване -
- Онлайн тестване се отнася до тестване на CICS екрани, което е подобно на тестване на уеб страницата.
- Функционалността на съществуващите екрани може да бъде променена или да бъдат добавени нови екрани.
- Различните приложения могат да имат екрани за запитвания и екрани за актуализиране. Функционалността на тези екрани трябва да бъде проверена като част от онлайн тестването.

Как се прави тестване на мейнфрейм

Бизнес екипът изготвя документи за изисквания. Което определя как даден елемент или процес ще бъде модифициран в цикъла на освобождаване.
Екипът за тестване и разработката получават документа с изискванията. Те ще разберат колко процеси ще бъдат засегнати от промяната. Обикновено в дадена версия само 20-25% от приложението се влияе директно от персонализираното изискване. Останалите 75% от изданието ще бъдат за стандартните функционалности като тестване на приложения и процеси.
И така, приложението Mainframe трябва да бъде тествано от две части:
1. Изисквания за тестване - Тестване на приложението за функционалността или промяната, посочена в документа за изискванията.
2. Тестване на интеграция - Тестване на целия процес или друго приложение, което получава или изпраща данни до засегнатото приложение. Регресионното тестване е основният фокус на тази тестова дейност.

Инструменти за тестване на автоматизация на мейнфрейм

По-долу е списъкът с инструменти, които могат да се използват за тестване на автоматизация на мейнфрейм.

REXX
Excel
QTP

Методология в мейнфрейм тестване

Нека разгледаме един пример: Застрахователната компания XYZ има модул за записване на членове. Взема данни както от екрана за регистрация на членове, така и от офлайн записване. Както обсъждахме по-рано, са необходими два подхода за Mainframe тестване, онлайн тестване и тестване на партиди.

Онлайн тестването се извършва на екрана за регистрация на членове. Подобно на уеб страница, базата данни се потвърждава с данни, въведени през екраните.
Офлайн записването може да бъде записване на хартиен носител или записване на уебсайт на трета страна. Офлайн данните (наричани също партидни) ще бъдат въведени в базата данни на компанията чрез пакетни задания. Входящият плосък файл се изготвя съгласно предписания формат на данните и се подава към последователността на партидните задачи. Така че за тестване на приложения на мейнфрейм можем да използваме следния подход.
- Първото задание в реда на пакетни задания проверява въведените данни. Да кажем например специален знак, азбуки в полета само с числа и т.н.
- Втората работа потвърждава последователността на данните въз основа на бизнес условията. Например записването на дете не трябва да съдържа зависими данни, пощенски код на член (който не е достъпен за обслужване от записания план) и т.н.
- Третото задание променя данните във формата, който може да бъде въведен в базата данни. Например изтриване на името на плана (базата данни ще съхранява само ID на плана и името на застрахователния план), добавяне на дата на влизане и т.н.
- Четвъртото задание зарежда данните в базата данни.
Партидното тестване се извършва по този процес на две фази -
- Всяко задание се валидира отделно и
- Интеграцията между заданията се проверява чрез предоставяне на входен плосък файл на първата работа и валидиране на базата данни. (Междинните резултати трябва да бъдат валидирани за допълнително внимание)

Следва методът, използван за тестване на мейнфрейм:

Стъпка 1) : Shakedown / Smoke Testing

Основният фокус на този етап е да провери дали внедреният код е в правилната тестова среда. Той също така гарантира, че няма критични проблеми с кода.

Стъпка 2) : Тестване на системата

По-долу са видовете тестове, извършени като част от системното тестване.

Пакетно тестване - Това тестване ще се извърши чрез валидиране на резултатите от теста на изходните файлове и промените в данните, извършени от пакетните задания в обхвата на тестване и записването им.
Онлайн тестване - Това тестване ще се извърши на предния край на приложението на мейнфрейма. Тук приложението е тествано за правилно поле за влизане като застрахователен план, лихва по плана и т.н.
Тестване на онлайн- партидна интеграция - Това тестване ще се извърши в системите, имащи пакетни процеси и онлайн приложение. Потокът от данни и взаимодействието между онлайн екраните и пакетните задания се потвърждават.
( Пример за този тип тестване - Помислете за актуализация на подробности за плана, като например увеличаване на лихвения процент. Промяната на лихвата се извършва на екрана за актуализация, а данните за баланса на засегнатите акаунти ще бъдат променени само от всяка партидна работа. Тестване в този случай ще бъде направено чрез валидиране на екрана с подробности за плана и стартиране на пакетното задание за актуализиране на всички акаунти).
Тестване на база данни - базите данни, в които данните от приложението на мейнфрейм (IMS, IDMS, DB2, VSAM / ISAM, последователни набори от данни, GDG) се валидират за тяхното оформление и съхранение на данните.

Стъпка 3) : Тестване на системната интеграция

Основната цел на това тестване е да провери функционалността на системите, които взаимодействат с тестваната система.

Тези системи не са пряко засегнати от изискванията. Те обаче използват данни от тестваната система. Важно е да тествате интерфейса и различните видове съобщения (като Job Successful, Job Failed, Database updated и т.н.), които могат да преминат между системите и произтичащите от това действия, предприети от отделните системи.

Видовете тестове, извършени на този етап, са

Партидно тестване
Онлайн тестване
Онлайн - тестване на партидна интеграция

Стъпка 4) : Тестване на регресия

Регресионното тестване е често срещана фаза във всеки тип тестови проекти. Това тестване в Mainframes гарантира, че пакетните задания и онлайн екраните, които не взаимодействат пряко с тестваната система (или не попадат в обхвата на изискванията), не са засегнати от текущата версия на проекта.

За да има ефективно регресивно тестване, определен набор от тестови случаи трябва да бъде включен в списъка в зависимост от тяхната сложност и трябва да се създаде регресионно легло (хранилище за тестови случаи). Този комплект трябва да се актуализира винаги, когато има нова функционалност, пусната в изданието.

Стъпка 5) : Тестване на производителността

Това тестване се прави, за да се идентифицират тесните места в силно засегнатите области като данни от предния край, надграждане на онлайн бази данни и да се проектира мащабируемостта на приложението.

Стъпка 6) : Тестване на сигурността

Това тестване се прави, за да се оцени доколко приложението е проектирано и разработено за противодействие на атаките срещу защита.

В системата трябва да се направят двукратни тестове за сигурност - Системна защита и Мрежова сигурност.

Характеристиките, които трябва да бъдат тествани, са

Интегритет
Поверителност
Разрешение
Удостоверяване
Наличност

Стъпки, включени в тестването на партиди

След като екипът за QA получи одобрения пакет (Пакетът съдържа процедури, JCL, контролни карти, модули и др.), Тестерът трябва да визуализира и извлече съдържанието в PDS, както се изисква.
Преобразувайте производствения JCL или JCL за разработка в QA JCL, иначе наречен JOB SETUP.
Копиране на производствен файл и подготовка на тестови файлове.
За всяка функционалност ще има определена последователност от задачи. (Както е обяснено в примера в Методология в раздел Mainframe). Работните места трябва да бъдат изпратени с помощта на командата SUB с файловете с тестови данни.
Проверете междинния файл, за да идентифицирате причините за липсващи или грешни данни.
Проверете окончателния изходен файл, базата данни и макарата, за да потвърдите резултатите от теста.
Ако работата не успее, макарата ще има причината за неуспеха на работата. Отстранете грешката и изпратете отново заданието.

Отчитане на теста - Дефектът трябва да се регистрира, ако действителният резултат се отклонява от очаквания.

Стъпки, включени в онлайн тестване

Изберете екрана Онлайн в тестова среда.
Тествайте всяко поле за приемливи данни.
Тествайте тестовия сценарий на екрана.
Проверете базата данни за актуализации на данните от онлайн екрана.

Отчитане на теста - Дефектът трябва да се регистрира, ако действителният резултат се отклонява от очаквания.

Стъпки, включени в тестване за онлайн - пакетна интеграция

Изпълнете заданието в тестова среда и проверете данните на онлайн екраните.
Актуализирайте данните на онлайн екраните и проверете дали пакетната задача се изпълнява правилно с актуализираните данни.

Команди, използвани при тестване на мейнфрейм

ПОДАВАНЕ - Изпратете фоново задание.
ОТМЕНЯ - анулиране на фонова работа.
ALLOCATE - Разпределете набор от данни
КОПИРАНЕ - Копиране на набор от данни
ПРЕИМЕНЯВАНЕ - Преименувайте набора от данни
ИЗТРИВАНЕ - Изтриване на набор от данни
СКАНИРАНЕ НА ЗАДАЧИ - За да свържете JCL с програмата, библиотеките, файла и т.н., без да го изпълнявате.

Има много други команди, използвани при необходимост, но те не са толкова чести.

Предварителни условия за започване на тестване на мейнфрейм

Основните подробности, необходими за тестване на мейнфрейм, са:

Идентификационен номер за вход и парола за влизане в приложението.
Кратки познания за командите на ISPF.
Имена на файловете, квалификаторът на файлове и техните типове.

Преди да започнете тестване на мейнфрейм, следващите аспекти трябва да бъдат проверени.

Работа
1. Направете сканиране на задание (Command - JOBSCAN), за да проверите за грешки, преди да го изпълните.
2. Параметърът CLASS трябва да бъде насочен към тестовия клас.
3. Насочете изхода на заданието в макара или JHS или както се изисква с помощта на параметъра MSGCLASS.
4. Пренасочете имейла в заданието към макарата или тестов ID на поща.
5. Коментирайте FTP стъпките за първоначално тестване и след това насочете заданието към тестов сървър.
6. В случай, че в заданието се генерира IMR (Incident Management record), просто добавете коментар „TESTING PURPOSE“ в заданието или param картата.
7. Всички производствени библиотеки в заданието трябва да бъдат променени и насочени към тестови библиотеки.
8. Работата не трябва да се оставя без надзор.
9. За да се предотврати изпълнението на задачата в безкраен цикъл в случай на грешка, трябва да се добави параметър TIME с определено време.
10. Запазете резултата от заданието, включително макарата. Макарата може да бъде запазена с помощта на XDC.

Файл
1. Създайте само тестов файл с необходимия размер. Използвайте GDG (Генериране на групи данни - Файлове със същото име, но с поредни номера на версиите - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 и т.н.), когато е необходимо, за да съхранявате данни в последователни файлове със същото име.
2. Параметърът DISP (Disposition - описва системата за извършване на запазване или изтриване на набора от данни след нормално или необичайно прекратяване на стъпката или заданието) трябва да бъде кодиран правилно.
3. Уверете се, че всички файлове, използвани за изпълнение на заданието, са запазени и затворени правилно, за да предотвратите преминаването на заданието в HOLD.
4. Докато тествате с помощта на GDG, уверете се, че е посочена правилната версия.
База данни
1. Докато изпълнявате заданието или онлайн програмата, уверете се, че непредвидените данни не са вмъкнати, актуализирани или изтрити.
2. Също така, уверете се, че правилната DB2 област се използва за тестване.
Тестови случаи
1. Винаги тествайте за гранични условия като - празен файл, обработка на първи запис, обработка на последен запис и др.
2. Винаги включвайте както положителни, така и отрицателни условия на теста.
3. В случай, че в програмата се използват стандартни процедури като рестартиране на Check point, Abend Modules, Control files и др., Включват тестови случаи за проверка дали модулите са били използвани правилно.
Данни от теста
1. Настройката на тестовите данни трябва да се извърши преди началото на тестването.
2. Никога не променяйте данните в тестовия регион, без да уведомите. Възможно е да има други екипи, работещи със същите данни, и тестът им да се провали.
3. В случай, че производствените файлове са необходими по време на изпълнението, трябва да се получи подходящо разрешение преди копирането или използването им.

Най-добри практики

В случай на изпълнение на пакетно задание, MAX CC 0 е индикатор, че заданието е изпълнено успешно. Това не означава, че функционалността работи добре. Заданието ще се изпълнява успешно дори когато изходът е празен или не според очакванията. Така че винаги се очаква да проверите всички изходи, преди да обявите работата за успешна.
Винаги е добра практика да се прави суха работа на тестваната работа. Сухият старт се извършва с празни входни файлове. Този процес трябва да се следва за заданията, които са засегнати от промените, направени за тестовия цикъл.
Преди да започне тестовият цикъл, тестовата работа трябва да се извърши предварително. Това ще ви помогне да откриете предварително всяка грешка в JCL, като по този начин ще спестите време по време на изпълнението.
Докато осъществявате достъп до DB2 таблици чрез SPUFI (Опция на емулатора за достъп до DB2 таблици), винаги задавайте автоматично фиксиране като "НЕ", за да избегнете случайни актуализации.
Наличието на тестови данни е основното предизвикателство при груповото тестване. Необходимите данни трябва да бъдат създадени много преди тестовия цикъл и трябва да бъдат проверени за пълнота.
Някои онлайн транзакции и групови задачи могат да записват данни в MQ (Message Queue) за предаване на данни към други приложения. Ако данните не са валидни, те могат да деактивират / спрат MQ, това ще повлияе на целия процес на тестване. Добра практика е да проверите дали MQ работят добре след тестване.

Предизвикателства и отстраняване на неизправности при тестване на мейнфрейм

Предизвикателства	Приближаване
Непълни / неясни изисквания Може да има достъп до ръководство за потребителя / ръководство за обучение, но те не са същите като документираните изисквания.	Тестерите трябва да участват в SDLC от фазата на изискванията нататък. Това ще помогне да се провери дали изискванията са проверими.
Настройка / идентификация на данни Може да има ситуации, при които съществуващите данни трябва да се използват повторно според изискването. Понякога е трудно да се идентифицират необходимите данни от съществуващите данни.	За настройка на данни могат да се използват собствени инструменти според нуждите. За извличане на съществуващи данни, заявките трябва да бъдат изградени предварително. В случай на затруднение може да бъде отправена заявка до екипа за управление на данни за създаване или клониране на необходимите данни.
Настройка на заданието След като задачите бъдат извлечени в PDS, заданието трябва да бъде настроено в QA региона. Така че заданията не се изпращат с производствен квалификатор или подробности за пътя.	Трябва да се използват инструменти за настройка на работа, за да се преодолеят човешки грешки, допуснати по време на настройката.
Ad-hoc заявка Възможно е да има ситуации, когато тестването от край до край трябва да се поддържа поради проблем в приложенията нагоре или надолу по веригата. Тези заявки увеличават времето и усилията в цикъла на изпълнение.	Използването на скриптове за автоматизация, скриптове за регресия и скелети може да помогне за намаляване на времето и усилията.
Навременни издания за промяна на обхвата Възможно е да има ситуация, при която въздействието на кода да промени напълно външния вид и усещането на системата. Това може да изисква промяна на тестови случаи, скриптове и данни.	Трябва да са налице процесът на управление на обхвата и анализ на въздействието.

Често срещани Abends

S001 - Възникна грешка при вход / изход.
Причина - Четене в края на файла, грешка в дължината на файла, опит за запис в файл само за четене.
S002 - Невалиден I / O запис.
Причина - Опитайте се да напишете запис, по-дълъг от дължината на записа.
S004 - Възникна грешка по време на ОТВОРЕНО.
Причина - Невалиден DCB
S013 - Грешка при отваряне на набор от данни.
Причина - членът на PDS не съществува, дължината на записа в програмата не съответства на действителната дължина на записа.
S0C1 - Изключение от операцията
Причина-Не може да се отвори файл, липсва DD карта
S0C4 - Изключение за защита / нарушение на съхранението
Причина - Опит за достъп до хранилището, недостъпно за програмата.
SC07 - Изключение за проверка на програмата - Данни
Причина - Промяна в оформлението на записа или оформлението на файла.
Sx22 - Работата е отменена
S222 - Заданието е отменено от потребителя без изхвърляне.
S322 - Времето за работа или стъпка надвишава определената граница или програмата е в цикъл или недостатъчен параметър за време.
S522 - Време за изчакване на сесията на TSO.
S806 -Не може да се свърже или зареди.
Причина - Идентификационното задание не може да намери посочения модул за зареждане.
S80A - Няма достатъчно виртуално хранилище, за да задоволи заявките GETMAIN или FREEMAIN.
S913 - Опит за достъп до набора от данни, който потребителят не е упълномощен.
Sx37 - Не може да разпредели достатъчно място за съхранение на набора от данни.

Помощ за грешки - Много популярен инструмент за получаване на подробна информация за различни видове абени.

Често срещан проблем по време на тестване на мейнфрейм

Отмяна на заданието - За успешното завършване на заданието трябва да проверите данните, входния файл и модулите, присъстващи на конкретното място или не. Abends могат да бъдат изправени по множество причини, като най-често срещаните са - Невалидни данни, Неправилно поле за въвеждане, несъответствие на датата, екологични проблеми и др.

Изходният файл е празен - Въпреки че заданието може да се изпълнява успешно (MaxCC 0), изходът може да не е както се очаква. Така че, преди да премине всеки тест, тестващият трябва да се увери, че изходът е кръстосано проверен. Едва след това продължете по-нататък.
Входният файл е празен - В някои приложения файловете ще се получават от възходящите процеси. Преди да използвате получения файл за тестване на текущо приложение, данните трябва да бъдат кръстосано проверени, за да се избегне повторно изпълнение и преработка.

Резюме:

Тестването на мейнфрейм е като всяка друга процедура за тестване, започвайки от събиране на изисквания, дизайн на теста, изпълнение на теста и отчитане на резултатите.
За да тества ефективно приложението, тестващият трябва да участва в срещи за проектиране, насрочени от екипите за разработка и бизнес.
Задължително е тестерът да свикне с различни функции за тестване на мейнфрейм. Като навигация на екрана, създаване на файлове и PDS, запазване на резултатите от теста и др., Преди да започне тестовият цикъл.
Тестването на приложения на мейнфрейм е процес, който отнема време. Трябва да се следва ясен график на теста за тестовия дизайн, настройката на данните и изпълнението.
Партидното тестване и онлайн тестването трябва да се извършват ефективно, без да се пропуска каквато и да е функционалност, спомената в документа за изискване, и не трябва да се спестяват тестови случаи

Тестване на мейнфрейм - пълен урок

Съдържание:

Какво е Mainframe?