Autotest Assist: توليد الاختبارات العشوائي لضمان جودة واجهات برمجة التطبيقات في اقتصاد السحابة

جدول المحتويات

1. المقدمة

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

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

2. التحديات الأساسية في توليد الاختبارات العشوائية لواجهات برمجة التطبيقات

يتضمن نموذج توليد الاختبارات العشوائية اختيار دالة واجهة برمجة تطبيقات $f()$ ومعاملات الإدخال القانونية الخاصة بها $p_1, ..., p_k$ بشكل عشوائي، وتنفيذها، ومراقبة المخرجات والتأثيرات الجانبية. يواجه هذه العملية عدة تحديات حرجة.

2.1 صحة المُدخلات النحوية والدلالية

بعد توليد مدخلات نحوية صحيحة، يجب على المُولِّد التأكد من التزام المعاملات بالشروط المسبقة لواجهة برمجة التطبيقات لكي ينجح الاستدعاء. على سبيل المثال، يتطلب استدعاء واجهة برمجة تطبيقات "شراء كتاب" $g()$ مرجعًا صالحًا لكتب تم الحصول عليه من واجهة برمجة تطبيقات سابقة "الحصول على كتاب" $f()$.

2.2 التحقق من السلوك ومشكلة أوراكل الاختبار

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

2.3 التنقيح وعزل المشكلات

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

2.4 التكامل مع مجموعات اختبارات الانحدار الموجهة

السؤال الأساسي هو كيفية دمج حالة اختبار قيمة، تم اكتشافها عبر التوليد العشوائي (خاصة تلك التي كشفت عن خطأ)، في مجموعة اختبارات انحدار موجهة مستقرة.

2.5 تقييم التغطية والثقة

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

3. منهجية Autotest Assist

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

3.1 مواصفات واجهة برمجة التطبيقات كأساس

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

3.2 استنتاج النموذج وتوليد الاختبارات

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

3.3 الكشف عن ثغرات المواصفات

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

4. الرؤى الأساسية ومنظور المحلل

5. التفاصيل التقنية والإطار الرياضي

جوهر Autotest Assist يتضمن استنتاج نموذج من المواصفات. يمكننا تصور واجهة برمجة تطبيقات $f$ كدالة ذات شروط مسبقة $Pre_f$ وشروط لاحقة $Post_f$. يتم تعديل حالة النظام $S$ بواسطة استدعاءات واجهات برمجة التطبيقات.

يمكن تلخيص خوارزمية التوليد على النحو التالي:

1. النموذج: لكل واجهة برمجة تطبيقات $f_i$، استخرج $Pre_{f_i}(S, \vec{p})$ و $Post_{f_i}(S, S', \vec{p}, \vec{r})$ حيث $S$ هي الحالة السابقة، $S'$ هي الحالة اللاحقة، $\vec{p}$ هي المعاملات، و $\vec{r}$ هي النتائج.
2. الاختيار: اختر واجهة برمجة تطبيقات $f_i$ بشكل عشوائي حيث يمكن تحقيق $Pre_{f_i}(S_{current}, \vec{p})$. يتطلب هذا حل $\vec{p}$ معطى $S_{current}$.
3. التوليد: ولِّد قيمًا ملموسة لـ $\vec{p}$ تحقق $Pre_{f_i}$.
4. التنفيذ والتحقق: نفذ $f_i(\vec{p})$، ولاحظ الحالة الجديدة $S'_{observed}$ والنتيجة $\vec{r}_{observed}$. تحقق من أن $Post_{f_i}(S_{current}, S'_{observed}, \vec{p}, \vec{r}_{observed})$ تتحقق.
5. تحديث الحالة: إذا كانت صالحة، حدّث $S_{current} = S'_{observed}$.

التحدي هو حل القيود في الخطوتين 2 و 3 بكفاءة، وهو ما يرتبط بمشكلة قابلية الإشباع مع النظريات (SMT).

6. النتائج التجريبية والأداء

بينما لا يحتوي مقتطف PDF المقدم على نتائج كمية محددة، تشير الورقة البحثية إلى مقاييس أداء ستكون حاسمة للتقييم:

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

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

7. إطار التحليل: مثال غير برمجي

فكر في "واجهة برمجة تطبيقات متجر كتب" مبسطة مع عمليتين:

1. GET /book/{id}: تُرجع تفاصيل الكتاب. الشرط المسبق: يجب أن يكون كتاب بالمعرف `{id}` موجودًا في المخزون.
2. POST /cart/{bookId}: تضيف كتابًا إلى عربة التسوق. الشرط المسبق: يجب أن يكون الكتاب بالمعرف `{bookId}` متاحًا (موجودًا وفي المخزون).

سير عمل Autotest Assist:

1. استنتاج النموذج: تقرأ الأداة المواصفات وتتعلم التبعية: `POST /cart` يتطلب استدعاء `GET /book` ناجحًا أولاً (لإثبات الوجود/التوفر).
2. توليد الاختبار: تقرر عشوائيًا اختبار `POST /cart/{bookId}`.
3. حل المعاملات: لتحقيق الشرط المسبق، يجب أولاً توليد معرف كتاب صالح `bookId`. قد تفعل ذلك إما عن طريق:
   أ) استدعاء `GET /book` بمعرف عشوائي حتى ينجح أحدها (الاستكشاف).
   ب) استخدام قائمة معروفة من المعرفات من جولة اختبار سابقة أو بيانات بذرة.
   ثم تستخدم هذا المعرف الصالح `bookId` لاستدعاء `POST /cart`.
4. اكتشاف الثغرات: إذا ذكرت مواصفات `POST /cart` فقط "يجب أن يكون الكتاب موجودًا" ولكن التنفيذ يتحقق أيضًا من مستوى المخزون، فقد يفشل الاختبار العشوائي. يحدد Autotest Assist هذا على أنه ثغرة في المواصفات: الشرط المسبق في المواصفات غير مكتمل.
5. تكامل الانحدار: يتم حفظ التسلسل `[GET /book/valid_id, POST /cart/valid_id]` الذي أضاف عنصرًا إلى عربة التسوق بنجاح كمرشح لمجموعة اختبارات الانحدار الموجهة.

8. التطبيقات المستقبلية واتجاهات البحث

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

9. المراجع

1. Farchi, E., Prakash, K., & Sokhin, V. (2022). Random Test Generation of Application Programming Interfaces. arXiv preprint arXiv:2207.13143v2.
2. Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing. John Wiley & Sons. (لمبادئ الاختبار الأساسية).
3. Osterweil, L., et al. (2020). Shifting Left: The Economic Impacts of Early Defect Detection. Carnegie Mellon University, Software Engineering Institute. (لتحليل التكلفة والعائد للاختبار المبكر).
4. Google Testing Blog. (2019). Fuzzing at Scale. تم الاسترجاع من https://testing.googleblog.com/. (لرؤى عملية حول الاختبار العشوائي على نطاق واسع).
5. de Moura, L., & Bjørner, N. (2008). Z3: An Efficient SMT Solver. Tools and Algorithms for the Construction and Analysis of Systems. (للأساس التقني في حل القيود المستخدم في توليد الاختبارات).
6. OpenAPI Initiative. (2023). OpenAPI Specification v3.1.0. https://spec.openapis.org/oas/v3.1.0. (للمعيار في مواصفات واجهات برمجة التطبيقات القابلة للقراءة آليًا).