SAP performans testi: BT liderlerinin bilmesi gerekenler

SAP performans testi, canlıya geçişten önce kritik işlemlerin, arka plan işlerinin ve arayüzlerin üretim hacimleri altında kararlaştırılmış yanıt sürelerini karşıladığını kanıtlar. Tasarım aşamasında başlatın, konfigürasyon durulduktan sonra Realize aşamasında hacim ve yük testlerini çalıştırın, döngüyü kullanıcı kabul testinden (UAT) önce bitirin ve sonuçları cutover için bir kapıya çevirin. Bu rehber, RISE with SAP dahil S/4HANA programlarındaki CIO'lar, program direktörleri ve test liderleri için. Neyin test edileceğini, sahipliğin kimde olduğunu, kabul kriterlerinin nasıl yazılacağını ve bulutta nelerin değiştiğini ele alıyor. Kabul kriterleri tablosundan başlayın: onu dolduramıyorsanız teste hazır değilsiniz.

SAP programlarındaki performans sorunları neredeyse her zaman canlıya geçişten sonra bulunur. 300 kullanıcı vardiya değişiminde oturum açtığında Fiori kutucukları zaman aşımına uğrar. Biri 50 milyon kayıtlı bir tabloya sınırsız bir mali yıl sorgusu çalıştırdığı için Z raporları donar. Ay sonu kapanışında arka plan işleri çakışır ve kayıt çalıştırması yarıda kesilir.

SAP programlarındaki performans sorunları nadiren sürpriz olarak gelir. Çoğu öngörülebilirdi, yalnızca planlanmamıştı. Olağan tablo şöyle: işlevsel test titizdi. Hacim testi planlandı, takvim sıkışınca ileri atıldı. Sonuçlar canlı operasyonun ilk haftalarında ortaya çıktı.

Bunlar uç durumlar değil. Öngörülebilirler. Tek soru, programın bunları test edip etmediği ya da iş biriminin bunları gerçek siparişler akarken bulup bulmadığı.

SAP Activate boyunca performans testi

1. 01

   Explore

   Performans risklerini tasarımda belirleyin. Mimari ve rapor yapısı, tek satır kod yazılmadan sonucu belirler.

2. 02

   Realize

   Konfigürasyon durulurken hacim ve yük testlerini çalıştırın. Kısmi konfigürasyon 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üşe değil, önceden kararlaştırı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ındaki ECC sisteminde performans testi, uygulama sunucusuna ve veritabanına yük uygulamak demekti: ABAP çalışma zamanı, SQL performansı, iş zamanlaması. Ön yüz, kimseyi nadiren şaşırtan SAP GUI idi.

S/4HANA'da, Fiori ön yüzleri, SAP BTP üzerindeki genişletmeler ve SAP Cloud Integration (CPI) üzerinden entegrasyonla birlikte performans aynı anda birçok katmana bağlıdır. Yavaş bir Fiori kutucuğu uzun bir ABAP çağrısı, bir gateway zaman aşımı, eşzamanlı isteklere göre tasarlanmamış bir OData servisi ya da hibrit bir kurulumda ağ gecikmesi olabilir. Yalnızca arka ucu test etmek bunu bulmaz. Tüm yolu test etmek bulur.

1. 01Kutucuk açılışıVardiya başında oturum açma fırtınaları
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ülemeUzak lokasyonlar için ağ gecikmesi de eklenir

Tek bir yanıt süresi, uçtan uca ölçülür

Entegrasyon akışları kendi risklerini ekler. Geliştirme ve kalite ortamında tek test mesajıyla çalışan akışlar, üretim hacimlerinde kuyrukta birikebilir ya da sessizce başarısız olabilir. Mesaj kuyrukları gerçek yüke göre boyutlandırılmamışsa gecikmeler birikir. Belirtiler başka bir şeye benzer: aralıklı sipariş hataları, fatura uyuşmazlıkları, bir sistemde var olup diğerinde eksik olan veri.

1. Yük testi, beklenen hacim altındaki davranışı kontrol eder. Anahtar kelime “beklenen”. Gerçek işlem hacimlerine, kullanıcı sayılarına ve eşzamanlı oturumlara ihtiyacınız var. Birçok yük testi, herkesin iyimser olduğunu zaten bildiği hacim tahminlerini kullandığı için başarısız olur.
2. Stres testi, sistemin nerede kırıldığını bulmak için tasarım sınırlarının ötesine zorlar. Hacimler on sekiz ay içinde iki katına çıkacaksa, mimarinin buna dayanıp dayanmayacağını ve bir sonraki altyapı gözden geçirmesinden önce boyutlandırmanın sorun olup olmayacağını söyler.
3. Dayanıklılık (soak) testi, zamanla biriken sorunları ortaya çıkarmak için uzun süre sabit yük uygular: bellek sızıntıları, parçalanma ve tekrarlanan çalıştırmalarda iş zinciri çekişmesi. En sık atlanan testtir ve aşağıda anlatılan ay sonu arızasını yakalayacak olan da odur.
4. Uçtan uca test, kullanıcının izlediği tüm yolu takip eder: kutucuk açılışı, OData çağrısı, ABAP işleme, veritabanı okuması, görüntüleme. Her katman tek başına test edildiğinde görünmeyen sorunları bulmanın tek yoludur.

Vardiya değişimi ve yoğun oturum açma. 200 kullanıcı sabah 8'de Fiori launchpad'i açtığında kimlik doğrulama ve launchpad görüntüleme sıçrar. Yoğun olmayan saatlerde sorunsuz çalışan bir sistem, eşzamanlı oturum açma hiç test edilmediyse o aralıkta kullanılamaz hâle gelebilir. Üretim, perakende ve finansal hizmetlerde, oturum açma fırtınaları canlıya geçişin ilk gününün en görünür şikâyetlerini üretir.

Ay sonu ve yıl sonu kapanışı. Çoğu programda en riskli senaryo: yüksek hacimli kayıtlar, sıkı sıralı iş zincirleri ve sabit bir son tarihe karşı yarışan bir finans ekibi. Kapanış iş zincirlerini, ortalama günlük sayılara değil, kapanış dönemi hacimlerine karşı baştan sona çalıştırın.

Arka plan işleri genellikle yalıtılmış olarak test edilir, bu da gerçeği yansıtmaz. Ay sonunda arka plan işleme zirve yapar ve birçok program aynı kaynaklar üzerinde paralel çalışır. Kötü optimize edilmiş tek bir iş beş işi daha engelleyebilir ve kapanış penceresini aşar.

ECC'den S/4HANA'ya dönüşüm. Kararlı ECC kodu HANA'da farklı davranır. Birçok program çok hızlanır, bazıları belirli veri kalıplarında beklenmedik profiller üretir. Dönüşüme özgü regresyon testi isteğe bağlı değildir. ECC'den S/4HANA'ya geçiş rehberim, bunun dönüşüm planında nereye oturduğunu ele alıyor.

Çok bölgeli kullanıcılar. Ağ gecikmesi her işlemi etkiler. Barındırma ülkesinde iki saniye süren bir satış siparişi, kimse oradan test etmediyse 3.000 mil ötede bozuk hissettirebilir. 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.

Kriterleri iş birimiyle Prepare aşamasında, herhangi bir test çalışmadan önce kararlaştırın. Her biri işlemi ya da işi, yükü ve eşiği adlandırır. Bu örnekler biçimi gösteriyor, rakamlarınızı operasyonel ihtiyaçlardan belirleyin:

Kalem	Yük koşulu	Geçme eşiği	Sahip
Satış siparişi oluşturma (VA01 ya da Fiori uygulaması)	150 eşzamanlı sipariş girişi kullanıcısı	İşlemlerin yüzde 95'inde 3 saniyenin altında	Siparişten tahsilata süreç sahibi
Vardiya başında Fiori launchpad ilk yükleme	En büyük vardiya için zirve eşzamanlı oturum açma	Kullanıcıların yüzde 95'inde 5 saniyenin altında	BT operasyon lideri
Ay sonu kapanış iş zinciri	Kapanış dönemi hacimleri, tam sıra	Kabul edilen kapanış penceresi içinde, hiçbir iş yarıda kesilmeden tamamlanır	Mali kontrolör
Gelen sipariş arayüzü	Saatlik zirve 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 engellenir	Rapor sahibi

“Sistem iş operasyonları için yeterince hızlı olmalı” ifadesi test edilemez ve kabul edilemez. Sonuçlar geldikten sonra kriterleri değiştirmek, kriterlere sahip olmanın anlamını ortadan kaldırır.

Bunların her birini adıyla isteyin:

Beklenti	Teslim edilmesi gereken	Neden önemli
Performans hizmet seviyeleri	İşlem, arayüz ve iş başına eşikler, geçti ve kaldı tanımıyla	UAT görüşünün kanıtın önüne geçmesini engeller
Risk bazlı kapsam	Kullanıcı hacmine, entegrasyon noktalarına ve veri bağımlılığına göre önceliklendirme	Test döngülerini önemli iş yüklerine odaklar
Ekipler arası katılım	Çalıştırmalar sırasında Basis, altyapı, işlevsel, güvenlik ve entegrasyon ekipleri hazır	Boşluklar çıktığında suçun birbirine atılmasını önler
Hazır araçlar ve ortamlar	Döngüler başlamadan önce yük üreteçleri (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), izleme ve veri yenilemeleri hazır	Simülasyonu gerçekçi kılar
Gerçekçi test verisi	Üretim hacminde ana veri, gerçek arayüz çağrıları, temsili işlem karışımı	Sonuçların canlıya geçiş davranışını öngörmesini sağlar
Performans raporlaması	Yük karışımı, yanıt süreleri, CPU ve bellek, iş çalışma süreleri, hata oranları	Cutover onayına bir kanıt temeli verir
Canlıya geçiş sonrası izleme planı	İlk 30 ila 60 gün izlenecek KPI'lar	Canlı sistemin test edilen sınırlar içinde kaldığını doğrular

En sık dört hata, olgun teslimat modellerine sahip büyük kurumlarda bile ortaya çıkıyor.

İşlevsel testi performans testi saymak. İşlevsel testler bir işlemin doğru sonucu verdiğini kanıtlar. 150 kişinin aynı anda çalıştırması hakkında hiçbir şey söylemez.

Küçük veri hacimleriyle test etmek. 200.000 açık sipariş kalemi olan bir müşteri, 5.000 olan bir müşteriden farklı davranır. Testte anında dönen filtreler üretimde zaman aşımına uğrar. Yüksek riskli alanlar için hacim tohumlayın.

Performansı Basis'e bırakmak. Basis, boyutlandırmanın ve iş zamanlamasının sahibidir. Rapor tasarımının, OData servis mimarisinin ya da entegrasyon akışı tasarımının sahibi değildir. Uygulama performansını yönlendirenler ise bunlardır.

Sahipliği yalnızca kalite güvenceye vermek. Kalite güvence testleri çalıştırır ve sonuçları raporlar. Performans sorunlarına yol açan kararları tasarımda işlevsel, teknik ve Basis ekipleri verir. Program düzeyinde bir test liderinin ya da mimarın bu kararlara erkenden itiraz etme yetkisi olmalı, RACI de performans gerekçesiyle canlıya geçişi kimin durdurabileceğini söylemeli.

RISE sorumluluğu böler

RISE with SAP kapsamında SAP altyapının sahibidir: boyutlandırma, hyperscaler bölgesi, ağ ve platform erişilebilirliği. Müşteri ve ortak uygulama katmanının sahibidir. SAP'nin RISE roller ve sorumluluklar belgesi bunu açıkça söylüyor: pahalı SQL ifadelerini bulmak ve ayarlamak, SAP'nin ek uygulama hizmetlerini satın almadıkça müşteride kalır.

RISE programlarında sık görülen bir hata, SAP altyapıyı işlettiği için performans sorunlarını yakalayacağı varsayımıdır. Altyapı sorunlarını yakalar. Kötü tasarlanmış bir OData servisini, verimsiz bir ABAP işini ya da ölçeklenmeyen bir entegrasyon akışını yakalamaz. Bu ayrımı proje başlatma belgesine ve test planına yazın:

1. SAP: altyapı erişilebilirliği ve platform düzeyinde yanıt
2. Ortak: genişletmeler ve entegrasyon akışları dahil, tanımlı yük altında uygulama performansı
3. Müşteri: kapanış çalışma süresi ve sipariş işlem hacmi gibi süreç düzeyi sonuçlar ile kabul kararı

Public Edition ve GROW kapsamı daraltır

Genellikle GROW with SAP üzerinden satın alınan S/4HANA Cloud Public Edition'da SAP, performans testini kendi ürün standardının parçası olarak çok kiracılı platformunda yürütür ve müşterilerin paylaşılan sistemi yük testine tabi tutmasını beklemez. Sizin testiniz, size ait olana kayar: özel entegrasyonlar, genişletmeler, yüksek hacimli raporlar ve analitik, kapanış ve konsolidasyon sırası ve lokasyonlarınızdan gelen ağ yolu. Platformun kendisindeki performans sorunları SAP desteğine gider.

Yapay zeka senaryolara yardım eder, mimariye değil

Yük testi sağlayıcıları, betik bakımı ve sonuç analizi için yapay zeka ekliyor. Bu, uygulamanın döngüler arasında değiştiği programlarda işe yarar. İddiaları, parasını vermeden önce kendi sistem ortamınızda sınayın. SAP Cloud ALM test senaryolarının ve gereksinimlerin üretilmesine yardımcı olabilir, yapay zeka asistanları da süreç tanımlarından senaryo taslakları çıkarabilir.

Hiçbiri mimariyi düzeltmez. Yapay zeka size OData servisinin farklı tasarlanması gerektiğini ya da bir raporun hacimleri için fazla ağır olduğunu söylemez. Bu kararları hâlâ insanlar, tasarımda, herhangi bir test çalışmadan önce verir.

Üretimde performans sorunu yaşayan programların çoğu testi tümüyle atlamadı. Kararlaştırılmış kriterler olmadan test ettiler ya da test edip, takvim baskısı altında boşlukları bilinen sorun olarak kabul ettiler. Disiplin araçta değil, kriterlerde ve onların uygulanmasında yatıyor. Performansın diğer test türleri arasındaki yeri için SAP test ve doğrulama araçları karşılaştırmama ve SAP kalite kapıları rehberime bakın.

SAP performans testi nedir ve neden önemlidir?

SAP'nin gerçekçi yük altında nasıl davrandığını kontrol eder: kullanıcı işlemlerinin yanıt süreleri, arka plan işlerinin çalışma süreleri, arayüzlerin işlem hacmi ve eşzamanlı çalışma sırasında kaynak kullanımı.

İşlevsel doğruluk ile performans farklı özelliklerdir. Tek kullanıcı için doğru olan bir işlem 200 kullanıcı için zaman aşımına uğrayabilir. Test verisinde on dakikada çalışan bir iş, üretim hacimlerinde saatlerce sürebilir. Bunu canlıya geçişten sonra bulmak operasyonları aksatır, acil değişiklikleri zorunlu kılar ve benimsenmenin en kırılgan olduğu anda kullanıcı güvenine zarar verir.

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

Risk belirleme Explore aşamasında başlar, çünkü mimari tercihler performans sonuçlarını belirler. Aktif test, konfigürasyon sonuçların bir anlam taşıyacağı kadar durulduğunda Realize aşamasında başlar. Kısmi konfigürasyon yanıltıcı rakamlar verir.

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

SAP performans testinin sahibi kim olmalı?

Yalnızca kalite güvence değil, program. Kalite güvence yürütür ve raporlar, ama performansı belirleyen kararlar tasarımda işlevsel, teknik ve Basis ekipleri arasında alınır. Merkezi bir mimarın ya da program test liderinin bu kararlara erkenden itiraz etme yetkisi olmalı.

RACI'de açıkça yazın: kabul kriterlerini kim onaylar, kriterler tutmadığında düzeltmenin sahibi kim, performans gerekçesiyle canlıya geçişi kim durdurabilir.

RISE with SAP performans testi sorumluluğunu nasıl değiştirir?

SAP altyapının sahibidir: boyutlandırma, bölge, ağ ve platform erişilebilirliği. Müşteri ve ortak uygulama performansının sahibidir: konfigürasyon, genişletmeler, OData ve Fiori tasarımı, entegrasyon akışları ve süreç KPI'ları. SAP'nin RISE roller ve sorumluluklar belgesi, ek SAP hizmetleri satın alınmadıkça SQL ayarlamasını müşteriye bırakır.

Ayrımı kabul kriterlerine yazın ki her eşiğin bir sahibi olsun.

En yaygın SAP Fiori performans sorunları nelerdir?

Dört örüntü çoğunu kapsar. Vardiya başında oturum açma fırtınaları, yani kimlik doğrulama ve launchpad görüntülemenin sıçradığı an. Büyük sonuç kümeleri döndüren ya da etkileşim başına birkaç arka uç çağrısı yapan OData servisleri. Kendi başına bir darboğaza dönüşen gateway katmanı, bu yüzden testler sırasında izlenmesi gerekir. Ve standart performans varsayımlarının geçerli olmadığı özel ya da ağır biçimde değiştirilmiş uygulamalar.

SAP için performans kabul kriterleri nasıl tanımlanır?

İşlemi, yükü ve eşiği adlandırın. Örneğin: “Sipariş girişi rolünde 150 eşzamanlı kullanıcıyla sipariş oluşturma, işlemlerin yüzde 95'inde 3 saniyenin altında tamamlanır.” Bu test edilebilir.

“Sistem yeterince hızlı olmalı” test edilemez. Kriterleri iş birimiyle Prepare aşamasında, gerçek operasyonel ihtiyaçlara göre kararlaştırın ve sonuçlar geldikten sonra değiştirmeyin.

Performans testi atlanırsa ya da sıkıştırılırsa ne olur?

Sorunlar üretimde ortaya çıkar: pencerelerini aşıp başkalarını engelleyen işler, yoğun saatte zaman aşımına uğrayan Fiori uygulamaları, iki kat uzayıp raporlama son tarihlerini kaçıran ay sonu kapanışı, birikmiş arayüz kuyrukları.

İlk haftalarında performans sorunlarıyla karşılaşan kullanıcılar, tersine çevirmesi zor olumsuz bir görüş oluşturur. Canlı operasyon altında acil düzeltme de testten pahalıya gelir, çünkü Realize aşamasında bir tasarım kararı olan şey acil bir mimari değişikliğe dönüşür.