Какие есть методы поиска доменных ошибок анализ комбинаторного тестирования

Книга посвящена всего лишь одному виду тестирования — тестированию доменного анализа (также его называют доменный анализ либо доменное тестирование).

Что это за вид тестирования, которому посвятили целых 488 страниц? Давайте разберемся.

Если мы с вами обратимся к глоссарию ISTQB, то определение доменного тестирования звучит следующим образом:

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

Если переформулировать проще, то определение будет следующим:

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

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

Для понимания возьмем простой пример. Скажем, что у нас есть поле Логин и Пароль. В идеале, нам необходимо каждое поле протестировать по отдельности. Однако доменное тестирование позволяет сделать так, чтобы в одном тесте мы смогли проверить оба поля одновременно и без потери в качестве тестирования.

Пример из жизни. Возьмем два действия: 1. ехать в автобусе в качестве пассажира и 2. слушать аудиокнигу. Мы можем просто ехать в автобусе без прослушивания книги, как и слушать книгу, не едучи в автобусе. Но мы можем объединить эти два действия и слушать книгу, пока едем в автобусе. При таком объединении мы без потери качества и до нужного места доберемся, и книгу послушаем.

Конечно, тут тоже есть свои ограничения и нюансы. Например, будет так шумно, что мы ничего не услышим. Но и при реальном тестировании они тоже есть. Например, при вводе логина и пароля сайт выводит “общее” предупреждение, которое гласит: “Логин или пароль введены неверно”. То есть в этом случае мы не сможем понять, что именно неверно.

Разновидности доменного тестирования: признаки эквивалентности и анализ граничных значений

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

Давайте вспомним, что они означают.

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

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

Цель доменного тестирования

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

Нет, естественно, не один, но должно остаться минимум тестов, которые будут самые эффективными.

Шаги для достижения цели:

1. Для начала нужно разделить предполагаемые значения на отдельные группы, условия — это могут быть цифры, буквы, допустимый диапазон цифр, предполагаемые граничные значения.
2. Далее необходимо выявить конкретный набор значений и выбрать из них наиболее показательные, представляющие каждую группу, включая обязательно границы. Здесь мы уже определяем значения, которые будем проверять.
3. И далее необходимо скомбинировать эти значения таким образом, чтобы отдельные параметры можно было протестировать одновременно.

Давайте разберем все на конкретном примере.

К нам на тестирование поступает задача «протестировать форму авторизации». Форма состоит из двух полей: логин и пароль. Длина логина и пароля — от 5 до 10 символов. Логин может принимать различные символы, цифры и буквы на латинице. Пароль тоже может принимать символы, цифры и латиницу.

Решение:

1. Для начала разделим все предполагаемые значения на группы:

• Кол-во значений от — ∞ до 4
• Кол-во значений от 5 до 10
• Кол-во значений 11 до + ∞
• Спец. символы
• Буквы (латиница)
• Цифры

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

• 4
• 5, 7, 10
• 11
• @, !, $
• a, b, w, l
• 2, 4

3. И далее скомбинируем эти значения в виде таблицы.

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

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

У доменного тестирования есть свои как плюсы, так и свои минусы.

К достоинствам можно отнести:

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

Недостатки:

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

Полезные хитрости

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

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

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

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

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

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

1. планированием работ (Test Management)

2. проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

3. выполнением тестирования (Test Execution)

4. анализом результатов (Test Analysis)

Основные цели тестирования

• техническая: предоставление актуальной информации о состоянии продукта на данный момент.

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

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

• Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

• Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

• Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Атрибуты дефекта

• Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

• Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

1. Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

2. Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

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

4. Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

5. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

6. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

7. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

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

9. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

10. Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

• Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Классификация по позитивности сценария

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

• Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

• Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

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

Классификация по исполнителям тестирования

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

• Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.

Классификация по уровню тестирования

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

• Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

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

• Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Классификация по исполнению кода

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

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

Классификация по хронологии выполнения

• Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

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

• Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

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

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

• Что нужно тестировать?

• Как будет проводиться тестирование?

• Когда будет проводиться тестирование?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий.

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

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

• Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.

• Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.

• иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

Введение в тестирование домена

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

Лучшие 4 стратегии доменного тестирования

Теперь давайте обсудим стратегию тестирования домена:

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

1. Выбор домена

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

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

Подобный тип входных данных разбивается на подмножества. Существует два типа разделения: разделение по эквивалентным классам и анализ граничных значений (BVA). Разделение по классам эквивалентности разбивает входные данные на эквивалентные разделы данных для определения контрольных примеров. Здесь тестовые случаи разработаны таким образом, что каждый раздел покрывается за один раз. В тестировании анализа граничных значений (BVA) тестовые случаи разрабатываются с учетом недопустимого диапазона граничных значений.

3. Входные данные классов для тестирования

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

4. Проверка выходных данных

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

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

Давайте рассмотрим два сценария в качестве примера:

1. Тестовые данные с одним входом

Рассмотрим x & y — входную переменную для любого выражения, а переменная z — выход. Здесь выражение представляет собой один входной сценарий, который включает переменную x & y, следовательно, нет комбинированной входной переменной.

Примеры выражений: (z = x + y) или (z = xy) или (z = x * y) или (z = x / y) и т. Д.

2. Тест с несколькими входными переменными

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

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

• Сценарий 1: баллы учащихся> 80 и <= 100, при этом предмет «Наука» должен быть в классе А.
• Сценарий 2: баллы учеников> 80 и <= 100, при этом учетная запись должна быть в классе B.
• Сценарий 3: студент набирает 65 баллов, предмет по естественным наукам должен быть в классе C.
• Сценарий 4: учащийся набирает 65 баллов, предмет «Счета» должен быть в классе D.
• Сценарий 5: студент набирает 50 баллов, предмет по науке должен быть в классе Е.
• Сценарий 6: учащийся набирает 50 баллов, предмет Счета должен быть в классе F.
• Сценарий 7: баллы учащихся <= 50, предмет науки должен быть в классе G.
• Сценарий 8: баллы учащегося <= 50, предмет Счета должен быть в классе H.

Здесь, в приведенном выше примере, входными данными будут Marks & Subject, касающиеся тех классов, которые будут распределены. Этот случай относится к разделу входов или группировке входных значений. Диапазон оценочных баллов подразделяется на следующие классы:

• Класс 1: учащиеся, набравшие> 80 и <100.
• Класс 2: студенты, набравшие 65 баллов.
• Класс 3: студенты, набравшие 50 баллов.
• Класс 4: учащиеся, набравшие <= 50.

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

Для класса 1 — учащиеся, набравшие более 80 баллов (оценки> 80 и оценки <= 100).

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

• Знаки 80 не должны учитываться в этом классе, так как значения должны быть больше 80.
• В этом классе следует учитывать отметки 81, так как значения должны быть больше 80.
• В этом классе следует учитывать отметки 100, так как значения должны быть меньше 100 или равны 100.
• Знаки 101 не должны учитываться в этом классе, поскольку значения должны быть меньше 100 или равны 100.

Значения раздела эквивалентности: входные значения от 81 до 100 действительны, поэтому необходимо включить одно из значений от 81, 82, 83 до 100. Следовательно, выбранные отметки «90» являются действительными отметками для этого класса.

Проверка выходных данных

Здесь из каждого раздела выполняется только одно условие теста. Если одно условие теста работает правильно в разделе, то все остальные условия теста должны работать правильно. И, если одно условие теста в разделе работает неправильно, предполагается, что никакие другие условия не будут работать правильно.

Структура доменного тестирования

Структура тестирования домена описана ниже:

• Проанализируйте заявку относительно домена.
• Узнайте допустимые входные переменные.
• По поводу вывода найдите, проанализируйте входные переменные и отсортируйте их.
• Относительно анализа разделов BVA & Equivalence создайте / найдите входные переменные.
• Найти и проанализировать выходные переменные относительно входных переменных.
• Найти неанализированные входные переменные. Соберите информацию для дальнейшей оценки.
• Суммируйте весь анализ теста относительно таблиц риска.

Вывод

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

Рекомендуемая статья

Это руководство по тестированию домена. Здесь мы обсуждаем Введение в тестирование домена и его стратегию тестирования, а также структуру с примером. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше —

1. Уровни тестирования программного обеспечения | Топ 4
2. Топ 6 видов ручного тестирования
3. 10 лучших инструментов тестирования безопасности с открытым исходным кодом
4. Введение в жизненный цикл тестирования программного обеспечения
5. Как генерировать тестовые данные с их преимуществами?
6. Что такое тест-кейс? Как писать?

1.

Раздел 1: «Общие навыки»
Тема 2
«Функциональное и доменное тестирование»

2.

3.

Ранее мы определили
функциональное тестирование
(functional testing) как «проверку на
соответствие требованиям и
спецификациям».
Теперь мы посмотрим на этот
вопрос более пристально.

4.

Функциональное
тестирование (functional
testing) – проверка на
соответствие требованиям и
спецификациям.
Может быть ручным (manual
testing) или
автоматизированным
(automated testing).

5.

Функциональное тестирование
(functional testing) – вид
тестирования, направленный на
исследование отдельных
(изолированных) функций
приложения.
Здесь нет противоречия с
предыдущим определением. Мы
лишь конкретизировали область
применения функционального
тестирования в чистом виде.

6.

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

7.

Посмотрим на нефункциональные виды
тестирования…
Вид тестирования
«Нуждается» в ФТ
Доменное тестирование
Очень сильно
Тестирование на основе спецификаций
Очень сильно
Тестирование на основе рисков
Очень сильно
Стрессовое тестирование
Очень сильно
Исследовательское тестирование
Очень сильно
Сценарное тестирование
Очень сильно
Тестирование интернационализации
Сильно
Тестирование локализации
Сильно
И т.д.
Сильно

8. Какие бывают тесты

Основные виды тестов:
позитивные;
негативные.
Направления тестирования:
статическое;
динамическое.
Методы тестирования:
чёрный ящик;
белый ящик;
серый ящик.
Виды тестирования:
инсталляционное;
регрессионное;
нового функционала;
конфигурационное;
совместимости;
удобство использования;
интернационалиазации;
локализации;
исследовательское.

9.

Хорош для своих целей
Каждый
вид/метод…
Пропускает часть ошибок
Не может заменить собой
другие
Опытный
тестировщик…
Может использовать разные
виды/методы
Может выбирать лучший
вид/метод

10.

К чему мы готовимся?
Типичные вопросы на собеседовании:
• Назовите плюсы и минусы функционального
тестирования.
• Что такое классы эквивалентности и граничные
условия?
• Назовите и объясните типичные тесты для
следующих полей: текстовое, числовое, даты, двух
связанных дат и т.п.
• Определите переменные, представленные в
требовании или на рисунке. Определите, какие из них
являются независимыми, а какие – связанными.
Сформируйте чек-лист.

11.

Итак, о функциональном тестировании
Основная цель
тестировать каждую
функцию в
отдельности
Источники информации
для тестов
экран приложения,
каждое отдельное
поле
меню, каждый пункт
в отдельности

12.

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

13.

Задачи функционального тестирования
• Определить набор функций.
• Определить переменные и граничные
условия.
• Определить переменные окружения,
которые могут повлиять на выполнение
функции.
• Проверить каждую функцию в
А вот и доменное
«обычных условиях» (позитивное
тестирование!
тестирование) и «нестандартных
ситуациях» (негативное тестирование).

14.

15.

Доменное тестирование (domain
testing) – вид тестирования,
направленный на анализ
показательных значений и
взаимосвязи элементов.
… также известно как:
• «тестирование разделением» (partitioning testing);
• «анализ эквивалентности» (equivalence analysis);
• «анализ граничных условий» (boundary analysis).

16.

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

17.

Основная цель доменного
тестирования: предоставить
стратегию по выбору минимального
набора показательных тестов.
Должен остаться
только один…

18.

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

19.

«В конце рабочего дня клерк заносит в БД
информацию о количестве обработанных
заказов. Если количество превышает 100,
система запрашивает подтверждение «Вы
уверены?»

20.

