Boundary Value Analysis: Находим Баги на Границах

Освойте Анализ Граничных Значений (BVA) для поиска багов там, где они скрываются чаще всего. Изучите технику, примеры и повысьте покрытие.

Boundary Value Analysis: Находим Баги на Границах — критически важная дисциплина в современном обеспечении качества программного обеспечения. According to NIST, software bugs cost the US economy $59.5 billion annually, with about 80% preventable through better testing (NIST Software Testing Study). According to research by Capers Jones, finding and fixing a defect after deployment costs 10-100x more than finding it during design (Capers Jones Software Engineering Best Practices). Это руководство охватывает практические подходы, которые QA-команды могут применить немедленно: от базовых концепций и инструментов до реальных паттернов реализации. Независимо от того, развиваешь ли ты навыки в этой области или улучшаешь существующий процесс, здесь ты найдёшь действенные техники, подкреплённые практическим опытом. Цель — не просто теоретическое понимание, а рабочий фреймворк, который можно адаптировать под контекст команды, технологический стек и цели по качеству.

TL;DR
Тестируй рано и часто — стоимость исправления дефектов растёт экспоненциально после деплоя
Тестирование на основе рисков гарантирует, что наиболее важные области получают наибольшее внимание
Хорошие баг-репорты с шагами воспроизведения и ожидаемым/фактическим поведением ускоряют исправления
Подходит для: QA-инженеры, строящие или улучшающие процессы тестирования Пропустите если: Команды с полностью автоматизированными, зрелыми наборами тестов

Почему Границы Важны

Рассмотрим этот реальный баг из банковского приложения:

Валидация Суммы Перевода:

- Минимум: $1.00
- Максимум: $10,000.00

Баг: Перевод ровно $10,000.00 привел к ошибке:
"Сумма превышает максимальный лимит"

Причина: Разработчик использовал "amount < max" вместо "amount <= max"

Этот баг появился только на точном граничном значении. Тестирование $5,000 или $9,999 никогда бы его не обнаружило. Только тестирование на и около границы ($9,999.99, $10,000.00, $10,000.01) выявило бы проблему.

«Тестирование — это мастерство, а не просто чеклист. Самые эффективные тестировщики, с которыми я работал, сочетают глубокое знание домена со структурным мышлением — они предсказывают, где сломается ПО, ещё до написания первого тест-кейса.» — Юрий Кан, Senior QA Lead

Принцип BVA

Для любого входного диапазона с границами тестируйте эти значения:

Позиция	Значение для Теста	Почему
Чуть Ниже Мин	мин - 1	Должно быть отклонено (невалидно)
Точно Мин	мин	Должно быть принято (валидная граница)
Чуть Выше Мин	мин + 1	Должно быть принято (валидно)
Чуть Ниже Макс	макс - 1	Должно быть принято (валидно)
Точно Макс	макс	Должно быть принято (валидная граница)
Чуть Выше Макс	макс + 1	Должно быть отклонено (невалидно)

Это дает вам 6 тест-кейсов вместо тестирования тысяч случайных значений.

Базовый Пример BVA: Валидация Возраста

Требование: Поле возраста принимает значения от 18 до 65 (включительно)

Традиционный Подход к Тестированию (Неэффективный)

Тестовые значения: 25, 30, 35, 40, 45, 50, 55, 60
Результат: Все проходят, но ограниченное покрытие

Подход BVA (Эффективный)

Тестовые значения:

- 17 (мин - 1) → Ожидается: Отклонено ❌
- 18 (мин) → Ожидается: Принято ✅
- 19 (мин + 1) → Ожидается: Принято ✅
- 64 (макс - 1) → Ожидается: Принято ✅
- 65 (макс) → Ожидается: Принято ✅
- 66 (макс + 1) → Ожидается: Отклонено ❌

Результат: 6 целевых тестов с более высокой частотой обнаружения дефектов

Шаблон Тест-Кейса BVA

**ID Тест-Кейса**: TC-BVA-AGE-001
**Функция**: Валидация Возраста
**Граница**: 18-65 (включительно)

| ID Теста | Входное Значение | Позиция | Ожидаемый Результат | Фактический Результат | Статус |
|----------|-----------------|---------|--------------------|--------------------|--------|
| 1 | 17 | мин - 1 | Ошибка: "Возраст должен быть 18-65" | [Заполнить] | |
| 2 | 18 | мин | Принято | [Заполнить] | |
| 3 | 19 | мин + 1 | Принято | [Заполнить] | |
| 4 | 64 | макс - 1 | Принято | [Заполнить] | |
| 5 | 65 | макс | Принято | [Заполнить] | |
| 6 | 66 | макс + 1 | Ошибка: "Возраст должен быть 18-65" | [Заполнить] | |

