новости
статьи
.software

тестируй веб-сайты вместе с Badboy

часть 1

Разработка программного обеспечения не самая простая наука. И уж тем более не сводится к знанию языков программирования и разных библиотечек с готовыми наработками. Если создавать что-то не “для себя” или “на потеху”, а заниматься разработкой ПО профессионально, зарабатывать деньги, то необходимо качественно “пройтись” по всем шагам жизненного цикла ПО: от планирования до сопровождения.

Сегодня рассказ будет посвящен такому этапу как тестирование. Тестирование один из важнейших шагов в процессе разработки. Возможен вариант, когда после создания ПО, но до передачи заказчику выполняется тестирование качества, поиск ошибок. Возможен и другой стиль тестирования, когда оно идет одновременно с разработкой ПО. В этом случае затраты времени больше чем в первом варианте, но и качество продукта будет выше. Условно тесты делятся “по шагам” и “по способам”. Шаги - это юнит-тестирование (оно же, модульное тестирование), интеграционное тестирование, системное тестирование. В первом случае тестированию подвергаются наименьшие части приложения: обычно это отдельный класс и его методы. В случаях, если класс нуждается для обеспечения своей работы в еще одном классе, а тот класс - в третьем и т.д., то для лучшего контроля нужно отделить тестируемые классы друг от друга, заменить их с помощью “заглушек”, “имитаций”. Например, если мы тестируем код класса принимающего имя и пароль, а затем проверяющего его по базе данных (а это уже второй класс), то можно заменить класс, работающий с реальными данными “имитацией”, которая не обращается к базе данных за сведениями, а хранит эти данные внутри самого класса. Т.е. предполагается, что имитация должна быть достаточно проста, чтобы не содержать ошибок – в противном случае говорить о модульном тестировании нельзя.

После модульного тестирования мы начинаем говорить, что тесты следует выполнить для всего приложения в сборе – этим занимается интеграционное тестирование. Этот вариант является достаточно трудоемким: выполнять “сборку” приложения в единое целое из множества разрозненных модулей требует много времени и это нельзя делать каждые 10 минут или после внесения правок в один из методов. Здесь имеет смысл использовать системы автоматического тестирования, которые срабатывают по некоторому закону (например, в конце рабочего дня или как только изменения были помещены в общий репозиторий). Тогда скрипт тестирования “вытягивают” из репозитория SVN файлы и нужные для работы библиотеки, затем выполняет тесты. Отчеты же об найденных ошибках публикуются и доступны для пришедших с утречка программистов. Третий вид тестирования – системное – делится на альфа-тестирование и бета- тестирование. В первом случае мы набираем небольшую команду тестеров (работающих в нашей организации), которые пытаются использовать программу, ищут в ней ошибки. Бета-тестирование похоже на альфа-тестирование, но отличается кругом привлеченных лиц: их больше и это посторонние (не наши сотрудники и работающие не за зарплату) люди. Бета-тестирование - это еще и инструмент продвижения программы на рынок: мы можем представить бета- тестерам бесплатную версию ПО, даем скидки на последующую покупку, надеемся на то, что тестеры расскажут о “классной” программе своим друзьям.

