Так это не для дома. Это специализированная техника для определенных задач.
Думаю, что организовывать производство всех комплектующих достаточно дорого стоит. И есть ли на это компетенции. Нет ничего зазорного в кооперации. Не те объемы, чтобы строить фабрики. Это же куча людей и инженеров нужна. Чем их загружать? У нас рынок маленький.
Приветствую, господа.
Хотелось бы понимать цель тестирования.
Поделитесь опытом нагрузочного тестирования в связке с криптографией (PIN, MAC, EMV) и обвязкой с HSM. Происходит ли валидация данных в ответе?
Или мы говорим исключительно об отключении части функционала и тестировании грубо говоря запроса баланса без проверок криптографии, балансов, лимитов, лоялти, оповещения, фрод мониторинга и дале по списку. На сколько % у вас стенд приближен к продакшену?
Протестировать, к примеру динамический сценарий ATM с продакшена не тривиальная задача, еще и под нагрузкой. Просто траффик заснифирить тут не получится. На сколько вы эмулируете работу того же АТМ?.. АТМ у вас на картинке и у клиента, говорите их много, вот и интересуюсь.
Да так же все и работают. Сталкивались конечно. И читали "Как тестируют" правильные компании.
Но у нас каждый ищет свой путь(строит свой велосипед), знаете же.
Большой плюс, что у вас одна версия в продакшене, и следующая на тесте.
В нашем случае на продукте, который не менее масштабный и тиражируемый, сопровождается около трех последних активных версий и плюсом до пяти разных старых версий, которые стоят у клиентов.
Такая же примерно схема как у вас на текущей версии разработки и n-ое количество стендов под более ранние версии.
Что-то в начале писали про 5 миллионов, я так и не понял по тексту на что вы их потратили. А в целом согласен, размах тестирования зависит от целей и финансов. Руководитель всего этого также нужен. Тут вообще обеими руками «за». Никаких особых секретов то тут и нет. Просто грамотный и работающий производственный процесс.
а) обычно на практике сводится к двум методам подписи xml документов. 1 — подпись на строго заданном списке значений тэгов. Например:
<a>aa</a><b>bb</b>
— договариваемся, что подписываем строку из последовательности значений тэгов. Считаем подпись на 'aabb'. 2 — считаем подпись на всем документе или части документа как есть. Например на выходе:
<a>aa</a><b>bb</b>
на все этой строке и считаем подпись.
Нормализация подразумевает, что обе стороны должны привести документ к одному виду, и потом на нем посчитать. Но тут есть детали. Желательно, чтобы на обеих сторонах были одни и те же библиотеки, которые реализуют нормальзацию документа. Если на одной стороне самописная реализация стандарта, то приходится подгонять их под реализацию принимающей стороны. А это очень не быстро.
б) к сожалению, я сам не могу предоставить описание и демонстрационную версию, тк закрыто NDA.
Если в нескольких словах, то это программа, к которой есть доступ через web. В ней есть список обязательных кейсов, которые надо пройти. Под своим пользователем выбираем кейс, проводим его удаленно, интерфейс отображает ошибки и прошли или нет кейс. Как прошли все кейсы — создается протокол о тестировании. Подписывается и в бой. В онлайне видно и описание кейса и входящие сообщения, и ошибки. Очень экономит время с обеих сторон.
ГИС ЖКХ взаимодействует с федеральными ресурсами и кредитными организациями через систему межведомственного электронного взаимодействия (СМЭВ).
На моё субъективное мнение, тк занимался поддержкой именно этой части, как таковая отсутсвует среда для полноценного тестирования решения с интеграторами. Текущая реализация тестирования грубо говоря наколеночная.
Чего только стоит нормализация документа для подписи. Понятно, что хотелось по стандартам, но с практикой немного разошлись.
Опять таки не известно, что авторы системы проектировали до текущей системы и как учитывался опыт.
Из того, что я видел, то на мой взгляд, решение по тестированию и интеграции с внешними системами наилучшее у Билайна. Если есть возможность, посмотрите в эту сторону.
Просто спасибо за статью. Давно ждал такой статьи с производства.
Думаю, что организовывать производство всех комплектующих достаточно дорого стоит. И есть ли на это компетенции. Нет ничего зазорного в кооперации. Не те объемы, чтобы строить фабрики. Это же куча людей и инженеров нужна. Чем их загружать? У нас рынок маленький.
Приведенные цифры мало о чем говорят без этого.
Хотелось бы понимать цель тестирования.
Поделитесь опытом нагрузочного тестирования в связке с криптографией (PIN, MAC, EMV) и обвязкой с HSM. Происходит ли валидация данных в ответе?
Или мы говорим исключительно об отключении части функционала и тестировании грубо говоря запроса баланса без проверок криптографии, балансов, лимитов, лоялти, оповещения, фрод мониторинга и дале по списку. На сколько % у вас стенд приближен к продакшену?
Протестировать, к примеру динамический сценарий ATM с продакшена не тривиальная задача, еще и под нагрузкой. Просто траффик заснифирить тут не получится. На сколько вы эмулируете работу того же АТМ?.. АТМ у вас на картинке и у клиента, говорите их много, вот и интересуюсь.
Спасибо.
а как логируете и храните сообщения при работе с МПСами?
как PA\PCI DSS по всем этим проходите?
Но у нас каждый ищет свой путь(
строит свой велосипед), знаете же.Большой плюс, что у вас одна версия в продакшене, и следующая на тесте.
В нашем случае на продукте, который не менее масштабный и тиражируемый, сопровождается около трех последних активных версий и плюсом до пяти разных старых версий, которые стоят у клиентов.
Такая же примерно схема как у вас на текущей версии разработки и n-ое количество стендов под более ранние версии.
Что-то в начале писали про 5 миллионов, я так и не понял по тексту на что вы их потратили. А в целом согласен, размах тестирования зависит от целей и финансов. Руководитель всего этого также нужен. Тут вообще обеими руками «за». Никаких особых секретов то тут и нет. Просто грамотный и работающий производственный процесс.
Нормализация подразумевает, что обе стороны должны привести документ к одному виду, и потом на нем посчитать. Но тут есть детали. Желательно, чтобы на обеих сторонах были одни и те же библиотеки, которые реализуют нормальзацию документа. Если на одной стороне самописная реализация стандарта, то приходится подгонять их под реализацию принимающей стороны. А это очень не быстро.
б) к сожалению, я сам не могу предоставить описание и демонстрационную версию, тк закрыто NDA.
Если в нескольких словах, то это программа, к которой есть доступ через web. В ней есть список обязательных кейсов, которые надо пройти. Под своим пользователем выбираем кейс, проводим его удаленно, интерфейс отображает ошибки и прошли или нет кейс. Как прошли все кейсы — создается протокол о тестировании. Подписывается и в бой. В онлайне видно и описание кейса и входящие сообщения, и ошибки. Очень экономит время с обеих сторон.
На моё субъективное мнение, тк занимался поддержкой именно этой части, как таковая отсутсвует среда для полноценного тестирования решения с интеграторами. Текущая реализация тестирования грубо говоря наколеночная.
Чего только стоит нормализация документа для подписи. Понятно, что хотелось по стандартам, но с практикой немного разошлись.
Опять таки не известно, что авторы системы проектировали до текущей системы и как учитывался опыт.
Из того, что я видел, то на мой взгляд, решение по тестированию и интеграции с внешними системами наилучшее у Билайна. Если есть возможность, посмотрите в эту сторону.