Типы Границ для Тестирования

1. Числовые Диапазоны

Пример: Процент скидки (0% - 100%)

Тестовые Значения BVA:

- -1% → Невалидно
- 0% → Валидно (граница)
- 1% → Валидно
- 99% → Валидно
- 100% → Валидно (граница)
- 101% → Невалидно

Пример Реального Кода:

def apply_discount(price, discount_percent):
    # Версия с багом
    if discount_percent > 0 and discount_percent < 100:  # ❌ Баг: исключает 0 и 100
        return price * (1 - discount_percent / 100)
    else:
        raise ValueError("Невалидная скидка")

# BVA обнаружит этот баг:
apply_discount(100, 0)    # ❌ Выбрасывает ошибку (должно работать!)
apply_discount(100, 100)  # ❌ Выбрасывает ошибку (должно работать!)

# Исправленная версия
def apply_discount(price, discount_percent):
    if 0 <= discount_percent <= 100:  # ✅ Правильно: включает границы
        return price * (1 - discount_percent / 100)
    else:
        raise ValueError("Невалидная скидка")

2. Границы Длины Строки

Пример: Поле имени пользователя (3-20 символов)

Тестовые Значения BVA:

- 2 символа: "ab" → Невалидно
- 3 символа: "abc" → Валидно (граница мин)
- 4 символа: "abcd" → Валидно
- 19 символов: "abcdefghijklmnopqrs" → Валидно
- 20 символов: "abcdefghijklmnopqrst" → Валидно (граница макс)
- 21 символ: "abcdefghijklmnopqrstu" → Невалидно

Пример Автоматизации:

describe('Валидация Имени Пользователя - BVA', () => {
  test('должен отклонить имя пользователя с 2 символами (мин - 1)', () => {
    expect(validateUsername('ab')).toBe(false);
  });

  test('должен принять имя пользователя с 3 символами (мин)', () => {
    expect(validateUsername('abc')).toBe(true);
  });

  test('должен принять имя пользователя с 4 символами (мин + 1)', () => {
    expect(validateUsername('abcd')).toBe(true);
  });

  test('должен принять имя пользователя с 19 символами (макс - 1)', () => {
    expect(validateUsername('a'.repeat(19))).toBe(true);
  });

  test('должен принять имя пользователя с 20 символами (макс)', () => {
    expect(validateUsername('a'.repeat(20))).toBe(true);
  });

  test('должен отклонить имя пользователя с 21 символом (макс + 1)', () => {
    expect(validateUsername('a'.repeat(21))).toBe(false);
  });
});

3. Границы Даты/Времени

Пример: Система бронирования (резервации на 1-365 дней вперед)

Сегодня: 2025-10-02

Тестовые Значения BVA:

- Сегодня (день 0) → Невалидно (должно быть минимум 1 день вперед)
- Завтра (день 1) → Валидно (граница мин)
- Через 2 дня (день 2) → Валидно
- Через 364 дня → Валидно
- Через 365 дней → Валидно (граница макс)
- Через 366 дней → Невалидно

4. Границы Массива/Коллекции

Пример: Корзина покупок (1-99 товаров)

Тестовые Значения BVA:

- 0 товаров → Невалидно (пустая корзина)
- 1 товар → Валидно (граница мин)
- 2 товара → Валидно
- 98 товаров → Валидно
- 99 товаров → Валидно (граница макс)
- 100 товаров → Невалидно (превышает лимит)

BVA на Две Точки vs Три Точки

BVA на Две Точки (Минимальный)

Тестирует только граничные значения:

Для диапазона 18-65:

- 18 (мин)
- 65 (макс)

Плюсы: Самый быстрый подход Минусы: Может пропустить ошибки off-by-one

BVA на Три Точки (Стандартный)

Тестирует границу ± 1:

Для диапазона 18-65:

- 17 (мин - 1)
- 18 (мин)
- 19 (мин + 1)
- 64 (макс - 1)
- 65 (макс)
- 66 (макс + 1)

Плюсы: Лучший баланс покрытия и эффективности Минусы: Больше тест-кейсов, чем на две точки

Примеры BVA из Реального Мира

Пример 1: Промокод E-commerce

Требование: Промокод действителен для заказов $50-$500

def apply_discount_code(order_total, code):
    if order_total >= 50 and order_total <= 500:
        return order_total * 0.9  # 10% скидка
    else:
        raise ValueError("Сумма заказа должна быть $50-$500 для использования кода")

