API testing: Čo to je, ako funguje a aké nástroje použiť

Autor:  Michaela Kojnoková

Testovanie • 16 min. čítania • 1. 7. 2026

Autor:  Michaela Kojnoková •

Testovanie • 16 min. čítania • 1. 7. 2026

API testing patrí medzi najefektívnejšie spôsoby, ako odhaliť chyby ešte predtým, než sa dostanú k používateľovi. Overuje logiku, dátové toky aj bezpečnosť aplikácie priamo na úrovni rozhraní, kde vzniká väčšina kritických problémov. Zoznám sa s typmi API testov, odporúčanými nástrojmi ako Postman, Cypress či Apache JMeter a praktickými stratégiami, ktoré využiješ pri testovaní v reálnych projektoch.

Čo je API a prečo je API testing dôležitý?

API (Application Programming Interface – aplikačné programové rozhranie) je kontrakt medzi dvoma softvérovými komponentmi. Definuje, ako si systémy vymieňajú dáta a volajú funkcie navzájom. Používa ho každý moderný systém. Mobilná aplikácia volá API, aby získala kurzy mien, poisťovňa volá API, aby overila platobnú históriu klienta, e-shop volá API platobnej brány pri každej transakcii. API testing je pre spoľahlivosť týchto procesov nevyhnutný.

API rozhranie tvorí jadro každej modernej aplikácie. Ak API nefunguje, UI nepomôže. Práve API riadi logiku, pravidlá a dátové toky. Testerom, ktorí testovanie softvéru robia profesionálne, preto nestačí ovládať len UI nástroje. API testing sa zameriava na vrstvu, kde sa zachytí väčšina kritických chýb rýchlejšie, lacnejšie a spoľahlivejšie ako cez rozhranie.

API je krvným obehom moderných aplikácií. Komunikuje s databázami, externými službami, platobnými bránami a inými mikroslužbami. Keď API zlyhá, padá celá aplikácia.

Test pyramída: Kde patrí API testing

Test pyramída je základný model, ktorý ukazuje, ako rozdeliť investície do rôznych typov testov. Zdola nahor:

• Unit testy (základ pyramídy): rýchle, izolované, testujú jednotlivé funkcie. Najlacnejšie na písanie aj spúšťanie.
• API testy (stred pyramídy): overujú logiku, integrácie a pravidlá bez UI. Rýchlejšie ako UI testy, stabilnejšie v čase.
• UI/E2E testy (vrchol pyramídy): pomalé, krehké, drahé na údržbu. Používaj ich len na kľúčové používateľské toky.

Test pyramída znázorňujúca význam API testov

Výhody API testingu oproti UI testovaniu

Rozdiel medzi API a UI testovaním najlepšie vidno v praxi, napríklad pri automatizácii cez Selenium, kde každá zmena v rozhraní okamžite ovplyvní stabilitu testov, zatiaľ čo API vrstva zostáva stabilná.

API testing zároveň šetrí náklady. Chybu zachytíš skôr a zaplatíš za ňu menej. V produkcii sa rovnaký problém násobí časom, peniazmi aj dopadom na používateľov.

Typy API testov

Každý typ API testu overuje iný aspekt API. Komplexná testovacia stratégia ich kombinuje:

Funkčné testovanie

Overuje, že každý endpoint robí presne to, čo má. Vracia správne dáta, správne stavové kódy a správne spracúva vstupy. Funkčné testovanie je základ každej testovacej sady.

Čo konkrétne kontroluješ:

• Stavové kódy: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 409 Conflict, 422 Unprocessable Entity, 500 Internal Server Error
• Tvar a typy hodnôt v response body (JSON schema validácia)
• Happy path: správne vstupy vedú k správnym výstupom
• Negatívne scenáre: chýbajúce polia, neplatné hodnoty, neplatné typy
• Hraničné prípady: minimálne a maximálne hodnoty, prázdne polia, špeciálne znaky

Integračné testovanie

Integračné testovanie overuje spoluprácu viacerých endpointov alebo služieb.

