Открыть сервис

Техники тест-дизайна в обеспечении качества ПО

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

Назначение и место в процессе тестирования

Проектирование тестов — этап, следующий за анализом требований и предшествующий выполнению проверок. Его цель — ответить на вопросы: что именно проверять, какие значения подавать на вход, какие условия комбинировать и когда прекратить тестирование. Без применения техник тест-дизайна количество возможных проверок растёт комбинаторно: даже для формы из нескольких полей число вариантов ввода может достигать миллионов. Техники позволяют сократить этот набор, сохраняя покрытие наиболее вероятных и наиболее опасных сценариев.

Различают две большие группы методов: «чёрный ящик» (анализ поведения системы без знания её внутреннего устройства) и «белый ящик» (анализ внутренней структуры кода). Отдельно выделяют методы, основанные на опыте тестировщика.

Классические техники «чёрного ящика»

Классы эквивалентности

Метод предполагает разбиение области допустимых значений на классы, внутри которых поведение системы считается одинаковым. Из каждого класса выбирается по одному представителю. Например, для поля, принимающего возраст от 18 до 65 лет, выделяют классы: «меньше 18», «от 18 до 65», «больше 65». Проверка одного значения из каждого класса даёт то же покрытие, что и проверка всех значений, но требует в разы меньше тестов.

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

Развитие метода классов эквивалентности. Ошибки чаще всего возникают на границах диапазонов, поэтому проверяются значения на самих границах и рядом с ними: 17, 18, 19 и 64, 65, 66. Техника граничных значений считается одной из наиболее эффективных по соотношению затрат и находимых дефектов.

Таблицы решений

Применяются, когда результат зависит от комбинации нескольких условий. Условия и действия сводятся в таблицу, где столбцы соответствуют правилам, а строки — условиям и ожидаемым действиям. Метод удобен для проверки бизнес-логики: расчёта скидок, начисления бонусов, определения статуса заказа.

Попарное тестирование

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

Диаграммы состояний и переходов

Используются для систем с явным набором состояний: заказ, платёж, заявка, учётная запись. Модель описывает состояния, события и переходы между ними. Тесты строятся на покрытии всех состояний, всех переходов и типовых маршрутов, включая недопустимые переходы.

Предугадывание ошибок

Метод, при котором тестировщик на основе опыта и знания типовых дефектов предполагает, где именно система может дать сбой, и составляет проверки, исходя из этого предположения. Формальных правил не имеет и часто дополняет структурированные техники.

Техники «белого ящика»

Методы «белого ящика» опираются на исходный код и управляющие конструкции.

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

Эти метрики используются и для оценки полноты уже написанных тестов, в том числе при автоматизированном прогоне.

Методы на основе опыта

К этой группе относят предугадывание ошибок, а также исследовательское тестирование, при котором сценарии не фиксируются заранее, а формируются по ходу изучения системы. Широко применяется в гибких методологиях, где требования уточняются итеративно.

Сравнение и совместное применение

ТехникаТипОсновное назначение
Классы эквивалентностиЧёрный ящикСокращение входных данных
Граничные значенияЧёрный ящикПоиск дефектов на границах
Таблицы решенийЧёрный ящикКомбинации условий и бизнес-логика
Попарное тестированиеЧёрный ящикКомбинаторика параметров
Диаграммы состоянийЧёрный ящикСистемы с состояниями
Покрытие ветвейБелый ящикПолнота проверки кода

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

Значение и ограничения

Применение техник тест-дизайна снижает стоимость тестирования за счёт уменьшения числа избыточных проверок и одновременно повышает вероятность обнаружения дефектов в критичных местах. В российской практике техники тест-дизайна входят в программы подготовки специалистов по тестированию и в стандарты внутреннего документирования QA-процессов в ИТ-компаниях.

Ограничения связаны с тем, что ни одна техника не гарантирует полного отсутствия дефектов. Формальные методы плохо работают там, где требования неполны или противоречивы, а также в системах с высокой степенью неопределённости входных данных. Поэтому техники тест-дизайна рассматриваются как инструмент систематизации, а не как замена экспертной оценке и исследовательскому тестированию.

Источники: стандарт ISO/IEC/IEEE 29119 (тестирование программного обеспечения); работы Б. Бейзера по тестированию ПО; материалы по методам комбинаторного тестирования; публикации по обеспечению качества в ИТ-отрасли.