[ تعرٌف على ] محاكاة افتراضية للخدمة # اخر تحديث اليوم 2024-04-27

تم النشر اليوم 2024-04-27 | محاكاة افتراضية للخدمة

نظرة عامة

تحاكي المحاكاة الافتراضية للخدمة سلوك مكونات البرامج لإزالة قيود التبعية على فرق التطوير والاختبار. تحدث مثل هذه القيود في بيئات معقدة ومترابطة عندما يكون المكون المتصل بالتطبيق قيد الاختبار: لم تكتمل بعد
لا يزال يتطور
يسيطر عليها طرف ثالث أو شريك
متاح للاختبار بسعة محدودة أو في أوقات غير ملائمة
من الصعب توفير أو تكوين في بيئة اختبار
مطلوب للوصول المتزامن من قبل فرق مختلفة مع إعداد بيانات اختبار متنوعة ومتطلبات أخرى
مقيد أو مكلف للاستخدام لاختبار الحمل والأداء
على الرغم من أن مصطلح «ظاهرية الخدمة» يعكس التركيز المبدئي لهذه التقنية على ظاهرية خدمات الويب، فإن ظاهرية الخدمة تمتد عبر جميع جوانب التطبيقات المركبة: الخدمات وقواعد البيانات والحواسيب المركزية وESBs والمكونات الأخرى التي تتواصل باستخدام بروتوكولات المراسلة الشائعة. أدوات مماثلة أخرى تسمى محاكيات واجهة برمجة التطبيقات، أدوات محاكاة واجهة برمجة التطبيقات، على الزوجي اختبار الأسلاك. تحاكي المحاكاة الافتراضية للخدمات فقط سلوك المكونات التابعة المحددة التي يحتاجها المطورون أو المختبرون من أجل إتمام معاملاتهم من البداية إلى النهاية. فبدلاً من إضفاء الطابع الافتراضي على أنظمة بأكملها، فإنه يقوم فقط بإضفاء الطابع الافتراضي على شرائح محددة فقط من السلوك المستقل الحاسم لتنفيذ مهام التطوير والاختبار. تحاكي المحاكاة الافتراضية للخدمات فقط سلوك المكونات التابعة المحددة التي يحتاجها المطورون أو المختبرون من أجل إتمام معاملاتهم من البداية إلى النهاية. فبدلاً من إضفاء الطابع الافتراضي على أنظمة بأكملها، فإنه يقوم فقط بإضفاء الطابع الافتراضي على شرائح محددة فقط من السلوك المستقل الحاسم لتنفيذ مهام التطوير والاختبار. وهذا يوفر منطق تطبيق يكفي فقط حتى يحصل المطورون أو المختبرون على ما يحتاجون إليه دون الحاجة إلى انتظار اكتمال الخدمة الفعلية وإتاحتها بسهولة. على سبيل المثال، بدلاً من محاكاة قاعدة بيانات كاملة (وتنفيذ جميع إدارة بيانات الاختبار المرتبطة بالإضافة إلى إعداد قاعدة البيانات لكل جلسة اختبار)، يمكنك مراقبة كيفية تفاعل التطبيق مع قاعدة البيانات، ثم محاكاة سلوك قاعدة البيانات ذات الصلة (SQL الاستعلامات التي تم تمريرها إلى قاعدة البيانات، ومجموعات النتائج المقابلة التي يتم إرجاعها، وما إلى ذلك).

العلاقة بسرقة واستهزاء

نهج بديل للعمل حول قيود الوصول إلى بيئة الاختبار الموضحة في مقدمة هذه المقالة لأعضاء الفريق لتطوير كعوب الأسلوب أو محاكاة الكائنات التي تحل محل الموارد التابعة. أصبح عيب هذا النهج واضحًا في أوائل العقد الأول من القرن الحالي مع ظهور بنية موجهة نحو الخدمة. أدى انتشار التطبيقات المركبة التي تعتمد على العديد من الخدمات التابعة، بالإضافة إلى ظهور تطوير برمجيات أجايل بعد نشر بيان أجايل لعام 2001، إلى صعوبة متزايدة للمطورين أو المختبرين في تطوير عدد ونطاق وتعقيد الأوتاد أو النماذج يدويًا مطلوب لإكمال مهام التطوير والاختبار لتطوير تطبيقات المؤسسة الحديثة. كانت الخطوة الأولى في التطور من الاستدلال إلى المحاكاة الافتراضية للخدمة هي التكنولوجيا المعبأة في أدوات اختبار SOA منذ عام 2002. تم تصميم التطبيقات الأقدم للمحاكاة الافتراضية للخدمات لأتمتة عملية تطوير محاكاة بسيطة تشبه العقب بحيث يمكن اختبار التطبيقات المركبة بشكل أكثر كفاءة. مع استمرار نمو أنظمة المؤسسات في التعقيد والتوزيع بشكل متزايد، حول موردو أدوات البرامج التركيز من التلعثم إلى المحاكاة الافتراضية للخدمات الأكثر تركيزًا على البيئة. في حين أنه لا يزال من الممكن إتمام عملية الحصر من خلال التطوير اليدوي وإدارة بذرة، فإن ما أصبح يُعرف باسم «محاكاة الخدمة الظاهرية» قد اكتمل باستخدام إحدى تقنيات المحاكاة الافتراضية للبرمجيات التجارية الجاهزة كمنصة لتطوير ونشر «الأصول الافتراضية للخدمة» الخاصة بهم.

تطبيق

تتضمن ظاهرية الخدمة إنشاء «أصل افتراضي» ونشره يحاكي سلوك مكون حقيقي مطلوب لممارسة التطبيق قيد الاختبار، ولكن من الصعب أو المستحيل الوصول إليه لأغراض التطوير والاختبار. يمثل الأصل الظاهري مكونًا تابعًا من خلال الاستماع إلى الطلبات وإعادة استجابة مناسبة، مع الأداء المناسب. بالنسبة لقاعدة البيانات، قد يتضمن هذا الاستماع إلى عبارة SQL، ثم إرجاع صفوف مصدر البيانات. بالنسبة لخدمة ويب، قد يتضمن هذا الاستماع لرسالة لغة الترميز القابلة للامتداد عبر بروتوكول نقل النص الفائق، أو JMS، أو MQ، ثم إرجاع رسالة لغة الترميز القابلة للامتداد أخرى. قد تعكس وظيفة وأداء الأصل الظاهري الوظيفة أو الأداء الفعلي للمكون التابع، أو قد تحاكي ظروفًا استثنائية (مثل الأحمال الشديدة أو حالات الخطأ) لتحديد كيفية استجابة التطبيق قيد الاختبار في ظل هذه الظروف. عادةً ما يتم إنشاء الأصول الافتراضية من خلال: تسجيل الاتصال المباشر بين المكونات أثناء استخدام النظام من التطبيق قيد الاختبار (AUT)
توفير سجلات تمثل الاتصال التاريخي بين المكونات
تحليل مواصفات واجهة الخدمة (مثل WSDL)
تحديد السلوك يدويًا باستخدام عناصر تحكم الواجهة المختلفة وقيم مصدر البيانات
ثم يتم تكوينها أيضًا لتمثيل بيانات ووظائف وأوقات استجابة محددة. يتم نشر الأصول الافتراضية محليًا أو في السحابة (العامة أو الخاصة). مع تهيئة بيئات التطوير أو الاختبار لاستخدام الأصول الافتراضية بدلاً من المكونات التابعة، يمكن للمطورين أو المختبرين بعد ذلك ممارسة التطبيق الذي يعملون عليه دون الحاجة إلى انتظار اكتمال المكونات التابعة أو الوصول إليها بسهولة. يشير محللو الصناعة إلى أن الوضع الافتراضي للخدمة هو الأنسب لـ "متاجر تكنولوجيا المعلومات التي تتمتع بخبرة كبيرة في" تخطي "اختبار التكامل بسبب" البرامج التابعة "، ومع تسخير اختبار متطور إلى حد معقول.

أجايل وديف أوبس

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

شرح مبسط

في هندسة البرمجيات، تكون المحاكاة الافتراضية للخدمة طريقة لمحاكاة سلوك مكونات محددة في التطبيقات القائمة على المكونات غير المتجانسة مثل التطبيقات المدفوعة بواجهة برمجة التطبيقات والتطبيقات المستندة إلى السحابة والمعماريات الموجهة للخدمة. يتم استخدامه لتوفير تطوير البرامج وفرق ضمان الجودة أو الاختبار للوصول إلى مكونات النظام التابعة اللازمة لممارسة تطبيق قيد الاختبار (AUT)، ولكنها غير متوفرة أو يصعب الوصول إليها لأغراض التطوير والاختبار. مع سلوك المكونات التابعة «افتراضية»، يمكن أن يستمر الاختبار والتطوير بدون الوصول إلى المكونات الحية الفعلية. يعترف البائعون ومحللو الصناعة والمنشورات الصناعية بأن الخدمة الافتراضية تختلف عن السخرية.[1][2]