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

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

Какво е мейнфрейм?

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

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

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

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

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

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

Атрибути на мейнфрейм

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

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

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

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

1. Тестване на пакетни задачи —

• Процесът на тестване включва изпълнение на пакетни задачи за функционалността, реализирана в текущата версия.
• Резултатите от теста бяхаtracИзвлечените от изходните файлове и базата данни се проверяват и записват.

2. Онлайн тестване —

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

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

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

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

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

• REXX — скриптовият език, доставян със z/OS, широко използван за управление на повтарящи се задачи и проверки на изхода.
• Excel — използва се с макроси за изграждане, сравняване и отчитане на тестови данни и изходни файлове.
• OpenText UFT Един — настоящото наименование на инструмента, което индустрията все още нарича QTP или QuickTest Professional; той автоматизира екраните на терминали 3270.
• Галаса — отворен код, Тестова рамка за дълбока интеграция на Open Mainframe Project който управлява 3270 екрани, JCL пакетни задачи и Db2 от CI/CD конвейер.
• Тестови пакети за z/OS на доставчици - IBM Ускорителят на тестване за Z и BMC AMI DevX Total Test обхваща COBOL модулно тестване и виртуализирани тестови среди.

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

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

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

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

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

Стъпка 1) Тестване за раздвижване/дим

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

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

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

1. Пакетно тестване — Това тестване се извършва чрез валидиране на резултатите от тестовете върху изходните файлове и промените в данните, направени от пакетните задачи в обхвата на тестването, и записването им.
2. Онлайн тестване — Това тестване се извършва на предния край на мейнфрейм приложението. Тук приложението се тества за коректно въвеждане на полета, като например застрахователен план, лихва по плана и подобни стойности.
3. Онлайн тестване на пакетна интеграция — Това тестване се извършва на системи, които имат както пакетни процеси, така и онлайн приложение. Потокът от данни и взаимодействието между онлайн екраните и пакетните задачи са валидирани.

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

4. Тестване на бази данни — Базите данни, в които се съхраняват данните от мейнфрейм приложението (IMS, IDMS, Db2, VSAM/ISAM, последователни набори от данни, GDG), са валидирани по отношение на тяхното оформление и съхранение на данни.

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

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

Тези системи не са пряко засегнати от изискванията. Те обаче използват данни от тестваната система. Важно е да се тества интерфейс и различните видове съобщения (като „Задачата е успешна“, „Задачата е неуспешна“, „База данни е актуализирана“), които могат да се обменят между системите, и произтичащите от това действия, предприети от отделните системи.

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

1. Пакетно тестване
2. Онлайн тестване
3. Онлайн — Тестване на пакетна интеграция

Стъпка 4) Регресионно тестване

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

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

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

Това тестване се извършва, за да се идентифицират пречките в области с висок риск, като въвеждане на данни от front-end и онлайн актуализации на базата данни, както и да се оцени мащабируемостта на приложението. Дълго изпълняващите се пакетни прозорци обикновено се изследват с... Стресиране спрямо пиковите обеми.

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

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

Трябва да се извърши двойно тестване на сигурността на системата - сигурност на мейнфрейм компютрите и мрежова сигурност.

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

1. Integrity
2. Поверителност
3. Упълномощаване
4. заверка
5. Наличност

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

1. След като екипът по QA получи одобрения пакет (пакетът съдържа процедури, JCL, контролни карти, модули и подобни елементи), тестерът трябва да прегледа и извлече съдържанието в PDS, както се изисква.
2. Конвертирайте производствения JCL или JCL за разработка в QA JCL, наричан още JOB SETUP.
3. Копирайте производствения файл и подгответе тестовите файлове.
4. За всяка функционалност ще бъде дефинирана последователност от задачи (както е обяснено в примера в раздела „Методология при тестване на мейнфрейм системи“). Задачите трябва да бъдат подадени с помощта на командата SUB с файловете с тестови данни.
5. Проверете междинния файл, за да установите причините за липсващи или грешни данни.
6. Проверете крайния изходен файл, базата данни и Spool-а, за да валидирате резултатите от теста.
7. Ако заданието е неуспешно, макарата ще има причината за неуспеха на заданието. Отстранете грешката и изпратете отново заданието.

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

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

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

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

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

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

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

Тези стъпки се управляват от терминала, така че малък речник от команди покрива по-голямата част от деня на тестера.

1. ИЗПРАТИ — Изпратете фонова работа.
2. ОТМЕНЯ — Отмяна на фонова задача.
3. РАЗПРЕДЕЛЕНИЕ — Разпределете набор от данни.
4. COPY — Копиране на набор от данни.
5. ПРЕИМЕНУВАНЕ — Преименуване на набор от данни.
6. ИЗТРИЙ — Изтриване на набор от данни.
7. СКАНИРАНЕ НА ЗАДАНИЕ — Свържете JCL с програмата, библиотеките, файловете и други ресурси, без да го изпълнявате.

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

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

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

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

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

1. Работа
   • Извършете сканиране на задачата (команда — JOBSCAN), за да проверите за грешки, преди да я изпълните.
   • Параметърът CLASS трябва да сочи към тестовия клас.
   • Насочете изхода на заданието към спула или JHS, или както е необходимо, като използвате параметъра MSGCLASS.
   • Пренасочете имейла в заданието към буфер или към тестов имейл идентификатор.
   • Коментирайте стъпките на FTP за първоначално тестване и след това насочете задачата към тестов сървър.
   • В случай че в заданието е генериран IMR (Запис за управление на инциденти), добавете коментара „ЦЕЛ НА ТЕСТВАНЕ“ в заданието или картата с параметри.
   • Всички производствени библиотеки в заданието трябва да бъдат променени и насочени към тестови библиотеки.
   • Работата не трябва да се оставя без надзор.
   • За да се предотврати изпълнението на задачата в безкраен цикъл в случай на грешка, параметърът TIME трябва да бъде добавен с определено време.
   • Запазете резултата от заданието, включително макарата. Макарата може да бъде запазена с помощта на XDC.
2. досие
   • Създайте тестов файл само с необходимия размер. Използвайте GDG (Generation Data Groups — файлове с едно и също име, но с последователни номера на версиите, като например MYLIB.LIB.TEST.G0001V00 и MYLIB.LIB.TEST.G0002V00), когато е необходимо, за да съхранявате данни в последователни файлове с едно и също име.
   • Параметърът DISP (Disposition — указва на системата дали да запази или изтрие набора от данни след нормално или необичайно прекратяване на стъпката или задачата) за файловете трябва да бъде кодиран правилно.
   • Уверете се, че всички файлове, използвани за изпълнение на задачата, са запазени и затворени правилно, за да предотвратите преминаването на задачата в режим ЗАДЪРЖАНЕ.
   • Докато тествате с GDG, уверете се, че е посочена правилната версия.
3. База данни
   • Докато изпълнявате заданието или онлайн програмата, уверете се, че не се въвеждат, актуализират или изтриват нежелани данни.
   • Също така се уверете, че за тестване се използва правилният Db2 регион.
4. Тестови случаи
   • Винаги проверявайте за гранични условия, като например празен файл, обработка на първия запис и обработка на последния запис.
   • Винаги включвайте както положителни, така и отрицателни условия на теста.
   • В случай че в програмата се използват стандартни процедури, като например рестартиране на контролни точки, модули за прекъсване или контролни файлове, включете Тестов случайs, за да се провери дали модулите са използвани правилно.
5. Данни от теста
   • Настройката на тестовите данни трябва да се извърши преди началото на тестването.
   • Никога не променяйте данните в тестовия регион, без да уведомите другите. Възможно е други екипи да работят със същите данни и техните тестове ще се провалят.
   • В случай, че производствените файлове са необходими по време на изпълнението, трябва да се получи подходящо разрешение преди копирането или използването им.

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

