A teljesítményteszt ( eng . Performance Testing ) a szoftverfejlesztésben olyan tesztelés , amelyet annak meghatározására végeznek, hogy egy számítógépes rendszer vagy annak egy része milyen gyorsan működik bizonyos terhelés mellett . Ezenkívül más rendszerminőségi attribútumok tesztelésére és érvényesítésére is szolgálhat, mint például a méretezhetőség , a megbízhatóság és az erőforrás-felhasználás.
A teljesítményteszt a teljesítményfejlesztés egyik feltörekvő területe a számítástechnikában , amely a rendszer modellezési és tervezési fázisában, a fő kódolási fázis megkezdése előtt igyekszik figyelembe venni a teljesítményt .
A teljesítményteszt során a következő területeket különböztetjük meg:
A szoftverteljesítmény tesztelésének két megközelítése létezik [1] :
A terhelési tesztelés a teljesítményteszt legegyszerűbb formája. A terhelési tesztelést általában azért végzik, hogy értékeljék az alkalmazás viselkedését egy adott várható terhelés mellett. Ez a terhelés lehet például az alkalmazás egyidejű felhasználóinak várható száma, akik adott számú tranzakciót hajtanak végre időintervallumonként. Az ilyen típusú tesztelés általában lehetővé teszi, hogy megkapja a legfontosabb üzleti tranzakciók válaszidejét. Adatbázis, alkalmazásszerver , hálózat stb. megfigyelése esetén az ilyen típusú tesztelés bizonyos alkalmazások szűk keresztmetszetét is azonosítani tudja.
A stressztesztet általában az alkalmazások átviteli korlátainak megértésére használják. Ez a fajta tesztelés a rendszer megbízhatóságának meghatározására szolgál extrém vagy aránytalan terhelések esetén, és választ ad a rendszer megfelelő teljesítményére vonatkozó kérdésekre abban az esetben, ha az áramterhelés nagymértékben meghaladja az elvárt maximumot.
Stabilitási teszteléssel biztosítják, hogy az alkalmazás hosszú távon ellenálljon a várható terhelésnek. Az ilyen típusú tesztelés figyeli az alkalmazás memóriafelhasználását a lehetséges szivárgások azonosítása érdekében. Ezen túlmenően az ilyen tesztelés teljesítményromlást tár fel, amely az információfeldolgozás sebességének csökkenésében és/vagy az alkalmazás válaszidejének növekedésében fejeződik ki hosszú futás után a teszt kezdetéhez képest.
A konfigurációteszt a hagyományos teljesítményteszt másik típusa. Ebben az esetben a rendszer teljesítményének az alkalmazott terhelés szempontjából történő tesztelése helyett a konfigurációs változtatások teljesítményhatását tesztelik. Az ilyen tesztelés jó példája a különböző terheléselosztási módszerekkel való kísérletezés. A konfiguráció tesztelése terhelés-, feszültség- vagy stabilitásteszttel is kombinálható.
Általában a teljesítményteszt különböző célokat szolgálhat.
Sok teljesítménytesztet anélkül végeznek el, hogy megpróbálnák megérteni valódi céljukat. A tesztelés megkezdése előtt mindig fel kell tenni az üzleti kérdést: „Mi a célunk a teljesítményteszttel?”. A kérdésre adott válaszok a tesztelés megvalósíthatósági tanulmányának (vagy üzleti esetének ) részét képezik. A célok az alkalmazás által használt technológiától vagy annak céljától függően változhatnak, azonban mindig tartalmazzák a következők valamelyikét:
Ha az alkalmazás végfelhasználóit a rendszerbe bármilyen formában bejelentkező felhasználóknak tekintjük, akkor ebben az esetben a párhuzamosság elérése nagyon kívánatos. Értelemszerűen ez az alkalmazás egyidejűleg futó felhasználóinak maximális száma, amelyet az alkalmazásnak adott időpontban támogatnia kell. A felhasználói viselkedési minta jelentősen befolyásolhatja az alkalmazás azon képességét, hogy párhuzamosan tudja feldolgozni a kéréseket, különösen, ha rendszeres be- és kijelentkezést igényel.
Ha az alkalmazás koncepciója nem az, hogy meghatározott végfelhasználókkal dolgozzon, akkor a követett teljesítménycél a maximális átviteli sebességen vagy az időegységenkénti tranzakciók számán fog alapulni. Jó példa ebben az esetben a weben való böngészés, például a Wikipédia portálon.
Ez a koncepció az egyik alkalmazáscsomópont válaszideje köré épül egy másiknak küldött kérésre. Egy egyszerű példa egy HTTP „GET” kérés a munkaállomás böngészőjétől a webszerver felé. Szinte minden terhelési tesztelésre kifejlesztett alkalmazás pontosan ezen mérési séma szerint működik. Néha célszerű célokat beállítani a szerver válaszidő-teljesítményének eléréséhez az összes alkalmazáscsomóponton.
A megjelenítési idő az egyik legnehezebb fogalom a terheléstesztelő alkalmazásoknál, mivel általában nem használják azt a koncepciót, hogy a rendszer egyes csomópontjain zajló eseményekkel dolgozzanak, csupán egy olyan időtartam felismerésére korlátozódnak, amely alatt nincs hálózati tevékenység. A megjelenítési idő mérése általában megköveteli a funkcionális tesztesetek bevonását a benchmark tesztekbe, de a legtöbb benchmark alkalmazás nem tartalmazza ezt a lehetőséget.
Nagyon fontos a teljesítménykövetelmények részletezése és valamilyen teljesítményvizsgálati tervben történő dokumentálása. Ideális esetben ez a rendszerfejlesztés követelményfejlesztési szakaszában történik, még a tervezési részletek kidolgozása előtt. Lásd a teljesítménytervezést .
A teljesítménytesztet azonban gyakran nem a specifikációnak megfelelően végzik el, mivel nincs rögzített értelmezés az adott számú felhasználó maximális válaszidejéről. A teljesítménytesztet gyakran használják a teljesítményprofil-alkotási folyamat részeként. Ötlete egy „gyenge láncszem” megtalálása – a rendszer egy olyan része, amelynek reakcióidejének optimalizálásával javítható a rendszer általános teljesítménye. Annak meghatározása, hogy a rendszer melyik része van ezen a kritikus úton, néha nagyon nehéz feladat, ezért egyes tesztalkalmazások tartalmaznak (vagy bővítményeken keresztül hozzáadhatók) a szerveren futó eszközöket (ügynököket), amelyek figyelik a végrehajtási időbeli tranzakciókat, az adatbázis-hozzáférést. idő, hálózati többlet és a rendszer szerver részének egyéb mutatói, amelyek más teljesítménystatisztikák mellett elemezhetők.
A benchmark tesztelés nagy kiterjedésű hálózaton és akár földrajzilag távoli helyeken is elvégezhető, mivel az internet sebessége helyenként változik. Helyben is végrehajtható, de ebben az esetben a hálózati útválasztókat úgy kell beállítani, hogy minden nyilvános hálózatban legyen késés. A rendszerre kifejtett terhelésnek meg kell egyeznie a tényleges állapottal. Tehát például, ha a rendszerhasználók 50%-a 56K-os hálózati csatornát használ a rendszer eléréséhez, a másik fele pedig optikai csatornát, akkor a rendszeren tesztterhelést létrehozó számítógépeknek ugyanazokat a kapcsolatokat (ideális) vagy emulálniuk kell. a fenti hálózati kapcsolatok késései, adott felhasználói profilokat követve.
A teljesítménykövetelményeknek legalább a következő kérdésekre kell vonatkozniuk:
Gyakori félreértés, hogy a rendszerterhelés-tesztelő eszközök ugyanazok a rögzítési és lejátszási eszközök, mint a regressziós tesztelés automatizálására szolgáló eszközök . A terheléstesztelő eszközök protokollt használnak, míg a regressziós tesztelést automatizáló eszközök mind protokoll, mind GUI objektumok használatával működnek.
| 1. példa:
Létezik egy szabványos internetböngésző, amely gombnyomáskor követi a megadott hivatkozást. Ebben az esetben a regressziós tesztelés automatizálásához olyan szkriptet kell írni, amely egy egérkattintást és egy gombkattintást küld a böngészőnek, míg a terhelési teszteléshez szükséges szkript létrehozásához hiperhivatkozás-átvitelt kell írni a böngészőből több felhasználónak. , beleértve mindegyikhez egyedi felhasználónevet és jelszót. |
Különféle eszközök állnak rendelkezésre a problémák észlelésére és kivizsgálására a rendszer különböző részein. A rendszer összes csomópontja a következőképpen osztályozható:
Szintén figyelemre méltó a hálózatba kapcsolt Business-to-business (B2B) alkalmazások megjelenése, amelyek szolgáltatási szint megállapodást (vagy SLA, Service Level Agreement) használnak. A B2B alkalmazások növekvő népszerűsége oda vezetett, hogy egyre több alkalmazás tér át szolgáltatás-orientált architektúrára , amelyben az információcsere a webböngészők részvétele nélkül történik. Ilyen interakció például egy utazási iroda, amely egy adott Szentpétervár és Omszk közötti járatról kér információt, miközben a légitársaságnak 5 másodpercen belül válaszolnia kell. Az SLA-megállapodás megsértése gyakran nagy pénzbírsággal fenyeget.
Az alábbiakban felsoroljuk a legnépszerűbb terheléstesztelő eszközöket.
| TOVÁBB | A gyártó neve | Hozzászólások |
|---|---|---|
| OpenSTA | "Nyílt rendszer tesztelési architektúra" | Ingyenes szoftver terhelési/stressz teszteléshez, a GNU GPL licenc alatt. CORBA alapú elosztott alkalmazásarchitektúrát használ . Windows-verzió is elérhető, bár a Windows Vista rendszerrel kompatibilitási problémák vannak. A támogatás 2007-ben véget ért. |
| IBM Rational Performance Tester | IBM | Az Eclipse fejlesztői környezeten alapuló szoftver, amely lehetővé teszi nagy terhelés létrehozását és a válaszidő mérését a kliens-szerver architektúrájú alkalmazásokhoz. Engedélyt igényel. |
| jmeter | Nyissa meg az Apache Jakarta Projectet | Java-alapú, többplatformos eszközkészlet, amely lehetővé teszi terhelési tesztek végrehajtását JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP kapcsolatok használatával. Lehetővé teszi nagyszámú kérés létrehozását különböző számítógépekről, és ezek egyikéről irányíthatja a folyamatot. |
| HP LoadRunner | Micro Focus (a HP-től vásárolva) | Egy terheléstesztelő eszköz, amelyet eredetileg nagyszámú egyidejű felhasználó munkájának emulálására fejlesztettek ki. Egységhez vagy integrációhoz is használható . |
| Silk_Performer | Mikrofókusz | |
| Visual Studio terhelési teszt | Microsoft | A Visual Studio teljesítmény-tesztelő eszközt biztosít, beleértve a terhelés-/egységtesztet |
A terheléses tesztelés során kapott és további elemzésekhez felhasznált eredmények egyike az alkalmazás teljesítménymutatói. A főbbeket az alábbiakban tárgyaljuk.
1. CPU erőforrás fogyasztás (CPU, %)Egy mérőszám, amely megmutatja, hogy egy adott intervallumból mennyi időt fordított a processzor a kiválasztott folyamat számításaira. A modern rendszerekben fontos tényező, hogy egy folyamat több szálon tudjon futni, így a processzor párhuzamosan végezhet számításokat. A CPU erőforrás-fogyasztási előzményeinek elemzése megmagyarázhatja a feldolgozott adatfolyamok rendszerének általános teljesítményére, az alkalmazások és az operációs rendszer konfigurációjára, a többszálú számítástechnikára és egyéb tényezőkre gyakorolt hatást.
2. Memóriahasználat (Mb)Az alkalmazás által használt memória mennyiségét mutató mérőszám. A használt memória három kategóriába sorolható:
Amikor az alkalmazás fut, a memória megtelik az objektumokra vonatkozó hivatkozásokkal, amelyeket ha nem használnak, egy speciális automatikus folyamat, az úgynevezett "szemétgyűjtő" (Eng. Garbage Collector ) törölheti . A processzornak a memória ilyen módon történő tisztításához szükséges idő jelentős lehet, ha a folyamat felemésztette az összes rendelkezésre álló memóriát (Java-ban az úgynevezett "persistent Full GC"), vagy ha a folyamathoz nagy mennyiségű memóriát foglaltak le, takarítani kell. A memória megtisztításához szükséges idő alatt a folyamatok hozzáférése a lefoglalt memória lapjaihoz blokkolható, ami befolyásolhatja a folyamat végső feldolgozási idejét.
3. Hálózati erőforrások fogyasztásaEz a mérőszám közvetlenül nem kapcsolódik az alkalmazás teljesítményéhez, de mutatói jelezhetik a rendszer egészének teljesítményhatárait.
| 2. példa:
A szerveralkalmazás a felhasználó kérését feldolgozva egy 2 megabites hálózati csatornán keresztül egy videofolyamot küld vissza neki. A követelmény kimondja, hogy a szervernek egyszerre 5 felhasználói kérést kell feldolgoznia. A terhelési tesztek kimutatták, hogy a szerver egyszerre csak 4 felhasználó számára tud hatékonyan adatot szolgáltatni, mivel a multimédiás adatfolyam bitsebessége 500 kilobit. Nyilvánvaló, hogy ennek a streamnek az egyidejű biztosítása 5 felhasználó számára lehetetlen a hálózati csatorna sávszélesség túllépése miatt, ami azt jelenti, hogy a rendszer nem felel meg a megadott teljesítménykövetelményeknek, bár a processzor- és memória erőforrás-fogyasztása lent. |
A lemezalrendszerrel való munka jelentősen befolyásolhatja a rendszer teljesítményét, így a lemezzel való munkavégzésről szóló statisztikák gyűjtése segíthet a szűk keresztmetszetek azonosításában ezen a területen. A nagyszámú olvasás vagy írás a processzor tétlenségéhez vezethet, miközben az adatok lemezről történő feldolgozására vár, és ennek eredményeként megnő a CPU-fogyasztás és a válaszidő.
5. Válaszidő kérése (ms)A kérések alkalmazás általi végrehajtási ideje továbbra is a rendszer vagy alkalmazás teljesítményének egyik legfontosabb mutatója. Ez az idő mérhető a szerver oldalon, mint annak az időnek a mértéke, amely alatt a szerveroldal feldolgozza a kérést; az ügyfélen pedig a kérés szerializálásához/deserializálásához , továbbításához és feldolgozásához szükséges teljes idő mutatójaként . Meg kell jegyezni, hogy nem minden teljesítménytesztelő alkalmazás képes mindkét időt mérni.
Az alábbiakban felsorolunk néhány leggyakoribb mítoszt.
1. A rendszer megszakítása érdekében teljesítménytesztet végeznek. Stressz-tesztet végeznek annak érdekében, hogy megtalálják a rendszer erősségének kritikus pontját. Más esetekben a szokásos terhelési tesztet végzik el, hogy megvizsgálják a rendszer viselkedését a várható terhelés mellett. Egyéb követelményektől függően szükség lehet stabilitástesztre, konfigurációtesztre vagy stressztesztre.
2. A benchmark tesztelést csak az integrációs benchmark tesztelés után szabad elvégezni. Bár a szoftverfejlesztő iparágban ez gyakorlatilag bevett szokás, a teljesítményteszt az alkalmazásfejlesztés kezdeti szakaszában is elvégezhető. Ezt a megközelítést korai teljesítménytesztnek nevezik . Elősegíti a fejlesztés holisztikus megközelítését, figyelembe véve a teljesítményparamétereket, és így nemcsak annak esélyét csökkenti, hogy közvetlenül a kiadás előtt találjanak teljesítményproblémát, hanem az ilyen problémák kijavításának költségeit is.
3. A teljesítményteszt csak szkriptek írásából áll, és az alkalmazásban bekövetkezett bármilyen változás a szkriptek kismértékű átdolgozását eredményezi. Maga a teljesítményteszt a szoftveripar egyre növekvő ága . A szkriptelés, bár fontos, csak a teljesítményteszt része. A tesztelő legnehezebb dolga az elvégzendő tesztek meghatározása és a különböző teljesítménymutatók elemzése a rendszer szűk keresztmetszete azonosítása érdekében.
A szkriptek apró változtatásairól szóló mítosz másik része sem igaz, mivel a felhasználói felületen, különösen a hálózati protokollban végrehajtott bármilyen változtatás a szkriptek teljes újraírását fogja eredményezni a kezdetektől fogva. A probléma észrevehetőbbé válik olyan protokollok használatakor, mint a Web Services, Siebel, Citrix, SAP.
4. A stresszteszt, a terhelésteszt és a stabilitásteszt egy és ugyanaz. Az egyik leggyakoribb mítosz, amely a terminológia félreértésével kapcsolatos. A stresszteszt és a terhelésteszt két különböző típusú tevékenység, amelyet a teljesítményteszt általános kifejezésének neveznek , és különböző problémákat oldanak meg. A stresszteszt feladata a rendszer szilárdságának kritikus pontjának megtalálása a vártnál lényegesen nagyobb vagy aránytalan terhelések mellett; A terhelési tesztelés feladata annak ellenőrzése, hogy a rendszer az elvárt terhelés mellett megfelel-e a követelményeknek.
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|