Vlastnosti testování webově orientovaných aplikací. Funkční testování moderních webových aplikací. Vlastnosti testování webových aplikací se zvýšenou složitostí

Testování webových aplikací

V dnešním neustále se měnícím a konkurenčním světě obchodních scénářů by organizace měly vždy otestovat své webové aplikace před spuštěním svých webových stránek.

Díky testování webových aplikací si každá organizace může být jistá, že webová aplikace bude fungovat perfektně a bude snadno přijata koncovými uživateli. Techniky testování webových aplikací také testují kompatibilitu webové aplikace s prohlížečem. Provádí se zátěžové testování, testování škálovatelnosti, zátěžové testování a testování rozlišení.

Typy testování webových aplikací

Zde jsou některé základní typy testování webových aplikací:

1. Funkční testování. Toto testování se používá ke kontrole všech odkazů na webové stránky; Testování formulářů, cookies a databázových připojení.

2.Testování použitelnosti: toto testování kontroluje navigaci a použitelnost webových stránek. Toto testování zajišťuje, aby byl obsah koncovým uživatelem vnímán správně. Kontroluje také, zda fungují správně textové odkazy vazby, zda soubory obsahují soubory nápovědy nezbytné informace a fungují všechny odkazy?

3. Testování rozhraní. Kontroluje, zda rozhraní webového serveru a aplikačního serveru, aplikačního serveru a databázového serveru správně komunikují. Tento test zajišťuje, že uživatelé neuvidí žádné chybové zprávy.

4. Testování kompatibilityb. Testování kompatibility je velmi důležité, protože kontroluje kompatibilitu prohlížeče, kompatibilitu operačního systému, prohlížeč a možnosti tisku.

5. Testování výkonu. Testování výkonu zahrnuje testování zatížení webu a zátěžové testování sítě. Testování zatížení webu testuje, zda má mnoho uživatelů přístup na stejnou stránku současně a zda webová stránka zvládne velké zatížení na konkrétní stránce. Zátěžové testování webu se provádí na webu, aby se zjistilo, jak bude web reagovat a zotavit se v době stresu.

6. Bezpečnostní testování. Kontroluje bezpečnost webových aplikací. Z bezpečnostních důvodů by se vnitřní stránky neměly otevírat, pokud nejste přihlášeni na web. Ostatní statistiky by se neměly zobrazovat, i když je uživatel přihlášen. Soubory by měly být přístupné pouze tehdy, když se přihlásíte ke svému účtu, a bez toho k nim nelze přistupovat. Testovat by se měla také CAPTCHA pro automatizaci přihlašování. SSL musí být testován na bezpečnostní opatření.

Po dokončení testování všech webových aplikací je třeba provést testování webových aplikací a webových stránek v reálném čase. Poté načtěte web a proveďte úplný test.

Webové aplikace mohou být vystaveny velkému a různorodému publiku, ale existuje riziko, že budou vystaveny široké škále možných mezer. Úspěšné výsledky testu software:

Aplikaci lze používat mnoha způsoby (Entry-Exit)

Aplikaci mohou používat lidé různého původu a technických dovedností. Kromě toho mohou nastat problémy mezi platformami a rozdíly v prohlížečích, typech sítí nebo rychlostí sítě, rozdíly v internetových aplikacích atd. mohou vést k problémům souvisejícím se softwarem.

I ve stejném prohlížeči mohou aplikace běžet odlišně v závislosti na místních nuancích, jako je rozlišení obrazovky/hardware/ softwarovou konfiguraci systémy

Aplikace mohou vyžadovat testování kompatibility a použitelnosti

Závěrem lze říci, že celý proces testování webových aplikací zahrnuje několik skutečně důležitých a kritických kroků, které je třeba pečlivě dodržovat, aby bylo možné koneční uživatelé byli s výsledkem spokojeni.

A náš tým vám pomůže rozvíjet dovednosti úspěšného testera – zavolejte a přihlaste se právě teď!

, informační šum , logické chyby , zpřístupnění informací , SQL Injection , "stres" , zátěžové testování , testování výkonu , objemové testování , objemová stabilita , vizuální test , sondování , sniffing , firebug , RDP , generování zátěže , tester , manažer kvality , webové testování -servery , Transakční modelování , Metoda "Analýza dat na straně klienta" Metoda "Analýza dat na straně klienta" Metoda "Analýza dat na straně klienta" , Metoda analýzy síťového provozu , Kontrola HTML kódu , profiler , graf hovorů , graf hovorů , pokrytí kódu , syntaxe zvýraznění, Prohlížeč, vývojové nástroje, posun prvku, hierarchický seznam, bod přerušení, sestavení, Internet Explorer Developer Tools, funkční dekompozice, data-driven, runtime, cache, validita, DHTML, css

Prezentaci k této přednášce si můžete stáhnout.

19.1. Testování webových aplikací

19.1.1. Úvod

Výpočetní a komunikační systémy se používají stále častěji a každým dnem se stále více začleňují do našeho každodenního života. Firmy i jednotliví uživatelé jsou při své práci stále více závislí na webových aplikacích. Webové aplikace propojují různá oddělení v rámci firem, různé společnosti i běžné uživatele. Webové aplikace jsou velmi dynamické a jejich funkčnost neustále roste. Streamování médií a požadavků generovaných přenosnými a vestavěnými zařízeními se neustále zvyšuje. V důsledku toho se zvyšuje složitost systémů tohoto druhu. Je zřejmé, že porozumění, analýza, vývoj a správa takových systémů vyžaduje kvantitativní metody a modely, které pomáhají vyhodnocovat různé provozní scénáře a zkoumat strukturu a stav velkých systémů. Existují trendy směřující k neustálému nárůstu poptávky po webových službách. Problémy s výkonem tedy budou v budoucnu vyvstávat a nakonec se stanou převládajícími, protože se plánují a zavádějí nové webové služby a přibývá uživatelů internetu. Webové aplikace jsou stále běžnější a složitější, a tak hrají hlavní roli ve většině online projektů. Jako u všech systémů založených na interakci mezi klientem a serverem, zranitelnosti webových aplikací obvykle vznikají v důsledku nesprávného zpracování klientských požadavků a/nebo nedostatečného ověření vstupních informací vývojářem.

V první části této přednášky se podíváme na problémy specifické pro testování a ladění webových aplikací.

Budou zváženy principy následujících přístupů k testování webových aplikací [, ]:

• funkční testování ;
• testování uživatelského rozhraní ;
• testování použitelnosti ;
• zatížení a zátěžové testování ;
• kontrola odkazů a HTML kódu;
• bezpečnostní testování.

K dispozici bude také přehled nástrojů. automatizace testování Webové aplikace.

S obecnými otázkami o testování a ověřování informační systémy Doporučujeme, abyste se seznámili s kurzem Internetová univerzita Informační technologie"Ověření softwaru".

Druhá část přednášky se bude zabývat přístupy a nástroje ladění CSS a ladění a profilování JavaScriptu.

19.1.2. Přístupy k funkčnímu testování webových aplikací

Funkční testování(funkční testování) je proces ověření, že fungování produktu odpovídá jeho původním specifikacím. Typickým příkladem je kontrola, zda program pro výpočet splátek bankovního úvěru vytváří správné výpočty pro jakoukoli zadanou částku úvěru a dobu splácení. Obvykle se takové kontroly provádějí ručně, někdy se na nich podílejí koncoví uživatelé jako beta testeři. Softwarové systémy jsou však stále složitější a různé kombinace vstupní parametry a podporované operační systémy se často počítají na desítky a stovky.

Uveďme si některé z metod funkční testování webové aplikace [ , ]:

1. Nahrávání a přehrávání– na základě možnosti finančních prostředků automatizace testování automaticky vygenerovat kód.
2. Funkční rozklad– je založen na rozdělení všech komponent frameworku podle funkčnosti na obchodní funkce (implementace/kontrola obchodní funkčnosti aplikace), uživatelsky definované funkce (pomocné funkce, které jsou rovněž vázány na testovanou aplikaci nebo na konkrétní projekt), utility (funkce obecných schůzek nejsou vázány na konkrétní aplikaci, technologie, projekt).
3. Na základě dat– je založen na skutečnosti, že zdroj dat je spojen s nějakým testem nebo skupinou testů a tento test nebo sada testů se cyklicky provádí pro každý záznam z tohoto zdroje dat. Může být dobře použit v kombinaci s jinými přístupy.
4. Na základě klíčových slov– je vlastně enginem pro zpracování příkazů, které jsou mu zasílány, a samotné instrukce jsou odesílány do externího zdroje dat.
5. Objektově řízené– je založeno na tom, že hlavní průběžné části frameworku jsou implementovány ve formě objektů, což umožňuje sestavovat testy cihlu po cihle.
6. Na základě modelu– je založen na tom, že testovaná aplikace (nebo její části) je popsána formou nějakého behaviorálního modelu.

Nejběžnější přístup se nazývá Capture & Playback (jiné názvy: Record & Playback, Capture & Replay). Podstatou tohoto přístupu je, že testovací scénáře jsou vytvářeny na základě zkušeností uživatele s testovanou aplikací. Nástroj zachycuje a zaznamenává akce uživatele, výsledek každé akce je také zapamatován a slouží jako standard pro následné kontroly. Navíc ve většině nástrojů, které tento přístup implementují, nejsou dopady (například stisknutí tlačítka myši) spojeny se souřadnicemi aktuální polohy myši, ale s objekty rozhraní HTML (tlačítka, vstupní pole atd.), které jsou ovlivněny, a jejich atributy. Při testování nástroj automaticky přehrává dříve zaznamenané akce a porovnává jejich výsledky s referenčními, přesnost srovnání lze upravit. Můžete také přidat další kontroly - nastavit podmínky na vlastnosti objektů (barva, umístění, velikost atd.) nebo na funkčnost aplikace (obsah zprávy atd.).

Hlavní výhodou tohoto přístupu je jeho snadné učení. Vytvářejte testy pomocí nástrojů, které implementují tento přístup, zvládnou to i uživatelé bez znalosti programování.

Tento přístup má však řadu významných nevýhod. Pro vývoj testů není poskytována žádná automatizace; ve skutečnosti nástroj zaznamenává proces ruční testování. Pokud je při záznamu testu zjištěna chyba, ve většině případů není možné vytvořit test pro pozdější použití, dokud nebude chyba opravena (nástroj si musí správný výsledek pro ověření zapamatovat). Když se testovaná aplikace změní, je obtížné udržovat testovací sadu aktuální, protože testy pro změněné části aplikace musí být napsány znovu.

19.1.3. Testování uživatelského rozhraní

Část softwarový systém, zajištění provozu uživatelského rozhraní je jedním z netriviálních objektů pro ověřování. Netriviálnost spočívá v dvojím vnímání pojmu „uživatelské rozhraní“.

Na jedné straně je uživatelské rozhraní součástí softwarového systému. V souladu s tím jsou pro uživatelské rozhraní napsány funkční a nízkoúrovňové požadavky, které jsou následně použity k vytvoření testovacích požadavků a testovacích plánů. V tomto případě zpravidla požadavky určují reakci systému na každý uživatelský vstup (pomocí klávesnice, myši nebo jiného vstupního zařízení) a typ informační zprávy systémy zobrazené na obrazovce, tiskovém zařízení nebo jiném výstupním zařízení. Při ověřování takových požadavků mluvíme o o ověření funkční úplnost uživatelské rozhraní - kolik implementované funkce splňuje požadavky, zda se informace na obrazovce zobrazují správně.

Na druhou stranu uživatelské rozhraní je „tváří“ systému a na jeho promyšlenosti závisí efektivita práce uživatele se systémem. Faktory ovlivňující efektivitu práce jsou méně přístupné formalizaci v podobě specifických požadavků na jednotlivé prvky, je však třeba zohlednit formou obecných doporučení a zásad pro konstrukci uživatelského rozhraní softwarového systému. Testování rozhraní na efektivitu interakce člověk-stroj se nazývá ověřování použitelnosti (v ruskojazyčné literatuře se slovo „praktičnost“ často používá jako překlad termínu použitelnost).

Funkční testování uživatelské rozhraní se skládá z pěti fází:

• analýza požadavků na uživatelské rozhraní;
• vývoj testovacích požadavků a testovacích plánů pro testování uživatelského rozhraní;
• provádění testovacích případů a shromažďování informací o provádění testů;
• určení úplnosti pokrytí uživatelského rozhraní požadavky.
• sestavení problémových hlášení v případě nesouladu mezi chováním systému a požadavky nebo při absenci požadavků na jednotlivé prvky rozhraní.

Všechny tyto fáze jsou naprosto stejné jako v případě testování jakékoli jiné součásti softwarového systému. Rozdíly spočívají ve výkladu některých pojmů aplikovaných na uživatelské rozhraní a ve vlastnostech automatizovaného sběru informací v každé fázi.

Testovací plány pro testování uživatelského rozhraní jsou tedy zpravidla scénáře, které popisují akce uživatele při práci se systémem. Skripty mohou být napsány buď v přirozeném jazyce, nebo ve formálním jazyce některého systému automatizace uživatelského rozhraní. Testy provádí buď operátor v manuální režim nebo systém, který emuluje chování operátora.

Při shromažďování informací o provádění testovacích případů se zpravidla používají technologie k analýze formulářů a jejich prvků zobrazených na obrazovce (v případě grafického rozhraní) nebo textu zobrazeného na obrazovce (v případě text jedna), místo kontroly hodnot určitých proměnných nastavených softwarovým systémem.

Úplnost pokrytí uživatelského rozhraní znamená, že v důsledku provedení všech testovacích případů byl každý prvek rozhraní použit alespoň jednou ve všech dostupných režimech.

Zprávy o problémech uživatelského rozhraní mohou obsahovat jak popisy nesrovnalostí mezi požadavky a skutečným chováním systému, tak popisy problémů v požadavcích na uživatelské rozhraní. Hlavním zdrojem problémů v těchto požadavcích je jejich nedostatečná testovatelnost způsobená vágními formulacemi a nedostatkem specifičnosti.

Testování uživatelského rozhraní může být provedeno různé metody– jak ručně za přímé účasti operátora, tak pomocí různých nástrojů, které automatizují provádění testovacích případů. Podívejme se na tyto metody podrobněji.

19.1.3.1. Ruční testování

Ruční testování uživatelské rozhraní provádí operátor tester, který se ve své práci řídí popisem testovacích příkladů ve formě sady scénářů. Každý scénář obsahuje seznam posloupnosti akcí, které musí operátor provést, a popis reakcí systému, které jsou důležité pro analýzu výsledků testů, promítnutých do uživatelského rozhraní. Typická forma pro nahrání scénáře k dirigování ruční testování– tabulka, ve které jeden sloupec popisuje akce (kroky scénáře), druhý popisuje očekávanou reakci systému a třetí má za úkol zaznamenat, zda se očekávaná reakce systému shodovala se skutečnou a uvádí nesrovnalosti .

• poziční, kdy se k prvku přistupuje zadáním jeho absolutních (vzhledem k obrazovce) nebo relativních (vzhledem k oknu) souřadnic a velikostí;
• podle identifikátoru, ve kterém se přístup k prvku provádí získáním prvku rozhraní pomocí jeho unikátní identifikátor uvnitř okna.

Při provádění změn uživatelského rozhraní při použití první metody v důsledku regresní testování bude identifikováno velké množství neúspěšných testů – pouhá změna umístění jednoho klíčového prvku rozhraní způsobí, že všechny skripty začnou fungovat nesprávně. Podle toho s touto metodou automatizace testování je nutné změnit významnou část skriptů v testovacím systému při každé změně rozhraní systému. Tato metoda automatizace testování Vhodné pro systémy se zavedeným a zřídka měněným rozhraním.

Druhá metoda automatizace testování je odolnější vůči změnám v umístění prvků rozhraní, ale i zde mohou být vyžadovány změny zkušebních příkladů, pokud se změní logika činnosti prvků rozhraní. Předpokládejme například, že v první verzi systému se po kliknutí na tlačítko „Přenos dat“ okamžitě spustil přenos dat a zobrazilo se okno s indikátorem průběhu. Scénář testovacího případu v tomto případě zahrnuje simulaci kliknutí na tlačítko a přístup k ukazateli průběhu, abyste získali procentuální hodnotu průběhu.

Moderní webové aplikace často obsahují mnoho pohyblivých částí a závislostí třetích stran. V procesu refaktoringu a přidávání/změny funkčnosti v takové aplikaci se mohou stávající skripty případu použití rozbít a nestabilní práce v určitých prohlížečích.

Pro včasnou detekci takových situací a provádění průběžné integrace je nutné funkční testování webové aplikace. Článek se bude zabývat dvěma bezplatný open-sourceřešení:

Zvažovaná řešení poskytují zdánlivě podobný rozsah schopností.

• Automatizované funkční testování se sekvenčním a paralelním prováděním testů a jejich seskupování, integrace s Gulp a Mocha.
• Podporuje většinu stolních a mobilní prohlížeče; provádění interakce se skutečným DOM API (webová aplikace se otevře v neskrytém okně prohlížeče v běžné záložce - test je co nejblíže k životu).
• Široká podpora pro selektory prvků stránky: document.querySelector, selektory CSS a dokonce XPath; kombinace těchto možností umožňuje zachovat funkčnost funkční test při provádění změn v označení.
• Automaticky čeká, až bude model DOM prohlížeče připraven, synchronně odesílá příkazy vizuální interakce (klepání na tlačítka, zadávání textových polí); pohodlné nástroječekat na klientský kód JS a aktivitu sítě AJAX.
• Podpora iframe - výběrem aktuálního kontextu DOMWindow - okno pro test a provádění příkazů v něm s možností kdykoli přepnout.
• Možnosti rozšíření – obě řešení poskytují možnosti přidat podporu pro vlastní prohlížeče a rozšířit vlastní funkcionalitu včetně přidávání nových příkazů.

Příklad funkčního testu

Příkladem pro testování bude webová aplikace jako TodoMVC se serverem na node.js a klientskou SPA stránkou na React+Redux. Aby se testovací podmínky přiblížily skutečným, byla do všech akcí Redux přidána náhodná zpoždění, která emulují vytváření sítí s backendem (to se bere jako základ).

V následujícím textu se bude předpokládat, že testovací webová aplikace běží na adrese http://localhost:4000/. Funkční test bude jednoduchý a bude zahrnovat přidání prvku úkolu, úpravu jeho obsahu, označení jako dokončený/nedokončený a jeho smazání.

Jazyk pro psaní testů v obou frameworkech je JS (ES2016 a ES5 pro TestCafe a Nightwatch, v tomto pořadí), ale je ideální pro webové aplikace napsané v jakémkoli jazyce. Pokud jste se v JS dlouho nevyvíjeli, pak musíte vzít v úvahu, že moderní edice zašly velmi daleko od starého ES3 a obsahují pohodlné nástroje pro psaní kódu, objektově orientované a Funkcionální programování a mnohem víc.

Instalace TestCafe se provádí pouze jedním příkazem: npm install -g testcafe . Po stažení a instalaci potřebných závislostí se test provede příkazem testcafe / v příslušném adresáři.

Zdrojový kód funkčního testu, který kontroluje scénář použití popsaný výše, by mohl vypadat takto:

importovat ( očekávat ) z "chai"; import ( Selector ) z "testcafe"; const MAX_TIME_AJAX_WAIT = 2500; // 2,5 sekundy standardně const querySelector = Selector((val) => document.querySelector(val), ( timeout: MAX_TIME_AJAX_WAIT )); const querySelectorCondition = Selector((val, checkFunc) => ( const foundElems = document.querySelectorAll(val); if(!foundElems) return null; for(let i=0; i< foundElems.length; i++) { if(checkFunc(foundElems[i])) return foundElems[i]; } return null; }, { timeout: MAX_TIME_AJAX_WAIT }); fixture `Example page` .page `http://localhost:4000/`; test("Emulate user actions and perform a verification", async t =>( wait t.setNativeDialogHandler(() => true); const inputNewTodo = wait querySelector("header.header input.new-todo"); wait t.typeText(inputNewTodo, "Nový prvek TODO\r\n"); const addedTodoElement = wait querySelectorCondition("section.main label", (elm) => (elm.innerText === "Nový prvek TODO") wait t.doubleClick(addedTodoElement = waitSelectorCondition("section.main). ) input", (elm) => (elm.value === "New TODO element")); await t.typeText(addedTodoEditInput, " changed\r\n"); const addedTodoCheckboxAC = await querySelectorCondition("section.main input:not()", (elm) => (elm.nextSibling.innerText === "New TODO element changed")); await t.click(addedTodoCheckboxAC); const addedTodoCheckboxBC = await querySelectorCondition("section.main input", (elm) => (elm.nextSibling.innerText === "New TODO element changed")); await t.click(addedTodoCheckboxBC); const addedTodoDelBtn = await querySelectorCondition("button.destroy", (elm) => (elm.previousSibling.innerText === "New TODO element changed")); await t.click(addedTodoDelBtn); }); !}

Adresa testované webové stránky se zjišťuje v části příslušenství, následují funkční testy, po jejichž dokončení se webová stránka automaticky obnoví do původního stavu. Pro hledání prvků DOM na stránce se používají selektory specifické pro testcafe, které se používají jako obal pro funkci, která bude dotazovat model DOM, případně pomocí argumentů.

V tomto příkladu první selektor obtéká document.querySelector a druhý selektor obtéká document.querySelectorAll funkcí zpětného volání, která vám pomůže vybrat požadovaný prvek ze seznamu. Obal Selector zde akceptuje možnosti, zejména se nastavuje maximální doba, po kterou bude testcafe čekat, až se prvek s danými vlastnostmi objeví v modelu DOM.

Samotný funkční test je sada asynchronních volání selektorů, mezi kterými se provádějí akce pomocí testovacího řadiče vytvořeného proměnnou t. Účel většiny jeho metod je zřejmý z názvů (click, typeText atd.) a t.setNativeDialogHandler se používá k zabránění generování oken podobných upozorněním, která mohou test zmrazit - což je velmi pohodlné.

Instalace Nightwatch také začíná jednoduchým příkazem npm install -g nightwatch , ke spuštění funkčních testů však budete potřebovat také Selenuim-server (můžete si jej stáhnout, na vašem počítači musí být nainstalován Java SE runtime) a webové ovladače pro každý z prohlížečů ve kterém bude test probíhat.

Chcete-li spustit testy, musíte nejprve vytvořit konfigurační soubor nightwatch.json, který popisuje umístění testů, cesty a nastavení pro selenium-server a webdrivers, a poté použít jednoduchý příkaz nightwatch v aktuálním adresáři.
Pokud použijete Web společnosti Microsoft Driver (Edge), pak nightwatch.json může vypadat nějak takto:

( "src_folders" : ["nightwatch-tests"], "output_folder" : "reports", "custom_commands_path" : "", "custom_assertions_path" : "", "page_objects_path" : "", "globals_path" : "", " selen" : ( "start_process" : true, "server_path" : "nightwatch-bin/selenium-server-standalone-3.0.1.jar", "log_path" : "", "port" : 4444, "cli_args" : ( "webdriver.edge.driver" : "nightwatch-bin/MicrosoftWebDriver.exe" ) ), "test_settings" : ( "default" : ( "selenium_port" : 4444, "selenium_host" : "localhost", "desiredCapabilities": ( " browserName": "MicrosoftEdge", "acceptSslCerts": true ) ) ) )

Zdrojový kód funkčního testu, který testuje scénář použití podobný tomu, který je popsán výše, může vypadat takto:

module.exports = ( "Demo test" : funkce (klient) ( client.url("http://localhost:4000/") .waitForElementVisible("body", 1000) // Může používat selektory CSS pro vyhledávání prvků .waitForElementVisible ("header.header input.new-todo", 1000) .setValue("header.header input.new-todo", ["New TODO element", client.Keys.ENTER]) // Nebo použijte Xpath - it" s výkonnějším nástrojem .useXpath() .waitForElementVisible("//section[@class=\"main\"]//label", 2000) .execute(function() ( // Pro odeslání poklepejte - Nightwatch nepracuje ve výchozím nastavení to podporuje var evt = new MouseEvent("dblclick", ("view": okno, "bubbles": true,"cancelable": true)); var foundElems = document.querySelectorAll("section.main label"); if(!foundElems) return; var elm = null;< foundElems.length; i++) { if(foundElems[i].innerText === "New TODO element") { elm = foundElems[i]; break; } } elm.dispatchEvent(evt); }) .waitForElementVisible("//section[@class=\"main\"]//input[@type=\"text\"]", 2000) .clearValue("//section[@class=\"main\"]//input[@type=\"text\"]") .setValue("//section[@class=\"main\"]//input[@type=\"text\"]", ["New TODO element changed", client.Keys.ENTER]) .waitForElementVisible("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\" and not(@checked)]", 2000) .click("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\" and not(@checked)]") .waitForElementVisible("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\"]", 2000) .click("//section[@class=\"main\"]//label" + "/preceding-sibling::input[@type=\"checkbox\"]") .waitForElementVisible("//section[@class=\"main\"]//label" + "/following-sibling::button[@class=\"destroy\"]", 2000) .click("//section[@class=\"main\"]//label" + "/following-sibling::button[@class=\"destroy\"]") .waitForElementNotPresent("//section[@class=\"main\"]//label", 2000) .pause(2000) .end(); } }

Mezi zvláštnostmi kódu je snadné si všimnout, že Nightwatch nepodporuje emulaci dvojitého kliknutí na prvek - místo toho musíte implementovat řešení s funkcí inject na klientovi, který spustí událost dispatchEvent na cílovém ovládacím prvku.

Šikovnou funkcí Nightwatch je její podpora pro XPath, která poskytuje podstatně více dostatek příležitostí pro výběr prvků modelu DOM ve srovnání s CSS selektory - vezměte alespoň extrakci prvku podle jeho textového obsahu, což je ve funkčním testu zcela běžné.

Srovnání funkcí TestCafe a Nightwatch

Instalace:
[T]estCafe: Stačí jeden příkaz npm install -g testcafe a hned můžete začít psát a spouštět testy v aktuálním adresáři webového projektu
[Noční hlídka: Přestože je instalace modulu npm jednoduchá - npm install -g nightwatch , budete si muset ručně stáhnout selenium-standalone-server, webové ovladače pro všechny prohlížeče, které vás zajímají, ruční tvorba konfigurační soubor(Nebo možná dokonce stáhnout Javu, pokud není nainstalována)

Výběr prvků DOM:
T: Používá se mechanismus Selectors - wrappery nad klientskými funkcemi JS, které vybírají jeden nebo více uzlů DOM; to prakticky poskytuje neomezené možnosti pro výběr, od jednoduchého obalu přes document.querySelector nebo document.getElementById a končící libovolnou logikou pro procházení prvků DOM. TestCafe zároveň nezávisle kontroluje přítomnost/nepřítomnost prvků dle zadaného Selectoru ve stanoveném čase.
N: Můžete si vybrat ze selektorů CSS nebo XPath - v zásadě druhá možnost postačuje k vyřešení většiny problémů s výběrem prvků na stránce, i když to se samozřejmě nevyrovná možnosti zadat složitou libovolnou logiku vyhledávání.

Testovací jazyk psaní:
T: Po vybalení je možné psát testy přímo v jazyce ES2016, což umožňuje psát jednoduchý a čitelný testovací kód ve stejném jazyce jako samotná webová aplikace konkrétní modul z testovaného projektu.
N: Zastaralá syntaxe ES5 a exportuje konstrukce ve zdrojovém kódu funkčního testu (Stále je možné přidat ES6, ale pouze s berličkami)

Podpora asynchronních operací:
T: Všechny funkce API jsou založeny na Promises, což umožňuje popsat libovolnou logiku asynchronního testu a zároveň integrovat nativní funkce ze strany node.js. Díky podpoře ES2016 lze tento kód psát pomocí asynchronně a čekat na konstrukce v sekvenčním stylu.
N: V testu můžete implementovat sekvenci příkazů pro analýzu a správu obsahu webové stránky, které se však přidávají do interní fronty událostí a integrace vlastních asynchronních funkcí s nimi je problematická.

Vkládání klientského kódu za běhu:
T: Snadno implementovatelné pomocí příslušného API, podporuje vytváření a následné provádění klientských funkcí, jednorázové spuštění vloženého kódu, nahrazení stávající funkce na zdrojové webové stránce, stejně jako provádění klientských funkcí ve zpětných voláních funkcí node.js s vazbou na testovací řadič.
N: Existuje funkce pro spouštění kódu JS na straně klienta nebo dokonce pro vložení celého bloku skriptu, ale nejsou poskytovány žádné prostředky pro integraci s testovacím řadičem. Vhodné pro jednoduchý synchronní integrovaný JS kód, ale obecnější integrace je problematická.

Popisy prohlášení a očekávání:
T: Výchozí je normální jazyk asercí chai/expect, lze použít jakoukoli jinou kompatibilní knihovnu asercí.
N: Rozšířený jazyk tvrzení a očekávání, který zahrnuje nástroje pro popis stavu stránky, včetně toho, zda je prvek přítomen a má fokus, zda patří do třídy CSS a tak dále. Vypadá to pohodlně, ale je to především kvůli nedostatku plná podpora asynchronní operace v testu, pokud je nutné mít tvrzení a očekávání.

Správa testované webové stránky:
T: Předpokládá možnost zesměšňovat funkce alert , potvrdit atd., které blokují provádění skriptů, s možností nastavení návratové hodnoty. Podporuje komplexní manipulaci s DOM, emulaci uživatelské interakce s ovládacími prvky a dokonce i schopnost pozastavit skript JS zabalením funkcí JS na straně klienta.
N: Příkazy jsou podporovány pro přímé ovládání zobrazeného okna prohlížeče a základního DOM, integrace se skriptem JS na straně klienta je obtížná

Práce s kurzorem myši:
T: K dispozici je virtuální kurzor, jehož prostřednictvím se pro cíl provádějí události najetí, kliknutí a přetažení vizuální prvky stránky. Zatímco test běží, můžete sledovat pohyb kurzoru a prováděné akce.
N: Na práci s kurzorem obecně existují nástroje - jsou to funkce z api webdriveru, ale práce s akcemi, které jsou složitější než jedno kliknutí levým tlačítkem, je dost problematická - i dvojklik.

Implementace interakce prohlížeče v TestCafe a NightWatch

Framework NightWatch je založen na známé, poněkud tradiční knihovně webových ovladačů Selenium, mezi jejíž výhody patří dobře zavedené API, vysoký stupeň dokumentace a rozsáhlé otázky a odpovědi na internetu, stejně jako univerzální a poměrně nízkoúrovňový přístup k prohlížeči... Interakce s prohlížeči je organizována prostřednictvím webových ovladačů, jeden pro každý prohlížeč.
Hlavní nevýhodou je, že webové ovladače neexistují pro všechny prohlížeče a také vyžadují samostatnou aktualizaci při změně verze samotného prohlížeče a k fungování je také vyžadována externí závislost na Javě. Více informací o technologii webdriveru si můžete přečíst na http://www.w3.org/TR/webdriver/

Metoda TestCafe je univerzálnější, protože může potenciálně fungovat s jakýmkoli prohlížečem, který podporuje HTML5 a ES 5+, zatímco NightWatch vyžaduje odpovídající webový ovladač. Navíc to umožňuje spouštět testy nejen v lokálním prohlížeči, ale v jakémkoli prohlížeči v síti, včetně jakéhokoli mobilního - bez instalace jakéhokoli softwaru do telefonu.

Příklad testování výše uvedené webové aplikace v prohlížeči na Androidu ukazuje následující video: https://youtu.be/2na5jkqvUx0

Testcafe-hammerhead má však i potenciální nevýhody: režijní náklady na analýzu a úpravu zdrojového JS kódu testované stránky, které jsou zase produkovány v JS kódu jádra Testcafe, a také teoreticky nesprávný provoz testovaného webu. stránka nebo testovací integrace, pokud zdroj byl nesprávně zadán. (Například nahrazení výstražného okna v testcafe lze obejít tímto příkladem http://pastebin.com/p6gLWA75 – a jeho spuštění může být neúmyslně nebo záměrně pozastaveno)

závěry

Selenium-webdriver, na kterém je Nightwatch založen, je samozřejmě populární a široce rozšířený známé řešení, který má standardní API rozhraní, což je bezesporu jeho výhoda. Kromě toho v souvisejících oblastech úkolů, například automatizace cílového webového zdroje v zadaný prohlížeč- vlastně psaní bota pro vzdálený web - selenium-webdriver je vhodnější.

Pokud jde o funkční testování vyvíjené nebo udržované webové aplikace, je TestCafe nepochybně napřed z celé řady důvodů:

1) Spusťte testy v libovolném prohlížeči, včetně mobilní telefony a tablety, a to lze provést v dávkách pro všechny zajímavé prohlížeče a nevyžaduje instalaci žádného dalšího softwaru.
2) Snadné psaní testu v ES2016, včetně konstrukcí async/await pro sekvenční zápis kódu, import programových prvků ze samotného projektu, přenos funkcí na klienta a zpět atd. – dostatek příležitostí pro integraci a správu klientské webové aplikace .
3) Široká podpora selektorů pro vizuální prvky, snadná interakce s modelem DOM, virtuální kurzor myši, emulace různých a složitých uživatelských interakcí se stránkou. Přidat štítky

Testování webových aplikací má mnoho společného s testováním operačních systémů pro stolní počítače. Musíte otestovat standardní funkčnost, konfiguraci a kompatibilitu a vše ostatní standardní typy testy. Testování webových aplikací je ale složitější proces, protože potíže násobí všechny distribuované součásti systému, které s aplikací interagují. Když v síťovém prostředí vidíme chybu, je často obtížné přesně určit, kde k ní došlo, a proto chování nebo chybová zpráva, kterou obdržíme, může být výsledkem chyb, ke kterým došlo v různé části síťový systém. V tomto případě bude oprava chyby problematická. Jak bychom tedy měli analyzovat chyby v systému založeném na internetové technologii a jaký výzkum by měl být proveden, abychom tyto typy chyb opravili?

Když rozumíme zařízení základní technologie, jsme mnohem lépe schopni zvýšit efektivitu testování psaním snadněji reprodukovatelných oznámení o selhání a chybách. To nám zase umožňuje rychleji odhalit závady. To je ale mnohem jednodušší deklarovat než realizovat. Zejména v prostředí internetu. Je plný procesních proměnných, které jsou poměrně náchylné k chybám. Zde je 5 základních, základních úsudků o testování webových aplikací:

• Když vidíme chybu na straně klienta, vidíme příznak chyby, ale ne samotnou chybu.
• Chyby jsou závislé na prostředí a nemusí se vyskytovat v různých prostředích.
• Chyby mohou být v kódu nebo v konfiguraci.
• Chyby se mohou nacházet na kterékoli z několika úrovní.
• Zvažování 2 tříd operačních prostředí – statického a dynamického – vyžaduje různé přístupy.

Podívejme se na těchto 5 tvrzení podrobněji:

1. Co vlastně vidíme, chyba nebo symptom?

Bez environmentální diagnostiky nemůžeme s úplnou jistotou říci, co přesně je příčinou příznaku. Pokud některý z konkrétních proměnné prostředí na straně klienta nebo serveru se přesune nebo změní, pak existuje možnost, že nebudeme schopni problém reprodukovat.

Zde je příklad. Testuji webovou aplikaci pro sledování defektů a právě vytvářím novou zprávu o chybě. Když kliknete na NOVÝ, zobrazí se chybová zpráva, která vypadá takto:

Chyba zprostředkovatele Microsoft OLE DB pro ovladače ODBC "8004014".

Poté, co jsem strávil nějaký čas zkoumáním hardwaru prohlížeče, v dialogovém okně předvoleb prohlížeče jsem zjistil, že JavaScript není povolen. Aktivace JavaScriptu chybu vyřeší. Základní myšlenkou je, že přidávám další informace o konfiguraci JavaScriptu týkající se chybové zprávy. Kromě toho je v mém zahrnuta položka „deaktivace JavaScriptu“. testovací sada v budoucnu bude přidán do všech částí aplikace, takže vše je potenciálně související chyby mohla být objevena.

2. Je chybové prostředí závislé?

Hrát prostředí závislé chyba, musíme dokonale duplikovat jak přesnou sekvenci akcí, tak podmínky prostředí, ve kterém bude aplikace fungovat (operační systém, verze prohlížeče, přídavné komponenty databázový server, webový server, terciární komponenty, serverové/klientské zdroje, šířka pásma sítě, provoz atd.). Pokud se například pokusíte přihlásit do své webové aplikace pomocí vytáčeného připojení rychlostí 28,8 kb/s, dojde k selhání registrace, dokud nebude proces autorizace přerušen z důvodu vypršení času vyhrazeného pro tento účel. Registrace v síti, provedená stejným způsobem, ale pomocí připojení T-1 o rychlosti 1,54 Mb/s, bude úspěšná. V tomto případě máte chybu závislou na prostředí, kde závislost souvisí s propustností sítě.

Na druhou stranu chyby nezávislé na prostředí se reprodukují poměrně snadněji. Není třeba duplikovat operační prostředí. U chyb nezávislých na prostředí je potřeba pouze duplikovat kroky, které budou chybu reprodukovat. Pokud je například název společnosti na všech stránkách s jejími produkty napsán nesprávně a vypadá takto - WebTesting.Con, pak ty Vždy Tato chyba se zobrazí bez ohledu na proměnné hardwaru, softwaru nebo prostředků ve vašem operačním prostředí. Jinými slovy, chyby nezávislé na životním prostředí vnímáme jako funkčně specifické.

3. Jedná se o chybu kódování nebo problém s konfigurací?

Chyby (nebo příznaky podezřelých chyb) lze opravit pomocí souřadnic jejich umístění v programu (za předpokladu, že chyby skutečně existují) nebo překonfigurováním systému (klient, server nebo síť). Neměli byste dělat ukvapené závěry a věřit, že jde o chybu.

Chyba zprostředkovatele Microsoft OLE DB pro ovladače ODBC "80004005"

Zde je příklad ilustrující potíže s identifikací možný problémy s konfigurací versus nemovitý softwarové problémy. Vidíme chybové hlášení, jehož důvodem je nemožnost registrace ("neúspěšné přihlášení"). Tato zpráva byla vygenerována webovou aplikací. Pouhým pohledem na tuto chybovou zprávu však není možné určit, zda se skutečně jedná o chybu nebo zda je výsledkem selhání softwaru, problémů s konfigurací na straně serveru, problémů s nekompatibilitou, problémů s konfigurací prohlížeče nebo všech těchto problémů. větší či menší míře.

Po další analýze selhání jsem jich našel několik možné důvody který mohl vygenerovat toto chybové oznámení:

Virtuální adresář webového serveru (IIS) nebyl správně nainstalován.

Pokud není virtuální adresář správně nakonfigurován, požadované soubory, skripty nebo data nebudou nalezeny. Obvykle se jedná o problém s konfigurací serveru. I když, kdyby instalační program nemohl automaticky nakonfigurovat webový server podle specifikace, pak toto softwarová chyba. Pokud se správci systému nepodaří správně nakonfigurovat webový server v souladu se specifikací, chyba se změní na uživatelská chyba.

Adresář aplikace nebyl správně nakonfigurován pro správné spouštění skriptů.

Standardní adresář aplikačního serveru obsahuje skripty, které se spouštějí, když jsou volány webovým serverem na žádost klienta. Z bezpečnostních důvodů lze webový server nakonfigurovat tak, aby povoloval nebo blokoval provádění skriptů v jednotlivých adresářích. Pokud je tedy váš aplikační server vytvořen tak, že obsahuje skripty, které je třeba spustit, a webový server je nakonfigurován tak, aby blokoval jejich provádění v tomto adresáři, aplikace nebude fungovat. co je potom? softwarová chyba nebo problém s konfigurací?

Výchozí webová stránka nebyla správně nainstalována.

Problém je podobný výše popsanému problému.

SQL Server je neaktivní.

Aplikační server vyžaduje připojení k databázovému uzlu umístěnému na serveru SQL pro spouštění dotazů, ukládání procedur a přístup k datům. Pokud proces služby SQL neběží, aplikace se samozřejmě nespustí.

Objekty DLL/COM chybí nebo nebyly úspěšně zaregistrovány.

Je možné, že instalační program nebyl schopen zkopírovat všechny soubory DLL používané aplikačním serverem během instalace. Pokud některý soubor DLL požadovaný pro fungování aplikačního serveru chybí, aplikace nebude fungovat.

Je možné, že instalační program správně zkopíroval všechny požadované moduly, ale nedokázal zaregistrovat jeden nebo více z nich. Například v objektech založených na OLE, jako je COM nebo DCOM, musí být jejich ID třídy (CLSID) registrováno v databázi. systémový registr než budou k dispozici k použití. Pokud se aplikace pokusí o přístup k objektu COM, který nebyl úspěšně zaregistrován, nebude fungovat.

K tomuto problému často dochází v důsledku chyb během instalace. Na druhou stranu, pokud je nutné komponenty registrovat ručně, stane se to problém s konfigurací.

Nastavení JavaScriptu na straně prohlížeče bylo zakázáno.

Toto je problém s konfigurací specifického prohlížeče, ke kterému dochází, jakmile aplikace požádá prohlížeč o povolení JavaScriptu. Jedná se o softwarovou chybu, problém s konfigurací nebo problém s technickou podporou?

4. Jaká úroveň skutečně způsobuje problém?

Často je obtížné konzistentně reprodukovat chyby ve webových systémech, protože velké množství proměnných je reprezentováno distribuovanou povahou struktury systému klient/server. Ve webovém prostředí jsou minimálně 3 „obvyklí podezřelí“. Tento klienta, server A síť.

Klient i server podléhají nesrovnalostem v konfiguraci a kompatibilitě, které jsou podobné prostředí PC, kde jsou všechny komponenty ve stejné krabici. Tyto nekonzistence se však v systémech klient/server zvětšují, protože k síti může být připojeno mnoho klientů a serverů. Typické nekonzistence konfigurace a kompatibility vedou k nejasnostem technická podpora a operační systém (např. jednotky založené na systému UNIX versus jednotky založené na systému Windows) a softwarový mix na straně serveru (balíčky webových serverů, balíčky databázových serverů, brány firewall, objekty COM, objekty CORBA atd.). Nekonzistence mohou také vést k záměnám softwaru na straně klienta (fronty TCP/IP, software dialeru, součásti nápovědy, značky a verze prohlížečů). Kromě toho nastavení prohlížeče, jako jsou obecná nastavení, nastavení připojení, nastavení zabezpečení (včetně ovladačů ActiveX, další softwarových modulů(pluginy), Java, skripty, stahování, přihlášení uživatele atd.), nastavení obsahu, nastavení programu a další pokročilá nastavení (včetně možností zobrazení, možností multimédií, možností Java VM, možností tisku a možností HTTP), poskytují mnoho proměnných, které by měly být testovány a zahrnuty do studií.

Sítě nabízejí jinou sadu proměnných. Ovlivňují webové aplikace na několika frontách, včetně problémů souvisejících s časem (stav spojení, výkon, prostoje atd.), které jsou způsobeny šířkou pásma a latencí, možnou konfigurací a problémy s kompatibilitou s hardwarem, jako jsou brány a směrovače, a vedlejšími efekty spojené s prací bezpečnostní služby.

5. Statická a dynamická provozní prostředí se navzájem liší.

Existují 2 třídy operačních prostředí, z nichž každé má své vlastní jedinečné testovací inkluze:

Statická prostředí ve kterých problémy s nekompatibilitou mohou existovat nezávisle na nich proměnlivé podmínky, jako je rychlost zpracování a dostupná paměť.

Dynamická prostředí. V nich je tomu naopak - kompatibilní komponenty dokážou detekovat chyby v souladu s chybami závislými na paměti a skryté podmínky. (Dynamická prostředí probereme podrobněji později v této části.)

Statické provozní prostředí: Konfigurace a proměnné kompatibility.

Problémy s konfigurací a kompatibilitou mohou nastat v kterémkoli bodě webového systému: mohou se objevit na straně klienta, serveru nebo sítě.

Problémy s konfigurací ovlivňují různá nastavení serverový software a hardware, nastavení prohlížeče, síťová připojení a Nastavení TCP/ IP fronty. Výše uvedený příklad prohlížeče a JavaScriptu ilustroval jeden typ konfiguračního problému. Jiný typ je uveden v Schéma 1 A Schéma 2 . Jsou prezentovány ve dvou možných konfiguracích fyzického serveru: jedno- a dvou-jednotkové.

Schéma 1: Webový server, aplikační server a databázový server na jedné platformě

Schéma 2: WEB server a aplikační server na jedné platformě, databázový server na druhé

Naše testovaná vzorová aplikace má některé funkce pro vytváření grafů, které uživateli umožňují vytvářet metrické sestavy, jako jsou pruhové a spojnicové grafy. Když uživatel požádá o sestavu metrik, spustí se pseudokód aplikačního serveru v následujícím pořadí:

1. Připojte se k databázovému serveru a zadejte požadavek.

2. Záznam výsledku požadavku ve formě souboru s názvem c:\temp\chart.val

3. Spuštění apletu Chart Java. Čtení a používání dat ze souboru c:\temp\chart.val umět nakreslit graf.

4. Odeslání apletu Java do prohlížeče.

V procesu testování aplikace jsem zjistil, že funkcí při vykreslování grafu bylo, že fungovala pouze s jednou z výše uvedených konfigurací. Při další kontrole se ukázalo, že problém byl specifický pro konfiguraci se dvěma jednotkami. Po kontrole kódu se ukázalo, že problém je v bodech 2 a 3. V druhém bodě je výsledek dotazu c:\temp\chart.val byla zapsána lokální disková jednotka databázového serveru. Ve třetím bodě byl na aplikačním serveru spuštěn Chart Java Applet, který byl umístěn na jiných blocích než databázový server. Když se pokusím otevřít soubor c:\temp\chart.val na místním disku aplikačního serveru se ukázalo, že tento soubor tam prostě není.

V tomto případě nedoporučuji číst kód pokaždé, když narazíte na chybu. Nechte vývojáře, aby opravili problémy. Chci jen poukázat na potřebu identifikovat, který server má problémy s konfigurací, a zahrnout tyto informace do zpráv o problémech. Také bych spustil mělkou testovací sadu na všech distribuovaných konfiguracích podporovaných testovaným aplikačním serverem.

Problémy s dodržováním předpisů jsou také důležité ve statických provozních prostředích. Jako příklad můžeme uvažovat Schéma 3 kde vidíme rozdíl v kompatibilitě mezi Netscape Navigator a internet Explorer.

Diagram 3: Problém s kompatibilitou prohlížeče

To v žádném případě neznamená, že internet Explorer je lepší než Netscape Navigator. To jen znamená, že mezi prohlížeči existují problémy s nekonzistencí a že kód nemusí fungovat relativní cesty(do souboru) pro všechny prohlížeče. Ještě důležitější je, že pokud narazíte na chybu v jednom prostředí, může se objevit i v jiném prostředí. nevznikají za předpokladu, že se jedná o chybu závislou na prostředí.

Dynamické provozní prostředí: Věci nezůstávají stejné.

Když hodnota specifického atributu prostředí nezůstane během každé testovací procedury konstantní, dojde k přeměně operačního prostředí dynamický. Atribut může být cokoli od specifického pro zdroj (dostupná RAM, místo na disku atd.) až po načasování (latence sítě, pořadí uživatelských transakcí atd.)

Když testovací případ závisí na přesný přehrávání jako soubor akcí, tak operační prostředí a prostředí nemůže být reprodukováno (kvůli jeho dynamické povaze), pak se chyba stává nereprodukovatelnou nebo obtížně reprodukovatelnou.

To je mimochodem důvod, proč je často obtížné reprodukovat chyby související s pamětí. Když je například v kódu chyba přepsání paměti, vždy to vytvoří odpovídající problém. Z hlediska testování černé skříňky však nebudeme schopni vidět příznak této chyby, dokud nebudou provedeny nebo přečteny konkrétní bajty nebo data přepsaného kódu. V tomto příkladu představuje kolekce akcí přesnou sadu funkcí černé skříňky. Chyba přepsání paměti představuje skutečnou chybu v kódu. Stav, za kterého se provede nebo přečte přepsaný bajt, označuje dynamické provozní prostředí nebo stav nezbytný pro reprodukci chyby.

Zde je příklad chyby dynamické webové aplikace závislé na prostředí, ve které budeme uvažovat chybu související s časem.

Požadavky na specifikaci:

1. Názvy projektů v systému musí být jedinečné.
2. Detekce chyb a zpracování potenciálního kopírování na straně klienta by se mělo provádět pomocí JavaScriptu.
3. Uživatelé mohou přidávat nebo odebírat názvy projektů vyžádáním stránky NastaveníNahoruProjekty.
4. Když uživatel vytvoří nový název projektu, JavaScript prohlížeče porovná zadaný název s vybraným seznamem umístěným na stránce HTML (jak je uvedeno v Schéma 4 )

Podívejte se na chybu související s časem zobrazenou v Schéma 5 . Toto jsou snímky obrazovky stránky Nastavení projektů vyrobeno před A po, nám umožní vidět, že aplikace nebyla schopna detekovat duplicitní titul „Odsouzeno“. V Schéma 4 poskytuje vysvětlení této chyby související s časem, která způsobuje, že oba uživatelé přidávají nové názvy projektů do stejné databáze.

Schéma 4: Java-script na straně prohlížeče kontroluje zadané hodnoty

Diagram 5: Chyba související s časem

Jak je uvedeno v stůl 1 , uživatel A a uživatel B vytvářejí nové projekty, i když současně, ale bez znalosti vzájemných akcí. Podle bodu 3 uživatel A přidá projekt tzv Další. Ale protože takové jméno již existuje, JavaScript jeho prohlížeče zobrazí zprávu, která mu říká, aby použil jiné jméno.

Tabulka 1: Aktivity uživatelů A a B
[otevřít větší]

Uživatel B přidá název projektu odsouzený k záhubě. JavaScript jejího prohlížeče jej nerozpozná jako již existující, takže přidá název do databáze i do seznamu vrácených položek. Aktualizovaný seznam názvů projektů je zaslán zpět uživateli B.

Následně uživatel A přidá stejné jméno Odsouzeno seznam projektů. JavaScript jeho prohlížeče jej v seznamu HTML nerozpozná, takže název znovu přidá odsouzený k záhubě do databáze a seznamu návratů. Uživateli A je zaslán aktualizovaný seznam názvů projektů včetně dvou položek odsouzený k záhubě.

Získaný výsledek nesplňuje specifikace produktu. Přestože je tato situace dobře ilustrovaným testovacím případem, náhodné odhalení této chyby a pokus o její reprodukci není snadný úkol. V tomto příkladu samotná chyba spočívá v tom, že aplikace nebyla schopna zkontrolovat a opravit duplicitní názvy na straně serveru (kromě kontroly na straně klienta). Kroky zahrnují uživatele A. Dynamic operační systém vytvořené akcemi uživatele B, které jsou uživateli A skryté nebo mu jednoduše neznámé.

Závěr

Chcete-li efektivně analyzovat a reprodukovat chyby ve webovém prostředí, musíte mít vliv na operační prostředí. Musíte také pochopit, jak mohou proměnné specifické pro prostředí ovlivnit vaši schopnost reprodukovat chyby. Doufám, že s některými dovednostmi, které se můžete naučit z tohoto článku, bude vaše testování webu méně frustrující a příjemnější.

Pamatujte, že nic nemůže nahradit vaše testovací dovednosti a vaši schopnost nabízet dobro testovací případy. Nebojte se zeptat „Co když...?“, dělejte si podrobné poznámky a metodicky vyšetřujte těžko reprodukovatelné chyby. To jsou přesně dovednosti, které vám pomohou nejen při studiu chyb, ale také při hledání dalších problémů s nimi spojených.

Testování webových aplikací*
Co je webová aplikace?
Webová aplikace - aplikace klient-server, V
ve kterém je klientem prohlížeč a serverem je webový server. Logika webové aplikace je distribuována mezi serverem
a klienta se provádí ukládání dat,
výměna informací probíhá především na serveru
přes síť. Jednou z výhod tohoto přístupu je to
skutečnost, že klienti nejsou závislí na konkrétním operačním systému
systém uživatele, tedy webové aplikace
multiplatformní služby.

Testování webových aplikací

*
Co jsou webové aplikace?
1. „Jednoduché“ stránky a webové aplikace:
-
Informační stránky
Elektronické obchody
Jednoduché webové aplikace

Testování webových aplikací

*
2. Komplexní aplikace a portály
-
Řešení s rozšířenou funkčností
Horizontální portály a sociální sítě
Streamovací řešení
Online aukce a obchodní platformy

Testování webových aplikací

*
3. Pokročilé webové produkty a cloudová řešení
- Inovativní produkty
- SaaS řešení
-Vyhledávače
-Obchodní systémy
-Online platební systémy

Architektura klient-server

*

Architektura klient-server

*
2vrstvá architektura klient-server

Testování webových aplikací

*
Co je testování WEB aplikací?

10. Testování WEB aplikací

*
1. Přípravné práce
tester prostuduje obdrženou dokumentaci (analýzy
funkčnost dle tech úkolu, studuje konečné rozvržení stránek a
sestaví testovací plán pro další testování)
2. Funkční testování je nejdelší fází
kontroly zdrojů. Podstatou tohoto procesu je vše zkontrolovat
popsaná funkčnost:
Kontrola fungování všech požadovaných funkcí webu;
Testování výkonu uživatelských formulářů na webu
(například zpětná vazba, přidání komentáře na blog);
kontroly výkonu vyhledávání (včetně relevance výsledků);
Kontrola hypertextových odkazů, hledání nefunkčních odkazů;
Kontrola nahrávání souborů na server;
Kontrola funkčnosti čítačů nainstalovaných na stránkách
webová stránka;
Kontrola obsahu stránek webu z hlediska souladu s původním obsahem
obsah poskytnutý zákazníkem.

11.

3. Testování rozložení - při kontrole rozložení první věc
Tester kontroluje uspořádání prvků a jejich shodu
pozice do poskytnutých rozvržení a také kontroluje optimalizaci
obrázky a grafika. Dále se kontroluje platnost
kód.
Během procesu rozvržení je důležité zachovat správnou hierarchii objektů,
a po dokončení práce je důležité ověřit jeho platnost.
Prohlížeče, navzdory zjevně nesprávnému kódu, v každém případě
se pokusí zobrazit webovou stránku. Ale protože neexistuje
jednotné předpisy o tom, jak má být „křivka“ zobrazena
každý prohlížeč to zkouší jinak. A tohle je in
zase vede k tomu, že stejný dokument může
vypadat jinak v různých prohlížečích.
Oprava zjevných chyb a systematizace kódu vede k tomu, jak
obvykle ke stabilnímu výsledku. Po dokončení kontroly pro
platnost, specialista začne kontrolovat kompatibilitu mezi prohlížeči,
těch. kontroluje funkčnost webu v různých prohlížečích a
stejné s jiným nastavením obrazovky.

12.

Proč kontrolovat kompatibilitu webu s různými prohlížeči? K datu
existuje řada nejpopulárnějších webových prohlížečů, jako je Google
Chrome, Safari, Mozilla Firefox, Internet Explorer a Opera. Každý z
dodržují obecná doporučení pro vizualizaci značek
stránky, ale zároveň každý zpracovává kód v
podle vlastností vašeho vlastního motoru. Všechno se komplikuje
skutečnost, že se poměrně často objevují nové verze prohlížečů, a
zdroj, který vypadá skvěle, například v IE9, není nutný
bude vypadat správně v IE7 nebo IE8. Proto v procesu
testování bere v úvahu seznam prohlížečů, které podporují
provedli rezervaci u zákazníka v raných fázích projednávání projektu.
Fáze kontroly kompatibility webu mezi různými prohlížeči pod různými
rozlišení jsou poměrně časově náročná, ale výsledek stojí za to -
Jakýkoli zástupce cíle bude moci zobrazit vaše stránky
publikum.

13.

Testování použitelnosti – provádí se za účelem vyhodnocení použitelnosti
produkt v použití, na základě přitažlivosti
uživatelé jako testeři a analýza přijatých
Výsledek.
Nehledě na to, že studie použitelnosti
zdroj se provádí v procesu sestavování technických
úkoly, vývoj rozvržení, jsou situace, kdy
získaný výsledek není optimální. Ačkoli toto je
se stává docela zřídka optimální řešení v tomhle
případ - provést změny na prodávaném produktu.
Testování se provádí za účasti několika lidí z
cílové publikum, tzv. respondenti. Pro
K provedení testování stačí 4-6 lidí. Existuje
Pravidlo 80/20, které říká, že 20 % uživatelů dává 80 %
výsledek. Proto takový počet respondentů
co nejefektivněji z hlediska úspory času a
náklady.

14.

Testování zabezpečení – V této fázi testování
specialista kontroluje, zda uživatelé mají přístup
oficiální/soukromé stránky a také kontroly
ochrana všech je důležitá důležité stránky(například sekce
správa webu) před vnějšími vlivy.

15.

Testování výkonu webových stránek – provádí se za účelem
určování výkonnosti webu nebo jeho části pod určitým
zatížení. Testování výkonu zahrnuje následující typy
testování:
Zátěžové testování je nejjednodušší formou testování
produktivita. Zátěžové zkoušky se obvykle provádějí pro
za účelem vyhodnocení chování webu (nebo aplikace) pod daným
očekávané zatížení. Tato zátěž by mohla být například očekávaná
počet souběžných uživatelů na webu,
provedení určitého počtu transakcí za časový interval. Tenhle typ
testování obvykle umožňuje získat dobu odezvy ze všech nejvíce
důležité obchodní funkce.
Testování výkonu – kontrola rychlosti načítání webu
určení rychlosti zpracování skriptů, načítání obrázků a
obsah. Tento test se provádí za účelem optimalizace procesu spouštění
webu a také určení optimálního nastavení serveru.

16. Vlastnosti testování webových aplikací:

*
Technologické rozdíly.
Klasická aplikace běží pomocí jednoho
nebo rodiny příbuzných technologií.
Webová aplikace funguje zásadně pomocí
různé technologie.
Strukturální rozdíly.
Klasická aplikace je „monolitická“. Skládá se z jednoho resp
malý počet modulů. Nepoužívá databázové servery,
webové servery atd.
Webová aplikace je „multikomponentní“. Skládá se z velkého
počet modulů. Ujistěte se, že používáte databázové servery, webové servery, aplikační servery.

17.

Rozdíly v provozních režimech.
Klasická aplikace funguje v reálném čase
čas, tzn. okamžitě si je vědom akcí uživatele
pouze je dokončena.
Webová aplikace funguje v režimu „žádost-odpověď“, tzn.
vědět o určitém souboru akcí až po žádosti o
server.

18.

Rozdíly ve vytváření rozhraní.
Klasická aplikace používá ke generování
uživatelská rozhraní jsou poměrně zavedená a
standardizované technologie.
Ke generování slouží webová aplikace
uživatelské rozhraní se rychle vyvíjí
technologie, z nichž mnohé si navzájem konkurují.
Rozdíly v práci se sítí.
Klasická aplikace nepoužívá prakticky žádnou síť
kanály pro přenos dat.
Webová aplikace aktivně využívá síťové přenosové kanály
data.

19.

Rozdíly mezi spuštěním a zastavením.
Klasická aplikace se spouští a zastavuje
zřídka.
Webová aplikace se spustí a poté se zastaví
přijetí každé žádosti, tzn. Často.
Rozdíl je v počtu uživatelů.
Klasická aplikace: počet uživatelů,
současné používání aplikace jsou náchylné k
kontrola, omezená a snadno předvídatelná.
Webová aplikace: počet uživatelů současně
použití aplikace je obtížné předvídat a může
se náhle mění v širokém rozsahu.

20.

Vlastnosti poruch a poruch.
Klasická aplikace: selhání určitých komponent
se stává okamžitě zřejmým.
Webová aplikace: selhání některých komponent má dopad
nepředvídatelný dopad na výkon aplikace jako celku.
Rozdíly v instalaci.
Klasická aplikace - proces instalace je standardizovaný a
maximálně cílené na široké publikum uživatelů. Ne
vyžaduje specifické znalosti. Přidávání komponent aplikace
provedeno standardním způsobem pomocí stejného
stejný instalátor.
Webová aplikace – proces instalace je často pro koncového uživatele nepřístupný
uživateli. Instalace vyžaduje specifické znalosti. Proces
změny součásti aplikace nejsou poskytovány ani vyžadovány
uživatelská kvalifikace. Chybí instalační program.

21.

Rozdíly v odinstalaci.
Klasická aplikace: Proces odinstalace
standardizované a prováděné automaticky popř
poloautomaticky.
Webová aplikace: Vyžaduje proces odinstalace
specifické znalosti pro zásah administrátora a
často zahrnuje změnu kódu operačního prostředí
aplikace, databáze, nastavení OS systému.
Vlastnosti operačního prostředí.
Klasické použití: Prostředí
standardizované a nemá velký vliv na fungování
aplikací.
Webová aplikace: operační prostředí je velmi rozmanité
a může mít vážný dopad na výkon a
serverové a klientské části.

22. Praktický úkol:

*
Otestujte zdroj.
Vytvářejte hlášení o nalezených chybách.
http://mines.pp.ua/