Основная концепция реализации автоматизированного функционального тестирования (на примере Mercury QuickTestProfessional).

29.09.2008 18:08

Автор: Панкратов Вячеслав при активном участии консультантов проекта Ольги Агладзе и Дмитрия Шевченко

Содержание:

Общая схема работы
Основные шаги при записи автоматизированного теста
Параметризация
Контрольные точки

Общая схема работы.

Записываем только заранее запланированный тест!

Цели и задачи теста определены ранее.
Цепочка операций ясна, ожидаемые результаты ясны.
Определена возможность параметризации (какие переменные могут быть определены как параметры).
Записывается скрипт, который эмулирует законченный бизнес-процесс — то что мы делаем. Если бизнес-процесс с осуществляемым результатом выполняется в несколько этапов: то скрипт разбивается на несколько Actions (к примеру логин/заказ/логаут). (поправка 1)

Получаем «плоский» скрипт, который умеет вводить «в лоб» то что мы вводили во время записи и ничего не тестирует.

Создаются CheckPoints (контрольные точки) - то что мы проверяем. Чекпойнты могу создаваться как в процессе записи скрипта, так и после его отладки (в случае необходимости). Второй вариант видится более предпочтительным (дополнение 1).

Получаем «плоский» скрипт, который умеет вводить «в лоб» то что мы вводили во время записи и проверять, чтобы отображалось тоже самое, что он видел во время записи.

Скрипт параметризируется (если возможность и необходимость есть) для придания скрипту «объёма». Пример: объявив логин/пароль как параметры, можем эмулировать скриптом последовательный логин в систему стольких пользователей, сколько значений параметра мы зададим.

Получаем «объёмный» скрипт, который умеет вводить (поправка 2) наборы заданных значений и повторятся столько раз, сколько значений определено для каждого параметра. При этом скрипт по прежнему умеет «чекать» только на то, чтобы отображалось тоже самое, что он видел во время записи.

Термины типа «плоский», «объёмный» вводились на ходу, чтобы не употреблять «не параметризованный» и «параметризованный».

Из опыта специалистов, которые принимали участие в обсуждении статьи (в форуме тестировщиков):

Дмитрий Шевченко:

Поправка 1
Что касается разбивки на Actions, то это зависит от инструмента. В QTP вы можете такое проделать, но в WinRunner'e никаких actions нет. Вы можете или создавать отдельные скрипты, а потом вызывать их из какого-то общего скрипта, или положить часто используемую логику в библиотечные функции и дергать их.

Поправка 2
Параметризовать можно не только входные данные, но и проверяемые значения. В WinRunner'е, например, это называется data-driven tests. То есть в той же табличке где у вас есть parameter1, parameter2, ... со значениями этих параметров для всех итераций добавляется еще один (или несколько) столбцов на те значения, которые вы ожидаете в определенном месте вашего теста (эталонные значения). Тогда на каждую комбинацию входных параметров у вас будет свой ожидаемый результат.

Ольга Агладзе:

Дополнение 1:
По крайней мере для QTP наша практика показывает, что гораздо лучше иметь готовый, спланированный тест, включая checkpoints, и ставить их именно в процессе записи теста, а не после. Потому что иначе в один не очень прекрасный день вы столкнетесь с тем, что checkpoints не работают.

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Секретное слово:

yvComment v.1.19.3

Software-Testing.Ru