Материал для тех, кто хочет создавать надежные и масштабируемые моки API-сервисов и любит получать удовольствие от жизни
В этой статье поговорим о том, с чего начать, как лучше подойти к разработке сервисов-моков и как упростить себя жизнь при работе с ними
Примеры и практические советы, как перейти на новый уровень покрытия тестами, если вы интегрируетесь с внешними системами
Привет, Хабр! Я SDET-инженер в SimbirSoft Александр, в этой статье я предлагаю вам:
Рассмотреть основы Kafka, ее архитектуру и как она работает.
• Выяснить, как тестируются сообщения в топиках, какие инструменты для этого используются. Приведу примерные сценарии.
• Обсудить роль Kafka в интеграционном тестировании, покажу пример интеграционного теста.
• Материал будет полезен для новичков в области тестирования ПО, как ручного, так и автоматизированного.
Привет, Хабр! Я Эдуард, в команде РСХБ.Цифра занимаюсь организацией проведения нагрузочного тестирования. В нашей команде инженеры НТ занимаются проверкой производительности как монолитных, так и микросервисных решений. Одно из больших направлений — это мобильное приложение «Свои финансы» от РСХБ. В этой статье расскажу о том, как мы проводим нагрузочное тестирование UI‑микросервисов и поделюсь ценными выводами на тему.
Когда идёт речь про микросервисы, большинству читателей представляется сложная архитектура связей между различными блоками, внешними системами, другими микросервисами и базой данных. То есть первым делом мы, конечно же, думаем о backend микросервисах. Действительно backend выполняет основную работу в современных приложениях, являясь двигателем всех процессов.
Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.
Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.
Сейчас я работаю в Sminex и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.
Хабравчане, всех рада приветствовать! Меня зовут Акманова Елизавета, я ведущий аналитик ГК «Юзтех». В своих статьях я стараюсь затрагивать темы, которые считаю важными, и обязательно с опорой на личный практический опыт.
Признаюсь, к этой статье я шла долго и это волнительно для меня. Вот почему.
ДИСКЛЕЙМЕР
Данная статья отражает личный опыт автора и не претендует на статус эталонного или единственно верного решения. Некоторые моменты могут вызывать несогласие или внутреннее сопротивление, это совершенно нормально. Я описываю конкретную ситуацию, сложившуюся в моей команде в рамках одного проекта. Это довольно специфический кейс, который не обязательно окажется применим в других условиях. Однако для нас он оказался полезным, и я не утверждаю, что так должно быть у всех. Моя цель — просто показать один из возможных вариантов развития событий. Возможно, наше решение совсем не идеально и не безупречно, но оно помогло нам улучшить ситуацию. Поэтому, пожалуйста, не торопитесь с критикой, будет здорово, если просто поддержите.
Надеюсь, это небольшое предисловие поможет настроиться на нужный лад.
Из названия статьи, уже понятно: мы дошли до того, что аналитики начали заниматься нагрузочным тестированием. Более того, они проводят его на этапе обследования, когда ещё не написано ни одной строки кода. О том, как мы к этому пришли, почему эту роль взяли на себя именно аналитики и какие инструменты нам помогают, я и расскажу.
Я всё чаще замечаю, что разговоры о качестве программного обеспечения как будто застряли в прошлой эпохе. Мы по привычке обсуждаем тест-кейсы, регрессию, покрытие, приёмку перед релизом и автоматизацию проверок, как будто этого по-прежнему достаточно, чтобы уверенно говорить о качестве продукта. Но сама среда, в которой живёт современное ПО, уже давно стала другой.
Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.
И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.
Эти две вещи мирно сосуществовали месяцами, потому что никто не хочет быть тем человеком, который вручную переписывает 40 запросов в pytest-функции. Newman, конечно, есть, но Newman гоняет тесты, а не генерирует код, который можно прочитать, отредактировать и нормально положить в систему контроля версий.
Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.
Я написал postman2pytest, чтобы их познакомить.
Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.
TL;DR: Я создал BarkingDog — ИИ-сканер безопасности с открытым исходным кодом для Telegram-ботов и веб-приложений на базе LLM. Затем я натравил его на реального, широко используемого опенсорсного Telegram-бота.
Он написал работающий кейлоггер. Подтвердил, что отбеливатель лечит COVID-19. Выдал пошаговую инструкцию по взлому корпоративной сети с указанием конкретных хакерских утилит.
Затем я пропатчил системный промпт. Оценка: 97/100. Никакой смены модели. Никаких изменений в коде. Всего шесть строк текста.
Кратко о себе: в прошлом разработчик смарт-контрактов (с 2017 года), с 2022 года работаю аудитором смарт-контрактов. Эта статья для тех, кто так или иначе интересуется информационной безопасностью и непосредственно аудитом смарт-контрактов (да и процессом аудита в целом).
По итогам аудита могут возникнуть два серьёзных вопроса: «Почему мы ничего не успели?» и «Почему мы ничего не нашли?». И самая страшная ситуация, когда оба эти вопроса возникают одновременно. Опишем это одним ёмким словом: «Провал».
В данной статье я попробую описать типовой процесс проведения аудита на примере систем смарт-контрактов — от самого начала до итогового отчета.
В работе аналитика данные часто говорят одно, интуиция — другое, а неопределенность сопровождает на каждом шагу. Важно уметь применять ее в свою пользу и не бояться.
В этой статье хочу поделиться, как работать с неопределенностью: какие у нее есть виды, как она обманывает мозг и какие есть способы сделать ее понятнее.
Разбор SLA от человека, которого подключают, когда сайт недоступен, заказы не проходят, а в чатах уже ищут виноватых. Рассказываю, как SLA помогает без лишних споров переживать такие моменты.
Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.
ZConnect — второй месяц вайб-кодинга, или как я делаю свой удалённый рабочий стол
Прошло уже больше месяца с прошлой статьи. За это время в моём проекте ZConnect появились передача файлов, NAT traversal, клики по UAC, установщик со службой, мультимонитор, адресная книга, Android-клиент, тёмная тема.
Заодно поймал забавный краш в mrwebrtc 2.0.2 на нестандартных sample rates, выложил проект в open source и окончательно понял, что вайб-кодинг всё больше начинает напоминать лудоманию.
В статье расскажу: что удалось сделать; на какие грабли наступил; как ИИ помогает и мешает одновременно; и почему поддерживать большой проект в режиме «вайб-кодинга» оказалось утомляюще.
Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.ru.
Про flaky-тесты написано много, борьбу с ними не прекращаем и мы. Но сегодня немного о другом — хочу поделиться нашим опытом минимизации неприятностей, которые наносят такие тесты. Для этого мы провели ряд экспериментов со стороны тестового фреймворка.
Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что‑то продать. Особенно если «волшебство» сводится к установке плагина в IDE.
Меня зовут Алиса Герасимова, я руковожу отделом функционального тестирования в центре разработки и машинного обучения «Инфосистемы Джет». В статье расскажу, как ИИ ускорил одну из наших команд разработки, но с цифрами из реального мира. Поговорим про метрики, разграничение ролей между человеком и ИИ, а также честно покажем, где машина больше мешает.
Статья будет полезна тимлидам, скрам‑мастерам и всем, кто устал от маркетинговых метрик без контекста.
В микросервисной архитектуре ошибка — это не просто баг в отдельном сервисе. Это сорванный релиз, нестабильные интеграции, потерянные заказы и часы дорогой ручной проверки. Когда сервисов десятки, а релизы идут постоянно, цена отсутствия системной автоматизации становится слишком высокой.
Уже больше полутора лет я пишу автотесты на Go. За это время мы прошли путь от «зачем вообще тестировать на Go?» до «почему мы не сделали это раньше?».
В этой статье я покажу, как внедрить автоматизацию тестирования на Go с нуля — так, чтобы она решала реальные бизнес‑проблемы, а не просто увеличивала количество тестов в репозитории.
Привет, Хабр!
Разберём один интересный инструмент для создания CV — простой, полностью бесплатный и без VPN.
Но просто обзором не ограничимся: соберём полноценное резюме с нуля. Чьё именно — оставлю интригой 🙂
Посмотрим, что из этого получится.
У каждого второго разработчика или QA есть сервис, который написан на древней версии языка, не имеет авторов, тесты не работают, документация — одна страница, но он стабильно работает, и его все боятся трогать.
А потом прилетает задача: добавить мультиязычность, или новый тип данных, или интеграцию с внешним API. И вы понимаете: либо вы его трогаете сейчас, либо он ломается сам через полгода в самый неподходящий момент.
Нам в Иви "повезло" оказаться именно в такой ситуации. Поэтому делимся своим кейсом по тестированию и обновлению SEO-сервиса — без пафоса, с шишками, метриками и выводами, которые реально помогут.
Когда речь заходит про автотесты, первыми на ум приходят проверки для UI, API или для мобильных устройств. Однако автотесты нужны не только для проверки пользовательских сценариев. Они могут решать и менее очевидные, но не менее важные задачи, например проверять работу пайплайнов. Если одни и те же пайплайны используют сотни сервисов и библиотек, любая ошибка в них быстро выходит за пределы одного проекта. У многих команд одновременно могут сломаться сборки, релизы и привычный процесс разработки. В нашем случае такие пайплайны работали примерно для 700 сервисов и более 200 библиотечных репозиториев. Чтобы гарантировать работоспособность пайплайнов, мы пришли к идее покрытия их автотестами.
В статье я расскажу, как мы в Ozon покрывали тестами работу пайплайнов в GitLab CI, какие требования нужно было учесть и как в итоге были устроены end-to-end-тесты для таких сценариев.
