Sniedz piemēru, kā tu izvēlētos testēšanas gadījumus PUT pieprasījumam.

Testu gadījumu izvēle PUT pieprasījumiem ir vērsta uz pareizu resursa atjaunināšanu, dažādu datu tipu apstrādi un negatīvo scenāriju pārbaudi.

Testu gadījumu piemēri:

1. Pozitīvs scenārijs (veiksmīgs atjauninājums):

   • Resursa atjaunināšana ar visiem derīgajiem laukiem.
   • Resursa atjaunināšana tikai ar daļu derīgo lauku (ja API ļauj daļēju atjaunināšanu).
   • Lauku atjaunināšana ar dažādiem datu tipiem (teksti, skaitļi, loģiskās vērtības), ja tas ir paredzēts shēmā.
   • Resursa atjaunināšana ar minimāli pieļaujamām vērtībām (ja tas ir piemērojams).
   • Resursa atjaunināšana ar maksimāli pieļaujamām vērtībām (ja tas ir piemērojams).

2. Negatīvi scenāriji (kļūdas un izņēmumi):

   • Mēģinājums atjaunināt neeksistējošu resursu. Sagaidāma atbilde: 404 Not Found.
   • Pieprasījuma nosūtīšana bez ķermeņa. Sagaidāma atbilde: 400 Bad Request vai 422 Unprocessable Entity.
   • Pieprasījuma nosūtīšana ar nederīgu ķermeņa formātu (piem., nederīgs JSON). Sagaidāma atbilde: 400 Bad Request.
   • Pieprasījuma nosūtīšana ar nederīgiem datu tipiem laukiem. Piem., teksts vietā skaitlis. Sagaidāma atbilde: 400 Bad Request vai 422 Unprocessable Entity.
   • Pieprasījuma nosūtīšana ar obligātiem laukiem, kas nav norādīti. Sagaidāma atbilde: 400 Bad Request vai 422 Unprocessable Entity.
   • Pieprasījuma nosūtīšana ar vērtībām, kas pārsniedz pieļaujamo garumu vai diapazonu. Sagaidāma atbilde: 400 Bad Request vai 422 Unprocessable Entity.
   • Pieprasījuma nosūtīšana ar nederīgu ID. Sagaidāma atbilde: 400 Bad Request vai 404 Not Found.
   • Mēģinājums atjaunināt bloķētu vai nepieejamu resursu (ja tas ir piemērojams). Sagaidāma atbilde: 403 Forbidden vai 409 Conflict.
   • Pieprasījuma nosūtīšana ar nepareiziem galvenes laukiem (piem., Content-Type). Sagaidāma atbilde: 415 Unsupported Media Type vai 400 Bad Request.
   • Atjaunināšana ar īpašu simbolu vai emoji izmantošanu teksta laukos.

3. Robežvērtību pārbaude:

   • Lauku atjaunināšana ar robežvērtībām (piem., minimālais/maksimālais datums, robežskaitļi).
   • Lauku atjaunināšana ar tukšiem tekstiem vai null vērtībām (ja tas ir atļauts).

4. Paralēlas piekļuves scenāriji:

   • Vienlaicīga mēģinājuma atjaunināt to pašu resursu no vairākiem avotiem.

5. Atjaunināšanas sekas pārbaude:

   • Pārbaudīt, vai dati ir pareizi atjaunināti datu bāzē vai citās sistēmās.
   • Pārbaudīt, vai atkarīgie resursi vai dati ir atjaunināti vai mainīti atbilstoši.
   • Pārbaudīt, vai GET pieprasījums uz atjaunināto resursu atgriež aktuālus datus.
   • Pārbaudīt, vai citas operācijas (DELETE, POST) ar atjaunināto resursu darbojas pareizi.

Konkrēto testu gadījumu izvēles kritēriji ir atkarīgi no API specifikācijas, biznesa prasībām, riska analīzes un prioritātēm. Tiek izmantotas testēšanas tehnoloģijas, piemēram, ekvivalentās sadalīšanas un robežanalīzes, lai noteiktu visizteiktākos ievades datus.