#ЧарівнийКомпас 🧭
1️⃣6️⃣5️⃣ Завдання 165
Як би ви підходили до тестуванні REST API на проєкті?
Тестування API дуже часте завдання, з яким так чи інакше доведеться зіткнутися QA інженеру. І, на жаль, не кожен із цим може впоратися. Нижче буде корисний матеріал на цю тему:
🔣 До того, як приступати до тестування, необхідно ознайомитися з API документацією на проєкті, щоб відповідно підготувати всі тести. Вам знадобитися:
➖ зрозуміти базовий URL, від якого будуть відштовхуватися всі API запити.
➖ які endpoints існують на проєкті, щоб усі їх покрити тестами.
➖ які методи можливо використовувати з вашими API.
➖ як і де використовувати аутентифікацію.
➖ які відповіді очікуються.
🔣 Визначаємося з тим, який інструмент використовувати. Наприклад, postman.
🔣 Після приступаємо до основних перевірок:
➖ Почнемо з базових перевірок. Смикаємо GET з основних endpoints. Перевіряємо відповіді. Очікуємо отримати статус "200 OK" і body, що містить очікувану інформацію (наприклад, інформацію про товар або якусь загальнодоступну інформацію, яка не потребує логіна).
➖ Перевіряємо POST. Наприклад, можна заслати інформацію на реєстрацію нового користувача з усіма обов'язковими полями. Повинні отримати "201 Created" і деталі створеної, нової сутності. Після можна мануально перевірити й можливість логіна за цього користувача.
➖ Перевіряємо PUT. Відправляємо інформацію для апдейту вже створеної сутності. Наприклад, міняємо ім'я користувача або іншу інформацію, яка мається на увазі до зміни виходячи з наших вимог. Отримуємо "200 OK". Перевіряємо, чи оновилася інформація вручну.
➖ Перевіряємо DELETE. Видаляємо якусь інформацію або сутність. Отримуємо "200 OK". Не забуваємо перевірити результат вручну.
🔣 Деякі запити можуть вимагати аутентифікації та авторизації:
➖ Для виконання деяких запитів необхідно передати із запитом інформацію про логін і пароль. Якщо цього не зробити, то відповідь має бути "401 Unauthorized" і тіло "Authentication required". Можливий варіант "403 Forbidden" з повідомленням "Access denied", якщо інформація введена неправильно.
🔣 Перевіряємо негативні сценарії:
➖ Надсилаємо запити з не усіма заповненими полями. Наприклад, POST на створення нового користувача з відсутнім обов'язковим полем email. Очікуємо отримати "400 Bad Request" з описом, якої саме інформації не вистачає.
➖ Надсилаємо GET на неіснуючу сутність. Очікуємо "404 Not Found"
➖ Відправляємо не підтримуваний HTTP метод і формат. Наприклад, видалення користувача без зазначення ID. Очікуємо "405 Method Not Allowed".
🔣 Тестуємо методом граничних значень:
➖ Надсилаємо якісь сутності, що не підходять під наші умови. Наприклад, занадто довгий коментар, або ім'я, або будь-яке інше значення, яке повинно мати обмеження згідно з нашими вимогами. Очікуємо відповідь "400 Bad Request" або "404 Not Found".
🔣 Важливо не забувати:
➖ Перевіряємо всі коди помилок
➖ Перевіряємо формат відповіді
➖ Перевіряємо повідомлення про помилки, супутні кодам.
➖ Перевіряємо, що дії, які вимагають авторизації та аутентифікації, без неї спрацювати не можуть.
➖ Якщо є можливість, перевіряємо і продуктивність системи, з великою одночасною кількістю запитів.
#️⃣ Загалом, тестування API не являє собою якихось надскладних речей. Головне мати на руках API-документацію і відштовхуватися від того, що ви робите ті самі дії, що і через UI, але минаючи його. Тут діють усі ті самі закони побудови тестування, що й у звичайному UI мануальному тестуванні, з тією лише різницею, що ви тестуєте ці ж речі «під капотом», якщо так можна висловитися.
@Zatishna_Galera
1️⃣6️⃣5️⃣ Завдання 165
Як би ви підходили до тестуванні REST API на проєкті?
Тестування API дуже часте завдання, з яким так чи інакше доведеться зіткнутися QA інженеру. І, на жаль, не кожен із цим може впоратися. Нижче буде корисний матеріал на цю тему:
🔣 До того, як приступати до тестування, необхідно ознайомитися з API документацією на проєкті, щоб відповідно підготувати всі тести. Вам знадобитися:
➖ зрозуміти базовий URL, від якого будуть відштовхуватися всі API запити.
➖ які endpoints існують на проєкті, щоб усі їх покрити тестами.
➖ які методи можливо використовувати з вашими API.
➖ як і де використовувати аутентифікацію.
➖ які відповіді очікуються.
🔣 Визначаємося з тим, який інструмент використовувати. Наприклад, postman.
🔣 Після приступаємо до основних перевірок:
➖ Почнемо з базових перевірок. Смикаємо GET з основних endpoints. Перевіряємо відповіді. Очікуємо отримати статус "200 OK" і body, що містить очікувану інформацію (наприклад, інформацію про товар або якусь загальнодоступну інформацію, яка не потребує логіна).
➖ Перевіряємо POST. Наприклад, можна заслати інформацію на реєстрацію нового користувача з усіма обов'язковими полями. Повинні отримати "201 Created" і деталі створеної, нової сутності. Після можна мануально перевірити й можливість логіна за цього користувача.
➖ Перевіряємо PUT. Відправляємо інформацію для апдейту вже створеної сутності. Наприклад, міняємо ім'я користувача або іншу інформацію, яка мається на увазі до зміни виходячи з наших вимог. Отримуємо "200 OK". Перевіряємо, чи оновилася інформація вручну.
➖ Перевіряємо DELETE. Видаляємо якусь інформацію або сутність. Отримуємо "200 OK". Не забуваємо перевірити результат вручну.
🔣 Деякі запити можуть вимагати аутентифікації та авторизації:
➖ Для виконання деяких запитів необхідно передати із запитом інформацію про логін і пароль. Якщо цього не зробити, то відповідь має бути "401 Unauthorized" і тіло "Authentication required". Можливий варіант "403 Forbidden" з повідомленням "Access denied", якщо інформація введена неправильно.
🔣 Перевіряємо негативні сценарії:
➖ Надсилаємо запити з не усіма заповненими полями. Наприклад, POST на створення нового користувача з відсутнім обов'язковим полем email. Очікуємо отримати "400 Bad Request" з описом, якої саме інформації не вистачає.
➖ Надсилаємо GET на неіснуючу сутність. Очікуємо "404 Not Found"
➖ Відправляємо не підтримуваний HTTP метод і формат. Наприклад, видалення користувача без зазначення ID. Очікуємо "405 Method Not Allowed".
🔣 Тестуємо методом граничних значень:
➖ Надсилаємо якісь сутності, що не підходять під наші умови. Наприклад, занадто довгий коментар, або ім'я, або будь-яке інше значення, яке повинно мати обмеження згідно з нашими вимогами. Очікуємо відповідь "400 Bad Request" або "404 Not Found".
🔣 Важливо не забувати:
➖ Перевіряємо всі коди помилок
➖ Перевіряємо формат відповіді
➖ Перевіряємо повідомлення про помилки, супутні кодам.
➖ Перевіряємо, що дії, які вимагають авторизації та аутентифікації, без неї спрацювати не можуть.
➖ Якщо є можливість, перевіряємо і продуктивність системи, з великою одночасною кількістю запитів.
#️⃣ Загалом, тестування API не являє собою якихось надскладних речей. Головне мати на руках API-документацію і відштовхуватися від того, що ви робите ті самі дії, що і через UI, але минаючи його. Тут діють усі ті самі закони побудови тестування, що й у звичайному UI мануальному тестуванні, з тією лише різницею, що ви тестуєте ці ж речі «під капотом», якщо так можна висловитися.
@Zatishna_Galera