Вход/Регистрация
tестирование dot com
вернуться

Савин Роман

Шрифт:

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

Эта стадия требует от тестировщика наибольшего творчества и

профессионализма, так как именно на ней решается множество

головоломок, отвечающих на один простой вопрос: "Как будем

тестировать?", причем качество продукта (а значит, и счастье поль-

зователей) напрямую зависит от, не побоюсь сказать, мудрости

найденных решений.

136

Тестирование Дот Ком. Часть 2

Мудрость найденных решений проявляется в двух вещах:

а)

кратких, простых и изящных путях для проверки

функциональностей;

б)

компромиссе между

объемом тестирования, который возможен в теории;

объемом тестирования, который возможен на практике.

Ответы на "один простой вопрос" предстают перед

миром в виде тест-документации (test documentation),

ядро которой составляют наши любимые тест-кейсы. Во

многих случаях создание тест-документации

сопровождается написанием тестировщиком вспо-

могательных тулов (tool — компьютерная программа),

которые облегчают исполнение тестирования.

Идем дальше.

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

Суть исполнения тестирования — это практический

поиск багов в написанном коде с использованием

тест-кейсов, созданных ранее.

Исполнение функционального тестирования выглядит

следующим образом:

сначала идет проверка новых функциональностей по

новым тест-кейсам. Кстати, давайте вспомним, что во

многих случаях новые тест-кейсы редактируются,

проходя обкатку первым исполнением;

затем проверка старых функциональностей по старым

тест-кейсам.

То же самое, но в профессиональной терминологии:

тестирование новых функциональностей (new feature

testing) и соответственно

регрессивное тестирование (regression testing).

Мы исполняем тест-кейсы, рассчитывая найти баги.

Давайте еще раз вспомним, что

после нахождения бага тестировщик заносит запись о

нем в систему трэкинга багов;

после того, как программист починил баг,

тестировшик проверяет:

Цикл тестирования ПО

137

а)

действительно ли баг был починен. Проверка

осущест

вляется путем исполнения шагов, которые ранее приве

ли к багу, или, в профессиональной терминологии, пу

тем генерации ввода, который привел к выводу, не со

ответствующему ожидаемому результату;

б)

не появились ли новые баги как нечаянное

следствие

изменения кода при починке. Проверка осуществляется

путем тестирования функциональностей, работа кото

рых могла быть затронута починкой.

Тестирование, исполняемое в пунктах а) и б), также

называется регрессивным тестированием (bug regression

testing). Соответственно выражение "regress that bug"

(проведи регрессивное тестирование этого бага)

означает, что нужно последовательно исполнить пункты а)

и б).

Идем дальше.

Давайте сделаем небольшое обобщение.

Так как этапы 1. Изучение и анализ предмета

тестирования и

2. Планирование тестирования переплетены между собой, мы

объединим их в контейнер знания, который называется

подготовка к тестированию (test preparation или, по-

  • Читать дальше
  • 1
  • ...
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • ...

Ебукер (ebooker) – онлайн-библиотека на русском языке. Книги доступны онлайн, без утомительной регистрации. Огромный выбор и удобный дизайн, позволяющий читать без проблем. Добавляйте сайт в закладки! Все произведения загружаются пользователями: если считаете, что ваши авторские права нарушены – используйте форму обратной связи.

Полезные ссылки

  • Моя полка

Контакты

  • chitat.ebooker@gmail.com

Подпишитесь на рассылку: