Co je testování rozhraní? Typy a příklady
⚡ Chytré shrnutí
Testování rozhraní ověřuje, zda si dva propojené softwarové systémy správně vyměňují data. Zahrnuje propojení webového serveru, aplikačního serveru a databázového serveru, které přenášejí každý požadavek aplikace, spolu s ošetřením chyb v jejich okolí.

Co je testování rozhraní?
Testování rozhraní je definováno jako typ testování softwaru, který ověřuje, zda komunikace mezi dvěma různými softwarovými systémy probíhá správně.
Spojení, které integruje dvě komponenty, se nazývá rozhraní. Toto rozhraní v počítačovém světě může být cokoli jako API, webové služby atd. Testování těchto propojovacích služeb nebo rozhraní se označuje jako testování rozhraní.
Rozhraní je ve skutečnosti software, který se skládá ze sad příkazů, zpráv a dalších atributů, které umožňují komunikaci mezi zařízením a uživatelem.
Důležité je, že rozhraní má nevýhodutract: dohodnutý formát požadavku, dohodnutý formát odpovědi, dohodnutá sada chybových kódů a dohodnutý časový limit. Cvičení testování rozhraní, která obsahujítracz obou stran, takže změna provedená jedním týmem tiše nenaruší druhý. Protože většina tohoto provozu se nikdy nedostane na obrazovku, nalezené vady jsou pro testování černé skříňky prováděno pouze prostřednictvím uživatelského rozhraní.
Jak provést testování rozhraní
Testování rozhraní zahrnuje testování dvou hlavních segmentů:
- Rozhraní webového serveru a aplikačního serveru
- Rozhraní aplikačního serveru a databázového serveru.
U výše uvedených scénářů se provádí testování rozhraní
- Zkontrolujte, zda jsou servery spuštěny správně nebo ne
- Chyby jsou zpracovány správně nebo vrátí chybovou zprávu pro jakýkoli dotaz vytvořený aplikací
- Zkontrolujte výsledky, když se mezitím resetuje připojení k webovému serveru
Níže uvedený diagram zobrazuje tyto dva segmenty jako jeden řetězec, kde prohlížeč komunikuje s webovým serverem, webový server komunikuje s aplikačním serverem a aplikační server komunikuje s databázovým serverem.
V praxi tester prochází tímto řetězcem jeden krok po druhém. Každý krok je nejprve řízen platným požadavkem, poté chybným požadavkem a nakonec je vzdálený konec záměrně nedostupný, takže jak cesta k úspěchu, tak cesta k neúspěchu jsou zaznamenávány ve stejném pořadí. modelový případ.
Příklad testování rozhraní
Předpokládejme, že pro jakoukoli aplikaci xyz rozhraní nabývá XML soubor jako vstup a doručí JSON soubor jako výstup. Pro otestování rozhraní této aplikace stačí znát specifikace formátu souboru XML a formátu souboru JSON.
S pomocí těchto specifikací můžeme vytvořit vzorové vstupní XML soubory a vložit je do rozhraní. Následné ověření vstupního (XML) a výstupního (JSON) souboru s požadavky je testování rozhraní.
Všimněte si, co příklad nepotřebuje: žádnou obrazovku, žádné sestavení frontendu a žádnou znalost kódu uvnitř rozhraní. Pro napsání testů stačí dvě specifikace formátu, a proto může testování rozhraní začít dlouho předtím, než existuje uživatelské rozhraní.
Proč provádět testování rozhraní
Testování rozhraní je hotovo
- Aby se zajistilo, že koncoví uživatelé nebo zákazníci by se při používání konkrétního softwarového produktu neměli setkat s žádnými problémy
- Chcete-li zjistit, které aplikační oblasti jsou obvykle přístupné koncovým uživatelům, a také zkontrolovat její uživatelskou přívětivost.
- Pro ověření bezpečnostních požadavků při šíření komunikace mezi systémy
- Chcete-li zkontrolovat, zda je řešení schopno zvládnout selhání sítě mezi aplikačním serverem a webem
Existuje také argument nákladů. Oprava vady ve formátu požadavku je levná, dokud jsou oba systémy stále propojovány, a drahá, jakmile následný systém již uložil chybná data.
Typy testování rozhraní
Během testování rozhraní se na rozhraní provádějí různé typy testování, které mohou zahrnovat
- Pracovní postup: Zajišťuje, že modul rozhraní zpracuje vaše standardní pracovní postupy podle očekávání.
- Okrajové případy - neočekávané hodnoty: Toto se bere v úvahu při testování s obráceným zařazením data, měsíce a dne.
- Testování výkonu, zátěže a sítě: Rozhraní s vysokou hlasitostí může vyžadovat více Testování zatížení než nízkoobjemové rozhraní, v závislosti na modulu rozhraní a infrastruktuře připojení
- Jednotlivé systémy: To zahrnuje testování každého systému jednotlivě. Například fakturační systém a systém řízení zásob pro maloobchodní prodejnu by měly být schopny fungovat samostatně.
První položka je dostatečně blízko testování pracovního postupu znovu použít jeho scénáře a poslední položka se překrývá s testování modulů, protože systém, který sám selže, selže znovu, jakmile bude připojen.
Strategie testování rozhraní
Strategie testování rozhraní je metoda používaná k testování rozhraní pomocí běžných testů bez ohledu na implementaci. Můžeme použít abstract testovací případy a vytvořit konkrétní instance testovacího případu pro každou implementaci strategie testování rozhraní. Základní/abstracTestovací případy t provádějí implementačně neutrální testy, zatímco konkrétní testy se starají o vytváření instancí objektů pro testování a provádění implementačně specifických testů.
Výhodou této struktury je její opětovné použití. Když se objeví třetí implementace stejného rozhraní, abstract suite na něj běží beze změny a stačí napsat pouze kód pro instanciaci. Stejná myšlenka je aplikována ve větším měřítku v testování komponent, kde sdílený podvodtracSada t se spouští na každé komponentě, která tvrdí, že ji splňuje.
Nástroje pro testování rozhraní
Protože rozhraní nemá obrazovku, musí nástroje konstruovat požadavky přímo a prosazovat je na základě nezpracovaných odpovědí. Týmy obvykle kombinují tři kategorie nástrojů.
- Klienti API a nástroje pro tvorbu požadavků: Nástroje jako Postman, SoapUI, Insomnia a Hoppscotch odesílají volání REST, SOAP nebo GraphQL, ukládají je jako opakovaně použitelné kolekce a provádějí asserty na stavových kódech, záhlavích a tělech odpovědí.
- Codetestovací knihovny na úrovni -level: Knihovny běžící v rámci existující testovací sady umožňují, aby kontroly rozhraní běžely vedle jednotkových testů a spouštěly se při každém sestavení, což jim brání v zastarávání.
- Nástroje pro načítání a protokolování: Nástroj, jako například JMeter řídí stejné rozhraní na objemu, což promění funkční kontrolu v testování výkonu spojení.
- Virtualizace služeb a simulace: Pahýl zastupující vzdálený konec umožňuje testování jedné strany, zatímco druhá je nedostupná, nedokončená nebo příliš drahá na opakované volání.
Výběr je méně důležitý než pokrytí. Ať už je klient vybrán jakýkoli, kolekce požadavků musí být uložena ve správě verzí spolu s kódem, takže změna rozhraní a změna jeho testů se objeví ve stejném commitu. Podrobnosti o širší kategorii jsou uvedeny v API testování.
Kontrolní seznam testování rozhraní a osvědčené postupy
Krátký kontrolní seznam zajišťuje poctivost pokrytí rozhraní napříč verzemi. Projděte si ho pro každé připojení, nikoli pro aplikaci jako celek.
- stract první: Ověřte, zda schémata požadavků a odpovědí odpovídají publikované specifikaci, pole po poli, včetně datových typů a volitelných polí.
- Hraniční hodnoty: Odesílat prázdné datové části, pole s maximální délkou, neočekávané znakové sady a obrácené formáty data.
- Cesty k chybám: Ověřte, že každé selhání vrací smysluplný kód a zprávu, nikoli zásobník. trace nebo tichý úspěch.
- Časové limity a opakované pokusy: Přerušte spojení uprostřed požadavku a bezpečně potvrďte opakované pokusy volajícího bez duplikování transakce.
- Zabezpečení Zkontrolujte ověřování, autorizaci a šifrování odkazu a ověřte, že chybové zprávy neunikají interním informacím.
- Konzistence dat: Přečtěte si záznam zpět od druhé strany a ověřte, že během přenosu nebylo nic zkráceno, překódováno ani změněno jeho pořadí.
- Objem: Opakujte volání s nejvyšším provozem při souběžném zatížení a sledujte vyčerpání fondu připojení.
Tři postupy umožňují opakovat tento kontrolní seznam. Zaprvé, automatizovat sadu a spouštět ji při každém sestavení, protože rozhraní se mění tišeji než obrazovky. Zadruhé, zaznamenávat celý požadavek a odpověď pro každé selhání, protože vadu rozhraní je téměř nemožné reprodukovat ze snímku obrazovky. Zatřetí, udržovat sadu nezávislou na testovacích datech vytvořených jinými sadami, aby selhání ukazovalo na rozhraní, nikoli na chybějící záznam.
Tyto kontroly přirozeně zapadají do širšího plánu popsaného v typy testování softwarua běží předtím, než jsou stejná spojení prováděna od začátku do konce během testování systému.
Testování rozhraní versus testování integrace
Tyto dva pojmy spolu spíše souvisejí než si odporují: testování rozhraní je součástí integrační práce, která se zaměřuje na samotné připojení. Níže uvedená tabulka uvádí důraz na každou stranu.
| Testování rozhraní | Testování integrace |
|---|---|
| Typ integračního testu, který se zabývá testováním rozhraní mezi komponentami nebo systémy | Testování prováděné za účelem odhalení defektů v rozhraních a v interakcích mezi integrovanými komponentami nebo systémy. |
| Soustředění je podvodtract — formát požadavku, formát odpovědi, chybové kódy a časové limity | Fokus je kombinované chování komponent po jejich spojení. |
| Lze spustit, jakmile specifikace existuje, s odříznutým vzdáleným koncem | Vyžaduje, aby zúčastněné komponenty byly sestaveny a nasazeny společně |
| Chyba ukazuje na jedno připojení | Chyba může ukazovat na jakoukoli součást v sestavené skupině |
Každý, kdo je v širší disciplíně nováčkem, najde okolní úrovně popsané v integrační testování a obecně testování softwaru úvod, zatímco výše použitá terminologie pochází ze standardního softwarové inženýrství praxe. U systémů orientovaných v prohlížeči se stejná připojení nakonec znovu provádějí během testování webových aplikací.

