Тестирование на основе сценариев использования

Автор: Екатерина Курач

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

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

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

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

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

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

Методология разработки тестовых случаев на основе сценариев использования

Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации. Для разработки тест кейсов на основе одного случая использования разрабатываются несколько сценариев, соответственно: Сценарий использования представляет собой оптимистический сценарий, который выбирается чаще других. В раздел Альтернативные пути могут быть включены несколько сценариев, которые отличаются от сценария использования в различных аспектах, однако остаются полноценными путями исполнения. В раздел Исключительные пути попадают те сценарии, которые приводят к возникновению ошибок. Каждый сценарий предусматривает действия, предпринимаемые действующим субъектом, и требует от системы отклика, который соответствует основной части тестового случая. Тестовый случай состоит из некоторого набора предусловий, стимулирующего воздействия (входные данные) и ожидаемого отклика.

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

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

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

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

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

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

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

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

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

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

В таблице 1 показаны классы эквивалентности этих трех переменных.

Имя переменной	Тип объекта	Классы эквивалентности
Имя	Строка	Имя, которое выходит за пределы максимальной длины строки Имя, которое в точности соответствует максимальной длине строки Полное имя с оставшимся пустым пространством Пустое имя
Служащий	Штатная единица	Специально созданная штатная единица Ранее существовавшая единица
Авторизация	Код безопасности	Санкционирован только локальный доступ Санкционирован доступ в масштабах всей системы

Спецификация входных значений для системы управления кадрами

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

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

Имя	Штатная единица	Авторизация
Полное имя с остающимся пустым пространством	Ранее существовавшая штатная единица	Санкционирован только локальный доступ
Полное имя с остающимся пустым пространством	Новая штатная единица	Санкционирован только локальный доступ
…	…	…

Перестановки входных данных системы управления персоналом

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

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

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

Второй подход заключается в разработке тестовых случаев большого цикла (grand tour test cases), в котором каждый тестовый случай генерирует данные, которые служат входом для следующего тестового случая. По условиям такого подхода каждый тест переносит тестовые данные через весь жизненный цикл. Полученное при этом состояние базы данных используется в качестве входного для следующего теста. Этот метод особенно эффективен при тестировании жизненного цикла после того, как тестирование нижнего уровня позволило выявить большую часть дефектов, вызывающих отказы. Если выстроить тестовые случаи в соответствующую последовательность, то после успешного выполнения тестового случая 1 устанавливается такое состояние программы, которое ожидается как входное для тестового случая 2. Очевидная проблема в условиях очерченного подхода заключается в том, что неудачное выполнение тестового случая 1 оставляет программу в состоянии, которого мы не ожидали, в результате чего мы не можем выполнять прогон тестового случая 2 или даже вернуть программу в рабочее состояние.

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

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

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО «ТИД «ДС»», 2002.—432 с.

• Эквивалентное разделение
• Анализ граничных значений
• Переход состояний
• Попарное тестирование
• Предугадывание ошибок

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

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

Что такое тест-дизайн?

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

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

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

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

Популярные техники тест-дизайна

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

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

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

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

Эквивалентное разделение

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

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

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

Пример эквивалентного разделения

Допустим, есть интернет-магазин, который предлагает разные тарифы на доставку в зависимости от стоимости корзины. Например:

1. Стоимость доставки для заказов на сумму менее $100 составляет $15.
2. Стоимость доставки для заказов на сумму более $100 составляет $5.
3. При заказе от $300 долларов доставка бесплатна.

У нас есть следующие ценовые категории для работы:

1. от $1 до $100.
2. от $100 до $300.
3. $300 и выше.

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

От $1 до $100:

•  допустимые значения: любая цена в диапазоне от 1 до 99,99
•  недопустимые значения: любая цена ниже 1 или выше 99,99

От $100 до $300:

•  допустимые значения: любая цена в диапазоне от 100 до 299,99
•  недопустимые значения: любая цена ниже 100 или выше 299,99

$300 и выше:

• допустимые значения: любая цена выше 299,99;
• недопустимые значения: любая цена ниже 300.

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

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

Анализ граничных значений в чем-то похож на эквивалентное разделение. Можно даже сказать, что оно лежит в основе анализа граничных значений. Но есть некоторые отличия.

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

Эта логика применяется для интеграционного тестирования. Мы проверяем отдельные элементы во время юнит-тестирования, а на следующем уровне ошибки, скорее всего, появятся на «стыках» юнитов.

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

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

От $1 до $100:

• допустимые граничные значения: 1,00, 1,01, 99,99
• недопустимые граничные значения: 0,99, 100,00, 100,01

От $100 до $300:

• допустимые граничные значения: 100,00, 100,01, 299,99;
• недопустимые граничные значения: 99,99, 300,00;

$300 и выше:

• допустимые граничные значения: 300,00, 300,01;
• недопустимые граничные значения: 299,99.

Переход состояний

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

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

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

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

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

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

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

		Пароль верный	Пароль неверный
Состояние 1	Клик на «Войти»	Состояние 5	Состояние 2
Состояние 2	1-я попытка	Состояние 5	Состояние 3
Состояние 3	2-я попытка	Состояние 5	Состояние 4
Состояние 4	3-я попытка	Состояние 5	Состояние 6
Состояние 5	Вход в систему
Состояние 6	Блокировка

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

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

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

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

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

Допустим, есть сеть пекарен, продающих яблочные пироги и чизкейки онлайн. Каждый товар доступен в трех размерах – маленьком, среднем и большом. Пекарня предлагает доставку, как немедленную, так и к определенному времени, а также возможность самовывоза. Пекарня работает в трех городах – Нью-Йорке, Лос-Анджелесе и Чикаго. Также пользователь может заказать до трех товаров одновременно.

Заказ	Размер	Город	Количество	Доставка	Время
Яблочный пирог	Маленький	Нью-Йорк	1	Адресная	Немедленно
Чизкейк	Средний	Лос-Анджелес	2	Самовывоз	К указанному времени
	Большой	Чикаго	3

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

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

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

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

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

Как правило, тестировщики начинают с тестирования на распространенные ошибки:

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

Чем больше опыта у тестировщика, тем больше сценариев предугадывания ошибок он сможет быстро придумать.

Итоги

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

В этом уроке мы рассмотрим следующие темы:

• Тест-дизайн
• Техники тест-дизайна
  • Классы эквивалентности
  • Граничные значения
  • Попарное тестирование
  • Таблица принятия решений
  • Диаграмма состояний и переходов
  • Тестирование вариантов использования
  • Доменное тестирование

Тест-дизайн

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

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

Разработка тестов начинается после проведения исследования ПО, когда цели определены, а критерии тестирования заданы и выполняются.

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

Техники тест-дизайна помогают:

1. Исключить непродуктивные тест-кейсы и сократить общее количество кейсов
2. Покрыть тестами как можно больше функциональности
3. Провести все тесты и не пропустить ничего важного

Для работы с кодом (white-box) важны такие аспекты:

• Покрытие операторов
• Покрытие условий
• Покрытие путей
• Покрытие функций
• Покрытие вход/выход
• Покрытие значений параметров

В работе с требованиями (black-box) тестирование проходит иначе:

• Классы эквивалентности
• Граничные значения
• Попарное тестирование
• Таблица принятия решений
• Диаграмма состояний и переходов
• Тестирование вариантов использования
• Доменное тестирование.

Техники тест-дизайна на основании требований

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

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

Рассмотрим для примера перевод денег в банке. Размер комиссии зависит от суммы перевода:

• от 1 до 999 долларов включительно – 0%
• от 1000 до 4999 долларов включительно – 5%
• от 5000 долларов – 7%

Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются.

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

• 1-999 => ожидаем комиссию 0%
• 1000-4999 => ожидаем комиссию 5%
• 5000-100000 => ожидаем комиссию 7%

Выбранные значения для проверки: 500, 2500, 7500.

• На значение 500 система отреагирует так же, как и на любое другое значение из первого диапазона
• На значение 2500 система отреагирует так же, как и на любое другое значение из второго диапазона
• На значение 7500 система отреагирует так же, как и на любое другое значение из третьего диапазона

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

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

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

Например, неопытный программист при постановке «не больше 1000» может поставить значение <1000.

Вернемся к примеру с комиссией:

• от 1 до 999 долларов включительно – 0%
• от 1000 до 4999 долларов включительно – 5%
• от 5000 долларов – 7%

Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются. Вспомним классы эквивалентности:

• 1-999 => ожидаем комиссию 0%
• 1000-4999 => ожидаем комиссию 5%
• 5000-100000 => ожидаем комиссию 7%

Граничные значения: 1, 999, 1000, 4999, 5000, 100000.

С учетом классов эквивалентности и граничных значений выбираем значения для проверки:
1, 500, 999, 1000, 2500, 4999, 5000, 7500, 100000.

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

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

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

Рассмотрим пример. Возьмем наушники с такими характеристиками:

• Тип подключения (беспроводной или проводной)
• Микрофон (включен или выключен)
• Подсветка (включена или выключена)

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

#	Тип подключения	Микрофон	Подсветка
1	Проводной	Включен	Включена
2	Проводной	Включен	Выключена
3	Проводной	Выключен	Включена
4	Проводной	Выключен	Выключена
5	Беспроводной	Включен	Включена
6	Беспроводной	Включен	Выключена
7	Беспроводной	Выключен	Включена
8	Беспроводной	Выключен	Выключена

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

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

• 1 нет, нет, нет -> нет, нет, нет -> нет, нет, нет (00, 00, 00)
• 2 да, да, нет ->да, да, нет -> да, да, нет (11, 10, 10)
• 3 нет, да, да -> нет, да, да -> нет, да, да (01, 11, 01)
• 4 да, нет, да -> да, нет, да -> да, нет, да (10, 01, 11)

При трех параметрах, каждый из которых имеет 3 значения, количество вариантов полного перебора – 27 (три в третьей)
Применив pairwise, количество тест-кейсов сведётся к 9.

#	Тип подключения	Микрофон	Подсветка
1	Беспроводной	Выключен	Выключена
2	Проводной	Включен	Выключена
3	Беспроводной	Включен	Включена
4	Проводной	Выключен	Включена

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

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

Это взаимосвязь между множеством условий и действий.

Таблица принятия решений содержит следующие элементы:

• Условия — список возможных условий
• Варианты — комбинация из выполнения и/или невыполнения условий этого списка
• Действия — список возможных действий (вариантов исхода)

Например, кредит выдаётся людям, удовлетворяющим трём условиям:

• Возраст: 18-60 лет
• Гражданство: Россия
• Стаж работы: более 5 лет ИЛИ средняя месячная зарплата за год больше 100 тысяч рублей

Условие	Значение 1	Значение 2	Значение 3	Значение 4
Возраст 18-60	да	да	да	нет
Гражданство РФ	да	да	да	да
Стаж больше 5 лет	да	нет	да	да
ЗП выше 100 тысяч рублей	нет	да	да	да
Действие
Кредит одобрен	да	да	да	нет

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

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

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

Состояние А ——переход—–> Состояние Б

Тестирование вариантов использования

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

Вариант использования или юз-кейс – это описание конкретного использования системы субъектом или пользователем

Юз-кейсы содержат следующие сведения:

• Кто использует сайт или приложение
• Что пользователь хочет сделать
• Какие шаги делает пользователь, чтобы совершить определенное действие
• Как сайт или приложение реагируют на действия пользователя

Доменное тестирование

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

Доменное тестирование применяется для сокращения количества проводимых тестов без потери качества тестирования.

Очень часто классы эквивалентности, относящиеся к позитивным проверкам, можно проверять совместно.

Возьмем для примера такие требования:

• Размер файла: до 200 МБ
• Имя файла: от 5 до 24 символов, только латиница
• Форматы файлов: только изображения

В этом случае нужны такие проверки:

1. Загрузить файл менее 200 МБ
2. Загрузить файл с именем hexlet
3. Загрузить файл с расширением .jpg

Можно заменить одной проверкой:

1. Загрузить файл менее 200 МБ, с именем hexlet.jpg

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