Тестване на мейнфрейм – пълен урок
Томас Хамилтън
Преди да научим концепциите за тестване на мейнфрейм, нека научим
Какво е мейнфрейм?
Мейнфреймът е високопроизводителна и високоскоростна компютърна система. Използва се за по-мащабни изчислителни цели, които изискват голяма наличност и сигурност. Използва се най-вече в сектори като финанси, застраховане, търговия на дребно и други критични области, където огромни данни се обработват многократно.
Тестване на мейнфрейм
Тестване на мейнфрейм е процес на тестване на софтуерни приложения и услуги, базирани на мейнфрейм системи. Целта на тестването на мейнфрейм е да се гарантира производителността, надеждността и качеството на софтуерното приложение или услуга чрез методи за проверка и валидиране и проверка дали е готово за внедряване.
Докато извършва тестване на мейнфрейм, тестерът трябва да знае само за навигациите на екраните на CICS. Те са създадени по поръчка за специфични приложения. Всякакви промени, направени в кода в COBOL, JCL и др. Тестерът не трябва да се тревожи за емулатора, настроен на машината. Промените, които работят на един терминален емулатор, ще работят и на други.
- Приложението за мейнфрейм (иначе наричано партида от задания) се тества спрямо тестовите случаи, разработени с помощта на изисквания
- Тестването на мейнфрейм обикновено се извършва върху внедрения код, като се използват различни комбинации от данни, зададени във входния файл.
- Приложенията, които работят на мейнфрейм, могат да бъдат достъпни чрез терминален емулатор. Емулаторът е единственият софтуер, който трябва да бъде инсталиран на клиентската машина.
Атрибути на мейнфрейм
- Виртуално съхранение
- Това е техника, която позволява на процесор да симулира основно хранилище, което е по-голямо от действителното количество реално хранилище.
- Това е техника за ефективно използване на паметта за съхраняване и изпълнение на различни по размер задачи.
- Той използва дисково съхранение като разширение на реалното хранилище.
- Мултипрограмиране
- Компютърът изпълнява повече от една програма едновременно. Но във всеки един момент само една програма може да контролира процесора.
- Това е средство, предоставено за ефективно използване на процесора.
- Пакетна обработка
- Това е техника, чрез която всяка задача се изпълнява в единици, известни като работни места.
- Едно задание може да накара една или повече програми да се изпълнят в последователност.
- Планировчикът на задачи взема решение за реда, в който трябва да се изпълняват задачите. За да се увеличи максимално средната производителност, задачите се планират според техния приоритет и клас.
- Необходимата информация за пакетна обработка се предоставя чрез JCL (JOB CONTROL LANGUAGE). JCL описва пакетната работа – необходимите програми, данни и ресурси.
- Споделяне на времето
- В системата за споделяне на време всеки потребител има достъп до системата чрез крайното устройство. Вместо да изпраща задачи, които са планирани за по-късно изпълнение, потребителят въвежда команди, които се обработват незабавно.
- Следователно това се нарича „интерактивна обработка“. Позволява на потребителя да взаимодейства директно с компютъра.
- Обработката за споделяне на време е известна като „Обработка на преден план“, а обработката на пакетно задание е известна като „Обработка във фонов режим“.
- Навиващи
- SPOOLing означава Едновременна периферия Operaции онлайн.
- Устройството SPOOL се използва за съхраняване на изхода на програмата/приложението. Спулираният изход се насочва към изходни устройства като принтер (ако е необходимо).
- Това е съоръжение, използващо предимството на буферирането за ефективно използване на изходните устройства.
Класификация на ръчното тестване в мейнфрейм
Основна рамка Ръчно тестване могат да бъдат класифицирани в два типа:
1. Пакетно тестване на работа -
- Процесът на тестване включва изпълнение на пакетни задачи за функционалността, внедрена в текущата версия.
- Резултатът от теста, извлечен от изходните файлове и базата данни, се проверява и записва.
2. Онлайн тестване -
- Онлайн тестването се отнася до тестване на CICS екрани, което е подобно на тестването на уеб страницата.
- Функционалността на съществуващите екрани може да се промени или да се добавят нови екрани.
- Различни приложения могат да имат екрани за запитване и екрани за актуализиране. Функционалността на тези екрани трябва да бъде проверена като част от онлайн тестването.
Как да направите тестване на мейнфрейм
- Бизнес екипът изготвя необходимите документи. Което определя как даден елемент или процес ще бъдат модифицирани в цикъла на освобождаване.
- Тестващият екип и разработката получават документа с изискванията. Те ще разберат колко процеси ще бъдат засегнати от промяната. Обикновено в едно издание само 20-25% от приложението е засегнато директно от персонализираното изискване. Останалите 75% от изданието ще бъдат за функционалности извън кутията, като тестване на приложения и процеси.
- И така, мейнфрейм приложение трябва да се тества в две части:
- Изисквания за тестване – Тестване на приложението за функционалността или промяната, спомената в документа с изискване.
- Тестване на интеграция – Тестване на целия процес или друго приложение, което получава или изпраща данни към засегнатото приложение. Тестване на регресия е основният фокус на тази тестова дейност.
Инструменти за тестване на мейнфрейм автоматизация
По-долу е даден списък с инструменти, които могат да се използват за мейнфрейм Тестване на автоматизацията.
- REXX
- Excel
- QTP
Методология при тестване на мейнфрейми
Нека разгледаме един пример: Застрахователна компания XYZ има модул за записване на членове. Той взема данни както от екрана за записване на членове, така и от офлайн записване. Както обсъдихме по-рано, са необходими два подхода за тестване на мейнфрейм, онлайн тестване и пакетно тестване.
- Онлайн тестване се извършва на екрана за записване на членове. Точно като уеб страница, базата данни се валидира с данни, въведени през екраните.
- Офлайн записване може да бъде регистрация на хартия или регистрация на уебсайт на трета страна. Офлайн данните (наричани още партида) ще бъдат въведени в базата данни на компанията чрез пакетни задания. Входящият плосък файл се подготвя според предписания формат на данните и се подава към последователността от пакетни задания. Така че за тестване на мейнфрейм приложения можем да използваме следния подход.
- Първата задача в реда от партидни задачи потвърждава въведените данни. Да кажем например специален знак, букви в полета само с числа и т.н.
- Второто задание валидира последователността на данните въз основа на бизнес условията. Например записването на дете не трябва да съдържа зависими данни, пощенски код на член (който не е достъпен за обслужване от записания план) и т.н.
- Третата задача променя данните във формат, който може да бъде въведен в базата данни. Например изтриване на името на плана (базата данни ще съхранява само идентификатор на план и име на застрахователен план), добавяне на дата на въвеждане и т.н.
- Четвъртата задача зарежда данните в базата данни.
- Пакетно тестване на работа се извършва на този процес в две фази –
- Всяка работа се валидира отделно и
- Интеграцията между заданията се валидира чрез предоставяне на входен плосък файл към първото задание и валидиране на базата данни. (Междинните резултати трябва да бъдат валидирани за допълнително внимание)
Следният метод е следван за тестване на мейнфрейм:
Стъпка 1) Шейкдаун/Тестване на дим
Основният фокус на този етап е да се потвърди дали внедреният код е в правилната тестова среда. Той също така гарантира, че няма критични проблеми с кода.
Стъпка 2) Тестване на системата
По-долу са видовете тестове, извършени като част от системното тестване.
- Пакетно тестване – Това тестване ще бъде извършено чрез валидиране на резултатите от теста на изходните файлове и промените в данните, извършени от партидните задания в обхвата на тестване и тяхното записване.
- Онлайн тестване – Това тестване ще се извърши в предния край на мейнфрейм приложението. Тук приложението се тества за правилно поле за въвеждане като застрахователен план, лихва по плана и т.н.
- Онлайн тестване на пакетна интеграция – Това тестване ще бъде направено на системи с пакетни процеси и онлайн приложение. Потокът от данни и взаимодействието между онлайн екраните и пакетните задания са валидирани.
(Пример за този вид тестване – Помислете за актуализация на подробностите на плана, като увеличение на лихвения процент. Промяната на лихвите се извършва на екран за актуализиране и подробностите за баланса на засегнатите сметки ще бъдат променени само чрез партидна работа всяка вечер. Тестването в този случай ще бъде направено чрез валидиране на екрана с подробности за плана и стартиране на пакетно задание за актуализиране на всички акаунти).
- Тестване на бази данни – Базите данни, в които данните от мейнфрейм приложението (IMS, IDMS, DB2, VSAM/ISAM, последователни набори от данни, GDG) са валидирани за тяхното оформление и съхранение на данни.
Стъпка 3) Система Тестване на интеграцията
Основната цел на това тестване е да се потвърди функционалността на системите, които взаимодействат с тестваната система.
Тези системи не са пряко засегнати от изискванията. Те обаче използват данни от тестваната система. Важно е да тествате интерфейса и различните типове съобщения (като успешна работа, неуспешна работа, актуализирана база данни и т.н.), които могат да протичат между системите и произтичащите от това действия, предприети от отделните системи.
Видовете тестове, извършвани на този етап, са
- Пакетно тестване
- Онлайн тестване
- Онлайн – Тестване на пакетно интегриране
Стъпка 4) Тестване на регресия
Регресионното тестване е обичайна фаза във всеки тип проект за тестване. Това тестване в мейнфрейми гарантира, че пакетните задания и онлайн екраните, които не взаимодействат пряко с тестваната система (или не влизат в обхвата на изискванията), не са засегнати от текущото издание на проекта.
За да има ефективно регресионно тестване, трябва да бъде избран определен набор от тестови случаи в зависимост от тяхната сложност и трябва да се създаде регресионно легло (хранилище на тестови случаи). Този набор трябва да се актуализира всеки път, когато има нова функционалност, пусната в изданието.
Стъпка 5) Тестване на производителността
Това тестване се прави, за да се идентифицират тесните места в области с голям удар, като данни от предния край, надграждане на онлайн бази данни и да се проектира мащабируемостта на приложението.
Стъпка 6) Тестване на сигурността
Това тестване се прави, за да се оцени колко добре е проектирано и разработено приложението за противодействие на атаки срещу сигурността.
Трябва да се направи двукратно тестване на сигурността на системата – сигурност на мейнфрейм и сигурност на мрежата.
Характеристиките, които трябва да бъдат тествани са
- Integrity
- Поверителност
- Упълномощаване
- заверка
- Наличност
Стъпки, включени в пакетното тестване
- След като QA екипът получи одобрения пакет (пакетът съдържа процедури, JCL, контролни карти, модули и т.н.), тестерът трябва да прегледа и извлече съдържанието в PDS, както се изисква.
- Преобразувайте производствения JCL или JCL за разработка в QA JCL, наричан иначе JOB SETUP.
- Копиране на производствен файл и подготовка на тестови файлове.
- За всяка функционалност ще има определена последователност от задачи. (Както е обяснено в примера в раздел Методология в Мейнфрейм). Задачите трябва да бъдат изпратени с помощта на командата SUB с тестовите файлове с данни.
- Проверете междинния файл, за да идентифицирате причините за липсващи или грешни данни.
- Проверете крайния изходен файл, базата данни и Spool, за да потвърдите резултатите от теста.
- Ако заданието е неуспешно, макарата ще има причината за неуспеха на заданието. Отстранете грешката и изпратете отново заданието.
Отчитане на теста – дефект трябва да се регистрира, ако действителният резултат се отклонява от очаквания.
Стъпки, включени в онлайн тестването
- Изберете онлайн екрана в тестова среда.
- Тествайте всяко поле за приемливи данни.
- Тествайте Сценарий на теста на екрана.
- Проверете базата данни за актуализации на данните от онлайн екрана.
Отчитане на теста – Дефектът трябва да се регистрира, ако действителният резултат се отклонява от очаквания.
Стъпки, включени в онлайн – тестване на пакетна интеграция
- Изпълнете работата в a Тестова среда и валидирайте данните на онлайн екраните.
- Актуализирайте данните на онлайн екраните и проверете дали партидното задание се изпълнява правилно с актуализираните данни.
Команди, използвани при тестване на мейнфрейм
- ИЗПРАЩАНЕ – Изпратете фонова работа.
- CANCEL – Отменя фонова работа.
- ALLOCATE – Разпределяне на набор от данни
- COPY – Копиране на набор от данни
- RENAME – Преименуване на набор от данни
- DELETE – Изтриване на набор от данни
- JOB SCAN – За свързване на JCL с програмата, библиотеките, файла и т.н., без да се изпълнява.
Има много други команди, използвани при необходимост, но те не са толкова чести.
Предварителни условия за започване на тестване на мейнфрейм
Основните подробности, необходими за тестване на мейнфрейм, са:
- ID за влизане и парола за влизане в приложението.
- Кратки познания за ISPF командите.
- Имена на файловете, файлов квалификатор и техните типове.
Преди да започнете тестване на мейнфрейм, аспектите по-долу трябва да бъдат проверени.
- Работа
- Извършете сканиране на задание (команда – JOBSCAN), за да проверите за грешки, преди да го изпълните.
- Параметърът CLASS трябва да бъде насочен към тестовия клас.
- Насочете изхода на заданието към макара или JHS или както се изисква, като използвате параметър MSGCLASS.
- Пренасочване на имейла в заданието към спулинг или тестов идентификатор на поща.
- Коментирайте FTP стъпките за първоначално тестване и след това насочете заданието към тестов сървър.
- В случай че в заданието се генерира IMR (запис за управление на инциденти), просто добавете коментар „ЦЕЛ НА ТЕСТИВАНЕТО“ в заданието или картата с параметри.
- Всички производствени библиотеки в заданието трябва да бъдат променени и насочени към тестови библиотеки.
- Работата не трябва да се оставя без надзор.
- За да предотвратите изпълнението на заданието в безкраен цикъл в случай на грешка, трябва да се добави параметър TIME с определено време.
- Запазете резултата от заданието, включително макарата. Макарата може да бъде запазена с помощта на XDC.
- досие
- Създайте тестов файл само с необходимия размер. Използвайте GDG (групи данни за генериране – файлове със същото име, но с последователни номера на версията – MYLIB.LIB.TEST.G0001V00,MYLIB.LIB.TEST.G0002V00 и т.н.), когато е необходимо, за да съхранявате данни в последователни файлове с едно и също име.
- Параметърът DISP (Разпореждане – описва системата за запазване или изтриване на набора от данни след нормално или необичайно прекратяване на стъпката или заданието) за файловете трябва да бъде кодиран правилно.
- Уверете се, че всички файлове, използвани за изпълнение на задание, са запазени и затворени правилно, за да предотвратите преминаването на заданието в режим HOLD.
- Докато тествате с помощта на GDG, уверете се, че е насочена правилната версия.
- База данни
- Докато изпълнявате заданието или онлайн програмата, уверете се, че нежеланите данни не са вмъкнати, актуализирани или изтрити.
- Също така се уверете, че правилният DB2 регион се използва за тестване.
- Тестови случаи
- Винаги тествайте за гранични условия като – празен файл, обработка на първи запис, обработка на последен запис и т.н.
- Винаги включвайте както положителни, така и отрицателни условия на теста.
- В случай, че в програмата се използват стандартни процедури като рестартиране на контролна точка, премахване на модули, контролни файлове и т.н., включете тестови случаи, за да потвърдите дали модулите са били използвани правилно.
- Данни от теста
- Настройката на тестовите данни трябва да се извърши преди началото на тестването.
- Никога не променяйте данните в тестовия регион, без да уведомите. Може да има други екипи, работещи със същите данни, и техният тест ще се провали.
- В случай, че производствените файлове са необходими по време на изпълнението, трябва да се получи подходящо разрешение преди копирането или използването им.
Най-добри практики
- В случай на пакетно изпълнение на задание, MAX CC 0 е индикатор, че заданието е изпълнено успешно. Това не означава, че функционалността работи добре. Задачата ще се изпълнява успешно дори когато изходът е празен или не според очакванията. Така че винаги се очаква да се проверяват всички резултати, преди да се обяви работата за успешна.
- Винаги е добра практика да правите тестова работа на сухо. Сухият цикъл се извършва с празни входни файлове. Този процес трябва да се следва за работните места, които са засегнати от промените, направени за тестовия цикъл.
- Преди началото на тестовия цикъл настройката на тестовото задание трябва да бъде направена много предварително. Това ще помогне за откриването на всяка грешка в JCL предварително, като по този начин спестява време по време на изпълнение.
- Докато осъществявате достъп до DB2 таблици чрез SPUFI (Опция на емулатора за достъп до DB2 таблици), винаги задавайте автоматично поемане като „НЕ“, за да избегнете случайни актуализации.
- Наличието на тестови данни е основното предизвикателство при груповото тестване. Необходимите данни трябва да бъдат създадени много преди тестовия цикъл и трябва да бъдат проверени за пълнота.
- Някои онлайн транзакции и пакетни задания могат да записват данни в MQ (опашка за съобщения) за предаване на данни към други приложения. Ако данните не са валидни, това може да деактивира/спре MQ, това ще повлияе на целия процес на тестване. Добра практика е да проверите дали MQ работят добре след тестване.
Предизвикателства при тестване на мейнфрейм и отстраняване на неизправности
| Предизвикателства | Подход |
|---|---|
| Непълни/неясни изисквания Може да има достъп до ръководство за потребителя/ръководство за обучение, но те не са същите като документираните изисквания. |
Тестерите трябва да бъдат включени в SDLC от фазата на изискванията нататък. Това ще помогне да се провери дали изискванията могат да бъдат тествани. |
| Настройка на данни/Идентификация Възможно е да има ситуации, при които съществуващите данни трябва да се използват повторно според изискването. Понякога е трудно да се идентифицират необходимите данни от съществуващите данни. |
За настройка на данни могат да се използват собствени инструменти според нуждите. За извличане на съществуващи данни заявките трябва да бъдат изградени предварително. В случай на затруднение може да се отправи заявка към екипа за управление на данни за създаване или клониране на необходимите данни. |
| Настройка на работа След като заданията бъдат извлечени в PDS, заданието трябва да бъде настроено в QA региона. Така че заданията да не се подават с производствен квалификатор или подробности за пътя. | Инструментите за настройка на работа трябва да се използват, за да се преодолеят човешките грешки, допуснати по време на настройката. |
| Ad-hoc заявка Възможно е да има ситуации, когато трябва да се поддържа тестване от край до край поради проблем в проблеми с приложението нагоре или надолу по веригата. Тези заявки увеличават времето и усилията в цикъла на изпълнение. | Използването на скриптове за автоматизация, скриптове за регресия и скелетни скриптове може да помогне за намаляване на разходите за време и усилия. |
| Навременни публикации за промяна на обхвата Може да има ситуация, при която въздействието на кода може напълно да промени външния вид и усещането на системата. Това може да изисква промяна в тестовите случаи, скриптовете и данните. |
Трябва да има процес на управление на промените в обхвата и анализ на въздействието. |
Често срещани Abends
- S001 – Възникна I/O грешка.
Причина – Четене в края на файла, грешка в дължината на файла, опит за запис във файл само за четене.
- S002 – Невалиден I/O запис.
Причина – Опит за запис на запис, по-дълъг от дължината на записа.
- S004 – Възникна грешка по време на ОТВАРЯНЕ.
Причина – Невалиден DCB
- S013 – Грешка при отваряне на набор от данни.
Причина – PDS член не съществува, дължината на записа в програмата не съответства на действителната дължина на записа.
- S0C1 – Operaция Изключение
Причина – Не може да се отвори файл, липсва DD карта
- S0C4 – Изключение на защитата/ нарушение на съхранението
- Причина – Опит за достъп до хранилището, което не е достъпно за програмата.
- S0C7 – Изключение при проверка на програмата – Данни
- Причина – Промяна в оформлението на записа или оформлението на файла.
- Sx22 – Задачата е отменена
- S222 – Задачата е отменена от потребителя без дъмп.
- S322 – Времето за задание или стъпка надхвърли определеното ограничение или програмата е в цикъл или параметърът за време е недостатъчен.
- S522 – Изчакване на TSO сесията.
- S806 – Не може да се свърже или зареди.
Причина – Идентификационният номер на задание не може да намери посочения модул за зареждане.
- S80A – Няма достатъчно виртуално хранилище за удовлетворяване на заявки GETMAIN или FREEMAIN.
- S913 – Опит за достъп до набора от данни, за който потребителят не е оторизиран.
- Sx37 – Не може да се разпредели достатъчно място за съхранение на набора от данни.
Error Assist – Много популярен инструмент за получаване на подробна информация за различни видове прекъсвания.
Често срещан проблем по време на тестване на мейнфрейм
- Job Abends – За успешно завършване на работата, трябва да проверите данните, входния файл и модулите, присъстващи на конкретното място или не. Прекъсванията могат да възникнат поради множество причини, като най-често срещаните са – невалидни данни, неправилно поле за въвеждане, несъответствие на дата, екологични проблеми и др.
- Изходният файл е празен– Въпреки че заданието може да се изпълнява успешно (MaxCC 0), изходът може да не е според очакванията. Така че преди да премине всеки тестов случай, тестерът трябва да се увери, че изходът е кръстосано проверен. Едва тогава продължете по-нататък.
- Входният файл е празен – В някои приложения файловете ще бъдат получени от процесите нагоре по веригата. Преди да използвате получения файл за тестване на текущото приложение, данните трябва да бъдат кръстосано проверени, за да се избегне повторно изпълнение и преработка.
Oбобщение
- Тестването на мейнфрейм е като всяка друга процедура за тестване, като се започне от събиране на изисквания, дизайн на теста, изпълнение на теста и отчитане на резултатите.
- За да тества приложението ефективно, тестерът трябва да участва в дизайнерски срещи, насрочени от екипи за разработка и бизнес.
- Задължително е тестерът да свикне с различни функции за тестване на мейнфрейм. Като навигация на екрана, създаване на файл и PDS, запазване на резултатите от теста и т.н. преди началото на тестовия цикъл.
- Тестването на мейнфрейм приложения е отнемащ време процес. Трябва да се следва ясен график за тестване за проектиране на теста, настройка на данни и изпълнение.
- Пакетното тестване и онлайн тестването трябва да се извършват ефективно, без да се пропуска каквато и да е функционалност, спомената в документа с изискване, и не Тестов случай трябва да бъдат пощадени.