complete non functional testing guide
Kompletní průvodce nefunkčním testováním: jeho účel, typy, nástroje, testovací případy s příklady
Co je nefunkční testování?
Nefunkční testování se provádí k ověření nefunkčního požadavku aplikace, jako je výkon, použitelnost atd.
Ověřuje, zda je chování systému podle požadavku, či nikoli. Pokrývá všechny aspekty, které nejsou zahrnuty v funkční testování . Při našem každodenním testování je věnována velká pozornost funkčnímu testování a funkčním požadavkům.
Klienti mají také zájem o plnění funkčních požadavků, které přímo souvisejí s funkčností aplikace. Ale ve skutečné fázi, tj. Když jste funkčně testováni, software přichází na trh a je používán skutečnými koncovými uživateli, a existuje šance, že bude čelit některým problémům souvisejícím s výkonem.
Tyto problémy nesouvisejí s funkčností systému, ale mohou negativně ovlivnit uživatelské prostředí. Proto je důležité, aby software nebo aplikace byly testovány také na nefunkční požadavky, aby se zabránilo negativní zkušenosti zákazníků.
Testování je obecně klasifikováno do dvou typů:
- Funkční testování
- Nefunkční testování
Co se naučíte:
- Důležitost
- Účel
- Příklad
- Výhody
- Jak zachytit nefunkční požadavky?
- Rozdíl ve funkčních a nefunkčních požadavcích
- Testuje se tato černá skříňka nebo bílá skříňka?
- Kontrolní seznam nefunkčních testovacích případů
- Přístupový dokument
- Nefunkční typy testování
- Nefunkční testovací nástroje
- Závěr
- Doporučené čtení
Důležitost
Tomuto testování chyběla náležitá pozornost vzhledem k tomu, že neovlivňuje funkčnost systému.
Nefunkčním požadavkům nebyla v dřívějších testovacích cyklech věnována náležitá pozornost. To se však nyní změnilo. Nefunkční testy jsou nyní nejdůležitější, protože v dnešní době berou v úvahu všechny problémy s výkonem a zabezpečením aplikace.
Toto testování má větší dopad na aplikace, pokud jde o výkon aplikace za vysokého uživatelského provozu. Toto testování zajišťuje, že vaše aplikace je stabilní a je schopná zvládnout zatížení v extrémních podmínkách.
Jak samotný název vypovídá, toto testování se soustředí na nefunkční aspekt aplikace. Jaké jsou tedy nefunkční aspekty? Nebo bych měl říci, jaké jsou funkce, které nesouvisejí s funkčností aplikace?
Zde jsou odpovědi na tyto otázky:
- Jak aplikace funguje za normálních okolností?
- Jak se aplikace chová, když se současně přihlašuje příliš mnoho uživatelů?
- Zvládne aplikace stres?
- Jak bezpečná je aplikace?
- Může se aplikace zotavit z nějaké katastrofy?
- Může se aplikace chovat stejným způsobem v jiném prostředí nebo operačním systému?
- Jak snadné je přenést aplikaci do jiného systému?
- Jsou dokumenty / uživatelská příručka dodávané s aplikací snadno srozumitelné?
Seznam stále pokračuje. Jde ale o to - nepřispívají tyto funkce ke kvalitě aplikace? Odpověď je ano. Tyto funkce jsou stejně důležité.
Představte si, že aplikace dokonale splňuje všechny požadavky uživatele, ale nějaký neoprávněný uživatel snadno narazí na data zadaná uživatelem v aplikaci, nebo aplikace zemře, když je nahráno více než 5 BB libovolného souboru. Řekli byste tedy, že aplikace je kvalitní? Zjevně to není správné !!
Účel
Jediným účelem tohoto typu testování je zajistit, aby byly testovány nefunkční aspekty aplikace a aplikace fungovala dobře v kontextu stejného.
Účelem je pokrýt testování všech charakteristik aplikace, které pomáhají poskytovat aplikaci, která splňuje obchodní očekávání.
Příklad
Toto je důležitý typ testování.
Funkční testování testuje funkčnost aplikace a zajišťuje, že funguje podle očekávání, ale nefunkční testování zajišťuje, že aplikace funguje dostatečně dobře, aby splnila obchodní očekávání.
Abychom pochopili jeho důležitost, vezměme si jednoduchý příklad:
Je vyvinuta aplikace, která je kompletně testována na funkčnost, ale nefunkční testování se neprovádí současně.
Mezitím, když bude aplikace spuštěna, může to mít za následek kritické nebo závažné problémy, například když se zvýší zatížení aplikace, bude příliš pomalá a její otevření bude trvat hodně času.
Může se zvýšit doba odezvy nebo pokud se zatížení do určité míry zvýší, může dojít k selhání aplikace. To ukazuje, jak důležité je otestovat nefunkční aspekty aplikace.
Výhody
Níže jsou uvedeny některé výhody nefunkčního testu:
- Pokrývá testování, které nelze zahrnout do funkčního testování.
- Zajišťuje, že aplikace běží efektivně a je dostatečně spolehlivá.
- Zajišťuje bezpečnost aplikace.
Jak zachytit nefunkční požadavky?
Zatímco provádíme testování, zaměřujeme se hlavně na funkční testování, které testuje funkčnost produktu. Nefunkční testování je ale stejně důležité jako funkční testování a jeho požadavek by měl být zohledněn hned od založení produktu.
K provedení nefunkčního testování se používají nefunkční požadavky. Mezi tyto požadavky patří výstup výkonu, který se očekává od testované aplikace nebo softwaru. To v zásadě zahrnuje čas, který software potřebuje k provozu konkrétního systému.
Nefunkční požadavky také zachycují chování, když software používá velké množství lidí současně. Většinou se setkáváme s tím, že servery jsou zaneprázdněné nebo nedostupné kvůli velkému zatížení (tj. Více lidí je používá současně). Rezervace online železničních jízdenek může být nejlepší příklad takové situace.
Správné zdokumentování nefunkčního požadavku a správné provedení testování tedy zajistí vysokou spokojenost potenciálních zákazníků z hlediska použitelnosti.
Ačkoli toto testování nemá přímý obchodní dopad na funkčnost systému, může ve větší míře zvýšit uživatelský komfort a uživatelskou přívětivost, což zase bude mít větší dopad na kvalitu softwaru.
Příklad:
Zvažte stejný příklad přihlašovací stránky na Facebooku. V tomto případě je rozsahem nefunkčního testování zaznamenat čas potřebný pro přihlášení do Facebooku po zadání platných pověření.
Lze jej také otestovat, když se uživatelé (řekněme 100) přihlásí současně, kolik času zabere přihlášení uživatele na Facebooku.
Tím je zajištěno, že systém zvládne zatížení a provoz, což má zase dobrý uživatelský dojem.
V agile by měl být nefunkční požadavek zachycen pomocí vstupů.
Nefunkční požadavek by měl být zachycen jako:
- Uživatelské / technické příběhy
- V kritériu přijetí
- V artefaktu
9
# 1) Uživatelské / technické příběhy
Nefunkční požadavek lze zachytit pomocí uživatelské příběhy nebo technické příběhy. Zachycení nefunkčních požadavků jako uživatelského příběhu je stejné jako zachycení jakéhokoli jiného požadavku. Jediným rozdílem v uživatelském a technickém příběhu je, že uživatelský příběh vyžaduje diskusi a má viditelnost.
# 2) Kritéria přijetí
Kritéria přijatelnosti je bod, který je definován pro přijetí produktu zákazníkem, tj. aby produkt byl přijat do definovaných bodů, by měl být ve stavu pass.
Nefunkční požadavek by měl být zahrnut do kritérií přijetí, ale někdy není možné testovat nefunkční požadavky s každým příběhem, tj. S každou iterací. Proto by požadavky měly být přidávány nebo testovány pouze s příslušnou iterací.
# 3) V artefaktech
Pro nefunkční požadavky by měl být připraven samostatný artefakt, což by zase pomohlo získat lepší představu o tom, co je třeba testovat a jak to lze provést v iteracích.
Rozdíl ve funkčních a nefunkčních požadavcích
Existuje několik rozdílů mezi funkčními a nefunkčními požadavky a několik z nich je uvedeno níže:
Č. | Funkční požadavek | Nefunkční požadavek |
---|---|---|
Výkon | Testery výkonu pomocí nástroje, který považuje operaci za transakci provedenou určitým počtem souběžných uživatelů, zatímco tester analyzuje veškerou logistiku | Doba odezvy |
1 | Funkční požadavek je založen na zákazníkovi. | Nefunkční požadavek je založen na vývojářích a technických znalostech týmu. |
dva | Funkční požadavek specifikuje, které funkce je třeba vzít v úvahu, tj. Co je třeba testovat. | Nefunkční požadavky určují, jak je třeba jej otestovat. |
3 | Funkční testování se provádí před spuštěním aplikace. | Nefunkční požadavky zahrnují testování údržby, testování dokumentace, které se nevyžadují, když probíhá provádění, ale jedna, která byla spuštěna. |
4 | Je známý pouze jako funkční požadavek. | Také známý jako požadavky na kvalitu. |
5 | Plán implementace funkčních požadavků je definován v dokumentu návrhu systému. | Plán implementace nefunkčního požadavku je definován v architektuře systému. |
6 | Funkční požadavek zahrnuje testování technické funkčnosti systému. | Nefunkční požadavek zahrnuje vlastnosti jako zabezpečení, použitelnost atd. |
Další čtení => Rozdíly mezi funkčním a nefunkčním testováním
Testuje se tato černá skříňka nebo bílá skříňka?
Nefunkční test spadá pod a testování černé skříňky technika.
Tato technika se neomezuje pouze na testování funkčnosti, ale lze ji také použít k testování nefunkčních požadavků, stejně jako výkonu, použitelnosti atd. Technika testování černé skříňky nevyžaduje žádné znalosti interního systému, tj. Nevyžaduje znalost kódu pro testera.
Kontrolní seznam nefunkčních testovacích případů
Kontrolní seznam se používá k zajištění toho, že bez testování nezůstane žádný důležitý aspekt.
Kontrolní seznam se obvykle používá, když není čas na dokumentaci a produkt musí být testován, nebo pokud existuje časové omezení, lze použít kontrolní seznam, který zajistí, že byly pokryty všechny důležité aspekty.
Podívejme sepříkladKontrolní seznam testování výkonu, bezpečnosti a dokumentace.
Kontrolní seznam pro testování výkonu
- Doba odezvy aplikace by měl být ověřen, tj. jak dlouho trvá načtení aplikace, jakýkoli vstup daný aplikaci poskytuje výstup za kolik času, obnovení prohlížeče atd.
- Propustnost by měl být ověřen na počet transakcí dokončených během zátěžového testu.
- životní prostředí nastavení by mělo být stejné jako živé prostředí, jinak by výsledky nebyly stejné.
- Čas zpracování - Procesní činnosti, jako je import a export aplikace Excel, by měly být otestovány všechny výpočty v aplikaci.
- Interoperabilita by měl být ověřen, tj. software by měl být schopen spolupracovat s jiným softwarem nebo systémy.
- ETL čas by měl být ověřen, tj. čas potřebný k extrakci, transformaci a načtení dat z jedné databáze do druhé.
- Zvyšující se zatížení na aplikaci by měla být ověřena.
Kontrolní seznam pro testování zabezpečení
- Ověření: K přihlášení by měl mít přístup pouze autentický uživatel.
- Autorizovaný: Uživatel by měl být schopen se přihlásit do těch modulů, ke kterým má oprávnění nebo ke kterým má uživatel přístup.
- Heslo: Požadavek na heslo by měl být ověřen, tj. Heslo by mělo odpovídat tomu, jak požadavek definuje, tj. Délku, speciální znaky, čísla atd.
- Časový limit: Pokud je aplikace neaktivní, měla by vypršet časový limit v zadaném čase.
- Zálohování dat: Zálohování dat by mělo být provedeno ve stanovenou dobu a mělo by být zkopírováno na zabezpečené místo.
- Interní odkazy k webové aplikaci by neměl být přístupný, pokud je umístěn přímo v prohlížeči.
- Veškerá komunikace by měla být šifrována.
Kontrolní seznam pro testování dokumentace
- Uživatelská a systémová dokumentace.
- Dokumenty pro účely školení.
Přístupový dokument
Vytvořte dokument specifického přístupu pro fázi Testování výkonu vylepšením celkové strategie testování. Tento testovací přístup vede při plánování a provádění všech úkolů testu výkonu.
online zálohovací software pro poskytovatele služeb
- Rozsah zkoušky
- Testovací metriky
- Testovací nástroje
- Klíčové termíny a výsledky
Rozsah zkoušky
Provádějte testování výkonu z různých úhlů pohledu, jako je výkon uživatele, obchodní procesy, stabilita systému, spotřeba zdrojů atd. Druhy provádění testování výkonu jsou popsány ve výše uvedené části článku (například zátěžový test, zátěžový test atd.)
Testovací metriky
Přístup Test zpřesňuje metriky, které se mají měřit a vykazovat během testování, například:
- Doba odezvy (online)
- Dávkové okno (dávka)
- Propustnost ( Například , počet transakcí za jednotku času)
- Využití ( Například , procento použitých zdrojů)
Testovací nástroje
Testování výkonu většinou vyžaduje použití příslušných nástrojů:
- Nástroje pro generování zatížení
- Nástroje pro sledování výkonu
- Nástroje pro analýzu výkonu
- Nástroje pro profilování aplikací
- Nástroje pro obložení základny.
Klíčové termíny a výsledky
Dokument Přístup k testu výkonu by měl popisovat následující:
- Datum a čas každého provedení testu výkonu.
- Typy testů a kombinace funkcí, které mají být zahrnuty do každého provedení testu výkonu.
- Data dokončení testu výkonu.
Nefunkční typy testování
Následující obrázek znázorňuje typy nefunkčního testování:
Testování výkonu:
Vyhodnocuje celkový výkon systému .
Klíčové prvky jsou následující:
- Ověří, že systém splňuje očekávanou dobu odezvy.
- Vyhodnocuje, že významné prvky aplikace splňují požadovaný čas odezvy.
- Může být také prováděno jako součást testování integrace a testování systému.
Testování zátěže:
Vyhodnocuje, zda je výkon systému podle očekávání za normálních a očekávaných podmínek.
Klíčové body jsou:
- Ověřuje, že systém funguje podle očekávání, když souběžní uživatelé přistupují k aplikaci a získávají očekávanou dobu odezvy.
- Tento test se opakuje s více uživateli, aby se získala doba odezvy a propustnost.
- V době testování by databáze měla být realistická.
- Test by měl být proveden na dedikovaném serveru, který stimuluje skutečné prostředí.
Stresové testování:
Vyhodnocuje, zda je výkon systému podle očekávání, když má málo zdrojů.
Klíčové body jsou:
- Otestujte nedostatek paměti nebo nedostatek místa na disku na klientech / serverech, které odhalí vady, které nelze za normálních podmínek najít.
- Více uživatelů provádí stejné transakce se stejnými daty.
- K serverům je připojeno více klientů s různými úlohami.
- Zkraťte dobu pro přemýšlení na „nulu“, abyste servery namáhali na maximum.
Think Time: Stejně jako časový interval mezi zadáním uživatele a hesla.
Testování hlasitosti:
Vyhodnocuje chování softwaru, pokud jde o velké množství dat.
Klíčové body jsou:
- Pokud software podléhá velkému množství dat, zkontroluje limit, kde software selže.
- Vytvoří se maximální velikost databáze a více klientů se bude dotazovat na databázi nebo vytvoří větší sestavu.
- Příklad - Pokud aplikace zpracovává databázi za účelem vytvoření sestavy, testem objemu by bylo použití velké sady výsledků a kontrola, zda je sestava vytištěna správně.
Testování použitelnosti:
Vyhodnocuje systém pro lidské použití nebo kontroluje, zda je vhodný pro použití.
Klíčové body jsou:
- Je výstup správný a smysluplný a je stejný, jaký se očekával podle podnikání?
- Jsou chyby diagnostikovány správně?
- Je GUI správné a v souladu se standardem?
- Je aplikace snadno použitelná?
Testování uživatelského rozhraní:
Vyhodnocuje GUI.
Klíčové body jsou:
- GUI by mělo poskytovat nápovědu a popisy nástrojů, aby bylo jeho použití snadné.
- Konzistentní pro svůj vzhled?
- Data jsou správně procházena z jedné stránky na druhou?
- GUI by nemělo uživatele otravovat nebo mu být obtížné porozumět.
Testování kompatibility:
Vyhodnocuje, zda je aplikace kompatibilní s jiným hardwarem / softwarem s minimální a maximální konfigurací.
Klíčové body jsou:
- Vyzkoušejte každý hardware s minimální a maximální konfigurací.
- Otestujte pomocí různých prohlížečů.
Testovací případy jsou stejné jako ty, které byly provedeny během funkčního testování. - V případě, že je hardware a software příliš mnoho, můžeme pomocí technik OATS dospět k testovacím případům, abychom měli maximální pokrytí.
Testování obnovy:
Vyhodnocuje, že aplikace se řádně ukončí v případě jakéhokoli selhání a data se odpovídajícím způsobem obnoví z případných selhání hardwaru a softwaru.
Testy se neomezují pouze na níže uvedené body:
- Přerušení napájení klientovi při provádění CURD aktivit.
- Neplatné ukazatele a klíče databáze.
- Proces databáze je přerušen nebo předčasně ukončen.
- Ukazatele, pole a klíče databáze jsou poškozeny ručně a přímo v databázi.
- Fyzicky odpojte komunikaci, vypněte napájení, vypněte směrovače a síťové servery.
Testování nestability:
Vyhodnocuje a potvrzuje, zda se software nainstaluje a odinstaluje správně.
jak otevřít soubor shockwave flash
Klíčové body jsou:
- Ověřuje, že jsou součásti systému správně nainstalovány na určený hardware.
- Ověří, že navigace na novém počítači aktualizuje stávající instalaci a starší verze.
- Potvrzuje, že s nedostatečným prostorem na disku není žádné nepřijatelné chování.
Testování dokumentace:
Vyhodnocuje dokumenty a další uživatelské příručky.
Mezi klíčové body patří:
- Ověří, že uvedené dokumenty jsou v produktu k dispozici.
- Validuje všechny uživatelské příručky, nastavuje pokyny, čte mi soubory, poznámky k vydání a online nápovědu.
Testování převzetí služeb při selhání:
Testování převzetí služeb při selhání se provádí za účelem ověření, že v případě selhání systému je systém dostatečně schopný zpracovat další zdroje, jako jsou servery.
Aby se takové situaci předešlo, hraje velkou roli testování zálohování. Celý proces spočívá v vytvoření záložního systému. Pokud je k dispozici záloha, pomůže to získat systém zpět.
Testování zabezpečení:
Testování zabezpečení je zajištěno, že aplikace nemá žádné mezery, které by mohly vést ke ztrátě nebo ohrožení dat. Je to jeden z důležitých aspektů nefunkčního testování a pokud nebude správně proveden, může vést k bezpečnostním hrozbám.
Zahrnuje testování ověřování, autorizace, integrity a dostupnosti.
Testování škálovatelnosti:
Provádí se testování škálovatelnosti, aby se ověřilo, zda je aplikace dostatečně schopná zvládnout zvýšený provoz, počet transakcí, objem dat atd. Systém by měl fungovat podle očekávání, když se provede objem dat nebo změna velikosti dat.
Testování shody:
Testování shody se provádí za účelem ověření, zda jsou dodržovány definované standardy či nikoli. Audity se provádějí k ověření toho samého.
Pro Příklad , Audity se provádějí za účelem ověření procesu vytváření testovacích případů / testovacích plánů a jejich umisťování na sdílené místo se standardním názvem, který se právě provádí nebo ne. V QC se při pojmenovávání testovacích případů používá standardní název testovacího případu. Dokumentace je úplná a schválená či nikoli.
Toto je několik ukazatelů, které jsou zahrnuty při auditu.
Testování vytrvalosti:
Testování vytrvalosti provádí se k ověření chování systému při dlouhodobém zvyšování zátěže.
Nazývá se také jako testování namočení a testování kapacity. Pomáhá ověřit, zda v systému nedochází k úniku paměti. Vytrvalostní testování je podmnožinou zátěžového testování.
Testování lokalizace:
Testování lokalizace provádí se ověření aplikace v různých jazycích, tj. v různých národních prostředích. Aplikace by měla být ověřena pro konkrétní kulturu nebo národní prostředí. Hlavním zaměřením je testování obsahu, GUI aplikace.
Testování internacionalizace:
Testování internacionalizace je také známý jako testování i18n.
I18n představuje I - osmnáct písmen - N. Provádí se ověření, zda aplikace ve všech jazykových nastaveních funguje očekávaným způsobem. Ověřuje, že se žádná funkce nebo aplikace sama nerozbije, tj. Aplikace by měla být dostatečně schopná zvládnout všechna mezinárodní nastavení.
Také ověří, že se aplikace nainstaluje bez problémů.
Testování spolehlivosti:
Testování spolehlivosti se provádí za účelem ověření, zda je aplikace spolehlivá a je testována po určitou dobu v definovaném prostředí. Aplikace by měla pokaždé poskytnout stejný výstup, jak se očekávalo, pouze tehdy ji lze považovat za spolehlivou.
Testování přenositelnosti:
Testování přenositelnosti se provádí za účelem ověření, zda v případě, že je software / aplikace nainstalována v jiném systému nebo na jiné platformě, měl by být schopen běžet podle očekávání, tj. Kvůli změně prostředí by nemělo být ovlivněno žádné fungování.
Během testování je také nutné otestovat změnu s hardwarovou konfigurací, jako je místo na pevném disku, procesor, a také s různými operačními systémy, aby bylo zajištěno, že správné chování aplikace a očekávané funkce budou zachovány.
Základní testování:
Základní testování je také známé jako srovnávací testování protože vytváří základ pro každou novou aplikaci, která má být testována.
Například: V první iteraci byla doba odezvy pro aplikaci 3 sekundy. Nyní to bylo nastaveno jako měřítko pro další iteraci a v další iteraci se doba odezvy změní na 2 sekundy. Je to v podstatě validační dokument, který se používá jako základ pro budoucí reference.
Testování účinnosti:
Testování účinnosti se provádí za účelem ověření, zda aplikace funguje efektivně a počet požadovaných zdrojů, požadované nástroje, složitost, požadavek zákazníka, požadované prostředí, čas, o jaký projekt se jedná, atd.
Toto jsou některé z ukazatelů, které by pomohly definovat, jak efektivně by aplikace fungovala, kdyby všechny uvažované parametry fungovaly podle očekávání.
Testování zotavení po katastrofě:
Toto testování se provádí za účelem ověření úspěšnosti obnovy aplikace nebo systému, pokud dojde ke kritickému selhání, a zda je systém schopen obnovit data a aplikaci, nebo se systém dokáže snadno vyrovnat a vrátit se tak, jak fungoval dříve, tj. Z operační front.
Testování udržovatelnosti:
Jakmile bude aplikace / produkt spuštěna, pak existuje šance, že se problém objeví v živém prostředí, nebo může zákazník chtít vylepšení aplikace, která je již aktivní.
V tomto případě je k dispozici tým pro testování údržby, který otestuje výše uvedené scénáře. Jakmile je aplikace spuštěna, stále potřebuje údržbu, pro kterou tým údržby pracuje.
Nefunkční testovací nástroje
Na trhu je k dispozici několik nástrojů pro testování výkonu (zátěž a stres).
Několik z nich je uvedeno níže:
- JMeter
- Loadster
- Loadrunner
- Loadstorm
- Neoload
- Předpověď
- Načtení dokončeno
- Stresový nástroj webového serveru
- WebLoad Professional
- Loadtracer
- vPerformer
Provádí se nefunkční testování vždy bez dokumentace a testovacích případů? Proč?
'Vždy nás učí, jak psát funkční testovací případy.' Proč? Provádí se „nefunkční testování“ bez dokumentace (jinými slovy ad hoc) nebo jde o samostatný proces, kterému je mnohem obtížnější porozumět? Jak jsou psány testovací případy pro různé druhy testování, ke kterým v aplikaci dochází? “
Toto je jedna z nejoriginálnějších, nejosobitějších a nejpoužívanějších otázek, které mi byly v poslední době kladeny. Pojďme najít odpověď.
Jak to, že nikdy nebudeme vidět a trénovat psaní nefunkčních testovacích případů?
Začněme tím, co víme, a jako vždy praktickým scénářem.
Příklad: Následují kroky, které je třeba provést v aplikaci Online bankovnictví za účelem provedení převodu. Použijme to jako náš test pro referenci.
- Přihlaste se na web.
- Vyberte bankovní účet.
- Vyberte příjemce (tento příjemce může patřit do stejné banky nebo do jiné banky - záleží na vašem výběru údajů k provedení tohoto kroku. V každém případě si vyberte jednoho. Předpokládáme také, že příjemce je již přidán.) .
- Zadejte částku, která má být převedena (kladná hodnota, v rámci limitu, správný formát atd.).
- Klikněte na Převést a zkontrolujte, zda je potvrzeno, zůstatek na účtu byl aktualizován a tak dále.
Toto je funkční testovací případ, správně?
Ve stejné aplikaci na stejné stránce převodů řekněme, že provádíme výkon Testování výkonu, bezpečnosti a použitelnosti . Jedná se o nefunkční typy, správně?
Jak bychom psali testovací případy?
# 1) Testování použitelnosti Testovací případy
Testování použitelnosti je žánr testování softwaru, který se zabývá uživatelskou zkušeností. To jsou některé z otázek, na které se snažíme odpovědět.
- Jak snadné je použití aplikace?
- Jak uspokojivá je zkušenost s používáním systému?
- Pokud ne hned tak známé, jak snadné je se to naučit?
Více informací najdete zde: Průvodce testováním použitelnosti
Jak by uživatel určil odpovědi na výše uvedené otázky v kontextu testování použitelnosti?
Uživatel by provedl přesně stejné kroky jako v případě funkčního testu. Mám pravdu?
# 2) Testování výkonu Testovací případy
Existuje několik variant testování výkonu, ale v jádru se používá k získání statistik o systému, jeho využití zdrojů, době odezvy, spotřebě sítě atd. V různých bodech zatížení.
Podívejte se na naše Výukové programy pro testování výkonu vědět o tom víc.
Pokud bych teď měl otestovat výkonnost transakce, měl bych 10, 20, 30, 100 ... 1000… atd., Aby uživatelé prováděli operaci přenosu současně nebo postupně podle toho, na co chci cílit a shromáždit data.
Jaké kroky by každý uživatel provedl, aby mohl použít přenos, zatímco probíhá test výkonu?
Stejné přesné kroky jako funkční test, správně?
# 3) Testovací případy testování zabezpečení
Testování zabezpečení je odvětví QA, které pomáhá zajistit, aby softwarové systémy byly chráněny před hackery. Identifikuje zranitelná místa (potenciální problémové oblasti v softwarovém systému), využívá je pomocí techniky penetrace nebo testování bílého klobouku, a když jsou nalezeny smyčky, je na nich zapracováno.
Kdy chci zkontrolovat, zda jsou přenosy odolné proti hackerům a zda jsou správně směrovány na zamýšlené příjemce a zda v celém procesu nejsou žádné černé skvrny? Provedl bych přenos, zatímco proces monitorování úniků zabezpečení probíhá paralelně.
Ve skutečnosti tedy provádím přesně stejné kroky, jaké bych normálně udělal v případě funkčního testovacího případu.
Myslím, že máme dost na to, abychom dokázali, že kroky ve všech situacích jsou stejné. Metoda a záměr procesu jsou různé.
Pojďme se srovnávat:
Typ testování | SZO? | Proč? Záměr |
---|---|---|
Funkční testování | QA testeři | Přesnost |
Účinnost | ||
Obchodní použitelnost | ||
Použitelnost | QA testeři nebo uživatelé v reálném čase | Snadnost použití |
Snadné učení | ||
Účinnost | ||
Využití sítě atd. | ||
Bezpečnostní | Nástroje pro skenování a další monitorovací systém specializovanými bezpečnostními odborníky | Hackujte bezpečně |
Ochrana totožnosti příjemce a plátce atd. |
Zajímavé je, že bez ohledu na to, jakou formu testování chceme provést, všechny kroky jsou stejné .
Skutečný rozdíl je v tom, že:
- Kdo tyto kroky provádí?
- Jaký je záměr, nebo jinými slovy, čeho se tímto testem snažím dosáhnout?
- Použité nástroje a techniky.
Když se vrátíme k naší otázce, proč se nikdy nenaučíme psát nefunkční testovací případy se všemi podrobnými kroky, které k tomu existují?
To je Protože ,v jejich samotném jádru jsou testovací kroky pro variaci na typy testů u určité funkce stejné, funkční nebo ne. Rozdíl je způsoben záměrem a možná i metodou.
Závěr
Před provedením nefunkčního testování je nezbytné správně naplánovat strategii testování, aby bylo zajištěno správné testování. Na trhu jsou k dispozici různé nástroje k provádění tohoto typu testů, jako je Load Runner, RPT atd.
Toto testování hraje hlavní roli v úspěchu aplikace a při budování dobrého vztahu se zákazníkem, a proto by nemělo být opomíjeno. Toto je jedna z důležitých částí testování softwaru a testování bez něj nelze považovat za úplné.
Do plánu testování můžeme zahrnout nefunkční podrobnosti testování nebo pro něj můžeme vytvořit samostatnou strategii. V obou případech je cílem mít správné pokrytí nefunkčních aspektů softwaru.
Doufáme, že tento proces ponoření se do tohoto tématu byl pro vás stejně zábavný, jako byl představen vám všem. Rádi bychom slyšeli vaši zpětnou vazbu a myšlenky na toto téma.
Jak zvládáte nefunkční testování ve svých týmech? A jako vždy, dejte nám vědět, pokud souhlasíte, nesouhlasíte nebo máte co dodat k tomu, co se tu děje.
Doporučené čtení
- Funkční testování vs. nefunkční testování
- Alfa testování a beta testování (kompletní průvodce)
- Průvodce testováním zabezpečení webových aplikací
- Kompletní průvodce funkčním testováním s jeho typy a příklady
- Kompletní průvodce pro testování ověřování sestavení (testování BVT)
- Nejlepší nástroje pro testování softwaru 2021 [QA Test Automation Tools]
- Průvodce pro začátečníky k testování penetrace webových aplikací
- Load Testing Kompletní průvodce pro začátečníky