Důležitá příručka pro testování Rest API & RestAssured

by

V tomto vyčerpávajícím tutoriálu Rest Assured se naučíme Rest API Testing in depth, API Test Automation along with Rest Assured in modularized approach

Co je RestAssured a jeho použití

Rest Assured je velmi široce používaná technologie open source pro testování automatizace REST API, je založena na knihovně založené na java.

Rest Assured interaguje s Rest API v režimu bezhlavého klienta, můžeme vylepšit stejný požadavek přidáním různých vrstev k vytvoření požadavku a vytvoření požadavku HTTP prostřednictvím různých sloves HTTPS na server.

Integrovaná knihovna Rest Assured poskytuje obrovské metody a nástroje pro provádění ověření odpovědi přijaté ze serveru, jako je stavová zpráva, stavový kód a tělo odpovědi.

Tato kompletní řada Rest Assured Tutorial pro testování automatizace REST API se skládá z následujících témat:

RestAssured - Zkouška testování API pro ostatní
Zajistěte si automatizaci API

Začínáme: Konfigurace restAssured pomocí nástroje Build, tj. Maven / gradle

KROK 1: Pokud pracujete s maven, stačí přidat následující závislost v pom.xml (můžete si vybrat i jakoukoli jinou verzi):

Chcete-li začít s REST Assured, stačí do projektu přidat závislost. 


    io. klidný
    klidný
    4.3.0
    test

Pokud pracujete s gradle, přidejte do build.gradle následující (opět si můžete vybrat jakoukoli jinou verzi):

testCompile group: 'io.rest-assured', name: 'rest-assured', version: '4.3.0'

KROK 2: REST Assured lze snadno integrovat a používat s existujícími jednotkovými testovacími rámci, tj. Testng, JUnit

Tady používáme testNg podle Unit Test Framework.

Po importu knihoven Rest Assured musíme do našich testovacích tříd přidat následující statické importy:

importovat statické io.restassured.RestAssured. *;

importovat statický org.hamcrest.Matchers. *;

POZNÁMKA : Pro tento nadcházející účel učení otestujeme Ergast Developer API, které najdete zde. Toto API poskytuje historická data týkající se závodů Formule 1, jezdců, okruhů atd.

Znalost syntaxe:

Rest Assured podporuje formát BDD (Gherkinova syntaxe) k napsání testovacích skriptů, tj. ve formátu Dáno / Kdy / Potom / A, Předpokládáme, že rozumíte syntaxi BDD / okurky, pokud ne, pak vám doporučujeme věnovat 30 minut času tomu, abyste pochopili, co je BDD (Gherkinova syntaxe) a jak to funguje a je to velmi základní.

T-01: Náš 1. skript, který v podstatě ověřuje počet obvodů v F1 v roce 2017 pomocí tohoto API (http://ergast.com/api/f1/2017/circuits.json)

@Test (description = "Počet okruhů v sezóně 2017 by měl být 20") public void validatingNumberOfCircuits () {given (). When (). Get ("http://ergast.com/api/f1/2017/circuits. JSON "). then (). assertThat (). body ("MRData.CircuitTable.Circuits.circuitId", hasSize (20)); }

Ověření odezvy rest API :

1. Zachytí odpověď JSON na požadavek API.

2. Dotazy na circuitId pomocí výrazu GPath „MRData.CircuitTable.Circuits.circuitId“

3. Ověří, že kolekce prvků circuitId má velikost 20

Zde používáme Hamcrest dohazovači pro různé validace jako např

Existují různé další metody, které jsou užitečné k provedení určité validace.

Dále si můžete přečíst dokumentaci knihovny Hamcrest, kde najdete úplný seznam porovnávacích metod a metod.

Ověření kódu odpovědi:

dané (). when (). get ("http://ergast.com/api/f1/2017/circuits.json"). potom (). assertThat (). statusCode (200);

Ověření typu obsahu

dané (). when (). get ("http://ergast.com/api/f1/2017/circuits.json") .then (). assertThat (). contentType (ContentType.JSON);

Ověření záhlaví „Délka obsahu“

dané (). when (). get ("http://ergast.com/api/f1/2017/circuits.json") .then (). assertThat (). header (" Content-Length ", equalTo (" 4551 "));

Vícenásobné ověření v jednom testu jako (pomocí metod and ()):

@Test (description = "Počet obvodů v sezóně 2017 by měl být 20")
    public void validatingNumberOfCircuits () {
        given (). when (). get ("http://ergast.com/api/f1/2017/circuits.json") .then (). assertThat (). header ("Content-Length", equalTo (" 4551 ")). A (). StatusCode (200);
    }

Ověření prvku / atributu těla odpovědi:

Můžeme použít JsonPath k načtení hodnoty atributů json a uvedení tvrzení pomocí TestNg

@Test (description = "Ověření názvu série, která je f1")
    public void validatingSeriesName () {
        // Převést ResponseBody na řetězec
        Řetězec responseBody = given (). When (). Get ("http://ergast.com/api/f1/2017/circuits.json") .getBody (). AsString ();
        // Vytvořit objekt JsonPath předáním těla odpovědi jako řetězce
        JsonPath resJson = nový JsonPath (responseBody);
        // Načte řadu hodnot atributů pod MRData
        Řetězec název_série = resJson.getString ("MRData.series");
        // Tvrzení TestNg uživatele
        Assert.assertEquals ("f1", název_série);
    }

Podobným způsobem bychom mohli získat hodnotu XML odpovědi pomocí XMLPath. Zde pracujeme s JSON, proto jsme zde použili JSonPath

Rozhraní RESTful API podporují pouze dva typy parametrů:

A. Parametry dotazu: Zde jsou parametry připojeny na konci koncového bodu API a lze je identifikovat pomocí otazníku a tvoří pár klíč-hodnota, jako například 

https://www.google.com/search?q=https://www.wikipedia.org/

Tady ve výše uvedeném API je parametr „q“ a „https://www.wikipedia.org/“ je hodnota tohoto parametru, pokud bychom měli hledat “SOMETHING_ELSE_TEXT„mohli bychom nahradit hodnotu parametru 'q' s "SOMETHING_ELSE_TEXT„místo https://www.wikipedia.org/.

B. Parametry cesty: Jedná se o součást koncového bodu RESTful API. 

např. koncový bod, který jsme použili dříve: http://ergast.com/api/f1/2017/circuits.json, zde „2017“ je hodnota parametru cesty.

Chcete-li získat výsledek za rok 2016 bychom mohli nahradit rok 2017 rokem 2016 pak API poskytne tělo odpovědi pro rok 2016.

Testy využívající parametry cesty pro RestAssured

@Test (description = "Ověření počtu obvodů pomocí parametrů cesty")
    public void testWithPathParams () {
        Řetězec seasonNumber = "2017";
       Řetězec responseBody = given (). PathParam ("season", seasonNumber) .when (). Get ("http://ergast.com/api/f1/{season}/circuits.json") .getBody (). AsString ();
        // Vytvořit objekt JsonPath předáním těla odpovědi jako řetězce
        JsonPath resJson = nový JsonPath (responseBody);
        // Načte řadu hodnot atributů pod MRData
        Řetězec seriesName = resJson.getString ("MRData.series");
        // Tvrzení TestNg uživatele
        Assert.assertEquals ("f1", název_série);
    }

Testy využívající parametry dotazu pro RestAssured

@Test (description = "Ověření vyhledávání Google pomocí parametrů dotazu")
    public void testWithPathParams () {
        Řetězec searchItem = "https://www.wikipedia.org/";
  given (). queryParam ("q", searchItem) .when (). get ("https://www.google.com/search") .then (). assertThat (). statusCode (200);
    }

Parametrizující testy:

Můžeme provést testování řízené daty (tj. Stejný testovací skript bude proveden několikrát s různými sadami vstupních dat a poskytnout různé výstupní údaje) pomocí Rest Assured 

KROK 1: Vytvořeno testovací poskytovatel dat.

Krok 2: Využijte poskytovatele dat v testovacím skriptu.

@DataProvider (name = "SeasonsAndRaceNumbers")
    public Object [] [] testDataFeed () {
        vrátit nový objekt [] [] {
                {"2017", 20},
                {„2016“, 21}
        };
    }
@Test (description = "Number of Circuits validation in different Seasons", dataProvider = "SeasonsAndRaceNumbers") public void circuitNumberValidation (String seasonYear, int raceNumbers) {given ().pathParam ("sezóna", sezónaRok). kdy (). get ("http://ergast.com/api/f1/{sezóna}/circuits.json "). then (). assertThat (). body (" MRData.CircuitTable.Circuits.circuitId ", hasSize (čísla závodů)); }

Práce s parametry s více hodnotami pomocí nástroje RestAssured 

Multi-value parameters are those parameters which has more than one value per parameter name (ie a list of values ​​per paramKey), we can address them like below:

given (). param ("paramKey", "paramValue1", "paramaValue2"). when (). get („URL URL“);

Nebo bychom mohli připravit seznam a předat seznam jako hodnotu parametru paramKey jako:

Seznam paramValue = nový nový ArrayList ();
paramValue.add („paramvalue1“);
paramValue.add („paramvalue2);
given (). param ("paramKey", paramValue) .when (). get („URL URL“);
Práce s cookies pomocí RestAssured 
given (). cookie ("cookieK", "cookieVal"). when (). get ("API URL");

Or 

Můžeme zde také zadat soubor cookie s více hodnotami, jako například:

given (). cookie ("cookieK", "cookieVal1", "cookieVal2"). when (). get („URL URL“);

Práce se záhlavími:

V požadavku můžeme určit pomocí záhlaví / záhlaví jako:

given (). header („headerK1“, „headerValue1“). header („headerK2“, „headerValue2“). when (). get („API URL“);

Práce s contentType:

given (). contentType ("application / json"). when (). get („API URL“);

Or 

given (). contentType (ContentType.JSON) .when (). get ();

Změřte dobu odezvy:

long timeDurationInSeconds = get („URL API“). timeIn (SECONDS);

Ověření Rest API

Zajištěno REST podporuje různá schémata ověřování, např. OAuth, digest, certifikát, formulář a preventivní základní ověřování. Buď můžeme nastavit ověřování pro každý požadavek 

zde je ukázkový požadavek, který používá stejný:

given (). auth (). basic ("uName", "pwd"). when (). get („URL“) ..

Na druhou stranu ověřování a definované v níže uvedeném přístupu pro požadavky HTTP:

RestAssured.authentication = basic ("uName", "pwd");

Základní typy AUTH:

Existují dva typy základního ověřování, „preventivní“ a „základní ověřování tokenu s výzvou“.

Preventivní základní ověřování:

Tím se pošle pověření základního ověřování ještě předtím, než server v určitých situacích poskytne neoprávněnou odpověď spolu se spuštěným požadavkem, čímž se sníží režie navazujícího připojení. Obvykle se jedná o hlavní situace, pokud netestujeme schopnost serverů napadat. 

Např.

given (). auth (). preemptive (). basic ("uName", "pwd"). when (). get ("URL"). then (). statusCode (200);

Napadené základní ověřování

Na druhou stranu „zpochybněné základní ověřování“ REST Assured neposkytne pověření, pokud o to server výslovně nepožádal, tj. Server hodí Neoprávněnou odpověď. Po této neautorizované odpovědi odešle Rest-Assured další požadavek na server, kterým je Auth.

given (). auth (). basic ("uName", "pwd"). when (). get ("URL"). then (). statusCode (200);

Ověřování digestu

Od této chvíle se uvažuje pouze o „zpochybněné autentizaci digestu“. např:

given (). auth (). digest ("uName", "pwd"). when (). get ("URL"). then (). statusCode (200); 

Ověření formuláře

Toho bychom mohli dosáhnout hlavně ve 3 různých přístupech v závislosti na aplikaci / scénářích:

Ověřování formulářů je jedním z velmi populárních přes internet, což znamená, že uživatel zadává své přihlašovací údaje, tj. Uživatelské jméno a heslo prostřednictvím webové stránky a přihlašuje se do systému. To lze řešit pomocí tohoto 

given (). auth (). form ("uName", "pWd").
when (). get ("URL");
then (). statusCode (200);

I když to nemusí fungovat, protože je to optimální, může to projít nebo selhat v závislosti na složitosti webové stránky. Lepší možností je poskytnout tyto podrobnosti při nastavování ověřování formuláře v níže uvedeném přístupu:

given (). auth (). form ("uName", "pwd", new FormAuthConfig ("/ 'zde uveďte název akce formuláře, který je součástí html kódu stránky nder tag formuláře'", "uName", "pwd ")). when (). get (" URL "). then (). statusCode (200);

V tomto přístupu interně zajištěný REST nebude vyžadovat spuštění dalšího požadavku a analýzu prostřednictvím webové stránky. 

Pokud v případě, že používáte výchozí Spring Security, pak je spuštěn předdefinovaný FormAuthConfig.

given (). auth (). form ("uName", "Pwd", FormAuthConfig.springSecurity ()). when (). get ("URL"). then (). statusCode (200);

POZNÁMKA: Pokud chceme poslat další vstupní data spolu s ověřením formuláře, mohli bychom napsat níže:

given (). auth (). form ("uName", "pwd", formAuthConfig (). withAdditionalFields ("firstInputField", "secondInputField"). ..

CSRF:

CSRF je zkratka pro padělání požadavků napříč weby.

V dnešní době je velmi běžné, že server poskytuje token CSRF s odpovědí, aby se vyhnul útokům CSRF na zabezpečení. REST Assured to podporuje pomocí automatického analyzátoru a poskytnutím tokenu CSRF. 

K dosažení tohoto REST Assured je třeba podat další požadavek a analyzovat (několik pozic) webové stránky.

Podporu CSRF můžeme povolit napsáním níže uvedeného kódu:

given (). auth (). form ("uName", "pwd", formAuthConfig (). withAutoDetectionOfCsrf ()). when (). get ("URL"). then (). statusCode (200);

Kromě toho, abychom pomohli REST Assured a zajistili bezchybnou a robustní analýzu, můžeme zadat název pole CSRF (zde předpokládáme, že používáme výchozí hodnoty Spring Security a můžeme použít předdefinované springSecurity FormAuthConfig):

given (). auth (). form ("uName", "pwd", springSecurity (). withCsrfFieldName ("_ csrf")). when (). get ("URL"). then (). statusCode (200);

Ve výchozím nastavení je hodnota CSRF předávána jako parametr formuláře s požadavkem, ale můžeme ji nakonfigurovat tak, aby ji odeslala jako záhlaví, pokud je to požadováno níže:

given (). auth (). form ("uName", "pwd", springSecurity (). withCsrfFieldName ("_ csrf"). sendCsrfTokenAsHeader ()). when (). get ("URL"). then (). statusCode (200);

OAuth 1:

OAuth 1 vyžaduje, aby byl v cestě třídy Scribe. K použití ověřování oAuth 1 můžeme:

dané (). auth (). oauth (..). when (). ..

OAuth 2:

dané (). auth (). oauth2 (accessToken) .when (). ..

Ve výše uvedeném přístupu bude OAuth2 accessToken považován v záhlaví. Abychom byli jasnější, můžeme také udělat:

dané (). auth (). preemptive (). oauth2 (accessToken) .when (). ..

Předání souboru, bajtového pole, vstupního proudu nebo textu v požadavku:

Při odesílání velkého množství dat na server je obecně běžný přístup k použití techniky dat s více částmi. Rest Assured poskytují metody zvané multiPart, které nám umožňují určit soubor, bajtové pole, vstupní proud nebo text, který se má nahrát. 

given (). multiPart (new File ("/ File_Path")). when (). post ("/ upload");

Vytvoření požadavku POST se zajištěním odpočinku

S požadavky POST a PUT zasíláme Data na Server a jeho v podstatě vytváření zdrojů / aktualizaci zdrojů, můžete to považovat za operaci zápisu nebo aktualizace.

Data, která se odesílají na server v požadavku POST, se odesílají v těle volání požadavku HTTP / API. 

Typ odesílaného obsahu nebo dat může mít různý formát v závislosti na API, tj. XML, JSON nebo jiný formát je definován záhlaví Content-Type. 

Pokud se tělo POST skládá z dat JSON, pak záhlaví Content-Type bude application / json. Podobně pro požadavek POST skládající se z XML pak bude záhlaví Content-Type typu application / xml.

Tady je níže uvedený fragment kódu:

given (). contentType ("application / json"). param ("pk", "pv"). when (). body ("JsonPAyloadString"). post ("url"). then (). assertThat (). statusCode (200);

POZNÁMKA: Existuje několik způsobů, jak můžeme předat tělo užitečného zatížení / požadavku uvnitř metody „body“, jako je String (jak je ukázáno v úryvku výše), JsonObject, jako soubor atd. Atd.,

Požadavek PUT se zajištěným odpočinkem:

given (). contentType ("application / json"). param ("pk", "pv"). when (). body ("JsonPAyloadString"). put ("url"). then (). assertThat (). statusCode (200);

Smazat požadavek s Rest-Assured:

given (). contentType ("application / json"). param ("pk", "pv"). when (). delete ("url"). then (). assertThat (). statusCode (200);

A tak můžeme vytvořit různé volání Rest API pro různá slovesa API (GET / POST / PUT / DELETE atd.)

Serializace a deserializace v Javě:

Serializace je v podstatě zpracování nebo převod stavu objektu na bajtový proud. Na druhou stranu deserializace v Javě zpracovává nebo převádí bajtový proud na skutečný objekt Java v paměti. Tento mechanismus se používá v perzistenci Object.

Níže je blokové schéma pro totéž 

1ESLuGPTk5gUs9eA5 OXkbw KyHeRnO9TdX bg OEo3 ZD7BJ9HqLY HcOaf9saeK137JSzmDj7 TY2WmrlVogzLzkgmN1gvLvyaF6cdGb6psTcv0HVH98J45L4b1a0c3ucUvJ6p

Výhody serializace

A. Uložení / přetrvávání stavu objektu.

B. Přenést objekt přes síť.

Dosažení serializace s JAVA

Abychom dosáhli serializovatelného objektu Java, musíme implementovat rozhraní java.io.Serializable.

Třída ObjectOutputStream, která obsahuje metodu writeObject () zodpovědnou za serializaci Object.

Třída ObjectInputStream také obsahuje jinou metodu nazvanou readObject (), která je zodpovědná za deserializaci objektu.

třídy, které implementují rozhraní java.io.Serializable, lze objekt pouze serializovat.

Serializable je pouze značkovací rozhraní a stejně jako ostatní tržní rozhraní nemá s ním asociovaný žádný datový člen ani metodu. Který se používá k „označení“ tříd Java, aby objekty těchto tříd získaly určité schopnosti. Stejně jako několik dalších rozhraní značek: - Cloneable a Remote atd.

POZNÁMKA:

1. Pokud nadřazená třída implementovala Serializovatelné rozhraní, potom podřízená třída není povinna implementovat totéž, ale naopak není použitelná.

2. S procesem serializace jsou ukládány pouze nestatické datové členy.

3. Statické datové členy a také přechodné datové členy nejsou ukládány Serializací. Pokud tedy nepotřebujeme ukládat hodnotu nestatického datového člena, můžeme ji učinit přechodnou.

4. Konstruktor se nikdy nevolá, když je objekt deserializován.

KROK 1: Prvním krokem je v zásadě vytvoření třídy, která implementuje rozhraní Serializable:

import java.io.Serializable;
public class Dummy implementuje Serializable {
    soukromé int i;
    soukromá data řetězce;
    public Dummy (int i, String data)
    {
        toto.i = i;
        this.data = data;
    }
}

Krok 2: Vytvořte třídu pro její serializaci:

import java.io.FileNotFoundException;
importovat java.io.FileOutputStream;
import java.io.IOException;
importovat java.io.ObjectOutputStream;
public class Serialize {
    public static void Serialization (Object classObject, String fileName) {
        Snaž se {
            FileOutputStream fileStream = nový FileOutputStream (název souboru);
            ObjectOutputStream objectStream = nový ObjectOutputStream (fileStream);
            objectStream.writeObject (classObject);
            objectStream.close ();
            fileStream.close ();
        } chytit (FileNotFoundException e) {
            // TODO Automaticky generovaný blok zachycení
            e.printStackTrace ();
        } chytit (IOException e) {
            // TODO Automaticky generovaný blok zachycení
            e.printStackTrace ();
        }
    }
    public static void main (String [] args) {
        Dummy dummyObj = nový Dummy (10, "Lambda-geeks");
        Serializace (dummyObj, "DummSerialized");
    }
}

KROK 3: Jakmile je Step2 úspěšně dokončen, uvidíte soubor vytvořený s některými daty, která jsou v zásadě serializovanými daty členů Object.

  Deserializace pomocí Java:

Tady je fragment kódu níže:

 veřejný statický objekt DeSerialize (řetězec název_souboru)
    {
        Snaž se {
            FileInputStream fileStream = nový FileInputStream (nový soubor (název souboru));
            ObjectInputStream objectStream = nový ObjectInputStream (fileStream);
            Object deserializeObject = objectStream.readObject ();
            objectStream.close ();
            fileStream.close ();
            návrat deserializeObject;
        } chytit (FileNotFoundException e) {
            e.printStackTrace ();
        } chytit (IOException e) {
            e.printStackTrace ();
        } catch (ClassNotFoundException e) {
            e.printStackTrace ();
        }
        vrátit null;
    }

Kód ovladače vypadá takto:

 public static void main (String [] args) {
      / * Dummy dummyObj = nový Dummy (10, "Lambda-geeks");
        Serializace (dummyObj, "DummSerialized");
        System.out.println ("------------------------------------------- ------------------------------- ");
      */
        Dummy deSerializedRect = (Dummy) DeSerialize ("DummSerialized");
        System.out.println ("Data ze serializovaného objektu" + deSerializedRect.print ());
        System.out.println ("------------------------------------------- ------------------------------- ");
    }

JSONPATH Další syntaxe / dotaz:

Pojďme předpokládat JSON, jak je uvedeno níže:

{
  "OrganizationDetails": "Fiktivní údaje o organizaci",
  "Region": "Asia",
  „Emp-Details“: [
    {
      "Org": "lambda-Geeks",
      "Informace": {
        "Ph": 1234567890,
        "Přidat": "XYZ",
        „Věk“: 45
      }
    },
    {
      "Org": "lambda-Geeks-2",
      "Informace": {
        "Ph": 2134561230,
        "Přidat": "ABC",
        „Věk“: 35
      }
    }
  ]
}

ve výše uvedeném JSON se OrganizationDetails & Region nazývají jako Leaf node reason, protože nemají žádné další podřízené uzly / prvky, ale jako na druhé straně Emp-Details s podřízeným uzlem, proto se neuvádí jako Leaf node.

Tady, pokud se pokusíme získat hodnotu OrganizationDetails, musíme použít:

$ .OrganizationDetails 
Výsledkem bude:
 [
  „Fiktivní údaje o organizaci“
]

Stejně jako Wise, abychom získali data pro region, musíme napsat:

$. Region 

Pokud chceme zjistit hodnotu Age pro 1. zaměstnance, mohli bychom napsat:

$ .Emp-Podrobnosti [0] .Information.Age
Výsledkem bude:
[
  45
]

Pro věk druhého zaměstnance bychom mohli psát jako

$ .Emp-Podrobnosti [1] .Information.Age
Výsledkem bude: [35]

Tímto způsobem můžeme zjistit výraz / dotaz JsonPath pro načtení dat pro příslušná pole v JSON.