Доменный анализ в тестировании

Доменное тестирование (domain testing) – вид тестирования, направленный на анализ показательных значений и взаимосвязи элементов. Доменный анализ в тестировании также известен как:

• «тестирование разделением» (partitioning testing);
• «анализ эквивалентности» (equivalence analysis);
• «анализ граничных значений» (boundary analysis).

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

Класс эквивалентности (equivalence class) – набор тестов, полное выполнение которого является избыточным и не приводит к обнаружению новых дефектов. Другими словами, если мы ожидаем одинакового результата от выполнения двух и более тестов, эти тесты эквивалентны. Такие множества тестов называются классами эквивалентности.

Доменное тестирование (domain testing, domain analysis) — техника создания эффективных и результативных тест кейсов в случае, когда несколько переменных могут или должны быть протестированы одновременно. – Определение доменного тестирования из «Тестирование программного обеспечения. Базовый курс» / С. С. Куликов. — Минск, 2017.

Доменное тестирование: признаки эквивалентности

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

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

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

Domain testing: подход к достижению цели

Если очертить подход к достижению цели доменного тестирования, то можно выделить следующие шаги:

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

Сформировать конечный набор «наиболее показательных» значений и провести тесты с их использованием

Плюсы и минусы доменного тестирования

Нужно признать, что Доменное тестирование имеет как достоинства так и недостатки, поэтому давайте их перечислим.

Плюсы:

• Обнаружение ошибок при минимальном количестве тестов.
• Интуитивно понятный, универсальный подход.

Минусы:

• Низкая вероятность обнаружения ошибок НЕ на граничных условиях.
• Низкая вероятность обнаружения ошибок в сложных взаимодействиях.
• Пространство значений часто бывает сложно формализовать.

Доменное тестирование: эквивалентность и анализ граничных значений

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

Следующее поле пароля может содержать не менее 6 и не более 10 символов. Это означает, что результаты для значений в разделах 0-5, 6-10, 11-14 должны быть эквивалентны.

Тестовый сценарий №	Описание сценария теста	Ожидаемый результат
1	Введите от 0 до 5 символов в поле пароля	Система не должна принимать
2	Введите от 6 до 10 символов в поле пароля	Система должна принять
3	Введите от 11 до 14 символов в поле пароля	Система не должна принимать

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

Такое разделение и есть классами эквивалентности. Затем мы выбираем только одно значение из каждого раздела для тестирования. Гипотеза, лежащая в основе этого метода, заключается в том, что если одно условие / значение в разделе проходит, все остальные также будут проходить. Аналогичным образом, если одно условие в разделе не выполняется, все остальные условия в этом разделе не будут выполнены.

Анализ граничных значений — вы проверяете границы между разделами эквивалентности. В нашем примере вместо проверки одного значения для каждого раздела вы будете проверять значения в таких разделах, как 0, 5, 6, 10, 11. Как вы можете заметить, вы проверяете значения как на допустимых, так и на недопустимых границах.

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

Доменное тестирование: полезные трюки

И напоследок полезные трюки, которые можно применять при доменном тестировании и не только.

Делим или умножаем на два

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

Позитивное вместе, негативное отдельно

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

Используем готовые чек-листы:

• В большинстве случаев кто-то уже сталкивался с тем, с чем сейчас столкнулись мы
• Спрашиваем коллег, ищем в корпоративной библиотеке

Войти

The Domain Testing Workbook

Жаль, но не думаю, что эта книга стоит времени на перевод.
Прочтения – да. Поэтому только начало книги:

Секция 1: Что такое тестирование доменов?

Секция состоит из 2 глав:
– Введение в тестирование доменов
– резюме ключевых технических концепций

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

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

Секция 1. Часть 1: Введение в тестирование доменов

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

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

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

пример серии испытаний

Уже давно мы начали книгу Testing Computer Software (kaner, 1988) ч простого примера, иллюстрирующего эту технику. начнем работу с этого примера и сейчас:
Вам дали программу с таким описанием:
Программа создана для сложения двух чисел, которые вы введете. каждое число должно состоять из одной или двух цифр. программа отображает то, что вы ввели и сумму. Нажмите после каждого числа. Для запуска программы наберите ADDER.

В книге описан такой пример:
– Начните с простых тестов, раскрывающих, как программа работает с разными переменными:

2 + 3 Программа вообще работает?
99 + 99 99 действительно верхняя граница?
-9 + -99 Допустимы ли отрицательные значения?

– Дошли до проверки простых, очевидных рисков:

0+0 Программа работает с нулями?
-99 + -99 Обрабатывает ли программа двузначные числа из трех символов?
100 + 100 Как будут обработаны трехзначные числа за границей?
-100 + -100
+
Что будет, если ничего не ввести?
123456 + 0 Как много цифр она воспримет?

– Проверьте входной фильтр, гарантирующий, что программа принимает только легитимные числа. Примеры:
1.2 + 5 Разделитель точка? Если она отклонит это, как насчет 1.0 или 1.?
A + b Буквы?
/ + 1
или
1+ : ASCII соды цифр начинаются от 48(0) до 57(0). ASCII 47 это / а ASCII 58 это :

1 Попробуйте ввести произвольное количество пробелов в начале и в конце.

– Рассмотрите обработку пользовательских действий во время ввода чисел, такую как:
– Время ожидания между цифрами. Это таймаут?
– Повторное редактирование чисел после перед вводом. У вас есть возможность переполнить строку ввода, если программа хранит все, что вы вводите до нажатия (Сейчас мы должны называть эту входную строку, как буфер ввода и считаем этот тест слишком простым для переполнения буфера).
– Рассмотрите возможные значения результатирующей переменной:
– Если программа держит входные значения в виде byte, то их размерность может быть от -128 до + 12. Тесты, сумма в которых выходит за эти границы, может вызвать переполнение.

Следующий пример ставит несколько точек, с которыми, вы, вероятно, знакомы:
– Когда тестируется часть программы, которая хранит и обрабатывает данные, вы должны учитывать:
– Пользовательский интерфейс: По, которое поддерживает получение и ввод данных от пользователя и отображает результаты.
– Хранилище: как программа хранит данные?
– Вычисление и результатирующие переменные: Вычисления, которые производятся с данными и переменные, которые хранят результат вычислений.
– последствия: Как данные будут использованы и как это использование повлияет на них.

Большинство (а может и все) спецификации (или требования или пользовательские истории) двусмысленны и неполны. Для получения большего количества информации вы, вероятно, должны понять это и прибегнуть к стратегиям активного изучения:
– Задавать вопросы.
– Читать внешние материалы.
– Проводить тесты, выходящие за рамки спецификаций

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

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

Что такое «качественный программный продукт»? Это продукт, который выполняет поставленные перед ним задачи и удовлетворяет ожидания пользователей. Для достижения этого результата любая программа сначала проходит тестирование и только потом попадает в руки конечного потребителя. Так как сроки тестирования (как и любого процесса) имеют тенденцию стремиться к бесконечности, нам необходимо грамотное выстраивание процесса. И тут уже никак не обойтись без тест-дизайна.

Тест-дизайнер — что это за зверь и с чем его едят?

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

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

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

Техники тест-дизайна

Ли Копланд (Lee Copeland) выделяет следующие техники, используемые в тест-дизайне:

1. Тестирование Классами Эквивалентности (Equivalence Class Testing).
Тестовые данные разбиваются на определенные классы допустимых значений. В рамках каждого класса выполнение теста с любым значением тестовых данных приводит к эквивалентному результату. После определения классов необходимо выполнить хотя бы один тест в каждом классе.

• при возрасте от 0 до 16 лет – не нанимать;
• при возрасте от 16 до 18 лет – можно нанять только на part time;
• при возрасте от 18 до 55 лет – можно нанять на full time;
• при возрасте от 55 до 99 лет – не нанимать.

• класс эквивалентности NO: 0-16;
• класс эквивалентности PART: 17-18;
• класс эквивалентности FULL: 19-55;
• класс эквивалентности NO: 56-99.

• 10 – не нанимать;
• 17 – нанимать на неполный день;
• 40 – нанимать на полный день;
• 80 – не нанимать.

2. Тестирование Граничных Значений (Boundary Value Testing).
Эта техника основана на том факте, что одним из самых слабых мест любого программного продукта является область граничных значений. Для начала выбираются диапазоны значений – как правило, это классы эквивалентности. Затем определяются границы диапазонов. На каждую из границ создается 3 тест-кейса: первый проверяет значение границы, второй – значение ниже границы, третий – значение выше границы.

Нужно помнить, что «выше» и «ниже» – понятия относительные. Например, если мы говорим о границе 6$, то значение «ниже» будет 5$, а значение «выше» – 7$. Если речь идет о границе 6.00$, то значение «ниже» будет 5.99$, а значение «выше» – 6.01$. Не исключено, что значение «ниже» или «выше» границы может быть другим классом эквивалентности, уже охваченным нами. В этом случае нет смысла создавать дубликаты тест-кейсов.

• при возрасте от 0 до 16 лет – не нанимать;
• при возрасте от 16 до 18 лет – можно нанять только на part time;
• при возрасте от 18 до 55 лет – можно нанять на full time;
• при возрасте от 55 до 99 лет – не нанимать.

Представим, что соответствующий код выглядит так:

If (applicantAge >= 0 && applicantAge = 16 && applicantAge = 18 && applicantAge = 55 && applicantAge

• при возрасте от 0 до 15 лет – не нанимать;
• при возрасте от 16 до 17 лет – можно нанять только на part time;
• при возрасте от 18 до 54 лет – можно нанять на full time;
• при возрасте от 55 до 99 лет – не нанимать.

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

If (applicantAge >= 0 && applicantAge = 16 && applicantAge = 18 && applicantAge = 55 && applicantAge

Таким образом, набор значений, для которых будут составлены тесты, будет выглядеть так: <-1, 0, 1>, <15, 16, 17>, <17, 18, 19>, <54, 55, 56>, <98, 99, 100>.

3. Таблица Принятия Решений (Decision Table Testing).
Таблицы решений – это удобный инструмент для фиксирования требований и описания функциональности приложения. Таблицами очень удобно описывать бизнес-логику приложения, и они могут служить отличной основой для создания тест-кейсов.

По клику на картинку откроется полная версия.

По клику на картинку откроется полная версия.

• Если водитель был примерным студентом и при этом еще и женат, то ему предоставляется скидка $60.
• В случае, когда водитель женат, но студентом он был так себе, то ему предоставляется скидка $50.
• Если же он не женат, но был хорошим студентом, то ему предоставляется скидка $40.
• В случае, когда человек не женат и не был хорошим студентом, ему предоставляется скидка $30.

По клику на картинку откроется полная версия.

После этого нам следует составить хотя бы по одному тест-кейсу для каждого из предполагаемых тестов.

4. Тестирование Состояний и Переходов (State-Transition Testing).

• Состояние (state, представленное в виде круга на диаграмме) – это состояние приложения, в котором оно ожидает одно или более событий. Состояние помнит входные данные, полученные до этого, и показывает, как приложение будет реагировать на полученные события. События могут вызывать смену состояния и/или инициировать действия.
• Переход (transition, представлено в виде стрелки на диаграмме) – это преобразование одного состояния в другое, происходящее по событию.
• Событие (event, представленное ярлыком над стрелкой) – это что-то, что заставляет приложение поменять свое состояние. События могут поступать извне приложения, через интерфейс самого приложения. Само приложение также может генерировать события (например, событие «истек таймер»). Когда происходит событие, приложение может поменять (или не поменять) состояние и выполнить (или не выполнить) действие. События могут иметь параметры (например, событие «Оплата» может иметь параметры «Наличные деньги», «Чек», «Приходная карта» или «Кредитная карта»).
• Действие (action, представлено после «/» в ярлыке над переходом) инициируется сменой состояния («напечатать билет», «показать на экране» и др.). Обычно действия создают что-то, что является выходными/возвращаемыми данными системы. Действия возникают при переходах, сами по себе состояния пассивны.
• Точка входа обозначается черным кружком.
• Точка выхода показывается на диаграмме в виде мишени.

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

Каждое действие, выполненное над билетом, и соответствующее состояние (отмена бронирования пользователем, оплата билета, получение билета на руки, и т. д.) отображаются в блок-схеме. На основании полученной схемы составляется набор тестов, в котором хотя бы раз проверяются все переходы.

Некоторым исследователям представляется более удобным свести весь процесс в таблицу состояний и переходов. Конечно, таблица не так наглядна, как схема, но зато она получается более полной и систематизированной, так как определяет все возможные State-Transition варианты, а не только валидные.

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

Допустим, что мы имеем систему, которая зависит от нескольких входных параметров. Да, мы можем проверить все возможные варианты сочетания этих параметров. Но даже для случая, когда каждый из 10 параметров имеет всего два значения (Вкл/Выкл), мы получаем 2 10 = 1024 комбинаций! Используя метод парного тестирования, мы не тестируем все возможные сочетания входных параметров, а составляем тестовые наборы так, чтобы каждое значение параметра хотя бы один раз сочеталось с каждым значением остальных тестируемых параметров. Таким образом, метод существенно сокращает количество тестов, а значит, и время тестирования.

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

6. Доменный анализ (Domain Analysis Testing).
Это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования. Во многом доменное тестирование пересекается с известными нам техниками разбиения на классы эквивалентности и анализа граничных значений. Но доменное тестирование не ограничивается перечисленными техниками. Оно включает в себя как анализ зависимостей между переменными, так и поиск тех значений переменных, которые несут в себе большой риск (не только на границах).

7. Сценарий использования (Use Case Testing).
Use Case описывает сценарий взаимодействия двух и более участников (как правило – пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и шаги, которые надо для этого воспроизвести.

Что тут думать, трясти надо!

Как гласит известное определение, программирование – это размышление, а не печатание. Автор совершенно уверен, что то же самое можно сказать и о тестировании. Так для чего же нам необходимы тест-дизайнеры? Зачем тратить время на анализ и дизайн, если его можно использовать на выполнение массы дополнительных проверок?

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

Действительно: какой смысл, допустим, от полного тестового покрытия формы авторизации, если при этом не будет корректно работать механизм оплаты за товар в интернет-магазине? Ведь за то время, пока тестировщик 100 тестами проверит 100 значений, тест-дизайнер придумает, как за 10 тестов проверить 1000 значений! Таким образом, усилия, затраченные на тест-дизайн, с лихвой окупятся качеством выполнения тестирования.