Очевидно, что (а кое-кому совсем не очевидно), что выпускать на публичный тест не доделанную и “глючную” программу не самый умный поступок. Сегодняшний рассказ будет посвящен специальному инструменту для автоматизации системного и интеграционного тестирования при разработке, именно, веб-приложений – bayboy. Badboy похож на магнитофон: вы открываете страницу сайта, жмете на кнопку “начать запись” и затем работаете с сайтом (ходите по ссылкам, отправляете формы), все эти действия badboy записывает в виде сценария действий. Завершив запись, вы можете проиграть ее в любой момент и оценить результат выполнения каждого шага (ага, после отправки формы авторизации на экране должна была появиться надпись “Привет, Вася”, а ее нет, значит, тест провален). Badboy не единственный продукт такого класса и, наверняка, не самый лучший (тут я надеюсь на то, что те, кто профессионально занимается QA, выскажутся и поделятся своим опытом). С badboy я познакомился несколько месяцев назад, когда передо мной поставили задачу научить человека писать сценарии тестирования веб-приложений. Самым известным среди подобных инструментов для тестирования является Jmeter (http://jakarta.apache.org/jmeter/index.html). К сожалению, он не прост и совсем не похож на большой магнитофон с парой кнопок “запись-воспроизведение”, и поэтому я провел небольшой поиск в internet и нашел badboy. Оказалось, что badboy (такой простой и понятный) не только записывает сценарий, но и умеет экспортировать сценарии в jemeter (а там мы можем скрипт “обработать напильником” до нужной кондиции). Такая связка показалась мне наилучшим способом для быстрого старта, всем кто хочет заняться веб-тестированием.

Предположим, что вы загрузили и установили Badboy (домашний сайт проекта http://www.badboy.com.au/). Собственно говоря, Badboy не бесплатный (в отличии от Jmeter), но никаких проблем в использовании пробной версии вместо платной полной я не встретил. Очень приятно, что помимо неплохой документации в составе badboy есть почти интерактивный учебник, показывающий по шагам основные приемы работы (меню “Help -> Tutorial”). Теперь разберемся с терминологией: основные понятия это Suites, Tests, Steps. В общем случае, тестируемое приложение не тривиально: оно состоит из набора страниц, которые можно использовать по-разному (например, веб-интерфейс для почтовой системы содержит пусть и не очень много страничек, но большое количество различных действий). Очевидно, что глупо создать супер-огромный скрипт тестирующий абсолютно все. Поэтому мы представляет тесты как логически упорядоченное “дерево”. Верхний уровень теста, например, тестирование открытой части сайта и закрытой. Затем тест открытой состоит из теста новостей, теста формы регистрации и т.д. Количество таких вложенных уровней не ограничивается. Suite – это набор тестов, а каждый тест (Test) состоит из шагов (Steps). Step – это элементарная единица работы (имитировать нажатие на кнопку, отправить форму и т.д.). На рис 1. окно с деревом “suite->test->step” имеет пометку “1”.



Рис. 1.

Что и как записывает badboy? Когда вы нажали на ссылку или кнопку, то badboy выжидает 500 миллисекунд и если в течении этого времени браузер начал загрузку новой страницы, то относит ваше действие к разряду активных, если действия нет – к разряду пассивных событий. Все активные действия записываются в сценарий (и это без вариантов, хотя в последствии вы можете подправить сценарий вручную), будут ли записаны пассивные действия определяется в меню “Preferences” на закладке “recording”. Там же можно настроить будут ли записываться запросы браузера к странице, если они были инициированы с помощью javascript. Далее: есть два режима записи “Request Mode” и “Navigation Mode”. В первом случае badboy помещает в сценарий запросы, посылаемые браузером, во втором случае badboy имитирует действия человека (те же нажатия на кнопки). Эти режимы следует четко отделять друг от друга и понимать когда нужно использовать один из них. Например, если вы тестируете форму с кнопкой и использовали первый режим (Request Mode), то Badboy записал то, какие данные отправляются серверу при активации кнопки. Теперь предположим, что кнопка куда-то пропала, очевидно, что тест должен быть провален. Ничуть: первый режим отправляет веб-запрос, а не пытается “нажать” на кнопку, чтобы запрос был отправлен браузером. Или еще пример: по нажатию на кнопку отправляется форма, часть полей которой является вычисляемой браузером (например, текущее время). Очевидно, что в режиме “Request Mode” данные будут отравляться одни и те же. С другой стороны при тестировании производительности сервера, когда веб-приложению посылается одновременно несколько сотен запросов, то режим “Navigation Mode” не приемлем: просто физически не возможно открыть эту сотню браузеров, имитировать “клик” по кнопке, чтобы выдержать темп тестирования. Отсюда вывод: для тестирования корректности интерфейса используем режим “Navigation Mode”, для теста функциональности сайта и его производительности – режим “Request Mode” (для переключения в ходе записи сценария между этими двумя режимами просто зажмите пару клавиш “Ctrl+Alt”).

Попробуем записать небольшой сценарий, для этого включаем режим записи (клавиша “F2”). Затем в адресной строке вводим адрес сайта и видим то, как в дереве “Suite->Test->Step” появляется новый узел (пока идет выполнение запроса цвет элемента красный). После завершения загрузки попробуйте раскрыть только что добавленный узел, там вы увидите время, которое было затрачено на загрузку страницы, ее размер. Все выполняемые вами действия будут записаны, попробуйте открыть всплывающее окно и тут же его закрыть (при этом в дерево “шагов” будет добавлено действие “Close Active Browser”). Для качественного теста нам потребуется не просто набор страниц, но сайт, где можно отправить форму (например, регистрация на почтовом сайте). Посмотрите на рис. 2, там я показал как будет выглядеть запрос выполненный из формы: если раскрыть узел с названием запрошенной страницы, то мы увидим перечисление всех полей, которые были посланы на сервер. На этом описание методики записи теста будем считать завершенным, не забывайте только разбивать тест на части (на панели инструментов рядом с кнопками, запускающими и останавливающими запись, есть кнопки “Create New Suite” и “Create New Test”).



Рис. 2.

Далее: мало записать последовательность действий - нужно добавить условия, проверяемые после каждого шага. Если мы так не сделаем, то не возможно будет определить то, правильно ли работает сайт, разве что сидеть перед экраном и на глазок оценивать те ли страницы загружаются badboy- ем? Для этого остановим запись и перейдем к первому шагу в сценарии (если вызвать контекстное меню для произвольного Step-а, затем выбрать пункт “Play”, то этот шаг будет проигран и в основной области экрана badboy будет загружена соответствующая страница). Там же в контекстном меню есть функции для удаления Step-ов из сценария или их временного отключения (“Disable”). Итак: есть два способа добавить условие проверяемое после выполнения Step-а: во-первых на панели кнопок есть функция “Create Easy Assertion”, ее назначение добавить в сценарий Assertion (утверждение) состоящее из одного Check-а (условия). Assertion, в общем случае, состоит из нескольких check-ов, а check – это то, что должно быть проверено на странице. И если check не выполняется, то не выполняется и родительский для него Assertion. Самым простым видом check-ов является проверка того, что на странице присутствует какой-то кусочек текста (например, после отправки формы авторизации, если на странице не найдется фраза “Здравствуй, Петя”, то мы уже знаем, что процедура входа не была выполнена и тест считается проваленным). Именно такой check создается при нажатии “Create Easy Assertion”. Можно создавать Assertion и через контекстное меню: здесь надо выбрать пункт “Insert -> Assertion”, так мы добавим после Step-а условие. Вот только Assertion будет пуст (без вложенного check-а), но мы это легко поправим. Для этого на панели инструментов (на рис. 1 она помечена цифрой 2) перейдите на закладку “checks” и перетащите внутрь Assertion-а один из доступных check-ов (для каждого из них с помощью контекстного меню и пункта “Properties” можно изменить условия проверки):

1. Content Check – проверка наличия в тексте страницы (в любом ее месте) некоторой фразы. В качестве параметров настройки check-а задается, собственно, текст, который нужно найти на странице. Также можно изменить условие на противоположенное: check будет пройден, если только эта фраза не будет найдена. Самое приятное в том, что можно искать не просто кусочек текста, но и регулярное выражение. Да еще, если ваш сайт использует фреймы, то badboy умеет искать текст и внутри их.

2. Color Check – служит для проверки того, что в некоторых координатах страницы (можно их указать с некоторой дельтой погрешности) должен находиться пиксель заданного цвета. Проще всего после добавления check-а в окне его настроек нажать кнопку “Capture”, затем выполнить “клик” по нужному месту веб-страницы открытой в badboy (координаты “клика” и цвет пикселя в этом месте будут автоматически назначены как условие check-а).

3. Response Check – его назначение оценить время загрузки страницы или ее размер.

4. Jscript Check представляет самую гибкую функцию оценки – вы можете в окне свойств check-а в специальное текстовое поле ввести фрагмент кода на javascript (результат работы должен быть логической величиной и будет значением check-а).

5. Summary Check – дает возможность оценить “итоговые” результаты работы того Step-а, в который вложен данный check. Например, мы говорим, что операция загрузки страницы должна быть выполнена 100 раз, и если из них более 5 операций завершились timeout-ом, то тест провален.

6. Variable Check – служит для проверки того, что некоторая переменная (что такое переменные и как их использовать я расскажу чуть позже) равна или не равна некоторой величине.

Наполнив Assertion условиями (check) вызовем контекстное меню и рассмотрим какими параметрами Assertion-а можно управлять. Прежде всего, настроим поведение теста в случае, если произошел сбой, т.е. какой-либо из check-ов был провален (падающий список для пункта “When violated -> Action”). Можно потребовать вывести окно сообщения о возникшей ошибке (см. рис. 3), в падающем списке “When Violated -> Action” выберите пункт “Alert me”. Можно потребовать сделать скриншот экрана браузера с ошибкой. Где можно увидеть этот скриншот? Картинки не складываются в какую-то папку (это было бы не удобно для последующего поиска). Вместо этого после выполнения теста к узлу дерева Assetion будут добавлены еще вложенные узлы, содержащие статус выполнения check-а (только если check был провален), и если выполнить двойной клик по этому узлу, то откроется картинка скриншота. Assertion применяется к step-у, после которого он размещен в дереве проекта, однако, бывает ситуация когда некоторое условие должно проверяться постоянно (для каждого из step-ов в тесте). Например, после процедуры авторизации на всех страницах в углу должна быть надпись “Пользователь: Вася”. За настройку подобной “глобальности” (все Step-ы в рамках текущего Test-а) отметьте в свойства Assertion-а “галочку” “Cascade To Following Items”. Помните только, что Assertion не будет применяться к шагам расположенным в том же Step-е, но раньше, чем сам Assertion, а если расположить такой “глобальный” Assertion внутри не Test-а, а целой Suite, то условие будет проверяться для всех Test-ов и вложенных в них Step-ов. Если мы проверили check и он был провален, то не всегда имеет смысл продолжать дальнейшее выполнение теста (если операция авторизации на почтовом сайте была неуспешна, то какой смысл выполнять остальные тесты?). Обратите внимание на падающий список с вариантами “When Violated -> Continuation”. Именно здесь вы можете указать, что хотите либо “Continue from same position” (тест будет продолжаться дальше), “Abort *” (несколько вариантов команд начинающихся со слова “Abort” позволяют прервать выполнение текущего теста, или всего набора тестов). С вариантом “Repeat The Containing step” нужно быть острожным т.к. он приводит к повторному выполнению того теста, в который вложен данный Assertion, и если условие никогда не выполнится, то вы попадаете в настоящий бесконечный цикл.



Рис. 3.


Теперь, создав заготовку теста, мы можем его “проиграть”, для этого используйте снова контекстное меню на любом из пунктов дерева (на Suite, Test или отдельном Step-е) и выберите пункт Play. Вы можете наблюдать за работой badboy не только на основном экране, также узлы дерева проекта по очереди меняют свой цвет на зеленый (признак того, что этот шаг сейчас выполняется). После завершения теста удобно окинуть взглядом выполненные шаги и статусы их завершения (меню “View -> Report”). По-умолчанию badboy при очередном запуске теста не очищает добавленные на дерево проекта фиктивные узлы (результаты проверок check-ов, время выполнения запросов), для этого используйте меню “Tools -> Clear Responses”.

Предположим, что мы тестируем форму регистрации на сайте: мы заполняем форму, отправляем ее, проверяем наличие на сформированной странице фразы вроде “Вы успешно зарегистрированы”. Увы, но повторный запуск такого сценария должен завершиться неудачно. Даже если новых ошибок в коде сайта не появилось. Почему? Вот, к примеру, поле логин_пользователя, ведь оно должно быть уникальным, не так ли? А разве при повторном запуске сценария, то значение, которое мы вводили в форму регистрации, само поменяется? Конечно, нет. Так что перед каждым запуском сценария вы должны либо очищать базу данных сайта, либо изменять значения переменных. Обычно эти два подхода совмещаются: и базу очищаем (для этого неплохо иметь какую-нибудь служебную страницу, например, truncate.php), но и значения полей придется менять. Особенно ярко это проявится при нагрузочном тестировании, когда одновременно на сайт будут посылаться несколько сотен запросов (ведь все они должны быть разными). В badboy изменять параметры запроса можно двумя способами: во-первых, в дереве сценария работает поиск и замена (в диалоговом окне обратите внимание на поле Mask). Дело в том, что простая замена во всем сценарии, например, слова “vasya” на “petya” не всегда хороша: нам нужен механизм более точного указания на то, в каких строках искать некоторое слово. И как раз в поле Mask, вы в виде регулярного выражения (с урезанным синтаксисом) задаете шаблон строки. Однако поиск и замена слишком не удобны для частого использования и поэтому в badboy ввели понятие “переменных”. Для примера выполните запись отправки html-формы, затем раскройте дерево сценария и вызовите контекстное меню на элементе (поле) формы (см. рис. 4) и выберите пункт “Add as Variable” или "Add Linked Variable”. В первом случае будет добавлена обычная переменная с именем равным имени поля формы, значение же переменной вы введете в появившемся диалоговом окне. Визуально значение параметра формы должно измениться и выглядеть как показано на рис.4, где значение параметра action и user равны, соответственно, “${action}” и “${user}” (для вставки в сценарий переменных нужно использовать именно такой синтаксис со знаком доллара и фигурными скобками). Отличие команды “Add linked variable” от просто “Add as variable” в том, что автоматически будет выполнен поиск в сценарии других параметров для http-запроса, которые имеют такое же значение переменной, затем их значения также будут заменены на только что созданную переменную.

И последний вид переменных – Hostname variable (ее вы можете найти в меню “tools -> create hostname variable”), позволит вам хранить адрес сервера в виде отдельной переменной, а значит легко менять адреса всех тестируемых страниц, если веб-приложение будет переезжать с одного сервера на другой.



Рис. 4.

Все созданные вами переменные будут помещены на закладку “variables” расположенную в нижней левой части окна badboy. Для редактирования переменных просто используйте “двойной клик” или контекстное меню на их именах. Теперь попробуйте так сделать и внимательно рассмотрите диалоговое окно свойств переменной. Для хорошего теста веб-приложения было бы неплохо создать список возможных значений некоторой переменной, чтобы не вводить их каждый раз заново при очередной “прогонке” теста, а выбирать из списка готовых. И badboy это умеет: используйте для этого список Value List (рядом расположенная кнопка Current устанавливает текущее значение переменной). Однако, “самую силу” списки значений переменных приобретают только тогда, когда их используют совместно с еще одним механизмом модификации сценария – Increments, но об этом чуть позже, а пока еще раз вызовите окно настроек переменной и внимательно посмотрите на поля “Auto-update with expression”. Предположим такой сценарий тестирования: есть две веб-страницы, которые формируются некоторым скриптом. Для первой из них мы можем послать запрос, используя обычные переменные, а вот для второй – нет. Нам нужно отправить такую переменную, значение которой неизвестно на стадии составления скрипта тестирования, обычно, это некоторый кусочек текста находящийся на предыдущей странице. Например, найти на странице фрагмент текста следующего вида “result=какая-то цифра”, извлечь значение этой цифры и послать его во втором запросе как переменную “number”. Так что, если вы в окне свойств переменной отметите “галочку” напротив “Auto-update with expression”, затем в чуть ниже расположенное поле введете текст регулярного выражения, то это значение будет найдено и присвоено переменной. Точнее сказать, переменной будет присвоено значение той части регулярного выражения, которая заключена в круглые скобки. Возвращаясь к старому примеру, регулярное выражение должно выглядеть так “result=(\d+)”. Недостаток подобного автоматического вычисления, в слабом контроле над моментом времени, когда нужно вычислить значение этой переменной (например, это нужно сделать только после получения текста одной единственной страницы и не делать для других страниц). Я предпочитаю использовать механизм Variable Setter. Если вызвать контекстное меню на дереве сценария, затем выбрать пункт “Add -> Variable Setter”. То появится диалоговое окно похожее на встречавшееся вам ранее окно свойств переменной (с таким же полем для ввода регулярного выражения, кроме того, можно указать еще и фрейм где искать переменную). Гибкость в том, что Variable Setter можно расположить в дереве сценария точно в нужном месте. А вот еще трюк при использовании Variable Setter: предположим, что в рамках одного теста вы загружаете множество страниц, на какой-то из них должен встретиться фрагмент вида “result=число” (так же как и в прошлый раз я хочу ). Во-первых, глупо вставлять такой Variable Setter после каждого из множества запросов (тут вам поможет в свойствах Variable Setter опция “cascade to following items”). Также я хочу, чтобы значение переменной было бы присвоено только в том случае, если на странице был найден фрагмент “result=число” (если вы не отметите опцию “Do not overwrite with blank”, то значение переменной будет утеряно).

А вот еще один пример, как создать сценарий, работающий с переменными, но уже не простыми (распложенными внутри badboy), а хранящимися во внешнем файле, например, excel. Для примера создайте excel-документ, с небольшой табличкой из двух-трех колонок имитирующих некоторые переменные (названия колонок обязательно должны быть). Теперь вернемся в badboy и вызовем меню “Tools -> DataSource -> Attach Variable Source”. В появившемся диалоговом окне нас спросят тип источника данных (файлы excel, access, dbbase …). Мы, конечно, выберем excel как тип источника данных, затем укажем путь к файлу и лист, на котором находится табличка с информацией. Последний шаг – привязка переменных в excel-файле к параметрам для веб-запроса, после чего для каждой переменной будет создан и заполнен значениями из excel список Value List (при изменении данных в excel, badboy автоматически обновляет список значений переменных). Добиться той же функциональности (мне этот способ кажется более логичным, и очевидным), можно с помощью инструмента “Data Source Item” (его вы можете найти на закладке Tools). После того как вы перетяните “Data Source Item” на дерево сценария, то должны будете (точь-в-точь как в прошлом способе привязки к переменным значений из внешнего файла) указать тип источника данных, имя файла, название листа, имена переменных, которые импортируются из excel-документа.

Последний вид переменных - это глобальные переменные (в отличие от предыдущих эти переменные не отображаются на закладке “Variables”). Они будут передаваться во все скрипты и их не нужно явно указывать в дереве сценария (см. меню “Preferences” закладка “Variables”). Фокус в том, что глобальные переменные не являются частью вашего скрипта тестирования, а являются настройками самого badboy, поэтому будьте осторожны, ведь изменив одну из таких переменных, вы можете “поломать” рабочий до этого момента скрипт.

Несмотря на то, что мы рассмотрели несколько способов создания переменных не с одним значением, а множеством (списком), практической пользы от них нет до тех пор, пока мы не научимся выполнять сценарий тестирования несколько раз, обновляя при этом значение указателя на текущий элемент списка. Для этого используйте контекстное меню на дереве сценария, пункт “Add -> Increment”. В появившемся диалоговом окне необходимо указать значение какой переменной должно быть увеличено (либо все переменные, либо только одна, выбранная из падающего списка “variables to increment”). Затем указывается стратегия увеличения: Random Integer, Next List Value, Sequential Integer. В первом случае значение переменной будет равно случайному числу, в третьем случае – переменная будет принимать последовательные значения 1,2,3… Надо сказать, что в этих двух случаях переменная не обязательно должна быть целым числом, она может быть и строкой, самое главное чтобы эта строка заканчивалась на некоторую цифру, например “user1” (тогда в режиме Sequential Integer переменная будет принимать значения “user2”, “user3” …). И, второй вариант – Next List Value, наиболее интересен для нас: он позволяет перебирать переменной список привязанных к ней значений. Для примера я создал Test, в него я поместил “Data Source Item” загружающий переменные из excel. Затем внутрь Test был помещен Step отправляющий веб-запрос с двумя переменными (fio, age) как показано на рис. 5 (я специально отказался от Increment-а). Осталось только найти способ выполнять эту последовательность шагов несколько раз. Для этого вызываем контекстное меню на элементе Step и открываем диалоговое окно его свойств и видим, что в графе “Repeat” мы можем указать сколько раз должен выполниться “шаг”. Либо фиксированное количество раз, либо столько раз, сколько значений в списке для некоторой переменной (выбираем эту переменную в падающем списке и еще обязательно отметьте “галочки” “Increment variable automatically” и “Increment all variables from same data source”). Эти галочки нужны для того, чтобы в цикле происходило увеличение выбранной переменной, а также всех остальных переменных загруженных из одного и того же источника данных (файла excel). Как только мы научились делать циклы для тестов, то неплохо было бы создать Assertion, умеющий работать и с циклами, и с переменными (например, excel файл содержит три колонки цифр, мы посылаем две первые из них на сайт, а результирующая страница должна содержать значение из третьй колонки). Вспоминайте прошлую статью: нельзя просто делать какие-то шаги в сценарии – нужно контролировать успешно ли они выполнились (именно этим занимается Assertion). Простого “за один клик” решения я не нашел, так что пришлось делать так: создать в сценарии после отправки запроса на сервер, во-первых, элемент Variable Setter. Он должен присвоить значение переменной “if_ok”, по следующей формуле “result=(${thirdcolumn}) ”. Здесь предполагается, что excel-файл содержит третью колонку с именем thirdcolumn, и именно ее значение должно быть помещено на веб-страницу в виде строки “result=значение”. Для того чтобы в строке regexp-а я мог использовать badboy-переменные (синтаксис с $ и фигурными скобками), нужно в свойствах элемента Variable Setter установить значение флажка “Parse variable references in expression”. Если на странице действительно найдется правильное значение третьей колонки, то переменная “if_ok” будет не пустой. Поэтому сразу за Variable Setter (последнее действие внутри Step-а) я добавляю Assertion. А в качестве проверяемого условия использую “Variable Check” (закладка “Checks”). В свойствах check-а в падающем списке выбирается значение переменной, значение которой нужно проверить (это переменная “if_ok”), а в поле “regexp” вводится регулярное выражение, которому должна быть равна эта переменная (я указал “.+”, что значит “не пустая строка”).



Рис. 5.

Из чего еще можно составлять сценарий? Снова обратимся к закладке Tools.

1. Cookie Killer (неправда ли, “говорящее” название). Итак, Cookie Killer удаляет все cookie полученные в текущем сеансе. Это очень полезный механизм для тестирования системы авторизации: общепринято, что после успешной авторизации в cookie помещается некий флажок с признаком того, что человек прошел проверку, на основании этого же флажка, на сервере ведется сессия. Завершение работы с сайтом может быть выполнено либо с помощью специальной ссылки вида Logout, либо автоматически: авторизация должна быть потеряна спустя некоторое время (например, 15 минут). Естественно, что никто не будет создавать такой сценарий теста, в котором целенаправленно создается пауза между несколькими Step-ами в те самые 15 минут (хотя подобная возможность в badboy предусмотрена). Поэтому мы можем имитировать истечение 15 минут (срока давности для cookie) с помощью Cookie Killer.

2. Navigation. В прошлой статье я уже упомянул о том, что badboy может работать в двух режимах записи сценария: имитация отправляемых из браузера запросов и имитация действия с интерфейсом веб-страницы (клики мышью). Элемент navigation как раз и служит для указания на то какое действие нужно выполнить и с каким html-элементом (все это можно изменить в настройках элемента Navigation).

3. Save Item или же Send Email. Механизм, позволяющий сохранить некоторую величину в файл (можно либо затирать старое содержимое, либо добавлять информацию в конец файла). Еще информацию можно отправить по почте. Что касается самой информации, то это может быть произвольный кусочек текста Expression (в тексте можно использовать badboy-переменные), или содержимое текущего окна браузера. Может быть полезен и прием с добавлением Save Item в самый конец сценария тестирования, с тем чтобы послать по почте сформированный html-отчет о результатах тестирования (например, при запуске тестов по расписанию – badboy и такое умеет).

4. Mouse Click – этот элемент сценария служат для имитации событий мыши (например нажатия правой или левой кнопки мыши в заданных координатах). Похож на Mouse Click и такой элемент как Keys Item – он служит для имитации событий с клавиатурой. Вы можете не просто ввести несколько букв, но и сымитировать более сложное действие, например, нажатие комбинации ALT+F4. Для этого вы вводите в текстовом поле следующую “абракадабру” “{VK_MENU:DOWN}{VK_F4}{VK_MENU:UP}”. В документации badboy приводится описание кодов и других специальных клавиш (функциональные, клавиши управления курсором), все они заключаются в фигурные скобки.

5. Window Control. Служит для закрытия либо активного окна браузера, либо всех всплывающих окон.

6. Screenshot. Позволяет сделать копию экрана и сохранить ее в отдельный файл (к сожалению, нет способа управлять правилами именования файлов, так чтобы называть их pic1.jpg, pic2.jpg …). Если вы будете пользоваться не бесплатной версией badboy, а приобретете лицензию, то кроме скриншота можно сохранить картинку, содержащую график времени загрузки страниц сайта (еще этот график можно увидеть на закладке Graph).

7. MessageBox. Важно, что MessageBox не служит для того, чтобы показывать всплывающие окна сообщений, совсем наоборот. Если вы разрабатываете сайт с большим количеством javascript, то вероятнее всего ваш код не только вычисляет что-то, но и может потребовать у пользователя ответы на вопросы в форме всплывающего диалогового окна с кнопками “OK” и “Cancel”. Более того, javascript может попросить у пользователя ввести некоторое текстовое значение (функция prompt). Как раз для имитации нажатия на одну из кнопок “OK” и “Cancel” служит элемент MessageBox. Нужно только поместить MessageBox до (именно, до) элемента веб-запроса. В свойствах элемента MessageBox нужно указать время ожидания в секундах до автоматического нажатия на одну из кнопок (какая из двух кнопок также указывается в свойствах), и, самое важное, нужно указать шаблон текста окна с сообщением, на которое будет реагировать данный MessageBox. Если на html-странице появляется несколько диалоговых окон, то просто разместите такое же количество MessageBox (момент в том, что время закрытия окна рассчитывается по порядку, а не одновременно для всех MessageBox). Для имитации работы с prompt простого решения нет, к счастью, в серьезных приложениях прием с prompt считается не рекомендуемым.

В следующий раз я завершу рассказ об badboy. Нам осталось рассмотреть методику как запустить несколько тестов одновременно, как будто бы сайт посещает несколько человек одновременно. Также я расскажу об JMeter, мы попробуем написать небольшой сценарий тестирования веб-сайта с его помощью или, как вариант, создать сценарий в badboy с последующим переносом его в jmeter.



black-zorro@tut.by, black-zorro.com
обсудить статью
© сетевые решения
.
.