LoadRunner-testaustyökalu: ArchiRakennekaavio ja komponentit

Mikä on LoadRunner?

LoadRunner on Suorituskykytestaus työkalu, jonka edelläkävijänä oli Mercury Interactive vuonna 1999. HP osti LoadRunnerin myöhemmin vuonna 2006, ja HP:n ohjelmistoliiketoiminta yhdistyi Micro Focusin kanssa vuonna 2016 julkistetussa ja vuonna 2017 toteutuneessa kaupassa.

Tuotemerkin huomautus: OpenText saattoi päätökseen Micro Focus -yritysoston tammikuussa 2023Työkalua ei enää myydä HP:n tai Micro Focus LoadRunnerLoadRunner Professional on nyt OpenText Ammattimainen suorituskykytekniikka, LoadRunner Enterprise on OpenText Yritysten suorituskyvyn suunnittelu ja LoadRunner Cloud on OpenText Core Performance Engineering. Alla olevien komponenttien nimet – VuGen, Controller, load generators ja Analysis – ovat pysyneet ennallaan.

LoadRunner tukee useita kehitystyökaluja, teknologioita ja tietoliikenneprotokollia. Se sisältää yhden markkinoiden laajimmista protokollakirjastoista suorituskykytestauksen suorittamiseen. LoadRunner-ohjelmiston tuottamia suorituskykytestien tuloksia käytetään vertailukohtana muihin työkaluihin verrattuna.

LoadRunner-video

Katso alla oleva video, jolla saat lyhyen johdannon LoadRunneriin ennen komponenttien käsittelyä.

Miksi LoadRunner?

LoadRunner ei ole ainoastaan ​​suorituskykytestauksen pioneerityökalu, vaan se on edelleen yksi suorituskykytestauksen markkinajohtajista ja monien yritysten vertailukohta.

Protokollan kattavuus on selkein syy, miksi tiimit valitsevat sen, kuten alla oleva komponenttikartta osoittaa.

Yleisesti ottaen LoadRunner-työkalu tukee RIA:ta (Rich Internet Applications), Web 2.0:aa (HTTP/HTML, Ajax, Flex ja Silverlight jne.), mobiilia, SAP, Oracle, NEITI SQL Palvelin, Citrix, RTE, Mail ja ennen kaikkea, Windows Socket. Harvat kilpailevat työkalut tarjoavat niin laajan valikoiman protokollia yhdessä työkalussa, kuten alla oleva protokollaluettelo havainnollistaa.

Vakuuttavampi syy valita LoadRunner ohjelmistotestaukseen on tämän työkalun uskottavuus. LoadRunner-työkalulla on jo pitkään ollut maine, sillä asiakkaat usein tarkistavat suorituskykyvertailuarvojasi LoadRunnerin avulla. LoadRunnerin käyttö suorituskykytestaukseen on helpotus, jos käytät jo LoadRunneria suorituskykytestaustarpeisiisi.

LoadRunner-ohjelmisto on tiiviisti integroitu saman ohjelmistopaketin sisartyökaluihin — Unified Functional Testing (entinen QTP, nyt myydään nimellä OpenText Toiminnallinen testaus) ja ALM (sovelluksen elinkaaren hallinta, nyt OpenText ALM/laatukeskus) — jonka avulla voit suorittaa testausprosessisi kokonaisvaltaisesti.

LoadRunner toimii virtuaalikäyttäjien simulointiperiaatteella kyseisessä sovelluksessa. Nämä virtuaalikäyttäjät, joita kutsutaan myös VUser-käyttäjiksi, replikoivat asiakkaan pyynnöt ja odottavat vastaavaa vastausta transaktion läpäisemiseksi.

Miksi tarvitset suorituskykytestauksen?

Alla olevat alan arviot ovat laajalti siteerattuja ja peräisin 2010-luvun alkupuolelta, mutta niiden kuvaama kaava ei ole muuttunut: hitaat sivut maksavat rahaa.

Verkkosivujen heikon suorituskyvyn vuoksi vuosittain kirjataan arviolta 4.4 miljardin dollarin tulojen menetys.

Nykypäivän Web 2.0 -aikakaudella käyttäjät poistuvat sivustolta napsauttamalla, jos se ei vastaa 8 sekunnin kuluessa. Kuvittele odottavasi 5 sekuntia etsiessäsi jotain tiettyä. Google tai kaveripyynnön tekeminen Facebookissa. Suorituskyvyn heikkenemisen seuraukset ovat usein tuhoisampia kuin koskaan kuvitellaan. On olemassa tunnettuja esimerkkejä, kuten Bank of America Online Bankingiin kohdistuneet, Amazon Verkkopalvelut, Intuit ja Blackberry.

Dun & Bradstreetin mukaan 59 % Fortune 500 -yrityksistä kokee arviolta 1.6 tuntia seisokkeja viikossa. Kun otetaan huomioon, että keskimääräinen Fortune 500 -yritys, jossa on vähintään 10 000 työntekijää, maksaa 56 dollaria tunnissa, seisokkikustannusten työvoimaosuus olisi tällaiselle organisaatiolle 896 000 dollaria viikossa, mikä tarkoittaa yli 46 miljoonaa dollaria vuodessa.

Vain 5 minuutin seisokkiaika Google.comin elokuussa 2013 arvioidaan maksaneen hakukonejätille jopa 545 000 dollaria.

On arvioitu, että yritykset menettivät myyntiään 1 100 dollarin arvosta sekunnissa viime aikoina. Amazon Verkkopalveluiden käyttökatkos.

Kun organisaatio ottaa ohjelmistojärjestelmän käyttöön, se voi kohdata monia skenaarioita, jotka saattavat johtaa suorituskyvyn latenssiin. Useat tekijät aiheuttavat suorituskyvyn heikkenemistä, muutamia esimerkkejä voivat olla:

• Tietokannassa olevien tietueiden määrä lisääntynyt
• Järjestelmään tehtyjen samanaikaisten pyyntöjen määrä on kasvanut
• Järjestelmää käyttää kerrallaan enemmän käyttäjiä kuin aiemmin

Kaikki hakemukset eivät kuitenkaan ole ehdokkaita. Kuormitustesti kohdistuu asiakas-palvelin-tyyppisiin usean käyttäjän järjestelmiin, joten alla olevan kaltaista yhden käyttäjän työpöytäapuohjelmaa ei kannata testata suorituskyvyn suhteen.

Mikä on LoadRunner Architektuuri?

Yleisesti ottaen LoadRunnerin arkkitehtuuri on monimutkainen mutta helppo ymmärtää. Alla oleva LoadRunnerin arkkitehtuurikaavio näyttää, miten neljä komponenttia toimivat yhdessä.

Oletetaan, että sinut on määrätty tarkistamaan suorituskyvyn Amazon.com 5000 käyttäjälle.

Todellisessa tilanteessa kaikki nämä 5000 käyttäjää eivät istu etusivulla, vaan he ovat jakautuneet verkkosivuston eri osioihin. Miten siis simuloimme tätä eroa?

VuGen

VuGen tai virtuaalikäyttäjä Generator on IDE (Integrated Development Environment) eli rikastettu koodauseditori. VuGenia käytetään järjestelmän kuormituksen (SUL) tilan jäljittelemiseen. VuGen tarjoaa "tallennusominaisuuden", joka tallentaa asiakkaan ja palvelimen välisen ja heidän välisen kommunikaation koodatun skriptin muodossa – jota kutsutaan myös nimellä VUser-skripti.

Joten ottaen huomioon yllä olevan esimerkin, VuGen voi tallentaa simuloidakseen seuraavia liiketoimintaprosesseja:

• Surffaa tuotesivulla Amazon.com
• Kassa
• Payment Processing
• Tarkistetaan Oma tili -sivua

Kun skripti toistuu puhtaasti, dynaamiset palvelinarvot on yleensä tallennettava korrelaatio ennen kuin sitä voidaan skaalata suuremmaksi.

ohjain

Kun VUser-skripti on viimeistelty, ohjain on yksi LoadRunnerin pääkomponenteista, joka ohjaa kuormitussimulaatiota hallitsemalla esimerkiksi seuraavia asioita:

• Kuinka monta VU-käyttäjää simuloidaan kutakin liiketoimintaprosessia tai VUser-ryhmää vastaan
• VU-käyttäjien käyttäytyminen (nousu ylös, alas, samanaikainen tai samanaikainen luonne jne.)
• Kuorman luonne skenaario, esim. tosielämän tai tavoiteorientoitunut tai varmentava SLA
• Mitä suuttimia käytetään, kuinka monta VU-käyttäjää kutakin injektoria vastaan
• Kerää tulokset säännöllisesti
• IP-huijaus
• Virheraportointi
• Tapahtumaraportointi jne.

Esimerkkimme analogian mukaisesti ohjain lisää VuGen-skriptiin seuraavat parametrit:

1. 3500 käyttäjää selaa tuotesivua Amazon.com
2. 750 käyttäjää on kassalla
3. 500 käyttäjää suorittaa maksujen käsittelyä
4. 250 käyttäjää tarkistaa Oma tili -sivua VASTA sen jälkeen, kun 500 käyttäjää on käsitellyt maksuja.

Vielä monimutkaisempiakin skenaarioita on mahdollista:

• Käynnistä 5 VU-käyttäjää joka 2. sekunti, kunnes 3500 VU-käyttäjää (surffaa) Amazon tuotesivu) on saavutettu.
• Toista 30 minuuttia
• Keskeytä iterointi 25 VU-käyttäjälle
• Käynnistä 20 virtuaalikäyttäjää uudelleen
• Aloita 2 käyttäjää (Kassassa, Maksunkäsittelyssä, Omat tilit -sivulla) joka sekunti.
• Koneella A luodaan 2500 VU-käyttäjää
• Koneella B luodaan 2500 VU-käyttäjää

Agents Machine/Load Generators/suuttimet

LoadRunner-ohjain simuloi tuhansia virtuaalikäyttäjiä (VUser). Nämä käyttäjät kuluttavat laitteistoresursseja, kuten prosessoria ja muistia. Tämä rajoittaa simuloivan koneen kuormitusta. Lisäksi ohjain simuloi näitä VUser-käyttäjiä samasta koneesta (jossa ohjain sijaitsee), joten tulokset eivät välttämättä ole tarkkoja. Tämän ongelman ratkaisemiseksi kaikki VUser-käyttäjät on hajautettu useille eri koneille, joita kutsutaan Load... Generators tai kuormitussuuttimet.

Yleisenä käytäntönä Ohjain sijaitsee eri koneessa ja kuormaa simuloidaan muista koneista. Riippuen VUser-komentosarjojen protokollasta ja koneen teknisistä tiedoista, täydellistä simulointia varten voidaan tarvita useita kuormitussuuttimia. Esimerkiksi HTTP-komentosarjan VU-käyttäjät tarvitsevat 2-4 Mt yksikköä kohti simulointiin, joten 4 4 VU-käyttäjän kuorman simuloimiseen tarvitaan neljä konetta, joissa kussakin on 10,000 Gt RAM-muistia.

Otetaan analogia meidän Amazon Esimerkiksi tämän komponentin tuotos on 5000 VUsersia jaettuna kahdelle injektorille: 2500 VUsersia generoidaan koneella A ja 2500 koneella B.

analyysi

Kun latausskenaariot on suoritettu, rooli analyysi LoadRunnerin komponentti tulee mukaan.

Suorituksen aikana Controller luo tulosvedosvedoksen raakamuodossa ja sisältää tietoja, kuten sen, mikä LoadRunner-versio loi tämän tulosvedoksen ja mitkä olivat kokoonpanot.

Kaikki virheet ja poikkeukset kirjataan sisään a Microsoft Käytä tietokantaa nimeltä output.mdb. Analyysikomponentti lukee tämän tietokantatiedoston suorittaakseen erilaisia ​​analyysejä ja luodakseen kuvaajia.

Nämä kaaviot näyttävät erilaisia ​​suuntauksia, joiden avulla voidaan ymmärtää virheiden ja kuormituksen aiheuttamien vikojen syyt. Näin voit selvittää, tarvitaanko optimointia SUL:ssa, palvelimessa (esim. JBoss, Oracle) tai infrastruktuuria.

Alla on esimerkki, jossa kaistanleveys voi aiheuttaa pullonkaulan. Oletetaan, että web-palvelimen kapasiteetti on 1 Gt/s, mutta dataliikenne ylittää tämän kapasiteetin, mikä aiheuttaa kärsimystä seuraaville käyttäjille. Jotta voidaan määrittää, vastaako järjestelmä näihin tarpeisiin, suorituskykyinsinöörin on analysoitava sovelluksen toimintaa epänormaalin kuormituksen aikana. Alla on kaavio, jonka LoadRunner luo kaistanleveyden selvittämiseksi.

