Как Писать Тестовые Случаи: Окончательное Руководство С Примерами - Моя ХАТА
Разное 

Как Писать Тестовые Случаи: Окончательное Руководство С Примерами

avtor

В этом подробном практическом руководстве по написанию тестовых случаев я подробно описал, что такое тестовый случай, его стандартное определение и методы проектирования тестовых случаев manual test case.

Что такое тестовый случай?

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

Тестовый случай — это набор инструкций о том,” как » проверить конкретную тестовую цель/цель, которые при выполнении скажут нам, удовлетворено ли ожидаемое поведение системы или нет.

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

#1) TestRail

#2) Тестмонитор

Управление онлайн-тестированием на высшем уровне. Революционно просто.

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

Что Такое Тестовый Случай И Как Писать Тестовые Случаи?

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

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

Приведенные выше ресурсы должны дать нам основы процесса написания тестов.

Уровни процесса написания теста:

  • Уровень 1: на этом уровне вы будете писать основные случаи из доступной спецификации и документации пользователя.
  • Уровень 2: это практическая стадия, на которой случаи написания зависят от фактического функционального и системного потока приложения.
  • Уровень 3: это этап, на котором вы сгруппируете некоторые случаи и напишете процедуру тестирования . Процедура тестирования-это не что иное, как группа небольших случаев, возможно, максимум 10.
  • Уровень 4: автоматизация проекта. Это сведет к минимуму взаимодействие человека с системой, и таким образом QA может сосредоточиться на текущих обновленных функциональных возможностях для тестирования, а не оставаться занятым регрессионным тестированием.

Зачем мы пишем тесты?

Основная цель написания кейсов-проверка тестового покрытия приложения.

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

Как писать тестовые случаи?

Поля:

  • Идентификатор тестового случая
  • Блок для тестирования: что нужно проверить?
  • Допущения
  • Тестовые данные: переменные и их значения
  • Шаги, которые необходимо выполнить
  • ожидаемый результат
  • Реальный результат
  • Pass/Fail
  • Комментарии

Базовый формат заявления тестового случая

Проверьте
, используя [имя инструмента, имя тега, диалоговое окно и т. д.]
с [условиями]
на [что возвращается, показывается, демонстрируется]

Verify: используется в качестве первого слова тестового оператора.
Использование: для определения того, что тестируется. Вы можете использовать здесь «ввод» или «выбор» вместо использования в зависимости от ситуации.

Для любого применения вам необходимо охватить все типы тестов, а также:

  • Функциональные кейсы
  • Негативный случай
  • Граничные случаи

При написании этих текстов все ваши ТС должны быть простыми и понятными .

************************************************

Советы По Написанию Тестов

Одним из наиболее частых и основных видов деятельности тестировщика программного обеспечения (SQA/SQC person) является написание тестовых сценариев и кейсов.

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

Важные Факторы, Связанные С Процессом Написания:

а) ТКС подвержены регулярному пересмотру и обновлению:

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

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

Кроме того, во время регрессионного тестирования некоторые исправления и/или рябь требуют пересмотренных или новых ТКС.

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

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

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

в) ТКС склонны к кластеризации и дозированию:

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

Аналогично, в соответствии с бизнес-логикой AUT, один TC может способствовать нескольким условиям тестирования, а одно условие тестирования может состоять из нескольких TCs.