Как протестировать в веб-приложении различные разрешения экрана

Стратегия тестирования различных разрешений экрана в веб-приложении

Тестирование на различных разрешениях экрана — адаптивный веб-дизайн (Responsive Web Design, RWD) — является критически важной частью обеспечения кросс-платформенной совместимости. Подход должен быть многоуровневым, сочетающим ручное, автоматизированное и инструментальное тестирование.

1. Планирование и анализ брейкпоинтов

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

• Типичные брейкпоинты (на основе Bootstrap, Tailwind CSS):

    *   `xs` (Extra small): < 576px — мобильные устройства.
    *   `sm` (Small): ≥ 576px — планшеты в портретной ориентации.
    *   `md` (Medium): ≥ 768px — планшеты в альбомной, небольшие ноутбуки.
    *   `lg` (Large): ≥ 992px — десктопы.
    *   `xl` (Extra large): ≥ 1200px — большие мониторы.

• Дополнительные сценарии: Тестирование на промежуточных разрешениях (например, 700px) для выявления проблем между заданными брейкпоинтами.

2. Ручное тестирование с помощью инструментов разработчика браузера

Наиболее быстрый и распространённый метод. В Chrome DevTools (аналогично в Firefox, Edge) есть вкладка Responsive (Ctrl+Shift+M или Cmd+Shift+M на Mac).

// Пример простого скрипта для быстрой проверки нескольких разрешений
// Можно выполнить в консоли DevTools для списка URL
const resolutions = [
    { width: 360, height: 640, name: 'Mobile S' },
    { width: 768, height: 1024, name: 'Tablet' },
    { width: 1024, height: 768, name: 'Desktop' },
    { width: 1920, height: 1080, name: 'Full HD' }
];

resolutions.forEach(res => {
    console.log(`Testing: ${res.name} (${res.width}x${res.height})`);
    // Здесь можно открыть новую вкладку с нужным размером
    // или использовать window.open с параметрами
});

Ключевые проверки при ручном тестировании:

• Верстка: Отсутствие горизонтального скролла, наложение элементов, правильные отступы.
• Контент: Текст читаем, изображения не обрезаются и масштабируются корректно, медиа-контент (видео) адаптируется.
• Навигация и взаимодействие: Все кликабельные элементы (кнопки, ссылки) доступны и имеют достаточную область для тапа (по правилам WCAG — минимум 44x44px). Выпадающие меню и модальные окна открываются корректно.
• Функциональность: Все формы, фильтры, слайдеры работают корректно. JavaScript-логика учитывает размер экрана.
• Производительность: На мобильных разрешениях важно проверить скорость загрузки тяжелых ресурсов (картинки высокого разрешения для десктопа могут неоправданно грузиться на телефон).

3. Автоматизированное тестирование с использованием Selenium/Playwright/Cypress

Автоматизация позволяет интегрировать проверки разрешений в CI/CD-пайплайн. Playwright и Cypress предоставляют удобные встроенные методы для этого.

# Пример на Playwright (Python). Playwright отлично подходит для кросс-браузерного тестирования.
import pytest
from playwright.sync_api import Playwright, sync_playwright, expect

@pytest.mark.parametrize("viewport", [
    {'width': 375, 'height': 667},   # iPhone SE
    {'width': 768, 'height': 1024},  # iPad Portrait
    {'width': 1280, 'height': 720},  # Desktop HD
])
def test_homepage_responsive(playwright: Playwright, viewport):
    browser = playwright.chromium.launch(headless=True)
    context = browser.new_context(viewport=viewport)
    page = context.new_page()

    page.goto("https://your-app.com")

    # Пример проверки: навигационное меню на мобильном должно быть скрыто за гамбургером
    if viewport['width'] < 768:
        expect(page.locator('.desktop-nav')).to_be_hidden()
        expect(page.locator('.hamburger-menu')).to_be_visible()
    else:
        expect(page.locator('.desktop-nav')).to_be_visible()

    # Сделаем скриншот для визуальной регрессии
    page.screenshot(path=f"screenshot_{viewport['width']}x{viewport['height']}.png")
    browser.close()

// Пример на Cypress (JavaScript). Cypress удобен для интеграции с фронтенд-стеком.
describe('Responsive Tests', () => {
  const viewports = ['macbook-15', 'ipad-2', 'iphone-xr'];

  viewports.forEach(viewport => {
    it(`Should display correctly on ${viewport}`, () => {
      cy.viewport(viewport);
      cy.visit('/');
      cy.get('header').should('be.visible');

      // Проверка изменения layout
      if (viewport.startsWith('iphone')) {
        cy.get('.mobile-menu-button').should('be.visible');
        cy.get('.desktop-nav').should('not.be.visible');
      } else {
        cy.get('.desktop-nav').should('be.visible');
      }
    });
  });
});

4. Визуальное регрессионное тестирование

Инструменты вроде Percy, Applitools Eyes или Loki делают снимки экрана на разных разрешениях и сравнивают их с эталонными изображениями («бейзлайнами»), автоматически обнаруживая незапланированные визуальные изменения. Это незаменимо для контроля UI после правок в CSS или верстке.

5. Тестирование на реальных устройствах и эмуляторах

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

• Реальную производительность GPU и CPU.
• Особенности рендеринга в мобильных браузерах.
• Поведение тач-событий (свайпы, мультитач).
• Влияние плотности пикселей (Retina-дисплеи).

Используйте облачные сервисы, такие как BrowserStack, Sauce Labs, LambdaTest, которые предоставляют доступ к огромной ферме реальных устройств и браузеров.

Критерии успешного тестирования:

• Функциональная целостность: Все фичи работают на каждом разрешении.
• Визуальная целостность: Макет соответствует макетам (Figma, Adobe XD) и не «ломается».
• Юзабилити: Интерфейс удобен для использования (крупные кнопки на тач-устройствах, читаемый текст).
• Производительность: Страница загружается в разумные сроки, анимации плавные.

Итог: Эффективное тестирование разрешений требует комбинации методов: от быстрой ручной проверки в DevTools до автоматизированных скриншотных тестов в пайплайне и валидации на реальных устройствах. Ключ — понимание брейкпоинтов проекта и приоритизация сценариев, исходя из аналитики посещений (например, если 70% трафика — мобильный, тестирование начинается с него).