SAP performans testi: yük, eşzamanlılık ve araçlar

SAP performans testi, canlıya geçişten önce kritik işlemlerin, arka plan işlerinin ve arayüzlerin, çok sayıda kullanıcı ve iş aynı anda çalışırken üzerinde anlaşılmış yanıt sürelerini karşıladığını kanıtlar. Deneyimime göre önemli olanlar eşzamanlılık testleridir: üretim hacminde maskelenmiş veriler üzerinde, iş biriminin ilk çalıştırmadan önce üzerinde anlaştığı geçme ve kalma kriterlerine göre çalıştırılan testler.

Bu rehber, RISE with SAP dahil S/4HANA programlarındaki CIO'lar, program direktörleri ve test liderleri için. Neyin test edileceğini, ihtiyaç duyduğunuz verileri, kabul kriterlerinin nasıl yazılacağını, hangi araçların bu işi yaptığını ve kimin neyin sahibi olduğunu ele alıyor. Performansın diğer test türleri arasındaki yeri için SAP testi genel bakışımla başlayın.

SAP programlarındaki performans sorunları nadiren sürpriz olur.

Vardiya başında yüzlerce kullanıcı oturum açtığında Fiori kutucukları zaman aşımına uğrar. Biri çok büyük bir tabloya karşı sınırsız bir mali yıl seçimi çalıştırdığı için özel bir rapor donar. Arka plan işleri ay sonunda çakışır ve kayıt çalıştırması iptal olur.

Bunlar öngörülebilir. Tek soru, programın bunları test edip etmediği ya da iş biriminin bunları gerçek siparişler akarken mi bulacağıdır.

SAP Activate boyunca performans testi

1. 01

   Explore

   Tasarımdaki performans risklerini belirleyin. Sonuçları, kod yazılmadan önce mimari ve rapor yapısı belirler.

2. 02

   Realize

   Yapılandırma istikrar kazandıkça hacim ve yük testleri çalıştırın. Yarım yapılandırma yanıltıcı sonuçlar üretir.

3. 03

   UAT öncesi

   Tam performans döngüsünü UAT'nin parçası olarak değil, UAT'den önce tamamlayın.

4. 04

   Cutover

   Cutover'ı görüşlere göre değil, önceden üzerinde anlaşılmış kabul kriterlerine göre onaylayın.

5. 05

   Hypercare

   Canlı KPI'ları 30 ila 60 gün izleyin. Gerilemelerin çoğu ilk kapanış döngüsünde ortaya çıkar.

Geleneksel bir veritabanı üzerindeki ECC sisteminde performans testi, uygulama sunucusunun ve veritabanının yük testi demekti: ABAP çalışma zamanı, SQL performansı ve iş zamanlaması. Ön yüz SAP GUI'ydi ve nadiren birini şaşırtırdı.

Fiori ön yüzleri, SAP BTP üzerindeki uzantılar ve SAP Cloud Integration üzerinden entegrasyonla S/4HANA'da ise performans aynı anda birkaç katmana bağlıdır. Yavaş bir Fiori kutucuğu uzun bir ABAP çağrısı, bir gateway zaman aşımı, eşzamanlı istekler için tasarlanmamış bir OData servisi veya hibrit bir kurulumdaki ağ gecikmesi olabilir. Yalnızca arka ucu test etmek bunu bulmaz.

1. 01Kutucuğun açılmasıVardiya başında oturum açma yığılmaları
2. 02OData çağrısıGateway zaman aşımları, eşzamanlılık için kurulmamış servisler
3. 03ABAP işlemeUzun süren ABAP çağrıları
4. 04Veritabanı okumasıBüyük tablolarda sınırsız seçimler
5. 05GörüntülemeAyrıca uzak lokasyonlar için ağ gecikmesi

Uçtan uca ölçülen tek bir yanıt süresi

SAP HANA performans testinin bir dönüşümde kendine özgü bir yanı vardır. İstikrarlı ECC kodu bellek içi bir veritabanında farklı davranır. Birçok program çok daha hızlı çalışırken bazıları belirli veri örüntülerinde beklenmedik profiller üretir; bu yüzden ağır özel kodun dönüşüme özgü regresyonu isteğe bağlı değildir.

