Текст книги "tестирование dot com"

Автор книги: Роман Савин

сообщить о нарушении

Текущая страница: 8 (всего у книги 17 страниц)

• передать пользователям (релиз-инженер)

средства, которые эти потребности удовлетворят. Этими средст-

вами являются ФУНКЦИОНАЛЬНОСТИ интернет-проекта.

Вот формальное определение:

функциональность (functionality, feature) – это средство для

решения некой задачи.

Примеры из реальной жизни

Функциональность компьютерных колонок «Volume» решает задачу

«Как изменить громкость звука».

Функциональность «Казино» решает задачу "Как незаметно для себя

потратить все отпускные деньги".

Функциональность «Принтер» решает задачу «Как распечатать документ».

134

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

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

Функциональность «Корзина» решает задачу "Как хранить информацию

о товаре, выбранном пользователем".

Функциональность «Добавление товара в корзину» решает задачу "Как

добавить товар в корзину".

Функциональность «Удаление товара из корзины» решает задачу "Как

удалить товар из корзины".

Проверка работы функциональностей называется функциональ-

ным тестированием (functional testing).

Стратегический момент: так как функциональное тестирова-

ние – это ось, вокруг которой вертится деятельность большин-

ства тестировщиков, то, следовательно, вокруг нее же будет

"вертеться " и большинство наших последующих бесед.

Важность функционального тестирования состоит в том, что

функциональности – это не что иное, как продукт, предос-

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

дукт от релиза к релизу кишит багами, то вместе со счастьем

пользователей убывают и прибыли интернет-компании.

Основными источниками знания о функциональностях служат:

• документация...

...в электронном или распечатанном виде – спеки, макеты,

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

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

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

документа" может служить "Инструкция Мастеркард о

формате файлов с транзакциями";

• хомо сапиенс, т.е.

информация постигается через межличностное общение.

Так, в случае возникновения сомнений никогда не мешает

подойти к продюсеру, хлопнуть его по плечу и попросить:

"Старина, будь добр, объясни мне по-простому пункт 146 вот

этого спека". Здоровая дружеская атмосфера в коллек-

тиве – это отличное средство для предотвращения оши-

бок в толковании (идеальной питательной среды для багов);

• сам веб-сайт,

который мы изучаем посредством эксплоринга. Экспло-

ринг (exploring (англ.) – «исследование», «разведка») —

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

пользователя.

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

135

Эксплоринг совершается каждым из нас, когда мы приходим на

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

кнопки, кликая на линки и совершая прочие действия для того,

чтобы понять, как работает та или иная функциональность.

В интернет-компаниях эксплоринг, как правило, применяется в

двух случаях:

• когда написан код и отсутствует документация. Подоб-

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

ходящего в работающую интернет-компанию;

• для самообучения. Например, в крупных интернет-компа-

ниях вновь нанятые тестировщики в течение нескольких

недель проходят тренинг, часть которого посвящена экс-

плорингу.

Кстати, при эксплоринге источником ожидаемого результата слу-

жат наши драгоценные жизненный опыт, опыт работы и другие

ранее перечисленные помощники, не относящиеся к спекам.

Кстати, хорошая идея для тестировщика, помогающая лучше понять

функциональности своего проекта, – это стать обычным пользовате-

лем своего и аналогичных веб-сайтов. Выражение "Eat your own dog

food" («Ешь еду своей собаки») для тестировщика означает "Если ты

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

книги по Интернету".

Идем дальше.

Конечной целью этапа Изучение и анализ предмета тестирова-

ния является получение ответов на два вопроса:

а. Какие функциональности предстоит протестировать?

б. Как эти функциональности работают?

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

этапу цикла.

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

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

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

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

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

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

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

136

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

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

а)

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

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

б)

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

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

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

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

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

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

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

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

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

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

Идем дальше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

137

а)

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

осущест

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

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

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

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

б)

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

следствие

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

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

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

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

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

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

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

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

и б).

Идем дальше.

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

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

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

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

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

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

простому, test preps).

Итак, большая часть нашего дальнейшего общения будет

посвящена двум вещам:

Подготовка к тестированию (testpreparation);

Исполнение тестирования (test execution).

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

Функциональность – это средство для решения некой задачи.

Проверка работы функциональностей называется функциональным

тестированием.

Эксплоринг – это изучение того, как работает веб-сайт с точки зрения

пользователя.

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

Вспомогательные программы ("тулы") пишутся для облегчения исполнения

тест-кейсов.

Мы выделили два основных этапа цикла:

подготовка к тестированию;

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

138

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

7. Исполнение тестирования идет в два этапа:

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

• регрессивное тестирование.

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

1. Почему полезно представлять себе цикл тестирования ПО неза-

висимым от цикла разработки ПО?

2. Назовите источники информации о функциональностях.

3. Что такое эксплоринг и как он помогает в состоянии документа-

ционного вакуума?

4. Назовите два основных элемента стадии подготовка к тестиро-

ванию.

5. Что такое регрессивное тестирование? Назовите две ситуации,

при которых проводится регрессивное тестирование.

6. Почему сначала тестируются новые функциональности?

КЛАССИФИКАЦИЯ ВИДОВ

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

• ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ

• ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

• ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ

• ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ

• ПО КРИТЕРИЮ «ПОЗИТИВНОСТИ» СЦЕНАРИЕВ

• ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ

КОМПОНЕНТОВ

• ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ

• ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ

юбая классификация составляется по определенному при-

Л знаку, например:

• по полу люди делятся (классифицируются) на мужчин и

женщин;

• по наличию кошки люди делятся на тех, у кого кошка

есть, и тех, у кого ее нет;

• по росту люди делятся на группы в зависимости от коли-

чества сантиметров от земли до макушки (например, один

будет в группе "181 см", а другой – в группе "185 см").

Один и тот же субъект может быть одновременно элементом бес-

численного количества классификаций, при этом прекрасно себя

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

пример, дебошир и романтик Сева Б. может одновременно

• быть мужчиной,

• иметь кошку и

• вырасти до 175 см.

139

Классификация видов тестирования

141

Немедленная польза от классификаций в отношении видов тести-

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

информация легче воспринимается, усваивается и запоминается.

Замечу, что видов тестирования существует огромное количе-

ство и мы не будем пытаться объять необъятное, а поговорим

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

любого интернет-проекта.

Сначала перечислим, потом объясним. Объяснения призваны

дать общее понимание каждого из элементов, в то время как по-

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

Формат изложения:

Классификация по этому признаку

состоит из следующих элементов.

Перечисляем:

1. По знанию внутренностей системы:

• черный ящик (black box testing);

• серый ящик (grey box testing);

• белый ящик (white box testing).

2. По объекту тестирования:

• функциональное тестирование (functional testing);

• тестирование интерфейса пользователя (UI testing);

• тестирование локализации (localization testing);

• тестирование скорости и надежности (load/stress/perfor-

mance testing);

• тестирование безопасности (security testing);

• тестирование опыта пользователя (usability testing);

• тестирование совместимости (compatibility testing).

3. По субъекту тестирования:

• альфа-тестировщик (alpha tester);

• бета-тестировщик (beta tester).

4. По времени проведения тестирования:

• до передачи пользователю – альфа-тестирование (alpha–

testing);

– тест приемки (smoke test, sanity test или confidence test);

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

testing);

142

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

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

– тест сдачи (acceptance or certification test);

• после передачи пользователю – бета-тестирование (beta

testing).

5. По критерию «позитивности» сценариев:

• позитивное тестирование (positive testing);

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

6. По степени изолированности тестируемых компонентов:

• компонентное тестирование (component testing);

• интеграционное тестирование (integration testing);

• системное (или энд-ту-энд) тестирование (system or end-

to-end testing).

7. По степени автоматизированности тестирования:

• ручное тестирование (manual testing);

• автоматизированное тестирование (automated testing);

• смешанное/полуавтоматизированное тестирование (semi

automated testing).

8. По степени подготовки к тестированию:

• тестирование по документации (formal/documented testing);

• эд хок-тестирование (ad hoc testing).

Объясняем:

1. По знанию внутренностей системы

• черноящичное тестирование (black box testing);

• белоящичное тестирование (white box testing);

• сероящичное тестирование (grey box testing).

Кстати, в отношении четких дефиниций, водоразделов и прочих

академических штучек до сих пор идут споры.

ЧЕРНЫЙ ЯЩИК (black box)

Должен признаться, что лучшие мгновения моего студенчества

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

а в пивной Коптевского рынка, куда мы с Балмашновым, Гнезди-

ловым, Дебдой, Ермохиным, Илюхиным, Карповым, Назаровым,

Классификация видов тестирования

143

Осмоловским, Сапачевым и Тарасовым вламывались с тубусами

наперевес и за вечер выполняли недельный план по продажам.

Основным элементом Коптевской пивной того времени была так

называемая автопоилка, т.е. аппарат, принимающий жетон и вы-

дающий пол-литра того, что мы тогда считали пивом.

Так вот если перевести манипуляции с автопоилкой на компью-

терный язык, то

• жетон был вводом,

• пиво – выводом,

• щель для жетона и носик для пива – интерфейсом поль-

зователя, а

• механизм автопоилки, обменивающий жетон на пиво, —

черным ящиком, так как мы не знали (и для сохранения

аппетита не хотели знать), как был устроен изнутри тот

столь необходимый для студента аппарат.

В отношении ПО черный ящик, т.е. область незнания, – это не

что иное, как тестируемые части бэк-энда (например, код про-

граммиста, схема базы данных), составляющие невидимый поль-

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

• фактический ввод (шаги) и

• фактический вывод (фактический результат).

Признаки подхода "Черный ящик":

1. Тестировщик не знает, как устроен виртуальный мост.

2. ИДЕИ для тестирования идут от предполагаемых паттер-

нов (pattern – образец) поведения пользователей. Поэтому

подход "Черный ящик" также называют поведенческим.

Разберем первый признак.

1. ТЕСТИРОВЩИК НЕ ЗНАЕТ, КАК УСТРОЕН

ВИРТУАЛЬНЫЙ МОСТ

С одной стороны,

тестировщик имеет преимущество перед программистом, т.е. авто-

ром кода. Давайте будем честны перед собой: мы часто прини-

маем желаемое за действительное. Особенно это касается того,

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

человека. Сколько раз каждый из нас заводил романы с абсолют-

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

144

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

людьми и утешал себя, что it's o'k – притрется, пригладится и

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

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

программиста произвести функциональное тестирование.

Вот перевод постинга на одном из форумов по тестированию:

"Программист не должен проводить тестирование, и давать

релизу зеленый свет. Нужно, чтобы кто-то независимый (чело-

век/отдел) был ответствен за поиск багов и уполномочен "дос-

тавать " программиста до тех пор, пока баг не будет починен.

Дело в том, что я как программист знаю свой код, и если я сам

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

что какие-либо части кода работают по умолчанию и их можно

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

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

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

зователями с моим кодом. С третьей стороны, у меня на тес-

тирование нет времени, и я не понимаю, почему должен проводить

тестирование, если за него платят тестировщикам ".

Реальность – это мир, пропущенный через призму субъективно-

го восприятия. Например, каждый родитель свято верит, что его

ребенок самый умный, талантливый и перспективный. Код – это

дитя программиста, и в своей реальности программист нередко

воспринимает код как априорно непогрешимый.

Вот вам легенда про призму восприятия:

Когда на пути в Индию корабли Колумба остановились перед од-

ним из Карибских островов, индейцы... этих кораблей не увидели,

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

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

предки существовали бок о бок на протяжении тысячелетий. И

лишь шаман, учуяв что-то неладное, несколько дней пристально

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

силуэты испанских фрегатов от привычных океана и неба и не ска-

зал своей пастве: "Опа! Корабли Колумба " (тут, конечно, все сразу

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

деловито погрузили в лодки свиней и поехали менять их на бусы).

Идея, думаю, понятна. Программист пишет, тестировщик тести-

рует, Филипп Филиппыч оперирует, Айседора Дункан танцует, и

никаких разрух.

Классификация видов тестирования

145

Итак, блэк бокс-тестировщику, знающему лишь то, для чего был

написан код (т.е. функциональности), а не как он был написан, легче

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

летворения чаяний которого весь софтверный сыр-бор и начался.

С другой стороны,

блэк бокс-тестирование ведется вслепую, так как ни одна из час-

тей виртуального моста неизвестна. Следствием этого может

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

пишется несколько тест-кейсов.

Итак, в случае с черным ящиком тестировщик не знает, как

устроен виртуальный мост, и это может быть как полезно, так и

вредно для дела.

Разберем второй признак.

2. ИДЕИ ДЛЯ ТЕСТИРОВАНИЯ ИДУТ ОТ ПРЕДПОЛАГАЕМЫХ

ПАТТЕРНОВ (pattern – образец) ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЕЙ

То, что мы называли вводом (шагами), на самом деле является

двумя вещами, которые так же неотрывно связаны, как судьбы

Ромео и Джульетты. Речь идет о

сценариях и

данных для сценариев.

Исполнение тестирования может проходить как при наличии, так

и без тест-кейсов. Так вот в обоих случаях сценарий (scenario) —

это последовательность ДЕЙСТВИЙ для достижения фактиче-

ского результата.

Пример сценария

1. Открой www.main.testshop.rs.

2. Кликни линк «contact us».

Если исполнение тестирования идет по тест-кейсам, то можно ска-

зать, что сценарий тест-кейса – это совокупность шагов тест-кейса.

Данные для сценариев, или просто «данные», – это конкрет-

ные ЗНАЧЕНИЯ ВВОДА, используемые для достижения факти-

ческого результата.

Пример данных

1. Открой www.main.testshop.rs.

2. Введи текст «Затоваренная бочкотара» в поле поиска.

3. Нажми кнопку «Искать».

146

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

В последнем примере шаги 1 —3 (включительно) были сценарием,

а "Затоваренная бочкотара" – данными.

Еще один пример данных

При закрытии счета в одном из интернет-магазинов на последней

странице пользователь должен ответить, почему он закрывает счет.

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

мещен квадрат, куда можно поставить галочку (checkbox). Так вот если

пользователь поставит галочку напротив строк «Служба поддержки» и

«Медленная доставка» и нажмет на кнопку «Закрыть счет», то данными

будет текст "Служба поддержки " и « Медленная доставка».

Совместим знания о сценариях и данных со вторым признаком

подхода "Черный ящик".

Предполагаемые паттерны поведения пользователей – это те

сценарии и данные, которые, как мы ожидаем, будут реализо-

вываться и вводиться пользователями.

Основные источники предполагаемых паттернов поведения поль-

зователей могут быть:

а) напрямую взяты из спека.

Пример

Пункт 12 спека #9548 говорит: "Если на странице с регистрационной

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

кнопку «Зарегистрироваться» показывается та же страница, но с сооб-

щением об ошибке: «Пожалуйста, введите ваш е-мейл» и с изменением

шрифта имени текстового поля «Е-мейл:» на красный цвет".

Напишем тест-кейс.

ИДЕЯ: «Сообщение об ошибке, если при регистрации не указан е-мейл».

Сценарий:

1. Открой wvwv.main.testshop.rs/register.htm.

2. Заполни все текстовые поля кроме «Е-мейл:» действительными

данными (поле «Е-мейл:»должно быть пустым).

3. Нажми на кнопку «Зарегистрироваться».

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

Страница регистрации.

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

Сообщение об ошибке «Пожалуйста, введите ваш е-мейл».

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

Шрифт имени поля «Е-мейл:» изменен на красный цвет.

Кстати, данными для сценария из последнего примера послужили две

вещи: 1) действительный ввод всех полей, кроме е-мейла (мы предпола-

гаем, что лицо, исполняющее тест-кейс, знает легитимные значения ввода),

и 2) пустое поле для е-мейла. Значение ввода "" – это тоже вид данных.

Классификация видов тестирования

147

Давайте для простоты в дальнейшем использовать термин "сце-

нарий" в качестве собирательного образа, т.е. самого сценария

и данных, используемых в нем;

б) найдены путем эксплоринга.

Иногда "брожение" по сайту является лучшим источником для

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

щаться;

в) получены путем применения методики черноящичного

тестирования (black box testing methodology).

Примеры: впереди будет много примеров;

г) подарены интуицией.

Помните, как у Конан Дойля было сказано об инспекторе Лест-

рейде? Примерно так: "Но была единственная вещь, которая ме-

шала ему стать настоящим сыщиком, – у него не было чутья".

А чем мы не сыщики? Интуиция не менее важна для настоя-

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

и опыт работы;

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

Общение, общение и еще раз общение. Самое дорогое – это ин-

формация, и общение – один из главных ее источников. Продю-

сер, программист и тестировщик дают путевку в жизнь одной и

той же функциональности, но каждый смотрит на нее со своей

колокольни, и если нам, тестировщикам, получить мнения това-

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

полезные вещи;

е) др.

Например, мы прочитали статью в Интернете, давшую классную

идею для сценария.

Итак, мы разобрались со вторым признаком подхода "Черный ящик".

Обобщаем.

При подходе «Черный ящик» тестировщик не основывает

идеи для тестирования на знании об устройстве и логике тес-

тируемой части бэк-энда. Идеи формируются путем предпо-

148

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

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

меняться пользователями. Такие сценарии называются пат-

тернами поведения пользователей.

БЕЛЫЙ ЯЩИК (white box)

также известен под именами Стеклянный ящик (glass/clear box),

Открытый ящик (open box) и даже Никакой ящик (по box).

В отличие от "Черного ящика" при подходе «Белый ящик» тес-

тировщик основывает идеи для тестирования на знании об

устройстве и логике тестируемой части бэк-энда.

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

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

бэк-энда, а не определенный паттерн поведения пользователя.

Пример из жизни

Допустим, нужно протестировать проходимость нового российского

внедорожника.

При подходе «Черный ящик» тестировщик садится за руль, выезжает за

кольцевую – в объятия подмосковной осени, находит непролазную ка-

наву, заезжает в нее и пытается выбраться, т.е. он проделывает вещи,

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

вателями таких машин – охотниками, рыболовами и рэкетирами.

При подходе «Белый ящик» тестировщик открывает капот и видит, что

установлена система полного привода фирмы «Джапан моторз», мо-

дель RT6511. Тестировщик знает, что проходимость внедорожника

зависит именно от RT6511 и ее слабое место – это эффективность

при езде по снегу. Что делает тестировщик? Правильно! Выезжает

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

вольствие.

Последний пример не только служит иллюстрацией разницы в

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

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

возможных сценариев.

Идем дальше.

Постановка мозгов

Покрытие возможных сценариев – это одна из частей архиважнейшей

концепции, называемой тестировочное покрытие.

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

Представим себе шахматную доску, состоящую из 64 клеток. Единст-

венная фигура, присутствующая на доске, – белый король. Допустим,

Классификация видов тестирования

149

каждая возможная ПОЗИЦИЯ короля записана на отдельной карточке:

«Поставь белого короля на такую-то клетку». Следовательно, у нас есть

64 карточки, или 100% теоретически возможных вариантов располо-

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

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

добьемся 100%-й практической реализации предписаний, указанных

на карточках.

Теперь усложним задачу и представим, что у нас есть шахматная доска,

количество клеток на которой так велико, что не поддается подсчету.

Допустим, что, согласно лишь нам известной логике, в голову нам уда-

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

на карточках. Теперь вопрос: покрывают ли 20 карточек 100% теорети-

чески возможных вариантов расположения короля? Нет. Можем ли мы

на 100%о практически реализовать предписания, указанные на 20 кар-

точках? Да.

Обратно к тестированию ПО.

Тестировочное покрытие (test coverage) состоит из двух вещей:

а. Покрытие возможных сценариев.

б. Покрытие исполнения тест-кейсов.

Покрытие возможных сценариев – это в большинстве случаев абст-

рактная величина, так как в большинстве же случаев невозможно даже

подсчитать, сколько понадобится тест-кейсов, чтобы обеспечить

100%-ю проверку ПО (например, попробуйте подсчитать количество

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

софт Ворда-2003).

Другими словами, в большинстве случаев покрытие возможных сце-

нариев нельзя представить как процентное отношение сценариев, за-

фиксированных в тест-кейсах, ко всем теоретически возможным сце-

нариям.

Покрытие возможных сценариев может увеличиться либо уменьшиться

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

кейса,

• который тестирует реальный сценарий использования ПО и

• который не является дубликатом другого тест-кейса.

Покрытие исполнения тест-кейсов – это всегда величина кон-

кретная, и выражается она процентным отношением исполненных тест-

кейсов к общему количеству тест-кейсов. Допустим, тест-комплект для

тестирования функциональностей спека #1243 "Новые функциональ-

ности корзины" состоит из 14 тест-кейсов, и если 7 из них исполнены,

то покрытие исполнения тест-кейсов равно 50%>.

Возвращаемся к нашим ящикам.

Симбиоз использования подходов "Черный ящик" и "Белый ящик"

увеличивает покрытие возможных сценариев

• количественно, потому что появляется большее количест-

во тест-кейсов;

150

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

• качественно, потому что ПО тестируется принципиаль

но разными подходами: с точки зрения пользователя

("Черный ящик") и с точки зрения внутренностей бэк-энда

("Белый ящик").

В реальной жизни белоящичное тестирование проводится либо

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

программистской квалификацией того же уровня. Кстати, юнит-

тестирование, о котором мы говорили, – это часть white box-тес-

тирования.

СЕРЫЙ ЯЩИК (gray/grey box)

Это подход, сочетающий элементы двух предыдущих подходов, это

• с одной стороны, тестирование, ориентированное на поль-

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

зователя, т.е. применяем методику «Черного ящика»;

• с другой – информированное тестирование, т.е. мы знаем,

как устроена хотя бы часть тестируемого бэк-энда, и активно

используем это знание.

Ярчайший пример

Допустим, мы тестируем функциональность «регистрация»:

• заполняем все поля (имя, адрес, е-мейл и т.д.) и

• нажимаем кнопку «Зарегистрироваться».

Следующая страница – подтверждение, мол, дорогой Иван Иваныч,

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

Теперь вопрос: если мы видим страницу с подтверждением регистра-

ции, то значит ли это, что регистрация была успешной? Ответ: нет,

так как процесс регистрации с точки зрения нашей системы включает

не только подтверждение на веб-странице, но и создание записи в

базе данных,

т. е. вывод, который стоит проверить, состоит из

• страницы с подтверждением и

• новой записи в базе данных.

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

при регистрации? Например, из технической документации (документ

о дизайне/архитектуре системы, документ о дизайне кода), общения с

программистом, самого кода.

Как видно из последнего примера, подход "Серый ящик" – это

дело хорошее, жизненное и эффективное. Деятельность боль-

шинства профессиональных тестировщиков интернет-проектов

протекает именно в разрезе сероящичного тестирования.

Классификация видов тестирования

151

Пара мыслей вдогонку.

1. Когда мы говорим о поведенческом тестировании, то это не

значит, что тестировщик ограничен набором действий, совер-

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

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

чтобы вообще сделать его возможным.

Пример

При разговоре о формальной стороне тест-кейса мы проверяли баланс

кредитной карты до и после покупки на странице www.main.testshop.rs

/<четыре_последних_цифры_карты>/balance.htm. В реальности поль-

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

организации, выдавшей эту карту (например, www.wellsfargo.com),

а страница balance.htm является специальным кодом, написан-

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

ных карт.

Кстати, тот факт, что тестировщик использует информацию веб-стра-

ницы balance.htm, не означает, что он понимает логику работы кода,

отвечающего за списание денег со счета.

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

нужно было проверить для реального тестирования, послужила

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

Так как ожидаемый вывод – это ожидаемый результат на-

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

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

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

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

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

лишь тратой времени.

2. По объекту тестирования

• Функциональное тестирование (functional testing);

• Тестирование интерфейса пользователя (UI testing);

• Тестирование локализации (localization testing);

• Тестирование скорости и надежности (load/stress/ per-

formance testing);

• Тестирование безопасности (security testing);

• Тестирование опыта пользователя (usability testing);

• Тестирование совместимости (compatibility testing).

152

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