Решение примера
1. Разделить пространство значений на
группы.
Количество заказов:
• MinInt — -1
• 0 — 100
• 101 — MaxInt
• Нецелые числа и не числа
Из условия задачи автоматически следует, что данное поле
принимает только целые числа (при условии, что фиксируется
количество полностью выполненных заказов).

21.

Решение примера
2. Выбрать значения, представляющие
каждую группу.
3. Особое внимание обратить на граничные
значения групп.
Выбранные значения:
• 0, 50, 100, 101, 500, MaxInt
• -1, -200, 1.98
• [empty], буквы, пробелы, спецсимволы

22.

Решение примера
4. Сформировать конечный набор «наиболее
показательных» значений и провести
тесты с их использованием.
Значения:
• 0, 100, 101, MaxInt
• -1, 1.7
• [empty], «абв», пробел(ы), !#@%

23.

Расширенный подход к достижению цели:
• Скомбинировать наиболее показательные
тесты, полученные в результате
«классического подхода».
• Уменьшить полученный набор, определяя
наиболее показательные комбинации.

24.

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

25.

Ключевые действия при доменном
тестировании:
• Определение классов
эквивалентности.
• Определение наиболее
показательных значений.
• Создание таблиц эквивалентности.
• Комбинирование нескольких
тестов.
• Определение
взаимозависимостей.

26.

Частые возражения: «Мы тестируем на
реальных пользовательских данных. Нам всё
это не нужно!»
• Конкретные ограничения часто являются
не более, чем предположениями.
• Баги живут годами.
• Пользовательские данные – лишь
пример, но не полный перечень.
• Осознанный подход приносит больше
пользы.
• Изучим сейчас – быстро применим, когда
понадобится.

27.

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

28.

Определение неоднозначности
(неполноты) в требованиях
Игрок вводит целое число. Компьютер
отвечает:
• «Меньше», если введено число
большее, чем загаданное.
• «Больше», если введено число
меньшее, чем загаданное.
• «Угадал», если введено число,
равное загаданному.

29.

Определение диапазонов значений
Программа позволяет использовать
любое допустимое целое число.

30.

Определение «многомерных» значений
«Измерение»
Длина
Символы
Классы эквивалентности
Примеры значений
min-max, внутри диапазона
min, max
0, min-1
0, min-1
max+1, бесконечность
max +1, очень большое число
алфавитно-цифровые
123abc
спецсимволы
[email protected]#$%^&*()_+|-={}[]:»;'<>?,./
разные языки
ÀÇÈÌÑÒÙßàçèìíñò
разные кодировки (вкл. UTF)
Пробелы
Уникальность,
Регистр
Способ заполнения
нет пробелов
a
пробелы в начале, в конце
_a, _a_, a_
пробелы в середине
a_a
разные значения
aaa / bbb
одинаковые значения
aaa / aaa
различия в регистре
aaa / aAa
набор с клавиатуры
набрать текст
вставка
вставить текст

31.

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

32.

33.

34.

35.

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

36. Простой вопрос:

• Не нашли или нашли мало ошибок.
Плохое тестирование?
Хорошее качество?
• А если это последний релиз-кандидат?
• А если это приемочный тест?

37. Простой вопрос:

• Нашли много или очень много ошибок.
Хорошее тестирование?
Плохое качество?
• Получается, что разработка – плохая?
• А если раз за разом?
• А если добавлено много нового
функционала?

38.

A*B=C
Итак, у нас есть три
переменные…

39.

[7 значений для A] *
[7 значений для B] =
49 тестов
Почему здесь именно
такие числа? И всё ли с
этими числами в
порядке?

40.

Тип данных
Байты
Биты
Min
Max
signed char
1
8
— 128
127
unsigned char
1
8
0
255
signed short
2
16
-32768
32767
enum
2
16
-32768
32767
unsigned short
2
16
0
65535
signed int
2
16
-32768
32767
unsigned int
2
16
0
65535
signed long
4
32
-2147483648
2147483647
unsigned long
4
32
0
4294967295
Здесь также многое зависит от реализации. По крайней мере, для Borland C++ 4.5,
основные характеристики целочисленных типов выглядят следующим образом
http://citforum.ru/programming/cpp_march/cpp_017.shtml
http://tinyurl.com/7utf88x

41.

Идеальный программист
1.Изучает проблемы (найденные самостоятельно
или их обнаружили тестировщики)
2.Обобщает проблемы (подброшенные идеи)
3.Исследует ПО на выявление и исправление
таких же или подобных ошибок

42.

Итак, тестов всегда много, а времени
всегда недостаточно!
Что же делать?! Что нас
может спасти???!!!
Эвристические стратегии:
• Тестирование экстремальных точек
(граничных значений / особых
значений)
• Тестирование комбинаций
(типична, популярна, плохо
управляема)
• Число тестов растет
экспоненциально с увеличением
количества входных переменных

43.

Эвристическая стратегия
Предельные значения = 26 тестов

44.

«1×1, слабая стратегия» (Бейзер)
1 тест на границе, 1 вне = 16 тестов

45.

«1x1xN, сильная стратегия» (Бейзер)
1 тест на границе, 1 вне, N между ними
= 24 теста

46.

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

47.

48.

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

49.

Решение проблемы:
Создать список переменных (не полей!)
Сделать разумные допущения о
• допустимых значениях;
• недопустимых значениях и реакции приложения;
Согласовать полученное с разработчиками.
Согласовать полученное с заказчиком.

50.

Решение проблемы, пример:
Переменная
Тип
Обяз
Уник
Мин Макс
Дополнительно
Логин
Строка Да
Да
1
100 Любые символы
UTF-32,
НЕчувствителен к
регистру
Пароль
(ввод)
Строка Да
Нет
6
50 Любые символы
UTF-32,
чувствителен к
регистру
Пароль
Строка n/a
(хранение)
Нет
40
40 40

51.

Затем создаём чек-лист:
Экран
Переменная
Идеи тестов
Да/Нет
Создание
пользоват
еля
Логин
Корректный несуществующий логин
Да
Оставить пустым
Нет
Минимальная длина -1
Нет
Максимальная длина +1
Нет
Спецсимволы — [email protected]#$%^&*()_+|={}[]:»;'<>,.?/
Да
Существующий логин
Нет
Существующий логин в другом регистре
Нет

