На сегодняшний день существует множество приложений и программных комплексов от разных разработчиков, которые мы используем для решения общих задач. Обмен данными и взаимодействие между приложениями обеспечивают веб-службы. Для тестирования их работы, отладки взаимодействия между собой и клиентскими приложениями также выпущено множество инструментов. Самый популярный из них – SoapUI: он поддерживает SOAP/WSDL, REST, HTTP(S), JDBS, JMS и обладает набором инструментов, которые позволяют сделать тестирование проще и нагляднее. SoapUI выступает как тестовый сервис и тестовый клиент и позволяет тестировать интеграцию подсистем. Подробнее с инструментом можно познакомиться на официальном сайте разработчика.



Если для решения поставленной задачи используется один компьютер и комплекс приложений, поломка ПК или сбой одной из программ выявляется быстро. Но что делать, когда в организации много технических средств и программных продуктов? Физически трудно и очень затратно следить и каждую свободную минуту проверять, всё ли в порядке. Для решения этой задачи приходят на помощь специализированные программные системы, которых в интернете вы найдете очень много: одна из них – Zabbix.

Этот программный комплекс предназначен для отслеживания различных параметров сети и работоспособности технических средств. Если какой-то элемент мониторинга сломается, Zabbix сможет оповестить заинтересованных лиц через e-mail и sms. Подробнее о Zabbix можно прочитать также на официальном сайте разработчика.

Представим ситуацию. В компании используется много технических средств, которые мониторит Zabbix, и различные приложения не собственной разработки, а других IT-компаний. Часть или все эти решения связаны друг с другом и решают одну задачу. Чтобы обеспечить своевременное выявление сбоев в этом множестве элементов и быстро найти место возникновения проблемы, нам необходимо настроить мониторинг веб-служб.
Какие есть варианты?

Первый вариант — используя функционал Zabbix, настроить веб-мониторинг

Этот гайд не о том, как работать с Zabbix, поэтому я шаги буду описывать кратко.

Создаём сценарий.
Настройка – Веб– Создать сценарий.



На вкладке «Сценарий» обязательно заполняем поля «Группа элементов данных» и «Имя» (сценария).



Переходим на вкладку «Шаги», добавляем шаг сценария. Заполняем поля: название шага, URL, код ответа.

В «URL» вписываем адрес нужного веб-сервиса: http://Host:port/Service_name.

В «Код ответа» вписываем «200 OK («хорошо»). Список всех кодов состояния HTTP можно найти здесь



Далее настраиваем триггер на созданный сценарий.



Заполняем обязательные поля: имя триггера и выражение – как показано на рисунке ниже.



Что мы получили в результате? Создали элемент веб-мониторинга – «Test», который опрашивает страницу по указанному в сценарии адресу, и триггер, который сработает, как только веб-служба будет недоступна (т.е. элемент мониторинга «Test» получит код, отличный от «200»).

Этого будет достаточно, если не требуется ничего кроме, как удостовериться, что веб-служба доступна. Но, если нужно отслеживать не только доступность, но и корректность работы, то такой способ не подойдет.

Второй вариант — «подружить» Zabbix и SoapUI

Сразу уточню: Zabbix-сервер развёрнут на машине под управлением Linux.

Исходим из того, что SoapUI уже установлен на машине, где крутится Zabbix-сервер. Для примера возьмём некую Soap веб-службу с единственным методом getScore, который по запросу клиента возвращает некую структуру данных: секции с наименованием полей и секции с данными.



Чтобы понять, что веб-служба работает корректно, необходимо задать критерии:
А) метод возвращает корректный ответ;
Б) метод возвращает корректный состав полей в секции полей;
В) метод возвращает не пустой набор данных (секции данных заполнены);
Г) число полей в секциях полей и данных равны;

Первое, что нужно сделать – создать сам тест, которым планируем проверять корректность работы веб-службы. SoapUI позволяет создавать тестовые сценарии для полноценного тестирования веб-служб.



Как видно на скриншоте выше, проверки по критериям А и Б реализуются штатными средствами SoapUI. Для реализации проверок по критериям Б и Г придётся «пошаманить» с элементом SoapUI «Groovy Scripts».

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context );
step=context.testCase.getTestStepAt(1);
def holder = groovyUtils.getXmlHolder(step.name+"#Response");
holder.declareNamespace("scor","http://xml.spss.com/scoring-v2") ;
holder.declareNamespace("rem","http://xml.spss.com/scoring-v2/remote") ;

def columnNamesNode = holder.getDomNodes("//scor:columnNames/scor:name");
def rowValuesNode = holder.getDomNodes("//scor:rowValues");
def ValuesNode = holder.getDomNodes("//rem:getScoreResponse[1]/scor:scoreResult[1]/scor:rowValues[1]/scor:value");

int countNames = columnNamesNode.size();
int countRowValues = rowValuesNode.size();
int countValues = ValuesNode.size();

assert   countRowValues>0 : log.error("The Node with name \"rowValues\" is not found in the Response");
assert   countNames==countValues : log.error ("The count of elements of the node \"columnNames\" doesn't coincide with count of  elements  of the node \"rowValues\"!");

Итак, тестовый сценарий для проверки корректности работы веб-службы готов. Осталось заставить Zabbix и SoapUI работать в связке.

Тесты SoapUI можно запускать из консоли. Почему бы не использовать эту возможность?

Ниже приведен листинг скрипта для мониторинга различных сервисов.

#!/bin/bash
## путь к SoapUI
pathSoapUIDirectory=/usr/local/soapUI/bin/

## путь к папке Zabbix
pathZabbixDirectory=/etc/zabbix

## путь, где хранятся проекты SoapUI для тестирования веб-служб  
pathSoapUiProjectWithName=$pathZabbixDirectory/WebTest/"$2.xml"

## путь к папке, где будут лежать отчеты тестирования веб-служб
pathParentReportDir=/var/www/zabbix/SoapReport

## путь к папке, где будут лежать отчеты тестирования веб-служб c разбиением по наименованию служб
pathReportsDirectory=$pathParentReportDir/"$2"

## Путь к папке хранения отчетов с разбиением по хостам. Чтобы не перепутать, где лежат отчеты в случае, если одна и та же служба развернута на нескольких хостах
pathReportsDirectoryForHost=$pathReportsDirectory/"$1"

## чтобы не создавать каждый раз необходимую структуру папок при включении в мониторинг новой веб-службы, создаем структуру папок и выдаем им необходимые права доступа.
if [ -d "$pathParentReportDir" ];
  then
       chmod 666 "$pathParentReportDir"
  else
        mkdir "$pathParentReportDir"
        chmod 666 "$pathParentReportDir"
fi
if [ -d "$pathReportsDirectory" ];
  then
       chmod 666 "$pathReportsDirectory"
  else
        mkdir "$pathReportsDirectory"
        chmod 666 "$pathReportsDirectory"
fi
if [ -d "$pathReportsDirectoryForHost" ];
  then
       chmod 666 "$pathReportsDirectoryForHost"
  else
        mkdir "$pathReportsDirectoryForHost"
        chmod 666 "$pathReportsDirectoryForHost"
fi

## путь к файлу, в который SoapUI записывает все сценарии, которые не прошли проверки. Он пригодится чуть позднее
searchfile=$pathReportsDirectoryForHost/"alltests-fails.html"

## host:port/service_name
endPoint="$3"

## Путь к папке, где лежит источник тестовых данных (файл Excel), если необходимо
pathTestdataDirectory=$pathZabbixDirectory/WebTest/TestData/"$6"

## имя листа в файле-источнике Excel
workSpaceName="$7"

## наименование тестового набора в проекте
testSuiteName="$4"

## наименование тестового сценария в проекте
testCaseName="$5"

## В зависимости от того, какие параметры были указаны при вызове скрипта, формируем команду запуска тестов SoapUI
commandString="sh $pathSoapUIDirectory/testrunner.sh -e $endPoint -s $testSuiteName"
if [ -n "$testCaseName" ]
  then
        commandString=${commandString}" -c $testCaseName"
fi
commandString=${commandString}" -r -j -f $pathReportsDirectoryForHost"
if [ -n "$pathTestdataDirectory" ]
  then
        commandString=${commandString}" -P pathTestData=$pathTestdataDirectory -P varSpace=$workSpaceName"
fi
commandString=${commandString}" -I $pathSoapUiProjectWithName"
$commandString > $pathReportsDirectoryForHost/"$2RunLogs.txt"



###For Debug###
#errorString="### ErrorCode: 1 - error of start of the project, 2 - Error of assertions of the tests, 0 - All ok. The returned code:"
#echo "$errorString "$? >> /tmp/"$2RunLogs.txt"

if [ $? -ne 0 ];
        then
        echo "ErrorOfRunProject"
else
    if [ ! -f "$searchfile" ]
    then
        echo "FileNotFound"
    else
                if grep -w "Failure" "$searchfile" > /dev/null; then
                        echo "TestFailure"
                else
                        echo "OK"
                fi
    fi
fi

Этот скрипт необходимо поместить в папку /externalscripts, чтобы «Zabbix» его увидел, т.к., по умолчанию, внешние скрипты должны лежать именно в этой папке. В нашем случае скрипт «RunTestService.sh» должен лежать в «/etc/zabbix/externalscripts». Необходимо выдать скрипту права доступа на запуск:

sudo chmod 755 /etc/zabbix/externalscripts/RunTestService.sh

Осталось настроить сам Zabbix на работу с этим скриптом. Для этого нужно создать элемент данных с типом «Внешняя проверка».



Так как скрипт возвращает текстовые значения, то в «Типе информации» необходимо указать – «Текст».
«Ключ» выглядит так:

RunTestService.sh["{HOSTNAME}","ScoringProcessTests","{$SCORING.ENDPOINT}","getScoreTestSuite","getScoreTestCase"]

где:
«RunTestService.sh» — наш скрипт;
«{HOSTNAME}» — имя хоста, на котором развернут сервис для разделения отчётов одних служб на разных хостах;
«ScoringProcessTests» — наименование проекта SoapUI для тестирования веб-службы;
«{$ENDPOINT}» — URL веб-службы;
«getScoreTestSuite» — наименование тестового набора сценариев в проекте SoapUI;
«getScoreTestCase» — наименование тестового сценария в проекте SoapUI;

Чтобы Zabbix информировал об обнаруженном сбое веб-службы, нужно настроить триггер.



Триггер будет срабатывать, если элемент данных получит значение, отличное от «OK», а «Zabbix» отобразит в своем интерфейсе факт обнаружения сбоя и оповестит заинтересованных лиц по почте, sms или другим способом. Способ оповещения зависит от потребностей пользователей.

Таким образом, Zabbix и SoapUI каждый по отдельности бесплатно предоставляют огромный набор функций. По отдельности эти продукты не могут решить задачи, которые им по силе в тандеме. Как еще реализовать эту связку, каждый может придумать сам.