На первых этапах внедрения практик DevOps в программе ЕФС возникали сложности. Например, для выстраивания pipeline некоторых проектов требовалась автоматизация сквозных сценариев с использованием пластиковых карт и электронно-цифровой подписи, тогда как использование аппаратных средств, POS-терминал и Touch Memory — таблетка, накладывает значительные ограничения на автоматизацию проверок. С какими ограничениями столкнулись и как их решали, читайте под катом.
При тестировании UI тестировщик вручную выполняет шаги тест-кейсов, в ходе которых используются различные внешние устройства. Автоматизация была затруднена взаимодействием с внешними устройствами:
— в ходе внесения корректировок в данные клиентов требуется подтверждение уполномоченного сотрудника «таблеткой» (ТМ);
— при идентификации клиента по карте требуется вставить карту в POS-терминал.
Как вариант автоматизации предлагалось роботизировать процесс взаимодействия с устройствами. Однако роботизация оказалась не так доступна. Робот представлял собой механизированный хват на платформе площадью в 3 м?, который умел брать карту, вставлять ее в POS-терминал и вводить PIN. Особое препятствие использованию представляла малая точность движений руки: если карта не попадала в приемник терминала, то усилие механической руки могло ее сломать. Кроме того, управление рукой запускалось с сервера, который не был в корпоративном сегменте сети.
Следующим вариантом решили исследовать механизмы взаимодействия оборудования и программ. При анализе этих механизмов выяснилось, что связь с внешними USB-устройствами идет через зарегистрированные ActiveX-библиотеки.
Анализируя возможные пути реализации, в одном из html и js файлов встретили такую конструкцию:
Здесь явно видно, как создается объект ActiveX и вызываются его методы. В качестве эксперимента вызвали несколько методов следующим vbs-скриптом:
Получили результат:
Ошибок нет!
Получается, что если мы напишем свой ActiveX-объект и будем выдавать необходимые данные, то программа будет «думать», что она общается с «железом».
Идея в следующем: сохраняем данные, которые получаем от настоящей библиотеки, в настроечный файл, создаем фейковый ActiveX-объект с тем же именем, что и настоящий, и данные для ответа будем брать из настроечного файла.
В Visual Studio написали COM-библиотеку с именем «Signature.Processor», как в примере выше, где реализовали методы, возвращающие из тестового файла полученные ранее значения.
Данная реализация отлично работала с автоматизированной системой (АС), которая проверяет только номер носителя ЭЦП ТМ, состоящий из 8 шестнадцатеричных чисел, (JGetTmNumber) и идентификатор подписи (JIdUser). Однако новые версии модулей «научились» проверять подпись по передаваемому хэшу, который требуется подписать по настоящему.
Данный функционал криптографической подписи невозможно реализовать, считав один раз хэш и его подпись, так как при изменении хэша подпись тоже неизбежно должна измениться. Функционалом автоматизированного подписания обладает сервер ЭЦП. Однако для его использования необходимы заявки на физический доступ по локальной сети от каждого клиента, настройка администраторов непосредственно на сервере для открытия доступа, а еще требуется загрузка закрытого ключа в свободный слот. На все возможные машины, где, возможно, будет использоваться автоматизированная ЭЦП, доступ запросить нельзя. Чтобы обойти это ограничение, связанное с безопасностью, выделили отдельный сервер, через который будет осуществляться взаимодействие между рабочими станциями с тестами и сервером.
Следующая проблема — при работе с подписью через программно-аппаратный комплекс ФПСУ-IP Сервер ЭЦП нет возможности работы с ТМ, так как при запросе номера «таблетки» от самого ФПСУ возвращается пустое значение. Так как ФПСУ-IP для работы с ЭЦП использует понятие ключа (номер слота, в который загружен закрытый ключ ЭЦП), то наше решение должно эмулировать номер «таблетки». Например, все буквы «D» и в конце номер слота с ЭЦП.
В итоге получили следующее решение:
Так у нас появился гибкий инструмент для тестирования, эмулирующий физическое взаимодействие с оборудованием.
Заодно попрактиковались в Microsoft C#.
Аналогичная ситуация сложилась с POS-терминалами для банковских карт. Все взаимодействие осуществляется через ActiveX-компонент, через который вызываются различные функции терминала. Только без подводных камней.
В итоге у нас появилась возможность автоматизации сценариев на большом количестве тестовых данных, вплоть до эмуляции карты с некорректным номером или с истекшим сроком действия. Это позволило высвободить POS-терминалы в процессе автотестирования.
Что немаловажно, получили дополнительные «плюшки» — удалось решить проблемы, не связанные с автоматизацией, что очень порадовало тестировщиков:
Надеемся, этот короткий пост был для вас полезен. Как всегда, рады пообщаться и ответить на ваши вопросы в комментариях.
При тестировании UI тестировщик вручную выполняет шаги тест-кейсов, в ходе которых используются различные внешние устройства. Автоматизация была затруднена взаимодействием с внешними устройствами:
— в ходе внесения корректировок в данные клиентов требуется подтверждение уполномоченного сотрудника «таблеткой» (ТМ);
— при идентификации клиента по карте требуется вставить карту в POS-терминал.
Как вариант автоматизации предлагалось роботизировать процесс взаимодействия с устройствами. Однако роботизация оказалась не так доступна. Робот представлял собой механизированный хват на платформе площадью в 3 м?, который умел брать карту, вставлять ее в POS-терминал и вводить PIN. Особое препятствие использованию представляла малая точность движений руки: если карта не попадала в приемник терминала, то усилие механической руки могло ее сломать. Кроме того, управление рукой запускалось с сервера, который не был в корпоративном сегменте сети.
Следующим вариантом решили исследовать механизмы взаимодействия оборудования и программ. При анализе этих механизмов выяснилось, что связь с внешними USB-устройствами идет через зарегистрированные ActiveX-библиотеки.
Анализируя возможные пути реализации, в одном из html и js файлов встретили такую конструкцию:
try {
var signProcessor = new ActiveXObject("Signature.Processor");
if (typeof signProcessor.DWriteSettings != "undefined"
&& typeof signProcessor.DSignInitialize != "undefined"
&& typeof signProcessor.JSignErrorMessage != "undefined"
&& typeof signProcessor.JIdUser != "undefined"
&& typeof signProcessor.JGetTmNumber != "undefined"
&& typeof signProcessor.DSignUnInitialize != "undefined") {
return true;
} else {
return false;
}
} catch (e) {
return false;
}
Здесь явно видно, как создается объект ActiveX и вызываются его методы. В качестве эксперимента вызвали несколько методов следующим vbs-скриптом:
' запуск — c:\Windows\SysWOW64\wscript.exe "C:\term\sign.vbs"
Set MyServ = CreateObject("Signature.Processor")
MyServ.DWriteSettings
MyServ.DSignInitialize
s = "TM=" & MyServ.JGetTmNumber() & vbCrLf
s = s &"JIdUser=" & MyServ.JIdUser() & vbCrLf
wscript.stdout.writeline s
setMyServ=nothing
Получили результат:
Сервер сценариев Windows (Microsoft ) версия 5.8
Корпорация Майкрософт (Microsoft Corp.), 1996-2001. Все права защищены.
TM=06000000000000d0
JIdUser=SBTT0001uХамнуевВА ТестСБТ
Ошибок нет!
Получается, что если мы напишем свой ActiveX-объект и будем выдавать необходимые данные, то программа будет «думать», что она общается с «железом».
Идея в следующем: сохраняем данные, которые получаем от настоящей библиотеки, в настроечный файл, создаем фейковый ActiveX-объект с тем же именем, что и настоящий, и данные для ответа будем брать из настроечного файла.
В Visual Studio написали COM-библиотеку с именем «Signature.Processor», как в примере выше, где реализовали методы, возвращающие из тестового файла полученные ранее значения.
Данная реализация отлично работала с автоматизированной системой (АС), которая проверяет только номер носителя ЭЦП ТМ, состоящий из 8 шестнадцатеричных чисел, (JGetTmNumber) и идентификатор подписи (JIdUser). Однако новые версии модулей «научились» проверять подпись по передаваемому хэшу, который требуется подписать по настоящему.
Данный функционал криптографической подписи невозможно реализовать, считав один раз хэш и его подпись, так как при изменении хэша подпись тоже неизбежно должна измениться. Функционалом автоматизированного подписания обладает сервер ЭЦП. Однако для его использования необходимы заявки на физический доступ по локальной сети от каждого клиента, настройка администраторов непосредственно на сервере для открытия доступа, а еще требуется загрузка закрытого ключа в свободный слот. На все возможные машины, где, возможно, будет использоваться автоматизированная ЭЦП, доступ запросить нельзя. Чтобы обойти это ограничение, связанное с безопасностью, выделили отдельный сервер, через который будет осуществляться взаимодействие между рабочими станциями с тестами и сервером.
Следующая проблема — при работе с подписью через программно-аппаратный комплекс ФПСУ-IP Сервер ЭЦП нет возможности работы с ТМ, так как при запросе номера «таблетки» от самого ФПСУ возвращается пустое значение. Так как ФПСУ-IP для работы с ЭЦП использует понятие ключа (номер слота, в который загружен закрытый ключ ЭЦП), то наше решение должно эмулировать номер «таблетки». Например, все буквы «D» и в конце номер слота с ЭЦП.
В итоге получили следующее решение:
Так у нас появился гибкий инструмент для тестирования, эмулирующий физическое взаимодействие с оборудованием.
Заодно попрактиковались в Microsoft C#.
Аналогичная ситуация сложилась с POS-терминалами для банковских карт. Все взаимодействие осуществляется через ActiveX-компонент, через который вызываются различные функции терминала. Только без подводных камней.
В итоге у нас появилась возможность автоматизации сценариев на большом количестве тестовых данных, вплоть до эмуляции карты с некорректным номером или с истекшим сроком действия. Это позволило высвободить POS-терминалы в процессе автотестирования.
Что немаловажно, получили дополнительные «плюшки» — удалось решить проблемы, не связанные с автоматизацией, что очень порадовало тестировщиков:
- сокращение времени при ручном тестировании за счет исключения ручных манипуляций с картами после создания выделенного тестового стенда и настройки pipeline-трубы DevOps;
- сокращение времени от подачи заявки на изготовление карт с двух недель до нескольких дней. Впоследствии, реализовали скрипт подготовки тестовых карт по «малому кругу»;
- исключение необходимости транспортировки и доставки тестовых карт — сократились трудозатраты и расход материалов на эмбоссирование тестовых карт;
- при оперативном выводе нового тестировщика, например, аутсорс, отпала нужда в оборудовании рабочего места POS-терминалом и считывателем TM. Этот значительно ускорило погружение в проект!
Надеемся, этот короткий пост был для вас полезен. Как всегда, рады пообщаться и ответить на ваши вопросы в комментариях.