-
Notifications
You must be signed in to change notification settings - Fork 81
Загальна інструкція по Robot тестах до систем ProZorro та ProZorro.Sale
Репозиторій robot_tests містить тести до системи електронних закупівель ProZorro та системи електронних аукціонів ProZorro.Sale, що призначені для перевірки правильності роботи центральної бази даних (ЦБД) та майданчиків.
У системі ProZorro передбачено три ролі користувачів:
- замовник
- постачальник
- спостерігач
У системі ProZorro.Sale - також:
- організатор аукціону
- учасник
- спостерігач
Користувачі мають можливість працювати з тендерами (або лотами) за допомогою різних майданчиків. Функціонал і графічний інтерфейс майданчиків відрізняється. Тести дозволяють перевірити будь-яку комбінацію користувачів - як на одному майданчику, так і на різних. Тести перевіряють усі аспекти роботи з системами - від оголошення до визначення переможця.
Для роботи тестів потрібні:
- 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/openprocurement/robot_tests.git
cd robot_tests
- Для роботи з ProZorro перейдіть на гілку
master
:
git checkout master
- Для роботи з ProZorro.Sale CDB1 перейдіть з гілки
master
на гілкуeauction-awarding-2.1
:
git checkout eauction-awarding-2.1
- Для роботи з ProZorro.Sale CDB2 перейдіть з гілки
master
на гілкуeauction_cdb2
:
git checkout eauction_cdb2
- Підготуйте середовище:
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, використовуйте опцію -s
:
bin/op_tests -s reporting -s negotiation
В цьому прикладі буде виконано reporting.robot
і negotiation.robot
.
Якщо для одної з ролей використовується робота з ЦБД напряму, а не через майданчик, то можна вибрати версію API, до якої будуть надсилатись запити, і нестандартну адресу сервера. Приклад:
bin/op_tests -v API_VERSION:0.12 -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 файлах.
Для повноцінного тестування майданчик мусить додати наступних користувачів:
- для ProZorro
- одного замовника -
tender_owner
- двох постачальників -
provider
,provider1
- одного глядача (може бути анонімним) -
viewer
- одного замовника -
- для ProZorro.Sale
- одного організатора продажу -
tender_owner
- двох учасників -
provider
,provider1
- одного глядача (може бути анонімним) -
viewer
- одного організатора продажу -
Усіх користувачів, що можуть бути задіяні в тестах, потрібно описати в файлі data/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.
У корені файла міститься список усіх майданчиків, а також словник Default
, який містить значення за замовчуванням.
В описі майданчика обов’язково містяться поля:
-
keywords_file
, значенням якого є назва бібліотеки ключових слів (реалізації тестів) майданчика. Ця назва відповідає імені файла без розширення.robot
в каталозіbrokers/
. Детальний список ключових слів, які потрібно реалізувати майданчикам, можна знайти тут Перелік ключових слів (ProZorro) і тут Перелік ключових слів (ProZorro.Sale). -
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
, тому через цей майданчик неможливо буде здійснити дії, для яких потрібні ці користувачі (наприклад, подати цінову пропозицію).