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

Общение, общение и еще раз общение. Самое дорогое — это ин­формация, и общение — один из главных ее источников. Продю­сер, программист и тестировщик дают путевку в жизнь одной и той же функциональности, но каждый смотрит на нее со своей колокольни, и если нам, тестировщикам, получить мнения това­рищей с двух других колоколен, то можно узнать потрясающе полезные вещи;

е) др.

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

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

Обобщаем.

При подходе "Черный ящик" тестировщик не основывает идеи для тестирования на знании об устройстве и логике тес­тируемой части бэк-энда. Идеи формируются путем предпо-

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. Как мы видели на примере с регистрацией, выводом, который нужно было проверить для реального тестирования, послужила не только страница с подтверждением, но и запись в базе данных. Так как ожидаемый вывод — это ожидаемый результат на­ших тест-кейсов, то огромное значение для эффективности тестирования имеет поиск именно того ожидаемого результа­та, который реально подтвердит, что код работает.Так, если бы в том же самом примере ожидаемым результатом была только страница с подтверждением, то проверка базы данных была бы лишь тратой времени.

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

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

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

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

• Тестирование скорости и надежности (load/stress/ per­formance testing);

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

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

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

152

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

ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ(functional testing)

Уже говорили и еще будем много говорить.

ТЕСТИРОВАНИЕИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

(UI (читается как "ю-ай") testing)

Это тестирование, при котором проверяются элементы интерфей­са пользователя. Мы рассмотрим все основные элементы веб-интерфейса при разговоре о системе трэкинга багов.

Важно понимать разницу между

тестированием интерфейсапользователя и тестированием с помощью интерфейсапользователя.

Пример первого

Проверяем максимальное количество символов, которые можно напе­чатать в поле "Имя" на странице "Регистрация", т.е. проверяем, отве­чает ли конкретный элемент интерфейса, называющийся "одностроч­ное текстовое поле" (textbox), требованию спецификации, которая ука­зывает на максимальное количество символов, которое в этом поле можно напечатать.

Пример второго

Тестируем бэк-энд и с помощью интерфейса создаем транзакцию по­купки, т.е. мы использовали интерфейс пользователя как инструмент для создания транзакции.

ТЕСТИРОВАНИЕ ЛОКАЛИЗАЦИИ

(localization testing)

Многогранная вещь, подразумевающая проверку множества ас­пектов, связанных с адаптациейсайта для пользователей из других стран. Например, тестирование локализации для поль­зователей из Японии может заключаться в проверке того, не вы­даст ли система ошибку, если этот пользователь на сайте зна­комств введет рассказ о себе символами Kanji, а не английским шрифтом.

---

Дата добавления: 2018-05-02; просмотров: 434; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

⇐ Предыдущая20212223242526272829Следующая ⇒

---

Мы поможем в написании ваших работ!