عندما تحافظ على Oracle BRM (إدارة الفواتير والإيرادات) لبعض الوقت، تبدأ في إدراك أن كمية الكيانات التي تم تكوينها في تزايد مستمر. بحلول هذا الوقت، من المحتمل جدًا أنك قمت أيضًا بتطوير بعض التخصيصات والتكامل مع حلول إضافية. يؤدي تطور بيئتك إلى مجموعة معقدة من الكيانات المتشابكة. تأتي النقطة التي تقرر فيها أنت أو عميلك تغيير شيء ما. قد تبدو الميزة الجديدة سهلة التطوير في البداية. لكن الحقيقة هي أنه من المحتمل جدًا أن تتصادم مع ميزة موجودة، أو ستتطلب تحديث التكوين الحالي أيضًا. ما يبدو تغييرًا بسيطًا، ثم يؤثر على النظام بأكمله. يصعب أحياناً تجنب مثل هذه الأحداث، لكن الاستعداد لها يمكن أن يوفر عليك الكثير من المتاعب. يمكن أن تكون سيناريوهات الاختبار الوظيفي وتعدد استخدامات الاختبار عاملاً مغيراً لقواعد اللعبة.
جدول المحتويات
تدفق التطوير المستمر
هنا في شركة Tridens، أنشأنا تدفقًا مستمرًا للتطوير. جميع تكوينات BRM والتخصيصات والمكونات المدمجة الأخرى لدينا يتم إصدارها وتتبعها بشكل صحيح على نظام التحكم في الإصدار الموزع (Git). تسمح هذه الممارسة لمطورينا بالتحقق من إصدارات المكونات المطلوبة في أي وقت وبدء عملهم. كل شيء على ما يرام حتى هذه النقطة، ولكن كيف نتعامل مع إمكانية تعطل الميزات الجديدة في الإصدار الحالي؟
لدينا تدفق نشر واختبار تم إعداده، والذي يتتبع المستودعات البعيدة لمصادرنا. وبالتالي، في كل مرة يقوم أحد المطورين بإجراء بعض التغييرات ودفعها إلى التحكم في الإصدار، يبدأ هذا في عملية الاختبار. يقوم تدفق النشر ببناء صور docker لجميع المكونات ذات الصلة بأحدث إصداراتها على بيئة محلية (أو بعيدة)، ويتم تنفيذ الاختبارات الآلية للتأكد من استقرار البنية. فقط عندما تنجح الاختبارات، يمكننا إطلاق الإصدارات الجديدة إلى الإنتاج. تساعدنا هذه العملية على ضمان عمل الميزات الجديدة بسلاسة مع الميزات الحالية. الاختبارات المنفذة هي جزء من مجموعة أدوات الاختبار Oracle BRM TestToolkit التي قمنا بتطويرها. وتحتوي مجموعة أدوات اختبار BRM TestToolkit على خطوات وسيناريوهات محددة مسبقًا مع كود غراء الخلفية. الخطوات وصفية للغاية وسهلة الاستخدام، مما يسمح لمطورينا أو أي مستخدم آخر بكتابة سيناريوهات اختبار جديدة بسرعة. ابحث عن مثال لسيناريوهات الاختبار في الصورة أدناه.
مجموعة أدوات اختبار BRM TestToolkit للاختبار الآلي
ما بدأ كسيناريوهات اختبار بسيطة لعمليات إنشاء الحسابات وشراء المنتجات، يمثل اليوم الإطار الرئيسي لاختبارنا BRM TestToolkit. وللتوضيح، لدينا الآن العديد من حالات الاختبار المختلفة وسيناريوهات الحالات الهامشية لضمان أقصى تغطية للميزات المنفذة. تسمح الاختبارات المؤتمتة لمطورينا بالتركيز على المهمة التي بين أيدينا وعدم قضاء وقت طويل في الاختبار اليدوي. بالطبع، في بعض الأحيان، نجد أنفسنا في بعض الأحيان نطور ميزة جديدة لم تشملها سيناريوهات الاختبار بعد. في مثل هذه الحالات، يتم تنفيذ تعريفات خطوات الاختبار ورمز خلفيتها كجزء من تلك الميزة - لاستخدامها في المستقبل أيضًا.
يمكن لـ TestToolkit التواصل مع مكونات مختلفة، مما يتيح إمكانية إجراء تعديلات سريعة للأنظمة الأخرى أيضًا. نستخدم أيضًا إصدارات معاد تصميمها من BRM TestToolkit لمكوناتنا الأخرى. إحدى أحدث الميزات التي أضفناها هي النمطية، حيث يمكن للمطورين وضع علامات على سيناريوهات الاختبار المختلفة كأجزاء من مجموعة. ثم تحتوي كل مجموعة بعد ذلك على نصوصها البرمجية ومنطقها المنفصل، مما يسمح، إذا رغبت في ذلك، بتنفيذ عدد محدد فقط من الاختبارات في وقت واحد وبالتوازي. علاوة على ذلك، تمكننا النمطية من فصل اختبارات التصنيف المدفوعة مسبقًا عن اختبارات التصنيف المدفوعة لاحقًا أو اختبارات الشراء الإضافية عن اختبارات الشراء المتنوعة. يمكنك رؤية تدفق الاختبار في الصورة أدناه.
تغطية سيناريو الاختبار
تتواصل BRM TestToolkit مع واجهة برمجة التطبيقات الخاصة بنا، والتي قمنا بدمجها مع Oracle BRM لتبسيط العمليات الأكثر تعقيدًا. يمكن أن تتفاعل مجموعة أدوات الاختبار أيضًا مع BRM RestBridgeهو الحل المجمع BRM الخاص بنا، والذي يسهل التواصل مع BRM من خلال السماح باستخدام تنسيق JSON أو XML عبر واجهة برمجة تطبيقات REST. تدعم تعريفات خطوة الاختبار، من بين العديد من الخطوات الأخرى، العمليات التالية:
- إنشاء الحساب وإدارته
- شراء الصفقات وعمليات الصفقات الأخرى
- استرداد الرصيد وفحصه
- توليد حركة المرور - أحداث الاستخدام
- مكالمات واجهة برمجة التطبيقات
- إسقاط CDR
- أدوات حركة المرور في الوقت الحقيقي (بروتوكول القطر)
- عمليات التحقق من التصنيف
- تقوم مجموعة أدوات اختبار BRM TestToolkit بمقارنة أحداث الاستخدام المختلفة وعمليات الشراء بالقيم المتوقعة
- يمكن أن يكون لكل خطة أو منتج مختلف مجموعة من ملفات التصنيف الخاصة به، مما يضمن تعدد الاستخدامات في إعدادات المنتجات المعقدة
من خلال تأليف خطوات الاختبار سهلة الاستخدام، يمكن لكل مطور كتابة سيناريوهات الميزة قيد التطوير. في العديد من الحالات، يختار مطورونا إعداد سيناريوهات الاختبار مسبقًا - قبل تطوير الميزة. يتبع إعداد السيناريوهات مسبقًا نمط التطوير المدفوع بالسلوك (BDD). يعني BDD بشكل أساسي أن السيناريوهات تملي تدفق التطوير ويجب أن تكون موجودة مسبقًا. تصف هذه السيناريوهات كيف يجب أن يتصرف النظام، ويجب على المطورين تطوير ميزات جديدة بطريقة تناسب هذه السيناريوهات. يمكننا تنفيذ كل سيناريو اختبار يمكن أن يكون منفصلاً، مما ينتج عنه تقرير بصيغة محددة. فيما يلي مثال لتقرير HTML.
إعداد التقارير
عندما يقوم النظام بتشغيل سيناريوهات الاختبار كجزء من بناء تطوير جديد، فإنه عادةً ما يقوم بتنفيذها بكامل طاقتها - بما في ذلك جميع الاختبارات. قد يستغرق هذا الأمر بعض الوقت من بيئة إلى أخرى، ولكنه يوفر لك صورة واسعة عن كيفية تأثير الميزة الجديدة على أي تطبيقات أخرى موجودة. يمكننا تقييم استقرار البناء من تقرير الاختبار، والذي تقوم مجموعة أدوات اختبار BRM TestToolkit بإنشائه في نهاية تشغيل الاختبار. تحتوي تقارير الاختبار على تفاصيل لكل سيناريو اختبار، ولكنها توفر أيضًا بعض الإحصائيات والتحليلات حول جميع الاختبارات بشكل عام. يمكننا استخدام هذا التحليل للعثور على الاختلافات بين البنيات وللتأكد من أن البنية تعمل بشكل صحيح. انظر مثالاً لتقرير أدناه.
الخاتمة
إن وجود الحل المناسب للاختبار يمكن أن يوفر الكثير من الوقت ويمنع حدوث أي أخطاء غير ضرورية. لذلك، إذا كنت تعاني من أي صعوبات مذكورة في هذه المقالة، أو إذا كنت مهتمًا بمجموعة أدوات اختبار إدارة الاختبارات الخاصة بنا، فلا تتردد في الاتصال بنا. سنقوم بكل سرور بإخبارك بالمزيد عن حلنا ووضع خطة مثالية حول كيفية تحسين عملية النشر والاختبار.
