SAP परफ़ॉर्मेंस टेस्टिंग: लोड, कंकरेंसी और टूल

SAP परफ़ॉर्मेंस टेस्टिंग go-live से पहले साबित करती है कि जब एक साथ कई यूज़र और जॉब चलते हैं, तब अहम ट्रांज़ैक्शन, बैकग्राउंड जॉब और इंटरफ़ेस तय रिस्पॉन्स टाइम पूरा करते हैं। मेरे अनुभव में कंकरेंसी टेस्ट ही मायने रखते हैं, जो प्रोडक्शन वॉल्यूम वाले मास्क किए गए डेटा पर, उन पास और फ़ेल क्राइटेरिया के सामने चलाए जाएँ जिन पर बिज़नेस पहले रन से पहले सहमत हुआ हो।

यह गाइड S/4HANA प्रोग्राम के CIO, प्रोग्राम डायरेक्टर और टेस्ट लीड के लिए है, RISE with SAP समेत। यह बताती है कि क्या टेस्ट करें, कौन सा डेटा चाहिए, एक्सेप्टेंस क्राइटेरिया कैसे लिखें, कौन से टूल यह काम करते हैं और किसकी क्या ज़िम्मेदारी है। दूसरे टेस्ट प्रकारों के बीच परफ़ॉर्मेंस कहाँ बैठती है, यह जानने के लिए मेरे परिचय SAP टेस्टिंग क्या है से शुरू कीजिए।

SAP प्रोग्राम में परफ़ॉर्मेंस की समस्याएँ शायद ही कभी अचानक आती हैं।

शिफ़्ट की शुरुआत में जब सैकड़ों यूज़र लॉग इन करते हैं, तो Fiori टाइल टाइम आउट हो जाती हैं। कोई कस्टम रिपोर्ट इसलिए अटक जाती है कि किसी ने बहुत बड़ी तालिका पर पूरे वित्त वर्ष का बिना सीमा वाला सेलेक्शन चला दिया। मंथ-एंड पर बैकग्राउंड जॉब आपस में टकराते हैं और पोस्टिंग रन बीच में रुक जाता है।

इनका अनुमान पहले से लगाया जा सकता है। सवाल बस इतना है कि प्रोग्राम ने इनके लिए टेस्ट किया या बिज़नेस इन्हें असली ऑर्डर चलते समय पाता है।

SAP Activate में परफ़ॉर्मेंस टेस्टिंग

1. 01

   Explore

   डिज़ाइन में परफ़ॉर्मेंस के जोखिम पहचानिए। आर्किटेक्चर और रिपोर्ट की बनावट कोड लिखे जाने से पहले नतीजे तय कर देते हैं।

2. 02

   Realize

   कॉन्फ़िगरेशन स्थिर होने पर वॉल्यूम और लोड टेस्ट चलाइए। अधूरा कॉन्फ़िगरेशन भ्रामक नतीजे देता है।

3. 03

   UAT से पहले

   पूरा परफ़ॉर्मेंस साइकिल UAT से पहले पूरा कीजिए, उसके हिस्से के रूप में नहीं।

4. 04

   कटओवर

   कटओवर को पहले से तय एक्सेप्टेंस क्राइटेरिया के सामने मंज़ूर कीजिए, राय के सामने नहीं।

5. 05

   हाइपरकेयर

   30 से 60 दिन तक लाइव KPI पर नज़र रखिए। ज़्यादातर गिरावट पहले क्लोज़ साइकिल में दिखती है।

पारंपरिक डेटाबेस पर चलने वाले ECC सिस्टम में परफ़ॉर्मेंस टेस्टिंग का मतलब था एप्लिकेशन सर्वर और डेटाबेस का लोड टेस्ट: ABAP रनटाइम, SQL परफ़ॉर्मेंस और जॉब शेड्यूलिंग। फ़्रंट एंड SAP GUI था, जो शायद ही कभी किसी को चौंकाता था।

S/4HANA पर, Fiori फ़्रंट एंड, SAP BTP पर एक्सटेंशन और SAP Cloud Integration के ज़रिए इंटीग्रेशन के साथ, परफ़ॉर्मेंस एक साथ कई परतों पर निर्भर करती है। धीमी Fiori टाइल की वजह कोई लंबा ABAP कॉल, गेटवे टाइमआउट, कंकरेंट अनुरोधों के लिए डिज़ाइन न की गई OData सर्विस या हाइब्रिड सेटअप में नेटवर्क लेटेंसी हो सकती है। केवल बैक एंड टेस्ट करने से यह नहीं मिलेगा।

1. 01टाइल लॉन्चशिफ़्ट की शुरुआत में लॉगिन की बाढ़
2. 02OData कॉलगेटवे टाइमआउट, कंकरेंसी के लिए न बनी सर्विस
3. 03ABAP प्रोसेसिंगदेर तक चलने वाले ABAP कॉल
4. 04डेटाबेस रीडबड़ी तालिकाओं पर बिना सीमा वाले सेलेक्शन
5. 05रेंडरिंगसाथ में दूर की साइट के लिए नेटवर्क लेटेंसी

एक रिस्पॉन्स टाइम, शुरू से अंत तक मापा गया

कन्वर्ज़न में SAP HANA परफ़ॉर्मेंस टेस्टिंग का अपना पेच है। स्थिर ECC कोड in-memory डेटाबेस पर अलग व्यवहार करता है। कई प्रोग्राम बहुत तेज़ हो जाते हैं, जबकि कुछ ख़ास डेटा पैटर्न पर अप्रत्याशित प्रोफ़ाइल देते हैं, इसलिए भारी कस्टम कोड का कन्वर्ज़न-विशेष रिग्रेशन वैकल्पिक नहीं है।

इंटीग्रेशन फ़्लो अपना जोखिम जोड़ते हैं। जो फ़्लो डेवलपमेंट में एक-एक टेस्ट मैसेज के साथ काम करते थे, वे प्रोडक्शन वॉल्यूम पर कतार में फँस सकते हैं या चुपचाप फ़ेल हो सकते हैं। लक्षण किसी और चीज़ जैसे दिखते हैं: रुक-रुक कर ऑर्डर फ़ेल होना, इनवॉइस का मेल न खाना, एक सिस्टम में मौजूद और दूसरे में गायब डेटा।

परफ़ॉर्मेंस टेस्टिंग go-live से पहले होनी ही चाहिए। जिन टेस्ट को मैं अहम मानता हूँ, वे कंकरेंसी टेस्ट हैं: कई यूज़र और जॉब एक ही समय पर एक ही ट्रांज़ैक्शन, तालिकाओं और सर्विस पर।

एक यूज़र का दो सेकंड में सेल्स ऑर्डर चला लेना लगभग कुछ साबित नहीं करता। वही ऑर्डर, जब 150 लोग ऑर्डर डाल रहे हों, बैकग्राउंड में डिलीवरी रन चल रहा हो और कोई इंटरफ़ेस इनबाउंड मैसेज पोस्ट कर रहा हो, वह टेस्ट है जो पहले दिन का अनुमान देता है।

यह तालिका बताती है कि हर तरह का टेस्ट क्या साबित करता है और उसे कब चलाएँ:

टेस्ट	यह क्या साबित करता है	कब चलाएँ	आम तौर पर क्या मिलता है
कंकरेंसी	कई यूज़र और जॉब एक साथ उन्हीं ऑब्जेक्ट पर काम कर सकते हैं	Realize, कॉन्फ़िगरेशन स्थिर होने के बाद, और फिर UAT से पहले	लॉक वेट, लॉगिन की बाढ़, गेटवे की रुकावटें
लोड	सिस्टम अपेक्षित पीक वॉल्यूम पर रिस्पॉन्स टाइम पूरा करता है	Realize, कंकरेंसी स्क्रिप्ट काम करने के बाद	धीमी OData सर्विस, भारी कस्टम रिपोर्ट
स्ट्रेस	डिज़ाइन की सीमा से ऊपर सिस्टम कहाँ टूटता है	UAT से पहले, अगर वृद्धि अपेक्षित है	साइज़िंग की कमियाँ, कतार की सीमाएँ
सोक	सिस्टम घंटों तक स्थिर लोड संभालता है	UAT से पहले, आदर्श रूप से एक सिमुलेटेड क्लोज़ के दौरान	मेमोरी का बढ़ना, बार-बार के रन में जॉब चेन का टकराव
एंड-टू-एंड	यूज़र जिस पूरे रास्ते का इंतज़ार करता है, वह लक्ष्य पूरा करता है	लोड टेस्ट के साथ	वे समस्याएँ जो हर परत को अलग टेस्ट करने पर नहीं दिखतीं

लोड टेस्टिंग में अहम शब्द है अपेक्षित। आपको असली ट्रांज़ैक्शन वॉल्यूम, यूज़र संख्या और सेशन पैटर्न चाहिए। ऐसे वॉल्यूम अनुमानों पर बना लोड टेस्ट, जिन्हें सब पहले से आशावादी जानते थे, ऐसा पास देता है जिसका कोई मतलब नहीं।

सोक टेस्टिंग सबसे ज़्यादा छोड़ी जाती है। आम तौर पर वॉल्यूम टेस्टिंग वह शॉर्टकट है जो टाइमलाइन सिकुड़ने पर प्रोग्राम सबसे ज़्यादा लेते हैं, और जिस पर सबसे ज़्यादा पछताते हैं।

इन्हें पहले स्क्रिप्ट कीजिए। प्रोडक्शन तक पहुँचने वाली ज़्यादातर विफलताएँ इनमें आ जाती हैं।

1. शिफ़्ट बदलना और पीक लॉगिन। जब कुछ सौ यूज़र एक ही समय पर Fiori launchpad खोलते हैं, तो ऑथेंटिकेशन और launchpad रेंडरिंग में उछाल आता है। जो सिस्टम ऑफ़-पीक में ठीक है, वह उस विंडो में इस्तेमाल के लायक नहीं रह सकता, अगर कंकरेंट लॉगिन कभी टेस्ट नहीं हुए।
2. मंथ-एंड और ईयर-एंड क्लोज़। भारी पोस्टिंग, सख़्त क्रम वाली जॉब चेन और तय डेडलाइन से जूझती फ़ाइनेंस टीम। क्लोज़ की जॉब चेन को शुरू से अंत तक क्लोज़िंग पीरियड के वॉल्यूम पर चलाइए, औसत रोज़ाना गिनती पर नहीं।
3. आपस में टकराते बैकग्राउंड जॉब। बैच जॉब आम तौर पर एक-एक करके टेस्ट होते हैं, जो असलियत नहीं दिखाता। एक ख़राब ऑप्टिमाइज़ किया गया जॉब कई दूसरों को रोक सकता है, और क्लोज़ अपनी विंडो से आगे निकल जाता है।
4. बिना सीमा वाली कस्टम रिपोर्ट। जो रिपोर्ट टेस्ट डेटा पर तुरंत नतीजा देती है, वह पूरे वित्त वर्ष पर मिनटों चल सकती है। सामान्य और सबसे बुरे सेलेक्शन टेस्ट कीजिए, और बिना सीमा वाले सेलेक्शन ब्लॉक कीजिए।
5. कई क्षेत्रों के यूज़र। नेटवर्क लेटेंसी हर ट्रांज़ैक्शन पर असर डालती है। RISE होस्टिंग को SAP के पास ले जाता है, पर लेटेंसी अब भी आपके चुने क्षेत्र और आपके यूज़र्स तक की रूटिंग पर निर्भर करती है, इसलिए सबसे दूर की साइट से टेस्ट कीजिए।

मेरी ECC से S/4HANA माइग्रेशन गाइड बताती है कि कन्वर्ज़न टेस्टिंग बड़े प्लान में कहाँ आती है।

प्रोडक्शन-स्तर का टेस्ट डेटा

डेटा तय करता है कि इनमें से किसी का भी कोई मतलब है या नहीं। मैं प्रोडक्शन स्तर के मास्क किए गए डेटा पर ज़ोर देता हूँ: प्रोडक्शन जितना वॉल्यूम और प्रोडक्शन जैसी वास्तविकता, व्यक्तिगत और संवेदनशील फ़ील्ड मास्क करके।

200,000 खुली ऑर्डर लाइनों वाला ग्राहक 5,000 वाले ग्राहक से अलग व्यवहार करता है। जो फ़िल्टर पतले टेस्ट क्लाइंट में तुरंत नतीजा देते हैं, वे प्रोडक्शन में टाइम आउट हो जाते हैं। उच्च-जोखिम क्षेत्रों के लिए वॉल्यूम भरिए, ट्रांज़ैक्शन का प्रतिनिधि मिश्रण इस्तेमाल कीजिए और जहाँ हो सके असली इंटरफ़ेस कॉल कीजिए।

कॉपी, सेलेक्टिव टेस्ट डेटा टूल और मास्किंग के ज़रिए वह डेटा सुरक्षित रूप से कैसे पाएँ, यह मेरी SAP टेस्ट डेटा मैनेजमेंट गाइड में है। पहले परफ़ॉर्मेंस साइकिल से पहले रिफ़्रेश की योजना बनाइए, क्योंकि इसमें ज़्यादातर टेस्ट प्लान के अनुमान से ज़्यादा समय लगता है।

कोई भी टेस्ट चलने से पहले, Prepare चरण में, बिज़नेस के साथ क्राइटेरिया तय कीजिए। हर एक में ट्रांज़ैक्शन या जॉब, लोड और सीमा का नाम होता है।

ये उदाहरण बनावट दिखाते हैं। अपने आँकड़े संचालन की ज़रूरतों से तय कीजिए:

आइटम	लोड की स्थिति	पास की सीमा	ज़िम्मेदार
सेल्स ऑर्डर बनाना (VA01 या Fiori ऐप)	150 कंकरेंट ऑर्डर-एंट्री यूज़र	95% ट्रांज़ैक्शन के लिए 3 सेकंड से कम	Order-to-cash प्रोसेस ओनर
शिफ़्ट की शुरुआत में Fiori launchpad का पहला लोड	सबसे बड़ी शिफ़्ट के पीक कंकरेंट लॉगिन	95% यूज़र्स के लिए 5 सेकंड से कम	IT ऑपरेशंस लीड
मंथ-एंड क्लोज़ जॉब चेन	क्लोज़िंग पीरियड का वॉल्यूम, पूरा क्रम	तय क्लोज़ विंडो के भीतर बिना किसी रुकावट के पूरी	फ़ाइनेंशियल कंट्रोलर
इनबाउंड ऑर्डर इंटरफ़ेस	पीक घंटे का मैसेज वॉल्यूम	15 मिनट से पुरानी कोई कतार बकाया नहीं	इंटीग्रेशन लीड
भारी वॉल्यूम वाली कस्टम रिपोर्ट	पूरा प्रोडक्शन डेटा वॉल्यूम, सामान्य सेलेक्शन	60 सेकंड से कम; बिना सीमा वाले सेलेक्शन ब्लॉक	रिपोर्ट ओनर

“सिस्टम बिज़नेस संचालन के लिए पर्याप्त तेज़ होना चाहिए” न टेस्ट किया जा सकता है, न स्वीकार। नतीजे आने के बाद क्राइटेरिया बदलना उनके होने का मक़सद ही ख़त्म कर देता है।

अगर सिस्टम इसलिए पास हुआ कि UAT यूज़र्स को वह तेज़ लगा, तो आपके पास एक राय है, एक्सेप्टेंस क्राइटेरियन नहीं। नतीजों को कटओवर से पहले एक औपचारिक गेट बनाइए, जैसा मेरी SAP क्वालिटी गेट्स गाइड बताती है। हर टेस्ट चरण के एंट्री और एग्ज़िट क्राइटेरिया के साथ पूरा साइकिल प्लान आपकी S/4HANA टेस्टिंग स्ट्रैटेजी में होना चाहिए।

SAP परफ़ॉर्मेंस टेस्टिंग टूल

परफ़ॉर्मेंस टेस्ट को तीन चीज़ें चाहिए: SAP प्रोटोकॉल चला सकने वाला लोड जनरेटर, SAP की तरफ़ मॉनिटरिंग और टेस्ट केस व नतीजे मैनेज करने की एक जगह। LoadRunner वह लोड टूल है जो मेरी टीमों ने SAP प्रोग्राम में इस्तेमाल किया है। टेस्ट प्लान में टूल का नाम जल्दी तय कीजिए, क्योंकि लाइसेंस, लोड जनरेटर और स्क्रिप्टिंग कौशल, सबकी व्यवस्था में समय लगता है।

2026 में मुख्य विकल्प:

टूल	भूमिका	क्या जानना ज़रूरी है
OpenText Professional Performance Engineering	लोड जनरेशन	वह प्रोडक्ट जिसे पहले LoadRunner Professional कहा जाता था। इसके प्रोटोकॉल बंडल SAP, SAP GUI और SAP Web कवर करते हैं
Tricentis NeoLoad	लोड जनरेशन	Tricentis, SAP GUI, Fiori, RFC और IDoc सपोर्ट गिनाता है, और यह Tricentis Tosca के एसेट दोबारा इस्तेमाल कर सकता है
Apache JMeter	लोड जनरेशन	ओपन सोर्स। Fiori और OData कॉल जैसा HTTP ट्रैफ़िक चलाता है
SAP Cloud ALM	टेस्ट मैनेजमेंट	मैनुअल और ऑटोमेटेड टेस्ट केस तैयार करता और चलाता है और डिफ़ेक्ट ट्रैक करता है। यह ख़ुद लोड पैदा नहीं करता
SAP Solution Manager	टेस्ट मैनेजमेंट	मेनस्ट्रीम मेंटेनेंस 31 दिसंबर 2027 को समाप्त होता है, इसलिए नया काम Cloud ALM में प्लान कीजिए

फ़ंक्शनल और ऑटोमेशन टूल की व्यापक तस्वीर के लिए मेरी SAP टेस्टिंग और वैलिडेशन टूल की तुलना देखिए। टूल से ज़्यादा स्क्रिप्ट, डेटा और क्राइटेरिया मायने रखते हैं।

RISE with SAP ज़िम्मेदारी बाँटता है

RISE with SAP में इन्फ्रास्ट्रक्चर SAP का है: साइज़िंग, हाइपरस्केलर क्षेत्र, नेटवर्क और प्लेटफ़ॉर्म की उपलब्धता। एप्लिकेशन की परत क्लाइंट और पार्टनर की है।

SAP का RISE roles and responsibilities दस्तावेज़ इस पर साफ़ है। लोड टेस्ट चलाना और महँगे SQL स्टेटमेंट की ट्यूनिंग अतिरिक्त शुल्क वाली SAP Cloud Application Services हैं। अगर आप इन्हें नहीं ख़रीदते, तो यह काम ग्राहक करता है।

RISE प्रोग्राम में एक आम चूक यह मान लेना है कि SAP परफ़ॉर्मेंस की समस्याएँ पकड़ लेगा क्योंकि वह इन्फ्रास्ट्रक्चर चलाता है। वह इन्फ्रास्ट्रक्चर की समस्याएँ पकड़ेगा। यह बँटवारा चार्टर और टेस्ट प्लान में लिखिए:

1. SAP: इन्फ्रास्ट्रक्चर की उपलब्धता और प्लेटफ़ॉर्म-स्तर का रिस्पॉन्स
2. पार्टनर: तय लोड के तहत एप्लिकेशन परफ़ॉर्मेंस, एक्सटेंशन और इंटीग्रेशन फ़्लो समेत
3. क्लाइंट: प्रक्रिया-स्तर के नतीजे, जैसे क्लोज़ का रनटाइम और ऑर्डर थ्रूपुट, और स्वीकृति का फ़ैसला

पब्लिक क्लाउड स्कोप को छोटा करता है

SAP के क्लाउड ERP के public edition पर सिस्टम एक साझा, SAP द्वारा चलाए जाने वाले प्लेटफ़ॉर्म पर चलता है। किसी टेनेंट पर लोड टेस्ट की योजना बनाने से पहले SAP से लिखित में पूछिए कि क्या इसकी अनुमति है और इसके लिए कितनी पूर्व सूचना चाहिए।

तब आपकी टेस्टिंग उस पर केंद्रित होती है जो आपका है: कस्टम इंटीग्रेशन, एक्सटेंशन, भारी वॉल्यूम वाली रिपोर्ट, क्लोज़ का क्रम और आपकी साइट से नेटवर्क का रास्ता। प्लेटफ़ॉर्म परफ़ॉर्मेंस की समस्याएँ SAP सपोर्ट के पास जाती हैं।

आम ग़लतियाँ

1. फ़ंक्शनल टेस्टिंग को परफ़ॉर्मेंस टेस्टिंग मान लेना। फ़ंक्शनल टेस्ट साबित करते हैं कि ट्रांज़ैक्शन सही नतीजा देता है। वे इस बारे में कुछ नहीं कहते कि 150 लोग उसे एक साथ चलाएँ तो क्या होगा।
2. परफ़ॉर्मेंस को Basis पर छोड़ देना। साइज़िंग और जॉब शेड्यूलिंग Basis की ज़िम्मेदारी है। रिपोर्ट डिज़ाइन, OData सर्विस आर्किटेक्चर या इंटीग्रेशन फ़्लो डिज़ाइन उसकी ज़िम्मेदारी नहीं, और एप्लिकेशन परफ़ॉर्मेंस इन्हीं से तय होती है।
3. ज़िम्मेदारी अकेले QA को देना। QA टेस्ट चलाता है और नतीजे बताता है, पर परफ़ॉर्मेंस की समस्याएँ पैदा करने वाले फ़ैसले डिज़ाइन में होते हैं। प्रोग्राम-स्तर के टेस्ट लीड या आर्किटेक्ट के पास उन्हें जल्दी चुनौती देने का अधिकार होना चाहिए, और RACI में लिखा होना चाहिए कि परफ़ॉर्मेंस के आधार पर go-live कौन रोक सकता है।
4. कमियों को ज्ञात समस्याओं के रूप में स्वीकार करना। प्रोडक्शन में परफ़ॉर्मेंस की समस्याओं वाले ज़्यादातर प्रोग्राम ने टेस्टिंग छोड़ी नहीं थी। उन्होंने बिना तय क्राइटेरिया के टेस्ट किया, या टेस्ट किया और फिर शेड्यूल के दबाव में विफलताओं को स्वीकार कर लिया।

अपने सबसे ज़्यादा जोखिम वाले ट्रांज़ैक्शन और जॉब के लिए पाँच या छह एक्सेप्टेंस क्राइटेरिया लिखिए, हर एक के नामित ज़िम्मेदार के साथ। अगर आप ऊपर की तालिका नहीं भर सकते, तो आप टेस्ट के लिए तैयार नहीं हैं, और आपको पहली कमी मिल गई है।

फिर दो बातें जाँचिए: कि प्लान में प्रोडक्शन-वॉल्यूम वाले मास्क किए गए डेटा का रिफ़्रेश है, और कि कंकरेंसी साइकिल UAT शुरू होने से पहले पूरा होता है।

अगर आप किसी परफ़ॉर्मेंस टेस्ट प्लान या go-live फ़ैसले पर स्वतंत्र राय चाहते हैं, तो मैं इसमें संगठनों की मदद करता हूँ। आप यहाँ मुझसे संपर्क कर सकते हैं।

SAP परफ़ॉर्मेंस टेस्टिंग क्या है?

यह जाँचती है कि वास्तविक लोड में SAP कैसा व्यवहार करता है: यूज़र ट्रांज़ैक्शन का रिस्पॉन्स टाइम, बैकग्राउंड जॉब का रनटाइम, इंटरफ़ेस का थ्रूपुट और जब कई लोग एक साथ काम करें तब संसाधनों का इस्तेमाल। यह go-live से पहले होनी ही चाहिए।

फ़ंक्शनल रूप से सही होना और परफ़ॉर्मेंस अलग-अलग गुण हैं। जो ट्रांज़ैक्शन एक यूज़र के लिए सही है, वह 200 के लिए टाइम आउट हो सकता है।

SAP प्रोग्राम में परफ़ॉर्मेंस टेस्टिंग कब शुरू होनी चाहिए?

जोखिम की पहचान Explore में शुरू होती है, क्योंकि आर्किटेक्चर के चुनाव परफ़ॉर्मेंस के नतीजे तय करते हैं। सक्रिय टेस्टिंग Realize में शुरू होती है, जब कॉन्फ़िगरेशन इतना स्थिर हो जाए कि नतीजों का मतलब हो।

आख़िरी साइकिल UAT से पहले पूरा कीजिए, उसके दौरान नहीं। UAT में मिले परफ़ॉर्मेंस डिफ़ेक्ट शेड्यूल को दबाते हैं और उन्हें ज्ञात समस्याओं के रूप में स्वीकार करने का दबाव बनाते हैं।

SAP में लोड टेस्टिंग और कंकरेंसी टेस्टिंग में क्या अंतर है?

लोड टेस्टिंग अपेक्षित पीक वॉल्यूम पर रिस्पॉन्स टाइम जाँचती है। कंकरेंसी टेस्टिंग जाँचती है कि जब कई यूज़र और जॉब एक ही पल में उन्हीं ट्रांज़ैक्शन, तालिकाओं और सर्विस पर काम करते हैं तो क्या होता है। लॉक वेट, लॉगिन की बाढ़ और गेटवे की रुकावटें वहीं दिखती हैं।

मेरे अनुभव में कंकरेंसी टेस्ट ही अहम हैं। इन्हें पहले चलाइए, फिर उनके ऊपर पूरा लोड टेस्ट बनाइए।

SAP परफ़ॉर्मेंस टेस्टिंग में कौन सा टेस्ट डेटा इस्तेमाल होना चाहिए?

प्रोडक्शन स्तर का मास्क किया गया डेटा। इसका मतलब है प्रोडक्शन जितना वॉल्यूम और वास्तविकता, व्यक्तिगत और संवेदनशील फ़ील्ड मास्क करके। पतला टेस्ट डेटा उन धीमे फ़िल्टर, भारी रिपोर्ट और लंबे जॉब रनटाइम को छिपा देता है जो पहले दिन सामने आते हैं।

SAP परफ़ॉर्मेंस टेस्टिंग के लिए कौन से टूल इस्तेमाल होते हैं?

OpenText Professional Performance Engineering (पहले LoadRunner Professional), Tricentis NeoLoad और Apache JMeter जैसे लोड जनरेटर लोड पैदा करते हैं। SAP Cloud ALM या SAP Solution Manager टेस्ट केस और नतीजे मैनेज करते हैं, और SAP की तरफ़ की मॉनिटरिंग दिखाती है कि लोड के तहत सिस्टम ने क्या किया।

RISE with SAP में परफ़ॉर्मेंस टेस्टिंग की ज़िम्मेदारी किसकी है?

इन्फ्रास्ट्रक्चर SAP का है: साइज़िंग, क्षेत्र, नेटवर्क और प्लेटफ़ॉर्म की उपलब्धता। SAP का RISE roles and responsibilities दस्तावेज़ लोड टेस्ट चलाने और महँगे SQL की ट्यूनिंग को ग्राहक के पास छोड़ता है, जब तक अतिरिक्त शुल्क पर SAP Cloud Application Services न ख़रीदी जाएँ।

एप्लिकेशन परफ़ॉर्मेंस और स्वीकृति का फ़ैसला क्लाइंट और पार्टनर का है। यह बँटवारा एक्सेप्टेंस क्राइटेरिया में लिखिए, ताकि हर सीमा का एक ज़िम्मेदार हो।