Suorituskykytestauksen tekeminen

Suorituskykytestauksen etenemissuunnitelma voidaan karkeasti jakaa viiteen vaiheeseen, jotka on tiivistetty alla olevaan etenemissuunnitelmaan:

1. Kuormatestin suunnittelu
2. Luo VuGen-skriptejä
3. Skenaarion luominen
4. Skenaarion toteutus
5. Tulosanalyysi (jota seuraa järjestelmän säätäminen)

Kun LoadRunner on asennettu, ymmärretään prosessin vaiheet yksi kerrallaan.

Vaihe 1) Kuormatestin suunnittelu

Suorituskykytestauksen suunnittelu on eri asia kuin suunnittelu a SIT (System Integration Testing) or UAT (User Acceptance Testing). Suunnittelu voidaan jakaa edelleen pieniin vaiheisiin alla kuvatulla tavalla:

Kokoa tiimisi

Kun aloitat LoadRunner-testauksen, on parasta dokumentoida, ketkä kustakin prosessiin osallistuvasta tiimistä osallistuvat aktiviteettiin, kuten alla oleva tiimikaavio esittää.

• Projektipäällikkö: Nimeä projektipäällikkö, joka omistaa tämän aktiviteetin ja toimii pistehenkilönä eskalaatiossa.
• Toimintoasiantuntija / Liiketoiminta-analyytikko: Tarjoaa SUL:n käyttöanalyysin ja asiantuntemusta verkkosivuston tai SUL:n liiketoiminnan toiminnallisuudesta.
• Suorituskykytestauksen asiantuntija: Luo automatisoidut suorituskykytestit ja suorittaa kuormitusskenaarioita.
• järjestelmä ArchiTect: Tarjoaa SUL:n suunnitelman.
• Verkkokehittäjä ja pk-yritys: Ylläpitää verkkosivustoa, tarjoaa valvontaa, kehittää verkkosivustoa ja korjaa virheitä.
• Järjestelmänvalvoja: Ylläpitää mukana olevia palvelimia koko testausprojektin ajan.

Kuvaile sovellukset ja liiketoimintaprosessit

Onnistunut Kuormitustesti edellyttää, että aiot suorittaa tietyn liiketoimintaprosessin. Liiketoimintaprosessi koostuu selkeästi määritellyistä vaiheista haluttujen liiketapahtumien mukaisesti – kuormitustestaustavoitteidesi saavuttamiseksi.

Voidaan laatia vaatimusmittari, joka saa aikaan käyttäjän kuormituksen järjestelmään. Alla on esimerkki läsnäolojärjestelmästä yrityksessä:

Yllä olevassa esimerkissä luvut viittaavat sovellukseen (SUL) tiettynä aikana yhteydessä olleiden käyttäjien määrään. Voimme esimerkiksitract liiketoimintaprosessiin kytkettyjen käyttäjien enimmäismäärä mihin tahansa vuorokauden aikaan, joka lasketaan oikeanpuoleisimmissa sarakkeissa.

Vastaavasti voimme päätellä sovellukseen (SUL) kytkettyjen käyttäjien kokonaismäärän mihin tahansa vuorokauden aikaan. Tämä lasketaan viimeisellä rivillä.

Yllä olevat 2 tosiasiaa yhdessä antavat meille käyttäjien kokonaismäärän, jonka kanssa meidän on testattava järjestelmän suorituskykyä.

Määritä testitietojen hallintamenettelyt

Suorituskykytestauksen tilastoihin ja havaintoihin vaikuttavat suuresti monet tekijät, kuten aiemmin kerrottiin. On ratkaisevan tärkeää valmistella testitiedot suorituskykytestausta varten. Joskus tietty liiketoimintaprosessi kuluttaa tietojoukon ja tuottaa erilaisen tietojoukon. Ota esimerkki alla:

• Käyttäjä 'A' luo talouskonfliktintract ja lähettää sen tarkistettavaksi.
• Toinen käyttäjä 'B' hyväksyy 200 huijaustatrackäyttäjän 'A' luoma päivä
• Toinen käyttäjä 'C' maksaa noin 150 dollariatrackäyttäjän 'B' hyväksymä päivä

Tässä tilanteessa käyttäjällä B on oltava 200 contracts 'luotu' järjestelmässä. Lisäksi käyttäjä C tarvitsee 150 contracts "hyväksytyksi" 150 käyttäjän kuormituksen simuloimiseksi.

Tämä tarkoittaa implisiittisesti, että sinun on luotava vähintään 200 + 150 = 350 contracts.

Sen jälkeen hyväksytään 150 kontribuutiotatracts toimivat käyttäjän C testidatana – loput 200 contracts toimii käyttäjän B testidatana.

Outline-näytöt

Spekuloi jokainen tekijä, joka voisi mahdollisesti vaikuttaa järjestelmän suorituskykyyn. Esimerkiksi laitteiston vähentäminen voi vaikuttaa SUL:n (järjestelmän kuormitus) suorituskykyyn.

Ota huomioon kaikki tekijät ja asenna näytöt, jotta voit mitata niitä. Tässä muutamia esimerkkejä:

• Prosessori (verkkopalvelimelle, sovelluspalvelimelle, tietokantapalvelimelle ja injektoreille)
• RAM (verkkopalvelimelle, sovelluspalvelimelle, tietokantapalvelimelle ja injektoreille)
• Verkko-/sovelluspalvelin (esimerkiksi IIS, JBoss, Jaguar Server, Tomcat jne.)
• DB-palvelin (PGA- ja SGA-koko, jos kyseessä on Oracle ja MSSQL Server, SP jne.)
• Verkon kaistanleveyden käyttö
• Sisäinen ja ulkoinen verkkokortti klusteroinnin tapauksessa
• Load Balancer (ja että se jakaa kuorman tasaisesti kaikkiin klusterien solmuihin)
• Päiväys flux (laske, kuinka paljon dataa liikkuu asiakkaan ja palvelimen välillä – laske sitten, riittääkö verkkokortin kapasiteetti simuloimaan X käyttäjämäärää)

Vaihe 2) Luo VuGen-skriptejä

Suunnittelun jälkeen seuraava vaihe on VUser-skriptien luominen ja lisääminen parametrointi, tapahtumat ja ajonaikaiset asetukset käsikirjoituksen kypsyessä.

Vaihe 3) Skenaarion luominen

Seuraava vaihe on kuormitusskenaarion luominen ohjaimessa valitsemalla manuaalisen ja tavoitekeskeisen skenaarion välillä.

Vaihe 4) Skenaarion toteutus

Skenaarion suoritus on tapa, jossa emuloi käyttäjän kuormitusta palvelimella käskemällä useita ajoneuvojen käyttäjiä suorittamaan tehtäviä samanaikaisesti.

Voit asettaa kuormituksen tason lisäämällä ja vähentämällä tehtäviä suorittavien VU-käyttäjien määrää samanaikaisesti.

Tämä suoritus voi johtaa palvelimen kaatumiseen stressi ja käyttäytyvät epänormaalisti. Tämä on suorituskykytestauksen tarkoitus. Saatuja tuloksia käytetään sitten yksityiskohtaiseen analyysiin ja perimmäisten syiden tunnistamiseen.

Vaihe 5) Tulosanalyysi (jota seuraa järjestelmän säätäminen)

Skenaarion suorituksen aikana LoadRunner tallentaa sovelluksen suorituskyvyn eri kuormitusten alaisuudessa. Testien suorituksesta saadut tilastot tallennetaan ja niistä suoritetaan yksityiskohtainen analyysi. Analyysityökalu (tunnetaan nimellä 'HP Analysis' julkaisuissa, joita vasten tämä läpikäynti on kirjoitettu) luo erilaisia ​​kuvaajia, jotka auttavat tunnistamaan järjestelmän suorituskyvyn viiveen ja järjestelmävian taustalla olevat perimmäiset syyt.

Jotkut saaduista kaavioista sisältävät:

• Aika ensimmäiseen puskuriin
• Tapahtuman vastausaika
• Keskimääräinen tapahtuman vasteaika
• Osumia sekunnissa
• Windows Esittelymateriaalit
• Virhetilastot
• Liiketoimien yhteenveto

UKK