Общая часть

В самом общем виде процесс тестирования можно сформулировать как "подать некоторое воздействие на систему и проверить реакцию". uniset-testsuite предназначен для автоматизации этого процесса. При этом система расчитана на взаимодействие с тестируемой системой по цифровому протоколу.

На данный момент поддерживаются следующие интерфейсы:

uniset
MobusTCP
SNMP

Встроенная система плагинов, позволяет лего расширять список поддерживаемых интерфесов путём добавления своих реализаций.

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

Тестовый сценарий.

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

Сценарий

Сценарий представляет из себя xml-файл с инструкциями. При этом все тесты необходимо распологать между тегами <TestList>..</TestList>. На данный момент поддерживаются сценарии:

uniset
modbus
snmp

Тип сценария записывается в теге <TestList type="xxx">. Отдельно можно указывать тип для конкретной конфигурации. См. Использование нескольких интерфейсов обмена в одном сценарии.

Ниже приведён пример записи uniset-сценария из трёх тестов.

<?xml version="1.0" encoding="utf-8"?>
<TestScenario>
 <Config>
 ...
 </Config>
 <RunList after_run_pause="3000">
 ...
 </RunList>
 <TestList>
  <test name="Stopped" comment="Проверка что без команды 'ничего не делаем'">
   <action set="OnControl_S=0" comment="Снимаем команду 'начать работу'"/>
   <check test="CmdLoad_C=0" comment="команда 'наполнить' не меняется" holdtime="3000"/>
   <check test="CmdUnload_C=0" comment="команда 'опустошить' не меняется" holdtime="3000"/>
   <check test="Level_AS=0" comment="уровень не меняется" holdtime="6000"/>
  </test>
  <test name="Processing" comment="Проверка работы процесса">
   <action set="OnControl_S=1" comment="Подаём команду 'начать работу'"/>
   <check test="CmdLoad_C=1" comment="Подана команда 'наполнение'"/>
   <check test="CmdUnload_C=0" comment="Cнята команда 'опустошение'"/>
   <check test="Level_AS>=90" comment="Цистерна наполняется.." timeout="15000"/>
   <check test="CmdLoad_C=0" comment="Снята команда 'наполнение'"/>
   <check test="CmdUnload_C=1" comment="Подана команда 'опустошение'"/>
   <check test="Level_AS<=10" comment="Цистерна опустошается.." timeout="15000"/>
  </test>
  <test name="Stopped" comment="Проверка остановки процесса">
   <action set="OnControl_S=0" comment="Снимаем команду 'начать работу'"/>
   <check test="CmdLoad_C=0" comment="команда 'наполнить' не меняется" holdtime="3000"/>
   <check test="CmdUnload_C=0" comment="команда 'опустошить' не меняется" holdtime="3000"/>
   <check test="Level_AS<=80" comment="Уровень не меняется" holdtime="10000"/>
  </test>
</TestList>
</TestScenario>

Пример modbus-сценария:

<?xml version = '1.0' encoding = 'utf-8'?>
<TestScenario>
<Config>
  <aliases>
    <item default="1" alias="c1" mbslave="localhost:2048"/>
    <item alias="c2" mbslave="localhost:2049"/>
  </aliases>
</Config>
<RunList after_run_pause="200">
    <item script="./start_mbslave1.sh" args=""  silent_mode="1" chdir="../../Utils/Modbus/" ignore_terminated="0" ignore_run_failed="0" name="MBSlave1"/>
    <item script="./start_mbslave2.sh" args="" chdir="../../Utils/Modbus/" ignore_terminated="0" ignore_run_failed="0" name="MBSlave2"/>
</RunList>
<TestList replace="MyGlobalVar2:104,MyGlobalVar:101" type="modbus">
    <test name="Test simple read" ignore_failed="1">
        <action set="0x10=2" />
        <check test="0x10!=0" />
        <check test="0x1@0x02:0x02!=0" config="c2"/>
    </test>
    <test name="Test simple write" ignore_failed="1">
        <action set="0x25=10" />
        <action set="0x25:0x10=10" />
        <action set="0x25@0x02=10"  config="c2"/>
        <action set="0x25@0x02:0x05=10"  config="c2"/>
    </test>
    <test name="Test other 'check'" ignore_failed="1">
        <check test="0x20=0x20"  timeout="1000" check_pause="100"/>
        <check test="0x20=0x20" />
    </test>
    <test name="Test 'great'" ignore_failed="1">
        <action set="109=10" />
        <check test="109>=5"  />
        <check test="109>=10"  />
    </test>
    <test name="Test 'less'" ignore_failed="1">
        <action set="109=10" />
        <check test="109<=11"  />
        <check test="109<=10"  />
    </test>
    <test name="Test other 'action'" ignore_failed="1">
        <action set="20@2=1,21@0x02:5=1,103@2:0x10=12" config="c2"/>
    </test>
</TestList>
</TestScenario>

При этом в секции TestList для сценария можно задать следующие параметры:

notimestamp="1" - "1" означает не выводить дату и время при прохождении тестов

replace="var1:val1,var2:val2,.." - 'Список замен'. Смотри раздел Шаблоны в тестах

Формат записи поля 'id' в uniset-сценарии

Поддерживаются следующие формы записи идентификатора датчика:

id="100", id="SensorName", id="100@LocalhostNode", id="SensorName@Host2"

Т.е. задаётся пара - "идентификатор@узел", при этом в качестве идентификатора узла можно задавать как числовое значение, так и название (в любом сочетании).

Заметки: Если идентификатор узла не задан, то будет использован LocalNode заданный в соответствующем конфигурационном файле.

Формат записи поля 'id' в modbus-сценарии

Поддерживается следующая форма записи регистра опроса: "mbreg@mbaddr:mbfunc:nbit:vtype", где mbreg - регистр (для опроса или записи)

Остальные параметры являются не обязательными и имеют значения по умолчанию.

mbaddr - адрес устройства на шине. По умолчанию: 0x01

mbfunc - функция опроса или записи. По умолчанию для опроса используется mbfunc=0x04, а для записи mbfunc=0x06

nbit - номер бита [0...15]. Для случая, если опрос ведётся функцией чтения "слова", а при этом данные хранятся в каком-то бите. По умолчанию nbit=-1 - что означает не использовать.

vtype - тип запрашиваемого значения, задаётся строковым значением. По умолчанию "signed".

Все поддерживаемые типы описаны в include/libuniset/extensions/VTypes.h.

    enum VType
    {
        vtUnknown,
        vtF2,       // двойное слово float(4 байта). В виде строки задаётся как "F2".
        vtF4,       // 8-х байтовое слово (double). В виде строки задаётся как "F4".
        vtByte,     // байт.  В виде строки задаётся как "byte".
        vtUnsigned, // беззнаковое целое (2 байта).  В виде строки задаётся как "unsigned".
        vtSigned,   // знаковое целое (2 байта). В виде строки задаётся как "signed".
        vtI2,       // целое (4 байта). В виде строки задаётся как "I2".
        vtU2        // беззнаковое целое (4 байта). В виде строки задаётся как "U2".
    };

Предупреждения: Следует иметь ввиду, что в текущей реализации работа ведётся только с целыми значениями, поэтому все 'float'-значения округляются до целых.

При этом для функций записи регистра используются только поля mbreg, mbaddr, mbfunc. Поля mbaddr, mbfunc так же являются не обязательными.

Тесты

Каждый тест заключается в теги <test>...</test>. Все тесты исполняются последовательно.

Возможные действия деляться на три вида

"action" - 'выставление датчика'
"check" - это проверка реакции тестируемой системы
"compare" - сравнение состояния двух датчиков между собой

"Действия"(actions)

Доступны следующие виды "действий":

1. set - выставление значения
2. msleep - пауза
3. script - запуск внешнего скрипта

1. 'SET'. Выставление значения.

Выставление значения может быть двух видов. Просто выставить и выставить с автоматическим сбросом через заданное время. Ниже показан пример записи обоих форм "set".

<action set="101=0" />
<action set="TestSensor=0" />
<action set="100=0"  reset_time="300" rval="1"/>

Где в set - можно задавать, как число или как имя. reset_time - Время в мсек. через которое датчик примет значение заданное параметром rval.

Заметки: Следует иметь ввиду, что сброс значения происходит параллельно работе теста. Т.е. тест продолжается сразу после выставления значения. Но переход к следующему тесту будет осуществлён, только после "сброса"(reset_time).

Помимо этого разрешается выставление сразу нескольких значений. Датчики и их значения перечисляются через запятую. И записываются в формате "id1=val,id2@host2=val2,...".

Где также id - можно задавать, числом или именем.

2. 'MSLEEP'. Пауза.

Реализация паузы в миллисекундах.

\subsection uts_Actions_SCRIPT 3. 'SCRIPT'. Вызов внешнего скрипта.
Вызов внешнего скрипта. Скрипт должен возвращать \b 0 - в случае \b успеха и "не ноль" - в любом другом случае.
При вызове скрипта никаких проверок не производится, поэтому требуется его аккуратное(вдумчивое) использование,
чтобы исключить возможные зависания. Помимо этого скрипт САМ должен обеспечивать корректное освобождение ресурсов после своей работы
(например уничтожать свои дочерние процессы, если он их порождал во время своей работы, корркетно завершать работу с какими-либо устройствами
и т.п.)

По умолчанию вывод на экран отключён. Если требуется увидеть stdout и stderr, то можно задать параметр \b show_output="1".

При запуске скриптов доступны следующие переменные окружения:

UNISET_TESTSUITE_ROOTDIR - каталог где запущен "главный" тестовый файл
UNISET_TESTSUITE_ROOT_FILENAME - название главного тестового файла
UNISET_TESTSUITE_TESTNAME - название (name) текущего выполняемого теста
UNISET_TESTSUITE_TESTFILE - имя текущего тестового файла
UNISET_TESTSUITE_CURDIR - текущий каталог с выполняемым тестом
UNISET_TESTSUITE_CONFILE - текущий confile (зависит от теста)

Помимо предустановленных переменных имеется возможность задать свои (пользовательские) переменные окружения. Это делается при помощи подсекции <environment> в секции <Config>.

<Config>
    ...
    <environment>
        <item name="MyTEST_VAR1" value="MyTEST_VALUE1"/>
        <item name="MyTEST_VAR2" value="MyTEST_VALUE2"/>
        <item name="MyTEST_VAR3" value="MyTEST_VALUE3"/>
    </environment>
    ...
</Config>  

"Проверки"(checks)

Доступны следующие виды проверок:

1. false (=0)
2. true (!=0)
3. equal (=)
4. great (>,>=)
5. less (<,<=)
6. link
7. outlink
8. "проверка постоянства" (проверка выполнения заданного условия в течение времени)

Заметки

Для всех проверок обрабатывается флаг ignore="1" - пропустить данную проверку.

Для всех видов тестов (кроме link,outlink) разрешено использование полей timeout и check_pause.

timeout - задаёт время ожидания в мсек (не действует если указано поле holdtime!)
check_pause - задаёт паузу между проверками значения.

Если timeout > 0, то провека будет повторяться каждые check_pause миллисекунд, пока не будет успешна, или пока не истечёт время ожидания (timeout).

Если holdtime > 0, то провека будет повторяться каждые check_pause миллисекунд, пока она успешна в течение указанного времени

Предупреждения: В test="..." НЕ РАЗРЕШЕНО использовать ряд ЗАРЕЗЕРВИРОВАННЫХ СИМВОЛОВ: @,>,<,=,!

1. '=0'. Проверка ложности значения.

При этом если указывается идентификатор(или имя) аналогового датчика. То происходит сравнение с нулём (0).

2. '!=0'. Проверка истинности значения.

При этом если указывается идентификатор(или имя) аналогового датчика. То происходит сравнение "не ноль"

3. '='. Проверка условия эквивалетности значения.

4. '> или >='. Проверка условия, что значение больше (или равно) заданному

5. '< или <='. Проверка условия, что значение меньше (или равно) заданному

6. 'LINK'. Ссылка на другой тест в данном файле.

link - это ссылка на тест находящийся в этом же файле. При этом чтобы сослаться на тест, необходимо указать два поля prop=value. Т.е. будет осуществлён поиск теста у которого prop="value" Ниже представлен пример, в котором в тесте 22 идёт ссылка на тест 21, но не по полю 'name', а по полю num="1".

<test num="1" name="Test N21">
    <action set="101 =0" />
    <check test="101=0" />
    <action set="101=1" />
    <check test="101!=0" />
</test>
<test num="2" name="Test N22" ignore_failed="1">
    <action set="101 =0" />
    <check test="link" link="num=1"/>
</test>

7. 'OUTLINK'. Ссылка на другой файл.

outlink - позволяет ссылаться на тест в другом файле. Формат записи аналогичен 'link' только добавляется задание файла.

<test num="2" name="Test N22" ignore_failed="1">
    <check test="outlink" file="exttestfile.xml" link="num=1"/>
    <check test="outlink" file="exttestfile.xml" link="ALL" ignore_runlist="1"/>
</test>

Специальное слово "ALL" означает ссылку на весь файл (все тесты). Т.е сценарий в файле exttestfile.xml будет "проигрываться" полностью (а не конкретный тест).

ignore_runlist - [0,1] игнорировать (или нет) список запускаемых процессов (<RunList>)

8. 'HOLD' Проверка постоянства условия в течение заданного времени

Если в <check> указано поле holdtime="..msec.." то этот тест превращается в проверку постоянства выполнения заданного условия в течение указанного времени. Поддерживаются все предыдущие "условия".

<check test="101>20" holdtime="5000"/>
<check test="101!=21" holdtime="5000"/>
<check test="101>=24" holdtime="5000"/>
<check test="101=30" holdtime="5000"/>
<check test="101<=100" holdtime="1000"/>

Предупреждения: Если указаны поля timeout=".." и holdtime=".." то действует (имеет больший приоритет) holdtime.

"Сравнение"(compare)

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

>,>= - больше, больше либо равно
<,<= - меньше, меньше либо равно
=,!= - равно, не равно

Записываются они точно также как \i check только со специальным словом compare и во второй половине сравнения ставится идентификатор или название датчика.

<comapre test="101>Sensor2"/>
<comapre test="Sensor1!=Sensor2" check_pause="500" timeout="4000"/>
<comapre test="101>=Sensor2"/>
<comapre test="Sensor1=Sensor2" holdtime="5000"/>
<comapre test="Sensor1<=203" holdtime="1000"/>

Заметки: В данном случае "203" - это идентификатор датчика!; compare так же можно применять для сценариев типа modbus. В таком случае сравниваются значения двух регистров.

Параметры тестов

Сами тесты позволяют задавать следующий свойства: ignore_failed="1" - Не останавливаться в случае "провала" теста. По умолчанию тестирование будет прервано. ignore="1" - Пропустить данный тест при проверке.

<test num="1" name="Test N21"  ignore_failed="1">
    <action set="101 =0" />
    <check test="101=0" />
    <action set="101=1" />
    <check test="101!=0" />
</test>
<test num="2" name="Test N22">
    <action set="101 =0" />
    <check test="link" link="num=1"/>
</test>

Шаблоны в тестах

В uniset-testsuite встроен механизм позволяющий делать автоматические замены. Определяется он при помощи свойства replace="var1:val1,var2:val2,..". Заменять можно любое свойство относящееся к стандартным (обрабатываемым плээром), включая настроечные поля (test,id,link,val,name,ignore_failed и т.п.), КРОМЕ свойства replace.

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

Предупреждения

Замены производятся в порядке указанном в списке replace. Следует также учитывать, что цепочка замен формируется динамически по ходу прохождения тестов, поэтому если Вы используете outlink (

'OUTLINK'. Ссылка на другой файл.

), то на этот вызов будут действовать все "замены" действующие на текущий момент.

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

Поле 'replace' - задаёт список пар для замены, через запятую. Сами пары записываются в виде "слово:замена".

Список замены имеет область видимости в зависимости от места в котором он был задан. Имеется три облати видимости:

Глобальная область видимости. Задаётся в секции <TestList>. Пример:
...
<TestList replace="MyGlobalVar:val2,MyGlobalVar2:val2">
...
Область видимости для конкретного теста. Задаётся в теге <test>. Пример:
<test num="1" name="Test replace" ignore_failed="1" replace="MyTestVar1:val1">
...
</test>
Область видимости для тестов 'link' и 'outlink'. Пример:
<test name="Test 1" ignore_failed="1">
<check test="outlink" file="exttestfile.xml" link="num=1" replace="MyVariable1:101,MyVariable2:102"/>
</test>
А вызываемый тест при этом:
<test num="1" name="Test replace" ignore_failed="1">
<action name="MyVariable10" id="MyVariable1" val="0"/>
<check test="MyVariable1=0" />
<action set="MyVariable2=MyVariable3" />
<check test="MyVariable2!=0" />
</test>

Заметки: Следует иметь ввиду. Локальная область видимости "перекрывает" глобальную.

Работа с удалёнными узлами

Собственно работа заложена в способе задания id (cм. "Формат записи поля 'id'"). Т.е. при задании идентификатора узла "id@nodename", будет идти обращение к узлу 'node' в соответствии с секцией <nodes> в конфигурационном файле.

Работа с несколькими конфигурационными файлами одновременно (для uniset-сценариев)

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

В файле сценария в секции <Config><aliases>
<?xml version = '1.0' encoding = 'utf-8'?>
<TestScenario>
<Config>
<aliases>
<item type="uniset" alias="default" confile="configure.xml"/>
<item type="uniset" alias="c1" confile="configure1.xml"/>
<item type="uniset" alias="c2" confile="configure2.xml"/>
</aliases>
</Config>
<TestList>
...
</TestList>
</TestScenario>
В данном случае задаётся три файла, и им присваиваются короткие имена.
Второй способ, в параметрах командной строки, при запуске
uniset-testsuite-xmlplayer --confile configure.xml,c1@configure1.xml,c2@configure2.xml,...

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

Заметки: Следует иметь ввиду, что списки указанные в командной строке и в файле "складываются".; Если название совпадает, приоритетным является командная строка.

Указание используемого конфигурационного файла в тестах

В системе используется четыре области видимости для задания файла.

Глобальная Используется default - файл. См. выше.
Область Файла с тестами
<TestList config="c1">
...
</TestList>
Область конкретного теста Распространяется на <test>. Задаётся параметром 'config'. При этом указывается alias. Пример записи:
<test num="1" name="Test replace" ignore_failed="1" config="c1">
...
</test>
Область 'шага' Распространяется на кокнретный <check> или <action>. Задаётся параметром 'config'. При этом указывается alias. Пример записи:
<test num="1" name="Test replace" ignore_failed="1" config="c1">
<check test="Sensor1@nodename2=0" config="c2">
...
</test>
В данном случае при проверке этого теста, будет использован конфигурационный файл с alias-ом 'c2'.

Все эти параметры являются не обязательными. По умолчанию используется файл указанный при запуске теста.

Указание адресов опрашиваемых ModbusSlave-узлов (в modbus-сценариях)

Для modbus-сценариев также используется секция <Config>..<Config>. Только в ней указываются, ip адреса и порты slave-устройств. Ниже приведён пример записи:

<Config>
  <aliases>
    <item type="modbus" default="1" alias="c1" mbslave="localhost:2048"/>
    <item type="modbus" alias="c2" mbslave="localhost:2049"/>
  </aliases>
</Config>

Адрес записывается в виде mbslave="hostname:port". Один из адресов можно назначить, как адрес по умолчанию, просто дописав в соответствующей строке default="1". Тогда в тестах, где явно не указано config="..alias..", будет использоваться адрес по умолчанию.

Интерфейс работы с устройствами по протоколу SNMP

Для работы с устройствами по протоколу SNMP требуется указать тип сценария <TestScenario type="snmp"> и в секции <Config> прописать настройки указав специальный настроечный файл.

<Config>
      <aliases>
          <item default="1" type="snmp" alias="snmp1" snmp="snmp.xml"/>
          <item type="snmp" alias="snmp2" snmp="snmp2.xml"/>
      </aliases>
</Config>

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

<?xml version="1.0" encoding="utf-8"?>
<TestScenario type="snmp">
    <Config>
        <aliases>
            <item type="snmp" alias="snmp1" snmp="snmp.xml" default="1"/>
            <item type="snmp" alias="snmp2" snmp="/mydir1/snmp2.xml"/>
        </aliases>
    </Config>
    <TestList>
        <test num="1" name="SNMP_tests" comm="Тесты по snmp">
            <check test="uptime@node1>1" comment="Uptime"/>
            <check test="uptimeName@node2>=1" comment="Статус батареи" config="snmp2"/>
        </test>
    </TestList>
</TestScenario>

Настроечный файл имеет следующий формат:

<?xml version='1.0' encoding='utf-8'?>
<SNMP>
  <Nodes defaultProtocolVersion="2c" defaultTimeout='1' defaultRetries='2' defaultPort='161'>
    <item name="node1" ip="192.94.214.205" comment="UPS1" protocolVersion="2" timeout='1' retries='2'/>
    <item name="node2" ip="test.net-snmp.org" comment="UPS2"/>
    <item name="node3" ip="10.16.11.3" comment="UPS3"/>
  </Nodes>
  <MIBdirs>
      <dir path="conf/" mask="*.mib"/>
      <dir path="conf2/" mask="*.mib"/>
  </MIBdirs>
  <Parameters defaultReadCommunity="demopublic" defaultWriteCommunity="demoprovate">
    <item name="uptime" OID="1.3.6.1.2.1.1.3.0" r_community="demopublic"/>
    <item name="uptimeName" ObjectName="sysUpTime.0"/>
    <item name="bstatus" OID="1.3.6.1.2.1.33.1.2.1.0" ObjectName="BatteryStatus"/>
    <item name="btime" OID=".1.3.6.1.2.1.33.1.2.2.0" ObjectName="TimeOnBattery"/>
    <item name="bcharge" OID=".1.3.6.1.2.1.33.1.2.4.0" ObjectName="BatteryCharge"/>
    <item name="sysName" ObjectName="sysName.0" w_community="demoprivate" r_community="demopublic"/>
  </Parameters>
</SNMP>

Секция <Nodes> задаёт список узлов (устройств) с которыми будет происходит обмен. При этом возможно задавать следующие параметры:

name - название узла используемое в дальнейшем в тесте
ip - адрес устройства (ip или hostname)
timeout - таймаут на одну попытку связи, в секундах. Не обязательный параметр. По умолчанию 1 сек.
retries - количество попыток считать параметр. Не обязательный параметр. По умолчанию 2.
port - Порт для связи с устройством. Не обязательный параметр. По умолчанию 161.
comment - коментарий к названию. Не обязательный параметр, на данный момент не используется.

Непосредственно в секции <Nodes> можно задать параметры по умолчанию для всех узлов.

defaultProtocolVersion
defaultTimeout
defaultRetries
defaultPort

В секции <MIBdirs> задаются каталоги с mib-файлами, для проверки корректности OID

path - путь до каталога
mask - маска для файлов. Если не указана, загружаются все файлы из каталога

Секция <Parameters> задаёт список парамеров, которые будут участвовать в тестах:

name - название параметра используемое в дальнейшем в тесте
r_community - установка 'community string' при чтении параметра (см. snmp протокол).
w_community - установка 'community string' для записи параметра (см. snmp протокол).
OID - идентификатор параметра в соответсвии с протоклом SNMP.
ObjectName - название параметра в соответсвии с протоклом SNMP. Не обязательный параметр.
ignoreCheckMIB - не проверять параметр по mib-файлу (в режиме –check-scenario)

Параметры OID и ObjectName являются взаимозаменяемыми. Если заданы оба параметра, используется OID.

Непосредственно в секции <Parameters> можно задать параметры по умолчанию для всех узлов.

defaultReadCommunity
defaultWriteCommunity

Использование нескольких интерфейсов обмена в одном сценарии

Система позволяет в одном сценарии одновременно обращаться и через uniset интерфейс и через ModbusTCP. Для этого достаточно указать тип интерфейса в секции <Config>. Ниже показан пример такого сценария:

<?xml version="1.0" encoding="utf-8"?>
<TestScenario>
<Config>
  <aliases>
    <item type="uniset" alias="u" confile="configure.xml" default="1"/>
    <item type="modbus" alias="mb" mbslave="localhost:2048"/>
    <item type="snmp" alias="snmp" snmp="conf/snmp.xml"/>
  </aliases>
</Config>
<RunList>
...
</RunList>
<TestList>
   <test name="check: Equal test">
     <action set="111=10"/>
     <check test="111=10"/>
     <check test="uptime@node1>1" config="snmp"/>
     <check test="0x10!=0" config="mb"/>
    </test>
</TestList>
</TestScenario>

Как видно из примера в списке указыватся тип конфигурации type, а в самом тесте указывается поле config. как и в случае использования нескольких конфигураций.

Развёртывание системы (запуск фоновых скриптов)

В uniset-testsuite встроен механизм позволяющий запускать необходимые скрипты перед началом тестирования и завершать их после завершения теста. Список задаётся в файле теста в секции <RunList>.

<TestScenario>
<RunList after_run_pause="5000">
   <item script="./start_fg.sh" args="arg1 arg2" chdir="../../Utils/SharedMemory/" ignore_terminated="0" ignore_run_failed="0" name="SharedMemory"/>
</RunList>
<TestList ...>
...
</TestList>

У тега <RunList>

after_run_pause - [мсек], пауза после запуска скриптов. Default: 0.

У <item> можно использовать следующие параметры:

script - собственно запускаемая программа

args - аргументы передаваемые при запуске

chdir - можно задать "каталог" в который нужно перейти перед запуском программы

ignore_terminated - игнорировать "вылет" программы во время тестирования. В другом случае процесс тестирования будет остановлен.

ignore_run_failed - игнорировать неудачный "пуск" программы. В другом случае процесс тестирования будет остановлен.

after_run_pause - [мсек], пауза после запуска скрипта.

silent_mode - [0,1] перенаправить весь вывод в /dev/null

logfile filename - перенаправить весь вывод в указанный файл (отменяет действие silent_mode)

name - можно задать альтернативное имя скрипту (для вывода в логах). Иначе используется название программы.

Следует иметь в виду. Если используется ссылка на другой xml-файл (outlink) и там есть секция <RunList>, она будет исполнена, а по завершении - процессы будут остановлены.

См. также: Описание упрощённого текстового формата

Параметры запуска тестов

можно увидеть запустив

для консольного плеера: uniset-testsuite-xmlplayer [-h | –help]
для графического плеера (uniset-testsuite-gtkplayer): все параметры настраиваются в меню "Параметры".

Запуск скриптов при завершении

В системе имеется возможность запускать указанные программы по завершении тестирования. При этом имеется две возможности. Запуск в случае успешного завершения и запуск в случае "неуспешного" завершения. Для настройки какие программы запускать, предназначены две секции:

<?xml version="1.0" encoding="utf-8"?>
<TestScenario>
  <Success>
      <item script="./success.sh param1 param2"/>
      <item script="./success.sh param3 param4"/>
  </Success>
  <Failure>
      <item script="./failure.sh param1 param2"/>
      <item script="./failure.sh param3 param4"/>
  </Failure>
....
...
</TestScenatio>

Заметки: При этом следует иметь ввиду, что если у Вас имеется много тестов и при этом у них стоит ignore_failure="1", то такой сценарий будет считаться завершённым успешно, даже если все тесты пройдут с результатом [FAILED]

Проверка корректности сценария

В режиме проверки сценария, проверяется корректность сценария, доступность файлов и заданных идентификаторов, но не производится фактических дейтсвий (сохранения или считывания датчиков). Это режим служит только для проверки корректности заданых параметров с учётом "автозамен" (replace). Возможно два режима проверки:

–check-scenario - Проверка сценария, завершающаяся при первой же ошибке
–check-scenario-ignore-failed - Проверка сценария, c игнорированием ошибок...

При этом следует иметь ввиду что вывод результатов [PASSED] или [FAILED] говорит именно о корректности той или иной проверки, а не о результате самой проверки.

Для каждого теста можно задавать список тегов в поле tags="#tag1#tag2#long_name_tag". При этом если задать в аргументах командной строки для "проигрывателя" команду –play-tags "#tag1#tag2#".. то будут исполнены только те тесты в которых встречается один из указанных тегов. Помимо этого –play-tags действует и на команду –check-scenario (см. Проверка корректности сценария). Т.е. проверятся будут только те тесты которые отмечены подходящим тегом.

Для возможности отключить проверку тегов для тестов идущих "далее" сделано специальное поле disable_tags="#tag1#tag2#..". Позволяющее отключить дальнейшую проверку наличия тегов для всех последующих тестов "вглубь". Например, если дерево вызовов по тегу #D1 выглядит как:

Test1 [#D1]
   Test2 [#D1]
      Test3 [#D1]

И при этом Test3 выглядит как

<test name="Test3" tags="#D1" disable_tags="#D1">
   <check test="outlink" file="Test4.xml" link="ALL"/>
</test>  
<test name="Test5">
   <check test="outlink" file="Test6.xml" link="ALL"/>
</test>  
<test name="Test7" tags="#D1">
   <check test="outlink" file="Test8.xml" link="ALL"/>
</test>  

То при вызове Test4.xml и всех последующих вызовах ("в глубину") теги проверятся не будут, и будут исполнятся ВСЕ тесты. Следует иметь ввиду, что при возврате в точку вызова теста Test3, действие disable_tags отключается и вновь включается проверка указанных тегов, т.е. после \z Test3 следующий для исполнения тест будет - Test7, а не Test5 (потому-что он не имеет тега #D1).

Вывод дерева тестов

Для вывода дерева тестов необходимо указать команду –log-show-test-tree. При этом эта команда поддерживает теги (см. Теги), а так же команду –log-show-numline

Дерево вызовов при вылете теста

Если при запуске указать команду –print-calltrace то при вылете процесса, будет выведно дерево вызовов начиная от проваленного теста до самого первого. На случай если дерево вызовов слишком большое, глубину вывода можно регулировать параметром –print-calltrace-limit N Т.е. N - насколько "подняться наверх" от места "падения".

В случае если тестовый сценарий был type='uniset', то помимо вывода дерева вызовов, так же выводится информация о том, какой объект менял датчик (на котором произошёл вылет), когда это было последний раз, а так же информацию по всем заказчикам которые заказали этот датчик. Т.к. выводится очень много информации, то можно отключить её вывод параметром –log-calltrace-disable-extended-info

Контекст теста (для разработчиков интерфейсов)

В функциях UTestInterface можно увидеть параметр 'context'. Это словарь, содержащий различные параметры и значения. От версии к версии контекст может меняться (расширяться). В настоящий момент он содержит следующие параметры:

context['xmlnode'] - xml-узел текущего теста (check или action). (см. также uniset2.UniXML)
context['environment'] - словарь(dict) с текущими переменные окружения + устанавливаемые "проигрывателем тестов" (см. uts_Actions_SCRIPT)
context['supplierID'] - идентификатор под которым сохраняются датчик в SM (параметр специфичный для type="uniset"-интерфейса)