Шаблоны Best Test Case с примерами

 

Что такое тестовый набор?

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

Мы создаем тестовый сценарий как:

  1. Пользователь должен быть зарегистрирован
  2. Перейти на страницу «Загрузить фото»
  3. Нажмите кнопку «загрузить»
  4. Выберите фотографии
  5. Загрузить их

Теперь этот сценарий следует разделить на подробные контрольные примеры, например:

  • Проверьте возможность зарегистрированного пользователя перейти на страницу «Загрузить фото»
  • Проверьте возможность незарегистрированного пользователя перейти на страницу «загрузки фотографий»
  • Проверьте, может ли пользователь нажать кнопку «Загрузить»
  • Открывается ли форма для выбора фотографии и возможности ее закрытия?
  • Что произойдет, если вы не выберете фотографии, выберите другой формат файла (например, видео), выберите фотографии максимального размера и т. Д.
  • Проверьте возможность загрузки фотографий
  • Проверьте, сохранена ли фотография
  • Возможность перезагрузить или удалить фотографии
  • Что происходит с фотографиями в случае исчезновения интернета или выключения устройства
  • Все ли кнопки правильно отображаются в другом месте или в разных операционных системах (если есть разница)

И так далее. Количество тестовых случаев зависит от опыта и воображения тестера.

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

Структура тестового примера

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

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

Поле тестового примера Описание
Идентификатор
теста
Каждый тестовый пример
должен иметь уникальный идентификатор.
Тест Приоритет

Это полезно при выполнении
теста.

  • Низкий
  • Средняя
  • Высоко
Тест
разработан
Имя тестера
Дата проведения теста разработана Дата, когда был разработан тест
Тест
выполнен
Кто выполнил тест
(тестер)
Дата проведения теста Дата, когда необходимо выполнить тест
Имя или
название теста
Заголовок должен
содержать краткое, раскрывающее описание контрольного примера, например
«Reset Pass».
Название важно, потому что это часто первое или
единственное, что вы видите при сканировании списка тестовых
случаев.
Четкие заголовки являются ключом, помогающим тестировщикам
быстро находить правильные тестовые примеры.
Описание / Краткое содержание теста Подробное описание теста. В этом разделе вы также можете настроить
категории, чтобы организовать тестовые случаи в логические группы.
Предварительное
условие
Любое требование,
которое необходимо выполнить перед выполнением этого теста
Тестовые шаги

Раздел «Шаги тестирования» дает
тестировщику нумерованный список шагов, которые необходимо выполнить в
системе, что упрощает понимание тестового примера.

Рекомендуется иметь 3-8 этапов теста на
один тест. Слишком много шагов мешают разработчикам и тестировщикам
воспроизвести шаги, когда отчет об ошибке подан против контрольного
примера.

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

Типы тестовых случаев

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

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

Положительный

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

Например, положительные тестовые примеры проверяют все правильные форматы электронных писем, которые должны соответствовать следующим требованиям.

I. Первая часть адреса электронной почты до @ может содержать любой из следующих символов ASCII:

  • латинские буквы независимо от регистра – от а до я
  • цифры от 0 до 9
  • специальные символы # $% & ‘* + – / = ^ _` {|} ~!?
  • указать «.», но если он находится среди других символов
  • пробел и символы «(): <> @ [\] допускается с ограничениями для комментария или указания имени и т. д.

II. Доменная часть – после символа @ может содержать:

  • латинские буквы независимо от регистра – от а до я
  • цифры от 0 до 9, если доменное имя содержит не только числовые значения
  • и «-», если он находится между другими символами

Отрицательный

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

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

Граничное значение

Чтобы проверить значения на обеих сторонах ограничений. Один из них относится к положительным тестам, другой к отрицательным. Лучше их изолировать, чтобы не пропустить. Эти тесты свидетельствуют о том, что у вас есть собственный дизайн тестов, который вы можете увидеть ниже. Например, вы нашли в документации информацию о том, что пароль должен содержать не менее 6 и не более 60 символов. Поэтому вы должны выяснить, что произойдет, если вы введете 5, 6, 60 и 61 символ. Не забудьте про случай, когда поле пустое.
Если документация не описывает такие ограничения, вы можете предложить их сами, обсуждая с командой!

Интеграция

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

Тестирование локализации

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

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

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

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

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

Пример 1

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