52.

53.

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

54.

Считаем слова/символы автоматически
Если у вас под рукой нет удобного
средства анализа данных, можно
воспользоваться word’ом для подсчёта
длин.
Если хочется «всего и сразу», можно
написать программу, которая будет
выдавать вам полную информацию об
анализируемом тексте.
Какую информацию о тексте
имеет смысл собрать?
Ваши идеи!

55.

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

56.

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

57.

58.

Есть вопросы? Давайте обсудим!
При подготовке презентации
использованы материалы тренингов
Eduard Shymkus (EPAM)

Разработка тестов методом черного ящика (black box test design technique): Процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. (ISTQB)

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

Все specification-based или Black Box testing techniques могут быть удобно описаны и систематизированы с помощью следующей таблицы:

Эквивалентное разделение (Equivalence Partitioning (ISTQB/Myers 1979) / Equivalence Class Testing (Lee Copeland))

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

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

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

Правила нашей организации таковы:

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

Теперь мы готовы начать тестирование? Вероятно, нет. Что насчет таких входных данных как 969, -42, FRED или &$#! ? Должны ли мы создавать тестовые сценарии для некорректных входных данных? Для того, чтобы понять ответ, мы должны проверить подход, который пришел из объектно-ориентированного мира, названный «проектирование-по-контракту».

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

Например, если у нас есть модуль «openFile», что он обещает сделать? Открыть файл. Какие будут разумные предусловия для этого модуля?

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

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

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

Нужно ли нам делать проверку с такими входными значениями, как -42, FRED и &$#! @? Если мы используем проектирование-по-контракту и тестирование-по-контракту, то ответ «Нет». Если мы используем оборонительное проектирование и, поэтому, оборонительное тестирование, то ответ «Да». Спросите ваших проектировщиков, какой подход они используют. Если их ответом будет «контрактный» либо «оборонительный», то вы знаете, какой стиль тестирования использовать. Если они ответят «Хм?», то это значит, что они не думают о том, как взаимодействуют модули. Они не думают о предусловиях и постусловиях контрактов. Вам стоит ожидать, что интеграционное тестирование будет главным источником дефектов, будет более сложным и потребует больше времени, чем ожидалось.

Несмотря на то, что тестирование классов эквивалентности полезно, его величайшим вкладом является то, что оно приводит нас к тестированию граничных значений.

Анализ граничных значений (BVA — Boundary Value Analysis (Myers 1979)/range checking)

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

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

Обратите внимание на проблемы на границах — это «края» каждого класса. Возраст «16» входит в два различных класса эквивалентности (как и «18», и «55»). Первое правило гласит не нанимать шестнадцатилетних. Второе правило гласит, что шестнадцатилетние могут быть наняты на неполный рабочий день Тестирование граничных значений фокусируется на границах именно потому, что там спрятано очень много дефектов. Опытные тестировщики сталкивались с этой ситуацией много раз. У неопытных тестировщиков может появиться интуитивное ощущение, что ошибки будут возникать чаще всего на границах. Эти дефекты могут быть в требованиях, или в коде, если программист ошибется с указанием границ в коде (включительно/не включительно, индекс +-1).

Попробуем исправить приведенный выше пример:

А что насчет возраста -3 и 101? Обратите внимание, что требования не указывают, как должны быть рассмотрены эти значения. Мы можем догадаться, но «угадывание требований» не является приемлемой практикой. Следующий код реализует исправленные правила:

В этом примере интересными значениями на границах или вблизи них являются {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56} и {98, 99, 100}. Другие значения, например {-42, 1001, FRED, %$#@} могут быть включены в зависимости от предусловий документации модуля.

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

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

Тестирование таблиц решений (Decision Table testing)

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

Пример. Компания по автострахованию дает скидку водителям, которые состоят в браке и/или хорошо учатся.

эта таблица содержит все комбинации условий. Задав два бинарных условия («да» или «нет»), возможные комбинации будут: («да», «да»), («да», «нет»), («нет», «да») и («нет», «нет»). Каждое правило представляет собой одну из этих комбинаций. Нам, тестировщикам, нужно будет проверить, что определяются все комбинации условий. Пропущенное сочетание может привести к разработке такой системы, которая не сможет правильно обработать определенный набор исходных данных. Каждое правило является причиной «запуска» действия. Каждое правило может задать действие, уникальное для этого правила, или правила могут иметь общие действия. Для каждого правила с помощью таблицы решений можно указать более одного действия. Опять же, эти правила могут быть уникальными или быть общими. В такой ситуации выбрать тесты просто — каждое правило (вертикальная колонка) становится тест-кейсом. Условия указывают на входные значения, а действия — на ожидаемые результаты.

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

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

Комбинаторные техники тест-дизайна (Combination Strategies)

Комбинаторное тестирование (combinatorial testing): Метод, позволяющий выделить подходящую подгруппу тестовых комбинаций с целью добиться предопределенного уровня покрытия при тестировании объекта с множественными параметрами в случаях, когда эти параметры сами по себе состоят из нескольких значений, что приводит к появлению большего числа комбинаций, чем можно успеть протестировать за отведенное время. См. также метод дерева классификации, попарное тестирование, n-мерное (переборное) тестирование, тестирование с использованием ортогонального массива. (ISTQB)

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

Все комбинации (All combinations): как видно из названия, этот алгоритм подразумевает генерацию всех возможных комбинаций. Это означает исчерпывающее тестирование и имеет смысл только при разумном количестве комбинаций. Например, 3 переменные с 3 значениями для каждой дают нам матрицу параметров 3х3 с 27 возможными комбинациями.

Тестирование каждого выбора (EC — Each choice testing): эта стратегия требует, чтобы каждое значение каждого параметра было включено по крайней мере в один тестовый пример (Ammann & Offutt, 1994). Это также определение 1-wise coverage.

Тестирование базового выбора (BC — Base choice testing): алгоритм стратегии комбинирования базового выбора начинается с определения одного базового тестового примера. Базовый тестовый пример может быть определен по любому критерию, включая простейший, наименьший или первый. Критерий, предложенный Амманном и Оффуттом (Ammann & Offutt, 1994), — это «наиболее вероятное значение» с точки зрения конечного пользователя. Это значение может быть определено тестировщиком или основано на рабочем профиле, если таковой существует. Из базового тестового примера создаются новые тестовые примеры, изменяя интересующие значения одного параметра за раз, сохраняя значения других параметров фиксированными в базовом тестовом примере. Базовый выбор включает каждое значение каждого параметра по крайней мере в одном тестовом примере, поэтому он удовлетворяет 1-wise coverage.

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

Pairwise testing — техника тест-дизайна, а именно метод обнаружения дефектов с использованием комбинационного метода из двух тестовых случаев. Он основан на наблюдениях о том, что большинство дефектов вызвано взаимодействием не более двух факторов (дефекты, которые возникают при взаимодействии трех и более факторов, как правило менее критичны). Следовательно, выбирается пара двух тестовых параметров, и все возможные пары этих двух параметров отправляются в качестве входных параметров для тестирования. Pairwise testing сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Захватывающей надеждой попарного тестирования является то, что путем создания и запуска 1-20% тестов вы найдете 70-85% от общего объема дефектов.

Пример: По ТЗ сайт должен работать в 8 браузерах, используя различные плагины, запускаться на различных клиентских операционных системах, получать страницы от разных веб-серверов, работать с различными серверными, операционными системами. Итого:

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

Использование всех пар для создания тест-кейсов основывается на двух техниках:

Подробнее с разбором примера см. у Копленда в главе 6.

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

Classification tree method

Метод дерева классификации (classification tree method): Разработка тестов методом черного ящика, в которой тестовые сценарии, описанные средствами дерева классификации, разрабатываются для проверки комбинаций выборок входных и/или выходных подмножеств. (Grochtmann) См. также комбинаторное тестирование.

Метод дерева классификации: вид комбинаторной техники, в которой тестовые примеры, описанные с помощью дерева классификации, предназначены для выполнения комбинаций представителей входных и / или выходных доменов.

Чтобы рассчитать количество тестовых примеров, нам необходимо проанализировать требования, определить соответствующие тестовые функции (классификации) и их соответствующие значения (классы).

Обычно для создания Classification tree используется инструмент Classification Tree Editor. Если же взять лист бумаги и ручку, то у нас есть тестовый объект (целое приложение, определенная функция, абстрактная идея и т. д.) вверху как корень. Мы рисуем ответвления от корня как классификации (проверяем соответствующие аспекты, которые мы определили). Затем, используя классы эквивалентности и анализ граничных значений, мы определяем наши листья как классы из диапазона всех возможных значений для конкретной классификации. И если некоторые из классов могут быть классифицированы далее, мы рисуем под-ветку / классификацию с собственными листьями / классами. Когда наше дерево завершено, мы делаем проекции листьев на горизонтальной линии (Test case), используя одну из комбинаторных стратегий (all combinations, each choice и т. д.), и создаем все необходимые комбинации.

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

Тестирование переходов между состояниями (State Transition testing)

Таблица состояний (state table): Таблица, показывающая конечные переходы для каждого состояния вследствие каждого возможного события, как для корректных, так и для некорректных переходов. (ISTQB)

Тестирование переходов между состояниями определяется как метод тестирования ПО, при котором изменения входных условий вызывают изменения состояния в тестируемом приложении (AUT). В этом методе тестировщик предоставляет как положительные, так и негативные входные значения теста и записывает поведение системы. Это модель, на которой основаны система и тесты. Любая система, в которой вы получаете разные выходные данные для одного и того же ввода, в зависимости от того, что произошло раньше, является системой конечных состояний. Техника тестирования переходов между состояниями полезна, когда вам нужно протестировать различные системные переходы. Этот подход лучше всего подходит там, где есть возможность рассматривать всю систему как конечный автомат. Для наглядности возьмем классический пример покупки авиабилетов:

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

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

На основании полученной схемы составляется набор тестов.

Определим четыре разных уровня покрытия:

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

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

Подробнее с разбором примера см. у Копленда в главе 7.

Анализ доменов (domain analysis): Методика разработки тестов, относящаяся к методу черного ящика, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно. Методика базируется и обобщает методы эквивалентного разбиения и анализа граничных значений/ (ISTQB)

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

Domain-тестирование​ — это техника, которая может применяться для определения эффективных и действенных тест-кейсов, когда несколько переменных (например, поля ввода) должны проверяться вместе — либо для эффективности, либо по причине их логического взаимодействия. Она использует и обобщает тестирование классов эквивалентности и граничных значений в n одномерных измерениях. Подобно этим техникам, мы ищем случаи, где граница была неверно определена или реализована. Несмотря на то, что эта техника лучше всего подходит для числовых значений, она может быть обобщена и на другие типы — boolean, string, enumeration и т.д.

В двухмерном измерении (с двумя взаимодействующими параметрами) могут возникнуть следующие дефекты:

Подробнее с разбором примера см. у Копленда в главе 8.

Сценарий использования системы (use case): Последовательность операций во взаимодействии актера и компонента или системы со значимым результатом, при которой актером может быть как пользователь, так и все, что может обмениваться информацией с системой. (ISTQB)

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

Вариант использования (Use Case) — это сценарий, который описывает использование системы действующим лицом для достижения определенной цели (Ивар Якобсон — «Объектно-ориентированная разработка программ: подход, основанный на вариантах использования»).

Прежде чем использовать сценарии для создания Test case, их необходимо подробно описать с помощью шаблона. Шаблоны могут варьироваться от проекта к проекту. Но среди таких обычных полей, как имя, цель, предварительные условия, актер (ы) и т. д., всегда есть основной успешный сценарий и так называемые расширения (плюс иногда подвариации). Расширения — это условия, которые влияют на основной сценарий успеха. А подвариации — это условия, которые не влияют на основной flow, но все же должны быть рассмотрены. После того, как шаблон заполнен данными, мы создаем конкретные Test case, используя методы эквивалентного разделения и граничных значений. Для минимального охвата нам нужен как минимум один тестовый сценарий для основного сценария успеха и как минимум один Test case для каждого расширения. Опять же, этот метод соответствует общей формуле «получите условия, которые меняют наш результат, и проверьте комбинации». Но способ получить это — проанализировать поведение Системы с помощью сценариев.

Польза вариантов использования в том, что они:

Подробнее с разбором примера см. у Копленда в главе 8.

Как создать хорошие сценарии (Сэм Канер):

Cause/Effect, Cause-Effect (CE)

Таблица причинно-следственных решений (cause-effect decision table): См. таблица решений.

Таблица решений (decision table): Таблица, отражающая комбинации входных данных и/или причин с соответствующими выходными данными и/или действиям (следствиям), которая может быть использована для проектирования тестовых сценариев. (ISTQB)

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

Граф причинно-следственных связей (Cause-Effect Graph) использует такую ​​модель логических взаимосвязей между причинами и следствиями для компонента. Каждая причина выражается как условие, которое может быть истинным, ложным на входе или комбинацией входных данных компонента. Каждый эффект выражается в виде логического выражения, представляющего результаты или комбинацию результатов для произошедшего компонента (?Every effect is expressed as a Boolean expression representing results, or a combination of results, for the component having occurred). Модель обычно представлена ​​как логический граф, связывающий производные логические выражения ввода и вывода с использованием логических операторов:

Cause-Effect Graph также известен как диаграмма Исикавы, поскольку он был изобретен Каору Исикава, или как диаграмма рыбьей кости из-за того, как он выглядит.

Граф причинно-следственных связей похож на Decision Table и также использует идею объединения условий. И иногда они описываются как один метод. Но если между условиями существует много логических зависимостей, может быть проще их визуализировать на cause-effect graph.

Синтаксическое тестирование (syntax testing): Разработка тестов методом черного ящика, в которой тестовые сценарии строятся на основе области определения входящих и/или выходных значений. (ISTQB)

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

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

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

User Journey test, как следует из названия, охватывает полное путешествие пользователя по системе. Он охватывает сквозные тесты, из-за которых процент покрытия тестами больше по сравнению с другими методами. Этот метод помогает уменьшить количество тестовых примеров, поскольку тестовые примеры являются исчерпывающими и охватывают большую часть функциональности в одном сценарии. Сценарии написаны для самого сложного путешествия. Тесты взаимодействия с пользователем не связаны с пользовательскими историями (user stories).

User Story Testing (Agile)

Пользовательская история — это краткое и простое описание требований клиентов или конечного пользователя. Пользовательские истории написаны владельцем продукта (Product owner), поскольку именно он получает от клиента информацию о продукте, который будет создан. Если пользовательская история большая, она разбивается на несколько более мелких историй. Истории пользователей записываются на учетных карточках и вывешиваются на стене для обсуждения. Обсуждая важные аспекты функции, выберите те, которые в дальнейшем используются в пользовательской истории. Приемочные испытания — это заключительный этап, на котором продукт принимает заказчик после того, как он соответствует всем критериям выхода. Критерии приемлемости определяются владельцем продукта, заказчик на поставку также может привлекать разработчиков, определяя то же самое.

Исчерпывающее тестирование (exhaustive testing): Методика тестирования, в которой набор тестов включает в себя все комбинации входных данных и предусловий. (ISTQB)

Исчерпывающее тестирование (Exhaustive testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода почти всегда не представляется возможным, из-за огромного количества входных значений.

Уровень сложности
Простой

Время на прочтение
11 мин

Количество просмотров 3.2K

Статья написана в рамках моего личного блога о тестировании и QA: https://t.me/qanva_blog

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

Определение доменного анализа

У данной техники тест‑дизайна много названий: «доменный анализ», «анализ классов эквивалентности», «доменное тестирование», «анализ эквивалентного разбиения», «тестирование областей определения», «domain analysis».

Это, чтобы вы не растерялись на собесе =)

Прежде, чем штудировать источники информации, давайте посмотрим, что можно вытащить из различных определений понятия «Доменный анализ»:

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

Доменный анализ — техника, которая основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или, иначе, домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования. — из статьи Антона Алексеева «Кто такие тест‑дизайнеры и зачем они нужны»

Доменный анализ — это техника, которая может применяться для определения эффективных и действенных тест‑кейсов, когда несколько переменных могут или должны тестироваться вместе — Ли Копланд «A Practitioner’s Guide to Software Test Design«

Доменный анализ — техника создания эффективных и результативных тест‑кейсов в случае, когда несколько переменных могут или должны быть протестированы одновременно. — Святослав Куликов «Тестирование программного обеспечения»

Для себя я вынес следующее:

• данная техника позволяет сократить кол‑во тестов, не теряя при этом в эффективности тестового покрытия;

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

• чтобы объединить множество значений, необходимо выделить определенную область, называемую доменом;

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

Сформулировать свое полное определение попытаемся в конце =)

