Сколько ожидаемых результатов может быть в одном тест-кейсе?
Тест-кейсом проверятся только одна конкретная вещь, и в идеальном варианте для проверки этой вещи достаточно предусмотреть в тест-кейсе только один ОР, и если бы я был теоретиком, а не практиком тестирования, то сказал бы, что ни в коем случае нельзя включать в тест-кейс более одного ОР.
Вот вам случай из практики
Допустим, что в соответствии с пунктом 12.6 документа "Дизайн кода для спека #6522" признаком того, что оплата была успешно проведена картой VISA, будет одновременное наличие не одного, а двух условий:
1. Значение "10" в соответствующей колонке соответствующей строки в базе данных.
2. Уменьшение баланса на счете с картой VISA на сумму, равную сумме оплаты.
То есть получается, что для тестирования одной вещи ("Оплата может быть произведена картой VISA") нужно проверить соответствие жизненной реальности двум ожидаемым результатам.
У нас есть два пути:
1. Разложить идею тест-кейса на две идеи и создать два тест-кейса.
2. Оставить идею тест-кейса неприкосновенной и включить в один тест-кейс два ОР, т.е. у нас складывается ситуация,
48
Тестирование Дот Ком. Часть 1
когда исполнение тест-кейса будет иметь положительный исход, только если ОБА фактических результата совпадут с соответствующими им ожидаемыми результатами.
Вот как будет выглядеть визуально путь 2:
ТС ID/Priority | CCPG0001 | 1 | |||
IDEA:Оплата может быть произведена картой VISA SETUP and ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Данные карты: Номер: 9999-5148-2222-1277 Окончание действия: 12/07 CVV2: 778 SQL1: select result from cc transaction where id = <номер заказа>; Баланс счета карты можно посмотреть здесь: www.main.testshop.rs/1277/balance.htm | |||||
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. | S> "10" | ||||
9. Запиши баланс счета карты | > Шаг 1-Шаг 6 | ||||
Как будет проходить исполнение этого тест-кейса?
Искусство создания тест-кейсов 49
Прошли восемь шагов. Остановились. Проверили. Затем прошли девятый шаг. Остановились. Проверили.
Исход исполнения этого тест-кейса будет считаться положительным только при одновременной истинности двух условий:
|
|
1. ФР после исполнения шага 8 = "10" и
2. ФР после исполнения шага 9 = Шаг 1 - Шаг 6 (т.е. значение из Шага 1 минус значение из Шага 6).
В теории лучше было бы разбить нашу идею тест-кейса на две части и создать два отдельных тест-кейса:
1. IDEA: "Правильное значение вставляется в базу данных при использовании VISA".
2. IDEA: "Верная сумма списывается с баланса карты".
И если есть возможность, то ЛУЧШЕ сделать именно два тест-кейса, НО на практике во многих случаях имеет смысл включить в тест-кейс 2 или больше ОР, так как:
• у вас может просто не быть времени на написание, исполнение и поддержку двух тест-кейсов*;
• сэкономленное время можно потратить на написание, исполнение и поддержку тест-кейса, которым мы бы проверили другую вещь**.
Если у нас есть один случай, когда можно совместить два ОР, то написание, исполнение и поддержка двух тест-кейсов не представляет труда. А что, еслиу нас появляются сотни дополнительных тест-кейсов?..
В результате такой экономии мы с течением времени создаем десятки новых тест-кейсов, которые помогают нам провести более тщательное тестирование.
Я работал с тест-кейсами, включающими более одного ОР, в течение многих лет, проводя тестирование сложнейшего ПО, связанного с финансовыми транзакциями, и могу сказать, что 2 или больше ОР в одном тест-кейсе — это нормальная практика.
|
|
Идем дальше.
Во многих случаях, когда несколько ожидаемых результатов просятся в один тест-кейс, нужно проверить
• значение(-я) на веб-странице и
• значение(-я) в базе данных,
те. нужна проверка снаружи и изнутриили на front end и back end.
50
Тестирование Дот Ком. Часть 1
Постановка мозгов
Front end (читается как "фронт-энд") — это непосредственный интерфейс пользователя, т.е. текст, картинки, кнопки, линки и прочие вещи, которые пользователь видите окне веб-браузера или е-мейл клиента.
Back end (читается как "бэк-энд") — это ПО и данные, находящиеся за фасадом фронт-энда: HTML-код веб-страницы, веб-сервер, код приложения, база данных и т.д.
В последнем примере мы непосредственно "разговаривали"
• с фронт-энд ом — в шаге 5, когда добавляли товар в корзину;
• с бэк-эндом — в шаге 8, когда запрашивали базу данных.
Проблемные тест-кейсы
Теперь посмотрим, какие недостатки вы должны выжигать из своих тест-кейсов каленым железом.
1. Зависимость тест-кейсов друг от друга.
|
|
2. Нечеткая формулировка шагов.
3. Нечеткая формулировка идеи и/или ожидаемого результата.
Дата добавления: 2018-05-02; просмотров: 2882; Мы поможем в написании вашей работы! |

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