tестирование dot com

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

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

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

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

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

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

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

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

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

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

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

нариям.

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

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

кейса,

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

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

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

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

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

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

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

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

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

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

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

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

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

150

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

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

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

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

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

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

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

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

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

тирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

базе данных,

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

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

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

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

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

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

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

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

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

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

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

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

151

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

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

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

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

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

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

Пример