Дай пример как би избрал тестови случаи за PUT заявка.

Изборът на тест-кейсове за PUT заявки е насочен към проверка на коректното обновяване на ресурса, обработката на различни типове данни и негативните сценарии.

Примери за тест-кейсове:

1. Позитивен сценарий (успешно обновяване):

   • Обновяване на ресурса с всички валидни полета.
   • Обновяване на ресурса само с част от валидните полета (ако API позволява частично обновяване).
   • Обновяване на полета с различни типове данни (стрингове, числа, булеви стойности), ако това е предвидено от схемата.
   • Обновяване на ресурса с минимално допустими стойности (ако е приложимо).
   • Обновяване на ресурса с максимално допустими стойности (ако е приложимо).

2. Негативни сценарии (грешки и изключения):

   • Опит за обновяване на несъществуващ ресурс. Очакван отговор: 404 Not Found.
   • Изпращане на заявка без тяло. Очакван отговор: 400 Bad Request или 422 Unprocessable Entity.
   • Изпращане на заявка с невалиден формат на тялото (например, невалиден JSON). Очакван отговор: 400 Bad Request.
   • Изпращане на заявка с невалидни типове данни за полетата. Например, стринг вместо число. Очакван отговор: 400 Bad Request или 422 Unprocessable Entity.
   • Изпращане на заявка с пропуснати задължителни полета. Очакван отговор: 400 Bad Request или 422 Unprocessable Entity.
   • Изпращане на заявка с стойности, превишаващи допустимата дължина или диапазон. Очакван отговор: 400 Bad Request или 422 Unprocessable Entity.
   • Изпращане на заявка с невалидна стойност в пътя (например, невалиден ID). Очакван отговор: 400 Bad Request или 404 Not Found.
   • Опит за обновяване на блокиран или недостъпен ресурс (ако е приложимо). Очакван отговор: 403 Forbidden или 409 Conflict.
   • Изпращане на заявка с неправилни заглавки (например, Content-Type). Очакван отговор: 415 Unsupported Media Type или 400 Bad Request.
   • Обновяване с използване на специални символи или емоджита в стринговите полета.

3. Гранични условия:

   • Обновяване на полета с гранични стойности (например, минимална/максимална дата, гранични числа).
   • Обновяване на полета с празни низове или null стойности (ако е допустимо).

4. Сценарии за паралелен достъп:

   • Едновременна опит за обновяване на един и същ ресурс от няколко източника.

5. Проверка на последствията от обновяването:

   • Проверка дали данните са коректно обновени в базата данни или други системи.
   • Проверка дали зависимите ресурси или данни са обновени/променени съответно.
   • Проверка дали GET заявката към обновения ресурс връща актуални данни.
   • Проверка дали другите операции (DELETE, POST) с обновения ресурс работят коректно.

Критериите за избор на конкретни тест-кейсове зависят от спецификацията на API, бизнес изискванията, анализа на рисковете и приоритетите. Използват се техники за тестов дизайн като еквивалентно разделяне и анализ на граничните стойности, за да се определи най-показателните входни данни.