Всем привет! Добро пожаловать на мой Телеграм канал. Меня зовут Александр. Здесь я планирую делиться интересными ресурсами на темы тестирования, автоматизации и инжиниринга сложных распределенных систем.
#paper #blockchain
Блокчейн системы не так-то просто тестировать.
Можно тестировать end-to-end взаимодействие с системой через различного рода кошельки.
Можно тестировать работу смарт контрактов и репликацию транзакций между нодами в сети.
Но один из самых важных аспектов тестирования блокчейн систем - это протоколы консенсуса (Proof Of Work, Proof of Stake, Proof of Elapsed Time и др.).
Различные системы конкурируют между собой, чтобы предложить более защищенные и быстрые протоколы.
Но как сравнить, что один протокол консенсуса лучше другого?
В данной работе описан подход к созданию блокчейн симулятора - который позволяет замерять базовые метрики "идеальной" системы и дальше изменять протоколы и смотреть как протоколы влиять на производительность системы.
https://digitalcommons.odu.edu/cgi/viewcontent.cgi?article=1050&context=vmasc_pubs
Под "базовыми" метриками, авторы понимают такие: пропусная способность (throughput), задержка (latency), отказоустойчивость (fault tolerance) и неоднородность (heterogeneity).
Симулятор “под капотом” запускает сеть узлов в виде отдельных Docker контейнеров.
Звучит интересно.
Блокчейн системы не так-то просто тестировать.
Можно тестировать end-to-end взаимодействие с системой через различного рода кошельки.
Можно тестировать работу смарт контрактов и репликацию транзакций между нодами в сети.
Но один из самых важных аспектов тестирования блокчейн систем - это протоколы консенсуса (Proof Of Work, Proof of Stake, Proof of Elapsed Time и др.).
Различные системы конкурируют между собой, чтобы предложить более защищенные и быстрые протоколы.
Но как сравнить, что один протокол консенсуса лучше другого?
В данной работе описан подход к созданию блокчейн симулятора - который позволяет замерять базовые метрики "идеальной" системы и дальше изменять протоколы и смотреть как протоколы влиять на производительность системы.
https://digitalcommons.odu.edu/cgi/viewcontent.cgi?article=1050&context=vmasc_pubs
Под "базовыми" метриками, авторы понимают такие: пропусная способность (throughput), задержка (latency), отказоустойчивость (fault tolerance) и неоднородность (heterogeneity).
Симулятор “под капотом” запускает сеть узлов в виде отдельных Docker контейнеров.
Звучит интересно.
#testing #blockchain
Продолжая тему тестирования блокчейна. Я тут собираю список инструментов, видео, блог постов и академических работ по теме - https://github.com/alexromanov/awesome-blockchain-testing По мере свободного времени - изучаю их и буду готовить ревью). Если у Вас есть что-то интересное, чего нет в списке - делайте ПР, буду крайне рад.
Продолжая тему тестирования блокчейна. Я тут собираю список инструментов, видео, блог постов и академических работ по теме - https://github.com/alexromanov/awesome-blockchain-testing По мере свободного времени - изучаю их и буду готовить ревью). Если у Вас есть что-то интересное, чего нет в списке - делайте ПР, буду крайне рад.
GitHub
GitHub - alexromanov/awesome-blockchain-testing: Curated list of blog posts, videos and resources on testing blockchains and blockchain…
Curated list of blog posts, videos and resources on testing blockchains and blockchain-based applications - alexromanov/awesome-blockchain-testing
Что значит “тестировать блокчейн”?
#testing #blockchain
Блокчейн - это “хайповая тема” последних лет. Каждый второй делает свою криптовалюту, каждый третий открывает криптовалютный обменник на углу.
Чтобы получше понять, зачем этот самый блокчейн нужен, очень рекомендую статью Вастрика на эту тему
Но что значит “тестировать блокчейн” ? Насколько глубокими и техническими должны быть знания тест инженера для работы с такими системами? Давайте разберемся вместе.
Тестирование блокчейна как системы.
Самый “хардкорный” вариант. В данном случае тестируется блокчейн сеть целиком - как целостное решение. Примеры - Bitcoin, Ethereum.
Тестируем:
- сохранение транзакций в блоки и связь между ними
- криптографические протоколы хеширования и генерация ключей
- репликацию данных между узлами в сети
- алгоритмы консенсуса
- производительность системы
- безопасность системы
- отказоустойчивость системы
Тестирование приложений, построенных на базе блокчейна.
Тут мы имеем дело с обычными Веб и Мобильными приложениями, у которых одна из функций - это сохранять или читать что-то из блокчейн сети.
Связь с блокчейном на бекенде происходит через API запросы. Часто это не HTTP REST API, а что-то более специфическое, такое как gRPC.
API может быть как сторонней системой вообще, так и просто узлом блокчейн сети, который развернут внутри системы.
Кроме того, остальные подходы к тестированию и автоматизации приложений - сохраняются:
- функциональное и нефункциональное тестирование
- UI / API тесты (и автотесты)
Тестирование блокчейн кошельков.
Кошельки - это приложения, которые хранят информацию о ваших паролях и дают возможность покупать и продавать криптовалюту. Они могут быть как в виде веб или мобильных приложений, так и декстопные.
Основной аспект при тестировании - это использование специальных тестовых (TESTNET) блокчейн сетей для проведения транзакций. В таких сетях валюта технически такая же, как и реальная - но не стоит ничего.
Кроме того, могут быть еще и специфические виды кошельков в виде отдельных электронных устройств. А это отдельный интересный мир embedded девайсов.
Тестирование смарт контрактов и прочего DeFi.
Смарт контракты - это программный код, который релизует некую бизнес логику и загружен на блокчейн. Чаще всего под смарт контрактами имеют в виду код на языке Solidity в блокчейне Ethereum.
Тут подходы к тестированию как стандартные, так и необычные:
- юнит тесты
- функциональные тесты
- тесты безопасности
Необычность тестирования в том, что как только код отправлен в блокчейн (“задеплоен на прод”) - он начинает работать сразу. Его крайне сложно “остановить”. А уж удалить и “передеплоить” - так вообще невозможно.
Тестирование криптовалютных бирж
Биржы это обычно веб (или мобайл) приложения, который позволяют завести там аккаунт и заниматься торговлей и конвертацией разных криптовалют.
Очень похожи по своей сути на обычные сайты по банкингу и работе с валютой.
Основная сложность тестирования здесь - это интеграция с апи многих сотен (а то и тысяч) реализаций блокчейнов. Поэтому готовьтесь к ошибкам интеграции ибыстрым фиксам.
#testing #blockchain
Блокчейн - это “хайповая тема” последних лет. Каждый второй делает свою криптовалюту, каждый третий открывает криптовалютный обменник на углу.
Чтобы получше понять, зачем этот самый блокчейн нужен, очень рекомендую статью Вастрика на эту тему
Но что значит “тестировать блокчейн” ? Насколько глубокими и техническими должны быть знания тест инженера для работы с такими системами? Давайте разберемся вместе.
Тестирование блокчейна как системы.
Самый “хардкорный” вариант. В данном случае тестируется блокчейн сеть целиком - как целостное решение. Примеры - Bitcoin, Ethereum.
Тестируем:
- сохранение транзакций в блоки и связь между ними
- криптографические протоколы хеширования и генерация ключей
- репликацию данных между узлами в сети
- алгоритмы консенсуса
- производительность системы
- безопасность системы
- отказоустойчивость системы
Тестирование приложений, построенных на базе блокчейна.
Тут мы имеем дело с обычными Веб и Мобильными приложениями, у которых одна из функций - это сохранять или читать что-то из блокчейн сети.
Связь с блокчейном на бекенде происходит через API запросы. Часто это не HTTP REST API, а что-то более специфическое, такое как gRPC.
API может быть как сторонней системой вообще, так и просто узлом блокчейн сети, который развернут внутри системы.
Кроме того, остальные подходы к тестированию и автоматизации приложений - сохраняются:
- функциональное и нефункциональное тестирование
- UI / API тесты (и автотесты)
Тестирование блокчейн кошельков.
Кошельки - это приложения, которые хранят информацию о ваших паролях и дают возможность покупать и продавать криптовалюту. Они могут быть как в виде веб или мобильных приложений, так и декстопные.
Основной аспект при тестировании - это использование специальных тестовых (TESTNET) блокчейн сетей для проведения транзакций. В таких сетях валюта технически такая же, как и реальная - но не стоит ничего.
Кроме того, могут быть еще и специфические виды кошельков в виде отдельных электронных устройств. А это отдельный интересный мир embedded девайсов.
Тестирование смарт контрактов и прочего DeFi.
Смарт контракты - это программный код, который релизует некую бизнес логику и загружен на блокчейн. Чаще всего под смарт контрактами имеют в виду код на языке Solidity в блокчейне Ethereum.
Тут подходы к тестированию как стандартные, так и необычные:
- юнит тесты
- функциональные тесты
- тесты безопасности
Необычность тестирования в том, что как только код отправлен в блокчейн (“задеплоен на прод”) - он начинает работать сразу. Его крайне сложно “остановить”. А уж удалить и “передеплоить” - так вообще невозможно.
Тестирование криптовалютных бирж
Биржы это обычно веб (или мобайл) приложения, который позволяют завести там аккаунт и заниматься торговлей и конвертацией разных криптовалют.
Очень похожи по своей сути на обычные сайты по банкингу и работе с валютой.
Основная сложность тестирования здесь - это интеграция с апи многих сотен (а то и тысяч) реализаций блокчейнов. Поэтому готовьтесь к ошибкам интеграции и
vas3k.blog
Блокчейн изнутри: как устроен биткоин
Разбираемся раз и навсегда человеческим языком
Test Engineering Notes pinned «Что значит “тестировать блокчейн”? #testing #blockchain Блокчейн - это “хайповая тема” последних лет. Каждый второй делает свою криптовалюту, каждый третий открывает криптовалютный обменник на углу. Чтобы получше понять, зачем этот самый блокчейн нужен, очень…»
Как “быстро” проверить gRPC сервис?
#grpc #testing #tools
HTTP API приходится тестировать часто. Можно быстро сделать запрос с помощью cURL. Можно написать пару тестов на Java+RestAssured. Можно не усложнять - и использовать Postman.
Но что делать, когда надо быстро проверить работу сервиса, а он работает не по HTTP, а по gRPC? Как быть?
Postman судя по всему довольно криво поддерживает gRPC.
Генерировать клиент на основе протобафа и писать почти полноценный сервис для проверки одного-двух запросов - слишком долго и сложно.
На помощь приходит простой и удобный инструмент - grpcurl Он позволяет делать запросы на Ваши сервиса очень похоже, как бы Вы делали это с помощью cURL.
Перед использованием, убедитесь, что reflection включен на серверной стороне. Иначе, работать запросы не будут.
Для тех, кто не хочет связываться с терминалом - есть UI надстройка для grpcurl - gRPCox.
#grpc #testing #tools
HTTP API приходится тестировать часто. Можно быстро сделать запрос с помощью cURL. Можно написать пару тестов на Java+RestAssured. Можно не усложнять - и использовать Postman.
Но что делать, когда надо быстро проверить работу сервиса, а он работает не по HTTP, а по gRPC? Как быть?
Postman судя по всему довольно криво поддерживает gRPC.
Генерировать клиент на основе протобафа и писать почти полноценный сервис для проверки одного-двух запросов - слишком долго и сложно.
На помощь приходит простой и удобный инструмент - grpcurl Он позволяет делать запросы на Ваши сервиса очень похоже, как бы Вы делали это с помощью cURL.
Перед использованием, убедитесь, что reflection включен на серверной стороне. Иначе, работать запросы не будут.
Для тех, кто не хочет связываться с терминалом - есть UI надстройка для grpcurl - gRPCox.
Postman
Postman: The World's Leading API Platform | Sign Up for Free
Unify API design, testing, documentation, and monitoring in one platform. Build, collaborate, and innovate faster with seamless Git and gateway integrations.
Почему gRPC тестировать несколько сложнее, чем обычный HTTP REST?
#grpc #testing
АПИ тестирование и автоматизация уже давно не “магия”. Львиную долю АПИ, которое проходится тестировать составляет HTTP REST. Изредка “завозят” что-то посложнее - например веб сокеты.
Когда тестировщик проводит проверку АПИ, тесты сводятся к следующим шагам:
1. Отправь один запрос (GET, POST, PUT, DELETE, etc) на сервер
2. Получи один ответ от сервера (в разумное время)
3. Проверь содержание ответа
Как валидация будет происходить (cURL’ом, Postman’ом, кодом) - не так важно.
В случае с gRPC ситуация несколько усложняется:
- данные передаются в бинарном виде. Значит просто так в консоли браузера запросы не посмотришь. (Нужен прокси).
- передача данных между клиентом и сервером в виде унарных запросов (один запрос - один ответ) - это лишь один из возможных вариантов коммуникации
Методы коммуникации в gRPC, которых нет в HTTP REST:
- Server Streaming RPC. Клиент отправляет один запрос серверу, а в результате получает поток ответов. Клиент в этом случае сам решает, читать ли до конца потока или до наступления иного события (таймаута по времени или наличия специфического поля в ответе)
- Client Streaming RPC. Клиент формирует поток сообщений и отправляет на сервер. После обработки сообщений, сервер возращает лишь один ответ клиенту.
- Bidirectional streaming RPC. Обе стороны (клиент и сервер) отправляют друг другу потоки сообщений. Потоки независимы, потому клиент и сервер могут обрабатывать сообщения паралелльно (как захотят).
Конечно вполне возможно, что не все виды коммуникации будут использованы в конкретных сервисах. Но надо быть готовыми протестировать потоковую коммуникацию и возможные проблемы с ней.
Потоки и тестирование производительности
Из-за того, что потоки могут быть как на стороне клиента, так и на стороне сервера - усложняется не только функциональная часть тестирования.
Не все инструменты нагрузочного тестирования могут “из коробки” работать с потоками в gRPC. Например такие инструменты как k6.io или ghz работают только с единичными запросами и ответами в gRPC. Gatling и JMeter из коробки вообще не поддерживают gRPC - но хотя бы имеют плагины для такой функциональности.
#grpc #testing
АПИ тестирование и автоматизация уже давно не “магия”. Львиную долю АПИ, которое проходится тестировать составляет HTTP REST. Изредка “завозят” что-то посложнее - например веб сокеты.
Когда тестировщик проводит проверку АПИ, тесты сводятся к следующим шагам:
1. Отправь один запрос (GET, POST, PUT, DELETE, etc) на сервер
2. Получи один ответ от сервера (в разумное время)
3. Проверь содержание ответа
Как валидация будет происходить (cURL’ом, Postman’ом, кодом) - не так важно.
В случае с gRPC ситуация несколько усложняется:
- данные передаются в бинарном виде. Значит просто так в консоли браузера запросы не посмотришь. (Нужен прокси).
- передача данных между клиентом и сервером в виде унарных запросов (один запрос - один ответ) - это лишь один из возможных вариантов коммуникации
Методы коммуникации в gRPC, которых нет в HTTP REST:
- Server Streaming RPC. Клиент отправляет один запрос серверу, а в результате получает поток ответов. Клиент в этом случае сам решает, читать ли до конца потока или до наступления иного события (таймаута по времени или наличия специфического поля в ответе)
- Client Streaming RPC. Клиент формирует поток сообщений и отправляет на сервер. После обработки сообщений, сервер возращает лишь один ответ клиенту.
- Bidirectional streaming RPC. Обе стороны (клиент и сервер) отправляют друг другу потоки сообщений. Потоки независимы, потому клиент и сервер могут обрабатывать сообщения паралелльно (как захотят).
Конечно вполне возможно, что не все виды коммуникации будут использованы в конкретных сервисах. Но надо быть готовыми протестировать потоковую коммуникацию и возможные проблемы с ней.
Потоки и тестирование производительности
Из-за того, что потоки могут быть как на стороне клиента, так и на стороне сервера - усложняется не только функциональная часть тестирования.
Не все инструменты нагрузочного тестирования могут “из коробки” работать с потоками в gRPC. Например такие инструменты как k6.io или ghz работают только с единичными запросами и ответами в gRPC. Gatling и JMeter из коробки вообще не поддерживают gRPC - но хотя бы имеют плагины для такой функциональности.
gRPC
A high-performance, open source universal RPC framework
👍1
Что такое консенсус в распределенных системах?
#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.
Предположим, что есть два вида запросов: первый записывает данные в систему, а второй читает их.
Когда пользователь делает запрос, он не знает, на какой именно сервис попадет этот запрос. То же происходит и при чтении данных.
Вполне может случиться ситуация, когда пользователь U1 делает запрос на запись (set x = 10) на сервис S1, в это же время пользователь U2 делает запрос на запись (set x = 20) на сервис S3. Возникает вопрос - какое значение x получит пользователь U3 при отправке запроса на S4?
Протокол консенсуса - это алгоритм того, как узлы системы решат, какие данные являются правильными и сохранят эти данные на каждом из узлов. Как результат - запрос на чтение к любому узлу вернет верный ответ. В идеале, прийти к согласию узлы должны за конечное время.
#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.
Предположим, что есть два вида запросов: первый записывает данные в систему, а второй читает их.
Когда пользователь делает запрос, он не знает, на какой именно сервис попадет этот запрос. То же происходит и при чтении данных.
Вполне может случиться ситуация, когда пользователь U1 делает запрос на запись (set x = 10) на сервис S1, в это же время пользователь U2 делает запрос на запись (set x = 20) на сервис S3. Возникает вопрос - какое значение x получит пользователь U3 при отправке запроса на S4?
Протокол консенсуса - это алгоритм того, как узлы системы решат, какие данные являются правильными и сохранят эти данные на каждом из узлов. Как результат - запрос на чтение к любому узлу вернет верный ответ. В идеале, прийти к согласию узлы должны за конечное время.
Ошибка при работе с Shadow DOM в Chrome 96+ (Selenium 3 и 4)
Утром открыл юай тесты и оказалось, что все они начали падать по неведомой причине.
Ошибка вот такая:
“java.lang.ClassCastException: class com.google.common.collect.Maps$TransformedEntriesMap cannot be cast to
class org.openqa.selenium.WebElement (com.google.common.collect.Maps$TransformedEntriesMap and
org.openqa.selenium.WebElement are in unnamed module of loader 'app')“
Оказалось, что Chrome поменял механизм работы с shadow DOM элементами и так просто закастить их в WebElement нельзя.
Вот тут - Titus описал как это можно побороть. Как раз попробую сегодня.
Утром открыл юай тесты и оказалось, что все они начали падать по неведомой причине.
Ошибка вот такая:
“java.lang.ClassCastException: class com.google.common.collect.Maps$TransformedEntriesMap cannot be cast to
class org.openqa.selenium.WebElement (com.google.common.collect.Maps$TransformedEntriesMap and
org.openqa.selenium.WebElement are in unnamed module of loader 'app')“
Оказалось, что Chrome поменял механизм работы с shadow DOM элементами и так просто закастить их в WebElement нельзя.
Вот тут - Titus описал как это можно побороть. Как раз попробую сегодня.
Titus on Testing
Shadow DOM in Selenium
I’ve seen numerous bugs reported for how Chrome v96 has changed
the shadow root return values for Selenium. This is
a feature, not a bug! Here’s how to work with the shadow DOM in Selenium 3 and 4.
the shadow root return values for Selenium. This is
a feature, not a bug! Here’s how to work with the shadow DOM in Selenium 3 and 4.
Мой топ 5 ИТ книг в 2021
#books
Designing Data-Intensive Applications (M. Klepmann)
Монументальный труд по современным распределенным системам. Читается сложно (на русском даже сложнее чем на английском).
Прокачивает знания с теоретической и (немного) практической сторон. Хорошим подспорьем к книге будет бесплатный курс от автора на Youtube.
Книга будет очень полезна, если вы работаете над сложными распределенными системами. По тестированию тут не так много, но зато почти каждая концепция дается с позиции “как это может не работать и упасть”.
Блокчейн и децентрализованные системы (П. Кравченко, Б. Скрябин)
Книга имеет три части и была создана в первую очередь, как учебное пособие по блокчейну для университетов.
Самый главный плюс книги в том, что она не упрощает концепции - а объясняет их так, как они работают.
Просто must-have если вы стартуете в блокчейн проектах и хотите знать “как это работает изнутри”.
Внимание, тут есть немного математики.
Leading Quality (R. Cummings-John, O. Peer)
Очень небольшая, но крайне полезная книга о том, как “драйвить” качество в организациях. Вроде бы многое из сказанного и так знаешь - но мысли сформулированы лаконично и почти без воды.
Книга хорошо ставит “продуктовое” мышление.
После нее просто хочется идти и менять свой проект к лучшему).
И да, тут не будет кокретных инструментов, техник тест-дизайна и всего прочего. Это книга про общий подход и мышление.
How Technology Works (DK)
Энциклопедия о том, как работают технологии и устройства вокруг нас. Не только компьютеры и спутники, но бытовые приборы, сельскохозяйственная техника, медицинское оборудование.
Очень хотел бы, чтобы такая книга попалась мне в руки в школьные годы.
Информация балансирует на грани между “совсем просто” и “нужно знания физики и электроники, чтобы понять”.
А еще, книга здорово поможет объяснить детям как и почему работают устройства вокруг.
P.S. Если читать на английском языке - можно здорово обогатить свой словарный запас.
Functional Programming, Simplified (Alvin Alexander)
Отличная книга для тех, кто хочет "вьехать" в фунциональное программирование на Scala. Читается достаточно легко и что самое главное - автор строит сложные концепции на основе простых. Никаких функторов и хвостовой рекурсии на первой странице).
#books
Designing Data-Intensive Applications (M. Klepmann)
Монументальный труд по современным распределенным системам. Читается сложно (на русском даже сложнее чем на английском).
Прокачивает знания с теоретической и (немного) практической сторон. Хорошим подспорьем к книге будет бесплатный курс от автора на Youtube.
Книга будет очень полезна, если вы работаете над сложными распределенными системами. По тестированию тут не так много, но зато почти каждая концепция дается с позиции “как это может не работать и упасть”.
Блокчейн и децентрализованные системы (П. Кравченко, Б. Скрябин)
Книга имеет три части и была создана в первую очередь, как учебное пособие по блокчейну для университетов.
Самый главный плюс книги в том, что она не упрощает концепции - а объясняет их так, как они работают.
Просто must-have если вы стартуете в блокчейн проектах и хотите знать “как это работает изнутри”.
Внимание, тут есть немного математики.
Leading Quality (R. Cummings-John, O. Peer)
Очень небольшая, но крайне полезная книга о том, как “драйвить” качество в организациях. Вроде бы многое из сказанного и так знаешь - но мысли сформулированы лаконично и почти без воды.
Книга хорошо ставит “продуктовое” мышление.
После нее просто хочется идти и менять свой проект к лучшему).
И да, тут не будет кокретных инструментов, техник тест-дизайна и всего прочего. Это книга про общий подход и мышление.
How Technology Works (DK)
Энциклопедия о том, как работают технологии и устройства вокруг нас. Не только компьютеры и спутники, но бытовые приборы, сельскохозяйственная техника, медицинское оборудование.
Очень хотел бы, чтобы такая книга попалась мне в руки в школьные годы.
Информация балансирует на грани между “совсем просто” и “нужно знания физики и электроники, чтобы понять”.
А еще, книга здорово поможет объяснить детям как и почему работают устройства вокруг.
P.S. Если читать на английском языке - можно здорово обогатить свой словарный запас.
Functional Programming, Simplified (Alvin Alexander)
Отличная книга для тех, кто хочет "вьехать" в фунциональное программирование на Scala. Читается достаточно легко и что самое главное - автор строит сложные концепции на основе простых. Никаких функторов и хвостовой рекурсии на первой странице).