اختبار أداء SAP: الحمل والتزامن والأدوات

يثبت اختبار أداء SAP، قبل التشغيل الفعلي، أن المعاملات الحرجة والمهام الخلفية والواجهات تحقق أزمنة الاستجابة المتفق عليها حين يعمل عدد كبير من المستخدمين والمهام في الوقت نفسه. وفي تجربتي فإن اختبارات التزامن هي المهمة، وتُنفَّذ على بيانات مقنّعة بحجم الإنتاج، وفق معايير نجاح وفشل اتفق عليها قطاع الأعمال قبل الجولة الأولى.

هذا الدليل موجه إلى مديري تقنية المعلومات ومديري البرامج وقادة الاختبار في برامج S/4HANA، بما فيها RISE with SAP. ويغطي ما الذي تختبرونه، والبيانات التي تحتاجونها، وكيف تكتبون معايير القبول، وأي الأدوات تؤدي المهمة، ومن يتولى ماذا. ولمعرفة موقع الأداء بين أنواع الاختبار الأخرى، ابدؤوا بنظرتي العامة في شرح اختبار SAP.

مشكلات الأداء في برامج SAP نادرًا ما تكون مفاجأة.

تنتهي مهلة مربعات Fiori حين يسجل مئات المستخدمين دخولهم في بداية المناوبة. ويتجمد تقرير مخصص لأن أحدهم نفّذ اختيارًا مفتوحًا لسنة مالية كاملة على جدول كبير جدًا. وتتداخل المهام الخلفية في نهاية الشهر فيتوقف تشغيل الترحيل.

هذه أمور متوقعة. والسؤال الوحيد هو هل اختبرها البرنامج، أم سيكتشفها قطاع الأعمال مع تشغيل طلبات حقيقية.

اختبار الأداء عبر مراحل SAP Activate

1. 01

   Explore

   حددوا مخاطر الأداء في التصميم. فالبنية وشكل التقارير يحددان النتائج قبل كتابة الشيفرة.

2. 02

   Realize

   نفذوا اختبارات الحجم والحمل مع استقرار التهيئة. فالتهيئة الجزئية تعطي نتائج مضللة.

3. 03

   ما قبل UAT

   أكملوا دورة الأداء الكاملة قبل UAT، لا كجزء منه.

4. 04

   الانتقال

   اعتمدوا الانتقال وفق معايير القبول المتفق عليها مسبقًا، لا وفق الآراء.

5. 05

   الدعم المكثف بعد التشغيل

   راقبوا مؤشرات الأداء الحية لمدة 30 إلى 60 يومًا. فمعظم التراجعات تظهر في دورة الإقفال الأولى.

في نظام ECC على قاعدة بيانات تقليدية، كان اختبار الأداء يعني اختبار الحمل على خادم التطبيقات وقاعدة البيانات: وقت تشغيل ABAP، وأداء SQL، وجدولة المهام. وكانت الواجهة الأمامية SAP GUI، ونادرًا ما فاجأت أحدًا.

أما في S/4HANA، مع واجهات Fiori الأمامية، والإضافات على SAP BTP، والتكامل عبر SAP Cloud Integration، فيعتمد الأداء على عدة طبقات في الوقت نفسه. فقد يكون بطء مربع Fiori ناتجًا عن استدعاء ABAP طويل، أو عن انتهاء مهلة في البوابة، أو عن خدمة OData لم تُصمَّم للطلبات المتزامنة، أو عن زمن انتقال الشبكة في إعداد هجين. واختبار الطبقة الخلفية وحدها لن يكشف ذلك.

1. 01تشغيل المربعموجات تسجيل الدخول في بداية المناوبة
2. 02استدعاء ODataانتهاء مهلة البوابة، وخدمات غير مبنية للتزامن
3. 03معالجة ABAPاستدعاءات ABAP طويلة التشغيل
4. 04القراءة من قاعدة البياناتاختيارات مفتوحة على جداول كبيرة
5. 05العرضإضافة إلى زمن انتقال الشبكة للمواقع البعيدة

