что такое тест дизайн

18.12.202308.07.2022 admin 0 Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

Шаги:

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

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

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

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

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

Шаги:

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

Источник

Тест-дизайн. Когда и для чего

Предположим простую ситуацию. Вам дали тестировать сайт с описанием фильмов. Там около 1000 страниц. Простой вопрос, что тестировать?

Всегда существует вариант — тестировать “в лоб”. Открываем каждую страницу, проверяем на месте ли текст и картинки, смотрим, что расположение элементов не поехало и все стоит на своих местах. Звучит как-то не очень весело, не правда ли? Я уже не говорю о потраченном времени.

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

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

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

Мы, тестировщики, люди ленивые и не хотим много работать. Даже придумали автоматизированное тестирование, которые выполняет за нас всю нашу работу, а мы в это время лежим на берегу моря ничего не делая и зарабатывая от 100 000 рублей в месяц…. немного отвлекся:) Так вот. Умные люди задумались: а вдруг есть способ не тестировать все страницы? Может быть, есть возможность протестировать сайт быстрее, но так же качественно?

Оказывается есть. Работу тестировщика можно оптимизировать и вместо 1000 тестов провести, например, 15 или 20 тестов. Но для этого необходимо использовать определенные подходы к построению тестов. Такие подходы называют техниками тест-дизайна.

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

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

Раз речь зашла о процессе, то необходимо проговорить об этапах этого процесса.

Этапы тест-дизайна

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

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

И, в-третьих, используя полученные знания, необходимо составить набор тестов (чек-листов/тест-кейсов)

Изучить продукт. Определить техники. Написать тест-кейсы.

Еще один вопрос: должны ли они идти в таком порядке? Желательно, но не обязательно. Иногда, когда начинаешь писать кейсы, понимаешь, что необходимо еще изучить продукт и снова возвращаешься к первому этапу. Особенно если нет документации. Это нормально.