Поделиться через


Руководство по созданию планов тестирования и наборов тестов

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

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

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

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

  • Гибкая разработка

  • Прочие методологии разработки

Дополнительные сведения о планах тестирования и наборах тестов, а также о способах их создания см. в разделе Определение действий тестирования с помощью планов тестирования.

Гибкая разработка

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

  1. Пользователю необходимо выбрать несколько продуктов на веб-сайте и добавить их в покупательскую корзину (спринт 1).

  2. Пользователю необходимо приобрести товары из покупательской корзины с помощью кредитной карты (спринт 1).

  3. Пользователю необходимо сохранить сведения в процессе приобретения товаров, чтобы ускорить их покупку в следующий раз (спринт 2).

  4. Пользователю необходимо войти в свою учетную запись при приобретении товаров, чтобы извлечь свои личные сведения и не вводить их еще раз (спринт 2).

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

Планы тестирования и наборы тестов для гибкой разработки

Настройка проекта

  1. В начале проекта создайте следующие планы тестирования (на основе планируемого количества спринтов).

    1. План тестирования для спринта 1

      Этот план будет использоваться для тестирования описаний функциональности пользователей спринта 1.

    2. План тестирования для спринта 2

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

    3. Основной план тестирования

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

  2. Определите конфигурации тестов, которые необходимо использовать для тестирования описаний функциональности пользователей. Например, может понадобиться протестировать описания функциональности пользователей при выполнении приложения в браузере Internet Explorer 8 (конфигурация 1) и в браузере Firefox 3.5 (конфигурация 2). Затем создайте эти конфигурации тестов с помощью Microsoft Test Manager. Дополнительные сведения о создании конфигураций тестов см. в разделе Определение матрицы тестов с помощью конфигураций тестов.

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

    Примечание

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

Тестирование на спринте 1

  1. Добавьте описания функциональности пользователей 1 и 2 для спринта 1 в план тестирования для спринта 1, чтобы создать два набора тестов, основанных на требованиях. Дополнительные сведения о создании наборов тестов из описаний функциональности пользователей см. в разделе Практическое руководство. Добавление требований или сведений, полученных от пользователей, в план тестирования.

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

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

    1. Описание функциональности пользователей 1: добавить один товар в покупательскую корзину.

    2. Описание функциональности пользователей 1: удалить товар из покупательской корзины.

    3. Описание функциональности пользователей 2: купить один товар из покупательской корзины.

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

      Примечание

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

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

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

  6. Если описание функциональности пользователей готово для тестирования в ходе выполнения спринта, задайте для состояния набора тестов в плане тестирования значение Выполняется. Дополнительные сведения см. в разделе Практическое руководство. Изменение состояния тестирования наборов тестов.

    Примечание

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

  7. В представлении Выполнение тестов можно выбрать тестовые точки, предназначенные для выполнения. Тестовая точка — это связь тестового случая с конфигурацией теста. Например, на компьютере тест-инженера A установлен только Internet Explorer 8. Тест-инженер A выбирает все тестовые точки для описания функциональности пользователей, которые должны выполняться в браузере Internet Explorer 8, и запускает эти точки. Тест-инженер B выбирает все тестовые точки для описания функциональности пользователей, которые должны выполняться в браузере Firefox 3.5, и запускает их.

  8. После завершения всех ручных и автоматических тестов из набора тестов для данного описания функциональности пользователей, можно проверить состояние тестирования для этого набора тестов. Выберите представление Выполнение тестов в действии Тестирование. Можно также запустить создание отчетов, чтобы узнать состояние. В зависимости от требований к качеству, установленных для каждого спринта, можно оценить степень выполнения задач тестирования в спринте. Дополнительные сведения о создании отчетов из Microsoft Test Manager см. в разделе Отчеты о ходе выполнения планов тестирования.

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

  10. В плане тестирования для спринта 2 создайте набор тестов с именем "Регрессия". Затем добавьте в этот набор тестов плана тестирования для спринта 2 тестовые случаи, которые определены для тестов регрессии.

Тестирование на спринте 2

  1. Добавьте описания функциональности пользователей 3 и 4 для спринта 2 в план тестирования для спринта 2, чтобы создать два набора тестов, основанных на требованиях.

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

    1. Описание функциональности пользователей 3: создать учетную запись для входа.

    2. Описание функциональности пользователей 3: оформить заказ без создания учетной записи для входа.

    3. Описание функциональности пользователей 4: выполнить вход в учетную запись (в этот тестовый случай можно добавить параметры, чтобы выполнить вход с различными учетными данными).

    4. Описание функциональности пользователей 4: пользователь забыл пароль.

    5. Описание функциональности пользователей 4: просмотреть заказы для учетной записи.

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

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

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

  5. Если описание функциональности пользователей готово для тестирования в ходе выполнения спринта, измените состояние набора тестов на значение Выполняется. Затем выполните ручные и автоматические тесты из набора тестов для данного описания функциональности пользователей.

    Примечание

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

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

  7. Выполните все тесты производительности или комплексные тесты, соответствующие этому спринту.

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

  9. Скопируйте набор тестов "Регрессия" из плана тестирования спринта 2 в план тестирования для следующего спринта (спринта 3). Затем добавьте в этот набор тестов плана тестирования для спринта 3 тестовые случаи, которые определены для тестов регрессии. Дополнительные сведения о копировании наборов тестов из другого плана тестирования см. в разделе Практическое руководство. Копирование наборов тестов из другого плана тестирования.

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

Прочие методологии разработки

Если гибкая методология не используется, то задачи разработки и тестирования, скорее всего, основаны на функциях. Однако вместо описаний функциональности пользователей можно также использовать требования. Если используются требования, можно реализовать подход, описанный в разделе "Гибкая разработка", и создать планы тестирования для конкретных вех, а не для спринтов, а затем добавить в них требования. Например, можно создать план тестирования "Бета-версия 1", который содержит все требования для бета-версии 1, добавленные в качестве наборов тестов. Затем можно добавить в эти наборы тестов приемочные тестовые случаи и модульные тесты и связать тестовые случаи с требованиями. Дополнительные сведения см. в разделе Практическое руководство. Добавление требований или сведений, полученных от пользователей, в план тестирования. Дополнительные сведения о добавлении модульных тестов в план тестирования см. в разделе Практическое руководство. Связывание автоматического теста с тестовым случаем или Создание тестовых случаев из сборки автоматических тестов.

При использовании более функционально-ориентированного подхода в веб-приложении могут иметься следующие функции:

  1. Покупательская корзина (альфа).

  2. Вход (альфа).

  3. Оформление (бета-версия 1).

  4. Просмотр заказов (бета-версия 1).

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

Руководство по наборам тестов на основе функций

Настройка проекта

  1. В начале проекта создайте следующие планы тестирования (на основе планируемого количества вех).

    1. Альфа

      Этот план используется для тестирования функций, которые будут доступны в альфа-версии.

    2. Бета-версия 1

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

  2. Определите конфигурации тестов, которые необходимо использовать для тестирования этих функций. Например, может понадобиться протестировать данные функции при выполнении приложения в браузере Internet Explorer 8 (конфигурация 1) и в браузере Firefox 3.5 (конфигурация 2). Затем создайте эти конфигурации тестов с помощью Microsoft Test Manager. Дополнительные сведения о создании конфигураций тестов см. в разделе Определение матрицы тестов с помощью конфигураций тестов.

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

    Примечание

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

Тестирование альфа-версии

  1. Добавьте в план тестирования альфа-версии набор тестов для функции "Покупательская корзина" и набор тестов для функции "Вход". Их можно создать как статические наборы тестов, а затем добавить в них тестовые случаи. Дополнительные сведения о добавлении тестовых случаев в статический набор тестов см. в разделе Практическое руководство. Создание наборов тестов и управление ими.

    Важно!

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

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

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

    1. Покупательская корзина: добавить один товар в покупательскую корзину.

    2. Покупательская корзина 1: удалить товар из покупательской корзины.

    3. Вход: войти в учетную запись пользователя.

      Дополнительные сведения о добавлении тестовых случаев в набор тестов см. в разделе Добавление тестового случая в набор тестов.

      Примечание

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

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

  5. Если функция готова для тестирования на этапе альфа-версии проекта, задайте для состояния набора тестов в плане тестирования значение Выполняется. Дополнительные сведения см. в разделе Практическое руководство. Изменение состояния тестирования наборов тестов.

    Примечание

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

  6. В представлении Выполнение тестов можно выбрать тестовые точки, предназначенные для выполнения. Тестовая точка — это связь тестового случая с конфигурацией теста. Например, на компьютере тест-инженера A установлен только Internet Explorer 8. Тест-инженер A выбирает все тестовые точки для описания функциональности пользователей, которые необходимо выполнить в браузере Internet Explorer 8, и запускает эти точки. Тест-инженер B выбирает все тестовые точки для описания функциональности пользователей, которые должны выполняться в браузере Firefox 3.5, и запускает их.

  7. После завершения всех ручных и автоматических тестов из набора тестов для данной функции, можно проверить состояние тестирования для этого набора тестов в представлении Выполнение тестов действия Тестирование. Можно также запустить создание отчетов, чтобы узнать состояние. В зависимости от требований к качеству, установленных для тестирования альфа-версии, можно оценить степень выполнения задач тестирования. Дополнительные сведения о создании отчетов из Microsoft Test Manager см. в разделе Отчеты о ходе выполнения планов тестирования.

Тестирование бета-версии 1

  1. Скопируйте наборы тестов из плана тестирования альфа-версии в план тестирования бета-версии 1. Дополнительные сведения о копировании наборов тестов из другого плана тестирования см. в разделе Практическое руководство. Копирование наборов тестов из другого плана тестирования.

  2. При использовании статических наборов тестов добавьте в план тестирования бета-версии 1 набор тестов для функции "Оформление" и набор тестов для функции "Просмотр заказов". Если используются наборы тестов на основе запросов для путей к областям, все тесты, создаваемые для пути к области 1 или 2, будут автоматически добавлены в наборы тестов, скопированные из плана тестирования альфа-версии.

  3. Добавьте набор тестов с названием "Комплексные функции" в план тестирования бета-версии 1. В этот набор тестов можно добавить тестовые случаи для тестирования комплексных сценариев, включающих несколько функций.

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

    1. Оформление: оформить товары из покупательской корзины.

    2. Оформление: оформить заказ без создания учетной записи для входа.

    3. Вход (дополнительный тестовый случай): пользователь забыл пароль.

    4. Просмотр заказов: просмотреть заказы для учетной записи.

    5. Комплексные функции: добавить товар, выполнить вход и оформить.

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

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

  6. Если функция готова для тестирования на этапе бета-версии 1, измените состояние соответствующего набора тестов на значение Выполняется. Затем выполните ручные и автоматические тесты из набора тестов для данной функции.

    Примечание

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

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

  8. Выполните все комплексные тесты, необходимые для бета-версии 1.

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

См. также

Задачи

Краткое руководство по ручному тестированию с использованием Microsoft Test Manager

Основные понятия

Определение действий тестирования с помощью планов тестирования