Тест-дизайн: техники проектирования тестов и подходы в тестировании ПО

Можно быть усердным тестировщиком, но при этом пропускать 90% критических дефектов? Всё дело в подходе. Хаотичное нажатие кнопок давно проигрывает интеллектуальной системе. Эта система — тест-дизайн, и он превращает поиск ошибок из рутины в искусство.

Тест-дизайн (Test Design) — это этап процесса тестирования, на котором создаются тестовые случаи (test cases) по определенным правилам и техникам. Главная цель — не просто проверить программу, а сделать это максимально эффективно, найдя как можно больше дефектов за минимальное количество тестов и времени.

Проще говоря: это искусство придумывать правильные и умные проверки, а не проверять все подряд.

Зачем нужен тест-дизайн и его задачи

Представьте, что вам нужно проверить простое поле для ввода номера телефона. Можно вводить числа, буквы, символы, оставлять поле пустым… Вариантов — тысячи! Проверять все (полный перебор) неэффективно, долго и дорого. Тест-дизайн решает эту проблему. Он помогает:

• Находить больше критичных багов, используя логику, а не случайность.
• Быстро тестировать однотипные действия.
• Экономить время и ресурсы, избегая лишних проверок.
• Понять какие нас ждут риски и особенности тестирования.
• Систематизировать работу и ничего не упустить.
• Повысить качество конечного продукта.
• Создавать тестовую документацию.

Цели и задачи тест-дизайна:

1. Анализ требований — тщательное изучение документации к продукту.

2. Оценка рисков — выявление потенциальных проблем и особенностей эксплуатации.

3. Техники тест-дизайна — выбор тестов для максимального эффекта.

4. Создание тестов — разработка минимального, но достаточного набора проверок, охватывающих ключевой функционал.

5. Классификация тестов — разделение всех сценариев на категории: приемочные, критические и расширенные.

Измеримый результат грамотного тест-дизайна — это тестовое покрытие.

Если тест-дизайн — это искусство придумывать эффективные тесты, то тестовое покрытие — это карта, показывающая, какую область вы этими тестами осветили.

Тестовое покрытие (Test Coverage)

Тестовое покрытие (Test Coverage) — это метрика, показывающая, какая часть выбранной тестовой базы была проверена тестами. В её качестве могут выступать код, требования, функции или другие элементы системы.

Простая аналогия: представьте, что вам нужно осветить карту местности фонариком. Тестовое покрытие — это доля территории, которую вы осветили. Чем выше покрытие, тем меньше «тёмных участков» — областей системы, которые не были проверены и где могут скрываться дефекты.

Что может измерять покрытие:

• Код — сколько строк, ветвей или условий кода было выполнено во время тестирования.

• Требования — какая часть требований покрыта тест-кейсами.

• Функциональные элементы — какие функции или сценарии системы были проверены.

Основная цель тестового покрытия — выявить непроверенные области и оценить достаточность набора тестов для принятия обоснованных решений о качестве продукта.

Важно понимать, что 100% покрытие не означает отсутствие дефектов. Оно лишь показывает, что все запланированные области были затронуты тестированием, но не гарантирует корректность поведения системы во всех ситуациях.

Критерии выбора методик тестового проектирования

На выбор конкретного подхода к проектированию тестов влияет ряд определяющих факторов. К ним относятся сложность и тип тестируемой системы или её отдельных компонентов, а также положения нормативно-правовых документов. Существенную роль играют условия, определённые пользовательскими или контрактными требованиями, виды и степень рисков, а также поставленные цели тестирования.

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

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

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

Подход тестирования чёрного ящика (Black-box testing)

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

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

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

Основные техники тест-дизайна чёрного ящика:

• Разбиение на классы эквивалентности (Equivalence Partitioning)

• Анализ граничных значений (Boundary Value Analysis)

• Табличное тестирование (Decision Table Testing)

• Попарное тестирование (Pairwise Testing)

• Тестирование на основе сценариев использования (Use Case Testing)

• Тестирование состояний и переходов (State Transition Testing)

• Причинно-следственное тестирование (Cause-Effect Graphing)

Разбиение на классы эквивалентности

Разбиение на классы эквивалентности (Equivalence Partitioning) — это техника тест-дизайна, при которой все возможные входные данные разделяются на валидные и невалидные классы, внутри которых значения обрабатываются системой одинаковым образом. Для проверки в этом случае достаточно выбрать по одному представителю из каждого класса.

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

Анализ граничных значений

Анализ граничных значений (Boundary Value Analysis) — это техника тест-дизайна, ориентированная на проверку значений на границах классов эквивалентности и вблизи этих границ.

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

Таблица принятия решений

Таблица принятия решений (Decision Table Testing). Это техника, используемая для тестирования бизнес-логики, которая зависит от комбинации условий. Она представляет собой таблицу, где перечислены все возможные комбинации условий и соответствующие им действия (ожидаемые результаты).

Цели:

• Систематически проверить сложную бизнес-логику со множеством условий.
• Убедиться, что ни одна комбинация условий не была упущена.
• Сделать тестовые случаи полными и непротиворечивыми.

Пример: Правило для одобрения займа: «Займ одобряется, если клиенту больше 21 года и у него стабильный доход».
Условия:

• Возраст > 21? (Да/Нет)
• Стабильный доход? (Да/Нет)

Каждая строка этой таблицы превращается в один тестовый случай.

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

Попарное тестирование (Pairwise Testing) — Это техника, которая позволяет сократить количество тестовых случаев за счет того, что каждое значение каждого проверяемого параметра хотя бы один раз сочетается с каждым значением всех других параметров.

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

Цели:

• Резко сократить количество тест-кейсов при сохранении высокой эффективности поиска дефектов.
• Протестировать системы с большим количеством параметров и их значений, где полное переборное тестирование невозможно.

Пример: Настройка веб-сайта

Задача: Протестировать отображение веб-сайта в зависимости от трех параметров.

Параметры и их значения:

1. Браузер (Browser): Chrome, Firefox, Safari

2. Операционная система (OS): Windows, macOS

3. Язык (Language): Русский, Английский

Полное переборное тестирование:
3 браузера * 2 ОС * 2 языка = 12 возможных комбинаций.

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

Итог: Без попарного тестирования: 12 тестов. С попарным тестированием: 6 тестов.

Тестирование состояний и переходов

Тестирование состояний и переходов (State Transition Testing). Это техника, используемая для систем, которые по-разному реагируют на одни и те же входные данные в зависимости от своего текущего состояния.

Поведение системы моделируется в виде конечного автомата: определяются состояния, переходы между ними, события, вызывающие переходы, и действия, выполняемые при переходе.

Цели:

• Проверить корректность переходов системы между различными состояниями.
• Выявить дефекты, связанные с неправильной реакцией на события в неверном состоянии.
• Протестировать сложное поведение, зависящее от предыстории.

Пример: Тестирование банкомата и его реакции на ввод PIN-кода.

• Состояния: «Ожидание карты», «Ожидание PIN», «Доступ разрешен», «Карта заблокирована».
• Переходы:

1. Вставка карты (из «Ожидание карты» в «Ожидание PIN»).
2. Ввод правильного PIN (из «Ожидание PIN» в «Доступ разрешен»).
3. Ввод неправильного PIN 1-2 раза (остаемся в «Ожидание PIN»).
4. Ввод неправильного PIN 3-й раз (из «Ожидание PIN» в «Карта заблокирована»).
5. Тест-кейсы строятся на основе этой диаграммы состояний, например: «Вставить карту -> ввести неверный PIN 3 раза -> проверить, что карта заблокирована».

Тестирование форм

Тестирование форм (Form Testing). Это не отдельная техника, а целый комплекс мероприятий в рамках тестирования «черного ящика», направленный на проверку веб-форм или полей ввода в приложениях. Оно объединяет в себе несколько других техник (таких как анализ граничных значений, классы эквивалентности, тестирование состояний) для всесторонней оценки функциональности, удобства использования и надежности формы.

Цели:

• Проверить корректность обработки и валидации введенных пользователем данных.
• Убедиться, что форма выполняет свое основное предназначение (например, отправляет данные, регистрирует пользователя).
• Оценить удобство использования (usability) формы для конечного пользователя.
• Проверить безопасность формы (защита от SQL-инъекций, XSS-атак).
• Обеспечить корректное отображение формы в разных браузерах и на разных устройствах (кросс-браузерное и кросс-платформенное тестирование).

Пример тестирование формы регистрации на сайте

Элементы формы:

• Поле «Имя» (обязательное)
• Поле «Email» (обязательное)
• Поле «Пароль» (обязательное)
• Поле «Подтверждение пароля» (обязательное)
• Чекбокс «Согласие с пользовательским соглашением» (обязательный)
• Кнопка «Зарегистрироваться»

План тестирования с использованием различных техник

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

На первом этапе выполняется проверка обязательных полей. Цель данной проверки заключается в том, чтобы убедиться, что форма не может быть отправлена с пустыми обязательными полями. В рамках тестирования проверяется сценарий, при котором все поля остаются незаполненными и выполняется попытка отправки формы нажатием кнопки «Зарегистрироваться». Ожидаемым результатом является отображение сообщений об ошибке для каждого обязательного поля.

Следующий этап связан с валидацией пользовательского ввода с использованием техник разбиения на классы эквивалентности и анализа граничных значений. Для поля «Имя» валидным считается ввод кириллических или латинских букв, например «Анна» или «John», тогда как ввод чисел, специальных символов, скриптов или пустого значения относится к невалидным классам. Для поля «Email» проверяется корректность формата адреса электронной почты, при этом невалидными считаются адреса без символа @, без доменной части или содержащие пробелы. Для поля «Пароль», длина которого ограничена диапазоном от 8 до 20 символов, дополнительно выполняется проверка граничных значений, включая минимальные и максимальные допустимые и недопустимые длины.

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

Далее выполняется проверка зависимостей элементов формы с использованием тестирования состояний и переходов. В данном случае анализируется зависимость активности кнопки «Зарегистрироваться» от состояния чекбокса согласия с пользовательским соглашением. Если чекбокс не отмечен, кнопка должна быть неактивной либо выдавать сообщение об ошибке при попытке отправки формы. При отмеченном чекбоксе кнопка становится доступной для выполнения действия.

Важной частью плана является проверка безопасности формы, направленная на предотвращение уязвимостей, связанных с обработкой пользовательского ввода. В ходе тестирования в поле «Имя» вводятся SQL-конструкции и XSS-скрипты, при этом ожидается, что система либо отклонит подобный ввод, либо корректно обработает его путём экранирования.

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

Таким образом, тестирование форм представляет собой комплексный подход, который последовательно охватывает функциональность, бизнес-логику, безопасность и удобство использования, объединяя несколько техник тестирования чёрного ящика в единую систему проверок.

Подход тестирования белого ящика (White-box testing)

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

В отличие от тестирования чёрного ящика, ориентированного на внешнее поведение системы, подход белого ящика позволяет анализировать корректность реализации программного обеспечения с точки зрения архитектуры и программного кода.

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

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

К основным техникам тестирования белого ящика относятся тестирование потока управления, тестирование потока данных, покрытие операторов, покрытие ветвей, покрытие условий, покрытие решений, покрытие путей, анализ циклов, тестирование базового пути и мутационное тестирование.

На практике при использовании подхода белого ящика применяются различные метрики покрытия, включая покрытие операторов, покрытие ветвей, покрытие условий, покрытие решений и условий, в том числе MC/DC, а также покрытие путей.

Подход тестирования серого ящика (Gray-box testing)

Тестирование серого ящика — это подход к тестированию, при котором тестировщик обладает частичным знанием внутренней структуры системы, включая архитектуру, алгоритмы и схемы данных, но при этом выполняет проверки через внешние интерфейсы без анализа исходного кода.

Данный подход сочетает элементы тестирования чёрного и белого ящика и позволяет проектировать более целенаправленные тесты на основе ограниченной информации о реализации системы.

Типичными сценариями применения тестирования серого ящика являются тестирование веб-приложений при наличии информации о схеме базы данных, проверка API при доступной документации по внутренней логике, интеграционное тестирование компонентов, а также тестирование безопасности с частичным знанием архитектуры системы.

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

Тестирование на основе опыта

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

Данная техника не опирается на формальные модели или строгие правила, а использует понимание уязвимых мест системы, где вероятность возникновения дефектов наиболее высока.

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

Пример: Зная, что ранее ошибки часто возникали при обработке граничных и нулевых значений, тестировщик целенаправленно проверяет ввод значения 0, пустых полей и отсутствующих параметров, выявляя дефекты, связанные с некорректной обработкой таких случаев.

Исследовательское тестирование

Исследовательское тестирование (Exploratory Testing). Подход, совмещающий проектирование тестов, их выполнение и изучение системы одновременно. Тестировщик активно управляет тестированием, принимая решения на основе результатов предыдущих тестов.

Цели: Изучить систему, обнаружить неочевидные дефекты и быстро получить обратную связь о качестве продукта, особенно при отсутствии документации.

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

Тестирование на основе чек-листов

Checklist-Based Testing (Чеклист-Бейст Тэстинг). Метод, при котором тестирование направляется списком пунктов (чек-листом), составленным на основе опыта и знаний о критически важных аспектах системы.

Цели: Обеспечить выполнение ключевых проверок, не ограничивая свободу тестировщика строгими тест-кейсами, и не упустить важные функции.

Пример: Чек-лист для тестирования формы входа: «Проверить авторизацию с верными данными», «Проверить реакцию на неверный пароль», «Проверить кнопку ‘Забыли пароль?'», «Проверить работу Caps Lock».

Итог по тест-дизайну для тестировщика

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

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

В практической работе тест-дизайн помогает находить баланс между полнотой проверок, сроками и затратами. Он превращает тестирование из формальной проверки в процесс принятия решений в условиях ограниченной информации и меняющихся требований.

Именно качественный тест-дизайн делает тестирование осознанным, предсказуемым и полезным для продукта, команды и бизнеса.