Тестовый сценарий

Код: ТПО-1

Тестирование ПО: задачи, роли и артефакты

Отправить нам заявку на участие в мероприятииПолучить коммерческое предложение

Описание:

Тренинг, включающий базовые понятия (тестирование, качество, тесты, наборы, проектирование тестов и т.д.), практические примеры и реальный опыт из «боевой» практики наших экспертов

Целевая аудитория:

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

Программа мероприятия:

  • Место тестирования в процессе разработки ПО
  • Определение качества ПО и ИС
  • Заблуждения, связанные с тестированием
  • Цели и задачи тестирования
  • Стратегия в тестировании
  • Требования к процессу тестирования
  • Планирование тестирования
  • Виды тестов
  • Роли в тестировании
  • Описание артефактов тестирования
  • Основные разделы плана тестирования
  • Проектирование тестирования
  • Реализация тестов
  • Выполнение тестирования
  • Оценка тестирования
  • Работа с ошибками
  • Проектный подход в тестировании
  • Управление тестированием

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

Повторное «рождение» термина произошло в радиоэлектронике.

Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.

Автоматизация

Smoke Tests легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация снижает количество ручного труда и поэтому позволяет проводить эти тесты чаще. Чем чаще выполняются тесты, тем раньше становится известно о проблемах, выявляемых этими тестами. Чем раньше становится известно о проблеме, тем легче её устранить. Автоматизация тестирования часто выполняется с помощью средств непрерывной интеграции.

Ссылки

Раздел: Тестирование > Тестовые Артефакты > Тест План (План тестирования)

Тест План (План тестирования)

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Рекомендации по написанию Тест Плана

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

  1. Test Plan Template RUP
  2. Test Plan Template IEEE 829

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

  1. Что надо тестировать?
    • описание объекта тестирования: системы, приложения, оборудования
  2. Что будете тестировать?
    • список функций и описание тестируемой системы и её компонент в отдельности
  3. Как будете тестировать?
    • стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
  4. Когда будете тестировать?
    • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
  5. Критерии начала тестирования:
    • готовность тестовой платформы (тестового стенда)
    • законченность разработки требуемого функционала
    • наличие всей необходимой документации
  6. Критерии окончания тестирования:

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

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

  • Окружение тестируемой системы (описание программно-аппаратных средств)
  • Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
  • Риски и пути их разрешения

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

  1. Мастер Тест План (Master Plan or Master Test Plan)
  2. Тест План (Test Plan), назовем его детальный тест план)
  3. План Приемочных Испытаний (Product Acceptance Plan) — документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований.

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

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

Рецензия и Утверждение

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

  • Ведущий тестировщик
  • Тест менеджер (менеджер по качеству)
  • Руководитель разработки
  • Менеджер Проекта

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

Вывод

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

Наверх

 

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

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

  • функционального тестирования;
  • приемочного тестирования;
  • нагрузочного или стресс-тестирования;
  • исследовательского тестирования;
  • smoke-тестирования и др.

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

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

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

Тестовые сценарии удобно объединять в тест-планы по назначению:

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

Зачастую ручное тестирование превращается в рутину и занимает значительное время, что отрицательно сказывается на скорости выпуска релизов. Автоматизация тестирования позволяет:

  • высвободить ресурсы для проведения более сложных видов тестирования;
  • снизить количество дефектов, доходящих до стадии контроля качества;
  • ускорить выпуск релизов.

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

«Smoke test» — термин, который исходит от электротехники. Это относится к очень простому, очень простому тесту, в котором вы просто подключаете устройство и видите ли дым.

Это ничего не говорит о том, действительно ли устройство работает. Единственное, что он говорит вам, это то, что он не полностью сломан.

Он обычно используется как шаг сэкономить время перед более тщательными регрессионными/интеграционными/приемочными испытаниями, поскольку нет смысла запускать полный testuite, если вещь все равно улавливает огонь.

В программировании термин используется в одном и том же смысле: это очень мелкий простой тест, который проверяет некоторые простые свойства, например: запускает ли программа?

Может ли он распечатать свое справочное сообщение? Если эти простые вещи не работают, нет смысла даже пытаться запустить полный testuite, что иногда может занимать минуты или даже часы.

ответ дан Jörg W Mittag 29 окт. '10 в 23:49

источникподелиться

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

Закрыть меню