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

Блог седого тестировщика

говориМ о тестировании
простым языком

Меню

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

Время на прочтение: 3 мин.

• 
  
  
  Вячеслав Зимин
• 
  
  
  15 июля, 2019
• 
  
  
  Нет комментариев

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

Очень часто мне приходилось сталкиваться с тем, что начинающие тестировщики (да и я сам раньше) путают понятия. Например, исследовательское тестирование — это техника или вид? А функциональное тестирование? Давайте разбираться.

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

В первую очередь выделяют три категории методов проектирования тестов:

1. Методы черного ящика.
2. Методы белого ящика.
3. Методы, основанные на опыте.

В чем их различие?

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

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

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

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

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

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

Методы черного ящика (Black-box Test Techniques)

1. Эквивалентное разбиение (Equivalence Partitioning). Эта техника говорит нам о том, что тестовые данные необходимо разбивать на некоторые группы, внутри которых результат выполнения тестов идентичен. Группы могут быть как для позитивных, так и для негативных значений.
   Подробнее о методе читаем тут https://vk.com/wall-172009645_386
2. Анализ граничных значений (Boundary Value Analysis). Является продолжением предыдущего метода и говорит нам о том, что необходимо брать значения, которые лежат на границе классов.
   Подробнее о методе читаем тут https://vk.com/wall-172009645_386
3. Тестирование с помощью таблицы альтернатив (Decision Table Testing). Это способ компактного представления модели со сложной логикой.
   Достаточно понятно метод описан тут http://blog.rocketbrain.ru/decision-table-test-design/ (если данная ссылка не работает, то читаем о методе тут https://training.qatestlab.com/blog/technical-articles/tables-solutions-and-their-usage-in-testing/)
4. Тестирование с помощью таблицы переходов (State Transition Testing). Интересная техника, которая позволяет составлять высокоуровневые чек-листы.
   О ней я рассказывал в двух статьях https://vk.com/wall-172009645_515 и https://vk.com/wall-172009645_583
5. Тестирование с помощью сценариев использования (Use Case Testing). Сценарии использования — это перечень действий, сценарий по которому пользователь взаимодействует с приложением, программой для выполнения какого-либо действия для достижения конкретной цели. Тестирование по сценариям проводится для того, чтобы обнаружить дополнительные логические дыры и баги в приложении, которые сложно найти в тестировании индивидуальных модулей, частей приложения отдельно друг от друга.
   Почитать можно в статье http://software-testing.ru/library/5-testing/78-2008-09-29-07-33-51
6. Техника попарного тестирования (Pairwise Testing). Она не содержится в перечне техник ISTQB, но я тоже решил ее добавить. Используется, когда необходимо не просто протестировать продукт, а продукт с множеством взаимосвязанных входных данных.
   Подробнее тут https://vk.com/wall-172009645_468

Методы белого ящика

1. Тестирование и покрытие операторов (Statement Testing and Coverage). Тестирование операторов направлено на проверку исполняемых операторов в коде. Покрытие вычисляется как отношение количества операторов, выполненных тестом, к общему числу операторов в тестируемом коде.
2. Тестирование и покрытие условий (Decision Testing and Coverage). Тестирование условий направлено на проверку логических условий в коде, а также кода, выполняемого в зависимости от исхода условия. Покрытие вычисляется как отношение числа исходов условий, проверенных тестом, к общему числу исходов тестируемых условий.

Методы, основанные на опыте (Experience-based Test Techniques)

1. Предположение об ошибках (Error Guessing). Это способ предотвращения ошибок, дефектов и отказов, основанный на знаниях тестировщика.
   Подробнее можно прочитать тут https://vk.com/wall-172009645_640
2. Исследовательское тестирование (Exploratory Testing). Это достаточно гибкое тестирование, которое говорит нам о том, что тест-кейсы и чек-листы создаются, выполняются, анализируются и оцениваются динамически во время выполнения тестов.
   Исследовательское тестирование лучше всего подходит в ситуациях, когда документация недостаточная, либо вовсе отсутствует, в условиях очень сжатых сроков и как дополнение к другим, более формальным, методам тестирования.
