Сообщений в теме: 7

[Case]

Хочу начать цикл статей - как бы "первые шаги" - общее представление о том, что такое автоматизированное тестирование. Эта первая заготовка по функциональному тестированию.
==============================================================

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

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

Планируем тест.

- Цели и задачи теста определены ранее.

- Цепочка операций ясна, ожидаемые результаты ясны.

- Определена возможность параметризации (какие переменные могут быть определены как параметры).

- Записывается скрипт, которые эмулирует законченный бизнес-процесс - то что мы делаем.
Если бизнес-процесс с осуществляемым результатом выполняется в несколько этапов: то скрипт разбивается на несколько Actions.

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

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

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

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

- Получаем "объёмный" скрипт, который умеет вводить и жёстко заданные значения и повторятся столько раз, сколько значений определено для каждого параметра. При этом скрипт по прежнему умеет чекать только на то, чтобы отображалось тоже самое, что он видел во время записи.

- Белое пятно! По идее тулы нас умные и им как-то можно сказать, что если он использовал определённое значения параметра при проходе итерации, то и чекать нужно не в лоб, а умно - то есть где-то должна быть возможность поставить в соответствие значение параметра и значение, которое при таком значении параметра мы будем чекать в этой итерации.

------------------

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

==============================================================
Что требуется - желание покритиковать, дополнить, ответить на вопросы.
Потом это дело публикуется на сервере, с указанием всех авторов, конечно.

[barancev]

Насчёт нагрузочного тестирования -- это не мой профиль, а про функциональное с удовольствием покритикую. :)
Что критиковать? Изложенные здесь тезисы или уже есть черновик текста?

[Case]

Это и есть черновик :)
По сути идея сделать небольшой документик уровня "просто о сложном".

[Dmitry_NJ]

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

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

[Олешка]

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

И как насчет организации скриптов в scheduler?

[Dmitry_NJ]

Если checkpoints перестали работать, т.е. по каким-то причинам изменился baseline, с которым сравнивают (или файлы, хранящие baseline, как-то попортились), то в WinRunner предусмотрен специальный режим прогона скрипта. Если мне не изменяет память, он называется Update или что-то подобное. В этом случае скрипт выполняется как обычно, но в тех местах, где стоят checkpoints, происходит не сравнение с baseline, а текущие значения становятся новым baseline. То есть таким способом лечится проблема сломавшихся checkpoints без перезаписи скрипта, а просто путем его однократного запуска, но в другом режиме.

[Олешка]

Жаль, что в QTP такого нет. Есть Update Script, но не всегда срабатывает.

[Mike]

Олешка, я как раз сейчас работаю над написанием класса "сustom" чекпоинтов. В интерфейс QTP, конечно, встроить не получится, но зато храниться будут в xml (пробовал хранить в DataTable - работает, но не понравилось - медленно и глюковато в виду проблем класса DataTable с экспортом) и будет большАя гибкость в изменении baseline.

Что касается встроеных checkpoints в QTP, то единственная проблема при update script - то что затираются regular expressions. Лично мне QTPшные чекпоинты не нравятся не столько глючностью, сколько тем что они редактируются только из скрипта, наружу не видны, и вообще хранятся в бинарном формате.

Да, что касается классов в QTP. К сожалению, классы, определённые в библиотеках наружу не видны, поэтому приходится либо прибегать к ExecuteScript (что ведёт к некоторым глюкам при отладке) либо писать функцию, возвращающую экземпляр класса (в этом случае мы вываливаемся из скрипта при любом exception внутри класса, но зато нет глюков с отладкой самого теста).