tестирование dot com

Савин Роман

ного наличия добродетелей — все в отношении ПО. Мы долж-

ны твердо верить в то, что "был бы код, а баги найдутся".

Пытливый ум внимательного слушателя сразу же сгенерирует

вопрос, на который я тут же отвечу.

Вопрос: «О каком деструктивном мышлении мы можем гово-

рить, если у нас есть такое понятие, как "позитивное тестирова-

ние", и позитивные тест-кейсы настолько важны,

что мы испол-

няем их в первую очередь?»

Ответ: "Позитивное тестирование и принцип первичного испол-

нения позитивных тест-кейсов — это технический аспект. Де-

структивность в мышлении — это аспект ментальный. Даже если

мы создаем тест-кейс с позитивным сценарием, мы должны ис-

кать способ, чтобы обнаружить баги".

Дорогие друзья! Взращивайте и лелейте в себе неисправимый пес-

симизм в отношении идеи о коде, свободном от багов.

Смотрите на код как на виртуальную вещь, которая в процессе

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

несовершенстве мира. Если вы настроите себя на деструктив-

ное мышление в отношении кода, то ваша интуиция вклю-

чится на всю катушку и прекрасные идеи для тест-кейсов

будут стаями роиться в ваших головах, как только вы прочи-

таете спек.

Парочка сладких десертов

— Скажите, а исполнится ли загаданное желание, если я загадаю его,

сидя между двумя программистами?

— Конечно, исполнится, но... будет глючить!

Хирург, инженер и программист сидят в баре и обсуждают, чья про-

фессия является древнейшей:

Хирург: Моя профессия является древнейшей, потому что Богу нужны

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

Инженер: Но еще до этого был хаос, и, чтобы сделать мир из хаоса,

Богу нужны были инженерные знания.

Программист: Ха! Кто же, как вы думаете, создал весь этот хаос?

Нигилистический настрой и практическая методология

177

Теперь, настроенные и решительные, переходим к профессио-

нальным прикладным знаниям, а именно к методологии соз-

дания тест-кейсов (testcase design methodology) (далее — мето-

дология).

В одной из прошлых бесед мы говорили

о первой части методологии — формальной стороне построе-

ния тест-кейса.

Сегодня же речь пойдет

о второй ее части — содержательной стороне тест-кейса.

Искусство создания содержательной части тест-кейсов заключа-

ется в нахождении тех "золотых"

• идей тест-кейсов,

• сценариев и

• ожидаемых результатов,

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

жить больные, багосодержащие места тестируемого ПО.

Какие два этапа составляют процесс, называемый "выбор"?

1. Сначала нам нужно увидеть, что имеется в наличии.

2. Затем, используя некий критерий (-ии), мы выбираем или

не выбираем.

Например, выбирая щенка,

1) мы должны увидеть одного или больше щенков (что имеется в на-

личии) и затем

2) посмотреть, как весело он (они) бегает, как блестят его глазенки

и пр. И посмотрев, решить — брать или не брать.

Подход к выбору сценариев концептуально схож:

1. Что имеется в наличии, мы видим после использования

методов генерирования тестов (methods of test generation);

2. Орудиями отбора являются методы отбора тестов (test se-

lection criterion).

Развертываем:

Методы генерирования тестов:

1. Черновик-чистовик (dirty list-white list);

2. Матричная раскладка (matrices);

3. Блок-схемы (flowchart).

178

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

Методы отбора тестов:

1. Оценка риска (risk estimate);

2. Эквивалентные классы (equivalent classes);

3. Пограничные значения (boundary values).

Методы генерирования тестов

1. Черновик-чистовик (dirty list-white list).

2. Матричная раскладка (matrices).

3. Блок-схемы (flowchart).