11.5.4 Параметризация
Для параметризации запросов добавляется в самый верх элемент User Define
Variables. Thread > Config Element > User Define Variables. Внизу есть кнопка Add. После ее нажатия добавляются две переменные, т.к. меняться будут только два параметра: логин и пароль.
Им задаются имена: user и pswd. А в качестве значений указываются конкретные значения текущего пользователя. На рисунке 11.12 можно увидеть добавления.
Рисунок 11.12 - User Defined Variables
Чтобы их использовать нужно перейти в запрос Логин/пароль, и вместо конкретных значений записать имена переменных в формате ${имя переменной}. В данном примере указываются в поля
Value для логина — ${user}, для пароля — ${pswd}. На рисунке 11.13 можно увидеть добавление параметров.
87
Рисунок 11.13 - Параметризация логин и пароля
Для отладки передачи параметров добавляется еще один элемент – Debug Sampler. Thread >
Add > Samplers > Debug Sampler. В настройках элемента остается только Jmeter variables, остальные параметры в значение false. На рисунке 11.14 это изображено.
Рисунок 11.13 - Настройка Debug Sampler
После запуска в View Results Tree должны появится результаты. На них можно увидеть, что в качестве переменных передались именно те значения, изображение 11.14, которые были заданы, и запросы в целом вернули то, что нужно.
Рисунок 11.14 - Просмотр параметров
Теперь можно передать данные 5 пользователей. Для этого используется CSV Data Set Config.
88
11.5.5 CSV Data Set Config
Создается .csv файл в блокноте. Для пользователей файл должен представлять собой набор из
5 строчек вида «user; pswd», как показано на рисунке 11.15
Рисунок 11.15 - CSV-файл с пользователями и паролями
Далее в дерево добавляется элемент CSV Data Set Config (Add > Config Element > CSV Data
Set Config). Лучше его добавить не в катушку, а в тест-план, ниже пользовательских переменных.
В качестве filename для файла нужно указать полностью путь к файлу и его имя. Ниже указать кодировку (на ваш выбор). Если все данные на английском, то поле можно оставить пустым. Ниже необходимо написать переменные, которые считаются из файла. В качестве примера, это будут user и pswd. В качестве разделителя нужно указать точку с запятой, так как в файле используется она. Нужно поставить в false повтор файла по достижении конца, а также остановку катушки.
Настройка CSV Data Set изображена на рисунке 11.16
Рисунок 11.16 - Настройка CSV Data Set Config
Далее необходимо удалить подобные переменные из User Defined Variables. После этого в самой катушке количество потоков (Number of Threrads) устанавливается на 5. Теперь можно
89
запустить скрипт и наблюдать в Debug Sampler и View Results Tree результаты, рисунок 11.17.
Нужно не забыть проверить, те ли данные вернул сервер, есть ли в них имена созданных пользователей.
Рисунок 11.17 - Результат
11.5.6 Создание ФА
После создание скрипта на вход в систему, нужно проделать тоже самое, только для создания финансового анализа. Для этого нужно опять включить прокси-сервер и поставить галочку в браузере "использовать прокси-сервер". В Jmeter создается второй Recording Controller, который был назван "Создание ФА". Нужно не забыть поменять Target Controller в прокси на dwarf >
Создание ФА, как показано на рисунке 11.18.
Рисунок 11.18 - Изменение цели
90
После записи скрипта (создание ФА)
получается следующий результат, изображенный на рисунке 11.19.
Рисунок 11.19 - Скрипт создание ФА
Данный скрипт нужно отчистить от мусора, оставить только самое нужное и поменять для удобства имена запросов.
При создании скрипта ФА нужно знать следующее:
при создании ФА присваивается уникальный и неповторимый id;
результат ФА также имеет уникальный скрытый id.
Следовательно, необходимо параметризовать эти 2 id.
Для параметризации скрытого id используется CSV Data Set Config еще раз, как показано на рисунке 11.20.
Рисунок 11.20 - Параметризация скрытого id
91
Для параметризации уникального id, при создании ФА, нужно его сначала достать. Для этого используется элемент (dwarf > Add > Post Processors > Regular
Experssion Extractor). Уникальный id находится в адресной строке и имеет приблизительно следующий вид: fa/analysis?analysis_type=fa&incomplete_id=1378393412734465, где incomplete_id и есть идентификатор.
В Reference Name указывается имя параметра в Regular Expression записывается регулярное выражение, которое будет доставать нужный id при создании нового ФА. $1$ - означает порядок расстановки регулярного выражение, в нашем случае оно одно. Если бы было их 2, то запись должна быть $1$$2$. На рисунке 11.21 изображены настройки Regular Expression Extractor.
Рисунок 11.21 - Настройка Regular Expression Extractor
Теперь нужно заменить установленный id в скрипте на параметризованный. Вместо фиксированного идентификатора устанавливается созданный параметр, как показано на рисунке
11.22
Рисунок 11.22 - Замена на параметр
92
Все эти манипуляции с id были для того, чтобы каждый пользователь создавал новый ФА, а не пересоздавал уже созданный анализ.
Была поставлена следующая задача: нужно выяснить в каком месте, при создании ФА, серверу необходимо много времени для ответа, при высокой нагрузки на него.
Для этого была сымитирована ситуация, когда в системе находится одновременно 50 пользователей и они создают финансовый анализ. Для этого в Thread Group было проставлено количество пользователей 50, а время, в течении которого эти 50 пользователей окажутся в системе, 10 секунд, как показано на рисунке 11.23. Т.е. за 10 секунд в системе будет работать 50 пользователей. Возможно такой ситуации на самом деле маловероятно, но задача сейчас выяснить потенциально слабое место в системе.
Рисунок 11.23 - Установка 50 пользователей
Для того, чтобы точно определить слабое звено был использован элемент View Results in
Table (dwarf > Add > Listener > View Results in Table). На рисунке 11.24 изображен результат.
Рисунок 11.24 - Результат
93
Из таблицы можно увидеть, что самое слабое звено в системе - это формирование результата анализа, т.к. время, которое нужно серверу для этого действия, с
каждым разом растет, и в итоге может достигнуть критической отметки - 30 сек. В результате этого пользователь будет долго ждать свой анализ, а в веб-приложении это критический параметр. Соответственно, для того, чтобы этого не происходило нужно что-то сделать с формированием результата, чтобы это действие занимало меньше времени, а также нагрузка на сервер была низкая.
94
12 АВТОМАТИЗИРОВАННОЕ ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ Автоматизированное тестирование ПО (
Automation Testing)
- это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования [6].
12.1 Преимущества и недостатки С автоматизацией тестирования, как и со многими другими узконаправленными IT - дисциплинами, связано много неверных представлений. Для того, чтобы избежать неэффективного применения автоматизации, следует обходить ее недостатки и максимально использовать преимущества.
Преимущества автоматизации тестирования: повторяемость – все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор». Тестировщик не пропустит тест по неосторожности и ничего не напутает в результатах;
быстрое выполнение – автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения;
меньшие затраты на поддержку – когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную;
отчеты – автоматически рассылаемые и
сохраняемые отчеты о результатах тестирования;
выполнение без вмешательства – во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время (этот метод предпочтительнее, так как нагрузка на локальные сети ночью снижена).
Недостатки автоматизации тестирования (их тоже немало): повторяемость – все написанные тесты всегда будут выполняться однообразно. Это одновременно является и недостатком, так как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и, проведя несколько дополнительных операций, найти дефект. Скрипт этого сделать не может;
затраты на поддержку – несмотря на то, что в случае автоматизированных тестов они меньше, чем затраты на ручное тестирование того же функционала – они все же есть.
Чем чаще изменяется приложение, тем они выше;
95
большие затраты на разработку – разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. В сложных автоматизированных тестах также есть фреймворки, утилиты, библиотеки и прочее. Естественно, все это нужно тестировать и отлаживать, а это требует времени;
стоимость инструмента для автоматизации – в случае если используется лицензионное
ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты как правило отличаются более скромным функционалом и меньшим удобством работы;
пропуск мелких ошибок - автоматический скрипт может пропускать мелкие ошибки на проверку которых он не запрограммирован. Это могут быть неточности в позиционировании окон, ошибки в надписях, которые не проверяются, ошибки контролов и форм с которыми не осуществляется взаимодействие во время выполнения скрипта.
Для того чтобы принять решение о целесообразности автоматизации приложения нужно ответить на вопрос «перевешивают ли в нашем случае преимущества?» - хотя бы для некоторой функциональности нашего приложения. Если нельзя найти таких частей, либо недостатки в вашем случае неприемлемы – от автоматизации стоит воздержаться.
При
принятии решения стоит помнить, что альтернатива – это ручное тестирование, у которого есть свои недостатки.
12.2 Применение автоматизации Автоматизацию нужно применять в следующих случаях: 1) труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в
БД);
2) часто используемая функциональность, риски от ошибок в которой достаточно высоки.
Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение;
3) рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения);
4) валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации);
5) длинные end-to-end сценарии;
6) проверка данных, требующих точных математических расчетов;
96 7) проверка правильности поиска данных.
А также, многое другое, в зависимости от требований к тестируемой системе и возможностей выбранного инструмента для тестирования.
Для более эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие:
базовые операции создания/чтения/изменения/удаления сущностей (так называемые
CRUD операции - Create / Read / Update / Delete).
Пример: создание, удаление, просмотр и изменение данных о пользователе;
типовые сценарии использования приложения, либо отдельные действия.
Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это
end-to-end сценарий, который проверяет совокупность действий. Мы предлагаем вам использовать именно такие сценарии, так как они позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты;
интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную.
Пример: система создает некоторый xml файл, структуру которого необходимо проверить.
Это и есть функциональность, от автоматизации тестирования которой, можно получить наибольшую отдачу.
12.3 Как автоматизировать В
данном разделе рассмотрены аспекты, влияющие на выбор инструмента автоматизации тестирования.
Во первых, нужно обратить внимание насколько хорошо инструмент для автоматизации распознает элементы управления в вашем приложении. В случае когда элементы не распознаются стоит поискать плагин, либо соответствующий модуль. Если такового нет – от инструмента лучше отказаться. Чем больше элементов может распознать инструмент – тем больше времени можно сэкономить на написании и поддержке скриптов.
Во-вторых, нужно обратить внимание на то сколько времени требуется на поддержку скриптов написанных с помощью выбранного инструмента. Для этого необходим простой скрипт, который выбирает пункт меню, а потом представьте, что изменился пункт меню который необходимо выбрать. Если для восстановления работоспособности сценария придется перезаписать скрипт целиком, то инструмент не оптимален, так как реальные сценарии гораздо сложнее. Лучше всего тот инструмент, который позволяет вынести название кнопки в переменную в начале скрипта и быстро заменить ее значение. В идеале – описать меню как класс.
97
В-третьих, насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код (поддержка ООП), насколько код читаем, насколько удобна среда разработки для рефакторинга (переработки кода) и т.п.
Лучше всего для принятия правильного решения об автоматизации отвечать на вопросы «Зачем? Что? Как?» именно в таком порядке. Это поможет избежать впустую потраченное время, нервы и финансы. С другой стороны можно получить надежность, скорость и качество.
12.4 Уровни автоматизации тестирования Условно, тестируемое приложение можно разбить на 3 уровня:
unit tests layer;
functional tests layer (Non-UI);
gui tests layer. Для обеспечения лучшего качества продукта, рекомендуется автоматизировать все 3 уровня.
Рассмотрим более детально стратегию автоматизации тестирования на основе трехуровневой модели:
Уровень модульного тестирования (Unit Test layer) Под автоматизированными тестами на этом уровне понимаются Компонентные или
Модульные тесты написанные разработчиками. Тестировщикам никто не запрещает писать такие тесты, которые будут проверять код, если их квалификация позволяет это. Наличие подобных тестов на ранних стадиях проекта, а также постоянное их пополнение новыми тестами, проверяющими «баг фиксы», уберегает проект от многих серьезных проблем.
Уровень функционального тестирование (Functional Test Layer non-ui) Не всю бизнес логику приложения можно протестировать через GUI слой. Это
может быть особенностью реализации, которая прячет бизнес логику от пользователей. Именно по этой причине по договоренности с разработчиками, для команды тестирования может быть реализован доступ напрямую к функциональному слою, дающий возможность тестировать непосредственно бизнес логику приложения, минуя пользовательский интерфейс.
Уровень тестирования через пользовательский интерфейс (GUI Test Layer) На данном уровне есть возможность тестировать не только интерфейс пользователя, но также и функциональность, выполняя операции вызывающую бизнес логику приложения. С нашей точки зрения, такого рода сквозные тесты дают больший эффект нежели просто тестирование функционального слоя, так как мы тестируем функциональность, эмулируя действия конечного пользователя, через графический интерфейс.
98
12.5 Архитектура тестов Для удобства наложения автоматизированных тестов, на уже имеющиеся тест кейсы,
структура тест скриптов должна быть аналогична структуре
тестового случая -
Precondition, Steps & Post Condition.
Получаем правило, что каждый тест скрипт должен иметь:
precondition;
steps (Test);
post Condition.
Перечислим основные функции скрипта:
1) precondition: инициализация приложения (например, открытие главной страницы, вход под тестовым пользователем, переход в необходимую часть приложения и подведение системы к состоянию пригодному для тестирования);
инициализация тестовых данных.
2) steps: непосредственное проведение теста;
занесение данных о результате теста, с обязательным сохранением причин провала и шагов, по которым проходил тест.
3) post condition: удаление, созданных в процессе выполнения скрипта,
ненужных тестовых данных;
корректное завершение работы приложения.
Рекомендуется также создать общую библиотеку по обработке ошибок и исключительных ситуаций. Например:
PreConditionException;
TestCaseException;
PostConditionException.
В итоге, воспользовавшись вышеописанными рекомендациями будет реализована общая архитектура тест скриптов и сценариев.
99
12.7 Проект по автоматизированному тестированию для начинающих Рассмотрение данного проекта преследует следующую цель: принести пользу начинающему тестировщику — автоматизатору, помочь быстро создать первый авто-тест и продолжить автоматизировать.
Установка приложений и настройка проекта Для работы потребуется:
Git;
Visual Studio 2010/2012;
Nunit 2.6.1;
Resharper (для удобства запуска тестов и дебага);
Selenium IDE — плагин для firefox (для удобства распознавания локаторов элементов на страницах).
Чтобы закачать проект из репозитория, необходимо в папке (где вы хотите его содержать) открыть git bash и выполнить команду:
git clone git://github.com/4gott3n/AT.git master Далее нужно открыть файл AT.sln в Visual Studio. Откроется Solution, содержащий проект
AT (фреймворк), а также пример тестового проекта, в котором можно увидеть реализацию страниц, тестов и т.д. (он является удобным примером для создания своего проекта).
Следующий шаг — создание проекта, который будет хранить все тесты, страницы и все остальное.
Скачать 2.21 Mb.