Краткое описание принципов работы uniset-testsuite

1.2

• Общая часть
• Тестовый сценарий.
• Сценарий
• Формат записи поля 'id' в uniset-сценарии
• Формат записи поля 'id' в modbus-сценарии
• Тесты
• "Действия"(actions)
  • 1. 'SET'. Выставление значения.
  • 2. 'MULTISET'. Выставление сразу нескольких значений.
  • 3. 'MSLEEP'. Пауза.

• "Проверки"(checks)
  • 1. 'FALSE'. Проверка ложности значения.
  • 2. 'TRUE'. Проверка истинности значения.
  • 3. 'EQUAL'. Проверка условия эквивалетности значения.
  • 4. 'GREAT'. Проверка условия, что значение больше (или равно) заданному
  • 5. 'LESS'. Проверка условия, что значение меньше (или равно) заданному
  • 6. 'MULTICHECK'. Проверка сразу нескольких условий.
  • 7. 'LINK'. Ссылка на другой тест в данном файле.
  • 8. 'OUTLINK'. Ссылка на другой файл.
• Параметры тестов
• Шаблоны в тестах
• Работа с удалёнными узлами
• Работа с несколькими конфигурационными файлами одновременно (для uniset-сценариев)
• Указание используемого конфигурационного файла в тестах
• Указание адресов опрашиваемых ModbusSlave-узлов (в modbus-сценариях)
• Использование нескольких интерфейсов обмена в одном сценарии
• Развёртывание системы (запуск фоновых скриптов)
• Параметры запуска тестов
• Редактор

Общая часть

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

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

• uniset
• MobusTCP

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

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

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

Сценарий

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

• uniset
• modbus

Тип сценария записывается в теге <TestList type="..."> ("modbus" или "uniset"). Эти два вида различаются только способом задания параметров.

Отдельно можно указывать тип для конкретной конфигурации. См. Использование нескольких интерфейсов обмена в одном сценарии.

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

<?xml version = '1.0' encoding = 'utf-8'?>
<TestScenario>
<Config>
...
</Config>
<TestList type="uniset" logfile="result.test2.txt" logfile_trunc="1">
    <test num="2" name="DG1 Running">
        <check test="equal" id="SES1_CtlMode_AS" val="2" comm="SES1: mode=PultControl"/>
        <action name="set" id="DG1_Start_S" val="1" reset_time="300" val2="0" comm="start DG1"/>
        <check test="event" id="SEES1_State_AS" val="9" comm="SES1: state=Running" timeout="15000" check_pause="200"/>
        <check test="true" id="DG1_LampON_C"/>
        <action name="msleep" msec="2000" />
        <check test="false" id="DG1_Start_C"/>
        <check test="false" id="DG1_Stop_C"/>
    </test>
    <test num="3" name="QG1 ON">
        <check test="equal" id="SEES1_State_AS" val="9" comm="SES1: state=Running"/>
        <action name="set" id="QG1_On_S" val="1" reset_time="300" val2="0" comm="QG1 on command"/>
        <check test="event" id="QG1_State_AS" val="1" timeout="8000" check_pause="500" comm="QG1: state=ON"/>
        <check test="equal" id="SEES1_State_AS" val="1" comm="SES1: state=ON"/>
        <check test="true" id="QG1_LampON_C" comm="QG1: lamp ON"/>
        <action name="msleep" msec="2000" />
        <check test="false" id="QG1_On_C" comm="QG1: on command OFF"/>
        <check test="false" id="QG1_Off_C" comm="QG1: off command OFF"/>
        <check test="true" id="SEES1_NotAloneWorking_C"/>
    </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 logfile="result.txt" logfile_trunc="1" replace="MyGlobalVar2:104,MyGlobalVar:101" type="modbus">
    <test name="Test simple read" ignore_failed="1">
        <action name="set" id="0x10=2"/>
        <check test="true" id="0x10"/>
        <check test="true" id="0x1@0x02:0x02" config="c2"/>
    </test>
    <test name="Test simple write" ignore_failed="1">
        <action name="set" id="0x25" val="10"/>
        <action name="set" id="0x25:0x10" val="10"/>
        <action name="set" id="0x25@0x02" val="10" config="c2"/>
        <action name="set" id="0x25@0x02:0x05" val="10" config="c2"/>
    </test>
    <test name="Test other 'check'" ignore_failed="1">
        <check test="event" id="0x20" val="0x20" timeout="1000" check_pause="100"/>
        <check test="equal" id="0x20" val="0x20"/>
        <check test="multicheck" id="0x25=0x25,0x20:04=0x20,0x19:03=0x19" />
    </test>
    <test name="Test 'great'" ignore_failed="1">
        <action name="set" id="109" val="10"/>
        <check test="great" id="109" val="5" />
        <check test="great" id="109" val="10" />
    </test>
    <test name="Test 'less'" ignore_failed="1">
        <action name="set" id="109" val="10"/>
        <check test="less" id="109" val="11" />
        <check test="less" id="109" val="10" />
    </test>
    <test name="Test other 'action'" ignore_failed="1">
        <action name="multiset" set="20@2=1,21@0x02:5=1,103@2:0x10=12" config="c2"/>
    </test>
</TestList>
</TestScenario>

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

logfile="filname" - задаёт имя файла куда будет писатся лог прохождения теста

logfile_trunc="1" - "1" означает каждый раз писать файл сначала (очищать перед записью)

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

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

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

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

id="100", id="SensorName", id="100 ", \a id="SensorName"

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

Заметки:

Если идентификатор узла не задан, то будет использован 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,     // байт.  В виде строки задаётся как \b "byte".
            vtUnsigned, // беззнаковое целое (2 байта).  В виде строки задаётся как "unsigned".
            vtSigned,   // знаковое целое (2 байта). В виде строки задаётся как "signed".
            vtI2,       // целое (4 байта). В виде строки задаётся как "I2".
            vtU2        // беззнаковое целое (4 байта). В виде строки задаётся как "U2".
        };

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

Тесты

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

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

• "action" - это действия по имитации действий
• "check" - это проверка реакции тестируемой системы

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

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

• 1. set - выставление значения
• 2. multiset - выставление нескольких значений
• 3. msleep - пауза

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

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

   <action name="set" id="101" val="0"/>
   <action name="set" id="TestSensor" val="0"/>
   <action name="set" id="100" val="0" reset_time="300" val2="1"/>

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

Заметки:

Следует иметь ввиду, что сброс значения происходит параллельно работе теста. Т.е. тест продолжается сразу после выставления значения.

2. 'MULTISET'. Выставление сразу нескольких значений.

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

   <action name="multiset" set="101=1,102=3,123=4"/>
   <action name="multiset" set="TestSensor=1,TestSensor2@Node4=23,340=5"/>

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

3. 'MSLEEP'. Пауза.

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

   <action name="msleep" msec="1000"/>

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

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

• 1. false
• 2. true
• 3. equal
• 4. great
• 5. less
• 6. multicheck
• 7. link
• 8. outlink

Заметки:

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

• timeout - задаёт время ожидания в мсек.
• check_pause - задаёт паузу между проверками значения.

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

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

   <check test="false" id="101"/>
   <check test="false" id="CheckSensorName"/>

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

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

   <check test="true" id="101"/>
   <check test="true" id="CheckSensorName"/>

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

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

   <check test="equal" id="101" val="1"/>
   <check test="equal" id="CheckSensorName" val="10"/>

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

   <check test="great" id="101" val="1"/>
   <check test="great" id="CheckSensorName" val="10"/>

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

   <check test="less" id="101" val="1"/>
   <check test="less" id="CheckSensorName" val="10"/>

6. 'MULTICHECK'. Проверка сразу нескольких условий.

   <check test="multicheck" id="101=1,CheckSensorName=10,CheckSensorName2=23,102=0"/>

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

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

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

8. '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_run_list="1"/>
    </test>

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

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

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

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

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

logfile="filname" - задаёт имя файла куда будет писатся лог прохождения теста

logfile_trunc="1" - "1" означает каждый раз писать файл сначала (очищать перед записью)

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

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

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

Заметки:

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

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

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

1. Глобальная область видимости. Задаётся в секции <TestList>. Пример:

...
<TestList logfile="result.test2.txt" logfile_trunc="1" global_replace="MyGlobalVar:val2,MyGlobalVar2:val2">
...

2. Область видимости для конкретного теста. Задаётся в теге <test>. Пример:

    <test num="1" name="Test replace"  ignore_failed="1" replace="MyTestVar1:val1">
     ...
    </test>

3. Область видимости для тестов '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="false" id="MyVariable1" />
        <action name="set" id="MyVariable2" val="MyVariable3"/>
        <check test="true" id="MyVariable2" />
    </test>

Заметки:

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

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

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

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

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

1. В файле сценария в секции <Config><aliases>

<?xml version = '1.0' encoding = 'utf-8'?>
<TestScenario>
<Config>
<aliases>
    <item alias="default" confile="configure.xml"/>
    <item alias="c1" confile="configure1.xml"/>
    <item alias="c2" confile="configure2.xml"/>
  </aliases>
</Config>
<TestList>
...
</TestList>
</TestScenario>

В данном случае задаётся три файла, и им присваиваются короткие имена.

2. Второй способ, в параметрах командной строки При запуске uniset-testsuite-xmlplayer --confile configure.xml,c1@configure1.xml,c2@configure2.xml,...

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

Заметки:

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

Если название совпадает, приоритетным является командная строка.

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

В системе используется четыре области видимости для задания файла. 1. Глобальная Используется default - файл. См. выше. 2. Область Файла с тестами

    <TestList config="c1">
     ...
     </TestList>

3. Область конкретного теста Распространяется на <test>. Задаётся параметром 'config'. При этом указывается alias. Пример записи:

    <test num="1" name="Test replace"  ignore_failed="1" config="c1">
     ...
     </test>

4. Область 'шага' Распространяется на кокнретный <check> или <action>. Задаётся параметром 'config'. При этом указывается alias. Пример записи:

    <test num="1" name="Test replace"  ignore_failed="1" config="c1">
     <check test="false" id="Sensor1@nodename2" config="c2">
     ...
     </test>

В данном случае при проверке этого теста, будет использован конфигурационный файл с alias-ом 'c2'.

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

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

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

<Config>
  <aliases>
    <item default="1" alias="c1" mbslave="localhost:2048" config="reglist.xml"/>
    <item alias="c2" mbslave="localhost:2049"/>
  </aliases>
</Config>

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

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

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

<?xml version="1.0" encoding="utf-8"?>
<TestScenario>
    <RunList after_run_pause="5000">
        <item after_run_pause="0" chdir="../../Utils/SharedMemory/" ignore_run_failed="1" ignore_terminated="1" name="SharedMemory" script="./start_fg.sh" silent_mode="1"/>
    </RunList>
    <Config>
        <aliases>
            <item alias="c1" confile="configure.xml"/>
            <item alias="c2" mbslave="localhost:2049" type="modbus"/>
        </aliases>
    </Config>
    <TestList logfile="result.multitest.txt" logfile_trunc="1">
        <test ignore_failed="1" name="Test N21" num="1">
            <action id="Test_DI " name="set" val="1" config="c1"/>
            <check id="Test_DI" test="equal" val="1" config="c1"/>
            <check test="true" id="0x10" config="c2"/>
        </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

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

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

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

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

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

Редактор

Самое простое это напрямую редактировать xml-файлы сценариев в любом удобном текстовом редакторе. Их формат достаточно простой и методом "копирования" можно писать довольно быстро.

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

Редактирование параметров осуществляется двойным кликом на элементе ("тесте" или "проверке"). Остальные меню доступны по правому клику мыши.

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

Заметки:

Данный редактор позволяет редактировать не все детали сценариев. Поэтому в некоторых случаях, редактирование параметров реализуется непосредственно правкой в xml-файле.