Привет! Меня зовут Валерий Богданов, и я отвечаю за тестирование в команде мобильных платежей в Plat.Form World. я уже написал что в 2018 году мы запустили сервис мобильных платежей и в связи с этим примерно одновременно начали разрабатывать 2 мобильных платежных приложения:
- наше собственное приложение Мир Пай ;
- приложение, разработанное одним из наших партнеров по нашим спецификациям.
Имеются в виду мобильные приложения, предназначенные для оплаты покупок в магазинах на POS-терминал - терминалы с использованием телефона через НФК .
В связи с началом их разработки возникла необходимость наладить процесс тестирования именно платежного ядра мобильного приложения.
Платежное ядро — компонент мобильного платежного приложения, отвечающий за логику взаимодействия телефона и POS-терминал -терминал, который должен быть выполнен в строгом соответствии со спецификациями платежных систем, для управления рисками со стороны устройства (отклонение/одобрение операции) и безопасности транзакции (генерация криптограммы платежа).
Если с нашим платежным приложением все было относительно понятно, его можно было протестировать как сверху, так и снизу, то с партнерскими приложениями все было не так просто.
В данном случае у нас нет исходного кода приложения, а получить само приложение до его релиза не так-то просто.
Поэтому необходимо было создать не просто какой-то инструмент внутреннего тестирования, а целый сервис, который мог бы использоваться другими организациями и предоставлять нам полную картину функционирования тестируемого платежного ядра.
Еще на этапе аналитики был выявлен следующий важный момент: платежное ядро должно быть протестировано как можно ближе к релизной конфигурации.
Поскольку такие приложения могут подвергаться изменениям после сборки, как правило, это интеграция систем защиты приложений, например, одна из самых известных — декс-защитник , мы не можем исключить влияние такого вмешательства в приложение на работу его платежной части.
Также на работу платежного ядра потенциально могут влиять аппаратные особенности телефона или особенности операционной системы.
Например, один из телефонов вставил между командами нашего приложения команду стороннего платежного приложения, установленного на том же устройстве, а другой телефон вообще не смог корректно взаимодействовать с терминалом без изменения настроек системы.
В классическом случае такой системой может быть множество единица — тесты для разработчиков, или какой-то набор программно запускаемых скриптов — казалось бы, все очевидно и просто, но в силу ранее заявленных требований такой подход здесь неприменим.
Конечно, он не исключает единица - тестирование, любые другие этапы функционального тестирования, но в конечном итоге все должно проходить в обстановке, максимально приближенной к боевой.
Следовательно, система должна иметь возможность протестировать реальный телефон с реальным платежным приложением.
При этом тестирование должно включать в себя конкретный компонент - платежный терминал, который должен быть правильно (или неправильно, для отрицательных случаев) настроен, а так как не у всех есть такое тестовое устройство, то тестирование взаимодействия с терминалом всегда вызывало трудности.
Дело осложняется еще и тем, что не каждый разработчик или тестировщик понимает, как терминал должен взаимодействовать с телефоном, не все знают необходимые стандарты и хорошо в них разбираются.
Можно было бы тестировать, отправляя разработчикам готовые терминалы, но согласитесь, рассылайте всем огромное количество терминалов, постоянно настраивайте их, то удаленно, то возвращайте снова, при этом обучая кого-то, как ими пользоваться, как брать логи - это было бы крайне ресурсозатратно и неудобно.
Собственно, на первых этапах так и было, и изначально для тестирования ядра нужно было проделать огромное количество операций:
- разработчик выпускает версию приложения;
- настроить терминал, согласовав ключи (и это уже делают другие специалисты);
- отправить терминал разработчику;
- выполнить операцию;
- отдать терминал профильным специалистам;
- снять логи с терминала – что само по себе не так уж и просто;
- проанализировать логи и вычислить ошибку;
- создать отчет и отправить его разработчику.
Все эти шаги были необходимы, но все они требовали огромного количества времени.
Нам удалось решить эту проблему.
Система, о которой пойдет речь, позволила нам свести эту процедуру буквально к одному действию.
На основании всего вышеизложенного возникла задача создать сервис тестирования платежного ядра таким образом, чтобы для его использования не требовалось обладать специфическими знаниями в области платежных систем, не требовалось сложное специальное оборудование и чтобы результаты тестирования были понятны разработчикам.
То есть, если тест не пройден, отчеты должны содержать достаточное описание неправильного поведения для его исправления.
Учитывая все эти требования, мы выбрали формат веб-сервиса.
В нашем понимании тестировщик должен был зайти на веб-страницу и иметь возможность протестировать платежное приложение с помощью простого ПКСК -читатель.
Здесь нужно было как-то связать открытую в браузере веб-страницу с ридером — для этого было написано расширение для браузера.
Популярные браузеры позволяют наладить обмен информацией с нативным приложением с помощью расширений через стандартные потоки ввода/вывода ( Собственный обмен сообщениями в Chrome, например).
Такое приложение было реализовано; он устанавливался при установке соответствующего расширения, передавал команды читателю и возвращал ответ обратно через расширение на страницу.
Таким образом, задняя система имеет возможность общаться напрямую через НФК с телефоном удаленного пользователя.
С другой стороны, наши терминальные специалисты реализовали полностью настраиваемый виртуальный терминал, который в состоянии по умолчанию представляет собой практически полную функциональную копию.
POS-терминал -терминалы, которые мы видим в магазинах.
Задача эта тоже непростая, но благодаря нашим специалистам мы не столкнулись с какими-либо сложностями на этом этапе.
И на основе этого была реализована возможность, так сказать, совершать покупки удаленно.
То есть на странице веб-сервиса есть кнопка – оплатить.
Тестировщик может выбрать, в каком типе терминала он хочет произвести оплату (либо обычный POS-терминал -терминал, а может банкомат) и на какую сумму, после этого достаточно прикоснуться телефоном к считывателю и что именно произойдет, если он проведет операцию на реальном терминале.
Именно эта возможность на порядок сократила время внедрения ПО, существенно изменив цикл разработки.
Если раньше нужно было, как я уже говорил, разработчику выпустить версию приложения, настроить и отправить терминал, снять логи с терминала и так далее, то теперь все значительно упростилось: разработчик, даже не реально имея приложение, это всего лишь какой-то прототип на костылях, может в любой момент выполнить любую операцию и моментально получить по ней отчет вместе с разобранными логами и пояснениями к ним.
У нас появляется еще больше возможностей для автоматизации, когда мы говорим о собственном приложении — Мир Пай .
Дело в том, что наши партнеры по тем или иным причинам часто не могут предоставить нам свое приложение до его выпуска или какую-то его отладочную версию, но в случае с нашим приложением все карты в наших руках — наше приложение взаимодействует с нашими серверами.
, у нас есть исходный код и полное понимание того, как он должен себя вести.
С другой стороны, приложение было подключено к серверной заглушке, которая могла выводить в приложение любые данные, указанные в тесте, в виде профиля токена.
Так, только для платежного ядра было написано около сотни различных тестов, а также был автоматизирован процесс добавления карты в приложение.
Для этого было написано еще одно расширение для браузера, которое теперь могло выполнять скрипты А.
Д.
Б.
по команде с сервера, и эти самые команды отправлялись в нужные моменты тестирования.
То есть тестер заходит на страницу сервиса, выбирает галочками нужные тесты – например, все, кладет телефон на ридер и нажимает «Старт».
При выполнении каждого теста на телефоне с помощью команд А.
Д.
Б.
добавляются нужные карты, из штекера поступает нужный в тесте профиль и происходит обмен между телефоном и ридером.
Анализируется поведение телефона, а также логи виртуального терминала, тест помечается как пройден/не пройден, данные сохраняются, карта вынимается из телефона - то есть возвращаем все в исходное состояние и немедленно начинается следующее испытание.
При такой системе полное тестирование платежного ядра с подготовкой отчета теперь занимает не более пары часов, тогда как раньше в полуручном режиме это могло занимать до недели.
Таким образом, описанный сегодня подход позволил фактически изменить (пусть и частично) цикл разработки мобильных платежных приложений, и этап отладки платежного ядра, который раньше мог длиться месяцами, теперь занимает считанные дни.
Этот подход не ограничивается тестированием платежных приложений; потенциально его можно применить и в других случаях.
Если функционал разрабатываемого приложения включает сложное взаимодействие с какими-то другими устройствами, «не TCP »-протокол и реализован сторонним разработчиком, то вполне возможно построить что-то подобное, и, вероятно, это тоже даст тот же результат. Теги: #платежные системы #Тестирование мобильных приложений #автоматизация тестирования #платформа мира #мобильные кошельки.
#мобильный платеж #платежное ядро #MirPay
-
Важность Роли Консультанта Erp В Проекте
19 Oct, 24 -
Прилетит Ли Нло 14 Октября 2008 Года?
19 Oct, 24 -
[Ann] Унции Книги 11`2012
19 Oct, 24 -
Жж Продвигает Спонсируемые Сообщества
19 Oct, 24
