Покупка с использованием 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. Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/<четыре_последних_цифры карты>/bа1аncе.htm

 

ТС 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; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!