Entegrasyon akışları kendi risklerini ekler. Geliştirmede tekil test mesajlarıyla çalışan akışlar, üretim hacimlerinde kuyrukta birikebilir veya sessizce başarısız olabilir. Belirtiler başka bir şeye benzer: aralıklı sipariş hataları, fatura uyuşmazlıkları, bir sistemde bulunup diğerinde eksik olan veriler.

Performans testi canlıya geçişten önce yapılmalıdır. Önemli saydığım testler eşzamanlılık testleridir: çok sayıda kullanıcının ve işin aynı işlemlere, tablolara ve servislere aynı anda yüklendiği testler.

Bir satış siparişini iki saniyede çalıştıran tek bir kullanıcı neredeyse hiçbir şey kanıtlamaz. Aynı sipariş, 150 kişi sipariş girerken, arka planda bir teslimat çalıştırması dönerken ve bir arayüz gelen mesajları kaydederken çalıştırıldığında, ilk günü öngören test odur.

Bu tablo, her test türünün neyi kanıtladığını ve ne zaman çalıştırılacağını gösteriyor:

Test	Neyi kanıtlar	Ne zaman çalıştırılır	Genellikle ne bulur
Eşzamanlılık	Çok sayıda kullanıcı ve iş aynı nesneler üzerinde aynı anda çalışabilir	Realize'da yapılandırma istikrar kazanınca ve UAT'den önce yeniden	Kilit beklemeleri, oturum açma yığılmaları, gateway darboğazları
Yük	Sistem beklenen tepe hacimde yanıt sürelerini karşılar	Realize'da, eşzamanlılık betikleri çalıştıktan sonra	Yavaş OData servisleri, ağır özel raporlar
Stres	Sistem tasarım sınırlarının üzerinde nerede kırılır	UAT'den önce, büyüme bekleniyorsa	Boyutlandırma açıkları, kuyruk sınırları
Dayanıklılık (soak)	Sistem saatlerce sabit yükü taşır	UAT'den önce, ideal olarak simüle edilmiş bir kapanış boyunca	Bellek artışı, tekrarlanan çalıştırmalarda iş zincirlerinin çakışması
Uçtan uca	Kullanıcının beklediği yolun tamamı hedefi karşılar	Yük testleriyle birlikte	Her katman ayrı test edildiğinde görünmeyen sorunlar

Yük testinde anahtar kelime "beklenen"dir. Gerçek işlem hacimlerine, kullanıcı sayılarına ve oturum örüntülerine ihtiyacınız var. Herkesin zaten iyimser olduğunu bildiği hacim tahminleri üzerine kurulan bir yük testi, hiçbir anlam taşımayan bir "geçti" verir.

En sık atlanan dayanıklılık testidir. Genel olarak hacim testi, zaman çizelgesi daraldığında programların en sık başvurduğu ve en çok pişman olduğu kestirmedir.

Önce bunları betiğe dökün. Üretime ulaşan başarısızlıkların çoğunu kapsarlar.

1. Vardiya değişimi ve tepe oturum açma. Birkaç yüz kullanıcı Fiori launchpad'i aynı anda açtığında kimlik doğrulama ve launchpad görüntüleme sıçrar. Yoğun olmayan saatlerde sorunsuz olan bir sistem, eşzamanlı oturum açmalar hiç test edilmediyse bu pencerede kullanılamaz hale gelebilir.
2. Ay sonu ve yıl sonu kapanışı. Yüksek hacimli kayıtlar, katı sıralamalı iş zincirleri ve sabit bir son tarihe karşı yarışan bir finans ekibi. Kapanış iş zincirlerini ortalama günlük sayılara göre değil, kapanış dönemi hacimlerine göre uçtan uca çalıştırın.
3. Çakışan arka plan işleri. Toplu işler genellikle birer birer test edilir; bu da gerçeği yansıtmaz. Kötü optimize edilmiş tek bir iş birkaç başka işi bloke edebilir ve kapanış penceresini aşar.
4. Sınırsız seçimli özel raporlar. Test verilerinde anında dönen bir rapor, tam bir mali yılda dakikalarca çalışabilir. Tipik ve en kötü durum seçimlerini test edin, sınırsız olanları engelleyin.
5. Çok bölgeli kullanıcılar. Ağ gecikmesi her işlemi etkiler. RISE barındırmayı SAP'ye taşır, ama gecikme hâlâ seçtiğiniz bölgeye ve kullanıcılarınıza giden yönlendirmeye bağlıdır; bu yüzden en uzaktaki lokasyonlardan test edin.

ECC'den S/4HANA'ya geçiş rehberim, dönüşüm testinin daha geniş plandaki yerini ele alıyor.

Üretim düzeyinde test verileri

Bunların herhangi bir anlam taşıyıp taşımadığına veri karar verir. Üretim düzeyinde maskelenmiş veride ısrar ederim: üretim hacmi ve üretim gerçekçiliği, kişisel ve hassas alanlar maskelenmiş olarak.

200.000 açık sipariş satırı olan bir müşteri, 5.000 satırı olan bir müşteriden farklı davranır. Seyrek bir test client'ında anında dönen filtreler üretimde zaman aşımına uğrar. Yüksek riskli alanlar için hacim oluşturun, temsil edici bir işlem karışımı kullanın ve mümkün olan yerde gerçek arayüz çağrıları yapın.

Bu verileri kopyalar, seçici test verisi araçları ve maskeleme yoluyla güvenli şekilde nasıl elde edeceğinizi SAP test verisi yönetimi rehberimde ele alıyorum. Yenilemeyi ilk performans döngüsünden önce planlayın, çünkü çoğu test planının varsaydığından daha uzun sürer.

Kriterler üzerinde iş birimiyle Prepare aşamasında, herhangi bir test çalışmadan önce anlaşın. Her biri işlemi veya işi, yükü ve eşiği adıyla belirtir.

Bu örnekler yapıyı gösteriyor. Kendi sayılarınızı operasyonel ihtiyaçlara göre belirleyin:

Kalem	Yük koşulu	Geçme eşiği	Sahibi
Satış siparişi oluşturma (VA01 veya Fiori uygulaması)	150 eşzamanlı sipariş giriş kullanıcısı	İşlemlerin %95'i için 3 saniyenin altında	Order-to-cash süreç sahibi
Vardiya başında Fiori launchpad'in ilk yüklenmesi	En büyük vardiya için tepe eşzamanlı oturum açma	Kullanıcıların %95'i için 5 saniyenin altında	BT operasyon lideri
Ay sonu kapanış iş zinciri	Kapanış dönemi hacimleri, tam sıralama	Üzerinde anlaşılan kapanış penceresi içinde, hiçbir iptal olmadan tamamlanır	Mali kontrolör
Gelen sipariş arayüzü	Tepe saatlik mesaj hacmi	15 dakikadan eski kuyruk birikimi yok	Entegrasyon lideri
Yüksek hacimli özel rapor	Tam üretim veri hacmi, tipik seçim	60 saniyenin altında; sınırsız seçimler engellenmiş	Rapor sahibi

"Sistem iş operasyonları için yeterince hızlı olmalı" ifadesi ne test edilebilir ne de kabul edilebilir. Sonuçlar geldikten sonra kriterleri değiştirmek, onlara sahip olmanın amacını boşa çıkarır.

Sistem, UAT kullanıcıları hızlı hissettirdiğini söylediği için geçtiyse, elinizde bir kabul kriteri değil, bir görüş vardır. SAP kalite kapıları rehberimde anlattığım gibi, sonuçları cutover'dan önce resmi bir kapı haline getirin. Her test aşamasının giriş ve çıkış kriterleriyle birlikte genel döngü planı, S/4HANA test stratejinizde yer almalıdır.

SAP performans testi araçları

Bir performans testinin üç şeye ihtiyacı vardır: SAP protokollerini çalıştırabilen bir yük üreteci, SAP tarafında izleme ve test senaryolarını ve sonuçları yönetecek bir yer. LoadRunner, SAP programlarında ekiplerime kullandırdığım yük aracıdır. Aracı test planında erkenden belirleyin, çünkü lisansların, yük üreteçlerinin ve betik yazma becerilerinin ayarlanması zaman alır.

2026'daki başlıca seçenekler:

Araç	Rolü	Bilmeniz gerekenler
OpenText Professional Performance Engineering	Yük üretimi	Eski adı LoadRunner Professional olan ürün. Protokol paketleri SAP, SAP GUI ve SAP Web'i kapsar
Tricentis NeoLoad	Yük üretimi	Tricentis, SAP GUI, Fiori, RFC ve IDoc desteğini listeliyor; Tricentis Tosca varlıklarını yeniden kullanabilir
Apache JMeter	Yük üretimi	Açık kaynak. Fiori ve OData çağrıları gibi HTTP trafiğini çalıştırır
SAP Cloud ALM	Test yönetimi	Manuel ve otomatik test senaryolarını hazırlar ve çalıştırır, hataları takip eder. Kendisi yük üretmez
SAP Solution Manager	Test yönetimi	Ana bakım 31 Aralık 2027'de sona eriyor; bu yüzden yeni işleri Cloud ALM'de planlayın

Fonksiyonel ve otomasyon araçlarına daha geniş bir bakış için SAP test ve doğrulama araçları karşılaştırmama bakın. Araç; betiklerden, veriden ve kriterlerden daha az önemlidir.

RISE with SAP sorumluluğu böler

RISE with SAP kapsamında altyapının sahibi SAP'dir: boyutlandırma, hyperscaler bölgesi, ağ ve platform erişilebilirliği. Uygulama katmanının sahibi ise müşteri ve iş ortağıdır.

SAP'nin RISE rol ve sorumluluklar belgesi bu konuda açıktır. Yük testinin yürütülmesi ve maliyetli SQL ifadelerinin ayarlanması, ek ücretli SAP Cloud Application Services kapsamındadır. Bunları satın almazsanız işi müşteri yapar.

RISE programlarında yaygın bir başarısızlık, altyapıyı SAP işlettiği için performans sorunlarını da SAP'nin yakalayacağı varsayımıdır. SAP altyapı sorunlarını yakalar. Bölüşümü proje tüzüğüne ve test planına yazın:

1. SAP: altyapı erişilebilirliği ve platform düzeyinde yanıt
2. İş ortağı: tanımlanan yük altında, uzantılar ve entegrasyon akışları dahil uygulama performansı
3. Müşteri: kapanış süresi ve sipariş işleme kapasitesi gibi süreç düzeyindeki sonuçlar ve kabul kararı

Public cloud kapsamı daraltır

SAP'nin bulut ERP'sinin public edition'ında sistem, SAP'nin işlettiği paylaşımlı bir platformda çalışır. Bir tenant'a karşı herhangi bir yük testi planlamadan önce, buna izin verilip verilmediğini ve ne kadar önceden bildirim gerektiğini SAP'ye yazılı olarak sorun.

Bu durumda testiniz size ait olana kayar: özel entegrasyonlar, uzantılar, yüksek hacimli raporlar, kapanış sırası ve lokasyonlarınızdan gelen ağ yolu. Platform performans sorunları SAP desteğine gider.

Yaygın hatalar

1. Fonksiyonel testi performans testi saymak. Fonksiyonel testler bir işlemin doğru sonucu verdiğini kanıtlar. 150 kişinin onu aynı anda çalıştırması hakkında hiçbir şey söylemez.
2. Performansı Basis'e bırakmak. Boyutlandırmanın ve iş zamanlamasının sahibi Basis'tir. Rapor tasarımının, OData servis mimarisinin veya entegrasyon akışı tasarımının sahibi değildir; uygulama performansını belirleyenler ise bunlardır.
3. Sahipliği yalnızca QA'ya vermek. QA testleri çalıştırır ve sonuçları raporlar, ama performans sorunlarına yol açan kararlar tasarımda alınır. Program düzeyinde bir test lideri veya mimarın bunlara erkenden itiraz edebilecek yetkisi olmalı ve RACI, performans gerekçesiyle canlıya geçişi kimin durdurabileceğini söylemelidir.
4. Açıkları bilinen sorunlar olarak kabul etmek. Üretimde performans sorunu yaşayan programların çoğu testi atlamadı. Üzerinde anlaşılmış kriterler olmadan test ettiler ya da test edip ardından başarısızlıkları takvim baskısı altında kabul ettiler.

