Výukový program pro testování API: Kompletní průvodce pro začátečníky

api testing tutorial

Tento podrobný návod k testování API vysvětluje vše o testování API, webových službách a způsobu zavedení testování API ve vaší organizaci:

Z tohoto úvodního kurzu získáte hluboký vhled do testování API spolu s konceptem testování levého posunu a webových služeb.

Koncepty jako Web API, jak funguje API (s příkladem z reálného světa) a jak se liší od webových služeb, jsou dobře vysvětleny na příkladech v tomto kurzu.

=>POSUNOUT DOLŮzobrazit celý seznam 5 podrobných návodů pro testování API pro začátečníky

Co se naučíte:

• Seznam výukových programů pro testování API
• Přehled výukových programů v této sérii testování API
• Výukový program pro testování API
  • Testování posunu doleva
  • Životní cyklus vývoje softwaru (SDLC) před testováním posunu doleva
  • Fáze testování řazení vlevo
  • Webové rozhraní API
  • Jak funguje API?
  • Webové služby
  • Webové služby vs. webové API
• Představujeme testování API ve vaší organizaci
  • Posun zaměření na testování API
  • Úplné spektrum testování API
    • i) Funkční testování
    • ii) Testování zátěže a výkonu
    • (iii) Testování bezpečnosti
  • Jak zavést testování API ve vaší organizaci
  • Společné výzvy a způsoby, jak je zmírnit
    • # 1) Výběr správného nástroje
    • # 2) Chybějící specifikace testu
    • # 3) Křivka učení
    • # 4) Existující sada dovedností
  • Případová studie
• Závěr
  • Doporučené čtení

Seznam výukových programů pro testování API

Výukový program č. 1: Výukový program pro testování API: Kompletní průvodce pro začátečníky
Výukový program č. 2: Výukový program webových služeb: Komponenty, architektura, typy a příklady
Výukový program č. 3: Nejlépe 35 dotazů na rozhovor s ASP.Net a webovým API s odpověďmi
Výukový program č. 4: Výukový program POSTMAN: Testování API pomocí POSTMANU
Výukový program č. 5: Testování webových služeb pomocí klienta HTTP Apache

Přehled výukových programů v této sérii testování API

Výukový program pro testování API

Tato část vám pomůže získat základní znalosti o webových službách a webovém rozhraní API, které zase pomohou pochopit hlavní koncepty v nadcházejících cvičeních v této sérii testování API.

API (Application Programming Interface) je sada všech postupů a funkcí, které nám umožňují vytvořit aplikaci přístupem k datům nebo funkcím operačního systému nebo platforem. Testování těchto postupů je známé jako Testování API.

Testování posunu doleva

Jedním z důležitých typů testování, které se dnes v rozhovorech pro testování API žádá, je Shift Left Testing. Tento typ testování se praktikuje téměř u všech projektů, které se řídí agilní metodikou.

Před zavedením Shift Left Testing se testování softwaru dostalo do obrazu až po dokončení kódování a doručení kódu testerům. Tato praxe vedla ke shonu na poslední chvíli, aby byla dodržena lhůta, a do značné míry také omezila kvalitu produktu.

Kromě toho bylo vynaložené úsilí (kdy byly vady hlášeny v poslední fázi před výrobou) obrovské, protože vývojáři museli znovu projít fází návrhu i kódování.

Životní cyklus vývoje softwaru (SDLC) před testováním posunu doleva

Tradiční tok SDLC byl: Požadavek -> Návrh -> Kódování -> Testování.

Nevýhody tradičního testování

• Testování je extrémně správné. Při identifikaci chyby na poslední chvíli vznikají velké náklady.
• Čas spotřebovaný na vyřešení chyby a její opakované testování před jejím povýšením na produkci je obrovský.

Proto se objevila nová myšlenka, která posunula fázi testování doleva, což vedlo k testování posunu doleva.

Doporučené čtení => Testování posunu doleva: tajná mantra úspěchu softwaru

Fáze testování řazení vlevo

assert () c ++

Testování levého posunu vedlo k úspěšné migraci z Detekce defektů na Prevenci defektů. Pomohlo to také rychlému selhání softwaru a opravě všech poruch co nejdříve.

Webové rozhraní API

Obecně lze webové rozhraní API definovat jako něco, co převezme požadavek z klientského systému na webový server a odešle zpět odpověď z webového serveru na klientský počítač.

Jak funguje API?

Podívejme se na velmi běžný scénář rezervace letu na www.makemytrip.com, což je online cestovní služba, která agreguje informace od více leteckých společností. Při rezervaci letu zadáte informace, jako je datum cesty / datum návratu, třída atd., A kliknete na vyhledávání.

Zobrazí se cena několika leteckých společností a jejich dostupnost. V tomto případě aplikace interaguje s API více leteckých společností a tím umožňuje přístup k datům letecké společnosti.

Dalším příkladem je www.trivago.com, který porovnává a uvádí ceny, dostupnost atd. Různých hotelů z konkrétního města. Tento web komunikuje s API více hotelů za účelem přístupu do databáze a uvádí seznam cen a dostupnosti z jejich webových stránek.

Webové rozhraní API lze tedy definovat jako „rozhraní, které usnadňuje komunikaci mezi klientským počítačem a webovým serverem“.

Webové služby

Webové služby jsou (jako webové rozhraní API) služby, které slouží z jednoho počítače na druhý. Ale hlavní rozdíl, který vzniká mezi API a webovými službami, je ten, že webové služby používají síť.

Lze s jistotou říci, že všechny webové služby jsou webová rozhraní API, ale všechna webová rozhraní API nejsou webové služby (vysvětleno v druhé části článku). Webové služby jsou tedy podmnožinou webového rozhraní API. V následujícím diagramu najdete další informace o webovém rozhraní API a webových službách.

Webové rozhraní API a webové služby

Webové služby vs. webové API

Pro usnadnění komunikace mezi klientem a serverem se používají webové rozhraní API i webové služby. Hlavní rozdíl nastává pouze ve způsobu komunikace.

Každý z nich vyžaduje tělo požadavku, které je přijatelné v konkrétním jazyce, jejich rozdíly v poskytování zabezpečeného připojení, rychlost komunikace se serverem a zpětná odpověď klientovi atd.

Rozdíly mezi webovými službami a webovým API jsou uvedeny níže pro vaši potřebu.

Webová služba

• Webové služby obecně používají XML (Extensible Markup Language), což znamená, že jsou bezpečnější.
• Webové služby jsou bezpečnější, protože webové služby i rozhraní API poskytují během přenosu dat SSL (Secure Socket Layer), ale také poskytuje WSS (zabezpečení webových služeb).
• Webová služba je podmnožinou webového rozhraní API. Například, Webové služby jsou založeny pouze na třech stylech použití, tj. SOAP, REST a XML-RPC.
• Webové služby ke svému fungování vždy potřebují síť.
• Webové služby podporují „Jeden kód, různé aplikace“. To znamená, že v různých aplikacích je napsán obecnější kód.

Webové rozhraní API

• Webové rozhraní API obecně používá JSON (JavaScript Object Notation), což znamená, že webové rozhraní API je rychlejší.
• Webové rozhraní API je rychlejší, protože JSON je lehký, na rozdíl od XML.
• Webová rozhraní API jsou nadmnožinou webových služeb. Například, Všechny tři styly webových služeb jsou přítomny také ve webovém rozhraní API, ale kromě toho používá jiné styly, jako je JSON - RPC.
• Webové API k provozu nutně nevyžaduje síť.
• Webové rozhraní API může nebo nemusí podporovat interoperabilitu v závislosti na povaze systému nebo aplikace.

Představujeme testování API ve vaší organizaci

V našem každodenním životě jsme všichni tak zvyklí na interakci s aplikacemi pomocí API, a přesto ani nepřemýšlíme o back-end procesech, které řídí základní funkce.

Například, Zvažte, že procházíte produkty na Amazon.com a vidíte produkt / nabídku, která se vám opravdu líbí a chcete ji sdílet se svou sítí Facebook.

V okamžiku, kdy kliknete na ikonu Facebook v sekci sdílení na stránce a zadáte přihlašovací údaje ke svému účtu Facebook, budete sdílet, komunikujete s API, které bezproblémově spojuje web Amazon s Facebookem.

Posun zaměření na testování API

Než budeme diskutovat o testování API, probereme si důvody, proč si aplikace založené na API v poslední době získaly popularitu.

Existuje několik důvodů, proč organizace přecházejí na produkty a aplikace založené na API. A několik z nich je uvedeno níže pro vaši informaci.

# 1) Aplikace založené na API jsou ve srovnání s tradičními aplikacemi / softwarem více škálovatelné. Rychlost vývoje kódu je rychlejší a stejné API může obsluhovat více požadavků bez jakýchkoli zásadních změn kódu nebo infrastruktury.

#dva) Vývojové týmy nemusí začít kódovat od nuly pokaždé, když začnou pracovat na vývoji funkce nebo aplikace. API nejčastěji znovu používají existující opakovatelné funkce, knihovny, uložené procedury atd., A proto je díky tomuto procesu mohou celkově zvýšit jejich produktivitu.

Například, Pokud jste vývojář pracující na webu elektronického obchodu a chcete přidat Amazon jako zpracovatele plateb - nemusíte psát kód od nuly.

Vše, co musíte udělat, je nastavit integraci mezi vaším webem a Amazon API pomocí integračních klíčů a zavolat Amazon API pro zpracování plateb během pokladny.

# 3) API umožňují snadnou integraci s ostatními systémy jak pro podporované samostatné aplikace, tak pro softwarové produkty založené na API.

Například „Uvažujme, že chcete odeslat zásilku z Toronta do New Yorku. Jdete online, přejděte na dobře známý web o přepravě nebo logistice a zadejte požadované informace.

Po zadání povinných informací, když kliknete na tlačítko Získat sazby - v zadní části se může tento logistický web spojit s několika API a aplikacemi a aplikacemi poskytovatele služeb a poskytovatelů služeb, aby získal dynamické sazby pro kombinaci míst od místa původu.

Úplné spektrum testování API

Testování API se neomezuje pouze na odeslání požadavku na API a samotnou analýzu správnosti odpovědi. Je třeba otestovat jejich výkonnost API při různých zatíženích kvůli zranitelnosti.

Pojďme to probrat podrobně.

i) Funkční testování

Funkční testování může být náročným úkolem kvůli nedostatku rozhraní GUI.

Podívejme se, jak přístup funkčního testování for APIs is different from GUI based application and we will also discuss some examples around it.

na) Nejviditelnějším rozdílem je, že neexistuje žádné grafické uživatelské rozhraní, se kterým by bylo možné komunikovat. Testeři, kteří obvykle provádějí funkční testování založené na grafickém uživatelském rozhraní, je o něco těžší přejít na testování aplikací bez grafického uživatelského rozhraní ve srovnání s někým, kdo je již obeznámen.

Zpočátku, ještě před zahájením testování rozhraní API, budete muset otestovat a ověřit samotný proces ověřování. Metoda ověřování se bude lišit od jednoho API k druhému API a bude zahrnovat nějaký klíč nebo token pro ověřování.

Pokud se nemůžete úspěšně připojit k API, pak další testování nemůže pokračovat. Tento proces lze považovat za srovnatelný s ověřením uživatele ve standardních aplikacích, kde k přihlášení a používání aplikace potřebujete platná pověření.

b) Testování ověření pole nebo ověření vstupních dat je během testování API velmi důležité. Pokud bylo k dispozici skutečné rozhraní založené na formuláři (GUI), bylo možné implementovat ověřování polí v rozhraní front-end nebo back-end, čímž bylo zajištěno, že uživateli nebude povoleno zadávat neplatné hodnoty polí.

Například, Pokud aplikace potřebuje formát data DD / MM / RRRR, můžeme toto ověření použít ve formuláři shromažďujícím informace, abychom zajistili, že aplikace přijímá a zpracovává platné datum.

To však není stejné pro aplikace API. Musíme zajistit, aby API bylo dobře napsané a bylo schopné vynutit všechna tato ověření, rozlišovat mezi platnými a neplatnými údaji a vrátit koncovému uživateli prostřednictvím odpovědi stavový kód a chybovou zprávu o ověření.

C) Testování správnosti odpovědí z API na platnou a neplatnou odpověď je skutečně klíčové. Pokud je jako odpověď z testovacího rozhraní API přijat stavový kód 200 (to znamená v pořádku), ale pokud text odpovědi říká, že došlo k chybě, jedná se o vadu.

Pokud je samotná chybová zpráva navíc nesprávná, může to být pro koncového zákazníka, který se pokouší o integraci s tímto API, velmi zavádějící.

Na níže uvedeném snímku obrazovky uživatel zadal neplatnou hmotnost, což je více než přijatelných 2267 kg. API reaguje chybovým stavovým kódem a chybovou zprávou. Chybová zpráva však nesprávně uvádí jednotky hmotnosti jako libry místo KG. Jedná se o vadu, která může koncového zákazníka zmást.

ii) Testování zátěže a výkonu

Rozhraní API jsou záměrně škálovatelná.

To zase dělá Load a Testování výkonu zásadní, zvláště pokud se od systému, který je navržen, očekává obsluha tisíců požadavků za minutu nebo hodinu, v závislosti na požadavku. Rutinní provádění testů zatížení a výkonu na API může pomoci srovnávat výkon, špičková zatížení a bod zlomu.

Tato data jsou užitečná při plánování rozšíření aplikace. Získání těchto informací pomůže podpořit rozhodnutí a plánování, zejména pokud organizace plánuje přidat více zákazníků, což by znamenalo více příchozích požadavků.

Například , řekněme, že na základě poskytnutých požadavků víme, že navržené API musí obsluhovat nejméně 500 požadavků za hodinu a udržovat průměrnou dobu odezvy méně než 0,01 sekundy.

youtube to mp3 converter vysoce kvalitní stahování zdarma

Na základě našich testů zátěže a výkonu jsme zjistili, že pokud API obdrží méně než 500 požadavků za hodinu, je schopno udržovat SLA pro průměrnou dobu odezvy. Pokud však obdrží dalších 200 požadavků, průměrná doba odezvy se zvýší a bodu zlomu se dosáhne, když příchozí požadavek překročí 1 200 za hodinu.

Obvykle je vidět, že během počátečních fází návrhu je často kladen důraz na funkční aspekty API. Jak čas plyne, produkt začne podporovat více živých klientů, to je, když testování výkonu API a testování zátěže přichází do obrazu rutinnějším způsobem.

(iii) Testování bezpečnosti

Aplikační programovací rozhraní nebo API jsou zranitelná a představují nejjednodušší přístupový bod pro škodlivé hackery, kteří chtějí přístup k datům nebo získat kontrolu nad aplikací.

To může vést jakoukoli společnost k právním potížím, kde z důvodu narušení zabezpečení mohou nechtění lidé nebo organizace získat přístup k datům klienta prostřednictvím ctihodného rozhraní API.

Testování zabezpečení je specializovaná oblast testování a měla by se jí zabývat odborníci. Zdroje pro testování zabezpečení mohou pocházet z organizace nebo z nezávislých konzultantů.

Přečtěte si také = >> Co je Pact Contract Testing

Jak zavést testování API ve vaší organizaci

Proces zavedení testování API v jakékoli organizaci je podobný procesu použitému pro implementaci nebo zavedení jakéhokoli jiného testovacího nástroje a rámce.

Tabulka níže shrnuje hlavní kroky spolu s očekávaným výsledkem každého kroku.

Společné výzvy a způsoby, jak je zmírnit

Pojďme diskutovat o některých běžných výzvách, kterým týmy QA čelí při pokusu o implementaci testovacího rozhraní API v organizaci.

# 1) Výběr správného nástroje

Výběr správného nástroje pro práci je nejčastější výzvou. Na trhu je k dispozici několik testovacích nástrojů API.

Může se zdát velmi lákavé implementovat nejnovější, nejdražší nástroj dostupný na trhu - ale pokud nepřinese požadované výsledky, pak je tento nástroj k ničemu.

Proto si vždy vyberte nástroj, který řeší požadavky, které musíte mít, na základě vašich organizačních potřeb.

Zde je ukázková matice hodnocení nástrojů pro dostupné nástroje API

# 2) Chybějící specifikace testu

Jako testeři potřebujeme znát očekávané výsledky, abychom mohli aplikaci efektivně testovat. To je často výzva, protože abychom poznali očekávané výsledky, musíme mít jasné přesné požadavky - což však není pravda.

Například , zvažte níže uvedené požadavky:

„Přihláška by měla přijímat pouze platné datum odeslání a všechny neplatné požadavky by měly být odmítnuty.“

V těchto požadavcích chybí klíčové podrobnosti a jsou velmi nejednoznačné - jak definujeme platné datum? A co formát? Vracíme nějakou zprávu o odmítnutí koncovému uživateli atd.?

Příklad jasných požadavků:

1) Aplikace by měla přijímat pouze platné datum odeslání.

Datum odeslání se považuje za platné, pokud je

• Ne v minulosti
• Větší nebo rovné dnešnímu datu
• Je v přijatelném formátu: DD / MM / RRRR

2)

Stavový kód odpovědi = 200
Zpráva: OK

3) Datum odeslání, které nesplňuje výše uvedená kritéria, by mělo být považováno za neplatné. Pokud zákazník odešle neplatné datum odeslání, musí odpovědět následující chybovou zprávou:

3.1

Stavový kód odpovědi NENÍ 200
Chyba: Uvedené datum odeslání je neplatné; ujistěte se, že je datum ve formátu DD / MM / RRRR

3.2

Stavový kód odpovědi NENÍ 200
Chyba: Zadané datum odeslání je v minulosti

# 3) Křivka učení

Jak již bylo zmíněno dříve, přístup k testování API se liší od přístupu použitého při testování aplikací založených na GUI.

Pokud najímáte specialisty interně nebo konzultanty pro testování API, pak může být křivka učení přístupu k testování API nebo testovacího nástroje API minimální. Jakákoli křivka učení, v tomto případě, by byla spojena se získáním znalostí o produktu nebo aplikaci.

Pokud je existující člen týmu přiřazen k tomu, aby se naučil testování API, pak v závislosti na vybraném nástroji může být křivka učení střední až vysoká, spolu se změnou přístupu k testování. Křivka učení pro samotný produkt nebo aplikaci může být nízká až střední v závislosti na tom, zda tento tester tuto aplikaci dříve testoval nebo ne.

# 4) Existující sada dovedností

To přímo souvisí s předchozím bodem o křivce učení.

Pokud tester přechází z testování založeného na grafickém uživatelském rozhraní, bude muset tester změnit přístup k testování a podle potřeby se naučit nový nástroj nebo rámec. Např. Pokud API přijímá požadavky ve formátu JSON, pak by se tester musel naučit, co je JSON, aby mohl začít vytvářet testy.

Případová studie

Úkol

Aby bylo možné rozšířit stávající aplikaci, chtěla společnost nabídnout produkt v rozhraní API i standardní aplikaci GUI. Tým QA byl požádán, aby poskytl plán pokrytí testů, aby se ujistil, že jsou připraveni vyhovět testování API nad rámec běžných testů založených na grafickém uživatelském rozhraní.

Výzvy

• Žádný z ostatních softwarových produktů neměl architekturu založenou na API, a proto musí tým vyhovět testování kolem tohoto úkolu, musí tým vytvořit testovací proces API od nuly. To znamená, že nástroje měly být vyhodnoceny, vybrány do užšího výběru, dokončeny a tým musel být pro testy vyškolen.
• Na pořízení a implementaci nástroje nebyl přidělen žádný další rozpočet. To znamená, že tým musel zvolit bezplatný nebo open-source testovací nástroj API a někdo ze stávajícího týmu musel být vyškolen, aby tento úkol zvládl.
• Na pole API a ověření dat nebyly kladeny žádné požadavky. Požadavky byly „měly by fungovat stejně jako odpovídající aplikace GUI“.

Přístup, který tým používá ke zmírnění rizik a řešení problémů

zdarma Windows Registry Cleaner a opravy

• Tým QA spolupracoval s projektovým týmem na identifikaci následujících požadavků:
  • Typ API (REST / SOAP): ODPOČINEK
  • Požadované testy (funkční, zátěž, zabezpečení): Pouze funkční testování
  • Vyžadovány automatické testy (ano / ne): Prozatím volitelné
  • Protokoly o zkoušce (ano / ne): Požadované
• Tým QA provedl hodnocení nástrojů na základě dostupných údajů Nástroje pro testování API na základě nezbytných požadavků. Nástroj Postman API byl dokončen jako nástroj podle jejich výběru, protože byl bezplatný a snadno použitelný také, čímž se minimalizovala křivka učení, a měl potenciál automatizovat testy a přišel s dobrými vestavěnými zprávami.
• Stejný tester, který testoval aplikaci, byl vyškolen pro používání aplikace Postman k vytváření počátečních testů, čímž se eliminují mezery ve znalostech produktu.
• Aby se vypořádal s chybějícími požadavky, vytvořil projektový tým dokumentaci na vysoké úrovni v terénu pomocí nástroje Swagger. To však zanechalo určité mezery, pokud jde o přijatelné datové formáty, a to bylo řešeno projektovým týmem a očekávané formáty byly dohodnuty a zdokumentovány.

Závěr

Aplikace založené na API si v poslední době získaly oblibu. Tyto aplikace jsou více škálovatelné ve srovnání s tradičními aplikacemi / softwarem a umožňují snadnější integraci s ostatními API nebo aplikacemi.

Tento výukový program Testování API podrobně vysvětlil vše o Testování API, Shift Left Testing, Web Services a Web API. Na příkladech jsme také prozkoumali rozdíly mezi webovými službami a webovým API.

V druhé části tutoriálu jsme diskutovali celé spektrum testování API, jak zavést testování API ve vaší organizaci a některé běžné výzvy v tomto procesu spolu s jejich řešeními.

Podívejte se na náš nadcházející výukový program a dozvíte se více o webových službách spolu s příklady !!

DALŠÍ výuka

Doporučené čtení

• Alfa testování a beta testování (kompletní průvodce)
• Funkční testování vs. nefunkční testování
• Výukový program pro testování použitelnosti: Kompletní příručka Začínáme
• Kompletní průvodce pro testování ověřování sestavení (testování BVT)
• Výukový program pro testování DevOps: Jak DevOps ovlivní testování kvality?
• Výukový program pro testování přístupnosti (kompletní průvodce krok za krokem)
• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Co je testování softwaru? 100+ návodů na ruční testování zdarma