# Тест-Кейсы BVA:
assert raises_error(apply_discount_code(49.99, "SAVE10"))    # Чуть ниже мин
assert apply_discount_code(50.00, "SAVE10") == 45.00        # Точно мин
assert apply_discount_code(50.01, "SAVE10") == 45.01        # Чуть выше мин
assert apply_discount_code(499.99, "SAVE10") == 449.99      # Чуть ниже макс
assert apply_discount_code(500.00, "SAVE10") == 450.00      # Точно макс
assert raises_error(apply_discount_code(500.01, "SAVE10"))   # Чуть выше макс

Типичные Ошибки BVA

❌ Ошибка 1: Тестирование Только Валидных Границ

Плохой подход:

- Тест возраста = 18 ✅
- Тест возраста = 65 ✅
- Пропуск тестов: 17 ❌, 66 ❌

Решение: Всегда тестируйте невалидные границы (мин-1, макс+1)

❌ Ошибка 2: Забывание о Типах Данных

Для числового поля 1-100:

- Не забудьте протестировать: null, "", "abc", -1, 0.5, 100.5

BVA в Автоматизации

Анализ Граничных Значений идеален для автоматизации:

import pytest

@pytest.mark.parametrize("age,expected", [
    # Ниже минимальной границы
    (17, "Невалидный возраст"),
    # Минимальная граница
    (18, "Валидный"),
    # Чуть выше минимума
    (19, "Валидный"),
    # Чуть ниже максимума
    (64, "Валидный"),
    # Максимальная граница
    (65, "Валидный"),
    # Выше максимальной границы
    (66, "Невалидный возраст"),
])
def test_age_validation_bva(age, expected):
    result = validate_age(age)
    assert result == expected

Заключение

Анализ Граничных Значений — одна из самых эффективных техник проектирования тестов, потому что:

Высокая Обнаружимость Дефектов: Баги кластеризуются на границах
Эффективность: Тестируйте 6 значений вместо сотен
Систематичность: Без догадок, четкие тестовые значения
Автоматизируемость: Идеально для регрессионных наборов
Основанность на Рисках: Фокусируется на зонах высокого риска

BVA работает лучше всего в сочетании с Разбиением на Классы Эквивалентности для полного покрытия тестами.

Помните золотое правило: Если есть граница, тестируйте ее на краях, а не только посередине.

Смотрите также

Техники проектирования тест-кейсов — полный обзор методов проектирования тестов
Тестирование черного ящика — фундаментальные техники функционального тестирования
Баг-репорты, которые любят разработчики — как документировать найденные на границах дефекты
Стратегия автоматизации тестирования — автоматизация граничного тестирования
Исследовательское тестирование — комбинирование BVA с исследовательским подходом

Официальные ресурсы

FAQ

В чём разница между верификацией и валидацией? Верификация проверяет, что ты правильно создал продукт (соответствует спецификациям). Валидация проверяет, что ты создал правильный продукт (соответствует потребностям пользователя).

Когда следует прекращать тестирование? Останавливай тестирование, когда: риск снижен до приемлемого уровня, ограничения по времени/бюджету требуют этого, или определённые критерии выхода выполнены (напр., 95% покрытие, ноль критических дефектов).

Что делает баг-репорт хорошим? Хороший баг-репорт включает: точные шаги воспроизведения, фактическое vs ожидаемое поведение, детали окружения (ОС, браузер, версия), классификацию серьёзности и минимальный кейс воспроизведения.

Как расставлять приоритеты при нехватке времени? Используй тестирование на основе рисков: определи области с наибольшим риском (новый код, сложная логика, функции, ориентированные на клиентов) и тестируй их первыми.

Boundary Value Analysis: Находим Баги на Границах

Почему Границы Важны #

Принцип BVA #

Базовый Пример BVA: Валидация Возраста #

Традиционный Подход к Тестированию (Неэффективный) #

Подход BVA (Эффективный) #

Шаблон Тест-Кейса BVA #

Типы Границ для Тестирования #

1. Числовые Диапазоны #

2. Границы Длины Строки #

3. Границы Даты/Времени #

4. Границы Массива/Коллекции #

BVA на Две Точки vs Три Точки #

BVA на Две Точки (Минимальный) #

BVA на Три Точки (Стандартный) #

Примеры BVA из Реального Мира #

Пример 1: Промокод E-commerce #

Типичные Ошибки BVA #

❌ Ошибка 1: Тестирование Только Валидных Границ #

❌ Ошибка 2: Забывание о Типах Данных #

BVA в Автоматизации #

Заключение #

Смотрите также #

Официальные ресурсы #

FAQ #