ما هو اختبار SOA؟ البرنامج التعليمي مع المثال

ما هو اختبار SOA؟

SOA (موجهة نحو الخدمة Archiاختبار (البنية) هو اختبار أسلوب SOA المعماري، حيث يتم تصميم مكونات التطبيق للتواصل عبر بروتوكولات الاتصال، وعادةً عبر الشبكة.

ما هي الخدمية؟

SOA هي طريقة لدمج تطبيقات الأعمال والعمليات معًا لتلبية احتياجات العمل.

In هندسة البرمجياتتوفر بنية الخدمات الموجهة (SOA) المرونة والسرعة في عمليات الأعمال. إذ يمكن توجيه أي تغيير في عملية أو تطبيق إلى مكون معين دون التأثير على النظام بأكمله.

يقوم مطورو البرامج العاملون في مجال SOA إما بتطوير أو شراء أجزاء من البرامج تسمى الخدمات.

ما هي الخدمة؟

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

• يمكن أن تكون الخدمة وحدة وظيفية ضمن تطبيق أو عملية تجارية، قابلة لإعادة الاستخدام أو التكرار من قِبل أي تطبيق أو عملية أخرى. (على سبيل المثال، في الصورة أعلاه، بوابة الدفع هي خدمة يمكن لأي موقع للتجارة الإلكترونية إعادة استخدامها. فعندما يحتاج موقع التجارة الإلكترونية إلى إجراء عملية دفع، يتصل بخدمة بوابة الدفع أو يطلبها. وبعد إتمام عملية الدفع عبر البوابة، يتم إرسال رد إلى موقع التجارة الإلكترونية).
• الخدمات سهلة التجميع وسهلة إعادة تكوين المكونات.
• يمكن تشبيه الخدمات بمكونات البناء. فهي قادرة على بناء أي تطبيق مطلوب، كما أن إضافتها أو إزالتها من التطبيق أو عملية العمل أمر سهل.
• تُعرَّف الخدمات بشكل أكبر من خلال الوظيفة التجارية التي تؤديها بدلاً من كونها أجزاء من التعليمات البرمجية.

خدمات الويب

يتم عرض معظم خدمات SOA كخدمات ويب، لذا فإن آليات استدعاء خدمة الويب تستحق التوضيح قبل طبقات الاختبار.

خدمات الويب هي مكونات تطبيق مستقلة متاحة عبر الإنترنت.

يمكن نشرها والعثور عليها واستخدامها على الإنترنت، وتتواصل فيما بينها عبر الإنترنت. يوضح التسلسل أدناه كيفية تفاعل مزود الخدمة والسجل والمستهلك.

• يقوم مزود الخدمة بنشر الخدمة على الإنترنت.
• يبحث العميل عن خدمة ويب معينة في سجل خدمات الويب.
• A URL و مبادئ السلوك wsdl يتم إرجاع البيانات المطلوبة لخدمة الويب. باستخدام WSDL و URL، يتم التواصل بين مزود الخدمة والمتلقي من خلال رسائل SOAP.
• عندما يقوم المستهلك باستدعاء خدمة ويب، يتم إنشاء اتصال HTTP مع المزود.
• يتم إنشاء رسالة SOAP لتوجيه الموفر لاستدعاء منطق خدمة الويب المطلوب.
• الرد المُستلم من المزوّد هو رسالة SOAP مُضمّنة في رد HTTP. هذا الرد هو تنسيق البيانات الذي يفهمه تطبيق المستهلك.

مثال

تُظهر لقطة الشاشة أدناه تقريرًا عن حالة الطقس مقدمًا من خدمة خارجية ومضمنًا في الصفحة الرئيسية لمحرك البحث.

تعرض الصفحة الرئيسية لموقع الويب ومحرك البحث تقريرًا يوميًا عن حالة الطقس. وبدلًا من برمجة قسم تقارير الطقس من الصفر، يمكن شراء خدمة تقارير الطقس من مزود خدمة ودمجها في الصفحات.

طبقات اختبار بنية الخدمات الموجهة (SOA)

تتألف بنية الخدمات الموجهة (SOA) من تقنيات متنوعة، وتتضمن التطبيقات المبنية باستخدامها خدمات متعددة مترابطة بشكل غير محكم. يوضح الرسم البياني أدناه الطبقات الثلاث التي يجب أن تغطيها خطة الاختبار.

ينبغي أن يركز اختبار بنية الخدمات الموجهة (SOA) على 3 طبقات من النظام.

طبقة الخدمات

تتكون هذه الطبقة من الخدمات التي يعرضها النظام، والمستمدة من وظائف الأعمال.

على سبيل المثال، لنفترض موقعًا إلكترونيًا للصحة والعافية يتكون مما يلي:

• الوزن Tracكير
• سكر الدم Tracكير
• ضغط الدم Tracكير

Tracتعرض kers البيانات ذات الصلة وتاريخ إدخالها. تتكون طبقة الخدمات من الخدمات التي تحصل على البيانات ذات الصلة من قاعدة البيانات:

• الوزن Tracخدمة كير
• سكر الدم Tracخدمة كير
• ضغط الدم Tracخدمة كير
• خدمة تسجيل الدخول

طبقة العملية

تتكون طبقة العمليات من العمليات، وهي مجموعة الخدمات التي تشكل جزءًا من وظيفة واحدة.

قد تكون هذه العمليات جزءًا من واجهة المستخدم (على سبيل المثال، محرك بحث) أو جزءًا من أداة ETL التي تسحب البيانات من قاعدة البيانات.

ينصب التركيز الرئيسي في هذه الطبقة على واجهات المستخدم والعمليات. واجهة المستخدم الخاصة بالوزن tracيُعدّ نظام ker وتكامله مع قاعدة البيانات محور التركيز الرئيسي.

الوظائف التالية جديرة بالاعتبار:

• إضافة بيانات جديدة
• تحرير البيانات الموجودة
• إنشاء ملف tracكير
• حذف البيانات

طبقة المستهلك

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

بناءً على هذه الطبقات، يتم توزيع اختبار تطبيق SOA على ثلاثة مستويات:

• مستوى الخدمة
• مستوى واجهة
• مستوى النهاية إلى النهاية

يختلف اتجاها السفر: يتم استخدام نهج من أعلى إلى أسفل لتصميم الاختبار، بينما يتم استخدام نهج من أسفل إلى أعلى لتنفيذ الاختبار.

استراتيجية لاختبار SOA

نهج تخطيط الاختبار

• ينبغي على مختبري بنية الخدمات الموجهة (SOA) فهم البنية الكاملة للتطبيق.
• يجب تقسيم التطبيق إلى خدمات مستقلة (خدمة لها هيكل طلب واستجابة خاص بها ولا تعتمد على أي خدمة أخرى لتكوين استجابة).
• يجب إعادة تنظيم بنية التطبيق إلى ثلاثة مكونات - البيانات والخدمات وتطبيقات الواجهة الأمامية.
• يجب تحليل جميع المكونات بعناية، وينبغي وضع سيناريوهات العمل.
• ينبغي تصنيف سيناريوهات الأعمال إلى سيناريوهات عامة وسيناريوهات خاصة بالتطبيقات.
• A Tracمصفوفة القدرات ينبغي إعدادها، وينبغي أن تكون جميع حالات الاختبار tracتم تطبيقها على سيناريوهات الأعمال.

نهج تنفيذ الاختبار

• يجب اختبار كل مكون من مكونات الخدمة.
• اختبار التكامل يجب إجراء مكونات الخدمة للتحقق من صحة تدفق البيانات من خلال الخدمات وسلامة البيانات.
• اختبار النظام ينبغي إجراء تحليل كامل للنموذج للتحقق من صحة تدفق البيانات بين تطبيق الواجهة الأمامية وقاعدة البيانات.
• اختبار أداء يجب أن يتم ذلك من أجل الضبط الدقيق والأداء الأمثل.

طرق اختبار الخدمية

1) اختبار قائم على البيانات وموجه بسيناريوهات الأعمال

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

2) بذرة

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

3) اختبار الانحدار

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

4) اختبار مستوى الخدمة

يشمل اختبار مستوى الخدمة اختبار المكون من حيث الوظائف والأمان والأداء وقابلية التشغيل البيني. يجب اختبار كل خدمة على حدة أولاً.

5) اختبار وظيفي

الاختبار الوظيفي ينبغي القيام بذلك في كل خدمة من أجل:

• تأكد من أن الخدمة تقدم الاستجابة الصحيحة لكل طلب.
• تأكد من استلام الأخطاء الصحيحة للطلبات التي تحتوي على بيانات غير صالحة أو خاطئة.
• تحقق من كل طلب واستجابة لكل عملية يتعين على الخدمة تنفيذها في وقت التشغيل.
• التحقق من صحة رسائل الخطأ عند حدوث خطأ على مستوى الخادم أو العميل أو الشبكة.
• التحقق من أن الإجابات الواردة بالتنسيق الصحيح.
• تحقق من أن البيانات المستلمة في الاستجابة تتطابق مع البيانات المطلوبة.

6) اختبار الأمان

يُعد اختبار أمان خدمة الويب جانبًا مهمًا أثناء اختبار مستوى الخدمة لتطبيق SOA، لأنه يضمن سلامة التطبيق.

هناك عوامل يجب تغطيتها أثناء الاختبار:

• يجب على خدمة الويب الالتزام بالمعيار الصناعي المحدد من قبل WS-Security.
• يجب أن تعمل التدابير الأمنية بشكل لا تشوبه شائبة.
• تشفير البيانات والتوقيعات الرقمية على المستندات.
• المصادقة والتفويض.
• سيتم اختبار ثغرات حقن SQL، والبرمجيات الخبيثة، وXSS، وCSRF، وغيرها من الثغرات الأمنية على XML.
• هجمات رفض الخدمة.

7) اختبار الأداء

يجب إجراء اختبار أداء الخدمة لأن الخدمات قابلة لإعادة الاستخدام وقد تستخدم تطبيقات متعددة نفس الخدمة.

يتم أخذ العوامل التالية في الاعتبار أثناء الاختبار:

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

8) اختبار مستوى التكامل

• يضمن اختبار مستوى الخدمة الأداء السليم للخدمات بشكل فردي؛ ولكنه لا يضمن عمل المكونات المترابطة.
• يتم إجراء اختبار التكامل مع التركيز بشكل أساسي على واجهات.
• تغطي هذه المرحلة جميع سيناريوهات العمل المحتملة.
• يجب إجراء اختبار غير وظيفي للتطبيق مرة أخرى في هذه المرحلة. تضمن اختبارات الأمان والامتثال والأداء توافر النظام واستقراره من جميع النواحي.
• يجب اختبار بروتوكولات الاتصال والشبكة للتحقق من اتساق اتصالات البيانات بين الخدمات.

9) نهاية إلى نهاية الاختبار

تضمن هذه المرحلة أن يتوافق التطبيق مع متطلبات العمل من الناحيتين الوظيفية وغير الوظيفية.

سيتم اختبار العناصر المذكورة أدناه خلال اختبار شامل:

• جميع الخدمات تعمل كما هو متوقع بعد التكامل
• معالجة الاستثناء
• واجهة مستخدم التطبيق
• تدفق البيانات السليم من خلال جميع المكونات
• طريقة العمل

التحديات في اختبار بنية الخدمات الموجهة (SOA)

نادراً ما يكون تطبيق هذه الأساليب أمراً سهلاً، وتتكرر الصعوبات المذكورة أدناه في كل برنامج SOA تقريباً.

• نقص في واجهات الخدمات.
• تمتد عملية الاختبار عبر أنظمة متعددة، مما يخلق احتياجات بيانات معقدة.
• التطبيق عبارة عن مجموعة من المكونات المختلفة التي تميل إلى التغيير، لذا فإن الحاجة إلى اختبار الانحدار تكون أكثر تكرارًا.
• بسبب البنية متعددة الطبقات، يصعب عزل العيوب.
• بما أن الخدمة تستخدم من قبل واجهات مختلفة، فمن الصعب التنبؤ بالحمل، مما يجعل تخطيط اختبار الأداء أمراً شاقاً.
• تُعدّ بنية الخدمات الموجهة (SOA) مجموعة من التقنيات غير المتجانسة. ويتطلب اختبار تطبيق SOA أشخاصًا ذوي مهارات مختلفة، مما يزيد بدوره من تكاليف التخطيط والتنفيذ.
• نظراً لأن التطبيق يدمج خدمات متعددة، فإن اختبار الأمان يواجه تحدياته الخاصة. فالتحقق من صحة المصادقة والتفويض أمر صعب.

أدوات اختبار SOA

تتوفر في السوق العديد من أدوات اختبار بنية الخدمات الموجهة (SOA) لمساعدة المختبرين في اختبار تطبيقاتها. إليكم بعضًا من أدوات اختبار بنية الخدمات الموجهة الشائعة.

1) SoapUI

SoapUI هي أداة اختبار وظيفية مفتوحة المصدر للخدمات و اختبار API.

• تطبيقات سطح المكتب
• يدعم بروتوكولات متعددة — SOAP، REST، HTTP، JMS، AMF، JDBC
• يمكن تطوير خدمات الويب وفحصها واستدعاؤها.
• يمكن استخدامه أيضاً لاختبار الأحمال، اختبار الأتمتة، واختبار الأمان
• يمكن إنشاء بذرة بواسطة MockServices
• يمكن إنشاء طلبات واختبارات خدمة الويب تلقائيًا من خلال عميل خدمة الويب الخاص بها.
• يحتوي على أدوات إعداد تقارير مدمجة
• تم تطويرها بواسطة شركة سمارت بير، التي تقوم بشحن كل من المصدر المفتوح SoapUI التوزيع والتجارة ReadyAPI طبعة

2) تقنية المحاكاة الافتراضية لخدمات برودكوم (المعروفة سابقًا باسم iTKO LISA)

LISA عبارة عن مجموعة منتجات توفر حلاً لاختبار الوظائف للأنظمة الموزعة مثل SOA. انتقل المنتج من iTKO إلى CA Technologies ويُباع اليوم تحت اسم Broadcom Service Virtualization.

• يمكن استخدامه أيضًا لاختبارات الانحدار والتكامل والتحميل والأداء.
• يمكن استخدامها لتصميم وتنفيذ الاختبارات.

3) UFT واحد (كان يُعرف سابقًا باسم اختبار خدمة HP)

Service Test هي أداة اختبار وظيفي تدعم اختبار كل من واجهة المستخدم والخدمات المشتركة. تم دمج إمكانية اختبار واجهة برمجة التطبيقات (API) الخاصة بها في Unified Functional Testing، والتي تُباع الآن بواسطة OpenText as UFT واحد.

• يمكن إجراء كل من الاختبارات الوظيفية واختبارات الأداء للخدمات بواسطة برنامج نصي واحد.
• مُدمج مع مركز الجودة، ويُباع الآن باسم OpenText مركز إدارة دورة حياة التطبيقات / مركز الجودة.
• يمكن إدارة كمية هائلة من الخدمات والبيانات.
• يدعم اختبار التشغيل البيني من خلال محاكاة بيئات عملاء JEE وAXIS وDotNet.

4) Parasoft SOAtest

Parasoft SOAtest هي مجموعة أدوات اختبار وتحليل تم تطويرها لاختبار واجهات برمجة التطبيقات والتطبيقات التي تعتمد على واجهات برمجة التطبيقات.

• يدعم خدمات الويب، وREST، وJSON، وMQ، وJMS، وTIBCO، وHTTP، وتقنيات XML.
• الاختبارات الوظيفية، واختبارات الوحدة، واختبارات التكامل، واختبارات الانحدار، واختبارات الأمان، واختبارات قابلية التشغيل البيني، واختبارات الامتثال، واختبارات الأداء ممكنة.
• يمكن إنشاء نماذج أولية باستخدام باراسوفت فيرتشوالايزوالتي تتمتع بقدرات أكبر من SoapUI خدمات وهمية.

حالات استخدام اختبار SOA

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

لنفترض وجود موقع للتجارة الإلكترونية يحتوي على الوظائف والوظائف الفرعية التالية.

معالجة الطلب

يقسم الرسم البياني أدناه عملية معالجة الطلبات إلى وظائف فرعية تصبح خدمات.

المرحلة 1

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

دعونا نلقي نظرة على الخدمات التالية في التطبيق.

• إنشاء النظام
• التحقق من حالة العميل
• تغيير حالة الطلب
• تفحص قائمة الطلبات
• تأكد من المخزون

الوظائف التجارية هي نفسها وظائف الموقع الإلكتروني.

ملاحظة: ستتضمن وثيقة استراتيجية الاختبار قائمة بالخدمات والوظائف التي يجب اختبارها.

المرحلة 2

هذه هي مرحلة تخطيط الاختبار. حالات الاختبار تُكتب هذه التعليمات لكل مستوى.

مستوى من البداية إلى النهاية. تُكتب حالات الاختبار لكل حالة استخدام وتدفق عمل تجاري. فيما يلي أمثلة على حالات الاختبار.

• أنشئ طلبًا باستخدام مستخدم نشط.
• قم بإنشاء طلب مع مستخدم غير نشط.
• أنشئ طلبًا لمنتج متوفر بكمية طلب أقل من الكمية المتوفرة.
• أنشئ طلبًا لمنتج متوفر بكمية طلب أكبر من الكمية المتوفرة.
• أنشئ طلبًا يحتوي على عدة منتجات.
• إلغاء الطلب بالكامل.
• إلغاء الطلب جزئياً.

مستوى التكامل. تُكتب حالات الاختبار لدمج قاعدة البيانات وواجهة المستخدم. فيما يلي أمثلة على حالات الاختبار.

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

مستوى الخدمة. يتم اختبار كل خدمة للتأكد من استيفائها لجميع شروط البيانات. فيما يلي بعض الأمثلة.

رقم	تفاصيل الطلب	حالة الطلب
1	إنشاء النظام. عدد العناصر = 1	الكمية عند الطلب < الكمية في قاعدة البيانات
2	إنشاء النظام. عدد العناصر > 1	الكمية المطلوبة < الكمية الموجودة في قاعدة البيانات
3	إنشاء النظام. عدد العناصر = 1	الكمية عند الطلب> الكمية في قاعدة البيانات
4	تفحص قائمة الطلبات	الحالة في قاعدة البيانات = نشطة
5	تفحص قائمة الطلبات	الحالة في قاعدة البيانات = تم الشحن
6	تفحص قائمة الطلبات	الحالة في قاعدة البيانات = ملغاة
7	تفحص قائمة الطلبات	معرف الطلب = غير صالح
8	التحقق من توافر المنتج	كمية المنتج>0
9	التحقق من توافر المنتج	كمية المنتج =0
10	التحقق من توافر المنتج	معرف المنتج = غير صالح

المرحلة الثالثة - تنفيذ الاختبار

يستخدم تنفيذ الاختبار نهجًا تصاعديًا: يتم إجراء اختبار مستوى الخدمة أولاً، ثم مستوى التكامل، وأخيرًا اختبار شامل من البداية إلى النهاية.

1) مستوى الخدمة

لنفترض أن SoapUI تُستخدم الأداة لاختبار التطبيق. WSDL و URL يتم تصفحها في نافذة الاختبار الخاصة بـ SoapUIويتم عرض طلب كل خدمة في نافذة الطلبات. ومن خلال تعديل البيانات وفقًا لحالات اختبار مستوى الخدمة، يتم إنشاء طلبات لكل حالة اختبار.

حالة الاختبار	أطلب	الرد المتوقع
إنشاء طلب. عدد الأصناف = 1، الكمية المطلوبة < الكمية في قاعدة البيانات	×2 2	o3251 ناجح
إنشاء طلب. عدد الأصناف > 1، الكمية في الطلب < الكمية في قاعدة البيانات	y1 1 y2 3	o3251 ناجح
إنشاء طلب. عدد الأصناف = 1، الكمية في الطلب > الكمية في قاعدة البيانات	×23 200	باطل غير ناجح
تحقق من حالة الطلب. الحالة في قاعدة البيانات = نشط	o9876	نشيط ناجح
تحقق من حالة الطلب. الحالة في قاعدة البيانات = تم الشحن	o9656	تم الشحن ناجح
تحقق من حالة الطلب. رقم الطلب = غير صالح	y5686	باطل غير ناجح
تحقق من توفر المنتج. كمية المنتج > 0	د34	34 نعم ناجح
تحقق من توفر المنتج. كمية المنتج = 0	y34	0 لا ناجح
تحقق من توفر المنتج. رقم تعريف المنتج = غير صالح	com.sder	غير ناجح

2) مستوى التكامل

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

• يقوم المستخدم بفتح الموقع.
• ينتقل المستخدم لتقديم طلب.
• يختار المستخدم منتجًا وكمية مناسبة ويحفظ الطلب.
• يجب عرض رسالة تفيد بنجاح عملية تقديم الطلب.
• يقوم المستخدم بفتح قاعدة البيانات ويتحقق مما إذا كانت تفاصيل الطلب هي نفسها التي تم إدخالها على الموقع الإلكتروني.

3) نهاية إلى نهاية المستوى

يتم تنفيذ عمليات سير العمل وحالات الاستخدام على واجهة المستخدم. إنشاء طلب يتضمن عدة عناصر:

• يقوم المستخدم بفتح الموقع.
• ينتقل المستخدم لتقديم طلب.
• يستفسر المستخدم عن منتج وكمية مناسبة ويضيفهما إلى سلة التسوق.
• تُضاف منتجات أخرى صالحة بكميات صالحة، ويتم حفظ الطلب. يتم الدفع عبر طريقة دفع جديدة، ويتم تأكيد الطلب.
• يجب عرض رسالة تقول "تم تقديم الطلب بنجاح".
• ينبغي على المختبر التحقق من أن التدفق بأكمله يكتمل دون تحريف البيانات.

الأسئلة الشائعة