3. Тестирование на основе чек-листов (Checklist-based Testing). При тестировании по чек-листам тестировщик проектирует, реализует и выполняет тесты, указанные в чек-листе.
   Такие списки могут быть построены на опыте, на исторических данных об ошибках, на информации о приоритетах для пользователей и понимании, как и почему происходят отказы в программе.

***

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

Автор статьи:

Вячеслав Зимин

Тестировщик со стажем. Основатель школы седого тестировщика.

Межтекстовые Отзывы

Посмотреть все комментарии

Ближайшие события

• Живые прямые эфиры с практикой
• 
  
  23 и 24 января в 19:00 по МСК.

• Тренинг с практикой на реальном проекте
• 
  
  с 6 февраля и с 6 марта

Ближайшие события

• Прямой эфир «Баг-репорты: как составлять отчеты об ошибках без ошибок»
• 
  
  2 сентября в 19:00 по МСК

• Мини-курс «Путь в тестирование»
• 
  
  После регистации

Вам также может понравится

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Очень часто тестировщикам приходится комбинировать несколько техник тест-дизайна для обеспечения наиболее эффективного покрытия тестами. Правильная комбинация всегда зависит от конкретного проекта.

Автор: Антон Алексеев

Оригинальная публикация

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

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

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

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

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

В итоге цепочка тестирования выглядит так:

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

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

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

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

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

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

Стоит ли проверять каждое значение? Более разумным видится тестирование диапазона каждого условия. Собственно, это и есть наши классы эквивалентности:

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

Как уже было указано, после определения классов эквивалентности мы должны выполнить тест с любым значением из диапазона класса. Таким образом, у нас остается только 4 позитивных тест-кейса вместо первоначальных 100 (0-99), например:

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

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

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

Вернемся к примеру, рассмотренному нами в технике классов эквивалентности:

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

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

If (applicantAge >= 0 && applicantAge <=15) hireStatus=»NO»;
If (applicantAge >= 16 && applicantAge <=18) hireStatus=»PART»;
If (applicantAge >= 18 && applicantAge <=55) hireStatus=»FULL»;
If (applicantAge >= 55 && applicantAge <=99) hireStatus=»NO»;

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

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

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

If (applicantAge >= 0 && applicantAge <=15)
hireStatus=»NO»;
If (applicantAge >= 16 && applicantAge <=17)
hireStatus=»PART»;
If (applicantAge >= 18 && applicantAge <=54)
hireStatus=»FULL»;
If (applicantAge >= 55 && applicantAge <=99)
hireStatus=»NO»;

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

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

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

 

Нажмите на картинку, чтобы увеличить изображение

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

Нажмите на картинку, чтобы увеличить изображение

Получаем:

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

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

Нажмите на картинку, чтобы увеличить изображение

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

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

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

Нажмите на картинку, чтобы увеличить изображение 

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

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

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

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

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

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

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

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

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

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

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

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

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

Обсудить в форуме

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

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

Тест-дизайн

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

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

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

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

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

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

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

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

Отчет
по лабораторной работе: набор тестовых
сценариев, спецификация для тест дизайна.

Теоретическая часть Функциональное тестирование или Functional Testing

Функциональное тестированиерассматривает заранее указанное
поведение и основывается на анализе
спецификаций функциональности компонента
или системы в целом.

Функциональные тестыосновываются
на функциях, выполняемых системой, и
могут проводиться на всех уровнях
тестирования (компонентном, интеграционном,
системном, приемочном). Как правило, эти
функции описываются в требованиях,
функциональных спецификациях или в
виде случаев использования системы
(use cases).

Тестирование функциональности может
проводиться в двух аспектах:

• требования

• бизнес-процессы

Тестирование в перспективе «требования»
использует спецификацию функциональных
требований к системе как основу для
дизайна тестовых случаев (Test Cases). В этом
случае необходимо сделать список того,
что будет тестироваться, а что нет,
приоритезировать требования на основе
рисков (если это не сделано в документе
с требованиями), а на основе этого
приоритезировать тестовые сценарии
(test cases). Это позволит сфокусироваться
и не упустить при тестировании наиболее
важный функционал.

