Тестирование облачных приложений с помощью Apache JMeter

Эффективные методики и передовой опыт тестирования RESTful API с помощью JMeter

JMeter – мощный инструмент тестирования приложений, работающих в облаке. Однако управление сценариями JMeter и их обслуживание могут стать проблемой при неэффективном использовании этого инструмента. В статье представлены методики реализации хорошо продуманных автоматизированных заданий JMeter для тестирования облачных приложений.

Шалини Гилра, руководитель группы автоматизации, IBM

Шалини Гилра (Shalini Gilra) – фотографияШалини Гилра (Shalini Gilra) – разработчик автоматизации для платформы SmartCloud в лаборатории IBM India Software Labs, Пуна. Она имеет 12-летний опыт автоматизации функционального тестирования и тестирования REST API с помощью Rational Functional Tester, Selenium, JMeter, JUnit, STAF/STAX и Perl. Среди ее публикаций есть статья на developerWorks Включение внешних функций в IBM Rational Functional Tester (EN). Она имеет сертификаты компании Sun как Java-программист, а также является сертифицированным специалистом по WebSphere Portal Server.



Прем Пракаш, специалист по тестированию ПО, IBM

Прем Пракаш (Prem Prakash) – фотографияПрем Пракаш (Prem Prakash) – специалист по тестированию ПО для платформы SmartCloud в лаборатории IBM India Software Labs, Пуна. Он работает в ИТ-индустрии около 12 лет и специализируется в тестировании на стороне сервера, написании Perl-сценариев и сценариев командной оболочки, а также в тестировании баз данных.



Том Туохи, разработчик автоматизации, IBM

Том Туохи (Tom Tuohy) – фотографияТом Туохи (Tom Tuohy) – разработчик автоматизации для платформы SmartCloud в лаборатории IBM в Литтлтоне, штат Массачусетс. До прихода в IBM он занимался проектированием, разработкой и распространением инфраструктур автоматизации для Lotus Notes/Domino, Lotus Quickplace/Quickr, Lotus Connections и Sterling Commerce. Он более 20 лет специализируется в тестировании на стороне сервера прикладных программных интерфейсов, Web-сервисов и корпоративных приложений, написанных на C, C++ и Java.



14.02.2014

Облачные приложения обычно состоят из нескольких компонентов, взаимодействующих посредством API, передающего данные в XML- или JSON-формате. В статье представлены методики использования Apache JMeter (GUI-приложения с открытым исходным кодом) для функционального тестирования, тестирования производительности и надежности облачных приложений, использующих Web-интерфейсы RESTful и JSON.

Web-интерфейсы RESTful

Web-интерфейс RESTful использует принципы HTTP и REST:

  • API имеет базовый идентификатор в формате URI.
  • Данные, предоставляемые API, обычно представлены в формате JSON.
  • Операции над данными выполняются посредством HTTP-методов GET, PUT, POST и DELETE.

Познакомьтесь с возможностями JMeter, инструмента тестирования Web-интерфейсов RESTful, и его применением для тестирования облачных приложений. Поскольку важнейшим свойством облачной среды является множественная аренда, в данной статье описываются методики программного разделения и извлечения данных, гарантирующие их целостность. В ней демонстрируется написание эффективных тестовых сценариев Jmeter (также известных как планы тестирования или JMX-файлы), облегчающих обслуживание, повторное использование и модульное построение. Узнайте, как использовать файлы настроек и свойств, гарантирующие выполнение одних и тех же сценариев в разных средах.

Авторы предполагают, что вы знакомы с пользовательским интерфейсом JMeter и имеете опыт работы с JMeter.

Определение свойств для оптимального повторного использования сценария

Обычно облачные приложения просты в копировании и развертывании, поэтому их можно тестировать в разных средах. При тестировании и выполнении сценариев автоматизации в нескольких средах полезно использовать отдельный файл JMeter, содержащий данные (включая учетные данные) для подключения к ресурсам, таким как серверы приложений или базы данных.

Переменные и свойства JMeter определяются в трех файлах каталога JMETER_HOME/bin. При запуске JMeter загружает эти файлы в следующей последовательности:

  1. jmeter.properties
  2. Дополнительный файл свойств, определяемых пользователем
  3. system.properties

При добавлении новых или изменении существующих свойств в процессе работы JMeter необходимо перезапустить его, чтобы изменения вступили в силу.

В файле jmeter.properties находятся свойства самого приложения JMeter. Сохраняйте в этом файле только свойства JMeter или конкретной инфраструктуры. Создайте отдельный файл (с произвольным именем) для хранения переменных и свойств конкретной среды тестирования, являющихся глобальными для всех сценариев, относящихся к тестируемому приложению (например, имя/пароль администратора). В файле jmeter.properties раскомментируйте строку с параметром user.properties и укажите в качестве его значения имя созданного файла. В листинге 1 указывается значение myuser.properties.

Листинг 1. Задание файла пользовательских свойств в jmeter.properties
# Должен ли JMeter автоматически загружать дополнительные свойства?
# Имя файла (раскомментировать строку)
user.properties=myuser.properties

В примере файла пользовательских свойств (см. листинг 2) показан формат определения переменных. (В имени свойства слева от знака равенства пробелы не допускаются; значения свойств при необходимости могут содержать пробелы.)

Листинг 2. Пример файла пользовательских свойств
#----------------------------------------------------------------
# Параметры среды тестирования FVT API
#----------------------------------------------------------------
#
# --- Учетные данные
USER_LOGIN=admin@in.ibm.com
USER_PASSWORD=password
#
# --- Сервер приложений
APP_SERVER=localhost
APP_PORT=80
APP_CONTEXT=ctx
PROTOCOL=http
#
# --- Сервер базы данных ${DB_NAME}
DB_HOST=localhost
DB_PORT=50000
DB_NAME=dbname
DB_USER=dbadmin
DB_PASSWORD=dbpassword

Третий файл свойств JMeter (system.properties) зарезервирован для системных свойств, общих для всех сценариев. Например, если все сценарии используют конкретный сервер базы данных, в файле system.propterties указываются соответствующие свойства.

В панели управления User Defined Variables (см. рисунок 1) отображается считывание сценарием JMeter свойств, определенных в файле пользовательских свойств.

Рисунок 1. Считывание сценарием JMeter конфигурационных данных, определенных в файле пользовательских свойств
Считывани сценарием JMeter конфигурационных данных, определенных в файле пользовательских свойств

Каждый элемент столбца Value в панели управления имеет формат:

${__property(ИМЯ_ПЕРЕМЕННОЙ,ИМЯ_ПЕРЕМЕННОЙ)}

Например, переменная USER_LOGIN файла пользовательских свойств считывается в сценарии как функция ${__property(USER_LOGIN, USER_LOGIN)}. Первый элемент USER_LOGIN в круглых скобках – это имя переменной, определенной в файле свойств (и указанной в столбце Name панели управления). Второй элемент – это значение по умолчанию или резервное значение переменной, не определенной в файле свойств.

Не существует незыблемого правила, где определять переменную: в файле свойств или в сценарии JMeter. Однако две приведенные ниже рекомендации помогут достичь согласованности и избежать ненужного дублирования определений переменных в разных сценариях JMeter.

  • При использовании одного и того же значения в нескольких сценариях определяйте данные либо в файле пользовательских свойств, либо в файле system.properties. Это могут быть, например, системные переменные, такие как имена баз данных и серверов, а также переменные времени исполнения, такие как уровни журналирования.
  • Если в нескольких сценариях используется значение, которое может меняться от сценария к сценарию, определяйте его в сценарии или в файле внешних данных (например, в CSV-файле).

Отделение полезной нагрузки с помощью файлов шаблонов JSON

Многие облачные программные интерфейсы в качестве входных данных требуют полезную нагрузку JSON. JSON определяет структурированный набор элементов, которые могут быть вложены в другие элементы. Каждый элемент определяет одну или несколько пар имя/значение. Функциональное тестирование включает в себя неоднократное предоставление данных в указанном формате. Например, при типичном вызове REST API нагрузка JSON, передаваемая в тело REST HTTP-запроса, обычно содержит жестко закодированные данные. Жестко закодированные данные обычно повторяются более чем в одном тесте и распределены по всему сценарию.

Типичная проблема этого подхода состоит в том, что при изменении структуры (или данных) JSON (например, из-за изменения параметров API) необходимо найти тело HTTP-запроса в тесте JMeter и привести структуру (и данные) JSON в соответствии с новыми требованиями. Если эту структуру JSON используют тысячи HTTP-запросов во множестве тестов Jmeter, придется выполнить огромное количество повторяющихся изменений.

Лучшим подходом является создание шаблона структуры JSON и определение строк подстановки, в которые будут записываться данные. Шаблоны JSON не содержат жестко закодированных значений данных, а определяют ссылочные переменные, в которые записываются фактические данные при выполнении сценария. Затем шаблон считывается в переменную сценария JMeter и заменяется в теле HTTP-запроса.

В листинге 3 показан обычный способ определения нагрузки JSON.

Листинг 3. Статическое определение нагрузки JSON в плане тестирования JMeter
{
   "Customer":{
      "CustomerType":"DIRECT",
      "CustomerNumber":"1234567890",
      "Organization":{
         "OrgName":"IBM",
         "Phone":"999-999-9999",
         "AddressSet":[
            {
               "AddressLine1":"Tech Park One",
               "AddressLine2":",
               "AddressType":"MAILING",
               "City":"Pune",
               "Country":"India",
               "State":"Maharashtra",
               "StateCode":"MH",
               "PostalCode":"411006"
            }
         ],
         "Contact":{
            "FamilyName":"Gilra",
            "GivenName":"Shalini",
            "EmailAddress":"shagilra@in.ibm.com",
            "NamePrefix":"Miss",
            "LanguagePreference":"EN_US",
            "WorkPhone":"999-9999"
         }
      }
   }
}

В листинге 4 показан динамический способ определения нагрузки JSON в шаблоне.

Листинг 4. Динамическое определение нагрузки JSON во внешнем файле шаблона JSON
{ 
   "Customer":{ 
      "CustomerType":"${__eval(${STR_CUSTOMERTYPE})}", 
      "CustomerNumber":"${__eval(${STR_CUSTOMERNUMBER})}", 
      "Organization":{ 
         "OrgName":"${__eval(${STR_ORGNAME})}", 
         "Phone":"${__eval(${STR_PHONE})}", 
         "AddressSet":[ 
            { 
               "AddressLine1":"${__eval(${STR_ADDRESSLINE1})}", 
               "AddressLine2":"${__eval(${STR_ADDRESSLINE2})}", 
               "AddressType":"${__eval(${STR_ADDRESSTYPE})}", 
               "City":"${__eval(${STR_CITY})}", 
               "Country":"${__eval(${STR_COUNTRY})}", 
               "State":"${__eval(${STR_STATE})}", 
               "StateCode":"${__eval(${STR_STATECODE})}", 
               "PostalCode":"${__eval(${STR_POSTALCODE})}", 
            } 
         ], 
         "Contact":{ 
            "FamilyName":"${__eval(${STR_FAMILYNAME})}", 
            "GivenName":"${__eval(${STR_GIVENNAME})}", 
            "EmailAddress":"${__eval(${STR_EMAILADDRESS})}", 
            "NamePrefix":"${__eval(${STR_NAMEPREFIX})}", 
            "LanguagePreference":"${__eval(${STR_LANGUAGEPREFERENCE})}", 
            "WorkPhone":"${__eval(${STR_WORKPHONE})}", 
         } 
      } 
   } 
}

Строки JSON в листинге 3 содержат только жестко закодированные данные. Напротив, шаблон в листинге 4 содержит только имена ссылочных переменных, поэтому его может использовать любой план тестирования JMeter. Фактические данные хранятся в виде CSV-файла, который будет рассмотрен в следующем разделе.

Обратите внимание, что JSON в листинге 4 вызывает JMeter-функцию __eval() для каждой переменной подстановки. Это позволяет вычислить переменную во время выполнения сценария JMeter.

На рисунках 2 и 3 показано определение в сценарии тестирования JMeter файла шаблона JSON. На рисунке 2 показана панель управления HTTP Request.

Рисунок 2. Использование в тестах содержимого файла шаблона
Использование в тестах содержимого файла шаблона

В примере на рисунке 2 переменная CUSTOMER_JSON представляет весь JSON-элемент Customer. Эта переменная, заключенная в функцию _eval(), отображается в теле HTTP-запроса под заголовком Send Parameters With the Request на вкладке Parameters. Таким образом, телом запроса на рисунке 2 является ${_eval(${CUSTOMER_JSON})}.

Переменная CUSTOMER_JSON определяется в панели управления User Parameters (см. рисунок 3).

Рисунок 3. Чтение файла шаблона JSON в сценарии JMeter
Чтение файла шаблона JSON в сценарии JMeter

На рисунке 3 переменной CUSTOMER_JSON присваивается FileToString() с путем к файлу шаблона JSON в качестве параметра. Все содержимое файла шаблона JSON считывается в переменную CUSTOMER_JSON. Таким образом содержимое файла шаблона JSON определяется во время исполнения, и все строки подстановки преобразуются в данные, определенные для них. (В следующем разделе описывается связывание переменных подстановки с фактическими данными.)

Поскольку файлы шаблонов JSON являются внешними по отношению к сценариям тестирования JMeter, их можно хранить в отдельном каталоге, например в JMETER_HOME/tests/jsontemplates. Чтобы обратиться к шаблону JSON из плана тестирования JMeter, укажите путь относительно каталога JMETER BIN, например:

../tests/jsontemplates/customer_template.json

Шаблоны также можно хранить вне каталога JMETER_HOME, но в этом случае нужно указать абсолютный путь.


Абстрактное представление данных с помощью элементов CSV Data Set Config

Хотя отделение тестовых данных от планов тестирования JMeter требует дополнительных усилий на начальном этапе, оно позволяет упростить тесты и облегчить их обслуживание. Преимущества становятся очевидными при внесении в тест изменений. Некоторые данные могут по-прежнему использоваться локально в каждом плане тестирования, но большинство тестовых данных выделяется во внешние файлы: либо в файл свойств (как описывалось выше), либо в конфигурационный CSV-файл. В результате получается более простой в обслуживании набор тестов, в большинстве случаев не требующий редактирования планов тестирования JMeter для изменения данных.

JMeter использует CSV-файлы для хранения наборов данных с разделителями. Функциональность CSV Data Set Config инфраструктуры JMeter позволяет динамически читать тестовые данные CSV-файла во время исполнения. Кроме того, использование CSV-формата позволяет хранить строки данных, содержащие несколько объектов/переменных данных или данных для нескольких итераций цикла. Версии JMeter начиная с 2.3.4 также поддерживают CSV-заголовок, задаваемый в первой строке CSV-файла. Имена, указанные в строке заголовка, используются для сохранения значений данных. Обычно данные в каждой следующей строке представляют собой очередную итерацию цикла. В этом смысле сценарий в основном управляется данными, и тестировщик может менять данные в CSV-файле без каких-либо изменений JMX-сценария.

Кроме того, данные могут использоваться несколькими потоками тестирования и храниться в нескольких CSV-файлах. Если тест выполняет вход с помощью набора учетных данных пользователя и создает заказ для этого пользователя, можно создать два CSV-файла: один для учетных данных пользователя, а второй для информации о заказе. Иногда доступ к CSV-файлу может потребоваться нескольким JMX-сценариям. В таком случае необходимо поместить CSV-файл в каталог, к которому эти сценарии имеют доступ.

Данные итераций, содержащиеся в CSV-файле, обычно связаны с именами переменных. Эти имена указываются в заголовке (через разделители), и их число однозначно соответствует числу значений данных. При обработке каждой строки файла JMeter присваивает соответствующее значение связанному с этой позицией имени переменной. В листинге 5 приведен пример содержимого CSV-файла.

Листинг 5. Пример CSV-файла (customer.csv)
"STR_TESTCASE","STR_CUSTOMERTYPE","STR_CUSTOMERNUMBER","STR_ORGNAME","STR_PHONE",
"STR_ADDRESSLINE1","STR_ADDRESSLINE2","STR_ADDRESSTYPE","STR_CITY","STR_COUNTRY",
"STR_STATE","STR_STATECODE","STR_POSTALCODE","STR_FAMILYNAME","STR_GIVENNAME",
"STR_EMAILADDRESS","STR_NAMEPREFIX","STR_LANGUAGEPREFERENCE","STR_WORKPHONE", 

"Testcase1","DIRECT","1234567890","IBM","999-999-9999","Tech Park One",","MAILING",
"Pune","India","Maharashtra","MH","411006","Gilra","Shalini","shagilra@in.ibm.com","Miss",
"EN_US","999-9999", 

"Testcase2","DIRECT","1234567891","IBM","999-999-9999","Tech Park One",","MAILING",
"Pune","India","Maharashtra","MH","411006","Prakash","Prem","premprakash@in.ibm.com",
"Mr","EN_US","999-9999", 

"Testcase3","DIRECT","1234567892","IBM","999-999-9999","550, Kings Street",","MAILING",
"Littleton","United States","MA","MA","1460-1250","Tuohy","Tom","tuohy@us.ibm.com","Mr",
"EN_US","999-9999",

Загружаемый сценарий преобразования

Детали реализации преобразования нагрузки JSON в файл шаблона JSON и преобразования данных в CSV-файл могут быть громоздкими. Необходимо определить ссылочную переменную для каждой пары атрибут-значение и отобразить ее на соответствующее значение данных CSV-файла. Для облегчения этой трудоемкой работы к статье прилагается пример пакетного файла Windows, который выполняет эти операции для определенной нагрузки JSON. В разделе Загрузки приведена ссылка на пакетный сценарий и инструкции по его использованию.

При обработке CSV-файла в листинге 5 на первой итерации JMeter присваивает переменной STR_CITY значение Pune, переменной STR_COUNTRY значение India и т.д. Затем он делает то же самое для двух следующих строк (итераций), но используя значения, содержащиеся в этих строках. При выполнении сценария указанные переменные получают и хранят значения до тех пор, пока они не будут перезаписаны или пока сценарий не закончится. Во избежание непреднамеренной перезаписи переменных внимательно отнеситесь к их именованию. При отладке сценария JMeter важно знать происхождение переменных, поскольку их местонахождение в самом сценарии не указывается. Здесь может быть полезно единообразное именование переменных в CSV-файлах.

На рисунке 4 показано задание CSV-файла в панели управления CSV Data Set Config.

Рисунок 4. Задание и чтение CSV-файла в JMeter
Задание и чтение CSV-файла в JMeter

На рисунке 4 в поле Filename указывается относительный путь к CSV-файлу, который необходимо прочитать. В поле Allow quoted data? указывается true, поскольку значения данных в CSV-файле заключены в кавычки. В поле Recycle on EOF? указывается false, а в поле Stop thread on EOF? указывается true для остановки потока при достижении конца файла (EOF).


Использование конструкций While Controller для организации циклов

Выделение тестовых данных в отдельные файлы CSV Data Set Config значительно упрощает использование набора данных для повторяющегося выполнения последовательности похожих, но самостоятельных операций. JMeter имеет циклические конструкции (например, While Controller), предназначенные для повторяющегося выполнения. Организуя операции тестирования с помощью циклических конструкций, можно выполнять все управляемые данными тесты одного плана тестирования JMeter.

Этот подход полезен при тестировании в облачной среде, поскольку позволяет тестировать доступ к API нескольких ролей или различные наборы данных (позитивные, негативные, граничные значения и т.д.). С помощью цикла можно выполнить все подстановки для одного теста API в одном плане тестирования, что ускорит написание тестов по крайней мере в 20 раз.

Рисунок 5 показывает, как в панели управления While Controller указать JMeter выполнить цикл по данным CSV-файла.

Рисунок 5. Перебор всех данных в CSV-файле
Перебор всех данных в CSV-файле

На рисунке 5 в поле Condition (function or variable) вводится функция jexl(). Эта функция проверяет переменную из CSV-файла на признак конца файла и указывает JMeter выйти из цикла, когда в CSV-файле закончатся строки. Условием может быть любая переменная или функция, которая в конечном счете получает значение false.


Написание сценариев с помощью BeanShell

Используя язык сценариев BeanShell, можно включать в сценарии JMeter Java-код (см. раздел Ресурсы). BeanShell полезен, например, при работе сценария с переменными, полученными с помощью JMeter Regular Expression Extractor. Сценарий BeanShell выполняет переданную в него программу и возвращает результат во время исполнения.

В некоторых облачных приложениях данные ответа (обычно в JSON-формате), возвращаемые командой API, используются (с некоторыми изменениями) в качестве данных запроса другой команды API. Работать с неизвестными динамическими данными сложно, если в сценариях нельзя использовать программирование. BeanShell позволяет управлять нагрузкой JSON или читать значения атрибутов нагрузки JSON во время исполнения, используя класс JSONObject (см. раздел Ресурсы). Чтобы использовать JSONObject в сценарии JMeter, включите java-json.jar в classpath, скопировав этот JAR-файл в папку JMETER_HOME/lib.

Сценарии BeanShell можно создавать и использовать разными способами и для разных целей. С помощью элементов BeanShell PreProcessor или PostProcessor можно включить фрагмент кода в JMeter BeanShell Sampler до или после выполнения сэмплера. С помощью элемента BeanShell Assertion можно проверять выполнение условий, например, имеет ли переменная JMeter ожидаемое значение.

Общий порядок действий по созданию и использованию сценария BeanShell:

  1. Создайте в JMeter элементы BeanShell Listener, BeanShell PreProcessor, BeanShell PostProcessor или BeanShell Sampler.
  2. Получите переменную в сценарии BeanShell с помощью функции vars.get("переменная").
  3. Для выполнения сценария BeanShell используйте язык Java.
  4. Верните обработанную переменную (переменные) обратно в указанную переменную JMeter (это может быть существующая или вновь созданная переменная) в сценарии BeanShell с помощью функции vars.put("переменная").

Пример сценария BeanShell в листинге 6 меняет значения GivenName и WorkPhone, являющиеся вложениями третьего уровня в JSON-коде листинга 3.

Листинг 6. Использование сценария BeanShell для изменения двух JSON-значений
custPayload= vars.get("testResp");
org.json.JSONObject custJSON= new org.json.JSONObject(custPayload);

if (custJSON.has("Customer") & custJSON.get("Customer")!= null) {
   org.json.JSONObject contactJSON = custJSON.getJSONObject("Customer").getJSONObject(
   "Organization").getJSONObject("Contact");
   contactJSON.put("GivenName", "Shalini");
   contactJSON.put("MobilePhone", "9923406159");
}
vars.put("updatedCustPayload", custJSON.toString());

Теперь запрос может использовать переменную ${updatedCustPayload} в команде интерфейса UPDATE.

Сценарий BeanShell позволяет множеством разных способов управлять переменными JMeter или данными JSON при выполнении арифметических операций, извлечении значения переменной или замене значения конкретной переменной. В целом BeanShell полезен при выполнении задач, которые JMeter не поддерживает напрямую.


Создание модулей повторно используемых фрагментов с помощью Module Controller

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

JMeter Module Controller – это механизм подстановки фрагментов планов тестирования в текущий план тестирования во время исполнения. Такой фрагмент может находиться в любой группе потоков или в рабочей области (WorkBench). Любой фрагмент, используемый Module Controller, должен иметь уникальное имя, поскольку оно используется для поиска целевого контроллера при перезагрузке плана тестирования.

На рисунке 6 показан пример размещения в сценарии контроллера Module Controller и вызываемого модуля.

Рисунок 6. Размещение Module Controller и модуля, на который он указывает
Размещение Module Controller и модуля, на который он указывает

В плане тестирования на рисунке 6 Register Customer определяется как отдельный модуль и размещается в разделе WorkBench. Module Controller (Module Controller – Register Customer), расположенный после процедуры Login User и перед процедурой Logout, указывает на модуль Register Customer. При выполнении сценария Module Controller вставляет модуль Register Customer на свою позицию в плане тестирования.

На рисунке 7 показано определение Module Controller в сценарии.

Рисунок 7. Module Controller, указывающий на простой контроллер, определенный в WorkBench
Module Controller, указывающий на простой контроллер, определенный в WorkBench

На рисунке 7 в выпадающем списке поля Module To Run (где перечислены все доступные модули) выбран модуль Register Customer.

Используйте Module Controller, если компонент повторно используется в том же сценарии (JMX-файле). Если фрагмент будет повторно использоваться в другом сценарии, поместите его в отдельный JMX-файл и вызывайте с помощью Include Controller (подробное описание приведено в следующем разделе).


Включение повторно используемых внешних файлов JMeter с помощью Include Controller

Include Controller предоставляет место вставки, где JMX-файл (родительский сценарий) может вызывать другой сценарий JMeter (дочерний сценарий). Разбиение сценария на более мелкие сценарии или модули/процедуры и создание набора тестов, использующих эти процедуры, позволяет реализовать модульность, чтобы улучшить наглядность и повторное использование сценария. Используйте Include Controller, чтобы выделить повторно используемые фрагменты кода или условий (например, Login User и Register User) для лучшего управления и обслуживания сценариев.

Перед использованием Include Controller создайте дочерний JMX-файл, содержащий повторно используемую процедуру (например, Login Admin User). На рисунке 8 показан пример дочернего сценария, который включается в родительский сценарий с помощью Include Controller.

Рисунок 8. Дочерний JMX-файл (LoginUser.jmx)
Дочерний JMX-файл (LoginUser.jmx)

Дочерний сценарий на рисунке 8 определяет план тестирования, содержащий сэмплер с HTTP-запросом для Login User. Переменные HTTP-запроса, содержащие протокол, имя сервера и другие настройки, определяются в родительском сценарии.

На следующем шаге в точку родительского сценария, где должен вызываться дочерний сценарий, добавляется Include Controller, которому указывается путь к дочернему JMX-файлу. На рисунке 9 показан Include Controller, определяемый в родительском сценарии.

Рисунок 9. Добавление Include Controller в родительский JMX-файл
Добавление Include Controller в родительский JMX-файл

В панели управления Include Controller (см. рисунок 9) в поле Filename вводится относительный путь к дочернему JMX-файлу (в нашем случае это Login_User.jmx).

Дочерний JMX-файл может обращаться к любой переменной, определенной в родительском сценарии, доступном для Include Controller, а родительский JMX-файл может использовать переменные, определенные в дочернем JMX-файле.


Использование регулярных выражений

Когда нагрузка для REST-операций запрашивается в JSON-формате, ответ возвращается в JSON-формате или в виде строки. После выполнения операции необходимо извлечь строку ответа, код ошибки или строку сообщения об ошибке, чтобы проверить, работает ли функция ожидаемым образом. Данные ответа извлекаются в переменные с помощью регулярных выражений JMeter.

На рисунке 10 демонстрируется создание в панели управления Regular Expression Extractor простого экстрактора, использующего регулярные выражения.

Рисунок 10. Простой экстрактор, использующий регулярные выражения
Простой экстрактор, использующий регулярные выражения

На рисунке 10 в поле Reference Name вводятся значения (в нашем случае это User), извлеченные с помощью регулярных выражений. В поле Regular Expression вводится регулярное выражение (на рисунке 11 это \"LoginName\":\"(.*?)\"), которое извлекает из ответа конкретные данные. Ниже приведены примеры регулярных выражений, часто используемых для извлечения JSON-данных из ответа:

  • \s*(.+)\s* для извлечения всей строки ответа.
  • \"LoginName\":\"(.*?)\" для извлечения " LoginName": "abc@testmail.com".
  • \"CustomerId\":(\d+) для извлечения "CustomerId": 2000006.

В поле Template на рисунке 10$1$ означает группирование ссылочных переменных. Поле Default Value предназначено для указания значения по умолчанию (в целях отладки) в случае, если регулярное выражение не подходит. Указывайте значение по умолчанию только на стадии создания сценария при добавлении и тестировании шаблонов регулярных выражений.


Распространение функциональных сценариев JMeter на тестирование производительности

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

Предположим, имеется план тестирования, который выполняет и проверяет простой набор операций REST, используя следующий алгоритм

  1. Выполнить HTTP-метод POST для создания объекта customer.
  2. Выполнить HTTP-метод GET для проверки создания объекта customer.
  3. Выполнить HTTP-метод PUT для проверки изменения объекта customer.
  4. Выполнить HTTP-метод DELETE для проверки удаления объекта.

Простой план функционального тестирования, изначально разработанный для сценария функционального тестирования RESTful API, можно преобразовать в сценарий тестирования производительности, нагружающий серверы, развернутые в облачной среде.

  1. Перейдите в панель управления Thread Group плана тестирования (см. рисунок 11).
    Рисунок 11. Пример настройки нагрузки
    Пример настройки нагрузки
  2. Введите ${Thread} в поле Number of Threads (users). Значение переменной Thread, которое будет присвоено на шаге 5, указывает число потоков для отражения количества виртуальных пользователей, обращающихся к серверам.
  3. Введите ${RampUp} в поле Ramp-Up Period (in seconds). Значение переменной RampUp, которое будет присвоено на шаге 5, определяет скорость выдачи запросов в зависимости от числа потоков, указанных на шаге 1. Например, для 10 потоков и времени разгона 100 секунд каждый поток запускается через 10 секунд после запуска предыдущего потока в течение всех 100 секунд.
  4. Введите ${Loop} в поле Loop Count. Значение переменной Loop, которое будет присвоено на шаге 5, определяет число выполнений плана тестирования.
  5. Перейдите в панель управления User Defined Variables и определите глобальные переменные Thread, RampUp и Loop (см. рисунок 12). Для каждой моделируемой нагрузки присваивайте переменным соответствующие значения.
    Рисунок 12. Переменные теста производительности
    Переменные теста производительности

    На рисунке 12 переменная Loop имеет значение 5, RampUp – значение 50, а Loop – значение 2.

На рисунке 13 показаны результаты выполнения JMeter для одного из node-серверов, развернутых в облачном приложении; результаты основаны на значениях, присвоенных переменным на рисунке 12.

Рисунок 13. Результаты теста производительности
Результаты теста производительности

На рисунке 13 показана большая нагрузка, создаваемая одновременными запросами, посылаемыми на сервер для моделирования условий теста производительности.


Распространение функциональных сценариев JMeter на тестирование надежности

Тестирование надежности позволяет гарантировать общую устойчивость системы путем непрерывного выполнения набора сценариев в соответствии с определенными наборами условий. Результат тестирования надежность следует рассматривать в сочетании с результатами стрессового тестирования, функционального тестирования и тестирования сетевых функций.

Аналогично тестированию производительности можно преобразовать план тестирования, который выполняет и проверяет простой набор операций REST, в набор сценариев тестирования надежности для определения стабильности любого продукта (или функции), работающего в экземпляре облака.

Важным аспектом тестирования надежности является определение сбоя при непрерывном многодневном выполнении сценария. Отметьте флажок Forever на панели управления Thread Group (см. рисунок 14), чтобы разрешить выполнение потоков до выявления сбоев теста или принудительного останова сценария.

Рисунок 14. Настройки надежности для сценария JMeter
Настройки надежности для сценария JMeter

После настройки параметров теста надежности выполняйте тест в течение нескольких дней и непрерывно отслеживайте результаты с помощью графика результатов JMeter или предоставляемых JMeter элементов assertion.


Заключение

В статье описываются способы использования JMeter для эффективного тестирования облачных приложений. Данная статья не претендует на исчерпывающее обсуждение, поэтому мы призываем исследовать другие методы повышения эффективности задач автоматизации в JMeter. Отличным местом для продолжения исследований является Wiki-сайт JMeter (см. раздел Ресурсы).


Загрузка

ОписаниеИмяРазмер
Пакетный файл преобразования нагрузки JSONConversion_Script.zip2КБ

Ресурсы

Научиться

  • Оригинал статьи: Test cloud-based applications with Apache JMeter.
  • Apache JMeter: на Web-сайте JMeter размещена документация, материалы для загрузки и примеры.
  • JMeter Wiki: исследуйте Wiki-сайт JMeter.
  • JSON Formatter & Validator: используйте эту программу в онлайновом режиме для проверки нагрузок JSON.
  • JSONObject: документация по классу JSONObject.
  • BeanShell: посетите Web-сайт BeanShell для получения дополнительной информации о написании сценариев с помощью BeanShell.
  • Regular expressions: этот полезный сайт содержит RegEx-ресурсы.
  • В разделе облачных вычислений на developerWorks публикуются полезные обсуждения и сведения о новых технических ресурсах, связанных с облачными технологиями.

Получить продукты и технологии

Обсудить

  • Подключайтесь к сообществу developerWorks. Общайтесь с другими пользователями developerWorks, посещая поддерживаемые разработчиками блоги, форумы, группы и вики-сайты.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Технология Java
ArticleID=962697
ArticleTitle=Тестирование облачных приложений с помощью Apache JMeter
publish-date=02142014