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).
1. "ЧЕРНОВИК-ЧИСТОВИК"
Это самый простой и практичный метод. Суть проста. Два этапа:
а. Черновик (dirty list)
В процессе (и/или после) прочтения спека, эксплоринга ПО и/или
получения информации о ПО другим способом, не анализируя и
отдавшись вдохновению и фантазии, мы просто набрасываем на
лист бумаги (или в файл Ворда), являющийся черновиком (dirty
list), ВСЕ идеи, связанные с тестированием, которые только могут