Тестирование ПО. Тестирование. Реферат актуальность. Основной всплеск интереса к теме тестирования пришёлся на 90е годы и начался в сша. Бурное развитие систем автоматизированной разработки
 Скачать 2.21 Mb.
|
|
Модель тестирования стабильности или надежности Используя базовый нагрузочный профиль, запускаем тест длительностью от нескольких часов до нескольких дней, с целью выявления утечек памяти, перезапуска серверов и других аспектов влияющих на нагрузку. 11.4 Обзор программ нагрузочного тестирования веб-сервисов Сдавая веб-сервер в повседневную эксплуатацию, нужно быть уверенным, что он выдержит планируемую нагрузку. Только создав условия, приближенные к боевым, можно оценить, достаточна ли мощность системы, правильно ли настроены приложения, участвующие в создании веб-контента, и прочие факторы, влияющие на работу веб-сервера. В этой ситуации на помощь придут специальные инструменты, которые помогут дать качественную и количественную оценку работы как веб-узла в целом, так и отдельных его компонентов. OpenSTA, рисунок 11.1- больше чем приложение для тестов, это открытая архитектура, проектируемая вокруг открытых стандартов. Проект создан в 2001 году группой компаний CYRANO, которая поддерживала коммерческую версию продукта, но CYRANO распался, и сейчас OpenSTA распространяется как приложение с открытым кодом под лицензией GNU GPL. Для работы требует Microsoft Data Access Components (MDAC), который можно скачать с сайта корпорации [12]. Текущий инструментарий позволяет провести нагрузочное испытание HTTP/HTTPS сервисов, хотя его архитектура способна на большее. OpenSTAпозволяет создавать тестовые сценарии на специализированном языке SCL (Script Control Language). Для упрощения создания и редактирования сценариев используется специальный инструмент Script Modeler. Выбирается 76 Tools – Canonicalize URL, поле запускается веб-браузер. Пользователь просто ходит по сайтам, собирая ссылки, которые будут сохранены в скрипт. Все параметры запроса поддаются редактированию, возможна подстановка переменных. Структура теста и заголовки будут выводиться во вкладках в панели слева. Тесты удобно объединять в наборы. Настройки прокси задаются в самом скрипте, поэтому можно указать несколько серверов. Реализована возможность организации распределенного тестирования, что повышает реалистичность, или когда с одного компьютера не получается нагрузить мощный сервер. Каждая из машин такой системы может выполнять свою группу заданий, а repository host осуществляет сбор и хранение результатов. После установки на каждой тестирующей системе запускается сервер имен, работа которого обязательна. Поддерживается аутентификация пользователей на веб-ресурсе и установление соединений по протоколу SSL. Параметры работы нагружаемой системы можно контролировать с помощью SNMP и средств Windows NT. Результаты тестирования, включающие время откликов, количество переданных байт в секунду, коды ответа для каждого запроса и количество ошибок выводятся в виде таблиц и графиков. Использование большого числа фильтров позволяет отобрать необходимые результаты. Результат можно экспортировать в CSV-файл. Возможности по выводу отчетов несколько ограничены, но по ссылкам на сайте можно найти скрипты и плагины, упрощающие, в том числе, анализ полученной информации. Рисунок 11.1 - OpenSTA 77 Apache Jmeter, рисунок 11.2 - это единственный инструмент для нагрузочного тестирования, который с одной стороны бесплатный и open source, а с другой стороны достаточно развит и имеет возможность создания тестовой нагрузки одновременно с нескольких компьютеров [12]. Тесты для JMeter создаются визуально и имеют древовидную структуру в окне редактирования теста. Запуск тестов можно производить как из окна приложения, так и из командной строки, что в свою очередь полезно, если вы их запускаете по расписанию, например, ночью. Для чего он лучше всего подходит Инструмент позиционирует себя как универсальный, позволяющий работать как с http запросами, так и FTP, JDBC запросы, SOAP, Web Services, TCP, LDAP, JMS, Mail testers. Но, однозначно, он лучше всего подходит для нагрузочного тестирования веб-приложений. Если пользователь создает многопользовательское веб-приложение, то перед его выпуском у него однозначно возникнут вопросы: стабильно ли работает приложение под большой нагрузкой; какое максимально возможное число пользователей выдержит приложение на определенной конфигурации; насколько быстрее стало работать приложение после улучшения архитектуры кода. На все эти вопросы, с относительно небольшими затратами времени ответит JMeter. Из чего состоит тест При создании теста JMeter предлагает несколько типов компонент: 1) samplers - основные элементы, которые непосредственно общаются с тестируемым приложением, например http sampler для обращения к веб-приложению; 2) logic controllers - элементы, позволяющие группировать другие элементы в циклы, группы параллельного запуска, и т.д.; 3) assertions - элементы, выполняющие контроль. С их помощью вы можете проверить текст, который вы ожидаете на веб-странице или, например, указать, что вы ожидаете ответ от сервера не более чем 2 секунды. Если какой-либо Assert не будет удовлетворен, тест будет иметь негативный результат. Как выглядит отчет Что будет содержаться в отчете, пользователь настраивает сам. Удобно то, что в отчет можно включать таблицы и графики. 78 Рисунок 11.2 - Apache Jmeter Можно ли расширять JMeter Jmeter является удобным инструментом для запуска и мониторинга тестов, а также для просмотра отчетов. Поэтому если пользователю нужны особые виды тестов, которые он может написать на Java, то все что ему нужно, это написать код самого теста. Далее его нужно оформить как Sampler, после чего JMeter поможет ему сделать всю остальную работу по организации, конфигурированию и выполнению тестов (в том числе и с нескольких компьютеров). WAPT (Web Application Testing), рисунок 11.3 - позволяет испытать устойчивость веб- сайта и других приложений, использующих веб-интерфейс, к реальным нагрузкам. Разрабатывается новосибирской компанией SoftLogica LLC. Это одна из самых простых в использовании программ обзора. Для проведения простого теста даже не нужно заглядывать в документацию, интерфейс прост, но не локализован. Для проверки WAPT может создавать множество виртуальных пользователей, каждый с индивидуальными параметрами. Поддерживается несколько видов аутентификации и куки. Сценарий позволяет изменять задержки между запросами и динамически генерировать некоторые испытательные параметры, максимально имитируя таким образом поведение реальных пользователей. В запрос могут быть подставлены различные варианты HTTP-заголовка, в настройках можно указать кодировку страниц. Параметры User-Agent, X-Forwarded-For, IP указываются в настройках сценария. Значения параметров запроса могут быть рассчитаны несколькими способами, в том числе, определены ответом сервера на предыдущий запрос, используя переменные и функции [12]. Поддерживается работа по 79 защищенному протоколу HTTPS (и все типы прокси-серверов). Созданные сценарии, сохраняемые в файле XML-формата, можно использовать повторно. Кроме стандартных Performance и Stress, в списке присутствуют несколько других тестов, позволяющих определить максимальное количество пользователей и тестировать сервер под нагрузкой в течение долгого периода. Рисунок 11.3 - WAPT NeoLoad, рисунок 11.4 - система, позволяющая провести нагрузочное тестирование веб- приложений. Написана на Java. В отчете можно получить подробную информацию по каждому загруженному файлу. NeoLoad весьма удобен для оценки работы отдельных компонентов (AJAX, PHP, ASP, CGI, Flash, апплетов и пр.). Возможна установка времени задержки между запросами (thinktime) глобально и индивидуально для каждой страницы. Тестирование проводится как с использованием весьма удобной графической оболочки, так и с помощью командной строки (используя заранее подготовленный XML-файл). Поддерживает работу с протоколом HTTPS, с HTTP и HTTPS прокси, basic веб-аутентификацию и cookies, автоматически определяя данные во время записи сценария, и затем проигрывает во время теста. Для работы с различными профилями для регистрации пользователей могут быть использованы переменные. При проведении теста можно задействовать дополнительные мониторы (SNMP, WebLogic, WebSphere, RSTAT и Windows, Linux, Solaris), позволяющие контролировать и параметры системы, на которой работает веб-сервер [12]. При помощи NeoLoad можно проводить и распределенные тесты. Один из компьютеров является контролером, на остальные устанавливаются генераторы нагрузки (loadGenerator). Контролер распределяет нагрузку между loadGenerator и собирает статистику. Очень удобно реализована работа с виртуальными пользователями. Пользователи имеют индивидуальные настройки, затем они объединяются в Populations (должна быть создана как минимум одна Populations), в Populations можно задать общее поведение (например, 40% 80 пользователей популяции посещают динамические ресурсы, 20% читают новости). Виртуальные пользователи могут иметь индивидуальный IP-адрес, полосу пропускания и свой сценарий теста. Используя утилиты нагрузочного тестирования, можно получить информацию о работе веб- сервиса, принять необходимые меры по устранению выявленных недостатков и гарантировать требуемую производительность. Рисунок 11.4 - NeoLoad Продукции Microsoft. Корпорация Microsoft предлагает целых два продукта, позволяющих протестировать веб-сервер под нагрузкой. Это Microsoft Application Stress Tool иWeb Capacity Analysis Tool. Первый распространяется как отдельный продукт и имеет графический интерфейс. Второй входит в состав комплекта инструментов Internet Information Services 6.0 Resource Kit Tools, работает из командной строки. MAST более наглядный, в создании теста поможет простой мастер создания тестов, возможна работа с cookies, регулировка нагрузки по разным URL. Сценарий тестирования может быть создан вручную или записан с помощью веб-браузера и при необходимости отредактирован. В WAST уровень нагрузки (stress level) регулируется путем задания количества нитей, осуществляющих запросы к серверу, а число виртуальных пользователей рассчитывается как произведение числа нитей на число сокетов, открытых каждой из нитей. По окончании теста получаем простой отчет в текстовой форме, в котором дана информация по числу обрабатываемых запросов в единицу времени, среднему времени задержки, скорости передачи данных на сервер и с сервера, количеству ошибок и т.д. Отчет можно экспортировать в CSV-файл. Никаких возможностей по статистической обработке не предусмотрено, то есть с его помощью можно только оценить работу при определенных условиях. В качестве примера работы с программами был рассмотрен инструмент для нагрузочного тестирования - Jmeter. 81 11.5 Нагрузочное тестирование с помощью Jmeter Работа с программой Jmeter была рассмотрена на простом примере создания скрипта для 5 пользователей, которые хотят: войти в систему; провести полный финансовый анализ; выйти из системы. На первый взгляд может показаться, что сценарий слишком короткий, однако во-первых, созданный скрипт не должен содержать много действий. Если цель состоит в том, что нужно рассмотреть больше сценариев пользователя, то скрипты можно комбинировать между собой в цепочку для выявления слабых мест в системе. А во-вторых, даже такой короткий скрипт поможет разобраться в программе Jmeter и использовать полученные знания для самостоятельного изучения программы. Одна из главных особенностей программы - автоматическая запись скрипта. Суть ее в том, что когда создается скрипт для сервиса, который тестируется методом черного ящика, тестировщик не знает всех тонкостей и особенностей его работы. Для облегчения работы существует встроенный элемент HTTP Proxy Server. Эмулируя работу прокси сервера, он будет записывать все полученные/отправляемые запросы. 11.5.1 Подготовительные действия Перед использованием прокси нужно понять, куда записывать полученные шаги. Их можно записать прямо в "катушку" (Thread), на "верстак" (Workbanch), либо в элемент "Recording Controller". Лучше использовать последний элемент по двум причинам: во-первых, так лучше отслеживается и формируется структура теста, а во-вторых, это позволит при необходимости отключить (ctrl+t) весь лог разом. Все действия по добавлению и редактированию происходят по нажатию правой кнопки мыши в контекстном меню. Созданные элементы можно просто перетаскивать (drag and drop). Но, для использования элемента "Recording Controller" нужно добавить хотя бы одну катушку. Для этого нужно нажать правой кнопкой на Test Plan > Add > Threads > Thread Group. Созданную катушку можно переименовать для удобства и понимания. Чтобы это сделать, необходимо нажать на созданный элемент, справа будет поле Name, вместо Thread Group можно написать что угодно. Катушка была названа как "dwarf" - имя сервера, где находится сервис, с которым была проведена работа. После добавлении катушки добавляется Recording Controller. Для этого нужно нажать правой кнопкой на созданный Thread Group > Add > Logic Controller > Recording Controller. Созданный элемент был назван как "вход в систему". На рисунке 11.5 изображен результат. 82 Рисунок 11.5 - Thread Group и Recording Controller 11.5.2 Запись скрипта при помощи HTTP Proxy Server Когда подготовительные действия были завершены, то можно добавить на «верстак» прокси- элемент: WorkBench > Add > Non-Test Elements > HTTP Proxy Server. В нем много настроек, но важен пока только порт. Если порт 8080 занят, можно выставить, например, 18000 или любой другой. Так же можно увидеть, что по умолчанию в поле Target Controller стоит «use recording controller». На рисунке 11.6 было явно указано, куда нужно записывать скрипт, т.е. в dwarf > вход в систему. Рисунок 11.6 - Настройка HTTP Proxy Server 83 После того, как порт был выставлен, необходимо перейти в настройки браузера. В данном примере будет использоваться IE9. Сервис — Свойства обозревателя — Подключения — кнопка Настройка сети. Отмечаются галки «Использовать прокси-сервер …», вторую галку необходимо снять. На рисунке 11.7 в поле Адрес указывается localhost, а порт как из Jmetеr'а: 18000. Рисунок 11.7 - Настройка браузера Теперь все готово для записи. Нужно вернуться в Jmeter на прокси и внизу нажать кнопку Start. После нажатия все действия пользователя в браузере начнут записываться в созданный Recording Controller. Необходимо войти в систему. Записывать действия желательно в несколько шагов, т.к. скрипт может оказаться чрезмерно большим и его будет сложно редактировать. Поэтому первое действие было выбрано как авторизация на сервисе. После нажатия Start и прохождения процедуры авторизации на сервере и процедуры авторизации на сайте, необходимо вернуться в Jmeter и нажать на Stop. В записанном Recording Controller есть много дочерних элементов, которые изображены на рисунке 11.8. Это то, что было послано на сервер, а сервер ответил. Необходимо изучить скрипт убрать лишнее. 11.5.3 Отладка скрипта Отладка скрипта представляет собой удаление различных .jpg, .png и ссылок на сторонние ресурсы. Всё это можно вычищать (клавишей delete). В целом, также можно вычистить .js. Главное найти запрос, который передает в своем теле учетные данные вашего пользователя. Для красоты найти запрос, который ведет на страницу, на которой пользователь логинится. 84 Рисунок 11.8 - Сгенерированный скрипт входа в систему Таким образом, вместе они моделируют связку в действиях пользователя «зашел на страницу — залогинился». После того как мусор был убран, а нужные запросы были оставлены, желательно дать им читаемые имена. Чтобы проверить, то ли было удалено, скрипт надо запустить. В данном примере, если запустить скрипт, то он выполнится с ошибками. Дело в том, что для тестирования нужно авторизоваться на сервере. Для этого необходимо добавить в верхушку дерева HTTP Autorization Manager (Thread Group > Add > Config Elements > HTTP Autorization Manager). Он интуитивно понятен. В нем необходимо указать адрес ресурса, на котором происходит нагрузочное тестирование, обязательно с http://, имя пользователя и пароль. Если Менеджер Авторизации нужен для авторизации на сервере, то абсолютно точно при авторизации на сайте используются куки. Необходимо добавить Cookie Manager после Менеджера Авторизации (TestPlan > Add > Config Elements > HTTP Cookie Manager). Этот элемент нужно добавлять всегда, если речь идет о том, что пользователю нужно залогиниться. На рисунке 11.9 изображено добавление. Прежде чем запустить и проверить скрипт добавляется элемент View Results Tree (dwarf > Add > Listener > View Results Tree), в котором можно будет наблюдать выполнение. Этот элемент удобно располагать всегда внизу. Еще нужно в настройках браузера убрать галку «использовать прокси». 85 Рисунок 11.9 - Установка менеджера авторизации и куков Для запуска используется сочетание клавиш ctrl + r. На рисунке 11.10 изображен результат выполнения скрипта. Рисунок 11.10 - Результат выполнения скрипта Для того, чтобы убедиться, что пользователь был успешно авторизован, можно зайти в дерево результатов и посмотреть на ответ. Для этого нужно нажать на вкладку Response Data. В ответе сервера есть информация, которая свидетельствует об успешной авторизации пользователя. В данном примере это имя пользователя, которое было указано при регистрации email, т.к. после авторизации оно высвечивается на странице. На рисунке 11.11 можно увидеть этого пользователя в Response Data. |