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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• REXX — мова сценаріїв, що постачається з z/OS, широко використовується для керування повторюваними завданнями та перевірками виводу.
• перевершувати — використовується з макросами для створення, порівняння та звітування про тестові дані та вихідні файли.
• 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) Тестування продуктивності

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

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

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

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

Функції, які потрібно протестувати, це

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

Кроки, що входять до пакетного тестування

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

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

Кроки, пов'язані з онлайн-тестуванням

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

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

Кроки, що входять до онлайн-тестування — пакетне інтеграційне тестування

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

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

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

1. SUBMIT — Надішліть фонове завдання.
2. СКАСУВАТИ — Скасувати фонове завдання.
3. РОЗДІЛИТИ — Виділити набір даних.
4. КОПІЯ — Скопіювати набір даних.
5. ОЗНАЧИТИ — Перейменувати набір даних.
6. DELETE — Видалити набір даних.
7. СКАНУВАННЯ ЗАВДАНЬ — Зв'язати JCL з програмою, бібліотеками, файлами та іншими ресурсами без її виконання.

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

Необхідні умови для початку тестування мейнфреймів

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

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

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

1. робота
   • Виконайте сканування завдання (команда — JOBSCAN) для перевірки на наявність помилок перед його виконанням.
   • Параметр CLASS має вказувати на тестовий клас.
   • Спрямуйте вивід завдання в бухту або JHS, або, за потреби, за допомогою параметра MSGCLASS.
   • Перенаправити електронну пошту в завданні на буфер або на тестовий ідентифікатор пошти.
   • Закоментуйте кроки FTP для початкового тестування, а потім спрямуйте завдання на тестовий сервер.
   • Якщо в завданні створюється IMR (Запис про управління інцидентами), додайте коментар «МЕТА ТЕСТУВАННЯ» до завдання або картки параметрів.
   • Усі виробничі бібліотеки в завданні слід змінити та вказати на тестові бібліотеки.
   • Робота не повинна залишатися без уваги.
   • Щоб запобігти запуску завдання в нескінченному циклі у разі будь-якої помилки, слід додати параметр TIME із зазначеним часом.
   • Збережіть результат завдання, включаючи спул. Котушку можна зберегти за допомогою XDC.
2. Файл
   • Створіть тестовий файл лише потрібного розміру. Використовуйте GDG (групи даних покоління — файли з однаковою назвою, але з послідовними номерами версій, такі як MYLIB.LIB.TEST.G0001V00 та MYLIB.LIB.TEST.G0002V00) за потреби для зберігання даних у послідовних файлах з однаковою назвою.
   • Параметр DISP (Disposition — повідомляє системі, чи зберігати, чи видаляти набір даних після нормального чи аномального завершення кроку або завдання) для файлів має бути закодований правильно.
   • Переконайтеся, що всі файли, що використовуються для виконання завдання, збережені та закриті належним чином, щоб запобігти переходу завдання в режим HOLD.
   • Під час тестування за допомогою GDG переконайтеся, що вказано правильну версію.
3. Database
   • Під час виконання завдання або онлайн-програми переконайтеся, що небажані дані не вставляються, не оновлюються та не видаляються.
   • Також переконайтеся, що для тестування використовується правильний регіон Db2.
4. Тестові випадки
   • Завжди перевіряйте граничні умови, такі як порожній файл, обробка першого запису та обробка останнього запису.
   • Завжди вказуйте як позитивні, так і негативні умови тесту.
   • Якщо в програмі використовуються стандартні процедури, такі як перезапуск контрольних точок, модулі завершення роботи або файли керування, включно Тестовий випадокs для перевірки правильності використання модулів.
5. Дані тесту
   • Налаштування тестових даних необхідно виконати до початку тестування.
   • Ніколи не змінюйте дані в тестовій області, не повідомивши інших. Можливо, з тими ж даними працюють інші команди, і їхні тести зазнають невдачі.
   • Якщо виробничі файли потрібні під час виконання, необхідно отримати належний дозвіл перед їх копіюванням або використанням.

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

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

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

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

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

Звичайні зустрічаються Абендс

Коли завдання не вдається, буфер повідомляє про код аварії. Наведений нижче список містить коди, з якими найчастіше стикається тестер мейнфреймів, а також звичайні причини їх виникнення.

1. S001 — Сталася помилка вводу/виводу.

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

2. S002 — Недійсний запис вводу/виводу.

   Причина — Спроба записати запис, довший за довжину запису.

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

   Причина — Недійсний DCB.

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 — Не вдається виділити достатньо місця для зберігання набору даних.

Допомога з помилками — Дуже популярний інструмент для отримання детальної інформації про різні типи абендів.

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

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

Поширені запитання