количество клеток на которой так велико, что не поддается подсчету.
Допустим, что, согласно лишь нам известной логике, в голову нам уда-
рило выбрать лишь 20 позиций, которые мы опять же зафиксировали
на карточках. Теперь вопрос: покрывают ли 20 карточек 100% теорети-
чески возможных вариантов расположения короля? Нет. Можем ли мы
на 100%о практически реализовать предписания, указанные на 20 кар-
точках? Да.
Обратно к тестированию ПО.
Тестировочное покрытие (test coverage) состоит из двух вещей:
а. Покрытие возможных сценариев.
б. Покрытие исполнения тест-кейсов.
Покрытие возможных сценариев — это в большинстве случаев абст-
рактная величина, так как в большинстве же случаев невозможно даже
подсчитать, сколько понадобится тест-кейсов, чтобы обеспечить
100%-ю проверку ПО (например, попробуйте подсчитать количество
всех теоретически возможных тест-кейсов для тестирования Майкро-
софт Ворда-2003).
Другими словами, в большинстве случаев покрытие возможных сце-
нариев нельзя представить как процентное отношение сценариев, за-
фиксированных в тест-кейсах, ко всем теоретически возможным сце-
нариям.
Покрытие возможных сценариев может увеличиться либо уменьшиться
путем прибавления либо отнятия уникального тест-кейса, т.е. тест-
кейса,
• который тестирует реальный сценарий использования ПО и
• который не является дубликатом другого тест-кейса.
Покрытие исполнения тест-кейсов — это всегда величина кон-
кретная, и выражается она процентным отношением исполненных тест-
кейсов к общему количеству тест-кейсов. Допустим, тест-комплект для
тестирования функциональностей спека #1243 "Новые функциональ-
ности корзины" состоит из 14 тест-кейсов, и если 7 из них исполнены,
то покрытие исполнения тест-кейсов равно 50%>.
Возвращаемся к нашим ящикам.
Симбиоз использования подходов "Черный ящик" и "Белый ящик"
увеличивает покрытие возможных сценариев
• количественно, потому что появляется большее количест-
во тест-кейсов;
150
Тестирование Дот Ком. Часть 2
• качественно, потому что ПО тестируется принципиаль
но разными подходами: с точки зрения пользователя
("Черный ящик") и с точки зрения внутренностей бэк-энда
("Белый ящик").
В реальной жизни белоящичное тестирование проводится либо
самими программистами, написавшими код, либо их коллегами с
программистской квалификацией того же уровня. Кстати, юнит-
тестирование, о котором мы говорили, — это часть white box-тес-
тирования.
СЕРЫЙ ЯЩИК (gray/grey box)
Это подход, сочетающий элементы двух предыдущих подходов, это
• с одной стороны, тестирование, ориентированное на поль-
зователя, а значит, мы используем паттерны поведения поль-
зователя, т.е. применяем методику "Черного ящика";
• с другой — информированное тестирование, т.е. мы знаем,
как устроена хотя бы часть тестируемого бэк-энда, и активно
используем это знание.
Ярчайший пример
Допустим, мы тестируем функциональность "регистрация":
• заполняем все поля (имя, адрес, е-мейл и т.д.) и
• нажимаем кнопку "Зарегистрироваться".
