Kas ir LoadRunner?
LoadRunner ir veiktspējas testēšanas rīks, kuru Mercury aizsāka 1999. gadā. LoadRunner vēlāk 2006. gadā iegādājās HPE. 2016. gadā LoadRunner iegādājās MicroFocus.
LoadRunner atbalsta dažādus izstrādes rīkus, tehnoloģijas un sakaru protokolus. Faktiski tas ir vienīgais rīks tirgū, kas atbalsta tik lielu protokolu skaitu, lai veiktu veiktspējas testēšanu. LoadRunner programmatūras veiktie veiktspējas pārbaudes rezultāti tiek izmantoti kā etalons salīdzinājumā ar citiem rīkiem
Šajā apmācībā jūs uzzināsiet
- Kāpēc LoadRunner?
- Kāpēc jums nepieciešama veiktspējas pārbaude?
- Kas ir LoadRunner arhitektūra?
- Veiktspējas pārbaudes ceļvedis: detalizēti soļi
- FAQ
Kāpēc LoadRunner?
LoadRunner ir ne tikai pionieris veiktspējas testēšanā, bet arī joprojām ir tirgus līderis veiktspējas testēšanas paradigmā. Nesenajā novērtējumā LoadRunner ir aptuveni 85% tirgus daļa veiktspējas testēšanas nozarē.
Kopumā LoadRunner rīks atbalsta RIA (bagātīgas interneta lietojumprogrammas), Web 2.0 (HTTP / HTML, Ajax, Flex un Silverlight uc), mobilo, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail un galvenokārt Windows Socket. Tirgū nav neviena konkurenta rīka, kas varētu piedāvāt tik plašu protokolu klāstu, kas pieder vienam rīkam.
Pārliecinošāk programmatūras testēšanā izvēlēties LoadRunner ir šī rīka uzticamība. LoadRunner rīks jau sen ir izveidojis reputāciju, jo bieži jūs atradīsit klientus, kuri verificēs jūsu veiktspējas etalonus, izmantojot LoadRunner. Jūs atradīsit atvieglojumu, ja jau izmantojat LoadRunner veiktspējas testēšanas vajadzībām.
LoadRunner programmatūra ir cieši integrēta ar citiem HP rīkiem, piemēram, Vienotais funkcionālais tests (QTP) un ALM (Lietojumprogrammas dzīves cikla pārvaldība), ļaujot jums veikt testēšanas procesus no gala līdz beigām.
LoadRunner darbojas pie galvenā virtuālo lietotāju simulēšanas priekšmeta lietojumprogrammā. Šie virtuālie lietotāji tiek saukti arī par transportlīdzekļa bloka lietotājiem, kas atkārtojas klienta pieprasījumos un sagaida atbilstošu atbildi uz darījuma nokārtošanu.
Kāpēc jums nepieciešama veiktspējas pārbaude?
Aptuveni 4,4 miljardu ieņēmumu zaudējumi tiek reģistrēti katru gadu sliktas tīmekļa veiktspējas dēļ.
Mūsdienu Web 2.0 laikmetā lietotāji noklikšķina, ja vietne nereaģē 8 sekunžu laikā. Iedomājieties, kā jūs gaidāt 5 sekundes, meklējot Google vai veicot drauga pieprasījumu Facebook. Veiktspējas dīkstāves sekas bieži ir postošākas, nekā jebkad iedomāties. Mums ir tādi piemēri kā tie, kas nesen skāra Bank of America Online Banking, Amazon Web Services, Intuit vai Blackberry.
Saskaņā ar Dunn & Bradstreet datiem 59% no Fortune 500 uzņēmumiem katru nedēļu tiek novērotas aptuveni 1,6 stundas dīkstāves. Ņemot vērā, ka vidējais Fortune 500 uzņēmums, kurā strādā vismaz 10 000 darbinieku, maksā 56 USD stundā, šādas organizācijas dīkstāves izmaksas darbaspēka daļā būtu 896 000 USD nedēļā, kas nozīmē vairāk nekā 46 miljonus USD gadā.
Tiek lēsts, ka tikai 5 minūtes ilgs Google.com dīkstāves laiks (19. augusts-13) meklēšanas gigantam izmaksās pat 545 000 USD.
Tiek lēsts, ka nesenā Amazon Web Service pārtraukuma dēļ uzņēmumi zaudēja pārdošanas apjomus 1100 USD sekundē.
Ja programmatūru sistēmu izvieto organizācija, tā var saskarties ar daudziem scenārijiem, kas, iespējams, noved pie veiktspējas kavēšanās. Vairāki faktori samazina veiktspēju, daži piemēri var būt:
- Palielināts datu bāzē esošo ierakstu skaits
- Palielināts vienlaicīgi sistēmā veikto pieprasījumu skaits
- vairāk lietotāju, kas vienlaikus piekļūst sistēmai, salīdzinot ar iepriekšējo
Kas ir LoadRunner arhitektūra?
Kopumā runājot, HP LoadRunner arhitektūra ir sarežģīta, tomēr viegli saprotama.
Pieņemsim, ka jums ir uzdots pārbaudīt Amazon.com veiktspēju 5000 lietotājiem
Reālajā dzīvē šie visi 5000 lietotāji neatrodas mājas lapā, bet citā vietņu sadaļā. Kā mēs varam simulēt atšķirīgi
VUGen:
VUGen jeb Virtual User Generator ir IDE (integrēta izstrādes vide) vai bagātināta kodēšanas redaktors. VUGen tiek izmantots, lai atkārtotu sistēmas zem slodzes (SUL) darbību. VUGen nodrošina "ierakstīšanas" funkciju, kas reģistrē saziņu ar un no klienta un servera kodēta skripta veidā, ko sauc arī par VUser skriptu.
Tātad, ņemot vērā iepriekš minēto piemēru, VUGen var ierakstīt, lai simulētu šādus biznesa procesus:
- Sērfošana Amazon.com produktu lapā
- Izrakstīšanās
- Maksājumu apstrāde
- Mana konta lapas pārbaude
Kontrolieris
Kad VUser skripts ir pabeigts, Controller ir viens no galvenajiem LoadRunner komponentiem, kas kontrolē slodzes simulāciju, pārvaldot, piemēram:
- Cik daudz VU lietotāju simulēt katram biznesa procesam vai VUser grupai
- VU lietotāju uzvedība (uzbraukt uz augšu, uz leju, vienlaikus vai vienlaikus) utt.)
- Slodzes scenārija veids, piemēram, reālā dzīve vai mērķis, vai SLA pārbaude
- Kādus injektorus lietot, cik VU lietotāju pret katru inžektoru
- Periodiski apkopojiet rezultātus
- IP izkrāpšana
- Ziņošana par kļūdu
- Darījumu pārskati utt.
Ņemot analoģiju no mūsu kontroliera piemēra, VUGen skriptam tiks pievienots šāds parametrs
1) 3500 lietotāji sērfo Amazon.com produktu lapā
2) Checkout ir 750 lietotāji
3) 500 lietotāji veic maksājumu apstrādi
4) 250 lietotāji pārbauda MyAccount lapu TIKAI pēc tam, kad 500 lietotāji ir veikuši maksājumu apstrādi
Iespējami vēl sarežģītāki scenāriji
- Inicializējiet 5 VU lietotājus ik pēc 2 sekundēm, līdz tiek sasniegta 3500 VU lietotāju slodze (sērfošana Amazon produkta lapā).
- Atkārtojiet 30 minūtes
- Apturēt iterāciju 25 VU lietotājiem
- Atkārtoti sāciet 20 VUSers
- Katru sekundi iniciējiet 2 lietotājus (Checkout, Payment Processing, MyAccounts lapā).
- Mašīnā A tiks ģenerēti 2500 VU lietotāji
- Mašīnā B tiks ģenerēti 2500 VU lietotāji
Aģenti Mašīnu / slodzes ģeneratori / inžektori
HP LoadRunner kontrolieris ir atbildīgs par tūkstošiem VU lietotāju simulāciju - šie VU patērē aparatūras resursus, piemēram, procesoru un atmiņu, tādējādi ierobežojot mašīnu, kas tos simulē. Turklāt kontrolieris simulē šos transportlīdzekļa blīvus no vienas mašīnas (kur dzīvo kontrolieris), un tāpēc rezultāti var nebūt precīzi. Lai novērstu šīs bažas, visi VU lietotāji ir sadalīti pa dažādām mašīnām, ko sauc par slodzes ģeneratoriem vai slodzes inžektoriem.
Parasti kontrolieris dzīvo citā mašīnā, un slodze tiek imitēta no citām mašīnām. Atkarībā no VUser skriptu protokola un mašīnas specifikācijām, pilnīgai simulācijai var būt nepieciešami vairāki slodzes inžektori. Piemēram, HTTP skripta VU lietotājiem simulācijai būs nepieciešami 2–4 MB uz vienu VUser, tāpēc, lai simulētu 10 000 VU lietotāju slodzi, būs nepieciešamas 4 mašīnas ar 4 GB RAM.
Ņemot analoģiju no mūsu Amazon piemēra, šī komponenta produkcija būs
Analīze:
Kad slodzes scenāriji ir izpildīti, parādās LoadRunner komponentu " Analīze " loma.
Izpildes laikā kontrolieris izveido rezultātu izgāšanu neapstrādātā veidā un satur informāciju, piemēram, kura LoadRunner versija izveidoja šo rezultātu izgāztuvi un kādas bija konfigurācijas.
Visas kļūdas un izņēmumi tiek reģistrēti Microsoft piekļuves datu bāzē ar nosaukumu output.mdb. Komponents "Analīze" nolasa šo datu bāzes failu, lai veiktu dažāda veida analīzi, un ģenerē diagrammas.
Šie grafiki parāda dažādas tendences, lai izprastu kļūdu un neveiksmes spriedzi zem slodzes; tādējādi palīdziet saprast, vai ir nepieciešama optimizācija SUL, Server (piemēram, JBoss, Oracle) vai infrastruktūrā.
Tālāk ir sniegts piemērs, kur joslas platums varētu radīt sašaurinājumu. Pieņemsim, ka tīmekļa servera jauda ir 1 GB / s, turpretī datu plūsma pārsniedz šo jaudu, izraisot nākamos lietotājus. Lai noteiktu sistēmu, kas atbilst šādām vajadzībām, Performance Engineer jāanalizē lietojumprogrammu darbība ar neparastu slodzi. Zemāk ir diagramma, ko LoadRunner ģenerē, lai iegūtu joslas platumu.
Veiktspējas pārbaudes ceļvedis: detalizēti soļi
Veiktspējas pārbaudes ceļvedi var sadalīt 5 posmos:
- Slodzes testa plānošana
- Izveidojiet VUGen skriptus
- Scenārija izveide
- Scenārija izpilde
- Rezultātu analīze (kam seko sistēmas uzlabošana)
Tagad, kad esat instalējis LoadRunner, sapratīsim procesā iesaistītās darbības pa vienai.
Veiktspējas pārbaudes procesā iesaistītie soļi
Slodzes testa plānošana
Veiktspējas testēšanas plānošana atšķiras no SIT (sistēmas integrācijas testēšana) vai UAT (lietotāju pieņemšanas pārbaude) plānošanas. Plānošanu var sīkāk sadalīt mazos posmos, kā aprakstīts zemāk:
Saliec savu komandu
Sākot darbu ar LoadRunner testēšanu, vislabāk ir dokumentēt, kurš piedalīsies aktivitātē no katras procesa laikā iesaistītās komandas.
Projektu menedžeris:
Izvirziet projekta vadītāju, kuram pieder šī darbība, un kalpos kā eskalācijas galvenā persona.
Funkciju eksperts / biznesa analītiķis:
Sniedziet SUL lietošanas analīzi un sniedz zināšanas par tīmekļa vietnes / SUL biznesa funkcionalitāti
Veiktspējas testēšanas eksperts:
Izveido automatizētos veiktspējas testus un izpilda ielādes scenārijus
Sistēmas arhitekts:
Nodrošina SUL projektu
Tīmekļa izstrādātājs un MVU:
- Uztur vietni un nodrošina uzraudzības aspektus
- Izstrādā vietni un novērš kļūdas
Sistēmas administrators:
- Uztur iesaistītos serverus visā testa laikā
Iesaistītās lietojumprogrammas un biznesa procesi:
Veiksmīgai slodzes pārbaudei ir nepieciešams veikt noteiktu biznesa procesu. Biznesa process sastāv no skaidri definētām darbībām atbilstoši vēlamajiem biznesa darījumiem, lai sasniegtu slodzes pārbaudes mērķus.
Prasību metriku var sagatavot, lai izraisītu lietotāju slodzi sistēmā. Tālāk ir sniegts apmeklējumu sistēmas piemērs uzņēmumā:
Iepriekš minētajā piemērā skaitļos minēts ar lietojumprogrammu (SUL) savienoto lietotāju skaits attiecīgajā stundā. Mēs varam iegūt maksimālo lietotāju skaitu, kas saistīti ar uzņēmējdarbības procesu jebkurā diennakts stundā, kas tiek aprēķināts labākajās slejās.
Līdzīgi mēs varam secināt kopējo lietotāju skaitu, kas saistīti ar lietojumprogrammu (SUL) jebkurā diennakts stundā. Tas tiek aprēķināts pēdējā rindā.
Iepriekš minētie 2 fakti kopā dod mums kopējo lietotāju skaitu, ar kuriem mums jāpārbauda sistēmas veiktspēja.
Definējiet testa datu pārvaldības procedūras
Veiktspējas testēšanas statistiku un novērojumus lielā mērā ietekmē daudzi faktori, kas aprakstīti iepriekš. Izšķiroša nozīme ir testa datu sagatavošanai veiktspējas pārbaudei. Dažreiz konkrēts biznesa process patērē datu kopu un rada citu datu kopu. Ņemiet piemēru zemāk:
- Lietotājs A izveido finanšu līgumu un iesniedz to pārskatīšanai.
- Cits lietotājs B apstiprina 200 līgumus dienā, ko izveidojis lietotājs A
- Cits lietotājs C maksā aptuveni 150 līgumus dienā, ko apstiprinājis lietotājs B
Šajā situācijā lietotājam B sistēmā jābūt “izveidotiem” 200 līgumiem. Turklāt, lai modelētu 150 lietotāju slodzi, lietotājam C nepieciešami 150 līgumi, kas ir "apstiprināti".
Tas netieši nozīmē, ka jums ir jāizveido vismaz 200 + 150 = 350 līgumi.
Pēc tam apstipriniet 150 līgumus, kas kalpos kā C lietotāja testa dati - pārējie 200 līgumi tiks izmantoti kā lietotāja B testa dati.
Kontūru monitori
Spekulējiet katru faktoru, kas varētu ietekmēt sistēmas darbību. Piemēram, samazināta aparatūra potenciāli ietekmēs SUL (sistēmas zem slodzes) veiktspēju.
Uzskaitiet visus faktorus un iestatiet monitorus, lai jūs varētu tos noteikt. Šeit ir daži piemēri:
- Procesors (tīmekļa serverim, lietojumprogrammu serverim, datu bāzes serverim un inžektoriem)
- RAM (tīmekļa serverim, lietojumprogrammu serverim, datu bāzes serverim un inžektoriem)
- Tīmekļa / lietotņu serveris (piemēram, IIS, JBoss, Jaguar Server, Tomcat uc)
- DB Server (PGA un SGA izmērs Oracle un MSSQL Server, SP utt. Gadījumā)
- Tīkla joslas platuma izmantošana
- Iekšējais un ārējais NIC klasterizācijas gadījumā
- Slodzes līdzsvarotājs (un tas vienmērīgi sadala slodzi uz visiem kopu mezgliem)
- Datu plūsma (aprēķiniet, cik daudz datu pārvietojas uz un no klienta un servera, pēc tam aprēķiniet, vai NIC ietilpība ir pietiekama, lai simulētu X lietotāju skaitu)
Izveidojiet VUGen skriptus
Nākamais solis pēc plānošanas ir VUser skriptu izveide.
Scenārija izveide
Nākamais solis ir izveidot slodzes scenāriju
Scenārija izpilde
Scenārija izpilde ir vieta, kur jūs atdarināt lietotāja slodzi uz serveri, uzdodot vairākiem VU lietotājiem vienlaikus veikt uzdevumus.
Slodzes līmeni var iestatīt, palielinot un samazinot to VU lietotāju skaitu, kuri vienlaikus veic uzdevumus.
Šīs izpildes rezultātā serveris var nonākt stresa stāvoklī un rīkoties nenormāli. Tas ir pats veiktspējas testēšanas mērķis. Pēc tam iegūtos rezultātus izmanto detalizētai analīzei un galveno cēloņu identificēšanai.
Rezultātu analīze (kam seko sistēmas uzlabošana)
Scenārija izpildes laikā LoadRunner reģistrē lietojumprogrammas veiktspēju dažādās slodzēs. Testa izpildes laikā iegūtā statistika tiek saglabāta un tiek veikta detaļu analīze. Rīks “HP analīze” ģenerē dažādus grafikus, kas palīdz identificēt sistēmas veiktspējas aizkavēšanās pamatcēloņus, kā arī sistēmas kļūmi.
Daži no iegūtajiem grafikiem ietver:
- Laiks līdz pirmajam buferim
- Darījuma atbildes laiks
- Vidējais darījuma reakcijas laiks
- Hīti sekundē
- Windows resursi
- Kļūdu statistika
- Darījumu kopsavilkums
FAQ
Kuras lietojumprogrammas mums vajadzētu pārbaudīt?
Veiktspējas pārbaude vienmēr tiek veikta tikai klienta-servera sistēmām. Tas nozīmē, ka jebkurai lietojumprogrammai, kas nav klienta-servera arhitektūra, nav nepieciešama veiktspējas pārbaude.
Piemēram, Microsoft kalkulators nav balstīts uz klientu-serveri, un tajā darbojas vairāki lietotāji; līdz ar to tā nav kandidāte uz veiktspējas testēšanu.
Kāda ir atšķirība starp veiktspējas testēšanu un veiktspējas inženieriju
Ir svarīgi saprast atšķirību starp veiktspējas testēšanu un veiktspējas inženieriju. Zemāk ir kopīga izpratne:
Veiktspējas pārbaude ir disciplīna, kas saistīta ar programmatūras lietojumprogrammas pašreizējās veiktspējas testēšanu un ziņošanu ar dažādiem parametriem.
Veiktspējas inženierija ir process, kurā programmatūra tiek pārbaudīta un noregulēta ar mērķi realizēt nepieciešamo veiktspēju. Šī procesa mērķis ir optimizēt vissvarīgākās lietojumprogrammas veiktspējas īpašības, ti, lietotāja pieredzi.
Vēsturiski testēšana un pielāgošana ir bijusi izteikti atsevišķa un bieži vien konkurējoša sfēra. Tomēr pēdējos gados vairākas testētāju un izstrādātāju kabatas ir neatkarīgi sadarbojušās, lai izveidotu tūninga komandas. Tā kā šīs komandas ir guvušas ievērojamus panākumus, koncepcija par veiktspējas testēšanas apvienošanu ar veiktspējas pielāgošanu ir iekritusi, un tagad mēs to saucam par veiktspējas inženieriju.