Тестування мейнфреймів – повний підручник

Перш ніж вивчати концепції тестування мейнфреймів, давайте навчимося

Що таке мейнфрейм?

Мейнфрейм — це високопродуктивна та високошвидкісна комп’ютерна система. Він використовується для більш масштабних обчислювальних цілей, які вимагають високої доступності та безпеки. Він в основному використовується в таких секторах, як фінанси, страхування, роздрібна торгівля та інших критичних сферах, де величезні дані обробляються кілька разів.

Тестування мейнфреймів

Тестування мейнфреймів це процес тестування програмних додатків і послуг на базі систем мейнфреймів. Метою тестування мейнфрейму є забезпечення продуктивності, надійності та якості програмного додатку чи послуги за допомогою методів верифікації та підтвердження та перевірка готовності до розгортання.

Виконуючи тестування мейнфрейму, тестувальник повинен знати лише про навігацію екранів CICS. Вони створені на замовлення для конкретних застосувань. Будь-які зміни, внесені до коду в COBOL, JCL тощо, тестеру не потрібно турбуватися про емулятор, встановлений на машині. Зміни, які працюють на одному емуляторі терміналу, працюватимуть і на інших.

• Мейнфрейм-додаток (інакше званий пакетом завдань) перевіряється на тестові приклади, розроблені з використанням вимог
• Тестування мейнфрейму зазвичай виконується на розгорнутому коді з використанням різних комбінацій даних, встановлених у вхідному файлі.
• До програм, які працюють на мейнфреймі, можна отримати доступ через емулятор терміналу. Емулятор — це єдине програмне забезпечення, яке необхідно інсталювати на клієнтській машині.

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

1. Віртуальне сховище
   1. Це техніка, яка дозволяє процесору імітувати основне сховище, яке перевищує фактичний обсяг реального сховища.
   2. Це техніка ефективного використання пам’яті для зберігання та виконання завдань різного розміру.
   3. Він використовує дискове сховище як розширення реального сховища.
2. Мультипрограмування
   1. Комп’ютер одночасно виконує більше однієї програми. Але в будь-який момент тільки одна програма може контролювати ЦП.
   2. Це засіб, який забезпечує ефективне використання ЦП.
3. Пакетна обробка
   1. Це техніка, за допомогою якої будь-яке завдання виконується в одиницях, відомих як завдання.
   2. Завдання може призвести до послідовного виконання однієї або кількох програм.
   3. Планувальник завдань приймає рішення щодо порядку виконання завдань. Щоб максимізувати середню продуктивність, завдання плануються відповідно до їх пріоритету та класу.
   4. Необхідна інформація для пакетної обробки надається через JCL (JOB CONTROL LANGUAGE). JCL описує пакетне завдання – необхідні програми, дані та ресурси.
4. Розподіл часу
   1. У системі розподілу часу кожен користувач має доступ до системи через термінальний пристрій. Замість надсилання завдань, запланованих для подальшого виконання, користувач вводить команди, які обробляються негайно.
   2. Тому це називається «Інтерактивна обробка». Це дозволяє користувачеві безпосередньо взаємодіяти з комп'ютером.
   3. Обробка з розподілом часу відома як «передня обробка», а пакетна обробка завдань — «фонова обробка».
5. Накрутка
   1. SPOOLing означає Одночасна периферія Operations Online.
   2. Пристрій SPOOL використовується для зберігання результатів програми/додатку. Буферний вихід спрямовується до пристроїв виведення, таких як принтер (за потреби).
   3. Це засіб, який використовує переваги буферизації для ефективного використання пристроїв виведення.

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

мейнфреймів Ручне тестування можна класифікувати на два типи:

1. Пакетне тестування завдань -

• Процес тестування передбачає виконання пакетних завдань для функціональності, реалізованої в поточному випуску.
• Результати тесту, отримані з вихідних файлів і бази даних, перевіряються та записуються.

2. Онлайн тестування -

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

Як проводити тестування мейнфрейму

1. Бізнес-команда готує необхідні документи. Що визначає, як певний елемент або процес буде змінено в циклі випуску.
2. Команда тестування та розробник отримують документ вимоги. Вони з’ясують, на скільки процесів вплинуть зміни. Зазвичай у випуску лише 20-25% додатків безпосередньо впливають настроювані вимоги. Інші 75% випуску будуть призначені для стандартних функцій, таких як тестування програм і процесів.
3. Таким чином, мейнфрейм-додаток потрібно тестувати двома частинами:
   1. Вимоги до тестування – Тестування програми на функціональність або зміни, згадані в документі вимог.
   2. Інтеграція тестування – Тестування всього процесу або іншої програми, яка отримує або надсилає дані в уражену програму. Регресійне тестування є основною метою цієї тестової діяльності.

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

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

• REXX
• перевершувати
• QTP

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

Розглянемо приклад: страхова компанія XYZ має модуль реєстрації учасників. Він отримує дані як з екрана реєстрації учасників, так і з реєстрації в режимі офлайн. Як ми обговорювали раніше, для тестування мейнфрейму використовуються два підходи, онлайн-тестування та пакетне тестування.

• Онлайн тестування виконується на екрані реєстрації учасників. Подібно до веб-сторінки, база даних перевіряється за допомогою даних, введених через екрани.
• Офлайн реєстрація це може бути паперова реєстрація або реєстрація на сторонньому веб-сайті. Дані в автономному режимі (також відомі як пакет) буде введено в базу даних компанії через пакетні завдання. Вхідний плоский файл готується відповідно до встановленого формату даних і подається до послідовності пакетних завдань. Отже, для тестування додатків мейнфрейму ми можемо використовувати наступний підхід.
• Перше завдання в рядку пакетних завдань перевіряє введені дані. Скажімо, наприклад, спеціальні символи, алфавіти в полях лише з числами тощо.
• Друге завдання перевіряє узгодженість даних на основі бізнес-умов. Наприклад, дочірня реєстрація не повинна містити залежні дані, поштовий індекс учасника (який недоступний для обслуговування за зареєстрованим планом) тощо.
• Третє завдання змінює дані у форматі, який можна ввести в базу даних. Наприклад, видалення назви плану (база даних зберігатиме лише ідентифікатор плану та назву плану страхування), додавання дати входу тощо.
• Четверте завдання завантажує дані в базу даних.
• Тестування пакетної роботи виконується на цьому процесі в два етапи –
• Кожна робота перевіряється окремо, і
• Інтеграція між завданнями перевіряється шляхом надання вхідного плоского файлу до першого завдання та перевірки бази даних. (Проміжні результати повинні бути підтверджені для додаткової обережності)

Нижче наведено метод тестування мейнфрейму:

Крок 1) Shakedown/Тестування диму

Основна увага на цьому етапі полягає в тому, щоб перевірити, чи розгорнутий код знаходиться в правильному тестовому середовищі. Це також гарантує відсутність критичних проблем із кодом.

Крок 2) Тестування системи

Нижче наведено типи тестування, які виконуються як частина тестування системи.

1. Пакетне тестування – Це тестування проводитиметься шляхом перевірки результатів тестування вихідних файлів і змін даних, виконаних пакетними завданнями в рамках тестування, і їх запису.
2. Інтернет-тестування – Це тестування буде виконано на передній частині додатку мейнфрейму. Тут програма перевіряється на правильність поля введення, як-от страховий план, відсотки за планом тощо.
3. Онлайн-пакетне тестування інтеграції – Це тестування проводитиметься на системах із пакетними процесами та онлайн-додатками. Перевірено потік даних і взаємодію між онлайн-екранами та пакетними завданнями.

   (Приклад для цього типу тестування – Розгляньте оновлення деталей плану, як-от підвищення процентної ставки. Зміна відсотка здійснюється на екрані оновлення, а деталі балансу на зачеплених рахунках буде змінено лише нічним пакетним завданням. Тестування в цьому випадку буде виконано шляхом перевірки екрана деталей плану та виконання пакетного завдання для оновлення всіх облікових записів).

4. Тестування бази даних – Бази даних, у яких дані з мейнфрейм-додатку (IMS, IDMS, DB2, VSAM/ISAM, послідовні набори даних, GDG) перевіряються на компонування та зберігання даних.

Крок 3) SYSTEM Інтеграційне тестування

Основною метою цього тестування є перевірка функціональності систем, які взаємодіють із системою, що тестується.

Вимоги безпосередньо не впливають на ці системи. Однак вони використовують дані з тестованої системи. Важливо протестувати інтерфейс і різні типи повідомлень (наприклад, «Завдання виконано», «Завдання не виконано», «База даних оновлено» тощо), які можуть надходити між системами, і відповідні дії, які виконуються окремими системами.

Типи тестування, які проводяться на цьому етапі, є

1. Пакетне тестування
2. Інтернет-тестування
3. Онлайн – Тестування пакетної інтеграції

Крок 4) Регресійне тестування

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

Для того, щоб мати ефективне регресійне тестування, певний набір тестових випадків має бути обраний у короткий список залежно від їх складності та має бути створено регресійне ліжко (сховище тестових випадків). Цей набір слід оновлювати щоразу, коли у випуску з’являється нова функція.

Крок 5) Тестування продуктивності

Це тестування проводиться для виявлення вузьких місць у таких областях, як інтерфейсні дані, оновлення онлайнових баз даних, і для прогнозування масштабованості програми.

Крок 6) Тестування безпеки

Це тестування проводиться, щоб оцінити, наскільки добре програма розроблена та розроблена для протидії атакам на захист.

У системі слід провести двоскладне тестування безпеки – безпеку мейнфрейму та безпеку мережі.

Функції, які необхідно перевірити, є

1. Integrity
2. Конфіденційність
3. авторизація
4. Authentication
5. доступність

Етапи пакетного тестування

1. Після того, як група контролю якості отримає схвалений пакет (пакет містить процедури, JCL, контрольні карти, модулі тощо), тестувальник повинен попередньо переглянути та отримати вміст у PDS, якщо потрібно.
2. Перетворіть робочий JCL або JCL розробки на JCL QA, інакше званий НАЛАШТУВАННЯМ ЗАДАЧ.
3. Копіювання робочого файлу та підготовка тестових файлів.
4. Для кожної функції буде визначена послідовність завдань. (Як пояснюється в прикладі в розділі «Методологія в мейнфреймі»). Завдання слід надсилати за допомогою команди SUB разом із файлами тестових даних.
5. Перевірте проміжний файл, щоб визначити причини відсутності або помилкових даних.
6. Перевірте кінцевий вихідний файл, базу даних і спул, щоб підтвердити результати тесту.
7. Якщо завдання зазнає невдачі, спул матиме причину збою завдання. Усуньте помилку та надішліть завдання повторно.

Звіт про тестування – Дефект слід реєструвати, якщо фактичний результат відрізняється від очікуваного.

Етапи онлайн-тестування

1. Виберіть екран «Онлайн» у тестовому середовищі.
2. Перевірте кожне поле на прийнятні дані.
3. Перевірте Сценарій тесту на екрані
4. Перевірте базу даних на наявність оновлень даних на екрані онлайн.

Звіт про тестування – якщо фактичний результат відрізняється від очікуваного, слід реєструвати дефект.

Етапи онлайн-тестування пакетної інтеграції

1. Виконайте завдання в a Тестове середовище і підтвердити дані на онлайн-екранах.
2. Оновіть дані на онлайн-екранах і перевірте, чи правильно виконується пакетне завдання з оновленими даними.

Команди, що використовуються в тестуванні мейнфрейму

1. НАДІСЛАТИ – подати фонову роботу.
2. СКАСУВАТИ – скасувати фонове завдання.
3. ALLOCATE – розподілити набір даних
4. COPY – копіювання набору даних
5. RENAME – перейменувати набір даних
6. DELETE – Видалити набір даних
7. JOB SCAN – для зв’язування JCL із програмою, бібліотеками, файлом тощо без його виконання.

Існує багато інших команд, які використовуються за потреби, але вони не такі часті.

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

Основні деталі, необхідні для тестування мейнфрейму:

• Логін і пароль для входу в додаток.
• Короткі знання про команди ISPF.
• Назви файлів, кваліфікатор файлу та їх типи.

Перед початком тестування мейнфрейму слід перевірити наведені нижче аспекти.

1. робота
   1. Виконайте сканування завдання (команда – JOBSCAN), щоб перевірити наявність помилок перед його виконанням.
   2. Параметр CLASS має вказувати на тестовий клас.
   3. Спрямуйте вивід завдання в спул або JHS або за потреби за допомогою параметра MSGCLASS.
   4. Переспрямуйте електронну пошту в завданні на спул або ідентифікатор тестової пошти.
   5. Прокоментуйте кроки FTP для початкового тестування, а потім направте завдання на тестовий сервер.
   6. Якщо в завданні створено IMR (запис керування інцидентами), просто додайте коментар «МЕТА ТЕСТУВАННЯ» в завдання або картку параметрів.
   7. Усі виробничі бібліотеки в завданні слід змінити та вказати на тестові бібліотеки.
   8. Робота не повинна залишатися без уваги.
   9. Щоб запобігти виконанню завдання в нескінченному циклі у випадку будь-якої помилки, слід додати параметр TIME із зазначеним часом.
   10. Збережіть результат завдання, включаючи спул. Котушку можна зберегти за допомогою XDC.

2. Файл
   1. Створіть тестовий файл тільки необхідного розміру. Використовуйте GDG (Групи даних генерації – файли з однаковою назвою, але з послідовними номерами версій – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 тощо), коли необхідно зберігати дані в послідовних файлах з однаковою назвою.
   2. Параметр DISP (розташування – описує систему для збереження або видалення набору даних після нормального чи ненормального завершення кроку чи завдання) для файлів має бути правильно закодовано.
   3. Переконайтеся, що всі файли, які використовуються для виконання завдання, збережено та закрито належним чином, щоб завдання не перейшло в режим HOLD.
   4. Під час тестування за допомогою GDG переконайтеся, що вказано правильну версію.
3. Database
   1. Під час виконання завдання або онлайн-програми переконайтеся, що небажані дані не вставляються, не оновлюються чи не видаляються.
   2. Також переконайтеся, що для тестування використовується правильний регіон DB2.
4. Тестові випадки
   1. Завжди перевіряйте наявність граничних умов, таких як – порожній файл, обробка першого запису, обробка останнього запису тощо.
   2. Завжди вказуйте як позитивні, так і негативні умови тесту.
   3. Якщо в програмі використовуються стандартні процедури, такі як перезапуск контрольної точки, перезапуск модулів, контрольні файли тощо, додайте тестові приклади для перевірки правильності використання модулів.
5. Дані тесту
   1. Налаштування тестових даних необхідно виконати до початку тестування.
   2. Ніколи не змінюйте дані в тестовій області без сповіщення. Можливо, інші команди працюють з тими ж даними, і їх тест буде невдалим.
   3. Якщо виробничі файли потрібні під час виконання, необхідно отримати належний дозвіл перед їх копіюванням або використанням.

Кращі практики

1. У разі виконання пакетного завдання MAX CC 0 є індикатором того, що завдання виконано успішно. Це не означає, що функціональність працює нормально. Завдання буде виконано успішно, навіть якщо вихідні дані порожні або не відповідають очікуванням. Тому завжди очікується перевірка всіх результатів, перш ніж оголосити роботу успішною.
2. Завжди корисно виконувати сухий прогін тестової роботи. Сухий запуск виконується з порожніми вхідними файлами. Цей процес слід дотримуватися для робіт, на які впливають зміни, внесені для циклу тестування.
3. Перед початком тестового циклу слід заздалегідь налаштувати тестове завдання. Це допоможе заздалегідь виявити будь-яку помилку JCL, отже, заощадивши час під час виконання.
4. Під час доступу до таблиць DB2 через SPUFI (опція на емуляторі для доступу до таблиць DB2) завжди встановлюйте автоматичне підтвердження як «НІ», щоб уникнути випадкових оновлень.
5. Доступність тестових даних є основною проблемою пакетного тестування. Необхідні дані повинні бути створені задовго до циклу тестування та повинні бути перевірені на повноту.
6. Деякі онлайн-транзакції та пакетні завдання можуть записувати дані в MQ (чергу повідомлень) для передачі даних іншим програмам. Якщо дані недійсні, це може вимкнути/зупинити MQ, це вплине на весь процес тестування. Гарною практикою є перевірка правильності роботи MQ після тестування.

Проблеми тестування мейнфреймів і усунення несправностей

Виклики	Підхід
Неповні/нечіткі вимоги Може бути доступ до посібника користувача/навчального посібника, але вони відрізняються від задокументованих вимог.	Тестери повинні бути залучені до SDLC, починаючи з фази вимог. Це допоможе перевірити, чи можна перевірити вимоги.
Налаштування даних/ідентифікація Можуть виникнути ситуації, коли існуючі дані слід повторно використовувати відповідно до вимог. Іноді буває важко визначити необхідні дані з наявних даних.	Для налаштування даних за потреби можна використовувати власні інструменти. Для отримання наявних даних запити повинні бути створені заздалегідь. У разі будь-яких труднощів можна надіслати запит групі управління даними для створення або клонування необхідних даних.
Налаштування завдання Після того, як завдання буде отримано в PDS, завдання потрібно налаштувати в регіоні QA. Щоб завдання не надсилалися з кваліфікатором виробництва або деталями шляху.	Інструменти налаштування завдання слід використовувати, щоб подолати людські помилки під час налаштування.
Спеціальний запит Можуть виникати ситуації, коли необхідна підтримка наскрізного тестування через проблему з проблемами програмного забезпечення вгорі або внизу. Ці запити збільшують час і зусилля в циклі виконання.	Використання сценаріїв автоматизації, сценаріїв регресії та каркасних сценаріїв може допомогти зменшити накладні витрати часу та зусиль.
Своєчасні релізи для зміни обсягу Може виникнути ситуація, коли вплив коду може повністю змінити зовнішній вигляд системи. Для цього може знадобитися змінити тестові випадки, сценарії та дані.	Необхідно запровадити процес управління змінами обсягу та аналіз впливу.

Зустрічаються поширені абенди

1. S001 – сталася помилка введення/виведення.

   Причина – читання в кінці файлу, помилка довжини файлу, спроба записати у файл лише для читання.

2. S002 – Недійсний запис введення/виведення.

   Причина – Спроба записати запис, який перевищує довжину запису.

3. S004 – сталася помилка під час ВІДКРИТИ.

   Причина – недійсний DCB

4. S013 – Помилка відкриття набору даних.

   Причина – член PDS не існує, довжина запису в програмі не відповідає фактичній довжині запису.

5. S0C1 – OperaВиняток

   Причина – Неможливо відкрити файл, відсутня карта DD

6. S0C4 – Виняток захисту/порушення зберігання
7. Причина – Спроба отримати доступ до сховища, недоступного для програми.
8. S0C7 – Виняток перевірки програми – Дані
9. Причина – зміна макета запису або файлу.
10. Sx22 – завдання скасовано
11. S222 – завдання скасовано користувачем без створення дампа.
12. S322 – Час завдання або кроку перевищив вказаний ліміт, або програма знаходиться в циклі, або недостатній параметр часу.
13. S522 – тайм-аут сеансу TSO.
14. S806 – Неможливо підключити або завантажити.

    Причина – ідентифікатор завдання не може знайти вказаний модуль завантаження.

15. S80A – Недостатньо віртуальної пам’яті для задоволення запитів GETMAIN або FREEMAIN.
16. S913 – Спроба отримати доступ до набору даних, для якого користувач не авторизований.
17. Sx37 – Неможливо виділити достатньо місця для набору даних.

Error Assist – дуже популярний інструмент для отримання детальної інформації про різні типи абендів.

Поширена проблема, з якою стикаються під час тестування мейнфрейму

• Робота Абендс – Для успішного завершення роботи ви повинні перевірити дані, вхідний файл і модулі, присутні в конкретному місці чи ні. Збій може виникати з кількох причин, найпоширенішою з яких є недійсні дані, неправильне поле введення, невідповідність дати, екологічні проблеми тощо.
• Вихідний файл порожній– Хоча завдання може виконуватися успішно (MaxCC 0), результат може бути не таким, як очікувалося. Тож перед проходженням будь-якого тесту тестувальник повинен переконатися, що вихідні дані пройшли перехресну перевірку. Тільки тоді продовжуйте далі.
• Вхідний файл порожній – У деяких програмах файли будуть отримані від вищестоящих процесів. Перш ніж використовувати отриманий файл для тестування поточної програми, дані повинні бути перехресно перевірені, щоб уникнути повторного виконання та переробки.

Підсумки

• Тестування мейнфрейму схоже на будь-яку іншу процедуру тестування, починаючи зі збору вимог, розробки тесту, виконання тесту та звітування про результати.
• Для ефективного тестування програми тестувальник повинен брати участь у нарадах щодо розробки, запланованих командами розробників і бізнес-групами.
• Тестеру необхідно звикнути до різних функцій тестування мейнфрейму. Наприклад, навігація по екрану, створення файлів і PDS, збереження результатів тестування тощо перед початком циклу тестування.
• Тестування додатків для мейнфреймів — це трудомісткий процес. Слід дотримуватися чіткого графіка тестування для розробки тесту, налаштування даних і виконання.
• Пакетне тестування та онлайн-тестування слід проводити ефективно, не пропускаючи жодної функції, зазначеної в документі вимог, і не Тестовий випадок слід пощадити.