Test case можно перевести как «тестируемая ситуация» икак «оболочка для теста»



Скачать 94.26 Kb.
Дата16.02.2018
Размер94.26 Kb.
#12825

Тест-кейс

Test case можно перевести как «тестируемая ситуация» и как «оболочка для теста».

Главная и неотъемлемая часть тест-кейса — это ожидаемый результат.

Пример

Допустим, что перед сборами на рыбалку мы составили следующий список:





  • Удочка.

  • Коробка с запасными поплавками и леской.

  • Банка с червями.

  • Стакан граненый.

  • Бутылка "Абсолюта".

  • Огурец соленый.



Каждая из 6 строк списка — это и есть тест-кейс (test case).

Сам список является тест-комплектом (test suite).

Процесс придумывания и написания каждой строки списка называется созданием тест-кейса (test case generation).

Процесс проверки рюкзака на наличие определенного предмета — исполнением тест-кейса (test case execution).


Структура тест-кейса

Проблема в том, что для нахождения бага (что является смыслом любого тестирования) кроме ожидаемого нам нужен и фактический результат. В случае с огурцом мы просто заглядываем в рюкзак и смотрим, на месте ли этот "фрукт". В случае же тестирования ПО, как правило, необходима инструкция, как прийти к фактическому результату.


Пример


Допустим, тестировщику дали для исполнения следующий тест-кейс:

«Оплата может быть произведена картой VISA».


Уже возникает по крайней мере две проблемы:

• для исполнения тест-кейса нужна тестировочная карта Visa которой у него нет;

• он не знает, как проверить, был ли действительно осуществлен платеж, даже если бы у него была карта.


Единственное, что более или менее понятно, — это процесс покупки в интернет-магазине (найти товар, добавить в корзину и т.д.), что в данной ситуации помогает немного. Естественно, никакого тестирования не будет, так как пробиться к фактическому результату трудно.

Шаги:

1. Открой www.main.testshop.ru



2. Введи в поле "Имя пользователя": "testuser1"

3. Введи в поле "Пароль": "pa$$w0rd"

4. Нажми кнопку "Войти"

5. Введи в поле "Поиск": "book117"

6. Нажми кнопку "Найти"

7. Кликни линк "Добавить в корзину"

8. Кликни линк "Корзина"

9. Кликни линк "Оплатить"

10. Выбери из меню "Вид карты": "VISA"

11. Введи в поле "Номер карты": "9999-5148-2222-1277"

12. Введи в поле "Действительна до": "12/07"

13. Введи в поле "CW2": "778"

14. Нажми кнопку "Завершить заказ"

15. Запиши номер заказа ________

16. Запроси базу данных:

select result from transaction where id =<номер заказа>; Ожидаемый результат: "10“

В последнем примере (тест-кейс с картой) к ожидаемому результату (ОР) добавились шаги, которые должны привести к фактическому результату (ФР), необходимому, чтобы узнать, есть баг или нет. Совокупность шагов называется процедурой (procedure).

Результат выполнения тест-кейса

Каждый тест-кейс, исполнение которого завершено, дает одно из двух:

1. Положительный исход (PASS), если ФР равен ОР, либо

2. Отрицательный исход (FAIL), если ФР не равен ОР: найден баг!


Иногда возникает ситуация, когда мы заблокированы, так как не можем пройти ВСЕ шаги тест-кейса. Например, мы не можем продвинуться дальше, если кнопки «Завершить заказ» из шага 14 не существует на соответствующей веб-странице. В таком случае мы рапортуем о баге (в данном случае баг об отсутствии кнопки "Завершить заказ") и откладываем исполнение тест-кейса до устранения бага.

Полезные атрибуты тест-кейса


  • УНИКАЛЬНЫЙ ID
    Со временем появится необходимость вести статистику по тест-кейсам, обновлять, удалять или переносить в другой документ некоторые из них

  • ПРИОРИТЕТ ТЕСТ-КЕЙСА
    Это важность тест-кейса. Важность отражается по шкале от 1 до n, где 1 — это высший приоритет, а n — это низший приоритет

  • ИДЕЯ
    Это описание конкретной функциональности, проверяемой тест-кейсом.
    Пример идеи.
    Плохой вариант.
    В тест-кейсе с картой ожидаемым результатом является значение 10 в колонке result строки с нашей транзакцией.
    Хороший вариант.
    Оплата может быть произведена картой VISA.

  • ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ
    В подготовительную часть тест-кейса могут включаться:

• данные о существующем аккаунте пользователя или инструкции по созданию нового аккаунта;

• другие данные, используемые в тест-кейсе, например атрибуты используемой кредитной карты;

• запросы к базе данных (SQL queries), используемые в тест-кейсе;

• комментарии в помощь тестировщику, например о нюансах, которые могут встретиться при исполнении тест-кейса;

• другие вещи, облегчающие исполнение и поддержку тест-кейса.



  • ИСТОРИЯ РЕДАКТИРОВАНИЯ (Revision History)

Для того чтобы иметь сведения о рождении и истории развития каждого тест-кейса, ведется лаконичный журнал изменений где отражается:

Кто? Что? Зачем? Когда? Почему?


Атрибуты истории редактирования:

• Created on by — Тест-кейс создан <дата> <кем>;

• Modified on by — Тест-кейс изменен <дата> <кем>;

• Change — Что, зачем и почему было изменено.



Тест-кейсы, управляемые данными

Основной плюс нового тест-кейса с платежной картой заключается в том, что нам не нужно вносить изменения в ШАГИ, чтобы протестировать по тому же сценарию другие платежные карты.

Единственное, что нам нужно — это модифицировать исходные ДАННЫЕ.
Такой вид тест-кейса называется data-driven («управляемый данными"), т.е. когда данные и инструкции по их применению не смешаны, а разделены и связаны.

Поддерживаемость тест-кейса

Пример


Кнопка "Войти" из шага 4 легко может быть переименована во "Вход". В этом случае, если у нас есть 3 тест-кейса, то нужно внести 3 изменения. А что, если у нас 500 тест-кейсов, где упоминается кнопка "Войти", и эти тест-кейсы разбросаны по разным документам? Вносить 500 изменений?

Возникает проблема поддерживаемости, т.е. насколько легко и просто можно изменить тест-кейс при изменениях в ПО.


Способ решения:
вынести шаги, повторяющиеся от тест-кейса к тест-кейсу во внешний документ и вместо них включить в тест-кейс лишь один шаг-ссылку «Произведи ОПЛАТУ КАРТОЙ из секции "SETUP and ADDITIONAL INFO"»

Как улучшить поддерживаемость тест-кейса?


  • Сделать тест-кейс управляемым данными.

  • Не описывать шаги по явно очевидным сценариям (например, логин).

  • Не давать конкретных деталей, если они не играют роли при исполнении тест-кейса (например, имя товара).

  • Вынести во внешний документ повторяющиеся сценарии (например, семь шагов оплаты).





Сколько ожидаемых результатов может быть в одном тест-кейсе?

Тест-кейсом проверятся только одна конкретная вещь и в идеальном варианте для проверки этой вещи достаточно предусмотреть в тест-кейсе только один ОР, и теоретически можно сказать, что ни в коем случае нельзя включать в тест-кейс более одного ОР.



Пример
Допустим, что в соответствии с пунктом 12.6 документа "Дизайн кода для спека #6522" признаком того, что оплата была успешно проведена картой VISA, будет одновременное наличие не одного, а двух условий:

1. Значение "10" в соответствующей колонке соответствующей строки в базе данных.

2. Уменьшение баланса на счете с картой VISA на сумму, равную сумме оплаты.
Возможны два пути:


  • Разложить идею тест-кейса на две идеи и создать два тест-кейса.

  • Оставить идею тест-кейса неприкосновенной и включить в один тест-кейс два ОР, т.е. у нас складывается ситуация, когда исполнение тест-кейса будет иметь положительный исход, только если ОБА фактических результата совпали с соответствующими им ожидаемыми результатами.



Признаки плохих тест-кейсов

1. Зависимость тест-кейсов друг от друга.

2. Нечеткая формулировка последовательности шагов, которая должна привести к ожидаемому результату.

3. Нечеткая формулировка идеи и/или ожидаемого результата.



ЗАВИСИМОСТЬ ТЕСТ-КЕЙСОВ ДРУГ ОТ ДРУГА


Пример

Тест-кейс 1:

Шаги:

1. Зайти в комнату.



2. Подойти к стулу.

3. Открыть правый внешний карман рюкзака.

Засунуть руку в правый внешний карман рюкзака.

Ожидаемый результат: Граненый стакан.


Тест-кейс 2:

Шаги:


1. Смотри шаги 1 и 2 из тест-кейса 1.

2. Открыть левый внешний карман рюкзака.

3. Засунуть руку в левый внешний карман рюкзака.

Ожидаемый результат: Огурец.

Шаг 1 тест-кейса 2 нужно избегать, так как:


  • тест-кейс 1 может быть удален из-за ненадобности или,

  • шаги по тестированию наличия стакана (в тест-кейсе 1) могут быть изменены (например, стакан лежит в другом рюкзаке, который находится на кухне).

В обоих случаях будет непонятно, как исполнить тест-кейс 2, так как



  • у нас или нет шагов 1 и 2 из тест-кейса 1, или

  • они стали неправильными (с субъективной точки зрения тест-кейса 2).

Другим распространенным случаем плохого тест-кейса является допущение, что ПО или база данных уже приведены к нужному состоянию, так как были исполнены предыдущие тест-кейсы.

Таким образом, хороший тест-кейс характеризуют:

• отсутствие ссылок на другие тест-кейсы;

• независимость от "следов", оставленных другими тест-кейсами в нашем ПО или базе данных.


Следовательно, если у нас в документе А есть 10 тест-кейсов: тест-кейс 1, тест-кейс 2,..., тест-кейс 10, то доказательством независимости каждого из тест-кейсов будет тот факт, что их без ущерба для тестирования можно всегда исполнять в любом порядке, например, тест-кейс 10, затем тест-кейс 2, затем тест-кейс 6 и т.д.

НЕЧЕТКАЯ ФОРМУЛИРОВКА ПОСЛЕДОВАТЕЛЬНОСТИ ШАГОВ

Перечисляющиеся в тест-кейсе шаги должны быть объективно четкими и ясными.

Нужно помнить,

• то, что очевидно для вас сейчас, может стать совершенно непонятным через пару месяцев.

Так, сокращенные шаги с нерасшифрованными аббревиатурами, понятными вам сейчас, могут впоследствии стать китайской грамотой для вас самих, так что проще будет написать тест-кейс заново, чем пробираться через дебри неосмотрительно сделанных описаний;

• тест-кейс, который не может быть исполнен никем, кроме его автора, должен быть публично уничтожен.

Обоснование простое: что, если автор тест-кейса заболеет, уйдет в отпуск, уйдет из компании. Любой тест-кейс должен создаваться с мыслью о коллеге, который однажды возьмет его в руки.

НЕЧЕТКАЯ ФОРМУЛИРОВКА ИДЕИ ТЕСТ-КЕЙСА И/ИЛИ ОЖИДАЕМОГО РЕЗУЛЬТАТА

а. При формулировки идеи не рекомендуется отсылка к внешнему документу.



Пример

Удобно ли будет исполнять тест-кейс, если в секции IDEA напечатано:

«В этом тест-кейсе мы проверяем пункт 21.6 спека номер 34 "Сценарий добавления кредитной карточки к счету пользователя"» или в секции Expected Result:

"Проверь, что значение последнего шага равно значению пересечения значения шага 5 по оси X и значению шага 23 по оси Y из таблицы 17.0 спека из секции IDEA"?

б. Нужно помнить, что суть секции IDEA — это ОБЪЯСНЕНИЕ идеи тест-кейса.

Пример

Если секция IDEA пуста или же в ней скромно напечатано "10", то каждый исполняющий этот тест-кейс каждый раз будет тратить несколько минут своего времени и/или времени своего коллеги на выяснение того, что же проверяется этим тест-кейсом.


в. Нужно помнить, что ожидаемый результат — это информация, на основании которой (вместе с фактическим результатом) мы принимаем решение об исходе тест-кейса. Следовательно, точность и четкость в формулировке ожидаемого результата играют наиважнейшую роль.
Пример

Ожидаемый результат гласит: "Проверь, что показана странице c ошибкой", и страница с ошибкой действительно показывается. Дело том, что если показывается не та ошибка, которая положена по спецификации, то будет пропущен баг.

Еще один пример плохого ожидаемого результата: "Все работает".

Тест-комплекты

C помощью каждого отдельно взятого тест-кейса проверяется какая-то одна вещь (развернуто сформулированная в секции IDEA).

Каждый спек — это источник для множества идей тестирования, и, таким образом, для проверки кода, написанного в сответствии со спеком, нам нужно множество тест-кейсов.

Совокупность тест-кейсов (находящихся, как правило, в одном документе), которые проверяют

• какую-то определенную часть нашего проекта

(например, "Оплату") и/или

• определенный спек (например, спек номер 1455 "Рассылка пользователям е-мейлов на основании истории заказов"),

называют тест-комплектом.



(как правило, один тест-комплект – это один файл)

В первый раз тест-кейсы должны исполняться их автором, задача которого

• если необходимо, добавить новые тест-кейсы;

• если необходимо, внести изменения по существу, например, в случае, если при создании тест-кейса тестировщик неправильно понял спек;

• если возможно, удалить лишние тест-кейсы, например, если два тест-кейса проверяют одну и туже идею, дублируя друг друга;

• сделать тест-кейсы более удобными для поддержки;

• отшлифовать их, что означает сделать формулировки ясными и точными.
Что происходит в жизни?

• получаем новую спецификацию;

• создаем новый файл, в котором создаем новые тест-кейсы для этого нового спека;

• исполняем новые тест-кейсы с их одновременной модификацией;

если имеет смысл, то переносим тест-кейсы в основной тест-комплект, где хранятся тест-кейсы, проверяющие ту же функциональную часть вашего проекта.

«Шапка», которую можно нацепить поверх тест-кейсов





Покупка с использованием кредитных карт
Часть 1: тестирование с VISA и MasterCard

Часть 2: тестирование со Switch

Часть 1

<Шапка, CCPG0001 и CCPG0002 из старого файла credit_card_payments.doc без изменений>

Часть 2

<Шапка и SWPL0001 из файла switch_payments.doc без изменений>
Причины, почему не была сделана замена SWPL0001 на CCPG0003:

  • это два независимых модуля и каждый из них прекрасно исполняем по отдельности;

  • уникальный ID тест-кейса дается последнему один раз и никогда не меняется.



Состояния тест-кейса


Рождение:

состояние — «Новый».

Это первая редакция тест-кейса: "Created on: 1/17/2003 к О. Тарасов".
Изменение:

состояние — «Измененный».


Модификации, как правило, связаны с изменением спецификации, затрагивающего этот тест-кейс, или с улучшением тест-кейса, например, для удобства в поддержке: "Modified on: 11/26/2003 by И. Новикова".


Смерть тест-кейса наступает

• вместе со смертью тестируемой вещи (определенной функциональности, элемента интерфейса пользователя и др.), например www.testshop.ru перестал принимать кредитные карты либо

• в других случаях, например когда один тест-кейс дублирует другой, т.е. имеем

состояние — «Более недействителен».



Хорошая практика – не удалять отжившие свой век тест-кейсы, а переносить их в отдельную папку.

Скачать 94.26 Kb.

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




База данных защищена авторским правом ©vossta.ru 2022
обратиться к администрации

    Главная страница