tестирование dot com
Шрифт:
говорится, "мухи отдельно, котлеты отдельно" (конечно, до тех
пор, пока нам это удобно).
Пример
На www.testshop.rs можно производить оплату картами VISA и Master-
Card. У нас есть тест-комплект, который мы исполняем из релиза в ре-
лиз (это регрессивное тестирование, о котором мы еще будем много
говорить), называемый "Покупка
Этот тест-комплект был написан на основании спека #1211 и содержит
тест-кейсы для проверки функциональностей оплаты с использовани-
ем VISA и MasterCard.
Для нового релиза написан спек #1422, согласно которому будет на-
писан код для поддержки новой карты — британской Switch.
56
Тестирование Дот Ком. Часть 1
Сначала создаем новый тест-комплект "Покупка с использованием
Switch", затем исполняем и одновременно модифицируем его. Учиты-
вая, что
• после исполнения содержимое тест-комплекта будет стабили-
зировано и
• в нем проверяется та же функциональная часть веб-сайта ("Оп-
лата"),
в данном случае будет логичным сделать его частью тест-комплекта
"Покупка с использованием кредитных карт".
Постановка мозгов
Никто не ожидает, что тест-кейсы будут на 100% "работать" сразу по-
сле написания. Дело в том, что они создаются на основании опека
(или, как это часто бывает, на основании устного пожелания начальни-
ка), и так как мы физически не видим функциональностей этого опека
(код еще не написан), то многие вещи нужно в буквальном смысле
представить себе. Кроме того, как мы уже видели, сами спеки имеют
баги и спек может быть изменен без ведома тестировщика... (об этом
позже).
В общем вариантов множество, и все ведут к тому, что в первый раз
тест-кейсы должны исполняться их автором, задача которого
• если необходимо, добавить новые
• если необходимо, внести изменения по существу, например в
случае, если при создании тест-кейса тестировщик неправильно
понял спек;
• если возможно, удалить лишние тест-кейсы, например, если два
тест-кейса проверяют одну и туже идею, дублируя друг друга;
• сделать тест-кейсы более удобными для поддержки;
• отшлифовать их, что означает сделать формулировки кри-
стально-сверкающе-искристо ясными и точными.
Вот "шапка", которую можно нацепить поверх тест-кейсов.
Author:
Spec ID:
Priority:
Producer:
Developer:
OVERVIEW:
GLOBAL SETUP and ADDITIONAL INFO:
Author — автор тест-кейсов.
Spec ID — номер (или иной уникальный ID) спека. Сам ID дол-
жен быть линком к спеку в локальной сети (об этом мы еще
поговорим).
Priority — приоритет тест-комплекта (например, от 1 до 4), обыч-
но соответствующий приоритету спека.
Producer — продюсер, написавший спек.
Developer — программист, пишущий код в соответствии со спеком.
Искусство создания тест-кейсов
57
В секции Overview вкратце рассказывается, чему посвящен этот
тест-комплект.
Предназначение секции GLOBAL SETUP and ADDITIONAL INFO
аналогично секции тест-кейса SETUP and ADDITIONAL INFO, толь-
ко здесь мы говорим о повторяющихся вещах, которые будем ис-
пользовать в более чем одном тест-кейсе, и вообще о любой дру-
гой полезной информации для всего тест-комплекта.
Вот содержимое файла credit_card_payments.doc, включающего
тест-комплект "Покупка с использованием кредитных карт":
Покупка с
использованием кредитных карт (TS7122)*
Author: