Research Article

PreventativeTestPro: إطار اختبار هجين قابل للتوسع يستخدم قابلية الملاحظة والذكاء الاصطناعي التوليدي لهندسة جودة البرمجيات الاستباقية

DOI:

10.3791/69316

⸱

March 24th, 2026

 ,  ,  , 
1Vishwakarma University, 2Kasetsart University

In This Article

Summary

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Abstract

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

يسهل النظام تنفيذ الاختبارات المتزامنة من خلال تحليل السجلات الفوري المدفوع بالذكاء الاصطناعي، مما يعزز حلقة تغذية راجعة مستمرة بين العمليات والاختبار. تم التحقق منه في عدة سيناريوهات مؤسسية، بما في ذلك منصات SaaS المعتمدة على الخدمات المصغرة وأنظمة SAP BTP. تشير النتائج التجريبية من أربع عمليات نشر إنتاجية ومجموعة تجريبية مكونة من 49 مهندسا إلى انخفاض يصل إلى 30٪ في متوسط الوقت حتى الحل، وأكثر من 95٪ من الامتثال لاتفاقيات مستوى الانتظار، وتحسن كبير في كل من تغطية الاختبار وتتبع العيوب. الاتصال السلس بالأدوات القياسية في الصناعة يوضح قدرتها على التوصيل والتشغيل.

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

Introduction

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

أدى تزايد شعبية نموذج الرشاقة في شركات البرمجيات إلى اهتمام متزايد ببيئات التكامل المستمر. تشمل مزايا هذه الأنظمة التكامل السلس لتعديلات البرامج المنتظمة، مما يؤدي إلى تطور برمجي سريع وفعال من حيث التكلفة. وبالتالي، ستقوم بإدارة المهام مثل إجراءات البناء، وتنفيذ الاختبارات، وتقرير نتائج الاختبار بكفاءة. تم تطبيق اختبار البرمجيات منذ بداية هندسة البرمجيات. تم تطبيق ممارسة اختبار البرمجيات لتقييم جودة البرمجيات1. يشمل الاختبار مجموعة من الإجراءات التي تهدف إلى اكتشاف وحل أي أخطاء محتملة في البرمجيات قبل نشرها للمستخدمين النهائيين. اختبار البرمجيات هو مرحلة مكلفة في عملية التطوير2. تكلفة اختبار البرمجيات وتصحيح الأخطاء تشكل أكثر من 50 بالمئة من إجمالي تكلفة التطوير 3,4. التكلفة المرتبطة باختبار الانحدار تعتمد على تعقيد التطبيق وحجم مجموعة الاختبار5.

منهجية الرشاقة تؤدي إلى تغييرات سريعة يتم تنفيذها في الإنتاج، مما يؤدي بدوره إلى عدد كبير من مشاكل الدعم بسبب التغذية الراجعة. إدارة صعوبات الدعم مسؤولية كبيرة وحيوية، كما يتضح من حقيقة أن 68٪ من المستهلكين يعبرون عن استعدادهم لدفع مبلغ إضافي مقابل المنتجات والخدمات من شركة معروفة بتقديمخدمة عملاء ممتازة. وفقا لدراسة، 86٪ من العملاء الذين يحصلون على خدمة عملاء ممتازة هم أكثر احتمالا لأن يصبحوا مدافعين مخلصين عن العملعلى المدى الطويل. وفقا لدراسة، 89٪ من المشترين يميلون أكثر لإعادة الشراء إذا كانت لديهم تجربة خدمة عملاء إيجابية8. وفقا لدراسة، يميل 93٪ من العملاء إلى إجراء عمليات شراء متكررة مع شركاتتقدم خدمة عملاء استثنائية. لتقديم خدمة عملاء ممتازة، من الضروري حل طلبات الدعم بسرعة وفعالية بجودة عالية. عنصر الجودة مهم جدا عند السعي نحو تسليم أسرع، حيث ترتفع تكلفة حل مشاكل الدعم مع مرور الوقت وارتفاع مستوىالتصعيد 10.

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

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

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

للحصول على فهم حول كيفية تعامل الصناعة مع قضايا الدعم وإجراء الاختبارات الوقائية، أجرينا دراسة بحثية وصفية من خلال مقابلات مع محترفين في المجال11. استنادا إلى بيانات المقابلة، تم التأكيد على أن أكبر عقبة تواجهها أثناء تنفيذ أي حل هي الوقت غير الكافي لضمان الجودة. خلال المقابلة، تم الإشارة إلى عدة مخاوف، منها تطوير مهارات الأفراد، نفقات الصيانة، انخفاض العائد على الاستثمار، واختيار الأدوات ودمجها11. وقد تم التحقق من هذه المعلومات أيضا في تقرير كاتالون "حالة الجودة 2024"12.. قبل تقديم أي حلول للمشاكل المذكورة في المقابلات، أجرينا تقييما مقارنا للأدوات لمعرفة ما إذا كانت هناك أدوات أو خوارزميات موجودة تعالج المخاوف المذكورة13,14. نحن الآن نفتقر إلى الأدوات أو الخوارزميات اللازمة المصممة خصيصا لمعالجة الصعوبات التي نوقشت في المقابلات.

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

تشير الملاحظة، في سياق نظرية التحكم، إلى مدى إمكانية استنتاج الحالات الداخلية للنظام من مخرجاته الخارجية. في مجال هندسة البرمجيات، تشير فكرة قابلية الرصد إلى القدرة على مراقبة وفهم حالة النظام البرمجي من خلال استخدام مخرجات مثل السجلات، والمقاييس، والآثار، والأحداث15، 16، 17. يشمل تحليلنا الأدبي دراسة قابلية الملاحظة واستخدامها في اختبار البرمجيات. ومع ذلك، وجدنا أدبيات محدودة متاحة حول هذا الموضوع. لذلك، أدرجنا أيضا مناقشات حول اختبارات وقائية مبتكرة وأبحاثا ذات صلة. تصنف مراجعتنا الأدبية إلى 3 مجموعات مختلفة.

يقدم بوغاتينوفسكي وآخرون تقنية CLog، وهي تقنية تجميع وشبكة عصبية واعية للسياق مصممة لمعالجة بيانات السجل غير المستقرة وتغطية الفشل غير الكافية من خلال تحديد العمليات الفرعية المهمة واكتشاف الأعطال وسط انتقالات سياقية مفاجئة. يقترح بوسبي وآخرون منهجية قائمة على السجل لإنشاء حالات اختبار مجهولة، وتتنبأ بتسلسلات المستخدمين للتكرار دون وجود بيانات شخصية؛ ومع ذلك، تستمر التغيرات في التزامن ومستوى المسجل كقيود كبيرة. يقترح لي وكانغ20 تنفيذ بنية اختبار لاختبار خطوط إنتاج البرمجيات لتحسين قابلية الملاحظة والتحكم في وجود آليات التغير. يجمع نموذج QEX21 بيانات من مصادر اختبار مختلفة لتقديم معلومات واضحة ومفيدة أثناء إجراء الاختبارات. يؤكد لال وكومارالبالغ من العمر 22 عاما على أهمية القدرة على رؤية والتحكم في الاختبارات الذكية. يقترحون استخدام الأتمتة المدعومة بالذكاء الاصطناعي لجعل الاختبار أسرع وأكثر كفاءة وشمولية. يوضح برياند وآخرون تطبيق البرمجة الموجهة نحو الجانب في جافا لأدوات فعالة للعقود والثوابت، بينما يؤكد بارال وأوفوت24 على مشكلة الادعاءات الخاطئة في الاختبارات التي تؤدي إلى "اختبارات عمياء"، لا تحدد سلوكا خاطئا.

يناقش Rott25 أن التحليلات والتصورات الحديثة داخل Teamscale تركز على عملية اختبار البرمجيات من خلال السماح للمختبرين بالوصول إلى القطع المعالجة الخاصة بالقضايا والوضع المطلوب. يؤكد كولينز ولوسينا26 على أهمية إجراء الكثير من الاختبارات في خط أنابيب CI قبل نشرها في الإنتاج. يقولون إن الاختبار متعدد الطبقات طريقة جيدة لضمان جودة المنتج وتقليل مشاكل الدعم.

يقدم BugSwarm27 طريقة لفحص فشل اختبارات CI من خلال ربط الأسباب الجذرية مع حلولها الخاصة. يفحص دوديلا وليتيا28 منهجيات اختبار الصندوق الأبيض والصندوق الأسود، مقترحين استراتيجية متماسكة للتخفيف من جهود تصحيح الأخطاء أثناء عملية التطوير. قام فوشيهارا وآخرون 29 بدراسة "روائح الاختبار" في تطبيقات بايثون، وحللوا تطورها من خلال تعديلات الشيفرة لتحسين إدارة شيفرة الاختبار. SUPERNOVA30 هو نظام لاختيار الاختبارات ومنع الأعطال التي تستخدم البيانات والأتمتة والتعلم الآلي لتحسين ضمان الجودة. يقترح أراوجو31 استراتيجية صيانة تركز على شيخونة البرمجيات. تستخدم هذه الاستراتيجية الصيانة التصحيحية عندما تكون تغييرات الكود ممكنة، واستراتيجيات وقائية عندما قد تسبب التغييرات وقتا لإيقاف النظام، مما يقلل من عدد أعطال الخدمة. يحقق أندرو وآخرون في اختبار الطفرات المتوازية، وهي عملية يتم فيها تحوير الفئات بشكل متكرر، واختبارها، وإعادة تحميلها حتى يتم تقييم جميع المتغيرات. يقترح دن وآخرون مقاييس ثغرات أمنية تخصص أوزانا للمكونات لتأكيد أهمية الاختبار الشامل. أخيرا، يستخدم Huo وآخرون فهرس مجموعات تسلسلي لتحديد مواقع العيوب وتأكيد المشكلات. هذا يوضح أن الأسباب الجذرية غالبا ما ترتبط بمعظم حالات الاختبار الفاشلة في تطبيقات البرمجيات.

Access restricted. Please log in or start a trial to view this content.

Protocol

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

ملخص بنية النظام والنموذج الأولي:

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

figure-protocol-1
الشكل 1: المدخلات والمخرجات للنظام المقترح. يتم توفير بيانات قابلية المراقبة، إلى جانب مخرجات المراقب، ومستودع الاختبار، وقواعد الخرائط، كمدخلات إلى جانب أسرة اختبار BHRAMARI، التي تبني منصات اختبار مدفوعة بالذكاء الاصطناعي لتعزيز متانة حالات الاختبار. يقوم النظام المقترح بتوليد أجهزة للشذوذات، والتوصيات التي تولدها الذكاء الاصطناعي، وتنفيذ حالات الاختبار ذات الصلة، والتوثيق والتقارير، بالإضافة إلى تحديد وإنشاء حالات الاختبار المفقودة. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

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

figure-protocol-2
الشكل 2: بنية النظام المقترح مع جامع ومحلل بيانات قابلية الملاحظة، طبقة ذكاء مدعومة بالذكاء الاصطناعي المولد، ومحرك التنسيق والتنفيذ للاختبار. يوضح هذا الشكل البنية الداخلية لنظام PreventativeTestPro، المقسم إلى ثلاث طبقات: طبقة جامع الملاحظة تجمع البيانات من مصادر متعددة، بما في ذلك أحداث المتصفح، السجلات، ملفات HAR، سجلات الخلفية، المقاييس، والتسلسلات. تستخدم طبقة الذكاء الاصطناعي التوليدي هذه البيانات لإجراء تحليل السبب الجذري، وتحديد أولويات الشذوذات، وإنشاء حالات اختبار (واجهة مستخدم، واجهة برمجة تطبيقات (API، دليل) وتوثيق بشكل مستقل من خلال استخدام نماذج اللغة الكبيرة (LLMs). كما تنشئ وحدة بهاراماري أسرة اختبار جديدة. يقوم محرك تنسيق الاختبار وتنفيذ الاختبارات برسم التناقضات مع حالات الاختبار، وينفذ الاختبارات في نفس الوقت، ويقيم النتائج، ويبلغ فرق الهندسة، وأنظمة التذاكر، ولوحات المعلومات لمراقبة الرقابة والحل في الوقت الحقيقي. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

تعمل وحدة جامع ومحلل بيانات الملاحظة كنظام حسي للمنصة، حيث تجمع باستمرار بيانات التطبيق قيد التقييم على نطاق واسع، مع جوانب متعددة. في حالة مراقبة الواجهة الأمامية، يتم نشر وكلاء المراقبة الاصطناعية لمراقبة أحداث جانب المتصفح، مثل هياكل نموذج كائن المستند (DOM)، وإجراءات المستخدم مثل النقرات، والهوفرز، والمدخلات، وملفات HAR التي تلتقط معلومات الطلبات والاستجابة على الشبكة وواجهة برمجة التطبيقات (API). PreventativeTestPro مدمج أيضا مع OBSERVER لزيادة قدرات المتصفحات. تستهدف المراقبة الخلفية تحليل السجل، حيث تطلب وتعالج معلومات الملاحظة على جانب الخادم، والتي تشمل سجلات التطبيقات، ورسائل الأخطاء، والمعلومات، ورسائل التصحيح، وسجلات تتبع المكدس والاستثناءات، ومقاييس الأداء مثل أوقات الاستجابة، والتتبع باستخدام تقنيات مثل OpenTelemetry أو New Relic. سيعمل النظام مع وكلاء صناعيين يحاكي حركة مرور المستخدمين وتفاعلهم، ويقوم جامعو السجلات بتكثيف البيانات الواردة في الوقت الحقيقي. ثم يتم تطبيع البيانات المجمعة إلى صيغ منظمة وتسليمها إلى وحدات معالجة أخرى لتحليلها بشكل أعمق.

جوهر PreventativeTestPro هو طبقة ذكاء مدعومة بالذكاء الاصطناعي المولد تستخدم نماذج اللغة الكبيرة (LLMs) مثل GPT لقراءة وتحليل بيانات الملاحظة ووضع سياقها وتوليد الردود. تقوم الوحدة بتحليل السبب الجذري: وهي عملية تفسير سجلات وآثار السبب الجذري لشرح الأخطاء التقنية بمصطلحات يمكن فهمها، مثل NullPointerException على سطر معين من الكود والسبب المفترض للمشكلة، مثل متغير غير مهيأ. في توليد حالات الاختبار، يستخدم النظام اختبارات تلقائية يتم إنشاؤها عن طريق تحويل أنماط الاستثناء أو تسلسل الأحداث إلى سكريبتات اختبار قابلة للتنفيذ، مثل اختبارات Selenium أو API، كما ينتج أيضا إجراءات اختبار قابلة للقراءة من قبل الإنسان يمكن لموظفي ضمان الجودة تشغيلها. تطورت اختبارات واجهات برمجة التطبيقات من خلال تحويل سجلات HAR وتتبع التتبع إلى سلسلة من طلبات API مع التأكيدات المتوقعة، وجميع حالات الاختبار المولدة تم تحسينها أكثر من خلال منصات اختبار فعالة من خلال التكامل مع BHRAMARI. يقترح نظام التوصية تحسينات إضافية، وتحسينات في تغطية الاختبارات، وفرص دمج CI/CD، حسب سلوك النظام المحلل. يستخدم محرك الذكاء الاصطناعي بيانات الملاحظة المنظمة عبر هندسة الأوامر وإثراء السياق لتقديم سياق السجل مع قوالب مطالبات تمرر الاستعلامات المنظمة إلى النموذج اللغوي، وأخيرا يولد مخرجات بشكل وظيفي، مثل مقتطفات الكود، مواصفات حالات الاختبار، وتوثيق اللغة الطبيعية.

تتولى وحدة الاختبار لتنسيق وتنفيذ الاختبار أولوية الاختبار، والجدولة، والتنفيذ، مما يتيح التحقق التلقائي بناء على تفاصيل تغطية تغيير الكود، والعلامات، ورسم الخرائط الشذوذ. يتضمن تعيين واختيار الاختبار ربط الشذوذات في الخرائط أو أنماط الأجهزة بحالات اختبار معروفة باستخدام محرك قواعد الخرائط، ثم تشغيل حالات الاختبار وفقا للرسم المعتمد. تسمح ميزات تنفيذ الاختبار المتزامن بإجراء أنواع متعددة من الاختبارات في نفس الوقت، مثل اختبارات وظيفية أو أدائية أو أمنية في بيئات مختلفة وتنسيق استخدام Selenium وJMeter وZAP كأدوات في خطوط أنابيب الأتمتة. يضمن تنفيذ حلقة التغذية الراجعة تسجيل نتائج التنفيذ، وفي حال فشل الاختبار، يتم إبلاغ التغييرات إلى أنظمة الدعم، بما في ذلك Jira وAzure DevOps، لتتبعها وحلها.

الفرضية:

H1 (الكفاءة التشغيلية): يفترض أن دمج بيانات قابلية الرصد والذكاء الاصطناعي المدفوع بالذكاء الاصطناعي سيعزز المقاييس التشغيلية، لا سيما من خلال تقليل متوسط الوقت للحل (H1a)، ومتوسط وقت التحليل (H1b)، ومتوسط الوقت لاكتشاف مشاكل الإنتاج (H1c)، ومتوسط الوقت لنشر الإصلاحات في الإنتاج (H1d). يجب أن تجعل هذه التغييرات من السهل تلبية متطلبات اتفاقية مستوى الخدمة (SLA) (H1e) من خلال تسريع الكشف والتحليل والنشر مع تقليل وقت توقف النظام إلى الحد الأدنى.

H2 (فعالية الاختبار): يعتقد أيضا أن فعالية اختبار البرمجيات ستتحسن مع زيادة تغطية الاختبار (H2a)، وتشغيل حالات الاختبار بالتوازي (H2b)، وتحديد أولويات الاختبارات الذكية (H2c). من المتوقع أيضا أن تساعد التوصيات التي يولدها الذكاء الاصطناعي (H2d) في كل من سير العمل الاختباري والتشغيلي. سيساعد ذلك في اكتشاف الأخطاء بشكل أسرع، وتسريع حلقات التغذية الراجعة، ودعم ممارسات ضمان الجودة الوقائية وطويلة الأمد.

النطاق والجمهور:

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

إعداد البيئة:

يحتوي الملف التكميلي 1 على وصف خطوة بخطوة وبرنامج مطلوب للتواصل مع PreventativeTestPro. يشمل ذلك تعليمات لتثبيت البيئة اللازمة، وكيفية بدء وإيقاف خدمات الأداة، وشرحا واضحا للاستخدام الأساسي للأداة. للحصول على توثيق أكثر تفصيلا، إلى جانب تعليمات حول كيفية استخدام الأدوات المتقدمة، وتعليمات الإعداد، وتفاصيل تنظيمية أخرى، راجع المصادر الرسمية على GitHub المخصصة للمشروع: صفحة الويكي المحددة في موقع https://github.com/sohambpatel/PreventativeTests/wiki وصفحة README الرئيسية في https://github.com/sohambpatel/PreventativeTests?tab=readme-ov-file/readme.

مدخلات نموذجية:

يمكن العثور على ملفات الإدخال النموذجية في مستودع GitHub: https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/Inputs. يمكن للإطار تشغيل حالات الاختبار والبيانات المحددة مسبقا لهذه الملفات فورا. تستخدم كمدخلات مرجعية لفحص إعداد البيئة والحصول على نفس النتائج الموصوفة في هذا البروتوكول.

مخرجات العينات:

يحتوي مستودع GitHub (https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/SampleOutputs) على عينات ملموسة من بيانات إخراج إطار الاختبار الوقائي بصيغة خام. من خلال هذه الملفات، يمكن للمستخدمين عرض تصميم وتفاصيل التقارير والمقاييس المولدة مباشرة، مما يوضح النتائج التي حققتها الأداة أثناء تشغيلها. هذا الدليل ذو صلة بمعرفة خط أنابيب البيانات وتأكيد سلوك الإطار المتوقع أثناء إعادة إنشاء العملية التجريبية.

نموذج التنفيذ:

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

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

figure-protocol-3
الشكل 3: واجهة المستخدم 1 للنظام. يوضح هذا الشكل واجهة المستخدم PreventativeTestPro، التي تتيح الاختيار من بين خمس طرق مختلفة لإجراء الاختبارات الوقائية: 1. الاختبار الوقائي، التنفيذ المتوازي: بدء الاختبار، 2. الاختبار الوقائي، إنهاء مجموعة الاختبارات بناء على مراقبة التطبيقات الاصطناعية، 3. الاختبار الوقائي، توليد حالات اختبار يدوية باستخدام الذكاء الاصطناعي المولد، 4. الاختبار الوقائي، توليد حالات اختبار آلية باستخدام الذكاء الاصطناعي المولد، 5. الاختبار الوقائي، تحليل السبب الجذري باستخدام الذكاء الاصطناعي المولد. يمكن اختيار خيار واحد فقط في كل مرة. التصميم المعياري يسهل إجراء الاختبارات الوقائية ويضيف إنشاء اختبارات مدعومة بالذكاء الاصطناعي وتشخيصات. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

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

figure-protocol-4
الشكل 4: واجهة المستخدم 2 للنظام. يوضح هذا الشكل وضع التنفيذ المتوازي في إطار PreventativeTestPro. يحدد المستخدم رابط التطبيق المستهدف والمسار إلى ملف خصائص يحتوي على تفاصيل التكوين. تشمل الخيارات اختبار بدء (لتشغيل اختبارات الوظائف والأمان والأداء بالتوازي وتسجيل السجلات)، وإيقاف الاختبار (لإيقاف التنفيذ)، والحصول على توصيات (للحصول على رؤى مدعومة بالذكاء الاصطناعي من السجلات والمقاييس). يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

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

figure-protocol-5
الشكل 5: واجهة المستخدم 3 للنظام. يوضح هذا الشكل كيفية ترتيب أولويات مجموعة الاختبارات في إطار عمل PreventativeTestPro باستخدام مخرجات المراقبة الاصطناعية. يقوم المستخدم بإدخال مسار ملف إخراج المراقبة، ومسار JSON للحصول على الاستثناءات/الأخطاء، والمسار إلى مستودع الاختبار (غير متصل). يمكن استخدام خيارات Get class/method Name و Get Test Cases لتحويل شذوذات التعيين إلى حالات اختبار يمكن تشغيلها. هذا يضمن تضمين مشاكل وقت التشغيل في عملية الاختبار. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

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

figure-protocol-6
الشكل 6: واجهة المستخدم 3 للنظام. يظهر هذا الشكل واجهة توليد حالات الاختبار في PreventativeTestPro. يحول تتبع تكديس الشذوذات إلى حالات اختبار يدوية في تطوير السلوك المدفوع (BDD) يمكن استخدامها. يعطي المستخدم المسارات إلى ملف تتبع المكدس وملف الخصائص ثم ينقر على "توليد حالات اختبار" ليقوم تلقائيا بإنشاء الحالات التي تطابق الفشل الذي تم العثور عليه. هذا يضمن أن مشاكل وقت التشغيل تتحول دائما إلى اختبارات انحدار يمكن تكرارها. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

يوضح الشكل 7 واجهة توليد حالات الاختبار الآلي من PreventativeTestPro. في هذه الخطوة، يعطي المستخدم المسار المطلق لملف إخراج JSON الخاص بالملاحظة والمسار إلى ملف تكوين الخاصية. عند الضغط على زر إنشاء حالات اختبار آلية، يعالج النظام بيانات المراقبة ويجعل حالات الاختبار يمكن تشغيلها لتظهر نفس المشاكل التي تم رؤيتها.

figure-protocol-7
الشكل 7: واجهة المستخدم 4 للنظام. يظهر هذا الشكل واجهة توليد حالات الاختبار الآلي ل PreventativeTestPro، التي تقوم بإجراء اختبارات يمكن تنفيذها باستخدام بيانات الملاحظة. يعطي المستخدم المسار إلى ملف الخصائص وملف إخراج JSON الخاص بالملاحظة. ثم ينقرون على "توليد حالات اختبار آلية" لإنشاء سكريبتات يمكن تشغيلها (بصيغتي Selenium وTestNG). يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

figure-protocol-8
الشكل 8: واجهة المستخدم 5 للنظام. يظهر هذا الشكل واجهة أجهزة الشذوذ في PreventativeTestPro لتحليل السبب الجذري (RCA). يعطي المستخدم المسار إلى ملف الخصائص وملف تتبع المكدس، ثم يختار RCA لبدء التحليل المعتمد على الذكاء الاصطناعي. تحول هذه الخطوة الشذوذات المكشوفة إلى رؤى تشخيصية منظمة، مما يضمن إصلاح الأعطال بطريقة يمكن تكرارها وتكون خاصة بالمشكلة. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

استكشاف المشكلة:

يوضح الجدول 1 أهم نقاط استكشاف الأخطاء التي تتعلق فقط بكود التطبيق. هذه النقاط هي طريقة سريعة لتذكر كيفية إصلاح المشكلات على مستوى الكود التي تظهر عند تشغيل إطار PreventativeTestPro. توفر وثائق المشروع مزيدا من المعلومات وتعليمات خطوة بخطوة للقراء الذين يرغبون في مزيد من المساعدة في حل المشكلات التي تؤثر على وظائف التطبيق بشكل عام. يمكن الحصول على المورد الكامل من الرابط: https://github.com/sohambpatel/PreventativeTests/wiki/How-to-use%3F. يضمن هذا المرجع الإضافي أن المستخدمين لا يصلحون مشاكل البرمجة فحسب، بل يتعلمون أيضا كيفية استكشاف الأخطاء والدوال، مما يمكنهم من استخدام الإطار بشكل أكثر فعالية.

سلوك الخطأالسبب الجذريكيف يمكن إصلاحها؟
الطلب لم يبدأمسار جافا غير محددفي متغير البيئة، اضبط JAVA_HOME
فشل الخادم عند بدء التشغيلالمنفذ 8080/9090 قيد الاستخدام (تحديدا أثناء استخدام Docker)تحديث تعيين منافذ Docker
محتوى الذكاء الاصطناعي المولد غير عادلقد يكون الرمز قد انتهى صلاحيتهقم بتوليد الرمز وتحديث إعدادات config.properties قبل أن توفر ذلك كمدخل
نسخة المتصفح التي تولدها الإطار لا تتصل بالشبكةإما أن خادم ZAP غير يعمل أو أن بيانات اعتماد ZAP غير صحيحةقم بتشغيل جهاز ZAP قبل تشغيل التطبيق، في حال كان يعمل واستمرت المشكلة، قم بتحديث بيانات اعتماد ZAP في config.properties قبل أن تقدم ذلك كمدخل

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

Access restricted. Please log in or start a trial to view this content.

Results

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

نتائج دراسة حالة الصناعة:

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

Access restricted. Please log in or start a trial to view this content.

Discussion

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Access restricted. Please log in or start a trial to view this content.

Disclosures

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Acknowledgements

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

يعبر المؤلف عن امتنانه للدعم والتعاون الكبير الذي قدمته المنظمات التالية خلال هذا البحث. كانت دراسات الحالة التجريبية التعاونية مع هذه الشركات حاسمة في دعم الأداة والطريقة المقترحة. يعرب الشكر إلى GazonTech وLopa Engineering وAfour Technologies وQJ Technologies وSecureLayer7 لمنحهم الوصول إلى البيئة العملية، والرؤى التقنية، والمدخلات القيمة خلال المرحلة التجريبية. وقد عزز مشاركتهم النشطة بشكل كبير الأهمية العملية وقابلية استخدام نتائج البحث. يعبر المؤلف عن امتنانه العميق لاستعداده للمشاركة في البحث الأكاديمي وتفانيهم في الابتكار والتطوير المستمر في مجالات هندسة البرمجيات والأمن السيبراني.

Access restricted. Please log in or start a trial to view this content.

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
أباتشي مافنمؤسسة أباتشي للبرمجيات3.9.6أداة إدارة الاعتماد والمشاريع لمشاريع جافا
ChatGPT (واجهة برمجة تطبيقات GPT-3.5 Turbo)OpenAIhttps://platform.openai.com/api-keysلتوليد توصيات اختبار تعتمد على الذكاء الاصطناعي من السجلات، وتوليد حالات الاختبار اليدوية، وتوليد حالات الاختبار الآلية، والحصول على تحليل السبب الجذري
الحاسوب (آلة التطوير/الاختبار)جهاز مكتبي/لابتوب قياسي-يستخدم لتطوير وتنفيذ واختبار PreventativeTestPro
فضاء الأقراص--يوصى بتوفير مساحة قرص خالية لا تقل عن 10 جيجابايت للسجلات والتقارير وتشكيلات الاختبار
دوكرشركة دوكر27 (https://docs.docker.com/desktop/setup/install/windows-install/) يستخدم في الحاويات لضمان قابلية التكرار عبر البيئات
اذهبGit SCMإصدار git 2.45.2.windows.1نظام التحكم في الإصدارات المستخدم في التطوير والتعاون
مستودع GitHubGitHubhttps://github.com/sohambpatel/PreventativeTestsمستودع عام يحتوي على الشيفرة المصدرية، والوثائق، ومجموعات البيانات، وأمثلة
جوجل كرومجوجل140.0.7339.128المتصفح الأساسي المستخدم للمراقبة والاختبار التركيبي
جافاأوراكل / OpenJDK21.0.2يستخدم لتطوير وتنفيذ البرمجيات PreventativeTestPro
نظام التشغيلمنصة مستقلة-الأداة تعمل على أي نظام تشغيل مثبت على جافا وMaven (ويندوز، لينكس، ماك أو إس).
OWASP ZAPمؤسسة OWASP2.14.0أداة المسح الأمني واكتشاف الثغرات
المعالج--يوصى بمعالج Intel i5 أو أعلى (أو ما يعادله) للتنفيذ المتوازي والمعالجة بالذكاء الاصطناعي
ذاكرة RAM--يوصى بحد أدنى 8 جيجابايت رام لإجراء الاختبارات والمراقبة عبر المتصفح

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. A novel approach to multiple criteria based test case prioritization. Abid, R., Nadeem, A. 2017 13th International Conference on Emerging Technologies (ICET), Islamabad, Pakistan, , (2017).
  2. Khatibsyarbini, M., Isa, M. A., Jawawi, D. N., Tumeng, R. Test case prioritization approaches in regression testing: A systematic literature review. Inf Softw Technol. 93, 74-93 (2017).
  3. Enhanced weighted method for test case prioritization in regression testing using unique priority value. Ammar, A., Baharom, S., Ghani, A. A. A., Din, J. 2016 International Conference on Information Science and Security (ICISS), Pattaya, Thailand, , (1109).
  4. Using artificial bee colony for code coverage based test suite prioritization. Konsaard, P., Ramingwong, L. 2015 2nd International Conference on Information Science and Security (ICISS), Seoul, Korea, 10, Forthcoming.
  5. Rosero, R. H., Gómez, O. S., Rodríguez, G. Regression testing of database applications under an incremental software development setting. IEEE Access. 5, 18419-18428 (2017).
  6. Customer Service Expectations 2018. , Gladly. Available at: https://www.gladly.com/blog/2018-customer-service-expectations-survey/ (2018).
  7. Must-Know Customer Service Statistics. , Khoros. Available at: https://khoros.com/blog/must-know-customer-service-statistics (2025).
  8. State of the Connected Customer, 4th Ed. , Salesforce. Available at: https://c1.sfdcstatic.com/content/dam/web/en_us/www/documents/research/salesforce-state-of-the-connected-customer-4th-ed.pdf (2025).
  9. Customer Acquisition Study. , HubSpot. Available at: https://blog.hubspot.com/service/customer-acquisition-study (2025).
  10. IT Ticket Handling Best Practices. , Ivanti. Available at: https://www.ivanti.com/blog/it-ticket-handling-best-practices (2025).
  11. Patel, S., Patil, K., Chumchu, P. Quantitative data set on test prioritization and preventative tests. Mendeley Data. V2, (2023).
  12. State of Software Quality Report 2024. , Katalon. Available at: https://katalon.info/hubfs/download-content/ebook/State%20of%20Software%20Quality%20Report%202024.pdf (2025).
  13. Patel, S., Patil, K., Chumchu, P. OBSERVER: Observing Browser Synthetic Environments for Robotization, Verification, Efficiency, and Resilience. Softw Impacts. 24, 100752(2025).
  14. Patel, S., Patil, K., Chumchu, P. Comparative analysis of software solutions for preventative testing and test prioritization. Mendeley Data. V2, (2024).
  15. Intro to Synthetic Monitoring . , New Relic. Available at: https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/intro-synthetic-monitoring (2025).
  16. Observability Glossary. , SolarWinds. Available at: https://www.solarwinds.com/resources/it-glossary/observability (2025).
  17. Patel, S., Patil, K., Chumchu, P. BHRAMARI: Bug driven highly reusable automated model for automated test bed generation and integration. Softw Impacts. 21, 100687(2024).
  18. Failure identification from unstable log data using deep learning. Bogatinovski, J., Nedelkoski, S., Wu, L., Cardoso, J., Kao, O. 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid), Taormina, Italy, , (2022).
  19. Creating test cases for testing software using anonymized log data. U.S. Patent. , US11709764B2. USPTO (2023).
  20. Towards test architecture based software product line testing. Lee, J., Kang, S. 2014 IEEE 38th Annual Computer Software and Applications Conference (COMPSAC), Vasteras, Sweden, , (2014).
  21. QEX: Automated testing observability and QA developer experience framework. Locke, H. L., Ting Keshia, Y. K., Yu, J. C. K., Chua, H. Y. 2023 IEEE Conference on Software Testing, Verification and Validation (ICST), Dublin, Ireland, , (1109).
  22. Intelligent testing in software industry. Lal, A., Kumar, G. 2021 12th International Conference on Computing Communication and Networking Technologies (ICCCNT), Kharagpur, India, , (2021).
  23. Instrumenting contracts with aspect-oriented programming to increase observability and support debugging. Briand, L. C., Dzidek, W. J., Labiche, Y. 2005 21st IEEE International Conference on Software Maintenance (ICSM), Budapest, Hungary, , (1109).
  24. An empirical analysis of blind tests. Baral, K., Offutt, J. 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST), Porto, Portugal, , (1109).
  25. Rott, J. Test intelligence: How modern analyses and visualizations in Teamscale support software testing. 2022 1st International Workshop on Visualization in Testing of Hardware, Software, and Manufacturing (TestVis), Oklahoma City, OK, USA, , (2022).
  26. Collins, E. F., de Lucena, V. F. Software test automation practices in agile development environment: An industry experience report. 2012 7th International Workshop on Automation of Software Test (AST), Zurich, Switzerland, , (2012).
  27. BugSwarm: Mining and continuously growing a dataset of reproducible failures and fixes. Tomassi, D. A., Dmeiri, N., Wang, Y., Bhowmick, A., Liu, Y. C., Devan, P. T. 2019 IEEE/ACM International Conference on Software Engineering (ICSE), Montreal, Canada, , (2019).
  28. Towards combining functional requirements tests and unit tests as a preventive practice against software defects. Dudila, R., Letia, I. A. 2013 International Conference on Control Systems and Computer Science (ICCP), Sinaia, Romania, , (2013).
  29. Fushihara, Y., Aman, H., Amasaki, S., Yokogawa, T., Kawahara, M. A trend analysis of test smells in Python test code over commit history. 2023 49th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Durres, Albania, , (2023).
  30. SUPERNOVA: Automating test selection and defect prevention in AAA video games using risk-based testing and machine learning. Senchenko, A., Patterson, N., Samuel, H., Ispir, D. 2022 IEEE Conference on Software Testing, Verification and Validation (ICST), Valencia, Spain, , (2022).
  31. A software maintenance methodology: An approach applied to software aging. Araujo, J., Melo, C., Oliveira, F., Pereira, P., Matos, R. 2021 IEEE International Systems Conference (SysCon), Vancouver, BC, Canada, , Forthcoming.
  32. Mutual Automobile Insurance Company. Mutation Testing in Parallel Threads. U.S. Patent. , US11163675B1. USPTO (2021).
  33. Machine learning-based decision-making for autonomous systems communication. U.S. Patent. , US11366748B1. USPTO (2022).
  34. Use sequential set index for root cause location and problem detection. U.S. Patent. Huo, Z. P., et al. , US11645142B1. USPTO (2023).
  35. Selenium WebDriver. , Selenium. https://www.selenium.dev (2025).
  36. The Katalon Platform. , Katalon. Available from: https://katalon.com (2025).
  37. Apache JMeter. , Apache Software Foundation. Available from: https://jmeter.apache.org (2024).
  38. OWASP ZAP (Zed Attack Proxy). , OWASP Foundation. Available from: https://www.zaproxy.org/ (2025).
  39. Xray by Xpand IT. Xray - Test Management for Jira. , Xray. Available from: https://www.getxray.app (2025).
  40. Tricentis Copilot. , Tricentis. Available from: https://www.tricentis.com/products/copilot/ (2025).
  41. SmartQ Tech Products. , SmartQ Technologies. Available from: https://www.thesmartq.com/smartq-tech-products/ (2025).

Access restricted. Please log in or start a trial to view this content.

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Tags

Hybrid TestingObservability AutomationGenerative AI TestingSoftware Quality EngineeringTest OrchestrationBlack Box TestingWhite Box TestingLog AnalysisRegression CoverageAnomaly Detection

Related Articles