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

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

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

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

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

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

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

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

Атрибуты мэйнфрейма
Классификация ручного тестирования в мэйнфреймах
Как проводить тестирование мэйнфреймов
Инструменты тестирования автоматизации мэйнфреймов
Методология тестирования мэйнфреймов
Этапы пакетного тестирования
Этапы онлайн-тестирования
Этапы онлайн-тестирования пакетной интеграции
Команды, используемые при тестировании мэйнфреймов
Предварительные условия для начала тестирования мэйнфрейма
Лучшие практики
Проблемы тестирования мэйнфреймов и устранение неисправностей
Встречаются обычные Abends
Распространенная проблема, возникающая при тестировании мэйнфрейма

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

Виртуальное хранилище
1. Это метод, который позволяет процессору моделировать объем оперативной памяти, размер которой превышает фактический объем реальной памяти.
2. Это метод эффективного использования памяти для хранения и выполнения задач различного размера.
3. Он использует дисковое хранилище как расширение реального хранилища.
Мультипрограммирование
1. Компьютер одновременно выполняет несколько программ. Но в любой момент только одна программа может управлять процессором.
2. Это средство, обеспечивающее эффективное использование ЦП.
Пакетная обработка
1. Это метод, с помощью которого любая задача выполняется в единицах, известных как рабочие места.
2. Задание может привести к последовательному выполнению одной или нескольких программ.
3. Планировщик заданий принимает решение о порядке выполнения заданий. Чтобы максимизировать среднюю пропускную способность, задания планируются в соответствии с их приоритетом и классом.
4. Необходимая информация для пакетной обработки предоставляется через JCL (ЯЗЫК УПРАВЛЕНИЯ ЗАДАНИЯМИ). JCL описывает пакетное задание - необходимые программы, данные и ресурсы.
Совместное времяпровождение
1. В системе с разделением времени каждый пользователь имеет доступ к системе через оконечное устройство. Вместо отправки заданий, запланированных для последующего выполнения, пользователь вводит команды, которые обрабатываются немедленно.
2. Следовательно, это называется «Интерактивная обработка». Это позволяет пользователю напрямую взаимодействовать с компьютером.
3. Обработка с разделением времени известна как «обработка переднего плана», а обработка пакетных заданий известна как «обработка в фоновом режиме».
Намотка
1. SPOOLing означает одновременные периферийные операции в Интернете .
2. Устройство SPOOL используется для хранения вывода программы / приложения. Буферный вывод направляется на устройства вывода, такие как принтер (при необходимости).
3. Это средство, использующее преимущества буферизации для эффективного использования устройств вывода.

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

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

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

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

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

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

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

REXX
Excel
QTP

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

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

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

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

Шаг 1) : Shakedown / Smoke Testing

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

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

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

Пакетное тестирование - это тестирование будет проводиться путем проверки результатов тестирования выходных файлов и изменений данных, выполненных пакетными заданиями в рамках объема тестирования, и их записи.
Онлайн-тестирование - это тестирование будет проводиться во внешнем интерфейсе приложения для мэйнфрейма. Здесь приложение проверяется на предмет правильности поля ввода, такого как план страхования, проценты по плану и т. Д.
Тестирование онлайн-пакетной интеграции - это тестирование будет проводиться в системах с пакетными процессами и онлайн-приложением. Проверяется поток данных и взаимодействие между онлайн-экранами и пакетными заданиями.
( Пример для этого типа тестирования - рассмотрите возможность обновления деталей плана, таких как увеличение процентной ставки. Изменение процентной ставки выполняется на экране обновления, а данные баланса на затронутых счетах будут изменены только с помощью еженедельного пакетного задания. Тестирование в этом случае будет выполняться проверка экрана сведений о плане и запуск пакетного задания для обновления всех учетных записей).
Тестирование базы данных - базы данных, в которых данные из приложения мэйнфрейма (IMS, IDMS, DB2, VSAM / ISAM, последовательные наборы данных, GDG) проверяются на предмет их структуры и хранилища данных.

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

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

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

На этом этапе проводятся следующие виды тестирования:

Пакетное тестирование
Онлайн-тестирование
Онлайн - тестирование пакетной интеграции

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

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

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

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

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

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

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

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

Функции, которые необходимо протестировать:

Честность
Конфиденциальность
Авторизация
Аутентификация
Доступность

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

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

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

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

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

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

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

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

ОТПРАВИТЬ - Отправить фоновое задание.
ОТМЕНА - отменить фоновое задание.
ALLOCATE - выделить набор данных
КОПИРОВАТЬ - копировать набор данных.
ПЕРЕИМЕНОВАТЬ - переименовать набор данных
УДАЛИТЬ - Удалить набор данных
JOB SCAN - привязать JCL к программе, библиотекам, файлу и т. Д. Без его выполнения.

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

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

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

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

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

Работа
1. Выполните сканирование задания (команда - JOBSCAN), чтобы проверить наличие ошибок перед его выполнением.
2. Параметр CLASS должен указывать на тестовый класс.
3. Направьте вывод задания в катушку или JHS или по мере необходимости с помощью параметра MSGCLASS.
4. Перенаправьте электронное письмо в задании для буферизации или тестового почтового идентификатора.
5. Прокомментируйте шаги FTP для первоначального тестирования, а затем укажите задание на тестовый сервер.
6. Если в задании создается IMR (запись управления инцидентами), просто добавьте комментарий «ЦЕЛЬ ТЕСТИРОВАНИЯ» в задание или карту параметров.
7. Все производственные библиотеки в задании следует изменить и указать на библиотеки тестирования.
8. Работу нельзя оставлять без присмотра.
9. Чтобы задание не запускалось в бесконечном цикле в случае какой-либо ошибки, следует добавить параметр TIME с указанным временем.
10. Сохраните результат работы, включая катушку. Катушку можно сохранить с помощью XDC.

Файл
1. Создайте тестовый файл только необходимого размера. При необходимости используйте GDG (группы данных генерации - файлы с тем же именем, но с последовательными номерами версий - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 и т. Д.) Для сохранения данных в последовательные файлы с одинаковыми именами.
2. Параметр DISP (Disposition - описывает систему для сохранения или удаления набора данных после нормального или аварийного завершения шага или задания) для файлов должен быть закодирован правильно.
3. Убедитесь, что все файлы, используемые для выполнения задания, сохранены и закрыты должным образом, чтобы предотвратить переход задания в режим ожидания.
4. При тестировании с использованием GDG убедитесь, что указана правильная версия.
База данных
1. При выполнении задания или интерактивной программы убедитесь, что непредусмотренные данные не вставляются, не обновляются или не удаляются.
2. Также убедитесь, что для тестирования используется правильный регион DB2.
Тестовые кейсы
1. Всегда проверяйте граничные условия, такие как - Пустой файл, Обработка первой записи, Обработка последней записи и т. Д.
2. Всегда указывайте как положительные, так и отрицательные условия теста.
3. В случае, если в программе используются стандартные процедуры, такие как перезапуск контрольной точки, модули Abend, контрольные файлы и т. Д., Включите тестовые примеры для проверки правильности использования модулей.
Данные испытаний
1. Настройка тестовых данных должна быть произведена до начала тестирования.
2. Никогда не изменяйте данные в тестовой области без уведомления. Могут быть другие команды, работающие с теми же данными, и их тест не пройдет.
3. В случае, если производственные файлы необходимы во время выполнения, перед их копированием или использованием необходимо получить соответствующее разрешение.

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

В случае выполнения пакетного задания MAX CC 0 указывает на то, что задание выполнено успешно. Это не значит, что функционал работает нормально. Задание будет выполняться успешно, даже если выходные данные пусты или не соответствуют ожиданиям. Таким образом, всегда ожидается проверка всех выходных данных перед объявлением работы успешной.
Всегда рекомендуется выполнить пробный прогон тестируемой работы. Пробный прогон выполняется с пустыми входными файлами. Этому процессу следует следовать для заданий, на которые влияют изменения, внесенные в цикл тестирования.
Перед началом цикла тестирования необходимо заранее выполнить настройку тестового задания. Это поможет заранее обнаружить любую ошибку JCL и сэкономить время во время выполнения.
При доступе к таблицам DB2 через SPUFI (опция эмулятора для доступа к таблицам DB2) всегда устанавливайте для автоматической фиксации значение «NO», чтобы избежать случайных обновлений.
Доступность тестовых данных является основной проблемой при пакетном тестировании. Необходимые данные должны быть созданы задолго до цикла тестирования и должны быть проверены на полноту.
Некоторые онлайн-транзакции и пакетные задания могут записывать данные в MQ (очередь сообщений) для передачи данных в другие приложения. Если данные недействительны, это может отключить / остановить MQ, это повлияет на весь процесс тестирования. После тестирования рекомендуется проверять, что MQ работают нормально.

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

Вызовы	Подход
Неполные / неясные требования Может быть доступ к руководству пользователя / обучающему руководству, но это не то же самое, что задокументированные требования.	Тестировщики должны участвовать в SDLC начиная с этапа требований. Это поможет проверить, можно ли проверить требования.
Настройка / идентификация данных Могут возникнуть ситуации, когда существующие данные следует повторно использовать в соответствии с требованиями. Иногда бывает сложно выделить требуемые данные из существующих данных.	При необходимости для настройки данных можно использовать собственные инструменты. Для получения существующих данных следует заранее строить запросы. В случае возникновения затруднений в группу управления данными можно направить запрос на создание или клонирование необходимых данных.
Настройка задания После того, как задания загружены в PDS, задание необходимо настроить в области контроля качества. Чтобы задания не отправлялись с квалификатором производства или подробным описанием пути.	Инструменты настройки задания должны использоваться, чтобы избежать человеческих ошибок, сделанных во время настройки.
Специальный запрос Могут возникнуть ситуации, когда потребуется поддержка сквозного тестирования из-за проблем в восходящем или нисходящем приложении. Эти запросы увеличивают время и усилия в цикле выполнения.	Использование скриптов автоматизации, регрессионных скриптов и скелетных скриптов может помочь в сокращении затрат времени и усилий.
Своевременные релизы для изменения объема. Может возникнуть ситуация, когда воздействие кода может полностью изменить внешний вид системы. Это может потребовать изменения тестовых примеров, скриптов и данных.	Должен существовать процесс управления изменениями содержания и анализ воздействия.

Встречаются обычные Abends

S001 - Произошла ошибка ввода-вывода.
Причина - чтение в конце файла, ошибка длины файла, попытка записи в файл, доступный только для чтения.
S002 - Недействительная запись ввода-вывода.
Причина - Попытка записать запись длиннее, чем длина записи.
S004 - Ошибка при ОТКРЫТИИ.
Причина - неверный DCB
S013 - Ошибка при открытии набора данных.
Причина - член PDS не существует, длина записи в программе не соответствует фактической длине записи.
S0C1 - Исключение операции
Причина - Невозможно открыть файл, отсутствует карта DD
S0C4 - Исключение защиты / нарушение хранилища
Причина - попытка доступа к хранилищу, недоступному для программы.
SC07 - Исключение проверки программы - Данные
Причина - изменение макета записи или макета файла.
Sx22 - Задание отменено
S222 - Задание отменено пользователем без дампа.
S322 - Время задания или шага превысило указанный предел, или программа находится в цикле, или недостаточный параметр времени.
S522 - Тайм-аут сеанса TSO.
S806 - Невозможно связать или загрузить.
Причина - Идентификатор задания не может найти указанный загрузочный модуль.
S80A - недостаточно виртуальной памяти для удовлетворения запросов GETMAIN или FREEMAIN.
S913 - Попытка получить доступ к набору данных, который не авторизован пользователем.
Sx37 - Невозможно выделить достаточно места для хранения набора данных.

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

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

Задание прервано - для успешного завершения задания вы должны проверить данные, входной файл и модули, присутствующие в определенном месте или нет. Сбои могут возникать по нескольким причинам, наиболее распространенными из которых являются неверные данные, неправильное поле ввода, несоответствие даты, проблемы с окружающей средой и т. Д.

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

Резюме:

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

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

Содержание:

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