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

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

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

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

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

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

При тестировании мэйнфреймов тестировщику в основном необходимо знать навигацию по экранам 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, широко используемый для выполнения повторяющихся операций отправки заданий и проверки результатов.
• Excel — Используется с макросами для создания, сравнения и составления отчетов по тестовым данным и выходным файлам.
• OpenText UFT Одна — нынешнее название инструмента, которое до сих пор используется в отрасли. QTP или QuickTest Professional; он автоматизирует 3270 экранов терминала.
• Галаса — проект с открытым исходным кодом, Open Mainframe Project — фреймворк для глубокого интеграционного тестирования Это позволяет запускать 3270 экранов, пакетные задания JCL и Db2 из конвейера CI/CD.
• Наборы тестов z/OS от производителя - IBM Test Accelerator for 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. Аутентификация
5. Доступность

Этапы пакетного тестирования

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

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

Этапы онлайн-тестирования

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

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

Этапы онлайн-интеграционного тестирования пакетной обработки данных

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

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

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

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

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

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

Для тестирования мэйнфреймов необходимы следующие основные данные:

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

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

1. работа
   • Перед выполнением задания выполните сканирование (команда — JOBSCAN), чтобы проверить его на наличие ошибок.
   • Параметр CLASS должен указывать на тестовый класс.
   • Направляйте вывод задания в очередь печати, файл JHS или, при необходимости, в файл конфигурации, используя параметр MSGCLASS.
   • Перенаправьте электронное письмо из задания в очередь рассылки или на тестовый почтовый адрес.
   • Закомментируйте шаги FTP для первоначального тестирования, а затем укажите тестовому серверу путь к заданию.
   • Если в задании создается запись об инциденте (IMR), добавьте комментарий «ЦЕЛЬ ТЕСТИРОВАНИЯ» в описание задания или параметрическую карту.
   • Все производственные библиотеки в задании следует изменить и указать на тестовые библиотеки.
   • Работу нельзя оставлять без внимания.
   • Чтобы предотвратить зацикливание задания в случае ошибки, в параметр TIME следует указать конкретное время.
   • Сохраните выходные данные задания, включая катушку. Катушку можно сохранить с помощью XDC.
2. Файл
   • Создайте тестовый файл только необходимого размера. При необходимости используйте GDG (Generation Data Groups — файлы с одинаковым именем, но с последовательными номерами версий, например, MYLIB.LIB.TEST.G0001V00 и MYLIB.LIB.TEST.G0002V00) для сохранения данных в последовательные файлы с одинаковым именем.
   • Параметр DISP (Disposition — указывает системе, следует ли сохранять или удалять набор данных после нормального или аварийного завершения шага или задания) для файлов должен быть закодирован корректно.
   • Убедитесь, что все файлы, используемые для выполнения задания, сохранены и надлежащим образом закрыты, чтобы предотвратить приостановку выполнения задания.
   • При тестировании с использованием GDG-файлов убедитесь, что указана правильная версия.
3. База данных
   • При выполнении задания или онлайн-программы убедитесь, что непреднамеренно не будут добавлены, обновлены или удалены ненужные данные.
   • Также убедитесь, что для тестирования используется правильный регион Db2.
4. Испытательные случаи
   • Всегда проверяйте наличие граничных условий, таких как пустой файл, обработка первой записи и обработка последней записи.
   • Всегда указывайте как положительные, так и отрицательные условия испытаний.
   • В случае использования в программе стандартных процедур, таких как перезапуск контрольной точки, аварийное завершение работы модулей или управляющих файлов, включите следующее: Тестовый кейсдля проверки правильности использования модулей.
5. Тестовые данные
   • Настройка тестовых данных должна быть выполнена до начала тестирования.
   • Никогда не изменяйте данные в тестовом регионе без уведомления других. С теми же данными могут работать и другие команды, и их тесты могут завершиться неудачей.
   • Если производственные файлы необходимы во время выполнения, перед их копированием или использованием необходимо получить соответствующее разрешение.

лучшие практики

1. В случае пакетного выполнения задания значение MAX CC 0 указывает на успешное выполнение задания. Это не означает, что функциональность работает корректно. Задание будет успешно выполнено, даже если выходные данные пусты или не соответствуют ожиданиям. Поэтому всегда рекомендуется проверять все выходные данные перед объявлением задания успешным.
2. Всегда полезно провести пробный запуск тестируемого задания. Пробный запуск выполняется с пустыми входными файлами. Этот процесс следует соблюдать для заданий, на которые влияют изменения, внесенные в тестовый цикл.
3. Перед началом цикла тестирования необходимо заранее подготовить тестовую задачу. Это поможет выявить любые ошибки JCL и, следовательно, сэкономить время во время выполнения.
4. При доступе к таблицам Db2 через SPUFI (опция эмулятора для доступа к таблицам Db2) всегда устанавливайте параметр автофиксации в значение «НЕТ», чтобы избежать случайных обновлений.
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), результат может не соответствовать ожиданиям. Поэтому перед прохождением любого тестового случая тестировщик должен убедиться, что результат перепроверен. Только после этого можно продолжать тестирование.
• Входной файл пуст — В некоторых приложениях файлы поступают из вышестоящих процессов. Перед использованием полученного файла для тестирования текущего приложения необходимо провести перекрестную проверку данных, чтобы избежать повторного выполнения и доработки.

Часто задаваемые вопросы (FAQ)