testirovanie_dot-com
.pdf
Искусство создания тест-кейсов |
59 |
|
Прошу обратить внимание на следующее:
1.Вещи, которые у нас повторяются в разных тест-кейсах,
вынесенывсекциюGLOBALSETUPandADDITIONALINFO
тест-комплекта:
1.SQL1: select result from cc_transaction where id— <номер заказа>;
2.Баланс счета карты можно посмотреть здесь: www.main.testshop.rs/<четыре_последних_цифры_карты>/bаlаисе.htm.
2.Данные, различающиеся между тест-кейсами CCPG0001 и CCPG0002, выделены жирным сподчеркиванием. Впредло женном тест-комплекте это сделано, чтобы приковать вни мание исполнителя к различиям в похожих тест-кейсах.
Вобщем случае хорошая практика — пользоваться ВОЗМОЖНО- СТЯМИ текстового редактора, чтобы выделить то, на что стоит обратить внимание.
Продолжаем.
Наш менеджер дает нам для проработки и создания тест-кейсов новый спек продюсера М. Чучикова: #1422 "Покупка с исполь-
зованием Switch". Мы создаем новый файл: switch_payments.doc.
И после того как мы его исполнили и причесали наши новые тесткейсы (в данном случае один тест-кейс), получаем:
Покупка с использованием Switch (TS7131)
Author: |
Spec ID: |
Priority |
Producer: |
Developer: |
И. Новикова |
1422 |
1 |
M.Чучиков |
Н. Назаров |
|
|
|
|
|
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/05 CVV2: 451
60 |
Тестирование Дот Ком. Часть 1 |
Revision History
Created on: 01/21/2003 by И. Новикова |
Новый тест-кейс |
|
|
Execution part |
|
|
PROCEDURE |
EXPECTED RESULT |
1. |
Запиши баланс счета карты |
> "30" |
2. |
Открой www.main.testshop.rs |
|
3. |
Войди в систему. |
|
4. |
Найди любой товар. |
|
5. |
Добавь товар в корзину. |
|
6. Произведи оплату картой из секции |
|
|
SETUPandADDITIONALINFO |
|
|
(!!! запиши полную сумму заказа: |
|
|
). |
|
|
7. |
Запиши номер заказа |
|
8. |
Запроси базу данных сSQL1. |
|
|
|
|
9. Запиши баланс счета карты |
S* Шаг 1-Шаг 6 |
|
|
|
|
Теперь нам остается просто объединить оба файла. Таким образом,
у нас получился all new credit_card_payments.doc. Откроем его:
Покупка с использованием кредитных карт
Часть1 |
тестирование с VISA и MasterCard |
|
Часть2: |
тестирование со Switch |
|
|
Часть 1 |
|
<Шапка, |
CCPG0001 и |
2CPG0002 из старого файла credit doc |
без изменений> |
Часть 2 |
|
|
|
|
<Шапка |
и SWPL0001 из файла |
.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 |
Priority |
Card |
Card Number |
Card |
Card |
|
Expected |
ID |
|
|
|
Expiration |
CVV2 |
|
Result |
|
|
|
|
date |
|
|
|
|
|
|
|
|
|
|
|
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 |
Вопросы и задания для самопроверки
1.Без какой части тест-кейс никак не может обойтись?
2.Для чего в тест-кейсе нужны шаги?
3.Два вида исхода исполнения тест-кейса. К какому исходу мы, как тестировщики, стремимся?
4.Что происходит, если состояние ПО не позволяет исполнить все шаги тест-кейса? Каковы наши действия?
5.Обоснуйте, почему у тест-кейса должна быть лишь одна тестируемая идея?
6.Перечислите полезные атрибуты тест-кейса и причину полезности каждого из них.
7.Изменяется ли ID тест-кейса при изменении самого тест-кейса или переносе его в другой документ?
8.Придумайте свой способ индексации тест-кейсов, например, частью ID может быть номер спека.
9.Что такое data-driven тест-кейс? В чем заключается удобство поддержания такого тест-кейса?
10.Как легкость в поддерживаемое™ тест-кейса позволяет сэкономить время?
11.Формальные недостатки, не позволяющие тест-кейсам быть белыми и пушистыми.
12.В чем удобство написания новых тест-кейсов в отдельный тесткомплект?
13.Ожидается ли, что тестировщик изменит тест-кейс, написанный лишь на основании спека, без знакомства с реально написанным ПО?
14.В чем проявляется родственность тест-кейсов, являющихся частью одного тест-комплекта?
15.Приведите атрибуты шапки тест-комплекта.
16.Состояния тест-кейса.
17.Почему не рекомендуется удалять тест-кейсы?
18.Есть ли стандартная форма тест-кейса, за несоблюдение которой лишают премий и не приглашают на празднование Нового года?
19.Разница между идеей тест-кейса и ожидаемым результатом.
20.Напишите тест-кейс с тестируемой идеей "Я могу убедить свою жену в чем угодно" и ожидаемым результатом "Дорогой, поезжайте с Алексеем на рыбалку. Вы так редко с ним видитесь".
21.Напишите тест-кейс с одной идеей и двумя ожидаемыми результатами. Используйте пример из жизни.
ЦИКЛРАЗРАБОТКИПО
•ИДЕЯ
•РАЗРАБОТКА ДИЗАЙНА ПРОДУКТА И СОЗДАНИЕ ОПЕКА
•КОДИРОВАНИЕ
•ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ И РЕМОНТ БАГОВ
•РЕЛИЗ
•БОЛЬШАЯ КАРТИНА ЦИКЛА РАЗРАБОТКИ ПО
Цикл (процесс) разработки ПО (software development life cycle) — это путь от идеи до поддержки готового продукта.
Чем более отлажены каждая из стадий цикла и координация между ними, тем эффективнее работает интернет-компания, тем выше качество и тем счастливее пользователи.
Сегодня мы поговорим о модели цикла разработки ПО, называемой "Waterfall" ("Водопад"), которая используется в подавляющем большинстве интернет-стартапов.
Наша цель — понять логику взаимосвязи между стадиями Циклаи основные моментыкаждой из стадий.
Большая картина цикла будет представлена в конце разговора, когда будет понятно, что уже ничего не понятно.
Постараюсь свести к минимуму вещи типа: "в одних компаниях Эгпо называется так, а в других — этак", нельзя объять необъятное, но если будет схвачен принцип, то, несмотря на разницу
67
