Опыт «Мира»: как снизить время тестирования платежного ядра мобильного приложения с недели до пары часов

Валерий Богданов

руководитель группы тестирования в команде мобильных платежей Mир Plat.form

Привет всем! Меня зовут Валерий Богданов, в сфере разработки ПО я работаю уже более 12 лет и сейчас занимаю должность руководителя группы тестирования в команде мобильных платежей Mир Plat.form – ИТ-бренде, объединяющем все технологические проекты Национальной системы платежных карт (НСПК). Каждый из вас уже пользуется ими, даже если сам никогда не задумывался об этом. Сотни наших специалистов обеспечивают бесперебойность и доступность операций по картам международных платежных систем в России, платежной системы «Мир», обеспечивают операционную функцию для Системы быстрых платежей и работают над созданием инновационных платёжных решений.

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

Предыстория

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

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

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

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

Изначально для его тестирования нужно было сделать огромное количество операций:

• разработчику выпустить версию приложения;
• настроить терминал, согласовав ключи (а это делают уже другие специалисты);
• отправить терминал разработчику;
• провести операцию;
• отдать терминал профильным специалистам;
• снять логи с терминала (что само по себе не так-то просто);
• проанализировать логи и вычислить ошибку;
• сформировать отчет и отправить его разработчику.

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

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

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

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

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

В классическом случае, такая система могла бы представлять собой набор unit-тестов для разработчиков, или какой-нибудь набор программно-запускаемых сценариев. Казалось бы, все очевидно и просто, но в силу ранее обозначенных требований такой подход здесь неприменим.

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

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

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

Как проводить тесты за несколько часов

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

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

Таким образом, у бэка системы появилась возможность напрямую общаться по NFC с телефоном удаленного пользователя. И на основе этого была реализована возможность, скажем так, удаленно совершать покупки.

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

Вот именно эта возможность на порядок сократила сроки реализации ПО, существенно изменив цикл разработки.

После этого все очень сильно упростилось: разработчик без приложения, имея лишь какой-то прототип «на костылях», может в любой момент провести операцию и мгновенно получить отчет по ней вместе с распарсеными логами.

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

Для этого мы предусмотрели ролевую модель, которая подразумевает разделение пользователей по организациям и включает в себя:

• роль администратора НСПК — он определяет, какой набор операций сможет проводить та или иная организация, заводит профиль организации и добавляет в нее операторов и администраторов организаций;
• администраторы организаций — могут заводить операторов только для своей организации;
• операторы — собственно тестировщики или разработчики, которые могут проводить тесты.

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

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

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

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

Таким образом было написано порядка сотни различных тестов на одно только платежное ядро, а процесс заведения карты в приложение тоже был автоматизирован.

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

Для этого было написано еще одно расширение для браузера, которое теперь могло выполнять скрипты ADB по команде с сервера, которые отправлялись в нужные моменты тестирования.

То есть, тестировщик заходит на страницу сервиса, выбирает галочками нужные тесты. Например, все, кладет телефон на считыватель и нажимает «Пуск». При выполнении каждого теста на телефон, посредством команд ADB добавляются нужные карты, от заглушки бэка приходит нужный в тесте профиль, и происходит обмен между телефоном и считывателем. Анализируется поведение телефона, а также логи виртуального терминала, тест отмечается, как пройден/не пройден, данные сохраняются, карта с телефона удаляется, то есть приводим все в исходное состояние и тут же начинается следующий тест.

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

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