LTE КОРРЕКТИРОВКА. Особенности технологий построения 3 систем связи для предоставления 3 банковских онлайн услуг 4 Основные сокращения, используемые в работе
 Скачать 253.1 Kb.
|
4 КРИТЕРИИ ЗАВЕРШЕНИЯ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯКритериями завершения нагрузочного тестирования являются совокупность следующих событий: Все запланированные тесты проведены Получены данные мониторинга по использованию системных ресурсов; Получены данные по производительности тестируемого сервиса; Достигнутая производительность тестируемого сервиса соответствует требованиям по производительности, все ограничения тестирования и исключения должны быть письменно согласованы ВП команды разработки и сопровождением промышленной эксплуатации. 5 ТЕСТОВЫЙ СТЕНДСхема тестового стенда представлена на рисунке 4 ниже.  Рисунок – 4 Схема тестового стенда НТ. В таблице ниже приведён перечень используемых в ходе проведения НТ платформенных и бизнес сервисов, кол-во серверов, на которых развёрнуты сервисы, ОС и СПО. Конфигурация серверов, если не указано иное, одинакова для всех ФП и соответствует: CPU : 4 ядра, RAM :24 Гб, HDD : 150 Гб. Таблица 2 . Конфигурация тестового стенда НТ
6 МОДЕЛИРОВАНИЕ НАГРУЗКИНа основании проведенного анализа текущих бизнес процессов и бизнес требований, предоставленных заказчиком, были определены наиболее часто используемые и ресурсоемкие операции. Работа тестового скрипта (СНТ) эмулирует POST запросы в Сервисе: /server/TransactionRest1 – позитивный /server/TransactionRest2 – позитивный /server/TransactionRest3 – негативный /server/TransactionRest4 - негативный СНТ разрабатываются с использованием ПО HP LoadRunner, предназначенного для создания тестов и проведения тестирования. HP LoadRunner (также HPE LoadRunner) — утилита для автоматизированного нагрузочного тестирования. Первая версия была выпущена компанией «Mercury Interactive» в 1989 г. Программа может выполнять тестирование как различных приложений, так и сайтов разного уровня сложности. При тестировании эмулирует параллельную работу большого количества виртуальных пользователей (в виде процессов или потоков), выполняющих различные скрипты (действия) по различным сценариям. Программа имеет соответствующие наборы инструментов для проведения тестирования. Также в состав HP LoadRunner входит набор инструментов для работы с приложением по различным протоколам (удалённо, через прокси-сервер и др.) HP LoadRunner состоит из следующих компонентных модулей: Virtual User Generator (VuGen) — для разработки нагрузочных скриптов; Load Generator — для генерации нагрузки (генерации виртуальных пользователей); Controller — для создания, настройки и запуска сценариев нагрузки; Agent process — связывает модули Controller и Load Generator; Analysis — для анализа результатов проведённого нагрузочного тестирования. В отличие от GUI-тестов, нагрузочные тесты (VuGen) работают с трафиком между клиентом и сервером (прикладной и транспортный уровни), а для генерации нагрузки можно использовать одну рабочую станцию. Virtual User Generator Модуль Virtual User Generator — служит для разработки скриптов, которые будут задействованы для дальнейшего тестирования. Имеет большой набор инструментов, помогающих написать максимально продуктивные скрипты для тестирования приложения. Часть инструментов позволяет вести автоматическое написание скриптов. Достаточно включить «запись» и все действия, выполняемые пользователем на компьютере, будут записываться в скрипт (своего рода «логирование»). Хотя в дальнейшем такие скрипты желательно вручную доработать, исправить или оптимизировать, повышая тем самым их эффективность и безотказность. Также данный модуль имеет функции для настройки работы с параметрами защиты тестируемого приложения. Допустим, если трафик сайта защищён недоверенным сертификатом, то при входе на такой сайт защита будет выдавать предупреждение о том, что надёжность сайта подозрительна. В результате настроек HP LoadRunner для работы с таким сертификатом в автоматическое написание скриптов не будут попадать лишние данные о защите сайта, что существенно улучшит работу скрипта. Скрипты, созданные данным модулем, имеют гибкую структуру, которую можно настраивать в зависимости от требований к тесту. По умолчанию структура скрипта состоит из трёх «секций»: Vuser_init — в данную секцию записываются начальные действия пользователя, которые приведут к запуску тестируемого приложения; Action — в эту секцию записывается основная часть скрипта, которая и будет производить нагрузку на тестируемый модуль; Vuser_end — в последней секции записываются действия для корректного закрытия модуля и завершения работы пользователя с тестируемым приложением. Такой подход к написанию скриптов обеспечивает очень высокую эффективность работы. Пример: 100 пользователей подключились к приложению и прошли этап Vuser_init, после чего 100 раз выполняют Action-часть скрипта и, завершая выполнение, проходят по одному разу этап Vuser_end. Таким образом, наши виртуальные пользователи не будут тратить время на выполнение лишних 99 раз этапов Vuser_init, Vuser_end. Есть возможность выполнить записанный скрипт и в случае возникновения ошибки можно посмотреть скриншоты или веб-страницы всех шагов скрипта, что в первую очередь позволяет увидеть, как приложение вело себя во время выполнения скрипта и детальней разобраться, в каком месте возникла ошибка. Controller Модуль Controller — основной модуль программы. Выполняет сценарии проведения тестирования по заданным настройкам. В этот модуль включаются скрипты, написанные в Virtual User Generator. Администратор имеет возможность создать сценарий тестирования: настроить количество виртуальных пользователей; объединить их в группы; задать интервалы времени, в которые определённые группы пользователей будут подключаться или отключаться; добавить скрипты, которые будут выполнять различные группы пользователей; настроить время выполнения (продолжительность) сценария. Рассматриваемый модуль имеет информативный интерфейс, то есть после запуска выполнения сценария можно детально следить за его процессом. Администратор имеет возможность следить: За тем, какие группы виртуальных пользователей, на каких этапах находятся. Пример: 15 пользователей ожидают своей очереди, 5 пользователей готовятся к выполнению первой секции скрипта (Vuser_init), 200 пользователей выполняют секцию Action, 100 пользователей успешно выполнили свои сценарии (то есть прошли все секции скрипта, по заданному сценарию), 20 пользователей потерпели неудачу и столкнулись с ошибкой приложения. Также детально посмотреть какая ошибка, у какого пользователя и в какой секции скрипта возникла. За графиками, которые отображают прохождение процесса тестирования. Различные графики можно подключить в любой момент выполнения сценария и они отобразят данные, которые записывались с самого старта сценария. Графики также имеют различные настройки для удобного мониторинга процесса. Примеры таких графиков: количество пользователей за время, ошибок за время, задействование памяти или других ресурсов сервера по времени и пр. По завершении выполнения сценария администратор может перейти в модуль Analysis. Analysis Модуль Analysis — служит для составления детальных отчётов о проделанном тестировании. Отчёты могут быть двух типов: в виде документа (Word-файла *.doc); в виде HTML-страницы (можно просматривать различными браузерами). Перед созданием отчёта администратор настраивает интересующие его показатели, которые попадут в отчёт. Можно включить различные графики, которые записывались во время проведения тестирования, стили отображения этих графиков (линейные, объёмные и пр.). Ошибки, которые возникали в ходе выполнения скриптов пользователями и т. п. В общем, в отчёт можно включить всё, что происходило во время тестирования. После настройки отчёта и нажатия кнопки «Создать отчёт», администратор получает детальную отчётность о проведённом тестировании. |