Образование

Тест кейс (test case)

Тест кейс ТЕСТ КЕЙС (TEST CASE) – это комплекс исходных данных, условий и ожидаемых результатов, разработанный с целью проверки требуемого свойства продукта. Test cases, собранные в последовательность для достижения некоторой цели образуют test suite (набор тестов).

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

Примечание: test case перевод из wikipedia

Содержание

Чтобы больше прояснить ситуацию с терминами и определениями, давайте сопоставим некоторые термины касательно этой темы:

  • Тест-кейс и тест = синоним
  • Не путаем чек-лист и тест. Отличие тест кейса от чек-листа заключается в том, что чек-лист это всего лишь идея будущего теста,  а тест кейс, как мы говорили выше, набор данных и ожидаемых результатов. Часто чек лист становится хорошим началом атрибута Test description в тест-кейсе.
  • Не путаем тест план и тест кейс. Что касается мы уже определились, а вот тест план это фундаментальный документ, который описывает разные аспекты процесса тестирования. Подробно о тест плане мы поговорим в отдельной статье.
  • Тест сценарий и тест кейс, также неравны. Тестовый сценарий (test scenario) – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Хороший тестовые сценарии и тест кейсы в нем всегда следуют некоторой логике, например: типичному использованию приложения, удобству тестирования, распределению функций по модулям и т.д.

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

В чем сложность написания тест кейсов?

Признаться честно, разработка тест кейсов не совсем приятное для многих тестировщиков занятие. И эта неприязнь легко поддается объяснению, ведь их создание требует от Software Testing Engineer следующего:

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

Примечание: Существует мнение, что мозг поглощает около 20% питательных веществ, при том, что занимает около 2% от всего организма. Возможно, поэтому наше «серое вещество», желая сэкономить энергию, предлагает посмотреть любимый сериал, а не обдумать какую-либо проблему.

  • Временных затрат. Оформление тест кейса требует нескольких минут, а, в зависимости от проекта, тестов может понадобиться сотни, а то и тысячи.
  • Выполнение рутинных действий. Создание и управление тест кейсами, зачастую, сопряжено с большим количеством копи-паста. Повторение однотипных действий бывает чрезвычайно утомительным.

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

back to menu ↑

Зачем нужно написание тест кейсов?

написание тест кейсов

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

  • Найти проблемные места в требованиях. Если требование не понятно и не тестируемо в принципе, то написание тест кейса это проявит. Вместе с тем, здесь нужно быть предельно ответственным, нельзя копипастить требования в ТК.
  • Структурировать всю информацию. Логика и структура дадут нам больше шансов тратить меньше времени на вникание в сам тест кейс (одно будет вытекать из другого). Кейсы, максимально замапленные на требования, позволяют потом не искать, откуда же эта информация взята.
  • Ускорить регрессию. Чтобы провести качественный регресс, надо выбрать правильные тест кейсы smoke test, высокоуровневый тест кейсы и тд. Помимо этого, тест кейсы, содержащие максимум вспомогательной информации: логины, пароли – тем самым экономим время.
  • Хранить и собирать информацию. Все сложные настройки должны быть описаны в тест кейсах (логины, пароли, валидация полей, сертификаты, данные карт и тд.). Всегда можно приатачить к кейсам дополнительные файлы с нужной инфой или даже какое-то важное письмо.
  • Отслеживать процесс тестирования. Тут важно отметить следующие особенности, что одна ячейка таблицы=один тест, так четко и без проблем ставим статус. Можно создаем статистику (пройдено /не пройдено, не протестировано)

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

back to menu ↑

Как писать тест кейсы?

как писать тест кейсы

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

  • Подробный или общий?
  • Позитивный или негативный?
  • Простой или сложный?
  • Независимый или объединенный?

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

Подробный или общий тест кейс?

Пример оформления 1

Тест кейс 1 Тест кейс 2
1.In the field A, type 2

2.In the field B, type 3

3.Click Add button.

4.Check value of the field C

4. The value is 5. 1. Verify that the program sums A and B correctly 1. It is so.

Плюсы и минусы

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

Пример оформления 2

Тест кейс
Summing A and B

1.In the field A, enter valid integer

2.In the field B, enter valid integer

3.Click Add button.

4.Check value of the field C

5. Repeat  steps 1-4 for 0, 99999 ( max allowed value), -99999, 1.5, aaa ( invalid values)

4. The value of C field equals A+B

Плюсы и минусы

  • Мы не привязаны к точным значениям
  • Время на поддержку теста сокращается
  • Мы перечисляем конкретные цифры, которые должны быть проверены в тесте

Позитивные или негативные тест кейсы?

Что касается этого вопроса, то здесь следует помнить несколько простых принципа:

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

Помня эти принципы, тестировщику проще не совершить крен в ту или иную сторону будь-то при написании тест кейсов игры или use case testing.

Простые или сложные тест кейсы?

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

  • Простые позитивные
  • Простые негативные
  • Сложные позитивные
  • Сложные негативные

Такая очередность позволяет оптимизировать процесс написания и в дальнейшем легче определять приоритет тест кейса.

Независимые или объединенные тест кейсы?

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

Независимые:

  • Независимые тесты быстро и легко проходим
  • Можно продолжать тестирование, если один тест упал
  • Проходить тесты можно в любом порядке

Объединенные:

  • Сценарии повторяют поведения пользователя
  • Эффективны, когда в 1 шаге у нас по 10 подшагов
  • Мы не создаем каждый раз новые данные, а используем созданное на предыдущем шаге
  • Характерны для интеграционного и системного тестирования

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

Best practices тест кейсы:

  • Используйте простой разговорный язык
  • Всегда используйте полное описание и наименование элементов
  • Не объясняйте Windows basics
  • [button], (?), “field name”, ‘label’
  • “Open”, а не “go”

Теперь пришло время поговорить про поля тест кейса и характерные атрибуты.

back to menu ↑

Что может являться атрибутом тест кейса?

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

Названия атрибутов тест кейса
ID Priority Req. ID Module Sub-Module Test description Expected result Result Comment

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

  1. ID — уникальный идентификатор. Если проставляется руками, то желательно делать его осмысленным. Часто генерируется автоматически.
  2. Priority (приоритет тест кейса) – атрибут, который указывает приоритетность ТК, и принимает значение, согласно принятой в компании классификации (A-B-C-D-E, High-Medium-Lowи тд.)
  3. Req. ID – атрибут, указывающий на связанный с тестом пункт требования
  4. Module – здесь указывается связанный с тест кейсом модуль.
  5. Sub-Module – аналогично предыдущему пункту, только вписывается более мелкая структурная единица.
  6. Test description (описание тест кейсов) – важный атрибут, в котором указывается заголовок (суть теста), условия для его выполнения, шаги и действия после прохождения теста. Test description, соответственно, может и должен содержать:
  • Precondition
  • Steps
  • Postcondition
  1. Expected result (ожидаемый результат тест кейса) – данный атрибут отражает ожидаемый результат по каждому шагу.
  2. Result – сюда заносятся данные о результате пройденного теста (passed/failed и др.)
  3. Comment – сюда можно вносить свои примечания к тесту (вопросы заказчику, какие-либо наблюдения или детали)
back to menu ↑

Написание тест кейсов: примеры

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

Написание тест кейсов: примеры

 

Скачать тест кейс пример оформления в формате xlsx

Еще больше примеров в этой статье

Мы будем рады и вашему мнению

Оставить отзыв

Veraksoff.info
Регистрация
Сбросить пароль
Сравнить товары
  • Всего (0)
Сравнить