Всем привет! Добро пожаловать на мой Телеграм канал. Меня зовут Александр. Здесь я планирую делиться интересными ресурсами на темы тестирования, автоматизации и инжиниринга сложных распределенных систем.
#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. Читается достаточно легко и что самое главное - автор строит сложные концепции на основе простых. Никаких функторов и хвостовой рекурсии на первой странице).
Ось тут Курсера на місяц коштує всього 1 доллар. (Тільки сьогодні 29.11.21)
Coursera
Coursera Plus | Unlimited Access to 7,000+ Online Courses
Invest in your professional goals with Coursera Plus. ...
Что нужно знать, чтобы тестировать блокчейн?
#distributedsystems #blockchain
В широком смысле блокчейн - это цепочка блоков, содержащих информацию, построенная по определенному принципу (с применением криптографических хешей).
В смысле криптовалют - это распределенная база данных неизменяемых транзакций на основе блокчейна, в которой записи распространяются между узлами сети согласно протоколу консенсуса.
Что же нужно знать и понимать, чтобы тестировать блокчейн (базово)?
1. Хеширование
2. Немного криптографии (ассиметричной)
3. Протоколы консенсуса и их виды
4. Распределенные системы и способы коммуникации между узлами в сети
5. Модели транзакции: UTxO (Bitcoin) или account-based (Ethereum)
6. Из чего состоят транзакции и как хранятся (привет Merkle деревья :) )
7. Типы блокчейнов (Mainnet vs Testnet, открытые и закрытые)
8. Виды кошельков и принципы их работы
9. Смарт-контракты (зачем они нужны)
В случае, если вы используете смарт-контракты:
10. Языки программирования смарт-контрактов - Solidity, Plutus (если вам нужно будет это тестировать)
11. Инструменты локального развертывания тестовых блокчейнов
12. Инструменты тестирования смарт контрактов
13. Уязвимости и проблемы блокчейнов в целом и смарт-контрактов в частности
#distributedsystems #blockchain
В широком смысле блокчейн - это цепочка блоков, содержащих информацию, построенная по определенному принципу (с применением криптографических хешей).
В смысле криптовалют - это распределенная база данных неизменяемых транзакций на основе блокчейна, в которой записи распространяются между узлами сети согласно протоколу консенсуса.
Что же нужно знать и понимать, чтобы тестировать блокчейн (базово)?
1. Хеширование
2. Немного криптографии (ассиметричной)
3. Протоколы консенсуса и их виды
4. Распределенные системы и способы коммуникации между узлами в сети
5. Модели транзакции: UTxO (Bitcoin) или account-based (Ethereum)
6. Из чего состоят транзакции и как хранятся (привет Merkle деревья :) )
7. Типы блокчейнов (Mainnet vs Testnet, открытые и закрытые)
8. Виды кошельков и принципы их работы
9. Смарт-контракты (зачем они нужны)
В случае, если вы используете смарт-контракты:
10. Языки программирования смарт-контрактов - Solidity, Plutus (если вам нужно будет это тестировать)
11. Инструменты локального развертывания тестовых блокчейнов
12. Инструменты тестирования смарт контрактов
13. Уязвимости и проблемы блокчейнов в целом и смарт-контрактов в частности
Telegram
Test Engineering Notes
Что такое консенсус в распределенных системах?
#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.
Предположим, что есть два…
#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.
Предположим, что есть два…
Структурные свойства протоколов консенсуса (в блокчейне)
#blockchain
В своей научной работе авторы выделяют такие структурные свойства протоколов консенсуса:
1. Тип узла в системе
2. Тип структуры - то, как узлы структурированы в системе
3. Механизм работы консенсуса
По типам структуры различают блокчейн системы с одной или несколькими группами (committees), принимающими решения.
В системах с одной группой принимающей решения вход в группу может быть как открытым для всех, так и закрытым. По конфигурации группа может быть статически зафиксированной или динамической (например меняться со временем).
В блокчейнах, где блоки могут создавать несколько независимых групп узлов важную роль играет топология организации групп. Они могут быть как равноправными, так и часть иерархии (с разными полномочиями).
Механизм работы консенсуса может основываться на принципе лотереи (может быть как полностью случайной так и вероятностной), голосования или также на возрасте коина, которым располагает пользователь.
#blockchain
В своей научной работе авторы выделяют такие структурные свойства протоколов консенсуса:
1. Тип узла в системе
2. Тип структуры - то, как узлы структурированы в системе
3. Механизм работы консенсуса
По типам структуры различают блокчейн системы с одной или несколькими группами (committees), принимающими решения.
В системах с одной группой принимающей решения вход в группу может быть как открытым для всех, так и закрытым. По конфигурации группа может быть статически зафиксированной или динамической (например меняться со временем).
В блокчейнах, где блоки могут создавать несколько независимых групп узлов важную роль играет топология организации групп. Они могут быть как равноправными, так и часть иерархии (с разными полномочиями).
Механизм работы консенсуса может основываться на принципе лотереи (может быть как полностью случайной так и вероятностной), голосования или также на возрасте коина, которым располагает пользователь.
Свойства безопасности и производительности протоколов консенсуса в блокчейне
#blockchain
Продолжаем разбираться как еще авторы научной работы сравнивают протоколы консенсуса.
На какие свойства безопасности консенсуса обращают внимание?
- authentication (аутентифицирован ли узел, принимающий участие в протоколе консенсуса)
- non-repudation (есть возможность у узла отрицать факт отправления транзакции)
- censorship resistance (стойкий ли протокол к цензуре)
- attack vectors (может ли протокол противостоять различным векторам атак - denial of service, sybil attack, nothing at stake и другие)
Что касается производительности, то выделяются такие свойства:
- fault-tolerance (какое максимально количество вышедших из строя узлов может выдержать протокол)
- throughput (количество транзакций в секунду)
- scalability (способность сохранять производительность при условии роста числа узлов)
- latency (finality) (время от момента, когда транзакция предложеня к включению в блок до момента достижения консенсуса по ней во всей сети)
- energy consumption (сколько энергии тратится системой для достижения консенсуса)
#blockchain
Продолжаем разбираться как еще авторы научной работы сравнивают протоколы консенсуса.
На какие свойства безопасности консенсуса обращают внимание?
- authentication (аутентифицирован ли узел, принимающий участие в протоколе консенсуса)
- non-repudation (есть возможность у узла отрицать факт отправления транзакции)
- censorship resistance (стойкий ли протокол к цензуре)
- attack vectors (может ли протокол противостоять различным векторам атак - denial of service, sybil attack, nothing at stake и другие)
Что касается производительности, то выделяются такие свойства:
- fault-tolerance (какое максимально количество вышедших из строя узлов может выдержать протокол)
- throughput (количество транзакций в секунду)
- scalability (способность сохранять производительность при условии роста числа узлов)
- latency (finality) (время от момента, когда транзакция предложеня к включению в блок до момента достижения консенсуса по ней во всей сети)
- energy consumption (сколько энергии тратится системой для достижения консенсуса)
Проблемы найма на "горячем" ИТ рынке (с точки зрения инженера)
#interview
Так как сегодня пятница - то и тема будет полегче и по холиварнее.
В Линкедине и разных телеграм чатах часто встречаю мнение о том, что сейчас ну просто очень сложно нанять толкового инженера.
"Ищем много месяцев и нет результатов", "Приходят люди без скиллов и просят много денег", "Куда катится ИТ рынок?", "Кандидаты не отвечают на письма", "Никто не хочет идти к нам работать".
За 10 лет в украинском ИТ я был как на стороне интервьюера, так и на стороне кандидата. Все пункты ниже основываются только лишь на моем опыте. Ваш опыт может быть совершенно другим.
Какие же главные блокеры в найме я вижу:
1. Предлагаемая Вами вилка зарплаты не соответствует рынку. Компании и бюджеты разные, рынок тоже может быть крайне разгорет. Но в любом случае, нужно или поднимать вилку до рыночной (и нанимать меньше людей) или завлекать кандидатов "плюшками", которых нет в других компаниях. И я не имею тут в виду красивый офис с печеньками :). В зависимости от кандидата это могут быть: личные проекты в рабочее время, оупен-сорс разработка, дополнительные дни отпуска, гибкий ремоут график.
2. Вы (или Ваш заказчик) хотите найти единорога на 100% соответствующего описаниям вакансии. Очень часто при составлении описания вакансии, заказчик хочет включить сразу все инструменты и процессы, которые есть или даже будут (может быть) в будущем в компании. В результате, процесс поиска кандидата превращается в "поиск Святого Грааля", который работал со свсеми технологиями и фреймворками ровно указанное количество лет.
3. Ваш процесс собеседования кардинально отличается от работы. Я видел много примеров, когда кандидата гоняли по жестким алгоритмам и прочему Computer Science - а в результате приходилось потом просто тестировать руками. Не вижу мануальном тестировании ничего плохого (сам занимаюсь), но плохо когда кроме мануального тестирования нет возможности улучшать процессы или инструменты и применять инженерные навыки. Синьйоры и выше не будут 100% времени проходить регрешн. Для этого есть крауд-тестирование.
Тут же стоит и "больная мозоль" - тестовое задание. О нем я поговорю как-нибудь в следующий раз.
4. У Вашей компании отсутствует или слабо развит технический бренд. Очень много компаний "забивает" на технический бренд - а зря. Именно бренд может помочь Вам найти крутого специалиста не имея зарплатного бюджета выше рынка. Задайте себе вопрос - как Вы можете заинтересовать кандидата, кроме ЗП?. Я вижу такие варианты:
1. В компании работают топовые специалисты и очень интересно поработать с ними (и поучиться их уникальному опыту)
2. Компания делает продукт, который помогает обществу или просто находится "на острие технологий".
3. В компании очень много open-source инструментов, которые можно развивать в рабочее время.
4. У компании полезный технический (не маркетинг!) блог или ютуб канал с кучей полезных ресурсов, которые помогают комьюнити.
Я видел много примеров, когда технический бренд привлекает действительно много кандидатов. И много крутых специалистов. Конечно это не означает, что все кандидаты будут подходящими. Но по крайней мере время на начальный поиск людей может сократиться. Дальше уже дело за интервью.
В заключение скажу, что вижу много примеров, когда люди закрывают позиции довольно быстро. Значит - не все еще потеряно на нашем текущем "горячем" ИТ рынке.
Удачи в поисках скилловых кандидатов!
#interview
Так как сегодня пятница - то и тема будет полегче и по холиварнее.
В Линкедине и разных телеграм чатах часто встречаю мнение о том, что сейчас ну просто очень сложно нанять толкового инженера.
"Ищем много месяцев и нет результатов", "Приходят люди без скиллов и просят много денег", "Куда катится ИТ рынок?", "Кандидаты не отвечают на письма", "Никто не хочет идти к нам работать".
За 10 лет в украинском ИТ я был как на стороне интервьюера, так и на стороне кандидата. Все пункты ниже основываются только лишь на моем опыте. Ваш опыт может быть совершенно другим.
Какие же главные блокеры в найме я вижу:
1. Предлагаемая Вами вилка зарплаты не соответствует рынку. Компании и бюджеты разные, рынок тоже может быть крайне разгорет. Но в любом случае, нужно или поднимать вилку до рыночной (и нанимать меньше людей) или завлекать кандидатов "плюшками", которых нет в других компаниях. И я не имею тут в виду красивый офис с печеньками :). В зависимости от кандидата это могут быть: личные проекты в рабочее время, оупен-сорс разработка, дополнительные дни отпуска, гибкий ремоут график.
2. Вы (или Ваш заказчик) хотите найти единорога на 100% соответствующего описаниям вакансии. Очень часто при составлении описания вакансии, заказчик хочет включить сразу все инструменты и процессы, которые есть или даже будут (может быть) в будущем в компании. В результате, процесс поиска кандидата превращается в "поиск Святого Грааля", который работал со свсеми технологиями и фреймворками ровно указанное количество лет.
3. Ваш процесс собеседования кардинально отличается от работы. Я видел много примеров, когда кандидата гоняли по жестким алгоритмам и прочему Computer Science - а в результате приходилось потом просто тестировать руками. Не вижу мануальном тестировании ничего плохого (сам занимаюсь), но плохо когда кроме мануального тестирования нет возможности улучшать процессы или инструменты и применять инженерные навыки. Синьйоры и выше не будут 100% времени проходить регрешн. Для этого есть крауд-тестирование.
Тут же стоит и "больная мозоль" - тестовое задание. О нем я поговорю как-нибудь в следующий раз.
4. У Вашей компании отсутствует или слабо развит технический бренд. Очень много компаний "забивает" на технический бренд - а зря. Именно бренд может помочь Вам найти крутого специалиста не имея зарплатного бюджета выше рынка. Задайте себе вопрос - как Вы можете заинтересовать кандидата, кроме ЗП?. Я вижу такие варианты:
1. В компании работают топовые специалисты и очень интересно поработать с ними (и поучиться их уникальному опыту)
2. Компания делает продукт, который помогает обществу или просто находится "на острие технологий".
3. В компании очень много open-source инструментов, которые можно развивать в рабочее время.
4. У компании полезный технический (не маркетинг!) блог или ютуб канал с кучей полезных ресурсов, которые помогают комьюнити.
Я видел много примеров, когда технический бренд привлекает действительно много кандидатов. И много крутых специалистов. Конечно это не означает, что все кандидаты будут подходящими. Но по крайней мере время на начальный поиск людей может сократиться. Дальше уже дело за интервью.
В заключение скажу, что вижу много примеров, когда люди закрывают позиции довольно быстро. Значит - не все еще потеряно на нашем текущем "горячем" ИТ рынке.
Удачи в поисках скилловых кандидатов!