Home

Robot тести до системи електронних закупівель ProZorro

Репозиторій robot_tests містить тести до системи електронних закупівель ProZorro, що призначені для перевірки правильності роботи центральної бази даних (ЦБД) та майданчиків.

У системі передбачено три ролі користувачів:

• замовник
• постачальник
• спостерігач

Користувачі мають можливість працювати з тендерами за допомогою різних майданчиків. Функціонал і графічний інтерфейс майданчиків відрізняється. Тести дозволяють перевірити будь-яку комбінацію користувачів - як на одному майданчику, так і на різних. Тести перевіряють усі аспекти роботи з системою - від оголошення до визначення переможця.

Встановлення тестів

Для роботи тестів потрібні:

• Python 2.7
• Git
• GCC
• Development-версії Python 2.7, libyaml, libjpeg, zlib
• Для Fedora / CentOS / RHEL потрібен пакет redhat-rpm-config
• Рекомендовано використовувати virtualenv

Щоб встановити їх для Fedora:

sudo dnf install python2-devel git gcc libyaml-devel libjpeg-devel redhat-rpm-config zlib-devel

Для openSUSE і інших RPM-дистрибутивів список пакетів такий самий, але замість dnf використовується інший пакетний менеджер, наприклад, zypper. Також пакет python2-devel може називатись python-devel.

Для Debian і похідних дистрибутивів (Ubuntu, Mint):

sudo apt-get install python-minimal python2.7-dev git gcc libyaml-dev libjpeg-dev libz-dev

Для встановлення тестів:

• 1. Завантажте репозиторій з кодом та перейдіть в новостворений каталог:

git clone git://github.com/openprocurement/robot_tests.git
cd robot_tests

• 2. Перейдіть з гілки master на гілку 2.3.x:

git checkout 2.3.x

• 3. Підготуйте середовище:

python2 bootstrap.py
bin/buildout -N

Система Buildout завантажить компоненти та встановить усе необхідне для запуску тестів.

Також виконання bin/buildout буває потрібним після оновлення пакету з Git, зокрема, коли змінюються версії залежностей.

Якщо ви отримуєте помилку, пов'язану з HTTPS/SSL, встановіть в системі пакет ca-certificates.

Запуск тестів

Для запуску виконайте:

bin/openprocurement_tests

Якщо запустити тести без аргументів, то виконується тестування ЦБД на пісочниці за допомогою доступу до API.

Вибір майданчика і ролі

За допомогою аргументів скрипт openprocurement_tests дає змогу перевизначити користувачів для ролей в тестах. Це дозволяє протестувати не лише ЦБД, але й різні майданчики. Запуск тестів виглядатиме так:

bin/openprocurement_tests -v BROKER:BrokerName -v ROLE:RoleName

Тут BrokerName – ім'я майданчика, що тестується, і RoleName – ім'я ролі, яка тестується на цьому майданчику. Решта ролей при цьому працюють безпосередньо з API ЦБД.

Доступні ролі: tender_owner, provider, provider1, viewer. Якщо вказати лише майданчик, то для нього автоматично буде вибрана роль viewer. Зверніть увагу: імена ролей і майданчиків чутливі до регістру.

Вибір test suite

За замовчуванням виконуються всі наявні test suite. Щоб вибрати test suite, використовуйте опцію -s:

bin/openprocurement_tests -s reporting -s negotiation

В цьому прикладі буде виконано reporting.robot і negotiation.robot.

Вибір версії API і адреси сервера

Якщо для одної з ролей використовується робота з ЦБД напряму, а не через майданчик, то можна вибрати версію API, до якої будуть надсилатись запити, і нестандартну адресу сервера. Приклад:

bin/openprocurement_tests -v API_VERSION:0.12 -v API_HOST_URL:http://localhost:6543/

Структура файлів і каталогів

В кореневому каталозі і каталозі op_robot_tests/ знаходяться службові файли, потрібні для запуску пакету. В каталозі op_robot_tests/tests_files/ знаходяться основні дані – тестові сценарії, бібліотеки ключових слів, опис майданчиків, дані про користувачів тощо. Всі шляхи, наведені нижче, слід шукати в op_robot_tests/tests_files/.

Конфігурація тестів відбувається в YAML файлах.

Користувачі

Для повноцінного тестування майданчик мусить додати чотирьох користувачів:

• одного замовника - tender_owner
• двох постачальників - provider, provider1
• одного глядача (може бути анонімним) - viewer

Усіх користувачів, що можуть бути задіяні в тестах, потрібно описати в файлі data/users.yaml.

Структура users.yaml

У корені файла є словник users, який містить у собі усіх користувачів. Елементами словника users є користувачі, де описано їх дані у вигляді зіставлення, як описано тут: https://uk.wikipedia.org/wiki/YAML#Зіставлення+імені+та+значення

Обов’язковим є поле broker - майданчик, до якого належить користувач.

Також користувач може містити відомості про його переглядач, розмір вікна, лоґін в майданчик та будь-які інші дані необхідні для тесту.

Приклад

users:
    Demo_Owner:
        username: demo0
        password: Password1
        broker: Demo
    Demo_User:
        broker: Demo
        username: demo1
        password: openproc
        browser:  chrome
        size:  [640, 450]
    Demo_User1:
        broker: Demo
        username: demo2
        password: pwd1234
        browser:  firefox
    Demo_Viewer:
        broker: Demo
        browser:  firefox

Майданчики

Опис майданчика здійснюється в файлі data/brokers.yaml.

Структура brokers.yaml

У корені файла міститься список усіх майданчиків, а також словник Default, який містить значення за замовчуванням. В описі майданчика обов’язково містяться поля:

• keywords_file, значенням якого є назва бібліотеки ключових слів (реалізації тестів) майданчика. Ця назва відповідає імені файла без розширення .robot в каталозі brokers/,
• roles — словник, у якому для кожної ролі встановлюється ім'я користувача з файла data/users.yaml.

Необов'язкові поля:

• timeout_on_wait — максимальний час очікування на відповідь від майданчика, період синхронізації з ЦБД.
• period_interval — інтервал між періодами в хвилинах. За допомогою цього числа можливо регулювати, як довго будуть тривати періоди тендера.

Якщо необов'язкове поле присутнє, то воно використовується, інакше береться значення за замовчуванням із словника Default.

Детальніше про бібліотеку тестів майданчика в розділі Перелік ключових слів

Приклад

Default:
    period_interval: 10
    timeout_on_wait: 7
Demo:
    keywords_file: demo_broker
    timeout_on_wait: 4
    roles:
        tender_owner: Demo_Owner
        provider: Demo_Provider
        provider1: Demo_Provider1
        viewer: Demo_Viewer
BoringBroker:
    keywords_file: boring_br
    roles:
        tender_owner: Boring_Boss
        viewer: Boring_Viewer

В цьому прикладі для брокера BoringBroker не задані користувачі для ролей provider і provider1, тому через цей майданчик неможливо буде здійснити дії, для яких потрібні ці користувачі (наприклад, подати цінову пропозицію).