ظل اختبار تطبيقات سطح مكتب Windows من أكثر الميزات التي يطلبها العملاء منذ زمن طويل، لأنه لم يكن لدى أحد البنية التحتية اللازمة لتشغيل آلاف هذه الاختبارات بالتوازي كل شهر. اختبار الويب أسهل نسبيًا: يبدأ متصفح بلا واجهة رسومية داخل حاوية Linux في ثوانٍ، وتكلف جزءًا ضئيلًا من السنت، ويُتخلص منه عند انتهاء الاختبار. أما اختبار سطح مكتب Windows فليس له مقابل. يحتاج كل اختبار إلى جهاز افتراضي كامل، لأن حاويات Windows لا تتضمن سطح مكتب رسومي. يستغرق تشغيل جهاز Windows افتراضي من الصفر من دقيقتين إلى ثلاث دقائق، ويجب أن يكون هناك مستخدم مسجل الدخول، لأن أتمتة واجهة Windows لا تعمل إلا داخل جلسة سطح مكتب نشطة. كما تحتفظ الأجهزة بالملفات المثبتة ومفاتيح السجل وملفات تعريف المستخدمين وبيانات الدخول المحفوظة بين عمليات التشغيل، بينما تأتي كل تطبيق بمثبتاته الخاصة وطلبات المسؤول ونوافذ التشغيل الأول. كما أن أجهزة Windows البعيدة لا توفر تتبعات أو سجلات أو لقطات شاشة مدمجة، ومعظم البنية التحتية للاختبار صُممت حول Linux.
كان رد الفريق معاملة أجهزة Windows كالهواتف: جهاز يحجزه اختبار واحد، ويستخدمه مرة واحدة، ثم يتخلص منه. تستعير البنية من بنيتها التحتية لاختبار الأجهزة المحمولة. يخصص مجدول أجهزة مخصص في Kubernetes جهاز Windows افتراضيًا على Google Compute Engine عبر مطالبة بالجهاز (Device Claim)، ويتحكم فيه الاختبار عن بُعد باستخدام WebdriverIO وAppium. احتاج نموذج الجهاز إلى توسعتين: يمكن أن تعمل الأجهزة خارج الكتلة، ويمكن أن تُعيد المطالبات عناوين اتصال بسطح المكتب، بما في ذلك CDP للمتصفحات.
يتكون النظام من ثلاثة أجزاء: وحدة تحكم تحافظ على مجموعة مُسخّنة من أجهزة Windows الافتراضية، وحاوية (Pod) Linux للمشغّل تنفذ كود الاختبار، وجهاز Windows الافتراضي نفسه الذي يشغل التطبيق قيد الاختبار ووكيل سطح مكتب صغيرًا. يتصل المشغّل عبر CDP في Playwright لمحتوى المتصفح، وعبر Appium للتطبيقات الأصلية، وعبر بث WebRTC يتيح للناس مشاهدة الاختبارات مباشرة ومراجعة التسجيلات لاحقًا.
كل جهاز افتراضي قابل للتخلص منه. لا أحد يسجل الدخول إليه أو يحدّثه أو يبقيه قيد التشغيل لأسابيع، ويحل محل كل جهاز بعد استخدامه جهاز جديد.
المصدر: Hacker News · لخّصه HeadlinesBriefing