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

Привет, заводчане! В этой статье вы найдете реальные технические советы по особенностям общения с бездушными ИИ моделями, в частности я расскажу про GPT 4o и свежую 5, но эти советы также применимы и к другим AI.

‼️Сразу внесу ясность: рекомендации предназначены для личных пет-проектов и
не призывают нарушать политику конфиденциальности вашей компании!

Я инженер по тестированию и уже около года поддерживаю работу своей песочницы по практике тестирования и подготовке к собеседованию на позицию Full Stack QA. Опыт вайбкодинга повлёк за собой понимания работы JS, CSS и HTML, если говорить конкретно про веб-проект. Благодаря такому проекту и подходу вайбкодинга, я собрал технические инструкции и заметки как выжать максимум из ответа ИИ моделей, здесь будет больше технических особенностей работы с моделями, нежели готовые промпты. Ниже указал 12 советов, которые упростят вам написание кода, разработку своего проекта, изучение нового стека или учебную практику.

Баги, пойманные на проде, всегда стоят слишком дорого — и времени, и нервов, и репутации. Юнит-тесты не видят проблем с реальными зависимостями, моки быстро устаревают, а интеграционные среды тормозят разработку. Выход ищут в подходе shift-left: проверять критичную бизнес-логику раньше, прямо в IDE, без ожидания CI. В этой статье разберём, как библиотека Testcontainers позволяет поднимать реальные сервисы в контейнерах, писать интеграционные тесты так же просто, как юнит-тесты, и что это даёт с точки зрения скорости и качества по метрикам DORA.

Привет, Хабр! Меня зовут Иван Калашников, я занимаюсь автотестированием в Инфовотч.

В мире web и тонких клиентов по-прежнему приходится тестировать классические приложения: Office apps, Explorer, Telegram, WhatsApp. Сегодня для примера мы возьмем WhatsApp.

Погрузившись в автоматизацию ручных кликов в приложениях Windows с помощью Python, я попробовал несколько известных библиотек, каждая из которых поодиночке оставляла ощущение «чего-то не хватает». PyAutoGUI не видит скрытые элементы, плохо находит элементы с экранами разного масштаба и разрешения, а pywinauto требует разбирать дерево элементов UIA (Microsoft UI Automation), которого может попросту не быть.

В этой статье разберём, как объединение этих инструментов позволяет обойти ограничения каждого и надёжно автоматизировать windows-приложения. Комбинация UI-ориентированных (pywinauto, Win32/UIA) и image-based (PyAutoGUI) техник остаётся самым гибким способом тестировать Windows-приложения. Но чтобы смесь действительно работала, нужны: сравнение бэкендов, явные ожидания, DPI-awareness.

Мы пройдем через ряд мини-кейсов — от кликов, поиска, отправки сообщения, до чтения текста с экрана и выясним, как справляется связка Python-библиотек.

Разбираем самые странные антипаттерны в автотестах на Python: от sleep(0.1) и стрелочек вниз до глобальных курсоров и "фреймворков" на 3500 строк. Почему так делать не стоит и какие есть взрослые альтернативы.

Асинхронность в Python кажется простой — добавил async/await, и всё летает. Но на практике синхронные вызовы внутри асинхронного кода превращаются в «бутылочное горлышко», блокируя event loop и приводя к непредсказуемым последствиям: от подвисших запросов до деградации производительности. Как разбираться в таком случае и почему важно знать особенности фреймворков в подкате...

Записки одного QA. Вспомогательная часть автотестов: советы и практики (Playwright + Typescript)

В статье рассматриваются подходы к организации вспомогательной части для автотестов на Playwright: структура проекта, Page Object, helpers, constants и шаги. Приведены практические примеры того, какие решения помогают поддерживать автотесты читаемыми и масштабируемыми, а каких стоит избегать. Материал будет полезен QA-инженерам и разработчикам, начинающим работать с Playwright.

Привет! Я Миша Симонов. Работаю в Контуре ведущим специалистом по тестированию и являюсь техлидом автоматизации тестирования кластера из 17 команд. Сегодня хороший день, чтобы рассказать об одной из задач, которой я занимаюсь — повышение квалификации сотрудников в области автоматизации тестирования.

Если ты опытный автоматизатор, то не проходи мимо и поделись своим опытом в комментариях к курсам. Эти комментарии прочтут не только администраторы, но и новички, проходящие курсы.

Отладка E2E-тестов может быть трудоёмкой задачей. При падении тестов Playwright нередко приходится вручную анализировать сообщения об ошибках и стек-трейсы, искать причины неудач (например, неправильно подобранный селектор, увеличенные задержки или неожиданные изменения в DOM) и пробовать разные варианты исправлений. Традиционно QA-инженерам приходится копировать текст ошибок и обращаться к документации или чат-ботам вроде ChatGPT с вопросами вроде «почему селектор не нашёлся» или «как увеличить таймаут». Это занимает время и отнимает ресурсы команды.

Тест-кейс тест-кейсу рознь!

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

Доработка кейсов своими силами (силами автотестеров) в процессе автоматизации – это сизифов труд.

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

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

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

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

Итак, начнем урок.

Есть небольшая книжка написанная более 20 лет назад, переведенная на русский как «Экстремальное программирование». При обсуждении этой книжки с коллегами я часто встречал мнение, что она только про то, что надо сначала тесты писать, а потом код и больше в ней нет ничего полезного. Когда у самого добрались руки до нее, я понял, что видимо читают выжимки из статей на Хабре или просто статьи википедии, потому что там есть и паттерны проектирования, и правила написания тестов и практические примеры. А все запоминают только мантру «Утром тесты — вечером стулья код».

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

В этой части обзора проанализируем ценовую политику продуктов и их подходы к позиционированию, а также рассмотрим, как компании взаимодействуют с сообществом.

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

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

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

Фильтрация — один из самых частых и критичных сценариев в интернет-магазинах и маркетплейсах. Ошибка в логике фильтров может стоить бизнесу продаж, а пользователям — нервов.

В этой статье я покажу, как построить гибкий и масштабируемый подход к тестированию фильтрации с помощью Playwright + TypeScript, используя: Page Object Model, Data-driven testing, конфигурацию фильтров и кастомные фикстуры.

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

Добрый день, уважаемые хабровчане! Меня зовут Евгений Иванов, и вот уже год я работаю на позиции QA-lead в компании FixPrice. В прошлом году руководство поставило передо мной задачу: наладить быстрый старт автотестирования и масштабирование решений на все проекты нашего отдела.

Mock-сервисы (или мок-сервисы) — это программные компоненты, которые имитируют поведение реальных сервисов, систем или зависимостей в процессе разработки и тестирования приложений. А мы сделали свой.

Дэвид Истман, разработчик ПО для Oracle Corp. и British Telecom, тестирует ИИ-инструмент для кодинга под названием Bolt. Совместно с ИИ-ассистентом он пробует разработать простенький проект блога, попутно рассуждая о сильных сторонах, ошибках и нюансах сервиса. Статья будет полезна новичкам и желающим приобщиться к вайб-кодингу работе с ИИ-помощниками.

Основан на pluggy. Основная единица pytest - pytest плагин. Написан достаточно интересно. Ключевое слово - “ключевое слово”. Основное взаимодействие в pytest происходит через хуки. Хук это некий этап к которому можно получить доступ к той или иной логики работы. Следуя из названия это некоторые крючки за который можно цепляться вставляя свои заплатки. Начинаются с pytest.

Фикстуры (Fixture) в  pytest это некий аналог мока/сетап tear down в unittests.  Это некие кусочки кода результаты которых могут быть пере использованы. Сами фикстуры реализованы как плагин. 

Как уже говорилось в эта система плагинов полагается на Pluggy. В Pluggy програамма полагается на PluginManager который управляет сохранения спецификаций хуков регистрацией плагинов и вызовом их. Плагины могут регистрировать сами себя в PluginManager.

Когда хук стартуют они вызывают свои имплементации по умолчанию как LIFO очередь - самый поздний элемент вызывается раньше всего. Для изменения этого порядка вызова можно применять trylast or tryfirst свойства в их имплементациях(пример). По умолчанию возвращается результат от всех имплементаций с исключением случая с как  firstresult свойством. В случае свойства firstresult программа возвращает результат первого не None результата. 

Другое интересное свойство имплементации плагина это hookwrapper.  С помощью этого свойства имплементации будут вести себя как обертки над другими хуками с помощью yield.

Вдохнули?

Хуки вызываются 3 способами:

Если вы когда-либо писали автотесты для веб-приложений с элементом canvas, то наверняка знаете, как это может быть непросто. Canvas — это "чёрный ящик", где привычные инструменты UI-тестирования бессильны: внутри нет DOM-структуры, за которую можно зацепиться. При этом на экране canvas может отображать что угодно — от графиков с осями X и Y до сложных анимаций.

Хотите узнать, как автоматизировать тестирование canvas без лишней боли? Давайте разберёмся на простом примере.

Я решил проверить, как популярные генераторы изображений справляются с одной и той же задачей: сделать фотореалистичный женский вариант известного персонажа игры. Участники: GPT (DALL·E), Gemini, Qwen и «Шедеврум» (Яндекс).