Что такое “домен”?

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

Для примера возьмем сайт создания блокнота по описанию пользователя. На нем есть такая форма:

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

То есть «домен» — это логически связанные между собой шаги/переменные/объекты, в рамках одного функционала: форма авторизации, форма регистрации, оформление заказа в интернет магазине, заполнение данных о пользователе, конвертирование различных форматов файла на разных ОС, окно редактирования изображения, отдельная зона игровой локации, инвентарь персонажа, окно крафта конкретной вещи из инвентаря персонажа и т. д.

Хочу заметить, так понятие «домен» понимаю лично я. И в данной статье буду опираться на него.

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

Мне кажется что «домен» это про объединение параметров общей логикой и про множественность параметров, а не про отдельные параметры.

Моя логика следующая: логически объединяем набор параметров ( домен ) > каждый параметр( поддомен) разбиваем на классы эквивалентности > выбираем представителей из каждого класса эквивалентности:

Алгоритм использования техники

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

1. Выбор домена.

2. Анализ входных параметров (поддомены).

3. Разбиение входных параметров на классы эквивалентности.

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

5. Анализ взаимосвязанных параметров и объединение их с помощью комбинаторики/попарного тестирования.

6. Создание тестов на основе полученных данных о входных значениях.

7. Анализ выходных параметров.

8. Разбиение выходных параметров на классы эквивалентности.

