Текст книги "tестирование dot com"
Автор книги: Роман Савин
Жанры:
Интернет
,сообщить о нарушении
Текущая страница: 3 (всего у книги 17 страниц)
2. Инструкция по тому, как жарить, парить и варить несчаст-
ных из пункта 1.
Первая часть рецепта нужна для того, чтобы повар мог знать
заранее, видеть в одном месте все необходимые составляющие
блюда и иметь их под рукой, когда "настанет день и час". В
общем выделение подготовительной части удобно, логично и
практично.
В подготовительную часть тест-кейса могут включаться:
• данные о существующем эккаунте пользователя (legacy user
account) или инструкции по созданию нового эккаунта (new
user account);
• другие данные, используемые в тест-кейсе, например атри-
буты используемой кредитной карты;
• запросы к базе данных (SQL queries), используемые в тест-
кейсе;
• комментарии в помощь тестировщику, например о ню-
ансах, которые могут встретиться при исполнении тест-
кейса;
• другие вещи, облегчающие исполнение и поддержку тест-
кейса (о поддержке мы еще поговорим).
ИСТОРИЯ РЕДАКТИРОВАНИЯ (Revision History)
Очень полезная вещь.
Пример
Допустим, у Макса Крылова живет попугай-жако Вася. Макс учит его
хорошим фразам:
– «Вася хороший»;
– «Amicus Plato, sed magis arnica Veritas» ("Платон мне друг, но истина
дороже");
– «Beatles forever» («ВИА „Битлз“ будет вечно жить в наших сердцах»).
42
Тестирование Дот Ком. Часть 1
Приходит друг Лежа и, пока Макс на правах радушного хозяина несется
к ларькам станции метро «Юго-Западная» и обратно, учит альтерна-
тивной мудрости честно впитывающего знания Васю:
– «Все козлы»;
– «Simia quantum similis turpissima bestia nobis!» ("Как похожа на нас
мерзейшая тварь – обезьяна!");
– «Move bitch, get out the way» («Уйди с дороги, противная»).
В итоге после возвращения домой Макса встречает не добрый, милый
попугайчик, а негативно настроенная машина, и вечером ему (Максу)
придется доказывать своей жене, что это не он, а подлец Леха изменил
лексикон бедолаги Василия.
Для того чтобы иметь сведения о рождении и истории развития
каждого тест-кейса, мы ведем лаконичный журнал изменений,
где отражаем: Кто? Что? Зачем? Когда? Почему?
Атрибуты истории редактирования:
• Created on
<кем>;
• Modified on
та> <кем>;
• Change – Что, зачем и почему было изменено. В наших
примерах мы не печатаем само слово «change», а просто
заполняем значение этого атрибута в поле справа от
«Created on...» или «Modified on...».
Давайте создадим тест-кейс с картой, используя только что полу-
ченные знания по полезным атрибутам тест-кейса:
ТС ID/Priority
CCPG0001
1
IDEA: Оплата может быть произведена картой VISA SETUP and
ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Наименование товара: book117 Данные
карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 778
SQL1: select result from cc_transaction where id = <номер заказа>;
Revision History
Created on: 11/17/2003 by О.Тарасов
Новый тест-кейс
Искусство создания тест-кейсов
43
Execution part
PROCEDURE
EXPECTED RESULT
1. Открой www.main.testshop.rs
> «10»
2. Введи имя пользователя.
3. Введи пароль.
4. Нажми кнопку «Войти».
5. Введи наименование товара в поле
поиска.
6. Нажми кнопку «Найти».
7. Кликни линк «Добавить в корзину».
8. Кликни линк "Корзина".
9. Кликни линк «Оплатить».
10. Выбери вид карты.
11. Введи номер карты.
12. Введи срок окончания действия.
13. Введи CVV2.
14. Нажми кнопку «Завершить заказ».
15. Запиши номер заказа
16. Запроси базу данных с SQL1
и запиши результат
Идем дальше.
Тест-кейсы, управляемые данными
Основной плюс нового тест-кейса с картой заключается в том, что
нам не нужно вносить изменения в ШАГИ, чтобы протестиро-
вать по тому же сценарию другие карты. Единственное, что
нам нужно, – это модифицировать исходные ДАННЫЕ.
Таким образом, если кроме VISA нам нужно протестировать по
тому же сценарию еще две карты, то мы
• делаем сору один раз;
• paste два раза;
• в каждом из новых тест-кейсов переписываем только пять
подчеркнутых значений, проживающих в шапке тест-кейса и
секции ожидаемого результата (меняем и ID тест-кейса – ТС ID,
который, как мы помним, должен быть всегда уникальным):
VISA
9999-5148-2222-1277
12/07
778
10
44
Тестирование Дот Ком. Часть 1
Такой вид тест-кейса называется data-driven (буквально "управ-
ляемый данными"), т.е. когда данные и инструкции по их при-
менению не смешаны, а разделены и слинкованы.
Поддерживаемость тест-кейса
Новый тест-кейс с картой хорош. Все при нем – и data-driven, и
удобочитаемый формат, и полезные атрибуты. Проблема в том,
что веб-сайт, а особенно его часть, именующаяся интерфейсом
пользователя {User Interface или просто UI– «ю-ай»), очень часто
меняется.
Пример
Кнопка «Войти» из шага 4 легко может быть переименована во «Вход».
Следовательно, если у нас есть 3 тест-кейса, то нужно внести 3 измене-
ния. А что, если у нас 500 тест-кейсов, где упоминается кнопка «Войти»,
и эти тест-кейсы разбросаны по разным документам, как мои одно-
классники по свету? Вносить 500 изменений? Скажете: "Ерунда, можно
догадаться". Но таких маленьких изменений будут десятки!!! И посте-
пенно ваши тест-кейсы будут либо хиреть без поддержки, либо потреб-
лять на поддержку уйму времени.
Пример
А что, если не имя кнопки, а сам путь, по которому вы добираетесь до
фактического результата, претерпел изменения? Например, шаги 7 и 9
станет разделять не линк «Корзина», а еще несколько дополнительных
линков и кнопок, появившихся в новой версии www.testshop.rs.
В общем проблема понятна. И имя ее – maintainability (поддер-
живаемость), т.е. насколько легко и просто можно изменить
тест-кейс при изменениях в ПО. Не думать о поддерживаемо-
сти тест-кейсов – значит не думать о завтрашнем дне, что, не-
смотря на полезность для духовной жизни, все-таки плохо для
бизнеса.
Если мы разобьем шаги нашего нового тест-кейса с картой на ло-
гические модули, получим:
1. Вход в систему (логин – log in).
2. Поиск товара.
3. Добавление товара в корзину.
4. Оплата.
5. Фиксация номера заказа.
6. Запрос базы данных.
Искусство создания тест-кейсов
45
Почему бы нам не выбросить из тест-кейса детали по следующим
позициям?
1. Вход в систему
В общем-то можно догадаться, куда ввести имя пользователя,
куда пароль и на какую кнопку нажать, тем более что в данном
случае мы не тестируем процесс логина, это было или будет сде-
лано при исполнении соответствующего тест-кейса, сейчас мы
просто грубо и бесцеремонно используем логин, легкомысленно
надеясь, подобно покупателю российского автопрома, что все
будет чики-пики.
2. Поиск товара
Все из предыдущего пункта применимо и здесь. Кроме того, до-
пустим, что book117 была удалена из нашей базы данных подлы-
ми завистниками и подхалимами. Что же нам – в отчаянии рвать
на себе волосы и кричать, что мы заблокированы? Нет, мы просто
превентируем такую ситуацию тем, что не будем давать имени
конкретного товара. Что найдется, то найдется (так как то, что
найдется, в данном случае значения не имеет).
3. Добавление товара в корзину
Концепция из "1. Вход в систему" применима и здесь.
4. Оплата
Концепция из "1. Вход в систему" применима и здесь.
О'к, с оплатой я, пожалуй, немного переборщил – не факт, что
будет абсолютно очевидно, как провести ее, и шаги все же потре-
буются.
Здесь появляется другая загвоздка: если мы производим оплату в
сотнях тест-кейсов, т.е. сотни раз включаем в тест-кейс те же
семь шагов (8—14 включительно), то при изменении даже в од-
ном из этих шагов нам придется переписывать эти сотни тест-
кейсов...
Не проще ли вынести шаги, повторяющиеся от тест-кейса к
тест-кейсу, во внешний документ и вместо них включить в
тест-кейс лишь один шаг-ссылку «Произведи ОПЛАТУ
КАРТОЙ из секции «SETUP and ADDITIONAL INFO»»? Поступив
46
Тестирование Дот Ком. Часть 1
таким образом, мы сэкономим громадное количество часов рабо-
чего времени, так как при необходимости менять шаги нужно
будет только в одном месте!
Кстати, «оплата картой» – это линк к страничке в локальной сети с со-
ответствующей инструкцией, называемой, например, "Как произвести
оплату кредитной картой".
Кстати, хорошей идеей является создание в локальной сети вашей
компании мини-веб-сайта департамента качества, где наряду с веб-
страничками с
• контактной информацией работников департамента,
• пинками к файлам с тест-комплектами,
• другой полезной информацией
расположится и внутреннее Пособие для тестировщиков (QA Knowl-
edge Base), где кроме прочего будут задокументированы повторяю-
щиеся сценарии.
Теперь обобщим уже известные нам мероприятия по улучшению
поддерживаемости тест-кейса:
1. Сделать тест-кейс data-driven.
2. Не описывать шаги по явно очевидным сценариям (напри-
мер, логин).
3. Не давать конкретных деталей, если они не играют роли
при исполнении тест-кейса (например, имя товара).
4. Вынести во внешний документ повторяющиеся сценарии
(например, семь шагов оплаты).
Ну, за поддерживаемость!
ТС ID/Priority
CCPG0001
1
IDEA: Оплата может быть произведена картой VISA SETUP and
ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 778 SQL1: select result from cc transaction where id
= <номер заказа>;
Revision History
Created on: 11/17/2003 by О.Тарасов
Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
искусство создания тест-кейсов
47
Execution part
PROCEDURE
EXPECTED RESULT
1. Открой www.main.testshop.rs
> «10»
2. Войди в систему.
3. Найди любой товар.
4. Добавь товар в корзину.
5. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO
6. Запиши номер заказа
7. Запроси базу данных с SQL1
и запиши результат
Идем дальше.
Сколько ожидаемых результатов
может быть в одном тест-кейсе?
Тест-кейсом проверятся только одна конкретная вещь, и в иде-
альном варианте для проверки этой вещи достаточно предусмот-
реть в тест-кейсе только один ОР, и если бы я был теоретиком, а
не практиком тестирования, то сказал бы, что ни в коем случае
нельзя включать в тест-кейс более одного ОР.
ВОТ вам случай из практики
Допустим, что в соответствии с пунктом 12.6 документа "Дизайн кода
для спека #6522" признаком того, что оплата была успешно прове-
дена картой VISA, будет одновременное наличие не одного, а двух
условий:
1. Значение «10» в соответствующей колонке соответствующей строки в
базе данных.
2. Уменьшение баланса на счете с картой VISA на сумму, равную сумме
оплаты.
То есть получается, что для тестирования одной вещи ("Оплата
может быть произведена картой VISA") нужно проверить соответ-
ствие жизненной реальности двум ожидаемым результатам.
У нас есть два пути:
1. Разложить идею тест-кейса на две идеи и создать два тест-кейса.
2. Оставить идею тест-кейса неприкосновенной и включить в один
тест-кейс два ОР, т.е. у нас складывается ситуация,
48
Тестирование Дот Ком. Часть 1
когда исполнение тест-кейса будет иметь положительный
исход, только если ОБА фактических результата совпадут
с соответствующими им ожидаемыми результатами.
Вот как будет выглядеть визуально путь 2:
ТС ID/Priority
CCPG0001
1
IDEA: Оплата может быть произведена картой VISA SETUP and
ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 778 SQL1: select result from cc transaction where id
= <номер заказа>; Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/1277/balance.htm
Revision History
Created on: 11/17/2003 by О.Тарасов
Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй
ожидаемый результат с целью
удостоверения в снятии денег со счета
Execution part
PROCEDURE
EXPECTED RESULT
1. Запиши баланс счета карты
S> "10"
2. Открой www.main.testshop.rs
3. Войди в систему.
4. Найди любой товар.
5. Добавь товар в корзину.
6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO
(!!! запиши полную сумму заказа:
).
7. Запиши номер заказа
8; Запроси базу данных с SQL1.
9. Запиши баланс счета карты
> Шаг 1-Шаг 6
Как будет проходить исполнение этого тест-кейса?
Искусство создания тест-кейсов
49
Прошли восемь шагов. Остановились. Проверили. Затем
прошли девятый шаг. Остановились. Проверили.
Исход исполнения этого тест-кейса будет считаться положитель-
ным только при одновременной истинности двух условий:
1. ФР после исполнения шага 8 = "10" и
2. ФР после исполнения шага 9 = Шаг 1 – Шаг 6 (т.е. значе-
ние из Шага 1 минус значение из Шага 6).
В теории лучше было бы разбить нашу идею тест-кейса на две
части и создать два отдельных тест-кейса:
1. IDEA: "Правильное значение вставляется в базу данных
при использовании VISA".
2. IDEA: «Верная сумма списывается с баланса карты».
И если есть возможность, то ЛУЧШЕ сделать именно два тест-
кейса, НО на практике во многих случаях имеет смысл включить
в тест-кейс 2 или больше ОР, так как:
• у вас может просто не быть времени на написание, испол-
нение и поддержку двух тест-кейсов*;
• сэкономленное время можно потратить на написание, ис-
полнение и поддержку тест-кейса, которым мы бы прове-
рили другую вещь**.
Если у нас есть один случай, когда можно совместить два ОР, то напи-
сание, исполнение и поддержка двух тест-кейсов не представляет труда.
А что, еслиу нас появляются сотни дополнительных тест-кейсов?..
В результате такой экономии мы с течением времени создаем десятки
новых тест-кейсов, которые помогают нам провести более тщательное
тестирование.
Я работал с тест-кейсами, включающими более одного ОР, в
течение многих лет, проводя тестирование сложнейшего ПО,
связанного с финансовыми транзакциями, и могу сказать,
что 2 или больше ОР в одном тест-кейсе – это нормальная
практика.
Идем дальше.
Во многих случаях, когда несколько ожидаемых результатов про-
сятся в один тест-кейс, нужно проверить
• значение(-я) на веб-странице и
• значение(-я) в базе данных,
те. нужна проверка снаружи и изнутри или на front end и back end.
50
Тестирование Дот Ком. Часть 1
Постановка мозгов
Front end (читается как «фронт-энд») – это непосредственный интер-
фейс пользователя, т.е. текст, картинки, кнопки, линки и прочие вещи,
которые пользователь видите окне веб-браузера или е-мейл клиента.
Back end (читается как «бэк-энд») – это ПО и данные, находящиеся за
фасадом фронт-энда: HTML-код веб-страницы, веб-сервер, код при-
ложения, база данных и т.д.
В последнем примере мы непосредственно "разговаривали"
• с фронт-энд ом – в шаге 5, когда добавляли товар в корзину;
• с бэк-эндом – в шаге 8, когда запрашивали базу данных.
Проблемные тест-кейсы
Теперь посмотрим, какие недостатки вы должны выжигать из
своих тест-кейсов каленым железом.
1. Зависимость тест-кейсов друг от друга.
2. Нечеткая формулировка шагов.
3. Нечеткая формулировка идеи и/или ожидаемого результата.
1. ЗАВИСИМОСТЬ ТЕСТ-КЕЙСОВ ДРУГ ОТ ДРУГА
Зависимость – это антоним независимости. Независимость тест-
кейса выражается в том, что он не связан с другими тест-кейсами.
Пример
Тест-кейс 1:
Шаги:
1. Зайти в комнату.
2. Подойти к стулу.
3. Открыть правый внешний карман рюкзака.
4. Засунуть руку в правый внешний карман рюкзака.
Ожидаемый результат: Граненый стакан.
Тест-кейс 2:
Шаги:
1. Зайти в комнату.
2. Подойти к стулу.
3. Открыть левый внешний карман рюкзака.
4. Засунуть руку в левый внешний карман рюкзака.
Ожидаемый результат: Огурец.
Как видно, шаги 1 и 2 сейчас одинаковы и всегда будет искуше-
ние улучшить то, что и так хорошо.
Искусство создания тест-кейсов
51
Пример
Тест-кейс 1:
Шаги:
1. Зайти в комнату.
2. Подойти к стулу.
3. Открыть правый внешний карман рюкзака.
4. Засунуть руку в правый внешний карман рюкзака.
Ожидаемый результат: Граненый стакан.
Тест-кейс 2:
Шаги:
1. Смотри шаги 1 и 2 из тест-кейса 1.
2. Открыть левый внешний карман рюкзака.
3. Засунуть руку в левый внешний карман рюкзака.
Ожидаемый результат: Огурец.
Так вот, таких вещей (имеется в виду шаг 1 тест-кейса 2) нужно
избегать, так как:
• тест-кейс 1 может быть удален из-за ненадобности или
• шаги по тестированию наличия стакана (в тест-кейсе 1)
могут быть изменены (например, стакан лежит в другом
рюкзаке, который находится на кухне).
В обоих случаях будет непонятно, как исполнить тест-кейс 2, так
как
• у нас или нет шагов 1 и 2 из тест-кейса 1, или
• они стали неправильными (с субъективной точки зрения
тест-кейса 2).
Другим распространенным случаем является допущение, что ПО
или база данных уже приведены к нужному состоянию, так как
были исполнены предыдущие тест-кейсы.
Пример
В тест-кейсе X мы создаем транзакцию покупки книги. В тест-кейсе Y
мы, допуская, что тест-кейс X был успешно исполнен, проверяем
атрибут успешности транзакции покупки книги, не создавая саму транз-
акцию («Зачем напрягаться, когда она уже создана?»). В итоге мо-
жет произойти ситуация, когда транзакция покупки книги не создана,
так как
• тест-кейс X был удален;
• тест-кейс X был модифицирован так, что он создает транзакцию
другого типа;
• тест-кейс X не создал транзакции по объективной причине (на-
пример, не работал соответствующий код).
52
Тестирование Дот Ком. Часть 1
Как результат, во всех трех случаях мы не можем исполнить тест-
кейс Y, так как данных, на которые он опирается, просто не суще-
ствует.
Таким образом, хороший тест-кейс характеризуют:
• отсутствие ссылок на другие тест-кейсы;
• независимость от «следов», оставленных другими тест-
кейсами в нашем ПО или базе данных.
Следовательно, если у нас в документе А есть 10 тест-кейсов:
тест-кейс 1, тест-кейс 2, ..., тест-кейс 10, то доказательством неза-
висимости каждого из тест-кейсов будет тот факт, что их без
ущерба для тестирования можно всегда исполнять в любом
порядке, например, тест-кейс 10, затем тест-кейс 2, затем тест-
кейс 6 и т.д. Принцип, думаю, понятен.
Согласен, что повторение шагов или подготовительной части тест-
кейса кажется порой тупым занятием, но все-таки преимущества
независимого тест-кейса перекрывают напряг операции скопиро-
вал—вставил.
2. НЕЧЕТКАЯ ФОРМУЛИРОВКА ШАГОВ
Пример
«Пойди туда, не знаю куда».
На шаги тест-кейса можно смотреть, как на инструкцию "Как
пройти" (или "Как проехать").
Пример
Если американцу, который в Москве первый раз, сказать (с видом
москвича в пятом колене), что Красная площадь находится «за ГУМом»,
то он бессмысленно потратит много времени в поисках «загума» в путе-
водителе. Если же черкнуть ему е-мейльчик с инструкцией:
1. Выйди из «Националя».
2. На улице поверни направо.
3. Не поднимая глаз, пройди мимо первой стайки барышень.
4. Не поднимая глаз, пройди мимо второй стайки барышень.
5. Спустись налево в подземный переход.
6. Следуй указателям на стенах с надписью «Красная площадь»,
то он не только найдет Красную площадь и купит там прапорскую
ушанку с гнутой кокардой, но и избежит обвинений в сексуальном хар-
расменте, которые на его родине вещь очень даже серьезная.
Искусство создания тест-кейсов
53
Кстати,
• шаги 1 – 5 включительно – это точные инструкции, а
• шаг 6 – это отсылка к инструкциям, хранящимся в другом месте
(помните, мы говорили о внутреннем Пособии для тестировщи-ков
с шагами для повторяющихся сценариев?).
Итак, перечисляющиеся в тест-кейсе шаги должны быть объ-
ективно четкими и ясными.
Нужно помнить,
• то, что очевидно для вас сейчас, может стать совершен
но непонятным через пару месяцев.
Так, сокращенные шаги с нерасшифрованными аббревиа-
турами и прочими веселыми прибамбасами, понятными
вам сейчас, могут впоследствии стать китайской грамотой
для вас самих, так что проще будет написать тест-кейс за-
ново, чем пробираться через дебри неосмотрительно сде-
ланных описаний;
• тест-кейс, который не может быть исполнен никем,
кроме его автора, должен быть публично сожжен, рас
терт в порошок и развеян по ветру.
Обоснование простое: что, если автор тест-кейса заболеет,
уйдет в отпуск, уйдет из компании или уйдет, извините,
вообще? Любой тест-кейс должен создаваться с мыслью
о коллеге, который однажды возьмет его в руки.
Нужно избегать и другой крайности – когда шаги тест-кейса
настолько детализируются, как будто он пишется для ученой
обезьяны. Излишняя детализация ведет к усложнению поддер-
живаемости тест-кейса, что было нами убедительно доказано
минуту назад.
В общем ищите золотую середину.
3. НЕЧЕТКАЯ ФОРМУЛИРОВКА ИДЕИ ТЕСТ-КЕЙСА
И/ИЛИ ОЖИДАЕМОГО РЕЗУЛЬТАТА
Оба тезиса, о которых мы только что говорили:
• о том, что можно забыть то, что сейчас понятно, и
• писать тест-кейсы нужно не для себя, а для того парня —
применимы и к идее и к ожидаемому результату. Нюансы для
идеи тест-кейса и ожидаемого результата:
54
Тестирование Дот Ком. Часть 1
а. Не рекомендуется отсылка к внешнему документу.
Когда мы говорили о выносе части шагов в Пособие для
тестировщиков, то делали это в случаях многократно по-
вторяющихся сценариев, встречающихся в разных тест-
комплектах, с целью сделать наш тест-кейс более поддер-
живаемым. С идеей же тест-кейса и ожидаемым результа-
том – совсем другая история.
Пример
Подумайте, удобно ли будет исполнять тест-кейс, если в секции IDEA
напечатано:
«В этом тест-кейсе мы проверяем пункт 21.6 спека номер 34 "Сцена-
рий добавления кредитной карточки к счету пользователя"»
или в секции Expected Result:
"Проверь, что значение последнего шага равно значению пересечения
значения шага 5 по оси X и значению шага 23 по оси Y из таблицы 17.0
спека из секции IDEA"?
б. Нужно помнить, что суть секции IDEA – это ОБЪЯСНЕ
НИЕ идеи тест-кейса.
Пример
Если секция IDEA пуста или же в ней скромно напечатано «10», то каж-
дый исполняющий этот тест-кейс каждый раз будет тратить несколько
минут своего времени и/или времени своего коллеги на выяснение того,
что же проверяется этим тест-кейсом.
в. Нужно помнить, что ожидаемый результат – это ин
формация, на основании которой (вкупе с фактическим
результатом) мы принимаем решение об исходе тест–
кейса. Следовательно, точность и четкость в форму
лировке ожидаемого результата играют наиважнейшую
роль.
Пример
Ожидаемый результат гласит: "Проверь, что показана страница с
ошибкой", и страница с ошибкой действительно показывается. Дело в
том, что если показывается не та ошибка, которая положена по специ-
фикации, то будет пропущен баг. Почему он будет пропущен? Пра-
вильно: из-за неточной формулировки ожидаемого результата.
Еще один пример плохого ожидаемого результата:
«Все работает».
Идем дальше.
Искусство создания тест-кейсов
55
Тест-комплекты
С помощью каждого отдельно взятого тест-кейса проверяется
какая-то одна вещь (развернуто сформулированная в секции
IDEA). Каждый спек – это источник для множества идей тести-
рования, и, таким образом, для проверки кода, написанного в со-
ответствии со спеком, нам нужно множество тест-кейсов.
Совокупность тест-кейсов (находящихся, как правило, в одном
документе), которые проверяют
• какую-то определенную часть нашего интернет-проекта
(например, "Оплату") и/или
• определенный спек (например, спек номер 1455 "Рассылка
пользователям е-мейлов на основании истории заказов"),
называют тест-комплектом (test case suite).
Что происходит в жизни?
• получаем новый спек;
• создаем новый файл, в котором создаем новые тест-кейсы
для этого нового спека;
• исполняем новые тест-кейсы с их одновременной модифи-
кацией (об этом через 45 секунд);
• если имеет смысл, то переносим тест-кейсы в основной
тест-комплект, где хранятся тест-кейсы, проверяющие ту
же функциональную часть вашего интернет-проекта.
Создание нового файла с новым тест-комплектом обусловлено
тем, что новые тест-кейсы всегда исполняются в первую оче-
редь и нам просто удобно хранить их отдельно от старых. Как
говорится, "мухи отдельно, котлеты отдельно" (конечно, до тех
пор, пока нам это удобно).
Пример
На 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:
Spec ID:
Priority
Producer:
Developer:
О. Тарасов
1211
1
П. Хрипунов
Н. Назаров
OVERVIEW:
Данный тест-комплект проверяет оплату картами VISA и MasterCard
GLOBAL SETUP and ADDITIONAL INFO:
1. SQL1: select result from cc_transaction where id = <номер заказа>;
2. Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/< четыре_последних_цифры_карты>/balance.htm
ТС ID/Priority
CCPG0001
1
IDEA: Оплата может быть произведена картой VISA
SETUP and ADDITIONAL INFO:
Эккаунт: testuser1/pa$$wOrd
Данные карты:
Номер: 9999-5148-2222-1277 Окончание действия:
12/07 CVV2: 778
Revision History
Created on: 11/17/2003 by О.Тарасов
Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй
ожидаемый результат с целью
удостоверения в снятии денег со счета
58
Тестирование Дот Ком. Часть 1
Execution part
PROCEDURE
EXPECTED RESULT
1. Запиши баланс счета карты
> «10»
2. Открой www.main.testshop.rs
3. Войди в систему.
4. Найди любой товар.
5. Добавь товар в корзину.
6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO
(!!! запиши полную сумму заказа:
).
7. Запиши номер заказа
8. Запроси базу данных с SQL1.
9. Запиши баланс счета карты
> Шаг 1 – Шаг 6
ТС ID/Priority
CCPG0002
1
IDEA: Оплата может быть произведена картой MasterCard
SETUP and ADDITIONAL INFO:
Эккаунт: testuser1/pa$$wOrd
Данные карты:
Номер: 3333-7112-4444-7844 Окончание действия: 12/08
CVV2: 676
Revision History
Created on: 11/17/2003 by О.Тарасов
Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй
ожидаемый результат с целью
удостоверения в снятии денег со счета
Execution part
PROCEDURE
EXPECTED RESULT
1. Запиши баланс счета карты
> "20"
2. Открой www.main.testshop.rs
3. Войди в систему.
4. Найди любой товар.
5. Добавь товар в корзину.
6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO
(!!! запиши полную сумму заказа:
).
7. Запиши номер заказа
8. Запроси базу данных с SQL1.
9. Запиши баланс счета карты
> Шаг 1 – Шаг 6
(TS7122) – каждый тест-комплект должен иметь свой уникальный ID.
Искусство создания тест-кейсов
59
Прошу обратить внимание на следующее:
1. Вещи, которые у нас повторяются в разных тест-кейсах,
вынесены в секцию GLOBAL SETUP and ADDITIONAL INFO
тест-комплекта:
1. SQL1: select result from cc_transaction where id– <номер заказа>;
2. Баланс счета карты можно посмотреть здесь:
www.main.testshop. rs/<четыре_последних_цифры_карты>/bаlаисе. h tm.
2. Данные, различающиеся между тест-кейсами CCPG0001 и
CCPG0002, выделены жирным с подчеркиванием. В предло
женном тест-комплекте это сделано, чтобы приковать вни
мание исполнителя к различиям в похожих тест-кейсах.
В общем случае хорошая практика – пользоваться ВОЗМОЖНО-
СТЯМИ текстового редактора, чтобы выделить то, на что стоит об-
ратить внимание.
Продолжаем.
Наш менеджер дает нам для проработки и создания тест-кейсов
новый спек продюсера М. Чучикова: #1422 "Покупка с исполь-
зованием Switch". Мы создаем новый файл: switch_payments.doc.
И после того как мы его исполнили и причесали наши новые тест-
кейсы (в данном случае один тест-кейс), получаем:
