Привет! Меня зовут Антон Воробьев, я отвечаю в Альфа-Банке за разработку приложений для централизованной банковской системы.
В этом посте я расскажу, что такое приложения с зеленым экраном, зачем они нужны и как мы делали для них автотесты, написав для этого собственное решение, которое позволило ускорить автотесты в 11 раз.
Платформа AS/400 (Application System/400) родилась в 1988 году.
Первой ОС для этой платформы была OS/400, позже переименованная в i5/OS и еще позже в IBM i. Не так давно она отпраздновала свое тридцатилетие.
Погружаясь в мир разработки под операционной системой IBM i, понимаешь, что это не совсем «наследие» в классическом понимании этого слова.
Это другая, совершенно другая среда, мало похожая на привычные системы Windows или Unix. Основная цель этой ОС — быть максимально производительной на оборудовании, с которым она работает, а не быть удобной для пользователя.
ИМХО, эта ОС может свести с ума из-за того, насколько неэффективны на ней традиционные подходы к написанию кода на C++ (потери ЦП до десятков раз), что некоторые антипаттерны, демонстрируемые в учебниках, являются лучшими практиками эффективного кода, а исходные коды с датой написания 1978 год они не только без проблем собираются, но и работают как положено! Все это заставляет нас по-новому взглянуть на современные подходы к разработке программного обеспечения.
Введение
Вопрос повышения качества разрабатываемого программного обеспечения волнует каждую команду разработчиков.Этот момент не обошёл стороной одну из наших кредитных команд, задачей которой является разработка и развитие Back части модуля для автоматизированной банковской системы Misys Equation. Особенность данной АБС в том, что:
- первые версии АБС работали под предшественницей AS/400 — платформой IBM System/38 (появившейся в 1978 году) под ОС CPF — «Control Program Facility»;
- он разрабатывается с 70-х годов двадцатого века, и можно найти код, написанный еще до вашего рождения (много старого кода);
- Особенности работы с ABS обусловлены тесной интеграцией с IBM i, а за счет колоссальной обратной совместимости последней создается впечатление, что ты работаешь археологом на раскопках Великой пирамиды.
IBM я (логотип) Мы разрабатываем приложения для данной АБС (опции АБС) в соответствии со стандартом Misys ITP — Технический пакет интегратора, который предусматривает, что опция должна состоять из интерактивной программы терминального взаимодействия с конечным пользователем и реализовывать API с использованием установленного интерфейса.
для фонового выполнения.
Такие интерактивные программы, разработанные под операционной системой IBM i, исторически называются приложениями зеленого экрана и являются единственным пользовательским интерфейсом, с которым взаимодействует пользователь этой АБС.
Что такое приложение с зеленым экраном?
Простой ответ — это приложение, которое выглядит следующим образом:
Или Так :
Зачем нам нужны приложения с зеленым экраном?
Исторически сложилось так, что единственными интерактивными приложениями, работавшими на системах семейства AS/400 низкого и среднего уровня и других мэйнфреймах IBM, которые позволяли запрашивать любой пользовательский ввод, были приложения с зеленым экраном.Установка, администрирование, настройка и разработка операционной системы IBM i (и ее предшественников i5/OS и AS400) выполнялись (а в некоторых случаях до сих пор выполняются) исключительно с использованием приложений зеленого экрана.
Изображения приложений с зеленым экраном доступны в двух размерах — 24x80 и 27x132 символов и в 16 возможных цветах.
В рамках этих масштабов выполняется большая часть работы разработчиков и пользователей данной операционной системы.
Такие размеры экрана являются результатом эволюции «рабочих станций», к которым подключались прародители AS400 из бюджетного и среднего бизнес-сегмента — IBM System/32, System/34, System/36 и System/.
38 компьютеров.
Эти рабочие станции назывались терминалами и состояли из экрана в металлическом корпусе с клавиатурой и дополнительного оборудования в виде светового пера.
Изначально поддерживалось только два цвета экрана — зеленый и ярко-зеленый, что породило в англоязычной литературе устоявшееся словосочетание «приложение с зеленым экраном».
В 1970-х годах количество поддерживаемых цветов увеличилось до 16. 
5251 Дисплейная станция, модель 11
Наиболее распространенными вариантами терминалов были 5251 Display Station Model 1 (960 символов на экране) и Model 11 (1920 символов на экране) с размерами Ширина/Глубина/Высота, равными 530/400/400 мм соответственно, и массой 34 кг.
Разрешение экрана модели 1 составляло 12x80, модели 11 — 24x80. Терминал был подключен напрямую к хост-системе.
Также довольно распространенными были терминалы 5251 Display Station Model 2 (960 символов на экране) и Model 12 (1920 символов на экране) с большими габаритами и весом 45 кг.
От Модели 1 и Модели 11 их отличает возможность «пробрасывать» восходящее соединение через себя на хост-машину от более дешевых клиентов в виде терминалов Модели 1 (или 11) с настольными принтерами или отдельным напольным принтером.
Таким образом, модели 2 и 12 выполняли роль хаба, проксируя подключение к хосту от устройств, которым требовалось прямое соединение с хост-машиной, и были существенно дороже.
Терминалы серии 5252 Dual Display Station современному обывателю также покажутся необычными.
Рекламное изображение из брошюры «Оборудование и программы IBM System/38 (5252 Dual Display Station)»
Цена одного комплекта терминала с подключенным к нему принтером может достигать нескольких тысяч долларов США.
Терминалы были подключены с помощью твинаксиальный кабель к хост-машине с топологией типа «шина» в полудуплексном режиме со скоростью передачи до 1 Мбит/с.
По твинаксиалу можно подключить максимум 6 терминалов, причем максимальный терминал от хоста должен находиться на расстоянии не более 1500 метров.
Номер каждого терминала указывается при его установке тремя переключателями, что определяет уникальный адрес внутри шины.
При наличии действующей коаксиальной сети можно использовать переходники с твинаксиального кабеля на коаксиальный и соответствующий набор кабельных наконечников для обжима.
При такой схеме можно было подключить к шине всего два устройства с максимальной длиной сегмента до 30 метров.
Общее количество подключаемых устройств варьировалось в зависимости от модели от десятка до нескольких десятков.
По мере развития настольных систем и сетей доступа на смену громоздким терминалам пришли рабочие станции, где в качестве средств доступа к хост-машине использовались различные карты расширения сторонних производителей, поддерживающие прямое соединение через твинаксиал.
После того, как компания IBM в 1984 году разработала технологию Token Ring, появились программные решения для доступа к машине, в том числе через этот интерфейс.
Адаптер шины 5250–ISA (производитель неизвестен) 
Карты адаптера Blackbox 5250 (PC470C, PC471C, PC472C, PC473C, PC478C)
Эмуляторы для MS-DOS и MS Windows появляются как от IBM, так и от сторонних производителей, включая реализации OpenSource (например, tn5250j.sourceforge.net).
В середине 90-х годов стек TCP/IP появился в мире бизнес-машин среднего и бюджетного уровня.
Для поддержки доступа к хост-машинам с использованием нового протокола IBM разрабатывает программные эмуляторы для терминалов серии 5250.
Для создания протокола обмена с хост-системой IBM разрабатывает
расширения протокола Telnet (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), называемые под общим названием Telnet5250 (TN5250), которые описывают процесс получения и передача потоков 5250 потоков данных по стандартному протоколу Telnet. 
Установщик IBM Client Access/400 для Windows 3.1
Что особенного в IBM 5250?
Особенностью терминалов IBM 5250 (и, соответственно, протокола TN5250) является его блочно-ориентированный в отличие от обычных терминалов *nix, которые ориентированный на характер .Это значит, что 5250 потоков данных, с помощью которых хост общается с терминалом, передаются блоками данных, и один символ в них без контекста передаваемого блока не имеет смысла.
Например, хост-машина передает терминалу блок данных, содержащий отображаемую на экране статическую информацию вместе с атрибутами и координатами полей ввода и указанием смещения в этом блоке, куда записывать результат пользовательского ввода в поля.
.
После этого хост-машина ожидает сообщений от терминала и больше не участвует в процессе пользовательского ввода.
ЭВойти в систему хостера IBM i RZKH.de (pub400.com)
Далее задача эмулятора терминала — интерпретировать блок данных с машины и создать для пользователя экран ввода, где ему предоставляется возможность ввести некоторую информацию в разрешенные поля.
В задачи эмулятора терминала также входит реагирование на действия пользователя.
Клавиши F1-F24 (F13-F24 имитируются с помощью SHIFT+Fx), Enter, Home, End, PageUp, PageDn и некоторые другие специальные клавиши, которых нет на современных клавиатурах, считаются клавишами хоста.
Это означает, что при нажатии этой клавиши на хост для обработки будет отправлен буфер потока с информацией из полей ввода и положением курсора на экране, предварительно заполненный эмулятором терминала.
Дамп попытки входа в WIreshark 5250 Data Stream на pub400.com
Хост получает буфер, анализирует его и результат ввода передается программе, запросившей ответ пользователя, для дальнейшей проверки данных и продолжения работы приложения, при этом приложению передается код нажатой клавиши хоста.
Зачем вообще существует автотестирование?
Мы начали задумываться об автоматизации ручного тестирования приложений зеленого экрана, когда столкнулись с необходимостью тестировать сотни экранов разрабатываемого модуля, где на одном экране могло быть до восьмидесяти различных бизнес-проверок (валидаций).Особой болью, с которой столкнулась команда, стало практически полное отсутствие инструментов автотестирования зеленого экрана на 2017 год, за исключением собственного решения.
УиПатх .
Даже сегодня таких решений не так много; автор знает Automate из HelpSystems и расширение JMeter для BlazeMeter (был бы рад услышать о других подобных продуктах).
Первое исследование проблемы
Стандартный эмулятор терминала TN5250, устанавливаемый на рабочих местах банка, является решением IBM. Личное общение для Windows 6.0 (PCOMM 6.0).Коллеги обнаружили, что данный продукт имеет стандартные средства автоматизации управления им в виде множества API, а именно:
- Язык прикладного программного интерфейса высокого уровня (HLLAPI);
- Улучшенный HLLAPI;
- Windows HLLAPI;
- Клиентская библиотека хост-доступа (HACL).
где первый параметр — указатель на числовой номер исполняемой функции, два других — ее аргументы, зависящие от контекста вызываемой функции, а последний — результат выполнения функции.long hllapi (LPWORD, LPSTR, LPWORD, LPWORD);
То есть, чтобы запросить статус соединения «А» (сеансы в эмуляторе нумеруются латинскими буквами от «А» до «Z»), нужно запустить следующий код (взято из документации IBM): #include "hapi_c.h"
struct HLDQuerySessionStatus QueryData;
int Func, Len, Rc;
long Rc;
memset(QueryData, 0, sizeof(QueryData)); // Init buffer
QueryData.qsst_shortname = 'A'; // Session to query
Func = HA_QUERY_SESSION_STATUS; // Function number
Len = sizeof(QueryData); // Len of buffer
Rc = 0; // Unused on input
hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI
if (Rc != 0) { // Check return code
// .
Error handling
}
Количество функций, доступных для вызова таким способом, составляет около 60.
Интерфейс WinHLLAPI немного расширяет этот функционал несколькими дополнительными функциями, позволяющими прописывать функции обратного вызова для асинхронных вызовов с целью оповещения о событиях установления соединения с хостом, отключения от хоста, изменения данных на экране терминала и т.п.
Интерфейс клиентской библиотеки доступа к хосту (HACL) казался более удобным в работе, поскольку вместо вызова «функции с одним именем» он предоставлял возможность объектно-ориентированной иерархии классов, которая позволяла полностью имитировать любое действие пользователя.
Иерархия классов библиотеки классов эмулятора из HACL (C++)
Реализации HACL доступны для C++, Java, LotusScript и COM Automation Server для Windows (полезно для Visual Basic и .
NET).
Первый прототип
Из-за огромной сложности протокола потока данных 5250 и крайне скудной информации о его внутренней структуре со ссылками на закрытую платную литературу от IBM, стало очевидно, что разработка собственного эмулятора — дело крайне нетривиальное и трудоемкое.В связи с этим возникла идея использовать промежуточный слой, который позволил бы управлять эмулятором терминала в рамках минимально необходимого функционала, в частности «ввести значение в поле», «проверить часть экрана стандартным» или «нажмите клавишу хоста F22».
Коллеги, ранее использовавшие интерфейсы HACL, утверждали (и поиск на StackOverflow подтвердил), что COM-объект имеет проблемы со стабильностью и может зависать после выполнения определенного количества команд. Помог только перезапуск процесса сервера автоматизации.
Быстрый анализ версии Java показал, что она использует Wrapper поверх интерфейса C++ через JNI. Поэтому выбор пал на интерфейс C++.
Соответствующие файлы заголовков и файлы .
lib были доступны в каталоге установки самого Personal Communications For Windows. Первый прототип был основан на Qt5, где можно было выполнять код JavaScript через QtScript. В среде исполняемого скрипта был зарегистрирован объект с небольшим количеством методов, которые позволяли выполнять команды в эмуляторе терминала так, как если бы их выполнял человек (ввод поля, нажатие клавиш хоста, ожидание завершения строки).
появиться на экране).
Мы продемонстрировали живую «демо», где написали пользовательский сценарий для запуска приложения с зеленым экраном из Equation ABS и проверки реакции приложения на неправильный ввод в поля.
Демонстрация показала, что прототип удался и можно двигаться дальше.
Внешний вид соседа
Одновременно с демонстрацией первого прототипа коллеги из другого отдела собрали связку Ruby+Ccucumber+ Quick3270 + Рубиновый модуль ( сыр/te3270 ).В предлагаемой версии используется модуль Ruby, который взаимодействует с эмулятором терминала Quick3270 от DN-Computing через свои специализированные COM-объекты (несовместимые с HACL-интерфейсами).
Это было полноценное решение для автотестирования приложений с зеленым экраном в стиле BDD, с небольшим количеством заранее описанных шагов.
Однако в предложенном решении нас насторожило следующее:
- Мы использовали сторонний платный эмулятор не от IBM (все эмуляторы работают немного по-другому, и нужно проверять работу на регулярно используемых в банке, цена ошибки невероятно высока);
- Реализация шагов Cucumber для Quick3270 использовала большое количество ожиданий ответа от машины;
- Очень низкая производительность Quick3270 через интерфейс автоматизации (работа с HACL в прототипе через интерфейс C++ выглядела гораздо динамичнее).
Эмулятор терминала Quick3270 На основе прототипа мы решили попробовать реализовать собственный сервер автоматизации для подключения Cucumber к Personal Communications for Windows и спроектировать шаги таким образом, чтобы время простоя между действиями на экране эмулятора было минимальным.
Лирическое отступление .
Несмотря на то, что вокруг якобы «наследия» IBM существует огромное количество технических проблем, которые, казалось бы, уже должны были быть решены для систем среднего и корпоративного уровня, актуальность адаптации и переноса существующих технических решений очень высок просто потому, что их нет на платформе.
Зачастую отсутствие связано с самими особенностями работы этой ОС, которая принципиально отличается от современных *nix, Windows или MacOS X, что требует значительной оптимизации программного обеспечения под этот стек.
Собственное решение
В качестве собственного решения мы создали сервер автоматизации как развитие ранее продемонстрированного прототипа.Этот сервер выполняет команды для автоматизации взаимодействия с потребителями через сервер RPC (Qt5 WebSocket).
Он взаимодействует с Personal Communications for Windows, входящим в состав корпоративного образа ОС Windows, и позволяет:
- запуск/остановка сеансов эмулятора терминала;
- выполнить очистку зеленого экрана;
- поиск полей ввода на экране;
- управлять курсором и имитировать нажатия клавиш (в том числе нажатия клавиш хоста);
- и так далее.
Запуск сервера автоматизации Однако при всех преимуществах HACL API у него есть один недостаток — он совершенно не умеет работать со встроенной в ОС СУБД DB2 for i и не позволяет выполнять команды, необходимые для построения макетной среды, в которой выполняется тестовый скрипт. будет казнен.
Если существует клиент DB2 для Ruby от IBM, то клиент для сервера для удаленного выполнения команд «Сервер удаленных команд и распределенных вызовов программ» доступен только для Java в виде библиотеки.
JTOpen : версия с открытым исходным кодом IBM Toolbox for Java (также известная как jt400).
Решение этой проблемы мы «подсмотрели» у самой IBM, проанализировав поведение ее продуктов со схожим функционалом (в частности, Personal Communications for Windows Data Transfer, iSeries to PC/PC to iSeries Transfer и т. д.).
Оказалось, что эти продукты в своей реализации работают под управлением IBM JRE 6 или 8, в зависимости от версии приложения, и используют библиотеку jt400. Для сервера автоматизации мы решили сделать то же самое.
IBM JVM, входящая в состав Personal Communications for Windows, работает через JNI. Используя специальные методы-обертки, команды RPC-сервера, поступающие извне, выполняются путем проксирования их в вызовы необходимой функциональности jt400. Поскольку последний также содержит драйвер JDBC для DB2, было решено использовать его для доступа к СУБД на IBM i. Важно отметить, что при использовании HACL нельзя использовать Oracle JVM. Если вы запускаете сеанс эмулятора терминала, попытка создать экземпляр виртуальной машины завершится сбоем.
Аналогично, если запустить Oracle JVM в адресном пространстве процесса, взаимодействующего с HACL, последний зависает без объяснения причин.
Со временем решение внедрялось на все большем количестве рабочих мест. Это было быстрее, чем решение Quick3270. Популярность возросла, как и количество автоматизированных тестов.
Однако в процессе эксплуатации возникли дополнительные трудности:
- -Периодические зависания терминала;
- Невозможность работы на регрессионном стенде из-за того, что эмулятор терминала отказывался запускаться, если рабочий стол пользователя, под которым запускается эмулятор, заблокирован или его RDP-сессия неактивна;
- только для Windows;
- Сложная процедура установки, настройки и обновления инструментов (через msi-пакет);
- Наш цикл регрессии на 130 автотестах (около 4000 шагов) стал занимать 7-8 часов.
Надо что-то сделать.
За счет анализа журналов трассировки многочисленных запусков автотестов и поиска узких мест в выполнении часто используемых шагов общее время выполнения регрессии сократилось до 4-5 часов.
Но было ясно, что использование промежуточного слоя в виде сервера автоматизации RPC в связке с интерфейсом HACL, который, помимо всего прочего, имеет «плавающие» ошибки, накапливающиеся за время работы всей системы, не поможет в улучшение производительности решения.
С другой стороны, в качестве альтернативы IBM Personal Communications for Windows поставщик предлагает кроссплатформенное решение под названием IBM i Access — клиентские решения.
IBM i Access — клиентские решения
Анализ его внутренней работы за чашкой кофе в субботу и воскресенье утром показал, что его кодовая база была построена на другом продукте IBM под названием IBM. Хостинг по требованию (ИБМ ХОД).
Это комплексное решение для доступа к IBM i, разработанное на Java 6, которое не только имеет полную реализацию различных протоколов связи, используемых в машинах IBM (TN3270, TN5250, VTxxx и т. д.), но и высокоуровневый пользовательский интерфейс Java-Swing. компоненты, используемые для создания собственных эмуляторов терминала в виде конструктора, который можно собрать за мизерную стоимость документация ИБМ.
Более детальное изучение IBM HOD показало, что компоненты пользовательского интерфейса построены на основе Java-реализации интерфейса HACL, документация по которой открыта.
Их поведение совпадает лишь с небольшими отличиями от документации C++ HACL. 
IBM Host On-Demand (логотип)
Далее мы создали библиотеку Java для внутреннего использования, которая реализует тот же интерфейс, что и сервер автоматизации C++ RPC, но внутри полностью использует IBM HOD. Чтобы сократить накладные расходы при выполнении шагов автотестирования, мы перешли с Ruby Cucumber на огурец-jvm с повторной реализацией всех шагов, аналогичных опциям Ruby. Учитывая наличие программного интерфейса, аналогичного RPC-серверу, это было несложно, особенно с учетом того, что мы старались сдерживать неконтролируемый рост количества самих шагов и наше значение составляло в районе 30 единиц.
Каков результат?
В результате мы добились того, чтобы все автотесты работали, не меняя их, а скорость работы стала настолько высокой, что пришлось вводить искусственную задержку между шагами, чтобы при разработке автотеста мы могли наблюдать за его работой, иначе UI не имел бы пора дорисовать экран до конца.Уже существующие 180 автотестов с более чем 16 000 шагов с установленной задержкой 60 мс между шагами стали выполняться примерно за 30 минут против 5 часов 30 минут, что соответствует одиннадцатикратному увеличению производительности регрессионного стенда.
Результаты превзошли все ожидания.
Мы приблизились к физическим ограничениям протокола TN5250. На сегодняшний день решение опубликовано по всему банку, к доработке подключились коллеги из других городов.
Среди последних изменений: коллеги интегрируют решение с Jenkins; в тестовой версии завершено тестирование запуска на Linux-сервере с Xvfb и начат этап опытной эксплуатации запуска автотестов на нем.
Спасибо, что дочитали до конца! Всем удачи! P.S. В декабре 2018 года еще один Конференция разработчиков IBMi, на котором, среди прочего, был сделан доклад по теме данной статьи.
До сих пор мы проводили ежегодную конференцию только для сотрудников Банка.
С 2019 года мы будем приглашать участников из других компаний.
Очень интересно расширить круг профессионального и личного общения, поделиться эмоциями, знаниями и опытом.
Теги: #ИТ-история #тестирование #C++ #Тестирование ИТ-систем #автотесты #AS400 IBMi iSeries огурец #зеленый экран #приложения зеленого экрана
-
Продавец Без Опыта: Брать Или Не Брать?
19 Oct, 24
