Требование задаёт входные данные, но не описывает ожидаемый результат. На что должен опереться тестировщик при проверке?
Тестировщик должен найти или сформировать оракул тестирования — надёжный источник, по которому можно определить корректность результата. Это может быть уточнённое требование, бизнес-правило, инвариант, эталонный расчёт или согласованное поведение аналогичной системы. Если достоверного оракула нет, тест может выявить сбой или нарушение свойства, но не доказать полную корректность результата.
Подход появился из практической проблемы: проверить выполнение операции недостаточно, нужно ещё понять, является ли полученный результат правильным. Во многих системах невозможно заранее выписать ожидаемый ответ для каждого набора входных данных, поэтому используют разные источники ожидаемого поведения.
Оракул не обязательно представляет собой отдельное средство или программу. Это может быть нормативное правило, формула, ограничение предметной области, результат независимого расчёта или свойство, которое должно сохраняться после операции.
Если требование содержит только входные данные, тестировщик рискует принять любое завершение операции за успех. Такой тест может обнаружить падение или неверный формат, но пропустить неправильное бизнес-значение.
Отсутствие оракула приводит к субъективной проверке, спорным дефектам и ложной уверенности в качестве. Нельзя корректно зарегистрировать дефект только потому, что результат кажется неожиданным: сначала нужно подтвердить, каким он должен быть.
Сначала нужно определить, какой источник задаёт ожидаемое поведение. Приоритет обычно имеют уточнённые требования и согласованные бизнес-правила; затем применяются математические свойства, инварианты, независимые вычисления и другие проверяемые ограничения.
Если точное значение неизвестно, можно проверить свойства результата. Например, после сортировки элементы должны быть упорядочены, их состав должен сохраниться, а повторное применение операции не должно менять уже достигнутое состояние, если это предусмотрено правилом.
Важно отличать оракул от тестовых данных. Данные задают вход, а оракул определяет, как оценить выход. Также нельзя безоговорочно считать текущую реализацию эталоном: если она содержит ту же ошибку, сравнение с ней лишь воспроизведёт дефект.
При противоречивых или неполных требованиях правильное действие — зафиксировать вопрос и получить согласованное ожидаемое поведение до автоматизации проверки. До этого тест можно использовать как исследовательский, но его вердикт не следует считать окончательным.
В отчёте рассчитывается сумма комиссии, но требование описывает только входные параметры и не уточняет правила округления. Тестировщик получает значение, отличающееся на несколько копеек, и рассматривает варианты: сравнивать с текущей версией системы, применить распространённое правило округления или запросить уточнение у владельца продукта.
Сравнение с текущей системой быстрое, но может закрепить уже существующую ошибку. Выбор распространённого правила выглядит объективно, однако оно может не соответствовать договору или требованиям законодательства. Наиболее надёжное решение — получить согласованное правило округления, явно зафиксировать его и использовать независимый расчёт как оракул.
После этого проверка выявила систематическое округление в меньшую сторону вместо требуемого правила. Дефект удалось воспроизвести и обосновать не субъективным ожиданием, а утверждённым правилом; спор о корректности результата исчез.
Нет. Отсутствие исключения подтверждает лишь то, что операция завершилась без наблюдаемого сбоя. Результат всё ещё может быть неверным по значению, неполным, небезопасным или нарушающим бизнес-правило. Такой тест проверяет ограниченное свойство — успешное выполнение в заданных условиях, но не всю корректность операции.
Нужно искать проверяемые свойства результата: диапазон, сохранение количества и состава элементов, монотонность, идемпотентность, согласованность связанных значений или соответствие независимому источнику. Такой подход называют проверкой свойств; он снижает требования к заранее известному точному ответу, но не заменяет бизнес-оракул там, где важны конкретные значения.
Две реализации могут содержать одну и ту же ошибку, особенно если используют одинаковые требования, формулы или библиотеку. Кроме того, эталонная реализация может быть слишком медленной, неполной или сама не иметь независимого подтверждения. Поэтому её полезно сочетать с инвариантами, независимым расчётом и проверкой граничных и предметных правил.