Testiranje performansi SAP-a: opterećenje, istodobnost i alati

Testiranje performansi SAP-a prije puštanja u rad dokazuje da kritične transakcije, pozadinski poslovi i sučelja postižu dogovorena vremena odziva kada mnogo korisnika i poslova radi istodobno. Prema mom iskustvu važni su testovi istodobnosti, izvedeni na maskiranim podacima produkcijskog volumena, prema kriterijima prolaza i pada koje je poslovanje dogovorilo prije prvog izvođenja.

Ovaj je vodič za CIO-e, direktore programa i voditelje testiranja na S/4HANA programima, uključujući RISE with SAP. Pokriva što testirati, koji su Vam podaci potrebni, kako napisati kriterije prihvaćanja, koji alati obavljaju posao i tko je za što odgovoran. Gdje se performanse nalaze među ostalim vrstama testiranja, pročitajte najprije u mom pregledu SAP testiranje objašnjeno.

Problemi s performansama na SAP programima rijetko su iznenađenje.

Fiori pločice istječu kada se stotine korisnika prijave na početku smjene. Prilagođeni izvještaj se zamrzne jer je netko pokrenuo neograničen odabir fiskalne godine nad vrlo velikom tablicom. Pozadinski poslovi preklapaju se na kraju mjeseca i izvođenje knjiženja se prekida.

To je predvidljivo. Jedino je pitanje je li program to testirao ili će poslovanje to otkriti dok obrađuje stvarne narudžbe.

Testiranje performansi kroz SAP Activate

1. 01

   Explore

   Identificirajte rizike performansi u dizajnu. Arhitektura i oblik izvještaja određuju ishode prije nego što je napisan kod.

2. 02

   Realize

   Izvodite testove volumena i opterećenja kako se konfiguracija stabilizira. Djelomična konfiguracija daje zavaravajuće rezultate.

3. 03

   Prije UAT-a

   Dovršite cijeli ciklus testiranja performansi prije UAT-a, a ne kao njegov dio.

4. 04

   Cutover

   Cutover odobrite prema unaprijed dogovorenim kriterijima prihvaćanja, a ne prema mišljenju.

5. 05

   Hypercare

   Pratite ključne pokazatelje u radu 30 do 60 dana. Većina regresija pojavi se u prvom ciklusu zatvaranja.

U ECC sustavu na tradicionalnoj bazi podataka testiranje performansi značilo je testiranje opterećenja aplikacijskog poslužitelja i baze: ABAP runtime, performanse SQL-a i raspoređivanje poslova. Sučelje je bio SAP GUI, koji je rijetko koga iznenadio.

Na S/4HANA, s Fiori sučeljima, ekstenzijama na SAP BTP-u i integracijom kroz SAP Cloud Integration, performanse ovise o nekoliko slojeva istodobno. Spora Fiori pločica može biti dug ABAP poziv, istek vremena na gatewayu, OData servis koji nije dizajniran za istodobne zahtjeve ili mrežna latencija u hibridnom okruženju. Testiranje samo backenda to neće pronaći.

1. 01Pokretanje pločiceNavala prijava na početku smjene
2. 02OData pozivIstek vremena na gatewayu, servisi koji nisu građeni za istodobnost
3. 03ABAP obradaDugotrajni ABAP pozivi
4. 04Čitanje iz bazeNeograničeni odabiri nad velikim tablicama
5. 05PrikazPlus mrežna latencija za udaljene lokacije

Jedno vrijeme odziva, mjereno od početka do kraja

Testiranje performansi SAP HANA ima vlastitu specifičnost pri konverziji. Stabilan ECC kod ponaša se drukčije na in-memory bazi podataka. Mnogi programi postaju mnogo brži, dok neki na određenim obrascima podataka daju neočekivane profile, pa regresija teškog prilagođenog koda specifična za konverziju nije opcionalna.

Integracijski tokovi dodaju vlastiti rizik. Tokovi koji su u razvoju radili s pojedinačnim testnim porukama mogu se pri produkcijskim volumenima nagomilati u redu čekanja ili tiho pasti. Simptomi izgledaju kao nešto drugo: povremeni neuspjesi narudžbi, neusklađeni računi, podaci prisutni u jednom sustavu, a nedostaju u drugom.

Testiranje performansi mora se dogoditi prije puštanja u rad. Testovi koje smatram važnima su testovi istodobnosti: mnogo korisnika i poslova koji istodobno opterećuju iste transakcije, tablice i servise.

Jedan korisnik koji prodajni nalog izvede za dvije sekunde ne dokazuje gotovo ništa. Isti nalog dok 150 ljudi unosi narudžbe, u pozadini teče izvođenje isporuka, a sučelje knjiži ulazne poruke, test je koji predviđa prvi dan.

Ova tablica pokazuje što svaka vrsta testa dokazuje i kada je izvesti:

Test	Što dokazuje	Kada ga izvesti	Što obično pronađe
Istodobnost	Mnogo korisnika i poslova može istodobno raditi na istim objektima	Realize, kada je konfiguracija stabilna, i ponovno prije UAT-a	Čekanja na zaključavanja, navale prijava, uska grla na gatewayu
Opterećenje	Sustav postiže vremena odziva pri očekivanom vršnom volumenu	Realize, nakon što skripte za istodobnost rade	Spori OData servisi, teški prilagođeni izvještaji
Stres	Gdje sustav puca iznad projektiranih granica	Prije UAT-a, ako se očekuje rast	Praznine u dimenzioniranju, ograničenja redova čekanja
Izdržljivost (soak)	Sustav satima stabilno podnosi opterećenje	Prije UAT-a, idealno kroz simulirano zatvaranje	Rast memorije, sukobi lanaca poslova kroz ponovljena izvođenja
Od početka do kraja	Cijeli put na koji korisnik čeka postiže cilj	Uz testove opterećenja	Problemi nevidljivi kada se svaki sloj testira zasebno

Ključna riječ u testiranju opterećenja je očekivano. Trebate stvarne volumene transakcija, broj korisnika i obrasce sesija. Test opterećenja izgrađen na procjenama volumena za koje su svi već znali da su optimistične daje prolaz koji ništa ne znači.

Test izdržljivosti najčešće se preskače. Testiranje volumena općenito je prečac koji programi najčešće uzimaju kada se vremenski plan sabije i zbog kojeg najviše žale.

Ove skriptirajte prve. Pokrivaju većinu neuspjeha koji stignu do produkcije.

1. Promjena smjene i vršne prijave. Kada nekoliko stotina korisnika istodobno otvori Fiori launchpad, autentifikacija i prikaz launchpada naglo skoče. Sustav koji je izvan vršnog vremena u redu može u tom prozoru biti neupotrebljiv ako istodobne prijave nikada nisu testirane.
2. Zatvaranje mjeseca i godine. Knjiženja velikog volumena, lanci poslova sa strogim redoslijedom i financijski tim koji se utrkuje s fiksnim rokom. Lance poslova zatvaranja izvedite od početka do kraja s volumenima razdoblja zatvaranja, a ne s prosječnim dnevnim brojkama.
3. Preklapajući pozadinski poslovi. Batch poslovi obično se testiraju jedan po jedan, što ne odražava stvarnost. Jedan loše optimiziran posao može blokirati nekoliko drugih, a zatvaranje prekorači svoj prozor.
4. Neograničeni prilagođeni izvještaji. Izvještaj koji na testnim podacima vraća rezultat trenutačno može na cijeloj fiskalnoj godini trajati minutama. Testirajte tipične i najgore odabire, a neograničene blokirajte.
5. Korisnici u više regija. Mrežna latencija utječe na svaku transakciju. RISE premješta hosting na SAP, ali latencija i dalje ovisi o regiji koju odaberete i usmjeravanju do Vaših korisnika, pa testirajte s najudaljenijih lokacija.

Moj vodič za migraciju s ECC-a na S/4HANA pokriva gdje se testiranje konverzije uklapa u širi plan.

Testni podaci na produkcijskoj razini

Podaci odlučuju znači li išta od ovoga nešto. Inzistiram na maskiranim podacima na produkcijskoj razini: produkcijski volumen i produkcijska realističnost, s maskiranim osobnim i osjetljivim poljima.

Kupac s 200.000 otvorenih stavki narudžbi ponaša se drukčije od kupca s 5.000. Filtri koji u oskudnom testnom klijentu vraćaju rezultat trenutačno u produkciji istječu. Za visokorizična područja pripremite volumen, koristite reprezentativnu kombinaciju transakcija i gdje možete izvodite stvarne pozive sučelja.

Kako te podatke dobiti sigurno, kroz kopije, alate za selektivne testne podatke i maskiranje, opisano je u mom vodiču za upravljanje SAP testnim podacima. Osvježavanje planirajte prije prvog ciklusa testiranja performansi, jer traje dulje nego što većina planova testiranja pretpostavlja.

Kriterije dogovorite s poslovanjem u fazi Prepare, prije nego što se izvede ijedan test. Svaki navodi transakciju ili posao, opterećenje i prag.

Ovi primjeri pokazuju oblik. Vlastite brojke odredite prema operativnim potrebama:

Stavka	Uvjet opterećenja	Prag prolaza	Vlasnik
Kreiranje prodajnog naloga (VA01 ili Fiori aplikacija)	150 istodobnih korisnika koji unose narudžbe	Manje od 3 sekunde za 95 % transakcija	Vlasnik procesa order-to-cash
Prvo učitavanje Fiori launchpada na početku smjene	Vršne istodobne prijave za najveću smjenu	Manje od 5 sekundi za 95 % korisnika	Voditelj IT operacija
Lanac poslova zatvaranja mjeseca	Volumeni razdoblja zatvaranja, cijeli slijed	Završava unutar dogovorenog prozora zatvaranja bez prekida	Financijski kontrolor
Ulazno sučelje za narudžbe	Vršni satni volumen poruka	Nema zaostatka u redu čekanja starijeg od 15 minuta	Voditelj integracije
Prilagođeni izvještaj velikog volumena	Puni produkcijski volumen podataka, tipičan odabir	Manje od 60 sekundi; neograničeni odabiri blokirani	Vlasnik izvještaja

„Sustav bi trebao biti dovoljno brz za poslovne operacije" ne može se testirati ni prihvatiti. Mijenjanje kriterija nakon što stignu rezultati poništava smisao njihova postojanja.

Ako je sustav prošao jer su korisnici u UAT-u rekli da djeluje brzo, imate mišljenje, a ne kriterij prihvaćanja. Neka rezultati budu formalna vrata prije cutovera, kako opisuje moj vodič za SAP quality gates. Ukupni plan ciklusa, s ulaznim i izlaznim kriterijima za svaku fazu testiranja, pripada Vašoj strategiji testiranja S/4HANA.

Alati za testiranje performansi SAP-a

Test performansi treba tri stvari: generator opterećenja koji može pokretati SAP protokole, praćenje na strani SAP-a i mjesto za upravljanje testnim slučajevima i rezultatima. LoadRunner je alat za opterećenje koji su moji timovi koristili na SAP programima. Alat imenujte u planu testiranja rano, jer za licence, generatore opterećenja i vještine skriptiranja treba vremena.

Glavne opcije u 2026.:

Alat	Uloga	Što treba znati
OpenText Professional Performance Engineering	Generiranje opterećenja	Proizvod koji se ranije zvao LoadRunner Professional. Njegovi paketi protokola pokrivaju SAP, SAP GUI i SAP Web
Tricentis NeoLoad	Generiranje opterećenja	Tricentis navodi podršku za SAP GUI, Fiori, RFC i IDoc, a može ponovno koristiti Tricentis Tosca resurse
Apache JMeter	Generiranje opterećenja	Otvoreni kod. Pokreće HTTP promet kao što su Fiori i OData pozivi
SAP Cloud ALM	Upravljanje testiranjem	Priprema i izvodi ručne i automatizirane testne slučajeve i prati nedostatke. Sam ne generira opterećenje
SAP Solution Manager	Upravljanje testiranjem	Standardno održavanje završava 31. prosinca 2027., pa novi posao planirajte u Cloud ALM-u

Za širi pregled funkcionalnih alata i alata za automatizaciju pogledajte moju usporedbu alata za SAP testiranje i validaciju. Alat je manje važan od skripti, podataka i kriterija.

RISE with SAP dijeli odgovornost

U okviru RISE with SAP, SAP je odgovoran za infrastrukturu: dimenzioniranje, regiju hyperscalera, mrežu i dostupnost platforme. Klijent i partner odgovorni su za aplikacijski sloj.

SAP-ov dokument o ulogama i odgovornostima za RISE to jasno kaže. Izvođenje testova opterećenja i podešavanje skupih SQL naredbi spadaju u SAP Cloud Application Services uz dodatnu naplatu. Ako ih ne kupite, posao radi korisnik.

Čest neuspjeh na RISE programima je pretpostavka da će SAP uhvatiti probleme s performansama jer upravlja infrastrukturom. Uhvatit će probleme s infrastrukturom. Podjelu upišite u povelju programa i plan testiranja:

1. SAP: dostupnost infrastrukture i odziv na razini platforme
2. Partner: performanse aplikacije pod definiranim opterećenjem, uključujući ekstenzije i integracijske tokove
3. Klijent: ishodi na razini procesa kao što su trajanje zatvaranja i protok narudžbi te odluka o prihvaćanju

Javni cloud sužava opseg

Na public editionu SAP-ova cloud ERP-a sustav radi na zajedničkoj platformi kojom upravlja SAP. Prije nego što planirate bilo kakav test opterećenja na tenantu, pisanim putem pitajte SAP je li to dopušteno i koju najavu treba.

Vaše se testiranje tada pomiče na ono što je Vaše: prilagođene integracije, ekstenzije, izvještaje velikog volumena, slijed zatvaranja i mrežni put od Vaših lokacija. Problemi s performansama platforme idu SAP-ovoj podršci.

Česte pogreške

1. Funkcionalno testiranje tretira se kao testiranje performansi. Funkcionalni testovi dokazuju da transakcija daje pravi rezultat. Ne govore ništa o 150 ljudi koji je izvode istodobno.
2. Performanse se prepuštaju Basisu. Basis je odgovoran za dimenzioniranje i raspoređivanje poslova. Nije odgovoran za dizajn izvještaja, arhitekturu OData servisa ni dizajn integracijskih tokova, a upravo oni pokreću performanse aplikacije.
3. Vlasništvo se daje samo QA-u. QA izvodi testove i izvještava o rezultatima, ali odluke koje uzrokuju probleme s performansama donose se u dizajnu. Voditelj testiranja ili arhitekt na razini programa treba ovlasti da ih rano ospori, a RACI treba reći tko može blokirati puštanje u rad zbog performansi.
4. Praznine se prihvaćaju kao poznati problemi. Većina programa s problemima performansi u produkciji nije preskočila testiranje. Testirali su bez dogovorenih kriterija ili su testirali, a zatim pod pritiskom rasporeda prihvatili neuspjehe.

Napišite pet ili šest kriterija prihvaćanja za svoje najrizičnije transakcije i poslove, s imenovanim vlasnikom za svaki. Ako ne možete ispuniti gornju tablicu, niste spremni za testiranje i pronašli ste prvu prazninu.

Zatim provjerite dvije stvari: da je osvježavanje maskiranih podataka produkcijskog volumena u planu i da ciklus istodobnosti završava prije početka UAT-a.

Ako želite neovisan pogled na plan testiranja performansi ili odluku o puštanju u rad, pomažem organizacijama u tome. Ovdje me možete kontaktirati.

Što je testiranje performansi SAP-a?

Provjerava kako se SAP ponaša pod realističnim opterećenjem: vremena odziva korisničkih transakcija, trajanje pozadinskih poslova, protok sučelja i korištenje resursa kada mnogo ljudi radi istodobno. Mora se provesti prije puštanja u rad.

Funkcionalna ispravnost i performanse različita su svojstva. Transakcija koja je ispravna za jednog korisnika može isteći za njih 200.

Kada bi testiranje performansi trebalo početi na SAP programu?

Identifikacija rizika počinje u fazi Explore, jer arhitektonske odluke određuju ishode performansi. Aktivno testiranje počinje u fazi Realize, kada je konfiguracija dovoljno stabilna da rezultati nešto znače.

Završni ciklus dovršite prije UAT-a, a ne tijekom njega. Nedostaci u performansama pronađeni u UAT-u stišću raspored i stvaraju pritisak da se prihvate kao poznati problemi.

Koja je razlika između testiranja opterećenja i testiranja istodobnosti u SAP-u?

Testiranje opterećenja provjerava vremena odziva pri očekivanom vršnom volumenu. Testiranje istodobnosti provjerava što se događa kada mnogo korisnika i poslova u istom trenutku radi na istim transakcijama, tablicama i servisima. Tu se pokazuju čekanja na zaključavanja, navale prijava i uska grla na gatewayu.

Prema mom iskustvu važni su testovi istodobnosti. Izvedite ih prve, a zatim na njima izgradite puni test opterećenja.

Koje testne podatke treba koristiti testiranje performansi SAP-a?

Maskirane podatke na produkcijskoj razini. To znači produkcijski volumen i realističnost, s maskiranim osobnim i osjetljivim poljima. Oskudni testni podaci skrivaju spore filtre, teške izvještaje i duga trajanja poslova koji se pojave prvog dana.

Koji se alati koriste za testiranje performansi SAP-a?

Opterećenje pokreću generatori opterećenja kao što su OpenText Professional Performance Engineering (ranije LoadRunner Professional), Tricentis NeoLoad i Apache JMeter. SAP Cloud ALM ili SAP Solution Manager upravljaju testnim slučajevima i rezultatima, a praćenje na strani SAP-a pokazuje što je sustav radio pod opterećenjem.

Tko je odgovoran za testiranje performansi na RISE with SAP?

SAP je odgovoran za infrastrukturu: dimenzioniranje, regiju, mrežu i dostupnost platforme. SAP-ov dokument o ulogama i odgovornostima za RISE ostavlja izvođenje testova opterećenja i podešavanje skupog SQL-a korisniku, osim ako se SAP Cloud Application Services kupe uz dodatnu naplatu.

Klijent i partner odgovorni su za performanse aplikacije i odluku o prihvaćanju. Podjelu upišite u kriterije prihvaćanja, tako da svaki prag ima vlasnika.