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

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

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

TLDR: забанили трёхлетний аккаунт с подпиской Pro, кибер‑доступом Daybreak Blue и вследствии: доступ ко всей накопленной информации в аккаунте — утерян.

Салют! Много‑много лет читаю Хабр, но сейчас специально зарегистрировался, чтобы рассказать маленькую историю, которая возможно поможет клиентам OpenAI избежать моей участи.

Приступим.

Жил да был аккаунт OpenAI с 2023 года. Сначала, он был бесплатный, совсем маленький. Потом подрос и пошёл в школу с ежемесячной оплатой в $20. К 2026 году аккаунт совсем возмужал и обросся подпиской Pro за $100 в месяц. Не тужил, от слова.

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

Одна точка в Gmail — и для сервиса перед вами уже другой пользователь. Мы наткнулись на это случайно, а потом решили проверить, насколько далеко можно зайти.

Привет, меня зовут Евгений Когтев, я руководитель направления разработки в команде дизайн-системы «LUNA» в Домклик. Расскажу про то, как у нас появилась идея упростить создание тестов с помощью Codegen: просто ходишь по сайту, как обычный пользователь, а в соседнем окне послушно рождается аккуратный, подсвеченный синтаксисом код. Никакой магии — сплошная инженерия, подумали мы.

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

В Allure Report такие уведомления были реализованы в версии 3.0 с помощью плагина для уведомлений в Slack. В этом руководстве я покажу, как настроить канал в Slack так, чтобы каждый запуск Allure Report отправлял туда сводку по результатам.

Собрал 6 сервисов с бесплатным или стартовым доступом к LLM API и проверил их. Какие модели реально работают, что дают после регистрации, сколько уходит баланса и какие лимиты встречаются — всё на реальных запросах.

Тестирование API часто сводится к одному: отправить запрос и убедиться, что сервер ответил 200. На собеседовании этого хватает на пару минут, а в проде именно здесь всплывает то, чего статус-код не ловит: чужой заказ в ответе, молчаливый 500 вместо ошибки валидации, товар, который не списался со склада.

Разберём 20 базовых проверок, которые отличают QA, тестирующего API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы — на одном сквозном сценарии, с примерами на curl и в Postman. Начинающий выстроит последовательность, опытный сверится и поймёт, куда расширять набор тестов.

Своих MCP‑серверов у нас два: один к Битрикс24, второй к нашей системе заявок Okdesk. К Copilot оба подключены штатным путём, по документации Microsoft. Я Александр Жогов, основатель ИТ‑компании «+Альянс».

Путь оказался короче, чем я ожидал. И упирается он в одну строку документации. Ту самую, которую я бы читал первой.

Обе страницы, на которые тут ссылаюсь, я открывал 4 сентября 2026 года. Версий у них нет, правки приезжают тихо. Перед своим подключением сходите по ссылкам сами: вдруг за прошедшее время формулировка уехала.

Breaking change в REST API часто обнаруживают слишком поздно — уже на интеграционном стенде. Разберём, какие риски можно поймать раньше, где помогают OpenAPI и consumer contracts и почему зелёные проверки ещё не гарантируют совместимость со старым клиентом.

Постмортем Electron-редактора меню: SceneTree, PDFKit и тесты, которые доказали не то

Я вернул «Объём» в поле, для которого он был задуман.

Текст наполз на цену.

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

Когда визуально все выглядело хорошо, пошла проверка деталей, на этапе которой результаты тестов разошлись с реальностью. Проверил руками и увидел, что объём лежит не там, где должен. Не в Position.volume, а внутри PriceNote. Четыре релиза. Четыре зелёных гейта. Четыре раза процесс сказал «всё правильно» тому, что правильным не было. После этого пришлось разбираться не только с багом, но и с контрактом, который его пропустил.

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

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

Тест зелёный, а фича сломана — потому что проверка смотрит на форму, а не на эффект: имя поля в файле есть, а в разметку оно не попало. Семь таких случаев из живого проекта на TypeScript и PostgreSQL: колесо мыши, которое убил мой собственный CSS-фикс и диагностика, проверившая defaultPrevented вместо прокрутки; подстрока, совпавшая с другой подстрокой; комментарий в SQL, прочитанный как код; метка источника, из-за которой отчёт показывал ноль и этот ноль читался как «людей нет». С кодом, разбором каждой ошибки и числами мутационного прогона на 13 400 мутантов.

Привет, меня зовут Артем Русов. Я автор курсов и образовательных материалов для тестировщиков. Сегодня первое сентября, и это удобный повод подвести итог одной работы.

С февраля я собираю курсы по тестированию, устроенные как игра: Древняя Греция для REST API, Древний Египет для GraphQL, город Цифроград для основ компьютерной грамотности. Сюжет, персонаж-проводник, задания в декорациях мира.

Задача была не в том, чтобы люди сидели в курсе дольше. Задача была сделать обучение доступнее и интереснее. И при этом не разориться, потому что курсы я продаю. Поэтому мерить пришлось всю воронку: сколько людей приходит, сколько покупает, сколько доходит до конца, что они потом ставят и сколько возвращают денег.

Ответ получился неудобным для заголовка. Геймификация улучшила почти всё, кроме одной метрики.

Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.

Впервые ежедневный анализ открываемых и закрываемых вакансий в более чем 2000 IT-компаний показал тренд роста вакансий, где требуется тестирование AI-приложений.

У нас семь публикаций в день на четыре площадки, и все они идут через один общий Chrome с живыми сессиями.

В моей игре доменный слой не знает, что существует Three.js. И Rapier. И DOM.

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

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

В двухнедельном спринте регрессия часто превращается в лотерею: фичи доделывают до последнего дня, полный прогон не помещается в окно, а красному CI уже никто не верит. В итоге команда выпускается, ориентируясь на ощущение, а не на понятную картину рисков.

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.

Как перейти от разовых ИИ-запросов к многоразовым Agentic AI рабочим процессам в QA. Я собрал несколько практических примеров, паттернов и предостережений, которые помогут инженерам по тестированию осуществить этот переход постепенно

Всем привет! Сегодня хочу рассказать об особенностях автоматического тестирования крупного проекта на Django, в котором тесты написаны в разных стилях и есть много пересечений моделей данных. Поговорим о том, как привести всё к единому знаменателю без риска получить непредсказуемое поведение тестов. Также разберём конфигурацию pytest, параметры его запуска, работу с фабриками моделей и стили тестирования в двух парадигмах (Django и чистый pytest).