زمن استجابة واحد، يُقاس من البداية إلى النهاية

لاختبار أداء SAP HANA خصوصية في التحويل. فشيفرة ECC المستقرة تتصرف بشكل مختلف على قاعدة بيانات في الذاكرة. كثير من البرامج يصبح أسرع بكثير، بينما ينتج بعضها أنماط أداء غير متوقعة مع أنماط بيانات معينة، ولذلك فإن اختبار الانحدار الخاص بالتحويل للشيفرة المخصصة الثقيلة ليس اختياريًا.

وتضيف تدفقات التكامل مخاطرها الخاصة. فالتدفقات التي عملت في التطوير برسائل اختبار منفردة قد تتكدس في الطوابير أو تفشل بصمت بأحجام الإنتاج. وتبدو الأعراض كأنها شيء آخر: إخفاقات متقطعة في الطلبات، وعدم تطابق في الفواتير، وبيانات موجودة في نظام ومفقودة في آخر.

يجب أن يجري اختبار الأداء قبل التشغيل الفعلي. والاختبارات التي أعدّها مهمة هي اختبارات التزامن: عدد كبير من المستخدمين والمهام يعملون على المعاملات والجداول والخدمات نفسها في الوقت نفسه.

مستخدم واحد ينفذ أمر بيع في ثانيتين لا يثبت شيئًا تقريبًا. أما الأمر نفسه مع 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 مستخدمًا متزامنًا لإدخال الطلبات	أقل من 3 ثوانٍ لـ 95% من المعاملات	مالك عملية من الطلب إلى التحصيل
التحميل الأول لـ Fiori launchpad في بداية المناوبة	ذروة تسجيلات الدخول المتزامنة لأكبر مناوبة	أقل من 5 ثوانٍ لـ 95% من المستخدمين	قائد عمليات تقنية المعلومات
سلسلة مهام إقفال نهاية الشهر	أحجام فترة الإقفال، بالتسلسل الكامل	تكتمل ضمن نافذة الإقفال المتفق عليها دون توقف	المراقب المالي
واجهة الطلبات الواردة	حجم الرسائل في ساعة الذروة	لا تراكم في الطابور أقدم من 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	توليد الحمل	مفتوح المصدر. يشغّل حركة HTTP مثل استدعاءات Fiori وOData
SAP Cloud ALM	إدارة الاختبار	يُعدّ حالات الاختبار اليدوية والمؤتمتة وينفذها ويتتبع العيوب. ولا يولّد الحمل بنفسه
SAP Solution Manager	إدارة الاختبار	تنتهي الصيانة الرئيسية في 31 ديسمبر 2027، فخططوا للعمل الجديد في Cloud ALM

لنظرة أوسع على الأدوات الوظيفية وأدوات الأتمتة، راجعوا مقارنتي لأدوات اختبار SAP والتحقق منه. فالأداة أقل أهمية من السيناريوهات والبيانات والمعايير.

RISE with SAP يقسم المسؤولية

في RISE with SAP، تتولى SAP البنية التحتية: التحجيم، ومنطقة مزود الخدمة السحابية الكبير، والشبكة، وتوافر المنصة. ويتولى العميل والشريك طبقة التطبيقات.

ووثيقة الأدوار والمسؤوليات في RISE من SAP واضحة في ذلك. فتنفيذ اختبار الحمل وضبط عبارات SQL المكلفة من SAP Cloud Application Services برسوم إضافية. وإذا لم تشتروها، يقوم العميل بالعمل.

من الإخفاقات الشائعة في برامج RISE افتراض أن SAP ستكتشف مشكلات الأداء لأنها تشغّل البنية التحتية. ستكتشف مشكلات البنية التحتية. اكتبوا التقسيم في ميثاق البرنامج وفي خطة الاختبار:

1. SAP: توافر البنية التحتية والاستجابة على مستوى المنصة
2. الشريك: أداء التطبيقات تحت الحمل المحدد، بما في ذلك الإضافات وتدفقات التكامل
3. العميل: النتائج على مستوى العمليات مثل مدة الإقفال وإنتاجية الطلبات، وقرار القبول

