Menu

Výukový program pro testování hlasitosti: Příklady a nástroje pro testování hlasitosti

  • Hlavní
  • Jiný
  • Výukový program pro testování hlasitosti: Příklady a nástroje pro testování hlasitosti

volume testing tutorial

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Přehled testování objemu:

Souvisí níže uvedený obrázek nějakým způsobem s našimi aplikacemi? Ano, přesně to se stane, když přetížíme naše servery, databáze, webové služby atd.

Každý z nás si musí být vědom funkční a nefunkční testování, ale pamatujete na skutečnost, že nefunkční testování je stejně důležité jako funkční testování? Někdy v krátkých verzích máme tendenci ignorovat toto nefunkční testování, což bychom v ideálním případě neměli.

Nemělo by nám záležet na tom, zda vlastník produktu dal tento požadavek nebo ne. Toto testování bychom měli považovat za součást našeho kompletního testovacího procesu i pro malá vydání.

Testování hlasitosti

Tento výukový program pro testování svazků vám poskytne kompletní přehled o jeho významu, potřebě, důležitosti, kontrolním seznamu a některých jeho nástrojích, abyste mu mohli lépe porozumět.

Co se naučíte:

Co je to testování hlasitosti?

Volume Testing je typ nefunkčního testování. Toto testování se provádí za účelem kontroly objemu dat zpracovaného databází. Testování objemu, které se také nazývá testování záplav, je nefunkční testování, které se provádí za účelem kontroly výkonu softwaru nebo aplikace proti obrovským datům databáze.

Databáze se natáhne na prahový bod přidáním velkého množství dat a poté se systém otestuje na odpověď.

Toto byla teoretická část, dovolte mi vysvětlit vám několik praktických příkladů, které vám pomohou pochopit 'když' část objemového testování.

Kdy je toto testování imperativní?

V ideálním případě by měl být každý software nebo aplikace testován na objem dat, ale v některých případech, kdy data nebudou velká, máme tendenci se tomuto testování vyhnout. Ale v některých případech, kdy jsou data zpracovávána v MB nebo GB na denní bázi, pak by rozhodně měl být proveden objemový test.

Následuje několik příkladů z mé vlastní 8leté zkušenosti, které vysvětlují část „kdy“:

Příklad 1:

Jedním z mých podniků byl velký systém, který se skládal z webové i mobilní aplikace. Samotná webová aplikace však měla 3 moduly obsluhované 3 různými týmy.

Někdy, dokonce iu nás, se databáze zpomalovala, když jsme všichni „společně“ přidávali data pro naše testování. Bylo to otravné a práce zvyklá být omezována kvůli velkému objemu dat a pro usnadnění práce jsme museli poměrně často uklízet DB.

Data, která „živý“ systém zpracovával, byla kolem GB, takže ve srovnání s mobilní aplikací byla webová aplikace velmi často testována na objem dat. Týmy QA webové aplikace měly své vlastní automatizační skripty, které běžely v noci a prováděly toto testování.

Příklad 2:

Dalším příkladem mého podniku byl ekosystém, který měl nejen webovou aplikaci, ale také aplikaci SharePoint a dokonce i instalační program. Všechny tyto systémy komunikovaly do stejné databáze pro datové přenosy. Data zpracovaná tímto systémem byla také velmi obrovská a pokud by se DB z nějakého důvodu zpomalil, i instalační program by přestal fungovat.

Z tohoto důvodu byl objemový test prováděn pravidelně a výkon databáze byl pozorován každou minutu kvůli jakýmkoli problémům.

Podobně, můžeme vzítPříkladyněkolika aplikací, které denně používáme k nakupování, rezervaci letenek, finančních transakcí atd., které se zabývají těžkými datovými transakcemi, a proto potřebují test objemu.

Na druhé straně nemusí být vždy možné dosáhnout ideálního testování objemu, protože má svá vlastní omezení a výzvy.

Několik jeho omezení a výzev zahrnuje:

  • Je obtížné vytvořit přesnou fragmentaci paměti.
  • Dynamické generování klíčů je složité.
  • Vytvoření ideálního reálného prostředí, tj. Repliky živého serveru, může být obtížné.
  • Na výsledky testu mají vliv také nástroje pro automatizaci, síť atd.

Nyní jsme to pochopili když musíme provést tento typ testování. Pojďme to také pochopit 'proč' měli bychom toto testování provádět jako v rámci cíle nebo cíle provádění tohoto testování.

Proč bych se měl zaměřit na testování objemu?

Připojená data

Testování hlasitosti vám pomůže pochopit, jak je váš systém vhodný pro skutečný svět, a také vám pomůže ušetřit peníze, které budou později vynaloženy na účely údržby.

