Покупка с использованием Switch (TS7131)
Author: И. Новикова | Spec ID: 1422 | Priority 1 | Producer: M.Чучиков | Developer: Н. Назаров |
OVERVIEW: Данный тест-комплект проверяет оплату картой Switch | ||||
GLOBAL SETUP and ADDITIONAL INFO: 1. SQL1: select result from cc transaction where id = <номер заказа>; 2. Баланс счета карты можно посмотреть здесь: |
ТС ID/Priority | SWPL0001 | 1 |
IDEA:Оплата может быть произведена картой Switch SETUP and ADDITIONAL INFO: Эккаунт: testuser1/pa$$wOrd Данные карты: Номер: 3333-1988-4444-5699Окончание действия: 12/05CVV2: 451 |
60 Тестирование Дот Ком. Часть 1
Revision History | |
Created on:01/21/2003 by И. Новикова | Новый тест-кейс |
Execution part | |
PROCEDURE | EXPECTED RESULT |
1. Запиши баланс счета карты 2. Открой www.main.testshop.rs 3. Войди в систему. 4. Найди любой товар. 5. Добавь товар в корзину. 6. Произведи оплату картой из секции SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа: ). 7. Запиши номер заказа 8. Запроси базу данных с SQL1. | > "30" |
9. Запиши баланс счета карты | S* Шаг 1-Шаг 6 |
Теперь нам остается просто объединить оба файла. Таким образом, у нас получился all new credit_card_payments.doc. Откроем его:
Покупка с использованием кредитных карт
| ||||||
Часть 1 | тестирование | с VISA и MasterCard | ||||
Часть 2: | тестирование | со Switch Часть 1 | ||||
<Шапка, | CCPG0001 и ( | 2CPG0002 из старого файла credit card_payments | doc | |||
без изменений> | ||||||
Часть 2 | ||||||
<Шапка | и SWPL0001 из файла switch_payments
| .doc без изменений> |
Прошу обратить внимание на следующее:
мы не меняли
• ни содержимое файла switch_payments.doc, которое вставили в основной тест-комплект credit_card_payments.doc,
• ни содержимое старого файла credit_card_payments.doc.
Можно, например, было сделать для них одну общую "шапку" или заменить SWPL0001 на CCPG0003 (чтобы иметь единую систему нумерации в одном тест-комплекте), но ни этого, ни других объединительных мероприятий не было (и не будет) проведено, так как:
• это два независимых модуля и каждый из них прекрас
но исполняем по отдельности(пусть даже они и объеди-
Искусство создания тест-кейсов 61
нены в одном файле (и одном тест-комплекте) из-за того, что они покрывают ту же функциональную часть нашего проекта);
• уникальный ID тест-кейса дается последнему один раз и никогда не меняется.Это как номер налогоплательщика — нас ведь нужно учитывать, где бы мы ни были, а то располземся, как тараканы, легкомысленно забыв о том, что у патрициев тоже есть семьи, которые мы, будучи не патрициями, должны содержать, платя налоги.
Кстати, генерировать уникальный ID тест-кейса можно
|
|
• автоматически (для этого может быть написана простая программка) или же
• вручную, для чего должна быть заключена конвенция внутри департамента качества.
Пример
Мы договариваемся, что ID состоит из двух частей:
• первая часть — это буквенное обозначение (например, четыре латинские буквы), а
• вторая часть — это цифровое обозначение (от 0001 до 9999).
ID присваивается автором тест-комплекта, и в случае если новые тест-кейсы (без ID) добавляются в тест-комплект, то буквенный ID берется из предшествующих тест-кейсов, а цифровое обозначение = максимальное цифровое обозначение + 1. Так если мы решим добавить тест-кейс для тестирования оплаты картой Switch, то как мы его назовем? Правильно! SWPL0002. А картой VISA или MasterCard? Правильно! CCPG0003.
Кстати, CCPG — это "Credit Cards Payments Global" ("общее по платежам с кредитными картами"), a SWPL — "SWitch Payments Local" ("локальное по платежам с картой Switch"). Почему я выбрал ТАКИЕ буквенные обозначения? Потому что мне так захотелось. Никакого правила здесь нет, как нравится, так и называйте, но постарайтесь, чтобы не было двух тест-кейсов с одним ID.
Пример
Процесс присвоения ID идет следующим образом:
|
|
1. Пишем тест-кейсы. ID не присваиваем.
2. "Обкатываем" их при первом исполнении с удалением тех из них, которые недостойны быть частью нашего тест-комплекта, и добавлением тех, которые пришли на ум по мере исполнения.
3. Присваиваем оставшимся тест-кейсам по ID.
Мы продолжим разговор о тест-комплектах на одном из следующих чаепитий.
62
Тестирование Дот Ком. Часть 1
Состояния тест-кейса
У них все, как у людей. Рождаются, изменяются и умирают...
Рождение:
состояние — "Новый"(New).
Это первая редакция тест-кейса: "Created on: 11/17/2003 by
0. Тарасов".
Изменение:
состояние — "Измененный"(Modified). Модификации, как правило, связаны с изменением спека, затрагивающего этот тест-кейс, или с улучшением тест-кейса, например, для удобства в поддержке: "Modified on: 11/26/2003 by И. Новикова".
Смертьтест-кейса наступает
• вместе со смертью тестируемой вещи (определенной функциональности, элемента интерфейса пользователя и др.), например www.testshop.rs перестал принимать кредитные карты либо
• в других случаях, например когда один тест-кейс дублирует другой, т.е. имеем
состояние — "Более недействителен"(Retired).
Рекомендую не удалять тест-кейсы насовсем,так как
во-первых, всегда возможна ошибка в суждении и нам нужно предусмотреть обратимость удаления,
|
|
во-вторых, тест-кейс, который, по нашему субъективно-несовершенному мнению, перестал быть актуальным, может еще пригодиться, хотя бы как память о годах жизни, проведенных не за штурвалом пиратского брига "Черная жемчужина", а за монитором "Хундаи" с неотдирающимся стикером "Моя компания — мой дом".
В общем:
1. Создаем специальную директорию в том же месте, где хра
ним файлы с тест-комплектами, и называем ее
retired_testcases.
2. Создаем в этой директории файл с тем же именем, что и
файл тест-комплекта, из которого удаляем тест-кейс.
Искусство создания тест-кейсов
63
3. Переносим тест-кейс (cut/paste) из файла, больше не нуждающегося в этих услугах, в одноименный файл директории retired testcases.
В жизни все выглядит проще, так как обычно пускается в расход не отдельный тест-кейс, а весь тест-комплект.
Иногда возникает дилемма — что лучше:
• изменить тест-кейс или
• удалить его и придумать новый.
Зсе ситуации уникальны, но, как показывает жизнь, легче возвести здание на пустом месте, чем делать генеральную реставрацию старого особняка. Кстати, судя по Москве, этой концепции придерживаюсь не я один.
Вот такие дела...
А напоследок я скажу...
Важный момент перед подведением итогов.
Все то, о чем мы говорили в этой беседе, является хорошей практикой при создании тест-кейсов и тест-комплектов, эта практика имеет место в реальных и успешных интернет-компаниях Силиконовой Долины, и все, включая формат, можно использовать, как оно было рассказано и показано. Я же хочу, чтобы вы всегда помнили главное:
тестирование — это процесс творческий и, следовательно, подразумевает поиск. Ищите, пока не найдете то, что эффективно работает именно в вашей компании и в конкретнойситуации.
Для иллюстрации творческого подхода те же тест-кейсы, но в другом виде.
Таблица 1
Test Case ID | Priority | Card | Card Number | Card Expiration date | Card CVV2 | Expected Result |
CCPG0001 | 1 | VISA | 9999-5148-2222-1277 | 12/07 | 778 | 10 |
CCPG0001 | 1 | MasterCard | 3333-7112-4444-7844 | 12/08 | 676 | 20 |
SWPL0001 | 1 | Switch | 3333-1988-4444-5699 | 12/05 | 451 | 30 |
64 Тестирование Дот Ком. Часть 1
IDEA: Оплата может быть произведена картами из Таблицы 1. |
Для каждого тест-кейса из Таблицы 1: |
1. Запиши баланс счета карты : |
www.main.testshop.rs/<четыре_последних цифры_карты>/balance.htm |
2. Открой www.main.testshop.rs. |
3. Войди в систему как testuser1/paSSwOrd. |
4. Найди любой товар. |
5. Добавь товар в корзину. |
6. Произведи оплату картой (!! !запиши полную сумму заказа: ). |
7. Запиши номер заказа |
8. Запроси базу данных: |
select result from cc_transaction where id = <номер заказа>; |
Сравни с Expected resultl. |
9. Запиши баланс счета карты |
Шаг 1 - Шаг 6 |
Прошу считать творческий подход проиллюстрированным.
Краткое подведение итогов
1. Тест-кейс — это инструмент тестировщика, предназначенный для документирования и проверкиодного или более ожидаемых результатов.
2. Шаги (procedure) — это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату (выводу). Излишняя детализация может осложнить поддержку, а излишнее абстрагирование привести к непониманию того, как исполнить тест-кейс.
3. Шаги для повторяющихся сценариев можно вынести в отдельный документ в локальной сети, и в тест-кейсе мы даем лишь ссылку на этот документ.
4. Исполнение тест-кейса завершается либо положительным (pass), либо отрицательным (fail или баг!!!) результатом. Причем именно отрицательный результат является желанным, так как мы нашли баг.
5. Исполнение тест-кейса не является завершенным, если исполнитель не смог "пройти" все шаги.
6. Тест-кейс должен быть независим от других тест-кейсов из того же или любого другого тест-комплекта.
7. Наиполезнейшими вещами являются следующие атрибуты тест-кейса:
• уникальный ID, который уникален в пределах всех существующих в компании тест-кейсов;
Искусство создания тест-кейсов
65
• приоритет,чтобы все знали, кто здесь главный;
• идея,которая на простом языке объясняет предназначение тест-кейса;
• подготовительная часть,которая... ну, в общем, подготавливает нас к исполнению тест-кейса;
• история редактирования,которая помогает указать на друзей, испортивших наши идеальные тест-кейсы и наших легковерных попугаев.
8. Поддерживаемость тест-кейса — это легкость и удобство, с которыми он может быть изменен. Поддерживаемость тест-кейса — одна из основных формальных вещей при создании или модификации тест-кейса.
9. Тест-кейс "проверяет" не более одной идеи. При этом два и более ожидаемых результата легитимны, если истинность идеи вытекает из одновременной истинности этих ожидаемых результатов.
10. К плохому стилю относятся:
а) зависимость тест-кейсов друг от друга;
б) нечеткая формулировка шагов;
в) нечеткая формулировка идеи тест-кейса и/или ожидаемого
результата.
11. Тест-кейсы объединяются в тест-комплекты (как правило, один тест-комплект — это один файл).
12. Как правило, тест-комплект включает тест-кейсы, родственные друг другу тем, что они проверяют определенный участок нашего интернет-проекта или вещи, описанные в определенном спеке.
13. Хорошим стилем является создание нового тест-комплекта для новых тест-кейсов.
14. Тест-кейсы, написанные после проработки спека (до того, как представилась возможность "пощупать" написанное по нему ПО), являются сырыми, и никто не посмеет бросить в тестировщика камень осуждения, если он впоследствии изменит тест-кейсы по мере их исполнения.
15. Создавая или модифицируя тест-кейсы, мы всегда должны помнить о том парне, который будет их исполнять после нас.
16. Состояние тест-кейса: "У них все, как у людей. Рождаются, изменяются и умирают..." — "Новый", "Измененный", "Более недействителен". Хорошая практика — не удалять (remove) отжившие свой век тест-кейсы (или целые тест-комплекты), а переносить их (move) в отдельную директорию, специально созданную для таких пенсионеров.
17. Важно понять, что в сегодняшнем разговоре речь шла о форме, а не о содержании тест-кейсов. Содержание конкретного тест-кейса — это отражение методологии нахождения багов применительно к конкретной ситуации,и этой методологии будут посвящены отдельные беседы.
66 Тестирование Дот Ком. Часть 1
Дата добавления: 2018-05-02; просмотров: 514; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!