Читаем tестирование dot com полностью

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

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

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

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

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

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

точках? Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

нариям.

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

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

кейса,

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

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

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

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

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

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

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

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

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

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

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

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

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

150

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

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

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

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

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

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

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

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

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

тирования.

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

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

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

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

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

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

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

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

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

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

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

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