Базовая схема тест-плана.

Теперь, когда вы узнали про требования, базис теории и терминологию тестирования программного обеспечения, пришло время заняться тест-планами. В тестпланах содержится полный план тестирования тестируемой системы. Затем они выполняются, т. е. человек или автоматизированный инструмент тестирования проходит все шаги тест-плана, и его результаты сравниваются с тем, что получено на самом деле. Иными словами, мы будем проверять соответствие ожидаемого поведения системы (то, что мы написали в нашем тест-плане) тому поведению, которое мы наблюдаем (то, что на самом деле выполняет система).

Тест-план по своей сути является просто набором тест-кейсов. Тест-кейсы — это отдельные тесты, которые составляют тест-план. Давайте предположим, что вы создаете тест-план для тестирования нового приложения, которое говорит вам, является ли ваш кофе слишком горячим, чтобы его пить. Маркетологи нашего гипотетического приложения любят холодный кофе и решили не создавать никакой функционал, сообщающий о том, что температура кофе слишком низкая. Имеются два требования:

FUN-COFFEE-TOO-HOT — если измеренная температура кофе составляет 80 °C или выше, на экране приложения должно отображаться сообщение "СЛИШКОМ ГОРЯЧО";

FUN-COFFEE-JUST-RIGHT — если измеренная температура кофе составляет меньше 80 °C, на экране приложения должно отображаться сообщение "САМОЕ ТО".

Как мы может разработать тест-план для нашего приложения по измерению температуры кофе? Есть одно входное значение — измеренная температура кофе — и два возможных выходных, одно из набора ["СЛИШКОМ ГОРЯЧО", "САМОЕ ТО"]. Мы проигнорируем, что большинство людей посчитают, что кофе температуры 7 °C далеко не "САМОЕ ТО".

Единственное входное значение и одно из двух возможных выходных значений являются простым случаем разбиения класса эквивалентности, поэтому давайте разобьем эти классы эквивалентности:

JUST-RIGHT — [–INF, –INF + 1, ..., 79, 80] → "САМОЕ ТО";

TOO-HOT — [81, 82, ..., INF– 1, INF] → "СЛИШКОМ ГОРЯЧО".

Нашими граничными значениями являются 80 и 81, т. к. они отмечают разделение между двумя классами эквивалентности. Давайте также использовать два внутренних значения: 57 °C для класса "САМОЕ ТО" и 93 °C для класса "СЛИШКОМ ГОРЯЧО". Для этого конкретного примера тест-плана мы проигнорируем неявные граничные значения бесконечности и отрицательной бесконечности (или, в представлении системы, MAXINT и MININT).

Используя эти значения и общее представление, что мы хотим протестировать, мы можем начать создавать тест-кейсы. Хотя в разных инструментах и компаниях применяют различные шаблоны для ввода тест-кейсов, существует относительный стандарт, который может быть использован или модифицирован для большинства проектов:

1. Идентификатор, такой как "16", "DB-7" или "DATABASE-DROP-TEST", который однозначно идентифицирует тест-кейс.

2. Тест-кейс — описание тест-кейса и определение, что он тестирует.

3. Предусловия — любые предусловия для состояния системы или мира перед началом теста.

4. Входные значения — любые значения, напрямую подаваемые на вход в тесте.

5. Шаги исполнения — фактические шаги теста, которые должны быть выполнены тестировщиком.

6. Выходные значения — любые значения, полученные на выходе теста.

7. Постусловия — любые постусловия состояния системы или мира, которые должны быть истинны после выполнения теста.

Не беспокойтесь, если у вас возникли какие-либо вопросы по поводу этих определений. В дальнейшем мы рассмотрим их более глубоко и приведем примеры.