9. Выбор представителей классов эквивалентности и граничных значений для выходных параметров.

10. Определение входных параметров для проверки представителей выходных значений.

11. Дополнение тестов на основе полученных данных о выходных значениях.

12. Объединение тестов.

Анализ входных параметров

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

Выделяем входные параметры:

Поле ФИО:

• Количество символов <= 25 и >=3 (если введены данные)

• Необязательно к заполнению, если заполнено поле Описание

• Принимает на вход латинские буквы и буквы кириллицы

• Не принимает на вход символы и числа, кроме пробела “_”

• Пробел нельзя ставить в начале строки и в конце строки

Поле Описание:

• Количество символов <=120, если формат = А5

• Количество символов <=200, если формат = А4

• Количество символов >=3 (если введены данные)

• Необязательно к заполнению

• Принимает на вход латинские буквы и буквы кириллицы

• Не принимает на вход символы, кроме пробела “_”, запятой “,”, восклицательного знака “!”, точки “.”, дефиса “-” 

• Принимает на вход числа, если они стоят не в начале и не в конце строки

Поле Количество страниц:

• Значение количества страниц >=250 и  <=1000 

• Значение должно быть целым числом

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

• Если формат выбран А4 , то значение <=500

• Количество символов для ввода >=3 и <=4

Загрузить изображение:

• Доступные форматы файла .png , .jpeg

• Размер файла от 500КБ до 5МБ

• Минимальный размер изображения >= 250x250px

• Если формат А5, то размер изображения <=650x650px

• Если формат А4, то размер изображения <=1200х1200px

• Имя файла не должно содержать символы и буквы кириллицы

• Длина имени файла <=15 и >=3 символов

• Имя файла содержит латинские буквы и цифры

• Необязательное поле

Применение уже знакомых техник тест дизайна

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

Эту задачу как раз прекрасно решает техника разбиения на классы эквивалентности.

• Если диапазон значений упорядочен, то выделяем внутренние интервалы и точки перехода: слева от диапазона и справа от диапазона — невалидные значения, сам диапазон — валидные значения.

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

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

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

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

• Временные границы: ограничение на выбор даты в прошлом, ограничение на выбор даты в будущем, таймеры и т.д.

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

• Границы итераций: ограничение на ввод пароля, ограничение на повторное использование части функционала и т.д.

• Границы окружения: ограничение на использование символов в именах файлов на разных ОС.

• и т.д.

Также важно выделение особых точек:

• значения на которые программа не реагирует;

• наиболее часто встречающиеся;

• специфичные значения, которые определяются предметной областью;

• 0 и null;

• дефолтные значения / значения по умолчанию.

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

Проанализировав входные параметры, мы получили следующие данные:

1. Значения входных данных для поля ФИО — ссылка на таблицу

2. Значения входных данных для поля Описание — ссылка на таблицу

3. Значения входных данных для поля Количество страниц — ссылка на таблицу

4. Значения входных данных для поля Загрузка изображения — ссылка на таблицу

Объединение тестов

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

• Описание поддомена для поля ФИО — ссылка на таблицу

• Описание поддомена для поля Описание — ссылка на таблицу

• Описание поддомена для поля Количество страниц — ссылка на таблицу

• Описание поддомена для поля файла изображения — ссылка на таблицу

Имена поддоменов заданы для удобства их использования в будущем.

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

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

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

В таком случае, поможет алгоритм похожий на бинарный поиск:

1. Поделить упавшее значение на 2

2. Если оба значения не проходят, то каждое нужно ещё раз поделить на 2

3. Если в одном значении ошибка пропала, то оставшиеся делим на 4

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

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

Значение поддомена считается независимым, если оно не влияет на диапазон валидных значений другого поддомена.

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

Для меня удобнее выписать получившиеся тесты в отдельную таблицу да да еще одна таблица горизонтально — начало таблицы и конец таблицы.

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

Анализ выходных параметров

В используемом мной примере, я намерено опускаю анализ выходных параметров. После заполнения необходимых полей, просто жмем на кнопку «Создать блокнот» и представим, что нас перебрасывает на страничку с надписью «Прекрасный блокнот получился! Наш менеджер с вами свяжется!». Анализировать тут особо нечего.

Тем не менее это важный этап, на котором вы сможете найти тестовые входящие значения для различных выходных данных.

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

Часто приводят следующий пример — есть программа сложения двух целых чисел:

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

1. 0 + 0 = 0 — минимальный результат равен нулю;

2. 1 + 1 = 2 — результат может быть длиной один символ;

3. 1 + 10 = 11 — результат может быть длиной два символа;

4. 99 + 99  = 208 — максимальный результат может быть равен 208 и максимальная длина результата 3 символа;

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

Можно дальше развивать мысль, но давайте просто выделим:

• класс эквивалентности “Допустимые значения выходного параметра” — [0, 208]

• класс эквивалентности “Допустимая длина результата” — 1, 2, 3

Выделим представителей: 0 , 1, 99, 208

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

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

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

Важно было передать суть, а дальше вы уже сами.

Заключение

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

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

Именно поэтому, в комментариях к различным статьям и видосам можно увидеть радостные и удивленные откровения людей по типу: «О, а я так и делаю! Не знал, что это называется доменный анализ!».

Ну и на последок, попробуем сформулировать определение своими словами:

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

На всякий случай, вот вам ссылка не на скрины таблиц а на гугл таблицу.

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

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

• Введение.
• Эквивалентное разбиения (Equivalence partitioning).
• Анализ граничных значений (Boundary value analysis)
• Доменное тестирование в деталях (Domain testingDomain analysis)
• Примеры:
  • Текстовое поле.
  • Целочисленное поле.
  • Файл.

Введение

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

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

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

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

Техника эквивалентного разбиения (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 testingDomain 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.

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

Использование классов эквивалентности и граничных условий позволяет
уменьшить число тестовых вариантов в случае, если идёт тестирование по
единственному критерию. Однако в ситуации, когда входные условия/значения описываются некоторым перечнем параметров (критериев),
возникает задача учёта различных сочетаний значений параметров из этого
перечня.
Доменное тестирование
Доменное тестирование (domain analysis, domain testing) — техника тестирования на основе классов эквивалентности и граничных условий, позволяющая эффективно создавать тест-кейсы, затрагивающие несколько параметров (переменных) одновременно (в том числе с учётом взаимозависимости этих параметров). Данная техника также описывает подходы к выбору
минимального множества показательных тест-кейсов из всего набора возможных тест-кейсов.
Одним их эффективных вариантов представления комбинаций параметров является использование таблицы.
Рассмотрим одну из методик составления таблицы комбинаций. Пусть
число параметров, комбинации которых нужно учесть, равно четырём. Так
же для краткости изложения пусть каждый параметр характеризуется лишь
двумя значениями.
1) В начале учтём комбинации значений первых двух параметров. Получим таблицу следующего вида:
Таблица 1. Комбинации значений первых двух параметров
Параметр2. Значение1
Параметр2. Значение2
Параметр1. Значение1
+
+
Параметр1. Значение2
+
+
На пересечении строк и столбцов можно отмечать необходимость выполнения проверки (здесь – «+») или её отсутствие, приоритет проверки, отдельные значения параметров, ссылки и т. д.
Далее добавим третий параметр:
Таблица 2. Комбинации значений первых трёх параметров
Пар#2 – Зн#1
Пар#3 – Зн#1
Пар#3 – Зн#2
Пар#2 – Зн#2
Пар#1 – Зн#1
+
+
Пар#1 – Зн#2
–
–
Пар#1 – Зн#1
+
+
Пар#1 – Зн#2
+
+
И наконец, четвёртый параметр. Чтобы таблица равномерно увеличивалась по высоте и ширине, удобно добавлять каждый последующий параметр
попеременно — то как столбец, то как строку. Третий параметр мы добавили
как столбец, четвёртый добавим как строку.
Таблица 3. Комбинации значений четырёх параметров
Пар#4 – Зн#1
Пар#4 – Зн#2
Пар#2 – Зн#1 Пар#2 – Зн#2 Пар#2 – Зн#1 Пар#2 – Зн#2
Пар#3 – Зн#1 Пар#1 – Зн#1
Пар#1 – Зн#2
Пар#3 – Зн#2 Пар#1 – Зн#1
Пар#1 – Зн#2
Такое представление позволяет очень легко увидеть комбинации значений параметров, которые необходимо подвергнуть тестированию. Вместо
знаков «+» в ячейки можно поставить ссылки на другие таблицы (хотя иногда все данные совмещают в одной таблице), в которых будут представлены
классы эквивалентности и граничные условия для каждого выбранного случая.
Комбинаторные техники или комбинаторное тестирование
Видно, что при большом числе параметров и их значений подобная таблица может иметь сотни строк и столбцов. И число комбинаций может оказаться слишком большим. В таких случаях можно прибегнуть к одной из
комбинаторных техник тестирования, которые позволяют выбрать подходящий набор комбинаций тестовых данных для достижения установленного
уровня тестового покрытия в случае, когда проверка всех возможных наборов значений тестовых данных невозможна за имеющееся время.

Книга посвящена всего лишь одному виду тестирования — тестированию доменного анализа (также его называют доменный анализ либо доменное тестирование).

Что это за вид тестирования, которому посвятили целых 488 страниц? Давайте разберемся.

Если мы с вами обратимся к глоссарию ISTQB, то определение доменного тестирования звучит следующим образом:

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

Если переформулировать проще, то определение будет следующим:

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

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

Для понимания возьмем простой пример. Скажем, что у нас есть поле Логин и Пароль. В идеале, нам необходимо каждое поле протестировать по отдельности. Однако доменное тестирование позволяет сделать так, чтобы в одном тесте мы смогли проверить оба поля одновременно и без потери в качестве тестирования.

Пример из жизни. Возьмем два действия: 1. ехать в автобусе в качестве пассажира и 2. слушать аудиокнигу. Мы можем просто ехать в автобусе без прослушивания книги, как и слушать книгу, не едучи в автобусе. Но мы можем объединить эти два действия и слушать книгу, пока едем в автобусе. При таком объединении мы без потери качества и до нужного места доберемся, и книгу послушаем.

Конечно, тут тоже есть свои ограничения и нюансы. Например, будет так шумно, что мы ничего не услышим. Но и при реальном тестировании они тоже есть. Например, при вводе логина и пароля сайт выводит “общее” предупреждение, которое гласит: “Логин или пароль введены неверно”. То есть в этом случае мы не сможем понять, что именно неверно.

Разновидности доменного тестирования: признаки эквивалентности и анализ граничных значений

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

Давайте вспомним, что они означают.

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

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

Цель доменного тестирования

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

Нет, естественно, не один, но должно остаться минимум тестов, которые будут самые эффективными.

Шаги для достижения цели:

1. Для начала нужно разделить предполагаемые значения на отдельные группы, условия — это могут быть цифры, буквы, допустимый диапазон цифр, предполагаемые граничные значения.
2. Далее необходимо выявить конкретный набор значений и выбрать из них наиболее показательные, представляющие каждую группу, включая обязательно границы. Здесь мы уже определяем значения, которые будем проверять.
3. И далее необходимо скомбинировать эти значения таким образом, чтобы отдельные параметры можно было протестировать одновременно.

Давайте разберем все на конкретном примере.

К нам на тестирование поступает задача «протестировать форму авторизации». Форма состоит из двух полей: логин и пароль. Длина логина и пароля — от 5 до 10 символов. Логин может принимать различные символы, цифры и буквы на латинице. Пароль тоже может принимать символы, цифры и латиницу.

Решение:

1. Для начала разделим все предполагаемые значения на группы:

• Кол-во значений от — ∞ до 4
• Кол-во значений от 5 до 10
• Кол-во значений 11 до + ∞
• Спец. символы
• Буквы (латиница)
• Цифры

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

• 4
• 5, 7, 10
• 11
• @, !, $
• a, b, w, l
• 2, 4

3. И далее скомбинируем эти значения в виде таблицы.

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

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

У доменного тестирования есть свои как плюсы, так и свои минусы.

К достоинствам можно отнести:

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

Недостатки:

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

Полезные хитрости

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

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

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

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