\nОжидается: скрипт не выполнится, текст выведется как есть\nДефект: если скрипт выполнится\n```\n\n**CSRF (Cross-Site Request Forgery):**\n```\nТестирую: может ли сайт А заставить мой браузер\nпередать деньги со счета на другой сайт?\nОжидается: нет, есть CSRF токен\n```\n\n**Инструменты:**\n- OWASP ZAP — автоматическое сканирование уязвимостей\n- Burp Suite — перехват и анализ запросов\n- Metasploit — имитация реальных атак\n\n**Что я тестирую:**\n- Пароли не хранятся в открытом виде (только хеши)\n- Чувствительные данные не передаются в URL\n- HTTPS используется везде\n- Нет SQL injection уязвимостей\n- Нет XSS уязвимостей\n- Rate limiting защищает от brute-force атак\n\n**6. Compatibility Testing (Совместимость)**\n\nТестируем работу на разных платформах и конфигурациях.\n\n**Платформы:**\n- Браузеры: Chrome, Firefox, Safari, Edge\n- ОС: Windows, macOS, Linux\n- Мобильные: iOS, Android\n- Версии: старые и новые версии\n\n**Пример:**\n```\nТестирую на:\n- Chrome 120 + Windows 11 ✓\n- Firefox 121 + Windows 11 ✓\n- Safari 17 + macOS Monterey ✓\n- IE 11 + Windows 7 ✗ (официально не поддерживаем)\n```\n\n**Инструменты:**\n- BrowserStack — тестирование на 2000+ конфигураций\n- Sauce Labs — облачное тестирование\n- LambdaTest — параллельное тестирование\n\n**7. Usability Testing (Юзабилити)**\n\nТестируем удобство использования приложения.\n\n**Вопросы:**\n- Может ли новый пользователь разобраться в интерфейсе?\n- Сколько клавиш/кликов нужно для стандартной операции?\n- Понимают ли пользователи сообщения об ошибках?\n- Интерфейс интуитивен?\n\n**Методы:**\n- Юзабилити-сессии с реальными пользователями\n- A/B тестирование двух вариантов\n- Тепловые карты (где пользователи кликают)\n- Запись сессий (как пользователь взаимодействует)\n\n**Инструменты:**\n- Hotjar — тепловые карты и записи\n- UserTesting.com — сессии с реальными пользователями\n- Figma — прототипирование и тестирование\n\n**8. Accessibility Testing (Доступность)**\n\nТестируем, может ли приложение использовать человек с ограничениями.\n\n**Типы ограничений:**\n- Слепота — используют screen reader (NVDA, JAWS)\n- Слабое зрение — увеличение шрифта, высокий контраст\n- Проблемы с моторикой — только клавиатура, без мыши\n- Глухота — субтитры в видео\n- Дальтонизм — не полагаться только на цвет\n\n**Что проверяю:**\n```\n✓ alt текст для всех изображений\n✓ Контраст текста >= 4.5:1\n✓ Можно управлять клавиатурой (Tab, Enter)\n✓ Fokus видимый\n✓ Семантический HTML (PrepBro
← Назад к вопросам

Что такое расширенное тестирование?

2.0 Middle🔥 101 комментариев
#Теория тестирования

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI26 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Расширенное тестирование (Extended Testing / Non-Functional Testing)

Что такое расширенное тестирование?

Расширенное тестирование — это проверка качества приложения за пределами основной функциональности. Если функциональное тестирование проверяет "что работает", то расширенное проверяет "как хорошо работает".

Основные типы расширенного тестирования

1. Performance Testing (Тестирование производительности)

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

Что тестируем:

  • Response time (время ответа): API должен ответить за 200ms
  • Throughput (пропускная способность): система может обработать 1000 запросов в секунду
  • Memory usage (использование памяти): приложение не утечет память
  • CPU usage (использование CPU): оптимальное использование процессора
  • Database query time: запросы выполняются быстро

Пример:

Тест: Загрузка списка из 1000 товаров
Ожидается: < 500ms
Дефект: если 2 секунды

Инструменты:

  • Apache JMeter — нагрузочное тестирование
  • Locust — для распределенной нагрузки
  • New Relic — мониторинг production
  • DataDog — аналитика производительности

Что я тестирую:

  • При увеличении нагрузки система остается отзывчивой
  • Нет утечек памяти после 1 млн запросов
  • При пиковой нагрузке система gracefully degrade (деградирует, но не падает)

2. Load Testing (Нагрузочное тестирование)

Тестируем поведение при увеличивающейся нагрузке.

Сценарий:

Рейсов: 1 пользователь
Ожидание: система работает нормально

↓ ↓ ↓ ↓

Рейсов: 100 пользователей одновременно
Ожидание: система остается быстрой

↓ ↓ ↓ ↓

Рейсов: 1000 пользователей
Ожидание: система работает, может быть медленнее, но не падает

Пример:

Тест Black Friday для интернет-магазина:
- Нормально: 100 пользователей одновременно
- Black Friday: 10000 пользователей одновременно
Ожидается: сайт остается доступен, может быть медленнее
Дефект: сайт падает при 5000 пользователей

3. Stress Testing (Стресс-тестирование)

Тестируем граничные возможности системы — когда она ломается?

Сценарий: Постоянно увеличиваем нагрузку до отказа.

100 users → OK
500 users → OK
1000 users → OK
5000 users → SLOW
10000 users → TIMEOUT
50000 users → CRASH

Так мы находим breaking point (точку отказа).

Вопросы:

  • При какой нагрузке система начинает падать?
  • Как она падает? (постепенно или вдруг?)
  • Восстанавливается ли после снижения нагрузки?
  • Потеряются ли данные при краше?

4. Reliability Testing (Надежность)

Проверяем стабильность длительной работы.

Сценарий:

Держу систему под нагрузкой 24 часа подряд
Проверяю:
- Растет ли память?
- Увеличивается ли CPU?
- Падает ли скорость ответа?
- Появляются ли ошибки в логах?

Пример: Мониторю production сервер 48 часов и смотрю графики памяти. Если память растет с 1GB до 4GB за сутки — есть утечка.

5. Security Testing (Тестирование безопасности)

Тестируем защиту от атак и защиту данных.

Типы атак:

SQL Injection:

Вводу в email: admin' --
Ожидается: ошибка или безопасное экранирование
Дефект: если система выполнит удаление всех пользователей

XSS (Cross-Site Scripting):

Вводу в имя: <script>alert('hacked')</script>
Ожидается: скрипт не выполнится, текст выведется как есть
Дефект: если скрипт выполнится

CSRF (Cross-Site Request Forgery):

Тестирую: может ли сайт А заставить мой браузер
передать деньги со счета на другой сайт?
Ожидается: нет, есть CSRF токен

Инструменты:

  • OWASP ZAP — автоматическое сканирование уязвимостей
  • Burp Suite — перехват и анализ запросов
  • Metasploit — имитация реальных атак

Что я тестирую:

  • Пароли не хранятся в открытом виде (только хеши)
  • Чувствительные данные не передаются в URL
  • HTTPS используется везде
  • Нет SQL injection уязвимостей
  • Нет XSS уязвимостей
  • Rate limiting защищает от brute-force атак

6. Compatibility Testing (Совместимость)

Тестируем работу на разных платформах и конфигурациях.

Платформы:

  • Браузеры: Chrome, Firefox, Safari, Edge
  • ОС: Windows, macOS, Linux
  • Мобильные: iOS, Android
  • Версии: старые и новые версии

Пример:

Тестирую на:
- Chrome 120 + Windows 11 ✓
- Firefox 121 + Windows 11 ✓
- Safari 17 + macOS Monterey ✓
- IE 11 + Windows 7 ✗ (официально не поддерживаем)

Инструменты:

  • BrowserStack — тестирование на 2000+ конфигураций
  • Sauce Labs — облачное тестирование
  • LambdaTest — параллельное тестирование

7. Usability Testing (Юзабилити)

Тестируем удобство использования приложения.

Вопросы:

  • Может ли новый пользователь разобраться в интерфейсе?
  • Сколько клавиш/кликов нужно для стандартной операции?
  • Понимают ли пользователи сообщения об ошибках?
  • Интерфейс интуитивен?

Методы:

  • Юзабилити-сессии с реальными пользователями
  • A/B тестирование двух вариантов
  • Тепловые карты (где пользователи кликают)
  • Запись сессий (как пользователь взаимодействует)

Инструменты:

  • Hotjar — тепловые карты и записи
  • UserTesting.com — сессии с реальными пользователями
  • Figma — прототипирование и тестирование

8. Accessibility Testing (Доступность)

Тестируем, может ли приложение использовать человек с ограничениями.

Типы ограничений:

  • Слепота — используют screen reader (NVDA, JAWS)
  • Слабое зрение — увеличение шрифта, высокий контраст
  • Проблемы с моторикой — только клавиатура, без мыши
  • Глухота — субтитры в видео
  • Дальтонизм — не полагаться только на цвет

Что проверяю:

✓ alt текст для всех изображений
✓ Контраст текста >= 4.5:1
✓ Можно управлять клавиатурой (Tab, Enter)
✓ Fokus видимый
✓ Семантический HTML (<button>, <label>, <input>)
✓ Aria labels для сложных компонентов

Инструменты:

  • Axe DevTools — автоматическое сканирование
  • WAVE — веб-доступность
  • Lighthouse — аудит доступности
  • Screen readers: NVDA (Windows), VoiceOver (macOS)

9. Localization Testing (Локализация)

Тестируем работу с разными языками и культурными особенностями.

Что проверяю:

  • Текст правильно переводится на все языки
  • Дата форматируется правильно (US: 01/31/2024, EU: 31/01/2024)
  • Валюта отображается правильно ($ для USD, € для EUR)
  • RTL языки (арабский, иврит) отображаются справа налево
  • Специальные символы не сломаны (русские буквы, иероглифы)
  • Длинные тексты не выходят за границы (немецкий длиннее английского)

10. Compliance Testing (Соответствие стандартам)

Тестируем соответствие законам и стандартам.

Примеры:

  • GDPR (защита данных в ЕС) — пользователь может скачать свои данные
  • HIPAA (здравоохранение) — медицинские данные защищены
  • PCI DSS (платежи) — номера карт не хранятся
  • WCAG 2.1 (доступность веба) — AAA уровень

Сравнение функционального и расширенного тестирования

АспектФункциональноеРасширенное
ПроверяетЧто работаетКак хорошо работает
ВопросЗагружается ли страница?За сколько мс загружается?
ПримерыКнопка работаетКнопка отзывчива за 100ms
ИнструментыSelenium, PostmanJMeter, ZAP, NVDA
ВремяНепрерывно в спринтеПеред релизом
ТребуетСпецификацияСпецификация + доп. требования

Практический пример расширенного тестирования

Проект: платежная система

Функциональные тесты (обязательно):

  • Платеж успешен при корректной карте
  • Платеж отклонен при невалидной карте

Расширенное тестирование:

  • Performance: платеж обрабатывается за 1-2 секунды
  • Load: система выдерживает 1000 платежей в секунду
  • Stress: система не теряет данные при 5000 платежей/сек
  • Security: номер карты не логируется, используется PCI DSS
  • Reliability: система работает 99.99% времени
  • Compliance: соответствует PCI DSS стандарту

Когда проводить расширенное тестирование?

Перед каждым релизом:

  • Performance тесты
  • Security сканирование
  • Compatibility проверка

Перед production:

  • Нагрузочное тестирование
  • Stress тестирование
  • Compliance проверка

Во время разработки:

  • Unit тесты (разработчики)
  • Юзабилити-тесты (на прототипе)
  • Accessibility тесты

Важность расширенного тестирования

Расширенное тестирование не менее важно, чем функциональное:

  • Быстрая система дает лучший UX
  • Безопасная система защищает пользователей
  • Доступная система для всех
  • Надежная система не теряет данные

Для критичных приложений (платежи, здравоохранение, финансы) расширенное тестирование обязательно.