Typický scenár: zaregistruj používateľa → prihlás ho → vytvor objednávku → zaplať → skontroluj stav. Každý krok je závislý na predchádzajúcom.

V mikroslužbových architektúrach je integračné testovanie kritické. Každá služba má vlastné API a v komunikácii medzi nimi sa môže chyba prejaviť nečakane až v produkcii. Integračné testy odhalia tieto zlyhania ešte pred nasadením.

Záťažové a výkonnostné testovanie

Overuje, že API zvládne reálnu záťaž bez degradácie výkonu. Medzi typy záťažových testov patria:

• load test: simulácia bežnej záťaže (napr. 500 súbežných požiadaviek),
• stress test: záťaž nad limity systému, sledovanie kde a ako zlyhá,
• spike test: náhly nárast záťaže (napr. spustenie kampane),
• endurance test: dlhodobá záťaž na odhalenie memory leakov a degradácie.

Záťažové a výkonnostné testovanie odhaľujú limity systému ešte pred reálnou prevádzkou a pomôže predísť výpadkom pri špičkovej záťaži, pričom v praxi sa na tieto scenáre často využíva nástroj JMeter.

Záťažové testovanie API

Response time pri 100, 500 a 1000 používateľoch. Pri ~500 používateľoch začína systém spomaľovať, pri 1000 prekračuje svoj limit

Testovanie18 min.

20. 3. 2024

Testovanie bezpečnosti: Safety & security testing

V tomto článku sa dozvieš, čo pojmy Safety testing a Security testing predstavujú, ako sú prepojené a ako ich môžeš využiť na zabezpečenie svojich aplikácií.

Bezpečnostné testovanie API

Bezpečnostné testovanie API je jednou z najdôležitejších, ale aj najčastejšie zanedbávaných oblastí. API sú primárnym cieľom útokov, pretože obsahujú citlivé dáta a logiku.

Čo overovať podľa OWASP API Security Top 10:

• Autentifikácia: overenie identity (tokeny, JWT, OAuth 2.0, API kľúče)
• Autorizácia: má volajúci oprávnenie na túto operáciu? Testuj prístup s rôznymi rolami.
• Expozícia citlivých dát: neobsahuje response viac dát ako je nutné?
• Rate limiting: je API chránené pred brute-force a DDoS útokmi?
• Injekčné útoky: SQL injection, NoSQL injection cez parametre a body
• BOLA (Broken Object Level Authorization): môže tester A vidieť dáta testera B?

OWASP API Security Top 10 (2023): rebríček najkritickejších bezpečnostných rizík pre API 

OWASP API Security Top 10

Contract testing

Contract testing overuje, že producent (API server) a konzument (klient) dodržiavajú dohodnutý kontrakt – tvar requestov a responses. Nástroj Pact umožňuje tento kontrakt definovať a automaticky overovať pri každom builde.

Je to kľúčová technika v mikroslužbových architektúrach. Keď tím A zmení API, Pact okamžite odhalí, či tým B (ktorý toto API konzumuje) bude stále fungovať. Bez contract testingu sa takéto nezlučiteľné zmeny odhalia až v integrovanom prostredí alebo v produkcii.

Regresné testovanie

Regresné testy overujú, že nová zmena kódu nerozbila existujúcu funkcionalitu. Každý deploy by mal automaticky spustiť regresnú sadu API testov. Práve regresné testovanie je prvou líniou obrany pred chybami, ktoré sa nečakane objavia po úpravách v kóde.

Fuzz a negatívne testovanie

Fuzz testovanie posiela na API náhodné, neočakávané a malformované vstupy. Ich cieľom je odhaliť zlyhania, ktoré bežné testy nezachytia. Negatívne testovanie systematicky testuje chybové stavy: chýbajúce polia, neplatné typy, záporné čísla, prázdne reťazce, SQL injections.

Ako testovať API – 5-fázový postup

Praktický proces testovania API má päť fáz. Platí pre manuálne aj automatizované testovanie:

#1 Zorientuj sa v API dokumentácii

Začni vždy od špecifikácie. Swagger/OpenAPI dokumentácia ti povie endpointy, metódy, parametre, povinné polia a očakávané odpovede. Bez dokumentácie testuješ naslepo.

