domain testing
Тестирование,  Техники тестирования

Техники тест дизайна: Доменное тестирование (Эквивалентное разбиение и анализ граничных значений)

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

Данная статья состоит из следующих частей:

Введение

Ранее в одной из статей мы уже познакомились с тем что такое тест дизайн и техники тестирования.

Список всех техник мы уже упоминали в статье Виды, уровни, методы и техники тестирования.

Доменное тестирование — это одно из самых главных оружий тестировщика. В умелых руках оно позволяет находить большое количество багов за небольшое время. А разве не это ли нам нужно?

Техника заключается в комбинации эквивалентного разбиения и анализа граничных значений. И сегодня мы познакомимся с ними поближе.

Техника эквивалентного разбиения (Equivalence partitioning)

Суть техники эквивалентного разбиения в том, чтобы:

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

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

Два теста можно назвать эквивалентными если выполняются все нижеперечисленные условия:

  • Оба теста направлены на поиск одной и той же ошибки;
  • Если один из тестов обнаруживает ошибку, другой скорее всего, тоже её обнаружит;
  • Если один из тестов не обнаруживает ошибку, другой, скорее всего, тоже её не обнаружит;
  • Тесты используют схожие наборы входных данных;
  • Для выполнения тестов мы совершаем одни и те же операции;
  • Тесты генерируют одинаковые выходные данные или приводят приложение в одно и то же состояние;
  • Все тесты приводят к срабатыванию одного и того же блока обработки ошибок;
  • Ни один из тестов не приводит к срабатыванию блока обработки ошибок.

Например, возьмём поле Username:

В котором система вводит ограничение по длине от 3 до 20 символов.

Соответственно для проверки длины поля, мы можем выделить следующие классы:

  • 0-2 символов — выдаст ошибку, что Username имеет недостаточное количество символов
  • 3-20 символов — обработается верно
  • 21-бесконечность — выдаст ошибку, что Username превышает разрешённое количество символов

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

Например, следующие значение: Za, Batman, SupperPupperMegaWarrior.

Этими значениями мы проверили все классы по длине поля. Тем самым мы существенно сократили количество тестов.

Я думаю вы уже заметили главный недостаток этой техники. А именно — отсутствие проверок поведения на границах классов. Об этом мы и поговорим дальше.

Техника анализа граничных значений (Boundary value analysis)

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

Продолжим разбирать пример с полем Username:

Для проверки длины поля мы уже выделили 3 класса: от 0 до 2, от 3 до 20, от 21 и выше.

Соответственно можно выделить следующие границы переходов:

В рамках техники анализа граничных значений мы должны сделать тесты для проверки вышеуказанных значений:

  • 2: Bo
  • 3: Bat
  • 20: BatmanAndRobinReturn
  • 21: BatmanAndRobinForever

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

Существует 2 подхода к анализу граничных значений:

  • 2 значения на границе (Two-value boundaries);
  • 3 значения на границе (Three-value boundaries).

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

  • Минимальная граница: 2, 3 символов
  • Максимальная граница 20, 21 символов

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

  • Минимальная граница: 2, 3, 4 символов
  • Максимальная граница 19, 20, 21 символов

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

Техника доменного тестирования (Domain testing\Domain analysis)

Практика показала, что в большинстве случаев использование только одной техники не даёт нужного результата.

Именно поэтому была придумана техника доменного тестирования (Анализа доменов).

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

Пример техники доменного тестирования №1.

Для проверки длины поля Username комбинацию этих техник можно представить так:

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

Но достаточно ли этого для проверки поля? Однозначно нет.

Мы должны определить какие ещё могут быть классы и какие у них граничные значения.

Представим, что мы хотим отправить значение поля Username для создания нового пользователя.

Ниже я выделил ещё несколько типов классов по различным характеристикам и определил в них классы эквивалентности.

Таблица классов эквивалентности с показательными значениями.

Итого получилось 19 показательных значений, то есть 19 тестов.

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

Что если я скажу, что многие позитивные проверки можно объединить?

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

Например, мы можем сделать так:

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

Наши 19 тестов превратились в 11. Разве не круто?

Мы объединили значения из нескольких позитивных классов и если, например, в значении BatМэн2!@#$%^&*()-_= хотя бы одно из условий выполняться не будет (например ввод спецсимволов), то упадёт весь тест и мы быстро найдём ошибку.

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

  1. Поделить упавшее значение на 2
  2. Если оба значения не проходят, то каждое нужно ещё раз поделить на 2
  3. Если в одном значении ошибка пропала, то оставшиеся делим на 4

Тем самым мы быстро определим, а что именно вызвало ошибку в нашем тесте.

Очевидно, что не все позитивные тесты мы можем объединить друг другом. Например, мы не можем одновременно использовать и минимальное и максимальное значение вместе.

Однако, негативные тесты ни в коем случае нельзя объединять друг с другом!

Представим, что мы проверяем вместе значение меньше минимального с добавлением пробела в начале » Bo». Мы предполагаем, что оба эти условия должны вызывать ошибку.

По итогу, если одно из условий по факту вызывает ошибку, а второе нет, то на экране мы увидим ошибку. И ложно подумаем, что тест был пройден успешно. А во втором условии у нас будет баг, который мы не обнаружим.

Именно поэтому негативные тесты нельзя объединять друг с другом.

Важно помнить!

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

Пример техники доменного тестирования №2.

Представим форму отправки суммы для подсчёта процента налога.

Которая работает по следующим правилам:

  1. Если сумма меньше 1000, то процент 0;
  2. Если сумма от 1000 до 2000, то процент 10;
  3. В случае, если сумма больше 2000, то процент 15;
  4. Форма принимает только целочисленные значения;
  5. Длина поля от 1 до 7 символов.

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

Таблица классов эквивалентности с показательными значениями.

Несколько замечаний по этой таблице:

Чем меньше позитивных тестов, тем меньше мы сможем сократить количество тестов. В данном случае мы сможем объединить только 2 теста: минимальное число символов и минимальное значение, то есть 0.

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

Пример техники доменного тестирования №3.

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

Которая работает по следующим правилам:

  • Размер файла: от 128кб до 10240кб
  • Имя файла: от 6 до 128 символов, любой регистр, цифры, буквы, любые языки, разрешённые Windows спецсимволы, пробелы только в середине и конце.
  • Форматы файлов: только изображения

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

Таблица классов эквивалентности с показательными значениями.

Несколько замечаний по этой таблице:

Наличие пробелов — имя файла не может начинаться с пробела, поэтому проверка не применялась.

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

Попробуем теперь сократить количество тестов:

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

По итогу мы получили всего 18 тестов вместо 32.

Вот как-то так 🙂