Mikä on HP LoadRunner -testaustyökalu? Arkkitehtuuri, komponentit

Mikä on LoadRunner?

LoadRunner on suorituskyvyn testaustyökalu, jonka Mercury aloitti vuonna 1999. LoadRunner osti myöhemmin HPE vuonna 2006. Vuonna 2016 LoadRunner osti MicroFocus.

LoadRunner tukee erilaisia ​​kehitystyökaluja, tekniikoita ja yhteyskäytäntöjä. Itse asiassa tämä on markkinoiden ainoa työkalu, joka tukee niin suurta määrää protokollia suorituskykytestauksen suorittamiseksi. LoadRunner-ohjelmiston tuottamia testituloksia käytetään vertailukohtana muihin työkaluihin nähden

Tässä opetusohjelmassa opit-

• Miksi LoadRunner?
• Miksi tarvitset suorituskykytestausta?
• Mikä on LoadRunner-arkkitehtuuri?
• Suorituskyvyn testauksen tiekartta: Yksityiskohtaiset vaiheet
• UKK

Miksi LoadRunner?

LoadRunner ei ole vain suorituskyvyn testauksen pioneerityökalu, mutta se on silti markkinajohtaja suorituskyvyn testaamisen paradigmassa. Tuoreessa arvioinnissa LoadRunnerilla on noin 85%: n markkinaosuus suorituskykytestausteollisuudessa.

Yleisesti ottaen LoadRunner-työkalu tukee RIA: ta (Rich Internet Applications), Web 2.0: ta (HTTP / HTML, Ajax, Flex ja Silverlight jne.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail ja ennen kaikkea Windows Socketia. Markkinoilla ei ole kilpailijatyökalua, joka voisi tarjota niin monenlaisia ​​protokollia, jotka kuuluvat yhteen työkaluun.

Tämän työkalun uskottavuus on vakuuttavampaa valita LoadRunner ohjelmistojen testauksessa. LoadRunner-työkalulla on jo pitkään ollut maine, koska usein löydät asiakkaita, jotka tarkistavat suorituskykysi vertailuarvot LoadRunnerilla. Löydät helpotusta, jos käytät jo LoadRunneria suorituskyvyn testaustarpeisiisi.

LoadRunner-ohjelmisto on tiiviisti integroitu muihin HP-työkaluihin, kuten Unified Functional Test (QTP) ja ALM (Application Lifecycle Management), mikä antaa sinulle mahdollisuuden suorittaa loppuun asti testausprosessit.

LoadRunner toimii pääasiassa, joka simuloi virtuaalisia käyttäjiä aihesovelluksessa. Näitä virtuaalisia käyttäjiä kutsutaan myös yksiköiksi, jotka toistavat asiakkaan pyynnöt ja odottavat vastaavaa vastausta tapahtuman läpäisemiseen.

Miksi tarvitset suorituskykytestausta?

Arvioitu 4,4 miljardin tulonmenetys kirjataan vuosittain huonon web-suorituskyvyn takia.

Nykyisessä Web 2.0 -kaudessa käyttäjät napsauttavat poispäin, jos verkkosivusto ei vastaa 8 sekunnin kuluessa. Kuvittele itsesi odottavan 5 sekuntia etsiessäsi Googlea tai tehdessäsi kaveripyyntöä Facebookissa. Suorituskyvyn seisokkien seuraukset ovat usein tuhoisampia kuin koskaan kuvitellaan. Meillä on esimerkkejä, kuten äskettäin tulleet Bank of America-verkkopankit, Amazon Web Services, Intuit tai Blackberry.

Dunn & Bradstreetin mukaan 59% Fortune 500 -yrityksistä kokee arviolta 1,6 tuntia seisokkeja joka viikko. Ottaen huomioon, että keskimääräinen Fortune 500 -yritys, jolla on vähintään 10000 työntekijää, maksaa 56 dollaria tunnissa, tällaisen organisaation seisokkien kustannukset olisivat 896 000 dollaria viikossa, mikä tarkoittaa yli 46 miljoonaa dollaria vuodessa.

Ainoastaan ​​viiden minuutin Google.comin seisokkien (19. elokuuta-13) arvioidaan maksavan hakujätille peräti 545 000 dollaria.

Arvioiden mukaan yritykset menettivät myyntiään 1100 dollaria sekunnissa äskettäisen Amazon Web Service -katkoksen vuoksi.

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

• Tietokannassa olevien tietueiden määrä on kasvanut
• Lisääntynyt samanaikaisten pyyntöjen määrä järjestelmälle
• enemmän käyttäjiä, jotka käyttävät järjestelmää kerrallaan verrattuna aikaisempaan

Mikä on LoadRunner-arkkitehtuuri?

Yleisesti ottaen HP LoadRunner -arkkitehtuuri on monimutkainen, mutta helppo ymmärtää.

Oletetaan, että olet määrittänyt tarkistamaan Amazon.comin suorituskyvyn 5000 käyttäjälle

Todellisessa tilanteessa nämä kaikki 5000 käyttäjää eivät ole kotisivulla vaan verkkosivustojen eri osiossa. Kuinka voimme simuloida eri tavalla

VUGen:

VUGen tai Virtual User Generator on IDE (integroitu kehitysympäristö) tai rikas koodauseditori. VUGen-järjestelmää käytetään toistamaan kuormitetun järjestelmän (SUL) käyttäytymistä. VUGen tarjoaa "tallennus" -ominaisuuden, joka tallentaa viestinnän asiakkaalle ja palvelimelle ja sieltä koodatun komentosarjan muodossa - jota kutsutaan myös VUser-komentosarjoksi.

Joten edellisen esimerkin perusteella VUGen voi tallentaa simuloimaan seuraavia liiketoimintaprosesseja:

1. Amazon.comin tuotesivun selaaminen
2. Tarkista
3. Maksunkäsittely
4. Tarkastetaan Oma tili -sivua

Ohjain

Kun VUser-komentosarja on viimeistelty, Controller on yksi tärkeimmistä LoadRunner-komponenteista, joka ohjaa kuormitussimulaatiota hallitsemalla esimerkiksi:

• Kuinka monta VU-käyttäjää simuloidaan kutakin liiketoimintaprosessia tai VUser-ryhmää vastaan
• Ajoneuvoyksiköiden käyttäytyminen (ramppi ylös, alas alas, samanaikainen tai samanaikainen luonne jne.)
• Kuormitustapa skenaario, esim. Tosielämä tai tavoite tai SLA: n tarkistaminen
• Mitä injektoreja käytetään, kuinka monta VU-käyttäjää jokaista injektoria vasten
• Lajittele tulokset säännöllisesti
• IP-huijaus
• Virheraportointi
• Tapahtumaraportointi jne.

Analogian ottaminen esimerkkiohjaimestamme lisää seuraavan parametrin VUGen-komentosarjaan

1) 3500 käyttäjää surffaa Amazon.comin tuotesivulla

2) Kassalla on 750 käyttäjää

3) 500 käyttäjää suorittaa maksujen käsittelyä

4) 250 käyttäjää tarkistaa Oma tili -sivun VAIN sen jälkeen, kun 500 käyttäjää on suorittanut maksujen käsittelyn

Vielä monimutkaisemmat skenaariot ovat mahdollisia

1. Aloita 5 käyttöyksikköä 2 sekunnin välein, kunnes saavutetaan 3500 VU-käyttäjän kuorma (surfattava Amazon-tuotesivu).
2. Toista 30 minuuttia
3. Keskeytä iterointi 25 yksikköön
4. Käynnistä 20 VUSeria uudelleen
5. Aloita 2 käyttäjää (Checkout-, Maksunkäsittely-, Oma tili -sivulla) joka sekunti.
6. Koneeseen A luodaan 2500 yksikköä
7. Koneeseen B luodaan 2500 yksikköä

Agentit kone- / kuormageneraattorit / injektorit

HP LoadRunner Controller on vastuussa tuhansien ajoneuvoyksiköiden simuloinnista - nämä ajoneuvoyksiköt kuluttavat laitteistoresursseja, esimerkiksi prosessoria ja muistia, ja asettavat siten rajoituksen koneita, jotka simuloivat niitä. Lisäksi ohjain simuloi näitä ajoneuvoyksiköitä samalta koneelta (jossa ohjain asuu), joten tulokset eivät välttämättä ole tarkkoja. Tämän ongelman ratkaisemiseksi kaikki ajoneuvoyksiköt jakautuvat eri koneisiin, nimeltään Load Generators tai Load Injectors.

Yleisenä käytäntönä Controller asuu eri koneella ja kuormitusta simuloidaan muista koneista. VUser-komentosarjojen protokollasta ja koneen spesifikaatioista riippuen täydelliseen simulointiin voidaan tarvita useita kuorma-injektoreita. Esimerkiksi HTTP-komentosarjan VU-käyttäjät tarvitsevat simulointiin 2-4 Mt / VUser-käyttäjä, joten tarvitaan 4 konetta, joissa kullakin on 4 Gt RAM-muistia, 10000 VU-käyttäjän kuormituksen simulointiin.

Kun otetaan analogia Amazon-esimerkistämme, tämän komponentin tuotos on

Analyysi:

Kun latauskenaariot on suoritettu, LoadRunnerin " Analysis " -komponenttien rooli tulee sisään.

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

Kaikki virheet ja poikkeukset kirjataan Microsoft Access -tietokantaan nimeltä output.mdb. "Analyysi" -komponentti lukee tämän tietokantatiedoston suorittamaan erityyppisiä analyyseja ja luo kaavioita.

Nämä kaaviot osoittavat erilaisia ​​suuntauksia ymmärtääkseen virheiden ja epäonnistumisten perustelut kuormitettuna; auttaa siten selvittämään, tarvitaanko optimointia SUL: ssa, palvelimessa (esim. JBoss, Oracle) vai infrastruktuurissa.

Alla on esimerkki siitä, kuinka kaistanleveys voisi luoda pullonkaulan. Oletetaan, että verkkopalvelimen kapasiteetti on 1 Gt / s, kun taas dataliikenne ylittää tämän kapasiteetin aiheuttaen seuraaville käyttäjille kärsimyksiä. Tällaisten tarpeiden mukaisen järjestelmän määrittämiseksi Performance Engineerin on analysoitava sovelluskäyttäytymistä epänormaalilla kuormituksella. Alla on kaavio, jonka LoadRunner tuottaa kaistanleveyden aikaansaamiseksi.

Suorituskyvyn testauksen tiekartta: Yksityiskohtaiset vaiheet

Suorituskykytestaussuunnitelma voidaan jakaa laajasti viiteen vaiheeseen:

• Kuormitustestin suunnittelu
• Luo VUGen-komentosarjoja
• Skenaarion luominen
• Skenaarion toteutus
• Tulosten analyysi (jota seuraa järjestelmän säätäminen)

Nyt kun olet asentanut LoadRunnerin, ymmärretään prosessin vaiheet yksitellen.

Suoritustestausprosessin vaiheet

Kuormitustestin suunnittelu

Suorituskykytestauksen suunnittelu eroaa SIT: n (järjestelmän integraatiotestaus) tai UAT: n (käyttäjän hyväksymistestaus) suunnittelusta. Suunnittelu voidaan jakaa edelleen pieniin vaiheisiin alla kuvatulla tavalla:

Kokoa joukkue

Kun aloitat LoadRunner-testauksen, on parasta dokumentoida kuka osallistuu toimintaan kustakin prosessin aikana mukana olevasta tiimistä.

Projektipäällikkö:

Nimeä projektipäällikkö, joka omistaa tämän toiminnan ja toimii eskaloituna eskaloitumiseen.

Toimintoasiantuntija / liiketoiminta-analyytikko:

Tarjoa SUL: n käyttöanalyysi ja tarjoaa asiantuntemusta verkkosivuston / SUL: n liiketoiminnallisuudesta

Suorituskykytestauksen asiantuntija:

Luo automaattiset suorituskykytestit ja suorittaa latauskenaariot

Järjestelmäarkkitehti:

Tarjoaa suunnitelman SUL: sta

Verkkokehittäjä ja pk-yritys:

• Ylläpitää verkkosivustoa ja tarjoaa seurantakohteita
• Kehittää verkkosivustoa ja korjaa virheitä

Järjestelmänvalvoja:

• Ylläpitää mukana olevia palvelimia koko testaushankkeen ajan

Esitä sovellukset ja liiketoimintaprosessit:

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

Vaatimusmetriikka voidaan valmistaa käyttäjien kuormituksen saamiseksi järjestelmään. Alla on esimerkki läsnäolojärjestelmästä yrityksessä:

Yllä olevassa esimerkissä luvuissa mainitaan sovellukseen (SUL) kytkettyjen käyttäjien määrä tiettynä tunnina. Voimme poimia liiketoimintaprosessiin liittyvien käyttäjien enimmäismäärän milloin tahansa päivän aikana, joka lasketaan oikeanpuoleisimmissa sarakkeissa.

Vastaavasti voimme päätellä sovellukseen yhdistettyjen käyttäjien kokonaismäärän (SUL) milloin tahansa päivästä. Tämä lasketaan viimeisellä rivillä.

Edellä mainitut kaksi tosiseikkaa antavat meille käyttäjien kokonaismäärän, joiden kanssa meidän on testattava järjestelmän suorituskyky.

Määritä testitietojen hallintamenettelyt

Suorituskykytestauksen tilastoihin ja havaintoihin vaikuttavat suuresti monet aiemmin kuvatut tekijät. On ratkaisevan tärkeää valmistaa testitiedot suorituskyvyn testausta varten. Joskus tietty liiketoimintaprosessi kuluttaa tietojoukon ja tuottaa toisen tietojoukon. Otetaan alla oleva esimerkki:

• Käyttäjä A luo rahoitussopimuksen ja lähettää sen tarkistettavaksi.
• Toinen käyttäjä 'B' hyväksyy käyttäjän 'A' luomat 200 sopimusta päivässä
• Toinen käyttäjä C maksaa noin 150 sopimusta päivässä, jonka käyttäjä B on hyväksynyt.

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

Tämä tarkoittaa epäsuorasti, että sinun on luotava vähintään 200 + 150 = 350 sopimusta.

Tämän jälkeen hyväksy 150 sopimusta toimimaan käyttäjän C testitiedoina - loput 200 sopimusta toimivat käyttäjän B testitiedoina.

Ääriviivat

Spekuloi kaikki tekijät, jotka saattavat vaikuttaa järjestelmän suorituskykyyn. Esimerkiksi vähentyneellä laitteistolla voi olla vaikutusta SUL (System Under Load) -suorituskykyyn.

Luetteloi kaikki tekijät ja aseta monitorit, jotta voit mitata ne. Tässä on muutama esimerkki:

• Suoritin (verkkopalvelimelle, sovelluspalvelimelle, tietokantapalvelimelle ja suuttimille)
• RAM (verkkopalvelimelle, sovelluspalvelimelle, tietokantapalvelimelle ja suuttimille)
• Verkko / sovelluspalvelin (esimerkiksi IIS, JBoss, Jaguar Server, Tomcat jne.)
• DB Server (PGA- ja SGA-koko Oraclen ja MSSQL-palvelimen, SP: n jne. Tapauksessa)
• Verkon kaistanleveyden käyttö
• Sisäinen ja ulkoinen verkkokortti klustereiden sattuessa
• Kuormituksen tasapainotin (ja että se jakaa kuorman tasaisesti kaikkiin klusterien solmuihin)
• Datavirta (laske kuinka paljon dataa siirretään asiakkaalle ja palvelimelle ja sieltä pois - laske sitten, riittääkö verkkokortin kapasiteetti simuloimaan X-käyttäjien määrää)

Luo VUGen-komentosarjoja

Seuraava vaihe suunnittelun jälkeen on luoda VUser-komentosarjat.

Skenaarion luominen

Seuraava vaihe on luoda latausskenaario

Skenaarion toteutus

Skenaarion toteutus on paikka, jossa matkitaan palvelimen käyttäjän kuormitusta käskemällä useita ajoneuvoyksiköitä suorittamaan tehtäviä samanaikaisesti.

Voit asettaa kuormituksen tason lisäämällä ja vähentämällä tehtäviä samanaikaisesti suorittavien ajoneuvoyksiköiden määrää.

Tämä suoritus saattaa johtaa siihen, että palvelin joutuu stressiin ja käyttäytyy epänormaalisti. Tämä on suorituskyvyn testauksen tarkoitus. Piirrettyjä tuloksia käytetään sitten yksityiskohtaiseen analyysiin ja perussyyn tunnistamiseen.

Tulosten analyysi (jota seuraa järjestelmän säätäminen)

Skenaarion suorittamisen aikana LoadRunner tallentaa sovelluksen suorituskyvyn eri kuormilla. Testin suorituksesta kerätyt tilastot tallennetaan ja yksityiskohtaanalyysi suoritetaan. 'HP Analysis' -työkalu luo erilaisia ​​kaavioita, jotka auttavat tunnistamaan järjestelmän suorituskyvyn viivästymisen perimmäiset syyt sekä järjestelmän vian.

Jotkut saaduista kaavioista ovat:

• Aika ensimmäiseen puskuriin
• Tapahtuman vasteaika
• Keskimääräinen tapahtumavasteaika
• Osumia sekunnissa
• Windowsin resurssit
• Virhetilastot
• Liiketoimien yhteenveto

UKK

Mitä sovelluksia meidän tulisi testata?

Suorituskyvyn testaus tehdään aina vain asiakas-palvelin-pohjaisiin järjestelmiin. Tämä tarkoittaa, että kaikki sovellukset, jotka eivät ole asiakaspalvelinpohjaisia ​​arkkitehtuureja, eivät saa vaatia suorituskyvyn testausta.

Esimerkiksi Microsoft Calculator ei ole asiakaspalvelinpohjainen eikä sillä ole useita käyttäjiä; joten se ei ole ehdokas suorituskyvyn testaamiseen.

Mikä on ero suorituskyvyn testauksen ja suorituskyvyn suunnittelun välillä

On tärkeää ymmärtää ero suorituskyvyn testauksen ja suorituskyvyn suunnittelun välillä. Ymmärrys jaetaan alla:

Suorituskykytestaus on tieteenala , joka liittyy ohjelmistosovelluksen nykyisen suorituskyvyn testaamiseen ja raportointiin useilla parametreilla.

Suoritustekniikka on prosessi, jolla ohjelmistoja testataan ja viritetään vaaditun suorituskyvyn toteuttamiseksi. Tämän prosessin tarkoituksena on optimoida sovelluksen tärkein ominaisuus eli käyttökokemus.

Historiallisesti testaus ja viritys ovat olleet selvästi erillisiä ja usein kilpailevia alueita. Viime vuosina useat testaajien ja kehittäjien taskut ovat kuitenkin tehneet itsenäistä yhteistyötä viritystiimien luomiseksi. Koska nämä joukkueet ovat saavuttaneet merkittävää menestystä, suorituskyvyn testaamisen yhdistäminen suorituskyvyn viritykseen on tarttunut, ja nyt me kutsumme sitä suorituskyvyn suunnitteluksi.