يستخدم الكثير SoapUI لاختبار واجهة برمجة التطبيقات نفسها والتطبيقات التي تصل إلى واجهة برمجة التطبيقات. أداة مرنة إلى حد ما تسمح ، على سبيل المثال ، بتصدير
ملف واجهة برمجة تطبيقات متعرجة وإنشاء خدمة وهمية بناءً على ذلك.
منذ وقت ليس ببعيد ، واجهت في شركتنا مشكلة مماثلة ، ولكن في ظروف غير تافهة. البيانات الأولية: من الضروري اختبار تطبيق خادم يتلقى مهمة كمدخل ؛ أثناء التنفيذ ، يشير إلى API ؛ يعتمد كل طلب لاحق على استجابة API. تم تضمين المنطق في التطبيق. أي أنه نوع من الصندوق الأسود حيث تحتاج إلى اختبار العديد من المخارج من البرنامج النصي ، عندما يكون هناك مدخل واحد فقط للبرنامج النصي.
أدناه أقترح مثالاً للحل الذي سمح بدمجه بسهولة في البنية التحتية للانحدار ، بالإضافة إلى وجود هامش للتوسع ، في حالة زيادة تغطية نطاق السيناريوهات وتعقيدها.
أولاً ، قم بإنشاء خدمة وهمية في SoapUI. يتم ذلك ببضع نقرات:
الآن دعنا ننتقل إلى إنشاء بذرة للاستعلامات. نظرًا لوجود إدخال واحد فقط في البرنامج النصي في المهمة ، فلدينا خيارات:
- استخدام معرف البرنامج النصي وتمريره في كل طلب ، وفي كل كعب حدد الاستجابة اعتمادًا على هذا المعرف ؛
- حدد مسبقًا قائمة بالإجابات لكل كعب وخزنها في المتغيرات العامة قبل تشغيل الاختبار.
يمكن استخدام الخيار الأول عندما يكون من الضروري تلقي استجابة من كعب الروتين لعدة طلبات في نفس الوقت. يتطلب التنفيذ أن يكون تطبيق العميل قادرًا على إرسال معرف محدد في كل طلب API. في حالتنا ، كان هذا مستحيلًا عمليًا ، ولم يكن الاختبار المتزامن للعديد من السيناريوهات مطلوبًا ، لذلك تم اختيار الخيار الثاني.
لذا ، لتعيين قائمة باستجابات كعب الروتين ، نقوم بتنفيذ الاستعلام التالي قبل تشغيل الاختبار:
Post: http:
في خدمة Mock ، نضيف معالجة الطلب "SetScenario". يحتوي على إجابتين فقط: "200_OK" إذا تمت معالجة الطلب الوارد بشكل صحيح ، و "400_BadRequest" إذا تم تقديم الطلب بشكل غير صحيح:
في النص البرمجي ، نوزع قيم الاستجابة للعناوين العالمية على المتغيرات العالمية:
def reqBody = mockRequest.getRequestContent() // def reqBodyParams = [:] reqBody.tokenize("&").each // , { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID ( ); { // , , “?:” – : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") // … return "200_OK" } else { return "400_BadRequest" }
يمكن رؤية المتغيرات المعينة في نافذة إعدادات الخدمة:
وبالتالي ، فإننا نصف المنطق الكامل لخدمة Mock بهذه الطريقة ، وفي بذات طرق واجهة برمجة التطبيقات ، يكفي كتابة نص برمجي يقرأ قيمة الاستجابة من المتغير العام:
Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}"
AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}"
إذا كنت بحاجة إلى إضافة نصوص المهلة ، وتأخر الاستجابات ، ثم أضف متغير التأخير ، على سبيل المثال:
Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing…
ونضيف في البرنامج النصي كعب:
… Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}"
إذا كان من الضروري دعم الطلب المتكرر ، فإننا ننقل قائمة الإجابات:
Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK
وفي البرنامج النصي للمعالجة ، أضف رمزًا مميزًا واحذف الاستجابة المرسلة بالفعل ، إذا لم تكن الأخيرة:
def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) }
ونتيجة لذلك ، حصلنا على خدمة Mock بسيطة ، يسهل نقلها بين مقاعد الاختبار والبيئات ، لأن ملف المشروع هو ملف xml. تبدأ الخدمة فورًا بعد الاستيراد ، بدون إعدادات إضافية (باستثناء تغيير عنوان الخادم والمنفذ بالطبع). في الوقت الحالي ، يساعدنا هذا في اختبار التطبيق بغض النظر عن استقرار خادم IPA والفترات الزمنية المحتملة لعدم إمكانية الوصول إليه.
ما نخطط لإضافته: دمج هذا الحل لاختبار التطبيقات قبل وأثناء تطوير واجهة برمجة التطبيقات نفسها. على سبيل المثال ، عندما يكون الوصف جاهزًا بالفعل في شكل ملف متسلل ، ولكن الخادم في طور الإعداد. لا تتزامن دورات تطوير API وتطبيقات العميل دائمًا. في هذه المرحلة ، من المفيد اختبار تطبيق العميل قيد التطوير لشيء ما ، ويمكن لخدمة Mock أن تساعد كثيرًا.
تحديث: في حال كان لديك أسئلة وتعليقات مفيدة.