Работа Кирилла

1. Архитектура тестирования: нашего будущего стека и его эффективность

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

2.

Наш будущий технологический стек
Инструмент
Назначение в архитектуре
Ключевая выгода
Python
Базовый язык программирования
Универсальность, богатая экосистема
библиотек, читаемость, поддержка
сообщества
Playwright
Сквозное (E2E) UI-тестирование для
Web
Высокая скорость, стабильность,
встроенные ожидания, поддержка
нескольких браузеров
Requests
Тестирование API (бэкенд)
Простота, скорость, прямое
тестирование бизнес-логики без
накладных расходов UI
Faker
Генерация тестовых данных
Чистота тестов, разнообразие сценариев,
независимость от конкретных данных в
БД
Allure Report
Визуализация результатов тестов
Наглядные отчеты с шагами,
артефактами (скриншоты, логи),
анализом дефектов
Appium
UI-тестирование мобильных
приложений (Android)
Кросс-платформенность, использование
одного языка (Python) для Web и Mobile
Locust
Нагрузочное тестирование
Python-код для сценариев, простота
описания пользовательского поведения,
мощная масштабируемость

3.

Плюсы архитектуры (сильные стороны)
1. Полный охват (Full-Stack Testing):
UI (Playwright/Appium): Проверяем конечный опыт пользователя.
API (Requests): Проверяем бизнес-логику, контракты и надёжность сервисов.
Load (Locust): Проверяем производительность и стабильность под нагрузкой.
Итог: Минимизируем риск пропуска критических дефектов на любом уровне.
2. Экономическая эффективность и скорость (Pyramid of Testing):
Большая часть проверок выполняется через API (Requests) — это быстро и
дёшево.
UI-тесты (Playwright) используются для ключевых пользовательских
сценариев. Это стабильнее и быстрее, чем чистый UI-подход.
Итог: Быстрая обратная связь при прогоне тестов и меньшая стоимость
поддержки.

4.

3. Стабильность и надёжность:
Faker обеспечивает изолированные тесты с уникальными данными.
Playwright обладает устойчивыми селекторами и умными ожиданиями.
API-тесты не зависят от изменений в интерфейсе.
Итог: Меньше «флаки» (случайных падений) тестов, выше доверие команды.
4. Мощная аналитика и отчётность:
Allure Report даёт не просто статус "Pass/Fail", а полную историю
выполнения: шаги, скриншоты на падения, логи запросов.
Итог: Ускоренная локализация дефектов и понятная отчётность для всех
членов
команды (тестировщики, разработчики, аналитики, DEVOPS).
5. Единая экосистема (Python):
Все инструменты связаны одним языком. Можно использовать общие
утилиты, хелперы, конфиги.
Итог: Лёгкость обучения, повторное использование кода, простая интеграция
между слоями тестов.

5.

Минусы и вызовы архитектуры
1. Сложность настройки и обучения:
Необходима экспертиза в большом количестве инструментов.
Требуется время на построение правильной, масштабируемой
структуры проекта (где что лежит).
Риск: Высокий порог входа для новых членов команды.
2. Затраты на поддержку:
Несмотря на стабильность, UI-тесты (Playwright/Appium) всё
равно требуют обновления при крупных изменениях вёрстки.
Необходимо следить за обновлениями всех библиотек и
фреймворков.
Риск: «Расползание» кодовой базы и увеличение времени на
рефакторинг.

6.

3. Требовательность к инфраструктуре:
Для параллельного запуска нужны мощные агенты (CI/CD).
Для Appium требуется настройка эмуляторов/реальных устройств.
Для Locust — выделенные серверы для генерации нагрузки.
Риск: Дополнительные финансовые и административные затраты.
4. Опасность «перетестирования»:
Соблазн написать много медленных UI-тестов там, где достаточно
быстрых API-проверок.
Риск: Долгий прогон тестовой пачки, что замедляет процесс
разработки.

7.

Ключевая интеграция: Почему мы используем API
вместе с UI?
Проблема чистого UI-тестирования:
Медленно: Каждое действие — загрузка страницы, отрисовка
элементов.
Хрупко: Падает из-за любых изменений вёрстки.
Сложно подготовить состояние: Чтобы проверить сложный
сценарий (напр., «Отчеты»), нужно через интерфейс создать
треки, проходы, пользователей.

8.

Наше решение: Гибридный подход (API + UI)
1. Подготовка и очистка тестовых данных через API (Requests):
• До запуска UI-теста мы через API:
• Создаём пользователя.
• Добавляем треки/факты прохода.
• После UI-теста чистим данные через API.
Выгода: UI-тест начинает работу сразу с нужного состояния. Он
становится короче, стабильнее и сосредоточен только на проверке
интерфейса.

9.

2. Проверка бизнес-логики и состояния системы через API:
• UI-тест может кликнуть кнопку «Создать профиль».
• Но чтобы убедиться, что «Профиль» действительно создался в
системе с правильными данными, мы делаем API-запрос (GET)
Выгода: Мы проверяем не только то, что "исчезло всплывающее
окно", а реальное состояние бэкенда. Это более глубокая и надежная
проверка.
3. Пример сценария «Создание Закладки в профиле":
1) (API, Requests) Создаём тестового пользователя и камеру. → Быстро, нет UI.
2) (UI, Playwright) Логинимся, Переходим в факты прохода. → Проверяем UI-логику.
3) (UI, Playwright) Нажимаем «Добавить закладку».
4) (API, Requests) Запрашиваем статус созданной закладки. → Проверяем бизнеслогику.
5) (API, Requests) Удаляем тестовые данные. → Чистота окружения.

10.

Итоговый выигрыш:
Скорость: Тесты выполняются в 2-3 раза быстрее.
Стабильность: Меньше зависимостей от изменений фронтенда.
Надёжность: Проверка на уровне данных, а не только интерфейса.
Чистота: Тесты не зависят от данных, оставшихся от предыдущих запусков.

11.

Заключение и выводы
Наша будущая архитектура — не набор отдельных инструментов, а продуманная
экосистема.
Она обеспечивает максимальный охват при минимальном времени выполнения
за счёт принципа пирамиды тестирования.
Ключевое преимущество — интегрированное использование API (Requests) для
подготовки и проверки, что делает UI-тесты (Playwright/Appium) быстрыми и
работоспособными.
Вызовы (сложность, поддержка) нивелируются выстроенными процессами,
обучением команды и значительным выигрышем в качестве продукта и скорости
разработки в долгосрочной перспективе.
Предлагаемое решение: внедрение данной архитектуры необходимо для расширения
функционального покрытия продукта. Это позволит обеспечить его стабильность и
высокое качество, а также организовать оперативную обратную связь о текущем
состоянии разработки.

12. Пройденный этап. Создан базовая архитектура автотестирования

Цель этапа: Построить надежную, поддерживаемую и многофункциональную
основу для автоматизации тестирования веб-приложения.
Выполненные ключевые работы:
1. Архитектура и инфраструктура
Разработана модульная архитектура тестирование с разделением тестов, шагов и
UI-элементов.
Создана подробная инструкция по установке и настройке всего необходимого ПО
для команды.
2. Функциональное тестирование (API & UI)
Реализован CRUD-тест через API с использованием Requests.
Настроено взаимодействие API и UI: данные создаются через API, а проверяются в
интерфейсе (Playwright + Requests).

13.

3. Визуальное тестирование
Создан автотест для сравнения скриншотов (актуальный vs эталонный) с
автоматическим подсветом различий с помощью библиотеки Pillow (PIL).
4. Удобство разработки и отчетность
Внедрена библиотека Faker для генерации реалистичных динамических
тестовых данных.
Реализована система меток (Tags) для гибкого запуска групп тестов
(например, @smoke, @api).
Интегрирован Allure для создания наглядных и детализированных отчетов о
прогоне тестов.
Итог: Создано полноценное архитектура автотестов, покрывающее основные
аспекты тестирования

14. Дорожная карта. Планы по расширению архитектуры

Цель этапа: Расширить охват автоматизации на мобильные платформы, добавить
нефункциональное тестирование и внедрить процессы CI/CD.
Планы по развитию:
1. Мобильное тестирование (Android)
Интеграция Appium для UI-тестирования мобильных приложений.
Автоматизация развертывания и управления виртуальными Android-машинами для тестов.
Реализация функционала передачи изображений в камеру эмулятора/устройства.
2. Нагрузочное тестирование
Внедрение инструмента Locust для создания сценариев нагрузочного тестирования API и ключевых
пользовательских сценариев.
Настройка генерации и визуализации отчетов по результатам нагрузочного тестирования.
3. Интеграция в процесс разработки (CI/CD)
Настройка автоматического запуска автотестов на dev-стенде при обновлении кода.
Контейнеризация фреймворка: упаковка тестов и зависимостей в Docker-образ для обеспечения
воспроизводимости и простоты запуска в CI-пайплайнах.
Итог: Доведение архитектуры до универсального решение, охватывающее мобильную платформу,
нагрузочное тестирование и работающее в полностью автоматизированном контуре CI/CD.