1. В случай на пакетно изпълнение на задача, MAX CC 0 е индикатор, че задачата е изпълнена успешно. Това не означава, че функционалността работи добре. Задачата ще се изпълни успешно, дори когато изходът е празен или не е според очакванията. Така че винаги се очаква да се проверят всички изходи, преди да се обяви задачата за успешна.
2. Винаги е добра практика да се направи пробен цикъл на тестваната задача. Пробният цикъл се извършва с празни входни файлове. Този процес трябва да се следва за задачите, които са засегнати от промените, направени по време на тестовия цикъл.
3. Преди началото на тестовия цикъл, настройката на тестовата задача трябва да се извърши достатъчно предварително. Това помага за предварително откриване на евентуални JCL грешки, като по този начин се спестява време по време на изпълнението.
4. Докато осъществявате достъп до Db2 таблици чрез SPUFI (опция на емулатора за достъп до Db2 таблици), винаги задавайте автоматичното потвърждаване на „НЕ“, за да избегнете случайни актуализации.
5. Наличността на тестови данни е основното предизвикателство при пакетното тестване. Необходимите данни трябва да бъдат създадени доста преди тестовия цикъл и трябва да бъдат проверени за пълнота. Tracking тази подготовка в споделена управление на тестове хранилището поддържа регресионното легло и настройката на данните подравнени.
6. Някои онлайн транзакции и пакетни задачи могат да записват данни в MQ (опашки за съобщения) за transmitпрехвърляне на данни към други приложения. Ако данните не са валидни, това може да деактивира или спре MQ-тата и това ще повлияе на целия процес на тестване. Добра практика е да се провери дали MQ-тата работят добре след тестване.

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

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

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

Често срещани Абенди

Когато дадена задача е неуспешна, spool-ът докладва код за прекъсване. Списъкът по-долу обхваща кодовете, с които тестерът на мейнфрейм системи се среща най-често, заедно с обичайната причина.

1. S001 — Възникна входно/изходна грешка.

   Причина — Четене в края на файла, грешка в дължината на файла или опит за запис във файл само за четене.

2. S002 — Невалиден входно/изходен запис.

   Причина — Опит за записване на запис, по-дълъг от дължината на записа.

3. S004 — Възникна грешка по време на ОТВАРЯНЕ.

   Причина — Невалиден дебитен идентификационен номер.

4. S013 — Грешка при отваряне на набор от данни.

   Причина — Членът на PDS не съществува или дължината на записа в програмата не съвпада с действителната дължина на записа.

5. S0C1 - OperaИзключение.

   Причина — Не може да се отвори файл или липсва DD карта.

6. S0C4 — Изключение за защита / нарушение на съхранението.

   Причина — Опит за достъп до хранилище, което не е достъпно за програмата.

7. S0C7 — Изключение от проверка на програмата, данни.

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

8. Sx22 — Работата е отменена.

   Причина — Заданието е прекратено преди завършване; средната цифра показва кой или какво го е отменило.

9. S222 — Заданието е отменено от потребителя без дъмп.
10. S322 — Времето за задача или стъпка е надвишило зададения лимит, програмата е в цикъл или параметърът TIME е недостатъчен.
11. S522 — Време за изчакване на сесията на TSO.
12. S806 — Невъзможно е да се свърже или зареди.

    Причина — Заданието не може да намери посочения модул за зареждане.

13. S80A — Няма достатъчно виртуално хранилище за задоволяване на заявките GETMAIN или FREEMAIN.
14. S913 — Опит за достъп до набор от данни, който потребителят няма право да използва.
15. Sx37 — Не може да се разпредели достатъчно място за съхранение на набора от данни.

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

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

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

Въпроси и Отговори