#2 Nastav si testovacie prostredie

Priprav environment variables (base URL, tokeny, prihlasovacie údaje). Nikdy nezadávaj citlivé hodnoty priamo do testov. Oddeľ prostredia: dev, test, staging.

#3 Vytvor test cases

Pre každý endpoint definuj happy path (správne vstupy → správne výstupy) aj edge cases (hraničné hodnoty, chýbajúce polia, neplatné typy). Pokryj všetky HTTP metódy, ktoré endpoint podporuje.

#4 Odošli requesty a skontroluj response

Spusti testy a over: stavový kód, tvar response body, typy hodnôt, čas odozvy, hlavičky. Neoveriť stavový kód je jedna z najčastejších chýb začiatočníkov.

#5 Zapoj automatizáciu do CI/CD

Manuálne testy nestačia. Každý build alebo pull request by mal automaticky spustiť API testy. Rýchle smoke testy spúšťaj pri každom commite, plnú regresnú sadu pri merge do main branchu. Dobre nastavené CI/CD z toho urobí prirodzenú súčasť vývoja, nie krok navyše pred releasom.

Príklad použitia GET request a JSON response

Nasledujúci príklad ukazuje základný GET request na REST API endpoint a overenie response:

 // GET request - načítanie detailu zmluvy
GET /api/v1/contracts/12345
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Accept: application/json
 
// Očakávaná JSON response (200 OK)
{
  "id": "12345",
  "status": "active",
  "client": {
	"id": "C-9876",
	"name": "Ján Novák"
  },
  "premium": 45.50,
  "currency": "EUR",
  "validFrom": "2024-01-01",
  "validTo": "2025-01-01"
}

// Čo overuješ:
// ✅ Status code = 200
// ✅ Content-Type: application/json
// ✅ id === "12345" (string, nie integer)
// ✅ status je jeden z povolených enumov
// ✅ premium je číslo s max 2 desatinnými miestami
// ✅ dátumy vo formáte YYYY-MM-DD
// ✅ response time < 500ms 

Príklad testovania login API

Login endpoint patrí medzi najdôležitejšie a zároveň najviac exponované časti API. Pri jeho testovaní potrebuješ pokryť viac scenárov:

• Pozitívny test: správne prihlasovacie údaje → 200 OK, JWT token, expirácia
• Negatívny test: zlé heslo → 401 Unauthorized, žiadny token v response
• Validačný test: chýba pole „password“ → 400 Bad Request alebo 422 s detailom chyby
• Bezpečnostný test: rate limit – po 5 neúspešných pokusoch API blokuje ďalšie pokusy
• Výkonnostný test: 200 súbežných prihlásení za sekundu bez degradácie latencie

HTTP metódy a stavové kódy: základ API testovania

Každý API tester musí ovládať HTTP metódy a stavové kódy. Sú jazykom, ktorým tester hovorí s API. Bez ich pochopenia nevieš vedome overiť, či sa API správa správne.

HTTP metódy

Stavové kódy: Čo testovať a prečo

Správny stavový kód je rovnako dôležitý ako obsah odpovede. Kontrolovať len text response a ignorovať status code je jedna z najčastejších chýb. Kľúčové skupiny:

• 2xx – úspech: 200 OK (GET, PUT, PATCH, DELETE s telom), 201 Created (POST), 202 Accepted (asynchrónne operácie), 204 No Content (DELETE bez tela).
• 4xx – chyba klienta: 400 Bad Request (neplatný vstup), 401 Unauthorized (nie si prihlásený), 403 Forbidden (prihlásený, ale nemáš oprávnenie), 404 Not Found, 409 Conflict (duplicita alebo verzionovací konflikt), 422 Unprocessable Entity (syntakticky správny ale sémanticky neplatný).
• 5xx – chyba servera: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout. Tieto kódy by sa nemali objavovať v bežných negatívnych testoch, ale treba ich logovať a eskalovať.

