Тест для дизайнера

Home

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

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

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

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

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

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

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

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

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

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

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

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

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

  • при возрасте от 0 до 16 лет – не нанимать;
  • при возрасте от 16 до 18 лет – можно нанять только на part time;
  • при возрасте от 18 до 55 лет – можно нанять на full time;
  • при возрасте от 55 до 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 лет – не нанимать.

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

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

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

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

Таким образом, набор значений, для которых будут составлены тесты, будет выглядеть так: {-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 параметров имеет всего два значения (Вкл/Выкл), мы получаем 210 = 1024 комбинаций! Используя метод парного тестирования, мы не тестируем все возможные сочетания входных параметров, а составляем тестовые наборы так, чтобы каждое значение параметра хотя бы один раз сочеталось с каждым значением остальных тестируемых параметров. Таким образом, метод существенно сокращает количество тестов, а значит, и время тестирования.

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

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

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

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

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

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

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

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

Немного о простом. Тест-дизайн. Часть 1

Сегодня тестирование ПО, один из ключевых процессов создания продукта. Неважно, какую Вы используете методологию, подход, процесс, тестирование ПО так или иначе всегда существует в Вашем процессе. В последние годы (да даже наверное десятилетие) тестирование ПО сформировалось в отдельную область ИТ, которая постоянно развивается в мировом сообществе.
И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!
Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.
Почему?
Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!
Потому что профессия ручного тестировщика на начальном этапе не требует специфических знаний и умений. Основное «знание» для тестировщика – это умение «разрушать» и аналитическое мышление. А главное – иметь нестандартный склад ума, находить нетривиальные решения поставленных задач. Некий монстр, умеющий крушить и ломать:)
Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)
Если рассматривать технические особенности тестирования, которые должен знать ручной тестировщик, то их можно поделить на 2 основных части возможно многие со мной не согласятся, будут кричать как же так, ты не прав, тестирование это очень сложно – это подготовка к тестированию и выполнение тестирования.
Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите довольное лицо Заказчика (ну или продукт овнера) качество задачи после внедрения.
Многие из вас, кто занимался тестированием, так или иначе, занимался подготовкой к тестированию. Отличие обычно лишь в том, насколько вы этот этап процесса тестирования формализуете. Если вы занимаете исследовательским тестированием, не пишите тестовые сценарии, вам дают систему и вы сразу кидаетесь в бой, все равно, вы готовитесь к тестированию. Зачастую, на несложных проектах, тестировщик может не замечать этого, потому что этап аналитики и подготовки к тестированию проходит у вас на бессознательном уровне. Но даже если так, он все равно есть.
И в этом цикле статей поговорим об этом.
У себя на работе я часто провожу обучения для ручных тестировщиков, и сталкиваюсь с ситуациями, что вроде все слышали о техниках тест дизайна, но в работе их никто не применяет.
Выглядит это так:

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

Почему так происходит? Ведь техники тест-дизайна – это основа составления сценариев тестирования. Это тоже самое, что уметь водить машину, но при этом не знать ПДД. Почему же тестировщики не применяют их в работе?
Ответ прост.
Первое, когда тестировщиков учат на курсах по тестированию (или самообучение по книгам и статьям), то им рассказывают, как применять техники тест-дизайна на элементарных примерах. И главная проблема такого обучения, что тестировщики не могут перенести полученные знания на свои реальные задачи. То есть использовать техники тест-дизайна в повседневной работе.
Второе, при обучении техникам тест-дизайна, данный процесс очень формализуется, что выглядит, как необходимость тестировщику в своей работе все формализовать. А обычно это никому не надо времени на это ни у кого нет.
Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде 🙂 уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!
В моей организации, как и общепринятых стандартах и практиках, задачами тест-дизайна являются:

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

В этом цикле статей я постараюсь вам рассказать не только о техниках тест-дизайна, но и о том, как их ВСЕ (именно все вместе, а не конкретную одну или две) применять на практике, в том числе на примере функционала нашего банка. Как формировать проверки к тестированию с применением техник тест-дизайна для больших систем и процессов. И самое главное, вы получите ответ на то, в каких случаях и при каких проверках применять техники тест-дизайна.
Итак, начнем.
А начнем мы с самого простого, а именно о 2-х основных техниках тест-дизайна, про которые все слышали, и я уверен, применяли, но скорее всего на интуитивном уровне в своей работе.
Это классы эквивалентности и граничные значения.
Что же такой классы эквивалентности?
Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.
То есть, это некое множество значений, которое вы можете подставлять в программу и получать один и тот же результат. Результатом можем быть не только конкретные значения, действия программы, но и просто область применения. Поэтому, самые простые классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные и негативные сценарии.
Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

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

Мы определяем 2 основных класса – это позитивные и негативные сценарии.
Позитивными сценариями будут все значения, которые приводят к получению результата, негативными сценариями – значения, результаты которых не описаны, как ожидаемый результат.
Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +
В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.
Результатом данного разбиения будет значение или диапазон значений, в котором нам необходимо выполнить всего одну проверку с любым значением из диапазона данных. Могут возникнуть такие ситуации, как одно значение в диапазоне. Это тоже отдельный класс эквивалентности и тоже требует проверки.
Итого мы имеем.
Очень важно, что техники тест-дизайна не применяются независимо от других! Сейчас мы рассматриваем их отдельно, но в конце я научу вас использовать их вместе.
Еще одна особенность классов эквивалентности – это их применение. Я выделяю 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 чек-бокса.

Наша задача, используя техники первого уровня определить перечень классов эквивалентности, которые может принимать программа.
Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.
Итак,
Поле ФИО может принимать значения (классы):

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

Очень часто тестировщики не понимают, какие значения выбирать для данной техники, если они не ограничены возможностью ввода. Например, если у нас есть возможность выбора пола человека М или Ж, то тут все просто, есть 2 значения. Но когда у нас есть строка для ввода данных, то при попарном тестировании мы не проверяем корректность заполнения конкретного поля, т.к. эти проверки должны быть выполнены на первом уровне тест-дизайна (либо совместить их с попарным тестированием). Мы используем класс эквивалентности для данного поля, потому что нам не важно, какое именно это будет значение.
Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

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

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:

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

Чек-боксы обычно имеют всего 2 состояния – Y или N.
Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)
Следующий шаг – составление ортогонального массива с комбинациями данных. Самым простым способом составления массива является попарное заполнение данными, начиная с элементов, имеющих наибольшее количество значений и далее по убыванию. Так как в нашем примере есть 4 элемента с одинаковым количеством значений, то мы можем выбрать любую пару.
Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:

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

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

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

ТЕСТ: на знание стилей интерьера

Голосов: 39, рейтинг 4.8 из 5

  • 11.02.2019 Шторы «песочные часы» в интерьере

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

  • 11.02.2018 Жалюзи на кухню — как совместить практичность и уют

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

  • 11.01.2019 Белые шторы: купить нельзя отказаться

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

  • 11.01.2019 Какой длины должны быть шторы: простая инструкция + комментарий дизайнера

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

  • 11.01.2018 Выбираем шторы в спальню в современном стиле: Как создать уют, используя модные новинки

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

Тест: Какой стиль интерьера вам подходит?

Начать тест

    • На то, сколько у вас денег.
    • На то, сколько денег потратили на ремонт друзья и коллеги.
    • На то, как ремонт сделали соседи.
    • На то, в каких интерьерах фотографируются случайные люди в инстаграме.
    • На советы специализированных изданий.
    • На то, как долго вы сможете терпеть ремонт.
    • Много маленьких домиков вдали от города.
    • Среднее количество маленьких домиков где-нибудь в пределах кольцевой.
    • Свеженькие многоэтажки с выходом к метро.
    • Многоквартирный дом в тихом и зеленом районе и в окружении магазинов.
    • Чем ближе к центру, тем лучше.
    • Я выхожу из бункера, а вокруг тишь, и только деревья шумят листвой и вдалеке о чем-то своем перебулькиваются утопцы.
    • Шелк.
    • Нелакированное дерево.
    • Плюшевые игрушки.
    • Живот кота.
    • Творог в пакете.
    • Деньги в кармане.
    • Весна в Италии (референсы для дизайнера: цветущие сады, вино, старая брусчатка, вид на море).
    • Осень в Нью-Йорке (референсы для дизайнера: листопад, голуби разлетаются из-под ног, Дональд Трамп идет мимо по своим делам).
    • На море в июле (референсы для дизайнера: красная спина, намазанная сметаной, еда из рыбы, обезьянка, продающая пахлаву).
    • Любое лето у бабушки (референсы для дизайнера: крапива, корова, собака Тюлик, песня «Моя оборона»).
    • Спьяну в Заславль (референсы для дизайнера: рынок «Ждановичи» мелькает за окном, перрон в Заславле).
    • За шпатлевкой в Каменную Горку (референсы для дизайнера: коллаж скриншотов пустошей из серии игр «Fallout»).
    • Жареная.
    • Полезная для здоровья.
    • Красиво получающаяся на фотографиях.
    • Сытная.
    • Как в детстве.
    • Сладкая.
    • Барная стойка.
    • Арка в дверном проеме.
    • Потолок в несколько уровней, типа волной, и чтобы на каждом уровне махонькие лампочки горели, как звездочки.
    • Картонная голова оленя, собранная по инструкции с YouTube.
    • Рядок пустых бутылок на самом видном месте.
    • Огромная фотография чужого младенца на шкафу, оставшаяся от предыдущих хозяев.
    • Детская.
    • Гостиная.
    • Столовая.
    • Гардеробная.
    • Библиотека.
    • Тещина комнатка.
    • Остаться от кого-то по наследству.
    • Остаться из тех, что забыли сдать в школьную библиотеку.
    • Если их дарят люди, имеющие наглость называть себя моими друзьями.
    • Если я вдруг какую-то куплю.
    • Если не все мои книги раскупят.
    • Если нужно будет чем-нибудь красивым заставить несколько поверхностей в квартире.
    • Появился слой пыли. Ну не протирать же мне его!
    • Вышел из моды, если верить случайно брошенной реплике кого-то из моих знакомых.
    • Намозолил глаза, и дальше уже на него смотреть нет никаких сил.
    • Им пользовалась еще мама.
    • Им пользовался еще дед и приговаривал: «Им пользовался еще мой дед!»
    • Рассыпается в руках, при намазывании клеем «Момент» упорно склеивается в другой предмет.
    • Хлебосольные.
    • Вежливые.
    • Богатые.
    • Тихие.
    • Полгода живущие на даче.
    • Какие угодно, лишь бы не делали ничего из того, что делаю я.

← Назад Ответить Хозяева, а балкон-то стеклить будем?.. Ошибка Разболтать друзьям Пройти еще раз

закрыть Данное соглашение об обработке персональных данных разработано в соответствии с законодательством Украины и Российской Федерации. Все лица заполнившие сведения составляющие персональные данные на данном сайте, а также разместившие иную информацию обозначенными действиями подтверждают свое согласие на обработку персональных данных и их передачу оператору обработки персональных данных. Под персональными данными Гражданина понимается нижеуказанная информация: Имя, адрес электронной почты, номер мобильного телефона. Граждане направляют свои персональные данные оператору в целях предоставления последним услуги по созданию сайта. Гражданин, принимая настоящее Соглашение, выражают свою заинтересованность и полное согласие, что обработка их персональных данных может включать в себя следующие действия: сбор, систематизацию, накопление, хранение, уточнение (обновление, изменение), использование, уничтожение. Гражданин гарантирует: информация, им предоставленная, является полной, точной и достоверной; при предоставлении информации не нарушается действующее законодательство Украины и Российской Федерации, законные права и интересы третьих лиц; вся предоставленная информация заполнена Гражданина в отношении себя лично.

Тест по «Web-дизайн». Ответы

1. Пример кода: h1 { color: blue}.

В приведенном выше примере color: blue – определение правило. h1 является –

  • a. Селектором
  • b. Определением
  • c. Значением
  • d. Свойством

Ответ: a

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

  • a. <hr>
  • b. <frame>
  • c. <button>
  • d. <fieldset>
  • e. <label>

Ответ: d

3. Какая из следующих спецификаций правильная для определения цветового стиля?

  • a. H1 {color: FF-00-88}
  • b. H1 {color: red}
  • c. H1 {font-color: red}
  • d. H1 {color: rgb(#D46A11)}
  • e. H1 {color: 66.7%/66.7%/73.3%}

Ответ: b

4. Сервис валидации W3C CSS представляет собой бесплатный сервис созданный консорциумом Word Wide Web, которая проверяет каскадные таблицы стилей (CSS) на наличие ошибок, опечаток или неправильного использования.

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

  • a. предлагает исправления для кроссбраузерной совместимости
  • b. говорит вам, какие спецификации вашего CSS-файла не соответствует спецификации CSS
  • c. определяет потенциальные риски юзабилити
  • d. меняет вашу CSS-спецификацию на основе соответствия требованиям
  • e. позволяет загрузить исправленную версию вашего CSS-файла

Ответ: b

5. Пример кода:

<select name=»options»>

<option value=»1″ selected>One</option>

<option value=»2″>Two</option>

<option value=»3″>Three</option>

<option value=»4″>Four</option>

Что будет отправлено с формы как значение «options»-элемента, если форма отправляется без изменений?

  • a. Null
  • b. SELECTED
  • c. 1
  • d. One
  • e. «Three»

Ответ: c

6. Пример кода: H1 {color: black;}.

Выберите один ответ:

  • a. h1.w1 {color: white;}
  • b. h1.black {color: white;}
  • c. h1 {color: black; color: white;}
  • d. h1 {color: white;}
  • e. h1#w1 {color: white;}

Ответ: a

7. Возможности CSS?

Выберите по крайней мере один ответ:

  • a. Управление представлением данных для различных сред, устройств
  • b. Изменение HTML-кода веб страницы
  • c. Управление визуальным представлением контента
  • d. Изменение содержания контента

Ответ: a c

8. Какой тег определяет переход на следующую строку?

  • a. <br>
  • b. <a>
  • c. <div>
  • d. <img>

Ответ: a

9. Что является основным недостатком использования кэш браузера?

  • a. Данные могут быть не обновляемыми.
  • b. Вызывают повторение операции.
  • c. Увеличивает время загрузки.
  • d. Нельзя использоваться шифрование. Некоторые интернет-провайдеры не поддерживают его.

Ответ: a

10. С помощью какой цветовой модели представлен цвет в шестнадцатеричном виде

Ответ: c

11. Какие способы верстки Web-страниц есть?

  • a. блочные
  • b. табличные
  • c. иерархические
  • d. реляционные

Ответ: a, b

12. Какие действия возможны над селекторами в CSS?

  • a. Создание псевдоселекторов
  • b. Комбинирование классов, псевдоклассов, классов и идентификаторов
  • c. Позиционирование селекторов
  • d. Комбинирование классов, псевдоклассов и идентификаторов
  • e. Группировка селекторов

Ответ: b, d, e

13. Веб-страница однозначно определяется

  • a. изображениями
  • b. содержанием
  • c. css-файлом
  • d. адресом url
  • e. веб-сервером

Ответ: d

14. Какие теги из перечисленных ниже определяют элементы-контейнеры?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *