Поширені запитання по проходженню тестування ProZorro

Розгортання середовища та перший запуск

• Чи є в нас еталонний тестовий майданчик для ручного тестування? Щоб можна було порівнювати отримані дані з еталоном?

Такого нема

• VersionConflict: (zc.buildout 2.9.3 (/var/lib/jenkins/workspace/robot_test_first_setup/eggs/zc.buildout-2.9.3-py2.7.egg), Requirement.parse('zc.buildout==2.5.3'))

При налаштуванні середовища виконайте python2 bootstrap.py --buildout-version==2.5.3

• При запуску тестів на Linux видає помилку http://joxi.ru/brRGzwMIx1yPm1 . Що з цим робити?

Створіть директорію для проекту перейдіть у неї і спробуйте послідовно виконати наступні команди:

• git clone https://github.com/openprocurement/robot_tests.git
• cd robot_tests
• python bootstrap.py
• bin/buildout -N versions:chromedriver=2.24 buildout:find-links+=http://testing.openprocurement.org/userContent/chromedriver-2.24.zip

• В мене при запуску тестів ось видає командна строчка http://prntscr.com/eezdys . Що з цим робити?

Щоб обійти проблему:

1. Візміть чистий virtualenv і встановіть туди setuptools старішої версії, наприклад, так: створіть окремий virtualenv, і виконайте в ньому pip install setuptools==18.3.2, тоді під цим віртуаленвом виконайте python2 bootstrap.py і bin/buildout -N. Надалі запуск тестів мав би працювати і без активації virtualenv, але перезбирання білдауту буде працювати лише під ним.
2. Можливо вам доведеться виконати другу команду у вигляді bin/buildout -N versions:chromedriver=2.24 buildout:find-links+=http://testing.openprocurement.org/userContent/chromedriver-2.24.zip, це скачає трохи свіжішу версію пакету chromedriver.

• Є питання стосовно файловової структури драйвера. Кількість тестів та ключових слів збільшилася. Також треба реалізувати немало розширень на python. Тримати все у 2 файлах, вже дуже не зручно. Якщо в драйвері буде 10-15 файлів, та кожен з них буде виконувати свої завдання, зауважень до ПР не буде?

Розбийте максимум на 5 файлів. впевнена, Вам вистачить) щоб не збільшити час на прийняття PR-ів:

• broker.robot - загальні ключові слова
• broker_utils.robot - якісь службові кл. слова для Вашого драйвера майданчика
• broker_service.py - теж пітонівські службові функції
• як варіант ще broker_view.robot - перевірка відображень, можливо, ще всі локатори

Конфігураційні файли, режими запуску, акселерація і т.д.

• Вопрос по автотестам: автотест по очереди выполняется то нашей ролью, то ролью Quinta.Есть какой-то способ ускорить переход с одного кейса теста на другой?

Так, можна. Для цього використайте параметр timeout_on_wait в brokers.yaml.

• Підскажіть, хто знає, можна якось прискорити виконання автотестів. Бо під роллю провайдера дуже довго чекати.

Якщо ви хочете в себе локально швидше тестувати, вам потрібно зменшити як періоди для свого брокера, так і для брокера Квінти, бо за змовчуванням між вашими і квінтівськими дефолтними періодами вибираються триваліші. Але коли будете кидати ПР, не забудьте повернути минулі дефолтні значення для Квінти.

• В мене в users.yaml enquire [0; 10] .... але ці часові проміжки не ставляться при виконанні тесту. А завжди проставляється +20хв. З чим це може бути пов'язано?

Тому що беруться найбільші часові проміжки серед брокерів, які беруть участь у конкретному прогоні тестів )) і це не проблема, це значить що у вас час синхронізації складає менше 15 секунд, при тому всьому, що рекомендований 5 хв. вам потрібно написати функцію на пайтоні, яка би конвертувала дату, яку ви витягуєте із UI у наступний формат: 2017-04-09T17:47:26.556992+03:00 . Мікро- і наносекунди можна не додавати, а офсет – обов'язково.

• Чи додає ваш сервер опцію на акселерацію при створенні тендера, і з яким коефіцієнтом?

Як і раніше, в brokers.yaml є запис default, який використовується за замовчуванням, якщо налаштувань під якийсь режим не вказано. Зважте, що деякі procurementMethodType можуть не підтримувати акселерацію.

Колись такий блок називався single, коли були mode single і mode multi. Про це є приписка на початку brokers.yaml, датована 2016-03-02. Режиму multi більше немає, а актуальний список модів такий:

• belowThreshold
• openua
• openeu
• reporting
• negotiation
• negotiation.quick
• open_competitive_dialogue

• Не работает режим пропуска аукциона.
• https://lb.api-sandbox.openprocurement.org/api/2.3/tenders/f900f79e592741648f61cbc03c8b13bd?opt_pretty=1
• Опция взведена, но закупка на этапе аукциона. в условиях планирования торгов песочницы на 2018 год это критично.
• ЦБД не реагирует ни на mode:fast-forward, ни на mode:no-auction

Ви використовуєте поле procurementMethodDetails, а потрібно submissionMethodDetails - http://api-docs.openprocurement.org/en/latest/acceleration.html

• Реализую сценарий Complaints. owner. Не проходит тест "Можливість подати пропозицію другим учасником". Ошибка: Keyword 'Звірити статус тендера' failed after retrying for 5 minutes 15 seconds. The last error was: Objects are not equal: active.qualification != active.auction. Добавляемый параметр -v submissionMethodDetails:"quick(mode:fast-forward)" не помогает.

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

• У себя на площадке мы устанавливаем параметр quick(mode:fast-forward) чтобы пропускало аукцион. этот параметр помогает для теста/роли complaints/owner. но он одновременно вредит роли owner в других тестах, например, в тесте singleItemTender квинтовский кейс "Можливість вичитати посилання на аукціон для глядача" падает зависая на ожидании статуса active.auction. а по факту статус уже active.qualification потому что пропустило аукцион. как быть в данном случае?

• PS. выставлять на площадке fast-forward по типу процедуры belowThreshold тоже нельзя потому что и singleItemTender и complaints используют этот тип.

В одному випадку створювати закупівлю із фаст форвард, а у іншому без цього параметру.

• Чи можна якось пропатчити аукціон при запуску тестів з оунером майданчика? Звісно не вносячи змін у код самого майданчика(не тестів, а безпосередньо самого майданчика)?

Для проходження тест сьюта (3-4 рівні) complaints.robot і можливості тестування скарг/вимог на аварді, ми внесли mode: fast-forward, який допомагає тестувати скарги після проходження аукціону (аукціон займатиме мінімальний час). Для реалізації такої можливості в майданчику необхідно реалізувати тріггер, що буде створювати тендер з submissionMethodDetails:"quick(mode:fast-forward)" для Замовника. Це полегшить роботу з цим сценарієм.

• Підкажіть, будь-ласка, на якому рівні потрібно реалізувати режим прискорення? Раніше ми думали, що він не обов'язковий і реалізували його тільки частково для наших внутрішніх юніт тестів. А тепер виникло кілька запитань:

1) Виявляється, що автоматичне тестування без цього режиму не буде працювати. Чи я помиляюсь?

Значить прийдеться додати в розмітку додаткові приховані поля...?

2) А що на рахунок ручних тестів? Треба зробити ці поля відкритими, щоб тестувальник міг вносити множник прискорення, чи ще якісь потрібні дані? Можна десь подивитись зразок реалізації на рівні інтерфейса користувача?

3) Підтримувати режим прискорення потрібно тільки на тестовому сайті, а на своєму продуктиві ми можемо повністю відключити цей функціонал?

4) Крім множника прискорення, які ще параметри потрібно реалізувати? auctionMode...?**

1. Буде працювати. Якщо мова про акселератор в procurementMethodDetails, то можна в brokers.yaml в секції вашого майданчика вписати accelerator: 1, тоді не має значення, чи включали акселератор при створенні тендера, чи ні – результат буде таким, ніби він не активний (множення на одиницю). Якщо мова про режими no-auction і fast-forward в submissionMethodDetails, то їх наявність чи відсутність можна регулювати опцією -v submissionMethodDetails:"quick(mode:no-auction)" і -v submissionMethodDetails:"quick(mode:fast-forward)". Якщо цю опцію не вказувати, то submissionMethodDetails буде мати (дефолтне) значення quick. Якщо потібно відключити quick, то використайте опцію -v submissionMethodDetails:"".

2. Навряд чи на ручних тестах це потрібно перевіряти.

3. Так.

4. Як procurementMethodDetails, так і submissionMethodDetails додавати не обов'язково (додавайте за бажанням). Зазвичай їх додають для того, щоб не доводилось довго чекати на проходження автотестів. Хоча, майте на увазі, що для автотестів ми рекомендуємо використовувати значення quick для procurementMethodDetails, інакше електронний аукціон буде плануватись не "на зараз", а так само, як на продуктиві.

Реалізація драйвера майданчика

• Тест "Можливість задати запитання на тендер" дает TypeError: can't subtract offset-naive and offset-aware datetimes. Что с этим делать?

Додати до дати офсет накшталт "+0200", якщо у вас його бракує, або забрати, якщо у вас він є.

• В тестах есть кейсы где нужно сравнить содержимое документа. у нас есть ссылка на документ формата https://public.docs-sandbox.openprocurement.org/get/2a9237cbd6cd470. Нам его нужно скачать и сохранить в output директорию для сравнения. Подскажите, какими командами можно скачать документ по ссылке и сохранить его в указанную директорию?

Є різні способи. Можна, до прикладу, діствти вміст файлу за допомогою urllib.urlretrieve. Почитати можна ось тут https://docs.python.org/2/library/urllib.html

• Падает кейс "Відображення бюджету тендера" с ошибкой " Objects are not equal: 12349288996.6 (float) != 12349288996.6 (float)". Что с этим делать?

Використати format(budget, '.2f') – гарантовано дасть два знаки після коми, наприклад:

format(1234, '.2f')

'1234.00'

Щоб це використати, можна написати функцію накшталт

`def convert_float_to_string(number):

return format(number, '.2f')`

і в ківорді створення тендера використати її замість Convert To String:

${budget}= Convert Float To String ${budget}

• Скажіть буль-ласка, region та locality у адрессі поставки генеруються рандомно? І якщо так, то де можна подивитися значення з яких вони обираються? Мені потрібно написати python функцію зі словарем, щоб я з неї міг отримувати адаптовані дані, конкретно під наш майданчик і міг підставити в xpath. Тому що я бачу що від вас приходить місто Київ а на майданчику м.Київ і звісно по xpath я потрібний регіон не знаходжу.

В op_faker_data.json .Як приклад: ` "addresses": [

    {
        "deliveryLocation": {

            "latitude": 50.443563,

            "longitude": 30.509402

        },

        "deliveryAddress": {

            "postalCode": "01030",

            "countryName": "Україна",

            "streetAddress": "бульвар Тараса Шевченка, 17",

            "region": "місто Київ",

            "locality": "Київ"

        }

    }`

• Не стартує аукціон

Через обмежену кількість ресурсів на серверах пісочниці інколи аукціон не встигає за графіком і тоді через перепланування з другої спроби він стартує.

• При тестуванні процедури конкурентного діалогу виникли певні питання, була б вдячна за роз'яснення:
• **1. яка тривалість етапу пре-кваліфікації (період оцінки пропозицій) на першому етапі процедури? **
• **2. скільки триває пре-кваліфікація другого етапу процедури конкурентного діалогу з публ. на англ. мові? **

Період пре-кваліфікації має становити 20 днів (по Закону), але ЦБД та майданчики не обмежують його, обмежується період оскарження після прекваліфікації (5 днів)

• Не можемо створити вимогу. При створенні отримуємо помилку "Forbidden error during ProZorro api call."
• req-ee76cdad-7129-4cc7-a42d-7464c688bdeb

"data": {

  "type": "claim",

  "status": "draft",

  "author": {
  
     "identifier": {

     "scheme": "UA-EDR",

     "id": "1212121212",

     "legalName": "ТОВ \"Учасник1\""

   },
  
  "contactPoint": {

     "telephone": "",

     "faxNumber": "+380445555555",

     "email": "[email protected]",

     "name": "Куценко М. В."

  },

  "address": {

     "postalCode": "02232",

     "countryName": "Україна",

     "region": "місто Київ",

     "locality": "м. Київ",

     "streetAddress": "вул. Маяковського 33"

 },
  
  "name": "ТОВ \"Учасник1\"",

  "description": "32424",

  "title": "324234"

}

• підкажіть як вирішити?

http://api-docs.openprocurement.org/uk_UA/latest/complaints-award.html#claim-submission "учасники можуть подати вимогу" - потрібно авторизуватись

• Вопрос по жалобам.

• На пре-квалификации stand-still подали claim. Поскольку claim в открытых торгах является просто чатиком — данная вимога ничего не блокирует. Соотсветственно, прошел аукцион и началась квалификация.

• Заказчик никаком образом не отреагировал на данный claim. На ЦБД статус claim.

• Вопрос: правильно ли это? Мы, как площадка, отображаем то что на цбд. С точки зрения пользователей (обоих) — неясно что делать:

• • у заказчика нет кнопок управления и он уже ничего сделать с ней не может;

• • у участника данное требование отображается как “рассматривается заказчиком”.

• Возможно, стоит как-то переводить их в статус cancelled автоматически? В противном случае нужно нам писать костыли, которые будут делать псевдостатус требованию, когда на него уже нельзя среагировать и закупка изменила статус.

Пропозиція має місце на існування, але оскільки вона суперечить закону, то ДП на даному етапі не внесе відповідних змін в ТЗ, і відповідно не віддасть такого сорту зміни на впровадження. Цю проблему треба розглядати в ширшому контексті, а саме, що робити з вимогами. Чи правити закон, щоб вони ставали "зубатішими" чи допилювати систему, щоб були "беззубі чатики" але згідно з законом... Подібні зміни можуть бути потрібні і в скаргах, які в деяких випадках потребують "жити своїм життям" окремо від процедури, яку можуть до того моменту скасувати.

• При спробі додати документ з підписом до плану
• X-Request-ID: req-c22a2985-6cb4-4247-b182-a975ad186bc0
• ЦБД повертає помилку:
• {"status": "error", "errors": [{"location": "body", "name": "url", "description": "Document url invalid."}]}
• Підкажіть будь-ласка в чому проблема?

Був невірно вирахуваний хешкод

• Сценарий для 1-2 уровня аккредитации. Роль тендер_овнер. Падает тест "Можливість подати пропозицію першим учасником".

Calling method 'create_bid' failed: RequestFailed: {"status": "error", "errors": [{"location": "body", "name": "lotValues", "description": ["This field is required."]}, {"location": "body", "name": "value", "description": ["value should be posted for each lot of bid"]}]}.

Проблема у тому що у тестах генеруються дані для безлотової закупівлі і відповідно клієнт квінти намагається подати пропозицію на тендер, а по факту ви створили лотову закупівлю, от пісочниця і викидує таку відповідь.

• У кейворді "Отримати документ" завантажую файл за допомогою функції пайтона. Документ завантажений, але він чомусь порожній. Зайшов на майданчик, скачав вручну, все гаразд. У документі є текст. Ось функція для завантаження:

`def download_file(url, file_name, output_dir):

urllib.urlretrieve(url, ('{}/{}'.format(output_dir, file_name)))`

Kористувачі квінти використовують інший механізм:

`def download_file_from_url(url, path_to_save_file):

f = open(path_to_save_file, 'wb')

f.write(urllib.urlopen(url).read())

f.close()

return os.path.basename(f.name)`

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

• Як проходить тестування часу? Чи може драйвер повертати час в UTC "2015-03-25T12:00:00Z"? Якщо ні то який офсет треба накладати - локальний чи київський?

Час в такому форматі мав би підійти, якщо не підійде – поміняйте Z на +0000. Який передавати офсет – який хочете, але він має бути правильним, тобто і 2015-03-25T12:00:00+0000, і 2015-03-25T15:00:00+0300 підійдуть. В кількох місцях порівняння дати може відбуватись із датою без офсету (такі генерує Robot Framework), там треба видавати дати без офсету, щоб в результаті був localtime комп'ютера, де запускаються тести. В таких випадках рекомендовано, щоб на комп'ютері був київський час (або TZ=Europe/Kiev).

• Можете уточнить какой именно список файлов доджен быть передан на CD носителе по автотестам? Адаптированный publicportal.robot и что еще?

Файл майданчика *.robot, допоміжний файл *_service.py, i .yaml файли з Вашим майданчиками.

• Є проблема з відображенням дат початку та завершення періоду поставки. На майданчику немає можливості вказувати години, хвилини та секунди. Дата складається тільки з рік, місяць, день. Із-за цього під час тестів на відображення цих дат тест падає, з результатами типу 2017-05-10T11:07:16.459705+03:00 != 2017-05-10T00:00:00+03:00. Чи можна це якось вирішити за допомогою адаптації даних у кейворді Підготувати дані для оголошення тендера

Так, Ви можете адаптувати дані тендера, поміняти значення в ківорді Підготувати дані для оголошення тендера.

• Є питання стосовно координат, під час виконання тестів у ролі tender_owner. В вікі на гітхаб написано. В ключовому слові Підготувати дані для оголошення тендера не можна змінювати тип координат на string, оскільки при перевірці відображення координат виконується їхнє порівняння з певною точністю. Але ж Input Text якщо я не помиляюся не вводить значення якщо воно не String? А якщо ввести координати як String то потім видає помилку. TypeError: Invalid type for coordinate 'right_lon'. Expected one of (<type 'int'>, <type 'long'>, <type 'float'>), got <type 'str'> То в якому ж форматі вводити координати?

У вас є валідація введених координат? Якщо ні, то варто її додати. Тоді, коли юзер вводить текст, цей текст можна буде перетворити в float (на вашому бекенді / JSом на фронтенді / і те, і інше). Потім в тесткейсі відбудеться порівняння float і float. Так само буде і для інших видів введення координат, наприклад, фрейму з картою – в результаті в ЦБД має потрапити float. Якщо вам заважає те, що Input Text не приймає float, то перетворюйте його в текст безпосередньо перед введенням, а не на етапі адаптації вихідних даних.