А. Не рекомендуется отсылка к внешнему документу.
Когда мы говорили о выносе части шагов в Пособие для тестировщиков, то делали это в случаях многократно повторяющихся сценариев, встречающихся в разных тест-комплектах, с целью сделать наш тест-кейс более поддерживаемым. С идеей же тест-кейса и ожидаемым результатом — совсем другая история.
Пример
Подумайте, удобно ли будет исполнять тест-кейс, если в секции 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 и MasterCard. У нас есть тест-комплект, который мы исполняем из релиза в релиз (это регрессивное тестирование, о котором мы еще будем много говорить), называемый "Покупка с использованием кредитных карт".
Этот тест-комплект был написан на основании спека #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: 1211 | Priority 1 | Producer: П. Хрипунов | Developer: Н. Назаров |
OVERVIEW: Данный тест-комплект проверяет оплату картами VISA и MasterCard | ||||
GLOBAL SETUP and ADDITIONAL INFO: 1. SQL1: select result from cc_transaction where id = <номер заказа>; 2. Баланс счета карты можно посмотреть здесь: |
ТС ID/Priority | CCPG0001 | 1 | |
IDEA:Оплата может быть произведена картой VISA SETUP and ADDITIONAL INFO: Эккаунт: testuser1/pa$$wOrd Данные карты: Номер: 9999-5148-2222-1277Окончание действия: 12/07CVV2: 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. Запиши баланс счета карты 2. Открой www.main.testshop.rs 3. Войди в систему. 4. Найди любой товар. 5. Добавь товар в корзину. 6. Произведи оплату картой из секции SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа: ). 7. Запиши номер заказа 8. Запроси базу данных с SQL1. | > "10" |
9. Запиши баланс счета карты | > Шаг 1 - Шаг 6 |
ТС ID/Priority | CCPG0002 | 1 | |
IDEA:Оплата может быть произведена картой MasterCard SETUP and ADDITIONAL INFO: Эккаунт: testuser1/pa$$wOrd Данные карты: Номер: 3333-7112-4444-7844Окончание действия: 12/08CVV2: 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. Запиши баланс счета карты 2. Открой www.main.testshop.rs 3. Войди в систему. 4. Найди любой товар. 5. Добавь товар в корзину. 6. Произведи оплату картой из секции (!!! запиши полную сумму заказа: ). 7. Запиши номер заказа 8. Запроси базу данных с SQL1. | > "20" | ||
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. И после того как мы его исполнили и причесали наши новые тест-кейсы (в данном случае один тест-кейс), получаем:
Дата добавления: 2018-05-02; просмотров: 831; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!