Як зробити зовнішнє тестування API (blackbox)

14

Припустимо, що ви використовуєте API від постачальника, як переконатися, що їх API працює так, як очікувалося?

Моя головна проблема - інколи постачальник підштовхує зміни до свого коду та порушує API, ми хочемо мати якесь автоматичне програмне забезпечення для постійного їх тестування. Як з цим боротися?

— користувач34401
джерело

Залежно від мови, можуть бути інструменти, які можуть допомогти (я думаю, Pex для C # бібліотек / API).

— Стівен Еверс

10

Коротка відповідь: вам потрібен тестовий набір для стороннього API постачальника - тому вам доведеться розробити його.

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

Деякі речі, які ви можете спробувати додатково:

запитайте у постачальника, чи надає вони список "неполадок змін" для кожного нового випуску
запитайте їх, як вони піклуються про сумісність API / повідомте, що це важлива особливість для вас
перевірте, чи API надає специфічні гачки тестування, вихідний журнал чи щось подібне для деталей, які також неможливо було легко перевірити
загортайте важливі дзвінки API за допомогою власного коду реєстрації, вводячи дані та пов’язані з ними дані API у файл журналу, це полегшить налагодження речей, якщо трапиться щось несподіване
додайте твердження до викликів API, щоб перевірити до- та постумови, тож якщо новий випуск API виявить несподівану поведінку у вашій програмі, ви повідомляєтесь рано повідомленням про помилку

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

— Док Браун
джерело

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

— Gangnus

@Gangnus: ІМХО ОП не розповів нам нічого про свій колишній досвід тестування підрозділу. Якщо у нього є проблеми з цим, я впевнений, що він знає задати більш конкретне запитання. Крім того, тема тут - не "одиничні тести", а "автоматизовані інтеграційні тести". Для них зазвичай потрібна інша схема, ніж, наприклад, тестування одиниць у стилі TDD.

— Док Браун

Так, він цього не сказав. Але якщо він запитує "як переконатися, що їх API працює, як очікувалося", не згадуючи тестових об'єднань, "мені здається", він не знає їх. Що стосується автоматизованих інтеграційних тестів, він не знає їх навіть з більшою ймовірністю, він згадував лише "якесь автоматичне програмне забезпечення". Ви чекаєте від людей тих же знань, що і ваші, але в цих темах 99% програмістів знають набагато менше. і на 90% набагато набагато менше.

— Gangnus

0

Виходячи з фразування плаката, це більше, ніж просто тестування, ІМО. Після того, як ви пишете свій тест на пристрій для API та переконайтеся, що все працює так, як очікувалося, вам слід відстежувати сторонні API, щоб ви могли вирішувати проблеми, перш ніж користувачі. Це реальний ризик для сторонніх API - це не ваш код, і ви не маєте контролю над тим, скільки тестувань було зроблено в API або коли / якщо він зміниться.

(Відмова від відповідальності: тут використовуються назви продуктів) Якщо ви використовуєте soapUI для написання своїх тестів API, ці тести можуть бути повторно використані в AlertSite як операційний монітор, щоб переконатися, що API продовжує працювати, як очікувалося. Якщо тест не вдасться, ви можете отримувати сповіщення, перш ніж ваші користувачі зателефонують вам та скаржаться, що ваш додаток не працює.

— Лорінда Брендон
джерело

0

Реалізуйте навчальні тести для вашої сфери інтересів (функції, які ви плануєте використовувати). Тести на навчання - це тести на інтеграцію, які розробники розробляються проти публічного договору API. Тести не слід записувати на внутрішні деталі реалізації, навіть якщо вихідний код для API доступний. Цей вид навчальних тестів виконує дві цілі -

Це значно покращує ваше розуміння сторонніх API.
Тести допомагають перевірити, чи заявлена нова версія насправді зворотна сумісна чи ні.

— Ананд Патель
джерело

0

Є два підходи до цього питання ...

ваш додаток працює у виробництві з реальним трафіком користувачів:

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

Ви завжди повинні враховувати, що:

api змінюються з часом
постачальник api може мати помилок
Тест-набори постачальників api можуть мати помилки або не повністю покривати всю функціональність виробництва api

ваш додаток - це установка і має заплановану версію / версії:

у цьому випадку у вас пільговий період до виходу з ладу ... живий користувач не здійснює негайних змін із зовнішніми перетвореннями api.

на мою думку, це більш легке завдання. написати тест (повний тест "до кінця"), який робить реальні транзакції / http / запити до вашої програми, яка викликає зовнішні api та перевіряє, чи немає збоїв. жоден тестовий набір не знущається над реальною транзакцією.

після виконання цього завдання ви можете запустити це кожні 24 год, 1 хв тощо тощо ...

передовий досвід:

автоматизувати все
У вас є людина, з якою ви можете швидко зв’язатися з продавцем зовнішнього апалу
не сліпо довіряйте тесту продавця все
невдача - якщо ваша послуга сильно залежить від зовнішньої програми, не дозволяйте вашій службі вийти з ладу. швидко вийти з ладу і повернути належні повідомлення про помилки

інструменти:

моніторинг живого застосування: гіперрічний new-relic
api тестування: apimetrics runcope soapui

— Nimrod007
джерело