Tester overuje aj tvar chybových odpovedí, a to konzistentné error body s poliami code, message, details a korelačným ID v hlavičke. Konzistentnosť chybových odpovedí naprieč celým API je znak kvality dizajnu a uľahčuje diagnostiku incidentov.

Typy API: REST, SOAP a GraphQL

Nie každé API je REST. Tester musí rozumieť rozdielom, pretože ovplyvňujú čo a ako testuješ – formáty, validáciu, bezpečnosť, chyby aj výkon.

REST API

REST API je dnes najpoužívanejší architektonický štandard. Používa HTTP protokol, pracuje so zdrojmi a endpointmi, odpovede sú väčšinou v JSON formáte. REST je bezstavový. Každý request obsahuje všetky potrebné informácie.

REST API testuješ cez HTTP metódy GET (čítanie), POST (vytvorenie), PUT (plná aktualizácia), PATCH (čiastočná aktualizácia), DELETE (odstránenie). Každá metóda má svoje pravidlá, očakávané stavové kódy a testovací prístup.

SOAP API

SOAP (Simple Object Access Protocol) je protokol s pevnou XML špecifikáciou. Používa sa v bankovníctve, poisťovníctve a legacy enterprise systémoch. Práve preto je relevantný pre testerov v msg life kontexte. SOAP prináša vysokú bezpečnosť (WS-Security, šifrovanie, podpisy) a transakčnú spoľahlivosť.

Pri testovaní SOAP API overuješ validáciu XML schém (XSD), správnosť SOAP headers a error handling scenáre. Špecializované nástroje: SoapUI, Postman v XML režime.

GraphQL

GraphQL je moderný dotazovací jazyk vytvorený Facebookom. Klient si presne určuje, aké dáta chce – žiadne overfetching ani underfetching. Namiesto viacerých REST endpointov má GraphQL zvyčajne jeden endpoint s flexibilnými dotazmi.

Pre QA prináša GraphQL špecifické výzvy: testovanie schémy (GraphQL schema validation), komplexnejšie bezpečnostné testovanie, throttling queries na prevenciu nadmernej záťaže a testovanie nested queries. Používa sa hlavne v moderných webových a mobilných aplikáciách s komplexnými UI.

Nástroje na testovanie API

Výber správneho nástroja závisí od tímu, stacku a typu testov. Pozri si porovnanie nástrojov na testovanie API od populárnych GUI klientov po frameworky pre automatizáciu:

Okrem týchto piatich nástrojov stojí za zmienku aj Insomnia (minimalistický GUI klient s výbornou podporou GraphQL), Bruno (open-source alternatíva k Postman s Git-friendly kolekcami) a REST Assured (štandard pre Java tímy, silná DSL syntax, výborná integrácia s JUnit a TestNG).

Ako vybrať framework:

• Java ekosystém → REST Assured + JUnit / TestNG
• JavaScript / TypeScript → Cypress, Playwright API testing alebo Supertest + Jest
• Python → pytest + requests + pydantic na schémy
• Low-code / no-code → Katalon alebo Postman s Newman CLI
• Záťažové testy → JMeter alebo k6

Stratégie testovania API

Dobrá stratégia testovania API nie je len o nástrojoch. Ide o systémový prístup k tomu, kedy, čo a ako testuješ. Tu sú kľúčové stratégie testovania API, ktoré používajú top QA tímy:

Shift-left testing: Testuj čím najskôr

Shift-left znamená presunúť testovanie čo najbližšie k začiatku vývojového cyklu. Namiesto čakania na hotové UI začneš testovať API hneď, ako je endpoint implementovaný alebo dokonca skôr, ak tím pracuje contract-first.

Výhoda shift-left v číslach:

• chyba opravená počas vývoja stojí 1-krát,
• chyba opravená po deploymente stojí 10-krát viac,
• chyba opravená po incidente v produkcii stojí 100-krát viac.

Shift-left je ekonomické rozhodnutie.

Testovanie25 min.

31. 7. 2025

Automatizované testovanie softvéru: Spoznaj proces a top nástroje na automatizáciu