Тестирование в перспективе «бизнес-процессы»
использует знание этих самых
бизнес-процессов, которые описывают
сценарии ежедневного использования
системы. В этой перспективе тестовые
сценарии (test scripts), как правило,
основываются на случаях использования
системы (use cases).

Преимущества функционального
тестирования:

• имитирует фактическое использование
  системы;

Недостатки функционального тестирования:

• возможность упущения логических ошибок
  в программном обеспечении;

• вероятность избыточного тестирования.

Достаточно распространенной является
автоматизация функционального
тестирования.

Тестовый случай (Test Case)

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

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

Action
> Expected Result
> Test Result

Пример:

Action	Expected Result	Test Result (passed/failed/blocked)
Open page «login»	Login page is opened	Passed

Виды Тестовых Случаев

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

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

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен
иметь 3 части:

PreConditions	Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description	Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions	Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

Примечание:
Post Conditions
не является обязательной частью. Это
скорее всего — правило хорошего тона:
«намусорил — убери за собой». Это
особенно актуально при автоматизированном
тестировании, когда за один прогон можно
наполнить базу данных сотней или даже
тысячей некорректных документов.

Пример
тест кейса:

do
A1, verify B1

do
A2, verify B2

do
A3, verify B3

В приведенном примере
конечная проверка — В3. Это значит, что
именно она является ключевой. Значит,
A1 и А2 — это действия приводящие систему
в тестопригодное состояние. А В1 и В2 —
условия того, что система находится в
состоянии пригодном для тестирования.
Таким образом имеем:

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1
do A2	verify B2
Test Case Description
do A3	verify B3
PostConditions

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

Теперь ответим на вопрос:
«Почему данное разбиение удобно
использовать?»

Ответ: конечная проверка
одна, т.е. в случае если тест провален
(test failed)
будет сразу ясно из-за чего. Т.к. если
провальными окажутся проверки В1 и/или
В2, то тест кейс будет заблокирован (test
blocked), из-за того, что
функцию не возможно привести в
тестопригодное состояние (состояние
пригодное для проведения тестирования),
но это не значит, что тестируемая функция
не работает.

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1	passed
do A2	verify B2	failed
Test Case Description:
do A3	verify B3	blocked
PostConditions

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

---

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

Обеспечение качества (Quality Assurance) — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

Контроль качества (Quality Control) — анализ результатов тестирования и качества новых версий выпускаемого продукта.

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

Это одна из техник QC, включающая в себя:

• планирование работ (Test Management)

• проектирование тестов (Test Design)

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

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

Как взаимосвязаны выше указанные термины хорошо объясняется в статье Разница между тестированием, QC и QA. Здесь я не буду слишком останавливаться на этом, потому что эта статья больше про тестирование ПО.

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

• техническая

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

• коммерческая

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

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

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

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

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

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

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

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

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

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

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

Тест дизайн

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Ответственные за тест дизайн:

• Тест аналитик — определяет «ЧТО тестировать?»

• Тест дизайнер — определяет «КАК тестировать?»

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

1. Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

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

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

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

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

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

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

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

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом.

Нефункциональные виды тестирования

• Тестирование пользовательского интерфейса (GUI Testing)  — функциональная проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

• Тестирование удобства пользования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
  User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

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

• Тестирование установки (Installation testing) направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

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

• Тестирование взаимодействия (Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

• Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

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

• Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

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

По виду Тестовых Сценариев:

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

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

По Уровню Тестирования:

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

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

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

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

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

Cтатическое и динамическое тестирование

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

Исследовательское / ad-hoc тестирование

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками.

Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В чем разница между regression testing и re-testing? Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

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

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

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

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

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

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

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

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

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

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию ( а также необходимое в процессе работы оборудование, специальные знания, оценки рисков с вариантами их разрешения). Отвечает на вопросы:

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

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

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

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

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

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

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

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

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

Тест-кейс состоит из:

• Названия

• Более подробного описания сути проводимого кейса (для более сложных кейсов)

• Описания окружения

• Указания тестируемого компонента приложения

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

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

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

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

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

Наиболее часто выделяются наборы для:

• Smoke тестирования

• приёмо-сдаточных испытаний.

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

---

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

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