السحابة العامة تضيّق النطاق

في public edition من نظام ERP السحابي من SAP، يعمل النظام على منصة مشتركة تشغّلها SAP. وقبل أن تخططوا لأي اختبار حمل على مستأجر، اسألوا SAP كتابيًا عما إذا كان ذلك مسموحًا وما الإشعار المسبق الذي تحتاجه.

وعندها ينتقل اختباركم إلى ما يخصكم: التكاملات المخصصة، والإضافات، والتقارير كبيرة الحجم، وتسلسل الإقفال، ومسار الشبكة من مواقعكم. أما مشكلات أداء المنصة فتُحال إلى دعم SAP.

الأخطاء الشائعة

1. معاملة الاختبار الوظيفي على أنه اختبار أداء. تثبت الاختبارات الوظيفية أن المعاملة تعطي النتيجة الصحيحة. ولا تقول شيئًا عن 150 شخصًا ينفذونها في الوقت نفسه.
2. ترك الأداء لفريق Basis. يتولى Basis التحجيم وجدولة المهام. لكنه لا يتولى تصميم التقارير أو بنية خدمات OData أو تصميم تدفقات التكامل، وهذه هي التي تقود أداء التطبيقات.
3. إسناد المسؤولية إلى ضمان الجودة وحده. ينفذ فريق ضمان الجودة الاختبارات ويبلغ عن النتائج، لكن القرارات التي تسبب مشكلات الأداء تُتخذ في التصميم. يحتاج قائد اختبار أو مهندس بنية على مستوى البرنامج إلى صلاحية الاعتراض عليها مبكرًا، ويجب أن تحدد مصفوفة RACI من يستطيع إيقاف التشغيل الفعلي لأسباب تتعلق بالأداء.
4. قبول الفجوات كمشكلات معروفة. معظم البرامج التي تعاني من مشكلات أداء في الإنتاج لم تتخطَّ الاختبار. لقد اختبرت دون معايير متفق عليها، أو اختبرت ثم قبلت الإخفاقات تحت ضغط الجدول الزمني.

اكتبوا خمسة أو ستة معايير قبول لأكثر معاملاتكم ومهامكم خطورة، مع مسؤول مسمّى لكل منها. إذا لم تستطيعوا ملء الجدول أعلاه، فأنتم لستم جاهزين للاختبار، وقد وجدتم الفجوة الأولى.

ثم تحققوا من أمرين: أن تحديثًا لبيانات مقنّعة بحجم الإنتاج موجود في الخطة، وأن دورة التزامن تنتهي قبل أن يبدأ UAT.

إذا أردتم رأيًا مستقلًا في خطة لاختبار الأداء أو في قرار تشغيل فعلي، فأنا أساعد المؤسسات في ذلك. يمكنكم التواصل معي هنا.

ما هو اختبار أداء SAP؟

يتحقق من سلوك SAP تحت حمل واقعي: أزمنة الاستجابة لمعاملات المستخدمين، ومدد تشغيل المهام الخلفية، وإنتاجية الواجهات، واستهلاك الموارد حين يعمل كثيرون في الوقت نفسه. ويجب أن يجري قبل التشغيل الفعلي.

الصحة الوظيفية والأداء خاصيتان مختلفتان. فالمعاملة التي تعمل بشكل صحيح لمستخدم واحد قد تنتهي مهلتها مع 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 البنية التحتية: التحجيم والمنطقة والشبكة وتوافر المنصة. وتترك وثيقة الأدوار والمسؤوليات في RISE من SAP تنفيذ اختبار الحمل وضبط SQL المكلف للعميل، ما لم تُشترَ SAP Cloud Application Services برسوم إضافية.

يتولى العميل والشريك أداء التطبيقات وقرار القبول. اكتبوا التقسيم في معايير القبول حتى يكون لكل حد مسؤول.