En yüksek riskli işlemleriniz ve işleriniz için beş altı kabul kriterini, her biri için adı belirlenmiş bir sahiple yazın. Yukarıdaki tabloyu dolduramıyorsanız teste hazır değilsiniz ve ilk açığı bulmuşsunuz demektir.

Ardından iki şeyi kontrol edin: maskelenmiş, üretim hacminde bir veri yenilemesinin planda olduğunu ve eşzamanlılık döngüsünün UAT başlamadan önce bittiğini.

Bir performans testi planına veya bir canlıya geçiş kararına bağımsız bir gözle bakılmasını istiyorsanız, kurumlara bu konuda yardımcı oluyorum. Bana buradan ulaşabilirsiniz.

SAP performans testi nedir?

SAP'nin gerçekçi yük altında nasıl davrandığını kontrol eder: kullanıcı işlemlerinin yanıt sürelerini, arka plan işlerinin çalışma sürelerini, arayüzlerin işleme kapasitesini ve çok sayıda kişi aynı anda çalışırken kaynak kullanımını. Canlıya geçişten önce yapılmalıdır.

Fonksiyonel doğruluk ve performans farklı özelliklerdir. Tek bir kullanıcı için doğru çalışan bir işlem 200 kullanıcıda zaman aşımına uğrayabilir.

Bir SAP programında performans testi ne zaman başlamalı?

Risklerin belirlenmesi Explore'da başlar, çünkü performans sonuçlarını mimari tercihler belirler. Aktif test, yapılandırma sonuçların anlam taşıyacağı kadar istikrar kazandığında Realize'da başlar.

Son döngüyü UAT sırasında değil, UAT'den önce bitirin. UAT'de bulunan performans hataları takvimi sıkıştırır ve bunları bilinen sorunlar olarak kabul etme baskısı yaratır.

SAP'de yük testi ile eşzamanlılık testi arasındaki fark nedir?

Yük testi, beklenen tepe hacimdeki yanıt sürelerini kontrol eder. Eşzamanlılık testi ise çok sayıda kullanıcı ve iş aynı işlemler, tablolar ve servisler üzerinde aynı anda çalıştığında ne olduğunu kontrol eder. Kilit beklemeleri, oturum açma yığılmaları ve gateway darboğazları burada ortaya çıkar.

Deneyimime göre önemli olanlar eşzamanlılık testleridir. Önce onları çalıştırın, ardından tam yük testini bunların üzerine kurun.

SAP performans testinde hangi test verileri kullanılmalı?

Üretim düzeyinde maskelenmiş veriler. Bu, kişisel ve hassas alanlar maskelenmiş olarak üretim hacmi ve gerçekçiliği demektir. Seyrek test verileri, ilk gün ortaya çıkan yavaş filtreleri, ağır raporları ve uzun iş sürelerini gizler.

SAP performans testi için hangi araçlar kullanılır?

Yükü OpenText Professional Performance Engineering (eski adıyla LoadRunner Professional), Tricentis NeoLoad ve Apache JMeter gibi yük üreteçleri oluşturur. Test senaryolarını ve sonuçları SAP Cloud ALM veya SAP Solution Manager yönetir; SAP tarafındaki izleme de sistemin yük altında ne yaptığını gösterir.

RISE with SAP'de performans testinin sahibi kim?

Altyapının sahibi SAP'dir: boyutlandırma, bölge, ağ ve platform erişilebilirliği. SAP'nin RISE rol ve sorumluluklar belgesi, ek ücretle SAP Cloud Application Services satın alınmadıkça yük testinin yürütülmesini ve maliyetli SQL ayarını müşteriye bırakır.

Uygulama performansının ve kabul kararının sahibi müşteri ve iş ortağıdır. Her eşiğin bir sahibi olması için bölüşümü kabul kriterlerine yazın.