Название проекта:Банковская
система
Прецедент
Идентификатор теста: BU_001 Тест разработан:<Имя>
Тест Приоритет(Низкий/средний/высокий):Med Дата разработки теста:<Дата>
Название модуля:Экран входа в банк Тест выполнен:<Имя>
Название теста:Проверьте функциональность входа в систему в банке Дата проведения теста:<Дата>
Описание:Подтвердите логин с действительным именем пользователя и паролем
Предпосылки:Пользователь имеет действительное имя пользователя и парольЗависимости:
шаг Тестовые шаги Тестовые данные ожидаемый результат Фактический результат Статус (Проход / Неудача) Заметки
1 Перейдите на
страницу входа
 

Пользователь должен иметь возможность войти

Пользователь
должен иметь возможность войти
Проходить
2 Введите действительное имя пользователя Пользователь =[email protected] Учетные данные могут быть введены Как и ожидалось Проходить
3 Введите действительный
пароль
Пароль: 1234 Учетные данные могут
быть введены
Как и ожидалось Проходить
4 Нажмите на кнопку Войти Пользователь вошел Пользователь успешно вошел Проходить
Пост-условия: Пользователь подтвержден с базой данных и успешно войти в учетную запись. Детали сеанса учетной записи заносятся в базу данных.

Пример 2

Если в ненужных деталях, этот пример экономит время и ресурсы.

Идентификатор теста BU_001 Описание тестового примера Проверьте функциональность входа в систему в банке
Создано <Имя> Рассмотрено <Имя> Версия 2,1
Журнал QA Tester’s Просмотрите комментарии от Билла, включенные в версию 2.1
Имя тестера <Имя> Дата тестирования 1-Jan-2017 Контрольный пример (Пройдено / Не выполнено / Не
выполнено)
Проходить
S # Предварительные
условия:
S # Тестовые
данные
1 Доступ к браузеру Chrome 1 Userid = mg12345
2 2 Pass = df12 @ 434c
3 3
4 4
Тестовый сценарий Подтвердите при вводе
действительного идентификатора пользователя и пароля, клиент может войти
Шаг № Детали шага Ожидаемые результаты Фактические результаты Pass / Fail / Not execute / Suspended
1 Перейдите на
http://Banksite.com
Сайт должен
открыться
Как и ожидалось Проходить
2 Введите идентификатор
пользователя и пароль
Учетные данные могут
быть введены
Как и ожидалось Проходить
3 Нажмите Отправить Cutomer вошел в
систему
Как и ожидалось Проходить
4

Пример 3

При необходимости, точные данные испытаний будут проверены, это будет удобно использовать. Который имеет «Набор данных» для разных вариантов данных.

Идентификатор теста TC_Functionality_01
приоритет Высоко
Dercription Проверьте функциональность входа в систему
модуль Главный экран входа
Приготовленный <Имя> Дата Подготовлено 1-Jan-2017
Проверено <Имя> Дата тестирования 13-Jan-2017
Тестовые занятия
нет Описание шага ожидаемый результат Фактический результат
1 Перейдите на http://BankSite.com Сайт
должен открыться
Как
и ожидалось
2 Введите логин и пароль
3
Тестовые наборы данных
Тип данных Набор данных 1 Набор данных 2 Набор данных 3
Логин или электронная
почта
User1 [email protected] Пользователь2
пароль 123456 123456 QWERTY @! $
Результат теста Проходить

Пример 4

Я БЫ

Резюме

меры

ожидаемый результат

Фактический результат

Заметки

1 Загрузить фото как незарегистрированный пользователь
Предварительные шаги 1.Открытое приложение
1,1 Проверьте, если
Загрузить
страница фотографий открывается страница фотографий открывается
1.Нажмите ссылку Загрузить
фото
Страница загрузки
фотографии не открывается
страница не открывается
Потерпеть поражение Ошибка # 1
2 Загрузить фото как зарегистрированный пользователь
Предварительные шаги 1.Открытое приложение
Выполните вход с правильными данными
2,1 Проверьте, открывается ли
страница загрузки фото
открывается страница с фотографией
1. Нажмите на ссылку Загрузить фото Загрузить фото
страница
открывается
Проходить
2,2 Проверьте, может ли пользователь вернуться 1.
Нажмите на ссылку Загрузить фото
2. Нажмите кнопку Назад
Предыдущая страница открывается
2,3 Проверьте, работает ли
кнопка «Загрузить»
1. Нажмите на ссылку Загрузить фото
2.
Нажмите на кнопку Загрузить
Откроется форма для выбора
фотографии
Проходить

Все шаблоны можно скачать здесь:

Шаблон_01

Шаблон_02

Шаблон_03

Шаблон_04