Учебники

Тестирование мэйнфреймов

Сентябрь 21, 2019

Прежде чем изучать концепции тестирования мэйнфреймов, давайте изучим

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

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

Что такое тестирование мэйнфреймов?

MAINFRAME TESTING — это валидация и верификация программных приложений и сервисов, основанных на мэйнфреймах. При выполнении тестирования мэйнфрейма тестер должен знать только о навигации по экранам CICS. Они изготовлены на заказ для конкретных приложений. Любые изменения, внесенные в код в тестере COBOL, JCL и т. Д., Не должны беспокоиться об установленном на компьютере эмуляторе. Изменения, которые работают на одном эмуляторе терминала, будут работать на других.

  • Приложение Mainframe (иначе называемое пакетом заданий) проверяется на соответствие тестовым примерам, разработанным с использованием требований.
  • Тестирование мэйнфреймов обычно выполняется на развернутом коде с использованием различных комбинаций данных, установленных во входном файле.
  • Приложения, работающие на мэйнфрейме, доступны через эмулятор терминала. Эмулятор — единственное программное обеспечение, которое должно быть установлено на клиентском компьютере.

В этом уроке для начинающих вы

Атрибуты мэйнфреймов

  1. Виртуальное хранилище
    1. Это метод, который позволяет процессору моделировать основное хранилище, которое больше, чем фактический объем реального хранилища.
    2. Это метод эффективного использования памяти для хранения и выполнения задач различного размера.
    3. Он использует дисковое хранилище как расширение реального хранилища.
  2. Мультипрограммирование
    1. Компьютер выполняет более одной программы одновременно. Но в любой момент времени только одна программа может управлять процессором.
    2. Это средство, предназначенное для эффективного использования процессора.
  3. Пакетная обработка
    1. Это техника, с помощью которой любая задача выполняется в единицах, известных как рабочие места.
    2. Задание может привести к тому, что одна или несколько программ будут выполняться последовательно.
    3. Планировщик заданий принимает решение о порядке выполнения заданий. Чтобы максимизировать среднюю пропускную способность, задания планируются в соответствии с их приоритетом и классом.
    4. Необходимая информация для пакетной обработки предоставляется через JCL (JOB CONTROL LANGUAGE). JCL описывает пакетное задание — необходимые программы, данные и ресурсы.
  4. Совместное времяпровождение
    1. В системе с разделением времени каждый пользователь имеет доступ к системе через терминальное устройство. Вместо отправки заданий, которые запланированы для последующего выполнения, пользователь вводит команды, которые обрабатываются немедленно.
    2. Следовательно это называется «Интерактивная обработка». Это позволяет пользователю напрямую взаимодействовать с компьютером.
    3. Обработка с разделением времени называется «Обработка переднего плана», а обработка пакетных заданий называется «Фоновая обработка».
  5. намоточные
    1. SPOOLing означает одновременные периферийные операции онлайн .
    2. SPOOL-устройство используется для хранения результатов программы / приложения. Буферный вывод направляется на устройства вывода, такие как принтер (при необходимости).
    3. Это средство, использующее преимущество буферизации для эффективного использования устройств вывода.

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

Ручное тестирование мэйнфреймов можно разделить на два типа:

  1. Пакетное тестирование —
    • Процесс тестирования включает в себя выполнение пакетных заданий для функциональности, реализованной в текущем выпуске.
    • Результат теста, извлеченный из выходных файлов и базы данных, проверен и записан.
  2. Интернет-тестирование —
    • Онлайн-тестирование относится к тестированию экранов CICS, которое аналогично тестированию веб-страницы.
    • Функциональность существующих экранов может быть изменена, или могут быть добавлены новые экраны.
    • Различные приложения могут иметь экраны запросов и экраны обновления. Функциональность этих экранов должна быть проверена в рамках онлайн-тестирования.

Как сделать тестирование мэйнфреймов

  1. Бизнес-команда готовит необходимые документы. Который определяет, как конкретный элемент или процесс будет изменен в цикле выпуска.
  2. Команда тестирования и разработка получают документ с требованиями. Они выяснят, сколько процессов будет затронуто изменением. Обычно в выпуске только 20-25% приложения напрямую зависят от настроенного требования. Остальные 75% выпуска будут предназначены для стандартных функций, таких как тестирование приложений и процессов.
  3. Итак, приложение Mainframe должно быть протестировано в двух частях:
    1. Требования к тестированию — тестирование приложения на функциональность или изменения, указанные в документе с требованиями.
    2. Интеграция тестирования — Тестирование всего процесса или другого приложения, которые получают или отправляют данные в уязвимое приложение. Регрессионное тестирование является основным направлением этой деятельности по тестированию.

Инструменты тестирования мэйнфреймов

Ниже приведен список инструментов, которые можно использовать для тестирования автоматизации мэйнфреймов .

  • REXX
  • превосходить
  • QTP

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

Давайте рассмотрим пример: у страховой компании XYZ есть модуль регистрации участников. Он берет данные как с экрана регистрации участника, так и из автономной регистрации. Как мы уже говорили ранее, для тестирования мэйнфреймов, онлайн-тестирования и пакетного тестирования требуются два подхода.

  • Онлайн тестирование проводится на экране регистрации участников. Так же, как веб-страница, база данных проверяется данными, вводимыми через экраны.
  • Автономная регистрация может быть бумажной регистрацией или регистрацией на стороннем веб-сайте. Автономные данные (также называемые пакетными) будут вводиться в базу данных компании посредством пакетных заданий. Входной плоский файл подготавливается в соответствии с заданным форматом данных и подается в последовательность пакетных заданий. Поэтому для тестирования приложений мэйнфреймов мы можем использовать следующий подход.
    • Первое задание в строке пакетных заданий проверяет введенные данные. Скажем, например, специальный символ, алфавиты в полях с числами и т. Д.
    • Второе задание проверяет согласованность данных на основе бизнес-условий. Например, регистрация ребенка не должна содержать зависимые данные, почтовый индекс участника (который не доступен для обслуживания зарегистрированным планом) и т. Д.
    • Третье задание изменяет данные в формате, который можно ввести в базу данных. Например, удаление имени плана (в базе данных будут храниться только идентификатор плана и имя плана страхования), добавление даты входа и т. Д.
    • Четвертое задание загружает данные в базу данных.
  • Пакетное тестирование выполняется в этом процессе в два этапа —
    • Каждая работа проверяется отдельно, а
    • Интеграция между заданиями проверяется путем предоставления входного плоского файла для первого задания и проверки базы данных. (Посреднические результаты должны быть проверены для особой осторожности)

Ниже приведен метод, используемый для тестирования мэйнфреймов:

Шаг 1) : Шейкдаун / Тест дыма

На этом этапе основное внимание уделяется проверке того, находится ли развернутый код в правильной тестовой среде. Это также гарантирует отсутствие критических проблем с кодом.

Шаг 2) : тестирование системы

Ниже приведены типы тестирования, выполненные в рамках Системного тестирования.

  1. Пакетное тестирование — это тестирование будет выполнено путем проверки результатов тестирования выходных файлов и изменений данных, выполненных пакетными заданиями в рамках области тестирования, и их записи.
  2. Онлайновое тестирование — это тестирование будет выполнено во внешней части приложения мэйнфрейма. Здесь приложение проверяется на правильное поле ввода, например, план страхования, проценты по плану и т. Д.
  3. Онлайн-пакетное интеграционное тестирование — это тестирование будет проводиться на системах, имеющих пакетные процессы и онлайн-приложения. Поток данных и взаимодействие между онлайн-экранами и пакетными заданиями проверяется.

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

  4. Тестирование базы данных — базы данных, в которых данные из приложения мэйнфрейма (IMS, IDMS, DB2, VSAM / ISAM, последовательные наборы данных, GDG) проверяются на предмет их расположения и хранения данных.

Шаг 3) : Тестирование системной интеграции

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

Эти системы напрямую не зависят от требований. Однако они используют данные из тестируемой системы. Важно протестировать интерфейс и различные типы сообщений (например, «Задание успешно выполнено», «Задание выполнено успешно», «Обновление базы данных» и т. Д.), Которые могут передаваться между системами, и в результате действия, предпринимаемые отдельными системами.

Типы тестирования, выполненные на этом этапе:

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

Шаг 4) : регрессионное тестирование

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

Для проведения эффективного регрессионного тестирования, определенный набор тестовых случаев должен быть включен в короткий список в зависимости от их сложности, и должен быть создан регрессионный слой (хранилище тестовых случаев). Этот набор должен обновляться всякий раз, когда в выпуске появляется новая функциональность.

Шаг 5) : Тестирование производительности

Это тестирование проводится для выявления узких мест в таких областях, как данные переднего плана, обновление онлайн-баз данных и прогнозирование масштабируемости приложения.

Шаг 6) : Тестирование безопасности

Это тестирование проводится для оценки того, насколько хорошо приложение спроектировано и разработано для противодействия атакам защиты.

В системе необходимо выполнить двойное тестирование безопасности — безопасность мэйнфрейма и безопасность сети.

Особенности, которые необходимо проверить

  1. целостность
  2. конфиденциальность
  3. авторизация
  4. Аутентификация
  5. Доступность

Шаги, вовлеченные в Пакетное тестирование

  1. После того, как команда QA получит утвержденный пакет (Пакет содержит процедуры, JCL, Контрольные карты, Модули и т. Д.), Тестировщик должен предварительно просмотреть и извлечь содержимое в PDS по мере необходимости.
  2. Преобразуйте производственный JCL или Development JCL в QA JCL, иначе называемый JOB SETUP.
  3. Копирование рабочего файла и подготовка тестовых файлов.
  4. Для каждой функции будет определена последовательность заданий. (Как объяснено в примере в разделе «Методология в разделе мэйнфреймов»). Задания следует отправлять с помощью команды SUB с файлами тестовых данных.
  5. Проверьте промежуточный файл, чтобы определить причины пропущенных или ошибочных данных.
  6. Проверьте итоговый выходной файл, базу данных и буфер, чтобы проверить результаты теста.
  7. Если работа не удалась, у катушки будет причина сбоя работы. Исправьте ошибку и повторите задание.

Отчет об испытаниях — дефект должен регистрироваться, если фактический результат отличается от ожидаемого.

Шаги, вовлеченные в онлайн-тестирование

  1. Выберите экран Online в тестовой среде.
  2. Проверьте каждое поле на приемлемые данные.
  3. Проверьте сценарий тестирования на экране.
  4. Проверьте базу данных для обновления данных с онлайн-экрана.

Отчет об испытаниях — дефект регистрируется, если фактический результат отличается от ожидаемого.

Шаги, вовлеченные в онлайн — пакетное тестирование интеграции

  1. Запустите задание в тестовой среде и проверьте данные на онлайн-экранах.
  2. Обновите данные на онлайн-экранах и проверьте правильность выполнения пакетного задания с обновленными данными.

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

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

При необходимости используется много других команд, но они не так часты.

Предварительные условия для начала тестирования мэйнфреймов

Основные детали, необходимые для тестирования мэйнфреймов:

  • Логин и пароль для входа в приложение.
  • Краткое знание команд ISPF.
  • Имена файлов, классификатор файлов и их типы.

Перед началом тестирования мэйнфреймов необходимо проверить перечисленные ниже аспекты.

  1. работа
    1. Выполните сканирование задания (Command — JOBSCAN), чтобы проверить наличие ошибок перед его выполнением.
    2. Параметр CLASS должен указывать на класс теста.
    3. Направьте вывод задания в буфер или JHS или, если требуется, с помощью параметра MSGCLASS.
    4. Перенаправьте адрес электронной почты в задании на буферизацию или идентификатор тестовой почты.
    5. Прокомментируйте шаги FTP для первоначального тестирования, а затем укажите задание на тестовом сервере.
    6. В случае, если IMR (запись управления инцидентами) генерируется в задании, просто добавьте комментарий «ЦЕЛЬ ИСПЫТАНИЯ» в задание или карточку параметров.
    7. Все производственные библиотеки в работе должны быть изменены и указаны для тестовых библиотек.
    8. Работу не следует оставлять без присмотра.
    9. Чтобы предотвратить выполнение задания в бесконечном цикле в случае возникновения ошибки, необходимо добавить параметр TIME с указанным временем.
    10. Сохраните результаты работы, включая катушку. Катушку можно сохранить с помощью XDC.
  1. файл
    1. Создайте тестовый файл только необходимого размера. Используйте GDG (группы данных генерации — файлы с тем же именем, но с последовательными номерами версий — MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 и т. Д.), Когда необходимо хранить данные в последовательных файлах с одинаковыми именами.
    2. Параметр DISP (Расположение — описывает систему для выполнения сохранения или удаления набора данных после нормального или ненормального завершения шага или задания) для файлов должен быть правильно закодирован.
    3. Убедитесь, что все файлы, используемые для выполнения задания, сохранены и правильно закрыты, чтобы задание не переходило в состояние HOLD.
    4. При тестировании с использованием GDG убедитесь, что указана правильная версия.
  2. База данных
    1. При выполнении задания или онлайн-программы убедитесь, что непреднамеренные данные не вставляются, не обновляются и не удаляются.
    2. Также убедитесь, что для тестирования используется правильный регион DB2.
  3. Контрольные примеры
    1. Всегда проверяйте граничные условия, такие как — Пустой файл, Обработка первой записи, Обработка последней записи и т. Д.
    2. Всегда включайте как положительные, так и отрицательные условия испытаний.
    3. В случае, если в программе используются стандартные процедуры, такие как перезапуск с контрольной точки, модули аварийного завершения, контрольные файлы и т. Д., Включите тестовые примеры для проверки правильности использования модулей.
  4. Тестовые данные
    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 — Исключение операции

    Причина — невозможно открыть файл, отсутствует DD-карта

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

    Причина — идентификатор задания не может найти указанный загрузочный модуль.

  15. S80A — Недостаточно виртуальной памяти для удовлетворения запросов GETMAIN или FREEMAIN.
  16. S913 — Попытка получить доступ к набору данных, который пользователь не авторизован.
  17. Sx37 — Невозможно выделить достаточно памяти для набора данных.

Error Assist — очень популярный инструмент для получения подробной информации о различных типах аварий.

Общая проблема, возникающая при тестировании мэйнфреймов

  • Завершение работы — для успешного завершения работы вы должны проверить данные, входной файл и модули, присутствующие в определенном месте или нет. С аварийными ситуациями можно столкнуться по нескольким причинам, наиболее распространенными из которых являются — неверные данные, неправильное поле ввода, несоответствие даты, проблемы окружающей среды и т. Д.
  • Выходной файл пуст — хотя задание может выполняться успешно (MaxCC 0), выходные данные могут быть не такими, как ожидалось. Поэтому, прежде чем проходить любой тестовый пример, тестировщик должен убедиться, что выходные данные проверены перекрестно. Только тогда продолжайте.
  • Входной файл пуст — в некоторых приложениях файлы будут получены от вышестоящих процессов. Прежде чем использовать полученный файл для тестирования текущего приложения, данные должны подвергаться перекрестной проверке, чтобы избежать повторного выполнения и переделки.

Резюме:

 

54
Share: