Главная страница

Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин


Скачать 5.26 Mb.
НазваниеПособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
АнкорРоман Савин - тест dot com.pdf
Дата26.04.2017
Размер5.26 Mb.
Формат файлаpdf
Имя файлаРоман Савин - тест dot com.pdf
ТипПособие
#5534
страница12 из 24
1   ...   8   9   10   11   12   13   14   15   ...   24
вводом,
• пиво — выводом,
• щель для жетона и носик для пива — интерфейсом поль-
зователя, а
механизм автопоилки, обменивающий жетон на пиво, —
черным ящиком, так как мы не знали (и для сохранения аппетита не хотели знать), как был устроен изнутри тот столь необходимый для студента аппарат.
В отношении ПО черный ящик, т.е. область незнания, — это не что иное, как тестируемые части бэк-энда (например, код про- граммиста, схема базы данных), составляющие невидимый поль- зователю виртуальный мост, который соединяет
фактический ввод (шаги) и
фактический вывод (фактический результат).
Признаки подхода "Черный ящик":
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 является
1   ...   8   9   10   11   12   13   14   15   ...   24


написать администратору сайта