Перш ніж вивчати концепції тестування мейнфреймів, давайте вчимось
Що таке мейнфрейм?
Мейнфрейм - це високопродуктивна та високошвидкісна комп’ютерна система. Він використовується для більш масштабних обчислювальних цілей, що вимагає великої доступності та безпеки. Він в основному використовується в таких секторах, як фінанси, страхування, роздрібна торгівля та інші важливі сфери, де величезні дані обробляються неодноразово.
Тестування мейнфреймів
Тестування мейнфреймів - це процес тестування програмних додатків та служб на базі систем мейнфреймів. Метою тестування мейнфреймів є забезпечення продуктивності, надійності та якості програмного додатку чи послуги методами перевірки та перевірки та перевірка його готовності до розгортання.
Виконуючи тестування мейнфреймів, тестувальник повинен знати лише про навігацію екранами CICS. Вони створені спеціально для конкретних програм. Будь-які зміни, внесені в код в тестер COBOL, JCL тощо, не повинні турбуватися про емулятор, встановлений на машині. Зміни, які працюють на одному емуляторі терміналу, будуть працювати на інших.
- Додаток Mainframe (інакше званий пакетною роботою) перевіряється на основі тестових випадків, розроблених з використанням вимог
- Тестування мейнфреймів зазвичай виконується для розгорнутого коду з використанням різних комбінацій даних, встановлених у вхідному файлі.
- До програм, що працюють на мейнфреймі, можна отримати доступ через емулятор терміналу. Емулятор - це єдине програмне забезпечення, яке потрібно встановити на клієнтській машині.
У цьому підручнику для початківців ви дізнаєтесь-
- Атрибути мейнфрейма
- Класифікація ручного тестування в мейнфреймі
- Як зробити тестування мейнфреймів
- Засоби тестування автоматизації основних систем
- Методологія тестування мейнфреймів
- Етапи, що стосуються пакетного тестування
- Етапи, задіяні в Інтернет-тестуванні
- Етапи, задіяні в Інтернет-тестуванні пакетної інтеграції
- Команди, що використовуються в тестуванні мейнфреймів
- Передумови для початку тестування мейнфреймів
- Кращі практики
- Випробування мейнфреймів Проблеми та усунення несправностей
- Зустрічалися спільні абенди
- Поширена проблема, з якою стикалися під час тестування мейнфреймів
Атрибути мейнфрейма
- Віртуальне сховище
- Це техніка, яка дозволяє процесору імітувати основну пам’ять, яка перевищує фактичну кількість реального сховища.
- Це техніка ефективного використання пам'яті для зберігання та виконання завдань різного розміру.
- Він використовує дисковий накопичувач як продовження реального сховища.
- Мультипрограмування
- Комп’ютер виконує одночасно більше однієї програми. Але в будь-який момент лише одна програма може мати контроль над процесором.
- Це можливість, що забезпечує ефективне використання центрального процесора.
- Пакетна обробка
- Це техніка, за допомогою якої будь-яке завдання виконується в підрозділах, відомих як робочі місця.
- Завдання може спричинити виконання однієї або декількох програм послідовно.
- Планувальник завдань приймає рішення про порядок виконання завдань. Щоб максимізувати середню пропускну здатність, завдання плануються відповідно до їх пріоритету та класу.
- Необхідна інформація для пакетної обробки надається через JCL (МОВА КОНТРОЛЮ ЗАДАЧ). JCL описує пакетне завдання - необхідні програми, дані та ресурси.
- Розподіл часу
- У системі розподілу часу кожен користувач має доступ до системи через термінальний пристрій. Замість подання завдань, запланованих для подальшого виконання, користувач вводить команди, які обробляються негайно.
- Звідси це називається "Інтерактивна обробка". Це дозволяє користувачеві взаємодіяти безпосередньо з комп’ютером.
- Часова обробка відома як "Обробка переднього плану", а пакетна обробка - "Фонова обробка".
- Спулінг
- SPOOLing означає Синхронні периферійні операції в Інтернеті .
- Пристрій SPOOL використовується для зберігання результатів роботи програми / програми. Буферний вихід спрямовується на такі пристрої, як принтер (за потреби).
- Це об'єкт, який використовує перевагу буферизації для ефективного використання вихідних пристроїв.
Класифікація ручного тестування в мейнфреймі
Тестування мейнфреймів вручну можна класифікувати на два типи:
- Пакетне тестування на роботу -
- Процес тестування передбачає виконання пакетних завдань для функціональних можливостей, реалізованих у поточному випуску.
- Результати тесту, витягнуті з вихідних файлів та бази даних, перевіряються та записуються.
- Інтернет-тестування -
- Інтернет-тестування відноситься до тестування екранів CICS, що схоже на тестування веб-сторінки.
- Функціональність існуючих екранів можна змінити або додати нові екрани.
- Різні програми можуть мати екрани запитів та екрани оновлення. Функціональність цих екранів потрібно перевірити в рамках онлайн-тестування.
Як зробити тестування мейнфреймів
- Бізнес-команда готує необхідні документи. Що визначає, як певний елемент або процес буде модифікований у циклі випуску.
- Команда випробувань та розробник отримують документ про вимоги. Вони з’ясують, на скільки процесів вплинуть зміни. Зазвичай у випуску лише 20-25% додатків безпосередньо впливають на індивідуальні вимоги. Інші 75% випуску будуть стосуватися таких функціональних можливостей, як тестування програм та процесів.
- Отже, додаток Mainframe має бути протестований у двох частинах:
- Вимоги до тестування - Тестування програми на функціональність або зміни, зазначені в документі вимог.
- Тестування інтеграції - тестування всього процесу або іншої програми, яка отримує або надсилає дані до зазначеної програми. Регресійне тестування є основним напрямком цього тестування.
Засоби тестування автоматизації основних систем
Нижче наведено перелік інструментів, які можна використовувати для тестування автоматизації основних систем.
- REXX
- Excel
- QTP
Методологія тестування мейнфреймів
Давайте розглянемо приклад: страхова компанія XYZ має модуль реєстрації членів. Вони беруть дані як з екрану реєстрації учасників, так і з автономної реєстрації. Як ми вже обговорювали раніше, для тестування мейнфреймів, онлайн-тестування та пакетного тестування використовуються два підходи.
- Онлайн-тестування проводиться на екрані реєстрації учасників. Подібно до веб-сторінки, база даних перевіряється даними, введеними через екрани.
- Офлайн-реєстрація може бути реєстрацією у паперовій формі або реєстрацією на веб-сайті третьої сторони. Офлайн-дані (також їх називають пакетними) будуть введені в базу даних компанії за допомогою пакетних завдань. Вхідний плоский файл готується відповідно до встановленого формату даних і подається до послідовності пакетних завдань. Отже, для тестування додатків мейнфреймів ми можемо застосувати наступний підхід.
- Перше завдання в рядку пакетних завдань перевіряє введені дані. Скажімо, наприклад, спеціальний символ, алфавіти в полях лише з числами тощо.
- Друге завдання перевіряє узгодженість даних на основі умов ведення бізнесу. Наприклад, реєстрація дитини не повинна містити залежні дані, поштовий індекс учасника (який не доступний для обслуговування згідно із зареєстрованим планом) тощо.
- Третє завдання змінює дані у форматі, який можна ввести в базу даних. Наприклад, видалення назви плану (база даних буде зберігати лише ідентифікатор плану та назву страхового плану), додавання дати вступу тощо.
- Четверте завдання завантажує дані в базу даних.
- Пакетне тестування виконується за цим процесом у два етапи -
- Кожне завдання перевіряється окремо, і
- Інтеграція між завданнями перевіряється шляхом надання вхідного плоского файлу для першого завдання та перевірки бази даних. (Результати посередницьких процедур повинні бути перевірені для додаткової обережності)
Нижче наведено метод, який застосовується для тестування мейнфреймів:
Крок 1) : Перетрушування / Тестування диму
На цьому етапі основним завданням є перевірка того, чи розгорнутий код знаходиться в правильному тестовому середовищі. Це також гарантує відсутність критичних проблем з кодом.
Крок 2) : Тестування системи
Нижче наведені типи тестування, проведеного в рамках системного тестування.
- Пакетне тестування - Це тестування проводитиметься шляхом перевірки результатів тестування на вихідних файлах та змін даних, виконаних пакетними завданнями під обсягом тестування, та їх запису.
- Інтернет-тестування - це тестування проводитиметься на передній частині програми мейнфрейму. Тут заявка перевіряється на правильність поля входу, наприклад, страховий план, відсотки за планом тощо.
- Тестування онлайн-пакетної інтеграції - це тестування проводитиметься в системах із пакетними процесами та онлайн-додатком. Перевіряється потік даних та взаємодія між онлайновими екранами та пакетними завданнями.
( Приклад для цього типу тестування - розгляньте оновлення деталей плану, як збільшення процентної ставки. Зміна процентів здійснюється на екрані оновлення, а деталі балансу на уражених рахунках будуть змінені лише щовечірньою пакетною роботою. Тестування в цьому випадку це буде зроблено шляхом перевірки екрана деталей плану та запуску пакетного завдання для оновлення всіх облікових записів).
- Тестування баз даних - бази даних, де дані з програми мейнфреймів (IMS, IDMS, DB2, VSAM / ISAM, послідовні набори даних, GDG) перевіряються для їх розміщення та зберігання даних.
Крок 3) : Тестування системної інтеграції
Основна мета цього тестування - перевірити функціональність систем, які взаємодіють із системою, що тестується.
Вимоги безпосередньо не впливають на ці системи. Однак вони використовують дані тестованої системи. Важливо протестувати інтерфейс та різні типи повідомлень (наприклад, Job Successful, Job Failed, Database updated, тощо), які можуть переходити між системами та наслідками дій, вживаних окремими системами.
Види тестування, проведеного на цьому етапі, є
- Пакетне тестування
- Інтернет-тестування
- Інтернет - пакетне тестування інтеграції
Крок 4) : Регресійне тестування
Регресійне тестування є загальним етапом у будь-якому типі проекту тестування. Це тестування в Mainframes гарантує, що пакетні завдання та онлайнові екрани, які безпосередньо не взаємодіють із системою, що тестується (або не входять в обсяг вимог), не зачіпаються поточним випуском проекту.
Для того, щоб мати ефективне регресійне тестування, певний набір тестових випадків повинен потрапити до короткого списку залежно від їхньої складності та створити регресійне ложе (сховище тестових випадків). Цей набір слід оновлювати щоразу, коли до випуску внесено нову функціональність.
Крок 5) : Тестування продуктивності
Це тестування проводиться для виявлення вузьких місць у районах із високим ступенем ураження, таких як дані інтерфейсу, оновлення онлайн-баз даних та прогнозування масштабованості програми.
Крок 6) : Тестування безпеки
Це тестування проводиться для оцінки того, наскільки прикладний засіб розроблено та розроблено для протидії атакам, що стосуються захисту.
У системі слід провести двократне тестування безпеки - безпека мейнфреймів та безпека мережі.
Особливості, які потрібно протестувати, такі
- Чесність
- Конфіденційність
- Авторизація
- Аутентифікація
- Доступність
Етапи, що стосуються пакетного тестування
- Після того, як команда з контролю якості отримає затверджений пакет (Пакет містить процедури, JCL, контрольні картки, модулі тощо), тестер повинен здійснити попередній перегляд та отримання вмісту в PDS за необхідності.
- Перетворіть виробничий JCL або JCL для розробки в QA JCL, який інакше називається JOB SETUP.
- Копіювання виробничого файлу та підготовка тестових файлів.
- Для кожної функції буде визначена послідовність завдань. (Як пояснюється в прикладі в розділі Методологія в розділі Mainframe). Завдання слід подавати за допомогою команди SUB із файлами даних тесту.
- Перевірте проміжний файл, щоб визначити причини відсутніх даних або помилок.
- Перевірте остаточний вихідний файл, базу даних та котушку, щоб перевірити результати тесту.
- Якщо робота не вдається, у котушці буде причина невдачі. Усуньте помилку та повторно надішліть завдання.
Звітність про тести - дефект слід реєструвати, якщо фактичний результат відхиляється від очікуваного.
Етапи, задіяні в Інтернет-тестуванні
- Виберіть екран Інтернет в тестовому середовищі.
- Перевірте кожне поле на наявність прийнятних даних.
- Перевірте сценарій тесту на екрані.
- Перевірте базу даних для оновлення даних з онлайн-екрану.
Звітність про тести - дефект слід реєструвати, якщо фактичний результат відхиляється від очікуваного.
Етапи, задіяні в Інтернет-тестуванні пакетної інтеграції
- Запустіть завдання в тестовому середовищі та перевіріть дані на онлайнових екранах.
- Оновіть дані на онлайнових екранах і перевірте, чи належним чином запущено пакетне завдання разом із оновленими даними.
Команди, що використовуються в тестуванні мейнфреймів
- ПОДАТИ - Надіслати фонове завдання.
- СКАСУВАТИ - Скасувати фонове завдання.
- ALLOCATE - Виділити набір даних
- КОПІЮВАННЯ - скопіюйте набір даних
- RENAME - Перейменувати набір даних
- ВИДАЛИТИ - Видалити набір даних
- СКАНОВАННЯ РОБОТИ - Щоб зв’язати JCL із програмою, бібліотеками, файлами тощо, не виконуючи їх.
Існує багато інших команд, які використовуються, коли це потрібно, але вони не такі часті.
Передумови для початку тестування мейнфреймів
Основними деталями, необхідними для тестування мейнфреймів, є:
- Ідентифікатор і пароль для входу в програму.
- Короткі знання про команди ISPF.
- Назви файлів, кваліфікатор файлів та їх типи.
Перед початком тестування мейнфреймів слід перевірити наведені нижче аспекти.
- Робота
- Виконайте сканування завдання (Команда - JOBSCAN), щоб перевірити наявність помилок перед його виконанням.
- Параметр CLASS слід вказувати на тест-клас.
- Спрямуйте вихідні дані завдання в котушку або JHS, або як потрібно за допомогою параметра MSGCLASS.
- Перенаправити електронну пошту в завданні на буфер або тестовий ідентифікатор пошти.
- Прокоментуйте кроки FTP для початкового тестування, а потім направте завдання на тестовий сервер.
- Якщо у завданні генерується IMR (запис управління інцидентами), просто додайте коментар "ТЕСТУВАННЯ ЦІЛІ" у завдання або параметр.
- Усі виробничі бібліотеки в роботі слід змінити і вказати на тестові бібліотеки.
- Робота не повинна залишатися без уваги.
- Щоб запобігти виконанню завдання у нескінченному циклі у разі будь-якої помилки, слід додати параметр TIME із зазначеним часом.
- Збережіть результат роботи, включаючи котушку. Котушку можна зберегти за допомогою XDC.
- Файл
- Створіть лише тестовий файл потрібного розміру. Використовуйте GDG (групи даних генерації - файли з однаковим іменем, але з послідовними номерами версій - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 тощо), коли потрібно зберігати дані у послідовних файлах з однаковим іменем.
- Параметр DISP (Disposition - описує систему для виконання збереження або видалення набору даних після нормального або ненормального завершення кроку або завдання) повинен правильно кодувати параметри файлів.
- Переконайтеся, що всі файли, що використовуються для виконання завдання, збережені та закриті належним чином, щоб запобігти переходу завдання до HOLD.
- Під час тестування за допомогою GDG переконайтеся, що вказана правильна версія.
- База даних
- Під час виконання завдання або онлайн-програми переконайтеся, що ненавмисні дані не вставляються, не оновлюються та не видаляються.
- Також переконайтеся, що для тестування використовується правильна область DB2.
- Тестові кейси
- Завжди перевіряйте граничні умови, такі як - порожній файл, обробка першого запису, обробка останнього запису тощо.
- Завжди включайте як позитивні, так і негативні умови тестування.
- Якщо в програмі використовуються стандартні процедури, такі як перезапуск контрольної точки, модулі Abend, файли керування тощо, включають тестові випадки для перевірки правильності використання модулів.
- Дані тесту
- Налаштування даних тестування слід проводити до початку тестування.
- Ніколи не змінюйте дані в тестовій області без попередження. Можуть бути інші команди, які працюють з тими самими даними, і їх перевірка не пройде.
- Якщо виробничі файли потрібні під час виконання, перед копіюванням або використанням слід отримати належний дозвіл.
Кращі практики
- У випадку виконання пакетного завдання, MAX CC 0 є показником успішного виконання завдання. Це не означає, що функціонал працює нормально. Завдання буде успішно виконано, навіть якщо вихідні дані порожні або не відповідають очікуванням. Тому завжди очікується перевірити всі результати перед тим, як оголосити роботу успішною.
- Це завжди хороша практика робити суху роботу під час перевірки. Сухий запуск виконується з порожніми вхідними файлами. Цей процес слід дотримуватися для робочих місць, на які впливають зміни, внесені в тестовий цикл.
- Перед початком тестового циклу налаштування тестового завдання слід виконати заздалегідь. Це допоможе виявити будь-яку помилку JCL заздалегідь, отже, заощадити час під час виконання.
- Під час доступу до таблиць DB2 через SPUFI (опція на емуляторі для доступу до таблиць DB2), завжди встановлюйте автоматичне фіксацію як "НІ", щоб уникнути випадкових оновлень.
- Доступність даних тестування є основною проблемою при пакетному тестуванні. Необхідні дані слід створювати задовго до тестового циклу та перевіряти на повноту.
- Деякі онлайн-транзакції та пакетні завдання можуть записувати дані у MQ (Черга повідомлень) для передачі даних до інших програм. Якщо дані недійсні, це може вимкнути / зупинити MQ, це вплине на весь процес тестування. Це хороша практика перевіряти, чи MQ працюють нормально після тестування.
Випробування мейнфреймів Проблеми та усунення несправностей
Виклики | Підхід |
Неповні / незрозумілі вимоги Може існувати доступ до посібника користувача / навчального посібника, але вони не є такими, як задокументовані вимоги. | Тестери повинні залучатися до SDLC з фази вимог і далі. Це допоможе перевірити, чи вимоги перевіряються. |
Налаштування / ідентифікація даних Можуть бути ситуації, коли наявні дані слід використовувати повторно відповідно до вимоги. Іноді важко визначити необхідні дані з наявних даних. | Для налаштування даних за потреби можна використовувати доморощені інструменти. Для отримання існуючих даних запити слід будувати заздалегідь. У разі виникнення будь-яких труднощів можна надіслати запит до команди управління даними для створення або клонування необхідних даних. |
Налаштування завдання Після отримання завдань у PDS, завдання потрібно налаштувати в області контролю якості. Так що завдання не подаються із виробничим кваліфікатором або деталями шляху. | Слід використовувати інструменти налаштування роботи, щоб подолати людські помилки, допущені під час налаштування. |
Спеціальний запит Можуть виникати ситуації, коли потрібно підтримувати наскрізне тестування через проблему, пов’язану з проблемами додатків вище та нижче. Ці запити збільшують час та зусилля у циклі виконання. | Використання сценаріїв автоматизації, сценаріїв регресії та скелетів може допомогти зменшити витрати часу та зусиль. |
Своєчасні випуски для зміни обсягу Можлива ситуація, коли вплив коду може повністю змінити зовнішній вигляд системи. Для цього може знадобитися зміна тестових кейсів, сценаріїв та даних. | Повинні бути передбачені процес управління зміною масштабу та аналіз впливу. |
Зустрічалися спільні абенди
- S001 - Сталася помилка вводу-виводу.
Причина - читання в кінці файлу, помилка довжини файлу, спроба записати у файл лише для читання.
- S002 - Недійсний запис вводу-виводу.
Причина - Спроба записати запис довший за довжину запису.
- S004 - Помилка сталася під час відкриття.
Причина - недійсний DCB
- S013 - Помилка відкриття набору даних.
Причина - член PDS не існує, тривалість запису в програмі не відповідає фактичній довжині запису.
- S0C1 - Виняток операції
Причина - Неможливо відкрити файл, відсутня карта DD
- S0C4 - Виняток захисту / порушення зберігання
- Причина - спроба отримати доступ до сховища, недоступного для програми.
- SC07 - Виняток перевірки програми - Дані
- Причина - Зміна макета запису або макета файлу.
- Sx22 - Робота скасована
- S222 - Завдання скасовано користувачем без дампа.
- S322 - Час завдання або кроку перевищив зазначений ліміт, або програма перебуває в циклі або недостатній параметр часу.
- S522 - час очікування сеансу TSO.
- S806 -Неможливо зв'язати або завантажити.
Причина - ідентифікатор завдання не може знайти вказаний модуль завантаження.
- S80A - Недостатньо віртуального сховища для задоволення запитів GETMAIN або FREEMAIN.
- S913 - Спроба отримати доступ до набору даних, який користувач не має дозволу.
- Sx37 - Неможливо виділити достатньо пам’яті для набору даних.
Допомога при помилках - Дуже популярний інструмент для отримання детальної інформації про різні типи відхилень.
Поширена проблема, з якою стикалися під час тестування мейнфреймів
- Відмова від роботи - для успішного завершення роботи вам слід перевірити дані, вхідний файл та модулі, присутні в конкретному місці чи ні. З Andends можна зіткнутися з різних причин, найпоширеніша з яких - недійсні дані, неправильне поле введення, невідповідність дат, екологічні проблеми тощо.
- Вихідний файл порожній -Хоча завдання може успішно виконуватися (MaxCC 0), результат може бути не таким, як очікувалося. Отже, перед тим, як пройти будь-який тест, тестувальник повинен переконатися, що вихідний результат перехресно перевірений. Тільки потім продовжуйте далі.
- Вхідний файл порожній - У деяких програмах файли отримуватимуться із вищих процесів. Перш ніж використовувати отриманий файл для тестування поточної програми, дані слід перехресно перевірити, щоб уникнути повторного виконання та переробки.
Короткий зміст:
- Тестування мейнфреймів подібно до будь-якої іншої процедури тестування, починаючи від збору вимог, проектування тесту, виконання тесту та звітування про результати.
- Для того, щоб ефективно протестувати заявку, тестувальник повинен брати участь у зустрічах з проектування, запланованих командами розробників та бізнесу.
- Тестер обов'язково звикає до різних функцій тестування мейнфреймів. Як і навігація екраном, створення файлів та PDS, збереження результатів тестування тощо перед початком тестового циклу.
- Тестування додатків для мейнфреймів - це процес, який вимагає часу. При розробці тесту, налаштуванні та виконанні даних слід дотримуватися чіткого розкладу випробувань.
- Пакетне тестування та тестування в режимі он-лайн слід проводити ефективно, не втрачаючи жодної функціональності, зазначеної в документі Вимога, і жоден тест-кейс не повинен бути пошкоджений.