Skip to content

Загальна інструкція по Robot тестах до системи ProZorro

alexdiatlov edited this page Feb 16, 2021 · 1 revision

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

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

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

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

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


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

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

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

sudo dnf install python2-devel git gcc libffi-devel libjpeg-devel libyaml-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 libffi-dev libjpeg-dev libyaml-dev libz-dev

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

  • Завантажте репозиторій з кодом та перейдіть в новостворений каталог:
git clone git://github.com/ProzorroUKR/robot_tests.git
cd robot_tests
  • Для роботи з ProZorro перейдіть на гілку master:
git checkout master
  • Підготуйте середовище:
python2 bootstrap.py
bin/buildout -N

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

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

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

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


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

bin/op_tests

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

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

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

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

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

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

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

bin/op_tests -s reporting -s negotiation

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

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

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

bin/op_tests -v API_VERSION:2.5 -v API_HOST_URL:http://localhost:6543/

Перевизначення у командному рядку параметрів представлених у файлах brokers.yaml та users.yaml

Приклад:

-v BROKERS_PARAMS:'{"Quinta": {"intervals": {"default": {"enquiry": [0, 0], "tender": [0, 1.2], "accelerator": 1440000}},"timeout_on_wait": 0.15}}'
-v USERS_PARAMS:'{"users": {"Tender_Owner": {"api_key": "aaabbbccc000"}}}'

Детальніше про зміст даних визначених у файлай brokers.yaml і users.yaml представлено нижче (структура brokers.yaml, структура users.yaml).

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


В кореневому каталозі і каталозі 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/. Детальний список ключових слів, які потрібно реалізувати майданчикам, можна знайти тут Перелік ключових слів (ProZorro).
  • 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, тому через цей майданчик неможливо буде здійснити дії, для яких потрібні ці користувачі (наприклад, подати цінову пропозицію).