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

Обновлено: 05.07.2024

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

Роли в тест дизайне:

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

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

Существуют следущее подходы к оценке и измерению тестового покрытия:

Покрытие требований (Requirements Coverage) — оценка покрытия тестами функциональных и нефункциональных требований к продукту, путем построения матриц трассировки (traceability matrix).
Покрытие кода (Code Coverage) — оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
Тестовое покрытие на базе анализа потока управления — оценка покрытия основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.

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

Пример использования техники анализа классов эквивалентности:

Эквивалентное разделение, алгоритм использования техники:

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

Можно разбивать тесты на классы эквивалентности по разным принципам. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем выбрать разные принципы разбиения на классы эквивалентности:

По количеству символов.
По типу символов (цифры, буквы, спец символы).

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

За 5 суток до вылета комиссия составляет 0%.
Меньше 5 суток, но больше 24 часов – 50%.
Меньше 24 часов, но до вылета – 75%.
После вылета – 100%.

Рис. 5.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов

Шаги:

1. Определим классы эквивалентности:

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

1 класс: время до вылета > 5 суток.
2 класс: 24 часа

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

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

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

За 5 суток до вылета комиссия составляет 0%.
Меньше 5 суток, но больше 24 часов – 50%.
Меньше 24 часов, но до вылета – 75%..
После вылета – 100%

Рис. 5.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов

Шаги:

1. Выделим классы эквивалентности:

1 класс: время до вылета > 5 суток.
2 класс: 24 часа

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

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

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

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

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете. (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

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

Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите ~~довольное лицо Заказчика (ну или продукт овнера)~~ качество задачи после внедрения.

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

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

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

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

Анализ требований и рисков тестирования
Определение проверок для тестирования
Формализация проверок в виде тестовых сценариев
Приоритезация проверок
Определение подходов к тестированию

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

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

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

Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

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

От 18 до 25 лет – 18%
От 25 до 45 лет – 16 %
Свыше 45 лет – 20%

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

В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.

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

Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
Негативные проверки: 0, 3, -1, А и т.д.

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

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

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

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

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

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

Вроде все просто!

Вернемся к нашему примеру ранее.

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

От 18 до 25 лет – 18%
От 25 до 45 лет – 16 %
Свыше 45 лет – 20%

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так :)

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

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

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

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

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

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

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

~~Что ж, слишком легко. Сейчас начнем разбирать более сложные техники, готовьтесь.~~

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

Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

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

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

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

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

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

Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:

ФИО
Дата рождения
Мобильный телефон
Серия номер паспорта
Электронная почта,
а также 2 чек-бокса.

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Поле ФИО может принимать значения (классы):

ФИО на русском
Невалидное значение
Пустое значение

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

Валидное значение
Невалидное значение
Пустое значение

Валидное значение
Невалидное значение

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:

После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Эквивалентное Разделение (Equivalence Partitioning – EP)

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

У нас есть приложения в котором при регистрации нужно ввести Имя.

Установлены следующие критерии при вводе имени.

Ограничение в 30 символов

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

По-этому мы можем разбить имена людей на классы.

Короткие имена от 2 до 5 символов

Средний длины имена от 5 до 15 символов

Длинные имена от 15 до 30 символов

В этой ситуации нам достаточно проверить три имени ( 2 символа, 8 символов, 30 символов).

Количество проверок значительно сократилось, плюс мы сэкономили кучу времени.

2. Тестирование Граничных Значений (Boundary Value Testing).

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

0 до 120 см вход на аттракцион запрещен.

120 до 160 см вход на аттракцион с ограничениями.

160-250 см вход без ограничений.

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

0 до 119 см вход на аттракцион запрещен.

120 до 159 см вход на аттракцион с ограничениями.

160-250 см вход без ограничений.

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

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

3 Таблица Принятия Решений (Decision Table Testing)

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

Условие	Значение
Пароль	Верный	Верный	Неверный	Неверный
Логин	Верный	Неверный	Верный	Неверный
Доступ разрешен	Доступ не разрешен	Доступ не разрешен	Доступ не разрешен

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

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

С помощью этого метода можно протестировать сочетание каждого параметра с остальными параметрами и выявить минимально количество тестов для максимального покрытия.

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

Платформа	Интернет	Сим-карта
Android	4G	MTS
Android	3G	Мегафон
Android	4G	MTS
Android	3G	Мегафон
iOs	4G	MTS
iOs	3G	Мегафон
iOs	4G	MTS
iOs	3G	Мегафон

С помощью вычисления программы Pairwise Independent Combinatorial Testing (PICT) мы можем найти оптимальное количество тестов для тестирования. Вместо 8 тестов нам нужно произвести всего 4.

Платформа	Интернет	Браузер
Android	4G	MTS
Android	3G	Мегафон
iOs	4G	Мегафон
iOs	3G	MTS

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

Читайте также: