حدود المنصات
يُغنيك Astur تماماً عن استخدام Appium، لكنه بكل تأكيد لا يمتلك صلاحية تجاوز القواعد والقيود الأساسية التي تفرضها أنظمة التشغيل والمنصات نفسها.
توافق أنظمة التشغيل المضيفة (Host OS)
Section titled “توافق أنظمة التشغيل المضيفة (Host OS)”| نظام المضيف | أندرويد (Android) | نظام آبل (iOS) |
|---|---|---|
| macOS | مدعوم بالكامل | مدعوم لبيئات المحاكاة (Simulators) والأجهزة الفعلية المتصلة عبر USB، اعتماداً على أدوات Xcode ووكيل XCUITest |
| Linux | مدعوم بالكامل | يُستثنى تلقائياً نظراً لعدم دعمه محلياً |
| Windows | مدعوم بالكامل | يُستثنى تلقائياً نظراً لعدم دعمه محلياً |
منصة Android
Section titled “منصة Android”يُقدم نظام Android مجموعة قوية من الأدوات العامة التي تُتيح بناء أتمتة أصلية (Native Automation) فعالة بدون الحاجة لحقن أي حزم SDK إضافية داخل التطبيق نفسه:
- أداة الـ ADB تمتلك صلاحيات التثبيت، التشغيل، الإيقاف، التقاط الشاشة، وحتى إرسال مدخلات للمستخدم.
- مكتبة الـ UIAutomator تكشف شجرة الواجهة اعتماداً على طبقة “إمكانية الوصول” (Accessibility).
- بروتوكول الـ Chrome DevTools Protocol (CDP) القادر على أتمتة Chrome وأي مكون WebView يُسمح بتنقيح أخطائه (Debuggable).
يُرفق Astur الآن مع وكيل UIAutomator مطور بلغة Kotlin متواجد في المسار agents/android-uiautomator، وهو يمثل المسار الافتراضي والمعتمد للتفاعل العميق والأساسي مع واجهات Android.
الوضع الفعلي للدعم:
- مُشغل Android على المُضيف قادر بكفاءة على تهيئة الوكيل الأصلي وتأمين نقطة الاتصال.
- المسار البديل (Fallback) الذي يعتمد على ADB/UIAutomator XML لا يزال موجوداً ومتاحاً للطوارئ.
- وكيل Kotlin المُرفق يدعم كافة المهام الأساسية كـ
tree.get، الانتظار، تحديد العناصر، أوامر الإيماءات، والتحكم بلوحة المفاتيح. - ما زلنا نعمل على توسيع قدرات التشخيصات لتكون أكثر شمولاً وتوفير خيارات مطابقة (Selectors) أكثر عمقاً مستقبلاً.
الويب على الجوال (استهداف المتصفح)
Section titled “الويب على الجوال (استهداف المتصفح)”تتيح device.browser تشغيل صفحة ويب داخل متصفح الجهاز — Chrome على Android و Safari على iOS. راجع الويب على الجوال للدليل الكامل؛ وفيما يلي ملخّص القيود.
- لا يوجد عزل لبيانات التخزين على أي من المنصتين. فالتبويب (Tab) ليس سياق متصفح (Browser Context) بمفهوم Playwright: إذ تعود ملفات الارتباط (Cookies) و
localStorageوالأذونات إلى ملف تعريف المتصفح نفسه، وتتشاركها التبويبات جميعًا. امسحها صراحةً متى اعتمد اختبارك على ذلك. - يحصل Android على تبويب لكل اختبار، يُنشأ ويُغلق عبر مقبس التنقيح (Debugging Socket). أما iOS فلا — إذ لا يكشف مفتّش WebKit عن أي واجهة لإنشاء تبويبات Safari أو إغلاقها، فتُعيد الجلسة استخدام تبويب واحد وتحدّثه.
- واجهة المتصفح نفسها ليست جزءًا من الصفحة. فشريط العنوان ومبدّل التبويبات ونوافذ الأذونات كلها عناصر أصلية (Native)، تحتاج محدّدات أصلية ووكيلًا، ولا تتوفر لها كائنات صفحات (Page Objects) بعد.
- يجب تجاوز شاشة التشغيل الأول (First Run) في Chrome قبل أن يفتح تبويبًا أو ينشر مقبس التنقيح. ويُبلغ Astur عن ذلك بالخطأ
BROWSER_FIRST_RUN_PENDINGبدل انتظار مهلة تنتهي دون فائدة. ويكفي إتمامها مرة واحدة لكل نسخة محاكي. - يتطلب iOS أداة
ios-webkit-debug-proxy(الإصدار 1.9 فأعلى)، ويحتاج الجهاز الحقيقي إضافةً إلى تفعيل: الإعدادات ▸ Safari ▸ متقدم ▸ Web Inspector. - لم يجرِ التحقق على أجهزة iOS الحقيقية. فمسار الكود موجود لكنه لم يُشغَّل على جهاز فعلي بعد.
أُطر العمل (Flutter)
Section titled “أُطر العمل (Flutter)”يتميز Astur بقدرته الفائقة على أتمتة تطبيقات Flutter بدون وساطة Appium أو أي مشغلات خارجية خاصة بـ Flutter. (للحصول على شرح وافٍ، يُمكنك الرجوع لدليل Flutter و React Native). وفيما يلي تلخيص لأهم القيود:
على نظام Android، يقوم Astur بإنشاء اتصال مباشر مع خدمة Dart VM ليقرأ شجرة الودجات (Widget Tree) الحية والتفصيلية، مستخرجاً (مُعرف الـ Semantics، النص، التسمية، القيمة، والأبعاد) — مُتجاوزاً بذلك الاعتماد على طبقة إمكانية الوصول وحدها.
الميزات المدعومة حالياً (Android عبر خدمة Dart VM):
- التعرف التلقائي الذكي على ملف الـ APK المبني بـ Flutter، تشغيله، وتنفيذ “إعادة التشغيل السريع” (Hot Restart) بين الاختبارات.
- الفحص العميق لشجرة الودجات المتشابكة في الـ Inspector ومُولّد الأكواد.
- القدرة على استخدام مُحددات كـ
getById(لـ Semantics)،getByText، وgetByLabel. - تنفيذ أوامر النقر (الأساسي والمزدوج)، الضغط المطول، التعبئة النصية، والسحب (Swipe).
- التحكم بالاتجاهات، التقاط الصور، وتسجيل الشاشة بصيغتها الأصلية.
المتطلبات والقيود (Flutter/Android):
- شرط أساسي: يجب أن تكون الحزمة مَبنية بوضع Debug أو Profile، (لأن خدمة الـ VM غير متوفرة إطلاقاً في بنية الـ Release).
- البيئة المطلوبة: يجب تحديد المتغير
ASTUR_FLUTTER_PROJECT(وهو مسار كود Flutter المصدري)، وأن يكون أمرflutterمتاحاً في الـPATH(أو مُعرّفاً عبرASTUR_FLUTTER_PATH). - المعروض فقط: تقتصر الشجرة على عرض الودجات الظاهرة فعلياً على الشاشة — ستحتاج لتمرير الشاشة (Scroll) للكشف عن العناصر المخفية.
- التفاعل الخارجي: لا يمكن لخدمة Dart VM اكتشاف المكونات الخارجية كـ (نوافذ إعطاء الأذونات، منتقي الصور الأصلي، قوائم المشاركة للنظام).
- الإيماءات المعقدة: السحب المُوجه على ودجات الـ Pan عبر المدخلات الاصطناعية قد لا يوفر الدقة المثالية دائماً.
أما على iOS، فللأسف لا تتواجد خدمة الـ Dart VM؛ لذا يتم رصد شجرة تطبيق Flutter اعتماداً على نظام إمكانية الوصول في XCUITest. تعمل اختبارات الـ (Smoke tests) المرفقة بنسبة مبشرة (6 من 9 ملفات على المحاكي، وتشمل تسجيل الدخول، النماذج، والتمرير). كل ما تحتاجه هو إدراج Semantics(identifier:) في الودجات المستهدفة. ويقدم وكيل iOS آلية دعم إضافية بالبحث المقطعي (Partial Text) لإيجاد التسميات المدمجة في الـ Flutter.
ولكن يُستثنى من الدعم في (Flutter/iOS): السحب والإفلات (Drag & Drop) نظراً لقيود XCUITest في تسجيل الإيماءات الاصطناعية، وكذلك نوافذ الـ WebView واختيار الوسائط. يُرجى المرور لقسم Flutter على iOS للمزيد من المعلومات.
منصة iOS
Section titled “منصة iOS”على خلاف Android، لا يقدم الـ iOS أداة مكافئة لـ ADB تُتيح لك التحكم بحرية في الواجهة الأصلية.
بالنسبة للأمر على التطبيقات الـ Native، فإن المسار الأكثر موثوقية هو XCTest/XCUITest. وقد حرص Astur على إبقائه مباشراً وبأقل قدر من التدخل:
- لا حاجة لـ Appium Server.
- لا وجود لطبقة ترجمة عبر WebDriver.
- الوكيل (Agent) ُيكتب بـ Swift ويظل ضمن بيئة المشروع.
الوضع الحالي للدعم (iOS):
- مُشغل iOS يُدير تهيئة الوكيل المرفق ويعمل على تأمين الاتصال.
- أوامر المحاكي ولقطات الشاشة يتم تنفيذها بسلاسة عبر
simctl. - أما على الأجهزة الفعلية، فتُدار عمليات التثبيت والإيقاف كلها عبر الـ
devicectl. - محددات العناصر، النقر، الضغط المطول، السحب والإيماءات تعمل بكفاءة على المحاكي والأجهزة الفعلية عبر الوكيل المكتوب بـ Swift.
يتطلب التطبيق على أجهزة iOS فعلية وجود Apple Developer Account وجهاز موثوق وملفات (Provisioning Profiles). يقوم Astur بتدبير الدورة الأتمتة الكاملة لكنه لا يملك ابتكار هوية توقيع من عدم.
القيود الحالية (iOS):
- يُشترط التشغيل على أجهزة أصلية وجود فريق تطوير (Apple Development Team) مُعداد وملف موقع. استخدم المتغير
ASTUR_IOS_DEVELOPMENT_TEAMفي بيئات الـ CI، أو قم بتخصيص ملفات من الـ Xcode. - تلبية النظام محدودة بما يمكن لـ XCTest أن يراه. فإذا عجز الـ XCTest عن رصد نافذة النظام، فلن يكون الـ Astur قادراً على أتمتتها.
- لا تتوفر أدوات iOS عامة للمسح المباشر لبيانات التطبيق؛ المسار الموثوق لإعادة الضبط هو الإلغاء التثبيت ثم إعادة التثبيت.
- القفل والفتح وتسجيل الفيديو على الأجهزة الفعلية غير متاحة بشكل موثوق عبر أدوات معتادة من Apple. ولكن التقاط الصور (Screenshots) يعمل بكفاءة عبر الوكيل.
- أما التحكم في الـ DOM داخل الـ WebView يعمل بكفاءة على المحاكي والأجهزة الفعلية عبر
device.webContext()باستخدام أداةios-webkit-debug-proxy(الإصدار 1.9 فما فوق). يُشترط في هذا التطبيق أن يضبط الخيارWKWebView.isInspectable = true(في iOS 16.4 فما فوق) مع تثبيت الأداة. في المحاكي يُجيد Astur الـ Port المخصص لكل محاكي آلياً. أما في الأجهزة الفعلية يجب تفعيل هذا الخيار: الإعدادات ▸ Safari ▸ متقدم ▸ Web Inspector. يقوم المقيم بـ Astur بتغليف الاستعلامات بشكل شفاف، ليدير الـ WKWebView والـ Chromium WebView بنفس الكفاءة. (أما الـ DOM في الـ WebView على الـ Android، فيعمل بـ Chrome DevTools Protocol — للمزيد راجع WebViews (DOM)).
كل الأكواد الموجودة في المسار agents/ios-xctest-agent/ تمثل الـ Agent المكتوب بـ Swift. يتولى هذا الوكيل قراءة شجرة الإمكانيات والإيماءات والنقر ويرجع البيانات في صيغة JSON إلى الـ Node.js، ولا يتجاوز قيود Apple في التبليغ أو واجهات النظام.