Доменное тестирование

Доменное тестирование (domain testing) — одна из ключевых техник в арсенале QA-инженера. Её популярность обусловлена высокой эффективностью при минимальных затратах ресурсов: исследования NIST показывают, что 65-75% критических ошибок в ПО возникают на границах входных значений. Этот метод целенаправленно проверяет точки, где вероятность сбоев максимальна, обеспечивая до 40% снижение дефектов в production (данные ISTQB). В отличие от хаотичных проверок, техника доменного тестирования предлагает системный подход к анализу данных, что особенно критично для финансовых, медицинских и государственных систем, где ошибки в обработке граничных значений могут привести к катастрофическим последствиям.

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

Доменное тестирование — это метод черного ящика, фокусирующийся на проверке поведения системы при обработке данных из разных классов эквивалентности, особенно на границах между ними. Эта техника основана на фундаментальном принципе: если программа корректно обрабатывает значения на границах допустимых диапазонов, она будет корректно работать и с любыми другими значениями внутри этих диапазонов.

Ключевые понятия

• Домен — логически связанный диапазон входных значений (например, цены от 100 до 1000 руб).

• Класс эквивалентности — группа значений с идентичной обработкой системой (напр., все числа 18-65 лет).

• Граничные значения — критические точки перехода между доменами (напр., 17, 18, 65, 66 для возраста).

Цель: выявление ошибок обработки на стыках классов эквивалентности.

Пример

Поле «Возраст»:

Валидный домен: [18, 65] 

Граничные точки:

•   17 (отклонено),

•   18 (принято),

•   65 (принято),

•   66 (отклонено) 

Дополнительные проверки:

  null (ошибка),

  "" (пустая строка → ошибка),

  "восемнадцать" (текст → ошибка)

Как работает техника доменного тестирования: 4 этапа

Этап 1. Идентификация доменов

Анализ требований:

• Выявление параметров с ограничениями (числа, строки, даты).

• Уточнение форматов через регулярные выражения: ^\d{1,3}(\.\d{1,2})?$  // Для цен с 1-3 цифрами до точки и 1-2 после

Определение доменов:

• Валидные (напр., 0.01 ≤ цена ≤ 1 000 000)

• Невалидные (отрицательные значения, превышение лимита)

• Специальные случаи:

• Пустые значения

• Null/undefined

• Unicode-символы (эмодзи, арабская вязь)

• SQL-инъекции (например, 100; DROP TABLE users)

Этап 2. Выбор тестовых данных

Стратегия для каждой границы (для выбранного диапазона 18-65 лет):

Дополнительные проверки:

• Экстремальные значения:

• Для чисел: 0, MAX_INT, MIN_INT

• Для строк: 255+ символов, спецсимволы (~!@#$%^&*()_+)

• Культурные особенности:

• Форматы дат (DD.MM.YYYY vs MM/DD/YYYY)

• Разделители тысяч (1 000 vs 1,000)

Этап 3. Разработка тест-кейсов

Структура тест-кейса в Gherkin:

Feature: Валидация цены товара

Сценарий: Проверка верхней границы

Дано: Открыта форма добавления товара

Когда: В поле «Цена» вводится «1 000 000.01»

Тогда: Отображается ошибка «Превышена максимальная цена»

И: Кнопка «Сохранить» неактивна

Этап 4. Выполнение и анализ

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

• JIRA для баг-трекинга

• Allure для визуализации отчетов

• Prometheus/Grafana для мониторинга ошибок в production

• Метрики:

Эффективность = (Кол-во найденных граничных дефектов / Общее кол-во дефектов) × 100%

Цель: > 70%

Пример 1: Тестирование поля «Цена товара»

Требования:

• Диапазон: 0.01 – 1 000 000 руб.

• Формат: 2 знака после точки, разделитель — точка.

• Дополнительные ограничения: запрет отрицательных значений, автоматическое округление.

Расширенный тест-дизайн:

Пример доменного тестирования

Пример 1: Тестирование поля «Дата рождения»

Требования:

• Минимальный возраст: 18 лет

• Формат: ДД.ММ.ГГГГ

• Запрет будущих дат

Расчет границ (на 06.08.2025):

• Валидная дата: ≤ 06.08.2007

• Граничные значения:

• 05.08.2007 (принято)

• 06.08.2007 (принято)

• 07.08.2007 (ошибка)

Особые случаи:

Пример 2: Тестирование поля «Размер файла»

Требования:

• Максимальный размер: 10 МБ

• Поддерживаемые форматы: PDF, JPG, PNG

Тестовые данные:

Пример 3: Тестирование поля «Пароль»

Требования:

• Длина: 8-32 символа

• Обязательные: 1 заглавная буква, 1 цифра, 1 спецсимвол

• Запрещенные последовательности ("123456", "qwerty")

Тестовые данные:

Преимущества техники

1. Экономическая эффективность: 5-7 тестов покрывают до 90% граничных сценариев (практика Microsoft).

2. Раннее выявление критических дефектов: 68% boundary-ошибок относятся к severity High/Critical.

3. Стандартизация процесса: Четкий алгоритм для Junior QA.

4. Интеграция с CI/CD: Автотесты на Pytest или JUnit выполняются за 2-3 сек. на параметр.

5. Универсальность: Применимо для:

• Веб-форм (Selenium)

• API (Postman, RestAssured)

• Мобильных приложений (Appium)

• Баз данных (SQL-инъекции)

1. Профилактика уязвимостей: Выявление XSS, SQL-инъекций на этапе тестирования.

Недостатки и ограничения

Зависимость от требований

• Проблема: 42% ошибок в тест-дизайне вызваны неполными спецификациями (QASymphony).

• Решение: Проводить совместные сессии с аналитиками.

Ограниченность для комбинаций

• Пример: Границы скидки зависят от категории товара → требует Pairwise Testing.

Ложные срабатывания

• Кейс: Ошибка валидации для "1 000 000.00" из-за пробела → нужна нормализация ввода.

Динамические границы

• Сценарий: Максимальный размер файла зависит от подписки пользователя.

• Решение: Параметризованные тесты с разными ролями.

Сложность для нечетких границ

• Пример: "Рекомендуемый возраст игры: 12+".

Решение: Использовать техники тестирования на основе рисков.

Практические рекомендации

1. Комбинируйте методы:

• Доменное тестирование + Эквивалентное разделение.

• Для веб-форм: добавлять проверки через Selenium WebDriver.

1. Автоматизируйте рутину:

# Расширенный пример теста на Pytest

import pytest

PRICE_VALID = ["0.01", "1.00", "999999.99", "1000000.00"]

PRICE_INVALID = ["0.00", "-5", "1000000.01", "1e6", "десять"]

@pytest.mark.parametrize("price", PRICE_VALID)

def test_valid_prices(price):

  assert validate_price(price) is True

@pytest.mark.parametrize("price", PRICE_INVALID)

def test_invalid_prices(price):

assert validate_price(price) is False

1. Проверяйте требования:

• Используйте чек-лист для анализа спецификаций:

[ ] Границы явно указаны

[ ] Форматы данных описаны

[ ] Поведение при ошибках определено

[ ] Учет культурных особенностей

[ ] Обработка null/пустых значений

1. Экстремальное тестирование:

• Для числовых полей: проверка MAX_INT, MIN_INT.

• Для строк: ввод 10 000 символов, XSS-инъекции.

1. Интеграция в CI/CD:

# Пример конфигурации GitLab CI

stages:

  - test

boundary_testing:

  stage: test

  image: python:3.9

  script:

- pip install pytest

- pytest boundary_tests.py

  rules:

- changes:

     - "src/validation_logic.py"

Овладев методом доменного тестирования, тестировщик получает мощный и эффективный инструмент для обеспечения качества. Это не панацея, но краеугольный камень в стратегии тестирования любого ПО, работающего с данными, имеющими ограничения. Умение видеть "страны" данных, их границы и законы позволяет предугадывать, где система может споткнуться, и целенаправленно проверять эти уязвимые места. Внедряя domain testing в свою практику, вы делаете ставку на осознанное, структурированное и результативное выявление дефектов, экономя время и укрепляя надежность вашего продукта там, где это критически важно — на границах его возможностей.

Остались вопросы? Вы можете задать их нашим специалистам на бесплатной консультации.