Тестирование веб-сервисов *

За каждым безупречным цифровым опытом стоит высокопроизводительный API. Независимо от того, работает ли ваш API для обработки потока покупок, медицинского дашборда или стриминговой платформы, проблемы с производительностью на уровне API могут повлиять на всю вашу систему — негативно влияя на скорость, надежность и доверие пользователей.

В этом руководстве мы рассмотрим типы тестирования производительности API, ключевые проблемы и решения, а также расскажем, как на основе метрик производительности принимать осмысленные решения.

Обычно специалисты, особенно начинающие, смотрят только в код. Но настраивая процессы автоматизированного тестирования, стоит отрываться от кода и внимательнее смотреть на процессы — именно тут кроется плодородная почва для оптимизации.

В двух частях этой статьи расскажем о вариантах оптимизации тестирования, которые можно применить как внутри тестов, так и, условно, снаружи, т. е. в обертках и прочих внешних инструментах. Сегодня поговорим о «внешних» инструментах.

Текст подготовлен по материалам выступления приглашенного спикера внутри компании.

Разбираемся, как организовать нагрузочное тестирование на Python с Locust — с сидинговыми сценариями, кастомными API-клиентами на HTTPX, конфигурацией через Pydantic и автоматическим запуском в GitHub Actions. Всё — на практике, с архитектурой, фреймворком и публикацией отчётов в GitHub Pages.

Поиск работы в IT — настоящий «чёрный ящик». Мы рассылаем резюме, проходим созвоны, получаем странные вопросы и туманные отказы. Что на самом деле происходит в голове у рекрутера? Почему один и тот же ответ где-то вызывает восторг, а где-то — вежливое «мы вам перезвоним»?

Чтобы пролить свет на этот процесс, мы разобрали более 10 часов записей живых, нефильтрованных эфиров с QA-практиками. В роли наших проводников выступят:

Lead QA Ада Ширченко (7+ лет в QA), Senior QA Юлия Самусева (8+ лет в QA) и Middle+ QA Евгений Гусинец (3+ лет в QA)

Это были не лекции, а честные диалоги, где начинающие тестировщики задавали самые наболевшие вопросы. Мы скрупулезно проанализировали эти разговоры и упаковали их в серию статей. Представляем наш «Сезон 1» — полный путь джуна от первого резюме до заветного оффера.

Мы не нашли свежего исследования про QA и решили: нужно делать своё. Так появилось наше первое большое огромное исследование про QA в России.

 Что внутри?

— Как работают в QA: какие процессы, инструменты и подходы используют.

— Зачем тестировщики работают: мотивация, удовлетворённость сферой и зарплатой.

— Будущее QA: как инженеры видят развитие профессии и какую роль в этом сыграет AI.  

Приправили статистику комментариями ребят из сообщества. 

Под катом собрали несколько важных инсайтов. С полной версией исследования можно ознакомиться по ссылке: https://qa-survey-2025.2gis.ru

В предыдущих статьях я приводила примеры применения техники тест‑дизайна «таблица решений» для тестирования фронтовых фич и алгоритмов. В этой статье я хочу привести пример, как применять таблицу решений для тестирования скриптов.

Такое представление тестов экономит время на расписывание большого количества тест‑кейсов, придает проверкам наглядность и облегчает их поддержку и расширение в будущем.

Приветствую читателей моей статьи!

В тестировании я уже 8 лет. Начала тогда, когда это еще не было мейнстримом :-)

Однако, сегодня эта профессия стала очень популярной и, по слухам, новичкам практически невозможно начать карьеру в этом поприще. Многие ребята сталкиваются с проблемой «донести» свое резюме до компании и попасть на собеседование. Поэтому я решилась на эксперимент и опубликовала резюме новичка без опыта работы на hh.ru, чтобы посмотреть – получится ли получить обратную связь.

Итак, входные данные.

Я взяла реальную историю и описала свои знания и навыки 15 летней давности т.е. на момент выпуска из колледжа.

Привет, Хабр! Чтобы не вводить никого в заблуждение, кратко перескажу, о чём пойдёт речь. Если тема будет вам близка или вы сталкивались с подобным, буду рад узнать ваше мнение и послушать советы.

Краткий пересказ:

Как я/мы в компании создаём процесс тестирования практически с нуля. Какие шаги предпринимались и как вообще получается в современном мире существовать без тестирования.

Вводные данные:

Я — QA, который работает в средней по размерам IT-фирме, которая, в свою очередь, является «дочкой» довольно крупной промышленной компании и обеспечивает поддержку и разработку внутренних систем. Когда я только пришёл, помимо меня был только один тестировщик на ~15 разработчиков. Ни о каком адекватном процессе тестирования речи и не шло.

Работа осуществляется в рамках спринтов по две недели. Задачи, выполненные разработчиками, проверяются во время ревью более крутыми разработчиками, затем мерджатся и раскатываются на тестовый стенд, где уже их проверяет аналитик на соответствие требованиям.

В целом, кажется, ничего плохого нет — две линии проверки. Вот только количество багов явно было больше запланированного, а это, в свою очередь, вызывает ночной кошмар любого менеджера: сдвиг сроков.

Было принято решение взять нескольких тестировщиков, да не просто каких-то, а с навыками автоматизации, чтоб оно всё там как-то само.

Так я, собственно, и попал в команду — молодой и неопытный. На самом деле, не настолько всё было плохо: разработчики работали по TDD, так что unit-тестов хватало, и пайплайны отрабатывали автоматически. Да, не было тестирования как процесса, но ведь давным-давно, в далёкой-далёкой галактике, именно так и начиналось программирование.

Всего за пару недель мы создали инструмент, который превращает трудоёмкий процесс создания проверок в автоматизированный сценарий. Теперь, чтобы запустить тесты, мы делаем всего несколько кликов.

Тест-документация рождается в 5 раз быстрее, а свободное время инженеры используют для исследовательских тестирований, погружения в продукт и проработки нефункциональных требований. И всё это вместо монотонного создания проверок по требованиям.

Пользователи GitHub часто используют принудительные пуши (git push --force), чтобы переписать историю коммитов — например, когда случайно закоммитили секреты и хотят удалить их из репозитория. 

На первый взгляд кажется, что коммит исчез, но на самом деле GitHub его не стирает. «Удаленный» коммит остается доступен по хэшу — пусть и без прямых ссылок. GitHub продолжает хранить такие коммиты вечно.

В статье покажу, как вычислял такие коммиты с помощью GitHub Archive и вытаскивал из них секреты, за которые мне выплатили $25 000 по багбаунти. А еще поделюсь open-source инструментом, который позволит вам самостоятельно искать подобные утечки.

Признаемся честно: слово «тестирование» вызывает у многих разработчиков примерно такую же радость, как поход к стоматологу. Большинство морщится и думает: «Опять эти тесты... Лучше бы новую фичу запилил!» И я вас прекрасно понимаю — сам когда-то был в лагере скептиков.

Но после нескольких лет руководства командой фронтенда, десятков ночных дебагов и сотен часов, потраченных на поиск неуловимых багов, я пришёл к неожиданному выводу: качественные юнит-тесты — это не якорь, замедляющий разработку, а реактивный двигатель, ускоряющий её.

В этой статье я расскажу, почему наша команда делает ставку именно на юнит-тесты, и как они могут превратить вашу разработку из хаотичного забега с препятствиями в уверенный марафон с чёткими ориентирами.

При работе со сквозным тестированием (E2E, end-to-end) в Playwright критическое значение имеет поддержание упорядоченной и масштабируемой тестовой базы. Хорошо организованная структура не только улучшает поддерживаемость, но и облегчает адаптацию новых коллег. В этой статье мы рассмотрим, как организовать тесты в Playwright наилучшим образом, начиная со структуры папок и заканчивая использованием хуков, аннотаций и тегов.

Как понять, что API отработало корректно? Как убедиться, что в ответе пришли нужные данные? И как использовать эти данные в следующих шагах, выстраивая сложные тестовые цепочки?

Именно здесь на сцену выходят post-response скрипты. Это код, который выполняется после получения ответа от сервера. Его основная задача – анализ, валидация и обработка полученных данных. Эти скрипты – ваши глаза и уши в мире API-тестирования, позволяющие автоматически проверять всё: от статус-кода до мельчайших деталей в теле JSON.

В этой статье мы рассмотрим 10 самых полезных post-response скриптов, которые превратят ручную проверку ответов в быстрый и надежный автоматизированный процесс. Давайте завершим наш путь к эффективному тестированию API!

Привет! Меня зовут Кристина, я тестировщик в ППК «Роскадастр» и ревьюер курса «Инженер по тестированию» в Яндекс Практикуме. В этой статье я расскажу, как правильно оформлять задачи в Jira — так, чтобы тестировщик сразу понял, что от него требуется, и выполнил работу без лишних уточнений и задержек.

Статья Галины Шайдуровой

Психология тестировщика: почему критическое мышление – это суперсила

Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.

Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъяренных пользователей.

Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберем, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход, и как нестандартное мышление спасает проекты (и иногда ночной сон).

На работе (вне собственных пет-проектов) тестировщик никогда не существует в вакууме - он решает некоторые задачи бизнеса, а значит все решения должны приниматься с оглядкой на финансовую целесообразность. Иногда это противоречит внутреннему перфекционизму. Сегодня расскажу о некоторых неочевидных принципах автоматизированного тестирования, которые сводятся к тому, что иногда необходимо искать компромисс, а не следовать за тем самым перфекционизмом. 

Что, если бы тесты могли писаться сами, просто используя ваше приложение как реальный пользователь?

В этой статье мы рассмотрим, как Playwright MCP (Model Context Protocol) в режиме агента может автономно исследовать приложение, обнаруживать ключевые функции и генерировать исполнимые тесты — без необходимости в ручном скриптинге.

Мы разберём процесс генерации и запуска теста для приложения Movies, не обойдя без внимания то, как MCP выявляет крайние случаи, строит покрытие и даже находит баги, которые вы могли пропустить.

Последнее время почти любой мой диалог с русскоязычными и англоязычными инженерами по тестированию выглядит так:

— Вижу у вас в профиле тестирование AI-приложений. 
— Я: Да.
— Имеется в виду использование AI-тулов для тестирования?
— Я: Нет, это разные вещи.

Сейчас в разработке буквально каждый квартал происходят какие-то изменения, связанные с AI. Поэтому сложно отличить хайп от того, что компании уже фактически используют в проде. Мне удалось поучаствовать в тестировании AI-приложений на нескольких международных проектах и понять, что действительно уже обрело жизнь.

Эта небольшая заметка позволит сориентироваться в том, что есть интересного в тестировании классических приложений при помощи AI, тестировании AI-приложений и какие есть уровни погружения во все это.

В статье хочу поделиться кейсом, с которым столкнулся на одном из проектов. И расскажу о своем варианте его решения.

Стояла задача автоматизации регресса для сервиса миграции из системы Jira во внутреннюю систему «Яга».

Всем привет! Сегодня хочу рассказать, как можно протестировать Личный кабинет банка с помощью Postman, на примере простого Веб-приложения. Будет проверено: создание пользователя, авторизация, отображение продуктов клиента в Личном кабинете, подача заявки на потребительский кредит и отображение результатов ее рассмотрения в ЛК. Приступим

Было разработано небольшое Веб-приложение на Node.js. После запуска приложения и открытия его на локальной машине по адресу - http://localhost:5000/, на странице отображается форма входа в Личный кабинет.