Савин Роман. Тестирование dot com

Подождите немного. Документ загружается.

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

199

Почему нам хватило только 5 сценариев, мы поговорим через

минуту.

А сейчас давайте посмотрим, сколько возможных вариантов

только для позитивных тестов у нас потенциально есть для

класса 2:

30 000 (по количеству копеек в 299,99 руб. плюс один слу-

чай, когда потрачено 200,00 руб.).

Наша методика позволила обойтись лишь 3 тестами (пози-

тивные тесты: а, б, в), которыми мы по сути протестировали

30 000 значений. По-моему, выглядит впечатляюще.

Теперь о 5 сценариях, которых было достаточно для позитивного

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

Представим себе схематично логику кода для решения вопроса о

скидке для класса 2:

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма /100 х 2.

Теперь рассмотрим, как каждый из наших тест-кейсов точечно

бьет по возможным проблемам кода. Прошу особого внимания —

ничего сложного нет, но много нюансов.

Тест-кейс Код с

выделенной жирным шрифтом

частью,

которая проверяется данным тестом

Возможная проблема кода, разоблачаемая тестом, и

пример проблемы

Ожидаемый результат

а. Сначала тестируется

нижний предел данного

класса (если нижний

предел имеется):

200

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2

Ошибка в знаке равенства и/или сумме нижнего

предела.

Пример (знакравенства перед 200,00 пропущен):

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2

2% от 200

200

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

б. Затем тестируется

верхний предел

данного класса (если

верхний предел

имеется):

499,99

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2

Ошибка в знаке равенства и/или сумме верхнего

предела.

Пример (499,00 вместо 499,99): ЕСЛИ сумма >

200,00 И CVMMQ < 499,00, ТО скидка = сумма/100

х 2

2% от 499,99

в. Затем тестируется

любое значение

внутри данного

класса:

315,11

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2

Ошибка в знаках больше (>) и меньше (<). Пример

(больше вместо меньше и меньше вместо больше):

ЕСЛИ сумма < 200,00 И сумма > 499,00: ТО скидка

= сумма/100 х 2

2% от 315,11

г. Затем тестируется

верхний предел класса,

непосредственно

предшествующего

данному классу

(если предшествующий

класс имеется):

199,99

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2

Тонкий момент. Здесь мы проверяем две вещи:

1. Наличие скачка от верхнего предела предьщущего

класса к нижнему пределу нашего класса.

Это делается для следующей ситуации. Допустим,

программист напечатал 100,00 вместо 200,00: ЕСЛИ

сумма > 100,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2. Если сделана такая

ошибка, то она не будет обнаружена ни тестом а, ни

тестом б, ни тестом е.

2. Логическое "И", так как если бы у нас было "ИЛИ":

ЕСЛИ сумма > 200,00 ИЛИ сумма < 499,99,

ТО скидка = сумма/100 х 2, то к данному классу

принадлежало бы любое в принципе возможное

значение

Скидка

не равна

2% от 199,99

д. Затем тестируется

нижний предел класса,

непосредственно

следующего

за данным классом

(если следующий

класс имеется):

500,00

ЕСЛИ сумма > 200,00 И сумма < 499,99,

ТО скидка = сумма/100 х 2

1. Наличие скачка от верхнего предела нашего класса

к нижнему пределу следующего за ним класса. Это

делается для следующей ситуации. Допустим,

программист напечатал 599,99 вместо 499,99: ЕСЛИ

сумма > 200 И сумма < 599,99, ТО скидка =

сумма/100 х 2

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

201

Если сделана такая ошибка, то она не будет

обнаружена ни тестом а, ни тестом б, ни тестом в,

ни тестом г.

2. Проверяется логическое "И", так как если бы у

нас было "ИЛИ":

ЕСЛИ сумма > 200,00 ИЛИ сумма < 499,99,

ТО скидка = сумма/100 х 2, то к данному

классу принадлежало бы любое в принципе

возможное значение

Скидка

не равна

2% от 500,00

Замечу, что для удобства в понимании мы производили тестиро-

вание класса 2 изолированно от его собратьев.

И теперь, поняв и разобравшись, давайте рассмотрим, как нам про-

тестировать все эквивалентные классы данного спека:

Класс Значение

Ожидаемая

ставка скидки, %

Класс 1 0 0

100,00

199,99

Класс 2

200,00

315,11

499,99

Класс 3

500,00

659,23

999,99

Класс 4 1000,00 4

3265,26

4999,99

Класс 5 5000,00 5

5075,00

Итого 14 тест-кейсов для тестирования всех возможных значе-

ний. Неплохо. Очень даже неплохо!

На сером фоне 5 значений ввода, которые мы использовачи для

изолированного тестирования нашего любимого кяасса 2. Прошу

отметить следующую вещь: теперь, когда мы тестируем класс 2

202

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

вместе с окружающими его собратьями, для класса 2 доста-

точно 3 тест-кейсов, так как случаи г. (199,99) и д. (500,00)

покрываются при тестировании класса 1 и класса 3 соответ-

ственно.

Мы рассмотрели самый сложный вариант пограничного тестиро-

вания, когда мы проверяли эквивалентные классы, включающие

множества значений. Зато теперь, пройдя огонь, воду и медные

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

когда эквивалентный класс содержит только одно значение.

Пример

Возьмем индекс, который должен быть равен 6 цифрам (Индекс_эл 005 из

табл. 1, матричной раскладки поля "Индекс"). Применяем метод

тестирования пограничных значений:

а. 6

б. 6

в. 6

г. 5

Д. 7

Таким образом, у нас есть:

• один позитивный тест 6 и

• два негативных теста 5 и 7.

Мы применяем метод

• как обособленно (тестирование скидок),

так и

• в сочетании с другими методами генерирования и отбора

тестов (использование пограничных значений на матрич

ной раскладке поля "Индекс").

Идея о возможности обособленного или интегрированного

применения, конечно, относится к каждому из методов гене-

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

Это все о пограничном тестировании.

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

к тестированию:

Не методы должны управлять вашей подготовкой, а вы должны

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

те тест-кейсы, которые с высокой вероятностью могли бы

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

203

найти баги. Для этого нужно в совершенстве владеть каждым

из методов. И только практика может отточить ваши навыки.

Практикуйтесь и помните о примере с шахматами, которым

мы поставили себе мозги в начале нашей сегодняшней беседы.

Сегодня мы узнали и изучили:

Краткое подведение итогов

1. Хороший тестировщик — это не просто некий работник компании,

который может порвать код на части своими прикладными

знаниями по тестированию. Хороший тестировщик — это неис-

правимый циник, нигилист и Фома неверующий — все в отно-

шении кода.

2. Код — это убежище багов.

3. Суть тестирования заключается в поиске багов.

4. В отношении методов генерирования тестов:

• при использовании метода Черновик-чистовик: Черновик —

это полет мысли и вдохновения, "мозговой штурм", не огра-

ниченный суетными приличиями бренного света. Чистовик —

это подчищенный, причесанный и классифицированный Чер-

новик;

• матричная раскладка может быть лишь простой классифика-

цией элементов на табл. 1, а может и бесконечно углубляться

в дебри комбинаций и комбинаций. Главное помнить, что

матричная раскладка создается для тестирования, а не тес-

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

• блок-схемы — это дочери добродетели под именем "Нагляд-

ность".

5. В отношении методов отбора тестов:

оценка риска основывается на том, что мы пытаемся влезть в

шкуру наших пользователей и бросить наши ограниченные ре-

сурсы не на бессмысленное кликанье правыми, левыми и даже

средними кнопками наших ошалевших мышек, а на тестирование

вещей, реально приоритетных для пользователей.

6. Методы генерирования тестов и методы отбора тестов —

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

свой (свои) инструмент (-ты).

Вопросы для самопроверки

1. Какой настрой должен быть у тестировщика?

2. Что такое код?

3. Что такое тестирование?

4. Какие вы знаете методы генерирования тестов?

204

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

5. Какие вы знаете методы отбора тестов?

6. В чем суть метода Черновик-чистовик?

7. Есть ли ограничение на количество таблиц в матричной рас-

кладке?

8. Каково основное преимущество блок-схем?

9. Кто может помочь тестировщику в оценке риска?

10. Какая практическая польза от приоритезации при оценке риска?

11. Приведите 5 правил тестирования пограничных значений. Какие

из них позитивные, а какие — негативные?

12. Что нам дает комбинирование методов?

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ

ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ

БАГОВ

• ЧТО ТАКОЕ СИСТЕМА ТРЭКИНГА БАГОВ

• АТРИБУТЫ БАГА

• ПРОЦЕССТРЭКИНГА БАГОВ

ак мы знаем, цель исполнения тестирования — поиск багов.

Но на самом деле найти баг — это только часть работы (хотя

и самая сложная). После того как баг обнаружен,

• нужно занести его в систему трэкинга багов и

• после того как он зафиксирован:

а) проверить, на самом ли деле он был зафиксирован и

б) не повредила ли починка этого бага другие части на

шего ПО.

Кстати, как мы помним, а и б называются регрессивным тес-

тированием.

Процесс, который начинается с занесения бага в систему трэкин-

га багов (Bug Tracking System), называется процессом трэкинга

багов (Bug Tracking Procedure), и для удобства понимания всей

стадии исполнения тестирования мы начнем именно с него.

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

Важная оговорка: нет двух интернет-компаний, у которых про-

цесс трэкинга багов и все нюансы системы трэкинга багов были

бы идентичны. Каждый, как известно, извращается как хочет.

Моя цель — развить ваше понимание предмета так, чтобы

205

Жизнь замечательных багов

207

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

ченные знания к любым процессам и системам, которые встре-

тятся вам на пути.

Забудем о тестировании ПО.

Допустим, мы совершаем тест-драйв на автомобиле, который со-

бираемся купить. Проверяем ускорение, вхождение в поворот,

удобство панели управления и сотню других важных вещей. По-

сле этого садимся за стол и записываем вещи, которые обманули

ожидания (т.е. баги), на пронумерованные страницы новой тетради

в клеточку. Один баг на одну страницу.

Например

на странице под номером 1 пишем: "Неудобно пользоваться навигаци-

онной системой";

на странице под номером 2 пишем: "Задержка в ускорении после на-

жатия на педаль акселератора"; на странице под номером 3 пишем:

"Слишком маленький багажник".

Наша ни в чем не повинная тетрадь на самом деле является не

только выброшенными на ветер деньгами, но и простейшей вер-

сией того, что называется системой трэкинга багов (СТБ).

Вспомним о тестировании. Опять же на примитивном уровне СТБ

может представлять собой простой текстовый файл с записями о

багах, который лежит на интранете и доступен участникам цикла

разработки ПО.

Итак, концептуально СТБ — это инфраструктура, позволяющая

• создавать,

• хранить,

• просматривать и

• модифицировать

информацию о багах.

Существует множество профессиональных СТБ — от бесплатной

Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test

Director by Segue), и естественно, что интернет-компании исполь-

зуют для трэкинга багов не тетрадки или текстовые файлы, а именно

специальное ПО, непосредственно созданное для трэкинга багов.

О таком ПО и процессе трэкинга багов мы и поговорим сегодня.

Каждый баг, занесенный в СТБ, представляет собой вирту-

альную учетную карточку

208

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

Каждая такая карточка существует не сама по себе, а как часть

процесса трэкинга багов (далее — Процесс).

С каждым багом, занесенным в СТБ, начинается новый Процесс.

Вопрос: Как определить, на какой стадии Процесса находится

каждая конкретная карточка?

Ответ: Ничего нет проще — нужно просто посмотреть на ее ат-

рибуты.

Пример

Одним из атрибутов является статус бага. Статус может принимать

одно из трех значений:

• Open (открыт),

• Closed (закрыт) либо

• Re-open (повторно открыт).

Пример Процесса

После того как баг заносится в СТБ, его статус автоматически стано-

вится "Open"; после того как баг зафиксирован и регрессивное тести-

рование подтвердило успех починки, мы меняем статус на "Closed";

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

то мы меняем "Closed" на "Re-Open".

Важно понять, что Процесс как формальный свод правил перви-

чен и такой зверь, как СТБ, приобретается именно как инстру-

мент для материализации Процесса.

Другими словами, после инсталляции ответственный товарищ

настраивает СТБ в соответствии с процессом, выбранным компа-

нией, а не наоборот.

В примере со статусом мы взглянули на процесс с высоты птичь-

его полета. Опустимся же на землю и увидим все подробности.

Допустим, мы нашли баг. Сам факт нахождения бага, даже если

это критический дефект, не имеет никакого значения и веса, пока

вы не сообщили об этом баге. Два вопроса:

Кому сообщить?

Как сообщить?

Кому? Программисту, если это баг кода, либо продюсеру, если

это баг спека.

Как? Здесь есть много путей: можно позвонить, послать е-мейл,

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