Následuje několik možných důvodů pro provedení tohoto testování:

  • Nejzákladnější potřebou je analyzovat výkon vašeho systému s ohledem na vyšší objem dat. Vytvoření obrovského objemu dat vám pomůže pochopit výkon vašeho systému z hlediska doby odezvy, ztráty dat atd.
  • Identifikujte problémy, které nastanou u obrovských dat a prahového bodu.
  • Za udržitelným nebo prahovým bodem chování systému, tj. Pokud dojde k chybě databáze, přestane reagovat nebo vyprší časový limit.
  • Implementace řešení přetížení DB a dokonce jejich ověření.
  • Zjištění extrémního bodu vaší databáze (který nelze opravit), za kterým systém selže, a proto je třeba přijmout preventivní opatření.
  • V případě více než jednoho serveru DB, zjištění problémů s komunikací DB, tj. Nejzranitelnějších z nich atd.

Nyní víme důležitost a důvod pro provedení tohoto testování.

NEBO Ne zkušenost, o kterou bych se rád podělil, spočívá v tom, že pokud jde o mobilní aplikace, nemusí být testování objemu potřeba, protože aplikaci používá vždy jen jedna osoba a mobilní aplikace jsou navrženy tak, aby byly jednoduché .

Takže pokud nemáte velmi složitou aplikaci se spoustou zapojení dat, testování objemu lze přeskočit.

Jakmile víte, co je třeba pro váš systém nebo aplikaci ověřit, je třeba udělat kontrolní seznam, který aplikace definuje 'co' je třeba otestovat.

Jaký je můj kontrolní seznam pro toto testování?

Kontrolní seznam

Než vstoupíme do několika příkladů pro vytvoření kontrolního seznamu pro vaši aplikaci nebo systém, nejprve pochopíme několik ukazatelů, které je třeba mít na paměti při vytváření kontrolního seznamu pro testování objemu nebo přístupu před zahájením testování.

Body k zapamatování:

  • Udržujte vývojářům přehled o vašem plánu testování, protože vědí hodně o systému a mohou vám poskytnout vstupy a dokonce i úzká místa.
  • Před strategizací testování pochopte fyzický aspekt jako v konfiguracích serveru, RAM, procesoru atd.
  • Pochopte složitost databáze, postupů, skriptů databáze atd. V možné míře, abyste mohli popsat složitost vašeho systému jako celek.
  • Připravte si informatiku, tj. Grafy, datový list atd., Pokud je to možné pro normální objem dat a jak dobrý je systém, pomůže vám to ujistit se, že než zdůrazníte DB, je výkon v pořádku pro normální zatížení dat. To vám také pomůže zajistit, než se přesunete k namáhané části, že neexistují žádné problémy, které by vyžadovaly opravu vašeho testu objemu.

Následuje několik příkladů, které můžete přidat nebo použít ve svém kontrolním seznamu:

  • Zkontrolujte správnost metod ukládání dat.
  • Zkontrolujte, zda má systém potřebné paměťové zdroje nebo ne.
  • Zkontrolujte, zda existuje riziko, že objem dat přesáhne stanovený limit.
  • Zkontrolujte a sledujte reakci systému na objem dat.
  • Zkontrolujte, zda se během testování objemu data neztrácejí.
  • Zkontrolujte, zda jsou data přepsána, a to pomocí předběžných informací.
  • Určete oblasti, které přesahují normální rozsah, jako mnoho atributů (prohledávatelných), obrovské číslo. vyhledávacích tabulek, mnoho mapování umístění atd.
  • Jak již bylo zmíněno dříve, nejprve vytvořte základní linii získáním výsledků pro normální objem a poté pokračujte se stresem.

Než přejdeme k dalším příkladům, testovacím případům a nástrojům, nejprve pochopíme, jak se toto testování liší od testování zátěže.

Testování objemu vs. Testování zatížení

Níže uvádíme některé hlavní rozdíly mezi testováním hlasitosti a zatížení:


Č.		Testování hlasitostiTestování zátěže
1Testování objemu se provádí za účelem ověření výkonu databáze oproti velkému objemu dat v databázi.Zátěžové testování se provádí změnou uživatelského načtení prostředků a ověřením výkonu prostředků.
dvaToto testování se primárně zaměřuje na „data“.Primární zaměření tohoto testování je na „uživatele“.
3Databáze je namáhána na maximální limit.Server je namáhán na maximální limit.
4Jednoduchým příkladem může být vytvoření souboru velké velikosti.Jednoduchým příkladem může být vytvoření velkého počtu souborů.

Jak provést toto testování?

Testování databáze

Toto testování lze provést ručně nebo pomocí libovolného nástroje. Obecně použití nástrojů ušetří náš čas a úsilí, ale v případě objemového testu, podle mých zkušeností používání nástrojů vám může poskytnout přesnější výsledky ve srovnání s manuálním testováním.

Před zahájením provádění testovacího případu se ujistěte, že:

  • Tým souhlasil s plánem testování tohoto testování.
  • Ostatní týmy vašeho projektu jsou dobře informovány o změnách databáze a jejich dopadu na jejich práci.
  • Testovací postele jsou nastaveny pro zadané konfigurace.
  • Základní linie pro testování je připravena.
  • Konkrétní objemy dat pro testování (datové skripty nebo postupy atd.) Jsou připraveny. O nástrojích pro vytváření dat si můžete přečíst na naší stránce generování dat.

Podívejme se na několik ukázkových testovacích případů, které můžete použít při provádění:

Ověřte to pro všechny vybrané objemy dat pro testování svazku:

  1. Ověřte, zda lze úspěšně přidávat data a zda se odrážejí v aplikaci nebo na webu.
  2. Ověřte, zda lze mazání dat úspěšně provést a zda se projeví v aplikaci nebo na webu.
  3. Ověřte, zda lze úspěšně aktualizovat data a zda se odrážejí v aplikaci nebo na webu.
  4. Ověřte, že nedochází ke ztrátě dat a všechny informace se v aplikaci nebo na webu zobrazují podle očekávání.
  5. Ověřte, zda aplikace nebo webové stránky nevyprší kvůli vysokému objemu dat.
  6. Ověřte, zda se chyby zhroucení nezobrazují kvůli vysokému objemu dat.
  7. Ověřte, že data nejsou přepsána a jsou zobrazena příslušná varování.
  8. Ověřte, zda jiné moduly vašeho webu nebo aplikace neprocházejí nebo nevyprší čas s velkým objemem dat.
  9. Ověřte, že doba odezvy DB je v přijatelném rozsahu.

Nástroje pro testování hlasitosti

Automatizační nástroje

Jak již bylo zmíněno dříve, testování automatizace šetří čas a dokonce poskytuje přesné výsledky ve srovnání s manuálním testováním. Další výhodou použití nástrojů pro testování svazků je, že můžeme testy spouštět v noci, a objem dat v databázi tak nebude ovlivněn na práci ostatních týmů nebo členů týmu.

Můžeme naplánovat testy na ráno a výsledky budou hotové.

Následuje seznam několika nástrojů pro testování objemu open-source:

# 1) DbFit:

Toto je open-source nástroj, který podporuje vývoj řízený testem.

DbFit testovací rámec je napsán na vrcholu Fitness, testy jsou psány pomocí tabulek a lze je provádět pomocí libovolného nástroje Java IDE nebo CI.

# 2) HammerDb:

HammerDb je také nástroj s otevřeným zdrojovým kódem, který lze automatizovat, používat více vláken a dokonce umožňuje skriptování za běhu. Může pracovat s SQL, Oracle, MYSQL atd.

# 3) JdbcSlim:

JdbcSlim příkazy lze snadno integrovat do Slim Fitness a podporuje všechny databáze, které mají ovladač JDBC. Důraz je kladen na vedení konfigurace, testovacích dat a dotazů SQL odděleně.

# 4) NoSQLMap:

Tento je open-source nástroj Python, který je navržen tak, aby automaticky vkládal útoky a narušoval konfigurace DB za účelem analýzy hrozby. Funguje pouze pro MongoDB.

# 5) Ruby-PLSQL-spec:

PLSQL lze testovat na jednotkách pomocí Ruby, protože Oracle je k dispozici jako nástroj s otevřeným zdrojovým kódem. Tento v zásadě používá dvě knihovny: Ruby-PLSQL a Rspec.

Závěr

Testování svazků je nefunkční testování, které se provádí za účelem analýzy výkonu databáze. Lze to provést ručně i pomocí některých nástrojů.

Pokud jste QA, který je v tomto testování nový, navrhuji nejprve hrát s nástrojem nebo nejprve provést některé testovací případy. To vám pomůže pochopit koncept testování objemu, než se pustíte do testování.

jak přidat do pole

Toto testování je docela složité a má své vlastní výzvy, a proto je velmi důležité mít před jeho provedením důkladnou znalost konceptu, vytvoření testovacího lože a jazyka DB.

Doufám, že by vám tento výukový program zvýšil objem znalostí o tomto tématu :)

Doporučené čtení

^