Performance Testing ( angl . Performance Testing ) v softwarovém inženýrství je testování , které se provádí za účelem zjištění, jak rychle počítačový systém nebo jeho část pracuje při určité zátěži . Může také sloužit k testování a ověřování dalších atributů kvality systému, jako je škálovatelnost , spolehlivost a spotřeba zdrojů.
Testování výkonu je jednou z nově vznikajících oblastí výkonového inženýrství v informatice , která se snaží zvažovat výkon ve fázi modelování a návrhu systému, než začne hlavní fáze kódování .
Při testování výkonu se rozlišují následující oblasti:
Existují dva přístupy k testování výkonu softwaru [1] :
Zátěžové testování je nejjednodušší formou testování výkonu. Zátěžové testování se obvykle provádí za účelem vyhodnocení chování aplikace při daném očekávaném zatížení. Touto zátěží může být například očekávaný počet souběžných uživatelů aplikace provádějících daný počet transakcí za časový interval. Tento typ testování obvykle umožňuje získat dobu odezvy všech nejdůležitějších obchodních transakcí. V případě monitorování databáze, aplikačního serveru , sítě atd. může tento typ testování také identifikovat některá úzká hrdla aplikace.
Zátěžové testování se běžně používá k pochopení limitů propustnosti aplikace. Tento typ testování se provádí za účelem zjištění spolehlivosti systému při extrémním nebo neúměrném zatížení a odpovídá na otázky o dostatečném výkonu systému v případě, že aktuální zatížení vysoce překročí očekávané maximum.
Testování stability se provádí, aby se zajistilo, že aplikace dlouhodobě vydrží očekávanou zátěž. Tento typ testování monitoruje spotřebu paměti aplikace a identifikuje potenciální úniky. Navíc takové testování odhalí degradaci výkonu, která se projevuje snížením rychlosti zpracování informací a/nebo zvýšením doby odezvy aplikace po delším běhu oproti začátku testu.
Testování konfigurace je dalším typem tradičního testování výkonu. V tomto případě se místo testování výkonu systému z hlediska aplikovaného zatížení testuje dopad změn konfigurace na výkon. Dobrým příkladem takového testování by bylo experimentování s různými metodami vyvažování zátěže. Testování konfigurace lze také kombinovat s testováním zátěže, zátěže nebo stability.
V obecných případech může testování výkonu sloužit různým účelům.
Mnoho výkonnostních testů se provádí bez jakéhokoli pokusu o pochopení jejich skutečného účelu. Před zahájením testování by měla být vždy položena obchodní otázka: „Jaký je cíl, který sledujeme testováním výkonu?“. Odpovědi na tuto otázku jsou součástí studie proveditelnosti (nebo obchodního případu ) testování. Cíle se mohou lišit v závislosti na technologii používané aplikací nebo jejím účelu, vždy však zahrnují jeden z následujících:
Pokud jsou koncoví uživatelé aplikace považováni za uživatele přihlašující se do systému jakoukoliv formou, pak je dosažení paralelismu v tomto případě vysoce žádoucí. Podle definice se jedná o maximální počet současně běžících uživatelů aplikace, u kterých se očekává, že aplikace bude v daném okamžiku podporovat. Vzorec chování uživatele může významně ovlivnit schopnost aplikace zpracovávat požadavky paralelně, zvláště pokud to zahrnuje pravidelné přihlašování a odhlašování ze systému.
Pokud konceptem aplikace není pracovat s konkrétními koncovými uživateli, pak bude sledovaný výkonnostní cíl založen na maximální propustnosti nebo počtu transakcí za jednotku času. Dobrým příkladem by v tomto případě bylo procházení webu například na portálu Wikipedie.
Tento koncept je postaven na době odezvy jednoho aplikačního uzlu na požadavek zaslaný jinému. Jednoduchým příkladem je požadavek HTTP 'GET' z prohlížeče pracovní stanice na webový server. Téměř všechny aplikace vyvinuté pro zátěžové testování fungují přesně podle tohoto schématu měření. Někdy má smysl nastavit cíle pro dosažení výkonu v době odezvy serveru ve všech aplikačních uzlech.
Doba zobrazení je jedním z nejobtížnějších konceptů pro aplikace zátěžového testování, protože obecně nepoužívají koncept práce s tím, co se děje na jednotlivých uzlech systému, a omezují se pouze na rozpoznání časového úseku, během kterého nedochází k síťová aktivita. Měření doby zobrazení obecně vyžaduje zahrnutí funkčních testovacích případů do benchmarkových testů, ale většina benchmarkových aplikací tuto schopnost neobsahuje.
Je velmi důležité podrobně popsat požadavky na výkon a zdokumentovat je v nějakém plánu testování výkonu. V ideálním případě se to provádí během fáze vývoje požadavků na vývoj systému, než jsou vypracovány detaily návrhu. Viz výkonnostní inženýrství .
Testování výkonu se však často neprovádí podle specifikace, protože neexistuje žádná pevná představa o maximální době odezvy pro daný počet uživatelů. Testování výkonu se často používá jako součást procesu profilování výkonu. Jeho myšlenkou je najít „slabý článek“ – takovou část systému, jejíž optimalizací reakční doby můžete zlepšit celkový výkon systému. Určit, která část systému se nachází na této kritické cestě, je někdy velmi obtížný úkol, takže některé testovací aplikace obsahují (nebo je lze přidat pomocí doplňků) nástroje běžící na serveru (agenti), kteří sledují dobu provádění transakcí, přístup k databázi čas, síťové režie a další ukazatele serverové části systému, které lze analyzovat spolu s dalšími statistikami výkonu.
Srovnávací testování lze provádět přes rozlehlou síť a dokonce i v geograficky vzdálených lokalitách, protože rychlost internetu se liší podle lokality. Lze to provést i lokálně, ale v tomto případě je nutné nakonfigurovat síťové routery tak, aby došlo ke zpoždění, které je přítomno ve všech veřejných sítích. Zátěž aplikovaná na systém musí odpovídat skutečnému stavu věcí. Pokud tedy například 50 % uživatelů systému používá pro přístup k systému 56K síťový kanál a druhá polovina používá optický kanál, pak by počítače, které vytvářejí testovací zátěž v systému, měly používat stejná připojení (ideální) nebo emulovat zpoždění výše uvedených síťových připojení podle daných uživatelských profilů.
Požadavky na výkon by měly řešit minimálně následující otázky:
Existuje běžné nedorozumění, že nástroje pro testování zátěže systému jsou stejné nástroje pro nahrávání a přehrávání jako nástroje pro automatizaci regresního testování . Nástroje pro zátěžové testování pracují pomocí protokolu, zatímco nástroje pro automatizaci regresního testování fungují jak pomocí protokolu, tak pomocí objektů GUI.
| Příklad 1:
Existuje standardní internetový prohlížeč, který po stisknutí tlačítka plní funkci sledování zadaného odkazu. V tomto případě pro automatizaci regresního testování musíte napsat skript, který odešle kliknutí myší a tlačítko do prohlížeče, zatímco pro vytvoření skriptu pro zátěžové testování musíte napsat přenos hypertextového odkazu z prohlížeče několika uživatelům. , včetně jedinečného uživatelského jména a hesla pro každý z nich. |
Existují různé nástroje pro zjišťování a vyšetřování problémů v různých částech systému. Všechny uzly systému lze klasifikovat takto:
Pozoruhodný je také vznik síťových Business-to-business (B2B) aplikací využívajících smlouvu o úrovni služeb (neboli SLA, Service Level Agreement). Rostoucí obliba B2B aplikací vedla k tomu, že stále více aplikací přechází na architekturu orientovanou na služby , ve které k výměně informací dochází bez účasti webových prohlížečů. Příkladem takové interakce může být cestovní kancelář požadující informace o konkrétním letu mezi Petrohradem a Omskem, přičemž letecká společnost je povinna poskytnout odpověď do 5 sekund. Často za porušení smlouvy SLA hrozí vysoká pokuta.
Nejoblíbenější nástroje pro testování zátěže jsou uvedeny níže.
| NA | Jméno výrobce | Komentáře |
|---|---|---|
| OpenSTA | "Otevřená architektura testování systému" | Svobodný software pro zátěžové/zátěžové testování, licencovaný pod GNU GPL. Používá architekturu distribuovaných aplikací založenou na CORBA . Verze pro Windows je k dispozici, i když existují problémy s kompatibilitou se systémem Windows Vista. Podpora skončila v roce 2007. |
| IBM Rational Performance Tester | IBM | Založeno na vývojovém prostředí Eclipse , software, který umožňuje vytvářet velké zatížení a měřit dobu odezvy aplikací s architekturou klient-server. Vyžaduje licenci. |
| jmetr | Otevřete projekt Apache Jakarta | Sada nástrojů pro více platforem založená na Javě, která vám umožňuje provádět zátěžové testy pomocí připojení JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP. Umožňuje vytvářet velké množství požadavků z různých počítačů a řídit proces z jednoho z nich. |
| HP LoadRunner | Micro Focus (zakoupeno od HP) | Nástroj pro testování zátěže původně vyvinutý pro emulaci práce velkého počtu souběžných uživatelů. Lze také použít pro jednotku nebo integraci . |
| Silk_Performer | Micro Focus | |
| Zátěžový test sady Visual Studio | Microsoft | Visual Studio poskytuje nástroj pro testování výkonu včetně zátěžového/jednotkového testování |
Jedním z výsledků získaných během zátěžového testování a použitých pro další analýzu jsou ukazatele výkonu aplikace. Ty hlavní jsou diskutovány níže.
1. Spotřeba prostředků CPU (CPU, %)Metrika ukazující, kolik času z daného definovaného intervalu strávil procesor výpočty pro vybraný proces. V moderních systémech je důležitým faktorem schopnost procesu běžet ve více vláknech, takže procesor může provádět výpočty paralelně. Analýza historie spotřeby prostředků CPU může vysvětlit dopad na celkový výkon systému zpracovávaných datových toků, konfiguraci aplikací a operačního systému, vícevláknové výpočty a další faktory.
2. Využití paměti (Mb)Metrika ukazující množství paměti využívané aplikací. Použitou paměť lze rozdělit do tří kategorií:
Při běhu aplikace se paměť plní odkazy na objekty, které, pokud se nepoužívají, lze vyčistit speciálním automatickým procesem zvaným „garbage Collector“ (angl. Garbage Collector ). Doba, kterou procesor potřebuje k vyčištění paměti tímto způsobem, může být značná, když proces spotřeboval veškerou dostupnou paměť (v Javě tzv. „perzistentní Full GC“) nebo když procesu bylo přiděleno velké množství paměti, je třeba vyčistit. Během doby potřebné k vyčištění paměti může být zablokován přístup procesu ke stránkám alokované paměti, což může ovlivnit konečnou dobu zpracování pro tento proces.
3. Spotřeba síťových zdrojůTato metrika přímo nesouvisí s výkonem aplikace, ale její ukazatele mohou indikovat limity výkonu systému jako celku.
| Příklad 2:
Serverová aplikace, která zpracovává požadavek uživatele, mu vrací video stream pomocí síťového kanálu 2 megabity. Požadavek uvádí, že server musí zpracovat 5 požadavků uživatelů současně. Zátěžové testování ukázalo, že server může efektivně poskytovat data pouze 4 uživatelům současně, protože multimediální stream má bitovou rychlost 500 kilobitů. Je zřejmé, že poskytování tohoto streamu 5 uživatelům současně je nemožné z důvodu překročení šířky pásma síťového kanálu, což znamená, že systém nesplňuje stanovené požadavky na výkon, ačkoli jeho spotřeba procesorových a paměťových zdrojů může být nízký. |
Práce s diskovým subsystémem může výrazně ovlivnit výkon systému, takže shromažďování statistik o práci s diskem může pomoci identifikovat úzká hrdla v této oblasti. Velký počet čtení nebo zápisů může způsobit nečinnost procesoru při čekání na zpracování dat z disku a v důsledku toho zvýšit spotřebu procesoru a prodloužit dobu odezvy.
5. Doba odezvy žádosti (ms)Doba provedení požadavku aplikací zůstává jedním z nejdůležitějších ukazatelů výkonu systému nebo aplikace. Tento čas lze měřit na straně serveru jako míru času, který server potřebuje ke zpracování požadavku; a na klientovi jako ukazatel celkového času potřebného pro serializaci/deserializaci , předání a zpracování požadavku. Je třeba poznamenat, že ne každá aplikace pro testování výkonu může měřit oba tyto časy.
Některé z nejčastějších mýtů jsou uvedeny níže.
1. Testování výkonu se provádí za účelem rozbití systému. Zátěžové testování se provádí za účelem nalezení kritického bodu síly systému. V ostatních případech se provádí obvyklé zátěžové testování, aby se zjistilo chování systému při očekávané zátěži. V závislosti na dalších požadavcích může být vyžadováno testování stability, testování konfigurace nebo zátěžové testování.
2. Srovnávací testování by mělo být prováděno až po integračním srovnávacím testování Ačkoli je to v odvětví vývoje softwaru prakticky normou, testování výkonu lze provádět také v počáteční fázi vývoje aplikace. Tento přístup se nazývá Early Performance Testing . Podporuje holistický přístup k vývoji s ohledem na výkonnostní parametry a snižuje tak nejen šanci na nalezení problému s výkonem těsně před vydáním, ale také náklady na opravu takových problémů.
3. Testování výkonu spočívá pouze v psaní skriptů a jakákoliv změna v aplikaci má za následek malý refaktoring těchto skriptů. Samotné testování výkonu je rostoucím odvětvím softwarového průmyslu . Skriptování je sice důležité, ale je pouze součástí testování výkonu. Nejobtížnějším úkolem pro testera je určit testy, které je třeba provést, a analyzovat různé metriky výkonu, aby bylo možné identifikovat úzká místa systému.
Druhá část mýtu o malých změnách ve skriptech také není pravdivá, protože jakékoli změny uživatelského rozhraní, zejména v síťovém protokolu, povedou k úplnému přepsání skriptů od samého začátku. Problém se stává znatelnějším při používání protokolů, jako jsou Web Services, Siebel, Citrix, SAP.
4. Zátěžové testování, zátěžové testování a testování stability jsou jedno a totéž. Jeden z nejčastějších mýtů spojený s nepochopením terminologie. Zátěžové testování a zátěžové testování jsou dva různé typy činností, které se nazývají obecným pojmem testování výkonu a řeší různé problémy. Úkolem zátěžového testování je najít kritický bod pevnosti systému při zatížení, které je výrazně vyšší než očekávané nebo nepřiměřené; Úkolem zátěžového testování je ověřit, zda systém splňuje požadavky při očekávané zátěži.
| Vývoj softwaru | |
|---|---|
| Proces | |
Koncepty na vysoké úrovni | |
| Pokyny |
|
Vývojové metodiky | |
| Modelky |
|
| Pozoruhodné postavy |
|