Zaujíma ťa oblasť testovania a chceš sa dozvedieť viac o automatizovanom testovaní? V našom článku ti prezradíme všetky dôležité informácie.

Test pyramída: rozloženie investícií

Drž sa pravidla 70/20/10 – väčšina testov na unit úrovni, solídna vrstva API testov v strede, minimum UI testov na vrchole. API testy sú najlepšou investíciou. Sú rýchle, stabilné a pokrývajú jadro logiky aplikácie.

Contract-first prístup

Najprv definuj špecifikáciu API (OpenAPI/Swagger), potom implementuj. Tester sa môže zapojiť do review špecifikácie ešte pred napísaním prvého riadku kódu. Chyby v dizajne sú najlacnejšie vtedy, keď sú opravené ešte pred implementáciou.

Contract testing (Pact) automaticky overuje, že každý producent aj konzument dodržiavajú dohodnutý kontrakt. V mikroslužbovom prostredí je to nevyhnutnosť. Bez neho sa nezlučiteľné zmeny API odhalia až pri integrácii.

Data-driven testing

Rovnaký test spúšťaš s rôznymi vstupnými dátami. Parametrizované testy pokrývajú viac scenárov s menším množstvom kódu. Napríklad jeden test pre overenie validácie vstupov spustíš s 20 rôznymi kombináciami platných aj neplatných hodnôt.

Data-driven prístup je výhodný najmä pre finančné aplikácie a poisťovníctvo, kde existuje veľa kombinácií vstupných hodnôt (typy zmlúv, rizikové skupiny, vekové kategórie). Jedným parametrizovaným testom pokryješ desiatky scenárov.

Automatizácia v CI/CD pipeline

Cieľový stav každého QA tímu: API testy bežia automaticky pri každom build alebo pull requeste, bez manuálnej intervencie. Postup:

• Rýchle smoke testy (5 – 10 minút) spúšťaj pri každom commite. Overujú, že základná funkcionalita funguje.
• Plnú regresnú sadu spúšťaj pri každom merge do main branchu.
• Záťažové a bezpečnostné testy spúšťaj v noci alebo pred každým release.
• Paralelizuj testy podľa domén alebo služieb. Skrátiš tak čas behu na zlomok.
• Ukladaj artefakty (reporty, logy, HAR záznamy). Sú potrebné pre rýchlu diagnózu zlyhaní.

Odporúčame ti…

Pre poisťovnícky a finančný sektor navyše platí, že každý API test by mal logovať korelačné ID requestu. Pri incidente v produkcii umožní vystopovať konkrétny request naprieč všetkými mikroslužbami. Bez toho je diagnostika veľmi ťažká.

Typické chyby pri API testingu, ktorým sa vyhni

Aj skúsení testeri robia opakovane tie isté chyby. Tu sú najčastejšie chyby pri API testingu:

• Kontroluješ len text odpovede, nie stavový kód. Response body môže vyzerať správne, ale status 200 namiesto 201 alebo 404 namiesto 400 je chyba.
• Ignoruješ negatívne a hraničné vstupy. Happy path nestačí. 40 – 60 % chýb sa objaví práve v negatívnych scenároch.
• Netestuješ autorizáciu a roly. Môže používateľ A vidieť dáta B? Má guest prístup k admin endpointom? Toto je BOLA zraniteľnosť č. 1 v OWASP.
• Nemáš validáciu JSON schémy. Response môže mať správne hodnoty, ale nesprávne typy (string namiesto integer). Schema validácia toto odhalí automaticky.
• Chýbajú výkonnostné testy. API funguje skvele pre 10 používateľov, padá pre 1 000. Bez load testov sa to dozvieš až v produkcii.
• Testy bežia len ručne, nie v CI/CD. Manuálne testy sú nespoľahlivé a pomalé. Bez automatizácie v pipeline nie je testovanie škálovateľné.
• Chýbajú korelačné ID a logovanie. Keď test zlyhá, potrebuješ vedieť prečo. Bez korelačného ID v hlavičke je diagnostika zdĺhavá.

Zdieľaj článok

API testing: Čo to je, ako funguje a aké nástroje použiť

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn